---
title: "23장. 데이터 요구사항"
description: "학생·강좌·신청·판정 데이터의 의미와 원천, 품질, 생명주기, 이력, 개인정보와 이관 책임을 정의한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
데이터의 의미·품질·생명주기·보호 책임을 요구사항으로 어떻게 다루는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “데이터의 의미·품질·생명주기·보호 책임을 요구사항으로 어떻게 다루는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
기능이 올바르게 동작하려면 처리하는 데이터의 의미와 책임이 먼저 분명해야 한다. 같은 ‘신청 상태’도 화면 표시, 업무 판정, 이력 보존에서 다른 뜻으로 쓰일 수 있고, 원천과 갱신 권한이 불명확하면 여러 시스템이 서로 다른 사실을 갖게 된다. 데이터 요구는 테이블 설계보다 앞선다.
이 장에서는 학생·강좌·신청·판정 데이터의 정의, 원천, 식별자, 품질과 생명주기를 정리한다. 이력·보존·개인정보·이관 책임을 기능 및 인터페이스 요구와 연결해, 논리적 의미를 보존하면서 설계 대안을 열어 두는 데이터 요구사항을 다룬다.
### 1. 데이터의 의미
데이터 요구사항은 시스템이 어떤 데이터를 어떤 의미로 생성·사용·변경·보존·삭제하고, 어느 품질과 보호 수준을 유지해야 하는지 정의한다. 데이터 모델의 엔터티와 필드만 나열하거나 “DB에 저장한다”라고 쓰는 것으로 충분하지 않다. 같은 `상태`, `학점`, `정원`도 기준 시점·단위·원천·업무 정의가 다르면 판정 결과가 달라진다.
수강신청의 핵심 데이터 용어를 먼저 고정한다.
| 용어 | 의미 후보 | 식별·기준 | 혼동할 대상 |
|---|---|---|---|
| 학생 | 대상 학기에 신청 권한을 평가받는 개인 역할 | 학생 ID와 학기·학적 상태 | 로그인 계정, 사용자 세션 |
| 강좌 | 교육과정상의 과목 정의 | 과목 코드·버전 | 학기별 강좌개설 |
| 강좌개설 | 특정 학기·분반·시간·정원을 가진 신청 대상 | 학기+개설 ID | 강좌, 화면 카드 |
| 신청 요청 | 학생이 제출한 하나의 업무 사건 | 요청 ID·수신 시각 | 신청 객체, 승인 |
| 신청 | 접수부터 승인·거절·보류·취소를 거치는 객체 | 신청 ID | 수강등록 원장 |
| 판정 | 입력 기준선과 규칙 버전으로 낸 결과 | 판정 ID·시각 | 현재 상태만의 표시 |
| 가용 좌석 | 승인된 정원 정책상 새 승인이 가능한 수량 | 강좌개설·좌석 유형·기준 시점 | 단순 정원-신청 수 |
`대기순번`은 사례 계획에 있지만 `RULE-005`의 대기·배정 정책이 아직 승인되지 않았다. 순번의 의미, 같은 순번 가능성, 갱신 사건과 좌석 점유를 확정 데이터처럼 정의하지 않는다. 먼저 정책 결정과 시스템 범위를 확인한다.
데이터 용어에는 정의, 데이터 유형보다 업무 의미, 허용값·단위, 기준 시점·시간대, 원천, 민감도, 관계, 품질 규칙과 사용 기능을 붙인다. 20장의 도메인 모델과 용어집을 기준 정보로 두고 화면·API·저장소가 같은 의미를 참조하게 한다.
기존 `DR-001`은 신청 판정 기록을 요구한다. 이 장에서는 다음 후보로 데이터 책임을 확장한다.
| ID | 데이터 요구 후보 | 상태 |
|---|---|---|
| `DR-001` | 학생·강좌 ID, 요청 시각, 결과, 사유, 규칙 버전과 최종 상태 변경을 판정 기록에 둔다 | 기존 요구 |
| `DR-002` | 신청과 요청·판정·상태 변경을 고유 식별자로 연결한다 | 후보 |
| `DR-003` | 학생·강좌·규칙 입력의 원천과 기준 시점을 판정에 연결한다 | `ASM-002` 확인 전 |
| `DR-004` | 현재 상태와 변경 이력이 모순되지 않게 유지한다 | 후보 |
| `DR-005` | 데이터별 목적·접근·보존·파기 기준을 적용한다 | 법·정책 확인 전 |
| `DR-006` | 이관 전후 건수·관계·핵심 값과 이력을 대사할 수 있게 한다 | 이관 범위 확인 전 |
데이터 요구 하나를 작성할 때 다음 속성을 함께 검토한다.
| 속성 | 작성 질문 | 빠졌을 때의 위험 |
|---|---|---|
| 업무 정의 | 이 값은 현실의 무엇을 뜻하는가? | 같은 이름의 다른 의미 사용 |
| 식별·관계 | 무엇을 유일하게 구분하고 무엇과 연결되는가? | 중복·고아·잘못된 결합 |
| 원천·책임 | 누가 생성·정정·승인하며 어떤 원천을 기준으로 삼는가? | 시스템 간 책임 떠넘김 |
| 기준 시점 | 언제의 값을 어느 시간대·버전으로 보는가? | 존재한 적 없는 입력 조합 |
| 허용값·단위 | 범위·코드·미상·0·빈값을 어떻게 구분하는가? | 기본값으로 품질 결함 은폐 |
| 생명주기 | 어떤 사건에 생성·변경·종료되는가? | 삭제와 취소, 정정과 덮어쓰기 혼동 |
| 품질·정합성 | 어느 목적에서 무엇과 일치해야 하는가? | 정확해 보여도 판정에 부적합 |
| 보호·접근 | 개인정보·민감도와 역할별 범위는? | 과도한 수집·노출·권한 |
| 보존·파기 | 어떤 근거로 얼마 동안 어떻게 유지·종료하는가? | 무기한 보존 또는 조기 삭제 |
| 검증 | 어떤 표본·원천·공식으로 합격을 판정하는가? | “데이터가 정상”이라는 주관 판정 |
속성은 한 문장에 모두 넣지 않는다. 데이터 용어사전, 소유권표, 생명주기·상태 모델, 품질 규칙, 개인정보 처리 목록과 이관 대사표로 나누고 `DR` ID에서 참조한다. 어느 산출물을 정의와 현재 상태의 기준으로 삼을지 정해야 복사본 간 불일치를 막을 수 있다.
검토자는 표본 데이터만 보고 판단하지 않는다. 정상값뿐 아니라 누락·중복·지연·잘못된 관계·오래된 버전과 권한 밖 조회 사례를 만들어 의미와 생명주기가 요구대로 유지되는지 확인한다.
### 2. 데이터 소유권
데이터 소유권은 누가 데이터의 의미·품질·접근·변경·보존에 관한 결정을 승인하고 책임지는지 정하는 거버넌스 개념이다. 법적 소유물처럼 마음대로 사용할 권리를 뜻하지 않는다. 개인정보의 정보주체, 법령상 개인정보처리자, 업무 데이터 책임자, 기술 보관자와 실제 원천 시스템을 구분한다.
| 데이터 | 업무 의미·정책 책임 후보 | 기준 원천 | 기술 보관·처리 | 확인할 사항 |
|---|---|---|---|---|
| 학생 학적·이수 | 학사 업무 책임 조직 | 학사정보 시스템 | 학사·수강신청 운영팀 | 정정·최신성 SLA |
| 강좌개설·일정 | 교무·교육과정 책임 조직 | 강좌 원장 | 학사정보 시스템 | 발효 시각·폐강 반영 |
| 학사 규칙 | 정책 결정 권한자 | 승인된 규칙 기준선 | 규칙 서비스 | `ASM-002`, 버전 제공 |
| 신청·판정 | 수강신청 업무 책임자 | 수강신청 시스템 | 제품 운영팀 | 정정·보존·감사 책임 |
| 인증 주체·역할 | 신원·접근관리 책임 조직 | 인증 서비스 | 인증 운영팀 | 역할 매핑·폐기 |
소유권표에는 `정의 승인`, `원천 생성`, `정정 승인`, `품질 감시`, `접근 승인`, `보존·파기 승인`을 역할별로 나누는 편이 정확하다. 한 사람을 “데이터 오너”로만 적으면 실제 결정을 누가 하는지 알 수 없다.
원천 시스템이 외부라고 수강신청 시스템의 책임이 사라지지 않는다. 소비자는 필요한 품질·최신성을 계약으로 요구하고, 불충분한 데이터로 자동 승인하지 않으며, 오류의 영향을 설명해야 한다. 학생이 학적 오류를 발견했을 때 어느 원천에서 누가 정정하고 신청을 재평가하는지도 흐름으로 연결한다.
### 3. 데이터 생성
데이터 생성 요구는 어떤 사건에서 누가 어떤 식별자와 필수 값을 만들며 중복·부분 실패를 어떻게 막는지 정한다. 사용자가 신청 버튼을 누른 순간, 요청이 시스템 경계에 도착한 순간, 유효성 검사를 통과한 순간 중 언제 `신청`이 생성되는지에 따라 추적과 재시도가 달라진다.
수강신청 생성 후보를 분리한다.
`DR-002` 후보:
> 유효한 신청 요청을 접수하면 수강신청 시스템은 요청 ID, 신청 ID, 학생·강좌개설 ID, 수신 시각과 최초 상태 변경을 서로 추적 가능하게 생성해야 한다.
식별자는 전역 유일성뿐 아니라 재시도·지원·감사에 안전하게 노출할 수 있는지 검토한다. 순차 번호만 노출해 다른 학생의 신청을 추측하게 해서는 안 된다. 어떤 생성 기술을 쓸지는 설계지만 충돌·중복 시 관찰 결과는 요구다.
생성과 승인도 구분한다. 요청과 신청 객체를 먼저 기록해야 판정 실패를 추적할 수 있다. 승인 때만 신청을 만들면 거절·보류·반복 제출 이력이 사라져 `G-01`과 `DR-001`을 지원하기 어렵다.
### 4. 데이터 변경
데이터 변경 요구는 누가 어느 상태의 값을 어떤 사건·검증·동시성 규칙으로 바꾸며 이전 값을 어떻게 남기는지 정의한다. 단순 CRUD의 `update`가 아니라 업무 상태 전이와 기준정보 변경의 의미를 다룬다.
| 변경 대상 | 허용 사건 후보 | 권한·검증 | 후속 영향 |
|---|---|---|---|
| 신청 상태 | 판정·취소·승인된 정정 | 상태 전이·수행 주체 | 결과 조회·정원·통지 |
| 가용 좌석 | 승인·취소·정책 배정 | 강좌·좌석 유형·동시성 | 다른 신청 판정 |
| 판정 사유 | 새 판정·정정 | 규칙 버전·원인 | 학생 안내·감사 |
| 학생 학적 | 원천 시스템 정정 | 학사 권한 | 미확정 신청 재평가 후보 |
| 규칙 | 승인된 정책 변경 | 발효일·버전·결정자 | 기능·시험·이력 영향 |
상태를 직접 덮어쓰는 관리 기능은 피한다. 정정은 이전 판정, 정정 사유, 승인자, 새 판정과 상태 전이를 남기는 별도 사건이어야 한다. 이미 학생이 본 결과나 후속 정원 배정에 미친 영향도 추적한다.
동시 변경에서는 “마지막 저장이 이긴다”가 업무적으로 맞는지 확인한다. 마지막 좌석에 신청과 취소가 겹칠 때 어느 기준 시점과 불변식을 지킬지 필요하다. 충돌 탐지, 직렬화, 재평가 같은 설계와 무관하게 정원 초과·모순 상태 금지 `QR-003`을 충족해야 한다.
### 5. 데이터 삭제
삭제는 화면에서 보이지 않게 하는 것, 업무상 효력을 종료하는 것, 식별자와 내용을 물리적으로 제거하거나 복구 불가능하게 만드는 것을 구분해야 한다. 신청 취소는 삭제가 아니라 `승인→취소` 상태 전이다. 취소 이력을 지우면 정원·판정·감사 재현이 깨진다.
삭제 요구에 묻는다.
- 어떤 목적과 근거가 끝나면 삭제·비식별화·보관 전환하는가?
- 삭제 대상에 복제본, 검색 색인, 분석 저장소, 로그, 백업이 포함되는가?
- 관계 데이터와 법적 보존 의무가 충돌하면 어떤 제한 처리를 하는가?
- 삭제 요청과 실행·예외 결과를 누가 확인하는가?
- 삭제 뒤 통계·감사에 필요한 최소 정보는 어떤 근거로 남기는가?
`DR-005` 후보는 항목별 정책을 참조해 표현한다.
> 보존 목적과 기간이 종료되거나 승인된 파기 사건이 발생하면, 수강신청 시스템은 적용 정책에 따라 대상 데이터를 삭제·비식별화 또는 접근 제한 상태로 처리하고 실행 범위와 결과를 추적해야 한다.
“7년 보존 후 삭제”처럼 근거 없는 공통 숫자를 만들지 않는다. 신청 기록, 보안 접속기록, 지원 문의, 임시 파일과 백업은 목적·법적 근거·복구 요구가 다르다. 적용 시점의 법·조직 정책과 분쟁·감사 필요를 승인받는다.
### 6. 데이터 보존
보존 요구는 데이터를 얼마 동안 어떤 형태·품질·접근성·보호 수준으로 유지하고 종료 때 무엇을 할지 정의한다. 백업 주기와 같은 기술 운영만을 뜻하지 않는다. 판정을 재현하려면 데이터가 남아 있어도 규칙 버전과 의미를 읽을 수 있어야 한다.
| 데이터 집합 | 보존 목적 후보 | 품질·접근 요구 | 종료 행동 |
|---|---|---|---|
| 신청·상태 변경 | 학생 조회·업무 처리 | 현재 상태·이력 일치 | 정책상 삭제·제한 |
| 판정 입력·규칙 버전 | 설명·분쟁·감사 | 당시 의미 재현 | 최소화·보존 근거 확인 |
| 보안 사건·접속 기록 | 오용 탐지·조사 | 무결성·제한 접근 | 안전 파기 |
| 알림 전달 기록 | 통지 운영 확인 | 판정 원천과 구분 | 목적 종료 후 파기 |
| 백업·복구 사본 | 장애 복구 | 암호화·복원 시험 | 보존 주기별 만료 |
보존 기간 중 형식이 바뀌면 읽기 가능성도 유지해야 한다. 규칙 엔진이 교체돼도 과거 규칙 버전의 이름·입력·결론을 설명할 수 있어야 한다. 모든 과거 실행 코드를 영구 보관하라는 뜻은 아니며, 감사 질문에 필요한 증거와 재현 수준을 승인한다.
운영 데이터와 백업의 삭제 시점이 다를 수 있다. 즉시 백업 내부 한 건을 물리 삭제하기 어려운 경우 접근 차단, 만료 주기, 복원 시 재삭제 절차와 법적 허용을 확인한다. 기술 편의로 법·정책 의무를 임의 해석하지 않는다.
### 7. 데이터 품질
데이터 품질은 데이터가 특정 사용 목적에 적합한 정도다. 정확성만으로 충분하지 않다. 신청 판정에서는 완전성, 일관성, 현재성, 유효성, 식별 가능성과 원천 신뢰가 함께 영향을 준다. [ISO/IEC 25012:2008](https://www.iso.org/standard/35736.html)은 구조화된 데이터의 품질 요구·측정·평가에 사용할 수 있는 데이터 품질 모델이며 2025년 재확인되어 현행판이다.
목적별 품질 규칙을 만든다.
| 규칙 ID | 대상·목적 | 품질 규칙 후보 | 판정 실패 결과 |
|---|---|---|---|
| `DQ-001` | 선수과목 판정 | 학생 ID·학기와 이수 과목·성적 상태가 완전하고 원천과 일치 | 자동 승인 없이 판정 불가 |
| `DQ-002` | 정원 판정 | 승인·취소·예약 좌석 변화가 기준 시점에 일관됨 | 재확인·안전 중단 |
| `DQ-003` | 규칙 적용 | 규칙 ID·버전·발효일·적용 범위가 식별됨 | `IR-001` 보류 |
| `DQ-004` | 결과 설명 | 상태와 사유가 같은 판정·규칙 버전을 참조 | 결과 제공 전 복구 |
| `DQ-005` | 감사 | 사건 시각·주체·이전/이후 상태가 연결됨 | 감사 결함·운영 조사 |
“정확도 99%”처럼 분모와 판정 근거가 없는 수치는 피한다. 어느 기간의 어떤 레코드를 기준 원천과 비교하고, 누락·오류·지연을 어떻게 계산하는지 적는다. 드문 데이터 오류가 대량 오승인을 만들 수 있다면 평균 비율보다 고위험 규칙의 완전성을 별도 검증한다.
품질 결함을 조용히 기본값으로 채우지 않는다. 학적 누락을 미이수로 간주하면 정상 거절처럼 보이고, 정원 값 누락을 0으로 간주하면 장애가 숨는다. `알 수 없음`, `판정 불가`, 실제 업무상 0을 구분한다.
### 8. 데이터 정합성
데이터 정합성은 서로 관련된 데이터가 정의된 제약과 기준 시점에서 모순되지 않는 상태다. 데이터 품질의 한 관점이지만 수강신청의 동시성과 여러 원천 때문에 별도로 다룬다.
핵심 정합성 규칙 후보는 다음과 같다.
- 하나의 신청 현재 상태는 가장 최근 유효 상태 변경과 일치한다.
- 승인된 신청은 정책상 해당하는 좌석 반영과 연결된다.
- 취소된 신청은 승인 상태로 조회되지 않으며 후속 정원 효과가 이력과 일치한다.
- 판정 결과의 학생·강좌·규칙 버전은 같은 입력 기준선을 참조한다.
- 같은 학생·강좌·학기의 유효 승인 중복은 정책이 금지한 범위에서 존재하지 않는다.
- 집계된 가용 좌석과 원천 상태가 다르면 어느 값을 기준으로 삼을지 식별한다.
`DR-004` 후보:
> 수강신청 시스템은 신청 현재 상태, 상태 변경 이력, 판정 결과와 좌석 반영이 승인된 정합성 규칙을 만족하게 유지하고, 불일치를 탐지하면 확정 결과 제공을 제한한 뒤 원인과 복구 상태를 기록해야 한다.
강한 실시간 정합성과 성능·가용성은 긴장할 수 있다. 오래된 읽기를 허용한다면 어느 기능에서 얼마 동안인지, 화면에 어떻게 알리고 최종 판정에는 사용할 수 있는지 정한다. “최종적 일관성”이라는 기술 용어만으로 업무 허용치를 대신하지 않는다.
### 9. 기준정보
기준정보는 여러 기능과 시스템이 공통으로 참조하는 상대적으로 안정된 코드·분류·식별·정책 데이터다. 강좌 코드, 학기, 학생 유형, 상태·사유 코드, 규칙 ID와 버전이 후보가 된다. 기준정보의 오류는 많은 신청에 같은 결함을 전파하므로 변경 통제가 중요하다.
| 기준정보 | 기준 원천 후보 | 버전·발효 | 소비 영향 |
|---|---|---|---|
| 학기·신청 기간 | 학사 일정 | 시작·종료·시간대 | 접수 허용·거절 |
| 강좌개설·분반 | 학사정보 시스템 | 학기·변경 시각 | 검색·신청·정원 |
| 학생 유형·학점 한도 | 학사 정책 | 발효 학기·예외 | `RULE-002` |
| 신청 상태·사유 코드 | 수강신청 업무 책임자 | 호환 버전 | UI·API·감사·통계 |
| 규칙 ID·버전 | 정책/규칙 책임자 | 발효·종료 시점 | `RULE-001–RULE-005` |
기준정보 요구에는 생성·변경 승인, 배포 시점, 이전·새 버전의 동시 사용, 하위 호환, 무효 코드 처리와 영향 통지를 둔다. 코드값만 맞고 설명·업무 의미가 달라지면 상호운용에 실패한다.
신청 처리 중 기준정보가 바뀌는 경우도 정한다. 요청 접수 시 버전으로 끝까지 판정할지, 승인 직전 최신 버전을 재확인할지, 발효 시각 이전 요청을 재평가할지는 정책 문제다. `DR-003`으로 당시 기준선을 연결해야 결과를 설명할 수 있다.
### 10. 이력
이력은 중요한 데이터가 시간에 따라 어떻게 바뀌었는지 재현하는 기록이다. 애플리케이션 로그와 다르다. 로그는 진단을 위해 구현 사건을 남길 수 있고 이력은 업무 질문에 답할 신뢰할 수 있는 증거다. 로그 수준을 바꾸거나 서버가 교체돼도 신청의 상태 변경 이력은 사라져서는 안 된다.
`DR-001`과 `DR-002–DR-004`를 결합한 이력 구조는 다음과 같다.
이력은 추가만 가능한 사건으로 관리할 수 있지만 구현 방식은 설계다. 요구에서는 원래 값을 보존하고 정정도 새 사건으로 남기며, 시각 순서와 상관관계를 검증할 수 있어야 한다고 정한다. 시스템 시계가 다르면 시각만으로 순서를 확정할 수 없으므로 사건 ID·버전·순번 등 논리적 연결이 필요할 수 있다.
누가 이력을 볼 수 있는지도 구분한다. 학생에게 공개할 설명, 지원 담당자의 업무 이력, 감사자의 증거, 개발자의 진단 로그는 범위와 민감도가 다르다.
### 11. 개인정보
개인정보 요구는 22장의 개인정보 보호 품질을 데이터 항목과 생명주기로 구체화한다. “개인정보를 암호화한다”는 한 통제만으로 목적·최소화·접근·제공·보존·파기·권리 대응을 다루지 못한다.
개인정보 처리 목록에 최소한 다음을 기록한다.
| 필드 | 질문 |
|---|---|
| 데이터 항목·분류 | 학생 ID, 학적, 이수, 신청·접속 정보 중 무엇인가? |
| 처리 목적·근거 | 신청 판정·지원·감사에 왜 필요한가? |
| 수집·원천 | 학생 직접, 학사정보, 인증 서비스 중 어디인가? |
| 이용·제공 | 어떤 기능·역할·외부 서비스가 쓰는가? |
| 보존·파기 | 목적·법적 근거별 기간과 종료 행동은? |
| 보호 | 전송·저장·접근·마스킹·기록은? |
| 정보주체 요청 | 열람·정정·삭제·처리 제한 요청을 어떻게 연결하는가? |
거절 사유를 상세히 보여 주는 것은 설명 가능성을 높이지만 화면 공유·알림 노출에서 학적 정보가 과도하게 드러날 수 있다. 학생 본인 화면, 푸시 미리보기, 지원 담당자 화면의 공개 범위를 나눈다. 인증 토큰·비밀번호·민감한 원문을 판정 이력에 남기지 않는다.
대한민국에서 실제 적용할 때는 [개인정보 보호법 현행·향후 시행본](https://law.go.kr/unSc.do?query=%EA%B0%9C%EC%9D%B8%EC%A0%95%EB%B3%B4+%EB%B3%B4%ED%98%B8%EB%B2%95)과 [개인정보보호위원회의 최신 안전성 확보조치 기준](https://pipc.go.kr/np/cop/bbs/selectBoardList.do?bbsId=BS216&etc1=%EA%B3%A0%EC%8B%9C&mCode=G010020040)을 적용 날짜와 처리자 유형에 맞춰 확인한다. 이 장은 법률 자문이나 고정 보존표가 아니다.
### 12. 데이터 이관
데이터 이관은 기존 원천의 데이터를 새 시스템·구조·환경으로 옮기면서 의미·관계·품질·보호와 업무 연속성을 보존하는 활동이다. 파일 복사 성공 건수만으로 완료되지 않는다. 변환 규칙, 누락·중복, 참조 무결성, 이력 순서, 컷오버 중 변경과 되돌림을 검증한다.
수강신청 이관 범위를 분류한다.
- 학생·강좌·기준정보: 기준 원천에서 다시 동기화할 수 있는가?
- 활성 신청·보류: 컷오버 순간 상태와 좌석을 어떻게 고정·재확인하는가?
- 과거 판정·상태 이력: 규칙 버전과 사유 의미를 보존하는가?
- 사용자·권한 매핑: 이전 역할을 새 권한에 과도하게 승계하지 않는가?
- 감사·보안 기록: 법·정책상 필요한 범위와 무결성을 유지하는가?
`DR-006` 후보:
> 이관 전후 수강신청 데이터는 승인된 매핑·변환 규칙에 따라 건수, 고유 식별자, 필수 값, 관계, 상태·좌석 불변식과 핵심 표본 판정을 대사할 수 있어야 하며, 불일치가 합의된 허용 기준을 넘으면 컷오버를 중단하거나 승인된 되돌림 절차를 수행해야 한다.
검증은 총건수만 비교하지 않는다. 상태별·학기별·학생 유형별 건수, 고아 참조, 중복 ID, 잘린 문자·시간대, 규칙 버전, 마지막 좌석과 보류 표본을 본다. 개인정보는 이관 시험 환경에서도 실제 운영과 같은 최소화·접근·파기 기준을 가져야 한다.
데이터 생명주기 표로 이 장을 마무리한다.
| 데이터 | 생성 | 변경 | 종료·삭제 | 품질·정합성 | 책임·추적 |
|---|---|---|---|---|---|
| 신청 | 유효 요청 접수 | 판정·취소·정정 | 보존 후 정책상 처리 | 상태·좌석 불변식 | `DR-002`, 신청 책임자 |
| 판정 | 규칙 평가 | 재평가·정정은 새 판정 | 근거별 보존 | 입력 기준·버전 완전성 | `DR-001`, `DR-003` |
| 상태 이력 | 각 전이 | 원기록 덮어쓰기 금지 | 보존 정책 | 현재 상태와 일치 | `DR-004` |
| 기준정보 | 책임 조직 승인 | 버전·발효 사건 | 폐기·호환 종료 | 코드·의미·버전 | 규칙·학사 책임자 |
| 개인정보 | 승인된 목적 수집·연계 | 원천 정정·권리 요청 | 목적별 파기·제한 | 정확성·최소성 | `DR-005`, 개인정보 책임자 |
| 이관 데이터 | 추출·변환 | 오류 정정·재실행 | 임시본 안전 파기 | 전후 대사 | `DR-006`, 이관 승인자 |
이 장에서 정리한 결과는 데이터 용어사전, 소유권표, 생명주기표, `DQ-001–DQ-005` 품질 규칙과 `DR-002–DR-006` 후보다. 다음 장에서는 이 데이터를 사용자 화면, 학사·인증·규칙·알림 경계에서 어떤 계약으로 교환하고 오류·재시도·시간 제한을 어떻게 다룰지 정의한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 23장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
학생·강좌·신청·판정 데이터의 의미와 원천, 품질, 생명주기, 이력, 개인정보와 이관 책임을 정의한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
학습 순서에 따라 다음 판단 주제로 이어갑니다.