'정보, 통신, 기술/읽은 것들'에 해당되는 글 9건

정보, 통신, 기술/읽은 것들

코딩 호러의 이야기, 그리고 한국 오픈소스 개발자들 이야기

 

코딩 호러의 이펙티브 프로그래밍

 

지은이: 제프 앳우드

옮긴이: 임백준

출판사: 위키북스

출판일: 2013-03-29

 

스택오버플러우 개발자로 유명한 제프 앳우드의 블로그에 있는 글을 책으로 정리했다.

제프 앳우드는 평범하지 않고, 괴상하며, 불친절하고, 타인의 마음엔 신경 쓰지 않는 전형적인 개발자스러움을 보여준다. 그러면서도 사용자의 이야기에 집중하라고 하고, 인간 관계가 중요하다고 하고, 인문학적인 소양을 키우기 원하며, 글 작성하는 방법을 익혀야 한다고 하는 등 한때 유행했던 자기개발서적류의 주장을 펼치는 복합적인 인물이다.

개발자들과 개발 조직에 생생한 느낌을 주는 글도 있고, 좀 시간이 지나서 이제는 식상해진 이야기도 있지만, 전체적으로 블로그 글에, 에세이식으로 편하게 가벼운 마음으로 읽어 보길 권한다.

 

* 프로그래머 8단계 : 죽은 프로그래머, 성공적인 프로그래머, 유명한 프로그래머, 일하는 프로그래머, 평균적인 프로그래머, 아마추어 프로그래머, 알려지지 않은 프로그래머, 나쁜 프로그래머

 

... 일하는, 평균적인, 알려지지 않은 까지... 단계가 너무 많잖아. 유명한 까지는 아니어도 평균 이상은 하고 싶은데 이래서는 평균 혹은 알려지지 않은 프로그래머에 만족해야 할 듯하다ㅡㅡ

 

* 그저 그런 그룹에게 좋은 아이디어를 제공하면 그들은 아이디어를 망쳐버릴 것이다. 하지만 훌륭한 그룹에게 그저 그런 아이디어를 제공하면 그들은 아이디어를 멋진 무엇으로 구현할 것이다. 혹은 그저 그런 아이디어를 밖으로 내던지고 뭔가 다른 것을 만들어 낼 것이다.

 

* 엘리베이터 테스트를 통과하기 위한 프로젝트 비전 모델 : (핵심 고객을) 위해, 누구 (필요성 혹은 기회에 대한 설명), (제품명)은 (제품 카테고리)에 속한다, 그것(핵심 이익, 구입해야 하는 설득력 있는 이유), (주요 경쟁 업체와) 다른 점, 우리의 제품(핵심적인 차이에 대한 설명)

 

* 우리는 어떤 방식으로 도움을 얻길 원하는가? 나는 동정을 받는 듯이 도움을 받을 마음이 없다. 어떤 이기적인 동기에 의해 도움을 받고 싶은 마음도 없다. 이러한 상황에서 도움을 주는 사람은 하나의 인간으로서 나에게 아무런 관심이 없기 때문이다. 내가 다른 사람이 나에게 가졌으면 하고 바라는 태도는 나를 사랑하는 것이다. 물론 로맨틱한 사랑을 말하는 것이 아니라, 다른 인간에 대한 보편적인 사랑을 의미하는 것이다.

 

* 썩은 사과의 효과가 놀랄 정도로 강력하다는 사실을 보여주는 사회학적 실험을 수행한 월 펠프스 교수. 썩은 사과를 포함한 그룹은 사람들이 서로 논쟁을 벌이고, 싸우고, 서로의 정보를 공유하지 않았으며, 의사소통의 양도 더 적었다. 더 나쁜 것은 다른 팀원들이 썩은 사과의 성격을 따라서 행동하기 시작했다는 점이다. ... 최악의 팀원을 살펴보는 것은 해당 팀이 어느 정도의 성적을 거둘 것인가에 대한 최고의 척도가 된다는 사실이다.

 

* 우리는 때로 AWS 안에 존재하는 네플릭스 소프트웨어 아키텍처를 우리의 람보 아키텍처라고 불렀다. DVD를 추천하는 시스템이 다운되며, 우리가 고객에게 제공하는 응답의 질은 낮아지겠지만 여전히 전체적인 서비스는 계속 응답한다. 우리의 엔지니어들이 AWS에서 구축한 첫 번째 시스템은 무질서한 원숭이Chaos Monkey라고 불리는 시스템이다. 무질서한 원숭이의 역할은 우리의 아키텍처 내에 존재하는 서비스 인스턴스를 무작위로 다운시키는 것이다.

 

* 사용성 테스트 : 한달에 한번 정도. 최대 3명이나 4명. 컴퓨터를 사용할 수 있는 사람이라면 아무나. 사용자 한 사람 당 45분에서 1시간 정도가 적당하다. 간결함을 유지하고, 범위를 작게 유지해라. 테스트는 사무실이나 회의실, 방해가 없는 방 아무 곳에서나 가능하다. 단지 어느 정도 참을성이 있고, 차분하며, 열정적이고, 남의 말을 잘 경청하는 사람이 좋다. 참여자가 테스트 과정동안 참조할 수 있는 짧은 스크립트를 준비하라. 결과의 해석은 같은 날 점심시간에 개발 팀과 다른 관심 있는 사람들에게 설명한다.

 

* 누군가를 몰래 정지시키는 방법 : 완전금지(드루팔 케이브), 느린금지, 에러금지(드루팔 미저리)

 

코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기

 

지은이: 제프 앳우드

옮긴이: 임백준

출판사: 위키북스

출판일: 2013-11-28

 

* 나는 마치 정신 나간 저장강박증 환자처럼 완료되지 않은 업무가 산처럼 쌓여가는 근본적인 원인을 착각한다. 저장강박증 환자는 언제나 물건을 보관할 장소가 부족한 것이 문제라고 느낀다. 사실은 물건을 '버리지 못하는 것'이 문제인데 말이다. 나는 나에게 주어진 하루 24시간이라는 시간이 너무 부족하다는 타임푸어 현상을 고민한다.

 

* 진정으로 더 나은 프로그래머가 되고 싶다면 프로그래밍 주변에 있는 다른 모든 것들에 열정을 쏟아야 한다.

 

* 그래서 어쩌면 우리는 어쩔 수 없이 아주 사소한 일에도 목숨을 걸 수밖에 없는 존재일 것이다.

 

* 그렇기 때문에 혹시라도 어느 프로그래머가 업계를 떠나는 것을 고려한다는 말을 농담이라도 입 밖에 낸다면 아마도 그는 업계를 떠나는 것이 여러 사람에게 도움이 되는 사람일 것이다. 그렇다고 해서 진로를 놓고 고민하는 사람에게 못되게 굴어도 좋다는 것은 아니다.

 

* 인터넷이 출현하기 이전의 초창기 컴퓨터 세계는 고독한 행위 그 자체였다. M.U.L.E의 저자인 대니 베리는 다음과 같은 유명한 인용구를 남겼다. "죽음을 맞이하면서 '세상에, 컴퓨터를 더 많이 이용했어야 했는데.'라고 말하는 사람은 없다." ... 프로그래밍을 진지하게 생각한다면 반드시 다른 동료와 함께 일하는 환경을 고집해야만 한다.

 

* 코드를 체크인하기 전에 동료가 코드를 간단하게나마 검토할 수 있게 하라. 코드의 내용을 설명할 수 있겠는가? 코드가 제대로 작성됐는가? 깜빡 잊은 것은 없는가?

 

* 웹 사이트의 첫 페이지가 어마어마하게 매력적이어야 한다는 사실이다. ... 어쩌면 사용자가 보는 것은 바로 그 첫 페이지에 국한될 수도 있기 때문이다.

- 페이지가 상당히 빠르게 로드돼야 한다.

- 애플리케이션이 해결하고 있는 문제가 무엇이고, 다른 사람들이 왜 그러한 문제에 신경을 써야 하는지 정확하게 설명하는 것이다. 첫 페이지에서는 일종의 엘리베이터 토크가 필요한 것이다.

- 구체적인 예를 제시한다.

- 장애물이 없는 명확한 동작이 가능하게 하라.

- 일부 사용자를 포기하는 것을 의미할지라도 자신에게 진짜로 의미 있는 사용자를 놓치지 않도록 노력하라.

 

* 그런 기능을 모두 더하는 것은 별로 아름답지 않습니다. 혁신이라는 것은 모든 것에 대해 '예'라고 대답하는 것이 아닙니다. 가장 결정적인 기능을 제외한 나머지 모두에 대해 '아니오'라고 대답하는 것이 혁신입니다.

 

* 유연성이 확장되는 것은 그들이 실수를 저지르거나 해서 검색이 실패할 확률을 낮춰주는 것이 아니라 오히려 높인다. 그들은 자신이 수행할 일을 더 단순하게 만들 수만 있다면 불필요한 복잡성, 통제, 그리고 동작 방식에 대한 이해를 기꺼이 포기할 준비가 돼 있다. ... 호모로지쿠스는 사물이 어떻게 동작하는가를 알고 싶어 하는 참을 수 없는 욕망을 느낀다. 이와 반대로 호모사피엔스는 성공을 위한 강력한 욕망을 느낀다. 프로그래머도 성공을 원하긴 하지만 그들은 이해라는 성취를 위해 실패라는 비용을 지불하는 것을 받아들인다.

 

* 사람들은 '오직 자기 엄마만 읽을' 블로그를 작성하는 사람을 조롱한다. 하지만 아무도 실행하지 않을 코드를 작성하는 수많은 프로그래머는 어떤가?

 

* 사용자들이 할 거라고 말하는 것과 그들이 실제로 하는 일은 완전히 다른 두 개의 존재다. 그렇기 때문에 사용성이라는 관점에서 봤을 때 사용자에게 직접 필요한 것을 묻는 것은 거의 아무런 의미가 없다. 대신 그들이 실제로 하는 행동을 관찰해야 한다. 사용성 테스트는 바로 그것을 의미한다. ... 묻지 않고 관찰하는 것이다.

 

꾸준히, 자유롭게, 즐겁게 - 한국 오픈 소스 개발자들 이야기

 

지은지: 송우일

출판사 : 인사이트

출판일 : 2013-10-10


한국의 오픈소스 생태계가 척박하고, 글로벌하게 기여하는 문화가 없다는 지적이 많다고 생각하는 한편, 어떻게 오픈소스 개발을 시작하고, 꾸준하게 기여할 수 있는지는 잘 모르겠다.

 

이 책은 한국에서 오픈소스 개발을 진행하고 있는 분들의 인터뷰 모음집이다.

읽기 전에는 한국에서 오픈소스 개발자가 된다는 것은 어떤 의미일까? 어떻게 시작하게 되었을까? 왜 포기하지 않고 꾸준하게 할까?하는 등의 의문이 생겼다.

다 읽고 난 후에도 깔끔하게 이해가 되진 않는다. 여전히 왜 하는지 잘 모르겠고, 나와는 먼 이야기기라고 생각이 되고, 실제로 발을 담그기가 주저된다.

 

그래도 제목처럼 꾸준히, 자유롭게, 즐겁게 오픈소스 개발을 하고 있는 여러~분들의 생생한 이야기를 들을 수 있어 좋다.

 

* 공개 후 유지 보수할 수 있는지 검토해 봐야 합니다. 그냥 소스만 공개해 놓고 내버려두면 추진력을 얻기가 쉽지 않거든요. 소스를 공개해서 회사도, 자신도 이득을 얻고 사용자도 혜택을 받으려면 최소한 프로젝트가 특정 궤도에 오르기까지 잘 관리해야 하고 또 크게 발전할 수 있도록 회사 외부 사람이 기여하더라도 차별 같은 게 없어야 합니다. ... 그렇게 하지 않고 소스만 공개하고 말면 이미지만 나빠질 수도 있습니다.

 

정보, 통신, 기술/읽은 것들

빅데이터의 충격

빅데이터의 충격- 거대한 데이터의 파도가 사업 전략을 바꾼다!

 

지은이: 시로타 마코토

옮긴이: 김성재

감수: 한석주

출판사: 한빛미디어

출판일: 2013-01-02

 

전에 읽은 "클라우드의 충격"의 저자가 같은 스타일로 쓴 IT 교양 서적이다.

"클라우드의 충격"이 갖고 있는 장점인, 짧은 분량에도 해당 주제와 관련된 다양한 이이기를 매우 짜임새 있게 제시한다는 점이 이 책에도 잘 살아 있다.(단, 개인정보보호와 관련된 장황한 이야기만 빼고...)

 

- 빅데이터란 기존의 일반적인 기술로는 관리하기 곤란한 대량의 데이터군이다.

- 3V: 데이터양(Volume), 다양성(Variety), 속도(Velocity)

- 하둡이란 한마디로 말해 오픈소스로 공개된 대규모 데이터의 분산처리 기술이다. ... 하둡은 구글이2004년에 발표한 '맵리듀스: 대형 클러스터의 데이터 처리 단순화'라는 대규모 데이터의 분산처리에 관한 논문이 기반이 되었다.

- 요즘 미국에서는 하둡과 NoSQL 데이터베이스 관련 기업으로 벤처캐피털의 투자가 대규모로 이루어지는 상황이다. 대표적인 벤더가 클라우데라다. 클라우데라는 2009년 창업 이후 네 번에 걸쳐 투자를 받아 총 7,600만 달러라는 거액의 자금 조달에 성공했다.

- 분석적 데이터베이스: MPP Architecture, Shared Nothing Architecture, 칼럼 지향, 데이터 압축 기능, 범용 하둡에서 동작 가능, 어플라이언스로서 제공, 하둡 지원

- 다양한 분석 기술: 기계학습, 데이터 마이닝, 클러스터링, 신경망 네트워크, 회귀 분석, 결정 트리, 연관 분석, 자연어 처리, 시멘틱 검색, 링크 마이닝, A/B 테스트

 

- 징가: "우리는 게임 회사의 탈을 쓴 분석 회사다.", '3클릭 테스트'

- 센트리카: 스마트 계량기를 도입해 에너지 소비 패턴을 분석

- 카탈리나 마케팅: 쿠폰으로 고객의 구매 행동을 디자인. 전 세계 약 5만 5,000개 소매점에서 매주 3억 6,000만 명의 고객 구매 이력을 측정

- 코마츠: 건설기계에 GPS와 각종 센서를 장착해 기계의 현재 위치, 가동 시간, 가동 상황, 연료의 잔량, 소모품 교체 시기 데이터를 수집

- 리크루트: 취직, 전직 구인 정보에서 시작, 결혼, 주택 구매, 전직, 음식, 여행 등의 정보 제공. 추천 시스템을 구현하고 연관 분석, 속성 분석 등을 실시

- GREE: 'GREE 분석'이라는 데이터 마이닝 도구를 독자 개발. 사용자 등록일, 등록경로, 이용 상황, 이벤트 참가율, 사용률, 소비율, 아이템별 매출, 게임 진척 상황, 지속률 등의 사용자 동향을 시간 단위로 파악

- 맥도날드: '이득이 되는 모바일', '이득이 되는 앱'. 쿠폰, 상품정보, 점포 검색, 스탬프 캠페인 등을 제공

 

- 빅데이터 활용 사례: 상품과 서비스 추천, 행동 타케팅 광고, 위치정보를 이용한 마케팅, 부정검출, 고객 이탈 분석, 고장 예측, 이상 검출, 서비스 개선, 차량 정체 예측, 전력 수요 예측, 감기 예측, 주식 시장 예측, 연료 비용 최적화

- 빅데이터 활용 수준 : 과거와 현재의 현상을 파악 → 패턴 발견: 데이터 마이닝, 기계학습 → 장래 예측 → 최적화: 쿠폰으로 판매 신장, 혜택으로 우량 고객 이탈 방지, 요금 변경으로 공급 압박 해소

 

- 개인정보보호는 너무 어려워...

 

- LOD 운동: Linked Open Data. 지금 당장 로 데이터를!(Raw DATA Now!)

- 열린 정부 만들기: Data.gov, Data.gov.uk

- 플라이트캐스터: '항공사 실시간 운항 실적 및 운항 지연의 원인' 등의 데이터를 활용

- 클라이메이트 코퍼레이션: 농가를 대상으로 '종합기후보험'을 판매. 미국 농부부가 공개한 과거 60년분의 작물 수확량으로 옥수수, 콩, 가을 밀 등의 수확량을 예측

- NYC Big Apps: 'NYC Open Data'라는 뉴욕시의 공공 데이터를 이용한 애플리케이션 콘테스트

 

- 데이터 어그리게이터: 오프라인 중심의 비즈니스에서는 데이터 어그리게이터의 존재 의의가 크다.

- 데이터 과학자의 능력과 자질: 컴퓨터 과학, 수학, 통계, 데이터 마이닝 등, 데이터의 가시화, 커뮤니케이션 능력, 기업가 정신, 호기심

- 오페라 솔루션: '빅데이터를 이익으로 바꾸다'. 2011년 9월 벤처캐피털로부터 8,400만 달러라는 거액의 투자를 받았다.

- 뮤 시그마: 데이터를 바탕으로 의사결정을 하는 기업을 지원. 2011년 12월 1억 800만 달러라는 거액의 투자를 받았다.

 

- "분석으로 경쟁하라"

기업이 분석력을 다 살리지 못하는 이유는 사실 분석 방법이나 데이터양, 분석 기술과도 관계없다. (중략) 결국 분석 관리로의 전환을 방해하는 것은 기업에서 아주 흔히 볼 수 있는 다음과 같은 현상 때문이다.

- '우리는 옛날부터 이렇게 해왔어'라는 '상식'때문에 정당성이 검토되지 않는다.

- 경영진이 데이터나 시실에 입각하지 않는 의사결정을 해도 비판받지 않는다. 오히려 천재형 리더가 인기 있다.

- 분석 능력을 갖추고 데이터 속에서 보물을 찾아내려는 사람이 없다. 아무것도 떠오르지 않을 때 할 수 없이 하는 일이 분석이라고 여기며, 더구나 전문지식이 없는 사람이 분석을 한다.

- '그 아이디어가 좋으냐 나쁘냐'보다 '그것을 누가 말했는지'를 문제시한다.

 

- 데이터 주도형 기업Data Driven Enterprise: 데이터 분석 결과로 얻어진 통찰을 시의적절하게 비즈니스에 도입해 경쟁 우위로 이끄는 기업

 

정보, 통신, 기술/읽은 것들

클라우드의 충격

 

클라우드의 충격- IT 역사상 최대의 창조적 파괴가 시작되었다

 

지은이 : 시로타 마코토

옮긴이 : 진명조

출판사 : 제이펍

출판일 : 2009-10-22

 

클라우드에 대해 이해하기 위해서 가볍게 읽어 볼 수 있는 책이다.

 

출판된지 5년이나 지나서, 매우 빠르게 변하는 IT 상황에서 보면 이미 유통 기한이 만료된 자료이다.

또 약 180여 페이지에 기술적인 상세함보다는 개념 설명을 중심으로 가볍게 작성되어 있다.

하지만 이런 단점에도 불구하고, 잘 짜여진 구성과 매우 쉬운 설명으로 클라우드에 대한 전반적인 이해와 클라우드 사업의 플레이어들에 대한 단초를 얻을 수 있다.

 

클라우드라는 어찌보면 무거운 주제를 이렇게 쉽게 설명하는 것도 상당한 능력이다.

앞서 지적한 바와 같이 이미 자료의 유효성은 이미 많이 만료되었다고 생각되어, 그 자세한 내용 하나하나는 크게 개의치 않고 쉽게쉽게 읽기에 좋은 책이다.

 

- 컨설턴트인 제프리 A. 무어의 '코어Core/컨텍스트Context' 이론이다. 무어는 자신의 저서 "Living on the Fault Line, Revised Edition"에서 '코어(핵심) 업무로의 자원집중이야말로 기업의 경쟁우위성을 높이는 방법이며, 그 이외의 업무(컨텍스트 업무)는 모두 아웃소싱을 해야 한다'라고 주장하고 있다. 여기서 말하는 '코어'란, 기업 경쟁력의 원천이 되고 영속적인 차별화를 가능하게 하는 기업활동이며, 그 이외의 활동은 모두 '컨텍스트'로 정의하고 있다.

한편, 무어가 컨텍스트 업무에 있어서 승리하는 접근방법으로 추천하고 있는 것은 차별화를 도모하는 것이 아니라 '가능한 한 표준적인 방식으로 효율을 최우선으로 해서 수앵하는 것'이다. 또한 '누군가에게 있어서 컨텍스트는 반드시 다른 누군가에게 코어다'라고도 언급하고 있다. 즉, '자신에게 코어가 아닌 업무라고 하더라도 이를 코어 업무로서 하고 있는 사람이 있다'는 것이다.

 

- 무어의 주장을 시스템 조달의 경우를 빗대어 생각해보면, '경쟁업체에 대한 경쟁우위를 가져오는 코어 시스템은 자사에서 개발하고, 차별화를 낳지 않는 컨텍스트 시스템은 그것을 코어 업무로 하고 있는 외부의 서비스 제공자에 맡기면 된다'는 것이 된다.

 

- 무어는 ... '미션-크리티컬Mission-Criticla/비 미션-크리티컬Non-Mission-Criticla'이라는 구별에 따라 기업활동을 더욱 상세하게 분석하는 방법을 소개하고 있다.

여기서 말하는 '미션-크리티컬'이란, 만일 정지했을 경우 즉시 심각한 리스크로 이어지는 기업활동을 가리키며, 그 이외의 활동은 비 미션-크리티컬이라고 한다. 즉, 코어/컨텍스트가 '타사와의 차별화와 관련되는지 여부'로, 미션-크라티컬/비 미션-크리티컬은 '확실하게 기능을 수행하지 않을 경우, 기업경영에 영향을 초래하는 심각한 리스크 요인이 되는지 여부'로 구별하고 있는 것이다.

 

- 아래 이미지를 갖고 조금만 더 설명하자면(정확한 내용은 책의 107쪽부터 확인하시면 되겠다!!), 모두 4 영역으로 구분되는 상황에서

 

4번 영역은 '가능한 한 표준적인 방식으로 효율을 최우선으로' 해서 SaaS를 도입한다.

3번도 역시나 SaaS인데, 미션 크리티컬하므로 서비스수준협약SLA이 납득 가능한 업체를 이용한다.

1번은 변화와 혁신이 있지만, 성과가 불확실한 면도 있으므로, PasS, 혹은 IaaS를 이용한다.

2번은 적극적으로 사내 리소스를 투입해서 자사 개발을 해야 한다.

 

물론, 마지막 이미지에서 자세히 설명된 바와 같이 자사 조달이 높은 비용과 큰 운영부하를 갖는 반면에 최근의 서비스 수준의 향상으로 클라우드 서비스 업체가 보안이나 안정성적인 측면에서 자사에서 운영하는 것 대비해 문제가 있다고 보기는 힘들기 때문에 2번은 개발과 운영은 사내 리소스를 투입해서 해야겠지만, 인프라만큼은 클라우드 서비스를 이용하는 것이 맞다고 생각한다. 즉, 1번은 PaaS를, 2번은 IasS를 이용하는 것이 좋다고 생각한다.

 

 

 

* 출처

1. http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8996241032

2. http://www.dealingwithdarwin.com/index.php

3. http://www.slideshare.net/sasindia/keynote-geoffrey-mooreusinginnovationtothriveandstrive

4. http://www.slideshare.net/movingmt/v4-37958904

 

정보, 통신, 기술/읽은 것들

[서평] 능률적인 프로그래머

 

능률적인 프로그래머- 프로그래머 생산성의 비밀

 

저자 : 닐 포드 (지은이), 김현수 (옮긴이)

출판사 : 지&선(지앤선)

출판일 : 2009-09-25

 

개발자 세계에는 게으른 개발자가 일을 잘 한다는 역설이 있다.

게으른 만큼 최소한의 노력으로 목표를 이루기 위해 머리를 잘 쓴다는 의미이다.

 

... 프로그래머의 3대 덕목으로 '게으름, 조급함, 오만함'이라고 했다.

 

능률적인 프로그래머가 어떤 스타일을 갖으며, 그렇게 되기 위해 어떤 툴을 익혀야 하는지를 다양한 주제로 이야기해준다.

이 책을 정리하거나, 요약하는 것은 정말 의미가 없다는 생각이 든다.

 

책에 나오는 소재 중에 생각을 이끄는 화두를 뽑아보면 다음과 같다.

 

... 검색. 클립보드. 매크로. 다중 모니터. 가상 데스크톱으로 작업 공간 분리. 자동화. 바퀴 다시 안 만들기. 야크 털깎기. 정식화. 반복치 말라Don't Repeat Yourself(DRY). 문서화. 테스트 주도 설계. 코드 검사. 정적 분석. 캡슐화 깨기. 쓸 데 없을걸You Ain't Gonna Need It(YAGNI). 은총알. 비운의 전함 바사호. 아리스토텔레스의 본질과 비본질 속성. 오컴의 면도날. 디미터의 법칙. 관용 코드. 성난 원숭이 떼. 반 객체. 메타 프로그래밍. 단일 추상화 수준 원칙SLAP. 다중 언어 프로그래밍polyglot programming. 최적의 편집기. 허락보다는 용서 구하기. 난쟁이 어깨 올라타기 반 패턴. 계속되는 대화. 소통dialogue. 시그원.

 

아마도 이 중에 관심이 가는 주제가 있다면, 그와 관련된 단행본을 구해 볼 수 있으리라...

이 책은 이렇게 백화점식 소재 안내로 능률적인 프로그래머가 되길 원하는 독자가 기호에 맞춰 갈 수 있는 방향을 안내하고 있다.

 

ps. 마우스를 쓰지 않고, 오로지 키보드만으로 모든 것을 해결하는. 마치 손가락 끝에서 생각이 나오는 듯이, 코드에 막힘이 없는 실력을 꿈꾼다.

하지만, 아쉽게도 이런 외워야 하는 기본 명령어에 익숙해 지지 않음이 안타깝다.

지향하는 개발 역할을 코어 개발보다는 업무 개발로 삼기때문에, 효율적인 툴 사용보다는 사용자 친화적인 UI/UX를 익히는데 더 노력해야지 하는 별 쓸데없는 다짐을 해본다.

 

정보, 통신, 기술/읽은 것들

구글은 소프트웨어를 어떻게 테스트하는가

 

구글은 소프트웨어를 어떻게 테스트하는가

 

저자 : 제임스 휘태커 , 제이슨 아본 , 제프 카롤로

출판사 : 에이콘출판

출판일 : 2013.03.29

 

구글은 소프트웨어 테스트를 어떻게 하는지 구글의 테스트 디렉터 '제임스 휘태커'가 쓴 책이다.

구글 검색, 애드센스, 지메일, 구글 앱스, 구글 지도, 안드로이드, 유튜브, 크롬과 크롬OS 등 구글은 많은 히트 작을 갖고 있다. 

제품 구성도 다양해서 그 제품이 지메일처럼 내부 개발인지, 유튜브처럼 외부 구매인지를 따지지 않는다.

또, 구글 검색처럼 소비재인지 애드센스처럼 기업용인지도 따지지 않고, 안드로이드처럼 대규모 사용자를 바탕으로 한 제품인지 크롬OS처럼 벤처정신의 제품인지도 따지지 않는다.

 

결론은 그냥 다 잘 만든다.

 

물론 구글의 모든 제품이 성공하는 것은 아니지만, 이렇게 성공하는 제품을 계속 출시하는 것은 하나를 성공시키고 유지하는 것보다 휠씬 더 대단한 일이다.

그리고 같은 개발자 입장에서 이런 대단한 성공에는 분명 무시무시한 전략과 이를 현실케하는 더 무시무시한 개발 문화가 있을 것이라고 생각한다.

 

본격적인 테스팅을 하지 않은, 개발하기에 급급한 일개 개발자가 이 책을 제대로 소화하기란 쉽지 않다.

샘플 코드가 쏟아지고, 데모 스크린 샷이 여기저기 있진 않지만, 소문듣고 찾아온 과객이 제대로 이해하기에는 어려운 내용이 많다.

 

그래서 나는 테스트 방법론 혹은 테스팅 툴에 대한 자세한 설명은 쉽게쉽게 건너 뛰고, 이런 방법론과 툴을 만들 수 있었던 구글의 문화, 관리 기법에 더 관심을 갖기로 했다.

 

... 지금까지 내 모든 이야기 중 구글에 대한 한 가지는 분명하다. 구글은 전산학과 코딩 기술을 존중했다. 결국 테스터가 이 클럽에 동참하려면 훌륭한 전산학 지식과 몇 가지 절묘한 코딩 기술을 갖고 있어야 했다. 일등 시민이 되기 위해선 반드시 갖춰야 할 요소였다.

 

... 불만이 있는 사람들에 대해 내 상사는 이렇게 이야기했다. "여긴 구글이야, 뭔가 하고 싶으면 해야지."

 

... 구글에서는 생산성 혁신 팀(Engineering Productivit Team)이라 불리는 중앙 조직에서 소프트웨어 테스팅을 담당한다. 생산성 혁신 팀은 개발자와 테스터의 툴 체인을 수행하고, 단위 테스팅부터 탐색적 테스팅에 이르는 모든 분야의 테스팅과, 그에 관련된 공학적인 방법을 만들며, 검색, 광고, 앱, 유튜브 등 모든 웹 특성과 관련된 공용 툴과 테스트 인프라스트럭처를 다룬다. 생산성 혁신 팀을 통해 구글은 속도와 규모에 관한 여러 가지 문제를 해결했으며, 대기업이 됐음에도 불구하고 시작 단계의 벤처와 같은 속도로 소프트웨어를 릴리스할 수 있게끔 했다.

 

... 품질과 테스트가 동치는 아니다. 하지만 품질을 이루기 위해서는 개발과 테스팅을 믹서기에 함께 넣고 구분되지 않을 정도로 섞어야만 한다. ... 품질 활동은 잘못된 부분을 발견해 수정하는 활동이 아니라 발생하기 전에 예방하는 활동에 가깝다는 것을 뜻한다. 품질은 개발 관련 문제이지 테스팅에 관한 문제가 아니다.

 

... 소프트웨어 엔지니어(SWE, SoftWare Engineer) 전형적인 개발자다. 많은 양의 테스트 코드를 작성하고, 거의 100%에 가까운 시간을 코드 작성에 사용한다.

 

... 테스트 소프트웨어 엔지니어(SET, Software Engineer in Test) 역시 개발자다. 단지 SET의 경우 테스트 가능성(testability)과 테스트 인프라스트럭처에 포커스가 맞춰져 있다는 점이 다르다. SET는 SWE 코드베이스에 같이 참여하지만, 새로운 기능 추가나 성능 향상보다는 품질 향상과 테스트 커버리지 향상에 집중한다. SET 역시 100%에 가까운 시간을 코드 작성에 할애하지만, 고객이 사용할 기능보다는 품질에 관한 서비스 기능을 만드는 데 집중한다.

 

... 테스트 엔지니어(TE, Test Engineer) 테스트를 하되, 반은 사용자의 입장에서, 나머지 반은 개발자의 입장에서 테스트한다. 프로젝트의 마무리 단계에서 릴리스 일정을 지키기 위해 압력을 넣는 역할을 한다. TE는 제품 전문가이며, 품질 조언자이고, 리스크 분석가이다.

 

... 테스터는 기본적으로 상품화 팀에 서비스를 제공하며, 품질 관련 논의를 자유롭게 제시할 수 있고, 테스터가 놓치거나 수용할 수 없는 버그 비율을 보여주는 기능 영역에 대해 질문할 수 있다. 개발 팀이 테스팅에 대해 지름길을 원한다면 미리 협의해야 하며, 우리는 어떤 경우에든  No라고 말할 권리가 있다.

 

... 완벽한 제품의 컨셉을 갖고 가능성을 타진하기도 전에 품질에 초점을 두게 되면 우선순위를 거꾸로 작업하는 꼴이 된다. 우리가 보아온 구글 20% 활동이 만들어낸 많은 초기 프로토타입이 개발 먹기(dog fooding)나 베타 버전쯤 됐을 때 오리지널 코드는 약간밖에 남아 있지 않으며, 결국 거의 다시 설계됐다. 실험적인 경우에 대해 테스트를 수행하는 일은 확실히 바보들이나 하는 짓이다.

 

... 이렇게 구글의 문화는 다르다. 단순히 프로젝트가 존재한다고 해서 테스팅 자원을 얻지는 못한다. 개발 팀은 테스터에게 도움을 요청하고 그들의 프로젝트가 매우 흥미롭고 잠재력이 많음을 확신시킬 책임이 있다. ... 우리는 프로젝트 초기에는 관여하지 않지만, 프로젝트가 실체화되면 어떻게 수행할 것인지에 대해 많은 영향력을 갖게 된다.

 

... 좋은 SET가 고려하는 항목 : 규모에 대해 생각한다. 재사용을 생각한다. 안전성에 대해 생각한다. 확장성에 대해 생각한다. 불변 인자에 기반을 둔 최적화를 고려한다. 안전성을 고려한다.

 

... ACC(Attribute, Component, Capability) 분석. 1) 제품의 목적과 목표를 설명하는 형용사와 부사, 2) 제품의 여러 부분과 기능을 일컫는 명사, 3) 제품이 실제로 수행하는 것을 지칭하는 동사다.

애트리뷰트는 시스템의 목적과 목표를 설명하는 형용사다. 이러한 형용사들은 제품을 경쟁 제품과 대비해 향상시키는 품질과 특성이다. 이것들은 고객들이 다른 경쟁사 제품 대신 우리의 제품을 선택하는 이유에 대한 설명이 될 것이다.

컴포넌트는 목표하는 시스템을 만들기 위해 함께 사용되는 벽돌과 같은 것이며, 어떤 소프트웨어인가를 결정짓는 주요 코드 부분들이 컴포넌트다.

캐퍼빌리티는 사용자 명령을 수행하는 시스템 동작을 말한다. 캐퍼빌리티는 입력에 대한 반응이며. 질의에 대한 대답이고, 사용자의 목적을 달성하기 위해 완료하는 활동이다.

 

... 온라인 쇼핑 사이트의 개퍼빌리티 예

- 장바구니에서 항목 추가/삭제하기. 장바구니 컴포넌트의 캐퍼빌리티로서 '직관적인 UI' 애트리뷰트를 다룬다.

- 신용카드 정보를 수집하고 데이터를 검증하기. 장바구니 컴포넌트의 캐퍼빌리티로서 '편리한' 애트리뷰트와 '통합된' 애트리뷰트를 다룬다.

- 배송비 계산하기. 이것은 '빠른'과 '보안' 애트리뷰트를 다루는 배송 컴포넌트의 캐퍼빌리티다.

- 재고 여부 보여주기. 이것은 '편리한'과 '정확한' 애트리뷰트를 다루는 검색 컴포넌트의 캐퍼빌리티다.

 

... 특히 TE는 알고리즘, 이론 증명, 기능 구현에 있어 최고가 아니기 때문에 직무에 적합한 사람을 채용하기란 어려울 수밖에 없다. ... 그들은 기술적이고, 사용자 입장을 고려하며, 제품을 체계적으로 최종 사용자의 관점에서 이해하는 사람들이다. 그들은 수그러들줄 모르는 훌륭한 교섭자이며, 그리고 무엇보다 중요한 것은 그들은 창의적이며, 애매모호한 것을 처리할 수 있다는 점이다.

 

... 구글 피드백(Google Feedback). 퀼리티 봇(Quality Bots). 셀레니엄(Selenium). 웹드라이버(WebDriver). 브라우저 통합 테스트 환경(BITE, Browser Integrated Test Environment). 기록/재생 프레임워크(RPF, Record and Playback Framework). 구글 테스트 케이스 매니저(GTCM, Google Test Case manager). 구글 테스트 분석(GTA. Google Test Analytics)

 

... 테스트 엔지니어(TE)와 테스트 소프트웨어 엔지니어(SET)가 사용자와 개발자 각각을 지원하기 위해 노력하는 동안 그들을 하나로 묶는 역할이 있다. 바로 테스트 엔지니어 매니저(TEM, Test Engineering Manager)다. TEM은 구글의 모든 위치 중 가장 도전적인 위치이고, TE와 SET 모두에게 필요한 기술을 알아야 한다. 또한 경력 개발 시에 필요한 보고서를 직접 만들 수 있는 관리 스킬도 필요하다.

 

... 구글 직원은 한 분기 정도의 차이는 있을지 모르지만 18개월마다 프로젝트를 변경할 수 있다는 점이다. ... 어떤 TEM이든 사내 공모를 하고, 어떤 TE 또는 SET든 새로운 기회를 볼 수 있다. 사내 공모를 하기 전에 현재 또는 향후 관리자들에게 어떠한 공식적인 승인도 받을 필요가 없다. ... 일반적으로 엔지니어가 프로젝트 A에서 프로젝트  B로 이동할 때 엔지니어는 한 분기 동안 20%의 시간을 새로운 프로젝트 B에 쏟고, 다음 분기에서 20%의 시간을 기존 A 프로젝트에 대해 사용하고, 프로젝트 B에 80%의 비율로 사용한다.

 

... 프로젝트를 선택하는 데 있어 TEM이 갖는 일반적인 규칙은, 나쁜 프로젝트는 피하라는 점이다. 품질에 있어 동등한 파트너십을 꺼려하는 팀에게는 테스팅을 그들 스스로의 일로 남겨두게 한다. 소형 테스트와 훌륭한 단위 레벨의 커버리지를 만들기 싫어하는 팀은 조용히 스스로의 무덤을 파게 된다.

 

... 그들이 협업하는 진짜 이유는 다른 팀과의 협업을 하면 아주 놀라울 만한 혁신을 일으킬 수 있기 때문이다. 그 누가 영향력 있는 새로운 툴을 사용하지 않는 유일한 테스터가 되고 싶겠는가? 또한 누가 스마트하게 일하고 싶지 않겠는가?

 

... 전 복잡하게 생각하지 않고 어려운 문제에 직면하면 그 문제를 해결할 수 있게 구체적인 단계로 변환할 수 있는 사람을 찾습니다. 물론 그 문제를 해결해야겠지요! 시간에 쫓기기보다는 적극적이고 열정적으로일을 하는 사람이 필요합니다. 혁신과 품질 사이에서 균형을 이룰 수 있어야 하고, 단순하게 찾을 수 있는 버그 이상을 찾아낼 수 있는 생각 있는 사람이 필요합니다. 그리고 그 무엇보다도 열정이 보이길 바랍니다. 정말로 테스터가 되길 원하는 사람을 바랍니다.

 

... 탐색적 테스팅이 제품을 파헤쳐가면서 제품을 익히는 최선의 방법입니다. ... 필요할 때는 모든 SET가 TE처럼 행동할 때도 있고, 그 반대의 경우도 있습니다. 전 직책에 그리 크게 신경 쓰지 않습니다. 가치를 부가하는 것에 더 많은 관심을 갖죠. ... 일일 빌드를 통해 나오는 S/W를 테스트하기 위해 그 안에 무엇이 있는지 밀착해서 분석합니다. 우리는 테스트를 해야 할 중요한 부분을 식별하기 위해서 조율 회의(coordination meeting)를 매일 수행하고, 해당 부분의 담당자가 누구인지를 확인합니다. 제게 있어 수동 테스트의 핵심은 집중과 조율입니다. ... 모든 기능은 각각 고유의 속성이 있고 수동 테스터들은 추후 이 기능을 테스트하게 될 다른 테스터들을 위해 이를 문서화해 가이드라인을 작성합니다. 따라서 일반적인 시스템 레벨의 유스케이스에 대한 테스트 문서와 기능 특화된 가이드라인을 작성하는 데 시간을 쏟습니다.

 

... 테스트 디렉터(Test Director) 여러 제품의 여러 매니저를 이끄는 역할이다. 그들의 초점은 어떻게 품질과 테스팅이 비즈니스에 영향을 미치는지, 때로는 외부 업계와의 공유에 대해 집중한다. 그들은 고위급이나 클라이언트, 애플리케이션, 광고 등과 같은 '핵심 분야'와 밀접하게 업무를 진행한다.

 

... 시니어 테스트 디렉터(Senior Test Director) 구글에는 직무 기술, 고용, 외부와의 커뮤니케이션, 그리고 전반적인 구글의 테스팅 전략을 위해 일관된 접근을 해야 하는 고위 리더십의 의무를 가진 사람이 딱 한명 있다(패트릭 코플랜드). 그의 업무는 종종 모범적인 경영 사례 중 하나로 공유되고, 글로벌 빌드 또는 테스트 인프라스트럭처, 정적 분석, 구글의 제품, 사용자 이슈, 코드 기반을 폭넓게 포괄하는 테스팅 활동들에 대해 새로운 계획을 창조하고 추진하는 일을 한다.

 

... 구글은 특출 나게 자기 동기 부여가 잘되는 사람들을 고용했어요. "내가 그렇게 하라고 했잖아"라는 건 한 번 정도 먹힐 뿐이지만, 이 스마트한 사람들은 시작을 하고 수십 번 생각한 후에 자신이 생각한 최선을 수행합니다. 가이드를 해주고, 통찰력을 제공하고, 제 사람들에게 문을 열고 그들이 가장 열정을 쏟아 붓고 싶어하는 일을 하게 해서 대부분 적극적으로 일을 수행하게 합니다.

 

... 제가 시작할 때 패트릭 코플랜드는 두 개의 조언을 해줬습니다. 첫 번째는 "오로지 배우기만 하는 시간을 가져라"였습니다. 처음 몇 달 동안은 패트릭이 제안한 대로 했습니다. 말하는 대신 듣고, 시도하는 대신 질문했습니다. 두 번째는 제가 그렇게 좋아하지는 않습니다만, 더 좋은 조언이라고 판명이 났습니다. 그는 제 옆으로 와서 이야기했습니다. "이봐 친구, 난 자네가 구글 밖에서는 명성이 있는걸 알지만, 자넨 아직 내부에서 이룬 것이 하나도 없네." 그의 메시지는 항상 명확하고 이번 메시지는 "그전에 제가 무엇을 했던지 간에 구글은 상관하지 않는다."라는 것이었습니다.

 

... 첫 번째 미팅 때 우린 두 개의 목록으로 시작했어요. 무엇이 TE라는 역할을 흥분하게 만들고, 무엇이 TE라는 역할에 회의감을 들게 하면서 미치게 만드는지. 단지 이 목록을 만드는 것만으로도 많은 참석자들에게 카타르시스를 느끼게 했어요.

 

... 테스팅은 주로 품질을 대변하는 것으로 보이며, 개발자에게 품질에 대해 무엇을 하고 있냐고 물어보면 '테스팅'이라고 주로 대답한다. 하지만 테스팅이 품질은 아니다. 품질은 녹아 들어가는 것이지 덧붙이는 것이 아니므로 품질은 개발자의 업무다. 더 이상 다른 말은 필요 없다. 그런 생각들이 테스터들은 개발자의 보조라는 첫 번째 심각한 결함을 가져온다. 결국 테스팅에 대해 많이 생각하지 않고, 테스팅을 쉽게 생각하고, 결국에는 더 적은 테스팅을 할 것이다.

 

... 사용자들은 제품과 사랑에 빠지지 그것을 만드는 프로세스와 사랑에 빠지진 않는다.

 

... SET의 미래. 대학을 졸업하고 고용된 신입 개발자들은 시작하기 좋은 곳으로 테스트 개발을 찾는다.. 전체 프로젝트를 이해할 수 있는 기회뿐만 아니라, 많은 테스트 코드들이 사용되는 것은 아니기 때문에 압박을 덜 수 있고, 사용자가 직면할 버그에 대한 잠재적인 부담(나중에라도 느낄)을 덜 수 있다. ... 새로운 멤버가 오면 기존의 테스트 개발자들은 기능 개발로 옮겨 새로운 엔지니어에게 길을 터준다. 신입 엔지니어들은 시간이 지남에 따라 능력이 좋아지고, 품질을 진지하게 다루게 된다.

 

... TE의 미래. 테스트 엔지니어링은 테스트 설계 역할로 변화해야 한다. ... 테스터들이 피드백을 주면 TE는 커버리지를 확인하고 리스크 영향을 계산하고, 그 경향이 줄어들고 있음을 확인하고, 테스팅 활동을 적절히 조정한다. ... 이러한 업무들은 테스트 생성도 없고, 테스트 수행도 없고, 실제 테스팅 자체가 없다. '없다'라는 것은 너무 강력한 표현일지도 모르겠지만, 여하튼 그러한 업무들이 매우 최소화된다. 우리가 생각하기에 TE는 보안 전문가와 같은 역할을 갖거나 다른 이들이 수행하던 테스팅 활동의 관리자가 될 것이다.

 

... "부록 B. 크롬에 대한 테스트 투어"는 테스트에 재미있는 여행 이름을 부여했다.

 

... 중간에 언급된 각종 툴에 대한 더 자세한 내용이 "부록 C. 툴과 코드에 대한 블로그 포스트"에 준비되어 있다.

 

소프트웨어 테스팅 마이크로소프트에선 이렇게 한다 

저자 : 앨런 페이지 , 켄 존스톤 , 비제이 롤리슨
출판사 : 에이콘출판

출판일 : 2009.12.01

 

책에도 나오지만, 구글이 소프트웨어 개발 테스팅의 르네상스를 열었다면, 그 처음의 태생은 마이크로소프트의 활동이라 할 수 있을 것이다.

다음엔 이 책을 읽어야겠다.

 

  1. Favicon of https://boom2580.tistory.com BlogIcon 칼퇴의품격 수정/삭제 답글

    이 책을 요즘 읽고 있는데, '소문듣고 찾아온 과객이 제대로 이해하기에는 어려운 내용이 많다.' 에서 공감하고 갑니다.

    • Favicon of https://blog.watist.net BlogIcon 최윤호 수정/삭제

      전 테스트에 관심있는 개발자라서 배경 지식의 부족함을 많이 느꼈구요.

      실제 테스트 업에 계신 분이라면 피와 살이 되지 않을까 싶더군요.

정보, 통신, 기술/읽은 것들

Node.Js 노드제이에스 프로그래밍

 

Node.Js 노드제이에스 프로그래밍 클라우드 컴퓨팅 시대의 고성능 자바스크립트 플랫폼

 

저자 : 변정훈

출판사 : 에이콘출판

출판일 : 2012.02.17

 

요즘 유행하는 Node.Js를 이용한 프로그래밍 서적이다. 자바스크립트와 CommonJS, 탄생과 역사, 그리고 특징 등의 기본적인 노드 소개설치와 간단한 샘플 등의 시작을 거쳐서 전역 객체, 유틸리티, 이벤트, 버퍼, 스트림, 파일 시스템, 경로, 네트워크, HTTP와 HTTPS, URL과 퀴리 문자열, 자식 프로세스, 클러스터, TCP를 이용한 채팅 예제 등의 기본 모듈에 대한 설명을 지나 npm을 이용한 확장 모듈 관리를 하고, 트워터 백업 애플리케이션 예제를 배운 후에 드디어 Simple Chat 예제가 나온다.

 

Simple Chat을 구성하는 2개의 확장 모듈인 경량 웹 프레임워크 익스프레스리얼타임 웹사이트를 위한 Socket.IO를 먼저 익힌 후에 익스프레스와 Socket.IO를 이용한 Simple Chat 예제가 본격적으로 펼쳐진다.

어느 지인이 말한대로 Node.JS 자습서의 1장이 채팅일지라도 완성된 채팅 기능을 하는 샘플은 쉽게 구할 수 없다.(물론 이 샘플도 완성 버전은 아니다. 단지, 기능적으로 입장부터 퇴장까지 완전하다.)

더구나 자세한 설명이 "한글"로 된 온전한 소스라니!!

앞의 확장 모듈을 설명하는 장과 함께 익히면 풍부한 주석까지 포함해서 총 350 라인 정도되는 온전히 작동하는 풀 소스를 갖게 된다.

 

Simple Chat 예제 이후, 책은 디버깅유닛 테스트, 그리고 VMWare의 클라우드 파운드리, 허로쿠, 조이엔트의 no.de 소개가 들어있는 클라우드 서비스 배포로 마무리된다.

 

개인적으로 자바스크립트 언어를 좋아하지만, 자바스크립트로 서버사이드를 100% 구현하는 것은 개발 생산성과 유지보수면에서 어렵지 않나 싶다. 정의로 이동, 자동완성, 리팩토링과 같은 IDE 기능도 그렇고, 인터페이스와 클래스 상속이란 OOP 언어면도 그렇고, 브레이킹과 단계별 실행 등의 디버깅도 그렇고, 전체 소스에 대한 가독성도 그렇고, 여러모로 아직은 그렇다.

 

반면 API 서비스를 하는 부분에선 UI라고는 JSON 데이터 Response하는 부분이 다인만큼 데이터베이스 드라이버만 제대로 갖춰진다면 얼마든지 Node.JS가 갖는 비동기성의 매력을 발휘할 여지가 많겠다는 생각이다.

지금 공부하는 이유도 개발중인 API 서비스에 Socket.IO를 적용해 보기 위함이고 말이다.

 

Node.JS에 관심있는 분이라면 일독을 권한다.

정말 어렵지 않게 단계별로 차근차근 설명해 준다.

 

다음은 경량 "6장 웹 프레임워크 익스프레스"에 나오는 "비동기 패턴의 의존성 문제" 해결 방안이다.

책을 읽다 보면 이거 뭐야 싶은 부분을 바로바로 긁어주는 부분이라 정리해 둔다.

 

6.6 비동기 패턴의 의존성 문제

6.5절에서 살펴본 MySQL과 몽고디비 예제를 보면 거슬리는 부분이 있다. 웹 서버에 대한 코드와 데이터베이스를 사용하는 코드를 분리하기 위해 repository.js를 만들었지만, 노드의 특징인 비동기로 인해 뷰 파일을 렌더링하는 코드가 repository.js의 콜백 함수 안으로 들어갔다. 의존성을 갖지 않기 위해 파일을 분리했지만, 데이터베이스 사용 결과가 콜백 함수로 전달되기 때문에 뷰를 렌더링하는 부분도 콜백 함수 안으로 이동했고, 결과적으로 깊은 의존성이 생겼다. 이는 좋은 모듈화라고 할 수 없다. ... 비동기 패턴의 의존성을 해결하는 방법은 두 가지가 있다.

 

1) 콜백 함수를 사용한 의존성 제거

콜백 함수를 이용하는 방법은 다른 함수를 호출할 때 추가적인 파라미터로 콜백 함수를 같이 전달한다. 지금까지 노드 기본 모듈의 I/O를 사용하면서 계속 사용했던 방법이기도 하다. ... 사용된 모듈에서 결과를 처리하는 대신 콜백 함수를 호출하면서 파라미터로 결과를 전달한다.

 

2) 이벤트를 사용한 의존성 해결

모듈 간의 의존성은 콜백 함수 대신 이벤트를 사용해 해결할 수 있다. 노드는 이벤트를 사용할 수 있게 이벤트 기본 모듈에서 EventEmitter 클래스를 제공한다. EventEmitter를 사용하면 모듈 간의 이벤트를 등록하고 발생시킬 수 있다.

 

3) 반복문에서 비동기 작업

노드로 코드를 작성하다 보면 반복문에서 비동기 요청을 사용하고 반복문이 끝난 후에 그 결과를 사용해야 하는 때가 있다. ... readFile()의 콜백 함수는 비동기로 실행되므로 console.log()가 실행되는 순간에는 text 변수에는 값이 들어 있지 않다. for문에서 실행한 fs.readFile()이 모두 실행 완료된 시점에 text를 사용해야 하지만, 이 시점을 정확히 알기가 어렵다. 이 문제는 콜백 함수나 이벤트로는 해결하기가 쉽지 않은데, 가장 간단한 방법은 loopIndex와 같은 변수를 추가해서 loopIndex가 마지막에 도달하면 console.log를 실행하는 것이다.

 

상기 내용은 샘플과 자세한 설명을 제외한 것으로 정확한 내용의 이해를 위해서는 꼭 책을 읽어 보기 바란다.

 

하지만, 함수가 파라미터로 함수 사이를 넘나드는 것 자체가 익숙하지 않다면 고구마 넝쿨같은 콜백 함수 연결 체인은 90년대 goto문만큼이나 코드를 이해하기 어렵게 만들 것이다. 따라서 이벤트를 사용한 의존성 해결이 생소한 접근이긴 하지만, 비동기라는 특수성을 이해하는 차원에서 더 맞는 접근방법이라 판단된다.

 

반복문에서 비동기 작업 역시 상기에서 소개한 내용 이후에 책에 더 소개되어 있는 재귀적 방법이 역시나 비동기라는 특수성에서 더 맞는 방법이라 생각된다.

 

정보, 통신, 기술/읽은 것들

소프트웨어 제품 마케팅

 

소프트웨어 제품 마케팅

 

저자 : 이강만

출판사 : 삼보아트

출판일 : 2012.08.31

 

제품을 어떻게 팔 것인지에 대한 진지한 고민의 결과물, 마케팅.

그리고 소프트웨어에 대한 진지한 고민의 결과물은 아직 부족한 상황에서 그럴듯한 제목의 책이라 읽기 시작했다.

책의 부제에도 들어 있듯이 이 책은 내가 알기론 "우리나라 최초의 소프트웨어 제품을 위한 마케팅" 서적이다.

 

참고로 저자는 KOTRA(글로벌 비즈니스 지원을 하는 대한무역투자진흥공사)에서 12년간 근무하고 티맥스소프트에서 10여년간 근무 후 인텔리안시스템즈에서 총괄부사장으로 일하고 있다.

 

기본적인 용어부터 시작해서, 수행 전략까지 정말 많은 내용이 담겨 있다.

이 책의 내용을 다 소화하기에도 정말 힘들것 같지만, 어쨋든 하나씩 하나씩 노력해야겠다는 생각은 든다.

자, 고고씽~~!!

 

01 소프트웨어 마케팅의 특징

- 소프트웨어는 1) 제품 자체가 눈에 보이지 않고, 2) 쉽게 복제되며, 3) 물리적인 마모가 없다. 4) 제품의 수정이 가능한다.

- 이 책에서 다루는 소프트웨어 매케팅은 어느 정도 일반화가 가능한 상업용 패키지 소프트웨어 제품을 대상으로 한다.

- 2009년 기준으로 우리나라 패키지 소프트웨어 기업들의 평균 매출은 12억원 내외, 자본금 규모도 평균 5.6억원에 불과

- 소프트웨어 기업들의 영세성으로 인해 마케팅 예산 부족 문제


02 소프트웨어 마케팅 조직

- 제품 매니저, 마컴 매니저, 홍보 매니저, 채널 마케팅 매니저, 채널 어카운트 매니저, 웹 마케팅 매니저, 콜래트럴 매니저

- 예산만 축내는 '코스트 센터(Cost Center)'가 아니라 매출을 만들어 내는 '프로핏 센터(Profit Center)'로 인식해야


03 제품이름 정하기

- 이미 사용 중인지 여부를 확인함으로써 상표권 등 법률적 분쟁을 사전에 예방

- 쉬운 이름, 영문 스페링도 쉬운 이름, 긍정적인 요소

 

04 제품가격 전략

- 전통적 가격 모델 : 제품가격 = 물리적 CPU 수 X CPU 당 코어 수 X 가중치 X 제품단가

- 동시 사용자(Concurrent User), 혹은 전체 사용자(Named User) 기준

- 유지보수 가격 : 해외는 표준가격의 20% 요율, 우리나라는 표준가격에서 30~60% 이상 할인된 실제 공급가를 기준으로 하며 요율 또한 5~15%에 불과

- 사이트 라이선스(Site License)는 최대한 자제하는 것이 바람직. 업그레이드(Upgrade) 비용은 별도의 라이선스 항목으로 분류. 이전 및 재사용 등에 대해서도 명확히 규정. 용도별로 정식 라이선스, 백업 라이선스, 개발 라이선스, 데모 라이선스, 교육용 라이선스 등을 구분. 제품별 판매 종료일(EOL:End-Of-Life)와 서비스 종료일(EOS:End-Of-Support)도 명확하게 방침을 정하고 고객에게 공지. 단, 서비스 종료일 이후 선별된 고객에게 한해서 제공하는 연장 기술지원 서비스(EMA:Entended Maintenance Support)가 있음. 가상화 관련 정책도 포함.


05 유통채널 전략

- 직접영업(Direct Sales)과 채널(Channel)을 이용한 간접영업(Indirect Sales)

- 채널은 총판(Distributor)와 리셀러(Reseller), VAR(Value-added Reseller)로 구성

- 채널 파트너들이 특정 소프트웨어 제품의 판매를 위한 투자를 하도록 유도하기 위해서는 소프트웨어 제조업체가 먼저 가능성을 보여줘야 한다. 즉, 소프트웨어 제조업체들이 직접 영업을 통해 만족할 만한 매출 실적을 거둔 다음에 간접 영업을 위한 유통 채널 파트너를 찾아야 한다는 것이다. ... 제품에 대해서 누구보다 많이 알고 있는 자사의 영업대표들도 성공적으로 판매하지 못하는 제품을 채널 파트너들이 선뜻 나서서 열심히 판매를 위해 노력해 줄 것이라고 기대하기는 어렵다.

- 소프트웨어 제조업체들은 보통 10% 정도의 커미션으로 채널 파트너들이 만족할 것으로 생각하지만 실제 대부분의 리셀러들은 20~40% 수준의 커미션을 요구한다. 10%의 커미션은 ... '소개비(Referral Fee)' 수준에 지나지 않는다.

- 채널 MDF(Market Development Fund) 프로그램 : 제조업체와 채널이 사전에 합의한 영업 및 마케팅 활동을 채널이 시행하고 증빙자료를 첨부해서 그 비용을 제조업체에 청구하는 형태. 전시회 참가, 다이렉트 마케팅 활동, 세미나 개최, 텔레마케팅, 광고, 영업자료 제작, 교육 훈련 등이다.


06 홍보전략

- 언론홍보 : 전자신문과 디지털타임즈. 마이크로소프트웨어, 컴퓨터월드, 네트워크타임즈 등

- 애널리스트 대상 홍보 : 가트너 매직쿼드런트. 애널리스트들이 관심을 가지는 주요 이슈에는 회사 개요, 주요 사업 분야, 제품 포트폴리오, 제품의 차별성, 제품이 해결해 줄 수 있는 고객의 문제들, 선두 경쟁사와의 비교, 중장기 계획 및 비전 등이다.


07 광고전략 
- 제품의 종류, 목표 시장, 메시지 내용, 예산 규모, 경쟁사의 동향 등 여러 가지 사항을 종합적으로 검토한 후에 내려야 하지만, 현실적으로 광고 예산의 규모에 따라 광고 매체가 선택된다.


08 세일즈 프로모션(Sales Promotion) 
- 프로모션에는 크게 광고(Advertising), 홍보(PR), 인적 판매(Personal Selling), 그리고 우리말로 '판매촉진'으로도 불리우는 세일즈 프로모션의 네 가지 종류가 있다.

- 만약 세일즈 프로모션을 통해 매출이나 고객층의 장기적으로 대폭적인 확대가 이루어졌다면 이는 기존의 제품 포지셔닝 등 마케팅 전략에 큰 오류가 있음을 입증하는 것으로 그 전략을 수정해야 할 필요가 있다.

- 세일즈 프로모션에는 소개형(Introductory), 상황형(Situational), 방어형(Defensive), 그리고 업그레이드형(Upgrade) 등 크게 네 가지 종류가 있다.

- 제안(Offer) 내용별로는 크게 가격 할인, 가치(Value) 확대, 그리고 가격 할인과 가치 확대를 혼합한 종류 등 세가지로 구분할 수 있다.

- 형태 : 유저 컨퍼런스(User Conference), 원백(Winback), 가격 할인(Price Cut), 쿠폰(Coupon), 무료 제공(Free Offer), 시험 사용(Trial Offer), 세미나(Seminar), 번들링(Bundling)


09 인터넷 마케팅 전략 
- 80% 이상의 구매자들이 인터넷으로 기본적인 조사를 한 뒤에 제조업체를 접촉 ... 기술적 구매자들이 주로 사용하는 온라인 도구를 보면 50% 이상이 인터넷 조사의 첫 단계로 검색엔진을 사용, 32%가 제조업체의 웹사이트에서 인터넷 검색을 시작하는 것으로

- 검색엔진 마케팅을 최대한 활용

- 회사 홈페이지에 상세한 정보를 올려 놓는다. 제품 스펙 시트(Specification Sheet), 경쟁 제품 비교 자료(Comparison Sheet), 화이트 페이퍼(White Paper), 성공 사례(Case Study) 등의 자료를 빠짐없이 올려 놓고 정기적으로 업데이트해야 한다.

- 홈페이지 구축하기


10 영업 및 마케팅자료 만들기 
- 마케팅 및 영업 활동을 하기 위해 필요한 여러 가지 자료들을 가리켜 콜래트럴(Collaterals)이라고 부른다. ... 그러나 일단 특정 콜래트럴을 만들기로 의사결정을 한 이상 최대한 프로패셔널하게 만들어야 한다. 콜래트럴은 잠재고객을 대상으로 영업 및 마케팅 활동을 하는데 첫 인상을 결정 지을 수 있는 주요한 역할을 하기 때문에 디자인이나 내용, 문구나 어휘 등의 면에서 아마츄어 같은 이미지를 보여줘서는 안된다.

- 브로슈어(Brochure) : 제품의 주요 기능과 효용을 고객이 쉽게 이해할 수 있도록 만든 자료

- 성공 사례(Case Study) : 고객이 특정한 비지느시 문제를 특정 소프트웨어 제품을 사용하여 어떻게 성공적으로 해결하는 지에 대한 내용을 담고 있다. ... 작은 기업도 매년 3~6 종의 성공 사례를 제작해서 배포할 것을 권한다. ... 배포 연한은 제작일로부터 2년 이내로 제한하는 것이 좋다.

- 화이트 페이퍼(White Paper) : 제품 기술, 시장 트랜드, 그리고 고급 사용자들을 위한 개발 및 사용 이슈 등을 담는다.

- 뉴스레터, 제품 포장, 회사 소개서, 제품 비교표, 데모 CD, 리프린트, 스펙 시트, 폴더


11 다이렉트 마케팅 
- 전통적 다이렉트 마케팅 : 다이렉트 메일, 다이렉트 팩스, 뉴스페터, 텔레마케팅 및 텔레세일즈

- 전자 다이렉트 마케팅 : 이메일, 전자 뉴스레터, RSS


12 전시회 참가


13 해외 마케팅

 

* 애널리스트 대상 홍보와 광고 전략, 세일즈 프로모션, 다이렉트 마케팅과 전시회 참가, 해외 마케팅은 지금 나에게 크게 와 닿는 내용이 없어서 많은 내용을 통과했다^^

  1. 수정/삭제 답글

    비밀댓글입니다

    • Favicon of https://blog.watist.net BlogIcon 최윤호 수정/삭제

      이렇게 좋은 책이 품절이라니 아쉽네요.
      도움이 되지 못해 아쉽습니다.
      도서관에서 대출이라도 가능하길 기원합니다.

정보, 통신, 기술/읽은 것들

스크럼 - 팀의 생산성을 극대화시키는 애자일 방법론

읽은 지는 좀 됐지만, 이제 서평을 남깁니다^^ 

 

저자 : 켄 슈와버, 마이크 비들

출판사 : 인사이트

출판일 : 2008.10.03

 

- 프로젝트 관리가 문서일정 중심에서 사람기능 중심으로 옮겨 가야 한다는 의견으로, 이에 대한 백데이터 수집과 스스로 이를 실천하기 위해 이 책을 읽는다.

- 책의 내용을 부분 발췌한 것으로, 전체적인 그림을 놓칠까 걱정이 되지만, 기억을 새롭게 떠올리는 용도로^^

- 스크럽의 전반적인 설명은 위키피디아의 글이 더 좋다. 영어 두려운 마음 이해한다. 하지만, 별로 어렵지 않은 영어로 쉽게 설명되어 있다.

 

후원자를 찾으세요. 후원지는 당신을 지지하고 방어해주는 사람을 말합니다. 그는 누구나 다 알만한 업적을 가진 임원일 수도 있고, 신뢰할 만한 동료 이거나, 바로 옆에 있는 유능한 부하직원일 수도 있습니다. 중요한 것은, 그가 여러분의 시도가 외압으로 꺾이는 것을 막아주고, 필요한 자원들을 제공해주며, 정신적으로 탈진해 있을때 사기를 북돋워 준다는 점입니다.
- 좋은 동료를 위아래 관계로 더 확장하면 후원자가 되겠네요. 그래도 셋중에 가장 좋은 것은 수평적 관계에서 잘 맞는 동료이다.

 

작게 시작하세요. 할 수 있는 것부터 시작하세요. 완벽하게 하려고 미루다가 하지 않는 것 보다는 작은 거라도 일단 실천하는 게 좋습니다. 이름 없이 시작하세요. 많은 사람이 변화를 싫어합니다.
호의적인 사람들에 집중하세요. 변화에 부정적인 사람을 변화시키려고 하면, 그 사람도 괴롭고 여러분도 많은 에너지가 소모됩니다. 반면에 호의적인 사람에게 집중하면, 그 사람도 즐겁고 훨씬 적은 수고로도 성과를 낼 수 있습니다. 그리고 다른 사람들도 하나 둘씩 호의적으로 변해갈 것입니다.
- 완전 공감!! 작게, 꾸준히, 실천할 수 있는 것부터, 거창하지 않게, 호의적인 동료들과 함께 시작.

 

스크럼을 한마디로 정의하면, "피드백을 좀더 일찍, 좀 더 자주, 좀더 많이, 좀더 지속적으로 주고받자"라고 할 수 있습니다.
- 당연한 말!! 일찍!! 자주!! 많이!! 지속적으로!!

 

제조업 방식의 소프트웨어 개발기법에서는 명시적이고 반복가능한 프로세스나 조직, 개발자의 역할 규정을 통해 예측이 가능하다고 가정한다. 반면 스크럼에서는 프로세스와 조직, 그리고 개발 관련 역할들이 창발적이지만 통계적으로 예측 가능하다고 가정한다. 그리고 그러한 것들은 단순한 실천법과 패턴, 규칙을 적용할 때 생기게 된다고 가정한다.
- 경험적인 과정에서 통계적으로 예측한다.

 

 

나는 러스티에게 어떤 요청이든지 목록에 추가하라고 조언했다. 러스티는 “안 됩니다” 라고 얘기할 필요가 없었다. 대신 우선순위를 정하기만 하면 되었다. '나쁜' 아이디어란 없었다. 단지 도저히 구현될 것 같지 않은 아이디어만 있을 뿐이었다.
- 요청을 개발로 오해하지만 않는다면. 요청은 항상 그에 따른 비용과 효과 분석을 통한 우선순위가 있다는 사실을 제대로 이해할 필요가 있다. 다시 한번, "단지 도저히 구현될 것 같지 않은 아이디어". 사람들을 괴롭히는 아이디어~~

 

스프린트는 겨우 30 일밖에 되지 않기 때문에, 다들 이번 스프린트가 끝날 때까지 기다려 달라는 요구를 받아들일 수 있었다.
- 반복이 보여주는 마술이다. 이해 가능한 상황에선 누구나 합리적인 의사결정을 한다고 믿을 필요가 있다. 통제되느냐, 믿을만하냐의 문제이다.

 

나는 PNP 팀과 변화하는 요구사항 및 끊임없는 압력들 사이의 완충지대가 되었고, 팀이 스프린트의 목표달성에 집중하도록 도왔다. 내가 수행했던 역할은 나중에 스크럼 마스터(Scrum Master)라고 불리게 되었다.

 

1) 지난 일일 스크럼 회의 이후로 무엇을 했고 2) 다음 일일 스크럼 전까지 무엇을 할 계획이며 3) 무엇이 작업을 방해하고 있는가.
- 회의는 집중해서

 

제품에 원하는 기능을 어렵지 않게 추가할 수 있을 시간이 우리에게 있다면, (약간 더 무리해서) 얼마 간의 위험을 감수한다면 더 많은 기능을 추가할 수 있지 않을까? 이런 식으로 프로젝트는 서서히 미쳐 돌아가기 시작하게 된다. 우리는 감당할 수 있는 최대한의 위험을 감수하려는 경향이 있는 것이다. 제임스 배치(James Bach)
- 진지한 이야기지만 농담처럼 들리는 것은 애써 외면하고 싶은 자기보호 본능 때문일까? 개발할때 여유를 부리는 것은 쉬기 위함이 아니라, 제대로 개발하기 위함임으로 어떻게 이해시킬 수 있을까?

여유에 대한 나의 고민이 리스크 관리와 연결된다.

 

최전선의 스크럼에 속한 사람들은 하루에 한 번 만났고, 한 제품군의 각 스크럼 팀 리더들이 포함된 ‘스크럼들의 스크럼 (A Saum of Scrums)’은 한 주에 한 번 회의를 가졌다. 그리고 임원들의 스크럼은 한 달에 한번 모였다.
- 효과적인 미팅은 어느 수준에서든 가능하다.

 

나는 ADM의 개발프로세스를 각각 한달씩 걸리는 두 개의 연속적인 주기로 재구성하였다. 첫째 주기 동안 기능을 추가한다. 그 다음 주기에서는 릴리스를 준비한다. 만약 릴리스 기간 동안 시간이 남는 개발자가 있다면 다음 릴리스 주기에 추가할 다른 기능들을 작업한다.
- 규칙을 정하고 반복함으로써 숙달되게 한다.

 

그들은 내가 왜 올바르지 못한 길로 가고 있는지를 이해시키기 위해서 "프로세스 역학, 모델링과 제어(Process Dynamics, Modeling, and Control)"라는 산업 공정 제어 이론의 필독 서를 권했다.
- 번역된 것은 없는 거... orz...

 

팀은 제품 백로그의 분량을 결정하고, 스프린트 목표를 수립한다. 대부분의 개발 프로세스에서는 관리자가 각 팀원에게 무엇을 언제까지 해야 한다고 지시한다. 이런 방식으로 어떻게 관리자가팀의 헌신을 이끌어낼 수 있을까? 스크럼에서는 어떤 제3자도 팀원이나 팀에게 이래라 저래라 할 수 없다.
- 당연한 책임은 참여와 권한에서 나온다. 책임감 있는 사람을 구할 수도 있겠지만, 책임감을 느끼게 하는 방법도 있다.

 

팀은 스프린트 목표 달성을 위해 필요한 태스크들의 목록을 작성한다. 이 작업들은 제품 백로그를 작동하는 소프트웨어로 변환하는데 필요한 태스크들의 상세한 목록이다. 각 태스크는 대략 4시간에서 16시간안에 완료할 수 있을 만큼 충분히 자세하게 명시되어 있어야 한다. 이 태스크 목록을 스프린트 백로그라고 부른다. 팀은 스프린트 백로그에서 자신이 할 태스크를 스스로 선택하고 결정한다.
- 제품 백로그와 스프린트 백로그


스프린트 검토 회의는 개발 업무의 일환이다. 누구나 질문하고, 관찰하고, 토론하고 제안할 수 있으며, 그렇게 하도록 장려된다. 만약 타협을 많이 해야 한다면 그렇게 하라. 이 회의는 비평을 하거나 어떤 행동을 취하기 위한 것이 아니라 정보 교환을 위한 것이라는 점을 명심해야 한다. 참석한 모든 사람들이 이번 제품 증분을 이해하는 것이 가장 중요하다. 이 정보가 다음 스프린트 계획 회의의 토대가 되기 때문이다.
- 스프린트 검토 회의의 목적

 

나는 관리자와의 토론에서 줄곧 경험주의적인 접근법을 옹호해 왔다. 미리 모델링할지 여부를 선택에 맡겼을 때 팀의 생산성이 올라가는가? 그렇다면 개발자가 생각을 정리하는 용도 정도로만 모델링을 쓰게 하라. 코드의 품질이 모델링을 강제했을 때보다 많이 떨어지는가? 그렇다면 품질이 중요한 부분을 작업할 때에는 모델링을 필수적으로 하게 하라.
- 경험주의적 접근법 사용 예

 

몇 가지 빽로그 그래프. 어떤 경우든 변경하는 타겟을 동적으로 쫓아야 한다.

 

 

팀은 스크럼 회의를 통해 단순한 정보 공유 이상의 것을 얻을 수 있습니다. 사람들은 이 회의에서 단순히 어제 무엇을 했는지에 대해서만 얘기하는 것이 아닙니다. 모든 사람 앞에서 말함으로써 다른 사람이 무엇을 하고 있는지를 모두 알게 되고 나중에 도움을 줄 수도 있습니다. 또한 현재 문제가 무엇인지를 얘기하는 데 그치지 않고 문제를 관리자와 얼굴을 마주보며 얘기할 수 있습니다. 사람들이 정직할 수 있게 용기를 줍니다. 또한 지금 겪고 있는 문제를 관리자가 해결하도록 압박할 수 있습니다. 그리고 무엇보다도, 이 회의는 서로가 서로에게 다음에 무엇을 할 것인지 약속하게 합니다. 이는 사람들의 신용과 믿음을 모두 시험 받도록 합니다. 스크럼은 팀원들 간에 신뢰를 구축하게 해 주는 높은 수준의 사회적 상호작용입니다.
- 믿고 따르는 느낌으로 그대로 한번 해 보고 싶다.

 

무엇보다도 소프트웨어 개발을 제조업으로 생각하고 그쪽에서 비슷한 프로세스를가져온 것이 큰 실수였다.
제조업에서는 라디오, 자동차나 비행기 같은 똑같은 모델을 계속해서 조립한다. 하지만 소프트웨어 개발은 뭔가 새로운 걸 만들어 내는 과정인데, 비록 소프트웨어의 일부분이 재사용 된다곤 하지만, 매번 형태나 설계가 달라지기 때문이다. 예를들어, 어떤 라이브러리나 컴포넌트를 애플리케이션 개발에 사용하는 경우를 생각해 보자. 컴포넌트의 인자 값은 사용할 때마다 달라지고 몇몇 기능은 오버라이딩(ovenide)되기 마련이다.
- 소프트웨어 개발은 매 개발개발이 매번 새로움이다. 단 한번도 반복되는 경우는 없다.

 

아키텍처 팀과 두 번째 애플리케이션 팀을 하나의 팀이라고 생각하라. 그리고 제품의 출시에만 집중하라.
사용될지 안될지도 모르는 '재사용 가능한 일반적인 서비스'는 더이상 신경 쓰지 말고, 두 번째 애플리케이션에서 꼭 필요한 서비스 개발에만 집중하라.
- 항상 전체 그림만 고민하느라 정작 코딩을 하지 못 하는 상황을 피해야겠다. 일단 작업하고 생각은 딱 작업에 필요한만큼만 과하지 않게 해라.

 

정보, 통신, 기술/읽은 것들

[서평] Head First Software Development

Head First Software Development
2011-11-02
댄 필로네 지음,  황상철 옮김, 한빛미디어

Head First는 Design Patterns 보고, 두번째 입니다. Head First Java는 구매만 하고 보질 않았네요. Head First는 설명이 필요 없을 정도로 유명하고, 좋은 시리즈입니다. HFSD도 명성에 걸맞는 내용입니다.

Software Development는 사실 한권에 담기 어려운 큰 주제입니다. 이 책은 Agail 방법론에 기반해 소프트웨어 개발을 어떻게 관리할 것인가에 대한 전체적인 그림과 세세한 사항을 짚어줍니다. 자바때문에 약간 덜그럭 거리는 부분은 있지만, 분량도 그리 많지 않아 가벼운 마음으로 빠르게 읽기 좋습니다.

이렇게 함부로 정리해도 될지 모르겠지만, 내용을 간단히 요약하면 1) 사용자의 요구사항을 수집해서, 2) 사용자 스토리로 정리합니다. 3) 이를 태스크로 만들고 4) "충분히" 좋은 설계를 한 후에 5) 버전 관리, 6) 빌드 관리, 7) 테스트 관리 등의 기법을 사용해 8) 개발을 합니다. 그리고 이 모든 것은 9) 20일, 한달 가량의 이터레이션으로 묶어 계속 반복한다는 내용입니다^^
저는 "커다란 현황판"이 가장 마음에 와 닿네요.

* 이터레이션으로 목표 달성하기
- 이터레이션이 없는 경우 : 문제와 가정이 생길때마다 프로젝트는 점점 목표와 멀어져 고객이 바라는 모습이 아닌 결과물이 나옵니다.
- 이터레이션이 있는 경우 : 문제가 생겨도, 고객의 생각이 바뀌어도, 중간중간에 고객의 피드백을 받아 수정해가면서 진행하기 때문에 고객이 원하는 결과를 만듭니다.

* 각 이터레이션은 작은 프로젝트와 같고, 요구사항 > 설계 > 코드 > 테스트 > 피드백을 계속 반복합니다. 즉 각 이터레이션은 품질 좋은 소프트웨어입니다.

* 고객 요구사항을 알기 위해서는 크게 생각해야 합니다. 개별적으로 브레인스토밍을 한 다음 모여서 다시 좀 더 브레인스토밍을 합니다. 떨어져서 무슨 일이 일어날지 생각해 보고 돌아와서 다 같이 두번째 미팅을 합니다. 혹은 역할극을 하고, 사용자들 관찰하는 방법으로 고객의 요구사항을 알아냅니다.
하늘은 한계가 없기 때문에 요구사항을 받을 때도 블루스카이를 한다고 생각하세요. 그렇게 고객에게 더 많은 정보를 달라고 말합니다.

* 사용자 스토리가 정리되면 계획 포커 게임을 합니다. 개발자들이 각 스토리에 대해 예상되는 일수를 카드로 제시하고, 그렇게 생각한 이유를 설명하면서 서로간의 합의 가능한 추정치를 찾아갑니다.
너무 동떨어진 추정치에서 많은 사람이 놓치고 있는 가정이 나올 수도 있습니다. 또, 모두의 추정치가 비슷해도 서로가 생각하는 바를 이야기합니다. 추정치가 너무 크다면, 스토리를 나눌 수 있는지 확인합니다.
가정에 대해 가정을 하지 마세요. 모든 것을 이야기해야 합니다.

* 스토리에 우선순위를 부여하고, 선행 작업을 확인합니다. 이렇게 스토리에 우선순위와 추정치가 결정되면, 20일 기준으로 팀에서 할 수 있는 만큼의 스토리를 선택해 이터레이션들을 구성합니다. 그리고 첫번째 이터레이션을 진행합니다. 이때 팀의 개발 속도는 0.7로 고려해서 시행착오에 대비합니다.

* 이터레이션으로 계획이 세워지면, "피곤하게 하는" 혹은 "동정의 여지가 없는" 고객을 다루어야 합니다. 이터레이션 계획을 설명하고, 범위를 벗어나는 사용자 스토리는 없어지는 게 아니라 연기하는 것뿐임을 설명합니다. 구체적으로 수치가 어떻게 나왔는지를 설명합니다.

* 벽에 "커다란 현황판"을 만드세요.(이건 정말 해 보고 싶어요!!!)
한쪽에는 처리할 사용자 스토리가, 가운데는 처리 중인 스토리의 태스크가, 다른 한쪽에는 소멸 그래프와, 다음 이터레이션으로 넘어갈 스토리, 그리고 완료된 스토리를 놓은 큰 현황판입니다. 
현황판을 직접 적용해서 친절하게 사진까지 올려주신 블로거가 있습니다. 꼭 한번 방문해 보세요.
커다란 현황판 : http://mckdh.net/353

* 일은 스토리에서 태스크를 확정하는 것으로 시작합니다. 태스크는 개발자에게 할당되어 개발이 시작됩니다. 그리고 매일 간단한 미팅을 위해 "스탠드업" 미팅을 진행합니다.
이 모든 작업이 일을 줄여주지는 않습니다. 하지만 우리가 어디에 있는지를 "정확히" 알고 있습니다. 더욱이 고객도 우리가 어디에 있는지 알고 있습니다.

* 충분히 구현 가능한 좋은 설계와 안전한 개발을 위한 버전 관리, 작성한 코드 빌드하기, 그리고 테스트와 지속적인 통합은 가볍게(?) 넘어갑니다.

* 이터레이션에서 위의 방법을 통해 할 수 있는 일은 고객 주도적 기능, 코드 컴파일, 감시되는 빌드, 지속적으로 테스트된 코드, 견고한 테스트 커버리지, 믿을 수 있는 진행상태 추적, 팀에 알맞는 속도로 나아가기 등입니다. 이제는 테스트팀의 테스트와 여기서 발견된 버그를 수정합니다.
버그까지 마무리가되면 이터레이션을 마무리하고, 첫번째 버전을 정식으로 배포합니다. 그리고 이터레이션 마지막날 이터레이션 리뷰를 진행합니다. 이번 이터레이션이 어떻게 진행되어 왔는지를 느낀 점을 서로 전달하는 시간입니다. 진취적인 자세를 취하고, 속도와 범위를 파악해서 지표를 계산합니다. 이제 잠시 휴식을 취하며, 훈련이나 교육을 위한 시간을 갖거나, 다음 이터레이션을 위한 프로토타입을 만들어 보세요.

* 작동하는 소프트웨어는 이터레이션을 마쳐야 하고, 테스트를 다 통과해야 하며, 고객이 만족해야 합니다.
우리가 개발하지 않은 코드, 라이브러리, 혹은 프로그램이 만약 그것이 우리의 소프트웨어에 적용된다면 이제는 우리의 책임입니다. 외부 업체와 다른 사람이 우리의 프로세스를 따르리라고 가정하면 안 됩니다. 적용된 코드, 라이브러리, 프로그램을 우리의 시스템에 넣고, 우리가 코드를 만든 방식 그대로 관리합니다.

* 소프트웨어 개발 프로세스를 명확히 합니다. 좋은 프로세스가 좋은 소프트웨어를 만듭니다.
현황판, 사용자 스토리, 버전 관리, 지속적인 통합, 테스트 주도 개발, 테스트 커버리지를 사용합니다.

  [ 1 ]  

카운터

Today : 9
Yesterday : 53
Total : 353,061

Site

Copyright (c) 2016 최윤호. All Rights Reserved.
Powered by Tistory. Skin by wallel.
Subscribe Rss Feed