한 중견기업이 "이제 우리도 제대로 된 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차원 중 하나일 뿐입니다. 균형을 맞추지 않은 기술 투자는 비싼 장식이 됩니다.
심화 — 네 차원이 두 회사로 쪼개질 때
심화: 발주사-수행사 구조에서는 차원마다 주인이 다르다
본문은 네 차원의 '균형'을 말했지만, 한국의 위탁 운영(SM) 구조에는 그보다 앞선 문제가 있습니다 — 차원마다 소속이 다르다는 것입니다.
- ① 조직과 사람: 운영 인력은 수행사 소속입니다. 교육·평가·이탈 관리 권한이 발주사에 없습니다.
- ② 정보와 기술: 시스템·데이터는 발주사 자산입니다. 수행사는 개선 권한이 제한됩니다.
- ③ 파트너와 공급자: 그 사이를 규정하는 계약이 사실상 유일한 접합부입니다.
- ④ 가치 흐름과 프로세스: 흐름은 두 회사를 가로지르는데, 주인이 없기 쉽습니다.
이 구조의 무서운 점은 재계약 주기(보통 1년)마다 차원들이 찢어질 수 있다는 것입니다. 수행사가 교체되면 ①(사람과 머릿속 지식)이 통째로 나가고 ②(문서·데이터)만 남습니다. 본문에서 개인 단위 속인화를 봤다면, 여기서는 회사 단위 속인화가 일어납니다. 그래서 성숙한 발주사는 계약서에 네 차원을 명시적으로 박습니다 — 인수인계 조항에 문서 목록(②)만이 아니라, 핵심 인력의 병행 근무 기간(①), 런북 시연·검증 절차(④), 전임 수행사의 협조 의무와 위반 시 제재(③)까지.
PESTLE도 한국형으로 읽을 수 있어야 합니다. 교과서의 '법(Legal)'은 한국 현장에서 개인정보보호법·전자금융 규제·공공 망분리 정책으로 구체화되고, 이들은 ②(시스템 구조)·③(클라우드 계약 가능 여부)·④(접근 절차)를 한꺼번에 흔듭니다. 규제 변화를 '보안팀 일'로만 미루는 조직은 어느 날 4차원 어딘가가 갑자기 무너지는 경험을 하게 됩니다.
상황: 연말 재입찰에서 운영 수행사가 A사에서 B사로 교체된 제조기업. 12월 2주간 인수인계가 진행됐고, 문서 목록 87종의 전달 확인서에 양사가 서명했습니다. 1월 2일 새벽, 연초 결산 배치가 실패합니다. B사 야간 근무자는 배치 의존 관계를 몰라 복구 순서를 잡지 못했고, A사 인력은 이미 다른 프로젝트에 투입된 뒤였습니다. 발주사 팀장이 "확인서에 서명하지 않았느냐"고 따지자 B사 PL이 답합니다 — "문서는 다 받았습니다. 문제는 문서에 없는 것들입니다."
원인: 인수인계를 ②정보와 기술 한 차원으로만 정의한 것입니다. 문서 87종은 '무엇을 하는가'를 담고 있었지만, '왜 이 순서인가'와 '실패하면 어디부터 보는가'는 A사 담당자의 머릿속에 있었습니다. ①(사람의 지식 이전)을 계획하지 않았고, ④(절차의 실연·검증)를 요구하지 않았으며, ③(계약)에는 전임사의 인수인계 협조 의무가 "성실히 협조한다" 한 줄뿐이라 강제할 수단이 없었습니다.
진단: 인수인계 체크리스트를 다시 열어 보니 전 항목이 '문서 전달 여부'였습니다. 장애 상황을 가정한 시나리오 검증, 배치 실패 복구 실연, 핵심 담당자 동석 기간 — 지식과 절차를 검증하는 항목은 0개. 4차원 점검표로 보면 ② 칸만 가득 차고 ①③④가 빈, 본문 시나리오와 정확히 같은 불균형이 '이관'이라는 행사 안에서 재현된 것입니다.
해결: 재발 방지는 다음 계약에 반영됐습니다. 인수인계 기간을 4주로 늘리되 마지막 2주는 B사가 운전하고 A사가 배석하는 병행 운영으로 구성하고(①), 주요 장애 시나리오 5종의 복구 실연을 이관 완료 조건으로 명문화하며(④), 전임사 협조 의무에 구체적 범위·기간·미이행 시 잔금 유보 조항을 달았습니다(③). 문서는 인수인계의 시작이지 완료 조건이 아닙니다.
한국 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)가 각각 무엇을 다루고 어떻게 보완 관계인지, 그리고 한국 기업의 실제 도입 현황을 한 장의 지형도로 정리합니다.