AI

프롬프트가 GPT의 답변이 되기까지

수수다 2026. 9. 2. 19:33

ChatGPT에 질문을 입력하면 잠시 후 자연스러운 문장으로 답변이 돌아온다. 겉으로 보면 GPT가 질문을 읽고 머릿속에서 답을 완성한 뒤 전달하는 것처럼 보인다. 하지만 생성형 언어 모델의 실제 동작은 이와 다르다.

GPT 계열의 생성형 언어 모델은 입력을 토큰으로 변환하고, 앞에 놓인 토큰을 바탕으로 다음에 올 토큰의 확률을 계산한다. 선택한 토큰을 입력 뒤에 붙인 다음 같은 과정을 반복하면서 답변을 만든다.

이 글의 범위

이 글은 공개된 Transformer 및 GPT 논문을 바탕으로 GPT 계열 생성형 언어 모델의 일반적인 추론 과정을 설명한다. 공개된 초기 GPT는 Decoder-only Transformer를 사용했지만, GPT-5.6을 포함한 현재 상용 모델의 정확한 레이어 구성, 파라미터 수, 위치 정보 처리 방식 등은 공개되지 않았으므로 동일한 세부 구조라고 단정하지 않는다. 또한 ChatGPT라는 서비스와 그 안에서 사용되는 GPT 모델을 구분해서 설명한다.

또한 이 글은 텍스트 입력과 텍스트 출력을 기준으로 설명한다. 이미지·음성 등의 멀티모달 입력은 모델에 맞는 별도의 표현 변환 과정을 거칠 수 있으며, 그 세부 방식은 모델마다 다를 수 있다.

GPT-4 Technical Report는 2023년 자료이므로 최신 모델의 구조 명세가 아니다. 그러나 Transformer 기반 처리와 다음 토큰 예측이라는 공개된 기본 원리를 이해하는 자료로는 여전히 가치가 있다. GPT-5.6 공식 자료는 추론, 도구 사용, 평가와 안전성 등을 설명하지만 정확한 내부 아키텍처 전체를 공개하지 않는다.

목차

  1. 전체 흐름
  2. 프롬프트와 컨텍스트 구성
  3. 토큰화
  4. 임베딩과 위치 정보
  5. Transformer Decoder의 문맥 처리
  6. 다음 토큰의 확률 계산
  7. Decoding: 다음 토큰 선택
  8. 토큰 생성 반복과 종료
  9. 텍스트 변환과 응답 반환
  10. GPT 모델과 애플리케이션의 경계
  11. Context Window와 정보 활용의 한계
  12. 이 과정에서 할루시네이션이 발생하는 이유
  13. 정리

1. 전체 흐름

사용자가 입력한 문장이 답변으로 돌아오기까지의 과정을 크게 나누면 다음과 같다.

여기서 중요한 점은 ChatGPT 애플리케이션이 하는 일과 GPT 모델이 하는 일이 다르다는 것이다. 대화 기록을 보관하고 입력을 구성하며 응답을 화면에 표시하는 것은 애플리케이션의 역할이다. GPT 모델의 핵심 역할은 주어진 컨텍스트를 바탕으로 다음 출력 토큰을 생성하는 것이다.

2. 프롬프트와 컨텍스트 구성

사용자가 입력한 질문만 모델에 전달된다고 생각하기 쉽지만, 대화형 AI에서 모델의 실제 입력은 더 넓다.

모델에 전달되는 입력의 예

개발자 또는 시스템 지침
+ 이전 대화 기록
+ 사용자의 현재 질문
+ 필요한 경우 예시·문서·도구 설명
= 모델이 처리할 전체 컨텍스트

프롬프트(prompt)는 모델로부터 원하는 결과를 얻기 위해 제공하는 지시와 입력을 뜻한다. 컨텍스트(context)는 모델이 현재 응답을 생성할 때 참고할 수 있도록 함께 전달된 정보 전체에 가깝다.

OpenAI API에서는 지시와 입력에 서로 다른 역할과 우선순위를 부여할 수 있다. 예를 들어 개발자가 제공한 지침은 애플리케이션의 규칙과 동작 방식을 정의하고, 사용자 메시지는 그 규칙이 적용될 실제 입력을 제공한다. 다만 이러한 역할이 모델에 전달되는 정확한 직렬화 형식과 현재 ChatGPT 내부에서 컨텍스트를 조립하는 세부 방식은 모델과 서비스에 따라 달라질 수 있다.

사용자가 입력한 한 문장만이 프롬프트의 전부라고 보기보다, 모델에 전달되는 지침과 대화 기록을 포함한 전체 입력을 함께 살펴봐야 한다.

3. 토큰화

컴퓨터는 입력 문장을 사람처럼 단어와 의미로 바로 이해하지 않는다. 먼저 텍스트를 모델이 처리할 수 있는 작은 단위인 토큰(token)으로 나눈다. 이 과정을 토큰화(tokenization)라고 한다.

입력: 오늘 날씨가 좋다

개념적인 예:
[오늘] [ 날씨] [가] [ 좋] [다]

위 예시는 이해를 위한 단순화다. 실제 분할 결과는 사용하는 tokenizer와 모델에 따라 달라진다. 하나의 토큰이 한 단어일 수도 있고, 단어의 일부·문장부호·공백의 조합일 수도 있다. 같은 문장도 언어와 모델에 따라 필요한 토큰 수가 달라질 수 있다.

토큰 수는 다음 항목에 직접적인 영향을 준다.

  • 모델이 한 번에 처리할 수 있는 입력 길이
  • 생성할 수 있는 출력 길이
  • API 사용 비용
  • 처리 시간과 메모리 사용량

OpenAI 역시 일반 텍스트의 토큰 수와 실제 API 요청의 전체 입력 토큰 수가 항상 같지는 않다고 설명한다. 메시지 구조, 도구 정의, 스키마, 이미지와 파일 등도 전체 입력량에 영향을 줄 수 있기 때문이다.

4. 임베딩과 위치 정보

토큰은 모델이 계산에 사용할 수 있도록 숫자로 된 벡터로 변환된다. 이 벡터 표현을 토큰 임베딩(token embedding)이라고 한다.

토큰
→ 토큰 ID
→ 고차원 벡터
→ Transformer가 계산할 수 있는 입력 표현

같은 토큰이라도 문장 안에서 놓인 순서에 따라 의미가 달라질 수 있으므로 위치 정보도 필요하다.

개가 사람을 물었다
사람이 개를 물었다

두 문장은 비슷한 토큰을 포함하지만 순서 때문에 뜻이 완전히 다르다. Transformer는 순환 구조를 사용하지 않으므로 토큰의 위치를 표현하는 장치가 필요하다. 최초 Transformer 논문은 사인·코사인 기반의 Positional Encoding을 제시했다. 다만 현재 상용 GPT가 정확히 어떤 위치 정보 처리 방식을 사용하는지는 공개된 범위 밖일 수 있으므로, 특정 방식을 현재 GPT의 구현이라고 단정해서는 안 된다.

5. Transformer Decoder의 문맥 처리

공개된 초기 GPT는 여러 층의 Transformer Decoder를 쌓은 Decoder-only 구조를 사용했다. Decoder 블록에서는 Self-Attention, Feed-Forward Network, Residual Connection, Normalization 등의 연산을 거쳐 각 토큰의 문맥 표현을 갱신한다.

Transformer 블록에 포함된 주요 연산을 간단히 정리하면 다음과 같다.

  • Feed-Forward Network: 각 토큰의 표현을 신경망을 통해 한 번 더 변환한다.
  • Residual Connection: 블록에 들어온 기존 입력을 연산 결과에 더해 정보가 깊은 레이어까지 전달되도록 돕는다.
  • Normalization: 중간 표현의 값 분포를 조정해 계산과 학습이 안정적으로 이루어지도록 돕는다.

연산의 정확한 순서와 Normalization이 적용되는 위치는 모델 구조에 따라 달라질 수 있다.

5.1 Self-Attention

Self-Attention은 입력에 포함된 토큰들이 서로 어떤 관계를 가지는지 계산하는 구조다.

철수는 사과를 먹었다. 그는 배가 고팠다.
                       └─ '그'가 누구를 가리키는지 주변 토큰과의 관계를 계산

각 토큰 표현으로부터 Query, Key, Value를 만들고, Query와 Key의 관계를 이용해 어떤 Value를 얼마나 참고할지 계산한다.

Query: 현재 토큰이 찾으려는 정보
Key: 각 토큰이 가진 정보의 표지
Value: 실제로 가져올 정보

이 설명은 이해를 위한 비유다. 실제로는 학습된 행렬 연산을 통해 관계 점수와 새로운 토큰 표현을 계산한다.

5.2 Causal Masking

GPT와 같은 자기회귀 생성 모델은 다음 토큰을 예측할 때 아직 생성되지 않은 미래 토큰을 볼 수 없어야 한다. 이를 위해 뒤쪽 위치를 참고하지 못하도록 가리는 Causal Mask를 사용한다.

입력: 나는 오늘 학교에

'나는'  → '나는'까지 참고
'오늘'  → '나는 오늘'까지 참고
'학교에' → '나는 오늘 학교에'까지 참고
다음 토큰 → 지금까지 주어진 모든 이전 토큰을 참고

5.3 Multi-Head Attention

Multi-Head Attention은 하나의 Attention만 사용하는 대신 여러 Attention Head를 병렬로 사용한다. 하나의 Head도 토큰 사이의 여러 관계를 계산할 수 있지만, 각 Head는 서로 다른 학습된 가중치를 사용하므로 동일한 입력에서도 서로 다른 관계가 상대적으로 강조될 수 있다.

예를 들어 “나는 차를 마신다”라는 문장에서 어떤 Head는 ‘차를’과 ‘마신다’ 사이의 의미 관계를 강하게 반영할 수 있다. 다른 Head에서는 ‘나는’과 ‘마신다’ 사이의 문법적 관계나 토큰의 위치 관계가 상대적으로 강하게 반영될 수 있다. 여러 Head의 결과는 다시 하나로 결합되어 다음 연산으로 전달된다. 이를 통해 모델은 같은 문장에 포함된 의미, 문법, 위치 등의 다양한 관계를 더 풍부하게 표현할 수 있다.

다만 “한 Head는 문법만 보고 다른 Head는 의미만 본다”처럼 각 Head의 역할이 사람에게 명확하게 하나씩 대응되거나 고정되어 있다고 단정해서는 안 된다. 각 Head가 어떤 관계를 강조할지는 학습 과정에서 형성되며, 하나의 Head가 여러 관계를 함께 반영할 수도 있다.

6. 다음 토큰의 확률 계산

여러 Decoder 블록을 통과한 결과를 이용해 모델은 어휘 집합에 포함된 각 토큰의 점수를 계산한다. 이 점수를 Logit이라고 하며, Softmax 등을 통해 다음 토큰에 대한 확률 분포로 변환할 수 있다.

입력: 대한민국의 수도는

다음 토큰의 개념적인 확률 분포
' 서울'    0.91
' 부산'    0.03
' 대한민국' 0.02
' 도시'    0.01
기타        0.03

위 숫자는 설명을 위해 만든 예시다. GPT가 데이터베이스에서 정답 문장을 그대로 조회한 결과가 아니다. 모델은 학습을 통해 형성된 파라미터와 현재 컨텍스트를 바탕으로 다음에 올 가능성이 높은 토큰의 분포를 계산한다.

7. Decoding: 다음 토큰 선택

확률 분포가 만들어지면 실제로 출력할 다음 토큰을 선택해야 한다. 이 선택 과정을 Decoding이라고 한다.

방식 또는 설정 의미
Greedy Decoding 매 단계에서 확률이 가장 높은 토큰을 선택한다.
Sampling 확률 분포를 바탕으로 토큰을 확률적으로 선택한다.
Temperature 토큰을 선택하기 전에 Logit을 조절해 확률 분포를 더 날카롭거나 평평하게 만든다.
Top-p 누적 확률이 일정 범위에 들어오는 후보 안에서 선택한다.

일반적으로 선택 범위를 좁히면 일관된 결과가 나오기 쉽고, 선택 범위를 넓히면 표현의 다양성이 커질 수 있다. 그러나 특정 설정이 사실 정확성을 보장하지는 않는다. 또한 실제 API에서 지원하는 제어 항목은 모델에 따라 다를 수 있다.

8. 토큰 생성 반복과 종료

다음 토큰 하나를 선택했다고 답변이 완성되는 것은 아니다. 선택한 토큰을 기존 컨텍스트 뒤에 추가하고 다시 다음 토큰의 확률을 계산한다.

대한민국의 수도는
→ ' 서울'

대한민국의 수도는 서울
→ '입니다'

대한민국의 수도는 서울입니다
→ '.'

대한민국의 수도는 서울입니다.
→ 종료

이처럼 이전 토큰을 바탕으로 다음 토큰을 순차적으로 생성하는 방식을 Autoregressive Generation이라고 한다. 개념적으로는 컨텍스트가 토큰 하나씩 길어진다. 실제 서빙 시스템에서는 이전 계산 결과를 재사용하는 캐시 등의 최적화를 적용할 수 있지만, 세부 구현은 모델과 제공 환경에 따라 달라진다.

8.1 Prefill과 Decode

실제 추론 과정은 개념적으로 Prefill과 Decode 단계로 나눠볼 수 있다.

  • Prefill: 입력 프롬프트를 처리하고 이후 계산에 재사용할 KV(Key-Value) Cache를 구성하는 단계
  • Decode: KV Cache를 읽고 확장하면서 출력 토큰을 순차적으로 생성하는 단계

입력 프롬프트의 여러 위치는 Causal Mask를 적용한 상태에서 병렬로 계산할 수 있지만, 출력 토큰은 앞에서 생성한 토큰에 의존하므로 기본적으로 순차적으로 생성된다. 따라서 입력 처리와 출력 생성이 모두 같은 방식으로 한 토큰씩 진행되는 것은 아니다.

현재 추론 모델의 Reasoning Token

현재의 추론 모델은 사용자에게 보이는 최종 답변 토큰 외에 내부적으로 Reasoning Token을 생성할 수 있다. 이 토큰의 원문은 일반적으로 사용자에게 공개되지 않지만, Context Window와 출력 토큰 사용량 및 API 비용에는 영향을 줄 수 있다. 따라서 최신 추론 모델에서는 화면에 표시되는 답변 토큰만 생성되는 것은 아니다.

생성은 다음과 같은 조건에서 종료될 수 있다.

  • 모델이 종료를 나타내는 토큰을 생성한 경우
  • 설정된 최대 출력 토큰 수에 도달한 경우
  • 지정된 Stop Sequence가 생성된 경우
  • 애플리케이션이나 서비스의 정책에 의해 중단된 경우

9. 텍스트 변환과 응답 반환

생성된 토큰 ID는 tokenizer를 통해 사람이 읽을 수 있는 텍스트로 변환된다. 애플리케이션은 완성된 결과를 한 번에 받을 수도 있고, 생성되는 일부 결과를 순차적으로 받을 수도 있다.

Streaming을 사용하면 전체 답변이 완성될 때까지 기다리지 않고 생성되는 내용을 조금씩 화면에 표시할 수 있다.

모델: '대한'
화면: 대한

모델: '민국의'
화면: 대한민국의

모델: ' 수도는'
화면: 대한민국의 수도는

...

Streaming은 사용자에게 첫 결과를 더 빨리 보여줄 수 있지만, 전체 토큰 생성 연산 자체를 없애는 것은 아니다. 생성형 모델은 출력 토큰을 순차적으로 생성하기 때문에 답변이 길수록 전체 응답 시간도 대체로 길어진다.

10. GPT 모델과 애플리케이션의 경계

GPT의 생성 과정과 ChatGPT 서비스의 전체 동작을 동일하게 생각하면 개념이 뒤섞이기 쉽다.

구분 주요 역할
애플리케이션 사용자 입력 수신, 지침과 대화 기록 구성, 모델 호출, 대화 상태 저장, 출력 표시
GPT 모델 전달받은 컨텍스트를 처리하고 다음 출력 토큰을 생성
외부 도구 검색, DB 조회, 파일 처리, API 호출 등 실제 외부 작업 수행

예를 들어 Tool Calling에서 GPT 모델은 일반적으로 실행할 도구와 인자를 나타내는 출력을 생성한다. 그 출력을 해석해 실제 함수를 실행하고 결과를 다시 모델에 전달하는 것은 애플리케이션 영역의 역할이다. 이 구분은 이후 RAG, AI Agent, MCP를 이해하는 기준이 된다.

11. Context Window와 정보 활용의 한계

Context Window는 모델이 한 요청에서 처리할 수 있는 컨텍스트의 범위다. 모델과 API에 따라 계산 방식에는 차이가 있지만, 일반적으로 입력 토큰과 생성할 출력 토큰은 모두 제한된 처리 범위를 고려해야 한다.

Context Window가 크다고 해서 그 안의 모든 정보를 같은 정확도로 활용한다는 뜻은 아니다. 긴 컨텍스트에서 관련 정보의 위치를 바꿔가며 평가한 연구에서는 중요한 정보가 중간에 있을 때 활용 성능이 낮아지는 Lost in the Middle 현상이 관찰됐다.

정보가 컨텍스트에서 실제로 삭제된다는 뜻이 아니다. 입력에는 포함되어 있지만, 모델이 답변을 만들 때 해당 정보를 정확하게 회수하고 활용하는 성능이 낮아질 수 있다는 의미다.

따라서 대화 기록과 문서를 무조건 많이 넣는 것이 항상 좋은 전략은 아니다. 관련 정보를 선별하고, 오래된 내용을 요약하며, 중요한 지침과 상태를 구조화하는 Context Engineering이 필요하다.

12. 이 과정에서 할루시네이션이 발생하는 이유

GPT는 기본적으로 현재 문맥에서 이어질 가능성이 높은 토큰을 생성한다. 이 목표는 사실을 데이터베이스에서 조회해 참과 거짓을 판정하는 작업과 다르다.

언어적으로 자연스러운 다음 토큰
≠
외부 세계에서 검증된 사실

학습 데이터에 정보가 부족하거나, 질문이 모호하거나, 컨텍스트에 잘못된 정보가 들어 있더라도 모델은 문장 생성을 계속할 수 있다. 그 결과 자연스럽지만 사실과 다른 답변이 만들어질 수 있다.

따라서 실제 서비스에서는 모델의 답변을 그대로 신뢰하기보다 다음과 같은 장치가 필요하다.

  • 외부 문서를 검색해 근거를 제공하는 RAG
  • JSON Schema 등을 이용한 출력 형식 검증
  • 중요한 사실과 계산 결과의 별도 검증
  • 실패 조건, 재시도, 타임아웃 처리
  • 평가 데이터셋과 실행 로그를 이용한 품질 측정

각 장치의 역할은 서로 다르다. RAG와 별도 검증은 사실 오류를 줄이기 위한 장치다. JSON Schema는 출력 형식의 일관성을 높이지만 내용의 사실 여부까지 보장하지는 않는다. 재시도와 타임아웃은 주로 서비스의 운영 안정성을 위한 장치이며, 평가 데이터셋과 실행 로그는 모델의 품질을 측정하고 개선하는 데 사용된다.

13. 정리

1. 애플리케이션이 지침·대화 기록·사용자 입력으로 컨텍스트를 구성한다.
2. 입력 텍스트를 토큰으로 나눈다.
3. 토큰을 벡터로 바꾸고 위치 정보를 반영한다.
4. Transformer Decoder가 이전 토큰들의 관계를 계산한다.
5. 어휘 집합의 각 토큰에 대해 다음 토큰 점수를 계산한다.
6. Decoding 전략에 따라 다음 토큰을 선택한다.
7. 선택한 토큰을 컨텍스트 뒤에 추가한다.
8. 종료 조건을 만날 때까지 같은 과정을 반복한다.
9. 생성된 토큰을 텍스트로 변환해 애플리케이션에 반환한다.

GPT는 답변 전체를 한 번에 작성하는 시스템이 아니다. 이전까지의 컨텍스트를 바탕으로 다음 토큰을 선택하는 과정을 반복해 답변을 완성한다.

이 기본 흐름을 이해하면 이후 기술을 어디에 추가해야 하는지도 선명해진다.

이 기술들은 일반적으로 GPT 내부의 다음 토큰 생성 원리를 바꾸기보다, GPT 주변의 애플리케이션 구조를 확장한다. 따라서 LLM의 기본 플로우는 RAG와 AI Agent를 학습하기 위한 출발점이 된다.

참고 자료

저작자표시 비영리 변경금지 (새창열림)