꽤 진부하면서도, 논쟁거리가 될수도 있지만, 개인적인 경험과 고민 끝에 글을 나누고자 한다. 꽤 스타트업을 기술적, 아키텍팅 쪽을 컨설팅하면서 지켜보아 왔던 경험치를 가지고 말씀 드리는 겁니다.  (물론 삼성이라는 대기업만 다닌 니가 스타트업을 얼마나 잘 알아? 라고 물어보실수 있지만 말랑 스튜디오, 빙글, 이노피아 테크 등 꽤 많은 업체들을 컨설팅하고 이야기를 나누고, 그들을 지켜보온 경험치라고 생각을 해주시면 될듯 합니다)

개발자들에게 TDD의 도입을  물으면 찬반이 매우 명확한 편입니다. 특히 큰 규모의 라이브 시스템을 운영한  웹 개발자 분들은 TDD를 통해 조기에 많은 문제를 잡고, 찐한 경험 이야기를 해주십니다. 100%로 동의합니다. 많은 유저들이 동시에 모여서 나가는 서비스라면 품질이 매우 중요해지고,  돌다리도 두들기고 건너가는 것이 맞습니다.  큰 웹서비스를 경험하신 분 입장에서는 TDD 가 큰 보험이 되며, 그 다음 Step을 넘어가는 좋은 보험이 되죠.

은총알은 없다.

특정 방법론, 전략이 A 상황에서는 좋은 약이 될수 있지만, 모든 상황에  항상 옳다고 할수 있을까요?

어떤 방법론이든, 기법이든 항상 장단이 있습니다. 전달을 할때 꽤 신중하게 전달을 해야 한다고 봅니다. “TDD는 좋다!” , “내가 해본 경험으로서는 정말 보험이 되고 든든한 녀석이다!!”  라고 말을 하지만, 모든 상황에서 적절한 방법인지는 정말 고민을 해봐야 합니다. 정말 크게 이슈가 되었던 Joel과 Bob 삼촌의 TDD 논쟁 사건을 보더라도, Joel쪽에 공감하는 사람도 제법있습니다.  이 논쟁에서 Bob 삼촌의 이야기를 지지하는 사람도 있지만, 아닌 사람도 꽤 많다는 것이죠..

정말 공감가는 글이 있는데,  바로 TDD역시 비용의 문제라는 것이다.  미물님께써 적은신 글을 보고 크게 공감을 하고 있습니다.   바로 비용이라는 측면에서 바라보아야 한다는 것입니다. 또한 지금 xper 에서 논의되고 있는 “TDD 는 죽었다.”  라는 글을 보면 공감할 부분이 꽤 있습니다.

전규현님의 블로그중에 QA팀이 필요 없다고?  라는 내용이 있습니다.  사실 이글을 읽고 좀 이상하게 생각을 했습니다.. 현재 스타트업의 상황을 제대로 이해하고 계신건지..  모든 것을 다 갖추고 할수 없는게 스타트업인데.. QA팀이 내부에 있다는 것은 꽤 투자를 받은 회사나 가능하겠죠..

재미난 지표를 하나 보여 드리겠습니다. (2011-12 KOCCA 연구보고서)

앱을 만드는 개발자중 1인 개발자의 비율입니다. (2년전 데이터이기 하나)  무료 + 유료를 평균치 내면 70%가 육박합니다.  물론 요즘 스타트업들이 많이 육성되어 회사로 운영을 한 비율이 늘어나도, 역시 대부분 스타트업입니다.

이 사람들이 TDD할 비용이 있을까요?    어떤 느낌인지를 잘 표현하는 그림을 하나  보여드리죠..

개발자가 2,3명인 회사에서  기획, 개발, 배포, QA까지 모든 걸 다 커버할 수 있을까? 라고 생각을 해봅니다.

Startup은 사용자가 쓰는 제품을 찾기 위해 탐색을 하는 긴 여정을 떠나는 겁니다.

뭐가 성공할지 모른는데, 높은  Test 커버리지 비율, 아키텍처의 무결함을 가지고 있더라도 고객이 쓰지 않으면 아무 소용이 없죠. 처음부터 이거 고객이 쓸거야라고 100% 장담을 한다면 그렇게 하겠죠.. 당장 사람 1명을 고용할 비용이 없어, 적은 인원으로 운영되는 스타트업에게는 Quick & Dirty가 맞습니다.  그리고 투자를 받거나, 가망성이 보이면 그때 부채를 갚는 것이 맞습니다.  다만 부채를 갚는 스킬을 잘 알고 있어야 겠죠.  (이것도 어려운 이야기입니다.)

코딩/해킹 문화가 최고가 아니라. 내 물건을 쓸 고객을 찾는 것이 우선입니다. 스타트업은 인원도 없습니다.  믿을것은 팀원 밖에 없습니다. 상황에 따라서는 더 적은 비용의 검증, 즉 우선순위에 맞게 더 적은 비용으로 내가 품질을 얻을수 없나. 고려해 봐야 하는 겁니다.  스타트업은 적은 비용으로 효율성을 추구해야지, 예산이 넉넉한 곳과는 다르다는 것입니다 .

특히 모바일 스타트업의  환경에서는 전 높은 Test Coverage를 기반으로 하는 TDD보다는  핵심 가치와 많이 사용하는 기능을 위주로 TDD 환경을 구축하고, Static Analysis, Dynamic Analysis (Profiling)으로 hot spot 등을 발견해가면서 미리 잡고 가고, 사후 문제를 UrQA, Bugsense, ACRA와 같은 걸로 잡아서 해결해  다듬어 주는게 더 낫다고 생각이 듭니다.  더 적은 비용으로 할수 있거든요.

물론 이렇게 TDD 비용을 dramatic하게 줄인다면 그것도 환영입니다. (그걸 만들려고 노력중 이구요).  물론 LINE, KAKAO 같이 성공한 회사는 당연히  TDD 해야 합니다. 리소스가 되잖아요. 자본도 있고, 많은 유저가 붙어있으니 당연히 해야죠.

하지만 TDD자체가 품질을 확보하는데 제한적인 영역도 있습니다. 대표적인 경우로 안드로이드는 많은 디바이스, 단편화 문제로 미리 완벽한 품질을 확보하기 위해 TDD가 해줄수 있는 역할이 매우 제한적입니다. 갤럭시에서 돌던 것이  중국 샤오미(AOSP)에서는 말도 안되게 동작하지 않는 일들이 허다합니다. (전 세계에 모든 디바이스를 구하지 않는 한 의미가 없죠. 현실적으로 TDD가 매우 제한적이며, 돈 있는 업체들만 글로벌 테스트 SaaS를 이용해서 주요 폰들만 테스트해서 나가죠.)  iOS는  그래도 안드로이드에 비해 플랫폼, 디바이스가 제한적이어서 가능은 합니다.

저의 개인적인 생각을 잘 대변한 글입니다.

TDD의 아버지라고 할수 있는 Kent Beck이 Lean Startup 컨퍼런스에서 Jazz Engineering 이라는 주제로 다음과 같은 이야기를 했습니다.  (조현길 님에게 감사를)

• 초창기 스타트업 실패하면 그건 그것대로 좋지만, 성공하면 그 방법이 옳았다고 생각. 오히려 이것이 재난이 될 수 있음. 왜냐하면 처음 알게된 커스터머들이 아주 일부분이기 때문임. 조직에서는 그렇게 하는 방법이 맞다고 간주해버림.

• 외부에 대한 지식 보다 조직의 벨류만 중시하는 조직문화는 위험. 헤커중심으로만 간다든지, 회사의 벨류를 너무 강조한 나머지 외부에서 얻은 지식을 등한시하는 것을 경계해야함. 조직 문화가 매우 중요함. 내부적으로 영리한 방법이라고 생각하고 도취되는 것이 재난의 시작. 사용자와는 동떨어진 방법.

• 프로덕트 마켓 핏은 자주 일어나지 않음. 엔지니어는 헤킹/코딩이 최고라는 식의 의식을 바꿔야 함. 조직 내부의 고집 / 아집을 버려야 함.

• 깔끔한 코딩, 테스트코드 모두 좋지만, 필요없는 개발은 낭비일 뿐임.

• 두번째 위기 상황: 캐즘을 넘은 이후 너무 자만한 나머지, 비즈니스가 커간 상황에서 안주. 영리한것은 오히려 나쁜 것임. 마켓에서 오는 시그널을 무시해버릴 수 있음. 엔지니어가 “똑똑한” 것과는 별개. 조직이 바뀌어야 함.

• next market, 비즈니스, 피봇을 계속 찾으면서 고객이 원하는 것에 집중해야. 2개의 문제임. (다음 마켓에 대한 시도는 고객 중심 개발하고는 약간 다름. 다음 마켓 부분에 대한 탐색은 린스타트업에서 이야기하는 “실험”이라기 보다는 새롭게 시도해보는 것들임. 기회의 창들을 닫을 필요는 없음.)

비용과 플랫폼의 특성으로, 여러분이나 제가 믿고 있는 가치는 언제든지 변경될수 있다는 것을 다시 생각해 보자구요.  🙂