· LLM

메모리 매니지 랭귀지에 이어서 컨텍스트 매니지 모델

여러분, 그거 아셨나요?

LLM이 스스로 컨텍스트를 관리하는 기법은 다들 아실 텐데요. MemGPT가 제시한 방법이 대표적이죠. 툴 호출로 청크 단위 정보를 불러오고, 슬라이딩 윈도우로 오래된 건 아카이브하거나, LLM이 직접 대화를 요약해서 압축합니다. 긴 대화 요약 걸어주는 도구들, 전부 여기서 나온 아이디어예요.

근데 이런생각이 들었습니다. <-이건 ai아니고 진짜 제 생각임.

GIF

"모델이 스페셜 토큰으로 중요하지 않은 토큰을 표시하면, 서빙 엔진이 이를 감지해서 몰래 빼버린다면 좋지않을까?"

왜냐면 llm 은 본인의 추론실수를 인지할정도로 똑똑하거든요.

근데 진짜 얼탱없는건 이미 활발히 연구되고 있는 분야라는겁니다. 전 이미 늦었던거에요. 근데 그전에 알아야 할게 있습니다.

아무 의미 없는 첫 토큰이 제일 절대 안 죽어

LLM한테 첫 토큰은 별 의미 없어요. 그냥 시작 기호잖아요. 근데 이 녀석이 어텐션을 어마어마하게 빨아들입니다. 내용이랑 상관없이요. 연구자들은 이걸 attention sink라고 불러요.

문제는 여기서예요. 긴 대화에서 이 sink 토큰을 밀어내버리면 모델 출력이 개판이 됩니다. StreamingLLM이 밝혀낸 사실이고요. 그래서 서빙 엔진들은 이 쓸모없어 보이는 토큰을 절대 안 버려요. 버리면 망하니까요.

OpenAI gpt-oss는 아예 어텐션 헤드마다 학습된 sink 벡터를 박아놨어요. vLLM 공식 블로그에 명시돼 있어요.

말해뭐 해요. 제일 멍청해 보이는 토큰이 제일 오래 살아남는 겁니다.

GIF

중요한 토큰만 남기고 쳐내는 연구는 진짜다

참고로 이런 eviction 연구들, sink 토큰은 예외로 남겨두는 게 정석이 됐어요. StreamingLLM이 그 방어 로직의 출발점이고요.

프로덕션 서빙엔진(vLLM 같은)이 실제로 비우는 건 이게 아니라 요청끼리 재활용하는 prefix 캐시예요. LRU로 오래된 캐시를 정리하는 거지, 지금 진행 중인 대화에서 토큰을 몰래 빼는 게 아닙니다.

DeepSeek는 아예 "볼 토큰"만 골라 봅니다

DeepSeek-V3.2-Exp부터 들어간 DSA가 이거예요. 라이트닝 인덱서라는 작은 모듈이 매 쿼리마다 "이 토큰들만 보면 돼" 하고 top-k를 고르고, 엔진은 선택 안 된 토큰의 어텐션 계산을 스킵해요.

소문의 "서빙엔진이 토큰을 빼버린다"에 제일 가까운 실체인데, 정확히는 빼는 게 아니라 안 보는 겁니다. 긴 컨텍스트 비용을 확 깎는 트릭이에요. 제가 했던 생각보다 더 고도화된 방법이죠.

그래서 저도 해봤습니다

모델 레이어 얘기만 하면 뜬구름 잡는 느낌이라서, 제가 같은 문제로 만든 오픈소스 두 개를 소개할게요. 규칙으로 정리하느냐, 요약으로 바꾸느냐. 정반대 방향입니다.

inline-agent — LLM 호출 0, 순수 규칙 기반

에이전트는 매 스텝마다 대화 기록 전체를 다시 읽어요. 연구 보면 Claude 4 Sonnet 하루 1000억 토큰 중 99%가 생성이 아니라 재독입니다(Xiao et al., FSE 2026). SWE-bench 트레이토리 평균도 48.4K 토큰 중 63%가 툴 결과인데, 대부분 다음 스텝엔 무의미한 것들이죠. 통과한 테스트 로그, ls 결과 같은 것들.

근데 위에서 본 것처럼 LLM은 자기 컨텍스트를 안 지워요. AgentDiet가 erase 도구를 줘도 Claude 4 Sonnet은 원래 태스크만 했어요. 그래서 inline-agent는 "LLM이 모르게 외부에서 정리"합니다.

pi-recap — 요약으로 갈아끼우고, 필요하면 되찾기

규칙만으로는 선을 못 그리는 경우가 있더라고요. 그래서 pi-recap은 반대로 LLM한테 요약을 맡겼습니다. 메인 에이전트가 일하는 동안, 메인과 같은 모델·같은 컨텍스트를 공유하는 familiar이라는 조수가 툴 결과마다 1~3줄 요약을 써요. 몇 턴 뒤엔 원본을 조용히 요약으로 갈아끼웁니다. 필요해지면 recap_recover로 원문 복구.

포인트는 familiar이 메인과 같은 prefix를 쓴다는 거예요. provider prefix cache를 타니까 요약 입력이 캐시 요금으로 계산되고, 메인 다음 호출의 캐시까지 데워집니다.

실측도 있습니다. 실제 코딩 세션에서 메인 컨텍스트의 툴 결과 토큰 75.5K → 7.0K, 90.7% 절감. 긴 세션 226개 요약을 분석했을 때 원문 복구 호출은 127번 중 0번이었어요. 요약만으로 충분했다는 뜻입니다.

근데 여기서 정당한 의문이 하나 생겨요. 요약이 엉터리였거나, 필요한 걸 잘라버렸다면 어쩌냐고요.

에이전트 추론 로그를 보면 스왑에 대한 불만이 한 번도 없어요. 그게 정상일까요? 제 판단은 이렇습니다. 불충분했으면 티가 났을 거예요.

한 가지 정직하게 덧붙이면, 모델이 항상 솔직하게 말해주는 건 아니라는 연구도 있습니다(Reasoning Models Don't Always Say What They Think, 2025). 그래서 저는 "말"이 아니라 "행동 신호"로 판단해요. 복구 호출, 재탐색, 같은 걸 다시 묻기. 127번의 스왑에서 그 신호가 한 번도 없었다는 건, 불충분 사례가 관측되지 않았다는 뜻입니다.

그리고 스왑은 에이전트한테 알리지도 않는데, 모르고 잘만 돌아가더라고요. 소문의 "몰래 빼버린다"를 진짜로 구현한 건 모델이 아니라 제 도구였습니다.

정리

슬롭은 안 믿고 원문을 믿읍시다. 출처 전부 실제 논문·공식 문서예요.

MemGPT · StreamingLLM · H2O · SnapKV · DeepSeek-V3.2 · ReAct · Kadavath 2022 · SQuAD 2.0 · Lost in the Middle · CoACT · CoT 비충실성 · vLLM gpt-oss

comments (1)

182.213.255.51

GIF