Spec-Driven Development, 왜 주목받을까?
AI 코딩 도구가 쏟아지면서 개발자들이 겪는 가장 큰 문제는 컨텍스트 유실이에요. 채팅 로그에만 의존하다 보면 어제 설계한 아키텍처가 오늘 사라지고, 새 세션을 열 때마다 프로젝트 맥락을 처음부터 다시 설명해야 하죠.
Conductor는 이 문제를 정면으로 다뤘습니다. 프로젝트 인식을 휘발성 채팅 로그에서 꺼내 버전 관리되는 마크다운 파일로 옮긴 거예요. spec.md, plan.md 같은 산출물이 저장소에 남기 때문에, AI가 생성한 설계가 곧 팀의 문서가 됩니다.
이 접근법을 Spec-Driven Development(SDD) 라고 부릅니다. 코드를 짜기 전에 스펙을 명확히 정의하고, 그 스펙을 AI와 함께 반복적으로 다듬는 방식이에요. 자세한 배경은 근거자료에서 확인할 수 있습니다.
확장(Extension)에서 플러그인(Plugin)으로
이번 변화의 핵심은 배포 단위의 전환이에요. 기존 Conductor는 Gemini CLI 전용 확장이었지만, 이제 플러그인 형태로 패키징됩니다.
플러그인이 뭘 담을 수 있나?
플러그인은 다음 요소를 하나의 패키지로 묶을 수 있어요:
- Skills — 특정 작업을 수행하는 능력
- Rules — 프로젝트 규칙/제약
- MCP Servers — 외부 도구 연결
- Hooks — 라이프사이클 이벤트 트리거
이 구조 덕분에 Conductor는 Gemini CLI를 벗어나 Antigravity CLI 같은 다른 도구에서도 동작합니다. 즉, 특정 CLI에 락인(lock-in)되지 않는 이식성 있는 자산이 된 거죠.
설치 방법
Antigravity CLI에 통합하려면 다음 한 줄이면 됩니다:
# Antigravity CLI에 Conductor 플러그인 설치
agy plugins install https://github.com/gemini-cli-extensions/conductor
설치 후에는 별도 명령어 시퀀스를 외울 필요 없이, 자연어로 대화하면서 스펙과 플랜을 생성할 수 있어요.
대화형 SDD: 무엇이 달라졌나?
Before vs After
| 항목 | 기존 (Extension) | 변경 후 (Plugin) |
|---|---|---|
| 워크플로우 | 엄격한 커맨드 시퀀스 | 대화형, 유연한 흐름 |
| 컨텍스트 생성 | 수동 트리거 | 대화 중 자동 생성 |
| 도구 호환성 | Gemini CLI 전용 | Gemini CLI, Antigravity CLI 등 |
| 산출물 | spec.md, plan.md | spec.md, plan.md (동일) |
| 프로젝트 상태 관리 | 사용자가 직접 | AI가 백그라운드에서 관리 |
실제로 어떻게 동작하나
기능 요구사항을 AI와 대화로 풀어놓으면, Conductor가 알아서:
- 프로젝트 컨텍스트를 업데이트하고
- 새로운 스펙을 생성하며
plan.md의 완료된 태스크를 체크오프합니다
개발자는 아키텍처에 집중하고, 프로젝트 상태 관리는 AI가 백그라운드에서 처리하는 구조예요. 이건 단순한 UX 개선이 아니라, SDD의 절차적 엄격함과 대화형 편의성을 동시에 잡으려는 시도로 보입니다.
생태계 관점에서의 의미
여러 CLI 도구가 공통 설정과 개발 트랙을 공유할 수 있다는 건, AI 워크플로우의 연속성이 확보된다는 뜻이에요. 한 도구에서 시작한 작업을 다른 도구에서 이어받아도 컨텍스트 손실이 없다는 거죠.
이 기술의 한계와 주의사항
- CLI 생태계 의존성: Conductor는 여전히 CLI 기반이에요. GUI 중심 워크플로우를 선호하는 팀에는 진입 장벽이 될 수 있습니다.
- 마크다운 산출물 관리 부담:
spec.md,plan.md가 저장소에 쌓이면, 결국 이 문서들의 버전 관리와 리뷰 프로세스를 팀 차원에서 정해야 해요. - 플러그인 생태계 성숙도: Antigravity CLI는 아직 신생 도구라, 실무에서의 안정성은 검증이 더 필요합니다.
- AI 자동 상태 관리의 리스크: AI가 백그라운드에서 태스크를 체크오프한다는 건 편리하지만, 잘못된 업데이트가 누적되면 플랜이 실제 진행 상황과 어긋날 수 있어요. 주기적인 사람 검토가 필요합니다.
한국 개발 생태계에서의 적용 맥락
국내 SI·스타트업 환경에서는 스펙 문서화가 곧 커뮤니케이션 비용이에요. 기획-개발-QA 사이의 핸드오프가 잦은 조직이라면, AI가 생성한 spec.md를 그대로 협업 산출물로 활용하는 전략이 특히 효과적입니다.
다만 국내 팀 문화상 AI가 만든 문서를 그대로 신뢰하기 어려운 경우가 많죠. Conductor의 산출물은 초안(draft)으로 취급하고, 시니어가 리뷰하는 프로세스를 함께 설계하는 걸 권합니다.
다음 단계 학습 방향
- SDD 방법론 자체를 먼저 이해하세요. 도구는 수단일 뿐, 스펙 우선 사고방식이 체화되어야 효과가 납니다.
- MCP 서버 연동을 실습해보세요. Conductor 플러그인이 외부 도구와 어떻게 결합되는지 감이 옵니다.
- 직접 Codelab을 돌려보며 대화형 워크플로우를 체험하는 게 가장 빠릅니다.
함께 보면 좋은 글
AI 개발 워크플로우는 지금 빠르게 재편되고 있어요. Conductor의 플러그인 전환은 그 흐름의 한 축일 뿐이고, 핵심은 스펙을 코드보다 먼저 다루는 습관입니다. 도구가 바뀌어도 이 원칙은 남습니다.