5장. 비즈니스와 업무를 이해한다

문제가 실제 업무의 어느 단계와 규칙·데이터·역할·외부 시스템에서 생기는지 현행과 목표 흐름으로 확인한다.

이번 장에서 해결할 질문

학습 목표

• “조직의 목표·업무 흐름·규칙에서 소프트웨어가 바꿔야 할 지점을 어떻게 찾는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

문제를 한 문장으로 정리했다고 해서 업무를 이해한 것은 아니다. 같은 신청 실패도 학생의 준비 단계, 교무 담당자의 예외 처리, 외부 학사 규칙 서비스의 판정 시점에 따라 원인과 책임이 달라진다. 화면만 관찰하면 실제로 결정을 만드는 규칙과 데이터 이동을 놓치기 쉽다.

이 장에서는 현재 업무가 시작되어 끝나는 흐름을 역할·활동·정보·규칙·외부 시스템 관점에서 살펴본다. 현행 흐름과 목표 흐름을 비교해 바꿔야 할 지점과 유지해야 할 통제를 구분하고, 이후 요구 도출에서 누구에게 무엇을 물어야 하는지 근거를 마련한다.

1. 조직과 업무

요구사항은 화면 안에서 태어나지 않는다. 조직이 달성하려는 결과, 그 결과를 만들기 위해 사람이 수행하는 업무, 판단을 제한하는 규칙과 사용되는 데이터가 먼저 존재한다. 비즈니스라는 말도 영리 활동만 뜻하지 않는다. 대학처럼 교육·행정 목적을 가진 조직에서도 가치, 자원, 권한과 성과를 다루는 활동은 비즈니스 분석의 대상이다. IIBA Business Analysis Standard는 비즈니스 분석을 맥락 안에서 필요를 정의하고 이해관계자에게 가치를 주는 변화를 가능하게 하는 실천으로 설명한다.

수강신청 화면만 보면 학생이 강좌를 검색하고 신청 버튼을 누르는 일이 전부처럼 보인다. 실제 업무는 훨씬 길다. 교무처가 학사 일정을 정하고, 학과가 강좌·담당 교수·정원과 제한 조건을 등록하며, 학생이 장바구니를 구성하고, 본 신청에서 여러 규칙을 통과한 결과가 학적에 반영된다. 이후 정원 조정, 예외 승인, 취소, 폐강과 대체 안내가 이어진다. FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 자동 판정은 이 업무 사슬의 한 부분일 뿐이다.

조직을 부서도만 보고 이해해서는 안 된다. 공식 조직과 실제 업무 경로가 다를 수 있기 때문이다. 학칙은 교무처가 소유하지만 전공 제한의 실무 해석은 학과 사무실이 하고, 장애학생의 대체 절차는 지원센터가 안내하며, 장애 시 최종 복구는 IT 운영팀과 교무 담당자가 함께 결정할 수 있다. 그래서 조직 분석에는 목적, 업무 결과, 결정 권한, 실행 역할과 인계 지점을 기록한다.

최소 판단 질문은 네 가지다. 이 업무가 만들어 내는 결과는 무엇인가? 그 결과의 수혜자와 책임자는 누구인가? 어느 결정이 어느 조직의 권한인가? 소프트웨어가 없어도 수행되어야 할 절차는 무엇인가? 답이 부서 이름과 화면 목록에 머문다면 업무를 아직 이해하지 못한 것이다.

2. 업무 프로세스

업무 프로세스는 특정 결과를 만들기 위해 연결된 활동, 결정, 사건과 인계의 흐름이다. 화면 전환 순서와 같지 않다. 화면은 사용자가 보는 접점이고 프로세스는 화면 밖의 승인, 대기, 외부 연계, 예외와 수작업까지 포함한다. OMG의 BPMN 2.0.2 공식 사양은 프로세스 참여자, 활동, 사건, 게이트웨이와 메시지 흐름을 표현하는 표기법을 제공한다. 이 장의 목적은 BPMN 기호를 모두 익히는 것이 아니라 누가 언제 무엇을 받아 어떤 결과를 넘기는지 빠뜨리지 않는 데 있다.

현행 수강신청의 상위 흐름을 텍스트로 먼저 그려 보자.

각 단계에는 시작 사건, 입력, 수행자, 규칙, 출력과 종료 조건을 붙인다. 특히 “오류 시 담당자가 처리한다”로 예외를 뭉개지 않는다. 누가 어떤 목록을 받아 어떤 근거로 승인·거절·보류를 결정하고, 결과를 어디에 기록하며, 기한 안에 처리되지 않으면 무엇이 일어나는지 풀어야 한다. IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 외부 서비스 장애 시 보류는 이 예외 흐름에서 확인된 요구다.

프로세스도가 충분한지는 그림의 아름다움이 아니라 질문에 답하는지로 판단한다. 시작과 끝이 합의되었는가? 정상·대안·예외 흐름이 있는가? 부서 사이 인계와 대기 시간이 보이는가? 각 결정에 적용되는 규칙과 필요한 데이터가 연결되는가? 아직 관찰하지 못한 흐름은 사실처럼 그리지 않고 ‘확인 필요’로 남긴다.

3. 업무 규칙

업무 규칙은 조직의 행동이나 의사결정을 지배하고 안내하는 명제다. 프로세스의 “무엇을 언제 수행하는가”와 규칙의 “어떤 조건에서 무엇을 허용·금지·분류하는가”를 분리해야 한다. 한 규칙은 여러 프로세스에서 재사용될 수 있고, 규칙이 바뀌어도 전체 흐름은 유지될 수 있다. 반대로 화면의 if 문은 구현된 로직일 뿐, 그 자체로 유효한 업무 규칙의 근거가 되지 않는다.

OMG SBVR 1.5는 조직 관점의 업무 어휘·사실·규칙을 정밀하게 표현하기 위한 공식 사양이다. 모든 프로젝트가 SBVR로 명세해야 한다는 뜻은 아니다. 적어도 규칙을 코드에서 역추정하지 말고, 조직이 쓰는 용어로 별도 식별하며 출처와 소유자를 붙여야 한다는 실무 원칙을 얻을 수 있다.

SR-001SR-001 · 시스템 요구멱등 처리 항목.은 이 규칙들을 시스템 수준의 평가 책임으로 묶고, FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.은 소프트웨어가 현재 적용되는 규칙과 강좌 상태로 판정하도록 한다. DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.이 규칙 버전을 기록하는 이유도 나중에 같은 요청이 왜 승인 또는 거절되었는지 설명하기 위해서다.

규칙 검토에서는 문장의 진위만 묻지 않는다. 용어가 정의되었는가? 권한 있는 출처와 소유자가 있는가? 적용 시작·종료 시점과 우선순위가 있는가? 예외 승인자는 누구이며 감사 흔적을 남기는가? 코드와 문서가 다르면 어느 쪽을 고칠지 결정할 수 있는가? 답할 수 없다면 규칙은 구현 준비가 끝난 것이 아니다.

4. 업무 데이터

업무 데이터는 조직이 업무 사실을 표현하고 판단과 결과를 남기는 정보다. 데이터베이스 테이블과 동일하지 않다. ‘학생’, ‘강좌’, ‘신청’, ‘판정’, ‘규칙 버전’은 업무 개념이고, 이를 어느 저장소의 몇 개 테이블로 구현할지는 설계다. 이 경계를 지키면 기존 테이블 구조가 새 요구를 제한하는 일을 줄일 수 있다.

수강신청 판단에는 적어도 학생 자격과 소속, 이수 과목, 신청 가능 학점, 강좌 정원과 현재 신청 수, 시간표, 제한 조건, 우선순위 자격, 신청 상태가 필요하다. 결과 설명과 복구에는 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.에 정의한 학생·강좌 식별자, 요청 시각, 결과, 사유 코드, 적용 규칙 버전과 최종 상태 변경 시각이 필요하다. ‘현재 정원’처럼 시간에 따라 바뀌는 값은 어느 시점의 진실인지도 기록해야 한다.

CRUDCRUD데이터 책임을 생성(Create)·조회(Read)·변경(Update)·삭제(Delete)로 나눠 확인하는 틀이다. 표는 데이터의 생성(Create), 조회(Read), 변경(Update), 삭제(Delete) 책임을 빠르게 살피는 도구다. 삭제가 곧 물리 삭제를 뜻하지는 않으며 보존, 익명화, 상태 종료도 함께 검토한다.

데이터 분석의 완료 기준은 필드가 많다는 것이 아니다. 같은 용어가 조직마다 같은 뜻인지, 원본 시스템과 소유자가 누구인지, 생성·변경 시점과 품질 기준이 있는지, 민감한 데이터의 접근·보존·삭제 근거가 있는지, 오류 시 복구할 수 있는지를 설명해야 한다.

5. 조직과 역할

역할은 사람이 특정 업무 상황에서 맡는 책임과 권한이다. 직책이나 개인 이름과 같지 않다. 한 사람이 학과 담당자와 예외 승인자 역할을 동시에 맡을 수 있고, 교무처라는 조직 안에서도 정책 소유자·운영 담당자·감사 담당자가 다를 수 있다. 역할을 개인에게 바로 묶으면 인사 이동 때 요구사항의 책임까지 사라진다.

수강신청 업무에서 역할을 결과 중심으로 나눈다.

책임표를 만들 때 ‘참조’와 ‘승인’이 너무 많은지 살핀다. 모든 부서가 승인해야 한다면 아무도 제때 결정하지 못하고, 한 사람이 정책·구현·예외 승인까지 맡으면 통제가 약해질 수 있다. RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 정원 소유자와 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.의 우선 배정 변경 권한, IR-001IR-001 · 인터페이스 요구자격·운영 흐름. 발생 시 보류 해제 권한을 분명히 하지 못하면 소프트웨어 동작도 확정할 수 없다.

판단 기준은 각 주요 업무 결과에 실행 책임자와 최종 결정권자가 있고, 역할 사이 인계와 부재 시 대체가 드러나며, 시스템 권한이 업무 권한을 과도하게 넓히지 않는가이다.

6. 외부 시스템

외부 시스템은 이번 개발팀이 내부를 직접 설계·통제하지 않지만 업무 결과에 데이터나 서비스를 제공하거나 받는 시스템이다. 외부라고 해서 범위 밖인 것은 아니다. IREB 용어집의 시스템 경계 설명에 따르면 시스템 경계 밖의 관련 환경과 인터페이스도 요구사항을 이해하는 맥락이다.

수강신청 소프트웨어는 통합인증에서 사용자 신원을 받고, 학사정보 서비스에서 학적·이수·학점 원천 정보를 조회하며, 학사 규칙 판정 서비스에서 해당 정보와 규칙 버전에 따른 판정 결과를 받는다. 교과 시스템에서는 강좌 정보를 받고 알림 서비스로 결과를 보낼 수 있다. 사례 계획에 언급된 결제 시스템은 등록금 납부 여부가 신청 자격에 실제 영향을 주는지 확인한 뒤 맥락 포함 여부를 정한다. 이름만 익숙하다고 연결을 가정하지 않는다.

인터페이스마다 다음을 기록한다.

• 제공·수신 데이터의 업무 의미, 원본 소유자와 최신 시점
• 호출 또는 전달을 시작하는 주체와 순서, 정상 응답의 완료 조건
• 시간 제한, 중복·순서 뒤바뀜·부분 실패와 재시도의 의미
• 인증·권한·개인정보 노출 범위와 감사 기록
• 장애 연락처, 복구 책임, 변경 공지와 버전 호환 정책

IR-001-CIR-001-C · 인터페이스 요구> 학사 규칙 판정 서비스는 합의된 시간 안에 요청 식별자, 규칙 버전, 판정 결과 또는 계약된 오류 정보를 반환해야 한다.는 학사 규칙 판정 서비스의 응답 계약을, IR-001-RIR-001-R · 인터페이스 요구> 수강신청 소프트웨어는 합의된 시간 안에 유효한 판정 정보를 받지 못하면 신청을 자동 승인하지 않고 처리 보류 상태와 원인 코드를 기록·반환해야 한다.은 유효한 정보를 받지 못했을 때 수강신청 소프트웨어가 임의 승인하지 않고 처리 보류 상태와 원인 코드를 기록·반환하는 동작을 다룬다. 이 두 문장만으로는 정한 시간이 얼마인지, 보류를 누가 언제 재평가하는지, 학생에게 어떻게 알리는지 부족하다. 외부 시스템 분석은 API 목록이 아니라 실패해도 업무가 의미 있는 상태를 유지하는지까지 확인해야 끝난다.

7. 법률과 제도

법률과 제도는 구현 후 검수 항목이 아니라 문제·범위·업무 규칙의 출처다. 대학 수강신청에는 적용되는 학칙과 교과과정 규정, 개인정보 처리 근거와 보존 정책, 접근성 의무, 기록·감사 규정, 계약 조건이 영향을 줄 수 있다. 다만 “법 때문에 필요하다”는 말만 요구사항 근거로 쓰지 않는다. 정확한 조항, 적용 대상, 시행일, 해석 책임자와 시스템에 미치는 조건을 연결한다.

예를 들어 학생·강좌·판정 기록에는 개인정보가 포함될 수 있으므로 국가법령정보센터의 개인정보 보호법 현행 본문과 대학의 개인정보 처리방침·기록물 정책을 함께 확인해야 한다. 접근성은 장애학생지원센터의 의견과 적용 법령을 확인하고, 기술 기준 후보로 W3C WCAG 2.2 권고를 검토할 수 있다. WCAG가 모든 법적 의무를 자동으로 대신하거나 모든 사용자의 필요를 충족한다는 뜻은 아니다.

실무 기록은 근거 문서·조항 → 업무 의무 → 영향받는 프로세스·데이터 → 요구 후보 → 검증 책임으로 이어진다. 적용 법령과 학칙은 기관 유형과 시점에 따라 달라질 수 있으므로 법무·개인정보·접근성 책임자의 확인을 받는다. 분석가가 법률 해석을 단독으로 확정해서도, 전문가에게 전부 넘기고 소프트웨어 영향을 기록하지 않아서도 안 된다.

완료 기준은 관련 근거가 최신인지, 의무와 내부 정책·실무 관행이 구분되는지, 예외와 충돌을 결정할 권한이 있는지, 각 근거가 실제 요구와 시험·운영 증거로 이어지는지다.

8. 현재 업무 분석

현재 업무 분석은 앞 절의 조각을 하나의 설명으로 합친다. 입력은 4장4장. 문제를 정의한다해결책을 고르기 전에 실제 문제와 성공 기준을 어떻게 정의하는가?페이지로 이동의 문제 정의와 초기 범위, 실제 프로세스 관찰, 규칙·데이터·역할·외부 연계 목록, 지표와 사건 기록이다. 결과는 “현재 화면이 이렇다”가 아니라 문제가 어느 업무 단계와 조건에서 만들어지고 어떤 수작업으로 보완되는지 보여 주는 현행 모델이다.

수강신청 사례에서는 다음 순서로 분석한다.

1. 본 신청 전 강좌·정원·규칙이 어떤 승인 경로로 준비되는지 확인한다.
2. 학생 요청 한 건을 선택해 인증, 데이터 조회, 판정, 기록, 통지까지 추적한다.
3. 승인·거절·보류·중복·취소 사례를 각각 따라가며 상태 전이를 확인한다.
4. 첫 30분의 대기와 반복 요청, 문의, 수동 재처리를 프로세스 단계에 붙인다.
5. 문서 규칙과 실제 판정, 데이터 원본과 화면 표시가 다른 지점을 기록한다.

가상의 현행 분석에서 “결과 미확인 → 학생 반복 제출 → 중복 상태 분류 → 담당자 수동 확인”이라는 고리가 발견되었다고 하자. 이것은 ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다.을 뒷받침할 후보이지 아직 사실 확정이 아니다. 로그에서 같은 요청의 상관관계를 확인하고 학생 관찰과 담당자 처리 기록을 대조해야 한다. 외부 연계 지연이 없는데도 같은 현상이 발생한다면 원인 가설을 수정한다.

현재 업무 분석은 비효율을 비난하는 활동이 아니다. 수작업이 자동화가 놓친 중요한 예외나 통제일 수 있다. 왜 그 일이 생겼고 어떤 위험을 막는지 모른 채 제거하면 속도는 빨라져도 잘못된 승인이 늘 수 있다. 완료 여부는 문제의 증상과 영향이 프로세스·규칙·데이터·역할 중 어디에 연결되는지, 그리고 확인하지 못한 부분이 표시되어 있는지로 판단한다.

9. 목표 업무 설계

목표 업무는 현행 화면을 새 기술로 복제한 모습이 아니다. 목표 상태를 달성하는 데 필요한 업무 조건과 책임을 다시 구성한 것이다. 소프트웨어 기능뿐 아니라 규칙 정비, 데이터 품질, 승인 권한, 예외 처리, 교육과 운영 측정이 함께 바뀔 수 있다. 현행의 좋은 통제는 보존하고 불필요한 인계와 중복은 줄인다.

이 사례의 목표 업무 후보는 다음과 같다.

• 신청 접수와 판정을 분리해 학생이 접수 식별자와 처리 상태를 확인한다.
• 판정은 승인·거절만이 아니라 보류를 공식 상태로 다루고 재평가 책임과 기한을 둔다.
• 규칙은 소유자·시행일·버전·우선순위를 승인한 뒤 배포하며, 판정 기록이 그 버전을 참조한다.
• 같은 학생·강좌 요청의 중복 의미를 정하고 반복 제출이 새 신청을 만들지 여부를 합의한다.
• 교무 담당자는 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.의 사유와 상태 이력으로 문의·이의·복구를 처리한다.
• 운영팀은 QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.뿐 아니라 보류·오류·반복 요청·수동 재처리를 함께 감시한다.

이는 설계 확정이 아니다. 접수와 판정을 동기로 처리할지, 대기열을 둘지, 어떤 저장소를 사용할지는 여러 대안 중에서 결정한다. 목표 업무 설계의 판단 기준은 각 변화가 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.과 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.에 기여하는가, 새 위험과 역할 공백이 없는가, 예외 상황에서도 책임과 상태가 끊기지 않는가, 사람이 수행할 변화가 명시되었는가이다.

10. 현행과 목표의 차이 분석

차이 분석은 현행에 없는 기능을 찾는 일이 아니다. 같은 판단 축으로 현재 상태와 목표 상태를 비교하고, 그 간격을 줄이려면 어떤 능력·규칙·데이터·역할 변화가 필요한지 찾는 일이다. IIBA 표준의 변경 전략은 현행과 미래 상태의 차이, 대안과 위험을 평가해 변화 접근법과 해결 범위를 정하는 활동으로 제시된다. 작은 점진적 변화와 큰 전환 중 어느 하나를 항상 우월하다고 보지 않는다.

차이를 발견했다고 모두 소프트웨어 요구로 옮기지 않는다. 규칙 소유권 정비는 조직 조치, 기준선 수집은 분석·운영 조치, 상태 조회는 소프트웨어 요구일 수 있다. 하나의 차이가 여러 조치를 요구할 수도 있다. 반대로 현행 화면에 없다는 이유만으로 새 기능을 만들면 목표와 연결되지 않은 범위가 늘어난다.

이 장에서 정리한 결과는 현행·목표 프로세스 초안, RULE-001–RULE-005RULE-001–RULE-005RULE-001: 신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. · RULE-002: 승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. · RULE-003: 시간 충돌 판정. · RULE-004: 분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다. · RULE-005: 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다., 데이터 CRUD 표, 역할·외부 시스템 목록과 차이표다. 이 자료가 충분한지 확인하는 마지막 질문은 “누가 이 규칙을 결정하고, 누가 실행하며, 누가 결과의 영향을 받는가?”이다. 다음 장에서는 이 질문을 사용해 학생과 담당자뿐 아니라 정책·운영·보안·접근성·외부 서비스까지 이해관계자 지도로 확장한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로