· 생활·도구 가이드

AP25 — SLA, 인시던트·문제·변경·릴리스 관리

응용정보기술자시험 과목 A에 필요한 SLA·SLO·SLI와 서비스 수준 관리, 가용성과 허용 중단 시간 계산, 인시던트 관리와 문제 관리의 차이, 변경·릴리스 관리 순서를 결제 API 장애 사례와 오리지널 연습 문제 5문항으로 익힙니다.

応用情報技術者試験科目AサービスマネジメントSLAインシデント管理

AP 과목 A 제25편 · 2026년도·실라버스 Ver.7.2 기준의 독립 학습 자료입니다. IPA와 제휴하지 않으며 합격을 보장하지 않습니다. 시리즈 허브 보기

  • 개정일 / 출처 확인일: 2026-10-21
  • 시험 기준: 2026년 IPA 응용정보기술자시험 실러버스 Ver.7.2. 2027년 이후 제안·검토 자료는 출제 기준에서 제외합니다.

학습 인덱스

PDF 쪽과 인쇄 바닥글 쪽은 서로 다른 번호 체계입니다.

  1. PDF 90 / 인쇄 86: 서비스 관리, ITIL, SLA/SLO/SLI, 가용성·신뢰성·서비스 시간·응답 시간
  2. PDF 91 / 인쇄 87: 서비스 수준의 정의·합의·문서화·관리와 정기적인 감시·검토·보고
  3. PDF 92 / 인쇄 88: 변경 정책, RFC 기록·분류·우선순위·평가·승인·빌드·테스트·롤백, CAB, PIR
  4. PDF 93 / 인쇄 89: 서비스 설계·전환, 릴리스/배포, 인시던트의 기록·분류·우선순위·에스컬레이션·해결·종료, 중대 인시던트
  5. PDF 94 / 인쇄 90: 문제 추세·근본원인·예방·알려진 오류·우회책, 가용성 요구·목표·감시·조사, MTBF/MTTR

공통 용어표

English 한국어 日本語
service-level agreement (SLA) 서비스 수준 협약(SLA) サービスレベル合意書（SLA）
service-level objective (SLO) 서비스 수준 목표(SLO) サービスレベル目標（SLO）
service-level indicator (SLI) 서비스 수준 지표(SLI) サービスレベル指標（SLI）
service-level management (SLM) 서비스 수준 관리(SLM) サービスレベル管理（SLM）
availability 가용성 可用性
incident 인시던트 インシデント
problem 문제 問題
known error 알려진 오류 既知の誤り
workaround 우회책 回避策
request for change (RFC) 변경 요청(RFC) 変更要求（RFC）
change advisory board (CAB) 변경 자문 위원회(CAB) 変更諮問委員会（CAB）
post-implementation review (PIR) 구현 후 검토(PIR) 実施後レビュー（PIR）
release and deployment 릴리스 및 배포 リリース及び展開
mean time between failures (MTBF) 평균 고장 간격(MTBF) 平均故障間隔（MTBF）
mean time to repair (MTTR) 평균 수리 시간(MTTR) 平均修復時間（MTTR）

1. SLA와 반복 활동인 SLM

SLA는 서비스와 합의된 성능을 식별하는 합의 문서다. SLO는 그 안에서 달성할 목표값이고, SLI는 실제 상태를 나타내는 측정값이다. 예를 들어 “월 가용성 99.9%”는 SLO, 관측된 월 가용성은 SLI가 될 수 있다. SLM은 문서 하나가 아니라 서비스 수준을 정의·합의·문서화·관리하고, 목표 대비 성과를 주기적으로 감시·검토·보고하는 반복 활동이다.

2. 가용성 식과 상세 계산

이 글의 측정 규칙을 다음처럼 명시한다.

가용성 = (합의된 서비스 시간 - 산입 중단 시간) / 합의된 서비스 시간 × 100

30일 동안 24×7인 서비스의 합의 시간은 30×24=720시간이다. 산입되는 계획 외 중단이 3시간이면 가동 시간은 720-3=717시간, 실제 가용성은 717/720×100=99.5833...%, 즉 소수 둘째 자리에서 **99.58%**다.

SLO가 99.9%라면 허용 중단은 720×(1-0.999)=0.72시간=43.2분이다. 실제 3시간은 180분이므로 허용량을 180-43.2=136.8분 초과한다. 따라서 99.58%는 99.9% 목표를 충족하지 못한다. 계획 중단이나 제외 시간의 분모·분자 처리 방식은 반드시 SLA 정의를 따라야 하며 보고 기간마다 일관되어야 한다.

3. 인시던트와 문제

인시던트 관리의 목적은 정상 서비스를 신속히 복구하고 사업 영향을 제한하는 것이다. 기록·분류하고, 영향도와 긴급도를 함께 이용해 우선순위를 정하며, 필요하면 에스컬레이션한 뒤 해결 또는 우회하고 확인 후 종료한다. 복구는 근본원인 입증보다 먼저 이루어질 수 있다.

문제 관리는 인시던트 추세와 근본원인을 분석해 발생·재발을 예방한다. 원인을 아직 제거하지 못했다면 알려진 오류와 우회책을 문서화할 수 있다. 영구 수정이 변경을 요구하면 변경 정책을 따라야 한다. 즉 복구 중심 인시던트와 원인·예방 중심 문제는 연계되지만 같은 활동은 아니다.

4. 변경, 릴리스와 배포

변경 관리는 RFC를 기록·분류하고 우선순위를 정한 뒤 위험, 사업 편익, 실행 가능성, 재무 영향을 평가한다. 정의된 권한 또는 CAB가 승인하고, 빌드·테스트와 롤백 계획 및 롤백 테스트를 수행한다. 조직 절차가 정한 경우 PIR로 결과와 개선점을 확인한다.

릴리스/배포 관리는 승인되고 시험된 변경을 묶고 계획하여 운영 환경에 배치하며, 성공·실패를 감시·검토하고 릴리스 정보를 공유한다. 변경 승인은 배포 그 자체가 아니다.

5. 구체 사례: 결제 API 중단

가상의 쇼핑몰에서 결제 API가 멈췄다고 하자. 인시던트 팀은 넓은 고객 영향과 즉시 발생하는 매출 손실을 근거로 영향도·긴급도가 모두 높다고 판단해 높은 우선순위를 부여하고 에스컬레이션한다. 대기 시스템으로 페일오버하여 서비스를 복구하고, 조치와 상태를 기록·소통한다.

이어 문제 조사는 연결 풀 고갈을 근본원인으로 찾고, 알려진 오류와 “임계치 전에 인스턴스를 순환한다”는 임시 우회책을 문서화한다. RFC는 연결 풀 설정과 코드를 바꾸자고 제안한다. 변경 관리는 위험·편익·실행 가능성·비용을 평가해 승인을 받은 뒤 빌드·테스트를 수행하고 롤백 절차를 준비·시험한다. 릴리스 팀은 승인되고 시험된 변경을 배포하고 지표를 감시한 뒤 결과를 검토·공유한다. 사례에는 실제 개인정보가 없다.

6. 오리지널 4지선다

Q1

위 측정 규칙에서 720시간 중 산입 중단이 3시간이고 SLO가 99.9%일 때 올바른 설명은?

  • ア 99.90%이며 목표를 충족하고 허용 중단은 180분이다.
  • イ 99.58%이며 목표를 놓치고 허용 중단은 43.2분이다.
  • ウ 99.42%이며 목표를 놓치고 허용 중단은 72분이다.
  • エ 99.58%이며 목표를 충족하고 허용 중단은 136.8분이다.

정답: イ (2). ア는 실제값과 허용량을 혼동한다. イ는 717/720과 720×0.001을 올바르게 계산한다. ウ는 가용성과 허용량이 모두 틀렸다. エ는 실제값은 맞지만 목표 판정과 초과분 136.8분을 허용량으로 오인한다.

Q2

결제 API 중단 직후 가장 적절한 조치는?

  • ア 근본원인이 입증될 때까지 복구를 미룬다.
  • イ 승인 없는 영구 코드 변경을 운영에 즉시 배포한다.
  • ウ 인시던트 관리로 페일오버/우회해 복구한 뒤 문제 기록을 열어 RCA를 수행한다.
  • エ 인시던트를 종료하고 원인 조사는 하지 않는다.

정답: ウ (3). ア는 신속 복구 목적에 어긋난다. イ는 변경 통제를 우회한다. ウ는 복구와 후속 근본원인 분석의 순서가 맞다. エ는 재발 예방 기회를 버린다.

Q3

광범위한 결제 중단으로 즉시 사업 손실이 발생할 때 우선순위 결정은?

  • ア 영향도와 긴급도를 함께 평가해 높은 우선순위와 에스컬레이션을 정한다.
  • イ 접수 순서만 사용한다.
  • ウ 근본원인을 아는 경우에만 영향도를 평가한다.
  • エ 모든 인시던트를 같은 우선순위로 처리한다.

정답: ア (1). ア는 넓은 영향과 즉각적 손실을 모두 반영한다. イ는 사업 영향을 무시한다. ウ는 복구 우선순위에 RCA 완료를 잘못 요구한다. エ는 차등 대응을 불가능하게 한다.

Q4

변경부터 배포까지 올바른 순서는?

  • ア 먼저 배포하고 실패하면 RFC를 기록한다.
  • イ RFC 승인만 받으면 테스트 없이 즉시 배포한다.
  • ウ 빌드한 뒤 평가·승인을 생략하고 릴리스한다.
  • エ RFC를 평가·승인하고 빌드/테스트와 롤백을 준비한 뒤 릴리스/배포하고 감시·검토한다.

정답: エ (4). ア는 기록·평가·승인을 사후로 미룬다. イ는 승인을 테스트나 배포와 혼동한다. ウ는 위험·편익·실행 가능성·비용 평가와 승인을 생략한다. エ는 통제된 변경과 릴리스의 경계를 지킨다.

Q5

SLA와 SLM의 관계를 올바르게 설명한 것은?

  • ア SLA는 측정값이고 SLM은 목표값이다.
  • イ SLA는 합의 문서이고 SLM은 합의·감시·검토·보고를 지속하는 관리 활동이다.
  • ウ SLA와 SLM은 모두 일회성 배포 승인이다.
  • エ SLM은 중단 때만 수행하는 근본원인 분석이다.

정답: イ (2). ア는 SLI와 SLO까지 혼동한다. イ는 문서와 반복 관리 활동을 정확히 구분한다. ウ는 서비스 수준 관리와 변경/릴리스를 혼동한다. エ는 SLM을 문제 관리로 잘못 축소한다.

모든 문제는 자체 제작했으며 IPA 기출문제를 사용·번역·개작하지 않았다.

범위, 공식 출처 및 고지

보안 인시던트 대응, 감사, 내부통제는 AP26 범위이며 이 글의 서비스 관리 인시던트 절차와 구분한다.

이 자료는 IPA와 제휴하거나 IPA의 승인을 받은 자료가 아니다. 학습·합격·시험 결과를 보장하지 않는다.

블로그로