# 이메일 세그먼테이션: 메시지를 바꾸는 차이부터 찾기

정식 URL: https://brew.new/ko/blog/email-segmentation
글쓴이: Philip Sørensen
게시일: 2026-08-07
수정일: 2026-09-29

세그먼트는 하려는 말을 바꿀 때 제 몫을 해요. “설정 완료” 세그먼트는 설정 리마인더를 보내지 않게 막아 준다면 쓸모가 있어요. 아무도 설명하지 못하는 복잡한 점수는 대개 그렇지 않아요.

수신자에게 중요한 차이 몇 가지에서 시작하세요. 복잡한 조건은 그 조건으로 어떤 결정이 나아지는지 짚어 말할 수 있을 때만 더하세요.

## 세그먼테이션의 일반적인 유형

대부분의 세그먼트는 몇 가지 데이터 종류 중 하나를 바탕으로 해요. 아래 예시는 설명을 위한 것이니, 내 데이터가 지원하는 필드와 기간으로 바꿔 쓰세요.

| 유형 | 사용하는 데이터 | 세그먼트 예시 |
| --- | --- | --- |
| 인구통계·기업 정보 | 위치, 직무, 업종, 회사 규모 같은 개인이나 회사에 관한 사실 | 유럽 업무 시간에 열리는 웨비나를 위한 유럽 지역 연락처 |
| 행동 | 제품, 사이트, 이메일에서 한 행동 | 이번 주에 요금 페이지를 봤지만 아직 체험을 시작하지 않은 사람 |
| 라이프사이클 단계 | 구독자, 체험 사용자, 고객, 예전 고객처럼 관계에서 어느 단계에 있는지 | 설정을 완료하지 않은 체험 계정 |
| 참여 | 최근 클릭, 답장, 로그인, 사이트 방문 | 지난 6개월 동안 클릭이나 로그인이 없는 구독자 |
| 구매 이력 | 주문, 요금제, 갱신, 구매한 상품 | 한 번 구매한 뒤로 주문이 없는 고객 |
| 심리 특성·선호 | 관심 주제나 이메일 수신 빈도처럼 본인이 직접 알려 준 관심사와 선택 | 수신 설정 센터에서 제품 업데이트만 선택한 구독자 |

참여 세그먼트에서는 오픈을 조심해서 다루세요. Apple의 Mail Privacy Protection은 누가 읽든 읽지 않든 이메일이 도착하면 이미지를 내려받을 수 있어서, 오픈은 관심의 근거로 약해요. 클릭, 답장, 제품 내 활동이 더 강한 신호예요. 자세한 내용은 [꼭 봐야 할 이메일 지표](/ko/blog/email-metrics-that-matter) 가이드에서 다뤄요.

쓸모 있는 세그먼트는 대부분 여러 유형을 섞어요. “설정을 완료하지 않은 체험 계정”은 라이프사이클 단계와 아직 일어나지 않은 행동을 함께 써요. 어떤 유형으로 부르느냐보다, 규칙 뒤에 있는 데이터가 최신인지가 더 중요해요.

## 현재 상태와 이력 구분하기

현재 상태는 계정이 유료 요금제를 쓰는지, 어떤 제품을 쓰는지 같은 질문에 답해요. 이벤트 이력은 가져오기가 완료되거나 구독이 갱신된 것처럼 이미 일어난 일을 기록해요. 둘 다 유용하지만 서로 대신할 수는 없어요.

지난주의 가입 이벤트로는 그 사람이 오늘 아침에 업그레이드했는지 알 수 없어요. 현재 상태를 담는 필드에는 명확한 관리 주체와 업데이트 경로를 정해 두세요. 이벤트의 타임스탬프와 식별자를 보관해 두면 순서와 재시도를 따져 볼 수 있어요.

첫 라이프사이클 프로그램이라면 의미 있는 작업을 아직 완료하지 않은 신규 사용자, 새 기능을 쓸 수 있는 활성 고객, 활동이 끊긴 고객을 고려해 보세요. 비활성 기준은 임의의 일수가 아니라 제품의 일반적인 사용 주기에 맞춰 정하세요.

## 규칙을 더하기 전에 메시지부터 쓰기

두 세그먼트가 같은 제목, 같은 제안, 같은 다음 단계를 받는다고 해 볼게요. 그렇다면 캠페인을 따로 만들 필요가 없을 수도 있어요. 반대로 요금제가 다른 고객이라면 참여도가 비슷해 보여도 서로 다른 안내가 필요할 수 있어요.

제안된 세그먼트마다 포함 규칙, 제외 대상, 데이터 출처, 그리고 그 세그먼트로 가능해지는 메시지를 적어 두세요. 오디언스를 검토할 때 수신 거부와 발송 제외도 포함하세요. 세그먼트 조건에 맞는다고 해서 마케팅 수신 동의를 무시할 수는 없어요.

다음 제품 마일스톤을 안내할 때는 [웰컴 시퀀스](/ko/blog/welcome-email-sequence)를, 돌아올 만한 설득력 있는 이유가 있을 때는 [윈백 이메일](/ko/blog/win-back-emails)을 쓰세요. 서로 독립된 두 규칙이 우연히 함께 맞았다는 이유로 같은 사람에게 둘 다 보내지는 마세요.

## 비즈니스 모델별 세그먼트 예시

아래 표는 앞에서 말한 형식, 즉 규칙과 그 규칙으로 가능해지는 메시지를 따라요. 그대로 쓰기보다 상황에 맞게 고쳐 쓸 출발점이에요. 기간은 예시로 넣은 값이니, 고객이 얼마나 자주 구매하거나 제품을 쓰는지에 맞춰 정하세요.

### 이커머스

| 세그먼트 | 규칙 | 가능해지는 메시지 |
| --- | --- | --- |
| 장바구니 없이 둘러본 사람 | 지난주에 상품 조회, 장바구니·주문 없음 | 사이즈 가이드나 비슷한 상품 비교처럼 선택을 돕는 내용 |
| 장바구니 이탈자 | 장바구니에 상품 추가, 몇 시간이 지나도 주문 없음 | [장바구니 이탈 이메일 가이드](/ko/blog/abandoned-cart-emails)처럼 배송·반품 정보와 함께 보내는 담아 둔 상품 리마인더 |
| 첫 구매 고객 | 주문 정확히 1건 | 구매한 상품의 설치나 관리 방법, 이어서 관련 상품 |
| 재구매 고객 | 시간을 두고 여러 번 주문 | 자주 사는 카테고리의 재입고 알림과 신상품 |
| 구매가 끊긴 고객 | 평소 주문 간격보다 오래 주문 없음 | 새 상품 라인처럼 돌아올 이유(있는 경우) |

### SaaS

| 세그먼트 | 규칙 | 가능해지는 메시지 |
| --- | --- | --- |
| 체험 중, 미활성화 | 체험 중, 핵심 설정 이벤트 미발생 | 첫 결과를 얻게 해 줄 단 하나의 단계 |
| 체험 중, 활성화됨 | 체험 중, 설정 완료 | 다음에 해 볼 일과 유료 요금제별 차이 |
| 활성 유료 고객 | 유료 요금제, 제품을 꾸준히 사용 | 이미 쓰고 있는 기능과 관련된 새 기능 |
| 사용량 감소 | 유료 요금제, 활동이 해당 계정의 최근 수준보다 크게 낮음 | 갱신 전에 보내는 고객 지원팀의 도움 제안 |
| 해지 | 구독 종료 | 떠난 뒤 달라진 점(관련 있는 변화가 있을 때) |

### B2B

| 세그먼트 | 규칙 | 가능해지는 메시지 |
| --- | --- | --- |
| 신규 리드 | 가이드 다운로드 또는 뉴스레터 가입, 아직 영업 상담 없음 | 선택한 주제에 관한 추가 콘텐츠 |
| 참여도가 높은 리드 | 요금 페이지나 제품 페이지 반복 방문, 또는 이메일 답장 | 담당자와의 상담 제안 또는 제품 안내 |
| 진행 중인 영업 기회 | CRM에서 진행 중인 딜 | 보안 문서처럼 구매 결정에 관여하는 사람들에게 필요한 자료 |
| 신규 고객 | 최근 계약 체결 | 고객사 내 역할별 온보딩 |
| 기존 고객 | 몇 개월째 활성 상태인 고객사 | 고객사에 있는 역할에 맞춘 기능 업데이트와 교육 |

이 세그먼트 중 마케팅이 이메일을 보내도 되는 세그먼트가 어느 것인지 영업팀과 합의하세요. 딜이 한창 진행 중일 때 일반적인 너처링 이메일이 도착하면, 조심스럽게 이어 가던 대화가 꼬일 수 있어요. 업무 인계는 [B2B 이메일 마케팅 가이드](/ko/blog/b2b-email-marketing)에서 다뤄요.

## 대기 후에도 그대로인 이벤트 데이터

Brew의 이벤트 트리거 자동화에서 `payload.activated` 값에 거는 조건은 대기 단계가 지나도 여전히 가입 이벤트를 읽어요. `contact.activated` 값에 거는 조건은 그 노드가 실행되는 시점의 현재 Brew 연락처 필드를 읽어요. 필드를 선언하고 계속 동기화하세요. 이 조건이 애플리케이션 데이터베이스를 직접 조회하지는 않아요.

며칠 뒤에 보내는 리마인더라면 연락처 조건을 대기 단계 뒤에 두세요. 대상 여부가 Brew에 동기화하지 않은 상태에 달려 있다면, 예정된 시점에 애플리케이션이 확인하게 하고 조건에 맞는 사람에게만 새 이벤트를 보내세요. 두 방법 모두 [체험 전환 가이드](/ko/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events)에서 보여 줘요.

이 구분을 지키면 흔한 실수를 막을 수 있어요. 이미 설정을 마친 사람에게 “설정을 마무리하세요”를 보내는 실수 말이에요.

## 실제 기록과 세그먼트 대조하기

게시하기 전에 포함된 연락처와 제외된 연락처를 몇 개씩 직접 살펴보세요. 값이 없는 경우, 수신 거부한 연락처, 최근에 바뀐 계정, 두 번 전달된 이벤트를 테스트하세요.

발송한 뒤에는 그 세그먼트로 개선하려던 성과를 측정하세요. 세그먼트가 많다고 더 나은 프로그램이라는 증거가 되지는 않아요. 누군가에게 관련 없는 이메일이 가지 않게 막아 준 규칙이야말로 그 증거예요.