“일단 써보세요. 기계값은 안 받습니다"

직무로 읽는 세상이야기 18화

“일단 써보세요. 기계값은 안 받습니다": 18세기를 뒤흔든 역발상

직무로 읽는 세상이야기 18화

0. 인트로: 증기기관은 기계가 아니라, 시대의 ‘엔진’이었다

18세기 영국.
산업혁명이 막 꿈틀대던 시절, 가장 뜨겁고 치열한 산업은 의외로 광산업이었습니다. 석탄은 그 시대의 석유이자 전기였습니다. 공장을 돌리고, 난방을 하고, 철을 녹이는 모든 산업의 출발점이 바로 석탄이었기 때문입니다. 그리고 그 석탄을 캐내는 광산은 당시로서는 가장 첨단 기술이 집약된 공간이었습니다.

문제는 하나였습니다.

물.

광산을 깊이 팔수록 지하수가 차올랐고, 물이 차오르면 채굴은 멈췄습니다. 아무리 석탄이 묻혀 있어도, 물을 퍼내지 못하면 산업은 멈추는 구조였습니다.

이때 등장한 인물이 바로 제임스 와트(James Watt)입니다. 와트가 개량한 증기기관은 단순히 ‘기계 하나’를 만든 사건이 아니었습니다. 그는 광산주인들에게 이렇게 말했습니다.

“이 기계를 사지 않아도 됩니다. 대신 이 기계를 써서 절감된 석탄 비용의 일부만 저에게 주십시오.”

당시 증기기관은 지금의 클라우드 서버처럼 거대하고 비싼 설비였습니다. 광산주인들이 선뜻 구매하기에는 부담이 컸습니다. 그래서 와트는 ‘소유’ 대신 ‘사용’을 제안했습니다.

기계를 파는 대신,
기계가 만들어낸 효율을 파는 방식.

광산이 더 깊이 파일수록,
석탄 생산량이 늘어날수록,
와트의 수익도 함께 늘어나는 구조였습니다.

이 모델 덕분에 광산은 멈추지 않았고, 증기기관은 산업혁명의 표준이 되었습니다. 그리고 이 장면은 놀랍게도, 현재 우리가 살아가는 디지털 산업의 구조와 정확히 닮아 있습니다.

예전에는 서버를 사고,
오피스 프로그램을 CD로 구매하고,
라이선스를 영구 소유했습니다.

지금은 다릅니다.

클라우드를 빌려 쓰고,
노션과 슬랙을 구독하고,
사용량만큼 비용을 지불합니다.

제임스 와트의 증기기관은 기계를 판 것이 아니라 ‘사용 기반 모델’의 씨앗을 심은 사건이었습니다. 눈에 보이는 제품을 파는 영업이 아니라, 고객의 업무 속에 스며들어, 빠져나오기 어려운 ‘중력’을 만드는 영업.

소유의 세계를 지나, 사용의 세계로 들어갑니다.

1. 디지털의 세계로 들어가기

우리는 지금 '영업'이라는 거대한 대륙을 탐험하고 있습니다. 영업이 작동하는 세계를 세 갈래로 나누어 살펴보고 있습니다.

유형의 세계: 눈에 보이는 제품과 실체를 파는 영업

디지털의 세계: 시스템과 소프트웨어, 사용 경험을 파는 영업

무형의 세계: 신뢰, 판단, 위험 이전 같은 가치를 파는 영업

그렇다면, 디지털의 세계는 무엇이 다른가

이제 무대가 바뀝니다. 18화부터 다루는 디지털의 세계에서는 영업의 출발점이 다시 한번 달라집니다.

여기서는 제품이 창고에 쌓이지 않고, 재고와 배송이 사라지며 사용과 접속이 곧 가치가 됩니다.

무엇보다 중요한 차이는 이것입니다.

디지털의 세계에서는 영업이 끝난 뒤 사용이 시작되는 것이 아니라, 사용 그 자체가 영업이 됩니다. 어떤 서비스는 써보는 순간 가치가 드러나고, 어떤 설루션은 최고의 의사결정이 선행되어야만 도입됩니다.

그래서 디지털의 세계에서 영업은 “얼마나 잘 설득했는가”보다 “어떤 구조로 쓰이게 만들었는가”에 더 가깝습니다.

디지털의 세계에서 다룰이야기

이번 디지털 영업을 다음과 같은 기준으로 나누어 살펴봅니다.

18화에서는 사용을 통해 팔리는 사용기반 영업을

19화에서는 결정을 통해 시작되는 결정기반 영업을,

20화에서는 그리고 그 사이의 혼합형 구조 구축형·에코시스템을,

SaaS, 협업툴, 클라우드, 엔터프라이즈 설루션에서
영업은 어디까지가 설명이고,
어디부터가 설계인지,
데이터와 사용 로그는
어떻게 실적으로 연결되는지를 직무 단위로 풀어볼 예정입니다.

2. 사용기반 영업(PLG)이란 무엇인가

사용기반 영업(PLG:Product-Led Growth) 은 한 문장으로 정리하면 이렇습니다.

“구매 계약이 먼저가 아니라, 사용 경험이 먼저 시작되고, 그 경험이 쌓이면서 거래가 완성되는 구조”

사실 ‘먼저 써보고 결정하는 방식’은 디지털에만 존재하는 개념이 아닙니다.
식품은 시식 후에 계약이 이뤄지고,
장비는 데모를 거친 뒤 도입이 결정되며,
무형의 컨설팅조차 파일럿 프로젝트를 통해 신뢰를 쌓습니다.

유형·디지털·무형의 세계 모두 사용 경험은 늘 중요한 판단 기준이었습니다. 다만 대부분의 전통적 거래에서는 계약 → 납품 → 사용의 순서가 기본 구조였습니다.

반면 디지털 세계의 사용기반 모델은 이 순서가 구조적으로 뒤집혀 있습니다.

먼저 써본다.
팀 안에서 자연스럽게 퍼진다
조직 단위 계약으로 확장된다

즉, ‘사용 그 자체가 영업의 출발점’이 됩니다. 영업사원이 설득하기 전에, 제품이 먼저 고객의 업무 속으로 들어가 자리를 잡습니다. 그래서 사용기반 영업은 설명으로 설득하는 영업이 아니라, 경험이 확산되며 계약을 만들어내는 영업에 가깝습니다.

(1) 협업 및 생산성 도구 (SaaS: Softwear as a Service )

첫 번째는 사람의 ‘업무 방식’을 바꾸는 도구들입니다.

문서 작성

커뮤니케이션

일정 관리

협업 방식

이 영역의 공통점은 비개발자도 바로 쓸 수 있고, 개인 → 팀 → 조직으로 확산된다는 점입니다. 이 영역에서 영업의 성과는 사용자 수, 활성도, 확장 속도로 측정됩니다.

(2) 클라우드 인프라 및 개발자 도구 (DevTools)

두 번째는 개발자와 시스템을 중심으로 움직이는 도구들입니다.

클라우드 인프라

API

개발 프레임워크

배포·운영 도구

이 영역 역시 사용기반이지만, 첫 번째와 결정적인 차이가 있습니다. 사용자는 소수지만, 영향 범위는 조직 전체 입니다. 개발자 한 명이 선택한 기술이 회사의 전체 시스템과 비용 구조를 결정합니다. 그래서 이 세계의 영업은 기능 설명보다 기술적 신뢰가 핵심입니다.

이 구분이 가지는 의미

같은 사용기반 영업이라도,

협업·생산성 도구는 사람을 많이 쓰게 만드는 영업이고,

클라우드·DevTools는 조직의 기술 선택에 들어가는 영업입니다.

그래서 필요한 역량도 다르고, 영업의 언어도 다르며, 커리어의 방향도 달라집니다. 이제부터 이 두 갈래의 사용기반 영업이 현장에서 실제로 어떻게 작동하는지, 그리고 왜 이런 직무들이 등장했는지를 하나씩 풀어보려 합니다. 디지털의 세계에서 영업은 더 이상 ‘설득의 기술’이 아니라, 사용과 선택의 구조를 설계하는 일이기 때문입니다.

3. Account Executive (AE) –협업 및 생산성 도구 (SaaS): “무료로 시작된 사용을, 전사 계약으로 완성하는 사람”

이 산업은 무엇인가 – 협업·생산성 SaaS의 세계

협업 및 생산성 도구(SaaS) 산업은 기업의 업무 방식 그 자체를 바꾸는 소프트웨어를 다룹니다. 문서 작성, 커뮤니케이션, 프로젝트 관리처럼 매일 반복되는 업무에 깊숙이 들어가 사용자가 바꾸기 어려운 락인(Lock-in)을 만들어냅니다.

이 산업의 특징은 명확합니다. 먼저 개인·소규모 팀이 무료로 사용하고 사용성이 검증되면 조직 전체로 확장(엔터프라이즈 계약)됩니다. 그래서 이 세계에서 영업은 “사기 전에 설득”하는 일이 아니라, “이미 쓰고 있는 것을 회사 차원으로 묶는 일”에 가깝습니다.

회사는 어떤 곳인가 – 노션 · 슬랙

노션과 슬랙은 단순히 “업무 도구를 파는 회사”가 아닙니다. 이들은 사람들이 일하는 방식을 바꿔버린 회사에 가깝습니다.

노션(Notion): 문서가 아니라 ‘업무의 구조’를 파는 회사

노션은 표면적으로 보면 문서 작성, 위키, 프로젝트 관리, 데이터베이스 기능을 하나로 묶은 협업툴입니다. 하지만 실제로 노션이 팔고 있는 것은 기능이 아니라 업무를 정리하는 방식입니다. 많은 기업에서 노션은 공식 도입 이전에 이미 현업에서 쓰이고 있습니다.

팀 회의록 정리

개인 업무 관리

프로젝트 진행 현황 공유

사내 위키 대체

이 모든 것이 IT 부서나 경영진의 승인 없이 실무자 개인의 선택으로 먼저 시작됩니다. 그래서 노션의 확산은 위에서 아래로 내려오는 방식이 아니라, 아래에서 위로 번져 올라가는 구조를 가집니다.

AE가 마주하는 고객은 “도입할지 말지 고민하는 회사”가 아니라, 이미 노션으로 일하고 있는 조직입니다. 문제는 기능 설명이 아니라 보안, 권한 관리, 데이터 통제, 전사 표준화입니다.

노션 AE의 역할은 “이 도구가 좋다”를 말하는 사람이 아니라, “이미 이렇게 쓰고 계신데, 이제는 회사 차원에서 관리해야 하지 않겠습니까?”를 구조적으로 정리하는 사람입니다.

슬랙(Slack): 메시지가 아니라 ‘조직의 흐름’을 파는 회사

슬랙 역시 단순한 메신저가 아닙니다. 슬랙이 만들어낸 변화는 ‘이메일 중심 업무’에서 ‘실시간 협업 중심 업무’로의 이동입니다. 슬랙은 특히 개발 조직, IT 기업, 스타트업에서 폭발적으로 먼저 확산되었습니다.

이메일보다 빠른 의사소통

프로젝트별 채널 관리

다양한 SaaS 도구와의 연동

이런 이유로 슬랙은 종종 공식 도입 이전에 팀 단위로 먼저 깔려 있는 경우가 많습니다. 하지만 팀 단위 사용과 전사 도입 사이에는 큰 간극이 존재합니다.

회사 전체 커뮤니케이션 표준으로 쓸 수 있는가

외부 협업과 내부 보안은 어떻게 관리할 것인가

메시지 데이터는 어떻게 보관·감사할 것인가

바로 이 지점에서 슬랙 AE의 역할이 등장합니다. 슬랙 AE는 “메신저 하나 더 쓰세요”라고 말하지 않습니다. 대신, 슬랙이 조직 전체의 협업 인프라가 되었을 때, 어떤 운영적 이점이 생기는지를 설명합니다.

두 회사의 공통점: ‘팔 필요가 없는 제품’

노션과 슬랙의 가장 큰 공통점은 이것입니다.

개인 단위 무료 사용자가 매우 많고

이미 현업에서 자발적으로 쓰이고 있으며

“쓸까 말까”의 문제가 아니라,
“어디까지, 어떻게 쓸 것인가”의 문제만 남아 있다는 점입니다.

그래서 이 두 회사의 AE 포지션은 전통적인 의미의 신규 영업과 다릅니다. 시장에 없는 수요를 만드는 사람이 아니라, 이미 존재하는 사용을 조직의 계약과 매출로 정리하는 역할입니다.

이 점에서 노션·슬랙 AE는 디지털의 세계, 그중에서도 사용기반 영업이 어떻게 작동하는지를 가장 잘 보여주는 직무라고 할 수 있습니다. 제품이 먼저 쓰이고, 영업은 그다음에 등장합니다.

AE(Account Executive) 직무는 실제로 무엇을 하는가

JD에 적힌 AE(Account Executive)의 역할을 현장 언어로 풀면 이렇게 정리할 수 있습니다. “어디에서 이미 쓰이고 있는지를 찾아, 그 사용을 회사의 공식 표준으로 만드는 사람”

구체적으로 보면

무료 또는 팀 단위 사용 기업 발굴,

조직 내 실제 사용자(실무자)와 접점 확보,

IT, 보안, 재무, C-level 등 의사결정 구조 파악

전사 도입 시의 가치(보안·관리·확장성) 제안

협상 및 계약 체결까지 End-to-End 세일즈 수행

이 과정에서 AE는 고객을 ‘설득’하기보다 고객 내부에서 이미 일어나고 있는 변화를 ‘정리’합니다. 그래서 이 직무는 전통적인 필드 영업보다 훨씬 더 구조적이고 컨설팅에 가까운 영업입니다.

필수요건은 왜 이런 사람을 요구하는가

JD에서 공통적으로 요구하는 필수요건의 핵심은 B2B SaaS 영업 경험과 Mid-Market·Enterprise 고객 경험입니다. 그 이유는 명확합니다.

SaaS AE가 상대하는 고객은

사용자(실무자)

관리자(IT/보안)

의사결정자(C-level)

가 동시에 얽혀 있는 구조입니다. 한 명을 설득해서는 계약이 성사되지 않고, 조직 전체의 논리를 맞춰야 하는 영업이기 때문에 복잡한 세일즈 사이클을 경험해 본 사람이 필요합니다. 또한 글로벌 SaaS 특성상 영어 커뮤니케이션 능력은 ‘우대’가 아니라 사실상 업무 언어에 가깝습니다.

우대요건이 말해주는 이 직무의 난이도

우대요건에 자주 등장하는 키워드는 다음과 같습니다.

글로벌 SaaS 기업 경험

협업툴·생산성 소프트웨어 영업 경험

대기업 대상 장기 세일즈 사이클 경험

이는 단순히 스펙을 높이기 위한 조건이 아니라, 이 직무가 다루는 고객의 복잡도를 보여줍니다. AE는 단기 매출보다 장기 사용과 확장을 설계하는 역할이기 때문에 제품을 이해하는 수준을 넘어, 조직과 프로세스를 이해하는 감각이 요구됩니다.

인사이트 – 이 직무를 한 문장으로 정리하면

AE는 “고객에게 새로운 제품을 파는 사람”이 아니라, “이미 쓰고 있는 도구를 회사의 표준으로 만드는 사람”입니다. 디지털의 세계, 특히 사용기반 SaaS에서 영업은 더 이상 말로 설득하는 일이 아닙니다. 제품이 먼저 영업을 하고, AE는 그 결과를 계약으로 정리합니다. 그래서 이 직무는 디지털 영업의 본질을 가장 잘 보여주는 자리이기도 합니다.

4. Account Manager(AM) –협업 및 생산성 도구 (SaaS): “더 잘 쓰게 만들수록, 매출이 커지는 영업”

앞서 살펴본 AE가 ‘처음 사용을 열어주는 사람’이라면, 이제는 디지털의 세계, 특히 사용기반 구조 안에서
이미 사용하고 있는 고객의 성과를 키우는 역할, 즉 AM의 세계를 살펴보겠습니다.

사용기반 모델에서 진짜 매출은 신규 계약이 아니라 기존 고객의 사용 확장과 예산 확대에서 나옵니다. 그래서 AM은 “더 쓰게 만드는 사람”이 아니라 “더 잘 쓰게 만들어 자연스럽게 확장되게 하는 사람”입니다.

이 산업은 무엇인가 – 디지털 광고 & 퍼포먼스 플랫폼의 세계

디지털 광고 산업은 ‘노출을 파는 산업’이 아닙니다. 정확히 말하면, 성과를 예측·측정·확장하는 시스템을 파는 산업입니다. 구글 Ads를 비롯한 글로벌 광고 플랫폼에서 광고는 한 번 집행하고 끝나는 상품이 아닙니다.

집행 → 데이터 발생

데이터 분석 → 전략 수정

성과 개선 → 예산 확대

이 순환이 반복되는 사용기반 구조입니다. 그래서 이 산업에서 영업은 신규 고객을 데려오는 것보다, 이미 쓰고 있는 고객의 성과를 키우는 일에 훨씬 더 큰 비중을 둡니다.

회사는 어떤 곳인가 – 구글코리아 (Google Ads)

구글은 검색·유튜브·디스플레이·앱 생태계를 아우르는 세계 최대의 디지털 광고 플랫폼을 운영하고 있습니다. 구글 Ads의 본질은 단순합니다.

“광고비를 쓰면, 그 결과가 데이터로 남고 그 데이터가 다시 다음 성과를 만든다.”

예를 들어, 프리미엄 반려동물 사료를 판매하는
중견 D2C 브랜드가 이미 검색 광고와 유튜브 광고를 집행하고 있다고 가정해 보겠습니다.

이때 AM의 질문은

“광고비를 더 쓰시겠습니까?”가 아니라

검색 유입 고객과 유튜브 유입 고객 중
장기 재구매율이 더 높은 채널은 어디인가?

유튜브는 직접 전환이 적더라도
검색 구매에 얼마나 간접 기여하고 있는가?

지금 예산 구조가 단기 매출 중심인지,
브랜드 성장까지 고려하고 있는가?입니다.

AM은 계정 데이터를 분석해 전환 경로를 재해석하고, 예산 재배분과 캠페인 구조 변경을 제안합니다.

그 결과, 단순 증액이 아니라 ‘성과가 검증된 후 확장’이라는 결정이 내려집니다.

이미 고객은 광고를 쓰고 있습니다.

그래서 AM은 “써보세요”라고 말하지 않습니다.

“지금 쓰고 있는 광고비가, 가장 좋은 방식으로 쓰이고 있는가?”

이 질문에 데이터로 답을 만드는 사람, 그 역할이 바로 Account Manager입니다.

AM 직무는 실제로 무엇을 하는가

JD에 적힌 AM의 역할을 현장 언어로 풀면 이렇게 정리할 수 있습니다.

“광고 데이터를 읽고, 그 데이터를 근거로 고객의 성장을 설계하는 사람”

구체적으로는,

고객의 비즈니스 목표(KPI) 정의

광고 성과 측정 구조 설계
(Conversion, Incrementality, Media Mix 등)

캠페인 성과 분석 및 개선 전략 제안

예산 재배분·확대 전략 컨설팅

AE, 기술·측정 조직과의 협업

중요한 점은 AM이 직접 ‘판매’를 하지 않는 경우도 많다는 사실입니다. 하지만 결과적으로는 AM의 전략 제안이 광고 집행액 증가로 이어집니다. 그래서 이 직무는 전통적 의미의 ‘관리’가 아니라, 데이터 기반 성장 영업에 가깝습니다.

필수요건은 왜 이런 역량을 요구하는가

구글 Ads AM JD에서 공통적으로 강조되는 필수요건은 다음과 같습니다.

디지털 광고 또는 성과 분석 경험

데이터 분석(SQL 등) 기반 인사이트 도출

고객 커뮤니케이션 능력

글로벌 환경에서의 영어 커뮤니케이션

이유는 명확합니다.

AM은 “이 광고가 좋아요”라고 말하는 사람이 아니라, “이 숫자가 이렇게 움직였고, 그래서 다음에는 이렇게 써야 합니다”를 논리적으로 설명해야 하는 역할이기 때문입니다. 데이터를 읽지 못하면 설득도 불가능합니다.

우대요건이 말해주는 직무의 성격

우대요건에 등장하는 키워드는 이 직무가 어디까지 깊게 들어가는지를 보여줍니다.

A/B 테스트

Incrementality 분석

Media Mix Modeling

고급 분석 기반 컨설팅 경험

이는 AM이 단순한 광고 운영자가 아니라, 고객의 마케팅 의사결정을 함께 내리는 파트너라는 뜻입니다. 그래서 이 직무는 마케팅, 데이터, 영업의 경계에 서 있습니다.

인사이트 – 이 직무를 한 문장으로 정리하면

Account Manager는 광고비를 늘리는 사람이 아니라, 광고 성과를 증명하는 사람입니다. 디지털의 세계에서 영업은 더 이상 “얼마를 쓰게 했는가”가 아니라, “그 사용이 왜 합리적이었는가를 데이터로 설명할 수 있는가”로 평가됩니다.

그래서 구글 Ads AM은 디지털 영업이 어디까지 진화했는지를 보여주는 가장 상징적인 직무 중 하나입니다.

사용이 먼저 시작되고, 데이터가 말을 하며, 영업은 그 데이터를 번역하는 역할을 맡습니다.

5.Customer Success Manager (CSM) –협업 및 생산성 도구 (SaaS): “계약 이후의 시간을 매출로 바꾸는 사람”

앞서 AE가 ‘처음 쓰게 만드는 사람’이고, AM이 ‘더 잘 쓰게 만들어 확장시키는 사람’이었다면, 이제 세 번째 축은 전혀 다른 시간대에서 움직입니다.

계약이 끝난 이후, 제품이 실제 조직 안으로 들어간 이후, 사용이 일상이 되는 과정을 책임지는 역할. 바로 이 지점에서 CSM(Customer Success Manager)라는 역할이 등장합니다.

이 산업은 무엇인가 – B2B 구독형 서비스의 세계

B2B 구독형 서비스 산업에서 영업의 승부는 계약 시점이 아니라, 계약 이후에 갈립니다. 처음 계약은 했지만 잘 쓰이지 않는 서비스 사용은 하지만, 어느 순간 조용히 사라지는 고객, 한 가지 기능만 쓰다 끝나는 고객

이런 고객이 많아질수록 회사의 성장은 멈춥니다.

그래서 이 산업에서는 신규 영업만큼이나 ‘이탈 방지’와 ‘확장’이 중요해집니다. 바로 이 지점에서 CSM(Customer Success Manager)라는 역할이 등장합니다.

회사는 어떤 곳인가 – 위펀

위펀은 기업을 대상으로 간식 구독, 조식 배송, 복지 운영 설루션 등을 제공하는 B2B 서비스 플랫폼입니다.

겉으로 보면 위펀의 비즈니스는 분명 유형의 세계에 발을 딛고 있습니다. 간식과 식음료 같은 실물 상품이 실제로 배송되고, 기업은 이를 직원 복지로 활용합니다.

그래서 15화에서는 위펀의 아웃바운드 특판·제휴 신사업 영업을 국내 온라인 비대면 B2B 영업의 사례로 다뤘습니다. 전화와 온라인 접점을 통해 기업 고객을 발굴하고, 실제 서비스를 판매하는 구조였기 때문입니다.

하지만 계약 이후의 위펀은 조금 다르게 움직입니다. 그 순간부터 위펀은 단순히 ‘간식을 파는 회사’가 아니라, 기업 복지 운영 데이터를 관리하는 서비스에 가까워집니다.

어떤 요일에 주문이 몰리는지
어떤 메뉴가 반복 선택되는지
이용 빈도가 떨어지는 시점은 언제인지

이 모든 정보가 데이터로 남고, 그 데이터를 바탕으로 서비스 구성이 조정됩니다. 이 지점에서 위펀은 유형의 세계에서 디지털의 세계로 넘어옵니다. 고객은 직원 수가 수십 명에서 수천 명에 이르는 기업들이고, 서비스는 매달 반복됩니다.

그래서 이 구조에서 가장 중요한 질문은 이것입니다.

“이 회사가 다음 달에도, 다음 해에도 위펀을 계속 쓸 이유는 무엇인가?”

이 질문에 답하는 역할이 바로 CSM(Customer Success Manager)입니다. 아웃바운드 영업이 고객을 처음 데려오는 역할이라면, CSM은 계약 이후의 사용과 만족을 관리해 관계를 지속시키는 역할입니다. 같은 회사, 같은 서비스이지만 영업이 개입하는 시점과 방식은 전혀 다릅니다.

위펀은 유형의 세계와 디지털의 세계가 어떻게 연결되는지를 보여주는 대표적인 사례입니다.

CSM 직무는 실제로 무엇을 하는가

JD에 적힌 CSM의 역할을 현장 언어로 풀면 이렇게 정리할 수 있습니다.

“고객이 서비스를 계속, 더 많이 쓰게 만들어 매출을 지키고 키우는 사람.”

CSM은 계약 이후의 시간을 관리합니다.
고객사별 이용 패턴을 분석하고(이용 빈도, 주문 주기, 선택 메뉴 등),

이탈 가능성이 보이는 신호를 조기에 감지합니다.

이 과정에서

고객 커뮤니케이션으로 불편과 이슈를 해결하고,
조식·이벤트 패키지 등 교차 판매를 제안하며,
계약 만료 시점에는 재계약을 설계합니다.

모든 과정은 CRM 위에서 관리되고,
사용 데이터와 매출 데이터가 함께 움직입니다.

그래서 CSM은 단순한 ‘문제 해결 담당자’가 아닙니다. 운영과 영업의 경계에서, 데이터를 기반으로 매출을 유지·확장하는 역할입니다. JD에서 강조하는 역량도 이 구조를 그대로 반영합니다.

고객 커뮤니케이션 능력,
데이터 기반 사고,
CRM 활용 역량.

CSM은 “서비스가 좋습니다”라고 말하는 사람이 아니라,
“고객이 이렇게 쓰고 있고, 그래서 이런 확장이 가능합니다”를 숫자로 설명하는 사람입니다.

우대요건에 영업관리 경험, 매출 개선 경험,
고객 데이터 기반 성과 창출 경험이 포함되는 이유도 여기에 있습니다.

CSM은 응대 직무가 아니라,
계약 이후의 시간을 매출로 바꾸는 영업형 포지션이기 때문입니다.

AE · AM · CSM은 무엇이 다른가

사용기반 디지털 영업에서 이 세 역할은 명확히 구분됩니다.

AE (Account Executive) : 이미 쓰고 있는 고객을 계약으로 전환하는 사람
→ “시작을 완성하는 영업”

AM (Account Manager) : 계약된 고객의 사용 효율과 성과를 키우는 사람
→ “성장을 설계하는 영업”

CSM (Customer Success Manager): 고객의 이탈을 막고, 사용 범위를 넓히는 사람
→ “지속을 매출로 바꾸는 영업”

세 역할 모두 ‘사용기반’이지만, 영업이 개입하는 시간대가 다릅니다.

AE는 도입 이전

AM은 성장 구간

CSM은 유지와 확장 구간

인사이트 – 이 직무를 한 문장으로 정리하면

CSM은 고객이 서비스를 떠나지 않게 하는 사람이 아니라, 고객이 더 많이, 더 깊게 쓰도록 만드는 사람입니다. 디지털의 세계에서 영업은 계약서에 사인하는 순간 끝나지 않습니다. 오히려 그때부터 시작됩니다. 위펀의 CSM 포지션은 ‘리텐션이 곧 매출’인 시대에 영업의 정의가 어떻게 확장되었는지를 보여주는 직무입니다.

고객이 성공하면, 그 자체가 영업 성과가 됩니다.

6.DevRel – 클라우드 인프라 및 개발자 도구: “개발자에게 팔리게 만드는 영업” 계약을 따기 전, ‘선택지’를 ‘표준’으로 바꾸는 사람

클라우드 인프라 및 개발자 도구(DevTools)란 무엇인가

앞서 살펴본 사용기반 영업의 첫 번째 축이 협업·생산성 도구(SaaS)였다면,
이제 두 번째 축인 클라우드 인프라 및 DevTools로 넘어갑니다.

협업 도구가 사람의 ‘일하는 방식’을 바꾼다면,
클라우드와 DevTools는 서비스가 어떻게 만들어지고, 배포되고, 운영되는지를 결정합니다.

서버를 어디에 둘 것인지,
트래픽이 몰리면 어떻게 확장할 것인지,
장애를 어떻게 복구할 것인지,
개발자가 어떤 환경에서 코드를 배포할 것인지.

이 영역의 고객은 일반 사용자가 아니라, 개발자와 엔지니어, 기술 의사결정자입니다. 겉으로 보면 무료 크레디트와 문서, 커뮤니티 중심이라 영업이 보이지 않지만, 한 번 채택된 기술은 시스템 전체에 깊이 들어가 쉽게 바꾸기 어렵습니다.

진입은 가볍지만, 이탈은 무거운 구조. 그래서 DevTools 영업은 기능을 파는 일이 아니라 기술 선택의 기준을 설계하는 일에 가깝습니다.

DevTools와 DevRel

DevTools(Developer Tools)는 개발자가 소프트웨어를 만들고, 배포하고, 운영하기 위해 사용하는 기술 도구들입니다. 클라우드, API, SDK, 인프라, CI/CD, 모니터링 시스템 등 개발 환경을 구성하는 모든 기반 기술이 여기에 포함됩니다.

DevRel(Developer Relations)은 이 DevTools를 개발자 생태계 안에 자연스럽게 확산시키는 역할입니다. 기술을 광고처럼 “홍보”하는 것이 아니라, 개발자가 스스로 선택하도록 신뢰와 기준점을 만드는 일입니다.

이제 DevRel이 실제로 무엇을 하는지, 장면으로 보겠습니다.

DevRel이 실제로 하는 일

1) 기술 블로그는 ‘광고’가 아니라 ‘영업 자료’입니다
토스 내부에서 이런 일이 있었다고 해보겠습니다.

트래픽 폭증 구간에서 결제 지연이 발생함 → 큐잉 구조, 캐시 전략, 관측(Observability)을 개선해 해결함

DevRel은 여기서 이렇게 움직입니다.
내부 엔지니어에게서 “진짜 사례”를 발굴합니다.
(무슨 기술을 썼는지가 아니라, 어떤 문제가 있었고 어떻게 해결했는지)
이를 외부 개발자가 이해할 수 있는 언어로 재구성합니다.
핵심 그림/코드 조각/의사결정 포인트 중심으로 압축해
기술 블로그·영상으로 배포합니다.

이 콘텐츠를 본 외부 개발자는 당장 ‘구매’ 하진 않습니다.
하지만 이렇게 생각하기 시작합니다.

“토스는 기술을 진짜로 한다.”
“저 방식은 우리 회사에도 적용할 수 있겠다.”
이게 DevRel의 첫 번째 성과입니다. ‘신뢰’라는 선행 지표를 만들어냅니다.

2) 콘퍼런스(토스 SLASH)는 ‘행사’가 아니라 ‘시장 장악 장치’입니다
토스가 SLASH 같은 콘퍼런스를 연다고 해보겠습니다. 겉으로는 행사지만, DevRel의 목적은 다릅니다.

어떤 주제가 개발자들을 끌어들이는가
어떤 발표가 “토스 방식”을 기준처럼 느끼게 만드는가
발표 이후 커뮤니티에서 어떤 질문과 확산이 생기는가

콘퍼런스는 개발자들의 머릿속에 ‘토스 방식’을 심는 작업입니다.

발표 자료가 스터디로 공유되고,
“우리도 저 방식 도입하자”는 대화가 생기면, B2B 세일즈가 들어갈 때 이미 판이 기울어 있습니다.

3) DevRel은 “개발자 경험(DX)”을 영업 자산으로 만듭니다
DevTools에서 가장 강력한 무기는 기능보다 DX입니다.

DevRel은 커뮤니티에서 이런 신호를 수집합니다.
문서가 불친절하다
예제가 부족하다
온보딩이 어렵다

그리고 이것을 “마케팅 피드백”이 아니라 도입 장벽과 이탈 위험(영업 리스크)으로 번역해 내부를 움직입니다.
문서/예제/온보딩이 개선되면
개발자가 처음 써보고 “된다”는 순간이 늘어나고,
그 순간이 곧 세일즈 파이프라인의 시작점이 됩니다.

결론적으로 DevRel은 계약서에 사인하지 않아도, 기술 선택과 채용 유입을 좌우하는 “선행 영업 성과”를 만들어냅니다.

필수요건은 왜 이런 역량을 요구하는가

JD에서 강조되는 필수요건은
다음 한 가지로 요약됩니다.

“개발자를 이해하는 사람인가”

개발자 경험 개선(DX) 추진 경험

개발자 대상 콘텐츠 기획·운영 경험

커뮤니티 또는 기술 행사 운영 경험

이는 글을 잘 쓰는 능력이 아니라,
기술의 맥락을 정확히 번역할 수 있는 능력을 뜻합니다.

DevRel은 마케터도, 개발자도 아닌 그 중간 지점에 서 있는 직무입니다.

우대요건이 말해주는 이 직무의 깊이

우대요건에
소프트웨어 개발 경험이나
기술 조직 이해가 포함되는 이유도 여기에 있습니다.

DevRel은 기술을 과장해서도 안 되고, 단순화해서도 안 됩니다. 그래서 이 직무는 ‘기술 브랜딩’이지만,

실제로는 기술 신뢰를 쌓는 일에 가깝습니다.

그래서 DevRel은 디지털 영업에서 어떤 의미가 있나

디지털 영업을 시간 순서로 보면 흐름이 보입니다.
선택 이전(Preference) → 선택 시점(Evaluation) → 결정 이후(Procurement) → 사용 이후(Expansion).

AE·AM·CSM이 주로 계약 이후와 사용 확장 구간에서 성과를 만든다면,
DevRel은 그보다 앞단, 개발자의 첫 선택이 이루어지는 지점을 담당합니다.

기술이 도입되기 전,
“이 기술을 믿어도 되는가?”
“한번 붙여볼 만한가?”

라는 질문에 미리 답을 만들어 두는 역할입니다.

그래서 DevRel이 강한 조직은

영업이 들어갈 때 설명 비용이 줄고,
PoC 전환율이 올라가며,
기술 채용과 생태계 확장이 자연스럽게 이어집니다.

클라우드와 DevTools의 승부는 계약서 싸인이 아니라 개발자의 첫 선택에서 이미 상당 부분 결정되기 때문입니다. 한 문장으로 정리하면,

DevRel은 기술이 “팔리도록” 만드는 영업입니다. 직접 계약을 체결하지 않지만, 계약이 체결되기 쉬운 환경을 먼저 설계하는 사람입니다.

7. 설루션 아키텍트(SA)-클라우드 전환 : “기술로 ‘된다’는 확신을 주는 설계형 영업”

이 산업은 무엇인가 – 클라우드 전환(Cloud Migration)의 세계

클라우드 인프라 산업에서 가장 어려운 영업은 “새로운 기술을 써보세요”라고 말하는 일이 아닙니다. 가장 어려운 순간은 바로 이것입니다.

“지금 잘 돌아가고 있는 시스템을 정말 클라우드로 옮겨도 괜찮을까?”

금융, 공공, 대기업 고객일수록 이 질문은 더 무거워집니다.

장애가 나면 누가 책임지는가

보안과 규제는 충족되는가

기존 시스템과의 연계는 가능한가

성능과 비용은 예측 가능한가

이 질문들에 기술적으로 ‘된다’는 확신을 주는 역할, 그것이 바로 설루션 아키텍트(SA)입니다.

회사는 어떤 곳인가 – NHN Cloud

NHN Cloud는 국내 대표적인 클라우드 서비스 제공 기업(CSP)으로, IaaS, PaaS, Application 서비스 전반을 제공합니다.

특히

공공 / 금융/ 엔터프라이즈 같이 보수적이고 요구사항이 까다로운 고객군에서 다수의 구축 레퍼런스를 보유하고 있습니다. 이런 고객을 상대하는 영업에서 말과 조건만으로는 계약이 성사되지 않습니다. 반드시 기술적으로 검증된 설계가 선행되어야 합니다. 그래서 NHN Cloud의 SA는 세일즈 조직과 함께 움직이며 클라우드 영업의 기술적 핵심 축을 담당합니다.

SA 직무는 실제로 무엇을 하는가

JD에 적힌 SA의 역할을 현장 언어로 풀면 이렇게 정리할 수 있습니다.

“이 고객의 시스템은, 이 구조로 클라우드에 올리면 된다”를 설계해 주는 사람

구체적으로는,

고객사의 기존 레거시 인프라 분석

클라우드 전환 가능성 진단(Assessment)

보안·규제 요구사항 반영한 아키텍처 설계

PoC(Proof of Concept) 수행 및 기술 검증

구축 이후 운영 구조 가이드 제시

세일즈·MSP·개발 조직과의 기술 협업

이 과정에서 SA는 기능을 설명하지 않습니다.

구조를 그립니다.

다이어그램, 트래픽 흐름, 장애 시나리오,
비용 구조까지 포함해
“이렇게 하면 실제로 돌아간다”를 보여줍니다.

왜 이것이 ‘영업’인가 – 예로 보면 분명해진다

예를 들어,
금융권 고객이 기존 온프레미스 환경에서 클라우드 전환을 검토한다고 가정해 보겠습니다. 세일즈가 “비용 절감됩니다”, “확장성 좋습니다”라고 말해도 결정은 나지 않습니다.

이때 SA가 등장해 다음을 설계합니다.

업무 시스템별 분리 배치 구조

개인정보·금융 데이터 분리 아키텍처

DR(재해복구) 시나리오

예상 비용 시뮬레이션

이 설계를 보고 고객 내부에서 이런 말이 나옵니다.

“아, 이 구조면 가능하겠네요.”
“리스크는 이 정도로 관리되겠군요.”

그 순간, 영업은 사실상 끝났습니다. 계약을 성사시킨 결정적 요인은 가격이 아니라 SA가 만든 기술적 확신이었기 때문입니다.

필수요건은 왜 이런 역량을 요구하는가

JD에서 요구하는 필수요건을 보면 이 직무의 성격이 분명해집니다.

클라우드 아키텍처 설계 경험

레거시 환경 이해

CSP 환경에서의 SA 또는 컨설팅 경험

이는 SA가 ‘설명하는 사람’이 아니라 실제로 시스템을 설계하고 책임질 수 있는 사람이어야 함을 의미합니다.

DevRel과 SA는 무엇이 다른가

여기서 앞서 살펴본 DevRel과의 차이가 명확해집니다.

DevRel은 선택 이전 단계에서
“이 기술은 믿을 만하다”는 선호와 신뢰를 만듭니다.

SA는 선택 직전 단계에서
“이 구조면 실제로 된다”는 기술적 확신을 만듭니다.

즉,

DevRel이 ‘마음을 움직이는 영업’이라면

SA는 ‘결정을 가능하게 만드는 영업’입니다.

둘 다 DevTools 영업이지만, 개입하는 타이밍과 무기가 완전히 다릅니다.

인사이트 – 이 직무를 한 문장으로 정리하면

설루션 아키텍트는 기술을 파는 사람이 아니라, 기술로 고객의 결정을 설계하는 사람입니다.

클라우드·DevTools의 세계에서 영업은 더 이상 프레젠테이션으로 끝나지 않습니다. 설계도가 곧 영업 자료가 됩니다. NHN Cloud의 SA 포지션은 디지털 영업이 어디까지 ‘기술화’되었는지를 가장 선명하게 보여주는 직무입니다.

8. 마치며: 증기기관은 기계가 아니라 ‘구조’를 바꿨다

18세기 광산에서 시작된 제임스 와트의 제안은 단순히 증기기관을 싸게 빌려주겠다는 거래가 아니었습니다.

그는 기계를 팔지 않았습니다. 대신, 그 기계가 만들어내는 절감된 비용과 효율을 함께 나누자고 제안했습니다.

“소유”가 아니라 “사용”을 기준으로 수익 구조를 다시 설계한 순간, 영업의 문법도 함께 바뀌었습니다.

오늘날 디지털의 세계도 같습니다.

서버를 사는 대신 클라우드를 쓰고,
프로그램을 구매하는 대신 협업툴을 구독하며,
기능을 설명하기보다 사용 데이터를 기반으로 확장합니다.

이 세계에서 영업은
“좋은 제품입니다”라고 말하는 일이 아니라, 고객의 업무 흐름 속에 들어가, 빠져나오기 어려운 사용의 중력을 만드는 일입니다.

AE는 사용을 확장하고,
AM은 사용을 최적화하며,
CSM은 사용을 유지하고,
DevRel은 선택 이전의 토양을 설계합니다.

결국 디지털 영업의 본질은 ‘계약’이 아니라 ‘습관’에 가깝습니다.

와트의 증기기관이 광산에 들어가 그곳의 작업 방식 자체를 바꿔버렸듯,
디지털 서비스는 고객 조직 안에서, 일하는 방식의 일부가 될 때 비로소 성공합니다.

소유의 시대에서 사용의 시대로.
영업은 더 이상 한 번의 설득이 아니라,
지속적인 사용을 설계하는 일이 되었습니다.

다음 화에서는
이 사용 기반 모델을 넘어,
디지털 세계의 두 번째 축인 ‘결정 기반’ 영업의 세계를 살펴보려 합니다.