로드맵과 고객의 요구가 충돌할 때 해야 할 일

FabricLoop 팀 작성  ·  2026년 5월  ·  4분 읽기

모든 제품 팀은 이런 전화를 받습니다. 고객 한 곳, 그것도 중요한 고객이 로드맵에 없는 기능을 원합니다. 지금 당장 필요하다고 합니다. 갱신 여부가 그 기능에 달려 있다고 은근히 암시하기도 합니다. 영업 팀은 느낌표 두 개를 붙여 그 메시지를 전달합니다. 두 번의 기획 주기를 거쳐 공들여 만든 로드맵은 한쪽에 있고, 고객은 반대쪽에 있습니다. 어떻게 해야 할까요?

이것은 예외적인 상황이 아닙니다. 유료 고객이 있는 제품이라면 어디서나 정기적으로 일어나며, 이를 어떻게 처리하는지는 제품 개발 프로세스가 실제로 어떻게 돌아가는지를 많은 부분 보여 줍니다. 목표는 언제나 “예”라고 하거나 언제나 “아니오”라고 하는 것이 아니라, 판단을 내릴 때 일관된 방법을 갖추는 것입니다.

고객과 로드맵이 충돌할 때의 의사결정 프레임워크

“한 고객인가, 여러 고객인가”가 첫 번째 필터입니다

여러 고객이 서로 독립적으로 같은 것을 요청한다면 진지하게 받아들일 가치가 있는 신호입니다. 특히 문제를 설명하는 표현이 비슷하다면 더욱 그렇습니다. 이는 그 필요가 특수한 사례가 아니라 실제이고 널리 퍼져 있음을 시사합니다.

한 고객이라면 계산이 달라집니다. 가장 큰 계정이라 해도 고객 한 곳의 요구가 시장 전체를 대표하지는 않습니다. 고객 한 곳을 위한 기능을 만드는 것은 시간이 갈수록 쌓이는 제품 전략의 세금입니다. 일회성 기능이 하나씩 늘 때마다 복잡성이 커지고, 유지보수 부담이 생기며, 더 넓은 시장에 대한 제품의 매력이 줄어듭니다.

관계를 해치지 않고 거절하는 방법

관계에 손상 없이 고객의 요청을 거절하는 핵심은 요청 자체가 아니라 그 이면의 문제를 인정하는 것입니다. “그 기능은 만들지 않겠습니다”라고 하면 반응이 좋지 않습니다. “X를 하시는 데 어려움을 겪고 계신 점을 이해합니다. 저희는 그 문제를 이렇게 생각하고 있고, 같은 필요를 해결할 계획이 로드맵에 있습니다”라고 하면 훨씬 잘 받아들여집니다.

고객에게 정말 필요한 것은 요청한 그 기능 자체가 아닌 경우가 많습니다. 그들에게 필요한 것은 근본적인 문제의 해결입니다. 고객이 제안한 기능이 아니더라도 그 해결로 가는 길을 보여 줄 수 있다면 대부분의 고객은 받아들입니다. 자신이 요청한 사양이 아니면 어떤 길도 받아들이지 못한다면, 그 고객이 우리 제품과 잘 맞는지에 대해 중요한 사실을 알려 주는 것입니다.

고객이 옳고 로드맵을 고쳐야 할 때

때로는 고객과의 충돌이 우리 생각에 실제로 빈틈이 있음을 드러내 줍니다. 계획에 없던 것을 여러 고객이 요청한다면 로드맵이 무언가를 놓쳤다는 신호입니다. 이때 올바른 대응은 요청받은 것을 반사적으로 만드는 것이 아니라, 그 이면의 문제가 로드맵에 들어가야 하는지, 들어간다면 어디인지 따져 보는 것입니다.

이 구분이 중요합니다. 고객은 문제에 대해서는 옳은 경우가 많지만, 해결 방법에 대해서는 거의 옳지 않습니다. 피드백은 문제에 대한 이해를 갱신하는 데 사용하세요. 기능 요청을 그대로 복사해 백로그에 붙여 넣는 데 쓰지 마세요.