잠자는 동안 코드를 작성하는 AI 에이전트, 어떻게 신뢰할 수 있을까? - 수용 기준(Acceptance Criteria) 기반 자동 검증 파이프라인 정리

AI 코드 에이전트가 개발자가 자는 동안 코드를 작성하고 브랜치에 반영하는 시대가 됐습니다.
하지만 **“이 코드, 정말 믿어도 될까?”**라는 질문은 여전히 남아 있습니다.

이 글에서는

• 자율 AI 에이전트가 만든 코드를 왜 신뢰하기 어려운지
• 기존 코드 리뷰와 AI 테스트 방식의 근본적인 한계는 무엇인지
• 그 해법으로 제시된 TDD(테스트 주도 개발)의 핵심 원칙 + 수용 기준(Acceptance Criteria) 접근법
• 그리고 Claude Code와 Playwright를 활용한 4단계 자동 검증 파이프라인이 실제로 어떻게 동작하는지

를 하나씩 정리합니다.
목표는 단순합니다. AI가 만든 결과물을 “읽고 믿는 것”이 아니라, “검증하고 신뢰하는 방법”을 이해하는 것입니다.

반응형

---

자율 AI 코드 에이전트의 등장과 새로운 문제

최근 AI 코드 에이전트는 다음과 같은 일을 자연스럽게 수행합니다.

• 수 시간 동안 코드 작성
• 자동으로 브랜치 생성 및 변경 사항 반영
• PR 생성까지 완료

겉으로 보면 생산성은 폭발적으로 증가합니다.
실제로 AI를 일상적인 PR에 사용하는 팀에서는 주당 PR 병합 수가 10개 → 40~50개로 증가했습니다.

문제는 여기서 시작됩니다.

• 리뷰해야 할 코드가 너무 많아짐
• 모든 diff를 사람이 읽는 것이 불가능해짐
• 결국 “배포하고 문제 없기를 바라는” 구조로 변질

즉, 속도는 빨라졌지만 신뢰성은 오히려 낮아진 상황이 됩니다.

---

왜 기존 AI 코드 검증 방식은 실패하는가

1. AI가 작성한 코드를 AI가 테스트하는 구조

AI가 만든 코드를 같은 AI가 테스트하면 어떤 일이 벌어질까요?

• 테스트는 통과
• 회귀 버그는 일부 잡힘
• 하지만 처음부터 잘못 이해한 요구사항(misunderstanding) 은 절대 잡히지 않음

이 상태를 저자는 “자기 축하 기계(Self-congratulation machine)” 라고 표현합니다.
같은 출처의 사고방식으로 작성과 검증을 동시에 하니, 놓치는 지점도 동일합니다.

---

2. 코드 리뷰 인력 확충은 해답이 아님

• 리뷰어를 더 뽑아도 AI 속도를 따라갈 수 없음
• 시니어 엔지니어가 하루 종일 AI 코드만 읽는 것은 비효율
• 코드 리뷰의 본질은 “두 번째 시선”인데, AI 간 교차 검토는 진짜 두 번째 시선이 아님

결국 사람도, AI도 기존 방식으로는 한계에 부딪힙니다.

---

TDD가 정확히 짚었던 핵심

여기서 다시 주목받는 것이 TDD(Test-Driven Development) 의 원칙입니다.

TDD의 핵심은 단순합니다.

1. 테스트(기준)를 먼저 작성
2. 그 기준을 만족하는 코드만 구현
3. 테스트가 통과하면 멈춘다 (더 만들지 않음)

많은 팀이 TDD를 하지 않았던 이유는 하나였습니다.
 “코드를 쓰기도 전에 무엇을 해야 하는지 생각하는 데 시간이 너무 걸린다”

하지만 AI가 등장하면서 상황이 바뀝니다.

• 코드를 작성하는 속도는 AI가 해결
• 이제 가장 느린 부분은 “이 코드가 맞는지 판단하는 것”

---

단위 테스트 대신 ‘수용 기준(Acceptance Criteria)’

여기서 제안되는 접근은 테스트 코드보다 쉬운 방식입니다.

핵심 아이디어

• 기능이 무엇을 해야 하는지를
• 코드가 아닌 평문(자연어) 수용 기준으로 먼저 정의

예시 (로그인 기능)

• 사용자는 이메일과 비밀번호로 로그인한다
• 잘못된 자격 증명 시 "Invalid email or password" 메시지 표시
• 성공 시 /dashboard로 이동
• 세션 토큰은 24시간 후 만료

이 문서는 코드 에디터를 열기 전에 작성 가능합니다.
그리고 AI 에이전트는 이 기준을 만족하도록 구현만 하면 됩니다.

---

실제 적용 사례: 프론트엔드

수용 기준 예시

• AC-1: 유효한 자격 증명 → /dashboard 리다이렉트 + 세션 쿠키 설정
• AC-2: 잘못된 비밀번호 → 정확히 "Invalid email or password" 표시, /login 유지
• AC-3: 필드가 비어 있으면 제출 버튼 비활성화 또는 인라인 에러 표시
• AC-4: 5회 실패 시 60초 로그인 차단 + 대기 메시지 표시

모든 기준은 pass / fail로 명확히 판별 가능합니다.

검증 방식

• 브라우저 에이전트가 각 AC를 실제 브라우저에서 실행
• 스크린샷과 함께 기준별 결과 리포트 생성
• 실패 시 “어떤 기준이, 어떤 화면에서 실패했는지” 바로 확인 가능

---

백엔드에도 동일한 패턴 적용

브라우저가 없어도 방식은 같습니다.

• 관찰 가능한 API 동작 정의
  • 상태 코드
  • 응답 헤더
  • 에러 메시지
• curl 명령어로 수용 기준 검증

즉, “외부에서 관찰 가능한 행동”만 기준으로 삼는 것이 핵심입니다.

---

4단계 자동 검증 파이프라인 구조

이 접근은 별도 백엔드 없이 다음 구조로 구현됩니다.

1단계: Pre-flight

• 순수 bash
• LLM 호출 없음
• 개발 서버 실행 여부, 인증 세션, 스펙 파일 존재 여부 확인
• 토큰 소모 전에 빠르게 실패 처리

2단계: Planner

• 한 번의 LLM 호출
• 스펙과 변경 파일을 읽고 검증 전략 수립
• 실제 코드를 읽어 정확한 셀렉터 사용 (추측 없음)

3단계: Browser Agents

• 수용 기준(AC)당 하나의 에이전트
• 병렬 실행
• 실제 사용자처럼 네비게이션 + 스크린샷 수집

4단계: Judge

• 모든 증거를 종합해 최종 판정
• 결과: pass, fail, needs-human-review

---

도구 구성과 설치 방식

• Claude Code headless 모드(claude -p)
• Playwright MCP
• GitHub 기반 Claude Skill로 제공

별도 API 키나 커스텀 백엔드 없이
Anthropic Claude OAuth 토큰만으로 동작합니다.

플러그인 방식 또는 저장소 클론 후 커스터마이징도 가능하며,
CI 연동도 지원합니다.

---

이 방식의 한계도 명확하다

• 스펙 자체가 잘못되면 검증을 통과해도 결과는 틀릴 수 있음
• “절대적 정확성”을 보장하지는 않음

하지만 다음은 확실히 잡아냅니다.

• 통합 실패
• 실제 브라우저에서만 발생하는 렌더링 버그
• 사람이 코드 리뷰로 놓치기 쉬운 사용자 관점 오류

---

워크플로우 요약

1. 프롬프트 전에 수용 기준 작성
2. 에이전트가 기준에 맞춰 구현
3. 자동 검증 실행
4. diff가 아니라 실패한 기준만 리뷰

---

728x90

이 사례가 던지는 메시지는 명확합니다.

“완료의 정의를 사전에 명시하지 않으면, 결과를 신뢰할 수 없다.”

• 수용 기준 작성은 프롬프트보다 어렵습니다
• 하지만 이 과정이 엣지 케이스를 드러내고 품질을 끌어올립니다
• AI 주도 개발 환경에서 신뢰성을 확보하는 필수 절차입니다

AI가 코드를 대신 써주는 시대에는,
무엇을 만들어야 하는지 정의하는 능력이 개발자의 핵심 역량이 됩니다.

속도는 이미 해결됐습니다.
이제 남은 과제는 신뢰입니다.

300x250

https://www.claudecodecamp.com/p/i-m-building-agents-that-run-while-i-sleep

I'm Building Agents That Run While I Sleep