한 중견기업이 "이제 우리도 제대로 된 IT 운영을 하자"며 유명 ITSM 도구를 거액에 도입했습니다. 화려한 대시보드, 자동 분류, SLA 타이머까지 다 있는 물건이었죠.
반년 뒤, 도구를 열어 보니 거의 비어 있었습니다. 직원들은 여전히 메신저와 전화로 "그거 또 안 돼요"를 외쳤고, 운영자는 머릿속 기억으로 불을 껐습니다. 경영진은 물었습니다. "비싼 도구를 샀는데 왜 그대로죠?"
답은 도구에 있지 않았습니다. 도구(기술)만 바꾸고, 그 도구를 쓸 사람의 역할·교육·습관, 신고가 흐르는 절차, 외주 운영사와의 책임 분담은 그대로 뒀기 때문입니다. 서비스는 기술 하나로 굴러가지 않습니다. 사람·기술·공급자·프로세스가 동시에 맞물려야 합니다.
ITIL 4는 이 "동시에 봐야 할 네 가지 면"을 **서비스 관리의 4가지 차원(Four Dimensions of Service Management)**이라 부릅니다. 이 모듈은 한쪽만 챙겼다 실패하는 패턴을, 네 개의 렌즈로 분해해 봅니다.
- 1ITIL 4의 4가지 차원(조직과 사람·정보와 기술·파트너와 공급자·가치 흐름과 프로세스)을 한/영으로 정의할 수 있다
- 2각 차원의 의미와 예시, 그 차원을 소홀히 했을 때 나타나는 실패 증상을 설명할 수 있다
- 34가지 차원이 특정 프로세스가 아니라 모든 서비스·프랙티스에 동시에 적용되며, 균형이 깨지면 실패한다는 원리를 설명할 수 있다
- 4PESTLE(정치·경제·사회·기술·법·환경) 외부 요인이 4차원에 어떻게 영향을 주는지 예로 들 수 있다
- 5특정 서비스(예: 사내 그룹웨어)를 4가지 차원으로 점검하는 체크리스트를 직접 작성할 수 있다
서비스는 한 면만으로 굴러가지 않는다
왜 '4가지 차원'인가 — 균형의 문제
서비스를 만들고 운영하는 일은 보통 한쪽으로 기웁니다. 엔지니어는 기술로, 관리자는 절차로, 구매팀은 계약으로 세상을 봅니다. 각자 자기 면만 열심히 챙기면 서비스 전체가 흔들립니다 — 좋은 도구를 샀는데 아무도 안 쓰거나(사람 무시), 절차는 완벽한데 외주사가 안 따르거나(공급자 무시) 하는 식으로요.
ITIL 4는 그래서 어떤 서비스든, 어떤 활동이든 동시에 고려해야 할 네 개의 면을 정의합니다. 이것이 **4가지 차원(Four Dimensions)**입니다. 핵심은 두 가지입니다.
- 전방위성: 4차원은 특정 프로세스 전용이 아니라 모든 서비스·모든 프랙티스에 동시에 적용됩니다. 인시던트 관리에도, 변경 관리에도, 신규 서비스 출시에도 네 면을 다 봅니다.
- 균형: 네 면은 어느 하나도 빠지면 안 됩니다. 한 면에 자원을 몰빵하고 다른 면을 굶기면 그 굶은 면이 서비스 전체의 발목을 잡습니다.
4가지 차원 — 의미·예시·소홀히 했을 때
네 차원을 정확한 한/영 명칭과 함께 정리하면 다음과 같습니다. **마지막 열(소홀히 했을 때)**이 현장에서 가장 자주 보는 실패 신호입니다.
| 차원 (한/영) | 의미 | 현장 예시 | 소홀히 했을 때 나타나는 증상 |
|---|---|---|---|
| ① 조직과 사람(Organizations & People) | 서비스를 만드는 조직 구조·역할·책임(R&R)·역량·문화·일하는 방식 | 서비스데스크·운영팀·PMO의 R&R, 교육, 변화 수용 문화 | 좋은 도구·절차가 있어도 아무도 안 쓴다. 역할이 겹치거나 비어 책임 떠넘김, 담당자 이탈 시 운영 마비(속인화) |
| ② 정보와 기술(Information & Technology) | 서비스를 떠받치는 정보·데이터·지식과 기술·도구·인프라 | 티켓 시스템, CMDB, 모니터링, 지식베이스, 데이터 정확성·보안 | 데이터가 흩어져 현황 파악 불가, 도구 노후·미연동으로 수작업·중복입력, 보안 사고·데이터 품질 저하 |
| ③ 파트너와 공급자(Partners & Suppliers) | 서비스 제공에 관여하는 외부 파트너·공급자·외주·클라우드와의 관계·계약·SLA | 클라우드 사업자, SaaS, 운영 외주(SM), 솔루션 벤더, 하도급 협력사 | 장애 시 책임 미루기, SLA·책임 범위 불명확으로 복구 지연, 공급자 종속(lock-in)·단일 공급자 리스크 |
| ④ 가치 흐름과 프로세스(Value Streams & Processes) | 가치를 만들기 위해 활동이 어떻게 흐르고 어떤 절차로 일하는가 | 신고 접수→분류→처리→종결의 흐름, 변경 절차, 표준 작업 절차 | 절차가 없어 매번 다르게 처리, 병목·재작업·핸드오프 누락, 누가 해도 같은 품질이 안 됨 |
핵심 메시지: 위 네 줄은 한 줄도 빼면 안 됩니다. 시나리오의 회사는 ②(좋은 도구)만 챙기고 ①(사람·역할·교육)·④(신고가 흐르는 절차)를 굶겼기에 실패했습니다. 반대로 절차(④)만 정교하게 짜고 그걸 실행할 사람(①)을 교육하지 않아도, 외주사와 책임을 명확히(③) 하지 않아도 똑같이 무너집니다.
그림: 네 차원은 모든 서비스에 동시에 적용되며 균형이 핵심 — 가장 약한 차원이 서비스 전체의 한계를 정하고, PESTLE은 그 바깥에서 네 차원 모두를 흔든다.
조직 바깥에서 들어오는 압력 — PESTLE
4차원을 둘러싼 외부 영향 요인
4가지 차원은 조직이 어느 정도 통제할 수 있는 내부의 면입니다. 하지만 서비스는 진공 속에 있지 않습니다. 조직 바깥의 환경이 네 차원 모두에 끊임없이 영향을 줍니다. ITIL 4는 이 외부 요인을 분석하는 틀로 PESTLE을 씁니다.
| 요인 (한/영) | 무엇인가 | 4차원에 주는 영향 예시 |
|---|---|---|
| 정치 (Political) | 정부 정책·규제 방향·공공 조달 정책 | 공공 클라우드 우선 정책 → 파트너·공급자 선택(③) 변화 |
| 경제 (Economic) | 경기·환율·예산·인건비 | 경기 침체로 IT 예산 삭감 → 인력(①)·외주 계약(③) 축소 |
| 사회 (Social) | 인구·근무 문화·사용자 기대 | 재택근무 확산 → 원격 접속 서비스(②)·운영 방식(①④) 변화 |
| 기술 (Technological) | 신기술·자동화·AI·표준 변화 | 생성형 AI 등장 → 도구·자동화(②)와 일하는 방식(①④) 재편 |
| 법 (Legal) | 법률·규제·계약 의무 | 개인정보보호법 강화 → 데이터 처리(②)·절차(④)·공급자 계약(③) 변경 |
| 환경 (Environmental) | 친환경·에너지·지속가능성 | 데이터센터 탄소 규제 → 인프라(②)·공급자(③) 선택 기준 변화 |
PESTLE은 "4차원을 둘러싼 날씨"라고 생각하면 됩니다. 우리가 바꿀 수는 없지만, 무시하면 4차원의 어딘가가 갑자기 흔들립니다. 그래서 서비스를 설계·점검할 때 내부 4차원과 외부 PESTLE을 함께 봅니다.
그림: 외부 PESTLE 요인 하나가 내부 4차원의 여러 면을 한꺼번에 흔든다 — 그래서 둘을 함께 본다.
직접 해보기 — 사내 그룹웨어를 4차원으로 점검하기
회사가 매일 쓰는 사내 그룹웨어(메일·전자결재·일정) 하나를 골라, 아래 점검표의 각 칸을 채워 보세요. "지금 잘 되고 있나?"와 "안 되면 무슨 증상이 나타날까?"를 함께 적는 것이 핵심입니다. 빈칸을 채우다 보면 어느 차원이 약한지가 드러납니다.
[ 사내 그룹웨어 4차원 점검표 — 빈칸을 채우세요 ]
① 조직과 사람
- 운영 담당자/백업 담당자가 지정돼 있는가? (___)
- 사용자 교육·매뉴얼이 있는가? (___)
- 담당자가 휴가여도 대응 가능한가? (___)
② 정보와 기술
- 사용량·장애 이력이 데이터로 남는가? (___)
- 백업·보안 패치가 정기적인가? (___)
- 다른 사내 시스템(인사·메신저)과 연동되나? (___)
③ 파트너와 공급자
- 외부 메일/클라우드/유지보수 업체가 있는가? (___)
- 그 업체와 SLA·장애 시 책임이 명확한가? (___)
- 한 업체에만 묶여(lock-in) 있지는 않은가? (___)
④ 가치 흐름과 프로세스
- 장애 신고→처리→종결 절차가 정의돼 있는가? (___)
- 신규 입사자 계정 발급 절차가 표준화됐나? (___)
- 누가 처리해도 같은 결과가 나오는가? (___)
[ 외부 요인(PESTLE) 점검 ]
- 법: 개인정보·메일 보관 의무를 지키는가? (___)
- 기술: 클라우드 전환·AI 도입 압력이 있나? (___)
대상 서비스: 사내 그룹웨어(메일·결재·일정)- 한 차원의 칸이 유난히 비거나 "아니오"가 몰린다면 — 그 차원이 이 서비스의 약점이다. (예: ① 칸이 비면 담당자 이탈 시 운영 마비 위험)
- ② 칸이 가득 차고 다른 칸이 비었다면 — 시나리오 회사와 같은 "기술만 챙긴" 불균형. 도구를 더 사도 해결되지 않는다
- ③ 칸에서 SLA·책임이 비어 있다면 — 평소엔 안 보이다가 큰 장애 때 "서로 책임 미루기"로 터진다. 의존도가 높을수록 치명적
- ④ 칸에서 "누가 해도 같은 결과"가 아니오라면 — 속인화·재작업 비용이 숨어 있다. 절차 표준화가 우선 과제
- PESTLE 칸의 "법"이 비어 있다면 — 지금은 괜찮아 보여도 규제 점검에서 한 번에 터질 수 있는 잠복 리스크
- 핵심 감각: 4차원은 점수를 매기는 시험이 아니라 "균형이 어디서 깨졌는지" 찾는 렌즈다. 가장 약한 차원이 서비스 전체의 한계를 정한다
현장에서 자주 보는 함정
증상: 경영진이 "디지털 전환", "운영 자동화"를 외치며 ITSM 도구·모니터링·자동화 솔루션을 도입합니다. 그런데 1년이 지나도 장애 대응 품질은 그대로고, 도구 라이선스 비용만 늘었습니다.
원인: ②(정보와 기술) 한 차원에 자원을 몰빵하고 나머지 세 차원을 굶긴 전형적인 불균형입니다.
- ①(조직과 사람): 도구를 쓸 역할·교육·인센티브를 안 만들어, 직원들이 옛 방식(전화·메신저)을 고수.
- ④(가치 흐름과 프로세스): 신고가 도구로 흐르도록 절차를 재설계하지 않아, 도구는 입력이 안 됨.
- ③(파트너와 공급자): 운영 외주사가 새 도구를 안 쓰는데도 계약·SLA에 반영하지 않아 강제력이 없음.
해결 방향: 기술 도입을 변화의 시작점으로만 보고, 같은 프로젝트 안에서 네 차원을 함께 움직입니다.
- 도구 도입과 동시에 역할·교육·"이제 모든 신고는 도구로"라는 규칙(①)을 정한다.
- 신고가 흐르는 **절차(④)**를 도구에 맞춰 다시 그린다.
- 외주 운영사의 **계약·SLA(③)**에 "도구 사용·SLA 준수"를 명문화한다.
- 데이터·연동(②)은 그 위에서 비로소 가치를 낸다.
도구는 4차원 중 하나일 뿐입니다. 균형을 맞추지 않은 기술 투자는 비싼 장식이 됩니다.
한국 IT서비스사(SI/SM)·MSP 현업에서 4가지 차원은 "ITIL 시험 용어"가 아니라 사업·운영의 현실입니다.
- 운영(SM) 담당으로 들어가면 ③(파트너와 공급자)이 곧 당신의 일상입니다. 고객사·원청·하도급 협력사·클라우드 사업자 사이에서 SLA·과업범위·책임 분담을 조율합니다. 장애가 나면 "이건 우리 영역, 저건 클라우드 영역"을 가르는 切り分け(장애 구간 분리)가 핵심 역량입니다.
- 신규 서비스·시스템 오픈 때는 네 차원을 한꺼번에 점검합니다. 인프라(②)만 준비되면 끝이 아니라, 운영 인력·교육(①), 운영 절차·매뉴얼(④), 유지보수 업체 계약(③)이 함께 갖춰져야 "오픈 가능"입니다. 이 점검표가 곧 오픈 체크리스트가 됩니다.
- 경영보고·제안서에서도 "도구 도입"만 적으면 약합니다. 사람·절차·공급자까지 함께 다룬 계획이라야 의사결정자를 설득합니다. 그리고 PESTLE — 특히 **법(개인정보보호·전자금융 등 규제)**과 기술(클라우드·AI 전환) — 은 한국 공공·금융 사업에서 제안의 당락을 가르는 외부 변수입니다.
즉 4가지 차원은 "균형 잡힌 서비스 관점"을 갖춘 관리자라는 신호이자, 실제 오픈·운영·제안 문서를 만들 때 그대로 쓰는 점검 틀입니다.
관련 모듈로 더 깊이:
- ITIL 4 한눈에 — 4가지 차원이 속한 ITIL 4 SVS 전체 구조와 가이딩 원칙
- ITIL만 있는 게 아니다 — ITIL 외 COBIT·ISO 20000·DevOps와의 보완 관계 지형도
다음 모듈에서는 ITIL과 다른 프레임워크(COBIT·ISO 20000·DevOps)가 각각 무엇을 다루고 어떻게 보완 관계인지, 그리고 한국 기업의 실제 도입 현황을 한 장의 지형도로 정리합니다.