한빛출판네트워크

▶ Introduce

개발자에게 비젼을 제시해주는 책

이 책은 개발을 어떻게 해야하는지에 대해서 내용을 담고 있을뿐더러 개발하는 사람의 목표를 어디까지 두어야 하는지를 담고 있는 책입니다. IT 개발의 기본 개념은 다른 무수한 원천 기술을 통해서 응용을 하는 경우가 대부분일 것 입니다. (안 그런 부분도 있지만 그런 분들은 엄청난 내공(?)을 가지고 계신분들이기 때문에 여기에서의 언급은 제 스스로를 위해서라도 안하는게 좋을 것 같네요.)

그래서, 응용 기술을 하는 입장에서 잘났다고 난척할 필요도 없고 별볼일 없다고 치부해서도 안된다고 생각합니다. 여기에서 미래의 비젼이 갈라진다고 할 수 있습니다.

"고품질 쾌속 개발" 이라는 화두 뒤에는 무었이 있을까요?

남는 시간이 있을 것 입니다.
이 시간을 잘 이용하고 이를 통해서 Level Up과 다음에 무엇을 할 것인가? 미래를 위해서 무엇을 준비할 것인가를 고민해야 합니다.

개발을 하는 사람들과 이야기를 해보면 몇가지 유형으로 나눌 수가 있더군요.

1. 자기가 아는 것만 할려는 사람
- 조직에 적합하지 않는 사람 : Paltform을 개발하거나 기반 기술을 하는냐? 아니다.
- 적합하지 않는 일만 할려는 사람 : 직장이나 조직은 목표가 있는데 Road Map 문제가 있다.

2. 많은 것에 대한 기술에 관심은 가지고 있지만 적용하기 힘든 사람
- 남에게 일을 만들어 줄려는 사람 : 기술만 검토해주는 사람
- 적합하지 않는 일만 할려는 사람 : 학교의 동호회 수준으로 생각하는 사람 ...

3. 아무 생각이 없는 사람
- 고민이 없는 사람 : 시키는 대로만 하겠다는 ...
- 욕심만 앞서는 사람 : 잘 모르면서 설계나 PM 업무는 언제하냐고 투덜대는 ...
- 자기 주도의 사람 : 기회가 생기면 자기는 잘 할꺼라고 호헌장담하는 사람

4. 다 잘하는 사람
- 천부적인 재능이 있는 사람
- 노력하는 사람

이 모든 종류의 사람들이 늘 고민하는 것은 일찍 집에 가는 것일 것 입니다.
(정말 안 그런 사람들도 있기는 하지만 ... 그렇게 바람직하다고 생각지는 않습니다.)

하지만, 세상은 알고있는 것 하나만 가지고 살 수 있는 세상은 아니더군요.

그러면, 과연 각자의 성향에 따른 목표가 있을 것인데 좀더 가치있는 일을 하고자하는 고민은 없어보입니다. (물론, 저에게만 국한된 이야기이기는 합니다만 ... 오해가 없었으면 합니다.)

앞으로의 세상에는 많은 기반 기술들이 난무할 것이고 (지금도 마찬가지입니다.) 사라질 것 입니다.

이들 기술을 다 배우는 것은 무리이지만 ...

따지고 보면 그런 기반 기술 역시도 세상에서 툭하고 떨어진 기술들은 아니라고 생각합니다.

본인은 개발에서 손뗀지 정말 오래 되었지만 이 책을 통해서 개발을 하고 있는 직접적으로 연관된 동료들과 함께 이 책에 대해서 심각한 논의를 해 보았습니다.

아울러 다소 개발과 연관없는 이야기라고 생각이라도 생각과는 다르다고 딱닥한 의견보다는 진솔한 의견이 있다면 좋겠습니다.


▶ Prolouge
그렇다면 개발자하는 사람이라면 집에 일찍 갈 수 있을까?

소프트웨어의 품질을 높이는 방법이라는 의미를 다르게 이야기 해보면 착오를 없애는 길이고 좀더 쉽게 이야기하면 두번 세번 해야 할 일들을 한번에 줄이는 것입니다.

개발자가 평생 개발을 할 것이 아니라면 마인드가 좀 바귀어야 할 것 이고 ...
가져다가 쓰는 기술인 경우 그것을 활용하는 입장이라면 좀 더 열린 마인드를 가지고 있어야 할 것 이다.

다른 것보다 이 책에서 주목할 만한 내용들은

1. 전문가들의 인터뷰

2. 저자의 한마디를 들 수 있다.

가지 않아야 할 길에 대해서 자세히 이야기 하고 있고 본인은 개발에서 손을 놓은지 좀 되지만 ...

이런 책을 오래 전에 보았다면 개발하면서 막막할 수도 있는 순간에 해결점을 찾을 수 있는 많은 조언과 해결 방법들이 있습니다.


▶ Result

그래도 중요한 것은 마인드 ...

아주 좋은 개발 방법론이나 실천 및 도구가 있다고 해도 업무에 대한 마인드가 무엇보다 가장 중요하다고 할 수 있다.

그런 점에서는 다소 만능 일 것 같아보이는 표현들이 좀 거북하기는 하지만 좀처럼 찾아보기 힘든 책 중 하나로 볼 수 있다.

테스트 주도의 개발이라는 말은 다르게 말해서 다른 사람과 같이 개발 방법 및 품질에 대한 고민을 해야지 이루어 낼 수 있는 성과이다.

아무리 혼자서 개발을 완벽하게 한다고 해도 1인 개발 체계인 경우를 제외하고는 절대로 순수하게 잘 될 것이라고 판단을 하는 것은 무리라고 생각을 한다.

정형화된 개발에 대한 절차가 없는 스타일의 개발 조직이라면 늘 땜질에 고객의 요구에만 끌려다니게 되고 변명처럼 시간이 부족하다고 말만 나올 뿐이다.

일은 회피하는 것이 아니라 적극적인 마인드로 수용이 되어야 하는 것이고 그러기 위해서는 생산성 및 품질을 회사의 요구에 의해서 진행이 되어야 하는 것이 아니라 개발자들의 기본 소양이라는 것을 잘 알려준 책이다.

프로그램을 개발할때 시간에 쫓겨서 실제로 개발을 하다가 보면 자신이 만든 버그에 늪에 빠지곤 한다.
버그를 잡기 위해 그 버그를 우회하고 다른 코드를 더 넣다가 우리는 찾기 힘든 버그의 늪으로 서서히 빠져든다.
이런 버그의 늪에서 우리를 구해줄 한가지 방법론이 TDD가 아닌가 생각이 든다.
아무리 바쁘더라도 내가 만든 기능을 테스트를 통해서 완벽한 확신을 가지고 코딩을 한다면 실제 개발보다는 오래 걸릴지라도 버그에 늪에 빠지는 일은 적을 것이라 생각한다.
"바쁠수록 TDD를 사용해서 코딩하라." 이책을 읽으면서 느낀 점이다.

책의 내용을 살펴보자면..
처음 TDD를 접하는 입문자에게 적합한 책으로 판단 된다.
간단한 메소드 단위 테스트를 시작으로 JUnit3과 JUni4에 대한 설명
조금 심화과정인 Mock을 이용한 TDD 및 DbUnit, Unitils등
TDD의 기본부터 중급자까지 사용가능 한 책으로 보인다.
그리고 가장 이색적이였던 9장인 FAQ를 통해서 TDD를 배우면서 궁금했던 점을 조금이나마 해소해준다는 점이다.
그리고 중간중간 전문가와의 인터뷰를 통해서 전문자의 경험담을 들을 수 있어서 좋았던거 같다.

이 책은 TDD를 공부하는 사람에게 꼭 추천해주고 싶다.
당신도 TDD를 공부하신다면 이책으로 시작해 보시는건 어떤가요?

알찬 책이다.
저자가 "꼭 한 번 읽어보시기 바랍니다"라고 자신있게 말하는 이 책을 나는 아끼는 사람들에게만 살짝 알려주고 싶어지는 책이다.
그만큼 프로그래머에게 유용하고 좋은 책이라는 뜻이다.

주로 웹 애플리케이션을 개발하는 개발자 이다보니 다른 분야의 개발자 보다 TDD에 대해 조금은 회의적인?? 생각을 갖고있었다. 하지만 이 책은 TDD 뿐만이 아닌 일반적인 JAVA 개발자들에게도 아주 유용하다. 꼭 테스트 주도 개발 방식을 적용하지 않더라도 JUnit , DbUnit등 개발을 하면서 우리가 한번쯤은 사용했을 법한 라이브러리에 대한 상세한 소개와 사용법, Tip 게다가 Eclipse에 유용한 tip까지 알려주고 있는 친절한 책이다.

가장 흥미롭게 읽었던 부분은 7장 개발 영역에 따른 TDD 작성 패턴과 9장 FAQ 부분이었다. 하지만 가장 아쉬웠던 부분 역시 7장이 아니었나 싶다. 많은 얘기를 하고 싶다보니 조금은 수박 겉핥기식의 내용과 온갖 라이브러리의 나열만이 있는 것 같았기 때문이다.

TDD의 실천법 및 도구라는 제목에 걸맞게 다양한 툴을 소개하고 있다. 툴의 사용에 짧은 예제가 나오는데 예제의 연관성이 떨아져 아쉬웠다. 예제의 테스트 케이스들을 뒷부분까지 이어서 발전 시켜 나가는 형태로 독자가 함께 따라하며 TDD를 맛볼 수 있는 기회가 주어졌더라면 더 좋았을 것 같다. 물론 마지막 10장에 실습 예제가 나오기는 한다.

솔직히 아직은 TDD라는 것이 나는 낯설다. 그러나 이 책을 통해 꼭 TDD를 위한 것뿐만이 아닌 한명의 JAVA개발자로서 한단계 업그레이드 된 나를 느낄 수 있었다.

급변하는 java의 세계에서? 이 책은 존경하는 선배님들의 조언이 가득한 책이라고 생각한다.

테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구 - 채수원

TDD 적용이 잘된 프로젝트 성공적인 프로젝트는 왠지
토끼와 거북이의 경주에서 거북이가 느리지만 토끼간까지 챙겨가는 성공적인 경주가 아닐까 하는 생각이 드네요!^_^

이전부터 TDD에 대해서 이론적으로만 얇게 알고 있었는데
개인적으로 책을 통해서 한걸음 더 다가가는 계기가 되었다.

현재까지 개발할 때면 항상
1. MFC나 C#, VB 같은 경우에는 개발이나 수정시 MessageBox 를 이용하며 값을 확인하는 방식.
2. Java, FLEX 나 Python 같은 경우엔 시스템 출력하는 방식이나
3. 클래스 내에 임의로 main 을 만들어서 모듈을 테스트 하는 방식.
4. Python 을 제외하고는 디버그로 중단점을 이용하여 처리를 하는 방식.
5. 값 체크 용도로 ValidationMethod 를 만든다거나 하는 방식.
이런 방법을 이용해서 Test를 하면서 개발을 하였었었다.

그런데 이번에 TDD를 책을 통해 접하게 되면서 TDD에 쓰는 프레임워크들을 좀더 사용해 볼까한다.
개인적으로 위와같이 개발환경이 너무 다양하고 누구나 그렇듯 일정이 빠듯한 경우도 있기 때문에
TDD를 적용한다면 특정 모듈과 같은 컴포넌트로 적용범위가 나오지 않을까 생각한다.

개인적인 업무와 관련지어 TDD를 생각하면 기존업무에는 TDD 적용이 거의 불가능 한점이 있다.
몇년에 걸쳐 TDD를 적용하지 않은 패키지를 개선 및 기능 업데이트 등을 하고 있기 때문에 힘든점들이 많다.

TDD의 경우에는 신규 Project 성격에 따라서 적용여부라든가
적용 범위를 생각해서 도입해 보는것이 다소 실무애서 다급한 일정이 아니라면
적용해 보는 것이 아닐까 생각한다.

개인적으로 책을 읽으며 리팩토링 측면에서 확실히 TDD의 장점이 있는것 같다.
SI 처럼 일정내에 마치기만 하고 정상적으로 돌아가기만 하면 끝나는
죽음의 레이서가 아니고 지속적인 패키지 제품을 개발한다면
TDD는 나쁘지 않은 선택으로 보인다.

개인적으로 공부삼아 Android AP 개발시에 TDD를 적용하여 개발해 해볼까 한다.
아직까지 적용에 의심?이 생기는 부분이 들지만
성과가 좋으면 전도사로 변신할지도!!! ^_^;

회사에서 하루 1/2을 보내거나 2/3란 시간을 보내는 개발자라면
한번 저처럼 시도를 함께 해보시길...!!
단. 업무성격이 가능하다면 말이죠. ^_^


스티브 맥코널의 프로젝트 쾌속 개발 전략(Rapid Development)에 보면
프로젝트가 산으로 가는 전형적인 실수 목록 중 아래 같은 항목이 있다.

"새로운 도구나 방법에 대한 과대평가" - 기술관련 실수 관련

식사도 천천히 하는것이 잘 채하지 않듯(전 사실 1분이면 먹을수도 있지요)
TDD 적용도 천천히 음미한 후에 적용하는 것이 최선이라고 생각하며
마무리.........

테스트 주도 개발. 이 개발방식이 무슨 의미와 효과를 줄 수 있을까요? 일반적으로 규모가 작은 프로젝트는 시나리오와 요구사항을 정의하고 설계 및 구현을 통해 결과물을 도출한 다음 테스트를 거쳐 배포하게 됩니다. 테스트 유형에 따라 배포된 다음에서야 오류가 발견되는 경우도 종종 있습니다. 또는 테스트 도중에 오류가 발견되어 구현과 테스트 과정을 반복하게 되기도 합니다. 테스트 코드를 먼저 만드는 것부터 시작하는 TDD는 "개발문서 없이도 결과물만 도출하면 되지 않느냐?" 하는 방식의 저를 포함해 일부 개발자들의 통념과 발상을 완전히 뒤집는 것이었습니다. 예외는 발생하면 그때 그때 개선하자는 식의 코딩 스타일을 근본부터 뒤흔들고 있었습니다. 다른 책에서 읽었던 내용인데 개발자들은 동일한 코드지만 에러가 발생할 만한 상황으로의 테스트를 본능적으로(!) 피해간다고 합니다. 정확하게는 반의도적으로 에러가 나는 상황은 발생을 안시켜서 문제가 없다고 넘긴다고 해야할 것 같습니다.
무엇보다 책의 구성과 필체가 마음에 들었습니다. 이론에 해당하는 내용의 설명과 실제적인 예제(물론 전체 소스라기 보다는 조각에 해당하는 예제들이 많은편이긴 하다)를 통한 따라하기 식의 친절한 구성이 돋보입니다.
저자의 필체는 굉장히 자연스럽고 읽기 편한 구어체(거의 이끌어주기식의 대화체에 가깝다)로 되어 있습니다. 따라서 쉽게 읽을 수 있었고 마치 1:1 대화식으로 개인과외를 받는 느낌이었습니다.
IT 개발자 들에게는 너무나 익숙한 용어(전문용어는 아님)를 사용한 표현으로 상황을 예로 들어 필자의 의도를 정확하게 전달하고 있습니다. 정말이지 너무나 가슴에 와닿는 예시들이었습니다. 또한 전문용어 표기시 용어(명령영어)를 표기해 의미를 정확히 전달하고 있습니다.
주제별로 목차가 구성되어 있고 각 장은 초반에는 간단한 예제로 시작하면서 점점 깊이있는 API 활용으로 넘어가도록 구성이 되어 있습니다.
TDD 경험이 없었던지라 독특한 용어가 눈에 띄었습니다. 더미->테스트 스텁->페이크 객체->테스트 더블->테스트 스파이, Mock 객체 등 생소한 용어가 많아 그 의미를 몇번씩 짚어보기도 했습니다.
다른 테스트 프레임워크나 API에 대해서 이전 버전에 대한 비교 설명으로 최신버전에 대한 거부감을 감소시킬 수 있다고 기대합니다. 예를 들면 JUnit3와 JUnit4의 비교설명을 자세히 해 놓았습니다. 프로그램의 구성 단위별로 테스트가 가능한 자동화된 테스트 프레임워크인 JUnit에 대해서는 들어보기만 했었습니다. 저는 JUnit의 사용경험이 없어서 잘 모르지만 기존의 JUnit3 사용자들에게는 비교설명을 통해 JUnit4의 습득이 용이할 것 이라 기대됩니다.
Mock의 개념과 이를 구현한 다양한 프레임워크에 대한 설명으로 각 프레임워크의 장단점을 알 수 있고, 자신에게 맞는 프레임워크의 선택시에 조언으로 활용할 수 있습니다.
개발도구 중 이클립스를 활용해 테스트 프레임워크를 적용하는 방법을 설명하고 있습니다. 이클립스 사용법을 위주로 제시하므로 추가적인 기능을 익힐 수 있다고 본다. 중간 중간의 이클립스 활용팁은 꼭 필요한 정보들이었습니다.
TDD는 부품->조립->전체의 성능테스트가 아닌 부품테스트->조립으로 결함을 감소 시키는 방식을 취하고 있습니다. TDD의 강점은 초기 시간투자로 지연이 될 수는 있지만 일단 완성되면 결함을 60% 이상 감소시킨다는 연구결과도 나와 있습니다.
이러한 TDD의 프로젝트에의 도입결과로 얻는 효과는 엄청날 것이라 생각합니다. 테스트 케이스의 작성, 리팩토링을 통한 정제된 코드로 배포 하는 것이 개발자 입장에서는 더 없이 좋은 도움말이 될 듯 합니다. Javadoc 기능으로 API 문서 작성을 해본적은 있지만 활용예제는 담을 수가 없어서 아쉬울 때가 많았습니다. 테스트 코드의 배포 방식이 단순히 소스코드에 대한 문서화 주석기능을 통한 API 문서보다는 훨씬 나을 것이라고 판단합니다. 정석코스(해당 분야별 바이블)가 있다면 이 TDD 책은 속성코스에 해당한다고 할 수 있습니다. 꼭 필요한 내용들로만 구성이 되어었습니다.
페이지 중간중간의 전문가 인터뷰를 통해 쉬어가는 느낌과 실제 필드에서 TDD가 어떻게 사용되는지 경험담과 현장의 목소리를 간접적으로 들을 수 있었고, 인터뷰에 응한 전문가만의 프로젝트를 통해 얻은 노하우를 얻을 수 있었습니다(개인적으로는 다른 한빛미디어의 책과 비교해서 가장 좋았던 부분입니다).

느리지만 빠른길은 항상 요원한 길이다. 거북이와 토끼의 경주만큼 누가 이길지 모르는 그러나 지나봐야 알수 있는 풀리지 않는 숙제같은 느낌을 준다.



소프트웨어 업계에 있으면서 특히 SI일이 가장 많은 이 분야에서 느리게 가는 방법은 죄악이나 다름이 없다. 그만큼 한국의 개발환경이 척박하는 말이 되기도 한다. 테스트 주도 개발 TDD라고 해서 언어의 새로운 방법론이나 획기적인 툴을 설명하는것은 아니다.



적어도 SW의 개발환경을 이해하려는 저자와 각 분야에서 고생하고 있는 SW개발자들을 위한 괜찮은 책이라는 생각이 든다. 보통 테스트라는것은 개발이 대부분 끝나거나 적어도 프로토타입의 개발이 끝났을 경우에나 적용되는 아주 작은 시간이라고 인식되곤 한다. 물론 현업에서 일하는 개발자나 SE등은 테스트 기간이 개발기간만큼 잡아먹을것이라는것을 누구보다 잘 알고 있지만 대부분 적당한 테스트(언젠가는 문제가 발생할것이라는 예언도 가능한)를 마지막으로 클라이언트에게 넘겨주고 떠나는것도 사실이다.



TDD라는것은 말그대로 초기부터..그리고 아주 사소한것부터 테스트를 단계적으로 피드백해나가면서 개발해나가는 방식을 일컫는다. 경영이나 사업계획쪽의 TEC알고리즘과 굉장히 유사한 느낌인데 제대로된 피드백이 중간중간 끊임없이 이어지는 방식이다. 물론 짝 프로그래밍과 같이 진행되면 더욱 좋은 결과물을 볼 수 있다는 가능성이 있지만 현업에서는 쉽지 않은길이긴 하다.



책을 전체적으로 리뷰를 하고 나면 아! TDD는 이렇게 시작하는거다라고 딱히 감은 안올수 있지만 적어도 개념적으로 정립은 되는 느낌이다. 테스트 주도개발이 무엇인지 간략하게 소개하는가 싶더니 유용한 툴에 대한 설명과 데이터베이스 테스트의 요령 및 패턴과 개발분야에서의 TDD의 현업에서의 다양한 시각과 실습 예제를 보여주는것은 상당히 유쾌한 경험이라는 생각과 시도해볼만한 방법론이라는 느낌이 든다.



저자는 책의 장이 시작할때마다 실패에 대한 많은 유명인들의 명언을 담고 있었다.

만일 당신이 때때로 실패하지 않는다면, 그건 안이하게 살고 있다는 확실한 증거다. -우디 앨런



-> 나의 해석 : 실패도 무언가 시도해야 느끼는 법이다. 자기가 잘하는 일만 한다던가 지금까지 하는방법을 고수한다면 실패란 있을수 없고 또한 발전도 없다



성공은 열정을 잃지 않고 실패를 거듭하는 와중에 나온다. - 윈스턴 처칠



-> 나의 해석 : 어떤 목표를 이루고 싶다는 열정이 있다면 작은 실패는 얼마든지 뛰어넘을 수 있다.



실패는 좀 더 현명하게 다시 시작할 수 있는 기회다 - 헨리 포드



-> 나의 해석 : 실패에서 무엇을 배울수 있는 사람에게는 실패는 성공으로 가는 디딤돌



이런 많은 실패에 대한 유명인들의 발언을 써놓은 이유가 뭘까? 보통 소프트웨어를 개발하면서 작은실패를 두려워하기 때문에 우선 다 만들어놓고 마지막에 밤을 새서 코드를 뒤집는일을 선택하는 경우가 허다하다. 실패란것이 한국사회에서 얼마나 용납이 되지 않으면 그리고 일정이라는것이 개발자를 얼마나 몰아세웠으면 그럴까하는 안타까움이 밀려든다.



TDD라는 것은 코드를 작성하다가 실패를 경험하는것이 아니라 나중에 발생할 큰 문제에 대한 작은 피드백일 뿐이다라고 말하고 싶은듯 하다.



특히 코드를 작성하고 떠나는 개발자들에게 "최고의 프로그래밍 팁"은 가슴이 서늘하게 해줄 문장이다.

"당신이 사는곳을 어떤 매니악한 연쇄살인법이, 당신이 작성한 코드의 유지보수 작업을 맞게 될 거라고 늘 생각하면서 코딩하세요" 얼마나 섬뜩한가? 그러나 현실에서 전임자 혹은 전 프로젝트의 코드를 받아보면 살인충동이 일어날때를 많이 경험했을 것이다. TDD는 이런 문제에 조금더 현명하게 대처할 수 있지 않을까?



마지막으로 옛날에도 읽고 웃었던 묘비명이 이곳에도 쓰여 있었다. "우물쭈물하다가 내 이럴 줄 알았다." 버나드 쇼의 묘비명에서 발췌를 했다는데 얼마나 인생이 짦고 허무한가를 단적으로 드러내는 말이다.



당신의 인생은 아무것도 시도하지 않기에는 너무나 짦다. 우물쭈물 하는 당신의 오늘은 이제 해와 함께 넘어가고 있다.