지금 테크 리드 앞에 놓인 진짜 결정
AI 코딩 도구 선택이 '취향 문제'이던 시절은 끝났다. Microsoft가 수십 명 엔지니어의 Claude Code 구독을 해지하고 GitHub Copilot으로 전환한다는 보도가 나왔고, Mustafa Suleyman은 공개 인터뷰에서 "Anthropic은 지나치게 비싸다"고 직격했다. 같은 시점에 GitHub Copilot은 사용량 기반 과금으로 전환해 개발자들에게 실질적인 비용 부담을 주기 시작했다. 한쪽은 비싸다고 욕하면서, 자기 제품도 비싸지고 있는 아이러니다. 어느 쪽을 믿든, 지금 이 압력은 팀 예산에 실제로 영향을 미친다.
프롬프트 50개 실험이 보여준 ROI의 실체
dev.to에 올라온 한 엔지니어의 실험이 흥미롭다. 50개의 Claude Code 커스텀 스킬(프롬프트)을 작성하고, 일주일 동안 애드혹 프롬프팅을 금지한 채 강제로 사용했다. 결과는 명확하게 갈렸다.
실제로 시간을 아낀 스킬은 7개였다. Code Review Assistant(~3시간), Bug Investigator(~2시간), Test Generator(~2시간)가 상위권이다. 나머지 상당수는 한 번도 손대지 않았다. 8개는 '이번 주엔 쓸 일이 없었다'는 결론이 났다.
이 실험에서 내가 주목하는 지점은 절약 시간 숫자가 아니다. ROI가 집중되는 작업 유형이 명확하다는 것이다. 코드 리뷰, 버그 조사, 의존성 감사처럼 '고판단력 분석 작업'에서 AI의 철저함이 속도를 이긴다. 반면 DB 마이그레이션, CI/CD 파이프라인처럼 컨텍스트가 깊게 필요한 작업은 커스텀 스킬만으로 커버가 안 됐다. 이 분류는 도구 선택보다 먼저 해야 할 작업 분류 기준을 팀에 요구한다.
멀티 에이전트 병렬 운영: 가능성과 현실 사이
도구를 하나로 고정하지 않아도 된다는 주장을 실제 제품으로 구현한 사례도 나왔다. Klaussy(v0.3.0)는 단일 데스크톱 앱에서 Claude Code, OpenAI Codex, Google Gemini, GitHub Copilot을 동시에 구동하는 멀티 에이전트 오케스트레이션 앱이다. 핵심 설계는 Provider Registry—에이전트별 차이(실행 명령어, 모델 선택 플래그, 세션 재개 방식, 출력 파싱 포맷)를 단일 모듈에 가두고, 나머지 워크플로우는 에이전트에 무관하게 동작하게 만든 것이다.
실용적으로 흥미로운 기능은 두 가지다. 첫째, 같은 태스크를 두 에이전트에 동시에 던져 결과를 비교할 수 있다. 어떤 에이전트가 특정 작업에 더 강한지 아직 확신이 없다면, 나란히 돌려보는 것이 가장 빠른 검증이다. 둘째, 작업 단위(git worktree)별로 에이전트를 다르게 지정할 수 있다. 비용 이유로 Copilot을 기본으로 쓰되, 복잡한 리팩토링은 Claude로 전환하는 식의 운영이 현실적으로 가능해진다.
단, 솔직한 한계도 있다. 인터랙티브 터미널 운영과 에이전트 전환은 4개 모두 작동하지만, PR 리뷰 자동화와 CI 실패 디버깅 같은 깊은 AI 기능은 Claude에서만 충분히 검증됐다고 개발자 스스로 밝힌다. 멀티 에이전트는 '지금 당장 풀 프로덕션 신뢰'가 아니라 '검증하며 확장하는 단계'다.
비용 경쟁이 가져오는 선택 압력
Microsoft의 움직임은 단순한 경쟁사 비판이 아니다. 가트너는 2025년 보고서에서 현재 AI 프로젝트의 상당수가 2027년까지 중단될 것으로 전망했다. ROI 입증 실패가 이유다. 'AI 도입 = 생산성 향상'이라는 자동 등식이 예산 심의에서 더 이상 통하지 않는다는 뜻이다.
이 맥락에서 MS의 Claude Code 구독 해지는 기술 판단이라기보다 비용 구조 재조정에 가깝다. 팀이 어떤 도구를 쓰느냐보다, 그 도구의 비용이 산출 가능한 가치와 연결되는지가 경영진의 판단 기준이 되고 있다. 테크 리드 입장에서 이건 불편한 신호다. 도구 선택이 기술 판단에서 재무 정당화 문제로 이동하고 있다.
팀 ROI 기준 선택 프레임
세 가지 흐름을 종합하면 실용적인 선택 기준이 나온다.
먼저 작업을 분류하라. 코드 리뷰, 버그 조사, 테스트 생성처럼 반복적이고 판단 강도가 높은 작업은 커스텀 프롬프트를 정교하게 만들면 ROI가 빠르게 나온다. 도구를 바꾸기 전에 현재 도구를 제대로 구성했는지를 먼저 점검해야 한다. 50개 프롬프트 실험에서 확인된 것처럼, 스킬은 기술이 아니라 습관 문제다.
단일 도구 몰빵의 리스크를 인식하라. MS 사례처럼 특정 벤더에 전체 팀을 고정하면 가격 정책 변화나 계약 조건에 취약해진다. 멀티 에이전트 오케스트레이션이 성숙해지는 지금, 워크플로우 레이어를 에이전트 종류와 분리해두는 설계가 리스크 헤지가 된다.
그러나 멀티 도구 분산의 비용도 계산하라. 에이전트마다 학습 곡선, 프롬프트 최적화, 출력 파싱 방식이 다르다. Klaussy가 솔직히 인정했듯, 멀티 에이전트의 깊은 통합은 아직 성숙 단계다. 팀 전체가 멀티 에이전트를 소화할 역량이 되기 전에 분산하면 복잡도만 늘어난다.
결론: 도구가 아니라 워크플로우 레이어를 설계하라
지금 AI 코딩 도구 시장은 비용 경쟁과 기능 확장이 동시에 진행 중이다. 도구 선택을 '어떤 게 더 좋은가'로 접근하면 6개월마다 결론이 바뀐다. 더 안정적인 접근은 작업 유형별 AI 활용 패턴을 정의하고, 특정 에이전트에 종속되지 않는 워크플로우 레이어를 먼저 설계하는 것이다.
내일 당장 팀에 적용할 수 있는 것부터 시작한다면: 이번 주 가장 반복되는 작업 3가지에 커스텀 프롬프트를 만들어 2주 동안 강제로 써봐라. 숫자가 나온다. 그 숫자가 도구 선택과 예산 정당화의 출발점이 된다.