코딩 에이전트와 함께 일하기 위한 도구들은 정말로, 그것도 빠르게 좋아지고 있습니다. 처음 등장한 것은 자동완성이었습니다. 그다음은 프롬프트를 받아 diff를 만들어낼 수 있는 에이전트였습니다. 이제 최신 기술의 정점은 개인용 커맨드 센터입니다: 한 명의 개발자가 여러 에이전트를 동시에 오케스트레이션하는 데스크톱이나 터미널 앱 — 병렬 워크트리, 번들로 묶인 스킬, 예약된 자동화, 검토를 기다리는 실행 큐. 이것은 진짜 진보이며, 코드를 써서 생계를 유지한다면 가질 만한 가치가 있습니다.
하지만 그 모든 것이 어디에 존재하는지 보십시오: 한 사람의 노트북 위, 한 사람의 세션 안, 정확히 한 쌍의 눈에만 보이는 곳입니다. 아무리 많은 에이전트를 관리하더라도, 커맨드 센터는 기본적으로 싱글 플레이어입니다. 그리고 소프트웨어는 싱글 플레이어 게임이 아닙니다.
자동완성에서 커맨드 센터로
에이전트 도구의 각 세대는 이전 세대의 병목을 해결했습니다. 자동완성은 타이핑을 해결했습니다. 프롬프트-투-diff 에이전트는 백지 문제를 해결했습니다. 커맨드 센터는 한 명의 개발자가 여러 에이전트를 병렬로 실행할 수 있게 함으로써 "프롬프트 하나, diff 하나, 대기 한 번"이라는 루프를 해결했습니다.
그중 어느 것도 해결하지 못한 것은 소유권의 단위가 그대로였다는 점입니다: 내 에디터, 내 세션, 내 에이전트. 인터페이스는 더 강력해졌지만, 결코 노트북을 떠나지 못했습니다.
싱글 플레이어의 한계
개인용 에이전트에는 아무리 다듬어도 고칠 수 없는 구조적인 문제가 있습니다: 그것이 배우는 모든 것이 비공개 세션 안에 갇혀버린다는 것입니다.
당신과 당신의 에이전트가 결제 서비스가 왜 그런 식으로 구성되어 있는지 알아냈을 때, 그 이해는 당신의 채팅 기록 안에만 존재합니다. 내일 동료의 에이전트가 같은 질문에 부딪히면, 처음부터 다시 시작하게 됩니다 — 그리고 당신이 휴가 중이라면 동료 역시 처음부터 시작하게 됩니다. 이것을 팀 전체로 곱하면 이상한 종류의 조직적 건망증이 생깁니다: 회사는 하루에 수십 개의 지능적인 세션을 실행하면서도 그 어느 것에서도 거의 아무것도 유지하지 못합니다.
두 번째 문제도 있습니다: 위임입니다. 에이전트가 당신의 도구 안에 존재한다면, 오직 당신만이 그것에게 일을 줄 수 있고, 오직 당신만이 그것이 한 일을 볼 수 있습니다. "당신의 에이전트가 이걸 좀 봐줄 수 있어요?"라는 말은 당신에게 보내는 요청이 되어, 당신의 주의를 거쳐, 당신의 기기에서 실행됩니다. 그 에이전트에게는 관리자는 있지만 팀은 없습니다.
에이전트가 공유되면 무엇이 달라지는가
우리는 TaskGoblin을 다른 모델 위에 만들었습니다: 에이전트는 당신이 여는 앱이 아니라, 당신의 도구들이 이미 대화하는 법을 알고 있는 팀원입니다.
에이전트는 당신의 팀이 일하는 모든 곳에 고유한 아이디를 가지고 있습니다 — GitLab과 Slack에서는 @taskgoblin, GitHub에서는 taskgoblin[bot]입니다. 팀의 누구든 동료를 대하듯 에이전트에게 일을 시킬 수 있습니다: Linear 이슈를 할당하거나, 머지 리퀘스트 댓글에서 멘션하거나, GitHub에서 이슈에 라벨을 붙이거나, Slack 스레드에서 무언가를 물어볼 수 있습니다. 에이전트는 그 작업을 받아 클라우드 샌드박스에서 수행하고 — 누구의 노트북도 아닌, 항상 켜져 있는 곳에서 — 작업이 이미 존재하는 곳에 결과를 전달합니다: 브랜치, 머지 리퀘스트, 리뷰 댓글, 스레드의 답글입니다.
이것은 누가 그 작업을 보고 방향을 잡을 수 있는지를 바꿉니다. 에이전트의 결과물은 비공개 기록이 아니라, 팀 전체가 검토할 수 있는 머지 리퀘스트이고, 누구나 읽을 수 있는 댓글의 흐름이며, 공개적으로 보드를 가로질러 이동한 이슈입니다. 감독은 더 이상 혼자 하는 활동이 아니라, 인간의 작업에서 이미 그러하듯이 팀이 공유된 공간에서 이미 가진 도구로 함께 하는 일이 됩니다.
컨텍스트의 흔적은 작업과 함께 남는다
여기서 복리 효과가 생깁니다. 에이전트가 당신 팀의 시스템 안에서 작업하기 때문에, 그 컨텍스트는 한 사람의 세션이 아니라 작업 자체에 고정됩니다.
TaskGoblin이 작업하는 모든 이슈에는 스레드가 있습니다: 대화, 결정 사항, 푸시한 브랜치, 그리고 배운 것을 다음 실행으로 전달하는 인계 메모리입니다. 사흘 후 후속 댓글을 달고 돌아와도, 이력을 손에 쥔 채로 재개합니다 — 누군가 컨텍스트를 다시 붙여 넣어서가 아니라, 컨텍스트가 한 번도 떠난 적이 없기 때문입니다. 그 흔적은 이슈와 머지 리퀘스트에 남아 있으며, 그곳이 바로 다음 사람 — 또는 다음 실행 — 이 실제로 살펴볼 곳입니다.
잘 인정받지 못하는 점은, 그 흔적의 주된 수혜자가 인간이 아니라는 것입니다. 바로 에이전트입니다. 이 파일에 대한 마지막 변경이 어떻게 리뷰되었는지, 두 링크 떨어진 이슈에서 팀이 무엇을 결정했는지, 이전 접근 방식이 왜 되돌려졌는지를 볼 수 있는 에이전트는, 매일 아침 텅 빈 방에서 깨어나는 에이전트보다 단순히 더 나은 엔지니어입니다.
팀은 한 번만 가르친다
공유된 컨텍스트는 에이전트의 작업을 플라이휠로 바꿉니다. 검토된 머지 리퀘스트 하나하나, 동료가 댓글로 남긴 수정 사항 하나하나, 이슈에 기록된 결정 하나하나가 다음 실행을 더 잘 알게 만듭니다 — 마침 그 세션에 있었던 사람뿐 아니라 모두를 위해서 말입니다. 팀은 각자 자신의 사본을 비공개로 가르치는 대신, 공개적으로 에이전트를 단 한 번만 가르칩니다.
개인용 커맨드 센터는 아무리 좋아지더라도 이 플라이휠을 돌릴 수 없습니다. 배움이 오직 한 사람만 볼 수 있는 곳에서 일어나기 때문입니다.
간단한 테스트
어떤 도구가 어느 쪽에 있는지 알고 싶다면, 두 가지를 물어보십시오. 팀의 누구든 이미 일하고 있는 곳에서 에이전트를 @멘션할 수 있습니까? 그리고 그렇게 했을 때, 아무도 다시 설명해줄 필요 없이 이슈, 스레드, 이전 실행이라는 이력을 알고 도착합니까?
답이 '아니오'라면, 그것은 개인용 도구입니다. 어쩌면 아주 훌륭한 도구일 수도 있습니다 — 하지만 팀에게 던져지는 질문은 이제 "에이전트가 코드를 쓸 수 있는가?"에서 "우리가 어떻게 함께 에이전트에게 위임하고, 감독하고, 함께 배울 것인가?"로 옮겨갔습니다. 이 질문은 공유된 공간에서만 답할 수 있습니다. 그것이 바로 TaskGoblin이 당신의 노트북 위 창이 아니라, 당신의 팀이 매일 아침 이미 열고 있는 도구들 안의 팀원으로 제공되는 이유입니다.
