39장. 운영과 유지보수의 요구사항

운영 중 들어오는 장애·문의·정책 변경을 요구사항 지식으로 되돌리고 관측·복구·변경 책임을 지속적으로 관리한다.

이번 장에서 해결할 질문

학습 목표

• “운영 중 발견되는 장애·문의·정책 변경을 요구사항 지식으로 어떻게 환류하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

운영에 들어간 뒤에도 요구사항은 끝나지 않는다. 장애, 문의, 규정 변경, 성능 저하와 새로운 사용자 집단은 기존 요구의 가정이 달라졌음을 보여 주며, 임시 운영 조치가 장기적인 시스템 동작으로 굳기도 한다. 유지보수 요청 역시 근거와 영향을 분석해야 한다.

이 장에서는 운영 관측과 지원 기록을 요구 변경의 입력으로 바꾸고, 수정·개선·예방·적응 요구를 구분한다. 서비스 수준서비스 수준가용성·응답 시간·복구처럼 운영 서비스가 약속하고 측정해야 하는 성과 범위다., 데이터 보존, 보안과 외부 연계 책임을 지속적으로 확인해 운영 현실과 요구 기준선이 어긋나지 않게 관리하는 방법을 다룬다.

1. 장애

프로젝트가 검수됐다고 요구사항의 생명주기가 끝나지는 않는다. 운영에서 실제 부하·사용자·데이터·외부 시스템을 만나면 설계 때 보지 못한 사실이 드러나고, 정책과 기술 환경도 바뀐다. 장애·민원·개선 요청·법제도 변경은 모두 요구사항의 입력이 될 수 있지만 티켓 문장을 그대로 요구로 구현해서는 안 된다.

ISO/IEC 20000-1은 서비스 관리 시스템을 수립·구현·유지하고 지속적으로 개선하기 위한 요구를 다루며 2023년에 현행성이 확인됐고 2024년 개정사항이 있다. ISO/IEC 20000-2은 그 적용 지침이다. 특정 도구·조직도를 강요하기보다 서비스 요구, 계획·전환·제공·개선과 측정·검토를 연결하는 관점이 이 장에 중요하다.

이 사례에는 실제 운영 사건과 서비스 수준 계약이 없다. INC, PRB, OPS, REG, CHG 식별자는 교육용 후보이며 장애가 실제 발생했다거나 조치가 승인됐다는 뜻이 아니다.

장애는 합의한 서비스의 정상 제공이 중단되거나 품질이 저하된 사건이다. 요구사항 결함, 구현 결함, 용량, 데이터, 외부 연계, 운영 절차 등 원인은 다양하다. 장애 대응의 첫 목적은 안전한 서비스 복구와 피해 제한이고, 원인·영구 개선 요구 도출은 증거를 보존한 뒤 이어진다.

INC-ENR-001INC-ENR-001 · 프로젝트 항목이 규칙 시간 초과와 내부 무제한 재시도의 결합이라면 시간 제한·회로 차단만 고치지 않는다. 후보를 “피크 시간에 규칙 서비스 응답이 지연되고 일부 학생이 결과를 알 수 없어 반복 제출했다”로 둔다. 이 문장만으로 원인이 규칙 서비스인지, 내부 재시도인지, 화면의 접수 표현인지 알 수 없다. 먼저 관찰 사실과 추정을 분리한다.

심각도와 우선순위는 신고자의 직급이나 티켓 수만으로 정하지 않는다. 영향 사용자 수, 신청 기회·데이터·권리 손상, 안전·보안, 지속 시간, 우회 가능성과 피크 시점을 본다. 소수 학생에게만 생긴 객체 인가 오류는 트래픽 장애보다 심각할 수 있다.

복구 중에도 요구를 지킨다. 규칙 서비스가 느리다고 검사 생략·자동 승인으로 우회하면 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.을 위반한다. 운영자가 DB 상태를 직접 바꿔야 한다면 사전 승인된 비상 절차, 최소 권한, 전후 대사와 감사가 필요하다. “서비스가 열렸다”만으로 복구 완료하지 않고 신청·좌석·결정·알림의 일관성과 보류 후속 처리를 확인한다.

장애 종료 뒤에는 결함 수정, 운영 절차 개선, 모니터링·용량·회복 요구와 정책 결정을 분리한다. 같은 증상이 여러 원인을 가질 수 있으므로 개인을 탓하는 서술 대신 사건 시간선, 기여 조건과 방어선 실패를 분석한다. 복구 속도를 높이려다가 증거·재발 방지를 잃지 않는다.

2. 개선 요청

개선 요청은 서비스가 고장 나지 않았어도 사용자 가치·효율·품질·운영성을 높이자는 제안이다. “검색 필터 추가”, “알림 발송”, “대기순번 표시”는 해법 요청이며 먼저 어떤 문제·결과를 위한 것인지 정제한다.

운영 요청 분류표 후보:

OPS-IMP-001OPS-IMP-001 · 프로젝트 항목후보 “거절 사유를 더 자세히 보여 달라”를 그대로 구현하면 내부 규칙, 다른 학생 정보와 민감 학적 사유를 노출할 수 있다. 후보 “거절 사유를 더 자세히 보여 달라”를 그대로 구현하면 내부 규칙, 다른 학생 정보와 민감 학적 사유를 노출할 수 있다. 문제는 학생이 자신의 다음 행동을 판단하기 어렵다는 것일 수 있다. 공개 가능한 사유 범위, 문의 유형·사용자 관찰, QR-006QR-006 · 품질 요구대표 사용자는 신청·상태 과업과 공개 사유의 다음 행동을 합의한 성공 기준으로 이해해야 한다, QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다을 확인하고 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다., UI-001UI-001 · 프로젝트 항목적용·미적용 사유와 정정·이의 경로.의 변경인지 문구 개선인지 구분한다.

개선 요청에는 예상 outcome, 근거, 영향 사용자, 긴급도·시행 시점, 대안, 위험·비용, 측정과 요청자를 기록한다. 요청 수가 많다는 사실은 문제 규모의 신호일 수 있지만 중복 캠페인·표본 편향도 확인한다. 조용히 우회하거나 서비스를 포기한 사용자는 티켓에 나타나지 않는다.

우선순위는 장애보다 낮다는 고정 규칙을 두지 않는다. 현재 장애가 아니어도 학칙 시행일, 인증서 만료, 지원 종료, 접근성 장벽처럼 늦추면 큰 장애가 되는 개선이 있다. 반대로 임원의 아이디어도 목표·증거·위험이 낮으면 보류할 수 있다. 결정과 근거를 요청자에게 설명한다.

개선이 승인되면 기존 요구 ID를 새 버전으로 바꾸는지, 파생 요구를 추가하는지 결정하고 설계·시험·운영 문서를 갱신한다. 배포 뒤 예상 outcome과 보호 지표를 관찰해 요청 종료가 아니라 효과 확인까지 연결한다.

3. 사용자 민원

사용자 민원은 서비스 경험·권리·피해에 대한 중요한 증거지만 한 건의 표현이 곧 보편 요구는 아니다. 민원 원문과 사용자의 맥락을 보존하면서 개인정보를 최소화하고, 사실·해석·요청 해법을 분리해 분석한다.

예를 들어 “분명 신청했는데 사라졌고 다시 누르니 중복이라고 한다”는 민원에서 확인할 것은 다음과 같다.

• 신청 의도·요청 ID·접수 ID와 응답 유실 여부
• 화면이 접수와 승인을 어떻게 표현했는지
• 같은 신청의 현재 상태와 중복 판별 근거
• 다른 학생·강좌에도 같은 패턴이 있는지
• 사용자 피해와 즉시 복구·정정 필요
• FR-002FR-002 · 기능 요구인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다., FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다., FR-004FR-004 · 기능 요구같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다., UI-001UI-001 · 프로젝트 항목적용·미적용 사유와 정정·이의 경로.의 충족 여부

민원 대응과 제품 분석을 분리하되 연결한다. 개인 사례에는 현재 상태 확인, 정정·이의·보상과 안전한 안내가 필요하다. 집계 분석은 동일 증상·상황·사용자 집단·버전·채널을 묶어 시스템 문제를 찾는다. 분석을 위해 민원 원문을 넓게 공유하거나 민감정보를 장기 보관하지 않는다.

민원 건수 감소를 성공으로 단정하지 않는다. 문의 경로가 어려워졌거나 자동 답변이 사용자를 막았을 수 있다. 해결 시간, 재문의, 정정 성공, 상태 이해, 사용자 집단별 접근성과 실제 서비스 지표를 함께 본다. 지원 담당자가 반복해서 수동 확인하는 지식은 운영 요구의 중요한 원천이므로 알려진 오류·절차와 요구 저장소에 반영한다.

민원이 학칙의 공정성이나 공개 범위를 문제 삼으면 운영팀이 임의로 정책을 바꾸지 않는다. 적용 규칙·시점과 판정 근거를 보존하고 정책·법무·학사 책임자에게 결정 가능한 질문으로 올린다. 결과와 시행 범위를 민원·요구·변경 기록에 연결한다.

4. 법제도 변경

법제도 변경에는 법률·시행령·고시뿐 아니라 학칙, 개인정보·보안 정책, 접근성 기준, 계약·감사 의무와 기관 내부 규정이 포함될 수 있다. 제목이 비슷한 개정 소식만 보고 구현하지 않고 공식 원문, 공포·시행일, 경과조치, 적용 대상·지역·서비스와 해석 책임자를 확인한다.

변경 감시부터 요구 반영까지의 흐름은 다음과 같다.

학칙이 졸업예정자 우선 신청을 신설했다고 가정해도 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.을 즉시 승인하지 않는다. 실제 원문, 적용 학기, 졸업예정자 판정 시점, 동률·예외·소급, 공개·이의와 기존 좌석 정책을 확인한다. 시행일까지 필요한 임시 절차와 시스템 변경, 데이터 제공 책임을 비교한다.

법제도 요구 후보에는 원문 조항·버전, 적용 해석, 의무 주체, 발효·종료, 영향받는 서비스·데이터, 증거·보존, 예외와 승인자를 둔다. 법령 문장을 그대로 시스템 요구로 복사하지 않고 조직이 무엇을 해야 준수되는지 업무·시스템·운영 통제로 분해한다. 해석은 분석가가 독단적으로 확정하지 않는다.

변경하지 않았을 때의 준수·사용자 피해와 변경했을 때의 전환·오류 위험을 함께 본다. 긴급 시행이면 기능 비활성화, 제한 수동 절차, 단계 배포 같은 임시 통제를 둘 수 있지만 책임·기한·감사와 종료 조건을 명시한다. 임시 통제가 영구 관행이 되지 않게 추적한다.

5. 시스템 변경

시스템 변경은 사용자 기능 요청뿐 아니라 인증 공급자 버전, 규칙 API, 운영체제·DB·브라우저 지원, 클라우드·네트워크, 보안 패치, 인증서, 데이터 스키마와 관찰 도구의 변화다. 외부 시스템이 바뀌어 내부 코드 한 줄만 고치면 될 것처럼 보여도 서비스 요구와 회귀 범위에 영향을 줄 수 있다.

CHG-AUTH-001CHG-AUTH-001 · 프로젝트 항목후보로 외부 인증 연계가 새 토큰 형식과 세션 정책으로 바뀌는 상황을 보자. 후보로 외부 인증 연계가 새 토큰 형식과 세션 정책으로 바뀌는 상황을 보자.

기술 변경을 요구사항과 무관한 유지보수로 분류하면 사용자·업무 불변조건이 시험에서 빠진다. 반대로 모든 패치에 전체 요구 분석을 요구하면 긴급 보안 대응이 늦어진다. 표준·긴급·일반·중대 변경처럼 위험·가역성·영향에 따라 검토·승인·시험 깊이를 조정한다.

변경 계획에는 목적·근거, 영향 구성항목, 선행조건, 배포 순서, 호환 구간, 데이터 변화, 관찰·성공·중단 기준, 롤백·롤포워드, 사용자·지원 공지와 책임을 둔다. 롤백이 데이터 스키마·외부 계약 때문에 불가능하면 그 사실과 복구 대안을 미리 검증한다.

설정 변경과 기능 토글도 코드가 아니라는 이유로 통제 밖에 두지 않는다. 우선권 규칙·시간 제한·캐시 신선도·재시도 횟수는 서비스 결과를 바꾼다. 누가 언제 왜 바꿨는지, 어떤 버전과 사용자에게 적용됐는지 감사하고 회귀 요구와 연결한다.

6. 영향 분석

영향 분석은 “수정 파일 세 개, 2일” 같은 개발 견적에 머물지 않는다. 변경의 필요·범위·권리, 업무·사용자, 규칙·데이터·연계·품질, 운영·조직·계약, 시험·전환과 변경하지 않을 때의 위험을 양방향 추적으로 확인한다.

입력은 변경 원문과 근거, 현행 기준선·구성, 운영 지표·사건, 관련 계약·정책과 알려진 위험이다. 분석 결과에는 대안, 영향 대상·책임자, 비용·기간·위험, 필요한 승인과 검증·롤백 조건을 둔다.

추적 사슬을 순방향과 역방향으로 읽는다.

영향이 없다는 판단도 근거를 남긴다. 예를 들어 인증 공급자 로고 변경은 업무 규칙에 영향이 없을 수 있지만 접근성 이름·피싱 혼동·캐시 배포는 확인해야 한다. 분석 깊이는 위험에 비례하되 “코드 변경 없음”을 “서비스 영향 없음”으로 바꾸지 않는다.

긴급 장애에서는 복구 전 완전한 분석이 불가능할 수 있다. 안전 불변조건과 영향 범위를 빠르게 확인해 임시 변경을 승인하고, 사후에 누락 영향·영구 요구·회귀·문서를 보완한다. 긴급 절차는 분석 면제가 아니라 시점과 권한이 조정된 통제다.

영향분석 결과가 일정·비용·위험 허용 범위를 넘으면 범위 축소, 단계 전환, 대체 통제, 시행 연기 협의 또는 변경 거절을 비교한다. 가장 싼 구현만이 아니라 변경하지 않을 비용과 운영 부담까지 결정권자에게 보여 준다.

7. 회귀 요구사항

회귀 요구사항은 과거 테스트 케이스 목록이 아니다. 변경 뒤에도 유지해야 할 기존 사용자 결과, 업무 규칙, 품질·보안 불변조건, 데이터·운영 능력과 계약 의무를 명시한 집합이다. 테스트는 이를 확인하는 수단이다.

수강신청의 회귀 요구 후보:

회귀 범위는 변경 영향과 장애 위험으로 선택한다. 인증 변경은 모든 업무 규칙을 다시 계산할 필요가 없을 수 있지만 제출·조회·취소의 주체·세션·직접 API 접근과 개인정보 로그는 깊게 본다. 규칙 정책 변경은 판정 결정표뿐 아니라 좌석 경합, 사유 공개, 운영 정정과 과거 신청 버전을 포함한다.

자동화 가능한 계약·상태·인가 시험은 배포 파이프라인에서 빠르게 실행하고, 동시성·복구·성능·접근성·운영 리허설은 위험과 환경에 맞춘 주기로 실행한다. 자동화 비율보다 어떤 불변조건이 어느 환경에서 확인됐는지, 미실행·불안정 시험과 잔여 위험을 본다.

장애 사후 검토는 회귀 요구를 갱신하는 중요한 게이트다. INC-ENR-001INC-ENR-001 · 프로젝트 항목이 규칙 시간 초과와 내부 무제한 재시도의 결합이라면 시간 제한·회로 차단만 고치지 않는다.이 규칙 시간 초과와 내부 무제한 재시도의 결합이라면 시간 제한·회로 차단만 고치지 않는다. 부하 제어, 보류 적체 경보, 재평가 속도, 사용자 안내, 운영 대사와 공급자 연락 절차를 새 요구·모니터·시험으로 연결한다.

조치 티켓이 닫혔다고 사후 검토가 끝나지 않는다. 변경이 배포되고 회귀 요구와 관찰 지표가 실제로 충족됐는지, 같은 원인이 다른 경로에 남아 있지 않은지 확인한다. 효과가 없으면 문제 정의와 대안을 다시 검토한다.

11부의 다섯 환경은 형식과 결정 주기가 다르지만 공통 원리는 유지된다.

이 장에서 정리한 결과는 운영 요청 분류표, 장애·민원 증거 기록, 법제도·시스템 변경 흐름, 변경 영향표, 회귀 요구 목록, 사후 검토 기록이다. 프로젝트 환경이 달라도 요구사항 공학은 문서 형식이 아니라 필요를 근거로 판단하고 결과를 검증하며 변경의 책임과 영향을 추적하는 활동으로 남는다. 다음 부에서는 이 공통 원리를 보안·데이터·AI 같은 전문 영역에 적용한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로