AI가 밤새 일한 결과물에 대해
잠들어 있는 사이 AI가 코드를 짜고, 아침에 눈을 뜨면 결과물이 쌓여 있습니다. Claude Code 같은 도구를 쓰면 가능한 이야기입니다. 문제는 그다음입니다. 코드가 제대로 작동하는지 확인할 방법이 없거든요.
Claude Code 워크숍을 100명 넘는 엔지니어와 진행한 Abhishek Ray가 이 문제를 다뤘습니다. AI 도입 후 주간 코드 병합이 10건에서 40~50건으로 뛰었는데, 리뷰 시간은 오히려 늘었다고 합니다. 만드는 속도는 빨라졌는데 확인하는 속도가 그대로니까요.
코드 에디터를 열기 전에 할 일
Ray가 찾은 답은 오래된 원칙에 있었습니다. 코드를 짜기 전에 '뭘 해야 하는지'부터 적는 것입니다. TDD테스트 주도 개발의 핵심이죠.
'자기 축하 기계'의 함정
AI가 코드를 짰으니, AI에게 테스트도 시키면 되지 않을까요? 합리적으로 보이지만 함정이 있습니다.
AI가 코드를 짜고 AI가 테스트를 만들면, '사용자가 원한 것'이 아니라 'AI가 해석한 사용자의 의도'를 확인하게 됩니다. 요청을 잘못 이해했더라도 테스트는 통과합니다. 오해한 방향이 같으니까요. Ray는 이걸 "자기 축하 기계"라고 불렀습니다.
사람을 더 뽑는다고 해서 해결되지도 않습니다. AI가 쏟아내는 양을 따라잡을 수 없거든요.
예전에 TDD가 안 통한 건 느려서입니다. 기능 만들기도 바쁜데 테스트부터 설계할 여유가 없었죠. 그런데 AI가 속도 문제를 해결해 버렸습니다. 이제 느린 건 '맞는지 확인하는 과정'뿐입니다.
로그인 기능을 예로 들면, "로그인 만들어 줘" 대신 이런 기준을 먼저 씁니다.
— 올바른 이메일과 비밀번호 입력 시 /dashboard로 이동한다.
— 비밀번호가 틀리면 "이메일 또는 비밀번호가 올바르지 않습니다"가 뜬다.
— 빈 칸이 있으면 제출 버튼이 비활성화된다.
— 5회 연속 실패 시 60초 차단, 대기 시간이 표시된다.
개발 지식이 없어도 쓸 수 있습니다. "사용자가 이렇게 하면 이런 결과가 나온다"는 문장이면 충분하거든요.
실패한 항목만 보면 됩니다
기준을 적었으면, 그 뒤는 네 단계입니다.
AI 기반 자동 검증 프로세스
PM 입장에서 무엇이 달라질까요? 코드 변경 내역을 줄줄이 읽는 대신, "3번 항목 불합격 — 빈 칸 제출 시 버튼이 비활성화되지 않음" 같은 리포트만 봅니다. 실패 지점이 곧 리뷰 대상입니다.
한 가지 짚을 점이 있습니다. 기준 자체가 잘못됐으면, 잘못된 기준도 통과시킵니다. 하지만 코드 로직은 맞는데 브라우저에서 깨지는 것, 기능 간 충돌처럼 코드 리뷰가 놓치기 쉬운 영역은 잘 잡아냅니다.
기준을 정하는 사람이 필요합니다
여기서 중요한 건 도구가 아닙니다. AI에게 일을 시키기 전에 '끝난 상태'를 정의하라는 원칙입니다. 시작도 안 한 기능의 예외 상황을 미리 생각하는 건 느리게 느껴집니다.
그런데 기준 없이 맡기면, 결과물을 받고 나서 처음부터 들여다봐야 합니다. 앞단을 건너뛴 만큼 뒷단에서 시간을 씁니다.
코드를 쓸 줄 몰라도 상관없습니다. "이걸 하면 이런 결과가 나와야 한다"는 문장을 쓸 수 있으면 됩니다. AI 에이전트 시대에 품질 관리란 바로 이런 문장을 쓰는 능력입니다.
