Claude Code가 보여준 에이전트 설계 방향은

최근 UCL 연구진이 Claude Code의 구조를 분석한 논문을 공개했다. 논문의 제목은 Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems다.

이 분석이 흥미로운 이유는 단순히 Claude Code가 어떤 기능을 가지고 있는지를 보여주기 때문이 아니다. 오히려 이 자료는 앞으로 AI 에이전트를 어떻게 설계해야 하는지에 대한 중요한 힌트를 준다.

가장 눈에 띄는 숫자는 Claude Code 코드베이스에서 AI 의사결정 로직은 단 1.6% 에 불과했으며, 나머지 98.4%는 운영 인프라였다. 여기서 말하는 운영 인프라는 단순한 보조 코드가 아니다. 권한 관리, 도구 라우팅, 컨텍스트 압축, 복구 로직, 세션 지속성, 확장 메커니즘 같은 것들이다. 다시 말해 모델은 추론을 담당한다. 하지만 실제 제품으로서 에이전트를 안전하고 안정적으로 굴러가게 만드는 것은 모델 바깥의 하네스다.

많은 사람들은 AI 에이전트를 만들 때 모델의 추론 능력, 프롬프트, 플래너, 멀티에이전트 구조에 먼저 집중한다. 물론 이것들도 중요하다. 하지만 Claude Code의 구조를 보면 진짜 차별화는 모델 그 자체가 아니라, 모델을 둘러싼 실행 환경에서 나온다는 것을 알 수 있다.

Claude Code의 핵심 루프는 생각보다 단순하다. 모델을 호출하고, 도구를 실행한다. 그런후 다시 모델을 호출하고 이 과정을 반복한다. 말하자면 단순한 while true 구조다.

하지만 중요한 것은 이 단순한 루프를 둘러싼 시스템이다. Claude Code의 복잡성은 루프 안에 있는 것이 아니라 루프 주변에 있다. Claude Code에는 여러 단계의 권한 모드가 존재한다. 사용자가 매번 승인할지, 일부 편집을 자동 승인할지, 더 넓은 범위의 자동 실행을 허용할지 등을 세밀하게 나눈다. 흥미로운 점은 사용자가 권한 요청의 대부분을 승인한다는 사실이다.

사용자가 어차피 대부분의 경고창을 승인한다면, 경고창을 더 많이 띄우는 것은 좋은 보안 설계가 아니다. 그것은 사용자를 더 안전하게 만드는 것이 아니라, 더 빠르게 “승인 버튼 누르는 사람”으로 훈련시키는 일에 가깝다.

그래서 Claude Code는 단순히 더 많은 경고를 추가하는 대신, 자동화된 보호 계층을 둔다. 위험한 명령, 민감정보 유출 가능성, 파괴적인 파일 조작 같은 행위를 별도로 판단하고 차단하려는 구조다.

Resume 기능에서도 흥미로운 철학이 보인다. Claude Code는 세션을 다시 시작할 때 이전 세션의 권한을 그대로 복원하지 않는다. 신뢰는 매 세션마다 다시 설정된다. 사용자는 조금 불편할 수 있다. 하지만 그 불편함 자체가 설계의 일부다.

에이전트가 강력해질수록 권한은 더 중요해진다. 한 번의 실수가 코드베이스를 망가뜨리거나 민감한 파일을 외부로 보낼 수 있기 때문이다. 따라서 Claude Code는 편리함만 추구하지 않는다. 사용자의 승인 피로를 줄이면서도, 신뢰 경계는 계속 새로 설정하는 방향을 택한다.

또 하나의 핵심은 컨텍스트 관리다. 에이전트는 일반 챗봇보다 훨씬 빠르게 컨텍스트가 커진다. 파일을 읽고, 터미널 출력을 받고, 테스트 로그를 보고, 오류 스택을 분석하고, 코드 diff를 만들고, 다시 수정한다. 여기에 서브에이전트까지 붙으면 토큰 사용량은 순식간에 늘어난다.

Claude Code는 이를 해결하기 위해 여러 단계의 컨텍스트 압축 파이프라인을 사용한다. 먼저 저렴한 방식으로 예산을 줄인다. 그래도 부족하면 일부 내용을 잘라낸다. 그다음 더 작은 단위로 압축하고, 필요하면 컨텍스트를 더 강하게 접는다. 마지막으로 자동 압축까지 수행한다.

중요한 점은 처음부터 비싼 요약을 돌리는 것이 아니라는 점이다. 가장 저렴한 방식부터 시도하고, 그것이 실패했을 때만 더 비싼 방식으로 넘어간다. 이것은 에이전트 설계에서 매우 현실적인 접근이다. 컨텍스트 관리는 단순한 부가 기능이 아니라 제품의 핵심 기능이다. 좋은 에이전트는 “많이 기억하는 에이전트”가 아니라, “무엇을 남기고 무엇을 버릴지 아는 에이전트”에 가깝다.

확장 구조도 흥미롭다. Claude Code에는 Hooks, Skills, Plugins, MCP 같은 여러 확장 방식이 있다. 이들은 단순히 기능 이름이 다른 것이 아니다. 각각 컨텍스트 비용과 통합 방식이 다르다.

Hooks는 거의 컨텍스트 비용 없이 실행 경계에서 개입한다. Skills는 필요한 지식이나 작업 방식을 낮은 비용으로 주입한다. Plugins는 더 넓은 기능 묶음을 제공한다. MCP는 외부 도구와 서비스를 연결하는 강력한 방식이지만 상대적으로 무겁다.

이 구분은 중요하다. 요즘 많은 에이전트 설계가 모든 외부 기능을 MCP로 붙이면 된다는 식으로 흘러간다. 하지만 모든 것을 무거운 통합 방식으로 처리하면 컨텍스트 비용과 지연시간이 커진다. Claude Code의 접근은 다르다. 가벼운 개입과 무거운 통합을 구분하고, 각각의 문제에 맞는 확장 방식을 사용한다.

병렬처리하는 서브에이전트 설계에서도 같은 철학이 드러난다. Claude Code의 서브에이전트는 부모 에이전트에게 전체 대화 기록을 모두 넘기지 않는다. 대신 요약 텍스트만 반환한다. 전체 transcript는 별도의 sidechain 파일에 남긴다.

이것은 컨텍스트 폭발을 막기 위한 설계다. 멀티에이전트는 멋져 보이지만 공짜가 아니다. 서브에이전트 여러 개를 동시에 쓰면 토큰 비용이 급격히 증가한다. 실제 분석에서도 에이전트 팀은 일반 세션보다 훨씬 많은 토큰을 사용한다.

따라서 좋은 멀티에이전트 설계는 “모든 에이전트가 모든 내용을 공유하는 구조”가 아니다. 각 에이전트가 독립적으로 작업하고, 부모에게는 필요한 요약만 반환하는 구조가 더 현실적이다.

제가 이 논문을 읽게 된 이유는, 어떻게 하면 claud code architecture에 잘 맞게 사용하는 데 있다. 현재 사용자마다 케이스마다 사실 베스트 프락티스가 없다. 누가 어떻게 했더라 하면 그 케이스가 나에게도 적용되나 해보지 않으면 알 수 없다. 즉 예측할 수 없으니 명령대로 실행해 주는 지 늘 파악해야 하고 토큰 비용이 얼마나 드는지 가름할 수 없다.

AI 에이전트의 성능은 모델만으로 결정되지 않는다. 물론 모델은 중요하다. Claude, GPT, Gemini, DeepSeek, Qwen 같은 프런티어 모델의 코딩 능력은 계속 발전하고 있다. 하지만 모델들의 순수 코딩 능력이 점점 비슷해질수록, 차별화는 모델 바깥에서 발생한다.

권한을 어떻게 설계하는가? 도구 호출을 어떻게 통제하는가? 컨텍스트를 어떻게 압축하고 유지하는가? 실패한 작업을 어떻게 복구하는가? 세션을 어떻게 저장하고 재개하는가? 확장 기능을 어떤 비용 구조로 붙이는가? 서브에이전트의 출력을 어떻게 요약하고 격리하는가? 이런 요소들이 실제 에이전트 제품의 품질을 결정한다.

결국 Claude Code의 교훈은 단순하다. 에이전트의 지능은 모델 안에만 있지 않다. 모델을 둘러싼 운영체제, 즉 하네스 안에도 있다.

앞으로 AI 에이전트 경쟁은 더 좋은 모델을 누가 쓰느냐의 싸움만이 아니다. 그 모델을 얼마나 안전하고, 효율적이고, 복구 가능하고, 확장 가능한 시스템 안에 넣느냐의 싸움이 될 가능성이 크다. Claude Code가 보여준 것은 바로 그 방향이다. 모델은 추론하고 하지만 제품은 하네스가 만든다.

• 논문: Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems