저는 불가능하다는 생각이 우선적으로 듭니다. 그렇게 생각하는 이유는 다음과 같습니다. 1. 눈앞의 생산성에만 집중한다. 회사의 입장에서는 빠른 결과물이 나오는것을 좋아합니다. TDD 초기단계에서 기존의 개발방법과 비교하여 생산성이 떨어지기 때문에 SI라는 기간이 짧은 프로젝트에는 옳바르지 않다고 생각합니다.

1. 주변사람들의 설득 과정이 필요하다. 만약 쓰고 싶더라도 주변사람들을 설득하고, 교육하는 과정이 필요합니다. 주변의 소위 학원파(저 또한 학원파이긴 합니다만..)분들을 설득하여 기존의 개발체계를 버리고 TDD로 가는 과정은 쉽지 않습니다. 이도현님또한 나이가 어리다라는 커다란 장벽 아래에서 이러한 부분을 쉽사리 해결할 수 없다고 보여집니다.

2. TDD를 위한 사전준비가 되어있지 않다. 앞서 말씀드린대로, TDD는 지속적인 준비가 필요하다고 봅니다. 뭐랄까 이상적인 개발환경을 만들어가는 과정이기에, 패러다임의 전환과정, TDD를 오롯이 개인의 것으로 만들기에는 수양이 많이 필요합니다.(주변분들도 마찬가지이구요.) 이러한 부분이 충분히 완성되지 않은 상태에서 회사 업무에 적용시키기란 오히려 야근을 조장하는 일이 될 수도 있구요.

저 또한 한동한 이상적인 개발방법론을 지지하는 편입니다(자동화를 위해서 회사사람들과 무지막지하게 대립관계를 형성하였습니다.) 작업을 함께 진행하는 분들의 교육, 설득 과정은 결코 쉽지 않습니다. 개인의 환경에 맞추어 부디 좋은 관계를 유지하면서, 현실적인 방향으로 나갔으면 하는게 개인적인 바램입니다.

저도 SI 환경에서는 TDD를 전파하는 것이 힘들다고 생각합니다. 물론 윗 선의 강력한 의지가 있다면 일정 정도 가능할 수도 있겠지만 형식적으로 접근할 가능성이 높다고 봅니다.

SI 환경에서 TDD가 힘들다고 생각하는 이유는 다음과 같습니다. 일단 @devSejong 의견에 전적으로 공감하면서 글을 시작해 볼께요.

제가 생각하는 가장 큰 장벽은 SI 프로젝트가 지속적이지 못하다는 것입니다. TDD를 위해서는 TDD에 대한 교육과 TDD를 성공하기 위해 지속적 통합과 같은 개발 환경 구축이 같이 진행되어야 합니다. 그런데 SI의 경우 교육에 투자할 시간이 없고, 그럴 의지도 없습니다. 교육에 대한 투자와 의지가 있더라도 개발자가 해당 practice에 익숙해질 때까지 기다려줄 수도 없습니다. 그리고 TDD나 지속적 통합과 같은 활동은 프로젝트가 끝난 후 유지보수를 하는 시점에 그 효과가 나타날 가능성이 높은데 SI는 프로젝트를 기간 내에 끝내는 것에 집중하지 유지보수까지 고려하는 경우는 거의 없는 듯 합니다.

국내의 하도급 구조에 의해 잠시 모였다가 프로젝트가 끝나면 흩어지는 구조에서는 지속적으로 문화를 만들고 개발자의 역량을 키우는데 투자하는데는 한계가 있습니다. 그렇다보니 SI에서 좋은 개발자가 나오기 힘든 것으로 생각합니다. 물론 개인이 노력하면 일정 수준으로 성장할 수 있겠지만 현재 진행하는 프로젝트에서 직접 경험할 수 없기 때문에 좌절하고 포기하는 경우가 많은 듯 합니다.

@devSejong 글에서도 언급했지만 SI 뿐만 아니라 대부분의 프로젝트에서 주변 사람들을 설득하는 과정이 필요합니다. 같이 일하는 사람들과 지금까지 신뢰 관계를 쌓아온 상황이라면 생각보다 어렵지 않게 설득할 수 있습니다. 하지만 SI의 경우 대부분의 사람들이 프로젝트를 위해 처음 만남 사람들이기 때문에 설득하는 과정이 상당히 힘듭니다.

그렇다고 그냥 포기해 버리지는 말았으면 합니다. 주변 사람들을 설득하고 프로젝트 전체를 TDD나 지속적 통합 환경으로 만들기 힘들다고 개개인이 포기할 필요는 없습니다. 자신이 맡은 기능에 한해 TDD로 개발하거나 그것이 힘들다면 중요 로직에 대해서만이라도 단위 테스트를 만드는 노력을 했으면 좋겠습니다. 그럼 개인적으로 연습도 될테고 TDD에 대한 경험도 쌓이면 추후 기회가 왔을 때 적극적으로 도전할 수 있는 계기가 되겠죠. TDD의 경우 프로젝트 전체가 같이 하면 좋겠지만 그런 환경이 되지 않는다면 개인적으로도 시도해볼 수 있는 활동이라고 생각합니다.

쉽지 않은 길이겠지만 더 좋은 개발자로 거듭나기 위한 과정이라 생각하고 개인적인 역량을 쌓아 나갔으면 합니다.

프로젝트 진행과정 중 빈번하게 변경되는 요구사항도 큰 장벽일것 같아요. 결국, 요구사항이 자주 변경되면서 테스트케이스에 작성해놓은 input과 output이 자주 변경되기 시작하면 TDD를 통해 만들어놓은 테스트케이스는 요구사항 바뀔때마다 같이 바꿔야하는 짐짝같은 느낌이 되겠죠..

그래도 최근에는 테스트케이스에 대한 인식이 많이 좋아져서 어떻게든 설득도 되고 도입도 가능할것 같지만 결국 프로젝트가 막바지로 가면서 일정에 쫓기고 요구사항은 더더욱 빈번하게 바뀌게되면 관리되지 않는 주석처럼 애매한 상태의 테스트 코드들만 남게 될것 같습니다.

하지만.. 재성님 말씀대로.. 그렇다고해서 개인의 역량을 올리기위한 노력까지 포기할 필요는 없다고 생각합니다.

예전에도 비슷한 논의가 많았는데요... "테스트를 한다는 것 == TDD" 로 판단하는 것은 자제를 했으면 합니다.

테스트 코드가 있다는 것은 코드의 품질과 관련된 문제고 변경에 대해서 강해진다는 것이죠. 개발자나 관리자 모두에게 좋은 기반이 될것입니다.

TDD 는 패러다임의 전환이고 개발 접근법의 변화죠. 얘는 개발코드에 테스트가 있어야 한다는 것과는 다른 맥락으로 접근해야 한다고 봅니다.

무엇보다도 TDD 로 패러다임을 변화시켰을때의 장점을 스스로가 인식을 해야 합니다. ( 저 역시도 연습이 많이 부족해서 잘 모르겠습니다. 저는 아직도 production code 를 먼저 작성하고 test 작성하는 것이 편합니다. ) TDD 를 통해야만 테스트가 작성되는 것도 아니고 Production Code 를 만들고 테스트 코드를 만들수도 있습니다. 테스트코드를 먼저 만든다는 것은 테스트를 통해서 설계/구현 을 진행해 나가겠다는 개발방법의 변화라고 생각하는 것이 조금더 좋은 접근법이라는 생각입니다.

토론이 재미없게 '역시 SI에서는 TDD 혹은 테스트 코드 작성은 무리야.'로 결론나는듯해서 반론을 적어봅니다.

얼마전까지 했던 SI프로젝트의 경험을 말씀드리려고 합니다. 딱히 애정도 없고 프로젝트 기간 끝나면 제가 앞으로 볼일이 없는 코드였지만, 당장 프로젝트 기간 중에 이득을 얻고자 되도록 Test first방식의 TDD로 개발을 했습니다. 서버개발자 3명의 작은 프로젝트였고 개발분량이 많지는 않았지만 라인커버레이지는 90%이상이 나왔습니다. 물론 Coverage를 의식하고 개발을 하지는 않았습니다.

많은 SI프로젝트가 그렇듯이 중간 요구사항 변경도 많았는데, 그때마다 테스트 코드 덕분에 변경을 하는 시간이 많이 줄어들었습니다. 요구사항 변경이 있으면 테스트 코드를 추가 변경해야할때도 있지만, 변하지 않는 부분이 더 많기 때문에 테스트를 수정하는 비용보다 변하지 않는 부분의 회귀테스트를 해주는 이득이 더 크다고 느꼈습니다.

자신있는 부분은 주로 통합테스트로 포폭을 크게 테스트하고, 나중에 세부검증이 필요해질때는 Mock을 쓰는 등 , 상황에 따라 테스트를 활용하면 디버깅 시간이 줄어들어서 SI에서도 충분히 생산성 향상을 이룰수 있다고 생각합니다. 그리고 요구사항 변경이 많을 수록 기존 기능이 부작용 없이 돌도록 수정하는 것이 어려워집니다. 그래서 테스트가 많으면 요구사항 변경을 하면서 시스템도 안정시켜야하는 프로젝트 후반부의 스트레스가 줄어들 수 있습니다.

테스트 코드 작성에 익숙하지 않는 개발자가 많다면 Util클래스나 Controller단의 통합테스트부터 시작해서 디버깅 시간이 줄어드는 긍정적인 경험의 기회를 늘려보는 전략이 좋을듯합니다. 테스트코드 중에는 몇달뒤에 이득이 돌아오는 테스트도 있고, 몇일 뒤에 돌아오는 것도 있지만, 당장 몇시간 안에 이득이 돌아오고 오늘 퇴근을 빠르게 해주는 테스트도 있음을 많이 경험했습니다. 유지보수성을 위해 테스트를 한다는 관점이 아닌 당장 오픈전까지의 생산성을 높인다는 관점으로라도 SI개발자가 테스트를 작성할 동기는 있다고 생각합니다.

물론 단기간의 프로젝트에서 JUnit도 모르는 개발자들로만 프로젝트를 시작한다면 깊이 있게 기법과 라이브러리 사용법을 전파하기는 어려울수도 있습니다. 그리고 몇달정도의 경험으로는 효율적으로 테스트를 짤 수 있는 수준이 되지는 않는다고 생각합니다. 그래도 테스트 코드가 단 한둘도 없는 코드가 생산성이 가장 높은 개발방식은 아니라고 생각합니다.

7~8년전 SI에서도 main 메소드 안에서 디버깅을 위해 System.out으로 찍어보는 코드들을 많이 봤었는데, @Test와 assert가 뭐하는것인지 알려주고 main에 있는 것들을 @Test로 옮기는 일 정도는 아주 어렵지는 않다고 봅니다.

그리고 SI에서는 Tomcat이나 Jetty보다는 JavaEE스펙을 다 지원하는 등 기능이 많은 상용WAS를 많이 씁니다. 이런 WAS를 내렸다올리는데는 Servlet Spec만 지원하는 WAS보다 시간이 더 많이 걸립니다. 이런 호나경에서 Controller단의 통합테스트 템플릿을 만들어서 활용을 하면, SQL과 그에 들어가는 바인딩변수의 실수는 전부 다 잡고 WAS를 올릴 수 있습니다. SI에서 긴 SQL이 많이 나오는 이유중에 하나가 TOAD에서 SQL로 최대한 많은 결과를 보고서 그 다음에 Java코드를 작성하는 개발습관을 가진 사람들이 많아서라고 생각합니다. TOAD같은 툴을 일종의 예비테스트 환경으로 쓰는 셈입니다. 통합테스트 코드에서는 TOAD에서는 검증할 수 없는 #{}같은 변수바인딩에서의 오타 같은 실수도 더 빨리 볼 수 있으므로 디버깅 시간이 줄어들수 있습니다. SI에서 많이 쓰이는 iBatis와 myBatis의 XML선언, 변수 선언에는 컴파일러가 검증할수 없는 부분이 많은데, 그런 에러를 잡는다고 WAS를 몇번씩 내렸다 올리기보다, 그 시간에 테스트 코드를 copy&paste로도 만들어서 돌려보는 편이 더 이득일수 있습니다.

Android 환경처럼 TDD나 테스트코드의 장벽이 큰 기술환경도 있지만(물론 안드로이드에서도 어느정도 극복할 수 있는 방안은 있습니다.) SI에서 특별히 안 될 이유는 없어 보입니다. Java 웹개발에서는 특히 좋은 Mock 프레임워크도 많고, 테스트 작성에 편한 구조를 만들어주는 Spring도 있으니까요. 참고로 저도 C로는 TDD가 힘들지 않나 생각했었는데, 임베디드 C의 대가가 쓴 '임베디드 C를 위한 TDD'를 읽고서 많은 것을 느꼈습니다.

@benelog 한쪽으로 치우친 토론에 이슈를 불러 넣어줘서 고맙다.

나도 SI 환경에 대해 부정적인 이야기는 하고 싶지 않지만 현실적으로 TDD(TDD가 뭐하면 단위 테스트라고 하자.)를 적용하는데는 많은 한계점이 있다고 생각한다. 네가 말한대로 프로젝트 기간 내에도 TDD를 함으로써 많은 이점을 얻을 수 있다는 의견에는 공감한다. 어차피 우리가 기능을 추가하는 시점부터 유지보수 업무가 발생하기 때문에 단위 테스트에 대한 효과는 프로젝트를 진행하는 기간 내에 얻을 수 있다고 생각한다.

하지만 내가 SI 환경에서 TDD가 힘든 이유는 그 효과적인 측면보다는 문화적인 측면에서 너무 많은 장벽이 있다고 생각한다. 너와 같이 TDD에 대한 필요성을 인지하고 경험이 있는 개발자가 다른 개발자들을 가이드하면서 리딩할 수 있다면 일정 수준 성공할 수 있겠지만 그런 경험을 가진 개발자도 많지 않은 상황이고, 이에 대한 공감대를 형성하는 개발자도 많지 않아서 그 짧은 기간 내에 그들과 공감대를 형성하고, 교육하는데는 많은 장벽이 있으리라 생각한다. 이런 변화를 만들어 가려면 TDD(또는 단위 테스트)에 대한 경험도 많고, 자신이 일정부분 희생하겠다는 각오가 있지 않으면 힘들 듯하다.

또한 프로그래머의 수도 중요하다고 생각한다. 네가 경험했듯이 3,4명의 개발자라면 일정 수준의 노력으로 접근해 볼 수 있겠지만 10명만 넘어가더라도 힘들지 않을까라는 생각이 든다. 물론 프로젝트 내에 적극적인 친구들이 몇 명 있다면 다소 수월하겠지만 그런 경우는 많지 않더라고...

개인적으로 중, 대규모 SI 프로젝트에서 TDD나 지속적 통합과 같은 문화를 전파하려면 같은 생각과 문화를 가지고 있는 프로그래머들이 프리랜서 그룹을 만들고 이들이 프로젝트를 주도한다면 가능하지 않을까라는 생각을 해본다. 최근에 프로그래머들의 협동 조합도 생기고 있는데 이런 형태로 같은 성향의 프로그래머들이 뭉쳐서 같이 일할 수 있는 환경도 좋아 보인다. 그런 환경이 가능해 진다면 프로그래머들이 지금보다는 좀 더 즐겁고, 인정받으면서 일할 수 있는 환경이 되지 않을까라는 기대를 해본다.

지난 번 프로젝트의 경험들을 공유해 준다면 SI 프로젝트에서도 단위 테스트와 통합 테스트를 만드는데 많은 도움이 되리라 생각한다. 기회될 때 함 공유해주라.

눈팅하다가 몇자 적습니다.

일단 제 의견에 앞서 고도화가 많은 SI에서는 TDD보다는 유닛테스팅의 케이스가 더 많겠다라는 생각이 드는군요. 기존의 코드에 대한 테스트 코드를 작성한다면 유닛 테스팅의 개념이 더 가까우니까요.

그리고 코드에 변경이 가해질 때 마다 테스트 코드도 같이 변경해줘야한다라는 불만에 대한 의견을 몇자 적겠습니다. 요구사항이 바뀔때나 코드에 리펙토링이 가해질 때 어김없이 뜨는 테스트 실패들... 개발하는 입장에서는 스트레스입니다. 하지만 달리 생각해보면 변경이 가해져서 실패한 케이스들 모두 잠재적인 버그들입니다. 이런 테스트코드들이 없었더라면 개발단에서 이런 잠재적인 버그들을 이렇게 쉽게 발견할 수 있었을까요? 짐짝으로 치부하는 것은 섣부른 판단인 것 같습니다.

SI에 TDD가 어울리느냐는 질문을 하게 된 이유가, 로버트 L. 글래스의 책을 읽고 나서였다면 SI 개발 인력이 TDD를 하기엔 수준 이하이기 때문이라는 건데... 일단 TDD를 강압적으로 수행하도록 하는 건 SI가 아니라 어떤 개발 현장에서도 무리인 것을 인정하고 넘어가야 할 거라고 봅니다. 캔트 백도 "나" 먼저 수행하고 점차 그 경험을 동료에게 전파하는 식으로 서서히 전파되도록 하라고 조언했으니까요.

하지만 지금 당장 수행하기 어렵다(거나 불가능하다)고 해서 앞으로도 안된다거나, 할 필요가 없다거나, 나도 하지 말아야 한다는 의미까지 확대되는 건 문제가 있지 않을까요?

SI도 뭔가 변해야 한다는 공감대는 형성되었다고 보는데, 고객이나 PM이나 아키텍트는 변할 기미가 안 보이니 개발자가 전문가로서 대안을 제시해야 하지 않을까 싶습니다. 한사람 한사람이 노력하고 서로 독려하고 장애가 되는 걸 싸워서 제거해야죠.

그리고 TDD를 교과서적인 "개인"이 "짧은 주기"로 시행하는 방식이 아닌, 변형해서 시행하면 지금의 SI도 가능하다고 생각합니다. 교과서적인 TDD는 "팀" 단위가 "긴 주기"로 시행하는 방식인데요. 단위 테스트가 아닌 인수 테스트 성격의 통합 테스트를 TDD로 진행하면 SI에서도 충분히 가능합니다.

이터레이션마다 개발한 요건을 테스트 케이스로 표현하고 이를 만족하는 코드를 이터레이션 기간 내에 개발해서 테스트가 모두 통과되도록 하는 것이지요. 이런 테스트를 보통 ATDD(Acceptance Test Drive Dev.)라고 하고 Specification by example을 보면 유사한 다른 기법들도 있습니다.

http://en.wikipedia.org/wiki/Specification_by_example

이런 관점에서 저는 테스트 자동화에 대한 경험이 부족한 팀에 통합 테스트를 우선 적용하도록 요청합니다.

개인적인 생각으로는 SI에서 TDD라는 방식 자체를 전파하기 위해서는 SI의 프로젝트 성격이 변해야하는건 아닐까합니다.

3차에 걸친 단위테스트를 수행하고, 다시 3차 통합테스트, 시스템 테스트, 스트레스 테스트, 고객의 인수테스트와 같이 대형 SI의 경우에는 수많은 테스트 들을 별도의 일정으로 잡고 그에 대한 가중치를 상당히 높게 두는 편이지요.

그래서인지, 개발자들에게 (테스트 == 나를 귀찮게함 == 불필요한 요식행위) 라는 인식이 지배적인것도 사실이구요. 게다가 고객은 품질이 높은 코드보다 화면에 빨리 띄워보고, 동작하는 (자신들 기준의) "프로그램"으로 테스트 하는 것들만 테스트 단계로 인식이 되어 지니까요.

"적인 인원으로 단기간에 고객이 사용할 만한 프로그램을 개발한다." 에서 "지속적으로 발전시켜 갈수 있는, 가치있는 프로그램을 개발하고, 고객에게 인도한다" 라는 형태로 개발을 수행하는 패러다임 자체가 별경이 되야 하는건 아닌걸까요?