▲

잠자는 동안 실행되는 에이전트를 만들고 있어요

 (claudecodecamp.com)
9P by GN⁺ 13시간전 | ★ favorite | 댓글 1개
  • AI 코드 작성 에이전트가 개발자가 자는중에도 코드를 생성하고 브랜치에 변경사항을 반영하지만, 결과의 정확성과 신뢰성 검증이 어려움
  • AI가 작성한 코드를 같은 AI가 테스트하면 자기 축하 기계가 되어, 원래 의도와 다른 오해를 잡아내지 못함
  • TDD의 핵심 원칙을 차용해 코드 작성전에 수용 기준을 먼저 작성하고, 에이전트가 이를 기준으로 구현 후 별도 검증 수행
  • 검증 도구로 Claude Code의 headless 모드(claude -p)와 Playwright MCP를 결합한 4단계 파이프라인 구축, 별도 백엔드 불필요
  • 에이전트 산출물을 신뢰하려면 작업 시작 전에 "완료"의 정의를 명확히 해야 하며, 이는 프롬프트 작성보다 어렵지만 필수적인 과정

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

  • Gastown 같은 AI도구를 활용해 에이전트가 수 시간 동안 코드를 작성하고 브랜치에 변경 사항을 반영하지만, 그 결과물이 실제로 올바른지 신뢰할 수 있는 검증 방법이 없음
  • 지난 6개월간 100명 이상의 엔지니어 대상 Claude Code 워크숍을 진행한 결과, 모든 팀에서 동일한 문제 확인
  • Claude를 일상적 PR에 사용하는 팀들은 주당 10개에서 40~50개로 PR 병합량이 증가해, 코드 리뷰에 훨씬 더 많은 시간 소비
  • 시스템이 자율적으로 동작할수록 문제가 심화됨 - 어느 시점에서는 diff를 리뷰하지 않고 배포를 지켜보며 문제가 없기를 바라고, 배포 후에야 오류를 발견하는 구조가 됨

기존 해결책의 한계

  • 리뷰어를 추가 채용하는 방법은 속도가 따라가지 못하고, 시니어 엔지니어가 하루 종일 AI 생성 코드를 읽는 것은 비효율적
  • Claude가 자신이 작성한 코드의 테스트를 작성하면, 사용자가 실제로 원한 것이 아니라 Claude가 원한다고 판단한 것을 검증하는 구조
    • 회귀 버그는 잡을 수 있지만 원래의 오해(misunderstanding) 는 포착 불가
  • 같은 AI로 작성과 검증을 동시에 수행하면 "자기 축하 기계(self-congratulation machine)" 가 됨
  • 코드 리뷰의 본래 목적은 원래 작성자가 아닌 두 번째 시선인데, AI 간 교차 검토는 동일한 출처에서 비롯되어 같은 것을 놓침

TDD가 올바르게 짚은 핵심

  • TDD의 원칙: 테스트를 먼저 작성하고, 코드를 작성하고, 테스트가 통과하면 멈춤(더 구현하지 않고)
  • 대부분의 팀이 TDD를 하지 않는 이유는 코드가 무엇을 해야 하는지 미리 생각하는 데 시간이 걸리기 때문
  • AI가 속도 문제를 해결하므로 이 핑계가 사라짐 — 이제 느린 부분은 코드가 올바른지 판단하는 것
  • 단위 테스트 대신 기능이 해야 할 일을 평문으로 기술하는 방식이 더 쉬움
    • 예시: "사용자가 이메일과 비밀번호로 인증. 잘못된 자격 증명 시 'Invalid email or password' 표시. 성공 시 /dashboard 이동. 세션 토큰은 24시간 후 만료"
  • 코드 에디터를 열기 전에 이 기준을 작성 가능하며, 에이전트가 구현하고 다른 무언가가 검증

실제 적용 사례

  • 프론트엔드 변경

    • 스펙 파일 기반으로 수용 기준(Acceptance Criteria) 을 생성
      • AC-1: 유효한 자격 증명으로 /login 접속 시 /dashboard로 리다이렉트, 세션 쿠키 설정
      • AC-2: 잘못된 비밀번호 입력 시 정확히 "Invalid email or password" 표시, /login 페이지 유지
      • AC-3: 필드가 비어 있으면 제출 버튼 비활성화 또는 인라인 에러 표시
      • AC-4: 5회 실패 후 60초간 로그인 차단, 대기 시간 메시지 표시
    • 각 기준은 통과 또는 실패로 명확히 판별 가능
    • 에이전트가 기능 구축 후, Playwright 브라우저 에이전트가 각 AC에 대해 검증 실행, 스크린샷 촬영, 기준별 판정 리포트 생성
    • 실패 시 어떤 기준이 실패했고 브라우저에서 무엇이 보였는지 정확히 확인 가능

  • 백엔드 변경

    • 브라우저 없이 동일한 패턴 적용
    • 관찰 가능한 API 동작(상태 코드, 응답 헤더, 에러 메시지)을 명시하고 curl 명령어로 검증

  • 한계점

    • 스펙 자체의 오해는 잡아내지 못함 — 스펙이 처음부터 잘못되면 검증을 통과해도 기능이 틀린 상태
    • Playwright가 잡아내는 것: 통합 실패, 렌더링 버그, 실제 브라우저에서 깨지는 동작
    • "검증된 정확성"보다는 좁은 범위의 주장이지만, 코드 리뷰가 안정적으로 잡아내던 것보다는 더 많은 것을 포착

  • 워크플로우 요약

    • 프롬프트 전에 수용 기준 작성 → 에이전트가 기준에 맞춰 구현 → 검증 실행 → 실패한 것만 리뷰 (diff가 아닌 실패 리뷰)

구축 방법: 4단계 파이프라인

  • Claude Skill로 구현 (github.com/opslane/verify), claude -p(Claude Code headless 모드)와 Playwright MCP 사용
  • 별도 커스텀 백엔드나 추가 API 키 불필요, 기존 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

  • 설치 방법

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

핵심 교훈

  • “완료의 정의를 사전에 명시하지 않으면, 결과를 신뢰할 수 없다” 는 점이 핵심
  • 수용 기준 작성은 프롬프트보다 어렵지만, 엣지 케이스를 사전에 고려하게 만들어 품질을 높임
  • 엔지니어들이 TDD를 거부했던 이유와 동일하게, 처음에 더 느리게 느껴지기 때문에 저항함
    • 수용 기준 없이는 결과물을 읽고 올바르기를 바라는 것만 가능
  • 이는 AI 주도 개발 환경에서 신뢰성을 확보하는 필수 절차임
▲
GN⁺ 13시간전  [-]
Hacker News 의견들

  • 요즘 나오는 LLM 프레임워크들이 오히려 개발을 더 어렵고 비싸게 만드는 느낌임
    기본 설정만으로도 충분히 멀리 갈 수 있는데, 모델이 계속 바뀌는 상황에서 수많은 래퍼와 하네스를 만드는 건 비효율적이라 생각함
    밤새 돌려놓고 돈 태우는 이런 방식은 나중에 PHP 밈처럼 웃음거리로 남을 것 같음

    • AI 붐 속에서 삽 파는 사람 입장이라면 얘기가 다름
      기사에 따르면 “지난 6개월간 100명 넘는 엔지니어에게 Claude Code 워크숍을 진행했다”고 함
    • 경쟁사들이 코드베이스에 AI 에이전트를 최대한 많이 쓰길 바람
      밤낮없이 돌리다가 결국 AI 회사가 파산하고, 남은 건 80%가 AI가 짠 스파게티 코드뿐일 때 누가 웃을지 보겠음
    • PHP를 비웃을 일은 아님. 지금도 내 최고의 프로젝트 중 일부는 PHP로 만들어졌음
      요즘의 풀스택 JS/TS 환경보다 15년 전 PHP로 만든 게 더 나았다고 느껴짐
    • 예전의 anti-PHP 밈이 얼마나 어리석었는지 이제야 보임
      PHP는 여전히 살아 있고 발전 중임. LLM 툴링도 결국 그런 식으로 기본 도구가 될 것임
    • 이건 단순히 일이 늘어난 게 아니라 역할의 융합임
      BA, PO, QA, SWE의 경계가 흐려지고 있음. 이제는 비즈니스와 개발의 중간에 있는 하이브리드 역할이 생겨나고 있음

  • 사람들은 요즘 에이전트를 그냥 써보는 게 목적이 된 것 같음
    나는 글쓰기용, 리뷰용 두 개만 돌리는데도 생산성 5~7배는 충분함
    스펙 검토에 시간을 더 쓰고, 코딩은 에이전트가 10~30분이면 끝내서 급할 게 없음

    • “밤새 돌리는 에이전트” 개념은 이해가 안 됨. Claude는 대부분 5~20분이면 끝남
      내일도 일은 계속 있으니 굳이 밤새 돌릴 이유가 없음
    • 나도 처음엔 여러 에이전트를 병렬로 돌렸지만, 결국 한 디렉토리 단위로 집중하는 게 훨씬 효율적이었음
    • SWE가 하던 일 중 상당 부분을 이제는 AI가 brute force로 처리할 수 있음
      고객 입장에서는 인도, 샌프란시스코, AI 중 어디서 버그가 오든 큰 차이 없음
    • 나도 두 개의 에이전트만 돌리며 미세 조정을 많이 함
      요즘 유행하는 ‘에이전트 오케스트라’보다는 훨씬 통제된 방식임
    • 스펙 검증이 가장 중요한 단계라 생각함
      그래서 Claude가 스펙을 잘 따르는지 확인하려고 verify 스킬을 직접 만들었음

  • Claude에게 red-green-refactor 패턴을 쓰게 하면 확실히 테스트 품질이 올라감
    더 나아가 red/green/refactor 서브에이전트를 만들어 서로 검증하게 하면 꽤 잘 작동함
    핵심은 컨텍스트를 섞지 않는 것임

    • 하지만 리팩터링이 진행되면 테스트가 쓸모없어지거나 빠지는 경우가 많음
      reward hacking이 실제로 존재하며 방어하기 어려움
    • red/green TDD를 시켜도 실패하지 않는 테스트를 써놓고 “이미 해결됨”이라며 넘어감
      이 가이드를 참고해도 여전히 나쁜 테스트 문제가 큼
    • 나는 Outside-in TDD를 Claude Code에 완전히 적용했음
      결과가 좋아서 원리와 예제와 starter repo를 공개했음
    • green/red/refactor 패턴 구현법을 더 자세히 알고 싶음. 참고 자료가 있으면 좋겠음
    • PR 리뷰에도 이 접근이 효과적임
      작성자와 검증자 분리가 중요하며, 같은 모델이라도 컨텍스트를 분리하면 품질이 올라감

  • 현재 LLM의 컨텍스트 한계 때문에 진짜 에이전트는 아직 불가능함
    500줄 이상 코드에서는 오류가 급격히 늘고, 200줄 정도가 한계임
    결국 LLM은 계산기처럼 반복적으로 사용해야 하는 도구에 불과함

  • 나는 이 현상을 “Test Theatre”라 부름
    관련 글을 여기에 썼음. 적극적으로 피해야 함

    • 에이전트가 100줄 코드에 600줄 테스트를 쓰기도 하지만, 대부분 의미 없는 테스트임
      좋은 테스트는 디자인 패턴과 의존성을 검증하고, 디버깅에 도움을 줘야 함
    • property testing을 활용하면 훨씬 나은 결과를 얻음
      예를 들어 Schemathesis로 사용자 권한이나 5xx 응답 여부를 자동 검증함
    • Test Theatre는 정확한 표현임. 테스트가 통과해도 실제로는 아무것도 증명하지 않음
    • 가장 좋은 방법은 Outside-in TDD + mutation testing을 강제하는 것임
      관련 POC를 여기에 올려둠
    • 사실 이런 형식적인 테스트는 예전부터 있었음. 대부분 구현 자체를 테스트함

  • 최근 에이전트 오케스트레이션을 실험 중임
    핵심은 LLM 호출을 줄이고 결정적 스크립트 파이프라인으로 연결하는 것임
    자세한 내용은 이 글에 정리했음

    • 나도 비슷하게 스크립트 중심 오케스트레이션을 시도 중임
      이 실험 기록처럼 LLM보다 스크립트가 핵심임

  • 나는 비즈니스 운영용 에이전트 6개를 돌리고 있음
    시장 조사, 콘텐츠 작성, 영상 스크립트 등 다양한 역할을 맡김
    “밤새 돌리기”는 과장된 개념이고, 실제로는 명확한 목표와 좁은 범위가 효과적임
    진짜 병목은 실행이 아니라 컨텍스트 관리임

    • 흥미로운 접근임. 어떤 제품을 만들고 있는지, Reddit 기반 리서치가 여전히 유효한지도 궁금함

  • 이 사람이 실제로 뭘 만드는지 모르겠음
    LinkedIn에 Claude 관련 글만 보임

    • 검증도 못 하는 코드를 배포한다는 건 심각한 리스크임
      진지한 비즈니스라면 상상도 못 할 일임
    • 25년 업계 경험상, 이렇게 빠른 속도로 코드가 필요한 회사는 없었음
      결국 팔 방법을 고민하느라 코드가 놀게 됨

  • 테스트만 쓰는 사람을 고용했을 때와 같은 문제임
    결국 “코드가 코드대로 동작한다”는 걸 확인할 뿐임
    명확한 스펙 정의가 훨씬 중요함

    • 사후 테스트는 대부분 동어반복 검증임
      다른 공학 분야는 이런 실수를 반복하지 않는데, 소프트웨어만 유독 그렇다는 게 놀라움
    • 테스트의 진짜 가치는 회귀 방지에 있음
      초기 릴리스가 틀렸더라도, 이후 동작이 바뀌지 않도록 보장함
    • 테스트의 목적은 결국 mock 검증임
    • 스펙을 먼저 정의하고 그에 맞춰 검증하는 게 핵심임
      많은 컨설팅 회사들이 acceptance criteria 기반 검증으로 일함

  • 지금의 AI는 개발을 돕는 도구가 아니라 개발자를 대체하는 수준에 도달함
    우리가 더 이상 코드를 통제하거나 검증하지 못하는 건 심각한 문제임
    이건 새로운 개발 방식이 아니라 이해 대신 신뢰에 의존하는 종교적 전환처럼 느껴짐

    • 나는 이해하지 못한 코드는 절대 배포하지 않음
      자율성이 낮더라도 검증 가능한 코드만 머지함
    • 혹은 형식 검증(formal methods) 같은 도구로 코드 보안을 보장하는 방향이 필요함
답변달기