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

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

그런데 정상화만 반복하면, 같은 장애가 계속 돌아옵니다. 증상만 눌렀기 때문입니다. 문제(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에는 "임시조치"와 함께 "영구 해결 예정"이 같이 적혀 있어야 합니다.

문제 관리가 교과서대로 굴러가려면 한 가지 전제가 필요합니다 — 근본 원인을 찾으면 고칠 수 있다는 전제. 그런데 한국 SI·SM 현장에서는 이 전제가 계약 구조에 걸려 자주 무너집니다.

• 문제관리에 배정된 공수(MM)가 없습니다: 운영 계약은 보통 인시던트 대응·정기 점검 기준으로 산정됩니다. 근본 원인을 파고 코드·설정을 고치는 일은 계약서 어디에도 공수가 없어, "급한 티켓부터"라는 말에 항상 밀립니다. Problem 티켓이 6개월째 열려 있는 진짜 이유가 게으름이 아니라 그 일을 할 시간이 계약에 존재하지 않기 때문인 경우가 많습니다.
• 근본 수정이 '유상 변경' 논쟁이 됩니다: 원인이 코드 결함이면 수정은 개발 작업입니다. 구축을 했던 개발사는 "검수 끝난 시스템, 수정은 유상"이라 하고, 발주사는 "운영사가 SLA로 책임지라" 하고, 운영사는 "우리가 만든 코드가 아니다"라고 합니다. 하자보수 기간이 지났다면 이 삼각 공방은 몇 달을 갑니다 — 그동안 Known Error는 KEDB에서 늙어갑니다.
• 문제 등록 자체가 정치적 부담이 됩니다: Problem 티켓을 공식화하는 것은 발주사 앞에서 "우리 운영 범위에 구조적 결함이 있다"를 인정하는 일입니다. 협력사 평가에 불리할 것을 우려해, 반복 장애를 문제로 승격하지 않고 인시던트로만 조용히 닫는 유인이 생깁니다.
• 형식화 신호: ① KEDB 등록 건수는 느는데 '영구 해결 완료' 전환율이 몇 분기째 0%에 가깝다 ② 재발방지대책서의 대책이 전부 '담당자 교육 강화·모니터링 강화·주의 철저' 류(사람 대책)이고 설정·코드·아키텍처(시스템 대책)가 없다 ③ 같은 증상의 인시던트가 반복돼도 Problem 승격이 일어나지 않는다.
• 처방: (1) 운영 계약 갱신 시 문제관리 공수를 운영 MM의 일정 비율로 명시합니다 — "개선 활동 월 X MM"이 한 줄 있으면 우선순위 싸움의 근거가 됩니다. (2) 재발방지대책서 양식에 시스템 대책 최소 1건을 필수 항목으로 박습니다 — 사람 대책만 적힌 대책서는 반려. (3) 원인이 타사 산출물에 있으면 운영사-개발사 양자 공방으로 두지 말고 발주사 주관 협의체로 올립니다 — 비용과 책임의 판정은 발주사만 할 수 있습니다.

문제관리의 성숙도는 RCA 기법의 세련됨이 아니라, "찾은 원인을 고칠 예산·공수·권한이 조직 어디에 있는가"라는 질문에 답이 있는가로 측정됩니다.