HubSpot 라이프사이클·딜 단계 설계 — 세 축이 충돌하지 않게

HubSpot을 쓰는 조직에서 가장 흔한 문제는 기능 부족이 아니라 숫자가 맞지 않는 것입니다. 마케팅이 말하는 리드 수와 영업이 말하는 리드 수가 다르고, 파이프라인 금액이 실제 예상과 다릅니다.

원인은 대개 하나입니다. 라이프사이클 스테이지, 리드 상태, 딜 단계 — 세 개의 축이 각각 따로 굴러가고 있습니다.

세 축은 다른 질문에 답하는 속성입니다. 그런데 설계 없이 쓰면 같은 정보를 세 번 다르게 기록하게 되고, 그 순간부터 어느 숫자도 믿을 수 없게 됩니다.

이 글은 세 축의 역할을 구분하고, 서로 충돌하지 않게 설계하는 방법을 정리합니다. 설정 화면 조작법이 아니라 무엇을 정해야 하는지에 관한 글입니다.

1. 세 축은 각각 다른 질문에 답합니다

라이프사이클 스테이지는 '이 사람 또는 이 회사가 우리와의 관계에서 어디까지 왔는가'에 답합니다. 방문자, 리드, MQL, SQL, 기회, 고객, 전도자 같은 값입니다. 연락처와 회사 객체에 붙습니다.

리드 상태는 '이 리드에 대해 지금 무엇이 진행 중인가'에 답합니다. 신규, 접촉 시도, 연결됨, 보류, 부적격 같은 값입니다. 영업 담당자의 작업 상태를 나타냅니다.

딜 단계는 '이 거래가 어디까지 진행됐는가'에 답합니다. 거래 객체에 붙고 금액과 예상 종료일을 동반합니다.

세 축은 상하 관계가 아니라 서로 다른 관점입니다. 그런데 실무에서는 '리드 상태를 딜 단계처럼' 쓰거나 '라이프사이클을 영업 진행도처럼' 쓰는 경우가 많습니다. 이 순간 집계가 깨집니다.

2. 라이프사이클은 되돌아가지 않게 설계합니다

라이프사이클의 기본 원칙은 단방향입니다. 앞으로만 갑니다. 고객이 된 연락처를 다시 MQL로 되돌리면 전환율 집계가 망가집니다.

실무에서 되돌리고 싶어지는 상황은 대개 두 가지입니다. 기존 고객이 다른 제품 문의를 새로 한 경우, 그리고 담당자가 바뀌어 처음부터 다시 접촉하는 경우.

두 경우 모두 라이프사이클을 되돌리는 대신 새 거래를 만드는 것이 맞습니다. 사람의 관계 단계와 거래의 진행 단계는 별개이기 때문입니다.

자동화를 만들 때 이 원칙을 규칙으로 고정하십시오. '현재 단계보다 앞선 값으로만 변경'이라는 조건을 넣으면 실수로 되돌아가는 일을 막을 수 있습니다.

3. MQL과 SQL의 정의는 두 팀이 합의해야 합니다

라이프사이클에서 가장 분쟁이 많은 지점입니다. 마케팅이 MQL로 올린 리드를 영업이 인정하지 않으면 숫자가 두 벌이 됩니다.

해결 방법은 정의를 문서로 만드는 것입니다. MQL 판정 조건, SQL 판정 조건, 그리고 반려 조건과 반려 사유 목록.

반려 조건이 특히 중요합니다. 영업이 리드를 되돌릴 수 있는 경로가 없으면 품질 문제가 데이터에 드러나지 않고 대신 불신으로 쌓입니다.

반려된 리드는 라이프사이클을 되돌리는 대신 별도 속성에 반려 사유를 기록하고 마케팅 재활용 대상으로 분류하십시오. 이렇게 하면 품질 개선의 근거가 남습니다.

4. 리드 상태는 영업의 작업 큐입니다

리드 상태의 목적은 집계가 아니라 작업 관리입니다. 지금 누가 무엇을 해야 하는지를 나타냅니다.

값은 적을수록 좋습니다. 신규, 접촉 시도, 연결됨, 보류, 부적격 정도면 충분합니다. 값이 열 개가 넘으면 담당자마다 다르게 쓰기 시작합니다.

각 값에 '다음 행동'과 '머무를 수 있는 최대 기간'을 정의하십시오. 예를 들어 접촉 시도는 최대 7일, 그 안에 연결되지 않으면 보류 또는 부적격으로 이동.

이 기간 규칙이 있어야 정체된 리드를 자동으로 찾을 수 있습니다. 규칙이 없으면 리드가 '접촉 시도' 상태로 몇 달씩 남아 있고, 파이프라인 상단이 실제보다 커 보입니다.

5. 딜 단계는 통과 조건으로 정의합니다

딜 단계에서 가장 흔한 실수는 단계 이름만 정하고 통과 조건을 정하지 않는 것입니다. 이러면 같은 상황의 거래가 담당자마다 다른 단계에 놓입니다.

각 단계에 '이 단계로 넘어가려면 무엇이 확인되어야 하는가'를 적으십시오. 의사결정자를 만났는가, 예산 범위를 확인했는가, 기술 검토를 통과했는가, 견적을 제출했는가.

조건은 관찰 가능해야 합니다. '관심이 높다'는 조건이 아닙니다. '결정 권한자와 미팅을 완료했다'가 조건입니다.

조건을 정하면 단계별 확률도 의미를 갖습니다. 조건 없이 붙인 확률은 예측이 아니라 희망입니다.

6. 세 축을 연결하는 지점은 두 곳뿐입니다

세 축은 독립적이지만 두 지점에서 만납니다. 이 두 지점만 자동화하면 나머지는 각자 굴러갑니다.

첫 번째 연결점은 딜 생성입니다. 거래가 만들어지면 연관된 연락처와 회사의 라이프사이클을 '기회'로 올립니다. 이때 리드 상태는 더 이상 갱신하지 않습니다. 작업 관리의 주체가 딜로 넘어갔기 때문입니다.

두 번째 연결점은 딜 성사입니다. 거래가 성사되면 라이프사이클을 '고객'으로 올립니다. 패배한 경우에는 라이프사이클을 그대로 두고 딜만 패배로 닫습니다.

이 두 규칙만 자동화로 고정하면 세 축이 충돌하지 않습니다. 그 이상 연결하려 하면 예외 처리가 늘어나고 결국 아무도 신뢰하지 않는 자동화가 됩니다.

7. 파이프라인은 몇 개가 적당한가

파이프라인을 여러 개 만들고 싶어지는 상황이 있습니다. 신규와 갱신, 직판과 채널, 제품군별 구분.

기준은 '단계가 실제로 다른가'입니다. 단계 이름과 통과 조건이 같다면 파이프라인을 나누지 말고 속성으로 구분하십시오. 파이프라인이 늘어나면 리포트가 복잡해지고 비교가 어려워집니다.

반면 갱신처럼 단계 구성 자체가 다른 거래는 별도 파이프라인이 맞습니다. 신규 영업의 단계를 갱신에 억지로 맞추면 양쪽 다 부정확해집니다.

실무 권장은 셋 이하입니다. 넷을 넘어가면 관리 부담이 리포트 가치를 넘어서는 경우가 많습니다.

8. 설계를 검증하는 다섯 질문

설계가 끝났다면 다음 다섯 질문에 답할 수 있어야 합니다. 답이 안 나오면 설계가 덜 된 것입니다.

첫째, 지난달 MQL이 몇 건이고 그중 몇 건이 SQL이 됐는가. 둘째, 각 딜 단계에 평균 며칠 머무는가. 셋째, 14일 이상 정체된 거래가 몇 건인가.

넷째, 패배한 거래의 사유가 몇 퍼센트 기록되어 있는가. 다섯째, 채널별로 계약까지 이어진 비율이 얼마인가.

다섯 질문 중 셋 이상 답이 나오지 않으면 도구 문제가 아니라 설계 문제입니다. 기능을 추가하기 전에 정의부터 다시 보십시오.

9. 이미 운영 중인 조직이 고치는 순서

이미 데이터가 쌓인 상태에서 설계를 바꾸려면 순서가 중요합니다. 한꺼번에 바꾸면 과거 데이터와 비교가 불가능해집니다.

1단계, 현재 상태를 기록합니다. 각 축의 값 분포와 자동화 목록을 뽑아 둡니다. 2단계, 정의 문서를 만듭니다. 세 축의 값과 조건을 문서로 확정합니다.

3단계, 새 정의로 과거 데이터를 분류해 봅니다. 분류가 안 되는 레코드가 많다면 정의가 현실과 맞지 않는 것입니다. 4단계, 전환 시점을 정하고 그 이전·이후를 구분해 리포트합니다.

5단계, 자동화를 교체합니다. 이때 기존 자동화를 먼저 끄고 새 자동화를 켜야 합니다. 둘이 동시에 도는 기간이 있으면 원인 추적이 불가능해집니다.

세 축의 역할 구분

세 축은 상하 관계가 아니라 서로 다른 관점입니다. 연결은 두 지점에서만 하고 그 이상은 자동화하지 마십시오

설계 검증 다섯 질문

다섯 중 셋 이상 답이 안 나오면 기능 추가가 아니라 정의를 다시 봐야 한다는 신호입니다

자주 묻는 질문

Q. 라이프사이클을 되돌려야 하는 상황이 계속 생깁니다.

대부분 사람의 관계 단계와 거래의 진행 단계를 하나로 관리하려 해서 생기는 문제입니다. 기존 고객이 새 제품을 문의하면 라이프사이클은 '고객'으로 두고 새 거래를 만드십시오. 되돌리기 시작하면 전환율 집계가 망가지고 복구할 수 없습니다.

Q. 딜 단계 통과 조건을 정하면 영업이 불편해하지 않나요?

조건이 관찰 가능하고 개수가 적으면 괜찮습니다. 단계당 조건 한두 개면 충분합니다. 불편은 조건의 존재가 아니라 개수와 모호함에서 옵니다. '관심이 높다' 같은 판단형 조건이 들어가면 불만이 커지고 입력도 부정확해집니다.

Q. 파이프라인을 제품군별로 나누고 싶은데 괜찮을까요?

단계 구성이 실제로 다른지 확인하십시오. 단계 이름과 통과 조건이 같다면 파이프라인이 아니라 속성으로 구분하는 편이 낫습니다. 파이프라인을 나누면 제품군 간 비교가 어려워지고 리포트가 복잡해집니다.

Q. 이미 데이터가 많이 쌓였는데 지금 고쳐도 되나요?

고칠 수 있습니다. 다만 순서를 지키십시오. 현재 상태 기록 → 정의 문서 확정 → 과거 데이터로 시범 분류 → 전환 시점 지정 → 자동화 교체. 특히 기존 자동화와 새 자동화가 동시에 도는 기간을 만들지 마십시오. 원인 추적이 불가능해집니다.

이 글이 다루지 않는 것

이 글은 HubSpot에서 라이프사이클 스테이지·리드 상태·딜 단계를 설계하는 원칙을 다룹니다. 설정 화면의 조작 방법, 속성 생성 절차, 개별 자동화의 구현 단계는 다루지 않습니다. 리드 점수 모델과 캠페인 귀속 설계는 별도 주제입니다.

함께 읽으면 좋은 글

이 글은 P3 구축과 운영 시리즈의 일부입니다.

• HubSpot 시트 구조 해부 — 견적이 커지는 이유 (P1)
• MQL SQL 차이와 정의 방법 — 점수표 설계부터 인계 SLA까지 (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
• HubSpot 공식 가격 페이지 및 제품·서비스 카탈로그 (2026.09.12 확인) — hubspot.com/pricing, legal.hubspot.com
• HubSpot 제품 발표 및 개발자 체인지로그 — hubspot.com/company-news, developers.hubspot.com/changelog
• HubSpot Annual ROI Report (자체 집계 · 외부 감사 아님) — hubspot.com/roi
• HubSpot 고객 사례 — hubspot.com/case-studies

본문의 원화 환산은 1 USD = 1,380원, 기준일 2026년 9월 12일을 적용했습니다. 요금과 약관은 변경될 수 있으므로 계약 전 공식 페이지에서 재확인하십시오.