AI 코딩 도구를 “어떻게 쓰는지”는 많이 알려져 있지만, “왜 이렇게 작동하는지”를 아는 사람은 드뭅니다. Claude Code를 단순히 자동완성 도구로만 쓰고 있다면, 당신은 Ferrari를 자전거처럼 타고 있는 셈이죠.

개발자 Sankalp가 Claude Code 2.0과 Opus 4.5를 6개월간 실전 투입하며 발견한 내부 작동 원리와 최적화 전략을 상세히 분석한 가이드를 공개했습니다. 이 글은 단순 사용법을 넘어 Sub-agents의 메커니즘, Context Engineering의 핵심 개념, 그리고 실제 개발 워크플로우까지 다룹니다.

개발자 Sankalp가 Claude Code 2.0의 실전 사용 경험과 내부 메커니즘을 분석한 심층 가이드를 발표했습니다. Opus 4.5와 GPT-5.2 Codex를 비교 분석하며, Sub-agents의 작동 원리, Context Engineering 최적화 전략, 그리고 실무 워크플로우를 다룹니다.

출처: A Guide to Claude Code 2.0 and getting better at using coding agents – sankalp’s blog

이 글은 Claude Code의 새로운 기능들부터 시스템 프롬프트 분석까지 방대한 내용을 다루고 있습니다. 여기서는 가장 핵심적인 세 가지 메커니즘을 중심으로 정리해봤습니다: Sub-agents의 작동 원리, Context Engineering 전략, 그리고 실전에서 두 모델을 비교하며 얻은 인사이트입니다.

Sub-agents: 작업을 나눠 맡는 전문가들

당신이 Claude에게 “이 프로젝트에서 API 호출하는 부분을 찾아서 에러 처리 추가해줘”라고 요청했다고 생각해보세요. Claude는 혼자 모든 파일을 뒤지는 대신, Explore라는 전문 검색 에이전트를 따로 소환합니다. 마치 큰 회사에서 CTO가 특정 조사를 신입 직원에게 맡기는 것과 비슷하죠.

흥미로운 건 이 Explore 에이전트가 당신과 Claude의 이전 대화 내용을 전혀 모른다는 점입니다. “API 관련 파일 찾기”라는 임무만 받고 깨끗한 상태에서 출발하죠. 검색이 끝나면 “user_api.py, auth.py, config.py에서 발견했습니다”라는 요약 보고서만 메인 Claude에게 전달합니다.

그런데 저자는 여기서 중요한 팁을 공유합니다. 이 요약 보고서만 믿지 말고, 반드시 메인 Claude가 그 파일들을 직접 읽게 하라는 것입니다. 왜냐하면 Explore가 전달한 요약은 핵심만 추린 것이라 디테일이 빠질 수 있거든요. 메인 Claude가 파일 전체를 읽으면 코드 간의 연결고리를 훨씬 잘 파악합니다.

실전 예시를 하나 들면, 저자는 복잡한 기능 분석이 필요할 때 일부러 “지금 찾은 파일들 내용을 네가 직접 읽고 설명해줘”라고 추가 지시를 내린다고 합니다. 이렇게 하면 Claude가 코드 구조를 제대로 이해하고 더 정확한 수정을 할 수 있습니다.

Sub-agents는 총 5가지 종류가 있습니다: 범용 작업용, 코드베이스 탐색용(Explore), 설계 계획용(Plan), 문서 검색용, 그리고 설정 관리용. 상황에 따라 Claude가 자동으로 적절한 에이전트를 선택하지만, “Sonnet으로 빠르게 검색해줘”처럼 직접 지시할 수도 있습니다.

Context Engineering: 토큰 전쟁의 기술

AI 에이전트는 토큰 괴물입니다. 툴을 호출할 때마다 입력과 출력이 모두 컨텍스트 윈도우에 쌓이거든요. 간단한 랜딩 페이지 하나 만들어달라고 했는데, 웹 검색 결과 1.5K 토큰, 브랜드 가이드라인 읽기 4K 토큰, 이미지 생성 30 토큰… 금방 6K 토큰이 넘어갑니다.

LLM은 상태가 없기(stateless) 때문에 매번 전체 대화를 다시 처리해야 합니다. 메시지가 n개면 다음 메시지 보낼 때 n+1개를 모두 읽죠. 컨텍스트가 길어질수록 모델의 주의력(attention budget)은 분산되고 성능이 떨어집니다. 이게 바로 “Context Rot” 현상입니다.

Claude Code는 이를 해결하기 위해 정교한 전략들을 씁니다:

Skills와 온디맨드 로딩: 보통은 도메인 지식을 시스템 프롬프트에 다 넣어야 하는데, Skills는 필요할 때만 로드됩니다. 영화 매트릭스에서 네오가 “나 쿵푸 안다”라며 순식간에 기술을 다운로드받는 것처럼요. 모델이 프론트엔드 디자인 작업을 감지하면 그제야 frontend-design 스킬을 읽어들입니다.

System Reminders: 작업이 길어지면 목표를 잊어버리기 쉽습니다. Claude Code는 대화 중간중간에 <system-reminder> 태그로 목표를 반복 주입합니다. Manus라는 에이전트는 아예 todo.md 파일을 계속 업데이트하면서 “현재 목표”를 컨텍스트 끝부분에 계속 재연송하죠. 이렇게 하면 “lost-in-the-middle” 문제를 피할 수 있습니다.

MCP Code Execution: MCP 서버가 많아지면 툴 정의만으로도 컨텍스트가 폭발합니다. 그래서 Anthropic은 툴 정의 대신 코드 API를 노출하고, 샌드박스 환경을 줘서 Claude가 직접 코드를 짜서 툴을 호출하게 하는 방식을 제안했습니다.

Opus 4.5를 선택한 이유

저자는 GPT-5.1 Codex를 쓰다가 Opus 4.5로 갈아탔습니다. 코드 생성 능력은 비슷했지만, Opus 4.5가 압도적으로 빨랐고 커뮤니케이션이 훨씬 자연스러웠습니다.

속도는 단순히 시간 절약이 아닙니다. 빠른 피드백 루프는 시행착오를 가속화하고, 진행 과정이 더 생생하게 느껴지죠. 개발자로서 몰입감이 달라집니다. GPT-5.2 Codex가 코드 리뷰와 버그 찾기에는 여전히 우수하지만, 일상적인 개발에는 Opus 4.5가 더 나은 파트너라는 게 저자의 결론입니다.

흥미로운 건 UI 디테일입니다. Claude Code는 고대비 텍스트와 굵은 폰트를 쓰는 반면, Codex는 얇고 읽기 어려운 폰트를 씁니다. 작은 차이 같지만 하루 종일 보는 인터페이스에선 이런 게 피로도를 좌우하죠.

실전 워크플로우: 탐색→실행→리뷰

저자의 워크플로우는 간단하면서도 효과적입니다. Plan Mode는 거의 안 쓰고, 대신 코드베이스를 직접 탐색하며 맥락을 파악합니다. Opus 4.5는 설명을 기가 막히게 잘하고 ASCII 다이어그램도 멋지게 그리거든요.

복잡한 기능은 “일회용 초안” 접근법을 씁니다. 새 브랜치를 만들고 Claude가 기능을 처음부터 끝까지 짜게 놔둡니다. 그 결과를 보며 Claude가 어디서 실수했고, 어떤 가정을 했는지 배우죠. 영화 테넷처럼 미래를 먼저 보고 과거로 돌아가 더 나은 선택을 하는 겁니다.

코드 리뷰는 GPT-5.2 Codex에게 맡깁니다. /review 명령 하나면 P1, P2 우선순위로 버그를 찾아주고, 거짓 양성도 적습니다. “Claude로 개발하고 GPT로 리뷰한다”는 패턴이 1년 넘게 유지되고 있다고 하네요.

개발자에게 요구되는 새로운 역량

AI 코딩 도구의 시대에 중요한 건 구현 속도가 아니라 판단력(taste)입니다. 구현은 빨라졌지만, 무엇을 만들지, 어떻게 설계할지 결정하는 건 여전히 사람의 몫이죠.

저자는 세 가지 요소를 강조합니다: (1) 툴링 업데이트 따라잡기, (2) 도메인 깊이와 인접 분야 확장, (3) 열린 마음으로 실험하기. 특히 구현이 빨라진 만큼 taste 개선에 더 많은 시간을 써야 한다고 말합니다. 좋은 네이밍, 리팩토링, 문서화, 타입 어노테이션 같은 소프트웨어 엔지니어링 실천법이 LLM에게 더 나은 피드백 루프를 만들어줍니다.

Claude Code는 단순한 자동완성 도구가 아닙니다. Context Engineering, Sub-agents, Skills 같은 정교한 시스템으로 구성된 협업 파트너죠. 이 메커니즘을 이해하면 Claude Code뿐 아니라 Cursor, Codex 같은 다른 AI 코딩 도구도 훨씬 효과적으로 쓸 수 있습니다. 결국 AI 시대의 개발자는 코드를 직접 치는 사람이 아니라, AI를 설계하고 조율하는 시스템 엔지니어가 되어가고 있습니다.

참고자료:

• Building Effective Agents – Anthropic
• Effective Context Engineering for AI Agents – Anthropic
• Context Rot – Chroma Research