개발자가 AI 오케스트레이터로 변화한다는 말은 이제 새롭지 않다. dev.to에 올라온 'Why Every Developer Will Become an AI Orchestrator'는 이 흐름을 역사적 맥락으로 잘 정리한다. 머신 코드에서 어셈블리, 고수준 언어, 프레임워크, 클라우드, DevOps—매번 추상화 계층이 올라갈 때마다 개발자는 사라지지 않고 그 위로 올라갔다. AI도 같은 패턴이다. 다만 이번 추상화 계층은 '생각할 수 있다'는 점이 다르다.
문제는 역할 재정의 담론이 실제 설계 기준으로 이어지지 않는다는 데 있다. "개발자는 이제 테크 리드처럼 일해야 한다"는 선언은 맞지만, 그 선언만으로 팀이 내일 당장 바꿀 수 있는 건 없다. 오케스트레이터로 전환하려면 구체적으로 세 가지를 설계해야 한다. 에이전트에게 무엇을 가르칠 것인가, 어떤 도구 접근 권한을 줄 것인가, 그리고 비용을 어떻게 제어할 것인가.
첫 번째 설계 기준: 에이전트에게 도메인 지식을 주입하라
범용 AI 에이전트는 코드를 생성하고 파일을 설명하고 보일러플레이트를 뽑아낸다. 하지만 특정 플랫폼이나 내부 시스템에 투입하는 순간, 컨벤션을 무시하고 런타임 규칙을 틀리게 적용하며 틀린 답을 자신 있게 내놓는다. dev.to의 'Teaching AI Coding Agents How to Build Workflows with Skills and MCP'가 제안하는 Skills+MCP 패턴은 이 문제를 정면으로 건드린다.
Skill은 재사용 가능한 지식 패키지다. 에이전트가 워크플로우 YAML을 어떻게 구성해야 하는지, 어떤 블록이 사용 가능한지, 유효성 검증 규칙이 무엇인지를 매번 프롬프트로 설명하는 대신 한 번 정의해두면 된다. 핵심은 "에이전트가 어떻게 작동해야 하는가"를 사전에 구조화하는 것이다. 팀 리드 관점에서 이건 온보딩 문서를 AI가 읽을 수 있는 형식으로 변환하는 작업이다. 우리가 신입 개발자에게 코드 컨벤션과 도메인 용어를 가르치듯, 에이전트에게도 같은 작업이 필요하다.
두 번째 설계 기준: 시스템 접근 권한을 구조화하라
MCP(Model Context Protocol)는 에이전트에게 실행 중인 시스템에 대한 구조화된 접근을 제공한다. Skills가 "어떻게 작동해야 하는가"에 답한다면, MCP는 "실제 시스템과 어떻게 상호작용하는가"에 답한다. 에이전트가 로컬에서 파일만 생성하는 게 아니라, 실행 중인 애플리케이션의 액션을 검사하고, 워크플로우 정의를 검증하고, 실제 결과를 확인할 수 있게 된다.
이 두 레이어가 결합될 때 에이전트는 코드 생성기에서 시스템 인식 개발 파트너로 격상된다. 그리고 여기서 오케스트레이터의 역할이 명확해진다. 에이전트에게 그냥 프롬프트를 던지지 않고, 시스템을 가르치고 안전한 도구 접근 권한을 설계하는 것. 이건 단순히 "AI를 잘 쓰는 법"이 아니라 팀의 엔지니어링 인프라를 재설계하는 작업이다.
세 번째 설계 기준: 에이전트 비용은 직관과 반대로 작동한다
마지막이자 가장 반직관적인 기준은 비용 최적화다. Claude의 effort 레벨을 실측한 벤치마크 결과(dev.to, 'Effort Levels in Practice')는 팀 리드라면 반드시 알아야 할 데이터를 보여준다. 단순 분류 작업에서 max 레벨은 low 대비 토큰을 8배 소모하면서 정확도는 동일했다. 단일 코드 생성은 high에서 품질이 정점을 찍고 이후 추가 비용만 나간다.
그런데 멀티스텝 에이전트 작업에서는 완전히 다른 패턴이 나타났다. medium 레벨에서는 에이전트가 스텝마다 탐색을 덜 하고, 더 많은 턴을 소모하고, 막힌 길을 재탐색하며 결과적으로 총 토큰 비용이 더 높았다. xhigh에서는 초반 계획이 더 정밀해지면서 턴 수가 줄고 총 비용이 오히려 낮아졌다. "effort를 올리면 비용이 오른다"는 직관은 단일 호출에서만 맞다. 피드백 루프가 있는 에이전트 작업에서는 틀린 직관이다.
실용적인 기준은 이렇다. 분류·라우팅·추출 같은 단순 작업은 low. 단일 코드 생성은 high. 멀티스텝 에이전트 루프는 xhigh. 오답이 토큰 비용보다 비싼 극단적 케이스만 max. 이 테이블을 팀 표준으로 만들어두지 않으면, 에이전트는 빠른 청구서 생성기가 된다.
오케스트레이터의 실제 역할은 판단 설계다
세 가지 기준을 관통하는 공통점이 있다. 에이전트 자체가 아니라 에이전트가 작동하는 구조를 설계하는 것이다. AI는 잘못된 아키텍처를 만들고, 요구사항을 오해하고, 보안 취약점을 자신 있게 심을 수 있다. 다섯 개 에이전트에게 코드베이스 접근 권한을 주는 것과 좋은 엔지니어링 팀을 만드는 것은 전혀 다른 일이다.
특히 주니어 개발자에게 이 전환은 위험하다. AI가 이해하지 못한 코드를 생성해주면, 개발자는 빨라지는 게 아니라 기술 부채를 더 빠르게 쌓는 것이다. 오케스트레이터로 전환한다는 건 코드를 덜 쓰는 게 아니라, "이 아키텍처가 왜 선택됐는가