에이전트를 직접 만들고 싶다면 — Claude Code 개발팀이 알려주는 에이전트 설계의 핵심
2026년 2월 27일, Anthropic의 Claude Code 개발을 이끄는 Thariq Shihipar가 X에 긴 글 하나를 올렸습니다. 제목은 "Lessons from Building Claude Code: Seeing like an Agent". Claude Code를 만들면서 배운 에이전트 설계 교훈을 정리한 글입니다.
요즘 AI 에이전트라는 말이 넘쳐납니다. 그런데 정작 에이전트를 직접 만들어보려고 하면 어디서부터 시작해야 할지 막막합니다. "ChatGPT한테 API 호출 좀 시키면 에이전트 아닌가?"라고 생각할 수도 있습니다. 절반은 맞고 절반은 틀립니다.
Thariq의 글과 Anthropic이 공개한 여러 기술 자료를 바탕으로, 에이전트를 직접 설계하고 싶은 분들을 위해 핵심 개념을 정리했습니다. 현업 개발자에게 들어보니, 결국 에이전트 개발의 핵심은 "모델이 세상을 어떻게 보는지 이해하는 것"이라고 합니다.
에이전트, 정확히 뭐가 다른 건가
일반적인 AI 챗봇은 질문을 받으면 답변을 내놓고 끝입니다. 한 번의 주고받기로 완결되는 구조죠. 에이전트는 다릅니다. 스스로 생각하고, 도구를 선택하고, 실행하고, 결과를 확인하고, 다시 생각합니다. 목표를 달성할 때까지 이 순환이 계속됩니다.
Princeton과 Google 연구진이 제안한 ReAct 패턴으로 설명하면 이렇습니다.
컨텍스트 수집 → 생각(Thought) → 행동(Action) → 관찰(Observation) → 다시 생각 → ...
"파일에서 에러 로그를 찾아서 원인을 분석해줘"라고 요청하면, 에이전트는 이런 식으로 움직입니다. 먼저 어떤 파일을 봐야 할지 생각하고, grep으로 에러 로그를 검색합니다. 검색 결과를 읽고 패턴을 파악한 다음 관련 소스 코드를 열어봅니다. 그리고 원인을 분석해서 수정안을 제시합니다.
이 과정에서 모델은 여러 번의 도구 호출을 자율적으로 수행하고, 사람이 매번 다음 단계를 지시할 필요가 없습니다. 이 "자율적 도구 사용의 반복"이 에이전트를 챗봇과 구분 짓는 지점입니다.
다음 그림은 일반 챗봇과 에이전트의 동작 방식 차이를 보여줍니다.
챗봇은 질문-답변의 단방향 흐름으로 끝나지만, 에이전트는 생각-행동-관찰의 순환을 목표 달성까지 반복합니다. 이 순환 구조가 에이전트의 핵심입니다.
단순함이 이긴다 — 단일 루프 아키텍처
에이전트를 처음 설계할 때 흔히 빠지는 함정이 있습니다. 여러 AI 모델이 서로 대화하며 복잡한 작업을 나눠 처리하는 멀티 에이전트 시스템을 구상하는 것입니다. 멋져 보이지만, Claude Code 팀은 정반대의 길을 택했습니다.
Claude Code의 내부 구조를 분석한 PromptLayer 블로그에 따르면, Claude Code는 단일 스레드 마스터 루프로 동작합니다. 핵심 동작은 이렇게 단순합니다.
while (도구 호출이 있는 동안) { 도구 실행 결과를 대화 이력에 추가 모델에게 다음 행동 질의 } // 도구 호출 없는 일반 텍스트 응답이 나오면 종료
하나의 메시지 히스토리를 유지하고, 서브에이전트는 최대 1개만 허용합니다. 서브에이전트가 또 다른 서브에이전트를 만들 수 없어서 재귀적으로 확산되는 것을 원천 차단합니다. MinusX의 분석에 따르면 Claude Code는 "매 분기점에서 아키텍처 단순성을 선택했다"고 합니다.
이 접근법의 장점은 디버깅이 쉽다는 겁니다. 동작이 예측 가능하고, 문제가 생겼을 때 원인을 추적할 수 있습니다. 복잡한 다중 에이전트 시스템에서는 "왜 이렇게 동작했는지" 파악하기가 어렵거든요. 단일 루프에서는 메시지 히스토리를 처음부터 따라가면 모든 의사결정 과정이 드러납니다.
에이전트를 처음 만든다면 이 점을 기억해야 합니다. 단순한 루프 하나로 시작하세요. 복잡한 아키텍처는 이 구조가 한계에 부딪힌 다음에 고려해도 늦지 않습니다.
다음 그림은 Claude Code가 채택한 단일 루프 아키텍처의 동작 흐름입니다.
사용자 요청이 들어오면 LLM이 생각하고, 도구 호출이 필요하면 실행 후 결과를 대화 이력에 추가합니다. 도구 호출 없이 텍스트 응답이 나오면 루프가 종료됩니다. 단일 스레드, 단일 메시지 히스토리, 서브에이전트 최대 1개라는 제약이 오히려 디버깅과 예측 가능성을 높입니다.
행동 공간을 설계하라 — 도구가 곧 에이전트의 세계다
Thariq는 원문에서 이렇게 썼습니다. "에이전트 하네스 구축에서 가장 어려운 일은 행동 공간(action space)을 구성하는 것입니다."
행동 공간이란 에이전트가 사용할 수 있는 도구의 집합입니다. 사람에게 비유하면, 프로그래머가 사용할 수 있는 IDE, 터미널, 브라우저, 검색 엔진 같은 것입니다. 에이전트에게는 도구가 곧 세상을 조작하는 유일한 수단입니다.
Claude Code가 제공하는 도구를 계층별로 살펴보면 설계 의도가 보입니다.
읽기/탐색 쪽에는 파일 읽기(Read), 디렉토리 탐색(LS), 파일명 패턴 검색(Glob), 내용 검색(Grep) 등이 있고, 편집 쪽에는 부분 수정(Edit)과 전체 쓰기(Write)를 분리해뒀습니다. 실행 도구는 Bash 셸인데, 위험도를 분류해서 위험한 명령은 사용자 확인을 받도록 설계했고요. 이 외에 웹 검색(WebSearch), URL 내용 가져오기(WebFetch), 사용자에게 질문하기(AskUserQuestion) 같은 도구도 있습니다.
여기서 하나 눈여겨볼 게 있습니다. Bash 하나면 파일 읽기, 검색, 편집이 전부 가능합니다. 그런데도 Grep, Glob, Read를 별도 도구로 분리했거든요.
Anthropic의 컨텍스트 엔지니어링 문서에 따르면 "도구는 에이전트의 컨텍스트 윈도우에서 눈에 띄는 위치를 차지하기 때문에, 모델이 가장 먼저 고려하는 행동이 됩니다." 자주 사용하는 작업을 별도 도구로 만들면 모델이 그 작업을 더 정확하게 수행합니다. Bash에 grep -r "error" .이라고 쓰는 것보다 Grep 도구에 패턴을 넘기는 쪽이 실수가 적습니다.
도구를 설계할 때 지켜야 할 원칙이 있습니다. 비슷한 일을 하는 도구가 여러 개 있으면 모델이 어느 것을 써야 할지 혼란스러워합니다. 도구가 불필요하게 긴 결과를 돌려주면 컨텍스트 윈도우를 낭비하고요. 그리고 도구 설명(description)은 모델이 읽는 사용 설명서이기 때문에, 사용 의도를 명확하게 적어야 합니다.
에이전트를 직접 만들 때 이 부분에 가장 많은 시간을 쓰게 됩니다.
AskUserQuestion — 실패에서 배운 도구 설계 사례
Thariq의 글에서 가장 흥미로운 부분은 AskUserQuestion 도구의 탄생 과정입니다. 이 사례는 도구 설계가 왜 "시행착오의 연속"인지를 잘 보여줍니다.
Claude Code에는 Plan Mode라는 기능이 있습니다. 복잡한 작업을 수행하기 전에 먼저 계획을 세우고, 사용자의 승인을 받은 후 실행하는 모드입니다. 개발팀은 이 과정에서 Claude가 사용자에게 질문하는 능력을 개선하고 싶었습니다.
첫 번째 시도는 기존 ExitPlanMode 도구에 질문 파라미터를 추가하는 것이었습니다. "계획을 제출하면서 동시에 질문도 할 수 있게 하자"는 아이디어였습니다. 결과는 실패였습니다. Claude는 계획 제출과 질문이라는 두 가지 목적이 섞인 도구를 제대로 활용하지 못했습니다. 계획은 내놓는데 질문은 빠뜨리거나, 질문을 하면서 불완전한 계획을 제출하는 식이었습니다.
해결책은 완전히 별도의 도구를 만드는 것이었습니다. AskUserQuestion이라는 독립 도구를 만들어서 Claude가 작업 중 언제든 사용자에게 질문할 수 있게 한 겁니다. 이 도구가 호출되면 사용자 화면에 모달 팝업이 뜨고, 사용자가 답변할 때까지 에이전트 루프는 일시 중지됩니다. 구조화된 출력을 유도해서 Claude가 반드시 복수의 선택지를 제시하도록 설계했고요.
Thariq에 따르면 "Claude는 이 도구를 사용하는 것을 좋아하는 듯했고, 출력 품질도 좋았다"고 합니다.
이 사례에서 배울 수 있는 원칙은 분명합니다. 하나의 도구에 여러 목적을 넣지 마세요. 모델은 명확한 단일 목적의 도구를 가장 잘 활용합니다. 그리고 도구를 설계하고 나서 모델의 출력을 주의 깊게 읽어야 합니다. 모델이 도구를 이상하게 쓰고 있다면 모델의 문제가 아니라 도구 설계의 문제일 가능성이 높습니다.
점진적 공개 — 모든 정보를 한꺼번에 주지 마라
에이전트 설계에서 직관과 반대되는 부분이 하나 있습니다. 모델에게 정보를 많이 줄수록 성능이 좋아질 것 같지만, 실제로는 반대거든요.
Anthropic은 이것을 "컨텍스트 부패(Context Rot)"라고 부릅니다. 책상 위에 서류 3장만 올려놓으면 바로 찾을 수 있는데, 300장을 올려놓으면 오히려 필요한 한 장을 찾기가 더 어렵습니다. LLM의 어텐션도 같은 식입니다. 토큰이 늘어날수록 모델이 각 정보에 할당하는 주의(attention)가 분산됩니다. Anthropic의 컨텍스트 엔지니어링 문서에 따르면, 프로젝트의 모든 파일을 미리 읽어서 컨텍스트에 넣어두면 정작 필요한 정보를 찾는 능력이 떨어집니다.
Claude Code가 채택한 방식은 점진적 공개(Progressive Disclosure)입니다. 처음부터 모든 정보를 주지 않고, 에이전트가 필요할 때 스스로 찾아가게 합니다.
구체적으로 이런 식입니다. 프로젝트를 열면 Claude Code는 CLAUDE.md 파일만 먼저 읽습니다. 이 파일에는 프로젝트 구조와 규칙이 요약되어 있고, 더 자세한 정보가 있는 파일 경로도 적혀 있습니다. Claude가 특정 기능을 구현해야 하면, 관련 파일을 Glob으로 찾고, Grep으로 내용을 검색하고, Read로 읽어옵니다. 1년 전에는 이렇게 스스로 파일을 찾아다니지 못했지만, 이제는 여러 계층의 파일을 재귀적으로 탐색할 수 있게 되었다고 Thariq는 설명합니다.
자신의 에이전트에 적용하려면, 시스템 프롬프트에는 최소한의 핵심 정보만 넣고, 상세 정보는 도구를 통해 런타임에 가져오도록 설계하면 됩니다. CLAUDE.md 같은 "지도 파일"을 만들어서 프로젝트 전체를 한눈에 파악할 수 있는 요약을 제공하되, 세부 내용은 에이전트가 필요할 때 직접 찾아오게 하는 겁니다.
Anthropic의 공식 표현을 빌리면, "최소한의 고신호 토큰(high-signal token) 집합을 찾아 원하는 결과 달성 가능성을 최대화"하는 것이 목표입니다.
컨텍스트 관리 — 에이전트의 생명줄
에이전트가 장시간 작업을 수행하면 피할 수 없는 문제에 부딪힙니다. 컨텍스트 윈도우의 한계입니다. 아무리 큰 컨텍스트 윈도우를 가진 모델이라도 수십 번의 도구 호출을 거치면 이전 대화 내용이 밀려나기 시작하거든요.
Claude Code는 이 문제를 여러 층위에서 관리합니다.
먼저 컴팩션(Compaction)이 있습니다. 컨텍스트 사용량이 92%에 도달하면 자동으로 대화 내용을 요약합니다. 아키텍처 결정사항이나 미해결 버그 같은 핵심 정보는 보존하고, 중복된 도구 출력은 제거하는 식입니다.
다음으로 구조화된 노트(Todo List)가 있습니다. 에이전트가 스스로 작업 목록을 관리하는 건데, 컨텍스트 윈도우 바깥에 존재하는 외부 기억 장치 역할을 합니다. 작업 ID, 내용, 상태, 우선순위를 JSON 형태로 기록하고, 시스템 메시지를 통해 현재 상태를 지속적으로 모델에 주입합니다. 긴 작업 중에 "지금 내가 뭘 하고 있었지?" 같은 상황을 막는 장치죠.
마지막으로 서브에이전트 아키텍처입니다. 주 에이전트가 고수준 계획을 조율하고, 코드베이스 검색 같은 집중 작업은 서브에이전트에게 위임합니다. 서브에이전트는 수만 토큰을 사용할 수 있지만, 결과를 1,000~2,000 토큰의 압축된 요약으로 반환합니다. 메인 에이전트의 컨텍스트를 깨끗하게 유지하는 전략입니다.
자신의 에이전트를 만들 때도 이 문제를 피할 수 없습니다. 언제 요약할 것인가, 외부 기억 장치를 어떻게 구현할 것인가, 무거운 작업을 어떻게 분리할 것인가. 이걸 해결하지 않으면 에이전트는 긴 작업에서 반드시 길을 잃습니다.
다음 그림은 Claude Code가 사용하는 세 가지 컨텍스트 관리 전략을 정리한 것입니다.
컴팩션은 컨텍스트 사용량이 임계치에 도달하면 자동으로 대화를 요약하는 방식입니다. 구조화된 노트는 컨텍스트 윈도우 바깥에 존재하는 외부 기억 장치로, 작업 목록과 상태를 관리합니다. 서브에이전트는 무거운 작업을 위임받아 처리한 뒤 압축된 요약만 돌려주는 구조입니다.
프롬프트 캐싱 — 비용과 속도의 열쇠
설계 원칙만큼 중요한 것이 운영 현실입니다. 아무리 잘 설계된 에이전트도 비용이 감당이 안 되면 프로덕션에 올릴 수 없거든요. 에이전트는 일반 챗봇보다 훨씬 많은 API 호출을 발생시킵니다. 한 번의 사용자 요청을 처리하는 데 수십 번의 모델 호출이 필요할 수 있고, 비용은 늘고 지연시간은 길어지는 구조입니다.
Thariq는 Simon Willison의 블로그(2026.02.20)에 인용된 발언에서 이 문제의 해결책을 제시합니다. "장시간 실행되는 에이전트 제품은 프롬프트 캐싱을 통해 이전 왕복의 계산을 재사용할 수 있게 되며, 이는 지연시간과 비용을 상당히 감소시킵니다."
Claude Code는 전체 시스템을 프롬프트 캐싱 중심으로 설계했습니다. 에이전트 루프의 매 반복에서 시스템 프롬프트와 이전 대화 이력은 대부분 동일합니다. 새로 추가되는 것은 마지막 도구 호출 결과와 모델의 새 응답뿐입니다. 이전 부분을 캐싱하면 매번 전체를 다시 처리하지 않아도 됩니다. Thariq의 원문에 따르면, Anthropic은 캐시 히트율을 핵심 지표로 삼고, 이 수치가 떨어지면 심각한 경고를 보냅니다.
또 하나 흥미로운 부분이 있습니다. 외부 기술 블로그 MinusX의 역공학 분석에 따르면, Claude Code는 전체 LLM 호출의 50% 이상에서 Haiku 같은 소형 모델을 쓰는 것으로 추정됩니다. 공식 발표가 아니라 외부 분석이긴 하지만, 전략 자체는 합리적입니다. 대용량 파일 읽기, 웹 페이지 파싱, Git 이력 처리, 대화 요약 같은 작업에는 소형 모델로도 충분하고 비용은 대폭 줄어듭니다. 핵심 추론이 필요한 작업에만 대형 모델을 투입하는 셈이죠.
에이전트를 상용 제품으로 만들 생각이라면 프롬프트 캐싱과 모델 크기 분기, 이 두 가지는 반드시 설계에 반영해야 합니다. 이걸 빠뜨리면 비용 문제로 프로젝트가 좌초될 수 있습니다.
검증 루프 — 에이전트가 스스로 확인하게 하라
에이전트가 행동을 하고 나서 그 결과를 검증하지 않으면 실수가 누적됩니다. Anthropic의 Agent SDK 문서에서는 검증을 에이전트 루프의 독립적인 단계로 강조합니다.
검증 방식은 크게 세 가지입니다.
가장 기본적인 것은 규칙 기반 피드백으로, 코드 린터, 타입 체커, 테스트 실행 같은 것을 말합니다. 에이전트가 코드를 수정한 후 자동으로 린트를 돌리면 문법 오류나 스타일 위반을 즉시 잡을 수 있습니다. Claude Code는 코드 편집 후 자동으로 이런 검증을 수행합니다.
UI 관련 작업에서는 시각적 피드백이 유용합니다. 에이전트가 웹 페이지를 수정한 후 렌더링 결과를 캡처해서 의도한 대로 보이는지 확인하는 방식이죠.
LLM-as-judge도 있습니다. 다른 LLM이 결과물의 품질을 평가하는 건데, 톤이나 스타일 같은 정량화하기 어려운 기준에서 쓸 만합니다.
이 검증 단계를 빠뜨리면 에이전트는 확신에 차서 틀린 결과를 반복 생산합니다. 코드를 다루는 에이전트라면 린터와 테스트 실행을 검증 도구로 반드시 포함시켜야 합니다.
에이전트처럼 보는 법을 배워라
Thariq의 글에서 가장 인상적인 메시지는 제목 그 자체입니다. "Seeing like an Agent" — 에이전트처럼 보라.
도구를 설계하고 프롬프트를 작성할 때, 개발자는 자기 관점에서 생각하기 쉽습니다. "이 도구를 이렇게 만들면 내가 사용하기 편하겠지"라고 생각하는 거죠. 하지만 에이전트는 사람이 아닙니다. 모델은 도구의 설명(description)을 읽고, 파라미터의 이름과 타입을 보고, 어떤 도구를 어떤 순서로 호출할지 결정합니다.
Thariq가 권하는 방법은 이렇습니다. 에이전트의 출력을 주의 깊게 읽으세요. 모델이 도구를 어떤 순서로, 어떤 파라미터와 함께 호출하는지 관찰하세요. 이상한 패턴이 보이면 도구 설명이나 구조를 조정하고, 새로운 도구를 만들어서 실험해 보세요. 이 과정을 반복하면 점점 "모델의 눈"으로 자신의 시스템을 볼 수 있게 됩니다.
Claude Code 팀은 이 방식으로 1년 이상 도구를 반복 개선해왔습니다. 처음에는 Claude가 자기 컨텍스트를 구성하지 못했지만, 도구 설계를 다듬고 점진적 공개를 도입하면서 지금은 여러 계층의 파일을 재귀적으로 탐색할 수 있게 되었습니다. "도구 설계는 과학이자 예술이며, 사용하는 모델, 에이전트의 목표, 운영 환경에 따라 달라진다"는 것이 Thariq의 결론입니다.
직접 만들어볼 때 기억할 것
지금까지의 내용을 정리하면 이렇습니다.
멀티 에이전트 시스템이 아니라 while 루프 하나로 시작하세요. Claude Code처럼 "도구 호출이 있으면 실행하고 결과를 돌려주는" 단순한 루프가 생각보다 많은 것을 해냅니다. 그리고 에이전트의 능력은 모델의 지능이 아니라 도구의 품질에 좌우됩니다. 하나의 도구에 하나의 목적을 부여하고, 도구 설명을 명확하게 작성하는 데 가장 많은 시간을 쓰세요.
정보는 한꺼번에 주지 마세요. 에이전트가 필요한 정보를 필요한 시점에 가져오도록 설계하는 게 낫습니다. 컨텍스트 관리도 설계 초기부터 고려해야 합니다. 요약 전략, 외부 메모리, 서브에이전트 분리를 미리 계획해야 긴 작업에서 에이전트가 길을 잃지 않습니다.
무엇보다 에이전트의 출력을 읽으세요. 모델이 도구를 어떻게 사용하는지 관찰하고, 이상한 패턴이 보이면 도구를 조정합니다. 이것이 에이전트 개발에서 가장 중요한 습관입니다. 그리고 검증 단계를 빠뜨리지 마세요. 에이전트가 행동한 결과를 자동으로 확인하는 메커니즘이 없으면, 실수가 쌓여서 결과물의 품질이 급격히 떨어집니다.
에이전트 개발은 프레임워크 설치하고 API 연결한다고 끝나는 게 아닙니다. 모델의 관점에서 세상을 바라보고, 도구를 반복적으로 다듬고, 실패에서 배우는 과정입니다. Claude Code를 만든 팀이 1년 넘게 이 과정을 거쳐왔다는 사실 자체가, 이 일이 만만치 않다는 걸 말해줍니다.
가장 좋은 시작은 작은 에이전트를 하나 만들어보는 것입니다. 아래는 Anthropic의 Python SDK로 구현한 최소한의 에이전트 루프입니다. 파일을 읽고 요약하는 에이전트로, 앞서 설명한 "단일 루프 아키텍처"의 실제 구현입니다.
import anthropic client = anthropic.Anthropic() tools = [ { "name": "read_file", "description": "파일을 읽어서 내용을 반환합니다.", "input_schema": { "type": "object", "properties": { "path": {"type": "string", "description": "읽을 파일 경로"} }, "required": ["path"] } } ] def execute_tool(name, tool_input): if name == "read_file": with open(tool_input["path"]) as f: return f.read() return "알 수 없는 도구입니다." messages = [{"role": "user", "content": "src/main.py 파일을 읽고 핵심 로직을 요약해줘"}] while True: response = client.messages.create( model="claude-sonnet-4-20250514", max_tokens=1024, tools=tools, messages=messages ) # 도구 호출이 없으면 최종 응답 출력 후 종료 if response.stop_reason == "end_turn": for block in response.content: if hasattr(block, "text"): print(block.text) break # 도구 호출이 있으면 실행하고 결과를 대화에 추가 messages.append({"role": "assistant", "content": response.content}) tool_results = [] for block in response.content: if block.type == "tool_use": result = execute_tool(block.name, block.input) tool_results.append({ "type": "tool_result", "tool_use_id": block.id, "content": result }) messages.append({"role": "user", "content": tool_results})
30줄 남짓한 코드이지만 에이전트의 핵심 구조가 모두 들어 있습니다. while 루프가 돌면서 모델에게 질의하고, 도구 호출이 있으면 실행하고 결과를 돌려주고, 도구 호출이 없는 일반 텍스트 응답이 나오면 종료됩니다. 앞서 설명한 의사코드와 정확히 같은 구조죠.
여기에 도구를 더 추가하면 됩니다. Grep 도구를 넣으면 코드 검색이 되고, Write 도구를 넣으면 파일 수정이 됩니다. 검증 루프를 넣고 싶으면 린터 실행 도구를 추가하면 되고요. 이 단순한 구조 위에 도구를 하나씩 얹어가는 것이 에이전트 개발의 실제 과정입니다.
처음 만드는 에이전트라면 이렇게 시작하는 것을 권합니다. 단일 while 루프를 구현하고, 도구는 3개 이내(읽기, 검색, 실행 정도)로 시작합니다. 시스템 프롬프트에는 핵심 규칙만 넣고, 상세 정보는 도구를 통해 가져오게 하세요. 검증 도구도 최소 1개는 포함하는 게 좋습니다. 코드 에이전트라면 린터 실행이 좋은 시작점이고요. 그리고 에이전트의 도구 호출 로그를 반드시 출력하세요. 이것이 "에이전트의 눈으로 보는" 첫걸음입니다. 이상한 패턴이 보이면 코드가 아니라 도구 설명을 먼저 고치세요.
이렇게 시작해서, 에이전트의 출력을 읽으면서 도구를 다듬어 가면 됩니다. Claude Code 팀이 1년 넘게 해온 것이 정확히 이 과정입니다.
참고 자료
- Thariq Shihipar, "Lessons from Building Claude Code: Seeing like an Agent" (2026.02.27)
- Anthropic, "Building agents with the Claude Agent SDK"
- Anthropic, "Effective Context Engineering for AI Agents"
- PromptLayer, "Claude Code: Behind the scenes of the master agent loop"
- MinusX, "What makes Claude Code so damn good"
- Simon Willison's Weblog, Thariq Shihipar 인용 (2026.02.20)
댓글
댓글을 작성하려면 이 필요합니다.