검증 가능한 답변 구조 만들기
프롬프트를 잘 설계해도 모델은 여전히 틀릴 수 있다. 문제는 틀릴 수 있다는 사실 자체보다, 틀린 답이 그럴듯하게 보인다는 점이다. 실무에서 더 위험한 것은 낮은 정확도보다 낮은 가시성이다. 답이 틀렸는데도 맞아 보이고, 근거가 빈약한데도 단정적으로 말하며, 확신이 없는데도 확신 있는 문장으로 포장되면 검토자는 속기 쉽다.
그래서 고급 프롬프트 설계에서는 정답률을 높이는 일과 함께, 틀렸을 때 티 나게 만드는 구조를 설계해야 한다. 이 장의 핵심은 바로 여기에 있다. 답변을 그럴듯한 문장 덩어리로 내보내지 말고, 검증 가능한 단위로 나누어야 한다. 무엇이 사실인지, 무엇이 추론인지, 무엇이 불확실한지, 어디서부터는 답변을 멈춰야 하는지가 답 안에 드러나야 한다.
왜 '잘 답하는 구조'보다 '검증 가능한 구조'가 중요한가
입문 단계에서는 흔히 이렇게 생각한다. "모델에게 더 정확하게 답하라고 지시하면 되지 않을까?" 물론 어느 정도는 도움이 된다. 하지만 운영 환경에서는 그 한 문장이 충분하지 않다. 모델은 때때로 부족한 정보를 메우려 하고, 애매한 질문을 스스로 해석하며, 빈칸을 추론으로 채운다. 이때 필요한 것은 더 강한 당부가 아니라, 잘못된 추론이 밖으로 드러나는 형식이다.
예를 들어 "이 정책은 언제부터 시행되나요?"라는 질문에 모델이 날짜를 단정해서 말해 버리면, 검토자는 그 문장을 그대로 믿고 지나갈 수 있다. 반대로 답이 다음과 같이 구성되어 있다면 이야기가 달라진다.
확인된 정보: 정책 문서 본문에서 시행일을 직접 찾지 못함
추정: 개정일과 시행일이 같을 가능성이 있으나 문서상 명시 확인 필요
권장 조치: 원문 부칙 또는 시행 조항 재확인 필요
이 구조의 장점은 화려하지 않지만 강력하다. 모델이 아는 것과 모르는 것이 섞이지 않는다. 검토자는 어느 지점이 사실이고 어느 지점이 해석인지 빠르게 구분할 수 있다. 즉, 답변이 단순히 보기 좋게 정리되는 것이 아니라, 검토 가능한 객체가 된다.
검증 가능한 답변의 기본 원리
검증 친화적인 답변은 대개 세 가지 특징을 가진다.
첫째, 주장과 근거가 분리되어 있다. 결론만 있으면 검토가 어렵다. 어떤 문장을 근거로 그 결론에 도달했는지가 함께 보여야 한다.
둘째, 확실한 것과 불확실한 것이 구분되어 있다. 모델이 자신 없는 내용을 자신 있는 말투로 말할수록 위험해진다. 반대로 불확실성을 구조적으로 표현하면 후속 검토가 쉬워진다.
셋째, 멈춰야 할 때 멈춘다. 답을 끝까지 만들어 내는 습관은 친절해 보일 수 있지만, 실제로는 사고를 키운다. 어떤 요청은 거절해야 하고, 어떤 요청은 추가 정보가 필요하며, 어떤 요청은 사람 검토가 먼저다.
이 세 가지를 운영 프롬프트로 옮기면 네 가지 설계 패턴으로 정리할 수 있다. self-check, compare-and-verify, uncertainty 표현, refusal policy가 그것이다.
self-check: 답을 내기 전에 스스로 점검하게 만들기
self-check는 모델이 답변을 생성한 뒤, 그 답이 최소한의 품질 조건을 만족하는지 스스로 점검하게 만드는 방식이다. 여기서 중요한 점이 하나 있다. self-check는 모델이 완벽한 심판이 된다는 뜻이 아니다. 모델은 자기 오류를 완전히 잡아내지 못한다. 그래도 이 단계가 유용한 이유는, 아주 단순한 실수와 명백한 모순, 빠진 조건, 형식 위반을 줄이는 데 효과가 있기 때문이다.
예를 들어 고객 응대 시스템이라면, 답을 내기 전에 다음과 같은 질문을 내부적으로 거치게 할 수 있다.
사용자의 질문에 직접 답했는가
제공된 근거 밖의 단정을 포함했는가
정책상 금지된 안내를 했는가
불확실한 내용을 확실한 것처럼 표현했는가
필요한 경우 사람 검토로 넘겼는가
이 점검은 겉으로 긴 자기반성 문장을 출력하게 할 필요가 없다. 오히려 운영 환경에서는 내부 점검만 하고, 사용자에게는 정리된 결과만 보여 주는 편이 낫다. 중요한 것은 장황한 사고 과정을 노출하는 것이 아니라, 답변 전에 오류를 한 번 더 걸러내는 것이다.
실무에서는 self-check를 "출력 전 최종 게이트"처럼 생각하면 이해하기 쉽다. 초안 작성이 1차 작업이라면, self-check는 출하 전 검수다. 제품을 만들고 바로 내보내지 않듯, 답변도 한 번 더 살펴보고 내보내야 한다.
self-check를 잘못 쓰는 방식
초보 설계에서 자주 보는 실수는 "스스로 다시 생각해 봐"를 너무 막연하게 주는 것이다. 이 지시는 듣기에는 그럴듯하지만, 실제로는 불안정하다. 무엇을 기준으로 다시 생각해야 하는지 없기 때문이다. 검수 기준이 없는 self-check는 감상문에 가깝다.
좋은 self-check는 추상적인 반성이 아니라 체크리스트를 가진다. 예를 들어 "답변 안에 날짜가 있으면 출처 문장과 일치하는지 확인하라", "금액을 안내할 때는 조건과 예외를 함께 명시하라", "근거가 없으면 추정으로 표시하거나 답변을 보류하라"처럼 구체적이어야 한다.
즉, self-check의 핵심은 '더 똑똑하게 생각해'가 아니라 '어떤 오류를 찾을지 명시해'다.
compare-and-verify: 한 번에 믿지 말고, 대조해서 확인하기
compare-and-verify는 답을 한 번 생성하고 끝내지 않고, 별도의 검증 관점에서 다시 비교하는 구조다. 쉽게 말해 "답변 생성"과 "답변 검사"를 분리하는 방식이다. 사람이 문서를 쓸 때도 초안을 쓴 뒤 맞춤법, 숫자, 논리 흐름을 따로 보듯이, 모델에게도 이 두 작업을 나누어 맡길 수 있다.
이 패턴은 특히 다음 상황에서 강하다. 사실 관계가 섬세한 답변, 숫자나 날짜가 포함된 답변, 규정 해석처럼 조건 누락이 치명적인 답변, 그리고 여러 후보 중 하나를 선택해야 하는 답변에서 그렇다.
예를 들어 compare-and-verify 구조는 보통 이런 흐름으로 동작한다.
먼저 질문에 대한 초안 답변을 만든다.
그다음 초안의 핵심 주장만 뽑아낸다.
각 주장에 대해 제공된 근거와 일치하는지 확인한다.
불일치, 과장, 누락이 있으면 수정하거나 보류한다.
중요한 점은 검증 단계가 초안의 문장력이나 설득력에 흔들리지 않도록 만드는 것이다. 초안이 아무리 유창해도, 검증 단계는 "문장이 좋아 보이는가?"가 아니라 "주장이 근거와 맞는가?"만 봐야 한다.
이때 아주 유용한 습관이 있다. 답변을 문장 단위가 아니라 주장 단위로 쪼개는 것이다. 예를 들어 "환불은 7일 이내 가능하며, 개봉 후에는 불가합니다"라는 문장은 사실 두 주장으로 나뉜다. 하나는 기한이고, 다른 하나는 조건이다. 이 둘을 따로 확인해야 한다. 한 문장 안에 두 사실이 섞여 있으면 한쪽만 맞고 한쪽은 틀릴 수 있기 때문이다.
답변을 '주장 단위'로 설계하기
검증 가능한 답변 구조를 만들려면 최종 출력도 주장 단위 검토가 쉽도록 정리하는 편이 좋다. 예를 들어 아래처럼 구성할 수 있다.
답변
정책상 일반 환불은 구매 후 7일 이내에 신청할 수 있습니다.
확인 근거
환불 규정 2조에 7일 이내 청약철회 가능이라고 명시되어 있습니다.
주의 사항
다만 개봉 상품은 예외 조항 적용 여부를 별도로 확인해야 합니다.
이 형식의 장점은 단순하다. 답변, 근거, 예외가 섞이지 않는다. 검토자는 각 부분을 따로 볼 수 있다. 특히 정책 문서, 내부 규정, 법률, 의료, 재무처럼 예외와 조건이 중요한 분야에서는 이 분리가 매우 큰 차이를 만든다.
반대로 아래와 같은 답은 검증이 어렵다.
"정상적인 경우 대체로 7일 이내 환불이 가능하지만 상황에 따라 다를 수 있으니 고객센터에 문의해 보세요."
이 문장은 얼핏 안전해 보이지만 실제로는 불친절한 회피와 불명확한 정보가 섞여 있다. 무엇이 규정이고 무엇이 추정인지 모호하다. 검증 가능성은 낮고, 책임 소재도 흐려진다.
uncertainty 표현: 모를 때는 모른다고, 그러나 더 구조적으로
많은 팀이 "모르면 모른다고 답하라"는 지시를 넣는다. 나쁜 지시는 아니다. 하지만 이것만으로는 충분하지 않다. 이유는 간단하다. 실무에서 불확실성은 단순한 흑백이 아니기 때문이다. 완전히 아는 경우, 일부만 아는 경우, 문서는 있지만 해석이 필요한 경우, 정보는 없지만 추정은 가능한 경우가 모두 다르다.
그래서 uncertainty 표현은 단순 거절보다 더 세밀해야 한다. 모델은 자신의 상태를 몇 가지 유형으로 나누어 보여 줄 수 있어야 한다. 예를 들어 다음과 같은 구분이 유용하다.
확인됨: 제공된 근거나 정책 문서에서 직접 확인한 정보
추정됨: 직접 근거는 없지만 맥락상 가능성이 있는 해석
불명확함: 질문이 애매하거나 문서가 모호해서 단정할 수 없는 상태
확인 불가: 현재 주어진 정보만으로는 판단할 수 없는 상태
이 구분이 중요한 이유는, 같은 "모르겠습니다"라도 후속 조치가 달라지기 때문이다. 확인 불가라면 추가 문서가 필요하고, 불명확함이라면 질문을 다시 받아야 하며, 추정됨이라면 가정이 무엇인지 밝혀야 한다. 즉, uncertainty 표현은 단지 겸손한 말투가 아니라, 다음 행동을 설계하는 신호다.
좋은 uncertainty 표현의 조건
좋은 uncertainty 표현은 세 가지를 함께 제공한다. 현재 확실한 정보, 무엇이 비어 있는지, 다음에 무엇을 해야 하는지다.
예를 들어 이런 답은 훨씬 운영 친화적이다.
"현재 제공된 정책 본문에서는 시행일을 직접 확인하지 못했습니다. 개정 공고일이 함께 제시되어 있지만, 그것이 시행일과 동일한지는 문서상 확정할 수 없습니다. 부칙 또는 시행 조항을 추가로 확인해 주세요."
이 답의 장점은 애매함을 감추지 않는다는 점이다. 동시에 사용자를 그냥 돌려보내지도 않는다. 어디를 확인하면 되는지까지 제시한다. 실무에서 좋은 답은 항상 친절한 답이 아니라, 다음 행동이 분명한 답이다.
uncertainty를 수치로만 표현하면 생기는 문제
가끔 팀에서는 "확신도 80%" 같은 숫자를 붙이고 싶어 한다. 숫자는 보기에는 그럴듯하지만, 실제로는 오해를 부를 수 있다. 모델의 80%가 사람의 80%와 같은 의미가 아니기 때문이다. 특히 내부 기준 없이 숫자를 붙이면 검토자는 그 수치를 객관적 확률처럼 받아들일 수 있다.
따라서 초기 운영에서는 막연한 퍼센트보다 범주형 표현이 더 안전한 경우가 많다. 예를 들어 "직접 근거 확인", "부분 근거 있음", "추정", "확인 불가"처럼 업무적으로 해석 가능한 라벨이 낫다. 나중에 평가 체계가 쌓이면 그때 수치화 여부를 검토해도 늦지 않다.
refusal policy: 답을 멈추는 것도 설계다
검증 가능한 구조를 이야기할 때 refusal policy는 빠질 수 없다. 어떤 요청은 정확히 답하는 것이 목표가 아니라, 아예 답하지 않는 것이 목표이기 때문이다. 민감정보 요청, 권한 밖 데이터 열람, 위험한 행동 가이드, 근거 없는 단정 요구, 허위 문서 작성 같은 경우가 대표적이다.
운영 환경에서 거절은 실패가 아니다. 오히려 잘 설계된 거절은 시스템의 성공 조건이다. 문제는 많은 프롬프트가 거절을 너무 거칠게 하거나, 반대로 지나치게 약하게 만든다는 점이다. 거칠면 사용자 경험이 나빠지고, 약하면 위험한 내용을 슬쩍 제공하게 된다.
좋은 refusal policy는 보통 세 층으로 구성된다.
무엇을 거절할지 정의한다.
어떻게 거절할지 문장 스타일을 정한다.
거절 후 어떤 안전한 대안을 제시할지 정한다.
예를 들어 "사내 인사평가 원문을 그대로 보여 달라"는 요청이 권한 밖이라면, 단순히 "답변할 수 없습니다"로 끝낼 수도 있다. 하지만 더 나은 구조는 이렇다.
"해당 요청은 권한 확인이 필요한 내부 정보 열람에 해당하므로 제공할 수 없습니다. 권한이 확인된 경로를 통해 문서 열람을 요청하거나, 공개 가능한 범위의 정책 요약이 필요하면 그 형태로 도와드릴 수 있습니다."
이 답은 단호하지만 불친절하지 않다. 거절 이유가 정책 기준과 연결되어 있고, 안전한 대안도 제시한다. 실무에서 이런 거절은 서비스 품질을 떨어뜨리기보다 오히려 신뢰를 높인다.
부분 거절과 제한적 응답
모든 거절이 전면 차단일 필요는 없다. 어떤 요청은 핵심 위험 요소만 제거하면 일부 도움을 줄 수 있다. 이를 부분 거절이라고 생각하면 된다.
예를 들어 사용자가 "우리 회사 채용 평가 기준 원문을 보내 주고, 특정 지원자를 탈락시키는 설득 문구도 써 줘"라고 요청했다면, 두 작업은 성격이 다르다. 문서 원문 제공은 권한 문제일 수 있고, 차별적 표현이나 부적절한 인사 조언은 정책 문제일 수 있다. 이 경우 시스템은 위험한 요청은 거절하되, 공개 가능한 채용 원칙 요약이나 공정한 피드백 문구 예시는 제공할 수 있다.
부분 거절은 사용성 측면에서 특히 중요하다. 사용자는 완전 차단보다, 가능한 범위와 불가능한 범위를 명확히 구분해 주는 시스템을 더 신뢰한다.
self-check, compare-and-verify, uncertainty, refusal을 한 흐름으로 묶기
이 네 가지는 따로 떨어진 기능이 아니다. 실제 운영 프롬프트에서는 하나의 흐름으로 엮이는 편이 좋다.
가장 단순한 흐름은 이렇다. 먼저 답변 초안을 만든다. 다음으로 핵심 주장과 근거의 일치 여부를 점검한다. 그 후 불확실한 부분을 라벨링한다. 마지막으로 정책 위반, 권한 초과, 근거 부족이 심한 경우에는 거절 또는 보류로 전환한다.
이 구조를 도식적으로 표현하면 다음과 같다.
초안 생성 → 주장 추출 → 근거 대조 → 불확실성 표시 → 허용 여부 판단 → 최종 응답
이 순서가 좋은 이유는, 답변의 품질 문제와 정책 문제를 한 번에 뒤섞지 않기 때문이다. 먼저 맞는지 보고, 그다음 말해도 되는지를 본다. 이렇게 하면 검증 로직이 더 선명해진다.
검증 가능한 출력 형식의 예
운영 환경에서는 자유서술형 답변보다 검증이 쉬운 출력 틀을 두는 편이 좋다. 예를 들어 내부 지식 도우미라면 아래와 같은 형식을 사용할 수 있다.
최종 답변
사용자 질문에 대한 직접 답변을 한두 문장으로 제시한다.
근거
어떤 문서나 규정의 어떤 내용이 이 답을 뒷받침하는지 적는다.
가정 또는 한계
문서에 직접 없는 해석, 질문의 애매함, 누락된 정보가 있으면 분리해서 적는다.
권장 다음 단계
추가 확인, 사람 검토, 필요한 문서 요청 등 후속 행동을 제시한다.
이 형식은 생각보다 강력하다. 사용자는 첫 줄에서 빠르게 답을 얻고, 검토자는 아래에서 근거와 한계를 확인할 수 있다. 즉, 친절함과 통제 가능성을 동시에 잡는다.
형식이 너무 무거워지는 문제
물론 모든 답에 이렇게 긴 구조를 붙이면 답변이 지나치게 무거워질 수 있다. 그래서 답변 구조는 위험도에 따라 달라져야 한다. 단순한 FAQ와 고위험 정책 답변의 형식이 같을 필요는 없다.
예를 들어 배송 조회처럼 위험이 낮고 사실 구조가 단순한 작업은 짧은 답변만으로 충분할 수 있다. 반면 인사, 법무, 보안, 재무, 의료처럼 틀렸을 때 비용이 큰 답변은 근거와 한계를 분리해 적는 편이 낫다. 즉, 검증 가능한 구조는 늘어나는 장식이 아니라, 위험도에 따라 두께를 조절하는 보호장치다.
프롬프트에 넣어야 할 것은 '사고의 공개'가 아니라 '검증 규칙'이다
이 장의 주제를 다룰 때 자주 생기는 오해가 있다. 검증 가능한 답변 구조를 만들려면 모델의 생각 과정을 전부 출력해야 한다고 여기는 것이다. 하지만 실무에서 정말 필요한 것은 사고의 장황한 노출이 아니다. 필요한 것은 검증 가능한 결과의 구조다.
예를 들어 우리는 모델에게 이렇게 요구할 수 있다. 직접 근거가 있는 주장만 사실처럼 말하라. 추정은 추정이라고 표시하라. 확인할 수 없는 항목은 필요한 추가 정보를 요청하라. 정책 위반 요청은 대안을 포함해 거절하라. 이런 규칙만으로도 답변은 훨씬 더 검토 가능해진다.
즉, 검증 가능성은 '얼마나 길게 생각을 보여 주는가'가 아니라 '얼마나 분명하게 구분해 출력하는가'에서 나온다.
나쁜 답변과 좋은 답변의 차이
같은 질문에 대해 두 답을 비교해 보자.
질문: "이 규정상 외부 협력사에게 고객 이메일 목록을 전달해도 되나요?"
나쁜 답변은 이럴 수 있다.
"업무상 필요하면 전달할 수 있습니다. 다만 보안에 유의하세요."
문장은 짧고 단정적이지만 매우 위험하다. 어떤 조건에서 가능한지, 동의가 필요한지, 계약상 보호조치가 필요한지, 문서 근거가 있는지 아무것도 드러나지 않는다.
좋은 답변은 이렇게 달라진다.
"현재 제공된 규정만으로는 외부 협력사에 고객 이메일 목록을 제공할 수 있다고 단정할 수 없습니다.
확인된 정보: 고객 정보의 외부 제공은 승인 절차와 목적 제한을 따른다는 규정이 있습니다.
확인되지 않은 정보: 협력사 위탁 처리 계약이 체결되어 있는지, 정보주체 고지 또는 동의 요건이 충족되는지는 확인되지 않았습니다.
권장 조치: 관련 승인 절차와 위탁 계약 조항을 확인한 뒤 법무 또는 개인정보 담당자 검토를 거치세요."
이 답은 더 조심스럽지만, 실제 업무에는 훨씬 유용하다. 무턱대고 허용하지 않고, 확인된 것과 확인되지 않은 것을 분리하며, 다음 행동을 분명히 제시한다.
운영 관점에서 가장 중요한 질문
실무자가 프롬프트를 설계할 때는 항상 이 질문을 던져야 한다.
"이 답이 틀렸다면, 어디에서 티가 나는가?"
답이 틀려도 티가 안 나면 운영 리스크가 커진다. 반대로 틀릴 경우 근거 빈칸, 불확실성 표시, 보류 문구, 사람 검토 유도 같은 신호가 남아 있으면 피해를 줄일 수 있다. 검증 가능한 답변 구조는 결국 오류를 완전히 없애는 기술이 아니라, 오류를 숨지 못하게 만드는 기술이다.
이 관점은 매우 중요하다. 완벽한 모델을 기다리는 팀은 늦어진다. 반면 불완전한 모델을 통제 가능한 구조 안에 넣는 팀은 실제로 운영을 시작할 수 있다.
실무용 설계 원칙
이 장의 내용을 프롬프트 설계 원칙으로 정리하면 다음과 같다.
답변, 근거, 한계, 다음 행동을 가능한 한 분리한다.
사실과 추정을 같은 톤으로 섞지 않는다.
self-check는 추상적 반성이 아니라 체크리스트 기반으로 만든다.
compare-and-verify에서는 문장보다 주장 단위로 검증한다.
uncertainty는 단순 사과문이 아니라 상태 라벨과 후속 조치를 포함한다.
refusal policy는 전면 거절, 부분 거절, 안전한 대안을 함께 설계한다.
고위험 업무일수록 검증 가능한 출력 형식을 더 두껍게 적용한다.
이 원칙들은 화려하지 않다. 하지만 운영 환경에서는 이런 평범한 구조가 성능을 지탱한다. 답변의 품질은 멋진 표현보다 검토 가능한 구조에서 오래 살아남는다.
다음 장으로 가기 전에
이번 장에서는 답변 자체를 검증 친화적으로 만드는 방법을 살펴보았다. 핵심은 모델이 덜 틀리게 만드는 것만이 아니라, 틀렸을 때 더 잘 드러나게 만드는 것이다. self-check는 답변 전에 스스로 오류를 점검하게 하고, compare-and-verify는 초안과 근거를 대조하게 하며, uncertainty 표현은 모호함을 숨기지 않게 하고, refusal policy는 멈춰야 할 순간을 분명히 한다.
다음 장에서는 여기서 한 걸음 더 나아간다. 이번 장이 답변 구조를 검증 친화적으로 설계하는 일이었다면, 다음 장은 그 답변을 자동으로 판정하고 걸러내는 검증 프롬프트의 문제를 다룬다. 즉, 이제부터는 답변이 스스로 티 나게 만드는 단계를 넘어, 시스템이 그 티를 자동으로 읽어내는 단계로 들어간다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.