Code Agent의 한계를 MCP로 극복하기

Code Agent, 생각보다 한계가 많다

요즘 Code Agent가 대세다. Continue, Cline, Cursor 같은 도구들. IDE에 붙여놓으면 코드 자동완성, 리팩토링, 심지어 기능 구현까지 해준다.

근데 써보면 안다. 대규모 프로젝트에서는 무력하다.

5000라인짜리 레거시 파일? 분석 못 한다. 컨텍스트 윈도우가 터진다. 멀티 모듈 프로젝트? 전체 구조를 모른다. 파일 하나씩만 본다. 서비스 간 연계? 당연히 모른다. API 호출 관계 같은 건 꿈도 못 꾼다.

왜 이런 걸까?

근본적인 문제: 컨텍스트 윈도우

LLM의 컨텍스트 윈도우는 128K~200K 토큰 정도다. 많아 보이지만, 대규모 코드베이스 앞에서는 한없이 작다.

문제	영향
대용량 파일	5000라인 파일 하나만 읽어도 컨텍스트 절반 소진
프로젝트 구조	파일 단위로만 보니까 전체 아키텍처 파악 불가
의존성 분석	A가 B를 호출하고, B가 C를 호출하는데... 이걸 어떻게 알아
멀티 프로젝트	서비스 간 API/EAI/DB 연계? 그게 뭔데

Code Agent가 "이 함수 수정하면 어디 영향 가요?"라는 질문에 제대로 답하지 못하는 이유다.

해결책: MCP + 또 다른 LLM

MCP(Model Context Protocol)를 아는가? Anthropic이 만든 프로토콜인데, LLM이 외부 도구를 호출해서 데이터를 가져올 수 있게 해준다.

근데 여기서 한 발 더 나간다. MCP 뒤에 또 다른 LLM을 붙이는 거다.

핵심 아이디어:

원본 LLM은 필요한 내용만 MCP에 전달하고, MCP 뒤의 LLM이 자기 컨텍스트를 최대한 활용해서 정보를 추출한다.

두 LLM이 각자의 컨텍스트를 독립적으로, 효율적으로 사용하는 구조다.

컨텍스트 분리 원칙

이게 핵심이다.

구분	원본 LLM (Code Agent)	Query Resolver (MCP 뒤 LLM)
컨텍스트	사용자 대화, 현재 작업 맥락	프로젝트 인덱스, 코드 전체
MCP 호출 시	현재 질문 + 필요한 힌트만 전달	요청 의도 파악에 집중
역할	최종 답변 생성	정보 추출에 컨텍스트 최대 소비

원본 LLM이 MCP 호출할 때 이전 대화 컨텍스트를 다 보내지 않는다. 필요한 것만 보낸다.

MCP 뒤의 LLM은 그 요청을 받아서 자기 컨텍스트에 프로젝트 전체를 로드하고, 필요한 정보만 추려서 응답한다.

각자 자기 컨텍스트를 최대한 활용하는 구조.

왜 고성능 모델이 필요한가

처음에는 "압축용 소형 모델 붙이면 되지 않나?"라고 생각했다. 틀렸다.

요구사항	이유
요청 의도 파악	"이 함수 수정하면 어디 영향?"의 의도를 정확히 이해해야 함
코드 이해	대용량 코드를 읽고 관계를 파악해야 함
정보 선별	수많은 정보 중 진짜 필요한 것만 골라내야 함

소형 모델로는 요청 의도 파악이 부정확하다. "영향도 분석해줘"라고 했는데 엉뚱한 정보를 가져온다.

동등 수준의 고성능 모델이 필요하다. 1회성으로 자기 컨텍스트를 최대한 소비해서 정확한 정보를 추출해야 한다.

아키텍처

[Code Agent (원본 LLM)]
        │
        │ 필요한 내용만 전달
        │ (이전 컨텍스트 X)
        ▼
[Context MCP Server]
        │
┌───────┼───────┐
▼       ▼       ▼
[AST]  [Index] [Query Resolver]
               (동등 수준 LLM)
                    │
                    │ 자기 컨텍스트 최대 활용
                    │ 필요한 정보만 추출
                    ▼
              [정제된 응답]

Context MCP Server가 핵심이다:

프로젝트 등록 시 tree-sitter로 AST 파싱
의존성 그래프, 심볼 테이블 등을 인덱싱
요청이 오면 Query Resolver에게 전달
Query Resolver가 자기 컨텍스트로 분석해서 응답

실제 동작 예시

[원본 LLM 요청]
"AccountService의 transfer 메서드 수정하면 어디에 영향?"
    │
    ▼
[Context MCP Server]
    │ 요청 분석: 영향도 분석 필요
    ▼
[Query Resolver]
    │
    │ 1. 의존성 그래프 로드
    │ 2. AccountService 관련 코드 로드
    │ 3. transfer 메서드 호출처 탐색
    │ 4. 자기 컨텍스트 최대 활용
    ▼
[응답]
- 직접 호출처: PaymentController.processPayment()
- 간접 영향: BatchTransferJob, TransferApiController
- 관련 테스트: AccountServiceTest
- 연계 서비스: notification-service (이벤트 발행)

원본 LLM은 이 응답을 받아서 사용자에게 설명해주면 된다. 프로젝트 전체를 읽을 필요 없다.

압축이 아니라 정보 추출이다

처음에 "응답 압축"이라고 생각했는데, 그건 틀린 프레이밍이었다.

압축 (X)	정보 추출 (O)
원본을 줄이는 것	요청에 맞는 정보를 찾는 것
소형 모델로 가능	고성능 모델 필요
품질 손실 불가피	정확도가 핵심

Query Resolver는 "압축기"가 아니라 "정보 추출기"다. 요청 의도를 정확히 이해하고, 필요한 정보만 골라서 응답한다.

왜 이게 중요한가

Code Agent 시장이 커지고 있다. 근데 다들 같은 한계를 갖고 있다. 대규모 프로젝트에서 무력하다.

금융권 레거시 시스템? 수십만 라인이다. 이런 데서 Code Agent가 제대로 동작하려면 컨텍스트 문제를 해결해야 한다.

MCP + Query Resolver 구조가 그 해답이 될 수 있다.

원본 LLM: 사용자 대화에 집중
Query Resolver: 프로젝트 분석에 집중
각자 자기 컨텍스트를 최대 활용

아직 기획 단계

솔직히 말하면 아직 기획 단계다.

구현 계획:

단계	시기	내용
1단계	2월	Context MCP Server 기본 구조, AST 분석
2단계	3월	프로젝트 인덱싱, MCP 도구 구현
3단계	4월	Query Resolver 통합, LLM 연동
4단계	5월	멀티 프로젝트 지원
5단계	6월	통합 테스트, 최적화

회사 업무로 쓸 거라 우선순위가 높다. 진행되면 또 글 쓰겠다.

참고 자료

MCP 공식 스펙: modelcontextprotocol.io
Anthropic 블로그: Code execution with MCP
tree-sitter: tree-sitter.github.io