지식iN 답변 자동화, 검사는 다 통과했는데 왜 채택이 안 붙었나?
지식iN 답변 자동화가 질문과 동떨어진 답을 낸 원인은 모델도 프롬프트도 아니었습니다. 답변을 만들 때 모델에게 건넨 입력이 질문 본문이 아니라, 같은 페이지에 붙어 있던 남의 답변 조각이었습니다.
우리 파이프라인은 지식iN에서 업무 질문을 골라 LLM으로 답변 초안을 쓰고, 발행 전에 품질 검사를 거쳐 올렸습니다. 검사 항목은 답변 길이, 브랜드 언급, 링크, 금지어였습니다. 발행한 답변은 전부 이 항목을 통과한 답변이었습니다.
그런데 반응이 없었습니다. 라이브 계정에서 다시 세어 보니 답변 98건 가운데 채택 2건, 추천 2건이었고 채택률은 2.0%였습니다. 검사표는 초록불인데 질문자는 거의 반응하지 않는 상태였습니다.
그래서 점검 질문을 바꿨습니다. 답변이 규칙을 지켰는가가 아니라, 질문자가 궁금해한 것을 답변이 실제로 풀어 주고 있는가입니다. 채택률 2.0%라는 숫자를 채널 판단에 어떻게 쓰면 안 되는지는 지식iN 답변 채택률 분석 오류에 따로 적었습니다. 이 글은 그 숫자 뒤에 있던 답변 품질 자체를 파고든 기록입니다.
처음 의심한 곳: 답변 프롬프트
답변이 질문을 빗나가면 가장 먼저 떠오르는 용의자는 프롬프트입니다. 모델이 질문자의 사정을 짚지 않고 일반론만 늘어놓는다면, 지시문을 더 구체적으로 쓰면 나아지리라고 생각하기 쉽습니다.
이 가설대로라면 할 일은 분명했습니다. 프롬프트에 조건을 더 넣고, 예시를 늘리고, 질문자 상황을 짚으라는 문장을 강조하는 작업입니다. 들이는 품도 작고 결과도 바로 보이니 가장 먼저 손이 가는 수리입니다.
다만 프롬프트를 고치면 무엇이 좋아졌는지 잴 기준이 없었습니다. 검사표는 이미 만점이었으니 검사표로는 개선을 볼 수 없습니다. 그래서 지시문을 건드리기 전에, 실제로 나간 답변이 실제 질문과 얼마나 맞는지부터 재기로 했습니다.
어떻게 확인했나 — 발행분 135건의 원 질문을 다시 모았다
발행한 답변 135건의 원 질문을 라이브 지식iN 페이지에서 직접 다시 수집했습니다. 그중 채점할 수 있는 건은 111건이었습니다.
대조 방법은 결정론적입니다. 답변을 만들 때 모델에게 넣은 입력 텍스트를 토큰 단위로 쪼개고, 그 토큰 가운데 실제 질문 본문에 등장하는 비율을 셉니다. 입력이 정말 질문이었다면 이 비율은 높게 나와야 합니다. 모델 판단을 섞지 않으니 누가 다시 돌려도 같은 숫자가 나옵니다.
같은 표본에서 두 가지를 더 표시했습니다. 입력 안에 다른 사람의 답변 흔적이 있는지, 그리고 질문이 사람이 쓴 글인지 자동 생성 글인지입니다.
이 방식을 고른 이유는 검사표와 다른 곳을 재기 위해서입니다. 기존 검사는 답변만 봤고, 답변이 무엇을 보고 쓰였는지는 한 번도 보지 않았습니다. 입력과 질문을 나란히 놓는 대조는 파이프라인에서 아무도 재지 않던 구간을 처음으로 재는 일이었습니다.
프롬프트는 왜 범인이 아니었나?
프롬프트를 열어 보니 필요한 지시는 이미 있었습니다. 「질문자 조건을 구체적으로 언급하라」와 「질문에 없는 조건을 지어내지 마라」 두 줄입니다. 지시가 없어서 생긴 문제가 아니었습니다.
문제는 이 지시를 지킬 재료가 입력에 없었다는 점입니다. 질문자의 조건이 담긴 원문을 주지 않으면 모델은 그 조건을 언급할 수 없습니다. 모델에게 남는 선택지는 조건을 지어내거나 총론으로 가는 것뿐입니다.
그래서 프롬프트를 아무리 다듬어도 이 결함은 고칠 수 없습니다. 입력이 틀린 상태에서 지시만 강화하는 일은, 빈 서류철을 건네며 요약을 더 꼼꼼히 하라고 주문하는 일과 같습니다. 첫 가설은 여기서 반증으로 끝났습니다.
우리는 비슷한 구조를 이미 한 번 겪었습니다. AI가 쓴 한국어 번역체를 줄이려고 생성 지시를 강화했을 때는 효과가 없었고, 발행 전에 기계로 걸러 내는 사후 검사만 효과가 있었습니다. 생성 단계의 지시보다 입력과 사후 검사가 결과를 좌우한다는 점이 이번에도 똑같이 드러났습니다.
품질 검사는 왜 빗나간 답을 통과시켰나?
기존 검사 네 항목은 전부 형식을 봤습니다. 길이가 충분한가, 브랜드를 넣지 않았는가, 링크 규칙을 지켰는가, 금지어가 없는가. 어느 항목도 답변이 그 질문에 답하고 있는지는 묻지 않았습니다.
그 결과 질문과 무관한 총론이 만점으로 통과했습니다. 검사표가 초록불이라는 사실은 답변이 질문을 맞혔다는 증거가 아니었습니다. 검사표를 보고 품질이 괜찮다고 믿은 것이 두 번째로 무너진 가정이었습니다.
진짜 원인: 네이버 검색 API의 description은 질문 본문이 아니다
답변 생성 입력은 네이버 검색 API가 돌려주는 description 필드였습니다. 이름만 보면 질문 설명 같지만, 실제로는 질문 본문이 아니라 검색어가 매칭된 페이지 조각입니다.
지식iN은 한 페이지에 질문 하나와 답변 여러 개가 함께 있습니다. 검색어가 질문 본문이 아니라 누군가의 답변 문장과 맞으면 API는 그 답변 문장을 잘라 돌려줍니다. 파이프라인은 그 조각을 질문으로 알고 모델에게 넘겼고, 모델은 남의 답변을 읽고 답변을 썼습니다.
이 결함이 오래 드러나지 않은 이유도 여기에 있습니다. 조각은 대개 질문과 같은 주제의 문장이라 사람이 한두 건 훑어서는 이상하다고 느끼기 어렵습니다. 질문 본문과 한 줄씩 겹쳐 비율을 세어 보고서야, 겉으로 비슷한 글이 실제로는 다른 사람의 말이라는 사실이 보였습니다.
대조 수치는 이 설명과 맞아떨어졌습니다.
- description 토큰 가운데 실제 질문 본문에 있는 토큰의 중앙값은 7%였습니다. 65%의 건은 15% 미만이었습니다.
- 18%는 입력에 다른 사람 답변의 신호가 있었습니다. 그중 4건은 경쟁 업체의 홍보 답변이 통째로 입력에 들어가 있었습니다.
- 질문의 21%는 사람이 쓴 글이 아니라 자동 생성 질문(「오늘숏텐츠」 표시)이었습니다.
경쟁 업체의 홍보 답변을 입력으로 받은 경우라면, 모델은 그 업체가 이미 한 말을 우리 말투로 다시 쓴 셈입니다. 질문자 입장에서는 같은 페이지에 비슷한 답이 하나 더 달린 것뿐이니 채택할 이유가 없습니다.
어떻게 고쳤나: 질문 원문을 저장하고, 없으면 쓰지 않는다
고친 방향은 입력을 질문 원문으로 바꾸는 것입니다. 네 곳을 바꿨습니다.
- 질문 수집기가 질문 페이지를 열 때 본문과 해시태그를 함께 저장합니다. 수집기는 이미 작성일과 FAQ 여부를 판정하려고 같은 페이지를 열고 있었으므로 추가 요청은 0건입니다.
- 질문 점수 매기기와 답변 생성 단계가 그 원문을 읽습니다. 원문을 확보하지 못하면 생성 자체를 막고, description으로 돌아가는 폴백을 두지 않습니다.
- 품질 검사에 5번째 항목인 관련성을 세웠습니다. 질문 고유어가 답변에 10% 이상 다시 등장해야 통과하고, 질문 고유어가 12개 이상인 질문에만 적용합니다.
- 자동 생성 질문은 수집 단계에서 뺍니다.
관련성 기준 10%는 일부러 낮게 잡았습니다. 명백하게 빗나간 답만 잡으려는 목적입니다. 대조 데이터에서 잘 답한 건의 점수는 0.28, 빗나간 건은 0.03과 0.00이었습니다. 두 무리 사이가 넓어서 제대로 답한 답변을 잘못 막을 여지가 작습니다.
변경은 PR #426으로 머지했습니다. 새 회귀 테스트 7건을 더했고, 전체 테스트 708건이 통과했습니다.
검토하고 버린 대안은 무엇이었나?
- 프롬프트 강화 — 버렸습니다. 지시는 이미 있었고, 입력이 없어 이행이 불가능했습니다.
- description 폴백 유지 — 버렸습니다. 기존 대기열 전체가 본문 없는 상태라 폴백을 두면 폴백만 쓰입니다. 수리 전과 똑같아지고, 검사는 통과하는 척만 합니다.
- LLM에게 관련성을 채점시키기 — 버렸습니다. LLM이 LLM을 채점하는 방식은 판정 자체를 믿기 어렵고, 생성할 때마다 판정 호출이 붙어 비용이 배로 늘어납니다. 결정론 지표만으로 실측 판별력이 충분했습니다.
- 이미 나간 135건 수정 — 버렸습니다. 네이버 답변 수정은 저품질·어뷰징 신호로 읽힐 위험이 있어 되돌리기 어렵고, 얻는 것은 채택 가능성뿐이라 기대값이 음수였습니다.
네 대안 모두 당장 손쉬운 길이었다는 공통점이 있습니다. 특히 폴백 유지는 코드상으로는 안전장치처럼 보이지만, 이번 경우에는 수리를 무효로 만드는 장치였습니다. 새 필드가 비어 있는 과거 데이터가 대기열을 채우고 있는 한, 폴백은 예외 경로가 아니라 사실상 기본 경로로 바뀝니다.
대가도 있습니다. 원문을 확보하지 못한 초안을 버리므로 발행할 수 있는 물량이 줄어듭니다. 과거 데이터에 적용해 보면 원문 미확보로 17%, 자동 생성 질문 제외로 21%가 빠집니다. 하루 7건 발행 상한을 채우지 못하는 날도 생길 수 있습니다.
그래도 적게 쓰더라도 제대로 쓰자는 운영 원칙과 같은 방향이라 이 손실을 받아들였습니다. 빗나간 답을 많이 올리는 쪽이 채택률에도, 계정 평판에도 더 나쁘다고 판단했습니다.
같은 실수를 막는 장치: 관련성 검사와 폴백 금지
같은 실수를 막는 장치는 세 겹입니다.
- 관련성 검사 — 형식만 보던 검사표에 「질문에 답했는가」를 묻는 항목이 처음 생겼습니다. 입력이 다시 오염되면 답변 속 질문 고유어가 줄어들고, 이 항목이 발행을 막습니다.
- 폴백 금지 — 원문이 없으면 생성하지 않습니다. 조용히 옛 입력으로 돌아가는 길을 코드에서 없앴습니다. 폴백이 있으면 고장 난 경로가 멀쩡한 경로처럼 보이기 때문입니다.
- 회귀 테스트 — tests/test_kin_answer_relevance.py의 7건이 관련성 판정 동작을 고정합니다.
이 수리 자체가 틀렸을 가능성도 열어 두었습니다. 2026-09-14를 판정일로 정하고, 수리 후 발행분의 채택·추천이 2.0% 위로 올라가지 않으면 원인은 입력이 아니라 질문 주제 선택으로 보고 키워드 축을 다시 설계하기로 했습니다. 이 글은 그 결정을 내린 시점까지의 기록입니다.
판정 기준을 2.0%로 둔 데도 이유가 있습니다. 수리 전 채택률이 2.0%였으니, 입력을 바로잡았는데도 그 선을 넘지 못한다면 입력이 유일한 원인은 아니라는 뜻입니다. 그때는 답변을 더 손보는 대신 어떤 질문에 답할지를 고르는 단계로 돌아가야 합니다. 원인을 하나 찾았다고 해서 그것이 전부라고 단정하지 않으려고, 반증 조건을 수리와 같은 날 적어 두었습니다.
LLM 답변 자동화에서 왜 입력부터 의심해야 하나?
이번 일에서 얻은 교훈은 하나입니다. LLM 출력이 빗나가면 지시문보다 입력을 먼저 열어 봐야 합니다. 필드 이름이 description이라고 해서 그 안에 질문 설명이 들어 있다는 보장은 없습니다.
비슷한 자동화를 점검한다면 이 순서를 권합니다.
- 모델에게 실제로 들어간 입력을 발행분 단위로 뽑아, 원천 데이터와 겹치는 비율을 셉니다.
- 검사표 항목을 형식 항목과 내용 항목으로 나눠 봅니다. 내용 항목이 하나도 없다면 총론이 만점을 받습니다.
- 폴백 경로가 있다면 실제로 몇 건이 폴백을 타는지 셉니다. 전부 폴백을 탄다면 수리는 없던 일입니다.
- 수리가 틀렸을 때를 대비해 판정일과 반증 조건을 먼저 적어 둡니다.
AI로 고객 문의 답변이나 콘텐츠 초안을 자동화하다가 비슷하게 빗나가는 답을 겪고 있다면, 입력 경로부터 같이 점검해 볼 수 있습니다. 상황은 상담으로 알려 주세요.