네이버 계정 제재 위험, 발행 상한을 5에서 7로 올려도 되나?
SGK 스튜디오는 중소기업의 홈페이지 제작과 AI 업무 자동화를 맡는 작은 회사다. 이 회사는 네이버 지식iN에 자동으로 질문을 찾아 답을 올리는 프로그램을 운영한다. 지식iN은 네이버가 운영하는 질문·답변 서비스이고, 답변자 프로필에 홈페이지 링크를 걸 수 있어 중소기업이 검색 노출과 방문자 확보 수단으로 쓰기도 한다. 이 회사가 겪은 일은 하루에 올릴 수 있는 답변 수(발행 상한)를 5건에서 7건으로 늘리려다 맞닥뜨린 네이버 계정 제재 위험과, 그 위험을 사람이 아니라 코드가 알아서 처리하게 만든 과정이다.
2026년 8월 25일, 이 회사는 지식iN 채널을 줄이지 않고 오히려 하루 발행 상한을 5건에서 7건으로 늘리기로 확정했다. 문제는 발행량이 40% 늘면 네이버가 계정을 제재할 위험도 그만큼 는다는 점이었다. 그래서 이번 결정에는 조건이 하나 붙었다 — 제재로 읽히는 신호가 로그에 나타나면 사람이 알아채기 전에 그날 상한을 자동으로 5건으로 되돌리는 장치를 코드로 만들어야 했다. 발행량을 늘리는 결정과 이 안전장치는 같은 작업 안에서 함께 만들어졌다.
상한은 그대로 두고 프로필 쪽만 손보자는 방안도 검토했다. 하지만 실측으로 병목은 프로필이 아니라 발행 상한 자체였다. 2026년 8월 13일부터 24일까지 12일 연속으로 그날 상한에 도달했고, 답하지 못한 질문이 대기 큐에 15~18건씩 쌓여 있었다. 상한을 그대로 두면 이 적체는 풀리지 않는다는 뜻이었다.
채널을 줄이자던 근거부터 다시 짚었다 — 두 분석의 착시
발행 상한을 늘리자는 얘기가 나오기 전, 이 회사는 반대로 채널을 5분의 1로 줄이자는 권고를 검토하고 있었다. 근거는 두 가지 분석이었다. 하나는 지식iN을 운영한 지 35일이 지난 시점에 답변 99건 중 채택은 2건(2.0%)뿐이라는 전반적인 저성과였고, 다른 하나는 그 안에서도 구매 의도가 뚜렷한 질문 25건에 답했는데 채택이 0건이라는 숫자, 그리고 답변 제목을 분야별로 걸러 보니 회사 서비스와 무관한 질문이 13%라는 숫자였다.
이 두 숫자를 다시 검산하자 둘 다 무너졌다. 구매 의도가 뚜렷한 질문 25건의 채택 0건은, 전체 채택률 2.04%를 그대로 적용하면 기대 채택 건수가 0.51건이라는 뜻이었다. 기대값이 1건도 안 되는 표본에서는 (1-0.0204)^25 = 0.597, 즉 차이가 전혀 없어도 0.597의 확률로 0건이 나온다는 계산이 나왔다 — Fisher 정확검정 결과도 p=1.000으로, 통계적으로 아무 신호가 아니었다. 회사와 무관한 질문 13%라는 숫자는 더 단순한 결함이었다. 분류 코드가 대문자로 쓴 서비스명은 잡아내면서 소문자로 쓴 같은 단어는 놓치고 있었고, 답변 목록을 사람이 직접 읽어 보니 진짜 무관한 질문은 4건(4.1%)뿐이었다. 재확인한 타게팅 정확도는 95.9%였다. 이 시점까지 이 채널이 만든 결과는 리드 0건, 매출 0원이었다 — 그런데도 축소 대신 확장을 택한 이유는 뒤에서 다룬다.
같은 채널에서 있었던 이 착시는 지식iN 답변 채택률 분석 오류 글에 표본 크기 계산과 코드 결함을 따로 정리해 뒀다. 이 글에서는 그 재검산 이후에 실제로 내려진 결정 — 채널을 유지·확장하면서 네이버 계정 제재 위험을 어떻게 코드로 막았는지를 다룬다. 두 분석이 무너지지 않았다면 발행 상한은 5건에서 7건이 아니라 1건으로 줄어드는 쪽으로 갔을 것이다.
처음 의심한 것 — 발행 실패는 전부 위험 신호로 세면 되지 않을까?
채널을 줄이지 않고 오히려 늘리기로 한 이상, 발행 상한을 5건에서 7건으로 올리는 일과 별개로 안전장치가 있어야 했다. 이 안전장치를 사람이 매일 로그를 읽고 판단하는 방식으로 만들 수는 없었다(이유는 뒤에서 다룬다). 그래서 가장 먼저 떠오른 설계는 단순했다 — '오늘 발행 중 실패한 기록이 있으면 그날 상한을 낮춘다'는 규칙이었다.
이 설계는 그럴듯해 보였다. 발행이 실패했다는 건 뭔가 잘못됐다는 신호이고, 신호가 있으면 보수적으로 상한을 낮추는 쪽이 안전해 보였다. 문제는 '실패'라는 말이 실제로는 성격이 다른 여러 상황을 뭉뚱그리고 있었다는 점이다. 코드에서 하루 발행 상한을 관리하는 값(`MAX_DAILY_PUBLISH`)은 숫자 하나만 갖고 있었고, 그 숫자를 낮출지 말지를 정하는 판단 로직이 아직 없는 상태였다 — 채워 넣어야 할 게 정확히 그 판단 로직이었다.
확인에 쓴 수단 — 실패 로그를 유형별로 나눠 읽기
실패를 전부 같은 것으로 취급해도 되는지 확인하려면, '실패'라고 기록된 로그를 직접 열어 종류별로 나눠 읽는 수밖에 없었다. 발행 프로그램은 질문을 찾는 단계, 답을 쓰는 단계, 실제로 게시하는 단계마다 성공·실패 여부를 로그에 남기고 있었고, 실패 항목을 원인별로 분류하는 작업을 거쳤다.
이 방식을 쓴 이유는 하나다. '오늘 실패 건수'라는 숫자 하나만 보면 그 실패가 네이버 쪽 계정 문제인지, 아니면 이 회사의 프로그램이 답할 질문을 못 찾았을 뿐인지 구분이 안 된다. 구분하려면 로그 안의 오류 메시지 하나하나를 읽어야 했다. 실패 건수라는 요약값만 봐서는 원인이 셋 중 어디에 있는지 가려낼 수 없었고, 그래서 요약 이전 단계인 원본 로그로 내려가야 했다.
알리바이 — 질문이 없거나 브라우저가 멈춘 건 계정 문제가 아니었다
실패 로그를 유형별로 나눠 보니, 상당수는 계정과 무관한 이유였다. 하나는 그 시간대에 답할 만한 새 질문 자체가 없었던 경우(질문 사정)였다. 프로그램이 답을 다는 하위 분야에는 새 질문이 끊임없이 올라오는 게 아니라서, 어떤 시간대에는 조건에 맞는 질문이 아예 없을 수 있었다. 다른 하나는 자동화된 브라우저가 페이지를 불러오다 일시적으로 멈추는 경우였다.
이 두 유형은 네이버가 계정을 겨냥해서 막은 게 아니라, 공급이 부족하거나 기술적으로 한 번 삐끗했을 뿐이었다. 둘 다 무죄였다. 문제는 이걸 '실패'라는 이름으로 뭉뚱그리면, 이 무죄인 실패가 나올 때마다 상한이 함께 낮아진다는 데 있었다. 질문이 없는 시간대가 하루에도 여러 번이면, 상한은 사실상 항상 낮은 값에 머물게 된다 — 안전장치가 필요할 때만 켜지는 게 아니라 상시로 꺼진 상태가 되는 셈이다.
진짜 원인 — 계정을 위협하는 신호는 딱 세 가지였다
로그를 전부 나눠 보고 나서야 진짜 계정 위험 신호가 무엇인지 좁혀졌다. 네이버가 실제로 이 계정을 겨냥해서 막았다고 볼 수 있는 실패는 셋뿐이었다.
- 자동입력 방지 문자(CAPTCHA)를 통과하지 못함
- 신원 확인 절차가 걸림
- 로그인이 3회 이상 연속으로 만료됨
이 셋은 질문이 없거나 브라우저가 멈추는 경우와 성격이 다르다. 앞서 확인한 두 유형은 각각 공급 문제와 일회성 기술 문제였지만, 이 세 가지는 네이버 쪽 시스템이 이 계정의 행동을 의심하고 있다는 신호로 읽을 수 있었다. 자동입력 방지 문자와 신원 확인 절차는 원래 사람이 아닌 접속을 걸러내려고 만든 장치이고, 로그인이 반복해서 끊기는 현상도 정상적인 사용 패턴과는 다르다. 반대로 질문이 없거나 브라우저가 한 번 멈추는 건 계정의 행동과 무관하게 누구에게나 일어날 수 있는 일이다.
왜 사람이 로그를 읽는 방식은 안 됐나?
안전장치를 '매일 아침 로그를 읽고 사람이 판단한다'는 방식으로 만들 수도 있었다. 실제로 이 방식이 대안으로 검토됐지만 기각됐다. 이유는 같은 발행 프로그램에서 채택 건수 같은 핵심 수치가 16일간 아무도 확인하지 않은 채 방치된 전례가 있었기 때문이다.
사람이 매일 확인해야 작동하는 장치는, 그 사람이 하루라도 잊으면 그날부터 장치가 없는 셈이 된다. 16일이라는 숫자가 이미 그 위험을 증명하고 있었다. 그래서 판정 자체를 코드 안으로 옮기기로 했다 — 사람이 읽지 않아도 매일 스스로 판단하는 구조여야 했다.
고친 방법 — 오늘 로그를 스스로 읽고 상한을 낮추는 함수 하나
최종적으로 만든 것은 `effective_daily_cap()`이라는 이름의 함수다. 이 함수는 그날의 로그를 열어 앞서 추려낸 세 가지 신호(CAPTCHA 실패·신원 확인 절차·로그인 3회 이상 만료) 중 하나라도 있으면 그날 상한을 7에서 5로 자동으로 낮춘다. 질문 사정이나 브라우저 일시 오류는 이 판단에서 제외된다.
- 일일 발행 상한 5건 → 7건
- 발행 슬롯 3개 → 4개(오전 8시 30분에 한 슬롯 추가)
- 계정 대상 거부 신호가 있으면 그날 상한을 자동으로 5건으로 원복
- 자동화된 테스트 61개(신규 13개) 통과
슬롯을 3개에서 4개로 늘린 이유도 같은 조사 중에 나왔다. 발행 한 건을 처리하는 배치는 건마다 2시간과 임의 대기시간(지터)을 쓰는데, 슬롯이 3개뿐이면 하루 안에 7건을 다 처리할 시간이 물리적으로 모자랐다. 상한만 올리고 슬롯을 그대로 뒀다면, 코드는 맞게 짜였는데도 실제로는 7건을 다 채우지 못하는 상황이 벌어졌을 것이다. 이 변경은 PR #391로 정리해 병합됐다(커밋 5b28bf7).
발행 상한을 곧바로 5에서 10으로 올리는 방안도 검토했지만 기각했다. 미리 정해둔 계획은 5→7→10처럼 단계를 밟는 계획이었는데, 7로 4주를 운영해 본 실측 없이 바로 10으로 가면 나중에 제재가 나더라도 원인이 상한 때문인지 다른 변경 때문인지 가릴 수 없기 때문이다. 같은 이유로 상한을 5→1로 줄이는 원래 권고안도 다시 채택되지 않았다 — 그 권고를 받치던 두 분석이 이미 무너졌고, 발행량을 줄이면 채택 표본 자체가 줄어 다음 판정이 오히려 늦어진다는 문제도 있었다.
같은 실수를 막는 장치 — 다음 판정은 2026년 9월 22일
이 안전장치가 재발 방지 장치인 이유는 두 가지다. 첫째, 사람이 로그를 읽어야만 작동하던 구조를 코드가 대신하므로 16일 방치 같은 일이 되풀이될 수 없다. 둘째, 실패를 유형별로 나누지 않고 뭉뚱그리던 첫 설계로 되돌아갈 수 없도록 자동화된 테스트 61개(신규 13개)가 함께 통과했다 — 이 테스트가 남아 있는 한, 다음에 코드를 고치는 사람이 이 구분을 실수로 지워도 곧바로 드러난다.
2026년 8월 13일부터 24일까지 12일 연속으로 그날 상한에 도달했고, 답하지 못한 질문이 대기 큐에 15~18건씩 쌓여 있었다. 질문 후보 자체도 하루 최대 10건을 넘지 않아 공급이 병목이었다는 사실도 이번에 함께 확인됐다. 상한을 7건으로 늘려도 하루 최대 10건이라는 공급 한도 안에 있으므로, 이번 확장은 공급이 감당할 수 있는 범위 안에서 이뤄진 셈이다. 다음 단계로 상한을 10건까지 올릴지는 2026년 9월 22일 재측정에서 정하기로 했다 — 7건으로 운영한 4주치 실측이 쌓여야 판단할 수 있는 값이기 때문이다.
비슷한 자동화 안전장치가 필요하면 상담에서 이 회사가 겪은 과정을 더 물어볼 수 있다.