AI 코딩을 시작하면 가장 먼저 체감하는 장점은 속도입니다. 자연어로 요청하면 컴포넌트, API, 테스트 코드, 문서 초안이 빠르게 나옵니다. 그런데 실무에서 진짜 문제가 되는 것은 속도가 아니라 확신입니다. 코드가 빨리 생겼는데 왜 맞는지 설명할 수 없고, 어떤 실패를 막았는지 기록이 없고, 수정 범위가 생각보다 넓어졌다면 그 결과물은 빠른 것이 아니라 위험한 것입니다.

이 글의 주제는 간단합니다. AI에게 바로 구현을 시키지 말고, 먼저 실패를 재현하는 테스트를 만들게 하라는 것입니다. 초보자에게는 테스트가 귀찮은 절차처럼 보일 수 있지만, AI 코딩에서는 테스트가 대화의 안전벨트입니다. 실무자에게는 더 직접적인 효과가 있습니다. 테스트가 먼저 있으면 에이전트가 추측으로 코드를 넓히는 것을 막고, 리뷰어는 결과가 아니라 근거를 볼 수 있습니다.

핵심 결론

AI 코딩의 기본 단위는 "요청 한 줄"이 아니라 "실패를 증명하고 통과시키는 루프"여야 합니다. 좋은 루프는 세 단계입니다.

1. RED: 지금 빠져 있는 동작을 테스트로 먼저 표현하고 실제로 실패하는지 확인합니다.
2. GREEN: 테스트를 통과시키는 가장 작은 수정만 합니다.
3. REFACTOR: 테스트가 계속 통과하는 상태에서 이름, 구조, 중복만 정리합니다.

이 순서를 지키면 AI가 만든 코드도 사람이 검토할 수 있는 작업 단위로 바뀝니다. "괜찮아 보인다"가 아니라 "이 실패를 막는 테스트가 있고, 그 테스트가 실제로 실패했다가 통과했다"라고 말할 수 있기 때문입니다.

핵심 포인트: 에이전트에게 코드를 먼저 쓰게 하면 결과를 믿어야 합니다. 테스트를 먼저 쓰게 하면 결과를 검증할 수 있습니다.

왜 중요한가

AI는 그럴듯한 완성본을 너무 빨리 만든다

AI 코딩 에이전트는 빈 파일을 채우거나 기존 파일을 고치는 데 능숙합니다. 문제는 그 능숙함 때문에 중간 사고 과정이 생략되기 쉽다는 점입니다. 사용자는 "로그인 버튼이 안 눌린다"고 말했는데 에이전트는 상태 관리, 스타일, 라우팅, 데이터 호출까지 한 번에 만질 수 있습니다. 겉보기로는 열심히 일한 것 같지만, 실제 실패 원인이 버튼 이벤트인지, 비활성 조건인지, 권한 체크인지, 네트워크 응답인지 흐려집니다.

테스트 우선 루프는 이 흐림을 줄입니다. 먼저 실패 원인을 관찰 가능한 문장으로 고정합니다. 예를 들어 "비로그인 사용자는 결제 버튼을 누르면 로그인 안내를 본다"처럼 사용자가 기대하는 결과를 테스트로 적습니다. 이 테스트가 실패하면 현재 시스템이 그 기대를 만족하지 못한다는 증거가 됩니다. 그다음 수정은 이 증거를 통과시키는 데 집중합니다.

리뷰 기준이 코드 취향에서 행동 증거로 바뀐다

AI가 만든 코드를 리뷰할 때 "이 구현이 마음에 드는가"만 보면 논쟁이 길어집니다. 반대로 테스트가 먼저 있으면 질문이 달라집니다.

초보자에게도 이 방식은 도움이 됩니다. 코드를 완벽히 이해하지 못하더라도 테스트 이름과 실패 메시지를 읽으면 "무엇이 안 됐고 무엇을 기대했는지"를 따라갈 수 있습니다. 실무자에게는 작업 인수인계와 장애 재발 방지에 더 큰 장점이 있습니다.

실제 작업 순서

1단계: 문제를 사용자 행동으로 다시 쓴다

에이전트에게 바로 "고쳐줘"라고 하지 말고 먼저 문제를 관찰 가능한 행동으로 바꾸게 합니다. 좋은 문장은 입력, 행동, 결과가 들어 있습니다.

나쁜 요청:

``text 검색이 이상해. 고쳐줘. ``

좋은 요청:

``text 검색어가 비어 있을 때는 결과 API를 호출하지 않고 안내 문구를 보여야 한다. 먼저 이 동작을 실패하는 테스트로 작성하고, 테스트가 왜 실패하는지 설명한 뒤 최소 수정만 해줘. ``

이렇게 쓰면 에이전트는 구현보다 검증 조건을 먼저 생각하게 됩니다. "검색이 이상하다"는 너무 넓지만, "빈 검색어에서는 API를 호출하지 않는다"는 테스트 가능한 요구입니다.

2단계: RED를 실제로 확인한다

테스트 파일을 만들었다는 것만으로는 부족합니다. 반드시 실행해서 실패를 봐야 합니다. 실패하지 않는 테스트는 이미 있는 동작을 확인했거나, 테스트가 잘못 작성됐거나, 아예 실행되지 않았을 수 있습니다.

예시 명령은 프로젝트에 맞게 달라질 수 있지만 흐름은 같습니다.

``bash npm test -- 검색-빈-입력 ``

실패 메시지에서 확인할 것은 세 가지입니다.

1. 테스트가 문법 오류가 아니라 기대 동작 불일치로 실패했는가.
2. 실패 메시지가 문제 상황을 설명하는가.
3. 실패 원인이 이번 작업 범위 안에 있는가.

여기서 테스트가 통과하면 멈춰야 합니다. "통과했으니 좋은 것 아닌가"가 아닙니다. 통과했다면 새 테스트가 문제를 잡지 못했다는 뜻일 수 있습니다. 테스트 조건을 더 구체화하거나 실제 버그 재현 데이터를 추가해야 합니다.

3단계: GREEN에서는 작게 고친다

GREEN 단계의 목표는 멋진 구조가 아니라 통과입니다. AI에게 "관련 리팩터링도 같이 해줘"라고 요청하면 작업 범위가 바로 커집니다. 이 단계에서는 다음처럼 제한을 걸어야 합니다.

``text 방금 실패한 테스트 하나를 통과시키는 최소 수정만 해줘. 새 기능, 파일 이동, 스타일 정리, 성능 최적화는 하지 마. 수정 후 같은 테스트를 다시 실행하고 결과를 보여줘. ``

최소 수정은 품질이 낮다는 뜻이 아닙니다. 원인을 좁히기 위한 전략입니다. 작은 수정으로 테스트가 통과하면 문제 원인을 더 확신할 수 있습니다. 큰 수정으로 통과하면 어떤 변경이 효과를 냈는지 알기 어렵습니다.

4단계: REFACTOR는 통과 이후에만 한다

테스트가 통과한 뒤에야 구조를 정리합니다. 이름을 바꾸고, 중복을 줄이고, 헬퍼를 분리하고, 문서를 보강합니다. 이때도 규칙은 명확합니다. 리팩터링은 행동을 바꾸지 않습니다. 행동을 바꾸고 싶다면 다시 RED부터 시작합니다.

리팩터링 요청 예시는 다음과 같습니다.

``text 테스트가 통과한 상태를 유지하면서 중복된 조건문만 정리해줘. 공개 API와 사용자 동작은 바꾸지 말고, 수정 후 같은 테스트와 전체 테스트를 실행해줘. ``

마지막에는 최소한 다음 검증을 통과시킵니다.

``bash npm run lint npm run build npm test ``

작업 성격에 따라 특정 페이지 스모크, 접근성 검사, API 응답 확인을 추가할 수 있습니다. 중요한 것은 "에이전트가 알아서 했겠지"가 아니라 검증 결과를 작업의 일부로 남기는 것입니다.

상황별 예시

예시 1: UI 조건이 자주 깨지는 버튼

문제: 결제 버튼이 로그인 상태와 구독 상태에 따라 다르게 보여야 하는데, 수정할 때마다 한 조건이 깨집니다.

테스트 우선 요청:

``text 결제 CTA 조건을 테스트로 고정하자. 비로그인 사용자는 "로그인 후 이용", 무료 사용자는 "구독 시작", 유료 사용자는 "대시보드로 이동"을 봐야 한다. 먼저 세 케이스가 실패하는 테스트를 작성하고 실행 결과를 확인한 다음 최소 수정해줘. ``

여기서 좋은 테스트는 내부 변수 이름보다 사용자에게 보이는 문구와 클릭 결과를 확인합니다. UI 구현은 바뀔 수 있지만 사용자 경험은 유지되어야 하기 때문입니다.

예시 2: API 에러 처리가 누락된 폼

문제: 저장 API가 실패하면 사용자는 아무 메시지도 보지 못하고 버튼만 멈춘 것처럼 보입니다.

테스트 우선 요청:

``text 저장 API가 실패했을 때 폼이 에러 메시지를 보여주고 재시도 가능 상태로 돌아오는지 테스트해줘. 네트워크 실패를 재현하는 테스트를 먼저 만들고, 실패 원인을 설명한 뒤 최소 수정해줘. ``

이 경우에는 성공 케이스보다 실패 케이스가 중요합니다. AI는 정상 흐름을 잘 채우지만 장애 흐름을 빼먹는 경우가 많습니다. 테스트가 실패 흐름을 고정하면 배포 후 사용자가 빈 화면을 만나는 위험을 줄일 수 있습니다.

예시 3: 리팩터링 중 데이터 정렬이 바뀌는 문제

문제: 목록 페이지를 정리하다가 최신순 정렬이 깨졌습니다.

테스트 우선 요청:

``text 목록은 publishedAt 기준 최신순이어야 한다. 서로 다른 날짜의 샘플 3개를 넣고 정렬 결과를 검증하는 테스트를 먼저 추가해줘. 그 테스트가 현재 실패하는 것을 확인한 뒤 정렬 로직만 최소 수정해줘. ``

정렬, 필터, 권한, 공개/비공개 상태처럼 규칙이 있는 코드는 테스트 우선 효과가 큽니다. 사람이 눈으로 한두 번 확인하기 쉽지만, 다음 리팩터링에서 다시 깨지기도 쉽기 때문입니다.

실수와 주의점

테스트를 만들었지만 실패를 보지 않는다

가장 흔한 실수입니다. 에이전트가 "테스트를 추가했습니다"라고 말하면 끝난 것처럼 느껴집니다. 하지만 RED를 확인하지 않은 테스트는 안전장치가 아닙니다. 반드시 실패 로그를 확인해야 합니다. 실패 로그가 없으면 작업 보고에 "RED 확인"이라고 쓰면 안 됩니다.

테스트가 구현 세부사항에 묶인다

초보자는 특정 함수가 몇 번 호출됐는지, 내부 상태 이름이 무엇인지 같은 세부사항을 테스트하기 쉽습니다. 하지만 좋은 테스트는 가능하면 사용자 결과나 외부 관찰 결과를 봅니다. 버튼 문구, 페이지 이동, API 응답, 저장된 데이터, 정렬 순서처럼 구현을 바꿔도 유지되어야 하는 것을 검증해야 합니다.

GREEN에서 기능을 한꺼번에 늘린다

AI에게 "하는 김에"를 붙이면 범위가 커집니다. GREEN 단계에서는 하나의 실패를 하나의 수정으로 통과시키는 것이 좋습니다. 추가 개선 아이디어는 다음 단계 목록에 남기고, 새 행동이 필요하면 새 RED 테스트를 만듭니다.

실패 원인을 설명하지 못한 채 통과시킨다

테스트가 통과해도 왜 통과했는지 모르면 위험합니다. 에이전트에게 수정 요약만 받지 말고 실패 원인과 수정 포인트를 짧게 설명하게 하세요. 단, 설명은 코드보다 우선하지 않습니다. 설명이 그럴듯해도 테스트와 빌드가 실패하면 아직 끝난 것이 아닙니다.

롤백 기준이 없다

AI 코딩에서는 변경량이 커질 수 있으므로 롤백 기준도 필요합니다. 테스트를 통과시키려다가 관련 없는 파일이 많이 바뀌거나, 기존 동작을 설명 없이 바꾸거나, 빌드 실패가 길어지면 되돌리고 더 작은 테스트부터 시작하는 편이 낫습니다. 좋은 운영자는 많이 고치는 사람이 아니라 안전하게 되돌릴 수 있는 사람입니다.

검증 체크리스트

작업이 끝났다고 보고하기 전에 아래 항목을 확인합니다.

• 문제를 사용자 행동 또는 데이터 규칙으로 다시 썼는가.
• RED 테스트를 먼저 작성했고 실제 실패를 확인했는가.
• 실패가 문법 오류가 아니라 기대 동작 불일치였는가.
• GREEN 수정은 해당 실패를 통과시키는 최소 범위였는가.
• REFACTOR는 테스트 통과 이후에만 했는가.
• 새 테스트와 관련 테스트가 통과했는가.
• npm run lint, npm run build, npm test가 통과했는가.
• 공개 화면이나 API 동작이 바뀌었다면 실제 페이지 또는 응답을 확인했는가.
• 작업 보고에 실패 원인, 수정 범위, 검증 결과, 남은 리스크가 포함됐는가.

이 체크리스트는 형식적인 문서가 아닙니다. AI가 빠르게 만든 결과를 팀이 신뢰할 수 있는 결과로 바꾸는 최소 운영 기준입니다. 특히 초보자는 이 순서를 따라가기만 해도 "AI가 만들어준 코드"를 무작정 붙여 넣는 습관에서 벗어날 수 있습니다.

다음 단계

첫 번째 목표는 모든 작업을 거대한 TDD 프로젝트로 바꾸는 것이 아닙니다. 오늘부터 자주 깨지는 한 영역에만 적용해도 충분합니다. 추천 순서는 다음과 같습니다.

1. 최근에 실제로 깨졌던 버그 하나를 고릅니다.
2. 그 버그를 한 문장으로 재현합니다.
3. 에이전트에게 실패 테스트를 먼저 만들게 합니다.
4. RED 로그를 확인합니다.
5. 최소 수정으로 GREEN을 만듭니다.
6. 필요한 정리만 REFACTOR합니다.
7. 검증 명령과 남은 리스크를 작업 기록에 남깁니다.

이 루프가 익숙해지면 AI 코딩의 느낌이 달라집니다. 더 많은 코드를 더 빨리 받는 것이 목표가 아니라, 더 작은 증거를 더 자주 쌓는 방식으로 바뀝니다. 그때부터 바이브코딩은 감에 맡기는 코딩이 아니라, 사람의 의도와 기계의 실행력을 검증 가능한 루프로 묶는 실무 기술이 됩니다.