---
title: "33장. 요구사항에서 시스템 설계로"
description: "기능·품질·데이터·인터페이스 요구를 컴포넌트 책임과 상호작용에 할당하고 설계 근거를 보존한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
요구가 아키텍처 결정을 제약하는 지점과 설계 선택인 지점을 어떻게 구분하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “요구가 아키텍처 결정을 제약하는 지점과 설계 선택인 지점을 어떻게 구분하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
요구사항은 시스템이 달성해야 할 결과를 말하지만 그 결과를 어떤 구조와 책임 분담으로 실현할지는 설계에서 결정한다. 기능만 따라 구성요소를 나누면 성능·가용성·보안 같은 품질 요구가 뒤늦게 구조를 흔들고, 반대로 익숙한 아키텍처를 먼저 선택하면 요구가 설계에 끌려갈 수 있다.
이 장에서는 기능·품질·데이터·인터페이스 요구를 아키텍처 동인으로 해석하고 시스템 책임을 구성요소에 할당한다. 여러 설계 대안과 트레이드오프를 요구 근거로 비교하며, 결정과 가정·위험을 추적해 요구 변경이 시스템 구조에 미치는 영향을 설명하는 방법을 다룬다.
### 1. 요구사항과 아키텍처
요구사항에서 시스템 설계로 넘어갈 때 가장 먼저 버려야 할 생각은 “요구사항 하나에 화면 하나, API 하나, 테이블 하나를 붙이면 설계가 된다”는 식의 일대일 대응이다. 하나의 품질 요구는 여러 컴포넌트에 걸친 전술을 필요로 하고, 하나의 컴포넌트는 여러 기능을 함께 맡을 수 있다. 요구사항은 설계가 만족해야 할 필요와 제약을 말하고, 설계는 그 필요를 실현하는 책임·상호작용·데이터·기술 선택을 설명한다.
[ISO/IEC/IEEE 42010:2022](https://www.iso.org/standard/74393.html)는 시스템의 아키텍처와 아키텍처 설명을 구분한다. 도표가 곧 아키텍처인 것이 아니라 이해관계자의 관심사를 어떤 관점으로 표현했는지, 요소와 관계에 어떤 근거가 있는지를 함께 다뤄야 한다. 따라서 이 장에서 만드는 컴포넌트와 인터페이스는 실제 배포 구조를 확정한 그림이 아니라 앞 장의 요구 후보를 검증하기 위한 **교육용 설계 후보**다. 실제 이해관계자 승인 기준선과 운영 환경 자료가 없으므로 `CMP`, `API`, `DATA`, `ADR` 식별자에는 모두 후보 상태가 붙는다.
요구사항은 설계를 제약하지만 단 하나의 해답을 지시하지 않는다. `FR-003`의 상태·사유 조회는 단일 애플리케이션, 모듈형 단일체, 여러 서비스 가운데 어느 구조로도 구현할 수 있다. 반대로 “마이크로서비스를 쓴다”는 선택은 사용자의 필요가 아니다. 독립 배포, 조직 경계, 장애 격리, 부하 차이 같은 근거가 확인될 때만 설계 대안으로 정당화된다.
설계 전환은 다음 네 질문으로 시작한다.
1. 어떤 기능이 어떤 상태와 결정을 공식적으로 소유하는가?
2. 품질 시나리오를 만족하려면 어디에 시간 제한, 중복 안전성, 격리와 관찰 지점을 두어야 하는가?
3. 외부 연계가 실패했을 때 어떤 결과까지 안전하게 제공할 수 있는가?
4. 이 구조에서 요구 변경의 영향을 어느 컴포넌트·계약·데이터·시험까지 역추적할 수 있는가?
`G-01`` → ``UR-001`` → ``FR-001–FR-005``, ``QR-001–QR-011``, ``IR-001–IR-006`의 연결을 설계 입력으로 삼는다. 다만 `BR-001`과 `QR-001`의 수치는 기준선·부하 환경이 확인되지 않은 목표이고, `RULE-005`와 `CR-003`의 졸업 예정자 우선권도 승인되지 않았다. 설계가 이 미결 정책을 코드 구조나 데이터 열로 먼저 확정해서는 안 된다.
### 2. 기능 할당
기능 할당은 화면 이름을 서버 모듈 이름으로 바꾸는 작업이 아니다. 기능이 어떤 결정을 내리고 어떤 상태를 바꾸며 어떤 근거를 남기는지에 따라 책임을 묶는다. 31장에서 도출한 기능 후보를 다음과 같이 할당한다.
| 기능 후보 | 주 책임 | 소유 상태·판단 | 주요 입력·출력 | 연결 요구 |
|---|---|---|---|---|
| `FEAT-CATALOG-01` | 개설 강좌 탐색과 판단 정보 제공 | 검색 표현, 정보 기준 시점 | 학기·필터 → 강좌 목록·상세 | `UR-001`, `IR-003` |
| `FEAT-ELIGIBILITY-01` | 적용 규칙과 입력으로 자격 판정 | 판정 결과·사유·규칙 버전 | 학생·강좌·학적 스냅숏 → 결정 후보 | `FR-001`, `RULE-001–RULE-005` |
| `FEAT-ENROLL-01` | 신청 의도 접수와 생명주기 조정 | 신청 ID, 접수·처리 상태 | 신청 명령 → 접수 또는 미접수 | `FR-002`, `FR-004` |
| `FEAT-STATUS-01` | 공식 현재 상태·사유 조회 | 신청 현재 상태와 결정 참조 | 신청 ID → 상태·사유·다음 행동 | `FR-003`, `DR-001` |
| `FEAT-CANCEL-01` | 허용 상태의 취소 처리 | 취소 의도와 전이 결과 | 신청 ID·버전 → 취소 결과 | `FR-005` |
| `FEAT-NOTIFY-01` | 상태 변경 보조 통지 | 전달 시도·결과 | 상태 변경 사건 → 최소 정보 알림 | `IR-005`, `QR-004` |
| `FEAT-OPERATE-01` | 보류 관찰·재평가·감사 지원 | 운영 조치와 근거 | 보류 사례 → 안전한 후속 처리 | `IR-001`, `QR-009`, `QR-010` |
여기서 신청 접수와 자격 판정을 분리하는 이유는 실패 의미가 다르기 때문이다. 접수 성공은 사용자의 의도가 내구성 있게 기록됐다는 뜻이지 승인됐다는 뜻이 아니다. 규칙 서비스가 응답하지 않으면 `IR-001`에 따라 자동 승인하지 않고 보류 상태와 원인 코드를 남겨야 한다. 두 책임을 하나의 불투명한 호출로 합치면 응답 유실 때 접수 여부를 알기 어렵고, 재시도에서 중복 처리가 생기기 쉽다.
기능 간 호출 방향만 그리지 말고 사건과 상태 전이도 기록한다. `FEAT-ENROLL-01`이 신청을 접수하면 `FEAT-ELIGIBILITY-01`이 판정을 시도하고, 결과가 있으면 `FEAT-STATUS-01`에서 조회할 공식 상태에 반영한다. 알림은 그 뒤의 보조 반응이다. 알림 실패가 승인·거절 결정을 되돌리지 않으며, 알림 성공이 판정 성공을 대신하지 않는다.
할당표를 역으로 읽으면 빠진 책임이 드러난다. `FR-004`가 중복 안전성을 요구하는데 요청 식별자와 기존 결과를 누가 보존하는지 없다면 설계가 불완전하다. `QR-009`가 감사 가능성을 요구하는데 운영자가 변경한 이유를 어느 데이터가 남기는지 없다면 컴포넌트 수가 많아도 요구를 만족하지 못한다.
### 3. 컴포넌트
컴포넌트는 우선 배포 단위가 아니라 변경 이유와 상태 책임이 비슷한 논리적 경계로 잡는다. 이후 조직·부하·가용성·배포 독립성 근거가 모이면 한 프로세스 안의 모듈로 둘지 독립 서비스로 둘지 결정한다.
| 컴포넌트 후보 | 책임 | 소유하거나 참조하는 데이터 | 실패 시 안전한 결과 |
|---|---|---|---|
| `CMP-CATALOG-01` | 강좌 검색·상세 조회, 원천 시점 표시 | `DATA-COURSE-01` 읽기 모델 | 오래된 정도 표시 또는 조회 불가 |
| `CMP-ENROLL-01` | 접수, 중복 판별, 신청 상태 전이 조정 | `DATA-APPLICATION-01` | 미접수 또는 내구성 있는 접수·보류 |
| `CMP-RULE-01` | 규칙 연계, 입력 기준선 고정, 판정 정규화 | `DATA-DECISION-01` 기록 입력 | 원인 있는 보류, 자동 승인 금지 |
| `CMP-STATUS-01` | 공식 상태와 공개 사유 조회 | 신청·결정 참조 | 최신성 정보를 포함한 제한 조회 |
| `CMP-NOTIFY-01` | 알림 큐 처리와 전달 추적 | 전달 사건·결과 | 재시도·격리, 업무 상태 불변 |
| `CMP-AUDIT-01` | 판정·운영 조치의 변경할 수 없는 추적 기록 지원 | 감사 사건, 주체·근거·시각 | 핵심 기록 실패 시 조치 제한 |
| `CMP-OPERATE-01` | 보류 사례 관찰·허용된 재처리 | 신청·연계·감사 참조 | 수동 우회 승인 금지 |
`CMP-STATUS-01`을 별도 논리 책임으로 둔다고 해서 별도 데이터베이스나 서비스가 즉시 필요한 것은 아니다. 조회 부하가 신청 명령보다 훨씬 크고 독립 확장이 필요하다는 측정이 나오면 읽기 모델을 검토할 수 있다. 그때도 사용자가 보는 상태가 얼마나 늦을 수 있는지, 최신 판정과 충돌할 때 무엇을 기준으로 삼을지, 지연을 어떻게 표시할지 먼저 합의한다.
컴포넌트 경계에는 불변조건을 적는다.
- 동일한 신청 의도는 재전송돼도 유효한 신청으로 여러 번 반영되지 않는다.
- 승인 상태는 규칙 판정과 좌석 반영이 정한 일관성 경계를 통과한 뒤에만 만들어진다.
- 규칙 실패·무효 응답·시간 초과는 승인으로 해석되지 않는다.
- 현재 상태는 이력과 모순되지 않으며 늦은 응답이 더 새로운 전이를 덮지 않는다.
- 운영 조치는 주체·사유·대상·전후 상태와 함께 감사된다.
분산 트랜잭션을 피한다는 구호만으로 일관성을 포기하지 않는다. 좌석 차감과 승인 기록이 다른 경계에 있다면 예약, 조건부 갱신, 보상 가운데 어떤 방식으로 “좌석 초과 승인 없음”을 지킬지 증명해야 한다. `ISS-001`이 해결되지 않은 현재는 우선 배정과 좌석 경합의 최종 알고리즘을 확정할 수 없다. `DEC-001`도 승인된 결정이 아니라 검토 중인 기록이다.
컴포넌트 산출물은 요구-컴포넌트 매핑과 책임 카드다. 카드에는 입력, 출력, 소유 상태, 불변조건, 의존성, 실패 의미, 관찰 지점과 연결 시험을 포함한다. 상자 이름만 있는 그림보다 이 카드가 설계 검토에 더 유용하다.
### 4. API
API는 화면 필드를 그대로 주고받는 통로가 아니라 책임 경계 사이의 계약이다. 호출자는 성공·실패·시간 초과·중복·버전 충돌을 구분할 수 있어야 하고, 제공자는 인증·인가·검증과 오류 의미를 일관되게 지켜야 한다.
| API 후보 | 목적 | 핵심 계약 | 오류·재시도 원칙 |
|---|---|---|---|
| `API-CATALOG-01` | 강좌 검색·상세 제공 | 강좌개설 ID, 원천 기준 시점, 페이지 규칙 | 오래된 정보와 장애 구분 |
| `API-ENROLL-01` | 신청 의도 접수 | 인증 주체, 강좌 ID, 요청 ID → 신청 ID·접수 상태 | 동일 요청 결과 재사용, 무조건 재실행 금지 |
| `API-STATUS-01` | 공식 상태·사유 조회 | 신청 ID → 상태, 버전, 사유, 갱신 시각 | 접근 거절과 부재의 정보 노출 통제 |
| `API-CANCEL-01` | 허용 상태의 취소 | 신청 ID, 기대 상태 버전, 요청 ID | 경합 시 최신 상태 반환 |
| `API-RULE-01` | 규칙 평가 연계 | 고정된 입력 기준선 → 결과·사유·규칙 버전 | 무효·시간 초과는 `IR-001` 보류 |
`API-ENROLL-01`의 성공 응답은 승인 여부가 아니라 접수 계약을 표현한다. 응답이 유실됐을 때 클라이언트는 같은 요청 ID로 결과를 조회하거나 재전송할 수 있어야 한다. 서버는 요청 ID의 유효 범위, 동일성 판단에 포함할 필드, 보존 기간과 충돌 응답을 정의한다. 같은 키에 다른 강좌를 넣은 요청을 기존 성공으로 돌려주는 식의 잘못된 중복 처리는 금지한다.
`API-STATUS-01`은 화면 문구가 아니라 안정된 상태·사유 의미를 제공한다. 사람용 설명은 지역화될 수 있지만 상태 코드와 사유 코드는 버전 관리한다. 내부 예외 문자열을 공개 사유로 보내지 않고, 지원이 필요한 경우 개인정보를 포함하지 않는 상관 ID를 제공한다. 캐시를 사용한다면 응답 시각·데이터 버전과 허용 지연을 계약에 포함한다.
시간 제한은 호출마다 임의로 두지 않는다. 사용자 응답 예산, 외부 연계 특성, 재시도 횟수, 큐 대기와 서버 처리 시간을 함께 배분한다. 규칙 호출을 세 번 재시도한 결과 p95 목표를 초과하고 동시 장애를 증폭한다면 회복 전술이 아니다. 지수형 지연, 회로 차단, 동시 요청 제한, 격리 큐를 후보로 비교하고 실제 장애·부하 시험으로 조정한다.
API 버전은 URL 숫자만의 문제가 아니다. 필드 의미, 필수성, 상태 전이와 오류 분류의 호환성을 관리한다. 소비자·제공자 계약 시험을 두고, 폐기 일정과 관찰 지표를 기록한다. 승인되지 않은 `CR-003` 때문에 우선순위 필드를 공개 계약에 미리 추가하지 않는다. 정책이 승인되면 사유 공개 범위와 데이터 최소화를 함께 검토한다.
### 5. 데이터
데이터 설계는 화면 표를 저장할 열로 옮기는 일이 아니라 업무 사실, 현재 상태, 판정 근거와 보존 책임을 정의하는 일이다. 같은 “상태”라도 신청 생명주기, 규칙 판정, 알림 전달 상태는 서로 다른 사실이다.
| 데이터 후보 | 핵심 내용 | 기준·무결성 | 보존·보호 질문 |
|---|---|---|---|
| `DATA-COURSE-01` | 학기·강좌개설·일정·수용량의 조회 표현 | 학사 원천과 기준 시점 연결 | 얼마나 오래 캐시 가능한가? |
| `DATA-APPLICATION-01` | 신청 ID, 주체, 대상, 요청 ID, 현재 상태·버전 | 유효 전이와 중복 유일성 | 신청·취소 기록 보존 기간은? |
| `DATA-DECISION-01` | 결과, 공개/내부 사유, 입력 기준선, 규칙 버전 | `DR-001`, `DR-003`과 일치 | 이의·감사에 필요한 최소 기간은? |
| `DATA-NOTIFICATION-01` | 통지 대상 참조, 유형, 전달 시도·결과 | 업무 판정과 분리 | 연락처·내용 최소화와 삭제는? |
| `DATA-AUDIT-01` | 주체, 행위, 근거, 전후 상태, 시각 | 변조 탐지와 시간 일관성 | 역할별 조회와 법적 보존은? |
`DATA-APPLICATION-01`의 현재 상태만 저장하면 과거 판정의 근거와 늦은 응답 경합을 설명하기 어렵다. 모든 것을 무기한 사건으로 저장하는 것도 정답은 아니다. 필요한 이력, 스냅숏, 파생 현재 상태를 구분하고 `DR-004`, `QR-009`, `QR-011`에 맞춰 보존·파기·접근 정책을 결정한다.
규칙 판정에는 “지금 조회한 학생 정보”가 아니라 판정에 실제 사용한 입력의 기준선이 필요하다. 학적·이수·신청·강좌 상태가 서로 다른 시점이면 재현성이 무너진다. `DR-003`은 데이터 항목, 원천 버전, 조회 시각과 일관성 경계를 정하도록 요구한다. 전체 개인정보 복사본을 남기기보다 필요한 사실의 버전 참조나 최소 스냅숏을 선택하고, 원천 정정이 과거 판정과 재평가에 미치는 영향도 기록한다.
좌석 수는 특히 기준이 중요하다. 검색용 캐시의 잔여 좌석은 안내에는 쓸 수 있어도 최종 승인 기준으로 그대로 사용할 수 없다. 동시 신청에서 음수 좌석이나 초과 승인이 생기지 않도록 조건부 갱신·직렬화·예약 같은 대안을 비교한다. 좌석을 보류 신청이 점유하는지는 `ASM-003`이 아직 확인되지 않았으므로 데이터 모델에 확정하지 않는다.
개인정보 최소화는 열을 줄이는 것에 그치지 않는다. 로그, 추적 ID, 메시지 큐, 분석 사본, 백업과 시험 데이터까지 흐름을 따라간다. 민감 사유를 알림 본문이나 URL에 넣지 않고, 운영자가 볼 수 있는 내부 사유와 학생에게 공개할 사유를 분리한다. 삭제 요청과 법정 보존이 충돌할 때의 책임자는 실제 정책 확인이 필요하다.
### 6. 외부 연계
외부 연계는 “호출 성공”뿐 아니라 데이터 기준, 응답 지연, 부분 실패, 버전과 운영 책임을 계약해야 한다. 수강신청 후보는 인증, 학사정보, 규칙, 알림과 파일 이관 연계에 의존한다.
| 연계 요구 | 외부 책임 | 내부 책임 | 안전 저하 방식 |
|---|---|---|---|
| `IR-002` 인증 | 주체 인증·세션 정보 | 대상별 인가·재인증 처리 | 미인증 조작 거절, 기존 신청 불변 |
| `IR-003` 학사정보 | 학생·강좌·이수 원천 | 기준 시점 기록·오래된 정보 표시 | 판정에 불충분하면 보류 또는 미접수 |
| `IR-004` 규칙 | 규칙 결과·사유·버전 제공 | 시간 제한·검증·정규화·감사 | `IR-001`에 따라 자동 승인 금지 |
| `IR-005` 알림 | 채널 전달 | 최소 정보·재시도·공식 조회 연결 | 알림 실패와 업무 결과 분리 |
| `IR-006` 파일 이관 | 합의 형식·전달 | 무결성·중복·격리·재처리 | 일부 실패 격리, 전체 성공 오인 금지 |
연계 계약에는 소유자, 지원 시간, 용량, 시간 제한, 재시도 가능 오류, 중복 의미, 순서, 스키마 버전, 개인정보 등급, 관찰 지표와 비상 연락 절차를 둔다. “REST로 연계한다”는 기술 표현만으로는 이런 책임을 설명하지 못한다.
규칙 서비스가 느릴 때 내부 신청 처리를 같은 시간 동안 붙잡아 둘지, 접수를 먼저 내구성 있게 남기고 비동기 판정할지 비교한다. 피크 시간, 허용 판정 지연과 사용자 기대가 없으면 확정할 수 없다. 현재 후보에서는 접수 여부를 분명히 하고 판정이 끝나지 않으면 보류로 조회 가능하게 하는 방향이 `FR-002`, `FR-003`, `IR-001`을 함께 만족시키기 쉽다. 다만 좌석의 점유 시점과 공정성 정책이 결정돼야 세부 순서를 정할 수 있다.
외부 응답은 신뢰 경계 밖의 입력이다. 성공 코드라도 필수 필드, 규칙 버전, 사유 값과 서명을 검증하고, 예상하지 못한 값은 승인으로 변환하지 않는다. 장애 중 운영자가 CSV로 결과를 덮어쓰는 우회 절차도 별도 요구·권한·감사·대사 없이 허용하지 않는다.
연계 시험은 모의 성공 응답만으로 끝내지 않는다. 지연, 중복, 순서 뒤바뀜, 부분 필드, 이전 버전, 연결 단절과 회복 뒤 폭주를 포함한다. 연계 소유자와 함께 계약 예제를 검토하고 운영 대시보드에서 어떤 신호로 문제를 구별할지도 정의한다.
### 7. 기술 제약
기술 제약은 조직이 반드시 따라야 하는 플랫폼·법규·운영 환경과, 설계자가 선호하는 선택을 구분한다. 지원 브라우저, 배포 창, 기존 인증 체계, 데이터 위치, 암호화 기준, 접근성 준수 범위가 실제 제약일 수 있다. 특정 프레임워크나 메시지 브로커는 근거가 확인되지 않으면 대안일 뿐이다.
[ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html)의 제품 품질 모델은 요구 도출, 설계 목표, 시험 목표와 수용 기준을 연결하는 데 사용할 수 있다. 품질 특성을 이름으로만 적지 않고 관찰 가능한 시나리오로 내린다. SEI가 제시한 품질 속성 시나리오의 여섯 요소인 원천, 자극, 환경, 대상, 반응, 측정값을 사용하면 다음과 같이 설계 전술을 비교할 수 있다.
| 시나리오 후보 | 원천·자극·환경 | 대상·기대 반응·측정 | 설계 전술 후보 | 연결 |
|---|---|---|---|---|
| `QS-PERF-01` | 피크 시간 학생의 상태 조회 | 조회 경로가 상태·시각 반환, p95 2초 후보 | 읽기 최적화, 인덱스, 제한 캐시, 부하 제어 | `QR-001`, `PT-STATUS-001` |
| `QS-AVAIL-01` | 운영 중 규칙 서비스 시간 초과 | 신청이 자동 승인되지 않고 보류·원인 기록 | 내구 접수, 시간 제한, 회로 차단, 재평가 큐 | `IR-001`, `QR-002`, `QR-010` |
| `QS-RELI-01` | 응답 유실 뒤 동일 요청 재전송 | 중복 반영 없이 기존 신청 ID·결과 반환 | 요청 ID, 유일성, 결과 보존 | `FR-004`, `QR-003` |
| `QS-REC-01` | 처리 노드 중단 뒤 복구 | 승인·좌석·결정 불일치 없이 재개 | 원자적 경계, 멱등 소비, 대사·격리 | `QR-010`, `TC-CAP-001-01` |
| `QS-SEC-01` | 다른 학생 신청 ID 직접 조회 | 대상 정보 비노출, 접근 거절·감사 | 객체 수준 인가, 최소 응답, 감사 | `QR-006`, `QR-011` |
수치가 없는 시나리오는 아직 수용 기준이 아니다. `QR-001`의 p95 2초도 동시 사용자, 데이터량, 네트워크 위치, 캐시 상태와 측정 구간을 정해야 의미가 있다. 가용성·복구 목표 역시 업무 시간과 허용 데이터 손실을 확인한 뒤 정량화한다.
신청 처리 구조는 세 대안으로 비교할 수 있다.
| 대안 | 장점 | 위험·비용 | 적합 조건 |
|---|---|---|---|
| 동기식 일괄 처리 | 즉시 결과가 단순해 보임 | 연계 지연 전파, 응답 유실 불확실, 피크 결합 | 모든 의존의 짧고 안정적인 응답이 입증될 때 |
| 완전 비동기 처리 | 흡수·재처리·격리에 유리 | 결과 지연, 순서·중복·운영 복잡도 | 판정 지연이 허용되고 운영 역량이 있을 때 |
| 내구 접수와 분리 판정의 혼합 | 접수 여부 명확, 보류·회복 가능 | 상태 모델·대사·관찰 필요 | 즉시 승인보다 안전성과 회복이 중요할 때 |
현재 증거로는 세 번째 혼합 대안을 우선 검토할 수 있다. 접수 상태를 내구성 있게 만들고, 규칙 판정은 시간 제한 안에 완료되면 즉시 반영하되 미완료면 보류와 재평가로 넘긴다. 알림은 상태 변경 뒤 비동기로 분리한다. 이것은 **권고 후보**이지 승인된 구조가 아니다. 좌석 점유 시점, 허용 대기 시간, 피크 부하와 운영 지원 능력이 확인되면 다시 비교한다.
설계 결정 기록 후보 `ADR-ENR-001`은 다음처럼 남긴다.
| 항목 | 내용 |
|---|---|
| 상태 | 제안됨, 미승인 |
| 결정 질문 | 규칙 연계 실패 중 신청 의도와 결과를 어떻게 안전하게 보존할 것인가? |
| 고려 대안 | 동기식 실패, 완전 비동기, 내구 접수+분리 판정 |
| 제안 | 내구 접수 후 제한 시간 판정, 미완료는 원인 있는 보류 |
| 근거 | `FR-002`, `FR-003`, `FR-004`, `IR-001`, `QR-010` |
| 결과 | 상태·재평가·대사·운영 관찰이 추가로 필요 |
| 재검토 조건 | 좌석 정책, 부하, 허용 지연, 외부 SLA 확인 또는 변경 |
`ADR-ENR-002`는 상태 조회 캐시의 사용 범위를 기록한다. 검색·설명용 읽기 성능은 캐시로 개선할 수 있지만 승인·좌석·최종 상태의 기준을 캐시가 대신하지 않도록 한다. 허용 지연, 무효화, 버전 비교와 장애 시 표시 방법이 정해지지 않으면 적용하지 않는다.
설계 추적 사슬은 다음처럼 양방향으로 관리한다.
화살표를 역으로 읽어 `DATA-DECISION-01`의 필드가 어떤 요구와 화면, 시험에 쓰이는지 설명할 수 있어야 한다. `CR-003`이 승인된다면 `RULE-005`의 정책만 고치는 것이 아니라 `RULE-004`의 수용량 불변조건을 재검증하고 판정 컴포넌트, 결정 데이터, 공개 사유, 동시 좌석 처리, 운영 감사와 회귀 시험까지 영향을 평가한다.
이 장에서 정리한 결과는 **요구사항-컴포넌트 매핑**, **컴포넌트 책임 카드**, **API·데이터·연계 계약 후보**, **품질 시나리오-전술표**, **설계 결정 기록 후보**다. 다음 장에서는 이 연결을 수용 기준과 시험 조건·시나리오·케이스로 내리고, 설계가 의도한 결과를 관찰 가능한 증거로 확인한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 33장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
기능·품질·데이터·인터페이스 요구를 컴포넌트 책임과 상호작용에 할당하고 설계 근거를 보존한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.