4화. 분명 제품기능은 준비됐는데, 왜 사업기회가 안 만들어지지?

제품의 활용가치를 고객이 직접 만들어내는지, 우리가 다 해줘야 하는지, 아니면 제3의 누군가가 필요한지 구분해야 합니다.

지난 글에서는 고객사 안팎의 복잡한 판을 지도처럼 그려봤습니다. 현업, 부서장, IT, 보안, 법무, 구매팀, 예산권자…. 내부만 해도 이렇게 얽혀 있었죠. 그 판을 이해하고 나니 누가 제품을 좋아하는지, 누가 예산을 쥐었는지, 누가 반대할지도 예상됩니다. 이쯤 되면 해당 어카운트의 전문가가 된 기분이죠.

그렇게 자신감을 조금 가지고 들어간 어느 화요일 오후의 고객 미팅이었습니다.

기술팀의 제품 설명도 좋았고, 고객의 언어에 맞춰 제법 잘 소통이 됩니다. 느낌이 좋습니다. 영업이 다시 잘 맞는 직업 같습니다.

설명을 듣던 고객이 묻습니다.

"기능도 기능이지만, 이 제품으로 저희 업무를 개선하려면 어떻게 해야 한다고 보세요?"

"직접 해주시는 거죠?"

"타사 사례도 보여주시고, 그에 맞게 프로젝트도 해주실 수 있나요?"

땀이 흐릅니다.

'음, 실제 프로젝트를요? 저희가 직접 하지는 않는데…. 그냥 사시면 되는데….'

이렇게 말하면 안 된다는 건 확실히 알 것 같습니다.

기능과 가격·라이선스 구조는 잘 정리했습니다. 고객 업무도 공부했고, 경쟁 제품보다 무엇이 나은지도 준비 했습니다. 데모도 괜찮았고, 사내에서는 어떻게 그렇게 잘 아느냐고도 했습니다. 그런데 공부한 것만 피해 나온 시험문제처럼, 이 질문이 사업기회를 다시 원점으로 돌립니다.

흐르는 땀을 닦으며 기술팀에 물어볼까, 생성형 AI한테 먼저 물어볼까 고민합니다. 그러면 그렇지, 이렇게 쉽게 풀릴 리가 없죠.

고객의 첫 번째 과제는 시스템 구축이 아닙니다

사실 고객의 질문은 틀리지 않았습니다.

고객에게 첫 번째 과제는 시스템 구축이 아니라 문제 해결입니다. 예를 들어 데이터 관리·분석 솔루션이라면 데이터 파이프라인의 변화와 설계를 먼저 봐야 합니다. 그런데 그 답은 고객도 아직 찾는 중입니다. 알았다면 벌써 했겠죠. 그래서 선진 사례를 찾고 내부와 의논하고, 때로는 컨설팅사나 SI, 클라우드 MSP와 업무 범위와 구축 방식을 협의합니다.

여기서 제품의 판매 전략과 도입 방식이 갈립니다.

어떤 제품은 사용자가 직접 켜서 써보는 순간 가치가 드러납니다. 기존 방식보다 빠르고 정확하고 저렴하거나, 특정 기능이 확실히 낫다면 그것이 곧 구매 이유가 됩니다. 제품 자체의 성능과 가격 경쟁력이 무기이고, 집중해서 영업해야 할 대상도 비교적 선명합니다.

반면 고객의 업무 프로세스와 데이터, 승인 구조를 건드리는 엔터프라이즈 소프트웨어는 다릅니다. 특히 실제 업무에 깊이 들어가는 AI 기반 솔루션이나 여러 시스템과 연동해야 하는 플랫폼형 제품은 더 그렇습니다. 기능이 좋다고 알아서 업무 혁신이 일어나지는 않습니다. AI에게 무엇을 맡길지 정의하고, 데이터를 준비하고, 기존 업무 흐름에 연결하는 과정이 오히려 더 복잡합니다.

그래서 다음의 질문을 던져야 합니다.

앞이라면 기능·가격·안정성이 승부처입니다. 뒤라면 누가 업무 변화를 설계하고, 누가 제품을 실제 업무에 적용하며, 누가 계속 사용되도록 정착시킬지가 승부처가 됩니다.

오늘 다루는 이야기는 특히 그 역할을 맡은 사람이 고객사 외부에 있을 때입니다. 예산은 고객이 집행하지만 업무 변화의 방향은 컨설팅사가 정하고, 구축은 SI가, 장기 운영은 클라우드 MSP가 맡을 수 있으니까요.

여기서 짚고 갈 게 있습니다. 이때 등장하는 SI·컨설팅사·클라우드 MSP는 아직 우리 편도 남의 편도 아닌 외부 플레이어입니다. 그중 우리 제품의 가치와 적용 방식을 이해하고 함께 움직이는 관계가 만들어졌을 때 비로소 파트너가 됩니다. 그 관계를 만들지 못하면 경쟁 제품을 가져오거나, "그건 굳이 안 사도 됩니다"라는 한마디로 딜을 멈추는 주체가 되기도 합니다.

그리고 이건 타이밍의 문제이기도 합니다. 고객이 설계를 모르는 게 아닙니다. 다 알고, 검토하고, 승인합니다. 다만 그 설계를 실제로 그리는 손은 컨설팅사나 SI일 때가 많습니다. 그들이 우리 제품을 모르면, 자기가 아는 방식과 익숙한 제품으로 그림을 그립니다. 나쁜 의도가 아니라 그게 가장 빠르고 안전하니까요.

고객은 그 그림을 보고 고개를 끄덕입니다. 고객에게 중요한 건 어떤 제품을 쓰느냐가 아니라 결과물이니까요. 우리 제품이 안 들어간 설계라도 고객의 문제만 풀린다면 굳이 반대할 이유가 없습니다. 그래서 설계가 다 그려진 뒤에 들어가면, 우리는 사업기회를 만드는 쪽이 아니라 이미 정해진 그림에 맞는지 검토받는 후보가 됩니다. 고객을 아무리 열심히 만나도, 그 그림을 그리는 손이 우리를 모르면 반영될 자리가 없습니다.

우리 제품의 가치는 누가 실제로 만들어내는가

이런 일이 일부 특이한 프로젝트에서만 벌어지는 것도 아닙니다.

BCG와 AWS가 1,100개 이상 조직을 조사해 2026년 발표한 자료를 보면, GenAI 도입에서 외부 전문업체 참여율은 PoC 단계에서 87%, 파일럿 단계에서 86%에 달했습니다. 참여하는 플레이어도 단계마다 달랐습니다. PoC에서는 컨설팅·자문이 39%, 파일럿에서는 SI가 41%까지 높아졌습니다. 이들은 주변에서 도움만 주는 업체가 아니라, 단계마다 실제 설계·검증·구축·운영을 맡는 핵심 주체일 수 있다는 뜻입니다.

그래서 세 역할을 함께 봐야 합니다. 회사 이름으로 구분하면 헷갈립니다. 같은 SI라도 컨설턴트는 업무 변화를, 엔지니어는 구축·운영을 맡을 수 있으니까요. 중요한 건 소속이 아니라 그 프로젝트에서 맡은 역할입니다. 그리고 세 역할은 관심사도, 말이 통하는 방식도 다 다릅니다.

언젠가 고객 미팅에서 이런 장면이 있었습니다. 제품 가치를 한창 설명하는데 뒤에 앉아 있던 SI 파견 엔지니어가 툭 던집니다.

"그거, 사람이 수동으로 해도 구축에는 문제없어요."

"굳이 유료 버전이나 고급 플랜까지는 필요 없을 수도 있고요."

"그리고 이거, 누가 구축하고 운영하죠? 고객이 하실 건가요?"

구구절절 정곡입니다. 영업 입장에서는 참 야속한 말인데, 저도 틀린 말은 아니라고 생각했습니다. 저부터 납득하지 못한 것을 남에게 설득하는 건 참 어려운 일입니다.

그 말에 고객의 표정이 바뀝니다. 기능 설명을 들으며 끄덕거리던 얼굴에서, "이거 굳이 해야 하나?"를 계산하는 얼굴로요.

이미 무료 버전이나 베이직 플랜을 쓰고 있는 고객이라면 저 말이 더 아픕니다. 그 고객은 우리 제품의 기능에 대해서는 이미 압니다. 어떤 면에서는 우리보다 더 잘 알기도 합니다. 그래서 더 어렵습니다. 이미 알고 있는 가치만으로는 더 큰 계약이 만들어지지 않거든요.

엔터프라이즈급 계약으로 넘어가려면 고객이 아직 충분히 확인하지 못한 그다음 가치를 보여줘야 합니다. 제품을 더 잘 활용하는 방법, 보안과 권한, 기존 시스템과의 연동, 그리고 운영 책임 같은 것들입니다.

그다음 가치를 설계하고 보여줄 사람이 아직 이 사업기회에 들어와 있지 않다면, 설명은 잘 끝났는데 딜은 이상하게 그 자리에서 멈춥니다.

그렇다면 누가 어떤 가치를 만들고, 무엇을 이유로 도입을 결정하는지 세 역할로 나눠볼 필요가 있습니다.

첫 번째, 고객프로젝트 담당자입니다. 예산을 요청하고 프로젝트를 검토하며 결과에 책임지는 사람입니다. 그는 묻습니다.

“꼭 이 제품을 구매해서 해결해야 할 이유가 있습니까?”

이 사람에게는 사업 가치와 위험 감소를 보여줘야 합니다.

두 번째, 사용자·업무변화주도자입니다. 고객사 현업이나 내부 챔피언일 수도 있고, 외부 컨설턴트나 SI일 수도 있습니다. 이들은 묻습니다.

“실제 업무는 어떻게 달라집니까?”

이들에게는 업무 개선 효과와 실제 사용 가치를 보여줘야 합니다.

세 번째, 구축·운영실행자입니다. 우리 혹은 파트너사 엔지니어일 수도 있고, SI 기술팀·MSP·고객 IT팀일 수도 있습니다. 이들은 묻습니다.

“어디까지가 표준이고, 어디부터 커스터마이징입니까? 운영은 누가 맡습니까?”

이들에게는 구현 용이성과 명확한 책임 범위를 보여줘야 합니다.

세 역할은 모두 고객사 안에 있을 수도 있고, 고객과 외부 플레이어에게 나뉘어 있을 수도 있습니다. 어디에 있든 한 축이 비면 프로젝트는 흔들립니다.

그리고 세 역할 중 하나라도 외부 플레이어가 맡고 있다면, 그 플레이어를 판매와 도입 구조에서 간과해서는 안 됩니다.

이때부터 영업은 훨씬 고난도가 됩니다. 세 꼭짓점을 모두 시야에 넣고, 프로젝트 단계에 맞춰 각각 다른 이유로 움직이게 해야 하니까요. 하나도 힘든데 셋이라니, 참 쉽지 않습니다.

그 와중에 회사에서는 또 묻습니다.

"왜 고객을 더 만나지 않습니까? 밸류 셀링을 제대로 못 하는 것 아닌가요?"

고객은 엄청 만났습니다. 우리가 정의한 밸류도 열심히 전했지요. 문제는 그 밸류가 고객이 원하는 업무 결과와 반드시 같지는 않다는 것입니다. 

그 간극을 해결하지 않은 채 어쩌다 계약만 성사시켜도 문제는 사라지지 않습니다. 고객이 기대한 결과가 나오지 않으면, 영업 단계의 빈칸이 인력 부족과 구축·운영의 혼선, 결국에는 재계약 불발로 옮겨갈 뿐입니다.

고객을 보라는 말의 범위를 넓혀야 합니다

파트너가 없으면 못 판다거나, 파트너 수를 더 늘리자는 이야기가 아닙니다. 실제 업무를 설계하고 제품을 프로젝트에 반영하는 주체가 고객사 밖에 있다면, 그들을 GTM 구조 안에 포함해야 한다는 이야기입니다. 그들이 우리를 모르면 고객을 열심히 만나고도 사업기회 발굴과 설계 반영의 타이밍을 놓칠 수 있습니다.

고객을 '계약하는 고객사'나 '예산권자'로만 정의하면, 제품을 업무 가치로 바꾸는 사람이 시야에서 사라집니다. 그들은 구매 이후의 주변 인물이 아니라 도입의 핵심 주체이고, 그들을 이해하는 것이 고객에게도 더 도움이 됩니다.

그래서 외부 플레이어를 고객에 준하는 수준으로 별도의 가치 제안을 설계해야 할 이해관계자로 봐야 합니다. SI와 컨설팅사도 묻습니다. "이 도구를 우리가 쓰면 무엇이 좋아집니까?" 벤더가 "고객에게 좋은 제품입니다"라는 말만 반복하면 반응은 미지근할 수밖에 없습니다. 이들이 자기 프로젝트에서 얻을 효율과 차별성, 반복 가능한 운영 방식을 보여줘야 우리 제품을 먼저 꺼내볼 이유가 생깁니다. 그 과정에서 이들도 자신만의 부가가치를 만들 수 있습니다.

반대의 함정도 있습니다. 이미 함께 일하는 구축·유통 파트너에게 기능과 설정 방법만 교육해놓고, 고객 발굴부터 업무 설계와 계속되는 커스터마이징까지 알아서 해주기를 기대하는 경우입니다. 업무 설계를 맡는 업체와 기술 구축을 맡는 업체는 역량과 계약 범위가 반드시 같지 않습니다. 게다가 그 역량이 특정 엔지니어 한두 명에게 몰려 있으면 문제는 더 커집니다. 다음 미팅에 갔더니 공들여 교육한 엔지니어가 퇴사했다고 합니다. 다시 교육하고, 다시 관계를 만들고, 또 처음부터. 내부에서는 왜 진행이 안 되냐 묻고, 결국 책임은 또 영업으로 돌아옵니다.

영업은 퇴근길 순대국집에서 동료와 술 한잔으로 답답함을 달랩니다. 그런데 회사에서는 그 술도 고객과 마시라네요. 

실제 가치를 만드는 사람을 찾는 것이 영업입니다

세 꼭짓점에 늘 같은 시간을 쏟으라는 뜻은 아닙니다. 초기에는 담당자와 업무변화주도자의 문제의식이, 설계와 PoC 단계에서는 사용자와 구축·운영실행자의 역할이 중요해집니다. 비중은 달라져도 어느 축이 비었는지는 계속 살펴야 합니다. 그리고 이 조율이 결국 최종 고객의 성공을 위한 일이라는 것을, 고객 담당자와 계속 공유해야 합니다.

그러니 제품을 실제 가치로 바꾸는 사람을 찾아 손잡는 일은 '부차적인 파트너 관리'가 아닙니다. 고객을 만나는 것만큼 중요한 영업입니다. 앞서 말한 통합 판매, Integrated Sales도 이 지점과 맞닿아 있습니다. 영업은 고객만 보고 생태계는 파트너팀 일이라고 분리해버리면 삼각형은 만들어지지 않습니다. 누구보다 열심히 담당자를 만났는데도 진행은 더디고, 포캐스팅은 어려워지며, CRM에 뭘 적을지 난감해집니다.

그런데 외부 플레이어는 알아서 우리 편이 되어주지 않습니다. 그들 역시 자신의 고객과 사업, 수익을 위해 움직입니다.

알아서 우리 제품을 영업해줄 파트너를 이미 찾으셨다면 복 받으신 겁니다. 아무도 그렇게 쉽게 남의 영업까지 대신해주지는 않더라고요.

그래서 이것은 영업이나 파트너팀의 개인기로 해결할 문제가 아닙니다. 누가 우리 제품을 실제 업무 가치로 바꿀 수 있는지, 그 역할을 맡을 주체를 어디서 찾고 어떤 이유로 함께 움직이게 할지를 회사 차원에서 미리 설계해야 하는 GTM 문제입니다.

결론

다시 화요일 오후의 미팅입니다. 이번에는 업무 범위를 협의하던 SI 담당자가 고객에게 말합니다.

"이 부분은 구축할 때 A 솔루션으로 푸는 게 좋겠습니다. 이번에 바꾸려는 업무 프로세스를 제대로 반영할 수 있고, 담당자가 바뀌어도 안정적으로 운영할 수 있습니다. 구축 이후 지원 체계도 잘 갖춰져 있으니, 한번 설명을 들어보시죠."

이 문장이 나오려면 그 외부 플레이어가 우리 제품의 가치를 이해하고, 자기 프로젝트에서 먼저 꺼내볼 이유가 있어야 합니다. 그 관계는 우연이 아니라 미리 준비된 것이어야 합니다.

제품 기능은 분명 준비됐습니다. 문제는 그 기능을 업무 가치로 바꿔줄 사람이 누구인지, 우리가 아직 정하지 못했다는 것입니다. 

그래서 이번 글에서 붙잡을 한 가지는 이것입니다.

고객이 우리 제품을 몰라서만 안 사는 것은 아닙니다. 이 기능이 자신의 업무에서 어떤 결과로 이어지는지, 그 과정을 설계할 사람이 아직 판에 없을 수 있습니다.

그 사람을 찾아내는 일. 어쩌면 그것이 우리가 지금 놓치고 있는 영업인지도 모릅니다.

이번 글의 적용 액션

진행 중인 딜 하나를 고르세요. 종이에 세 꼭짓점을 적어봅니다.

그리고 이 딜에 등장한 외부 플레이어를 적고 마지막 한 줄을 채워보세요.

지금 이 프로젝트의 설계를 그리는 손은 누구인가? 그 사람은 우리 제품을 아는가? 그에게 줄 가치는 무엇인가?

칸이 하나라도 비어 있다면, 딜이 안 풀리는 이유가 고객이나 영업 개인에게만 있는 것은 아닐 수 있습니다. 회사가 아직 그 역할을 정의하지도, 맡을 사람을 준비하지도 못한 것일 수 있습니다.

다음 화 예고

고객만 만나고 있었는데 업무 변화의 방향은 컨설팅사가 정하고 있었고, 무엇을 구축할지는 SI가 결정하고 있었습니다. 게다가 그 구축 파트너를 어떻게 교육하고 키울지도 숙제로 남습니다. 그런데 누가 그렇게 쉽게 우리 편이 되어줄까요?

다음 글에서는 고객의 변화와 구축에 참여하는 컨설팅·SI·운영등 시장의 다양한 전문 플레이어와 그 생태계를 더 깊이 들여다보겠습니다. 고객사를 나서자마자 외부 업체를 만나야 하는 순간들. 이 복잡한 정글로 들어가 보겠습니다.

💬 최근 딜에서 우리 제품으로 실제 일을 한 사람은 누구였나요? 고객사 안에 있었나요, 아니면 컨설팅사·SI·운영업체 같은 바깥에 있었나요?

본문에 나온 약어

참고자료