2026: 에이전트 오케스트레이션의 해 — Zach Lloyd (Warp) 강연
출처: Coding Agents Conference at the Computer History Museum
강연일: 2026년 3월 3일
강연자: Zach Lloyd — Warp 창업자 & CEO
영상 링크: https://www.youtube.com/watch?v=eT1F2BAZJ64
목차
- 강연자 소개: Zach Lloyd는 누구인가
- 강연의 핵심 주장: 2026년은 에이전트 오케스트레이션의 해
- 패러다임의 전환: 손으로 쓰던 코드에서 프롬프트 기반 개발로
- 랩톱 중심 에이전트 워크플로의 한계
- 솔루션의 방향: 클라우드로의 이전과 오케스트레이션
- 에이전트 오케스트레이션의 주요 활용 사례
- 클라우드 에이전트를 직접 구축하려면 필요한 것들
- Warp의 해답: Oz 오케스트레이션 플랫폼
- 라이브 데모 상세 분석
- 질의응답: GitHub Copilot Agents와의 비교
- 강연의 의미와 시대적 맥락
- Warp와 Oz에 대한 최신 정보 (2026년 2월 기준)
1. 강연자 소개: Zach Lloyd는 누구인가
Zach Lloyd는 단순한 스타트업 CEO가 아니라, 20년이 넘는 실전 엔지니어링 경력을 가진 기술인이다. 그의 이력을 살펴보면 왜 그가 개발자 도구 분야에서 특별한 통찰력을 갖고 있는지가 명확히 드러난다.
그는 Stanford 대학교에서 Symbolic Systems(기호 시스템, AI와 인지과학의 교차점에 있는 학문) 학사 학위를 받았으며, 이후 London School of Economics and Political Science(LSE)에서 과학철학 석사 학위를 취득했다. 흥미롭게도 Yale Law School에서 법학 공부를 시작했지만, 법이 자신의 길이 아님을 깨닫고 중퇴한 뒤 다시 기술 분야로 돌아왔다. 이 다양한 학문적 배경은 기술적 사고와 인문학적 사고를 결합하는 그의 특성에 잘 드러난다.
커리어 측면에서는 NASA에서 경력을 시작했고, 이후 구글에 합류해 7년 이상 Principal Engineer로 재직하면서 Google Sheets 팀 전체를 이끌었다. 그는 Google Sheets를 오프라인 지원이 가능하고 더 빠르며 기능이 풍부한 애플리케이션으로 전면 재작성하는 대형 프로젝트를 주도하면서 사용량을 40배 이상 성장시켰다. 이후 Google Docs Suite 전체의 기술 책임자로서 Docs, Sheets, Slides 세 편집기를 아우르는 100명 이상의 엔지니어링 팀을 이끌었으며, 이 과정에서 10여 건의 특허를 보유하게 되었다.
구글을 떠난 뒤에는 SelfMade라는 스타트업을 공동 창업해 CTO를 역임했고, TIME 매거진에서 임시 CTO로도 활동했다. 그리고 2020년, Warp를 창업했다. 강연 당시 Warp는 Sequoia Capital, GV, Sam Altman, Dylan Field(Figma 창업자), Marc Benioff(Salesforce 창업자) 등 실리콘밸리 최고의 투자자들로부터 7,000만 달러 이상의 투자를 받은 회사로, 70만 명 이상의 개발자가 사용하고 있었다.
2. 강연의 핵심 주장: 2026년은 에이전트 오케스트레이션의 해
Zach Lloyd의 강연은 하나의 대담한 예언으로 시작된다. “2026년은 에이전트 오케스트레이션의 해가 될 것이다.” 그런데 이 주장은 단순한 마케팅 문구가 아니라, 그가 직접 경험하고 있는 현실의 반영이다.
그는 이 예언을 뒷받침하기 위해 먼저 자신의 개인적인 경험에서 출발한다. Warp의 코드베이스는 수백만 줄의 Rust 코드로 구성되어 있다. 그 코드베이스를 자신의 랩톱에 4~5개씩 체크아웃해두고, 각각에서 에이전트를 동시에 실행하는 방식으로 일하고 있다는 것이다. 더 나아가 청중에게 “이런 경험을 하고 있는 분 손들어 보세요”라고 물었을 때, 서서히 손이 올라오기 시작했다. 이 작은 순간이 강연의 방향을 잡아준다. 아직은 소수지만 빠르게 확산되고 있는 트렌드임을 방증하는 것이다.
Zach는 2025년을 “인터랙티브 에이전트의 해”로 규정한다. 즉, 사람이 직접 에이전트와 대화하면서 코드를 짜던 방식이 2025년에 주류가 되었다는 것이다. 그리고 2026년에는 이 에이전트들이 클라우드에서 팀 단위로 조율되며 실행되는 “오케스트레이션 시대”로 진화할 것이라고 선언한다.
3. 패러다임의 전환: 손으로 쓰던 코드에서 프롬프트 기반 개발로
Zach Lloyd는 소프트웨어 개발 방식에 일어나고 있는 역사적 전환을 개인적 고백 형식으로 풀어낸다. 그는 20년 이상 매일 코드를 직접 타이핑하면서 살아왔던 사람이다. 아침마다 사무실에 출근해 코드 에디터를 열고 손으로 코드를 입력하는 것이 그의 일상이었다.
그런데 2025년 어느 시점부터 그의 일하는 방식이 완전히 바뀌었다. 더 이상 코드를 손으로 쓰지 않는다. 지난 6개월 동안 단 한 줄의 코드도 직접 작성하지 않았음에도 Warp의 소프트웨어를 계속 출시하고 있다. 대신 그는 프롬프트를 작성하고, 에이전트가 그것을 수행한다.
이 전환의 의미는 단순히 “AI 보조 도구를 쓰게 됐다”는 수준이 아니다. 개발자의 역할 자체가 바뀌고 있다는 것이다. 이전에는 개발자가 곧 코드 작성자였다. 앞으로는 개발자가 에이전트 함대의 오케스트레이터, 즉 지휘자가 된다.
그는 2025년의 개발 방식을 “인터랙티브 방식”이라고 부른다. 버그를 고치거나 기능을 구현하고 싶을 때, 터미널이나 IDE를 열고 에이전트에게 작업을 지시한 다음, 에이전트가 작업하는 동안 옆에서 함께 대화하며 방향을 잡아주는 방식이다. 여러 에이전트를 동시에 열어두고 작업을 분배하기도 하지만, 이 모든 것이 개발자가 자리를 지키고 있는 상태에서 이루어진다.
그러나 2026년에 일어날 다음 단계는 이 에이전트들이 사람의 직접적인 관여 없이도, 클라우드에서 자율적으로, 팀 전체의 가시성 아래, 스케줄에 따라 혹은 이벤트에 반응해서 작동하는 것이다.
4. 랩톱 중심 에이전트 워크플로의 한계
Zach는 현재의 랩톱 기반 멀티에이전트 워크플로가 직면한 구체적인 문제들을 체계적으로 제시한다.
4.1 하드웨어 물리적 한계
가장 직관적인 문제다. 에이전트를 여러 개 동시에 돌리면 랩톱의 CPU와 메모리가 한계에 부딪힌다. Warp 같은 팀의 경우, 백만 줄짜리 Rust 코드베이스를 여러 벌 체크아웃해두고 각각에서 에이전트를 돌리면 랩톱이 버텨낼 수 있는 수준을 넘어선다.
4.2 팀 가시성(Visibility)의 부재
팀을 이끄는 엔지니어링 매니저나 CTO 입장에서 생각해보자. 각 개발자의 랩톱에서 에이전트들이 돌아가고 있지만, 그 내용이 조직 전체에서 보이지 않는다. 어떤 에이전트가 무슨 작업을 하고 있는지, 에이전트 도입이 어느 수준까지 진행됐는지, 생산성은 실제로 얼마나 향상됐는지를 파악할 방법이 없다.
4.3 보안 구멍의 위험
에이전트가 랩톱에서 실행된다는 것은, 그 에이전트가 어떤 데이터에 접근하는지, 어떤 API를 호출하는지, 어떤 코드를 외부로 내보내는지를 중앙에서 감사(audit)하거나 통제하기 어렵다는 것을 의미한다. 보안 구멍이 있어도 발견하기 힘들다.
4.4 연속성 문제
랩톱이 꺼지거나 인터넷이 끊기면 에이전트도 멈춘다. 장시간 실행되어야 하는 작업이나 야간/주말에 돌아야 하는 자동화 작업은 랩톱 환경에서 안정적으로 운영할 수 없다.
4.5 컨텍스트 창(Context Window) 한계
어려운 코딩 작업을 에이전트에게 맡기다 보면, 에이전트가 컨텍스트 창을 초과해버리는 문제가 자주 발생한다. 컨텍스트를 압축(compact)하면 에이전트가 이전 맥락을 잊어버리기 시작한다. 길고 어려운 작업을 처리하기 위한 새로운 프리미티브(primitive)가 필요하다.
이 다섯 가지 문제는 모두 같은 근원에서 비롯된다. 에이전트가 개인 랩톱에 묶여 있다는 것이다. 해법의 방향도 자연스럽게 도출된다. 에이전트를 클라우드로 옮겨야 한다.
5. 솔루션의 방향: 클라우드로의 이전과 오케스트레이션
Zach는 솔루션을 설명하면서 먼저 두 가지 유형의 문제를 구분한다.
첫 번째는 단일 에이전트의 장기 실행(long single-threaded agents) 문제다. 어려운 코딩 작업 하나를 에이전트가 처음부터 끝까지 완수하게 하려면, 컨텍스트 관리, 메모리 지속성, 중간 실패에 대한 복구 등 복잡한 인프라가 필요하다.
두 번째는 복수 에이전트의 협업(multi-agent collaboration) 문제다. 어떤 종류의 작업들은 여러 에이전트가 병렬로 달려들면 훨씬 빠르고 효과적으로 처리될 수 있다. 대규모 코드베이스의 리팩토링, 여러 마이크로서비스에 걸친 변경 등이 여기에 해당한다.
그는 또한 이 두 유형의 솔루션을 위해 2026년에 갖춰져야 할 인프라를 “오케스트레이션”이라는 개념으로 묶는다. 그리고 이 오케스트레이션의 핵심이 클라우드로의 이전임을 강조한다. 흥미롭게도 그는 “오케스트레이션이라 불렀지만, 사실 다른 큰 부분은 그냥 클라우드로 이전하는 것”이라고 솔직하게 인정한다. 기술적 복잡함보다 실용적인 이전이 핵심이라는 것이다.
한편 그는 일부 대형 기업들이 이미 내부적으로 자체 에이전트 오케스트레이션 시스템을 구축하고 있다는 사실도 언급한다. Stripe가 “Minions”라는 이름의 내부 시스템을 론칭했고, RAMP도 유사한 시스템을 구축했다. 규모가 큰 조직은 이런 시스템을 직접 만드는 것이 합리적일 수 있다. 그러나 대부분의 팀에게는 이 모든 것을 처음부터 구축하는 데 드는 시간과 비용이 부담스럽다. 그래서 Warp가 나선다.
6. 에이전트 오케스트레이션의 주요 활용 사례
Zach는 클라우드 에이전트 오케스트레이션이 필요한 구체적인 활용 사례들을 제시한다.
6.1 인터랙티브 코딩 작업의 병렬화
현재 가장 많이 사용되는 방식을 클라우드로 확장한 것이다. 한 기능을 구현하거나 버그를 수정하는 인터랙티브 코딩 작업을, 랩톱 제약 없이 클라우드에서 여러 개 동시에 실행한다. Zach는 데모에서 알파벳 A부터 E까지 다섯 가지 수식(formula)을 각각 다른 에이전트에게 병렬로 구현하도록 클라우드에 론칭하는 모습을 직접 보여준다.
6.2 반복적 개발 작업의 자동화(Automations)
에이전트가 특정 이벤트나 스케줄에 따라 자동으로 실행되는 방식이다. Zach가 제시한 구체적인 예시들은 실제 엔지니어링 팀에서 즉시 도입할 수 있는 것들이다.
- 문서 자동 업데이트: Warp에서 새 릴리즈가 나올 때마다 에이전트가 코드베이스와 기존 문서를 분석하고, 변경된 내용에 맞게 문서를 자동 업데이트하는 PR을 생성한다.
- 죽은 코드 정리: 매주 타이머로 실행되는 에이전트가 이미 꺼진 feature flag들(dead code를 감싸고 있는 플래그들)을 탐지해 자동으로 제거한다. 개발자가 직접 찾아다니며 정리하던 반복 작업을 에이전트가 대신한다.
이런 자동화 작업들이야말로 에이전트를 랩톱에서 클라우드로 옮겨야 하는 강력한 이유다. 개발자가 자리를 비워도, 심지어 잠을 자는 동안에도 에이전트는 계속 일할 수 있기 때문이다.
6.3 앱 내 에이전트 기능(Agents as App Intelligence)
에이전트는 단순히 개발자의 보조 도구를 넘어, 애플리케이션 자체의 핵심 기능으로 임베딩될 수 있다. Zach는 Warp 내부에서 실제로 사용하는 “PowerFixer”라는 도구를 예시로 든다. 이것은 GitHub 이슈를 트리아지(분류/분석)하는 CLI 애플리케이션인데, 앱 내에서 직접 에이전트를 론칭해 중복 이슈를 자동으로 제거하거나, 특정 이슈에 대한 수정 PR을 생성하는 기능을 제공한다. 여기서 에이전트는 앱의 “지능 기능(intelligence feature)”으로서 동작한다. 단순한 자동화가 아니라, 사용자가 원할 때 에이전트를 호출해 복잡한 작업을 처리하는 인터랙티브 앱의 구성요소가 되는 것이다.
7. 클라우드 에이전트를 직접 구축하려면 필요한 것들
Zach는 조직이 클라우드 에이전트 시스템을 직접 구축하려 할 때 갖춰야 할 핵심 프리미티브들을 설명한다. 이는 Warp의 Oz가 어떤 문제를 해결하려는지를 역으로 보여주는 분석이기도 하다.
환경(Environments): 에이전트가 무엇에 접근할 수 있는지를 정의하는 것. 어떤 도구 체인이 있는지, 어떤 코드에 접근 가능한지를 명세해야 한다.
호스팅(Hosting): 에이전트를 실제로 실행할 컴퓨팅 자원. Daytona, E2B, Docker 샌드박스, Namespace 등의 옵션이 있다.
가시성(Visibility): 에이전트가 무엇을 하고 있는지 보여주는 모니터링 시스템. 단순한 로그가 아니라, 에이전트의 추론 과정, 생성한 아티팩트, 진행 상태 등을 실시간으로 파악할 수 있어야 한다.
휴먼 인 더 루프(Human in the loop): 에이전트가 80%까지 완료했을 때 엔지니어가 개입해서 나머지를 마무리하거나 방향을 수정할 수 있는 구조. 완전 자율화가 목표이더라도, 현 시점에서는 사람이 언제든 개입할 수 있는 핸드오프 메커니즘이 필수적이다.
완전한 프로그래밍 가능성(Full Programmability): API, SDK, CLI를 통해 에이전트를 론칭하고, 환경을 설정하고, 아티팩트를 가져오고, 대화 히스토리를 추출할 수 있어야 한다. 이 프로그래밍 가능성은 인간 개발자만을 위한 것이 아니라, 에이전트가 다른 에이전트를 오케스트레이션하는 것을 가능하게 하는 빌딩 블록이기도 하다.
8. Warp의 해답: Oz 오케스트레이션 플랫폼
Warp가 이 문제에 대한 답으로 내놓은 것이 Oz다. Zach는 Oz를 “Vercel for cloud agents” 또는 “Supabase for cloud agents”에 비유한다. 즉, 개발자들이 복잡한 인프라를 직접 구축하지 않고도 클라우드 에이전트 워크플로를 쉽게 사용할 수 있게 해주는 플랫폼이라는 것이다.
Oz는 2026년 2월 10일에 공식 출시되었으며, Warp 무료/유료 플랜 모두에게 제공된다. 아래는 Oz가 제공하는 핵심 기능들이다.
8.1 자동 추적(Auto-tracking)
어디서 Oz 코딩 에이전트를 론칭하든, 어떤 방법으로 론칭하든 관계없이, 해당 에이전트 실행에 대한 링크와 전체 기록이 자동으로 생성된다. 에이전트가 생성한 PR, 작성한 코드, 추론 과정 등 모든 아티팩트가 자동으로 기록되어 나중에 조회할 수 있다.
8.2 팀 가시성(Team Visibility)
팀의 모든 구성원이 어떤 에이전트 작업을 실행했는지, 그 결과가 무엇인지를 중앙에서 확인할 수 있다. Zach는 데모에서 자신의 팀원 Matthew, Ian 등이 실행한 에이전트 작업들이 Oz 웹 앱에서 한눈에 보이는 것을 보여주며 “에이전트를 위한 Google Docs 같은 개념”이라고 설명한다.
8.3 핸드오프(Handoff)
에이전트가 80%까지 작업을 완료한 뒤 막혔을 때, 팀의 어떤 엔지니어든 해당 에이전트 세션에 접속해 나머지 작업을 이어받을 수 있다. 랩톱에서 시작한 에이전트 작업을 웹이나 모바일에서 이어서 지시하거나 방향을 바꿀 수도 있다.
8.4 Named Agents & Skills
반복적으로 실행될 에이전트 작업을 “Named Agent”로 정의할 수 있다. 이는 코드 저장소에 버전 관리된 스킬 파일(skill file)로 관리되며, 스케줄에 따라 자동 실행되거나 특정 이벤트에 반응해 실행될 수 있다. 고객 피드백 분석, 사기(fraud) 탐지, feature flag 정리 등을 정형화된 스킬로 만들어 팀 전체에서 공유하고 재사용할 수 있다.
8.5 완전한 프로그래밍 가능성
Oz는 CLI, API, SDK를 통해 완전히 프로그래밍 가능하다. 에이전트를 론칭하고, 상태를 추적하고, 결과물을 가져오는 모든 것이 코드로 자동화될 수 있다. 이것이 결국 에이전트가 다른 에이전트를 조율하는 진정한 멀티에이전트 오케스트레이션의 기반이 된다.
8.6 자체 인프라 지원(Self-hosting)
기업 고객들이 자사 인프라 위에서 Oz 에이전트를 실행할 수 있는 옵션도 제공된다. 코드 저장소는 자사 머신에서만 클론되고, 에이전트는 VPN이나 방화벽 내에서 실행되지만, 오케스트레이션, 세션 관리, 모니터링은 Warp의 백엔드를 활용하는 분리 아키텍처를 채택하고 있다.
9. 라이브 데모 상세 분석
강연의 백미는 Zach가 직접 진행한 라이브 데모 세 가지다. 이 데모들은 추상적인 개념을 실제 동작하는 시스템으로 구체화시켜 보여준다.
데모 1: 병렬 클라우드 에이전트
Warp 팀이 Google Docs/Sheets를 모방해서 직접 “바이브 코딩(vibe coding)”으로 만든 스프레드시트 앱이 데모의 배경이 된다. 이 앱은 기본 합산(SUM) 수식은 구현되어 있지만 절대값(ABS) 등 많은 수식이 미구현 상태다.
Zach는 이 앱에 누락된 수식들을 알파벳 순서로 나눠서 여러 에이전트에게 병렬로 구현하도록 지시한다. “A로 시작하는 수식 모두 구현해라”, “B로 시작하는 수식 구현해라” 하는 식으로 각각의 작업을 클라우드 에이전트로 론칭한다. 중요한 것은, 이 에이전트들이 랩톱에서 실행되는 것이 아니라 클라우드에서 실행되기 때문에, 랩톱 성능에 구애받지 않고 A, B, C, D, E 등 여러 에이전트를 거의 동시에 론칭할 수 있다는 점이다.
Oz 웹 앱에서 보면 이 모든 에이전트 실행이 팀 단위에서 추적되고 있으며, 팀원들이 실행한 다른 에이전트 작업들(PR 생성, 계획 수립 등)도 함께 보인다. 또한 랩톱에서 시작한 에이전트 작업을 웹에서 열어서 “E와 F로 시작하는 수식을 구현해라”와 같이 지시를 업데이트하자 에이전트가 즉시 반응해 작업 내용을 조정하는 것을 보여준다.
데모 2: Named Agents & 자동화 스킬
Oz의 “Named Agents” 기능을 보여주는 데모다. 저장소 안의 어떤 스킬(문서로 정의된 에이전트 작업 명세)도 반복 실행 가능한 Named Agent로 등록할 수 있다. 고객 피드백 분석 스킬, 사기 탐지 스킬 등의 예시가 등장하며, 이 스킬들이 스케줄에 따라 자동으로 실행되고 PR 같은 결과물을 자동으로 생성하는 모습을 보여준다.
데모 3: PowerFixer — 앱 내 에이전트 기능
Warp가 내부적으로 GitHub 이슈 트리아지에 사용하는 CLI 앱 “PowerFixer”를 보여준다. 이 앱에서 수천 개의 GitHub 이슈를 탐색하고, 자동 중복 제거(dedup) 결과를 확인하며, 특정 이슈를 선택해 에이전트에게 수정 PR을 생성하도록 지시할 수 있다. 이 모든 에이전트 실행이 팀 단위에서 추적되고, 공유 가능한 세션 링크로 팀원들이 진행 상황을 확인할 수 있다.
10. 질의응답: GitHub Copilot Agents와의 비교
강연 말미에 한 청중이 GitHub의 클라우드 에이전트(GitHub Copilot Agents)와 어떻게 다른지 질문한다. Zach는 비교적 겸손하게 “비슷한 아이디어”라고 인정하면서도, Warp가 특별히 집중하는 차별화 포인트를 설명한다.
첫째, 프로그래밍 가능성(Programmability) 이다. 기존 시스템들이 특정 Docker 환경을 설정하고 클라우드 호스트에서 실행하는 방식으로 굉장히 경직되어 있는 반면, Oz는 에이전트를 개발자 자신의 인프라로 가져와서도 추적 등의 기능을 모두 사용할 수 있도록 유연성을 극대화하고 있다.
둘째, 에이전트 하네스의 중립성 이다. Warp의 에이전트만 지원하는 것이 아니라, Claude Code, Codex 등 어떤 에이전트 하네스와도 함께 작동하는 범용 오케스트레이션 플랫폼을 지향한다는 것이다.
11. 강연의 의미와 시대적 맥락
이 강연이 단순한 제품 발표를 넘어서 중요한 이유는, 소프트웨어 개발이라는 직업의 본질이 변화하고 있음을 정면으로 다루고 있기 때문이다.
역사적으로 소프트웨어 개발자의 생산성은 개인 단위로 측정되어 왔다. 더 빠른 IDE, 더 좋은 자동완성, 더 나은 디버거 — 이 모든 도구의 발전은 “한 명의 개발자가 더 빠르게 코드를 쓸 수 있게 하는 것”에 집중해 왔다. GitHub Copilot의 등장, 그리고 Claude Code, Codex, Warp Agent의 등장도 기본적으로는 이 패러다임 위에서 작동했다. 개발자 한 명이 AI와 함께 더 빠르게 코드를 만드는 것.
그런데 Zach가 제시하는 비전은 이 패러다임을 근본적으로 뒤집는다. 앞으로 개발자의 생산성은 개인이 얼마나 빠르게 코드를 쓰느냐가 아니라, 얼마나 많은 에이전트를 얼마나 효과적으로 오케스트레이션하느냐로 측정될 것이다. 마치 공장의 생산성이 노동자 개인의 손재주가 아니라 기계들의 조율과 관리 능력으로 측정되듯이.
이 관점에서 그의 비유는 인상적이다. “엔지니어에게 더 빠른 자전거를 주는 것”이 아니라 “조직에게 교통 시스템을 주는 것”이라는 표현이 그것이다. 개인 도구의 개선이 아니라 조직적 인프라의 구축으로 패러다임이 이동하는 것이다.
또한 Zach의 예측대로라면, 엔지니어링 팀장의 역할도 바뀐다. 더 이상 “좋은 코드를 직접 쓰는 사람”이나 “코드 리뷰를 잘하는 사람”이 좋은 리더가 아니라, 어떤 에이전트에게 어떤 작업을 맡길지 설계하고, 에이전트 함대를 효과적으로 운영하며, 에이전트의 결과물을 검증하고 통합하는 사람이 뛰어난 리더가 된다.
12. Warp와 Oz에 대한 최신 정보 (2026년 2월 기준)
강연에서 언급된 Oz는 2026년 2월 10일에 공식 출시되었다. 공식 발표 자료와 문서를 바탕으로 한 주요 사실들은 다음과 같다.
출시 배경: 업계 조사에 따르면 대부분의 기업이 AI 코딩 도구를 도입하고 있지만, 실제로 에이전트를 프로덕션에 배포한 기업은 10%도 안 되는 것으로 나타났다. Warp는 이 갭이 기술적 의지의 문제가 아니라 거버넌스, 가시성, 자동화를 갖춘 인프라의 부재 때문이라고 판단했다.
사용자 규모: 강연 당시 기준으로 Warp는 전 세계 70만 명 이상의 개발자들이 사용하고 있으며, Docker, Ramp, Peloton을 포함한 기업들과 Fortune 500 기업의 절반 이상, 주요 AI 연구소들이 고객사에 포함되어 있다.
지원 에이전트 모델: Oz는 Claude(Anthropic), Codex(OpenAI), Gemini(Google) 등 주요 AI 모델을 지원하며, Skills 표준을 지원해 쉽게 온보딩할 수 있다.
접근 방법: Oz는 Warp 데스크톱 앱, oz.warp.dev 웹 앱, Oz CLI, API/SDK를 통해 사용할 수 있으며, 모바일에서도 에이전트를 모니터링하고 제어할 수 있다.
통합 지원: Slack, Linear, GitHub Actions 등 외부 시스템과의 연동을 통해 이벤트 기반 에이전트 실행이 가능하다. 서버 크래시, 버그 리포트, CI 실패 등의 이벤트에 자동으로 에이전트가 반응하도록 설정할 수 있다.
엔터프라이즈 기능: 자사 인프라에서 Oz 에이전트를 실행하는 Self-hosting 기능(Enterprise 플랜), Bring Your Own LLM(BYOLLM)을 통한 AWS Bedrock 등 자체 클라우드 공급자 활용 기능을 제공한다.
마치며
Zach Lloyd의 이 강연은 2026년 초의 기술 시대정신을 잘 포착하고 있다. AI 에이전트가 단순한 코딩 보조 도구를 넘어 소프트웨어 개발의 핵심 실행 단위로 자리잡기 시작했고, 이제 그 에이전트들을 어떻게 팀 단위, 조직 단위로 안전하고 효과적으로 운영할 것인가라는 인프라 문제가 전면에 등장했다는 것이다.
그의 예측처럼 2026년이 실제로 에이전트 오케스트레이션의 해가 될지는 시간이 말해줄 것이다. 하지만 분명한 것은, 에이전트 기반의 소프트웨어 개발로의 전환은 이미 진행 중이며, 그 다음 단계인 오케스트레이션으로의 이행은 피할 수 없는 방향이라는 점이다.
작성 일자: 2026-04-01