같은 장애, 두 운영자.
A는 "결제가 안 돼요"라는 전화를 받고 바로 서버에 붙어 재시작합니다. 30분 뒤 복구. 보고는 "처리했습니다" 한 줄. 다음 주 같은 장애가 또 납니다.
B는 같은 전화를 받자마자 티켓을 엽니다. 영향 범위(전 고객인지 일부인지)와 긴급도를 확인해 우선순위를 정하고, 임시 복구(재시작) 후 "왜 또?"를 따로 기록해 근본 원인을 추적합니다. 다음 주, 같은 장애는 나지 않습니다.
둘의 차이는 기술력이 아니라 IT를 바라보는 단위입니다. A는 '서버'를 고쳤고, B는 '결제 서비스'를 운영했습니다. 이 트랙은 B의 사고방식 — IT 서비스 관리(ITSM) — 를 다룹니다.
- 1ITSM이 "기술 구성요소"가 아니라 "서비스와 가치"를 관리 단위로 본다는 관점 전환을 설명할 수 있다
- 2서비스·가치·이해관계자·결과(outcome)의 의미를 자기 말로 정의할 수 있다
- 3인시던트·서비스 요청·문제·변경을 구분하고 신고를 올바르게 분류할 수 있다
- 4"개인기 임기응변"과 "반복 가능한 체계(프랙티스)"의 차이와, 왜 체계가 필요한지 설명할 수 있다
- 5이 트랙 전체(ITSM·프로젝트 관리·SI/SM·산출물)가 어떤 직무를 향하는지 지도를 그릴 수 있다
IT를 '서비스'로 본다는 것
관리 단위가 서버에서 서비스로 바뀐다
엔지니어는 보통 구성요소로 세상을 봅니다 — 이 서버, 저 컨테이너, 그 쿼리. ITSM은 한 칸 위에서 봅니다: 이 구성요소들이 모여 사용자에게 무엇을 전달하는가?
- "웹서버 2대 + DB 1대 + 결제 API" → 사용자에게는 '결제 서비스' 하나.
- 사용자는 서버 대수에 관심이 없습니다. **"결제가 3초 안에 되는가"**에 관심이 있습니다.
그래서 ITSM에서 관리의 단위는 서비스입니다. 서비스는 "고객이 특정 비용·리스크를 직접 떠안지 않고 원하는 결과를 얻도록 돕는 수단"으로 정의됩니다. 사내 메일, 그룹웨어, 결제, VPN 접속 — 모두 하나의 서비스입니다.
| 보는 단위 | 엔지니어의 말 | ITSM의 말 |
|---|---|---|
| 구성요소 | "DB CPU가 90%다" | (원인 조사용 신호) |
| 서비스 | — | "주문 서비스 응답이 느려 고객이 이탈 중" |
| 우선순위 | "가장 바쁜 서버부터" | "매출 영향이 큰 서비스부터" |
이 전환이 ITSM의 출발점입니다. 기술을 버리는 게 아니라, 기술 위에 **'그래서 사용자에게 무슨 일이 일어나는가'**라는 렌즈를 하나 더 끼우는 것입니다.
가치·이해관계자·결과 — ITSM의 기본 어휘
가치는 받는 쪽이 정한다
ITSM(그리고 ITIL 4)의 중심 단어는 **가치(value)**입니다. 가치는 공급자가 "우리 좋은 일 했어요"라고 선언하는 게 아니라, 받는 쪽(고객·사용자)이 인식하는 편익과 결과로 정해집니다.
핵심 어휘를 정리하면:
| 용어 | 뜻 | 예 |
|---|---|---|
| 서비스(Service) | 고객이 리스크·비용을 직접 지지 않고 원하는 결과를 얻게 돕는 수단 | 사내 결제 시스템 |
| 가치(Value) | 이해관계자가 인식하는 편익·유용성·중요도 | "결제가 빠르고 안 끊긴다" |
| 결과(Outcome) | 서비스가 가능하게 한, 이해관계자가 원하는 상태 | "고객이 이탈 없이 주문을 끝낸다" |
| 산출물(Output) | 활동이 만든 결과물(결과와 다름) | "서버 증설 완료" |
| 이해관계자(Stakeholder) | 서비스에 영향을 주거나 받는 사람·조직 | 고객, 운영팀, 발주사, 협력사 |
| 효용(Utility) | 무엇을 하는가(기능 적합성) | "해외 카드로 결제된다" |
| 보증(Warranty) | 얼마나 잘 하는가(가용성·성능·보안) | "99.9% 시간 동안 3초 내 결제" |
산출물 ≠ 결과가 특히 중요합니다. "서버를 2배로 늘렸다"는 산출물이지만, 고객이 여전히 느리면 결과(가치)는 0입니다. ITSM은 산출물 보고("했습니다")가 아니라 결과 보고("고객 이탈이 줄었습니다")를 지향합니다.
그림: 산출물("했습니다")과 결과("좋아졌습니다")는 다르며, 가치는 효용·보증 두 축으로 잰다.
신고 한 건을 올바르게 분류하기
인시던트 · 요청 · 문제 · 변경
운영의 하루는 "뭔가 들어온다"로 시작합니다. 그 '뭔가'를 올바른 종류로 분류해야 올바른 절차로 처리됩니다. 이 네 가지는 이 트랙에서 각각 한 모듈로 깊어지지만, 지금은 구분 감각을 잡습니다.
| 종류 | 한 줄 정의 | 신고 예시 | 다루는 핵심 |
|---|---|---|---|
| 인시던트(Incident) | 정상 서비스가 계획 없이 중단·저하됨 | "메일이 안 와요" | 빠른 정상화 |
| 서비스 요청(Request) | 미리 승인된 정상적 요청 | "신규 입사자 계정 만들어 주세요" | 표준 절차로 신속 처리 |
| 문제(Problem) | 하나 이상 인시던트의 근본 원인 | "그 장애가 이번 달만 세 번째" | 재발 방지 |
| 변경(Change) | 서비스에 영향을 줄 의도적 추가·수정·제거 | "결제 모듈 v2 배포 예정" | 리스크 통제된 반영 |
구분의 실전 팁:
- 인시던트 vs 요청: "원래 되던 게 안 되나(인시던트)" vs "원래 없던 걸 새로 해달라(요청)".
- 인시던트 vs 문제: 인시던트는 '지금 이 불을 끄는 것', 문제는 '왜 자꾸 불이 나는지 밝혀 끄지 않게 하는 것'. 인시던트는 빠르게, 문제는 깊게.
- 변경: 사람이 의도적으로 시스템을 건드리는 모든 것. 통제 없는 변경이 인시던트의 가장 흔한 원인입니다.
그림: 같은 "안 돼요"라도 무엇으로 분류하느냐가 처리 절차를 결정한다 — 올바른 분류가 올바른 처리의 출발점.
직접 해보기 — 분류와 영향·긴급도
아래 5건을 (1) 종류로 분류하고, (2) 인시던트라면 영향 범위 × 긴급도로 우선순위(P1~P4)를 매겨 보세요. 정답은 ObserveBlock에 있습니다.
A. "전 직원이 그룹웨어 로그인이 안 됩니다." (오전 9시, 전사)
B. "신규 입사자 3명 메일 계정 생성 부탁드립니다." (인사팀, 내일까지)
C. "지난주부터 매일 새벽 배치가 가끔 실패해요." (반복)
D. "다음 주 화요일 결제 서버 보안 패치를 적용하려 합니다." (예정)
E. "제 자리 모니터가 안 켜져요." (1명, 업무 가능)
우선순위 직관: 영향(몇 명/어떤 서비스) 과 긴급도(업무 멈춤 정도) 를 두 축으로 봅니다. 전사·핵심서비스·지금 멈춤일수록 P1에 가깝습니다.
분류: 인시던트 / 요청 / 문제 / 변경- A = 인시던트, P1 (영향: 전사 / 긴급도: 지금 업무 중단). 즉시 대응·에스컬레이션 대상
- B = 서비스 요청 (정상적·예정된 요청). 표준 절차로 처리, 장애 아님
- C = 문제 (반복·원인 미상). 임시 대응과 별개로 근본원인분석(RCA) 착수 대상
- D = 변경 (의도적 수정 예정). 리스크 평가·승인·롤백 계획·점검창(maintenance window) 필요
- E = 인시던트지만 P4 (영향: 1명 / 긴급도: 업무는 가능). 우선순위 낮게, 그러나 기록은 남긴다
- 핵심 감각: 같은 "안 돼요"라도 영향×긴급도가 다르면 우선순위가 다르다 — 먼저 끌 불을 고르는 것이 운영의 시작
현장에서 자주 보는 함정
증상: 팀에 '에이스' 운영자가 있어 장애를 빠르게 끕니다. 그런데 (1) 같은 장애가 주기적으로 재발하고, (2) 그 사람이 휴가를 가면 대응 품질이 뚝 떨어집니다.
원인: 임기응변이 개인의 머릿속에만 있고 조직의 자산이 되지 못했습니다. 기록(티켓)이 없으니 패턴이 안 보이고(→ 문제관리 불가), 절차가 없으니 다른 사람이 못 합니다(→ 속인화).
해결 방향(이 트랙에서 깊어짐):
- 모든 대응을 티켓으로 기록 → 데이터로 반복 패턴을 발견.
- 반복되면 인시던트와 분리해 문제(Problem)로 등록 → 근본 원인 제거.
- 처리 방법을 지식 베이스에 남겨 누가 해도 같은 품질.
- 자주 오는 정상 요청은 표준 절차/셀프서비스로 만들어 에이스의 시간을 아낀다.
ITSM은 에이스를 대체하는 게 아니라, 에이스의 판단을 팀 전체가 재현할 수 있게 만드는 일입니다.
이 트랙이 향하는 직무는 "코드를 짜는 사람"이 아니라 "서비스와 프로젝트를 관리하는 사람" 입니다 — 발주사·원청의 IT 운영 담당, 서비스데스크·운영(SM) 담당, 프로젝트 관리(PM/PMO), SI 사업관리.
이런 자리에서 당신은 직접 서버를 만지기보다, "이 신고는 무엇이고, 누가, 언제까지, 어떤 절차로 처리하며, 재발을 어떻게 막고, 그 결과를 어떻게 보고하는가" 를 설계하고 통제합니다. 협력사(하도급) 엔지니어가 실제 작업을 하더라도, 서비스 품질(SLA)·일정·범위·산출물에 대한 책임은 관리자에게 있습니다.
그래서 이 트랙은 ITSM(운영의 언어)·프로젝트 관리(PMBOK/PMP의 언어)·SI/SM 구조·보고서와 산출물·자격증(ITIL 4, PMP)까지, 관리 직무가 쓰는 공용어 전체를 기초부터 심화까지 다룹니다. 기술을 아는 관리자는 협력사와 대등하게 대화하고, 잘못된 보고에 속지 않습니다.
관련 모듈로 더 깊이:
- ITIL 4 한눈에 — 이 사고방식을 글로벌 표준 체계(SVS·가이딩 원칙)로 정리한 ITIL 4의 전체 지도
- 인시던트 관리 — 여기서 배운 어휘(인시던트)가 실제 운영에서 어떻게 접수·대응·기록되는가
다음 모듈에서는 이 사고방식을 체계로 만든 글로벌 표준 — ITIL 4의 전체 구조(서비스 가치 시스템, 가이딩 원칙)를 한 장의 지도로 정리합니다.