클라우드 코드 작동 원리
AI Engineer
구독자 99,800명
요약
Prompt Layer의 Jared가 코딩 에이전트의 혁신 배경과 작동 원리를 소개합니다. 단순한 while 루프와 핵심 도구 호출만으로 복잡도를 낮추고, 최신 언어 모델을 믿음으로써 에이전트 개발을 가속화하는 방법을 설명합니다. 또한 To-Do 리스트, 샌드박스 격리, 다양한 에이전트 철학 비교, 평가 전략을 통해 실제 개발 워크플로우에 적용 가능한 주요 원칙을 제시합니다.
주요 키워드
coding agent
Cloud Code
tool call
prompt engineering
context management
sandboxing
to-do list
unified diff
sub-agent
evaluation
하이라이트
- 🔑 Cloud Code는 복잡한 분기 대신 단순한 while 루프와 도구 호출 아키텍처를 활용해 에이전트 개발을 간소화합니다.
- ⚡️ 최신 언어 모델의 향상 덕분에 과도한 프롬프트 설계 없이도 에이전트가 스스로 오류를 수정하며 유연하게 실행 결과를 만들어냅니다.
- 📌 도구 호출(tool call)은 함수처럼 입력과 출력이 명확해 테스트·검증이 용이하며, 10개 이하의 핵심 도구만으로도 강력한 코딩 워크플로를 구축할 수 있습니다.
- 🌟 To-do 리스트 기능은 시스템 프롬프트에 주입된 상태로 에이전트의 계획·진행 상황·완료 여부를 관리해 큰 코드 변경 없이 작업 흐름을 제어합니다.
- 🚀 샌드박스 격리와 URL 필터링을 통해 웹·쉘 접근 권한을 제어하며, 컨테이너 기반 권한 설정으로 로컬 환경을 안전하게 보호합니다.
- 🔍 백테스트(backtest)와 도구 호출 횟수·재시도율 등의 에이전트 스멜(Agent Smell) 지표 분석을 통해 실제 성능과 안정성을 검증해야 합니다.
- 🌐 Cloud Code, CodeEx, AMP, Cursor 등 각 플랫폼은 모델 선택·UI·동시 처리 전략에서 차별화된 관점을 제시하므로 목적에 맞게 혼합·매칭이 필요합니다
용어 설명
agent
사용자의 지시를 바탕으로 코드 작성·수정·실행 등을 자동화하는 자율 코딩 시스템입니다.
tool call
에이전트가 사전에 정의된 외부 기능(파일 읽기·편집·쉘 실행 등)을 호출해 작업을 수행하는 인터페이스입니다.
constitution
에이전트의 초기 동작 원칙·규칙을 정의하는 문서(MD 코드엑스 등)로, 사용자가 MARKDOWN 형식으로 직접 편집 가능합니다.
unified diff
파일 수정 시 전체를 다시 쓰지 않고 변경 부분만 표기해 토큰 사용량과 오류 가능성을 줄이는 데이터 포맷입니다.
sub-agent
메인 루프와 별도로 특정 작업을 수행하는 하위 에이전트로, 고유 컨텍스트를 가지며 결과만 메인 에이전트에 반환합니다.
sandboxing
에이전트의 쉘 명령어·웹 요청 등을 제한된 가상 환경에서 실행하도록 격리해 보안·안정성을 확보하는 기술입니다.
워크숍 시작 및 연사 소개
주최 측이 800명 중 끝까지 남은 헌신적 엔지니어들을 환영하며, 이 세션이 공식 후원은 아니지만 뉴욕 AI 커뮤니티를 알리는 자리임을 안내합니다.
컨퍼런스의 마지막 워크숍이 시작되며, 800명 중 끝까지 남은 헌신적인 엔지니어들을 축하합니다.
발표자가 'Claude Code' 제목으로 Anthropic에게 혼난 일화를 재미있게 소개하며, 이는 공식적으로 승인된 내용이 아님을 밝힙니다.
뉴욕의 주목할 만한 AI 인재들을 소개하는 것을 좋아하며, Jared가 코딩 에이전트 외에도 스타트업을 운영하고 있다고 설명합니다.
Jared가 발표를 시작하며 컨퍼런스에 대한 감사를 표하고, Claude Code의 작동 방식에 대해 이야기할 예정임을 밝힙니다.
Jared와 Prompt Layer 소개
Jared가 Prompt Layer 창업 배경과 AI 엔지니어링용 워크벤치 비전을 공유합니다. 프롬프트·에이전트 개발에 제품·엔지니어·도메인 전문가 협업을 핵심 원칙으로 제시합니다.
발표의 목표를 설명하며, 최근 코딩 에이전트들이 폭발적으로 성장한 이유와 무엇이 이들을 마침내 좋게 만들었는지에 대한 궁금증을 표현합니다.
코딩 에이전트 진화
ChatGPT 복붙 방식부터 Cursor, Cursor Assistant를 거쳐 Cloud Code로 이어진 코딩 에이전트 발전사를 되짚으며, 최근 기술이 비약적으로 개선된 이유를 묻습니다.
Jared가 자신을 소개하며, AI 엔지니어링을 위한 워크벤치를 만드는 Prompt Layer라는 뉴욕 기반 회사를 운영하고 있다고 설명합니다.
Prompt Layer의 핵심 철학을 설명하며, 엄격한 프롬프트 엔지니어링과 에이전트 개발을 믿고, 제품팀과 엔지니어링팀의 협업을 중요시한다고 밝힙니다.
발표 중 자유로운 질문을 환영하며, 매일 수백만 건의 LLM 요청을 처리하는 경험과 고객들과의 대화에서 얻은 인사이트를 공유할 예정임을 알립니다.
창업자로서 제품을 직접 사용해보는 독특한 경험을 언급하며, 에이전트를 시작하는 일과 자신의 제품으로 에이전트를 만드는 일을 병행한다고 설명합니다.
창업자로서 에이전트 개발과 자사 제품을 활용한 에이전트 구축을 병행하는 독특한 경험을 소개하며, Claude Code에 대한 열정적인 지지를 표현합니다.
플랫폼 구축의 어려움으로 수많은 엣지 케이스와 예상치 못한 문제들로 인한 '천 번의 작은 상처'를 언급하며, 이를 해결하기 위한 조직적 접근법을 설명합니다.
엔지니어링 조직의 새로운 규칙을 소개합니다. Claude Code로 한 시간 안에 완료할 수 있는 작업은 우선순위 고려 없이 바로 실행하라는 방침으로, 작은 팀임에도 큰 효과를 거두었다고 설명합니다.
강연의 핵심 목표를 제시합니다. 코딩 에이전트가 왜 폭발적으로 성장했는지, 어떤 혁신이 이를 가능하게 만들었는지 분석하고, 개인이 AI 엔지니어링에 활용할 수 있는 방법을 다룬다고 소개합니다.
혁신 포인트: 단순 아키텍처·향상된 모델
Cloud Code의 핵심은 복잡한 분기 대신 단순한 while 루프와 도구 호출, 그리고 도구 호출에 최적화된 최신 언어 모델입니다. 단순 설계와 모델 성능 향상이 결합된 혁신을 설명합니다.
과거 자율 코딩 에이전트의 한계를 인정하며, 현재는 완전히 다른 수준에 도달했다고 평가합니다. 이후 내부 구조 분석과 실용적 활용법을 다룰 것이라고 예고합니다.
AI 코딩 도구의 발전 역사를 단계별로 설명합니다. Chat GPT 복사-붙여넣기 워크플로우에서 시작해, 초기 Cursor의 Command K 기능, Cursor 어시스턴트, 그리고 Claude Code까지의 진화 과정을 추적합니다.
Claude Code를 코드를 직접 건드리지 않는 새로운 헤드리스 워크플로우로 정의하며, 이러한 도구가 정말 좋아야 하는 이유와 그 성공 요인에 대한 의문을 제기합니다.
개인적 견해임을 전제로 하며, 코딩 에이전트 성공의 핵심 요소를 간단한 아키텍처와 지속적인 모델 개선으로 분석합니다. 특히 Anthropic의 더 나은 모델 출시가 중요한 돌파구였다고 평가합니다.
“Give tools and get out of the way”
에이전트에 파일 읽기·편집·쉘 실행 등의 핵심 도구를 제공한 뒤, 과도한 프레임워크 설계 없이 모델에 유연한 탐색과 문제 해결을 맡기는 방식을 강조합니다.
Claude Code의 아키텍처는 '툴을 주고 방해하지 않는다'는 간단한 철학에 기반합니다. 과거의 복잡한 프롬프트 엔지니어링 대신 모델에게 필요한 도구를 제공하고 모델이 스스로 작업하도록 하는 방식입니다.
툴 호출은 JSON 포맷팅을 위한 새로운 추상화로, 예전의 JSON former 같은 라이브러리들을 대체했습니다. 현재 모델들은 툴 호출에 특화되어 훈련되고 있어 이런 작업에 더욱 최적화되고 있습니다.
엔지니어들이 흔히 하는 실수는 과도한 최적화입니다. 할루시네이션을 방지하기 위해 복잡한 프롬프트 체인을 구축하는 대신, 간단한 루프를 사용하고 불필요한 스캐폴딩을 제거하는 것이 중요합니다.
모델들은 지속적으로 향상되고 있으며, 특히 툴 호출과 자율 실행 능력에서 발전하고 있습니다. Anthropic의 'AGI pill' 철학은 현재 모델의 결함을 위한 과도한 엔지니어링보다는 모델 자체의 개선을 기다리라는 것입니다.
Claude Code의 핵심 철학은 임베딩, 분류기, 패턴 매칭 등 복잡한 RAG 시스템을 버리는 것입니다. 대신 더 나은 모델을 만들고 간단한 툴 호출에 의존하여, 복잡한 워크플로우 대신 직관적인 접근 방식을 채택합니다.
Claude Code의 핵심은 최적화된 도구 호출 모델에 기반한다고 설명하며, 파이썬의 선(禪) 철학을 언급합니다.
파이썬의 'import this' 철학을 소개하며, '간단함이 복잡함보다 낫다'는 원칙이 시스템 구축과 Claude Code 설계에 어떻게 적용되는지 설명합니다.
이 철학이 발표의 핵심이며, 엔지니어링 원칙으로 돌아가 간단한 설계가 더 나은 설계라는 점을 강조합니다.
데이터베이스 스키마뿐만 아니라 자율 코딩 에이전트 구축에서도 이 원칙이 적용되며, 코딩 에이전트의 구체적인 부분들을 분석하겠다고 합니다.
To-Do 리스트로 작업 구조화
에이전트의 계획·진행·완료 단계를 시스템 프롬프트에 주입된 To-Do 리스트로 관리합니다. 별도 코드 없이 프롬프트만으로 작업 흐름과 상태를 간소화해 통제합니다.
첫 번째 구성 요소인 '컨스티튜션(헌법)'을 소개하며, Claude의 .mcp codeex나 agents.md에 대해 설명합니다.
라이브러리 지침을 넣는 마크다운 파일의 중요성을 설명하며, 과도한 엔지니어링 없이 간단한 접근 방식을 택한 팀의 철학을 소개합니다.
Cursor 1.0이 벡터 DB를 만들어 연구하는 복잡한 방식과 달리, 단순히 마크다운 파일로 해결하는 접근법을 설명합니다.
모든 것이 결국 프롬프트 엔지니어링이나 컨텍스트 엔지니어링이며, 범용 모델을 특정 용도에 맞게 적응시키는 것이 핵심이라고 설명합니다.
시스템의 핵심인 간단한 마스터 루프를 소개하며, 이것이 기존 에이전트 구축 방식과 비교해 혁명적이라고 평가합니다.
Claude Code와 현재 모든 코딩 에이전트들이 단순한 while 루프와 도구 호출로 작동하는 방식을 설명하며, 이것이 N0라고 불리는 4줄 코드 시스템이라고 합니다.
AI 모델들이 툴 호출 시 언제 계속하고 언제 실수를 고칠지 아는 능력이 놀라우며, 실수 수정과 유연한 대응에 뛰어나다는 점을 강조합니다.
모델에게 더 많은 탐색과 자율 해결을 맡길수록 더 나은 모델이 등장했을 때 시스템이 더욱 견고해진다고 설명합니다.
Claude Code의 핵심 툴들을 소개하며, 이들이 매일 변화하고 있지만 현재 가장 흥미로운 핵심 기능들을 설명하겠다고 합니다.
Read 기능은 단순한 cat 명령어와 달리 토큰 제한을 고려해 설계되었으며, 큰 파일 처리 시 발생하는 문제를 해결하기 위한 툴이라고 설명합니다.
Grep, glob 기능은 기존의 RAG나 벡터 접근법과 반대되지만, 범용 에이전트에서는 사용자가 실제로 하는 방식을 따라하는 것이 효과적이라고 강조합니다.
모든 툴들이 인간의 실제 작업 방식을 모방한 것이며, 터미널에서 문제를 해결할 때 사용하는 자연스러운 행동들을 따라한다고 설명합니다.
Edit 기능은 diff를 사용해 파일 전체를 다시 쓰지 않고 부분만 수정하는 방식으로, 더 빠르고 효율적이며 실수를 방지하는 자연스러운 방법이라고 설명합니다.
Bash는 가장 핵심적인 툴로, 모든 다른 툴들을 제거하고 bash만으로도 충분할 것이라며, Claude Code가 Python 파일을 생성-실행-삭제하는 과정의 아름다움을 설명합니다.
샌드박싱과 권한 관리
에이전트의 쉘·웹 접근을 컨테이너·URL 필터링으로 격리해 보안과 안정성을 확보합니다. macOS Seatbelt, 리눅스 커널 격리 등 다양한 메커니즘을 설명합니다.
웹 검색과 웹 fetch 기능들은 더 저렴하고 빠른 모델로 작업을 이동시키는 특징이 있다고 소개합니다.
에이전트가 여러 엔드포인트에 연결할 때는 메인 루프와 분리된 하위 계층으로 구성하는 것이 효율적이라고 설명합니다.
투두 리스트 기능과 태스크 관리의 중요성을 소개하며, 이것이 모델의 조향성과 컨텍스트 관리에 핵심적인 역할을 한다고 강조합니다.
긴 프로세스 실행 시 컨텍스트를 어지럽히지 않는 방법의 중요성을 설명하며, 컨텍스트가 가득 차면 모델 성능이 떨어진다는 핵심 문제를 지적합니다.
bash의 두 가지 장점을 설명합니다 - 간단하면서도 모든 작업이 가능한 견고함과 풍부한 훈련 데이터의 존재로, 이것이 범용 어댑터 역할을 한다고 강조합니다.
Python 스크립트 생성과 테스트 생성 기능의 장점을 설명하며, Claude 코드를 로컬 환경 구축에 활용하는 실용적인 경험을 공유합니다.
시스템 프롬프트에서 도구 선택 지침과 엣지 케이스 처리 방법을 설명하며, 편집 전 읽기, 병렬 작업 처리, 경로 인용 등의 기술적 세부사항을 다룹니다.
다양한 코딩 에이전트 철학
Cloud Code, CodeEx, AMP, Cursor Agent 등 주요 플랫폼을 모델 선택·UI/UX·동시 처리 전략 관점에서 비교 분석하며, 사용 사례에 따른 혼합·매칭 가능성을 조명합니다.
투두 리스트 기능에 대한 본격적인 설명을 시작하며, 이것이 현재는 일반적이지만 과거에는 흔하지 않았던 기능이라고 소개합니다.
투두 리스트의 구조적 특성에 대한 설명: 구조화되어 있지만 구조적으로 강제되지 않는 특징을 가지고 있으며, 한 번에 하나의 작업, 완료 표시, 진행 중인 작업 유지 등의 규칙들이 있다.
투두 리스트가 결정론적으로 강제되지 않고 순전히 프롬프트 기반이라는 점을 강조하며, 현재 모델들의 지시 따르기 능력 향상으로 인해 가능해진 기능임을 설명한다.
시스템 프롬프트에 도구 설명과 투두를 주입하는 방식으로 작동하며, 실제 코드에서 강제되지 않음에도 불구하고 효과적으로 작동하는 간단한 구현임을 설명한다.
투두 시스템의 실제 구조를 설명하며, 버전, ID, 제목, 증거 등의 요소들을 포함한 구조화된 스키마를 통해 데이터를 정리하는 방식임을 보여준다.
투두 시스템의 네 가지 주요 이점을 제시: 계획 강제, 충돌 후 재개, UX 개선(사용자가 진행 상황을 알 수 있음), 조종성 향상 등을 통해 사용자 경험을 크게 개선한다.
비동기 버퍼(H2A) 시스템에 대한 소개로, IO 프로세스를 추론으로부터 분리하고 터미널의 모든 내용을 모델에 무차별적으로 입력하지 않는 효율적인 컨텍스트 관리 방법을 설명한다.
컨텍스트가 AI 모델의 가장 큰 제약사항이며, 이를 해결하기 위해 스마트한 압축과 요약 전략이 필요하다고 설명합니다. 용량 한계에 도달하면 중간 부분을 삭제하고 앞뒤를 요약하는 방식으로 처리한다고 소개합니다.
평가 전략: 백테스트와 지표 분석
과거 로그 재실행(backtest)과 도구 호출 횟수·재시도율 같은 Agent Smell 지표를 활용해 에이전트 신뢰도와 안정성을 검증하는 방법을 제안합니다.
Bash 샌드박스의 장점을 설명하며, 모든 AI 채팅 인터페이스가 미래에 샌드박스를 갖게 될 것이라고 예측합니다. 장기 메모리 저장이 가능하여 컨텍스트가 짧아질수록 더 빠르고 스마트하게 작동한다고 강조합니다.
복잡한 DAG 구조의 문제점을 실제 사례로 설명합니다. 고객 지원 에이전트 구축 시 수백 개의 노드로 이루어진 복잡한 분류 시스템을 사용했던 과거 방식의 한계를 지적하며, 이는 프롬프트 인젝션 문제는 해결하지만 엔지니어링적으로 너무 복잡하다고 평가합니다.
핵심 메시지로 '모델을 믿으라'고 강조합니다. 모든 엣지 케이스와 조건문을 미리 생각하려 하지 말고, 현재 AI 모델의 능력이 충분히 발전했으므로 모델이 스스로 탐색하고 문제를 해결하도록 맡기는 것이 더 효과적이라고 설명합니다.
브라우저 에이전트 실험 사례를 공유합니다. 웹사이트의 모든 버튼에 제목을 추가해 에이전트의 탐색을 도우려 했지만, 오히려 성능이 저하되었다는 예상 밖의 결과를 얻었다고 설명합니다.
에이전트에게 구체적인 지시를 하면 오히려 산만해져서 성능이 떨어질 수 있으므로, 탐색에 의존하는 것이 더 효과적이라고 설명합니다.
현재 모델의 한계를 해결하기 위한 스캐폴딩이 3-6개월 후에는 무용지물이 될 텐데, 단기 문제 해결에 엔지니어링 리소스를 투자하는 것과의 균형을 어떻게 맞추냐는 질문이 제기됩니다.
사용 사례에 따라 다르지만, 에이전트 패러다임에서 메인 루프와 엄격한 툴 호출을 사용하되, 엣지 케이스는 구조화된 툴로, 탐색 단계는 모델에 맡기는 절충안을 제시합니다.
주요 시사점 및 마무리
“모델을 믿고 단순 설계가 승리하며, bash로 도구를 연결하라”는 핵심 원칙과 다양한 관점을 수용하는 중요성을 강조하며 워크숍을 마무리합니다.
Claude Code는 ML 기반 의도 탐지, ReAct, 분류기 등을 제거하고 있으며, LLM 대신 비LLM 분류기를 사용하는 접근법은 비용 절감 외에는 큰 도움이 되지 않을 것이라고 평가합니다.
Claude는 think, think hard, think harder, ultra think 같은 트리거 단계를 통해 추론 토큰 예산을 조절 가능한 파라미터로 활용하는 스마트한 방식을 사용합니다.
모델이 조정할 수 있는 매개변수에 대해 설명하며, 모델이 스스로 조정하거나 하드 플래닝을 위한 도구 호출, 또는 사용자 지정을 통한 실시간 변경 방법을 제시합니다.
샌드박싱과 권한 관리의 중요성을 강조하며, YOLO 모드의 위험성과 데이터베이스 삭제 사례를 통해 보안의 필요성을 설명합니다.
인터넷에서 오는 프롬프트 인젝션 공격의 위험성과 이에 대응하는 컨테이너화, URL 차단 등의 보안 조치에 대해 설명합니다.
bash 명령어 게이팅 파이프라인과 접두사에 따른 샌드박싱 환경 구분 방식에 대해 설명하며, 다른 모델들과의 차이점을 언급합니다.
서브 에이전트의 개념과 컨텍스트 관리 문제를 해결하는 방법을 소개하며, 긴 컨텍스트가 에이전트 성능에 미치는 부정적 영향을 설명합니다.
서브 에이전트의 핵심 원리와 연구자, 문서 리더, 테스트 러너, 코드 리뷰어 등의 구체적인 예시를 제시하며, 웹사이트 태그 추가 작업 사례를 통해 실제 적용 방법을 설명합니다.
태스크 구조와 서브 에이전트의 설명 및 프롬프트 구성 요소에 대해 설명하며, 사용자에게 보여지는 부분과 실제 작동 방식의 구분을 소개합니다.
코딩 에이전트가 자체적으로 다른 에이전트들을 프롬프팅하는 혁신적인 패러다임을 설명하며, 에이전트가 문자열에 원하는 만큼 많은 정보를 넣고 오류 발생시 더 많은 정보를 추가해 문제를 해결하는 유연한 접근법을 강조했습니다.
문자열 대신 객체 구조를 사용하여 더 구조화된 데이터를 제공하는 개선 방안을 제안했습니다.
메인 에이전트와 서브 에이전트 간의 컨텍스트 공유 방식에 대한 질문에 답변하며, 툴 콜 구조가 메인 에이전트에 있고 설명과 프롬프트가 즉석에서 생성되는 방식을 설명했습니다.
클로드 코드 시스템 프롬프트의 유출된 정보를 바탕으로 한 주요 지침들을 소개했습니다. 간결한 출력, 텍스트 설명보다 툴 사용 우선, 기존 코드와의 매칭, 병렬 명령 실행 등이 포함되며, 시스템 프롬프트를 통해 할 수 있는 다양한 넛지 기법들과 DAG와의 트레이드오프에 대한 논의로 이어집니다.
Claude Code 사용 경험에서 나온 기능들과 프롬프팅의 중요성에 대해 설명합니다. 사용자들이 "이 부분만 좀 덜/더 했으면"이라고 요청하는 것들이 기능으로 발전했다고 언급합니다.
스킬 기능을 소개하며 확장 가능한 시스템 프롬프트로 설명합니다. 컨텍스트를 어지럽히지 않으면서 더 많은 정보에 접근할 수 있는 방법을 제공한다고 강조합니다.
스킬의 구체적 활용 사례들을 설명합니다. 문서 업데이트용 글쓰기 스타일 스킬, Microsoft Office 편집, 디자인 스타일 가이드, 심화 연구 등의 예시를 제시하며 실제 효과를 증명합니다.
Unified diffing의 장점을 설명합니다. 토큰 제한 감소, 속도 향상, 오류 감소 등의 이점을 언급하며 에세이 전체 재작성 대신 빨간 줄 표시로 수정하는 것의 비유로 설명합니다.
청중의 스킬 관련 질문이 시작됩니다. 4만 자 초과 시 Claude Code의 경고와 스킬 분할 시도, 그러나 Claude가 스킬을 무시하는 문제점에 대한 혼란을 표현합니다.
Claude 코드 시스템의 스킬 인식 문제에 대한 논의. Claude MD가 코드가 길다고 알려주어 스킬로 옮겨도 시스템이 스킬을 제대로 인식하지 못하고 필요할 때 호출하지 않는다는 문제점을 지적합니다.
스킬 호출 시스템의 설계 의도와 현실적 한계를 설명합니다. 각 스킬에 대한 설명을 모델에 제공하지만 실제로는 수동으로 호출해야 하는 경우가 많으며, 이는 모델 훈련이나 후훈련의 문제일 수 있다고 분석합니다.
AI 개발의 미래 방향에 대한 두 가지 상반된 관점을 제시합니다. 많은 사람들이 수백 개의 도구 호출을 가진 하나의 마스터 루프를 선호하는 반면, 발표자는 도구 호출을 줄이고 bash와 로컬 스크립트를 활용하는 방향을 지지합니다.
적응적 예산과 추론 조정의 개념을 소개하며, 추론 모델을 도구로 활용하는 패러다임의 가능성을 논의합니다. 속도와 성능 간의 트레이드오프를 고려한 혼합 접근법이 차세대 AI 시스템의 핵심이 될 것이라고 전망합니다.
새로운 패러다임과 스킬 시스템 구축에 대해 논의하며, 완벽하지 않더라도 새로운 발견의 가능성이 많다고 설명합니다.
발표의 후반부에서 다른 AI 프런티어 기업들이 채택한 에이전트 철학과 설계 전략들을 분석하겠다고 소개합니다.
AI 테라피스트 문제를 예시로 들며, 가장 흥미로운 AI 문제들에는 전역 최적해가 없다고 주장합니다. 뉴욕시의 다양한 치료사들처럼 서로 다른 전략들이 같은 목표를 위해 존재한다고 설명합니다.
AI 애플리케이션 구축 시 취향과 설계 아키텍처가 중요하다고 강조하며, 여러 코딩 에이전트가 각각의 강점을 가질 수 있다고 설명합니다.
개인적으로 Claude Code는 로컬 환경과 git 작업에, Codex는 어려운 문제에, Cursor Composer는 속도가 필요한 작업에 사용한다고 경험을 공유합니다.
다양한 철학적 접근의 가치를 강조하며, 하나의 승자가 아닌 각기 다른 사용 사례에 맞는 여러 승자가 존재할 것이라고 예측합니다. 도메인 전문가와의 협업이 방어 가능성 구축의 핵심이라고 설명합니다.
주요 코딩 에이전트들의 관점을 소개하며, Claude Code가 특히 인상적이라는 개인적 견해를 표현합니다.
Claude Code가 사용자 친화성과 단순성에서 우승한다고 설명하며, Git과 같은 복잡한 작업에서 특히 강력하다고 언급합니다.
Claude Code의 강력함을 입증할 명확한 증거는 없지만 개인적으로 강력하게 느껴지며, 시장도 동의하는 것 같다고 설명합니다.
Cursor IDE는 모델 불가지론적이고 빠르며, Factory의 Droid는 하위 에이전트들을 전문화시키는 것이 특징이라고 소개합니다.
Devon은 end-to-end 자율성과 자기 성찰을 특징으로 하며, Free는 모델 불가지론적이고 뛰어난 UX 디자인을 제공한다고 설명합니다.
Codex에 대해 분석하기 시작하며, Claude Code와 유사하지만 Rust 코어를 사용하고 오픈소스라는 점이 특징이라고 설명합니다.
Codex는 더 이벤트 기반적이고 동시 스레딩에 중점을 두며, 샌드박싱 방식이 커널 기반으로 다르다고 분석합니다.
Codex와 Claude Code의 진짜 차이점은 모델이며, 실제로 Claude Code를 사용해 Codex를 연구했다는 경험을 공유합니다.
Sourcegraph의 코딩 에이전트인 AMP에 대해 소개하며, 무료 티어를 제공하고 여분의 토큰을 활용해 광고를 통해 수익을 창출한다고 설명합니다.
화자가 광고에 대한 자신만의 독특한 견해를 밝히며, 모델 선택 옵션이 없는 것이 오히려 개발 속도를 높인다고 설명합니다.
그들의 비전은 단순히 최고의 에이전트가 아닌 에이전트 친화적 환경에서 작동하는 에이전트 구축이며, 밀폐된 코딩 환경과 피드백 루프 구축이 핵심이라고 강조합니다.
기존의 compact 방식의 문제점을 지적하며, handoff라는 새로운 접근 방식을 소개합니다. 이는 콜 오브 듀티의 무기 교체처럼 새 스레드를 시작하는 것이 더 효과적이라고 설명합니다.
모델 선택에 대한 그들의 접근법을 설명하며, 빠름, 스마트, 오라클 세 가지 옵션과 상황에 따른 오라클 사용 전략을 소개합니다.
Cursor의 에이전트는 UI 우선 접근법과 빠른 속도의 distilled 모델 컴포저를 특징으로 하며, 파인튜닝에 대한 관심을 되살렸다고 평가합니다.
데이터 기반의 방어력 구축에 대해 설명하며, 커서의 에이전트 컴포저의 놀라운 속도와 성능에 대해 언급합니다.
커서 에이전트 컴포저로 완전히 전환한 경험을 공유하며, 속도가 너무 빨라 실수로 마스터에 푸시하는 사건도 있었다고 합니다.
커서가 모두의 사랑을 받는 이유와 팀의 점진적 개발 접근법을 칭찬하며, 초기 형편없던 버전에서 현재의 훌륭한 소프트웨어로 발전한 과정을 설명합니다.
OpenAI의 코덱스 모델들도 비슷하게 발전했다고 평가하며, 속도는 조금 느리지만 코딩 에이전트에 최적화된 디스틸 모델이라고 설명합니다.
블로그의 사진을 통해 코딩 에이전트에 대한 관점을 보여주며, 컴포저와 최첨단 모델을 동시에 제공하는 전략에 대해 설명합니다.
어떤 아키텍처가 최고인지에 대한 핵심 질문을 던지며, 벤치마크가 이제 마케팅 도구가 되어 쓸모없어졌다고 비판합니다.
평가가 중요한 영역이 있다고 주장하며, 단순한 while 루프 아키텍처가 모델 유연성에 의존하여 평가를 더 어렵게 만든다고 설명합니다.
통합 테스트, 스냅샷 테스트, 백테스트 등 다양한 평가 방법들을 제시하며, 각각의 활용법에 대해 구체적으로 설명합니다.
에이전트 냄새라는 새로운 개념을 소개하며, 도구 호출 횟수, 재시도 횟수, 소요 시간 등 표면적 지표들이 정상성 확인에 유용하다고 설명합니다.
AI 모델 평가의 복잡성에 대해 설명하며, 엔드투엔드 테스트, 특정 시점 테스트, 백테스트 등 다양한 평가 방법론을 제시합니다.
PromptLayer 평가 제품을 사용한 Claude Code 테스트 예시를 보여주며, 헤드리스 환경에서 웹 검색을 통해 최신 모델을 찾는 엔드투엔드 테스트 방법을 시연합니다.
엔드투엔드 테스트의 핵심은 높은 수준에서 모델 성능을 분석하고 각 행별 통계와 도구 호출 횟수를 모니터링하는 것임을 설명합니다.
도구의 엄격한 테스트 중요성을 강조하며, 도구를 함수처럼 입력과 출력으로 테스트하고, 하위 에이전트인 경우 재귀적 테스트가 필요함을 설명합니다.
구체적인 출력이 필요한 경우, 모델 탐색보다는 엄격하게 테스트 가능한 도구 구축을 추천하며, 이메일 형식 검증 워크플로우 예시를 통해 실용적인 접근법을 보여줍니다.
에이전트 워크플로에서 놓친 부분을 자동으로 수정하는 과정을 설명. 간단한 예시이지만 SEO 블로그 포스트용으로는 20개 노드를 가진 복잡한 버전도 있으며, 심층 연구부터 링크 추가까지 전체 과정을 자동화한다고 소개.
명확한 비전이 있는 작업일 때 테스트가 더 쉬워진다고 설명. 워크플로 테스트는 단계가 적고 유연성이 낮아서 평가하기 용이하며, 샘플 이메일로 시작해서 휴리스틱을 추가하여 3개 부분(인사, 본문, 서명)이 포함되었는지 LLM 판단기로 확인하는 방식을 소개.
헤드리스 클로드 코드 SDK의 미래 가능성에 대해 언급. 간단한 프롬프트만으로 파이프라인의 일부가 되며, GitHub 액션을 통해 매일 문서를 자동 업데이트하고 커밋을 읽어 PR을 생성하는 실제 사용 사례를 공유. 더 높은 추상화 수준에서 에이전트 구축 가능성을 시사.
에이전트 개발의 핵심 교훈 4가지를 제시: 1) 모델 신뢰하기 - 확신이 서지 않을 때 모델에 의존, 2) 간단한 설계가 승리, 3) bash 정도의 간단한 도구 사용(40개가 아닌 5-10개), 4) 컨텍스트 관리의 중요성. 현재 에이전트의 주요 과제이며 미래 모델이 개선되더라도 인간과의 소통에는 항상 한계가 있을 것이라고 분석.
에이전트에서 다양한 관점이 중요하다는 다섯 번째 포인트를 설명합니다. 엔지니어링적 사고방식만으로는 문제 해결의 다양한 방법을 충분히 이해하지 못하며, 여러 전문가들의 조합된 접근이 필요하다고 강조합니다.
Claude Code와 CodeX 등 여러 에이전트가 팀으로 작동하여 Slack 채널에서 협업하는 시스템에 대한 비전을 제시합니다. 이어서 자신이 Claude Code를 사용해 슬라이드 덱을 만든 과정을 보너스로 소개합니다.
슬라이드 개발, 심층 연구, 디자인 등 다양한 스킬을 Claude Code로 구축한 구체적인 사례를 설명합니다. 디자인 스킬의 경우 자신이 디자이너가 아님을 인정하면서도 AI의 도움으로 시각적 개선을 이뤄낸 경험을 공유합니다.
발표를 마무리하며 질의응답 시간을 열고 자신을 Prompt Layer의 창립자 Jared로 소개합니다.
청중으로부터 DAG(방향성 비순환 그래프)에 관한 질문을 받습니다. DAG가 순차적 실행을 강제하는 역할을 하는데, 고객 서비스에서 이름과 이메일을 순서대로 수집하는 것 같은 상황에서 어떻게 순서를 보장할 수 있는지에 대한 질문입니다.
DAG 제거에 대한 자신의 입장을 명확히 설명합니다. 범용 코딩 에이전트 같은 문제는 특정한 해결 단계가 없어 모델에 의존하는 것이 낫지만, 여행 일정 작성처럼 명확한 결과물이 있는 경우에는 DAG가 도움될 수 있다고 답변합니다. 다만 여행 연구 단계에서는 각 도시가 다르므로 DAG가 적절하지 않다고 설명합니다.
화자가 여행 일정 에이전트를 예로 들며, 문제에 따라 접근 방식이 달라진다고 설명합니다. 출력 형식을 일관되게 유지하기 위해 DAG 구조를 사용할 수 있지만, 범용적인 솔루션을 원한다면 모델과 간단한 루프에 더 의존하고 DAG에는 덜 의존하는 것이 좋다고 조언합니다.
청중이 API 직접 호출에서 클라우드 코드 트리거 방식으로의 전환에 대해 질문합니다. 화자는 이에 대한 장단점을 설명하며, 개발의 용이성과 최첨단 기술 활용이 장점이라고 답합니다.
화자가 추론 모델의 발전을 예로 들며, 이것이 본질적으로 OpenAI 서버의 while 루프와 같다고 설명합니다. 클라우드 코드 SDK도 비슷한 구조라며, 많은 개발자들이 에이전틱 엔드포인트만 사용하게 될 가능성을 언급합니다.
복잡한 작업에는 여전히 더 많은 제어가 필요할 것이라고 설명합니다. 과거 컴플리션 모델에 대한 요구가 사라진 것처럼, 모든 것이 SDK 형태로 발전할 가능성이 높다고 전망하지만 확실하지는 않다고 말합니다.
새로운 청중이 AI에서의 테스트 주도 개발과 스펙 주도 개발에 대해 질문합니다. 화자는 에이전트 구축용인지 일반적인 작업용인지 구체화를 요청하고, 질문자는 코딩을 위한 것이라고 명확히 합니다.
에이전트와 함께하는 코딩에서 스펙 기반 개발과 테스트 기반 개발에 대한 질문이 제기되었습니다. 연사는 확신이 서지 않을 때는 좋은 엔지니어링 관행으로 돌아가라고 조언합니다.
테스트 기반 개발에 대한 엔지니어링 논쟁이 있지만, 코딩 에이전트에게는 분명히 테스트 기반 개발이 도움이 됩니다. AMP의 소스 그래프 철학처럼 좋은 테스트를 구축할 수 있다면 코딩 에이전트가 훨씬 더 잘 작동할 수 있습니다.
개인적으로 작업할 때는 계획 단계와 스펙 개발 단계에 많이 의존하며, 간단한 작업은 모델이 쉽게 처리하지만 매우 간단한 수정의 경우 그 단계를 건너뛰기도 합니다. 만능 해결책은 없지만 믿는 엔지니어링 원칙으로 돌아가야 합니다.
시스템 프롬프트 누수에 대한 질문이 나왔습니다. 일반적으로 프롬프트는 숨겨져 있지만, 코드엑스가 오픈 소스이기 때문에 과거에 누군가가 해킹을 통해 커스텀 프롬프트를 사용할 수 있었던 사례가 있습니다.
프롬프트가 서버에 숨겨져 있는지 로컬 머신에서 찾을 수 있는지에 대한 질문에 대해, 참석자가 로컬 머신에 있다고 확인해줍니다.
네, 마지막 워크숍에 오신 걸 환영합니다.
여러분이 해내셨네요. 축하드립니다.
800명 중에서 여러분이
끝까지 남아있는 정말
헌신적인 엔지니어들입니다.
네, 이번 건은 좀 특별합니다.
Anthropic에게 혼났어요.
당연히 제목 때문이죠.
사실 제가 제목도 지어줬는데
바꾸고 싶냐고 물었더니
아니다, 그냥 가자고 하더라고요. 재밌다고요.
네, 이건 Anthropic에서
공식적으로 승인한 건 아니지만, 우리는 해커니까요.
그리고 Jared는 정말
헌신적입니다. 또 제가 정말 좋아하는 건
뉴욕의 주목할 만한 AI 인재들을
소개하는 것입니다.
이게 Jared가 하는 유일한 일이라고
생각하지는 마세요.
그는 여러분이 꼭 물어봐야 할
스타트업을 운영하고 있습니다.
하지만 지역 인재들을 위한
더 많은 콘텐츠를 소개하게 되어 정말 기쁩니다.
자, Jared, 시작하세요.
정말 감사합니다.
정말 훌륭한 컨퍼런스였습니다.
끝나는 게 아쉽지만
좋은 마무리가 되었으면 합니다.
네, 제 이름은 Jared입니다.
Claude Code가 어떻게 작동하는지에 대한 이야기를 해드리겠습니다.
다시 말하지만, Anthropic과는 무관합니다.
돈을 주지도 않아요. 받고는 싶지만요.
하지만 다른 코딩 에이전트들에 대해서도
이야기해보겠습니다.
제가 다룰 주요 목표는 개인적으로
저는 모든 코딩 에이전트의 열성 사용자이고
여기 계신 모든 분들도 마찬가지일 것입니다.
최근에 이런 도구들이 폭발적으로 늘어났고
개발자로서 무엇이 바뀌었는지 궁금했습니다.
무엇이 마침내
코딩 에이전트를 좋게 만들었는지 말이죠.
그럼 시작해보겠습니다.
먼저 저에 대해 말씀드리겠습니다. 저는 Jared입니다.
X나 Twitter에서 Jared Z로 찾으실 수 있습니다.
저는 AI 엔지니어링을 위한 워크벤치를 만들고 있습니다.
제 회사는 Prompt Layer라고 하고
뉴욕에 기반을 두고 있습니다.
여기서 저희 사무실을 보실 수 있는데
작은 건물이에요.
다른 몇 건물들에 가려져 있어서
저희는 작은 팀입니다.
3년 전에 제품을 출시했습니다.
AI 기준으로는 오래됐지만 다른 모든 것 기준으로는 짧죠.
저희의 핵심 신념은
엄격한 프롬프트 엔지니어링을 믿고
엄격한 에이전트 개발을 믿으며
제품팀이 참여해야 하고
엔지니어링팀도 참여해야 한다고 생각합니다.
AI 변호사를 만든다면
엔지니어뿐만 아니라 변호사도
참여해야 한다고 믿습니다.
그게 저희가 하는 일입니다.
매일 수백만 건의 LLM 요청을 처리하고 있고
이 발표의 많은 인사이트는
코딩 에이전트를 만드는 방법에 대한
고객들과의 대화에서 나온 것들입니다.
그리고 발표 중에 언제든지
편하게 해도 됩니다.
제가 하는 말 중에 궁금한 게 있으면
언제든지 질문해 주세요.
저는 시간을 많이 들여
제품을 직접 사용해보고 있습니다.
요즘 창업자의 일은 좀 이상해요.
반은 에이전트를 시작하는 일이고
반은 제 자신의
제품을 사용해서 에이전트를 만드는 일입니다.
에이전트를 만들고, 나머지 반은 그냥 제가
만든 제품을 사용해서 에이전트를 구축하는 거죠. 이상하긴 하지만
꽤 재미있어요. 그리고, 제가 마지막으로
덧붙이고 싶은 건 저는 정말 열성적인 사용자입니다.
우리는 말 그대로 Claude Code를 중심으로
엔지니어링 조직을 재구성했어요. 제 생각에
플랫폼을 구축하는 데 있어 어려운 점은
모든 엣지 케이스들을 다뤄야 한다는 거예요.
아, 여기서 데이터셋을 업로드하는데 작동이 안 되네요.
이런 식으로 천 번의 작은 상처로
죽을 수 있죠. 그래서 우리 엔지니어링
조직에 규칙을 만들었습니다.
Claude Code로 한 시간 안에 뭔가를
완료할 수 있다면, 그냥 하세요.
우선순위를 정하지 말고요. 우리는 의도적으로
작은 팀이지만, 이 방식이 우리에게 많은 도움이 됐고
정말 다음 단계로 끌어올려 준 것 같아요.
그래서 저는 큰 팬이고, 이제 이런 것들이
어떻게 작동하는지 살펴보겠습니다. 이게 바로
제가 말했듯이 이번 강연의 목표입니다.
첫째, 왜 이런 것들이 폭발적으로 성장했을까요?
혁신이 뭐였을까요? 코딩 에이전트를
마침내 작동하게 만든 발명품이 무엇일까요?
이 분야에 조금이라도 있어봤다면
자율 코딩 에이전트들이 처음에는
정말 형편없었다는 걸 아실 텐데, 우리 모두
사용해보려고 했었죠. 하지만 지금은
완전히 다른 수준이에요. 내부 구조를
들여다보겠고, 마지막으로 이 강연의 모든 내용은
밤과 낮만큼 차이가 납니다. 내부 구조를
살펴보겠고, 마지막으로 이 강연의
모든 내용은 여러분이 어떻게 자신만의
에이전트를 구축하고 이를 어떻게 사용해서
AI 엔지니어링을 할 수 있는지에
초점을 맞췄습니다. 그럼 잠깐 역사에 대해
얘기해보죠. 어떻게 여기까지 오게 됐을까요?
모든 분들이 아시겠지만 Chat GPT에서
코드를 복사해서 붙여넣기 하는 워크플로우로
시작됐던 걸 기억하시죠. 앞뒤로 복사 붙여넣기 하고
그거였는데, 그것만으로도 대단했고
그 당시엔 혁신적이었죠.
두 번째 단계는 Cursor가 나왔을 때인데
우리 모두 기억하듯이, 처음엔 그리 좋은 소프트웨어가 아니었어요.
그냥 VS Code 포크에 Command K가
있는 정도였는데 우리 모두 좋아했죠. 하지만 이제
우리는 더 이상 Command K만 쓰지 않죠.
그 다음에 Cursor 어시스턴트가 나왔어요.
그 작은 에이전트가 앞뒤로 대화하고
그리고 Claude Code가 나왔죠. 솔직히
제가 이 슬라이드를 만든 후 지난 며칠 동안
아마 여기서 얘기할 수 있는 새로운 버전이
나왔을지도 모르겠어요. 마지막에
다음엔 뭐가 올지에 대해 얘기하겠습니다.
하지만 이렇게 여기까지 오게 됐고
이게 정말 제 생각에 Claude Code는
일종의 헤드리스 같은, 아니 심지어
코드를 건드리지도 않는 새로운 워크플로우예요.
그리고 정말 좋아야 해요. 그럼 왜 이렇게 좋을까요?
여기서 큰 돌파구가 무엇이었을까요?
한번 알아보도록 하겠습니다. 그리고 다시 한번 말씀드리면
이 모든 건 제 의견이고
제가 생각하는 돌파구입니다.
다른 것들도 있을 수 있지만 간단한 아키텍처가
핵심이라고 생각해요. 에이전트가 어떻게
설계됐는지에서 많은 것들이
단순화됐다고 생각하고, 그리고 더 나은 모델들,
더 나은 모델들, 그리고 더 나은 모델들이죠.
제 생각에 돌파구의 많은 부분이
어떻게 보면 지루한데, 그냥 Anthropic에서
더 잘 작동하는 더 나은 모델을 출시한 거라고 생각해요.
돌파구의 많은 부분이 사실 좀
지루한 면이 있는데, 그냥 Anthropic에서
더 잘 작동하는 더 나은 모델을 출시한 거예요.
이런 종류의 툴링 호출들과
이런 종류의 작업들에 더 잘 작동합니다. 하지만 간단한
아키텍처가 그것과 관련이 있습니다. 그래서 우리는
그것에 대해 살펴볼 수 있습니다. 아키텍처와 그리고
이것은 저희의 작은 프롬프트를 보실 수 있습니다
랭글러는 저희 회사의 작은 마스코트입니다. 그래서 저희는
이 슬라이드들을 위해 많은 그래픽을 만들었지만
기본적으로 툴을 주고 그다음에 방해하지 않는 것이
오늘날 아키텍처의 한 줄 요약입니다. 만약 여러분이
LLM 위에서 구축하는 일을 조금 해보셨다면
이것이 항상 사실이었던 것은 아니라는 걸 아실 겁니다.
명백히 툴 호출은 항상
존재했던 것은 아니고 툴 호출은 일종의
JSON 포맷팅을 위한 새로운 추상화입니다
그리고 만약 여러분이 GitHub 라이브러리들을 기억하신다면
JSON former 같은 것들과
옛날의 그런 것들 말이죠. 하지만 툴을 주고
방해하지 않는 것입니다. 모델들은
이런 것들을 위해 만들어지고 훈련되어
툴 호출을 더 잘하고
이것을 더 잘하게 됩니다. 그래서 여러분이 더
과도하게 최적화하고 싶어할수록 그리고 모든 엔지니어들은
특히 저를 포함해서 과도하게 최적화하는 것을 좋아하고
에이전트를 어떻게 구축할지에 대한 아이디어를 처음 가질 때
여러분은 앉아서 말하게 됩니다 아 그럼
이 할루시네이션을 방지하기 위해
이 프롬프트를 하고 그다음에
이 프롬프트를 하고 그다음에
이 프롬프트를 하고
그러지 마세요
그냥 간단한 루프를 하고 방해하지 말고
그냥 스캐폴딩을 삭제하고
스캐폴딩은 적게 모델은 더 많이가
여기서의 태그라인입니다 그리고 이것은
이번 주의 리더보드입니다.
명백히 이 모델들은
점점 더 좋아지고 있습니다. 우리는 전체 대화를 할 수 있고
그리고 저는 이미
많은 대화가 있었을 것이라고 확신합니다
느려지고 있는가? 정체되고 있는가?
이 발표에서는 실제로 중요하지 않습니다. 우리는
그것이 더 좋아지고 있다는 것을 알고 있고
툴 호출에서 더 좋아지고 있고
자율적으로 실행하는 데 더 잘 최적화되고 있습니다.
그리고 하지 마세요 이것은
Anthropic에서 이것을 AGI 필이라고 부르는 것 같습니다
생각하는 방식은
오늘날의 모델 결함을 중심으로 과도하게 엔지니어링하려고 하지 마세요
왜냐하면 많은 것들이
그냥 더 좋아질 것이고 여러분은
시간을 낭비하게 될 것입니다. 그래서 여기 철학이 있습니다
제가 보는 Claude Code의 방식은
임베딩을 무시하고, 분류기를 무시하고
패턴 매칭을 무시합니다.
우리는 실제로 이 전체 RAG 시스템을 가지고 있었습니다
Cursor가 조금의 RAG를 다시 가져오고
그들이 어떻게 하고 있는지 그리고 그들이
섞고 매치하고 있습니다. 하지만 저는
Claude Code의 천재성은 그들이
이 모든 것을 긁어내고 그들이 말했습니다 우리는
모델이 나쁜 방법을 해결하기 위해 이 모든 화려한 패러다임들이 필요하지 않습니다
그냥 더 나은 모델을 만들고 그리고 그것이
요리하도록 놔두고 그냥
이런 툴 호출들에 의존하고
툴 호출을 단순화하는 것이
매우 중요한 부분입니다
마스터 프롬프트가 세 가지 다른 브랜치로 나눠지고
그다음 네 가지 다른 브랜치로 들어가는
워크플로우를 갖는 대신에
정말로 몇 가지 간단한 툴 호출들만 있습니다
RAG 대신에 grep를 포함해서 그리고 네 그리고 그게
이것이 바로 모델이 훈련된 방식입니다.
이들은 매우 최적화된 도구 호출
모델입니다.
이것은 파이썬의 선(禪) 철학입니다.
파이썬에서 import this를 하면 나오는 내용이죠.
저는 이 철학을 정말 좋아하는데
시스템을 구축할 때
정말 적절하다고 생각하고
Claude Code가 구축된 방식에 정말 적합합니다.
정말 간단한 것이 복잡한 것보다 낫고
복잡한 것이 복잡하게 얽힌 것보다 낫고
평면적인 것이 중첩된 것보다 낫습니다.
이것이 바로 전부입니다. 이것이 이 발표의 전부이고
Claude Code가 어떻게 작동하는지에 대해
알아야 할 모든 것이며
특히 왜 작동하는지를 보여줍니다. 우리는
엔지니어링 원칙으로 돌아가서
간단한 설계가
더 나은 설계라는 점을 강조합니다.
이것은 데이터베이스 스키마를 구축할 때도 마찬가지이지만
이것은 또한
이런 자율 코딩 에이전트를 구축할 때도
마찬가지입니다. 이제 저는
이 코딩 에이전트의 모든 특정 부분들을
분석해보고 왜 흥미로운지 설명하겠습니다.
첫 번째는 컨스티튜션(헌법)입니다.
이제 우리가 당연하게 여기는 것들 중 많은 것들이
사실 한 달이나
두 달 전에 시작되었거나
아마 3-4개월 전에 시작되었을 겁니다.
이것이 Claude의 .mcp codeex나
다른 도구들이 사용하는 agents.md입니다.
흥미로운 점은 여러분 대부분이
이게 무엇인지 알고 있다고 가정하는데
다시 말하지만 이것은
라이브러리에 대한 지침을 넣는 곳입니다.
하지만 이것의 흥미로운 점은
기본적으로 팀이 말하는 것이 '우리는
모델이 먼저 저장소를 연구하는
시스템을 과도하게 엔지니어링할 필요가 없고
커서 1.0이 저장소를 이해하기 위해
로컬에 벡터 DB를 만들고
모든 연구를 하는 것처럼
그들은 그냥 말합니다. '마크다운 파일만 넣어라.
사용자가 필요할 때 바꾸게 하고
에이전트가 필요할 때 바꾸게 하라
매우 간단하고 프롬프트 엔지니어링으로
돌아가는 것이다'
저는 조금 편향되어 있는데
프롬프트 레이어가 프롬프트 엔지니어링
플랫폼이기 때문입니다만
결국 모든 것이 프롬프트 엔지니어링이거나
컨텍스트 엔지니어링입니다.
모든 것이 어떻게
이런 범용 모델들을 여러분의 용도에
맞게 적응시키느냐의 문제입니다.
그리고 가장 간단한 답이 여기서는 최고의 답이라고 생각합니다.
이것이 시스템의 핵심입니다.
간단한 마스터 루프일 뿐이고
이것이 사실
우리가 예전에 에이전트를 구축했던 방식을 고려하면
혁명적입니다.
Claude Code와 오늘날의 모든 코딩 에이전트들
codeex와 새로운 cursor와
AMP 등 모든 것들이
도구를 호출하는 하나의 while 루프일 뿐이고
마스터 while 루프를 실행하고 도구를 호출하고
마스터 while 루프로 돌아갑니다.
이것은 기본적으로 4줄로 된
N0라고 불리는 것입니다.
적어도 제 연구에 따르면 내부적으로
그렇게 불리는데, 도구 호출이 있는 동안
도구를 실행하고 도구
결과를 모델에 주고 도구 호출이 없을 때까지
다시 반복한 다음
사용자에게 무엇을 할지 묻습니다. 처음으로 도구를 사용했을 때
툴을 호출했을 때, 모델들이 언제 툴을 계속 호출할지
그리고 언제 실수를 고칠지를 너무 잘 안다는 게
정말 충격적이었어요.
그리고 저는 이게 언어 모델의
가장 흥미로운 점 중 하나라고 생각합니다.
언어 모델은 정말로 실수를 고치고
유연하게 대응하는 데 뛰어나거든요.
그리고 다시 돌아가서 말하자면,
모델에게 탐색하고 스스로 해결하도록 맡길수록
더 나은 모델이 나왔을 때
시스템이 더 좋아지고
더 견고해질 거예요.
자, 그럼
이것들이 현재 Claude Code에 있는
핵심 툴들입니다. 솔직히 말하자면
이것들은 매일 바뀌어요.
며칠마다 새로운 릴리스를 하고 있거든요.
하지만 이것들이 제가 가장 흥미롭게 생각하는
핵심적인 것들입니다.
내일은 15개가 될 수도 있고
내일은 5개로 줄어들 수도 있지만
이게 제가 흥미롭게 생각하는 부분이에요.
먼저 read 기능부터 살펴보죠.
그냥 cat 명령어를 쓸 수도 있겠지만
흥미로운 점은 read 기능에서
토큰 제한이 있다는 거예요.
Claude Code를 많이 사용해보신 분들은
가끔 '이 파일이 너무 크다'라는
메시지를 보셨을 거예요. 그래서 이런
read 툴을 만드는 게 가치가 있는 거죠.
Grep, glob 기능도요.
이것도 매우 흥미로운데
RAG나 벡터를 사용하는 기존의
많은 지혜에 반하는 접근이거든요.
물론 RAG가 전혀 쓸모없다는 건 아니에요.
하지만 이런 범용 에이전트에서는
grep이 좋고, 그리고 grep은
사용자들이 실제로 하는 방식이죠.
그리고 저는 이게 정말 중요한 포인트라고 생각해요.
제가 이런 툴들에 대해 설명할 때
기억해주세요. 이것들은 모두
인간의 작업이에요. 우리는
모델이 사용할 완전히 새로운 툴을
만들어내는 게 아니라
인간의 행동과 여러분과 제가
터미널에서 문제를 해결하려 할 때
하는 행동을 그냥 따라하는 거예요.
Edit 기능도 말이 되죠.
edit에서 흥미로운 점은 diff를 사용하고
대부분의 경우 파일을 다시 쓰지 않는다는 거예요.
훨씬 빠르고, 훨씬 적은 컨텍스트를 사용하며
문제도 훨씬 적어요.
만약 제가 여러분에게
이 슬라이드를 주고 검토해달라고 하고
읽어보신 후에 수정된 내용으로
모든 슬라이드를 다시 써달라고 하는 것과
종이에서 그냥 부분만
지워달라고 하는 것 중에서
지우는 게 훨씬 쉽죠.
diff는 실수를 방지하는
자연스러운 방법이에요.
Bash는 핵심 중의 핵심이에요.
아마 이 모든 툴들을 없애고
bash만 가지고도 될 거라고 생각해요.
처음에 이걸 봤을 때, Claude Code에서
뭔가를 실행할 때 Claude Code가
Python 파일을 만들고
그 Python 파일을 실행한 다음
Python 파일을 삭제하는 걸 보고
이게 바로 이 시스템이 작동하는
아름다운 이유라고 생각했어요.
그래서 bash가 가장 중요해요.
웹 검색, 웹 fetch 기능들도 있는데
이것들의 흥미로운 점은
더 저렴하고 빠른 모델로 이동한다는 거예요.
예를 들어, 여러분의 플랫폼에서
일부 엔드포인트나 엔드포인트 목록에 연결해야 한다면
마스터 while 루프와 분리해서 하위 계층으로 가져오는 것이 좋을 수 있습니다.
바로 이런 이유로 이것이 별도 도구가 된 겁니다.
투두 리스트에 대해서는 우리 모두 익숙하죠.
나중에 더 자세히 이야기하겠지만, 모델을 올바른 방향으로 유지하는 것
조향 가능성, 그리고 태스크 관리입니다.
태스크 관리는 정말 흥미로운 기능입니다.
이는 컨텍스트 관리에 관한 것입니다.
긴 프로세스를 실행하고 전체 파일을 읽으면서도
컨텍스트를 어지럽히지 않는 방법에 관한 것이죠.
컨텍스트가 가득 차면
모델이 어리석어지거든요.
더 좋은 표현이 없어서 그렇게 말하는 건데요.
바로 이것이 가장 큰 적입니다.
기본적으로 bash가 전부입니다.
제가 강조하고 싶은 한 가지가 있습니다.
코딩 에이전트에서 bash의 놀라운 점이 두 가지 있습니다.
첫 번째는 간단하다는 것이고
모든 것을 할 수 있습니다. 매우 견고하죠.
두 번째로 똑같이 중요한 점은
bash에 대한 훈련 데이터가 엄청나게 많다는 것입니다.
왜냐하면 우리가 실제로 사용하는 것이거든요.
모델들이 Rust나
덜 일반적인 프로그래밍 언어에서
성능이 떨어지는 이유도
그것을 사용하는 사람이 적기 때문입니다.
정말로 범용 어댑터라고 할 수 있죠.
수천 개의 도구를 사용할 수 있고 무엇이든 할 수 있습니다.
이것이 제가 앞서 든 Python 예시입니다.
모델이 Python 스크립트를 작성할 때
정말 멋있다고 생각해요.
테스트를 만들 때도 그렇고요.
항상 하지 말라고 해야 하지만요.
하지만 이 모든 셸 도구들이
그 안에 들어있습니다.
저는 Claude 코드를 사용해서
로컬 환경을 구축하곤 하는데
보통은 어딘가 파일에 적어둔
다섯 개 명령어가 있었을 텐데
그것들이 시간이 지나면 구식이 되거든요.
Claude 코드는 이런 것들을 알아내는 데 정말 뛰어나고
여러분이 하고 싶어하는 작업들을 실행해줍니다.
특히 모델이 직접 시도해볼 수 있게 해줍니다.
네, 여기 다른 제안들과
도구 사용법에 대해서
시스템 프롬프트에 어떤 도구를 언제 사용할지
알려주는 부분이 좀 있는 것 같고
어떤 도구를 다른 도구보다 우선 사용할지
자주 변경되지만
이런 것들은 일종의 엣지 케이스이고
모델이 막히는 구석들입니다.
편집하기 전에 읽기
실제로 bash 대신
GP 도구를 사용하도록 강제합니다.
여기 도구 목록을 보시면 특별한 GP 도구가 있습니다.
여러 이유가 있을 수 있어요.
보안이 큰 이유 중 하나라고 생각하고
샌드박싱도 그렇지만
토큰 제한 문제도 있죠.
독립적인 작업을 병렬로 실행하는 것
모델이 더 그렇게 하도록 유도하는 것이죠.
그리고 공백이 있는 경로를 인용하는 것 같은
사소한 것들도 있습니다.
그냥 일반적인 문제들이에요.
Anthropic에서 많은 도그푸딩을 하고 있고
문제를 발견하면
"좋아, 시스템 프롬프트에 넣자"라고
하는 것 같아요.
자, 이제 투두 리스트에 대해 이야기해봅시다.
다시 말하지만, 매우 일반적인 기능이지만
예전에는 일반적이지 않았던 기능입니다.
실제로 투두 리스트라고 생각해요.
이는 실제로 투두 리스트입니다.
제가 이 슬라이드 덱을 위한 연구에서
얻은 내용입니다. 하지만
투두 리스트에서 정말 흥미로운 점은
구조화되어 있지만
구조적으로 강제되지는 않는다는 것입니다. 규칙들을 보면
한 번에 하나의 작업만 하고, 완료되면 표시하라는
예상할 만한 내용들이죠.
진행 중인 작업에 계속 집중하고, 차단이나
오류가 있으면
작업을 다른 지시사항들로 나누라는 것들입니다.
하지만 가장 흥미로운 점은
이것이 결정론적으로 강제되지 않는다는 것입니다.
순전히 프롬프트 기반이에요.
순전히 시스템 프롬프트에 있고,
순전히 우리 모델들이
이제 지시 따르기를 잘하기 때문입니다.
이건 1년 전에는 작동하지 않았을 것이고,
2년 전에도 작동하지 않았을 겁니다.
시스템 프롬프트 상단에 도구 설명이 있고,
투두를 시스템 프롬프트에
주입하는 방식입니다.
실제 코드에서 강제되지는 않지만
그럼에도 작동합니다.
다른 경로를 택하는 에이전트들도 있을 수 있지만,
저는 이게 꽤 흥미롭다고 생각했습니다.
적어도 사용자로서는 큰
차이를 만들어내는데,
심지어 보기에도
구현하기 매우 간단해 보였습니다.
거의 주말 프로젝트처럼
누군가가 만들어서 작동하는 것 같았어요.
물론 제가 틀릴 수도 있지만,
실제로는 단순한 함수 호출입니다.
처음 무언가를 요청하면,
추론이 이 투두 블록을 내보내고,
다음 슬라이드에서 그 구조를
보여드리겠습니다.
ID들이 있고, 어느 정도의
구조화된 스키마와 결정론이 있지만,
그냥 거기에 주입된 것뿐입니다.
여기 어떻게 보일 수 있는지의 예시입니다.
버전을 얻고, ID를 얻고,
투두의 제목을 얻고, 그리고 실제로
증거를 주입할 수 있습니다.
이것은 겉보기에는 임의의
데이터 덩어리들로 사용할 수 있는 것이고,
ID들은 그것이 참조할 수 있는
해시값들입니다.
제목은 사람이 읽을 수 있는 것이지만,
이것은 데이터를 구조화하는 또 다른 방법입니다.
그리고 여러분이 일할 때
책상을 정리하는 것과 같은 방식으로,
우리는 이렇게 모델을
정리하려고 시도하고 있습니다.
이렇게 해서 얻는 네 가지 이점이
있다고 생각합니다.
계획을 강제하고,
충돌 후 재개할 수 있고, 클로드 코드는 실패하죠.
UX가 이것의 큰 부분이라고 생각합니다.
사용자로서 어떻게 진행되고 있는지 알 수 있어요.
아무런 신호 없이 40분 동안
루프에서 돌기만 하는 게 아닙니다.
UX는 무시할 수 없는 요소입니다.
UX가 더 나은 코딩 에이전트로 만들지는 못해도,
우리 모두가 사용하기에는
더 나을 수 있습니다. 그리고 조종성 부분도 있습니다.
여기 후드 아래에 있던 두 가지 다른 부분이 있습니다.
비동기 버퍼인데, 그들은 이걸 H2A라고 불렀습니다.
이것은 IO 프로세스와 이를 추론으로부터
분리하는 방법, 그리고
터미널에서 보는 모든 것을
그냥 채워넣지 않는 방식으로
컨텍스트를 관리하는 방법에 관한 것입니다.
모든 것을 모델에 다시 넣지 않고 말이죠.
다시 말하지만, 컨텍스트가 여기서 우리의 가장 큰 적입니다.
이것이 모델을 더 바보로 만들 거예요.
그래서 압축과 요약을
어떻게 할지에 대해 조금 더 스마트하게 접근해야 합니다.
여기서 보시면 용량에 도달하면
중간 부분을 삭제하고
앞과 뒤 부분을 요약합니다.
그게 컨텍스트 압축기의 역할입니다.
제한은 92% 정도인 것 같습니다.
그럼 장기 저장은 어떻게 하는 걸까요?
실제로 이것이 제 생각에는 bash와
샌드박스의 또 다른 장점입니다.
여기서 예측을 하나 해보겠습니다.
모든 ChatGPT 창과
모든 Claude 창이 가까운 미래에
샌드박스를 갖게 될 것입니다.
장기 메모리를 저장할 수 있어서
훨씬 더 좋거든요.
저는 항상 이렇게 합니다.
깊이 있는 연구와 그런 것들을 위해
Claude 코드 스킬을 가지고 있고,
항상 마크다운 파일을 저장하라고
지시합니다.
컨텍스트가 짧을수록
더 빠르고 더 스마트하거든요.
이것이 제가 가장 기대하는 부분입니다.
우리는 이런 DAG가 필요하지 않습니다.
실제 예시를 하나 들어보겠습니다.
PromptLayer의 일부 사용자들은
고객 지원 에이전트 같은 다른 에이전트들을
기본적으로 모든 사람이 지난 2년 반 동안
이런 DAG를 구축해 왔습니다.
정말 미친 일이었어요.
수백 개의 노드가 있었는데,
이 사용자가 환불을 원하면 이 프롬프트로 라우팅하고,
저것을 원하면 저쪽으로 라우팅하고,
많은 분류 프롬프트들이 있었습니다.
이것의 장점은 환각이 일어나지 않는다는 것을
어느 정도 보장할 수 있고,
환불받으면 안 되는 사람들에게
환불이 일어나지 않는다는 것을 보장할 수 있다는 겁니다.
이것은 프롬프트 인젝션 문제를
해결하는 데 도움이 됩니다.
순전히 X 또는 Y로 분류하는
프롬프트에 있다면
인젝션은 별로 중요하지 않습니다.
특히 컨텍스트를 버린다면 말이죠.
지금은 그 공격 벡터를 다시 가져왔지만,
주요한 이점은
이런 엔지니어링의 복잡한 웹을
다룰 필요가 없다는 것입니다.
이런 것들을 개발하는 것이 10배 더 쉽고,
10배 더 유지보수하기 쉽습니다.
그리고 모델이 이제 좋아졌기 때문에
실제로 훨씬 더 잘 작동합니다.
이것이 핵심 포인트입니다.
모델을 믿으세요.
의심스러울 때는 모든 엣지 케이스를
생각하려고 하지 말고,
모든 if문을 생각하려고 하지 마세요.
그냥 모델이 탐색하고
알아내도록 믿으세요.
실제로 이틀 전인가 어제였나,
이번 주 어느 날에
저희 대시보드에서 브라우저 에이전트를
테스트하는 실험을 했습니다.
모든 버튼에 작은 제목을 추가해서
에이전트가 저희 웹사이트를
자동으로 탐색하는 데
도움이 되는지 보고 싶었습니다.
그런데 놀랍게도 더 나빠졌어요.
다시 실행해볼 수도 있고
제가 테스트에서 뭔가 잘못했을 수도 있지만,
에이전트가 PromptLayer를 탐색하는 것을 더 어렵게 만들었습니다.
오히려 더 안 좋아졌어요. 에이전트가 산만해졌거든요
제가 이 버튼을 클릭해야 한다고
그리고 저 버튼도 클릭해야 한다고
계속 지시했더니
뭘 해야 할지 몰라했어요. 그래서
탐색에 의존하는 게 더 나아요. 질문
있으신가요?
>> 네, 좀 반박해보겠습니다
>> 좋습니다. 인정하겠습니다
오늘 우리가 만드는 스캐폴딩이 현재 모델의
특성이나 한계를 해결하기 위한 것이라면
3-6개월 후엔 무용지물이 될 거예요
설사 그렇다 해도 지금은 조금이라도 도움이 되죠
어떻게 균형을 맞추시나요?
3개월짜리 문제를 해결하는 데
엔지니어링 리소스를 낭비하는 것과
>> 아주 좋은 질문입니다. 다시 정리하면
질문의 핵심은
현재 당면한 실제 문제를 해결하는 것과
모델이 지금은 못하지만
3개월 후엔 할 수 있게 될 것에
의존하는 것 사이의 트레이드오프죠?
케이스 바이 케이스입니다. 뭘 만드느냐에 따라 달라요
은행용 챗봇을 만든다면
좀 더 신중해야겠죠
제가 생각하는 적절한
절충점은 메인 루프와 툴 호출의
에이전트 패러다임을 사용하되
툴 호출을 매우 엄격하게 만드는 것입니다
이런 식이나
이것의 절반 정도 되는
툴 호출을 갖는 건 괜찮다고 봅니다
Claude Code가 읽기를
툴 호출로 사용하거나 GPT를
툴 호출로 사용하는 것과 같은 방식으로요
엣지 케이스의 경우
구조화된 툴에 넣어서
버전별로 평가할 수 있게 하는 거죠
이에 대해서는 나중에
더 자세히 얘기하겠지만
구조화된 툴에 넣으세요
나머지는
탐색 단계에서는 모델에게 맡기거나
시스템 프롬프트를 추가하세요
결국 트레이드오프이고 사용 케이스에
많이 의존하는데, 좋은 질문이라고
생각합니다. 감사합니다. 그럼 다시
Claude Code로 돌아가서
이런 것들을 다 없애고 있습니다
ML 기반 의도 탐지도 원하지 않고
ReAct도 원하지 않고
ReAct를 조금은 쓰지만
내장하고 싶지 않습니다
분류기도 원하지 않고요. 실제로
PromptLayer를 위해 오랫동안
제품을 개발했는데 결국 출시하지 않았어요
프로토타입 수준이었는데
LLM이 아닌 ML 기반
분류기를 프롬프트 파이프라인에서
LLM 대신 사용하는 것이었어요. 많은 사람들이
성공을 거뒀지만
비용이 엄청난 이슈가 아닌 이상
그리 도움이 되지 않을 것 같습니다
설사 그렇다 해도
작은 모델들의 비용은 계속 줄어들고 있어요
회사들 간의 금융 엔지니어링으로
토큰 비용을 지불하게 되죠
Claude는 또한 트리거 단계에서 스마트한 일을 합니다
think, think hard,
think harder, 그리고
ultra think가 제가 가장 좋아하는 것입니다
이를 통해 추론 예산, 즉
추론 토큰 예산을 또 다른
파라미터로 사용할 수 있게 됩니다
모델이 조정할 수 있는 매개변수입니다. 그리고
이것은 실제로 모델이 조정할 수 있지만
이것이 우리가 강제로 조정하게 하는 방법입니다.
반대로 하드 플래닝을 위해 도구 호출을 만들 수도 있고
실제로 이런 방식을 사용하는
코딩 에이전트들이 있습니다. 또는
사용자가 지정하게 하고
실시간으로 변경할 수도 있습니다.
이것이 가장 중요한 주제 중 하나입니다.
샌드박싱과 권한입니다.
솔직히 말하면, 이 부분은
저에게 가장 지루한 부분입니다.
저는 종종 YOLO 모드로
실행하거든요.
저희 팀의 일부 사람들은 실제로 로컬 데이터베이스를 전부 삭제했습니다.
그래서 조심해야 합니다.
물론 기업 고객들과는
YOLO 모드를 사용하지 않습니다만
이런 기능들은
해결될 것 같은 느낌이지만
작동 방식을 조금은 알아야 합니다.
인터넷에서 오는
프롬프트 인젝션의 큰 문제가 있습니다.
쉘 접근 권한을 가진 에이전트를 연결하고
웹 페치를 수행한다면
이는 꽤 큰 공격 벡터입니다.
그래서 컨테이너화가 필요하고
URL을 차단하는 기능이 있습니다.
Claude Code가 이 URL에서
가져올 수 있는지, 이 작업을 할 수 있는지
꽤 까다롭게 묻는 걸 볼 수 있습니다.
그리고 서브 에이전트로 전환합니다.
대부분의 복잡한 코드가
이 샌드박싱과 권한 설정에
들어있습니다.
bash 명령어를 게이트하는
전체 파이프라인이 있다고 생각합니다.
접두사에 따라 샌드박싱 환경을
거쳐가는 방식이 결정되고
다른 모델들은 이 부분에서
다르게 작동합니다.
하지만 이것이 Claude Code의 방식입니다.
마지막에 다른 방식들도 설명하겠습니다.
다음 주제는
서브 에이전트입니다. 이것은
컨텍스트 관리로 돌아가는 것이고
계속 돌아오는 문제인
컨텍스트가 길어질수록
에이전트가 더 멍청해진다는 문제입니다.
이것이 그에 대한 답입니다.
특정 작업을 위한 서브 에이전트를 사용하고
서브 에이전트의 핵심은 자체 컨텍스트를 가지고
결과만 피드백한다는 것입니다.
이렇게 해서 어수선하게 만들지 않습니다.
여기 네 가지 예시가 있습니다 - 연구자,
문서 리더, 테스트 러너, 코드 리뷰어
제가 앞서 말한 예시에서
웹사이트에 모든 태그를 추가해서
에이전트가 더 잘 작동하도록 했을 때
당연히 코딩 에이전트를 사용했고
먼저 문서를 읽고 그다음에 작업하라고 했습니다.
이것이 서브 에이전트에서 수행됩니다.
정보를 피드백하고
여기서 핵심은
에이전트의 포크와 그것을 메인 컨텍스트로
다시 통합하는 방법입니다.
여기 예시가 있습니다. 정말 흥미롭다고 생각합니다.
한두 가지를
지적하고 싶습니다. 태스크는
서브 에이전트입니다. 태스크에
두 가지를 제공합니다. 설명과 프롬프트입니다.
설명은 사용자가 볼 내용입니다.
그래서 태스크라고 말하고
기본 채팅 컨텍스트를 찾는다고
할 것입니다
인스턴스화 같은 것들이죠. 그리고
프롬프트에는 긴
문자열을 줄 건데, 이게 정말 흥미로운 부분은
이제 코딩 에이전트가
자체적으로 에이전트들을 프롬프팅하고 있다는 점입니다. 저도
실제로 이런 패러다임을 저희 제품용으로
구축한 에이전트에서 사용해봤습니다. 만약
에이전트가 이 문자열에 원하는 만큼
많은 정보를 넣을 수 있다면
그리고 다시 모델에 의존한다면
만약 이 작업이
오류를 반환하면 더 많은 정보를 넣고
문제를 해결하도록 하는 거죠.
경직되기보다는 유연한 게
더 좋습니다.
제가 이걸 구축한다면
문자열을 객체로 바꾸는 걸 고려해볼 텐데요
여기서 뭘 구축하느냐에 따라
실제로 더 구조화된 데이터를
제공하게 할 수도 있죠. 네. 이 프롬프트에
꽤 여러 문장이 있는 걸 보니까요.
이게 메인 에이전트에 있는 건가요?
메인 에이전트의 컨텍스트를
가져오는 건가요? 아니면
서브 에이전트가
메인 에이전트가 하는 일을
다시 읽어보고 나서 생성하는 중간 단계가 있는 건가요?
네, 맞습니다. 그러니까 질문은 작업이
여기서 프롬프트만 받는지 아니면
채팅 히스토리도 받는지인가요?
그런 질문인가요?
질문은 제가 메인 에이전트를 가지고 있는데
이 모든 것이 메인 에이전트의
시스템 프롬프트에 있어서
서브 에이전트를 어떻게 프롬프팅할지
알려주는 건가요? 아니오, 아니에요.
시스템에 있는 게 아니라
전체 컨텍스트에 있어요. 메인 에이전트의
모든 컨텍스트가 호출하는 작업에
들어가는 건지 아니면
작업의 구조를 말하는 건지요?
이 전체 JSON을 말하는 건가요?
네. 이건 툴 콜이에요. 작업이 무엇인지에 대한
툴 콜 구조가 메인 에이전트에 있고
이것들은 즉석에서 생성됩니다.
작업을 실행하려고 할 때
설명과 프롬프트를 생성하는 거죠. 작업은
툴 콜입니다. 병렬로 실행될 수 있고
그 결과를
반환하는 거죠. 도움이 되었으면 좋겠네요.
다시 시스템 프롬프트로 돌아가 볼까요.
클로드 코드 시스템 프롬프트의
일부 유출이 있었어요.
그래서 제가 이걸 기반으로 하고 있습니다.
온라인에서 찾을 수 있어요. 제가 그것에서
주목한 몇 가지 사항들이 있습니다. 간결한 출력.
당연히 너무 긴 건 주지 마세요.
여기 있는 건 없고 사용자가 원하는
작업을 그냥 하라는 겁니다.
텍스트 설명 대신
툴을 더 많이 사용하도록 유도하는 거죠.
분명히 우리 모두 코딩 에이전트를
구축해봤고 그럴 때 보통
"이 SQL을 실행하고 싶다"고 하죠. 아니에요,
툴을 사용하도록 유도하세요.
기존 코드와 매칭시키고,
주석은 추가하지 않기. 이건 저한테는
작동하지 않지만 명령을 병렬로
광범위하게 실행하고 할 일들
같은 것들이요. 시스템 프롬프트로
할 수 있는 넛지가 많이 있습니다.
하지만 보시다시피 정말 흥미로운 점은
앞서 질문하신 부분에 대해
DAG와의 트레이드오프가 어디에 있는지
루프에 대해서 말이죠.
이런 기능들을 보면 대부분
Claude Code를 사용하면서
"아, 이 부분만 좀 덜 하거나
이 부분만 좀 더 했으면 좋겠다"라고
말하는 사람들에게서 나온 것 같습니다.
그래서 프롬프팅이 중요한데,
반복하기가 너무 쉽고, 꼭 필수는 아니지만
"여기서 좀 더 설명해줬으면 좋겠다"고 하면
가끔씩 그렇게 해주는 정도죠.
좋습니다. 스킬에 대해 얘기해보죠.
스킬은 정말 훌륭한 기능이에요.
비교적 새로운 기능이고, 솔직히 저도
최근에야 확신을 갖게 되었어요.
이 슬라이드도 스킬로 만들었습니다.
기본적으로 아키텍처의 맥락에서
이 발표를 생각해보면,
확장 가능한 시스템 프롬프트라고
볼 수 있어요. 컨텍스트를
어지럽히고 싶지 않은 것처럼,
여러 다양한 유형의 작업들이 있고
훨씬 더 많은 컨텍스트가 필요할 때가 있죠.
이것이 Claude Code에게
더 많은 정보에 접근할 수 있는
몇 가지 옵션을 제공하는 방법입니다.
여기 몇 가지 예시가 있습니다. 저는
문서 업데이트용 스킬을 만들어서
제 글쓰기 스타일과 제품에 대해 알려주고 있어요.
문서 업데이트를 하고 싶을 때
그 스킬을 사용하라고 말하면 됩니다.
Microsoft Office 편집, Microsoft
Word와 Excel 같은 것들 말이에요.
저는 이걸 사용하지 않지만
많은 사람들이 사용하는 걸 봤어요.
파일을 역컴파일하는 것 같은데
정말 멋져요. Claude Code가
디자인 스타일 가이드를 처리할 수 있게 해줍니다.
이건 흔한 사용 사례죠. 심화 연구도 있어요.
얼마 전에 심화 연구에 대한
GitHub 레포나 기사를 넣고
"이걸 Claude Code 스킬로 재구축해줘"라고 했는데, 정말 잘 작동했어요. 놀라울 정도로요.
Unified diffing에 대해서는
별도 슬라이드로 다룰 만한 가치가 있다고 생각해요.
아마 너무 뻔해서
많이 설명할 필요는 없을 것 같지만
이 기능이 훨씬 더 좋게 만들어주고
토큰 제한도 줄이고, 속도도 빠르게 하며
제가 앞서 예시로 든
실수를 덜 일으키게 해줍니다.
에세이 전체를 다시 쓰는 것과
빨간 줄로 표시하는 것의 차이 같죠.
그냥 더 좋아요. 어떤 에이전트를 만들든
diffing 사용을 강력히 추천합니다.
Unified diff는 표준이에요.
이런 코딩 에이전트들을 살펴보니
일부는 자체적인 표준을 만들었더라고요.
Unified diff의 약간의 변형으로
항상 라인 번호가 필요하지 않기 때문이죠.
하지만 unified diff가 잘 작동해요.
질문이 있으신가요?
스킬로 돌아가서 말씀드리면...
Claude Code를 본 적이 있는지 모르겠지만
Claude Code가 노란색 텍스트로
코드가 4만 자를 넘으면
경고를 해주거든요. 그래서
"좋아, 이걸 스킬로 나눠보자"라고 했죠.
시간을 들여서 나눴는데
Claude가 제 스킬들을 다 무시했어요.
그래서 다시 넣었죠.
도대체 뭐가... 모르겠어요. 스킬이
전반적으로 잘못 이해되고 있는 건지
제가 뭔가 놓치고 있는 건지 모르겠네요.
이해할 수 있게 도와주세요.
네, 질문의 요지는...
Claude 코드 시스템인 Claude MD가 너무 길다고 알려줍니다. 그러면
스킬로 옮기는데, 그러면 이제
스킬을 인식하지 못하고
필요할 때 선택하지 않습니다.
필요할 때 말이죠.
>> 네.
그건 Anthropic 팀에게 문의하시면 될 것 같습니다.
하지만 그것도 좋은 예시입니다.
시스템 프롬프트의
>> 그게 의도였습니다. 스킬은
호출해야 하는 것이고, 에이전트가
항상 모든 스킬을 호출하면 안 되잖아요.
그렇죠?
>> 맞습니다. 각 스킬에 대한 설명을 모델에게 제공합니다.
또는 제공해야 하고, 각 스킬에 대한
한 줄 설명을 알려줍니다.
이론적으로는 완벽한 세상에서
모든 스킬을 항상 선택해야겠지만,
말씀하신 게 맞습니다. 저도
일반적으로 스킬을 직접
수동으로 호출해야 합니다. 하지만 이것이
언제 프롬프팅이 올바른 솔루션인지,
언제 DAG가 올바른 솔루션인지,
아니면 이것이 모델
훈련 문제인지에 대한 좋은 연결점이라고 생각합니다.
후훈련에서 조금 더
모델이 스킬을 호출하도록 훈련시켜야 할지도 모릅니다.
이는 거의 도구 호출과 같습니다.
언제 호출할지 알아야 합니다.
그래서 이것은 단지
아직 그렇게 좋지 않은 기능일 수 있지만,
패러다임은 매우 흥미롭습니다.
하지만 우리가 배우고 있듯이 완벽하지는 않습니다.
차이점에 대해 방금 얘기했고, 다음은 뭐가 있을까요.
이것은 좀 더 의견에 기반한 내용이지만,
제가 보는 이런 것들의 방향과
다음 혁신이 일어날 가능성이 있는 곳입니다.
그래서
여기에는 두 가지 사고방식이 있다고 생각합니다.
많은 사람들이 생각하기를
우리가 하나의 마스터 루프를 가지고
수백 개의 도구 호출을 하고,
단지 도구 호출이 훨씬 좋아질 거라고 합니다.
그럴 가능성이 높습니다. 저는
반대 견해를 가지고 있습니다.
도구 호출을 최대한
줄이고 그냥 bash로 돌아가서
스크립트를 로컬 디렉토리에
넣어야 한다고 생각합니다. 저는
많은 도구 호출 대신
하나의 메가 도구 호출을 지지합니다.
실제로는 하나가 아닐 수도 있습니다.
실제로 제가 전에 보여드린 슬라이드가
아마 좋은 리스트라고 생각하지만,
많은 사람들이 수백 개의
도구 호출이 필요하다고 생각합니다. 저는 그렇게 가지 않을 거라고 봅니다.
적응적 예산, 추론 조정,
우리가 이것을 조금 하고 있습니다.
thinking과 ultra think 같은 것들 말이죠.
하지만 추론 모델을 도구로 사용하는 것이
패러다임으로서 매우 합리적이라고 생각합니다.
우리 중 많은 사람들이
20배 빠른 모델과
약간 더 못한 결과를 트레이드오프하고
매우 좋은 모델을 위한 도구 호출을
할 수 있을 거라고 생각합니다.
그것은 우리가 많은 경우에
만들 트레이드오프라고 생각합니다.
아마 우리 플래너는 아닐 수도 있습니다. 아마 플래너에는
GPT-4o1 코덱스나 Opus로 먼저 가거나
새로운 Opus가 나올 때 그걸로 갈 수도 있습니다.
하지만
많은 혼합과 매칭을 할 수 있다고 생각하고
그것이 다음 프론티어라고 생각합니다.
그리고 마지막 프론티어는
우리가 배울 수 있는 것들이 많다고 생각합니다.
할 일 목록과 새로운 일급 패러다임들을
우리가 구축할 수 있는 스킬이 또 다른
일급 패러다임의 예시입니다. 우리가
시도해볼 수 있는 것들이죠. 완벽하게
작동하지 않을 수도 있지만
저는 새로운 발견들이
많이 있을 거라고 생각해요.
제 의견으로는 말이죠. 제가 그런 답을 가지고 있느냐? 잘 모르겠어요.
그래서 이제 이 발표의 후반부에서
다른 프런티어인 에이전트들과
그들이 설계한 다른 철학들에 대해
이야기하고 싶습니다.
그들이 선택한 철학들에 대해서요.
우리 모두는 장점이 있습니다. 조합해서 사용할 수 있죠.
우리가 에이전트를 구축할 때
원하는 대로 할 수 있고 최고의
것들로부터 배울 수 있습니다. 그리고
프런티어 랩들은 이런 면에서 정말 뛰어나죠.
제가 자주 돌아가는 것이 있는데
AI 테라피스트 문제라고 부르는 것입니다.
더 나은 이름이 있을지도 모르겠지만
많은 문제들이 있다고 생각해요.
가장 흥미로운 AI 문제들은
전역 최대값이 없다는 것입니다.
즉
여기는 뉴욕시입니다. 제가
치료사를 만나야 한다면, 이 블록에만
여섯 명이 있어요. 최고의 치료사가
무엇인지에 대한 전역적 답은 없습니다.
다양한 전략이 있죠. 명상을 하는
치료사나 CBT를 하는 치료사가 있고
아야와스카를 주는 치료사도 있을 거예요.
이런 것들은 모두
같은 목표를 위한 다른 전략들입니다.
AI 치료사를 구축할 때도
전역 최대값이 없는 것과 같은 방식으로요.
이것이 제 반AGI적 관점이기도 하지만
이런 애플리케이션을 구축할 때
취향이 많이 개입된다고 말하는
관점이기도 하고, 설계 아키텍처가
매우 중요하다는 것이죠.
모두 놀라운 다섯 개의 서로 다른
코딩 에이전트를 가질 수 있어요. 오늘날
어떤 것이 최고인지 아무도 모릅니다.
솔직히 어떤 것이 최고인지 아무도 모릅니다.
Anthropic도 모르고, OpenAI도
모르고, Sourcegraph도 모릅니다.
누가 최고인지 아무도 모르지만
어떤 것들은 특정 분야에서 더 뛰어납니다.
개인적으로는 Claude Code가 좋다고 했듯이
로컬 환경을 실행하거나
git을 사용하거나 이런 종류의
상호작용이 필요한 인간 활동들에서 말이죠.
하지만 어려운 문제들은 Codex로 가거나
더 빠르기 때문에 Cursor의 Composer로 갑니다.
기본적으로 이 모든 것이 말하는 것은
여기서 다른 철학을 갖는 것에 가치가 있다는 것입니다.
그리고 이것에 하나의 승자만
있을 거라고 생각하지 않습니다.
다른 사용 사례들을 위한
다른 승자들이 있을 거라고 생각해요.
그리고 이것은 코딩 에이전트만이 아닙니다.
모든 AI 제품들입니다. 이것이
우리 회사 전체가 도메인
전문가들과 PM, 그리고
주제 전문가를 참여시키는 데
집중하는 이유입니다. 그것이 바로
방어 가능성을 구축하는
방법이기 때문입니다.
여기 관점들이 있습니다. 제가 보기에는
이것이 코딩 에이전트의 완전한 목록은 아니지만
제가 생각하기에 가장 흥미로운 것들입니다.
Claude Code는 제 생각에는
제게는 승리한다고 생각합니다
사용자 친화성과 단순성에서 말이죠.
말씀드렸듯이 만약 제가 뭔가를 하고 있다면
많은 애플리케이션이 필요한 작업에서 git이
git이 최고의 예시죠. 만약 제가
PR을 만들고 싶다면 Claude 코드로 갈 거예요.
음, 컨텍스트 관리에 정말 뛰어나요.
강력하게 느껴져요. 제가
더 강력하다는 증거를 보여드릴 수 있나요?
아마도 그렇지 않을 겁니다. 하지만
저에게는 그렇게 느껴지고 시장도 그렇게 느끼죠.
여기서 완전히 다른 대화가 있습니다
시장이 가장 잘 안다고 말하는 것과
사람들이 이야기하는 것이 최고라는 것이지만
그들도 알고 있는지는 모르겠어요. Cursor
IDE는 그런 관점에서 모델
불가지론적이에요. 더 빠르죠. Factory에서
Droid를 만들어요. 훌륭한 팀이죠. 그들도 여기 있었어요.
그들은 여러 개를 가지고 있어요. 정말로
이 droid 하위 에이전트들을 전문화시켜요.
그들이 가지고 있는 것이죠. 그래서 그게 그들의 강점이고
그것도 DAG 대화일 수 있거나
아니면 모델 훈련일 수도 있어요. 음, cognition.
Devon은 이런 end-to-end
자율성 자기 성찰 AMP인데 이에 대해서는
잠시 후에 더 자세히 이야기할게요. 그들은
많은 흥미로운 관점을 가지고 있고
실제로 저는 그들이 매우 흥미롭다고 생각해요
요즘에는 free는 모델 불가지론적이고
사용자를 위한 많은 UX 기능이 있어요. 그리고
실제로 저는 그들의 디자인을 사랑해요.
이 컨퍼런스에서의 그들의 발표들
그들은 매우 매우 독특한
관점을 가지고 있어요. 그러면 codeex부터 시작해봅시다
인기 있는 툴이니까요.
Claude 코드와 꽤 비슷해요.
같은 마스터 while 루프죠. 대부분이 그렇게 하는데
그게 바로 승리하는
아키텍처니까요. 흥미롭게도 rust
코어죠. 멋진 점은 오픈
소스라는 것이에요. 실제로 codeex를 사용해서
codeex가 어떻게 작동하는지 이해할 수 있어요
제가 한 일이 그런 거예요. 조금 더
이벤트 기반적이고 조금 더
동시 스레딩 작업이 들어갔어요.
제출 큐, 이벤트 출력 같은
제가 이야기했던 것들
Claude 코드의 IO 버퍼에 대해서요.
그들은 조금 다르게
한다고 생각해요. 샌드박싱은 매우
다릅니다. 그들의 것은 더... 제 말은
여기서 보실 수 있듯이 Mac OS seat belt와
Linux land로 그들의 것은 더 커널 기반이고
그리고 상태는 이런... 모든 것이
스레딩과 권한 하에 있고
제가 말하고 싶은 것은 대부분 다르다는 것이고
그리고 진짜 차이점은 정직히 말해서
모델이에요. 이것은
실제로 제가 Claude 코드를 사용해서
codeex가 어떻게 작동하는지 이해한 것입니다.
보시면 몇 개의 explore가 있어요. explore에 대해서는 이야기하지 않았지만
그것은 또 다른 하위 에이전트 유형입니다
제가 언급했듯이 이것들은 들어가고 나가요. 하지만
네, 이것은 codeex를
Claude 코드로 연구하는 것입니다.
항상 재미있는 일이에요.
그럼 AMP에 대해 이야기해봅시다.
이것은 소스그래프의 코딩 에이전트예요.
무료 티어가 있어요. 제 생각에는 멋진
관점입니다. 그들은
이런 여분의 토큰들을 활용해요
제공업체들로부터 말이죠. 그리고 광고를 보여줍니다. 그래서
실제로 저희가 그들에게 광고를 내고 있어요. 저는
그게 멋지다고 생각해요. 저는 광고 찬성파예요. 많은 사람들이
광고 반대파에요. 이게 제 특이한 견해 중 하나인데
저는 좋아해요. 모델 선택 옵션이 없어요.
이것도 아주 흥미롭고
독특한 관점이에요.
실제로 이게 그들의 개발 속도를 높여줘요.
결과물에 대한 정확한 기대치가 줄어들기 때문이죠.
왜냐하면 그들이 모델을 계속
바꾸고 있을 수 있거든요.
그래서 이것이 그들의 개발 방식을 바꿔놓죠.
그리고 그들의 비전도 상당히 흥미로워요.
음
그들의 비전은 단순히 최고의 에이전트를 만드는 것이 아니라
가장 많은 에이전트 친화적 환경에서
작동하는 에이전트를 만드는 것이에요.
실제로 Factory에서도 이와 비슷한
발표를 했었는데
밀폐된 코딩 리포지토리를 어떻게 구축하느냐
에이전트가 테스트를 실행할 수 있는
피드백 루프를 어떻게 구축하느냐
이게 성배 같은 것이고
자율 에이전트를 만드는 방법이며
프론트엔드 버전도 보고 싶어요.
자기 디자인을 보고 개선하게 하고
계속 반복하게 하는 것
이것이 그들의 핵심 철학이고
제가 에이전트 관점이라고 부르는
것으로 요약할 수 있어요.
그들이 컨텍스트로
하는 것도 흥미로워요.
우리 모두 compact에 익숙하잖아요.
정말 최악이에요. 10초나 기다려야 해요.
왜 이렇게 오래 걸리는지 모르겠어요.
모르시는 분들을 위해 설명하면
컨텍스트가 너무 커지면 채팅창을 요약하고
요약본을 제공하는 기능이에요.
그들에게는 handoff라는 게 있는데
이전에 콜 오브 듀티 해본 분이라면
기억하실 거예요. 무기 교체가
재장전보다 빠르다는 걸.
그게 바로 handoff예요.
새로운 스레드를 시작하고
거기에 필요한 정보만 주는 거죠.
새 스레드에 말이에요.
제게는 이게 승리 전략 같아요.
틀릴 수도 있지만, 아마 둘 다 필요할 수도 있고
그게 그들이 추진하는 방향이에요.
저는 그게 좋아요.
정말 신선한 관점을 제공해요.
두 번째는 모델 선택이에요.
이것은 추론 조절 기능이고
그들의 관점이에요.
빠름, 스마트, 오라클이 있어요.
다른 모델들을 사용한다는 점에 더 집중하고
오라클이 뭔지는 알려주지 않아요.
사실은 알려주긴 하지만
오라클이 무엇인지 바꿀 용의가 있고
아주 어려운 문제가 있을 때
오라클을 사용할 거라는 거죠.
네, 그게 AMP예요. 이제 Cursor의 에이전트로 넘어가죠.
Cursor의 에이전트는 정말 흥미로운 관점을 가지고 있어요.
첫째로, 당연히 UI 우선이에요.
CLI가 아니라요. CLI도 있을 수 있지만
확실하지는 않아요. 하지만 UI가
흥미로운 부분이에요.
정말 빨라요. 새로운 모델 컴포저는
distilled되어 있어요.
그들은 데이터를 가지고 있어요.
제 생각에는 사람들이 파인튜닝에
다시 관심을 갖게 만들었어요.
파인튜닝은 거의 우리가 고객들에게
추천하지 않던 것이었는데
컴포저는 실제로 가능하다는 걸 보여줘요.
데이터 기반의 방어력을 구축할 수 있다는 걸 보여주는데
이건 정말 놀라운 일이죠. 하지만
커서의 에이전트 컴포저는
너무 빨라서 거의 완전히 갈아탔어요
정말 빠르거든요
너무 빨라서 문제인 게
실수로 개인 프로젝트 마스터에 푸시까지 해버렸어요
그런 건 원하지 않았는데 말이죠
커서는 정말 모두의 사랑을 받고 있고
팀에게 박수를 보내고 싶어요
정말 점진적으로 개발했거든요
커서의 첫 번째 버전은 정말 형편없었어요
그래도 VS 코드 포크라서 써봤는데
잃을 게 없잖아요
그런데 지금은 정말 좋아졌어요
정말 훌륭한 소프트웨어고
팀도 훌륭하죠
하지만 OpenAI의 코덱스 모델들도
마찬가지라고 생각해요
속도는 조금 느리지만
코딩 에이전트에 최적화되어 있고
디스틸된 모델이거든요
OpenAI에서도 정말 빠른 모델을
내놓을 수 있다고 봐요
그들도 데이터를 가지고 있으니까요
여기 사진이 하나 있는데
블로그에 올린 사진이에요
코딩 에이전트에 대한 그들의 관점을
여기서 볼 수 있어요
세 개의 모델을 보여주는 걸로
알 수 있죠
컴포저를 제공하지만
최첨단 모델도
사용할 수 있게 해줘요
GPT-5.1이 계획 수립에 더 나을 수도 있다는 걸
알고 있거든요. 여기선 5라고 했지만 지금은 5.1이 있죠
그래서 큰 질문은
우리가 어떤 걸 써야 하냐는 거예요
어떤 아키텍처가 최고일까요?
뭘 해야 할까요? 제 의견으로는
벤치마크는 거의 쓸모없어요
벤치마크는 이제 모델 제공업체들의
마케팅이 되어버렸어요
모든 모델이 벤치마크를 이긴다고 해요
어떻게 그런 일이 일어나는지 모르겠지만
평가가 중요한 세상이 있다고 생각해요
그리고
문제는 뭘 평가할 수 있느냐예요
제가 계속 추진해온 이 단순한 while 루프 아키텍처가
실제로는 평가를 더 어렵게 만든다는
점이 문제예요. 모델의 유연성에
더 의존하게 되면
어떻게 테스트하나요?
통합 테스트나 엔드투엔드 테스트를 실행해서
문제를 해결하는지만 확인할 수 있어요
그게 한 가지 방법이죠
나누어서 할 수도 있고
특정 시점의 스냅샷을 찍어서
반쯤 끝난 대화에서
특정 도구 호출을 해야 하는 상황의
컨텍스트를 챗봇에 주고
테스트를 실행할 수 있어요
아니면 백테스트를 실행해서
얼마나 자주 도구를 바꾸는지
확인할 수도 있어요
여기서 또 다른 개념이 개발되고 있는데
에이전트 냄새라고 부르거나
적어도 제가 그렇게 부르고 있어요
에이전트를 실행해서
몇 번이나 도구를 호출하는지 확인하는 거죠
몇 번이나 재시도하는지
얼마나 시간이 걸리는지
이런 건 다 표면적인 지표지만
정상성 확인에는 정말 좋아요
그리고
이런 것들은 평가하기가 어렵습니다. 여기에는
많은 것들이 관여하죠. 제가 한 예시를
보여드리겠습니다. 좀 더 자세히 알아보기 위해서요.
하지만 이 주제에 대해
한 가지 더 말씀드리고 싶은 게 있습니다.
제 사고 모델로 정리하면
엔드투엔드 테스트를 할 수도 있고,
특정 시점 테스트를 할 수도 있습니다. 제가
가장 자주 추천하는 것은 백테스트입니다.
백테스트부터 시작하세요.
기록 데이터를 수집하기 시작하고
그냥 재실행하면 됩니다. 자, 이 예시를
보여드리겠습니다. 기본적으로 여기 있는 것은
PromptLayer의 스크린샷입니다.
이것이 저희 평가 제품이고
배치 러너이기도 합니다. 여러
컬럼들을 프롬프트를 통해
실행할 수 있습니다. 하지만 이 경우에는
프롬프트가 아닌 Claude Code를 통해
실행하고 있습니다. 헤드리스 Claude Code가 있고
이 모든 제공업체들을 가져와서 제 헤드리스
Claude Code가 다음과 같이 말합니다. 다음
슬라이드에 있을 것 같은데요. 모델
제공업체를 웹에서 검색하라고 합니다.
파일 변수로 주어집니다.
가장 최근에 출시되고 가장 큰 모델을 찾아서
이름을 반환하라고 합니다.
무엇을 하고 있는지 모르겠습니다.
웹 검색을 하고 있습니다. 저는
그것에 대해 신경쓰지도 않습니다.
이것이 엔드투엔드 테스트입니다. 이렇게 Claude Code를
시도해보는 방법입니다. 실제로
Claude Code를 워크플로우에
통합하는 것과 이런 유형의 헤드리스 SDK에 대해
할 말이 많습니다. 다음 슬라이드에서
이야기할 것 같습니다. 하지만
여기서 핵심은 엔드투엔드 테스트를
시작할 수 있다는 것입니다. 높은 수준에서
살펴보고 모델 스멜을 수행한 다음
각 행의 통계를 살펴보고
도구를 몇 번 호출했는지 확인할 수 있습니다.
그리고 돌아가서, 이 강연에서
이에 대해 많이 이야기했죠. 엄격한 도구들.
도구들은 엄격하게 테스트될 수 있습니다.
이것이 결정론을 오프로드하는 방법입니다.
이것이 결정론을 모델의
다른 부분으로 오프로드하는 방법입니다.
도구를 테스트합니다. 도구의
결과를 테스트합니다. 함수처럼
보세요. 입력과
출력이 있습니다. 만약 도구가
실행되는 하위 에이전트라면,
여기서 재귀가 발생합니다. 그러면 다시 돌아가서
엔드투엔드를 테스트해야 합니다.
하지만 도구의 경우, 이 예시를
들어드리겠습니다. 제 코딩 에이전트나
일반적인 에이전트, 자율적인 에이전트에서
매우 구체적으로 출력하고 싶은 것이 있다면
예를 들어, 매우 구체적인 유형의
이메일 형식이나
작성하고 싶은 블로그 포스트 유형이 있고
정말로 제 목소리를 제대로 구현하고 싶다면,
모델 탐색에 의존하고 싶지 않습니다.
실제로 엄격하게 테스트할 수 있는
도구를 구축하고 싶습니다.
이 경우, 이것도 PromptLayer
스크린샷이지만, 제가 구축한
워크플로우입니다. 이메일이 제 기준에
맞는지 확인하는 LM 어설션이 있습니다.
좋다면 수정하고, 좋지 않다면
누락된 부분을 추가합니다.
헤더와 같은 부분들을 말이죠.
놓친 부분을 수정하고 같은 단계로 다시 작업합니다.
이것은 매우 간단한 예시입니다만,
저희는 SEO 블로그 포스트를 위한
다른 버전도 가지고 있습니다.
20개의 노드를 갖춘 버전으로,
심층 연구로부터 개요를 작성하고
결론을 수정하고 링크를 추가합니다.
명확한 비전이 있는 작업의 경우,
테스트하기가 훨씬 쉬워집니다.
보시다시피
이런 워크플로를 테스트하는 것은
단계가 적고 유연성도 낮습니다.
제가 만든 평가 방법이 있는데,
샘플 이메일들로 시작해서
실제로 프롬프트를 실행하고
에이전트 워크플로를 실행한 후
여러 휴리스틱을 추가합니다.
매우 간단한 LLM 판단기로
3개 부분이 포함되어 있는지 확인합니다.
'안녕 재러드', 이메일 본문,
서명을 테스트했습니다.
훨씬 복잡하게 만들 수도 있고
코드 실행도 가능하지만
LLM 판단기가 보통 가장 쉽습니다.
이제 보시다시피
모든 케이스가 맞을 때까지 계속 실행하고
시간에 따른 평가 결과를 볼 수 있습니다.
이 예시에서는
100점을 달성했습니다. 재미있었어요.
미래 지향적인 내용을 하나 더 추가하고 싶습니다.
헤드리스 클로드 코드 SDK를 주목해 보세요.
오늘 아침에도 관련 발표가 있었죠.
그래서
너무 많은 시간을 할애하지는 않겠지만
정말 놀랍습니다.
간단한 프롬프트만 주면
파이프라인의 또 다른 부분이 됩니다.
제가 사용하는 용도는... 다음 슬라이드에 있는데
매일 문서를 업데이트하는
GitHub 액션이 있습니다.
다른 저장소에 푸시한
모든 커밋을 읽고, 많은 커밋이 있는데
클로드 코드를 실행합니다.
클로드 코드가 모든 저장소를 가져와서
업데이트된 내용을 확인하고
클로드 MD를 읽어서 문서를 업데이트해야 하는지 확인한 후
PR을 생성합니다.
이것이 많은 가능성을 열어준다고 생각하고
우리가 더 높은 추상화 수준에서
에이전트를 구축하기 시작할 가능성이 있습니다.
클로드 코드와 다른 에이전트들에 의존하여
많은 하드니스와 오케스트레이션을 처리하도록 하죠.
>> 그것들을 검토하시나요?
네,
PR을 생성하긴 하지만
PR을 병합하지는 않습니다.
자, 제가 얻은 교훈들입니다.
첫 번째, 모델을 신뢰하세요. 확신이 서지 않을 때는
에이전트를 구축할 때 모델에 의존하세요.
두 번째, 간단한 설계가 승리합니다.
첫 번째와 두 번째는
어느 정도 연결되어 있습니다. 세 번째, bash면 충분합니다.
도구는 간단하게 하세요. 40개 도구 말고
10개나 5개 도구를 사용하세요.
컨텍스트 관리가 중요합니다. 이것은
현재 에이전트에서 우리가 계속 피하려는
골칫덩어리입니다. 미래에는
컨텍스트를 훨씬 잘 다루는
새로운 모델들이 나올 수도 있습니다.
하지만 항상 한계가 있을 것입니다.
결국 인간과 대화하는 것이니까요.
하루에 너무 많은 사람을 만나면 이름을 잊어버려요.
그건 컨텍스트 관리 문제일 수도 있고
아니면 제 무능함일 수도 있어요. 잘 모르겠어요.
다섯 번째, 에이전트에서는 다양한 관점이 중요합니다.
저는 엔지니어링적 사고방식이
이 부분을 충분히 이해하지 못하는 경우가 많다고 생각해요.
특히, 저도 엔지니어이기 때문에
저 자신에 대한 이야기이기도 하지만
다양한 관점이 중요한 이유는
문제를 해결하는 여러 가지 방법이 있고
어느 한 방법이 다른 방법보다 나은 것이 아니라
아마도 여러 전문가들의 조합을
원할 것이기 때문입니다.
저는 제 에이전트가 Claude Code와 CodeX를 실행해서
결과를 제공하고 팀으로 간주되어
Slack 기반 메시지 채널에서
서로 대화할 수 있게 하는 것을 원해요.
누군가 그런 걸 만들어주기를 기다리고 있어요.
정말 좋을 것 같아요.
이것들이 제 주요 교훈입니다.
보너스로 제가 이 슬라이드 덱을
Claude Code를 사용해서 어떻게 만들었는지 보여드릴게요.
슬라이드 개발 스킬을 만들었어요.
기본적으로 Claude Code에게
슬라이드 개발이 어떻게 작동하는지 연구하라고 했어요.
그리고 그건 제가 이걸로 만든 라이브러리 같은 거예요.
이 모든 에이전트들과 작동 방식을 연구하기 위해
심층 연구 스킬을 만들었어요.
디자인 스킬도 만들었는데
뭔가가 끔찍해 보이는지 좋아 보이는지는 알지만
제가 좋은 디자이너가 아니라서
어떻게 해결해야 할지 모르거든요.
그래서 이런 박스들도 그냥
'오, 박스를 좀 더 예쁘게 만들어줘.
강조 색상을 넣어줘'라고 했어요.
네, 이렇게 만들었습니다.
다시 한번 들어주셔서 감사합니다.
질문이 있으시면 기꺼이 답변해드리겠습니다.
저는 Prompt Layer의 창립자 Jared입니다. 거기서 찾아주세요.
네.
감사합니다. 훌륭한 발표였어요.
DAG에 관해서 언급하셨는데
기본적으로 DAG를 없애자고 하셨잖아요
하지만 DAG는 순차적인 실행을 강제하잖아요.
예를 들어 고객 서비스에서
에이전트가 이름과 이메일을 물어보는 것처럼
어떤 순서로 실행되어야 하잖아요.
그래서 이걸 그냥 써야 한다는 말씀인가요?
이제 이것이 에이전트가 실행할 계획으로
그냥 작성되어야 하고
모델이 그 순서대로 도구를 호출할 것이라고
그냥 믿어야 한다는 건가요?
어떻게 순서를 강제할 수 있나요?
맞습니다. 질문은 제가 왜 계속
DAG를 없애자고 말하는지,
문제를 해결하기 위한 특정 순서를
어떻게 강제할 수 있는지에 대한 것이었습니다.
다양한 유형의 문제가 있다고 생각해요.
우리 모두가 사용할 수 있는
범용 코딩 에이전트를 만드는 문제는
비기술적인 사람들도 사용할 수 있도록 하는
문제를 해결하는 특정한 단계가 없기 때문에
모델에 의존하는 것이 더 낫습니다.
만약 여러분의 문제가
여행 일정을 만드는 것이라면
예를 들어 여행 일정을 만드는 것이라면
항상 동일한 결과물이 있기 때문에
좀 더 구체적인 단계가 됩니다.
따라서 중요할 수 있는 DAG가 조금 더 있지만
여행의 연구 단계에서는
아마도 DAG를 원하지 않을 것입니다.
왜냐하면 모든 도시가
다르기 때문입니다.
정말 다를 거예요. 그래서 정말로
해결하려는 문제에 따라 달라집니다. 만약
여행 일정을 위한 에이전트를 만들고 싶다면
아마 제 툴 호출 중 하나는
출력 파일을 만드는 DAG가 될 것입니다
왜냐하면 출력이
동일하게 보이길 원하거나 계획을 만들고 싶기 때문입니다. 그리고
시스템 프롬프트에서 예를 들어
항상 출력으로 끝내라고 말할 수 있습니다. 하지만
혼합하고 매치해야 합니다. 모든 사용 사례는
다르지만, 만약
범용적인 것을 만들고 싶다면
제 의견은 모델에 더 의존하고
간단한 루프에 의존하고 DAG에는 덜 의존하는 것입니다.
>> 좋네요. 다른 질문 있나요?
네.
>> 네.
그 점을 바탕으로, 우리가
실제로 코드를 통해 API를 호출하지 않고
대부분의
LM 호출이 클라우드 코드를 트리거하고
그냥 파일만 작성하는 세상으로 향하고 있다고 생각하시나요?
그냥 파일만
작성하는 대신에 말이죠?
그래서 질문은 우리가 모델을 직접 호출하는 것에서
벗어나서 헤드리스 클라우드 코드 같은 것을
호출하게 될 것인가, 맞나요?
>> 네. 만약 제가
문서당 하나의 LM 호출을 하는
파이프라인을 가지고 있다면, 마지막에 요약하죠. 당신은
매번 파일을 저장하는 while 루프 클라우드 코드를 만들 수 있습니다. API를
전혀 호출하지 않고
클라우드 코드만 사용해서
while 루프에서
>> 가능할 수 있습니다. 음, 거기에 장단점을
설명드리겠습니다.
>> 네,
>> 장점은 개발하기 더 쉽고 우리가
최첨단 기술에 의존할 수 있다는 것입니다.
생각해보면, 추론
모델이 바로 그런 것입니다. 추론 모델들은
항상 존재했던 것은 아닙니다. 우리에게는 그냥 일반적인
LM 모델이 있었고 그런 다음 오, 이제 우리에게 01과
추론 모델이 있습니다. 그것이 바로
제 말은, 이것보다 조금 더 복잡하지만
기본적으로는 그냥
OpenAI 서버에서 계속
컨텍스트를 실행하다가 결국
출력을 제공하는 while 루프입니다. 마찬가지로
클라우드 코드 SDK는
더 많은 것들이 있는 while 루프입니다. 그래서
많은 빌더들이 오직
이런 에이전틱 엔드포인트만 다루게 될 것을 충분히 볼 수 있습니다. 심지어
모델 제공자가 모델을
에이전틱 엔드포인트로 릴리스하는 것도 볼 수 있습니다. 하지만
많은 작업들에 대해서는
조금 더 많은 제어를 원할 것입니다. 그리고
아마도 여전히 가능한 한 메탈에 가깝게 가고 싶을 것입니다. 그렇긴 하지만
아직도 컴플리션 모델을 원하는 많은 사람들이
있었는데 그건 결코 일어나지 않았고 아무도
더 이상 그것에 대해 이야기하지 않습니다. 그래서
모든 것이 그냥 이 SDK가 될 가능성이 매우 높지만
저는 수정구슬을 가지고 있지 않습니다
하지만 그것들이 제가
생각하는 방식입니다.
>> 네,
>> 강연 감사합니다. 음, 단순할수록 좋다고 말씀하셨는데
음, AI에서의 테스트 주도
>> 네,
개발, 스펙 주도 개발에 대해 어떻게 생각하시나요?
시도해보셨나요? 그것에 대해 어떻게
>> 에이전트를 구축하는 것에 대해서인가요 아니면 작업을
완료하는 것에 대해서인가요?
>> 코딩을 위해서요.
>> 코딩을 위해서요.
>> 코딩에 대해서요.
스펙 기반 개발에 대한 질문이네요.
에이전트와 함께하는 코딩을 위한 테스트 기반 개발 말이죠.
에이전트와 함께 코딩할 때요.
확신이 서지 않을 때는
좋은 엔지니어링 관행으로 돌아가라고 말하고 싶습니다.
그래서 만약 여러분이 그리고 전체 엔지니어링
테스트 기반 개발이
올바른 방법인지에 대한 논쟁이 있습니다.
어떤 사람들은 맹신하고
어떤 사람들은 그렇지 않아요.
그래서 정답은 없다고 생각합니다.
코딩 에이전트에게는 분명히
테스트 기반 개발이 더 쉽게 만들어줍니다.
제가 보여드린 것처럼 AMP의 소스 그래프의
전체 철학이 좋은 테스트를 구축할 수 있다면
팩토리도 그렇게 생각한다고 봅니다.
좋은 테스트를 구축할 수 있다면
코딩 에이전트가 훨씬 더 잘 작동할 수 있습니다.
그래서 제가 개인적으로 작업할 때는
계획 단계와
스펙 개발 단계에 꽤 많이 의존합니다.
그리고 더 간단한 작업들은
모델이 꽤 쉽게 처리할 수 있다고 생각합니다.
하지만 매우 간단한 수정을 한다면
그 단계를 건너뛸 것입니다.
만능 해결책은 없지만
여러분이 믿는 엔지니어링 원칙으로 돌아가세요.
확신이 서지 않을 때는 그렇다고 말하겠습니다.
앞서 시스템에 대해 이야기하셨는데
록 누수가 그냥
UI를 보는 것만으로도 가능한가요?
다운로드 번들을 보거나
프롬프트가 숨겨진 특별한 엔드포인트가 있나요?
엔드포인트 뒤에요.
네, 숨겨져 있다고 생각합니다.
숨겨져 있다고 생각해요.
실제로 흥미로운 기사가 있었는데
누군가가
코드엑스가 오픈 소스이기 때문에
OpenAI가 코드엑스 모델을 출시하기 전에
그것이 사용하고 있던 것을
오픈 소스 코드엑스를 해킹해서
모델에 커스텀 프롬프트를 주고
그것 없이도 모델을 사용할 수 있었어요.
네, 파고들 수는 있지만 일반적으로는
숨겨지려고 하고 또한 누군가가 게시한 게으름도 있죠.
그래서 거기 있어요.
그게 그 작업이지만 누군가는 찾았어야 했겠죠.
이게 문제인가요?
여러분 컴퓨터 어딘가에 있나요?
사실 그 답은 모르겠습니다.
그 답을 아세요?
네.
네.
여러분 컴퓨터에 있어요.
니코가 여러분 컴퓨터에 있다고 해요.
그래서 거기 있네요.
그럼 제가 보고 있던 프롬프트가
조금 오래된 것 같고 업데이트해야 할 것 같습니다.
하지만 질문은
프롬프트가 그들의 서버에 숨겨져 있는지
아니면 충분히 결심이 서 있다면 찾을 수 있는지였어요.
그리고 답은 그렇다인 것 같아요.
다른 질문 있나요?
네.
이게 마지막인가요?
이게 마지막 질문인가요?
그럴 수 있어요.
프롬프트 레이어에 대해 이야기해주시고
사람들이 어떻게 도움을 줄 수 있는지 말씀해 주세요.
네, 좋은 질문이네요.
잊고 있었어요. 감사합니다.
음, 네, 첫 번째로 저희는 채용 중입니다.
뉴욕의 매우 재미있고 빠르게 움직이는 팀에서
코딩 직업을 찾고 계신다면
X나 이메일로 jaredprompter.com으로 연락주세요.
저희는 뉴욕에 기반을 두고 있습니다.
저희는 AI 제품 구축 및 테스트를 위한 플랫폼이에요.
프롬프트 관리, 감사 가능성,
거버넌스, 이런 재미있는 것들을 위한 플랫폼이지만
로깅과 평가도 해요.
그리고 제가 보여드린 그 스크린샷들은
프롬프트 레이어에서 나온 것입니다.
AI 애플리케이션을 구축하고 있고
팀과 함께 구축하고 있다면
아마 프롬프트 레이어를 시도해봐야 할 것입니다.
여러분의 삶을 더 쉽게 만들어줄 거예요.
특히 팀이 클수록
더 협업하고 싶을수록
PM과 비기술직 사용자들과 더 협업하고 싶을수록
또는 그냥 기술 사용자들이라면
훌륭한 도구입니다.
여러분의 삶을 더 좋게 만들어줄 거예요.
적극 추천합니다. prompt layer.com이고
사용하기 쉽습니다.
그리고 이것이 제 쇼였습니다. 들어주셔서 감사합니다.
끝.