---
type: knowledge
domain: product
role: Backend
status: active
last-reviewed: 2026-07-27
---

# Backend 기획 가이드

> Backend 기획은 요구사항정의서·기능사양서의 요구를 소비 가능한 API 계약과 재현 가능한 성공·실패 동작으로 바꾸는 작업이다.

## 책임과 경계

- 책임: API endpoint, 서버 도메인 로직, 입력 검증, 오류 정책, 외부 서비스 통합
- 입력: 요구사항정의서(SRS)·기능사양서, 기술 경계, Database Result Card, 보안 요구
- 범위 밖: UI 코드, DB 마이그레이션 작성, CI/CD, 자체 암호 알고리즘
- 다음 소비자: Frontend, Database, Security, DevOps, QA(테스트케이스 작성), 발주사 검수자

## 필수 입력

| 입력 항목 | 원천 | 없을 때 처리 |
|---|---|---|
| 요구사항정의서(SRS)·기능사양서 | PM·PO·BA (요구 ID 포함) | 착수 보류, PM에 요청 — 사양 없는 endpoint는 CR로 회부 |
| 기술 경계·NFR 합의값 | Tech Lead·발주사 합의 | 가정으로 표시하고 Tech Lead 검토 항목으로 등록 |
| Database 스키마·쿼리 경로 | Database 역할(ERD·Result Card) | 필요 스키마를 가정으로 명시하고 Database 역할에 검토 요청 |
| 보안 요구·인증 정책 | Security·Privacy, 발주사 보안 정책 | 보호 endpoint 설계를 최소 권한 기본값으로 두고 확인 요청 |
| 외부 연동 스펙 | 발주사·외부 서비스 문서 | 의존성 대장에 등록, timeout·실패 정책만 먼저 확정 |

## 납품 연결 ([[외주 개발 산출물]])

| 이 역할의 결과물 | 납품 산출물 | 마일스톤 |
|---|---|---|
| API 계약([[01_API 계약]]) | **API 정의서(인터페이스 정의서)** — 코드에서 역생성이 가장 정확 | 설계 완료 |
| 도메인 규칙·오류 정책 | 기능사양서(입력·처리·출력·예외·권한)의 근거 | 설계 완료 |
| 서버 코드·커밋 이력 | **소스코드 일체(저장소 이관) + 형상관리·버전 이력** | 개발 완료 |
| 빌드 설정·배포 절차 | **빌드·배포 스크립트** — 재현 가능한 배포가 인수 조건 | 개발 완료 |
| 테스트·검증 기록 | 테스트결과서(계약·실패 경로 PASS/FAIL)·RTM 갱신 | 검수 |

## 기획 순서

1. [[01_API 계약]]에서 URL·method·schema·상태코드를 먼저 확정한다.
2. [[02_도메인·오류 정책]]에서 규칙, 경계 검증, 실패 동작을 정한다.
3. [[03_DB·외부연동 의존성]]에서 쿼리와 외부 호출의 한계를 정한다.
4. [[04_관측·테스트 계획]]에서 로그·메트릭과 재현 시나리오를 연결한다.
5. [[90_Backend 완료 체크리스트]]로 구현과 계약을 검증한다.
6. [[99_Backend Result Card 템플릿]]으로 다음 역할에 인계한다.

## 파일 지도

| 파일 | 용도 | 주 소비자 |
|---|---|---|
| 현재 문서 | 역할 책임·입력·기획 순서 | Backend |
| [[01_API 계약]] | URL·method·schema·상태코드 — 납품 API 정의서 원본 | Frontend, Tech Lead, QA |
| [[02_도메인·오류 정책]] | 규칙·경계 검증·실패 동작 | Backend 구현자, 리뷰어 |
| [[03_DB·외부연동 의존성]] | 쿼리 패턴과 외부 호출의 한계 | Database, DevOps |
| [[04_관측·테스트 계획]] | 로그·메트릭과 재현 시나리오 | QA, Release·운영 |
| [[90_Backend 완료 체크리스트]] | 구현·계약 자체 검증 | Reviewer, QA |
| [[99_Backend Result Card 템플릿]] | 의존성·제약 인계 카드 | Frontend, Database, QA |

## 핵심 결정 원칙

- API 계약을 구현보다 먼저 정의하고 Frontend가 그대로 참조하게 한다 — 이 계약이 곧 납품 API 정의서의 원본이다.
- 입력은 시스템 경계에서 schema로 검증한다.
- 도메인 로직과 HTTP transport를 분리한다.
- 외부 호출에는 timeout·재시도·중복 실행 정책이 있어야 한다.
- 상태 변경은 transaction과 idempotency를 함께 검토한다.
- 오류를 삼키지 않으며 내부 정보와 사용자 존재 여부를 노출하지 않는다.
- 기능사양서에 없는 endpoint·기능 요청(타 시스템 연동 추가 등)은 임의 구현하지 않고 **CR(변경요청)로 회부**한다 ([[SI 수주와 범위 관리]]).

## 진입 게이트

- [ ] 요구사항정의서·기능사양서에서 대상 요구 ID가 확정됐다.
- [ ] API 계약을 먼저 쓸 수 있는 입력(도메인 규칙·데이터 요구)이 있다.
- [ ] Database 스키마 방향이 확정됐거나 가정이 Database 역할과 공유됐다.
- [ ] 보호 endpoint에 적용할 인증·인가 등 보안 요구가 식별됐다.

## 완료된 기획의 조건

- 정상·권한·검증·충돌·외부 장애·timeout 경로가 재현 가능하다 — 검수 시나리오로 그대로 쓸 수 있는 형태.
- DB 쿼리 패턴과 필요한 migration이 Database 역할에 명시된다.
- 모든 결정에 Owner, 근거, 영향, 미결 사항이 있다.
- 로그와 지표가 민감정보 없이 장애 원인을 식별하게 한다 — 하자보수 기간 원인 규명의 근거.
- 종료 게이트: 다음 역할이 착수 가능한 동시에, 산출물이 **검수·계약 근거로 쓸 수 있는가**를 통과한다.

## 함께 읽기

- [[00_역할별 기획 허브]]
- [[00_역할별 기획 운영 가이드]]
- [[역할별 개발 산출물]]
- [[외주 개발 산출물]]
- [[SI 수주와 범위 관리]]
- [[01_백엔드 설계]] — 설계 판단 기준(03_설계 역할별)