11장. 범위를 정의한다

제품·시스템·업무·데이터 경계와 외부 시스템 책임을 정해 범위 확대와 책임 공백을 함께 막는다.

이번 장에서 해결할 질문

학습 목표

• “제품과 프로젝트가 책임질 범위와 경계 밖의 일을 어떻게 합의하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

요구를 분석해도 시스템이 어디까지 책임지는지 정하지 않으면 범위는 계속 팽창한다. 사용자의 기대와 업무 절차, 조직 정책, 외부 서비스의 역할이 한 문서에 섞이면 책임 공백과 중복 구현이 동시에 생긴다. 범위는 기능 목록보다 경계에서 더 선명하게 드러난다.

이 장에서는 제품·시스템·업무·데이터 경계와 외부 시스템의 책임을 구분한다. 컨텍스트 안팎의 역할과 인터페이스를 확인하고 포함·제외·보류 범위를 근거와 함께 기록해, 이후 분해와 설계가 의지할 안정된 책임 경계를 만든다.

1. 프로젝트 범위

범위는 원하는 기능을 한데 모은 목록이 아니라 이번 변화가 책임질 결과와 경계를 합의한 것이다. 범위가 흐리면 외부 시스템의 지연을 우리 시스템이 해결한다고 약속하거나, 반대로 외부 연계라는 이유로 실패 처리를 아무도 맡지 않는다. 10장10장. 요구사항 분석도출한 요구 후보에서 누락·모순·중복·실현 가능성 문제를 어떻게 찾는가?페이지로 이동의 후보를 분석했다면 이제 무엇을 바꿀 수 있는가, 누가 책임지는가, 어디에서 다른 책임으로 넘어가는가를 정해야 한다.

프로젝트 범위는 정해진 기간과 예산으로 수행할 변화 활동의 경계다. 새 소프트웨어 제작뿐 아니라 규정 정비, 데이터 이관, 외부 연계 변경, 교육, 운영 전환과 성과 측정이 포함될 수 있다. 반대로 제품에 필요한 기능이어도 이번 프로젝트가 만들지 않고 기존 서비스를 재사용한다면 그 구축 활동은 프로젝트 범위 밖이다.

수강신청 개선 프로젝트의 범위 문장 초안은 다음처럼 쓸 수 있다.

다음 학기 수강신청 첫 30분의 반복 제출과 수동 재처리를 줄이기 위해 신청 상태·사유 제공, 판정 기록, 외부 규칙 실패 시 보류·복구 흐름을 개선하고 운영 절차와 측정 기준을 함께 정비한다. 학사 정책 자체의 전면 개정과 대학 통합 인증 서비스 교체는 이번 프로젝트에서 수행하지 않는다.

이 문장은 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전., BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자., UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자., FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다., DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다., IR-001IR-001 · 인터페이스 요구자격·운영 흐름.을 묶지만 아직 승인안은 아니다. 특히 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 50% 목표와 기준선, ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다.의 원인 가정과 ASM-004ASM-004 · 가정직전 학기 첫 30분 자료가 비교 가능한 기준선이다의 기준선 비교 가능성은 확인 전이다. 프로젝트 범위를 승인할 때는 결과, 기한, 주요 산출물, 수행 조직, 예산·인력 한계, 전환과 종료 조건, 제외 활동과 승인자를 함께 남긴다.

판단 질문은 “이 기능이 좋을까?”가 아니다. 이 활동이 목표 달성에 필요한가, 이번 기간 안에 책임질 조직과 자원이 있는가, 빠지면 누가 어떤 방식으로 수행하는가를 묻는다. 제품 범위와 프로젝트 범위를 섞지 않기 위한 출발점이다.

2. 제품 범위

제품 범위는 변화 후 사용자와 운영자에게 제공할 능력과 품질의 경계다. 프로젝트가 ‘어떤 일을 할지’를 말한다면 제품은 ‘무엇을 제공하고 유지할지’를 말한다. 구축 프로젝트가 끝나도 제품의 기능·데이터·인터페이스와 운영 책임은 남는다.

이 사례의 제품 범위 후보는 다음과 같다.

• 학생이 수강 가능 강좌와 신청의 접수·판정 중·승인·거절 결과 및 사유를 확인한다.
• 시스템이 선수과목, 시간표 충돌, 최대 학점, 정원과 우선순위 규칙을 평가한다.
• 승인에는 신청 식별자를, 거절에는 사유 코드를 연결한다.
• 규칙 서비스가 유효한 결과를 주지 못하면 자동 승인하지 않고 보류 상태와 원인을 제공한다.
• 판정의 입력·규칙 버전·결과·최종 상태 변경을 추적한다.

반면 인증 서비스 자체의 계정 발급, 학사정보의 성적 확정, 등록금 결제, 문자·전자우편 전송 인프라의 운영은 기존 외부 제품의 능력으로 둘 수 있다. 그렇다고 수강신청 제품의 요구가 사라지지는 않는다. 어떤 인증 결과를 신뢰할지, 학사정보가 늦거나 무효일 때 무엇을 할지, 알림 요청과 실제 신청 결과를 어떻게 분리할지는 제품 경계의 요구다.

제품 범위를 검토할 때는 사용자 결과, 핵심 기능, 품질·제약, 운영·지원, 외부 인터페이스를 함께 본다. 화면 기능만 적으면 관측·복구·감사·접근성 같은 제품 책임이 빠진다. 기술 구성요소 목록만 적으면 학생과 운영자가 얻는 결과가 사라진다.

3. 시스템 경계

시스템 경계는 개발할 시스템과 그 주변 맥락 사이의 선이다. IREB CPRE 용어집은 시스템 경계를 시스템과 주변 맥락의 경계로 정의하고, 경계에서 외부 인터페이스를 정의해야 한다고 설명한다. 또한 시스템 경계와 설계할 수 있는 범위가 흔히 일치하지만 항상 같지는 않다고 구분한다. 시스템 내부에 바꿀 수 없는 기존 구성요소가 있을 수 있고, 시스템 바깥의 업무 절차를 프로젝트가 바꿀 수도 있기 때문이다.

여기서는 수강신청 제품을 관심 시스템으로 둔다. 그 내부에는 신청 요청 수신, 규칙 평가 조정, 상태 저장·조회, 판정 기록과 운영 복구 지원이 있다. 학사정보, 학사 규칙 판정, 인증, 알림과 결제 서비스는 외부 시스템이다. 학생, 교무 담당자, 학과 담당자와 운영자도 시스템 밖의 행위자다.

경계는 조직도나 배포 서버 선과 같지 않다. 같은 IT 부서가 운영하는 인증 서비스라도 독립된 책임·데이터·장애 정책을 가진다면 외부로 모델링할 수 있다. 반대로 외부 업체가 개발한 규칙 평가 구성요소를 수강신청 제품 팀이 계약상 책임지고 배포·변경한다면 관심 시스템 내부일 수 있다.

경계 결정에는 최소한 다음 근거가 필요하다.

경계가 정해졌다는 말은 외부를 통제할 수 있다는 뜻이 아니다. 통제할 수 없는 변동을 인터페이스 조건과 안전한 동작으로 다룰 책임을 정했다는 뜻이다.

4. 업무 범위

업무 범위는 자동화 여부와 관계없이 변화할 업무 과정, 규칙, 역할과 책임의 경계다. 시스템 범위가 소프트웨어 안팎을 나눈다면 업무 범위는 조직이 어떤 일을 새롭게 수행하거나 중단할지를 말한다.

수강신청 개선에서는 신청 판정, 보류 재평가, 학생 문의, 정원·규칙 변경과 이의 처리가 하나의 업무 흐름으로 이어진다. 자동 판정만 제품에 넣고 보류를 누가 언제 끝내는가를 업무 범위에서 제외하면 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.은 영구 대기열을 만든다. 반대로 학과 교육과정 편성 전체를 개선 범위에 넣으면 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.과 무관한 거대한 변화가 된다.

업무 범위는 시작 사건과 종료 결과로 표현하면 경계가 분명해진다.

시작: 학생이 본 신청 기간에 강좌 신청을 제출한다
포함: 자격·규칙 판정, 정원 반영, 결과·사유 제공, 보류 재평가,
      오류 정정과 문의에 필요한 판정 이력 조회
종료: 신청이 승인·거절·취소 등 정의된 최종 상태가 되고,
      학생과 담당자가 결과와 다음 행동을 확인할 수 있다
제외: 교과과정 설계, 성적 확정, 등록금 수납 업무 자체

업무 범위의 검토자는 개발팀만이 아니다. 실제 규칙과 예외 권한을 가진 교무·학과 담당자, 문의와 복구를 맡는 운영자, 영향을 받는 학생이 정상·예외·실패 경로를 확인해야 한다. 사람의 수작업을 남길 때도 입력, 권한, 처리 기한, 증거와 종료 상태를 요구사항으로 다룬다.

5. 기능 범위

기능 범위는 제품이 제공할 동작과 서비스다. 이것을 화면 메뉴 목록으로 적으면 같은 업무 능력이 채널별로 중복되고, 보이지 않는 판정·기록·복구 기능이 빠진다. 사용자 또는 외부 시스템이 얻는 결과 중심으로 묶는다.

이 사례에서는 다음 능력 묶음을 둘 수 있다.

대기명단, 개인화 추천, 관리자 통계는 유용해 보이지만 현재 목표에 대한 근거와 범위 합의가 아직 없다. 기능 후보 목록에 남기되 자동으로 이번 출시 범위에 넣지 않는다. 13장13장. 요구사항의 우선순위를 결정한다가치·긴급성·위험·노력을 섞지 않고 우선순위를 어떻게 결정하는가?페이지로 이동에서 가치·비용·위험·의존성을 비교할 입력으로 보낸다.

기능 범위가 충분한지는 기능 수가 아니라 업무 흐름의 시작부터 안전한 종료까지 책임이 끊기지 않는지로 판단한다. 정상 흐름만 있고 실패·취소·복구가 없다면 범위는 아직 불완전하다.

6. 데이터 범위

데이터 범위는 시스템이 소유하는 데이터만을 뜻하지 않는다. 목적을 위해 생성·조회·복제·변환·보존·삭제하는 정보와 그 책임을 정한다. 외부에서 읽는 학적·성적·강좌 정보도 입력 시점과 품질이 판정 결과를 바꾸므로 범위에 포함해 분석해야 한다.

DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.은 학생·강좌 식별자, 요청 시각, 결과, 사유 코드, 규칙 버전과 최종 상태 변경 시각을 판정 기록에 포함한다. 여기에 다음을 확인해야 한다.

• 학생 식별자와 강좌 식별자의 원천·변경 규칙은 무엇인가?
• 선수과목 이수, 최대 학점, 시간표, 정원은 어느 시점의 값을 사용하는가?
• 같은 요청을 구분할 신청 식별자와 중복 판단 키는 무엇인가?
• 규칙 버전을 외부 서비스가 주는가, 우리 시스템이 별도로 기록하는가?
• 판정 기록과 알림 전송 기록을 얼마나 보존하고 누가 볼 수 있는가?
• 정정·삭제가 필요할 때 업무 감사성과 개인정보 원칙을 어떻게 함께 지키는가?

데이터 범위표는 데이터/원천 소유자/우리 시스템의 사용 목적/복제 여부/최신성·품질/보존·접근/실패 동작으로 구성한다. 이때 필요할 수 있으니 모두 저장은 범위 근거가 아니다. 목적과 요구에 필요한 최소 데이터를 설명하고, 민감도와 접근 권한을 함께 검토한다.

ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.처럼 규칙 버전 제공 여부가 확인되지 않았다면 데이터 범위에 확정 사실로 넣지 않는다. 인터페이스 확인 항목과 위험으로 남겨야 한다. 데이터 경계는 23장23장. 데이터 요구사항데이터의 의미·품질·생명주기·보호 책임을 요구사항으로 어떻게 다루는가?페이지로 이동의 데이터 요구와 24장24장. 인터페이스 요구사항시스템 경계를 넘는 계약과 실패 대응을 인터페이스 요구사항으로 어떻게 정의하는가?페이지로 이동의 인터페이스 요구에서 더 상세화한다.

7. 외부 시스템

외부 시스템은 관심 시스템 밖에 있지만 목표와 요구에 영향을 주고받는 시스템이다. 외부라고 해서 요구사항이 없는 것이 아니다. 오히려 직접 통제할 수 없으므로 입력·출력·시간·보안·장애와 책임 이관을 명확히 해야 한다.

IR-001-CIR-001-C · 인터페이스 요구> 학사 규칙 판정 서비스는 합의된 시간 안에 요청 식별자, 규칙 버전, 판정 결과 또는 계약된 오류 정보를 반환해야 한다.는 학사 규칙 판정 서비스의 정상·오류 응답 계약을 정의하고, IR-001-RIR-001-R · 인터페이스 요구> 수강신청 소프트웨어는 합의된 시간 안에 유효한 판정 정보를 받지 못하면 신청을 자동 승인하지 않고 처리 보류 상태와 원인 코드를 기록·반환해야 한다.은 그 계약을 충족하는 유효 응답을 받지 못했을 때 수강신청 제품이 자동 승인하지 않고 처리 보류하도록 한다. 그러나 실패의 범위가 연결 끊김만인지, 시간 초과·형식 오류·오래된 규칙 버전까지 포함하는지는 아직 정해야 한다. 외부 인터페이스마다 정상 응답뿐 아니라 무응답, 늦은 응답, 중복, 순서 역전, 부분 성공과 잘못된 데이터의 책임을 묻는다.

외부 시스템 이름을 적는 데서 끝내지 않는다. 각 연결의 소유자, 계약·명세, 변경 통지 경로, 시험 환경, 운영 연락, 감시와 복구 경계를 확인해야 한다. 경계에서 주고받는 사건과 데이터가 없는 외부 대상은 왜 관련 있는지 다시 검토한다.

8. 범위 제외

범위 제외는 중요하지 않아서 잊은 항목이 아니라 이번 책임에 포함하지 않기로 한 명시적 결정이다. 제외 항목에도 이유, 영향, 대체 처리, 책임자, 재검토 조건을 붙인다. 그래야 나중에 몰래 되돌아오거나 누락으로 오해되지 않는다.

“범위 밖”은 “아무도 안 한다”가 아니다. 기존 운영이 계속되는지, 다른 프로젝트가 맡는지, 수동 절차가 남는지, 영향을 받아들이는지 명시한다. 법정 의무, 안전·보안, 목표 달성의 필수 조건은 일정이 촉박하다는 이유만으로 제외할 수 없다. 그런 경우 목표·기간·자원을 다시 협상해야 한다.

9. 컨텍스트 다이어그램

컨텍스트 다이어그램컨텍스트 다이어그램관심 시스템의 경계와 외부 사용자·시스템·정보 흐름을 한눈에 보이는 그림이다.은 관심 시스템을 하나의 상자로 놓고 외부 사람·시스템 및 경계를 넘는 정보·사건을 보여 주는 그림이다. 내부 설계를 설명하는 구성도와 목적이 다르다. IREB 용어집은 시스템 맥락을 요구사항을 정의하고 이해하는 데 관련 있는 주변 환경으로 설명한다. 다이어그램은 그 맥락을 빠르게 합의하고 누락된 인터페이스를 찾는 도구다.

읽는 순서는 중앙 경계, 외부 대상, 들어오는 흐름, 나가는 흐름이다. 화살표에는 “API 호출” 같은 기술보다 업무 의미를 먼저 쓴다. 알림 하나가 아니라 알림 요청과 전송 결과를 나누면 신청 결과가 확정되었는데 통지만 실패한 경우가 보인다. 교무 담당자의 규칙 변경과 예외 결정도 단순 사용자 조작이 아니라 권한 있는 업무 사건으로 나타낸다.

작성 절차는 다음과 같다.

1. 관심 시스템의 이름과 목적을 한 문장으로 합의한다.
2. 목표·업무 흐름·후보의 주체와 데이터 출처에서 외부 대상을 찾는다.
3. 각 대상과 주고받는 사건·데이터를 방향과 함께 적는다.
4. 정상뿐 아니라 실패·정정·변경 통지와 운영 흐름을 더한다.
5. 각 화살표에 소유자, 요구 후보, 계약과 미해결 쟁점을 연결한다.
6. 경계 안 요소를 지나치게 그렸다면 별도 내부 모델로 옮긴다.

컨텍스트 다이어그램은 정답 그림이 아니다. 필요하면 업무 관점, 데이터 관점, 운영 관점으로 나눌 수 있다. 완성 기준은 모든 서버를 그린 것이 아니라 목표에 관련된 외부 책임과 경계 상호작용이 빠짐없이 검토되었는가이다.

10. 범위 변경

범위는 한 번 승인하면 얼어붙는 목록이 아니다. 도출과 분석이 반복되고 정책·외부 시스템·근거가 바뀌면 범위도 달라질 수 있다. 중요한 것은 변화를 막는 것이 아니라 영향을 알고 권한 있는 사람이 결정하며 기준선을 갱신하는 것이다. IIBA의 Business Analysis Standard도 요구사항 추적·유지·우선순위·변경 평가·승인을 하나의 생명주기 관리 영역으로 다룬다.

범위 변경 요청에는 최소한 다음이 있어야 한다.

• 바꾸려는 포함·제외·경계와 요청자
• 새 정보와 출처, 바꾸지 않을 때의 영향
• G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.·BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.과의 기여 또는 충돌
• 관련 요구·업무·데이터·외부 인터페이스
• 일정·비용·위험·운영·검증 영향
• 대안, 권고안, 결정권자와 결정 기한
• 승인·거절·보류 결과, 근거와 재검토 조건

예를 들어 “대기명단을 이번 출시에 넣자”는 요청이 오면 인기 기능이라는 주장만 보지 않는다. 반복 제출을 줄이는 근거, 정원·우선순위 정책, 취소 시 자동 승급의 공정성, 알림과 응답 기한, 추가 운영 부담, 핵심 흐름과의 의존성을 분석한다. 넣기로 했다면 제품·기능·데이터·외부 인터페이스 범위와 계획을 함께 바꾼다. 제외한다면 대체 처리와 재검토 조건을 남긴다.

범위 기준선에는 범위 문장, 컨텍스트 다이어그램, 내부·외부 책임표, 제외 목록과 미확인 가정을 묶는다. 변경 뒤 일부 산출물만 고치면 경계가 다시 모순된다. 검토 질문은 누가 새 책임을 맡는가, 기존 제외나 인터페이스가 달라졌는가, 관련 후보와 목표의 추적이 유지되는가, 아직 사실이 아닌 내용을 확정하지 않았는가이다.

11장의 결과로 수강신청 제품은 판정·상태·기록·안전한 실패와 복구 지원을 책임지고, 인증·학사정보·강좌·알림은 외부 서비스로 다루는 경계 초안을 얻었다. 프로젝트는 필요한 운영 절차와 측정 정비까지 포함하되 정책 전면 개정과 인증 교체는 제외 후보로 남겼다. 다음 장은 이 경계 안의 요구를 평평한 목록으로 두지 않고 계층과 관계로 구조화한다. 그때 사용할 입력은 범위 안 요구 후보, 컨텍스트 다이어그램의 상호작용, 제외 결정, ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다., ASM-001–ASM-004ASM-001–ASM-004ASM-001: 결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다. · ASM-002: 규칙 버전 제공 여부 미확인. · ASM-003: 처리 보류가 좌석을 점유하는가? · ASM-004: 직전 학기 첫 30분 자료가 비교 가능한 기준선이다이다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로