# 잠자는 동안 실행되는 에이전트를 만들고 있어요 > Clean Markdown view of GeekNews topic #27414. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27414](https://news.hada.io/topic?id=27414) - GeekNews Markdown: [https://news.hada.io/topic/27414.md](https://news.hada.io/topic/27414.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-12T02:33:42+09:00 - Updated: 2026-03-12T02:33:42+09:00 - Original source: [claudecodecamp.com](https://www.claudecodecamp.com/p/i-m-building-agents-that-run-while-i-sleep) - Points: 19 - Comments: 2 ## Summary AI 코드 작성 에이전트가 자율적으로 코드를 생성하는 시대에는, 결과의 **정확성과 신뢰성 검증**이 가장 큰 과제가 됩니다. 같은 AI가 스스로 작성한 코드를 테스트하면 ‘자기 축하 기계’가 되어 오해를 잡아내지 못하기 때문입니다. 이를 해결하기 위해 **TDD의 원칙을 차용한 수용 기준 기반 검증 파이프라인**을 도입, Claude Code의 headless 모드와 Playwright MCP를 결합해 별도 백엔드 없이 구현할 수 있습니다. 핵심은 작업 전 “완료의 정의”를 명확히 세우는 것으로, 이는 프롬프트 작성보다 어렵지만 AI 산출물을 신뢰하기 위한 필수 조건입니다. ## Topic Body - **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](https://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 주도 개발 환경에서 신뢰성을 확보하는 필수 절차**임 ## Comments ### Comment 52933 - Author: github88 - Created: 2026-03-13T03:25:58+09:00 - Points: 1 아무리 TDD해봐야 LLM이 테스트 조작해서 통과하게 만드는 지금 수준에선 인간의 리뷰가 꼭 필요함.. ### Comment 52849 - Author: neo - Created: 2026-03-12T02:33:42+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47327559) - 요즘 나오는 **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 스킬](https://github.com/opslane/verify)을 직접 만들었음 - Claude에게 **red-green-refactor** 패턴을 쓰게 하면 확실히 테스트 품질이 올라감 더 나아가 **red/green/refactor 서브에이전트**를 만들어 서로 검증하게 하면 꽤 잘 작동함 핵심은 컨텍스트를 섞지 않는 것임 - 하지만 리팩터링이 진행되면 테스트가 쓸모없어지거나 빠지는 경우가 많음 **reward hacking**이 실제로 존재하며 방어하기 어려움 - red/green TDD를 시켜도 실패하지 않는 테스트를 써놓고 “이미 해결됨”이라며 넘어감 [이 가이드](https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/)를 참고해도 여전히 **나쁜 테스트** 문제가 큼 - 나는 **Outside-in TDD**를 Claude Code에 완전히 적용했음 결과가 좋아서 [원리와 예제](https://www.joegaebel.com/articles/principled-agentic-software-development/)와 [starter repo](https://github.com/JoeGaebel/outside-in-tdd-starter)를 공개했음 - green/red/refactor 패턴 구현법을 더 자세히 알고 싶음. 참고 자료가 있으면 좋겠음 - PR 리뷰에도 이 접근이 효과적임 **작성자와 검증자 분리**가 중요하며, 같은 모델이라도 컨텍스트를 분리하면 품질이 올라감 - 현재 **LLM의 컨텍스트 한계** 때문에 진짜 에이전트는 아직 불가능함 500줄 이상 코드에서는 오류가 급격히 늘고, 200줄 정도가 한계임 결국 LLM은 **계산기처럼 반복적으로 사용해야 하는 도구**에 불과함 - 나는 이 현상을 “**Test Theatre**”라 부름 관련 글을 [여기](https://benhouston3d.com/blog/the-rise-of-test-theater)에 썼음. 적극적으로 피해야 함 - 에이전트가 100줄 코드에 600줄 테스트를 쓰기도 하지만, 대부분 **의미 없는 테스트**임 좋은 테스트는 디자인 패턴과 의존성을 검증하고, 디버깅에 도움을 줘야 함 - **property testing**을 활용하면 훨씬 나은 결과를 얻음 예를 들어 Schemathesis로 사용자 권한이나 5xx 응답 여부를 자동 검증함 - Test Theatre는 정확한 표현임. 테스트가 통과해도 실제로는 아무것도 증명하지 않음 - 가장 좋은 방법은 **Outside-in TDD + mutation testing**을 강제하는 것임 관련 POC를 [여기](https://www.joegaebel.com/articles/principled-agentic-software-development)에 올려둠 - 사실 이런 **형식적인 테스트**는 예전부터 있었음. 대부분 구현 자체를 테스트함 - 최근 **에이전트 오케스트레이션**을 실험 중임 핵심은 LLM 호출을 줄이고 **결정적 스크립트 파이프라인**으로 연결하는 것임 자세한 내용은 [이 글](https://www.frequency.sh/blog/introducing-frequency/)에 정리했음 - 나도 비슷하게 **스크립트 중심 오케스트레이션**을 시도 중임 [이 실험 기록](https://blog.unratified.org/2026-03-06-receiving-side-agent-proposals/)처럼 LLM보다 스크립트가 핵심임 - 나는 **비즈니스 운영용 에이전트** 6개를 돌리고 있음 시장 조사, 콘텐츠 작성, 영상 스크립트 등 다양한 역할을 맡김 “밤새 돌리기”는 과장된 개념이고, 실제로는 **명확한 목표와 좁은 범위**가 효과적임 진짜 병목은 실행이 아니라 **컨텍스트 관리**임 - 흥미로운 접근임. 어떤 제품을 만들고 있는지, **Reddit 기반 리서치**가 여전히 유효한지도 궁금함 - 이 사람이 실제로 뭘 만드는지 모르겠음 LinkedIn에 **Claude 관련 글**만 보임 - 검증도 못 하는 코드를 배포한다는 건 **심각한 리스크**임 진지한 비즈니스라면 상상도 못 할 일임 - 25년 업계 경험상, 이렇게 빠른 속도로 코드가 필요한 회사는 없었음 결국 팔 방법을 고민하느라 코드가 놀게 됨 - 테스트만 쓰는 사람을 고용했을 때와 같은 문제임 결국 “코드가 코드대로 동작한다”는 걸 확인할 뿐임 명확한 **스펙 정의**가 훨씬 중요함 - 사후 테스트는 대부분 **동어반복 검증**임 다른 공학 분야는 이런 실수를 반복하지 않는데, 소프트웨어만 유독 그렇다는 게 놀라움 - 테스트의 진짜 가치는 **회귀 방지**에 있음 초기 릴리스가 틀렸더라도, 이후 동작이 바뀌지 않도록 보장함 - 테스트의 목적은 결국 **mock 검증**임 - 스펙을 먼저 정의하고 그에 맞춰 검증하는 게 핵심임 많은 컨설팅 회사들이 **acceptance criteria 기반 검증**으로 일함 - 지금의 AI는 개발을 돕는 도구가 아니라 **개발자를 대체**하는 수준에 도달함 우리가 더 이상 코드를 통제하거나 검증하지 못하는 건 심각한 문제임 이건 새로운 개발 방식이 아니라 **이해 대신 신뢰에 의존하는 종교적 전환**처럼 느껴짐 - 나는 **이해하지 못한 코드**는 절대 배포하지 않음 자율성이 낮더라도 검증 가능한 코드만 머지함 - 혹은 **형식 검증(formal methods)** 같은 도구로 코드 보안을 보장하는 방향이 필요함