AI 시대의 TDD, 궁극의 애자일을 향하여
AI 시대에 TDD는 어떤 의미를 가질까요?
누군가는 “AI가 코드를 짜주는데 테스트가 왜 필요해?”라고 물을 수 있습니다.
하지만 저는 오히려 지금이야말로 TDD가 빛을 발할 때라고 생각합니다.
저는 TDD를 두 가지 관점에서 바라봅니다.
하나는 스펙을 정하고 구현하고 개선하는 사이클의 반복,
다른 하나는 빠른 피드백 루프로 학습하며 목표를 향해 나아가는 방법입니다.
첫 번째 관점: Red-Green-Refactoring 사이클
TDD(Test-Driven Development)1의 핵심은 Red-Green-Refactoring 사이클입니다.
- Red: 실패하는 테스트를 먼저 작성한다
- Green: 테스트를 통과하도록 구현한다
- Refactoring: 코드를 개선한다
이 사이클을 다르게 표현하면 이렇습니다:
- Red: 스펙과 인터페이스를 명확히 정의한다
- Green: 일단 작동하게 만든다
- Refactoring: 더 나은 설계로 개선한다
기존에는 Green 하나도 제대로 못 하는 경우가 많았습니다.
시간에 쫓기고, 복잡성에 압도당하고, 결국 “일단 돌아가게” 만들고 끝내버리죠.
AI가 함께하면서 상황이 달라졌습니다.
AI와 함께하는 TDD 사이클
- Red: 스펙을 명확히 밝히는 게 더 중요해졌습니다.
AI에게 무엇을 원하는지 정확히 전달해야 원하는 결과를 얻을 수 있으니까요. - Green: AI 덕분에 빠르게 구현할 수 있습니다.
일단 테스트를 통과하게 만드는 데 집중합니다. - Refactoring: 부담 없이 개선을 요청할 수 있습니다.
사람에게 부탁하기 어려운 세세한 작업도 거리낌 없이 맡길 수 있습니다.
그리고 결과를 보고 다시 Red로 돌아갑니다.
놓친 케이스는 없는지, 테스트가 충분한지 검토하며 사이클을 반복합니다.
두 번째 관점: 빠른 피드백 루프
AI 시대의 개발 방법, 특히 Spec-Driven Development2 같은 접근을 워터폴처럼 느끼는 분들이 있습니다.
“스펙을 먼저 정하고 개발한다고? 그거 워터폴 아닌가?”
아닙니다.
우리는 커다란 계획을 먼저 세우고 그대로 실행하는 게 아닙니다.
- 빠르게 계획하고
- 빠르게 구현하고
- 빠르게 피드백하고
- 빠르게 다시 계획을 수정합니다
이것이야말로 궁극의 애자일입니다.
AI가 이 속도를 가능하게 해줍니다.
TDD는 단순히 테스트 코드를 먼저 쓰는 게 아닙니다.
빠른 피드백 루프를 통해 자신감을 갖고 앞으로 나아가는 것.
AI 덕분에 이게 가능해졌고, 이게 워터폴과의 결정적 차이입니다.
미시적 TDD를 넘어, ATDD로
기존에는 미시적 TDD도 힘들었습니다.
함수 하나, 클래스 하나 수준의 테스트조차 제대로 작성하기 어려웠죠.
거대한 TDD 사이클, 즉 ATDD(Acceptance Test-Driven Development)는 꿈 같은 이야기였습니다.
AI 덕분에 상황이 바뀌었습니다.
ATDD 사이클이 짧아졌습니다.
기능 단위로 스펙을 정의하고, 빠르게 결과를 확인하고, 바로 방향을 조정합니다.
Specification by Example도 자연스러워졌습니다.
"이런 입력이 들어오면 이런 결과가 나와야 해"라고 예시를 들면,
AI가 그에 맞는 테스트와 구현을 함께 만들어줍니다.
예전엔 몇 주 걸리던 피드백 루프가 몇 시간, 몇 분으로 줄어들었습니다.
새로운 기회
AI를 활용하는 개발이 누군가에겐 낡은 방법으로의 회귀처럼 느껴질 수도 있습니다.
"스펙 문서? 그거 예전에 하던 거잖아."
"계획을 세운다고? 애자일 아니었어?"
하지만 올바르게 일하려는 사람들에게는 새로운 기회입니다.
스펙을 명확히 하고, 계획을 세우고, 테스트를 먼저 작성하는 것.
이것들은 낡은 방법이 아니라 원래 옳았던 방법입니다.
현실의 제약 때문에 제대로 하기 어려웠을 뿐이죠.
AI가 그 제약을 걷어냈습니다.
이제 우리는 급진적인 TDD를 통해 빠르게 피드백하고, 자신감을 갖고 앞으로 나아갈
수 있습니다.