스펙 주도 개발(SDD), 왜 다시 주목받고 있을까
작년 Conductor가 처음 등장했을 때 핵심 메시지는 단순했어요. "프로젝트 인식을 휘발성 채팅 로그에서 꺼내서, 버전 관리되는 마크다운 파일로 옮기자." 이게 바로 Spec-Driven Development(SDD)의 출발점입니다.
AI 코딩 도구가 쏟아지면서 개발자들이 겪는 진짜 문제는 코드 생성 속도가 아니에요. 컨텍스트가 다음 세션으로 이어지지 않는다는 점입니다. 어제 Claude랑 짠 아키텍처를 오늘 Cursor에서 다시 설명해야 하고, 그 설명은 또 어딘가로 흘러가 버리죠. Conductor는 이 문제를 spec.md와 plan.md라는 영속적 산출물로 해결하려 했습니다.
이번 업데이트는 그 다음 단계예요. 확장(Extension)에서 **플러그인(Plugin)**으로 체급을 바꿨습니다. 단순한 이름 변경이 아니라, 워크플로우 자체가 달라지는 전환이에요. 근거자료는 Google Developers Blog 원문에서 확인할 수 있습니다.
확장 vs 플러그인, 뭐가 달라졌나
1. 명령어 시퀀스의 족쇄가 풀렸다
기존 Conductor는 확장이었기 때문에 정해진 명령어 흐름을 따라야 했어요. /conductor:plan 같은 걸 순서대로 호출하는 식이죠. 이제는 **대화형(conversational)**으로 바뀝니다.
# 설치 자체는 여전히 한 줄입니다
agy plugins install https://github.com/gemini-cli-extensions/conductor
설치 후에는 기능 요구사항을 그냥 이야기하면 돼요. AI가 알아서 컨텍스트를 갱신하고, 스펙을 만들고, 플랜의 완료된 태스크를 체크오프합니다. 개발자는 아키텍처에만 집중하면 됩니다.
2. 툴 종속성에서 해방
이게 실무에서 가장 체감이 큰 변화예요. 기존에는 Gemini CLI 전용이었습니다. 이제 플러그인이기 때문에 Antigravity CLI를 비롯한 여러 도구에서 동일한 Conductor를 쓸 수 있어요.
# 프로젝트 루트에 유지되는 산출물
project/
├── spec.md # 아키텍처 스펙 (버전 관리 대상)
├── plan.md # 태스크 플랜 (체크리스트 형태)
└── .conductor/ # 공유 설정
3. 컨텍스트가 툴을 넘어 이어진다
A 도구에서 시작한 워크플로우를 B 도구에서 이어받아도 컨텍스트 손실이 없습니다. 공유 설정과 개발 트랙이 그대로 유지되기 때문이에요. 여러 AI 도구를 병행하는 팀이라면 이 부분이 결정적입니다.
플러그인 아키텍처, 한눈에 비교
| 항목 | 기존 Extension | 신규 Plugin |
|---|---|---|
| 배포 단위 | Gemini CLI 전용 확장 | skills + rules + MCP servers + hooks 통합 패키지 |
| 인터랙션 | 명령어 시퀀스 기반 | 대화형, 동적 컨텍스트 생성 |
| 툴 호환 | Gemini CLI 한정 | Antigravity CLI 등 멀티 툴 |
| 산출물 | spec.md, plan.md | 동일 (영속성 유지) |
| 컨텍스트 이식 | 불가 | 툴 간 seamless 이전 |
| 진입 장벽 | 명령어 학습 필요 | 자연어 대화로 시작 |
주의할 점
- "대화형"이 곧 "아무렇게나"는 아닙니다. spec.md와 plan.md는 여전히 엄격한 포맷을 따라야 하고, AI가 임의로 스펙을 갈아엎지 않도록 리뷰 습관은 유지해야 해요.
- 플러그인이니 만큼 권한 범위가 넓어집니다. hooks와 MCP servers가 함께 패키징된다는 건, 파일 시스템·네트워크 접근 권한도 같이 딸려온다는 뜻이에요. 사내 보안 정책이 있는 팀은 설치 전 감사(audit)가 필요합니다.
- 아직 초기 단계입니다. Antigravity CLI 지원은 발표됐지만, 다른 CLI로의 확장은 앞으로의 로드맵에 달려 있어요.
다음 단계 학습 방향
- 공식 Codelab으로 플러그인 기능을 직접 테스트
- 팀 프로젝트 하나에 spec.md/plan.md를 도입해 2주간 운영
- 여러 AI CLI를 병행하는 워크플로우를 실험해 컨텍스트 이식성 검증
한국 개발 생태계에서의 적용 맥락
국내 SI·외주 환경에서는 요구사항 변경이 잦고, 문서화가 뒤로 밀리는 경우가 많아요. Conductor의 spec.md/plan.md는 이 문제에 꽤 잘 맞습니다. 다만 SI 특성상 고객사가 특정 AI 도구만 허용하는 경우가 있으니, 멀티 툴 지원이 실제로는 제약이 될 수도 있다는 점은 감안해야 해요.
스타트업이나 사내 프로덕트 팀이라면 훨씬 유리합니다. 여러 AI 도구를 자유롭게 넘나들 수 있고, 컨텍스트 이식성이 곧 온보딩 속도로 이어지니까요.
마무리
Conductor의 이번 전환은 "확장을 플러그인으로 바꿨다"는 기술적 사실보다, SDD를 도구 종속성에서 해방시켰다는 점이 본질입니다. AI 코딩 도구가 난립하는 지금, 프로젝트 컨텍스트를 어디에 둘 것인가는 앞으로 몇 년간 가장 중요한 설계 결정 중 하나가 될 거예요.