핵심 인사이트 (3줄 요약)
- 본질: IT 서비스 카탈로그 (IT Service Catalog)는 사용자가 요청할 수 있는 현재 제공 가능한 서비스만 비즈니스 언어로 정리한 공식 메뉴판이다.
- 가치: 서비스 요청, 승인, 제공 시간을 표준화하여 IT 문의를 줄이고, 셀프서비스와 자동 프로비저닝의 출발점을 만든다.
- 판단 포인트: 카탈로그의 성공 여부는 목록의 양이 아니라 비즈니스 뷰와 기술 뷰를 정확히 매핑하고, 실제 이행 프로세스까지 연결했는가에 달려 있다.
Ⅰ. 개요 및 필요성
IT 서비스 카탈로그는 IT 조직이 현재 제공 중이거나 승인된 서비스를 표준화된 형태로 게시하고, 사용자가 그 서비스를 일관된 방식으로 요청할 수 있게 만드는 관리 체계다. 단순 문서 모음이 아니라, "무엇을 얼마나 빨리 어떤 조건으로 제공하는가"를 약속하는 서비스 접점이라는 점이 중요하다.
이 체계가 필요한 이유는 전통적인 IT 지원이 사람 의존적이기 때문이다. 같은 계정 발급 요청도 누구에게 보내야 하는지 부서마다 달랐고, PC 지급·권한 신청·가상서버 할당 같은 업무가 이메일과 전화에 흩어져 처리되었다. 이런 구조에서는 사용자 경험이 나쁘고, IT 부서도 요청량, 원가, 병목 구간을 체계적으로 파악하기 어렵다.
또한 카탈로그가 없으면 현업은 느린 내부 프로세스를 우회해 섀도우 IT (Shadow IT)로 이동하기 쉽다. 따라서 서비스 카탈로그는 편의성과 통제력을 동시에 회복하는 가장 실용적인 IT 서비스 관리 장치다.
- 📢 섹션 요약 비유: 서비스 카탈로그는 손님이 주방장에게 "오늘 뭐 되나요?"라고 매번 묻지 않도록, 메뉴와 가격과 조리 시간을 한 번에 보여주는 식당 메뉴판과 같다.
Ⅱ. 아키텍처 및 핵심 원리
잘 설계된 서비스 카탈로그는 보통 비즈니스 뷰, 기술 뷰, 요청/승인 워크플로, 이행 자동화로 구성된다. 사용자는 비즈니스 언어로 요청하지만, 내부에서는 그 요청이 구성 항목 (CI, Configuration Item), 스크립트, 승인 정책으로 번역되어야 한다.
| 구성 층 | 역할 | 사용자에게 보이는 내용 | 내부 설계 포인트 |
|---|---|---|---|
| 비즈니스 카탈로그 | 서비스 메뉴 제시 | 서비스명, 비용, SLA, 신청 대상 | 기술 용어 제거, 번들링 설계 |
| 요청 모델 | 입력 양식과 검증 | 필요 용량, 사용 기간, 승인자 | 필수값 검증, 정책 조건식 |
| 승인 워크플로 | 조직 통제 | 팀장 승인, 예산 승인, 보안 승인 | 자동 라우팅, 예외 처리 |
| 기술 카탈로그 | 백엔드 변환 | 사용자에게는 대부분 비노출 | CI 매핑, 스크립트 파라미터화 |
| 이행 자동화 | 실제 제공 | 완료 알림, 접근 정보 | IaC, 계정 생성, CMDB 반영 |
아래 그림은 사용자의 클릭이 실제 서비스 제공으로 이어지는 흐름을 보여준다.
┌──────────────────────────────────────────────────────────────────────┐
│ Service catalog fulfillment flow │
├──────────────────────────────────────────────────────────────────────┤
│ User portal │
│ -> choose service item │
│ -> submit request form │
│ │
│ Workflow engine │
│ -> manager / budget / security approval │
│ │
│ Technical mapping │
│ -> VM template / account role / network policy │
│ │
│ Automation │
│ -> IaC run / account creation / CMDB update │
│ │
│ Output │
│ -> notify user / start SLA tracking / chargeback │
└──────────────────────────────────────────────────────────────────────┘
이 그림의 핵심은 카탈로그가 "정적 설명서"가 아니라 요청 이행의 시작점이라는 사실이다. 비즈니스 카탈로그와 기술 카탈로그 간의 매핑이 없다면 포털은 예쁜 접수 화면에 그친다. 반대로 이 매핑이 잘 되어 있으면 "신입사원 온보딩" 같은 하나의 서비스 항목이 계정 생성, 권한 매핑, 장비 지급이라는 여러 기술 작업으로 자동 분해된다.
여기서 서비스 수준 협약 (SLA, Service Level Agreement)과 구성 관리 데이터베이스 (CMDB, Configuration Management Database)가 함께 연결되어야 운영 품질이 유지된다. SLA는 약속 시간을, CMDB는 서비스와 인프라의 관계를 잡아 주는 뼈대다.
- 📢 섹션 요약 비유: 앞면엔 손님용 메뉴가 있고, 뒷면엔 주방용 레시피와 조리 순서가 숨어 있어서 주문 버튼 하나로 주방 전체가 자동으로 움직이는 키오스크 식당과 같다.
Ⅲ. 비교 및 연결
서비스 카탈로그는 서비스 포트폴리오 (Service Portfolio)나 CMDB와 자주 혼동되지만 역할이 다르다. 포트폴리오는 투자 관점의 전체 서비스 집합이고, 카탈로그는 현재 제공 가능한 서비스의 소비 창구이며, CMDB는 그 서비스를 지탱하는 기술 구성요소 데이터다.
| 항목 | 서비스 포트폴리오 | 서비스 카탈로그 | CMDB |
|---|---|---|---|
| 관리 범위 | 파이프라인·운영·폐기 서비스 전체 | 현재 제공 가능한 활성 서비스 | 서버·앱·네트워크 등 구성 항목 |
| 핵심 질문 | 어디에 투자할 것인가 | 사용자가 무엇을 요청할 수 있는가 | 무엇이 무엇에 의존하는가 |
| 주요 사용자 | CIO, 서비스 기획자 | 현업 사용자, 헬프데스크 | 운영자, 아키텍트 |
| 대표 지표 | ROI, 전략 적합도 | 요청 리드타임, SLA 준수율 | 정확도, 변경 추적성 |
또한 성숙도 측면에서 카탈로그는 보통 세 단계로 진화한다. 처음에는 PDF나 엑셀 목록 수준의 정적 카탈로그, 다음은 티켓 접수 중심 포털, 마지막은 승인·프로비저닝·과금까지 이어지는 실행형 카탈로그다. 실무에서 가치가 커지는 지점은 세 번째 단계다.
이 주제는 ITIL (Information Technology Infrastructure Library) 서비스 관리와 직접 연결된다. ITIL이 서비스 중심 운영 철학을 제공한다면, 서비스 카탈로그는 그 철학을 사용자가 체감하는 실제 화면으로 구현한 결과물이다.
- 📢 섹션 요약 비유: 서비스 포트폴리오가 회사 전체의 사업계획서라면, 서비스 카탈로그는 오늘 손님에게 판매하는 메뉴판이고, CMDB는 주방 창고의 재료와 조리도구 목록이다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 가장 강력한 카탈로그 패턴은 번들 서비스다. 예를 들어 "신입사원 온보딩 패키지" 하나를 클릭하면 계정 생성, 권한 부여, 노트북 지급, 협업툴 초대가 동시에 생성되도록 설계할 수 있다. 이렇게 해야 사용자는 서비스를 비즈니스 결과물로 인식하고, IT는 반복 업무를 표준화할 수 있다.
설계 체크리스트
- 서비스명이 기술 용어가 아니라 비즈니스 목적 중심으로 작성되었는가?
- 요청 항목마다 비용, 제공 시간, 지원 범위가 명확한가?
- 승인 규칙이 조직도와 예산 규칙에 맞게 자동 라우팅되는가?
- 기술 카탈로그가 CMDB, 계정 시스템, IaC와 연결되는가?
- 사용률이 낮은 항목을 주기적으로 폐기하거나 통합하는가?
대표 안티패턴
- 카탈로그에 기술자만 이해하는 용어를 그대로 노출하는 경우
- 접수만 표준화하고 실제 이행은 이메일과 수작업에 남겨 둔 경우
- 서비스가 이미 폐기되었는데 카탈로그만 남아 신뢰를 무너뜨리는 경우
- 승인 단계가 과도하게 많아 포털을 만들고도 리드타임이 줄지 않는 경우
기술사 답안에서는 서비스 카탈로그를 단순 목록이 아니라 표준화, 셀프서비스, 거버넌스, 자동화의 교차점으로 설명하면 좋다. 특히 섀도우 IT를 줄이는 수단이라는 점을 함께 언급하면 현업 관점이 살아난다.
- 📢 섹션 요약 비유: 카탈로그 설계는 손님에게 레시피 재료명을 나열하는 일이 아니라, "아이스 아메리카노" 한 번 주문하면 뒤에서 얼음·원두·컵·결제가 한꺼번에 맞물리게 만드는 일과 같다.
Ⅴ. 기대효과 및 결론
서비스 카탈로그가 자리 잡으면 사용자 입장에서는 요청 경로가 단순해지고, IT 조직 입장에서는 반복 요청의 변동성과 병목이 보인다. 요청 리드타임 단축, SLA 관리 용이성, 수요 데이터 축적, 서비스 원가 가시화가 함께 따라온다. 특히 셀프서비스와 자동화가 붙으면 단순 운영 업무 비중을 크게 줄일 수 있다.
다만 카탈로그는 한 번 만들고 끝나는 문서가 아니다. 서비스가 바뀌면 항목도 바뀌어야 하며, 현업 언어와 내부 기술 구조 사이의 매핑도 계속 유지되어야 한다. 업데이트가 멈춘 카탈로그는 오히려 신뢰를 해치는 오래된 메뉴판이 된다.
앞으로는 대화형 인터페이스와 인공지능이 카탈로그 탐색 방식을 바꿀 가능성이 크다. 그러나 형태가 바뀌어도 본질은 같다. 현재 제공 가능한 서비스를 명확히 정의하고, 요청에서 제공까지의 흐름을 표준화한다는 점이 카탈로그의 핵심이다.
- 📢 섹션 요약 비유: 좋은 카탈로그는 보기만 좋은 안내 책자가 아니라, 손님이 주문하는 순간 주방과 계산대와 배달 시스템이 동시에 움직이게 만드는 진짜 영업 시스템과 같다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| ITIL (Information Technology Infrastructure Library) | 서비스 관리 프랙티스의 상위 기준 |
| 서비스 포트폴리오 (Service Portfolio) | 카탈로그를 포함하는 상위 투자·생명주기 관리 |
| SLA (Service Level Agreement) | 서비스 제공 시간과 품질 약속 |
| CMDB (Configuration Management Database) | 서비스와 기술 자산의 관계 데이터 |
| 셀프서비스 포털 (Self-Service Portal) | 사용자의 실제 요청 접점 |
| IaC (Infrastructure as Code) | 요청 결과를 자동 제공으로 전환하는 실행 수단 |
📈 관련 키워드 및 발전 흐름도
Help desk request by email
│
▼
Static service list
│
▼
Portal-based request standardization
│
▼
Approval workflow + CMDB mapping
│
▼
Self-service and zero-touch fulfillment
이 흐름은 사람 의존형 요청 처리에서, 서비스 중심·자동화 중심 운영으로 발전하는 단계를 요약한다.
👶 어린이를 위한 3줄 비유 설명
- 서비스 카탈로그는 회사 컴퓨터 일을 모아 둔 메뉴판이에요.
- 필요한 걸 고르면 누구에게 부탁해야 하는지 헤매지 않아도 돼요.
- 좋은 메뉴판은 주문만 받는 게 아니라, 뒤에서 바로 준비까지 시작하게 해 줘요.