지식인 하루 답변 한도, 7건을 10건으로 올린 첫날 초안 3건이 전부 버려졌다

지식인 하루 답변 한도를 왜 손대야 했나?

하루 답변 한도를 손댄 이유는 답변을 아무리 꾸준히 올려도 채택이 거의 붙지 않았기 때문입니다. 저희 발행분의 채택률은 2.8%였습니다. 답변 100건을 올리면 채택은 3건이 채 안 붙는다는 뜻이고, 이 채널을 굴리는 비용 대부분이 채택 없는 답변에 들어가고 있었습니다.

지식iN에서 채택은 답변자 등급을 올리는 재료입니다. 등급이 오르면 하루에 달 수 있는 답변 수가 늘어납니다. 2026년 9월 15일에 프로필 화면을 열어 보니 “중수까지 남은 채택 답변 15”라고 적혀 있었습니다. 채택 15건만 더 받으면 중수가 되고, 중수의 하루 답변 한도는 50건입니다.

그러니까 문제는 두 겹이었습니다. 채택이 안 붙으니 등급이 안 오르고, 등급이 안 오르니 하루에 쓸 수 있는 답변 수도 그대로였습니다. 저희가 스스로 정해 둔 하루 발행 상한은 7건이었는데, 이 값을 올릴지 말지보다 먼저 “올린 답변이 왜 채택을 못 받나”를 풀어야 했습니다. 이 진단 과정은 앞선 글 지식인 채택률 2.8%의 원인, 프롬프트가 아니라 질문 나이였다에 따로 적었고, 이 글은 그다음, 원인을 알고 나서 파이프라인을 어떻게 바꿨고 첫날 무엇이 깨졌는지를 다룹니다.

이 파이프라인에는 사람의 검토 단계가 없습니다. 2026년 7월 23일에 사람이 승인하던 대기열을 없애고, 품질 검사를 통과한 초안은 곧바로 발행 대상으로 넘기도록 바꿨습니다. 길이·브랜드·금지 문구·외부 링크를 보는 검사 4종이 이미 걸러 주고 있어서 사람 승인은 지연만 만들었기 때문입니다. 대신 그때부터 잘못된 답변을 막는 장치는 품질 검사 하나뿐입니다. 이 사실이 뒤의 첫 사이클 결과를 읽는 열쇠가 됩니다.

처음 잰 숫자: 질문 나이 중앙값 141일, 채택률 2.8%

측정은 두 갈래로 했습니다. 하나는 같은 시장에서 지식iN 답변을 대량으로 운영하는 회사의 답변을 전수조사한 값이고, 다른 하나는 저희가 올린 답변을 질문 작성 시각 기준으로 다시 센 값입니다. 전수조사에서 채택을 가른 1순위 변수는 질문의 신선도였습니다. 질문이 올라온 당일에 단 답변은 27.0%가 채택을 받았고, 작성 8일이 지난 질문에 단 답변은 0~1.5%에 그쳤습니다.

여기서 “질문 나이”는 저희가 답을 단 시점에 그 질문이 작성된 지 며칠이 지났는지를 말합니다. 채택률은 저희가 올린 답변 가운데 질문자에게 채택된 답변의 비율입니다. 두 값을 같은 발행분에서 함께 뽑아 보면, 채택이 붙은 답과 안 붙은 답이 질문 나이에서 갈리는지 바로 볼 수 있습니다.

저희 쪽 숫자는 이 그림에 그대로 들어맞았습니다. 저희가 답을 단 질문은 작성된 지 중앙값 141일이 지난 글이었습니다. 7일 이내 질문에 단 답변은 3건뿐이었고, 그 3건도 채택은 0건이었습니다. 채택률 2.8%는 답변 문장의 품질이 아니라 질문 나이 하나로 거의 다 설명됐습니다. 141일 지난 질문이라면 채택 버튼을 누를 사람이 이미 화면 앞에 없으리라고 봤습니다(추정).

• 저희 발행분 채택률: 2.8%
• 답을 단 질문의 나이 중앙값: 141일
• 7일 이내 질문에 단 답변: 3건, 그중 채택 0건
• 외부 기준, 당일 답변 채택률: 27.0%
• 외부 기준, 작성 8일 이후 질문 채택률: 0~1.5%
• 중수까지 남은 채택: 15건 (중수 하루 답변 한도 50건)

세운 가설: 지시와 키워드로 신선한 질문을 고를 수 있다

처음 떠올린 가설은 단순했습니다. 질문 나이가 문제라면 초안을 쓰는 AI에게 최신 질문을 고르라고 지시하고, 질문을 찾는 키워드를 넓히면 신선한 질문이 저절로 늘어나리라고 봤습니다. 둘 다 이미 손에 있는 장치라 공수도 적었습니다.

키워드를 넓히는 방법은 이전에 효과를 본 적도 있었습니다. 2026년 7월 26일, 질문 수집 키워드를 13개에서 21개로 늘렸을 때 다음 수집 사이클의 신규 후보가 2건에서 92건으로 46배 늘었습니다. 그 경험 때문에 키워드를 더 손보면 신선한 질문도 늘어나리라고 기대했습니다.

두 번째 후보는 네이버 검색 API였습니다. 키워드로 질문을 검색하되 최신순으로 받아 오면, 작성된 지 얼마 안 된 질문만 추릴 수 있으리라고 봤습니다. 이 가설들이 맞다면 파이프라인 구조는 그대로 두고 프롬프트 몇 줄과 키워드 목록만 고치면 끝날 일이었습니다.

가설은 어디서 틀렸나?

첫 번째 가설은 확인해 보니 이미 시험이 끝나 있었습니다. 초안 프롬프트에는 “최신 질문 우선” 지시가 원래 들어 있었습니다. 그 지시를 단 채로 나온 결과가 질문 나이 중앙값 141일이었습니다. 지시를 더 세게 쓴다고 달라질 이유가 없었습니다. AI는 눈앞에 놓인 후보 가운데서 고를 뿐이고, 후보 자체가 오래된 질문이면 가장 최신을 골라도 오래된 질문입니다.

두 번째 가설도 숫자에서 막혔습니다. 기존 키워드 스카우트가 찾아내는 질문 가운데 7일 이내 질문은 하루 4.4건뿐이었습니다. 키워드 검색 API로 신선한 질문을 받아 오는 방법은 하루 2.3건이 나와서 기각했습니다. 7월에 키워드를 넓혔을 때 늘어난 92건은 양이었지 신선도가 아니었습니다. 키워드 검색은 그 단어가 들어간 질문을 작성 시기와 상관없이 끌어오므로, 후보가 많아질수록 오래된 질문도 같이 많아졌다고 봅니다(추정).

정리하면 가설이 틀린 지점은 “고르는 쪽”을 고치려 했다는 데 있었습니다. 고르는 쪽은 이미 최신을 고르고 있었고, 고를 재료가 없었습니다. 하루 7건을 쓰려는데 7일 이내 질문이 하루 4.4건이면, 상한을 7에서 10으로 올려도 늘어난 3건은 결국 오래된 질문으로 채워집니다.

진짜 원인: 질문을 가져오는 곳과 도는 주기

채택은 질문이 살아 있을 때만 일어납니다. 그리고 질문이 살아 있는 동안 답을 달 수 있느냐는 프롬프트가 아니라 두 가지로 정해집니다. 첫째는 질문을 어디서 가져오느냐(공급원), 둘째는 파이프라인이 얼마나 자주 도느냐(슬롯 주기)입니다.

공급원 쪽부터 보면, 키워드 검색은 구조적으로 신선한 질문을 많이 줄 수 없습니다. 반면 지식iN의 각 하위 분야에는 새 질문이 올라오는 순서대로 보여 주는 최신 질문 목록이 있고, 로그인하지 않아도 열립니다. 여기서 가져오면 작성 시각으로 거르는 일이 처음부터 가능합니다. 저희가 그동안 답해 온 하위 분야가 14개였으니, 이 14개 목록을 공급원으로 쓰면 됐습니다.

거르는 조건도 숫자에서 나왔습니다. 작성 24시간 이내라는 조건은 채택률 27.0%가 나온 “당일 답변” 구간에 맞춘 값입니다. 답변이 1개 이하라는 조건은 아직 답이 거의 달리지 않은 질문만 고르려는 장치입니다. 답이 이미 여러 개 달린 질문은 질문자가 그중 하나를 고를 가능성이 높아서, 늦게 단 답이 채택을 가져갈 여지가 적다고 봤습니다(추정: 이 조건의 효과를 따로 잰 숫자는 아직 없습니다).

주기 쪽은 이렇습니다. 당일 질문의 채택률이 높다는 말은 질문이 올라온 뒤 몇 시간 안에 답이 붙어야 한다는 뜻입니다. 하루에 한두 번만 도는 파이프라인은 아무리 좋은 공급원을 붙여도 그사이 올라온 질문을 반나절 늦게 봅니다. 그래서 공급원을 바꾸는 일과 크론 슬롯을 하루 여러 번으로 쪼개는 일은 한 묶음이어야 했습니다.

채택은 질문이 살아 있을 때만 일어나고 그건 공급원과 슬롯 주기의 문제지 프롬프트 문제가 아니다. ("최신 우선" 지시는 이미 있었고 결과가 141일이었다.)

여기에 하나가 더 얹혔습니다. 하루 발행 상한을 올리려면 네이버가 등급별로 정한 하루 답변 한도를 넘지 않는다는 보장이 필요했습니다. 그런데 그 한도는 코드 어디에도 없었습니다. 등급이 오르면 사람이 값을 기억해서 고쳐야 하는 구조였고, 누가 상한을 잘못 넣으면 네이버 한도를 넘는 시도를 막을 장치가 없었습니다.

어떻게 고쳤나: 두 트랙, 하루 10건, 등급 상한을 천장으로

조치는 다섯 가지였고, 모두 2026년 9월 15일에 PR 세 개(#612, #613, #614)로 들어갔습니다. 핵심은 기존 경로를 건드리지 않고 옆에 당일 질문 전용 경로를 하나 더 놓은 것입니다.

• 채택 트랙 신설: 새 수집 스크립트가 하위 분야 14개의 최신 질문 목록(비로그인 HTML)에서 작성 24시간 이내이고 답변이 1개 이하인 질문만 긁어 옵니다. 초안 스크립트는 이 질문에 답할 수 있는지 먼저 판정한 뒤, 60~300자 길이에 브랜드 언급 0회인 짧은 직답을 씁니다. 품질 검사의 글자 수 상한은 400자, 관련성 기준은 5%에 겹치는 단어 2개 이상입니다
• 노출 트랙 유지: 기존 키워드 파이프라인은 그대로 둡니다. 오래된 질문이라도 검색 노출용 답변은 여전히 쓸모가 있기 때문입니다
• 하루 발행 상한 7건→10건, 그중 채택 트랙 몫은 6건까지. 여기에 네이버 등급 상한(초수 30, 중수 50, 고수 100)을 코드 천장으로 둡니다
• 크론을 08~22시 8슬롯으로 교체합니다. 매 슬롯 채택 트랙이 돌고, 키워드 스카우트는 08시 슬롯에서만 돕니다. 프로필 등급을 읽는 조회 스크립트는 매일 07:10에 돕니다
• 2시간 간격 하한, 채택 트랙의 분야 제한, 총상한 10건은 지금 건드리지 않고 2026년 9월 29일 판정 수치를 보고 다시 정합니다

등급 상한을 코드 천장으로 둔 이유는 두 가지입니다. 첫째, 매일 아침 프로필에서 등급을 읽어 오므로 등급이 올라도 사람이 값을 고칠 일이 없습니다. 둘째, 누가 어떤 상한 값을 넣어도 실제 발행 수는 등급 한도를 넘지 못합니다. 설정 값과 플랫폼 한도 가운데 작은 쪽이 항상 이깁니다. 반대로 발행 중 제재 신호가 잡히면 하루 상한을 5건으로 자동으로 되돌리는 장치는 이전부터 있었고, 그 구조는 네이버 계정 제재 자동 원복 글에 적었습니다.

세 숫자의 관계를 정리하면 이렇습니다. 맨 위에 네이버가 정한 등급 한도가 있고(지금 등급인 초수는 하루 30건), 그 아래에 저희가 스스로 정한 하루 상한 10건이 있고, 다시 그 안에서 채택 트랙이 쓸 수 있는 몫이 6건입니다. 초수 한도가 30건인데도 자체 상한을 10건에 묶어 둔 이유는, 하루 상한을 단계적으로 올리는 계획을 미리 세워 두었고 이번이 그 두 번째 단계였기 때문입니다. 한 번에 한도 끝까지 올리면 제재 신호가 왔을 때 어느 단계에서 문제가 생겼는지 가를 수 없습니다.

기각한 대안도 남깁니다. 키워드 API로 신선한 질문을 받는 방법은 하루 2.3건이라 버렸습니다. 모든 분야로 채택 트랙을 여는 방법은 답변에 회사 이름이 붙은 프로필명이 따라가고 모르는 분야에서 사실 오류를 낼 위험이 있어 버렸습니다. 게시 간격을 2시간에서 30분으로 바로 줄이는 방법은 대표가 정한 하한이라 판정 뒤로 미뤘습니다. 계정을 여러 개 쓰는 방법은 방안만 검토하고, 등급을 먼저 올리는 쪽을 택했습니다.

발행량 조정을 판정일 뒤로 미룬 데도 이유가 있습니다. 지금 “상한을 더 올릴까”를 결정 요청으로 올리면 판단할 숫자가 없어서, 답 없이 14일을 쌓이는 요청이 될 게 뻔했습니다. 그래서 2026년 9월 29일에 숫자가 나온 뒤 총상한·간격·분야를 한 번에 판정하기로 했습니다.

재측정 결과: 첫 사이클 3건 전부 폐기, 수리 뒤 2건 통과

첫 라이브 사이클에서 채택 트랙이 만든 초안은 3건이었고, 3건 모두 품질 검사에서 떨어졌습니다. 탈락 초안의 길이는 305~313자였고, 질문과의 관련성은 6~7%였습니다. 목표로 준 길이가 60~300자였으니 세 초안 모두 상한을 조금씩 넘겼습니다. 짧게 쓰라는 지시를 받은 AI가 상한 바로 위에서 멈춘 모양새입니다(추정: 세 값이 모두 300자를 5~13자 넘긴 데서 읽은 해석).

관련성 6~7%가 왜 떨어졌는지는 기록에 수리 뒤의 기준(5%에 겹치는 단어 2개 이상)만 남아 있어서, 수리 전 문턱이 정확히 얼마였는지는 이 글에서 단정하지 않습니다. 확실한 사실은 기존 키워드 트랙용으로 맞춰 둔 검사 기준이 60~300자 짧은 직답에는 맞지 않았다는 점입니다. 짧은 답은 질문과 겹치는 단어 수 자체가 적어서, 긴 답에 맞춘 관련성 문턱을 그대로 쓰면 멀쩡한 답도 떨어질 수 있습니다(추정).

수리 PR #613을 넣은 뒤 다시 돌렸습니다. 재사이클에서는 초안 3건 가운데 2건이 통과했고, 그중 1건이 그날 22:31에 실제로 게시됐습니다. 첫 측정 0/3에서 재측정 2/3으로 올라선 셈입니다. 사람이 승인하는 단계가 없는 파이프라인이라, 이 3건 전부 탈락은 사고가 아니라 검사가 제 할 일을 한 결과였습니다. 기준을 고치지 않고 검사를 끄는 쪽을 택했다면 300자를 넘는 답이 그대로 나갔을 것입니다.

그런데 수리 과정에서 사고가 하나 있었습니다. #613을 머지할 때 테스트 결과를 tail 로 잘라서 보는 명령 체인을 썼는데, 이 체인이 pytest 의 종료 코드를 삼켰습니다. 파이프로 이어진 명령은 마지막 명령(여기서는 tail)의 종료 코드를 돌려주므로(셸의 일반 동작), 테스트가 실패해도 체인 전체는 성공으로 끝납니다. 그 결과 실패 테스트를 안은 채 #613이 머지됐고, 다음 PR #614에서 바로잡았습니다.

측정 방법도 남깁니다. 초안 스크립트에는 수집·초안·검사 탈락·게시 단계별로 건수를 세는 집계 명령이 있고, 트랙별로 따로 셉니다. 첫 사이클과 재사이클의 숫자는 이 집계에서 채택 트랙 줄만 읽은 값입니다. 2026년 9월 29일 판정도 같은 명령으로 채택 트랙의 게시 건수와 채택률을 읽습니다. 측정 도구를 바꾸지 않아야 첫날 숫자와 판정일 숫자를 나란히 놓을 수 있습니다.

남는 한계는 무엇인가?

가장 큰 한계는 이 기록이 채택률을 아직 재지 못했다는 점입니다. 첫날 재측정한 것은 “초안이 품질 검사를 넘는가”였지 “당일 질문에 단 답이 실제로 채택되는가”가 아닙니다. 채택은 질문자가 돌아와서 눌러야 생기므로, 하루 단위로는 판정할 수 없습니다. 그래서 판정 기준을 미리 정해 두었습니다.

• 채택 트랙 게시 40건 이상이 쌓이고 채택률이 15% 이상이면, 또는 중수에 도달하면: 총상한·간격·분야를 다시 정하는 발행량 조정에 들어갑니다
• 채택률이 5% 미만이면: 채택 트랙의 하루 상한을 0으로 내려 사실상 끕니다

판정을 미룬 대상은 세 가지 손잡이입니다. 하루 총상한(지금 10건), 게시 간격 하한(지금 2시간), 채택 트랙이 다룰 분야 범위(지금 14개)입니다. 셋을 한꺼번에 돌리면 채택률이 오르거나 내려도 어느 손잡이 때문인지 알 수 없어서, 판정일 전까지는 셋 다 고정해 두었습니다.

두 번째 한계는 노출이 늘어난 만큼 위험도 늘었다는 점입니다. 하루 발행량이 7건에서 10건으로, 크론 슬롯이 8개로 늘면서 자동화 게시가 네이버 눈에 띌 여지도 커졌습니다. 제재 신호가 보이면 상한을 5건으로 되돌리는 장치는 그대로 살아 있지만, 그 장치가 잡지 못하는 형태의 제재가 올 가능성은 남습니다.

세 번째는 본업 밖 질문입니다. 채택 트랙 답변에도 회사 이름이 든 프로필명이 붙은 채 나갑니다. 질문을 저희가 원래 답해 온 인접 분야 14개로 좁혀 완화했지만, 그 안에도 저희 서비스와 직접 관계없는 질문은 섞입니다. 짧은 직답이 틀리면 프로필명이 그 오류를 함께 짊어집니다.

마지막으로 테스트 사고가 남긴 교훈입니다. 출력을 보기 좋게 자르려고 붙인 tail 하나가 검증 단계를 통째로 무력하게 만들었습니다. 사람이 승인하지 않는 파이프라인일수록 “테스트가 돌았다”와 “테스트가 통과했다”를 같은 것으로 읽으면 안 됩니다. 비슷한 자동 답변이나 발행 파이프라인을 운영하면서 하루 한도와 품질 검사 기준을 어떻게 잡을지 고민한다면 상담에서 이야기를 나눌 수 있습니다.