Warp의 클라우드 에이전트 플랫폼은 어떻게 만들어졌을까요?

URL: https://www.youtube.com/watch?v=6SBCO0vg1UM 날짜: 2026-08-28 채널: Tech Bridge 원문 제목: [한영자막] Warp는 어떻게 클라우드 에이전트 플랫폼을 만들었을까요?

---

핵심 질문 / 이 영상이 다루는 핵심 논점

Warp는 로컬 터미널에서 출발해 AI 에이전트가 클라우드의 샌드박스에서 장시간 작업하고, 여러 하네스(harness)와 여러 에이전트를 조합하며, 그 모든 복잡성을 사용자가 직접 떠안지 않도록 하는 플랫폼으로 확장했다. ==좋은 개발자 도구는 개발자가 이미 일하는 자리에서 시작해 복잡성이 커질수록 함께 성장해야 하며, 궁극적으로는 사람의 의도를 반복 가능하고 관찰 가능하며 비용 효율적인 코드 생산 시스템으로 바꿔야 한다.==

• 개발자는 셸, 언어, 하네스, 코드 리뷰 절차처럼 자신만의 워크플로와 선호를 갖고 있으므로 도구는 이를 존중하면서도 새로운 작업 방식에 적응해야 한다.
• 클라우드 에이전트 플랫폼은 실행 환경, 보안과 인프라, 하네스, 상태 복원, 산출물, 멀티 에이전트 협업을 통합하되 그 내부의 지저분한 복잡성을 사용자에게 새지 않게 해야 한다.
• API와 SDK로 핵심 프리미티브를 공개하면 제품 UI의 의견에 사용자를 가두지 않고, 엔지니어가 아닌 동료도 Slack 봇 같은 자기 업무 도구를 만들 수 있다.
• Warp의 오픈소스 저장소에서는 에이전트가 이슈를 분류하고 맥락을 보강하며 구현과 리뷰까지 맡아, 사람은 신호가 높은 작업에 집중하는 구조를 실험하고 있다.
• 이를 단순한 ‘소프트웨어 공장’이라고 부르기보다, 장인이 공정을 설계하고 계속 개선하는 ‘공방(workshop)’으로 이해하면 사람과 시스템의 긴밀한 상호작용, 품질, 관찰 가능성의 중요성이 드러난다.

1. 개발자 도구를 만드는 이유와 출발점

1.1. 발표자의 경력과 문제의식

1. 개발자 도구는 사용자의 현재 위치에서 시작해야 한다
   1. 8년의 도구 개발 경험: Python과 데이터 과학 분야의 오픈소스에서 출발해 Jupyter Notebook 핵심 팀에서 일했고, interact 프로젝트의 유지관리자(maintainer)를 맡았다.
   2. 웹 개발자용 플랫폼 경험: Microsoft에서는 웹 개발자를 위한 API와 SDK를 만드는 일을 이어 갔다.
   3. 현재의 초점: Warp에서 AI 에이전트를 클라우드로 가져오는 일을 하며, 개발 도구가 사람의 실제 작업 방식과 어떻게 맞물려야 하는지 고민한다.
2. 좋은 도구는 워크플로에 맞고 변화에 따라 성장한다
   1. 매일 쓰는 도구는 사용자가 이미 가진 워크플로를 수용해야 한다.
   2. 작업의 복잡도와 성격이 바뀌면 도구도 그 변화에 맞춰 충분히 적응해야 한다.
   3. 특정 방식으로 일하라고 사용자를 강제로 재교육하기보다, 사용자가 있는 곳에서 출발해 능력을 확장해 주는 편이 지속적인 사용성을 만든다.

1.2. 개발자 도구의 파급 효과

1. 한 명의 생산성이 소프트웨어 생태계 전체에 누적된다
   1. 개발자나 빌더가 훌륭한 일을 하도록 돕는 소프트웨어를 만들면, 세상에 존재하는 좋은 소프트웨어의 양을 증폭할 수 있다.
   2. 개발자 도구의 개선은 한 사용자의 편의에 그치지 않고 그 사용자가 만들어 내는 모든 결과물에 연쇄적으로 영향을 준다.
2. 개인의 선호를 존중해야 한다
   1. 사람마다 선호하는 셸(shell), 프로그래밍 언어, 하네스, 리뷰 프로세스가 다르다.
   2. 워크플로와 선호에 적응하는 도구는 더 즐겁게 사용할 수 있고, 그 도구를 이용해 소프트웨어를 만드는 일도 더 즐거워진다.
   3. 반복해서 쓰는 도구는 단순한 외부 유틸리티가 아니라 사용자가 생각하고 만드는 방식의 일부가 된다.

2. Warp가 로컬 터미널에서 클라우드 에이전트로 확장된 과정

2.1. AI 이전과 로컬 에이전트의 등장

1. Warp 터미널은 기존 커맨드라인 워크플로에 들어갔다
   1. AI 이전에는 Warp가 개발자들이 익숙하게 사용하던 커맨드라인 작업 방식에 맞춰진 터미널이었다.
   2. 기존 사용 습관을 버리게 하지 않고 익숙한 표면 위에 새로운 능력을 더하는 방식이 출발점이었다.
2. AI가 개발자에게 새로운 로컬 도구 층을 열었다
   1. AI가 개발자 도구에 들어오면서 컴퓨터에서 바로 사용할 수 있는 도구의 종류가 급격히 늘었다.
   2. 개발자들은 터미널, IDE, 에디터 안에서 에이전트형 코딩(agentic coding) 패턴을 사용하기 시작했다.
   3. 자연어로 문제를 설명하고 에이전트가 명령 실행, 코드 작성, 수정 같은 작업을 수행하는 흐름이 기존 개발 환경에 들어왔다.

2.2. 노트북의 한계와 클라우드의 필요

1. 로컬 컴퓨터의 자원과 실행 시간이 한계를 만들었다
   1. 한동안 에이전트 작업을 노트북에서 처리할 수 있었지만, 점점 더 오래 실행되는 작업이 필요해졌다.
   2. 작업마다 메모리, CPU, 네트워크, 보안, 지속 시간 등 제약 조건이 달라졌고, 노트북이 모든 작업을 감당하기 어려워졌다.
   3. 결국 에이전트가 더 장시간 작업하고 서로 다른 제약에 맞춰 실행되려면 클라우드가 필요해졌다.
2. 클라우드는 능력과 함께 복잡성을 가져온다
   1. 무엇이든 클라우드로 보내는 순간 인프라의 여러 관심사를 다뤄야 한다.
   2. 컴퓨트, 격리, 배포, 보안, 상태, 모니터링처럼 개발자가 직접 관리해야 할 지저분한 스택이 생긴다.
   3. 여기서 ‘우리’는 클라우드 에이전트 플랫폼을 만드는 개발자 도구 팀을 뜻하며, 플랫폼이 이 복잡성을 사용자에게 전달하지 않고 먼저 흡수해야 한다.

3. 복잡성을 사용자에게 도달하기 전에 흡수하는 플랫폼

3.1. 샌드박스가 실행 장소를 추상화한다

1. 에이전트는 클라우드의 격리 환경에서 일한다
   1. 개발자의 컴퓨터에서 실행되지 않는 에이전트에는 개발자처럼 작업할 장소가 필요하다.
   2. 그 장소가 샌드박스(sandbox)이며, 클라우드 안에서 에이전트가 작업을 수행하는 격리된 환경이다.
   3. 샌드박스는 에이전트가 파일을 만들고 명령을 실행하며 결과물을 남길 수 있는 실행 기반이 된다.
2. 첫 번째 직관은 관리형 샌드박스였다
   1. 초기 클라우드 에이전트 플랫폼은 자체 호스팅(self-hosted) 샌드박스를 제공해 사용자가 쉽게 시작하도록 하려 했다.
   2. 사용자는 컴퓨트가 어디에 있고 어떻게 준비되는지 고민하지 않고 바로 작업을 시작할 수 있었다.
   3. 이는 진입 장벽을 낮추는 간단한 온램프(on-ramp)였다.

3.2. 관리형 호스팅과 셀프 호스팅의 공존

1. 진지한 팀은 이미 자기 인프라를 운영한다
   1. 실제 팀은 자체 인프라를 관리하고, 상호작용해야 하는 개발 박스(dev box)나 다른 내부 실행 환경을 갖고 있을 가능성이 높다.
   2. 따라서 플랫폼이 제공하는 관리형 환경만으로는 보안 요구사항, 배포 방식, 팀의 워크플로와 선호를 충족하기 어렵다.
2. 사용자가 가져온 인프라에서도 에이전트를 실행한다
   1. 플랫폼은 관리형 호스팅뿐 아니라 셀프 호스팅을 지원하도록 확장됐다.
   2. 사용자는 자신의 보안 경계와 배포 관행을 유지하면서 에이전트 워크로드를 실행할 수 있다.
   3. 실행 위치의 선택과 그 차이를 플랫폼의 동일한 동작 모델 안에 넣어, 사용자가 인프라 세부사항을 일일이 조정하지 않아도 되게 한다.

4. 멀티 하네스로 선호와 일관성을 함께 지키기

4.1. 하네스 선택권을 플랫폼에 포함한다

1. 하네스는 개인의 작업 방식을 결정하는 도구다
   1. 개발자는 어떤 AI 하네스를 로컬에서 쓸지에 대해 강한 선호를 가질 수 있다.
   2. 현장에 “Cloud Code(자막 표기)”를 선호하는 사람이 있는지, Codex를 쓰는지, 전혀 다른 도구를 쓰는지 묻자, 서로 다른 선택이 공존한다는 농담 섞인 반응이 나온다.
   3. 중요한 점은 특정 하네스 하나를 정답으로 정하지 않고, 사람들이 실제로 일하는 곳을 지원하는 것이다.
2. 멀티 하네스는 작업에 맞는 도구를 고르게 한다
   1. 여러 하네스를 통합하면 개인의 선호를 수용할 수 있다.
   2. 동시에 작업 성격에 따라 가장 적합한 하네스와 모델을 선택할 수 있다.
   3. Warp Zone 하네스를 포함해 사용자가 가져오는 하네스도 같은 플랫폼에 연결할 수 있다.

4.2. 유연성을 구조와 가드레일 안에 둔다

1. 유연성만 억지로 넣으면 경험이 파편화된다
   1. 플랫폼에 하네스를 무제한으로 끼워 넣기만 하면 하네스마다 클라우드 사용 경험이 달라질 위험이 있다.
   2. Codex를 쓸 때와 사용자가 직접 만든 커스텀 하네스를 쓸 때의 동작과 결과가 제각각이면 플랫폼의 일관성이 사라진다.
2. 플랫폼 네이티브 경험을 공통 구조로 제공한다
   1. 하네스는 서로 달라도 플랫폼이 제공하는 구조와 가드레일(guardrails)을 따라야 한다.
   2. 대화 상태(conversation state)를 저장하고 나중에 복원(rehydrate)하는 기능을 공통 방식으로 제공한다.
   3. 에이전트가 만드는 산출물도 같은 방식으로 다룬다.
   4. 산출물에는 PR, 이슈, 새로 생성된 파일 등이 포함되며, 어떤 하네스가 만들었는지와 무관하게 플랫폼 안에서 일관되게 접근할 수 있어야 한다.

5. 한 번의 프롬프트를 넘어선 멀티 에이전트 오케스트레이션

5.1. 실제 소프트웨어 작업은 한 프롬프트에 들어가지 않는다

1. 하나의 에이전트로 모든 문제를 해결하려는 기대는 비현실적이다
   1. 한 번의 프롬프트를 보내고 소프트웨어의 모든 문제를 해결할 수 있다면 좋겠지만, 실제 엔지니어링은 거의 그렇게 작동하지 않는다.
   2. 문제를 조사하고 해결책을 계획하는 일, 구현하는 일, 결과를 검증하는 일은 서로 다른 종류의 판단을 요구한다.
2. 역할을 나누면 더 견고한 흐름을 만들 수 있다
   1. 첫 번째 에이전트는 문제를 조사하고 해결책을 계획한다.
   2. 두 번째 에이전트는 계획을 코드로 구현한다.
   3. 세 번째 에이전트는 구현 결과를 검증한다.
   4. 각 에이전트가 서로 다른 하네스와 모델을 사용하면 상호 반박적인(adversarial) 검토와 더 견고한 결과를 기대할 수 있다.

5.2. 프롬프트와 API라는 두 가지 오케스트레이션 경로

1. 프롬프트 기반 오케스트레이션은 내부 복잡성을 숨긴다
   1. 사용자는 /orchestrate 같은 명령을 호출하거나 프롬프트로 여러 하위 에이전트에 작업을 위임하라고 요청할 수 있다.
   2. 오케스트레이터 에이전트가 하위 에이전트와 통신하고, 메시지를 중재하며, 각 작업의 진행 상황을 추적한다.
   3. 사용자는 단일 프롬프트만으로 이 복잡한 협업을 시작하고 뒤에서 벌어지는 조정 작업을 직접 관리하지 않는다.
2. API 기반 오케스트레이션은 조합 가능한 기반을 만든다
   1. 표면에 드러난 모든 핵심 기능을 API로 노출해, 부모 에이전트에 연결된 하위 에이전트를 사용자가 제공한 설정으로 실행할 수 있게 한다.
   2. API의 의미는 단순히 UI 기능을 원격 호출하는 데 있지 않고, 플랫폼의 프리미티브를 다른 제품과 도구가 그 위에 쌓을 수 있게 공개하는 데 있다.
   3. 훌륭한 API와 SDK는 사용자를 특정 UI나 플랫폼 제작자의 경험 설계에 가두지 않는다.
   4. 여러 프리미티브를 조합(composability)하면 원래 플랫폼이 예상하지 못한 새로운 경험도 만들 수 있다.
3. 핵심 스택 전체에 API를 제공한다
   1. 에이전트와 하위 에이전트를 시작하는 API를 제공한다.
   2. 에이전트가 실행되는 환경과 컴퓨트를 관리하는 API를 제공한다.
   3. 에이전트가 만든 아티팩트와 결과물을 다루는 API를 제공한다.
   4. 실행, 환경, 산출물이라는 주요 구성요소를 조합 가능한 공통 기반으로 만든다.

6. API와 SDK가 사내 비개발자의 업무 도구가 되는 방식

6.1. 개발팀 밖에서도 새로운 에이전트 경험을 만든다

1. Warp 내부의 비엔지니어링 팀이 SDK를 활용한다
   1. API와 SDK가 공개되자 Warp의 엔지니어가 아닌 동료들도 그 위에 커스텀 Slack 봇을 만들 수 있었다.
   2. 이는 플랫폼의 사용처가 공식 UI에만 머무르지 않고 각 팀의 구체적인 업무로 확장된다는 사례다.
2. 개발자 관계 팀의 소셜 멘션 관리
   1. Developer Relations 팀은 소셜 멘션을 관리하는 도구를 직접 구축했다.
   2. 트윗, Reddit 게시물 등 새로운 언급이 들어오면 에이전트가 이를 수집한다.
   3. 에이전트는 감정 분석(sentiment analysis)을 수행하고 사용자가 무엇을 원하는지 파악한다.
   4. 그 결과를 바탕으로 소셜 미디어 팀이 원래 트윗이나 Reddit 게시물에 답할 수 있는 응답 초안을 제안한다.
   5. 사람이 최종적으로 문맥을 판단하고 응답하는 업무 흐름을 유지하면서, 반복적인 수집·분류·초안 작성은 에이전트가 담당한다.

6.2. 제품 문의와 경쟁 조사로 확장된다

1. 내부에서는 제품이 어떻게 동작하는지에 대한 질문에 답하는 도구도 만들어졌다.
2. 경쟁 제품 조사를 돕는 도구도 만들어졌다.
3. 그 밖에도 팀마다 필요로 하는 다양한 내부 에이전트 경험이 등장했다.
4. 플랫폼의 프리미티브가 충분히 잘 노출되면 엔지니어만이 아니라 도메인 업무를 아는 사람이 자기 문제를 해결하는 자동화를 만들 수 있다.

7. 오픈소스 전환과 에이전트가 참여하는 개발 생명주기

7.1. Warp의 규모 변화

1. 터미널에서 에이전트형 개발 환경으로 성장했다
   1. Warp는 처음에는 터미널로 시작했다.
   2. 이후 에이전트형 개발 환경(agentive development environment)으로 확장됐다.
   3. 약 3개월 전 오픈소스로 전환했고, 오래 기다려 온 사용자들에게 큰 성공으로 받아들여졌다.
2. 오픈소스 전환 직후의 지표
   1. GitHub 스타는 약 2만 개에서 6만 개 이상으로 급증했다.
   2. 수천 개의 PR이 들어왔다.
   3. 수백 명의 기여자가 참여했으며, 그중에는 오랫동안 플랫폼을 사용하다가 처음으로 내부에 코드를 기여할 기회를 얻은 사람들도 있었다.

7.2. 에이전트를 단순 코드 생성기가 아닌 프로세스 참여자로 만든다

1. 목표는 PR을 무작정 생산하는 자동화가 아니다
   1. 에이전트가 코드만 작성해 PR을 발행하게 하는 방식은 오픈소스 저장소의 운영 문제를 해결하지 못한다.
   2. 핵심은 이슈 분류, 맥락 보강, 구현, 리뷰라는 저장소의 구조화된 절차에 에이전트가 의미 있게 참여하는 것이다.
   3. 사람은 이 루프에서 빠지는 것이 아니라, 에이전트가 정리한 맥락과 결과를 바탕으로 중요한 판단을 계속 내린다.
2. 새 이슈는 자동 트리아지된다
   1. Warp 오픈소스 저장소에서 버그 신고나 기능 요청으로 새 이슈를 등록하면 에이전트가 자동으로 작동한다.
   2. 코드베이스 전체와 저장소 안의 관련 맥락을 조사해 요청자가 실제로 제안하는 것이 무엇인지 파악한다.
   3. 요청이 추상적이면 추가 정보를 얻기 위해 질문을 되묻는다.
   4. 이는 오픈소스에서 오랫동안 어려웠던 문제, 즉 문제를 제기한 사람이 수정에 필요한 세부사항을 충분히 주지 않아 작업이 명확해지지 않는 문제를 완화한다.
3. 명세·구현·리뷰를 연결한다
   1. 에이전트는 작업에 대한 초기 명세와 실행 계획을 작성할 수 있다.
   2. 구현을 수행할 수 있다.
   3. 기여된 모든 PR은 에이전트가 관리하는 리뷰 프로세스를 거친다.
   4. 여러 차례 반복 검토를 거친 뒤 에이전트가 PR을 승인해야 사람 리뷰어에게 알림이 간다.
   5. 그 결과 수천 개의 PR 중 사람이 직접 처리해야 하는 것은 신호가 높고 품질이 검증된 PR로 줄어든다.

7.3. 더 많은 사례를 통해 에이전트를 개선한다

1. 저장소에 PR과 코드 사례가 더 쌓일수록 에이전트를 개선한다.
2. 에이전트가 실제 문제와 기여 코드를 처리한 경험을 다음 판단과 리뷰 기준에 반영한다.
3. 이런 자기개선 루프(self-improvement loop)가 소프트웨어 개발 생명주기(SDLC)를 전반적으로 향상시키는 중요한 방법이라고 본다.
4. 오픈소스 전환은 단순히 코드 공개에 그치지 않고, 대규모 참여를 수용하는 구조화된 개발 시스템을 검증하는 계기가 됐다.

8. ‘소프트웨어 공장’에서 ‘소프트웨어 공방’으로

8.1. 에이전트가 의도를 구현으로 번역한다

1. 구조와 맥락이 참여의 문턱을 낮춘다
   1. 에이전트가 이슈와 PR에 구조와 맥락을 부여하면 많은 사람이 자기 아이디어나 버그 신고를 실제 제품까지 가져갈 수 있다.
   2. 에이전트는 사용자의 의도를 구현으로 번역하는 중간 계층이 된다.
2. 가장 흥미로운 의도는 개발자 밖에서도 나온다
   1. 소프트웨어를 흥미로운 방식으로 사용하는 사람은 그것을 직접 만드는 사람과 다를 수 있다.
   2. 코드를 작성하지 않더라도 특정 분야의 도메인 지식을 가진 사람이 더 좋은 문제 정의와 목표를 제시할 수 있다.
   3. 개발자가 비개발자를 위한 도구를 만드는 대부분의 상황에서는, 이 도메인 지식과 구현 능력 사이의 간극이 특히 크게 나타난다.
   4. 구조와 가드레일을 제공하면 비개발자도 필요한 인프라의 도움을 받아 진지한 소프트웨어를 출시할 수 있다.

8.2. ‘software factory’라는 말에 대한 반론

1. 자동화 담론의 한계
   1. 사람들은 소프트웨어가 만들어지는 과정을 자동화하고 작업 시스템을 제공한다는 의미로 ‘소프트웨어 공장(software factory)’이라는 말을 자주 사용한다.
   2. 그러나 이 표현은 사람의 역할을 지워 버리는 느낌이 있고, 무엇이 중요한지 충분히 전달하지 못한다.
   3. “이 안에 사람은 어디에 있는가?”라는 질문이 남는다.
2. 농산물 시장에서 만난 도예가의 머그컵
   1. 발표자는 약 2년 전 여름 농산물 시장에서 산 머그컵을 예로 든다.
   2. 부스의 도예가는 자신이 만든 일에 깊이 몰입한 사람처럼 보였고, 머그컵의 세부를 열정적으로 설명했다.
   3. 손잡이의 곡선은 사람마다 다른 손에 맞도록 설계됐다.
   4. 손잡이 위쪽에는 엄지를 올려둘 수 있는 작은 딤플(dimple)을 만들었고, 그것을 컵의 핵심 인체공학적 디테일로 여겼다.
   5. 컵이 넘칠 때 물이 옆면으로 바로 흘러내리지 않도록 윗부분에 유약을 발라 넘친 액체를 받아내게 했다.
   6. 작은 형태와 사용성까지 집요하게 생각하고 직접 빚은 결과물이 단순한 그릇 이상의 의미를 갖는다.

8.3. 장인의 공방은 반복 가능한 시스템이다

1. 작업장의 구성까지 설계한다
   1. 도예가는 컵을 몇 개 만들고 작업장에 도예가가 몇 명 있는지 묻자 작업장 구성에 더 신이 나서 설명했다.
   2. 머그컵의 구성요소별로 서로 다른 작업 스테이션을 배치했다.
   3. 점토를 조달하고 미리 준비하는 구체적인 절차를 갖췄다.
   4. 컵의 각 구성요소에 검증 절차를 넣었다.
   5. 예를 들어 딤플 크기가 정확하지 않으면 어느 단계로 되돌아가 공정을 다시 시작할지 정해 두었다.
2. 아이디어를 품질 있는 결과로 확장한다
   1. 장인은 컵 하나에만 생각을 쏟은 것이 아니라 완성도 높은 컵이 계속 생산되도록 작업장 자체를 설계했다.
   2. 그 시스템을 수십 명의 견습생이 따를 수 있게 확장했다.
   3. 하루에 손으로 만든 머그컵 수백 개를 생산하는 규모까지 도달했다.
   4. 공방은 한 사람의 조용한 작업 공간이 아니라, 아이디어를 반복 가능하게 실제 결과물로 바꾸는 고강도 시스템이다.
3. 공방은 신호에 반응하며 변한다
   1. 작업장과 결과물을 사용하는 사람 사이에는 가까운 상호작용 루프가 있다.
   2. 사람들이 작업 공간에서 어떻게 일하고 제품을 어떻게 사용하는지 관찰하면 공정에 대한 신호를 얻을 수 있다.
   3. 공방은 고정된 생산 라인이 아니라, 그 신호에 반응하고 작업 방식과 결과물을 함께 개선하는 유연한 시스템이다.

9. 사람이 아이디어를 코드로 만드는 에이전트 작업 시스템

9.1. 현실의 사건에 반응하는 자동화

1. 에이전트가 현실에서 발생하는 이벤트에 반응하는 자동화를 구현할 수 있어야 한다.
2. 도예 작업장에서 가마가 예상과 다르게 작동하거나 손잡이가 깨지는 것처럼, 소프트웨어 작업에서도 외부 사건에 따라 다음 행동이 달라진다.
3. 이벤트를 감지하고 적합한 에이전트를 실행하며, 결과를 다음 단계로 넘기는 구조가 사람이 일하는 공간의 반응성을 소프트웨어 시스템에 옮긴다.

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

1. 관찰 가능성(observability)이 기본 조건이다
   1. 도예가는 사람들이 작업장에서 어떻게 일하는지 보고 공정을 다듬었다.
   2. 이런 개선은 저절로 일어나지 않으므로 시스템을 실제로 들여다보고 검사할 수 있어야 한다.
   3. 에이전트의 실행, 상태, 메시지, 산출물, 실패 지점을 추적할 수 있어야 공정의 어느 부분을 바꿀지 판단할 수 있다.
2. 작업 공간은 목표에 맞춰 스스로 진화해야 한다
   1. 작업 공간은 한 번 설정한 뒤 영원히 변하지 않는 정적 구성요소가 아니다.
   2. 사람들이 무엇을 하려는지와 시스템이 어떤 제품을 만들어 내는지에 따라 공정을 수정해야 한다.
   3. 실제 사용에서 얻은 신호를 다음 자동화, 가드레일, 리뷰 기준에 반영하는 루프가 필요하다.

9.3. 품질과 비용의 균형

1. 불량 결과를 줄인다
   1. 도예 공방이 깨진 머그컵의 수를 줄이려 하듯, 소프트웨어 시스템은 최종 산출물의 버그를 줄여야 한다.
   2. 에이전트를 많이 붙이는 것 자체가 목표가 아니며, 신뢰할 수 있는 결과와 반복 가능한 품질이 기준이다.
2. 토큰과 인프라 비용을 통제한다
   1. 품질을 높이기 위해 무제한으로 모델 호출과 토큰을 소비할 수는 없다.
   2. 너무 많은 비용을 쓰지 않으면서 버그가 있는 소프트웨어를 줄이는 공정을 설계해야 한다.
   3. 실행 환경, 모델, 하네스, 검증 단계를 적절히 조합해 품질·속도·비용 사이의 균형을 맞춘다.
3. 공통 목표는 반복 노동을 제거하는 것이다
   1. 이 모든 원칙은 소프트웨어 과정의 고역(toil)과 단순 반복(drudgery)을 줄이는 하나의 목표로 수렴한다.
   2. 버그를 재현하는 어려움과 운영 중인 시스템을 모니터링하는 어려움은 대표적인 고역이다.
   3. 이러한 일을 반복 가능하고 다른 사람에게 이전 가능한 구조로 만들면, 기술 역할이 아닌 사람도 소프트웨어를 만드는 과정에 참여할 수 있다.

10. 마무리 안내

10.1. 더 이야기할 수 있는 경로

1. 이런 방식으로 누구나 소프트웨어를 출시할 수 있는 견고하고 신뢰할 수 있는 시스템을 만드는 일에 관심이 있다면 Warp 부스 UG 20에서 발표자와 팀을 만날 수 있다.
2. 발표자는 소셜 미디어와 GitHub, Twitter에서 Captain Sophia라는 이름으로 활동한다.
3. 개인 사이트에서 이메일 주소를 확인해 직접 연락할 수도 있다.

10.2. 발표의 마지막 메시지

1. 에이전트, 개발자, AI를 둘러싼 다음 작업을 이끌고 있는 엔지니어링 철학이 참석자에게 흥미로운 배움이 되기를 바란다는 말로 마무리한다.
2. 발표가 끝난 뒤 박수가 이어진다.

주요 발언 모음

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

“플랫폼은 복잡성이 사용자에게 도달하기 전에 먼저 떠안아야 합니다.”

“사람은 자신의 선호를 아주 중요하게 여깁니다. 셸, 언어, 하네스, 리뷰 프로세스가 모두 다를 수 있습니다.”

“실제 엔지니어링 작업은 하나의 프롬프트 안에 들어가는 경우가 거의 없습니다.”

“훌륭한 API와 SDK는 사용자가 우리의 UI나 특정 경험에 갇히지 않고 그 위에 무언가를 만들게 합니다.”

“에이전트는 단순히 코드를 작성해 PR을 보내는 것이 아니라, 이슈를 분류하고 맥락을 제공하고 구현하고 리뷰하는 구조에 의미 있게 참여해야 합니다.”

“소프트웨어 공장이라는 말에는 사람이 어디에 있는지 드러나지 않습니다.”

“공방은 아이디어를 실제 존재하는 결과물로 바꾸는 무겁고 강력한 작업 시스템입니다.”

“이 시스템의 공동 목표는 소프트웨어 과정에서 고역과 단순 반복을 제거해 더 많은 사람이 만들 수 있게 하는 것입니다.”

핵심 데이터 & 수치

• 개발자 도구를 만든 경력: 약 8년.
• 오픈소스 전환 시점: 발표 시점 기준 약 3개월 전.
• GitHub 스타: 약 20,000개에서 60,000개 이상으로 증가.
• 오픈소스 전환 후 유입: 수천 개의 PR과 수백 명의 기여자.
• 도예 공방의 확장 사례: 수십 명의 견습생과 하루 수백 개의 수제 머그컵.
• 전형적인 에이전트 개발 흐름: 조사·계획 에이전트 1개, 구현 에이전트 1개, 검증 에이전트 1개로 역할 분담.
• 플랫폼이 다루는 핵심 층: 에이전트·하위 에이전트 실행, 환경·컴퓨트 관리, 아티팩트·산출물 관리.

결론 및 시사점

1. 클라우드 에이전트 플랫폼의 핵심 경쟁력은 모델 하나가 아니라 실행 환경, 상태, 산출물, 하네스, 오케스트레이션, API를 일관된 프리미티브로 묶고 복잡성을 숨기는 데 있다.
2. 관리형 샌드박스는 빠른 시작을 제공하고 셀프 호스팅은 기업의 보안과 배포 현실을 수용하므로, 두 방식의 공존이 실제 팀을 위한 확장성의 조건이 된다.
3. 멀티 하네스는 선호를 존중하지만 공통 상태·아티팩트·가드레일을 통해 경험을 파편화하지 않아야 한다.
4. 멀티 에이전트는 조사, 구현, 검증을 분리하고 서로 다른 모델과 하네스를 활용할 때 단일 프롬프트보다 견고한 개발 루프를 만들 수 있다.
5. API와 SDK가 프리미티브를 충분히 공개하면 비개발자도 도메인 지식을 바탕으로 업무 자동화를 만들고, 아이디어를 실제 소프트웨어로 연결할 수 있다.
6. 오픈소스 운영에서 에이전트는 코드 생성기가 아니라 이슈 명확화, 명세, 구현, 반복 리뷰를 담당하는 프로세스 참여자이며, 사람은 높은 신호의 의사결정에 집중한다.
7. 소프트웨어 공방의 관점은 자동화의 양보다 공정의 관찰 가능성, 현실 이벤트에 대한 반응성, 지속적인 자기개선, 불량과 비용의 동시 절감을 강조한다.
8. 최종 목표는 사람을 생산 과정에서 밀어내는 것이 아니라 반복 노동을 덜어 더 많은 사람이 각자의 도메인 지식과 의도를 코드로 구현하게 하는 것이다.

핵심 요약 (20줄)

1. Warp는 로컬 터미널에서 출발해 AI 에이전트가 클라우드에서 장시간 작업하는 플랫폼으로 확장됐다.
2. 좋은 개발자 도구는 개발자가 현재 사용하는 워크플로에서 시작해 업무의 복잡도와 성격 변화에 맞춰 성장한다.
3. 개발자의 셸, 언어, 하네스, 리뷰 절차 선호를 존중하는 도구는 더 즐겁고 지속적으로 사용된다.
4. 개발자 도구의 생산성 향상은 사용자가 만드는 모든 소프트웨어로 퍼지는 누적 효과를 만든다.
5. 클라우드 에이전트에는 개발자처럼 일할 격리된 실행 장소인 샌드박스가 필요하다.
6. 관리형 호스팅은 빠른 시작을 돕고 셀프 호스팅은 팀의 보안, 배포, 인프라 요구를 수용한다.
7. 멀티 하네스는 다양한 선호를 허용하면서도 상태와 산출물을 공통 플랫폼 경험으로 묶어야 한다.
8. 실제 엔지니어링은 조사, 구현, 검증을 각각 맡는 여러 에이전트의 협업을 필요로 한다.
9. 프롬프트 기반 오케스트레이터는 하위 에이전트의 메시지와 진행 상황을 관리해 사용자에게 복잡성을 숨긴다.
10. API와 SDK는 에이전트 실행, 컴퓨트 관리, 환경 구성, 아티팩트 처리를 조합 가능한 프리미티브로 공개한다.
11. Warp의 비엔지니어링 팀은 SDK로 소셜 멘션을 분석하고 답변을 제안하는 커스텀 Slack 봇을 만들었다.
12. Warp는 터미널에서 에이전트형 개발 환경으로 성장한 뒤 약 3개월 전 오픈소스로 전환했다.
13. 오픈소스 전환 후 GitHub 스타는 약 2만 개에서 6만 개 이상으로 늘었고 수천 개의 PR과 수백 명의 기여자가 유입됐다.
14. 에이전트는 새 이슈의 코드베이스 맥락을 조사하고 추상적인 요청에는 추가 질문을 던져 문제를 명확히 한다.
15. 에이전트는 초기 명세와 구현을 돕고 모든 PR을 반복 검토해 사람에게 높은 신호의 작업만 전달한다.
16. 더 많은 PR과 코드 사례는 에이전트의 기준을 개선하는 자기개선 루프의 재료가 된다.
17. 소프트웨어 공장은 사람을 가리는 표현이지만 공방은 장인과 공정과 결과물의 상호작용을 함께 보여 준다.
18. 도예 공방처럼 소프트웨어 시스템도 이벤트에 반응하고 관찰되며 사용 신호에 따라 공정을 개선해야 한다.
19. 좋은 에이전트 시스템은 버그를 줄이면서도 토큰과 인프라 비용을 통제하는 반복 가능하고 비용 효율적인 공정이다.
20. 최종 목표는 고역과 단순 반복을 제거해 비개발자를 포함한 더 많은 사람이 아이디어를 신뢰할 수 있는 코드로 바꾸게 하는 것이다.