6주 사이에 두 번의 회귀가 있었다. dev.to의 한 Flutter 개발자는 Claude Code CLI의 추론 수준이 무음으로 다운그레이드된 것을 뒤늦게 알아챘고, Opus 4.7이 출시된 직후에는 CLAUDE.md 파일 전체가 이전 버전 기준으로 튜닝되어 있었다는 사실을 실감했다. 그가 내린 결론은 단순하다. "한 AI 제품 레이어에 전체 워크플로우를 걸어두는 건, 그 레이어가 회귀하지 않는다는 데 베팅하는 것이다."
같은 시기, 또 다른 개발자는 Kiro·Cursor·GitHub Copilot 세 도구를 실제 Node.js 프로젝트에 투입해 워크플로우 관점에서 비교했다. 그의 관찰도 비슷한 지점을 건드린다. 세 도구는 기능 목록이 다른 게 아니라, 개발자가 생각하는 방식 자체를 다르게 설계한다. 코드를 빠르게 완성시켜주는 도구, 코드베이스 전체를 대화 맥락으로 끌어안는 도구, 코드를 쓰기 전에 스펙을 먼저 강제하는 도구—세 도구가 최적화하는 대상이 근본적으로 다르다.
도구별 역할을 잘못 이해하면 가장 먼저 무너지는 건 아키텍처다. GitHub Copilot은 속도를 최적화한다. 타이핑 흐름을 끊지 않고 보일러플레이트를 줄이는 데 탁월하지만, 프로젝트 구조 결정은 온전히 개발자 몫이다. Cursor는 맥락을 최적화한다. 코드베이스 전체를 AI와 대화하듯 다룰 수 있고, 멀티파일 리팩토링과 디버깅에서 실질적인 생산성이 나온다. Kiro는 의도를 최적화한다. 스펙을 먼저 정의하고 AI가 그 구조에 따라 구현을 생성하는 방식—코드 한 줄 쓰기 전에 시스템 설계가 확정된다. 같은 Node.js 프로젝트라도 Kiro를 쓴 쪽은 게임 로직이 자연스럽게 모듈로 분리됐고, Copilot을 쓴 쪽은 구조가 개발자의 의도에 전적으로 달려 있었다.
문제는 이 세 도구가 서로를 대체하지 않는다는 데 있다. 4-툴 Flutter 스택 경험담(dev.to)을 보면 역할 분리 원칙이 명확하다. 아키텍처 결정과 장기 세션은 Claude 원시 API, 일상적인 Dart 편집과 인라인 리팩토링은 Cursor, 설계가 확정된 이후 실행 단계는 Minimax, 낮은 위험도의 UI 이터레이션은 Gemini 무료 티어. 각 도구가 투입되는 단계가 명확히 구분된다. 특히 Claude Code CLI가 아닌 원시 API를 쓴 이유가 날카롭다—CLI 레이어에서 발생한 두 번의 회귀가 원시 API에는 영향을 주지 않았다.
테크 리드 관점에서 이 두 사례가 함께 가리키는 건 하나다. 도구 선택 문제가 아니라 레이어 설계 문제다. 단일 도구를 팀 전체가 모든 단계에 쓰는 구조는, 그 도구의 모델이 바뀌거나 제품 레이어가 회귀하는 순간 팀 전체의 산출물 품질이 동시에 흔들린다. 반면 도구별 역할을 명시적으로 구분해두면 한 레이어의 품질 저하가 다른 레이어로 전이되지 않는다. 이건 비용 최적화 전략이기도 하지만, 더 정확히는 리스크 격리 전략이다.
팀에 AI 도구를 롤아웃할 때 흔히 저지르는 실수가 여기서 나온다. "어떤 도구가 가장 좋냐"는 질문을 하는 순간 이미 방향이 틀렸다. 질문은 "각 단계에서 어떤 도구를 투입하고, 어떤 도구의 산출물을 다음 도구의 입력으로 넘길 것인가"여야 한다. Kiro가 스펙을 생성하면 Cursor가 그 맥락 안에서 편집하고, Claude가 아키텍처 결정을 내리면 비용이 낮은 실행 모델이 그 결정을 코드로 옮기는 구조—이게 멀티툴 스택의 실질적인 설계 방식이다.
앞으로 방향은 더 복잡해질 가능성이 높다. 도구들이 진화하면서 각자의 최적화 영역이 겹치기 시작할 것이고, 호스팅 LLM 제품의 모델 교체 주기는 빨라질 것이다. Kiro가 'spec-driven development의 세 번째 단계'를 표방하는 것처럼, 각 도구는 자신의 포지션을 더 뚜렷하게 가져갈 것이다. 그 변화 속에서 팀이 흔들리지 않으려면, 지금 당장 "우리 팀은 어떤 단계에 어떤 도구를 쓰는가"를 명문화해두는 것이 출발점이다. 도구가 바뀌어도 레이어 설계 원칙은 남는다.