3,600개 별이 증명한 '맥락의 박제', Conductor의 등장

AI 코딩 도구를 사용할 때 세션이 바뀔 때마다 프로젝트 구조와 라이브러리를 다시 설명해야 하는 불편함이 반복된다. AI가 이전 대화를 잊고 아키텍처를 추측해 코드를 작성하면, 개발자는 잘못된 코드를 수정하는 데 더 많은 시간을 쓰게 된다. 이러한 맥락의 휘발성 문제를 해결하기 위해 2025년 12월 17일 프리뷰로 출시된 도구가 Conductor다. Conductor는 프로젝트의 맥락을 채팅창이 아닌 저장소 내 마크다운 파일로 관리하는 컨텍스트 기반 개발(CDD) 방식을 도입했다.

출시 이후 Conductor의 GitHub 저장소는 별 3,600개와 포크 284개를 기록했다. 2026년 4월에는 구글의 단계별 학습 가이드인 Google Codelab을 통해 신규 프로젝트를 구축하는 그린필드 사례가 공개되었다. 기존 AI 코딩의 문제는 세션마다 맥락이 초기화되는 '상태 없음' 구조에 있었다. AI가 실제 구조를 모르는 상태에서 추측만으로 코드를 작성하면 실제 아키텍처와 어긋난 결과물이 나오기 때문이다.

Conductor는 AI가 아키텍처를 추측하게 두지 않고, 명세서와 계획서라는 물리적인 기록에 따라 움직이게 하여 개발자의 통제권을 확보한다. 작업 단위별로 명확한 커밋을 남기고 계획에 따라 구현하는 워크플로를 통해 AI 결과물을 검토하고 수정하는 시간을 줄인다. 업데이트된 마크다운 파일 하나로 맥락을 동기화하는 방식이 실무적인 대안이 된다.

컨텍스트 기반 개발(CDD)의 3단계 레이어 구조

CDD(Context-Driven Development)는 프로젝트의 맥락과 계획을 저장소 내 마크다운 파일로 관리하는 방식이다. AI가 저장소에 박제된 명세서를 읽고 작업을 시작하게 함으로써, 개발자가 AI의 기억(맥락)을 직접 제어하는 관리형 아티팩트(Artifact) 체계로 전환한다.

이 시스템은 컨텍스트(Context), 트랙(Track), 구현(Implementation)으로 이어지는 3계층 아키텍처로 작동한다. 컨텍스트 레이어는 프로젝트의 전체 방향성, 기술 스택, 코딩 스타일 같은 공통 분모를 정의한다. 트랙 레이어는 개별 기능 구현이나 버그 수정 같은 구체적인 작업 단위로 맥락을 쪼개어 관리하며, AI가 작업 범위를 벗어나 엉뚱한 코드를 작성하는 것을 막는 가이드라인 역할을 한다. 마지막 구현 레이어는 앞선 두 단계에서 정의된 명세와 계획을 바탕으로 실제 코드를 작성하는 단계다.

실제 워크플로는 맥락 구축 $ ightarrow$ 기능 명세(Spec) $ ightarrow$ 구현 계획(Plan) $ ightarrow$ 코드 작성의 순서를 따른다. 먼저 프로젝트 전반의 맥락을 구축한 뒤, 요구사항과 범위를 담은 `spec.md` 파일을 작성한다. 이후 단계별 체크리스트가 담긴 `plan.md` 파일을 생성해 구현 경로를 확정한다. AI는 이 계획서의 체크박스를 하나씩 채우며 코드를 작성하고, 각 작업이 끝날 때마다 개별 커밋을 남긴다. 개발자는 AI가 코드를 작성하기 전 계획서를 직접 수정해 작업 범위를 정밀하게 통제할 수 있다.

'상태 없음'의 코딩에서 '관리되는 아티팩트'로의 전환

기존의 AI 코딩 워크플로는 세션을 종료하는 순간 이전의 설계 선택 이유와 구축 내용을 망각하는 상태 없음(Stateless) 방식으로 작동한다. 구글 클라우드 개발자는 이런 모델의 특성을 일시적이고 제멋대로 행동하는 카우보이에 비유했다. 이로 인해 AI는 아키텍처를 그럴듯하게 추측해 코드를 짜고, 개발자는 이를 다시 뜯어고치는 비효율을 겪는다.

Conductor는 프로젝트의 정체성을 저장소 내 마크다운 파일로 유지하는 관리되는 아티팩트 개념으로 이를 해결한다. AI 에이전트는 코드를 수정하기 위해 실행될 때마다 코딩 표준, 기술 스택 결정 사항, 제품 목표가 기록된 파일들을 읽어 들인다. 이 파일들은 버전 관리 시스템(Git)에 함께 기록되어 이동하므로, AI가 매번 다른 답을 내놓는 불안정성을 제거하고 정의된 규칙 안에서만 움직이도록 강제할 수 있다.

실제 적용 시에는 기존 코드베이스가 있는 브라운필드(Brownfield)와 신규 프로젝트인 그린필드(Greenfield) 환경을 모두 지원한다. `/conductor:setup` 명령어를 실행하면 Conductor는 기존 저장소를 분석해 기술 스택과 아키텍처를 자동으로 추론한다. 이때 `.gitignore` 및 `.geminiignore` 패턴을 준수하여 `node_modules`나 `__pycache__` 같이 토큰 소모가 심한 디렉토리를 분석 대상에서 제외한다. 신규 프로젝트의 경우에는 사용자 인터뷰를 통해 기초 맥락을 생성하고 방향성을 설정한다.

설치부터 첫 구현까지: 실무 적용 튜토리얼

Conductor를 사용하려면 먼저 Gemini CLI 환경을 구축해야 한다. 터미널에서 아래 명령어를 입력해 도구를 전역으로 설치한다.

bash
npm install -g @google/gemini-cli

설치 후 Google API 키를 등록하거나 Vertex AI 인증을 완료한다. Conductor는 작업 단위별로 커밋을 남겨야 하므로 프로젝트 폴더 내에서 Git 초기화가 필수적이다.

bash
git init

준비된 환경 위에 Conductor를 설치해 프로젝트 전용 컨텍스트 관리 체계를 구축한다.

bash
npm install -g @google/conductor

설치 완료 후 Gemini CLI 세션에서 `/conductor:setup` 명령어를 실행한다. Conductor는 코드베이스 분석이나 사용자 인터뷰를 통해 `product.md`(제품 목적), `tech-stack.md`(허용 라이브러리 및 패턴), `workflow.md`를 포함한 6가지 컨텍스트 아티팩트를 자동 생성한다. 이 파일들은 `conductor/` 디렉토리에 저장되어 팀원 모두가 동일한 맥락을 공유하게 만든다.

실제 기능 구현은 `/conductor:newTrack [기능명]` 명령어로 시작한다. 이 명령을 내리면 `spec.md`, `plan.md`, `status.md` 세 가지 파일이 생성되어 기능 범위와 구현 계획이 수립된다. 계획서 작성이 끝나면 `/conductor:implement`를 실행해 실제 코드를 작성한다. AI는 `plan.md`의 체크리스트를 수행하며 각 태스크 완료 시마다 개별 Git 커밋을 남긴다. 전체 과정은 `setup`, `newTrack`, `implement`, `status`, `revert`, `review`라는 6가지 핵심 명령어로 통제한다.

'약속보다 증명'을 우선하는 실무자의 제어 방식

Conductor는 인간이 개입하는 Human-in-the-loop 방식을 통해 AI의 임의 추측을 제어한다. `/conductor:implement` 명령어를 실행하기 전, 개발자가 AI가 작성한 `plan.md` 파일을 직접 열어 수정하는 단계가 필수적이다. 작업 범위가 너무 넓거나 단계가 잘못되었다면 텍스트를 고쳐 AI의 경로를 수정함으로써 구현 도중에 방향을 트는 비용을 줄인다.

작업의 추적 가능성은 커밋 단위에서 관리된다. Conductor는 개별 태스크가 완료될 때마다 즉시 Git 커밋을 남긴다. AI는 `plan.md`의 체크박스를 `[ ]`(대기) $ ightarrow$ `[~]`(진행 중) $ ightarrow$ `[x]`(완료)로 업데이트하며 기록을 남긴다. 예를 들어 다크 모드 구현 중 색상 정의 태스크가 끝나면 즉시 커밋하고, 다음 UI 컴포넌트 적용 태스크가 끝나면 다시 커밋하는 식이다. 이를 통해 개발자는 AI의 실수 지점을 정확히 짚어내고 특정 태스크 단위로 롤백할 수 있다.

'약속보다 증명(Proof over Promise)' 원칙은 페이즈 종료 시점에 적용된다. AI가 계획서의 한 페이즈를 완료했다고 주장해도, 개발자가 직접 코드를 실행하고 수동 검증을 거쳐 승인해야만 다음 페이즈 작업이 시작된다. 구현 완료라는 AI의 주장보다 실제 동작하는 코드라는 증거를 먼저 확인하는 절차를 강제해 품질을 보장한다.

`conductor/` 디렉토리를 저장소에 함께 커밋하면 팀원 모두가 동일한 프로젝트 맥락을 즉시 공유한다. 새로 합류한 팀원이 AI에게 프로젝트 구조를 다시 설명하거나 온보딩 문서를 읽는 시간을 줄일 수 있다. 도구가 주는 편의성보다 개발자가 쥐고 있는 제어권의 크기가 실제 생산성을 결정한다.

AI에게 프로젝트 구조와 라이브러리를 매번 다시 설명하는 소모적인 대화는 이제 멈춰도 좋다. `/conductor:setup` 명령어로 생성한 6가지 컨텍스트 아티팩트가 있다면 AI는 추측이 아닌 명세서와 계획서라는 물리적 근거에 따라 작업한다.

결국 AI 코딩의 생산성은 도구의 지능이 아니라 개발자가 쥐고 있는 제어권의 크기에서 결정된다. AI가 아키텍처를 추측하게 두지 않고 명확한 문서로 맥락을 박제하는 것이 실무자가 확보해야 할 가장 확실한 통제권이다.