Amp Code: Next Generation AI Coding – Beyang Liu, Amp Code
서론: 에이전트 시대의 새로운 코딩 경험
Beyang Liu가 이끄는 Amp는 스스로를 “opinionated frontier agent”로 규정한다. 이는 단순히 또 하나의 AI 코딩 도구가 아니라, 에이전트가 코드를 작성하는 시대의 경이로움(awe)과 부조리함(absurdity)을 받아들이며 1년 앞선 미래를 살아가는 에이전트 연구소(agent research lab)를 지향한다는 의미다.
현재 개발자들의 작업 방식은 1년 전과 완전히 달라졌다. Amp는 이러한 변화의 본질을 이해하고, 에이전트와 함께 코딩하는 새로운 craft를 정의하려는 시도다.
제품 구조: Terminal UI와 Editor 경험
Terminal Interface의 재구성
Amp는 터미널에서 호출 가능한 코딩 에이전트로, 완전히 처음부터(from scratch) 구축한 터미널 UI 프레임워크를 사용한다. 이는 현대 터미널의 모든 기능(capabilities)을 최대한 활용하기 위한 전략적 선택이었다.
핵심 설계 원칙은 **정보의 균형(balance)**이다. 에이전트가 수행하는 작업을 사용자에게 전달하되, 모델이 생성하는 모든 토큰(token)으로 사용자를 압도하지 않는 것이다. 실시간으로 diff를 스트리밍하고, CLI 명령어를 표시하며, Emacs, NeoVim, JetBrains 등 사용자가 사용하는 에디터와 연결하여 진단 정보(diagnostics)를 수집한다.
터미널 렌더링에서도 독특한 접근을 보인다. 예를 들어, diff의 녹색 색상은 터미널의 배경색과 자동으로 혼합(mix)되어 더 나은 시각적 경험을 제공한다. 동시에 JetBrains나 VS Code 내의 터미널을 포함한 다양한 터미널 환경에서 gracefully degrade하여, 기본 macOS 터미널에서도 제대로 작동한다.
Editor 경험: 코드 리뷰의 최적화
Amp는 VS Code 포크를 만들지 않기로 결정했다(아직까지는). 대신 VS Code와 Cursor, Windsurf, Anti-gravity 등 파생 제품에 설치되는 확장으로 제공된다.
현대 개발자의 작업 패턴을 재정의한 핵심 통찰은 다음과 같다: **에디터는 이제 코드를 편집하는 곳이 아니라, 코드를 리뷰하는 곳(rediter, not editor)**이다. Liu 본인도 수동으로 코드를 편집하는 시간이 극히 적어졌으며, 대부분의 작업을 에이전트 패널을 통해 수행한다.
병목(bottleneck)은 코드 작성이 아니라 코드 리뷰다. 에이전트 출력을 읽고 이해하는 시간이 더 많은 에이전트를 병렬로 실행하는 것을 제약한다. 이를 해결하기 위해 Amp는 에이전트 출력 소비에 최적화된 커스텀 diff viewer를 구축했다.
이 diff viewer의 특징:
- 임의의 커밋 범위(commit range) 선택 가능
- 파일 수준 diff를 빠르게 탐색
- 모든 diff가 편집 가능(editable)
- 전체 코드 네비게이션 지원(go to definition, find references)
- Tour of the change: 대규모 변경사항을 리뷰할 때 어디서부터 시작해야 할지 안내하는 기능
아키텍처 철학: 에이전트의 본질과 레버(Levers)
에이전트의 핵심 구조
Liu는 에이전트를 극도로 단순하게 정의한다:
Agent = for loop + tool calls + model
이 관점이 중요한 이유는 에이전트 빌더가 조작할 수 있는 **레버(levers)**가 무엇인지 명확히 보여주기 때문이다:
- 모델 선택(choice of model)
- 도구 설명(tool descriptions)
- 도구와의 반복 방식(how the model iterates with tools)
프로그래밍 언어가 if문과 for문의 문법적 설탕(syntactic sugar)으로 놀라운 복잡성을 만들어내듯, 이 세 가지 레버만으로도 광범위한 행동과 복잡성(wide variance of behaviors and complexity)을 만들어낼 수 있다.
MCP에 대한 반대 입장: 도구의 정밀함 vs 확장성
MCP(Model Context Protocol)는 에이전트에 컨텍스트를 제공하는 방법에 대해 모두가 생각하게 만든 프로토콜이다. Amp 팀이 직면한 초기 결정은 MCP 통합에 얼마나 투자할 것인가였다.
Amp의 논쟁적 입장: MCP 대신 커스텀 도구 세트(custom tool set)에 집중해야 한다.
이유는 두 가지다:
1. 피드백 루프의 식별과 폐쇄(Feedback loop closure) 에이전트와 작업할수록 피드백 루프를 식별하고 에이전트가 이를 닫도록 돕는 것이 핵심임을 발견하게 된다. 이를 위해서는 에이전트가 이러한 루프를 찾도록 정밀하게 조정된 도구 세트가 필요하다. MCP 서버의 제작자는 당신의 에이전트가 무엇을 하려는지 모르므로, 당신의 목표에 맞춰 도구 설명을 조정할 수 없다.
2. 컨텍스트 혼란(Context confusion) 컨텍스트 윈도우에 더 많은 도구를 추가할수록 에이전트가 선택해야 할 것이 많아진다. 도구가 당면 과제와 관련이 없으면 에이전트는 혼란스러워진다.
이는 2025년 4월 당시만 해도 논쟁적이었지만, 지금은 덜 논란이 되는 입장이다.
컨텍스트 소진 문제와 Subagent 솔루션
도구 설명뿐만 아니라 도구 호출(tool calls) 자체도 컨텍스트를 소모한다. 모든 에이전트 빌더가 직면하는 문제는 **컨텍스트 소진(context exhaustion)**이다.
전형적인 실패 패턴:
- 에이전트가 grep과 파일 읽기로 관련 컨텍스트를 찾는다
- 편집할 차례가 되면 컨텍스트 윈도우가 거의 남지 않는다
- 조기 종료(premature stop)
순진한 해결책은 읽기를 덜 하도록 프롬프트하는 것이지만, 이는 둠 루프(doom loop) 실패 모드를 초래한다:
- 초기에 충분한 컨텍스트를 수집하지 못함
- 무엇을 해야 할지 파악하지 못함
- 같은 것을 반복적으로 재시도
진정한 해결책은 Subagent다.
Subagent는 일반 프로그래밍 언어의 서브루틴 호출(subroutine calls)과 유사하다. 하위 작업에 사용된 컨텍스트 윈도우를 별도의 컨텍스트 윈도우(subagent의 컨텍스트)로 분리할 수 있다. Subagent는 필요한 모든 작업을 수행하고, 마지막에 관련 결과만 메인 에이전트 윈도우에 반환한다.
Subagent = 메인 에이전트의 컨텍스트 윈도우를 보존하고 확장하는 방법
Amp의 Subagent 전략: 특화된 에이전트 생태계
대부분의 에이전트가 시스템 프롬프트와 도구 세트를 약간 조정하는 일반적(generic) subagent를 사용하는 반면, Amp는 심도 있게 특화된(leaned into) subagent를 구축했다.
핵심 Subagent 4종
1. Finder (코드베이스 검색 에이전트)
- 목적: 코드베이스에서 관련 컨텍스트를 빠르게 발견
- 특징: 상대적으로 작고 빠른 모델 사용
- 도구 세트: 빠른 컨텍스트 발견에 최적화된 제한된(limited) 도구 세트
2. Oracle (추론 에이전트)
- 목적: Amp의 추론(reasoning) 담당
- 핵심 차별점: 대부분의 에이전트가 모델 선택(model selection)으로 추론을 구현하는 것과 달리, Amp는 subagent로 추론을 구현
이 접근의 장점:
- 메인 에이전트의 상대적 민첩성(snappiness) 유지
- 다양한 도구 사용 능력 보존
- 까다로운 문제를 디버깅하거나 미묘한 계획이 필요할 때만 oracle subagent로 전환
사용 경험: 메인 에이전트가 문제를 해결하는 데 어려움을 겪을 때, “oracle을 호출하고, 깊이 생각하라(invoke the oracle, think really hard)“고 태그하고 이메일을 확인하러 간다. 몇 분이 걸릴 수 있지만(깊이 생각하고 있으므로), 5번 중 4번은 근본적인 문제를 마법처럼 찾아낸다.
3. Librarian (라이브러리 컨텍스트 에이전트)
- 목적: 코드베이스 너머의 컨텍스트 가져오기
- 대상: 의존하는 라이브러리와 프레임워크
4. Kraken (실험적 리팩토링 에이전트)
- 목적: 대규모 리팩토링
- 특징: 파일을 하나씩 편집하지 않고 코드 모드(code mods)를 작성하여 대규모 리팩토링 수행
모델 선택에 대한 입장: 선택의 역설(Paradox of Choice)
거의 모든 다른 코딩 에이전트가 핵심 UX 구성 요소로 **모델 선택기(model selector)**를 구현하는 반면, Amp는 이것이 미래의 아키텍처가 아니라고 생각한다.
선택의 문제점
개발자들이 선택(choice) 또는 선택의 가능성을 좋아한다는 것은 이해한다. 그러나 선택에는 **선택의 역설(paradox of choice)**이 존재한다:
- 선택지가 많을수록 인지적 부담(cognitive burden)이 커진다
- 아키텍처 수준에서 N개의 모델과 하나의 에이전트 하네스를 가지면, 각 모델을 약간만 커스터마이징할 수 있다
- 결과적으로 어떤 특정 모델이 할 수 있는 것을 최적화하지 못한다
Amp의 Two-Agent 전략
Amp의 아키텍처는 훨씬 더 **에이전트 지향적(agent-oriented)**이다. 두 개의 최상위 에이전트만 존재한다:
1. Smart Agent (스마트 에이전트)
- 특징: 모든 고급 subagent에 접근 가능, 많은 작업 수행 가능
- 속도: 약간 느림
- 용도: 더 복잡한 지시사항 처리
- 현재 모델: Gemini 3 (2일 전 전환)
2. Rush Agent (러시 에이전트)
- 특징: 빠름
- 용도: 루프 내(in-the-loop) 작업, 빠르고 타겟팅된 편집
왜 두 개인가?
지능(intelligence)과 속도(speed)의 프론티어를 따라 사용자 경험에 의미 있는 지점을 선택하기 위함이다.
사용자 조사 결과, 에이전트를 호출하는 두 가지 주요 모달리티(modality)를 발견했다:
- 비동기 모드: 작업을 시작하고 실행하게 한 다음, 완료되면 코드를 리뷰
- 인 루프 모드: 루프 안에서 에이전트가 편집하는 동안 빠르게 리뷰하며 에이전트를 돌보는(babysitting) 방식
Gemini 3 전환의 의미
모델 선택에 매우 신중하다. Smart 모델은 단 한 번만 전환했으며, 그것이 Gemini 3로의 전환이었다.
Gemini 3에 대한 반응은 다양하지만, 에이전트 설정에 따라 매우 다른 동작을 보인다. Amp 팀은 릴리스 전 1주일 동안 대량의 테스트를 수행하여 Gemini 3의 역량을 최대한 활용하도록 smart agent를 최적화했다. 아직 일부 문제를 해결 중이지만, Gemini 3가 가능한 것의 프론티어를 다시 이동시켰다고 확신한다.
사회적 학습과 접근성: 새로운 Craft의 전파
팀 협업과 지식 공유
Amp가 구축한 첫 번째 기능 중 하나는 팀원과 스레드를 공유하는 기능이다.
Amp를 팀에서 사용하면:
- 특정 기간 동안 사람들이 Amp로 얼마나 많은 코드를 변경했는지 확인 가능
- 특정 스레드를 살펴보고 그들이 어떻게 작업하는지 확인 가능
사람들이 이 기능을 사랑하는 이유: “여기 내가 발견한 멋진 프롬프팅 기법이 있어. 이렇게 해봐.” “여기서 막혔어. 에이전트를 피드백 루프에 더 잘 연결하여 더 나아갈 수 있는 방법을 생각하는 것을 도와줄 수 있어?”
인간 개발자는 오랫동안 존재할 것이지만, 함께 코딩하는 craft를 본질적으로 다시 배워야 한다. 스레드 공유는 이러한 학습을 가속화한다.
경제적 접근성: 터미널 광고의 실험
더 많은 사람들이 코딩 에이전트를 경험하고 작동 방식을 배우도록 하는 또 다른 측면은 경제적 관점에서의 접근성이다.
현실:
- Smart 모델은 여전히 상대적으로 비싸다
- Rush 모델은 점점 저렴해지고 있지만 아직 무료는 아니다
- 비용이 에이전트를 완전히 사용하는 데 가장 큰 장벽 중 하나다
대학 캠퍼스의 학생들과 대화해보면, 실제로 코딩 에이전트를 사용한 사람의 수는 젊은 세대의 신기술 채택 성향을 고려할 때 생각보다 훨씬 적다. 이는 주로 비용 때문이다.
급진적 해결책: 터미널 광고
누군가 팀에서 미친 아이디어를 냈다: “터미널에 광고를 넣으면 어떨까?”
처음에는 거부감이 있었지만, 추론 비용이 하락하면서 실현 가능성을 보기 시작했다. Amp는 실제로 **미니 광고 네트워크(mini ad network)**를 출시했다:
- 다른 개발자 도구를 위한 광고를 터미널과 에디터에 전달
- 매우 미묘하게(subtle) 디자인하여 침입적이지 않게
- Rush agent의 추론 비용을 스폰서하여 더 많은 사람들이 사이드 프로젝트에서 경험할 수 있도록
커뮤니티와 비전: 미래에 사는 사람들
주목할 만한 사용자들
Amp는 과대광고(hype)나 유료 개발자 인플루언서 마케팅을 하지 않는다. 대신 미래에 조금 살고 싶어 하는 소수의 사람들을 타겟팅한다.
주목할 만한 사용자:
- Mitchell Hashimoto: HashiCorp 창립자 겸 전 CEO, 현재 Ghosty(오픈소스 터미널) 구축 중, Amp를 사용하여 Ghosty에 많은 변경 사항을 적용
- Hamill Hussein: AI evals의 선도적 권위자, 몇 주 전 Amp를 자신이 가장 좋아하는 코딩 에이전트라고 언급
둘 다 팀원도 아니고 투자자도 아니지만, Amp가 만들고 있는 것을 좋아한다는 사실이 팀에게 큰 의미다.
Builder Community: 경이로움을 공유하는 공간
Ryan Carson(전 Treehouse 창업자, 100만 명 이상에게 코딩 교육)이 운영하는 빌더 커뮤니티를 시작했다.
특징:
- Amp 사용이 가입 조건이 아님
- 에이전트로 구축하고 에이전트를 더 밀어붙이는 방법을 실험하는 사람들을 위한 공간
- 경이로움과 놀라움(awe and wonder)의 감각을 동료 집단과 함께 나누는 것이 핵심
- 이상함과 실험의 감각을 받아들이는 문화
활동:
- 정기적인 인터뷰: 흥미로운 것을 만들거나 에이전트를 흥미로운 방식으로 사용하는 사람들 피처
- 대면 이벤트: 실제 에이전트 구축부터 AI의 본질에 대한 철학적 논의까지 흥미로운 대화
결론: 다르게 생각하기로의 초대
Beyang Liu는 청중 모두가 Amp가 최고의 프론티어 코딩 에이전트를 구축하고 있다고 확신하기를 기대하지 않는다고 솔직하게 말한다.
그러나 최소한 다음을 보여주기를 희망한다:
- Amp가 이상함(weird)을 받아들이고 있다는 것
- 다르게 생각하고 있다는 것
이것이 흥미롭다면, 황금 물고기를 타고 있는 이상한 Pied Piper 남자를 찾아 부스에 들러보라는 초대로 강연은 끝난다.
Amp Code는 단순히 또 하나의 AI 도구가 아니라, 에이전트와 함께 코딩하는 미래를 먼저 살아보고, 그 경험을 통해 새로운 개발 패러다임을 정의하려는 대담한 실험이다.