코딩 에이전트를 전략 게임으로 만든 이유

제목: 코딩 에이전트를 전략 게임으로 만든 이유 제목 원문: [한영자막] 코딩 에이전트를 전략 게임으로 만들었습니다 — Ido Salomon, AgentCraft URL: https://www.youtube.com/watch?v=eTtZlAPA9H4 날짜: 2026-10-08 실제 업로드일: 2026-10-07 채널: Tech Bridge 발표자: Ido Salomon 재생 시간: 13분 12초

---

📌 핵심 질문 / 핵심 논점

==코딩 에이전트의 능력이 부족해서가 아니라 사람의 조종·감독·검토 능력이 병목이기 때문에, 에이전트 운영을 전략 게임처럼 설계해 인간이 더 많은 일을 처리하면서도 소진되지 않게 만들어야 한다.==

• 에이전트는 고양이 밈부터 B2B SaaS 앱까지 만들 수 있지만, 25개의 클라우드 코딩 에이전트를 띄우는 것만으로는 무적의 생산성이 생기지 않는다.
• 사람은 각 에이전트를 지시하고, 방향을 잡고, 결과를 검토해야 하며, 에이전트 수가 늘어날수록 그 감독이 새로운 노동이 된다.
• Warcraft·The Sims·실시간 전략(RTS) 게임이 여러 유닛을 한꺼번에 파악하고 필요한 곳에 개입하는 감각을 이미 훈련해 주었으므로, 그 상호작용을 AgentCraft에 옮길 수 있다.
• 가시성(visibility), 자율성(autonomy), 협업(collaboration)으로 숙련 사용자의 처리 한계(ceiling)를 높이고, 더 많은 사람이 접근할 수 있도록 사용 난이도의 바닥(floor)도 낮춰야 한다.

에이전트 시대의 핵심 문제는 에이전트가 무엇을 할 수 있느냐가 아니라 사람이 얼마나 많은 에이전트를 지속해서 이해하고 조종할 수 있느냐다. AgentCraft는 파일·도구·작업 상태를 게임 맵처럼 보여주고, 반복 작업과 검토를 자동화하며, 사람과 에이전트가 같은 공간에서 대화하게 만든다. 다음 단계인 TBD 또는 ‘Loopers’는 복잡한 파일 단위 조작을 감추고 모바일 게임처럼 “프롬프트를 입력하면 결과를 받고, 원할 때만 내부를 들여다보는” 경험을 제공해 에이전트 생산성의 진입 장벽을 낮추려 한다.

1. 에이전트가 많은데도 사람이 병목인 이유

에이전트의 실행 능력은 빠르게 커졌지만, 인간의 주의력과 검토 용량은 그대로라서 에이전트 수만 늘리는 전략은 곧 감독 피로로 이어진다.

1.1. 뛰어난 에이전트와 무적이 되지 못한 사용자

1. 에이전트의 능력 범위

   1. 가벼운 창작부터 실제 제품까지: 에이전트는 고양이 밈을 만드는 일부터 기업 간 거래(B2B)용 SaaS 애플리케이션을 만드는 일까지 수행할 수 있다.
   2. 자연스러운 질문: 이 정도로 강력한 도구라면 누구나 원하는 일을 해내는 에이전트 군단을 가져야 할 것처럼 보인다.

2. 25개를 띄우면 끝이라는 착각

   1. 단순한 상상: 모니터를 여러 대 준비하고 클라우드 코딩 에이전트 25개를 실행하면 된다는 그림은 간단해 보인다.
   2. 실제 운영의 복잡성: 에이전트를 정말 쓰고 싶다는 의지부터 필요하고, 실행한 뒤에는 각각을 조종하고(steer), 방향을 지시하고(direct), 산출물을 검토(review)해야 한다.

1.2. 감독 비용이 에이전트의 혜택을 잠식하는 구조

1. 에이전트가 늘수록 감독도 늘어난다

   1. 에이전트당 인간 개입: 에이전트 하나도 관리가 필요한데, 여러 개를 동시에 돌리면 각자의 진행 상황·결정·결과를 별도로 확인해야 한다.
   2. 규모의 피로: 작업을 에이전트에게 넘겨도 사람이 모든 에이전트를 계속 붙잡고 있어야 하면, 생산성 향상이 아니라 소진으로 끝난다.

2. 병목의 정체

   1. 사람이 병목: 에이전트의 능력이 모자라서가 아니라 사람이 동시에 스무 가지 일을 머릿속에 유지할 수 없기 때문에 사람이 병목이 된다.
   2. 필요한 기술: 에이전트를 쓸 때마다 번아웃하지 않으려면 상황을 파악하고, 우선순위를 정하고, 필요한 순간에만 개입하는 운영 기술이 필요하다.

2. 게임이 제공하는 에이전트 운영의 비유

게임은 여러 자율 유닛의 상태를 읽고 적절한 순간에 지시하는 방식을 이미 익숙한 조작으로 만들었다.

2.1. Warcraft와 The Sims에서 얻는 감독 모델

1. 여러 유닛을 동시에 다루는 감각

   1. 상태 파악: Warcraft나 The Sims에서 여러 유닛이 맵을 돌아다니면 각각 무엇을 하는지 이해해야 한다.
   2. 감독과 개입: 모든 유닛을 매초 직접 움직이지 않으면서도 전체 상황을 감독하고 필요한 곳에 명령을 내려야 한다.

2. 에이전트 검토와 게임 플레이의 공통점

   1. 관찰 대상의 전환: 에이전트가 어떤 파일과 도구를 쓰는지 확인하는 일은 맵 위 유닛의 상태를 읽는 일과 비슷하다.
   2. 인지 부담의 전환: 게임이 복잡한 동시 작업을 하나의 인터랙티브 공간에 넣듯, 에이전트 운영도 목록과 명령줄만이 아니라 공간적 모델로 바꿀 수 있다.

2.2. AgentCraft로 옮긴 게임의 원리

1. 게임에서 영감을 받은 오케스트레이터

   1. AgentCraft: Ido Salomon은 게임적 운영 개념을 실제 업무에 가져오는 오케스트레이터 AgentCraft를 만들었다. 한 대목에서는 이름을 ‘AtomCraft’처럼 발음하기도 하지만, 제품명은 AgentCraft다.
   2. 목표: 인간과 에이전트가 협업할 수 있는 한계를 높이고, 사람이 에이전트를 관리하는 일을 게임처럼 이해하기 쉽게 만든다.

2. 첫 화면의 기본 구성

   1. 에이전트 표현: 화면 속 에이전트는 Claude Code로 해석되는 클라우드 코드, OpenClaw 등 사용자가 상상할 수 있는 실제 에이전트를 나타낸다.
   2. 연결과 생성: 이미 기기에 연결된 에이전트를 감지할 수도 있고, AgentCraft 안에서 새 에이전트를 직접 생성할 수도 있다.
   3. 지원 대상: Codex와 OpenCode 같은 코딩 에이전트도 같은 방식으로 배치할 수 있다.

2.3. 게임 맵 안에 들어온 개발 환경

1. 프롬프트와 음성

   1. 사이드 패널: 에이전트를 선택하고 옆 패널에서 자연어로 일을 시킬 수 있다.
   2. 멀티모달 입력: 패널에는 음성 기능도 있어 타이핑뿐 아니라 말로 명령을 내리는 멀티모달 경험을 제공한다.
   3. 일반 에이전트의 자유도: 화면에 표시된 에이전트도 특별히 제한된 유닛이 아니라 일반 에이전트이므로, 사용자가 요청한 일을 그대로 수행한다.

2. 건물로 표현한 기능

   1. 플러그인과 스킬: 맵의 건물은 기능을 나타내며, 에이전트가 사용하는 플러그인과 스킬을 관리하는 공간이 된다.
   2. 터미널과 Git: 통합 터미널과 통합 Git이 건물처럼 제공되어, 작업을 위해 다른 화면으로 계속 이동하지 않아도 된다.
   3. 한 공간의 업무: 에이전트 호출, 도구 사용, 프로젝트 작업을 AgentCraft 맵 안에서 이어 갈 수 있다.

3. 가시성: 에이전트가 무엇을 하는지 한눈에 파악하기

에이전트 운영의 첫 단계는 모든 세부사항을 외우는 것이 아니라 필요한 정보만 빠르게 읽을 수 있는 가시성을 확보하는 것이다.

3.1. 사이드 패널의 상태 요약

1. 에이전트별 핵심 정보

   1. 현재 작업: 각 에이전트가 어떤 과제를 맡고 있는지 표시한다.
   2. 최근 행동: 마지막으로 무엇을 했는지 보여준다.
   3. 진행 중인 행동: 지금 무엇을 하고 있는지 실시간으로 확인할 수 있다.

2. 주의가 필요한 에이전트의 선별

   1. 빠른 판단: 모든 로그를 읽지 않아도 누가 사람의 관심을 필요로 하는지 확인할 수 있다.
   2. 선택적 개입: 문제가 없는 에이전트는 계속 일하게 두고, 답변·승인·방향 수정이 필요한 에이전트에만 시간을 쓸 수 있다.

3.2. 파일 시스템을 맵으로 투영하기

1. 목록을 공간으로 바꾸기

   1. 프로젝트 맵: 파일 시스템을 AgentCraft 맵에 투영하면 에이전트가 실제로 어떤 디렉터리나 파일에서 작업하는지 공간적으로 볼 수 있다.
   2. 목록 이상의 이해: 단순히 “현재 작업 중인 에이전트 목록”을 보는 데서 끝나지 않고, 에이전트의 활동이 프로젝트 구조의 어디에 위치하는지 알 수 있다.

2. 룬(rune)으로 표시되는 파일

   1. 파일 단위 흔적: 맵의 파일은 룬으로 표현되어 에이전트가 어떤 파일을 건드렸는지 확인할 수 있다.
   2. 시간 정보: 각 룬을 살펴보면 어떤 에이전트가 무엇을 했는지와 언제 작업했는지를 함께 확인할 수 있다.

3.3. 관계와 히트맵으로 확장되는 가시성

1. 오케스트레이터의 연결 정보

   1. 관계 생성: 에이전트 활동과 파일 정보를 오케스트레이터가 연결해 프로젝트 전체의 관계를 구성한다.
   2. 상황의 구조화: 흩어진 파일 변경과 에이전트 행동이 하나의 맥락으로 이어져 어디에 활동이 집중되는지 읽을 수 있다.

2. 히트맵

   1. 집중 구간 확인: 히트맵을 사용하면 작업이 몰린 디렉터리나 파일을 빠르게 식별할 수 있다.
   2. 정보의 압축: 수많은 세부 활동을 색과 위치의 패턴으로 압축해, 사람이 모든 파일을 직접 열어 보지 않아도 된다.

3.4. 필요한 곳으로 즉시 이동하기

1. 공간 키로 주의 대상 찾기

   1. 게임식 이동: 스페이스바를 누르면 사람의 관심이 필요한 가장 가까운 대상으로 이동한다.
   2. RTS와 Civilization의 조작: 실시간 전략 게임이나 Civilization에서 다음 사건으로 화면을 이동하는 방식처럼, 한 에이전트에서 다른 에이전트로 빠르게 전환한다.

2. 이동 뒤 수행하는 일

   1. 질문에 응답: 에이전트의 질문이 있는 곳으로 이동해 답할 수 있다.
   2. 계획 승인: 계획을 승인하거나 수정하고, 다시 전체 맵의 다른 주의 대상에게 넘어갈 수 있다.

4. 자율성: 직접 감독하지 않아도 일하게 만들기

가시성만으로는 충분하지 않다. 파일과 도구의 세부사항을 계속 들여다보는 일 자체가 또 하나의 피로가 되므로, 에이전트에게 다음 작업을 찾고 실행하며 검토 가능한 상태로 전달하는 역할까지 맡겨야 한다.

4.1. 에이전트가 다음 퀘스트를 찾아주는 방식

1. 사람이 동시에 감당하기 어려운 양

   1. 머릿속 용량의 한계: 현재 상황을 완전히 볼 수 있어도 스무 가지 일을 동시에 할 수는 없다.
   2. 다음 행동의 실종: 큰 코딩 프로젝트를 진행하면서 현재 상태를 관리하느라 다음에 무엇을 해야 할지 생각할 여유조차 사라질 수 있다.

2. 퀘스트 생성

   1. 코드베이스 탐색: 에이전트에게 코드베이스를 훑어 다음에 필요한 작업을 찾아 달라고 요청한다.
   2. 작업 목록 전환: 에이전트가 찾아낸 작업을 사용자의 퀘스트로 만들어 주고, 사용자는 버튼을 눌러 퀘스트를 수락한다.
   3. 수행 위임: 수락된 퀘스트는 적절한 에이전트가 실행하므로, 사람이 다음 일을 기억하고 쪼개는 부담이 줄어든다.

4.2. 소프트웨어 팩토리와 격리된 실행

1. 일반 의도에서 실행 계획으로

   1. 넓은 요구 전달: 사람은 만들고 싶은 결과의 일반적인 방향만 제시한다.
   2. 오케스트레이터 생성: 에이전트가 오케스트레이터를 만들고, 큰 목표를 하위 작업으로 분해한다.

2. 로컬 컨테이너의 격리

   1. 독립 실행: 분해된 작업은 로컬 컨테이너 안에서 실행된다.
   2. 감독 제거: 작업이 격리되어 진행되므로 사람이 각 단계에 붙어 있거나 계속 ‘베이비시팅’하지 않아도 된다.

4.3. 루프가 백그라운드에서 만드는 기능

1. 반복 탐색 루프

   1. Twitter 스캔: 만들 만한 흥미로운 것을 찾도록 Twitter를 계속 훑게 할 수 있다.
   2. GitHub 스캔: GitHub를 살펴보고 구현할 만한 기능을 자동으로 찾아낼 수도 있다.

2. 선행 작업이 적은 기능 생산

   1. 백그라운드 생성: 루프는 사용자가 처음부터 세부 계획을 많이 제시하지 않아도 기능 후보를 만들고 배경에서 작업한다.
   2. 자율성의 대가: 기능을 자동으로 많이 만들수록 사람이 나중에 검토해야 하는 결과도 함께 늘어난다.

4.4. Review Kit으로 여러 결과를 빠르게 비교하기

1. 검토 병목

   1. 작업 수의 증가: 스무 개의 결과는 물론이고 다섯 개만 동시에 검토해도 모두 처리하기 어렵다.
   2. 자율성의 역설: 에이전트가 일을 대신한 뒤 사람이 결과를 하나씩 확인하느라 다시 지치면, 자율성이 병목을 없애지 못한다.

2. 검토 정보의 묶음

   1. 변경 전체: Review Kit은 검토해야 할 변경사항을 한곳에 모은다.
   2. 파일 단위 검토: 어느 파일이 바뀌었는지 보여주므로 필요하면 파일별로 깊게 확인할 수 있다.
   3. 시각적 증거: 코드 차이만 읽지 않고, 변경 결과를 보여주는 동영상이나 사진을 확인할 수 있다.

3. 병렬 구현과 선택

   1. 여러 인스턴스 실행: 같은 작업의 구현을 여러 에이전트 인스턴스에서 동시에 돌릴 수 있다.
   2. 최선의 결과 선택: 결과를 나란히 비교하고 가장 나은 구현을 고르면, 모든 구현을 직접 만드는 대신 판단에 집중할 수 있다.

5. 협업: 사람과 에이전트가 같은 작업 공간에서 일하기

가시성과 자율성을 모두 갖춰도 한 사람이 에이전트와 하루 종일 대화하는 구조는 외롭고 지속하기 어렵다. 팀의 전문성이 필요한 경우 담당자가 아닌 사람이 검토하는 문제도 생긴다.

5.1. 혼자서 모든 에이전트를 상대하는 한계

1. 외로운 운영

   1. 한 사람의 부담: 모든 에이전트를 혼자 지휘하고 검토하면 일을 많이 할 수 있어도 운영은 외로운 작업이 된다.
   2. 팀의 불일치: 팀이 있다면 현재 작업을 검토하는 사람이 반드시 가장 적합한 전문가는 아닐 수 있다.

2. 협업의 필요

   1. 전문성 연결: 제품 디자이너가 설계를 보고 엔지니어가 구현하는 식으로, 각자 잘하는 판단을 같은 흐름에 연결해야 한다.
   2. 공유 상황판: 사람과 에이전트가 서로 무엇을 하는지 알아야 중복 작업과 단절을 줄일 수 있다.

5.2. War Hall·War Room 형태의 로컬 방

1. 방을 만들고 사람을 초대하기

   1. 공유 공간: AgentCraft에서는 War Hall 또는 War Room이라고 부를 수 있는 방을 만든다.
   2. 로컬 호스팅: 방은 완전히 로컬에서 호스팅할 수 있다.
   3. 터널과 참여: 터널을 열어 다른 사람이 방에 참여하게 만들 수 있다.

2. 제품 디자이너와 엔지니어의 사례

   1. 디자이너 참여: Ido Salomon은 팀의 제품 디자이너가 방에 들어와 자신의 일을 하도록 승인한다.
   2. 가족을 활용한 농담: 시연 속 제품 디자이너는 그의 아내이며, 아내를 승인하지 않으면 화낼 수 있으니 승인해야 한다는 농담이 나온다.
   3. 동시 진행: 디자이너가 설계하는 동안 엔지니어는 맵에서 그 설계 작업을 확인하고 다음 구현으로 이어 간다.

5.3. 포크·핸드오프·공유 워크스페이스

1. 설계에서 구현으로 이어지는 흐름

   1. 작업 가져오기: 엔지니어는 디자이너의 설계 작업을 가져와 후속 작업으로 연결할 수 있다.
   2. 포크와 핸드오프: 작업을 포크(fork)하거나 넘겨받아 각자의 작업을 이어 가며, 원래 담당자는 자신의 작업을 계속한다.

2. Git에 종속되지 않는 협업

   1. Git은 선택지: Git을 사용할 수는 있지만, 사람과 에이전트의 공유 작업 공간이 Git에만 묶일 필요는 없다.
   2. 공동 상태: 한 사람이 만든 맥락을 다른 사람이 이어받는 구조가 저장소의 브랜치 전환만으로 설명되지 않는 협업을 가능하게 한다.

5.4. 사람·에이전트 간 대화와 디바이스 확장

1. 방 안의 채팅

   1. 사람 사이의 채팅: 같은 방에 들어온 팀원들이 서로 대화할 수 있다.
   2. 에이전트 사이의 채팅: 사람뿐 아니라 에이전트끼리도 대화하며 서로의 작업을 파악한다.
   3. 공지판: 무엇을 하고 있는지 기록되는 공지판이 생겨 방 전체가 작업 현황을 공유한다.

2. 기기 선택

   1. 모바일 접근: AgentCraft 작업은 컴퓨터에만 고정되지 않고 모바일 기기에서도 이어 갈 수 있다.
   2. Telegram 연동 가능성: Telegram을 선호하면 Telegram을 사용하면 되고, 사용자가 편한 기기를 선택할 수 있다.
   3. 다양한 접점: 특정 인터페이스를 강요하기보다 사람의 기존 습관과 도구를 에이전트 협업 공간에 연결한다.

6. 처리 한계를 높이는 것과 진입 장벽을 낮추는 것

가시성·자율성·협업은 숙련 사용자의 처리 상한을 올리지만, 에이전트를 처음 접하는 사람에게는 여전히 복잡하게 보일 수 있다.

6.1. 파워 유저의 상한을 높인 세 가지 축

1. 가시성: 에이전트·파일·도구·주의 대상을 맵과 사이드 패널에서 파악하게 한다.
2. 자율성: 퀘스트 생성, 소프트웨어 팩토리, 격리된 컨테이너, 루프, 검토 키트로 사람의 상시 감독을 줄인다.
3. 협업: 사람·에이전트·디바이스를 하나의 공유 공간과 대화 흐름으로 묶어 한 사람이 모든 판단을 독점하지 않게 한다.

6.2. 예상 밖의 사용자 피드백

1. 어린이의 반응

   1. 기존 경험이 없어도 사용: 에이전트나 생산성 도구와 관련이 거의 없던 사람들도 AgentCraft를 접했다.
   2. 아이들의 몰입: 아이들이 AgentCraft를 정말 좋아했고, 에이전트와 작업하는 데 계속 사용했다.

2. StarCraft 플레이어의 전환

   1. 과거의 문제 행동: StarCraft를 너무 많이 하다가 대학에서 탈락한 사람도 있었다.
   2. 생산성으로의 전환: 전략 게임에서 익힌 감각 덕분에 AgentCraft를 통해 갑자기 생산적인 일을 할 수 있게 됐다.

3. 뒤처져 있던 공동체의 참여

   1. 기존 생산성 도구의 배제: 지금까지의 에이전트·생산성 도구는 특정 기술과 업무 습관을 가진 사람에게 유리했다.
   2. 새로운 세계로의 진입: 게임 친화적인 인터페이스가 그동안 뒤처져 있던 공동체도 새로운 생산성 세계에 들어오게 하는 통로가 될 수 있다.

6.3. 90%의 사람을 위한 낮은 바닥

1. 상한만 높여서는 부족하다

   1. 파워 유저 중심의 한계: 숙련자에게 더 많은 에이전트를 다루게 해도 에이전트 미래가 전체 사회로 확장되는 것은 아니다.
   2. 소진 방지: 세계 인구의 약 90%가 에이전트 미래에 들어오려면 번아웃하지 않고 시작할 수 있는 경험이 필요하다.

2. 접근성의 목표

   1. 낮은 바닥: 에이전트의 강력한 내부 기능을 처음부터 모두 이해하지 않아도 일을 시작할 수 있게 해야 한다.
   2. 상한과 바닥의 동시 설계: 숙련자가 깊이 파고들 수 있는 기능과 초보자가 쉽게 들어오는 표면을 함께 제공해야 한다.

7. TBD·Loopers: 모바일 게임 수준의 에이전트 경험

복잡한 전략 게임 모델이 모든 사람에게 맞는 것은 아니므로, AgentCraft보다 단순한 경험으로 에이전트의 혜택을 전달하는 실험이 이어진다.

7.1. Warcraft의 복잡성을 낮추는 발상

1. 복잡한 UI의 부담

   1. 파일 단위의 세부사항: 어떤 파일에서 어떤 에이전트가 일하는지 보여주는 기능은 강력하지만, 처음 접하는 사람에게는 부담스럽다.
   2. Warcraft의 진입 난이도: Warcraft처럼 풍부한 전략 요소를 가진 인터페이스는 세밀한 조작을 좋아하지 않는 사람에게 위압적으로 보일 수 있다.

2. 공통분모 찾기

   1. 에이전트의 능력 활용: 에이전트가 더 자율적으로 일할 수 있게 된 만큼, 사람이 모든 내부 과정을 직접 조작해야 한다는 전제를 내려놓는다.
   2. 모바일 게임 수준: 정확한 파일 위치나 복잡한 상태 대신, 프로젝트를 선택하고 다음 결과를 기다리는 모바일 게임 수준의 인터페이스를 목표로 한다.

7.2. 프로젝트를 반복해서 방문하는 구조

1. 프롬프트에서 결과까지

   1. 최소 입력: 사용자는 프롬프트를 입력한다.
   2. 결과 수신: 에이전트가 결과를 가져온다.
   3. 과정의 선택적 확인: 사용자는 내부에서 어떤 일이 벌어졌는지 꼭 알 필요는 없고, 원할 때만 세부 과정을 들여다본다.

2. 돌아오고 싶은 경험

   1. 프로젝트 유지: 한 번 쓰고 버리는 명령줄이 아니라 계속 돌아와 진행 상황을 확인하는 프로젝트 공간을 만든다.
   2. 루프 활용: 에이전트의 자율성과 반복 루프가 백그라운드에서 프로젝트를 진행하게 한다.
   3. 상호작용의 재미: 결과를 기다리고, 확인하고, 다음 요청을 보내는 흐름을 재미있고 상호작용적인 경험으로 설계한다.

7.3. 사람마다 다른 접근성

1. 하나의 UI가 모두를 만족시키지 못한다

   1. 개인차: 같은 시각화가 어떤 사람에게는 놀랍고 쉬워도 다른 사람에게는 어려울 수 있다.
   2. 선호의 차이: 모두가 게임·맵·파일 세부사항을 같은 방식으로 좋아하는 것은 아니다.

2. 맞춤화의 방향

   1. 필요 파악: 각 사람이 도구를 이해하고 사용하고 싶어 하려면 무엇이 필요한지 파악해야 한다.
   2. 맞춤형 표면: 사람마다 다른 복잡도와 표현 방식을 선택할 수 있게 만드는 것이 TBD/Loopers의 방향이다.
   3. 초기 실험: TBD 또는 잠정적으로 Loopers라 부르는 아이디어는 매우 이른 초안이며, 사용해 보고 싶은 사람에게 피드백을 요청한다.

주요 발언 모음

“에이전트는 놀라운데, 왜 우리는 모두 무적이 되지 못했을까?”

“현실은 그렇게 간단하지 않다.”

“실제로 우리는 병목이다.”

“에이전트를 쓰다가 매번 번아웃하지 않게 해 줄 기술은 줄곧 우리와 함께 있었다.”

“가시성, 자율성, 협업을 갖추면 에이전트로 할 수 있는 일의 상한을 높일 수 있다.”

“약 90%의 사람을 에이전트 미래로 데려오려면 바닥도 낮춰야 한다.”

“우리가 병목이기는 하지만, 반드시 병목일 필요는 없다.”

핵심 데이터 & 수치

• 13분 12초: AgentCraft의 문제 정의, 기능 시연, 협업 모델, 다음 단계 구상을 압축해 설명하는 발표 길이다.
• 25개: 여러 모니터에서 동시에 띄운다고 상상한 클라우드 코딩 에이전트 수다.
• 20개: 한 사람이 동시에 머릿속에 유지하거나 검토하려 하면 부담이 커지는 작업의 예시 규모다.
• 5개: 다섯 작업만 동시에 검토해도 매우 어렵다고 말한 최소 사례다.
• 약 90%: 번아웃 없이 에이전트 미래에 들어오도록 낮은 진입 장벽을 설계해야 하는 사람들의 대략적인 비율이다.
• 3가지 축: AgentCraft가 처리 한계를 높이는 핵심 축은 가시성, 자율성, 협업이다.
• 2026-10-07: YouTube 실제 업로드일이며, Nuggets drop_date에 사용한다.

결론 및 시사점

1. 에이전트 도입의 가장 큰 제약은 모델의 기능 목록이 아니라 사람이 동시에 이해하고 검토할 수 있는 작업량이다.
2. 상태 패널·맵·룬·히트맵·주의 대상 이동은 에이전트 군단을 감시하는 일을 공간적이고 선택적인 조작으로 바꾼다.
3. 코드베이스에서 다음 퀘스트를 찾고, 컨테이너에서 자율 실행하고, 루프로 백그라운드 작업을 돌리면 사람은 세부 지시보다 방향과 판단에 집중할 수 있다.
4. 자율성이 커질수록 검토량도 커지므로, 파일 목록·시각적 증거·병렬 구현 비교를 제공하는 Review Kit이 필수다.
5. 에이전트 작업은 한 사람의 사적 대화가 아니라 제품 디자이너·엔지니어·에이전트가 함께 보는 공유 공간이 되어야 한다.
6. 게임에 익숙한 사람에게 자연스러운 맵과 유닛 모델이 다른 사람에게는 부담일 수 있으므로, 숙련자를 위한 깊이와 초보자를 위한 단순성을 함께 설계해야 한다.
7. 사람이 병목이라는 사실은 고정된 운명이 아니라 인터페이스와 운영 방식으로 개선할 수 있는 설계 문제다.

핵심 요약 (20줄)

1. 코딩 에이전트는 고양이 밈부터 B2B SaaS 앱까지 만들지만 사람의 감독 용량이 생산성의 병목이 된다.
2. 클라우드 코딩 에이전트 25개를 띄우는 것만으로는 무적의 에이전트 군단이 만들어지지 않는다.
3. 여러 에이전트를 운영하려면 각각을 조종하고 지시하고 검토해야 하므로 감독 피로가 빠르게 커진다.
4. Warcraft와 The Sims의 유닛 감독 방식은 에이전트 운영에 필요한 상황 파악과 선택적 개입을 설명한다.
5. AgentCraft는 게임에서 영감을 얻은 오케스트레이터로 에이전트를 맵 위의 작업 유닛처럼 표현한다.
6. AgentCraft는 Claude Code로 해석되는 클라우드 코드, OpenClaw, Codex, OpenCode 같은 에이전트를 연결하거나 생성한다.
7. 음성까지 지원하는 사이드 패널에서 에이전트에게 자연어로 작업을 요청할 수 있다.
8. 플러그인과 스킬, 통합 터미널, 통합 Git은 맵 위 건물로 표현되어 업무 흐름을 한 공간에 모은다.
9. 사이드 패널은 에이전트별 작업과 최근 행동과 현재 행동을 보여 주어 주의가 필요한 대상을 골라 준다.
10. 파일 시스템을 맵에 투영하면 에이전트가 작업 중인 디렉터리와 파일을 룬으로 확인할 수 있다.
11. 히트맵과 스페이스바 이동은 수많은 활동 중 집중 구간과 즉시 개입할 대상을 빠르게 찾게 한다.
12. 에이전트는 코드베이스를 훑어 다음 작업을 퀘스트로 만들고 사용자는 버튼으로 수락할 수 있다.
13. 소프트웨어 팩토리는 일반적인 목표를 오케스트레이터와 하위 작업으로 나누고 로컬 컨테이너에서 격리 실행한다.
14. Twitter와 GitHub를 스캔하는 루프는 사용자가 계속 붙어 있지 않아도 백그라운드에서 기능 후보를 만든다.
15. Review Kit은 변경 파일과 시각적 증거와 병렬 구현 결과를 묶어 여러 작업의 검토 부담을 줄인다.
16. AgentCraft의 협업 방은 로컬 호스팅과 터널을 통해 팀원과 에이전트를 같은 작업 공간에 모은다.
17. 제품 디자이너의 설계를 엔지니어가 포크하고 구현하는 흐름은 Git에만 묶이지 않는 공유 워크스페이스를 보여 준다.
18. 아이들과 StarCraft를 많이 했던 사람도 게임식 인터페이스를 통해 에이전트 생산성에 참여할 수 있다.
19. 약 90%의 사람을 에이전트 미래로 데려오려면 Warcraft의 복잡성보다 모바일 게임에 가까운 낮은 진입 장벽이 필요하다.
20. 사람은 여전히 병목이지만 가시성·자율성·협업과 맞춤형 인터페이스로 반드시 병목일 필요는 없다.