반응형


원문 : Refactoring open source business models

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7808268979



오픈소스 비즈니스를 운영하는 것은 오픈소스 커뮤니티의 일부가 되는 것과는 많은 차이점을 가지고 있다.

 

저는 Lucidworks에서 일할 때 맨 처음 영업 상담 전화를 잊지 못할 것입니다. 우리는 막 펀딩의 첫걸음을 시작하고 첫번째 영업사원을 고용했습니다. 저는 기술적 자원으로써 잠재적인 고객들과 통화를 했습니다. 통화가 끝날 때 즈음 저는 고객들의 기술에 관련된 모든 질문에 대답을 했고, 그 결과 영업사원의 기회를 차례로 망쳐버렸습니다. 고객들은 우리회사의 도움없이도 자신들의 문제를 해결할 수 있었습니다.

 

저는 오픈소스 비즈니스를 운영한다는 것은 오픈소스 커뮤니티의 일부가 되는 것과는 많이 다르다는 것을 빨리 깨달았습니다. 우리가 지원을 우선시 하는 사업에서 제품에 초점을 맞춘 조직으로 성장함에 따라 지난 몇 년 동안 이 테마에 대한 변화는 정기적으로 발생해왔습니다.  모든 사업과 마찬가지로 우리는 어떻게 수입을 만들어낼지 생각해야 합니다. 오픈소스 비즈니스들은 주요 제품의 결과물이 프리(Free) 라이선스가 된다는 고유한 특성을 가지고 있습니다.  이것으로 인해 심각한 가격 하향을 야기하는 경우는 최선의 경우입니다. 최악의 경우에는 무료 소프트웨어, 무료 지식, 무료 지원처럼 모두 무료가 됩니다.

 

만약 오픈소스 프로젝트로 비즈니스를 하고 싶다면 당신은 이 현실이 어떻게 돌아가는지 알 필요가 있습니다. 실제로 “당신의” 코드 베이스가 실제로 당신 소유가 아니고 Apache Software Foundation과 같은 오픈소스 기관의 소유일 경우 더욱 복잡해 집니다. 그리고 당신은 종종 “당신의” 샌드박스 내에서 이익이 상충이 될 수 있습니다.

 

Lucidworks에서는 컨설팅과 지원을 우선적으로 하면서 “어떻게 이익을 만들수 있나” 라는 질문에 대답하기 위해 여러번 반복을 했습니다. 이것은 점차적으로 오픈소스로 직접 만들기를 원하는 사람들을 지원하는 옵션을 가지고 있으면서도 오픈소스로 만들어진 플랫폼을 판매하는 우리의 현재 모델로 진화를 했습니다. 이러한 접근에는 각각의 장점과 단점이 존재합니다.

 

컨설팅이 알맞은 팀에게 큰 이익을 가져다 줄 수는 있지만 변경하기가 힘듭니다. 따라서 마진이 적고 거의 벤처 기업 정도의 수익을 창출하는 회사가 알맞습니다. 우리들에게는 초기 컨설팅 프로젝트들은 무슨 기능을 만들지 학습하는데 중요한 역할을 했습니다.

 

당신의 소프트웨어가 유비쿼터스이고 반복되어 발생하는 계약의 사용자 비율을 변환할 수 있다면 지원은 정말 좋은 사업이 될 수 있습니다. 어떤 경우에는, 지원은 단지 초기에 소프트웨어에 버그가 발생하는 기간에만 필요하다고 생각했습니다. 그리고 일단 고객들이 초기 러닝커브를 극복하고 성공적인 배포를 하게 되면 기업들은 판매를 위한 다른 모델을 찾도록 강요합니다.

 

많은 기업들은 상업적 확장을 위해서 오픈소스 프로젝트를 선택합니다. 그리고 그들은 사람들이 부가적인 추가 기능을 사용하기 위해 돈을 지불하기를 기대합니다. 여기에서 문제는 특정 업체에 종속되거나, 또는 커뮤니티에 의해 만들어진 유사한 기능과 구분되고 지원을 강요 받는 데에서 생기는 어려움입니다. 만약 좋은 스위트 스폿을 찾았다면 당신이 커뮤니티의 좋은 집사 역할을 하는 동안은 마진을 유지할 수 있을 것입니다. 하지만 제품 개발에 대한 예리한 눈을 가지고 사용자가 실제로 필요한 것을 더 잘 이해하기 위해 지원하고 컨설팅 한 후에 성장하는 경우도 있습니다.

 

최선의 선택은 무엇일까요? 물론 대답은 당신의 오픈소스 프로젝트의 특별한 능력을 포함한 회사가 어떻게 출자됐는지, 팀의 스킬셋, 경쟁구도와 같은 다양한 요인에 따라 결정됩니다. 당신이 스스로 확산하지 않는 한 하이브리드 모델도 실용적이 될수 있습니다.

 

결론적으로 오픈소스 기업으로서 여전히 커뮤니티가 성장하고 육성되는 동안 “무료”라는 함정을 회피하기 위한 방법을 빠르게 결정해야 합니다. 단지 소프트웨어 회사로서 정상적으로 작동되지 않는 모델을 리펙토링하는 것을 두려워해서는 안됩니다. 

728x90
반응형
반응형

원문 : 3 challenges for using Docker


http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS3858827361



컨테이너가 어떻게 사용되고 어떤 기술과 인프라가 채택되고 있는지 알아봅시다.

요즘 컨테이너는 IT 업종에서 가장 뜨거운 주제입니다. 그런데 실제로 컨테이너가 어떻게 사용되고 있습니까? 2015년 5월에 Ruxit과 공동으로 O"Reilly Media는 현재 조직이 어떻게 컨테이너를 사용하고 있는지 또는 사용할 계획인지를 공유하기 위해 O"Reilly커뮤니티에 사람들을 초대해서 조사를 했습니다.
그 결과 컨테이너 기술들은(특히 Docker는) 어플리케이션 배포를 빠르고 쉽고 보다 유연하게 해주기 때문에 빠르게 채택되고 있는 것으로 밝혀졌습니다. 2015년 DockerCon에서 있었던 설문에서는 컨테이너를 어떻게 사용하고 있는지,어떤 컨테이너 기술과 인프라를 채택하고 있는지 그리고 그 컨테이너를 사용하는 데에 동기를 주거나 연관된 요소들은 무엇인지 밝히는 데에 중점을 두었습니다.

컨테이너, 확실하긴 하지만…
설문 응답자들 중 40%는, 현재 개발을 위해 사용하고 있다는 86%와 비교하여 "생산을 위해 컨테이너를 사용한다"고 대답 했습니다. Docker 컨테이너는 "한번에 빌드를 하고 언제 어디서나 실행 가능하도록" 설계 되어있습니다. 그런데 왜 컨테이너를 생산에 좀더 많은 부분에서 사용하지 않는 걸까요? 응답자들은 컨테이너를 채택하기 위해서는 기술의 성숙도, 오케스트레이션, 모니터링,자동화, 그리고 환경의 크기뿐만 아니라 컨테이너를 적용함으로써 생기는 장점을 개발팀, 관리팀, 고객에게 설득해야 하는 어려움도 존재 한다고 대답했습니다.


적용하는데 걸림돌이 되는 기술 성숙도
56%이상의 설문 응답자들은 컨테이너 기술을 활용한 인프라 구조로 변경하는데 가장 큰 장벽은 기술의 성숙도라고 응답했습니다. 과거 2년동안 릴리즈된 컨테이너와 연관된 모든 툴과 프로젝트들을 계속해서 파악하는 것은 어렵습니다. 그리고 그 것들 중 몇몇은 이름이 바뀐 것도 있고 아직 베타 버전인 경우도 있습니다. 이렇게 개발의 빠른 속도는 아직 안정성이나 성숙도를 보여줄 정도는 아닙니다.


그러나 컨테이너로 패키징 되고 동적으로 관리되는 마이크로 서비스 기반의 어플리케이션 개발을 발전시키기 위한 기존 기술들과 조화를 이루는데 초점을 맞췄던 설문은 6월, OCI가 포메이션에 대한 발표를 하기 전과 7월, Cloud Native Computing Foundation(CNCF)가 설립 되기 전에 종료되었습니다. 이런 주도적인 행동들로 짧은 기간에 컨테이너 기술이 어떤 영향을 줄 수 있는지 말하는 것은 쉽지 않습니다. 기존 기술들과 융화 되려면 아직은 시간이 필요합니다.


그러나 이 공간에 기존 툴을 가지고 있는 선두 업체들이 돌아오게 되면 이러한 주도적인 행동들은 안정성을 보장할 수 있게 됩니다. 그리고 그들은 컨테이너로 기동하는 일련의 안정적 통합 솔루션을 찾기 위한 진입 점을 제공할 것입니다.

대규모 배포 시에 중요한 요소인 오케스트레이션
응답자중 절반은 컨테이너를 채택하려고 할 때 오케스트레이션은 하나의 요소라고 응답했습니다. 이미 Docker를 사용하고 있던 응답자들은 이런 응답을 했습니다.


오케스트레이션은 멀티 컨테이너, 멀티 호스트 어플리케이션에 있는 컨테이너를 조직화하고 연결하는 기능을 가지고 있습니다. 그리고 특히 마이크로 서비스 아키텍쳐로 되어 있는 어플리케이션들을 위해 중요한 역할을 합니다. 예를 들어 웹 어플리케이션은 각각의 컨테이너에서 동작하는 수많은 백앤드 서비스들과 마찬가지로(페일오버나 로드발란싱을 위한) 프론트 앤드의 여러 개 인스턴스를 관리하기 위한 웹 서버들을 구동하는 컨테이너의 집합으로 구성되어있습니다.


분명하게 Google 의 Kubernates와 Mesosphere"s Marathone을 지원하는 오케스트레이션 툴들은 Apache Mesos로 만들어졌습니다. Docker 자체적인 오케스트레이션 툴인 Swarm, Compose, Machine은 2월에 릴리즈 되었고 Compose는 기존의 Fig 툴이 변경된 것입니다. 어떤 컨테이너 관련 기술들을 사용하고 있는지 응답자들에게 물었을 때 38%는 Docker Swarm을, 22%는 Kubernates를 , 22%는 Mesos를 사용하고 있거나 사용할 예정이라고 응답했습니다. 그리고 Kubernetes를 사용한다고 응답한 사람들은 대개 큰 기업에서 일을 하고 있었습니다. Docker Swarm과 Machine은 여전히 베타 버전이지만 Kubernetes는 CNCF를 출시했던 7월21일에 버전 1.0을 릴리즈 했습니다. 따라서 이러한 툴들이 발전할 수 있는 기회를 준 후에 적용 비율을 비교해보는 것은 매우 흥미로운 일이 될 것 입니다.

확장성 모니터링에 대한 제한 요인
컨테이너가 제품의 넒은 영역에 사용되면서 모니터링 툴에 대한 요구가 또한 증가하게 되었습니다. 응답자중 46%는 모니터링이 컨테이너화한 어플리케이션으로 변경하는데 중요한 요소라고 응답했습니다. 오직 1개의 호스트에서만 동작하고 디스크에 있는 로그파일(예:/var/log 아래)을 분석하는데 의존했던 기존 Linux기반의 모니터링과 리포팅 툴들은 멀티 컨테이너 클러스터 어플리케이션으로 변경하기에 적합하지 않았고 싱글 컨테이너 어플리케이션을 모니터링 하는 것 조차도 적합하지 않았습니다. 왜냐하면 저장되지 않은 데이터들은 컨테이너가 동작하지 않을 때에 디스크의 내용이 유지 되지 않기 때문입니다. 컨테이너 인식 모니터링 툴 또는 서비스를 사용하여 어플리케이션을 모니터링 하고 로그를 확인하는 것에 대한 집중화된 접근은 동적으로 다수의 컨테이너 어플리케이션을 관리하는 데에 더 적합합니다.


컨테이너의 상태를 모니터링 하기 위한 셀프 호스트 솔루션으로는 오픈 소스 툴인 cAdvisor와 Sensu, Prometheus가 있습니다.


Docker는 1.5버전부터 동작중인 컨테이너들의 스트리밍 자원의 사용 상태를 확인 하기 위한 Stats API를 지원해왔습니다. 그리고 수많은 벤더들은 New Relic, Scout, DataDog, SignalFX, AppDynamics 를 포함한 Docker Stats API로 만들어진 호스트 모니터링 툴을 제공합니다. 이 툴들은 컨테이너 상태를 모니터링 하지만 Stats API를 통해 제공된 데이터에 의존적입니다. 그리고 그런 이유로 컨테이너 안에서 동작하고 있는 서비스들이나 어플리케이션에 대한 좀더 상세한 정보는 제공하지 않습니다. Ruxits의 Docker Monitoring은 새로 생성된 컨테이너에 대한 오토 디스커버리를 제공합니다. 그리고 컨테이너 내부에서 동작하고 있는 어플리케이션과 서비스들에 대한 디스커버리와 Docker컨테이너 안에서 실행되는 마이크로서비스들과 동적 분산 어플리케이션에 대한 어플리케이션 중심 모니터링을 제공합니다.

자동화
40%의 응답자들은 자동화는 또 다른 요소라고 말합니다. 특히 자동화는 변경이 많은 마이크로 서비스 기반의 분산 어플리케이션 구현하는 데에 유용합니다. 예를 들어 하나의 서비스를 새로운 컨테이너로 변경 하는 것이 장소를 업그레이드 하는 것보다 낫습니다. 기존에 Jenkins와 같은 배포 툴(배포를 위해 Ansibl과 같은 CM 툴과 결합한)과 CircleCI같은 컨테이너 사용가능한 서비스들은 DockerHub로부터 직접적으로 Docker이미지들을 내려받고 CI/CD프로세스의 부분처럼 직접 빌드를 하고 배포를 할 수 있습니다. 동적으로 서로 관련이 있는 서비스들을 미리 연결하는 것보다 다른 서비스들을 동적으로 디스커버리 하는 것을 가능하게 하기 위한 Etcd와 Consul을 포함한 서비스 디스커버리 툴들은 이 이야기에 중요한 부분입니다.

요약
설문 응답자들에 의하면 컨테이너 기술 채택에 대한 높은 비율은 Docker와 컨테이너에 관련된 현재 업계에 대한 추세를 반영합니다. 응답자중 반 이상이 앞으로 6-12개월 안에 제품에 컨테이너를 사용할 예정이라고 말했습니다. 그리고 설문에 의해 확인된 분산 컨테이너 어플리케이션을 위한 자동화, 모니터링, 오케스트레이션과 같은 핵심적인 요소와 관련된 영역을 다루는 통합솔루션과 안정성, 제품준비에 대한 명백한 수요도 있습니다.
어떻게, 왜 사람들이 Docker를 사용하는지 배우기를 원하시나요? 설문의 나머지 부분을 읽어보십시요.

728x90
반응형
반응형

좀처럼 늘지않는 번역실력이라니..


원문 : Data Scientists: Generalists or specialists?


http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS8320856782



그 대답은 회사의 성숙에 대한 수준에 달려있습니다.

2008년에 LinkedIn에서 “데이터 사이언티스트”를 처음 모집할 때에 회사에서는 분명히 제너럴리스트를 원했습니다.

LinkedIn에 도전하세요. 우리는 매우 혁신적인 제품을 만들기 위한 작은 팀을 만들기 위해 분석적인 마인드를 갖고 있는 사람들을 찾고 있습니다.


특별한 테크니컬 스킬은 필요하지 않습니다.(회사에서 SQL, Python, R에 대한 교육을 제공할 예정입니다.) 당신은 매우 영리하고 넓은 배경지식을 가지고 있어야 합니다. 그리고 빨리 배울수 있어야 하며 독립적으로 일을 진행할 수 있어야 합니다. 이 직업은 정말 영리하고 주도적이며 창의적으로 문제를 해결하는데 매우 능숙한 사람에게 완벽한 직업입니다. 당신은 통계, 데이터 마이닝, 프로그래밍, 제품 디자인을 배우게 될 것입니다. 하지만 우리가 가르칠 수 없는 지적 능력과 창의력은 당신이 가지고 있어야 합니다.


반면에 오늘날 데이터 사이언티스트란 직업의 대부분은 높은 수준의 기술들을 요구합니다. 어떤 고용주들은 특정 프로그래밍 언어나 툴 셋에 대한 지식을 요구합니다. 또 다른 곳은 박사 학위나 머신 러닝과 통계에 대한 특별한 학위를 요구하는 곳도 있습니다. 그리고 많은 고용주들은 관련 분야에 경험이 있는 지원자를 선호합니다.

만약 당신이 데이터 사이언티스트들로 팀을 만든다면 제너럴리스트를 선택하겠습니까? 아니면 스페셜 리스트를 선택하겠습니까? 마찬가지로 대부분의 것들은 그것에 의존합니다. 회사가 해결해야 하는 문제의 종류, 팀의 크기, 재능에 대한 당신의 입장을 생각해 보십시오. 그러나 가장 중요한 것은 성숙에 대한 회사의 수준을 고려하는 것입니다.

초기

기업의 초기에는 스페셜리스트보다 제너럴리스트가 더 가치가 있습니다. 왜냐하면 당신은 아무런 사전 준비지식 없이 대부분의 제품을 만들고 무엇인가 없는 것보다 있는게 더 낫기 때문입니다. 당신의 첫 번째 분류는 game-changing 결과를 달성하기 위해 딥 러닝을 사용할 필요가 없습니다. 또한 당신의 첫 번째 추천 시스템도 gradient-boosted decision tree를 사용할 필요가 없습니다. 단순한 t-test 정도면 당신의 A/B 테스트의 요구를 충족시킬 것입니다.

이런 이유로 제품을 만드는 사람은 10년 정도의 머신 러닝 알고리즘을 사용한 경험이나 통계학 박사 학위는 필요하지 않습니다. 초기에는 데이터를 정제하든 네이티브 모바일 앱을 개발하든 원숭이처럼 스택 주위에 올라갈 수 있고 무슨 일이든 할 수 있는 사람이 더 필요했습니다.

뛰어난 제너럴리스트인지 어떻게 확인할 수 있을까요? 이상적으로 그들은 이미 계산, 품질, 이질성에 대한 기술들을 테스트 할 정도로 충분히 거대한 데이터 셋을 가지고 일해온 사람들입니다. 학업이나 직장 내 훈련을 통해서 STEM에 대한 지식을 가지고 있는 사람은 좋은 지원자가 될 수 있습니다. 그리고 어떻게 툴을 사용하는지 배우고 그것을 적절하게 사용할 수 있는 능력과 의지를 보여주는 사람도 확실히 제 주의를 끌 것입니다. 나는 제너럴리스트들을 평가할 때 그들의 다양한 관심사를 보여줄 수 있는 프로젝트를 보여달라고 요청합니다.

나중 단계

제품이 발전할수록 제너럴리스트들은 한계에 부딪치게 됩니다. 그들은 데이터 제품의 초기 버전을 개발하는 데에 열중하기만 할 뿐 그것을 어떻게 발전시켜야 하는지는 관심이 없습니다. 반대로 머신 러닝 스페셜리스트들은 비효율적인 알고리즘을 좀더 나은 방법으로 변경하고 계속해서 시스템들을 튜닝합니다. 기업이 성장하는 단계에서 스페셜리스트들은 기존 시스템들에 추가적인 부분을 도출하는 데에 도움이 됩니다. 만약 당신이 Google이나 Amazon에 있다면 이러한 점진적인 개선들은 놀라운 가치로 나타나게 될 것입니다.

비슷하게 동시에 수천 개의 실험들이 진행되고 상호작용과 새로운 것에 대한 영향, 속성에 대해 걱정이 될 때 직원들이 통계적인 전문지식을 갖고 있는 것은 중요합니다. 이것들은 제1세계 문제이지만, 그들이 정확히 시니어 통계학자를 요구하는 그런 종류의 문제입니다.

뛰어난 스페셜리스트인지 어떻게 확인할 수 있을까요? 머신 러닝이나 실험과 같은 특정 분야에 깊이 있는 경험을 가지고 있는 사람을 찾아야 합니다. 모든 스페셜리스트들은 학위를 가져야만 하는 것은 아니지만 관련 분야에 대한 학력은 전문성에 대한 신뢰할만한 자료이고 그 또는 그녀가 전문분야에 헌신했다는 의미입니다. 간행물과 프리젠테이션도 도움이 됩니다. 제너럴리스트의 영역에서 스페셜리스트를 평가할 때에 그들이 나를 겸손해지게 만들고 무언가 새로운 것을 가르쳐 주기를 원하게 됩니다.

결론

물론 이상적인 데이터 사이언티스트는 팀의 부족한 부분을 보완할 수 있도록 특별한 전문성을 가지고 있는 뛰어난 제너럴 리스트 입니다. 그러나 이상은 유니콘 또는 유니콘의 뿔과 같습니다. 만약 당신이 운 좋게 이러한 희귀 동물들을 찾는다 할지라도 그들이 모든 능력을 발휘할 가능성이 없을 것 같은 일일 지라도 몰두 할 수 있도록 몸부림 칠 것입니다.

자, 이제 제너럴리스트와 스페셜리스트 중 누구를 고용하시겠습니까? 이건 정말로 의존적이긴 하지만 당신의 결정의 큰 요인은 성숙에 대한 회사의 수준이어야만 합니다. 만약 당신이 여전히 확신할 수 없다고 회사가 여전히 빠른 성장 단계에 있다면 제너럴리스트를 선택하는 것이 좋습니다. 당신의 문제들은 아마도 당신이 생각한것 만큼 깊은 수준이 아닐 것입니다. 그래서 제너럴리스트를 고용하는 것이 당신의 부담을 줄여줄 수 있습니다. 더 나아가 제너럴리스트들에게 높은 수준의 스킬을 배울 수 있는 기회를 준다면 모두가 윈윈 할 수 있을 것입니다.

728x90
반응형
반응형

간신히 마친 번역



원문 : 3 easy reasons why you’ll move your business to the cloud


http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7356601744


클라우드 네이티브 애플리케이션 아키택쳐로의 변화는 혁신으로 이어집니다.

클라우드 네이티브 애플리케이션 아키택쳐를 적용할 때 어떻게 클라우드가 혁신과 변화를 가능하게 하는지 회사가 고려해야 할 부분과 클라우드 네이티브 애플리케이션 아키택쳐로의 변화가 가지고 있는 기본적인 동기들을 살펴봅시다.

 

속도(Speed)

속도가 시장에서 중요한 성공 요인이라는 것은 분명합니다. 소프트웨어 기반의 솔루션들을 개발하고 제공하는 사업들은 경쟁자들보다 빠르게 기존의 딜리버리 모델들을 습득해야 합니다.

엔터프라이즈 환경에서 새로운 애플리케이션 환경을 제공하고 새로운 버전의 소프트웨어를 반영하는데 걸리는 시간은 기본적으로 일, 주, 또는 월 단위로 측정됩니다. 신속성의 부족은 특정 릴리즈에 의해 발생할 수 있는 위험을 엄격하게 제한합니다. 왜냐하면 오류를 만들어내고 수정하는 비용 또한 동일한 시간 단위로 측정되기 때문입니다.

인터넷 기업들은 종종 하루에 수 백 번씩 배포를 하는 작업에 대해 표창을 하기도 합니다. 왜 빈번한 배포가 중요한 걸까요? 만약 당신이 하루에도 수 백 번 배포가 가능하다면 거의 즉시 오류들을 처리할 수 있을 것입니다. 그리고 당신이 즉시 오류를 처리할 수 있다면 더 많은 위험을 떠맡게 될 것입니다. 그리고 더 많은 위험을 떠맡게 된다면 결과적으로 당신은 다른 경쟁자들 보다 우위에 설수 있게 됩니다.

탄력성과 셀프서비스를 갖춘 클라우드 기반의 인프라는 자연스럽게 이런 작업에 적합합니다. 클라우드 서비스 API를 호출해서 새로운 애플리케이션 환경을 제공하는 것이 수많은 절차를 거쳐서 진행되는 양식 기반의 방식보다 빠릅니다. 다른 API를 호출해서 새로운 환경에 코드를 반영할 때에는 속도가 더 빠릅니다. 팀에 있는 통합 빌드 서버 환경에 셀프서비스와 후크를 추가하게 되면 속도는 더 향상될 것입니다. 결과적으로 우리는 Lean 그루인 Mary Poppendick이 말한 “당신의 조직은 단 한 줄의 변경된 코드를 반영하는데 얼마나 시간이 걸립니까?” 라는 질문의 답을 몇 분 또는 몇 초 안에 측정할 수 있습니다.

당신이 그렇게 빠르게 처리 할 수 있다면 당신의 팀이, 당신의 비즈니스가 무엇을 할 수 있을지 상상해 보십시오.

보안(Safety)

단지 빠른 것만으로는 충분하지 않습니다. 만약 당신이 차를 타고 건물을 향해 패달을 밟는다면 치명적인 사고를 당하게 될 것입니다. 항공기나 특급 고속열차 같은 운송수단은 빠르고 안전하게 만들어졌습니다. 클라우드 네이티브 애플리케이션 아키택쳐는 내구성, 유효성, 안전성에 대한 요구에 빠르게 대응할 수 있도록 균형을 유지해 줍니다. 따라서 속도와 보안은 갖추는 것은 기본이고 필수입니다.

우리가 앞에서 언급했듯이 클라우드 네이티브 애플리케이션 아키택쳐는 오류를 빠르게 복구하는 것을 가능하게 해줍니다.

우리는 지금 엔터프라이즈 환경에서 프로세스 엔지니어링에 많은 시간을 투자해서 오류를 예방해야 한다는 이야기를 하고 있는 것이 아닙니다. 화려한 디자인, 철저한 문서, 아키텍처 리뷰보드, 긴 회귀 테스트 사이클은 우리가 추구하는 속도에 역행을 하고 있습니다. 물론 이런 관행들은 좋은 의도에서 만들어졌던 것들입니다. 하지만 안타깝게도 그 중 어느 하나도 수많은 결함을 제품으로 만드는 데에 꾸준하게 주목할만한 향상을 보여주지 못했습니다.

그렇다면 우리는 어떻게 빠르고 안전하게 할 수 있을까요?

가시성(Visibility)

우리의 아키텍처는 장애가 발생했을 때 확인하기 위해 필요한 툴을 제공해야만 합니다. 우리는 모든 것을 측정할 수 있어야 하고 “정상적인 것이 무엇인지”에 대해 설명을 할 수 있어야 합니다. (절대값과 변화율을 포함한) 일반적인 상태와의 편차를 찾아내고 원인에 대해 알아낼 수 있어야 합니다. 다양한 통계, 모니터링, 경고, 데이터 시각화 프레임워크와 툴들은 모든 클라우드 네이티브 애플리케이션 아키택쳐의 핵심입니다.

장애 고립(Fault isolation)

장애와 연관된 위험을 줄이기 위해 위해 장애로 인해서 영향을 받을 수 있는 컴포넌트, 또는 기능들의 범위를 제한하는 것이 필요합니다. 만약 실시간 추천 엔진에 문제가 발생해서 Amazon.com에서 물건을 구매할 수 없다면 큰 재앙일 것입니다. 모놀리틱 애플리케이션 아키텍처는 이런 장애 모드에 대한 유형을 가지고 있습니다. 클라우드 네이티브 애플리케이션 아키택쳐는 종종 마이크로 서비스를 사용합니다. 마이크로 서비스로 구성된 시스템들 중에서도 오직 장애 허용 능력을 가지고 있는 마이크로 서비스만이 장애에 대한 범위를 제한할 수 있습니다.

장애 허용능력(Fault tolerance)

시스템을 독립적으로 반영할 수 있는 컴포넌트로 분해하는 것은 적합하지 않습니다. 그리고 우리는 컴포넌트들 중 한곳에서 발생한 장애가 의존관계를 통해 장애를 야기시키는 것을 막아야만 합니다. Mike Nygard는 그의 저서인 “Release It”(Progmatic Programmers) 에서 몇 가지의 장애 허용 패턴들에 대해서 언급하면서 가장 많이 사용되는 것은 서킷 브레이커라고 했습니다. 소프트웨어에서 서킷 브레이커는 전자기기에서 사용되는 서킷브레이커와 매우 유사하게 동작을 합니다. 서킷브레이커가 보호하고 있는 컴포넌트와 그 이외에 오류가 발생한 시스템 사이에 서킷을 오픈 함으로써 오류가 전이되는 것을 방지합니다. 또 서킷이 오픈되어 있는 동안 제품에서 기본적으로 제공되는 기본 셋 같은 폴백도 제공합니다.

자동 복구(Automated recovery)

가시성, 장애고립, 장애 허용능력과 같이 우리는 식별 및 복구 과정에 참여하는 동안 오류를 식별, 복구하고 우리의 고객들에게 적절한 레벨의 서비스를 제공하는데 필요한 툴을 가지고 있습니다. 발생할 때마다 쉽게 발견할 수 있는 패턴을 보여주는 오류들은 식별하기 쉽습니다. 예를 들어 헬스 체크 서비스는 건강한지 아닌지, 상태가 좋은지 나쁜지에 대해 2진법으로 응답을 합니다.

이런 종류의 오류가 매번 발생할 때마다 우리는 같은 행동을 반복할 것입니다. 헬스 체크에 오류가 생겼을 경우, 우리는 단순히 서비스를 다시 시작하거나 다시 배포할 것입니다. 클라우드 네이티브 애플리케이션 아키택쳐는 이런 상황에서 수동으로 개입하는 것을 기다리지 않습니다. 대신 감지 및 복구를 자동화해서 사용합니다. 다시 말해 사람대신 컴퓨터가 호출기를 착용한 것과 마찬가지입니다.

크기(Scale)

요구사항이 많아짐에 따라 요구사항에 대한 서비스를 제공하기 위한 우리의 능력도 조정을 해야만 합니다. 과거에 우리는 더 큰 용량의 서버를 구매하는 방법으로 수직적으로 크기를 확장해서 요구사항을 만족시켰습니다. 결국 목표는 이루긴 했지만 점점 많은 비용을 지불해야만 했습니다. 이것은 용량에 대한 사용이 최대 사용 시점을 기준으로 계획이 되었기 때문에 발생한 문제입니다. 우리는 “이 서비스가 필요한 가장 적절한 용량은 어느 정도인가?” 라는 의문을 갖고 그에 맞는 충분한 하드웨어를 구매합니다. 하지만 대부분의 경우 우리는 이 예측이 잘못되었다는 것을 깨닫게 되고 블랙프라이데이 같은 이벤트 기간 동안에 여전히 허용량을 초과하게 됩니다. 또한 더 빈번하게 유휴상태의 CPU를 가지고 수십, 수백대의 서버를 보게 되고 비효율적인 결과를 초래하게 될 것입니다.

혁신을 선도하는 기업들은 두 가지 방법으로 이 문제를 해결하고 있습니다.

  • 대용량 서버를 구매하여 숫자를 늘리는 것보다 다수의 장비를 이용해서 수평적으로 애플리케이션 인스턴스의 크기를 조정한다. 이 장비들은 취득(또는 조립), 그리고 빠르게 배포하는 것이 보다 쉽다.

  • 대용량 서버들이 가지고 있는 비효율성은 같은 공간에 여러 개의 작은 서버들을 가상화하고 여러 개의 고립된 워크로드를 배포하여 개선한다.

Amazon Web Service 같은 일반적인 클라우드 환경이 가능해지면서 이런 두 가지 움직임은 수렴되었습니다. 가상화에 대한 노력은 클라우드 제공자에게로 위임되었고, 소비자들은 수많은 클라우드 서버 인스턴스에 걸쳐있는 그들의 애플리케이션들을 수평적으로 확장하는데 초점을 맞추고 있습니다. 최근 또 다른 변화는 응용 프로그램 배포 단위가 가상서버에서 컨테이너 단위로 변하고 있습니다.

더 많은 혁신을 위해 클라우드 환경이 보여준 변화는 더 이상 기업들은 그들의 소프트웨어를 배포하기 위해 수많은 초기자본이 필요하지 않게 되었습니다. 또한 더 적은 투자로도 지속적으로 유지를 할 수 있게 되었고, API를 통한 공급은 최초 배포 속도를 향상시켜줄 뿐만 아니라 수요의 변화에 대한 대답을 최대한 빨리 할 수 있게 되었습니다.

안타깝게도 이런 모든 혜택들은 비용이 필요합니다. 애플리케이션들은 수직적 크기 보다는 수평적으로 다르게 설계되어야만 합니다. 클라우드의 탄력성은 짧은 수명을 요구합니다. 뿐만 아니라 새로운 애플리케이션 인스턴스를 빠르게 생성할 수 있어야 하며 빠르고 안전하게 그것들을 폐기할 수 있어야 합니다.

이런 필요는 어떻게 지속적으로 처분할 수 있게 상호작용을 해야 하는지라는 상태관리에 의문을 가지게 됩니다. 매우 수직적인 아키텍쳐에 해당하는 세션을 클러스터링 하거나 파일 시스템을 공유하는 고전적인 방법은 스케일링을 제대로 수행할 수 없습니다.

클라우드 네이티브 애플리케이션 아키택쳐의 또 다른 특징은 애플리케이션 인스턴스를 기본적으로 상태없이 유지하는 동안 인-메모리데이터 그리드, 캐쉬, 영구적인 객체 저장에 대한 외부화 입니다. 상태 없는 애플리케이션은 빨리 생성할 수 있고 없앨 수 있습니다. 마찬가지로 요구사항 변화에 대한 응답에 대한 능력을 향상시킬 수 있도록 외부의 상태 매니저에 붙이거나 떼어낼 수 있습니다. 

물론 이건 스스로 확장할 수 있는 외부 상태 관리자가 필요합니다. 대부분의 클라우드 인프라를 제공자들은 이 부분의 필요성을 알고 있으며 이런 서비스들을 제공하고 있습니다.

728x90
반응형
반응형

이번에도 겨우겨우 마친 번역작업....

하아.. 퀄리티는 어찌할거니.. ㅠㅠ


원문 : 4 Steps to a culture of performance 


http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS3666867495



전략적인 자원 사용과 할당, 최대화를 위한 가이드 라인 

구글 처럼 웹 성능에 의해 구동되는 기업들은 성능에 관심을 갖고 있는 CEO 덕분에 톱다운(top-down) 방식으로 성능의 문화를 개발한다. 그러나 대부분의 기업들은 이러한 방식을 사용하지 않는다. 종종, 회사가 전반적으로 성능에 초점을 맞춘 사업가치를 가지고 있는 기업임을 알리고, 프로세스와 인프라를 실제로 변경하고 성능 중심의 문화를 유지하려고 이해 관계자들을 설득시키기 위해 매일 성능을 모니터링 하는 것은 일하는 사람들의 몫이다. 

단계 1 : 사례를 만들어라 

당신이 성능에 대한 문화를 정착시키기 전에 먼저 동료나 상사들에게 웹 성능의 장점을 보여줄 필요가 있다. 이를 위해 사람들과 연관이 있는 비즈니스 표준을 기반으로 웹 성능과 수익 간의 명확한 연관성을 보여주는 사례를 만들어야 한다. 당신의 사이트가 몇 시간 또는 몇 분이라도 다운 되었을 경우 얼마나 수익에 영향을 미치는지 측정해봐야 한다. IT 인력들이 문제가 발생했을 때 해결하는데 얼마나 시간이 필요한지 알아봐야 한다. 그리고 당신의 경쟁사의 웹 성능과 비교해봐야 한다(그들보다 더 좋다면 잘 유지 시켜야 하고 그렇지 않다면 약점을 극복할 수 있는 기회로 만들어야 한다).

당신의 의견을 납득시킬 수 있도록 언제 어디서든지 가능한 자료를 제공해야 한다. 당신의 기업이나 또는 다른 사람들 중에서 성능과 관련 있는 성공적인 사례에 대한 예를 제공해야 한다. 당신의 사이트의 현재 로드 타임을 없애는 것이 얼마나 수익을 증가시키고 고객들의 충성도를 향상시킬 수 있는지 증명해야 한다. 성능에 대한 우선 순위를 결정할 수 있는 고객과 이야기를 하고 성능이 그들의 결과에 어떤 영향을 줄 수 있는지 찾아내야 한다. 

단계 2 : 벤치마킹을 작성하라 

당신이 비즈니스에 영향을 주는 아이디어를 한 번 판다면 그 영향을 측정하는 것도 중요하다. 이렇게 하려면 벤치마크를 작성하면 성능이 얼마나 향상되었는지 측정할 수 있고 모니터 할 수 있는 당신의 투자수익을 보장할 수 있다. 

단계 3 : 목표를 전달하고 다시 알려라 

우선순위로 성능 모니터링을 구축함으로써 당신은 사이트의 향상된 속도, 신뢰도 그리고 수립된 벤치마크를 이용해서 유효성을 추적할 수 있다. 또 이런 성공적인 상황을 팀 동료와 상사에게 전달하는 것도 필수적이다. 진행 상황을 보여줌으로써 당신의 주변사람들을 기운나게 하고 더 나은 최적화 전략을 찾도록 촉구할 수 있다. 

단계 4 : 성능에 대한 태도를 서서히 주입시켜라 

사이트의 성능을 향상시키는 것은 훌륭하고 좋은 일이다. 그러나 당신이 완료라고 말할 수 있는 시간은 절대 오지 않는다. 성능은 여행이지 목적지가 아니라는 것을 기억해라. 향상을 위한 여지는 항상 존재할 것이다. 

즉, 하나의 단일한 프로젝트를 완료하는 것보다 성능에 대한 문화를 확산시키는 것이 중요하다. 당신의 팀은 성능을 지속적으로 측정해야 하고 목표를 수정하고 향상시키기 위한 더 많은 영역을 찾아야 한다. 

또한 온라인 환경의 변화에 대해 철저한 조사가 지속적으로 필요하다. 새로운 변화가 사이트의 로딩 시간에 영향을 주는가? 새로운 마케팅 기술이 사이트에 위험을 초래하는가? 장소의 변화에 대응하여 효과적으로 확장할 수 있는가? 

성능에 대한 인식을 갖도록 하는 것이 중요하다. 앞에서 말한 질문들은 의사결정 절차의 한 부분이 될 것이다. 그리고 이런 일들이 일어나서 뒤로 돌아가 바로잡기 보다는 그전에 당신과 당신의 팀원들이 가능한 문제들을 예측할 수 있도록 도와줄 것이다. 

성능에 관한 문화는 비싼 인프라의 투자를 의미하는 것이 아니다. 오히려 성능 문화는 기업이 그들의 자원들을 더 효과적이고 전략적으로 극대화 하고, 할당해서 영향력을 발휘할 수 있도록 도와줄 것이다. 그러나 무엇보다 중요한 점은 최종 사용자 경험에 대한 변함없는 관심이다. 최종 사용자 경험에 대한 잠재적인 영향은 모든 웹사이트와 관련된 결정과 제안된 변경사항들 안에서 가장 먼저 생각해야 할 부분입니다. 

성능문화를 만들고 유지하는 것은 시간과 노력이 필요하다. 그러나 충분히 해볼만한 가치가 있다.

728x90
반응형
반응형

양도 많지 않았는데.. 너무 오래 걸려버렸다.

한 2달 반 넘게 걸린듯... 그래서 이번 전반기에는 이거 하나밖에 못하겠네.. 


원문 : The reason everyone should learn to code 


http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS2204135551



우리는 왜 모든 사람들이 코드를 배우기를 원하는 것일까요? 이건 분명히 코더를 양산하겠다는 의미가 아닙니다. 저 또한 모든 사람이 코드를 배울 것이라는 망상도 없습니다. 이런 일은 일어나지도 않을뿐더러 일어나서도 안됩니다. 

그러나 슬로건이 말하고 있는 근본적인 근거는 슬로건 자체가 아니라 슬로건이 가능하냐 입니다. 나는 Bloomberg 시장이 Python을 배웠는지 안 배웠는지에 전혀 관심이 없습니다. 단지 그의 새로운 경력에 도움이 되기를 바랄 뿐입니다. 그러나 그가 프로그래밍 기술에 상관 없이 그의 일을 잘 해낼 거라 생각합니다. 내가 좀더 관심을 갖는 것은 "모든 사람이 코딩을 해야합니다"라는 슬로건에서 직접 파생된 Black Girls Code 같은 단체입니다. 

단지 흑인 소녀들이어서 일까요? 그 점에 있어서는 흑인 소년들도 마찬가지 입니다. 왜냐하면 정확한 기사의 초점은 가난, 빈곤은 상속된다는 점이기 때문입니다. 만약 당신이 도심의 학교에 다니는 가난한 흑인 소년이라면 당신의 경력은 맥도널드나 월마트 같은 최저 임금을 주는 곳 밖에 없을 것입니다. 

코드를 배우는 것은 가난의 굴레를 깨버릴 몇 안 되는 방법 중의 하나입니다. 80년대 초에 흑인 친구 한 명이 “프로그래밍에 대한 정규 교육 없이 소프트웨어를 개발하러 가는 마지막 세대라서 슬프다”라고 말한 적이 있습니다. 그러나 그것은 틀린 말이었습니다(그는 Stanford를 졸업했지만 CS는 아니었습니다). 그 후 매년 그게 잘못된 것이라는게 입증되었습니다. 컴퓨터에 대한 정규교육이 관련 없는 것은 아니지만(이건 별게의 문제입니다) 이게 절대적으로 필요한 것도 아니고 당분간 실현되지도 않을 것입니다. 그리고 웹 상점, 사무실, 또는 어디서든지 간에 그들의 직업들은 맥도날드와 월마트의 최저 임금보다 훨씬 좋습니다. 

그리고 이것은 중요한 점입니다. 왜냐하면 대학을 나오지 않은 채로 가난의 고리를 끊을 수 있는 다른 좋은 방법이 없기 때문입니다. “법을 공부하는 흑인 소녀들”, “은행에서 일하는 흑인 소녀들” 과 같은 사례는 없습니다. 소프트웨어를 제외한 법률, 금융, 의학과 같은 모든 전문분야들은 진입하기 높은 장벽을 가지고 있고 대학 학위부터 시작을 해야 합니다. 그리고 다른 도시 아이들에게 대학은 불안정한 가치입니다. 4년동안 당신을 지원해줄 수 있는 재정지원패키지로 좋은 학교에 들어간다 하더라도 부모님이 일자리를 잃거나 병을 얻게 될 수도 있고 당신이 갑자기 직장을 그만둬야 할지도 모릅니다. 

코드를 배웠다 하더라도 확실히 가난은 기술경력에 많은 어려움을 줍니다. Anil Dash는 기업문화에서 성공을 하기 위해 소수자들이 배워야 하는 다른 코드들과 성공에 필요한 기업문화의 변화에 관련된 글을 썼습니다. Dash가 언급한 요점은 정말 중요합니다. 바로 코드를 배우는 것이 사회적 유동성에 무료 티켓을 제공하는 만병통치약이 아니다라는 점이죠. 

그러나 Dash의 문화적 기술에 대한 주장에도 불구하고 코드를 배우는 것이 도시나 시골의 빈민들 또는 3세계의 빈민들에게는 최고의 선택으로 여겨집니다. 나는 프로그래머들이 다른 영향을 받지 않고 그들의 특권을 가지고 있는 영역에 대한 걱정에 다소 즐겁습니다. 슬로건 이외에, 대부분의 사람들이 코드를 배우지 않을 것이라는 많은 이유 만큼이나 직업관련 기술로 코드를 배우는 것을 제외하는 많은 이유들이 있습니다. (문화적 지식도 이유 중 하나입니다.) 코더들이 많아서 일까요? 그것은 문제가 되지 않습니다. 피부색이나 백인 남자 프로그래머의 문화적 습관에 따라 공유하지 않는 코더들 때문일까요? 그런 사람들은 데려오십시오. 더 많은 사람들이 필요합니다. 

모든 사람들이 코드를 배우는 것이 코더를 양상한다는 의미가 아니라는 것이 요점입니다. 10살이 되는 동안 프로그래밍을 해보지 않은 사람들 중에 재능있는 사람을 찾으려는 것입니다. 코드 학습이 필요하거나 시작할 방법을 찾지 못한 사람들에게 교육을 제공하고 그들의 창의성을 활용하는 것입니다. 이것은 그들이 해결하기를 원하는 문제이기도 하며 현재 불쑥 나타난 신생기업보다 중요합니다. 나는 도심에 사는 아이들이 자바스크립트나 파이썬을 가르쳐줄 사람들 찾는 것보다 여름 농구 캠프를 보내기 위한 장학금을 받는게 더 쉽다는데 동의합니다. 우리는 그것을 고쳐야 하고 또 고칠 수 있습니다.

728x90
반응형
반응형

어렵게 어렵게 번역한 기사.... 내용은 어렵지 않았는데.. 점점 게을러져서.. 이번에도 기간이 딜레이 됐구나..


원문 : Not Your User’s Problem 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS4920798014



사용자 문제, 비즈니스 요구사항, 솔루션의 차이에 대한 이해가 필요합니다. 

 먼저, 제가 요즘 보고 있는 Customer Development, Early user Research, Product Market Fit에 중점을 두고 말하는 것임을 미리 알려드립니다. 이에 따른 제 의견에 혼란이 발생하는 것을 원치 않습니다. 

제가 명확히 하려고 노력했던, 또는 뭔가를 추가할 수 있었던 제품 개발 프로세스의 초기에 팀에서 본 특정 유형의 논란이 있습니다. 우리는 그것을 같이 보게 될 것입니다. 

일부 사람들은 비즈니스 요구사항과 사용자 문제, 그리고 솔루션의 차이를 이해하지 못하는 것 같습니다. 그러나 이것에 대한 이해가 분명히 필요합니다. 그렇지 않으면 잘못된 제품을 설계하거나 잘못된 연구를 수행하게 될 것입니다. 

비즈니스 요구사항 

아주 간단히, 비즈니스 요구사항은 회사가 그 제품에 바라는 것을 말합니다. 이것은 종종 변화가 필요한 형태나 큰 돈을 모을 수 있는 새로운 기능이나 제품을 어떻게 만들 것인가에 대한 가설로 표현됩니다. 

여기 비즈니스 요구사항에 대한 몇 가지 예가 있습니다.

  • 좀더 많은 사람들이 우리의 제품을 찾도록 방문페이지의 전환율 향상. 

  • 더 많은 위젯들의 판매에 의한 수익 향상 

  • 현재 사용자들이 우리 제품을 홍보함으로써 더 많은 사용자들이 등록하도록 유도. 

  • 사람들이 사용자가 될 가능성이 높기 때문에 우리제품에 대한 참여율을 향상시켜야 함. 

  • 수익을 창출할 수 있도록 거대한 사용자공간 기반을 구축

이들 비즈니스 요구사항들에 관련된 흥미로운 점은 무엇일까요? 아마도, 어떻게든 이 모든 것들이 정확하게 실행된다면 결국 우리의 수익이 늘어나거나 비용이 줄어들 것입니다. 우리는 성공할 수 있는 업무들을 가지고 이러한 일들을 할 필요가 있습니다. 그러나 이것들을 수행하는 여러 가지 방법들은 사용자에게 유용한 것도 있고 그렇지 않은 것들도 있습니다. 

업무상 필요를 정의하기 위해서는 기본적으로 양적인 데이터가 있어야 합니다. 그리고 당신의 지표들을 수행하기 위해 어떤 것들이 우선순위를 갖는지 알 필요가 있습니다. 당신은 사용자들과 대화를 통해서는 비즈니스 요구사항을 알아낼 수 없습니다. 

분명하게 비즈니스 요구사항들은 사용자 문제로부터 발생됩니다. 예를 들어 당신의 보딩 프로세스가 사용하기 어렵다면 전환율은 낮을 것입니다. 그러나 비즈니스 요구사항이 전환율을 높이는 거라면 당신은 여러 가지 방법을 모색해 봐야 할 것입니다. 

사용자 문제 

당신의 사용자들은 문제들을 가지고 있습니다. 어떤 문제들은 해결하기 위해서 돈을 지불해야 하기도 하고 어떤 문제들은 정말 끔찍한 UX 때문에 발생하기도 합니다. 어떤 문제들은 심지어 문제를 갖고 있는지 조차 모르기도 합니다.

  • 여기 사용자 문제의 몇 가지 예가 있습니다. 

  • 다른 컴퓨터들 간에 문서를 공유가 어려움 

  • 특정 제품에 첫인상이 복잡하고 혼란스러움. 

  • 인터넷이 연결되어 있지 않으면 앱을 사용할 수 없음. 

  • 어떤 분이 집 주변에 좋은 미용실을 찾아서 예약하는데 문제가 있다고 함.

당신은 이 사용자 문제들이 모두 조금씩 다르다는 것에 주목할 것입니다. 첫번째 문제는 DropBox같은 회사들에게서 영향을 받았을 것입니다. 두번째 문제는 많은 제품에서 발생하는 흔한 문제입니다. 세번째는 모바일에 한해서 해당하는 문제입니다. 네번째는 여러 가지 다른 종류의 제품에 의해서 해결되어 왔고 일부는 간단한 기술로 해결되어 왔습니다. 발생할 수 있는 사용자 문제들은 수없이 많습니다. 

여기에서 공통점은 이 문제점들이 인간에 의해서 발생한다는 점입니다. 다른 공통된 요인은 실제로 비즈니스 요구사항을 실현하기 위한 사용자 문제를 해결하는 것은 보수가 없다는 점입니다. 물론 사람들을 위해 문제를 해결하는 것은 일반적으로 좋은 일이지만 문제를 해결하기 위해 돈을 지불해야 하는 문제들이 있고 그렇지 않은 것들이 있습니다.

사용자 문제를 정의하기 위해 가장 좋은 방법은 관찰하고 난 후 만들어지는 리서치입니다. 당신의 제품이나 다른 제품을 사용하는 야생의 사람들을 살펴보십시오. 그들이 다양한 작업을 수행하거나 일을 하는 모습을 지켜보십시오. 그것들이 사람들의 생활을 힘들게 만든다는 것을 이해해야 합니다. 그렇게 된다면 당신이 그들을 위해 해결할 수 있는 크고 중요한 문제점들이 보이게 될 것입니다. 

솔루션 

솔루션은 이름에서 의미하듯이 어떻게 문제를 해결하느냐에 대한 것이다. 이상적으로 당신의 솔루션은 비즈니스 요구사항을 수정하게 될 사용자 문제를 해결할 것입니다. 

여기 솔루션에 대한 몇 가지 예가 있습니다.

  • 당신과 학교 친구들을 모두 연결해주는 네트워크 . 

  • 사용자가 데이터를 입력하는데 도와주는 향상되고 능률적인 온보딩 절차. 

  • 복잡한 프로세스에 대한 동영상 튜토리얼.

문제들과 마찬가지로, 실제로 솔루션은 많습니다. 사실 사용자 문제들은 거의 대부분 수많은 솔루션을 가지고 있습니다. 이러한 솔루션들 중 일부는 다른 사람들보다 쉽게 구현할 수 있을 것입니다. 또 다른 사람들보다 더 좋은 방법으로 해결할 수도 있습니다. 단 하나의 정확한 솔루션이 있는 것이 아니라 다른 사람들보다 더 나은 솔루션이 존재하는 것입니다. 

솔루션을 정의하기 위해서는, 해결하려고 하는 문제에 대한 이해가 필요합니다. 그리고 기본 설계 원칙에 대한 적절한 이해와 당신의 비즈니스를 향상시킬 수 있는지에 대해서도 알아야 합니다. 이건 당신이 아이디어를 만들어내고 공유할 수 있는 프로세스의 일부분입니다. 

리서치는 문제에 대한 정확한 솔루션을 알려주지 않습니다. 당신이 원하는 만큼의 사용자들에게 그들이 경험한 문제들을 어떻게 해결하는지 물어볼 수 없습니다. 만약 그들이 해결 방법을 안다면 당신은 필요없는 존재가 될 것입니다. 리서치가 알려줘야 하는 것은 문제에 대한 더 나은 통찰력을 주는 것입니다. 

왜 걱정을 하나요? 

당신은 비즈니스 문제를 해결해야 하는지, 사용자 문제를 이해해야 하는지, 또는 해결책을 찾아내야 하는지에 따라 전혀 다른 일들을 할 필요가 있습니다. 

예를 들어, 만약 낮은 전환율 같은 비즈니스 요구를 해결하기 원한다면, 비율이 낮은 이유를 찾기 위해 사용성 테스트를 할 것입니다. 반면에 중요한 사용자 문제를 찾길 원한다면 특정 시장에 대한 사람들을 관찰하고 상황에 맞은 연구를 할 것입니다. 그리고 물론 솔루션을 만들기 위해서는 비즈니스와 사용자 문제에 대한 탄탄한 이해뿐만 아니라 확실한 설계에 대한 사고방식도 필요합니다. 

사용자 리서치를 시작하기 전에 몇 분동안 비즈니스 요구사항, 사용자 문제, 솔루션 제안에 대해 더 알려고 노력했는지 스스로에게 물어보기 바랍니다.

728x90
반응형
반응형


원문 : Ebooks and the future of research 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS1548255504


번역한지 꽤나 됐는데. 이제올라왔네 ^^


 과거를 알지 못하면 지식은 발전할 수 없다. 지식을 추구하는 사람은 지난 세대가 경험했던 일들을 참고해야만 한다. 문학가들은 책으로, 음악가들은 악보로, 예술가들은 박물관에 있는 유물로, 각각 그들의 업적을 남겨놓았다. 

참고 자료들의 지속적인 효용성은 우리의 전체적인 연구 시스템을 뒷받침 해준다. 그것은 우리들이 간신히 유지하기 위한 가치 목록을 등록하는 방법에 뿌리깊게 자리잡게 되었다. 그 효용성은 신기루처럼 사라질지 모르지만, 놀랍게도 조금씩 효과가 나타나고 있다. 

출판의 지속성은 출판한 책의 양과 권위 있는 버전에서 갖고 있는 편의성에 의해서 결정된다. 어떤 연구가도 정당하게 얻을 수 없거나 존재 자체가 무시되는 책을 참고하지는 않을 것이다. 

eBook들의 성공은 우리가 ebook 유통에 대한 잘못된 인식 때문에 매력적으로 보일지 모른다. 하지만 대부분의 상업적인 플랫폼들은 마음대로 수정하고 삭제할 수 있는 유일한 원본을 의미한다. 킨들과 아이패드에서 사용하는 수많은 ebook들이 있지만 실제로는 애플과 아마존이 가지고 있는 책은 2권 뿐이다. 

Amazon에서 판매하던 조지오웰의 "1984"는 기록을 쉽게 삭제할 수 있다는 것을 입증하였다. 검열의 위험에 대해 말하자면, Nook 사용자들은 최근에 전쟁과 평화(War and Peace)의 기괴한 버전을 접하게 되었다. 바로 kindled 이라는 단어 대신에 nooked로 바꼈던 것이다. 이렇게 너무나도 우스운 실수는 빨리 잊혀졌지만 더 위험한 편집이 쉽게 발생할 수 있다. 

Apple과 Amazon이 가장 수준 높은 학문의 표준을 지키고 있다고 할 지라도 이들의 플랫폼이 만들어진 형식들은 그들을 생존할 수 있도록 설계되지 않았다. 예측하건데 일반 텍스트 문서는 나중에 판독될 수 있다. 하지만 상표로 등록되어 암호화된 문서들은 어떨까? 미래에 연구가들이 암호를 해독을 위해 신경을 쓸까? 

역사적으로 도서관 제도는 개인적으로 사용된 수 백만권의 책들을 백업하기 위한 곳으로 여겨졌다. 이런 신뢰할만한 제도들은 모든 책들을 보호하는 데에 그 의미를 두고 있다. 그 시대의 사람들이 재미없어 하거나 어리석고 불필요하다고 생각했던 책들도 포함해서 말이다. 

그들은 지금 개개인의 연구들로부터 오랫동안 버려졌던 훌륭한 보관소를 가지고 있습니다. 가장 중요한 점은 이들 도서관들이 예측 불가능한 정치적 변화로부터 그들의 의무를 지키려 한다는 점이다. 

개인 독자들이 배포되고 인쇄되어 판매되는 책들을 멀리 하고 도서관들이 ebook의 "구매"를 대행한다면 지금 시대의 출판물들은 사라질 위험에 처하거나 점점 믿을 수 없게 될 것이다. 

나는 책들을 암호화하는 관행에 동의하지는 않지만 출판사들이 이러한 행동을 하는 이유는 이해한다. 그러나 사회는 광범위하게 퍼져있는 지식 자산을 잃어버려서는 안된다. 

나는 출판사들에게 정치적이고 상업적인 압력으로부터 책들을 보호할 수 있고, 세계적으로 컴퓨터 사용에 능한 기관들에게 그들이 디지털 형태로 발간한 모든 책들의 암호화되지 않은 원본들을 맡기라고 말하고 싶다. 

그렇게 되면 책들은 저작권이 없는 채로 온라인에 출판될 것이다. 그렇게 함으로써, 미래의 연구가들에게 오늘날을 참고할 수 있는 글들이 믿을 수 있고 증명할 수 있는 형태라는 확신을 심어줄 수 있을 것이다.


728x90
반응형
반응형

원문 : The future of programming 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7197890408


점점 더 번역을 할 수록 어렵다는것이 느껴진다.

의미는 이해가 가는데 말로 표현하고 글로 작성하는 부분이 여전히 부족한 점이 많다.

여러번 퇴고를 해야하는데.. 핑계삼아서 반복을 못한것도 하나의 원인인것 같다.


"누가 읽더래도 이해하기 쉽게 번역을 하자"!!

----------------------------------------------------------------------------------------------------------------------------------------------------------------------


프로그래밍은 변화하고 있습니다. PC의 시대가 끝나고 소프트웨어 개발자들의 시대가 오고 있습니다. 그들은 수많은 장비와 업무 기능들, 그리고 기종에 따라 다른 접근방법들이 필요한 문제점들을 해결하고 있습니다. 데이터가 증가하는 지금 시대에, 많은 종류의 프로그래밍을 할 수 있는 능력은 모든 분야에서 점점 중요하게 여겨지고 있습니다. 그리고 프로그래밍도 더 이상 엔지니어 영역이라는 인식도 사라지고 있습니다. 

 앞으로 몇 년에 걸쳐, 저는 프로그래밍이 변화해 가는 모습과 그것이 영향을 미치는 요인을 연구해 보려고 합니다. 그리고 이 기사는 그러한 몇 가지 영향력에 대해 다루고 있습니다. 이러한 변화에 대한 의견이나 같이 할 연구할 의사가 있다면 언제든지 알려주기 바랍니다. 

우선 무엇을 먼저 해야 할까요? 목표는 다가올 10년동안 프로그래머들이 필요한 필수적인 기술과 그들이 우선시 해야 할 교육, 그리고 단기간의 경향과 장기적 변화간의 차이에 대해 서술하는 데에 있습니다. 

분산 컴퓨팅 

오늘날에 "평범한" 환경에서 개발을 한다는 것은 10년전과는 의미가 달라졌습니다. 웹 애플리케이션이나 모바일 또는 빅 데이터와 같은 환경이 생기면서 프로그램이 오직 한대의 컴퓨터에서만 사용한다는 생각은 바뀌게 되었습니다. 

그렇게 되면서 프로그래머들은 동시성, 락, 비동기 네트워크 통신, 프로토콜과 같은 문제들을 처리 하게 되었습니다. 가장 기본적인 웹 프로그래밍을 할 때라도 캐싱과 같은 친근한 문제와 마주치게 될 것입니다. 

이러한 문제들과 관련해서 우리는 컴퓨팅 스택에 있는 단계별 현상들을 볼 수 있습니다. 

상위 단계인 클라우드 컴퓨팅은 다양한 기계와 네트워크를 유지하는데 발생하는 번거로운 상황을 줄이기 위한 방법을 찾고 있습니다. 애플리케이션 개발 단계에서는 익숙한 패턴을 사용하여 프레임워크를 구현하고 복잡한 세부 내용들을 추상화하고 있습니다. 그리고 개발 언어 단계에서는 Go나 Scala 같은 언어가 제공하는 기능에 의해 동시성이나 네트워크 컴퓨팅이 좀더 간단해 지고 있습니다. 

디바이스 컴퓨팅 

주위를 둘러보면 당신이 가지고 있는 모든 전자 제품에는 프로세서와 프로그램을 가지고 있습니다. 그리고 당신의 컴퓨터 또한 그 중에 하나입니다. 모든 사람들이 제품에 내장된 프로그램에 관심을 갖지는 않지만 많은 개발자들은 분명히 모바일 폰으로 개발하기 위한 방법이 무엇인지 배워야 합니다. 가까운 미래에 자동차나 무인항공기안경스마트 더스트에 적용시켜야 할 수도 있습니다. 

심지어 기존의 컴퓨터 사용에서도 다양한 고급 데이터를 고속으로 처리하는 보조 프로세서로 GPU 수가 늘어나게 되면서 기존과 다른 프로그래밍이 필요해졌습니다. 다른 형태의 요인들은 다른 방법의 프로그래밍 접근을 요구하게 되었고 Hobbyist와 prototype들은 비슷하게 Arduino와 Processing이라는 하드웨어를 도입하게 되었습니다. 그리고 프로그래밍 언어들과 프로그래머들은 메모리의 부족, CPU 속도, 파워 소비, 주파수 통신, 실시간 처리 등과 같은 특별한 분야의 이슈들에 대해 미리미리 대응 해야만 했습니다. 

데이터 컴퓨팅 

오늘날 많이 사용하는 객체 지향 프로그래밍은 일반적으로 데이터에 적대적입니다. 이 방법은 접근하는 메소드를 통해 데이터를 감싸는 행위에 초점을 맞추고 있기 때문에 이전보다 데이터를 더 타이트하게 보호하게 됩니다. 수학적인 의미로 데이터는 행동이 없는 말 그대로 데이터에 불과하지만 C++이나 java와 같은 영역에서 개발자들은 데이터의 접근 방법에 대해 생각해야만 합니다. 

데이터와 데이터 분석의 중요성이 커짐에 따라 first class citizen 처럼 데이터를 처리하는 언어들의 인기와 사용이 증가하게 되었습니다. 그리고 분명히 R과 같은 통계적인 언어들도 이러한 흐름에 따라 사용이 증가하고 있습니다. 하지만 일반적으로 프로그래밍의 목적면에서 Python이나 Clojure가 데이터를 다루는데 더 쉽다는 의견이 대부분을 차지하고 있습니다. 

보편화된 컴퓨팅 

점점 많은 사람들이 프로그래밍을 하고 있습니다. 이 영리하고 수많은, 돌발적인 개발자들은 엑셀 매크로의 마법과 같은 기능과 자바스크립트 기술, IFTTT 또는 Zapier와 같은 웹 서비스를 지원하는 것들에 골머리를 앓고 있습니다. 그들은 소프트웨어 개발에 대해 약간 알고 있긴 하지만 그 이상 관심을 갖고 있지는 않기 때문이죠. 

이렇게 무심한 프로그래머들은 쉽게 문제들을 발생시키고 오랫동안 이런 문제들이 해결될 때까지 곤경에 빠지게 됩니다. 아무리 낙관적으로 생각해도 이건 짜증스럽고, 최악의 경우에는 고용주에게 책임을 묻는 경우도 발생하게 됩니다. 게다가 이건 프로그래머의 잘못도 아닙니다. 

프로그램이 작동 가능한 환경을 제공하는 사람들은 어떻게 더 나은 "돌발적인 개발자" 를 찾을 수 있을까요? 우리는 기존의 언어보다 새로운 개발 언어와 더 나은 프레임워크를 사용해야만 할까요? 이건 교육적인 문제인걸까요? 아니면 이건 문제가 아니라 단지 시기상의 문제일까요? 

Bre Victor"s work와 ScratchLight Table과 같은 프로젝트에서 다른 미래에 대한 힌트를 얻을 수 있습니다. 

위험한 컴퓨팅 

마침내, 우리가 소프트웨어 개발에 대한 지금의 접근 방법으로 만든 불안정한 계획을 시험해볼 가치가 있게 되었습니다. 두뇌가 오직 두뇌 안에서 풀 수 있는 문제들만 해결 할 수 있듯이 문제는 단순합니다. 오늘날 프로그래머가 되기 위해서는, 머릿속으로 생각해서 만든 프로그램을 실행시킬 수 있는 능력을 갖춰야 합니다. . 

만약 문제에 대한 영역이 점점 커지면 프레임워크를 사용해서 문제에 대한 영역을 줄이면 됩니다. 우리는 CPU 위에 운영체제를 설치하고 라이브러리들과 사용자 인터페이스들은 운영체제 위에서 실행합니다. 그리고 애플리케이션 프레임워크는 이들 라이브러리 위에서 실행되고, 웹 브라우저는 프레임워크 위에서 실행됩니다. 그리고 자바스크립트는 브라우저 위에서 실행되고 자바스크립트 라이브러리는 자바스크립트 위에서 실행됩니다. 여기에서 끝이 아닙니다. 

우리는 다른 쪽 위에 한 개의 찻잔을 쌓아 올리는 야심찬 웨이터와 같습니다. 바로 지금은 약간 흔들려 보일지도 모릅니다. 우리는 더 빠르고 강력한 CPU를 만든 것이 아니라 지난 10년전에 만들었던 같은 종류의 애플리케이션을 만들었을 뿐입니다. 그리고 결국 수많은 시스템들을 위험으로 몰아놓는 보안상 문제점을 프레임워크 상에 만들어 냈습니다. 

왜 우리는 컴퓨터를 사용하면서 불안한 문제점들을 만들고 프로그래머가 컴퓨터의 능력을 그들의 머리에서 활용할 수 있는 정도로만 국한시킬까요? 이런 소프트웨어의 관점을 바꿀 수 있는 방법이 있을까요? 

결론 

나는 미래의 프로그래밍을 연구하면서 이러한 트렌트를 지켜볼 것입니다. 만약 경험이나 관점을 가지고 있거나 다른 방법으로 연구를 하고 계신 분들이 있다면 의견을 듣고 싶습니다. 그리고 이 기사에 대한 의견을 남겨주면 감사하겠습니다.

728x90
반응형

+ Recent posts