Gemini Conductor: AI 코딩을 고치러 온 구글의 새로운 도구

채널에서 다뤄온 다양한 컨텍스트 엔지니어링 워크플로우를 언급하며 구글의 새로운 워크플로우 Conductor를 소개합니다. 발표자는 이 도구가 다른 워크플로우보다 낫지 않으며 많은 문제가 있다고 솔직하게 밝힙니다. Gemini 생태계 내에서도 여전히 좋지 않다고 평가하며, 본론으로 들어가기 전에 Automata 서비스를 소개합니다. Automata는 수백만 명에게 AI 구축 방법을 가르친 경험을 바탕으로 고객의 아이디어를 앱이나 웹사이트로 실현해주는 기술 공동 조종사 역할을 한다고 설명합니다.

Conductor가 실제로 어떻게 작동하는지 설명하며 문서 링크를 제공합니다. Conductor는 Gemini CLI에 확장 프로그램으로 설치되는데, 확장 프로그램은 명령어, MCP, 기타 규칙을 하나로 묶어 패키지화한 것입니다. Claude의 플러그인과 유사한 개념으로, 명령어를 통해 설치하면 됩니다. 설치 후에는 Conductor의 슬래시 명령어를 사용할 수 있으며, 워크플로우를 제어하는 다섯 가지 명령어가 제공됩니다.

가장 먼저 사용하는 setup 명령어의 기능을 상세히 설명합니다. 이 명령어는 기존 Conductor 파일의 존재 여부를 확인하고, 트랙이라는 파일을 만들어 하나씩 완료합니다. 새로운 GitHub 저장소를 초기화하고 무엇을 만들지 물어보는데, 발표자는 간단한 프로젝트를 만들면서도 아키텍처의 품질을 테스트하고자 했습니다. 프로덕션 준비가 되어 있고 더 많은 사용자로 확장 가능해야 한다고 명시했으며, product.md 파일이 생성되었습니다. 처음에는 질문을 통해 다듬으려 했으나 질문들이 단순해서 결국 모든 것을 자동 생성하도록 했습니다.

제품 가이드를 승인한 후 스타일링과 디자인 원칙에 중점을 둔 제품 가이드라인 파일이 생성되었습니다. 이후 기술 스택을 정의하는 과정에서 Conductor의 첫 번째 주요 문제가 드러났습니다. 전체 프로젝트의 성격을 알고 있었음에도 불구하고 제안한 기술 스택이 엉망이었고 적절한 것을 제대로 추천하지 않았습니다. 발표자가 직접 수정한 후에야 기술 스택을 승인하고 MD 파일을 업데이트할 수 있었습니다.

프로젝트에서 사용할 언어에 따라 코드 스타일 가이드가 초기화 중에 추가됩니다. Conductor가 기본적으로 사용하는 워크플로우는 실제로 꽤 좋은 편입니다. 80% 코드 테스트 커버리지를 기본으로 포함하고 있으며, 기본 컴포넌트를 작성하는 동안 테스트도 함께 작성되는지 확인합니다. 작업 완료 후에도 테스트를 진행하며, 모든 작업 후 변경사항을 커밋하고 git notes를 사용하여 문제 발생 시 추적이 가능하도록 합니다.

초기 설정 완료 후 상위 수준의 제품 요구사항을 만들어 초기 트랙을 시작합니다. 첫 번째 트랙이 너무 광범위해서 더 작은 트랙으로 나눌 필요가 있었습니다. 하나의 트랙에서 처리하기에는 너무 많은 작업이 포함되어 있어 엉망이 될 가능성이 높았습니다. 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 버튼을 사용해달라고 안내하며, 시청에 감사하고 다음 영상에서 만나자는 인사로 마무리합니다.