같은 회사, 같은 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% 확인".
- 일의 종류별로 가치 흐름을 미리 정의해 두기(장애·요청·변경·신규) → 매번 즉흥 판단을 줄임.
- 각 활동에서 어떤 프랙티스를 쓸지 매핑해 두면, 누가 해도 같은 품질로 흐름을 탄다.
심화 — 가치 사슬을 계약 경계가 자른다
심화: 구축과 운영이 다른 회사일 때 — 설계및전환은 누구의 일인가
본문은 6개 활동이 한 조직 안에서 물려 도는 그림을 그렸지만, 한국 SI 관행에서는 이 사슬 위에 계약 경계가 그어집니다. 구축(SI)과 운영(SM)은 대개 별도 계약이고, 흔히 다른 회사가 수행합니다. 가치 사슬에 대입하면 확보및구축과 설계및전환 전반부는 구축 계약이, 제공및지원은 운영 계약이 가져가는데 — 설계및전환의 후반부, 즉 '운영으로의 이행'은 어느 계약에도 온전히 속하지 않는 공백이 됩니다. 구축사는 검수만 통과하면 대금을 받고, 운영사는 검수에 참여한 적이 없습니다.
이 구조를 아는 관리자가 챙기는 것들:
- 검수와 전환을 구분합니다: 검수는 "요구사항대로 만들어졌는가"(산출물)를, 전환은 "운영 조직이 이것을 진단·복구·개선할 수 있는가"(운영 준비도)를 봅니다. 검수 조건에 런북·모니터링 이관·운영사 교육을 넣지 않으면 전환은 일어나지 않습니다.
- 운영사를 설계및전환에 조기 참여시킵니다: 오픈 한 달 전 문서 전달이 아니라 설계 리뷰·테스트 단계부터 운영사가 배석해야, "받았는데 굴릴 수 없는 시스템"이 안 나옵니다.
- 하자보수와 운영의 경계를 미리 가릅니다: 하자보수(통상 무상 1년)는 '결함 수정'이고 장애 대응·성능 개선은 운영의 영역인데, 실제 장애는 늘 그 경계에 걸칩니다. 사안 유형별 책임 매트릭스를 오픈 전에 합의해 두는 것이 분쟁 공문 열 통보다 쌉니다.
하나 더 — 참여(Engage)의 한국적 구현입니다. 발주사-수행사 사이의 공식 Engage는 공문과 회의록입니다. 책임 추적에는 꼭 필요하지만 공문 왕복은 며칠 단위라, 장애 복구 흐름의 속도와 정면충돌합니다. 성숙한 현장은 채널을 이원화합니다 — 일은 실무 채널(전화·메신저·상황실)로 즉시 진행하고, 결정과 책임은 공문으로 사후 확정. 이 순서를 뒤집어 공문 회신을 기다렸다 착수하면, 가치 흐름이 문서 흐름에 잡아먹힙니다.
상황: 공공기관의 신규 포털을 구축사 C가 개발해 12월 검수 완료, 1월부터 기존 운영사 D가 운영을 맡았습니다. 2월 첫 장애 — 특정 시간대 로그인 지연이 발생하자 D사는 전달받은 아키텍처 문서만으로는 원인 구간을 좁히지 못했고, C사에 지원을 요청하니 "성능 저하는 하자(결함)가 아니라 운영 이슈"라는 회신이 왔습니다. 발주 담당자가 양사에 공문을 보내고 회신을 기다리는 사이 2주가 흘렀고, 그동안 같은 장애가 세 번 더 났습니다.
원인: 가치 사슬로 보면 설계및전환(Design & Transition)의 핵심인 '운영 조직으로의 지식·절차 이행'이 실행되지 않았습니다. 구축 계약은 '검수'로 끝나는데, 검수는 요구사항 충족(산출물)을 확인하는 이벤트지 **운영 가능성(운영사가 장애를 진단·복구할 수 있는가)**을 확인하는 절차가 아닙니다. 운영사 D는 설계 단계에 참여한 적이 없어 시스템을 '받은 문서만큼만' 알았고, 하자보수 조항은 결함 수정만 다뤄 장애 대응 협조를 강제하지 못했습니다.
진단: 검수 체크리스트를 확인하니 기능 시험·성능 시험·보안 점검 항목은 수십 개인데, 운영 전환 항목 — 런북 존재 여부, 운영사 대상 장애 시나리오 교육, 모니터링 이관 — 은 0개였습니다. 가치 흐름이 '검수'라는 계약 이벤트에서 절단된 것이 문서로 확인된 셈입니다.
해결: 발주 기관은 이후 사업부터 두 가지를 바꿨습니다. 첫째, 검수 조건에 운영 전환 게이트를 추가 — 운영사가 참여하는 장애 시나리오 실연과 런북·모니터링 이관 확인이 통과돼야 검수가 완료됩니다. 둘째, 구축-운영의 책임 경계를 하자 대 운영의 이분법이 아니라 사안 유형별 매트릭스(코드 결함/설정/용량/외부 연동)로 사전 합의해, 장애가 났을 때 '누구 일인지'부터 다투는 공문 왕복을 없앴습니다. 산출물이 아니라 결과까지 — 본문의 원칙은 계약서에 박혀야 현장에서 작동합니다.
한국 IT서비스사(삼성SDS·LG CNS·SK AX·롯데정보통신 등)와 MSP 현장에서, 운영·PM 담당자는 직접 코드를 짜거나 서버를 만지기보다 "이 일이 어떤 경로(가치 흐름)로 흘러야 하는가"를 설계하고 통제합니다.
예컨대 SM(유지보수) 계약에서 장애가 나면 "장애 복구 흐름"으로 빠르게 돌리되 SLA 시간 안에 복구·보고를 끝내야 하고, 발주사가 신규 기능을 요청하면 "신규 출시 흐름"으로 과업범위(과업 변경)·M/M 산정·검수 절차를 밟아야 합니다. 같은 6개 활동을 두 흐름으로 나눠 관리하는 것이 곧 운영관리자의 일입니다.
이 사고가 몸에 배면, 협력사(하도급) 엔지니어가 "개발 완료했습니다"라고 할 때 **"그건 확보및구축 산출물일 뿐, 설계및전환(배포·검수)과 제공및지원(운영 안정화)까지 가야 인수합니다"**라고 정확히 통제할 수 있습니다. 산출물 보고에 속지 않고 결과까지 책임지는 것 — 그것이 가치 사슬을 이해한 관리자의 강점입니다.
관련 모듈로 더 깊이:
- ITIL 4 한눈에 — 가치 사슬이 자리한 SVS 전체 구조와 가이딩 원칙을 되짚는 지도
- 서비스 관리의 4가지 차원 — 6개 활동을 '어떤 관점에서 빠짐없이 볼지' 보완하는 4가지 차원
다음 모듈에서는 서비스 가치 사슬을 떠받치는 또 다른 축 — 사람·조직, 정보·기술, 파트너·공급자, 가치 흐름·프로세스로 이루어진 **서비스 관리의 4가지 차원(four dimensions)**을 다룹니다. 6개 활동이 '무엇을 하는가'라면, 4가지 차원은 '그 활동을 빠짐없이 보려면 어떤 관점에서 봐야 하는가'입니다.