[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

레이블이 agile korea인 게시물을 표시합니다. 모든 게시물 표시
레이블이 agile korea인 게시물을 표시합니다. 모든 게시물 표시

2016년 4월 28일 목요일

[EP] Agile Korea 2012 #2..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

개인이 조직을 바꾸는 법 - 김창준
시작하면서  "조직장등이 아닌데 TDD를 팀에 도입하려고 하는 경우 한두달 정도 TDD에 대해서 공부를 한다"에 동의하는 사람이 손들어보라고 하시고는 여기에 손드는 사람은 이 발표가 도움이 될꺼라고 하셨다. 리스크라는 말이 있고 또 불확실성(uncertainity)이란 말이 있다. 리스크가 있는 상황은 여러 상황에 대한 대안이 있고 각각의 경우에 확률이 존재하는 경우고 불확실성은 상황에 대한 경우의 수도 모르고 그에 대한 확률도 모른다. 리스크에 대한 대처가 도움이 되는 대표적인 경우는 도박인데 현실에서는 불확실성의 경우가 훨씬 더 많다. 리스크 대처방안은 많이 존재하지만 리스크 대처방안을 불확실성에 적용해도 잘 안되기 때문에 불확실성에 맞는 대처방안이 따로 필요하지 않은가 하는 고민을 하기 시작했다.

그래서 실험을 진행했는데 10여개정도의 창업을 해본 창업자들과 MBA를 졸업한 사람을들 모아놓고 어떤 상황을 주고 선택을 하라고 하니까 창업자들과 MBA 졸업자들이 완전히 반대의 선택을 했고 창업자들과 포츈 100대 기업의 매니저들과 비교했을 때도 서로 반대의 선택을 했다. 이는 대기업은 안정적이기 때문에 리스크가 있는 상황에 비해 불확실성의 상황이 훨씬 적기 때문이다. 개인이나 조직에서도 불확실성의 경우가 훨씬 많고 성공한 중간 관리자들을 조사했을 때는 대부분 창업자들과 같은 전략을 취하고 있었다. 이 전략을 다음의 5가지로 정리했다.

  • Bird in Hand Principle : 지금 손안에 있는것 부터 시작한다는 의미로 방법중심인가 목표중심인가를 얘기한다. MBA은 좋은 목표를 정하고 가용한 방법 중에서 선택하지만 창업자들은 현재 가지고 있는 방법들을 가지고 무엇을 할 수 있는지를 결정한다. 예측가능한 경우에는 목표중심이 낫다. 앞에서 얘기한 TDD 도입은 목표중심이기 때문에 실패할 가능성이 높고 아는 것을 중신으로 해낼 수 있는 것을 생각하는 것이 좋다.
  • Crazy-Quilt Principle : 불확실할수록 사람을 끌여들여서 내편으로 만드는 것이 좋다. TDD를 도입하려고 한다면 사람을 모아서 같이 스터디를 하는 것이 좋다. 앞에서 얘기했듯이 혼자만 먼저 공부를 한다면 공부한뒤에 불리한 위치가 되기 쉽다. 여기서 불리한 위치라는 것은 먼저 공부했으므로 가르치는 위치가 되기 싶고 다른 사람들은 잘아는 사람이 옆에 있으므로 수동적이 되기 쉽다. 이런 경우는 대부분 실패한다.
  • Affordable Loss Principle : 감당할 수 있는 즉 잃을 수 있는 양을 정해놓고 그 안에서만 움직인다. 불확실한 상황속에서는 오래 살아남아야 하고 더 다양하게 선택할 수 있기 때문에 자신이 잃을 수 있는 양을 정해놔야 한다.
  • Pilot in the Plane Principle : 이는 비행기안에 조종사를 비유한 것인데 비행에서는 예측불가능한 상황이 많이 발생할 수 있지만 자동에 의존하지 않고 항상 파일롯이 비행기에 있는데 이는 예측을 할 수는 없지만 제어는 할 수 있다는 의미이다.
  • Lemonade Principle : 이는 레몬을 주면 레모네이드를 만들라는 의미이다. 뭔가가 주어졌을 때는(심지어 공격을 단하거나 피해의 상황이라고 할지라도) 그것을 이용한다.
이러한 전략을 조직을 바꿀때도 적용할 수 있다고 본다. 보통 애자일등을 조직내에 도입하려고 하는 사람이 오히려 변화할 수 없는 전략을 취하는 경우가 많다.

이번 세션도 10여분 정도의 짧은 세션이었다. 리스크의 상황과 불확실성의 상황을 따로 구분해서 생각해 보지는 않았기 때문에 꽤 인상적이었고(맨 처음에 손들어 보라고 할때 난 손을 들었다 ㅠㅠ) 나는 새로운 기술이나 방법론(혹은 새로운 서비스) 등에 관심이 많기 때문에 생각해 볼 여지가 많이 있었다. 한편으로는 항상 느끼는 거지만 김창준님은 이런 걸 어디서 어떻게 알아낼까 궁금하다.

유니콘 목장(The Unicorn Ranch) - 정기원
정기원님은 LAB80이라는 마이클이라는 개발자와 창업을 했고 디자이너로 국내에서 스타트업을 하면서 좋은 인재(이 발표에서는 유니콘형 인재라고 부른다.)를 찾다가 절망한 경험을 나누고 조언도 받기 위한 자리였다. 어떤 재능이 다른 재능보다 더 가치가 있는가? 하는 생각은 처음부터 어떤 재능이 다른 재능보다 낫다는 것을 전제하고 있다. 먼저 역사를 살펴보면 가로축을 여러가지 다른 분야로 나열하고 세로축을 그 분야를 위해서 필요한 것들로 나열했을 때 과거에는 수직으로만 움직이다가 르네상스 시대에는 수평축으로 여러 영역에 걸쳐서 활동했지만 산업혁명 이후에는 다시 수직적으로만 움직이고 있었다. 하지만 이제 다시 수평적으로 움직이려고 하고 있는데 이렇게 수평적으로 영역을 넓히는 사람을 보통 제너럴리스트라고 부르지만 여기서 말하려는 유니콘은 제너럴리스트과는 다르다.

그럼 유니콘은 무엇인가? 유니콘은 T자형 인재처럼 자신의 깊게 아는 영역이 있지만 그 외의 수평적으로도 넓게 알고 있으면서 각 역을 깊게도 알고 있는 사람을 유니콘이라고 부르고 스타트업에서는 이렇게 혼자서 다양한 영역을 커버할 수 있는 사람을 찾는다. 수평적이라고 함은 다른 영역의 사람과도 공감할 수 있는 사람을 의미한다. 유니콘을 T자형 인재보다 상위레벨로 보는데 피라미드 구조이기 때문에 유니콘은 많지 않지만 유니콘이 주는 가치는 엄청나다. 여기서 유니콘이라 함은 이미 유니콘인 사람과 현재는 T자형 인재이지만 유니콘으로 가기 위해서 노력하는 사람들을 의미한다. 현재 실리콘밸리의 구인광고를 보면 다양한 분야에 대해서 전문성을 가진 유니콘을 찾고 있는데 왜 다들 이렇게 유니콘을 찾는지를 이해하려면 지난 10년간 성공한 사람들을 살펴봐야 한다. 대표적인 대기업외에도 37signals53등의 회사등이 있는데 이러한 회사를 만들거나 합류한 사람들의 특성을 다음과 같이 정리할 수 있다.

  • Love your problem : 스스로 해결하고 싶은 문제를 푼다.(자신이 가려운 부분을 긁는다.)
  • Love your customers : 자신과 동일한 가려움이 있는 사람들이 있어야 한다.
  • Make Opinionated product : 가치관이 있는 제품을 만든다.
  • Cross-function : 하던 것만 반복해서는 이미 존재하는 것밖에 할수 없고 해보지 않은 다양한 분야를 해봐야 한다.
  • Learn Quickly : 이렇게 하려면 책이나 교과서를 읽고 할 시간이 없고 다른 사람들과 직접 해보거나 물어보면서 빨리 배울 수 있어야 한다.
  • Momentum-sensitive : 무엇이든 기세가 오를때가 있고 쳐질때가 있는데 이런 부분에 대한 감을 가지고 실제 제품에 적용해서 해결할 수 있어야 한다.
  • Quick Decisions : 스스로 결졍을 빨리 해야 한다.
  • Good communicator : 이렇게 하는 사람이 소통을 못할리가 없다. 빨리 배우고 찾는 사람은 자연히 소통을 잘하게 된다. 말을 잘하고 글을 잘 쓴다는 것은 생각이 간결하다는 의미고 이런 사람이 코드도 잘짜고 디자인도 잘한다.
유니콘은 경력이 아닌 세상을 바꾸고 개선하겠다는 태도에 달려있다. 이 유니콘들은 갑자기 생겨난게 아니라 사회에 대한 이해가 있는 사람들이고 이런 부분을 일일이 설명하거나 가르칠 필요가 없이 스스로 자기계발하고 혁신을 하고자 하고 빨리 배우면서 문제를 해결하고 모호함을 다룰 수 있는 사람들이다. 이 유니콘들은 만들 수 있는게 아니다. 즉, "요즘 이게 대세래. 우리도 다같이 유니콘이 되자"해서 되는게 아니다.


정기원님과 마이클은 자신들이 유니콘이라고 소개하셨고 유니콘들이 많은 IDEO, MIT 미디어 랩, 마이크로소프트 리서치등에서 일하다가 현재 LAB80을 서울에서 창업했다. 작년에 1년정도 세계를 돌면서 세계 각지에서 프로토타이핑을 해보다가 현재는 한국에 정착해 있다. 유니콘 목장들이 운영하는 방식은 대개 비슷한데 공통의 목표와 언어를 가지고 기본적인 구조와 프로세스를 정하는 환경을 조정하는 단계로 목표는 어디로 달릴지 방향을 정하는 것이다. 그리고 그 다음에는 각자 앞에서 정한 목표를 향해서 달린다. 이게 전부다. 국내에서 이러한 유니콘을 찾으려고 노력했지만 현재는 실패했고 유니콘이 없는 것인가 하는 절망에 빠져있다. 주니어를 뽑으려고 할 때 대부분 이들이 가장 싫어하는 3가지 말을 많이 했는데 스타트업에서 경력을 쌓아서 대기업으로 갈 것이라는 말과 새로운 것을 해야할 때 꼭 책으로 배우려는 것과 모르는 것을 물으면 대답을 회피하는 것이다.

인상적인 것으로 따지면 애자일 코리아에서 가장 인상적인 세션이었다. 이 세션을 들은 사람들은 대부분 비슷한 느낌을 받지 않았나 싶은데 "우린 유니콘인데 한국엔 유니콘 혹은 유니콘의 자질을 갖춘 사람이 없어"라는 약간 도발적인 말에 욱하는 억울함과 여러모로 매력적인 요소를 가진 LAB80에 대한 흥미일 것이다.(사실 이 욱하는 억울함은 금새 사라졌다.) 의도적인지 유하게 전달하는게 부족했는지는 모르지만 일단 정기원님의 목적은 어디서 유니콘을 찾을 수 있는지 혹은 어떻게 해야하는지 조언을 받고자 함이었고 많은 사람들이 이런 저런 얘기를 해주었다. 여러 얘기가 있었지만 LAB80이 아직 브랜딩이 제대로 안되어 있으므로 유니콘들이 관심을 가질 기회조차 없다는 것이었다. 그리고 쥬니어들을 뽑기 위한 과정에 대해서는 황상철님이 가르치는 방법이 잘못되지 않았는 생각해 볼 필요가 있다면서 당구도 300한테 배우는 것보다는 80한테 배우는게 낫다.라는 예를 드셨는데 귀에 쏙쏙 들어왔다.

나는 유니콘이라는 말을 여기서 처음 들어봤지만 인재형 자체는 내가 추구하는 인재형과 비슷하다.(내가 유니콘이라는 건 아니고..) 사실 듣고나서도 제너럴리스트와 유니콘과의 구분이 정확히 되지 않고 개발자인 내가 디자인, 마케팅 이런 부분까지 아울러야 한다는 건지 한 기술만 파지말고 다양한 기술을 파야 되는건지 좀 헷갈리기도 했다. 어쨌든 상당히 흥미가 가서 세션이 끝나고 나서 BOF에서도 정기원님 테이블에 가서 이런저런 얘기를 나누었지만 주로 유니콘을 어디서 찾아야 하는지 조언을 해드렸던것 같다.

Ephilogue
행사장인 전문 세미나 장이 아니라 MS의 세미나실이라서 약간 좁기는 했지만 이래저래 준비를 많이 하신 느낌이 많이 들었다. 작년에는 없던 로고부터 해서 중간 참석자네트워크에서 사용되는 고무팔찌에 음료수등의 간식이 들어있는 깨알같은 웰컴팩까지... 운영을 사실 불편하게 느끼지 않는다면 잘 느껴지지 않는데 자원활동가도 많아서인지 컨퍼런스는 부드럽게 잘 운영이 된것 같고 찬찬히 컨퍼런스를 보면 여러가지로 신경을 많이 쓴 티가 나는 컨퍼런스였다.


이번 컨퍼런스는 세션들이 전체적으로 흡족한 편이긴 했는데 또 막상 끝나고 생각해 보니 딱히 애자일에 대해서 많은 느낌을 받지 않았던 것 같다는 생각이 좀 들었다. 물론 이는 내가 세션 선택을 그런쪽으로 해서인지도 모르겠고 이번에는 스타트업 세션들이 포함되어서 좀 영역을 넓히려는 노력을 한게 아닐까 싶다. 애자일은 방법론(태도라고 해야하나?)에 관한 것이기 때문에 자바컨퍼런스나 루비컨퍼런스등에 비한다면 한가지 색을 가지기 어려운 면도 있지만 좀더 애자일적인 색체가 더 많이 묻어났으면 혹은 애자일 전파에 대해서 좀더 고민해 보는 자리였으면 하는 아쉬움이 있었다.(말했듯이 이는 내 세션선택의 따른 결과일 수도 있다.) 뭐 애자일 설명을 하고 그러면 너무 기초적인 내용이라 컨퍼런스에 참석한 사람에게는 지루할 수도 있으므로 어려운 문제라고는 생각한다.

아무튼 좋은 컨퍼런스를 단돈 몇만원에 참석해서 좋은 내용을 들어서 만족스럽다. 준비해주신 모든 분들께 감사의 말씀을 드리고 싶다. ㅎㅎ



[EP] Agile Korea 2012 #1..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

작년에 1회로 시작한 애자일 코리아 2012가 지난 토요일(1일)에 열렸다. 작년에도 가고 싶었지만 같은날 여러 컨퍼런스가 겹쳐서 참석못했는데 이번에는 참여를 했다. 이번 애자일 코리아는 포스코센터에 있는 마이크로 소프트의 세미나실에서 개최되고 프로그램은 다음과 같다.
사용자 삽입 이미지


(페르소나와 커뮤니케이션으로 풀어보는) 애자일을 실천하는 사람들이 겪는 어려움 - 최보나
작년 xper에서 활동도 많이 하시고 ThoughtWorks에서 일하시는 Analyst로 일하시는 최보나님의 세션이었고 (자기 소개하실때 소트웍스의 발음이 확 굴러가서 다른 회사인줄 알았;; 참고로 소트웍스는 마틴 파울러가 있는 회사다.) 커뮤니케이션에 대한 이야기였다. 시작할 때 T자형 인재와 A자형 인재에 대한 이야기로 시작하셨는데 T자형은 도요타에서 제시한 인재유형으로 익히 알다시피 하나에 깊은 지식을 가지고 있고 넓은 상식을 가지고 있는 인재형이고 A자형 인재는 T자형 인재유형에서 다른 사람들을 융합해 주는 커뮤니케이션 능력을 가진 인재유형을 말한다. 다음은 애자일 선언이다.

  • 프로세스나 도구에 앞서 개인과 상호작용을
  • 포괄적인 문서화에 앞서 작동하는 소프트웨어를
  • 계약 협상에 앞서 고객과의 협력을
  • 계획준수에 앞서 변화에 대한 대응을
여기서 관심가져야 하는 것은 상호작용이다. 상호작용을 잘하려면 어떻게 해야 하는가가 문제인데 커뮤니케이션이 답이라고 하셨다. 애자일을 하는 사람이라고 하면 항상 어떻게 하면 지금보다 더 나아질 수 있을까를 고민하고 해결해 나가는 사람이라고 생각한다. 그래서 애자일 프로세스를 적용해서 일하더라도 이러한 고민과 해결이 없으면 애자일이라고 부를 수 없다. 일을 할 때 다양한 역할의 사람들이 모여서 일을 하므로 다양한 커뮤니케이션이 필요해진다. 더군다나 이제는 한 조직 혹은 한 공간내의 사람들과 일하는 환경이 점점 적어지고 다양한 조직과 다양한 위치의 사람과 일을 하는 곳이 많아지고 있다. 이런 가운데 원활한 커뮤니케이션을 해야만 "동작하는 소프트웨어"를 만들 수 있다. 커퓨니케이션을 통해 해결해 가는 과정을 설명하기 위해 실제 소트웍스에서 있었던 사례를 중심으로 설명하셨다.

사례 1
신페이는 15명 팀에서 일하며 팀원들의 애자일 경험년수의 평균이 5년정도 된다. 팀원들은 개인역량이 뛰어나고 자기조직화가 잘되어 있어서 문제가 없을 줄 알았는데 신페이는 "이 프로젝트가 어디로 가고 있는가?"라는 고민을 시작했다. Analyst
[Analyst라는 역할이 국내에는 없기 때문에 정확히 이해는 안가지만 다른 분께 물어본바에 의하면 고객의 요구사항을 분석해주는 사람이라고 한다. 팀의 업무와 고객을 연결해주는 역할이 아닌가 싶다.]인 신페이는 각 팀원들이 정확히 무슨 일을 하고 있는지 알고 있지 못했다. 이를 해결해 주는 것이 1일 스크럼인데 각 팀원들이 각자 잘하다보니 스크럼은 뻔한 회의가 되었고 지루하고 의미없는 회의가 되어 그 중요성이 사라져 버렸다. 그래서 시각적인 회의를 도입해서 팀원들이 원형으로 앉아있는 것이 아니라 화이트보드를 바라보고 화이트보드에 스토리보드등 내용을 적어서 참여도와 집중도를 높였다. (시각적인) 커뮤니케이션이 답니다.

사례 2
필 클락은 미국과 인도로 나누어진 30명 정도의 팀에서 일하는데 여기에는 3개의 회사가 속해있고 팀원들은 애자일 경험도 별로 없었다. 이 팀의 문제는 사람들이 말이 안통한다는 것이었다.(언어가 다르다는 얘기는 아니다.) 비즈니스 하는 사람들이 하는 말을 기술자들이 제대로 이해못해서 결과물이 다르게 나오는게 문제였기 때문에 "테크니컬한 사람과 비즈니스하는 사람이 어떻게 소통할 수 있을까?"를 고민하기 시작했다. 그래서 BDD와 Cucumber를 팀내에 도입해서 비즈니스를 하는 사람들이 테스트와 인수테스트를 작성하도록 해서 개발자들이 완료의 기준을 정확히 잡을 수 있도록 했다. (도구를 이용한) 커뮤니케이션이 답이다.

사례 3
지납 난디는 10명 정도의 팀에서 애자일을 경험한 평균은 2-3년정도가 되는데 이 팀에는 소위 수퍼개발자라고 하는 사람들이 몇명있어서 문제가 생기면 누구나 이사람들에게 물어봐서 해결을 한다. 하지만 지납 난디는 이 수퍼개발자들이 오히려 고민거리가 되었는데 이 팀에서는 1일 스크럼 이후에 그날 누구랑 페어 프로그래밍을 할지를 추첨식으로 정해서 같은 사람과 계속 페어프로그래밍을 하지 않도록 하고 있었다. 수퍼개발자와 페어프로그래밍을 하게 되면 잘하는 개발자들이 그렇듯이 무수한 단축키로 빠르게 개발하면서 설명도 자세하게 하지 않기 때문에 오히려 더 어렵고 그 수준차이가 너무나서 오히려 자괴감이 들게 되어서 당일날 페어 프로그래밍의 짝을 선정하는 과정이 두렵게 느껴지기 시작했다. 그래서 이 팀에서는 일일 스크럽 이후에 1:1 피드백을 도입해서 매일 1:1로 커피먹으러 나가서 회고를 하도록 했다. 지납 난디와 같은 생각을 하던 사람들이 여럿이 있었기 때문에 이에 대한 얘기를 들은 수퍼개발자는 변하기 시작해서 설명도 자세히 해주고 페어프로그래밍에서 키보드도 다른 사람에게 내어주기 시작했다. (personal한 환경에서 하는) 커뮤니케이션이 답니다.

어려움에 부딪혔을 때는 문제의 답이 커뮤니케이션이 아닐까 고민해 봐야 한다. 보통 애자일을 도입하거나 프로세스를 확 바꾸는 것을 시도하기 쉬운데 의외로 많은 문제는 커뮤니케이션에 있고 이를 통해서 해결할 수 있다.

최보나님의 발표는 무난한 느낌이었다. 중요한 혹은 핵심적인 내용이 이런 경우가 많은데 너무 중요한 한편으로는 또 너무 뻔하기 때문에 어떤 임팩트를 주기는 어렵다. 자칫 지루하고 뻔할 수 있는 주제를 사례를 들어서 설명해서 흥미롭게 들을 수 있었다. 누구나 커뮤니케이션이 중요하다는 건 당연히 인지하고 있지만 의외로 또 쉽게 잊을 수 있는 부분이기도 하다. 사례처럼 간단히 문제가 해결되지는 않겠지만 그 과정자체가 커뮤니케이션인거니까... 다른 내용보다도 애자일 하는 사람은 지속적으로 개선하는 사람이라는 말이 인상적!

Lean Startup in Practice - 정지웅
클럽배닛의 CEO이신 정지웅님이 린 스타트업을 자사에 적용한 경험담을 나누어 주셨다. Eric Ries스타트업을 세상에 존재하는 문제를 해결해서 사업화하기 위한 특수한 목적을 가진 조직이라고 정의했고 스타트업은 그 반응을 증명하기 전에는 회사라고 부르기도 어렵다. 다시 말하면 불확실성속에서 많은 위험요인을 감수하고 세상에 존재하는 문제를 보다 명확히하고 그에 대한 해답을 찾아 시장과 고객앞에서 증명해내는 조직이라고 할 수 있다. 그래서 스타트업은 불확실성에 관한 것이고 새로운 실험적인 방법을 시도해 봐야하고 90%이상의 스타트업은 실제로 실패한다. 그럼 왜 실패하는가?가가 문제인데 대부분의 스타트업은 다음의 문제-해답-비용-타이밍의 4가지 요소에서 확실성을 확보하기 전에 모든 자원을 잃고 소멸되게 된다.

  1. 고객이 원하는 진짜 문제를 찾아내지 못함.
  2. 진짜 문제를 찾았더라도 그에 맞는 해답을 찾아내지 못함.
  3. 진짜 해답을 찾았더라도 그 해답을 증명하기 위해 너무 많은 비용을 소모.
  4. 많은 비용이 뒷받침되더라도 많은 시간을 소요해서 시장의 상황이 달라지면 문제와 해답은 모두 무효가 됨.
Frederick Winslow Taylor는 예상되는 문제를 모두 통제해야 한다고 했지만 예상할 수 없기 때문에 문제도 정의할 수 없다는 것이 문제다. 그래서 빠른 Pivot을 통해서 실패의 간격을 줄여간다면(주어진 자원과 금전이 모두 떨어지기 전에) 성공의 확률을 조금씩 올릴 수 있다는 것이 린스타트업이다. 대부분의 성공한 스타트업들은 최초 만들려던 것이 아닌 Pivot으로 전환한 제품을 통해서 성공을 이루어 냈다. 린스타트업의 원리는 이제 실리콘밸리에서 스타트업 기업의 경영기법과 철학으로 보편화되었고 Eric Ries는 IMVU의 창업자로 본인의 경험을 통해 린 스타트업이라는 개념을 만들어냈다. 린 스타트업은 더 적은 비용으로 자주 실패해서 결국 시장과 고객의 요구를 해결하는 것이 신규 사업이나 신규 서비스의 성공확률을 높이는 경영 및 프로덕트 개발방법이다.

폭포수 방법은 문제와 해결방법이 명확한 경우에 좋다. 정지웅님이 스타트업을 시작하면서 처음에는 1forMe라는 서비스를 만들었다 1forMe는 Etsy의 카피캣으로 핸드메이드 셀러마켓이었는데 핸드메이드를 하는 사람들이 다들 좋다고 해서 금새 셀러들을 모았는데 오픈하고 나니 국내에서는 핸드메이스 시장이 작어서 고객이 없었다. 이 문제를 못보고 폭포수 방법론으로 개발해서 런칭까지 한 후에 문제를 발견하고도 해결하는 대신 사이트를 리뉴얼 했었다. 두번째는 Torsto라는 서비스였는데 파워블로그들의 공동구매를 플랫폼화한 서비스로 이미 존재하는 문제를 비즈니스모델로 만들었다. 반응도 좋아서 오픈 첫날 매출이 천만원이나 찍었었지만 이제 사람들이 블로그의 공동구배를 믿지 않게 되는 분위기라 시장의 타이밍이 좋지 았았다. 하지만 pivot을 하지 않고 활성화를 해볼려고 폭포수 프로세스로 밀어붙였고 더이상 성장하지는 못하고 다른 서비스로 확장할 수 있는 모델도 아니었다.


애자일 방법론은 고객이 자신들이 원하는 것을 제대로 설명을 못하기 때문에 개발프로세스를 짧게 반복하면서 고객이 진정 원하는 것을 찾아내는 과정이다. 이와 비슷하게 린 스타트업은 불확실한 문제를 점진적으로 검증하면서 그에 맞는 해결책을 함께 만들어나가는 비즈니스 방법론으로 시장조사에 기초해서 애자일 프로세스를 적용하고 시장소자 데이터나 상황이 달라지만 애자일 프로세스를 재 적용한다. 언제든지 달라질 수 있기 때문에 ongoing review하고 ongoing development한다. 무엇이 맞는지에 대한 보장이 없으니 핵심만으로 아이디어를 빨리 구현하고 실제 수치를 측정한다. 사용자의 의견같은거 말고 수치로 측정할 수 있는 데이터를 만들로 린으로 검증하는 과정을 방복한다.

IDEAS 과정에서는 무엇이 문제인지 알수 없으므로 계속 회의하지만 아이디어단계에서는 답이 나올 수 없다. BUILD 과정에서는 빨리 오픈하고 빨리 피드백을 받아야 한다. 중요하지 않은 기능을 다 제거해야 하는데 중요한 기능을 생각하는 것보다 훨씬 적을 수 있기 때문에 가장 중요한 것에 집중하고 나머지는 계속 버려나가는 과정을 반복해야 한다. MEASURE 단계에서는 객관적인 지표를 뽑아내야 한다. 각자 선호하는 것들이 있지만 여기서 필요한건 객관적인 지표이다. 수많은 지표들이 있는데 무엇이 중요한지를 결정해야 하고 지표를 실제로 A/B 테스팅등으로 확인해 보고 사용자의 피드백을 받아야 한다. 린 스타트업의 원리는 답을 알기힘든 큰 변화를 추구하는 개인이나 신규 서비스를 만드는 소규모 조직이나 신규 사업을 하는 내부 조직등 어디나 적용할 수 있다. 실제 적용할 때는 pivot을 하는 용기를 내는 것이 정말 중요하고 pivot을 하는 것은 생각보다 어렵다.

개인적으로는 오랜만에 정지웅님을 뵙게 되서 반가운 세션이었다. 몇번 얼굴을 뵌 적이 있어서 SNS에서 소식은 듣고 있었는데 사실 클럽베닛이 이렇게까지 성공을 하고 있는 줄은 몰랐다. 이 세션은 개발에 대한 세션이라기 보다는 스타트업의 프로세스에 대한 세견이었지만 이런쪽에 대해선 잘 모르기 때문에 더욱 흥미로왔다. 린 스타트업책은 한번 읽어봐야겠다.(번역서 얘기를 들은것 같은데 검색해봐도 못 찾겠다. ㅠㅠ) 일단 몇년간 실패를 한 경험은 나눈 세션이라서 알차고 좋았다.


ATDD: 스펙도 애자일하게 쓰자 - 황상철
스펙을 제대로 작성하는 것은 구식이다?에 나오는 "스펙을 한번이라도 제대로 작성해 본적이 있는가?"라는 글을 보시고 발표를 하기로 했다고 하셨다. 스펙(Specification)은 문서나 다이어그램 등이 있는데 그럼 스펙은 언제 얼마만큼 작성해야 하는가? 황상철님은 스펙은 개발전에 쓰고 개발을 할 수 있으면 멈추면 되고 다시 개발을 할 수 없게 되면 스펙을 쓰면 된다고 하셨다.(표준이나 WBS등이 중요한게 아니다.) 스펙 작성에는 대표적으로 UML이 있는데 오랫동안 UML을 가르쳤지만 여태까지 UML을 잘 쓰는 개발자는 한번도 본적이 없다고 하셨다. 그럼 개발자가 UML을 잘 모르는게 잘못인가생각하면 그렇지는 않다. 보통 UML은 너무 복잡하기 때문에 개발자들은 잘못 그릴까봐 오히려 안그리게 된다. 그 외에 유즈케이스가 있는데 유즈케이스는 코드수정에 따른 버전업이 문제다.


그러면 스펙과 코드가 일치하지 않는 것이 정말 문제인지 생각해 보자. 문제라고 가정해보면 Specification by Example에서 제시한 Living Document가 대안이 될 수 있는데 여기서 얘기하는 스펙은 코드와 시스템을 의미한다. 스펙에 해당하는 코드는 JUnit등으로 작성한 유닛테스트나 Cucumber등으로 작성한 테스트가 있고 이것을 시스템(specflow)으로 만들 것을 제시하고 있다. 그럼 문제가 아니라고 생각하면 어떤가? 스펙도 우유처럼 유통기한이 있어야 한다. 스펙을 어떤 기간동안의 스냅샷으로 보고 그 기간동안만 맞추면 되고 그 이후에는 코드로 보면 된다. 현재 하고있는 nForge 프로젝트에서는 Markdwon으로 스펙을 쓰고 있는데 팀원들이 다양한 OS를 사용하고 있기 때문에 어디서나 쉽게 작성하고 출력을 자유롭게 할 수 있기 때문에 Markdown을 선택했다. 스펙에는 반드시 완료조건(AC, Acceptable Condition)을 적어서 개발이 완료되어야 하는 조건을 명시하고 있다. 스펙에 AC를 잘 작성해 놓으면 테스트 시나리오는 대부분 커버할 수 있다. 추가적으로 테스트를 피라미드로 나타내면 맨 아래 유닛테스트가 있고 그 위에 서비스테스트가 있고 가장 위에 UI 테스트가 있다. UI 테스트가 제대로 이득을 보지 못하는 이유는 서비스 테스트를 제대로 하지 않기 때문이라고 생각하는데 보통은 유닛테스트를 작성한 다음에 UI 테스트를 작성하곤 한다. 서비스 테스트의 영역을 넓히는 것이 좋다.

다른 세션에 비해선 짧은 세션이었다.(20분 정도였나?) 이 세션을 듣고 생각해 보니 나는 스펙을 작성해 본 적이 없다. 예전에 회사에서는 CMMI 한다고 문서들을 만들기도 했지만 그건 보여주기 문서였지 사실 개발을 위한 문서는 아니었다. 그래서 처음에 들을 때 이 스펙을 나는 기획서라고 생각하고 있었다.(어떤 의미에선 비슷하기도 하지만 어쨌든 기획서를 보고 개발을 하기 때문에) 사실 문서화를 좋아하는 편은 아닌데(코드에 문서가 섞이는걸 더 선호한다.) 세션을 듣다 보니 개발자가 개발할 내용을 확실히 하기 위해서 적는 것을 스펙으로 이해했고 저런 문서를 개발자가 정리하면 개발영역도 명확하고 다른 사람들과 의논하기에도 괜찮겠다는 생각이 들었다. 담에 해봐야지...