내 AI 에이전트가 세션 도중에 멍청해졌다. MCP를 탓하기 전에 컨텍스트 윈도우(Context Window)를 측정해 보았다.

AI 코딩 에이전트가 성능이 저하되는 특정한 방식이 있습니다. 충돌이나 에러가 발생하는 것이 아닙니다. 그저 점점 둔해지는 것입니다. 긴 세션의 중간쯤에 되면 초기에 설정한 제약 조건을 잊어버리거나, 이미 답변한 질문을 반복하거나, 한 시간 전에는 잘 처리했던 것과 같은 종류의 요청에 대해 더 짧고 모호한 답변을 하기 시작합니다. 실제로 무언가 고장 나지 않았음에도 품질이 떨어지는 것을 느낄 수 있습니다.

제 첫 번째 본능은 MCP를 탓하는 것이었습니다. 몇 개의 서버가 연결되어 있었고, 연결된 서버들이 컨텍스트 윈도우 (Context Window)를 잡아먹는다는 글을 읽었기에 이야기는 저절로 만들어졌습니다. 너무 많은 도구(Tools)가 로드되어 생각할 공간이 남지 않았고, 당연히 성능이 표류(Drifting)하고 있다는 식이었죠. 저는 막 연결을 해제하려던 참이었습니다. 그러다 먼저 측정해 보기로 결정했고, 측정 결과는 제가 예상했던 것과는 달랐습니다.

추측 대신 분석 내용을 읽다

제가 사용하는 에이전트는 현재 컨텍스트 윈도우 (Context Window)를 채우고 있는 내용을 카테고리별로 분석하여 출력할 수 있습니다. 그래서 무엇인가를 끊어내기 전에, 토큰(Tokens)이 실제로 어디로 가고 있는지 살펴보았습니다. 절대적인 수치는 모델과 윈도우 크기에 따라 달라지므로, 유의미한 형태를 보여줄 수 있도록 원시 숫자 대신 비율로 말씀드리겠습니다.

대략, 성능 저하가 시작된 세션에서의 구성은 다음과 같았습니다:

대화 기록 (지금까지의 주고받은 대화): 단일 항목 중 가장 큰 비중을 차지하며, 전체 윈도우의 약 5분의 1을 차지함
고정된 시작 오버헤드 (시스템 프롬프트 (System Prompt), 도구 프레임워크 (Tool Framework), 메모리 파일): 의미 있는 비중을 차지하지만, 안정적이며 일회성임
연결된 MCP 도구 정의: 작은 비중. 제가 걱정했던 반올림 오차보다도 작음

제가 탓하려 했던 것은 목록의 거의 맨 아래에 있었습니다. 제가 생각하지 못했던 것, 즉 대화의 단순한 누적이 맨 위에 있었습니다.

MCP 가설이 절반만 맞았던 이유

여기서 주의를 기울이고 싶습니다. 왜냐하면 "MCP는 비용이 전혀 들지 않는다"라고 결론 내리는 것은 잘못된 교훈이며, 제가 발견한 사실도 아니기 때문입니다.

MCP는 무거울 수 있습니다. 연결된 서버가 전체 도구 스키마 (tool schema)를 로드하여 매 턴마다 이를 전달할 수 있으며, 만약 클라이언트가 이 모든 것을 사전에 로드한다면, 단 몇 개의 서버만으로도 사용자가 한 마디를 입력하기도 전에 컨텍스트 윈도우 (context window)의 상당 부분을 차지할 수 있습니다. 이러한 경고는 실재하며, 많은 사람들이 자신의 환경에서 이를 직접 측정해 보았습니다. 따라서 많은 서버를 연결하고 클라이언트가 스키마를 미리 로드(front-loads)하는 방식이라면, 사용하지 않는 것은 연결을 해제하라는 일반적인 조언은 타당합니다.

제가 덧붙이고 싶은 점은 더 구체적입니다. 이는 클라이언트가 도구를 어떻게 로드하느냐에 달려 있습니다. 어떤 설정에서는 스키마 로드를 지연시키고, 도구가 실제로 필요할 때만 정의를 가져옵니다. 그러한 설정에서는 연결된 유휴 서버들이 최악의 경우 예상되는 수치보다 훨씬 적은 비용을 소모하며, 제가 측정한 세션에서도 이들이 병목 현상 (bottleneck)의 원인은 아니었습니다. "MCP는 비용이 많이 든다"라는 일반적인 주장과 "MCP가 내 윈도우를 채운 것이 아니었다"라는 저의 구체적인 결과는 서로 충돌하지 않습니다. 이들은 서로 다른 로딩 동작에 관한 것입니다. 정직한 결론은 "MCP는 무죄다"가 아니라, "설정에 따라 다르므로 어떤 항목이 문제인지 함부로 단정 짓지 마라"입니다.

실제로 무엇이 채우고 있었나

제가 눈치채지 못하는 사이에 늘어난 부분은 대화 기록 (conversation history)이었습니다. 이를 확인하면 이해가 됩니다. 모든 교환 내용이 윈도우에 남아 있으며, 긴 탐색적 세션은 턴이 거듭될수록 계속 쌓여 결국 초기 컨텍스트가 모델이 지금 당장 필요로 하는 부분과 공간을 다투게 됩니다. 극적인 무언가가 추가된 것이 아니었습니다. 그저 긴 대화가 주는 꾸준한 무게였으며, 제가 직접 켠 "기능"처럼 느껴지지 않았기에 살펴볼 생각조차 못 했던 부분이었습니다.

이것은 저에게 성능 저하 (drift)의 의미를 재정의해 주었습니다. 에이전트가 멍청해진 것은 제가 무엇을 연결했기 때문이 아니었습니다. 제가 매우 긴 대화를 나누고 있었고, 추론을 위한 공간이 그 대화의 기록으로 서서히 채워지고 있었기 때문에 멍청해진 것이었습니다.

이제 저는 어떻게 대응하는가

해결책 중 영리한 것은 없습니다. 그저 기록이 무거운 부분이라는 것을 알게 된 후 따르게 되는 조치들일 뿐입니다.

저는 하나의 탐색적 세션(exploratory session)을 영원히 지속하게 두지 않습니다. 작업의 흐름이 기본적으로 완료되면, 전체 대화 기록(transcript)을 다음의 관련 없는 작업으로 가져가는 대신 새로 시작합니다. 연속성이 필요한 경우에는 전체 이력을 그대로 끌고 가는 대신, 에이전트에게 현재 상황을 요약하게 한 뒤 그 요약본을 새로운 세션으로 가져갑니다. 핵심은 전체 대화 내용(full back-and-forth)이 아니라 요점(gist)을 옮기는 것입니다. 왜냐하면 전체 대화 내용이야말로 제가 측정한 바로 그 '무게(weight)'이기 때문입니다.

머릿속에 각인된 멘탈 모델(mental model)은 이렇습니다. 컨텍스트 윈도우(Context Window)는 서류 보관함(filing cabinet)이 아니라 책상(desk)입니다. 모델이 한 번에 사용하기를 원하는 모든 것은 책상 표면에 들어갈 수 있어야 하며, 긴 대화는 작업할 공간이 없어질 때까지 종이로 책상을 서서히 덮어버립니다. 때로는 더 큰 책상을 사는 것보다 책상을 치우는 것이 더 낫습니다.

실제 교훈은 MCP에 관한 것이 아니다

만약 제가 첫 번째 직관을 따랐다면, 서버 몇 개를 연결 해제하여 약간의 여유 공간을 확보한 뒤, 성능 저하(drift)가 계속되는 것을 지켜보며 아무것도 배우지 못했을 것입니다. 해결책은 원인을 놓쳤을 것이고, 저는 제가 비난하기로 마음먹었던 도구를 탓했을 것입니다.

따라서 제가 간직하려는 교훈은 "항상 기록(history)이 범인이다"가 아닙니다. 왜냐하면 다른 사람의 설정에서는 실제로 연결된 서버나 메모리 파일, 혹은 제가 생각하지 못한 다른 무언가가 원인일 수도 있기 때문입니다. 제가 간직하려는 것은 작업 순서(order of operations)입니다. 에이전트가 성능 저하를 보이기 시작하면, 무엇인가를 끊어내기 전에 먼저 분석(breakdown)을 읽으십시오. 당신이 문제라고 확신하는 항목과 실제로 문제인 항목은 종종 일치하지 않으며, 이 둘을 구별하는 유일한 방법은 직접 살펴보는 것입니다.

다음의 나에게 남기는 메모

에이전트가 세션 도중에 멍청해진다면, 이미 알고 있는 설명을 떠올리지 마세요. 먼저 측정하십시오. 토큰이 실제로 어디로 가고 있는지 읽고, 실제로 용량이 큰 슬라이스(slice)를 수정하십시오. 그리고 설정에 따라 상황이 달라질 수 있으므로, 지난번의 원인이 규칙이 아님을 받아들이십시오. 저의 경우에는 대화 기록(conversation history)이 문제였기에, 세션을 더 짧게 유지하고 전체 기록(transcript) 대신 요약본을 전달합니다. 다음번에는 다른 것이 원인일 수도 있으며, 이것이 바로 추측하는 대신 직접 확인해야 하는 이유입니다.

저는 https://raplsworks.com/에서 WordPress 플러그인을 제작하고 AI 도구 및 보안에 관한 글을 씁니다.