무엇이 문제였나: 답변은 쌓이는데 채택이 거의 없었다
지식인 마케팅에서 답변 채택률을 가른 변수는 답변 문장이 아니라 질문의 나이였습니다. 저희 답변이 단 질문은 작성된 지 중앙값 141일이 지난 질문이었고, 채택률은 2.8%였습니다. 그래서 2026년 9월 15일, 답변 문장을 다듬는 대신 막 올라온 질문을 따로 긁어 오는 두 번째 공급 경로를 만들고, 하루 답변 상한을 7건에서 10건으로 올렸습니다.
네이버 지식인에 답을 달아 회사를 알리는 방식은 오래된 마케팅 수단입니다. 저희도 질문을 찾고, 답변 초안을 쓰고, 품질 검사를 거쳐 올리는 과정을 전부 자동으로 돌리고 있었습니다. 자동화 덕분에 답변 수는 꾸준히 늘었습니다. 그런데 질문자가 “이 답이 도움이 됐다”고 고르는 채택은 거의 일어나지 않았습니다.
채택이 중요한 이유는 둘입니다. 하나는 채택된 답변이 질문 페이지 맨 위로 올라가 검색으로 들어온 사람 눈에 먼저 띈다는 점입니다. 다른 하나는 네이버가 채택 수로 답변자 등급을 매기고, 그 등급이 하루에 올릴 수 있는 답변 수를 정한다는 점입니다. 저희 계정은 채택 15건만 더 받으면 하루 50건까지 답할 수 있는 “중수” 등급이었습니다. 채택이 막혀 있으니 노출과 발행량이 함께 묶여 있던 셈입니다.
비용으로 보면 이렇습니다. 답변 한 건을 만드는 데 드는 검색·초안·검사 비용은 채택이 되든 안 되든 똑같이 듭니다. 채택률 2.8%라면 답변 대부분이 질문자의 선택을 받지 못한 채 묻힌다는 뜻입니다. 같은 비용으로 더 많은 채택을 얻으려면 무엇을 바꿔야 하는지가 이 글의 질문이었습니다.
배경을 조금 더 적으면, 이 시스템은 이미 사람 손을 거의 타지 않는 구조였습니다. 예전에는 초안을 사람이 한 번 승인해야 게시할 수 있었는데, 길이·회사명 노출·금지 문구·외부 링크 네 가지 품질 검사가 그 역할을 이미 하고 있어서 승인 단계를 없앴습니다. 그 결과 처리 단계는 6단계에서 5단계로 줄었습니다. 사람이 검토하지 않는 구조라서, 무엇을 고칠지도 숫자로 정해야 했습니다.
- 질문 찾기: 정해 둔 키워드로 지식인을 검색해 후보 질문을 모은다
- 판정: 이 질문에 답할 수 있는지 고른다
- 초안: 언어 모델이 답변 초안을 쓴다
- 품질 검사: 길이·회사명 노출·금지 문구·외부 링크를 기계로 걸러 낸다
- 게시: 정해진 시각에 자동으로 올린다
처음 잰 숫자: 질문 나이 중앙값 141일, 채택률 2.8%
먼저 저희가 이미 올린 답변을 다시 셌습니다. 측정 방법은 단순합니다. 발행 기록에 남은 질문마다 질문 작성일과 저희 답변 게시일의 간격을 계산하고, 그 답변이 채택됐는지를 함께 적었습니다. 계정 등급과 남은 채택 수는 네이버 지식인 내 정보 화면에 표시되는 “중수까지 남은 채택 답변 15” 문구를 그대로 읽었습니다.
결과는 한쪽으로 크게 기울어 있었습니다. 저희가 답한 질문의 나이는 중앙값 141일이었고, 작성 7일 이내의 질문에 단 답변은 3건뿐이었습니다. 그 3건에서도 채택은 0건이었습니다. 전체 채택률은 2.8%였습니다.
질문을 고르는 단계도 같이 봤습니다. 저희 답변 시스템은 정해 둔 키워드로 지식인을 검색해 후보 질문을 모읍니다(이하 키워드 탐색). 이 방식으로 모이는 작성 7일 이내 질문은 하루 평균 4.4건이었습니다. 하루 상한 7건을 전부 새 질문으로 채우고 싶어도 재료가 모자랐다는 뜻입니다.
이 숫자들은 서로 다른 출처에서 나왔다는 점도 적어 둡니다. 질문 나이와 채택 여부는 저희 발행 기록에서, 등급과 남은 채택 수는 네이버 화면에서, 신선한 질문의 하루 공급량은 키워드 탐색 실행 기록에서 셌습니다. 한 출처만 보면 원인을 다른 곳에 갖다 붙이기 쉬워서, 공급과 결과를 따로 세어 맞대 봤습니다.
비교 기준도 하나 필요했습니다. 지식인에서 활발하게 답변하는 다른 회사(아정당) 계정의 답변을 전수로 모아, 질문이 올라온 뒤 언제 답했는지와 채택 여부를 묶어 봤습니다. 작성 당일 질문에 단 답변의 채택률은 27.0%였고, 8일 이상 지난 질문에 단 답변은 0~1.5%였습니다. 같은 사람이 같은 품질로 써도 질문이 묵으면 채택이 거의 사라졌습니다.
세운 가설: 답변 문장을 더 잘 쓰면 채택이 오른다
처음에 저희가 의심한 쪽은 답변의 품질이었습니다. 답이 길고 일반적이라 질문자가 고르지 않는다, 혹은 질문의 핵심을 비껴간다는 가설이었습니다. 자동으로 쓰는 답변이니 문장이 평평할 수 있다는 걱정은 처음부터 있었고, 그래서 손대기 쉬운 곳도 프롬프트였습니다.
실제로 이 방향의 조치는 이미 한 번 들어가 있었습니다. 답변 초안을 쓰는 모델에게 “최신 질문을 우선하라”는 지시를 넣어 둔 상태였습니다. 이 가설이 맞다면 그 지시만으로도 답변이 붙는 질문의 나이가 짧아지고, 채택률이 조금은 움직였어야 합니다.
하루 발행량도 같이 의심했습니다. 하루 7건이라는 상한이 너무 낮아서 표본 자체가 적고, 그래서 채택이 우연히 적게 잡힌다는 생각이었습니다. 상한을 올리면 채택 수도 비례해서 늘 것이라는 기대가 있었습니다.
두 가설에는 공통점이 있습니다. 둘 다 이미 손에 쥔 설정값을 돌리는 해법이라는 점입니다. 프롬프트 한 줄을 고치거나 숫자 하나를 바꾸면 끝나니 비용이 거의 들지 않습니다. 그래서 먼저 시도할 만했지만, 동시에 시스템이 받아 오는 재료 자체는 건드리지 않는 해법이기도 했습니다.
가설은 어디서 틀렸나?
두 가설 모두 숫자 앞에서 버티지 못했습니다. 프롬프트에 최신 질문 우선 지시가 있었는데도 결과는 중앙값 141일이었습니다. 모델은 받은 후보 가운데서 고를 뿐이고, 후보 자체가 몇 달 묵은 질문이면 아무리 “최신을 고르라”고 해도 고를 새 질문이 없습니다. 문장을 다듬는 일은 이 숫자를 한 칸도 움직이지 못했습니다.
상한을 올리면 채택이 늘 거라는 가설도 같은 이유로 무너졌습니다. 키워드 탐색이 하루에 찾아 주는 7일 이내 질문은 4.4건이었습니다. 상한을 10건으로 올려도 늘어나는 몫은 묵은 질문으로 채워지고, 묵은 질문의 채택률은 비교 계정 기준 0~1.5%입니다. 발행량만 늘리면 채택 없는 답변이 더 쌓일 뿐이었습니다.
공급원을 바꾸는 쉬운 길도 하나 시험했습니다. 네이버 검색 API에 날짜순 정렬을 걸어 신선한 질문을 받아 오는 방법입니다. 그런데 이 방식으로 건지는 신선한 질문은 하루 2.3건이었습니다. 키워드 탐색보다도 적었습니다. 이 결과로 “검색어를 잘 고르면 해결된다”는 기대도 접었습니다.
여기서 원래 가설을 지우지 않고 남겨 두는 이유가 있습니다. 답변 품질을 의심하는 생각은 자연스럽고, 대부분의 팀이 먼저 그쪽을 손봅니다. 저희도 그랬고, 그 시도가 141일이라는 숫자를 바꾸지 못했다는 사실이 다음 판단의 근거가 됐습니다.
돌아보면 비슷한 착각이 전에도 있었습니다. 질문 유입이 갑자기 줄었을 때도 처음엔 답변 쪽을 의심했지만, 실제 원인은 키워드 목록이 이미 접은 서비스를 겨냥하고 있었다는 데 있었습니다. 문제를 결과물 가까이에서 찾는 습관이 있으면, 입구 쪽 결함을 늦게 발견합니다. 이번에도 같은 순서를 밟았습니다.
진짜 원인은 무엇이었나?
원인은 질문을 어디서 받아 오는지, 그리고 얼마나 자주 확인하는지였습니다. 채택은 질문자가 아직 답을 기다리는 동안에만 일어납니다. 그 창은 짧습니다. 비교 계정의 숫자가 보여 주듯 당일에는 27.0%가 채택되고, 일주일이 넘어가면 거의 0이 됩니다.
키워드 탐색은 이 창을 맞추도록 설계한 장치가 아니었습니다. 키워드 탐색은 정해 둔 검색어에 맞는 질문을 모으는 장치라서, 질문이 언제 올라왔는지는 고르는 기준에 들어 있지 않습니다. 결과 목록에는 몇 달 전 질문과 오늘 질문이 함께 섞여 있고, 실측으로 보면 그중 작성 7일 이내 질문은 하루 4.4건뿐이었습니다. 질문이 올라온 직후에 답이 붙으려면, 처음부터 최신 질문만 보는 입구와 하루 여러 번 확인하는 주기가 필요했습니다.
정리하면 문제는 두 곳에 있었습니다. 첫째, 공급원이 신선한 질문을 내주지 못했습니다(하루 4.4건, API로도 2.3건). 둘째, 확인 주기가 질문의 수명보다 길었습니다. 둘 다 프롬프트 바깥, 즉 시스템 구조의 문제였습니다. 그래서 고칠 곳도 구조였습니다.
이 결론은 비용 구조도 바꿉니다. 문장 품질 문제라면 모델이나 프롬프트에 돈과 시간을 더 써야 합니다. 공급원 문제라면 이미 있는 답변 능력을 더 이른 시점의 질문에 갖다 대기만 하면 됩니다. 답변 한 건의 비용은 그대로인데, 그 답이 채택될 가능성이 질문 나이에 따라 크게 달라지기 때문입니다.
조치: 막 올라온 질문만 받는 두 번째 공급 경로
기존 키워드 탐색은 그대로 두고, 그 옆에 새 경로를 하나 더 깔았습니다. 기존 경로는 검색 노출을 노리는 “노출 경로”, 새 경로는 채택을 노리는 “채택 경로”라고 부르겠습니다. 채택 경로는 저희가 그동안 답해 온 하위 분야 14개의 최신 질문 목록 페이지를 로그인 없이 읽고, 작성 24시간 이내이면서 기존 답변이 1개 이하인 질문만 골라 옵니다.
고른 질문은 먼저 “답할 수 있는 질문인가”를 판정합니다. 통과한 질문에만 60~300자의 짧은 직답을 쓰고, 답변 안에 회사 이름은 넣지 않습니다. 막 질문을 올린 사람에게 필요한 것은 긴 설명보다 바로 쓸 수 있는 답이라고 봤기 때문입니다. 기존 노출 경로의 답변은 검색으로 들어올 사람을 위해 더 길게 쓰고, 채택 경로의 답변은 지금 기다리는 한 사람을 위해 짧게 씁니다. 같은 시스템 안에서 독자가 다른 두 종류의 글을 나눠 쓰는 셈입니다. 품질 검사의 길이 상한은 400자로, 질문과의 관련도 하한은 5%와 공통 단어 2개로 잡았습니다.
발행량은 이렇게 바꿨습니다. 하루 총상한을 7건에서 10건으로 올리고, 그중 6건을 채택 경로 몫으로 떼어 뒀습니다. 그리고 네이버가 등급별로 허용하는 하루 상한(초수 30건, 중수 50건, 고수 100건)을 코드가 직접 읽어 천장으로 씁니다. 사람이 설정값을 얼마로 넣든 네이버 상한을 넘지 못하고, 등급이 오르면 사람이 값을 고치지 않아도 천장이 따라 올라갑니다.
이 천장을 코드에 박은 이유는 사람 실수를 막기 위해서입니다. 상한 값은 설정 파일, 환경 변수, 실행 스크립트 여러 곳에서 바뀔 수 있습니다. 어느 한 곳에서 실수로 큰 값을 넣어도 마지막 단계에서 네이버 등급 상한과 비교해 작은 쪽을 쓰게 하면, 계정이 네이버 규칙을 넘는 일은 구조상 생기지 않습니다. 등급 정보는 매일 아침 따로 읽어 와서, 값이 오래되는 문제도 줄였습니다.
확인 주기도 바꿨습니다. 정해진 시각에 자동으로 도는 작업(크론)을 오전 8시부터 밤 10시까지 8개 시각에 배치하고, 매 시각마다 채택 경로를 돌립니다. 키워드 탐색은 오전 8시에 한 번만 돕니다. 계정 등급과 남은 채택 수를 읽는 작업은 매일 오전 7시 10분에 따로 돕니다. 답변 사이 2시간 간격 하한과 총상한 10건은 손대지 않았습니다.
검토하고 버린 선택지도 남깁니다. 모든 분야에 채택 경로를 여는 안은 회사 프로필 이름이 붙은 답변이 본업과 먼 질문에 달리고 사실 오류 위험도 커서 접고, 인접 분야 14개로 좁혔습니다. 답변 간격을 2시간에서 30분으로 줄이는 안과 계정을 여러 개 쓰는 안도 지금은 쓰지 않습니다. 계정 수를 늘리기보다 채택으로 등급을 먼저 올리는 쪽이 낫다고 판단했습니다.
재측정 결과: 첫 사이클은 초안 3건이 전부 버려졌다
새 경로를 처음 실제로 돌린 사이클의 결과는 실패였습니다. 채택 경로가 만든 초안 3건이 3건 모두 품질 검사에서 떨어졌습니다. 길이가 305~313자로 짧은 직답 기준을 넘었고, 질문과의 관련도는 6~7%에 그쳤습니다.
초안을 쓰는 단계를 고친 뒤 같은 날 다시 돌렸습니다. 이번에는 3건 가운데 2건이 검사를 통과했고, 1건을 실제로 게시했습니다. 첫 게시 시각은 9월 15일 밤 10시 31분이었습니다. 숫자는 아직 작지만, 막 올라온 질문에 짧은 답을 다는 경로가 끝까지 이어진다는 사실은 확인했습니다.
수리 과정에서 사고도 하나 있었습니다. 테스트를 돌리는 명령 끝에 출력 일부만 잘라 보여 주는 `tail`을 붙여 두었는데, 이 명령이 pytest의 실패 종료 코드를 삼켰습니다. 그래서 실패한 테스트가 있는 변경이 통과한 것처럼 합쳐졌고, 바로 다음 변경에서 바로잡았습니다. 출력을 줄이는 습관 하나가 검사 전체를 무력하게 만들 수 있다는 교훈이었습니다.
첫 사이클의 실패도 기록으로서 가치가 있었습니다. 300자 이내로 쓰라고 지시했는데 초안이 305~313자로 나왔다는 것은, 모델에게 숫자 제한을 말로 주는 것만으로는 경계를 지키지 못한다는 뜻입니다. 길이와 관련도를 기계가 다시 재는 검사가 없었다면, 기준을 넘은 답변 3건이 그대로 게시될 뻔했습니다. 사람이 검토하지 않는 구조에서는 이 검사가 유일한 방어선입니다.
성패를 가를 기준은 미리 정해 뒀습니다. 판정일은 9월 29일입니다. 채택 경로로 게시한 답변이 40건 이상 쌓이고 채택률이 15% 이상이거나 계정이 중수에 닿으면, 총상한·간격·분야를 더 여는 결정을 올립니다. 채택률이 5%에 못 미치면 채택 경로의 하루 몫을 0으로 내립니다. 지금 이 결정을 올리면 판단할 숫자가 없어 14일 동안 아무도 답하지 못하는 안건이 되기 때문에, 숫자가 쌓인 뒤로 미뤘습니다.
판정은 사람이 감으로 하지 않고 명령 하나로 합니다. 답변 시스템의 깔때기 집계 명령(`python3 scripts/kin_draft.py funnel`)이 경로별로 게시 수와 채택 수를 세어 줍니다. 채택 경로의 게시가 40건에 닿기 전에는 채택률을 말하지 않기로 했습니다. 몇 건짜리 표본에서 나온 비율은 한두 건의 우연으로 크게 흔들리기 때문입니다.
- 채택 경로 게시 40건 이상 + 채택률 15% 이상, 또는 중수 도달 → 총상한·간격·분야를 더 여는 결정을 올린다
- 채택률 5% 미만 → 채택 경로의 하루 몫을 0으로 내린다
- 그 사이 → 설정을 그대로 두고 숫자를 더 모은다
비슷한 일을 이전에도 겪었습니다. 키워드 목록이 실제로 파는 서비스와 어긋나 하루 신규 질문 유입이 15건에서 2건으로 줄었을 때, 키워드를 13개에서 21개로 고치자 다음 사이클 후보가 2건에서 92건으로 늘었습니다. 그때도 원인은 답변 문장이 아니라 질문을 가져오는 입구였습니다. 채택률 분석을 더 깊이 다룬 글은 지식인 채택률 2.8%의 원인에 정리해 뒀습니다.
남는 한계는 무엇인가?
가장 큰 한계는 아직 결과가 없다는 점입니다. 이 글을 쓴 시점의 재측정은 첫날 사이클 두 번뿐이고, 채택률 변화는 9월 29일 판정 전까지 말할 수 없습니다. 첫 사이클 0/3, 재사이클 2/3, 게시 1건은 경로가 작동한다는 증거일 뿐, 채택이 오른다는 증거는 아닙니다.
노출이 늘어나는 부담도 있습니다. 하루 7건이던 발행이 10건으로, 실행 시각이 8개로 늘면서 자동화된 게시가 네이버 눈에 더 자주 띕니다. 제재 신호가 잡히면 하루 상한을 5건으로 자동으로 되돌리는 장치는 기존대로 살아 있습니다. 하지만 그 장치는 신호가 온 뒤에 움직이니, 신호가 오기 전의 위험까지 막지는 못합니다.
판정 기준 자체에도 빈틈이 있습니다. 게시 40건이라는 표본 기준은 채택 경로가 하루 6건 몫을 다 채운다는 가정 위에 서 있습니다. 하위 분야 14개에서 24시간 이내·답변 1개 이하 조건에 맞는 질문이 그만큼 나오지 않으면, 9월 29일까지 표본이 차지 않을 수 있습니다. 그 경우엔 판정을 미루고 공급량부터 다시 셉니다.
채택 경로의 답변에는 회사 프로필 이름이 붙은 채 본업 밖 질문에도 나갑니다. 분야를 인접 14개로 좁혀 위험을 줄였지만, 질문 하나하나가 회사 이미지에 맞는지는 기계 판정에 기대고 있습니다. 비교 기준으로 쓴 27.0%도 다른 회사 계정 하나의 수치라, 저희 분야에서 같은 숫자가 나온다고 장담할 수 없습니다.
마지막으로, 이번 조치는 질문 신선도만 바꾼 실험이 아닙니다. 질문 나이와 함께 답변 길이, 분야, 실행 시각 수, 하루 총상한까지 한꺼번에 바꿨기 때문에 9월 29일에 채택률이 오르더라도 그중 무엇이 효과를 냈는지 깔끔하게 떼어 내기는 어렵습니다. 그래서 판정 뒤에 발행량을 더 열 때는 총상한·간격·분야를 한 번에 하나씩 움직여, 어떤 다이얼이 숫자를 바꾸는지 따로 보려 합니다.
그래도 이 작업에서 얻은 판단 기준은 분명합니다. 자동 답변의 성과가 안 나올 때 문장부터 고치기 전에, 그 답이 붙는 질문이 언제 올라온 것인지부터 세어 보십시오. 지식인 마케팅이나 콘텐츠 자동화 구조를 점검하고 싶다면 상담으로 문의하실 수 있습니다.
작성: SGK Studio 엔지니어링. 이 글의 수치는 2026년 9월 15일 결정 기록과 같은 날의 실행 기록에서 가져왔습니다.