커튼 뒤의 에이전트: Oz 클라우드 에이전트 플랫폼 구축

메타데이터

• 원문 제목: The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp
• 한국어 제목: 커튼 뒤의 에이전트: Oz 클라우드 에이전트 플랫폼 구축
• 채널: aiDotEngineer
• 발표자: Safia Abdalla, Warp
• 발행·처리 날짜: 2026-08-23
• YouTube: https://www.youtube.com/watch?v=L173Z8DpaJg
• 영상 ID: L173Z8DpaJg
• 분류: AI·LLM / 에이전트 플랫폼 / 개발자 도구

📌 핵심 질문 / 이 발표가 다루는 핵심 논점

==개발자와 더 넓어진 빌더 집단이 각자의 방식으로 소프트웨어를 만들 수 있도록, 클라우드 에이전트 플랫폼이 복잡성을 뒤에서 흡수하고 조합 가능한 작업 시스템으로 성장해야 한다.==

• 좋은 개발자 도구는 개발자가 이미 쓰는 워크플로와 선호를 존중하면서 작업의 복잡도 변화에 맞춰 함께 성장한다.
• Oz 클라우드 에이전트 플랫폼은 샌드박스, 호스팅 방식, 에이전트 하네스, 멀티에이전트 오케스트레이션, 산출물, API를 하나의 일관된 구조로 묶어 사용자가 인프라 복잡성을 직접 떠안지 않게 한다.
• Warp의 오픈소스 운영은 이 원칙을 이슈 분류·명세 작성·구현·리뷰에 적용해, 에이전트가 사람을 대체하는 대신 고신호 작업만 사람에게 전달하는 구조를 보여준다.

Safia Abdalla는 개발자 도구가 단순히 코드를 생성하는 기능이 아니라 아이디어를 반복 가능하고 관찰 가능하며 비용 효율적인 소프트웨어 생산 시스템으로 바꾸는 작업 공간이어야 한다고 주장한다. 도예가의 공방처럼 플랫폼은 세부 작업을 표준화하면서도 현장의 신호에 반응하고, 에이전트와 사람이 함께 목표·품질 기준·워크플로를 개선하도록 설계되어야 한다.

1. 개발자 도구가 지켜야 할 출발점

Safia Abdalla는 8년 동안 개발자 도구를 만들며 얻은 경험을 바탕으로, 도구의 가치는 기능 수보다 사용자의 현재 위치를 이해하고 변화하는 작업을 따라가는 능력에서 나온다고 설명한다.

1.1. 개발자의 현재 워크플로에서 시작하기

1. Safia Abdalla의 경력은 개발자 도구라는 문제의식으로 이어진다

   1. 오픈소스와 데이터 과학: Safia Abdalla는 Python·데이터 과학 영역에서 개발자 도구를 만드는 일을 시작했고, Jupyter Notebook 코어 팀에서 활동했다.
   2. Interact 프로젝트 유지보수: Safia Abdalla는 Interact 프로젝트의 메인테이너로 일하며 사용자와 도구 사이의 실제 상호작용을 다뤘다.
   3. Microsoft의 API·SDK 작업: Safia Abdalla는 Microsoft에서 웹 개발자를 위한 API와 SDK를 만드는 일을 이어갔다.
   4. Warp에서 AI 에이전트의 클라우드화: Safia Abdalla는 현재 Warp에서 AI 에이전트를 클라우드로 가져오는 일을 맡고 있다.

2. 좋은 개발자 도구는 사용자의 자리에서 출발한다

   1. 워크플로 적응: 매일 사용하는 도구는 개발자가 이미 가진 작업 흐름을 수용해야 한다.
   2. 변화에 대한 적응: 작업의 복잡도와 성격이 바뀌면 도구도 그 변화에 맞춰 확장되어야 한다.
   3. 습관과 사고의 결합: 사용자의 셸(shell), 언어, 하네스(harness), 리뷰 프로세스 같은 선호는 소프트웨어를 생각하고 만드는 방식의 일부가 된다.

1.2. 개발자 도구의 누적 효과

1. 도구는 소프트웨어 생태계에 복리 효과를 만든다

   1. 생산성의 증폭: 개발자나 빌더가 훌륭한 작업을 하도록 돕는 소프트웨어는 세상에 존재하는 좋은 소프트웨어의 총량을 늘린다.
   2. 즐거운 제작 경험: 개인의 선호와 워크플로에 적응하는 도구는 사용하기도 즐겁고 그 도구로 소프트웨어를 만들기도 즐겁다.

2. 개발자 중심 설계는 장기 사용성을 만든다

   1. 선호의 다양성: 같은 작업이라도 개발자는 셸, 프로그래밍 언어, 하네스, 코드 리뷰 방식에서 서로 다른 선택을 한다.
   2. 성장하는 관계: 도구는 사용자의 현재 방법을 억지로 바꾸기보다 그 방법을 수용한 뒤 작업이 복잡해질 때 더 강력한 기능을 제공해야 한다.

2. 로컬 AI 도구에서 클라우드 에이전트 플랫폼으로

Warp의 변화는 AI가 개발자의 로컬 도구에 들어온 뒤, 노트북의 한계를 넘어 장시간 실행과 다양한 제약을 처리하는 클라우드 에이전트로 확장된 흐름을 보여준다.

2.1. Warp 터미널과 로컬 에이전트의 등장

1. Warp 터미널은 기존 명령줄 워크플로를 수용했다

   1. 터미널의 연속성: AI 이전의 Warp 터미널은 개발자가 익숙하게 사용하던 커맨드라인 작업 방식에 맞춰졌다.
   2. 개발 환경의 확장: 터미널이라는 익숙한 진입점은 이후 AI 기능과 에이전트 작업을 받아들일 수 있는 기반이 되었다.

2. AI는 개발자에게 새로운 로컬 작업 패턴을 열었다

   1. 로컬 도구의 증가: AI가 개발자 도구에 들어오면서 개발자는 자신의 컴퓨터에서 사용할 수 있는 새로운 도구 집합을 얻었다.
   2. 에이전트형 코딩: 개발자는 터미널, IDE, 에디터 안에서 에이전트형 코딩(agentic coding) 패턴을 실험하기 시작했다.

2.2. 노트북의 한계와 클라우드 전환

1. 장시간 작업은 로컬 컴퓨터만으로 처리하기 어려워진다

   1. 실행 시간의 제약: 개발자는 한 번의 짧은 프롬프트가 아니라 오래 실행되는 에이전트 작업을 원하게 되었다.
   2. 제약 조건의 다양화: 에이전트는 서로 다른 실행 제약과 환경 조건에 맞춰 작업해야 했다.
   3. 클라우드의 필요성: 장시간 실행과 다양한 제약을 수용하려면 작업을 클라우드에서 실행할 필요가 생겼다.

2. 클라우드 전환은 인프라 복잡성을 추가한다

   1. 더 복잡한 스택: 클라우드 실행은 로컬 노트북보다 훨씬 어지러운 인프라 문제를 탐색하게 만든다.
   2. 플랫폼의 책임: 개발자 도구를 만드는 팀은 사용자가 인프라 스택의 누수(leaky complexity)를 직접 처리하지 않도록 그 복잡성을 먼저 흡수해야 한다.

3. 플랫폼의 핵심 원칙은 사용자에게 도달하기 전에 복잡성을 처리하는 것이다

   1. 복잡성의 후방 격리: 좋은 경험은 플랫폼이 내부에서 처리하는 복잡성을 사용자 인터페이스에 그대로 노출하지 않는다.
   2. 핵심 업무에 집중: 각 플랫폼 프리미티브(primitive)는 사용자가 인프라가 아니라 자신에게 중요한 작업에 집중하도록 만들어져야 한다.

3. 에이전트가 일하는 장소와 실행 방식

Oz 플랫폼은 에이전트의 실행 공간과 실행 방식을 사용자 환경에 맞게 분리하고, 관리형·자체 호스팅과 여러 하네스를 일관된 경험으로 묶는다.

3.1. 샌드박스와 인프라 선택

1. 샌드박스는 클라우드 에이전트의 작업 공간이다

   1. 격리된 환경: 개발자 컴퓨터에서 실행되지 않는 에이전트는 일을 수행할 장소가 필요하며, 그 장소가 클라우드의 격리된 샌드박스다.
   2. 실행 책임의 분리: 샌드박스는 에이전트가 개발자처럼 파일과 도구를 다루되 사용자 컴퓨터와 분리된 상태에서 작업하게 한다.

2. 초기 셀프 호스팅 샌드박스는 쉬운 진입점을 제공했다

   1. 컴퓨트 걱정의 제거: 초기 설계는 플랫폼이 제공하는 샌드박스를 통해 개발자가 컴퓨트가 어디에 있는지 고민하지 않게 하는 것이었다.
   2. 간단한 온램프: 관리되는 샌드박스는 클라우드 에이전트 플랫폼을 처음 접하는 개발자에게 빠른 시작 경로를 제공했다.

3. 진지한 팀은 자신이 가져온 인프라에서 에이전트를 실행해야 한다

   1. 기존 인프라의 존재: 실제 팀은 이미 자체 인프라와 개발 박스(dev box)를 관리하고 있으므로 완전히 호스팅된 환경만으로는 부족하다.
   2. 보안과 배포 관행: 에이전트 작업은 팀이 가져온 인프라에서 실행되어야 보안 우려와 배포 관행을 반영할 수 있다.
   3. 팀별 선호: 자체 인프라 실행은 팀의 워크플로와 운영 선호를 플랫폼에 맞출 수 있게 한다.

4. 관리형 호스팅과 자체 호스팅은 함께 제공되어야 한다

   1. 선택권의 확대: Oz 플랫폼은 관리형 호스팅(managed hosting)뿐 아니라 자체 호스팅(self-hosting)도 지원한다.
   2. 사용자에게 숨겨진 복잡성: 두 실행 방식을 하나의 모델로 추상화하면 사용자는 내부 인프라 구성 차이를 매번 학습하지 않아도 된다.

3.2. 멀티 하네스와 일관된 플랫폼 경험

1. 하네스는 개발자 워크플로의 개인적인 핵심 도구다

   1. 강한 도구 선호: 개발자는 작업 방식을 형성하는 도구에 강한 애착을 보이며, 어떤 하네스를 쓰는지에도 뚜렷한 선호를 가진다.
   2. 현장의 다양성: 청중은 Claude Code, Codex 또는 전혀 다른 도구를 각자 선호할 수 있으며, Warp는 이런 다양성을 인정해야 한다.

2. 멀티 하네스 지원은 선택권과 작업 적합성을 결합한다

   1. 선호 존중: 사용자는 자신이 일하는 환경에서 익숙한 하네스를 계속 사용할 수 있어야 한다.
   2. 업무별 도구 선택: 사용자는 한 가지 하네스에 갇히지 않고 작업 목적에 맞는 도구를 선택할 수 있어야 한다.
   3. 유연성의 부작용 관리: 플랫폼에 단순히 하네스를 많이 집어넣으면 Claude, Codex, 사용자 정의 하네스마다 경험이 갈라져 파편화될 수 있다.

3. 플랫폼 구조와 가드레일은 여러 하네스의 일관성을 보장한다

   1. 대화 상태 저장·복원: 각 하네스는 대화 상태를 저장하고 나중에 다시 복원할 수 있어야 한다.
   2. 산출물의 공통 처리: PR, 이슈, 새로 생성된 파일 같은 에이전트 산출물은 어떤 하네스에서 만들어져도 같은 방식으로 다뤄져야 한다.
   3. 네이티브 경험의 공유: 하네스는 플랫폼에 내장된 상태 관리와 아티팩트 경험을 공유해 사용자가 하네스마다 새로운 사용법을 배우지 않게 해야 한다.

4. 하나의 프롬프트를 넘어선 멀티에이전트 오케스트레이션

실제 소프트웨어 엔지니어링은 조사·계획·구현·검증을 분리하는 경우가 많으므로, Oz 플랫폼은 여러 에이전트와 하네스·모델을 조합하는 오케스트레이션을 제공한다.

4.1. 역할 분담과 적대적 검증

1. 실제 엔지니어링 작업은 하나의 프롬프트에 잘 들어맞지 않는다

   1. 조사와 계획: 첫 번째 에이전트는 문제를 조사하고 해결책을 계획할 수 있다.
   2. 구현: 두 번째 에이전트는 계획을 실제 코드와 변경 사항으로 옮길 수 있다.
   3. 검증: 세 번째 에이전트는 결과를 검증하고 결함이나 누락을 찾을 수 있다.

2. 서로 다른 모델과 하네스는 더 강한 검증을 만든다

   1. 관점의 분리: 조사·구현·검증 에이전트가 같은 모델과 하네스만 사용하지 않으면 한 가지 관점에 오류가 고착될 위험이 줄어든다.
   2. 적대적 접근: 서로 다른 하네스와 모델을 조합하면 실제로 적대적(adversarial)이고 견고한 접근을 구성할 수 있다.

4.2. 프롬프트 기반 오케스트레이터

1. 사용자는 한 번의 지시로 하위 에이전트를 호출할 수 있다

   1. 오케스트레이션 명령: 사용자는 /orchestrate 같은 명령을 사용하거나 프롬프트로 여러 하위 에이전트에게 작업을 위임하도록 요청할 수 있다.
   2. 단일 진입점: 사용자는 각각의 하위 에이전트를 직접 관리하지 않고 하나의 프롬프트로 전체 작업을 시작한다.

2. 오케스트레이터는 뒤에서 조정 업무를 수행한다

   1. 메시지 중재: 오케스트레이터 에이전트는 하위 에이전트 사이의 메시지를 전달하고 조정한다.
   2. 진행 상황 추적: 오케스트레이터 에이전트는 각 하위 작업의 상태를 추적한다.
   3. 복잡성 추상화: 사용자는 하위 에이전트와 상호작용하고 작업을 연결하는 번거로운 과정을 직접 처리하지 않아도 된다.

5. API 프리미티브와 조합 가능성

Oz 플랫폼의 핵심 가치는 UI 하나를 강요하는 데 있지 않고 에이전트·실행 환경·컴퓨트·산출물을 API 프리미티브로 공개해 누구나 새로운 경험을 조합할 수 있게 하는 데 있다.

5.1. UI를 넘어서는 API 표면

1. 에이전트 관계를 API로 표현한다

   1. 부모-자식 연결: 사용자는 설정(configuration)을 제공해 부모 에이전트에 연결된 하위 에이전트를 실행하도록 API 요청을 보낼 수 있다.
   2. 구조의 노출: 플랫폼은 에이전트와 하위 에이전트의 관계를 숨겨진 UI 동작이 아니라 빌딩 블록으로 제공한다.

2. 좋은 API와 SDK는 플랫폼을 확장시킨다

   1. 사용자 구축 가능성: API와 SDK를 공개하면 사용자는 플랫폼이 제공하는 UI 안에 갇히지 않고 그 위에 자신만의 도구를 만들 수 있다.
   2. 의견의 비강제성: 사용자는 플랫폼 제작자가 정한 특정 경험이나 화면 구조를 그대로 받아들이지 않아도 된다.
   3. 조합 가능성: 프리미티브를 조합하면 제품 표면 위에 겹쳐지는 새로운 에이전트 경험을 누구나 만들 수 있다.

5.2. 플랫폼 전 영역의 프리미티브

1. 에이전트와 하위 에이전트 생성 API가 필요하다

   1. 실행 시작: 개발자는 API로 에이전트와 하위 에이전트를 시작할 수 있어야 한다.
   2. 구성의 재사용: 개발자는 자신의 애플리케이션이나 내부 도구에 에이전트 실행 구성을 재사용할 수 있어야 한다.

2. 실행 환경과 컴퓨트가 API로 노출되어야 한다

   1. 환경 관리: 개발자는 에이전트가 실행되는 환경을 생성·관리할 수 있어야 한다.
   2. 컴퓨트 제어: 개발자는 실행에 필요한 컴퓨트 자원을 플랫폼 위에서 조정할 수 있어야 한다.

3. 에이전트 산출물도 동일한 조합 단위가 되어야 한다

   1. 결과 활용: 개발자는 에이전트가 만든 아티팩트를 다른 워크플로와 연결할 수 있어야 한다.
   2. 엔드투엔드 확장: 에이전트 생성부터 실행 환경, 컴퓨트, 결과물까지 전체 스택이 API로 연결되어야 새로운 도구가 플랫폼의 일부만 우회하지 않고 전체 흐름을 활용할 수 있다.

6. Warp 내부의 SDK 활용과 오픈소스 운영

Warp는 엔지니어링 팀만 API를 사용하는 조직이 아니라, 비엔지니어링 팀도 SDK로 업무용 Slack 봇과 오픈소스 운영 자동화를 만드는 조직으로 확장되었다.

6.1. 비엔지니어링 팀이 만든 에이전트 경험

1. 개발자 관계 팀은 소셜 멘션 관리 봇을 만들었다

   1. 입력 수집: 에이전트는 트윗, Reddit 게시물 등 Warp에 관한 소셜 멘션을 수집한다.
   2. 감정 분석: 에이전트는 각 멘션의 감정(sentiment)을 분석한다.
   3. 사용자 의도 파악: 에이전트는 사용자가 무엇을 원하는지 추정한다.
   4. 응답 초안 제안: 에이전트는 소셜 미디어 팀이 원래 트윗이나 Reddit 글에 답할 때 사용할 응답을 제안한다.

2. SDK는 엔지니어링 밖의 업무에도 적용된다

   1. 제품 작동 문의: Warp 구성원은 제품이 어떻게 작동하는지에 대한 질문에 답하는 데 에이전트를 활용했다.
   2. 경쟁사 조사: Warp 구성원은 경쟁 제품과 시장을 조사하는 데 에이전트를 활용했다.
   3. 내부 확산: 같은 프리미티브가 여러 팀의 맞춤형 Slack 봇과 업무 경험으로 확장되었다.

6.2. 오픈소스 전환과 저장소 관리

1. Warp는 터미널에서 에이전트형 개발 환경으로 성장했다

   1. 제품 범위의 확장: Warp는 처음에 터미널로 시작했지만 이후 에이전트형 개발 환경으로 성장했다.
   2. 오픈소스 결정: Warp는 발표 시점 기준 약 3개월 전에 오픈소스로 전환했다.
   3. 커뮤니티의 기대: 오픈소스 전환은 오래 기다려온 변화였고, Warp는 큰 성공으로 평가했다.

2. 오픈소스 전환은 커뮤니티 참여를 폭발적으로 늘렸다

   1. GitHub 스타 증가: Warp의 GitHub 스타는 약 2만 개에서 6만 개 이상으로 뛰었다.
   2. 기여 규모: Warp 저장소에는 수천 개의 PR이 들어왔고 수백 명의 기여자가 참여했다.
   3. 기여자의 배경: 수백 명의 기여자는 오랫동안 플랫폼을 사용해 온 사람들이었으며, 오픈소스 전환 뒤 마침내 플랫폼 위에 직접 만들 수 있게 되었다.

7. 에이전트가 사람을 대체하지 않고 개발 프로세스를 구조화하는 방식

Warp는 에이전트를 코드와 PR을 무작정 쏟아내는 자동화로 쓰지 않고, 이슈의 맥락을 만들고 명세·구현·리뷰를 연결하는 인간 참여형 프로세스로 사용한다.

7.1. 이슈에서 구현까지의 에이전트 루프

1. 에이전트는 새 이슈를 자동으로 분류한다

   1. 버그·기능 요청 감지: 누군가 Warp 오픈소스 저장소에 버그 신고나 기능 요청을 올리면 에이전트가 자동으로 개입한다.
   2. 코드베이스 조사: 에이전트는 코드베이스와 저장소의 맥락을 조사해 요청자가 무엇을 제안하는지 파악한다.
   3. 추가 질문: 원래 요청이 추상적이면 에이전트는 필요한 정보를 얻기 위해 작성자에게 질문할 수 있다.

2. 에이전트는 오픈소스의 모호성을 줄인다

   1. 정보 부족 문제: 오픈소스에서는 문제나 버그를 고치고 싶은 사람이 충분한 세부 정보를 제공하지 않는 경우가 많다.
   2. 명확성 확보: 에이전트는 코드와 저장소 맥락을 조사하고 질문을 던져 작업을 앞으로 밀어갈 정도의 명확성을 만든다.

3. 에이전트는 명세·구현·리뷰를 단계별로 지원한다

   1. 초기 명세: 에이전트는 작업에 필요한 초기 사양(specification)과 계획을 작성하는 데 도움을 준다.
   2. 구현: 에이전트는 합의된 작업을 구현한다.
   3. 리뷰 게이트: 에이전트는 사람이 검토하기 전에 변경 사항을 검증하는 리뷰 관문 역할을 한다.

7.2. 고신호 작업을 사람에게 전달하는 리뷰 게이트

1. 모든 Warp PR은 에이전트 관리 리뷰를 통과한다

   1. 반복 리뷰: Warp에 기여되는 모든 PR은 에이전트가 관리하는 리뷰 프로세스를 거치며 여러 차례 반복된다.
   2. 사람 호출의 지연: 에이전트가 PR을 승인하기 전에는 Warp 팀의 인간 리뷰어에게 알림을 보내지 않는다.
   3. 업무량 감소: 수천 개의 PR 가운데 사람은 에이전트 리뷰를 통과한 고품질·고신호 PR만 처리한다.

2. 사람은 여전히 운영 루프에 남는다

   1. 의미 있는 참여: Warp는 에이전트가 이슈를 분류하고 코드를 작성하더라도 사람이 프로세스에 참여할 공간을 유지한다.
   2. 자동화의 역할: 에이전트는 인간 판단을 없애는 대신 반복적이고 저신호인 선별 작업을 먼저 처리한다.

3. 저장소 사례는 의도를 구현으로 번역하는 구조를 보여준다

   1. 구조와 맥락: 에이전트는 들어온 아이디어·버그 신고·기능 요청에 구조와 맥락을 부여한다.
   2. 참여 범위의 확대: 개발자는 물론 도메인 지식을 가진 비개발자도 가드레일 안에서 자신의 의도를 실제 소프트웨어 변경으로 연결할 수 있다.
   3. 도메인 지식의 가치: 흥미로운 아이디어와 목표를 가진 사람은 항상 구현자가 아니며, 소프트웨어를 실제로 사용하는 도메인 전문가일 수 있다.

7.3. 자기개선 루프

1. PR과 코드 사례는 에이전트를 개선하는 재료가 된다

   1. 새 사례의 축적: Warp는 저장소에 더 많은 PR과 코드 사례가 쌓일수록 에이전트를 개선한다.
   2. SDLC 고도화: 자기개선 루프(self-improvement loop)는 전체 소프트웨어 개발 생명주기(SDLC)를 강화하는 중요한 방법이 된다.

2. 구조화된 프로세스는 대규모 유입을 감당한다

   1. 처리량의 확장: 이슈와 PR이 갑자기 늘어도 에이전트가 일정한 구조로 선별·명세·구현·리뷰를 진행한다.
   2. 제품 도달 경로: 누구나 아이디어나 버그 신고를 제출하고, 에이전트의 지원을 받으며 실제 제품 변경까지 이동할 수 있다.

8. ‘소프트웨어 공장’보다 ‘공방’에 가까운 시스템

Safia Abdalla는 에이전트 자동화를 소프트웨어 공장(software factory)이라고 부르는 유행어가 사람과 작업 공간의 상호작용을 지워버린다고 비판하며, 도예가의 공방을 통해 더 나은 생산 시스템의 모습을 제시한다.

8.1. 소프트웨어 공장이라는 표현에 대한 문제 제기

1. ‘소프트웨어 공장’은 자동화만 강조하기 쉽다

   1. 유행하는 표현: 사람들은 소프트웨어가 만들어지는 방식을 자동화하고 일하는 시스템을 제공한다는 의미로 software factory라는 말을 자주 사용한다.
   2. 사람의 부재: Safia Abdalla는 공장이라는 표현이 누가 어떤 의도와 감각으로 만드는지 보여주지 못한다고 느끼며 그 용어에 거부감을 드러냈다.

2. 도예가의 머그컵은 생산 시스템의 본질을 설명한다

   1. 시장과 장인의 만남: Safia Abdalla는 약 두 해 전 여름 농산물 시장에서 한 도예가가 만든 머그컵을 샀다.
   2. 손에 맞는 손잡이 곡선: 도예가는 손잡이의 특정 곡선을 사람마다 다른 손에 맞도록 설계했다.
   3. 엄지손가락 딤플: 도예가는 손잡이 위쪽에 엄지를 올려둘 수 있는 특정한 움푹한 부분을 넣었고, 그 부분을 핵심적인 인체공학적 세부사항으로 여겼다.
   4. 넘침을 받는 유약: 도예가는 컵이 넘칠 때 물이 옆면을 타고 흘러내리지 않도록 상단에 유약을 발라 넘친 액체를 받아내게 했다.

8.2. 완성품 뒤에 있는 공방의 설계

1. 도예가는 머그컵뿐 아니라 작업장을 설계했다

   1. 단계별 작업대: 도예가는 머그컵의 여러 부품을 만들기 위해 공방 안에 구성 요소별 작업 스테이션을 마련했다.
   2. 점토 조달과 준비: 도예가는 점토를 조달하고 미리 준비하는 구체적인 프로세스를 만들었다.
   3. 검증 절차: 도예가는 머그컵의 각 구성 요소를 확인하는 검증 단계를 마련했다.

2. 검증 실패는 다음 작업을 결정한다

   1. 딤플 크기 확인: 딤플이 올바른 크기가 아닌지 검사하는 기준이 있었다.
   2. 재시작 지점: 딤플이 잘못되었을 때 공정의 어느 부분을 다시 시작할지 정해져 있었다.
   3. 품질의 반복성: 세부 품질 기준과 재작업 규칙은 완성품의 일관성을 높였다.

3. 공방은 숙련자의 감각을 확장 가능한 시스템으로 바꾼다

   1. 수십 명의 견습생: 도예가는 자신이 만든 공방 시스템을 수십 명의 견습생이 사용할 수 있도록 확장했다.
   2. 하루 수백 개 생산: 공방은 수백 개의 머그컵을 하루에 손으로 제작할 수 있는 규모가 되었다.
   3. 아이디어에서 실재로: 공방은 ‘완벽한 머그컵’이라는 아이디어를 누구나 실제 완성품으로 옮길 수 있게 하는 진지하고 반복 가능한 시스템이 되었다.

8.3. 공방에서 얻는 플랫폼 설계 원칙

1. 공방은 개인 작업실 이상의 중장비 시스템이다

   1. 작업의 구조화: 공방은 단순히 한 사람이 일하는 아늑한 공간이 아니라 작업을 수행하기 위한 강력한 시스템이다.
   2. 신호에 반응: 공방은 사람들이 작업 공간과 결과물을 어떻게 사용하는지에 대한 신호에 반응하며 형태를 바꾼다.
   3. 사람과 산출물의 근접성: 공방은 사람과 작업 공간, 생산된 결과물 사이에 매우 가까운 상호작용 루프를 만든다.

2. 소프트웨어 시스템도 아이디어를 코드로 바꾸는 공방이어야 한다

   1. 빌더의 정의 확대: 빌더는 전통적인 개발자에 한정되지 않고 소프트웨어를 만들고 싶은 비개발자까지 포함하도록 넓어지고 있다.
   2. 진지한 생산 시스템: 개발자 도구를 오래 만든 사람은 아이디어를 코드로 바꾸는 데 필요한 구조와 지원을 설계할 수 있다.
   3. 프리미티브 공개: 플랫폼은 도예가의 작업대와 절차처럼 에이전트가 실제 세계의 사건에 반응하고 사람의 목표를 실행할 수 있는 프리미티브를 제공해야 한다.

9. 에이전트 기반 소프트웨어 공방의 운영 원칙

Safia Abdalla가 제시한 생산 시스템은 이벤트 반응, 관찰 가능성, 지속적 개선, 비용 효율성을 통해 사람의 반복 노동을 줄이고 더 많은 사람이 소프트웨어를 만들게 한다.

9.1. 현실 이벤트에 반응하는 자동화

1. 에이전트는 실제 사건을 작업 신호로 받아들여야 한다

   1. 이벤트 기반 자동화: 플랫폼은 에이전트가 현실 세계의 이벤트에 반응하는 자동화를 구현하도록 해야 한다.
   2. 공방의 비유: 가마가 잘못 작동하거나 손잡이가 깨지는 사건에 도예가가 대응하듯, 소프트웨어 시스템도 문제 이벤트에 맞춰 후속 작업을 시작해야 한다.

2. 자동화는 사전 입력된 일회성 명령을 넘어선다

   1. 운영 상황 반응: 에이전트는 미리 정해진 프롬프트만 실행하지 않고 작업 중 발생하는 오류와 변화에 반응해야 한다.
   2. 워크플로 연결: 이벤트는 조사·수정·검증·사람에게 알리기 같은 다음 단계로 연결되어야 한다.

9.2. 관찰 가능성과 지속적 개선

1. 관찰 가능성은 좋은 공방의 필수 조건이다

   1. 작업 방식 확인: 도예가는 사람들이 자신의 공간에서 일하는 방식을 지켜보고 시간이 지나면서 프로세스를 다듬었다.
   2. 시스템 내부 확인: 에이전트 시스템도 무엇이 일어나는지 살펴보고 작업 흐름과 결과를 점검할 수 있어야 한다.
   3. 무료로 생기지 않는 특성: 관찰 가능성은 자동으로 주어지지 않으므로 플랫폼이 처음부터 검사와 추적 기능을 갖춰야 한다.

2. 워크스페이스는 목표와 결과에 맞춰 스스로 개선되어야 한다

   1. 정적 시스템 거부: 작업 공간은 한 번 정하면 영원히 변하지 않는 정적 구성 요소가 아니다.
   2. 목표 적응: 워크스페이스는 그 안에서 일하는 사람들의 목표와 만들어지는 제품에 맞춰 자신을 수정해야 한다.
   3. 피드백 반영: 운영 신호와 산출물의 품질은 다음 프로세스 변경을 결정하는 피드백이 되어야 한다.

9.3. 비용 효율성과 품질의 동시 달성

1. 생산 시스템은 불량 산출물을 줄여야 한다

   1. 도예의 불량 감소: 공방은 반대편에서 나오는 깨진 머그컵의 수를 줄여야 한다.
   2. 소프트웨어 버그 감소: 에이전트 공방은 결과물로 나오는 버그가 있는 소프트웨어의 양을 줄여야 한다.

2. 품질 개선은 토큰 비용을 무시할 수 없다

   1. 비용 관리: 시스템은 품질을 높이면서도 과도한 컴퓨트와 토큰을 사용하지 않아야 한다.
   2. 효율적 검증: 관찰과 리뷰 구조는 필요한 검증을 제공하되 비용 대비 효과가 높아야 한다.

10. 최종 목표: 고역을 줄이고 더 많은 사람이 만들게 하기

에이전트 플랫폼의 공통 목표는 버그 재현과 운영 모니터링 같은 고된 일을 반복 가능하고 이전 가능한 구조로 바꿔, 기술적 배경이 적은 사람도 진지한 소프트웨어를 출시하게 하는 데 있다.

10.1. 제거해야 할 개발의 반복 노동

1. 에이전트는 토일(toil)과 고역을 구조화한다

   1. 버그 재현의 어려움: 버그를 재현하는 일은 개발자가 반복적으로 겪는 대표적인 고역이다.
   2. 프로덕션 모니터링: 운영 시스템을 감시하는 일도 어렵고 지속적인 주의가 필요한 작업이다.
   3. 반복 가능한 시스템: 플랫폼은 이런 일을 매번 새로 해결하지 않도록 절차와 에이전트 자동화를 구조화해야 한다.

2. 구조는 비기술 직군에게도 이전되어야 한다

   1. 전달 가능한 방법론: 한 팀이 만든 문제 해결 구조는 다른 팀과 비기술적 역할의 사람에게 전달될 수 있어야 한다.
   2. 빌더의 대중화: 필요한 인프라와 가드레일이 갖춰지면 비개발자도 진지한 소프트웨어를 출시하는 빌더가 될 수 있다.

10.2. Warp가 남긴 실행 메시지

1. Warp는 에이전트·개발자·AI의 다음 작업을 준비한다

   1. 공유된 철학: Warp의 다음 작업은 에이전트, 개발자, AI를 연결하는 엔지니어링 철학에 기반한다.
   2. 관심 있는 빌더의 참여: 이런 견고하고 신뢰할 수 있는 시스템 구축에 관심이 있는 사람은 Warp의 부스에서 팀과 더 이야기할 수 있다.

2. Safia Abdalla는 후속 소통 경로를 열어두었다

   1. 현장 부스: Safia Abdalla는 Warp 부스 UG 20에서 참석자와 대화할 수 있다고 안내했다.
   2. 온라인 연락: Safia Abdalla는 소셜 미디어와 GitHub에서 Captain Sophia라는 이름을 사용하며, 개인 사이트에서 이메일 주소를 찾을 수 있다고 말했다.

주요 발언 모음

“정말 좋은 개발자 도구는 개발자가 있는 곳에서 만나고, 개발자와 함께 성장한다.”

“플랫폼은 복잡성이 사용자에게 도달하기 전에 그 복잡성을 떠안아야 한다.”

“실제 엔지니어링 작업은 하나의 프롬프트 안에 거의 들어맞지 않는다.”

“좋은 API와 SDK는 사람들이 그 위에 만들 수 있게 하며, 사용자를 우리의 UI나 특정 경험에 가두지 않는다.”

“에이전트가 구조와 맥락을 제공하면 누구나 자신의 의도를 구현으로 번역하는 데 참여할 수 있다.”

“워크숍은 한 사람을 위한 아담한 작업 공간이 아니라 일을 수행하기 위한 중장비 시스템이다.”

“우리가 지향하는 목표는 소프트웨어 프로세스에서 고역과 반복 노동을 제거해 더 많은 사람이 만들 수 있게 하는 것이다.”

핵심 데이터 & 수치

• 8년: Safia Abdalla가 개발자 도구를 만들어 온 기간이다.
• 약 3개월 전: Warp가 발표 시점 기준으로 오픈소스 전환을 결정한 시점이다.
• GitHub 스타 약 2만 → 6만 이상: Warp 오픈소스 전환 뒤 저장소의 관심도가 급증한 규모다.
• 수천 개의 PR: 오픈소스 전환 후 Warp 저장소에 유입된 기여 규모다.
• 수백 명의 기여자: Warp를 오래 사용해 온 커뮤니티 구성원을 포함한 참여자 수다.
• 수십 명의 견습생·하루 수백 개의 머그컵: 도예가가 공방 시스템을 확장해 달성한 생산 규모다.
• UG 20: Safia Abdalla가 참석자에게 안내한 Warp 부스 위치다.

결론 및 시사점

1. 플랫폼 설계: 클라우드 에이전트 플랫폼은 샌드박스·호스팅·하네스·오케스트레이션의 복잡성을 사용자에게 드러내지 않으면서도 각각을 API 프리미티브로 열어야 한다.
2. 워크플로 존중: 개발자 도구는 셸·언어·하네스·리뷰 프로세스의 기존 선호를 보존하고, 업무가 복잡해질 때 그 위에 성장 경로를 제공해야 한다.
3. 멀티에이전트 품질: 조사·구현·검증을 분리하고 서로 다른 모델과 하네스를 활용하면 한 에이전트의 편향을 줄이는 적대적 검증 루프를 만들 수 있다.
4. 인간 참여: 에이전트는 사람을 리뷰 루프에서 제거하기보다 저신호 이슈와 반복 검토를 먼저 처리해 사람이 고품질 작업에 집중하게 해야 한다.
5. 오픈소스 운영: 이슈 맥락화·추가 질문·명세·구현·리뷰를 하나의 구조로 연결하면 커뮤니티의 아이디어가 제품 변경으로 이어지는 경로가 명확해진다.
6. 비개발자 빌더: 가드레일과 도메인 맥락을 제공하면 구현자가 아니었던 사용자도 자신의 문제와 의도를 소프트웨어로 만들 수 있다.
7. 공방형 시스템: 소프트웨어 생산 시스템은 머그컵 공방처럼 세부 품질 기준, 재작업 지점, 관찰, 이벤트 대응을 갖춘 살아 있는 작업 공간이어야 한다.
8. 지속적 개선: PR과 실제 사용 사례를 에이전트 개선 루프에 다시 넣으면 SDLC 전체가 운영 경험에 맞춰 진화한다.
9. 운영 자동화: 버그 재현·프로덕션 모니터링 같은 토일을 이벤트 기반 자동화와 관찰 가능한 워크플로로 바꾸면 더 많은 사람이 안정적으로 소프트웨어를 출시할 수 있다.
10. 비용과 품질의 균형: 에이전트 시스템은 버그와 불량 결과를 줄이면서 토큰과 컴퓨트 비용을 통제해야 실전적인 생산 시스템이 된다.

핵심 요약 (20줄)

Safia Abdalla는 개발자 도구가 사용자의 현재 워크플로를 존중하고 작업의 복잡도 변화에 맞춰 성장해야 한다고 주장한다.

개발자 도구는 한 사람의 생산성을 높이는 데서 그치지 않고 세상에 존재하는 좋은 소프트웨어의 양을 누적적으로 늘린다.

Warp 터미널은 개발자가 익숙한 커맨드라인에서 출발해 로컬 AI 에이전트와 클라우드 실행으로 확장됐다.

노트북은 장시간 실행과 다양한 제약을 감당하기 어려우므로 에이전트 작업은 클라우드로 이동한다.

클라우드 플랫폼은 인프라의 누수되는 복잡성을 사용자에게 전달하기 전에 내부에서 흡수해야 한다.

샌드박스는 개발자 컴퓨터와 격리된 클라우드 작업 공간으로서 에이전트가 안전하게 일을 수행하게 한다.

Oz 플랫폼은 관리형 호스팅과 자체 호스팅을 함께 제공해 팀의 보안·배포·인프라 선호를 수용한다.

멀티 하네스 지원은 Claude Code·Codex·사용자 정의 하네스의 선택권을 주면서 공통 상태와 산출물 경험을 유지한다.

실제 엔지니어링은 조사·계획·구현·검증으로 나뉘므로 하나의 프롬프트보다 여러 에이전트의 협업이 적합하다.

오케스트레이터 에이전트는 하위 에이전트의 메시지와 진행 상황을 조정해 사용자가 복잡한 연결 작업을 직접 처리하지 않게 한다.

Oz 플랫폼은 에이전트·컴퓨트·환경·아티팩트를 API로 공개해 사용자가 자체 도구와 경험을 조합하게 한다.

Warp의 비엔지니어링 팀은 SDK로 소셜 멘션 감정 분석과 응답 제안을 수행하는 Slack 봇을 만들었다.

Warp의 오픈소스 전환은 GitHub 스타를 약 2만 개에서 6만 개 이상으로 늘리고 수천 개의 PR을 불러왔다.

Warp 저장소의 에이전트는 이슈를 분류하고 코드베이스를 조사하며 모호한 요청에 질문을 던진다.

Warp의 모든 기여 PR은 에이전트 리뷰를 먼저 거치므로 사람은 고신호·고품질 변경에 집중할 수 있다.

PR과 코드 사례가 늘어날수록 에이전트가 개선되는 자기개선 루프는 SDLC의 품질을 높인다.

Safia Abdalla는 자동화만 강조하는 소프트웨어 공장보다 사람과 결과물의 상호작용을 살리는 도예가의 공방을 제안한다.

공방형 플랫폼은 이벤트 반응·관찰 가능성·지속적 개선·비용 효율성을 갖춘 살아 있는 작업 시스템이어야 한다.

버그 재현과 프로덕션 모니터링 같은 토일을 구조화하면 비개발자도 도메인 지식으로 소프트웨어를 만들 수 있다.

에이전트 플랫폼의 최종 목표는 사람을 배제하는 자동화가 아니라 더 많은 사람이 안정적으로 아이디어를 코드로 바꾸게 하는 것이다.