문제 정의 – 진짜 문제와 가짜 문제를 구별하라

15년간 소프트웨어 개발과 시스템 아키텍처 업무를 해오며
가장 자주 마주친 장면은 이것이었습니다.

“문제를 해결하고 있었지만, 그 문제는 애초에 해결할 필요가 없는 것이었다.”

조직 안에서는 일을 만들기 위해 문제를 만들고,
그 문제를 ‘해결하는 과정’에 자원과 시간이 소비됩니다.
하지만 정작 고객은 그 문제에 아무 관심도 없습니다.

문제를 잘못 정의하면, 해결하지 않아도 될 일을 하게 된다

문제를 잘못 정의하면 다음과 같은 결과가 따라옵니다:

그 결과 우리는 실제로는 문제 해결이 아니라
“일을 위한 일”을 하고 있게 됩니다.

실제로 실무에서는 이런 사례를 자주 봅니다.

문제를 잘못 정의하면,
해결은 정확할지 몰라도 결과는 무의미할 수 있습니다.

요구분석은 단순히 “무엇을 만들어야 하나요?”를 묻는 게 아닙니다.
진짜 시작은:

“고객이 왜 불편을 느끼고, 무엇을 기대하고 있으며, 그 기대는 어디에서 비롯되었는가”를 이해하는 데 있습니다.

요구분석이 고객 중심이 아니라면,
우리는 “문제처럼 보이는 것”을 정의하고,
“고객이 중요하게 생각하지 않는 것”을 해결하는 실수를 저지르게 됩니다.

좋은 아키텍트는 설계보다 먼저 문제를 구조화합니다.
문제인식이란 단순한 오류 지적이 아니라,
해결해야 할 과제를 정의하는 일입니다.

문제를 정의한다는 것은 다음과 같은 질문에 답하는 것입니다:

단순한 불편과 실질적인 손실(매출, 고객 이탈, 신뢰 저하 등)을 구분해야 합니다.

현상만을 해결하면 또 다른 형태로 같은 문제가 반복됩니다.

내부 효율이 아닌 고객의 경험과 목표에 영향을 주는 문제인가를 판단해야 합니다.

모든 문제를 해결할 수는 없습니다. 리소스와 가치 대비 효과를 고려해 결정해야 합니다.

많은 이들이 문제를 ‘해결해야 할 대상’으로만 봅니다.
하지만 진짜 중요한 건,

“해결할 만한 가치가 있는 문제인가?”를 먼저 정의하는 일입니다.

잘 정의된 문제는 절반은 해결된 셈입니다.
반대로 잘못 정의된 문제는 아무리 훌륭한 기술로도,
결코 고객의 마음을 얻을 수 없습니다.

우리는 종종 조직의 관점에서 문제를 정의합니다.
하지만 문제정의에서 고객이 빠지면,
그 문제는 결국 조직 내부에서만 유의미한 ‘가짜 문제’가 되기 쉽습니다.

문제는 언제나 고객 안에 있고,
요구분석은 고객을 이해하는 데서 출발해야 하며,
문제정의는 고객의 언어로 표현되어야 합니다.

문제를 해결하는 것보다
문제를 잘 정의하는 것이 더 어렵고, 더 중요합니다.

태그: 설계철학