---
title: "24장. 인터페이스 요구사항"
description: "사용자·API·파일 인터페이스의 데이터 의미와 오류·재시도·중복·시간 제한·복구 책임을 계약으로 정리한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
시스템 경계를 넘는 계약과 실패 대응을 인터페이스 요구사항으로 어떻게 정의하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “시스템 경계를 넘는 계약과 실패 대응을 인터페이스 요구사항으로 어떻게 정의하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
시스템 경계에서 주고받는 값만 적는다고 인터페이스 계약이 완성되지는 않는다. 호출 순서, 오류 의미, 시간 제한, 재시도와 중복 처리 책임이 빠지면 각 참여 시스템은 정상 상황에서만 맞는 서로 다른 가정을 구현한다. 장애가 발생했을 때 그 빈칸이 데이터 손실과 이중 처리로 드러난다.
이 장에서는 사용자·API·파일 인터페이스별로 데이터 의미와 상호작용 책임을 정의한다. 오류·타임아웃·재시도·멱등성·복구 조건을 품질 및 데이터 요구와 연결하고, 특정 기술 형식에 성급히 고정되지 않는 검증 가능한 인터페이스 요구사항을 만든다.
### 1. 사용자 인터페이스
인터페이스 요구사항은 시스템 경계를 넘는 상호작용의 의미와 책임을 정의한다. 화면 배치나 API 스키마만이 아니라 누가 어떤 조건에서 무엇을 보내고, 상대가 무엇을 돌려주며, 오류·지연·중복·버전 차이에서 어떤 결과를 보장할지를 명세한다. 접점의 구현 문서가 있어도 업무 계약이 없으면 양쪽이 각자 “정상”인데 전체 흐름은 실패할 수 있다.
사용자 인터페이스 요구는 사람이 시스템의 정보와 기능을 인지·조작·이해하는 접점에 관한 요구다. 와이어프레임은 배치를 보여 주지만 상태 의미, 권한, 오류 결과, 접근성, 응답시간과 개인정보 노출을 모두 대신하지 않는다.
수강신청의 핵심 화면·대화 상태를 기능과 연결한다.
| 사용자 접점 | 필요한 입력·행동 | 제공할 결과 | 오류·경계 |
|---|---|---|---|
| 강좌 검색·상세 | 검색 조건·강좌 선택 | 강좌개설·신청 가능 정보 | 빈 결과·오래된 정보·권한 |
| 신청 준비 | 선택 목록·제출 확인 | 예상 충돌·학점·정책 안내 | 안내와 실제 판정 차이 |
| 신청 제출 | 의도 확인·중복 방지 | 접수 ID 또는 설명 가능한 비접수 | 마감 경계·재전송 |
| 결과 조회 | 자신의 신청 선택 | 승인·거절·보류, 사유·다음 행동 | 처리 중·권한·갱신 지연 |
| 취소 | 취소 대상·의도 확인 | 취소 상태와 후속 결과 | 기간 종료·동시 상태 변경 |
`UI-001` 후보:
> 수강신청 시스템은 학생에게 접수와 최종 판정을 구분해 제공하고, 승인·거절·보류 상태를 색상에만 의존하지 않는 이름·사유·신청 식별자와 가능한 다음 행동으로 제시해야 한다.
사용자 오류와 시스템 오류도 구분한다. 형식이 잘못된 입력은 수정할 위치와 기준을 알려 주고, 선수과목 미충족은 정상 업무 판정으로 설명하며, 규칙 서비스 장애는 사용자가 잘못한 것처럼 표시하지 않는다. 내부 예외·경로·민감한 정책 정보를 그대로 노출하지 않는다.
22장의 `QR-001`, `QR-006`, `QR-007`, `QR-011`을 사용자 인터페이스에 연결한다. [WCAG 2.2](https://www.w3.org/TR/WCAG22/) 적용 범위, 키보드·보조기술 시험, 오류 식별과 인증 접근성을 포함한다. 화면별 요구를 기능과 중복 복사하지 않고 접점 특유의 표현·상호작용 기준만 둔다.
### 2. 시스템 인터페이스
시스템 인터페이스는 수강신청 시스템과 인증·학사정보·규칙·알림 같은 외부 시스템 사이의 교환 계약이다. 내부 모듈 호출과 외부 책임 경계를 구분한다. 같은 조직 안 서비스라도 독립 배포·운영·버전·장애 책임을 가진다면 외부 인터페이스처럼 명세할 수 있다.
| 인터페이스 | 방향 | 교환 의미 | 수강신청 책임 | 상대 책임 |
|---|---|---|---|---|
| 인증 | 인증→수강신청 | 주체·세션·역할 문맥 | 권한 매핑·만료 처리 | 신원·인증 상태의 진실성 |
| 학사정보 | 학사→수강신청 | 학적·이수·강좌·일정 | 기준 시점·품질 검증 | 기준 데이터·정정·변경 통지 |
| 규칙 | 양방향 | 판정 입력, 결과·사유·버전 | 요청 상관·안전 보류 | 유효 규칙·버전·오류 의미 |
| 알림 | 수강신청→알림 | 통지 대상·내용·사건 | 판정과 통지 분리·개인정보 최소화 | 전달 결과·실패·중복 계약 |
계획에는 결제 연계도 예시로 언급되지만 지금까지 승인된 시스템 경계와 수강신청 흐름에는 결제 필요가 없다. 수강료 결제가 실제 신청 조건인지 확인되기 전에는 인터페이스를 발명하지 않는다. 범위에 들어오면 결제 승인·취소·중복·개인정보·보상 흐름을 독립 분석한다.
기존 `IR-001`은 규칙 서비스 실패 시 자동 승인 없이 보류할 안전 결과다. 다음 후보를 추가한다.
| ID | 인터페이스 요구 후보 | 상태 |
|---|---|---|
| `IR-001` | 규칙 서비스 실패·무효·시간 초과 시 보류하고 자동 승인하지 않는다 | 기존 요구 |
| `IR-002` | 인증 주체·역할·만료 정보를 권한 판정에 사용할 수 있게 교환한다 | 역할 매핑 확인 전 |
| `IR-003` | 학적·이수·강좌 데이터의 원천·기준 시점·변경을 식별한다 | 계약 확인 전 |
| `IR-004` | 규칙 판정에 요청 ID, 결과·사유, 규칙 버전과 유효성을 연결한다 | `ASM-002` 확인 전 |
| `IR-005` | 통지 요청과 전달 결과를 신청 판정과 구분해 추적한다 | 채널·SLA 확인 전 |
| `IR-006` | 파일 이관의 형식·검증·대사·재처리 계약을 정의한다 | 실제 파일 연계 범위 확인 전 |
교환 방식을 목적에 맞춰 선택한다.
| 방식 | 잘 맞는 상황 | 강점 | 놓치기 쉬운 위험 |
|---|---|---|---|
| 동기 API | 즉시 응답이 필요한 조회·명령 | 요청과 응답의 직접 상관 | 시간 초과 뒤 처리 여부 불확실 |
| 비동기 메시지 | 사건 통지·느슨한 시간 결합 | 생산자·소비자 독립, 완충 | 중복·순서·지연·스키마 진화 |
| 파일 | 대량·주기·이관 교환 | 대량 대사·재처리 용이 | 부분 오류·오래된 데이터·보안 |
| 사용자 인터페이스 | 사람이 판단·입력·확인 | 맥락 설명과 직접 피드백 | 접근성·오입력·상태 오해 |
하나의 업무 흐름에서 여러 방식을 조합할 수 있다. 신청 제출은 동기 API로 접수하고 판정은 비동기로 끝나며, 학생은 조회 화면에서 공식 상태를 확인하고 알림 메시지는 보조 채널이 될 수 있다. 방식이 늘수록 어느 결과를 기준으로 삼을지와 서로 모순될 때의 조정 규칙을 분명히 한다.
기술 선호로 방식을 정하지 않는다. 즉시 확정이 필요한지, 처리 시간과 부하, 데이터 양, 실패 시 재처리, 상대의 운영 능력, 개인정보와 감사 요구를 비교한다. 선택 근거와 배제한 대안을 결정 기록에 남기면 나중에 조건이 바뀌었을 때 재평가할 수 있다.
### 3. 외부기관 연계
외부기관 연계는 기술 연결뿐 아니라 조직 간 책임·승인·운영·변경·분쟁 계약을 포함한다. API가 정상 응답해도 상대 기관의 데이터 의미·갱신 주기·지원 시간이 다르면 업무 결과는 틀릴 수 있다.
외부기관마다 다음을 합의한다.
- 업무 목적과 처리할 데이터, 법적·정책 근거
- 데이터·규칙의 기준 원천과 정정 책임
- 서비스 시간, 성능·가용성, 계획 작업과 장애 통지
- 보안·개인정보 역할, 인증·권한, 사고 대응과 제공 종료
- 버전·변경 공지 기간, 호환 기간과 폐기 절차
- 시험 환경·시험 데이터·공동 수용 기준
- 장애·불일치·분쟁의 연락·에스컬레이션과 복구 책임
학사정보 원천에 오류가 있어 학생이 부당하게 거절되면 수강신청 시스템은 오류를 고칠 권한이 없을 수 있다. 그렇더라도 원천·기준 시점을 표시하고 정정 요청 경로와 재평가 상태를 제공해야 한다. 기관 경계는 사용자에게 책임을 떠넘기는 문구가 아니다.
연계가 종료되거나 제공자가 바뀔 때의 데이터 반환·파기, 미처리 요청, 미확정 보류와 감사 증거도 계약한다. 정상 운영 계약만 있고 종료 계약이 없으면 교체 시 개인정보·이력·업무 연속성 위험이 커진다.
### 4. API
API 요구는 호출 경로 목록보다 자원·행동의 의미, 요청·응답, 권한, 상태 코드, 오류·중복·시간·버전과 관측 책임을 정의한다. API 설명서는 계약을 기계가 읽을 수 있게 표현하지만 어떤 업무 결과가 필요한지 스스로 결정하지 않는다.
신청 제출 API의 논리 계약 후보를 보자.
| 항목 | 계약 후보 |
|---|---|
| 업무 목적 | 인증된 학생의 특정 강좌 신청을 접수하고 처리 상태를 연결 |
| 입력 | 요청 ID, 학생 문맥, 학기·강좌개설 ID, 제출 시각 문맥 |
| 성공 | 접수된 신청 ID와 현재 상태; 즉시 확정이면 결과·사유 포함 |
| 성공 외 결과 | 입력 오류, 권한 거절, 기간 밖, 규칙 미충족, 판정 보류를 구분 |
| 동일성 | 같은 업무 제출을 판별할 키와 적용 기간 |
| 권한 | 인증 주체와 학생·대리 역할의 데이터 범위 |
| 상관 | 요청·신청·판정·외부 호출 ID 연결 |
| 버전 | 지원 스키마·의미, 폐기 공지와 호환 기간 |
[RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html)은 HTTP 메서드·상태 코드 등 공통 의미를 정의한다. 기존 상태 코드의 의미를 업무 편의대로 바꾸지 않는다. 네트워크 시간 초과 후 클라이언트가 결과를 모르는 상황에서 POST를 무조건 재전송하면 중복 신청이 생길 수 있다. 안전한 조회와 업무 멱등성 계약을 함께 둔다.
[OpenAPI Specification 3.2.0](https://spec.openapis.org/oas/v3.2.0.html)은 2025년 9월 공개된 현행 언어 독립적 HTTP API 설명 형식이다. 경로·스키마·보안·응답 예를 기술하고 계약 검사에 활용하되, 상태 생명주기·업무 규칙·품질·데이터 원천은 `FR·QR·DR`에 연결한다. 생성된 문서와 실제 구현이 일치하는지도 지속 검증한다.
### 5. 파일 연계
파일 연계는 대량 기준정보·과거 데이터·정산·이관에서 쓰일 수 있다. 단순히 “CSV로 매일 전송한다”라고 쓰면 문자 인코딩, 시간, 완전성, 중복, 부분 오류, 보안과 재처리 책임이 빠진다.
파일 계약에는 다음을 둔다.
| 범주 | 정할 내용 |
|---|---|
| 식별 | 파일 유형·업무일·생성 주체·버전·고유 ID |
| 형식 | 문자셋, 구분자, 헤더, 날짜·시간대, 숫자·빈값·코드 |
| 구조 | 필수 열, 데이터 유형, 스키마 버전, 정렬 필요 여부 |
| 완전성 | 총건수·합계·해시·끝 표시와 전송 완료 조건 |
| 보안 | 전송·저장 보호, 접근 역할, 민감 필드 최소화 |
| 수신 | 도착 시각, 중복·누락·순서, 격리·바이러스 검사 |
| 오류 | 파일 전체 거절·행별 오류·부분 수용 기준과 오류 보고 |
| 재처리 | 동일 파일 ID 처리, 수정본 식별, 대사·승인 |
| 보존 | 원본·오류·처리 결과·임시본의 보존·파기 |
`IR-006` 후보:
> 승인된 파일 이관에서는 송신자와 수신자가 같은 스키마 버전·인코딩·시간 의미·무결성 검증을 사용하고, 수신 시스템은 파일 ID별 접수·검증·처리·거절·재처리 결과와 이관 대사를 추적할 수 있어야 한다.
부분 수용은 운영상 편리해도 참조 관계를 깨뜨릴 수 있다. 학생은 들어왔지만 해당 강좌나 규칙 기준정보가 누락되면 자동 판정을 시작하지 않는다. 어떤 오류에서 전체 중단하고 어떤 오류를 격리할지 데이터 의존성·위험으로 정한다.
### 6. 메시징
메시징은 발행자와 소비자가 시간적으로 분리된 사건·명령을 교환하는 방식이다. 큐·브로커 제품을 먼저 선택하기보다 메시지가 사실을 알리는 이벤트인지 행동을 요청하는 명령인지, 누가 결과에 책임지는지 정의한다.
알림 연계 후보를 예로 든다.
```text
신청 판정 확정 이벤트
- 이벤트 ID, 발생 시각, 신청 ID
- 상태와 공개 가능한 사유 참조
- 스키마 버전
- 개인정보 최소화된 수신 대상 참조
```
메시징 계약의 핵심 질문은 다음과 같다.
- 전달이 적어도 한 번, 많아도 한 번, 효과상 한 번 중 무엇을 목표로 하는가?
- 중복을 어느 ID와 기간으로 탐지하고 소비 결과를 어떻게 재사용하는가?
- 같은 신청의 판정·취소 사건 순서를 보장하거나 오래된 사건을 거부하는가?
- 처리 실패·독성 메시지를 어디에 격리하고 누가 재처리하는가?
- 스키마·의미 변경 때 생산자와 소비자가 얼마나 함께 운영되는가?
- 소비 지연·누적·유실을 어느 지표와 경보로 관찰하는가?
알림 메시지가 중복 전달돼도 신청 판정은 한 번이어야 한다. 반대로 신청 상태는 승인인데 통지가 유실될 수 있으므로 공식 상태 조회 경로를 유지한다. 전달 보장과 업무 효과의 정확히 한 번을 혼동하지 않는다.
[AsyncAPI 3.0.0](https://www.asyncapi.com/docs/reference/specification/v3.0.0)은 메시지 기반 API의 채널·동작·메시지 구조를 기술하는 공식 명세다. 문서 형식을 채우는 일과 중복·순서·보상이라는 업무 계약을 합의하는 일은 별개다.
### 7. 오류 처리
인터페이스 오류 처리는 송신자와 수신자가 같은 실패 의미와 후속 행동을 이해하게 한다. 모든 실패를 `500`, `ERROR`, `-1`로 반환하면 재시도 가능성·사용자 책임·업무 상태를 구분할 수 없다.
| 오류 분류 | 예 | 소비자 행동 후보 | 업무 상태 |
|---|---|---|---|
| 요청 형식·유효성 | 필수 필드 누락, 무효 강좌 ID | 수정 후 새 제출 | 미접수 또는 비승인 |
| 인증·권한 | 만료 세션, 다른 학생 데이터 | 재인증 또는 접근 중단 | 기존 신청 영향 없음 |
| 업무 규칙 | 선수 미충족, 학점 초과 | 사유 제공·선택 변경 | 거절 |
| 충돌·중복 | 이미 처리된 동일 요청 | 기존 결과 조회 | 기존 상태 유지 |
| 일시적 연계 실패 | 시간 초과, 서비스 불가 | 제한된 재시도·보류 | `IR-001` |
| 영구 계약 오류 | 지원하지 않는 버전·코드 | 격리·운영 수정 | 자동 재시도 금지 |
| 부분 처리 불확실 | 응답 전 연결 끊김 | 상태 조회·상관 ID 확인 | 확정 전 안전 상태 |
오류에는 안정된 업무 코드, 사람에게 제공할 안전한 설명, 상관 식별자, 재시도 가능성, 문서 참조와 관측 정보를 둔다. 내부 스택·쿼리·개인정보는 노출하지 않는다. 같은 코드의 의미를 버전마다 바꾸지 않는다.
[RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html)은 HTTP API에서 상태 코드만으로 부족한 오류 세부를 공통 형식으로 표현하는 표준을 제공한다. 이를 사용해도 업무 오류 유형·필드·공개 범위는 프로젝트가 정해야 한다. 사용자 화면의 메시지는 기계용 오류 객체를 그대로 번역하지 않고 과업과 다음 행동에 맞춘다.
### 8. 재시도
재시도는 일시적 실패에서 성공 가능성을 높이지만 요청이 실제 처리됐는지 모르면 중복 처리가 생길 수 있다. “3회 재시도”만 정하면 간격·대상 오류·동일성·최종 실패·전체 시간 예산이 없다.
재시도 계약에는 다음을 포함한다.
- 재시도 가능한 오류와 즉시 중단할 오류
- 같은 업무 요청임을 나타내는 식별자와 유지 기간
- 시도 간 지연·지수 증가·무작위 분산 등 부하 완화 정책
- 최대 횟수보다 중요한 전체 시간·요청 예산
- 각 시도의 상관관계와 최종 결과 조회 방법
- 최종 실패 때 보류·격리·운영 통지·사용자 안내
신청 제출의 응답이 끊기면 새 신청을 만드는 대신 요청 ID로 기존 신청 상태를 조회하거나 같은 ID의 처리 결과를 재사용할 수 있어야 한다. 멱등성을 어떻게 구현할지는 설계지만 `FR-004`의 복수 최종 판정·좌석 반영 금지를 만족해야 한다.
규칙 서비스 재시도도 신청 처리 제한시간 안에서만 한다. 서비스 장애 중 모든 인스턴스가 동시에 재시도하면 장애를 악화할 수 있다. 제한시간이 지나면 `IR-001`의 보류로 전환하고 늦은 응답을 현재 상태·판정 시도와 대조한다. 인증·권한·형식 오류는 재시도해도 성공하지 않으므로 자동 반복하지 않는다.
### 9. 타임아웃
타임아웃은 호출자가 더 기다리지 않고 다음 업무 상태로 전환하는 시간 경계다. 상대 처리의 취소나 실패를 자동으로 뜻하지 않는다. 호출자는 시간 초과했지만 상대는 뒤늦게 승인 효과를 만들 수 있으므로 불확실 상태와 늦은 응답을 다뤄야 한다.
시간 경계를 계층별로 본다.
| 경계 | 질문 |
|---|---|
| 사용자 전체 | 제출부터 접수·보류·확정 결과까지 얼마를 기다리는가? |
| 수강신청 처리 | 기능이 품질 목표 안에서 사용할 전체 시간 예산은? |
| 외부 호출 | 연결·응답 시작·전체 본문·처리 완료를 어떻게 구분하는가? |
| 재시도 | 한 시도와 모든 시도의 예산은? |
| 비동기 판정 | 보류 재평가와 최종 종료 기한은? |
`IR-001`의 “정한 시간”은 규칙 서비스의 단일 네트워크 타임아웃과 같지 않을 수 있다. 재시도·대체 경로를 포함한 판정 시간 예산이 끝났을 때 유효 결과가 없으면 자동 승인 없이 보류한다. 구체 값은 상태 조회 성능을 다루는 `QR-001`과 분리해 **판정 완료 시간 품질 요구 후보**로 등록하고, 가용성·사용자 영향·상대 계약을 함께 보고 승인한다.
늦은 응답은 요청·신청·판정 시도·규칙 버전과 현재 상태를 확인한 뒤 수용·무시·재평가한다. 이미 취소됐거나 새 규칙으로 재판정된 신청을 오래된 응답이 덮어쓰지 않게 한다. 타임아웃 사건과 후속 결과는 `DR-001` 이력으로 추적한다.
### 10. 인터페이스 계약
인터페이스 계약은 앞 절의 의미·데이터·품질·오류·운영 책임을 한 기준선으로 묶는다. API 문서, 메시지 스키마, 파일 명세, 화면 가이드 중 하나만을 계약 전체로 부르지 않는다. 각 산출물에서 기준으로 삼을 내용과 버전 관계를 정한다.
**규칙 서비스 계약 후보**
| 계약 항목 | 내용 후보 |
|---|---|
| 목적·범위 | 신청에 적용할 `RULE-001–RULE-005` 판정과 근거 제공 |
| 제공·소비 책임 | 규칙 책임 조직 / 수강신청 시스템 |
| 촉발 사건 | 유효 신청의 판정 시작·승인된 재평가 |
| 요청 | 요청·신청 ID, 학생·강좌 입력 참조, 기준 시점, 지원 계약 버전 |
| 응답 | 규칙별 결과·사유, 규칙 ID·버전·유효성, 판정 시각 |
| 성공 의미 | 계약·업무 검증을 통과한 판정이며 현재 신청에 적용 가능 |
| 오류 | 입력·권한·규칙 없음·무효 버전·일시 실패·시간 초과 구분 |
| 시간 | 전체 판정 예산 안의 호출·재시도·늦은 응답 처리 |
| 동일성·순서 | 판정 시도 ID, 중복 응답, 오래된 응답 거부 |
| 보안·개인정보 | 최소 학생 속성, 상호 인증·권한, 전송·기록 보호 |
| 품질 | 가용성·성능·정확성·변경 공지와 공동 시험 |
| 관측 | 상관 ID, 요청·결과·지연·오류 지표와 감사 증거 |
| 버전·변경 | 지원 버전, 호환 기간, 발효·폐기·롤백 절차 |
| 실패 업무 결과 | 유효 판정 없음→자동 승인 금지·보류 `IR-001` |
네 인터페이스의 오류·복구 매트릭스를 대조한다.
| 연계 | 실패 시 기능 영향 | 안전 결과 | 복구·대체 | 연결 요구 |
|---|---|---|---|---|
| 인증 | 신규 권한 판정 불가 | 요청 중단·재인증 | 인증 복구 후 새 시도 | `IR-002`, `QR-005` |
| 학사정보 | 자격·강좌 입력 불확실 | 자동 승인 없이 판정 중단/보류 후보 | 원천 정정·재평가 | `IR-003`, `DQ-001` |
| 규칙 | 규칙 결과·버전 불확실 | 보류·자동 승인 금지 | 제한 재시도·운영 조사 | `IR-001`, `IR-004` |
| 알림 | 결과 전달 실패 | 신청 판정 유지 | 재시도·공식 상태 조회 | `IR-005`, `UR-001` |
| 파일 이관 | 일부 데이터 불완전 | 컷오버 중단·격리 | 수정본·재처리·롤백 | `IR-006`, `DR-006` |
계약 검토에는 제공자·소비자·보안·운영·데이터 책임자와 시험 담당자가 참여한다. 예시 요청 하나가 성공하는지만 보지 않고 오래된 버전, 누락 필드, 중복·순서 역전, 시간 초과, 부분 장애, 권한 위반과 복구를 공동 시험한다.
계약이 검토 가능한지 다음 질문으로 확인한다.
- 요청·응답·메시지·파일의 각 필드가 23장 데이터 용어와 같은 의미인가?
- 정상 성공, 업무 거절, 판정 불가와 기술 장애를 구별하는가?
- 호출자가 응답을 받지 못했을 때 실제 처리 여부를 확인할 방법이 있는가?
- 중복과 순서 역전을 어느 식별자·버전·현재 상태로 판정하는가?
- 전체 사용자 시간 예산과 개별 호출·재시도 시간이 양립하는가?
- 생산자와 소비자의 가용성·성능·보안·복구 책임이 측정 가능한가?
- 개인정보는 목적에 필요한 최소 항목만 교환되고 로그·오류에도 보호되는가?
- 계약 변경과 폐기 때 호환 기간·통지·시험·롤백이 있는가?
- 운영자가 상관 ID로 한 업무 사건을 경계 전체에서 추적할 수 있는가?
계약 파일이 자동 검사를 통과해도 의미가 맞는지는 별도 확인해야 한다. 예를 들어 `status` 필드가 양쪽 모두 문자열이어도 한쪽은 접수 상태, 다른 쪽은 최종 판정을 뜻할 수 있다. 소비자 계약 시험, 스키마 검사, 보안 시험, 장애 주입과 실제 업무 사례 리뷰를 조합한다.
공동 시험의 결과와 미해결 차이는 계약 버전별 근거로 보존한다.
7부에서 네 요구 유형은 같은 결과를 다음과 같이 나누어 책임진다.
```text
학생이 신청을 제출한다
FR: 어떤 조건·규칙으로 어떤 상태·결과를 만들 것인가
QR: 어느 부하·장애·사용 맥락에서 어느 수준을 지킬 것인가
DR: 어떤 의미·원천·기준 시점·이력을 보존할 것인가
IR: 경계를 넘어 무엇을 교환하고 실패·중복·시간을 어떻게 처리할 것인가
```
| 기능 결과 | 기능 요구 | 품질 요구 | 데이터 요구 | 인터페이스 요구 |
|---|---|---|---|---|
| 신청 접수 | `FR-002`, `FR-004` | `QR-003`, `QR-005` | `DR-002`, `DR-004` | 인증·제출 API 계약 |
| 규칙 판정 | `FR-001` | `QR-003`, `QR-008` | `DR-001`, `DR-003` | `IR-003`, `IR-004` |
| 결과 조회 | `FR-003`, `UR-001` | `QR-001`, `QR-006`, `QR-007`, `QR-011` | `DR-001`, `DR-004`, `DR-005` | 사용자·조회 API 계약 |
| 판정 불가 | `IR-001` 기능 결과 | `QR-002`, `QR-010` | `DR-001`, `DR-004` | 오류·재시도·타임아웃 |
| 취소·복구 | `FR-005` | `QR-003`, `QR-010` | `DR-004`, `ASM-003` | 상태 조회·후속 사건 계약 |
이 표는 ID를 축약해서 복사하라는 뜻이 아니다. 각 셀의 기준 요구를 양방향으로 연결하고 변경 시 함께 검토한다. 기능이 추가되면 품질·데이터·인터페이스가 필요한지 묻고, 인터페이스 필드가 추가되면 목적·원천·개인정보·보존을 되짚는다.
이 장에서 정리한 결과는 인터페이스 목록, 규칙 서비스 계약표, 오류·복구 매트릭스와 `IR-002–IR-006` 후보다. 8부는 7부에서 만든 `FR·QR·DR·IR` 요구 집합이 잘 작성되었는지 검증하고, 실제 이해관계자의 필요와 목표를 충족하는지 확인한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 24장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
사용자·API·파일 인터페이스의 데이터 의미와 오류·재시도·중복·시간 제한·복구 책임을 계약으로 정리한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
학습 순서에 따라 다음 판단 주제로 이어갑니다.