채용 면접을 하면서 많이 받는 질문 중 하나가, ‘개발 문화가 어떻게 되나요?’입니다. 더 자세하게 말해달라고 하면, ‘코드 리뷰는 하는지, TDD나 테스트케이스는 작성하는지’를 궁금해하십니다. 그리고 더 대화를 나눠보면, 많은 분들이 좋은 개발 실천법에 대한 동경이나 환상, 그리고 본인이 그것을 실천하고 있지 못하는 데에 대한 죄책감이나 부담감을 가지고 있는 것을 느낍니다. 아무래도 저희 포지션에 지원하시는 2~4년차 사이의 분들이 겪는 과정인 것 같습니다.

오늘은 그 중에서 TDD에 대한 이야기를 해볼까 합니다. 코드 리뷰에 대해서도 곧 쓸 계획입니다.

TDD가 가진 여러 측면이 있지만, 그 중에서 하나를 꼽아보면 test-first라는 특징이 있습니다. 이야기를 나눠보면 적지 않은 분들이 여기서 막히는 것을 발견하게 됩니다. 몸에 익지 않아서 잘 실천이 안되거든요. 하지만 저는 test-first가 꼭 중요한 것은 아니고, test-last여도 무방하다고 생각합니다. 테스트를 작성하는 것이 먼저냐 나중이냐보다 훨씬 더 중요한 것이 있다고 생각하거든요.

바로, 코드 작성-결과 확인의 피드백 루프가 짧게 진행되는 것입니다.

긴 피드백 루프 안티패턴

웜블러드에서는 채용 과정에서 코딩 과제를 라이브 코딩으로 진행합니다. 이를 통해 수십 명이 개발하는 모습을 관찰해올 수 있었습니다. 짧은 시간 안에 압박을 받는 상황이어서 제 기량을 충분히 발휘할 수 없는 상황일 수 있겠지만, 몇 가지 패턴들이 보이곤 합니다.

웜블러드에서 한 사람의 개발자가 진행하는 개발의 전반적인 범위는, ORM을 사용해서 테이블을 만드는 것, 비즈니스 로직을 만드는 것, 데이터를 화면에 표시하는 것, 화면의 상호작용 요소를 비즈니스 로직과 연결하는데까지 걸쳐있습니다.

지원자 분들에게서 가장 많이 보이는 패턴은, 여러 레이어에 걸친 작업이 분리되지 않고, 한쪽 끝에서 일부분을 개발하고 반대쪽 끝에서 확인하는 것입니다.

이를테면, 기능에 필요한 테이블을 만들고, 그 효과를 화면을 만들면서 웹브라우저를 통해 실행해보면서야 확인하는겁니다. 비즈니스 로직 하나를 변경하고 나서도 웹브라우저를 실행시켜서 화면에서 버튼을 클릭해가면서 동작시켜보면서 결과를 확인합니다. 결과적으로, 피드백 루프의 길이가 매우 길어집니다. 코드를 변경하고 나서 결과를 확인하기까지 시간이 오래 걸리고 번거롭습니다. 그래서 피로감이 생기고, 코드를 여러번 수정하고 실행하기 어렵게 됩니다. 그리고 이런 저런 설계 실험/시도를 하는 횟수가 엄청나게 줄어듭니다.

짧은 피드백 루프로서의 TDD

Extreme Programming에서는 여러 층위의 피드백 루프를 소개하는데, 그 중에서 초 단위, 분 단위의 피드백 루프가 바로 코드 작성과 단위 테스트입니다.

Extreme programming의 feedback loop 다이어그램

제가 예전에 썼던 글에서 언급했던 짝 작업 사례에서도 코드 작성과 테스트 작성-실행의 간극에 대한 얘기가 나오는데, 그때 저와 함께 짝 작업을 했던 다른 주니어 개발자분은 테스트 작성과 실행의 사이클이 하루 단위였고, 저는 수십초에서 수 분 수준으로 굉장히 짧았다는 것이 주요한 차이점이었습니다. 주니어 개발자분은 하루 수준의 큰 작업에 대한 코드를 쭉 작성했고, 그 코드 작성이 끝나면 그에 대한 테스트 코드를 쭉 작성했습니다. 반면에 저와 짝 작업을 할 때는 수줄-십수줄 정도의 코드를 작성하고 그것을 함수나 메소드로 떼어내어 그에 대한 테스트 코드를 작성했는데, 그 간격이 수분~수십분 수준이었습니다. 그리고 로직과 테스트가 같은 층위에 있어서 로직을 실행하는데 필요한 과정이 매우 짧았습니다.

이렇게 되면 단위 테스트를 먼저 작성하는지 나중에 작성하는지를 따지는 것이 크게 중요하지 않습니다.1 수십 초 내지는 수 분 수준으로 테스트 작성과 실행이 반복되기 때문에, 테스트가 먼저인지 실행-결과 확인이 먼저인지가 닭과 달걀처럼 물고 물리거든요.

짧은 피드백 루프는 개발의 인지적인 측면에도 영향을 미칩니다.

칙센트미하이는 몰입을 연구한 학자입니다. 그는 몰입이 일어날 수 있는 조건으로, 명확한 목표, 정확한 규칙, 신속한 피드백을 이야기2합니다. 개발을 짧은 단위로 쪼개어 한 시점 한 시점에서의 범위를 줄이고 목표를 명확하게 하며 짧은 피드백 루프 환경을 만들면, 개발에 몰입하게 되며 리듬감이 생깁니다. 개발된 코드들을 믿을 수 있게 되고, 확신 있는 한 걸음 한 걸음을 내딛으며 ‘작은 성취들의 연속’으로 개발을 진행해나가게 됩니다.

개발 이외의 업무에서도 피드백 루프를 짧게 하여 비슷한 효용을 얻을 수 있습니다.

웜블러드에서는 특별히 TDD를 강조하지는 않습니다. 하지만 그 기저 원리인 짧은 피드백 루프의 중요성에 공감하고, 일상적인 개발에서 피드백 루프가 짧게 만들어지도록 노력하고 있습니다. 또한 테스트가 용이한(testability) 코드를 작성하는 것을 추구합니다. 결국 그렇게 하는 것이 리듬감이 생기고 더 정확하고 문제가 적은 코드를 만들어낸다는 것을 이해하고 있습니다.

  1. 단위 테스트를 먼저 작성하느냐 나중에 작성하느냐와는 별개로, 단위 테스트를 작성하는 것 자체는 테스트가 용이한 코드를 작성하는 데에 중요합니다. 테스트가 용이한 코드는, 격리시킬 수 있다는 특징이 있습니다. ↩

  2. 미하이 칙센트미하이가 쓴 ‘몰입의 즐거움(Finding Flow)’ 5장에는 이런 구절이 나옵니다. “앞에서 보았듯이 사람의 기분은 몰입 상태에 있을 때 절정에 이른다. 그것은 도전을 이겨내어 문제를 해결한 뒤 무언가 새로운 것을 발견하는 순간이다. 몰입을 낳는 활동은 대부분 명확한 목표, 정확한 규칙, 신속한 피드백이라는 공통점을 갖는다.” ↩