[ITSM] 문제 관리 — 같은 불이 다시 나지 않게

운영의 하루는 인시던트로 가득 찹니다 — "안 돼요", "느려요", "또 멈췄어요". 인시던트 관리의 목표는 단 하나, 빠른 정상화입니다. 사용자가 다시 일하게 만드는 것. 그래서 인시던트는 시간 압박 아래 움직입니다.

그런데 정상화만 반복하면, 같은 장애가 계속 돌아옵니다. 증상만 눌렀기 때문입니다. 문제(Problem) 는 "하나 이상의 인시던트를 일으키는 원인(또는 잠재적 원인)"입니다. 문제 관리의 목표는 정상화가 아니라 재발 방지, 즉 근본 원인(Root Cause) 제거입니다.

핵심은 분리입니다. 새벽에 디스크를 비우는 일(인시던트)과, 왜 디스크가 차는지 밝히는 일(문제)을 같은 티켓에 섞으면, 급한 복구에 밀려 원인 추적은 영원히 미뤄집니다. 그래서 ITSM은 인시던트 티켓과 별개로 Problem 티켓을 둡니다.

인시던트와 문제는 다대일(N:1) 입니다. 같은 근본 원인이 여러 번의 인시던트로 터져 나옵니다.

• 새벽 2시 디스크 풀 (인시던트 #1241)
• 2주 뒤 디스크 풀 (인시던트 #1318)
• 또 2주 뒤 디스크 풀 (인시던트 #1402)

이 세 인시던트는 각각 별개로 "복구 완료" 처리됐지만, 뒤에는 하나의 문제 — "결제 서버 로그 로테이션 미설정" — 가 있습니다. 문제 관리는 이 세 인시던트를 하나의 Problem 티켓으로 묶어, 근본 원인 하나를 제거함으로써 미래의 인시던트 다수를 한꺼번에 없앱니다.

그래서 문제를 찾는 출발점은 보통 인시던트 데이터의 패턴입니다. "같은 서비스·같은 증상이 반복되는가", "특정 시간대에 몰리는가", "한 건이지만 영향이 막대해 원인을 꼭 알아야 하는가". 인시던트 기록(티켓)이 쌓여 있어야 이 패턴이 보입니다 — 기록 없는 조직은 문제 관리를 시작조차 못 합니다.

문제 관리는 출발점에 따라 두 갈래입니다.

반응적(Reactive) 문제 관리 는 이미 발생한 인시던트에서 출발합니다. "이 장애가 왜 났는지 끝까지 밝혀 다시는 안 나게 하자." 위 디스크 사례가 전형입니다. 대부분의 조직이 여기서 시작합니다.

선제적(Proactive) 문제 관리 는 아직 장애로 번지지 않은 신호에서 출발합니다. 모니터링 추세, 반복되는 경미한 경고, 과거 인시던트 통계를 분석해 "이대로 두면 터질 것"을 미리 제거합니다.

선제적 문제 관리는 모니터링·관측(Observability)과 맞물립니다. "디스크가 매주 5%씩 찬다 → 8주 뒤 가득 참 → 미리 로테이션·증설"처럼, 데이터가 미래의 인시던트를 미리 보여줄 때 그것을 잠재 문제로 등록해 처리합니다. 성숙한 운영 조직일수록 반응적에서 선제적으로 무게중심이 옮겨갑니다.

두 갈래는 들어오는 입구가 다릅니다. 반응적은 인시던트가 트리거가 되어 "왜 또 반복되는가"를 캐고, 선제적은 모니터링 추세 같은 데이터가 트리거가 되어 "아직 장애는 없지만 곧 터질 곳"을 미리 찾아 제거합니다. 반응적만 하면 늘 불을 쫓게 되지만, 선제적을 더할수록 터지기 전에 막아 인시던트 발생 자체가 줄어듭니다 — 이것이 운영 성숙도의 차이입니다.

문제의 근본 원인을 찾았다고 곧바로 고칠 수 있는 건 아닙니다. 코드 수정에는 배포 일정이, 인프라 변경에는 승인과 점검창이 필요합니다. 그 사이의 공백을 메우는 것이 임시조치와 Known Error입니다.

흐름은 이렇습니다. 근본 원인이나 효과적인 임시조치를 찾는 순간, 그 문제는 Known Error 상태가 되고 KEDB에 등록됩니다. 그러면 같은 증상의 인시던트가 또 들어와도, 서비스데스크가 KEDB를 검색해 "이건 알려진 오류, 임시조치는 X" 라고 즉시 대응합니다. 원인을 매번 처음부터 파지 않으니 평균 복구시간(MTTR)이 크게 줄어듭니다.

임시조치는 '임시'라는 게 함정입니다. 임시조치가 너무 잘 들으면 근본 수정이 자꾸 뒤로 밀립니다. 그래서 Known Error는 근본 수정이 완료될 때까지 살아 있는 미해결 항목이어야 하며, KEDB에는 "임시조치"와 함께 "영구 해결 예정"이 같이 적혀 있어야 합니다.