2026년 Sonar 조사에 따르면 개발자의 88%가 AI가 생성한 코드가 기술 부채를 늘리고 있다고 답했습니다. 명세 기반 개발(spec-driven development)의 지지자들은 규율 있는 명세 단계를 통해 이러한 흐름을 막을 수 있다고 주장합니다.
이 문제가 중요한 이유
사람이 모호한 티켓을 받으면 명확한 질문을 던집니다. 반면 AI 에이전트는 빈칸을 최선의 추측으로 채우고 그럴듯해 보이는 코드를 넘겨줍니다. 이러한 '정확해 보이는 착각'은 비용이 많이 듭니다. 동일한 Sonar 설문조사에 따르면 응답자의 절반 이상이 기본적인 검사를 통과했지만 미묘한 결함을 숨기고 있는 코드를 본 적이 있다고 답했습니다. 이러한 결함은 기술 부채로 쌓여 나중에 리팩토링을 강제하고, 기능 배포를 늦추며, 유지보수 예산을 늘립니다.
명세 기반 개발이란 무엇인가
명세 기반 개발(SDD)은 현재의 순서를 뒤집습니다. AI 모델에 짧은 사용자 스토리(user story)를 프롬프트로 입력하는 대신, 팀은 코드와 동일한 버전 관리 시스템에 저장되는 상세하고 에이전트가 실행 가능한 명세를 작성합니다. 명세는 의도, 엣지 케이스(edge cases), 성능 기대치 및 AI 모델이 준수해야 하는 모든 제약 조건을 기록하는 단일 진실 공급원(single source of truth)이 됩니다.
이 프로세스는 인간의 설계 작업을 대체하는 것이 아니라, 이를 코드화하는 것입니다. 결정을 개발자의 기억에서 구체적인 문서로 옮김으로써, 인간과 향후 AI 에이전트 모두 특정 코드가 왜 그렇게 동작하는지 추적할 수 있습니다. 명세를 초안하는 데는 초기에 노력이 들지만, 모호한 AI 출력물을 디버깅하는 데는 나중에 훨씬 더 많은 비용이 듭니다.
워크플로의 변화
제품 백로그(Product backlog) – 항목을 짧게 유지하며 의도와 높은 수준의 수용 기준(acceptance criteria)만 담습니다. 이 목록은 계속해서 우선순위 결정의 기준이 됩니다.
스프린트 계획(Sprint planning) – 팀은 전반적인 목표를 논의하고 스프린트 목표(Sprint Goal)에 합의하지만, 명세가 준비될 때까지 세부 구현은 보류합니다.
스프린트 진행 중 – 작업을 가져온 담당자는 정밀하고 기계가 읽을 수 있는 명세를 작성합니다. 명세에는 입력 형식, 예상 출력, 오류 처리 및 기타 비기능 요구사항이 포함됩니다. 명세는 버전 관리되므로, 리뷰어는 코드와 마찬가지로 의견을 남기고, 수정을 제안하며, 변경 사항을 승인할 수 있습니다.
완료 정의(Definition of Done) – 품질 게이트에 “명세 검토 및 승인됨”을 추가합니다. 명세가 구현 코드와 동일한 검토 표준을 통과하기 전까지는 어떤 코드도 완료된 것이 아닙니다.
칸반(Kanban) 적용 – “명세 초안 작성(Spec Drafted)”과 “명세 승인됨(Spec Approved)”이라는 두 개의 새로운 열을 삽입합니다. 이제 작업 항목은 백로그 → 스프린트 목표 → 명세 초안 작성 → 명세 승인됨 → 진행 중 → 완료 순으로 흐릅니다. 이러한 시각적 변화는 이전에 보이지 않았던 조정 단계를 명확하게 만듭니다.
이미 명세를 강제하는 도구들
GitHub Spec Kit 및 AWS Kiro와 같은 플랫폼은 AI 코드 생성이 시작되기 전에 요구사항 문서가 필요하도록 게이트를 추가했습니다. 이들은 AI 모델을 대체하는 것이 아니라, 글자 그대로만 받아들이는 에이전트를 인간의 의도와 일치시킵니다. 명세를 전제 조건으로 만듦으로써, 이러한 도구들은 기존 CI/CD 파이프라인을 깨뜨리지 않고 변화를 자동화합니다.
잠재적인 반론
비판론자들은 명세를 작성하는 것이 이미 빠르게 진행되는 애자일 리듬에 마찰을 더한다고 말합니다. 이에 대한 반론은 다음과 같습니다. 명세를 작성하는 데 소비되는 시간은 대개 모호한 프롬프트로 인해 생성된 AI 코드를 나중에 디버깅하는 데 드는 시간의 극히 일부에 불과합니다.
또 다른 우려는 요구사항이 진화함에 따라 명세가 구식이 될 수 있다는 점입니다. 버전 관리 통합이 이 문제를 해결합니다. 명세의 모든 변경 사항은 새로운 커밋을 생성하고, 리뷰를 트리거하며, 팀이 관련 코드를 재평가하도록 강제합니다. 실제로 명세를 코드처럼 취급하면 문서를 최신 상태로 유지할 수 있습니다.
향후 주목할 점
도입 초기 단계이지만 그 모멘텀은 눈에 띕니다. AI 코드 생성기가 더욱 유능해짐에 따라, 정밀하고 기계가 읽을 수 있는 의도에 대한 필요성은 더욱 커질 것입니다.
핵심 요약: 모호한 프롬프트를 구체적이고 검토된 명세로 전환하는 것이 추가 단계처럼 느껴질 수 있지만, 이는 추측을 책임 있는 결정으로 바꿔줍니다.