진단 리포트를 먼저 보내는 아웃바운드는 어떻게 만드나

왜 "영상 잘 봤습니다" 메일이 스팸으로 읽히나

아웃바운드는 내가 먼저 연락하는 영업이다. 상대가 문의를 남겨서 시작되는 인바운드와 반대다. 그중에서도 지난 몇 년 해외에서 크게 유행한 방식이 시그널 기반 아웃바운드다. 시그널이란 상대 회사에서 최근 일어난 관측 가능한 변화를 말한다. 새 채용 공고가 올라왔다, 투자를 받았다, 대표가 유튜브에 영상을 올렸다 같은 것이다. 그 시그널을 감지해서 메일 첫 줄에 언급하며 여는 것이 이 방식의 골자다.

문제는 이 감지와 언급이 자동화하기 너무 쉽다는 데 있다. 유튜브 제목을 긁어와 요약한 뒤 "최근 올리신 영상 인상 깊게 봤습니다"를 붙이고 본론으로 넘어가는 스크립트는 반나절이면 만든다. 그래서 모두가 같은 걸 보내게 됐다. 받는 쪽에서 이 문장은 더 이상 "나를 봤구나"의 증거가 아니다. 자동화 도구를 돌렸다는 증거로 읽힌다.

이 지점을 AB180에서 GTM(고투마켓)을 이끄는 최현종은 인터뷰에서 "이 플레이는 죽었다"고 표현했다. 영업 담당자가 하면 안 되는 것 중 하나가 모두가 하는 행동을 똑같이 하는 것인데, 시그널 언급이 정확히 거기에 해당한다는 것이다. 같은 인터뷰에서 진행자는 월 300통 가까운 협업 제안 메일을 받는데 98%를 버린다고 말한다. 형식이 전부 똑같아서다.

그러면 무엇이 남나. 자동화하기 쉬운 것으로는 차별화가 안 되니, 자동화하되 만드는 데 실제 노력이 들어가는 것을 보내야 한다. 그게 이 글의 주제다.

대신 무엇을 보내나 — 상대가 지금 쓸 수 있는 문서

첫 접촉에 보내는 것은 세 단계로 진화해 왔다. 첫 단계는 좋은 메시지를 보내는 것이다. 두 번째는 도움이 될 만한 자료를 던지는 것이다. 업계 리포트 링크나 참고할 만한 사례가 여기 해당한다. 세 번째가 지금 이야기하는 것으로, 상대가 당장 쓸 수 있는 결과물을 아예 만들어서 보내는 것이다.

앞서 인터뷰에서 최현종이 시연한 것이 이 세 번째다. 해외 구독 앱 창업자를 상대하다 보니 그 사람들이 늘 안고 있는 질문이 "우리 앱에서 무엇부터 고쳐야 하나"였고, 그래서 상대 앱의 스토어 리뷰를 모아 분석한 리포트를 만들어 보냈다. 영상에서 예시로 띄운 화면 기준으로 듀오링고 리뷰 1,000개를 분석했고 그중 118개를 이탈 신호로 분류했으며, iOS와 안드로이드에서 리뷰가 어떻게 갈리는지, 여덟 가지 패턴이 무엇인지, 그래서 무엇부터 손대야 하는지를 담았다.

받는 쪽 입장에서 이 문서는 광고가 아니다. 자기 회사 이야기이고, 자기가 이미 궁금해하던 질문에 대한 답이다. 그래서 끝까지 읽힌다. 여기까지가 이 방식이 작동하는 이유의 전부다.

노리는 결과는 두 가지다. 하나는 당연히 미팅으로 이어지는 것이다. 다른 하나는 지금 당장 사지 않더라도, 나중에 그 문제가 실제로 터졌을 때 나를 먼저 떠올리게 하는 것이다. 최현종은 오히려 후자의 확률이 높다고 말하고, 영업의 핵심을 "고객이 문제가 있을 때 나를 찾게 하는 것"으로 정의한다.

그래서 리포트를 설계할 때 한 가지를 심어 둔다. 다 주지 않는 것이다. "이건 지금 확인할 수 있지만, 이건 우리 데이터가 있어야 보인다"는 대목을 남겨 두면 대화를 열 이유가 생긴다. 도움만 주고 끝나는 자료는 고맙다는 말로 끝난다.

리뷰는 어디서 가져오나 — App Store

App Store 공개 리뷰 피드 주소창과, 페이지 1~10을 돌며 리뷰를 JSONL로 내려받는 curl 반복문을 터미널 목업으로 보여 준다.

여기부터는 인터뷰에 나오지 않는 부분이다. 영상은 완성된 리포트 화면만 보여 줄 뿐 어떻게 모았는지는 말하지 않는다. 아래는 같은 것을 만들기 위해 실제로 쓸 수 있는 경로다.

애플은 앱마다 고객 리뷰 피드를 공개해 두고 있다. 개발자 계정도, API 키도, 로그인도 필요 없다. 주소만 알면 브라우저에서도 열린다. 반환 형식은 JSON이다.

먼저 상대 앱의 숫자 ID가 필요하다. 앱 스토어 웹 페이지 주소 끝의 id 뒤 숫자가 그것인데, 검색 API로도 바로 찾을 수 있다.

앱 ID 찾기

curl -s "https://itunes.apple.com/search?term=duolingo&country=kr&entity=software&limit=5" | jq -r '.results[] | [.trackId, .trackName] | @tsv'

리뷰 500건 내려받기

APP=570060128
for p in $(seq 1 10); do
  curl -s "https://itunes.apple.com/kr/rss/customerreviews/page=$p/id=$APP/sortby=mostrecent/json" | jq -c '.feed.entry[]? | {rating: .["im:rating"].label, version: .["im:version"].label, title: .title.label, body: .content.label}'
done > reviews-kr.jsonl

wc -l reviews-kr.jsonl

500건이라는 상한은 어디서 오나

애플 리뷰 피드의 수집 상한 네 가지 — 한 페이지 50건, 페이지는 10까지, 국가를 바꾸면 또 500건, 정렬은 최신순과 도움순 두 가지.

위 반복문이 1부터 10까지만 도는 데는 이유가 있다. 이 피드는 한 페이지에 리뷰 50건을 주고 페이지는 10까지만 존재한다. 11페이지를 요청하면 JSON이 아니라 에러가 돌아온다. 그래서 한 스토어, 한 국가에서 얻을 수 있는 최대치가 500건이다.

인터뷰에서 말한 1,000건이 어떻게 가능한지도 여기서 설명된다. 주소의 kr을 us나 jp로 바꾸면 그 나라 스토어의 리뷰가 따로 500건씩 나온다. 안드로이드까지 합치면 훨씬 더 쌓인다. 국가를 섞을 때는 한 가지만 주의하면 된다. 나라마다 불만의 종류가 다르므로 국가 구분을 데이터에 남겨 둬야 나중에 "일본에서만 결제 불만이 몰린다" 같은 이야기를 할 수 있다.

정렬 옵션도 바꿀 수 있다. 주소의 sortby=mostrecent를 mosthelpful로 바꾸면 도움이 됐다는 표를 많이 받은 리뷰가 먼저 온다. 최근 버전에서 무엇이 깨졌는지 보려면 최신순이, 오래 묵은 불만을 보려면 도움순이 낫다.

Google Play 쪽은 어떻게 하나

구글은 애플 같은 공개 피드를 열어 두지 않았다. 대신 오픈소스 패키지를 쓴다. google-play-scraper가 사실상 표준이고, 이 글을 쓰는 시점의 버전은 10.1.3이다. 앱 ID는 숫자가 아니라 패키지 이름이다. 플레이 스토어 웹 주소의 id= 뒤에 붙은 값(듀오링고는 com.duolingo)을 그대로 쓴다.

한 번 호출에 최대 200건이 오고, 응답에 다음 페이지를 가리키는 토큰이 함께 온다. 그 토큰을 다시 넣는 식으로 이어 붙이면 된다. 아래 스크립트는 5회 반복해 1,000건을 받는다.

설치

npm init -y
npm i google-play-scraper

reviews-play.mjs

import gplay from "google-play-scraper";

const out = [];
let token;

for (let i = 0; i < 5; i++) {
  const r = await gplay.reviews({
    appId: "com.duolingo",
    lang: "ko",
    country: "kr",
    sort: gplay.sort.NEWEST,
    num: 200,
    nextPaginationToken: token,
  });
  out.push(...r.data);
  token = r.nextPaginationToken;
  if (!token) break;
}

for (const r of out) {
  console.log(JSON.stringify({ rating: r.score, version: r.version, body: r.text }));
}

실행

node reviews-play.mjs > reviews-play.jsonl
wc -l reviews-play.jsonl

500건을 어떻게 리포트로 바꾸나

원본 리뷰 뭉치는 그 자체로는 아무 의미가 없다. 상대도 자기 리뷰를 볼 수 있다. 값이 생기는 지점은 분류다. 축을 미리 정해 두고 그 축으로 전부 나눈 다음, 축마다 몇 건인지와 어느 버전에 몰려 있는지를 세는 것이 리포트의 골격이다.

축은 다섯 개면 충분하다. 아래는 앱 제품에 두루 쓰이는 기본형이고, 상대 업종에 맞게 하나둘 갈아 끼우면 된다.

분류 축	무엇을 담나	왜 중요한가
이탈 신호	지웠다·해지했다·다른 걸 쓴다	매출에 바로 붙는 유일한 축
기능 요청	이게 없어서 불편하다	로드맵 우선순위 근거
결제 불만	비싸다·환불이 안 된다·자동갱신	구독 제품에서 이탈 직전 단계
버그	특정 화면·특정 버전에서 깨진다	버전과 묶으면 원인이 좁혀진다
칭찬	이래서 쓴다	마케팅 문구로 그대로 쓰인다

분류는 사람이 하지 않는다

500건을 손으로 읽으면 하루가 간다. 그러면 이 방식은 확장되지 않고, 확장되지 않으면 아웃바운드가 아니다. 분류는 모델에 맡기고 사람은 축을 정하는 일만 한다.

명령 한 줄이면 된다. 아래는 앞에서 만든 JSONL을 그대로 표준 입력으로 밀어 넣는 형태다.

분류 (터미널)

claude -p "아래는 앱 리뷰 JSONL이다. 각 줄을 이탈신호/기능요청/결제불만/버그/칭찬 중 하나로 분류하라. 출력은 CSV 한 가지만: 분류,평점,버전,원문인용(30자 이내). 판단이 애매하면 기타로 두고 새 분류를 만들지 마라." < reviews-kr.jsonl > classified.csv

축별 집계

cut -d, -f1 classified.csv | sort | uniq -c | sort -rn

리포트에 반드시 남겨야 하는 것 — 원문 인용

분류 결과에 원문 한 조각을 함께 남기라고 지시한 데는 이유가 있다. 요약만 있는 리포트는 검증이 안 되고, 검증이 안 되는 문서는 받는 쪽에서 신뢰하지 않는다. "결제 불만 41건"보다 "결제 불만 41건, 그중 하나는 이런 문장이다"가 훨씬 강하다.

동시에 이것은 지어내기를 막는 장치이기도 하다. 모델은 없는 패턴을 그럴듯하게 만들어 낼 수 있는데, 원문 인용을 강제하면 그 자리에서 드러난다. 인용이 원본 파일에 실제로 있는지 확인하는 일은 grep 한 번으로 끝난다.

리포트의 최종 형태는 대단할 필요가 없다. 한 장짜리 문서에 다음 네 가지만 있으면 된다. 전체 몇 건을 봤는지, 축별 건수와 비율, 버전이나 국가와 엮인 눈에 띄는 패턴 두세 개, 그리고 무엇부터 손대야 하는지에 대한 권고 순서다. 마지막 권고 순서가 상대에게 남는 유일한 실행 항목이다.

메일 본문은 첫 줄만 바꾼다

리포트가 준비되면 메일을 쓴다. 여기서 흔한 실수가 본문 전체를 상대별로 새로 쓰는 것이다. 비용도 시간도 늘어나는데 품질은 오히려 떨어진다. 인터뷰에서 최현종이 말한 실무 규칙은 단순하다. 제목과 인사 다음 첫 줄만 상대에 맞춰 바꾸고, 나머지는 가장 반응이 좋았던 템플릿을 그대로 반복한다.

첫 줄에 들어갈 내용은 리포트에서 뽑는다. 이미 분석을 해 뒀으니 "리뷰 500건 중 118건이 이탈 신호였고, 그중 절반이 최근 두 버전에 몰려 있었습니다" 같은 문장이 자동으로 나온다. 이건 크롤링해서 요약한 유튜브 제목과 질이 다르다. 상대가 확인할 수 있는 자기 데이터이기 때문이다.

받는 쪽이 실제로 그런 대접을 받았는지 여부보다, 그런 느낌을 주는지가 중요하다는 것이 최현종의 표현이다. 다만 여기서 느낌을 만드는 재료가 진짜 데이터라는 점이 앞선 방식과 갈리는 지점이다.

답장이 없어도 다음 대화가 열리는 이유

리포트를 링크로 보내고 열람 여부를 추적한다. 파일 첨부 대신 링크를 쓰는 이유가 이것이다. 상대가 열었는지, 몇 번 봤는지가 남는다.

그러면 답장이 없어도 다음 수가 생긴다. "열어 보신 것 같은데, 이 부분은 더 도와드릴 수 있습니다"는 아무 명분 없이 보내는 재촉 메일과 완전히 다른 물건이다. 상대가 관심을 보였다는 사실 위에 서 있기 때문이다.

같은 구조는 영업 밖에서도 쓰인다. 인터뷰에서 소개된 다른 예가 제품 인터뷰 대상자 모집이다. 우리 제품을 최근에 많이 쓴 사용자 목록을 뽑아 두고, 첫 줄만 그 사람의 사용 기록으로 채워 15분 인터뷰를 요청하는 방식이다. 리포트 대신 사용 기록이 재료로 들어갔을 뿐 뼈대는 같다.

이번 주에 한 건만 만들어 보려면

전부 갖추고 시작하려 하면 시작을 못 한다. 한 번 돌려 보는 데 필요한 최소 절차는 다음과 같다.

첫째, 지금 제안하고 싶은 회사 중 앱이 있는 곳을 하나 고른다. 앱이 없다면 재료를 바꾸면 된다. 공개 채용 공고, 웹사이트 성능, 검색 노출 상태처럼 밖에서 관측 가능한 것이면 무엇이든 같은 자리에 들어간다.

둘째, 위 명령으로 리뷰를 내려받는다. 애플만 해도 500건이니 첫 편은 그것으로 충분하다. 여기까지 10분이면 된다.

셋째, 다섯 축으로 분류하고 축별 건수를 센다. 여기까지 또 10분이다.

넷째, 한 장짜리 문서로 정리한다. 건수, 패턴 두세 개, 권고 순서, 그리고 원문 인용 몇 줄. 여기까지 20분.

다섯째, 메일을 쓴다. 첫 줄은 방금 센 숫자로 채우고 나머지는 평소 쓰던 템플릿 그대로 둔다. 링크로 보내고 열람을 확인한다.

한 편을 끝까지 돌려 보고 나면 다음부터는 대상만 갈아 끼우면 된다. 그 시점부터가 이 방식이 아웃바운드가 되는 지점이다. 처음 한 편이 오래 걸리는 것은 정상이고, 오래 걸린다는 사실 자체가 이 방식이 아직 스팸으로 읽히지 않는 이유이기도 하다.