고객이 원하는 것을 그대로 구현해야 할까?
2026년 1월 2일
제품을 개발할 때 가장 중요한 것은 고객이 겪는 문제를 해결하는 것이다. 그러기 위해서는 고객의 이야기를 충분히 들어야 합니다. 고객의 의견 없이 제품을 만든다면 결국 제품 개발을 참여하는 사람들의 경험이나 가치관이 반영된 기능을 만들 가능성이 높기 때문입니다.
하지만 고객이 말한 요구사항을 그대로 구현하는 것 역시 위험하다. 고객은 자신이 겪는 문제를 가장 잘 알고 있지만, 그 문제를 해결하는 최선의 방법까지 알고 있는 것은 아닙니다. 고객이 말하는 것은 하나의 해결책일 뿐이며, 개발자는 그 해결책보다 먼저 해결해야 할 문제를 이해해야 합니다.
이번 글에서는 고객의 요구사항을 그대로 구현했을 때 발생할 수 있는 문제와, 요구사항 너머의 의도를 파악하는 과정이 왜 중요한지 이야기해보려 합니다.
본질 파악하기
사내 직원들이 사용하는 백오피스 성격의 프로덕트를 배포하고, 한 달 후 사용자 인터뷰를 진행했다. 사용하면서 불편했던 점이나 필요한 기능, 이해하기 어려운 용어가 있는지 묻고 제품을 개선하기 위해서였다.
한 직원은 다음과 같은 의견을 주었다.
"새로운 데이터를 만들 때 기존 데이터를 파일로 업로드해서 시작할 수 있게 해주세요."
이 요구사항만 보고 개발합니다면 단순히 파일 업로드 기능을 추가했을 것이다. 하지만 이렇게 구현하면 확장성을 고려하지 못할 수도 있고, 실제로는 사용성이 기대만큼 개선되지 않아 나중에 기능을 제거하게 될 수도 있다.
그래서 먼저 요구사항보다 이유를 이해하려고 했다.
- 왜 이 기능이 필요할까?
- 어떤 점이 가장 불편했을까?
- 정말 파일 업로드만이 해결책일까?
- 다른 방법으로도 같은 문제를 해결할 수 있을까?
대화를 이어가면서 사용자가 겪는 진짜 문제를 알게 되었다.
새로운 데이터를 생성할 때마다 작업 공간을 만들고 초기 데이터를 설정해야 하는데, 대부분 비슷한 형태의 데이터로 시작했다. 그래서 매번 동일한 초기 데이터를 입력하는 작업이 반복되었고, 이를 줄이기 위해 "기존 파일을 업로드하고 싶다"는 요구사항을 제안한 것이었다. 이미 데이터를 파일로 저장하는 기능은 존재하고 있었다는 것이다.
결국 팀에서는 기존 파일을 불러오는 기능뿐만 아니라, 데이터를 생성하는 과정에서 초기 데이터를 바로 설정할 수 있는 기능도 함께 제공하기로 했다. 개발해야 할 기능은 처음보다 조금 늘어났지만, 사용자는 반복 작업을 훨씬 덜 하게 되었고 만족도도 높아졌다.
만약 처음 요구사항만 그대로 구현했다면 "파일 업로드 기능"은 추가했겠지만, 사용자가 실제로 겪고 있던 반복 작업의 불편함은 충분히 해결하지 못했을 것이고, 추후에 초기 데이터를 설정하는 기능을 개발하게 되었을 것이다.
기획 문서를 구현할 때도 마찬가지다. 문서에 적힌 요구사항을 그대로 구현하기보다 "왜 이런 기능이 필요할까?"를 고민하면 더 적절한 설계를 할 수 있고, 제품 역시 더 나은 방향으로 발전할 수 있다.
마치며
개발을 시작했을 때는 기획 문서에 적힌 내용을 빠르게 구현하는 것이 가장 중요하다고 생각했다. 자연스럽게 관심도 코드의 가독성이나 구조를 개선하는 데 집중되어 있었다.
하지만 경험이 쌓이면서 같은 기능을 더 빠르게 구현할 수 있게 되었고, 그만큼 기획 문서를 더 꼼꼼하게 읽기 시작했다. 이전에는 지나쳤던 부분을 살펴보며 "왜 이런 기능이 필요한 걸까?"라는 질문을 던졌고, PM이나 사용자와의 대화를 통해 기능의 의도를 이해하려고 노력했다.
그 과정에서 알게 된 것은 고객이 원하는 것은 특정 기능이 아니라 자신의 문제를 해결하는 경험이라는 점이었다.
개발자의 역할은 요구사항을 그대로 구현하는 사람이 아니라, 고객이 해결하고 싶은 문제를 이해하고 가장 적절한 해결책을 만드는 사람이라고 생각합니다.