Revenue Architecture 개념 — RevOps·마테크 스택과의 차이

작성자: 솔바인드9 | Sep 14, 2026, 3:34:19 PM

Revenue Architecture는 마케팅·영업·고객관리가 각각 만드는 데이터와 행동을 하나의 매출 경로로 설계하는 일입니다.

기능 단위로 툴을 도입하면 툴의 수만큼 데이터 섬이 생깁니다. Revenue Architecture는 그 반대 방향에서 시작합니다 — 매출이 만들어지는 경로를 먼저 그리고, 그 경로의 각 구간을 어떤 도구가 담당할지 나중에 정합니다.

용어가 새롭게 들리지만 하는 일은 단순합니다. 누가 언제 무엇을 근거로 다음 단계로 넘기는지를 조직 전체에서 하나로 맞추는 것입니다.

Forrester가 2024년 12월 발표한 The State Of Business Buying, 2024에 따르면 하나의 B2B 구매 결정에 평균 13명이 관여하고, 89%의 구매가 둘 이상의 부서에 걸쳐 일어나며, 86%가 진행 중에 한 번 이상 멈춥니다. 부서를 가로지르는 거래를 부서별 도구로 관리할 수 없다는 것이 이 개념이 필요한 이유입니다.

한 문장 정의

Revenue Architecture는 잠재고객의 첫 접점부터 계약, 그리고 갱신까지의 경로를 하나의 데이터 구조와 하나의 책임 체계로 설계하는 작업입니다.

설계 대상은 도구가 아니라 세 가지입니다 — 단계 정의, 데이터 정의, 인계 규칙. 도구는 이 세 가지를 구현하는 수단입니다.

왜 이 개념이 생겼나

2010년대에 마케팅 자동화, CRM, 고객지원, 분석 도구가 각각 독립 제품으로 성장했습니다. 회사는 필요할 때마다 하나씩 도입했고, 그 결과 같은 고객이 도구마다 다른 ID로 존재하게 되었습니다.

광고비를 얼마 써서 매출이 얼마 났는지 답할 수 없는 상태가 여기서 나옵니다. 데이터가 없어서가 아니라, 네 곳에 나뉘어 있고 연결 키가 없어서입니다.

RevOps라는 직무가 생긴 이유도 같습니다. 부서 사이에 낀 이 문제를 누구도 소유하지 않았기 때문입니다.

실무에서는 어떤 모습인가

설계가 끝난 조직에서는 다음 질문에 시스템이 즉시 답합니다. 이번 달 신규 상담 중 어느 채널에서 온 것이 계약까지 갔는가. 제안 단계에서 멈춘 딜의 공통점은 무엇인가. 갱신이 위험한 고객은 누구인가. 이 답이 나오려면 세 가지가 갖춰져야 합니다. 고객을 식별하는 단일 키, 단계 전환 시점의 기록, 그리고 각 단계의 담당 소유자.

기술적으로는 CRM이 중심이 되고 마케팅 도구·ERP·고객지원 도구가 연결되는 형태가 됩니다. 다만 중심을 어디에 둘지는 회사의 매출 구조에 따라 달라집니다.

혼동되는 인접 개념과의 차이

RevOps는 이 구조를 운영하는 직무이자 조직 기능입니다. Revenue Architecture는 그 직무가 다루는 설계 자체입니다. 설계 없이 RevOps 인력을 뽑으면 도구 관리자가 됩니다.

마테크 스택은 도구의 목록입니다. 목록은 구조가 아닙니다. 같은 스택을 쓰는 두 회사의 성과가 다른 이유가 여기에 있습니다.

디지털 전환은 범위가 더 넓은 말입니다. 생산·회계·인사를 포함합니다. Revenue Architecture는 그중 매출 경로에 한정됩니다.

어디서부터 시작하는가

현재 매출이 실제로 어떤 경로로 만들어지는지 그리는 것부터 시작합니다. 이상적인 퍼널이 아니라 실제 경로입니다. 대부분의 회사에서 이 그림은 조직도와 일치하지 않습니다.

그다음 각 구간에서 데이터가 끊기는 지점을 표시합니다. 끊기는 지점이 곧 개선 대상이며, 도구 도입은 그 지점을 잇기 위한 수단으로만 검토합니다.

구매자는 이미 대부분을 결정하고 옵니다

6sense가 2025년 11월 발표한 2025 B2B Buyer Experience Report(북미·EMEA·APAC 구매자 4,000명 이상)에 따르면 구매자는 첫 접촉 시점에 구매 여정의 61%를 이미 진행한 상태입니다. 2024년 조사의 69%보다는 낮아졌지만 여전히 절반을 넘습니다.

같은 조사에서 구매 그룹의 94%가 첫 접촉 전에 선호 벤더 순위를 이미 정해 두었고, 실제로 그 선호 벤더에서 구매한 비율이 77%였습니다. 평균 검토 벤더 수는 5.1개, 구매 주기는 10.1개월이며 APAC은 10.9개월입니다.

영업이 개입하기 전에 승부가 상당 부분 결정된다는 뜻입니다. Revenue Architecture가 마케팅과 영업을 같은 구조 안에 넣어야 한다고 말하는 근거가 여기에 있습니다. 첫 접촉 이전 구간이 측정되지 않으면 그 61%가 통째로 관리 밖에 있게 됩니다.

설계의 세 층 — 단계·데이터·인계

단계 층은 매출 경로를 구간으로 나누고 각 구간의 통과 조건을 정의합니다. 조건은 주관적 판단이 아니라 확인 가능한 사실이어야 합니다. '관심 있어 보임'이 아니라 '예산 담당자와 통화 완료'입니다.

데이터 층은 각 구간에서 반드시 남아야 할 값을 정의합니다. 최소 세트는 고객 식별자, 구간 진입 시각, 구간 이탈 사유입니다. 이 셋이 있으면 구간별 소요일과 전환율, 그리고 이탈 원인이 계산됩니다.

인계 층은 구간과 구간 사이에서 누가 언제까지 무엇을 하는지 정합니다. 세 층 중 가장 자주 빠지고, 빠졌을 때 가장 큰 손실을 냅니다. Forrester 조사에서 86%의 거래가 멈춘다고 한 지점이 대부분 인계 구간입니다.

설계가 끝났는지 판단하는 다섯 가지 질문

다음 다섯 질문에 시스템이 즉시 답하면 설계가 끝난 것입니다. 사람에게 물어봐야 답이 나온다면 아직입니다.

이번 분기 신규 계약의 최초 유입 채널 분포는 어떻게 되는가. 구간별 평균 체류일은 며칠인가. 가장 많이 이탈하는 구간은 어디이고 사유는 무엇인가. 지금 위험한 거래는 몇 건이고 왜 위험한가. 갱신이 임박한 고객 중 이탈 신호가 있는 곳은 어디인가.

다섯 개 중 세 개 이상 답이 나오지 않으면 도구를 더 사는 것보다 구조를 다시 그리는 편이 비용이 적게 듭니다.

세 가지 인접 개념 구분

개념	무엇인가	누가 소유하는가
Revenue Architecture	매출 경로의 단계·데이터·인계 규칙 설계	경영진 + RevOps
RevOps	그 설계를 운영하고 유지하는 기능	전담 조직 또는 겸임
마테크 스택	사용 중인 도구의 목록	각 부서
디지털 전환	전사 업무의 디지털화 (생산·회계 포함)	경영진

용어가 겹쳐 쓰이지만 소유 주체가 다릅니다

B2B 구매 현실 — 인용 가능한 공개 조사

수치	무엇을 측정한 것인가	출처 · 연도
61%	구매자가 첫 접촉 시점에 이미 진행한 구매 여정 비율	6sense, 2025 B2B Buyer Experience Report (2025.11)
13명	하나의 B2B 구매 결정에 관여하는 평균 인원	Forrester, The State Of Business Buying, 2024 (2024.12)
89%	둘 이상의 부서가 관여하는 구매의 비율	Forrester, 동 보고서
86%	진행 중 한 번 이상 멈추는 구매의 비율	Forrester, 동 보고서
10.1개월	평균 B2B 구매 주기 (APAC 10.9개월)	6sense, 2025 보고서
5.1개	평균 검토 벤더 수	6sense, 2025 보고서
74%	구매팀 내부 갈등을 겪는 비율	Gartner (2025.05 발표, 632명 조사)

모든 수치는 발행 기관 공식 자료 기준입니다 · 정리 기준일 2026.09.12

자주 묻는 질문

Q. RevOps 인력을 먼저 뽑아야 하나요?

아닙니다. 소유할 프로세스가 정의되지 않은 상태에서 전담 인력을 뽑으면 도구 관리자가 됩니다. 단계·데이터·인계·리포트 네 가지를 한 장씩 문서로 만든 뒤에 인력을 검토하십시오.

Q. 조직이 작으면 이 설계가 필요 없나요?

20인 미만이면 CRM 하나로 충분한 경우가 많습니다. 다만 단계 정의와 인계 규칙은 규모와 무관하게 필요합니다. 문서 한 장이면 되고, 나중에 규모가 커질 때 다시 만들지 않아도 됩니다.

Q. 기존 도구를 다 바꿔야 하나요?

대부분 바꾸지 않습니다. 설계는 도구 위에서 구현되는 것이지 도구가 결정하는 것이 아닙니다. 솔바인드9의 진단 사례에서도 교체보다 현행 도구 재구성으로 해결되는 비중이 더 큽니다.

Q. 설계부터 구현까지 얼마나 걸리나요?

조직 규모와 도구 수에 따라 다르지만, 정의 문서화에 2~3주, 시스템 구현에 4~8주가 일반적인 범위입니다. 도구가 4개 이상 얽혀 있으면 연동 설계에 추가 시간이 필요합니다.

이 글이 다루지 않는 것

이 글은 개념 정의에 한정합니다. 실제 설계 절차와 산출물 형식은 별도 글에서 다룹니다. 또한 조직 규모가 20인 미만이면 별도 설계 없이 CRM 하나로 충분한 경우가 많습니다.