사용자 관점에서 문제를 정의하는 법

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

자기 제품을 만드는 일은 문제 해결 능력을 훈련하는 좋은 방법입니다. 다만 구현에서 멈추지 않아야 합니다. 출시하고, 사람에게 써 달라고 부탁하고, 왜 다시 오는지 또는 왜 돌아오지 않는지 확인해야 합니다.

저도 주니어 때 제품을 만들고 띄운 다음 어떻게든 실제 사용자를 모으는 과정을 많이 반복했습니다. 코드를 만드는 것도 훈련이었습니다. 더 불편하고 중요한 훈련은 내가 자신 있게 정의한 문제가 다른 사람에게도 자동으로 가치가 되는 것은 아니라는 사실을 확인하는 일이었습니다.

“문제 해결 능력”이라는 말에는 서로 다른 종류의 작업이 들어 있습니다. 기술 성능, 제품 수요, 수익을 하나의 점수로 합치면 안 됩니다.

트래픽은 시스템을 검증하지만 제품을 증명하지 않는다

개인 프로젝트에 수익이 없고 실제 트래픽도 적다면 문제 해결에 실패한 걸까요?

반드시 그렇지는 않습니다. 부하 대응을 연습하는 게 목표라면 부하 발생기로 트래픽을 만들 수 있습니다. 현재 아키텍처에 요청을 부어 보면 약한 지점이 나옵니다. 실제 고객이 서비스를 발견하지 못했더라도 이 실험으로 기술적인 문제 해결을 배울 수 있습니다.

수익은 다른 질문입니다. 기술 문제를 풀었다고 고객이 만족하거나, 제품의 존재를 알거나, 비용을 지불하고 싶어지는 것은 아닙니다. 개발자가 비즈니스 문제까지 해결할 수 있다면 당연히 좋습니다. 그렇다고 개발이라는 책임 자체가 사라지는 것은 아닙니다. 수익이 없다고 기술적으로 배운 내용까지 무효가 되지는 않습니다.

반대 방향도 봐야 합니다. 인위적인 트래픽은 엔드포인트가 정해진 부하를 버틴다는 사실을 확인할 수 있습니다. 사람이 가치를 얻었다는 증거는 아닙니다. 결과를 해석하기 전에 어떤 문제를 검증했는지 분리해서 적어야 합니다.

좋은 해결은 좋은 정의에서 시작한다

해결하려는 사람은 많지만 문제를 정말 잘 정의하는 사람은 손에 꼽을 만큼 적었습니다. 문제 정의가 틀려도 활동은 많이 일어납니다. 기능을 만들고 아키텍처를 바꾼 뒤 작업 완료를 선언합니다. 처음 미션이 잘못됐기 때문에 의미 있는 결과는 아무것도 나아지지 않습니다.

문제 정의는 분석입니다. 무슨 일이 벌어지고 있는지, 누가 겪는지, 어떤 결과가 바뀌어야 하는지, 실제 제약이 무엇인지 확인합니다. 정의가 정확하면 구현은 오히려 쉬워집니다. 반대로 정의가 모호하거나 잘못됐다면 뛰어난 구현으로 엉뚱한 문제를 빠르게 해결할 수 있습니다.

기술을 답으로 정하기 전에 먼저 미션의 정체를 분석하고 문제를 정확히 정의해야 합니다.

저는 이 단계에서 왜를 많이 씁니다.

• 왜 이것이 문제인가?
• 왜 지금 이 문제가 생겼는가?
• 누가 영향을 받고 무엇을 하지 못하는가?
• 제안한 변경이 왜 그 사람에게 도움이 되는가?
• 사용자가 돈을 내야 한다면 왜 이 결과를 선택하는가?

질문을 부주의하게 반복하면 동료를 괴롭히거나 공격하는 것처럼 느껴질 수 있습니다. 첫 답이 부족하다는 사실을 과시하려는 질문이 아닙니다. 자신감은 있지만 비어 있는 정의에 몇 주를 쓰지 않기 위한 질문입니다. 전달 방식은 조심하되 호기심 자체를 없애서는 안 됩니다.

사용자 중심 사고는 자기 자리에서 벗어나는 일이다

개발자는 무언가 만들면서 “이건 무조건 대박이다”라고 생각하기 쉽습니다. 저도 그랬습니다. 대개 자기 위치에서만 아이디어를 평가했을 때 생기는 확신입니다.

사용자는 다른 상황에 있고 제품을 선택하는 이유도 다릅니다. 제품을 만들고 출시한 뒤 실제 사용자를 초대합니다. 사람들이 이 기능을 쓸지, 쓴다면 왜 쓸지, 무슨 가치를 얻는지 물어야 합니다.

기술적인 트래픽이 학습 목표라면 통제된 부하를 별도로 만듭니다. 인위적인 트래픽은 시스템 문제를 드러내고, 실제 사용자는 처음 정의한 제품 문제가 맞았는지 보여줍니다. 두 관찰을 바탕으로 문제 정의를 다시 봅니다.

이 방법이 유일한 정답이라고 말하지는 않습니다. 제 시도 속에서 설득력을 얻은 방식입니다. 미션을 정의하고, 여러 위치에서 왜를 묻고, 만든 것을 공개한 뒤 사용자와의 접촉으로 머릿속 이야기를 고칩니다. 문제 해결은 코드 전에 시작하고 코드가 동작한 다음 검증됩니다.