1장. 생성형 AI 작동 원리와 한계
학습 목표
- 토큰, 컨텍스트 창, 확률적 생성, 지식 기준일을 일상의 비유로 설명한다.
- 모델, 제품, 도구를 구분하고 답이 '생성'된 것인지 '검색'된 것인지 가려낸다.
- 할루시네이션이 생기는 원인을 말하고, 출력을 그대로 믿으면 안 되는 상황을 식별한다.
- 작업의 복잡도와 속도·비용 요구에 맞춰 추론 모델과 일반 모델, 모델 등급을 고른다.
- 이미지·PDF·음성 같은 멀티모달 입력의 쓰임과 오류 유형을 설명한다.
들어가며
구립 도서관 사서 민 주무관은 '청소년 진로 독서 주간'에 쓸 추천 도서 목록을 AI로 만들었습니다. 열두 권의 책이 저자, 출판사, 출간 연도, 한 줄 소개와 함께 깔끔하게 정리되어 나왔습니다. 그런데 목록을 서가와 대조하던 동료가 고개를 갸웃했습니다. 두 권은 어느 서점에도 없는 책이었고, 한 권은 저자는 맞지만 제목이 달랐습니다. 나머지 아홉 권은 정확했습니다. 목록이 그대로 게시판에 붙었다면 학생들은 없는 책을 찾아 헤맸을 것입니다.
민 주무관이 놀란 점은 틀린 책도 맞는 책과 똑같은 말투와 형식으로 적혀 있었다는 것입니다. AI는 "이 두 권은 자신 없습니다"라고 말하지 않았습니다. AI는 어떻게 이런 목록을 만들었을까, 왜 아홉 권은 맞고 세 권은 틀렸을까, 무엇을 보면 틀린 것을 미리 알 수 있을까.
이 장은 그 질문에 답합니다. 먼저 AI가 글을 다루는 단위(토큰)와 한 번에 볼 수 있는 양(컨텍스트 창)을 이해하고, 답을 만드는 방식(확률적 생성)과 아는 것의 시간적 한계(지식 기준일)를 봅니다. 이어서 할루시네이션의 원인과 유형, 추론 모델과 일반 모델의 차이, 이미지와 문서 입력의 한계를 다룹니다. 마지막에는 "언제 출력을 그대로 믿으면 안 되는가"를 점검표로 정리합니다. AI 활용 역량 가운데 분별(Discernment)의 기초가 되는 장입니다.
핵심 개념
모델, 제품, 도구를 구분하기
AI 이야기를 할 때 가장 먼저 구분할 세 가지가 있습니다.
- 모델: 글을 읽고 다음 글을 만들어 내는 계산 엔진입니다. 자동차로 치면 엔진입니다.
- 제품: 사람이 모델을 쓰도록 만든 서비스입니다. 대화 화면, 파일 업로드, 대화 기록, 공유 기능이 여기에 속합니다. ChatGPT, Claude, Gemini 같은 이름은 보통 제품 이름이고, 그 안에서 여러 모델이 돌아갑니다. 자동차로 치면 차체와 계기판입니다.
- 도구: 모델이 답을 만들 때 불러 쓰는 별도 기능입니다. 웹 검색, 계산을 위한 코드 실행, 사내 문서 검색, 외부 앱 연결이 대표적입니다. 자동차로 치면 내비게이션입니다.
오류가 어디서 생겼는지에 따라 대응이 달라집니다. 같은 모델이라도 검색 도구를 켠 제품과 끈 제품은 최신 정보에 전혀 다른 답을 냅니다. "AI가 틀렸다"에서 멈추지 말고 "모델이 틀렸나, 도구가 꺼져 있었나, 제품이 오래된 자료를 넣었나"를 묻는 습관이 이 장의 출발점입니다.
토큰: 모델이 글을 자르는 단위
모델은 글을 사람처럼 단어 단위로 읽지 않습니다. 글을 토큰이라는 조각으로 잘라 처리합니다. OpenAI는 토큰이 글자 하나일 수도, 단어의 일부나 단어 전체, 문장부호일 수도 있으며, 공백도 자르는 방식에 영향을 준다고 설명합니다. 레고로 비유하면 같은 집을 지어도 어떤 블록 세트를 쓰느냐에 따라 필요한 블록 수가 달라지는 것과 같습니다.
토큰 수와 글자 수, 단어 수는 일대일로 대응하지 않습니다. 같은 글도 모델, 모델이 쓰는 인코딩(토크나이저가 글을 토큰으로 바꾸는 규칙), 언어에 따라 토큰 수가 달라집니다. 회사들이 내놓는 어림값은 영어 기준입니다.
| 회사 | 공식 문서의 어림값 | 단서 |
|---|---|---|
| OpenAI | 영어 기준 1토큰은 약 4글자, 100토큰은 단어 약 75개 | 다른 언어는 관계가 다르다고 명시 |
| Gemini 기준 1토큰은 약 4글자, 100토큰은 영어 단어 60~80개 | 이미지·음성·영상도 토큰으로 계산 |
한국어 문서와 영어 번역본의 토큰 수가 다르게 나오는 것은 자연스러운 일입니다. 영어 어림값을 한국어 문서에 그대로 곱해 분량을 추정하면 크게 빗나갈 수 있습니다. 정확한 수가 필요하면 제품이나 개발자 도구가 제공하는 토큰 계산 기능으로 직접 세는 것이 원칙입니다.
토큰은 크게 세 종류로 나뉩니다.
| 종류 | 뜻 | 왜 알아야 하나 |
|---|---|---|
| 입력 토큰 | 모델에 보낸 지시, 자료, 대화 이력 | 길게 붙여 넣을수록 늘어남 |
| 출력 토큰 | 모델이 만든 답 | 긴 보고서를 요청하면 늘어남 |
| 추론 토큰 | 추론 모델이 답하기 전에 속으로 쓰는 토큰 | 모델이 만들어 낸 토큰이라 보이지 않아도 출력으로 집계·과금 |
토큰은 한도와 비용의 단위입니다. 한 번에 다룰 수 있는 양이 토큰으로 정해지고, 언어 모델 API의 기본 요금도 주로 토큰으로 계산합니다. OpenAI는 다른 기능에는 다른 과금 단위가 쓰일 수 있다고 덧붙입니다. OpenAI는 추론 토큰이 답의 글자로 보이지 않아도 출력 토큰으로 과금되므로 짧은 답도 많은 토큰을 쓸 수 있다고 안내합니다.
컨텍스트 창: 책상 위 작업 공간
컨텍스트 창은 모델이 답을 만들 때 한꺼번에 참고하는 글 전체의 크기입니다. Anthropic은 컨텍스트 창이 모델이 학습한 방대한 자료와는 다른 '작업 기억'이며, 지시문과 대화 이력, 첨부한 이미지와 문서, 도구 결과, 그리고 지금 만들고 있는 답까지 모두 여기에 들어간다고 설명합니다. 학습 데이터가 모델이 오랫동안 쌓은 도서관이라면, 컨텍스트 창은 지금 펼쳐 놓은 책상입니다.
책상이 넓다고 일을 더 잘하는 것은 아닙니다. Anthropic은 토큰이 늘어날수록 정확도와 회상이 떨어지는 현상을 컨텍스트 부패(context rot) 라고 부르고, 무엇을 넣을지 고르는 일이 공간의 크기만큼 중요하다고 강조합니다. 또 채팅 화면은 대화가 길어지면 오래된 내용부터 밀어내는 '먼저 들어온 것이 먼저 나가는'(선입선출) 방식으로 컨텍스트를 관리할 수 있다고 적어 둡니다. 긴 대화에서 초반에 정한 조건이 흐려지는 이유가 여기에 있습니다. 넣을 수 있다는 것과 빠짐없이 활용한다는 것은 다릅니다. 조건이 여러 문서에 흩어져 있거나, 폐기된 판본이 섞여 있거나, 결론을 바꾸는 예외가 각주에 있을 때 특히 누락이 잦습니다.
컨텍스트 창과 함께 알아 둘 것이 출력 한도입니다. 모델은 한 번의 응답으로 만들 수 있는 토큰 수에도 상한이 있습니다. OpenAI는 컨텍스트 창과 별도로 출력 한도가 있고, 추론 모델은 보이는 답 외에 추론 토큰이 쓸 공간도 남겨야 한다고 안내합니다. 긴 문서를 통째로 넣는 것은 받아들여져도, 그만큼 긴 결과를 한 번에 돌려받지는 못할 수 있다는 뜻입니다. 입력은 책상 넓이, 출력은 한 번에 쓸 수 있는 원고지 장수라고 생각하면 됩니다. API에서는 입력만으로 창을 넘으면 요청이 오류로 돌아온다고 Anthropic은 안내합니다.
핵심
긴 작업을 이어 갈 때는 지금까지 확정한 조건과 결정 사항을 짧게 요약해 새 대화의 첫 메시지로 주세요. 책상을 정리하고 필요한 서류만 다시 올려놓는 것과 같습니다. 결과가 길면 장이나 절 단위로 나눠 요청하세요.
확률적 생성: 아주 강력한 자동완성
생성형 AI는 지금까지의 글을 보고 다음에 올 토큰으로 그럴듯한 것을 확률에 따라 골라 이어 씁니다. 휴대폰 자판의 자동완성을 훨씬 크고 정교하게 만든 것이라고 생각하면 쉽습니다. 이 방식에서 두 가지 성질이 나옵니다.
- 같은 질문에도 답이 조금씩 달라질 수 있습니다. 그럴듯한 후보가 여럿이면 매번 다른 것이 뽑힐 수 있기 때문입니다.
- 생성 과정 자체에는 '사실인지 확인하는 단계'가 없습니다. 모델은 문장이 자연스러운지를 기준으로 이어 쓰며, 문장이 참인지는 따로 확인하지 않습니다.
개발자용 API에는 무작위성의 정도를 조절하는 temperature(온도) 라는 설정이 있습니다. Google은 낮은 온도가 정해진 답이 필요한 작업에, 높은 온도가 다양한 답이 필요한 작업에 맞는다고 설명합니다. 그러나 Anthropic의 API 문서는 온도를 0으로 낮춰도 결과가 완전히 같아지지는 않는다고 적어 두었고, 최근 모델 일부는 온도 설정을 받지 않거나 무시합니다. 무엇보다 온도를 낮춘다고 정확해지지는 않습니다. 틀린 답을 매번 똑같이 낼 수도 있고, Google은 일부 모델에서 기본값을 바꾸면 추론 성능이 떨어질 수 있으니 기본값을 유지하라고 안내합니다.
그래서 같은 답이 반복된다고 해서 사실이 되지는 않습니다. 반대로 같은 질문을 여러 번 했는데 답이 서로 어긋난다면 의심할 신호입니다. Anthropic은 같은 지시로 여러 번 실행해 결과를 비교하는 방법을 소개하면서, 결과 사이의 불일치가 할루시네이션을 가리킬 수 있다고 설명합니다. 일관성은 진실의 증거가 아니지만, 불일치는 경고등이 될 수 있다는 비대칭을 기억하세요.
지식 기준일: 출국 전에 읽은 마지막 신문
모델은 특정 시점까지의 자료로 학습합니다. 그 이후의 일은 거의 모르거나 부정확하게 알기 때문에, 검색이나 첨부 같은 외부 근거로 확인해야 합니다. 오랫동안 남극 기지에서 근무하다 돌아온 사람이 출국 전에 읽은 마지막 신문까지만 아는 것과 같습니다.
Anthropic의 모델 문서는 두 날짜를 구분해 적습니다. 신뢰할 수 있는 지식 기준일(reliable knowledge cutoff) 은 모델의 지식이 가장 폭넓고 믿을 만한 시점이고, 학습 데이터 기준일(training data cutoff) 은 학습에 쓴 자료의 더 넓은 범위입니다. 두 날짜 사이의 사건은 모델이 조금은 알지만 얕거나 부정확하게 알 수 있다는 뜻입니다. 기준일 바로 전의 일도 세상에 글이 충분히 쌓이기 전이라 학습 자료가 적을 수 있습니다.
실무에서는 날짜를 외우는 것보다 이 질문이 시간이 지나면 답이 바뀌는 종류인가를 판단하는 능력이 더 중요합니다.
| 잘 바뀌지 않는 것 | 자주 바뀌는 것 |
|---|---|
| 맞춤법 원리, 수학 공식, 오래된 역사적 사실 | 가격, 환율, 금리, 재고 |
| 일반적인 글쓰기 구조 | 법령 개정과 새 시행일, 정부 지원 사업 공고 |
| 널리 알려진 개념의 정의 | 담당자, 연락처, 영업시간, 제품 기능과 요금제 |
오른쪽 칸의 질문은 지식 기준일 이전 정보라도 이미 바뀌었을 수 있습니다. 이런 질문에는 최신 자료를 첨부하거나 검색 기능을 켜고, 답에 기준 시점을 적게 하는 것이 원칙입니다.
주의
컨텍스트 창이 큰 모델이라고 최신 정보를 아는 것은 아닙니다. 컨텍스트 창은 '한 번에 읽을 수 있는 양'이고, 지식 기준일은 '학습한 시점'입니다. 두 개념을 섞은 설명은 시험의 대표적인 오답입니다.
생성과 검색: 답을 만들 때와 찾아올 때
AI 제품의 답은 두 가지 방식으로 만들어집니다. 하나는 모델이 학습한 지식만으로 답을 생성하는 것이고, 다른 하나는 검색이나 문서 조회로 자료를 찾아온 뒤 그 자료를 근거로 답을 만드는 것입니다. 뒤의 방식을 그라운딩(grounding) 이라고 부릅니다. 땅에 말뚝을 박듯 답을 실제 자료에 묶어 둔다는 뜻입니다.
Google은 Gemini의 Google 검색 그라운딩이 모델의 지식 기준일 이후의 최근 정보에 답하게 해 주고, 답과 출처를 연결하는 인용을 돌려주어 사용자가 직접 확인할 수 있게 한다고 설명합니다. 사내 문서를 검색해 답하는 기능도 같은 원리입니다.
그라운딩은 강력하지만 만능이 아닙니다. 검색을 했어도 다음 오류는 그대로 생길 수 있습니다.
- 검색 결과 자체가 오래되었거나 틀렸습니다.
- 모델이 검색 결과를 잘못 해석하거나, 여러 출처의 내용을 섞습니다.
- 인용은 달려 있지만 인용된 문단이 실제로는 그 주장을 뒷받침하지 않습니다.
그래서 답의 출처 표시를 보는 일은 검증의 시작이지 끝이 아닙니다. 4장에서 출처를 주장 단위로 대조하는 절차를 자세히 다룹니다.
할루시네이션의 원인과 유형
할루시네이션은 모델이 사실과 다르거나 주어진 자료와 어긋나는 내용을 그럴듯하게 만들어 내는 현상입니다. Anthropic은 가장 앞선 모델도 사실과 다르거나 주어진 맥락과 맞지 않는 글을 만들 수 있다고 인정합니다. '틀렸다'로 뭉뚱그리지 말고 유형을 나눠 보면 대응이 보입니다.
| 유형 | 모습 | 주된 원인 | 대응 |
|---|---|---|---|
| 지어낸 출처 | 없는 책, 논문, 판례, 링크 | 확률적 생성이 '그럴듯한 형식'을 만들어 냄 | 출처를 원문에서 직접 열어 확인 |
| 바뀐 숫자와 날짜 | 실제 통계의 값이나 연도가 미묘하게 다름 | 기억이 흐릿한 영역을 자연스러운 값으로 채움 | 원자료와 숫자 대조, 계산은 도구로 |
| 오래된 정보 | 이미 바뀐 규정이나 가격 | 지식 기준일 | 최신 자료 첨부, 검색, 기준 시점 표시 |
| 자료 밖 내용 섞기 | 첨부에 없는 내용을 덧붙임 | 일반 지식을 자료와 구분하지 않음 | "자료에 있는 내용만" 지시, 인용 요구 |
| 자료 사이의 혼동 | A 문서의 내용을 B의 것으로 적음 | 긴 컨텍스트, 비슷한 문서 | 문서마다 이름 붙이기, 출처 표시 요구 |
| 추론 오류 | 전제는 맞지만 결론이 틀림 | 단계를 건너뛴 판단 | 전제와 계산 과정을 확인 가능하게 요구 |
Anthropic이 권하는 기본 대책은 세 가지입니다. 확실하지 않으면 모른다고 말할 수 있게 허용하기, 긴 문서에서는 답하기 전에 관련 문장을 그대로 인용하게 하기, 주장마다 인용과 출처를 달게 하고 뒷받침하는 문장을 찾지 못한 주장은 철회하게 하기입니다. 여기에 "제공한 문서의 정보만 쓰고 일반 지식은 쓰지 말라"고 범위를 제한하는 방법도 있습니다. Anthropic은 이런 기법이 할루시네이션을 크게 줄이지만 없애지는 못하므로, 중요한 정보와 고위험 결정은 언제나 확인하라고 덧붙입니다.
말투의 자신감과 근거의 강도
AI의 답은 틀릴 때도 유창하고 단정적이며, 사람은 자신 있게 말하는 쪽을 더 믿기 쉽습니다. 들어가며의 틀린 세 권도 맞는 아홉 권과 똑같은 말투였습니다. 말투의 자신감과 근거의 강도는 별개입니다.
비슷한 현상으로 아첨(sycophancy) 이 있습니다. Anthropic의 연구는 아첨을 모델이 진실한 답보다 사용자의 믿음에 맞는 답을 내는 행동으로 정의하고, 사람의 선호 평가가 그럴듯하게 쓴 아첨형 답을 정확한 답보다 좋게 평가하는 일이 원인의 일부라고 봅니다. 실무에서는 이렇게 나타납니다.
- 사용자가 "정말? 내가 알기로는 다른데"라고 반박하면 근거 없이 답을 바꿉니다.
- 질문에 원하는 결론이 들어 있으면 그 결론을 뒷받침하는 쪽으로 기웁니다.
- 사용자가 쓴 초안을 평가해 달라고 하면 실제보다 후하게 평가합니다.
대응은 간단합니다. 답이 바뀌었을 때 어느 쪽이 맞는지를 모델의 태도로 판단하지 말고 외부 근거로 판단합니다. 질문은 원하는 결론을 드러내지 않게 중립적으로 쓰고, 평가를 받을 때는 "약점 세 가지를 먼저 찾아라"처럼 비판할 자리를 명시합니다.
추론 모델과 일반 모델
요즘 AI 제품은 대부분 여러 종류의 모델을 함께 제공합니다. 그중 추론 모델은 답하기 전에 속으로 여러 단계를 따져 보는 모델이고, 일반 모델은 지시를 받으면 곧바로 답을 이어 쓰는 모델입니다. OpenAI는 이를 '계획가(planner)'와 '일꾼(workhorse)'에 비유하며, 한쪽이 더 좋은 것이 아니라 서로 다를 뿐이고 대부분의 업무 흐름은 둘을 섞어 쓴다고 설명합니다.
| 구분 | 추론 모델 | 일반 모델 |
|---|---|---|
| 강점 | 모호하고 복잡한 다단계 판단, 흩어진 정보 속 관계 찾기, 다른 결과물 평가 | 명확하게 정의된 작업의 빠른 실행 |
| 약점 | 느리고, 추론 토큰 때문에 비용이 큼 | 복잡한 판단에서 단계를 건너뛸 수 있음 |
| 어울리는 일 | 여러 안의 장단점 비교 메모, 모순된 요구사항 정리, 계획 수립 | 형식 변환, 대량 분류, 짧은 초안, 번역 초벌 |
두 가지 오해를 피해야 합니다. 첫째, 추론 모델이라고 최신 지식을 더 많이 아는 것은 아닙니다. 추론 능력은 '주어진 정보로 얼마나 잘 따지는가'이고, 지식의 최신성은 지식 기준일과 검색 여부로 정해집니다. 둘째, 오래 생각한 결과도 틀릴 수 있습니다. 추론 모델의 결론 역시 근거와 계산을 확인해야 합니다. 추론 모델에 지시하는 방법은 일반 모델과 조금 다른데, 이는 2장 깊이 읽기에서 다룹니다.
작업 난이도에 맞는 모델 등급 고르기
회사들은 같은 계열 안에서도 크고 느리며 비싼 모델부터 작고 빠르며 싼 모델까지 여러 등급을 내놓습니다. Anthropic의 모델 비교표는 가장 빠른 등급을 분류, 추출, 라우팅처럼 처리량이 많고 응답 속도가 중요한 작업용으로, 가장 큰 등급을 까다로운 추론과 긴 작업용으로 설명합니다.
등급을 고를 때는 다음 네 가지를 묻습니다.
- 판단이 얼마나 복잡한가? 규칙이 분명한 일인가, 여러 조건을 저울질해야 하는 일인가.
- 얼마나 많이, 얼마나 빨리 처리해야 하는가? 하루 수천 건인가, 한 달에 몇 건인가. 몇 초 안에 답해야 하는가.
- 틀리면 얼마나 해로운가? 사람이 바로 고칠 수 있는가, 외부로 나가 되돌리기 어려운가.
- 작은 모델로 충분한지 확인했는가? 대표 사례 몇십 건으로 작은 모델과 큰 모델을 비교해 보았는가.
마지막 질문이 핵심입니다. 등급표나 이름보다 자기 업무의 대표 사례로 해 본 작은 비교 실험이 더 믿을 만한 근거입니다. 정확도, 누락, 속도, 사람이 고치는 데 든 시간을 기록하면 어느 등급이 필요한지 숫자로 보입니다. 처리량이 많은 업무에서는 쉬운 요청은 작은 모델로, 어려운 요청만 큰 모델로 보내는 나눠 보내기(라우팅) 설계도 흔히 씁니다.
멀티모달 입력
멀티모달은 글뿐 아니라 이미지, PDF, 음성, 영상 같은 여러 형식의 입력을 다루는 능력입니다. 영수증 사진에서 금액을 읽거나, 그래프 이미지의 추세를 설명하게 하거나, 회의 녹음을 요약하게 할 수 있습니다.
멀티모달 입력에서 알아 둘 성질은 세 가지입니다.
- 이미지와 소리도 토큰을 씁니다. Google은 이미지, 영상, 음성을 정해진 규칙으로 토큰 수로 바꿔 센다고 안내하고, Anthropic은 이미지를 작은 조각 단위로 나눠 토큰으로 계산합니다. 사진으로 찍어 올린 문서도 공간을 차지하며, 글로 넣을 때보다 적게 쓰는지는 해상도와 모델에 따라 다릅니다. 이미지가 줄어들면 작은 글씨를 읽기 어려워진다는 점도 함께 기억하세요.
- 읽기 오류의 종류가 따로 있습니다. Anthropic은 화질이 낮거나 회전되었거나 아주 작은 이미지를 해석할 때 틀릴 수 있고, 위치 관계 판단은 근사치이며, 작은 물체가 많으면 개수를 정확히 세지 못할 수 있다고 밝힙니다. 실무에서는 작은 글씨와 흐린 스캔, 표의 행과 열 대응, 차트의 축과 단위와 범례가 대표적인 오독 지점입니다.
- 판별할 수 없는 것이 있습니다. Anthropic은 모델이 이미지가 AI로 만든 것인지 판별하지 못하므로 위조 이미지 탐지에 기대지 말라고 안내합니다.
음성은 받아쓰기 단계와 해석 단계로 나눠 봅니다. 사람 이름, 전문 용어, 겹쳐 말한 부분은 받아쓰기에서, 누가 무엇에 동의했는지는 해석에서 틀리기 쉽습니다.
Anthropic은 이미지가 글보다 앞에 올 때 결과가 가장 좋다고 안내합니다. 그리고 숫자가 중요한 자료라면 이미지보다 원본 파일(스프레드시트, 원문 텍스트)을 주는 편이 정확합니다.
출력을 그대로 믿으면 안 되는 상황
지금까지의 개념을 하나의 점검표로 묶습니다. 다음 중 하나라도 해당하면 출력을 그대로 쓰지 말고 확인 절차를 거칩니다.
| 신호 | 왜 위험한가 | 확인 방법 |
|---|---|---|
| 최근 정보이거나 자주 바뀌는 정보 | 지식 기준일, 오래된 검색 결과 | 최신 원문, 기준 시점 확인 |
| 구체적인 숫자, 날짜, 고유명사 | 그럴듯한 값을 채워 넣기 쉬움 | 원자료와 대조 |
| 계산과 집계 | 모델은 셈을 머릿속으로 흉내 냄 | 스프레드시트나 코드 실행으로 재계산 |
| 출처, 인용, 링크 | 지어낸 출처, 뒷받침하지 않는 출처 | 원문을 열어 해당 문단 확인 |
| 첨부 자료 밖의 내용 | 일반 지식이 섞임 | 근거 문장 표시 요구 |
| 이미지·스캔·음성에서 읽은 값 | 오독 | 원본 대조 |
| 외부 공개나 되돌리기 어려운 결정에 쓰임 | 틀렸을 때 피해가 큼 | 사람의 검토와 승인 |
출력의 종류에 따라 검증 방법도 다릅니다. 사실은 원문과 대조하고, 계산은 다른 방법으로 다시 계산하고, 해석은 전제와 반례를 확인하고, 창작은 목적·독자·제약에 맞는지 봅니다. 모든 결과를 같은 방식으로 검토하면 중요한 오류를 놓칩니다.
깊이 읽기
계산과 집계는 왜 도구에 맡기는가
언어 모델은 숫자를 계산하는 기계가 아니라 다음에 올 토큰을 예측하는 기계입니다. 짧은 덧셈은 대개 맞히지만, 행이 많은 표의 합계, 비율과 증감률, 여러 조건을 건 집계에서는 그럴듯하지만 틀린 숫자를 낼 수 있습니다. 문제는 틀린 숫자도 맞는 숫자와 똑같이 자연스럽게 보인다는 점입니다.
Google은 산술, 개수 세기, 계산이 필요한 작업에는 코드 실행 도구를 쓰라고 권합니다. 코드 실행은 모델이 계산 과정을 프로그램으로 써서 실제로 돌려 보는 기능입니다. 사람이 결과뿐 아니라 계산식도 확인할 수 있다는 장점이 있습니다. 코드 실행 기능이 없는 환경이라면 계산은 스프레드시트에 맡기고, AI에게는 계산 결과를 해석하거나 문장으로 정리하는 일만 맡기는 것이 안전합니다.
이 원칙은 "AI는 숫자에 약하니 숫자 업무에는 쓰지 말라"는 뜻이 아닙니다. 역할을 나누라는 뜻입니다. 계산은 계산이 확실한 도구가, 해석과 서술은 언어 모델이 맡고, 사람은 둘의 연결이 맞는지 확인합니다. 보고서에 들어갈 숫자라면 누가 어떤 방법으로 계산했는지 다시 따라갈 수 있어야 합니다.
같은 이름의 모델도 바뀐다: 버전과 재현성
어제와 같은 지시를 넣었는데 오늘 답의 형식이 달라지는 일이 있습니다. 확률적 생성 때문일 수도 있지만, 제품 뒤에서 모델 자체가 바뀌었기 때문일 수도 있습니다. 채팅 제품의 기본 모델은 제품이 업데이트되면서 새 버전으로 바뀔 수 있습니다. 개발자용 API에서는 회사들이 특정 시점의 모델을 고정한 스냅숏 이름을 제공하고, OpenAI는 일관된 동작이 필요한 운영 환경이라면 특정 스냅숏에 고정하고 프롬프트의 동작을 재는 평가 세트를 만들어 두라고 권합니다.
그래서 팀의 템플릿 지시문이 갑자기 다르게 동작하면 지시문만 탓하지 말고 모델이나 설정이 바뀌었는지 확인합니다. 꾸준히 쓰는 AI 기능이라면 대표 사례 10~20건과 기대 결과를 묶은 점검 세트를 만들어 두고, 모델이 바뀔 때마다 같은 사례로 다시 돌려 차이를 찾습니다.
실무 장면
새벽베이커리 구매팀의 버터 단가 보고서
수제 디저트 프랜차이즈 '새벽베이커리' 본사 구매팀의 오 대리는 다음 달 버터 구매량을 정하기 위한 가격 동향 보고서를 써야 한다. 그는 웹 검색이 꺼진 사내 AI 도구에 "최근 3개월 국내 버터 도매가 추이와 다음 달 전망을 정리해 줘"라고 물었고, 월별 가격과 전망이 담긴 깔끔한 표를 받았다.
오 대리는 표를 바로 붙여 넣으려다 세 가지 질문을 떠올린다.
- 이 정보는 언제 것인가? 최근 3개월 가격은 지식 기준일 이후일 가능성이 크다. 검색이 꺼져 있으니 모델은 실제 가격을 볼 수 없었다.
- 이 숫자는 어디서 왔나? 표에 출처가 없다. 구체적인 숫자일수록 확률적 생성이 채운 '그럴듯한 값'일 수 있다.
- 틀리면 얼마나 해로운가? 구매량 결정에 쓰이는 숫자이고, 잘못 사면 재고 손실로 이어진다.
오 대리가 처음 떠올린 대안은 두 가지였다. 하나는 같은 질문을 몇 번 더 해서 숫자가 같으면 쓰는 방법이었지만, 반복이 사실 확인을 대신하지 못한다는 점에서 버렸다. 다른 하나는 검색을 켜고 다시 묻는 방법이었는데, 검색 결과가 소매가와 도매가를 섞을 수 있고 회사가 실제로 받는 단가와 다를 수 있다는 점에서 보조 수단으로만 쓰기로 했다.
결국 그는 거래처 세 곳에서 받은 최근 3개월 단가표 PDF를 첨부하고 이렇게 다시 요청했다. "첨부 자료에 있는 숫자만 쓰고, 표의 각 값 옆에 근거가 된 문서 이름과 쪽 번호를 적어라. 자료에 없는 달은 '자료 없음'으로 표시하라. 평균과 증감률은 직접 계산하지 말고 계산할 열만 표시하라." 평균과 증감률은 스프레드시트로 따로 계산했다. 전망은 별도 요청으로 나눠 "위 표의 추세를 설명하되, 확인된 사실과 추정을 문단으로 구분하라"고 지시했다.
결과는 처음보다 덜 화려했지만, 모든 숫자에 근거가 붙었고 빠진 달은 빈칸으로 드러났다. 오 대리는 PDF 원본과 표를 한 번 대조한 뒤 보고서에 넣었다. 핵심은 모델의 능력을 의심한 것이 아니라, 모델이 볼 수 없는 정보와 확인하지 않는 방식을 이해하고 그 빈자리를 근거와 도구로 채운 데 있다.
여름숲캠핑 운영팀의 대시보드 캡처 보고
캠핑용품 온라인몰 '여름숲캠핑' 운영팀의 강 매니저는 매주 월요일 임원 회의에 주간 실적 요약을 올린다. 그는 시간을 줄이려고 판매 대시보드 화면을 캡처한 이미지 세 장을 AI에 넣고 "지난주 실적을 다섯 줄로 요약해 줘"라고 요청했다. 대시보드에는 왼쪽 축이 매출액, 오른쪽 축이 전환율인 이중 축 그래프와, 작은 글씨로 된 카테고리별 표가 있었다.
요약은 그럴듯했지만 팀원이 두 군데를 짚었다. 전환율이 실제의 열 배로 적혀 있었고, 표의 '텐트' 행 매출이 바로 아래 '타프' 행 값으로 바뀌어 있었다. 강 매니저는 원인을 이렇게 나눠 보았다. 전환율 오류는 두 축의 단위를 혼동한 해석 오류이고, 행 바뀜은 작은 글씨 표에서 행과 열을 잘못 대응한 읽기 오류였다.
강 매니저는 세 선택지를 따졌다. 캡처 해상도를 높이면 읽기 오류는 줄지만 축 해석 오류가 남는다. 이미지를 아예 쓰지 않으면 오독은 없지만 추세를 한눈에 설명받는 장점까지 잃는다. 그래서 숫자는 원본 파일로, 이미지는 추세 설명에만 쓰기로 했다.
그는 대시보드에서 내려받은 CSV 파일을 숫자의 근거로 첨부하고, 합계와 전주 대비 증감은 스프레드시트에서 계산한 값을 함께 넣었다. 이미지는 "그래프에서 눈에 띄는 변화 두 가지를 말로 설명하라. 숫자는 쓰지 마라"는 요청에만 썼다. 이 주간 요약은 매주 같은 형식으로 반복되는 가벼운 작업이라, 큰 추론 모델 대신 빠른 일반 모델로도 기준을 통과하는지 4주 동안 비교해 보았다. 결과가 같아 빠른 모델로 정착시켰다.
핵심은 이미지가 잘하는 일(전체 모습의 설명)과 원본 데이터가 잘하는 일(정확한 숫자)을 나누고, 오류를 읽기와 해석 단계로 나눠 대응한 데 있다.
자주 틀리는 지점
- "구체적이면 정확하다." 사건 번호, 날짜, 소수점까지 있는 숫자는 믿음직해 보입니다. 그러나 확률적 생성은 형식이 그럴듯한 가짜 정보를 쉽게 만듭니다. 구체성은 오히려 확인할 신호입니다.
- "여러 번 물어 같은 답이면 사실이다." 같은 모델은 같은 오류를 반복할 수 있습니다. 반복은 사실 확인을 대신하지 못합니다. 다만 답이 서로 어긋나면 의심 신호로 쓸 수 있습니다.
- "온도를 0으로 낮추면 정확해진다." 온도를 낮춰도 정확도는 보장되지 않고, 0에서도 결과가 완전히 같아지지 않을 수 있으며, 모델에 따라 기본값을 바꾸면 오히려 성능이 떨어지기도 합니다. 정확도는 근거 제공과 검증으로 확보합니다.
- "컨텍스트 창이 크면 최신 정보도 안다." 컨텍스트 창은 읽을 수 있는 양이고 지식 기준일은 학습 시점입니다. 서로 다른 축입니다.
- "출처가 달려 있으면 검증된 것이다." 출처가 실재해도 그 문단이 주장을 뒷받침하지 않을 수 있고, 검색 결과 자체가 낡았을 수 있습니다. 출처 표시는 확인의 출발점입니다.
- "반박했더니 답을 고쳤으니 이제 맞다." 모델은 사용자의 반박에 맞춰 답을 바꾸는 경향이 있습니다. 어느 답이 맞는지는 외부 근거로 판단합니다.
- "비싼 추론 모델이 언제나 낫다." 단순 대량 작업에 추론 모델을 쓰면 느리고 비싸기만 할 수 있습니다. 추론 모델이 최신 지식을 더 아는 것도 아닙니다.
- "사진으로 올리면 공간도 덜 쓰고 숫자도 정확히 읽는다." 이미지도 컨텍스트 창을 차지하며 절약 여부는 해상도에 따라 다르고, 작은 글씨와 표와 차트 축은 대표적인 오독 지점입니다.
한눈에 정리
| 개념 | 한 줄 정의 | 시험에서 기억할 것 |
|---|---|---|
| 모델·제품·도구 | 엔진·차체·내비게이션 | 오류가 어디서 생겼는지부터 구분 |
| 토큰 | 모델이 글을 자르는 조각 | 글자·단어 수와 다름, 언어마다 다름, 추론 토큰은 출력으로 과금 |
| 컨텍스트 창 | 한 번에 참고하는 작업 기억 | 클수록 좋은 것이 아님(컨텍스트 부패), 출력 한도는 별도 |
| 확률적 생성 | 그럴듯한 다음 토큰 고르기 | 사실 확인 단계 없음, 일관성은 증거가 아님, 불일치는 경고 |
| 온도 | 무작위성 설정 | 낮춰도 정확도 보장 안 됨, 0도 완전한 재현 아님 |
| 지식 기준일 | 학습 자료의 기준 시점 | 두 기준일 구분, 자주 바뀌는 정보는 최신 근거 필요 |
| 그라운딩 | 검색·문서로 답을 근거에 묶기 | 출처 표시는 검증의 시작 |
| 할루시네이션 | 그럴듯하게 틀리는 현상 | 모른다고 허용, 인용 먼저, 근거 없으면 철회 |
| 아첨 | 사용자 믿음에 맞추는 경향 | 반박에 답이 바뀌면 외부 근거로 판단 |
| 추론 모델 | 계획가: 복잡한 판단 | 느리고 비쌈, 최신성과 무관 |
| 모델 등급 | 큰 모델과 작은 모델 | 대표 사례로 비교 실험, 쉬운 것과 어려운 것 나눠 보내기 |
| 멀티모달 | 이미지·PDF·음성 입력 | 토큰 사용, 읽기 오류와 해석 오류, 숫자는 원본으로 |
공식 문서로 확인하기
- OpenAI — Understanding and counting tokens: 토큰의 정의, 영어 기준 어림값, 추론 토큰 과금, 출력 한도.
- Google — Understand and count tokens: Gemini 기준 어림값, 이미지·음성·영상의 토큰 계산.
- Anthropic — Context windows: 작업 기억으로서의 컨텍스트 창, 컨텍스트 부패.
- Anthropic — Models overview: 두 지식 기준일의 정의, 등급별 쓰임.
- Anthropic — Reduce hallucinations: 모른다고 허용, 인용 먼저, 근거 없으면 철회, 여러 번 실행해 비교.
- Anthropic — Vision: 이미지 입력의 한계(저화질, 위치 판단, 개수 세기, AI 생성 이미지 판별).
셀프 체크
1-1. 토큰, 컨텍스트 창, 지식 기준일은 각각 '무엇을 재는 말'인지 한 줄씩 구분해 쓰라.
1-2. 어떤 모델의 문서에 신뢰할 수 있는 지식 기준일은 3월, 학습 데이터 기준일은 5월로 적혀 있다. 이 모델에게 4월에 일어난 일을 물었을 때 답을 어떤 태도로 다뤄야 하는지 설명하라.
1-3. 추론 모델이 두 줄짜리 답을 냈는데 사용량 화면에는 긴 보고서를 받았을 때만큼 출력 토큰이 잡혔다. 가능한 이유를 쓰라.
1-4. 다음 네 가지 출력에 가장 알맞은 검증 방법을 하나씩 짝지어라. 출력: (가) 신제품 홍보 문구 (나) 분기별 매출 합계 (다) 경쟁사 출시일 (라) 고객 이탈 원인에 대한 해석. 방법: 원문 대조, 다른 도구로 재계산, 전제와 반례 확인, 목적·독자·제약에 맞는지 보는 평가.
1-5. 손글씨로 작성된 종이 설문지 스무 장을 사진으로 찍어 AI에게 문항별 응답 수를 세게 하려 한다. 생길 수 있는 오류 두 가지와 각각의 대응을 쓰라.
1-6. 같은 질문을 새 대화 다섯 곳에서 했더니 다섯 번 모두 같은 답이 나왔다. 이 결과가 말해 주는 것과 말해 주지 않는 것을 한 문장씩 쓰라.
1-7. 한 팀에 세 가지 업무가 있다. 매일 들어오는 상품명 500건의 영문 표기 통일, 매달 한 번 쓰는 신규 시장 진출 검토 메모, 주 2회 보내는 사내 일정 공지 초안. 업무마다 모델 등급을 고르는 규칙을 두세 줄로 설계하고, 그 규칙이 맞는지 확인할 방법을 함께 쓰라.
실습 과제
실습
근거가 있을 때와 없을 때 비교하기 (40분)
- 답을 직접 확인할 수 있는 질문 두 개를 준비한다. 하나는 잘 바뀌지 않는 사실(예: 공개된 국제 표준의 정식 명칭), 하나는 최근 한 달 안에 바뀐 정보(예: 우리 동네 공공시설의 이번 달 운영 시간)다.
- 검색 기능을 끈 상태에서 각 질문을 새 대화 세 곳에서 따로 묻고 답을 표에 적는다.
- 같은 질문에 "확실하지 않으면 모른다고 답하라"를 덧붙여 다시 묻는다.
- 마지막으로 최신 정보가 담긴 공식 페이지 내용을 붙여 넣고 "붙여 넣은 자료에 있는 내용만으로 답하고 근거 문장을 인용하라"고 묻는다.
- 모든 답을 정답과 비교해 '맞음/틀림/모른다고 답함'으로 표시한다.
완료 기준: 세 조건(근거 없음, 모른다고 허용, 자료 첨부)별 결과가 한 표에 정리되어 있고, 최근 정보 질문에서 결과가 달라진 이유를 지식 기준일과 그라운딩으로 두 문장 이상 설명할 수 있다.
실습
멀티모달 오독 찾기 (40분)
- 숫자가 들어간 공개 자료(예: 공공기관이 발표한 통계표나 그래프) 하나를 고르고, 그 화면을 캡처한 이미지와 원본 수치(표나 CSV)를 함께 준비한다.
- 이미지만 넣고 "이 자료의 주요 숫자 다섯 개와 추세를 정리하라"고 요청한다.
- 원본 수치와 결과를 대조해 틀린 값을 찾고, 각 오류를 '읽기 오류(글자·행열)'와 '해석 오류(축·단위·범례)'로 분류한다.
- 원본 수치를 첨부하고 이미지는 추세 설명에만 쓰도록 요청을 바꿔 다시 실행한다.
완료 기준: 오류 목록이 두 유형으로 분류되어 있고, 요청을 바꾼 뒤 숫자 오류가 줄었는지 전후 비교표로 보여 줄 수 있다.