Claude Code를 처음 켜면 대부분 같은 실수를 한다. "이거 만들어줘"라고 던지고, 결과물이 마음에 안 들면 다시 던진다. 그렇게 몇 번 반복하다 컨텍스트 창이 쓰레기로 가득 차고, 세션이 죽는다. 문제는 Claude Code의 능력이 아니다. 워크플로우 설계의 부재다.
최근 dev.to에 올라온 세 편의 실전 사례는 각각 다른 도메인—Rust CLI 개발, 컨텍스트 압축 도구 운용, AI와의 기술 글쓰기—을 다루지만, 놀랍도록 비슷한 설계 원리를 공유한다. 이 글은 그 세 패턴을 추출해 하나의 워크플로우 철학으로 재구성한다.
패턴 1: 서브에이전트 분할 — '큰 요청'을 '작은 계약'으로 쪼개라
Rust를 한 줄도 못 쓰는 개발자가 1,056개 테스트를 가진 40모듈 Rust CLI를 3주 만에 출시했다. dev.to의 사례(「Building a 1,056-Test Rust CLI Without Writing Rust」)에서 핵심 전략은 단 하나였다. 모든 작업을 '서브에이전트 디스패치'로 분해하는 것.
"컨텍스트 압축기를 만들어줘" 같은 모호한 명령은 없었다. 대신 이런 식의 계약서를 썼다: "Node.js 에러 스택트레이스 필터를 구현해. 입력: Express 미들웨어 프레임이 포함된 raw stderr. 출력: 에러 메시지 + 사용자 코드 프레임만. 중첩 에러, 빈 트레이스, 혼합 출력 케이스를 포함해 20개 이상의 테스트를 작성할 것. 파일 위치는 src/filters/error_stacktrace.rs."
구현이 끝나면 두 번째 서브에이전트가 리뷰를 맡는다. "엣지케이스를 점검해. 프레임이 0개일 때는? 파일 경로가 없는 프레임은? JSON 출력 안에 스택트레이스가 있을 때는?" 이 '구현→리뷰' 2-에이전트 사이클이 버그의 80%를 인간이 코드를 보기 전에 잡아냈다.
이 패턴의 본질은 프롬프트를 '요청'이 아니라 '명세서'로 쓰는 것이다. 입력, 출력, 예외, 테스트 조건이 명확할수록 Claude Code는 '그럴듯한 코드'가 아니라 '검증 가능한 코드'를 만든다. 개발자가 하는 일은 Rust 타이핑이 아니라 아키텍처 결정과 품질 게이트 설계—전체 작업의 20%지만 출시를 결정하는 20%.
패턴 2: 컨텍스트 압축 — 노이즈를 걷어내야 AI가 기억한다
npm install 하나가 150줄의 deprecation 경고를 컨텍스트에 쏟아붓는다. Claude Code는 그 모든 줄을 읽는다. 그리고 아무것도 배우지 못한 채 5분 전에 보여준 코드를 잊는다. 이것이 컨텍스트 낭비의 진짜 비용이다—돈이 아니라 기억.
같은 저자의 후속 글(「I Compressed Claude Code's Context by 90%」)에서 소개된 ContextZip은 이 문제를 정면으로 공략한다. 셸과 Claude Code 사이에 앉아 모든 커맨드 출력을 압축한 뒤 컨텍스트 창에 전달하는 방식이다. 실측 결과는 인상적이다: Node.js 스택트레이스 93% 절감, npm install 95% 절감, Docker 빌드 96% 절감.
중요한 건 이 압축이 '신호'를 건드리지 않는다는 점이다. 에러 메시지, 보안 경고, 테스트 실패 상세—이것들은 원본 그대로 살아남는다. 제거되는 건 프레임워크 내부 로그, ANSI 이스케이프 코드, 동일한 패턴의 반복 경고들이다. AI가 어차피 무시할 정보만 잘라낸다는 설계 철학이 핵심이다.
흥미로운 반전은 이 도구 자체가 Claude Code로 만들어졌다는 것이다. AI가 자신의 컨텍스트 창을 더 효율적으로 만들기 위한 도구를 스스로 빌드한 셈이다. 벤치마크 결과가 균일하지 않다는 점(Java 스택트레이스 초기 -12%)을 README에 그대로 공개한 것도 눈에 띈다. 숫자를 미화하지 않는 것, 그것도 워크플로우 설계의 일부다.
패턴 3: 대화적 글쓰기 — AI의 초안을 '거울'로 쓰는 법
세 번째 패턴은 코드가 아닌 기술 글쓰기에서 나왔다(「What Actually Happens When You Write an Article with AI」). 20번의 대화, 2시간, 제목 3번 교체, 핵심 논지 완전 변경. 이것이 AI와 함께 기술 아티클 한 편을 쓰는 실제 과정이다.
이 워크플로우의 시작점은 /collect-context라는 커스텀 커맨드다. "뭔가 써줘"가 아니라, 현재 세션 내용·과거 관련 작업·프로젝트 지식을 하나의 구조화된 파일로 먼저 집결시킨다. 이 원재료를 기반으로 Claude Code가 초안을 생성하고, 별도의 에디터 에이전트가 문체 일관성과 논리 정합성을 점검한다. 인간의 리뷰는 그 사이에 낀다.
가장 결정적인 순간은 저자가 무심코 던진 한 마디에서 왔다. "프로덕션에서는 Claude Code가 아예 등장하지 않아. launchd가 자동으로 실행해." 이 발언이 Claude Code가 2시간 동안 공들여 쌓아올린 '외부 위임' 프레임을 통째로 무너뜨렸다. AI는 그럴듯한 서사를 완성할 수 있지만, 실제 구현이 어떻게 돌아가는지는 인간만 안다.
이 패턴이 가르쳐주는 건 AI의 초안을 결과물이 아니라 사고를 촉발하는 거울로 쓰라는 것이다. Claude Code가 틀렸을 때—cron을 launchd라고 쓰거나, "설계가 옳았다"고 단언하거나—그 오류가 오히려 내 실제 경험을 명료하게 만드는 저항점이 됐다. AI가 잘못 쓴 문장이 내가 무엇을 알고 있는지를 드러냈다.
세 패턴을 관통하는 하나의 원리
서브에이전트 분할, 컨텍스트 압축, 대화적 글쓰기—세 패턴은 표면상 전혀 다른 문제를 다루지만 같은 설계 원리로 수렴한다. 노이즈를 구조적으로 제거하고, 인간의 판단을 워크플로우의 정점에 배치하라.
Claude Code는 Rust를 타이핑하고, 컨텍스트를 압축하고, 초안을 생성하는 데 탁월하다. 하지만 아키텍처가 맞는지, 어떤 정보가 신호이고 어떤 게 노이즈인지, 초안이 실제 경험을 반영하는지—이 판단들은 여전히 인간의 몫이다. AI를 잘 쓴다는 건 AI에게 많이 시키는 게 아니라, 인간이 판단해야 할 지점을 정확히 설계하는 것이다.
빠른 프로토타이핑에서 검증으로, 검증에서 고도화로 이어지는 루프에서 AI는 이미 강력한 실행 엔진이다. 이제 남은 숙제는 그 엔진을 어떤 트랙 위에 올릴지 설계하는 일—그리고 그것은 아직, 그리고 한동안은, 사람이 해야 하는 일이다.