TDD

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

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

은총알은 없다.

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

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

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

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

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

구분 무료 어플리케이션 유료 어플리케이션
등록자 등록자 중 회사 등록자 등록자 중 회사
합계 3082 957 2869 734
A사 마켓 1695 579 1415 417
B사 마켓 423 163 589 192
C사 마켓 633 215 581 125

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

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

STARTUP

개발자가 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개의 문제임. (다음 마켓에 대한 시도는 고객 중심 개발하고는 약간 다름. 다음 마켓 부분에 대한 탐색은 린스타트업에서 이야기하는 “실험”이라기 보다는 새롭게 시도해보는 것들임. 기회의 창들을 닫을 필요는 없음.)

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

About these ads

Join the conversation! 9 Comments

  1. wizardfactory에서 이 항목을 퍼감댓글:
    좋은 의견임

    응답
  2. 1인개발자로서 공감합니다…

    응답
    • 옙! 많이 힘드시겠네요… 조만간 저희가 만든 툴을 공개할 예정이니 시간이 되시면 한번 이야기를 나누어용 :)

      응답
  3. 항상 TDD로만 개발하기도 어렵지요. 항상은 해보셨는지 궁금합니다.
    필요한 상황에서 적절하게 사용하면 됩니다.

    그리고 저는 TDD의 아버지를 켄트백 뿐 이라고 생각하지 않습니다.
    런던학파 쪽도 보시면 좋을 것 같네요.

    실력이 없으면 어떤 도구를 써도 효율이 떨어지기 마련이지요.
    TDD는 쉬워보이지만 진입장벽이 높은 스킬 중에 하나라고 생각합니다.

    응답
    • 청하님 의견 감사합니다.

      필요한 상황에 적절하게 쓴다는 것. 이걸 잘 설명하기가 전달하기 어려운것 같습니다.
      보통 개발자들은 좋아, 나빠.. 라고 말씀하시지, 내가 어떤 프로젝트에 어떤 형태로 사용했는데 성공했어, 실패 했어 등의 경험 공유와 또 프로젝트의 Context가 빠진 상황에서 좋다,나쁘다만 공유되거든요..

      정말 어려운 것이 자기가 익숙한 무기를 내려놓고, 이 무기가 과연 이 분야에도 맞는가? 라고 생각해 볼수 있어야 하는지 고민을 해봐야 하는데, 저 역시도 그러지 못하는 거 같습니다. 기존 기술의 애착은 일종의 캐쉬니깐요 :)

      어떤 패러다임이나 기술을 맹신하기 보다는 적재적소하게 사용해야 하는데, 특정 기술에 애착을 가지게 되면서 맹신하게 되는 분들에게 메세지를 전달하고 싶었습니다. :) 여튼 이런 이야기를 적기도 어렵고, 용기 내봐서 적었습니다. 이 포스트로 인해 이미 절 돌팔이라고 하시는 분도 있지만, 다양한 의견과 현실적인 답변을 해주시는 분도 있어서.. 거기서 만족하고 있습니다. :)

      응답
  4. 글 재미있게 읽었습니다.

    TDD 전파 적용에 대한 학습비용도 만만치 않아서 회사에 도입하기 어려운 점도 있습니다.

    혼자서 많은 모듈/프로세스를 개발해야 하는 경우 기억력에만 의존하고 실수로 공통적인 부분을 손댔을 경우 TDD는 그 실수를 잡을 수 있다고 생각하고 적용하는데. 초반에는 거의 사용하지 않습니다. 일이 커진다 싶으면 그때 적용하기 시작하지요.

    TDD 적용 기준이라는게 해보지 않으면 언제 해야 할지 어떻게 해야할지 가늠하기 어렵기 때문에 경험삼아서라도 해둬야 한다고 생각합니다.

    항상 옳지 않다는 것을 아는 경험이 중요하지요.

    응답
    • 좋다, 안좋다의 양 극단적인 표현보다,
      비용적인 문제로, 그리고 균형잡힌 시건으로 말씀해 주셔서 감사합니다. :)

      경험을 해보고, 자신만의 기준을 정립하는게 꽤 중요하다고 생각이 듭니다. :)

      응답
  5. ERD..
    아주 오래된 표현기법입니다.
    아마도 신입사원이 왔을때 ERD 같은건 필요없으니
    절대로 그리지 말라는 사람은 없을거라 생각합니다.
    ERD가 필요한 상황이 있기 때문이겠죠.
    프로그램에 쿼리 확인해보면 알수있는데도 필요한 이유는
    제 생각엔.. 좀 극단적으로 말하자면..
    글보단 그림이 더 눈에 들어오기 때문이 아닐까 생각됩니다.
    하지만, 프로젝트의 모든 관련 테이블들을 대상으로 ERD를 그리지는 않겠죠.
    그림이 복잡해져서 알아볼 수 없어지니까

    TDD..
    아주 오래된 방법론입니다.
    아마도 신입사원이 왔을때 TDD는 반드시 필요하니
    꼭 배워야 한다는 사람은 없을겁니다.
    TDD가 꼭 필요한 상황이 있다는 걸 모르기 때문이겠죠
    TDD 도입하지 않아도 잘 돌아가리라 생각되는 프로젝트에 도입이 필요한 이유는
    제 생각엔.. 좀 극단적으로 말하자면..
    요구사항 변경시 소스 수정에 대한 자동 검증이 아닐까 생각됩니다.
    소스가 어떤식으로 변경되더라도
    1 + 1 = 2 라는 수학적 대전제는 반드시 지켜져야 하기 때문에
    이 부분에 대해서 만큼은 TDD가 반드시 필요하다고 생각합니다.
    하지만, 프로젝트의 모든 변경이 가능할만한 전제를 대상으로 TDD를 적용하지는 않겠죠.
    요구사항 변경시 TDD를 위한 개발 공수가 더 많이 들테니까

    10년째 TDD 눈팅만 하다가 이제 막 시작해보려는 1인이었습니다.

    응답
  6. 감사합니다 좋은 하루 되세요

    응답

댓글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

카테고리

My Activity, My Thinking, News

태그

, , , ,