Inside the Team That Killed Mandatory Code Review — Quinn Slack, AMP

URL: https://www.youtube.com/watch?v=hvwtHZ5E27c 날짜: 2026-09-07 채널: Latent Space 영상 ID: hvwtHZ5E27c

자동 생성 영어 자막을 바탕으로 작성한 한국어 심층 노트다. 대화의 핵심 화자는 AMP의 Quinn Slack이며, 진행자는 Latent Space 호스트다.

---

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

==AI 에이전트가 충분히 신뢰할 만해지면, 소프트웨어 팀의 기본 단위는 ‘로컬에서 한 가지 작업을 하고 코드 리뷰를 기다리는 개발자’에서 ‘클라우드에서 여러 작업을 병렬 실행하고 결과에 책임지는 작은 팀’으로 바뀌는가?==

• AMP는 원격 실행 단위인 orb를 통해 에이전트·개발 서버·데스크톱을 클라우드에 묶고, 노트북을 닫은 뒤에도 여러 작업을 병렬로 실행한다.
• AMP 팀은 메인 브랜치에 들어가기 전의 의무적 코드 리뷰를 없앴다. 대신 높은 신뢰, 엔드투엔드 소유권, 관측 가능성, 빠른 롤백을 안전장치로 삼는다.
• 에이전트는 코드를 작성하는 도구를 넘어 임시 앱, 운영 배포, 로그·데이터베이스 모니터링, 마케팅 자동화까지 담당하는 범용 실행 계층이 된다.
• 소프트웨어의 설정 화면·통합 기능·SaaS 패키지는 에이전트와 코드로 대체되고, 개인화·포크·리믹스 가능한 ‘mini app’과 ‘jellyware’가 새로운 제품 단위가 될 수 있다.

이 대화의 결론은 특정 제품의 기능 소개보다 조직 운영 방식에 가깝다. AI 시대에는 오래 유지되는 레거시 경로를 보존하는 것 자체가 제품 경쟁력의 약점이 될 수 있으며, 변화에 동의하는 소수의 고신뢰 인력이 클라우드 에이전트와 함께 훨씬 넓은 범위의 일을 맡는 모델이 등장하고 있다는 주장이다.

1. AMP가 제품을 다루는 방식: 최전선에 남기 위해 기능을 죽인다

1.1. 원격 20인 팀과 오프사이트

1. AMP의 팀 구성

   1. 팀은 약 20명이며, 인원의 3분의 1이 유럽, 3분의 1이 미국, 3분의 1이 호주에 있다.
   2. 서로 다른 시간대에서 일하기 때문에 팀원들끼리 지금 몇 시인지조차 헷갈릴 정도지만, 원격 근무 자체를 즐기고 있다.

2. 원격 조직의 비용 원칙

   1. 사무실에 쓸 돈을 아끼는 대신, 그 돈을 오프사이트에 써서 팀 전체가 실제로 만날 수 있게 해야 한다.
   2. AMP는 독일 뮌헨에서 전 팀 오프사이트를 진행했고, 싱가포르에서도 모임을 가졌다.

1.2. ‘추가’보다 ‘제거’에 집중하는 전략

1. 최전선(frontier)을 탐색하는 제품 철학

   1. AMP의 질문은 “가장 미친 방식으로 무엇을 할 수 있는가?”와 “오래된 기능 중 무엇을 없애야 에이전트를 가장 잘 쓰게 되는가?”다.
   2. 사용자가 AMP를 쓴다는 것은 팀이 검증하고 축복한(happy path) 방식으로 에이전트를 쓰게 된다는 뜻이어야 한다.

2. 기능 제거를 제품 전략으로 삼기

   1. AMP는 편집기 확장 기능을 일찍 없앴고, 이후에도 많은 기능을 제거했다.
   2. 한동안은 새 기능을 추가하는 회사라기보다 기능을 죽이는 회사로 더 유명했지만, Quinn은 이것이 옳은 선택이었다고 본다.

3. AI 시대의 변화 속도

   1. 과거에는 기술 주기가 5~10년이어서 사용자를 한 번 확보하면 오랫동안 같은 제품에 머물게 할 수 있었다.
   2. 이제는 사용자를 계속 최전선으로 끌어올리지 않으면 3개월 뒤 제품이 낡았다고 느끼게 된다. 변화를 늦추는 것이 오히려 사용자에게 제품이 구식이라는 인상을 준다.

2. Orb와 클라우드 개발: 로컬 개발 환경의 종말

2.1. Orb가 제공하는 작업 방식

1. 원격 에이전트의 병렬 실행

   1. orb는 AMP 에이전트를 원격으로 실행하므로 사용자는 노트북을 닫아도 된다.
   2. 여러 작업을 동시에 실행할 수 있고, 최근 3~4주 동안 고객이 orbs를 사용하는 방식이 전년도 전체의 개발 방식 변화보다 더 큰 영향을 팀에 주었다.

2. 단순한 원격 실행을 넘어선 통합

   1. 에이전트만 클라우드에서 도는 것이 아니라 개발 서버가 포털에서 바로 보이고, 필요하면 데스크톱에도 접근할 수 있어야 한다.
   2. 개발 서버가 매번 제대로 뜨고, 여러 작업이 서로 충돌하지 않는 것이 핵심이다. 사용자가 “어떻게 띄우지?”를 생각하지 않아도 되는 수준까지 마찰을 줄여야 한다.

3. Devon에 대한 평가

   1. 원격 에이전트 작업이라는 발상을 처음부터 밀었던 Devon은 초기에 사람들이 조롱했지만 중요한 방향을 일찍 봤다.
   2. AMP는 원격 실행만 복제하는 대신 개발 서버·포털·병렬 실행·데스크톱 접근을 하나의 경험으로 묶으려 한다.

2.2. ‘로컬 개발은 죽었다’는 주장

1. Thin shell로 변하는 노트북

   1. Quinn은 AMP의 관점에서 로컬 개발이 죽었다고 말한다. 충분한 인프라가 있으면 노트북은 클라우드 컴퓨팅에 입력을 보내는 얇은 셸(thin shell)이 된다.
   2. 2021년에 이미 로컬호스트의 종말에 관한 글을 썼으며, AI 이전에도 Facebook·Google·Uber 같은 대기업 개발자는 주로 강력한 클라우드 머신에 SSH로 접속하거나 가벼운 로컬 복제본을 사용했다.
   3. 인프라만 충분하다면 iPad에서도 코딩할 수 있다. 기기는 실행 환경이 아니라 입력 장치가 된다.

2. 기존 원격 개발과 다른 점

   1. 과거 대기업 개발자들은 로컬보다 느리고 불편하다는 이유로 원격 환경을 감수했다.
   2. 에이전트가 원격으로 실행되면 개발자는 무엇인가를 포기한다는 느낌 없이 병렬성만 얻는다. 기업 보안팀이 VM 사용을 강제해서가 아니라, 몇 주 동안 로컬 개발 서버를 켜지 않았다는 사실을 스스로 깨닫게 된다.

3. 필요한 전제

   1. 클라우드 개발 환경을 만들기 위한 투자는 필요하지만, 생각보다 거대한 작업은 아니다.
   2. 여기에 에이전트를 투입하면 환경 구성·실행·수정의 상당 부분을 자동화할 수 있다.

2.3. 왜 지금 클라우드 에이전트가 확산되는가

1. 모델 신뢰도의 임계점

   1. 에이전트가 긴 시간 범위의 작업을 충분히 자주 성공시키기 시작했다.
   2. 개발자가 모든 코드를 계속 검토하지 않아도 된다고 느끼는 순간, 한 번에 실행할 수 있는 작업 수가 늘어난다.

2. CLI 에이전트가 만든 전제 조건

   1. 12월과 1월 무렵 CLI 에이전트가 본격적으로 확산된 것이 다음 단계인 원격 병렬 실행의 전제였다.
   2. 기술 도입 속도는 Quinn이 경험한 어떤 기술보다 빠르지만, 여전히 조직 의사결정과 인간의 업무 습관을 통과해야 하므로 사람의 속도로 진행된다.

3. 조직 프로세스의 병목

   1. 코드 리뷰가 필수인 회사에서는 작업 20개를 병렬로 쌓아도 리뷰 대기열만 길어질 수 있다.
   2. AMP는 20명이 모두 공동 창업자처럼 생각하고 서로의 판단을 신뢰하기 때문에 병렬성의 혜택을 바로 얻지만, 다른 팀은 리뷰·승인·배포 프로세스가 함께 바뀌어야 한다.

3. 의무적 코드 리뷰를 없앤 이유

3.1. 코드 리뷰의 사망 선언과 대체 안전장치

1. 없앤 것은 모든 검토가 아니라 ‘메인 반영 전 의무 절차’다

   1. AMP에서는 메인 브랜치에 들어가기 전의 mandatory code review가 AMP를 만들기 시작한 때부터 사라져 있었다.
   2. 이는 코드 품질에 관심이 없다는 뜻이 아니라, 리뷰 대기를 기본 제어 루프로 삼지 않는다는 뜻이다.

2. 가장 중요한 대체재는 신뢰받는 팀

   1. AI를 활용하면 적은 인원으로도 더 높은 신뢰와 더 큰 책임감을 가진 팀을 구성할 수 있다.
   2. 제품 관리자의 요구사항을 받아 스프린트 단위로 구현하고 다른 팀에 넘기는 자동화된 생산라인이 아니라, 한 사람이 문제를 발견하고 해결하고 고객에게 설명하는 엔드투엔드 소유권을 갖는다.

3. 에이전트가 팀의 책임 수준을 높인다

   1. 에이전트가 구현의 반복 작업을 맡으면 사람은 단순히 산출물을 전달하는 역할보다 판단·맥락·결과에 책임지는 역할에 집중할 수 있다.
   2. 그만큼 팀원을 신뢰할 수 있고, 각자가 제품 전체에 스킨 인 더 게임(skin in the game)을 가진 상태가 되어야 한다.

3.2. 리뷰 대기보다 빠른 복구를 우선하기

1. 15분 안에 수정 배포하기

   1. 로그나 고객 제보를 받은 뒤 15분 안에 수정 사항을 배포할 수 있는 시스템을 목표로 한다.
   2. 며칠 동안 리뷰를 기다린 뒤 배포하는 것보다, 빠르게 문제를 복구하는 편이 최종 사용자 소프트웨어에는 더 높은 품질일 수 있다는 관점이다.

2. 적용 범위는 제한적이다

   1. 이 방식이 모든 소프트웨어에 맞는 것은 아니다.
   2. 빠르게 움직이는 엔드유저 제품에서는 실패까지의 시간을 늘리는 것보다 복구까지의 시간을 줄이는 접근이 더 중요하다는 판단이다.

3. 새로운 품질 기준

   1. 품질은 배포 전 리뷰의 횟수만으로 결정되지 않는다.
   2. 신뢰할 수 있는 팀, 작은 변경의 단계적 배포, 로그와 데이터베이스의 검증, 즉시 롤백이 결합될 때 빠른 배포가 오히려 더 높은 운영 품질을 만들 수 있다.

4. 에이전트가 소프트웨어를 ‘사용하고 운영하는’ 방식까지 바꾼다

4.1. Orb 안에서 즉석 앱을 만드는 Apps 패턴

1. Ad hoc software

   1. AMP의 ‘apps’는 orb 안에서 임시 소프트웨어를 바로 띄우는 방식이다.
   2. 에이전트가 그 앱의 코드를 만들고, 사용자는 에이전트에게 즉석 수정을 요청할 수 있다.

2. 동작 방식

   1. 내부적으로 sandbox를 띄우고, 그 안에서 HTTP를 말하는 프로세스를 실행한다.
   2. 사용자는 포털에서 결과를 보고, 필요하면 에이전트에게 바로 수정·확장을 지시한다.

3. 개발 조직에서의 변화

   1. 과거에는 데이터 팀이 Looker 같은 도구에 SQL 쿼리를 추가해 대시보드를 만들었을 것이다.
   2. 다음 단계에서는 대시보드 도구에 MCP를 붙여 에이전트가 조작하도록 만들겠지만, 더 근본적인 선택은 대시보드 자체를 에이전트와 코드로 필요할 때 만드는 것이다.

4.2. 에이전트와 코드가 새로운 설정 화면이 되다

1. ‘Ultimate settings screen’

   1. 에이전트가 있으면 모든 설정을 미리 설계한 설정 화면으로 제공할 필요가 줄어든다.
   2. 코드는 소프트웨어의 궁극적인 설정 화면이고, 에이전트는 그 코드를 사용자의 요구에 맞게 수정하는 인터페이스가 된다.

2. 통합의 오버헤드 감소

   1. 모든 기능을 설정 화면·복잡한 통합·MCP 연결로 포장하면 제품을 구매하고 유지하는 비용이 커진다.
   2. 필요한 데이터와 작업을 아는 사용자가 에이전트에게 앱을 만들게 하면 궁극적인 커스터마이즈가 가능해진다.

3. 변화하는 제품 경계

   1. 에이전트는 소프트웨어를 만드는 방식뿐 아니라 사용하는 방식, 운영하는 방식, 배포하는 방식까지 바꾼다.
   2. 현재는 그 경계가 어디에 놓일지 아무도 확실히 모르며, AMP도 여러 패턴을 실험하는 중이다.

4.3. Sandstorm, Cloudflare OS, mini app, forkable software

1. Sandstorm의 재등장

   1. 진행자는 Cloudflare가 발표한 ‘Cloudflare OS’를 언급하고, Kenton Varda가 이를 과거 자신의 스타트업 Sandstorm의 V2처럼 부른다고 설명한다.
   2. Sandstorm은 자체 호스팅 웹 앱 플랫폼으로, 컨테이너처럼 패키징된 격리 앱을 개인 서버에 설치하고 제한된 API로 서로 연결하는 구상이었다.
   3. 이메일·오피스 스위트 같은 앱을 개인 클라우드에 들여오되, 앱은 완전히 컨테이너화되고 필요한 최소한의 연결만 허용된다.

2. Fork 가능한 소프트웨어

   1. 프런트엔드와 백엔드의 계약이 안정적이고 보안·프라이버시 경계가 지켜진다면, 사용자가 UI를 자유롭게 포크해도 된다.
   2. 모든 사용 사례를 설정 화면으로 제품에 집어넣는 대신, 각 사용자가 자신의 맥락에 맞는 앱을 직접 리믹스하는 모델이다.

3. Mini app 패턴

   1. 회사 데이터와 개인의 작업 사이, 그리고 앱과 앱 사이에 재사용 가능한 작은 의미 단위를 두고 사용자가 직접 앱을 만든다.
   2. Replit처럼 포크 가능한 환경에서 사용자는 기존 앱을 복제한 뒤 에이전트로 자신의 업무에 맞게 바꾼다.

4. 산업의 압축과 재팽창

   1. 지금은 전체 소프트웨어 산업이 ‘에이전트’라는 작은 단어 안으로 압축된 것처럼 보인다.
   2. 시간이 지나면 에이전트가 다시 여러 범주로 나뉘면서 어떤 경계가 제품·플랫폼·도구 사이에 남을지 드러날 것이다.

4.4. 레거시를 버리는 회사와 고객 선택

1. Burn the ships

   1. AMP는 레거시에 붙잡히지 않고 최첨단을 추구하겠다는 선택을 회사 차원에서 했다.
   2. 그 방향에 동의하는 직원과 고객을 끌어들이는 것이 전략의 일부다.

2. 두 종류의 고객

   1. 한쪽에는 10년 동안 써온 도구를 바꾸지 말라고 요구하는 고객이 있다.
   2. 다른 쪽에는 제품이 계속 변하고 최전선으로 이동하기를 기대하는 고객이 있다. AMP는 후자를 전제로 한다.

3. 변화를 수용하는 방법

   1. AMP는 고객을 버리는 대신 자신들이 왜 이런 방향으로 이동하는지 설명하고, 새로운 사용 방식을 함께 익히도록 돕고 있다.
   2. AI 제품에서는 변화 자체를 늦추는 것이 고객 보호가 아니라 제품의 진부화를 앞당길 수 있다는 판단이다.

5. 에이전트가 운영과 보안에 들어오는 방식

5.1. 다중 워크스페이스 마이그레이션을 단계적으로 운영하기

1. 변경의 성격

   1. AMP는 사용자가 하나의 워크스페이스에만 속하던 구조에서 여러 워크스페이스에 속할 수 있는 구조로 바꾸는 작업을 진행 중이다.
   2. 이는 핵심 데이터 모델을 건드리는 변경이므로, 한 번에 배포하지 않고 역호환성을 유지하는 여러 단계로 쪼개야 한다.

2. 에이전트의 역할

   1. 에이전트는 ‘phase 1 B2’와 같은 각 단계를 구현하고 배포한 뒤, 로그와 데이터베이스를 관찰한다.
   2. 스스로 세운 불변식(invariant)을 확인해 예상하지 못한 오류가 없으면 다음 단계로 진행하고, 문제가 생기면 롤백한다.

3. 비행기 안에서의 사례

   1. Quinn은 뮌헨으로 가는 12시간 비행 중 불안정할 수 있는 기내 Wi-Fi를 이용해 안전한 마이그레이션 단계 몇 개를 배포했다.
   2. 에이전트가 로그를 감시하고 정상일 때만 다음 단계로 넘어가게 했기 때문에, 본인은 잠을 잘 수 있었다.
   3. 과거에는 개발자 한 명이나 여러 운영 인력이 배포 상태를 계속 지켜보며 ‘베이비시팅’해야 했던 작업이다.

5.2. 제한된 권한이 노트북보다 안전할 수 있다

1. Orb의 제한된 운영 접근

   1. 클라우드에서 실행되는 orb에 의도적으로 제한된 권한만 부여하고, OIDC를 통해 짧은 수명의 토큰을 발급할 수 있다.
   2. 예를 들어 30분 동안 Google Cloud 로그 또는 프로덕션 데이터베이스에 읽기 전용으로 접근하도록 만들 수 있다.

2. 현재 방식과의 비교

   1. 많은 조직은 개발자 노트북에서 실행되는 에이전트에 개발자가 인증해 둔 다양한 리소스에 사실상 무제한 접근 권한을 준다.
   2. 에이전트가 격리를 탈출할 수 있다는 사례가 이미 있었고, Hugging Face 관련 사고나 우연히 인증된 다른 스크립트를 찾아 프로덕션 콘솔에 접근한 고객 사례가 언급된다.

3. 보안팀도 클라우드를 선호할 수 있는 이유

   1. 클라우드 orb는 접근 범위와 시간을 시스템적으로 제한할 수 있다.
   2. 따라서 원격 개발은 개발자에게 병렬성과 편의성을 제공하면서도, 보안팀에는 노트북보다 감사 가능한 권한 경계를 제공할 수 있다.

4. 전환 속도에 대한 전망

   1. 개발자 경험과 보안이 동시에 좋아지면 클라우드 에이전트로의 이동은 예상보다 빨라질 수 있다.
   2. Quinn은 두 달 안에 CLI 코딩 에이전트가 사실상 사라지는 방향으로 갈 수도 있다고 전망한다.

5.3. 완전한 자율성과 제한된 권한 사이의 UX 긴장

1. 두 가지 사용자 선호

   1. 어떤 사용자는 에이전트를 팀의 완전한 인간 구성원처럼 대하며 모든 권한과 자율성을 주고 싶어 한다.
   2. 다른 사용자는 보안 우려 때문에 에이전트를 강한 통제 아래 두고 싶어 한다.

2. 제한만으로는 충분하지 않다

   1. orb가 더 안전하다는 사실만으로 사용자가 이동하지는 않는다.
   2. 핵심은 20개 작업을 동시에 띄워도 서로 충돌하지 않고, 각각 적절한 권한을 받으며, 개발 서버가 자동으로 작동해 개발자의 마찰을 거의 0으로 만드는 것이다.

6. GitHub가 갑자기 사라지는 방식

6.1. ‘GitHub 킬러’가 아니라 무관심의 확산

1. 현재 GitHub의 역할

   1. AMP의 메인 저장소는 여전히 GitHub에 있지만, GitHub Actions에 문제가 생겼을 때를 제외하면 팀이 GitHub에 들어갈 일이 거의 없다.
   2. 지난 24시간 동안 장시간 장애가 있었던 것처럼 Actions가 반복해서 문제를 일으키고 있으며, 팀은 Actions에서도 벗어나려 한다.

2. 도구의 대체 방식

   1. AMP는 이슈와 pull request를 사용하지 않고, GitHub Actions도 거의 사용하지 않는다.
   2. 대신 AMP가 호스팅하는 임시·목적별 저장소를 사용한다. GitHub가 한 번에 무너지는 것이 아니라, 팀이 더 이상 방문하지 않는 방식으로 서서히 사라진다는 설명이다.

3. 개인 프로젝트의 이동

   1. Quinn은 개인 프로젝트도 AMP 호스팅 저장소로 옮겼고, GitHub를 거의 그리워하지 않는다고 말한다.
   2. 오랫동안 모두가 GitHub를 쓴다는 사실을 당연하게 여겼지만, 사용하지 않기 시작하면 대체재가 완성될 때까지 기다릴 필요조차 줄어든다.

6.2. 저장소보다 어려운 것은 Actions와 CI/CD다

1. 코드 저장의 평가

   1. AMP 호스팅 코드 저장소는 지금까지 필요한 일을 안정적으로 해냈고, Sourcegraph 출신의 신뢰할 수 있는 팀원이 있어 요청도 처리된다.
   2. 더 빠르게 처리되면 좋겠지만, 전반적으로 신뢰할 만하다는 평가다.

2. 개인 프로젝트와 SaaS의 비대칭

   1. 한 사람의 문제만 해결하는 자체 호스팅 도구는 견고하게 만들기 쉽다.
   2. 다중 테넌시, 설정 화면, 다양한 보장 조건을 추가하면 복잡도가 크게 늘어난다. AMP처럼 이런 요구사항을 실제로 감당해야 하는 제품과 개인 프로젝트 사이에는 근본적인 비대칭이 있다.

3. Coding SaaS가 마지막 SaaS가 될 수 있다는 주장

   1. 다른 SaaS는 코딩 SaaS를 이용해 사용자별로 직접 만들 수 있다.
   2. 그렇다면 코딩 SaaS가 세상에 마지막까지 남는 SaaS가 되고, 나머지 SaaS는 특정 조직의 문제를 해결하는 코드로 대체될 수 있다는 전망이다.

7. CI의 미래와 샌드박스 경쟁

7.1. CI가 필요한 이유

1. 에이전트가 테스트를 실행하는 환경

   1. Quinn의 에이전트는 팀 모두가 공유하는 동일한 sandbox에서 테스트를 실행하므로, CI가 제공하던 재현 가능한 환경을 이미 갖고 있다.
   2. 에이전트가 스스로 검증까지 했다면, 결과를 기다리는 별도 CI 단계가 왜 필요한지 의문이 생긴다.

2. 결정론적·포괄적 검증

   1. 반론은 에이전트가 자신의 컨텍스트 안에서 필요한 테스트를 실행했다고 해도, 큰 프로젝트의 모든 테스트를 빠짐없이 실행했는지 보장할 수 없다는 것이다.
   2. CI는 모든 테스트를 정해진 환경에서 실행하고, 실패 결과를 에이전트에 돌려보내 수정·재실행하는 결정론적 단계가 된다.

3. 숨은 영향 범위 찾기

   1. 개발자는 한 부분을 바꿨지만 자신이 인지하지 못한 다른 부분이 깨질 수 있다.
   2. 전체 테스트를 실행하는 CI는 이런 간접적인 회귀(regression)를 찾아내는 마지막 안전망이다.

7.2. ‘CI as we know it’의 종료

1. Quinn의 유보적 입장

   1. Quinn은 CI가 필요하다는 주장에 동의하지만, 약 3주 뒤에는 생각이 달라질지도 모른다고 말한다.
   2. AMP 팀의 절반은 이미지 패키징과 배포만 담당하는 단계가 있으면 되고, 별도의 CI는 필요 없다고 본다.

2. 현재 CI의 한계

   1. 이미 많은 팀이 변경된 파일 주변의 테스트만 실행하는 휴리스틱을 사용해 전체 테스트 비용을 줄이고 있다.
   2. 테스트 플래크(flaky test)가 큰 골칫거리인데, 에이전트가 모든 테스트를 실행하고 플래크까지 자동 수정할 수 있다면 현재의 CI보다 전체적으로 나을 수 있다.

3. CI는 사라지는 것이 아니라 변형된다

   1. 모델이 특정 작업을 못 믿겠다는 이유는 시간이 지나면 약해지는 경우가 많다는 경험에 기반해, CI의 전통적 형태는 수명이 얼마 남지 않았다는 전망이 나온다.
   2. 그러나 재현 가능한 실행 환경 자체는 사라지지 않는다. 하루에 100개의 orb를 사용하는 사람이 있고 E2B·Daytona 같은 sandbox 회사가 성장하는 것처럼, CI와 비슷한 인프라는 오히려 커진다.

7.3. E2B와 샌드박스의 핵심 프리미티브

1. AMP의 선택

   1. AMP는 현재 E2B를 사용하고 있으며, E2B가 sandbox에 필요한 핵심 프리미티브를 잘 구현했다고 평가한다.
   2. AMP Megawatt와 Gigawatt 구독은 orb에 매우 넉넉한 쿼터를 제공하므로, 99.9%의 사용자는 한도에 닿지 않을 것으로 본다.

2. 중요한 기능과 비용

   1. sandbox를 일시 중지했다가 재개하는 기능, 필요한 네트워크 접근, 일관된 실행 환경이 중요하다.
   2. AMP는 사용자가 더 많은 orb를 띄우는 데 비용이 장벽이 되지 않도록 가격을 낮추고 싶어 한다.

3. 경쟁이 복잡한 이유

   1. 대형 클라우드 사업자가 sandbox라고 부르는 제품도 재개 기능이 없거나 네트워크 접근이 막혀 있어 E2B와 동일한 경쟁자가 되지 못할 수 있다.
   2. 샌드박스 요구사항은 작업 유형마다 다르며, 일반 개발·CI·강화학습(RL) sandbox는 필요한 프리미티브가 다르다. 시장은 아직 요구사항을 만들어 가는 중이다.

8. 20명 조직, 분사, 그리고 AI 시대의 회사 운영

8.1. Sourcegraph에서 AMP를 분사한 배경

1. Sourcegraph에서 배운 것

   1. Quinn은 코드 검색 회사 Sourcegraph를 창업했고, 상위 10개 상장 기술 회사 중 9곳, 상위 6개 은행 중 4곳, Uber와 Stripe 등을 고객으로 둔 경험을 했다.
   2. 그 과정에서 규모 있는 소프트웨어 사업이 어떻게 운영되는지와 대형 고객이 실제로 무엇을 필요로 하는지를 배웠다.

2. 두 제품의 분리

   1. Sourcegraph 안에는 코드 검색 제품과 AMP라는 서로 다른 제품이 있었다.
   2. 이사회와 공동 창업자 Bang과 함께 AMP를 분사하기로 결정했고, 이런 스타트업·소프트웨어 분사는 David Sacks가 2009년 무렵 Geni에서 Yammer를 분사한 사례 이후 흔치 않았다고 회고한다.

3. 분사 구조

   1. 약 20명이 AMP로 이동하고 나머지는 Sourcegraph 팀에 남았다.
   2. 투자자와 직원은 두 회사 모두의 지분을 가지므로 투자자에게도 공정한 구조를 만들었다.
   3. Intercom에서 기존 사업과 AI 사업인 Finn이 분리된 사례처럼, 하나의 회사 안에서 성장 단계와 제품 철학이 다른 사업을 나누는 방법은 여러 가지가 있을 수 있다.

8.2. 200명 회사보다 20명 스쿼드가 맞는 이유

1. 창업자의 에너지와 역량

   1. Quinn은 200명 규모의 회사를 운영하는 CEO보다 20명 팀의 구성원과 함께 일할 때 자신이 훨씬 더 많은 에너지를 얻고 잘할 수 있다고 느낀다.
   2. 팀의 모든 사람이 고객과 대화하고 버그를 고치고 제품을 바꿀 수 있으며, 어느 한 사람에게 일을 맡겨도 안심할 수 있다는 점을 특별하게 생각한다.

2. 에이전트가 채용 구조를 바꾼다

   1. 과거에는 신뢰도·에이전시·기술이 부족한 사람을 채용해서라도 기능을 확장해야 했다.
   2. 이제는 에이전트가 특정 작업을 보조하거나 구현할 수 있으므로, 모든 기능을 별도 직무와 사람으로 채울 필요가 줄어든다.

3. 사업 상태와 오버헤드

   1. AMP는 수익을 내고 있고 빠르게 성장하는 시장에 있다.
   2. 비슷한 규모의 회사가 PM이나 마케터를 추가 채용하는 것을 보지만, Quinn에게는 과거 방식처럼 보인다.
   3. 예전에는 전체 인원의 10%가 제품을 만들고 90%가 판매·운영 오버헤드를 처리하는 구조가 필요했을지 모르지만, AI로 그 비율을 바꿀 가능성이 있다.

8.3. 코딩 에이전트에서 회사 운영 에이전트로

1. 에이전트를 코딩이라는 상자에 가두지 않기

   1. AMP는 처음에는 코딩 에이전트였지만, 에이전트가 코딩만 해야 한다는 라벨에 가둘 수는 없다.
   2. 마케팅 아이디어와 구현, 마케팅 자동화처럼 회사의 여러 기능도 같은 에이전트의 연속선상에 있다.

2. 내부에서 만들고 외부로 내보낼 수 있는 것

   1. AMP에 특화된 내부 도구는 회사 내부에서만 쓰면 된다.
   2. X·Discord·이메일에서 사람들이 AMP를 어떻게 말하는지 모니터링하고, 답변을 만들고, 커뮤니티 옹호자를 찾아내는 시스템은 다른 회사에도 일반적이므로 외부에 내놓을 수 있다.

3. Jellyware

   1. 이런 작은 결과물을 Quinn은 ‘소프트웨어보다 부드럽지만 완전히 vibe coding으로 만든 것은 아닌 것’이라는 의미에서 jellyware라고 부른다.
   2. 과거라면 오픈소스 프로젝트로 공개해 유지보수 부담을 떠안거나, 설정·통합을 갖춘 SaaS로 판매해야 했다.
   3. 이제는 코드를 공개하고, 각 사용자가 자신의 에이전트로 리믹스하고 수정할 수 있게 하는 방식이 가능하다.

9. 개인 생산성, 공개된 작업 방식, 미디어 제작

9.1. Skills와 Markdown이 새로운 오픈소스가 되다

1. Codex를 CMO처럼 쓰는 사례

   1. 진행자는 최근 2개월 동안 Codex를 사실상 CMO처럼 사용해 광고, AEO, SEO에 대한 조언을 받고 있다.
   2. 실제 인간 컨설턴트와 대화하는 것보다 선호하며 결과는 대략 비슷하다고 평가한다.

2. 작업 방식을 Skills로 공개하기

   1. Quinn은 자신의 Codex 화면 전체를 보여주기보다, 업무에 사용하는 skills를 공개하는 편이 더 유용하다고 말한다.
   2. 마케팅, AI 개발, 엔지니어링 콘텐츠 등이 하나의 작업 시스템으로 연결되어 있다.

3. 새로운 오픈소스 단위

   1. Forge의 엔지니어링 블로그는 사람이 처음부터 쓰는 것이 아니라, Quinn이 좋은 기술 이야기를 골라 방향을 주면 에이전트가 글과 그래픽을 만든다.
   2. Markdown 파일과 샘플 코드, 실행 규칙을 공개하면 특정 라이브러리보다 다른 프로젝트로 옮기기 쉬운 지식이 된다.
   3. 즉, 새로운 오픈소스는 라이브러리 하나가 아니라 사람이 일하는 방식 자체를 담은 이식 가능한 작업 파일 묶음이 될 수 있다.

9.2. 비디오 편집은 아직 인간이 비용 대비 충분히 좋다

1. 긴 형식의 콘텐츠 전략

   1. AIE는 20분에서 3시간 길이의 영상을 만들고, Latent Space는 30~60분 길이의 대화를 만든다.
   2. 클릭을 유도하는 짧은 클립보다 깊이 있는 롱폼을 선호하기 때문에 클립을 많이 만들지 않는다.

2. AI 편집 도구 실험

   1. Quad Code, Hyperframes, A16Z 지원의 Overclip 같은 도구가 언급되지만, 아직 충분히 실험하지 않았다.
   2. Overclip은 기대만큼 좋지 않았고, 금융 서비스에 초점을 둔 Starzero를 AIE에서 새로 시험할 예정이라고 말한다.

3. 인간 편집자를 유지하는 이유

   1. 현재 인간 편집은 여전히 충분히 저렴하고 품질도 좋아서 비용 문제가 아니다.
   2. 2년 동안 함께 일한 편집자 Alejandro에게 “이 부분은 이렇게 해달라”고 말하면 맥락을 이해하고 처리한다.
   3. 직접 AI 편집 파이프라인을 해킹해 만드는 것보다 이미 신뢰 관계가 있는 사람이 결과를 내는 편이 더 효율적일 수 있다.

4. 비용 구조의 차이

   1. 소규모 제작자에게 수백 달러는 큰 비용이지만, 고품질 미디어 사업을 운영하며 올해 A/V에 약 600만 달러를 쓰는 조직에서는 수만 달러의 편집 비용을 줄이는 것이 최우선 과제가 아니다.

10. 작은 팀의 시대인가

10.1. 대기업을 떠나 SWAT 팀으로 가는 흐름

1. Build in public의 에너지

   1. 진행자는 Quinn이 회사와 작업 방식을 공개적으로 만들어 가는 모습에서 강한 에너지를 느낀다고 말한다.
   2. 이런 공개적인 실험이 다른 창업자에게도 회사 규모와 운영 방식을 다시 생각하게 한다.

2. Jeff Dean 사례

   1. Google의 Jeff Dean이 회사를 떠났다는 소식은 예상하기 어려웠던 변화로 언급된다.
   2. 그가 수천 명 대신 소수 인원이 방에서 무엇을 할 수 있는지 실험하려는 방향을 보였고, 이는 대규모 Gemini 조직에 대한 간접적인 문제 제기로도 읽힐 수 있다.

3. 남아 있는 질문

   1. AI로 인해 5명짜리 팀이 과거 수천 명의 팀에 가까운 결과를 낼 수 있다면, 도메인 전문성은 어디에 남는가?
   2. 여러 사람을 조직적으로 확장하는 것이 여전히 필요한가, 아니면 높은 역량의 소수와 에이전트 조합이 새로운 기본값이 되는가?

10.2. 결론: 정답보다 먼저 실험하는 사람들

1. 아무도 AI 시대에 회사를 어떻게 운영해야 하는지 아직 모른다.
2. 그래서 가장 좋은 위치는 완성된 정답을 기다리는 곳이 아니라, 실제 제품을 만들고 배포하면서 운영 원칙을 발견하는 곳이다.
3. AMP의 사례는 코드 리뷰 폐지 자체가 핵심이 아니라, 신뢰·소유권·관측·롤백·원격 실행이 하나의 시스템으로 결합될 때만 가능한 실험이다.
4. 작은 팀과 에이전트가 성공하려면 팀이 공유하는 방향성이 강하고, 각 구성원이 높은 책임감을 가지며, 운영 안전장치가 자동화되어야 한다.
5. 앞으로 소프트웨어 산업은 에이전트라는 공통 계층에서 다시 제품·플랫폼·직무·SaaS의 경계를 만들어 갈 것이며, 그 경계를 먼저 실험한 팀이 유리할 가능성이 크다.

주요 발언 모음

“로컬 개발은 우리 관점에서 죽었다.”

“에이전트는 어떤 소프트웨어의 궁극적인 설정 화면이고, 코드는 어떤 소프트웨어의 궁극적인 설정 화면이다.”

“코드 리뷰를 없애는 데 가장 중요한 시스템은 정말 신뢰할 수 있는 팀을 갖는 것이다.”

“CI와 비슷한 것은 폭발적으로 커지고 있지만, 우리가 아는 형태의 CI는 수명이 얼마 남지 않은 것처럼 느껴진다.”

“아무도 모르고, 우리 모두 알아낼 것이다. 그러니 나가서 만드는 것이 가장 좋은 위치다.”

핵심 데이터 & 수치

• 팀 규모: AMP 약 20명.
• 팀 분포: 유럽·미국·호주에 각각 약 3분의 1.
• 수정 배포 목표: 로그나 고객 제보 후 약 15분 안에 수정.
• 제한 권한 예시: OIDC 토큰으로 30분 동안 특정 로그나 프로덕션 DB에 읽기 전용 접근.
• 마이그레이션 사례: 12시간 비행 중 안전한 단계를 배포·관찰·진행 또는 롤백.
• Orb 사용 규모 예시: 일부 사용자는 하루 100개의 orb를 실행.
• 쿼터 전망: AMP Megawatt·Gigawatt 사용자의 99.9%는 제공 쿼터에 도달하지 않을 것으로 예상.
• Sourcegraph 고객 경험: 상위 10개 상장 기술 회사 중 9곳, 상위 6개 은행 중 4곳, Uber·Stripe 등이 코드 검색 고객.
• 영상 제작: AIE 20분~3시간, Latent Space 30~60분.
• A/V 예산: 진행자의 미디어 사업은 올해 약 600만 달러를 A/V에 지출.

핵심 요약 (20줄)

1. AMP는 AI 에이전트의 최전선을 탐색하기 위해 오래된 기능을 과감히 제거한다.
2. 팀은 유럽·미국·호주에 분산된 약 20명의 원격 조직이다.
3. 사무실 예산을 오프사이트에 투자해 원격 팀의 연결을 보완한다.
4. Orb는 에이전트와 개발 서버를 클라우드에서 실행하고 여러 작업을 병렬화한다.
5. 개발자는 노트북을 닫아도 작업을 계속할 수 있으며, 로컬 개발 환경의 필요성이 줄어든다.
6. 에이전트가 긴 작업을 안정적으로 수행하면서 클라우드 개발이 확산되기 시작했다.
7. AMP는 메인 반영 전 의무적 코드 리뷰를 오래전부터 없앴다.
8. 그 대신 높은 신뢰와 엔드투엔드 소유권을 가진 팀을 안전장치로 삼는다.
9. 빠르게 움직이는 제품에서는 리뷰 대기보다 15분 내 복구가 더 높은 품질일 수 있다.
10. 에이전트는 임시 앱을 Orb 안에서 만들고 실행하며 즉시 수정한다.
11. 코드와 에이전트가 설정 화면과 복잡한 통합을 대체할 수 있다.
12. Cloudflare OS와 Sandstorm의 사례는 개인 소유·격리·포크 가능한 소프트웨어를 연상시킨다.
13. Mini app은 회사 데이터와 개인 업무를 연결하는 재사용 가능한 작은 소프트웨어 단위다.
14. 에이전트는 단계적 배포, 로그 관찰, 데이터베이스 불변식 검증, 롤백까지 수행한다.
15. 짧은 수명의 읽기 전용 권한을 주는 클라우드 에이전트가 노트북 에이전트보다 안전할 수 있다.
16. GitHub는 갑자기 무너지기보다 팀이 더 이상 방문하지 않는 방식으로 약화될 수 있다.
17. CI는 사라지기보다 에이전트 테스트와 재현 가능한 sandbox로 형태를 바꿀 가능성이 있다.
18. AMP는 E2B를 사용하며, sandbox의 재개·네트워크·일관성이 핵심 프리미티브라고 본다.
19. AI는 200명 조직보다 모든 구성원이 책임지는 20명 스쿼드의 경제성을 높인다.
20. 회사 운영의 정답은 아직 없으므로, 먼저 만들고 배포하며 실험하는 팀이 유리하다.