LLM은 정답을 보관해두었다가 꺼내는 시스템이 아닙니다. 앞에 놓인 토큰을 조건으로 다음 토큰의 확률을 계산하고, 하나를 고른 뒤 같은 계산을 반복합니다. 놀라운 점은 이 단순한 학습 목표를 충분히 큰 데이터와 모델에 적용했을 때 요약·번역·코딩 같은 능력이 함께 나타난다는 것이고, 주의할 점은 문맥상 그럴듯함이 사실 여부까지 보장하지는 않는다는 것입니다.
편집자 노트 · B2B 도입 관점 — 검토 자리에서 가장 자주 갈리는 판단이 「데모에서 잘 답한다」와 「업무에 넣어도 된다」입니다. 이 편은 그 둘이 왜 다른 문제인지를 모델의 가장 밑바닥 동작에서 설명합니다. 도입을 검토 중이시라면 과제를 고르는 기준과 검증 예산을 잡는 근거로 읽으실 수 있습니다.
유창한 답을 만드는 과정을 다시 들여다봤습니다
LLM은 문서를 요약하고, 질문에 답하고, 코드를 작성합니다. 서로 다른 과제인데도 사용자는 같은 대화창에 문장을 입력하고 결과를 받습니다. 이 경험이 자연스러울수록 모델 안에서도 사람이 일을 처리하는 것과 비슷한 과정이 일어날 것처럼 느껴집니다.
실제 동작은 조금 다릅니다. 모델은 질문의 의미를 별도의 지식 항목으로 조회하거나, 답을 쓰기 전에 사실 여부를 판정하는 절차를 기본으로 거치지 않습니다. 앞에 놓인 문맥에서 다음에 올 토큰을 계산하는 한 가지 과정을 반복합니다.
저희도 모델 결과를 검토하면서 같은 혼동을 여러 번 봤습니다. 문장이 자연스러우면 내용을 이해했다고 느끼고, 답이 단정적이면 근거도 충분할 것이라 받아들이기 쉽습니다. 반대로 모델이 다음 토큰을 예측한다는 설명만 들으면 고급 자동완성과 무엇이 다른지 의문이 남습니다.
둘 사이의 간격을 이해하려면 할 수 있는 일을 더 나열하기보다 가장 단순한 동작부터 볼 필요가 있었습니다. 첫 편의 질문은 하나입니다. 다음 토큰 예측이라는 단순한 목표가 어떻게 실제 일을 수행하는 능력으로 이어지는가입니다.
다음 토큰 예측은 한 번의 선택이 아니라 반복입니다
토큰은 모델이 텍스트를 처리하는 기본 단위입니다. 한 토큰이 한 단어와 정확히 일치하지는 않습니다. 짧은 단어 하나가 한 토큰일 수도 있고, 긴 단어나 낯선 표현은 여러 토큰으로 나뉠 수 있으며, 공백과 문장부호도 토큰화 방식에 따라 함께 처리됩니다.
사용자가 “회의 내용을 세 줄로 요약해줘”라고 입력하면 모델은 문장 전체를 한 번에 완성하지 않습니다. 입력을 토큰으로 바꾸고, 현재 문맥 다음에 올 수 있는 수많은 후보마다 점수를 계산합니다. 그 점수를 확률 분포로 바꾼 뒤 하나를 선택하고, 선택한 토큰을 문맥 끝에 붙여 다시 계산합니다.
입력 토큰
→ 다음 토큰 후보별 점수
→ 확률 분포
→ 토큰 하나 선택
→ 선택한 토큰을 문맥에 추가
→ 종료 토큰이 나올 때까지 반복
이를 간단히 쓰면 P(다음 토큰 | 지금까지의 토큰)을 반복해서 구하는 과정입니다. 여기서 확률은 세상의 사실일 확률이 아니라, 모델이 학습한 패턴과 현재 문맥 안에서 그 토큰이 이어질 확률입니다.
온도와 샘플링 설정은 이 선택 방식을 바꿉니다. 온도를 낮추면 높은 점수의 후보에 선택이 더 몰리고, 높이면 낮은 점수의 후보도 뽑힐 여지가 커집니다. 설정을 바꾸면 표현의 다양성과 재현성은 달라지지만, 답의 사실 여부를 따로 확인해주지는 않습니다.
다음 단어를 맞히려면 문장보다 많은 것을 배워야 했습니다
“다음 토큰 예측”이라는 말은 휴대전화 자동완성을 떠올리게 합니다. 차이는 예측 목표보다 규모와 조건에 있습니다. LLM은 매우 다양한 자연어와 코드에서 앞 문맥과 다음 토큰의 관계를 반복해서 학습하고, 틀린 정도를 줄이는 방향으로 수많은 파라미터를 조정합니다.
긴 문장에서 다음 토큰을 잘 맞히려면 가까운 단어의 빈도만으로는 부족합니다. 주어와 서술어의 관계, 앞 문단에서 정의한 용어, 질문과 답변의 형식, 코드에서 먼저 선언한 변수, 문서 장르에 따른 전개를 함께 이용해야 합니다. 예측 오차를 계속 줄이는 과정에서 이런 관계를 재사용할 수 있는 내부 표현이 만들어집니다.
이 때문에 학습 때 정답을 따로 붙이지 않은 과제도 프롬프트 안의 지시와 예시만으로 수행하는 행동이 나타납니다. GPT-3 논문은 모델의 가중치를 다시 학습하지 않고도 입력에 몇 개의 예시를 제공해 번역, 질의응답 등 여러 과제를 수행하는 few-shot 방식을 폭넓게 평가했습니다.
그렇다고 모든 능력의 발생 원리를 완전히 설명했다는 뜻은 아닙니다. 어떤 패턴이 어느 규모에서 안정적으로 나타나는지, 모델 내부 표현을 사람의 개념과 어디까지 대응시킬 수 있는지는 여전히 연구 대상입니다. 실무에서는 “이해한다”와 “이해하지 않는다” 중 하나를 먼저 고르기보다, 어떤 조건에서 어떤 행동을 반복해서 보이는지를 측정하는 편이 유용했습니다.
Transformer는 멀리 떨어진 관계를 한 문맥 안에서 다룹니다
오늘날 LLM의 출발점에는 Transformer가 있습니다. 2017년 Transformer 논문이 제안한 self-attention은 각 위치가 같은 문맥의 다른 위치를 얼마나 참고할지 계산하게 했습니다.
예를 들어 긴 문서의 마지막에 있는 대명사가 앞 문단의 어느 대상을 가리키는지 판단하려면 멀리 떨어진 토큰 사이의 관계를 봐야 합니다. 코드에서는 함수 호출이 앞에서 정의된 인자와 맞는지 살펴야 합니다. Attention은 이 관계를 고정된 거리 규칙이 아니라 현재 입력에 따라 다르게 조합합니다.
다만 attention을 검색이나 사실 확인과 같은 것으로 받아들이면 곤란합니다. Attention은 주어진 문맥 안의 정보를 조합하는 계산이지, 문맥 밖의 최신 자료를 자동으로 찾아보는 장치가 아닙니다. 최근 모델은 순수한 Transformer 구조에 다른 계산 방식을 섞기도 하지만, 현재 문맥을 바탕으로 다음 출력을 만든다는 기준은 그대로 남습니다.
사전학습 모델이 바로 친절한 조수는 아니었습니다
사전학습이 만든 기본 모델은 텍스트를 이어 쓰는 능력은 갖지만, 사용자의 요청을 안전하고 유용하게 따르는 조수와는 거리가 있습니다. 질문을 받았을 때 답하기보다 비슷한 질문을 하나 더 이어 쓰거나, 요청한 형식을 무시할 수도 있습니다.
그래서 사전학습 뒤에는 보통 지시 예시로 답변 방식을 익히는 지도 미세조정과, 사람이 선호하는 응답 쪽으로 행동을 다듬는 후속학습이 이어집니다. InstructGPT 논문에서는 연구에 사용한 프롬프트 분포의 사람 평가에서 13억 파라미터 InstructGPT 출력이 1,750억 파라미터 GPT-3 출력보다 선호됐습니다. 모델 크기만큼이나 어떤 행동을 좋은 답으로 학습시켰는가가 중요하다는 초기의 구체적인 사례입니다.
이 구분을 알고 나면 모델 비교표도 다르게 읽힙니다. 사전학습은 언어와 코드의 넓은 패턴을 익히는 단계이고, 후속학습은 그 능력을 어떤 지시와 안전 기준에 맞춰 꺼낼지 정하는 단계입니다. 같은 기반 모델이라도 base 모델과 instruct 모델의 대화 경험이 크게 다른 이유입니다.
유창한 오답은 별도의 결함이 아니라 같은 메커니즘에서 나옵니다
LLM이 좋은 초안을 만드는 이유와 존재하지 않는 출처를 자연스럽게 적는 이유는 멀리 떨어져 있지 않습니다. 둘 다 현재 문맥에서 이어질 법한 토큰을 잘 고르는 능력에서 나옵니다. 학습 데이터에서 자주 본 보고서 형식을 재구성하는 데도, 불완전한 정보를 그럴듯한 세부사항으로 메우는 데도 같은 생성 능력이 쓰입니다.
이 현상을 단순히 “모델이 거짓말한다”고 부르면 대응 방법을 놓치기 쉽습니다. 모델은 먼저 문장의 자연스러움을 최적화하도록 학습됐고, 현재 답이 최신 사실인지 판정하는 별도의 데이터베이스를 기본으로 갖고 있지 않습니다. 사실성이 중요한 과제라면 최신 자료를 문맥에 넣고, 출처를 요구하고, 계산과 실행 결과를 외부 도구로 확인해야 합니다.
저희가 현장에서 구분해 사용하는 기준은 다음과 같습니다.
| 과제 | LLM이 잘하는 부분 | 함께 확인할 것 |
|---|---|---|
| 주어진 문서 요약·재작성 | 문맥의 구조를 읽고 원하는 형식으로 변환 | 원문 누락, 숫자 보존, 출력 형식 |
| 최신 사실 조사 | 질문 정리, 검색어 확장, 자료 간 연결 | 출처, 게시일, 원문과의 일치 |
| 계산·데이터 분석 | 식과 분석 절차 제안, 결과 설명 | 계산기·코드 실행 결과, 입력 데이터 범위 |
| 코드 작성 | 익숙한 패턴 조합, 수정안 제시 | 컴파일, 테스트, 실제 API와 버전 |
| 도구를 쓰는 업무 실행 | 다음 행동 제안, 관측 결과 해석 | 권한, 도구 반환값, 종료 조건, 실행 기록 |
요약처럼 답의 근거가 입력 안에 있는 과제와, 최신 사실처럼 근거가 입력 밖에 있는 과제를 같은 방식으로 평가하지 않는 것이 출발점입니다. 생성 능력은 같아도 실패를 발견하는 방법은 달라야 합니다.
프롬프트는 모델을 다시 학습시키지 않고 조건을 바꿉니다
프롬프트가 중요한 이유도 다음 토큰의 조건을 바꾸기 때문입니다. 역할, 과제, 예시, 참고 자료, 출력 형식을 앞 문맥에 놓으면 모델이 어떤 패턴을 이어갈지 좁힐 수 있습니다. 좋은 예시 하나가 긴 지시보다 잘 작동하는 경우가 있는 것도, 원하는 출력 패턴을 직접 문맥에 보여주기 때문입니다.
하지만 프롬프트만으로 모델의 파라미터가 바뀌지는 않습니다. 새 정보를 검색해 넣는 RAG, 정확한 산술을 맡는 계산기, 실제 파일을 다루는 도구가 필요한 이유입니다. 프롬프트는 모델의 행동 방향을 정하고, 외부 시스템은 모델 안에 없거나 보장할 수 없는 사실과 실행을 담당합니다.
이 경계를 나누면 프롬프트를 계속 길게 고치는 일도 줄어듭니다. 모델에게 부탁할 조건과 코드로 보장할 조건을 구분할 수 있기 때문입니다. “세 문장으로 써줘”는 지시로 충분할 수 있지만, “금액 합계가 원장과 정확히 같아야 한다”는 검증 코드가 맡는 편이 안전합니다.
기능 이름보다 동작 조건을 먼저 봅니다
같은 LLM이라도 어떤 문맥을 제공했는지, 어떤 샘플링 설정을 썼는지, 어떤 후속학습을 거쳤는지에 따라 결과가 달라집니다. 검색과 계산기, 코드 실행 도구를 연결했는지에 따라서도 할 수 있는 일의 범위가 바뀝니다. 그러므로 화면에 보이는 답은 모델 하나의 능력이라기보다 모델과 입력, 외부 도구, 검증 절차가 함께 만든 결과에 가깝습니다.
추론 과정을 길게 쓰게 하면 복잡한 문제를 풀 여지가 커지지만 토큰과 시간이 더 필요합니다. 검색을 연결하면 최신 자료를 받을 수 있지만 어떤 출처를 골랐는지 확인해야 하고, 도구를 연결하면 실제 행동을 할 수 있지만 권한과 실패 처리, 종료 조건이 필요합니다. 한 가지 능력을 더할 때마다 확인해야 할 조건도 하나씩 생깁니다.
이 구조를 기준으로 보면 하나의 출력이 만들어지는 책임도 나눌 수 있습니다. 모델이 제안과 변환을 맡고, 자료가 근거를 제공하고, 도구가 실행하며, 검증 절차가 결과를 확인합니다. 역할을 나눠두면 오류가 생겼을 때 모델, 입력 자료, 도구 반환값, 검증 규칙 중 어디를 다시 봐야 하는지도 분명해집니다.
첫 편에서 남길 판단 기준은 세 가지입니다.
- LLM의 확률은 사실의 확률이 아니라 문맥상 다음 토큰의 확률입니다.
- 사전학습이 넓은 생성 능력을 만들고, 후속학습이 그 능력을 지시에 맞게 꺼내도록 다듬습니다.
- 사실·계산·실행을 보장하려면 출처, 도구, 검증 절차가 모델 바깥에 있어야 합니다.
다음 편에서는 모델 이름에서 가장 먼저 마주치는 숫자를 다룹니다. 파라미터는 학습 과정에서 무엇을 담게 되는지, 그 수가 많아지면 어떤 능력과 비용이 함께 달라지는지, 모델 크기만으로 답변 품질을 판단하기 어려운 이유를 살펴보겠습니다.
도입을 검토한다면
이 편의 내용을 도입 판단으로 옮기면 세 가지가 남습니다.
첫째, 과제를 근거의 위치로 나눠서 시작합니다. 회의록 요약이나 문서 재작성처럼 답의 근거가 입력 안에 있는 일은 비교적 빨리 성과가 납니다. 최신 사실 조회나 금액 계산처럼 근거가 입력 밖에 있는 일은 같은 모델이라도 출처·도구·검증을 함께 붙여야 합니다. 두 종류를 같은 PoC에 섞으면 성공도 실패도 원인을 읽기 어렵습니다.
둘째, 검증 비용을 처음부터 예산에 넣습니다. 모델 사용료만 계산하면 실제 운영 비용을 과소평가하게 됩니다. 출처 확인, 계산 결과 대조, 테스트, 실행 기록 보관은 선택이 아니라 사실성이 필요한 과제의 필수 구성입니다.
셋째, 평가 문장을 바꿉니다. 「답이 그럴듯한가」 대신 「이 답의 근거를 어디서 확인할 수 있는가」를 물으면, 도입 회의에서 오가는 대화의 질이 달라집니다.
다음 편 → 파라미터가 많으면 무엇이 달라질까 (2편)