스레드 자동 답글은 왜 한 건도 나가지 않았나?
스레드 자동 답글이 한 건도 나가지 않은 이유는 답글을 보낼지 판단하는 프로그램에 새 글이 들어오지 않았기 때문입니다. 저희는 이 사실을 바로 알아채지 못했고, 먼저 발송 기준이 너무 깐깐하다고 판단해 기준을 풀었습니다. 기준을 풀어도 숫자가 그대로였을 때 비로소 입력 쪽을 봤습니다. 이 글은 그 순서를 고치지 않고 그대로 적은 기록입니다.
구조부터 설명하겠습니다. 스레드에는 「홈페이지 견적 대략이라도 알고 싶다」, 「행사용품 렌탈 어디서 하나」처럼 무언가를 사려는 사람이 직접 쓴 글이 올라옵니다. 저희 프로그램은 이런 글을 주기적으로 모아 구매 의도 점수를 매기고, 점수가 기준을 넘으면 그 글에 짧은 답글을 답니다. 사람이 하루 종일 피드를 들여다보지 않아도 잠재 고객에게 먼저 말을 거는 장치입니다.
답글 한 건을 보내는 데 드는 돈은 사실상 0원입니다. 그래서 문제는 비용이 아니라 실패율이었습니다. 리드는 잡히는데 답글이 나가지 않으면, 그 장치는 매일 돌면서 아무 일도 하지 않는 셈입니다. 당시 리드 공급 자체가 30일에 2건 수준으로 적었기 때문에, 잡힌 리드를 한 건이라도 놓치는 일은 곧 영업 기회를 통째로 잃는 일이었습니다.
자동 답글에는 반대 방향의 위험도 있습니다. 같은 사람에게 두 번, 세 번 답을 달면 귀찮게 구는 계정이 되고, 고객이 아니라 판매자에게 영업 답글을 달면 엉뚱한 상대에게 말을 거는 꼴이 됩니다. 그래서 발송 직전에 리드를 거르는 게이트를 두었습니다. 이 글의 핵심 질문은 「그 게이트가 일을 너무 많이 하고 있었나, 아니면 게이트까지 오는 입력이 없었나」입니다.
처음 잰 숫자: 14일 동안 리드 8건, 통과 0건
측정은 단순하게 했습니다. 최근 14일 동안 스레드에서 잡힌 리드를 전부 꺼내, 각 리드가 게이트의 어느 조건에서 걸렸는지를 한 건씩 판정했습니다. 결과는 「통과」 또는 「어느 조건에서 보류」 두 가지로만 기록했고, 보류라면 어느 조건이 막았는지를 함께 적었습니다. 그 시점에는 이미 수집 채널을 스레드 하나로 통일하는 정리를 마친 뒤였습니다.
결과는 리드 8건, 게이트 통과 0건이었습니다. 채널을 정리하면 나아질 거라는 기대가 있었지만 숫자는 움직이지 않았습니다. 그때 게이트의 차단 기준은 다섯 가지였습니다. 구매 의도 점수가 7점 미만이면 차단, 글이 올라온 지 24시간이 지나면 차단, 같은 사람에게 1회라도 답한 적이 있으면 차단, 하루 발송은 최대 3건, 한 번 실행할 때 최대 1건이었습니다.
| 기준 | 완화 전 값 | 뜻 |
|---|---|---|
| 최소 점수 | 7점 | 구매 의도 점수가 이보다 낮으면 차단 |
| 신선도 | 24시간 | 글이 올라온 지 이보다 오래되면 차단 |
| 반복 접촉 | 1회부터 차단 | 같은 사람에게 한 번이라도 답했으면 차단 |
| 하루 발송 상한 | 3건 | 판정 코드에 버그가 나도 하루 피해를 이 안에 묶는다 |
| 1회 실행 상한 | 1건 | 한 번 돌 때 보내는 최대 건수 |
앞의 세 줄이 리드를 실제로 걸러 내는 기준이고, 뒤의 두 줄은 오작동에 대비한 상한입니다.
이 표를 보면 기준 하나하나가 「애매하면 막는다」 쪽으로 서 있습니다. 점수 7점은 수집 단계에서 쓰는 기본 기준보다 높았고, 24시간은 하루만 지나도 글을 버린다는 뜻이었습니다. 반복 접촉 1회 차단은 예전에 한 번 답한 사람이 며칠 뒤 완전히 새로운 질문을 올려도 다시는 답하지 않는다는 뜻입니다. 이렇게 보면 8건 중 0건이 이상하지 않아 보였습니다.
세운 가설: 게이트가 너무 보수적으로 설계됐나?
첫 가설은 게이트가 지나치게 보수적이라는 것이었습니다. 각 기준은 처음 정할 때 나름의 근거가 있었습니다. 예를 들어 신선도 24시간은 8월 9일에 잰 실측에서 나왔습니다. 그때 스레드 글에 달리는 댓글이 시간당 1건 안팎이었고, 하루가 지나면 이미 다른 사람이 답을 달았거나 글쓴이가 해결했을 가능성이 크다고 봤습니다.
문제는 그 근거가 리드가 충분히 들어온다는 전제 위에 서 있었다는 점입니다. 리드가 넘칠 때는 신선한 것만 골라도 손해가 없습니다. 하지만 리드 공급이 30일에 2건 수준이라면, 24시간이 지난 글을 버리는 순간 남는 리드가 거의 없습니다. 신선도 기준이 품질 관리가 아니라 병목으로 작동하고 있다고 판단했습니다.
오탐이 아닌 수준에서 모두 발송, 비용 0인데 왜 엄격해야 하나. 두번 세번 귀찮게 하거나 공급자 오탐만 막아라.
대표의 지시도 같은 방향이었습니다. 답글 한 건의 비용이 0원이라면, 게이트가 막아야 할 대상은 두 가지뿐입니다. 같은 사람을 반복해서 귀찮게 하는 경우, 그리고 고객이 아니라 판매자(공급자)를 리드로 잘못 잡는 경우입니다. 나머지 애매한 리드는 막기보다 보내는 편이 기대값이 높다는 논리였습니다.
그래서 가설을 이렇게 정리했습니다. 「게이트를 반복 접촉과 판매자 오탐만 막는 수준으로 풀면, 14일 리드 8건 중 일부가 통과하고 실제 발송이 나간다.」 이 가설은 검증하기 쉬워 보였습니다. 기준을 바꾸고 같은 8건을 다시 판정한 뒤, 실제 운영에서 발송이 나가는지 지켜보면 됐습니다.
가설대로 푼 다섯 가지 기준과 지킨 다섯 가지 기준
기준은 8월 13일에 한꺼번에 바꿨습니다. 최소 점수는 7점에서 5점으로 내렸습니다. 5점은 수집 단계가 쓰는 기본 기준과 같은 값이라, 수집 단계가 리드로 인정한 글은 발송 후보에서도 빠지지 않습니다. 이로써 6점짜리 구매 의도 리드도 발송 후보에 오릅니다.
신선도는 24시간에서 168시간, 즉 7일로 늘렸습니다. 대신 늦게 보낸 답글이 이미 해결된 글에 달리는 문제는 발송 직전의 실시간 확인이 잡도록 맡겼습니다. 답글을 보내기 바로 전에 원글을 다시 열어 이미 끝난 글인지 확인하는 단계입니다. 반복 접촉 차단은 1회에서 2회 이상으로 바꿨습니다. 한 번 답한 사람이 나중에 새 글을 쓰면 그건 새 리드라는 판단입니다.
하루 발송 상한은 3건에서 10건으로, 한 번 실행할 때 보내는 상한은 1건에서 3건으로 올렸습니다. 이 두 상한은 적극적으로 보내기 위한 숫자이면서 동시에 안전장치입니다. 판정 코드에 버그가 생겨 엉뚱한 글에 답글을 달기 시작해도 하루 피해를 10건 안에 묶어 둡니다.
반대로 손대지 않은 기준도 다섯 가지입니다. 판매자 말투를 잡아내는 두 가지 검사, 이미 해결된 글을 거르는 종결 검사, 원글 주소가 있는지 보는 검사, 채널이 스레드인지 보는 검사, 그리고 발송 직전 실시간 확인입니다. 대표가 「공급자 오탐과 반복만 막아라」라고 짚은 축이 바로 여기였기 때문에 그대로 두었습니다.
바꾼 뒤 같은 14일 리드 8건을 다시 판정했습니다. 이번에는 1건이 통과했습니다. 행사용품 렌탈을 찾는 6점짜리 글로, 올라온 지 1일이 지난 리드였습니다. 이전 기준이라면 점수(7점 미만)와 신선도(24시간 초과) 두 군데에서 걸렸을 글입니다. 나머지는 관계 글 2건, 협업 요청 1건, 판매자 1건, 반복 접촉 4건으로 보류됐고, 반복 접촉 4건 중에는 같은 계정에 2회 답한 사례가 있었습니다.
숫자를 더하면 9가 나와 8건보다 하나 많습니다. 원 기록은 사유별 건수만 적고 건별 분해를 남기지 않아, 한 리드가 두 사유에 함께 걸린 것인지 확인할 수 없습니다. 이 글에서는 원 기록의 숫자를 고치지 않고 그대로 둡니다.
회귀 테스트도 다시 돌렸습니다. 기존 테스트 케이스 16개 중 실패는 0건이었습니다. 다만 「이틀 지난 글」 케이스는 기대값을 뒤집었습니다. 예전에는 차단이 정답이었지만 이제는 48시간이 지난 글도 통과해야 합니다. 그리고 168시간 경계에서 정확히 갈리는지 확인하는 케이스를 새로 넣었습니다. 여기까지는 가설이 맞아 보였습니다.
가설이 틀린 지점: 624번 돌려도 통과는 0건이었다
나흘 뒤인 8월 17일, 대표가 「스레드에서 수집하는 리드한테 자동답글 나가는지 확인해봐」라고 요청했습니다. 확인해 보니 실제 발송 성공은 0건이었습니다. 답글 기록 파일에는 2건이 있었지만, 둘 다 8월 9일 초기에 사람이 직접 보낸 건이었습니다. 게이트를 푼 뒤 자동으로 나간 답글은 한 건도 없었습니다.
실행 로그를 세어 보니, 게이트 완화 이후 발송 프로그램은 624회 실행됐고 그 전부가 「게이트 통과 0건」으로 끝났습니다. 더 이상한 점은 보류 사유였습니다. 624회의 보류 사유가 협업 요청 217회, 관계 205회, 판매자 202회, 이 세 가지에 고정돼 있었습니다. 셋을 더하면 정확히 624회입니다.
이 분포가 말해 주는 사실은 하나였습니다. 같은 리드 3명이 4일 동안 계속 반복해서 평가받고 있었습니다. 새 리드가 들어왔다면 보류 사유가 조금이라도 다양해지거나, 적어도 새 기준을 통과하는 글이 한 번은 나왔어야 합니다. 로그 전체를 통틀어 고유 리드는 7명뿐이었습니다.
앞에서 새 기준으로 다시 판정할 때 통과한 6점짜리 렌탈 리드도 실제 실행에서는 한 번도 통과로 찍히지 않았습니다. 원 기록은 이 리드가 실제 실행에서 왜 보이지 않았는지 따로 적지 않았습니다. 보류 사유가 세 가지뿐이었다는 점으로 보면, 실제 실행의 후보 목록에 들어오지 못했다고 보는 편이 자연스럽습니다(추정).
돌아보면 신호는 처음부터 있었습니다. 수집 채널을 통일한 뒤에도 0건, 게이트를 푼 뒤에도 0건이었습니다. 두 번 고쳤는데 숫자가 꿈쩍하지 않았다면 다음 할 일은 게이트를 한 번 더 푸는 일이 아니라, 게이트 앞에 무엇이 도착하고 있는지 보는 일이었습니다. 「통과 0건」은 후보가 나쁘다는 뜻으로 읽기 쉽지만, 이번에는 후보가 들어오지 않는다는 뜻이었습니다. 분모가 며칠째 같은 3명으로 고정돼 있던 점이 그 신호였습니다.
진짜 원인은 무엇이었나? 두 프로그램이 서로 다른 파일을 읽었다
원인은 리드를 읽는 경로가 둘로 갈라져 있었다는 데 있었습니다. 리드를 감시하는 프로그램은 15분마다 돌면서 수집 원본 파일을 직접 읽었습니다. 반면 자동 답글 프로그램은 원본을 직접 보지 않고, 별도의 판정 단계가 점수를 매겨 내놓은 결과 폴더를 읽었습니다. 그 판정 단계는 6시간 간격의 배치 작업이었습니다.
배치 작업에는 조건이 하나 더 붙어 있었습니다. 실행할 때마다 그날 날짜 이름이 붙은 원본 파일만 처리했고, 하루의 마지막 실행은 18시였습니다. 그러면 18시 이후에 감지된 리드는 그날 배치를 탈 기회가 없습니다. 자정이 지나면 날짜가 바뀌어 배치는 새 날짜 파일만 보기 때문에, 전날 저녁에 잡힌 리드는 영영 판정 단계에 들어가지 못합니다.
실제 사례가 있었습니다. 8월 16일 19시 46분, 감시 프로그램이 8점짜리 리드를 잡았습니다. 글은 「홈페이지 제작 잘 하는 곳? 견적 대략으로도 알고싶음」이었습니다. 저희가 하는 일과 정확히 맞는 문의였습니다. 이 리드는 수집 목록 파일에는 분명히 적혀 있었지만, 다음 날 11시까지 자동 답글의 후보 목록에는 없었습니다.
결정적인 증거는 줄 번호였습니다. 8월 17일 원본 파일은 76줄이었고, 이 리드는 그 가운데 70번째 줄에 있었습니다. 같은 날 6시 배치가 내놓은 결과는 69건이었습니다. 배치가 파일을 읽고 지나간 직후에, 정확히 한 줄 뒤로 이 리드가 들어온 셈입니다. 감시 프로그램은 이 리드를 봤고 답글 프로그램은 못 봤습니다.
두 프로그램이 같은 리드를 다르게 본 탓에, 사람이 보기에는 「리드는 잡히는데 답글이 안 나간다」는 증상만 남았습니다. 감시 쪽 화면에서는 리드가 쌓였고, 답글 쪽 로그에는 묵은 3명만 반복해서 찍혔습니다. 두 화면을 나란히 놓고 비교하기 전까지는 게이트가 문제처럼 보일 수밖에 없는 구조였습니다.
조치: 수집 목록 파일을 답글 후보에 직접 연결했다
해결은 배치를 기다리지 않는 쪽으로 했습니다. 감시 프로그램이 리드를 잡을 때마다 한 줄씩 쌓는 수집 목록 파일이 이미 있었습니다. 이 파일을 자동 답글의 후보 공급에 직접 연결해, 배치 결과와 수집 목록을 합친 뒤 게이트로 넘기도록 바꿨습니다. 이제 저녁에 잡힌 리드도 다음 실행에서 바로 후보에 오릅니다.
이 수집 목록 파일은 그전부터 있었지만, 같은 사람에게 두 번 답하지 않도록 막는 중복 차단에만 쓰이고 있었습니다. 기록은 남기고 있었는데 판정에는 연결돼 있지 않았던 셈입니다. 대표가 앞서 「기록은 남기는 데서 끝나지 말고 판정에 연결돼야 한다」고 지적한 적이 있는데, 이번 수정이 그 나머지 절반을 채웠습니다.
연결하면서 세 가지 처리를 함께 넣었습니다.
- 경과일을 지금 기준으로 다시 센다 — 감지 시점의 경과일을 그대로 쓰면 묵은 리드가 영원히 「1일 전」으로 남아 신선도 기준이 무력해진다
- 원글 주소가 없는 항목은 후보로 세지 않는다 — 답글을 달 글을 특정할 수 없기 때문이다
- 주소를 정규화해 배치 판본과 접는다 — 같은 글이 두 경로로 들어와도 후보는 한 번만 세고, 한 번만 답한다
첫 번째 처리는 특히 놓치기 쉬웠습니다. 감지 당시에 「1일 전」으로 적힌 리드를 그대로 후보에 넣으면, 그 숫자는 며칠이 지나도 바뀌지 않습니다. 그러면 7일 신선도 기준을 넣어 둔 의미가 사라집니다. 경과일은 기록된 값이 아니라 발송 시점에 다시 계산해야 하는 값입니다.
재측정 결과: 통과 0건에서 1건, 첫 실전 발송
수정한 뒤 다시 쟀습니다. 잰 숫자는 처음과 같은 두 가지, 게이트 통과 건수와 실제 발송 여부입니다. 발송은 답글이 실제로 게시됐는지와 기록 파일에 남았는지까지 확인했습니다. 게이트 통과는 0건에서 1건으로 바뀌었습니다.
그리고 8월 17일 11시 50분 예약 실행에서 첫 실전 자동 발송이 나갔습니다. 대상은 앞에서 누락됐던 바로 그 8점짜리 홈페이지 제작 문의였습니다. 답글이 실제로 게시됐는지 확인했고, 수집 목록 파일에도 발송 기록이 남았습니다. 게이트 완화 이후 8월 20일까지 첫 실전 발송을 관찰하겠다고 열어 둔 확인 항목도 이것으로 닫혔습니다.
숫자를 정직하게 적으면, 바뀐 것은 0건이 1건이 된 것뿐입니다. 표본이 1건이라 「이제 잘 돈다」고 말할 수는 없습니다. 다만 이 1건은 성격이 분명합니다. 게이트를 두 번 풀어도 통과하지 못하던 상태에서, 입력 경로 하나를 고치자마자 가장 점수가 높은 리드가 바로 통과했습니다. 원인이 게이트가 아니라 공급이었다는 판단을 이 1건이 뒷받침합니다.
남는 한계는 무엇인가?
첫째, 18시 이후 누락 자체는 고치지 않았습니다. 리드 공급은 수집 목록 파일로 우회했지만, 6시간 배치는 여전히 그날 날짜 파일만 처리합니다. 그래서 배치 결과를 쓰는 다른 산출물, 예를 들어 수집한 글을 검증하고 인사이트를 뽑는 분석에는 저녁 데이터가 계속 빠집니다. 이 문제는 별도 작업으로 미뤄 두었습니다.
둘째, 게이트 완화가 실제로 효과가 있었는지는 따로 떼어 잴 수 없습니다. 완화와 공급 문제가 겹쳐 있었기 때문입니다. 첫 실전 발송 리드는 8점이라 옛 기준 7점도 넘는 점수였습니다(신선도 같은 다른 조건에서 옛 기준이 어떻게 판정했을지는 기록이 없습니다). 완화된 기준이 얼마나 많은 리드를 추가로 살렸는지는 공급이 정상화된 뒤 더 쌓인 데이터로 다시 봐야 합니다.
셋째, 공급의 절대량이 작습니다. 리드 공급이 30일에 2건 수준이라면, 경로를 고쳐도 한 달에 나갈 답글은 몇 건에 그칩니다. 이번 수정은 잡힌 리드를 놓치지 않게 했을 뿐, 리드를 더 많이 잡는 문제는 건드리지 않았습니다. 하루 상한 10건, 1회 실행 상한 3건도 지금 공급에서는 닿을 일이 거의 없는 숫자입니다.
넷째, 테스트가 이 결함을 잡지 못했습니다. 게이트 판정을 검사하는 테스트 16개는 전부 통과했지만, 그 테스트는 후보가 이미 손에 있다고 가정하고 판정만 확인했습니다. 후보가 어디서 오고 언제 도착하는지는 아무도 검사하지 않았습니다.
같은 구조를 운영한다면 무엇을 먼저 봐야 하나?
자동 답글이든 자동 메일이든, 「걸러서 보내는」 구조에서 발송이 0건일 때 가장 먼저 볼 숫자는 통과율이 아니라 분모입니다. 게이트에 들어오는 후보가 날마다 바뀌는지, 같은 후보가 반복해서 평가받고 있지는 않은지를 먼저 확인해야 합니다. 이번 경우에는 고유 리드 7명, 반복 평가된 3명이라는 숫자가 이미 답을 쥐고 있었습니다.
두 번째로 볼 곳은 같은 데이터를 읽는 경로의 수입니다. 감시하는 쪽과 실행하는 쪽이 서로 다른 파일, 서로 다른 주기, 서로 다른 날짜 조건으로 데이터를 읽으면, 한쪽 화면은 정상이고 다른 쪽은 텅 빈 상태가 생깁니다. 날짜로 파일을 나누는 배치라면 그날 마지막 실행 이후에 들어온 데이터가 어디로 가는지 꼭 확인해야 합니다.
스레드 운영에서 다른 병목을 다룬 글로는 스레드 프로필 링크 유입과 게시 상한이 있습니다. 리드 수집부터 자동 응대까지 비슷한 구조를 회사에 들이고 싶다면 상담에서 지금 쓰는 도구와 막힌 지점을 알려 주세요.