같은 장애, 두 운영자.
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은 에이스를 대체하는 게 아니라, 에이스의 판단을 팀 전체가 재현할 수 있게 만드는 일입니다.
심화 — 어휘가 계약서에 들어가는 순간
심화: 분류는 중립이 아니다 — 건수가 돈이 되는 구조에서 벌어지는 일
네 가지 어휘(인시던트·요청·문제·변경)를 자체 운영 조직이 쓰면 품질 도구지만, 한국에서 흔한 발주사-수행사(SM 위탁) 구조에서는 이 어휘가 계약서와 정산서의 단위가 됩니다. 그 순간 분류의 성격이 바뀝니다.
- 분류에 이해관계가 붙습니다: SLA 페널티가 인시던트 건수·복구시간에 걸려 있으면, 수행사에게는 애매한 신고를 '단순 문의'나 '요청'으로 분류할 유인이, 발주사에게는 반대 유인이 생깁니다. 악의가 아니라 구조입니다 — 그래서 성숙한 계약은 분류 기준을 사례집 형태로 계약 시점에 합의하고, 분류 변경 이력을 감사 가능하게 남깁니다.
- 형해화 신호를 읽는 법: ITSM을 '도입'한 조직이 실제로 굴리고 있는지는 티켓 원장이 말해 줍니다. ① 티켓 등록 시각이 월말에 몰림(보고용 사후 입력), ② 분류의 절반 이상이 '기타', ③ 문제(Problem) 티켓이 연중 0건 — 셋 중 하나라도 보이면 그 조직의 ITSM은 보고서 안에만 존재합니다. 특히 ③이 치명적입니다. 인시던트만 세고 문제를 안 여는 조직은 같은 불을 영원히 다시 끄고 있다는 뜻입니다.
- 규모에 맞는 최소 세트: 네 어휘 전부를 갖춘 프로세스는 전담 인력이 있는 조직의 이야기입니다. IT 담당이 두세 명인 조직이 그대로 도입하면 기록 부담만 남습니다. 최소 세트는 두 가지 — 모든 대응을 한 곳에 기록하는 것과 인시던트/요청 두 갈래만 구분하는 것. 문제·변경 어휘는 반복 장애가 눈에 보이기 시작할 때 추가해도 늦지 않습니다.
어휘를 배우는 진짜 이유는 시험이 아닙니다. 분류 하나가 우선순위·책임·돈을 결정하는 자리에서, 그 판정을 방어하고 검증할 수 있어야 하기 때문입니다.
상황: 그룹웨어 운영을 위탁한 중견기업. 매달 수행사 월간보고에는 "인시던트 10~12건, SLA 달성률 99%"가 찍혔고, 발주사 팀장은 안정 운영으로 평가했습니다. 6월 어느 월요일, 그룹웨어가 4시간 전사 중단됩니다. 경영진이 "이런 장애가 처음이냐"고 물었을 때, 티켓 시스템에는 답할 근거가 없었습니다.
원인: 조사해 보니 같은 증상(로그인 지연·간헐 접속 불가)의 신고가 반년간 9건 있었지만 전부 '단순 문의'로 분류되어 인시던트 통계에 잡히지 않았습니다. SLA 페널티가 인시던트 건수와 복구시간에만 걸려 있어, 애매한 건을 문의로 분류할수록 수행사 성적이 좋아지는 구조였습니다. 반복 패턴이 통계에서 사라졌으니 문제(Problem)로 등록될 기회도 없었습니다.
진단: 티켓 원장에서 '문의' 분류 건의 본문을 키워드("안 됨", "멈춤", "느려")로 전수 검색했습니다. 재분류 결과 실제 인시던트는 보고된 수치의 약 3배였고, 그중 동일 증상 9건이 한 덩어리로 드러났습니다 — 대형 장애의 전조가 반년간 기록 밖에 있었던 것입니다.
해결: 분류 기준을 사례집으로 만들어 양사가 합의하고("원래 되던 것의 이상 신고는 규모와 무관하게 인시던트"), 분류 변경 이력을 감사 항목에 넣었습니다. 페널티 구조도 손봤습니다 — 인시던트 건수 대신 재발률과 문제 처리 이행률에 무게를 옮겨, 솔직하게 기록할수록 유리한 구조로 바꿨습니다. 분류를 정직하게 만드는 것은 교육이 아니라 유인 설계입니다.
이 트랙이 향하는 직무는 "코드를 짜는 사람"이 아니라 "서비스와 프로젝트를 관리하는 사람" 입니다 — 발주사·원청의 IT 운영 담당, 서비스데스크·운영(SM) 담당, 프로젝트 관리(PM/PMO), SI 사업관리.
이런 자리에서 당신은 직접 서버를 만지기보다, "이 신고는 무엇이고, 누가, 언제까지, 어떤 절차로 처리하며, 재발을 어떻게 막고, 그 결과를 어떻게 보고하는가" 를 설계하고 통제합니다. 협력사(하도급) 엔지니어가 실제 작업을 하더라도, 서비스 품질(SLA)·일정·범위·산출물에 대한 책임은 관리자에게 있습니다.
그래서 이 트랙은 ITSM(운영의 언어)·프로젝트 관리(PMBOK/PMP의 언어)·SI/SM 구조·보고서와 산출물·자격증(ITIL 4, PMP)까지, 관리 직무가 쓰는 공용어 전체를 기초부터 심화까지 다룹니다. 기술을 아는 관리자는 협력사와 대등하게 대화하고, 잘못된 보고에 속지 않습니다.
관련 모듈로 더 깊이:
- ITIL 4 한눈에 — 이 사고방식을 글로벌 표준 체계(SVS·가이딩 원칙)로 정리한 ITIL 4의 전체 지도
- 인시던트 관리 — 여기서 배운 어휘(인시던트)가 실제 운영에서 어떻게 접수·대응·기록되는가
다음 모듈에서는 이 사고방식을 체계로 만든 글로벌 표준 — ITIL 4의 전체 구조(서비스 가치 시스템, 가이딩 원칙)를 한 장의 지도로 정리합니다.