에이전트가 쏟아낸 코드를 사람이 다 읽어야 한다 — ADE가 나온 이유

About this offer

에이전트가 쏟아낸 코드를 사람이 다 읽어야 한다 — ADE가 나온 이유 ADE(Agentic Development Environment)는 코딩 에이전트를 여러 개 동시에 돌리고, 그 결과를 받아 확인하는 작업 환경이다. 에디터가 "코드를 쓰는 창"이라면 ADE는 "일을 나눠 주고 결과를 받는 관리대"에 가깝다. 터미널에서 출발한 Warp, 오픈소스 데스크톱 앱 Orca, 구글의 Antigravity, 에디터에서 넘어온 Cursor가 이 자리를 놓고 경쟁한다. 코드가 나오는 속도는 지난 2년 동안 크게 올랐다. 읽는 속도는 그대로다. Warp가 자사 블로그에 이렇게 적는다. 개발의 가장 큰 병목은 더 이상 코드를 쓰는 것이 아니다. 코드 주변에서 사람이 하는 일 — 무엇을 만들지 정하고, 동작이 맞는지 확인하는 일이다. 에디터는 코드를 쓰는 자리를 다듬어 왔다. 그 자리가 더 이상 병목이 아니라면 도구도 확인하는 쪽으로 옮겨가야 한다. ADE가 그렇게 나왔다. ADE가 무엇인가 Orca는 같은 것을 화면 구성으로 설명한다. 여러 AI 코딩 에이전트를 나란히 돌리는 데스크톱 IDE. 작업마다 자기 git worktree, 자기 에이전트 터미널, 자기 브라우저 탭을 갖는다. 여기서 worktree 는 git이 제공하는 기능이다. 같은 저장소를 디스크의 여러 폴더에 동시에 펼쳐 두고, 각 폴더가 서로 다른 브랜치를 본다. 에이전트 셋이 같은 파일을 동시에 고쳐도 서로 덮어쓰지 않는 이유가 이것이다. 각 폴더의 작업 결과는 diff , 즉 바뀐 줄만 추려 보여주는 비교 화면으로 확인한다. 주의 — 같은 약어가 세 가지를 가리킨다 ADE를 검색하면 서로 다른 것이 섞여 나온다. 풀어 쓰면 쓰는 곳 무엇을 하는 도구인가 Agentic Development Environment Warp 코딩 에이전트 운용 Agent Development Environment Orca 코딩 에이전트 운용 Agent Development Environment Letta 에이전트 자체를 만드는 도구 Warp와 Orca는 약어를 다르게 푸는데 하는 일이 같다. Letta는 약어가 Orca와 똑같은데 하는 일이 다르다. Letta의 ADE는 에이전트의 기억과 도구 설정을 사람이 열어 고치는 화면이다. 코딩 에이전트를 여러 개 돌리는 것과는 상관이 없다. 이 글에서 ADE는 Warp와 Orca 쪽, 코딩 에이전트를 운용하는 도구만 가리킨다. 그리고 ADE는 업계가 합의한 말이 아니다. 제품 이름표로 ADE를 내건 곳은 Warp와 Orca 둘뿐이다. 나머지는 각자 다르게 부른다. Google은 "agentic development platform", Cursor는 "agent-first interface", Zed는 "여러 에이전트를 지휘한다", JetBrains는 "제품들의 묶음"이다. 부르는 말은 제각각인데 만드는 화면은 서로 닮아 있다. 왜 쓰나 확인할 양이 늘었다 에이전트가 하루에 1,000줄을 내놓으면 1,000줄을 읽어야 한다. 읽는 일 자체는 전과 똑같은데 양만 몇 배로 늘어난다. 게다가 직접 쓰지 않은 코드 다. 손으로 쓴 코드는 확인의 상당 부분이 쓰는 동안 끝난다. 왜 그렇게 했는지 쓴 사람이 알고 있기 때문이다. 받은 코드는 의도부터 짐작해야 한다. 그리고 에이전트는 그럴듯하게 틀린다. 문법이 틀리면 컴파일러가 잡는다. 돌아가는데 잘못된 코드는 사람이 읽어야만 걸린다. 숫자가 이 간극을 보여준다. 구글의 개발 성과 연구 프로그램 DORA가 2025년에 기술 전문가 약 5,000명에게 물었다. AI가 생산성을 높였다고 답한 비율은 80%를 넘었다. 같은 조사에서 AI가 만든 코드 를 "상당히" 또는 "많이" 신뢰한다고 답한 비율은 24% 였다. 빨라졌다고는 하는데 그 결과물을 믿지는 않는다. 믿지 않으면 전부 확인해야 한다. 쓰는 사람은 계속 는다. Stack Overflow 개발자 조사에서 AI 도구를 쓴다고 답한 비율은 2023년 44%, 2024년 62%, 2025년 79%였다. 에이전트로 좁히면 2025년 31%에서 2026년 4월 59%로 올랐다. 뒤의 둘은 조사 설계가 서로 달라 같은 집단을 추적한 값이 아니다. 기다리는 시간이 아깝다 에이전트 하나에 일을 시키면 끝날 때까지 사람이 논다. 결제 모듈을 리팩터링하라고 시켜 놓고 5분을 기다린다. 결과가 마음에 안 들면 다시 시키고 또 기다린다. 같은 5분에 셋을 돌리면 결과가 셋 나온다. Cursor는 이 효과를 이렇게 적는다. 여러 모델에 같은 문제를 풀게 하고 가장 좋은 결과를 고르면 최종 산출물이 눈에 띄게 좋아진다. 어려운 과제일수록 그렇다. Orca는 비용까지 들어 설명한다. 에이전트마다 다른 실수를 한다. 같은 과제를 병렬로 돌리는 것이 순차 재시도보다 싸고, 의견이 갈리는 지점이 신호가 된다. 셋이 같은 답을 내면 대개 맞다. 셋이 갈리면 거기가 어려운 지점이다. 에이전트 하나만 돌렸으면 그냥 넘어갔을 자리를 세 결과의 차이가 가리킨다. 읽을 곳이 좁혀진다. 확인하기 좋은 형태로 받는다 에이전트가 무슨 짓을 했는지 터미널 로그로 쫓는 것은 느리다. Google Antigravity는 결과를 Artifacts 라는 형태로 내놓는다. 작업 목록, 구현 계획, 변경 설명, 스크린샷, 브라우저 녹화다. 공식 문서의 표현은 이렇다. 원시 도구 호출보다 개발자가 검증하기 쉽다 ADE가 파는 것이 결국 이것이다. 더 똑똑한 모델이 아니라 확인하기 쉬운 형태 다. 기존 IDE와 무엇이 다른가 세 가지가 다르다. 작업 단위가 파일이 아니라 과제다. IDE는 파일을 열고 함수를 고친다. ADE는 "결제 모듈 리팩터링"이라는 과제를 통째로 넘기고 결과를 받는다. Antigravity는 이것을 "더 높은, 과제 중심의 수준에서 일하게 한다"고 적는다. 창이 하나가 아니라 여럿이다. IDE는 한 프로젝트를 한 창에서 연다. Cursor 3.0은 반대로 간다. 새 인터페이스는 여러 저장소와 여러 환경에 걸쳐 에이전트를 병렬로 돌리게 해준다. 로컬, worktree, 클라우드, 원격 SSH에서. 주인공이 바뀐다. 이 변화를 Antigravity가 가장 선명하게 적었다. 에이전트가 화면 안에 들어가 있던 구도를, 화면이 에이전트 안에 들어가는 구도로 뒤집는다. 지금까지 AI는 에디터에 붙은 기능이었다. 자동완성 패널, 사이드바 챗이다. Antigravity가 화면 둘을 나란히 두는 것이 그래서다. Editor View는 평소 쓰던 AI 에디터다. Manager Surface는 "여러 에이전트를 여러 작업공간에서 띄우고, 지휘하고, 지켜보는 전용 화면"이다. 대표 프로그램 이름 바탕 격리 방식 가격 Warp 터미널 로컬 worktree + 클라우드 Docker 오픈소스(AGPL v3) + 유료 클라우드 Orca 데스크톱 앱 git worktree MIT, 무료 Google Antigravity 에디터 + 관리 화면 작업공간 분리 무료 티어 있음, Ultra 월 $100 Cursor 에디터 worktree · 클라우드 · 원격 SSH 유료 Devin 클라우드 클라우드 샌드박스 무료 · 월 $20–$200 Zed 에디터 worktree(스레드별 선택) 오픈소스 Claude Code CLI --worktree 옵션 구독 격리 방식은 둘로 갈린다. worktree는 디스크 에서 폴더를 나누고, 클라우드 샌드박스는 기계 자체 를 따로 띄운다. Warp — 터미널에서 출발했다 2026년 4월 28일 클라이언트를 AGPL v3로 공개했다. 서버 쪽은 비공개로 남겼다. 로컬에서 여러 세션을 띄우거나, 에이전트마다 worktree를 하나씩 주거나, Oz라는 클라우드 플랫폼으로 넘겨 돌릴 수 있다. Oz는 2026년 2월 10일에 나왔고 Docker 샌드박스에서 에이전트를 돌린다. 기업용 자체 호스팅 선택지도 있다. 지휘 구조에 제한을 뒀다. 공식 문서 표현으로 "정확히 한 단계 깊이 — 부모와 그 직속 자식뿐" 이다. 부모가 자식 N개를 띄워 각자 다른 조각을 맡긴다. 전부 끝나면 결과를 합친다. 자식이 또 자식을 낳지는 않는다. 부모 에이전트 ├── 자식 1 — packages/api ├── 자식 2 — packages/web └── 자식 3 — 테스트·문서 확인 화면은 Interactive Code Review다. 변경된 줄에 인라인으로 의견을 달고, 여러 개를 모아 한 번에 에이전트에게 보낸다. 에이전트는 그 묶음을 한 번에 반영해 새 diff를 돌려준다. Orca — 무료이고 아무 에이전트나 꽂는다 데스크톱(macOS·Windows·Linux)에 모바일 동반 앱이 붙는다. 특징은 에이전트를 가리지 않는다 는 점이다. Claude Code, Codex, Gemini, Cursor, GitHub Copilot, Devin, Cline 등 30여 종의 CLI 에이전트를 꽂아 쓴다. 각 에이전트는 이미 들고 있는 구독을 그대로 쓴다. 대상 독자를 공식 문서가 직접 적어 뒀다. 이미 코드로 먹고살면서 AI를 지렛대로 쓰려는 사람을 위해 만들었다. 대체가 아니다. diff를 읽고, 커밋을 신경 쓰고, worktree를 정돈하는 사람 을 전제한다. 확인은 diff 줄에 마크다운 의견을 달아 묶음으로 되돌리는 방식이다. Google Antigravity — 화면 둘을 나란히 2025년 11월 18일 공개 프리뷰로 나왔다. 2026년 5월 19일 I/O에서 2.0이 나왔다. 독립 데스크톱 앱과 CLI가 붙었다. 무료 티어도 주 단위로 갱신되는 사용량 안에서 CLI까지 전부 쓴다. Cursor — 에디터가 관리대를 흡수했다 2026년 4월 2일 3.0에서 Agents Window가 들어왔다. 여러 저장소와 환경에 걸쳐 에이전트를 병렬로 돌린다. worktree 운용이 명령어로 들어가 있다. /worktree 로 격리된 작업 폴더를 만들고, /apply-worktree 로 본 체크아웃에 반영하고, /delete-worktree 로 치운다. /best-of-n 은 여러 모델에 같은 일을 시켜 결과를 비교한다. worktree마다 필요한 준비 명령은 .cursor/worktrees.json 에 적어 둔다. Devin — 동시 실행 개수가 요금제다 다른 도구와 달리 동시에 띄울 수 있는 세션 수가 요금제로 정해져 있다. 무료와 Pro는 최대 10개, Max와 팀은 무제한이다. Zed, Claude Code, JetBrains Air Zed는 2026년 4월 22일 병렬 에이전트를 넣었다. 한 창 안에서 여러 에이전트가 동시에 돈다. Threads Sidebar에서 에이전트마다 접근 가능한 폴더와 저장소를 지정 하고 진행 상황을 본다. worktree 격리는 스레드별로 켜고 끈다. Claude Code는 CLI 쪽 방식이다. 터미널마다 이름을 달리해 띄우면 그만큼 격리된 작업이 생긴다. claude --worktree feature-auth # 첫 번째 터미널 claude --worktree fix-login # 두 번째 터미널 저장소에 커밋이 최소 하나는 있어야 worktree가 만들어진다. 커밋이 없으면 Failed to resolve base branch "HEAD" 로 실패한다. JetBrains는 2026년 9월 22일 Air를 발표했다. 특정 모델에 묶이지 않는 것을 설계 원칙으로 내세웠고, 목표를 이렇게 적었다. 목표는 더 많은 코드가 아니다. 개발자와 팀과 조직이 이해하고, 검증하고, 책임질 수 있는 소프트웨어다. 쓰는 팁 아래는 전부 각 제품 공식 문서에 적혀 있는 권고다. 공식 권장 숫자는 Orca의 셋뿐이다 구체적인 숫자를 적어 둔 곳은 Orca 하나다. 첫 사용 안내가 worktree를 셋 만들게 하고, 병렬 사용법 문서도 "세 브랜치, 세 diff, 같은 프롬프트"로 시작한다. 규모 감각도 적어 뒀다. worktree 열 개는 감당하기 벅차다. Warp, Cursor, Zed, Antigravity, Claude Code는 권장 개수나 상한을 문서에 적지 않았다. Devin의 10개는 권고가 아니라 요금제 상한이다. "셋"이 두 가지 뜻이다 같은 "에이전트 3개"가 운용 방식에 따라 완전히 다르다. 같은 과제를 셋에 다른 과제를 셋에 하는 일 같은 프롬프트, 결과 셋을 비교해 승자를 고른다 작업을 쪼개 각자 다른 부분을 맡긴다 쓰는 곳 Orca, Cursor /best-of-n Warp 얻는 것 품질, 그리고 의견 차이라는 신호 시간 어려운 과제에는 앞쪽이 맞고, 범위가 넓고 명확한 작업에는 뒤쪽이 맞다. 작업은 파일·패키지·테스트로 쪼갠다 Warp 문서가 구체적이다. 시작하기 전에 파일·패키지·테스트·이슈 중 무엇을 누가 갖는지 정하라고 한다. 예로 든 분할은 이렇다. 한 에이전트에 packages/api , 다른 에이전트에 packages/web , 세 번째에 테스트와 문서. 겹칠 수밖에 없을 때의 규칙도 있다. 두 에이전트가 같은 파일을 건드려야 한다면 한쪽을 주인으로 정하고 , 다른 쪽에는 고치지 말고 검토하거나 제안만 하게 한다. 합칠 때 — 자동으로 합치지 않는다 모든 에이전트의 결과를 자동으로 머지하지 마라. 모으는 단계를 따로 둔다. 각 에이전트의 요약, 바뀐 파일, 검증 결과를 확인하고 한 브랜치씩 머지하거나 체리픽한다. 체리픽은 브랜치를 통째로 합치지 않고 필요한 커밋만 골라 가져오는 것이다. 브랜치 이름에 주인을 드러내라는 조언도 붙는다. agent/claude-auth-refactor , agent/codex-auth-tests 같은 식이다. import·에러 처리·인증부터 본다 Warp는 세 곳을 짚는다. import 구문, 에러 처리, 그리고 보안이나 인증에 닿는 코드 다. 통합 전에는 전체 파일을 가로지르는 합친 diff를 한 번 보라고 한다. Cursor는 확인을 건너뛰지 말라고 못 박는다. AI가 쓴 코드는 리뷰가 필요하다. 정리는 자주 Orca의 조언이다. 머지한 worktree는 과감하게 지워라. 한 번 클릭이면 worktree와 브랜치가 같이 사라진다. 머지된 것을 수십 개씩 쌓아 두면 탐색만 느려진다. 쟁점 공식 문서에서 끝내 찾지 못한 것이 둘 있다. 머지 충돌이 실제로 났을 때 푸는 절차 와 에이전트가 실패한 뒤의 복구 절차 다. 아래 쟁점들도 같은 자리에서 나온다. 승자를 무엇으로 고르나 같은 과제를 셋에 돌려 가장 좋은 것을 고르라는 조언은 Orca에도 Cursor에도 있다. 무엇을 기준으로 고르라는 문서는 어느 쪽에도 없다. 테스트가 다 통과한 결과가 둘이면 거기서부터는 읽어 보는 수밖에 없다. 결과를 셋으로 늘리는 일은 자동화됐는데, 그중 하나를 고르는 일은 자동화되지 않았다. 싸다는 근거가 파는 쪽에서 나온다 "병렬이 순차 재시도보다 싸다"는 문장은 Orca 공식 문서의 주장이다. 토큰을 세 배 쓰는 대신 사람이 기다리는 시간을 줄인다는 계산인데, 어느 선부터 손해인지 알려주는 공식 가이드는 없다. 과제가 쉬우면 셋 다 같은 답을 내고 두 번은 버려진다. 어려울수록 이득이 커진다는 Cursor의 설명이 맞다면, 쉬운 일에 병렬을 쓰는 것이 가장 비싼 선택 이 된다. 격리를 어디까지 해야 하나 지금 두 갈래로 갈려 있다. git worktree 클라우드 샌드박스 나누는 것 디스크의 폴더 기계 자체 강점 가볍고 빠르다 포트 충돌·전역 설정 오염까지 막는다 약점 같은 기계를 쓴다 느리고 돈이 든다 Warp는 둘 다 제공하고, Zed는 스레드마다 켜고 끄게 한다. 어느 쪽이 맞는지는 아직 합의가 없다. 믿지 않으면서 쓴다 앞서 본 24%가 이 도구들이 서 있는 자리다. 믿지 않는데 쓴다. ADE는 이 상태를 전제로 만들어진 도구다. 신뢰를 올리려 하지 않고, 믿지 않아도 쓸 수 있게 확인 화면을 깐다. 신뢰가 올라가면 이 도구들의 생김새도 달라질 것이고, 올라가지 않으면 확인 화면은 계속 두꺼워진다. 정리 ADE가 하는 일은 결국 셋이다. 결과를 diff로 묶어 주고, worktree로 갈라 두고, 의견을 모아 한 번에 되돌린다. 고를 때 볼 것은 세 가지다. 격리를 어디까지 하나 — 디스크에서 나누는 worktree와 머신까지 나누는 클라우드 샌드박스가 다르다. Warp와 Cursor는 둘 다 되고, Orca·Zed·Claude Code는 디스크까지, Devin은 머신 쪽이다 에이전트를 가리나 — Orca·Zed·Cursor는 외부 에이전트나 모델을 꽂게 열어 뒀고, Antigravity와 Devin은 자사 쪽으로 묶인다 확인 화면이 있나 — 인라인 의견을 묶어 보내는 기능이 있는지가 실제 작업 속도를 가른다 다만 이 도구들이 메우는 것은 격차의 한쪽뿐이다. 확인을 쉽게 만들었지 덜 하게 만들지는 않았다. 읽어야 할 양은 그대로이고, 읽는 사람도 그대로다. 에이전트를 셋으로 늘리면 확인할 결과도 셋이 된다. 참고 Warp, Warp is now open source · 문서 · 여러 에이전트 돌리기 · AI 코드 리뷰하기 · Oz Orca, onorca.dev · 문서 · 병렬 에이전트 · GitHub Google, Antigravity 소개 · 개발자 블로그 · I/O 2026 Cursor, 3.0 변경사항 · Agents Window · Worktrees · 에이전트 모범 사례 Devin, 요금제 Zed, 병렬 에이전트 Claude Code, 일반 워크플로 JetBrains, Air 소개 Stack Overflow, 개발자 조사 돌아보기 Google, DORA 2025 리포트