ITSM 시스템: 요청·장애·변경·서비스 수준을 관리하는 법 [2026]

ITSM 시스템은 문의 티켓을 모으는 도구가 아니라 서비스·사용자 요청·인시던트·문제·변경·구성항목·지식·서비스 수준과 복구 증거를 연결하는 IT 운영 체계입니다. 요청 처리와 장애 복구, 원인 제거, 변경 승인을 같은 상태로 뭉치지 않아야 우선순위와 책임을 판단할 수 있습니다.

사용자가 로그인할 수 없다는 한 문장은 접근 요청일 수도 있고 여러 사용자가 겪는 인시던트일 수도 있습니다. 장애를 임시 복구했다고 문제가 해결된 것도 아니며, 재발 방지 변경이 배포됐다고 서비스가 정상인 것도 아닙니다. 서비스·요청·인시던트·문제·변경을 별도 객체로 만들고 관계와 상태 사건을 남겨야 합니다.

ITSM의 목적은 티켓을 빨리 닫는 것이 아니라 합의된 서비스를 안정적으로 제공하고 복구·학습·개선하는 것입니다. 서비스 카탈로그에는 이름보다 소유자·사용자·지원 시간·의존성·목표·데이터 등급·복구 기준이 있어야 하며 우선순위는 목소리 크기가 아니라 영향과 긴급도의 근거로 계산해야 합니다.

서비스 관리의 생애주기와 조직 전체의 인시던트 대응을 함께 본다#

ISO/IEC 20000-1:2018은 서비스를 계획·설계·전환·제공·개선하는 서비스 관리 시스템의 요구사항을 다룹니다. NIST SP 800-61 Rev. 3은 인시던트 대응을 사이버보안 위험 관리 활동 전반에 통합해 준비·탐지·대응·복구의 효과를 높이도록 권고합니다. 두 기준은 제품 화면이나 특정 프로세스 이름을 강제하지 않으며 조직의 계약·규제·위험에 맞는 운영 설계가 필요합니다.

• ISO/IEC 20000 IT Service Management Guide: ISO/IEC 20000-1:2018 기반 서비스 관리 안내
• NIST SP 800-61 Rev. 3: CSF 2.0 기반 인시던트 대응 권고
• ISO 서비스 관리 시스템 안내: 서비스 관리 시스템과 범위·통합 관점

서비스 건강·미처리 요청·인시던트·문제·변경 위험을 한 운영 리듬으로 본다#

서비스 카탈로그와 구성항목 원장은 소유자와 정기 검토일을 둡니다. 자동 발견 결과는 실제 서비스 관계의 후보로 취급하고 사람이 근거를 확인합니다. 모니터링 알림은 서비스·환경·증상·시간 창으로 중복을 묶고 사용자 신고와 같은 인시던트에 연결하되 원본 이벤트를 보존합니다.

우선순위는 영향 사용자·핵심 업무·데이터 위험·우회 가능성·시간 민감도를 근거로 계산하고 수동 상향에는 사유를 남깁니다. 중대 인시던트에는 지휘·기술 복구·커뮤니케이션·기록 역할을 분리합니다. 상태 변경보다 탐지 지연, 복구 시간, 재발, 오래된 문제, 변경 실패·롤백, SLA 제외 비율을 봅니다.

변경은 위험·영향·검증·배포 창·승인·롤백·성공 판정과 관찰 기간을 갖습니다. 긴급 변경도 사후 승인과 검토를 생략하지 않습니다. 모니터링 장애·CMDB 지연·티켓 중복·공급자 장애·통지 채널 장애·롤백 실패를 훈련하고 복구 뒤 사용자 관점·데이터 정합성·미처리 큐를 대사합니다.

장비·소프트웨어 원장은 IT 자산관리 시스템과 연결하세요. 계정 접근 장애와 회수는 SSO 통합 로그인을 함께 보세요. 운영 결정과 인수인계는 업무일지 시스템도 참고할 수 있습니다.

사용자 신고 한 건을 서비스·장애·변경·복구·학습까지 재현하면 승인한다#

일반 요청·접근 요청·중대 인시던트·보안 인시던트·반복 장애·표준 변경·긴급 변경·공급자 장애·잘못된 알림·다중 서비스 영향·롤백 실패를 표본으로 시험합니다. 요청자·상담원·서비스 소유자·변경 승인자·감사의 허용·거부도 확인합니다.

대체 운영자가 신고에서 서비스·구성항목·인시던트·타임라인·변경·롤백·문제·지식·통지·서비스 수준 계산을 역추적하고, 변경 유발 장애 뒤 사용자 관점의 복구와 후속 개선 책임까지 닫을 수 있을 때 인수합니다.