터미널 하나와 Claude Code로 시작합니다. 그러다 두 번째 작업이 들어와서 터미널을 하나 더 열고 Codex를 실행하죠. 프론트엔드 수정 건은 세 번째 터미널로 갑니다. 이제 창 세 개를 오가며 alt-tab을 누르고 있습니다. 어느 창이 나를 기다리는지, 어느 창이 10분 전에 질문을 던졌는지, 어느 창이 조용히 끝나고 놀고 있는데 나는 나머지 둘에 집중하느라 신경을 쓰고 있는지 기억하려 하면서요. 아무것도 불타고 있지는 않습니다. 하지만 당신은 에이전트들 사이에서 작업을 배분하는 라우터가 되어버렸고, 그 역할은 어느 에이전트보다도 확장성이 나쁩니다.
비용은 터미널이 아닙니다. 바로 당신입니다. 에이전트를 손으로 돌리면 다음에 무슨 일이 일어날지에 대한 모든 결정이 한 곳, 즉 당신 머릿속에 있습니다. 어느 에이전트가 다음 작업을 받을지, 마지막 diff가 안전한지, 다른 창을 읽는 동안 무엇이 실패했는지. 이 조율은 실제 노동이고, 보상도 없으며, 에이전트를 추가할수록 더 빠르게 늘어납니다.
이 글에서는 코딩 에이전트를 손으로 돌리는 것이 실제로 얼마를 청구하는지, 그 청구서가 복리로 불어나기 전까지 어디에 숨어 있는지, 그리고 그 대부분을 없애주는 워크플로를 살펴봅니다. Sharkly는 당신의 에이전트 위에 놓이는 관리 계층입니다. 이미 쓰고 있는 Claude Code, Codex, 혹은 어떤 런타임이든 그대로 두고, Sharkly가 작업과 격리, 리뷰를 터미널 벽에 흩어진 대신 하나의 공유된 장소에 담아줍니다.
TL;DR
코딩 에이전트를 손으로 돌리는 것은 무료처럼 보입니다. 아무 도구도 그 대가를 청구하지 않으니까요. 진짜 비용은 당신의 주의력입니다. 당신은 에이전트들 사이의 라우터가 되고, 각 에이전트가 무엇을 하는지에 대한 기억이 되고, 모든 창을 따라잡아야 하는 유일한 리뷰어가 됩니다. 이 비용은 에이전트가 둘, 셋일 때는 작게 유지되지만 다섯을 넘어가면 복리로 불어납니다. 계속 손으로 관리할 수도 있고, 이미 쓰는 에이전트를 Sharkly 같은 작업 계층을 통해 라우팅해서 작업을 할당하고, 각 실행을 격리하고, 모든 결과를 리뷰할 Task로 돌려받을 수도 있습니다.
문제는 터미널이 아니라 당신입니다
기억해둘 만한 정의가 있습니다. 터미널은 에이전트가 실행되는 곳이고, task는 에이전트가 실행하는 작업입니다. 에이전트를 손으로 관리하면 당신 외에는 이 둘을 연결하는 것이 아무것도 없습니다. 터미널은 출력을 보여줄 뿐입니다. 그 task가 무엇이었는지, 끝났는지, 다음에 무슨 일이 일어날지 누가 결정하는지 알지 못합니다. 그 모든 것을 당신이 기억에서, 한 번에 창 하나씩 공급합니다.
그래서 “터미널이 너무 많다”는 증상이지 병이 아닙니다. tmux로 에이전트 하나를 다섯 개 창으로 쪼개도 조율이 줄어들지는 않습니다. 그저 배치만 바뀔 뿐입니다. 어느 창이 어느 task를 맡고 있는지, 어느 것이 실행 중인지, 어느 것이 끝나서 사람이 확인해야 하는지에 대한 지도는 여전히 당신이 들고 있습니다. 그 지도는 어디에도 공유되지 않으니, 자리를 뜨는 순간 낡아버리고, 동료가 필요로 하는 순간 존재하지 않습니다.
에이전트를 손으로 돌리는 데 실제로 드는 비용
청구서는 주의력으로 지불되고, 주의력에는 측정 가능한 가격이 있습니다. 서로 무관한 작업 사이를 오갈 때, 당신은 즉시 원래대로 복귀하지 못합니다. Gloria Mark와 동료들이 CHI 2008에 발표한 방해받은 지식 노동에 관한 연구에 따르면, 사람들은 방해를 받고 다른 곳으로 끌려간 뒤 중단된 작업으로 돌아오는 데 평균 20분 이상이 걸린다고 합니다. 작업 전환 연구에 대한 미국심리학회의 요약은 작업 사이를 옮겨 다니며 생기는 생산성 손실이 최대 40퍼센트에 달한다고 봅니다. 에이전트가 끝나서 다른 창으로 고개를 돌릴 때마다, 당신은 그 세금의 어떤 버전을 지불합니다.
에이전트를 손으로 돌리면 그 전환이 당신의 주된 루프가 됩니다. 비용이 쌓이는 지점은 다음과 같습니다:
| 숨은 비용 | 손으로 할 때 나타나는 모습 | 복리로 불어나는 이유 |
|---|---|---|
| 라우팅 | 새 task를 어느 에이전트에게 줄지 기억에 의존해 결정 | 에이전트가 많을수록 머릿속에 담아야 할 조합이 늘어남 |
| 컨텍스트 재로딩 | 각 터미널이 무엇을 하고 있었는지 다시 읽어 기억함 | 전환할 때마다 그 task로 돌아가는 시계가 처음부터 다시 시작됨 |
| 상태 표류 | 각 터미널이 저마다의 브랜치, 환경, 어중간한 수정을 들고 있음 | 한 디렉터리의 두 task가 조용히 서로를 망가뜨림 |
| 리뷰 적체 | 각 실행이 일어나는 것을 본 사람이 당신뿐임 | 끝난 작업이 리뷰할 수 있는 단 한 사람을 기다림 |
| 공유 기록 없음 | 상태가 동료가 볼 수 있는 어디에도 없고 당신 세션에만 있음 | 자리를 뜨면 진행 상황이 보이지 않고, 아무도 이어받을 수 없음 |
이 중 어느 것도 크래시로 나타나지 않습니다. 대신 바빴던 것 같은데 병합된 PR이 여덟 개 대신 세 개 나온 하루로 나타나고, 문제라고 짚을 수 있는 순간은 하나도 없습니다.
실패 모드는 복리로 불어나기 전까지 숨어 있습니다
에이전트가 둘일 때는 전체 지도를 작업 기억에 담아둘 수 있고 비용은 거의 0에 가깝습니다. 이 점은 분명히 말할 가치가 있습니다. 대부분의 조언이 문제를 과장하는 지점이니까요. 한 대의 머신에서 에이전트를 하나 또는 둘 돌리고, 다음 것을 시작하기 전에 각각을 리뷰한다면 아직 관리 계층이 필요하지 않습니다. 움직이는 부품은 0으로 유지하세요.
작업이 시간상 또는 상태상 겹칠 때 방정식이 달라집니다. 같은 체크아웃에서 에이전트 셋을 돌리면 같은 저장소에서 여러 코딩 에이전트가 작업할 때 다루는 격리 문제에 부딪힙니다. 두 에이전트가 같은 파일을 건드리고, 하나가 다른 하나를 조용히 덮어씁니다. 이를 task마다 worktree를 두는 방식, 즉 코딩 에이전트 worktree의 규율로 해결하면 병합 문제를 장부 관리 문제로 바꾸게 됩니다. 어느 디렉터리가 어느 task에 매핑되는지, 어느 것이 지워도 안전한지, 어느 것을 사람이 리뷰 중인지 말이죠. 이를 터미널을 더 늘려 해결하면 창만 더 많아진 채 시작점으로 돌아옵니다.
마지막 비용은 조용한 것입니다. 모든 실행이 개인 터미널에서 일어나면 끝난 작업이 갈 곳은 당신의 주의력뿐입니다. 당신이 에이전트가 일하는 것을 지켜본 유일한 사람이고, diff가 좋은지 말할 수 있는 유일한 사람이니 리뷰가 병목이 됩니다. 병렬 에이전트는 그 출력을 리뷰하는 일이 한 사람에게 직렬화된다면 도움이 되지 않습니다. 이것이 최고의 코딩 에이전트가 그것들을 어떻게 관리하느냐보다 덜 중요한 이유에서 설명하는 함정입니다. 모델은 빨라졌는데 리뷰 큐는 그대로였으니까요.
관리 계층이 없애주는 것
task 보드는 당신이 손으로 하던 부분, 즉 에이전트와 작업 사이의 연결 조직 역할을 없애줍니다. Sharkly에서는 Task가 실행을 소유하는 단위입니다. Task를 Agent에 할당하면, Sharkly가 연결된 Computer에 격리된 worktree를 준비하고, 그곳에서 에이전트 세션을 실행하고, diff와 로그, 그리고 모든 블로커를 그 Task로 돌려줍니다. 당신이 머릿속에 들고 있던 라우팅, 격리, 기록이 대신 Task의 속성이 됩니다.
이렇게 하면 역할 분담이 깔끔하게 유지됩니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 받아들입니다. Sharkly는 Claude Code, Codex, 혹은 이미 쓰는 런타임을 대체하는 것이 아닙니다. 실행은 그들이 담당합니다. Sharkly는 그들 주위에 공유된 task, 연결된 Computer, 리뷰 계층을 더해서, 컨텍스트와 진행 상황, 블로커, 결과, 사람의 리뷰가 당신만 볼 수 있는 다섯 개 세션에 흩어지는 대신 요청부터 릴리스까지 계속 보이도록 합니다. 여러 실행을 한꺼번에 지켜봐야 할 때, 그것이 바로 에이전트 대시보드가 실제로 필요한 이유이며, 팀들이 또 다른 터미널 대신 Claude Code와 Codex 위의 계층을 원하게 되는 이유입니다.
이미 여러 에이전트를 돌리고 있다면, 그것이 Sharkly가 만들어진 워크플로입니다. 터미널을 오가며 계속 손으로 라우팅할 수도 있고, 이미 쓰는 코딩 에이전트를 Sharkly를 통해 실행해서 보드가 지도를 들고 있게 할 수도 있습니다.
손으로 하는 게 괜찮을 때와 그렇지 않을 때
정직한 판단 기준은 짧습니다:
- 다음의 경우 손으로 돌리세요 에이전트가 하나 또는 둘이고, 한 대의 머신에서 돌리며, 다음 것을 시작하기 전에 각각을 리뷰한다면. 어떤 도구든 그 오버헤드는 아직 그만한 가치가 없습니다.
- 다음의 경우 task 계층으로 옮기세요 세 번째 에이전트가 시작되거나, 작업이 저장소 하나를 넘어서거나, 당신이 아닌 누군가가 무엇이 실행 중인지 볼 필요가 있을 때. 그 지점에서 조율 비용은 한 사람의 머릿속에 들어맞지 않기 시작합니다.
신호는 터미널의 개수가 아닙니다. “잠깐, 그게 어느 창이었지?”라고 스스로에게 묻는 순간입니다. 그 질문은 한 문장으로 드러난 조율 세금이고, task 보드가 끝내기 위해 존재하는 바로 그 에이전트 혼돈입니다.
FAQ
tmux나 터미널 멀티플렉서로 충분하지 않나요? 그것은 창을 배치할 뿐, 조율을 없애지는 않습니다. 어느 창이 어느 task를 맡고 있는지, 무엇이 끝났는지, 누가 리뷰하는지는 여전히 당신이 들고 있습니다. 멀티플렉서는 화면 공간을 해결합니다. 에이전트를 손으로 돌리는 비용은 픽셀이 아니라 주의력입니다.
힘들어지기 전까지 에이전트를 몇 개나 손으로 돌릴 수 있나요? 대부분의 사람은 하나나 둘일 때는 괜찮고, 특히 저장소가 둘 이상일 때 셋에서 다섯 사이쯤부터 부담을 느끼기 시작합니다. 정확한 숫자는 각 task가 얼마나 오래 돌아가는지, 각각이 얼마나 많은 리뷰를 필요로 하는지에 달려 있습니다. 신호는 라우팅과 창 다시 읽기가 실제 리뷰보다 하루의 더 많은 부분을 차지할 때입니다.
task 보드가 에이전트를 더 빠르게 만드나요? 아닙니다. Sharkly도 그렇게 주장하지 않습니다. 에이전트는 같은 속도로 실행됩니다. 달라지는 것은 당신의 오버헤드입니다. 라우팅, 격리, 리뷰가 머릿속에 사는 것을 멈추고, 작업이 보이고 리뷰 가능한 Task로 돌아가기 시작합니다.
세션 간에 컨텍스트를 유지하는 건 어떨까요? 개인 터미널은 닫는 순간 그것을 잃습니다. 실행을 Task에 묶으면 목표, diff, 논의가 함께 유지됩니다. 이는 세션 간 컨텍스트 유지 문제를 기억이 아니라 기록 수준에서 해결한 것입니다.
이렇게 하면 Claude Code와 Codex를 함께 계속 쓸 수 있나요? 네. Sharkly는 도구 주위의 작업을 관리할 뿐, 도구를 대체하지 않습니다. 패턴은 Claude Code와 Codex를 함께 실행하는 방법을 참고하세요.
