같은 "해주세요", 두 운영자.
월요일 아침, 인사팀에서 메일이 옵니다. "이번 주 신규 입사자 4명, 계정·메일·그룹웨어·VPN 만들어 주세요."
A는 메일을 보고 그제서야 손으로 계정을 하나씩 만듭니다. 어떤 그룹에 넣어야 하는지 매번 옆자리에 묻고, VPN 권한은 깜빡해서 입사자가 첫날 접속을 못 합니다. 다음 주, 또 같은 메일이 오고, 또 같은 실수가 반복됩니다.
B는 이미 요청 카탈로그에 '신규 입사자 온보딩'이라는 항목을 만들어 뒀습니다. 인사팀은 포털에서 그 항목을 골라 이름·부서만 입력합니다. 그러면 사전 정의된 절차대로 계정·메일·기본 그룹이 자동 생성되고, 부서별 권한은 팀장 승인을 거쳐 부여되며, 입사일 하루 전까지 완료됩니다. B는 그 시간에 다른 일을 합니다.
둘의 차이는 부지런함이 아니라 '정상적이고 반복되는 요청'을 체계로 만들었느냐입니다. 이 모듈은 장애가 아닌 정상 요청 — 서비스 요청 — 을 빠르고 일관되게 처리하는 방법을 다룹니다.
- 1서비스 요청이 무엇인지, 인시던트와 어떤 기준으로 구분되는지 설명할 수 있다
- 2요청 모델·서비스 카탈로그·요청 카탈로그의 관계와 역할을 자기 말로 정의할 수 있다
- 3셀프서비스 포털과 승인 워크플로가 언제 필요한지 판단할 수 있다
- 4반복 요청을 자동화하는 접근(요청 모델 → 자동 처리)을 설계할 수 있다
- 5요청 유형별 처리 절차·승인·목표시간 표를 직접 만들어 운영 기준을 세울 수 있다
서비스 요청이란 무엇인가 — 인시던트와의 경계
'정상적인 요청'과 '비정상 중단'을 가르는 한 줄
운영의 받은편지함에는 온갖 "해주세요"가 섞여 들어옵니다. 그 모두를 같은 절차로 처리하면, 급한 장애가 단순 요청에 밀리거나, 반대로 단순 요청이 장애 대응처럼 무겁게 처리됩니다. 그래서 가장 먼저 하는 일은 종류를 가르는 것입니다.
**서비스 요청(Service Request)**은 사용자가 미리 정해진 정상적 서비스를 요청하는 것입니다. 새 계정, 권한 부여, 장비 지급, 소프트웨어 설치, 정보 제공 — 모두 "원래 제공하기로 되어 있는" 일이고, 위험이 낮으며 자주 반복됩니다. 그래서 미리 승인되고(pre-approved) 표준 절차로 신속히 처리할 수 있습니다.
**인시던트(Incident)**는 정상 서비스가 계획 없이 중단되거나 품질이 떨어진 상태입니다. "메일이 안 와요", "결제가 느려요"처럼 원래 되던 게 안 되는 비정상입니다.
| 구분 | 서비스 요청 | 인시던트 |
|---|---|---|
| 본질 | 정상적·계획된 요청 | 정상 서비스의 비정상 중단·저하 |
| 사용자 표현 | "새로 만들어/달라" | "원래 되던 게 안 된다" |
| 위험·예측성 | 낮음·예측 가능·반복 | 가변적·돌발 |
| 승인 | 미리 승인(또는 정해진 승인) | 승인 개념 없음, 즉시 대응 |
| 목표 | 약속한 시간 안에 일관되게 | 최대한 빠른 정상화 |
| 측정 지표 | 처리 리드타임·이행률 | 복구 시간(MTTR)·영향 |
표를 그림으로 보면 둘을 가르는 이유가 분명해집니다. 왜 굳이 가르는가 — 요청을 인시던트로 받으면 평범한 발급이 "장애"로 집계돼 통계와 우선순위가 왜곡되고, 반대로 인시던트를 요청으로 받으면 빨리 복구할 일이 승인 대기 줄에 묻혀 SLA를 놓칩니다. 입구에서의 한 줄 분류가 두 흐름을 모두 건강하게 지킵니다.
요청 모델 · 서비스 카탈로그 · 요청 카탈로그
서비스 요청을 체계로 만드는 세 가지 도구가 있습니다. 이름이 비슷해 헷갈리지만 역할이 다릅니다.
**요청 모델(Request Model)**은 자주 반복되는 한 종류의 요청에 대해 "어떤 단계로, 누구의 승인을 거쳐, 며칠 안에 처리하는가"를 미리 정의한 표준 절차입니다. 예: '비밀번호 초기화 모델', '신규 계정 모델'. 매번 새로 판단하지 않으니 빠르고 일관되며, 자동화의 밑그림이 됩니다.
**서비스 카탈로그(Service Catalogue)**는 조직이 제공하는 서비스 전체의 목록입니다. 사용자에게 보이는 "메뉴판"으로, 각 서비스가 무엇이고 어떤 보증(가용시간·지원범위)을 갖는지 보여줍니다.
**요청 카탈로그(Request Catalogue)**는 그 서비스 카탈로그 안에서 사용자가 실제로 신청할 수 있는 항목들의 목록입니다. '노트북 신청', '소프트웨어 설치 요청', '신규 입사자 온보딩'처럼, 클릭해서 신청서를 작성할 수 있는 단위입니다. 각 요청 카탈로그 항목 뒤에는 보통 하나의 요청 모델이 연결되어 있습니다.
| 도구 | 한 줄 정의 | 누가 보나 | 예 |
|---|---|---|---|
| 서비스 카탈로그 | 제공하는 서비스의 전체 메뉴판 | 사용자·관리자 | "메일 서비스", "VPN 서비스" |
| 요청 카탈로그 | 신청 가능한 요청 항목 목록 | 사용자(신청자) | "VPN 접속 신청", "노트북 신청" |
| 요청 모델 | 한 요청을 처리하는 표준 절차 | 운영자(처리자) | "VPN 신청 → 팀장 승인 → 권한 부여 → 안내" |
정리하면: 사용자는 요청 카탈로그에서 항목을 고르고, 그 항목은 요청 모델대로 처리되며, 그 모든 항목은 결국 서비스 카탈로그에 정의된 서비스의 일부입니다.
셀프서비스 포털과 승인 워크플로
모든 요청이 자동은 아니다 — 승인이 필요한 지점
요청 처리를 자동·셀프서비스로 만들수록 빨라지지만, 아무거나 자동으로 내주면 안 됩니다. 권한과 비용이 걸린 요청은 통제가 필요합니다. 그래서 요청을 두 갈래로 나눕니다.
- 셀프서비스로 즉시 처리 — 위험이 낮고 비용이 없는 요청. 비밀번호 초기화, FAQ 정보 제공, 메일링 리스트 가입 등. 사용자가 포털에서 직접 처리하거나 자동으로 완료됩니다.
- 승인 워크플로를 거친 뒤 처리 — 권한 상향(보안 영향)이나 장비·라이선스 지급(비용 발생)처럼 누군가 책임지고 결정해야 하는 요청. 신청 → 승인자(팀장/예산권자) 검토 → 승인 시 처리, 반려 시 사유 회신.
셀프서비스 포털은 이 두 갈래의 입구입니다. 사용자가 요청 카탈로그에서 항목을 고르면, 시스템이 그 항목의 요청 모델을 보고 "승인 필요 여부"를 판단해 자동 처리하거나 승인자에게 라우팅합니다. 핵심은 승인이 필요한 항목만 사람을 거치게 하고, 나머지는 흐르게 하는 것입니다 — 모든 요청에 사람을 붙이면 셀프서비스의 의미가 없고, 아무것도 안 붙이면 통제가 무너집니다.
그림: 요청 카탈로그 → 요청 모델 → 승인 불필요(자동) / 승인 필요(워크플로) 분기. 입구에서 인시던트와도 갈린다.
반복 요청의 자동화 — 요청 모델에서 자동 처리로
요청 모델로 절차가 명문화되면, 그 절차의 일부 또는 전부를 자동화할 수 있습니다. 자동화는 "사람을 없애는 것"이 아니라 판단이 필요 없는 단계를 사람에게서 떼어내는 것입니다.
자주 자동화되는 반복 요청:
| 요청 | 자동화할 수 있는 단계 | 사람이 남는 단계 |
|---|---|---|
| 신규 계정 생성 | 계정·메일·기본 그룹 생성 | 부서별 특수 권한 승인 |
| 권한 부여 | 승인 후 그룹 편입·반영 | 승인 자체(보안 판단) |
| 비밀번호 초기화 | 본인 확인 후 즉시 초기화 | (없음 — 완전 자동 가능) |
| 소프트웨어 설치 | 표준 SW 자동 배포 | 비표준·유료 SW 승인 |
자동화의 순서는 항상 표준화가 먼저입니다. 절차가 사람마다 다르면 자동화할 대상이 없습니다. 그래서 흐름은 늘 같습니다: 반복 요청 발견 → 요청 모델로 표준화 → 요청 카탈로그에 등록 → 승인 불필요한 단계 자동화. 이 순서를 건너뛰고 자동화부터 하면, 잘못된 절차를 빠르게 반복하는 결과만 남습니다.
직접 해보기 — 요청 운영 기준표 만들기
아래 5개 요청 유형에 대해 (1) 처리 절차를 한 줄로, (2) 승인 필요 여부를, (3) 목표 처리시간을 채워 운영 기준표를 만들어 보세요. 그다음 (4) 같은 표현이라도 인시던트로 가야 하는 경우를 한 가지씩 적어 보세요. 정답 예시는 ObserveBlock에 있습니다.
1. 비밀번호 초기화
2. 신규 입사자 계정 생성
3. 폴더 접근 권한 부여
4. 노트북 신규 지급
5. 사내 소프트웨어 설치 요청
작성 직관: 위험·비용이 없으면 자동·무승인·짧은 목표시간, 권한·비용이 걸리면 승인·여유 있는 목표시간으로 잡습니다. 목표시간은 "약속"이므로 무조건 짧게가 아니라 지킬 수 있게 정합니다.
작성: 요청유형 × 처리절차 × 승인필요 × 목표시간- 1 비밀번호 초기화 = [절차] 본인확인 후 자동 초기화 / [승인] 불필요 / [목표] 30분 이내(셀프서비스 시 즉시)
- 2 신규 입사자 계정 = [절차] 카탈로그 신청 → 계정·메일·기본그룹 자동생성, 특수권한은 팀장승인 / [승인] 부분 필요 / [목표] 입사 1일 전까지
- 3 폴더 접근 권한 = [절차] 신청 → 데이터 소유자/팀장 승인 → 그룹 편입 / [승인] 필요(보안) / [목표] 1영업일
- 4 노트북 신규 지급 = [절차] 신청 → 예산권자 승인 → 자산 등록 → 지급 / [승인] 필요(비용) / [목표] 3~5영업일
- 5 SW 설치 = [절차] 표준SW는 자동배포, 비표준·유료는 승인 후 설치 / [승인] 항목별 상이 / [목표] 표준 즉시·승인건 1영업일
- 인시던트로 가는 경우: "비밀번호가 갑자기 안 먹혀요"(요청 아님-계정 잠김 장애), "원래 되던 폴더가 안 열려요"(권한 신청 아님-접근 장애), "설치돼 있던 SW가 안 켜져요"(설치요청 아님-장애)
- 핵심 감각: 같은 단어라도 "새로 달라"면 요청, "원래 되던 게 안 된다"면 인시던트 — 입구에서 갈라야 절차가 맞게 흐른다
현장에서 자주 보는 함정
증상: 비싼 ITSM 도구를 도입하고 셀프서비스 포털을 열었습니다. 그런데 (1) 사용자는 익숙한 대로 담당자에게 직접 전화·메일을 하고, (2) 포털로 들어온 요청도 "승인 대기"에서 며칠씩 멈춰 처리가 더 느려졌습니다. 결국 "예전이 더 빨랐다"는 불만이 나옵니다.
원인: 두 가지가 겹칩니다. 첫째, 요청 카탈로그가 부실합니다. 사용자가 뭘 신청해야 할지 항목이 없거나 이름이 어려워 포털을 못 씁니다. 둘째, 승인 워크플로가 과설계됐습니다. 위험·비용이 없는 단순 요청까지 전부 승인을 걸어 둬서, 자동으로 흘러야 할 요청이 사람 손에 막힙니다. 도구만 깔고 절차(요청 모델)와 승인 기준을 설계하지 않으면 일어나는 전형적 현상입니다.
해결 방향:
- 가장 자주 오는 요청 상위 몇 개부터 요청 카탈로그 항목으로 만들고, 이름을 사용자 언어로 짓는다("AD 그룹 편입" 대신 "공유폴더 접근 신청").
- 각 항목에 승인 필요 여부를 명확히 정한다 — 위험·비용 없는 항목은 승인을 빼고 자동 처리로, 승인은 정말 필요한 항목에만.
- 들어온 요청을 일정 비율 이상 포털로 유도하고(전화·메일은 담당자가 대신 티켓 등록), 멈춘 승인은 목표시간 초과 시 에스컬레이션한다.
- 자동화는 절차가 안정된 뒤에 — 표준화되지 않은 절차를 자동화하면 잘못을 빠르게 반복할 뿐이다.
셀프서비스는 도구가 아니라 설계입니다. 좋은 카탈로그와 꼭 필요한 만큼의 승인이 있을 때만 빨라집니다.
한국 SI/SM 현장에서 서비스 요청 관리는 운영(SM) 인력의 일상 업무 대부분을 차지합니다. 발주사·원청은 "장애가 며칠에 한 번 나느냐"보다 "계정 하나 만드는 데 며칠 걸리느냐", "권한 신청이 제때 처리되느냐"로 운영 품질을 체감하는 경우가 많습니다. 실제로 SLA 협약서에는 인시던트 복구시간뿐 아니라 **요청 유형별 처리 목표시간(이행률)**이 항목으로 들어가는 일이 흔합니다.
이 자리에서 당신은 직접 계정을 만드는 사람이라기보다, **"어떤 요청을 카탈로그로 표준화하고, 무엇에 승인을 걸며, 목표시간을 며칠로 약속하고, 그 이행률을 어떻게 보고하는가"**를 설계·관리하는 사람입니다. 협력사 엔지니어가 실제 처리를 하더라도, 요청이 약속한 시간 안에 일관되게 처리되도록 절차를 잡고 지연을 통제하는 책임은 관리자에게 있습니다. 그래서 요청 유형별 처리 기준표·승인 워크플로·이행률 리포트는 운영 관리자가 매달 손에 쥐고 있어야 할 기본 산출물입니다.
관련 모듈로 더 깊이:
- 서비스 데스크 — 요청이 가장 먼저 접수·분류되는 단일 접점과 셀프서비스 포털
- 변경 관리(변경 활성화) — 표준 요청의 경계를 넘는 변경을 승인·통제하는 변경 관리 절차
다음 모듈에서는 반복되는 인시던트의 근본 원인을 파고들어 재발 자체를 막는 문제 관리(Problem Management)를 다룹니다.