53. 문제 관리와 근본 원인 분석 (Problem Management RCA)

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

1. 본질: 문제 관리 (Problem Management)는 반복 장애의 근본 원인을 찾아 재발을 막는 ITSM (IT Service Management) 활동이다.
2. 가치: RCA (Root Cause Analysis)는 임시 복구가 아닌 진짜 원인을 찾아 KEDB (Known Error Database)에 축적한다.
3. 판단 포인트: Incident (장애) 복구와 Problem (문제) 제거를 구분해야 운영과 개선이 분리되지 않는다.

Ⅰ. 개요 및 필요성

장애를 빠르게 복구하는 것과 장애가 다시 안 나게 만드는 것은 다른 일이다. 문제 관리는 후자에 집중한다. 같은 장애가 반복되면 서비스 신뢰가 무너지고 운영 비용도 커진다.

그래서 문제 관리는 현상 대응을 넘어, 재발 방지 체계를 만드는 활동이다.

• 📢 섹션 요약 비유: 문제 관리는 넘어졌을 때 상처를 닦는 것과, 왜 자꾸 넘어지는지 바닥을 고치는 것을 구분하는 일이다.

Ⅱ. 아키텍처 및 핵심 원리

문제 관리의 흐름은 장애 접수에서 시작해 우회책을 찾고, 원인을 분석한 뒤, 알려진 오류를 기록하고, 영구 수정으로 이어진다.

Incident → Workaround → Problem Record → RCA → Known Error → Permanent Fix

RCA에서는 5 Whys (5 왜), Fishbone Diagram (어골도), Pareto Analysis (파레토 분석)를 자주 쓴다. 핵심은 증상이 아니라 원인을 끝까지 파고드는 것이다.

• 📢 섹션 요약 비유: 문제 관리는 열이 난 아이에게 해열제만 주지 말고, 왜 열이 나는지 병원을 찾는 일과 같다.

Ⅲ. 비교 및 연결

문제 관리는 Incident Management (장애 관리), Change Management (변경 관리)와 연결된다. 장애 관리는 빨리 복구하는 쪽이고, 문제 관리는 같은 장애가 반복되지 않게 하는 쪽이다.

Problem Management는 KEDB를 통해 해결책과 우회책을 축적한다. 그래서 운영팀이 다음번 장애에서 더 빨리 대응할 수 있다.

• 📢 섹션 요약 비유: 장애 관리는 소방, 문제 관리는 방화 원인 조사다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 반복 장애, 큰 영향도, 보안/규제 이슈를 우선 분석한다. RCA가 끝나면 임시 우회책과 영구 수정이 분리되어야 한다.

체크리스트

1. 반복되는 Incident가 Problem으로 승격되는가?
2. RCA 결과가 KEDB에 축적되는가?
3. 임시 우회책과 영구 수정이 구분되는가?
4. 변경 후 재발 방지 검증이 있는가?

안티패턴

• 증상만 적고 원인을 적지 않는 경우
• 장애 복구와 원인 제거를 같은 회의에서 섞는 경우
• KEDB가 검색되지 않아 지식이 쌓이지 않는 경우

기술사 관점에서는 문제 관리가 운영 품질을 높이는 지속 개선 메커니즘이라는 점을 강조해야 한다. 단순 장애 대응과는 목표가 다르다.

• 📢 섹션 요약 비유: 문제 관리는 의사 진료 기록처럼, 같은 병이 또 생기지 않도록 진짜 병명을 적는 일이다.

Ⅴ. 기대효과 및 결론

문제 관리는 반복 장애를 줄이고, 운영 지식을 축적하며, 서비스 안정성을 높인다. 장애를 고치는 조직에서 장애를 줄이는 조직으로 바꾸는 힘이다.

정리하면, RCA는 책임 추궁이 아니라 학습과 재발 방지를 위한 분석이다.

• 📢 섹션 요약 비유: 문제 관리는 "왜 깨졌는지"를 적는 수리공의 노트다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

장애 발생
    │
    ▼
즉시 복구
    │
    ▼
문제 등록
    │
    ▼
RCA / KEDB
    │
    ▼
영구 수정 / 재발 방지

이 흐름은 운영 복구에서 지속 개선으로 넘어가는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

1. 문제 관리는 자꾸 고장 나는 장난감을 왜 고장 나는지 조사하는 일이에요.
2. 임시로 붙여 놓는 것만으로는 또 떨어질 수 있어요.
3. 진짜 원인을 고치면 다음엔 덜 고장 나요.