# \#behavior-driven-development **URL:** https://discuss.pytorch.kr/tag/behavior-driven-development/5440.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [GitHub, 스펙 기반 개발(Spec-Driven Development)를 위한 실험적 프레임워크 Spec Kit 공개](https://discuss.pytorch.kr/t/github-spec-driven-development-spec-kit/7675)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 1\ **마지막 업데이트:** [9월 10, 2025, 2:54오전 UTC](https://discuss.pytorch.kr/t/github-spec-driven-development-spec-kit/7675 "2025-09-10T02:54:05Z")
Spec Kit 소개 Spec Kit은 GitHub이 최근 공개한 오픈소스 도구로, 스펙 기반 개발(Spec-Driven Development, 이하 SDD) 을 실천하기 위한 실험적 프레임워크입니다. 전통적인 소프트웨어 개발은 언제나 코드가 중심이었습니다. 요구사항 문서, 설계 문서, 아키텍처 다이어그램 등은 시간이 지나면서 코드와 동기화되지 못해 버려지고, 개발자는 “코드만 보면 된다”는 태도에 익숙해졌습니다. Spec Kit은 이러한 구조를 뒤집는 도구입니다. 코드가 스펙을 따르는 것이 아니라, 스펙이 코드의 원천이 됩니다. 스펙은 단순한 가이드가 아니라 실행 가능한 명세로 다뤄지며, 여기에 기반한 구체적인 구현 계획이 만들어지고, 최종적으로 코드가 생성됩니다. Spec Kit을 활용하면 개발팀은 더 이상 “코드 짜기”라는 반복적이고 차별화되지 않은 작업에 묶이지 않고, 제품 시나리오와 사용자 가치 창출에 집중할 수 있습니다. 특히 빠른 프로토타이핑, 병렬 실험, 기존 시스템의 점진적 현대화 같은 상황에서 강력한 효과를 발휘합니다. Spec Kit 시작하기 Spec Kit은 specify라는 CLI 도구를 중심으로 동작하며, 다음과 같은 사전 요구사항을 만족해야 합니다: Linux/macOS (또는 Windows WSL2) Python 3.11 이상, Git, uv 필요 AI 코딩 에이전트: Claude Code, GitHub Copilot, Gemini CLI 중 선택 Spec Kit의 사용 방법은 다음과 같습니다: 설치: 다음과 같은 명령어로 사용 중인 코딩 에이전트에 따른 프로젝트 초기화를 진행합니다: uvx --from git+https://github.com/github/spec-kit.git specify init \ 스펙 작성: /specify 명령어를 사용하여 구축하고자 하는 내용을 설명합니다. 이 단계에서는 기술 스택에 신경 쓰지 않고, \*\*무엇을 만들고자 하는지(What), 왜 필요… --- ## [\[Deep Research\] GitHub의 Spec Kit으로 알아보는 Spec-Driven Development(SDD)의 개념 및 활용 (feat. Vibe Coding)](https://discuss.pytorch.kr/t/deep-research-github-spec-kit-spec-driven-development-sdd-feat-vibe-coding/7689)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 8, 2025, 9:00오전 UTC](https://discuss.pytorch.kr/t/deep-research-github-spec-kit-spec-driven-development-sdd-feat-vibe-coding/7689 "2025-09-08T09:00:34Z")
개요: 주요 개발 방법론 비교 개요 구분 (Dimension) TDD (Test-Driven Development) BDD (Behavior-Driven Development) SDD (Spec-Driven Development) 핵심 철학 실패하는 테스트를 먼저 작성하고, 이를 통과하는 코드를 구현한 후 리팩토링한다. 이해관계자 모두가 이해할 수 있는 자연어로 시스템의 '행위'를 정의하고 이를 기반으로 개발을 진행한다. 코드가 아닌, 시스템의 '명세(Specification)'를 개발의 중심에 두고, 명세를 통해 코드를 생성하고 검증한다. 주요 관점 개발자 관점 (내부 구현) 사용자/이해관계자 관점 (외부 행위) 시스템/제품 관점 (전체 요구사항 및 아키텍처) 개발 시작점 단위 테스트 코드 (Unit Test Code) 사용자 스토리/시나리오 (User Story/Scenario) 제품 요구사항 명세서 (PRD), 기술 명세서 (Spec) 주요 산출물 단위 테스트 코드, 프로덕션 코드 행위 시나리오 (예: Gherkin feature 파일), 인수 테스트 코드 실행 가능한 명세서 (Executable Spec), 기술 계획서, 작업 목록, 생성된 코드 주요 참여자 개발자 개발자, QA, 기획자, 비즈니스 분석가 제품 관리자, 아키텍트, 개발자, AI 코딩 에이전트 검증 단위 코드 단위 (함수, 클래스) 기능/피처 단위 (Feature Behavior) 시스템 전체 또는 주요 기능의 명세 언어/형식 프로그래밍 언어 (예: JUnit, RSpec) 구조화된 자연어 (예: Gherkin Given-When-Then) 정형화된 문서 (Markdown), API 정의 언어 (OpenAPI), 데이터 스키마 (JSON Schema) 주요 장점 높은 코드 커버리지, 견고한 단위 모듈, 안전한 리팩토링 팀원 간의 명확한 소통, 사용자 요구사항 충족, 살아있는 문서 요구사항과 구현의 불일치 최소화, 개발 프로세스 자동화, 단일 진…