지금 일어나고 있는 일
2026년 7월, OpenAI는 GPT-Live의 양방향 음성 제어(full-duplex voice control)를 데스크톱 ChatGPT와 Codex에 이식했다. 모바일 출시 2주 만이다. 같은 시기, Anthropic의 Claude Code는 회사 자체 코드베이스의 80% 이상을 Claude가 작성하는 수준에 도달했다고 밝혔다. PADO가 인용한 이코노미스트 분석에 따르면, Claude의 최신 모델은 인간 엔지니어가 하루 이상 걸리는 작업을 수행할 수 있는 단계에 진입했다. 그리고 dev.to에 올라온 OpenClaw 사례에서 한 개발자는 메인 에이전트가 서브에이전트를 스폰(spawn)해 병렬로 리서치·초안 작성·상태 보고를 처리하는 구조를 이미 운영 중이다.
세 흐름이 동시에 가리키는 방향은 하나다. 에이전트가 에이전트를 시키는 시대가 실험실 밖에서 작동하기 시작했다.
단일 에이전트의 천장
OpenClaw 사례가 먼저 짚은 문제는 구조적이다. 단일 에이전트에 모든 작업을 몰아주면 두 가지 한계가 동시에 온다. 첫째, 컨텍스트 윈도우가 빠르게 포화된다. 리서치·초안·이메일 전송을 하나의 세션에서 순차 처리하면, 중반부터 에이전트는 앞에서 무슨 결정을 했는지 '잊기' 시작한다. 둘째, 확증 편향이다. 이메일을 쓴 에이전트가 그 이메일을 뒷받침하는 리서치를 동시에 검토하면, LLM도 자기 결과물을 좋게 평가하는 경향이 생긴다.
OpenClaw의 해법은 격리(isolation)다. 서브에이전트는 메인 세션의 컨텍스트를 상속받지 않는다. 입력과 출력이 명확히 정의된 작업만 위임된다. 메인 에이전트는 오케스트레이터로 남아 위임·취합·판단을 담당한다. 밤 2시에 크론잡이 서브에이전트를 깨우고, 에이전트는 작업을 완료한 뒤 로그를 남기고 사라진다. 메인 세션은 그 결과만 받는다.
이 구조가 팀 워크플로우에서 의미하는 것
이 패턴은 코드 레벨 트릭이 아니다. 팀 구조의 은유다. 오케스트레이터 에이전트는 시니어 엔지니어나 테크 리드의 역할과 닮아 있다. 무엇을 위임할지, 어떤 기준으로 결과를 검토할지, 어디서 사람이 개입해야 할지를 판단한다. 서브에이전트는 명확한 인터페이스를 받아 실행하는 역할이다.
GPT-Live의 음성 인터페이스가 이 구조에 더해지면 무슨 일이 생기는가. VentureBeat 시연에서 개발자는 음성 명령만으로 새 스레드를 생성하고, PR을 만들고, 버그 원인을 추적했다. 이 장면의 진짜 의미는 '핸즈프리 코딩'이 아니다. 사람이 오케스트레이터 에이전트를 음성으로 조율하고, 그 에이전트가 다시 서브에이전트에 작업을 위임하는 3단 위임 구조가 일상 도구 수준에서 실현된다는 것이다.
Claude Code가 Anthropic 내부 코드의 80%를 쓰는 맥락도 같다. 코드 작성 자체가 에이전트에 위임됐다면, 인간 엔지니어가 실제로 하는 일은 무엇인가. 요구사항을 명세로 번역하고, 위임 범위를 정의하고, 결과를 검증하고, 에이전트가 판단할 수 없는 경계를 직접 결정하는 것이다.
그래서 개발자는 무엇을 설계해야 하나
실용적으로 정리하면 세 가지다.
첫째, 위임 가능한 작업과 그렇지 않은 작업을 분류하는 기준을 팀 안에 만들어야 한다. OpenClaw 사례가 도출한 원칙은 명확하다. 입력·출력이 명확하고, 메인 컨텍스트에 의존하지 않고, 인간 개입 없이 진행 가능한 작업이 위임 대상이다. 반대로 공유 컨텍스트가 필요하거나, 루프 중간에 사람의 판단이 필요한 작업은 위임하면 실패한다. 이 분류 기준 자체가 팀의 설계 산출물이 돼야 한다.
둘째, 결과 검증 구조를 에이전트 설계 초기에 포함해야 한다. OpenClaw 개발자가 서브에이전트마다 결과 로그를 data/subagent-results/에 남기도록 설계한 이유는 간단하다. 밤 2시에 실패가 조용히 사라지면 아침에 추적이 불가능하다. GPT-Live가 CI/CD 파이프라인과 코드 저장소에 직접 접근하는 시나리오에서도 마찬가지다. 권한 로그, 변경 이력, 감사 추적을 에이전트 아키텍처의 일부로 설계하지 않으면 사고는 트레이스 없이 발생한다.
셋째, 오케스트레이터 역할을 팀 안에 명시적으로 정의해야 한다. 에이전트가 에이전트를 시킬 수 있다면, 누가 최상위 오케스트레이터인가. 현재 가장 현실적인 답은 '사람'이다. 도메인 판단, 위임 설계, 예외 처리 결정은 아직 인간의 역할이다. 하지만 이 역할이 팀 구조에 명시되지 않으면, 에이전트 스택은 빠르게 늘어나는데 책임 소재는 흐려진다.
트레이드오프를 냉정하게 보자
낙관만 하면 안 된다. OpenClaw 사례가 솔직하게 인정한 비용이 있다. 서브에이전트를 스폰하고 결과를 기다리는 레이턴시는 단순 순차 처리보다 길다. 2분 이하 작업은 위임이 오히려 느리다. 병렬로 3개의 서브에이전트가 돌아가면 결과를 취합하는 로직이 필요하고, 그 로직도 설계 비용이다. 실패 모드도 곱셈으로 늘어난다.
GPT-Live의 음성 인터페이스에는 별도의 리스크가 있다. 소음, 음성 데이터 저장·전송 정책, 사내 보안 규정이 현실적 장벽이다. 금융·공공 도메인이라면 컴플라이언스 검토 없이 음성 에이전트가 저장소에 접근하는 구조는 지금 당장 도입할 수 없다. 파일럿 단위부터 시작해 권한 분리와 감사 로그를 먼저 갖추는 게 맞다.
Claude의 '순환적 자기개선(recursive self-improvement)' 가능성은 더 긴 시계에서 봐야 한다. PADO가 인용한 이코노미스트 분석은 여전히 인간 개입이 필요한 병목이 여러 군데 남아 있다고 짚는다. 지금 팀에서 내일 당장 써먹을 수 있는 이야기와, 3~5년 뒤의 시나리오를 구분해서 대응 우선순위를 잡아야 한다.
팀에게 남는 질문
Anthropicing이 Claude Code 출시 전 AI 작성 코드 비율이 '한 자릿수 초반'이었다고 밝혔을 때, 그건 도구의 문제가 아니었다. 위임 구조가 없었기 때문이다. 도구가 생기자 80%가 됐다. 이 숫자가 팀에게 던지는 질문은 '우리도 이렇게 할 수 있는가'가 아니다. '우리 팀의 20%—인간이 직접 해야 하는 부분—는 무엇인가'다.
에이전트가 에이전트를 시키는 구조가 팀에 들어오는 순간, 개발자의 핵심 역할은 위임 설계와 검증 판단으로 이동한다. 코드를 빠르게 쓰는 능력보다, 무엇을 에이전트에 맡기고 무엇을 직접 붙잡을지를 아는 능력이 더 희소해진다. 그리고 그 판단을 팀 전체가 공유하는 기준으로 만드는 것—그게 지금 테크 리드가 설계해야 할 진짜 아키텍처다.