How Claude Code Works - Jared Zoneraich, PromptLayer
강연자 소개
Jared Zoneraich는 AI 엔지니어링을 위한 워크벤치 플랫폼인 PromptLayer의 창업자다. PromptLayer는 뉴욕에 기반을 둔 팀으로, 3년 전 제품을 출시하여 현재 하루에 수백만 건의 LLM 요청을 처리하고 있다. 그들의 핵심 철학은 엄격한 프롬프트 엔지니어링과 에이전트 개발에 있으며, 제품팀과 엔지니어링팀, 그리고 도메인 전문가가 함께 협업해야 한다고 믿는다.
Jared는 Claude Code의 열성적인 사용자로, 그의 팀은 엔지니어링 조직을 Claude Code를 중심으로 재편성했다. 그들의 규칙은 간단하다: “Claude Code를 사용해 1시간 이내에 완료할 수 있는 작업이라면, 우선순위를 정하지 말고 그냥 실행하라.” 이 강연은 Anthropic의 공식 지원을 받지 않았지만, 코딩 에이전트가 어떻게 작동하는지에 대한 깊은 기술적 통찰을 제공한다.
코딩 에이전트의 역사: 왜 지금 폭발적으로 성장했는가
진화의 과정
코딩 에이전트의 여정은 ChatGPT에서 코드를 복사-붙여넣기하는 단순한 워크플로우에서 시작되었다. 초기 Cursor는 단순히 VS Code 포크에 Command K 기능을 추가한 수준이었고, 품질도 그리 좋지 않았다. 이후 Cursor Assistant가 등장했고, 마침내 Claude Code가 헤드리스(headless) 방식의 새로운 워크플로우를 선보였다. 이는 개발자가 코드를 직접 만지지 않고도 작업을 완료할 수 있는 수준까지 발전한 것이다.
혁신의 핵심: 무엇이 달라졌는가
코딩 에이전트가 마침내 제대로 작동하게 된 이유는 크게 두 가지로 요약된다:
1. 단순한 아키텍처(Simple Architecture)
과거의 복잡한 워크플로우와 과도한 최적화를 버리고, 모델에 도구(tools)를 제공한 뒤 방해하지 않는 방식이다. “Give it tools and then get out of the way”라는 원칙은 모든 엔지니어가 가진 과최적화(over-optimization) 성향을 경계한다. 모델은 이미 tool calling에 최적화되어 훈련되고 있으므로, 스캐폴딩(scaffolding)을 줄이고 모델에 더 많이 의존하는 것이 핵심이다.
2. 더 나은 모델(Better Models)
솔직히 말해, 많은 혁신은 단순히 Anthropic이 더 나은 모델을 출시했기 때문이다. Tool calling에 특화되고, 자율적으로 실행되는 데 최적화된 모델들이 계속 발전하고 있다. Anthropic이 말하는 “AGI Pill” 사고방식은 오늘날 모델의 결함을 우회하려는 과도한 엔지니어링을 지양하라는 것이다. 왜냐하면 많은 것들이 자연스럽게 개선될 것이기 때문이다.
Claude Code의 설계 철학
Claude Code는 임베딩(embeddings), 분류기(classifiers), 패턴 매칭을 무시한다. RAG(Retrieval-Augmented Generation) 같은 복잡한 패러다임 대신, 더 나은 모델을 만들고 그것이 스스로 작동하도록 둔다. RAG 대신 grep을 사용하는 것이 그 예시다. 이는 매우 최적화된 tool calling 모델을 기반으로 한다.
Python의 Zen에서 가져온 철학이 이를 잘 설명한다:
- Simple is better than complex (단순함이 복잡함보다 낫다)
- Complex is better than complicated (복잡함이 난해함보다 낫다)
- Flat is better than nested (평평함이 중첩보다 낫다)
이것이 Claude Code가 작동하고 특히 잘 작동하는 이유의 전부다. 데이터베이스 스키마를 설계하든 자율 코딩 에이전트를 만들든, 단순한 설계가 더 나은 설계라는 엔지니어링 원칙으로 돌아간 것이다.
Claude Code의 핵심 구성 요소
Constitution: Claude.md 파일
Claude Code는 claude.md 파일(다른 에이전트는 agents.md를 사용)을 사용한다. 이것의 흥미로운 점은, 모델이 먼저 레포지토리를 조사하는 과도하게 엔지니어링된 시스템이 필요 없다는 팀의 판단이다. Cursor 1.0은 로컬에서 벡터 DB를 만들어 레포지토리를 이해하는 등 많은 연구를 수행했지만, Claude Code는 단순히 마크다운 파일을 두고 사용자나 에이전트가 필요할 때 변경하도록 한다.
이는 매우 단순하며, 결국 프롬프트 엔지니어링(또는 컨텍스트 엔지니어링)으로 귀결된다. 범용 모델을 특정 용도에 맞게 조정하는 방법에서 가장 단순한 답이 최선의 답이다.
Master Loop: 시스템의 핵심
Claude Code의 핵심은 단순한 마스터 루프다. 이는 과거 에이전트 구축 방식과 비교하면 거의 혁명적이다. 모든 현대 코딩 에이전트(Codex, 새로운 Cursor, AMP 등)는 tool calls가 있는 하나의 while 루프일 뿐이다.
# Claude Code의 마스터 루프 (의사코드)
while there_are_tool_calls:
tool_results = run_the_tool()
give_tool_results_to_model(tool_results)
# 반복
# tool calls가 없으면 사용자에게 다음 행동을 묻는다내부적으로 “N0”라고 불리는 이 루프는 4줄로 표현된다. Tool calling을 처음 사용했을 때 가장 충격적이었던 것은 모델이 언제 도구를 계속 호출해야 하고 언제 실수를 수정해야 하는지 매우 잘 안다는 점이다. LLM의 가장 흥미로운 특징 중 하나는 실수를 수정하고 유연하게 대응하는 능력이다. 모델이 탐색하고 스스로 알아내도록 더 많이 의존할수록, 더 나은 모델이 나왔을 때 시스템이 더 강력하고 견고해진다.
핵심 도구들(Core Tools)
Claude Code의 도구들은 매일 변하지만, 가장 흥미로운 핵심 도구들은 다음과 같다:
Read
단순히 cat 명령을 사용할 수도 있지만, 토큰 제한이 있기 때문에 read 도구를 구축할 가치가 있다. Claude Code를 많이 사용해본 사람은 때때로 “이 파일은 너무 크다”는 메시지를 본 적이 있을 것이다.
Grep/Glob 이것은 매우 흥미롭다. 당시의 RAG와 벡터 사용에 대한 많은 통념에 반하기 때문이다. RAG가 자리가 없다는 것은 아니지만, 범용 에이전트에서는 grep이 좋고, grep은 사용자가 사용하는 방식이다. 여기서 중요한 상위 레벨 포인트는: 이 모든 도구들은 인간의 작업이라는 것이다. 모델이 사용할 완전히 새로운 도구를 만드는 게 아니라, 터미널에서 문제를 해결하려는 당신이나 나의 행동을 모방하는 것이다.
Edit Edit에서 흥미로운 점은 diff를 사용하며 대부분의 경우 파일을 다시 작성하지 않는다는 것이다. 훨씬 빠르고, 사용하는 컨텍스트가 적으며, 문제도 훨씬 적다. 슬라이드를 검토해달라고 요청받았을 때, 슬라이드를 읽고 모든 수정 사항을 새로 작성하는 것과 종이에서 그냥 내용을 지우는 것 중 어느 것이 더 쉬울까? 지우는 것이 훨씬 쉽다. Diff는 실수를 방지하는 자연스러운 방법이다.
Bash: 가장 중요한 도구 Bash는 핵심이다. 솔직히 말하면, 이 모든 도구를 제거하고 bash만 남겨도 될 것이다. Claude Code가 Python 파일을 생성하고, 실행하고, 삭제하는 것을 처음 봤을 때, 이것이 바로 작동하는 이유의 아름다움이다.
Bash가 코딩 에이전트에 놀라운 두 가지 이유:
- 단순하고 모든 것을 할 수 있다 - 매우 견고하다
- 엄청난 학습 데이터 - 우리가 사용하는 것이기 때문에 학습 데이터가 많다
Bash는 진정한 유니버설 어댑터다. 수천 개의 도구가 있고 무엇이든 할 수 있다. 로컬 환경을 구축할 때 Claude Code를 사용하면, 보통 어딘가 파일에 적어둔 5개의 명령어(그리고 나중에 오래되어버린)를 사용하던 방식 대신, 에이전트가 알아서 처리한다.
WebSearch/WebFetch 흥미로운 점은 이들이 더 저렴하고 빠른 모델로 이동한다는 것이다. 예를 들어, 플랫폼에서 어떤 에이전트를 구축하고 일부 엔드포인트 목록에 연결해야 한다면, 마스터 while 루프 대신 서브 티어로 가져오는 것이 가치 있을 수 있다.
To-dos 모델을 궤도에 유지하고 조향성(steerability)을 제공한다.
Tasks 매우 흥미롭다. 컨텍스트 관리에 관한 것이다. 컨텍스트를 어지럽히지 않고 긴 프로세스를 실행하고 전체 파일을 읽는 방법이다. 왜냐하면 가장 큰 적은 컨텍스트가 가득 차면 모델이 멍청해지기 때문이다.
도구 사용 제안
모델에게 어떤 도구를 언제 사용할지 알려주는 시스템 프롬프트가 있다. 이것은 자주 변하지만, 모델이 막히는 엣지 케이스와 모서리들이다:
- 편집 전 읽기 - 실제로 이것을 강제한다
- Bash 대신 grep 도구 사용 - 도구 목록에 특별한 grep 도구가 있다. 이유는 여러 가지일 수 있는데, 보안과 샌드박싱이 큰 이유이고, 토큰 제한도 있다
- 독립적인 작업을 병렬로 실행 - 모델이 이를 더 많이 하도록 유도한다
- 공백이 있는 경로에 따옴표 사용 - Anthropic이 dogfooding하면서 발견하고 시스템 프롬프트에 추가한 일반적인 것들이다
To-do Lists: 구조화되지만 강제되지 않는 구조
To-do list는 일반적인 것이지만 예전에는 일반적이지 않았다. 정말 흥미로운 점은 구조화되어 있지만 결정론적으로 강제되지 않는다는 것이다.
규칙들:
- 한 번에 하나의 작업
- 완료되면 표시
- 블록이나 오류가 있으면 진행 중인 작업을 계속 진행
- 작업을 서로 다른 지시사항으로 나눔
가장 흥미로운 점은 이것이 결정론적으로 강제되지 않는다는 것이다. 순전히 프롬프트 기반이고, 시스템 프롬프트에만 있으며, 모델이 이제 지시 따르기를 잘하기 때문이다. 이것은 1년 전에는 작동하지 않았을 것이고, 2년 전에는 더욱 불가능했을 것이다.
시스템 프롬프트 상단에 도구 설명이 있고, to-do를 시스템 프롬프트에 주입하지만, 실제 코드에서는 강제되지 않는다. 다른 에이전트들이 반대 경로를 택할 수도 있지만, 사용자로서 큰 차이를 만드는 것이 거의 주말 프로젝트처럼 구현하기 간단해 보이면서도 효과적이라는 점이 흥미롭다.
// To-do 구조 예시
{
version: "1.0",
todos: [
{
id: "hash_12345",
title: "Fix authentication bug",
status: "in_progress",
evidence: { /* 임의의 데이터 블롭 */ }
}
]
}To-do의 네 가지 이점:
- 계획을 강제함 - 모델이 계획을 세우도록 만든다
- 크래시 후 재개 - Claude Code가 실패해도 재개할 수 있다
- UX - 사용자로서 진행 상황을 알 수 있다. 40분 동안 신호 없이 루프를 돌지 않는다
- 조향성(Steerability) - 작업 방향을 조정할 수 있다
후드 아래: 고급 메커니즘
Async Buffer (H2A) IO 프로세스와 추론(reasoning)을 분리하는 방법, 그리고 터미널에서 보는 모든 것을 그냥 모델에 채워넣지 않고 컨텍스트를 관리하는 방법이다. 컨텍스트는 우리의 가장 큰 적이다. 모델을 더 멍청하게 만든다. 압축(compaction)과 요약(summarization)을 어떻게 하는지에 대해 조금 똑똑해야 한다.
용량에 도달하면 중간을 버리고 head와 tail을 요약한다. 컨텍스트 압축기는 약 92% 정도의 한계를 가진다.
장기 저장소(Long-term Storage) Bash와 샌드박스를 가지는 것의 또 다른 장점이다. 모든 ChatGPT 윈도우, 모든 Claude 윈도우가 가까운 미래에 샌드박스와 함께 제공될 것이라고 예측한다. 장기 메모리를 저장할 수 있어 훨씬 낫다.
Jared는 항상 이렇게 한다. 심층 연구 등을 위한 Claude Code 스킬이 있고, 항상 마크다운 파일을 저장하라고 지시한다. 컨텍스트가 짧을수록 더 빠르고 똑똑하기 때문이다.
Subagents: 컨텍스트 관리의 핵심
컨텍스트 관리와 계속 돌아가는 문제, 즉 컨텍스트가 길어질수록 에이전트가 멍청해지는 문제에 대한 답이다. 특정 작업에 서브에이전트를 사용하고, 핵심은 서브에이전트가 자체 컨텍스트를 가지며 결과만 피드백한다는 것이다. 이렇게 해야 어지럽히지 않는다.
예시 서브에이전트:
- Researcher (연구자)
- Docs reader (문서 리더)
- Test runner (테스트 러너)
- Code reviewer (코드 리뷰어)
// Task 도구 사용 예시
Task({
description: "Find default chat context instantiation",
prompt: `긴 문자열로, 코딩 에이전트가 자체 에이전트를 프롬프팅한다.
모델에 의존하면, 작업이 오류를 반환하면 더 많은 정보를
이 문자열에 채워넣고 문제를 해결하도록 한다.
유연함이 경직됨보다 낫다.`
})질문: 서브에이전트는 메인 에이전트의 컨텍스트를 받는가?
Task는 tool call이다. Tool call 구조는 메인 에이전트에 있다. Description과 prompt는 실시간으로 생성된다. 작업을 실행하려 할 때 설명과 프롬프트를 생성한다. 작업들은 병렬로 실행될 수 있고 결과를 반환한다.
System Prompt 분석
Claude Code 시스템 프롬프트의 온라인 유출본을 기반으로 한 주목할 점들:
- 간결한 출력 - 너무 긴 것을 주지 않음
- “I will just do the task” - 사용자가 원하는 작업을 그냥 수행. 텍스트 설명 대신 도구를 더 많이 사용하도록 유도
- 기존 코드와 일치 - 주석을 추가하지 않음 (이것은 Jared에게는 잘 작동하지 않는다고 함)
- 병렬로 명령 실행 - 광범위하게 활용
- To-do 등
흥미로운 점은 많은 것들이 누군가 Claude Code를 사용하다가 “이것만 조금 덜 하거나 조금 더 했으면”이라고 말한 것에서 나온 것처럼 보인다는 것이다. 프롬프팅이 등장하는 지점이다. 반복하기 매우 쉽고 엄격한 요구사항이 아니기 때문이다.
Skills: 확장 가능한 시스템 프롬프트
Skills는 훌륭하다. 비교적 최근에 생겼고, Jared는 최근에야 이것에 확신하게 되었다. 이 슬라이드도 스킬로 만들었다. 아키텍처 관점에서 보면 확장 가능한 시스템 프롬프트라고 생각할 수 있다.
컨텍스트를 어지럽히고 싶지 않은 것처럼, 훨씬 더 많은 컨텍스트를 원하는 다양한 유형의 작업들이 있다. 이것이 Claude Code에 더 많은 정보를 활용할 수 있는 몇 가지 옵션을 제공하는 방법이다.
예시:
- Docs updates - 작성 스타일과 제품을 알려줌
- Microsoft Office 편집 - Word와 Excel 파일을 디컴파일함
- Design style guide - 일반적인 스킬
- Deep research - 논문이나 GitHub 레포를 던져주고 “이것을 Claude Code 스킬로 재구축해”라고 하면 놀랍도록 잘 작동함
주의사항: Skills의 한계
Claude Code는 Claude MD가 40k 자를 초과하면 노란색 텍스트로 경고한다. 그래서 스킬로 나누었더니 Claude가 모든 스킬을 무시했다는 사용자 피드백이 있었다. 이는 시스템 프롬프트 문제일 수 있다. 각 스킬에 대한 설명을 모델에 제공해야 하는데, 완벽한 세계에서는 모든 스킬을 항상 선택해야 한다. 하지만 현실에서는 보통 스킬을 수동으로 호출해야 한다.
이것은 프롬프팅이 올바른 솔루션인지, DAG가 올바른 솔루션인지, 아니면 모델 훈련 문제인지에 대한 좋은 사례다. 모델이 스킬을 호출하는 시점을 아는 것은 거의 tool call을 호출하는 것과 같다. 패러다임은 매우 흥미롭지만 아직 완벽하지는 않다.
Unified Diffing: 속도와 정확성
Unified diffing은 매우 명백하다. 너무 많이 이야기할 필요는 없지만, 이것이 훨씬 낫게 만든다. 토큰 제한을 짧게 만들고, 더 빠르게 만들고, 실수를 덜 발생시킨다. 에세이를 다시 쓰는 것과 빨간 선으로 표시하는 것의 차이다.
어떤 에이전트를 만들든 diffing을 사용하는 것을 강력히 권장한다. Unified diff는 표준이다. 많은 코딩 에이전트를 조사했을 때, 일부는 줄 번호가 항상 필요한 것은 아니기 때문에 unified diff의 약간 변형된 자체 표준을 구축했다. 하지만 unified diff는 작동한다.
DAG를 필요 없게 만드는 패러다임 전환
과거: 복잡한 DAG 구조
지난 2~2.5년 동안 모든 사람이 이런 식으로 DAG를 구축했다. 고객 지원 에이전트를 예로 들면, 수백 개의 노드가 있었다. “사용자가 환불을 원하면 이 프롬프트로 라우팅하고, 이것을 원하면…” 하는 식이었다. 많은 분류 프롬프트가 있었다.
DAG의 장점:
- 환각이 발생하지 않을 것을 보장할 수 있음
- 환불을 받아선 안 되는 사람에게 환불이 가지 않도록 보장
- 프롬프트 인젝션 문제를 해결 - X 또는 Y로만 분류하는 프롬프트에서는 인젝션이 크게 중요하지 않음
현재: 모델에 의존하라
이제 우리는 공격 벡터를 다시 가져오지만, 주요 이점은 이 엔지니어링 광기의 웹을 다룰 필요가 없다는 것이다. 개발하기 10배 쉽고, 유지보수하기 10배 쉬우며, 모델이 이제 좋기 때문에 실제로 훨씬 더 잘 작동한다.
핵심 교훈: 의심스러우면 모델에 의존하라
모든 엣지 케이스를 생각하고 모든 if 문을 생각하려고 하지 마라. 그냥 모델이 탐색하고 알아내도록 의존하라.
실제 사례
Jared는 브라우저 에이전트를 실험하면서 모든 버튼에 작은 타이틀을 추가하면 에이전트가 웹사이트를 자동으로 더 잘 탐색할 것이라고 생각했다. 놀랍게도 오히려 더 나빠졌다. “이 버튼을 클릭해야 한다”고 알려주면서 에이전트가 주의가 산만해져서 무엇을 해야 할지 몰랐기 때문이다. 탐색에 의존하는 것이 더 낫다.
질문: 스캐폴딩 vs AGI Pill의 균형
질문: “우리가 오늘 만드는 모든 스캐폴딩은 3~6개월 후면 쓸모없어질 것이다. 그렇다 해도 오늘은 조금 도움이 된다. 오늘만 있는 문제를 해결하기 위해 낭비되는 엔지니어링을 어떻게 균형잡는가?”
답변: 케이스 바이 케이스다. 무엇을 만드느냐에 달려 있다. 은행을 위한 챗봇을 만든다면 아마 조금 더 조심해야 할 것이다.
행복한 중간 지점은 마스터 while 루프와 tool calls의 에이전트 패러다임을 사용하되, tool calls를 매우 엄격하게 만드는 것이다. Claude Code가 read나 grep을 tool call로 사용하는 것처럼, 매우 구체적인 출력 형식이 필요한 경우(특정 이메일 형식이나 블로그 포스트 등) 엣지 케이스를 위해 구조화된 도구로 만들고 버전 관리와 평가를 할 수 있게 한다.
탐색 단계에서는 모델에 맡기거나 시스템 프롬프트를 추가한다. 트레이드오프이며 사용 사례에 매우 의존적이다.
미래 전망: What’s Next?
1. Tool Calls의 미래: 많은가 적은가?
학파 1: 수백 개의 Tool Calls 많은 사람들이 하나의 마스터 루프에 수백 개의 tool calls를 가질 것이라고 생각한다. Tool calling이 훨씬 더 나아질 것이라는 견해다. 이것은 매우 가능성이 높다.
학파 2 (Jared의 견해): 최소화 Tool call을 최대한 줄이고 bash로 돌아가는 것이다. 심지어 스크립트를 로컬 디렉토리에 넣는 것도 고려한다. Jared는 수백 개가 아닌 하나의 메가 tool call(실제로는 몇 개) 지지자다. 많은 사람들이 수백 개가 필요하다고 생각하지만, 그는 그렇게 가지 않을 것이라고 본다.
2. Adaptive Budgets: 추론 조정
추론을 조정하는 것이다. “Thinking”, “Ultra think” 같은 것을 조금 하고 있지만, reasoning models를 도구로 사용하는 것이 많은 의미가 있다.
우리 중 많은 사람들이 20배 빠른 모델에 약간 덜 똑똑한 결과를 선택하고, 매우 좋은 모델을 위한 tool call을 호출할 수 있는 트레이드오프를 할 것이다. 플래너(planner)에서는 그렇지 않을 수 있다. 새로운 Opus가 나올 때 GPT 5.1 Codex나 Opus로 먼저 플래너에 갈 수도 있다. 하지만 많은 믹싱 매칭을 할 수 있고 이것이 다음 프론티어다.
3. 새로운 First-class 패러다임
To-do list에서 배울 수 있는 것이 많고, 구축할 수 있는 새로운 first-class 패러다임이 많다고 생각한다. Skills도 우리가 구축하려는 first-class 패러다임의 또 다른 예다. 완벽하게 작동하지 않을 수도 있지만, 거기서 많은 새로운 발견을 할 수 있다.
다른 프론티어 에이전트들과의 비교
AI Therapist Problem: 글로벌 맥시멈은 없다
Jared가 “AI Therapist Problem”이라고 부르는 개념이 있다. 가장 흥미로운 AI 문제들 주변에는 글로벌 맥시멈이 없다고 믿는다.
뉴욕에 있다면, 치료사를 만나야 할 때 모든 블록에 6명씩 있다. 최고의 치료사가 무엇인지에 대한 글로벌 답은 없다. 명상을 하는 치료사, CBT를 하는 치료사, 아야와스카를 주는 치료사 등 서로 다른 전략들이 있다. 이것들은 같은 목표를 위한 다른 전략일 뿐이다. AI 치료사를 만든다면 글로벌 맥시멈이 없다.
이것은 일종의 반(anti)-AGI 견해이지만, 애플리케이션을 구축할 때 취향이 많이 관여하고 설계 아키텍처가 많이 중요하다고 말하는 견해이기도 하다. 5개의 서로 다른 코딩 에이전트가 모두 놀라울 수 있다.
오늘날, 어느 것이 최고인지 아무도 모른다
Anthropic도 모르고, OpenAI도 모르고, Sourcegraph도 모른다. 하지만 어떤 것들은 특정 것에 더 낫다. Jared는 개인적으로 로컬 환경을 실행하거나 Git을 사용하거나 앞뒤로 필요한 인간 행동에 Claude Code를 좋아한다. 하지만 어려운 문제는 Codex로 가고, Cursor의 Composer는 빠르기 때문에 사용한다.
기본적으로 여기에 서로 다른 철학을 가지는 것에 가치가 있다. 하나의 승자가 될 것이라고 생각하지 않는다. 서로 다른 사용 사례에 대한 서로 다른 승자가 있을 것이다. 이것은 코딩 에이전트만이 아니다. 모든 AI 제품이다.
각 에이전트의 관점
Claude Code
- 사용자 친화성과 단순성
- Git 작업에 최고
- PR을 만들고 싶으면 Claude Code로
Codex
- 컨텍스트 관리가 정말 좋음
- 강력하게 느껴짐
- 더 강력하다는 증거가 있는가? 아마 없지만, 그렇게 느껴짐
Cursor
- IDE 관점
- 모델 애그노스틱(agnostic)
- 더 빠름
Factory (Droid)
- 다중 특화된 Droid 서브에이전트
- DAG 또는 모델 훈련 대화일 수 있음
Cognition (Devin)
- 엔드투엔드 자율성
- 자기 반성(self-reflection)
AMP (Sourcegraph)
- 무료
- 모델 애그노스틱
- 사용자를 위한 많은 UX 슈가
- 독특한 관점들
Codex 상세 분석
Claude Code와 매우 유사하다. 대부분이 그러는데, 그것이 승리하는 아키텍처이기 때문이다. 흥미롭게도:
기술적 차이점
- Rust 코어
- 오픈소스 - Codex를 사용해서 Codex가 어떻게 작동하는지 이해할 수 있음
- 조금 더 이벤트 드리븐
- 동시 스레딩에 더 많은 작업
- Submission queues, event outputs
- Claude Code의 IO buffer와 비슷하지만 조금 다르게 수행
샌드박싱
- 매우 다름
- macOS Seatbelt과 Linux Lambda
- 더 커널 기반
실제 차이 솔직히 말하면, 모델이다. Jared는 실제로 Claude Code를 사용해서 Codex가 어떻게 작동하는지 연구했다. 항상 재미있는 일이다.
AMP (Sourcegraph) 상세 분석
독특한 특징들
1. 무료 티어 공급자로부터 초과 토큰을 활용하고 광고를 제공한다. PromptLayer도 거기에 광고가 있다. Jared는 pro-광고다. 많은 사람들이 anti-광고지만, 그의 핫테이크 중 하나다.
2. 모델 선택기 없음 이것은 매우 흥미롭다. 자체적인 관점이다. 여기저기서 모델을 전환할 수 있다는 것을 알기 때문에 출력에 대한 정확한 기대가 덜하다. 이것은 개발 방식을 변경한다.
3. 비전: 에이전트 친화적 환경 가장 좋은 에이전트만 만드는 것이 아니라, 가장 많은 에이전트 친화적 환경에서 작동하는 에이전트를 어떻게 만드는가? Factory도 비슷한 이야기를 했다. 에이전트가 테스트를 실행할 수 있는 밀폐된(hermetically sealed) 코딩 레포를 어떻게 만드는가? 피드백 루프를 어떻게 만드는가? 이것이 일종의 성배다. 자율 에이전트를 만드는 방법이다.
컨텍스트 관리: Handoff
우리 모두 Compact에 익숙하다. 최악이다. 10분을 기다려야 한다. 왜 그렇게 오래 걸리는지 모르겠다. 익숙하지 않다면, 컨텍스트가 너무 높아지면 채팅 윈도우를 요약하고 요약을 제공하는 것이다.
AMP는 “handoff”라는 것이 있다. Call of Duty 플레이어였던 사람이라면 생각나게 한다. “Switch weapons. It’s faster than reloading.” 그것이 handoff다. 새 스레드를 시작하고 새 스레드에 필요한 정보를 제공하는 것이다.
이것이 Jared가 보기에 승리 전략처럼 느껴진다. 틀릴 수도 있지만, 아마 둘 다 필요할 수도 있다. 그들은 그쪽으로 밀고 있고, 마음에 든다. 매우 신선한 관점을 제공한다.
모델 선택: Fast, Smart, Oracle
추론 노브와 그것에 대한 견해다. Fast, Smart, Oracle이 있다. 다른 모델들이 있다는 것에 더 크게 의존한다. Oracle이 무엇인지 말하지 않는다(실제로는 말하지만). Oracle을 전환할 의향이 있다. 하지만 매우 어려운 문제가 있을 때 Oracle을 사용할 것이다.
Cursor Agent 상세 분석
Cursor의 에이전트는 매우 흥미로운 관점을 가지고 있다.
핵심 특징
1. UI First, not CLI CLI가 있을 수도 있지만 확실하지 않다. UI가 흥미로운 부분이다.
2. 속도: Composer 새로운 모델 Composer가 너무 빠르다. Distilled되어 있다. 데이터를 가지고 있다. Jared의 의견으로는, 실제로 사람들을 다시 fine-tuning에 관심 갖게 만들었다. Fine-tuning을 고객에게 권장하지 않았었는데, Composer는 데이터를 기반으로 실제로 방어 가능성을 구축할 수 있다는 것을 보여준다. 놀랍다.
출시 이후 거의 완전히 Composer로 전환했다. 너무 빠르다. 거의 너무 빨라서 개인 프로젝트 중 하나에서 실수로 master에 푸시했다. 항상 원하는 것은 아니다.
3. 점진적 구축 Cursor는 군중의 선호를 받고 있고, 팀에 많은 찬사를 보낸다. 점진적으로 구축했다. Cursor의 첫 번째 버전은 너무 나빴다. VS Code 포크라서 잃을 게 없어서 사용했는데, 너무 좋아졌다. 훌륭한 소프트웨어이고 훌륭한 팀이다.
OpenAI의 Codex 모델도 마찬가지다. 꽤 빠르지는 않지만 이 코딩 에이전트에 최적화되어 있고 distilled되어 있다. OpenAI도 데이터를 가지고 있기 때문에 정말 빠른 모델을 내놓을 것이라고 볼 수 있다.
철학을 보여주는 그림 Cursor가 블로그에 올린 그림을 보면, 사용하는 세 가지 모델을 보여준다. Composer를 제공하지만, GPT 5.1(또는 5)이 플래닝에 더 나을 수 있다는 것을 알기 때문에 최신 모델을 사용하도록 허용한다.
평가(Evaluation)의 문제
어느 것을 사용해야 하는가?
큰 질문이 여기 있다. 어느 아키텍처가 최고인가? 무엇을 해야 하는가?
벤치마크는 거의 쓸모없다
벤치마크는 많은 모델 제공자들에게 마케팅이 되었다. 모든 모델이 벤치마크를 이긴다. 어떻게 그런 일이 일어나는지 모르겠다. Eval이 중요한 세계가 있고, 문제는 무엇을 eval할 수 있는가다.
단순한 while-loop 아키텍처의 역설
Jared가 이해를 바탕으로 밀어붙이려고 한 가장 단순한 simple while-loop 아키텍처가 실제로 eval하기 더 어렵게 만든다. 모델 유연성에 더 의존한다면 어떻게 테스트하는가?
Evaluation 전략
1. End-to-end 테스트 통합 테스트, 엔드투엔드 테스트를 실행하고 문제를 해결하는지 확인한다.
2. Point-in-time 스냅샷 중간에서 챗봇에 컨텍스트를 제공하여, 특정 tool call을 실행해야 한다는 것을 알고 있는 반쯤 끝난 대화에서 실행할 수 있다.
3. Backtest 에이전트를 실행하고 몇 번이나 도구를 호출하는지, 몇 번이나 재시도하는지, 얼마나 걸리는지 본다.
Agent Smell Jared가 “agent smell”이라고 부르는 또 다른 개념도 개발되기 시작했다. 에이전트를 실행하고:
- 몇 번이나 tool call을 호출하는가?
- 몇 번이나 재시도하는가?
- 얼마나 걸리는가?
표면 수준 메트릭이지만 정신 건강 체크에 정말 좋다. 이것들은 eval하기 어렵다. 많은 것이 들어간다.
멘탈 모델
- End-to-end 테스트
- Point-in-time 테스트
- Backtest - 가장 자주 추천. 히스토리컬 데이터를 캡처하기 시작하고 재실행
실제 예시: PromptLayer에서의 Eval
# Claude Code Headless Eval
Provider | Task
---------|------
OpenAI | Search web for model provider, find most recent/largest model, return name
Anthropic| ...
Google | ...웹 검색을 수행하고, 웹 검색은 신경 쓰지 않는다. 이것은 엔드투엔드 테스트다. Claude Code를 시도하고, headless SDK를 워크플로우에 넣는 것에 대한 많은 것이 있다.
주요 테이크어웨이는 엔드투엔드 테스트를 시작할 수 있다는 것이다. 높은 수준에서 model smell로 볼 수 있고, 각 행의 통계를 보고 몇 번이나 도구를 호출했는지 볼 수 있다.
엄격한 도구(Rigorous Tools)
이 이야기에서 많이 이야기했지만, 엄격한 도구. 도구는 엄격하게 테스트될 수 있다. 함수처럼 보면 된다. 입력과 출력이다.
도구가 실행되는 서브에이전트라면, 일종의 재귀에 있는 것이므로 다시 돌아가서 엔드투엔드를 테스트해야 한다. 하지만 도구에 대해서는, 예를 들어:
매우 구체적으로 출력하고 싶은 것이 있다면(특정 이메일 형식이나 블로그 포스트 등), 모델 탐색에 의존하고 싶지 않다. 엄격하게 테스트할 수 있는 도구를 실제로 만들고 싶다.
# 이메일 생성 워크플로우
Input → LLM Draft → Assertion (Good?)
↓ No
Revision (Add missing parts)
↓ Yes
Output매우 구체적인 비전이 있는 것들에 대해서는 테스트하는 것이 훨씬 쉬워진다. 덜 유연하기 때문에 이런 종류의 워크플로우를 테스트하는 것이 더 적은 단계를 가지기 때문이다.
Headless Claude Code SDK의 미래
앞으로를 내다보며, headless Claude Code SDK를 주시하라. 이번 아침에 이에 대한 강연이 있었다. 놀랍다. 단순한 프롬프트만 주면 파이프라인의 또 다른 부분일 뿐이다.
실제 사용 사례 Jared는 매일 문서를 업데이트하는 GitHub 액션이 있다. 다른 레포에 푸시한 모든 커밋을 읽고 - 많은 커밋이 진행 중이다 - Claude Code를 실행한다. Claude Code는 모든 레포를 pull down하고, 무엇이 업데이트되었는지 확인하고, Claude MD를 읽어 문서를 업데이트해야 하는지 확인한 다음 PR을 생성한다.
질문: 이것을 리뷰하는가? 그렇다. PR을 생성하는 것이지 PR을 병합하지 않는다.
이것은 많은 것을 열어준다고 생각하며, 더 높은 추상화 순서로 에이전트를 만들기 시작하고, 많은 하네스와 오케스트레이션을 하기 위해 Claude Code와 다른 에이전트들에 의존할 가능성이 있다.
핵심 테이크어웨이
1. 모델을 신뢰하라 (Trust in the Model)
의심스러울 때 에이전트를 만들 때 모델에 의존하라.
2. 단순한 설계가 승리한다 (Simple Design Wins)
첫 번째와 두 번째는 함께 간다.
3. Bash가 전부다 (Bash is All You Need)
도구를 단순하게 가져가라. 40개 도구가 아니라 10개 또는 5개 도구.
4. 컨텍스트 관리가 중요하다 (Context Management Matters)
이것은 이 시점에서 에이전트에서 항상 도망치고 있는 부기맨이다. 미래에 컨텍스트에서 훨씬 더 나은 새로운 모델이 있을 수 있지만, 항상 제한이 있을 것이다. 인간과 이야기하고 있기 때문이다. 하루에 너무 많은 사람을 만나면 이름을 잊는다. 그것이 컨텍스트 관리다. 아니면 내 멍청함일까?
5. 에이전트에서 서로 다른 관점이 중요하다 (Different Perspectives Matter in Agents)
엔지니어링 두뇌는 항상 이것을 충분히 이해하지 못한다. 특히 엔지니어이므로 자신에 대해서도 이야기하는 것이다. 서로 다른 관점이 중요하다.
문제를 해결하는 서로 다른 방법들이 있는데 하나가 다른 것보다 낫지 않다. 아마 믹스처 오브 엑스퍼츠(mixture of experts) 에이전트를 원할 것이다. Claude Code와 Codex와 이것들을 실행하고 출력을 주고 팀으로 간주하고 Slack 기반 메시지 채널에서 서로 대화하게 하고 싶다. 누군가 그것을 만들기를 기다리고 있다. 훌륭할 것이다.
보너스: 이 슬라이드를 Claude Code로 만든 방법
Jared는 실제로 이 발표 슬라이드를 Claude Code를 사용해 만들었다:
사용한 Skills:
- Slide Dev Skill - 기본적으로 Claude Code에게 slide dev(슬라이드 라이브러리)가 어떻게 작동하는지 연구하라고 했다
- Deep Research Skill - 모든 에이전트와 그들이 어떻게 작동하는지 연구
- Design Skill - 무언가가 끔찍하게 보이는지 좋게 보이는지 알지만, 그것을 알아낼 좋은 디자이너가 아니기 때문. 이 박스들조차도 “박스를 조금 더 멋지게 만들어. 액센트 컬러를 줘”라고 했다
이것이 만든 방법이다.
Q&A 하이라이트
DAG와 순차 실행에 대한 질문
질문: “DAG는 순차 실행을 강제할 수 있다. 고객 서비스 에이전트가 이름, 이메일을 순서대로 묻는 것처럼. 이것을 계획으로 작성하고 모델이 그 순서대로 도구를 호출할 것을 신뢰해야 하는가? 순서를 어떻게 강제하는가?”
답변: 서로 다른 유형의 문제가 있다. 우리 모두가 작업을 하는 데 사용할 수 있는 범용 코딩 에이전트를 만드는 문제, 비기술적 사람들도 사용할 수 있는 것, 이 문제를 해결하는 특정 단계가 없다. 그래서 모델에 의존하는 것이 더 낫다.
여행 일정을 만드는 것이라면, 항상 같은 결과물이 있기 때문에 좀 더 특정한 단계다. 그래서 중요할 수 있는 DAG가 조금 더 있다. 하지만 여행 연구 단계에서는 모든 도시가 다를 것이기 때문에 DAG를 원하지 않을 것이다.
정말로 해결하는 문제에 달려 있다. 여행 일정을 위한 에이전트를 만들고 싶다면, 아마도 tool call 중 하나가 출력 파일을 만드는 DAG일 것이다. 출력이 같게 보이기를 원하기 때문이다. 또는 계획을 만드는 것. 그리고 시스템 문제에서 항상 출력으로 끝나라고 말할 수 있다.
하지만 믹스 앤 매치해야 한다. 모든 사용 사례가 다르다. 범용으로 만들고 싶다면, 모델에 더 의존하고, 단순한 루프에 의존하고, DAG에는 덜 의존하라는 것이 Jared의 견해다.
API 호출의 미래
질문: “코드를 통해 실제로 API를 호출하지 않고, 대부분의 LLM 호출이 Claude Code를 트리거하고 파일을 작성하는 것으로 향하는 세계로 가고 있다고 생각하는가?”
답변: 잠재적으로. 장단점이 있다.
장점: 개발하기 더 쉽고, 프론티어 모델에 의존할 수 있다. 생각해보면, reasoning model이 바로 그것이다. Reasoning model은 항상 존재하지 않았다. 일반 LLM 모델만 있었고, 그다음 O1과 reasoning model이 생겼다. 그것이 전부는 조금 더 복잡하지만, 기본적으로 OpenAI 서버에서 컨텍스트를 계속 실행하다가 결국 출력을 주는 while 루프일 뿐이다. Claude Code SDK가 더 많은 것들이 있는 while 루프인 것과 같은 방식으로.
많은 빌더들이 이런 에이전틱 엔드포인트만 만지는 것을 완전히 볼 수 있다. 심지어 모델 제공자가 에이전틱 엔드포인트로 모델을 출시하는 것을 볼 수도 있다.
하지만 많은 작업에 대해 조금 더 제어를 원할 것이고, 아마 가능한 한 메탈에 가깝게 가고 싶을 것이다.
그렇긴 하지만, 여전히 completions 모델을 원했던 많은 사람들이 있었고, 그것은 절대 일어나지 않았고, 아무도 더 이상 그것에 대해 이야기하지 않는다. 따라서 모든 것이 그냥 이 SDK가 될 가능성이 매우 높지만, 수정 구슬은 없다. 하지만 그렇게 생각할 것이다.
TDD와 Spec-driven Development
질문: “단순할수록 좋다고 항상 말하지만, AI에서 테스트 주도 개발과 스펙 주도 개발에 대한 생각은 어떤가?”
답변: 의심스러울 때 좋은 엔지니어링 관행으로 돌아가라. 테스트 주도 개발이 올바른 방법인지에 대한 전체 엔지니어링 논쟁이 있고, 일부 사람들은 맹세하고 일부는 그렇지 않다. 따라서 답은 없다고 생각한다.
코딩 에이전트는 분명히 테스트 주도 개발이 더 쉽게 만든다. AMP, Sourcegraph의 전체 철학이 그것이다. 좋은 테스트를 만들 수 있다면 코딩 에이전트가 훨씬 더 잘 작동할 수 있다. Factory도 이렇게 생각한다고 본다. 그래서 말이 된다.
개인적으로 작업할 때, 계획 단계와 스펙 주도 개발 단계에 꽤 많이 의존하고, 단순한 작업은 모델에 꽤 쉽다고 생각하지만, 매우 간단한 편집을 한다면 그 단계를 건너뛴다.
모두에게 맞는 단일 크기는 없지만, 의심스러울 때 믿는 엔지니어링 원칙으로 돌아가라.
System Prompt 접근
질문: “시스템 프롬프트 유출에 대해 이야기했다. 다운로드한 JavaScript 번들을 보고 특별한 엔드포인트가 프롬프트 종류의 엔드포인트를 가지고 있는지 볼 수 없는가?”
답변: 숨기려고 한다고 생각한다. 실제로 흥미로운 기사가 있었다. Codex가 오픈소스이기 때문에, OpenAI가 사용하고 있던 Codex 모델을 출시하기 전에, 오픈소스 Codex를 해킹해서 모델에 커스텀 프롬프트를 주고 그것 없이 모델을 사용할 수 있었다.
그래서, 들어갈 수 있지만, 일반적으로 숨기려고 하고, 또한 누군가 게시했기 때문에 게으름이다. 그래서 작업이 끝났다.
하지만 누군가는 그것을 찾아야 했다, 맞는가? 이 프롬프트는 어딘가 머신에 있는가? 실제로 그 답을 모른다. 답을 아는가? (청중: 당신의 머신에 있다.) Nico가 당신의 머신에 있다고 말한다.
그래서 답은 그렇다. 프롬프트가 서버에 숨겨져 있는가, 아니면 그렇게 결심하면 찾을 수 있는가? 답은 그렇다인 것 같다.
PromptLayer 지원 방법
질문: “PromptLayer에 대해 이야기하는데, 사람들이 어떻게 도울 수 있는가?”
답변:
- 채용 중 - 뉴욕에서 매우 재미있고 빠르게 움직이는 팀에서 코딩 직업을 찾고 있다면, X나 이메일 [email protected]으로 연락하라
- 플랫폼 - AI 제품을 만들고 테스트하기 위한 플랫폼, 프롬프트 관리, 감사 가능성, 거버넌스, 모든 재미있는 것들, 그리고 로깅과 eval
- 팀과 협업 - AI 애플리케이션을 팀과 함께 만들고 있다면, PromptLayer를 시도해야 한다. 삶을 더 쉽게 만들 것이다. 특히 팀이 클수록, 더 협업하고 싶을수록, PM과 비기술적 사용자와 더 협업하고 싶을수록, 또는 기술적 사용자만 있어도 훌륭한 도구다
발표 마무리
이것이 전체 쇼였다. 들어주셔서 감사하다. 이 강연은 현대 코딩 에이전트의 핵심이 “단순함”에 있으며, 과도한 엔지니어링보다 모델의 능력을 신뢰하는 것이 더 효과적이라는 통찰을 제공한다. Claude Code, Cursor, Codex, AMP 등 각 에이전트는 서로 다른 철학과 강점을 가지고 있으며, 사용 사례에 따라 적절히 선택하고 조합하는 것이 중요하다는 메시지로 마무리된다.