토큰이 늘면 메모리도 는다

프롬프트, 컨텍스트, 하네스, 에이전트 루프로 AI 호출 구조가 복잡해질수록 토큰과 추론 메모리 수요가 어떻게 늘어나는지 설명합니다.

요즘 AI를 쓰는 방식이 바뀌고 있습니다. 예전에는 “질문을 어떻게 잘 쓰느냐”가 중심이었습니다. 그래서 프롬프트 엔지니어링이라는 말이 먼저 유행했습니다.

그런데 실제 업무에 AI를 붙여 보면 프롬프트만으로는 부족합니다. 모델에게 어떤 문서를 넣을지, 어떤 도구를 연결할지, 결과를 어떻게 검증할지, 실패하면 몇 번 다시 돌릴지를 설계해야 합니다. 그래서 관심은 프롬프트 엔지니어링에서 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링으로 넓어지고 있습니다.

이 변화는 단순한 방법론 변화가 아닙니다. AI 인프라 관점에서는 토큰 사용량 증가이고, 토큰 사용량 증가는 곧 메모리 수요 증가로 이어집니다.

프롬프트 엔지니어링: 한 번 잘 묻는 단계

프롬프트 엔지니어링은 모델에게 원하는 답을 얻기 위해 지시문을 잘 쓰는 기술입니다. 역할을 지정하고, 형식을 정하고, 예시를 넣고, 금지 조건을 붙입니다.

이 단계의 토큰 사용량은 비교적 단순합니다. 사용자가 넣은 입력 토큰과 모델이 생성한 출력 토큰이 대부분입니다. 예를 들어 2,000토큰짜리 지시문을 넣고 1,000토큰 답변을 받으면 한 번의 호출은 약 3,000토큰입니다.

물론 프롬프트가 길어질수록 비용은 늘어납니다. 하지만 아직은 “한 번 호출해서 한 번 답을 받는 구조”에 가깝습니다. 메모리 관점에서도 부담은 컨텍스트 길이와 동시 사용자 수에 비례하는 정도로 이해할 수 있습니다.

컨텍스트 엔지니어링: 모델에게 무엇을 보여줄 것인가

컨텍스트 엔지니어링은 질문 문장보다 넓은 문제입니다. 모델이 답을 내기 전에 어떤 정보를 보게 할지 정하는 일입니다.

여기에는 회사 문서, 코드베이스, 과거 대화, 사용자 프로필, 검색 결과, 벡터DB에서 가져온 문단, 도구 설명, 출력 스키마가 들어갑니다. 프롬프트는 짧아도 컨텍스트가 길면 실제 입력 토큰은 크게 늘어납니다.

예를 들어 기본 질문은 2,000토큰이어도, 관련 문서 20,000토큰과 도구 설명 3,000토큰이 붙으면 입력은 25,000토큰이 됩니다. 답변 1,500토큰까지 더하면 한 번의 호출이 약 26,500토큰으로 커집니다. 단순 프롬프트 호출의 8배 이상입니다. 이 글의 토큰 수치는 호출 구조를 설명하기 위한 가상 예시입니다.

여기서 메모리 부담이 생깁니다. LLM은 긴 컨텍스트를 읽는 동안 각 토큰의 상태를 내부적으로 유지해야 합니다. 특히 추론 중에는 KV cache가 필요합니다. KV cache는 모델이 이전 토큰을 다시 계산하지 않도록 key와 value 상태를 저장해 두는 구조입니다. 컨텍스트가 길어질수록 이 캐시는 대체로 선형적으로 커집니다.

그래서 긴 컨텍스트 모델은 단순히 “많이 읽는다”가 아닙니다. HBM 위에 더 많은 토큰 상태를 올려야 하고, 동시에 여러 사용자를 처리하면 서버 전체 메모리 요구량이 빠르게 커집니다.

하네스 엔지니어링: 한 번이 아니라 계속 검증하는 단계

하네스 엔지니어링은 AI를 제품이나 업무 시스템에 넣을 때 중요해집니다. 여기서 하네스는 모델을 둘러싼 실행·평가·검증 장치라고 볼 수 있습니다.

예를 들어 고객 응대 AI를 만든다고 해보겠습니다. 한 번 좋은 답을 내는 것만으로는 부족합니다. 50개, 100개, 1,000개의 테스트 질문을 돌려야 합니다. 답변이 정책을 지키는지, 개인정보를 흘리지 않는지, 근거 문서를 제대로 인용하는지, 실패 케이스에서 안전하게 멈추는지 확인해야 합니다.

이때 토큰 사용량은 테스트 케이스 수만큼 곱해집니다. 한 케이스당 입력 10,000토큰, 출력 800토큰이 필요하고 50개 케이스를 돌리면 총 54만 토큰입니다. 단순 프롬프트 3,000토큰과 비교하면 180배입니다.

하네스는 제품 품질을 높이지만, 인프라 입장에서는 대량 반복 호출입니다. 개발 단계, 회귀 테스트, A/B 테스트, 안전성 평가가 모두 토큰을 소비합니다. AI 서비스가 성숙할수록 “사용자가 실제로 쓴 토큰” 외에 “검증을 위해 내부에서 태운 토큰”이 커집니다.

루프 엔지니어링: 에이전트가 생각하고 실행하고 다시 읽는 단계

AI 에이전트는 한 번 답하고 끝나지 않습니다. 계획을 세우고, 도구를 호출하고, 결과를 읽고, 다시 판단하고, 필요하면 수정합니다. 이 반복 구조가 루프입니다.

문제는 루프가 돌 때마다 토큰이 누적된다는 점입니다. 첫 번째 단계에서는 사용자 요청과 시스템 지시만 있으면 됩니다. 두 번째 단계부터는 이전 판단, 도구 출력, 오류 로그, 검색 결과, 중간 산출물이 다시 컨텍스트에 들어옵니다. 루프가 길어질수록 모델이 읽어야 할 작업 기억이 늘어납니다.

예를 들어 한 단계당 입력 14,000토큰, 출력 1,000토큰이 필요하고 8단계 에이전트 루프가 돈다면 총 12만 토큰입니다. 단순 프롬프트 호출보다 40배입니다. 실제 코딩 에이전트나 리서치 에이전트는 여기에 파일 검색, 테스트 로그, 웹 검색 결과, 리뷰 지시까지 붙습니다.

이 구조에서는 메모리 수요가 두 방향으로 늘어납니다. 하나는 매 호출의 컨텍스트가 길어지는 방향입니다. 다른 하나는 루프 횟수와 동시 작업 수가 늘어나는 방향입니다. 긴 컨텍스트와 많은 반복이 만나면 HBM 용량, HBM 대역폭, 서버 D램, 스토리지 I/O가 모두 영향을 받습니다.

한눈에 보는 토큰 곱셈 구조

아래 수치는 앞선 설명과 같은 가상 예시입니다. 핵심은 한 번의 호출이 길어지는 것뿐 아니라, 테스트 케이스와 에이전트 단계가 더해질 때 전체 토큰이 곱셈으로 커진다는 점입니다.

왜 토큰 증가는 메모리 수요로 이어질까

토큰은 단순한 과금 단위가 아닙니다. 인프라에서는 모델이 읽고, 저장하고, 참조해야 하는 작업 단위입니다.

입력 토큰이 길어지면 KV cache가 커집니다. 출력 토큰이 길어지면 생성 시간이 늘어나고, 생성 중에도 이전 토큰 상태를 계속 참조해야 합니다. 동시 사용자가 늘면 같은 구조가 배치 단위로 반복됩니다. 에이전트 루프가 길어지면 한 작업이 더 오래 GPU와 메모리를 점유합니다.

그래서 AI 메모리 수요를 HBM 하나로만 설명하기 어렵습니다. HBM은 모델 실행과 KV cache에 가까운 고속 메모리입니다. 서버 D램은 검색, 전처리, 라우팅, CPU 기반 작업을 받칩니다. CXL은 GPU나 CPU에 직접 붙지 않은 확장 메모리 계층을 열어 줍니다. SSD와 NVMe는 문서, 벡터, 로그, 데이터셋, 체크포인트를 저장하고 불러옵니다.

프롬프트 엔지니어링은 토큰을 잘 쓰는 기술이었습니다. 컨텍스트 엔지니어링은 모델이 볼 정보를 늘렸습니다. 하네스 엔지니어링은 검증을 위해 호출 횟수를 늘렸습니다. 루프 엔지니어링은 작업이 끝날 때까지 모델을 반복 실행하게 만들었습니다.

이 네 가지가 합쳐지면 AI 서비스의 토큰 소비는 단순 증가가 아니라 곱셈 구조가 됩니다. 더 긴 입력, 더 많은 테스트, 더 많은 반복, 더 많은 동시 실행이 한꺼번에 올라갑니다.

메모리 인프라를 볼 때의 질문

앞으로 AI 인프라를 볼 때는 “모델이 얼마나 큰가”만 보면 부족합니다. 더 중요한 질문은 이것입니다.

그 모델이 실제 업무에서 몇 번 호출되고, 매번 얼마나 긴 컨텍스트를 읽고, 실패하면 몇 번 다시 도는가?

기업 업무에 AI 에이전트가 들어갈수록 이 질문은 더 중요해집니다. 보고서 작성, 코드 수정, 고객 응대, 설비 분석, 리서치 자동화는 모두 한 번의 프롬프트가 아니라 컨텍스트와 하네스와 루프를 필요로 합니다.

내 업무는 어디쯤일까

• 우리 AI 호출은 한 번 묻고 끝나는가, 아니면 검증 루프가 도는가?
• 컨텍스트에 매번 붙는 문서와 도구 설명이 몇 토큰인지 파악하고 있는가?
• 테스트·회귀·안전성 평가에 쓰는 토큰이 실사용 토큰보다 크지는 않은가?

그래서 AI 도입이 확산될수록 토큰 사용량은 늘고, 토큰 사용량이 늘수록 메모리 병목은 더 자주 드러납니다. AI 메모리 수요는 모델 학습만의 이야기가 아닙니다. 실제 업무에서 에이전트가 오래 생각하고, 많이 읽고, 여러 번 검증하는 순간부터 추론 메모리 수요의 이야기가 됩니다.

HBM이 GPU 가까이에서 어떤 병목을 푸는지 더 보고 싶다면 HBM, AI 서버의 메모리 대역폭 병목을, CXL이 확장 메모리 계층에서 맡는 역할은 CXL 메모리, AI 인프라의 다음 병목에서 이어서 볼 수 있습니다.

이 글은 AI 인프라와 메모리 수요를 이해하기 위한 기술 해설입니다. 특정 기업이나 금융 판단을 다루지 않습니다.

확인한 출처 / 근거

• Anthropic, “Effective context engineering for AI agents” (2025-09-29) — 에이전트의 컨텍스트 구성과 관리 원칙.
• TrendForce, “How AI Inference Is Creating New Memory Demand” (2026-06-18) — AI 추론 확대와 메모리 수요의 연결.
• Neo4j, “Why AI teams are moving from prompt engineering to context engineering” (2026-01-16) — 프롬프트에서 컨텍스트 중심 설계로의 전환.
• Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention” (SOSP 2023) — 긴 시퀀스와 대규모 배치에서 KV cache의 동적 증가·단편화가 서빙 병목이 되는 구조.
• Hugging Face Transformers, “KV cache strategies” — 이전 토큰의 key/value 상태를 재사용해 추론 시 반복 계산을 줄이는 KV cache의 동작 방식.
• CXL Consortium, “CXL Specification” — 메모리 확장·공유를 위한 CXL 인터커넥트의 공식 규격과 세대별 개요.