35장. 계획 기반 개발의 요구사항

계획 기반 개발에서 단계별 산출물·검토·기준선과 변경 통제를 운영하면서 선행 문서의 한계를 관리한다.

이번 장에서 해결할 질문

학습 목표

• “계획 기반 개발에서 기준선과 변경 통제를 어느 깊이로 운영하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

계획 기반 개발을 처음에 모든 요구를 완벽히 확정하고 이후에는 바꾸지 않는 방식으로 이해하면 요구사항 통제의 목적을 놓친다. 중요한 것은 문서의 양이 아니라 특정 시점의 합의와 책임을 분명히 하고, 새로운 사실이 생겼을 때 그 영향을 정해진 절차에 따라 판단하는 것이다.

이 장에서는 단계별 요구사항 활동, 기준선, 공식 검토와 변경 통제가 설계·구현·시험·인수와 어떻게 연결되는지 살펴본다. 계획을 현실과 분리된 약속으로 만들지 않고, 결정 시점과 증거를 관리하는 계획 기반 접근의 실제 역할을 설명한다.

1. 계획 기반 개발의 통제 원칙

2026년에 발행된 ISO/IEC/IEEE 12207은 소프트웨어의 획득·공급·개발·운영·유지보수·폐기에 적용할 수 있는 생명주기 프로세스의 공통 틀을 제공하며 특정 생명주기 모델을 요구하지 않는다. ISO/IEC/IEEE 15288도 시스템 생명주기 프로세스를 반복적·동시적으로 적용할 수 있다고 설명한다. 계획 기반이라는 말은 표준 활동을 순차 폭포형으로만 수행한다는 뜻이 아니다. 계약 위험, 안전·규제, 공급자 관계와 검수 책임 때문에 사전 합의와 공식 통제가 강한 환경을 가리키는 편이 정확하다.

ISO/IEC/IEEE 29148은 2024년 재확인된 현재 발행본이며 2026년 8월 현재 차기 판 초안이 별도로 진행 중이다. 프로젝트 적용 기준은 승인되지 않은 초안이 아니라 계약·조직이 지정한 발행본으로 정하고, 새 판이 발행되면 변경 내용을 평가한다.

10부에서 이어받는 입력은 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전., FR-001–FR-005FR-001–FR-005FR-001: 학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. · FR-002: 인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다. · FR-003: 인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. · FR-004: 같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다. · FR-005: 신청·판정 이력., QR-001–QR-011QR-001–QR-011QR-001: 합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다. · QR-002: 핵심 업무 99.9% 가용 후보. · QR-003: 동시 신청 경쟁. · QR-004: 기준 요청량 2배 후보. · QR-005: 다른 학생 객체 접근. · QR-006: 대표 사용자는 신청·상태 과업과 공개 사유의 다음 행동을 합의한 성공 기준으로 이해해야 한다 · QR-007: 적용 접근성 기준 미정. · QR-008: 승인된 규칙 변경의 영향받는 요구·설계·시험·계약·운영 자료를 추적하고 정한 시간 안에 갱신·검증할 수 있어야 한다 · QR-009: 권한 있는 역할은 판정·상태 변화를 원천·주체·입력·규칙 버전까지 재현할 수 있어야 한다 · QR-010: 정의된 장애에서 안전 상태를 보존하고 합의된 목표 안에 재평가·복구·대사할 수 있어야 한다 · QR-011: 목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다, IR-001–IR-006IR-001–IR-006IR-001: 자격·운영 흐름. · IR-002: 주체 인증·세션 정보. · IR-003: 학생·강좌·이수 원천. · IR-004: 규칙 결과·사유·버전 제공. · IR-005: 최소 정보·재시도·공식 조회 연결. · IR-006: 합의 형식·전달.과 그 설계·시험 후보의 추적 사슬이다. 그러나 이 사례에는 실제 발주기관, 계약과 승인 기준선이 없다. 아래의 계약 항목·게이트·기준선은 교육용 예시이며 사업 착수나 검수를 승인한 기록이 아니다. 특히 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 50% 감소와 QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 p95 2초는 기준선과 측정 환경이 확인되지 않은 후보 수치다.

계획 기반 요구사항의 첫 흐름은 제안요청이나 사업계획과 계약에서 목표·범위·검수 책임을 확인하는 일이다. 발주 문서에 “수강신청 시스템 고도화”만 적혀 있으면 공급자는 화면 개편, 처리량 증설, 규칙 자동화 가운데 무엇을 가격과 일정에 포함해야 하는지 판단할 수 없다. 반대로 모든 화면 필드와 기술 제품을 미리 고정하면 아직 분석하지 않은 해법을 계약으로 굳힐 수 있다.

계약 입력은 최소한 다음 질문에 답해야 한다.

계약 요구 후보 CTR-ENR-001CTR-ENR-001 · 프로젝트 항목수강신청 구축 범위를 계약 요구부터 상세 요구, 기능·화면, API·데이터, 시험·검수까지 추적하는 계약 항목 후보다.을 “학생은 신청 결과를 확인할 수 있어야 한다”로만 두지 않는다. 상위 목표와 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.을 연결하고, 상태·공개 사유·기준 시점·권한·접근성·응답 시간의 상세화 책임, 공급 데이터와 제외 항목, 검수 근거를 함께 가리킨다. 계약 본문이 모든 세부를 담을 필요는 없지만 참조 문서의 버전과 우선순위, 불일치 해결 규칙은 분명해야 한다.

가격과 기간은 요구와 독립된 행정 숫자가 아니다. 규칙 서비스 장애 때 내구 접수와 보류 재평가를 포함하는지, 피크 부하 시험 환경을 누가 준비하는지, 실제 학사 데이터 이관과 대사를 누가 책임지는지에 따라 규모가 달라진다. “당연히 포함”이라는 기대를 줄이려면 포함·제외·발주자 제공사항·가정을 구분한다. 가정 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.처럼 규칙 버전이 제공된다는 전제가 틀리면 어떤 계약 항목을 다시 협의할지도 둔다.

두 번째 흐름은 분석으로 모호성과 누락을 줄이고 기준선을 만드는 일이다. 계약 체결이 분석 종료를 뜻하지 않는다. 계약 요구의 목적과 경계를 지키면서 사용자, 규칙, 데이터, 품질, 연계와 운영 조건을 상세화한다. 분석 중 발견된 차이가 단순 설명인지 계약 범위의 변경인지 구분해야 한다.

예를 들어 “수강 가능 여부를 확인한다”를 분석하면 선수과목 RULE-001RULE-001 · 업무 규칙신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다., 최대 학점 RULE-002RULE-002 · 업무 규칙승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다., 시간 충돌 RULE-003RULE-003 · 업무 규칙시간 충돌 판정., 수용량 RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다., 우선 배정 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.가 나온다. 학칙과 시스템 동작이 다르거나 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.처럼 우선 배정과 수용량 불변조건이 충돌하면 분석자가 임의로 한쪽을 선택하지 않는다. 출처, 해석 대안, 업무·비용·일정 영향을 정리해 결정권자에게 쟁점으로 올린다.

상세 요구 후보는 다음 게이트를 통과해야 기준선 후보가 된다.

BL-ENR-01BL-ENR-01 · 프로젝트 항목다음 학기 설계 입력으로 사용할 요구·모델·규칙·인터페이스의 승인 버전을 묶는 교육용 기준선 후보다.은 이 책에서 기준선 형식을 설명하기 위한 가상 후보일 뿐 실제 승인본이 아니다. 후보 기준선에는 요구 ID와 버전, 상태, 적용 릴리스, 출처, 승인 역할, 제외·유예, 열린 위험을 포함한다. 문서 파일을 잠그는 것만으로 기준선이 되지 않는다. 어떤 요구 집합과 참조 규칙·모델·수용 기준이 함께 승인됐는지 재현할 수 있어야 한다.

기준선은 변화를 막는 벽이 아니라 비교 기준이다. 승인 뒤 발견된 오탈자, 의미를 바꾸지 않는 설명 보완, 상세 설계 선택, 계약 범위 변화는 같은 절차로 다룰 필요가 없다. 분류 기준이 없으면 사소한 편집에도 회의가 필요하거나, 중요한 범위 변화가 “문구 정리”로 통과한다.

세 번째 흐름은 설계·구현 중 변경을 영향 분석과 승인으로 통제하는 일이다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.의 졸업예정자 우선권을 예로 들면 “규칙 한 줄 추가”가 아니다. 대상 증명, 동률 처리, 적용 학기, 좌석 경합, 학생 공개 사유, 개인정보, 이의 절차와 소급 적용을 결정해야 한다. FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정., CMP-RULE-01CMP-RULE-01 · 구성요소규칙 연계·입력 기준선·판정 정규화., API-RULE-01API-RULE-01 · API 설계규칙 평가 연계., DATA-DECISION-01DATA-DECISION-01 · 데이터 설계학적 기준·우선 근거 재현., SCR-STATUS-01SCR-STATUS-01 · 화면 설계적용 사유와 정정 안내., TC-CAP-001-01TC-CAP-001-01 · 시험 항목마지막 좌석에 여러 신청이 동시에 들어와도 정원 초과와 복수 승인이 생기지 않는지 확인하는 시험 후보다.까지 영향이 이어진다.

변경 통제에서는 변경했을 때뿐 아니라 변경하지 않았을 때의 영향도 분석한다. 학칙 개정이 시행될 예정인데 시스템 변경을 미루면 수동 처리, 법적·운영 위험과 임시 통제가 필요할 수 있다. 일정이 촉박하다는 사실이 자동 승인 근거는 아니지만 단계적 적용, 기능 비활성화, 제한된 수동 절차 같은 대안을 비교할 근거가 된다.

변경 결정 기구를 흔히 변경통제위원회라고 부르지만 이름보다 권한 구성이 중요하다. 업무 정책, 사용자 영향, 기술·시험, 보안·개인정보, 비용·계약과 운영 책임이 필요한 변경에 맞게 참여한다. 모든 변경을 큰 위원회에 올리지 않고 위험·금액·일정·규제 임계값에 따라 위임 수준을 정한다. 단, 공급자가 범위 확대를 무상으로 흡수하거나 발주자가 계약 책임을 기술 판단으로 우회하지 않게 기록을 남긴다.

변경 승인 후 가장 흔한 실패는 의사록만 갱신되고 요구·설계·시험·일정이 서로 다른 버전을 보는 것이다. 변경 기록에는 적용 기준선, 대체·폐기 요구, 영향받는 산출물 소유자와 완료 확인을 둔다. 늦게 발견된 영향은 원 요청에 다시 연결하고 필요하면 재승인한다. 승인됐다는 사실이 구현 완료를 의미하지 않는다.

2. 변경과 기준선 관리

네 번째 흐름은 시험·인수 결과를 계약 요구와 기준선까지 추적하는 일이다. 인수는 “화면을 시연했다”거나 “시험 케이스가 모두 실행됐다”로 끝나지 않는다. 계약된 목적·범위·품질과 승인 기준선의 수용 기준을 어떤 환경과 데이터에서 충족했는지, 미결함과 예외를 누가 어떤 조건으로 받아들이는지 결정한다.

QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 p95 2초를 계약 수치로 승인하려면 동시 사용자, 데이터량, 요청 분포, 네트워크 경계와 오류율을 함께 고정해야 한다. 개발 환경의 단일 요청이 0.5초였다는 결과로 인수하지 않는다. 반대로 환경을 발주자가 제공하기로 했는데 준비되지 않았다면 공급자 실패와 시험 불가를 구분하고 책임·일정을 조정한다.

인수 중 발견된 결함과 새 요구도 구분한다. 승인 기준선과 다르면 결함 후보이고, 기준선에는 없지만 실제 업무에 필요하면 변경 후보이다. “검수 보완”이라는 한 이름으로 합치면 비용·책임과 품질 데이터가 왜곡된다. 조건부 수용은 미완료를 숨기는 표현이 아니라 남은 항목, 영향, 임시 통제, 해결 기한과 미이행 결과를 명시한 결정이어야 한다.

단계마다 산출물 이름은 조직에 따라 달라도 입력과 결정 책임은 연결돼야 한다. 다음 지도는 문서 목록이 아니라 앞 단계의 어떤 증거가 다음 판단에 쓰이는지를 보여 준다.

이 지도에서 분석가가 모든 문서를 혼자 소유하지 않는다. 업무 책임자는 규칙의 의미와 예외를, 보안·개인정보 책임자는 통제와 공개 범위를, 운영자는 감시·복구 가능성을, 시험 책임자는 관찰 가능한 수용 조건을 검토한다. 공급자는 실현 가능성과 비용을 설명하고 발주자는 정책·데이터·외부 시스템 제공 의무를 확인한다. RACI 표를 기계적으로 채우기보다 결정마다 최종 권한과 필요한 자문을 지정한다.

초안이 기준선 후보로 바뀌는 과정을 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.으로 살펴보자. 첫 초안은 “학생에게 신청 결과를 즉시 알려야 한다”였다. 이 문장은 즉시의 측정 구간, 접수와 판정의 구분, 규칙 장애와 알림 실패의 의미가 없다. 검토에서 운영자는 규칙 서비스 지연을, 학생 대표는 거절 사유와 다음 행동을, 시험 담당자는 측정 환경을 질문한다.

검토 뒤 후보는 다음처럼 분리된다.

FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.: 인증된 학생은 자신의 신청 ID로 현재 접수·판정 상태, 공개 가능한 사유, 마지막 갱신 시각과 가능한 다음 행동을 조회할 수 있어야 한다.

IR-001IR-001 · 인터페이스 요구자격·운영 흐름.: 규칙 평가가 실패·무효·시간 초과이면 자동 승인하지 않고 원인 코드가 있는 보류 상태로 기록하며 재평가할 수 있어야 한다.

QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.: 상태 조회 성능 목표는 합의된 부하 환경과 측정 구간에서 p95 2초 후보로 검증하되, 환경·기준선 확인 전에는 계약 수치가 아니다.

수정 결과는 더 길어서 좋은 것이 아니라 서로 다른 책임과 시험 근거가 분리됐기 때문에 낫다. 원래 문장은 폐기하거나 대체 관계를 기록하고, 계약 표현이 결과 중심으로 충분하다면 상세 요구를 참조하게 한다. 검토 의견도 누가 어떤 증거로 문제를 제기했고 어떻게 반영했는지 남겨 나중에 같은 논쟁이 반복되지 않게 한다.

품질 검토는 문서 승인 직전 한 번만 하지 않는다. 요구 작성자는 자체 검토로 식별자·출처·단일성·검증 가능성을 확인하고, 동료 검토는 용어·모델·추적의 일관성을 본다. 이해관계자 검토는 업무 적합성과 공개 범위를, 설계·시험 검토는 실현성과 관찰 가능성을 확인한다. 결정되지 않은 항목을 억지로 통과시키지 않고 쟁점·가정·위험과 해결 기한으로 분리한다.

계획의 상세도도 위험에 맞춰 조정한다. 학칙 판정과 좌석 정합성처럼 사용자 권리·대규모 경합에 영향을 주는 부분은 규칙, 데이터 기준선, 상태 전이와 시험을 일찍 상세화한다. 내부 운영 보고서의 배치나 낮은 위험의 문구는 설계 시점까지 선택을 늦출 수 있다. 상세화 순서를 모든 기능에 똑같이 적용하면 중요한 위험에 쓸 시간을 형식 채우기에 소모한다.

통제를 가볍게 한다는 것은 근거·검증·추적을 없앤다는 뜻이 아니다. 별도 문서 대신 관리 도구의 필드와 자동 추적을 사용할 수 있고, 작은 변경은 위임된 승인자가 짧은 영향표로 결정할 수 있다. 반대로 문서가 많아도 승인 대상과 버전이 모호하거나 시험 증거가 기준선과 연결되지 않으면 통제 강도는 낮다.

기준선 이후에도 요구 발견 활동은 계속한다. 상세 설계, 시제품, 시험과 운영 리허설에서 새 사실을 얻으면 원래 가정과 위험을 갱신한다. 계획의 가치는 미래를 정확히 맞히는 데만 있지 않고, 틀렸을 때 무엇을 다시 계획하고 누가 결정을 내릴지 준비하는 데 있다. 변경 건수 자체를 실패 지표로 삼으면 문제를 숨기게 된다. 미예측 변경, 늦은 결정, 재작업 원인과 대응 시간을 함께 분석한다.

마지막으로 인수 뒤 운영 인계도 요구사항 흐름의 일부다. 알려진 제한, 보류 재처리, 규칙·데이터 버전, 모니터링 임계값, 지원 권한과 회귀 묶음을 운영팀이 사용할 수 있어야 한다. 프로젝트 문서 보관 위치만 알려 주는 것으로는 부족하다. 운영 중 발견된 장애·민원·정책 변경이 어느 기준선과 설계·시험을 갱신해야 하는지도 연결해 둔다.

계획 기반 흐름을 한 장으로 정리하면 다음과 같다.

계획 기반 방식을 선택할 근거는 예측 가능성만이 아니다. 다수 공급자, 고정 예산, 규제·안전 책임, 장기간 조달과 공식 인수처럼 결정권과 책임을 명시해야 할 때 강한 기준선과 게이트가 유용하다. 요구 불확실성과 사용자 학습이 큰 부분은 시제품·점진 상세화·반복 검증을 계획 안에 포함할 수 있다. 어느 환경에서도 모든 것을 처음에 확정하거나 모든 변경을 금지하는 것은 좋은 통제가 아니다.

이 장에서 정리한 결과는 단계별 산출물 지도, 기준선 통과 조건, 변경 통제 흐름, 계약-요구-시험 인수 연결표다. 다음 장에서는 같은 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.과 FR 집합을 장기 기준선 중심이 아니라 Product Goal, 백로그, 짧은 반복과 피드백으로 다루되 근거·품질·추적 책임이 사라지지 않는 방식을 살펴본다.

3. 단계별 산출물과 인계

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로