"테스트 연극"의 등장

AI 코딩 어시스턴트는 높은 커버리지를 가진 테스트를 생성하는 데 뛰어나다. 하지만 여기에는 종종 치명적인 문제가 하나 있다. 코드가 의도한 대로가 아니라 작성된 그대로 동작한다는 것을 테스트하고 있다는 점이다. 이러한 '테스트 연극(Test Theater)'은 버그에 대한 실질적인 보호는 거의 없으면서 품질에 대한 위험한 환상을 만들어낸다.

"테스트 연극"의 등장: 아무 의미 없는 테스트를 AI가 작성할 때

AI 코딩 어시스턴트를 성급히 도입하면서 우리는 위험한 환상, 즉 테스트 연극(Test Theater)에 빠지게 되었다. 이는 의도가 아닌 구현을 검증하는 멋져 보이는 테스트 스위트를 생성하는 관행이다. 이 용어는 보안 연극(Security Theater)에서 영감을 받았다. 보안이 아닌 테스트 영역에서 유사한 현상이 일어나기 때문이다.

AI가 생성한 테스트의 거짓된 약속

이것은 매우 유혹적인 워크플로다. 코드를 작성한 다음 클로드, 코파일럿 또는 다른 AI 어시스턴트에게 "이 함수에 대한 테스트를 작성해"라고 요청한다. 몇 초 안에 높은 커버리지, 경계 조건, 그리고 깔끔하게 정리된 테스트 블록을 갖춘 멋진 테스트 스위트를 얻을 수 있다. CI 파이프라인은 녹색 물결을 보여준다. 커버리지 리포트는 90% 이상을 기록한다. 경영진은 기뻐한다.

하지만 여기에는 치명적인 문제가 있다. 이 테스트들은 근본적으로 순환 논리에 빠져 있다.

순환성 문제

매우 명확하고 주의하지 않는 한, 현재 AI 코딩 어시스턴트는 구현을 살펴보고 코드가 이미 하고 있는 일을 확인하는 테스트를 작성한다. 이들은 본질적으로 다음과 같이 말한다. "이 함수는 Y가 주어지면 X를 반환한다. 그러므로 Y가 주어질 때 X를 반환하는지 확인하는 테스트를 작성하겠다." 이는 정답을 본 후 자신의 시험 문제를 직접 출제하는 학생과 같다. 이는 동어반복이다. 정의에 따라 참이지만, 가치 있는 것을 검증하지는 않는다.

진정한 테스트는 코드가 요구 사항을 충족하고 설계를 올바르게 구현하는지 확인해야 한다. (잠재적으로 잘못될 수 있는) 동일한 동작을 일관되게 생성한다는 것을 확인하는 것이 아니다.

좋은 테스트가 실제로 작동하는 방식

좋은 테스트는 구현 우선이 아닌 명세 우선이다. 좋은 테스트는 다음을 수행해야 한다.

1. 요구 사항 검증: 테스트는 코드가 내부적으로 일관성이 있는지가 아니라 명세에 따라 동작하는지 확인해야 한다.
2. 회귀 방지: 테스트는 동작이 다른 구성 요소와의 계약을 위반하는 방식으로 변경될 때 실패해야 한다.
3. 의도 문서화: 테스트는 코드가 해야 할 일에 대한 실행 가능한 문서 역할을 해야 한다.
4. 가정 검증: 테스트는 구현이 올바르게 처리하지 못할 수 있는 경계 조건과 예상치 못한 입력을 확인해야 한다.

이것이 테스트 주도 개발(TDD)에서 테스트를 코드보다 먼저 작성하라고 권장하는 이유다. 테스트가 요구 사항이 되고, 코드가 그 요구 사항을 충족하도록 작성된다. 그 반대가 아니다.

AI가 의미 있는 테스트를 작성하는 데 어려움을 겪는 이유

문제의 본질은 테스트를 작성하는 데 AI 어시스턴트를 사후에 사용하는 데 있다. 현재 AI 어시스턴트는 명시적으로 컨텍스트를 제공하지 않는 한 요구 사항, 시스템 아키텍처 또는 비즈니스 도메인을 이해하지 못한다. "테스트를 작성해"라고 요청하면 일반적으로 구현 자체에서 기대치를 추론한다. AI는 다음을 알지 못한다.

• 코드가 무엇을 해야 하는지 (현재 무엇을 하는지만 앎)
• 다른 구성 요소와 어떤 계약이 존재하는지
• 어떤 비즈니스 규칙을 준수해야 하는지
• 도메인에 어떤 경계 조건이 중요한지

테스트 연극에서 벗어나는 방법

그렇다면 테스트를 위해 AI 어시스턴트를 책임감 있게 사용하려면 어떻게 해야 할까?

1. 요구 사항부터 시작: 테스트를 요청하기 전에 AI에게 명확한 명세를 제공하라. "이 함수는 RFC 5322에 따라 이메일 주소를 검증하고, null 입력을 거부하며, 주소를 254자로 제한해야 한다."
2. 핵심 테스트는 직접 작성: 핵심 비즈니스 로직에는 TDD 원칙을 적용하라. 테스트를 먼저 작성한 다음 구현하라.
3. AI를 활용해 테스트 커버리지 확장: 핵심 테스트가 준비되면 AI를 사용해 추가적인 경계 조건을 식별하거나 변형을 생성할 수 있다.
4. AI가 생성한 테스트를 비판적으로 검토: 스스로에게 물어보라. "이 테스트는 요구 사항을 검증하는가, 아니면 구현을 반영하는가?" 내 경험상 작성된 테스트의 50% 이상이 단순히 구현을 반영하고 있다.
5. 속성 기반 테스트 고려: fast-check(자바스크립트)나 QuickCheck 같은 도구는 수천 개의 테스트 케이스를 생성하여 구현이 놓칠 수 있는 경계 조건을 찾을 수 있다.

테스트 연극의 실제 비용

테스트 연극은 단지 비효율적인 것이 아니다. 실제로 해롭다.

1. 거짓된 자신감: 팀은 코드가 잘 테스트되었다고 믿지만 실제로는 그렇지 않다.
2. 리팩토링 마비: 테스트가 현재 구현 세부 사항에 결합되어 있고 수백 개가 있기 때문에 구현을 변경하기가 어려워진다.
3. 유지 보수 부담: 최소한의 가치만 제공하는 거대한 테스트 스위트를 유지 보수해야 한다. 물론 AI를 사용해 구현 테스트를 업데이트할 수 있지만, 이제 연극 공연을 유지하기 위해 토큰을 낭비하는 셈이다.
4. 놓친 버그: 테스트는 코드가 이미 하는 일만 검증하기 때문에 중요한 문제가 빠져나간다.

결론

AI 코딩 어시스턴트는 강력한 도구이지만 마법은 아니다. 명시적인 지침 없이는 요구 사항이나 비즈니스 도메인을 이해할 수 없다. 테스트와 관련하여 이러한 도구는 요구 사항과 시스템 계약에 기반한 사려 깊은 테스트 설계를 대체하는 것이 아니라 보완해야 한다.

다음번에 AI에게 "이 코드에 대한 테스트를 작성해"라고 요청하고 싶을 때 기억하라. 코드가 이미 하는 일을 확인하는 테스트는 테스트가 아니다. 그것은 그저 연극일 뿐이다.