💡 핵심 인사이트
문제 관리(Problem Management)는 인시던트 관리팀이 임시방편(재부팅 등)으로 대충 살려놓고 떠난 장애의 '보이지 않는 진짜 뿌리(Root Cause)'를 현미경으로 찾아내어 소스코드를 고치고, 다시는 똑같은 장애가 재발하지 않도록 영구적인 해결책을 박아버리는 셜록 홈즈 같은 프로세스입니다.

Ⅰ. 인시던트(Incident)와 문제(Problem)의 차이

이 두 가지를 구분하는 것이 ITIL의 가장 뼈대입니다.

• 인시던트 (증상): "내 PC 화면이 갑자기 파란색으로 변하며 죽어버렸다(블루스크린)." ➔ 조치: 재부팅했더니 다시 켜짐 (해결됨).
• 문제 (근본 원인): 재부팅해서 당장 PC는 켜졌지만, 내일 또 꺼질지 모릅니다. "대체 왜 어제 오후 3시에 회사의 PC 100대가 동시에 파란 화면을 띄우며 죽었는가?"라는 보이지 않는 숨은 원인, 그것이 바로 **문제(Problem)**입니다.

즉, 하나의 거대한 '문제(원인)' 밑에는 수십수백 건의 '인시던트(증상 신고 전화)'가 열매처럼 매달려 있습니다. 문제 관리는 나무의 열매를 자르는 게 아니라 독을 품은 뿌리를 뽑아버리는 작업입니다.

Ⅱ. 문제 관리 프로세스의 핵심 목표

1. 근본 원인 분석 (RCA, Root Cause Analysis)

문제 관리팀(Tier 2~3의 고급 엔지니어들)은 불난 불을 끄는 조급함에서 벗어나, 여유를 가지고 서버의 깊은 로그(Log) 파일, 덤프 덤프 파일을 뜯어보며 왜 서버가 죽었는지 추리합니다.

• 추리 기법: 5 Why 기법 ("왜 죽었지? 메모리가 차서. 왜 찼지? A 코드가 메모리를 안 놔줘서..."), 피시본(Fishbone) 다이어그램 등을 활용합니다.

2. 영구적 해결책 (Permanent Solution) 적용

원인이 'A 소스코드의 메모리 누수 버그'라는 것을 알아냈다면, 개발팀에 요청하여 소스코드를 뜯어고치는 패치(Patch)를 배포하게 만듭니다. 이제 이 시스템은 완치되어, 내일부터는 블루스크린 인시던트 접수 전화가 0건으로 사라집니다. (도움데스크 업무량 극적 감소)

3. 알려진 오류 (KEDB, Known Error Database) 등록

수십억짜리 오라클 DB 자체의 버그라서 우리 회사 직원이 코드를 못 고칠 때는 어떻게 할까요? "이건 오라클 11g 버전의 어쩔 수 없는 버그다. 이 에러 창이 뜨면 캐시를 지우는 우회책을 써라."라고 명확히 증명해 낸 지식을 **알려진 오류 데이터베이스(KEDB)**에 기록해 둡니다. 나중에 1차 헬프데스크 직원은 똑같은 에러 전화를 받으면 당황하지 않고 이 KEDB 매뉴얼을 보고 10초 만에 우회책을 알려줄 수 있습니다.

Ⅲ. 사후 관리 (사후 장애 분석, Post-Mortem)

치명적인 장애가 복구된 후, 며칠 뒤 IT 팀장과 엔지니어들이 모여 장애 보고서(Post-mortem)를 씁니다.

• 누구를 혼내려는 자리(Blame)가 아니라, 우리가 근본 원인을 잘 찾았는지, 재발 방지 패치는 잘 적용됐는지, 다음엔 더 빨리 원인을 찾으려면 모니터링 툴에 어떤 알람을 추가해야 할지를 학습하는 가장 중요한 자양분입니다.

📢 섹션 요약 비유: 인시던트 관리가 **'응급실에서 당장 해열제를 먹여 열을 떨어뜨리는 것'**이라면, 문제 관리는 환자를 입원시킨 뒤 정밀 MRI와 혈액 검사를 돌려 체내의 '맹장염(근본 원인)'을 찾아내고, 수술실에서 맹장을 영구적으로 잘라내어 다시는 배가 아플 일이 없게 만드는 완치 수술 과정입니다.