프로그래밍 기초편 · 복잡도: 이 코드, 쓸 만한가?

컨텍스트가 길수록 왜 비쌀까? O(n²) 청구서

지난 레슨에서 Big-O 자를 손에 넣었죠—이륙하던 빨간 선 기억나요? 오늘은 LLM 안에서 가장 유명한 O(n²)—어텐션 메커니즘을 봅니다. 끝나면 오래된 질문들이 갑자기 풀려요: 왜 긴 대화는 점점 버벅이고, 왜 컨텍스트 윈도우는 「창고」가 아니라 「창문」이며, 왜 다들 컨텍스트 압축에 목을 매는지.

먼저 복습 · 어텐션은 뭘 하나요

앞 강의에서 다뤘어요: LLM이 새 토큰(token)을 만들 때마다 앞선 모든 토큰을 「되돌아보고」, 각각에 어텐션 가중치를 준 뒤에야 다음에 뭘 붙일지 압니다. 토큰 하나가 모든 토큰을 한 바퀴 본다—지난 레슨 말로 옮기면: 토큰 n개, 각각이 n개를 보니 총 n × n번의 「눈맞춤」. 그게 n×n 표예요. 슬라이더로 그려 드릴게요.

인터랙티브 1 · 어텐션 행렬: n²는 이렇게 생겼어요

아래 한 줄은 「토큰 하나가 모든 토큰을 본다」이고, 진한 대각선은 자기 자신을 보는 칸입니다. 오른쪽 칸 수를 보세요: 슬라이더는 고르게 가는데 숫자는 점점 세게 뛰어요—그게 「제곱 증가」의 감촉입니다.

8개
한 줄 = 토큰 하나가 모든 토큰을 본다
TOKEN 수 n
8
눈맞춤 횟수 n²
64
= 어텐션 행렬의 칸 수
n을 4에서 48로 끌면 12배인데, 칸은 16에서 2304로—144배. 실제 대화는 수만 토큰이 흔해요—이 그림을 머릿속에서 천 배 키워 보면, GPU가 뭘 계산하는지 알 수 있어요.
인터랙티브 2 · 같은 질문, 두 가지 컨텍스트

똑같이 「핵심만 요약해 줘」라고 물어요. 한 사람은 기록을 1만 토큰으로 줄인 뒤, 다른 사람은 10만 토큰 통째로 넣습니다. 토큰은 10배 차인데 청구서는 얼마나 벌어질까요. 「어텐션 계산량」 줄을 보세요: ×10이 아니라 ×100입니다.

절약파 1만 token
질문과 관련된 단락만 남기고 질문
어텐션 계산량1배
첫 글자 지연（예시）≈ 1초
이번 입력 비용（예시）≈ ¥0.1
다 넣기파 10만 token
전체 기록을 통째로 컨텍스트에 투입
어텐션 계산량100배
첫 글자 지연（예시）≈ 수십 초
이번 입력 비용（예시）≈ ¥1+
※ 지연·비용은 자릿수 감 예시이며 정확한 견적이 아니에요. 모델·요금제마다 차이가 큽니다
핵심 한 줄: 컨텍스트 10배면 어텐션 계산 100배. 비용은 대체로 토큰 수를 따라가고(×10부터, 긴 컨텍스트 요금제는 가산이 흔함), 지연과 VRAM 압박은 계산량을 따라가요—그래서 LLM에선 「조금 더 넣어도 손해는 없다」가 성립하지 않습니다. 넣은 토큰마다 뒤따르는 모든 토큰이 반복해서 되돌아봅니다.
지식 이어 보기 · 앞 강의의 세 가지를 설명합니다
🐢

① 왜 긴 대화는 점점 버벅이나

대화가 길수록 n이 커지고, 새 토큰마다 「되돌아보기」가 늘어납니다. 버벅임은 네트워크 문제가 아니라 백그라운드에서 n²가 눈덩이처럼 커지는 거예요.

🗜

② 왜 컨텍스트 압축을 하나

Compaction은 옛 대화를 짧은 요약으로 줄인 뒤 이어 갑니다. 디테일 조금을 희생해 n을 크게 줄여요—n을 절반으로 줄이면 계산량은 3/4가 깎입니다. 이득이죠.

💾

③ 왜 KV Cache가 돈을 아끼나

접두사에서 이미 계산한 어텐션 결과를 캐시해 다음 턴에 다시 안 합니다(자매편 ds-6). 원래 계산이 O(n²)로 비싸기 때문에 캐시 할인이 더 값진 거예요.

일상으로 가져가세요. 다음에 AI와 긴 대화가 버벅이거나 청구서가 커지면 할 일이 보여요: 새 대화를 열고, 먼저 요약하게 한 뒤 이어 가고, RAG에서는 관련 단락만 리콜합니다. 트릭 뒤의 수학은 같아요—n을 조금 줄이면 n²는 많이 줄어요.

이 강의가 전하고 싶은 것