청구서가 바꾼 것은 비용이 아니라 행동이었다
GitHub Copilot이 토큰 기반 종량제(AI Credits)로 전환한 지 한 달이 채 되지 않아, Reddit에는 스크린샷이 쏟아지기 시작했다. 에이전트 요청 몇 번, 코드 리뷰 한 사이클, 디버깅 세션 하나—그것만으로 월간 크레딧 상당 부분이 사라졌다는 제보들이다. dev.to의 한 개발자는 이를 두고 "코딩에 루트박스를 도입한 것"이라고 표현했다. 과장처럼 들리지만, 핵심을 정확히 찌른다. 예측 불가능한 비용 구조는 창의적 실험을 막는다. 프롬프트 하나를 날리기 전에 '이게 얼마짜리 질문인가'를 먼저 계산하게 만들기 때문이다.
아이러니: 모범 사례를 따를수록 비용이 올라간다
더 흥미로운 문제는 구조적 역설에 있다. 지난 2년간 AI 회사들은 개발자에게 '더 많은 컨텍스트를 제공하라', '에이전트가 깊이 추론하게 하라', '자율 워크플로우를 활용하라'고 가르쳤다. 그런데 토큰 기반 청구가 시작되자, 그 모범 사례들이 정확히 비용 폭탄의 원인이 되었다. 좋은 프롬프트일수록, 에이전트를 잘 활용할수록 크레딧이 빠르게 소진된다. 모범 사례를 따른 대가로 청구서를 받는 셈이다.
이탈은 이미 시작됐다
반응은 빠르게 나타나고 있다. 무거운 추론 작업은 ChatGPT나 Claude로, 복잡한 에이전트 워크플로우는 Cursor나 Cline으로 분산하고, Copilot은 IDE 자동완성 수준으로만 쓰는 패턴이 형성되고 있다. 아이러니하게도 GitHub이 수년간 공들여 만든 'AI가 개발 모든 단계에 임베딩된 경험'이, 스스로 도입한 비용 구조 때문에 해체되고 있다. 단일 도구 의존 전략이 청구서 한 장으로 흔들린 것이다.
진짜 질문은 '어느 도구'가 아니라 '어떻게 엮는가'이다
이 시점에서 솔로 개발자들의 AI 활용 사례는 시사하는 바가 크다. dev.to의 한 아티클은 10배 생산성의 핵심이 '어떤 도구를 쓰느냐'가 아니라 '워크플로우에 어떻게 통합하느냐'에 있다고 정리한다. 실제로 고레버리지 솔로 개발자의 AI 활용은 단계별로 역할이 명확하게 분리되어 있다. 아키텍처 의사결정 전에는 모델을 '압박 테스터'로 활용해 가정을 검증하고, 코드 생성 단계에서는 스캐폴딩과 보일러플레이트만 위임하며 핵심 로직은 직접 소유한다. 디버깅과 코드 리뷰에는 맥락이 풍부한 단발성 요청을 집중적으로 사용하고, 문서화는 AI 초안을 기반으로 사람이 최종 패스를 한다. 이 구조에서 각 도구는 비용-효과 최적점에서 작동한다.
MCP 서버가 보여주는 또 다른 설계 방향
흥미로운 대안 설계도 등장하고 있다. Adobe Commerce 개발자를 위한 adobe-commerce-docs-mcp 서버는 AI 어시스턴트가 공식 문서를 직접 인덱싱하고 검색하도록 연결한다. BM25 검색 랭킹, 동의어 확장, 로컬 캐싱을 조합해 불필요한 네트워크 왕복과 컨텍스트 낭비를 줄인다. 개발자가 브라우저로 왔다 갔다 하는 컨텍스트 스위칭 비용을 없애면서, 동시에 모델에 전달하는 토큰을 정밀하게 제어한다. 이 접근법의 핵심은 단순하다—AI가 '알아야 할 것'을 미리 설계하면, 토큰 소비와 응답 품질을 동시에 최적화할 수 있다.
시사점: 도구 설계를 외주 줄 수 없다
Copilot 종량제 전환이 가져온 가장 큰 변화는 비용이 아니다. 개발자가 AI 워크플로우를 직접 설계해야 한다는 압력이다. 정액제 시절에는 모든 것을 Copilot 하나에 넣어도 상관없었다. 이제는 작업 유형별로 최적 모델을 선택하고, 컨텍스트 크기를 의도적으로 조절하며, 어떤 단계에서 AI를 개입시킬지를 명시적으로 결정해야 한다. 이것은 추가 부담이기도 하지만, 동시에 프로덕트 사고를 가진 개발자에게는 경쟁 우위가 되는 지점이기도 하다. AI를 잘 쓰는 것이 아니라, AI 시스템을 설계하는 능력이 핵심 역량이 되는 시대가 시작됐다.
전망: 도구 다변화는 심화된다
앞으로 단일 AI 도구에 개발 워크플로우 전체를 맡기는 패턴은 빠르게 사라질 가능성이 높다. 대신 IDE 보조, 에이전트 추론, 문서 검색, 코드 리뷰 각각에 최적화된 도구를 조합하는 멀티-도구 아키텍처가 표준이 될 것이다. Copilot의 종량제 전환은 이 흐름을 가속했을 뿐, 방향 자체는 이미 정해져 있었다. 지금 필요한 것은 어느 도구가 더 싸냐는 비교가 아니다. 내 워크플로우의 어느 지점에 어떤 AI가 가장 높은 레버리지를 만드는지—그 설계도를 직접 그리는 것이다.