AI가 모르는 내용을 말하게 하는 질문: 확인 불가와 추정 분리
AI에게 질문했을 때 가장 곤란한 답은 모르는 내용을 자연스럽게 확정해서 말하는 것입니다. 보기에는 친절하지만 독자는 어디까지 확인된 사실인지 알 수 없습니다. “모르면 모른다고 해”라는 요청은 도움이 될 수 있지만 그것만으로 오류가 사라지지는 않습니다. 어떤 근거를 사용할지, 자료가 부족할 때 무엇을 남길지, 추정은 어떻게 표시할지를 함께 정해야 합니다. 이 글은 답변을 검증하는 일반적인 체크리스트보다 질문 단계에서 확인 불가와 추정을 나누는 방법에 초점을 맞춥니다.
모르는 이유를 두 가지로 나누기
첫 번째는 질문에 필요한 조건이 빠진 경우입니다. “이 파일이 왜 안 열리나요”라고 물었는데 파일 형식, 사용 앱, 오류 메시지가 없다면 원인을 확정하기 어렵습니다. 이 경우에는 출처를 더 찾기 전에 필요한 조건을 정리해야 합니다. 두 번째는 조건은 있지만 확인할 자료가 없는 경우입니다. 제품 이름과 버전을 알려 줬어도 해당 버전의 공식 문서를 열지 못했다면 기능 지원을 단정할 수 없습니다. 두 상황을 같은 “모름”으로 묶으면 다음 행동을 선택하기 어렵습니다.
AI에게도 이유를 구분해 달라고 요청하세요. “질문 조건이 빠진 것인지, 공식 근거를 확인하지 못한 것인지 나눠 설명해 줘”라고 쓸 수 있습니다. 파일 오류 질문에서는 추가로 필요한 정보를 목록으로 받고, 제품 기능 질문에서는 찾아야 할 공식 문서를 정리할 수 있습니다. 불확실성을 표현한다는 것은 답변을 아무것도 하지 않는 상태로 끝내는 일이 아닙니다. 무엇을 확인하면 판단이 가능해지는지 연결해야 유용한 답이 됩니다.
확인된 사실과 추정을 다른 문장에 쓰기
설명용 문서에 “CSV 파일을 가져올 수 있다”라고 적혀 있고, 내보내기에 대한 내용은 없다고 가정해 봅시다. 여기에서 확인할 수 있는 사실은 가져오기 지원입니다. 내보내기도 지원한다고 말하는 것은 추가 추정이고, 내보내기를 지원하지 않는다고 말하는 것도 자료만으로는 확정할 수 없습니다. “문서에는 내보내기 설명이 없으므로 지원 여부를 확인하지 못했다”라고 쓰면 사실과 자료 부족을 구분할 수 있습니다.
이 차이는 단순한 표현 문제가 아닙니다. 지원되지 않는다고 잘못 단정하면 필요한 기능을 포기할 수 있고, 지원된다고 잘못 단정하면 없는 메뉴를 계속 찾을 수 있습니다. 질문에 “자료에 없는 내용은 지원 안 됨으로 바꾸지 말고 확인 불가로 표시해 달라”고 넣어 보세요. AI가 설명을 완성하기 위해 빈칸을 채우는 대신, 실제로 확인된 범위와 남은 질문을 보여 주도록 결과 형식을 정하는 것입니다. 가상 문서 예시는 실제 제품의 기능 정보를 뜻하지 않습니다.
| 답변 상태 | 표현 예시 | 다음에 할 일 |
| 원문에 명시 | 제공한 문서에 가져오기 지원이 적혀 있음 | 버전·적용 범위 확인 |
| 원문에 없음 | 내보내기 지원 여부는 이 자료로 확인 불가 | 관련 공식 안내 찾기 |
| 조건 부족 | 오류 메시지가 없어 원인 확정이 어려움 | 필요한 조건 수집 |
| 자료 충돌 | 두 문서의 지원 버전이 다름 | 게시일·개정 상태 비교 |
| 설명용 추정 | 이 조건이라면 가능한 원인 예시 | 실제 환경에서 확인 |
확률처럼 보이는 숫자를 주의해서 읽기
AI가 “90% 확실하다”라고 적었다고 해서 실제 검증된 확률을 뜻하는 것은 아닙니다. 어떤 자료와 계산으로 나온 수치인지 없으면 숫자가 정밀한 근거처럼 보일 뿐입니다. 사실 질문에서는 임의의 확신 퍼센트를 요청하는 것보다 근거의 상태를 요청하는 편이 낫습니다. 공식 문서를 직접 열었는지, 어떤 문장이 주장과 연결되는지, 예외가 있는지 확인하세요. 근거가 없는 높은 확신과 근거가 있는 제한된 판단은 서로 다릅니다.
통계 자료에 실제 확률이나 신뢰구간이 있는 경우에도 AI 자신의 확신과 원문 데이터의 값은 구분해야 합니다. 문서에 나온 수치를 인용했다면 표본과 조건을 함께 읽어야 하고, AI가 추정한 값이라면 계산 근거를 확인해야 합니다. “답변의 자신감 수치를 만들지 말고 확인한 근거와 적용 조건을 설명해 달라”는 요청을 사용할 수 있습니다. 숫자를 없애는 것이 목적이 아니라 실제 자료의 숫자와 근거 없는 표현을 구분하는 것이 목적입니다.
불확실성을 포함한 질문 형식
다음은 제품 문서를 확인하는 가상의 요청입니다. “제공한 안내문만 기준으로 파일 가져오기와 내보내기 지원을 정리해 줘. 원문에 명시된 기능, 원문에 없는 기능, 문장이 애매한 기능을 나눠 표로 보여 줘. 원문에 없다는 이유로 지원하지 않는다고 단정하지 마. 버전이나 조건이 필요하면 질문을 남겨 줘. 추정이 꼭 필요한 설명은 사실 문장과 분리하고 어떤 가정에서 가능한지 적어 줘.”
이 요청은 답변을 짧게 만들기보다 검토 가능한 형식으로 만드는 데 목적이 있습니다. 결과가 너무 길면 원문에 명시된 사실을 먼저 보여 주고, 확인할 질문은 뒤에 정리해 달라고 할 수 있습니다. 최신 정보가 필요하다면 공식 자료를 검색해서 실제로 열어 확인하도록 요청하고, 확인 날짜를 남기게 합니다. 링크를 제시했다는 사실만으로 원문을 읽었다고 판단하지 않습니다. 주장과 해당 페이지의 내용이 맞는지 직접 대조할 수 있어야 합니다.
추정이 도움이 되는 경우
자료가 부족해도 가능한 원인을 비교하는 설명은 유용할 수 있습니다. 예를 들어 파일이 안 열린다는 질문에서는 파일 손상, 앱 호환성, 접근 권한 같은 가능성을 나눠 볼 수 있습니다. 다만 이런 목록은 진단 결과가 아닙니다. “가능한 원인 예시”라고 표시하고, 각 원인을 확인하는 관찰을 연결합니다. 같은 앱에서 다른 파일은 열리는지, 같은 파일을 지원 앱에서 열 수 있는지처럼 실제 비교로 범위를 좁히면 추정이 다음 행동으로 이어집니다.
AI에게 하나의 원인을 고르게 하기 전에 확인 비용이 작은 순서로 점검하도록 요청할 수도 있습니다. “파일을 바꾸거나 삭제하기 전에 읽기 전용 확인부터 제안해 줘. 원인별로 관찰할 결과와 다음 단계를 적어 줘”처럼 쓰세요. 현재 정보로 확정할 수 없는 원인을 단정하기보다 조건별 흐름을 만드는 방식입니다. 이때 가상의 단계가 실제 실행되었다고 표현하지 않도록 요청하고, 사용자가 확인한 결과를 다음 질문에 넣어 추정을 갱신합니다.
서로 다른 출처가 충돌할 때
자료 A에는 기능이 지원된다고 쓰였고 자료 B에는 제한이 있다고 쓰였다면 AI가 임의로 평균을 내듯 결론을 만들지 않도록 요청합니다. 제품 버전, 지역, 계정 유형, 게시일, 개정 상태가 다른지 확인해야 합니다. 더 최근인 문서가 초안이고 이전 문서가 현재 유효한 규정일 수도 있습니다. “충돌하는 문장과 각 자료의 적용 범위를 먼저 보여 달라”는 요청이 도움이 됩니다. 원문 차이를 읽은 뒤 어떤 조건에 적용할지 판단할 수 있습니다.
두 자료 중 하나를 열지 못했다면 충돌이 해결되었다고 쓰지 않습니다. 검색 결과의 짧은 소개와 실제 페이지 내용이 다를 수도 있습니다. 자료를 읽지 못한 상태는 별도로 남기고, 접근 가능한 공식 경로를 찾습니다. 공식 자료에도 설명이 없으면 고객 지원에 물어야 할 질문을 정리할 수 있습니다. AI 답변의 역할은 빈 정보를 대신 만들어 내는 것이 아니라 현재 근거와 필요한 확인을 연결하는 데 있습니다.
후속 질문으로 답변을 개선하기
첫 답변이 지나치게 확정적으로 나왔다면 “이 결론을 직접 뒷받침하는 원문 문장과 확인 날짜를 보여 줘. 근거가 없으면 확인 불가로 고쳐 줘”라고 요청할 수 있습니다. 같은 답을 더 자신 있게 반복하도록 하는 질문은 검증에 도움이 되지 않습니다. “정말 맞아?”보다는 무엇을 확인해야 맞는지 구체적으로 묻습니다. 근거가 표시된 뒤에는 실제 원문에 같은 내용이 있는지 읽어야 합니다.
사용자가 조건을 추가하면 답변이 달라질 수 있습니다. 처음에는 Windows 앱을 사용하는 줄 알았는데 실제로는 브라우저에서 문서를 열고 있었다면 확인할 항목이 달라집니다. 이전 답변을 그대로 유지하라고 하기보다 새 조건에 맞춰 어떤 판단이 바뀌는지 설명하게 하세요. 불확실성은 답변의 약점을 숨기는 표현이 아니라 조건이 달라질 때 판단이 어떻게 변하는지 드러내는 정보입니다. 질문의 목적과 근거 상태를 함께 정리하면 후속 답변도 일관되게 검토할 수 있습니다.
완성 답변을 다시 사용할 때
AI 답변을 문서나 블로그로 옮길 때는 확인 불가라는 표시를 지우고 단정 문장으로 바꾸지 않습니다. 읽기 쉬운 표현으로 고치더라도 근거의 상태는 유지하세요. “이 자료에서는 확인하지 못했다”는 문장이 빠지면 독자는 전체 사실이 검증되었다고 생각할 수 있습니다. 확인 날짜와 적용 버전이 중요한 정보라면 본문 가까이 적습니다. 오래된 답변을 새 사실처럼 재사용하지 않도록 이후 검토에 필요한 출처도 함께 남깁니다.
공식 안내와 이 글의 질문 예시는 역할이 다릅니다. 공식 자료는 제품의 기능과 권장 사항을 확인하는 근거이고, 예시는 답변을 검토하기 쉽게 만들기 위한 자체 구성입니다. 예시의 표현을 그대로 사용해도 정확성이 자동으로 보장되지는 않습니다. 실제 자료를 읽고 필요한 조건을 수집하는 과정이 함께 이루어져야 합니다. “모름”을 허용하면서도 다음 확인 방법을 구체적으로 요청하는 것이 이 방식의 핵심입니다.
자주 나오는 질문
모른다고 말하게 하면 답변이 쓸모없어지지 않나요? 확인 불가의 이유와 다음 확인 항목을 함께 요청하면 오히려 판단에 도움이 됩니다. 근거 없는 결론보다 무엇이 부족한지 보여 주는 답변이 실제 작업의 다음 단계로 이어집니다.
AI에게 확신을 말하지 말라고 하면 오류가 없어지나요? 표현을 바꾸는 것만으로 오류가 사라지지는 않습니다. 원문 근거, 적용 범위, 실행 결과를 대조해야 합니다. 불확실성 표시는 확인할 대목을 찾기 위한 도구입니다.
추정은 항상 빼야 하나요? 가능한 원인을 비교하거나 설명용 상황을 이해할 때 추정이 도움이 될 수 있습니다. 사실과 분리하고 가정과 확인 방법을 붙이세요. 추정을 실제 발생한 사건이나 검증한 결과로 소개하지 않으면 독자가 어떤 부분을 확인해야 하는지 알 수 있습니다.
공식 자료와 작성 기준
AI를 활용해 작성한 정보형 원고입니다. 공식 문서는 2026년 10월 3일 확인했으며, 아래 예시는 설명을 위해 구성했습니다. 실제 개인 프로젝트의 실행 성과나 실측값을 뜻하지 않습니다. 발행 전 바뀐 제품 안내를 다시 확인합니다.
AI가 모르는 내용을 말하게 하는 질문
1. 질문 조건 점검
→
2. 근거 상태 구분
→
3. 확인 불가 이유 표시
→
4. 추정의 가정 명시
→
5. 다음 확인 항목 연결
설명을 위한 자체 제작 흐름도이며 실제 제품 화면이나 측정 결과가 아닙니다.
본문의 이해를 돕기 위해 제작한 설명용 삽화입니다.
티스토리 원문 ↗