Alibaba의 Qwen Code는 9월 17일 주간 릴리스에서 눈에 띄는 방향을 보여줬습니다. v0.23.3, v0.23.4, v0.24.0 세 릴리스에 267개 PR이 묶였는데, 그중 핵심은 기능 하나가 아니라 구조의 변화입니다.

Qwen Code 안에서 Claude Code와 Codex에게 하위 작업을 넘긴다.

코딩 에이전트가 다른 코딩 에이전트를 호출하기 시작했다는 뜻입니다. 이 글에서는 무엇이 바뀌었는지, 그리고 이 변화를 실무에서 어떻게 받아들여야 하는지 정리합니다.

서브에이전트 위임이 정확히 무엇인가요

대화창에서 이렇게 말하면 됩니다.

use the claude-code subagent to review this module

그러면 그 하위 작업이 로그인된 계정과 모델로 Claude Code 쪽에서 돕니다. 권한 관리와 결과 취합은 Qwen Code 세션이 맡고, 화면에는 여전히 하나의 대화 흐름으로 보입니다. Qwen Code가 일을 할당하고, 권한을 관리하고, 결과를 거둬옵니다. 두 서브에이전트 모두 기본은 foreground 실행입니다.

차이가 있다면 기본 권한입니다.

Codex — 기본 읽기 전용
코드를 읽고 의견을 준다.
파일을 만지려면 세션의 auto-edit·YOLO를 켜거나
서브에이전트 정의에서 쓰기 권한을 명시해야 한다.

Claude Code — 여러 라운드 주고받기 가능
작업 도중 몇 차례 왕복이 된다.
Codex는 한 작업을 주면 하나의 답이 돌아오는 형태다.

동작 환경은 macOS와 Linux에서 바로 되고, Windows에서는 WSL을 쓰는 안내가 붙습니다.

다른 에이전트를 붙이는 길도 열려 있습니다. .qwen/agents/ 아래 서브에이전트 정의 파일에 executor 블록을 적고 실행 명령을 쓰는 방식입니다. ACP를 말하는 외부 에이전트를 이 경로로 연결한다는 구상입니다. Claude Code 2.1.168 쪽 frontmatter 필드 호환도 정리되고 있는데, permissionMode, maxTurns, color, mcpServers, hooks 같은 필드를 같은 의미로 해석하려는 시도입니다.

활용 예시는 문서에 나온 그대로가 가장 분명합니다.

- 코드 리뷰나 수정된 계획을 Claude Code·Codex에 넘기기
- Codex에 저장소를 읽게 하고 읽기 전용으로 의견 받기
- 파일 변경 허용 여부는 그때그때 결정하기

예산 통제가 같이 왔다는 게 중요합니다

이번 릴리스가 단순한 연동 하나로 끝나지 않는 이유는 예산 통제 기능이 같이 묶였기 때문입니다.

- 워크플로우를 이름으로 호출
- 에이전트 작업에 token · round · time limit 설정
- goal turn 제한, 스케줄 작업의 모델·그룹 선택
- 웹 서치 호출 상한, 세션 간 메시징

메시지 뒤에 +500k 같은 토큰 상한을 적으면 실행 중인 플로우가 그 상한을 기준으로 일을 조율하고, 가까워지면 스스로 조입니다. 승인 대화상자에는 실행 전에 구조 미리보기가 뜹니다. 어디서 서브에이전트가 생기고, 어디서 병렬로 벌어지고, 어디서 왕복이 생기는지를 먼저 보여줍니다. 실제 실행이 예상보다 커지면 oversized-workflow 알림이 뜹니다.

에이전트에게 에이전트를 시키는 구조에서는 이 상한이 없으면 비용이 어디까지 불어날지 가늠이 안 됩니다. 위임 기능과 예산 기능이 같은 릴리스에 묶인 이유가 여기에 있습니다.

구조를 그림으로 그리면 이렇습니다

개발자 → 하나의 AI (예전)

개발자 → 오케스트레이터 (Qwen Code)
           ├→ Implementer (Claude Code, 여러 라운드)
           ├→ Reviewer (Codex, 기본 읽기 전용)
           └→ Test agent (빌드·테스트 실행)
           ↓ 결과 취합 + 권한 관리
         검증된 변경 (지금)

개발자 → 오케스트레이터 → 여러 전문 에이전트로 코딩 환경이 이동하고 있다는 신호로 읽히는 이유입니다. 모델 하나를 잘 프롬프팅하는 능력보다 task decomposition, agent delegation, budget control, verification이 중요한 engineering problem이 됩니다.

여기서 주의할 점도 있습니다. 외부 서브에이전트 경로를 쓸 때는 실제로 어떤 에이전트가 돌았는지 확인하는 습관이 필요합니다. 파일이 바뀌었다고 해서 원하는 에이전트가 돌았다는 증거는 되지 않습니다. 서브에이전트 메타데이터의 모델 표시, transcript의 도구 호출 기록, 어댑터 프로세스 같은 독립적인 흔적을 함께 보는 편이 안전합니다.

CodeBridge Mini Lab: 역할을 나눠서 비교해 보세요

복잡한 작업이 있다면 한 에이전트에게 전부 맡기지 말고 이렇게 나눠보세요.

Implementer — 코드를 고치는 역할
Reviewer — 읽기 전용으로 문제만 지적하는 역할
Test agent — 빌드와 테스트를 돌려 통과 여부만 말하는 역할

비교할 것은 품질만이 아닙니다.

결과 품질 + 총 비용 + 완료 시간 + 재시도 횟수

리뷰나 계획 수정을 외부 에이전트에 넘기는 것부터 시작하면, 오케스트레이션 비용이 얼마나 드는지 감이 옵니다. 이 감이 쌓이면 task decomposition, delegation, budget control, verification이 프롬프트 잘 쓰기보다 중요한 문제라는 말이 실감 나기 시작합니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

프롬프트를 넘어 하네스·루프·그래프 구조로 에이전트 시스템을 설계하는 연습이 필요하다면, 다섯 단계를 순서대로 쌓는 과정이 이 글의 오케스트레이터 이야기와 바로 이어집니다.