에이전트를 하나 띄웠을 땐 괜찮다. 두 개도 버틸 만하다. 그런데 다섯 개쯤 되면 뭔가 이상해진다. 같은 파일을 두 에이전트가 동시에 수정하고, 누군가 이미 끝낸 태스크를 다른 에이전트가 다시 집어 들고, 결과물이 서로를 덮어쓴다. 이게 조정세(Coordination Tax)다. 에이전트 수가 늘어날수록 이 비용은 선형이 아니라 지수적으로 커진다.
개발자 커뮤니티 dev.to에 올라온 사례가 이 문제를 구체적으로 보여준다. Mac Mini 한 대에서 9개 에이전트를 돌려 프로덕트를 공동 개발하는 팀이 겪은 현실이다. Claude Code, Codex, Cursor—각각은 뛰어나다. 문제는 이들이 서로를 인식하지 못한다는 점이다. 공유 상태가 없고, 태스크 보드도 없고, 'Agent A가 auth 모듈을 이미 작업 중'이라는 사실을 Agent B는 알 방법이 없다.
이 팀이 직접 만든 오픈소스 조율 서버 reflectt-node가 보여주는 해법은 단순하다. HTTP 엔드포인트로 태스크 소유권을 잠그는 뮤텍스, 누가 활성 상태인지 확인하는 프레즌스 API, 에이전트끼리 사람을 거치지 않고 대화하는 팀 채널—이 세 가지다. npx reflectt-node 한 줄로 로컬에서 실행되고, 에이전트 트래픽은 클라우드로 나가지 않는다. 결과는 하루 15개 이상 PR 머지, 인간 커밋 제로. 조율 레이어가 없을 때와의 차이가 여기서 극명하게 갈린다.
구글이 이 시점에 공개한 워크스페이스 CLI(gws)는 조율 문제의 다른 축을 건드린다. Gmail·Docs·Sheets·Calendar·Drive를 단일 명령줄 인터페이스로 묶고, "사람과 AI 에이전트 모두를 위해 설계됐다"는 점을 전면에 내세운다. AI Times 보도에 따르면, 기존에는 서비스마다 별도 API 인증과 호출 코드가 필요했지만, gws는 구글의 Discovery Service를 동적으로 읽어 명령어 체계를 자동 생성한다. 100개 이상의 에이전트 스킬과 MCP 서버 모드가 포함돼 있어, Claude Desktop이나 VS Code 같은 MCP 호환 환경에서 워크스페이스 API를 직접 호출할 수 있다.
테크 리드 관점에서 gws의 진짜 의미는 공통 제어 인터페이스다. 개발자가 터미널에서 치는 명령과 에이전트가 실행하는 명령이 동일한 체계를 공유한다. 모든 응답이 구조화된 JSON으로 나오니 에이전트가 결과를 파싱해 후속 작업으로 넘기기 쉽다. --dry-run 옵션으로 실제 API 요청을 미리 확인할 수 있고, Model Armor 옵션으로 프롬프트 인젝션 공격도 방어한다. 다만 아직 공식 Google 제품이 아닌 실험적 프로젝트다. 지금 당장 프로덕션 파이프라인에 꽂기보단, 테스트 환경에서 자동화 시나리오를 검증하는 용도가 현실적이다.
그렇다면 이 흐름에서 개발자의 연봉은 어떻게 될까. dev.to에 올라온 기술 분석은 '대체' 내러티브에 정면으로 반박한다. 핵심 논지는 간단하다—코드 생성은 시스템 설계가 아니다. 프로덕션 시스템은 예측 불가한 트래픽 급증, 의존성 장애, 보안 위협, 규제 요건을 동시에 처리해야 한다. LLM은 패턴을 생성하지만, 그 설계의 운영 결과에 책임지지 않는다. 역사적으로 고수준 언어, 프레임워크, 클라우드 인프라가 등장할 때마다 엔지니어는 사라지지 않고 더 복잡한 문제로 올라갔다. AI는 그 다음 단계일 뿐이다.
실질적인 변화는 기술 분포의 양극화다. 단순 CRUD 구현처럼 AI가 빠르게 대체할 수 있는 작업의 희소성은 줄어든다. 반면 분산 시스템 설계, 멀티 에이전트 조율 인프라, AI 생성물 검증—이 영역의 가치는 오른다. 시니어 엔지니어는 AI로 루틴 작업을 가속하면서 남은 시간을 아키텍처 결정에 쓴다. 단위 시간당 산출 가치가 올라가면 보상 압력도 올라간다.
세 가지 소식을 하나의 맥락으로 묶으면 테크 리드가 지금 해야 할 일이 보인다. 첫째, 멀티 에이전트를 띄우기 전에 조율 레이어를 먼저 설계하라. reflectt-node 같은 경량 조율 서버든, 자체 태스크 큐든, 공유 상태 없이 에이전트를 늘리는 건 혼란을 늘리는 일이다. 둘째, gws 같은 통합 CLI를 파이프라인 실험 대상으로 올려두라. 아직 프로덕션급은 아니지만, 에이전트가 워크스페이스 데이터를 직접 다루는 시나리오를 지금 설계해두지 않으면 나중에 따라잡기 빠듯하다. 셋째, 팀원의 역할 재정의를 미루지 마라. 조율 인프라를 설계하고, AI 생성물을 검증하고, 에이전트 간 충돌을 디버깅하는 역할—이게 AI 시대 시니어 엔지니어의 실제 업무가 되고 있다.
조정세는 피할 수 없다. 하지만 설계로 줄일 수 있다. 에이전트가 늘어나는 속도보다 조율 인프라를 먼저 갖추는 팀이 ROI를 실제로 증명할 수 있다.