도구 선택이 곧 팀의 기술 전략이다
"어떤 AI 코딩 에이전트 써요?"라는 질문에 "요즘 다들 Claude Code 쓰던데요"라고 답하는 팀이 아직도 많다. 벤치마크도 없고, 비용 시뮬레이션도 없고, 우리 코드베이스에서 실제로 돌려본 적도 없이. 도구 선택을 바이브로 하는 순간, 그 결과도 바이브로 나온다.
2026년 중반 기준으로 AI 코딩 에이전트 시장은 세 가지 축에서 동시에 움직이고 있다. 첫째, 오픈소스 에이전트의 부상으로 "특정 모델에 락인되지 않을 자유"가 현실적인 선택지가 됐다. 둘째, MCP(Model Context Protocol) 생태계가 성숙하면서 에이전트에 외부 도구를 붙이는 비용과 편익 계산이 복잡해졌다. 셋째, "어떤 모델이 제일 잘해?"라는 질문 자체가 잘못됐다는 인식이 퍼지면서 자체 벤치마크 방법론이 등장했다. 이 세 가지를 함께 이해해야 팀에 맞는 도구를 고를 수 있다.
첫 번째 축: 도구의 철학을 먼저 따져라
dev.to에 소개된 OpenCode 사례는 도구 철학이 얼마나 중요한지를 단적으로 보여준다. OpenCode는 SST 팀이 Go로 만든 오픈소스 터미널 에이전트다. GitHub 스타 기준으로 Claude Code(12만 2천+)를 이미 넘어섰고(16만+), 75개 이상의 LLM 프로바이더를 지원하며 세션 도중 모델을 교체할 수 있다. 핵심 명제는 단순하다. "에이전트 하네스와 모델을 분리한다."
반면 Claude Code는 Anthropic 모델과 수직 통합된 관리형 제품이다. /goal 모드, Agent View, 즉시 되감기(double-Esc) 같은 자율 오케스트레이션 기능은 Claude Code가 앞서 있다. 통제된 벤치마크에서는 "Claude Code는 속도, OpenCode는 철저함"이라는 평가가 나왔다.
2026년 1월 Anthropic이 OAuth 정책을 변경해 Claude.ai 구독 계정으로는 서드파티 에이전트 접근을 막은 사건은 도구 철학 선택의 무게를 더 높였다. OpenCode를 쓰려면 별도 API 키가 필요하고, Claude Pro/Max 구독 크레딧은 사용 불가다. 이건 단순한 비용 문제가 아니라 "우리 팀이 특정 벤더의 로드맵에 얼마나 묶일 것인가"라는 전략 질문이다.
실용적 판단 기준은 이렇다. 컴플라이언스 요건으로 코드가 외부로 나가면 안 되는 팀, 비용 상한선을 직접 통제해야 하는 팀, 모델을 자주 교체해가며 최적을 찾고 싶은 팀이라면 OpenCode가 맞다. 반면 무거운 디버깅 세션이나 멀티 에이전트 오케스트레이션이 핵심인 팀이라면 Claude Code가 여전히 우위다. 양쪽을 병행 운용하는 팀도 많다는 점도 참고할 것.
두 번째 축: MCP 서버는 공짜가 아니다
MCP 생태계에 대한 가이드(dev.to, 2026)가 던지는 가장 중요한 경고는 설치 목록이 아니라 비용 구조다. MCP 서버를 하나 연결할 때마다 세션 시작 시점에 2,000~5,000토큰의 툴 스키마가 주입된다. 서버 세 개를 기본값으로 켜두면 첫 프롬프트를 입력하기도 전에 최대 1만 5천 토큰이 사라진다.
"Claude Code가 갑자기 느려졌어요" "컨텍스트를 일찍 잃어버려요"라는 증상의 상당수는 MCP 서버를 너무 많이 연결해둔 것이 원인이다. MCP는 편리하지만 공짜가 아니다.
그럼 어떤 MCP를 먼저 써야 할까. 여러 독립적인 가이드가 수렴하는 결론은 세 가지다. Context7(라이브 라이브러리 문서 조회—구버전 API 환각 방지), 공식 GitHub MCP(PR·이슈·CI 관리), Playwright MCP(프론트엔드 실제 렌더링 검증). 단순 저장소 조회라면 gh CLI가 MCP보다 토큰 비용이 훨씬 싸다는 점도 기억해야 한다.
2025년 12월 MCP 거버넌스가 Anthropic 단독에서 Linux Foundation 산하 Agentic AI Foundation으로 이관된 것도 주목할 변화다. Anthropic, OpenAI, Google, Microsoft, AWS가 보드에 참여한다. 실질적 함의는 하나다. Slack, GitHub처럼 벤더가 직접 유지보수하는 공식 MCP가 서드파티 통합보다 안정적이다. 팀 MCP 스택을 구성할 때 "공식인가 서드파티인가"를 필터로 쓰는 게 현명하다.
세 번째 축: 바이브 대신 재현 가능한 벤치마크를
"어떤 모델이 제일 잘해?"라는 질문이 왜 쓸모없는지를 dev.to의 한 기술 글이 명쾌하게 설명한다. 외부 벤치마크는 LeetCode 스타일 그린필드 태스크, 데모 TODO 앱, 내가 쓰지 않는 프레임워크로 측정한 결과다. 우리 코드베이스의 빌드 시스템, 아무도 건드리고 싶지 않은 레거시 모듈, 40분짜리 테스트 스위트는 그 어디에도 없다.
대안은 자체 Git 히스토리에서 태스크를 추출하는 것이다. 버그를 고쳤거나 소규모 기능을 추가한 커밋을 찾아 부모 커밋으로 체크아웃하고, 실제 수정 내용 없이 커밋 메시지만으로 모델에게 재현을 요청한다. 평가 축은 세 가지다. 정확성(테스트 통과 여부), 편집 국소성(수정해야 할 파일만 건드렸는가), 반복 비용(몇 라운드 만에 도달했는가).
이 방법론이 드러낸 실용적 인사이트가 있다. 패치 적용 실패가 테스트 실패보다 더 자주 발생한다. 멋진 설명을 생성하는 모델이 실제 파일 버전과 맞지 않는 컨텍스트 라인으로 diff를 만드는 경우가 많다. 또 편집 국소성은 리뷰 비용의 프록시다. 테스트를 통과하더라도 11개 파일을 건드린 모델은 2개 파일만 건드린 모델보다 팀 리뷰 부담이 크다. 그리고 가장 중요한 발견—같은 모델을 같은 태스크에 두 번 돌렸을 때의 편차가, 서로 다른 두 모델 간 편차보다 큰 경우가 있었다. 원샷 비교는 노이즈다. 최소 두 번 돌려라.
실행 가능한 도입 프레임워크
이 세 축을 종합하면 팀 도입 결정 흐름이 만들어진다.
1단계: 도구 철학 결정. 벤더 락인을 감수하고 수직 통합의 편의성을 취할 것인가(Claude Code), 모델 자유도와 비용 통제를 위해 구성 복잡성을 감수할 것인가(OpenCode). 컴플라이언스, 예산, 팀 숙련도를 기준으로 먼저 결정한다.
2단계: MCP 스택 최소화. 기본값으로 연결된 MCP 서버를 모두 끊고 필요한 것만 태스크 단위로 연결한다. Context7, 공식 GitHub MCP, Playwright 세 개가 실용적 시작점이다. 서버를 추가할 때마다 토큰 예산을 확인한다.
3단계: 자체 벤치마크 설계. 팀 Git 히스토리에서 태스크 8~10개를 추출하고, 정확성·편집 국소성·반복 비용 세 축으로 후보 모델을 비교한다. 벤치마크 엔드포인트는 설정값으로 관리해 분기마다 재실행 가능하도록 설계한다.
전망: 도구보다 평가 능력이 오래간다
"어떤 모델이 제일 잘해?"라는 질문에는 유통기한이 없다. 분기마다 새 모델이 나오고, 벤더 정책은 하루아침에 바뀐다. Anthropic의 OAuth 차단이 OpenCode 사용자들을 Gemini로 이주시킨 것처럼, 도구 시장은 예측 불가능하게 움직인다.
팀이 오래 쓸 수 있는 자산은 특정 도구 숙련도가 아니라 평가 방법론이다. 태스크 셋 한 번 만들고, 스코어러 지루하게 유지하고, 엔드포인트를 교체 가능하게 설계해두면—다음 모델이 나왔을 때 핫테이크 대신 점심 전에 답을 낼 수 있다. 그게 AI-First 팀이 도구 선택에서 유지해야 할 실질적 경쟁력이다.