문제를 잘못 고르면, 완벽하게 만들어도 실패한다
IT 서비스의 가장 위험한 착각은 "좋은 기능을 만들면 고객이 알아줄 것"이라는 믿음이다. 기능이 훌륭하고, 화면이 세련되고, 기술적으로 안정적이라도 고객의 진짜 문제를 건드리지 못하면 서비스는 조용히 사라진다. 사람들은 냉정하다. 특히 자신의 시간과 돈을 쓰는 순간에는 더 냉정하다.
고객은 기능을 사지 않는다. 고객은 더 나은 하루와 덜 불안한 미래를 산다.
협업툴을 사는 팀은 채팅창을 사고 싶은 것이 아니다. 누가 무엇을 하고 있는지 몰라서 생기는 혼란을 줄이고 싶다. 보안 서비스를 사는 회사는 대시보드를 감상하고 싶은 것이 아니다. 사고가 터졌을 때 "왜 미리 막지 못했느냐"는 질문 앞에 무너지지 않고 싶다. 예약 시스템을 쓰는 병원은 달력 기능을 원하는 것이 아니다. 전화가 몰리는 아침마다 직원이 지치고, 환자가 기다리다 화내는 상황을 줄이고 싶다.
진짜 문제는 대개 기능 이름보다 깊은 곳에 있다. 고객이 "검색 기능이 필요해요"라고 말할 때 실제 문제는 검색이 아닐 수 있다. 자료가 너무 흩어져 있어 최신 파일을 믿을 수 없는 상황일 수 있다. 고객이 "알림 기능을 넣어 주세요"라고 말할 때 실제 문제는 알림이 아닐 수 있다. 중요한 일을 놓쳤을 때 책임을 혼자 떠안아야 하는 불안일 수 있다.
최고의 서비스 팀은 고객의 말을 무시하지 않는다. 하지만 고객의 말을 그대로 요구사항으로 받아 적지도 않는다. 고객이 말한 문장 뒤에 숨은 장면을 찾는다. 왜 그런 말을 했는지, 언제 그런 문제가 생기는지, 그 문제 때문에 무엇을 잃는지, 지금은 어떻게 버티고 있는지, 정말 돈을 내고 바꾸고 싶은지 끝까지 파고든다.
이 장의 목표는 바로 그것이다. 시장 조사, 고객 인터뷰, 관찰, 로그 데이터, Jobs-to-be-Done 관점을 통해 고객이 실제로 돈을 내고 해결하고 싶은 문제를 발견하는 법을 익히는 것. 서비스의 운명은 이 단계에서 상당 부분 결정된다. 문제를 잘못 고르면 실행력이 뛰어날수록 더 빠르게 엉뚱한 곳으로 달려간다.
고객이 말하는 니즈는 출발점이지 결론이 아니다
고객 인터뷰를 해 보면 놀라울 정도로 많은 사람이 자신에게 필요한 기능을 말해 준다. "이런 버튼이 있으면 좋겠어요." "자동으로 정리되면 좋겠어요." "관리자 권한을 더 세분화해 주세요." "AI로 추천해 주세요." 겉으로 보면 모두 소중한 의견이다. 실제로도 소중하다. 문제는 그것이 곧바로 정답은 아니라는 데 있다.
사람은 자신의 행동을 완벽하게 설명하지 못한다. 불편하다고 말한 것을 실제로는 계속 쓰기도 하고, 좋다고 말한 기능을 출시해도 거의 사용하지 않기도 한다. 인터뷰에서 "꼭 필요하다"고 말한 사람이 결제 페이지 앞에서는 망설인다. 반대로 별말 없이 쓰던 기능이 사라지면 강하게 항의한다.
왜 이런 차이가 생길까? 사람은 미래의 행동보다 현재의 감정을 더 쉽게 말하기 때문이다. 인터뷰 자리에서는 예의상 긍정적으로 말할 수 있고, 상상 속에서는 무엇이든 유용해 보일 수 있다. 하지만 실제 업무 시간, 실제 예산, 실제 책임, 실제 동료의 반응이 개입되는 순간 선택은 달라진다.
그래서 고객이 말하는 니즈는 세 가지로 나누어 보아야 한다.
고객이 명확히 말하는 요구
고객이 행동으로 드러내는 우선순위
고객도 아직 언어로 설명하지 못한 숨은 고통
서비스 팀이 해야 할 일은 이 셋을 맞춰 보는 것이다. 고객이 "중요하다"고 말한 것이 실제 행동에서도 나타나는가? 고객이 "불편하다"고 말한 문제가 돈이나 시간을 쓰면서까지 해결하려는 문제인가? 고객이 반복해서 우회하고, 엑셀로 보완하고, 사람을 붙이고, 야근으로 메우는 부분은 어디인가?
고객의 말과 행동이 다를 때는 행동을 더 무겁게 보아야 한다. 말은 희망을 담지만, 행동은 비용을 담는다. 고객이 이미 돈을 쓰고 있거나, 시간을 반복해서 낭비하고 있거나, 실수를 막기 위해 복잡한 절차를 만들고 있다면 그곳에는 실제 문제가 있을 가능성이 높다.
좋은 인터뷰는 의견을 묻지 않고 과거를 복원한다
많은 고객 인터뷰가 실패하는 이유는 미래를 묻기 때문이다.
"이런 서비스가 있으면 쓰시겠어요?"
"월 3만 원이면 결제하실 것 같나요?"
"이 기능이 있으면 편할까요?"
이 질문들은 친절해 보이지만 위험하다. 고객은 대개 긍정적으로 답한다. "네, 있으면 좋죠." "상황에 따라 쓸 수도 있을 것 같아요." "가격만 맞으면 괜찮을 것 같네요." 이런 답변은 회의실에 희망을 준다. 그러나 출시 후에는 아무도 결제하지 않는 잔인한 현실이 기다릴 수 있다.
좋은 인터뷰는 미래의 상상을 묻기보다 과거의 실제 사건을 복원한다.
"마지막으로 이 문제 때문에 곤란했던 때가 언제였나요?"
"그때 어떤 일이 벌어졌나요?"
"누가 영향을 받았나요?"
"결국 어떻게 해결했나요?"
"그 해결에 시간이나 비용이 얼마나 들었나요?"
"왜 기존 도구로는 충분하지 않았나요?"
이런 질문은 고객을 상상에서 현실로 데려온다. 고객이 실제로 겪은 장면을 말하기 시작하면 문제의 온도가 드러난다. 목소리가 빨라지는 순간, 웃으면서도 짜증이 묻어나는 순간, "그때 정말 큰일 날 뻔했어요"라는 말이 나오는 순간, 그곳에 힌트가 있다.
예를 들어 한 스타트업이 중소 쇼핑몰을 위한 재고 관리 서비스를 만든다고 해 보자. 나쁜 인터뷰는 이렇게 묻는다.
"재고 자동화 기능이 있으면 쓰실까요?"
대부분은 "있으면 좋죠"라고 답할 것이다. 하지만 이 답으로는 아무것도 판단할 수 없다. 좋은 인터뷰는 이렇게 들어간다.
"최근에 재고가 맞지 않아서 문제가 생긴 적이 있나요?"
고객이 "지난달에 인기 상품이 품절됐는데 사이트에는 재고가 남아 있다고 떠서 주문이 계속 들어왔어요"라고 말한다면 이야기가 시작된다. 이어서 묻는다. "그 주문은 어떻게 처리했나요?" "고객 불만은 얼마나 들어왔나요?" "환불이나 쿠폰 비용은 얼마나 들었나요?" "그 뒤로 어떤 방식으로 확인하고 있나요?"
이 과정을 거치면 단순한 "재고 자동화"가 아니라 진짜 문제가 드러난다. 문제는 재고 숫자 자체가 아니라, 잘못된 재고 정보가 고객 불만과 운영자의 불안을 만들고, 매출 손실과 평판 하락으로 이어지는 구조일 수 있다. 이때 서비스가 팔아야 할 것은 재고 입력 화면이 아니라 "품절 사고를 줄이고 밤에 덜 불안하게 만드는 운영 안정감"이다.
관찰은 고객이 생략한 진실을 보여 준다
인터뷰만으로는 부족하다. 사람은 자신이 너무 익숙하게 하는 행동을 잘 설명하지 못한다. 매일 하는 일일수록 "그냥 그렇게 해요"라고 말한다. 하지만 서비스 기회는 바로 그 "그냥" 안에 숨어 있다.
고객이 업무를 하는 모습을 관찰하면 말로는 나오지 않던 진실이 보인다. 창을 여러 개 띄워 놓고 복사 붙여넣기를 반복하는 손놀림, 시스템 오류가 날 때마다 옆 사람에게 묻는 습관, 중요한 값을 입력하기 전에 휴대폰 사진을 찍어 두는 불안, 공식 도구보다 개인 메신저를 더 자주 쓰는 현실. 이런 장면은 회의실 인터뷰에서는 잘 나오지 않는다.
관찰에서 중요한 것은 고객을 평가하지 않는 태도다. "왜 이렇게 비효율적으로 하지?"라고 생각하는 순간 관찰은 끝난다. 고객은 바보가 아니다. 그 방식이 이상해 보여도, 그 고객의 환경에서는 나름의 이유가 있다. 권한이 부족해서, 시스템이 느려서, 동료가 새 도구를 싫어해서, 실수하면 책임이 커서, 회사 규정상 다른 방법이 없어서 그렇게 하는 것이다.
현장 관찰을 할 때는 다음을 유심히 보아야 한다.
고객이 공식 절차를 우회하는 순간
같은 데이터를 여러 번 입력하거나 확인하는 순간
실수를 막기 위해 개인적인 장치를 만드는 순간
기다림, 불안, 확인, 재작업이 반복되는 순간
고객이 도구보다 사람에게 의존하는 순간
이런 순간은 서비스가 개입할 수 있는 균열이다. 좋은 서비스는 고객의 현실을 탓하지 않는다. 현실의 마찰을 흡수한다. 고객이 이미 만들어 둔 임시방편은 특히 중요하다. 엑셀 템플릿, 메신저 공지방, 수기 체크리스트, 캡처 폴더, 개인 노트, 별도 승인 문서. 이것들은 모두 "기존 해결책이 충분하지 않다"는 증거다.
가끔 최고의 아이디어는 고객이 만든 조악한 우회로에서 나온다. 고객이 엑셀로 매일 정리하는 표는 새 서비스의 핵심 데이터 모델이 될 수 있다. 고객이 메신저에 반복해서 올리는 공지는 자동 알림 기능의 시작점이 될 수 있다. 고객이 실수 방지를 위해 종이에 적어 붙인 체크리스트는 온보딩 플로우의 뼈대가 될 수 있다.
관찰은 고객의 말을 의심하기 위한 도구가 아니다. 고객이 미처 설명하지 못한 맥락을 존중하기 위한 도구다.
로그 데이터는 행동의 그림자다
인터뷰와 관찰이 고객의 장면을 깊게 보여 준다면, 로그 데이터는 많은 사람의 행동 패턴을 넓게 보여 준다. 사용자가 어디에서 가입을 멈추는지, 어떤 기능을 반복해서 쓰는지, 어떤 화면에서 오래 머무는지, 어떤 오류 이후 이탈하는지, 어떤 고객군이 결제까지 이어지는지 데이터는 조용히 말한다.
하지만 데이터도 저절로 진실이 되지는 않는다. 숫자는 질문을 잘 던지는 사람에게만 대답한다. 가입 전환율이 낮다는 숫자만 보고 "가입 버튼 색을 바꾸자"고 결론 내리면 위험하다. 진짜 문제는 가격 설명이 불명확한 것일 수도 있고, 고객이 서비스의 가치를 이해하지 못한 것일 수도 있으며, 가입 과정에서 회사 정보 입력을 너무 일찍 요구하기 때문일 수도 있다.
로그 데이터는 특히 고객의 말과 행동 사이의 차이를 검증할 때 강력하다. 고객들이 인터뷰에서 "고급 분석 기능이 중요하다"고 말했는데 실제로는 기본 리포트만 반복해서 본다면, 그 이유를 다시 물어야 한다. 고급 분석이 필요 없는 것일 수도 있지만, 너무 어려워서 못 쓰는 것일 수도 있다. 반대로 고객이 별로 언급하지 않은 기능이 높은 재방문과 결제 유지에 연결되어 있다면, 그 기능은 고객이 말로 표현하지 못한 핵심 가치일 수 있다.
좋은 팀은 인터뷰, 관찰, 로그를 따로 보지 않는다. 세 가지를 서로 연결한다.
인터뷰는 왜 그런 행동을 하는지 설명해 준다. 관찰은 실제로 어떻게 행동하는지 보여 준다. 로그는 그 행동이 얼마나 자주, 누구에게, 어떤 결과로 나타나는지 알려 준다. 이 세 가지가 같은 방향을 가리킬 때 문제의 신뢰도는 높아진다.
예를 들어 고객 인터뷰에서 "초기 설정이 어렵다"는 말이 반복된다. 관찰해 보니 고객은 API 키 발급 단계에서 개발자를 불러야 해서 멈춘다. 로그를 보니 가입자의 60%가 연동 설정 페이지에서 이탈한다. 이때 문제는 선명해진다. 단순히 도움말을 추가할 일이 아니다. 초기 가치 경험을 API 연동 뒤로 미루는 구조 자체를 바꿔야 할 수 있다.
데이터는 고객의 마음을 직접 보여 주지 않는다. 하지만 행동의 흔적을 남긴다. 그 흔적을 사람의 맥락과 함께 읽을 때, 서비스 팀은 감이 아니라 근거로 움직이기 시작한다.
문제의 강도를 측정하라
모든 문제는 같지 않다. 어떤 문제는 있으면 불편하지만 없어도 버틸 만하다. 어떤 문제는 계속 미루다가 언젠가 해결해도 된다. 반면 어떤 문제는 오늘 해결하지 않으면 돈을 잃고, 고객을 잃고, 평판을 잃고, 잠을 잃는다. 서비스가 먼저 노려야 할 곳은 후자다.
초기 IT 서비스가 자주 실패하는 이유는 너무 넓은 시장을 바라보기 때문이다. "모든 직장인을 위한 생산성 도구", "모든 소상공인을 위한 관리 플랫폼", "모든 기업을 위한 협업 솔루션" 같은 문장은 커 보이지만 실제로는 흐릿하다. 시장이 넓다는 말은 고객의 문제가 다양하다는 뜻이다. 문제가 다양하면 메시지도 흐려지고, 기능 우선순위도 흔들리고, 영업도 어려워진다.
처음에는 시장의 크기보다 고통의 강도를 보아야 한다. 고통이 강한 세그먼트는 작아 보여도 빠르게 반응한다. 그들은 이미 문제를 알고 있고, 해결책을 찾고 있으며, 기존 방식에 불만이 있고, 비용을 지불할 이유가 있다.
문제의 강도는 몇 가지 질문으로 가늠할 수 있다.
이 문제가 얼마나 자주 발생하는가?
발생했을 때 손실은 얼마나 큰가?
고객은 현재 이 문제를 해결하기 위해 무엇을 쓰고 있는가?
고객은 이미 시간, 돈, 사람, 절차를 투입하고 있는가?
이 문제를 해결하지 못하면 누가 가장 곤란해지는가?
예산을 승인할 사람도 이 문제를 중요하게 느끼는가?
여기서 핵심은 "불편함"과 "구매 동기"를 구분하는 것이다. 사람은 불편하다고 해서 반드시 돈을 쓰지는 않는다. 불편하지만 익숙하면 참고 산다. 무료 대안으로 대충 버틴다. 담당자 개인은 힘들어도 회사 차원에서는 중요하게 보지 않을 수 있다.
반대로 강한 문제는 조직 안에서 계속 비용을 만든다. 반복 야근, 고객 불만, 매출 누수, 보안 위험, 법적 리스크, 의사결정 지연, 직원 이탈 같은 형태로 나타난다. 이런 문제는 단순히 "있으면 좋은 서비스"가 아니라 "없으면 위험한 서비스"가 될 수 있다.
최고의 서비스는 처음부터 모두를 만족시키려 하지 않는다. 가장 아픈 사람을 먼저 찾는다. 그리고 그들의 문제를 깊고 날카롭게 해결한다. 작은 세그먼트에서 강한 사랑을 받는 서비스가 큰 시장으로 확장될 가능성이 높다. 반대로 넓은 시장에서 약한 관심만 받는 서비스는 아무리 많은 기능을 넣어도 중심을 잡기 어렵다.
세그먼트는 인구통계가 아니라 고통의 모양으로 나눈다
세그먼트를 나눌 때 흔히 업종, 회사 규모, 나이, 직무 같은 기준을 사용한다. 물론 이런 기준은 필요하다. 하지만 진짜 서비스 기회를 찾으려면 한 걸음 더 들어가야 한다. 중요한 것은 "누가 비슷하게 생겼는가"가 아니라 "누가 비슷한 고통을 겪는가"다.
예를 들어 "소상공인"이라는 세그먼트는 너무 넓다. 동네 카페, 온라인 쇼핑몰, 필라테스 스튜디오, 작은 병원, 학원은 모두 소상공인일 수 있지만 하루의 문제는 다르다. 카페는 피크타임 주문 처리와 재고 폐기가 문제일 수 있고, 쇼핑몰은 재고와 배송 문의가 문제일 수 있으며, 병원은 예약, 대기, 개인정보 보호가 문제일 수 있다.
같은 업종 안에서도 고통은 다를 수 있다. 매장이 하나인 카페와 지점이 다섯 개인 카페는 필요한 서비스가 다르다. 사장이 직접 운영하는 곳과 매니저가 교대로 운영하는 곳도 다르다. 고객 불만이 리뷰로 즉시 퍼지는 업종과 내부 업무 효율이 더 중요한 업종도 다르다.
그래서 세그먼트는 이렇게 정의할수록 강해진다.
"직원 10명 이하의 소상공인"보다 "네이버 예약과 전화 예약을 동시에 관리하느라 하루에 두 번 이상 예약 누락을 걱정하는 소규모 병원"이 낫다.
"B2B 영업팀"보다 "월말마다 여러 CRM과 스프레드시트 데이터를 맞추느라 영업관리자가 이틀 이상 보고서 작업을 하는 SaaS 영업팀"이 낫다.
"개발자"보다 "운영 장애 대응을 겸하는 5명 이하 백엔드 팀에서 새벽 알림을 받고도 원인 파악에 30분 이상 걸리는 개발자"가 낫다.
이렇게 좁히면 시장이 작아 보인다. 하지만 메시지는 강해진다. 고객은 "좋은 서비스네요"가 아니라 "우리 얘기인데요?"라고 반응한다. 이 반응이 중요하다. 최고의 서비스는 고객이 설명을 듣고 이해하는 것이 아니라, 첫 문장에서 자신의 상황을 발견하게 만든다.
고통의 모양으로 세그먼트를 나누면 기능 우선순위도 선명해진다. 누구를 위해 무엇을 포기해야 하는지 알 수 있다. 초기 서비스는 모든 것을 잘할 수 없다. 따라서 누구의 어떤 문제를 먼저 압도적으로 해결할지 정해야 한다.
Jobs-to-be-Done: 고객은 서비스를 고용한다
Jobs-to-be-Done, 줄여서 JTBD는 고객이 제품을 구매하는 이유를 "일"의 관점에서 보는 사고방식이다. 여기서 말하는 일은 직업이 아니라 고객이 어떤 상황에서 이루고 싶은 진전이다. 고객은 서비스를 소유하기 위해 사는 것이 아니라, 자신의 삶이나 업무에서 어떤 일을 더 잘 끝내기 위해 서비스를 고용한다.
이 관점은 강력하다. 경쟁을 기능표가 아니라 고객의 선택 상황으로 보게 만들기 때문이다. 고객이 우리 서비스를 선택하기 전에도 그 문제를 어떻게든 해결하고 있었다. 엑셀로 버텼을 수도 있고, 사람을 더 뽑았을 수도 있고, 외주를 썼을 수도 있고, 기존 유명 솔루션을 억지로 사용했을 수도 있다. 심지어 아무것도 하지 않고 불편을 감수했을 수도 있다.
JTBD의 핵심 질문은 이것이다.
"고객은 어떤 상황에서, 어떤 진전을 이루기 위해, 어떤 기존 해결책을 버리고, 왜 새로운 서비스를 선택하는가?"
여기에는 네 가지 요소가 들어 있다. 첫째, 상황이다. 고객이 언제 문제를 강하게 느끼는가. 둘째, 진전이다. 고객이 어떤 더 나은 상태로 가고 싶은가. 셋째, 기존 해결책이다. 지금은 무엇으로 버티고 있는가. 넷째, 전환 동기다. 왜 지금 바꾸려 하는가.
예를 들어 한 팀이 프로젝트 관리 도구를 도입한다고 해 보자. 표면적으로는 업무 관리 기능이 필요해 보인다. 그러나 JTBD로 보면 더 깊어진다.
"프로젝트가 세 개 이상 동시에 돌아가고, 재택근무자가 늘어나면서, 팀장은 누가 무엇을 놓치고 있는지 매일 물어보는 상황에서 벗어나고 싶다. 지금은 메신저 공지와 엑셀 목록으로 관리하지만, 업데이트가 늦고 책임 소재가 흐려진다. 새 도구를 선택하는 이유는 업무를 예쁘게 정리하려는 것이 아니라, 마감 전날에야 누락을 발견하는 불안을 줄이기 위해서다."
이 문장이 나오면 서비스 설계가 달라진다. 핵심 기능은 단순한 할 일 목록이 아닐 수 있다. 누가 막혔는지 빨리 보이게 하는 상태 표시, 반복 확인을 줄이는 알림, 회의 전에 자동으로 정리되는 진행 요약, 책임자가 명확히 남는 변경 기록이 더 중요할 수 있다.
고객이 서비스를 고용하는 이유를 알면, 무엇을 만들지보다 무엇을 약속할지가 보인다.
전환은 사랑보다 불안에서 시작된다
새로운 서비스로 바꾸는 일은 귀찮다. 계정을 만들고, 데이터를 옮기고, 팀원을 설득하고, 사용법을 배우고, 기존 프로세스를 바꿔야 한다. B2B 서비스라면 보안 검토, 계약, 예산 승인, 내부 교육까지 필요하다. 고객이 새로운 서비스를 선택하려면 "좋아 보인다"만으로는 부족하다.
전환은 보통 네 가지 힘의 싸움이다.
현재 방식의 불만
새로운 서비스가 주는 매력
바꾸는 과정의 불안
기존 습관의 관성
현재 방식의 불만이 약하면 고객은 움직이지 않는다. 새로운 서비스의 매력이 커도 전환 불안이 더 크면 미룬다. 기존 습관이 강하면 불편해도 계속 쓴다. 그래서 서비스 팀은 "우리 기능이 얼마나 좋은가"만 말해서는 안 된다. 고객이 바꾸지 못하게 붙잡는 힘을 함께 줄여야 한다.
고객은 이런 걱정을 한다. 데이터 이전이 실패하면 어쩌지? 팀원들이 싫어하면 어쩌지? 기존 시스템과 연동이 안 되면 어쩌지? 결제했는데 우리가 기대한 효과가 없으면 어쩌지? 담당자가 퇴사하면 운영이 멈추지 않을까? 보안 심사에서 문제가 되지 않을까?
최고의 서비스는 이런 불안을 설계의 일부로 다룬다. 무료 체험만 던져 주는 것이 아니라, 첫 성공까지 안내한다. 데이터 가져오기를 쉽게 만들고, 기존 도구와 병행할 수 있게 하고, 실패해도 되돌릴 수 있게 한다. 내부 설득용 자료를 제공하고, 보안 문서를 준비하고, 고객의 상사에게 설명할 수 있는 성과 지표를 보여 준다.
전환 장벽은 제품 밖에만 있지 않다. 마케팅 문구, 가격 정책, 온보딩, 고객 지원, 문서, 계약 방식 모두 전환 장벽을 낮추거나 높인다. 고객이 새 서비스를 고용하는 순간에는 기대와 두려움이 동시에 있다. 두려움을 낮추지 못하면 기대는 행동으로 바뀌지 않는다.
경쟁 분석은 기능표 베끼기가 아니다
경쟁 서비스를 분석할 때 많은 팀이 기능표를 만든다. A사는 대시보드가 있고, B사는 자동화가 있고, C사는 모바일 앱이 있고, 우리는 무엇이 부족한지 표시한다. 이런 분석은 필요할 때도 있다. 그러나 여기서 멈추면 위험하다. 기능표를 따라가다 보면 경쟁사의 그림자만 쫓게 된다.
경쟁 분석의 진짜 목적은 "무엇을 베낄까"가 아니라 "고객이 아직 만족하지 못한 지점은 어디인가"를 찾는 것이다. 경쟁사가 기능을 갖고 있다는 사실보다 중요한 것은 고객이 그 기능을 통해 성공하고 있는지다. 기능은 있는데 어렵다면 기회가 있다. 기능은 많은데 특정 세그먼트에는 과하다면 기회가 있다. 유명한 서비스지만 도입 장벽이 높다면 기회가 있다. 가격은 싸지만 신뢰가 낮다면 기회가 있다.
경쟁 서비스를 볼 때는 세 가지를 집중해서 보아야 한다.
첫째, 미충족 욕구다. 고객이 정말 원하는 결과가 무엇인데 기존 서비스가 충분히 주지 못하는가. 예를 들어 기존 서비스가 강력한 분석 기능을 제공하지만, 고객이 실제로 원하는 것은 분석가가 없어도 회의에서 바로 설명할 수 있는 간단한 요약일 수 있다.
둘째, 불만 리뷰다. 앱스토어, 커뮤니티, 블로그, 고객 사례, Q&A, 영업 현장의 반응에는 고객의 좌절이 남아 있다. "복잡하다", "느리다", "지원이 답답하다", "가격이 갑자기 오른다", "연동이 어렵다", "작은 팀에는 부담스럽다" 같은 말은 단순한 불평이 아니다. 새 서비스가 들어갈 틈이다.
셋째, 전환 장벽이다. 고객이 경쟁 서비스를 싫어하면서도 왜 계속 쓰는가. 데이터가 묶여 있어서, 팀 전체가 이미 익숙해서, 경영진이 승인한 표준 도구라서, 다른 시스템과 깊게 연결되어 있어서, 바꿀 사람이 없어서일 수 있다. 이 장벽을 이해하지 못하면 더 좋은 서비스를 만들어도 고객을 데려오지 못한다.
경쟁사의 약점만 보는 것도 위험하다. 그들이 왜 선택받았는지도 보아야 한다. 고객은 바보가 아니다. 경쟁사가 오래 살아남았다면 고객이 참아 줄 만한 강점이 있다. 그 강점이 신뢰인지, 생태계인지, 가격인지, 도입 편의인지, 브랜드인지 파악해야 한다. 그래야 정면승부를 할지, 특정 세그먼트에서 파고들지, 완전히 다른 기준으로 경쟁할지 결정할 수 있다.
경쟁 분석의 결론은 "우리도 저 기능을 만들자"가 아니라 "고객이 아직 얻지 못한 결과를 우리가 어떤 방식으로 더 잘 제공할 수 있는가"여야 한다.
돈을 내는 문제와 칭찬만 받는 문제
서비스 아이디어를 검증할 때 가장 달콤한 독은 칭찬이다. "좋은 아이디어네요." "저도 필요할 것 같아요." "출시하면 알려 주세요." 이런 말은 팀을 들뜨게 한다. 하지만 칭찬은 결제가 아니다. 관심은 구매가 아니다. 다운로드는 반복 사용이 아니다.
고객이 돈을 내는 문제는 몇 가지 특징을 가진다. 먼저 문제의 주인이 분명하다. 누가 이 문제 때문에 가장 곤란한지 알 수 있다. 다음으로 손실이 구체적이다. 시간이 얼마나 낭비되는지, 비용이 얼마나 새는지, 어떤 위험이 커지는지 설명할 수 있다. 또한 해결의 긴급성이 있다. 언젠가가 아니라 지금 바꾸고 싶은 이유가 있다.
반대로 칭찬만 받는 문제는 대개 흐릿하다. 있으면 좋지만 없어도 된다. 고객은 흥미를 보이지만 다음 행동을 하지 않는다. 미팅은 잡지만 자료를 보내지 않는다. 무료 체험은 신청하지만 데이터를 넣지 않는다. 가격을 물어보지만 예산 이야기는 피한다.
그래서 초기 검증에서는 고객의 말보다 작은 행동을 요청해 보아야 한다. 다음 인터뷰를 잡아 달라고 하기. 실제 데이터를 일부 보여 달라고 하기. 현재 쓰는 템플릿을 공유해 달라고 하기. 베타 테스트에 팀원을 초대해 달라고 하기. 유료 파일럿 예산을 논의해 달라고 하기. 이런 요청 앞에서 고객의 진짜 온도가 드러난다.
고객이 귀찮음을 감수할수록 문제는 강하다. 고객이 내부 사람을 연결해 줄수록 조직 문제일 가능성이 높다. 고객이 가격 이야기를 피하지 않을수록 지불 의사가 있다. 고객이 "이건 우리 팀장도 봐야 해요"라고 말하는 순간, 서비스는 개인 호기심을 넘어 조직의 문제로 들어가기 시작한다.
물론 초기에는 완벽한 확신을 얻을 수 없다. 하지만 최소한 스스로 속이지는 않아야 한다. 좋은 반응과 강한 구매 신호를 구분해야 한다. 최고의 서비스 팀은 칭찬에 취하지 않고 행동을 본다.
문제 정의문은 팀의 나침반이다
진짜 문제를 찾았다면 그것을 한 문장으로 정리해야 한다. 이 문장은 단순한 기획 문서가 아니다. 팀의 나침반이다. 무엇을 만들고, 무엇을 만들지 않을지 결정하는 기준이 된다. 마케팅 문구, 온보딩, 가격, 영업, 고객 지원까지 모두 이 문제 정의에서 출발한다.
좋은 문제 정의문은 고객, 상황, 고통, 현재 대안, 원하는 결과를 담는다.
예를 들어 "중소기업을 위한 문서 관리 서비스"는 약하다. 너무 넓고 추상적이다. 반면 다음 문장은 훨씬 강하다.
"50명 이하의 제조업체 품질관리팀은 외부 감사가 다가올 때마다 최신 문서와 승인 이력을 찾느라 며칠을 쓰고, 오래된 파일을 제출할까 봐 불안해한다. 지금은 공유 폴더와 엑셀 목록으로 관리하지만 책임자 변경과 버전 혼선 때문에 실수가 반복된다. 이들은 감사 전에 필요한 문서를 빠르게 찾고, 누가 언제 승인했는지 확신할 수 있는 상태를 원한다."
이 문장에는 서비스의 씨앗이 들어 있다. 대상 고객이 있고, 고통의 순간이 있고, 기존 해결책의 한계가 있고, 고객이 원하는 진전이 있다. 이제 팀은 기능을 논의할 때마다 물을 수 있다.
"이 기능은 감사 전 문서 불안을 줄이는가?"
"이 온보딩은 품질관리팀이 첫날부터 최신 문서를 찾게 하는가?"
"이 가격은 감사 리스크를 줄이는 가치와 연결되는가?"
문제 정의문이 선명하면 팀의 에너지가 모인다. 반대로 문제 정의가 흐리면 모든 기능이 그럴듯해 보인다. 누구를 위한 서비스인지 모르면 모든 고객의 요청이 중요해 보이고, 결국 아무에게도 결정적인 서비스가 되지 못한다.
진짜 문제를 찾는 실전 흐름
진짜 문제 발견은 영감의 순간이 아니라 반복 가능한 과정에 가깝다. 처음부터 완벽한 답을 찾으려 하기보다, 가설을 세우고, 고객의 현실에서 검증하고, 더 날카롭게 좁혀 가야 한다.
먼저 의심에서 시작한다. "이런 사람이 이런 상황에서 이런 문제를 겪을 것이다"라는 가설을 만든다. 이때 가설은 구체적이어야 한다. "사람들은 일정 관리가 어렵다"보다 "프리랜서 디자이너는 여러 클라이언트의 피드백과 마감일을 동시에 관리하다가 수정 요청을 놓쳐 신뢰를 잃을까 봐 불안해한다"가 좋다.
다음은 인터뷰다. 고객에게 의견을 묻기보다 최근 사건을 묻는다. 마지막으로 문제가 발생한 때, 당시의 대응, 손실, 감정, 현재 대안, 의사결정 구조를 파악한다. 여기서 중요한 것은 설득하지 않는 것이다. 인터뷰는 판매 시간이 아니라 학습 시간이다. 고객이 불편하다고 말하지 않는다면 억지로 문제를 만들지 않는다.
그다음은 관찰이다. 가능하다면 고객이 실제로 일하는 장면을 본다. 화면 공유도 좋고, 현장 방문도 좋고, 고객이 사용하는 파일과 프로세스를 함께 보는 것도 좋다. 고객이 말하지 않은 우회로와 반복 행동을 찾는다.
이후 로그나 시장 데이터를 확인한다. 이미 서비스가 있다면 사용 로그, 문의 티켓, 이탈 지점, 결제 전환, 반복 사용률을 본다. 아직 서비스가 없다면 랜딩 페이지 실험, 수동 파일럿, 대기자 신청, 견적 요청, 컨설팅 형태의 선판매 등을 통해 행동 신호를 본다.
마지막으로 문제를 좁힌다. 가장 고통이 강하고, 예산 가능성이 있으며, 기존 해결책에 불만이 있고, 접근 가능한 세그먼트를 고른다. 처음부터 가장 큰 시장을 고르지 않아도 된다. 오히려 처음에는 "이 사람들에게는 반드시 필요하다"는 확신이 더 중요하다.
이 흐름은 한 번으로 끝나지 않는다. 문제를 발견했다고 생각했을 때 다시 고객에게 돌아가야 한다. 고객의 현실은 팀의 회의실보다 복잡하다. 좋은 서비스 팀은 자존심보다 현실을 더 사랑한다.
문제를 찾을 때 피해야 할 함정
진짜 문제를 찾는 과정에는 여러 함정이 있다. 첫 번째 함정은 자기 문제를 시장 문제로 착각하는 것이다. 창업자나 기획자가 개인적으로 겪은 불편은 좋은 출발점이 될 수 있다. 그러나 내가 불편하다고 해서 충분히 많은 고객이 돈을 낼 문제라는 뜻은 아니다. 개인적 경험은 가설이지 증거가 아니다.
두 번째 함정은 목소리 큰 고객에게 끌려가는 것이다. 강하게 요구하는 고객이 항상 중요한 고객은 아니다. 큰 고객의 요청 하나가 제품 방향을 흔들 수도 있다. 요청을 들을 때는 그 기능이 전체 문제 정의와 맞는지, 같은 고통을 가진 다른 고객에게도 가치가 있는지 봐야 한다.
세 번째 함정은 솔루션을 너무 일찍 사랑하는 것이다. 팀이 이미 만들고 싶은 기능에 빠져 있으면 고객의 말을 그 기능을 정당화하는 방식으로만 듣게 된다. 고객이 문제를 말해도 팀은 곧장 "그러면 이 기능을 넣으면 되겠네요"라고 결론 내린다. 하지만 문제를 충분히 이해하기 전의 해결책은 대개 얕다.
네 번째 함정은 평균 고객을 상상하는 것이다. 평균 고객은 실제로 존재하지 않는다. 모든 고객을 평균 내면 아무도 절실히 원하지 않는 중간 서비스가 나온다. 초기에는 평균보다 극단을 보아야 한다. 가장 자주 문제를 겪는 사람, 가장 큰 손실을 보는 사람, 가장 빨리 바꾸고 싶은 사람을 찾아야 한다.
다섯 번째 함정은 경쟁사를 너무 두려워하는 것이다. 이미 강한 경쟁자가 있다는 사실은 나쁜 신호만은 아니다. 그만큼 고객이 돈을 쓰는 시장일 수 있다. 중요한 것은 같은 방식으로 싸우지 않는 것이다. 특정 세그먼트의 미충족 욕구, 불만 리뷰, 전환 장벽을 깊게 이해하면 거대한 경쟁사 옆에도 작은 문이 열린다.
문제 발견은 겸손을 요구한다. 고객을 안다고 생각하는 순간 놓친다. 시장을 안다고 생각하는 순간 낡는다. 좋은 팀은 계속 묻고, 보고, 확인한다.
고객의 하루 속에서 돈이 새는 지점을 찾아라
진짜 문제는 고객의 하루 속 어딘가에서 비용을 만들고 있다. 그 비용은 항상 돈으로만 나타나지 않는다. 시간, 집중력, 신뢰, 평판, 기회, 안정감, 관계도 비용이다. 하지만 결국 강한 문제는 어떤 방식으로든 경제적 의미를 갖는다.
실무자가 매주 5시간씩 반복 입력을 한다면 인건비가 새고 있다. 고객 문의에 늦게 답해 환불이 늘어난다면 매출이 새고 있다. 보안 점검을 수기로 하다가 사고 위험이 커진다면 미래의 손실이 커지고 있다. 보고서 숫자를 믿지 못해 회의가 길어진다면 의사결정 속도가 느려지고 있다. 직원이 같은 문제로 매번 스트레스를 받는다면 조직의 에너지가 닳고 있다.
서비스는 이 비용을 줄여야 한다. 그리고 고객이 그 비용을 알아차리게 도와야 한다. 고객은 자신의 고통에 익숙해져서 그것이 비용이라는 사실을 잊고 있을 수 있다. 매주 야근하는 것이 당연해지고, 수작업 검수가 당연해지고, 고객 불만을 사과로 때우는 것이 당연해진다. 좋은 서비스는 고객에게 묻는다.
"이게 정말 당연한 일인가요?"
이 질문이 고객의 마음에 꽂히면 변화가 시작된다. 고객은 그동안 참고 있던 불편을 문제로 인식한다. 문제로 인식된 고통은 해결책을 찾기 시작한다. 그리고 해결책이 충분히 믿을 만하다면 돈을 낼 준비를 한다.
사람들은 기능을 사지 않는다. 더 나은 하루를 산다. 덜 불안한 미래를 산다. 오늘 밤 조금 더 편히 잠들 수 있는 이유를 산다. 내일 회의에서 덜 공격받을 확신을 산다. 고객에게 사랑받을 가능성을 산다. 실수해도 무너지지 않을 안전망을 산다.
최고의 IT 서비스는 이 사실을 잊지 않는다.
이 장에서 가져가야 할 관점
최고의 서비스는 멋진 아이디어보다 선명한 문제에서 시작된다. 고객이 말하는 니즈는 중요하지만 그것만으로 충분하지 않다. 인터뷰로 과거의 실제 사건을 복원하고, 관찰로 고객이 생략한 행동을 발견하며, 로그 데이터로 반복되는 패턴을 확인해야 한다. 말과 행동이 만나는 지점에 진짜 문제가 있다.
Jobs-to-be-Done 관점은 고객이 서비스를 왜 선택하는지 깊게 보게 해 준다. 고객은 기능을 구매하는 것이 아니라 특정 상황에서 더 나은 상태로 가기 위해 서비스를 고용한다. 따라서 기존 해결책의 불만, 새로운 서비스의 매력, 전환 과정의 불안, 습관의 관성을 함께 분석해야 한다.
초기에는 넓은 시장보다 고통이 강하고 지불 의사가 높은 세그먼트를 먼저 공략해야 한다. 모두를 위한 서비스는 대개 아무에게도 절실하지 않다. 고객이 "좋네요"라고 말하는 수준을 넘어 "지금 필요합니다"라고 말하는 지점을 찾아야 한다.
경쟁 분석도 기능표를 베끼는 일이 아니다. 경쟁사의 기능보다 고객의 미충족 욕구, 불만 리뷰, 전환 장벽을 보아야 한다. 고객이 왜 기존 서비스를 쓰고, 왜 불만을 가지며, 왜 아직 떠나지 못하는지 이해할 때 새로운 기회가 열린다.
이 장의 핵심 문장은 이것이다.
최고의 IT 서비스는 고객이 요청한 기능을 만드는 팀이 아니라, 고객이 돈을 내고서라도 벗어나고 싶은 장면을 발견한 팀이 만든다.
다음 장에서는 그 장면 속에서 사람의 마음이 어떻게 움직이는지 더 깊이 들어간다. 고객은 왜 미루고, 왜 믿고, 왜 불안해하고, 왜 어떤 서비스에는 습관처럼 돌아오는가. 서비스의 승부는 문제를 찾은 뒤에도 계속된다. 이제 우리는 사람의 마음을 움직이는 심리학의 문을 열 것이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.