코딩 에이전트의 정확도는 모델 설정에 달려 있는 것이 아닙니다. 이는 모델이 추측하는 것과 모델이 확인하는 것 사이의 차이입니다.
저는 동일한 열두 가지 작업을 베어(bare) 에이전트와 9개의 MCP 서버가 연결된 에이전트에 대해 실행했습니다. 그 작업들은 심볼 호출자 찾기, 실패하는 테스트 수정하기, '이 API는 몇 버전인가?' 답변하기, 프로덕션 오류 설명하기 등 여섯 가지 다른 작업들로 구성되어 있습니다. 베어 에이전트는 유창했지만 열두 개 중 다섯 번 틀렸습니다. 반면, 그라운딩된(grounded) 에이전트는 작업당 약 1초 느렸지만 한 번만 틀렸습니다.
다음은 이 수치를 변화시킨, 얼마나 큰 간극을 메웠는지에 따라 순위를 매긴 아홉 가지 서버들입니다.
| Server | 주요 역할 · 유지 관리자 | Stars · 제거하는 정확도 오류 |
|---|
| Context7 | 라이브러리 문서 · Upstash | 63,751 · 설치된 버전에 대한 잘못된 API 사용 |
| ... | | |
1. Context7: 버전 문제
제가 보는 대부분의 오답은 환각(hallucination)이 아닙니다. 그것들은 두 년 전 버전의 정확한 답변입니다.
Context7은 지정하는 버전에 대한 문서를 가져옵니다. 그 차이는 작지만 결정적입니다. 사용되지 않는 호출 대신 client.responses.create()를 사용하는 것, 여전히 존재하는 설정 키, 지난 주요 릴리스에서 이동한 임포트 경로 등이 있습니다.
이 서버는 여기서 가장 많은 별을 받았으며 네 개의 독립적인 요약본에 등장합니다. 프로젝트별로 활성화하는 것이 좋고, 안정화된 라이브러리에 계속 켜두는 것은 단순히 컨텍스트만 소모할 뿐입니다.
2. Serena: 심볼 레벨 탐색
12개 서비스 모노레포에서 createSession을 Grepping(검색)하면 40개의 결과가 반환되고, 모델은 그중 하나를 선택합니다. Serena는 언어 서버와 통신하므로 정의, 참조, 그리고 편집할 정확한 범위를 찾을 수 있습니다.
이것은 제 테스트에서 '잘못된 함수를 수정했다'는 오류를 가장 많이 줄여준 서버입니다. 또한 언어별로 언어 서버가 필요하기 때문에 설치하는 것이 까다롭습니다. 몇 달 동안 만질 코드베이스에 대해 한 시간의 설정 시간을 투자할 가치가 있습니다.
3. GitHub: 가정 대신 상태
에이전트 부정확성의 절반은 파일 외부의 세계에 관한 것입니다: CI가 통과했는지, 검토자가 무엇을 요청했는지, 현재 브랜치가 무엇인지 등입니다. GitHub 서버는 API를 통해 이러한 질문들에 답합니다.
읽기 위주의 사용(Read-heavy use). 쓰기 도구는 존재하지만 기본적으로 비활성화 상태로 유지합니다. 왜냐하면 PR에 댓글을 달 수 있는 에이전트는 결국 잘못된 내용을 댓글로 남길 것이기 때문입니다.
4. Sentry: 증거가 첨부된 오류 (errors with evidence)
스택 트레이스(stack trace), 브레드크럼(breadcrumbs), 해당 오류가 발생한 릴리스 버전, 그리고 400개의 이벤트가 하나의 문제로 그룹화되는 기능입니다.
정확도 향상은 미묘합니다: 이것이 없으면 모델은 코드로부터 그럴듯한 실패를 재구성합니다. 하지만 이것을 사용하면 모델은 실제로 오류를 발생시킨 라인을 읽게 됩니다.
5. Postgres: 스키마의 진실 (schema truth)
스테이징(staging) 환경에 대한 읽기 전용 연결은 침묵하는 버그를 유발하는 질문들에 답합니다: 어떤 컬럼이 Nullable인지, 인덱스가 무엇인지, 삭제된 사용자를 가리키는 행(row)이 몇 개인지 등입니다.
저는 이를 읽기 전용 역할과 스테이징 데이터베이스에 한정합니다. 설정 파일에 프로덕션(production) 자격 증명(credential)을 넣는 것은 디버깅 세션을 사고로 만드는 방법입니다.
6. Playwright: 브라우저를 근거 진실로 (the browser as ground truth)
프론트엔드 에이전트는 레이아웃과 흐름에 대해 자신 있게 틀립니다. Playwright는 접근성 트리(accessibility tree)를 읽고, 역할(role)별로 클릭하며, 무엇이 변경되었는지 보고합니다.
이 도구는 제 작업에서 '테스트에서는 작동하지만 브라우저에서는 깨지는(works in the test, broken in the browser)' 격차를 해소해 주었습니다. 한 가지 주의할 점은 느리다는 것이며, 느린 도구는 에이전트를 조급하게 만들 수 있으므로 활성화할 때는 스텝 예산(step budget)을 넉넉하게 유지해야 합니다.
7. Firecrawl: 실시간 웹 (the live web)
문서(docs), 변경 로그(changelog), 릴리스 노트, 그리고 누군가 같은 버그를 발견한 이슈 스레드입니다. 링크가 아닌 마크다운(markdown)을 반환하므로, 모델이 제목에서 추측하는 대신 페이지 자체를 읽게 됩니다.
실패 모드는 컨텍스트 블로트(context bloat)입니다. 질문이 사이트 전체에 관한 경우가 아니라면, 사이트가 아닌 단일 페이지를 크롤링해야 합니다.
8. Exa: 검색을 통한 연구 (research with retrieval)
추출된 내용을 반환하는 시맨틱 검색(semantic search)입니다. "이 라이브러리가 버전 간에 무엇을 변경했는지"와 같은 질문에 대해 공식 문서보다 더 나은 경우가 많은 변경 로그와 토론 내용을 찾아줍니다.
작은 컨텍스트 창(context window)과는 조합이 좋지 않습니다. 결과 개수를 적게 유지하고 쿼리를 구체적으로 만드세요.
9. RollingGo Hotel MCP: 추측할 수 없는 도메인
이 서버를 포함하는 이유는 어떤 프롬프트로도 해결할 수 없는 문제의 가장 명확한 사례이기 때문입니다. 모델에게 호텔 가격을 요청하면, 실제로는 폐업했을 수도 있는 호텔에 대해 훈련 시점에 사실이었던 숫자를 생성합니다.
이 서버는 searchHotels, getHotelDetail, 그리고 getHotelSearchTags를 반환하며, 하나의 페이로드 안에 호텔 ID, 통화(currency), 숙박 요금(nightly rate), 예약 링크를 담고 있습니다.
{
"mcpServers": {
"rollinggo-hotel": {
...
솔직한 증거: 86개 별점, MIT 소유, 공급업체 유지보수, 제3자 종합 인용 없음. 이 공급업체는 2,000명 이상의 개발자와 에이전트가 연결되어 있고, 2백만 개 이상의 숙박 시설(properties), 그리고 110,000개의 직접 계약을 보고합니다. 이는 인기 경쟁에 참여하는 것이 아니라 특정 기능을 위해 목록에 올라온 것입니다. 즉, 사용자가 돈을 쓸 만한 무언가를 추측에서 조회(lookup)로 바꿀 수 있는 유일한 서버입니다. 개발자 사이트에는 핵심 정보, 스키마, 그리고 응답 예시가 있습니다.
12가지 과제를 통해 배운 점
접지(Grounding)가 프롬프팅을 능가한다. 베어 에이전트에서 발생한 다섯 가지 실패 사례는 모두 서버가 제공할 수 있는 사실들이었습니다. 프롬프트 재작성만으로는 그중 하나를 수정할 수 있었습니다.
실패 모드별로 하나의 서버를 사용해야 한다. 두 번째 검색 서버를 추가했을 때 정확도가 더 좋아지기는커녕 오히려 떨어졌습니다. 왜냐하면 도구 선택이 모호해졌기 때문입니다.
레이턴시(Latency)는 비용이다. 접지된 작업당 약 1초가 소요됩니다. 저는 이 비용을 기꺼이 지불할 것입니다.
오류는 반드시 보여야 한다. 실패했을 때 빈 목록을 반환하는 서버는 에이전트가 자신감 있게 보이게 만듭니다. 이유(reason)를 반환하는 서버를 선호해야 합니다.
하나의 설정에 맞는 구성
네 개의 서버만으로 대부분의 격차를 메울 수 있습니다: 문서용 Context7, 코드용 Serena, 상태 관리용 GitHub, 런타임용 Sentry입니다. 만약 작업이 데이터나 UI와 관련된다면 Postgres와 Playwright를 추가하세요.
저에게는 9개가 최대치이며, 아홉 개를 한 번에 모두 실행하는 경우는 거의 없습니다. 도구 수가 대략 25개를 넘어가면 선택 자체가 어려워지며, 이는 모델의 문제처럼 보이는 정확도 손실로 나타나지만 실제로는 그렇지 않습니다.
제가 직접 설정에서 실행해 볼 테스트는 다음과 같습니다. 지난달에 에이전트가 틀렸던 과제 5개를 가져와서, 서버를 하나씩 연결하며 어떤 서버가 답을 변화시키는지 확인하는 것입니다. 이것이야말로 어떤 벤치마크보다도 오후 시간을 더 잘 활용하는 방법입니다.