---
type: knowledge
domain: architecture
status: active
last-reviewed: 2026-07-27
---

# 역할별 설계 지도

> 한 줄 정의
> 외주·SI 프로젝트에서 **누가 무엇을 설계하고, 그 결과가 어떤 납품 산출물이 되는가**의 전 역할 조망. 각 역할의 "무엇을 어떤 기준으로 결정하나"는 01~06 문서, "무엇을 채워 납품하나"는 [[00_역할별 기획 허브|02_기획/05_역할별]] 템플릿이 정본.

## 역할 × 설계 대상 × 납품 산출물

| 역할 문서 | 설계 대상 | 납품 산출물 ([[외주 개발 산출물]]) |
|---|---|---|
| [[01_백엔드 설계]] | API·도메인 계층·트랜잭션·외부 연동 | API정의서, 기능사양서 |
| [[02_데이터·DB 설계]] | 스키마·키·인덱스·마이그레이션·이관 | ERD·테이블정의서·코드정의서·데이터 이관 계획서 |
| [[03_프론트엔드 설계]] | 화면 구조·라우팅·상태·컴포넌트 경계 | 화면정의서(구현 측), 소스·빌드 이관 |
| [[04_인프라 설계]] | 배포 구조·환경 분리·IaC·백업·모니터링 | 시스템구성도, 설치·운영 매뉴얼 |
| [[05_보안 설계]] | 인증·인가·데이터 보호·감사 로그 | 보안 아키텍처 문서, 보안성 검토 답변서 |
| [[06_AI·에이전트 설계]] | LLM 파이프라인·에이전트 구조·평가 게이트 | AI 처리 흐름도, 평가 리포트, 데이터 명세 |

시스템 전체 경계·구성은 Tech Lead 소관 — Tech Lead의 판단 기준은 별도 역할 문서가 아니라 01_원리([[설계 결정과 리뷰]]·[[아키텍처 스타일 선택]])와 [[도메인 경계 설계]]가 담당하고, 납품 템플릿은 [[01_시스템 경계·구성도]](02_기획)가 정본이다.

## 역할 간 설계 경계 규칙 — Owner 하나, 합의는 명시

경계에 걸친 계약은 **Owner가 초안을 내고, 소비자가 합의 서명**한다. 둘 다 소유하면 아무도 소유하지 않은 것이다.

| 계약 항목 | Owner | 합의(Consulted) | 규칙 |
|---|---|---|---|
| API 계약(요청·응답·에러) | 백엔드 | 프론트엔드, QA | 프론트는 소비만, 계약 변경은 백엔드 경유 |
| DB 스키마·코드정의 | 데이터·DB | 백엔드 | 백엔드가 스키마를 임의 변경하지 않는다 |
| 화면 구조·상태 명세 | 프론트엔드 | UX 디자인, 백엔드 | 화면이 요구하는 데이터는 API 계약으로 역제안 |
| 배포 구조·환경 | 인프라 | 전 역할, 발주사 운영 | 발주사 환경 제약이 고정 입력 |
| 인증·인가 모델 | 보안 | 백엔드, 프론트엔드 | 구현은 각 역할, 모델·정책은 보안이 판정 |
| AI 평가 기준·HITL 지점 | AI | QA, 발주사 현업 | 정확도 기준 = 검수 기준으로 착수 전 합의 |

## 설계 순서 — 경계 → 계약 → 내부

1. **경계**: 시스템·도메인·신뢰 경계와 발주사 시스템 연동 지점을 먼저 고정한다 ([[도메인 경계 설계]]).
2. **계약**: 경계를 건너는 것(API·스키마·이벤트·인증)을 문서 계약으로 확정한다 — 병렬 작업의 전제.
3. **내부**: 계약이 잠긴 뒤 각 역할이 내부 구조를 독립 설계한다. 내부 변경은 계약을 깨지 않는 한 자유.

역순으로 가면(내부부터) 계약이 구현의 부산물이 되어 소비자가 매번 깨진다.

## 충돌 시 조정 절차

1. 계약 문서 기준으로 판정 — 문서에 있으면 문서가 이긴다 (단계별 정본 계층 — 설계 정본 vs 구현 원본 vs 역생성 납품본 — 은 각 역할 문서의 선언을 따른다).
2. 문서에 없는 신규 지점이면 Owner가 대안·영향(일정·비용)을 정리해 Tech Lead가 조정한다.
3. one-way door(스키마 파괴 변경·인증 모델 교체 등)는 [[설계 결정과 리뷰]]의 ADR로 기록 후 결정한다.
4. 계약 범위를 넘는 요구(발주사 신규 요청 포함)는 현장 수락 금지 — **CR 회부** ([[SI 수주와 범위 관리]]).

## 외주 공통 원칙 (01~06 전 문서 공통)

- 검수 기준은 **착수 전 합의만 유효** — 설계 결정마다 "이게 검수에서 어떻게 판정되나"를 붙인다.
- 범위 밖 발견은 즉석 해결이 아니라 CR 회부. "하는 김에"는 무상 노동이다.
- 발주사 의존(자료·계정·결정 지연)은 날짜·영향과 함께 기록한다 — 지연 책임의 근거.
- 데이터·소스의 소유권은 발주사, 수행사는 수탁 처리자다.

## 안티패턴

- **Owner 없는 계약** — "같이 정하자"로 시작해 아무도 문서화하지 않은 API·스키마.
- **내부 설계 먼저** — 구현하다 나온 형태를 계약이라 부르는 것. 소비 측 재작업의 근원.
- **역할 침범 해결** — 프론트가 스키마를 고치고 백엔드가 화면을 정하는 임시 해결. 당장은 빠르고 검수에서 터진다.
- **구두 조정** — 조정 결과를 계약 문서에 반영하지 않으면 다음 분쟁의 씨앗이다.

## 관련 문서

- [[00_설계 허브]] · [[설계 결정과 리뷰]] · [[아키텍처 스타일 선택]]
- [[외주 개발 산출물]] · [[SI 수주와 범위 관리]] · [[00_역할별 기획 허브]]
- [[01_백엔드 설계]] · [[02_데이터·DB 설계]] · [[03_프론트엔드 설계]] · [[04_인프라 설계]] · [[05_보안 설계]] · [[06_AI·에이전트 설계]]