잠자는 동안 실행되는 에이전트

• AI 코드 작성 에이전트가 개발자의 수면 중에도 코드를 생성하고 브랜치에 변경사항을 반영하지만, 결과의 정확성과 신뢰성 검증이 어려운 문제가 제기됨
• 동일한 AI가 코드와 테스트를 모두 작성하면 자기검증 루프가 발생해 실제 요구사항과의 불일치를 잡지 못함
• 이를 해결하기 위해 TDD(테스트 주도 개발) 의 원칙을 적용, 코드 작성 전 명확한 수용 기준(Acceptance Criteria) 을 정의하는 접근이 제시됨
• 프런트엔드에서는 Playwright 브라우저 에이전트를, 백엔드에서는 API 응답 검증을 통해 각 기준을 자동 확인하는 구조로 설계됨
• 핵심은 “시작 전에 ‘완료’의 정의를 명시”하는 것으로, 이는 AI 기반 개발의 신뢰 확보를 위한 필수 절차로 강조됨

AI가 작성한 코드를 신뢰하기 어려운 이유

• AI 도구(Gastown 등)가 장시간 자동으로 코드를 작성하고 브랜치에 반영하지만, 결과물이 올바른지 확인할 방법이 부족함
  • 작성자는 코드 품질을 보장하지 못한 채 병합되는 상황을 문제로 인식함
• 여러 팀이 Claude를 활용해 PR을 자동화하면서 코드 리뷰 부담이 급증
  • 일부 팀은 주당 40~50개의 PR을 병합하며, 이는 기존의 10개 수준보다 훨씬 많음
• 시스템이 자율적으로 동작할수록 검토 과정이 생략되고, 배포 후 오류를 발견하는 구조로 변함

기존 해결책의 한계

• 리뷰어를 늘리는 것은 속도와 비용 측면에서 비현실적
• Claude가 작성한 코드를 Claude가 테스트하면, AI가 스스로를 검증하는 구조가 되어 오류를 놓침
  • 테스트는 “Claude가 이해한 요구사항”만 검증하며, 실제 요구사항과의 불일치는 탐지하지 못함
• 서로 다른 AI를 코드 작성과 검증에 사용해도, 동일한 학습 기반으로 인해 같은 실수를 반복함

TDD가 제공하는 통찰

• TDD는 “테스트를 먼저 작성하고 코드로 이를 충족시키는 방식”으로, 정확성 정의를 명시적으로 요구함
• AI의 속도 덕분에 개발자는 이제 ‘무엇이 올바른가’를 정의하는 단계에 집중할 수 있음
• 예시로 로그인 기능의 요구사항을 자연어로 명확히 기술하고, AI가 이를 구현하도록 함
  • 예: 올바른 자격 증명 시 /dashboard로 이동, 잘못된 경우 “Invalid email or password” 표시 등

실제 적용 사례

• 프런트엔드에서는 명세 파일로부터 수용 기준(AC) 을 자동 생성
  • 예: 성공적 로그인, 잘못된 비밀번호 오류, 빈 필드 검증, 5회 실패 후 60초 차단 등
• 각 AC는 Playwright 브라우저 에이전트가 실행해 스크린샷과 결과 보고서를 생성
  • 실패 시 어떤 기준이 실패했는지와 브라우저 상태를 명확히 제시
• 백엔드에서는 curl 명령으로 API 응답(상태 코드, 헤더, 오류 메시지 등) 을 검증
• 다만, 명세 자체가 잘못된 경우는 탐지 불가하며, 실제 브라우저 환경에서의 통합 오류나 렌더링 문제를 주로 포착함
• 전체 워크플로는 “수용 기준 작성 → 에이전트 빌드 → 검증 실행 → 실패 항목만 리뷰”의 형태로 구성됨

Claude Skill ‘verify’ 구축 방식

• GitHub의 opslane/verify 프로젝트로, Claude Code의 headless 모드(claude -p) 와 Playwright MCP를 활용
• 4단계 구조로 구성됨
  • Pre-flight: Bash 기반 사전 점검(서버 실행 여부, 인증 세션, 명세 파일 존재 등)
  • Planner: Opus 모델이 명세와 코드 변경을 분석해 필요한 검증 절차를 계획
  • Browser agents: Sonnet 모델이 각 AC를 병렬 실행하며 스크린샷 수집
  • Judge: Opus 모델이 결과를 종합해 각 기준의 통과/실패/인간 검토 필요를 판정
• 설치는 Claude Code 플러그인 명령어(/plugin marketplace add opslane/verify)로 가능하며, CI 파이프라인에도 통합 가능

결론: 신뢰 가능한 AI 개발의 조건

• “완료의 정의를 사전에 명시하지 않으면, 결과를 신뢰할 수 없다” 는 점이 핵심
• 수용 기준 작성은 프롬프트보다 어렵지만, 엣지 케이스를 사전에 고려하게 만들어 품질을 높임
• 이는 TDD와 동일한 철학으로, AI 주도 개발 환경에서 신뢰성을 확보하는 필수 절차로 강조됨