6월 22일, 시편 23편으로 글 한 편을 만들어 보기로 했습니다. 테스트할 게 있어서가 아니라, 그냥 잘 되는지 보고 싶었습니다.
결과물은 그럴듯했습니다. 문장이 매끄럽고 각주도 열두 개나 붙어 있었습니다. 저는 각주를 하나씩 눌러 봤습니다.
시편 글에 히브리서 출처가 붙어 있었습니다
각주 열두 개가 전부 같은 책을 가리켰습니다. 히브리서의 반복 구조를 다룬 논문이었습니다. 시편 23편 글에 말입니다.
한 개가 틀렸으면 실수라고 생각했을 겁니다. 열두 개가 전부 같은 엉뚱한 책이라는 건 실수가 아니라 구조입니다.
찾아보니 원인이 허무했습니다. 출처를 적는 형식을 알려주려고 프롬프트에 예시를 넣어 두었는데, 그 예시에 제가 실제 책 이름을 썼습니다. 형식만 보라고 넣은 것을 연구 담당 에이전트가 내용까지 베낀 것입니다. 사람도 그럽니다. 양식 예시에 "홍길동"이라고 적혀 있으면 누군가는 그대로 제출합니다.
그리고 옆에서 다른 것이 튀어나왔습니다
같은 런의 기록을 보다가 이상한 숫자를 봤습니다. 그 글을 쓰는 동안 에이전트가 엉뚱한 자료 묶음에 열여섯 번 질문했고, 정작 시편 자료에는 다섯 번만 물었습니다. 세 배 더 많이 헛것을 뒤진 셈입니다.
이유는 이름이었습니다. 제가 개인적으로 만들어 둔 자료 묶음의 이름이 "한글 주석서"였습니다. 실제 내용은 히브리서 전용이었지만, 이름만 보면 시편 주석도 거기 있을 것처럼 보입니다. 에이전트는 그 일반적인 이름을 보고 시편 주석인 줄 오해했습니다.
이 헛질의가 그 런을 50분 지연시켰고, 무료 호출 한도를 밀어 올렸고, 무엇보다 내용이 오염될 위험을 만들었습니다.
그렇게 하나를 당기니 줄줄이 나왔습니다. 그날 잡은 것이 여덟 개였습니다 — 출처 형식 예시가 그대로 복사되던 것, 서로 다른 파일이 같은 표기를 공유하던 것, 본문 각주 번호가 검증된 출처 개수를 넘어가던 것, 개인 자료가 공용 검색에 노출되던 것, 자료 선택이 엉뚱한 곳으로 라우팅되던 것…
진짜 원인 — 저는 결과물만 보고 있었습니다
여덟 개 모두 글을 읽을 때는 보이지 않았습니다. 문장은 매끄러웠고 각주는 형식이 완벽했습니다. 보인 것은 각주를 눌러 봤을 때, 기록을 세어 봤을 때였습니다.
그때 배운 것이 지금 이 프로젝트의 습관이 됐습니다. 결과물이 그럴듯하다는 것은 아무것도 증명하지 않습니다. 특히 언어 모델이 만든 것은 그럴듯함을 가장 잘 만들어 냅니다. 그럴듯함은 검증이 아니라 검증을 미루게 만드는 유혹입니다.
고친 것
- 프롬프트의 예시에서 실제 책 이름을 지웠습니다. 중립적인 자리표시자로 바꾸고 "예시를 베끼지 말라"는 경고를 함께 넣었습니다.
- 서로 다른 파일이 같은 표기를 공유하면 그것을 예시 복사 신호로 보고, 표기를 파일에서 다시 뽑아냅니다.
- 발행 직전에 본문 각주 번호와 검증된 출처 개수를 대조합니다. 범위를 벗어난 번호(고아 각주)가 있으면 발행을 멈춥니다.
- 개인 자료 묶음은 공용 검색에서 아예 보이지 않게 막았습니다(막지 못하면 통과가 아니라 차단이 기본값입니다).
그날 남은 원칙
사람의 질문이 가장 좋은 디버깅 도구입니다.
저는 코드를 읽어 그 여덟 개를 찾은 게 아닙니다. "이 각주 진짜인가?" "왜 이렇게 오래 걸렸지?" 같은 평범한 질문을 하나씩 던졌고, 그 질문마다 진짜 범인이 하나씩 끌려 나왔습니다. 개발 경험이 없는 제가 할 수 있었던 일은 그것뿐이었는데, 결과적으로 그게 가장 효과적이었습니다.
지금도 그렇습니다. 저는 자주 "이거 정말 그런가?"를 묻고, 그 질문이 문서와 코드가 어긋난 자리를 찾아냅니다. 자동화를 만들면서 배운 역설이 하나 있다면 이것입니다 — 자동화가 늘어날수록 사람이 던지는 의심의 가치가 올라갑니다. 기계는 자기가 그럴듯한지 스스로 의심하지 않습니다.
이 연재는 목사 한 사람이 AI 연구 에이전트 팀을 만들어 온 과정을 시간순으로 적는 기록입니다. 다음 화에서는 배경음악 한 곡을 트는 일이 왜 그렇게 어려웠는지 이야기하겠습니다.
Comments
Post a Comment