5화. 고객 안 만나고 누구를 만나는 거야?

새 파트너십, 빈 파이프라인

새 제품을 팔려고 할 때마다 막막했습니다.

도대체 누구부터 만나야 할까요.

무작정 콜드콜을 돌릴 수도 없고, 회사 로비를 찾아다니며 소개서를 나눠줄 수도 없습니다. 그래서 2화에서 우리가 어떤 고객의 무슨 문제를 푸는 회사인지 시장에 선명하게 알려야 한다고 말씀드렸습니다.

그러던 어느 날 이메일 문의가 들어옵니다.

“자료를 봤는데, 제품을 조금 더 자세히 알고 싶습니다.”

바로 이거다 싶어 에너지가 솟습니다. 그런데 만나보니 제품을 직접 사려는 고객은 아니었습니다.

“저희 고객에게 같이 제안할 수 있는 제품인지 보고 싶었습니다.”

고객을 더 뚫지 못해 답답하던 차에, 자기 고객을 데려오겠다는 회사가 제 발로 온 겁니다.

파트너십 체결을 진행합니다. 제품 교육을 두 번 했고, 데모 계정을 열어줬습니다. 가격과 마진을 정하고 기술 문의를 받을 엔지니어도 붙였습니다.

이제 그 회사가 자기 고객에게 우리 제품을 팔아 줄 차례라고 생각했습니다.

분기 말, 파트너와 회의를 엽니다.

“그래서 이번 분기, 같이 만든 사업기회가 몇 건이죠?”

정적이 흐릅니다.

교육 참석자 명단은 두 장인데, 공동 파이프라인은 한 줄도 없습니다.

그날 제가 내린 결론은 이랬습니다.

“영업 교육도 한 번 더 해야 할 것 같습니다.”

지금 돌아보면, 교육보다 먼저 다른 질문을 했어야 했습니다.

고객인 듯 고객 같은 고객 아닌 너

영업을 시작하면 일부러 찾지 않아도 여러 회사를 만나게 됩니다.

고객의 업무 방향을 잡는 컨설팅사, 시스템을 설계하고 구축하는 SI, 운영을 맡는 MSP, 계약과 공급을 지원하는 총판·리셀러, 다른 회사의 기술을 자기 솔루션에 넣어 파는 ISV까지.

제품과 고객 사이에는 생각보다 많은 회사가 있었습니다.

처음에는 고객을 위해 이들의 요청에도 잘 맞춰주면 된다고 생각했습니다. 그런데 요청이 쌓일수록, 고객도 아닌 회사들이 왜 이렇게 많은 조건을 붙이나 싶어졌습니다.

“전체 아키텍처에서 어디에 들어가나요?”

“기존 시스템과는 어떻게 연결합니까?”

“운영 중 문제가 생기면 누가 어디까지 책임지나요?”

제품을 만든 것은 우리인데, 어느 순간 우리가 시험을 보는 쪽이 되어 있었습니다.

특히 SI는 고객만큼이나 까다로웠습니다. 보안 자료와 연동 방법, 지원 인력과 장애 대응 절차를 확인하고 가격과 일정도 다시 맞춰 달라고 했습니다.

파트너 계약을 맺지 않은 회사라도 프로젝트의 주사업자라면 우리 제품이 들어갈지 말지를 좌우할 수 있었습니다.

제품 구매자는 고객인데 시험지는 SI가 내는 느낌이었습니다.

처음에는 그 과정이 딜을 진전시키기보다 방해하는 것처럼 보였습니다.

이럴 바에는 고객을 더 설득해 보자 싶었습니다. 고객이 원한다고 하면, SI도 우리 제품을 넣지 않겠느냐는 계산이었죠.

지금 보면 판을 절반만 본 계산이었습니다.

고객만 붙들고 설득하는 사이 SI와의 조율은 뒤로 밀렸고, 정작 우리 제품이 최종 제안에서 빠지는 일을 겪었습니다. 고객이 “이 제품 좋더라” 한마디 해줘도, 설계와 구축을 쥔 SI가 움직이지 않으면 자리가 쉽게 나지 않았습니다.

딜이 어느 정도 진전돼도 고객은 결국 다시 물었습니다.

“전체 설계와 구축은 어느 회사가 책임지나요?”

“도입 후 운영은 누가 받아주나요?”

그사이 경쟁사는 SI와 운영 계획까지 묶인 제안서를 내놓았습니다.

정반대처럼 보이는 두 실패의 원인은 하나였습니다.

저는 이 회사들을 고객에게 가려면 넘어야 할 존재이거나, 우리 대신 팔아줄 존재로만 나눴습니다.

그러면서 똑같은 부탁을 했습니다.

“좋은 제품이니 고객에게 한 번 소개해 주세요.”

정작 물어야 할 것은 따로 있었습니다.

이 회사는 고객 프로젝트에서 무슨 역할을 하는가. 우리 제품과 함께하면 무엇을 얻는가. 우리는 무엇을 해주고, 그들은 무엇을 책임지는가.

그들에겐 우리 제품보다 중요한 일이 있었습니다

에코시스템이라는 말은 거창하지만, 실제로는 고객 하나를 두고 각자 다른 방식으로 가치를 만들고 이익을 얻는 회사들이 모인 판입니다.

컨설팅사는 고객의 업무 변화와 투자 방향을 앞단에서 다룹니다. SI는 프로젝트의 설계·연동·구축 결과를 책임지고, MSP는 운영·장애·보안·비용을 봅니다. 총판은 계약·정산과 파트너 지원을 맡고, 리셀·구축 파트너는 제품을 배우고 제안·설치·교육에 투자합니다. 클라우드 플랫폼사 역시 고객의 아키텍처와 도입 경로에 영향을 주는 중요한 협업 대상이 되었습니다.

각자 잘하는 일도, 먼저 챙기는 포인트도 달랐습니다.

SI는 우리 제품이 제안 경쟁력을 높이면서도 구축 위험을 키우지 않는지 봅니다. MSP는 운영 과정에서 관리와 장애 부담을 감당할 수 있는지 보고, 총판과 리셀 파트너는 투자한 인력과 비용을 회수할 만한 매출이 나오는지 계산합니다. 클라우드 플랫폼사는 자기 플랫폼의 사용과 확장에 도움이 되는지를 먼저 봅니다.

파트너십에 합의했다고 우리 제품이 그 회사의 우선순위가 되는 것은 아니었습니다.

그들도 자신들이 잘하고, 반복하기 쉽고, 이익을 내기 좋은 일에 먼저 사람과 시간을 씁니다. 너무 자연스러운 일이었습니다.

우리가 파트너에게 사업기회를 기대하는 동안, 그들도 우리에게 사업기회를 기대하고 있었습니다. 전담 인력을 붙이고 교육과 데모 환경에 투자하려면 실제 매출로 이어질 가능성이 보여야 합니다.

우리가 “왜 고객을 더 발굴하지 않느냐”고 물을 때, 반대편에서는 “이 벤더는 우리에게 어떤 사업을 가져왔나”를 계산하고 있었습니다.

우리가 파이프라인을 기다리듯, 그들도 파이프라인을 기다렸던 겁니다.

그러니 파트너의 우선순위를 억지로 바꿀 수는 없었습니다.

제가 좋아하는 영화의 한 대사를 빌리자면, 이 바닥에도 영원한 적도, 영원한 동지도 없었습니다. 

어제 경쟁 제품을 제안했던 SI와 오늘은 공동 제안을 할 수 있습니다. 오늘 함께 세미나를 연 클라우드 플랫폼사가 내일은 다른 제품을 먼저 권할 수도 있습니다.

그 프로젝트에서 서로의 역할과 이익, 책임이 맞는 동안 함께 달릴 수 있었습니다.

우리에게 없는 능력과 타이밍을 봐야 했습니다

만나는 회사마다 열심히 설명하고 부탁했지만, 어떤 파트너에게는 너무 늦었고 어떤 파트너에게는 너무 빨랐습니다.

우리 제품이 고객의 업무 프로세스를 바꾸는 제품이라면, 고객이 무엇을 바꿀지 정하는 컨설팅과 설계 단계에서 먼저 알려져야 합니다.

그림이 완성된 뒤 찾아가면 이런 말을 듣습니다.

“좋은 제품이네요. 그런데 방향은 이미 정해졌습니다.”

4화에서 말씀드린 그 상황입니다.

버스는 이미 떠났고, 우리는 정류장에서 제품 소개서를 흔들고 있었던 거죠.

자동화·데이터·인프라 제품이라면 전체 구조를 설계하는 SI가 중요합니다. 운영 부담이 크다면 MSP가 장애·보안·비용과 지원 체계까지 검토해야 합니다. 반대로 표준화된 제품의 공급·설치·교육이 중요하다면 구축·리셀 파트너가 더 현실적입니다.

좋은 파트너는 유명세가 아니라, 우리 제품이 어느 단계에서 알려지고 검토·선택돼야 하는지에 따라 달라졌습니다.

Canalys는 2025년 전 세계 IT 지출을 약 5조3천억 달러로 전망하면서, 파트너를 통해 제공되는 IT가 그중 70%를 조금 넘을 것으로 추산했습니다. 파트너가 개입하는 경로가 IT 시장 전반에서 주변부가 아니라는 근거로 보는 편이 안전합니다.

그렇다고 그 단계에 들어갈 수 있는 회사가 모두 완벽한 파트너인 것은 아니었습니다.

컨설팅사와 대형 SI는 고객의 고민을 일찍 듣고 제안서에 우리 제품을 넣을 수 있습니다. 하지만 매출이 아직 작은 제품을 위해 전담 엔지니어를 미리 교육하고 대기시키기는 어렵습니다.

프로젝트를 만들 능력은 있지만, 구현할 손발은 부족할 수 있습니다.

반대로 전문 구축 파트너는 제품을 깊이 배우고 설치·연동·교육을 맡을 수 있습니다. 하지만 고객의 설계 단계에 들어가 있지 않거나 새로운 프로젝트를 만들 영업력이 부족할 수 있습니다.

제품은 잘 압니다.

그런데 제품을 넣을 프로젝트가 없습니다.

구현할 능력은 있지만, 사업기회를 만들 능력은 부족할 수 있습니다.

둘을 붙이면 해결될 것 같지만 이것도 간단하지 않습니다. 고객은 책임 창구를 하나로 두고 싶어 하고, 주사업자는 낯선 파트너가 끼는 것을 부담스러워합니다. 구축 파트너는 어려운 일은 자신들이 하는데 고객 관계와 매출은 앞단이 가져간다고 느낄 수 있습니다.

사업 규모가 작으면 나눌 몫도 부족합니다.

그래서 물어야 했습니다.

영업은 강하지만 구축·교육·운영 자원이 부족하다면, 비슷한 영업 파트너보다 그 빈칸을 채울 회사가 필요합니다. 반대로 기술지원 능력은 강하지만 사업기회를 일찍 발견하지 못한다면, 고객의 고민을 먼저 듣는 컨설팅사나 SI, 산업 영업력이 있는 파트너가 중요합니다.

파트너 전략은 계약한 회사의 수를 늘리는 일이 아니었습니다.

우리 제품이 알려지고 검토·선택돼야 하는 단계에 먼저 들어갈 수 있으면서, 지금 우리에게 부족한 능력까지 가진 회사를 찾는 일이었습니다. 그리고 그 회사가 함께 움직일 이유를 만드는 일이었습니다.

영업과 파트너팀도 같은 판을 봐야 했습니다

어카운트 영업도 해봤고 파트너 업무도 맡아보니, 서로를 바라보는 기분이 묘했습니다.

어카운트 담당자일 때는 파트너팀이 매주 매출 예측을 설명하는 책임에서 조금 비켜나 있는 것처럼 보였습니다.

막상 파트너 업무를 맡고 나니, 고객의 예산과 프로젝트 정보를 먼저 듣고 필요한 자원을 내부에 요청할 수 있는 영업의 권한이 다시 중요해 보였습니다. 제가 그 일을 해봤다는 것도 잠시 잊은 모양입니다.

그저 남의 떡이 커 보였던 겁니다.

GTM 전체를 맡고서야 둘 다 반쪽이라는 것을 알았습니다.

영업은 지금 딜에 무엇이, 언제 필요한지 압니다. 하지만 그 일을 맡을 회사를 혼자 찾아 키우기는 어렵습니다. 파트너팀은 회사를 발굴하고 훈련할 수 있지만, 실제 딜에 어떤 역할이 필요한지는 현장 없이 알기 어렵고요.

영업은 필요한 역할을 구체적으로 알려주고, 파트너팀은 그 일을 반복해서 맡을 회사를 미리 준비해야 했습니다. 서로 상대가 알아서 해주길 기다리면 안 됐던 겁니다.

둘이 따로 우선순위를 정하면 파트너는 늘어도 필요한 능력은 채워지지 않았습니다. 그렇다고 계약이 없는 SI나 주사업자를 무시할 수도 없었습니다.

중요한 것은 파트너를 몇 곳 확보했느냐가 아니라, 프로젝트에서 역할·이익·책임이 맞물리는 구조를 만들었느냐였습니다.

그래서 특정 프로젝트에서 협업할 회사와, 교육·기술지원·공동영업에 우선 투자할 핵심 파트너를 구분해야 했습니다.

다시 그 회의실, 부족했던 것은 교육이 아니었습니다

공동 파이프라인이 한 건도 없던 그 회의로 돌아가 보겠습니다.

우리는 제품을 두 번 가르쳤지만, 그 회사가 이 제품으로 무엇을 얻을지는 제대로 같이 그리지 않았습니다.

그 회사가 실제로 잘할 수 있는 역할도 확인하지 않은 채 영업부터 기술지원까지 모두 해주길 바랐습니다. 어떤 고객 문제를 새로 풀 수 있는지, 그들이 잘하는 일 안에서 어떤 매출과 차별화가 생기는지, 문제가 생기면 벤더가 어디까지 책임지는지도 함께 정하지 않았습니다.

다음 교육 일정을 잡기 전에, 그 회사가 맡을 역할과 얻을 이익부터 썼어야 했습니다. 그들이 투입한 사람과 시간을 회수할 사업을 함께 만들 계획이 있는지도요.

그래서 지금 파트너가 움직이지 않아 답답하다면, 다음 교육을 잡기 전에 두 칸만 먼저 써보시길 권합니다.

우리 제품이 알려지고 검토·선택돼야 하는 단계 하나. 그 단계에서 우리에게 없는 능력 하나.

그리고 “팔아주세요”라고 부탁하기 전에, 그 회사가 이 일에서 무엇을 얻을 수 있는지부터 함께 그리는 겁니다. 그 한 문장을 우리가 쓰지 못하면, 그 파트너도 다음 분기에 움직이지 않습니다.

영업은 그 판단을 지금 딜 안에서 구체화하고, 파트너팀은 그 역할을 반복해서 해낼 회사를 찾아 키웁니다. 어느 한쪽이 상대를 기다리기만 하면, 그 회의실의 정적은 다음 분기에도 다시 찾아옵니다.

“고객 안 만나고 누구를 만나는 거야?”

고객만 만나는 것으로는 부족했습니다.

고객의 성공과 우리의 성공을 위해, 우리에게 없는 능력을 가진 그들과 결국 함께 가야 했습니다.

AI 덕분에 제품을 더 빨리 만들고 더 쉽게 보여줄 수 있게 됐습니다. 하지만 그렇게 만든 제품을 고객의 데이터와 업무, 책임 구조 안에 실제로 앉히는 일은 오히려 더 복잡해졌습니다. 그 복잡한 도입 과정을 함께 책임질 적합한 파트너와의 협업이 더 중요해지지 않을까요?

이번 글의 적용 액션

1. 우리 제품이 알려지고 검토·선택돼야 하는 단계는 어디인가?

문제 발견·업무 설계 / 아키텍처·제품 선정 / 제안·계약 / 구축·온보딩 / 운영·확장 중 하나를 고릅니다.

2. 그 단계에서 우리에게 가장 부족한 능력은 무엇인가?

고객 접근·영업력 / 컨설팅·설계 / 구축 인력 / 교육·운영 중 하나를 고릅니다.

3. 그 능력을 가진 회사의 역할·이익·책임을 한 문장씩 적습니다.

모든 회사를 전략 파트너로 키우려 하지 않습니다. 특정 프로젝트에서 협업할 회사와 교육·기술지원·공동영업에 우선 투자할 핵심 파트너를 구분합니다.

그 회사가 잘하는 일 안에서 어떤 매출과 차별화를 얻을 수 있는지 우리가 설명하지 못한다면, 다음 분기에도 우리가 기대한 역할을 해줄 가능성은 높지 않습니다.

💬 댓글 질문

여러분에게도 “좋은 제품이니 소개 좀 해주세요”라고 부탁하고 기다렸던 파트너가 있나요?

그 파트너는 자신이 잘하는 일 안에서 무엇을 얻을 수 있어야 움직였을까요?

다음 글

어떤 영업이나 회사는 쉽게 파는 것 같고, 어떤 딜은 아무리 설명하고 두드려도 좀처럼 움직이지 않습니다.

단계가 착착 진행되는 기회가 있는 반면, 같은 자리만 빙빙 돌다가 산으로 가는 기회도 있습니다.

제품을 만들었다는 것은 이 제품으로 실제 혜택을 볼 누군가를 이미 가정했다는 뜻입니다. 결국 구매할 가능성이 있는 사람이 구매합니다. 당연한 이야기 아니냐고요?

다음 글에서는 이 살 사람에 대한 이야기들을 다루어보고자 합니다.

본문에 나온 약어

참고자료

Canalys, Channel partner investment in cloud hyperscalers: a strategic pivot point, 2025년 7월 1일.