tddbuddy.com에서 처음 게시되었습니다.

AI는 몇 초 만에 코드를 작성합니다.

그것은 더 이상 어려운 부분이 아닙니다.

어려운 부분은 그 코드가 올바른지 아는 것입니다. 247번 라인의 예외 케이스(edge case)를 처리하는지, $99.99 주문에는 무료 배송이 적용되지 않지만 $100 주문에는 적용된다는 비즈니스 규칙을 준수하는지 말입니다.

코드 리뷰(Code review)가 여기서 당신을 구원해주지 못할 것입니다.

AI의 속도로는 불가능합니다.

리뷰 병목 현상은 이미 무너져 있었다

대부분의 팀은 코드를 주의 깊게 리뷰하지 않습니다. 그들은 훑어봅니다. 패턴을 매칭합니다. 일정이 밀려 있기 때문에 승인합니다.

그것은 AI가 등장하기 전에도 사실이었습니다.

이제 에이전트(agent)가 30초 만에 500줄의 코드를 생성하는데, 이미 훑어보기 급급했던 동일한 리뷰어가 그 모든 것을 추론해야 한다고 말입니까?

그들은 그러지 못할 것입니다. 아무도 그렇게 하지 않습니다.

의식(ritual)은 남지만, 보호막은 사라집니다.

그리고 아무도 입 밖으로 내뱉고 싶어 하지 않는 부분이 있습니다: 코드 리뷰는 우리가 대단한 안전망인 것처럼 가장했던 것과는 거리가 멀었습니다. 연구들에 따르면 리뷰는 결함의 약 60%만을 잡아냅니다. 쉬운 것들 말입니다. 테스트가 어차피 잡아냈을 법한 것들 말이죠.

리뷰는 품질 게이트(quality gate)로 포장된 사회적 의식에 불과합니다.

테스트는 사후 고려 사항이 아니라 명세(Specification)이다

이 지점이 사고의 전환이 일어나는 곳입니다.

테스트를 코드를 작성한 후에 하는 무언가로 생각하는 것을 멈추십시오. 테스트는 **명세(specification)**입니다. 시스템이 무엇을 해야 하는지에 대한 실행 가능한 설명입니다.

테스트를 먼저 작성할 때, 당신은 "테스트를 위해 속도를 늦추는 것"이 아닙니다.

당신은 계약(contract)을 정의하고 있는 것입니다.

• 입력값(inputs)은 무엇인가?
• 경계(boundaries)는 어디인가?
• 가장자리(edges)에서는 어떤 일이 발생하는가?
• "완료(done)"된 상태는 어떤 모습인가?

그 계약은 기계가 읽을 수 있습니다. 어떤 에이전트(agent)도 그 계약에 맞춰 코딩할 수 있습니다. 어떤 CI 파이프라인(CI pipeline)도 이를 검증할 수 있습니다. 어떤 배포(deployment)도 이를 통해 유효성을 확인할 수 있습니다.

실패하는 테스트 스위트(test suite)는 AI에게 줄 수 있는 가장 명확한 브리프(brief)입니다: 여기에 정확히 무엇이 잘못되었는지 있으니, 가서 고쳐라.

그것은 어떤 인간 리뷰어가 제공하는 것보다 더 긴밀한 피드백 루프(feedback loop)를 제공합니다.

빌드-테스트-피드백 루프

실제로 확장 가능한 워크플로우는:

1. 계약 정의 (Define the contract): 동작을 명시하는 테스트를 작성합니다.
2. AI 생성 허용 (Let AI generate): 속도는 AI의 강점입니다.
3. 테스트 실행 (Run the tests): 즉각적이고, 객관적이며, 완전합니다.
4. Red? AI 반복 (Red? AI iterates): 실패한 테스트 그 자체가 피드백입니다.
5. Green? 배포 (Green? Ship it): 테스트가 곧 리뷰입니다.

3일 동안 큐(queue)에 쌓여 있는 PR은 없습니다. 형식적인 승인(rubber stamps)도 없습니다. 리팩터링(refactor) 속에 숨겨진 'off-by-one error'를 리뷰어가 놓치는 일도 없습니다.

테스트가 잡아내거나, 아니면 못 잡아내거나입니다.

그리고 테스트가 훌륭하다면, 반드시 잡아냅니다.

이것이 지금 중요한 이유

TDD를 실천하는 팀은 코드 리뷰에 의존하는 팀보다 AI 에이전트(AI agents)를 더 빠르고 안전하게 도입할 것입니다.

TDD가 유행이기 때문이 아닙니다.

테스트 스위트(test suite)가 인간의 의도와 기계의 실행 사이를 잇는 **인터페이스 계층 (interface layer)**이기 때문입니다.

테스트가 없다면, AI 에이전트는 허공을 향해 코드를 생성하는 것과 같습니다. 피드백도 없고, 완료의 정의(definition of done)도 없습니다. 에이전트가 여는 모든 PR은 인간의 전수 검사를 필요로 하며, 이는 자동화의 목적 자체를 무색하게 만듭니다.

테스트가 있다면, 에이전트는 필요한 모든 것을 갖게 됩니다:

• 실패한 테스트 (Failing tests): 무엇을 구축해야 하는지 알려줍니다.
• 통과한 테스트 (Passing tests): 언제 완료되었는지 알려줍니다.
• 테스트 출력 (Test output): 무엇이 잘못되었는지 알려줍니다.

이것이 완전한 피드백 루프(feedback loop)입니다. 마지막 단계 전까지는 인간이 필요하지 않습니다.

불편한 결론

코드베이스에 양질의 테스트 커버리지(test coverage)가 없다면, AI 에이전트를 받아들일 준비가 되지 않은 것입니다.

원하는 만큼 코드를 생성할 수는 있습니다. 하지만 자동화된 검증(automated verification)이 없다면, 당신은 그저 검토되지 않은 변경 사항을 더 빠르게 생산하고 있을 뿐입니다.

그것은 생산성이 아닙니다. 더 나은 도구를 사용한 위험의 축적일 뿐입니다.

TDD는 속도를 늦추는 것에 관한 것이 아닙니다. 단 한 번도 그런 적이 없었습니다.

TDD는 속도를 유지하면서도 생존 가능하게 만드는 비계(scaffolding)를 구축하는 것에 관한 것입니다.

테스트는 가드레일(guardrail)이고, AI는 엔진이며, 당신은 설계자(architect)입니다.

그리고 설계자는 모든 벽돌을 일일이 검토하지 않습니다. 스스로 자립할 수 있는 구조를 설계합니다.