🤖 잠자는 동안 실행되는 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 원칙 차용
- 테스트 먼저 작성: 코드를 작성하기 전에 무엇을 해야 하는지 미리 생각함.
- 코드 작성 및 테스트 통과: 테스트가 통과하면 더 구현하지 않음.
- 왜 TDD 를 하지는 않는가?: 코드가 무엇을 해야 하는지 미리 생각하는 데 시간이 걸리기 때문.
- AI 가 속도 해결: 이제 느린 부분은 코드가 올바른지 판단하는 것.
- 단위 테스트 vs 기능 명세서: 단위 테스트 대신 기능이 해야 할 일을 평문으로 기술.
예시: 수용 기준(Acceptance Criteria)
"사용자가 이메일과 비밀번호로 인증.
잘못된 자격 증명 시 'Invalid email or password' 표시.
성공 시 /dashboard 이동.
세션 토큰은 24 시간 후 만료."
📋 실제 적용 사례
✅ 프론트엔드 변경
스펙 파일 기반 수용 기준 생성
| 기준 | 설명 |
|---|---|
| AC-1 | 유효한 자격 증명으로 /login 접속 시 /dashboard로 리다이렉트, 세션 쿠키 설정 |
| AC-2 | 잘못된 비밀번호 입력 시 정확히 "Invalid email or password" 표시, /login 페이지 유지 |
| AC-3 | 필드가 비어 있으면 제출 버튼 비활성화 또는 인라인 에러 표시 |
| AC-4 | 5 회 실패 후 60 초간 로그인 차단, 대기 시간 메시지 표시 |
검증 프로세스
- 에이전트 기능 구축 후,
- Playwright 브라우저 에이전트 각 AC에 대해 검증 실행.
- 스크린샷 촬영 및 기준별 판정 리포트 생성.
- 실패 시: 어떤 기준이 실패했고 브라우저에서 무엇이 보였는지 정확히 확인 가능.
✅ 백엔드 변경
브라우저 없이 동일한 패턴 적용
- 관찰 가능한 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 설치
- Claude Code 플러그인으로 설치 가능:
/plugin marketplace add opslane/verify - 레포 클론: 커스터마이징 가능.
- 각 단계는 단일
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 칩 최적화 전략)