Warp가 엔지니어링 리더들이 더 이상 선호하는 코딩 에이전트를 하나만 선택하지 않을 것이라고 확신하는 이유

엔지니어링 리더들은 지난 1년 동안 팀이 AI 코딩 도구를 가능한 한 빨리 도입하도록 노력해 왔습니다. 이제 새로운 질문들이 그 자리를 대신하고 있습니다. 이 모든 것이 비용을 지불할 가치가 있는지 어떻게 측정할 것인가, 그리고 에이전트가 프로덕션 시스템에서 통제 없이 실행되는 것을 어떻게 막을 것인가 하는 문제입니다.

터미널부터 구축된 오픈 에이전틱 개발 환경(open agentic development environment)인 개발자 도구 기업 Warp는 그 해답이 단 하나의 에이전트를 선택하여 표준화하는 것이 아니라고 생각합니다. 대신 팀이 여러 에이전트를 동시에 실행하고, 서로 비교하며, 단일 제어 평면(control plane)에서 이들 모두를 관리할 수 있는 방법을 제공하는 것이 해답이라고 봅니다.

Tessl이 지난 2월에 작성했듯이, 오케스트레이션 (orchestration)은 그 자체로 하나의 전문 분야로 부상했습니다. 즉, 병렬로 실행되는 여러 에이전트를 조정, 감독 및 지시하기 위한 전용 도구 계층입니다. 지난 2월, Warp는 코딩 에이전트를 대규모로 실행하고 관리하기 위한 클라우드 플랫폼인 Oz를 출시했습니다.

이제 Warp는 한 단계 더 나아가고 있습니다. 지난 5월, 이 회사는 Oz를 최초의 멀티 하네스 제어 평면(multi-harness control plane)이라 부르는 형태로 확장했습니다. 이는 팀이 특정 에이전트 하나에 전념하는 대신, 단일 인터페이스를 통해 Claude Code, Codex, Warp Agent를 동시에 실행할 수 있음을 의미합니다.

Tessl은 Warp의 CEO Zach Lloyd를 만나 엔지니어링 리더들이 에이전트 함대(agent fleets)를 어떻게 생각하고 있는지, 하네스 계층(harness layer)이 실제로 무엇을 변화시키는지, 그리고 자율성과 인간의 감독 사이의 경계가 실제로 어디에 그어지고 있는지에 대해 논의했습니다.

"무법지대": 에이전트 골드러시가 어떻게 예산 문제로 변했는가

Zach는 Google에서 수년간 근무하며 Docs와 Sheets의 엔지니어링을 이끌었으며, 이후 사진 편집 스타트업인 SelfMade를 공동 창업했습니다. 그 후 Time에서 임시 CTO로 재직했으며, 2020년 Warp를 설립하여 Sequoia, Google Ventures, Figma의 공동 창업자 Dylan Field, 그리고 Salesforce의 공동 창업자 Marc Benioff 등으로부터 7,000만 달러 이상의 투자금을 유치했습니다.

Google 규모의 협업 도구를 구축하고 스타트업 세계를 경험한 그러한 배경은, 엔지니어링 툴링 (Engineering Tooling) 환경이 얼마나 빠르게 변화했는지에 대해 Zach에게 특별한 관점을 제공합니다. 그는 약 1년 반 전만 해도 대부분의 기업이 개발자들이 AI 자동 완성 (Autocomplete) 도구를 사용하도록 유도하는 데 집중하고 있었다고 말합니다. 그러다 약 1년 전, 대화의 주제는 대화형 에이전트 (Interactive Agents) — Claude Code, Codex, Warp 등 — 로 옮겨갔으며, 엔지니어들이 도구에 지시를 내려 기능을 구축하고 문제를 엔드 투 엔드 (End-to-end)로 해결하는 단계에 이르렀습니다.

이제 그는 그 단계 또한 대부분 지나갔다고 말하며, 대화에 CFO (최고재무책임자)가 등장한 것이 아마도 이를 보여주는 가장 명확한 신호라고 설명합니다.

"현재 기업들은 '사람들이 채택하게 만들 수 있을까'라는 사고방식에서 'ROI (투자 대비 수익)를 어떻게 측정할 것인가'라는 사고방식으로 전환되었습니다."라고 Zach는 설명했습니다. "기업들은 이러한 도구들에 많은 돈을 지불하고 있으며, 이에 따라 CFO가 개입하기 시작했습니다. 모든 비용이 가시화되면서, 기업들은 모든 엔지니어가 각기 다른 에이전트에 가능한 많은 비용을 지출하던 '무법지대'에서, 최대한의 생산성을 유지하면서도 이를 측정하고, 할당량과 예산을 설정하며, 또한 서로 다른 유형의 작업에 서로 다른 에이전트를 사용하는 세상으로 어떻게 나아갈지 고민하고 있습니다."

마지막 지점은 Warp가 '멀티 하네스 (Multi-harness)' 전략에 베팅하는 핵심 이유입니다. Zach는 엔지니어링 팀이 단일 에이전트로 표준화하기보다는, 모든 에이전트에 대해 거버넌스 (Governance) 계층을 일관되게 유지하면서도 각 에이전트가 가장 잘 수행하는 작업에 따라 서로 다른 작업을 서로 다른 에이전트로 라우팅 (Routing) 할 수 있는 능력을 원한다고 주장합니다.

"우리가 목격하고 있는 가장 큰 트렌드는 이것입니다: 최첨단 (Frontier) 모델을 사용해야 할 때, 특정 작업에는 오픈 웨이트 모델 (Open-weight models)을 사용할 수 있는가 하는 점입니다."라고 Zach는 말했습니다. "우리가 Oz를 포지셔닝하는 방식은 기본적으로 단 하나의 지능 소스에 종속되지 않도록 하는 것입니다. Claude Code를 사용할 수도 있고, Codex를 사용할 수도 있으며, 오픈 웨이트 모델을 사용할 수도 있습니다. 하지만 특정 에이전트에 밀접하게 결합되지 않은 거버넌스 (Governance) 인프라 계층에 자신 있게 투자할 수 있습니다."

이를 뒷받침하는 경제적 요인은 이미 가시화되고 있습니다. DeepSeek, Kimi, Qwen과 같은 오픈 웨이트 모델 (Open-weight models)은 최첨단 (Frontier) 모델에 한참 뒤처지던 수준에서 벗어나, 많은 작업에서 최첨단 모델과 대등한 성능을 보여주는 동시에 추론 비용 (Inference cost)은 극히 일부 수준으로 낮췄습니다. Tessl 또한 정확히 이러한 이유로 최근 기본 평가 모델 (Default eval model)을 Claude Sonnet 4.6에서 GLM 5.1로 전환했습니다. 기술 평가 작업에서 더 저렴한 오픈 웨이트 모델이 훨씬 낮은 비용으로 거의 동일한 신호 (Signal)를 생성한다는 것을 발견했기 때문입니다.

다른 곳에서도 AI 에이전트 스타트업인 Lindy는 최근 트래픽의 100%를 Anthropic에서 DeepSeek v4로 이동시켰으며, CEO Flo Crivello는 이 과정을 통해 회사가 수백만 달러를 절약하게 될 것이라고 주장했습니다.

Warp가 더 폭넓게 개방성에 집중해 왔다는 점도 주목할 만합니다. 이들은 올해 초 클라이언트를 오픈 소스로 공개했으며, Oz 자체를 사용하여 리포지토리 (Repo)를 관리하고 있습니다. 즉, 에이전트가 구현 (Implementation)을 담당하고, 커뮤니티 기여자들이 방향 설정과 검증 (Verification)을 담당하는 구조입니다.

"우리는 이제 우리의 규칙, 컨텍스트 (Context), 그리고 검증 (Verification)을 거쳐 Oz가 생성한 코드에 대해 큰 확신을 가지고 있습니다. 따라서 기여하는 사람이라면 누구나 기능을 올바르게 코딩할 확률이 매우 높습니다."라고 Zach는 당시 말했습니다.

이러한 움직임은 Warp의 자체적인 가설을 검증하는 실시간 테스트 역할도 합니다. 즉, 오케스트레이션 레이어 (orchestration layer)가 공개 리포지토리 (public repo)를 대규모로 실행할 수 있을 만큼 충분히 훌륭하다면, 기업 팀들이 자신들의 리포지토리를 믿고 맡길 수 있을 만큼 충분하다는 것입니다.

“에이전트 (agents)에 의존한다는 것은 오케스트레이션 (orchestration), 메모리 (memory), 핸드오프 (handoff), 그리고 우리 비즈니스의 핵심인 에이전틱 엔지니어링 (agentic engineering)의 다른 모든 부분들을 완벽하게 해내야 한다는 압박감을 우리에게 줍니다.”라고 Zach는 이어서 말했습니다. “여기에 선순환 구조 (virtuous loop)가 있습니다.”

이 선순환 구조는 고객에게도 확장됩니다. Zach는 가장 중요한 요소들인 컨텍스트 관리 (context management), 메모리 (memory), 감사 로그 (audit logs) 등이 모두 에이전트 자체로부터 분리될 수 있다고 주장합니다. 그것이 Oz의 목적입니다. 이 모든 것을 위한 컨테이너 레이어 (container layer)를 제공함으로써, 최고의 모델 (model)이나 하네스 (harness)가 변경될 때 — Zach는 이것이 몇 달마다 일어날 것이라고 분명히 말했습니다 — 팀들이 처음부터 다시 시작하지 않도록 하는 것입니다.

모델만으로는 충분하지 않다: 하네스와 컨텍스트가 똑같이 중요한 이유

자연스러운 질문은 멀티-하네스 (multi-harness)가 문제를 찾기 위해 만들어진 해결책은 아닌가 하는 점입니다. 만약 Claude Code와 Warp Agent가 모두 Anthropic 모델 위에서 실행될 수 있다면, 하네스 (harness)가 실제로 바꾸는 것은 무엇일까요?

Zach의 답변은 성능이란 모델 (model), 하네스 (harness), 그리고 컨텍스트 (context)라는 세 가지 요소가 함께 작동하여 만들어지는 함수라는 것입니다.

“하네스는 컨텍스트를 주입하는 역할을 합니다.”라고 Zach는 말했습니다. “컨텍스트 윈도우 (context window)를 잘 관리하는 하네스가 필요합니다. 즉, 언제 다양한 외부 컨텍스트 소스를 가져와서 넣을 것인가의 문제입니다. 너무 많은 컨텍스트를 넣으면 모델이 이를 요약해야 하며, 이 과정에서 현재 작업에 대한 정보를 잃게 됩니다. 그 컨텍스트 윈도우를 어떻게 관리하느냐가 정말 중요합니다. 서로 다른 하네스들은 각기 다른 분야에서 뛰어난 성능을 보입니다. Claude Code는 훌륭한 하네스이고, Codex는 정말 좋은 하네스이며, Warp의 에이전트 하네스 또한 정말 좋습니다.”

모델과 하네스(harness)는 이제 기본 사양(table stakes)입니다. 세 번째 요소인 조직적 맥락(organisational context)이야말로 Warp가 현재 '크로스 하네스 메모리(cross-harness memory)'라고 부르는 기술을 통해 가장 집중적으로 투자하고 있는 부분입니다. 이 아이디어의 핵심은 에이전트가 작업을 완료함에 따라 시스템이 무엇이 효과적이었는지를 포착하고, 어떤 하네스를 사용하든 향후 실행 시 이를 자동으로 노출하는 것입니다.

"이러한 에이전트 중 하나가 실행될 때마다 어떤 작업을 수행하고, 아마도 문제를 해결하는 과정에서 인간의 안내를 받아 어떤 솔루션에 도달하게 됩니다."라고 Zach는 말했습니다. "우리가 원하지 않는 것은 그것을 버리고 다음에 다시 처음부터 시작하는 것입니다. 만약 메모리 시스템이 있다면, 그것을 모든 에이전트가 무엇을 하고 있는지 관찰하며 '이것은 기억해 둘 만한 중요한 사항인 것 같다'라고 판단하는 레이어(layer)로 생각하십시오."

크로스 하네스 에이전트 메모리(Cross-harness agent memory)는 현재 소수의 파일럿 고객을 대상으로 리서치 프리뷰(research preview) 단계에 있습니다.

더 많은 자율성, 더 많은 제어: 불편한 균형 잡기에 대한 Warp의 해답

Oz의 피치(pitch) 중심에 있는 긴장감은 Zach가 해결하려 하기보다는 관리하려는 대상입니다. 한편으로 이 플랫폼은 마이그레이션(migrations), 프로덕션 배포(production deployments)와 같이 복잡하고 오래 걸리는 작업을 인간의 감독을 최소화하여 처리할 수 있는 에이전트를 약속합니다. 다른 한편으로는, 동일한 릴리스에서 승인 게이트(approval gates), 사용자별 인증(per-user authentication), 최소 권한 원칙(least-privilege permissions)을 추가합니다.

이 두 가지 요소는 서로 반대 방향으로 끌어당깁니다.

"근본적인 긴장 관계가 있다고 생각하지만, 이는 필요하다고 봅니다."라고 Zach는 말했습니다. "고객들과 대화해 보면, 기업들이 완전히 손을 떼고(hands off) 있을 준비가 되어 있다고 생각하지 않습니다. 현재 시점에서의 이상적인 시스템은 공장 바닥(factory floor)과 같습니다. 자동화 프로세스를 통해 자동화할 수 있는 것들을 배치하고 싶지만, 동시에 인간이 개입하여 '이것이 제대로 수행되었는가?'라고 말하고 싶어 하는 곳 말입니다."

Zach가 적용하는 논리는 본질적으로 리스크 계층화(risk-tiering)입니다. 오류 비용이 가장 저렴한 스택의 부분부터 먼저 자동화하고, 오류 비용이 가장 큰 부분은 가장 오랫동안 인간의 감독을 유지하는 방식입니다.

"가장 자동화할 수 있는 부분은 리스크가 가장 낮은 부분입니다. 이는 상식적인 일이죠,"라고 Zach는 말했습니다. "우리 웹사이트를 변경하는 것은 데이터를 변경하는 것보다 훨씬 리스크가 낮습니다. 따라서 리스크가 높은 부분에 적용되기 전에, 리스크가 낮은 부분에서 더 많은 가드레일 (guardrails)이 제거되는 것을 보게 될 것입니다."

기업 내부에서 실제로 누가 그러한 경계선을 긋는지에 대해, Zach는 단 하나의 팀이 담당하는 경우는 드물다고 말합니다. 플랫폼 팀 (Platform teams)이나 전담 AI 개발자 생산성 부서가 주도하는 경향이 있으며, 보안 팀은 항상 관여하고 재무 팀의 관여도 점점 늘어나고 있습니다.

"보안 팀은 항상 관여합니다. 아마도 가장 겁을 내는 팀일 것입니다,"라고 Zach는 말했습니다. "점점 더 비용 관리 (cost management) 요소가 중요해지고 있습니다. 이에 대한 예산은 얼마인가? 엔지니어당 토큰 (token) 예산은 얼마인가? ROI (투자 대비 수익)를 어떻게 확인할 것인가? 이 모든 것들이 고객들에게 중요한 항목이 되기 시작했습니다."

Evals: 공장 바닥 측정하기

이는 대화의 흐름을 evals로 가져옵니다. 즉, 팀들이 이 모든 것이 실제로 작동하고 있는지 어떻게 알 수 있는가에 대한 문제입니다. 여기서 Zach의 프레임워크는 다시 한번 공장 바닥 (factory floor) 비유를 사용합니다. 궁극적으로 원하는 것은 아이디어에서 출시된 제품에 이르기까지 작업이 어떻게 흐르는지에 대한 조감도 (bird's eye view)입니다.

Warp는 자체 오픈 소스 리포지토리인 build.warp.dev를 위해 이 기능의 라이브 버전을 구축했으며, 여기서 누구나 이슈 (issues)가 에이전트 파이프라인 (agent pipeline)을 통해 어떻게 이동하는지 볼 수 있습니다. Zach는 이를 엔터프라이즈 팀들이 목표로 삼아야 할 기준점으로 사용합니다.

"측정 가능한 것 중 하나는 코드 처리량 (throughput of code)이라는 기본적인 측정 지표입니다,"라고 Zach는 말했습니다. "이상적으로는, 더 정교한 단계로 넘어가서 코드 처리량 측정을 넘어 사용자 또는 고객 영향력 (user or customer impact)의 처리량까지 측정할 수 있어야 합니다. 즉, '이러한 기능을 요청하는 티켓이 접수되었고, 에이전트가 이를 구축할 수 있었으며, 비용은 이만큼의 달러 또는 토큰이 소모되었고, 프로덕션 환경에서 XYZ 고객들이 이를 사용했다'는 식으로 연결할 수 있어야 한다는 것입니다. 그것이 꿈의 루프 (dream loop)입니다. 코드 부분은 그렇게 어렵지 않습니다. 그 부분은 우리가 그냥 전달할 수 있는 영역입니다."

PR(Pull Request)당 토큰 효율성 (Token efficiency per PR)은 현재 Warp가 제공하는 기본 지표입니다. 더 어려운 문제, 즉 에이전트의 결과물을 비즈니스 성과 (business outcomes)와 연결하는 것은 Zach가 "성배 (holy grail)"라고 부르는 과제로 남아 있습니다.

에이전트 빌더 (The agent builder): 엔지니어링 배경 지식이 필요 없는 새로운 역할

이번 대화에서 가장 인상적인 부분 중 하나는 에이전트 함대 (agent fleets)가 표준이 됨에 따라 Warp와 그 협력사들의 엔지니어링 팀 자체에 어떤 변화가 일어나고 있는지에 대한 Zach의 설명입니다.

그는 Warp가 채용하는 엔지니어들의 배경 프로필은 크게 변하지 않았다고 말합니다. 변한 것은 그들이 하는 일입니다.

"이제 소프트웨어 엔지니어의 일상은 코드를 작성하는 것이 아닙니다,"라고 Zach는 말했습니다. "이제는 다음과 같은 것들이 핵심입니다: 에이전트에게 사용자 요구 사항 (user requirement)을 정확하게 명시할 수 있는가? 에이전트가 도출한 기술적 계획 (technical plan)이 타당한지 확인할 수 있는가? 코드베이스 (codebase)의 올바른 부분에 구축하고 있는가? 코드를 중복해서 작성하고 있지는 않은가? 인간이 사용하는 것과 동일한 품질의 추상화 (abstraction)를 사용하고 있는가?"