Spec-Driven Development:From Code to Contract in the Age of AI Coding Assistants
이 논문은 명세(specification)를 주요 산출물로 취급하는 것이 어떻게 다양한 소프트웨어 도메인 전반에서 AI 코딩 어시스턴트를 효과적으로 활용할 수 있는지를 입증하기 위해, 명세 기반 개발(Spec-Driven Development, SDD)의 원칙, 세 가지 수준의 명세 엄격도, 그리고 지원 도구들을 개괄하며 SDD에 대한 종합적인 가이드를 제시한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
당신은 매우 유능하고, 엄청나게 빠르지만, 약간은 글자 그대로만 받아들이는 로봇 요리사에게 복잡한 식사를 요리하도록 고용했다고 상상해 보십시오.
과거의 방식 (코드 우선 방식):
당신은 로봇에게 다가가 이렇게 말합니다. "맛있는 저녁을 만들어 줘."
로봇은 기쁘게 응답하기 위해 즉시 채소를 썰고 팬을 달구기 시작합니다. 로봇은 당신이 파스타를 원할 것이라고 추측합니다. 매콤한 맛을 원할 것이라고 추측합니다. 당신이 언급하지도 않은 비싼 트러플 오일을 사용할 것이라고 추측합니다.
10분 후, 당신 앞에는 매콤한 트러플 파스타가 놓여 있습니다. 당신가 원했던 것은 샐러드였습니다.
이제 당신은 로봇에게 멈추라고 말하고, 파스타를 버리고, 처음부터 다시 시작해야 합니다. 이것이 논문에서 말하는 "바이브 코딩(vibe coding)"입니다. 즉, AI가 당신의 의도를 추측하게 만드는 모호한 프롬프트에 의존하는 방식입니다. 그 결과는 대개 끊임없는 수정이 필요한 엉망진창인 상태가 됩니다.
새로운 방식 (명세 주도 개발):
주문을 소리 높여 외치는 대신, 먼저 **레시피 카드(명세서)**를 작성합니다.
당신은 정확하게 적습니다: "나는 샐러드를 원해. 시금치, 토마토, 페타 치즈를 사용해. 견과류는 넣지 마. 드레싱은 따로 담아줘. 상온 상태로 내어줘."
당신은 이 카드를 로봇에게 건넵니다. 로봇은 이를 읽고, 자신의 이해도를 확인한 뒤, 그다음에 요리를 시작합니다.
만약 로봇이 견과류를 넣으려 한다면, 카드가 "견과류 금지"라고 명시했기 때문에 로봇은 멈춥니다. 만약 뜨겁게 내놓으려 한다면, 로봇은 멈춥니다.
이 시나리오에서 **레시피 카드가 주인(boss)**입니다. 음식(코드)은 단지 레시피를 따르는 결과물일 뿐입니다. 만약 음식이 맛이 없다면, 당신은 요리사를 탓하는 것이 아니라 레시피가 명확했는지를 확인합니다.
세 가지 엄격함의 단계
이 논문은 항상 50페이지짜리 계약서가 필요한 것은 아니라고 설명합니다. 이 "레시レシピ 카드" 접근 방식을 사용하는 데는 얼마나 진지하냐에 따라 세 가지 방법이 있습니다.
명세 우선 (스케치 방식):
- 정의: 모두가 무엇을 만들 것인지 합의하기 위해 요리를 시작하기 전에 레시피를 작성합니다.
- 사용 시점: 새로운 아이디어를 시험하거나 일회성 프로젝트를 진행할 때 좋습니다.
- 주의점: 식사가 완성되면 레시피 카드를 버릴 수도 있습니다. 나중에 레시피를 변경하더라도 카드가 업데이트되지 않을 수 있습니다. 시작 단계에는 좋지만, 장기적인 유지보수에는 적합하지 않습니다.
명세 앵커링 (살아있는 메뉴 방식):
- 정의: 레시피 카드를 가스레인지 옆 냉장고에 붙여둡니다. 요리(치즈를 더 넣거나 드레싱을 바꾸는 등)를 변경할 때마다 즉시 카드를 업데이트해야 합니다.
- 사용 시점: 대부분의 전문적인 주방(프로덕션 소프트웨어)에 가장 적합한 방식입니다.
- 마법 같은 점: 주방에는 로봇 검사관이 있습니다. 만약 요리사가 요리를 변경했는데 카드 업데이트를 잊었다면, 검사관이 경보를 울립니다. 이는 메뉴(문서)가 항상 음식(소프트웨어)과 일치하도록 보장합니다.
명세가 곧 소스 (3D 프린터 방식):
- 정의: 이것은 가장 극단적인 버전입니다. 당신은 음식에 직접 손을 대지 않습니다. 오직 레시피 카드만 편집합니다. 그러면 기계가 오직 그 카드에 기반하여 음식을 자동으로 출력합니다.
- 사용 시점: 자동차 엔진을 만들거나 의료 기기를 만드는 것과 같이 실수가 위험을 초래할 수 있는 고도의 정밀도가 요구되는 분야에서 사용됩니다.
- 규칙: 자동차 브레이크를 바꾸고 싶다면, 렌치를 들고 보닛 아래로 손을 집어넣지 않습니다. 청사진을 수정하면, 기계가 브레이크를 완벽하게 다시 만듭니다. 당신은 생성된 부품을 수동으로 편집하는 것이 절대 허용되지 않습니다.
AI가 이를 필수로 만드는 이유
이 논문은 AI 코딩 어시스턴트가 재능은 있지만 글자 그대로만 받아들이는 그 로봇 요리사와 같다고 주장합니다. 그들은 지시를 따르는 데는 뛰어나지만, "독심술"에는 서툽니다.
- 명세가 없을 때: 당신이 "로그인 기능을 추가해 줘"라고 요청하면, AI는 비밀번호 규칙, 데이터베이스 유형, 보안 수준 등을 스스로 추측합니다. 그리고 종종 틀리곤 합니다.
- 명세가 있을 때: 당신은 AI에게 명확한 계약을 제공합니다: "로그인은 12자리의 비밀번호를 필요로 하며, 이메일을 사용하고, 3회 로그인 실패 시 계정을 잠근다." AI는 규칙을 완벽하게 따릅니다.
워크플로우: 4단계의 춤
논문은 이 과정의 간단한 리듬을 제안합니다:
- 명세(Specify): "무엇(What)"을 작성합니다. (레시피)
- 계획(Plan): "어떻게(How)"를 작성합니다. (장보기 목록과 주방 배치)
- 구현(Implement): 구축합니다. (요리하기)
- 검증(Validate): 확인합니다. (맛보기) 만약 맛이 레시피와 일치하지 않는다면, 요리를 수정하거나 레시피를 업데이트해야 합니다. 결코 불일치를 무시해서는 안 됩니다.
언제 사용하며, 언제 사용하지 않는가 (결정 가이드)
논문은 간단한 결정 가이드를 제공합니다:
- 사용할 때: 거대한 것을 구축할 때, 팀 단위로 작업할 때, AI를 사용할 때, 또는 실수가 비용이 많이 드는 분야(은행업이나 자동차 산업 등)를 구축할 때.
- 사용하지 않을 때: 버릴 목적으로 빠르게 프로토타입을 만들 때, 혹은 요구사항이 명확한 단순한 투두 리스트(to-do list) 앱을 만드는 개인 개발자일 때. 그런 경우에는 상세한 레시피를 쓰는 것이 시간 낭비일 뿐입니다.
핵심 요점
수십 년 동안 소프트웨어 개발자들은 코드를 먼저 작성하고, 레시피(문서)는 나중에 작성하거나 아예 작성하지 않았습니다. 이 논문은 이렇게 말합니다: 순서를 뒤집으십시오.
**명세(Specification)**를 당신이 만드는 가장 일차적인 것으로 만드십시오. 코드는 그 명세의 자동화된 결과물일 뿐이라고 취급하십시오.
이렇게 함으로써, 당신은 추측을 멈추고, AI 도구와 싸우는 것을 멈추며, 당신이 의도한 바로 그 결과물을 구축할 수 있게 됩니다. 코드는 명세의 그림자가 되어야 하며, 그 반대가 되어서는 안 됩니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.