꿈의 코딩 에이전트는 왜 아무도 만들지 않는가#

2026-10-18

작업대 위 설계도에 그려진 로봇의 윤곽 가운데 일부 칸만 실제 부품으로 채워져 있고, 빈칸에서 스위치가 늘어선 길, 닫힌 문으로 막힌 길, 안개 속으로 사라지는 길의 세 갈래가 뻗어 나가며 작은 로봇이 그 갈림길을 바라보는 모습

린치의 불만은 필자의 불만이기도 합니다#

마이클 린치(Michael Lynch)는 2026년 10월 9일 「코딩 에이전트는 왜 이렇게 멍청한가(Why are coding agents so dumb?)」라는 글을 올렸습니다. 요지는 모델은 크게 좋아졌는데, 모델을 감싸는 에이전트는 2025년 2월 이후 거의 그대로라는 것입니다. 필자는 2026-10-11 AI 뉴스 브리프에서 이 글을 소개하며 “필자의 작업 환경도 이 글의 불만 대부분에 해당한다"고 적었습니다.

그가 드는 사례는 구체적입니다.

열 개로 나눈 하위 작업을 동시에 돌려도 되는데 하나씩 순서대로 처리합니다.
5만 줄에서 패턴 하나를 찾는 단순한 일에도 가장 비싼 모델을 씁니다.
자기 기능을 모르면 웹을 검색하고, 다음 세션에서 같은 검색을 되풀이합니다.
밤새 맡긴 작업이 2분 만에 브랜치 이름을 묻고 멈춘 채 아침까지 기다렸습니다.
읽지 말라고 문서에 적어 둔 파일을 읽어, 애플리케이션 비밀 키가 모델 제공자의 서버로 넘어갔습니다.

글 후반에서 그는 “꿈의 에이전트"가 갖춰야 할 조건을 열일곱 개 적었습니다. 필자는 이 목록을 들고 두 가지를 확인해 보고 싶었습니다. 첫째, 2026년 10월 현재 Claude Code, Codex, GitHub Copilot, Cursor 같은 주요 코딩 에이전트(이하 메이저 에이전트)와 Hermes Agent, OpenCode, Pi 같은 오픈소스 에이전트가 이 조건에 얼마나 대응하고 있는가. 둘째, 대응하지 못한 부분이 모든 사용자를 만족시켜야 하는 범용 제품이라서 생긴 것이라면, 특정 사용자층을 노린 새 에이전트가 그 빈자리를 차지할 수 있는가.

두 번째 질문을 위해 용어 하나를 먼저 정해 두겠습니다. 이 글에서 틈새 에이전트는 특정 사용자층을 겨냥해, 범용 에이전트가 채우지 않는 요구를 전면에 내세우는 새 코딩 에이전트를 말합니다. 마케팅에서 말하는 틈새시장(niche market)을 노린 제품이라는 뜻이고, 기능 하나가 아니라 제품 전략을 가리킵니다. 이 글이 상정하는 사용자층은 린치 같은 파워 유저나 보안에 민감한 조직입니다.

결론부터 적으면 이렇습니다. 빈칸은 한 가지 이유로 생기지 않았습니다. 범용성과 충돌해서 생긴 빈칸, 모델 회사의 이해관계와 충돌해서 생긴 빈칸, 아직 아무도 풀지 못해서 생긴 빈칸이 섞여 있습니다. 틈새 에이전트가 이길 수 있는 곳은 두 번째 갈래뿐이고, 그마저도 에이전트를 새로 만드는 방식이 아니라 공식 에이전트 위에 지휘 계층을 얹는 방식으로만 성립한다고 봅니다.

꿈의 에이전트가 요구하는 것#

린치의 목록은 “기본으로 갖춰야 할 것” 열 개와 “더 큰 바람” 일곱 개로 되어 있습니다. 필자는 성격에 따라 네 묶음으로 다시 나눴습니다.

격리: 에이전트가 건드릴 수 있는 범위를 정하는 조건입니다.

OS가 강제하는 샌드박스: “이 파일은 읽지 마세요” 같은 부탁이나 명령어 정규식 목록이 아니라, 운영체제가 파일 시스템과 네트워크 경계를 강제해야 합니다.
저장소별 접근 권한: 기본은 작업 중인 저장소 하나이고, 다른 저장소는 세션마다 읽기 전용이나 읽기·쓰기로 열어 줍니다.
비밀값 주입 프록시: 에이전트는 비밀값 대신 대체 문자열만 보고, 실제 값은 허용된 호스트로 나가는 요청에만 프록시가 끼워 넣습니다. 비밀값을 쓸 수는 있어도 빼돌릴 수는 없게 만드는 장치입니다.

지휘: 여러 작업과 모델을 나눠 쓰는 조건입니다.

작업 분할과 모델 매칭: 일을 쪼개 단순한 일은 싸고 빠른 모델에, 어려운 일은 강한 모델에 맡기고, 사용자가 작업별로 조정할 수 있어야 합니다.
사용자가 지휘하는 서브에이전트: 어느 하위 세션에든 들어가 방향을 바꾸거나 일찍 끝낼 수 있어야 합니다.
보정되는 ETA: ETA(Estimated Time of Arrival, 도착 예정 시각)는 여기서 작업이 끝날 예상 시각을 뜻합니다. 작업마다 남은 시간을 보여 주고, 지난 예측이 얼마나 빗나갔는지를 반영해 점점 정확해져야 합니다.
쿼터를 보는 모델 선택: 남은 사용량과 리셋 시점을 보고 모델을 고릅니다. 곧 리셋될 쿼터가 넉넉하면 비싼 모델을 더 쓰는 식입니다.
교차 모델 리뷰: 복잡한 작업은 다른 모델이 검토하고, 두 모델이 합의할 때까지 반복합니다.

자율과 자기 인식: 사람이 없어도 일을 이어 가는 조건입니다.

사람이 읽을 수 있는 계획: 큰 그림에서 세부로 내려가고, UI 목업, 데이터 흐름도, 결정 트리를 담습니다.
미응답 시 자율 결정: 실행 중 던진 질문에 30분 동안 답이 없으면 스스로 정하고, 자리 비움(AFK) 모드에서는 아예 기다리지 않습니다.
자기 기능 인지: 자기 기능과 설정법을 웹 검색 없이 압니다.
세션 자기 리뷰: 지난 세션을 돌아보고 개선합니다. 로그를 매번 즉석에서 파싱하느라 토큰을 낭비했다면 전용 도구를 만들어 두는 식입니다.
정확한 오류 메시지: 플랜과 사용량에 관한 오류가 모호하거나 틀리지 않아야 합니다.
통합 로컬 대시보드: 모든 세션과, 그중 사람의 응답이 필요한 세션을 한 화면에서 봅니다. 외부 터널 없이 로컬에서 돌고 휴대폰에서도 열립니다.
언어를 인식하는 로컬 diff: 아래에서 따로 설명합니다.

개방성: 특정 회사에 묶이지 않는 조건입니다.

제공자 자유: 어떤 LLM 제공자든 쓸 수 있고, 정액제 무제한 플랜도 연결할 수 있어야 합니다.
오픈소스: 코드가 공개되어 있어야 합니다.

“언어를 인식하는 diff"는 설명이 조금 필요합니다. 보통의 git diff는 코드를 텍스트 줄의 나열로 보고 어느 줄이 지워지고 추가됐는지만 비교합니다. 언어를 인식하는 diff는 코드를 그 언어의 문법으로 파싱해 구조 단위로 비교합니다. 기존 코드 두 줄을 if 블록으로 감싼 경우를 보겠습니다.

// 변경 전
const result = compute(a, b);
save(result);

// 변경 후
if (enabled) {
  const result = compute(a, b);
  save(result);
}

줄 단위 diff는 들여쓰기가 바뀐 두 줄까지 지우고 새로 쓴 것으로 보여 줍니다. 구조를 비교하는 diff는 if (enabled) {와 }가 추가됐다는 사실만 보여 줍니다. 에이전트는 한 번에 수백 줄을 고치면서 포맷도 자주 건드리기 때문에, 줄 단위 diff에서는 진짜 변경이 노이즈에 묻힙니다. 린치는 이런 diff를 GitHub에 올리지 않고 로컬에서 바로 보고 싶다고 했습니다.

2026년 10월, 빈칸은 생각보다 적습니다#

아래 표는 2026년 10월 중순 기준으로 각 도구의 공식 문서와 변경 기록을 중심으로 확인하고, 일부는 서드파티 자료로 보완한 결과입니다. 도구마다 다 적지 않고, 조건에 가장 가까운 구현만 골랐습니다.

조건	가장 가까운 구현	판정
OS 샌드박스	Codex, Claude Code, Copilot	부분
저장소별 접근 권한	Codex(베타), Copilot, Cursor	부분
비밀값 주입 프록시	Claude Code, Copilot CLI, Hermes(Docker)	부분
작업 분할·모델 매칭	Cursor Router, Copilot HydraFusion	부분
서브에이전트 지휘	Claude Code, OpenCode	지원
보정되는 ETA	없음	공백
쿼터를 보는 모델 선택	플러그인 수준	공백
합의까지 반복하는 교차 리뷰	HydraFusion(1회 수정)	공백
읽히는 계획	Cursor(Mermaid 다이어그램)	부분
미응답 시 자율 결정	Claude Code(opt-in), Copilot	부분
자기 기능 인지	Gemini CLI, Pi	부분
세션 자기 리뷰	Hermes Agent	부분
정확한 오류 메시지	수정 진행 중	부분
로컬 대시보드	OpenCode, Hermes Agent	부분
언어 인식 diff	없음(difftastic 수동 연결)	공백
제공자 자유	오픈소스 에이전트	지원
오픈소스	오픈소스 에이전트, Codex CLI	지원

열일곱 개 가운데 아무도 손대지 않은 칸은 네 개뿐입니다. 필자가 예상한 것보다 훨씬 적었습니다. 대신 “부분"으로 적은 칸들은 모양이 비슷합니다.

기본값이 꺼져 있습니다. Claude Code의 샌드박스는 공식 문서에 “기본적으로 꺼져 있다"고 적혀 있습니다. GitHub Copilot의 로컬 샌드박스도 10월 7일 정식 출시됐지만 마찬가지로 기본값은 꺼짐입니다. Claude Code에서 질문에 답이 없을 때 스스로 진행하게 하는 대기 시간 제한도 사용자가 /config에서 켜야 합니다.

적용 범위가 좁습니다. Claude Code의 샌드박스는 셸 명령만 감쌉니다. 파일 읽기와 편집 도구, MCP(Model Context Protocol) 서버, hook은 샌드박스 밖에서 실행됩니다. 공식 문서는 “denyRead 항목은 Read 도구를 막지 못한다"고 분명히 적어 둡니다. 린치가 겪은 “읽지 말라는 파일을 읽은” 사고는, 샌드박스를 켜더라도 파일 도구 경로라면 샌드박스가 아니라 권한 규칙으로 막아야 합니다. 8월 초 2.1.221 버전에 들어온 비밀값 대체 기능 mask도 셸 명령에만 적용됩니다. Copilot 문서 역시 내장 파일 도구는 같은 프로세스 안에서 돌기 때문에 OS 샌드박스가 제한할 수 없고, 도구가 스스로 정책을 확인하는 수준이라고 밝힙니다.

한 번 하고 멈춥니다. GitHub Copilot의 연구 프리뷰 HydraFusion은 작업마다 실행 방식을 고릅니다. 모델 하나가 처리하거나(Single), 싼 모델이 초안을 쓰고 부족하면 강한 모델로 올리거나(Cascade), 다른 모델이 비평하게 합니다(Critique). 린치의 “작업별 모델 매칭"과 “교차 모델 리뷰"에 가장 가까운 구현입니다. 다만 공식 문서에 따르면 Critique는 처음 모델이 한 번 고치고 끝나며, 사용자는 어떤 모델을 쓸지 고를 수 없습니다.

오픈소스 쪽은 모양이 반대입니다. 제공자 자유와 오픈소스는 기본으로 갖췄지만 격리가 약합니다. OpenCode와 Cline은 앱 수준의 권한 규칙에 머뭅니다. Hermes Agent는 Docker 같은 컨테이너 백엔드를 골라야 실질적으로 격리되고, Pi는 의도적으로 권한 시스템을 두지 않는 대신 Gondolin 같은 마이크로 VM 확장을 안내합니다.

필자는 브리프에 Microsoft의 MXC, Copilot 로컬 샌드박스, HydraFusion이 “정확히 이 글이 요구한 목록에 대한 답"이라고 적었습니다. 표를 채우고 보니 반만 맞는 말이었습니다. 방향은 맞지만, 기본값과 적용 범위와 반복 횟수에서 아직 린치의 요구에 미치지 못합니다.

첫 번째 빈칸: 모두를 만족시키려다 생긴 기본값#

샌드박스가 기본으로 꺼져 있는 이유는 짐작하기 어렵지 않습니다. 운영체제 수준에서 경계를 강제하면 빌드 도구, 패키지 관리자, 키체인, SSH 에이전트, Docker처럼 경계 밖을 건드려야 하는 도구가 깨집니다. 수많은 사용자의 첫 경험이 “아무것도 안 된다"로 시작하면 제품이 버티기 어렵습니다. 그래서 기본값을 꺼 두고, 켠 뒤에도 출구를 남깁니다. Claude Code는 샌드박스 안에서 실패한 명령을 샌드박스 밖에서 다시 시도할 수 있게 하고, 샌드박스를 띄우지 못하는 환경에서는 기본적으로 보호 없이 실행합니다. 둘 다 설정으로 막을 수 있지만, 막는 쪽이 선택 사항입니다.

필자도 이 기본값의 논리를 몸으로 겪었습니다. Claude Code의 샌드박스를 켜 봤다가 불편해서 끄고, 응답을 꼼꼼히 읽는 것으로 위험을 관리해 왔습니다. 그 판단을 다시 점검한 과정은 불편해서 껐던 샌드박스, 다시 켜기 전에 따져 본 것들에 정리했습니다. 파워 유저인 필자도 끄는 기능을 일반 사용자에게 기본으로 켜 두기는 어렵습니다.

자율 결정도 같은 구조입니다. Claude Code는 2.1.200 버전에서 질문 창이 답 없이 자동으로 넘어가던 동작을 기본으로 끄고, 대기 시간 제한을 직접 켜는 방식으로 바꿨습니다. 사용자가 많을수록 “에이전트가 마음대로 정했다"는 사고의 책임도 커집니다. 기다리는 것을 기본으로 두고 자율은 사용자가 명시적으로 고르게 하는 것은, 범용 제품으로서는 합리적인 선택입니다.

정책 관리의 우선순위도 범용성에서 나옵니다. 돈을 내는 쪽은 조직이라서, 샌드박스 정책은 관리자가 일괄 배포하는 형태부터 다듬어집니다. MXC는 Microsoft의 기기 관리 도구(Intune, Entra) 연동을 예고했습니다. 반면 개인이 세션마다 “이 저장소는 읽기만 허용"을 고르는 화면은 뒤로 밀립니다.

여기까지는 “범용 목적과 충돌해서 생긴 빈칸"이라는 가설이 정확히 맞습니다. 다만 이 갈래에는 함정이 있습니다. 메이저 에이전트는 이미 스위치를 갖고 있습니다. 샌드박스를 엄격하게 강제하는 설정도, 질문 대기 시간 제한도 있습니다. 린치가 원하는 것의 상당 부분은 “다른 기본값"이고, 다른 기본값은 제품이 아니라 설정 파일 하나로 만들 수 있습니다. 틈새 에이전트가 “엄격한 기본값"을 내세운다면 그것은 설정 파일을 파는 셈이고, 메이저가 다음 릴리스에서 프리셋 하나만 추가해도 사라질 차이입니다.

두 번째 빈칸: 모델 회사가 할 이유가 없는 기능#

남은 사용량을 보고 모델을 고르는 기능, 다른 회사 모델로 작업을 보내는 라우팅, 다른 회사 모델에게 맡기는 교차 리뷰는 성격이 다릅니다. 기술적으로 어렵다기보다 만드는 회사의 이해관계와 어긋납니다.

Claude Code는 Claude 모델만 씁니다. 모델을 만드는 회사가 자사 에이전트 안에서 경쟁사 모델로 작업을 넘길 이유는 약합니다. 쿼터도 비슷합니다. Claude Code는 /usage로 사용량을 보여 주지만, 그 정보로 모델을 바꿔 고르지는 않습니다. 사용량 한도도 5시간 단위, 주 단위, 모델별로 겹쳐 있어 바깥에서 계산하기 어렵습니다. 사용자가 쿼터를 정확히 보고 아껴 쓰게 돕는 기능은 공급자의 매출과 반대 방향을 향합니다. 이 부분은 필자의 추론입니다.

그래서 이 칸을 채우는 쪽은 모델을 직접 만들지 않는 회사들입니다. 앞에서 본 HydraFusion이 그렇고, GitHub은 10월 7일 Copilot CLI가 Ollama 같은 로컬 모델 런타임을 찾아내는 기능을 내놓으며 간단한 작업을 로컬 모델로 보내는 라우팅을 예고했습니다. Cursor는 8월 6일 공개한 글에서 Cursor Router의 동작을 설명했습니다. 턴마다 복잡도를 0에서 1 사이 점수로 매겨 낮으면 저렴한 모델로, 높으면 그 유형의 작업에서 가장 성과가 좋았던 프런티어 모델로 보냅니다.

예외가 하나 있습니다. OpenAI는 Claude Code 안에서 Codex로 코드 리뷰를 돌리는 플러그인 codex-plugin-cc를 직접 공개했습니다. 경쟁사 에이전트 안으로 들어가 자사 모델을 쓰게 하는 유통 전략으로 읽힙니다. 이것도 결국 각 회사가 자기 모델의 사용처를 넓히는 방향일 때만 움직인다는 점을 보여 줍니다.

린치는 에이전트 투자가 부족한 이유로 “에이전트가 아니라 모델을 재는 벤치마크와 데모"에 집중하는 경영진의 유인을 꼽았습니다. 필자가 보기에 그의 가설이 가장 잘 들어맞는 곳이 이 갈래입니다. 그리고 틈새 에이전트가 메이저와 정면으로 겹치지 않고 들어갈 수 있는 곳도 이 갈래뿐입니다. 다만 빈자리는 아닙니다. 모델 중립을 내건 GitHub과 Cursor가 이미 이 자리에서 움직이고 있습니다.

세 번째 빈칸: 아직 아무도 풀지 못한 문제#

마지막 갈래는 누가 만들든 어려운 문제입니다.

작업 난이도는 해 보기 전에는 모릅니다. Cursor Router도 품질을 사후에 추정합니다. Cursor의 설명에 따르면 사용자가 다음 작업으로 넘어가면 좋은 신호, 에이전트를 고치면 나쁜 신호로 봅니다. 비용 문제도 있습니다. 9월 27일 브리프에서 다룬 것처럼 에이전트 작업은 입력 토큰이 출력보다 압도적으로 많고, 그 입력의 상당 부분이 프롬프트 캐시로 할인됩니다. 세션 중간에 모델을 바꾸면 그 캐시를 버리고 긴 컨텍스트를 다시 읽어야 합니다. Cursor도 모델 전환에 따른 캐시 미스를 비용에 반영한다고 밝혔습니다. 모델을 바꾸는 단위가 턴이 아니라 서브에이전트가 되는 이유입니다.

ETA는 근거가 될 숫자가 없습니다. 에이전트는 도구를 몇 번 호출할지, 테스트가 실패해 몇 번 다시 할지 미리 알지 못합니다. Cursor 포럼에서는 장시간 에이전트의 ETA는 사실상 불가능하다는 답변까지 나왔습니다. 현실적인 길은 린치가 말한 대로 과거 기록으로 보정하는 것뿐입니다.

합의까지 반복하면 끝을 보장할 수 없습니다. 두 모델이 끝내 동의하지 않으면 비용이 계속 늘어납니다. HydraFusion이 한 번만 고치게 한 것도 이 때문이라고 필자는 추측합니다.

OS 샌드박스는 에이전트 자신을 가두기 어렵습니다. 에이전트 프로세스는 모델 API를 호출해야 하므로 인증 정보와 네트워크를 쥐고 있어야 합니다. 그 프로세스 안에서 도는 파일 도구는 OS 샌드박스 바깥에 남고, 통째로 가두려면 컨테이너나 VM이 필요합니다. Hermes의 Docker 백엔드와 Pi의 Gondolin이 이 방식입니다. 운영체제마다 격리 기능도 제각각이라 macOS, Linux, Windows에서 같은 정책을 같은 강도로 지키기 어렵습니다. 7월에는 Cursor, Codex, Gemini CLI, Antigravity의 샌드박스 우회 사례가 한꺼번에 보고됐습니다. 여러 사례의 공통점은 샌드박스 밖의 신뢰받는 구성 요소가 에이전트가 쓴 파일을 실행했다는 것이었습니다.

계획과 diff에는 다른 종류의 비용이 듭니다. 언어를 인식하는 diff는 언어마다 파서를 유지해야 합니다. 큰 그림에서 세부로 내려가는 계획은 렌더러보다 모델과 프롬프트의 문제이고, 같은 브리프에 소개한 “플랜 모드는 죽었다"는 글처럼 긴 계획 문서 자체에 대한 회의론도 있습니다.

자기 기능 인지는 릴리스 속도와 싸웁니다. 필자가 쓰는 Claude Code에는 자기 기능을 안내하는 내장 서브에이전트가 있는데, 이 서브에이전트가 쓰는 도구에 웹 페치와 웹 검색이 들어 있습니다. 결국 웹 문서를 찾아 읽는 방식이라 린치의 불만이 그대로 남습니다. 거의 매일 새 버전이 나오는 도구에서 모델이 학습한 시점의 지식은 금방 낡습니다. 문서를 통째로 넣어 두면 크기와 컨텍스트 비용이 늘어납니다. Gemini CLI와 Pi가 내장 문서로 답하는 방식을 택했지만, 버전에 정확히 맞는 답을 주는지는 필자가 확인하지 못했습니다.

이 갈래는 특정 사용자층을 노린다고 풀리지 않습니다. 기술로 이겨야 하는 영역이고, 틈새 에이전트가 메이저보다 나은 위치에 있을 이유도 없습니다.

틈새 에이전트를 만든다면#

빈칸을 세 갈래로 나누고 나면, 틈새 에이전트가 노릴 곳은 두 번째 갈래로 좁혀집니다. 그 자리에 새 에이전트를 만들어 들어가는 것이 괜찮은지 따져 보면 걸림돌이 다섯 가지 보입니다.

첫째, 가장 인기 있는 구독을 쓸 수 없습니다. 린치는 정액제 무제한 플랜을 연결할 수 있기를 원했습니다. 그런데 Anthropic은 Claude 구독의 포함 사용량을 자사 제품 안에서만 쓰게 합니다. 올해 들어 서드파티 도구가 Claude 구독 인증으로 요청하는 길을 서버 측 차단과 약관 개정으로 막아 왔고, Hermes Agent처럼 Claude 계정을 연결하는 도구는 구독 포함량이 아니라 별도 추가 사용량 크레딧을 씁니다. 반대로 GitHub은 1월부터 OpenCode에서 Copilot 구독을 공식 지원하고, OpenAI는 Sign in with ChatGPT로 구독 사용량을 서드파티에 열고 있습니다. 이 차이는 AI 구독은 왜 값싼 API가 아닌가와 내 서비스의 AI 비용을 사용자의 구독으로 내는 날은 올까에서 다뤘습니다. 자체 루프를 가진 새 에이전트는 Claude에 관한 한 API 원가에서 출발해야 합니다.

둘째, 메이저가 기능을 흡수하는 속도가 빠릅니다. Claude Code 변경 기록만 봐도 2.1.200에서 질문 대기 방식, 2.1.217에서 동시 실행 서브에이전트 상한(기본 20개), 2.1.221에서 비밀값 대체 기능이 들어왔습니다. 첫 번째 갈래에 속한 기능은 몇 달이면 메이저의 설정 하나가 됩니다.

셋째, 오픈소스 범용 에이전트 자리는 이미 찼습니다. OpenCode와 Hermes Agent는 이미 큰 커뮤니티를 갖고 있고, Pi는 Earendil이 이어받아 10월 1일 1.0을 냈습니다. “어떤 모델이든 쓸 수 있는 설정 가능한 오픈소스 에이전트"는 더 이상 새로운 제안이 아닙니다.

넷째, 수익 모델 없는 도구부터 정리되고 있습니다. VS Code 확장으로 설치 수를 크게 늘렸던 Roo Code는 2026년 5월 서비스를 내렸고, 여러 코딩 에이전트를 칸반 보드로 관리하던 Vibe Kanban은 운영사가 문을 닫았습니다. 살아남은 쪽은 모델 사용량 재판매(OpenCode), 기업 판매(Factory), 회사 합류나 인수(Pi, Anaconda가 인수한 Kilo Code) 중 하나를 택했습니다. 서드파티 보도와 비교 자료를 종합한 내용이라 세부는 다를 수 있습니다.

다섯째, 이 목록을 가장 원하는 사람들은 직접 만듭니다. 린치도 벤더 샌드박스를 믿지 못해 자기 샌드박스를 만들었습니다. 파워 유저는 사려는 사람이기 이전에 직접 조립하는 사람입니다.

이 조건들을 놓고 접근 방식별로 판단하면 다음과 같습니다.

접근	판단	이유
자체 루프를 가진 범용 에이전트	비추천	첫 번째 갈래는 메이저가 흡수하고, Claude 구독을 쓸 수 없음
공식 에이전트를 감싸는 지휘 계층	조건부 가능	두 번째 갈래에 집중할 수 있고 약관 위험이 낮음. 개인·오픈소스 규모가 현실적
샌드박스와 비밀값 프록시	부품으로 가능	에이전트보다 여러 에이전트에 붙는 격리 계층으로 의미가 있음
폐쇄망·온프렘 조직용	영업 역량이 있을 때	수요는 있지만 오픈 모델 품질과 설치·운영 부담이 관건
특정 언어·도메인 특화	플러그인이 낫다	도구와 지식을 MCP나 스킬로 붙이는 편이 원가가 낮음

가능성이 남는 형태는 지휘 계층입니다. 수정하지 않은 Claude Code, Codex, Copilot CLI를 사용자 각자의 구독으로 실행하고, 그 위에서 작업을 나누고, 쿼터를 모아 보고, 서로의 결과를 교차 리뷰하게 하는 계층입니다. 공식 런타임을 실행하는 것과 공식 클라이언트를 흉내 내는 것은 다르기 때문에 약관 위험이 낮고, 두 번째 갈래에 힘을 모을 수 있습니다. 다만 여기에도 경쟁자가 있습니다. Conductor는 이미 Claude Code와 Codex를 Git worktree별로 병렬 실행하는 앱을 내놓았고, 6월에는 “거대 AI 기업 종속에 반대한다"를 내건 모델 중립 코딩 플랫폼 Niteshift가 시드 투자를 받았습니다. 큰 회사를 세울 만한 시장이라기보다 개인 도구나 오픈소스 프로젝트로 의미가 있는 규모라고 봅니다.

필자가 빈칸을 메우는 방식#

이 결론은 필자가 4월에 쓴 AI 에이전트 웹서비스에 코딩 런타임을 붙이는 방법의 판단과 같은 자리로 돌아옵니다. 그때 필자는 코딩 루프를 처음부터 만들 필요가 없고, 런타임은 실행 엔진이며 제품이 가져야 할 것은 운영 계층이라고 적었습니다. 이번 조사는 그 판단에 근거를 하나 더 보탰습니다. 루프를 새로 만들어 얻는 차이는 메이저가 곧 따라오고, 메이저가 따라오지 않을 차이는 루프가 아니라 루프 위에 있습니다.

실제로 필자의 작업 환경도 이미 그렇게 움직이고 있습니다.

자기 인식의 빈칸: 이 블로그 저장소에는 글 작성, 번역, 뉴스 브리프 작성 절차를 담은 스킬과 에이전트 메모리 파일이 있습니다. 에이전트가 자기 기능을 아는 것은 아니지만, 적어도 이 프로젝트에서 일하는 방법은 웹 검색 없이 압니다.
규칙 강제의 빈칸: 문서에만 적어 둔 규칙이 긴 세션에서 자주 어겨져서, 그 일부를 Claude Code Mods로 옮기려 하고 있습니다. 과정은 규칙을 기억에서 코드로에 적었습니다.
격리의 빈칸: 꺼 두었던 샌드박스를 작업 성격별로 다시 켜는 계획을 세웠습니다.
대시보드의 빈칸: 개인 원격 개발 환경에서는 웹 대시보드 대신 Hermes Agent와 Discord를 묶었습니다. 대시보드 같은 포트를 외부에 열지 않고 서버에서 Discord로 나가는 연결만 쓰는 방식이라, “터널 없이"라는 린치의 요구를 다른 방식으로 채운 셈입니다. 구성은 노트북을 접어도 일하는 에이전트에 있습니다.

필자의 환경에서도 두 번째 갈래의 칸, 교차 모델 리뷰와 쿼터를 보는 모델 선택은 아직 비어 있습니다. 공식 런타임끼리 엮는 방식이 이 칸을 얼마나 채울 수 있는지가 필자가 다음으로 살펴볼 후보입니다.

맺으며#

린치는 꿈의 에이전트가 없는 이유를 경영진의 유인에서 찾았습니다. 빈칸을 세 갈래로 나눠 보니 그 설명은 한 갈래에만 들어맞습니다. 모델 회사가 경쟁사 모델로 라우팅하지 않는 것은 유인의 문제가 맞습니다. 하지만 샌드박스가 꺼져 있는 것은 모두를 상대하는 제품이 치르는 대가이고, ETA가 없는 것은 아직 아무도 답을 모르기 때문입니다.

그래서 제목의 질문에 대한 필자의 답은 이렇습니다. 꿈의 코딩 에이전트는 한 회사가 만들어 팔 수 있는 제품이 아닐 가능성이 큽니다. 어떤 칸은 모든 사용자를 위한 기본값과 부딪히고, 어떤 칸은 만드는 회사의 사업과 부딪히고, 어떤 칸은 아직 기술이 없습니다. 당분간 꿈의 에이전트에 가장 가까운 것은 공식 런타임을 엔진으로 두고 각자가 그 위에 조립하는 작업 환경일 것입니다. 린치가 자기 샌드박스를 만들었듯이 말입니다.