IT 운영기획·서비스수준·ITSM

1. 서버는 정상인데 주문은 왜 실패할까

서버의 전원과 프로그램은 정상인데 고객은 결제 결과를 받지 못한다. 개발팀은 결제사에 문의하라고 하고, 결제사는 우리 주문번호를 모른다고 한다. 이때 부족한 것은 장비 한 대보다 어떤 결과를 약속했고, 누가 어떤 기록으로 복구를 판단할지 정한 운영체계다.

이 절에서는 주문서비스 한 개를 실제로 운영할 계획을 작성한다. 서비스 약속과 측정, 피크·장애 용량, 담당자, 사건·문제·변경·구성 기록을 연결한 뒤 10점 설명형과 25점 설계형 답안으로 옮긴다. 숫자는 모두 자체 교육용 가정이며 실제 회사의 운영 결과나 공식 채점기준이 아니다.

앞에서 배운 서비스 계층을 되짚는다

비즈니스·서비스·애플리케이션·데이터·플랫폼·인프라에서 비즈니스·서비스·애플리케이션·데이터·플랫폼·인프라는 제품 목록이 아니라 서로 다른 책임을 나타냈다. 이번에는 각 층의 정상 여부보다 전체 주문 결과와 층 사이의 인계 책임을 함께 판단한다.

운영기획은 결정하고, 운영관리는 실행·확인한다

IT 운영관리는 서비스 수준과 위험을 기준으로 애플리케이션·HW·NW·DB를 통합 운영하고, 역할·절차·측정·복구·변경을 통해 서비스 가용성과 품질을 지속적으로 유지·개선하는 체계다.

여기서 HW는 하드웨어, NW는 네트워크, DB는 데이터베이스를 뜻한다. 운영기획은 어떤 업무를 얼마만큼의 품질과 비용으로 유지할지 정하여 책임·용량·절차·확인 기준을 만드는 일이다. 운영관리는 그 계획을 실행하고 실제 서비스 결과와 차이를 확인하여 고치는 일이다.

예를 들어 ‘결제 결과가 불명확하면 주문을 확정하지 않고 담당자가 대조한다’는 결정과 담당자를 정하는 것은 기획이다. 오늘 발생한 미확인 결제 3건을 기록하고 결제사 결과와 대조하는 것은 관리다.

ITSM은 티켓 프로그램의 이름이 아니다

IT 서비스 관리(ITSM)는 서비스의 기획·전달·운영·개선을 가치·위험·프로세스·역할·증거로 관리하는 체계다. ITSM은 IT Service Management의 약어다. 티켓은 일을 식별하고 이력을 남기는 기록이고, ITSM은 그 기록을 누가 왜 만들고 어떤 결과까지 책임질지 정한 관리체계다.

ISO/IEC 20000-1:2018의 공개 미리보기 서문은 서비스 관리체계의 수립·실행·유지·지속 개선과 서비스 생애주기 관리를 설명한다. ITSM이 관리 활동 전체를 가리킨다면 이 표준은 그 관리체계에 대한 요구사항을 다룬다. 이 절은 공개 자료로 확인할 수 있는 범위를 다루며 표준 전문의 조항별 준수나 조직의 인증을 판정하지 않는다. ITIL은 이러한 관리를 위한 실무 지침이고, 도구 설치나 특정 절차명 나열만으로 적용이 완성되지는 않는다. [S1][S8]

이 절에서 확인한 실무 목적의 자료는 이름을 명시한 ITIL 4 공개 설명이다. 2026-09-12에 PeopleCert가 ITIL Version 5를 제공하는 사실도 확인했으므로 ITIL 4를 최신판이라고 부르지 않는다. Version 5 전체 실무 가이드의 대조나 표준 전문 감수는 이번 보강의 완료 범위가 아니다.

이 절의 지도: 약속에서 기록과 개선으로

표의 연결은 서비스 계획을 실행하고 그 결과를 되먹임하는 관계다. INC-17 기록 관계도의 복구·문제·변경·구성 가지를 함께 본다. 사건이 생길 때마다 반드시 문제와 변경이 하나씩 만들어진다는 직선 절차를 뜻하지 않는다.

측정 목표와 재시도에 관한 앞선 약속

요구에서 토폴로지·주소·라우팅·QoS·이중화까지에서 서비스 수준 목표는 측정 구간과 기간을 붙인 품질 목표였고, 정상·피크·장애 수요를 나누어 보았다. 시간초과·재시도·멱등성과 부분실패에서는 시간초과가 실행 실패의 증거가 아니므로 같은 요청의 식별자와 결과조회로 중복 효과를 통제했다. 이제 이 두 원리를 서비스수준 보고서와 결제 장애 절차에 적용한다.

2. 약속·목표·관측값을 구분한다

서비스 수준 협약(SLA)은 서비스 제공자와 이용자 사이에서 서비스 범위, 목표 수준, 측정방법, 책임과 예외를 합의한 약속이다. SLA는 Service Level Agreement의 약어다. 이 교육 사례에서는 약속을 못 지켰을 때 누구에게 무엇을 보고하고 개선안을 언제 제시할지도 합의한다. SLA가 반드시 금전 배상만을 뜻하는 것은 아니지만, 숫자 하나를 적었다고 합의 문서가 되는 것도 아니다. [S2]

서비스 수준 지표(SLI)는 제공한 서비스 수준의 한 측면을 측정 경계·집계 방법과 함께 수치로 나타내는 지표다. SLI는 Service Level Indicator의 약어다. 앞에서 배운 서비스 수준 목표(SLO)는 이 지표가 도달해야 할 값이다. ‘올바른 결과를 5초 안에 받은 비율’은 지표, ‘99.9% 이상’은 목표, 그 경계·책임·미달 시 조치까지 상대방과 합의한 것은 SLA다. [S2]

따라서 운영 보고서는 합의한 목표와 실제 관측값을 다른 칸에 쓴다. 내부적으로 더 엄격한 목표를 둘 수 있지만 고객 약속을 충족한 것과 내부 목표까지 충족한 것은 같은 판정이 아니다.

설계 사례 OP-S: 무엇을 서비스의 결과로 약속하는가

가상의 쇼핑몰 운영조직과 사업부가 아래 조건을 합의했다고 하자. 실제 계약서나 부하시험 결과가 아니라 이 절의 계산과 판단을 위한 입력이다.

정상 업무 거절은 카드 한도 부족처럼 실제로 확인된 거절을 정확히 반환한 경우다. ‘결제가 승인된 주문 비율’과 ‘요청을 올바르게 처리한 비율’을 혼동하지 않는다. 결과 미확인을 임의로 거절로 바꾼 응답, 저장 전에 완료라고 한 응답은 성공이 아니다.

이 약속의 측정 범위는 관문 이후다. 사용자의 통신망이나 관문 자체의 접속 실패까지 포함한 전체 고객 경험을 이 비율 하나로 대표하지 않는다. 접속 가능성은 아래의 별도 외부 관측으로 보완한다.

분모를 먼저 고정하고 결측은 숨기지 않는다

유효 요청은 인증·형식 요건을 충족하여 서비스가 처리해야 할 요청이다. 잘못된 형식의 거절은 별도 집계하되 서버 오류, 시간초과, 외부 결제사 장애, 계획 정비 중의 유효 요청을 분모에서 빼지 않는다. 재전송도 관문이 받은 요청 단위로 세며, 주문 건수와 중복 효과 여부는 요청 식별자로 따로 확인한다.

관문 기록에는 요청 식별자·수신시각·완료시각·결과 종류·기대 결과와의 일치·관련 주문/결제 식별자를 남긴다. 완료 기록이 없으면 5초 목표의 성공으로 세지 않는다. 수신 기록 자체가 유실되었다면 분모를 확정할 수 없으므로 보고서를 ‘측정 불완전’으로 표시하고 독립 집계와 대조한다. 기록 누락을 0건 장애라고 바꾸지 않는다.

관문 밖의 두 관측 지점에서 10초마다 접속과 승인된 시험용 거래를 확인한다. 두 지점 모두 30초 동안 실패하면 당직자에게 즉시 알리도록 한다. 이 외부 관측은 관문에 도착하지 못한 실패를 찾는 보조 장치이지 전체 실제 사용자의 성공률을 직접 측정한 것은 아니다. 지표의 이상적인 뜻과 실제 수집 지점의 한계를 함께 적는다. [S3]

같은 100만 건에서도 판정은 세 가지다

아래 A·B는 독립적인 두 가상 월의 집계다. 각 행의 요청 수는 서로 겹치지 않고 수신 기록은 완전하다고 가정한다. ‘5초 목표 미충족’에는 오류·미확인·틀린 결과와 5초 초과가 포함된다.

A의 5초 충족률은 (995000 + 4400) / 1000000 × 100 = 99.94%다. 고객 약속 99.9%는 충족하지만 내부 목표 99.95%에는 미달한다. 2초 충족률은 99.5%로 별도 지연 목표를 충족한다.

B의 5초 충족률은 99.86%, 2초 충족률은 98.5%로 두 목표에 미달한다. B에서 실패 1400건을 분모에서도 제외하면 998600/998600=100%가 되지만 이는 장애를 해결한 것이 아니라 측정 대상을 바꾼 것이다.

5초 경계는 ‘이하’다. 올바른 결과가 5000밀리초에 반환되면 그 시간 조건을 충족하고 5001밀리초면 미충족이다. 빠른 오류는 어느 시간 목표의 성공에도 넣지 않는다.

허용 실패 건수와 허용 중단시간은 서로 바꿔 쓰지 않는다

100만 유효 요청과 99.9% 목표에서는 미충족 허용량이 1000000 × 0.001 = 1000건이다. 내부 99.95% 목표의 허용량은 500건이므로 A의 600건은 내부 허용량보다 100건 많다. 이런 미충족 허용량을 오류 예산(error budget)이라고 부를 수 있지만, 불량 결과를 일부러 만들거나 데이터 손실을 허용한다는 뜻이 아니다. [S3]

별도의 시간 기반 예제 OP-T에서 30일을 모두 측정한다면 30 × 24 × 60 = 43200분이다. 시간 가용성 99.9%는 43200 × 0.001 = 43.2분, 99%는 432분의 중단에 대응한다. 이는 OP-S의 요청 기반 SLA를 시간 기반으로 바꾼 계약이 아니다.

초당 600건이 들어오는 2분 동안 모두 실패하면 600 × 2 × 60 = 72000건이다. 중단시간은 43.2분보다 작아도 1000건의 요청 오류 예산은 72배 사용한 셈이다. 월평균 또는 시간 비율만 보고 피크 장애의 피해를 가릴 수 없는 이유다.

3. 사건을 복구하는 일과 원인을 줄이는 일을 나눈다

고객이 주문 결과를 받지 못해 정상 서비스가 중단·저하된 상황은 사건(incident)으로 접수한다. 사건 관리의 우선 목적은 영향을 줄이고 정상 서비스를 신속하게 되찾는 것이다. 완벽한 원인 분석이 끝날 때까지 복구를 미루지 않는다. [S4]

예컨대 직전 배포 뒤 시간초과가 급증했는데 검증된 이전 버전으로 복원할 수 있다면, 안전한 되돌리기로 먼저 복구하고 원인 조사는 계속할 수 있다. 반대로 데이터 구조가 이미 되돌릴 수 없게 바뀌었다면 단순 버전 복원은 안전한 절차가 아니다. 담당자는 영향·대응·복구 확인시각과 아직 남은 영향을 기록한다.

비밀번호 초기화와 주문 장애는 같은 접수가 아니다

서비스 요청(service request)은 미리 정한 방식으로 처리할 수 있는 사용자의 요구다. 예를 들어 권한 있는 사용자의 비밀번호 초기화나 사용 안내 요청이 이에 해당한다. 서비스 데스크는 사용자 접점을 하나로 모으되 요청 유형에 맞게 담당자와 완료 기준을 나눈다.

초기화 요청도 승인·본인 확인을 생략할 이유가 되지는 않는다. 접수 건수를 줄이려고 장애 문의를 단순 요청으로 바꾸거나, 한 장애에 대한 여러 신고를 서로 무관한 장애 건수로 세지 않는다. 신고 기록과 실제 영향 사건을 연결한다.

문제 기록은 사건 기록을 지우는 상자가 아니다

문제(problem)는 실제 또는 잠재적인 사건 원인에 관한 관리 대상이다. 문제 관리는 원인, 임시 우회책과 알려진 오류를 관리하여 사건의 가능성과 영향을 줄이는 데 목적이 있다. 반드시 같은 장애가 여러 번 일어나야만 시작할 수 있는 것은 아니다. [S5]

OP-S에서는 한 달의 사건 12건이 같은 연결 설정 결함을 가리키면 각각의 영향·복구시간은 보존하고 PRB-3 하나에 연결한다. 원인을 알아냈다는 이유만으로 사건 12건의 이력이 1건으로 줄어들지 않는다.

PRB-3에는 ‘결제 응답 지연 시 연결이 회수되지 않음’이라는 검증할 원인 가설, 우회책의 적용 조건과 부작용, 영구 수정의 담당자·검증 계획을 기록한다. 원인을 확정하고 수정했어도 잔여위험이나 재발 관측이 남으면 그 상태를 드러낸다. 반대로 원인 조사가 끝나지 않아도 사건은 복구 확인 후 닫고 문제 조사를 이어갈 수 있다.

구성정보는 장비 목록에 버전과 관계를 더한다

운영에 필요하여 식별·관리하는 서비스 구성요소를 구성항목(configuration item, CI)이라고 부른다. 구성 관리는 항목 자체뿐 아니라 서비스와 항목 사이의 관계에 관한 정확하고 신뢰할 수 있는 정보를 필요한 때 제공하도록 한다. [S6]

‘어떤 버전이 어느 자원에서 어느 DB와 결제사를 쓰는가’를 알면 변경 영향과 장애 범위를 추적할 수 있다. 변경 승인 전의 기준 상태와 실제 반영 후 상태를 대조하며, 자동 수집값도 담당자·업무 관계와 일치하는지 확인한다. 장비 수가 정확해도 잘못된 의존 관계가 남으면 구성정보는 충분하지 않다.

4. 정상 합계가 아니라 고장 후 남는 용량을 계산한다

OP-S의 노드별 기준 처리율을 초당 300건, 설계에 사용할 비율을 70%로 가정한다. 한 노드의 계획 용량은 300 × 0.70 = 210건/초다. 나머지 30%는 변동·운영 부담을 위한 설계 여유이며 CPU 사용률 70%와 같은 지표가 아니다. 이 가정을 실제 서비스의 응답시간 조건에서 입증하는 부하시험은 아직 필요하다.

따라서 이번에는 4대를 선택한다. 식은 (노드 수 − 1) × 210 ≥ 600이며 같은 조건에서 3대는 기각한다. 4대의 장애 후 수요 대비 남는 용량은 30건/초다. 다섯 번째 노드는 성장·추가 장애 요구가 확인되면 검토하되 ‘많으면 좋다’는 이유만으로 비용을 정당화하지 않는다.

이 계산은 균등 분산, 같은 노드 성능, 전환 후 안정 상태라는 전제에 한정한다. 4대를 두 구역에 2대씩 두고 한 구역을 잃으면 420건/초만 남는다. 노드 한 대 장애를 견디는 설계를 구역 전체 장애까지 견디는 설계로 보고하지 않는다. 전환 중 요청 유실·세션·재분산 지연은 별도 시험한다.

앱만 늘려서는 결제사의 처리 한도를 늘릴 수 없다

같은 요청 혼합에서 DB가 700건/초, 네트워크 경로가 900건/초의 주문을 처리할 수 있고 외부 결제사의 신규 승인 호출 한도가 620건/초라고 가정한다. 주문 한 건당 신규 승인 호출은 최대 한 번이며 결과조회·재시도용 용량은 별도 계약으로 확보해야 한다.

단일 노드 장애 뒤의 전체 계획 한도는 min(630, 700, 900, 620) = 620건/초다. 피크 600건/초를 넘지만 결제사 쪽 여유는 20건/초뿐이다. 승인 재시도가 이 한도에 함께 들어가는 계약이라면 그 부하도 다시 계산해야 하므로 이 표만으로 운영을 승인하지 않는다.

플랫폼 담당자는 앱 용량, DB 담당자는 저장·잠금·복원, 네트워크 담당자는 연결 경로·장애 전환, 공급자 담당자는 호출 종류별 한도와 장애 대응을 각각 검증한다. ‘평균 CPU가 낮다’는 설명은 이 네 종류의 용량 증거를 대신하지 못한다.

OP-Q: 승인과 결과조회가 같은 호출 한도를 쓰는 별도 조건

이제 계약 조건만 달리한 자체 연습을 한다. OP-S의 ‘신규 승인 620건/초, 조회·재시도 별도’와 달리, OP-Q에서는 모든 앱 노드가 보내는 승인·조회·재시도를 합쳐 초당 620회까지라고 정한다. 성공·실패와 관계없이 실제 보낸 호출마다 한 번씩 세며, 다른 서비스의 호출은 없다고 가정한다. 같은 식별자를 사용하여 중복 청구를 막는 것과 공급자에게 보낸 호출 수를 줄이는 것은 별개다.

신규 주문 600건/초가 각각 승인 호출 한 번을 요구하고, 앞선 미확인 거래의 결과조회가 30회/초 필요하다면 총수요는 600 + 30 = 630회/초다. 여기서 조회 30회는 별도로 주어진 수요이지 주문 수의 일정 비율로 자동 계산한 값이 아니다. 총수요가 계약 한도보다 10회 많으므로 앱 노드를 늘리는 것만으로 이 조건을 충족할 수 없다.

조회 30회를 남기면 신규 승인 호출의 산술 상한은 620 − 30 = 590회/초다. 이 연습에서는 추가 변동을 위해 10회의 여유를 남겨 신규 승인을 최대 580회/초로 제한하는 안을 작성한다. 580과 여유 10은 교육용 선택값이지 공급자가 권고한 설정이나 시험으로 확인한 안전 한도가 아니다. 추가 승인 재시도가 발생하면 그 호출도 같은 합계에 넣어 배분을 다시 정해야 한다.

이 제한 운영안은 원래 피크 600건/초 요구의 충족이 아니다. 모든 신규 주문이 승인 호출을 필요로 하는 현재 조건에서는 초당 20건을 그대로 처리할 수 없다. 거절·지연된 유효 요청을 기존 서비스 지표의 분모에서 빼거나, 용량 부족을 카드 한도 부족 같은 정상 업무 거절로 바꾸어 성공 처리하지 않는다. 처음 대기 건수가 0이고 유입 600·처리 580이 일정하며 이탈도 없다고 가정하면 60초 뒤 대기는 (600 − 580) × 60 = 1200건 증가한다. 대기열에 넣는 것만으로 지속적인 과부하나 5초 응답 약속이 해결되지는 않는다.

산출물 OP-Q-1에는 ‘계약 합계 620, 조회 배분 30, 신규 승인 상한 580, 미배분 여유 10, 기존 피크 요구 미충족’을 함께 적는다. 공급자 담당자는 호출 집계 범위·시간창·순간 집중 허용 조건을 확인하고, 앱 담당자는 노드별이 아니라 서비스 전체의 호출 합계를 통제한다. 운영 담당자는 실제 호출과 미확인 거래·거절·지연을 대조하며, 서비스 책임자는 용량 증설·계약 변경 또는 제한 운영의 영향과 통지를 판단한다. 기록과 승인 없이 제한값을 적용했다는 이유만으로 운영 인수를 통과시키지 않는다.

조회 수요가 50회/초로 바뀌면 기존 안은 580 + 50 = 630으로 다시 한도를 넘는다. 같은 10회 여유를 남기려면 신규 승인 상한을 620 − 50 − 10 = 560회/초로 재계산해야 한다. 필요한 조회를 버려 장부를 맞추거나 미확인 거래를 완료로 바꾸는 대신, 늘어난 제한 영향과 재확인 조건을 책임자에게 올린다. 모든 수치는 공급자와 같은 집계 시간창으로 확인하고 실제 요청 혼합·응답시간·장애 전환 시험을 따로 수행한다. 이 표는 그 시험 결과가 아니라 조건이 바뀔 때 계획을 수정하는 계산 예다.

5. 누가 판단하고 누가 실행하는지 정한다

에스컬레이션(escalation)은 담당자가 해결하기 어렵거나 영향이 큰 상황을 필요한 전문 인력·권한 보유자에게 올리는 일이다. 전문팀의 지원을 받는 것과 서비스 중단·비용·고객 통지의 권한을 요청하는 것을 구분한다. 모든 연락은 사건 기록의 같은 시각표에 남긴다.

작은 조직에서는 한 사람이 여러 역할을 겸할 수 있지만 고위험 변경의 자기 승인까지 자동 허용하지 않는다. 당직 부재 시 대체자와 실제 연락 수단을 운영 인계 때 확인한다. 표에 역할 이름만 있고 담당·대체자와 권한이 없으면 운영 준비가 끝난 것이 아니다.

탐지부터 복구까지의 시간표를 미리 정한다

다음 등급과 시각은 자체 운영 규칙이다. ITIL이나 기술사 시험의 보편적 수치 기준이 아니다. 아래 조치 기한은 경보 확인·접수시각부터 세며, 고객 영향의 시작시각은 별도로 보존한다.

사건 발생시각을 알면 영향 시작부터 기록하며, 탐지시각으로 바꾸어 중단시간을 짧게 만들지 않는다. 요청이 0건이어도 접속 장애는 있을 수 있으므로 ‘100건 이상’ 조건만으로 중대 탐지를 막지 않는다. 외부 관측과 데이터 이상 경보는 별도로 작동한다.

예를 들어 14:00 장애가 시작되고 14:00:30 외부 경보가 울리면 당직자는 즉시 접수한다. 14:05:30 이내 지휘 체계를 만들고, 14:10:30 이내 권한이 필요한 결정을 보고하며, 14:15:30까지 첫 상태 공지를 낸다. 원인이 불명확하면 추정임을 밝히고 확인된 영향부터 안내한다.

하나의 장애를 복구해도 남은 주문까지 확인한다

INC-17은 주문 프로그램 1.4 배포 직후 결제 대기가 늘어난 사건이라고 하자. CI-ORDER의 변경 이력에서 CHG-7을 찾고, 앱 담당자는 1.3으로 되돌릴 수 있는지 DB 담당자와 확인한다. 이번 사례는 DB 구조와 저장 형식이 바뀌지 않았다는 조건에서만 이전 버전을 복원한다.

14:08에 되돌리기를 끝냈어도 그 시각을 곧바로 사건 종료로 쓰지 않는다. 복원 뒤 연속 10분간 두 지점의 외부 시험 요청이 정상이고 새 유효 요청의 5초 충족률이 99.95% 이상인지 지휘자가 확인한다. 이는 월간 SLO 달성 판정이 아니라 이 사례의 단기 복구 확인 기준이다. 미확인 결제 목록과 담당자도 누락 없이 정해져야 한다. 표본이 없으면 대표 시험 요청으로 기능을 확인하되 실사용 비율을 측정한 것처럼 쓰지 않는다.

서비스가 복구되면 사건의 복구시각을 기록하고 고객에게 갱신한다. 남은 미확인 거래와 고객 영향이 모두 처리되었거나 추적 가능한 후속 기록으로 인계되었는지 확인한 뒤 사건을 닫는다. 원인 가설과 영구 수정은 PRB-3으로 계속 관리한다. ‘서비스 복구’, ‘사건 종료’, ‘원인 제거’는 서로 다른 시점이다.

외부 결제사 응답이 없을 때의 결정

앞서 배운 재시도 원리를 적용한다. PAY-81의 응답이 5초 안에 없으면 해당 요청은 5초 지표에서 미충족이며, 업무 상태는 ‘결제 결과 확인 필요’로 남긴다. 이 결과를 성공이나 확정 거절로 표시하지 않는다.

앱 담당자는 동일 요청 식별자와 주문번호를 기록하고 공급자 담당자는 결제사 사건번호와 조회 가능 여부를 확인한다. 결과조회에서 이미 승인되었으면 주문의 저장 상태와 대조하여 확정·고객 통지를 진행한다. 명백히 미승인이고 고객 의사·재고·업무 기한이 여전히 유효할 때만 합의한 안전한 재요청을 검토한다.

대사(對査)는 주문 기록과 결제사 기록을 식별자로 맞추어 금액·통화·상태의 불일치를 찾는 일이다. DB/업무 담당자가 미확인 목록을 맡고, 30분을 넘긴 미확인 거래는 서비스 책임자에게 올린다는 자체 기한을 둔다. 이 30분은 결제가 반드시 해결된다는 외부 보증이 아니다.

다른 결제사로 바꾸는 안은 기존 승인 여부가 불명확한 거래에는 기각한다. 두 번째 결제사를 호출한다고 첫 번째 청구가 취소되는 것은 아니기 때문이다. 안전한 전환은 기존 거래의 대사와 신규 거래의 경로 분리·계약·시험을 먼저 갖춘 경우에 별도로 검토한다.

선택하지 않은 대안의 이유도 설계다

기각 이유는 모든 조직에서 그 대안이 나쁘다는 뜻이 아니다. 이 사례의 서비스 약속과 인력·부하·거래 안전 조건 아래에서 왜 적절하지 않은지를 적는다.

6. 변경을 허용하되 무엇이 달라졌는지 검증한다

변경 관리는 서비스에 영향을 주는 수정을 위험·영향·일정·권한과 함께 통제한다. ITIL 4의 Change Enablement 공개 설명은 위험을 줄이는 변경, 역할과 조정된 활동을 다룬다. 아래 승인 경로는 이를 적용한 자체 설계이며 공개 설명이 특정 회의체·분 단위 기한을 의무화한다는 뜻이 아니다. [S7]

반복 가능하고 저위험이며 검증된 절차의 변경은 적용 조건과 사전 승인 범위를 정한다. 조건을 벗어나거나 처음 하는 변경은 앱·DB·공급자 영향을 검토한 뒤 권한자가 개별 승인한다. 긴급 변경은 위험 검토를 없애는 대신 사건 지휘자와 지정 권한자의 빠른 결정을 기록하고 실행 후 검토를 남긴다.

CHG-7의 기록에는 CI-ORDER 1.3→1.4, DB 구조 변경 없음, 동시 변경 금지, 배포 전 기준값, 확인 요청, 중단·복원 조건을 적는다. 제한된 노드에서 먼저 확인하되 고객 거래 안전을 해치면 비율과 관계없이 중단한다. 이번 안은 최근 5분 미충족률 1% 이상이며 표본 100건 이상일 때도 중단·복원 검토를 요구한다. 요청이 적으면 표본 부족을 성공으로 쓰지 않고 대표 시험과 관찰시간을 추가한다.

성공 반영 후 구성정보의 실제 버전을 갱신하고 기능·지표·거래 정합성을 대조한다. 실패하면 INC와 연결하여 복구하고, 승인 기록만 있거나 서버가 기동했다는 이유만으로 CHG를 완료 처리하지 않는다.

연속성·보안·비용도 운영계획에서 빠질 수 없다

단일 노드 고장 대응과 센터 재난 복구는 범위가 다르다. OP-S의 4대 구성은 노드 한 대 장애만 계산했으므로 센터 전체 상실에 같은 성능을 보장하지 않는다. 사업부가 센터 상실에도 운영을 요구하면 대체 장소·통신·데이터 복구·인력과 예산을 별도로 설계하고, 승인 전까지 그 요구는 미충족으로 남긴다.

확정된 주문의 누락과 중복 청구는 이 사례의 금지 조건이다. 백업 파일이 존재한다는 사실만으로 이를 보장하지 못하므로 DB 담당자는 별도 환경에서 복원하고 주문·결제 대사로 확인한다. 복구시간과 되살릴 데이터의 시점은 업무가 허용할 범위로 합의하며, 이번 단일 노드 용량 계산에서 재난 복구의 수치를 임의로 도출하지 않는다.

운영 권한은 업무에 필요한 범위만 부여하고 고위험 변경 승인·실행 이력을 분리한다. 원문 결제정보를 관측 로그에 불필요하게 복제하지 않으며 로그 접근·보관 정책을 정한다. 자원 비용은 3대와 4대의 수량 차이뿐 아니라 당직·복원 시험·공급자 지원까지 같은 기간으로 비교한다. 가격 자료가 없으므로 가짜 금액을 채워 경제성이 검증됐다고 말하지 않는다.

운영 인수는 문서 존재가 아니라 조건별 증거로 판단한다

이 절의 계산은 시험 계획을 구체화한 것이며 위 실서비스 시험을 실행한 결과가 아니다. 필수 조건이 미확인일 때 서비스 책임자는 운영 인수를 보류하고 담당자·보완 증거·재확인 날짜를 정한다. 여러 항목이 통과해도 중복 청구 위험 같은 금지 조건을 평균점수로 상쇄하지 않는다.

일·주·월의 개선주기를 실제로 연결한다

매일 당직자는 요청 수·결측·미확인 거래와 긴급 사건을 확인한다. 주간에는 PRB-3의 원인 가설·우회책 위험·CHG-7 후속 시험과 피크 용량을 앱·DB·공급자 담당자가 함께 검토한다. 월간에는 서비스 책임자가 합의한 SLA와 내부 목표, 지연 분포, 지역/피크별 영향과 개선 기한을 사업부에 보고한다.

가상 월 A는 고객 SLA를 충족했어도 내부 99.95% 목표에 미달했으므로 ‘문제 없음’으로 닫지 않는다. 영향이 큰 일반 변경은 보류하고 PRB-3의 개선을 우선하며, 긴급 보안·복구 변경은 지정 권한자가 위험을 비교하여 예외 결정과 근거를 기록한다. 월 B는 고객 약속도 미달했으므로 SLA-OP-1의 2영업일 보고 조치를 실행한다.

다음 달의 목표나 측정 범위를 바꿀 필요가 있으면 사업부와 사전에 다시 합의한다. 이미 발생한 실패를 제외하거나 지난달 목표를 낮추어 과거 보고서를 통과로 고치지 않는다. 개선의 완료는 티켓을 닫은 수가 아니라 약속한 결과와 재발 위험이 실제로 바뀌었는지로 판단한다.

공식 범위 연결: 운영기획을 무엇으로 보여 줄까

공식 출제기준의 ‘IT시스템 운영기획 및 관리’ 중 운영기획은 업무 목적을 서비스수준·용량·인력·절차·검증이 있는 실행 가능한 계획으로 바꾸는 것으로 학습한다. OP-S에서 그 결과물은 SLA-OP-1, 노드 4대의 장애 용량표, 역할·에스컬레이션표, 외부 결제 계약 조건과 운영 인수 기준이다.

인접한 ‘응용SW, HW, NW, DB 운영관리’와 관련되지만 이 절에서 각 기술의 모든 상세 운영을 완료했다고 확대하지 않는다. 이 절은 여러 담당의 작업을 서비스 약속으로 묶는 기획과 관리 판단에 초점을 둔다.

공식 범위 연결: 운영관리는 어떤 증거를 남길까

운영관리는 기획에서 정한 약속을 실제 요청·사건·변경·구성 기록과 대조하고, 미달·불확실성·잔여위험을 담당자가 처리하도록 하는 것으로 학습한다. OP-S에서는 INC-17의 복구·종료 구분, PRB-3의 원인·우회책, CHG-7의 승인·복원, CI-ORDER의 실제 버전과 월간 A/B 판정이 그 증거다.

이 연결은 교재의 해석과 교육용 적용이다. 기출 원문을 확인하지 않은 회차·교시·문항번호를 붙이지 않으며, 뒤의 두 문제는 자체 작성 문제로 사용한다.

30초 정리

운영기획은 약속·측정·용량·역할·절차·인수 기준을 결정하고, 운영관리는 실제 결과와 기록으로 그 계획을 실행·교정한다. SLA의 합의, SLO의 목표, SLI의 측정 정의와 실제 관측값을 구분하고 분모·시간창·관측 사각을 밝힌다.

사건의 빠른 복구, 문제의 원인·위험 감소, 변경의 통제, 구성정보의 정확성은 목적이 다르지만 같은 서비스와 기록 식별자로 연결된다. 단일 노드 장애를 구역 재난으로 확대하거나 외부 결제사 장애와 미확인 결과를 보고서에서 지우지 않는다.

독립 연습 — 노드 수를 늘리는 답안을 서비스 한도로 되돌린다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

OP-S의 노드 4 대·대당 계획 용량 210 건/초·피크 600 건/초를 유지한다. 두 구역에 2 대씩 두었는데 한 구역 전체를 잃었다. 별도 OP-Q에서는 공유 호출 한도 620 회/초 안에 신규 승인 600 회와 결과 조회 30 회가 필요하다.

• 구역 장애 뒤 용량과 부족량을 계산하라.
• OP-Q의 합계·초과량과 조회 30 회를 먼저 확보할 때 신규 승인 상한을 계산하라.
• 한 노드의 장애 허용이라는 조건만으로 두 상황을 승인할 수 없는 이유를 설명하라.

풀이와 오답 교정 보기

구역 장애 뒤 남은 2 대의 용량은 2×210=420 건/초로 피크보다 180 건/초 부족하다. OP-Q는 600+30=630 회/초로 한도를 10 회 초과한다. 조회 30 회를 확보하면 신규 승인 상한은 620−30=590 회/초다. 잃는 노드의 수와 공유하는 외부 자원이 달라진 조건이며, 노드 확장이 외부 계약의 호출 한도를 늘리지는 않는다. 계산된 상한으로 600 건/초 요구를 충족했다고 보고하지 않는다.

장애 뒤 용량에서 잃은 노드 수를, 공유 호출 한도에서 승인과 조회의 분모를 고친다.

7. 10점 설명형: 목적의 차이와 연결을 모두 쓴다

자체 작성 문제 · 실제 기출 및 공식 기준답안이 아님 · 10점

IT시스템 운영기획과 운영관리를 구분하고, 서비스수준·사건·문제·변경·구성 관리가 서비스 운영에서 어떻게 연결되는지 설명하시오.

‘구분’에는 기획/관리의 목적과 산출물 비교가, ‘어떻게 연결’에는 사건→복구·문제→변경↔구성→서비스수준 재확인의 관계가 필요하다. 다섯 용어의 뜻만 나열하거나 모든 사건을 일렬로 처리하는 도식은 요구의 절반을 놓친다. 짧은 사례 한 개로 서로 다른 완료 기준을 확인하면 된다.

이 문제 풀이와 답안 구성 보기

답안 목차를 만드는 과정

기획/관리는 비교의 첫 축으로, 서비스수준은 전체 판단 기준으로 둔다. 이어 사건/문제와 변경/구성을 짝지으면 복구와 개선의 차이를 짧게 보여 줄 수 있다.

1. 운영기획·운영관리의 목적과 산출물
2. 서비스수준의 합의·측정과 차이 확인
3. 사건 복구와 문제의 원인·우회책 관리
4. 변경 통제와 실제 구성정보 갱신
5. 주문 사례의 연결과 개선

답안에 넣을 관계도

화살표의 방향과 조건을 따라 연결을 읽습니다.

이 그림은 OP-S의 사건이 있는 경우 연결할 기록이다. 점선의 문제 분석·변경은 필요할 때 연결하며 모든 사건에 문제·변경이 반드시 생기는 것은 아니다. 원인 조사 미완료가 복구 확인을 막지 않는다. 검증·보고에는 개선 결과와 남은 위험을 함께 적는다.

화살표는 필요할 때 연결되는 활동이다. 사건 복구가 원인 제거를 기다려야 한다거나 모든 문제에 반드시 변경이 필요한 것은 아니다.

10점 완성 답안 예시

운영기획은 업무 가치와 위험을 서비스수준·용량·역할·절차·검증 기준으로 결정하는 활동이고, 운영관리는 그 계획을 실행하여 결과를 측정하고 차이를 교정하는 활동이다. 따라서 계획서의 존재와 운영의 효과는 구분하여 평가한다.

서비스수준 관리는 서비스 범위·목표·분모·측정창·책임·미달 시 조치를 합의하고 관측값을 대조한다. 외부 의존성이나 실패 요청을 사후 제외해 충족률을 높이지 않는다.

사건 관리는 영향을 줄이고 정상 서비스를 복구하는 데 우선순위를 둔다. 문제 관리는 실제·잠재 원인과 우회책·잔여위험을 관리하여 재발 가능성과 영향을 줄이며, 원인 조사 미완료가 곧 사건 복구 불가를 뜻하지는 않는다.

수정이 필요하면 변경의 위험·영향·권한·일정·복원 조건을 검토하여 실행하고, 실제 반영된 버전과 의존 관계를 구성정보에 갱신한다. 승인서만 있거나 서버가 켜졌다는 이유로 변경을 완료하지 않는다.

주문 장애 INC-17은 안전한 이전 버전 복원 후 서비스 결과로 복구를 확인하고, 남은 미확인 거래를 추적한다. PRB-3에는 원인과 영구 수정을, CHG-7과 CI-ORDER에는 변경·구성 이력을 연결한다. 월간 서비스수준과 재발 위험을 다시 확인하여 운영계획을 개선한다.

답안 해설과 자기점검

첫 문단은 기획/관리의 차이를, 둘째는 공통 판단 기준을, 셋째와 넷째는 각 활동의 목적·끝을 답한다. 마지막 사례는 용어 나열을 실제 연결로 바꾸는 역할이다. 10점 답안에서는 용량 수치표 전체보다 이 관계를 명확히 쓰는 것이 이 문제의 요구에 맞다.

‘원인을 못 찾았으므로 복구할 수 없다’고 썼다면 사건과 문제로, ‘변경 승인 후 종료’라고 썼다면 변경 검증으로 돌아간다. 이 자기점검은 교재의 교육 기준이며 채점 점수나 합격을 예측하지 않는다.

8. 25점 설계형: 계획하겠다는 말 대신 결정한 결과를 쓴다

자체 작성 문제 · 실제 기출 및 공식 기준답안이 아님 · 25점

온라인 주문서비스를 신규 운영하려 한다. 월간 서비스수준, 피크 용량, 장애·문제·변경·구성 흐름, 외부 결제사 의존성, 역할·에스컬레이션과 개선주기를 포함한 IT시스템 운영기획 및 관리체계를 설계하시오.

이 문제는 목표를 수립하는 절차만 설명하라는 요구가 아니다. 조건이 주어지지 않은 수치는 교육 사례 OP-S의 가정임을 먼저 밝히고, 서비스 범위·측정 분모·장애 후 용량·누가 언제 판단할지·실패 시 대안·인수 증거를 실제로 정한다.

문제의 요구를 ‘약속→자원→사람→기록→외부 위험→검증·개선’으로 묶는다. 본문의 충분한 학습 설명과 아래 시험용 답안 예시를 구분하며, 실제 시험에서는 요구 범위와 주어진 조건에 맞춰 분량을 조절한다.

이 문제 풀이와 답안 구성 보기

답안 목차와 각 항목이 남길 결과

1. 가정·서비스 범위와 SLA
2. 측정 분모·경계와 수치 판정
3. 피크·단일 노드 장애 용량과 기각 대안
4. 역할·에스컬레이션과 고객 통지
5. 사건·문제·변경·구성의 실행 흐름
6. 외부 결제사와 미확인 거래 통제
7. 운영 인수·연속성·보안·비용 경계
8. 일·주·월의 개선과 미달 시 조치

1~2는 SLA-OP-1과 집계표, 3은 잔존 용량표, 4~6은 책임·기록 흐름, 7~8은 인수·개선 판단으로 남긴다. 숫자는 그 숫자를 정한 범위와 실패조건을 함께 적는다.

설계 답안 도식

사업부와 서비스 책임자는 SLA-OP-1·위험·미달 조치를 합의한다. 아래는 그 약속을 수행하는 서비스 의존 관계이며, 당직·지휘자는 INC-17 기록 관계도에 따라 복구·인계를 조정한다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

실선은 관문→앱→DB·외부 결제사의 서비스 의존 관계다. 점선은 요청·결과의 측정과 대조이며 실행 순서가 아니다. 앱 한 노드 장애 뒤 630건/초라도 OP-S의 전체 계획 한도는 min(630,700,900,620)=620건/초다. 외부 접속은 별도 관측으로 보완한다.

검증·월간 보고는 약속과 실제 결과를 대조해 계획을 개선한다. 필요 시 PRB-3·CHG-7을 연결하고 CI-ORDER의 실제 구성을 갱신한다.

주문서비스 그림은 책임과 서비스 의존성을, INC-17 기록 관계도는 복구·문제·변경·구성정보의 연결을 보여 준다. 데이터가 시간순으로 모든 상자를 한 번씩 지나간다는 뜻이 아니다.

25점 완성 답안 예시

가. 범위와 약속. 자체 가정 OP-S에 따라 24시간 주문서비스의 관문 수신부터 검증·결제 반영·응답까지를 범위로 한다. 올바른 결과에는 저장된 확정과 확인된 정상 업무 거절을 포함하되 미확인을 거절로 바꾸지 않는다. 사업부와 한국시간 달력월 기준 5초 이내 올바른 결과 99.9% 이상, 미달 시 월 마감 후 2영업일 내 원인·영향·개선 일정 보고를 SLA-OP-1로 합의한다. 내부 목표는 같은 지표 99.95%, 2초 이내 결과 비율 99%로 둔다.

나. 측정과 판정. 분모는 관문에 도착한 전체 유효 요청이고 오류·시간초과·외부 결제사 장애·정비 중 요청도 포함한다. 요청 식별자와 수신·완료시각, 결과·대사 정보를 기록하며 수신 기록 결손은 측정 불완전으로 보고한다. 관문 전 접속 장애는 두 외부 지점의 10초 주기 관측으로 보완한다. 가상 월 A의 1000000건 중 999400건이 5초 안에 올바른 결과이면 99.94%로 고객 약속만 충족하고 내부 목표는 미달한다. 같은 월의 2초 결과 995000건은 99.5%다. 요청 기반 1000건의 오류 예산을 시간 기반 43.2분과 동일시하지 않는다.

다. 용량과 대안. 피크를 600건/초, 노드 기준을 300건/초, 계획 사용 비율을 70%로 가정한다. 노드당 210건/초이므로 4대의 정상 용량은 840, 한 대 상실 후는 630건/초다. 3대는 장애 후 420이므로 기각하고 5대는 추가 비용을 정당화할 성장·장애 요구가 있을 때 검토한다. DB 700·네트워크 900·결제 승인 620건/초의 가정 아래 전체 한도는 620건/초이며 조회·재시도 한도는 별도 확인한다. 노드 장애 계산을 구역 전체 장애 보장으로 확대하지 않는다.

라. 역할과 통지. 서비스 책임자는 SLA·위험·고위험 변경·월간 보고를, 당직자와 지휘자는 접수·심각도·복구 조정을 맡는다. 앱·DB·플랫폼/네트워크·공급자 담당은 각 기술과 계약 증거를 책임지고 서비스 데스크는 고객 안내를 맡는다. 두 외부 지점의 30초 실패 또는 거래 안전 이상은 즉시 중대로 접수하여 5분 내 지휘 체계를 만들고 10분 내 책임자에게 보고한다. 첫 공지는 15분 이내, 지속 시 15분마다 갱신한다. 담당·대체자·연락 수단과 승인 권한을 인계한다.

마. 실행 흐름. INC-17은 사용자 영향을 기록하고 안전한 복원으로 먼저 복구한다. DB 구조·저장 형식이 같다는 조건에서 앱 1.4를 1.3으로 되돌리며 10분 관측과 거래 추적으로 복구를 확인한다. 후속 거래의 책임을 인계한 뒤 사건을 닫고 원인·우회책·영구 수정은 PRB-3에서 계속 관리한다. CHG-7은 위험·권한·검증·중단·복원 조건을 기록하고 실제 반영 버전은 CI-ORDER에 갱신한다. 원인 제거, 서비스 복구, 사건 종료를 같은 완료로 취급하지 않는다.

바. 외부 결제 통제. PAY-81의 응답이 없으면 5초 지표는 미충족, 업무 상태는 확인 필요로 둔다. 동일 식별자로 결과를 조회하고 주문·결제 금액과 상태를 대사한다. 명백한 미승인과 고객 의사·업무 기한이 확인된 경우에만 안전한 재요청을 검토한다. 공급자 담당은 사건번호·호출별 한도·연락을 책임지고 30분 초과 미확인 거래는 서비스 책임자에게 올린다. 기존 승인 여부를 모른 채 새 결제사로 재전송하는 안은 중복 청구 위험 때문에 기각한다.

사. 인수와 잔여위험. 600건/초 부하·노드 제거·재분산, 2초/5초 경계, 응답 유실·중복 요청·DB 복원·대사, 공급자 장애 연락과 실제 구성 일치를 시험한다. 계산표·승인서만으로 운영 인수를 승인하지 않으며 금지 조건 위반과 미확인은 보류한다. 센터 재난 복구는 별도 범위·예산·데이터 복원 계획을 합의한다. 최소 권한·변경 이력·민감정보를 줄인 관측을 적용하고 자원·당직·복원 시험·공급자 지원 비용을 같은 기간으로 비교한다.

아. 개선. 일간에는 측정 결손·사건·미확인 거래, 주간에는 문제·변경·용량, 월간에는 SLA·내부 목표와 피크/지역별 영향을 검토한다. A처럼 고객 약속만 충족한 경우에도 내부 미달 원인을 개선하고 위험한 일반 변경을 보류하되 긴급 보안·복구 변경은 권한자가 근거를 남겨 판단한다. B의 5초 충족률 99.86%는 고객 약속도 미달이므로 합의한 보고를 실행한다. 목표·분모 변경은 사전 합의로 다음 기간에 적용하고 과거 실패를 사후 삭제하지 않는다.

왜 이 답안은 설계 결과인가

‘용량을 확보한다’ 대신 4대와 장애 후 630건/초를, ‘장애를 관리한다’ 대신 지휘·보고·공지 기한을, ‘개선한다’ 대신 A/B의 서로 다른 후속 조치를 정했다. 동시에 가정한 처리율을 실측으로 바꾸지 않았고 센터 재난·공급자 호출 한도·운영 인수의 미확인도 남겼다.

다른 수치를 선택한 답안도 업무 필요·분모·장애 조건·자원·권한·검증이 일관되면 대안이 될 수 있다. 다만 본문 수치와 다른 값을 쓰면서 근거 없이 같은 결론을 복사하거나, 시험하지 않은 설계를 운영 승인 완료라고 쓰면 교정해야 한다.

9. 틀린 답안을 직접 고치는 방법

오답 1: ‘SLA 99.9%를 달성한다.’ 무엇을 세고 어디까지 책임지는지 빠졌다. ‘관문에 도착한 전체 유효 요청 중 5초 이내 올바른 결과 비율을 달력월 기준 99.9% 이상으로 합의한다’로 고치고 미달 조치를 붙인다. 복습: 범위와 분모.

오답 2: ‘A는 99.94%이므로 운영상 문제없다.’ 고객 약속과 내부 목표를 섞었다. ‘고객 99.9%는 충족하지만 내부 99.95%는 미달하므로 원인·위험을 개선한다’로 고친다. 복습: 수치 판정.

오답 3: ‘3대면 630건/초이므로 피크 600건/초를 수용한다.’ 정상 합계만 봤다. ‘한 대 고장 시 420으로 미달하므로 4대를 계획하고 장애 후 630을 시험한다’로 고친다. 복습: 잔존 용량.

오답 4: ‘원인 분석 완료 후 장애를 복구한다.’ 안전한 우회 가능성을 삭제했다. ‘안전한 복원으로 서비스 영향을 먼저 줄이고 원인·영구 수정은 연결된 문제 기록에서 계속한다’로 고친다. 복습: 서로 다른 완료 시점.

외부 의존성과 승인에서 생기는 네 가지 오류

오답 5: ‘결제사 오류이므로 SLA에서 제외한다.’ 서비스 경계와 사전 합의 없이 고객 영향을 지웠다. ‘약속한 유효 요청의 미충족에 포함하고 공급자 사건번호·대사·개선 책임을 연결한다’로 고친다. 복습: 결제 통제.

오답 6: ‘급하므로 승인 없이 변경하고 기록은 나중에 만든다.’ 긴급성과 무통제를 혼동했다. ‘지정 권한자의 신속한 위험 판단·결정·실행을 사건 시각표에 기록하고 사후 검토한다’로 고친다. 복습: 변경 경로.

오답 7: ‘노드 장애 시험에 통과했으므로 재난에도 안전하다.’ 검증한 장애 범위를 확대했다. ‘한 노드 상실만 검증했으며 구역·센터 상실은 별도 설계와 시험 대상’으로 고친다. 복습: 용량의 한계와 연속성.

오답 8: ‘계획서·백업·승인서가 있으므로 운영 인수 완료다.’ 존재와 작동 증거를 혼동했다. ‘실제 복원·부하·거래 대사·연락 훈련을 확인하고 미확인은 담당·기한을 정하여 보류한다’로 고친다. 복습: 인수 기준.

스스로 설명하고 조건을 바꾸어 판단한다

종이에 ‘약속·분모·장애 후 용량·책임·기록 흐름·외부 결제·인수·개선’ 여덟 칸을 그린다. 각 칸에 OP-S에서 정한 결과 한 개와 실패조건 한 개를 적어 본 뒤 위 완성 답안과 비교한다. 빈칸은 해당 본문으로 돌아가 채우며 점수 합계로 정확성이나 합격 여부를 판정하지 않는다.

조건 변경 문제: 피크가 900건/초로 늘면 앱만 6대로 늘려도 충분한가? 앱은 한 대 상실 후 5 × 210 = 1050건/초이지만 기존 결제 620·DB 700·네트워크 900 한도가 남아 있으므로 충분하지 않다. 의존성의 한도와 재시도 부하를 다시 확인해야 한다. 복습: 전체 경로의 한도.

공유 한도 자기교정: ‘신규 승인 600은 한도 620보다 작으므로 OP-Q도 통과’라는 답에는 조회 30회가 빠져 있다. ‘합계 630으로 10회 초과하며, 조회를 확보한 신규 승인 상한은 590회/초’로 고친다. 이어 580회 제한안은 원래 피크 요구의 충족이 아니고 거절·지연도 기존 지표에 남긴다고 적는다. 복습: OP-Q의 합산과 제한 영향.

추가 조건 변경: OP-Q에서 조회가 50회/초이고 별도 승인 재시도도 5회/초라면, 같은 10회 여유를 남기는 신규 승인 상한은 얼마인가? 620 − 50 − 5 − 10 = 555회/초다. 합계는 610이고 여유는 10이다. 새 식별자로 바꾸어 재시도를 신규 호출에서 지우거나, 원래 600건/초를 처리했다고 보고하지 않는다. 먼저 호출 종류별 수와 합계를 쓴 뒤 제한의 고객 영향과 재검증 조건을 붙인다.

면접 연습: ‘고객 SLA는 통과했는데 왜 일반 변경을 보류했습니까?’라는 질문에는 내부 목표 미달이 나타낸 운영 위험, 문제 개선 우선순위, 긴급 변경의 예외 판단을 설명한다. OP-S는 학습을 위한 가상 사례이므로 실제 본인이 수행한 경력이라고 소개하지 않는다.

출처·판본·지원 범위

확인일은 2026-09-12다. 원문은 근거 확인용이며 필수 설명은 본문 안에 두었다. 표준 전문·ITIL 유료 실무 가이드·공식 한국어 번역의 독립 대조와 권리 승인은 미완료다. 자체 사례·수치·역할·기한·문제·답안은 어느 출처의 공식 기준답안도 아니다.

[S1] ISO/IEC. ISO/IEC 20000-1:2018, Third edition (2018-09), 원 출판물의 공개 미리보기(iTeh 호스팅). 위치: PDF 7쪽(인쇄 vii쪽), Introduction 첫 문단. 지원: 서비스 관리체계의 수립·실행·유지·지속 개선과 서비스 생애주기 범위; 개별 조항·인증 판정은 지원하지 않는다. 원문: https://cdn.standards.iteh.ai/samples/70636/8a24bdb065a44c6285221f7ea8c88dda/ISO-IEC-20000-1-2018.pdf ISO 공개 안내 및 ANSI 미리보기와 같은 판본·지원 문단을 대조했다. 발행 주체와 파일 호스트는 다르다. 표준 전문과 2024 개정의 전체 대조는 미완료다.

[S2] Google SRE. Service Level Objectives. SRE book, chapter 4. 위치: Service Level Terminology: Indicators, Objectives, Agreements; Keep a safety margin. 지원: 지표·목표·합의의 구분과 내부 목표 여유의 취지; 자체 수치·계약 법적 효력은 지원하지 않는다. 원문: https://sre.google/sre-book/service-level-objectives/

[S3] Google SRE. Implementing SLOs. SRE Workbook, chapter 2. 위치: What to Measure: Using SLIs; SLI specification and SLI implementation. 지원: 좋은 사건/전체 사건 비율, 오류 예산, 측정 구현의 관측 한계; 본문의 가상 집계는 자체 계산이다. 원문: https://sre.google/workbook/implementing-slos/

[S4] PeopleCert. ITIL 4 Practitioner: Incident Management. ITIL 4 public practice description. 위치: Introduction; What will you learn?. 지원: 사건 관리의 신속한 정상 서비스 복구 목적; 자체 심각도·시간표는 의무 기준이 아니다. 원문: https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-incident-management-3684

[S5] PeopleCert. ITIL 4 Practitioner: Problem Management Mock exam — practice purpose. ITIL 4 public description, not mock-exam question content. 위치: Practice module introductory paragraph, before Key benefits. 지원: 실제·잠재 원인, 우회책·알려진 오류로 사건 가능성과 영향을 줄이는 목적만 참조한다. 모의시험 문항은 수집·복제하지 않는다. 원문: https://www.peoplecert.org/browse-mock-exams/it-governance-and-service-management/ITIL-1/ITIL%204%20Practitioner%20Problem%20Management%20Mock%20exam-3689

[S6] PeopleCert. ITIL 4 Practitioner: Service Configuration Management. ITIL 4 public practice description. 위치: Introduction; What will you learn?. 지원: 구성과 이를 지원하는 항목에 관한 정확하고 신뢰할 수 있는 정보의 제공; 표의 CI 식별자·버전은 자체 예이다. 원문: https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-service-configuration-management-3800

[S7] PeopleCert. ITIL 4 Practitioner: Change Enablement. ITIL 4 public practice description. 위치: What will you learn? Key concepts; Practice processes; Roles and competencies. 지원: 위험 감소·역할·조정된 변경 활동의 취지; 특정 승인 회의·자체 기한·전체 가이드의 세부 규정은 지원하지 않는다. 원문: https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-change-enablement-3794

[S8] PeopleCert. ITIL FAQ – Frequently Asked Questions about ITIL. ITIL Version 5 / ITIL 4 FAQ observed 2026-09-12. 위치: ITIL (Version 5); What has changed in the ITIL management practices?. 지원: ITIL Version 5 제공 및 실무 자료의 판본 구분. Version 5 전체 실무 가이드 대조는 미완료다. 원문: https://www.peoplecert.org/help-and-support/faq-itil

공식 출제기준은 저장소 보존본 references/peim/sources/official/정보관리기술사.pdf의 2쪽, ‘2. 소프트웨어 공학 → 4. 정보시스템 운영 및 유지보수’에서 확인했다. 적용기간은 문서의 2027-01-01~2030-12-31이며, 본문 사례와 자체 문제를 공식 출제 문항이라고 표시하지 않는다.