본문 바로가기

해외취업이야기

TDD/BDD의 허와 실

사실 한국에서 작은 개발팀에서 일할 당시에는, TDD (Test Driven Development)와 BDD (Behaviour Driven Development)라는 용어 조차 알지 못했다. 엄청나게 복잡한 서비스 로직이 녹아들어있는 콜서버를 C++로 개발하면서도, 테스트단계는 항상 매우 단촐했다. 몇가지 주요 시나리오를 구동해주는 시뮬레이터를 돌려보는것이 전부였다. 물론 마치 시계 장인이 현미경과 핀셋으로 숨죽이고 작업을 하듯이, 코드 한줄한줄에 굉장한 신경을 쏟으면서 작업하였던 기억이 난다. 왜냐하면, 시뮬레이터가 모든 케이스를 테스트해준다는 생각은 애초에 해본적이 없기 때문이다. 그저, 대형사고 날만한문제를 예방하며, 마음의 위안을위해서 한번정도 돌려보는 수준이랄까. 지금 생각하면, 어떻게 그렇게 일을 했는지 놀라울따름이다.


한번은 굉장히 확신을 가지고 아주 단순한 코드 변경을 하고, 당연히되겠지 라는 생각으로 KT의 상용 통신망에 그냥 적용해버렸다가 호처리가 불통되고 난리난적이 있었다. 그때는 정말 당혹스러웠고, 개발자는 스스로를 50% 이상 믿으면 안된다는 생각이 들었다. 하지만 팀장님도, 동료도 TDD/BDD라는걸 언급한적은 없었던 걸로 기억한다. 나 스스로도 그런 대규모 서버개발의 경험이 처음이었고, 그냥 다들 그렇게 하는줄 알았었다.


영국에와서, TDD/BDD/Agile을 사용하는 개발팀에서 완전 새로 시작하는 프로젝트에 참여하게 되었다. 언어나 문화적으로 익숙치 않은 환경에서 시작하는것 자체로도 상당한 어려움이 있었는데, 거기다가 개발 방법까지도 익숙하지 않다보니 처음에는 상당히 귀찮았다. 특히 내가 개발한 파트에 대한 유닛테스트 코드를 작성하는게 너무 귀찮았다. 특히나 서버쪽이다보니 다양한 상황에 맞는 유닛테스트 코드를 작성하기가 너무 복잡한 경우가 많았다.


유닛테스트 작성은 그 자체가 귀찮은것 뿐 만 아니라, 코드의 아키덱쳐에까지 영향을 미쳤다. 여러가지 복잡한 클래스들을 Mocking 해야하다보니, 실제로는 꼭 필요하지 않은 부분에도 interface를 사용해야 하는 경우가 많았다. 유닛테스트를 염두에 둔 개발에 익숙하지 않던 초기에는, 아주 깔끔하게 완성된 모듈을 보며 감상에 젖어있다가 유닛코드를 작성하면서 구조를 뒤집게 된 경우도 많았다. 테스트가 불가능한 구조로 짰기 때문이다.


우리 팀은 유닛테스트 외에, 컴포넌트 테스트도 동시에 작성한다. 서버를 가상으로 구동한 후, 실제로 인풋과 아웃풋을 발생시켜서 예상치를 검사하는 방식이다. 이를 위해서 자체의 validator engine과 script를 개발했고, 각각의 개발자가 새로운 기능 추가나 오류 수정시에 스크립트를 작성하여 추가한다. 테스트하고자하는 부분을 지원하기에 engine이나 script가 미흡할 경우, 각각의 개발자가 그때 그때 업그레이드를 하는 식으로 진행 하였고, 지금은 상당히 훌륭한 기능을 하게 되었다.


이 두가지 테스트 프레임웍을 훌륭하게 유지하면, 개발자의 아주 뻔한 실수부터, 완전 뒷통수 때리는 황당한 side effect까지 예방할 수 있다. 실제로도 그런 경험을 다수 했기 때문에, 나는 이 방법론에 대해서는 백프로 긍정적이다. 현 시점에서부터, 앞으로 30년동안 이보다 더 완벽한 개발 방법론이 있을까 싶을 정도로 신봉한다. 


여기서 가장 큰 변수는, 개발자 각자가 유닛테스트와 발리데이터를 얼마나 성실하게 수행하느냐인데, 이게 생각보다 어렵다. 귀찮거나, 시간이 없거나, 부주의함으로 인해서 분명히 테스트가 놓치는 부분이 존재하게 된다. 개발자가 자신의 유닛테스트의 완벽함을 확인하는데 최선을 다하지 않는 이상 이렇게 놓친 부분은 오랫동안 공백으로 남게 되고, 언젠가는 문제의 소지가 발견 될 수도 있는 것이다. 또 한가지 위험성은, 양립할 수 없는 착각을 할 수 있다는 것이다. "내 코드는 어차피 유닛테스트와 발리데이터로 검사될거야" 라는 생각으로, 코드 한줄한줄에 심혈을 기울이기보다는 전체적인 구현에 촛점을 맞추게 된다. 이로써 개발속도가 더 빨라지기는 하지만, 부주의한 코딩의 습관이 점차 늘어간다. 즉 실수를 더 많이 하게 된다. 이는 완벽한 유닛테스트 코드의 작성이 밑바탕에 깔려 있어야 하는데, 유닛테스트 코드도 결국 사람이 작성하는것이기에 완벽할 수 는 없는것이다. 그래서 또다른 헛점이 노출된다.


이런 문제를 일부 완화하기 위해서 우리 팀은 GCOV 같은 code test coverage 툴을 이용한다. 이 analyser를 이용하면 코드의 어느 부분이 테스트가 안되었고, 어느부분은 불완전하게 테스트 되었는지 상당히 훌륭한 수준으로 파악 할 수 있다. 프로젝트 중반즈음, 빌드시마다 자동으로 code coverage report를 퍼블리시 하도록 구성해 놓아서, 일일히 수동으로 검사 할 필요가 없게 하였다.


하지만 아직까지는 아쉬운 점이 많다. 팀에 조금 더 여유가 있다면, 테스트 부분을 전담하여 관리하는 엔지니어가 있으면 좋을것 같다. code coverage report를 확인하여, 부족한 부분에 대한 유닛테스트 코드 추가를 각 개발자들에게 요구하거나 직접 작성하는 것으로 시작하여, 프로젝트 전반에 대한 이해를 가지고, 발리데이터에 추가되어야 하는 서비스 시나리오들을 간파해 내는 일들을 누군가 전담할 필요가 있다고 본다. 안타깝게도 남의 코드를 꿰뚫어보는 수준의 C++ 프로그래머는 결코 싸지 않고, 하고싶은 일의 수준이 높기때문에 아마도 이런 일만 전담해서 하려고 하는 프로그래머는 구할수 없을것이다. 그래서 development lead가 개발일을 줄이고 이런 일을 주도적으로 수행하는 경우가 많은것 같다.


결론적으로, TDD/BDD는 각자의 롤을 확실히 세우고, 장치를 잘 설계하면 정말 훌륭하지만, 이부분이 소흘해지면 구멍이 숭숭 난 빵처럼 실속이 없어져 버린다. 더불어 개발 팀장의 역량이 여실히 들어나는 개발 방법론이다.

'해외취업이야기' 카테고리의 다른 글

영국 워킹홀리데이 비자에서 워킹비자로  (2) 2015.03.19
영국 C++ 프로그래머 체감 연봉  (7) 2015.03.18
비 개발자 출신이 스크럼 마스터가 될 수 있는가?  (10) 2014.05.16
애자일(Agile)/스크럼(Scrum)  (10) 2014.01.27
TDD/BDD의 허와 실  (10) 2013.12.12
구인 시즌?  (2) 2013.10.17
블룸버그 인터뷰 후기  (4) 2013.10.15
황당한 인터뷰  (6) 2013.08.29
IKM Test  (0) 2013.08.04

태그

  • HOONS 2014.01.02 10:12

    얼마나 많은 예외상황을 계산 할 수 있느냐로 프로그래밍 실력이 측정될 수도 있다고 생각이 드네요. TDD를 하게 되면 스스로 생각해서 벨리데이션을 처리하는 부분이 느슨하게 된다는 것에는 공감이 갑니다. (^^)

    • 에즈베어 곰발자 2014.01.02 11:19 신고

      저도 동감입니다. 결국 프로그래밍 방법론은 나날히 발전하기에, 비단 새로운 언어나 스크립트를 익히는 것 뿐 만 아니라, 방법론에서 요구하는 새로운 능력들을 익히는 것 또한 프로그래머의 숙명인것 같습니다.

      그나저나 훈님 분야에서 굉장히 유명한 분인것 같네요! 무엇보다도 그 열정과 부지런함에 찬사를 보냅니다 ^^

  • 남궁건 2014.01.10 02:08

    가끔 블로그의 글들을 읽는 눈팅족입니다.
    좋은글 잘 봤어요~~ㅎ

  • 꺄아 2014.01.13 23:13

    안녕하세요, 또 찾아왔습니다 :)
    새해 복 많이 받으세요~~
    밑에 해고 당하고 댓글 남겼었는데, 12월 31일에 겨우겨우 비자 받고, 새로운 곳으로.. 멀리 이사왔습니다. :)
    항상 London 이나 근교에서만 살다가 드디어 이렇게 멀리도 나와서 살아 보네요..... 저번에 우울한 이야기만 남겨드리고 간 것 같아서 새 소식 전해 드릴 겸 방문 했습니다.

    언제 한번 시간 되실 때 London 이든 중간 지점에서 뵙고 여러가지 배우고 싶습니다. 새로운 회사에서 자리 잘 잡고 또 들리겠습니다. 능력자 분들을 뵈면 항상 존경하는 마음이 가득가득한데, 어떻게 실력을 늘릴 수 있을지.. 어떤 걸 해야 할지 구분도 못 하는 초보라 까마득하기만 합니다. 언제 한번 시간 되시면 꼭 한번 뵙고 이런 저런 좋은 말씀 듣고 싶습니다. :)

    항상 좋은 일만 가득한 2014년이 되시길 기원합니다.

    • 에즈베어 곰발자 2014.01.15 11:58 신고

      오오오. 축하드려요!!
      좋은소식 전해주셔서 감사합니다 ㅎㅎ
      멀리 가셨다고 했는데 어느지역으로 가셨나요?
      런던에서 멀어지면 지루하긴한데 나름 삶의 여유가 있는것 같습니다.
      저야말로 능력부족으로 전전긍긍하고있으니 저한테 배울건 전혀 없으실거에요. 그리고 일이야기 하는거 별로 재미없잖아요 ㅋㅋ 갠적으로 메일주시면 나중에 런던에갈일 있으면 연락 드릴게요.
      새직장과 비자 다시한번 축하드립니다!

  • 산미치광이 2014.01.16 07:52

    안녕하세요.
    한 1년 전쯤 우연히 svn 사용 관련내용을 검색하다가 들른 후 이런 저런 얘길 듣고 즐겨 찾기 추가를 해놨었는데.. ㅎㅎ 오늘 다시 들어와서 보니 감회가 새롭네요. 지금은 저도 이직을 하여 (비록 한국에 있는 외국계 회사이긴 하지만)
    미국 엔지니어들과 협업을 하고있습니다. agile , TDD 뭐 이런 방식으로 embedded 쪽으로 하고 있죠.
    새해에도 늘 좋은 글 많이 부탁 드릴게요.
    복 많이 받으세요~ ^^

    • 에즈베어 곰발자 2014.01.16 16:30 신고

      반갑습니다. 일년만에 찾아주신거네요. 이런 감사할데가 ^^; 더 만족스러운 포지션을 찾으신것 같네요. 축하드립니다. 글을 가뭄에 콩나듯 적는데, 1년만에와주셨으니 그래도 새로운글이 몇개는 있어서 덜 챙피하군요.
      새해 복 많이 받으세요!! ^^

  • 침착함 2014.02.12 00:20

    안녕하세요.
    SVN merge관련 내용을 찾다가 들어와서 여러 글들을 읽어보게 되었습니다.
    회사 입사한 지 이제 막 2년 차인데 TDD에 대한 경험자도 없고
    저도 학교에서 이런 내용들을 배운 경험이 없어서,
    대체 이걸 어떻게 실제로 적용할지 막막하기만 합니다.
    여러 글들을 읽어보고 있는데 혹시 추천할만한 책이나 글이 있을까요?
    간단한 예제로 만들어볼 때는 쉽지만
    막상 제가 직접 작업하는 코드에 적용하려니 답답합니다.
    이런 좋은 글 남겨주셔서 감사합니다.

    • 에즈베어 곰발자 2014.02.12 07:54 신고

      안녕하세요?
      저도 어디서 보고 배운것이 아닌지라 추천해드릴만한 책이나 글은 안타깝게도 없네요. 2년차시면 팀 리더가 아니실테니, 본인이 짠 코드에 유닛테스트 코드를 추가하는것부터 시작해보세요. 비록 본인 일만 늘어나서 결국 포기하게 될 가능성이 있긴 하죠.
      되도록 팀장과 팀원들에게 유닛테스트 작성을 공식 업무화 하자고 해보세요. (일 늘린다고 돌맞으실지도 모르지만..)