클로드는 어떻게 동작하는가(How Claude Code Works)

본 포스팅은 AI Engineer 채널의 How Claude Code Works - Jared Zoneraich, PromptLayer 영상을 바탕으로 의역하여 정리한 글입니다. 본 영상은 Anthropic과의 제휴관계가 없으며 Anthropic을 대변하지 않습니다. AI 엔지니어링 회사의 CEO 이자 Claude의 열렬한 사용자가 자신의 의견을 발표하는 것입니다.

Core Philosophy: Simple Architecture & Better Models (핵심 철학: 단순한 아키텍처 & 더 나은 모델)

"오늘날 모델의 결함을 과도하게 엔지니어링 하려 하지 마세요. 더 많은 것들이 그냥 나아질 것이고 그 작업들은 시간낭비가 될 것입니다."

Claude Code는 RAG를 포함한 모든 것들을 긁어내고 “그냥 더 나은 모델을 만들고 맡기자” 라는 철학을 갖고 있다고 생각합니다. 아직 Cursor는 RAG를 가져와서 답변에 합치고 있긴 하지만요. 도구 호출을 사용하고 도구 호출을 단순화하는 것. 이것이 Claude의 가장 중요한 점입니다.

Claude의 마스터 프롬프트는 이럴땐 어떻게 하고, 저럴땐 어떻게 하고 ... 같은 복잡한 워크플로우 대신, 정말 몇 개의 단순한 도구 호출만 있어요. RAG 대신 grep을 포함해서요. 네, 그리고 그게 훈련된 내용이에요. 매우 최적화된 도구 호출 모델들이에요.

*RAG(Retrieval-Augmented Generation): 검색증강생성으로, 답변을 생성하기 전, 검색을 통해 답변을 보강하는 프로세스

*grep: 문자열을 찾아내는 리눅스 명령어

*도구: 여기서 자주 등장하는 “도구“는 AI가 코드를 읽고 쓰고 터미널에 접근하는 것(read, grep, bash)과 같이 외부와 상호작용하는 인터페이스를 말합니다.

*스캐폴딩(scaffolding): 스캐폴딩은 건설현장의 임시발판이라는 사전적 의미가 있지만, 보통 어떤 것을 시작할 때 도움이나 안내를 제공하는 것을 뜻합니다. 이 영상에서는 AI에게 스캐폴딩을 줄이고, 모델에 의존하라 라고 말하는데, 불필요한 프롬프트로 이것저것 AI를 통제하려 하지말고, AI와 모델에 의존하라는 의미입니다.

이건 파이썬의 선(Zen of Python)인데, 파이썬에서 import this를 하면 나오는 거예요. 시스템을 만들 때 이 철학을 정말 좋아하고, Claude Code가 만들어진 방식에 정말 적절하다고 생각해요. 단순함이 복잡함보다 낫고, 복잡함이 난해함보다 낫고, 평평함이 중첩보다 낫다. 이것이 이번 발표를 관통하는 것입니다. Claude Code가 어떻게 작동하고 왜 작동하는지 알아야 할 전부예요. 단순한 설계가 좋은 설계라는 엔지니어링 원칙으로 돌아가는 거죠.

The Constitution: Claude.md (헌법: Claude.md)

라이브러리에 대한 지시사항을 넣는 곳이에요. 흥미로운 건, 기본적으로 팀이 "모델이 먼저 레포를 조사하는 시스템을 과도하게 엔지니어링할 필요 없다"고 말하는 거예요. Cursor 1.0이 아시다시피 로컬에서 벡터 DB를 만들어서 레포를 이해하잖아요. Claude는 그냥 "아, 마크다운 파일 하나 넣어. 사용자가 필요할 때 바꾸게 해. 에이전트가 필요할 때 바꾸게 해"라고 하는 거예요. 매우 단순하죠.

The Core Master Loop (핵심 마스터 루프)

우리가 예전에 에이전트를 만들던 방식을 생각하면 이건 사실 혁명적이에요. 오늘날 모든 코딩 에이전트, Codex, Cursor, Amp 등 전부 도구 호출을 가진 하나의 while 루프예요. 마스터 while 루프를 실행하고, 도구를 호출하고, 다시 마스터 while 루프로 돌아가는 거죠.

기본적으로 4줄의 코드예요. 도구 호출이 있는 동안 도구를 실행하고, 도구 결과를 모델에 주고, 도구 호출이 없을 때까지 다시 하고, 그러면 사용자에게 뭘 할지 물어보는 거예요.

처음 도구 호출을 사용했을 때, 모델이 언제 도구를 계속 호출해야 하는지, 언제 실수를 고쳐야 하는지를 너무 잘 아는 게 정말 충격이었어요. LLM의 가장 흥미로운 점 중 하나가 실수를 고치고 유연하게 대처하는 것을 정말 잘해요. 모델이 탐색하고 알아내도록 더 맡길수록, 더 나은 모델이 나왔을 때 시스템이 더 좋고 더 견고해질 거예요.

Key Tools in Claude Code (Claude Code의 핵심 도구들)

오늘날 Claude Code에 있는 핵심 도구들이에요. 며칠마다 새 릴리스를 하면서 자주 바뀌고 있지만, 이 영상에서는 Read, Grep/Glob, Edit, Bash, WebSearch/WebFetch, TodoRead/TodoWrite, Task를 다룹니다.

RAG 대신 Grep을 사용하는 방식은 사용자가 터미널에서 문제를 해결할 때 시도하는 방식을 모방합니다.

Edit에서의 흥미로운 점은 diff를 사용하면서 필요한 부분만 수정해서 컨텍스트를 훨씬 적게 사용하고 수정으로 인한 문제도 줄여줍니다.

web search, web fetch에 대한 흥미로운 점은 더 저렴하고 더 빠른 방식으로 문제를 해결할 수 있게 해주는 것이에요.

The Power of Bash (Bash의 힘)

Bash가 여기서의 핵심인데요. 모든 도구를 Bash로 대신해도 될 것 같습니다. Claude Code가 가끔 파이썬 파일을 만들고 실행한 뒤 삭제하곤 하는데요. 이것이 바로 Bash가 우아하게 동작하는 방식이죠.

코딩 에이전트에서 Bash의 놀라운 점이 두 가지 있어요. 첫째, 단순하고 모든 걸 해요. 매우 견고하죠. 둘째, 훈련 데이터가 엄청 많아요. 우리가 그걸 쓰니까요. 모델이 Rust나 덜 흔한 프로그래밍 언어를 잘 못하는 이유가 그거예요. 사용하는 사람이 적으니까요.

평소에 어딘가 파일에 명령어를 적어놓고 오래돼 버리는 로컬 환경 구축을, 저는 Claude Code로 해요. 이런 걸 알아내는 데 정말 뛰어나요. 특히 모델이 시도해볼 수 있게 해줘요.

To-dos

To-dos는 모델을 궤도에 유지하고 Tasks는 컨텍스트를 어지럽히지 않으면서 긴 프로세스를 실행하는 방법이에요. 조심해야 하는 건, 컨텍스트가 가득차면 모델이 멍청해진다는 것이에요

to-dos는 네 가지 이점을 가지는데요. 계획을 세우도록 하고, 충돌해도 재개할 수 있습니다. 사용자가 진행 상황을 알 수 있고, 핸들을 계속 쥐고 있을 수 있죠.

to-do 리스트의 정말 흥미로운 점은 구조화되어 있지만 구조적으로 강제되지는 않는다는 거예요. 가지고 있는 규칙은 한 번에 하나의 작업, 완료 표시하기, 차단이나 에러가 있으면 진행 중인 것을 계속 작업하기, 작업을 다른 지시사항으로 분할하기 정도가 있지만, 가장 흥미로운 건 결정론적으로 강제되지 않습니다. 순수하게 프롬프트 기반이에요. 모델이 이제 지시 따르기를 잘하기 때문이에요. tool 구현도 매우 간단했던 것 같아요

Async Buffer & Context Compression (비동기 버퍼 & 컨텍스트 압축)

보이지 않는 내부 동작 방식의 두 가지 부분입니다. H2A라고도 불리는 Async buffer는 IO 프로세스입니다. 추론에서 분리할 수 있고, 터미널에서 보는 모든 것을 모델에 다 집어넣지 않으면서 컨텍스트를 관리하는 방법이에요. 컨텍스트가 가득 찰 수록 모델은 멍청해집니다. 꽉차게 되면 중간을 버리고 앞부분과 뒷부분을 Context Compression으로 요약합니다.

*여기서 말하는 **샌드박스(sandbox)**는 AI가 별도로 파일을 만들고 저장하고 실행할 수 있는 로컬 실행 환경을 의미합니다.

예측하자면, 모든 ChatGPT 창과 모든 Claude 창이 샌드박스를 가질겁니다. 장기 기억을 저장할 수 있으니까 훨씬 나아요. 저는 항상 "마크다운 파일로 저장해"라고 지시합니다. 컨텍스트가 짧을수록 더 빠르고 더 똑똑하거든요.

We Don't Need DAGs (DAG가 필요 없다)

"이 사용자가 환불을 원하면 이 프롬프트로 라우팅 해" Prompt Layer의 사용자, 고객 지원 에이전트 등 지난 2년 반 동안 모두가 이런 DAG를 만들었습니다. 환각이나 부적절한 환불이 없도록 보장하고, 프롬프트 인젝션 문제를 해결한다는 거예요.

하지만 앞으로 이런 DAG는 필요 없습니다. 모델이 10배 쉽고, 10배 더 유지보수 가능하게 좋아졌기 때문입니다.

*DAG(Directed Acyclic Graph): 방향성 비순환 그래프로써 작업 간의 의존 관계를 정의하여 데이터 흐름을 최적화하기 좋기 때문에 데이터 파이프라인, 컴퓨터 과학, 블록체인에서 주로 사용되는 그래프 구조입니다. 이 영상에서는 AI의 응답을 정제하기 위한 분류, 검증 프롬프트와 같은 것들을 의미합니다.

모델을 믿으세요. 의심스러울 때, 모든 엣지 케이스와 if 문을 고려하려 하지 마세요. 모델이 탐색하고 알아내도록 맡기세요. 대시보드에서 브라우저 에이전트 실험을 했는데, 버튼에 제목을 추가하면 에이전트가 자동으로 탐색하는 데 도움이 될지 봤어요. 놀랍게도 더 나빠졌어요. "이 버튼을 클릭해야 하고, 그다음 이 버튼"이라고 했더니 산만해져서 뭘 해야 할지 몰랐어요. 탐색에 의존하는 게 나아요.

Claude Code는 트리거 구문으로도 똑똑한 걸 해요. "think," "think hard," "think harder," 그리고 제일 좋아하는 "ultra think". 추론 토큰 예산을 또 다른 매개변수로 사용할 수 있어요. 어려운 계획 수립을 위한 도구 호출을 만들 수도 있고 아니면 사용자가 지정해서 즉석에서 바꿀 수도 있고요.

Sandboxing & Permissions (샌드박싱 & 권한)

샌드박싱과 권한. 솔직히 저한테는 가장 지루한 부분이에요 — 절반은 YOLO 모드로 실행하니까요. 저희 팀에서 로컬 데이터베이스를 다 날려먹은 사람도 있어요. 조심해야 해요. 인터넷으로부터의 프롬프트 인젝션이라는 큰 문제가 있어요. 셸 접근 에이전트에서 웹 패치를 하면 큰 공격 벡터예요. 컨테이너화, URL 차단이 있어요. "이 URL에서 가져와도 돼?"가 꽤 짜증나죠. 복잡한 코드 대부분이 이 샌드박싱과 권한 설정에 있고, 접두사에 따라 bash 명령어를 게이트하는 파이프라인이 있어요.

Sub-Agents (서브 에이전트)

서브 에이전트는 컨텍스트 관리로 돌아가는 건데 컨텍스트가 길수록 에이전트가 더 멍청해져요. 특정 작업에 서브 에이전트를 사용하는 핵심은 자체 컨텍스트를 갖고 결과만 돌려주는 거예요. 연구원, 문서 리더, 테스트 러너, 코드 리뷰어가 있어요. 핵심은 에이전트의 포크와 메인 컨텍스트로 어떻게 다시 합치느냐예요.

예를 들면, "task"라는 서브 에이전트가 있을 때 task에 description과 prompt 두 가지를 주었다고 가정합시다. description은 사용자가 볼 것, prompt는 긴 문자열로 코딩 에이전트가 자신의 에이전트를 프롬프팅하는 거예요.

에이전트가 이 문자열에 원하는 만큼 정보를 넣을 수 있어요. task가 에러를 반환하면 더 많은 정보를 넣고 문제를 풀게 해요. 경직되기보다 유연한 게 나아요.

서브 에이전트는 시스템 프롬프트가 아니라 전체 컨텍스트에서 실행됩니다. 서브 에이전트의 도구 호출구조가 메인 에이전트에 있고 즉석에서 생성됩니다. 즉 서브 에이전트는 도구 호출이고 병렬로 실행될 수 있습니다.

System Prompts (시스템 프롬프트)

Claude Code 시스템 프롬프트의 유출이 조금 있었는데, 이 영상에서는 이것을 기반으로 합니다.

• 간결하게 출력하기
• 텍스트 설명 대신 도구를 더 사용하도록 하기
• 기존 코드에 맞추기
• 주석 추가하지 않기
• to-do 같은 명령어를 광범위하게 병렬 실행 하기 이런 것들이 있습니다.

대부분이 누군가 Claude Code를 사용하면서 "이걸 좀 덜/더 했으면"이라고 한 데서 나온 것 같아요. 프롬프팅은 반복하기가 너무 쉬우니까요.

Skills: Extendable System Prompt (스킬: 확장 가능한 시스템 프롬프트)

Skills는 훌륭해요. 좀 더 새로운 기능이에요. 최근에야 납득했어요. 이 슬라이드를 Skills로 만들었어요. 확장 가능한 시스템 프롬프트라고 생각하세요. 컨텍스트를 어지럽히고 싶지 않지만, 더 많은 컨텍스트가 필요한 다양한 작업이 있어요. 예를 들면, 문서 스킬, Microsoft Word/Excel 편집, 디자인 스타일 가이드, 딥 리서치 같은 것이 있습니다. 딥 리서치 GitHub 레포를 넣고 "Claude Code 스킬로 다시 만들어"라고 했더니 정말 잘 동작하기도 했습니다.

스킬에 대한 한가지 사용 사례가 있었어요. 4만 자 이상으로 길어진 Claude.md를 스킬로 분리했는데, Claude가 분리한 스킬들을 모두 무시했다는 겁니다. 스킬은 각각의 설명을 가질 수 있습니다. 그래서 이론적으로 완벽한 세상에서는 항상 상황에 맞춰 스킬을 선택할 거예요. 하지만 현재는, 저도 보통 스킬을 수동으로 직접 호출하고 있습니다.

하지만 이게 좋은 연결 고리라고 생각해요. 프롬프팅이 올바른 해결책인 때가 언제이고, DAG가 올바른 해결책인 때가 언제인지, 아니면 그냥 모델 훈련 문제일 수도 있어요. 앞으로 훈련에서 모델이 도구 호출처럼 스킬을 좀 더 호출하도록 해야 할 수도 있어요. 아직 그렇게 좋지 않은 기능일 수 있지만, 패러다임은 매우 흥미롭다고 생각해요. 하지만 배우고 있듯이 완벽하지는 않아요.