---
title: "48장. 설계로 전환"
description: "명세 후보를 설계 탐색 입력으로 사용해 기능·데이터·인터페이스 책임을 할당하되 미정 정책을 확정하지 않는다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
합의된 요구를 화면·서비스·데이터·시험 설계로 어떻게 넘기는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “합의된 요구를 화면·서비스·데이터·시험 설계로 어떻게 넘기는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
요구사항 명세는 설계의 입력이지만 설계 해답 자체는 아니다. 요구 문장을 화면·서비스·데이터 구조에 기계적으로 대응시키면 공통 책임과 품질 트레이드오프를 놓치고, 아직 결정되지 않은 정책을 기술 선택으로 몰래 확정할 수 있다. 설계는 요구를 만족하는 대안을 탐색해야 한다.
이 장에서는 47장의 명세 후보를 바탕으로 기능·데이터·인터페이스 책임을 설계 요소에 할당한다. 대안과 결정 근거, 요구와의 추적 관계를 기록하고 미정 정책을 열린 항목으로 유지해, 검토 가능한 설계 후보를 만드는 과정을 보여 준다.
### 1. 요구를 설계 입력으로 해석한다
설계 전환의 입력은 요구 문장만이 아니다. 목표 `G-01`, 업무 목표 `BR-001`, 사용자·시스템 요구 `UR-001`과 `SR-001`을 먼저 읽는다. 여기에 기능 요구 `FR-001–FR-005`, 품질 요구 `QR-001–QR-011`, 데이터 요구 `DR-001–DR-006`, 인터페이스 요구 `IR-001–IR-006`, 규칙 `RULE-001–RULE-005`, 상태 모델, 수용 조건, 가정과 쟁점을 함께 놓는다. 특히 `ASM-002`, `ASM-003`, `ISS-001`, `CR-003`은 미해결이므로 설계가 그 빈칸을 몰래 채우면 안 된다. 입력 상태를 먼저 고정한다.
| 입력 묶음 | 설계에 전달하는 의미 | 현재 제한 |
|---|---|---|
| `G-01`, `BR-001` | 결과를 알 수 없는 상태와 수동 재처리를 줄이는 방향, 측정 필요 | 실제 기준선·분모·자료 없음 |
| `FR-001–FR-005` | 판정·접수·조회·중복 안전·취소 책임 | 규칙 원문과 일부 예외 미확인 |
| `QR-001–QR-011` | 성능·안전·접근성·회복·감사의 설계 자극 | 수치와 환경 대부분 후보 |
| `DR-001–DR-006` | 재현 가능한 판정과 상태 이력, 생명주기 | 보존·파기 정책 미확정 |
| `IR-001–IR-006` | 외부 실패와 계약 경계 | 실제 제공자 계약 없음 |
| `ASM-002`, `ASM-003`, `ISS-001` | 규칙 버전, 보류 좌석, 동시 좌석 배정의 결정 차단점 | 확인·결정 전 |
| `CR-003` | 졸업예정자 우선권 변경 제안 | 승인 근거가 없어 현 설계에서 제외 |
설계자는 이 입력을 세 종류로 나눈다. 반드시 지켜야 할 불변조건, 대안을 비교할 품질 자극, 사실 확인 전에는 정할 수 없는 정책이다. 예를 들어 규칙 연계 실패를 자동 승인으로 바꾸지 않는 것은 `IR-001`의 안전 불변조건이다. 상태 조회 p95 2초는 부하·데이터·측정 경계를 정해야 하는 품질 목표 후보다. 처리 보류가 좌석을 점유하는지는 `ASM-003`이므로 설계 선호로 결정할 정책이 아니다. 이 구분이 있어야 미결 사항을 구현 편의로 확정하지 않는다.
첫 설계 활동은 요구를 기능 책임으로 묶는 일이다. 화면이나 서비스 이름부터 정하지 않고 사용자가 얻는 결과, 상태를 바꾸는 업무 효과, 변경 이유와 실패 의미를 기준으로 기능 후보를 둔다.
| 기능 후보 | 맡는 결과와 책임 | 주요 상향 요구 | 넘지 않을 경계 |
|---|---|---|---|
| `FEAT-CATALOG-01` | 강좌 탐색과 판단 정보 제공 | `UR-001`, `IR-003` | 안내 정보가 최종 판정 기준이 되지 않음 |
| `FEAT-ELIGIBILITY-01` | 적용 규칙·입력 기준선으로 판정 후보 생성 | `FR-001`, `RULE-001–RULE-005` | 좌석의 최종 효과를 단독 확정하지 않음 |
| `FEAT-ENROLL-01` | 신청 접수, 중복 판별, 허용된 좌석·상태 효과 조정 | `FR-002`, `FR-004`, `QR-003` | 알림 성공을 업무 성공으로 해석하지 않음 |
| `FEAT-STATUS-01` | 현재 공식 상태·공개 사유·다음 행동 제공 | `FR-003`, `DR-001` | 다른 학생의 상태와 내부 사유를 노출하지 않음 |
| `FEAT-CANCEL-01` | 허용 상태에서 취소하고 후속 효과를 일관되게 기록 | `FR-005`, `DR-004` | 늦은 판정이 취소를 덮지 않게 함 |
| `FEAT-NOTIFY-01` | 상태 변경을 보조 채널로 통지 | `IR-005`, `QR-004` | 공식 상태를 관리하지 않음 |
| `FEAT-OPERATE-01` | 보류 관찰·재평가·대사와 감사 가능한 운영 | `IR-001`, `QR-009`, `QR-010` | 운영자의 근거 없는 수동 승인 금지 |
기능 사이의 핵심 흐름은 `FLOW-ENR-01`로 관리한다. 학생이 강좌를 찾고 신청 의도를 제출하면 `FEAT-ENROLL-01`이 유효 요청을 고유 ID로 접수한다. `FEAT-ELIGIBILITY-01`은 고정된 입력 기준선과 승인된 규칙 버전으로 판정을 시도한다. 판정 결과와 좌석 반영 결과가 안전성 기준을 충족하면 신청 상태에 반영하고, `FEAT-STATUS-01`이 그 결과를 제공한다. 알림은 그 뒤의 보조 반응이다. 규칙 연계가 실패하거나 응답이 무효이거나 시간 초과하면 승인으로 건너뛰지 않고 원인 코드가 있는 처리 보류로 간다.
이 흐름은 페이지 이동을 그린 것이 아니라 업무 상태 전이를 그린 것이다. `접수됨`은 `승인됨`이 아니고, 외부 장애로 생긴 `처리 보류`는 좌석 부족 학생을 순서대로 배정하는 `대기명단`이 아니다. 대기명단은 현재 확인된 범위에 없다. 보류가 좌석에 미치는 영향도 `ASM-003`이 열려 있으므로 도표에 점유 또는 비점유를 넣지 않는다. 전이마다 촉발 사건, 권한, 입력과 규칙 버전, 전후 상태, 사유와 요청 ID를 기록할 수 있어야 한다.
흐름을 사용자 접점으로 내리면 화면 후보가 된다. 화면은 요구를 새로 만드는 곳이 아니라 상태와 행동을 사용자가 이해하고 회복할 수 있도록 표현하는 곳이다.
| 화면 후보 | 사용자 목적 | 필수 상태·정보 | 연결 |
|---|---|---|---|
| `SCR-CATALOG-01` | 조건에 맞는 강좌 탐색 | 로딩·결과·빈 결과·오류, 원천 기준 시점 | `FEAT-CATALOG-01`, `API-CATALOG-01` |
| `SCR-COURSE-01` | 강좌 상세와 신청 판단 정보 확인 | 일정·학점·정원 안내·정보 시점·예외 안내 | `UR-001`, `DATA-COURSE-01` |
| `SCR-REVIEW-01` | 제출할 대상과 의도 재확인 | 제출 전·제출 중·미접수·접수 ID | `FR-002`, `API-ENROLL-01` |
| `SCR-STATUS-01` | 현재 상태·사유·다음 행동 조회 | 접수·판정 중·보류·승인·거절·취소 | `FR-003`, `UI-001`, `API-STATUS-01` |
| `SCR-CANCEL-01` | 취소 대상·영향을 확인하고 의도 제출 | 확인·처리 중·취소됨·취소 불가·경합 | `FR-005`, `API-CANCEL-01` |
`SCR-STATUS-01`은 이 설계의 의미 보존 지점이다. 신청 ID, 접수와 최종 판정의 구분, 현재 상태, 공개 가능한 사유, 마지막 갱신 시각과 가능한 다음 행동을 제공한다. 색만으로 상태를 구분하지 않고 텍스트와 프로그램적으로 인식 가능한 의미를 함께 제공한다. 상태 조회에 실패했을 때 이전 값을 최신처럼 보이지 않게 하고, 표시한다면 마지막 확인 시각과 최신성 한계를 명시한다. 알림을 받지 못해도 이 화면에서 공식 상태를 찾을 수 있어야 한다.
화면 시안이 매끄러워도 요구를 손상할 수 있다. 제출 직후 성공 색상과 “완료”만 표시하면 접수와 승인을 섞는다. 보류를 “대기”라고 줄이면 대기명단과 혼동한다. 내부 예외 문자열을 사유로 보여 주면 개인정보·보안과 이해 가능성을 해친다. 졸업예정자 배지나 우선순위를 넣으면 미승인 `CR-003`을 화면이 먼저 확정한다. 따라서 시안 검토는 아름다움뿐 아니라 상태 의미, 권한, 회복, 접근성과 상향 추적을 본다.
화면 뒤의 계약은 API 후보로 구체화한다. API는 화면 필드의 운반 통로가 아니라 책임 경계 사이에서 성공, 실패, 중복, 시간 초과, 버전 충돌의 의미를 합의하는 계약이다.
| API 후보 | 계약 목적 | 성공의 의미 | 실패·재시도 원칙 |
|---|---|---|---|
| `API-CATALOG-01` | 강좌 목록·상세 제공 | 원천 기준 시점이 있는 조회 결과 | 오래된 정보와 조회 불가를 구분 |
| `API-ENROLL-01` | 신청 의도 접수 | 신청 ID와 접수 상태 반환, 승인을 뜻하지 않음 | 같은 요청 ID는 중복 처리 없이 기존 결과에 연결 |
| `API-STATUS-01` | 자신의 공식 상태·사유 조회 | 상태·버전·공개 사유·갱신 시각 반환 | 부재와 접근 거절의 정보 노출을 통제 |
| `API-CANCEL-01` | 허용된 신청 취소 | 취소 결과와 최신 상태 반환 | 기대 버전 불일치 시 경합을 숨기지 않음 |
| `API-RULE-01` | 규칙 평가 연계 | 판정 결과·사유·규칙 버전 반환 | 실패·무효·시간 초과는 `IR-001` 보류 |
`API-ENROLL-01`에는 인증 주체, 강좌개설 ID, 요청 ID와 필요한 제출 문맥이 들어간다. 요청 ID의 적용 범위와 보존 기간, 같은 키에 다른 본문이 왔을 때의 충돌 처리, 응답 유실 후 재조회 방법을 계약해야 한다. “재시도 가능”을 단순히 다시 실행한다는 뜻으로 쓰면 안 된다. 서버가 첫 요청을 이미 반영했는데 응답만 유실될 수 있으므로 같은 의도는 기존 신청 ID와 상태로 돌아가야 한다.
`API-STATUS-01`은 사람용 문구와 안정된 상태·사유 코드를 구분한다. 공개 문구는 지역화하거나 개선할 수 있지만 상태 전이와 시험 오라클이 의존하는 코드 의미는 버전 관리한다. 내부 사유와 공개 사유의 분리는 `QR-005`, `QR-011`과 이어진다. 지원 문의가 필요하면 개인정보가 섞인 예외 대신 안전한 상관 ID를 제공한다. 캐시를 후보로 사용하더라도 승인·좌석·최종 상태의 공식 원천을 대체하지 않는다.
데이터 후보는 화면 표를 그대로 저장하는 구조가 아니라 업무 사실과 공식 원천을 나눈다.
| 데이터 후보 | 보존할 핵심 사실 | 무결성 책임 | 열린 정책 |
|---|---|---|---|
| `DATA-COURSE-01` | 학기·분반·일정·수용량의 조회 표현과 원천 시점 | 원천 참조와 최신성 표시 | 캐시 허용 지연 |
| `DATA-APPLICATION-01` | 신청 ID, 주체, 대상, 요청 ID, 현재 상태·버전 | 유효 전이, 동일 요청 유일성 | 상태별 보존·취소 경계 |
| `DATA-DECISION-01` | 결과, 공개·내부 사유, 입력 기준선, 규칙 버전 | `DR-001–DR-004`의 재현성 | 규칙 버전 제공 여부, 보존 기간 |
| `DATA-NOTIFICATION-01` | 통지 유형·대상 참조·시도·결과 | 업무 상태와 전달 상태 분리 | 채널별 최소 정보·재시도 |
| `DATA-AUDIT-01` | 주체·행위·근거·전후 상태·시각 | 운영 조치와 판정 변경의 추적 | 역할별 조회·법적 보존 |
현재 상태 한 열만 덮어쓰면 늦은 응답과 취소 경합을 설명하기 어렵다. 반대로 모든 원천 개인정보를 무기한 복제하면 `QR-011`과 `DR-005`를 해친다. 신청 식별과 상태 이력, 판정에 실제 사용한 최소 입력 기준선, 원천 버전 참조, 파생 현재 상태를 구분한다. `DATA-DECISION-01`은 학생·강좌 ID, 요청 시각, 결과와 사유, 규칙 버전, 최종 상태 변경을 연결하되 `ASM-002`가 확인되지 않았다는 사실을 메타데이터로 남긴다. 없는 규칙 버전을 임의 생성하지 않는다.
좌석 데이터의 공식 원천은 특히 조심해서 정한다. 탐색 화면의 잔여 좌석 캐시는 안내에 쓸 수 있어도 최종 승인 기준으로 사용할 수 없다. 마지막 좌석에 여러 요청이 들어오면 승인 기록과 좌석 반영 결과가 정원 초과 없이 일치해야 한다. 조건부 갱신, 직렬화, 예약, 배치 배정 같은 구현 대안은 `ISS-001`의 배정 정책과 실제 부하가 확인된 뒤 비교한다. 이 장에서는 누가 승자가 되는지 정하지 않고 “승인된 정원 초과 없음”과 “중복된 승인·좌석 반영 없음”을 불변조건으로 보존한다.
기능과 데이터를 논리적 컴포넌트 후보에 할당한다. 컴포넌트는 당장 별도 배포 서비스라는 뜻이 아니다. 변경 이유, 소유 상태와 실패 의미가 비슷한 책임의 경계다.
### 2. 기능과 데이터를 설계 후보에 할당한다
| 컴포넌트 후보 | 핵심 책임 | 실패 시 안전한 결과 | 연결 |
|---|---|---|---|
| `CMP-CATALOG-01` | 강좌 검색·상세, 원천 시점 표시 | 정보가 얼마나 오래됐는지 표시하거나 조회 불가로 처리 | `FEAT-CATALOG-01` |
| `CMP-ENROLL-01` | 접수·중복 판별·상태 전이 조정 | 미접수 또는 내구성 있는 접수·보류 | `FR-002`, `FR-004` |
| `CMP-RULE-01` | 규칙 연계·입력 기준선·판정 정규화 | 원인 있는 보류, 자동 승인 없음 | `FR-001`, `IR-001` |
| `CMP-STATUS-01` | 공식 상태·공개 사유 조회 | 최신성 한계를 포함한 제한 조회 | `FR-003`, `QR-001` |
| `CMP-NOTIFY-01` | 알림 전달과 실패 격리 | 업무 상태를 바꾸지 않고 재시도 | `IR-005` |
| `CMP-AUDIT-01` | 판정·운영 조치의 추적 | 필수 기록 실패 시 조치 제한 | `QR-009`, `DR-001` |
| `CMP-OPERATE-01` | 보류 관찰·재평가·대사 | 수동 우회 승인 없이 안전 정지 | `QR-010`, `FEAT-OPERATE-01` |
컴포넌트 경계는 다음 불변조건으로 검토한다. 동일 신청 의도는 재전송돼도 유효한 승인이나 좌석 반영이 중복되지 않는다. 규칙 실패나 무효 응답은 승인으로 해석하지 않는다. 늦은 응답은 더 새로운 취소나 판정 상태를 덮지 않는다. 알림 전달 결과는 신청 판정을 바꾸지 않는다. 운영 조치는 주체·사유·대상·전후 상태와 함께 감사된다. 하나라도 어느 책임이 지키는지 답할 수 없다면 설계 상자가 많아도 불완전하다.
외부 연계도 컴포넌트 호출선으로 끝내지 않는다. 인증 `IR-002`, 학사정보 `IR-003`, 규칙 `IR-004`, 알림 `IR-005`, 파일 이관 `IR-006`마다 제공자와 소비자, 공식 원천, 기준 시점, 시간 제한, 중복·순서, 오류 분류, 스키마 버전, 개인정보 등급, 변경 통보와 운영 연락을 계약해야 한다. 실제 계약은 아직 없으므로 이 항목들은 공급자 검토 체크리스트다. 성공 응답이라도 필수 필드와 규칙 버전이 없거나 알 수 없는 상태 코드라면 승인으로 정규화하지 않는다.
품질 요구는 횡단 설계 결정의 근거가 된다. `QR-001`을 이유로 캐시를 넣을 수 있지만 최신성과 공식성을 함께 설계해야 한다. `QR-003`은 요청 식별과 유일성, 원자적 상태 경계와 대사를 요구한다. `QR-005`와 `QR-011`은 객체 수준 인가, 최소 공개와 감사 경계를 만든다. `QR-007`은 화면 상태 메시지, 키보드 순서와 보조기술 확인을 설계에 넣는다. `QR-010`은 보류·재평가·격리·대사 절차를 정상 흐름과 같은 수준으로 다루게 한다.
| 품질 자극 | 설계 반응 후보 | 반드시 함께 측정·보호할 것 | 상태 |
|---|---|---|---|
| 피크 상태 조회 | 읽기 최적화·인덱스·제한 캐시·부하 제어 | p95, 오류율, 권한, 신선도 | 환경 미정 |
| 응답 유실 뒤 재전송 | 요청 ID·유일성·기존 결과 반환 | 중복 처리 결과 0, 보존 창 | 동일성 정책 미정 |
| 규칙 시간 초과 | 내구 접수·시간 제한·원인 보류·재평가 | 자동 승인 0, 보류 적체 | 허용 지연 미정 |
| 마지막 좌석 동시 신청 | 원자적 좌석 경계·버전·대사 | 정원 초과 0, 판정 일치 | 승자 정책 미정 |
| 다른 학생 ID 직접 조회 | 객체 인가·최소 오류·감사 | 내용 비공개, 상태 불변 | 역할 계약 미정 |
| 처리 노드 중단·복구 | 멱등 소비·대사·격리 | 좌석·신청·판정 모순 0 | 복구 목표 미정 |
신청 처리 방식은 동기식 일괄 처리, 완전 비동기 처리, 내구 접수와 분리 판정의 혼합 대안으로 비교한다. 동기식은 즉시 결과가 단순해 보이지만 외부 지연과 응답 유실의 불확실성을 전파한다. 완전 비동기는 부하 흡수와 재처리에 유리하지만 결과 지연, 순서·중복과 운영 복잡도가 크다. 혼합 방식은 접수 여부를 분명히 하고 제한 시간 안에 판정되지 않으면 보류로 넘길 수 있지만 상태·대사·재평가 운영이 필요하다.
현재 증거로는 혼합 방식을 우선 검토한다. 이것은 `FR-002`, `FR-003`, `FR-004`, `IR-001`, `QR-010`을 함께 설명하기 쉬운 **제안**이지 승인된 아키텍처가 아니다. 좌석 점유 시점, 허용 판정 지연, 피크 부하, 외부 SLA와 운영 역량이 확인되면 세 대안을 다시 비교한다. 모듈형 단일체인지 여러 서비스인지도 이 정보와 조직 경계·독립 배포 필요가 확인된 뒤 선택한다.
이 선택을 `ADR-ENR-001` 후보로 기록한다.
| 항목 | 기록 후보 |
|---|---|
| 상태 | 제안됨, 미승인 |
| 결정 질문 | 규칙 연계 실패 중 신청 의도와 결과를 어떻게 안전하게 보존할 것인가? |
| 대안 | 동기식 실패, 완전 비동기, 내구 접수+분리 판정 |
| 제안 | 내구 접수 후 제한 시간 판정, 미완료는 원인 코드가 있는 보류 |
| 근거 | `FR-002–FR-004`, `IR-001`, `QR-003`, `QR-010` |
| 비용·결과 | 상태 모델, 재평가, 대사, 운영 관찰과 추가 저장 필요 |
| 재검토 조건 | 좌석 정책·부하·허용 지연·외부 SLA·운영 능력의 확인 또는 변경 |
41장에서 사용한 `ADR-ENR-01`은 이 질문을 처음 포착한 분석 카드였다. 번호가 비슷하다고 두 결정을 따로 운용하지 않는다. 그 카드는 설계 기록 `ADR-ENR-001`로 통합됐다는 매핑을 남기고 이후에는 `ADR-ENR-001`을 정식 후보 ID로 사용한다. 원 기록을 지우지 않고 `통합됨` 관계를 둬 검토 이력을 보존한다.
상태 조회 캐시는 `ADR-ENR-002` 후보로 별도 관리한다. 캐시는 검색·설명용 읽기 성능을 개선할 수 있지만 승인, 좌석과 최종 상태의 공식 원천을 대신하지 않는다. 허용 지연, 무효화 사건, 버전 비교, 오래된 상태 표시와 장애 시 우회 기준이 결정되지 않으면 적용하지 않는다. 이 결정은 `QR-001`만 보고 승인할 수 없고 `FR-003`, `DR-004`, `QR-005`, `QR-011`과 함께 검토해야 한다.
설계의 품질은 상향·하향으로 같은 뜻을 읽을 수 있는지 확인한다. 대표 사슬은 다음과 같다.
아래에서 위로 읽으면 `DATA-DECISION-01`의 공개 사유와 규칙 버전이 어떤 사용자 결과를 지원하는지 설명할 수 있다. `API-STATUS-01`을 없애거나 캐시로 바꾸려면 `FR-003`의 공식 상태, 최신성, 접근 통제와 시험이 어떻게 유지되는지 보여야 한다. 위에서 아래로 읽으면 `FR-003`에 화면만 있고 시험 후보나 공식 데이터가 빠진 결함을 찾을 수 있다.
주요 설계 묶음을 한 표로 대조하면 누락이 더 잘 보인다.
| 기능 | 흐름 | 화면 | API | 데이터 | 시험 후보 |
|---|---|---|---|---|---|
| `FEAT-CATALOG-01` | `FLOW-ENR-01` | `SCR-CATALOG-01`, `SCR-COURSE-01` | `API-CATALOG-01` | `DATA-COURSE-01` | `TC-CATALOG-01` |
| `FEAT-ENROLL-01` | `FLOW-ENR-01` | `SCR-REVIEW-01`, `SCR-STATUS-01` | `API-ENROLL-01` | `DATA-APPLICATION-01` | `TC-DUP-001-01`, `TC-CAP-001-01` |
| `FEAT-STATUS-01` | `FLOW-ENR-01` | `SCR-STATUS-01` | `API-STATUS-01` | `DATA-DECISION-01` | `TC-FR-003-01` |
| `FEAT-CANCEL-01` | `FLOW-ENR-01` | `SCR-CANCEL-01`, `SCR-STATUS-01` | `API-CANCEL-01` | 신청·판정 상태 이력 | `TC-CAN-001-01` |
| `FEAT-ELIGIBILITY-01` | 판정 하위 흐름 | 직접 화면 없을 수 있음 | `API-RULE-01` | 규칙 입력·판정 참조 | `TC-RULE-001-01`, `TC-IR-001-01` |
표가 일대일 대응을 강제하지는 않는다. 하나의 품질 요구는 여러 컴포넌트와 시험에 걸치고, 하나의 화면은 여러 기능을 조합한다. 중요한 것은 모든 하위 항목이 존재 이유와 검증 방법을 설명하며, 미승인 기능이 상향 근거 없이 생기지 않는 것이다. 예를 들어 운영 대시보드가 필요해 보여도 역할·허용 조치·감사·개인정보 요구를 먼저 요구 후보로 되돌려야 한다. 설계 편의를 사용자나 운영자의 승인된 필요로 가장하지 않는다.
설계 검토에서는 입력, 판단, 출력, 승인과 다음 인계를 구분한다. 입력은 `SRS-ENR-01`` v0.9`와 미결 목록이다. 판단은 기능 경계, 상태 전이, API·데이터의 공식 원천, 컴포넌트 책임, 품질 전술과 대안 비교다. 출력은 `DES-ENR-01`` v0.1`, 요구-설계 매핑, 화면·계약·데이터 카드, `ADR-ENR-001`·`002` 후보와 열린 질문 목록이다. 설계 책임자는 실현 가능성과 내부 일관성을 검토하고, 요구 책임자는 의미 보존을, 시험 책임자는 관찰 가능성을, 보안·개인정보·접근성 책임자는 횡단 제약을 검토한다. 학사 정책 소유자는 규칙과 미결 정책만 승인할 수 있다.
현재 설계가 요구 단계로 돌려보낼 질문도 명시한다.
| 반환 ID 후보 | 질문 | 차단되는 설계·시험 |
|---|---|---|
| `DEF-001` | 처리 보류의 최대 시간, 재평가 종료와 사용자 후속은 무엇인가? | 큐 용량, 운영 절차, 회복 시험 |
| `ASM-002` | 규칙 서비스가 재현 가능한 규칙 버전을 제공하는가? | `DATA-DECISION-01`, 감사 오라클 |
| `ASM-003` | 처리 보류가 좌석을 점유하는가? | 좌석 모델, 취소·재평가 경합 |
| `ISS-001` | 마지막 좌석과 승인된 우선 조건에서 승자를 어떻게 정하는가? | 동시성 알고리즘, `TC-CAP-001-01`의 승자 오라클 |
| `DEF-003` | p95 2초의 부하·데이터·네트워크·오류·신선도 경계는 무엇인가? | 성능 구조와 합격 판정 |
| `DEF-004` | 신청·판정·감사 데이터의 목적별 보존·파기 기간은? | 저장·백업·삭제·감사 설계 |
이 질문들이 열려 있어도 설계 후보를 만들 수는 있다. 다만 선택을 확정하거나 개발 완료를 주장할 수는 없다. 현재 검토 결과는 `조건부 진행`이다. 자동 승인 금지, 중복 처리 금지, 권한 외 공개 금지, 정원 초과 금지, 상태·이력 모순 금지 같은 보호 조건은 유지한다. 누가 마지막 좌석을 얻는지, 보류가 좌석을 잡는지, 성능 목표를 어떤 환경에서 재는지, 데이터를 얼마나 보존하는지는 결정 전 빈칸으로 남긴다.
설계 승인 회의에 올릴 때는 그림 한 장만 보내지 않는다. 변경된 요구 버전, 대안과 탈락 근거, 불변조건, 위험, 미결 질문, 요구-설계-시험의 양방향 표본을 함께 제공한다. 각 검토 의견에는 작성자·시각·대상 버전·결정 역할·처리 결과를 남긴다. 실제 이해관계자와 정책 원문이 없는 이 사례에서는 어떤 역할도 실제 승인을 했다고 기록하지 않는다. `DES-ENR-01`` v0.1`은 다음 장의 추적성 점검을 위한 교육용 후보로 유지한다.
다음 장의 입력은 이 설계 묶음과 47장의 요구 묶음이다. 49장에서는 요구와 설계 사이에 화살표가 있다는 사실만 확인하지 않고 관계의 종류와 방향, 버전, 책임자와 변경 사건을 점검한다. `FR-003`에서 `TC-FR-003-01`까지 내려갔다가 다시 상위 목표로 돌아오는 대표 사슬, 고아 요구와 근거 없는 설계, 잘못된 관계를 찾아야 한다. 그 점검을 통과해야 50장에서 변경 요청 하나가 어느 요구·화면·계약·데이터·시험에 영향을 주는지 과장 없이 계산할 수 있다.
### 3. 설계 탐색 결과를 추적으로 넘긴다
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 48장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
명세 후보를 설계 탐색 입력으로 사용해 기능·데이터·인터페이스 책임을 할당하되 미정 정책을 확정하지 않는다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
학습 순서에 따라 다음 판단 주제로 이어갑니다.