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

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

최근에 올라온 글

최근에 달린 댓글

Carpe Diem

Life Style / 2009. 11. 11. 11:34
수개월 전부터 아침 지하철에서 영문 소설 읽는 것에 빠졌습니다.
전 지하철에서 책읽기를 좋아하는 편이라 제 가방에는 항상 1~2권의 책이 있습니다.
아침 지하철에는 사람이 매우 많습니다. 특히 제가 타는 4호선은 더욱 그렇죠.
영문 소설책은 아침 지하철에서 읽기에 매우 적합합니다. 작은 크기, 가벼운 무게...(물론 영어가 골치아프지만;)

최근 읽고 있는 소설은 "Dead Poets Society (죽은 시인의 사회)" 입니다.
"'Gather ye rosebuds while ye may,'" Keating repeated.
"The Latin term for that setiment is Carpe Diem. Does anyone know what that means?"
"Carpe Diem," Meeks, the Latin scholar, said.
"Seize the day."


가능 할 때 장미 꽃을 따라. ('Gather ye rosebuds while ye may,')

최근에 와이프랑 우리의 장미꽃은 무엇일까 고민해봤습니다.
그것은 바로 매년 해외여행가기 였습니다. (신혼여행 다녀오면서 만든 계획..)
그리고 결혼 1주년에 싱가폴을 다녀왔었습니다. (마이너스 통장으로..ㅠㅠ)
그리고 올해 2주년.. 지윤이 덕분에 예약해놨던 제주도행 티켓을 취소했었습니다.
애기가 생기면 여행가기 힘들다고 합니다. 
그래도 우리 부부는 내년 여행 계획을 세웠습니다. 당연히 지윤이랑 함께하는 여행!~
올해 못갔던 제주도를(마일리지 티켓임ㅋ) 내년 봄에 가고, 내년 가을에는 호주 혹은 터키를 다녀오는 계획을 세웠습니다.

개발자라면 누구나 자기 진로에 대해 고민할 것입니다.
지금까지 저에게 가장 어려운 질문은 "내가 뭘 해야 재미있을까?" 였습니다. 사실 다 재미있어 보이거든요ㅎㅎ
저는 질문을 바꿔보기로 했습니다. "내가 어떻게 해야 재미있게 할수 있을까?"
나름 세상이 다르게 느껴집니다. 하지만, 아직 저에게는 큰 숙제 입니다.^^
Posted by 윤청하
, |
   켄트백의 "익스트림 프로그래밍 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를 잘하기 위해 필요한 자료들을 정리해서 올려보도록 하겠습니다~ 감사합니다.


'Agile Experience' 카테고리의 다른 글

xper 11월 정기모임 회고  (12) 2009.12.01
우리 팀에 스크럼을 적용했어요 - 마무리  (12) 2009.10.28
xper 10월 정기모임 회고  (10) 2009.10.24
Posted by 윤청하
, |

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

교차 기능 개발팀 구성

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

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

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

XP 적용하기

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

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

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

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

문화 바꾸기

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

마무리

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

읽어주셔서 감사합니다!~ 
그냥 가지 마시고 리플로 피드백을 해주신다면 정말 정말 백만개 감사할 것 같습니다.^^
Posted by 윤청하
, |