개념
이 가이드는 OpenSpec의 핵심 개념과 이 개념들이 어떻게 연관되어 있는지 설명합니다. 실제 사용 방법은 시작하기와 워크플로우를 참고하세요.
철학
OpenSpec은 네 가지 원칙을 기반으로 구축되었습니다:
fluid not rigid — 단계별 검토 게이트가 없으며, 의미 있는 작업에 집중
iterative not waterfall — 구축하면서 배우고, 진행하면서 개선
easy not complex — 가벼운 초기 설정, 최소한의 절차
brownfield-first — 기존 코드베이스와 호환되며, 단순히 그린필드 환경만 지원하는 것이 아님이 원칙들이 중요한 이유
Fluid not rigid. 기존 명세 시스템은 작업을 단계별로 고정시킵니다: 먼저 계획을 수립한 후 구현하고, 완료되면 끝이죠. OpenSpec은 훨씬 유연합니다 — 작업에 맞춰 아티팩트를 원하는 순서대로 생성할 수 있습니다.
Iterative not waterfall. 요구사항은 변합니다. 이해도 깊어집니다. 초기에 좋았던 접근 방식이 코드베이스를 확인한 후에는 맞지 않을 수 있습니다. OpenSpec은 이러한 현실을 받아들입니다.
Easy not complex. 일부 명세 프레임워크는 광범위한 설정, 엄격한 형식, 무거운 프로세스를 요구합니다. OpenSpec은 방해하지 않습니다. 몇 초 만에 초기화하고 바로 작업을 시작할 수 있으며, 필요할 때만 사용자 정의할 수 있습니다.
Brownfield-first. 대부분의 소프트웨어 작업은 처음부터 새로 구축하는 것이 아니라 기존 시스템을 수정하는 것입니다. OpenSpec의 델타 기반 접근 방식은 새 시스템을 설명하는 것뿐만 아니라 기존 동작에 대한 변경 사항을 명세하기 쉽게 해줍니다.
전체 개요
OpenSpec는 작업을 두 가지 주요 영역으로 구성합니다:
┌────────────────────────────────────────────────────────────────────┐
│ openspec/ │
│ │
│ ┌─────────────────────┐ ┌───────────────────────────────┐ │
│ │ specs/ │ │ changes/ │ │
│ │ │ │ │ │
│ │ 신뢰할 수 있는 출처 │◄─────│ 제안된 수정사항 │ │
│ │ 시스템이 현재 │ 병합 │ 각 변경사항 = 하나의 폴더 │ │
│ │ 어떻게 작동하는지 │ │ 산출물 + 델타 포함 │ │
│ │ │ │ │ │
│ └─────────────────────┘ └───────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘Specs(명세)는 신뢰할 수 있는 출처로, 시스템이 현재 어떻게 작동하는지 설명합니다.
Changes(변경사항)은 제안된 수정사항으로, 병합할 준비가 될 때까지 별도의 폴더에 보관됩니다.
이 분리가 핵심입니다. 여러 변경사항을 충돌 없이 병렬로 작업할 수 있습니다. 주요 명세에 영향을 미치기 전에 변경사항을 검토할 수 있습니다. 그리고 변경사항을 아카이브하면 델타가 신뢰할 수 있는 출처에 깔끔하게 병합됩니다.
명세(Specs)
명세는 구조화된 요구사항과 시나리오를 사용하여 시스템의 동작을 설명합니다.
구조
openspec/specs/
├── auth/
│ └── spec.md # 인증 동작
├── payments/
│ └── spec.md # 결제 처리
├── notifications/
│ └── spec.md # 알림 시스템
└── ui/
└── spec.md # UI 동작 및 테마도메인별로 명세를 구성하세요. 시스템에 맞는 논리적 그룹핑입니다. 일반적인 패턴:
- 기능 영역별:
auth/,payments/,search/ - 컴포넌트별:
api/,frontend/,workers/ - 경계 컨텍스트별:
ordering/,fulfillment/,inventory/
명세 형식
명세에는 요구사항이 포함되며, 각 요구사항마다 시나리오가 있습니다:
markdown
# 인증 명세
## 목적
애플리케이션의 인증 및 세션 관리입니다.
## 요구사항
### 요구사항: 사용자 인증
시스템은 로그인 성공 시 JWT 토큰을 발급해야 한다(SHALL).
#### 시나리오: 유효한 자격 증명
- GIVEN 유효한 자격 증명을 가진 사용자
- WHEN 사용자가 로그인 폼을 제출하면
- THEN JWT 토큰이 반환된다
- AND 사용자가 대시보드로 리디렉션된다
#### 시나리오: 유효하지 않은 자격 증명
- GIVEN 유효하지 않은 자격 증명
- WHEN 사용자가 로그인 폼을 제출하면
- THEN 오류 메시지가 표시된다
- AND 토큰이 발급되지 않는다
### 요구사항: 세션 만료
시스템은 30분 동안 활동이 없으면 세션을 만료시켜야 한다(MUST).
#### 시나리오: 유휴 타임아웃
- GIVEN 인증된 세션
- WHEN 30분 동안 활동이 없으면
- THEN 세션이 무효화된다
- AND 사용자는 재인증해야 한다핵심 요소:
| 요소 | 목적 |
|---|---|
## 목적 | 이 명세의 도메인에 대한 고수준 설명 |
### 요구사항: | 시스템이 가져야 할 특정 동작 |
#### 시나리오: | 요구사항이 실제로 작동하는 구체적인 예시 |
| SHALL/MUST/SHOULD | 요구사항의 강도를 나타내는 RFC 2119 키워드 |
명세를 이런 방식으로 구성하는 이유
요구사항은 "무엇(what)"에 해당합니다 — 구현 방법을 명시하지 않고 시스템이 해야 할 일을 설명합니다.
시나리오는 "언제(when)"에 해당합니다 — 검증할 수 있는 구체적인 예시를 제공합니다. 좋은 시나리오의 특징:
- 테스트 가능합니다(자동화 테스트를 작성할 수 있습니다)
- 정상 경로와 엣지 케이스를 모두 다룹니다
- Given/When/Then 또는 유사한 구조화된 형식을 사용합니다
RFC 2119 키워드(SHALL, MUST, SHOULD, MAY)는 의도를 전달합니다:
- MUST/SHALL — 절대적 요구사항
- SHOULD — 권장되지만 예외가 있을 수 있음
- MAY — 선택 사항
명세의 정의(그리고 정의되지 않는 것)
명세는 동작 계약이며, 구현 계획이 아닙니다.
명세에 포함할 좋은 내용:
- 사용자나 다운스트림 시스템이 의존하는 관찰 가능한 동작
- 입력, 출력, 오류 조건
- 외부 제약 조건(보안, 개인정보 보호, 안정성, 호환성)
- 테스트하거나 명시적으로 검증할 수 있는 시나리오
명세에서 피해야 할 내용:
- 내부 클래스/함수 이름
- 라이브러리나 프레임워크 선택
- 단계별 구현 세부 사항
- 상세 실행 계획(이러한 내용은
design.md나tasks.md에 포함됩니다)
빠른 확인 방법:
- 구현 방법을 변경해도 외부에 보이는 동작이 변하지 않는다면, 해당 내용은 명세에 포함하지 않는 것이 좋습니다.
가볍게 유지하기: 점진적 엄격성
OpenSpec는 관료주의를 피하는 것을 목표로 합니다. 변경사항을 검증할 수 있는 가장 가벼운 수준을 사용하세요.
라이트 명세(기본값):
- 동작 우선의 짧은 요구사항
- 명확한 범위와 비목표
- 몇 가지 구체적인 수용 기준 검사
전체 명세(위험이 높은 경우):
- 팀 간 또는 리포지토리 간 변경사항
- API/계약 변경, 마이그레이션, 보안/개인정보 보호 관련 문제
- 모호함으로 인해 비용이 많이 드는 재작업이 발생할 수 있는 변경사항
대부분의 변경사항은 라이트 모드로 유지해야 합니다.
인간과 에이전트의 협업
많은 팀에서 인간이 탐색하고 에이전트가 산출물 초안을 작성합니다. 의도된 루프는 다음과 같습니다:
- 인간이 의도, 컨텍스트, 제약 조건을 제공합니다.
- 에이전트가 이를 동작 우선의 요구사항과 시나리오로 변환합니다.
- 에이전트는 구현 세부 사항을
spec.md가 아닌design.md와tasks.md에 유지합니다. - 구현 전에 검증이 구조와 명확성을 확인합니다.
이렇게 하면 명세가 인간이 읽기 쉽고 에이전트에게 일관성이 유지됩니다.
변경사항(Changes)
변경사항은 시스템에 대한 제안된 수정사항으로, 이해하고 구현하는 데 필요한 모든 것을 포함한 폴더로 패키징됩니다.
변경사항 구조
openspec/changes/add-dark-mode/
├── proposal.md # 이유와 내용
├── design.md # 방법(기술적 접근 방식)
├── tasks.md # 구현 체크리스트
├── .openspec.yaml # 변경사항 메타데이터(선택 사항): 스키마, 생성일, spec_skip
└── specs/ # 델타 명세
└── ui/
└── spec.md # ui/spec.md에서 변경되는 내용각 변경사항은 자체 포함되어 있습니다. 다음을 포함합니다:
- 산출물(Artifacts) — 의도, 설계, 작업을 포착하는 문서
- 델타 명세(Delta specs) — 추가, 수정, 삭제되는 내용에 대한 명세
- 메타데이터(Metadata) — 이 특정 변경사항에 대한 선택적 구성
변경사항을 폴더로 구성하는 이유
변경사항을 폴더로 패키징하면 여러 이점이 있습니다:
모든 것이 한 곳에 있습니다. 제안서, 설계, 작업, 명세가 한 장소에 있습니다. 여러 위치를 뒤질 필요가 없습니다.
병렬 작업. 여러 변경사항이 충돌 없이 동시에 존재할 수 있습니다.
fix-auth-bug가 진행되는 동안add-dark-mode작업을 할 수 있습니다.깔끔한 기록. 아카이브되면 변경사항이 전체 컨텍스트를 유지한 채
changes/archive/로 이동합니다. 단순히 무엇이 변경되었는지 뿐만 아니라 왜 변경되었는지도 이해할 수 있습니다.검토하기 편리합니다. 변경 폴더는 검토하기 쉽습니다 — 폴더를 열어 제안서를 읽고, 설계를 확인하고, 명세 델타를 확인하세요.
산출물(Artifacts)
산출물은 작업을 안내하는 변경사항 내의 문서입니다.
산출물 흐름
proposal ──────► specs ──────► design ──────► tasks ──────► implement
│ │ │ │
이유 변경 내용 접근 방식 수행할
+ 범위 내용 아키텍처 단계산출물은 서로를 기반으로 구축됩니다. 각 산출물은 다음 산출물에 컨텍스트를 제공합니다.
산출물 유형
제안서(proposal.md)
제안서는 고수준에서 의도, 범위, 접근 방식을 포착합니다.
markdown
# 제안서: 다크 모드 추가
## 의도
사용자가 야간 사용 시 눈의 피로를 줄이고 시스템 기본 설정과 일치시키기 위해 다크 모드 옵션을 요청했습니다.
## 범위
포함 범위:
- 설정의 테마 전환 토글
- 시스템 기본 설정 감지
- localStorage에 기본 설정 저장
제외 범위:
- 사용자 정의 색상 테마(향후 작업)
- 페이지별 테마 재정의
## 접근 방식
React Context를 사용하여 테마 상태를 관리하고 CSS 사용자 정의 속성을 사용하여 테마를 적용합니다. 첫 로드 시 시스템 기본 설정을 감지하고 수동 재정의를 허용합니다.제안서를 업데이트해야 하는 경우:
- 범위가 변경되는 경우(축소 또는 확장)
- 의도가 명확해지는 경우(문제를 더 잘 이해하게 됨)
- 접근 방식이 근본적으로 변경되는 경우
명세(specs/ 내의 델타 명세)
델타 명세는 현재 명세와 비교하여 변경되는 내용을 설명합니다. 아래의 델타 명세를 참조하세요.
설계(design.md)
설계는 기술적 접근 방식과 아키텍처 결정을 포착합니다.
markdown
# 설계: 다크 모드 추가
## 기술적 접근 방식
테마 상태는 React Context를 통해 관리하여 prop drilling을 방지합니다. CSS 사용자 정의 속성을 사용하면 클래스 토글링 없이 런타임에 전환할 수 있습니다.
## 아키텍처 결정
### 결정: Redux 대신 Context 사용
다음과 같은 이유로 테마 상태에 React Context를 사용합니다:
- 단순한 이진 상태(라이트/다크)
- 복잡한 상태 전환이 없음
- Redux 의존성 추가 방지
### 결정: CSS 사용자 정의 속성 사용
다음과 같은 이유로 CSS-in-JS 대신 CSS 변수를 사용합니다:
- 기존 스타일시트와 함께 작동
- 런타임 오버헤드 없음
- 브라우저 기본 제공 솔루션
## 데이터 흐름
```
ThemeProvider (컨텍스트)
│
▼
ThemeToggle ◄──► localStorage
│
▼
CSS 변수 (:root에 적용됨)
```
## 파일 변경 사항
- `src/contexts/ThemeContext.tsx` (신규)
- `src/components/ThemeToggle.tsx` (신규)
- `src/styles/globals.css` (수정)설계를 업데이트해야 하는 경우:
- 구현 과정에서 접근 방식이 작동하지 않는다는 것이 드러나는 경우
- 더 나은 솔루션이 발견되는 경우
- 의존성이나 제약 조건이 변경되는 경우
작업(tasks.md)
작업은 구현 체크리스트로, 체크박스가 있는 구체적인 단계입니다.
markdown
# 작업
## 1. 테마 인프라
- [ ] 1.1 라이트/다크 상태를 가진 ThemeContext 생성
- [ ] 1.2 색상에 대한 CSS 사용자 정의 속성 추가
- [ ] 1.3 localStorage 영속성 구현
- [ ] 1.4 시스템 기본 설정 감지 추가
## 2. UI 컴포넌트
- [ ] 2.1 ThemeToggle 컴포넌트 생성
- [ ] 2.2 설정 페이지에 토글 추가
- [ ] 2.3 빠른 토글을 포함하도록 Header 업데이트
## 3. 스타일링
- [ ] 3.1 다크 테마 색상 팔레트 정의
- [ ] 3.2 컴포넌트를 CSS 변수를 사용하도록 업데이트
- [ ] 3.3 접근성을 위한 대비율 테스트작업 모범 사례:
- 관련 작업을 제목 아래에 그룹화하세요
- 계층적 번호 매기기를 사용하세요(1.1, 1.2 등)
- 작업이 한 번의 세션에서 완료할 수 있을 만큼 작게 유지하세요
- 작업을 완료할 때마다 체크하세요
델타 명세(Delta Specs)
델타 명세는 기존 시스템에 대한 개발(brownfield development)에서 OpenSpec가 작동하게 하는 핵심 개념입니다. 전체 명세를 다시 기술하는 대신 변경되는 내용을 설명합니다.
형식
markdown
# 인증 델타
## 추가된 요구사항
### 요구사항: 2단계 인증
시스템은 TOTP 기반 2단계 인증을 지원해야 한다(MUST).
#### 시나리오: 2FA 등록
- GIVEN 2FA가 활성화되지 않은 사용자
- WHEN 사용자가 설정에서 2FA를 활성화하면
- THEN 인증자 앱 설정을 위한 QR 코드가 표시된다
- AND 활성화 전에 코드로 확인해야 한다
#### 시나리오: 2FA 로그인
- GIVEN 2FA가 활성화된 사용자
- WHEN 사용자가 유효한 자격 증명을 제출하면
- THEN OTP 챌린지가 제시된다
- AND 유효한 OTP 후에만 로그인이 완료된다
## 수정된 요구사항
### 요구사항: 세션 만료
시스템은 15분 동안 활동이 없으면 세션을 만료시켜야 한다(MUST).
(기존: 30분)
#### 시나리오: 유휴 타임아웃
- GIVEN 인증된 세션
- WHEN 15분 동안 활동이 없으면
- THEN 세션이 무효화된다
## 삭제된 요구사항
### 요구사항: 로그인 상태 유지
(2FA로 대체되어 더 이상 사용되지 않습니다. 사용자는 매 세션마다 재인증해야 합니다.)델타 섹션
| 섹션 | 의미 | 아카이브 시 발생하는 일 |
|---|---|---|
## ADDED Requirements | 새로운 동작 | 주요 명세에 추가됨 |
## MODIFIED Requirements | 변경된 동작 | 기존 요구사항을 대체함 |
## REMOVED Requirements | 폐기된 동작 | 주요 명세에서 삭제됨 |
전체 명세 대신 델타를 사용하는 이유
명확성. 델타는 정확히 무엇이 변경되는지 보여줍니다. 전체 명세를 읽으면 현재 버전과 mentally 비교해야 하지만, 델타는 변경 내용만 명확히 보여줍니다.
충돌 방지. 두 변경사항이 서로 다른 요구사항을 수정하는 한, 동일한 명세 파일을 수정해도 충돌이 발생하지 않습니다.
검토 효율성. 검토자는 변경된 내용만 보고, 변경되지 않은 컨텍스트는 보지 않습니다. 중요한 내용에 집중할 수 있습니다.
기존 시스템 개발에 적합. 대부분의 작업이 기존 동작을 수정합니다. 델타는 수정사항을 핵심 개념으로 다루며, 사후 고려 사항이 아닙니다.
스키마
스키마는 워크플로우에 사용될 아티팩트 유형과 해당 의존성을 정의합니다.
스키마의 작동 원리
yaml
# openspec/schemas/spec-driven/schema.yaml
name: spec-driven
artifacts:
- id: proposal
generates: proposal.md
requires: [] # 의존성이 없으므로 먼저 생성할 수 있습니다
- id: specs
generates: specs/**/*.md
requires: [proposal] # 생성 전에 제안서가 필요합니다
- id: design
generates: design.md
requires: [proposal] # 명세와 병렬로 생성할 수 있습니다
- id: tasks
generates: tasks.md
requires: [specs, design] # 생성 전에 명세와 디자인이 모두 필요합니다아티팩트는 의존성 그래프를 형성합니다:
proposal
(루트 노드)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(의존성: (의존성:
제안서) 제안서)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(의존성:
명세, 디자인)의존성은 가능하게 하는 요인일 뿐, 장벽이 아닙니다. 의존성은 다음에 반드시 생성해야 하는 것이 아니라 생성할 수 있는 것을 보여줍니다. 필요하지 않다면 디자인을 건너뛸 수 있습니다. 명세를 디자인 전이나 후에 생성할 수 있으며, 둘 다 제안서에만 의존합니다.
기본 제공 스키마
spec-driven (기본값)
스펙 주도 개발의 표준 워크플로우입니다:
proposal → specs → design → tasks → implement적합한 경우: 구현 전에 명세에 합의하려는 대부분의 기능 작업에 적합합니다.
커스텀 스키마
팀의 워크플로우에 맞는 커스텀 스키마를 생성할 수 있습니다:
bash
# 처음부터 생성
openspec schema init research-first
# 또는 기존 스키마 포크
openspec schema fork spec-driven research-first커스텀 스키마 예시:
yaml
# openspec/schemas/research-first/schema.yaml
name: research-first
artifacts:
- id: research
generates: research.md
requires: [] # 먼저 리서치를 수행합니다
- id: proposal
generates: proposal.md
requires: [research] # 리서치를 기반으로 제안서 작성
- id: tasks
generates: tasks.md
requires: [proposal] # 명세/디자인을 건너뛰고 직접 태스크로 이동커스텀 스키마 생성 및 사용에 대한 자세한 내용은 커스터마이제이션을 참조하세요.
아카이브
아카이빙은 변경 사항의 델타 명세를 메인 명세에 병합하고 변경 사항을 기록으로 보존하여 변경을 완료합니다.
아카이빙 시 발생하는 작업
아카이빙 전:
openspec/
├── specs/
│ └── auth/
│ └── spec.md ◄────────────────┐
└── changes/ │
└── add-2fa/ │
├── proposal.md │ 병합
├── design.md │
├── tasks.md │
└── specs/ │
└── auth/ │
└── spec.md ─────────┘
아카이빙 후:
openspec/
├── specs/
│ └── auth/
│ └── spec.md # 이제 2FA 요구사항이 포함됨
└── changes/
└── archive/
└── 2025-01-24-add-2fa/ # 기록으로 보존됨
├── proposal.md
├── design.md
├── tasks.md
└── specs/
└── auth/
└── spec.md아카이빙 프로세스
- 델타 병합. 각 델타 명세 섹션(ADDED/MODIFIED/REMOVED)이 해당 메인 명세에 적용됩니다.
- 아카이브로 이동. 변경 폴더는 시간 순 정렬을 위해 날짜 접두사와 함께
changes/archive/로 이동합니다. - 컨텍스트 보존. 모든 아티팩트가 아카이브에 그대로 보존됩니다. 나중에 변경 사유를 확인하기 위해 언제든지 돌아볼 수 있습니다.
아카이빙이 중요한 이유
깔끔한 상태. 활성 변경(changes/)에는 진행 중인 작업만 표시됩니다. 완료된 작업은 별도로 보관됩니다.
감사 추적. 아카이브는 모든 변경의 전체 컨텍스트를 보존합니다. 변경된 내용뿐 아니라 변경 이유를 설명하는 제안서, 구현 방법을 설명하는 디자인, 수행한 작업을 보여주는 태스크까지 모두 보존됩니다.
명세 진화. 변경이 아카이빙됨에 따라 명세가 자연스럽게 성장합니다. 각 아카이빙마다 델타가 병합되어 시간이 지남에 따라 포괄적인 명세가 구축됩니다.
전체 흐름
┌──────────────────────────────────────────────────────────────────────────────┐
│ OPENSPEC 흐름 │
│ │
│ ┌────────────────┐ │
│ │ 1. 변경 시작 │ /opsx:propose (코어) 또는 /opsx:new (확장) │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 2. 아티팩트 │ /opsx:ff 또는 /opsx:continue (확장 워크플로우) │
│ │ 생성 │ 제안서 → 명세 → 디자인 → 태스크 생성 │
│ │ │ (스키마 의존성 기반) │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 3. 태스크 │ /opsx:apply │
│ │ 구현 │ 태스크를 진행하며 완료 처리 │
│ │ │◄──── 학습에 따라 아티팩트 업데이트 │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 4. 작업 │ /opsx:verify (선택 사항) │
│ │ 검증 │ 구현이 명세와 일치하는지 확인 │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ ┌──────────────────────────────────────────────┐ │
│ │ 5. 변경 │────►│ 델타 명세가 메인 명세에 병합됨 │ │
│ │ 아카이빙 │ │ 변경 폴더가 archive/로 이동함 │ │
│ └────────────────┘ │ 명세가 이제 업데이트된 진실의 원천이 됨 │ │
│ └──────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────────┘선순환 구조:
- 명세가 현재 동작을 설명함
- 변경 사항이 수정안을 제안함(델타로)
- 구현이 변경 사항을 실제로 적용함
- 아카이빙이 델타를 명세에 병합함
- 명세가 이제 새로운 동작을 설명함
- 다음 변경이 업데이트된 명세를 기반으로 구축됨
용어 사전
| 용어 | 정의 |
|---|---|
| 아티팩트 | 변경 내의 문서(제안서, 디자인, 태스크 또는 델타 명세) |
| 아카이브 | 변경을 완료하고 해당 델타를 메인 명세에 병합하는 프로세스 |
| 변경 | 시스템에 대한 제안된 수정으로, 아티팩트가 포함된 폴더로 패키징됨 |
| 델타 명세 | 현재 명세와 비교하여 변경 사항(ADDED/MODIFIED/REMOVED)을 설명하는 명세 |
| 도메인 | 명세의 논리적 그룹화(예: auth/, payments/) |
| 요구사항 | 시스템이 가져야 하는 특정 동작 |
| 시나리오 | 요구사항의 구체적인 예시로, 일반적으로 Given/When/Then 형식으로 작성됨 |
| 스키마 | 아티팩트 유형과 해당 의존성에 대한 정의 |
| 명세 | 시스템 동작을 설명하는 명세로, 요구사항과 시나리오가 포함됨 |
| 진실의 원천 | 현재 합의된 동작이 포함된 openspec/specs/ 디렉토리 |
다음 단계
- Getting Started - 첫 단계를 위한 실용적인 가이드
- Workflows - 일반적인 패턴과 각 워크플로우의 사용 시점
- Commands - 전체 명령어 참조
- Customization - 커스텀 스키마 생성 및 프로젝트 구성