테스트 코드는 프로젝트 일정을 늦춘다??
안녕하세요. yeTi입니다.
오늘은 테스트 코드는 도입하고 싶은데 프로젝트 일정에 안 좋은 영향을 줄거같은 걱정을 해소해 드릴 수 있는 근거를 공유해보고자 합니다.
개요
현업에서 개발하시는 분들(개발자 혹은 리더) 과 대화를 하다보면 간혹 다음과 같은 질문을 받습니다.
테스트코드를 작성하면 개발일정을 맞추기가 힘든데 어떻게 도입할 수 있을까요?
그 동안 저도 프로젝트 일정을 늦추는 요인은 된다고 생각하고 있었는데요. 근래에 그렇지 않다 라는 생각이 들어 그 생각을 공유합니다.
프로젝트 일정과 개발 일정
테스트 코드는 개발 일정은 지연 요소가 될 수 있더라도 프로젝트 일정은 단축 요소라고 생각합니다.
왜에 대해서는 아래에 계속해서 얘기해 보겠습니다.
왜 지연요소라고 인식하는가?
코드를 타이핑(코딩) 하는 시간은 명확히 두 배 이상 소비하는 것은 맞습니다. (개발 일정의 지연 요소)
반면에 다른 요소들을 보겠습니다. 만일 아래 요소들에서는 긍정적인 요소라면 프로젝트를 관리하는 측면에서는 득이되지 않을까요?
- 팀내 테스트 scope의 공유
- 자동화된 회귀 테스트(regression testing)
- 개발 사항에 대한 업무 공유
우리는 코딩에만 시간을 쏟는가?
개발이라는 활동이 코딩만 하는것을 의미할까요? (개발이라는 의미가 중복의 의미가 있어 여기서는 코딩이라는 용어로 타이핑하는 활동을 표현하겠습니다.)
명백히 아닙니다.
개발이라는 활동은 목적을 가지고 목표를 공감한 후 적절한 설계와 코딩을 합니다.
바로 배포하나요? 아마도 검증이라는 단계를 거친 후 릴리즈를 할 것으로 예상합니다.
또한 개발하는 인력 또한 프로젝트에서는 관리 변수입니다. 사람이 바뀌면 업무를 위한 지식 공유는 어떻게 하나요?
동료가 잠시 자리를 비운다면 업무 공백은 어떻게 백업하나요?
개발자는 내가 목표에 맞게 설계 및 코딩을 했는지 무엇으로 증명하고 있나요?
이처럼 우리가 개발 활동에서 코딩이 차지하는 비중은 얼마나 될까요? 테스트 코드가 코딩하는 시간 외에 추가적으로 지연시키는 요소가 있나요?
개발 활동에서 코딩이 차지하는 비중은 생각보다 크지 않고, 테스트 코드는 코딩하는 시간 외에는 개발 활동에서 지연 요소가 되지 않습니다.
테스트 코드의 효용성
앞서 언급한 세가지 요소들에 대해 자세히 다뤄보겠습니다.
팀내 테스트 scope의 공유
두 명 이상의 개발자가 동일한 repository의 코드를 수정한다고 가정해보겠습니다. 그리고 두 개발자는 테스트를 request를 하는 방식으로 진행한다고 가정해 보겠습니다.
만일 두 개발자가 생각하는 테스트의 scope이나 유효한 검증 변수가 다르다면 어떻게 공유하시나요? 공유하지 않고 각자 on my way하시나요?
그렇다면 만일 한 개발자가 수정한 코드에서 버그가 발생했는데, 본인은 인지하지 못하는 테스트 scope 이었지만 다른 개발자는 인지하고 있었던 테스트 scope이라면 예방할 수 있었던 버그 아니었을까요?
이처럼 두 개발자가 생각하는 테스트 scope이나 검증 변수가 테스트 코드로 공유가 된다면, 꼭 테스트 코드가 아니더라도 공유가 된다면 예방할 수 있는 버그들이 존재합니다.
자동화된 회귀 테스트(Regression Testing)
테스트 자동화는 서비스 품질을 유지하는데 매우 큰 효용 가치를 가지고 있습니다.
혹시 자신이 개발한 부분이 다른 기능에 side-effect를 발생하지 않는다는 확신을 가지고 있는 개발자가 있을까요? 저는 아직 현업에서 본적이 없습니다.
자동화된 회귀 테스트는 side-effect가 없다는 확신을 제공합니다. 추가적인 말이 필요할까요?
개발 사항에 대한 업무 공유
흔히 말하는 산출물. 혹은 개발 문서를 작성하는 이유가 무엇일까요?
이전에 쓴 설계의 목적과 검수하는 문화와 같이 검수가 목적인 경우도 있습니다.
혹시 그 외에 문서를 위한 문서를 작성하고 계시진 않을까요?
그렇지 않다면 대부분 공유를 위한 기록이 목적일 것입니다.
개발 사항에 대한 공유를 위한 기록을 해보신 분들은 아시겠지만, 이 또한 유의미하게 사용할 수 있는 문서로 유지하기 위해서는 코딩하는 시간과 노력만큼의 공수가 필요합니다.
만일, 문서를 타이핑할 시간에 테스트 코드를 타이핑하고 테스트 코드가 문서의 효용성을 대체할 수 있다면 문서가 필요할까요? 이에 대해서 XP에서는 다음과 같이 말합니다.
오직 코드와 테스트만 영구 산출물로 유지하라. 다른 문서들은 코드와 테스트에서 생성되도록 한다. 프로젝트 역사의 중요한 부분은 살아있게 하는 일은 사회적 메커니증에 맡긴다.
고객은 시스템이 현재 하는 일, 그리고 시스템이 미래에 하도록 팀이 만들 수 있는 일에 대해 비용을 지불한다. 가치의 이런 두 원천에 기여하는 산출물은 그것이 어떤 산출물이든 가치를 지닌다. 그렇지 않은 것은 모두 쓰레기다. - .p.113, 익스트림 프로그래밍, 켄트 벡&신시아 안드레스
문서보다 코드를 간결하게 유지하고 테스트 코드로 검증하세요.
신뢰성 확보
무명 블로거가 약한 근거로 주장하는 말에는 신빙성이 적어 신뢰도가 낮을 것으로 짐작합니다.
그래서 테스트 코드를 바라보는 유명한 분들의 시각을 인용해보겠습니다.
XP에서 테스트는 프로그래밍만큼 중요하다. 테스트의 작성과 실행은 팀 스스로 자랑스럽게 여길 작업을 할 기회를 준다. 테스트를 돌려보면 예상하지 못한 방향으로 팀이 빠른 속도로 움직일 때 팀에 자신감의 타당한 기반을 제공해 준다. 테스트는 팀 내부의 신뢰와 고객과의 신뢰를 강화함으로써 개발에 기여한다. - p.158, 익스트림 프로그래밍, 켄트 벡&신시아 안드레스
테스트: 자동화되고 구체적이며 명확한 테스트를 말한다. 버튼을 누르면 테스트가 실행된다. TDD의 아이러니 중 하나는 TDD가 테스트 기술이 아니라는 점이다(워드 커닝엄의 선문답이다). TDD는 분석 기술이며, 설계 기술이기도 하다. 사실은 개발의 모든 활동을 구조화하는 기술이다. - p.325, 테스트 주도 개발, 켄트 벡
설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라. 머릿속에 객체의 협력 구조가 번뜩인다면 그대로 코드를 구현하기 시작하라. 설계가 제대로 그려지지 않는다면 고민하지 말고 실제로 코드를 작성해가면서 협력의 전체적인 밑그림을 그려보라. 테스트-주도 설계로 코드를 구현하는 사람들이 하는 작업이 바로 이것이다. 그들은 테스트 코드를 작성해 가면서 협력을 설계한다. - p.225, 객체지향의 사실과 오해, 조영호
XP에서는 테스트는 프로그래밍만큼 중요하다고 말하고, TDD에서는 개발의 모든 활동을 구조화하는 기술이라고 말하며, 객체지향의 사실과 오해에서는 객체의 협력 설계를 테스트 코드를 작성해 가며 하라고 말합니다.
왜 다들 테스트 코드의 중요성을 말할까요?
저는 코드를 타이핑하는 것 이상으로 테스트 코드를 만드는 것이 인간이 인지하는 방식을 명확히하고 새로운 시각을 제공하기 때문이라고 생각합니다.
진입장벽은 분명히 존재한다.
개발하는 시간도 빠듯한데 테스트 코드를 만들 시간은 어디있나요? 테스트 코드가 만들고 싶다고 뚝딱 만들 수 있는 건 아니잖아요.
분명히 테스트 코드를 작성하기 위해서는 진입장벽이 존재합니다.
그러나 다음과 같은 측면에서 생각해보는건 어떨까요?
- 테스트 코드를 만들지 않더라도 품질에 대해 생각해보신적이 있나요?
- 내가 만든 코드가 기존 기능에 side-effect를 만들지 않는다고 확신하시나요?
- 다른 사람이 생각하는 테스트 scope이 궁금하지 않으신가요?
- 내가 사용하는 기술(언어, 프레임워크)에 대한 이해도는 어느 정도 이신가요?
직관적으로 테스트 코드를 작성하기 위해서는 분명한 진입장벽이 존재하고 이를 뛰어 넘어야만 테스트 코드가 팀의 기술 부채로 전락하지 않습니다.
하지만 분명한 것은 테스트 코드를 작성하기 위한 고민조차 내가 기여하고 있는 서비스의 품질을 높이는데 도움이 될 것이라는 겁니다.
다급함 본능
팩트풀니스에서는 인간의 10가지 본능 중 하나로 다급함 본능을 말합니다.
두렵고 시간에 쫓기고, 최악의 시나리오가 생각날 때면 인간은 정말로 멍청한 결정을 내리는 성향이 있다. 빨리 결정하고 즉각 조치를 취해야 한다는 다급에 쫓기다 보면 분석적으로 생각하기 어렵다. - p.323
저는 위 인용문을 보고 개발 활동에서는 항상 시간에 쫓기는 두려움이 존재한다. 는 생각이 들었고 이 때문에 사업가나 관리자, 리더, 개발자 모두가 다급함 본능에 휩쓸려 업무를 진행하고 있을 것이라는 생각을 했습니다.
저의 경우에도 중요하지 않은 요구사항은 없었고, 긴급하지 않은 개발건은 없었기 때문입니다.
그런데 쉽지 않겠지만, 한발 물러서서 바라보면 생각보다 중요하지 않은 일들이 있고, 생각보다 긴급하지 않은 일들도 있습니다.
이러한 맥락에서 우리가 코딩을 하는 본질을 생각해본다면 테스트 코드가 없을 때의 개발 효율성보다 테스트 코드가 있을때의 개발 효율성이 향상될 것이라고 기대합니다.
결론
제목으로 돌아가 보겠습니다.
테스트 코드를 프로젝트 일정을 늦춘다??
아닙니다. 테스트 코드는 프로젝트 혹은 서비스 혹은 제품을 보다 긴밀하게 만들어주고 서비스의 구조를 탄탄하게 해주며 개발자에게 자신감을 제공해줄 수 있는 것입니다.
저도 실무에서 적용해본 결과.
테스트 코드가 없는 환경에서는 개발자와 리더간에 굉장히 단순한 피드백으로 협업하며 빠르게 개발되는 것 같지만,
그렇게 만들어진 코드의 품질을 보완하고 서비스의 신뢰도를 유지하기 위해서는 비용은 투입하면서도 명확하게 개선되었고 side-effect는 없다는 확신을 할 수 없는 환경이었습니다.
테스트 코드는 서로간에 신뢰를 쌓을 수 있는 근간입니다.