[문제해결] IT 운영에 활용할 수 있는 문제해결 기법

IT 운영을 하다 보면 크고 작은 문제들이 끊임없이 발생하죠.
장애 대응, 성능 저하, 설정 실수, 협업 이슈까지…
이런 문제들을 보다 구조적으로 접근하고, 재발하지 않도록 개선하기 위해 다양한 문제 해결 기법을 활용할 수 있습니다.

이번 글에서는 IT 운영에 직접 적용할 수 있는 6가지 실전 문제 해결 기법을 소개해볼게요.

 

🧩 5 Whys  - "왜?"를 다섯 번 묻자

 

5 Whys는 단순해 보이지만 꽤 강력한 기법입니다.
문제가 생겼을 때 "왜 그랬을까?"를 다섯 번 정도 반복해서 겉이 아닌 본질적인 원인을 찾아가는 방식이죠.

 

🔍 예시

서버가 다운됐다

→ 왜? CPU가 100%였다

→ 왜? 특정 쿼리가 폭주했다

→ 왜? 새 배치가 동시에 돌았다

→ 왜? 크론탭 설정이 잘못됐다

→ 왜? 검토 프로세스가 없었다

 

→ 결론: 배포 전에 설정 검토 프로세스가 없었던 게 진짜 원인!

 

서버가 다운된 원인을 찾기 위해 예상되는 질문을 계속 합니다.

원인을 찾을 때 까지, 질문을 확인하는 작업을 계속 반복합니다.

 

용어만 생소할 뿐, 가장 많이 사용하는 기법이라 생각됩니다.

경험을 토대로 가장 많이 발생했던 원인들을 하나씩 짚어가는거죠.

 

---

🐟 Fishbone Diagram — 원인을 구조적으로 쪼개보기

 

피시본 다이어그램은 문제가 생겼을 때 여러 가지 원인을 범주별로 시각화해서 분석하는 도구입니다.
사람(Man), 기계(Machine), 방법(Method), 환경(Environment) 등으로 분류해서 빠짐없이 파악할 수 있어요.

 

🔍 예시

서비스 속도가 느리다 →

• 사람: 개발자의 성능 테스트 생략
• 기계: 서버 메모리 부족
• 방법: 쿼리 인덱스 없음
• 환경: 갑작스런 유입 증가

→ 이처럼 다각도로 원인을 바라볼 수 있어요.

---

🔍 Root Cause Analysis — 겉이 아닌 ‘진짜’ 원인을 찾자

RCA는 말 그대로 근본 원인을 찾는 분석 기법입니다.
보통 5 Whys나 Fishbone 같은 툴과 함께 쓰이죠. 장애가 났을 때 원인을 ‘명확하게’ 설명하려면 필수입니다.

 

🔍 예시 - 배포 후 신규 상품 등록 실패

👉 현상

 

배포 후부터 관리자 페이지에서 신규 상품 등록이 실패함

 

👉 조사 과정

• 에러 로그 확인 결과: "JSON parse error - unknown property: discountType"
• 백엔드 DTO 변경 사항이 반영됐지만, 프론트에서 아직 해당 필드를 전송 중
• Swagger 문서도 업데이트되지 않았던 상태

👉 RCA 결론

API 명세 변경 후 프론트와 동기화되지 않았고, 문서 관리 프로세스가 누락된 것이 핵심 원인

👉 조치

• Swagger 문서 자동 동기화 파이프라인 적용
• API 변경 시 프론트엔드 알림 자동화 도입
• QA 단계에 API 변경 항목 체크리스트 포함

---

🧠 SCQA 기법 — 문제를 스토리처럼 풀어내기

SCQA는 상황(Situation)–갈등(Complication)–질문(Question)–해결(Answer) 순으로 흐름을 구성하는 기법이에요.
장애 보고서나 기술 블로그 쓸 때 구조를 깔끔하게 잡아주는 데 유용합니다.

🔍 예시 - 배포 속도가 너무 느린 이유는?

🟦 Situation (상황)

우리 팀은 매일 저녁 자동화된 배포 프로세스를 통해 서비스 코드를 운영 서버에 반영하고 있다.

🟥 Complication (문제/갈등)

그런데 최근 들어 배포 시간이 15분 이상 걸리는 경우가 잦아졌고, 트래픽이 몰리는 시간대와 겹쳐서 서비스 안정성에 영향을 주고 있다.

❓ Question (질문)

왜 배포 속도가 점점 느려지는 걸까? 그리고 어떤 방식으로 이를 개선할 수 있을까?

✅ Answer (해결)

배포 로그와 서버 부하 데이터를 분석한 결과, 배포 중 정적 리소스 압축과 동기화 시간이 병목이라는 점을 확인했다.
이를 해결하기 위해 정적 리소스를 CDN으로 분리하고, 병렬 배포를 적용해 평균 배포 시간을 60% 이상 줄일 수 있었다.

 

---

 

🧪 SCAMPER — 새롭게 개선하고 싶다면

SCAMPER는 기존의 아이디어나 시스템을 다양한 관점에서 변형해보는 창의적 문제 해결 도구입니다.
7가지 질문을 통해 “이걸 새롭게 바꿔보면 어떨까?”를 끌어내줘요.

 

항목질문	예시
대체하기 (Substitute)	이걸 다른 걸로 바꿔볼 수 있을까? (ex. Bash → Ansible)
결합하기 (Combine)	다른 기능이랑 합치면? (ex. 캐시 + 모니터링)
응용하기 (Adapt)	다른 데서 쓰던 걸 가져오면? (ex. 게임 서버의 자동 복구 → 웹 서비스 적용)
수정하기 (Modify)	구조나 속성을 바꾸면? (ex. 알람 기준을 더 민감하게)
다른 용도로 사용하기 (Put to another use)	다른 용도로도 쓸 수 있을까? (ex. 헬스체크 로그 → 부하 지표)
제거하기 (Eliminate)	생략하거나 제거할 수 있을까? (ex. 수동 보고서 제거)
반대로 하기 / 재배열하기 (Reverse)	순서를 바꾸면? (ex. 배포 순서 변경)