고객은 Jira가 싫다고 했다. 그래서 새 Jira가 필요할까
익숙한 도구에 대한 불만은 듣기 쉽다. 근데 그 불만이 곧 구매 문제는 아니다. 한 대화에서 배운 것. 고객이 말한 불편과 조직이 지금 풀어야 하는 문제를 구분하는 법, 그리고 고객 인터뷰에서 대신 물어야 할 네 가지 질문.
최근 한 소프트웨어 조직을 이끄는 분과 이야기하다가 Jira에 대한 불만을 들었다. 그리고 같은 대화에서 그분은 그게 지금 가장 큰 문제는 아니라고 했다. 두 이야기가 한자리에서 나왔다는 게 내게는 중요했다.
우리는 이슈와 프로젝트를 관리하는 기능을 만들고 있다. 그래서 익숙한 도구가 불편하다는 말을 들으면 자연스럽게 우리 기능이 떠오른다. 화면을 더 간결하게 만들고, 다른 작업과 연결하고, 번거로운 입력을 줄이면 어떨까. 대화를 제품 설명으로 이어가기 쉬운 순간이다.
근데 이어진 이야기는 다른 곳을 향했다.
고객이 도구에 불만이 있으면 그게 곧 구매 이유가 될까?
되지 않는다. 자주 쓰는 도구에는 구체적인 불만을 말하기 쉽지만, 새 제품에 예산과 시간을 배정하는 결정에는 다른 조건들이 들어간다. 지금 겪는 손실, 해결의 시급성, 도입 이후 달라질 업무, 바꾸는 데 드는 부담이다.
그 대화에서 뒤이어 나온 고민은 이런 것이었다. AI가 작성한 코드를 더 많이 내보내게 되고, 제품 담당자도 코드를 만들고, 여러 에이전트가 동시에 일하는데 전체 상황을 파악하기 어렵다. 누가 무엇을 바꾸고 있으며 그 결과를 어떻게 운영에 반영할지가 이슈 화면의 불편보다 훨씬 큰 질문이었다.
그래서 고객이 말한 불편과 우리가 검증해야 할 구매 문제를 구분해야 한다는 걸 다시 확인했다.
불편과 구매 문제는 어떻게 다른가?
예시로 보면 차이가 분명하다. 이슈 화면이 번거롭다는 불만이 있다고 하자. 조직 전체가 이미 같은 방식으로 보고하고 외부 협력사와도 연결돼 있다면, 화면이 조금 편해진다는 이유만으로 옮기기는 어렵다. 전환 비용이 불편의 크기보다 크다.
반대로 배포 직전마다 변경 범위와 검증 결과를 맞추는 데 어려움이 있다면 얘기가 달라진다. 이건 매 배포마다 반복되고, 틀리면 운영에 영향이 간다. 기존 도구를 유지하면서 그 작업을 줄이는 접근도 검토할 수 있고, 통합된 환경으로 옮기는 접근도 검토할 수 있다. 어느 쪽이 맞는지는 그 조직의 실제 업무를 더 들어봐야 한다. 이 선택의 기준은 커넥터를 다 만들어 놓고 왜 마이그레이션을 권하는가에 정리해뒀다.
사용자와 구매자의 질문도 다르다. 실무자는 오늘의 번거로움을 줄이고 싶고, 구매를 결정하는 사람은 조직이 얻을 변화와 도입 부담을 설명해야 한다. 한 사람의 강한 공감만으로 두 질문에 모두 답했다고 생각하면 다음 단계에서 멈추기 쉽다.
고객 인터뷰에서는 무엇을 물어야 하나?
제품에 대한 의견보다 최근에 실제로 벌어진 일을 묻는 게 낫다. 우리가 쓰는 질문은 네 가지다.
- 마지막으로 그 문제가 생겼을 때 누가 무엇을 확인했는가
- 어떤 도구를 열고 누구에게 질문했는가
- 얼마나 자주 반복되는가
- 이미 어떤 방법으로 해결하려 했는가
이 과정에서 우리가 도울 수 있는 지점이 드러난다. "이슈 관리가 불편하다"는 답에서는 나오지 않는 정보다.
그래서 새 Jira가 필요한 고객은 누구인가?
있다. 기존 도구가 업무와 맞지 않거나, 운영 비용이 크거나, 새로운 개발 환경을 처음부터 구성해야 하는 조직이다. 고객이 구매할 문제가 이슈 관리에 있다면 그 문제를 제대로 풀어야 하고, 우리 이슈·프로젝트 기능은 그걸 위해 있다.
다만 내가 이슈 관리 기능을 만들었다는 이유로 모든 인터뷰를 그 결론으로 가져가서는 안 된다. CollabOps의 방향을 고민할 때 이 대화를 다시 떠올리는 이유다. 이미 있는 도구를 더 많이 설명하는 것보다, 고객이 놓치고 있는 변경과 판단의 맥락을 이해하는 게 먼저다. 이슈, 코드, 빌드, 승인, 배포가 함께 설명돼야 풀리는 문제가 무엇인지 묻고 있고, 그게 우리가 Change를 제품의 중심에 놓은 이유이기도 하다.
고객 인터뷰를 잘했다는 기준은 무엇인가?
내가 갖고 있던 가정 중 무엇이 바뀌었는가다. 우리 제품이 좋다는 말을 얼마나 들었는가가 아니다. 한 번의 대화가 시장 전체를 증명하지는 않는다. 다만 이번 대화는 다음 고객에게 던질 질문을 바꿔줬다. 같은 문제가 다른 조직에서도 반복되는지, 현재 어떻게 처리하는지, 개선을 위해 실제로 시간을 내고 환경을 연결할 의사가 있는지.
고객의 말은 소중하다. 그래서 한 문장만 골라 듣지 않으려 한다. 불편하다는 말 뒤에 어떤 업무가 있고, 그 조직이 지금 무엇을 해결해야 하는지까지 듣는 것이 내 일이다.
비슷한 글
1억 원짜리 소프트웨어는 고객의 무엇을 바꿔야 할까
공급자가 원하는 계약 금액과 고객이 지불할 이유는 따로 설명해야 한다. 가상의 가정으로 투자 대비 효과를 끝까지 계산해 보면, 배포 한 번의 시간 절감만 세는 계산이 왜 부족한지와 함께 세야 할 항목이 무엇인지 드러난다.
백재민
기능은 늘었는데, "왜 우리 제품인가"는 더 어려워졌다
이슈·저장소·리뷰·CI/CD·문서·AI. 기능이 하나 늘 때마다 설명은 길어졌지만 고객이 지금 선택할 이유는 그만큼 선명해지지 않았다. 그래서 질문을 바꿨다. 고객이 지금 내리지 못하는 결정은 무엇인가. 우리가 Change를 제품의 중심에 놓은 이유.
백재민
우리는 왜 고객이 쓰는 도구부터 바꾸려 했을까
연동을 다 만들어 놓고 마이그레이션을 권했던 글에 기준 하나를 보탠다. 공급자에게 자연스러운 구조를 고객의 출발점으로 삼지 않기. 고객이 얻고 싶은 결과와 그 결과에 필요한 최소한의 변화부터 묻고, 연동을 택했을 때 해야 할 엔지니어링까지.
백재민