서비스 카탈로그: 요청 하나가 이행으로 연결되는 구조
ITSM/ITIL 서비스 카탈로그의 항목 모델·승인 워크플로우·거버넌스 구조와 요청 자동화 사례를 실무 관점에서 정리한다.
2026-08-13 · 최초 발행 2025-12-03
신규 입사자 한 명의 계정·권한·장비 요청이 부서별 이메일과 수기 티켓을 거쳐 처리되면 온보딩 첫 주가 통째로 사라진다. 이런 조직에 공통으로 빠진 것이 서비스 카탈로그다. IT와 비즈니스 서비스의 제공 단위를 표준화하고 셀프서비스로 연결하는 구성 요소로, ITIL·ITSM 프레임워크의 중심에 있으며 서비스 정의·요청·이행·측정을 하나의 체계로 통합해 리드타임 단축과 품질 일관성 확보에 기여한다.
포트폴리오와 카탈로그는 다른 층위다
서비스 카탈로그는 조직이 제공하는 서비스와 요청 가능한 항목을 구조화해 공개하는 공식 목록이다. 설명, 조건, 가격/원가, SLA/OLA, 요청 양식, 승인 규칙, 이행 절차를 포함한다. 서비스 포트폴리오는 전략·투자 관점의 전체 목록이고, 카탈로그는 고객·사용자에게 노출되는 실행 가능 목록이다 — 포트폴리오에서 카탈로그로, 카탈로그에서 요청 이행으로 흐르는 구조다. 운영 범위는 IT 서비스(계정/권한, 장비, SW)에서 비IT 서비스(시설, HR, 재무), 클라우드 자원(IaaS/PaaS)까지 걸친다.
목록 하나가 갖춰야 할 요소
카탈로그 구조와 분류 체계는 계층형 분류(도메인→서비스→항목)와 태깅을 병행해 탐색성과 재사용성을 확보하고, 대상자 기반 가시성(부서/역할/지역)에 따라 노출을 제어해 중복·스프롤을 막는다.
항목(Item) 모델은 이름, 설명, 카테고리, 폼 필드, 유효성 규칙, 가격/원가, SLA, 보안 등급을 필수 속성으로 두고, 승인 규칙, 작업 템플릿, 자동/수동 핸들러, 롤백/보상 트랜잭션을 이행 메타데이터로 정의한다.
요청·승인·이행 워크플로우는 금액·역할·데이터 민감도에 따른 조건부 승인을 동적으로 라우팅하고, 자동 이행(프로비저닝/API 호출)과 수동 작업(서비스데스크)을 혼합하며 예외 처리 분기를 둔다.
거버넌스와 수명주기는 RACI(서비스 오너, 과정 오너, 보안 담당)를 명확히 하고 버전을 관리하며, 변경 승인 정책과 사전·사후 검토(캡티브 CAB 또는 라이트웨이트 리뷰)를 운영한다. 통합·자동화는 IDaaS/IAM, CMDB, Terraform·Ansible 같은 클라우드/DevOps 툴, 재무/결재 시스템과 양방향 연계하고, APM/로그/메트릭 관측성 연계로 이행 성공률·리드타임·CSAT을 자동 수집한다.
설계에서 운영까지
비즈니스 요구사항, 기존 티켓 데이터, 표준 운영 절차(SOP)를 입력으로 받아 항목 모델링, 승인·이행 워크플로우 설계, 시스템 통합, 보안/컴플라이언스 검토를 거치면 운영 가능한 카탈로그와 측정 지표 대시보드, 개선 백로그가 나온다.
단계별로는 요구 수집·우선순위화(볼륨·리드타임·위험 기준으로 항목 후보 선정) → 항목 설계·표준화(폼/검증/승인/이행 템플릿화, 공통 컴포넌트 재사용) → 통합·보안(최소권한, 데이터 마스킹, 승인 근거 로깅, 감사 추적 활성화) → 시험·런칭·운영(샌드박스 시나리오 테스트, 카나리 공개, SLO 모니터링과 주기적 리팩터링) 순으로 진행한다.
구현 방식마다 다른 비용
| 구현 옵션 | 성능 | 확장성 | 일관성 | 안정성 | 운영 편의 |
|---|---|---|---|---|---|
| ITSM 플랫폼 기본 카탈로그 | 중상: 벤더 최적화 | 중상: 멀티 인스턴스/앱 | 높음: 템플릿/정책 내장 | 높음: 성숙한 권한/감사 | 높음: 관리 콘솔/업데이트 용이 |
| 로우코드 포털+워크플로우 | 중: 커스텀 의존 | 중상: 컴포넌트 재사용 | 중: 팀별 편차 가능 | 중: 확장 시 복잡성 증가 | 중상: 민첩, 거버넌스 보강 필요 |
| 커스텀 마이크로서비스 포털 | 상: 경량/전용화 | 상: 수평 확장 용이 | 설계 품질 의존 | 중상: SRE 성숙도 요구 | 중: 운영 자동화 투자 필요 |
실무에서는 이런 모양으로 쓰인다
신규 입사자 온보딩 번들은 계정 생성, 그룹 권한, 노트북/소프트웨어, 사내 시스템 접근을 항목 묶음으로 두고 HR 이벤트가 트리거되면 IAM·MDM·라이선스 프로비저닝을 거쳐 웰컴 패키지 알림으로 이어진다. 접근 권한 요청은 민감도·역할·금액 기준의 다단계 승인을 조건부로 걸고, SoD 충돌을 사전 검증하며 기간 한정 권한을 자동 회수한다. 클라우드 자원 셀프서비스는 표준 VPC/네트워크/태깅/보안그룹을 포함한 IaC 템플릿을 두고 비용 상한·리전 제한·자동 태그로 비용 센터에 청구하는 거버넌스를 건다.
이런 표준화가 자리 잡은 조직에서는 평균 리드타임이 3070% 단축되고 이행 성공률이 95% 이상으로 오르며, 티켓 볼륨의 2050%가 셀프서비스로 전환되는 것으로 보고된다. 서비스 품질의 일관성과 내부 고객 경험, 컴플라이언스·감사 대응 용이성이 함께 좋아지는 것은 정성적으로도 체감되는 부분이다.
속도와 통제 사이에서
템플릿을 우선 설계해 폼·승인·이행을 표준화하면 품질 변동이 최소화된다. 항목별 SLO(리드타임/성공률)와 에러 버짓을 추적하는 관찰 가능성도 내장해야 하고, 중복 항목을 통합하고 사용량 기준으로 아카이브하며 주기적으로 카탈로그를 리뷰하는 스프롤 방지도 필요하다. 다만 승인을 간소화하면 민첩성은 오르지만 리스크도 함께 오른다 — 민감도 기준으로 차등 적용해야 한다. 범용 항목은 유지보수가 쉽지만 전문화 항목만큼 만족도가 높지는 않고, 전문화 항목은 관리 비용이 늘어난다. 완전 자동화는 초기 투자·복잡도가 오르는 대신 장기 운영비를 줄여준다.
카탈로그 항목 하나를 등록해보면
전제는 사내 ITSM/포털이 REST 기반 카탈로그 CRUD와 멱등성 키를 지원한다는 것이다. 스키마의 필수 속성은 id, name, category, form.fields[], approvals.rules[], fulfillment.steps[], sla, cost이고, 보안 속성으로 dataSensitivity, accessPolicy, audit.enabled를 둔다.
{
"id": "svc.access.github",
"name": "GitHub 조직 접근 권한 요청",
"category": "Access",
"visibility": ["Engineering", "Data"],
"form": {
"fields": [
{
"key": "repo",
"type": "text",
"required": true,
"validation": "^[a-z0-9_.-]+$"
},
{
"key": "accessLevel",
"type": "select",
"options": ["read", "write"],
"required": true
},
{ "key": "justification", "type": "textarea", "required": true }
]
},
"approvals": {
"rules": [
{
"when": { "accessLevel": "write" },
"approvers": ["teamLead", "repoOwner"]
},
{ "when": { "accessLevel": "read" }, "approvers": ["teamLead"] }
]
},
"fulfillment": {
"steps": [
{
"type": "webhook",
"endpoint": "https://idm.example/api/grant",
"method": "POST",
"retry": { "max": 5, "backoff": "exp" }
},
{ "type": "auditLog", "target": "siem" }
],
"rollback": [
{
"type": "webhook",
"endpoint": "https://idm.example/api/revoke",
"method": "POST"
}
]
},
"sla": { "targetHours": 4, "businessHours": true },
"cost": { "chargeback": 0 },
"security": { "dataSensitivity": "low", "audit": { "enabled": true } }
}
등록은 다음과 같은 요청으로 이뤄진다.
curl -X POST https://itsm.example/api/catalog/items \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
--data @github_access.json
폼은 서버측 검증이 필수이고, 승인 근거와 이행 로그는 감사 추적으로 보관해야 한다. 실패하면 보상 트랜잭션을 호출하고, 재시도는 지수 백오프와 멱등성을 준수한다. 서비스 카탈로그는 서비스 전달의 표준화·자동화·가시화를 동시에 달성하는 체계다. 템플릿 기반 모델링과 조건부 승인, 트랜잭션 안전한 자동화를 결합해 리드타임을 단축하고 품질을 일관되게 유지하되, ITSM 기본 기능을 우선 활용하고 고도 자동화가 필요한 영역만 API/IaC 연계로 점진적으로 확장하는 편이 안전하다.