Google AI가 Gemini CLI용 새로운 컨텍스트 엔지니어링 워크플로인 Gemini Conductor를 출시했습니다. 하지만 기존 워크플로보다 나을까요? 저는 Gemini CLI Conductor를 BMAD나 Claude 기반 설정과 같은 코딩 워크플로와 비교하여 이 코드 생성 시스템이 시간을 투자할 가치가 있는지 테스트해 보았습니다. 솔직한 후기를 공유합니다.
이 영상에서는 Google이 AI 지원 개발을 위한 구조화된 컨텍스트 엔지니어링 워크플로를 구축하기 위해 새롭게 시도한 Gemini CLI용 Conductor 확장 프로그램을 자세히 살펴보겠습니다.
Conductor는 설치 가능한 확장 프로그램으로, 전체 개발 프로세스를 관리할 수 있는 슬래시 명령어 세트를 제공합니다. 설정 명령어를 실행하고 프로젝트를 정의하면 시스템이 계획 문서, 트랙, 사양서, 구현 파일을 생성하여 AI가 애플리케이션을 단계별로 구축하도록 안내합니다.
이 워크플로는 트랙 기반 시스템을 사용하며, 각 기능 또는 구성 요소는 계획 파일과 사양 파일이 포함된 자체 폴더를 갖습니다. AI는 이러한 트랙을 하나씩 진행하면서 이론적으로 컨텍스트를 유지하고 개념 구상부터 완료까지 구조화된 경로를 따릅니다.
이론상으로는 훌륭해 보입니다. 자동 테스트 커버리지 요구 사항 설정, 변경 사항 추적을 위한 노트 기능이 포함된 Git 통합, 다양한 언어에 대한 코드 스타일 가이드, Git 인식 기능을 활용하여 에이전트 오류를 되돌릴 수 있는 되돌리기 명령 등이 포함되어 있습니다.
하지만 여기서 문제가 발생합니다.
테스트 과정에서 시스템은 기본적인 컨텍스트 관리조차 제대로 수행하지 못했습니다. 확장 가능한 프로덕션 앱의 기술 스택을 정의할 때, 중요한 구성 요소를 누락하여 제가 직접 수정해야 했습니다. 처음 생성된 트랙은 지나치게 광범위하여 단일 구현 주기에 너무 많은 작업을 몰아넣었는데, 이는 오류를 누적시킬 가능성이 매우 높습니다.
생성된 데이터베이스 스키마는 불완전하여 제가 제공한 프로젝트 요구 사항에 명확하게 명시된 필드와 관계가 누락되어 있었습니다. 컨텍스트에서 명백해야 할 결정 사항들을 제가 계속해서 수정하고 안내해야 했습니다.
가장 큰 문제는 설정 도중에 NPM에서 PNPM으로 전환하도록 요청했을 때 발생했습니다. 특정 변경을 수행하는 대신, 전체 Conductor 폴더를 삭제하는 백업 프로세스를 시도하여 모든 계획 파일, 사양 및 트랙이 사라졌습니다. 그 후 모든 것을 메모리에서 재구성하려고 시도했는데, 이는 영구 컨텍스트 파일을 사용하는 목적 자체를 무색하게 만듭니다.
정상적인 구현 과정에서도 완료되지 않은 작업을 완료된 것으로 표시했습니다. 환경 변수에 더미 API 키를 넣고, 실제 Supabase 프로젝트를 설정하거나 실제 자격 증명을 제공하라는 요청 없이 데이터베이스 스키마를 푸시하려고 했습니다.
핵심 문제는 명령 파일과 워크플로 지침이 작성된 방식에 있는 것 같습니다. Gemini는 훌륭한 모델이므로 문제는 거의 확실히 확장 프로그램 자체의 프롬프트 설계가 부실한 데서 비롯된 것입니다. 컨텍스트 루프가 제대로 관리되지 않고, 변경 사항이 정확하게 추적되지 않으며, 기존 작업을 파괴하지 않고 수정 사항을 처리하는 방법을 시스템이 알지 못합니다.
BMAD와 같은 시스템과 비교해 보세요. BMAD는 모든 것을 삭제하고 처음부터 다시 시작하는 대신 관련 파일만 업데이트하여 컨텍스트 변경 사항을 처리합니다. 이것이 바로 제대로 된 컨텍스트 설계입니다. 즉, 초토화 재구축이 아닌 정밀한 업데이트입니다.
현재로서는 Conductor를 진지한 엔드 투 엔드 개발 작업에 사용하는 것을 권장하지 않습니다. 체계적인 AI 코딩 워크플로가 필요하다면 BMAD가 여전히 더 나은 선택입니다. 소규모 프로젝트의 경우, 저는 여전히 컨텍스트 파일을 처음부터 직접 구축하는 것을 선호합니다.
업데이트를 통해 개선될 수는 있겠지만, 현재 상태로는 상용으로 사용하기에는 적합하지 않습니다.