왜 AI에게는 테스트가 지시서가 되나

사람 개발자는 암묵적 맥락을 기억합니다. AI는 그 맥락을 매번 컨텍스트 안에서 추론해야 합니다. 좋은 테스트는 지금 실패하는 조건, 기대 동작, 지켜야 할 계약, 변경 범위를 알려 줍니다. 테스트는 AI에게 주는 가장 구체적인 작업 지시서입니다.

버그 설명을 사용자 행동으로 바꾼다

「목록이 이상해요」는 범위가 흐립니다. 「공개 글 5개만 보여야 하는데 draft가 같이 노출된다. draft는 목록과 sitemap에서 빠져야 한다」처럼 재현 문장으로 바꿉니다.

RED가 실제로 실패하는지 확인한다

테스트를 작성만 하고 실행하지 않으면 의미가 없습니다. 반드시 한 번 실패 로그를 봅니다. 처음부터 통과하는 테스트는 문제를 재현하지 못한 것입니다.

⚠️ 주의: AI가 「테스트도 같이 고쳐서 통과」시키려 하면 RED가 무너집니다. 실패 로그를 남긴 뒤에만 구현을 허용하세요.

GREEN에서는 최소만 고친다

통과에 필요한 가장 작은 diff만 허용합니다. 「관련 파일도 정리」는 이 단계가 아닙니다. 테스트가 통과한 뒤에야 구조를 건드립니다.

REFACTOR는 초록불 이후에만

중복 제거와 이름 정리, 범위 축소는 통과 이후에만 합니다. 리팩터 중 테스트가 깨지면 그 커밋은 롤백 후보입니다.

AI에게 줄 때 자주 깨지는 프롬프트

나쁜 예: 버그 고쳐줘. 좋은 예: 아래 테스트를 먼저 실패시킨 뒤, 그 테스트만 통과하는 최소 수정을 하고, 리팩터는 통과 후에만 해. 테스트 파일을 통과시키기 위해 기대값을 바꾸지 마.

💡 Tip: 프롬프트에 「기대값을 바꿔 통과시키지 말 것」을 명시하세요. AI가 테스트를 약화하는 경우가 있습니다.

공개 전에 남길 증거

실행한 명령, 실패/통과 로그, 변경 파일, 남은 위험을 짧게 남깁니다. 「된 것 같다」로 끝내지 않습니다.

어떤 테스트를 고를지

증상이 UI에만 보이면 컴포넌트 테스트나 통합 테스트가 재현에 유리합니다. API 계약이 깨졌다면 핸들러 단위 테스트가 빠릅니다. 결제나 배포처럼 공개 경로가 위험하면 마지막에 smoke E2E를 한 번 둡니다. 처음부터 E2E만 고르면 피드백이 느려 AI가 추측으로 넓게 고치기 쉽습니다.

확인: 지금 고칠 증상을 가장 싸게 실패시키는 계층을 골랐는지 한 줄로 말할 수 있어야 합니다.

실제로 돌려 본 짧은 시나리오

공개 목록에 draft가 섞여 보이던 경우, 먼저 「draft는 목록에 없어야 한다」는 테스트를 작성해 실패 로그를 받았습니다. AI에게는 그 로그만 주고 최소 필터 수정을 요청했습니다. 통과 후 sitemap 제외는 별도 RED로 나눴습니다. 한 번에 「목록이랑 사이트맵이랑 robots까지」를 맡기면 diff가 커지고 롤백이 어려워집니다.

플래키한 시간 의존 테스트는 GREEN 판정에 쓰지 않습니다. 시계를 고정하거나 네트워크를 스텁한 뒤에야 신뢰합니다.

팀에서 합의할 한 줄 규칙

「구현 전에 실패 로그를 붙인다」를 PR 템플릿에 넣으면 습관이 유지됩니다. 실패 로그가 없는 AI 코딩 PR은 리뷰를 시작하지 않습니다. 이 규칙만으로도 「된 것 같다」로 머지되는 사고가 줄어듭니다.

출처와 링크

• Testing Library guiding principles
• Jest Getting Started
• Kent C. Dodds Write tests
• GitHub Actions 워크플로 문법

조사 기준: 2026년 7월. 프레임워크별 러너는 프로젝트에 맞게 고르고, 순서(RED-GREEN-REFACTOR)만 고정합니다.