영상에서 단테는 직접 만든 영상 AI 편집 앱 하이퍼컷의 자막 수정, 프로젝트 저장, 최종 출력 흐름을 에이전트 스웜에게 검토하게 했습니다. 여러 에이전트를 동시에 켜 두는 것과 서로 대화하며 일하는 스웜이 실제로 어떻게 다른지, 실제 대화 기록과 결과로 보여줍니다. 코딩 에이전트를 여러 개 돌려 보려는 분, 중앙 분업과 동료 협업 중 무엇을 고를지 고민하는 분께 맞는 내용입니다.
분업과 스웜은 무엇이 다른가
지난 영상에서는 Astra가 일을 나눴습니다. 계산 모듈과 화면처럼 범위를 정해 Luna에게 맡기고, 결과를 받아 다시 검토하는 구조였습니다. Astra는 낮은 추론 설정, Luna는 medium으로 실행했고, 누가 무엇을 할지 정하는 권한은 주로 중앙의 Astra에 있었습니다.
이번에는 동료 에이전트들에게 같은 목표만 주고 담당은 스스로 정하게 했습니다. 영상에서 말하는 스웜은 공동 목표를 받은 에이전트들이 서로 소통하며 일을 나누고 필요한 도움을 주고받는 협업 방식입니다. 핵심은 동시에 일한다는 사실보다 동료와의 대화가 다음 행동을 바꾸느냐입니다.
그래서 "Astra 스웜"을 모델 이름 하나로 이해하면 헷갈립니다. Astra와 Luna는 어떤 모델을 쓰느냐의 문제이고, 스웜은 어떻게 협업하느냐의 문제입니다. Luna가 포함된 팀도 서로 직접 협의할 수 있고, 반대로 Astra를 여러 개 띄워도 모든 판단을 중앙에서 내리면 기존 분업에 더 가깝습니다.
동료끼리 담당을 조정한 장면
동료들에게 보낸 목표는 같습니다. 하이퍼컷의 자막 수정, 프로젝트 저장, 최종 출력 흐름을 살펴보고, 확인한 근거와 아직 확인하지 못한 부분을 정리할 것. 그리고 동료와 먼저 협의해 범위가 겹치지 않게 할 것. 시작할 때 담당 분야는 지정하지 않았습니다.
곧바로 두 번째와 세 번째 동료가 모두 출력 쪽을 보겠다고 했습니다. 단순 병렬 실행이었다면 같은 파일을 읽고 같은 테스트를 돌렸을 상황입니다. 그런데 세 번째 동료가 겹침을 알아차리고 두 번째 동료에게 직접 메시지를 보냈습니다. 출력 파이프라인은 맡기고 자신은 컷과 자막의 시간 매핑으로 범위를 좁히겠다는 내용이었고, 두 번째 동료는 동의하면서 겹치는 자막 테스트 실행도 넘겼습니다. 사람이 다시 개입해 역할을 나눈 것이 아니라 동료끼리 담당과 중복 작업을 조정한 것입니다.
두 번째 장면은 더 실용적이었습니다. 세 번째 동료가 저장을 맡은 첫 번째 동료에게, 테스트 이름에는 "검토 상태 보존"이 들어가는데 정작 입력에 실제 검토 키가 없으니 이 테스트만으로 확인했다고 볼 수 있느냐고 물었습니다. 버그를 발견했다는 말이 아니라 증거가 충분한지 묻는 질문입니다. 첫 번째 동료는 실제 검토 키를 넣고 프로젝트 데이터를 저장 형식으로 바꿨다가 복원한 뒤 다시 검토가 필요하지 않은지 확인하는 다른 테스트를 찾아 실행했고, 통과 결과를 돌려줬습니다. 동료들이 골라 실행한 기존 테스트는 아홉 개였고 모두 통과했습니다.
다만 이 실험에서 동료들은 화면을 조작하거나 실제 영상 파일까지 출력하지는 않았습니다. 대신 서로 찾은 빈틈을 합쳐 다음 검증 순서를 제안했습니다. 컷이 자막을 가로지르는 상태를 만들고, 자막을 수정·검토하고, 프로젝트를 저장했다가 다시 열고, SRT와 영상 파일까지 확인하는 순서입니다.
스웜이 제안한 검증을 실제 앱으로 이어가기
단테는 이 제안을 직접 만든 짧은 음성 샘플로 이어서 확인했습니다. 말하는 구간 세 개 사이에 침묵을 넣고 그중 3.5초를 제거하도록 설정했고, 자막에는 일부러 오타를 넣고 첫 자막이 컷 경계를 가로지르게 했습니다. 자동 전사의 정확도를 재려는 것이 아니라 편집 이후의 저장과 출력 흐름을 보기 위한 입력입니다.
하이퍼컷 화면에서 첫 자막에는 컷 경계 검토가 필요하다는 표시가 뜨고, 편집한 자막 저장 버튼은 비활성 상태였습니다. 컷이 문장을 가로지르면 잘려 나간 말이 자막에 남았는지 확인해야 하기 때문입니다. 출력 함수에서도 이 상태의 자막 저장 요청이 거부되는 것을 확인했습니다. 오타를 고치고 문구와 컷 경계 확인 완료를 누르자 경고 대신 편집본 기준 시각이 표시됐고, 첫 자막의 끝 시각은 잘린 구간만큼 당겨져 편집본에서 4.6초가 됐습니다.
저장과 출력은 실제 앱 함수를 호출해 확인했습니다. 프로젝트를 파일로 쓴 뒤 다시 읽어 수정한 문구와 검토 상태가 유지되는지 봤고, 출력한 SRT 파일을 디스크에서 다시 읽어 수정 문구와 세 개의 자막 구간을 확인했습니다. 최종 영상도 렌더링했는데 원본 약 16.17초가 12.67초가 되어 설정한 3.5초가 줄었고, 합성된 자막도 확인됐습니다. 다만 합성 샘플 결과가 모든 촬영 환경이나 네이티브 앱 설치까지 보장하지는 않습니다.
Codex CLI 실행 설정과 사용량
실행은 Codex CLI 0.153.4에서 했고, 모델은 Astra, 추론 강도는 low로 설정했습니다. 요청문에는 동료 세 명, 같은 목표, 담당은 직접 협의할 것을 적었습니다. 부모 대화 전체를 넘기지 않고 필요한 자료만 전달하게 했고, 대상 파일을 좁히고 테스트 명령도 최대 세 번으로 제한했습니다. 이 제한은 시간이나 토큰을 강제로 차단하는 설정은 아닙니다.
실제로 동료 세 명이 실행됐습니다. 생성 직후 아직 없는 동료에게 메시지를 보내 실패한 경우도 있었지만, 생성이 끝난 뒤에는 통신이 이어졌습니다. 재실행에서도 담당을 스스로 나눴고, 테스트 명령 두 번으로 자막 테스트 5개와 타임라인 테스트 15개가 통과했습니다. Codex 로그에서는 시작 이벤트 세 개와 동료끼리 직접 상호작용한 기록 18개를 확인했습니다.
토큰은 부모와 동료를 모두 포함해 집계했습니다. 입력의 대부분은 캐시 입력이었고, 캐시 입력은 이미 입력 합계에 포함되므로 다시 더하면 안 됩니다. 캐시가 아닌 입력, 캐시 입력, 출력에 각각 공식 표준 API 단가를 적용하면 약 3.20달러로, 실제 구독 청구액이 아니라 같은 사용량을 환산한 값입니다. 메시지를 주고받는 데도 토큰이 들고, Astra low를 썼다고 자동으로 싸지지도 않습니다.
정리
- 에이전트가 몇 명이냐보다 서로의 대화 때문에 일이 어떻게 달라졌는지를 봐야 합니다.
- 이번 실험에서는 동료들이 겹친 담당을 스스로 조정했고, 동료의 질문이 더 적합한 테스트 실행으로 이어졌습니다.
- 작업 경계가 처음부터 분명하면 Astra가 나누고 Luna가 실행하는 분업이 관리하기 쉽고, 함께 탐색하며 확인 대상이 바뀌는 일이라면 동료 협의가 도움이 될 수 있습니다.
- 같은 과제로 두 방식을 비교하지 않았으므로 스웜이 더 빠르거나 싸다고 결론 내리지는 않았습니다.
- 동료 수와 파일 범위를 줄이고, 부모와 동료 사용량을 함께 확인하며 작은 과제부터 시작하는 것이 좋습니다.