이 책은 너구리님이 2년 전에 쓰신 테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구가 출간할 때 베타리더 등으로 참여했던 사람들을 대상으로 너구리님이 책을 쓰고 2년이 지나면서 달라진 생각, 지금의 생각 등을 공유하기 위해서 만든 자리였습니다. 사실 어떤 시나리오가 있는 세미나가 아니라 너구리님이 자신의 생각을 공유하면서 자유롭게 토론을 하는 분위기였기에 정리하기가 쉽지 않지만 대충 임의로 정리해 봅니다. 여러 사람들이 얘기를 나누어서 누가 말씀하셨는지는 다 기억하기 어려워서 생략합니다.
잘 안된다...
책을 쓰고 2년이 지나면서 배운 점은 TDD가 잘 안된다는 점이라고 하셨습니다. 다른 사람을 설득하려고 했지만 결과적으로 잘되지 않았고 이게 원래 안되는 게 아닐까 라는 생각이 들었습니다. 과거 CBD(Component-Based Development)가 실패했던 이유에 대해서 않은 얘기가 오갔었는데 그 당시에 CBD가 필요한 상황이 없었거나 받쳐줄 기술이 제대로 갖추어지지 않았으며 장사꾼(?)들이 개입하면서 왜곡되기 시작했고 CBD로 무엇을 하는가에는 관심이 없고 무엇을 얻는가에 너무 집중되어 있었다는 얘기가 있었습니다.(전 CBD는 잘 몰라서....) 어떤 인식이 공유안된 상태에서 새로운 것을 도입하는 것은 상당히 힘들다는 것에 대부분 공감하는 것 같았습니다.
너구리님은 약간 회의적인 시각으로 보셨지만 반대 의견들도 있었습니다. TDD가 실패라면 반대로 성공은 무엇인가를 정의하는 것은 어렵고 OOP도 성공했다고 말하기에는 많은 반론이 있을 것입니다. 이런 면에서 재능이 포터블한가?에 대해서 생각해 볼 수 있는데 시도는 많이 하지만 대부분 잘 되지 않고 이동하는 순간 효과가 확 떨어지는 결과가 대부분입니다. 그럼에도 믿음이 의지력을 만든다고 생각하기 때문에 된다고 믿으면 실제로 되고 안된다고 믿으면 실제로 안될 수 있습니다.
왜 안되는가?
기술이 받쳐주지 못해서 못하는 경우는 거의 없고 실제로도 하는 사람들은 다 TDD를 하고 있습니다. 하지만 시급도와 중요도를 기준으로 했을 때 자꾸 뒤로 밀리는 경향이 있습니다. 외견상의 현상만 봤을 때는 문제가 무엇인지를 알지 못하거나 개발자들이 변화를 계속해서 시도하지 않는 문제가 있고 밥 아저씨처럼 "참 쉽죠~"해서 신기했지만 감동도 잠깐이고 어렵고 커버리지 압박등으로 재미도 없는 것 같다는 얘기도 있었습니다.
어떻게 하면 잘 할 수 있는가?
이건 어찌 보면 어떻게 하면 개발을 잘 할수 있는가의 문제입니다. 한가지 방법은 TDD를 잘하는 사람을 관찰하는 것입니다. 너구리님은 일단 TDD를 한다고 했습니다.(책의 저자이기도 하니...) 협력업체 직원같은 경우는 그냥 원래 그렇게 하는거라고 하면 대부분 잘 따라온다고 합니다. 오히려 위험한 사람이 우리 팀에서 가장 잘하는 개발자입니다. 이런 개발자는 보통 코드가 어려운 데다가 테스터블하지 않은 코드도 뛰어난 능력으로 테스트코드를 만들어버리기도 하기 때문에 이런 개발자의 TDD를 보고 배우는 건 위험합니다.
2년동안 보니 다음과 같은 조건의 사람들이 TDD를 잘 합니다.
- TDD의 경험이 있는 사람(장점을 기억하고 있는 사람)
- Divide and Conquer를 잘하는 개발자
- 협동작업을 잘하는 개발자
- 계획하기
- 확인할 방법 생각해보기
- 실행하기
- 기능 요구사항이 명학한지 확인하기
- 머리속으로 단계를 그려보기
- 종이에 적어보기
- 단계별로 확인할 방법을 생각해 보기
- 코딩 시작
책을 쓸 때와는 달라진 생각들
많은 개발자가 Mock에 흥미를 가지지만 대부분의 경우 Mock으로 불필요한 코드들이 생기게 된다.
짝 프로그래밍은 TDD에도 많은 도움이 된다. 짝 프로그래밍에 대해서도(이것도 엄청나게 큰 하나의 주제이므로) 많은 얘기가 오갔는데 짝 프로그래밍에는 소셜 스킬이 중요하다는 얘기가 나왔습니다. 물론 이는 짝이 같은 가치관을 가지고 있지 않으면 짝 프로그래밍이 무척 어렵다는 얘기부터 시작된 것이지만 가치관이 다른 경우 소셜스킬로 해결할 수 있다는 얘기로 이어졌습니다.(이 얘기가 더 맞는듯 합니다.) 대부분 짝 프로그래밍을 가르칠 때 소셜 스킬을 가르치지 않기 때문에 문제가 발생하는데 중요한 사건들은 화면이 아니라 두 사람 사이에서 발생합니다. 그래서 김창준님은 짝 프로그래밍을 조언할 때 화면이 아니라 짝 프로그래밍을 하는 두 사람을 촬영해서 가져오기를 요구한다고 했습니다. 그래서 프로그래밍이 아닌 두 사람간의 문제가 생긴다는 것을 미리 알려주지 않으면 짝 프로그래밍을 하면서 당황하기 때문에 어떤 상황이 생길 수 있고 어떻게 해결해야 하는지 얘기해 주어야 한다고 했습니다.
그리고 이런 얘기를 하는 가운데 김창준님이 don't는 약한 표현이기 때문에 don't를 얘기할 때는 do를 함께 얘기하는게 좋다고 하셨는데 이부분이 꽤 인상적이 었습니다. ~~를 하지 마라만으로 부족하고 대신 ~를 해라까지 나아가는게 좋다는 것이지요. 그리고 대부분은 문제를 감지할 수 있는 방법을 알려주는 것 좋은데 if()로 상황을 주어도 그 조건을 대부분을 감지해 내지 못한다는 얘기셨습니다. 그래서 구체적으로 문제를 감지할 수 있는 방법까지 알려주는게 좋다는 얘기였습니다.
내 생각....
일단 저는 TDD가 실패(?)했다고 생각하지 않는 쪽입니다. 실제로 TDD를 해보면 재미있기도 하지만 때때로 무척 귀찮을 때도 상당히 존재하는데 실제 프로덕션레벨로 나가면 또 상황이 달라지는 것 같습니다. 실배포전에 수정한 내용의 오류르 테스트케이스로 발견했을 때(물론 이는 TDD가 아니라 나중에 유닛테스트를 만들어도 같지만 그냥 뭉뚱구려 얘기합니다.) 테스트케이스를 작성한 보람을 느끼게 됩니다.
또 한편 이게 오픈소스나 공개소스로 넘어가면 얘기가 또 완전히 달라지게 됩니다. TDD는 좀 귀찮기도 하다는 생각을 한다고 하더라도 어떤 오픈소스를 가져다 쓸 생각을 하면 테스트코드가 얼마나 잘 작성되어있는가가 주요한 판단 기준이 되며 소스를 오픈소스로 제공한다고 생각하면 제 코드의 신뢰성을 증명하는데 테스트케이스 만한 것은 없습니다. 실제로 오픈소스 프로젝트들을 보면 대부분 테스트케이스를 작성하고 있으면 코드를 수정해서 제출하더라도 테스트코드를 같이 제출해야 하는 경우가 대부분입니다. 이런 면에서 TDD는 꽤 많이 자리 잡았다고 생각합니다.
암튼 마지막 정리하면서 의견을 낼 때 아직 너무 어려워서 더 쉬워져야한다. 라는 얘기가 있었습니다. 이 말이 제 머릿속에 오래 머물렀었는데 어려운 게 사실이고 그런식으로 생각해 보진 않았기 때문입니다. 많은 프렉티스가 공유되고 정보가 많아지면서 이전보다 쉬워지긴 했지만 여전히 어려운 것은 사실입니다. 하지만 더 쉬워져야 한다에는 공감하지만 쉬워질 수 있는가?에 대해서는 회의적입니다. 다른 얘기를 하면 건강을 유지하려면 음식을 조절해야 하고 운동을 규칙적으로 하고 잠을 충분히 자야합니다. 물론 그렇게 하는 사람도 있지만 직장생활을 하면서 음식조절을 하고 규칙적으로 매일 운동해서 건강하고 좋은 몸은 유지하는 것은 쉽지 않은 일입니다.(그래서 대부분 배가 나오죠.) 그럼에도 건강해 질 수 있는 지름길 같은 것은 존재하지 않고... 운동안하고 먹고싶은거 다 먹으면서 건강하고 날씬한 몸을 유지할 수 있는 방법도 없습니다. 많은 사람이 운동을 규칙적으로 못한다고 잘못된 방법이라고 생각하지도 않습니다. 비슷한 이치가 아닐까요? 좋은 소프트웨어를 만드는 것은 원래 어려운 일이고 여기에 은총알이나 지름길 같은 건 없습니다. 더 많이 생각하고 더 많이 해보고 하는 거지요.(머 그런의미로 이날의 논의가 이뤄졌다고 생각하진 않지만요.)
머 요즘은 그냥 할 수 있는 범위 내에서는 TDD를 해보려고 노력하면서 기술적인 부분에만 관심을 가지고 근본적인 내용에 대해서 고민해 적은 별로 없었습니다. 그냥 노력해야 할 것으로만 생각했을 뿐이지요. 간만에 TDD에 대해서 그 의미에 대해서 많은 생각을 해보고 의견을 들어볼 수 있는 좋은 모임이었습니다. 그리고 너구리님의 엄청난 인맥으로 이날에는 한자리에 모이기 힘든 대단하신 개발자들이 많이 모였는데 끝나고 생각해 보니 단체사진이라도 하나 찍을걸 그랬다는 아쉬움이 남더군요. ㅎ
좋은 글 감사합니다
한국사람들은 일단 TDD의 성공사례를 듣고 싶어하죠
저는 deploy 후 작업에 대해서 많은 도움을 받았어요
git 으로 deploy하고, 과연 내 소스가 production 에서 잘 돌아갈까?
로컬에서 서버 1대 만으로 작업했던것이
여러대로 분산되면서 잘 작동할까?
이 불안한 점을 작업해놓은 TDD코드가 해결해주었습니다
금방 오류를 찾아낼 수 있고, 오류를 찾아내기 위한 접근성이 꽤 좋아지더군요
이상 저의 성공담이었어요
수고여
성공담 공유 감사합니다.
TDD를 잘 하진 않지만 코드를 검증할 수 있는 방법중에는 가장 좋은 방법이라고 생각됩니다. ㅎ
발표 내용이 정말 궁금했었는데, 정리해주셔서 감사해요~
우선 정말 test first로서의 TDD는 습관을 바꾸는 일이라서 적어도 6개월이상은 걸리는듯합니다. 그리고 저도 테스트 코드를 짜고 몇년이 지나서야 전에는 몰랐던 것들이 보이기도 하구요. 예를 들면 mock library의 verify도 처음에는 대부분 불필요하다고 느꼈는데 꼭 필요한 상황이 있구나..는 것들이죠.
그렇다고 해서 이게 굉장히 어려운 일이라고는 생각하지 않습니다. 영어 잘 하기 같은 일상의 과제에 비하면 숙련도가 높아지는 기울기가 크다고 봅니다..
그리고 Mock으로 불필요한 코드가 생긴다는 점은 어떤 의미인지 궁금하네요.. Mock library를 의미하는 것이라면, 가짜 객체를 쓰는게 편한 상황이라면 Mock library가 코드를 더 간편하게 만들어준다고 생각하거든요. 직접 가짜 객체 만드는게 더 편한 상황이라면 Mock library를 그런곳에서는 안 쓰는게 좋구요..
암튼 너구리님과 같이 늘 고민하시는 분이 멋지다고 생각하구요,
실무에서, 현실의 요구사항을 구현하는 개발을 하면서, 바쁜 일정에 쫓기면서도 테스트를 작성해본 경험이 있는 사람만이 TDD를 다른 사람에게 전파해야한다고 생각합니다..
저는 Mock은 안써서 정확히는 모르지만 최근에 얼핏얼핏 너구리형이 얘기하는거 보면 Mock사용은 최소한으로 해야한다는 쪽으로 생각하시는듯 합니다.
저도 TDD는 익숙해지는데 오래걸린다고 생각합니다. TDD는 여러가지 스킬외에도 말씀하신것처럼 습관적인 부분도 있기 때문에 지속적으로 많이 해보는게 제일 좋은것 같습니다.
정리 잘 해주셔서 고맙습니다.
한가지 명확히 했음 하는데요. 너구리님이 잘 안 된다고 한 건 보급이 잘 안된다는 거였다고 생각합니다.
지금 생각해보면 너무 개인적인 수준에서 TDD가 받아들여지지 않는 이유를 얘기한 건 아닌가 싶습니다.
예.. 보급이 잘 안된다는 부분이기는 했는데 "좋음"과 "좋지만 보급안됨"이 그렇게 명확하게 구분되지는 않는것 같더라구요. 세미나가 아니라 토론처럼 진행되어서 정리가 어렵긴 했지만 곰곰히 생각해봐도 둘에 차이가 있는것 같으면서도 막상적으려면 둘의 구분은 쉽지 않다보니 약간 애매모호하게 표현되지 않는 것 같습니다.
무슨 얘기하려나 하고 갔다가 막상 해보니 평일이라 시간이 짧아서 아쉽더군요.
켄트벡도 그렇고 창준님도 그렇고 너구리님도 그렇고 무엇인가를 전파하려고 했던 분들이 이 부분에서 큰 벽을 느끼지 않았나 합니다.
켄트벡 :
저는 더 이상 사람들을 설득하려 하지 않습니다. 저는 거의 10년동안 사람들에게 TDD를 꼭해라, 짝프로그래밍을 꼭 해라고 설득하려고 애써왔지만, 더 이상 그렇게 하지 않습니다.
(출처 : http://blog.benelog.net/2815291)
남을 설득하는건 참 어려운것 같습니다. 좋아서 권장(/추천) 하는 건데 생각보다 이런 부분이 쉽지 않지만 또 그런 분들 때문에 조금씩 변해가는것 같기도 하고요.
좋은글 잘 보고 갑니다.
TDD의 현실적인 이야기와 마지막 의견이 많이 공감가네요,,,
저도 간만에 즐거운 시간이었었네요....
저도 TDD 가 좋다는것을 알고 있고, 전에 사용 해 봤고,
현재 담당하고 있는 부분이 TDD 적용할 만한 여건이 안되 중간 테스트 용으로만 사용 하고있습니다.
제가 생각 하는 TDD 가 많이 보급 되지 않는 부분중 하나는
윗분들의 커버리지 압박도 한몫 하지 않나 합니다.
도입 했으면 성과를 보여야지 하면서 몇% 이상 해라. 이러죠..
개발자에게 무언가 강요하면 그건 아무리 좋아도 실패 하게 된다고 생각합니다...
몇년전 NS 있을때 커버리지 채우기 위한 코드를 생상 했었죠..
사실 마지막 부분에 커버리지에 대한 내용도 적었었다가 글도 길어지는 대다가 대부분 그렇게 생각하실것 같아서 지웠습니다.
저도 실제의 주요인으로 생각하고 커버리지 수치덕에 정말 필요한 테스트를 다양하게 하는 대신에 불필요한 getter/setter 테스트를 만들어야 하는 형편이죠. ㅡㅡ;; 그게 딱히 소프트웨어의 품질을 보장해 주는것도 아닌데요 ㅠㅠ
이부분은 사실 TDD를 주장한 사람들의 의견을 윗분들이 다시 수치화하면서 생기는 복잡한 문제네요.. 뭐든지 수치로 보고싶어들 하셔서...
실무에서 예제(?!) 가 부족하다는것 도.. 하나의 이유라고 생각합니다... 책을 보면 대부분 실무랑은 약간 거리가 있는 느낌이라서..^^;
실제로 도입하자고 강력 주장했지만 결국 저만 하고 있네요..
그리고 사실 저도 제가 만들고 있는 이 case들이 TDD는 이렇게 하는 것입니다 라고 말할 수 있는지 확인할 방법도 없고요..ㅠㅠ
기술적(?)인 예제는 부족한 정도까진 아닌가 생각합니다만 뭐 다른 것들도 비슷하지만 단순히 예제나 기술적 설명만으로 해결하기에는 더 복잡한 부분이라고 생각합니다. 실제로 설계에 대한 접근이기도 하니 프로그래밍에 대한 지식이나 경험도 많이 필요하고요.
이렇게 하면 누구나 TDD를 할 수 있다라는 건 없다고 생각합니다. 계속 노력해서 조금씩 개선하는 거죠.