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

카테고리

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

최근에 올라온 글

최근에 달린 댓글

최근에 잘 나가는 회사의 팀장급 개발자 분이 하신 말씀이 생각 난다.
php를 좋아하면서 객체지향을 잘하는 사람을 본적이 없는데..ㅡㅡ^
그분의 말투는 마치 C style 개발자는 Loose Coupling, High Cohesion 과는 거리가 멀다는 것처럼 들렸다.
조금 비꼬아서 듣자면, C style 개발자는 스파게티 소스를 만들어낼 가능성이 크다는 것이었다.

내가 현재 재직중인 회사는 전형적인 C언어 개발 회사이다. 현재는 잘 모르겠지만 오래전(약 10년전)에 우리 회사에서 C언어로 만들어진 base library(자료구조, 로그, 통신등)들은 매우 훌륭했다. 어떤 도사분이신지는 모르겠지만 define으로 template까지 구현해놨다. 사실 현재 회사의 개발 능력으로 볼 때 그 base library의 출처가 의심스럽다.^^;; (깊이 알면 다친다..)
하지만, 솔직히 base library를 제외하고는 전체적으로 스파게티 소스에 가까운 경우가 많다. 물론 처음부터 스파게티 소스인 경우는 매우 드물다. 빈번한 customizing, 검증 받지 못한 코드의 커밋, 무분별한 BMT 성 코드 삽입등으로 인해 소스코드는 점점 스파게티처럼 꼬여만 간다.ㅠㅠ 이게 C로 개발하기 때문일까? (누가 답변좀~ㅋ)

나는 회사에서 객체지향으로의 패러다임 전환을 주장하고 있다. 하지만 꼭 C++을 쓰자는 것은 아니다.
단, 객체지향 언어에서 제공하는 것들을 잘 이용한다면 생산성에 더 도움이 될 수 있다에 한표를 던지고 싶다. (define문을 디버깅 한다고 생각해보면..끔찍하다)

나는 어떤 개발자의 주력 언어가 그 개발자의 개발 스타일을 어느정도 나타낼수 있지만 전부를 나타낼수는 없다고 생각한다. 그래도 패러다임이 다른 최소한 하나이상의 언어는 공부하는건 추천하고 싶다ㅋㅋ (요즘 python에 매료되었다는...ㅋㅋㅋ)

써놓고 보니..잡담이 되어버렸다는..ㄷㄷㄷ;; 
Posted by 윤청하
, |

객체지향 코덱 개발

제 업무의 60%는 표준 영상 코덱 개발입니다. 코덱개발은 성능과 품질이라는 trade-off를 가지고 있습니다.
더 많은 연산을 수행 할 수록 품질이 향상됩니다. 최근 멀티미디어 제품에서 품질 이슈가 굉장히 중요해졌습니다. 따라서 성능 개선이 가장 중요한 숙제중에 하나입니다. (대용량 미디어 처리를 위해 한 화면을 인코딩-디코딩하는데 약 2ms 이하로 유지해야 합니다.)
더불어 개발자에게 유지보수성(maintainability)은 버릴수 없는 가치 중에 하나입니다. 고객에게 직접적인 비즈니스 가치를 줄수는 없지만, 그 가치를 만들 수 있는 토대가 된다고 생각합니다.
기존의 영상 코덱은 주로 C언어로 개발되었습니다. 유지보수성은 철저하게 배재되었습니다. 자연히, 유지보수 가능 인력은 매우 제한되고, 기능 추가에 따른 위험은 매우 크며, 장애가 날 경우 원인 파악이 어려웠습니다. (대용량 미디어 처리 특성상 상용사이트에서 로그를 남기기 어렵습니다.)
그래서 저는 현재 기능 개발이 완료된 최신 영상 코덱(통신시장에서는 적용이 좀 늦습니다.)을 객체지향적으로 설계하고 개발하였습니다. (코덱의 복잡도가 매우 크게 증가해서 그랬습니다.ㅠㅠ 잘못한건가요??)

Subtype Polymorphism

Intellectual Wanderlust라는 블로그에 보면 "OOP란 조건문(if)을 줄이는 것"이라는 글에서 처럼 subtype polymorphism을 이용하여 조건문을 줄이는 것이 OOP의 핵심중 하나입니다. (IF문 안쓰기 운동도 있습니다. 껄껄^^ http://www.AntiIfCampaign.com 저도 동참하려고합니다(__ ))
보통 subtype polymorphism은 interface를 정의하는 base class를 상속(inheritance) 받아서 구현합니다.
따라서, virtual function을 자연스럽게 사용하게 됩니다.
(물론 C언어에서도 function pointer를 이용하여 비슷하게 구현할 수 있습니다. 좀 귀찮은 일이 많아 질 뿐이죠^^;;;)

Virtual Function과 성능 이슈

virtual function을 사용하게 되면 vtable이란 것이 생성됩니다. vtable을 이용하여 run-time에 어떤 함수를 호출할 건지 정하게 됩니다. 따라서, compile-time에서의 inline을 사용할 수 없습니다.(아픕니다.ㅠㅠ) 또한 vtable을 참조하여 함수호출이 이루어지는 경우 해당 주소로 redirect 해서 호출하게 되므로 성능이슈에 큰 영향을 줄 수 있습니다. 이러한 점들은 함수의 덩치가 크고 호출되는 횟수가 많지 않다면 전혀 문제가 될수 없지만, 영상 코덱의 경우 굉장히 호출횟수가 많은 작은 함수들이 다수 존재하기 때문에 문제가 됩니다.
또한 객체들의 메모리 사이즈가 virtual function의 갯수 곱하기 4bytes만큼 증가합니다.(32bit machine 기준)
이는 작은 internal memory(2MB under)에서 많은 작업을 해야 하는 DSP에서 제약이 될 수도 있습니다.

그럼 어떻게 해결할 수 있는가?

저는 호출횟수가 많지 않은 곳에서는 subtype polymorphism을 적용하고, 호출횟수가 많은 곳에서는 interface class에 기본적인 내용을 구현하였습니다. (다행히 단순한 기능들이라 가능했습니다^^;;;) 
결국 근본적인 해결이 아니기 때문에 부족한 부분이 많습니다. 그래서 찾아보고 고민하고 있습니다.!! (도움을 주세요~)


인터넷을 찾다가 virtual function을 template으로 대체 할 수 있다는 구문을 보고 찾아낸 방법입니다.
다음과 같은 방법으로 template을 사용하여 virtual function을 구현할 수 있습니다. 

결과는 child의 print()가 호출됩니다.
child = 123

약간(?)의 노력이 필요하지만 필요한 것을 모두 얻을수 있습니다. (base class가 복잡해 질듯..ㅋㅋ)
추후에 코드를 리팩토링 하면서 조금씩 적용해봐야 할 것 같습니다.^^
어디 더 좋은 방법 없나요?~~
Posted by 윤청하
, |
어제 회사에서 한분이 문자열 복사에 대한 질문을 하셨습니다. 
처리 결과를 문자열로 복사하여 리턴하는 부분의 코드였습니다.
그분의 코드를 리뷰하던 중에 다음과 같은 코드를 발견했습니다.
strncpy(rtString, "이건 이래서 실패했습니다.", sizeof(rtString));
해당 코드는 위험한 부분이 있습니다. 복사하고자 하는 문자열의 길이가 sizeof(rtString)의 크기보다 작다면 null 문자까지 정상적으로 복사되지만 그 크기를 넘어간다면 문제가 될 수 있습니다. 
당장은 buffer overflow가 발생하지 않지만, 추후 rtString을 출력하거나, 복사할때 큰 문제가 생길수 있습니다.

strncpy()의 man page를 보면 다음과 같이 기술하고 있습니다.
The strncpy() function is similar, except that not more than n bytes of src are copied. Thus, if there is no null byte among the first n bytes of src, the result will not be null-terminated.
이와같은 경우에는 snprintf() 쓰는 것이 더 안전합니다. 다음 예제를 보겠습니다.
위 코드의 실행 결과는 다음과 같습니다.
strncpy = 12345*****
snprintf = 1234

결과에서 snprintf()는 입력된 버퍼의 길이에 맞게 null 문자까지 포함하여 안전하게 복사해 주고 있습니다.
사실 매우 초보적인 내용일 수 있지만 잘 알지 못하고 쓰면 나중에 큰 화를 부를수도 있기에 정리해봤습니다^^

'Programming' 카테고리의 다른 글

여러분의 소스코드는 안녕하십니까?  (7) 2009.11.24
개발언어와 개발스타일  (5) 2009.11.23
Subtype Polymorphism과 성능 이슈  (4) 2009.11.17
Posted by 윤청하
, |

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 윤청하
, |

토요일 오후 2시, 명동 LG CNS 본사 2층 대회의실에서 xper 10월 정기모임이 진행되었다.
나는 청하 쥬니어 탄생 준비로 미뤄왔던 xper 정기모임에 처음으로 참가하였다.

LG CNS 건물 1층에서 어떻게 들어가야 할지 방황하던 다른 두분과 함께 모임 장소에 도착했을때에는 10명 정도 되는 분들이 자리에 계셨으며, 발표를 위한 셋팅 준비를 하고 계셨다.
일단 조촐하게 그룹을 만들어서 자기소개를 진행하고, 이런 저런 얘기를 나누었다.
처음 참석하는 모임이고 오프라인으로 아는 분들이 한명도 없어서 내심 긴장했는데, 편안한 분위기 속에서 진행되었고, 다른 분들도 딱히 서로 잘 아는 것 같지 않아서 좋았다^^;;;

첫번째 발표, "존재하기와 발전하기 - 변신철"
우리의 일상은 엉망진창이다.
TDD는 명료하며, 현재 엉망진창이라는 것을 확실히 알려준다.
짝프로그래밍은 같이 바라보는 것이다. "너 봤니? 나도 봤어" 같이 하면서 성공하게 되면 하이파이브를 하게 되고 매우 신나게 된다.
비난 받지 않는 회고를 진행하였다. 팀원들은 비난받지 않을 권리와 경청해야할 의무를 가진다.
비난 받지 않기 때문에 개인적인 일까지 회고한다. "웹서핑 시간이 많아졌어요. 이유는 핸드폰을 사야해서..ㅋ"
애자일은 우리를 우리(짐승을 가두어 기르는 곳)에 가둔다. 화를 낼수 없다.
혁명은 실천법(practice)나 개발 프로세스로 쉽게 얻을 수 있는 것이 아니다. 노력하고 힘들어져야 변화할 수 있다.
소통하기 어려운 팀원이 있었다. 드디어 소통하게 되었다. 그것은 내가 힘들어지고 바뀌게 되어서 된일이었다.
애자일이 실천법으로만 설명되지 않았으면 좋겠다.
변할만 할때 변화한다. 은탄환(silver bullet)은 없다.
애자일은 사람과 관련된 일이다. 켄트백왈 "프로그래밍은 사람이 하고 사람에 의해 사람을 위한 것이다.(맞나?^^)"
TDD가 가장 쉬었다는 변신철님, TDD를 실무에 적용하기로 마음먹고 실천한지 몇개월이 지났지만, 아직도 TDD를 자주 빼먹는 나로써는 매우 공감할 수 없는 표현이었다.ㅠㅠ
변신철님은 TDD를 통해 프로젝트를 성공적으로 이끄셨다고 한다. 개발 플래폼에서 완료된 프로그램을 상용 플래폼으로 이식할 때에 작업이 한번에 이루어졌으며, 그 후 3년간 개정 없이 상용 서비스 중이라고 한다. 일어나서 박수라고 치고 싶었다.ㅠㅠ

질문/답변 시간에 나왔던 내용들..
애자일 팀을 구분할 수 있는 특징은 무엇인가요?
-  야근을 안한다.(진심으로 부럽다ㅠㅠ) 팀장이 소리치지 않는다. 벽에 무언가 많이 붙어있다.
요구사항, 품질, 팀의 밸런스는 어떻게 조절하나요?
- 품질이 가장 높은 우선순위를 가진다. 잦은 릴리즈 주기로 높은 품질을 제공했더니 고객이 스스로 요구사항을 줄였다.
- 팀장이 고객 옆에서 계속 질문하며 일한다. (질문은 정확히 기억나지 않음)

휴식시간에 있었던 김창준님의 부연설명 (어떤 내용에 대한 부연설명이었는지 까먹었음ㅠㅠ)
위험을 어떻게든 줄여서 애자일을 조직에 적용하려 한다면, 성공하기 어렵다. 책임을 지고(위험을 감수하고) 애자일을 적용해야 성공할 수 있다. (노출, 다치기 쉬운, vulnerable)
어떻게든 쉽게, 위험 없이 애자일을 적용하려고 했던 내 지난날을 반성했다ㅠㅠ

두번째 발표, "캐빈문화 소개, 즐거운 일터 만들기 - 김종욱"
캐빈문화란, 다음 뷰 서비스를 개발하기 위해 기획자, 개발자, 디자이너 등이 한군데 모여 팀을 이룬 것이다. (장소가 옥상이라 캐빈이라 지은듯.. 창문 밖으로 한라산이 보인답니다ㅠㅠ부러우면 지는거다..)
우리는 포스트잇으로 테스크 관리를 한다.
각 테스크는 추정시간이 따로 없으며, 4시간단위로 쪼갠다. (갯수로 파악한다 - 한눈에 파악될듯..)
현재 프로젝트 상황은 포스트잇을 백로그/ToDo/Doing/Done/협의중 으로 분류하여 화이트보드에 붙여서 표현한다.
백로그로 파악되지 않는 일상 업무를 양지로 끌어올리기 위해 노력했다.
주간회고를 통해 구성원들이 더 많은 고민을 하게 만들었으며, 더 많이 공개하도록 하였다. (도움, 칭찬, 격려, 비폭력대화, 성향별대화)
도반(불교, 함께 도를 닦는 벗)을 얻는 것이 중요하다.
애자일 문화를 다른 팀까지 전파시키는데에는 조직적인 한계가 있다. (새로운 회사를 차리는게 빠를수 있다.)
직군은 할일을 제한시키며 많은 시도를 하기 힘들게 한다. 직군 파괴를 해야한다.
여유(다음의 ctime)를 주어서 더 많은 시도를 할수 있도록 해야 한다.
업무를 포스트잇과 화이트 보드로 하는 것은 현재 우리팀이 하고 있는것과 다르지 않았다. (기분 좋았다^^)
직군 파괴는 정말 괜찮은 아이디어 같았다. 현재 우리 회사도 직군을 더 세분화 시키려고만 하고 있다.ㅠㅠ

개인 회고
  • 그동안 실패했던 TDD를 다시 제대로 적용해야겠다는 다짐을 하게 되었다.
  • 애자일 문화가 전파되기 위해서는 더 많은 도반이 필요함을 느꼈다.
  • 기존의 세분화된 조직에서 애자일 문화를 전파시키는데는 한계가 있다는 것은 아쉽다.
    정말 방법은 없는 것일까?
    내가 애자일 팀으로 이직을 하던지, 새로 회사를 차리던지 하는게 유일한 방법일까?
  • 애자일과 야근과의 관계를 명확히 알수 있어서 좋았다.^^
  • 변화하고 싶다면, xper 정기 모임을 추천한다! (xper 메일링 리스트)

Posted by 윤청하
, |
2009/10/12 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 1편
2009/10/13 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 2편
2009/10/19 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 3편
2009/10/28 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 마무리

1편에서 빼먹은 내용

이 글은 수개월에 걸쳐 스크럼을 개발팀에 적용한 경험을 바탕으로 작성되었다.
개발팀은 7명의 개발자로 이루어져 있으며, 팀의 주된 업무는 통신용 서버 시스템 및 플래폼 개발이다.
실패든 성공이든 각자의 경험을 공유함으로써 한국의 개발자들도 인간적인 삶을 살수 있다는 믿음으로 이 글을 작성한다.

스프린트 회고

스크럼에서 스프린트 사이에 스프린트 회고 및 스프린트 계획 회의는 반드시 해야 할 일들이다.
초기의 스프린트 회고는 스프린트 동안 스크럼을 적용하면서 각자 느낀점을 나누는 정도였다.
데모를 하자는 의견을 냈으나, 다수의 분들이 데모의 필요성을 느끼지 못하여 적용하지 못했다.
몇번의 스프린트가 진행되고 나서 우리는 스프린트 데모의 필요성을 느꼈다.
우리는 스프린트 계획 회의에서 각 스프린트 백로그를 어떻게 데모 할 것인지 결정하였다.
결과적으로 우리는 스프린트 회고를 하면서 자연스럽게 스프린트 백로그 별로 데모를 진행하게 되었다.
말로만 주고받던 회고에서는 없었던 날카로운 피드백을 눈으로 보이는 데모를 진행하면서 주고받게 되었다.
우리는 점점 오픈되고 있었고 우리의 제품은 점점 발전하고 있었다. 조금씩 조금씩..

스프린트 계획 회의

우리의 스프린트 계획 회의는 한번에 끝나는 일이 없었으며, 지연되기 일쑤였다.
회의를 지연시키는 원인중 하나는 스프린트 백로그의 예상 시간을 결정하는 일(추정)이었다.
나는 다음의 책에서 소개하는 플래닝 포커를 적용해 보기로 하였다.
불확실성과 화해하는 프로젝트 추정과 계획 
(규모추정, 우선순위, 일정배치)
Agile Estimating and Planning
마이크 콘 지음 (이병준 역, 인사이트)

재미있게도 위의 책을 주문 하였더니 인사이트에서 플래닝 포커를 할수 있는 매우 이쁜 카드를 보내주셨다.

불확실성과 화해하는 프로젝트 추정과 계획 책을 주문하고 받은 선물

플래닝 포커는 우리가 스프린트 계획 회의를 재미있고 빠르게 진행 할 수 있도록 실질적인 도움을 주었다.
특정 사람(특히 경력이 많은)의 의견이 99% 적용되던 이전과는 달리 우리는 해당 백로그에 대한 여러가지 관점을 통해 매우 의미있는 예상시간(추정치)를 만들 수 있었다.

회의를 지연시키는 다른 원인은 스크럼 마스터를 중심으로 스프린트 백로그를 하나씩 검토해 나가는 방식이었다
우리는 스프린트 백로그를 순차적으로 하나씩 검토하고 정리하는 방식이 회의에 참가하는 리소스(팀원들)를 크게 낭비하는 것임을 깨달았다. 이는 마치 나와 관계 없는 회의에 참가하는 것과 같았다.
우리는 고민 끝에 스토리 카드와 포스트잇을 사용하기로 하였다. 절차는 다음과 같다.
  1. 스프린트 계획 회의 전에 스크럼 마스터는 스토리 카드를 출력해 온다.
  2. 회의실 벽에 스토리 카드를 분산시켜서 붙여놓는다.
  3. 스크럼 마스터는 계획 회의 시작을 알리고 팀원들은 모두 일어난다.
  4. 팀원들은 각자 관련있는 스토리 카드에 앞에 서서 추정치를 의논하고 예상되는 테스크들을 포스트잇에 적어 붙인다.
  5. 모든 스토리 카드가 추정될 때 까지 계속 한다.

스토리 카드와 포스트잇의 내용은 아래와 같다.
  • 스토리 카드에는 스프린트 백로그 번호와 내용이 간략하게 적혀있다.
  • 스토리 카드에는 스프린트 백로그의 추정치 및 데모방법을 적을 수 있는 공간이 있다.
  • 포스트잇에는 테스크 내용, 추정치 및 테스트 방법들을 적을 수 있다.
  • 스토리 카드의 추정치는 일 단위로 하였으며 테스크의 추정치는 시간 단위로 하였다.

우리의 방법은 대성공이었다. 
2~3시간의 스프린트 계획 회의에서 끝내지 못한 내용들을 단, 30분 만에 끝낼 수 있었다.

아날로그로의 귀환

이제 우리의 스프린트 계획 회의의 결과물은 스토리 카드와 테스크들을 적은 포스트잇이다.
따라서 우리에게 디지털로 저장하는 것은 매우 귀찮은 일이 되었다. 
히스토리를 남기길 원하셨던 팀장님 마져 손을 드셨다. 
사실 히스토리를 남기는 게 좋다ㅠㅠ 단지, 우리는 귀찮아서 안할뿐이다.
그래서 우리는 기존에 사용하던 화이트보드보다 더 큰 사이즈를 주문하여 다음과 같이 사용하고 있다.

스프린트 백로그 화이트보드

자세히~

포스트잇을 사용하게 되니, 각 테스크를 3단계(준비, 진행중, 완료)로 구분하여 관리할 수 있었다.
데일리 미팅 시간이 좀 더 역동적으로 변하였으며, 팀 영역에 들어오는 어느 누구도 현재 팀에서 진행중인 작업 내용을 꽤 자세히 확인할 수 있게 되었다.
포스트잇을 하나씩 완료영역으로 옮겨 붙이면서 쾌감을 느끼기도 했지만, 진행이 잘안될 때에는 큰 스트레스로 작용하기도 하였다. 
日新又日新 : 우리는 스크럼이 우리가 서로 커뮤니케이션 하기 편한 형태로 점점 진화하고 있다는 것을 느낄 수 있었다.

다음 편은 내가 느낀 우리팀과 스크럼의 한계에 대해 작성해보고자 한다. 
피드백 좀 부탁드려요~~~~~^----------------------^
Posted by 윤청하
, |

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

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

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

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

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

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

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

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

스크럼의 빠른 피드백

8주에 걸친 2번의 스프린트가 끝나고 우리 팀은 처음으로 강남 토즈에서 팀 미팅을 진행하였다.
주제는 "스프린트 회고 및 다음 분기 프로젝트 계획" 이었다.
미팅은 하루 종일 진행 되었고, 프로젝트 별 특정 주제까지 언급하였으나 누구 하나 지루해 하지 않았다.
이유는 간단하게 스크럼에서 찾을 수 있었다. 
우리는 이미 4주간 서로간의 업무를 공유하고 있었기 때문에 자신과 관련이 없는 프로젝트라 할지라도 듣고 이해하고 의견을 개진할수 있게 된 것이었다.
이는 개인 회고를 통해서 고백되었다.
"하루 목표가 분명하기 때문에 업무 시간에 더욱 집중 할 수 있었어요."
"데일리 미팅때 모두가 있는 자리에서 이슈를 설명하니 간단히 해결되는 경우가 많았어요."
"팀원들이 어떤 작업을 하고 있는지 알고 있다는게 도움이 되네요."
스크럼이 이렇게 빠른 피드백을 줄수 있는지 우리는 상상하지 못했었다.
또한 스크럼 하기 전에 진행되던 프로젝트가 오랫동안 지연되고 있었는데(결과물 없이) 약 8주동안 큰 진전이 있었으며 나름 의미있는 릴리즈를 시행하였다.


어떻게 정리할까?

우리는 화이트보드에는 데일리미팅에서 제시되는 테스크를 정리하고 엑셀에는 스프린트백로그를 정리하였다.
엑셀 파일은 공유하기 힘들어서 대부분의 내용 작성은 팀장님이 하셨다.
우리는 백로그를 해당 담당자가 직접 작성하고 관리하기를 원했다.
우리는 여러가지 스크럼 툴을 사용해보기로 하였다.
우리의 요구사항은 "간단한 GUI, 쉬운 사용법 이었다."
  1. IceScrum (http://www.icescrum.org/)
    - 아기자기하고 친근한 GUI로 우리의 눈길을 끌었으나, 사용법이 어려웠다.
    - 현재 IceScrum2가 릴리즈되어서 제공중이다. (사용해 보지 못하였으나 많이 개선된 듯한 느낌~)

    IceScrum2의 스토리를 이용한 스프린트 백로그 관리

  2. Trac (http://trac.edgewall.org/)
    - 개인적으로 위키를 매우 좋아해서 추천했으나 팀원들의 위키 사용 반대로 좌절되었다.
    - 현재 사내에서 사용중인 ClearCase(SCM)와도 연동할수 있어서 많이 끌렸었다.

    프로젝트 관리용으로 많이 쓴다는 Trac

  3. Pivotal Tracker (http://www.pivotaltracker.com)
    - 웹에서 서비스하지만 무료라서 일단 환영받았다. (개발 서버 부족으로 따로 웹서버를 돌릴 여유가 없었다.)
    - 직관적이고 깔끔한 GUI가 인상적이었으며, 사용법 또한 간단하였다.
    - 스프린트 시작일을 지정할 수 없다는 단점이 있었다.

    Pivotal Tracker의 스토리 관리

여러가지 툴을 검토해보고 써본 결과 우리에게는 Pivotal Tracker가 가장 알맞을 것이라는 결론을 내렸다.
결론을 내린 다음 스프린트 부터는 Pivotal Tracker를 사용하였다.

툴만 정하면 될것이라 여겼으나 툴 사용 첫날부터 삐걱거리기 시작하였다.
Pivotal Tracker에는 스토리 밑에 테스크라는 개념이 없는데 테스크 별로 모두 웹에 등록하려면 매우 비효율적이라는 것이었다.
XP의 윈윈윈 정신에 입각하여 우리는 어느정도의 크기로 스토리를 작성할 것인지, 테스크 관리는 어떻게 할 것인지 고민하였다. 고민의 결론은 다음과 같다.
  • 스토리는 비지니스적인 가치를 지닌 하나의 기능 정도의 크기를 갖는다.
  • 스토리는 프로젝트 담당자가 팀장님과 협의하여 작성한다.
  • 테스크는 해당 스토리를 완성하기 위해 필요한 작업들을 1~2일 정도 크기를 갖는다.
  • 테스크는 데일리미팅에서 화이트보드에 작성한다.


처음 블로그를 시작하여 올리는 글들인데 쓰다보니 스스로 회고도 되고 굉장히 재미있네요^^
다음편에서는 결국 모두 아날로그로 돌아가게 된 사연을 써보겠습니다. 감사합니다.
Posted by 윤청하
, |