SI 프로젝트 - '문제는 분명히 있었는데,"

- 1월 09, 2026

왜 아무도 문제를 정의하지 못했을까

어느 프로젝트에서였다.
장애는 분명히 발생하고 있었고, 로그도 있었고, 지표도 있었다.
사용자는 느리다고 말했고, 운영팀은 불안해했고, 개발팀은 바빴다.

그런데 이상하게도
아무도 “무엇이 문제인가”를 정확히 말하지 못하고 있었다.

현상은 있었지만, 문제는 없었다

회의에서는 이런 말들이 오갔다.

“DB 쿼리가 느린 것 같다”
“캐시를 붙이면 해결되지 않을까”
“트래픽이 늘어서 그런 것 같다”
“일단 스케일 아웃부터 해보자”

모두 그럴듯했다.
그리고 모두 해결책처럼 들렸다.

하지만 이 말들에는 공통점이 하나 있었다.
문제를 정의하는 질문이 아니라, 해결을 가정한 질문이라는 점이다.

내가 멈춰 섰던 지점

회의를 듣다가 문득 이런 생각이 들었다.

“지금 우리는 문제를 해결하려는 게 아니라
각자 익숙한 답을 말하고 있는 게 아닐까?”

이 순간부터 이 대화는 위험해진다.
왜냐하면 문제가 정의되지 않은 상태에서의 해결은,
대부분 ‘운 좋은 추측’이 되기 때문이다.

그래서 나는 더 이상 해결 이야기를 따라가지 않았다.
대신 질문을 바꾸기로 했다.

질문을 바꾸면, 풍경이 달라진다

그날 내가 던진 질문들은 이런 것들이었다.

“이 시스템에서 ‘느리다’는 말은, 누가 언제 판단한 건가?”
“사용자가 체감한 지연과 서버 지표는 같은 문제인가?”
“이 문제를 실패라고 정의하는 기준은 무엇인가?”
“이 시스템에서 이 문제의 책임 경계는 어디까지인가?”

이 질문들은 바로 답을 만들지 않는다.
오히려 대화를 잠시 멈추게 만든다.

하지만 놀랍게도,
이 질문들이 나오자 해결책 후보들이 하나둘 사라지기 시작했다.

해결책이 줄어드는 순간

캐시 이야기는 자연스럽게 사라졌다.
스케일 아웃도 잠시 보류되었다.
DB 튜닝은 “지금 당장은 아니다”라는 결론이 나왔다.

아무 것도 해결하지 않았는데,
하지 않아도 될 선택지가 먼저 제거된 것이다.

그제서야 팀은 같은 문제를 보고 있다는 느낌을 갖기 시작했다.

이 글은 해결 방법에 대한 기록이 아니다

이 글에는

어떤 기술을 썼는지
어떤 설정을 바꿨는지
최종적으로 어떻게 해결했는지

를 일부러 적지 않았다.

이 글은 문제를 해결한 기록이 아니라,
문제를 정의하기까지의 사고 과정을 남긴 기록이다.

나는 점점 이런 확신을 갖게 되었다.

문제 해결 능력보다 중요한 것은
문제를 올바르게 정의하는 능력이라는 것을.

앞으로 이 블로그에 남길 것들

이 블로그에는

정답보다 질문을
해결보다 판단 과정을
기술보다 사고의 전환점을

기록하려고 한다.

이 글이 누군가에게
“아, 나도 지금 이 상태구나”라는 느낌을 주었다면
그걸로 충분하다.

나는 문제를 해결해주는 사람이기보다,
문제를 올바르게 정의하도록 돕는 사람이고 싶다.

#사고, #문제정의, #아키텍처, #장애분석

이 블로그 검색

Ai Creator