RevOps 뜻과 시작 방법 — 첫 90일 로드맵과 전담 채용 시점
RevOps는 마케팅·영업·고객관리의 데이터와 프로세스를 한 사람 또는 한 팀이 소유하게 만드는 운영 기능입니다. 조직이기도 하고 프로세스이기도 하지만, 먼저 만들어야 하는 것은 프로세스입니다.
전담 조직부터 만들면 대개 도구 관리자가 한 명 늘어나는 결과가 됩니다. 소유할 프로세스가 정의되지 않았기 때문입니다.
국내 중견기업 규모에서 RevOps를 어떻게 시작하는지, 언제 전담 인력이 필요해지는지 정리했습니다.
Gartner가 2026년 5월 발표한 조사(영업 리더 210명, 2026년 1~2월 수행)에서 AI 도구가 영업사원에게 주당 평균 4.8시간을 돌려주지만, 영업 조직의 72%가 그 시간을 고부가 활동으로 재투자하지 못한다고 답했습니다. 도구가 만든 여유를 성과로 바꾸는 것이 RevOps가 소유하는 영역입니다.
한 문장 정의
RevOps는 매출을 만드는 모든 부서가 같은 데이터와 같은 정의 위에서 일하도록 유지하는 운영 기능입니다.
핵심은 '유지'입니다. 한 번 설계하고 끝나는 일이 아니라 계속 어긋나는 것을 다시 맞추는 일입니다.
왜 이 기능이 생겼나
마케팅·영업·고객지원이 각각 도구를 갖게 되면서 부서 사이의 데이터 인계가 누구의 업무도 아닌 상태가 되었습니다.
마케팅은 리드를 넘겼다고 하고 영업은 받은 적 없다고 하는 상황, 갱신 시점에 영업이 고객 상태를 모르는 상황이 대표적입니다.
이 틈을 소유하는 기능이 RevOps입니다.

프로세스가 먼저인 이유
RevOps가 소유해야 할 것은 네 가지입니다 — 단계 정의, 데이터 정의, 인계 규칙, 리포트 정의.
이 네 가지가 문서로 없으면 전담 인력이 와도 할 일이 도구 설정밖에 없습니다. 도구 설정은 RevOps가 아니라 어드민 업무입니다.
반대로 네 가지가 정의되어 있으면 겸임으로도 상당 부분 운영됩니다.
언제 전담이 필요해지는가
세 가지 신호 중 둘 이상이면 전담을 검토할 시점입니다. 매출 관련 도구가 4개 이상이고 서로 연동되어 있다. 영업 인원이 15명을 넘는다. 월간 리포트를 손으로 만드는 시간이 정기적으로 발생한다.
그 전까지는 마케팅 또는 영업 조직 안의 겸임으로 두되, 권한은 부서를 넘어가게 주어야 합니다. 권한 없는 겸임은 아무것도 바꾸지 못합니다.

국내 중견기업의 현실적 시작점
1단계는 정의 문서화입니다. 단계·속성·인계·리포트 네 가지를 한 장씩, 총 네 장으로 만듭니다.
2단계는 하나의 주간 리포트를 고정하는 것입니다. 매주 같은 형식으로 나오고, 숫자의 출처가 시스템 하나여야 합니다.
3단계는 그 리포트가 틀릴 때 고치는 책임자를 지정하는 것입니다. 이 사람이 사실상 첫 RevOps입니다.
흔한 오해
RevOps는 CRM 관리자가 아닙니다. CRM 관리는 RevOps가 소유한 프로세스를 구현하는 수단 중 하나입니다.
RevOps는 영업 조직 소속이어야 한다는 규칙도 없습니다. 중요한 것은 세 부서의 데이터에 모두 접근하고 정의를 바꿀 권한이 있는가입니다.

겸임으로 시작할 때의 권한 설계
전담 인력 없이 시작하는 조직이 대부분입니다. 이때 결정적인 것은 직급이 아니라 권한 범위입니다.
겸임 담당자에게 반드시 줘야 할 권한은 셋입니다. 첫째, 세 부서의 데이터에 모두 접근할 권한. 둘째, 속성과 파이프라인 정의를 변경할 권한. 셋째, 리포트가 틀렸을 때 원인 부서에 수정을 요청할 권한.
세 번째가 가장 자주 빠집니다. 접근과 변경 권한만 주고 요청 권한을 주지 않으면 담당자는 문제를 발견하고도 고치지 못합니다. 경영진의 공식 위임이 필요한 부분입니다.
첫 90일에 만들어야 할 것
1~30일에는 정의 문서 네 장을 만듭니다. 파이프라인 단계와 통과 조건, 객체별 필수 속성, MQL·SQL 정의와 인계 SLA, 주간 리포트 형식과 데이터 출처.
31~60일에는 주간 리포트 하나를 고정합니다. 매주 같은 형식, 같은 출처, 같은 요일에 나와야 합니다. 이 시기의 목표는 정확도가 아니라 규칙성입니다. 틀린 숫자라도 매주 나오면 무엇이 틀렸는지 알 수 있습니다.
61~90일에는 지표 정확도를 올립니다. 리포트가 틀리는 원인을 하나씩 제거하고, 제거할 때마다 원인이 된 규칙을 문서에 반영합니다. 90일이 지나면 리포트를 신뢰할 수 있는 상태가 됩니다.

전담 채용 시점 판단 — 세 가지 신호
다음 세 신호 중 둘 이상이 나타나면 전담을 검토할 시점입니다.
첫째, 매출 관련 도구가 4개 이상이고 서로 연동되어 있다. 연동이 늘면 장애 지점이 곱으로 늘어나고 겸임으로는 감당하기 어려워집니다.
둘째, 영업 인원이 15명을 넘는다. 이 규모부터는 배정 규칙, 지역 구분, 성과 보상 계산이 시스템 업무가 됩니다.
셋째, 월간 리포트를 손으로 만드는 시간이 정기적으로 발생한다. Gartner 조사에서 72%의 조직이 확보한 시간을 재투자하지 못한다고 답한 이유가 여기에 있습니다 — 확보한 시간이 다른 수작업으로 채워지기 때문입니다.
RevOps가 소유하는 네 가지
|
소유 대상 |
구체적 산출물 |
없을 때 생기는 일 |
|---|---|---|
|
단계 정의 |
파이프라인 단계와 통과 조건 |
파이프라인 금액이 실제와 다름 |
|
데이터 정의 |
필수 속성과 선택 목록 |
세그먼트 분석 불가 |
|
인계 규칙 |
MQL→SQL 기한과 반려 경로 |
리드가 부서 사이에서 사라짐 |
|
리포트 정의 |
주간·월간 리포트 형식과 출처 |
매번 손으로 숫자를 만듦 |
네 가지가 문서로 없으면 전담 인력을 뽑아도 도구 관리자가 됩니다
첫 90일 로드맵
|
기간 |
산출물 |
완료 기준 |
|---|---|---|
|
1~30일 |
정의 문서 4장 |
단계·속성·인계·리포트 정의 확정 및 두 팀 서명 |
|
31~60일 |
주간 리포트 고정 |
같은 형식·같은 출처로 4주 연속 발행 |
|
61~90일 |
지표 정확도 확보 |
리포트 오류 원인 제거 및 규칙 문서 반영 |
|
90일 이후 |
개선 주기 운영 |
분기 1회 정의 재검토 · 지표 기준선 조정 |
31~60일 구간의 목표는 정확도가 아니라 규칙성입니다 — 매주 나와야 무엇이 틀렸는지 알 수 있습니다
자주 묻는 질문
Q. RevOps를 마케팅과 영업 중 어디에 두어야 하나요?
소속보다 권한이 중요합니다. 세 부서 데이터에 접근하고 정의를 바꾸고 수정을 요청할 수 있다면 소속은 어디여도 동작합니다. 다만 한 부서에만 소속되면 그 부서 관점으로 기울기 쉬우므로 경영진 직속이 이상적입니다.
Q. CRM 관리자가 RevOps 아닌가요?
다릅니다. CRM 관리는 정의된 프로세스를 도구에 구현하는 업무이고, RevOps는 그 프로세스 자체를 소유합니다. 관리자만 있고 소유자가 없으면 도구는 잘 돌아가는데 숫자는 의미를 갖지 못합니다.
Q. 작은 조직도 주간 리포트가 필요한가요?
영업 인원이 3명이어도 필요합니다. 형식이 간단하면 됩니다. 열린 딜 목록, 이번 주 움직인 딜, 멈춘 딜 세 가지면 충분합니다. 규칙성이 핵심이지 복잡도가 핵심이 아닙니다.
Q. 90일 로드맵을 같이 진행할 수 있나요?
솔바인드9은 정의 문서 4장 작성부터 리포트 고정, 지표 정확도 확보까지 90일 단위로 함께 진행합니다. 이후에는 내부 담당자가 운영할 수 있도록 규칙 문서와 점검 절차를 이관합니다.
이 글이 다루지 않는 것
조직 규모와 업종에 따라 필요 시점이 다릅니다. 이 글은 영업 인원 10~50명 규모의 국내 B2B 조직을 기준으로 합니다. 전담 인력의 직무 정의서나 채용 기준은 다루지 않았습니다.
함께 읽으면 좋은 글
이 글은 P5 마테크지식 시리즈의 일부입니다.
- Revenue Architecture란 무엇인가 (P5)
- 마케팅·영업·서비스 데이터를 하나로 잇는 4단계 (P3)
- 주간 영업 리스크 리포트를 CRM에서 만드는 법 (P3)
출처
- Forrester, The State Of Business Buying, 2024 (2024.12) — forrester.com/press-newsroom
- 6sense, 2025 B2B Buyer Experience Report (2025.11) — 6sense.com
- Gartner B2B 구매자 조사 (2025.05 발표, 632명) — gartner.com/en/newsroom
- Salesforce, State of Sales 6th·7th Edition (2024.07 / 2026.02) — salesforce.com
본문의 원화 환산은 1 USD = 1,380원, 기준일 2026년 9월 12일을 적용했습니다. 요금과 약관은 변경될 수 있으므로 계약 전 공식 페이지에서 재확인하십시오.