블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (46)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (3)
Total120,772
Today98
Yesterday128

James Grenning의 TDD and Refactoring Workshop 참가

 

몇주전 사내 역량강화센터 분들의 도움으로 매우 귀한 교육에 참가하였습니다.

TDD에 대해서는 오래전 부터 관심을 갖고 실무에 적용해보려 하였지만, 지속적으로 유지하지는 못했었습니다.ㅠㅠ

이번에 하던 업무가 정리되던 타이밍에 맞춰서 좋은 교육이 소개 되어 바로 참석하였는데, 이것은 실로 엄청난 경험이었습니다!!

사실 제가 영어 실력이 많이 딸려서, 한마디 한마디 모두 새기진 못했지만, 우리에게는 정말 잘 통하는 언어가 있었습니다. 그가 준비한 코드들과 시연하면서 보여준 코딩 모습들은 모두 저에게 큰 인사이트를 보여주었습니다.

 

 

 

그가 발표한 내용 중 가장 흥미로운 그림은 위의 그림과 같이 무수히 많은 공으로 저글링을 하는 것이었습니다.

현재 우리는 많은 공으로 저글링 하는 것처럼 많은 문제를 모두 다 노출시킨뒤에 해결하고 있다는 것입니다.

저도 그렇게 하고 있었겠지만, 생각만해도 끔찍합니다.ㅠㅠ

TDD는 한번에 하나의 문제만 해결하는데 집중하도록 하고 있습니다.

 

Uncle Bob's Three Rules of TDD

1. Write no production code, except to pass a failing test

2. Write only enough of a test to demonstrate a failure

3. Write only enough production code to pass a test

 

궁금 했던 것들에 대한 해답을 찾다.


제가 궁금했던 부분은 세가지 정도 였습니다.

첫번째는 테스트 코드에 대한 관리 이슈입니다. 프로젝트가 성장하다보면 테스트 코드의 비중도 높아지게 됩니다.

프로덕트 코드가 리팩토링 되면 테스트 코드에도 영향을 줄 수 있습니다. 테스트 코드의 원저작자가 없다면 문제가 될 수도 있습니다. 특히나 요즘처럼 자신의 코드가 아니면 Owner-ship을 전혀 가지지 않는 개발 문화에서는 더욱 문제가 됩니다.

James는 항상 테스트 코드를 깨끗하게 유지하라고 하였습니다. 리팩토링의 대상이 프로덕트 코드만이 아닌 테스트 코드도 포함된다고 하였습니다. 그리고 중요한것 중에 하나는 테스트 코드를 너무 많이 만들면 안되는 것입니다.

Unit Test 30개 + Integration Test 10개로 되는 것을 Integration Test로만 Cover하려다 보면 테스트 코드는 수백개가 넘어도 모자를 것입니다. TDD를 하다보면 자연 스럽게 Unit Test와 Integration Test의 조합을 구성하게 되며, 따라서 적은 테스트로도 높은 Test Coverage를 만들어 낼수 있습니다.


두번째는 TDD를 소개하다보면 "오버헤드가 크다, 작업이 너무 느려진다"라는 질문을 많이 받는데, 그때마다 정확히 설득하지 못했었습니다. 이는 기존의 개발 방법 대비 작업이 느려지게 느끼는 것일 뿐입니다 라고 James는 말하였습니다. Debugging이란 작업은 매우 Unpredictable 한데 비해 개발자는 Debugging 이전에 개발 완료라고 느끼는 경우가 많다는 것이죠. 아래 그림 처럼 Debugging 이전까지는 기존 개발 방법이 빠르게 느껴지지만, 코드가 버그 없이 완성되는 것은 TDD가 빠릅니다.



 

세번째는 TDD Step의 크기가 궁금했습니다. 책에서처럼 너무 작은 단위로 하다보면 살짝 멍청해보였습니다. TDD의 적용 방법은 어떤 작업이냐 혹은 작업자가 그 작업에 대한 경험이 얼마나 있는가에 따라서 달라질 수 있습니다. TDD에서 말하는 Small Step은 어떤 상황에서도 TDD를 적용할 수 있게 하는 기본적인 스킬 입니다. 처음에는 Small Step으로 계속 연습하는 것이 좋을 것 같습니다. 익숙해 진다면 Step의 크기를 자유자재로 조절할 수 있다고 합니다.


결국 제가 깨달은것은, "나는 TDD에 대해서 진정 아는 것이 없었구나!" 라는 것이었습니다.

매우 슬펐지만 반대로 무척 기뻤습니다.^^


James의 Workshop을 따라해보면 나도 우리 동료과 TDD를 할수 있지 않을까?


James는 Dojo 시스템을 이용하여 본인이 준비한 코드들과 인스트럭션으로 Group Activity를 진행하도록 하였습니다.

또한 Group Activity는 랜덤하게 2인 단위로 Pair Programming을 유도하였습니다.

Workshop참가자들이 대부분 애자일 개발에 이미 익숙한 사람이 많았고 적극적인 사람들이었기 때문 일수도 있지만, 참가자들 대부분이 매우 몰입해서 Workshop에 임하였다는 것이 매우 흥미로웠습니다.


그래서 따라해보기로 했습니다. 무작정 팀내 공지를 하였고 (약 50여명) 무작정 대회의실을 잡고, 무작정 날짜를 잡았습니다. 회비도 유례없이 미리 선불로 받았습니다. (2만원 - 뒷풀이 비용)

팀내 워크샵 당일까지 약 16명이 등록을 하였고, 모두 참석하여 약 2시간 동안 진행하였습니다. 참가자들의 직위는 책임연구원부터 연구원까지 다양하였습니다. 

 

James가 했던 내용, Group Activity를 그대로 진행하였습니다.

제가 기억 나는데로~ 물론 애드립이 난무하긴 했지만, 초반에 시작할때 성공적인 S/W에 대해서 공유도 하고, 본인이 개발시에 좋아하는 것과 싫어하는 것도 공유하였습니다.

대부분 디버깅과 테스트를 싫어하시더라구요...ㅎㅎㅎ 디버깅은 우리의 적이죠..

제가 30분 정도 TDD로 Circular Queue를 만드는 과정을 데모로 보여드리고, 랜덤하게 2명씩 짝 지어서 30분간 Pair Programming으로 TDD로 Circular Queue를 끝까지 만들어 보도록 하였습니다.

Small Step과 한번에 하나의 테스트 케이스를 계속 강조했습니다.

아래 사진에 맨 앞에 두분이 책임 말년인데 정말 열심히하시더라구요~ 워크샵 끝나고도 자발적으로 며칠 더 진행하셨습니다. Thread-Safe 까지 검증하는 테스트 케이스를 만드셨더라구요..ㅎㅎ 대박..

 

 


어라 이거 효과가 있네요?^^ (회고)

 

매우 간소하게 James 따라하기 워크샵을 진행하고 나서, 간단하게 회고를 진행하였습니다.

질문은 두가지 였습니다.

TDD에 대한 긍정적인 느낌

TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정


 

먼저 TDD에 대한 긍정적인 느낌에 대해서는 아래와 같이 답해주셨습니다. (작성한 그대로 옮겼습니다.)

생각보다 재미있고 긍정적인 회고 내용이 많았습니다. 제가 말로만 설득할때와는 전혀 다른 반응입니다!

특히 Pair Programming에 대한 긍정적인 느낌은 매우 인상적이었습니다^^

 

- 새로운 개발 방법을 알게 되어서 좋았음. 비록 처음 익히기는 어렵겠지만 익숙해지만 Error를 사전에 예방할 수 있어서 개발시에 많은 도움이 될 것 같음

- Pair Programming 해보니 상대방이 나와 다르게 생각하는 부분을 알게된다. 처음부터 복잡하게 이것저것 다 생각하지 않고, 하나하나 순서대로 해서 좋다.

- 구멍이 없는 프로그램을 만들 수 있을 것 같다. 프로그래밍 개발시에 다른 함수를 추가하면서 기존 함수를 - 고칠 때 기존 함수에 대한 Test가 누적되어서 테스트가 보장됨.

- 쉽게 따라 할 수 있어서 좋았습니다.

- 잠들어가는 나의 뇌를 깨울수 있는 흥미있는 Programming 접근방법

- 반복적인 테스트 Set을 구축/확장하기 용이하다

- Code를 꼼꼼히 생각하며 짤수 있다.

- Test Case 자체가 Application이기 때문에 Caller 입장에서 구현할 수 있음.

- 재밌다(신기) ㅋㅋ 한번 업무에 활용해보고 싶다.

- 코딩이랑 테스트랑 같이하니 시간 절약은 될듯. 그러나 테스트가 명확해야 함.

- 잘하면 좋은 방법론이 될 듯하다.

- 계속해서 코딩단계부터 예외사항을 고려하게 된다.

 

두번째는 TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정입니다.

역시 업무 속도가 느려질것 같다는 걱정이 많습니다. 위에서 설명한 것처럼 실제로는 느리지 않다는게 핵심이죠

레거시 코드에 대해서 걱정하시는 분도 있습니다. 레거시 코드는 저도 무지 걱정됩니다.^^; 따로 다루어야 할 내용입니다.

 

- 내가 만드는 Test case에 hole이 분명! 있을거다. TDD하고도 이모양이냐는 비난?

- Project 파일에 junit을 어떻게 추가하는지? 코드의 규모가 커졌을 때는?

- 개발 시간이 많이 걸리고 알고리즘이 핵심인 SW에는 적용이 제한적일 것 같음. Step이 커질때 실수 할 수 있지 않을까?

- TDD에 익숙해지기 까지 업무속도가 느려질 것 같다. TDD를 이해하는 협업하는 분위기가 아니라면 좀 힘들듯...

- 코딩 및 설계과정에서 테스트 내용을 명확히 짚고 가야 할 거 같음

- 처음 하는 것이라 시간이 많이 걸릴것 같다. 보통 처음 설계부터 하는 개발이 아는 경우 어떻게 적용?

- 초반에 시간이 많이 걸림. 확실한 test case를 만드는데 어려움 있을듯

- 어느 단위 (어느 레벨)에서부터 적용할지 의문이 생김

- 일정이 촉박하면 이런거 다 무시하고 닥치는 데로 코딩하는 마음이 생길 수 있다.

- 개발 속도가 느리다.

- TDD를 익힐 때까지 기존의 습관을 고쳐야 할 것 같음. Test case를 정하기가 어려움.

- 아직 익숙치가 않아서 그럴지 모르지만 시간이 많이 걸릴것 같다. 내가 뽑은 테스트 케이스 외에 여러가지 다른 케이스가 있을 것 같다. 시간에 쫒겨 개발시에 이걸 적용할 수 있을지

 

생각보다 반응이 너무 좋아서 2부를 진행해보려고 합니다.

2부에는 Test 하기 좋은 클래스 설계하기 및 Mock Object 사용해보기로 진행해보려구요

또한 이러한 워크샵 형태로 스터디를 진행할 예정입니다. 그리고 내년에 제가 참가하는 프로젝트에서는 TDD를 매우 적극적으로 장려하고 적용할 생각입니다. 물론 현재 프로젝트에도 개인적으로 적용을 해봤구요. 정말 흥미 진진한 2013년이 될것 같습니다.

 

James 덕분에 동료들이랑 정말 좋은 경험 하고 있네요!

James가 이 글을 보진 못하겠지만 정말 감사하다고 말씀드리고 싶어요..!^^

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2012.12.21 06:55 신고 한주영  댓글주소  수정/삭제  댓글쓰기

    멋지네요. 2시간이라는 짧은 시간에 이런 훌륭한 워크샵을 진행하신 건 정말 대단해요. 두번째 워크샵은 서초 전체로 오픈하면 어떨까요. 저도 참석해서 학생이든 보조든 동참하고 싶어요. 사전 참가비 2만원 유지하고. ㅎㅎ 저도 예전에 파싱 세미나 개설하면서 사전에 참가비 입금을 받았는데 저희 교육팀장님이 딴지 거셔서 되돌려드린적이 있어요. 하지만 좋은 시도 같아요. 주요 내용을 번역해서 제임스에게 알려줘도 좋을 것 같아요.

    • 2012.12.21 07:34 신고 윤청하  댓글주소  수정/삭제

      댓글 주셔서 감사합니다.^^ 뒷풀이 비용으로 받는 2만원은 별거 아닐수 있지만 참여자의 관심도가 달라지는것 같아요..ㅎㅎ
      서초 전체 오픈은 좋은 생각입니다! 그런데 일단 소규모로 준비하고 검증을 해보고 진행해 보는 것이 어떨까 싶어요~ 팀내에서 진행하는건 1월 둘째주에 바로 진행해 보고 반응을 보려구요^^

  2. 2012.12.24 18:22 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    오.. 오랜만의 글이네. 잘 지내지? TDD Workshop 재밌었겠다.

    • 2012.12.26 09:17 신고 윤청하  댓글주소  수정/삭제

      웅..ㅋㅋ 올만에 썼엉.. 이거 쓰는데도 일주일정도 걸린거 같앙..
      요즘 회사외의 시간중에 내시간이 거의 없당..ㅋㅋㅋ
      TDD 잼있엉.. 내년에는 꼭 실무에서의 Small Success를 만들어보려궁..^^

  3. 2012.12.26 15:37 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    자식 있는 사람이 회사 외에 내 시간이 어딨어. 나도 애기 보느라 힘들당 ㅎㅎ
    우리 회사에서는 이제 겨우 단위 테스트랑 일일빌드 적용하는 걸음마 단계라 TDD는 좀 더 있다 봐야 할 듯 ㅎㅎ

    • 2012.12.26 16:26 신고 윤청하  댓글주소  수정/삭제

      단위테스트라는게 말그대로 Unit Test를 말하는거야? 아님 CppUnit, JUnit과 같은 Unit Test Framework을 쓴다는 것이야?
      보통 TDD를 안하고 Unit Test를 한다는 것을 보면 Unit Test Framework을 써서 Integration Test 이상을 하거든... 그냥 궁금해서^^

  4. 2013.01.02 15:55 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    말 그대로 Unit Test를 하고 있어. TDD는 개발 방식까지 포괄하는 개념이라 적용하지 않고 Unit Test만 먼저 적용하고 있지.

  5. 2013.01.11 14:09 신고 지나가다가  댓글주소  수정/삭제  댓글쓰기

    xper 그룹 이메일 보고 들어왔습니다. 알차게 부럽네요~ 역시 뭐니뭐니해도 실천이죠! TDD 이야기보다 실무에 적용하는 이야기가 더 와 닿아 글 남깁니다. 개발 초년생 입니다. 올바른 개발 문화의 예를 앞으로도 많이 만나게 해주세요! 화이팅!

   켄트백의 "익스트림 프로그래밍 2/E"에 다음과 같은 글이 있다.

매일 나아지고 있는 똘망이

  •   상황이 어떻건 간에 당신은 언제나 더 나아질 수 있습니다.
       No matter the circumstance you can always improve.
  •   당신은 언제나 자기 자신부터 개선을 시작할 수 있습니다.
      You can always start improving with yourself.
  •   당신은 언제나 오늘부터 개선을 시작할 수 있습니다.
      You can always start improving today.

나는 오늘부터 개발자로써의 나 자신을 개선하기 시작한다. 
(먼저 저에게 확신, 용기 그리고 영감을 주신 변신철님, 박피디님, 이희찬님, 박형근님, 김창준님께 감사드립니다.^----^)

회고 - 왜 실패했을까?

나는 지난 수개월간 TDD를 스스로에게 적응시키기 위해 부단히 노력하였다. (켄트백의 책은 이해가 잘안되서 3번이나 읽었다.ㅠㅠ) 팀내 동기인 이희찬(http://heestory.kr)씨와 함께하였으며, TDD에 적극적으로 동참하고자 하였다. (불행히도 둘다 팀에서 말단급이다ㅠㅠ. 하지만 나는 팀의 말단에서부터도 변화할 수 있다고 생각한다^^)
하지만, 난 아직도 TDD에 적응하지 못하였다. 이유가 무엇일까? 스스로에게 물어보았다.
  • 의도적 수련 시간의 부족 
    안데쉬 에릭손이 주장한 1만 법칙에 따르면 1만 시간 동안 의도적 수련(deliberate practice, 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련)을 해야 그 분야의 전문가가 될수 있다고 한다. 또한 TDD의 성공사례를 찾아보면 수개월만에 몸에 익숙해졌다는 사례는 찾기힘들다.
    TDD는 기존 개발 방식을 완전히 뒤바꾸어 놓은 개발 방식이다. 즉, 이미 수년간 몸에 익은 습관을 버리기 매우 힘들다. 변화할만 할때 변화한다. 난 아직 의도적 수련을 더 많이 해야 한다!
  • 테스트 케이스 작성의 어려움
    나는 팀에서 독립적으로 개발 가능한 라이브러리(영상 코덱)을 개발할때 TDD를 적용하려고 했다. 
    하지만, 쉽지않았다. 영상 코덱은 결과물이 영상이기 때문에 자동적으로 옳고 그름을 판단하기 어려웠다.
    어떤 알고리즘은 특성상 최적해(optimal value)를 찾기 보다는 제일 괜찮은 해(best effort)를 찾는 경우도 있는데 정답을 판단하기 어려웠으며, 수학 공식이 있는 부분은 손으로 계산하기 귀찮았다.ㅠㅠ

그럼에도 불구하고 왜 꼭 TDD를 해야 하는가?

  • 선배들의 아픔을 똑같이 경험하고 싶지 않다. 
    기 개발된 다른 코덱들은 테스트 케이스가 전혀 없었으며, 지금도 가끔 상용싸이트에서 장애를 일으키고 있다. 장애가 나면 담당 개발자는 무지하게 골치아파진다.
  • 기존(legacy) 코드는 테스트하기 어렵다.
    내가 작성중인 코드도 어렵다.ㅠㅠ
  • 지속적인 검증이 필요하다.
    영상 코덱은 리눅스 버전으로 기능 개발이 완료된 후 리눅스에서의 최적화 작업(알고리즘 및 어셈블리 최적화)과 DSP 보드 상에서의 최적화 작업(메모리 및 어셈블리 최적화)을 하게 된다. 따라서 자동화된 유닛 테스트가 있다면 해당 작업들이 매우(x백만개) 수월하게 작업할 수 있게 된다.
원래 목표는 자동화된 단위테스트(unit test) 케이스를 누적시키는 것이다. 회사내 수석 개발자 분에게 TDD를 언급하면 항상 이점을 지적하시면서 화이트 박스 테스팅을 하라고 강조(TDD는 말고)하신다.
하지만 TDD의 이점은 자동화된 테스트 케이스의 누적에만 있지 않다. 기존(legacy) 코드를 위해 테스트 케이스를 만들어보려고 시도해본 이는 알것이다. 테스트에 적합하게 작성되어 있지 않은 코드는 당연히 테스트 하기 어렵다. 불행히도 거의 대부분의 기존 코드는 테스트에 적합하게 작성되어 있지 않다. 재미있는 사실은 테스트에 적합하게 작성된 코드는 매우 명확하고 깔끔해 진다는 것이다.
또한 TDD는 점진적인 리팩토링을 하도록 유도한다. 즉, 기존 코드도 점진적인 리팩토링을 통해 거듭날 수 있다. (이는 TDD와 무관할 수도 있다.)

그럼 바로 지금부터 무엇을 할 것인가?

  • 기존 코드는 큰 기능 단위부터 자동화된 테스트를 만들어 본다.
    결과물이 영상이기 때문에 완전히 일치하는지 검사하는 것 보다는 유사성 테스트를 통해 자동적으로 판별하고 유사성이 크게 떨어질 경우 눈으로 확인하는 절치를 스크립트로 작성한다.
  • 신규 개발 코드는 어떤 일이 있어도 TDD로 작성한다.
  • 추가 개발 코드는 테스트 케이스 추가 및 테스트 가능한 인터페이스로의 리팩토링, 이 두가지 작업을 적절하게 조합하여 테스트 케이스를 어느정도 만든뒤 작업한다.
이렇게 꾸준히 작업하면 테스트 커버리지는 자연적으로 상승할 것이다.
나는 XP 정신으로 바로 오늘부터 시작하였다!^^ 뽐뿌 백만개 받았다~ (금요일이라 그런가ㅡㅡ^)
오늘 신규 개발된 코드는 모두 TDD로 작성되었으며, 빠른 테스트를 위해 스크립트도 작성하였다.


앞으로 TDD를 잘하기 위해 필요한 자료들을 정리해서 올려보도록 하겠습니다~ 감사합니다.

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.10.31 10:03 신고 박형근  댓글주소  수정/삭제  댓글쓰기

    화이팅입니다.!!!

  2. 2009.10.31 10:57 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    ㅋㅋ청하씨 화이팅!!ㅋㅋ충전 만땅되셨네-ㅎㅎ
    저는 베터리 방전될거 같아유...ㅠ


이번 편은 내 경험의 일차적인 마무리로써 앞으로 해결해야할 숙제들을 정리해보려고 한다.
이것은 말단 팀원으로써의 관점이다!

교차 기능 개발팀 구성

스크럼은 개발팀 구성을 스크럼 마스터, 고객, 제품 관리자, 개발자, 테스터 등으로 구성하도록 제안한다.
우리회사의 개발 프로세스는 단계적으로 매우 고립되어 있으며, 개발팀 구성 또한 개발자만으로 구성된다.
따라서 개발자가 프로젝트를 진행하면서 테스터(QA), 고객 혹은 제품 관리자와 피드백을 주고 받는 경우는 매우 드물다.
(프로젝트가 완료된 후 상용서비스에서 장애 발생시에는 직접적으로 피드백을 주고 받기도 한다.)
개발자는 개발 팀장이 간단하게 언급하는 기능 요구사항을 그저 개발만 하면되는 프로세스이다. 

최근에 구매해서 보고 있는 책에서 교차 기능팀(cross-functional team, Wikipedia)에 대해 소개하고 있다.
이해 관계자 중심 소프트웨어 개발
고객의 비즈니스 가치를 드높이는 개발 접근법
칼 케슬러, 존 스웨이처
차영호 역
인사이트
이 책에서 저자는 개발팀은 가능한한 교차 기능팀으로 구성되어야 한다고 주장한다.
개발팀으로써의 교차 기능팀의 인적 자원 구성은 스크럼에서 요구하는 구성원 정도면 충분하다.
교차 기능 개발팀이 됨으로써 개발자는 고객의 요구사항에 어떤 비즈니스 가치가 있는지 알고 개발할 수 있고, 고객과 함께 서로 윈윈 할수 있는 프로젝트가 될수 있다.
교차 기능 개발팀에서는 모든 팀원이 프로젝트의 비전에 대한 이해도가 높아지며, 소수의 이해관계자만을 만족시키는 결과물을 생산할 가능성이 줄어든다.

교차 기능 개발팀만으로 조직이 구성된다면 문제가 될 수 있다. 하지만, 필요한 경우 교차 기능 개발팀을 유연하게 구성할수 있는 조직이라면 조직의 휴먼 리소스 효율면에서 탁월한 조직이라 할수 있겠다.
애자일 문화가 퍼져서 그 성과가 보여진다면 조직도 바뀔수 있지 않을까?

XP 적용하기

스크럼을 적용하면서 나와 희찬씨(L씨)는 XP의 실천법중 짝프로그래밍과 테스트주도개발을 팀에 적용하고자 하였다. 짝프로그래밍은 팀장님이 반대하셨으나, 테스트주도개발은 한번 해보면 괜찮을것 같다는 반응이셨다.
익스트림 프로그래밍 2판
변화를 포용하라 
켄트벡, 신시아 안드레스
정지호, 김창준 역
인사이트
우리는 제대로된 짝프로그래밍은 못하였으나 짝을 지어서 개발을 하도록 노력하였다.
단일 기능에 대한 요구사항 분석, 설계, 개발, 테스트등을 짝을 지어서 개발하였다. (원래는 혼자 해야 한다.)
그나마 다행인것은, 팀장님의 배려로 짝으로 구성하여 자리를 옮길 수 있었다.
혼자 고민하던 것을 짝을 지어서 실시간으로 피드백을 주고 받다 보니 선택의 기로에서 정체되는 일이 드물었으며 개발의 완성도 또한 높았다. 하지만 혼자해야 할 작업에 두명이 투입되었기 때문에 시간적으로 2배 빠르게 진행되어야 했다.
또다른 장점은 코드 공유의 범위가 확대 되었으며, 무 집중도가 매우 크게 상승했다는 것이다.
불행히도 위에 열거한 장점들은 나와 희찬씨만 느꼈을 뿐 다른 팀원들은 이전 방법으로 되돌아 갔다.

올해 우리회사 슬로건 중 하나는 "장애율 0%" 이다. 
이 슬로건을 연구소에 내밀었을때 연구소의 개발자들은 매우 흥분하였다. "버그 없는 소프트웨어는 없다!"
이와 같은 슬로건이 나오게 된 것은 당연히! 작년에 회사의 신뢰도에 문제가 있을 정도로 장애가 많았기 때문이다.
VoIP가 대체 통신 수단에서 주 통신 수단으로 서서히 변경되면서 품질에 대한 걱정은 더 커져갔다.
연구소에는 자동화 테스트의 개념은 전혀 없었으며, 제품에 새로운 기능이 추가될 때 회귀 테스트도 없었다. (기본 기능의 성공 케이스만 확인하는 정도)

난 켄트백의 테스트 주도 개발 책을 보면서 이것이 바로 우리 회사에서 적용해야 할 첫번째 실천법이라고 생각했다.
테스트 주도 개발
Test Driven Development by example
켄트 벡
김창준 역
인사이트
그리고 회사 내의 수석 개발자를 찾아갔다. 그분이 이미 알고 있는 듯한 눈치였으며, 이런거는 회사 현실에서는 맞지 않는다는 뉘앙스를 풍기셨다. 팀장님도 그다지 환영하는 분위기는 아니었다.
물론 두분 다~ 자동화 테스트가 정말 필요하다는 것은 동의하셨다. 
테스트 주도 개발은 자동화 테스트를 누구나(?) 쉽게 만들 수 있는 명료한 방법이다.
  • 테스트 먼저 작성하라
  • 중복을 제거하라
희찬씨와 나는 신규 비디오 코덱 개발에 테스트 주도 개발을 적용하였다. 결과는 참담했다.
비율로 보자면 20 : 80 정도로 기존 개발 방식을 거의 고수하였던 것이다.ㅠㅠ

얼마전에 있었던 xper 정기모임에서 나는 테스트 주도 개발 실천법이 적용하기 어렵지만 그 효과는 매우 크다는 것을 다시 한번 깨달았다. 테스트 주도 개발을 팀에 제대로 적용할 수 있다면 지금처럼 팀의 리소스의 30% 이상을 유지보수에 힘쓰고 있지는 않을 것이다.

문화 바꾸기

애자일에서 팀웍은 매우 중요하다. 즉, 혼자 잘해서 될일이 아니다.
팀 혹은 조직의 문화가 바뀐다면 사람도 바뀔 것이고 조직의 가치도 바뀔 것이다. 
그 안에서 애자일 실천법의 적용은 매우 쉬울 수도 있다.
팀장도 아닌 말단 개발자인 내가 팀과 조직의 문화를 바꾸려면 매우 힘들다는 것을 잘 안다.
하지만 나의 지지자(도반)들을 꾸준히 늘려나간다면, 그리고 이와 같은 생각들을 공유한다면 언젠가는 내가 속해있는 조직도 고효율의 조직이 될 수 있을 것이라 확신한다.

마무리

당분간, 난 테스트 주도 개발에 익숙해 지기 위해 매진할 것이다. 일단 고!
같이 하실분 없나요?^---------^

읽어주셔서 감사합니다!~ 
그냥 가지 마시고 리플로 피드백을 해주신다면 정말 정말 백만개 감사할 것 같습니다.^^
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.10.28 17:48 신고 YUZI  댓글주소  수정/삭제  댓글쓰기

    연재 잘 읽었습니다. Cross-functional은 한팀에서 하기 어려울텐데 결과가 기대되네요.
    다양하고 많은 수행이 예정되어 있군요. 화이팅입니다.

    • 2009.10.28 18:11 신고 윤청하  댓글주소  수정/삭제

      감사합니다.^^
      제가 말단이라 다 수행할수 있을지는 모르지만 노력해야죠ㅋㅋ

      물론 교차 기능팀을 한팀으로 구성하기는 힘듭니다.
      가상팀으로 구성해도 괜찮을것 같아요.
      예를 들면 데일리 미팅을 같이 하는 방법으로..^^
      현실적으로 접근할 필요성이 있을것 같아요~

  2. 2009.10.29 12:43 신고 ParkPD  댓글주소  수정/삭제  댓글쓰기

    Mock 환경을 잘 갖춰놓은 다음에야
    다른 팀원들도 테스트를 작성하기 시작하더군요.
    시간이 좀 걸리는 일이지만, 일단 굴러가기 시작하면 좋아지는 걸 느끼실 수 있을 겁니다.
    좋은 글 감사합니다.

    • 2009.10.29 13:20 신고 윤청하  댓글주소  수정/삭제

      괜찮은데요? +_+
      저희는 프로세스간에 메시지를 주고받는 일이 많은데..
      큰부분부터 고민해보고 실행에 옮겨봐야 겠습니다.^^
      구체적인 방법을 제시해주셔서 감사합니다~

  3. 2009.10.29 17:54 신고 heestory.me  댓글주소  수정/삭제  댓글쓰기

    테스트 주도 개발..처음에는 쉬울거라 생각했는데..
    막상 해보니 익숙해지려면 시간이 좀 걸릴것 같네요..OTL
    그래도 홧팅-ㅎㅎ

  4. 2009.10.29 18:22 신고 박형근  댓글주소  수정/삭제  댓글쓰기

    재미있고 유익한 연재 잘 봤습니다.
    다음 연재도 기다려 지네요 ^^
    개인적인 의견으로는 ,
    테스트가 없는 기존 코드가 크게 있고, 거기에 기능을 추가/변경 해 나가는 경우라면 좀 큰 단위의 테스트케이스를
    먼저 작성하는것이 효율적이라 생각합니다. (유닛테스트라기 보다는 '기능테스트')
    저희 팀은 UnitTest가 실질적으로 정착되는데 약 3년 정도 걸린것 같구요.
    기존 코드가 테스트하기 어려운 구조여서 간단한 테스트케이스 만드는데도 시간이 오래걸리니 다들 안하려 하더군요.
    조금씩 코드가 정리되고, 테스트를 편하게 할 수 있는 helper기능들이 추가되니 테스트케이스만드는데 부담이
    적어지면서, 그때서야 정착이 되었던것 같습니다.
    지금은 다들 중요성을 인정하고 있구요.
    과정이 좀 힘들지만 꼭 성공하시길 바랍니다.!!

    • 2009.10.29 18:55 신고 윤청하  댓글주소  수정/삭제

      좋게 봐주시고 명쾌한 피드백 주셔서 감사합니다.^^
      오늘부터 짬나는 시간에 해야 할일들이 머릿속에 정리되는 느낌입니다.
      1) 좀더 큰 부분(기능단위)부터 테스트 케이스 작성을 시도하자.
      2) 테스트에 도움이 되는 것들 (mock object, helper등)을 정리하고 만들자.
      갑자기 뽐뿌 받았습니다!~ 블로깅 하는거 너무 재미있네요~ 진작 할껄~ㅋㅋ

  5. 2010.01.16 23:11 신고 귀뫄뉘  댓글주소  수정/삭제  댓글쓰기

    다른 애자일 관련 포스팅에는 원론적인 글 밖에 없어서 식상했는데,
    실제 적용사례와 효과까지 들려주시니 마치 제가 경험하는 것처럼 재미있네요
    좋은 포스팅 감사합니다 ^^

  6. 2010.10.14 23:47 신고 움케  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다. 내용이 참 실용적이네요. ㅎ

    사실 새로운 개발 방법론 같은 것을 프로젝트 매니저가 자신의 팀에 도입하려해도 성공하기 힘들다고 생각하는데,
    말단 팀원이 팀을 변화시키기위해 고생 많이 하시네요. 먼저 매니저를 변화시키고, 좋은 결과 거두시길...

    • 2010.10.18 19:43 신고 윤청하  댓글주소  수정/삭제

      읽어주셔서 감사합니다.
      현재 저는 해당 팀을 나왔습니다^^;;
      새로운 곳에서 변화를 꿈꾸고 있습니다. 꼭 애자일이 아니더라도~


어느날 아침에 한 영업실의 실장님과 간단한 대화를 나누었다. 그때 실장님은 귀에 거슬리는 말씀을 하셨다.
맨날 구조 바꾸고 갈아 엎는다고만 하지 말고 생각 좀 해서 개발해봐! 버그만 심지 말고..
이전에(애자일 마인드를 갖기 전) 이 말씀을 들었다면 매우 부정적으로 "니가 개발을 알아?" 라고 마음속으로 콧방귀를 꼈을 것이다. 하지만 오늘 나는 개발자로써 반성문을 써보고 무엇이 문제인지 밝혀보고자 한다.

영업부서와 개발부서와의 미팅에서 개발자들이 시간적으로나 기능적으로 불합리한 요구사항에 대처하는 핑계중에 하나는 아마 다음과 같을 것이다.
현재 우리 구조에는 적용하기 어렵습니다. 적용하더라도 시간이 걸릴것 같으며, 추후에는 전체적으로 뒤집어 엎어야 합니다.
실제로 내가 다니고 있는 회사의 모습만 봐도 구조 및 설계 개선 등의 이유로 전체 시스템 소스코드를 뒤집어 엎는 경우(전역 리팩토링)가 매우 많다. 우리팀도 작년부터 이전 플래폼을 개선한다는 이유로 2.0이라는 이름을 달고 1년이 넘게 팀의 리소스 중 많은 부분을 플래폼 구조 개선 작업에 투입하였다.

문제는 이러한 작업의 결과가 비지니스적인 가치로 창출되는 경우는 매우 드물다는 것이다. 오히려 새로운 소스코드에 대한 검증 및 안정화 작업으로 인한 업무 오버헤드가 더 증가할 수 있다. 물론 추후 생길수 있는 요구사항을 손쉽게 적용할 수 있을 수도 있다. 그러나 이것은 XP를 인용해보자면 쓸데없는 짓이다. "사용자 스토리"라는 책을 보면 스토리(요구사항)는 투자되는 리소스 대비 비지니스적인 가치가 높은 것의 우선순위를 높게 책정하도록 권장하고 있다. 지금 현재 다른 업무가 거의 없지 않은 이상 전체를 뒤집어 엎는 스토리의 우선순위는 높아질 수 없는것이 자명하다.

그렇다면, 무엇이 문제일까? 개발을 잘 못한 개발자들만의 잘못일까? 이와 같은 일이 벌어지는 이유를 내 경험을 통해 정리해 보겠다. (현재 재직중인 회사만의 현상일 수 있으나, 한국의 개발회사는 크게 차이 없을 것으로 생각된다.)
  1. 개발자마다 "개발완료"의 의미가 다르다.
    어떤 개발자는 코딩 및 컴파일 완료를 개발 완료라고 생각한다.
    어떤 개발자는 기능 테스트(화이트 박스 테스트) 완료를 개발 완료라고 생각한다.
    어떤 개발자는 리팩토링까지 완료해야 개발 완료라고 생각한다.
    불행히도 많은 경우에 두번째의 경우를 개발 완료라고 생각한다.
  2. 개발 기간이 너무 촉박하다.
    영업부서에서 전달하는 요구사항 대비 주어지는 개발 기간이 매우 적은 경우가 많다.
    이럴 경우 핵심적인 기능(비지니스적인 가치가 높은)을 선별적으로 개발해야 하나, 대부분의 협의는 모든 기능 구현으로 종결된다.
    즉, 개발자는 기능 구현에만 집착하게 되며, 리팩토링은 신경쓸 수 없게 된다.
  3. 과도한 업무로 보상 심리가 강해진다.
    개발양은 많고 개발 기간이 촉박해지면, 잦은 야근, 밤샘 작업 및 주말 작업은 일상생활이 된다.
    이로 인해, 프로젝트가 일단락 되어 여유 시간이 생기더라도 보상 심리로 인해 리팩토링 작업은 미뤄지게 된다.
  4. 리팩토링에 대한 교육이 없다.
    리팩토링 뿐만이 아니겠지만, 리팩토링을 강조하고 무엇을, 어떻게 해야하지는 알려주지 않는다.
  5. 깨진 자동차 유리 
    "실용주의 프로그래머"라는 책에 소개된 깨진 자동차 유리 실험처럼, 지속적인 리팩토링이 이루어지지 않은 코드의 중복성은 기하 급수적으로 증가하게 된다.

이유를 적다보니 개발자의 책임이 큰것을 알 수 있었다ㅠㅠ. 
물론 영업부서의 유연하지 못한 요구사항도 큰 문제이다.

나의 결론은 간단하다. 목표는 전체적으로 뒤집어 엎어야 하는 경우를 줄이는 것이다. 
다음과 같은 원칙을 가지고 개발한다면 어느정도 도움이 될 것이다.
  • 항상 중복을 제거한다. [리팩토링]
  • 코딩 전에 테스트를 작성한다. [TDD , 어렵다면 어떻게 테스트를 할지 미리 결정해야 한다.]
  • 설계와 구현은 동시에 진행한다. [XP, 점진적인 설계]
  • 코드 공유 및 리뷰를 수행한다. [XP, Pair Programming]

하지만, 시간이 촉박한 프로젝트의 경우에 해답을 찾기란 쉽지 않다.
결국은 영업 부서와 개발 부서가 한팀이 되어 긴밀한 협업을 하는 것이 중요한 관건이다.
협업이 원활이 이루어 진다면 영업 부서는 비지니스 적인 가치를 극대화 할수 있으며, 개발팀은 핵심 기능에 집중하여 더욱 신뢰성 높일 수 있을 것이다. 고객과의 협업까지 이루어 진다면 금상첨화가 아닐수 없다.
영업 부서와의 협업 방법으로 사용자 스토리스크럼을 추천한다.^^

사용자 스토리와 스크럼에 대한 내용은 다음 책을 참고하면 좋다.
사용자 스토리
고객 중심의 요구사항 기법
마이크 콘, 심우곤 역
인사이트
스크럼과 XP
애자일 최전선에서 일군 성공 무용담
헨릭 크닉버그
인사이트
신고
Posted by 윤청하

댓글을 달아 주세요

  1. 2009.11.05 14:09 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    스스로 피드백~ (아무도 안줘서..ㅋㅋ)
    거의 동일한 기능을 가지는 새로운 제품을 만들때(설계/구조 개선등의 목적) 생기는 또하나의 단점은
    만약 새로운 제품이 기 제품이 납품된 싸이트에 적용(migration) 될 수 없다면 개발팀으로써는 거의 동일한 두가지 제품을 follow-up 및 유지보수 해야 하는 것이다. 이는 혹떼러 갔다가 혹 더붙이는 꼴이 될 수 있다.
    (특히 상용에서 정상적으로 서비스 중인 제품을 검증되지 않은 새 제품으로 migration 하는 작업을 달가워할 고객은 별로 없을 것이다. - 설득의 문제)

  2. 2009.11.05 14:11 신고 윤청하  댓글주소  수정/삭제  댓글쓰기

    최근 옆팀에서 기존 제품에서 설계/구조 개선을 목적으로 새로 제품을 개발하는 작업을 시작하였다.
    이 팀의 경우 신규 팀원들의 능력 및 업무 만족도 향상이 이 작업의 목적중 하나라고 하였다.
    새로 만드는 것만이 교육적으로 의미가 있고 업무 만족도를 향상 시킬수 있다는 것은 생각해 볼 문제이다.^^

  3. 2009.11.12 18:01 신고 neokido  댓글주소  수정/삭제  댓글쓰기

    좋은 내용 참 잘 읽었습니다. ^^

    제가 TDD와 리팩토링 관련 컨퍼런스에 갔었는데. 그때는 초창기라 TDD와 리팩토링에 대한 관심이 대단했던것 같습니다. 그런데 거기 발표자의 발표 내용에서 제가 느낀것은 그 발표자가 말하는 TDD와 리팩토링의 목표가 정확히 무엇인지 알수 없는 말들을 늘어놓았다는 것입니다. (그분은 그냥 TDD를 이용하고, 이렇게 리팩토링을 하면 소스가 이렇게 짧아지고, .. 틈만나면 리팩토링을 해서 좀더 멋지게 잘 돌아가는 코드를 만든다.. 어쩌고.. 저쩌고..)

    과연 TDD와 리팩토링의 목적은 무엇인가? 에 대한 나름대로의 답을 가지고 있을거라 생각합니다.
    하지만 그 나름대로의 생각이, 회사의 이익으로 나타나지 않는다면 그것은 의미가 없을것입니다.

    단지 개발자 자신이 좋아서 하는 리팩토링,
    내가 만든 코드가 상당히 간결하니 내것을 쓰는게 좋을꺼야.. 자 ~ 써.~..
    남들이 TDD랑 리팩토링은 좋은 것이고, 꼭 해야한다고 생각해서
    기타 등등..

    이런 생각의 개발은 프로젝트중에서 또하나의 구멍을 뚫어서 자원을 낭비하는 거나 다름 없는 것이라 생각합니다.
    이제는 개발자가, 사용자와 니즈에 대한 적극적인 자세와 마인드로 개발을 해야할 시대인듯 합니다.
    좀더 Business적인 관점의 개발 마인드를 가지고, 그러한 Business needs 를 구현하기 위해서, TDD나 리팩토링은 좀더 Agile하게 개발을 쉽고, 명확하게 할수 있는 아주 좋은 툴이 될것같네요.

    님의 항상 연구하고, 적용하고자 하는 모습에 저도 다시한번 자극을 받게 되네요 ^^

    자주와서 좋은정보 공유하고 싶습니다. ^^

    • 2009.11.13 10:40 신고 윤청하  댓글주소  수정/삭제

      크나큰 관심과 엄청난 피드백 감사드립니다.^----^
      저는 고객의 비즈니스 가치는 개발자에게 매우 큰 동기 부여라고 생각합니다. 개발자는 자신이 개발하는 기능이 고객의 어떤 환경에서 어떻게 동작하고 어떤 이로움을 주는지 명확하게 알아야 한다고 생각합니다.
      그래서 저는 개발자의 시야가 좀더 넓어질수 있는 '기능개발팀' 혹은 '교차기능팀'을 구성하는 것을 회사에 제안하고 싶지만..
      아쉽게도 아직은 어렵네요.. 기술적 배경으로 성장한 회사라 그런지 기술적 성장에 더 관심이 많은것 같습니다.^^

      TDD는 고객에게 꼭 필요한 기능들을 명확하게 개발하고 품질을 보장할 수 있는 좋은 방법중에 하나라고 생각합니다.~

      다시한번 좋은 말씀 감사드리구요~ 피드백은 언제나 환영입니다.^^

  4. 2010.04.21 11:01 신고 ryoo  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다..
    영업부와 항상 피해의식만 생겼었는데 이 글을 보니 개발자도 달라져야겠다는 생각이 드네요.
    개발자의 책임이 큰만큼 먼저 반성하고 주도적으로 이끌수 있는 프로젝트를 역량을 갖춰야겠습니다.

티스토리 툴바