76. 서비스 데스크 (Service Desk) 및 인시던트(Incident) 관리 체계 감리

⚠️ 이 문서는 시스템 오픈 직후 쏟아지는 수백 통의 "비밀번호 까먹었어요", "결제가 튕겨요" 같은 고객/직원의 장애 전화(인시던트)를 개발팀이 직접 중구난방으로 받다가 멘탈이 붕괴되는 것을 막기 위해, 사용자와 IT 조직 사이의 유일한 단일 창구(SPOC) 역할을 하는 '서비스 데스크'를 구축하고, 장애를 접수부터 100% 완전 해결까지 추적 통제하는 ITIL(IT Infrastructure Library) 기반의 관리 프로세스가 시스템적으로 도입되었는지 평가하는 운영 이관 감리 지침을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: "개발 다 끝났으니 알아서 쓰세요"라고 도망가는 SI 업체의 관행을 막는 족쇄다. 시스템 장애가 터졌을 때 고객이 전화를 걸 단일 콜센터(접수처)가 있고, 그 장애가 1선, 2선, 3선 개발자에게 어떻게 흘러가서 조치되는지(티켓팅 시스템) 프로세스 뼈대를 갖췄는지 점검한다.
  2. 가치: 장애 처리가 개인의 카카오톡이나 이메일, 머릿속 기억에 의존하는 끔찍한 구멍가게식 운영을 종식한다. 모든 장애(Incident)를 '티켓(Ticket)'이라는 전자 문서로 강제 박제하여, SLA(장애 복구 시간 약속)를 위반하는 부서가 어디인지 투명하게 감시하는 체계를 만든다.
  3. 기술 체계: 전화/이메일을 일원화하는 단일 접점(SPOC), 장애의 긴급도에 따라 처리 우선순위를 매기는 우선순위 매트릭스, 그리고 Jira나 ServiceNow 같은 ITSM(IT 서비스 관리) 솔루션의 도입 여부가 감리의 핵심 점검 대상이다.

Ⅰ. 구멍가게 운영의 재앙과 단일 접점(SPOC)의 필요성

장애가 났는데 사장님이 개발자에게 직접 전화를 걸면 회사는 망한다.

  1. 사일로(Silo)화된 장애 접수의 비극:
    • 시스템 오픈 첫날 결제 버튼이 뻗었다. 영업팀 대리는 A 개발자에게 메신저를 보내고, 재무팀장은 B DB 관리자에게 전화를 걸어 소리친다.
    • 똑같은 1개의 장애를 2명이 동시에 고치느라 코드가 꼬이거나, 반대로 "남이 하겠지"라며 아무도 안 고쳐서 3일 방치되는 파국이 벌어진다. 기록(Log)도 없으니 다음 주에 또 같은 장애가 터진다.
  2. 서비스 데스크 (Service Desk)의 설립 원칙:
    • ITIL(글로벌 IT 운영 표준)의 0순위 원칙이다. 고객, 직원의 모든 IT 관련 불만, 장애, 문의는 **무조건 '서비스 데스크'라는 하나의 창구(Single Point of Contact, SPOC)**로만 100% 욱여넣어야 한다.
    • 감리인은 시스템 화면에 [장애 신고 게시판]이나 전용 [콜센터 번호]가 명확히 명시되어 있고, 개발팀으로 가는 직통 전화가 물리적/제도적으로 차단(보호)되어 있는지 매뉴얼을 점검한다.

📢 섹션 요약 비유: 식당에서 손님(고객) 10명이 김치찌개가 짜다며 주방에 쳐들어가서 주방장(개발자)의 멱살을 잡고 각자 소리를 지르면 요리(개발)가 마비됩니다. 홀 매니저(서비스 데스크) 한 명을 입구에 세워두고, 모든 불만은 매니저가 메모장(티켓)에 1번부터 10번까지 번호표를 매겨서 주방 창구에 꽂아주는 질서 정연한 단일 접수 체계가 SPOC입니다.

Ⅱ. 인시던트(Incident) 관리 프로세스의 해부학

티켓이 굴러가는 컨베이어 벨트를 깐깐하게 검사한다.

  1. 1선, 2선, 3선의 에스컬레이션 (Escalation):
    • 감리인은 장애 처리 매뉴얼이 수직적으로 잘 쪼개져 있는지 확인한다.
    • 1선(Level 1, 상담원): "비번 까먹었어요" 같은 단순 헛발질(전체 문의의 70%)을 매뉴얼(KEDB)을 보고 3분 만에 차단한다.
    • 2선(Level 2, 운영 엔지니어): DB 재시작, 권한 부여 등 스크립트로 해결 가능한 인프라성 장애를 고친다.
    • 3선(Level 3, 핵심 개발자/제조사): 로직에 빵꾸가 나서 소스코드를 뜯어고쳐야 하는 치명적 결함(Defect)을 해결한다. 1선에서 3선으로 티켓이 이관(Escalation)되는 조건이 명시되어 있어야 한다.
  2. 우선순위 (Priority) 매트릭스 점검:
    • 100개의 장애가 쏟아졌을 때 무엇부터 고칠 것인가?
    • 감리인은 [영향도(Impact: 전 직원 마비 vs 1명 마비)] $\times$ [긴급도(Urgency: 즉시 처리 요망 vs 며칠 여유)]를 곱하여 VVIP 장애와 일반 장애를 기계적으로 분류하는 매트릭스 표가 시스템(Jira 등)에 자동 탑재되어 있는지 검사한다.
  3. SLA (서비스 수준 협약) 시간 통제:
    • 1등급 장애는 2시간 내 해결, 3등급 장애는 24시간 내 해결이라는 SLA(Service Level Agreement) 타이머가 티켓에 찍혀 돌아가고 있는지, 시간을 어기면 담당 부장에게 알람(SMS)이 울리는지 깐깐하게 시스템을 시연해 보라고 요구한다.

📢 섹션 요약 비유: 응급실(인시던트 관리)에 환자가 몰려오면, 도착한 순서대로 의사를 만나게 하는 건 미친 짓입니다. 접수처 간호사(서비스 데스크)가 찰과상 환자(1선)는 반창고만 발라서 즉시 집에 보내고, 피를 철철 흘리는 환자(영향도/긴급도 최고)는 3시간 대기 줄을 무시하고 즉시 수술실 펠로우 의사(3선 개발자)에게 밀어 넣어 심정지 골든타임(SLA 2시간)을 칼같이 지켜내는 냉혹한 생명(시스템) 살리기 프로세스입니다.

Ⅲ. 감리 필수 산출물: ITSM 도구와 KEDB

사람의 기억력이 아닌, 영구적인 시스템에 기록을 남겨라.

  1. ITSM (IT Service Management) 시스템 구축 여부:
    • 이 모든 거대한 프로세스를 엑셀이나 이메일로 관리한다는 것은 사기다.
    • 감리인은 Atlassian Jira Service Management, ServiceNow, 또는 자체 구축한 ITSM 포털 화면을 띄우게 하고, "사용자가 티켓을 등록 $\rightarrow$ 담당자 배정 $\rightarrow$ 조치 중 $\rightarrow$ 완료 후 사용자 승인(Closed)"까지 넘어가는 상태(Status) 변화의 흐름을 눈으로 직접 테스트(Audit)한다.
  2. KEDB (알려진 에러 DB, Known Error Database) 축적:
    • 시스템 오픈 직전, 개발사가 빈손으로 떠나지 못하게 하는 감리의 필살기다.
    • "개발하면서 수백 번 터졌던 에러들, 그리고 오픈 후 예상되는 뻔한 에러들의 조치 방법 100가지를 FAQ 형태의 지식(Knowledge) 데이터베이스로 꽉 채워놓고 가라"고 요구한다.
    • 이 KEDB 지식창고가 든든하게 구축되어 있어야만 1선 콜센터 직원(비전문가)이 KEDB를 검색해서 개발자에게 가는 전화를 70% 이상 방어(First Call Resolution)해 낼 수 있기 때문이다.

📢 섹션 요약 비유: 식당 주방장이 떠날 때(개발사 철수) 단순히 음식 레시피만 넘겨주는 게 아닙니다. 감리관은 주방장에게 "손님이 찌개가 짜다고 컴플레인(인시던트)하면, 물을 한 컵 더 넣고 대파를 썰어 넣어라(해결책)"라는 진상 손님 대처법을 적은 100쪽짜리 비법 노트(KEDB)를 계산대 알바생(서비스 데스크) 손에 완벽히 쥐여주었는지까지 철저히 확인하고 나서야 퇴사를 허락합니다.