AI 코딩은 테스트부터

AI 코딩에서 가장 위험한 순간은 코드가 빨리 나오는 순간입니다. 모델이 빠르게 코드를 내놓으면 사람은 "일단 된 것 같다"고 느끼기 쉽습니다. 하지만 테스트가 없으면 그 코드는 동작하는 코드가 아니라 동작한다고 믿고 싶은 코드입니다.

이 글의 결론은 단순합니다. AI에게 구현을 맡기기 전에 실패를 먼저 재현해야 합니다. 실패 테스트가 있어야 AI가 어디까지 고쳐야 하는지 알 수 있고, 사람이 결과를 감이 아니라 증거로 판단할 수 있습니다.

핵심 결론 먼저

AI 코딩은 다음 순서로 진행합니다.

이 순서를 지키면 AI가 만든 코드를 훨씬 쉽게 통제할 수 있습니다. RED는 방향을 고정하고, GREEN은 범위를 제한하고, REFACTOR는 안전한 시점에만 구조를 바꾸게 만듭니다.

테스트 우선이 AI 코딩에 특히 중요한 이유

사람 개발자는 코드베이스의 암묵적 맥락을 기억합니다. 어떤 함수가 오래된 API와 연결되어 있는지, 어떤 예외가 실제 사용자에게 중요한지, 어떤 테스트가 flaky인지 경험으로 압니다. AI는 그 맥락을 매번 컨텍스트 안에서 추론해야 합니다.

테스트는 그 추론을 줄입니다. 좋은 테스트는 AI에게 지금 실패하는 조건, 기대 동작, 반드시 지켜야 할 계약, 변경 범위를 알려 줍니다. 테스트는 AI에게 주는 가장 구체적인 작업 지시서입니다.

전체 루프 한눈에 보기

테스트 우선 AI 코딩 루프는 여덟 단계입니다.

가장 중요한 단계는 3번입니다. 테스트가 먼저 실패하지 않으면 그 테스트는 문제를 재현하지 못한 것입니다. 그런 테스트를 통과해도 아무 의미가 없습니다.

문제를 사용자 행동으로 다시 쓴다

AI에게 "버그 고쳐줘"라고 말하면 범위가 흐립니다. 먼저 문제를 사용자 행동으로 바꿔야 합니다.

나쁜 설명:

목록이 이상해요.

좋은 설명:

VIBE 코딩 목록에서 공개 상태인 글 5개만 보여야 하는데 draft 글이 같이 노출된다. draft 글은 목록과 sitemap에서 제외되어야 한다.

이렇게 쓰면 테스트 조건이 바로 나옵니다. 입력은 공개/비공개 글 데이터이고, 기대 결과는 published 글만 반환되는 것입니다.

RED 테스트를 실제로 실패시킨다

RED 단계의 목표는 테스트를 만드는 것이 아니라 올바르게 실패하는 테스트를 만드는 것입니다.

RED 테스트 작성 후 다음을 확인합니다.

1. 현재 코드에서 실패하는가?
2. 실패 메시지가 문제 원인을 설명하는가?
3. 수정 없이 우연히 통과하지 않는가?

AI에게는 이렇게 지시합니다.

먼저 실패 재현 테스트만 작성하세요. 구현 코드는 아직 바꾸지 마세요. 테스트가 현재 코드에서 실패하는 로그를 보여 주세요.

이 단계에서 AI가 구현까지 같이 바꾸면 되돌립니다. RED와 GREEN이 섞이면 테스트가 문제를 잡은 것인지, 구현이 우연히 맞은 것인지 알 수 없습니다.

GREEN에서는 최소 수정만 한다

GREEN은 창의력을 발휘하는 단계가 아닙니다. 테스트를 통과시키는 최소 수정만 합니다. 이때 금지해야 할 작업은 분명합니다.

• 관련 없는 파일 수정 금지
• 리팩터링 금지
• 테스트 기대값 변경 금지
• public API 변경 금지
• 임의의 예외 처리 추가 금지

AI가 만든 GREEN diff가 크면 다시 지시합니다. "테스트를 통과시키는 가장 작은 변경으로 줄여라"고 말해야 합니다. GREEN 단계에서 구조 개선까지 하면 실패 원인이 흐려집니다.

REFACTOR는 통과 이후에만 한다

테스트가 통과한 뒤에만 구조를 정리합니다. 중복 제거, 함수 추출, 이름 정리, 타입 명확화는 모두 이 단계입니다. 리팩터링은 보상 단계가 아니라 검증 이후 단계입니다.

리팩터링 후 테스트가 실패하면 즉시 REFACTOR diff만 되돌립니다. GREEN diff까지 같이 되돌릴 필요가 없도록 커밋이나 작업 단위를 분리하는 것이 좋습니다.

테스트 종류를 어떻게 고를까

모든 문제에 E2E 테스트를 붙일 필요는 없습니다. 문제의 성격에 맞는 가장 작은 테스트를 고르면 됩니다.

AI에게 테스트 종류를 고르게 할 수도 있지만, 최종 선택은 사람이 해야 합니다. 너무 큰 테스트는 느리고, 너무 작은 테스트는 실제 문제를 놓칩니다.

상황별 예시

목록에 draft 글이 노출되는 경우

먼저 published와 draft가 섞인 fixture를 만듭니다. 목록 함수가 published만 반환하는지 RED 테스트를 작성합니다. 그 다음 필터 조건을 최소 수정하고, 목록 페이지 smoke로 실제 카드 노출을 확인합니다.

API 응답 필드가 빠지는 경우

API route에 대한 contract test를 작성합니다. status, JSON key, nullable 여부를 명시합니다. GREEN 단계에서는 serializer나 select 필드만 수정하고, 응답 구조 전체를 바꾸지 않습니다.

Markdown 이미지 캡션이 깨지는 경우

대표 markdown 샘플을 만들고 이미지 설명 접두어 다음 문장이 figcaption으로 렌더링되는지 테스트합니다. 이 문제는 UI 스타일이 아니라 parser/renderer 계약이므로, CSS부터 건드리면 안 됩니다.

AI에게 줄 프롬프트 템플릿

먼저 실패 재현 테스트를 작성하세요. 구현 코드는 바꾸지 마세요. 테스트가 현재 코드에서 실패하는 로그를 보여 주세요. 그 다음 테스트를 통과시키는 최소 수정만 하세요. 리팩터링은 GREEN 통과 이후 별도 단계로 진행하세요. 완료 보고에는 실행한 테스트, 통과/실패 결과, 변경 파일, 남은 위험을 포함하세요.

이 프롬프트는 AI가 바로 구현으로 뛰어드는 것을 막고, 결과를 증거 중심으로 바꿉니다.

검증 체크리스트

완료 전에는 다음을 확인합니다.

• RED 테스트가 현재 코드에서 실제로 실패했는가?
• GREEN diff가 최소 수정인가?
• 테스트 기대값을 바꾸지 않았는가?
• targeted test가 통과했는가?
• 필요한 경우 live smoke까지 확인했는가?
• 변경 파일과 남은 위험을 보고했는가?

마무리

AI 코딩의 장점은 속도입니다. 하지만 속도는 테스트가 있을 때만 품질로 바뀝니다. 테스트가 없으면 AI는 빠르게 틀릴 수 있고, 사람은 그럴듯한 diff를 리뷰하느라 시간을 잃습니다.

테스트가 먼저, 구현은 그 다음, 리팩터링은 마지막입니다. 이 순서만 지켜도 AI 코딩은 훨씬 안정적인 운영 루프가 됩니다.