스펙 기반 개발(Spec-Driven Development)은 진짜 문제를 해결하지 못했다
스펙 기반 개발(SDD)은 AI 에이전트가 잘못된 코드를 작성하는 문제에 대한 새로운 해답으로 떠오르고 있습니다.
워크플로우는 간단합니다. 구조화된 스펙을 작성하면, 에이전트가 계획을 실행하고, 사용자가 결과를 검토합니다. GitHub Spec Kit, OpenSpec, Kiro와 같은 도구들이 이러한 변화를 주도하고 있습니다.
이 방식은 단순 프롬프팅보다 효과적이지만, 치명적인 결함이 있습니다.
스펙이 '신뢰할 수 있는 단일 원천(source of truth)'으로 유지되어야 한다는 점에 의존하기 때문입니다. 하지만 이는 거짓입니다.
지난 20년 동안 우리는 문서와 코드를 동기화하려고 노력해 왔습니다. 설계 문서, 위키, README 모두 실패했습니다. 왜일까요? 코드를 수정하는 것은 빠르고 즉각적인 가치를 제공하지만, 문서를 수정하는 것은 느리고 눈에 보이는 결과가 없기 때문입니다. 문서는 항상 속도에 밀립니다.
SDD도 똑같은 문제에 직면해 있습니다.
에이전트가 제약 사항에 부딪히면, 작동하게 만들기 위해 코드를 수정합니다. 그러면 이제 코드와 스펙이 일치하지 않게 됩니다. 스펙은 며칠 지나지 않아 쓸모없게 됩니다. 대부분의 프레임워크는 이를 해결하기 위해 "규율(discipline)"을 지키라고 말합니다. 하지만 규율은 이전에도 매번 우리를 실망시켰습니다.
코딩 전에 전체 스펙을 작성한다는 것은 구현 과정에서 아무것도 배우지 않는다는 것을 전제로 합니다. 이는 피드백 루프를 깨뜨립니다. 애자일 개발을 무겁고 사전 작업이 많이 필요한 프로세스로 변질시킵니다.
한 개발자는 SDD를 사용하여 수개월간 프로젝트를 진행했습니다. 에이전트는 모든 스펙을 완벽하게 따랐지만, 시스템은 결국 실패했습니다. 스펙은 구축 과정에서만 나타나는 지식을 포착할 수 없었기 때문입니다. 작은 인프라 변경 하나가 전체 스펙 그래프를 망가뜨렸습니다.
또 다른 팀은 SDD를 시도했다가 속도가 10배나 느려진다는 것을 발견했습니다. 형식적인 절차(ceremony)는 더 많아졌지만 버그의 수는 동일했습니다.
목표는 더 많은 문서를 만드는 것이 되어서는 안 됩니다.
진짜 문제는 어떻게 스펙을 살아있게 유지하느냐입니다. 우리는 스스로 업데이트되는 스펙이 필요합니다. 코드와 실행 중인 시스템으로부터 스펙을 추론하는 도구가 필요합니다. 마치 lockfile처럼 작동해야 하며, 반드시 자동화되어야 합니다.
이것이 아직 가능한지 확신할 수 없습니다. 실제 프로덕션 환경에서 작업하는 분들의 의견을 듣고 싶습니다.
- 스펙이 3주 이상 유지되나요?
- 스펙이 어긋날 때, 무엇이 그 원인인가요?
- 코드나 텔레메트리(telemetry)로부터 스펙을 생성해 보셨나요?
- 엄격한 규칙이 가치를 더하나요, 아니면 단순한 형식에 불과한가요?
Optional learning community: https://t.me/GyaanSetuAi