AI-First로 전환한다고 선언한 팀이 막상 ROI를 측정해보면 예상보다 낮은 경우가 많다. 이유를 파고들면 대부분 같은 패턴이 나온다. 에이전트는 돌아가는데 비용이 예상을 초과하거나, 툴체인이 느려서 AI가 코드를 생성해도 피드백 루프가 병목이 되는 것이다. 이 두 가지는 서로 다른 문제처럼 보이지만, 실은 같은 질문의 양면이다. AI-First 워크플로우에서 진짜 속도를 만드는 비용은 어디에 있는가.
핵심 이슈 ①: 에이전트 비용은 모델이 아니라 루프 설계에서 결정된다
dev.to에 올라온 Claude Code 멀티모델 루프 엔지니어링 가이드는 꽤 직설적인 주장으로 시작한다. "Opus를 모든 곳에 쓰는 걸 멈춰라." 처음엔 당연한 말처럼 들리지만, 실제로 팀을 보면 그렇게 하는 경우가 드물지 않다. 가장 비싼 모델을 쓰면 가장 좋은 결과가 나올 거라는 직관이 작동하기 때문이다.
하지만 에이전트 루프의 구조를 들여다보면 얘기가 달라진다. 하나의 루프 안에는 여러 종류의 노드가 존재한다. 계획을 세우는 단계, 파일을 읽고 기계적으로 수정하는 단계, 결과를 검증하는 단계, 루프를 멈출지 판단하는 단계. 이 중에서 진짜 '판단'이 필요한 노드는 전체의 10~20%에 불과하다. 나머지 80~90%는 빠르고 저렴한 모델로 충분히 처리된다.
해당 가이드는 두 개의 독립적인 다이얼로 이를 설명한다. 모델(Model) 은 능력의 문제고, 노력(Effort) 은 철저함의 문제다. Claude가 무언가를 틀렸을 때 진단 방향이 달라진다. 몰라서 틀렸다면 더 큰 모델로 교체해야 하고, 충분히 확인하지 않아서 틀렸다면 effort를 올려야 한다. 이 둘을 구분하지 않고 무조건 비싼 모델로 교체하는 팀은 비용만 올라가고 문제는 그대로다.
멀티모델 루프의 핵심 설계 원칙은 단순하다. 고비용 모델은 계획 수립, 난이도 높은 버그 분석, 루프 종료 여부를 결정하는 최종 판단에만 배치한다. 나머지 반복적이고 기계적인 실행 단계는 Haiku처럼 빠르고 저렴한 모델이 담당한다. 이 구조가 제대로 작동하면, 역설적으로 비싼 모델이 더 적게 쓰이면서도 결과 품질은 올라간다. 전체 반복 횟수가 줄기 때문이다.
현장에서 내일 당장 적용할 수 있는 체크리스트는 이렇다. 지금 팀이 돌리는 에이전트 루프에서 각 단계별로 어떤 모델이 붙어 있는지 목록을 만들어보라. 그 중 '기계적 실행'에 해당하는 단계에 고비용 모델이 붙어 있다면, 그게 바로 숨겨진 비용이다.
핵심 이슈 ②: TypeScript 7.0이 AI 코딩 어시스턴트의 체감 속도를 바꾼다
dev.to에 게재된 TypeScript 7.0 리뷰는 "이 릴리스는 기다림을 해결한다"는 문장으로 요약된다. Microsoft가 TypeScript 컴파일러를 Go로 재작성하면서 공개한 벤치마크는 꽤 충격적이다. VS Code 프로젝트 기준으로 빌드 시간이 125.7초에서 10.6초로 줄었다. 약 12배 빠르다. Sentry는 139.8초에서 15.7초, Playwright는 12.8초에서 1.47초다.
AI-First 관점에서 더 중요한 수치는 에디터 피드백 속도다. VS Code 저장소에서 오류가 있는 파일을 열었을 때 첫 번째 진단이 표시되기까지 기존에는 약 17.5초가 걸렸다. TypeScript 7에서는 1.3초 미만이다. Cursor나 GitHub Copilot 같은 AI 코딩 어시스턴트는 LSP를 기반으로 인텔리센스와 타입 추론 결과를 실시간으로 참조한다. 타입 체킹 응답이 느리면 AI 어시스턴트의 컨텍스트 품질도 떨어진다. TypeScript 7은 이 병목을 구조적으로 해소한다.
실제 도입 사례도 유의미하다. Slack은 CI에서 타입 체킹 시간을 7.5분에서 1.25분으로 단축했다. Canva는 에디터에서 첫 번째 오류를 보는 데 58초 걸리던 것이 4.8초가 됐다. 한 Microsoft 팀은 월간 CI 시간을 400시간 절감했다고 밝혔다. 이 숫자들은 단순한 빌드 속도 개선이 아니다. 개발자가 로컬에서 타입 오류를 확인하지 않고 CI에 밀어 넣는 습관을 만들던 근본 원인을 제거한 것이다.
주의할 점이 하나 있다. TypeScript 7.0은 아직 안정적인 프로그래매틱 API를 제공하지 않는다. 7.1에서 제공될 예정이다. Vue, Svelte, Astro, Volar, typescript-eslint 등 TypeScript API에 직접 의존하는 도구들은 당장 전환이 어렵다. Microsoft가 권장하는 방식은 TypeScript 6과 7을 병렬로 설치해서 가능한 곳부터 점진적으로 전환하는 것이다. 팀 전체에 한 번에 강제 업그레이드하는 건 권하지 않는다.
시사점: 두 비용은 같은 층위에서 설계해야 한다
에이전트 루프 비용과 툴체인 속도는 별개의 문제로 보이기 쉽다. 하지만 AI-First 워크플로우에서 이 둘은 같은 피드백 루프 안에 있다. 에이전트가 코드를 생성하고, 개발자가 그 결과를 타입 체커와 린터로 검증하고, 다시 에이전트에게 수정을 요청하는 사이클에서—타입 체킹이 17초짜리라면 에이전트의 속도가 아무리 빨라도 루프 전체가 느려진다.
반대로 생각하면, TypeScript 7로 LSP 응답 속도가 10배 빨라지면 AI 코딩 어시스턴트의 실질적 활용 품질도 올라간다. 타입 정보가 빠르게 반영될수록 AI가 제안하는 코드의 컨텍스트 정확도가 높아지기 때문이다. 이 두 가지를 별도 태스크로 분리해서 개선하는 것보다, AI-First 워크플로우 전체의 피드백 루프 관점에서 동시에 설계하는 게 맞다.
전망: AI ROI는 '어디에 쓰는가'의 설계 문제다
AI 도구 예산을 늘리는 것만으로는 ROI가 비례해서 올라가지 않는다는 걸 이제 많은 팀이 경험으로 알고 있다. 멀티모델 루프 엔지니어링이 보여주는 것은, 비용 최적화란 더 싼 도구를 쓰는 게 아니라 어떤 판단에 어떤 수준의 도구를 배치할 것인가를 설계하는 것임을 다시 확인시켜 준다. TypeScript 7.0이 보여주는 것은, 개발자가 매일 '기다림'에 쓰는 시간이 AI 생산성의 천장을 결정한다는 사실이다.
두 방향 모두 같은 결론을 향한다. AI-First 팀의 진짜 ROI는 모델 선택이나 툴 도입 하나로 결정되지 않는다. 루프 전체를 설계하고, 각 노드에 적합한 도구를 배치하고, 툴체인 속도가 병목이 되지 않도록 지속적으로 측정하는 팀이 가져가는 것이다. AI 도구는 계속 좋아지고 있다. 그 속도를 팀이 실제로 흡수할 수 있는 워크플로우를 설계하는 것—그게 지금 테크 리드가 해야 할 일이다.