하이브리드 방식(La méthode hybride)은 사용자가 대화형 채팅 인터페이스인 Claude.ai에 머무는 동안, 길고 복잡한 엔지니어링 작업은 백그라운드에서 자율형 명령줄 에이전트(CLI agent)인 Claude Code에 위임하는 작업 조직 방식입니다. 이 위임 과정은 보이지 않게 이루어집니다. 채팅 자체가 상황에 적합한 전문적인 엔지니어링 프롬프트(prompt)를 작성하고, 실행기를 실행하며, 로컬 파일 시스템(filesystem)과 git 히스토리를 통해 작업을 감독한 뒤, 동일한 대화창 내에서 사용자에게 결과를 보고합니다. 사용자는 터미널을 열거나, Claude Code를 위한 프롬프트를 입력하거나, 채팅창을 떠날 필요가 전혀 없습니다.

이 명칭은 자동차의 비유를 따릅니다. 하이브리드 자동차는 지속적인 부하를 담당하는 내연 기관과 즉각적인 반응을 담당하는 전기 모터라는 상호 보완적인 힘을 가진 두 개의 엔진을, 매 순간 어떤 엔진을 사용할지 선택하는 변속기를 통해 조율합니다. 구조적으로 Claude.ai와 Claude Code는 이 두 엔진에 해당합니다. 운전자는 페달을 밟을 뿐이며, 시스템이 하부에서 할당을 관리합니다.

저는 2026년 4월 21일부터 프로덕션 프로젝트에서 매일 이 방식을 사용하고 있습니다. 한 달간의 신중한 사용 결과, 이는 제가 접한 가장 유용한 AI 보조 엔지니어링 조직 방식입니다. 단일 에이전트(mono-agent) 사용 대비 처리량(throughput)이 약 한 자릿수(order of magnitude) 증가했고, 출력(output) 품질이 더 높으며, 사용자가 대화형 인터페이스를 떠나지 않기 때문에 컨텍스트 스위칭(context-switching) 비용이 거의 제로에 가깝습니다.

2026년 5월 20일 기준으로, Claude 생태계에 관한 공개 문헌을 검토한 결과 이 정교한 조합은 어디에도 문서화되어 있지 않습니다. 개별 구성 요소들은 공개되어 있지만, 이 결합은 새로운 것으로 보입니다. 이것이 이 글을 쓰는 동기입니다.

1. 이 방식이 필요하게 된 맥락
   Claude.ai와 Claude Code는 서로 다른 작업 영역을 다룹니다.

Claude.ai는 의사 결정, 탐색, 문서 작업, 그리고 Model Context Protocol (MCP) 서버를 통한 짧은 도구 호출 (tool calls)에 최적화된 대화형 인터페이스(웹 또는 데스크톱)입니다. 반면 Claude Code는 코드베이스 읽기, 테스트 실행, 리팩토링 (refactors), 커밋 (commits) 등 수 시간에 걸친 자율적인 엔지니어링 작업을 수행하는 데 최적화된 명령줄 인터페이스 (CLI) 에이전트입니다. 대부분의 개발자는 이 두 도구를 별개로 사용합니다. 이들은 사고하고 결정하기 위해 채팅을 사용하고, 무언가를 구축하기 위해 Claude Code를 사용합니다. 이러한 분리에는 숨겨진 비용이 따릅니다. 수행해야 할 작업이 채팅이 편안하게 처리할 수 있는 범위를 넘어설 때 — 즉, 다중 파일 리팩토링, 구조화된 수정이 뒤따르는 감사 (audit), 테스트와 태그가 지정된 릴리스 (releases)를 포함한 수 시간의 스프린트 등 — 개발자는 두 인터페이스 사이의 오케스트레이터 (orchestrator)가 됩니다. 개발자는 계획을 머릿속에 담아둔 채, 컨텍스트 (contexts) 사이를 전환하며, 15분마다 다시 프롬프트를 입력하고, 모든 단계를 감독해야 합니다. Claude Code의 3시간 작업은 개발자의 3시간 집중력을 소모합니다. 프롬프트 엔지니어링 (prompt engineering) 숙련도가 낮은 사용자들에게 상황은 더 심각합니다. 이들이 Claude Code를 위해 작성할 수 있는 프롬프트는 도구가 자율 모드에서 생성할 수 있는 능력의 극히 일부만을 끌어낼 뿐입니다. Claude Code의 에이전트 모드 (agentic mode)는 대부분의 사용자가 작성할 줄 모르는 구조화된 브리프 (brief)를 기다립니다: 명시적인 단계, 수락 기준 (acceptance criteria), 운영 규칙, 에스컬레이션 프로토콜 (escalation protocol) 등이 포함된 브리프 말입니다. 이러한 브리프 없이는 도구의 성능이 저하되거나 작업이 경로를 이탈합니다. 하이브리드 방식은 동일한 메커니즘을 통해 이 두 가지 문제를 해결합니다. 즉, 사용자를 단일 대화형 환경에 머물게 하면서, 프롬프트 엔지니어링 작성과 실행 모두를 시스템에 위임하는 것입니다. 채팅은 사용자가 자연어로 표현한 의도를 구조화된 엔지니어링 브리프로 번역하여 실행기 (executor)에게 전달하고, 작업을 감독하며, 다시 자연어로 요약하여 반환합니다.

사용자의 기여는 의도를 표현하고, 계획을 검토하며, 결과를 승인하는 것으로 제한됩니다. 이는 정확히 사용자만이 수행할 수 있는 작업입니다. 2. 방법론의 원칙 및 설명

하이브리드 방식은 동일한 프로젝트에서 두 개의 별개 Claude 에이전트—대화형 에이전트와 실행형 에이전트—를 실행하며, 이들을 작은 전송 계층 (transmission layer)에 의해 조정되는 기능적으로 분리된 두 개의 엔진으로 취급합니다. 대화형 엔진은 Claude.ai입니다. 이는 사용자가 이미 사고하고, 질문하고, 결정하며, 글을 쓰는 데 사용하는 인터페이스입니다. 이 엔진은 대화, 의도 명확화 (disambiguation), 사용자와 공유되는 긴 문맥 (long context) 유지, 단일 MCP (Model Context Protocol) 도구 호출에 탁월합니다. 하지만 파일 시스템 (filesystem) 상에서 수 시간 동안 자율적으로 작업하는 것을 지원하지는 않습니다. 채팅은 그러한 용도로 설계되지 않았기 때문입니다.

실행형 엔진은 Anthropic이 제공하는 명령줄 인터페이스 (CLI) 에이전트인 Claude Code입니다. 구조화된 프롬프트 (prompt)와 권한 프로필을 부여받으면, 이 엔진은 자율적으로 작동합니다. 즉, 프롬프트의 수락 기준 (acceptance criteria)이 충족되거나 작업이 막힐 때까지 리포지토리 (repository)를 탐색하고, 계획을 세우고, 코드를 작성하고, 테스트하고, 커밋 (commit)하고, 수정하며, 반복 (iterate)합니다. 실행 중에는 인간의 턴제 (turn-by-turn) 개입을 요구하지 않습니다. 대신 짧은 대화형 교환에는 적합하지 않습니다.

두 에이전트 중 어느 하나만으로는 진지한 소프트웨어 프로젝트의 전체 작업 범위를 커버할 수 없습니다. 하이브리드 방식은 대화형 엔진이 실행형 에이전트의 감독관 (supervisor) 역할을 수행하며 두 엔진을 모두 실행합니다. 사용자가 대화형 경로의 능력을 벗어나는 목표를 설명하면, 채팅은 이 목표를 실행형 에이전트를 위한 구조화된 엔지니어링 프롬프트로 번역합니다. 그런 다음 실행형 에이전트를 백그라운드 프로세스로 실행하고, 주기적으로 진행 상황을 확인하며, 필요한 경우 개입하고, 결과를 자연어로 사용자에게 보고합니다. 사용자는 터미널 (terminal)을 열 필요가 전혀 없습니다.

사용자는 Claude Code를 위해 프롬프트 (prompt)를 작성하지 않습니다. 사용자는 채팅 (chat) 상태를 유지합니다. 자동차 비유는 이 방식의 명칭을 부여하며 그 기저에 깔린 논리를 명확하게 설명해 줍니다. 하이브리드 자동차는 두 개의 엔진을 동시에 작동시킵니다. 하나는 높은 부하가 걸리는 장거리 주행을 지원하지만 시동 비용이 눈에 띄게 발생하는 내연 기관 (internal combustion engine) 엔진이고, 다른 하나는 즉각적으로 시동이 걸리며 낮은 부하와 단거리 주행을 효율적으로 관리하는 전기 모터 (electric motor)입니다. 짧은 주행을 위해 시동을 건 열기관 (thermal engine)은 주행에 필요한 에너지보다 시동 시 더 많은 에너지를 낭비합니다. 반대로 장거리 주행에 투입된 전기 모터는 제약 요인이 됩니다. 하이브리드 자동차는 하나를 선택하지 않습니다. 두 엔진을 모두 작동시키며, 변속 시스템 (transmission system)이 주행 조건에 따라 특정 시점에 개입할 엔진을 선택합니다. 운전자는 페달을 밟을 뿐이며, 시스템이 그 아래에서 할당을 관리합니다. Claude.ai와 Claude Code는 비유가 아니라 구조적으로 이 두 엔진에 해당합니다. Claude.ai는 전기 모터의 특성을 가집니다. 사용자가 이미 채팅 세션에 있으므로 즉각적인 시작이 가능하고, 낮은 부하에서의 뛰어난 기동성, 매끄러운 전환, 그리고 의사결정이 이루어지는 사용자 인터페이스 (UI)를 갖추고 있습니다. Claude Code는 열기관의 특성을 가집니다. 프로젝트의 메모리 파일 (memory file)을 로드하고 리포지토리 (repository)를 탐색하는 동안 발생하는 눈에 띄는 냉간 시동 비용 (cold start cost, 통상 5~15초), 일단 실행되면 유지되는 지속적인 자율 성능, 그리고 파일 시스템 (file system) 및 버전 관리 (version control)에 대한 네이티브 접근 권한을 가집니다. 이 두 엔진 사이의 힘과 비용의 비대칭성이 바로 이들의 협업을 유용하게 만드는 핵심입니다.

각 엔진을 단독으로 사용할 경우, 각 엔진이 우위를 점하는 영역과 잘못된 선택이 되는 영역이 존재합니다. 명시적인 할당 정책과 작은 전송 계층 (Transmission Layer)을 갖추어 함께 사용하면, 실제 소프트웨어 프로젝트의 전체 운영 범위를 커버할 수 있습니다.

3. 기술 아키텍처

두 엔진 사이의 전송 계층은 어떠한 커스텀 통신 프로토콜에도 의존하지 않습니다. 이는 표준적인 개발 환경의 모든 머신에 이미 존재하는 세 가지 구성 요소, 즉 로컬 파일 시스템 (Filesystem), 버전 관리 시스템 (VCS), 그리고 대화형 엔진에 Bash 도구를 노출하는 작은 MCP 서버를 기반으로 구축됩니다. MCP 서버는 설치 및 설정이 필요한 유일한 구성 요소입니다. Anthropic의 공식 Python MCP SDK를 사용하는 약 200줄 정도의 Python 코드면 충분합니다. 이미 여러 커뮤니티 구현체도 사용 가능합니다.

이 서버는 대화형 엔진이 호스트 머신에서 쉘 명령어를 실행할 수 있게 해주는 도구(이를 bash_local이라고 부릅시다)를 노출합니다. 이 도구는 두 엔진 사이의 가교 역할을 합니다. 대화형 엔진은 이 도구를 사용하여 실행형 엔진을 백그라운드에서 서브프로세스 (Subprocess)로 실행하며, 이후 상태 파일을 조사하거나 git 로그를 읽기 위해 이를 사용합니다.

실행 명령 자체는 표준 nohup 호출이며, 수 페이지 분량의 프롬프트 엔지니어링 (Prompt Engineering) 결과물을 표준 입력 (Standard Input)으로 넣어 Claude Code를 생성 (Spawn)합니다: nohup bash -c 'echo "$PROMPT" | claude -p --model opus-4-7 --effort xhigh --dangerously-skip-permissions > /tmp/sprint_run.log 2>&1' &. 실행기 (Executor)가 시작되면, 두 엔진은 오직 파일 시스템 (Filesystem)에 기록된 아티팩트 (Artifacts)를 통해서만 통신합니다. 실행기는 현재 상태를 읽을 수 있는 형태로 반영하는 진행 파일 (Progress file, 일반적으로 /tmp/sprint_progress.md)을 유지합니다. 만약 작업이 막히면, 차단 파일 (/tmp/sprint_blocked.md)을 작성하고 다음 하위 작업 (Sub-task)으로 넘어갑니다. 커밋 (Commits)은 작업이 완료됨에 따라 git 리포지토리 (Repository)로 푸시 (Push)됩니다. 대화형 엔진 (Conversational engine)은 5분에서 10분 간격으로 자신의 bash_local 도구를 통해 이 세 가지 소스 — 진행 파일, 차단 파일의 존재 여부, 최신 git 로그 (git log) 항목 — 를 조사합니다. 콜백 (Callbacks), 스트리밍 (Streaming), WebSocket 연결은 없습니다. 파일 시스템이 채널이며, git이 분산 시계 (Distributed clock) 역할을 합니다. 이 아키텍처의 미묘하지만 중요한 구성 요소는 관례적으로 CLAUDE.md라고 명명된 프로젝트 메모리 파일입니다. Anthropic은 현재 디렉토리의 루트에 이 이름을 가진 모든 파일이 각 세션 시작 시 컨텍스트 (Context)에 자동으로 로드된다는 규칙을 Claude Code에 연결해 두었습니다. 이는 실행기의 지속적인 프로젝트 메모리 역할을 합니다. 하이브리드 방식에서 대화형 엔진 또한 프로젝트와 관련된 모든 대화의 시작 시점에 자신의 bash_local 도구를 통해 명시적으로 이 동일한 파일을 읽습니다. 따라서 두 엔진은 프로젝트에 대한 동일한 공유 이해도를 가지고 시작합니다: 프로젝트의 정체성, 현재 상태, 아키텍처 컨벤션 (Architectural conventions), 각 엔진이 할 수 있는 일과 금지된 일을 규정하는 엄격한 규칙, 필수 읽기 목록, 그리고 에스컬레이션 (Escalation) 프로토콜 등이 그것입니다.

이러한 공유된 메모리 (Shared memory)는 전달 과정을 신뢰할 수 있게 만드는 핵심 요소입니다. 대화형 엔진 (Conversational engine)이 실행기 (Executor)를 위한 스프린트 프롬프트 (Sprint prompt)를 작성할 때, 프로젝트 컨텍스트 (Project context)를 반복해서 설명할 필요가 없습니다. 실행기는 이미 CLAUDE.md를 통해 해당 정보를 가지고 있기 때문입니다. 따라서 프롬프트는 현재 스프린트의 구체적인 사항, 즉 어떤 하위 작업 (Sub-tasks)을, 어떤 수락 기준 (Acceptance criteria)과 함께, 어떤 순서로, 어떤 운영 규칙 (Operational rules)에 따라 수행할지에만 온전히 집중할 수 있습니다. 잘 관리된 CLAUDE.md는 이 구성에서 가장 과소평가된 산출물 (Artefact)입니다. 데이터 흐름을 도식화하면 다음과 같습니다:

사용자 (자연어) │
▼ Claude.ai (대화형 엔진)
│ MCP 도구 bash_local 사용
│ nohup claude -p ... & 실행
▼ Claude Code (실행 엔진, 백그라운드 서브프로세스)
│ CLAUDE.md 자동 읽기
│ stdin으로부터 엔지니어링 프롬프트 읽기
│ 13시간 동안 자율적으로 작업
│ 점진적으로 커밋 (Commit) 및 푸시 (Push)
▼ git 저장소 (유일한 진실의 원천, Single source of truth)
│ Claude.ai가 510분마다 다음 사항을 조사:
- git log의 최신 항목
- /tmp/sprint_progress.md
- /tmp/sprint_blocked.md (존재하는 경우)
▼ Claude.ai가 사용자에게 자연어로 보고

이 아키텍처의 그 어떤 것도 필요하지...