아웃바운드영업 자동화 답글에 왜 회사 이야기가 하나도 없었나?
지식인처럼 도움을 주고 한 줄로 회사를 권하려던 아웃바운드영업 자동화는, 실제로 나간 답글에 회사 이야기가 하나도 없어서 처음부터 다시 봐야 했다.
원래 의도는 분명했다. 스레드에서 우리 서비스가 필요해 보이는 글을 실시간으로 찾아 본문을 읽고, 네이버 지식인 답변처럼 실제로 쓸모 있는 정보를 준 뒤, 마지막 한 줄로만 'SGK 스튜디오에서 더 자세히 도와드릴 수 있다'는 권유를 붙이려 했다. 질문에 전문가가 답하는 국내 서비스인 지식인의 답변 구조를 그대로 흉내 내려는 시도였다.
봐드립니다.
그런데 실제로 나간 답글을 열어 보니 이 짧은 인사말과 되묻는 말 1개가 전부였다. 어떤 서비스를 쓸 수 있는지, 왜 그 서비스가 맞는지 같은 정보는 없었고, 마지막 한 줄로 남기려던 권유 문장도 없었다. 지식인 흉내를 내려던 답글에 지식인다운 부분이 하나도 남아 있지 않은 셈이었다.
처음 의심한 것 — 신원은 다이렉트 메시지 단계에서 밝히기로 한 설계였다
답글이 이렇게 얕다는 걸 확인하고 나서 가장 먼저 떠오른 설명은 단순했다. '이건 문제가 아니라 설계대로다'라는 생각이었다.
이 시스템에는 이미 정해 둔 규칙이 있었다. 공개 답글에서는 회사 신원과 서비스 소개를 밝히지 않고, 상대가 관심을 보여 다이렉트 메시지로 넘어간 다음 단계에서 신원을 밝히기로 한 규칙이었다. 이 규칙만 보면 공개 답글이 짧고 안전한 이유도 흠이 아니라 오히려 의도한 결과로 읽힌다. 정보와 권유는 나중 단계에서 채워질 예정이니, 첫 답글은 가볍게 두는 게 맞다는 논리였다.
이 설명이 그럴듯했던 이유는 또 있었다. 답글 지시문에는 링크를 걸지 말라는 규칙, 다이렉트 메시지로 유도하지 말라는 규칙, 노골적인 영업 문구를 쓰지 말라는 규칙까지 이미 갖춰져 있었다. 공개 자리에서 조심스러운 표현들을 미리 막아 둔 흔적이 뚜렷했으니, 신원을 나중에 밝히기로 한 설계 역시 같은 맥락에서 의도된 설계처럼 보였다.
다이렉트 메시지 단계까지 실제로 몇 건이 갔는지 세어봤다
'나중 단계에서 채워진다'는 설명이 맞는지 확인하는 방법은 하나였다. 실제로 다이렉트 메시지 단계까지 넘어간 대화가 몇 건인지 세어 보면 됐다. 나중 단계가 실제로 일어나고 있다면 그 단계에서 신원과 서비스 정보가 채워지고 있어야 하고, 일어나지 않고 있다면 얘기가 달라진다.
동시에 답글을 쓰는 지시문 자체도 열어 확인했다. 모델에게 실제로 어떤 재료를 주고 답글을 쓰게 하는지, 그리고 그 지시문 안에 '신원을 밝혀라'는 지시가 어디엔가 있는지를 직접 읽었다.
다이렉트 메시지 단계로 넘어간 대화는 0건이었다. 시스템이 가동된 이후 단 한 번도 이 단계가 실제로 일어난 적이 없었다.
가설이 무너진 자리 — 그 단계는 한 번도 열린 적이 없었다
'신원은 나중에 밝힌다'는 설명이 성립하려면 그 나중이 실제로 와야 한다. 그런데 그 나중은 0건이었다. 공개 답글이 짧고 정보가 없다는 사실을 정당화해 줄 뒷단계 자체가 존재하지 않았다는 뜻이다. 첫 가설은 이 지점에서 반증됐다.
지시문을 다시 읽어 보니 알리바이는 두 겹으로 무너져 있었다. 첫째, 나중 단계로 넘어간 대화가 0건이니 정보가 뒤늦게라도 채워질 경로가 없었다. 둘째, 지시문에는 링크·다이렉트 메시지 유도·영업 문구를 막는 규칙만 있었을 뿐, '신원을 밝혀라'거나 '서비스를 소개하라'는 지시는 이른 단계든 늦은 단계든 어디에도 적혀 있지 않았다. 나중에 밝히기로 한 계획은 사람의 머릿속에만 있었고, 지시문에는 옮겨진 적이 없었다.
진짜 원인 — 답글이 가진 재료는 원글과 '1인 개발자' 설정, 딱 둘뿐이었다
나중 단계가 원인이 아니라면 남는 설명은 하나였다. 답글을 쓰는 그 순간에 모델이 손에 쥔 재료 자체가 부족했다는 뜻이다. 지시문을 재료 단위로 나눠 보니 실제로 들어가는 재료는 상대가 올린 원글과, '1인 개발자'라는 화자 설정 두 가지뿐이었다. 회사가 어떤 서비스를 하고, 어떤 상황에 어떤 서비스가 맞는지에 관한 지식은 0건이었다.
없는 정보를 답하라고 시키면 모델이 할 수 있는 선택은 많지 않다. 상대에게 되물어 시간을 벌거나, '봐드립니다'처럼 아무 정보도 담지 않은 문장으로 얼버무리는 두 갈래뿐이다. 실제로 나간 답글이 되묻는 말 1개와 짧은 인사말뿐이었던 이유가 여기서 그대로 설명됐다. 모델이 게을렀던 게 아니라, 처음부터 쥔 재료가 그 두 가지 반응 말고는 다른 선택지를 주지 않았다.
답글을 모델이 직접 원글을 읽고 쓰게 만든 변화 자체는 이번이 처음이 아니었다. 그 전에는 업종·목적·상태처럼 규칙이 미리 정해 둔 몇 가지 항목만 뽑아 고정 문장을 이어 붙이는 방식이었고, 원글을 실제로 읽고 판단하는 역할은 스팸성 글을 걸러내는 다른 절차에만 붙어 있었다. 그 방식을 바꿔 모델이 원글을 직접 읽고 답글을 쓰게 만든 뒤로는 '원글을 읽고 분석해서 답한다'는 애초 목표가 이미 이뤄진 줄 알았다. 그런데 재료를 열어보니 모델이 '읽는' 대상만 원글로 넓어졌을 뿐, '아는' 대상은 여전히 좁았다. 읽는 힘과 아는 지식은 서로 다른 문제였다.
고친 방법 — 지식인 구조를 빌리고 서비스 카드 1장만 넣었다
가장 먼저 없던 재료부터 채웠다. 홈페이지 제작·AI 챗봇·업무 자동화·블로그, 네 서비스마다 지식 카드를 1장씩 만들어 총 4장을 준비했다. 카드에는 회사 문서에 실제로 적힌 사실만 옮기고, 실적이나 가격은 넣지 않았다. 답글 하나를 쓸 때는 상대 글에서 탐지된 서비스에 해당하는 카드 1장만 주입하기로 했다 — 이전에 관련 없는 카드까지 한꺼번에 넣어 답글이 산으로 간 적이 있어서, 이번에는 처음부터 1장으로 좁혔다.
지시문 구조도 다시 짰다. 원글만 던지고 알아서 쓰라고 하는 대신, 지식인 답변이 실제로 따르는 순서를 그대로 옮겼다. 상대가 처한 조건을 먼저 짚고, 바로 답과 그 근거를 제시하고, 지금 할 수 있는 일 1개를 알려준 뒤, 마지막 줄에 정해 둔 권유 문장 '더 구체적으로 필요하시면 SGK 스튜디오에서 도와드릴 수 있어요.'로 끝맺는 순서다.
답글이 이 구조를 실제로 지켰는지는 검사 규칙 여러 개로 가렸다. 회사 이름은 정확히 1회만 등장해야 하고, 답글은 정해 둔 권유 문장으로 끝나야 하며, 원글과의 관련성이 문턱 10퍼센트(말 끝만 다른 경우는 허용)를 넘어야 하고, 대시 기호는 아예 쓰지 못하게 막았다. 다이렉트 메시지 유도는 권유하는 표현만 걸러내고, 되묻는 문장인지는 실제로 물음표가 있는 문장에서만 판정하게 했다. 지시문이 실패해 규칙만으로 초안을 조립하는 예비 경로에도 같은 권유 문장을 붙였다.
고친 뒤 실제 스레드 글 6건으로 시험 운전을 했다. 6건 모두 첫 시도에 통과했고, 그중 4건은 실제 구매 문의였다. 답글에 금지된 대시 기호는 0건이었다. 자동으로 돌리는 회귀 테스트도 21건으로 늘려 돌렸고, 전체 수집기 테스트는 325건이 통과했다(기존에 있던 무관한 실패 1건은 이번 수정과 관계없어 남겨 두었다).
같은 날 뒤집힌 것 — 회사 방침 요약 5개가 아니라 실제 메뉴 9개가 더 있었다
카드 4장을 만들 때 기준으로 삼은 서비스 목록은 회사 방침 문서에 요약돼 있던 다섯 가지뿐이었다. 그런데 그 요약만 보고 만들었지, 실제로 고객이 보는 사이트 메뉴를 직접 열어 대조하지는 않았다. 같은 날 그 사실을 지적받고 실제 메뉴를 하나씩 열어 대조하니, 요약 다섯 가지에 없던 서비스가 9개 더 있었다.
- 검색광고 운영대행
- AI 소프트웨어 개발
- 영업 대행
- 거래명세서 대사
- 소상공인 패키지
- 오피스 업무 자동화
- 노무 관련 AI
- 세무 관련 AI
- 자동매매 트레이드 도구
요약본만 보고 판단한 방식이 이번 결함의 축소판이었다. 답글의 재료가 부족했던 원인은 실제로 있는지 확인하지 않고 옮겨 적은 목록만 본 데 있었는데, 카드를 만드는 과정에서 똑같은 실수가 한 번 더 나온 셈이었다.
빠진 9개 서비스마다 카드를 새로 만들었고, 원글에서 이 서비스들을 알아채는 탐지 규칙도 7개 추가했다. 사이트 메뉴 항목과 서비스, 카드를 잇는 연결표도 새로 만들고, 이 연결이 실제로 끊기면 검사가 잡아내는지 시험했다 — 연결 하나를 일부러 빼 봤더니 검사가 정말로 실패했다. 검사가 장식이 아니라 실제로 작동한다는 걸 이 시험으로 확인했다. 같은 자리에서 오탐 2건도 함께 고쳤다. '거래처'라는 단어를 무조건 막던 규칙은 우리 쪽 거래처를 내세우는 문장만 막도록 좁혔고, '거래명세서'라는 단어만으로 걸던 규칙은 서류 목록을 묻는 정상적인 문의까지 걸러 내고 있어 없앴다.
정정을 마친 뒤 다시 돌린 시험은 실제 글 3건 모두 통과였다. 검색광고 문의, 외주 개발 문의, 거래명세서 대사 답변 예시를 각각 확인했다.
같은 실수를 막는 장치는 무엇을 확인하는가?
이번에 새로 만든 연결 검사는 사이트 메뉴 항목 하나하나가 서비스로, 서비스가 다시 카드로 이어지는지를 확인한다. 메뉴에 새 항목이 생기는데 카드가 따라가지 못하면, 이번처럼 '요약만 보고 만들었다'는 실수가 소리 없이 반복될 수 있기 때문이다. 이 검사가 실제로 작동하는지는 연결 하나를 일부러 끊어 보는 방식으로 확인했다 — 끊었더니 검사가 실제로 실패했다. 평소에 통과하는 이유도 실제로 다 이어져 있기 때문이다.
회귀 테스트가 21건에서 23건으로, 전체 수집기 테스트가 325건에서 337건으로 늘어난 것도 같은 방향이다. 이번에 걸린 문제들을 한 번 고치고 끝내는 대신, 같은 유형의 실수가 다시 나오면 자동으로 잡히도록 케이스 형태로 남겨 뒀다.
아직 못 채운 곳
- 카드를 9장 더 늘렸지만, 14일 동안 모은 스레드 글 9,231건 가운데 이 새 서비스들에 맞는 구매 표현은 검색광고 3건·AI 개발 2건뿐이고 나머지는 0~1건이었다. 지금 모으는 글의 주제 자체가 홈페이지·마케팅 쪽에 쏠려 있어, 카드는 만들어졌지만 실제로 쓰일 일이 드물다.
- 이번 작업 중에 곁다리로 발견한 감지 결함은 이 글에서 고치지 않았다. 스레드 화면의 '팔로우' 버튼 글자가 답글 본문에 섞여 정보성 글로 오인되면서 점수가 깎이는데(-4), 이 감점이 우연히 진짜 판매 글을 걸러내는 역할도 하고 있었다. 14일 표본 9,199건에서 이 글자만 떼면 점수 문턱을 새로 넘는 글이 95건, 그중 자동 발송 대상 기준까지 통과하는 글이 22건이었지만, 한 건씩 읽어 보니 진짜 구매·도움 요청은 5건 안팎이고 나머지는 홍보 글이었다. 후보 35건을 정답 세트로 만들어 판매자 필터의 정확도를 잰 다음에 켜기로 하고, 그 과정과 결과는 [리드 스코어링에서 '팔로우' 글자가 판매자 필터였던 이야기](/engineering/lead-scoring-follow-button-seller-filter)에 따로 정리했다.
회사 신원을 언제, 어떻게 드러낼지는 답글 자동화에서 계속 다시 물어야 하는 질문이다. 지식인 답변을 그대로 흉내 내는 시도만으로는 부족했고, 무엇을 파는지부터 답글을 쓰는 순간에 알려주는 일이 먼저였다. 아웃바운드영업 자동화나 소셜미디어 리드 응대를 검토하고 있다면 상담에서 어떤 재료가 실제로 필요한지부터 확인할 수 있다.