Codex 에이전트 하나를 돌리는 건 간단합니다. 터미널을 열고 작업을 설명한 뒤 지켜보면 됩니다. 문제는 세 개부터 시작됩니다. 한 에이전트는 인증 모듈을 리팩터링하고, 다른 하나는 불안정한 테스트를 고치고, 세 번째는 마이그레이션 초안을 작성하는데, 각자가 저마다의 스크롤백을 가진 터미널 탭에 따로 존재합니다. 10분만 지나면 어느 탭에 어떤 작업이 있는지, 마이그레이션이 끝났는지, 테스트 수정이 어느 브랜치에 반영됐는지 기억나지 않습니다. 에이전트는 멀쩡합니다. 무너진 건 이들을 추적하는 당신의 능력입니다.
이것이 바로 "여러 Codex 에이전트 관리하기"의 진짜 문제입니다. 동시성이 아닙니다. Codex는 각기 다른 작업 디렉터리에서 기꺼이 병렬로 실행됩니다. 문제는 그 작업의 상태, 즉 각 에이전트가 무엇을 하고 있는지, 무엇이 끝났는지, 무엇이 실패했는지, 무엇을 검토해야 하는지가 터미널 탭과 워크트리 폴더, 그리고 당신의 기억 속에 흩어져 있다는 점입니다. 이 중 하나라도 놓치면 흐름을 놓치게 됩니다.
Sharkly는 바로 이 간극을 위해 존재합니다. 이미 코딩 에이전트는 가지고 있으니, Sharkly가 모든 에이전트 실행에 하나의 공유 기록을 부여해 이들을 팀으로 만들어 줍니다. 이 글에서는 먼저 수동 설정을 살펴봅니다. 무엇을 자동화하는지 이해해야 하기 때문입니다. 그런 다음 태스크 보드가 어떤 역할을 하는지 보여드립니다. 마지막으로 오늘 바로 실행할 수 있는 체크리스트로 마무리합니다.
"흐름을 놓친다"는 것의 진짜 의미
흐름을 놓친다는 건 모호한 얘기가 아닙니다. 구체적인 실패입니다. 작업 상태에 단일한 보금자리가 없는 것입니다. 여러 Codex 세션을 직접 돌리면 각 작업의 진실이 동시에 네 곳에 쪼개져 있습니다. 지시는 입력한 터미널에, 변경 사항은 Git 작업 디렉터리에, 상태는 당신 머릿속에, 결과는 아직 열지 않은 풀 리퀘스트에 있습니다. 이 넷을 동기화해 주는 건 아무것도 없습니다. 터미널을 닫으면 지시가 사라집니다. 탭을 전환하면 상태는 추측일 뿐입니다. 에이전트를 더 추가할수록 "지금 무슨 일이 벌어지는가"의 사본이 늘어나고, 이들을 하나로 묶는 유일한 통합 지점은 당신입니다.
그래서 여러 Codex 에이전트를 관리하는 목표는 좁고, 명확하게 말할 가치가 있습니다. 모든 에이전트의 작업, 진행 상황, 변경 사항, 검토 상태를 사적인 터미널 세션에 쪼개 두지 말고 한곳에 유지하는 것입니다. 아래의 모든 내용은 이 단 하나의 기준으로 판단됩니다.
1단계: 워크트리로 각 에이전트 격리하기
첫 번째 실패 유형은 충돌입니다. 두 Codex 에이전트를 같은 폴더로 향하게 하면 서로의 편집을 덮어쓰고, 서로의 파일을 스테이징하고, 아무도 읽을 수 없는 diff를 만들어 냅니다. Git 워크트리는 각 에이전트에게 같은 저장소의 자체 체크아웃을, 자체 브랜치 위에 부여함으로써 이 문제를 깔끔하게 해결합니다.
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
이제 각 디렉터리 안에서 Codex 세션을 하나씩 시작합니다. 각 에이전트는 자기 파일만 보고, 자기 브랜치에만 커밋하며, 다른 에이전트를 침범할 수 없습니다.
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
여기서 짚어야 할 실패 유형: 워크트리는 파일 충돌을 해결할 뿐, 추적은 해결하지 못합니다. 이제 이름이 거의 똑같은 폴더 세 개가 생겼고, 각 폴더에 어떤 작업이 담겼는지 기록이 없습니다. 작업을 인코딩하는 이름 규칙(agent/<task>)을 채택하세요. 일주일만 지나면 repo-2와 repo-3은 아무 의미도 없어집니다. 더 깊은 원리가 궁금하다면 AI 코딩 에이전트를 위한 Git 워크트리와 더 넓은 패턴을 다룬 여러 Codex 작업을 한 번에 실행하기를 참고하세요.
2단계: 세션을 시야에 두기
세 에이전트가 세 탭에 있다는 건 실수로 Cmd+W를 눌러 실행 중인 작업을 죽이고 스크롤백을 잃을 수 있다는 뜻입니다. tmux 같은 터미널 멀티플렉서는 모든 세션을 이름 붙은 윈도우에 살려 두고, 나중에 분리했다가 다시 붙일 수 있게 해 줍니다.
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
이름 붙은 윈도우(auth, flaky, migration)는 순수한 탭이 버려 버리는 라벨을 복원해 줍니다. Ctrl-b d로 분리하고, 노트북을 닫고, 아침에 다시 붙이면 세션이 그대로 남아 있습니다.
여기서 짚어야 할 실패 유형: tmux는 세션을 실행시켜 둘 뿐, 어느 세션이 당신을 필요로 하는지 알려주지 않습니다. 20분 전에 끝난 에이전트와 오류가 난 에이전트는 밖에서 보면 똑같습니다. 조용한 팬(pane)일 뿐입니다. 상태를 알려면 결국 각 윈도우를 찾아가 마지막 100줄을 읽어야 합니다. 이 폴링 비용은 에이전트를 추가할 때마다 커지고, 시간이 지날수록 수동 설정이 더 무겁게 느껴지게 만드는 세금입니다.
3단계: 상태와 검토를 오래 남는 곳에 기록하기
마지막 수동 조각은 사람들이 건너뛰는 부분입니다. 각 에이전트가 무엇을 만들어냈고 당신이 그것을 수락했는지 적어 두는 것입니다. 스크롤백은 기록이 아닙니다. 사라지고, 작업 간 검색도 안 되고, 동료가 읽을 수도 없습니다. 가벼운 버전은 손으로 갱신하는 평범한 체크리스트입니다.
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
이것이 축소판으로 본 전체 작업입니다. 진행 상황, 장애 요소, 결과, 그리고 사람의 검토가 요청부터 릴리스까지 계속 보이는 오래 남는 장소 말입니다. 이를 충실히 유지하면 오랫동안 터미널에서 여러 에이전트를 관리할 수 있습니다. 문제는 당신이 동기화 엔진이 되어, 뭔가 바뀔 때마다 손으로 갱신해야 한다는 점입니다. 에이전트 출력을 감사 가능하게 만드는 방법은 AI 코딩 에이전트가 완료한 작업을 추적하는 방법을 참고하세요.
직접 구축한 설정이 확장을 멈추는 지점
수동 방식이 충분한 때를 솔직히 인정하세요. 범위가 잘 잡힌 작업을 하는 Codex 에이전트 한두 개라면, 워크트리 + 이름 규칙 + 손으로 관리하는 상태 파일로 충분합니다. 필요하지 않은 도구를 추가하지 마세요. 움직이는 부품이 거의 없고, 전부 머릿속에 들어갑니다.
방정식은 예측 가능한 지점에서 바뀝니다. 다음과 같은 순간에 느끼게 됩니다.
- 에이전트를 세 개 이상 돌리고 있고, 폴링 비용(모든 팬을 방문하고, 끝부분을 읽고, 상태를 기억하기)이 에이전트가 절약해 주는 시간보다 더 많이 잡아먹을 때.
- 작업이 저장소 하나를 넘어 여러 곳에 걸쳐 있어, 워크트리만으로는 하나의 깔끔한 그림이 되지 않을 때.
- 다른 누군가 "지금 에이전트들이 뭐 하고 있어?"라고 묻는데, 솔직한 답이 당신의 터미널과 기억 속에만 있을 때.
이 모두가 글 서두의 동일한 근본 원인입니다. 공유 보금자리가 없는 작업 상태 말입니다. 수동 설정은 그것을 확장되지 않는 단 한 곳, 즉 당신 안에 유지합니다. 팀이 이 벽에 가장 빨리 부딪히며, 그래서 병렬 AI 코딩 에이전트를 관리하는 최고의 도구들이 모두 같은 결론으로 수렴합니다. 작업에 터미널 밖의 보금자리를 주라는 것입니다.
태스크 보드가 더해 주는 것
태스크 보드는 관리 단위를 "터미널 세션"에서 "Task"로 바꿉니다. Sharkly에서는 이미 Codex를 돌리고 있는 Computer를 연결한 뒤, 팬에 타이핑하는 대신 Codex 에이전트에 Task를 할당합니다. 에이전트는 자체 격리된 워크트리에서 실행되고, 실행·진행 상황·장애 요소·결과가 모두 Task로 돌아옵니다. 더 이상 폴링하지 않아도 됩니다. 보드가 이미 무엇이 끝났고 무엇이 실패했는지 알고 있습니다.
역할 분담은 의도적이며, 경계로 명확히 말할 가치가 있습니다. Sharkly는 Codex의 대체물이 아닙니다. 실행은 Codex가 담당합니다. Sharkly는 그 주위에 공유 태스크, Computer, 컨텍스트, 검토 계층을 더합니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수락합니다. 자동화는 당신의 판단이 필요한 지점에서 멈추는데, 그건 코드가 아니라 검토 게이트입니다.
이것이 수동 상태 파일이 애초에 도달하려던 것이며, 이제 오래 남고 공유됩니다. 터미널이 줄 수 없는 세 가지가 여기서 나옵니다.
- 폴링 없는 상태. 각 Task는 팬을 방문하지 않고도 실행 중, 완료, 차단됨, 검토 필요를 보여줍니다.
- 저장소 전반의 하나의 그림. 여러 저장소와 여러 에이전트의 Task가 하나의 Space에 모이므로, 에이전트가 늘어도 돌봐야 할 터미널이 늘지 않습니다. 팀이 Claude Code와 Codex를 함께 실행하는 이유도 같습니다.
- 지켜지는 검토 단계. 결과는 변경 요약과 증거가 첨부된 휴먼 인 더 루프 게이트에서 대기하므로, 대기 중인 걸 잊어버려서 병합되는 일이 없습니다.
이 모든 걸 워크트리와 규율로 직접 구축할 수도 있고, 에이전트 수가 늘어나면 Sharkly로 워크플로를 관리할 수도 있습니다. Codex는 그대로 있고, 관리 부담이 당신 어깨에서 내려갑니다. 이미 여러 Codex 에이전트를 돌리고 있다면, 그게 바로 Sharkly가 겨냥해 설계된 문제입니다.
오늘 바로 실행할 수 있는 체크리스트
수동으로 남든 보드로 옮기든, 흐름을 놓치지 않게 해 주는 최소 조건은 이렇습니다.
- [ ] 에이전트당 하나의 격리된 워크트리, 작업 이름을 딴 브랜치 위에. 한 폴더에 두 에이전트를 절대 넣지 않기.
- [ ] 작업을 인코딩하는 이름 규칙.
repo-3보다agent/auth-refactor가 낫습니다. - [ ] 작업을 죽이지 않고 분리·재연결할 수 있는 오래 사는 세션(tmux 또는 보드).
- [ ] 터미널 스크롤백 밖에 있는 오래 남는 상태 기록: 작업, 브랜치, 상태, 검토 상태.
- [ ] 명시적인 검토 게이트. 사람이 수락할 때까지 어떤 브랜치도 병합되지 않음.
- [ ] 개수 점검: 에이전트 세 개 이상, 또는 저장소 두 개 이상이면 상태를 머릿속에서 꺼내기.
폴링 세금이 아플 때까지 수동 버전을 실행하세요. 아파질 때 기존 코딩 에이전트를 Sharkly로 실행하면 추적이 당신이 아니라 보드의 일이 됩니다.
FAQ
Codex 에이전트를 현실적으로 한 번에 몇 개까지 돌릴 수 있나요? 머신과 요율 제한이 허용하는 만큼입니다. 가장 먼저 부딪히는 한계는 보통 기술이 아니라 사람입니다. 손으로 세 개 이상을 추적하는 지점에서 대부분 흐름을 놓칩니다. 실행 측 한계는 Codex 동시 스레드와 서브에이전트를 참고하세요.
태스크 보드가 Codex를 대체하나요? 아닙니다. Codex는 실행하고, 보드는 그 주위에서 할당, 격리, 컨텍스트, 검토를 관리합니다. 둘은 서로를 보완합니다.
