P6-4.2 attention의 참조 범위¶

Section ID: P6-4.2 Version: v2026.07.24

보조제목: attention은 context window 안에서만 무엇을 다시 볼 수 있는가

P6-4.1에서는 Transformer를 LLM 기준으로 다시 읽으며, 토큰이 임베딩을 거쳐 Transformer 블록을 통과한 뒤 다음 토큰 점수로 이어지는 흐름을 보았습니다. 이 흐름은 강력하지만, 실제 계산은 먼저 입력 범위 제약을 만납니다. attention은 강력한 관련도 계산 구조이지만, 그 계산은 context window 안에 들어온 토큰을 대상으로만 일어납니다.

Transformer가 이전 토큰을 참고할 수 있다면, 실제로는 어디까지 참고할 수 있는가? context window는 모델이 한 번의 계산 안에서 참고할 수 있는 토큰 범위이며, attention은 그 범위 안에서 어떤 토큰이 더 중요한지 계산하는 구조입니다.

attention이 읽을 수 있는 입력 범위¶

입력 범위 제약을 읽을 때는 attention과 context window를 먼저 갈라야 합니다. attention은 입력 안의 토큰들이 서로 얼마나 관련되는지 계산하지만, 그 계산 대상은 context window 안에 들어온 토큰으로 제한됩니다. 따라서 핵심은 attention이 모든 것을 본다가 아니라 입력 범위가 먼저 제한되고 attention은 그 안에서만 작동한다는 점입니다.

이 구분이 잡히면 반복 생성에서 왜 KV cache가 필요해지는지, 긴 문맥에서 왜 sparse attention과 long-context 이야기가 따로 나오는지, RAG가 왜 입력 선택 문제와 연결되는지도 자연스럽게 이어집니다. 문맥을 다 본다는 표현을 너무 크게 해석하면 LLM이 앞선 모든 정보를 언제나 기억하는 것처럼 오해하기 쉽습니다.

context window는 무엇을 뜻하나¶

context window는 모델이 한 번의 입력으로 받을 수 있는 토큰 길이 범위입니다.

예를 들어 어떤 모델이 8k tokens를 지원한다면, 시스템 메시지, 사용자 입력, 대화 기록, 검색 결과, 도구 출력까지 합쳐 그 범위 안에 들어와야 합니다.

다음처럼 이해하면 좋습니다.

문맥을 많이 넣을수록 좋을 것 같지만, 실제로는 토큰 길이 제한 안에서 무엇을 남기고 무엇을 줄일지 결정해야 한다.

이 지점에서 중요한 것은 많이 참고한다와 무한히 참고한다를 구분하는 일입니다. LLM은 입력 안에 들어온 토큰을 넓게 활용할 수 있지만, 그 입력 자체는 항상 한정되어 있습니다.

attention은 범위 안의 관련도를 계산한다¶

이제 attention을 이 제약 위에 올려 보면 관계가 더 분명해집니다. attention은 토큰 간 관련도를 계산하는 구조이지만, 그 계산은 무한한 과거 전체가 아니라 현재 입력에 들어와 있는 토큰 범위 안에서만 이루어집니다.

즉:

• context window는 무엇까지 볼 수 있는가를 제한하고
• attention은 그 안에서 무엇을 더 중요하게 볼 것인가를 계산합니다

이 둘을 섞으면 안 됩니다.

더 안전한 설명은 다음과 같습니다.

context window는 입력 범위 제한에 가깝고, attention은 그 안의 선택 규칙에 가깝다.

왜 이 제약이 바로 서비스 문제로 이어지나¶

context window는 단순 숫자 제한이 아닙니다. 실제로는 입력을 어떻게 구성할지 결정하게 만드는 제약이며, 다음 문제를 만듭니다.

• 긴 문서를 그대로 다 넣지 못할 수 있다
• 오래된 대화 기록을 계속 누적하면 앞부분이 밀릴 수 있다
• 검색 결과를 너무 많이 넣으면 비용이 커지고 핵심이 흐려질 수 있다
• 도구 출력이 길면 정작 중요한 사용자 질문이 뒤로 밀릴 수 있다

즉, context window는 모델 성능뿐 아니라 서비스 설계의 문제이기도 합니다.

긴 문맥이 항상 더 좋은가¶

긴 context window는 분명 유리한 점이 있습니다.

• 더 많은 배경 문서를 넣을 수 있고
• 긴 코드 파일이나 긴 계약서를 한 번에 다루기 쉬워지며
• 대화 맥락을 오래 유지하기 쉬워집니다

하지만 항상 무조건 더 좋은 것은 아닙니다.

• 불필요한 문맥도 함께 늘어날 수 있고
• 관련 없는 정보가 attention을 분산시킬 수 있으며
• 비용과 지연 시간(latency)이 커질 수 있습니다

따라서 실무에서는 단순히 길면 좋다보다 중요한 문맥을 어떻게 잘 고를 것인가가 더 중요해집니다.

입력 범위가 실제 설계를 바꾸는 지점¶

여기까지를 한 줄로 묶으면, 실제 설계 질문은 얼마나 길게 넣을 수 있는가 하나로 끝나지 않습니다.

• 무엇을 먼저 남길 것인가
• 무엇은 그대로 두고 무엇은 요약할 것인가
• 무엇이 현재 질문과 직접 연결되는가

즉, context window 문제는 길이 경쟁이 아니라 입력 선택과 압축의 기준을 세우는 문제이기도 합니다. 이 관점을 잡아야 뒤에서 RAG, 대화 요약, 에이전트 문맥 관리가 왜 모두 비슷한 설계 문제로 묶이는지 자연스럽게 읽을 수 있습니다.

RAG로 이어지는 입력 선택 문제¶

RAG(retrieval-augmented generation)는 이 절에서 자세히 설명할 대상은 아니지만, context window 제약이 어디로 이어지는지 보여 주는 대표 장면입니다. 긴 문서 전체를 넣는 대신 관련 문서 조각을 검색하고 필요한 부분만 잘라 넣는 이유는, 제한된 context window 안에서 근거를 더 효율적으로 쓰기 위해서입니다. 여기서 읽어야 할 핵심은 attention이 강하니 문서를 전부 넣으면 된다가 아니라, 윈도우 안에 남길 근거를 먼저 고르고 그 안에서 attention이 작동한다는 순서입니다.

아주 단순하게 그리면¶

flowchart TD
  A["가능한 모든 이전 정보"]
  B["context window 안에 남은 토큰"]
  C["선택된 토큰 위 attention"]
  D["다음 토큰 예측"]

  A --> B
  B --> C
  C --> D

이 도식의 핵심은 다음입니다.

• 전체 정보가 다 들어오는 것이 아니라
• 먼저 윈도우 안에 들어온 정보가 있고
• attention은 그 안에서 계산된다는 점입니다

사례 및 예시¶

아래 도식은 이 절의 세 사례를 얼마나 많이 넣는가보다 제한된 창 안에 무엇을 우선 남길 것인가라는 공통 질문으로 다시 묶은 것입니다.

flowchart TD
  A["같은 context window 질문"]
  B["긴 보고서<br/>어떤 구간이 살아남아야 하는가?"]
  C["코드 어시스턴트<br/>지금 직접 관련된 파일은 무엇인가?"]
  D["챗봇 메모리<br/>어떤 상태가 계속 보여야 하는가?"]

  A --> B
  A --> C
  A --> D

이 도식에서 확인해야 할 점은 과업이 달라도 핵심 제약이 같다는 것입니다. 모두 전부 넣는가보다 중요한 문맥을 먼저 남기는가가 더 중요하며, attention은 그 뒤에 남은 범위 안에서만 계산됩니다.

사례 1. 긴 문서 요약¶

사용자가 100페이지 보고서를 한 번에 넣고 핵심만 다섯 줄로 정리해 달라고 요청할 수 있습니다. 사람은 처음에 긴 문서를 다 넣으면 더 정확하겠지라고 생각하기 쉽습니다. 하지만 문맥 윈도우가 한정되어 있으면 모델은 문서 전체를 그대로 다 넣어 읽지 못합니다. 앞부분의 배경 설명과 뒤쪽의 결론을 모두 남기고 싶어도, 중간 표와 부록까지 전부 넣으면 정작 최종 권고안이 적힌 마지막 절이 잘려 나갈 수 있습니다.

같은 긴 문서도 입력 선택 방식에 따라 결과가 달라집니다.

이 사례에서 확인할 결과는 많이 넣으면 더 정확한가가 아니라 제한된 범위 안에서 핵심 절이 실제로 보존되는가입니다. context window를 이해할 때는 얼마나 담을 수 있나보다 그 제한 안에서 어떤 절을 먼저 남길 것인가를 더 먼저 봐야 합니다.

사례 2. 코드 도우미¶

큰 코드베이스에서 버그를 고칠 때 사용자는 저장소 전체를 보고 원인을 찾아 달라고 기대할 수 있습니다. 처음에는 전체를 다 보여 주면 더 잘 고칠 것 같다고 느끼기 쉽습니다. 하지만 실제로는 모든 파일을 한 번에 넣기 어렵기 때문에, 현재 파일, 관련 함수, 최근 에러 로그, 실패한 테스트 결과를 우선 선택해야 합니다. 로그인 오류를 고치는데 디자인 자산 파일과 오래된 문서까지 함께 넣는다면, 정작 인증 미들웨어와 세션 설정 파일이 잘리고 핵심 원인 후보를 놓칠 수 있습니다.

같은 버그 수정도 문맥 선택에 따라 남는 단서가 달라집니다.

이 사례에서 확인할 결과는 정보량을 늘리는 것보다 현재 질문과 직접 연결된 파일을 남긴 쪽이 실제 원인 후보를 더 잘 보존하는가입니다. context window는 전부 다 보여 줄 수 없다는 제약일 뿐 아니라, 지금 문제와 직접 연결된 문맥을 선별해야 한다는 설계 기준이기도 합니다.

사례 3. 대화형 챗봇¶

고객 지원 챗봇에서 대화가 길어지면 초반의 주문번호, 정책 설명, 사용자의 추가 질문이 계속 쌓입니다. 사람은 일단 다 남겨 두면 가장 안전하다고 느끼기 쉽지만, 이 기록을 전부 그대로 유지하면 문맥이 금방 길어지고 반대로 너무 많이 지우면 중요한 조건을 잃어버릴 수 있습니다.

초반에 나온 주문번호와 환불 예외 조건은 끝까지 중요하지만, 중간의 반복 인사나 이미 해결된 질문은 그대로 유지할 필요가 적을 수 있습니다. 반대로 주문번호까지 요약 과정에서 빠뜨리면, 뒤 답변이 맞는 정책을 말해도 다른 주문 건을 기준으로 설명하는 오류가 생길 수 있습니다. 이 사례에서 확인할 결과는 반복 인사보다 주문번호와 예외 조건 같은 핵심 상태가 실제로 더 오래 보존되는가입니다.

세 사례를 context window 관리 관점으로 다시 묶으면 다음과 같습니다.

이 표의 목적은 세 장면을 모두 같은 결론으로 밀어 넣는 데 있지 않습니다. 문서 요약, 코드 도우미, 챗봇은 서로 다른 과업이지만, 모두 많이 넣는가보다 제한된 창 안에 핵심 단서가 남는가를 먼저 묻는다는 공통점을 보여 줍니다.

실패 장면에서 다시 보는 기준¶

context window를 적용 장면에서 다시 볼 때 자주 하는 실수는, 긴 문맥이 필요하다는 말을 들으면 곧바로 더 많이 넣는 쪽으로만 생각하는 일입니다. 하지만 실제 서비스 장면에서는 먼저 지금 실패가 윈도우 안에 무엇이 안 남아서 생긴 것인가, 아니면 이미 남아 있는 범위 안에서 무엇이 더 중요했는가를 가르는 편이 안전합니다.

이 표의 목적은 context window와 attention을 다시 정의하는 데 있지 않습니다. 실제 실패 장면을 봤을 때 먼저 윈도우 안에 무엇이 남았는가를 볼지, 남은 범위 안에서 무엇이 더 중요해졌는가를 볼지 분기하게 만드는 데 있습니다.

연습 및 예제¶

이 예제의 목표는 길이 제한이 있을 때 무엇을 우선 남길 것인가를 더 분명하게 보는 것입니다. 단순 개수 제한이 아니라 토큰 예산을 두고, 입력 순서대로 그냥 넣는 방식과 중요도 기준으로 다시 고르는 방식을 비교하겠습니다. 여기에 현재 질문과 얼마나 직접 연결되는가를 흉내 내는 간단한 relevance 점수도 붙여, context window 안에 무엇이 남느냐가 attention이 실제로 볼 수 있는 단서와 어떻게 연결되는지도 함께 보겠습니다.

아래 코드에서 priority, must_keep, query_keywords는 모델이 자동으로 정답을 알아낸 값이 아닙니다. 서비스 설계자가 현재 작업에서 중요하다고 정한 문맥 선택 규칙입니다. 코드는 그 규칙이 토큰 예산 안에서 실제로 어떤 항목을 남기고, 어떤 항목을 밀어내는지 비교합니다. 각 항목의 토큰 길이는 tiktoken의 o200k_base 인코딩으로 직접 계산합니다. 결과에서는 입력 순서대로 넣었을 때 남는 항목, 중요도 기준으로 다시 골랐을 때 남는 항목, 예산 변화에 따라 탈락하는 항목, 핵심 상태 보존 정도, 선택된 항목 안에서 질문과 직접 연결된 단서의 relevance 순위를 함께 봅니다.

확인할 핵심은 context budget이 부족할 때 어떤 정보를 남기고 버리느냐에 따라 최종 답변에 쓸 수 있는 근거가 달라진다는 점입니다. 여기서 실제 tokenizer가 계산하는 값은 각 항목의 tokens이고, budget_options는 독자가 바꿔 볼 수 있는 운영 가정값입니다. budget_options 값을 바꾸면 어떤 항목이 살아남는지 달라지고, attention은 선택 뒤에 남은 항목 안에서만 관련도를 계산할 수 있습니다.

아래 도식은 이 예제가 비교하려는 두 선택 방식을 먼저 압축한 것입니다. 같은 토큰 예산이어도 입력 순서대로 남기는 방식과 우선순위로 다시 고르는 방식은, attention이 실제로 볼 수 있는 단서를 다르게 만듭니다.

flowchart TD
  A["같은 토큰 예산"]
  B["입력 순서대로 선택"]
  C["우선순위 기준 선택"]
  D["오래된 기록이나 반복 인사 보존"]
  E["현재 질문과 오류 로그 보존"]
  F["attention은 윈도우 안에<br/>남은 정보만 사용할 수 있음"]

  A --> B
  A --> C
  B --> D
  C --> E
  D --> F
  E --> F

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103

# context window 토큰 예산 안에서 입력 순서 선택과 중요도 기반 선택이 남기는 단서를 비교하는 예제입니다.
import string

import tiktoken

context_items = [
    {
        "name": "system instruction",
        "priority": 100,
        "content": "Follow policy and explain the cause clearly.",
    },
    {
        "name": "older chat history",
        "priority": 40,
        "content": "Earlier small talk and unrelated setup questions.",
    },
    {
        "name": "repeated greeting",
        "priority": 5,
        "content": "Hello again thank you hello again.",
    },
    {
        "name": "user question",
        "priority": 95,
        "content": "Why did login fail after the deploy?",
    },
    {
        "name": "current error log",
        "priority": 90,
        "content": "Login failed because session token signature mismatch after deploy.",
    },
    {
        "name": "related function code",
        "priority": 88,
        "content": "verify_session_token compares signature and rejects mismatch.",
    },
]

encoding = tiktoken.get_encoding("o200k_base")
for item in context_items:
    # 토큰 예산 판단은 사람이 넣은 추정치가 아니라 실제 tokenizer 관찰값에서 시작한다.
    item["tokens"] = len(encoding.encode(item["content"]))

budget_options = [24, 32, 40]
must_keep = {"system instruction", "user question", "current error log"}
query_keywords = {"login", "fail", "deploy", "token", "signature", "mismatch"}

def select_in_original_order(items, budget):
    selected = []
    used = 0
    for item in items:
        if used + item["tokens"] <= budget:
            selected.append(item)
            used += item["tokens"]
    dropped = [item for item in items if item not in selected]
    return selected, dropped, used

def select_by_priority(items, budget):
    ranked = sorted(items, key=lambda item: item["priority"], reverse=True)
    selected = []
    used = 0
    for item in ranked:
        if used + item["tokens"] <= budget:
            selected.append(item)
            used += item["tokens"]
    dropped = [item for item in ranked if item not in selected]
    return selected, dropped, used

def coverage(selected, must_keep_names):
    selected_names = {item["name"] for item in selected}
    kept = sorted(selected_names & must_keep_names)
    missing = sorted(must_keep_names - selected_names)
    return kept, missing

def relevance_ranking(selected, keywords):
    scored = []
    for item in selected:
        clean_content = item["content"].lower().translate(str.maketrans("", "", string.punctuation))
        words = set(clean_content.split())
        score = len(words & keywords)
        scored.append((score, item["name"]))
    return sorted(scored, reverse=True)

def print_summary(label, selected, dropped, used):
    kept, missing = coverage(selected, must_keep)
    print(f"[{label}]")
    print("used_tokens =", used)
    print("selected =", [item["name"] for item in selected])
    print("dropped =", [item["name"] for item in dropped])
    print("must_keep_missing =", missing)
    print("top_relevance =", relevance_ranking(selected, query_keywords)[:3])

for budget in budget_options:
    print("budget =", budget)
    naive_selected, naive_dropped, naive_used = select_in_original_order(
        context_items, budget
    )
    priority_selected, priority_dropped, priority_used = select_by_priority(
        context_items, budget
    )
    print_summary("original order", naive_selected, naive_dropped, naive_used)
    print_summary("priority based", priority_selected, priority_dropped, priority_used)
    print("---")

아래 출력은 로컬 .venv의 Python 실행으로 본문 코드와 같은 값을 확인했습니다.

실행 결과 예시는 다음처럼 읽을 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

budget = 24
[original order]
used_tokens = 23
selected = ['system instruction', 'older chat history', 'repeated greeting']
dropped = ['user question', 'current error log', 'related function code']
must_keep_missing = ['current error log', 'user question']
top_relevance = [(0, 'system instruction'), (0, 'repeated greeting'), (0, 'older chat history')]
[priority based]
used_tokens = 24
selected = ['system instruction', 'user question', 'older chat history']
dropped = ['current error log', 'related function code', 'repeated greeting']
must_keep_missing = ['current error log']
top_relevance = [(3, 'user question'), (0, 'system instruction'), (0, 'older chat history')]
---
budget = 32
[original order]
used_tokens = 31
selected = ['system instruction', 'older chat history', 'repeated greeting', 'user question']
dropped = ['current error log', 'related function code']
must_keep_missing = ['current error log']
top_relevance = [(3, 'user question'), (0, 'system instruction'), (0, 'repeated greeting')]
[priority based]
used_tokens = 26
selected = ['system instruction', 'user question', 'current error log']
dropped = ['related function code', 'older chat history', 'repeated greeting']
must_keep_missing = []
top_relevance = [(5, 'current error log'), (3, 'user question'), (0, 'system instruction')]
---
budget = 40
[original order]
used_tokens = 40
selected = ['system instruction', 'older chat history', 'repeated greeting', 'user question', 'related function code']
dropped = ['current error log']
must_keep_missing = ['current error log']
top_relevance = [(3, 'user question'), (2, 'related function code'), (0, 'system instruction')]
[priority based]
used_tokens = 35
selected = ['system instruction', 'user question', 'current error log', 'related function code']
dropped = ['older chat history', 'repeated greeting']
must_keep_missing = []
top_relevance = [(5, 'current error log'), (3, 'user question'), (2, 'related function code')]

이 예제에서 읽어야 할 핵심은 다음입니다.

• 같은 토큰 예산이어도 입력 순서대로 그냥 넣으면 older chat history와 repeated greeting이 자리를 차지해, 정작 user question과 current error log가 잘릴 수 있습니다.
• 중요도 기준으로 다시 고르면 현재 질문과 직접 연결된 항목이 먼저 살아남고, 오래된 기록이나 반복 인사는 뒤로 밀립니다.
• 예산이 24에서 32로 늘어날 때 priority 방식은 current error log를 새로 살리지만, original order 방식은 여전히 오래된 대화 기록이 자리를 차지합니다.
• 예산이 40까지 늘어나면 original order 방식도 user question과 related function code는 살리지만, current error log는 여전히 빠집니다. 많이 넣었다고 핵심 단서가 자동으로 보존되는 것은 아닙니다.
• original order 선택에서는 attention이 볼 수 있는 범위 안에 질문·오류 단서 자체가 없을 수 있으므로, relevance 순위를 매겨도 전부 0점에 가깝습니다.
• priority 선택에서는 current error log와 user question이 윈도우 안에 함께 들어와, attention이 실제로 참고할 만한 단서가 남습니다.
• context window 관리에서 중요한 것은 얼마나 많이 넣었는가보다 예산 안에서 핵심 상태를 실제로 살렸는가입니다.
• 우선순위 선택 뒤에 예산이 조금 남으면 낮은 우선순위 항목이 일부 들어올 수 있지만, 그보다 먼저 필수 상태가 전부 살아남았는가를 확인하는 편이 더 중요합니다.
• 그래서 문맥 선택 로직을 볼 때는 총 토큰 수뿐 아니라 주문번호, 현재 질문, 최신 오류 로그 같은 필수 상태가 실제로 남았는지를 함께 점검해야 합니다.

아래 그래프는 예산이 늘어날 때 두 선택 방식의 차이가 어떻게 바뀌는지 요약합니다. 위쪽은 필수 상태 세 가지 중 몇 개가 살아남았는지, 아래쪽은 선택된 항목 안에서 질문 관련 단서가 얼마나 남았는지를 보여 줍니다.

입력 선택에서 갈리는 관련도¶

앞의 예제는 긴 문맥 처리를 구현하는 코드가 아니라, 무엇을 더 넣을 수 있는가보다 무엇을 남기고 무엇을 덜어낼 것인가가 실제 설계 문제라는 점을 가장 짧게 보여 주는 장면입니다. 여기서 읽어야 할 핵심은 context window가 단순 길이 숫자가 아니라, 토큰 예산 안에서 입력 우선순위를 다시 정하게 만드는 제약이라는 점입니다. 그리고 attention은 그 뒤에 남아 있는 항목들 사이에서만 관련도를 계산하므로, 애초에 핵심 단서가 윈도우 밖으로 밀리면 attention이 아무리 좋아도 그 단서를 참고할 수 없습니다. RAG, 대화 요약, 코드 어시스턴트 문맥 선택이 모두 결국 이 문제를 다른 형태로 풀고 있다고 보면 연결이 자연스럽습니다.

왜 문맥 관리가 설계 주제가 되었는가¶

초기 언어 모델에서는 이렇게 긴 문맥 관리 문제가 지금처럼 실무 전면에 드러나지 않았습니다. 하지만 Transformer와 LLM이 긴 입력을 다루는 범용 구조가 되면서, 이제 문맥 길이 관리 자체가 중요한 설계 주제가 되었습니다.

체크리스트¶

• context window를 입력 범위 제한이라는 말로 설명할 수 있어야 합니다.
• attention과 context window의 역할 차이를 다시 구분할 수 있어야 합니다.
• 다음 장들을 얼마나 많이 넣는가보다 무엇을 남길 것인가의 문제로 읽을 준비가 되어 있어야 합니다.

출처와 참고 자료¶

• Ashish Vaswani et al., Attention Is All You Need, NeurIPS 2017, 확인 날짜: 2026-07-19. self-attention이 입력 시퀀스 안의 위치들 사이 관계를 계산한다는 설명의 기본 근거로 사용했다.
• Colin Raffel et al., Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer, JMLR 2020, 확인 날짜: 2026-07-19. Transformer 기반 text-to-text 구조가 요약, 질의응답, 분류 등 여러 텍스트 과업에 재사용된다는 배경 근거로 사용했다.
• OpenAI, Models documentation, 확인 날짜: 2026-07-19. 모델별 context window와 max output tokens가 명시되는 현재 API 문서 구조를 확인해, context window가 실제 입력 범위 제약으로 드러난다는 설명의 운영 근거로 사용했다.