TDD with Agile
TDD 란 무엇일까?
TDD 는 기능 구현에 중점을 둔 테스트 방법론이다.
TDD 는 왜 필요할까?
이름만 들으면 알만한 인하우스 회사들은 대부분 TDD 를 하지 않을까 생각한다. 또한 스타트업도 마찬가지일 것이다.
한번 이런 생각을 해보면 좋을 것 같다.
왜 유명한 회사들, 개발 문화가 좋은 회사들은 TDD 를 하는 것일까?
TDD 는 애자일 선언문 원칙과 익스트림 프로그래밍에 뿌리를 둔다.
애자일 선언문
애자일 선언문을 보면 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대응하기를 더 높은 가치로 두고있다.
다시 돌아와서, 스타트업에서 왜 Agile 한 문화를 선택하고 있는지 생각해 보자.
Agile 은 민첩한 이라는 의미를 가지고 있다.
스타트업은 매 순간 순간의 선택이 상당히 중요하다. 때로는 고객들이 진정으로 필요한 서비스를 출시하기 위해 1-2 개월 내에 새로운 서비스를 만들어 출시를 해야할 수도 있다.
왜 그렇게 빨리 출시할까?
빨리 출시해서 고객의 반응을 보고 고객으로부터 나오는 피드백을 수용하여 민첩하게 프로그램을 변화시키면서 서비스를 개선하는 것이, 고객들이 원하는 좋은 서비스를 만드는 지름길이지 않을까라고 감히 생각해본다.
따라서, 스타트업은 항상 민첩하게 움직일 준비가 되어있어야 빠른 성장세를 보여준다고 생각한다.
- 고객의 반응을 보고 고객으로부터 나오는 피드백을 수용 : 고객과의 협력 이라고 생각한다.
- 변화에 대응 : 민첩하게 변화에 대응하는 것을 의미하는 것이라고 생각한다.
애자일 선언 이면의 원칙
애자일 선언 이면의 원칙을 살펴보면 위에 설명한 내용과 유사하다.
맨 아래에 적힌 문구를 잠깐 살펴보자.
최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
개발을 만으로 2년간 해오면서 느낀점은 정답은 없다라는 것이다. 정답을 찾으려 하지말고, 주어진 상황에서 최선을 찾으려는 것이 중요하다고 생각한다. 회사마다 각자 문화, 상황, 어떤 서비스를 제공하는지 등 전부 다르기 때문이다.
다시 돌아와서, TDD 가 왜 필요한지 생각해 보자.
소프트웨어를 일찍 그리고 지속적으로 전달해야하는 애자일하게 돌아가는 문화에서, TDD 가 없으면 우리가 만든 서비스가 제대로 작동하는지 보장 할 수 있을까?
나는 없다고 생각한다.
설령 보장하는 방법이 있다 하더라도, 그 방법론이 TDD 보다 뛰어나고 효과적이었다면 이미 많은 인하우스 기업들이 채택하여 사용하고 있지 않았을까 생각한다.
기술 부채
애자일하게 돌아가는 문화에서, 2개월 안에 새로운 서비스를 출시해야한다고 가정하자.
2개월간 열심히 TDD 를 사용하여 개발하여서 고객들에게 선보였다.
2개월간 작성된 코드는 과연 최상의 품질을 지니고 있을까?
그러지 않을 것라고 생각한다.
그러면 결국 코드 품질이 좋은 상태가 아니므로, 그대로 두면 기술 부채로 이어질 것이다.
이러한 기술 부채는 쌓아두면 위험하다. 쌓인 기술 부채들을 해결하지 않고, 계속 계속 쌓아두기만하면 나중에는 기술 부채를 해결하려고 개발자를 추가로 고용해도 힘들 것이고, 최악으로는 아예 새로 만드는 것이 빠를 수도 있을 것이다.
기술 부채가 쌓이는 것 자체는 나쁘다고 생각하지 않는다. 주어진 상황에서 최선을 선택하다보면 쌓일 수 밖에 없는 상황이 있겠지만, 그것을 빠른 시일 내에 해결하지 않고 계속 쌓아두는 것이 문제라고 생각한다.
다음으로
다음번엔, TDD 사이클에 대해 다뤄볼 예정이다.
References
'TDD' 카테고리의 다른 글
| Write a test code right now (1) | 2022.03.24 |
|---|
