---
title: "44장. 프로젝트 시작"
description: "흩어진 수강신청 사례를 프로젝트 브리프와 이해관계자·범위·가정·위험으로 다시 조립해 시작 조건을 만든다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
수강신청 프로젝트의 문제·목표·범위·책임자를 어떻게 시작 시점에 정렬하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “수강신청 프로젝트의 문제·목표·범위·책임자를 어떻게 시작 시점에 정렬하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
앞 장들에서 사용한 수강신청 사례는 기법을 설명하기 위해 여러 위치에 나뉘어 있었다. 실제 프로젝트에서는 흩어진 문제·요구·규칙·가정과 위험을 하나의 시작 맥락으로 다시 조립해야 조사 범위와 책임을 정할 수 있다. 13부는 이 자료를 시간 순서의 종합 사례로 연결한다.
이 장에서는 기존 사례의 사실과 미확정 내용을 모아 프로젝트 브리프를 만든다. 문제, 목표, 이해관계자, 범위, 제약, 가정, 위험과 열린 질문을 구분해 이후 도출·분석·명세·설계·추적·변경 활동이 함께 참고할 공통 출발점을 마련한다.
### 1. 프로젝트의 사실 수준을 정한다
먼저 사례의 사실 수준을 분명히 해야 한다. 이 책에는 실제 대학의 운영 로그, 학칙 원문, 계약, 이해관계자 인터뷰와 승인 기록이 제공되지 않았다. 따라서 아래 프로젝트 브리프와 회의·시험 기록은 교육용 구성이다. `G-01`, `BR-001`, `FR-001–FR-005`, `QR-001–QR-011` 같은 ID가 여러 장에서 일관되게 사용됐어도 실제 기준선이 승인됐다는 뜻은 아니다. 예제의 완결성을 위해 빈칸을 사실처럼 채우지 않는다.
프로젝트가 처음 받은 요청을 “수강신청이 불편하니 시스템을 개선해 달라”라고 가정해 보자. 이 문장은 문제의 존재를 알리는 출발점이지만 투자·설계·인수의 기준으로는 부족하다. 불편이 검색인지, 판정 지연인지, 결과 표현인지, 정책 공정성인지 알 수 없고 누가 얼마나 피해를 겪는지도 모른다. 화면 개편, 서버 증설, 알림 추가 같은 해법을 먼저 고르면 원인이 다른데도 큰 비용을 쓸 수 있다.
첫 작업은 요청에서 관찰 사실, 증상, 원인 가설과 해법 제안을 나누는 일이다.
| 구분 | 초기 기록 후보 | 현재 상태 |
|---|---|---|
| 관찰 사실 | 학생지원 부서에 신청 결과를 확인하는 문의가 들어온다는 진술 | 실제 건수·기간·표본 미확인 |
| 증상 | 학생이 결과를 알지 못해 다시 제출하거나 문의할 수 있음 | 인터뷰·행동 로그 필요 |
| 업무 영향 | 운영자가 초기 30분에 중복·불명 요청을 수동 확인할 가능성 | 사건 정의·처리 시간 기준선 없음 |
| 원인 가설 | `ASM-001`: 결과를 알 수 없는 상태가 반복 제출과 수동 재처리의 주요 원인 | 미확인 |
| 해법 제안 | 상태 화면, 접수 식별자, 알림, 서버 증설 | 필요·효과·위험 분석 전 |
| 정책 쟁점 | 정원·우선 배정과 보류 좌석 처리 | `ISS-001`, `ASM-003` 미해결 |
이 구분을 바탕으로 문제 정의 0.1을 작성한다.
> 수강신청 피크 시간에 일부 학생은 신청 의도가 접수됐는지와 판정이 끝났는지 구분하기 어렵고, 실패·지연 상황에서 현재 상태와 다음 행동을 알기 어렵다는 문제가 제기됐다. 이 때문에 반복 제출·문의와 수동 재처리가 생긴다는 가설이 있으나 실제 빈도·원인·집단별 영향은 확인되지 않았다. 잘못된 중복 효과, 좌석 불일치와 개인정보 노출 없이 상태를 설명하고 회복할 수 있는지 조사한다.
이 문장은 “시스템이 느리다”보다 넓고 “상태 화면을 만든다”보다 중립적이다. 접수와 승인, 시스템 처리 보류와 좌석 대기명단을 구분하고 안전·개인정보 보호를 문제 경계에 포함한다. 동시에 `ASM-001`이 틀릴 수 있음을 남긴다. 로그에서 반복 제출이 거의 없거나 주원인이 인증 만료로 드러나면 목표와 범위를 다시 정해야 한다.
두 번째 작업은 목표 상태와 성공 기준을 정하는 일이다. 목표 `G-01`은 다음 학기에 결과를 알 수 없어 발생하는 반복 제출과 수동 재처리를 줄이고 신청을 설명·회복 가능하게 만드는 방향이다. 목표는 기능 목록이 아니라 변화 후 얻으려는 상태다. `BR-001`의 “첫 30분 수동 재처리 50% 감소”는 측정 가능한 형태를 보여 주지만 실제 기준선·사건 정의·투자 승인자가 없는 후보 수치다.
프로젝트 브리프에는 목표와 측정 계약을 다음처럼 둔다.
| 항목 | 후보 정의 | 결정 전 필요한 증거 |
|---|---|---|
| 목표 | `G-01`: 결과를 알 수 없는 상태와 관련한 반복 제출·수동 재처리를 줄이고 설명·회복 가능하게 함 | 학생·운영자가 같은 문제를 확인하는가? |
| 업무 성과 | `BR-001`: 다음 학기 첫 30분 수동 재처리를 이전 학기 대비 50% 줄임 | 이전/다음 학기, 재처리 사건·분모·수집 방식 |
| 사용자 결과 | 자신의 신청 가능 정보와 접수·판정 상태·공개 사유·다음 행동을 이해 | 대표 사용자와 과업·성공 정의 |
| 시스템 성능 | `QR-001`: 정의된 부하에서 상태 조회 p95 2초 후보 | 부하·데이터·측정 경계·오류율·비용 |
| 보호 지표 | 잘못된 자동 승인, 정원 초과, 다른 학생 정보 노출 없음 | 불변조건·관찰 지점·판정 책임 |
| 확인 시점 | 준비 기준선, 피크 운영, 학기 종료 후 효과 비교 | 데이터 가용성·책임자·분석 기간 |
성과 지표와 제품 지표를 혼동하지 않는다. 상태 조회 횟수가 늘어도 사용자가 불안해서 반복 확인했을 수 있다. 문의 건수가 줄어도 문의 경로가 막혔을 수 있다. 반복 제출·수동 재처리, 과업 이해도, 오류·권한·좌석 불변조건과 운영 회복을 함께 본다. 목표값이 승인되지 않았다면 “통과”나 “달성”을 보고하지 않는다.
세 번째 작업은 시스템 경계와 범위를 합의하는 일이다. 시스템 경계는 조직 책임과 외부 연계, 데이터의 공식 원천을 보여 준다. 화면이 보인다고 모두 수강신청 시스템의 책임은 아니며, 외부 서비스라고 프로젝트 영향 밖에 있는 것도 아니다.
포함 범위 후보는 신청 가능 정보 제공, 신청 의도 접수, 승인·거절·처리 보류 판정 조정, 본인 상태·공개 사유 조회, 동일 요청의 중복 안전성, 허용된 취소, 결정·상태 이력과 운영 회복이다. 이는 `FR-001–FR-005`, `DR-001–DR-005`, `IR-001–IR-005`와 연결된다. 실제 이관이 있다면 `DR-006`, `IR-006`을 별도 범위로 승인한다.
범위 제외와 미확정을 구분한다.
| 대상 | 초기 분류 | 이유·재검토 조건 |
|---|---|---|
| 교육과정·학칙 제정 | 시스템 범위 밖 | 시스템은 승인된 규칙을 실행·설명하며 정책을 만들지 않음 |
| 인증·학사·규칙 원천의 내부 개발 | 외부 책임 | 인터페이스·SLA·오류 책임은 프로젝트 범위 |
| 좌석 대기명단 | 미확정 | 처리 보류와 다른 정책이며 근거·배정 규칙 없음 |
| 졸업예정자 우선권 | 변경 후보 `CR-003` | 대상·시점·동률·이의·출처 미확인 |
| 실제 데이터 이관 | 조건부 | 원천·범위·품질·전환 계획이 확인될 때 포함 |
| 다채널 알림 확대 | 후순위 후보 | 공식 상태 조회를 대신하지 않으며 효과·SLA 미확인 |
“범위 밖”은 무시가 아니다. 인증 장애가 신청에 미치는 영향, 규칙 서비스가 제공할 버전, 학사 데이터의 기준 시점은 `IR` 요구와 외부 책임표로 통제한다. “미확정”은 나중에 몰래 구현할 여지도 아니다. 결정권자, 근거, 마감과 미결 시 기본 범위를 기록한다.
### 2. 범위와 이해관계자를 구조화한다
범위를 고를 때 검토한 대안도 남긴다. 첫 번째 대안은 화면 문구만 고치는 최소 변경이다. 비용은 낮지만 응답 유실·중복 효과와 규칙 장애에서 공식 상태를 제공하지 못하면 `G-01`을 충분히 다루지 못한다. 두 번째 대안은 검색부터 신청·상태·취소·회복까지 안전한 수직 흐름을 만드는 것이다. 연계·데이터·운영 작업이 늘지만 문제의 시작과 끝을 검증할 수 있어 브리프의 권고 후보로 둔다. 세 번째 대안은 대기명단·우선 배정·알림 채널까지 한꺼번에 포함하는 전면 개편이다. 정책 근거가 없고 변경 위험이 커 초기 범위에서 제외한다. 이 판단도 실제 비용·원인 자료가 나오면 바뀔 수 있다.
| 범위 대안 | 목표 기여 | 주요 위험 | 초기 판단 후보 |
|---|---|---|---|
| 문구만 개선 | 상태 이해 일부 개선 가능 | 공식 상태·중복·장애 원인 미해결 | 단독 범위로는 보류 |
| 안전한 신청 생명주기 | 접수·판정·조회·회복을 함께 검증 | 연계·상태·운영 복잡성 | 도출·분석 대상 |
| 정책·채널 전면 확대 | 잠재 가치 범위 큼 | 미승인 정책·비용·일정·검수 불명 | 초기 제외, 별도 변경 |
성공 기준선도 측정 전에 설계한다. `SRC-LOG-01` 후보에서 같은 신청 의도를 어떻게 식별할지, 시스템 자동 재시도와 사용자 재제출을 어떻게 구분할지, 수동 재처리의 시작·종료와 이유 코드를 정해야 한다. 지난 학기와 다음 학기의 신청 인원·강좌·정책·장애가 다르면 단순 건수 비교가 왜곡될 수 있다. 비율·업무시간·원인별 분포를 함께 보고 변경된 조건을 기록한다.
| 측정 단계 | 해야 할 일 | 판정 오류를 막는 질문 |
|---|---|---|
| 사건 정의 | 요청 ID·학생·분반·의도·시간 창으로 반복 후보 식별 | 재시도와 새 의도를 잘못 합치지 않는가? |
| 기준선 수집 | 이전 학기 첫 30분의 요청·문의·수동 처리 연결 | 누락 로그와 업무 외 처리가 있는가? |
| 목표 승인 | 50%의 분모·비교 기간·허용 차이 확정 | 숫자가 가능한지, 필요한 투자와 위험은? |
| 운영 관찰 | 배포 버전·외부 장애·사용자 집단별 결과 기록 | 감소가 문의 차단이나 오승인 때문은 아닌가? |
| 효과 확인 | 목표·보호 지표와 예상 밖 영향을 함께 평가 | 인과를 과장하지 않고 대안 설명을 검토했는가? |
프로젝트 제약에는 일정과 예산뿐 아니라 결정 가능 시점도 포함된다. 수강신청은 학기 일정에 묶일 수 있으므로 정책 확정, 데이터 동결, 성능 환경 준비, 사용자 안내와 전환 리허설의 마감이 필요하다. 실제 학사 일정이 없으므로 날짜를 만들지 않고 `M1`` 문제·범위 확인`, `M2`` 규칙·연계 결정`, `M3`` 명세 기준선 후보`, `M4`` 설계·시험 준비`, `M5`` 운영 전 승인` 같은 상대 게이트만 둔다. 각 게이트는 일정 통과가 아니라 필요한 증거와 권한이 갖춰졌는지 판단한다.
네 번째 작업은 이해관계자의 지식·관심·권한을 지도에 놓는 일이다. 사용 빈도나 직급만으로 우선순위를 정하지 않는다. 학생은 정책 승인권이 없지만 결과의 직접 영향을 받고 실제 과업 지식을 가진다. 운영자는 장애·수동 처리 지식을, 학사 책임자는 규칙과 예외 권한을 가진다. 한 사람이 모든 요구를 승인할 수 없다.
| 이해관계자 후보 | 필요한 지식·관심 | 결정·검토 책임 후보 | 참여 방식 |
|---|---|---|---|
| 학생·학생 대표 | 신청 목표, 상태 이해, 실패·회복 경험 | 사용자 필요·표현 확인 | 인터뷰·관찰·프로토타입, 집단 다양성 확보 |
| 장애학생·지원센터 | 보조기술·시간 제한·지원 장벽 | 접근성 요구·평가 자문 | 당사자 과업 평가, 대리 추정 금지 |
| 교무·학사 정책 책임 | 선수·학점·충돌·정원·예외·시행 | `RULE-001–RULE-005`, `ISS-001`, `CR-003` 결정 | 원문·결정표·워크숍·공식 승인 |
| 학과·교수 | 분반·정원·교육 운영과 예외 | 강좌 정보·업무 영향 검토 | 문서·인터뷰·정원 변경 시나리오 |
| 학생지원·상담 | 문의·민원·수동 처리와 설명 | 운영 요구·공개 사유 검토 | 사례 표본·업무 관찰 |
| IT 운영·개발·아키텍처 | 피크 부하, 장애·복구, 실현 가능성 | 기술 대안·운영 준비·추정 | 로그·실험·장애 워크스루 |
| 시험·품질 | 수용 기준·환경·증거 | 검증 가능성·시험 독립성 | 동료검토·시험 설계 |
| 보안·개인정보 | 신원·대상 인가, 최소 처리·보존 | `QR-005–QR-006`, `QR-011`, `DR-005` | 위협·처리 검토, 승인 권한 확인 |
| 사업 후원자 | 투자·성과·범위·위험 | `BR-001`, 예산·일정·잔여 위험 | 단계 게이트·성과 검토 |
| 외부 서비스 책임자 | 인증·학사·규칙·알림 계약 | `IR-002–IR-005`, SLA·변경·장애 | 계약·인터페이스 공동 검토 |
이 지도는 실제 조직도가 아니라 참여자가 빠졌는지 확인하기 위한 후보다. 실제 이름, 위임 범위, 대리 승인과 연락 경로는 확인해야 한다. 정책 책임자가 불참한 회의에서 개발·학생 다수가 동의해도 `CR-003`을 승인할 수 없다. 반대로 사용자 없는 정책 회의가 `UR-001`의 이해 가능성을 확인할 수도 없다.
가정·제약·위험을 프로젝트 브리프에 별도 등록한다.
| 종류 | ID·내용 | 영향 | 확인·대응 |
|---|---|---|---|
| 가정 | `ASM-001` 반복 제출이 수동 재처리의 주요 원인 | 목표·투자 타당성 | 로그 사건 정의와 사용자·운영 확인 |
| 가정 | `ASM-002` 규칙 서비스가 규칙 버전을 제공 | 판정 재현·감사 | 계약·표본 응답 확인 |
| 가정 | `ASM-003` 처리 보류가 좌석을 차지하지 않음 | 공정성·경합·재평가 | 정책 워크숍, 결정 전 구현 금지 |
| 가정 | `ASM-004` 직전 학기 첫 30분 자료를 비교 기준선으로 사용할 수 있음 | `BR-001`의 50% 감소 판정 | 사건 정의·기간·운영 조건의 비교 가능성 확인 |
| 제약 후보 | 기존 인증·학사·규칙 연계 사용 | 경계·가용성·버전 | 실제 계약·변경 책임 확인 |
| 위험 | `RSK-REQ-01` 우선 정책 미합의 구현 | 불공정·이의·재작업 | `ISS-001` 결정 전 승인 금지 |
| 위험 | `RSK-REQ-04` 기준선 없는 성능 수치 | 과소 설계·과잉 비용 | 측정 계약과 실험 |
이제 프로젝트 브리프 `PBR-ENR-01`` v0.1` 후보를 한 장으로 요약할 수 있다.
| 브리프 필드 | 내용 |
|---|---|
| 문제 | 결과·다음 행동 불명과 반복 제출·수동 처리 가능성, 원인 미확인 |
| 목표 | `G-01`, `BR-001` 후보와 안전·개인정보 보호 지표 |
| 사용자·업무 | 학생, 학사·학과, 지원·운영과 결정·자문 책임 |
| 포함 | 검색·접수·판정 조정·상태/사유·중복 안전·취소·감사·회복 후보 |
| 제외·미확정 | 정책 제정 제외, 대기명단·`CR-003`·이관·알림 확대 미확정 |
| 외부 경계 | `IR-002–IR-005`, 조건부 `IR-006` |
| 주요 가정·쟁점 | `ASM-001–ASM-004`, `ISS-001`, 측정·보존·종료 정책 |
| 승인 상태 | 교육용 초안, 실제 후원자·정책·사용자 확인과 기준선 없음 |
브리프 검토에서는 항목별 권한을 나눈다. 사업 후원자는 목적·투자·성과를, 정책 책임자는 규칙·예외를, 사용자 대표는 필요와 경험을, 기술·운영 책임자는 실현·회복을, 보안·개인정보 책임자는 해당 통제를 검토한다. 문서 전체에 서명 하나를 받는 대신 열린 항목, 조건, 반대 의견과 재검토 기한을 기록한다.
승인 전 자체 검토 질문도 브리프에 붙인다.
- 문제 문장에 특정 화면·제품·아키텍처가 정답처럼 고정되지 않았는가?
- 목표가 사용자·업무 결과를 말하며 측정 대상과 시점이 있는가?
- 목표 수치의 기준값·분모·비교 조건이 확인 전이라는 사실이 보이는가?
- 포함·제외·미확정과 외부 책임이 서로 구분되는가?
- 드물지만 피해가 큰 오승인·정원·인가·개인정보 실패가 보호 지표에 있는가?
- 규칙을 아는 사람, 실제 과업을 수행하는 사람과 운영·검증 책임이 모두 참여하는가?
- 가정이 틀리거나 외부 계약이 바뀔 때 돌아갈 결정 지점이 있는가?
프로젝트 시작의 완료는 모든 답을 아는 상태가 아니다. 어떤 문제를 왜 조사하는지, 성공을 무엇으로 판단할지, 어디까지 책임질지, 누구에게 무엇을 물어야 하는지와 어떤 결정이 비어 있는지가 보이면 다음 단계로 갈 수 있다. 다음 장의 도출 계획에는 네 묶음을 넘긴다.
새 로그에서 원인이 다르게 드러나면 문제·목표로 돌아가고, 정책 책임자가 범위를 바꾸면 경계·성과·참여를 다시 검토한다. 시작 문서는 고정된 선언문이 아니라 이후 증거와 결정이 어디에서 출발했는지 보여 주는 비교 기준이다. 변경 이유와 책임도 여기에서 설명한다.
### 3. 브리프를 다음 단계로 넘긴다
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 44장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
흩어진 수강신청 사례를 프로젝트 브리프와 이해관계자·범위·가정·위험으로 다시 조립해 시작 조건을 만든다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
학습 순서에 따라 다음 판단 주제로 이어갑니다.