メニュー
BE TechSpec 문서 작성 템플릿과 패턴. 백엔드 프로젝트의 기술 명세서를 작성할 때 참조. Use when: BE TechSpec 작성, API 설계 문서 생성, Given/When/Then 테스트 케이스 정의, DB 스키마 설계, 서비스 아키텍처 설계 문서 작성 시 사용.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | be-techspec |
| description | BE TechSpec 문서 작성 템플릿과 패턴. 백엔드 프로젝트의 기술 명세서를 작성할 때 참조. Use when: BE TechSpec 작성, API 설계 문서 생성, Given/When/Then 테스트 케이스 정의, DB 스키마 설계, 서비스 아키텍처 설계 문서 작성 시 사용. |
관련 스킬: entity-object-pattern - 구현 시 반복되는 도메인 로직을 Entity Object로 그룹화하는 패턴
대응 스킬: fe-techspec - 프론트엔드 TechSpec (동일 구조, FE 관점)
BE TechSpec은 프로젝트의 백엔드 기술 구현 방향을 정의하는 문서. PRD(요구사항)와 API Spec을 기반으로 Solution, Acceptance Criteria, Test Cases를 도출한다.
Summary → Solution → Acceptance Criteria → Non-Functional Requirements → Functional Requirements (Given/When/Then) → Design → Component & Code - Server → Verification
전체 템플릿은 references/template.md 참조.
프로젝트 배경과 맥락. PRD/API Spec 링크 포함.
## Summary
{프로젝트 배경 1-3문장}
- **PRD**: {Notion URL}
- **API Spec**: {Swagger/OpenAPI URL} (있으면)
비즈니스 관점에서 핵심 변경사항을 요약. 기술 용어 없이 "무엇이 어떻게 바뀌는가"에 집중.
## Solution
### 핵심 변경사항
1. **{변경1}**: {설명}
2. **{변경2}**: {설명}
3. **{변경3}**: {설명}
작성 규칙:
기능 동작의 최소 기준. 테스트 가능한 형태로 작성.
## Acceptance Criteria
1. {주어} 상태에서 {동작}하면 {결과}가 발생한다
2. ...
SLA/SLO 기준의 시스템 요구사항.
카테고리:
해당 프로젝트에 관련 없는 카테고리는 생략 가능.
테스트 케이스를 구조화된 테이블로 정의.
## Functional Requirements (Test cases / Given, When, Then)
| # | Given | When | Then |
|---|-------|------|------|
| 1 | {초기 상태/조건} | {API 호출/이벤트} | {기대 결과} |
| 2 | ... | ... | ... |
작성 팁:
테스트 케이스 기반으로 백엔드 설계를 진행.
작성 순서:
데이터 모델 가이드:
테스트 케이스 검증 전략.
우선순위:
| 문제 | 원인 | 해결 |
|---|---|---|
| AC가 모호함 | "빠르게", "잘" 같은 추상적 표현 | 측정 가능한 기준 사용 (예: "p95 < 200ms") |
| Given/When/Then 불명확 | 상태/호출/결과 구분 없음 | Given=DB 상태, When=API 호출, Then=응답+상태 변경 |
| Test Case 누락 | 정상 케이스만 작성 | 에러/엣지 케이스 반드시 포함 |
| NFR 생략 | 선택사항이라 무시 | 공개 API면 Performance/Security 필수 검토 |
| Solution에 코드 포함 | "기술적 해결책"으로 오해 | 비기술 요약으로 작성 |
| 스키마 과잉 설계 | 미래 요구사항 예측 | YAGNI. 현재 TC에서 필요한 컬럼만 |
| 인덱스 누락 | 쿼리 패턴 미분석 | FR의 When/Then에서 조회 패턴 도출 → 인덱스 결정 |
| Controller에 비즈니스 로직 | 레이어 책임 혼재 | Presentation(검증/라우팅)과 Application UseCase(조율) 분리 |
| Infrastructure → Domain 의존 | Dependency Rule 위반 | Domain은 순수 비즈니스 규칙만. DB/프레임워크 타입 import 금지 |
| Optimization Checklist 전부 채움 | RADIO 원칙 오해 | TC/NFR에서 도출된 항목만. "해당없음"이 대부분이어도 정상 |
| Verification 누락 | 선택사항으로 오인 | Integration Test 필수 |
Library/API 설계 판단 기준. `/design` command의 D step에서 기술 라이브러리를 설계할 때 참조.
DDD 도메인 모델링 판단 기준. `/design` command의 D step에서 도메인 복잡도가 높을 때 참조.
RADIO 기반 FE/BE 설계 체크리스트. `/design` command가 각 Step에서 참조하는 판단 기준과 질문 목록.
Entity Object(companion object) 패턴. Entity interface와 같은 이름의 const 객체에 도메인 로직 함수를 그룹화. Use when: TDD Refactor 단계에서 반복되는 도메인 로직을 정리할 때, Entity 구현 시 도메인 로직 코드화, UI/API/테스트에서 동일 로직 재사용이 필요할 때.
FE TechSpec 문서 작성 템플릿과 패턴. Linear 프로젝트의 기술 명세서를 작성할 때 참조. Use when: TechSpec 작성, 기술 명세서 생성, Given/When/Then 테스트 케이스 정의, Acceptance Criteria 작성, Solution 설계 문서 작성 시 사용.
Seed Design React 컴포넌트 라이브러리 참고 문서. Use when: @seed-design/react 컴포넌트 사용, UI 컴포넌트 구현, seed-design 컴포넌트의 props/API 확인이 필요할 때.