같은 회사, 같은 6명의 운영·개발 인력. 그런데 두 종류의 일이 완전히 다르게 흘러갑니다.
월요일 오전, 결제 서비스 장애가 터집니다. 고객 신고가 서비스데스크로 들어오고(접수), 곧바로 운영팀이 임시 복구를 하고, 복구 사실을 고객에게 알립니다. 이 일은 빠르게, 좁은 경로로 돕니다 — 받고, 고치고, 알린다.
수요일 오후, 영업팀이 **"해외 카드 결제 기능을 새로 넣어달라"**고 요청합니다. 이 일은 요구사항 정리 → 설계 → 개발·구매 → 테스트 → 배포 → 운영으로 느리고, 넓은 경로로 돕니다. 며칠~몇 주가 걸립니다.
두 일은 "다른 팀이 다른 절차로 하는 별개의 세계"처럼 보이지만, ITIL 4는 둘을 같은 6개 활동으로 설명합니다. 차이는 활동의 종류가 아니라 어떤 활동을, 어떤 순서로, 얼마나 거치느냐 — 즉 **가치 흐름(value stream)**의 모양입니다. 이 모듈은 그 6개 활동과, 그것들이 시나리오마다 다르게 엮이는 방식을 다룹니다.
- 1서비스 가치 사슬(SVC)의 6개 활동(계획·개선·참여·설계및전환·확보및구축·제공및지원)의 목적과 입출력을 표로 설명할 수 있다
- 2참여(Engage)가 왜 모든 외부 상호작용의 입출구이자 가치 사슬의 중심인지 설명할 수 있다
- 3가치 흐름(value stream)이 "6개 활동을 시나리오에 맞게 조합한 경로"라는 정의를 자기 말로 표현할 수 있다
- 4"장애 복구"와 "신규 기능 요청" 가치 흐름이 통과하는 활동 순서·비중의 차이를 비교할 수 있다
- 534개 프랙티스가 활동을 "수행하는 역량 자원"으로서 어떻게 지원하는지 관계를 그릴 수 있다
서비스 가치 사슬은 '활동 6개짜리 엔진'이다
수요를 받아 가치로 되돌리는 가운데 엔진
이전 모듈에서 본 **서비스 가치 시스템(SVS)**을 떠올려 봅시다. SVS는 "수요(demand)와 기회(opportunity)가 들어와 가치(value)로 나간다"는 큰 그림이었습니다. 그 한가운데에서 실제로 변환을 수행하는 엔진이 바로 **서비스 가치 사슬(Service Value Chain, SVC)**입니다.
SVC는 6개의 **활동(activity)**으로 이루어집니다. 중요한 점 두 가지:
- 이 6개 활동은 고정된 직선 순서가 아닙니다. 시나리오에 따라 자유롭게 연결됩니다. 어떤 일은 참여→제공및지원만 거치고, 어떤 일은 6개를 모두 통과합니다.
- 한가운데에 **참여(Engage)**가 있어 외부 세계(고객·사용자·공급자)와 닿는 모든 입력·출력을 받습니다. 나머지 활동은 Engage가 받아온 수요를 가공해 다시 Engage를 통해 내보냅니다.
비유하면, 활동은 공장의 작업 스테이션이고, 뒤에서 볼 가치 흐름은 제품마다 다르게 짜인 컨베이어 경로입니다. 스테이션(활동)은 6개로 정해져 있지만, 만드는 제품(시나리오)에 따라 어떤 스테이션을 어떤 순서로 거칠지가 달라집니다.
6개 활동 — 목적과 입출력
계획 · 개선 · 참여 · 설계및전환 · 확보및구축 · 제공및지원
각 활동의 한/영 명칭, 목적, 그리고 대표적인 입력(input)과 출력(output)을 정리합니다. 입출력을 보면 활동들이 서로 어떻게 물려 돌아가는지가 보입니다.
| 활동 (한/영) | 목적 | 주요 입력 | 주요 출력 |
|---|---|---|---|
| 계획 (Plan) | 비전·방향·정책·우선순위를 정해 전체에 공유 | 정책·전략, 개선 현황, 성과 데이터 | 전략·아키텍처 방향, 정책, 포트폴리오 결정 |
| 개선 (Improve) | 모든 활동·서비스의 지속적 개선(CSI) | 성과 정보, 이해관계자 피드백, 개선 이니셔티브 | 개선 계획, 활동·서비스 변경 요청, 성과 보고 |
| 참여 (Engage) | 이해관계자 수요 파악·관계 관리, 모든 외부 접점 | 수요·요청·장애 신고, 시장 정보, 공급자 계약 | 통합된 요구사항, 제품·서비스 정의, 계약·SLA, 고객 응대 |
| 설계 및 전환 (Design & Transition) | 품질·비용·시장 적시성을 충족하도록 설계하고 운영으로 안전하게 이행 | 요구사항, 정책, 서비스 컴포넌트 | 새/변경된 서비스 명세, 성능 기준, 전환된 서비스 |
| 확보 / 구축 (Obtain/Build) | 서비스 컴포넌트를 마련(구매·구축)해 필요한 곳에 제공 | 계약, 컴포넌트 요구사항, 변경 요청 | 서비스 컴포넌트(구축·구매됨), 배포 가능한 산출물 |
| 제공 및 지원 (Deliver & Support) | 합의된 사양대로 서비스를 운영·지원 | 새/변경된 서비스, 운영 작업, 사용자 요청·인시던트 | 운영 중인 서비스, 처리된 인시던트·요청, 성과·운영 정보 |
읽는 법 한 가지: 개선(Improve)은 모든 활동에 걸쳐 작동합니다. 다른 5개 활동이 만들어내는 성과 정보를 받아 "더 잘할 점"을 찾고, 그 개선을 다시 각 활동으로 흘려보냅니다. 그래서 개선은 가치 흐름의 어느 지점에서든 끼어들 수 있는 상시 활동입니다.
또 하나: 참여(Engage)는 입출구입니다. 위 표에서 Engage의 입력에 "장애 신고"가 있고 출력에 "고객 응대"가 있는 것에 주목하세요. 외부에서 들어온 모든 수요는 Engage로 들어와 다른 활동으로 분배되고, 결과는 다시 Engage를 통해 외부로 나갑니다.
그림: 6개 활동은 고정 순서가 아니라 물려 도는 엔진 — 참여가 입출구, 개선이 상시 작동한다.
가치 흐름 — 같은 활동, 다른 경로
value stream은 '시나리오에 맞춘 활동 조합 경로'다
**가치 흐름(value stream)**은 ITIL 4에서 "특정한 결과(예: 장애 복구, 신규 기능 출시)를 만들기 위해 조직이 수행하는 일련의 단계(활동 조합)"로 정의됩니다. 핵심은:
- 가치 흐름은 SVC의 6개 활동을 재료로 만들어집니다.
- 시나리오가 다르면 통과하는 활동·순서·비중·반복 횟수가 달라집니다.
- 한 조직은 보통 여러 개의 가치 흐름을 정의해 둡니다 — "인시던트 해결 흐름", "신규 서비스 출시 흐름", "사용자 요청 처리 흐름" 등.
같은 공장(6개 활동)을 두고 제품마다 다른 컨베이어 경로를 짜는 것과 같습니다. 아래 표는 두 대표 시나리오가 활동을 통과하는 모습을 비교합니다.
| 비교 항목 | 장애 복구 흐름 | 신규 기능 요청 흐름 |
|---|---|---|
| 입구 | 참여(Engage) — 장애 신고 접수 | 참여(Engage) — 요구사항 수렴 |
| 비중 큰 활동 | 제공및지원(Deliver & Support) | 설계및전환 + 확보및구축 |
| 속도 | 빠름(분~시간), 좁은 경로 | 느림(일~주), 넓은 경로 |
| 계획(Plan) 관여 | 약함(우선순위 기준만 참조) | 강함(범위·아키텍처 결정) |
| 개선(Improve) 연결 | 사후(포스트모템→재발방지) | 사전·사후 모두 |
| 출구 | 참여 — 복구 안내·결과 보고 | 참여 — 출시 안내·인수 확인 |
이 표가 말하는 한 줄: "활동의 종류는 같다. 흐르는 길이 다를 뿐이다." 그래서 운영자는 6개 활동이라는 공통 언어로 모든 종류의 일을 설명할 수 있습니다.
그림: 같은 6개 활동이라도 장애 복구는 좁고 빠른 경로, 신규 기능 요청은 넓고 신중한 경로 — 시나리오가 가치 흐름의 모양을 정한다.
직접 해보기 — 신규 요청을 가치 흐름으로 그려 보기
시나리오 블록의 수요일 요청 — "해외 카드 결제 기능 추가" — 을 6개 활동을 사용해 가치 흐름으로 그려 보세요. 각 단계에서 (1) 어떤 활동인지, (2) 그 단계에서 끌어다 쓰는 프랙티스가 무엇일지 한 줄씩 적어 봅니다. 정답 예시는 다음 ObserveBlock에 있습니다.
요청 접수 → ? → ? → ? → ? → ? → 출시 안내
(빈칸을: 계획 / 설계및전환 / 확보및구축 / 제공및지원 중에서 채워 넣고,
각 단계가 쓰는 프랙티스도 함께 적어 보세요)
힌트: 새 기능은 "방향 확인(계획) → 요구사항·설계(참여·설계및전환) → 개발·구매(확보및구축) → 안전한 반영(설계및전환) → 운영(제공및지원)"으로 흐르고, 모든 외부 응대는 참여(Engage)가 감쌉니다.
활동 순서: 참여 → ? → ? → ? → ? → 참여- 1단계 참여(Engage): 영업팀 요구사항 수렴·우선순위 합의 → 사용하는 프랙티스: 비즈니스 분석, 관계 관리
- 2단계 계획(Plan): 범위·아키텍처 방향·예산 결정 → 프랙티스: 포트폴리오 관리, 아키텍처 관리
- 3단계 설계및전환(Design & Transition): 결제 흐름 설계·테스트 계획 → 프랙티스: 서비스 설계, 변경 관리, 릴리스 관리
- 4단계 확보및구축(Obtain/Build): 해외 결제 PG 연동 개발·계약 → 프랙티스: 소프트웨어 개발 및 관리, 공급자 관리
- 5단계 설계및전환 재방문: 운영 환경에 안전하게 배포 → 프랙티스: 변경 관리, 배포 관리, 릴리스 관리
- 6단계 제공및지원(Deliver & Support): 운영·모니터링·사용자 지원 → 프랙티스: 인시던트 관리, 서비스 요청 관리, 모니터링/이벤트 관리
- 마무리 참여(Engage): 출시 안내·인수 확인 → 프랙티스: 관계 관리, 서비스 수준 관리(SLM)
- 핵심 감각: 한 가치 흐름이 활동을 여러 번 오갈 수 있고(설계및전환을 두 번 통과), 각 활동마다 다른 프랙티스를 끌어다 쓴다
현장에서 자주 보는 함정
증상 1 — 산출물에서 멈춤: 협력사가 "서버 증설 완료", "기능 개발 완료"라고 보고하면 일이 끝난 것처럼 여깁니다. 그런데 고객은 여전히 "그래서 빨라졌냐", "결제가 실제로 되냐"를 묻습니다.
원인 1: 확보및구축(Obtain/Build)은 산출물(output) 을 만드는 활동일 뿐입니다. 그것이 설계및전환으로 안전하게 반영되고, 제공및지원으로 운영되며, 참여(Engage)를 통해 고객이 원하던 결과(outcome) 가 확인되어야 가치 흐름이 닫힙니다. "구축 완료"는 컨베이어 중간 스테이션을 통과한 것이지 출고가 아닙니다.
증상 2 — 6개 활동을 고정 직선으로 오해: "무조건 계획→설계→구축→제공 순서로만 가야 한다"고 굳게 믿어, 빠른 장애 복구마저 무거운 설계·구축 단계를 끼워 넣으려 합니다. 반대로 큰 신규 구축을 참여→제공으로만 처리하려다 설계·테스트를 건너뛰어 사고를 냅니다.
원인 2: SVC의 6개 활동은 고정 순서가 아니라 시나리오별 가치 흐름으로 자유롭게 조합됩니다. 장애 복구는 좁고 빠른 경로, 신규 구축은 넓고 신중한 경로 — 같은 활동을 다른 길로 엮는 것입니다.
해결 방향(이 트랙에서 깊어짐):
- 모든 보고를 결과(outcome) 기준으로 — "구축 완료"가 아니라 "고객 결제 성공률 99.9% 확인".
- 일의 종류별로 가치 흐름을 미리 정의해 두기(장애·요청·변경·신규) → 매번 즉흥 판단을 줄임.
- 각 활동에서 어떤 프랙티스를 쓸지 매핑해 두면, 누가 해도 같은 품질로 흐름을 탄다.
한국 IT서비스사(삼성SDS·LG CNS·SK AX·롯데정보통신 등)와 MSP 현장에서, 운영·PM 담당자는 직접 코드를 짜거나 서버를 만지기보다 "이 일이 어떤 경로(가치 흐름)로 흘러야 하는가"를 설계하고 통제합니다.
예컨대 SM(유지보수) 계약에서 장애가 나면 "장애 복구 흐름"으로 빠르게 돌리되 SLA 시간 안에 복구·보고를 끝내야 하고, 발주사가 신규 기능을 요청하면 "신규 출시 흐름"으로 과업범위(과업 변경)·M/M 산정·검수 절차를 밟아야 합니다. 같은 6개 활동을 두 흐름으로 나눠 관리하는 것이 곧 운영관리자의 일입니다.
이 사고가 몸에 배면, 협력사(하도급) 엔지니어가 "개발 완료했습니다"라고 할 때 **"그건 확보및구축 산출물일 뿐, 설계및전환(배포·검수)과 제공및지원(운영 안정화)까지 가야 인수합니다"**라고 정확히 통제할 수 있습니다. 산출물 보고에 속지 않고 결과까지 책임지는 것 — 그것이 가치 사슬을 이해한 관리자의 강점입니다.
관련 모듈로 더 깊이:
- ITIL 4 한눈에 — 가치 사슬이 자리한 SVS 전체 구조와 가이딩 원칙을 되짚는 지도
- 서비스 관리의 4가지 차원 — 6개 활동을 '어떤 관점에서 빠짐없이 볼지' 보완하는 4가지 차원
다음 모듈에서는 서비스 가치 사슬을 떠받치는 또 다른 축 — 사람·조직, 정보·기술, 파트너·공급자, 가치 흐름·프로세스로 이루어진 **서비스 관리의 4가지 차원(four dimensions)**을 다룹니다. 6개 활동이 '무엇을 하는가'라면, 4가지 차원은 '그 활동을 빠짐없이 보려면 어떤 관점에서 봐야 하는가'입니다.