How to Build AI Agents That Check Their Own Work | Jared Zoneraich

게스트: Jared Zoneraich (Cognition의 Devon 프로덕트 Building-in-Residence, 전 PromptLayer) 진행: Peter Yang

계층 1 — 핵심 주장 / 결론

• "모델이 알아서 하게 두고, 특정 방향으로 억지로 밀어넣지 마라(Let the model cook)." 정교한 프롬프트 엔지니어링·거대한 DAG형 오케스트레이션은 방어력(defensibility)이 아니다 — 모델이 좋아질수록 그 우위는 사라진다.
• 에이전트를 만드는 최고의 전략은 모델 랩(Anthropic, OpenAI 등)의 로드맵과 같은 방향으로 흐르는 것이지, 거스르는 것이 아니다.
• Devon/Cognition의 철학: "코딩을 대체하려는 게 아니라, 좋은 소프트웨어의 풍요를 만들고 엔지니어를 증폭시키려는 것." 엔지니어는 안목(taste)과 고차원적 의사결정에 집중하고, 나머지는 에이전트가 처리해야 하며 엔지니어가 병목이 되면 안 된다.
• 완벽보다 완성이 낫다(Done is better than perfect). 에이전트 프로덕트를 만들 때 처음부터 완벽한 eval 체계를 갖추려 하지 말고 일단 80%까지 빠르게 도달한 뒤, 마지막 20%(진짜 어려운 부분, 사람의 취향과 다듬기가 필요한 구간)에 시간을 쓰라.
• 자기검증(self-check)의 핵심 패턴: 에이전트가 스스로 sanity check/smoke test를 만들고, 그 결과를 마크다운 파일로 남긴 뒤, 그 파일을 다시 읽어 스스로 판단하고 반복 개선하게 만드는 것. 이것이 "에이전트가 자기 작업을 확인한다"는 제목의 실질적 구현 방식이다.
• 비동기·클라우드 에이전트가 미래다. 로컬에서 하나씩 순차로 돌리는 방식보다, 클라우드에서 다수의 자식 에이전트(child Devon)를 병렬로 띄우고 마스터 에이전트가 오케스트레이션하는 방식이 실제 실무에서 훨씬 강력하다.

계층 2 — 주요 논점 및 근거

1) 프롬프트/스캐폴딩에 투자하지 말고 "모델 진보에 올라타라"

• LLM 역사가 아직 3~4년밖에 안 됐는데, 한때 사람들이 직접 프롬프트로 유도해야 했던 chain-of-thought, tool calling 같은 것들이 이제는 모델 자체에 내장됐다.
• 오늘날 많은 팀이 "이 노드가 저 노드에 연결되고, 저 프롬프트가 이 프롬프트에 연결되는" 거대한 DAG 워크플로우에서 벗어나는 중이고, Anthropic이 최근("어제") 내놓은 dynamic workflow 관련 작업도 이 흐름을 뒷받침한다.
• 시사점: 지금 초정밀한("think ultra hard", 1-2-3단계 지시 같은) 프롬프트가 필요하다고 느껴진다면, 그것을 회사의 핵심 경쟁력으로 착각하지 말 것 — 모델이 따라잡을 것이기 때문.
• 실제 사례: 1년 전, 심지어 6~8개월 전만 해도 안 됐던 것이, 지금은 "로그인 플로우에 이상한 버그가 있어" 한 줄만 던져도 최고 모델이 알아서 찾아 고친다.

2) "방어력(defensibility)"에 대한 재정의

• Jared는 방어력이라는 질문 자체에 크게 관심이 없다고 말한다. 좋은 걸 만들면 훌륭한 창업자는 방법을 찾아낸다.
• Cognition의 방어력은 두 가지: (1) 하니스(harness) 자체의 완성도, (2) 고투마켓 — 특히 FDE(Forward Deployed Engineering), 즉 엔지니어를 고객사에 파견해 함께 작업하며 실제 문제를 해결하는 방식.
• FDE가 중요한 이유: 시장의 실제 수요자는 트위터에서 AI 최신 기술을 따라가는 "AI-native" 개발자가 아니라, 에이전트 루프가 뭔지도 모르는 일반 기업(월가 은행, 포춘 100대 기업 등)이다. 이들에게는 "직접 앉아서 실제 문제를 에이전트로 함께 풀어주는" 경험이 신뢰를 만든다 — 실제로 그 과정에서 고객의 티켓 보드에서 티켓을 실제로 처리해준다.

3) 롤아웃 단계에서 흔한 실패: "완벽주의로 인한 마비"

• 흔한 실패 사례("AI psychosis"): 한 달 동안 13개의 서로 다른 에이전트로 구성된 "개인용 cloud code 인벤토리 시스템"을 만들다 지쳐버리는 경우.
• 완벽은 완성의 적이다. 구식(결정론적 코드) 세계에서 넘어온 팀들은 "모든 것에 테스트가 있어야 한다"는 습관을 그대로 에이전트에 적용하려 하지만, 최고의 팀 중 일부는 eval 세트 없이도 프로덕션에 배포한다.
• 첫 플래그십 에이전트 제품을 만드는 팀이라면: 계획만 세우다 갇히지 말고 일단 만들어라. 80%까지는 놀랍도록 쉽고 빠르게 도달하지만, 그 이후 마지막 구간(라스트 마일)은 1년이 걸릴 수도 있다. 많은 사람이 100%를 미리 계획하려다 80%에도 도달하지 못한다.
• Peter Yang의 보완 의견: 라스트 마일은 결국 사람의 취향(taste)과 손질의 영역 — AI 산출물을 실제로 들여다보고 다듬는 마지막 10%가 진짜 차별화 지점이며, 그렇지 않으면 그냥 "슬롭(slop)"이 쌓일 뿐이다.

4) 제목의 핵심 — 에이전트가 스스로 작업을 검증하게 만드는 실전 방법

• Jared 본인이 만들고 있는 프로젝트(OpenClaw 스타일의 heartbeat 기반 proactive 개인 비서 챗봇)를 예로 듦.
• 하니스를 만들면서 eval에는 시간을 거의 쓰지 않았고, 대신 Devon에게 스스로 eval을 만들게 하고, Devon이 그 eval 결과를 보고 스스로 반복 개선하도록 시켰다.
• 구체적 방식: 데이터 리콜, 툴 사용, 응답 길이 등에 대한 예시들을 Devon이 직접 만들게 함 → 몇 개의 프로그래매틱 엔드포인트가 마크다운 파일로 결과를 남김 → Devon이 그 마크다운 파일을 읽고 이전 출력과 새 출력을 비교해서 스스로 판단하고 계속 개선.
• 이는 "브라우저 유즈/컴퓨터 유즈로 클릭해보는 e2e 테스트"가 아니라, 에이전트 응답 자체를 평가하는 방식이라는 점이 핵심 — 사람이 미리 정답을 정해두는 게 아니라 에이전트가 스스로 채점 기준과 결과를 만들고 판단한다.
• 사람이 손대는 부분은 "다 만들어지고 응답도 꽤 좋아진 뒤" 맨 마지막 단계 — 진짜 다듬기(finishing touch)는 여기서 시작되며, 이 부분이 가장 시간이 오래 걸린다.

5) Devon의 차별점 — 클라우드 네이티브 + 멀티플레이어 + 자식 에이전트 오케스트레이션

• Devon은 처음부터 클라우드 에이전트로 설계됨 — 로컬이 아니라 비동기(async) 작업에 최적화.
• 동기 작업(하나의 작업에 붙어서 왔다갔다) vs 비동기 작업(8개 작업을 동시에 관리하며 왔다갔다) 구분 — Cognition은 클라우드 에이전트 패러다임이 미래라고 본다.
• 마스터 Devon이 다수의 자식 Devon을 스핀업하는 패턴이 Cognition에서 일하는 모든 엔지니어가 공통으로 언급한 "최고의 팁"이었다고 함.
  • 각 자식 Devon은 독립된 VM을 가지며, 자체 컴퓨터·디스플레이·컴퓨터 유즈 능력을 가짐 (자기 코드를 스스로 테스트 가능).
  • 마스터 에이전트는 이 자식들의 결과를 pull down하고 메시지를 보낼 수 있음.
• 생태계: Devon Desktop(신규 데스크톱 앱), Devon CLI, Devon Cloud가 서로 통신 — "개인용 스위스아미나이프"가 아니라 팀을 위한 멀티플레이어 툴.
  • 실제 사람들끼리도 서로의 Devon 세션을 보고 상호작용 가능 (지식/매크로/스킬을 팀 전체와 공유).
  • 가장 많이 쓰이는 표면은 Slack과 자동화.
• "이번 달에 이미 일어난 큰 전환": 사람이 아니라 다른 Devon이나 프로그램(automation)이 더 많은 Devon을 실행시키는 비중이 더 커졌다. 예: Datadog 알림이 오면 자동으로 Devon에게 파이프됨.
• 비유: 자율주행 초기에 GPU를 놀리지 않으려 했던 것처럼, 개발자가 잠든 사이에도 에이전트가 계속 일하게 두는 것.

6) 비용에 대한 회의론에 대한 답

• Peter의 질문: "$200 all-you-can-eat 플랜이 아니라 API 종량제로 쓰는 회사는 어떻게 하나? (우버는 엔지니어 지출을 캡을 씌우고 있다)"
• Jared의 답 두 가지:
  1. 토큰 가격은 장기적으로 하락 추세 — 감가상각되는 비용이다.
  2. 더 중요한 건 ROI 극대화지 토큰 절약이 아니다. Cognition은 모델 랩과 독립적인 하니스이기 때문에 사용자가 돈을 더 쓰게 만들 유인이 없다 — 그저 최선의 결과를 내는 모델을 쓰게 할 뿐.
• 핵심 단서: "좋은(good)" 엔지니어링에 쓰는 돈은 언제나 가치가 있지만, 슬롭을 만드는 데 쓰는 돈은 아니다.
• Devon은 모델 선택 UI 자체가 없음 — 회사가 최적 모델로 자동 라우팅. 자체 모델 "Suite"(소프트웨어 엔지니어링 특화, 더 빠르고 저렴)도 보유.

7) Devon이 실제로 가장 잘 먹히는 곳: 브라운필드(레거시) 작업

• 그린필드(제로투원 신규 기능)보다 브라운필드(대규모 코드 마이그레이션, 테스트 커버리지 확충, 개발자들이 하기 싫어하는 궂은일)에서 진가를 발휘.
• 실제로 많은 대기업이 코드베이스를 이해하는 사람이 수천 명 중 10명뿐인 상황(코볼/메인프레임 등 레거시 기술)에 처해있고, 이런 현대화 작업에 Devon이 강점을 보임.

8) 자식 에이전트 팬아웃(fan-out)의 실제 활용 사례

• 데모: 랜딩 페이지 리디자인을 위해 10개의 자식 Devon 세션을 동시에 스핀업, 각각 독립적으로 리디자인 시안을 만들고 스스로 테스트.
• 실전 활용: 코볼→자바스크립트, 리액트 네이티브→스위프트 같은 대규모 코드베이스 마이그레이션.
• 팬아웃이 유용한 이유 두 가지: (1) 병렬화로 속도 향상, (2) 컨텍스트 윈도우를 작게 유지 — 각 에이전트가 좁고 명확한 범위에만 집중해서 테스트 가능한 단위로 작업을 쪼갤 수 있음.
• Cognition 내부 모델 트레이닝 팀은 실제로 "100개의 Devon을 동시에 띄워서" 뭔가를 찾는 작업도 한다고 언급.
• 자식 Devon들은 코드만 작성해서 반환하는 게 아니라 작성 → 실행 → 스크린샷 촬영 → 확인까지 하는 "완전한 팀원"처럼 행동 — 이것이 별도 스킬/프롬프트 없이 제품에 내장되어 있음.

계층 3 — 세부 사례, 데이터, 인용

• 직접 인용: "Let the model cook and don't try to push it in certain directions."
• 직접 인용: "We're not trying to replace coding. We're trying to build abundance of good software and really multiply an engineer."
• 직접 인용: "Perfect is always the enemy of complete."
• 직접 인용: "Done is better than perfect... you'll be surprised at how good these things are and how easy it is to get to 80%. And now the last mile is the hard part. And that's going to take a year."
• 직접 인용: "More Devons are being launched from other Devons or programmatically than by humans." (이번 달 발생한 전환점)
• 구체적 데모 장면: Jared가 만든 macOS Quick Look 마크다운 뷰어 프로젝트를 화면 공유로 시연. "Devon Test" 버튼을 눌러 실제 VM에서 통합 테스트(링크 클릭 등)를 실시간으로 수행하는 모습을 보여줌.
• 구체적 데모 장면 2: 마스터 Devon 세션에서 "10개의 자식 Devon 세션을 스핀업해서 각각 랜딩페이지 리디자인을 하나씩 만들게 하라"는 지시를 실시간으로 실행, 각 자식이 자기 VM에서 스크린샷을 첨부해 응답하도록 마스터가 메시지를 보내는 과정을 시연.
• 일화: 스타트업 CTO 사례 — 출근길 통근 중에 Devon 작업들을 시작시키고, 회사에 도착하면 리포를 pull해서 확인하거나 Devon이 찍은 영상을 보고 바로 푸시한다고 함.
• 일화: Jared 본인은 로컬 에이전트가 클라우드 에이전트를 스핀업하고 세션을 클라우드로 넘긴 뒤 다시 pull down해서 모니터링하는 하이브리드 방식을 사용.
• Devon의 부가 기능들: Knowledge/Playbooks/Macros/Skills (팀 간 지식 공유용), Ask(리포를 사전 인덱싱해 질문·플랜모드 지원 — 데모에서 OpenClaw 레포로 테스트한 사례 언급), Automations(외부 이벤트 트리거 연결), Deep Wiki(레포 문서 자동 생성 — 데모에서 "샌프란시스코 아파트 찾기" 개인 프로젝트 레포로 시연).
• 여담(라디오 광고 구간): Riverside(팟캐스트 녹화 툴) 스폰서 구간 — 4K 로컬 녹화, AI 필러워드 제거, 자동 클립 생성 등. (코드 프로모: petery, creators.side.com/peryang)
• 인용 — 게스트 소개: Peter Yang이 Jared를 "cognition의 building-in-residence"로 소개, 이전 경력은 PromptLayer(에이전트 관측/평가 툴).
• 인용 — 마무리 라디컬 의견: "I think humans are going to return to the world where we just have a wooden desk and we don't have this whole monitor setup and keyboard setup and mouse... I just want a button and a whisper flow."
• 인용 — 에이전트-퍼스트 프로덕트에 대한 논의: "I think everything can be reduced to an API endpoint or API call... there's no reason an agent can't build a house" — Jared는 에이전트가 API 호출의 연쇄만으로 집을 짓거나 마을을 운영하는 미래까지 상상.
• 게스트 연락처: X(Twitter) @iamjaredz, 제품: devin.ai / cognition.ai

계층 4 — 시사점 및 실행 포인트

1. 에이전트 제품을 만들 때 "특정 방향으로 미는" 정교한 프롬프트/DAG 구조에 과투자하지 마라. 모델 자체 능력 향상에 흡수될 지출이다. 대신 툴 엔지니어링(어떤 툴을 줄지)과 프롬프트는 "치트시트" 수준으로 가볍게 유지하고, 모델이 알아서 판단하게 맡길 것.
2. eval에 갇혀서 출시를 미루지 말 것. 결정론적 코드 시절의 습관(모든 경우의 수 테스트)을 에이전트에 그대로 적용하지 말고, 일단 80%까지 빠르게 만들고 배포한 뒤 사용자 반응을 보며 마지막 다듬기에 시간을 투자하라.
3. "에이전트가 스스로 자기 작업을 검증하게" 만들고 싶다면: (a) 에이전트에게 스스로 평가 시나리오/스모크 테스트를 만들게 하고, (b) 실행 결과를 마크다운 등 읽기 쉬운 형태로 남기게 하고, (c) 그 결과를 다시 에이전트가 읽고 이전/이후를 비교·판단하며 반복 개선하게 하는 루프를 설계하라. 사람은 이 루프가 어느 정도 무르익은 뒤 마지막 다듬기 단계에만 개입한다.
4. 마스터-자식 에이전트 오케스트레이션 패턴을 실무에 도입할 가치가 있다. 특히 대규모 마이그레이션, 대량의 테스트 커버리지 확충, 여러 개의 독립적 후보안(디자인 시안 등) 병렬 생성 작업에서 (1) 속도, (2) 컨텍스트 윈도우 관리 양쪽에서 이득이 크다.
5. 비동기·클라우드형 에이전트 워크플로우로 전환을 고려하라. 로컬에서 순차적으로 붙어있는 방식보다, 여러 작업을 동시에 백그라운드에서 돌리고 나중에 결과만 검토하는 방식이 실무 생산성을 크게 높인다.
6. 토큰/비용에 대한 판단 기준은 "절약"이 아니라 "ROI". 진짜 좋은 엔지니어링 작업(레거시 마이그레이션, 반복적 궂은일 자동화 등)에 쓰는 비용은 아끼지 말고, 대신 "슬롭"을 양산하는 데는 쓰지 말 것 — 사람의 최종 검수(마지막 10%)가 그 경계를 가른다.
7. 자기 제품이 "에이전트 우선(agent-first)" 소비 방식에 잠식될 가능성을 미리 고민하라. 사용자가 웹사이트가 아니라 자신의 에이전트를 통해 API로만 제품을 소비하게 되면 브랜드/고객 관계가 희석될 수 있다는 문제의식은 아직 업계 전체가 답을 찾지 못한 열린 질문 — SaaS/프로덕트 팀이라면 지금부터 "에이전트에게 어떻게 브랜드를 각인시킬지" 고민을 시작할 필요가 있다.
8. 브라운필드(레거시/유지보수) 작업이야말로 에이전트의 진짜 승부처일 수 있다. 그린필드 신규 기능 개발에만 에이전트를 투입하기보다, 코드베이스를 아는 사람이 부족한 레거시 시스템 현대화·마이그레이션·테스트 커버리지 확충에 우선 투입하는 전략을 검토할 것.