AI 코딩 에이전트를 쓰다 보면 자연스럽게 확장을 늘리게 됩니다. 인증을 도와주는 MCP 서버 하나, 데이터베이스 쿼리를 잘 짜주는 스킬 하나, 팀이 만든 지시 파일 하나. 각각은 분명히 도움이 됐습니다. 그런데 14개를 깔고 나니 결과가 오히려 나빠졌습니다. 어느 하나가 고장 난 것도 아닌데 말이죠.

마이크로소프트의 Principal Developer Advocate인 발덱 마스티카즈(Waldek Mastykarz)가 ‘Agent Experience(AX)’ 시리즈의 네 번째 글에서 이 문제를 정면으로 다뤘습니다. 핵심은 명확합니다. 확장은 더하기처럼 작동하지 않으며, 각각 단독으로는 성능을 끌어올리던 확장도 함께 놓이면 서로의 발목을 잡는다는 것입니다. 그는 이를 ‘구성 비용(composition tax)’이라 부릅니다.

출처: When your agent extensions fight each other – Microsoft for Developers

더하기가 아니라 빼기인 이유

확장 A는 인증 코드를, 확장 B는 데이터베이스 쿼리를 개선한다고 해봅시다. 둘 다 깔면 인증도 좋아지고 쿼리도 좋아질 것 같습니다. 그런데 그렇지 않습니다.

첫 번째 이유는 자리싸움입니다. 모든 확장은 설치되어 있다는 것만으로 컨텍스트 윈도우의 토큰을 잡아먹습니다. 도구 8개를 가진 MCP 서버 하나가 약 2,000토큰의 도구 설명을 더하고, 서버 다섯 개면 질문을 던지기도 전에 1만 토큰이 도구 설명만으로 사라집니다. 컨텍스트 윈도우는 정해진 예산입니다. 도구 설명에 쓴 토큰은 작업 맥락이나 대화 기록에 쓰지 못한 토큰이죠. 확장이 충분히 쌓이면 시스템은 가위질을 시작합니다. 도구 설명을 요약하고, 관련 없다고 판단한 도구를 버리고, 안 들어가는 건 잘라냅니다. 공들여 쓴 도구 설명이 모델이 알아보기 힘든 형태로 뭉개지는 거죠.

두 번째 이유가 더 미묘합니다. 모델은 확장들을 하나씩 따로 처리하지 않고 컨텍스트 안의 모든 것을 동시에 봅니다. 그래서 인증 확장 옆에 데이터베이스 확장을 놓으면, 둘이 아무 관계가 없어도 각자 단독으로 있을 때와는 다른 결과를 내놓습니다. 관련 없는 도구 설명이 그저 존재한다는 사실만으로 모델의 주의가 흔들리고 출력이 바뀝니다. 마이크로소프트는 단독으로는 꾸준히 성능을 올리던 확장이 다른 확장 하나만 추가돼도 성능을 떨어뜨리는 것을 직접 측정했습니다.

확장끼리 부딪히는 세 가지 방식

토큰 예산만 문제가 아닙니다. 확장들은 더 알아채기 힘든 방식으로 서로를 방해합니다.

첫째는 어휘 충돌입니다. 두 확장이 비슷한 말로 자기 도구를 설명하는 경우죠. 한쪽은 “인증 설정 관리”, 다른 쪽은 “ID 및 액세스 구성”이라고 써뒀습니다. 개발자가 “앱 인증 설정해줘”라고 하면 두 도구 모두 의도에 들어맞고, 모델은 둘 중 하나를 고르는데 그게 내 도구가 아닐 수 있습니다. 더 골치 아픈 건 디버깅입니다. 개발자는 잘못된 결과를 보고 모델을 탓하지만, 이건 어느 확장의 버그도 아니라 어휘가 겹치는 두 도구를 같은 컨텍스트에 넣었을 때 생기는 창발적 현상입니다. 게다가 그 선택은 실행할 때마다 달라질 수 있습니다.

둘째는 지침 충돌입니다. 확장은 도구 설명이나 스킬 정의를 통해 지침을 주입하고, 에이전트는 저장소에 있는 지시 파일(AGENTS.md 등)도 함께 읽습니다. 내 확장은 “항상 v3 SDK를 써라”라고 하는데 팀의 지시 파일은 “레거시 호환을 위해 v2 SDK를 쓴다”라고 적혀 있다면, 어느 쪽이 이길까요? 모델은 둘 다 보고, 결과는 컨텍스트 순서와 표현의 강도, 그리고 모델이 학습한 내용에 따라 갈립니다. 예측 불가능하고 실행마다 뒤집힐 수 있습니다.

셋째는 리소스 경쟁입니다. 의미가 충돌하진 않지만 같은 행동을 두고 다투는 경우입니다. 두 MCP 서버가 모두 “프로젝트 설정”에서 호출되길 원하거나, 세 스킬이 모두 “배포”에 반응하는 식이죠. 모델은 셋 다 부르거나(토큰과 턴 낭비), 엉뚱한 걸 부르거나, 하나만 부르고 나머지도 처리됐다고 착각합니다.

‘일단 다 깔고 보자’가 지는 전략인 이유

확장들이 전혀 충돌하지 않더라도 비용은 발생합니다. 설치된 모든 확장은 컨텍스트 윈도우 공간을 차지하고, 모델이 평가해야 할 도구 호출 후보를 늘립니다. 이것이 구성 비용입니다. 쓰든 안 쓰든 그냥 거기 있다는 것만으로 드는 비용이죠.

다섯 개를 깔고 그중 하나에만 관련된 질문을 던져도, 모델은 어떤 걸 부를지 정하려고 다섯 개의 설명을 전부 읽어야 합니다. 나머지 네 개의 무관한 도구에 토큰과 처리 시간을 쓰는 겁니다. 때로는 설명이 그럴싸해 보인다는 이유로 관련도 없는 도구를 불러 턴 하나를 날리고, 남은 세션 내내 엉뚱한 내용을 컨텍스트에 끼워 넣기도 합니다. 마이크로소프트의 결론은 단호합니다. 모든 확장에는 한계 비용이 있고, 어느 선을 넘으면 누적 비용이 이득을 넘어섭니다.

그래서 글은 개별 확장의 효과가 아니라 ‘순(net) 리프트’를 보라고 말합니다. 전체 확장 묶음으로 얻은 결과에서 아무것도 안 깔았을 때의 결과를 뺀 값입니다. 확장 A가 단독으로 +15%, 확장 B가 +12%를 내더라도 함께 깔았을 때 +10%밖에 안 나온다면, 둘을 합치는 과정에서 가치를 잃고 있는 셈입니다. 기대했던 +27%와 실제 +10%의 격차, 그게 바로 구성 비용입니다.

측정할 수 없으면 관리할 수 없다

이 문제는 ‘느낌’으로는 잡히지 않습니다. 확장 하나하나는 분명 도움이 됐고, 그래서 계속 늘리게 됩니다. 정작 전체 묶음이 더 나빠지고 있다는 건 따로 측정하지 않으면 보이지 않습니다. 마이크로소프트가 제안하는 방식은 베이스라인(확장 0개)에서 시작해 하나씩 추가하며 매 단계 결과를 재고, 성능이 떨어지는 지점을 발견하면 확장을 하나씩 빼가며 원인이 특정 짝의 충돌인지 아니면 컨텍스트가 포화된 토큰 예산 문제인지 가려내는 것입니다. 둘은 해법이 다릅니다. 충돌은 확장이 ‘무엇을 말하는지’를 바꿔 고치고, 포화는 확장이 ‘무엇을 담는지’를 줄여 고칩니다.

내가 만든 확장이든 골라 쓰는 확장이든, 원문은 구성 비용을 줄이는 실용적인 방향도 제시합니다. 핵심만 추리면 다음과 같습니다.

• 린하게 유지하기: 붐비는 컨텍스트에서는 간결함이 이깁니다. 잘려 나가는 상세한 설명보다 다 들어가는 짧고 정확한 설명이 낫습니다.
• 구체적인 어휘 쓰기: “인증 설정 관리” 같은 일반적인 말 대신 제품명과 고유 용어를 넣어 다른 도구와 구별될 신호를 줍니다.
• 현실적인 환경에서 테스트하기: 깨끗한 방이 아니라 실제로 함께 쓰는 확장들을 모두 켜둔 상태에서 효과를 확인합니다.

각 항목의 구체적인 적용 방법과 측정 절차는 원문에 자세히 담겨 있습니다.

결국 이 글이 에이전트를 직접 쓰는 사람에게 주는 통찰은, 도구를 늘리는 것과 에이전트가 똑똑해지는 것이 같지 않다는 점입니다. 컨텍스트 윈도우는 공유된 유한 자원이고, 그 안에서 확장들은 모델의 주의를 두고 경쟁합니다. 무엇을 깔지보다 무엇을 빼고 어떻게 다듬을지가 더 중요한 질문이 되는 셈입니다.