1 도입
1M~2M 토큰의 컨텍스트 윈도우를 가진 모델이 등장하면서, “RAG 없이 데이터를 통째로 넣으면 된다”는 주장이 힘을 얻고 있다. 이 주장은 특히 문서 분석, 코드 분석 같은 대규모 텍스트 처리 시나리오에서 매력적으로 들린다.
그러나 컨텍스트 윈도우의 크기와 그 안에서의 추론 품질은 별개의 문제다. 이 글에서는 LC 모델의 대표적 주장 6가지를 비판적으로 분석하고, 각 주장이 어디까지 유효한지 경계를 명확히 한다.
2 주장 1: “NIAH 테스트에서 99%+ recall이므로 신뢰할 수 있다”
2.1 주장의 내용
Needle-in-a-Haystack(NIAH) 테스트에서 100만 토큰 내 특정 정보를 99.7% 이상의 정확도로 찾아낸다. 따라서 LC 모델은 대규모 데이터에서 정보를 놓치지 않는다.
2.2 비판
NIAH는 “숨겨진 문장 찾기” 테스트다. 이것은 검색(retrieval) 능력을 측정하는 것이지 추론(reasoning) 능력을 측정하는 것이 아니다.
| 능력 | NIAH가 측정하는가 | 실무에서 필요한가 |
|---|---|---|
| 특정 문장 위치 파악 | O | 부분적 |
| 다단계 인과추론 | X | 핵심 |
| 분산된 정보 간 논리적 연결 | X | 핵심 |
| 모순 탐지 | X | 자주 필요 |
200K 줄 코드에서 “3번째 메서드의 설정 변경이 145번째 메서드의 출력에 미치는 영향”을 분석하는 것은 단순 검색이 아니라 다단계 인과추론이다. “찾는 능력”과 “추론하는 능력”을 등치시키는 것은 범주 오류(category error)다.
다음은 NIAH 스타일 단순 검색과 다단계 추론을 동일 LC 모델에 요청했을 때의 차이를 보여주는 예시다:
from openai import OpenAI
client = OpenAI()
# 대규모 코드 텍스트를 컨텍스트로 준비 (예시: 파일 병합)
with open("merged_codebase.txt", "r") as f:
codebase = f.read() # ~200K lines, ~800K tokens
# --- Task 1: NIAH 스타일 단순 검색 (LC가 잘하는 영역) ---
response_search = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "아래 코드에서 질문에 답하라."},
{"role": "user", "content": f"{codebase}\n\n질문: 'validate_token' 함수가 정의된 파일명과 라인 번호는?"}
]
)
# → 높은 정확도로 위치를 찾아냄 (NIAH에 해당)
# --- Task 2: 다단계 인과추론 (LC가 약한 영역) ---
response_reasoning = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "아래 코드에서 질문에 답하라."},
{"role": "user", "content": f"{codebase}\n\n질문: config.py의 MAX_RETRY 값을 3에서 10으로 바꾸면 "
"payment_processor.py의 process_payment() 출력이 어떻게 바뀌는가? "
"중간 경로를 모두 추적하라."}
]
)
# → 중간 경로 일부를 누락하거나, 존재하지 않는 경로를 날조할 수 있음
# → 특히 경로가 5 hop 이상이면 정확도가 급격히 하락Task 1은 NIAH와 구조적으로 동일하다 — 텍스트 안에서 특정 문자열을 찾는 작업이다. Task 2는 변수 전파 경로를 다단계로 추적해야 하며, 이것은 NIAH가 측정하지 않는 능력이다.
2.3 유효한 범위
NIAH 결과가 의미 있는 경우: 특정 사실의 존재 여부 확인, 키워드 기반 검색, 단일 정보 회수. 이런 작업에서는 LC 모델의 recall이 실제로 우수하다.
3 주장 2: “Raw Code를 그대로 로드하므로 정보 손실이 제로다”
3.1 주장의 내용
RAG는 청킹·임베딩·검색 과정에서 정보가 손실되지만, LC 모델은 원본 텍스트를 그대로 수용하므로 손실이 없다.
3.2 비판
텍스트 수준의 손실이 0이라는 것은 맞다. 그러나 이 주장은 구조적 메타데이터의 가치를 무시한다.
AST 파싱 → 온톨로지 매핑은 텍스트에서 정보를 빼는 과정이 아니라 정보를 부가하는 과정이다:
Raw Code (200K lines)
↓ AST 파싱
구문 구조 (함수, 클래스, 호출관계, 타입) ← 암시적 → 명시적
↓ 온톨로지 매핑
도메인 개념 (비즈니스 규칙, 데이터 흐름) ← 코드에 없는 상위 의미 부가
↓ Graph 구축
관계 네트워크 (호출 그래프, 상속 트리) ← 탐색 가능한 구조화된 지식Keet(2020)은 온톨로지를 “데이터에 대한 데이터”가 아니라 “데이터의 의미를 명시적으로 표현하는 구조”로 정의한다. 데이터베이스 스키마에서 의미가 암시적(개발자의 머릿속)인 것과 달리, 온톨로지에서 의미는 명시적(기계 해석 가능)이다 (Keet, 2020, Ch.1).
| 차원 | Raw Code Loading | 온톨로지 + Raw Code |
|---|---|---|
| 텍스트 정보 | 보존 | 보존 |
| 구문 구조 | 암시적 (Attention이 추론해야 함) | 명시적 (AST에서 추출 완료) |
| 도메인 의미 | 없음 | 부가됨 |
| 정보 총량 | 원본과 동일 | 원본보다 많음 |
따라서 “정보 손실 제로”는 맞지만, “정보 손실 제로 = 최적”이라는 결론은 틀렸다. 구조적 메타데이터를 추가하면 정보량이 원본보다 늘어난다.
3.3 유효한 범위
구조화 인프라(AST 파서, 온톨로지, 그래프 DB)가 아직 구축되지 않은 초기 단계에서는 raw loading이 유일한 선택지다. 탐색적 분석(“이 코드베이스가 전반적으로 어떤 구조인가”)에서도 raw loading이 적합하다.
4 주장 3: “검색 실패율이 0이다 — 모든 정보가 Attention 안에 있으므로”
4.1 주장의 내용
RAG는 Top-K 검색에서 중요한 정보가 밀릴 수 있지만, LC 모델은 모든 데이터가 Attention 행렬 안에 있으므로 검색 실패가 발생하지 않는다.
4.2 비판
이론적으로 Self-Attention은 \(O(N^2)\) 의 모든 토큰 쌍을 연산한다. 그러나 \(N=1M\) 일 때 행렬 원소 수는 \(10^{12}\) 이다. 실제 구현에서는 이를 감당할 수 없으므로 근사(approximation) 기법을 사용한다:
| 기법 | 작동 방식 | 정보 손실 |
|---|---|---|
| Sparse Attention | 일부 토큰 쌍만 연산 | 비인접 관계 약화 |
| Sliding Window | 로컬 윈도우 내에서만 full attention | 원거리 의존성 약화 |
| Ring Attention | 시퀀스를 분할하여 분산 처리 | 분할 경계에서 약화 |
| Linear Attention | Softmax를 커널 근사로 대체 | 전반적 정밀도 하락 |
“모든 물리적 관계를 하나의 행렬 안에서 연산하므로 경로 손실이 0”이라는 주장은 이론적 상한(theoretical upper bound)을 실제 성능으로 등치시킨 것이다.
4.3 유효한 범위
수천~수만 토큰 범위의 짧은 문맥에서는 full attention이 실제로 작동한다. 이 범위에서는 LC 모델의 “검색 실패율 0” 주장이 사실에 가깝다.
5 주장 4: “RAG의 파편화 문제를 근본적으로 해결한다”
5.1 주장의 내용
RAG는 데이터를 청크로 나누므로 청크 경계에서 맥락이 끊어진다. LC 모델은 전체를 한 번에 보므로 파편화가 없다.
5.2 비판
이 주장은 벡터 검색 기반 RAG에는 타당하지만, GraphRAG에는 해당하지 않는다.
GraphRAG는 Top-K 유사도 검색이 아니라 그래프 순회(traversal) 로 작동한다. Robinson(2015)에 따르면, 네이티브 그래프 저장소는 Index-Free Adjacency 원칙을 따른다:
“각 노드는 인접 노드에 대한 직접 참조를 유지한다. 따라서 각 노드는 주변 노드의 마이크로인덱스 역할을 하며, 쿼리 시간은 그래프 전체 크기와 무관하고 탐색된 그래프의 양에만 비례한다.” (Robinson, 2015, Ch.6)
A가 B를 호출 → B가 C를 참조 → C가 D를 변경이 경로는 코사인 유사도와 무관하게 AST에서 결정론적으로 추출된다. 관계 순회 비용은 관계당 \(O(1)\) 이며 (Robinson, 2015, Ch.6), “검색 실패율”이라는 개념 자체가 적용되지 않는다.
| 차원 | 벡터 RAG | GraphRAG |
|---|---|---|
| 검색 방식 | Top-K 유사도 | 그래프 순회 |
| 정확도 | 근사적 | 정확 |
| 파편화 | 청크 경계에서 발생 | 관계가 명시적이므로 없음 |
| 알고리즘 | ANN (근사 최근접) | BFS, Dijkstra, SCC |
5.3 유효한 범위
청킹 기반 벡터 RAG를 사용하는 경우에는 파편화 비판이 타당하다. 이 경우 LC 모델이 실제로 우위에 있다.
6 주장 5: “비용과 편의성에서 압도적이다”
6.1 주장의 내용
LC 모델은 인프라 구축(임베딩, 벡터 DB, 그래프 DB) 없이 파일을 업로드하기만 하면 된다. Context Caching을 사용하면 비용도 90% 절감된다.
6.2 비판
이 주장 자체는 사실이다. 그러나 “쓰기 편하다”와 “더 좋은 결과를 낸다”는 별개의 주장이다.
| 차원 | LC 모델 | 구조화된 RAG |
|---|---|---|
| 초기 구축 비용 | 낮음 | 높음 |
| 운영 비용 | 토큰 비용 발생 (캐싱으로 절감 가능) | 인프라 유지 비용 |
| 결과 품질 (구조적 추론) | Attention 근사에 의존 | 결정론적 그래프 순회 |
| 결과 품질 (탐색적 분석) | 우수 | 그래프 구조에 의존 |
비용/편의성 논거를 품질 논거와 혼합하여 “압도적”이라고 결론내리는 것은 논리적 비약이다. 어느 쪽이 “더 좋은가”는 무엇을 최적화하느냐에 따라 달라진다.
6.3 유효한 범위
프로토타이핑, 일회성 분석, 인프라 구축 여력이 없는 상황에서는 LC 모델의 비용/편의성 우위가 결정적 장점이 된다.
7 주장 6: “컴파일러급 추론이 가능하다”
7.1 주장의 내용
LC 모델은 100만 토큰 내의 모든 코드를 Self-Attention 행렬 내에서 연산하므로, “3번째 메서드의 설정 변경이 145번째 메서드에 미치는 영향”을 컴파일러처럼 추적할 수 있다.
7.2 비판
LLM의 Attention 메커니즘과 컴파일러의 정적 분석은 근본적으로 다른 연산이다.
| 차원 | 컴파일러 정적 분석 | LLM Attention |
|---|---|---|
| 연산 방식 | AST → CFG → 데이터 흐름 분석 | 토큰 간 가중치 연산 |
| 정확도 | 결정론적 (증명 가능) | 확률적 (근사) |
| 타입 추론 | 형식적 타입 시스템 | 패턴 매칭 기반 추정 |
| 부수 효과 추적 | 명시적 모델링 | 암시적 추론 (불완전) |
LLM이 코드를 “이해”하는 방식은 텍스트 패턴의 통계적 학습이다. 변수의 타입, 스코프, 라이프사이클을 형식적으로 추적하는 것이 아니라, 학습 데이터에서 본 비슷한 패턴을 기반으로 추정한다. 이것은 많은 경우 놀라울 정도로 잘 작동하지만, 보장(guarantee) 을 제공하지는 않는다.
7.3 유효한 범위
일반적인 코드 패턴 이해, 코드 요약, 리팩토링 제안 등에서는 LLM의 패턴 매칭이 충분히 유용하다. 그러나 “이 변경이 정확히 어디에 영향을 미치는가”라는 질문에 대해서는 정적 분석 도구나 GraphRAG가 더 신뢰할 수 있다.
8 LC 모델이 실제로 우위인 시나리오
비판만 하는 것은 공정하지 않다. LC 모델이 구조화된 RAG보다 실제로 나은 경우를 정리한다.
| 시나리오 | LC 우위 이유 |
|---|---|
| 탐색적 분석 (“이 코드베이스의 전반적 구조는?”) | 구조화되지 않은 전체 조망이 필요 |
| 온톨로지/그래프 구축 전 초기 단계 | 구조가 없으므로 raw loading이 유일한 선택지 |
| 비정형적 질의 (“이 코드의 설계 철학은?”) | 구조적 검색으로 포착하기 어려운 암묵적 패턴 |
| 빠른 프로토타이핑 | 인프라 구축 없이 즉시 분석 가능 |
| 소규모 데이터 (수천~수만 토큰) | Full attention이 실제로 작동하는 범위 |
9 정리
LC 모델의 주장들은 각각 특정 조건에서만 유효하다. “1M 토큰을 넣을 수 있다”는 물리적 수용 능력과 “1M 토큰 안에서 정확하게 추론한다”는 인지적 처리 능력을 구분해야 한다.
| 주장 | 유효한 조건 | 유효하지 않은 조건 |
|---|---|---|
| NIAH 99%+ | 단일 정보 검색 | 다단계 인과추론 |
| 정보 손실 제로 | 텍스트 수준 비교 | 구조적 메타데이터 포함 시 |
| 검색 실패율 0 | 이론적 full attention | 실제 근사 기법 사용 시 |
| 파편화 해결 | 벡터 RAG 대비 | GraphRAG 대비 |
| 비용/편의성 | 프로토타이핑, 일회성 분석 | 반복적 대규모 분석 |
| 컴파일러급 추론 | 일반 패턴 이해 | 정확한 영향도 분석 |
Huyen(2026, Ch.10)의 표현을 빌리면, “복잡한 시스템은 더 많은 태스크를 해결할 수 있지만, 더 많은 실패 모드를 도입하여 디버깅을 어렵게 만든다.” LC 모델은 단순하고 강력하지만, 그 단순함이 곧 한계이기도 하다.
10 관련 주제
이 시리즈
- 구조화된 RAG 아키텍처: AST 온톨로지 + GraphRAG + Agentic RAG — LC의 대안으로서 구조화된 RAG의 설계
- RAG vs Long Context: 유즈케이스별 선택 프레임워크 — 실무 의사결정 가이드
선행 지식
- RAG 변형 비교 — Self-RAG, Corrective RAG, AutoRAG, Agentic RAG 개념
- RAG 오케스트레이션 고도화 로드맵 — RAG 진화 단계
교재 참조
- Huyen, C. (2026). AI Engineering. Ch.6, Ch.10.
- Robinson, I. et al. (2015). Graph Databases. 2nd Ed., O’Reilly. Ch.6.
- Keet, C.M. (2020). An Introduction to Ontology Engineering. Ch.1.