오늘날 코딩 에이전트를 실행하는 기본 장소는 에디터 안입니다. Cursor, Claude Code, IDE에 내장된 어시스턴트 — 이들은 여러분 옆에 앉아 있고, 여러분은 그 작업을 지켜보며, 한 단계씩 승인합니다. 이는 페어 프로그래밍을 그대로 본뜨기 때문에 자연스럽게 느껴집니다: 매우 빠른 주니어 개발자가 어깨너머에 앉아 있고, 여러분은 여전히 핸들을 잡고 있는 셈이죠.
이 모델은 지속적인 감독이 필요한 에이전트에는 완벽하게 들어맞습니다. 문제는 에이전트가 달이 갈수록 감독을 덜 필요로 한다는 점입니다. 그리고 자율성이 높아질수록, 여러분이 깨어 있을 때만 깨어 있는 단 한 대의 노트북에 에이전트를 묶어두는 것이 점점 더 이상하게 보입니다.
로컬의 한계
로컬 에이전트는 여러분의 모든 제약을 그대로 물려받습니다. 여러분의 컴퓨터가 켜져 있는 동안만 실행되고, 닫으면 멈춥니다. 에디터, 브라우저, 빌드와 같은 CPU와 메모리를 두고 경쟁합니다. 한 번에 하나의 작업만 처리하는데, 여러분도 한 번에 하나만 지켜볼 수 있기 때문입니다. 그리고 그것이 하는 모든 일은 오직 여러분만 볼 수 있는 곳에서 일어납니다.
이 중 어느 것도 도구의 결함이 아닙니다 — 이것이 바로 '로컬'의 논리입니다. 에이전트는 여러분이 사는 곳에서 살아가므로, 여러분을 제약하는 모든 것 — 근무 시간, 하드웨어, 주의력, 단 하나뿐인 두 눈 — 에 의해 제약됩니다. 에이전트가 모든 단계마다 사람의 감시를 필요로 했을 때는 이러한 제약이 공짜였습니다. 더 이상 그럴 필요가 없어지자, 그것은 순전한 비용이 되었습니다.
비동기·원격이라는 대안
또 다른 모델, 바로 우리가 TaskGoblin을 구축한 토대가 그것입니다: 에이전트는 애초에 여러분의 에디터 안에 살지 않습니다. 전용 인프라 위에서 살아가며, 여러분의 팀이 이미 사용하고 있는 도구 — Linear 이슈, GitLab이나 GitHub의 머지 리퀘스트, Slack 스레드 — 를 통해 여러분에게 도달합니다. 여러분은 다른 시간대에 있는 원격 동료에게 일을 맡기듯 작업을 넘기고, 에이전트는 클라우드 샌드박스에서 그 일을 처리하는 동안 여러분은 다른 일을 계속할 수 있습니다.
이 변화는 마치 연산이 어디서 실행되는지의 문제처럼 들립니다. 하지만 실제로는 에이전트가 무엇이 될 수 있도록 허용되는가의 문제입니다. 노트북에서 떼어놓으면 '로컬'의 제약들이 하나씩 사라집니다:
- 병렬로 실행됩니다. 어떤 인간도 각각을 일일이 지켜볼 필요가 없기 때문에, 열 개의 이슈가 동시에 진행될 수 있습니다.
- 항상 켜져 있습니다. 원격 에이전트는 여러분이 노트북을 닫아도 멈추지 않습니다. 저녁 6시에 배정된 작업은 아침이면 끝나 있습니다. 하루 동안 사용 가능한 에이전트 작업 시간은 더 이상 여러분의 근무 시간이 아니게 됩니다.
- 그것을 위해 만들어진 인프라 위에서 실행되며, 개발자 노트북에서 여러분의 에디터와 자원을 두고 다투지 않습니다.
- 팀이 볼 수 있는 곳에서 작업합니다. 결과물은 머지 리퀘스트와 댓글 기록이지, 비공개 세션이 아닙니다 — 감독은 팀 전체가 공유 공간에서 함께 수행하는 일이 됩니다.
- 플랫폼에 네이티브합니다. 여러분이 앱을 여는 것이 아니라, 이미 도구들 사이를 흐르고 있는 이벤트 — 할당, 멘션, 새로운 풀 리퀘스트 — 에 의해 트리거됩니다.
- 구조적으로 격리되어 있습니다. 각 실행은 새로운 샌드박스 환경에서 이루어지며, 에이전트가 결코 직접 보유하지 않는, 범위가 제한되고 중개된 자격 증명을 사용합니다 — 이는 여러분 자신의 머신에서 실행되는 프로세스가 결코 따라올 수 없는 보안 태세입니다.
이러한 장점들은 각각으로는 그리 극적이지 않습니다. 하지만 합쳐지면 반박하기 어려운 격차로 쌓입니다: 밤낮없이 일하는 열 개의 에이전트 대, 여러분이 멈추면 함께 멈추는 하나의 에이전트.
"하지만 저는 긴밀한 피드백 루프가 필요합니다"
원격에 대한 가장 강력한 반론은 긴밀한 루프입니다: 에이전트를 지켜보고, 중간에 수정하고, 감각으로 조종하는 빠른 주고받음 말이죠. 이는 실재하는 것이며, 진정으로 탐색적인 작업 — 아이디어를 스파이크로 시험하거나, 아직 스스로도 이해하지 못한 것을 디버깅하는 작업 — 에는 여전히 로컬이 올바른 도구입니다.
하지만 이 루프에 관해 두 가지가 사실입니다. 그것은 체감보다 실제 작업에서 차지하는 비중이 작습니다. 진짜 엔지니어링의 상당 부분은 사람이 붙어 있을 필요가 없는, 명세가 잘 정의된 작업입니다. 그리고 에이전트가 발전할 때마다 그 루프는 줄어듭니다. 여러분이 붙어 지켜보는 이유는 에이전트가 사람 없이도 일을 끝낼 것이라고 아직 신뢰하지 않기 때문이며, 바로 그 신뢰가 지금 높아지고 있는 것이기 때문입니다. 긴밀한 루프가 사라지지는 않겠지만, 하루 중 그것이 차지하는 비중은 점점 줄어들 것입니다.
"하지만 보안 문제는요"
가장 심각한 반론은 워크플로우가 아니라 신뢰에 관한 것입니다: 여러분의 코드와 자격 증명을 타인의 인프라에 올려놓는 것 말이죠. 이는 손사래를 치고 넘어갈 것이 아니라 진지한 답변을 받을 자격이 있으며, 우리가 구축하는 것의 상당 부분이 바로 이 문제를 다룹니다. 실행은 샌드박스 단위로 격리됩니다. 비밀 정보는 저장 시 암호화되고 절대 에이전트의 실행 환경에 놓이지 않습니다. 모든 조직의 데이터는 다른 모든 조직의 데이터와 엄격히 분리됩니다. 원격이라고 해서 부주의하다는 뜻은 아닙니다 — 제대로 구축된다면, 중개된 자격 증명을 사용하는 목적에 맞게 설계된 샌드박스는, 실제 토큰을 환경 변수에 그대로 둔 채 개발자 노트북에서 제멋대로 실행되는 에이전트보다 훨씬 더 방어하기 쉽습니다.
앞으로의 방향
우리는 로컬이 사라진다고 주장하는 것이 아닙니다. 탐색적인 작업과 일부 컴플라이언스 제약이 있는 환경에서는 앞으로도 오랫동안 에디터 안의 에이전트가 자리를 지킬 것입니다. 우리의 주장은 더 좁지만, 그만큼 피하기 어렵다고 생각합니다: 에이전트가 사람이 지켜보지 않아도 실제 작업을 끝낼 수 있게 됨에 따라, 무게 중심은 노트북에서 벗어나 공유되고 항상 켜져 있는 인프라로 옮겨갑니다 — 개발자들이 그것을 선호해서가 아니라, 열 개의 에이전트를 밤낮없이 돌리는 팀이 노트북 덮개를 닫을 때까지 하나만 돌리는 팀보다 단순히 더 많은 성과를 내기 때문입니다.
그것이 TaskGoblin이 걸고 있는 승부수입니다. 여러분의 머신 위에 있는 에이전트를 들여다보는 더 나은 창이 아니라, 애초에 여러분의 머신에 있었던 적이 없는 에이전트 — 여러분의 팀이 이미 사용하는 도구 안에서 기다리며, 여러분이 커피를 다 마시기도 전에 준비를 마치는 에이전트입니다.
