# \[GN⁺\] 잠자는 동안 실행되는 에이전트를 만들고 있어요 (I'm Building Agents That Run While I Sleep) **URL:** https://discuss.pytorch.kr/t/gn-im-building-agents-that-run-while-i-sleep/9208 **Category:** 읽을거리&정보공유 **Tags:** claude-code, autonomous-agent, spec-driven-development, vibe-coding, test-driven-development **Created:** [3월 13, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/gn-im-building-agents-that-run-while-i-sleep/9208 "2026-03-13T09:30:54Z") **Posts on this page:** 1 **Page:** 1
### Author: ![9bow](https://discuss.pytorch.kr/user_avatar/discuss.pytorch.kr/9bow/32/16301_2.png) [@9bow](https://discuss.pytorch.kr/u/9bow) #### Post date: [3월 13, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/gn-im-building-agents-that-run-while-i-sleep/9208/1 "2026-03-13T09:30:54Z")
![잠자는 동안 실행되는 에이전트를 만들고 있어요 (I'm Building Agents That Run While I Sleep)](https://discuss.pytorch.kr/uploads/default/original/3X/2/2/22a121dfbe7f4ba0c5ca11dcc5d8b4d57cece2e1.png) ## '잠자는 동안 실행되는 에이전트를 만들고 있어요' 글 소개 - **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 주도 개발 환경에서 신뢰성을 확보하는 필수 절차** 임 ## [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)** 같은 도구로 코드 보안을 보장하는 방향이 필요함 ## 원문 > **[I'm Building Agents That Run While I Sleep](https://www.claudecodecamp.com/p/i-m-building-agents-that-run-while-i-sleep)** > > I Have No Idea If What They Ship Is Any Good ## 출처 / GeekNews > **[잠자는 동안 실행되는 에이전트를 만들고 있어요 | GeekNews](https://news.hada.io/topic?id=27414)** > > AI 코드 작성 에이전트가 개발자가 자는중에도 코드를 생성하고 브랜치에 변경사항을 반영하지만, 결과의 정확성과 신뢰성 검증이 어려움AI가 작성한 코드를 같은 AI가 테스트하면 자기 축하 기계가 되어, 원래 의도와 다른 오해를 잡아내지 못함TDD의 핵심 원칙을 차용해 코드 작성전에 수용 기준을 먼저 작성하고, 에이전트가 이를 기준으로 구현 후 별도 검증 수행 * * * ### **ℹ 알려드립니다** 이 글은 국내외 IT 소식들을 공유하는 [GeekNews](https://news.hada.io/)의 운영자이신 [xguru](https://news.hada.io/user?id=xguru)님께 허락을 받아 GeekNews에 게제된 AI 관련된 소식을 공유한 것입니다. 출처의 [GeekNews](https://news.hada.io/) 링크를 방문하시면 이 글과 관련한 추가적인 의견들을 보시거나 공유하실 수 있습니다! 😉 🎁 아래↘쪽에 좋아요❤를 눌러주시면 새로운 소식을 정리하고 공유하는데 힘이 됩니다~ 🤩