당신은 사람이 결정할 수 있도록 정보를 제공하는 시스템을 구축했습니다. 그런데 어느 순간부터 시스템이 사람 대신 결정을 내리기 시작했습니다. 출력 내용이 "문서에 따르면 이렇습니다"라고 말하는 대신 "X를 해야 합니다"라고 말하기 시작한 것입니다. 아무도 이러한 편향(drift)을 설계하지 않았습니다. LLM(Large Language Model)은 질문을 받으면 답변 형태의 결과물을 만들어내며, 그 답변은 쉽게 판결(verdict)로 변질될 수 있습니다.

모두가 시도하는 방법

프롬프트 지침(prompt instruction)을 주는 것입니다: "추천하지 마세요." "문서에 있는 내용만 기술하세요." 사람들은 이 문구를 추가하고 경계가 강제된다고 가정합니다.

작동하지 않는 이유

프롬프트 지침은 _요청(request)_일 뿐, 가드레일(guardrail)이 아닙니다. 모델은 대부분의 경우 이를 따르지만, 정작 중요한 입력에 대해서는 구조적으로 막는 장치가 없기 때문에 결국 확신에 찬 추천을 내놓게 됩니다. "추천하지 마세요"라는 문구는 가드레일에 있어서, 잠긴 문에 "들어오지 마세요"라고 적힌 포스트잇을 붙여놓는 것과 같습니다.

그리고 그 위험성은 겉으로 보이는 것보다 훨씬 높습니다. 출력이 증거(evidence)에서 판결(verdict)로 편향되는 순간, 책임(accountability)의 소재가 이동합니다. 시스템이 증거를 반환하고 사람이 결정하는 한, 결정의 책임은 사람에게 있습니다. 하지만 시스템이 판결을 내리고 사람이 이를 따르는 순간, 시스템은 검증받지 않은 결정을 내리게 되며, 오류가 발생했을 때 책임 소재는 불분명해집니다. 이해관계가 큰 분야에서는 증거 추출(evidence extraction)과 판단(judgment)을 의도적으로 분리합니다. 하지만 대부분의 RAG(Retrieval-Augmented Generation) 시스템은 기본적으로 그 경계를 허물어 버립니다.

단 하나의 변화

출력이 무엇인지 결정하고 이를 구조적으로 강제하십시오. 출력은 스스로가 답변인지, 증거인지, 누락된 사실인지, 혹은 범위를 벗어난 것(out-of-scope)인지를 선언해야 합니다. "결정이 아닌 결정에 필요한 자료를 반환하라"는 원칙은 모델에 대한 정중한 요청이 아니라, 출력 계약(output contract)과 게이트(gates)에 존재해야 합니다. 시스템은 프레임(frames)을 제공하고, 사람은 판결(verdicts)을 내립니다.

이것이 바로 출력 경계(output boundary)이며, 실제 운영 환경의 RAG가 실패하는 세 가지 지점 중 하나입니다.

제 블로그에서 전체 버전을 읽어보세요. 이곳에서 이 내용은 운영 중인 RAG를 디버깅하는 팀들을 위한 **RAG 실패 진단 키트(RAG Failure Diagnosis Kit)**와 연결됩니다.