Gemini Conductor: AI 코딩을 고치러 온 구글의 새로운 도구
원제 · Gemini Conductor: Google's New Tool is Here To Fix AI Coding
핵심 요약
구글의 Gemini Conductor는 트랙 기반 작업 관리와 Git 통합 등 일부 기능은 괜찮지만, 부적절한 기술 스택 추천, 치명적인 파일 삭제 오류, 불완전한 작업 처리 등의 문제로 인해 실무에서 사용하기 어려운 도구입니다.
하이라이트
구글의 Gemini Conductor는 컨텍스트 엔지니어링 워크플로우를 제공하지만 다른 도구들보다 나은 점이 없음
Conductor는 Gemini CLI 확장 프로그램으로 설치되며 트랙 기반으로 작업을 관리하는 방식 사용
프로젝트 초기화 시 기술 스택 추천이 부적절하고 중요한 요소들을 놓치는 문제 발생
NPM을 PNPM으로 변경 요청 시 conductor 폴더 전체를 삭제하는 치명적 오류 발생
환경 변수 설정 시 더미 키를 입력하고 실제 키를 요청하지 않아 작업이 실패함
80% 테스트 커버리지와 Git 통합 등 일부 워크플로우 기능은 양호한 편
현재로서는 Be Mad가 훨씬 더 나은 옵션이며 작은 프로젝트는 직접 컨텍스트 파일을 만드는 것을 권장
타임라인
인트로 및 Automata 소개
채널에서 다뤄온 다양한 컨텍스트 엔지니어링 워크플로우를 언급하며 구글의 새로운 워크플로우 Conductor를 소개합니다. 발표자는 이 도구가 다른 워크플로우보다 낫지 않으며 많은 문제가 있다고 솔직하게 밝힙니다. Gemini 생태계 내에서도 여전히 좋지 않다고 평가하며, 본론으로 들어가기 전에 Automata 서비스를 소개합니다. Automata는 수백만 명에게 AI 구축 방법을 가르친 경험을 바탕으로 고객의 아이디어를 앱이나 웹사이트로 실현해주는 기술 공동 조종사 역할을 한다고 설명합니다.
Conductor의 작동 원리와 설치 방법
Conductor가 실제로 어떻게 작동하는지 설명하며 문서 링크를 제공합니다. Conductor는 Gemini CLI에 확장 프로그램으로 설치되는데, 확장 프로그램은 명령어, MCP, 기타 규칙을 하나로 묶어 패키지화한 것입니다. Claude의 플러그인과 유사한 개념으로, 명령어를 통해 설치하면 됩니다. 설치 후에는 Conductor의 슬래시 명령어를 사용할 수 있으며, 워크플로우를 제어하는 다섯 가지 명령어가 제공됩니다.
Setup 명령어와 초기 프로젝트 설정
가장 먼저 사용하는 setup 명령어의 기능을 상세히 설명합니다. 이 명령어는 기존 Conductor 파일의 존재 여부를 확인하고, 트랙이라는 파일을 만들어 하나씩 완료합니다. 새로운 GitHub 저장소를 초기화하고 무엇을 만들지 물어보는데, 발표자는 간단한 프로젝트를 만들면서도 아키텍처의 품질을 테스트하고자 했습니다. 프로덕션 준비가 되어 있고 더 많은 사용자로 확장 가능해야 한다고 명시했으며, product.md 파일이 생성되었습니다. 처음에는 질문을 통해 다듬으려 했으나 질문들이 단순해서 결국 모든 것을 자동 생성하도록 했습니다.
제품 가이드라인 및 기술 스택 정의의 문제점
제품 가이드를 승인한 후 스타일링과 디자인 원칙에 중점을 둔 제품 가이드라인 파일이 생성되었습니다. 이후 기술 스택을 정의하는 과정에서 Conductor의 첫 번째 주요 문제가 드러났습니다. 전체 프로젝트의 성격을 알고 있었음에도 불구하고 제안한 기술 스택이 엉망이었고 적절한 것을 제대로 추천하지 않았습니다. 발표자가 직접 수정한 후에야 기술 스택을 승인하고 MD 파일을 업데이트할 수 있었습니다.
코드 스타일 가이드와 워크플로우의 장점
프로젝트에서 사용할 언어에 따라 코드 스타일 가이드가 초기화 중에 추가됩니다. Conductor가 기본적으로 사용하는 워크플로우는 실제로 꽤 좋은 편입니다. 80% 코드 테스트 커버리지를 기본으로 포함하고 있으며, 기본 컴포넌트를 작성하는 동안 테스트도 함께 작성되는지 확인합니다. 작업 완료 후에도 테스트를 진행하며, 모든 작업 후 변경사항을 커밋하고 git notes를 사용하여 문제 발생 시 추적이 가능하도록 합니다.
트랙 시스템과 Implement 명령어
초기 설정 완료 후 상위 수준의 제품 요구사항을 만들어 초기 트랙을 시작합니다. 첫 번째 트랙이 너무 광범위해서 더 작은 트랙으로 나눌 필요가 있었습니다. 하나의 트랙에서 처리하기에는 너무 많은 작업이 포함되어 있어 엉망이 될 가능성이 높았습니다. implement 명령어를 실행하면 tracks 폴더의 다양한 트랙을 하나씩 구현하기 시작합니다. 각 트랙에는 plan.md와 spec.md 두 개의 파일이 있으며, spec.md는 목표와 기술 스택에서 추출한 기술적 세부 사항을, plan.md는 구현해야 할 작업 목록을 포함합니다.
기타 명령어와 파일 관리 구조
implement 명령어는 tracks.md를 보고 각 트랙의 상태에 따라 수행할 작업을 결정합니다. 비어 있으면 시작 전, 진행 중, 완료 상태로 구분됩니다. status 명령어는 현재 진행 상황과 트랙 완료 상태에 대한 보고서를 제공합니다. new track 명령어는 새로운 작업에 대한 질문을 하며, 기존 저장소에 구현할 때는 기존 파일을 확인하고 명확한 질문만 합니다. revert 기능은 정말 똑똑하게 손상을 완화하고 git을 인식하여 에이전트의 실수를 복구할 수 있습니다. 현재 파일 관리와 구조는 나쁘지 않으며, 트랙으로 작업을 구현하고 추적하는 방식은 실제로 꽤 좋은 편입니다.
지침과 명령어의 근본적 문제점
파일 관리는 괜찮지만 지침이 작성된 방식과 명령어 파일에는 개선이 필요합니다. 컨텍스트 루프를 제대로 관리하지 못하고 있으며, 변경 사항 처리에도 문제가 있습니다. 초기 프로세스 중에 많은 실수가 발생했는데, 첫 번째 실수는 각 문서 생성 시 아이디어를 제대로 분석하지 않아 발표자가 직접 많은 부분을 안내해야 했다는 점입니다. 기술 스택 정의 시에도 많은 것을 놓쳤으며, 확장 가능한 앱을 원한다고 명시했음에도 명확하게 다시 설명해야 했습니다. 초기 트랙 생성 시 데이터베이스 스키마가 완전히 불완전했고, 앱 설정에 중요한 요소들을 놓쳐서 다시 올바른 방향으로 이끌어야 했습니다.
치명적인 파일 삭제 오류 사례
Gemini 자체는 좋은 모델이므로 문제는 구현된 명령어들에 있다고 판단됩니다. 가장 큰 문제는 메인 슬래시 명령어들과 workflow.md에 있습니다. NPM을 PNPM으로 변경하고 싶다고 말했을 때 치명적인 오류가 발생했습니다. 먼저 백업을 만들려고 시도하면서 NPM 파일들을 제거해야 한다고 했는데, 결국 모든 계획 파일이 들어있던 conductor 폴더 전체를 삭제해버렸습니다. 삭제 후에는 계속 그 폴더를 찾다가, 찾을 수 없게 되자 컨텍스트와 메모리에 있는 모든 것을 사용해서 conductor 폴더를 재구성하겠다고 했습니다. 정상적인 컨텍스트 워크플로우는 변경사항이 메인 컨텍스트 파일과 관련 파일에만 영향을 미쳐야 하는데, 모든 것을 다시 작성해야 했습니다.
환경 변수 설정 오류와 작업 처리 문제
갑작스러운 변경 요청이 없었다면 잘 진행됐을 수도 있지만, 여전히 근본적인 문제가 있습니다. 첫 번째 트랙 구현 시작 시 프로젝트와 핵심 서비스들을 초기화했는데, Supabase 연결을 위한 환경 변수 구성에서 문제가 발생했습니다. 어떤 이유에서인지 더미 키를 넣어놓고 자동으로 작업을 완료된 것으로 표시했습니다. Supabase 프로젝트 설정이나 실제 키 제공을 요청하지도 않았으며, 자동으로 데이터베이스 스키마를 푸시하려다 실패했습니다. 이후 문자열을 다시 확인하라고 요청했지만 작업들조차 제대로 업데이트되지 않았고 올바르게 따르지도 않았습니다.
결론 및 대안 제시
발표자는 솔직하게 현재로서는 엔드 투 엔드 스펙 개발에 Conductor를 사용하지 않을 것이라고 결론 내립니다. Be Mad가 훨씬 더 나은 옵션이며, 작은 프로젝트의 경우에는 여전히 자신만의 컨텍스트 파일을 만드는 것을 선호한다고 밝힙니다. 영상의 마지막에서 채널을 지원하고 이런 영상을 계속 만드는 데 도움을 주고 싶다면 Super Thanks 버튼을 사용해달라고 안내하며, 시청에 감사하고 다음 영상에서 만나자는 인사로 마무리합니다.
설명
Google AI가 Gemini CLI를 위한 새로운 컨텍스트 엔지니어링 워크플로우인 Conductor를 출시했습니다. 하지만 기존 도구들을 능가할까요? BMAD와 Claude 기반 설정 같은 코딩 워크플로우와 비교 테스트를 진행하며 이 코드 생성 시스템이 시간을 투자할 가치가 있는지 확인했습니다. 솔직한 평가를 들려드립니다. 이 영상에서는 Google의 Gemini CLI용 새로운 Conductor 확장 프로그램을 분석합니다. AI 지원 개발을 위한 구조화된 컨텍스트 엔지니어링 워크플로우를 구축하려는 구글의 최신 시도입니다. Conductor는 설치 가능한 확장 프로그램으로 작동하며, 전체 개발 프로세스를 관리할 수 있는 슬래시 명령어 세트를 제공합니다. 설정 명령을 실행하고 프로젝트를 정의하면, 시스템이 계획 문서, 트랙, 스펙, 구현 파일을 생성하여 AI가 단계별로 애플리케이션을 구축하도록 안내합니다. 워크플로우는 트랙 기반 시스템을 사용하며, 각 기능이나 컴포넌트마다 계획 파일과 스펙 파일이 포함된 고유 폴더가 생성됩니다. AI는 이러한 트랙을 하나씩 처리하면서 이론적으로는 컨텍스트를 유지하고 개념부터 완성까지 구조화된 경로를 따릅니다. 이론적으로는 괜찮아 보입니다. 자동 테스트 커버리지 요구사항, 변경 사항 추적을 위한 Git 통합, 다양한 언어의 코드 스타일 가이드, Git 인식을 통해 에이전트의 실수를 되돌릴 수 있는 revert 명령 등이 포함되어 있습니다. 하지만 여기서부터 문제가 시작됩니다. 테스트 중 시스템은 기본적인 컨텍스트 관리에서 반복적으로 실패했습니다. 확장 가능한 프로덕션 앱의 기술 스택을 정의할 때, 제가 수동으로 수정해야 했던 중요한 컴포넌트들을 누락했습니다. 생성된 초기 트랙은 너무 광범위했고, 단일 구현 주기에 너무 많은 작업을 집어넣어 오류가 누적될 수밖에 없는 구조였습니다. 생성된 데이터베이스 스키마는 불완전했으며, 제공한 프로젝트 요구사항에서 명확히 암시된 필드와 관계가 누락되어 있었습니다. 컨텍스트상 명백했어야 할 결정들을 지속적으로 안내하고 수정해야 했습니다. 가장 큰 문제는 설정 중간에 NPM에서 PNPM으로 전환하도록 요청했을 때 발생했습니다. 목표를 두고 변경하는 대신, 백업 프로세스를 시도하다가 어떻게든 전체 Conductor 폴더를 삭제했습니다. 모든 계획 파일, 스펙, 트랙이 사라진 것입니다. 그런 다음 메모리에서 모든 것을 재구성하려고 했는데, 이는 영구 컨텍스트 파일을 사용하는 전체 목적을 무색하게 만듭니다. 정상적인 구현 중에도 명확히 완료되지 않은 작업을 완료된 것으로 표시했습니다. 환경 변수에 더미 API 키를 넣고, 실제 Supabase 프로젝트를 설정하거나 실제 자격 증명을 제공하라고 요청하지도 않은 채 데이터베이스 스키마를 푸시하려고 했습니다. 핵심 문제는 명령 파일과 워크플로우 지침이 작성된 방식에 있는 것으로 보입니다. Gemini는 유능한 모델이므로, 문제는 거의 확실히 확장 프로그램 자체의 부실한 프롬프트 엔지니어링에서 비롯됩니다. 컨텍스트 루프가 제대로 관리되지 않고, 변경 사항이 올바르게 추적되지 않으며, 시스템이 기존 작업을 날려버리지 않고 수정 사항을 처리하는 방법을 모릅니다. 이를 BMAD와 비교해보면, BMAD는 모든 것을 삭제하고 처음부터 다시 시작하는 대신 관련 파일만 업데이트하여 컨텍스트 변경을 처리합니다. 이것이 바로 적절한 컨텍스트 엔지니어링의 모습입니다. 전면적인 재구축이 아닌 정밀한 업데이트 말입니다. 현재로서는 심각한 엔드투엔드 개발 작업에 Conductor를 추천하지 않습니다. 구조화된 AI 코딩 워크플로우가 필요하다면 BMAD가 더 나은 옵션으로 남아 있습니다. 소규모 프로젝트의 경우, 저는 여전히 처음부터 직접 컨텍스트 파일을 구축하는 것을 선호합니다. 업데이트를 통해 개선될 수 있지만, 현재 상태로는 프로덕션 사용에 적합하지 않습니다.