Claude Code는 왜 갑자기 “쓸 만해졌는가”("How Claude Code Works - Jared Zoneraich, PromptLayer")
📝 Document 요약 및 번역
코딩 에이전트의 진짜 돌파구는 모델이 아니라 구조였다
2023~2024년에 등장했던 대부분의 코딩 에이전트는 솔직히 말해 실사용하기 어려웠다.
자율성은 과했고, 정확도는 낮았으며, 디버깅 비용이 사람보다 컸다.
그런데 2025년 말부터 분위기가 바뀌었다.
Claude Code, Codex, Cursor Agent 같은 도구들이 실제 개발 워크플로우에 들어오기 시작했다.
이 강연은 그 이유를 “감각적 경험”이 아니라 아키텍처 관점에서 설명한다.
1. 핵심 질문: 무엇이 달라졌는가?
강연자가 던지는 질문은 단순하다.
“모델이 좋아진 것 말고,
코딩 에이전트를 실제로 가능하게 만든 변화는 무엇인가?”
답은 의외로 화려하지 않다.
- 복잡한 에이전트 그래프(DAG)를 버렸다
- 분기 로직을 없앴다
- 추상화를 줄였다
- 단 하나의 while loop로 돌아왔다
2. Claude Code의 본질: 하나의 마스터 루프
Claude Code를 포함한 최신 코딩 에이전트들의 공통 구조는 거의 같다.
while (tool_call_exists):
run_tool()
feed_result_back()
end이게 전부다.
- 플래너 → 실행기 → 검증기 → 분기
- 이런 구조는 없다
- 모델이 스스로 탐색하고 수정하게 둔다
이 구조가 가능한 이유는 단 하나다.
모델이 이제 “실수 → 수정”을 반복할 만큼 충분히 똑똑해졌기 때문
3. “모델을 믿어라”는 말의 정확한 의미
강연에서 반복되는 메시지는 이것이다.
모델의 한계를 코드로 보완하려 하지 마라
모델에게 도구를 주고, 방해하지 마라
이건 무책임한 낙관이 아니다.
오히려 엔지니어링 관점에서의 보수적인 선택이다.
- 지금의 모델 한계에 맞춰
- 수백 개의 분기와 예외를 만들면
- 3~6개월 후 전부 기술 부채가 된다
Anthropic 내부에서도 이 철학을 이렇게 부른다.
“모델 결함을 중심으로 아키텍처를 짜지 말 것”
4. 도구 설계의 기준: “사람이 하던 일인가?”
Claude Code의 도구들은 매우 제한적이다.
- read
- grep / glob
- edit (diff 기반)
- bash
- web fetch
- to-do
- task (서브 에이전트)
공통점은 하나다.
전부 사람이 터미널에서 하던 행동
새로운 개념의 도구는 거의 없다.
RAG도, 벡터 DB도 없다.
대신 grep이 있다.
이게 중요한 이유는 명확하다.
- 학습 데이터가 압도적으로 많고
- 실패 패턴도 모델이 이미 알고 있기 때문
5. Bash가 “최강의 도구”인 이유
강연자가 여러 번 강조한 포인트:
사실 bash 하나만 있어도 에이전트는 성립한다
이유는 두 가지다.
-
범용성
- 파일 생성, 실행, 테스트, 삭제 전부 가능
-
학습 데이터
- 인류가 수십 년간 써온 인터페이스
Claude Code가
임시 Python 파일을 만들고 → 실행하고 → 지우는 이유도 여기에 있다.
6. To-do 리스트는 “기능”이 아니라 “프롬프트”
흥미로운 부분 중 하나는 to-do 시스템이다.
- 구조화되어 보이지만
- 실제로는 강제 로직이 없다
- 전부 시스템 프롬프트 기반
그런데도 잘 동작한다.
왜냐하면:
- 최신 모델은
- “한 번에 하나씩 하라”
- “완료 표시를 하라”
같은 규칙을 지속적으로 지킬 수 있기 때문
이건 1~2년 전에는 불가능했던 일이다.
7. DAG를 버려야 하는 이유
과거 에이전트 설계는 대부분 이런 모습이었다.
- 분류 → 분기 → 서브 플로우 → 또 분기
- 수백 개 노드
- 디버깅 불가능
강연자의 결론은 단호하다.
일반 목적 에이전트에는 DAG가 최악의 선택이다
- 문제 공간이 열려 있고
- 정답 경로가 하나가 아니기 때문
반면:
- 출력 포맷이 고정된 작업
- 규제가 강한 도메인
에서는 도구 내부에만 제한적으로 DAG를 쓰는 것은 유효하다.
8. 서브 에이전트의 역할: 컨텍스트 절약
Claude Code의 task는 핵심적인 설계다.
- 독립된 컨텍스트
- 결과만 메인 에이전트로 반환
- 중간 사고 과정은 버린다
이게 중요한 이유는 하나다.
컨텍스트가 길어질수록 모델은 멍청해진다
그래서:
- 리서치
- 문서 읽기
- 테스트 실행
같은 작업은 반드시 분리한다.
9. Skills의 정체: “확장 가능한 시스템 프롬프트”
Skills는 마법이 아니다.
- 자동으로 항상 호출되지도 않는다
- 대부분 수동 호출이 필요하다
하지만 의미는 명확하다.
컨텍스트를 항상 들고 있지 말고
필요할 때만 로드하라
- 글쓰기 스타일
- 디자인 가이드
- 제품 도메인 지식
이런 것들은
- 코드가 아니라
- 프롬프트 자산으로 관리하는 게 맞다
10. 에이전트 평가(Eval)는 왜 어려운가
강연에서 인상적인 개념 하나:
“Agent smell”
- 도구 호출 횟수
- 재시도 빈도
- 작업 시간
- 불필요한 루프
정확한 정답을 채점하는 건 어렵다.
대신 행동 패턴을 측정한다.
또 하나의 현실적인 방법:
- 과거 데이터 백테스트
- 동일 작업을 다시 돌려보기
11. 앞으로의 방향: API가 아니라 “에이전트 엔드포인트”
강연자의 예측은 이렇다.
- 직접 LLM API를 호출하는 코드 ↓
- Headless Claude Code 같은 에이전트 SDK ↑
이유는 간단하다.
- reasoning model 자체가 이미 while loop
- 그렇다면 한 단계 더 추상화해도 된다
다만:
- 모든 작업이 거기로 가지는 않는다
- 정밀 제어가 필요한 부분은 여전히 로우 레벨 API가 필요
12. 최종 정리
이 강연의 메시지는 매우 명확하다.
핵심 요약
- 코딩 에이전트의 돌파구는 아키텍처 단순화
- 모델을 믿을 수 있을 만큼 모델이 좋아졌다
- DAG보다 단일 루프
- 많은 도구보다 적은 도구
- 핵심 도구는 여전히 bash
- 컨텍스트 관리는 성능 그 자체
- 에이전트마다 철학은 다르며, 정답은 하나가 아니다
한 문장 결론
코딩 에이전트의 진짜 혁신은
“AI가 똑똑해졌다”가 아니라
“엔지니어가 덜 개입하기 시작했다”는 점이다.
