규격 주도 개발이란

서론

2025년 10월, GitHub는 Spec Kit이라는 툴킷을 오픈소스로 공개하며 「규격 주도 개발」(Spec-Driven Development)이라는 개념을 AI 프로그래밍의 영역으로 공식적으로 끌어왔습니다. 복고적으로 보일 수 있는 이 이념 -- 규격을 먼저 작성하고 코드를 나중에 작성하는 것 -- 이 AI 프로그래밍 도구를 다루는 새로운 패러다임이 되고 있습니다.

Claude Code, Cursor 또는 GitHub Copilot과 같은 AI 프로그래밍 어시스턴트를 자주 사용하신다면, 분명 이런 어려움을 겪어보셨을 것입니다: 「사용자 로그인 기능을 추가해줘」라고 말하면, AI가 의욕적으로 많은 코드를 작성하지만, 자세히 살펴보면 -- 익숙하지 않은 프레임워크를 사용하고, 보안 전략이 기대와 다르고, UI 스타일도 맞지 않습니다……그리고 수정을 반복하다가 결국 지치게 됩니다.

문제가 어디에 있을까요? AI가 충분히 똑똑하지 않은 것이 아니라, 여러분이 제공한 정보가 충분하지 않은 것입니다. 「사용자 로그인 기능 추가」라는 말은 명확해 보이지만, 실제로는 수백 가지의 명시되지 않은 결정을 숨기고 있습니다: 어떤 인증 방식을 사용할 것인가? 비밀번호 요구사항은 무엇인가? 로그인 실패는 어떻게 처리할 것인가? 로그인 상태를 기억해야 하는가? 제3자 로그인을 지원할 것인가?……AI는 추측할 수밖에 없고, 추측은 곧 편차를 의미합니다.

규격 주도 개발은 바로 이 문제를 해결하기 위해 탄생했습니다.

Vibe Coding: 속도의 대가

2025년 초, 전 Tesla AI 디렉터 Andrej Karpathy가 「Vibe Coding」이라는 용어를 만들어, 「AI의 제안을 심층 검토 없이 수용하는」 개발 방식을 설명했습니다. 이 용어는 빠르게 유행하며 Collins 사전의 2025년 올해의 단어로 선정되기까지 했습니다.

Vibe Coding의 유혹은 분명합니다: 아이디어를 설명하면 AI가 코드를 생성하고, 실행되는 것처럼 보이면 됩니다. 빠른 프로토타입, 해커톤, 일회성 스크립트에는 이 방식이 확실히 효율적입니다. 하지만 프로덕션 시스템에 사용되면 문제가 발생합니다.

이와 유사한 사례는 업계에서 흔히 볼 수 있습니다: AI가 생성한 데이터베이스 쿼리가 소규모 테스트에서는 잘 작동했지만 실제 트래픽에서는 시스템이 느려졌고, 조합된 인증 모듈이 QA를 통과했지만 2주 후 비활성화된 계정이 여전히 관리 도구에 접근할 수 있다는 것이 발견되었습니다. Final Round AI의 2025년 조사에 따르면, 18명의 CTO 중 16명이 AI 생성 코드로 인한 프로덕션 장애를 경험했습니다.

이것은 Vibe Coding이 전혀 가치가 없다는 의미가 아닙니다. 핵심은 경계를 식별하는 것입니다:

규격 주도 개발은 AI의 효율성을 유지하면서 Vibe Coding의 함정을 피하기 위한 것입니다.

규격 주도 개발이란 무엇인가

규격 주도 개발의 핵심 이념은 한 문장으로 요약할 수 있습니다: 「무엇을 할 것인가」를 먼저 정의하고, 「어떻게 할 것인가」를 나중에 고려합니다.

이것은 소프트웨어 엔지니어링에서 익숙한 이야기처럼 들리지만, AI 프로그래밍 시대에는 새로운 의미를 갖게 되었습니다. 전통적인 요구사항 문서는 사람을 위해 작성되었기 때문에 장황하고 모호하며 전문 용어로 가득 차 있는 경우가 많습니다. 규격 주도 개발에서의 「규격」은 AI를 위해 작성됩니다 -- 간결하고, 구조화되어 있으며, 실행 가능합니다.

집을 짓는다고 상상해 보십시오. 전통적인 AI 프로그래밍 방식은 시공팀에게 「편안한 3베드룸 집을 지어주세요」라고 말하고 알아서 하도록 맡기는 것과 같습니다. 결과가 괜찮을 수도 있지만, 여러분이 상상했던 것과 크게 다를 가능성이 더 높습니다. 규격 주도 개발은 먼저 건축 설계도를 그리는 것입니다: 몇 층인지, 각 층의 면적은 얼마인지, 창문 방향, 자재 규격……시공팀이 설계도대로 시공하면 결과는 자연히 기대에 부합합니다.

AI 프로그래밍에서 이 설계도가 바로 규격 문서(Specification)입니다. 어떤 프로그래밍 언어를 사용하는지, 어떤 프레임워크를 사용하는지는 관심사가 아니며, 기능이 어떤 효과를 달성해야 하는지, 사용자가 어떤 작업을 완료해야 하는지, 성공의 기준이 무엇인지만 다룹니다.

전통적인 개발 프로세스와 비교했을 때, 규격 주도 개발에는 근본적인 차이가 있습니다:

이러한 「점진적 구체화」 과정이 바로 규격 주도 개발의 핵심입니다. 한 번에 완성하는 것이 아니라, 여러 단계를 거쳐 요구사항을 점진적으로 명확히 하며, 각 단계에서 검토하고 조정할 수 있습니다.

Speckit 워크플로우 개요

GitHub의 Spec Kit과 Claude Code의 speckit 명령은 모두 유사한 워크플로우를 따르며, 대략 6단계로 나눌 수 있습니다:

Constitution → Specify → Clarify → Plan → Tasks → Implement
     ↓            ↓          ↓        ↓       ↓         ↓
  프로젝트 헌법   기능 규격   모호점 명확화  기술 계획  작업 분해   실행 구현

1. Constitution(프로젝트 헌법)

프로젝트 헌법은 프로젝트 전체의 기본 원칙과 제약 조건을 정의합니다. 예를 들어 「테스트 우선」「단순함 우선」「API 우선」 등이 있습니다. 이러한 원칙은 이후 모든 단계에 적용되어, AI가 생성하는 방안이 여러분의 기술적 선호도에 부합하도록 보장합니다.

2. Specify(기능 규격)

이것은 핵심적인 첫 번째 단계입니다. 자연어로 원하는 기능을 설명하면, AI가 이를 구조화된 규격 문서로 정리해 줍니다. 여기에는 다음이 포함됩니다:

• 사용자 스토리: 누가 무엇을 왜 하는가
• 기능 요구사항: 시스템이 반드시 갖추어야 할 능력
• 성공 기준: 기능의 달성 여부를 어떻게 판단하는가

중요한 것은, 규격 문서는 「무엇을 할 것인가」에만 집중하며 「어떻게 할 것인가」는 다루지 않습니다 -- 구체적인 기술 스택을 언급하지 않고, 코드 구조를 작성하지 않습니다.

3. Clarify(모호점 명확화)

AI가 규격의 모호한 부분을 검토하고, 최대 5개의 핵심 질문을 제시합니다. 이러한 질문은 보통 기능 범위, 사용자 유형, 보안 요구사항 등에 관한 것입니다. 질의응답을 통해 규격이 더욱 명확해집니다.

4. Plan(기술 계획)

명확한 규격이 완성된 후에야 기술 방안을 고려하기 시작합니다. 이 단계에서는 다음이 산출됩니다:

• 기술 선정(언어, 프레임워크, 데이터베이스)
• 데이터 모델 설계
• API 계약 정의
• 연구 보고서(기술 결정 해결)

5. Tasks(작업 분해)

기술 계획을 실행 가능한 작업 목록으로 분해합니다. 각 작업에는 명확한 ID, 설명, 파일 경로가 있어 AI에게 직접 맡겨 실행할 수 있습니다. 작업은 사용자 스토리별로 그룹화되며, 병렬 개발을 지원합니다.

6. Implement(실행 구현)

작업 목록에 따라 하나씩 실행합니다. 각 작업이 완료되면 완료로 표시하여 추적 가능성을 보장합니다.

이 6단계의 산출물은 명확한 체인을 형성합니다:

이 방식이 효과적인 이유

규격 주도 개발이 「AI에게 직접 코드를 작성하게 하는 것」이 실패하는 곳에서 성공할 수 있는 이유는, AI 프로그래밍의 핵심 모순인 정보 비대칭을 해결하기 때문입니다.

「사진 공유 기능 추가」라고 말할 때, 여러분의 머릿속에는 완전한 그림이 있을 수 있지만, AI는 이 몇 글자만 볼 수 있습니다. AI는 추측해야 합니다: 어디에 공유하는가? 누가 볼 수 있는가? 압축이 필요한가? 워터마크가 있는가? 일괄 처리를 지원하는가?……모든 추측이 틀릴 수 있습니다.

규격 주도 개발은 「먼저 생각을 정리하도록 강제하는 것」을 통해 이 문제를 해결합니다. 사용자 스토리, 기능 요구사항, 성공 기준을 작성하도록 요구받으면, 「당연하다고 생각했던」 세부사항들이 수면 위로 떠오릅니다. 이 과정 자체가 가치가 있습니다 -- AI를 사용하지 않더라도 요구사항을 명확히 작성하면 커뮤니케이션 비용을 줄일 수 있습니다.

또한 점진적 구체화는 오류를 더 일찍 노출시킵니다. Specify 단계에서 요구사항 편차를 발견하면 수정 비용이 거의 제로입니다. 코드가 완성된 후에야 발견하면 처음부터 다시 해야 할 수도 있습니다.

물론 규격 주도 개발이 만능은 아닙니다. 명확한 적용 시나리오가 있습니다:

적합한 경우:

• 복잡한 기능 개발(여러 모듈, 다양한 인터랙션 포함)
• 팀 협업 프로젝트(규격 문서가 커뮤니케이션 매개체 역할)
• 높은 품질이 요구되는 시나리오(추적 가능성, 검증 가능성 필요)

적합하지 않은 경우:

• 간단한 버그 수정이나 작은 변경
• 탐색적 프로그래밍(무엇을 할지 아직 모를 때)
• 시간이 극도로 촉박한 경우(규격을 작성할 시간이 없을 때)

핵심은 작업의 복잡도를 식별하는 것입니다. 한 시간 안에 완료할 수 있는 일에 한 시간을 들여 규격을 작성할 필요는 없습니다. 하지만 일주일짜리 기능 개발에 두 시간을 들여 규격을 작성하는 것은 충분히 가치가 있습니다.

그러나 규격은 만능이 아닙니다

흔한 오해를 바로잡을 필요가 있습니다: 규격 주도 개발은 추측을 줄이지만, 검토의 필요성을 없애지는 않습니다.

완전한 규격이 있더라도, AI는 여전히 다음과 같은 실수를 할 수 있습니다:

• 경계 케이스 누락(규격이 다루지 않은 극단적 시나리오)
• 성능 요구사항을 충족하지 못하는 코드 생성
• 잠재적 보안 취약점 도입
• 일관성 없는 스타일의 구현 산출

이것은 건축 시공과 같습니다: 상세한 설계도가 있더라도 준공 검사는 여전히 필요합니다. 시공팀이 도면대로 집을 지었다고 해서 바로 입주하지는 않을 것입니다 -- 전기 회로가 안전한지, 배관이 원활한지, 문과 창문이 견고한지 확인할 것입니다.

규격 주도 개발의 가치는 오류를 더 쉽게 발견할 수 있게 하는 것이지, 오류 자체를 없애는 것이 아닙니다.

요약

규격 주도 개발의 핵심은 간단한 이치입니다: 작업이 복잡할수록, 실행 전에 먼저 생각을 정리하는 것이 더 중요합니다. AI 프로그래밍 도구는 이 이치의 중요성을 증폭시킵니다 -- AI는 여러분의 지시를 충실히 실행하지만, 여러분의 의도를 진정으로 이해할 수는 없기 때문입니다.

세 가지 핵심 키워드를 기억하십시오:

이념을 이해하셨다면, 다음 글 《Speckit 실천 가이드》에서 직접 실습해 보실 수 있습니다: speckit 명령을 사용하여 하나의 기능에 대한 규격 주도 개발 프로세스를 완성하는 방법을 안내합니다.

《Claude Skills》와 함께 사용하면, 규격의 실행을 더욱 자동화하고 표준화할 수 있습니다.