Autonomy Is All You Need – Michele Catasta, Replit
1. 자율성의 재정의: Supervised vs. Unsupervised Autonomy
Michele Catasta는 Replit에서 비기술 사용자를 위한 코딩 에이전트를 구축하는 과정에서 자율성(Autonomy)이 핵심 북극성(North Star)이 되었다고 강조한다. 기존의 에이전트 논의는 주로 지연 시간(Latency)과 자율성의 2차원 트레이드오프에 집중했다. 저지연 상호작용은 사용자가 루프 안에 머물며 깊은 작업(Deep Work)을 수행할 수 있게 하지만, 전문가 수준의 기술 지식을 요구한다. 반면 비동기(Async) 영역의 에이전트는 충분히 자율적이지 못해 작업을 완전히 위임할 수 없으면서도, 사용자를 집중 상태에서 벗어나게 만드는 문제가 있었다.
Catasta는 여기에 제3의 차원이 존재한다고 주장한다. 바로 비기술 사용자를 위한 자율성이다. 그는 두 가지 유형의 자율성을 구분한다:
-
Supervised Autonomy (감독형 자율성): Tesla FSD와 같이 운전면허가 필요하고, 사용자가 핸들 앞에 앉아 롱테일 이벤트(Long-tail Events)를 처리해야 하는 형태. 대부분의 기존 코딩 에이전트가 여기에 해당하며, 기술적으로 능숙한 사용자를 전제로 한다.
-
Unsupervised Autonomy (비감독형 자율성): Waymo 경험과 같이 사용자가 뒷좌석에 앉고, 운전면허가 필요 없는 형태. Replit이 추구하는 방향으로, 모든 지식 노동자(Knowledge Worker)가 소프트웨어를 만들 수 있도록 기술적 복잡성을 완전히 추상화한다.
Replit의 목표는 명확하다: 모든 지식 노동자가 소프트웨어를 만들 수 있도록 임파워먼트(Empowerment)하되, 기술적 의사결정을 요구하지 않는 것이다. 이는 단순히 에이전트가 오래 실행되는 것 이상의 의미를 갖는다.
2. 자율성의 올바른 측정: Irreducible Runtime
Catasta는 자율성을 실행 시간(Runtime)과 혼동해서는 안 된다고 강조한다. 많은 경우 자율성이 허영 지표(Vanity Metric)로 사용되며, 몇 시간 동안 실행되는 것을 자랑스러워하는 경향이 있다. 그러나 진정한 자율성의 핵심은 사용자가 기술적 의사결정을 내리지 않아도 되는 시간의 최대화에 있다.
모든 작업(Task)에는 자연스러운 복잡성 수준이 있으며, 최소한의 환원 불가능한 작업량(Irreducible Amount of Work)이 존재한다. 에이전트는 계획(Planning) → 구현(Implementation) → 테스트(Testing)의 루프를 반복하며, 이 과정은 긴 쿼리 궤적(Long Querying Trajectory)을 통해 이루어진다.
핵심 목표는 환원 불가능한 런타임(Irreducible Runtime)의 최대화다. 여기서 “환원 불가능”이란 사용자가 어떠한 기술적 의사결정도 내리지 않아도 에이전트가 완전 자율로 작업을 완수할 수 있는 시간을 의미한다.
이는 특히 비기술 사용자에게 중요하다:
- 기술적 의사결정을 신뢰할 수 없는 사용자에게 적절한 기술 협력자를 제공
- 소프트웨어 생성 과정에서 복잡성을 최대한 추상화
- 사용자가 창의성을 발휘하면서도 통제감을 느끼도록 보장
중요한 통찰은 자율성과 속도가 상충하지 않는다는 점이다. 작업 범위(Scope)가 좁으면 완전히 자율적이면서도 빠른 에이전트를 만들 수 있다. 사용자는 자신이 관심 있는 측면(무엇을 만들 것인가)에 대한 통제권을 유지하고, 어떻게 만들 것인가는 에이전트에게 위임한다.
3. 자율성의 세 가지 기둥
Catasta는 자율 에이전트 구축의 세 가지 핵심 기둥을 제시한다:
3.1. Frontier Model Capabilities
프론티어 모델(Frontier Models)의 능력은 에이전트 루프에 주입되는 기본 IQ에 해당한다. Catasta는 이 부분은 “독자와 다른 연사들에게 맡긴다”며, Replit이 활용하는 놀라운 모델들을 구축하는 이들에게 감사를 표한다. 이는 첫 번째 기둥이지만, 이 강연의 주요 초점은 아니다.
3.2. Verification (검증)
두 번째 기둥인 검증은 Replit이 가장 적극적으로 작업하는 영역이다. 에이전트가 취하는 모든 단계에서 지역적 정확성(Local Correctness)을 테스트하는 것이 매우 중요하다. 그 이유는 직관적이다: 흔들리는 기초 위에 건물을 지으면 결국 무너진다. 검증을 루프에 통합함으로써 신뢰성의 “나인(9s)“을 확보하고, 통제 없이는 불가피하게 발생하는 오류의 누적(Compounding Errors)을 방지한다.
페인티드 도어(Painted Doors) 문제
테스트 없이 에이전트는 수많은 “페인티드 도어”를 만든다. 이는 겉보기에는 작동하는 것처럼 보이지만 실제로는 기능하지 않는 요소들이다. 웹 애플리케이션에서는 다음과 같은 형태로 나타난다:
- 클릭해도 핸들러가 연결되지 않은 버튼
- 데이터베이스가 아닌 목(Mock) 데이터를 표시하는 컴포넌트
- 완전히 구현되지 않은 기능들
Replit의 내부 평가 결과, 에이전트가 처음 생성한 개별 기능의 30% 이상이 고장 난 상태였다. 이는 거의 모든 애플리케이션에 최소 하나의 고장난 기능이나 페인티드 도어가 존재함을 의미한다.
이러한 문제는 발견하기 어렵다:
- 사용자는 모든 버튼, 모든 필드를 테스트할 시간이 없음
- 특히 비기술 사용자는 코딩 에이전트를 신뢰하기 어려워함
- 페인티드 도어를 발견했을 때 충격을 받음
자율 테스팅(Autonomous Testing)의 필요성
에이전트는 환경으로부터 필요한 모든 피드백을 스스로 수집해야 한다. 비기술 사용자는 기술적 의사결정을 내릴 수 없을 뿐만 아니라, 에이전트가 진전하는 데 필요한 기술적 피드백도 제공할 수 없다. 그들이 할 수 있는 것은 기본적인 품질 보증(QA) 테스팅뿐이다 – UI를 클릭하고 상호작용하는 것.
Replit은 초기에 사용자에게 QA를 의존했지만, 이는 매우 지루하고 나쁜 사용자 경험으로 이어졌다. 사용자들은 테스트에 시간을 쓰고 싶어 하지 않았다. 따라서 완전히 직교하는(Orthogonal) 솔루션인 자율 테스팅을 개발해야 했다.
자율 테스팅이 해결하는 문제들:
- 피드백 병목 현상 해소: 사람의 피드백을 기다릴 필요가 없음
- 작은 오류의 누적 방지: 빌드 과정에서 오류가 복합되지 않도록 보장
- 프론티어 모델의 게으름 극복: 모델이 작업 완료를 주장할 때 실제로 완료되었는지 검증
코드 검증의 스펙트럼
| 검증 방법 | 설명 | 한계 |
|---|---|---|
| Static Code Analysis | LSP를 활용한 정적 분석 | 기본적이고 제한적 |
| Code Execution | 기본 LLM 디버깅 시대부터 사용 | 실행만으로는 불충분 |
| Unit Testing | 단위 테스트 생성 및 실행 | 기능적 정확성에만 제한됨, 통합 테스트 불가 |
| API Testing | 엔드포인트 테스트 | API 코드에만 제한됨, UI 테스트 불가 |
| Browser-based Testing | 브라우저 자동화를 통한 테스트 | 가장 포괄적이지만 복잡함 |
최근 몇 달간 Replit과 다른 회사들은 브라우저 기반 자율 테스팅에 많은 노력을 기울였다. 웹 애플리케이션의 경우 두 가지 주요 카테고리가 있다:
1) Computer Use (컴퓨터 사용)
- UI와 1대1 매핑
- 모델이 애플리케이션과 직접 상호작용
- 스크린샷 필요
- 비교적 비싸고 느림
2) Browser Use (브라우저 사용)
- UI를 시뮬레이션
- 브라우저 및 웹 애플리케이션과 상호작용
- DOM 추상화에 의존
- 더 효율적인 중간 지점
Replit의 접근법: Playwright 기반 테스팅
Replit은 테스트에 적합한 애플리케이션을 생성하고, 이전 방법들을 모두 통합한다:
- 에이전트가 애플리케이션과 상호작용하고 스크린샷을 수집할 수 있음
- 실패 시 Computer Use로 풀백(Fallback)
- 대부분의 경우 프로그래밍 방식의 상호작용 사용:
- 데이터베이스와 상호작용
- 로그 읽기
- API 호출
- 앱에서 직접 클릭하여 정보 수집
기존의 도구 기반 브라우저 사용(Tool-based Browser Use) 방식은 제한적이다:
- 탭 생성, 클릭, 폼 채우기 등 몇 가지 일반적인 도구 노출
- 브라우저와의 모든 상호작용 유형을 열거하기 어려움
- Tesla 비유처럼 99%의 상호작용에는 충분하지만, 사용자가 웹 애플리케이션과 하는 특이한(Idiosyncratic) 상호작용의 롱테일이 존재
Replit의 혁신: Playwright 코드 직접 작성
# Playwright 코드 예시 (개념적)
# LLM이 직접 Playwright 스크립트를 생성
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch()
page = browser.new_page()
# 애플리케이션 탐색
page.goto('http://localhost:3000')
# 버튼 클릭 및 상호작용
page.click('button#submit')
# 폼 채우기
page.fill('input#username', 'testuser')
# 결과 검증
assert page.locator('.success-message').is_visible()
browser.close()Playwright 접근법의 장점:
- LLM 친화적: LLM이 Playwright 코드 작성에 매우 능숙함
- 강력하고 표현력 있음: 도구 기반 접근법의 상위 집합(Superset)
- 재사용성: 테스트 스크립트를 작성하면 원하는 만큼 재실행 가능
- 회귀 테스트 스위트(Regression Test Suite): 테스트를 만드는 것이 곧 향후 계속 실행할 수 있는 회귀 테스트를 만드는 것
성능 개선: 이러한 최적화들을 통해 Replit은 Computer Use 대비 대략 1/4 수준의 비용과 더 빠른 속도를 달성했다. 지연 시간이 얼마나 중요한지는 나중에 다시 다룬다.
3.3. Context Management (컨텍스트 관리)
세 번째 기둥인 컨텍스트 관리는 에이전트가 글로벌하게 일관성(Globally Coherent)을 유지하면서도 고수준 목표와 개별 작업을 모두 관리할 수 있어야 함을 의미한다. Catasta는 이 주제가 컨퍼런스 내내 많이 다뤄질 것이라며 간략히 설명한다.
핵심 메시지: 긴 컨텍스트 모델이 필수는 아니다
긴 쿼리 궤적(Long Querying Trajectories)을 처리하는 데 긴 컨텍스트 모델이 반드시 필요한 것은 아니다. Replit의 경험에 따르면, 가장 야심찬 작업들도 대부분 200,000 토큰 이내에서 완수할 수 있다. 따라서 1천만 또는 1억 토큰의 컨텍스트 윈도우를 가진 모델이 자율 에이전트 실행에 필수적인 것은 아니다.
이는 올바른 컨텍스트 관리 방법을 통해 달성된다:
1) 코드베이스 자체를 상태 유지 수단으로 활용
- 에이전트가 코드를 작성하면서 문서화 작성
- 계획 설명 및 작업 목록을 파일 시스템에 저장
- 메모리를 오프로드할 수 있는 다양한 방법 활용
2) 파일 시스템에 메모리 직접 덤프
- Anthropic이 적극 권장한 방식
- 메모리를 파일 시스템에 기록
- 에이전트가 작업과 관련이 있을 때 다시 읽어들이도록 결정
장시간 실행의 돌파
최근 몇 달간 여러 발표들:
- Anthropic Claude: 30시간 이상 연속 실행 (집중된 작업)
- OpenAI: 수학 문제에서 유사한 결과
핵심 성공 요인: Subagent Orchestration (서브에이전트 오케스트레이션)
모델과 에이전트 빌더들이 서브에이전트 오케스트레이션에 능숙해지면서 장시간 실행 장벽을 돌파했다.
서브에이전트 작동 방식:
- 코어 루프에서 호출됨
- **완전히 새로운 컨텍스트(Blank Slate)**에서 시작
- 에이전트 빌더가 서브에이전트 시작 시 주입할 컨텍스트 부분 집합을 결정
- 관심사의 분리(Separation of Concerns) 개념과 유사
- 서브에이전트가 작업할 내용 결정
- 가능한 최소한의 컨텍스트 제공
- 완료까지 실행하도록 허용
- 출력/결과만 받음
- 메인 루프에 다시 주입하여 계속 실행
성능 개선:
Replit의 프로덕션 데이터에 따르면, 새로운 서브에이전트 오케스트레이터를 적용한 순간:
- 컨텍스트 압축당 메모리 수: 약 35 → 45~50으로 증가
- 컨텍스트 오염(Context Pollution)을 서브에이전트를 통해 대부분 제거하여 재압축 빈도가 크게 감소
사례 연구: 테스팅에서 서브에이전트의 필수성
Catasta는 비용 최적화뿐만 아니라, 테스팅에서 서브에이전트가 거의 필수적이었다고 강조한다.
초기 문제:
- 서브에이전트 오케스트레이션이 고도화되기 전에 자동 테스팅 작업 시작
- 메인 루프가 코드 생성뿐만 아니라 브라우저 액션도 수행하도록 허용
- 브라우저 액션의 관찰 결과를 메인 루프에 다시 넣음
- 결과: 에이전트 루프가 매우 혼란스러워짐
- 메인 루프가 보는 액션의 이질성(Heterogeneity)이 너무 높음
해결책: 서브에이전트 아키텍처로 전환
[메인 에이전트 루프]
↓
(검증 필요 시점 도달)
↓
[테스팅 서브에이전트 생성]
- 브라우저 상호작용
- Playwright 코드 실행
- 결과 수집
↓
[서브에이전트 컨텍스트 삭제]
↓
[마지막 관찰만 메인 루프에 반환]
↓
[메인 루프 계속 실행]
명확한 관심사 분리:
- 메인 에이전트 루프: 고수준 계획 및 코드 생성
- 테스팅 서브에이전트: 검증 작업 전담, 완료 후 컨텍스트 제거
- 메인 루프는 검증 결과만 받아 계속 진행
Catasta는 서브에이전트 작동에 문제가 있다면 이러한 구조를 살펴보라고 권장한다.
4. 병렬화(Parallelism): 사용자 경험의 게임 체인저
Catasta는 병렬화가 에이전트를 더 강력하게 만드는 것이 아니라, 사용자 경험을 더 흥미롭게 만드는 요소라고 주장한다.
4.1. 장시간 실행의 딜레마
장시간 자율적으로 실행하는 에이전트를 갖는 것은 훌륭하지만, 사용자 경험이 덜 스릴 있게(Less Thrilling) 되는 대가가 따른다:
- 더 이상 “몰입 영역(In the Zone)“에 있지 않음
- 매우 긴 프롬프트 작성 → 작업 목록으로 변환 → 동료와 점심 먹으러 감 → 돌아와서 에이전트가 완료되기를 기대
- 이것은 대부분의 생산적인 사람들이 원하는 경험이 아님
- 사람들은 가능한 한 짧은 시간에 최대한 많은 작업이 완료되는 것을 보고 싶어 함
4.2. 병렬 에이전트의 트레이드오프
병렬 에이전트는 컴퓨팅 일반에 적용되는 매우 일반적인 트레이드오프를 사용한다: 추가 컴퓨팅 자원을 시간과 교환한다.
왜 트레이드오프인가?
-
컨텍스트 중복
- 병렬로 실행되는 각 에이전트는 대략 80%의 컨텍스트를 공유
- 여러 컨텍스트 윈도우에 동일한 컨텍스트를 로드
- 더 많은 컴퓨팅 자원 투입
-
병합 충돌(Merge Conflicts)
- 여러 병렬 에이전트의 출력을 어떻게 처리할 것인가?
- 전문 개발자에게도 자명하지 않음
- 비기술 사용자는 병합 충돌이라는 개념조차 모름
- Replit이 자체적으로 해결해야 하는 문제
현재 병렬 에이전트에 대한 사고방식은 Replit에는 적용되지 않는다. 그러나 Catasta는 여전히 이를 달성하고 싶어 한다.
4.3. 병렬화로 가능한 흥미로운 기능들
1) 더 많은 작업 완료
- 기본적인 병렬화의 이점
2) 테스팅과 코드 생성의 병렬 실행
- 테스팅은 아무리 최적화해도 여전히 매우 느림
- 에이전트가 테스팅에만 시간을 쓰면 사용자는 더 이상 애플리케이션에 참여하지 않음
- 비동기 프로세스를 에이전트 실행과 병렬로 실행하는 것이 유용함
- 유용한 정보를 메인 코어 루프에 다시 주입 가능
3) 다중 궤적 샘플링(Multiple Trajectory Sampling)
- 성능 향상이 입증된 매우 일반적인 기법
- 충분한 예산이 있다면 동시에 여러 궤적을 샘플링해야 함
4.4. 두 가지 오케스트레이션 패러다임
현재 방식: User as Orchestrator (사용자가 오케스트레이터)
특징:
- 실행할 작업의 부분은 사용자가 결정
- 각 작업은 별도의 스레드로 디스패치
- 수동 프로세스가 필요함
- 작업 분해(Task Decomposition)조차 사용자의 머릿속에서 발생
- 어떤 에이전트를 실행할지 생각하는 동안
- 모든 결과를 받은 후 병합 충돌 문제를 처리해야 함
- 많은 훌륭한 도구가 있어도 이는 종종 자명하지 않음
한계:
- 비기술 사용자에게 부적합
- 인지 부담(Cognitive Burden)이 큼
- 병합 충돌 해결 필요
Replit의 비전: Core Loop as Orchestrator (코어 루프가 오케스트레이터)
핵심 차이:
- 서브태스크는 사용자가 아닌 코어 에이전트 루프가 결정
- 병렬화는 즉석에서(On the Fly) 결정됨
- 에이전트가 사용자를 대신하여 작업 분해 수행
장점:
-
인지 부담 제거
- 사용자가 작업을 어떻게 분해해야 할지 이해할 필요 없음
-
병합 충돌 완화
- 병합 충돌 문제를 완화하는 방식으로 작업 생성 가능
- 100% 완화는 불가능 (많은 코너 케이스 존재)
- 그러나 소프트웨어 엔지니어링에서 알려진 많은 기법을 활용 가능
- 여러 서브에이전트가 서로의 영역을 침범하지 않도록 보장
구현 전략:
[코어 에이전트 루프]
↓
(작업 분석 및 분해)
↓
[병렬 가능 서브태스크 식별]
↓
[여러 서브에이전트 동시 시작]
├─ [서브에이전트 A: UI 컴포넌트]
├─ [서브에이전트 B: API 엔드포인트]
└─ [서브에이전트 C: 데이터베이스 스키마]
↓
[충돌 최소화 전략 적용]
- 파일 분리
- 모듈 경계 존중
- 의존성 분석
↓
[결과 통합 및 검증]
↓
[메인 루프 계속]
소프트웨어 엔지니어링 원칙 활용:
- 모듈화(Modularity): 독립적인 모듈에서 작업
- 인터페이스 분리: 명확한 인터페이스 경계
- 의존성 주입: 의존성 명시적 관리
- 파일 분리: 다른 파일에서 병렬 작업
4.5. 향후 방향
Core Loop as Orchestrator는 Replit의 다음 몇 달간 주요 베팅이다. Catasta는 이러한 주제에 열정이 있다면 Replit에서 항상 채용 중이라고 언급하며 강연을 마무리한다.
5. 종합: 자율성의 미래
Michele Catasta의 강연은 자율 코딩 에이전트 구축에 대한 명확한 비전을 제시한다:
핵심 원칙
-
자율성은 실행 시간이 아니다
- 환원 불가능한 런타임의 최대화
- 사용자의 기술적 의사결정 부담 제거
-
비기술 사용자를 위한 설계
- Waymo 경험: 뒷좌석에 앉기, 운전면허 불필요
- 모든 지식 노동자의 임파워먼트
-
세 가지 기둥의 균형
- 프론티어 모델 능력
- 검증 (Playwright 기반 자율 테스팅)
- 컨텍스트 관리 (서브에이전트 오케스트레이션)
-
병렬화를 통한 UX 혁신
- 코어 루프가 오케스트레이터
- 사용자는 “무엇”에 집중, 에이전트는 “어떻게”를 처리
기술적 혁신
검증 시스템:
- 페인티드 도어 문제 해결 (30% 이상의 기능 고장)
- Playwright 코드 직접 생성
- Computer Use 대비 1/4 비용, 더 빠른 속도
컨텍스트 관리:
- 200K 토큰 이내에서 대부분 작업 처리
- 서브에이전트 오케스트레이션으로 컨텍스트 압축당 메모리 35 → 50 증가
- 파일 시스템 활용한 메모리 오프로딩
병렬화 아키텍처:
- 사용자가 아닌 에이전트가 작업 분해
- 병합 충돌 최소화 전략
- 테스팅과 개발의 동시 실행
Replit의 접근법은 단순히 더 강력한 에이전트를 만드는 것을 넘어, 모든 사람이 소프트웨어를 만들 수 있는 미래를 향한 구체적인 로드맵을 제시한다. 자율성의 재정의, 검증의 체계화, 그리고 지능적인 병렬화를 통해 Replit은 코딩의 민주화라는 비전을 현실로 만들어가고 있다.