🤖 잠자는 동안 실행되는 AI 에이전트: 자동화 파이프라인

출처: [Claude Code Camp] (19P by GN+)

📌 핵심 요약 (TL;DR)

  • CLAUDE 코드로 작성된 코드는 개발자가 잠자는 동안에도 생성되고 브랜치에 반영되나, 검증의 어려움 존재.
  • 자기 축하 기계(self-congratulation machine): 같은 AI 로 작성과 테스트를 수행하면 원래 의도와 다른 오해를 잡아내지 못함.
  • TDD 원칙 차용: 코드 작성 전에 수용 기준(Acceptance Criteria) 을 먼저 작성하고, 에이전트가 이를 기준에 따라 구현 후 별도 검증 수행.
  • 4 단계 파이프라인: Claude Code headless 모드(claude -p) 와 Playwright MCP 를 결합하여 별도 백엔드 불필요.
  • “완료” 정의 명시: 작업 시작 전에 “완료”의 정의를 명확히 해야 하며, 프롬프트 작성보다 어려우나 필수.

⚠️ 자율 에이전트의 코드 검증 문제

현실적 난관

  • Gastown 같은 AI 도구를 활용해 에이전트가 수 시간 동안 코드를 작성하고 브랜치에 변경 사항을 반영.
  • 결과물의 정확성 검증 방법 부재: 실제로 올바른지 신뢰할 수 있는 검증 방법이 없음.
  • 100 명 이상의 엔지니어 워크숍 결과: 모든 팀에서 동일한 문제 확인.
  • PR 병합량 급증: 주당 10 개에서 40~50 개로 증가하여 코드 리뷰 시간이 크게 늘음.
  • 배포 후 오류 발견: 시스템이 자율적으로 동작할수록 문제가 심화됨.

해결책의 한계

  • 리뷰어 추가 채용: 속도가 따라가지 못함.
  • 시니어 엔지니어 AI 생성 코드 독서: 하루 종일 읽는 것은 비효율적.
  • 자기 검사 불가: Claude 가 자신이 작성한 코드의 테스트를 작성하면 원하지 않는 것임을 검증.
  • 회귀 버그 vs 오해 포착: 회귀 버그는 잡을 수 있으나, 원래의 오해(misunderstanding) 는 포착 불가.

💡 핵심 교훈

“동일한 AI 로 작성과 검증을 동시에 수행하면 자기 축하 기계가 됨.”


🎯 TDD 가 올바르게 짚은 핵심

TDD 원칙 차용

  1. 테스트 먼저 작성: 코드를 작성하기 전에 무엇을 해야 하는지 미리 생각함.
  2. 코드 작성 및 테스트 통과: 테스트가 통과하면 더 구현하지 않음.
  3. 왜 TDD 를 하지는 않는가?: 코드가 무엇을 해야 하는지 미리 생각하는 데 시간이 걸리기 때문.
  4. AI 가 속도 해결: 이제 느린 부분은 코드가 올바른지 판단하는 것.
  5. 단위 테스트 vs 기능 명세서: 단위 테스트 대신 기능이 해야 할 일을 평문으로 기술.

예시: 수용 기준(Acceptance Criteria)

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

📋 실제 적용 사례

✅ 프론트엔드 변경

스펙 파일 기반 수용 기준 생성

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

검증 프로세스

  1. 에이전트 기능 구축 후,
  2. Playwright 브라우저 에이전트 각 AC에 대해 검증 실행.
  3. 스크린샷 촬영 및 기준별 판정 리포트 생성.
  4. 실패 시: 어떤 기준이 실패했고 브라우저에서 무엇이 보였는지 정확히 확인 가능.

✅ 백엔드 변경

브라우저 없이 동일한 패턴 적용

  • 관찰 가능한 API 동작(상태 코드, 응답 헤더, 에러 메시지) 명시.
  • curl 명령어로 검증.
  • 한계점: 스펙 자체가 잘못된 경우 검증을 거쳐도 기능이 틀려남.

🔧 4 단계 파이프라인 구축

도구 Stack

  • Claude Code headless 모드: claude -p
  • Playwright MCP: 브라우저 자동화
  • 별도 백엔드 불필요: 기존 Claude OAuth 토큰만 사용.

1 단계: Pre-flight (사전 준비)

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

2 단계: Planner (플래닝)

  • Opus 한 번 호출.
  • 스펙과 변경된 파일 읽고, 각 검증에 필요한 사항과 실행 방법 결정.
  • 코드를 읽어 올바른 셀렉터 찾기.

3 단계: Browser Agents (브라우저 에이전트)

  • AC 당 Sonnet 한 번 호출, 모두 병렬 실행.
  • 5 개 AC 이면 5 개 에이전트가 독립적으로 네비게이션 및 스크린샷 촬영.
  • Sonnet = Opus 대비 3~4 배 저렴하며 클릭 기반 작업에서 동등한 성능.

4 단계: Judge (판정)

  • Opus 한 번 최종 호출로 모든 증거를 읽고 기준별 판정 반환.
  • 판정: pass, fail, 또는 needs-human-review.

🔧 설치 방법

CLI 설치

  1. Claude Code 플러그인으로 설치 가능:
    /plugin marketplace add opslane/verify
  2. 레포 클론: 커스터마이징 가능.
    • 각 단계는 단일 claude -p 호출로 명확한 입력과 구조화된 출력 보유.
    • 모델 교체, 단계 추가, CI 연동 가능 (--dangerously-skip-permissions 옵션 사용).

📚 핵심 교훈

완료의 정의 명시

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

수용 기준 작성은 프롬프트보다 어려움

  • 엣지 케이스를 사전에 고려하게 만들어 품질을 높임.
  • 엔지니어들이 TDD 를 거부했던 이유와 동일하게, 처음에 더 느리게 느껴져서 저항.
  • 수용 기준 없이는 결과물을 읽고 올바르게 바라는 것만 가능.
  • 이는 AI 주도 개발 환경에서 신뢰성을 확보하는 필수 절차.

🔗 관련 태그

AI ClaudeCode 에이전트 코드검증 PlaywrightMCP TDD 수용기준 자동화 CD

작성된 파일 경로: /home/bigstones/git/obsidian/bigstone/기술/AI-ML/AI_에이전트_자동화_파이프라인.md

참고 파일:

  • bigstone/기술/AI-ML/AI_엔지니어링_규율.md (엔지니어링 규율 중요성)
  • bigstone/기술/반도체/AI_칩_메타_MTIA.md (AI 칩 최적화 전략)