|
오늘 |
전체 |
|
| 방문자 |
379 |
1721187 |
|
| 구독자 |
0 |
180 |
|
| 댓글 |
0 |
3706 |
|
| 참조글 |
2 |
966 |
|
|
|
|
|
|
|
|
jrogue군은 컴퓨터 관련 서적 서평을 길게 쓰지 않기로 했지만, 때로는 예외가 생기는 모양이다. 오늘은 인사이트에서 따끈따끈하게 구워낸 '테스트 주도 개발'이라는 책을 읽고 난 소감을 몇 가지 정리해보겠다.
며칠 전에 강컴에서 주문하지도 않은 책 한권이 jrogue군 앞으로 배달되었다. 강컴 우수회원이라서 그런가? 아니면 jrogue군도 모르게 주문을 해버렸나? 일순간 궁금증이 일었지만, 이미 포장은 뜯었고, (에라 모르겠다) 나중에 비용을 청구하면 그 때 해결하는 것으로 생각하고 넙죽 받았으니 읽고 보자. :P
하지만, 몇 분 지나지 않아 목차를 뒤적거리다 보니 해답이 풀리고 말았다. 바로 이 책을 번역하신 김창준님께서 역자 증정본을 한 부 보내오신 것이었다.
지하철 출퇴근하면서 들고 나니며 읽고난 첫 느낌은 바로 _무협지_였다. 켄트 벡 아저씨도 이런 표현에 동의할까? 어쨌거나, 무림 고수들이 경공법을 쓰고 무공을 쓰는 이야기가 자꾸만 떠올라서 웃음이 나온다. 원문도 재미있고(철학적이며 현학적인 표현이 있어 조금 어렵긴 하다), 번역도 잘되었기에(역자 주도 마음에 들고 단어도 재미있다) 소프트웨어 개발에 관심이 있는 분이라면 재미있게 읽을 수 있을 거라고 확신한다. 주의) 소프트웨어 공학에 별반 관심이 없고 하루 벌어 하루 살고 있다면 이 책 내용은 뜬구름 잡는 허망한 이야기로 비춰질 수도 있다.
자, 그러면 TDD(Test Driven Development)를 읽고나서 생각할 점과 배울 점으로 나누어서 부문별로 정리해보았다. 어디까지나 jrogue군 _의견_이므로 너무 심각하게 생각하지는 마시길... "Just for Fun!"
생각할 점
1) 천재 프로그래머에게 적용 가능한 개발 기법
앞서 TDD가 무협지 같다고 표현했는데, 그 이유는 타고난 고수(고급 개발자)가 아니면 TDD를 적용하기가 무척 어렵기(무림 절정 고수님들께서는 제발 아니라고 말씀하지 마시고, 옛날에 올챙이적 시절을 한번 생각해보세요~) 때문이다. 솔직히 jrogue군도 머리로는 어떻게 잘 해보면 TDD를 적용할 수 있을지도 모른다는 생각이 들지만 가슴 속으로는 아니라는 메아리가 울려퍼진다. TDD를 제대로 하기 위해서는 사고 방식의 전환이 필요하지만, jrogue군처럼 이미 지팡이 짚고 다녀야하는 노친네 개발자 입장에서는 결코 쉽지 않다. 전형적인 코볼 프로그래머가 능수능란하게 람다 함수를 써가면서 리스프로 프로그램 짜기를 기대하지 말자. T_T
우리 주변에서 쉽게 찾아 볼 수 있는 평범한 프로그래머는 아직 모듈 개념조차도 속 시원하게 머리 속에 넣고 있지 못하다는 사실에 비춰볼 때(note: 날고 긴다는 친구들이 들어온다는 마이크로소프트 사 면접 과정에서 모듈에 대해 _확실한_ 개념을 알고 있는 인력 비율은 5%에 그친다고 한다) TDD는 한마디로 TDD를 사용하지 않더라도 즐겁게 프로그램을 만들고 잘 먹고 잘 살 수 있는 수준에 오른 프로그래머에게 적합한 프로그래밍 개발 기법이다.
TDD를 부정하려는 생각은 추호도 없다. 실제로, TDD 자체가 몇안되는(진짜 간단하다고 착각할 수도 있다) 단순한 개념과 기법만으로 개발을 가능하게 만들지만, 원래 기초가 되는 초식을 익히는 과정이 더 까다롭고 어려우며, 일부 뛰어난 사람만이 제대로 익힐 수 있다는 사실을 명심하자. 예제 몇 개 보고난 다음에 TDD를 얕보지 마라!
2) 임베디드 부문 적용 가능성
솔직히 '파란 막대'와 '빨간 막대'만으로는 미묘한 실시간 성격, 레지스터를 직접 건들이는 하드웨어 인터페이스, 무지막지한 표준 문서와 돌처럼 딱딱한 스펙에 기반한 개발로 밀어붙이는 임베디드 부문을 뒷받침하기에는 역부족이다. 스레드 교착 상태를 어떻게 assert로 확인하지? 타이밍은 또 어떻구? 켁... 기계/전자/전산 인력이 짬뽕이 되어 보이는 물건은 모두 무기로 쓰는 이종 격투기를 벌이는 상황에서 TDD는 발목에 감긴 모래주머니로 보인다. T_T
설상가상으로 테스트 프레임워크는 고사하고 자바도 파이썬도 심지어 C++도 사용할 수 없으며, 순수 ANSI C랑 느려터진(속도 느려터진다) CPU와 쥐꼬리만한 메모리에서 개발하다보니 임베디드 부문에서 TDD를 적용하기는 하늘에 별따기가 아닐까?
jrogue군 생각에는 TDD는 뜻이 잘 맞는 몇몇이 in-house 소프트웨어를 만들기에 딱 적합한 방식으로 보인다. 문제는 이 세상에 존재하는 모든 소프트웨어가 동일한 문맥에 놓여있지 않다는 사실이다. 혹시 누가 임베디드 부문에서 성공적으로 TDD를 완료했다면(휴대폰이랑 PDA 소프트웨어 개발 사례는 사절!), 제발 jrogue군에게 편지 좀 날려주시라. jrogue군도 좀 써먹게... T_T
3) PSP/TSPi에서 주장하는 컴파일 전에 오류를 최대한 잡아내는 원칙
테스트 주도 개발은 PSP나 TSPi에서 주장하는 컴파일 전에 오류를 최대한 잡아내는 원칙에 정면으로 위배된다. PSP에서는 모든 컴파일 오류를 원시 코드를 출력해서 눈으로 잡아내는 원칙을 고수한다. 쉽게 말해, 컴파일러를 돌려서 오류를 잡아내는 습관을 죄악시한다. 이렇게 해서도 일이 잘 안풀리면 Peer Review나 Inspection와 같은 기법을 동원해서 사람 힘으로 잘못된 가정, 빠진 조건, 오류를 유발하기 쉬운 부문, 수행되지 않는 경로를 탐색한다. Peer Review나 Inspection 기법은 소프트웨어 공학 역사상 제대로 효과를 발휘한다고 검증된 몇 안되는 기법이므로 과연 이를 TDD와 어떻게 접목할 수 있을지 벌써부터 궁금해진다. 참고로 TDD에서 주로 사용하는 XP는 walkthrough에 가깝다.
배울 점
1) '파란 막대'유지와 일일빌드/조명탄 기법
언제나 동작하는 소프트웨어를 확보하여 앞으로 나갈 길을 미리 살펴본다는 점에서 TDD는 일일빌드와 조명탄 기법과 유사한 측면이 많다. 어느 순간에도 동작하는 소프트웨어 제품을 확보하고 있다는 사실은 가시성을 높이며, 개발자 사기를 진작시키며, 기능 추가나 수정에 필요한 베이스 라인을 제공한다는 측면에서 무척 중요하다.
2) Design by Contract와 함수 자체의 견고성 확보
TDD는 함수나 객체에 책임을 부여하는 방법으로 구현을 완성해나가는 'Design By Contract' 기법을 전체 프로그램으로 확장한 느낌이 강하게 든다. 어떤 작업을 수행하면서 얻어지는 테스트 슈트가 무엇인가? 바로 Design by Contract에서 정의한 Contract라고 볼 수 있지 않을까? TDD에서 얻은 경험을 토대로 일반적인 프로그램을 작성할 때도 항상 함수 진입과 진출 입/출구에 바리케이트를 치고 계약에 따른 조건이 맞는지 assert 문등으로 방어를 해 놓으면 개발 과정에서 쉽게 뭐가 잘못되었는지 확인할 수 있을 것이다.
다음 URL을 참조하면 더 많은 정보를 얻을 수 있다(아쉽게도 원문 서비스는 ACM 회원만 가능하다).
Designing software for ease of extension and contraction
3) 리펙토링과 직교성, 그리고 확장 가능성
객체지향 프로그래밍 언어를 활용해서 본격적인 리펙토링을 하지 않더라도 일반 C에서도 얼마든지 TDD에서 금기시 하는 중복을 제거하고 프로그램 구조를 탄탄하게 만들어나갈 수 있다. 직교성을 높이기 위해 중복되는 코드를 함수로 만들고, 구조체를 활용해서 연관있는 변수를 한 곳으로 모으고, 모듈 개념을 활용해서 인터페이스 부문을 가다듬는 방법을 얼마든지 활용할 수 있다. 광의의 리펙토링은 어떤 프로그래밍 언어에서도 적용 가능함을 깨닫자.
다음 URL을 참조하면 더 많은 정보를 얻을 수 있을 것이다.
On the Design and Development of Program Families
아... 이렇게 골치아픈 이야기를 듣고 있는 독자 여러분 얼굴이 문득 떠오르지만, 아까 야후! 사용자 인증 후 다 날아가벼러 다시 작성해야만 했던 이 글을 생각하면 jrogue군의 정성이 갸륵해서라도 용서해주리라는 생각이 든다. T_T
EOF
|
http://kr.blog.yahoo.com/jhrogue/trackback/8486/1357170
-
 codian 2005.01.06 21:59 [220.71.52.13]
-
"하루 벌어 하루 살고 있다면..."
너무 적나라하십니다 :)
답글쓰기
-
-
junaftnoon 2005.01.06 23:14
-
긴 서평을 써주셨네요. 감사합니다.
"천재 프로그래머에게 적용 가능한 개발 기법" 이 부분은 제 경험으로는 그렇지 않습니다. 특히 짝 프로그래밍이나 한 방에서 함께 일하기가 가능한 경우는 더더욱 그렇지 않더군요. 제 경험으로 보면, 통상 XP팀에 XP 실천법을 전혀 모르는 사람이 들어오면 짧으면 이삼일 길면 일주일이면 적응을 했습니다. 하지만 혼자서 독학하는 상황은 그리 쉽지 않다는 데에 어느 정도 공감을 합니다.
"임베디드 부문 적용 가능성" 저번에 한자리를 했던 박응주씨가 임베디드 쪽에 TDD를 적용해서 성공한 경험이 있습니다. 그 외에 외국에는 사례가 많은 것 같습니다. 제임스 그레닝(James Grenning)이라는 사람이 오래전부터 XP의 실천법을 임베디드 부문에 적용을 해서 성공했다고 알려져 있습니다. 논문도 많이 발표했고요. 프란시스코 시릴로(Francesco Cirillo)도 유명하다고 합니다.
http://xper.org/wiki/xp/EmbeddedSoftwareDevelopment 에 있는 링크를 참고하세요.
답글쓰기
-
-
세시아 2005.01.07 12:53 [210.94.41.89]
-
PSP에서 주장하는 컴파일 전에 오류잡기랑, inspection을 함께 얘기하신 부분은 좀 이상하군요. Inspection의 주 대상은 논리적 오류이지 compiler가 잡아낼 수 있는 에러가 아니라고 생각하는데요.
PSP 교육을 들었지만, 대부분의 사람들이 컴파일 전에 오류를 잡으라는 저 얘기는 말도 안된다고 생각하고 흘려듣고 말더군요.
답글쓰기
-
-
  2005.01.07 13:26
-
codian님, 제가 너무 적나라한 표현을 썼나요? :)
답글쓰기
-
-
 2005.01.07 13:28
-
창준님, 임베디드 관련 제공해주신 정보는 잘 읽겠습니다. 그런데, 관련 자료를 몇 개 읽어보니 조금 추상적이라서 실제로 임베디드 개발에 적용하기에는 아직 멀었다는 생각입니다. TDD는 선문답에 가깝다는 생각이...
답글쓰기
-
-
2005.01.07 13:38
-
새시아님, 물론 개발자에게 잘못된 정보를 제공하면 안되겠지만, 제 블로그는 "Just for Fun!" 성격이 짙기에 논문 수준의 용어 선별과 정확도를 기대하시면 안됩니다. 참고로, 저는 컴파일 전에 오류 잡는 버릇을 inspection처럼 정형화된 성격은 없지만 개인 walkthrough 정도로 취급할 수 있다고 생각하고 있습니다.
뱀다리) PSP에서 컴파일러를 돌리기전에 오류를 잡아내라는 이야기는 원고를 작성한 다음에 '퇴고'하라는 이야기와 유사합니다. 퇴고가 단순히 오탈자만 잡아내는 작업일까요? 마찬가지로 구문 오류를 찾는 과정에서 예상치 못했던 논리적인 결함을 찾아낼 수 있습니다.
뱀다리 2) 구문 오류 개수와 최종 소프트웨어 결함 개수와는 연관성이 있기 때문에, PSP에서 컴파일 전에 오류를 찾아라는 이야기를 그냥 단순히 웃고 넘기면 안될 것 같습니다.
답글쓰기
-
-
세라비 2005.01.08 00:39 [211.209.214.206]
-
TDD와 PSP는 궁극적인 목적은 같겠지만, 사실 철학 자체가 틀립니다. TDD는 경험을 위주로 하는 XP 진영에서 나온 방법론이라면, PSP는 (좁은 의미에서의) 소프트웨어 엔지니어링 진영에서 나온 방법론이죠. TDD와 PSP의 대조는 XP와 CMM이 거의 화합하지 못하는 것과 비슷하다고 생각합니다. 어느 방법론이 옳다는 주장과 상관없이 그 차이를 지적하신 것은 정확하다고 생각합니다.
답글쓰기
-
-
2005.01.09 11:26
-
세라비님, 좋은 지적 감사드립니다. 아무리 생각해도 소프트웨어 공학 부문은 정말 어려운 것 같습니다. 한번쯤은 특정 방법론이나 이론에 푹 빠져보는 방법도 좋겠지만, 다양한 분야에 걸쳐 책도 더 읽고 생각도 많이해서 자신에게 꼭 필요한 사항을 취사선택하는 방법이 최선인 듯이 보입니다.
답글쓰기
-
-
junaftnoon 2005.01.09 22:56
-
금요일 저녁에 시간이 되시나요? TDD를 임베디드 부분에 성공적으로 적용하고 있다고 하는 제임스 그레닝(직접 만나봤는데 무척 확신에 차 있더군요) 초청 강연을 서울에서 하게 되었습니다.
http://xper.org/wiki/xp/JamesGrenning
답글쓰기
-
-
cmsong 2005.01.10 19:06 [210.94.41.89]
-
창준님, 혹시 제임스 그레닝의 초청 강연 때 동영상 찍을 계획도 있으신 건가요?
참가하고 싶은데... 아~ 시간을 쪼개서 가볼 수 있다면 얼마나 좋을까~ ㅜ.ㅠ
답글쓰기
-
-
2005.01.11 16:03
-
창준님, 제가 참석하지 못하더라도(이번주 금요일에 아무래도 회사 워크샵이..) 제 동료(소프트웨어 공학을 전공한 똑똑한 친구가 있습니다)을 보내서 참석할 수 있도록 하겠습니다. 좋은 정보 감사드립니다.
답글쓰기
-
-
jsbase 2008.01.31 16:57 [61.111.255.118]
-
임베디드에서의 TDD라는 키워드로 검색하다가 읽어보게 되었습니다. 좋은 글 감사합니다. 그런데 아직도 임베디드에서의 TDD는 무리라고 생각하시는지요? 혹은 적절한 답을 찾으셨는지... 원문이 2005년에 작성된 글이라서 여쭤봅니다.
답글쓰기
-
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
인기도 :
