Are Agent Swarms USEFUL? OpenAI''s GPT-6 Astra SWARM Takeaways

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenAI GPT-6 Astra 사례에서 출발한 에이전트 스웜 실험은 자율 협업의 가능성을 보여주지만, 실용성은 단일 에이전트 대비 품질 향상이 추가 비용과 조율 시간을 정당화하는지에 달려 있다.

📌 핵심 요점

1. 스웜의 핵심은 자율적인 소통과 협력이다. 공용 메시지함과 스레드에서 에이전트들이 역할과 정보를 조율한다. 여러 에이전트를 병렬로 실행하는 것만으로 공동 작업이 성립하지는 않는다.
2. 세 데모는 구현 가능성을 보여줬지만 상대적 우위를 입증하지는 못했다. GLM 5.3 에이전트 10개는 펠리컨 그림, DeepSeek V4 Pro 20개는 레이 트레이서, Gemini 3.7 Flash 30개는 웹 애니메이션을 제작했다. 결과물은 구현됐으나 애니메이션 재현에는 차이가 남았고, 펠리컨은 단일 에이전트 결과와 직접 비교되지 않았다.
3. 조율 자체가 상당한 자원을 소비한다. DeepSeek 스웜에서는 예산 약 30%를 쓰고도 파일 반영이 없다는 내부 진단이 나왔다. Gemini도 약 10달러와 3,200만 토큰을 사용한 시점에 역할을 조율하고 있었다. 다만 이후 완료에 도달했으므로 메시지 공백만으로 실패를 판정하기는 어렵다.
4. 반복 검증은 품질 개선의 유력한 경로다. 펠리컨 작업은 측정·비평·독립 검증을 거쳐 결과물을 확정했다. GLM 스웜은 약 56분 동안 20달러, 4,600만 토큰, 도구 호출 873회를 사용하고 종료했다. 상세한 프롬프트도 사용됐으므로 성과를 협업 효과만으로 설명할 수는 없다.
5. 완료·중단 조건과 실행 통제가 필수다. 파일 잠금은 덮어쓰기를 막고, 완료 도구는 종료 이유와 결과 파일을 남긴다. 실패 탐지와 알림이 실제 중단으로 이어져야 하며, 전용 샌드박스와 코드·네트워크 격리를 운용할 역량도 필요하다.

🧩 배경과 문제 정의

• 출발점은 격리된 평가 에이전트들이 공유 메시지 공간을 만들어 협력했다는 OpenAI Astra 스웜 사건이다. 핵심 관심사는 이런 자율 협력을 통제 가능한 엔지니어링 작업에 활용할 수 있는가다.
• 스웜의 실용성은 에이전트 수보다 결과물의 가치에 달려 있다. 단일 에이전트나 기존 하위 에이전트 위임보다 나은 성과가 추가 토큰 비용과 조율 시간을 정당화해야 한다.
• 실험은 펠리컨 그림, 레이 트레이서, 웹 애니메이션 재현을 대상으로 한다. 메시지 교환, 파일 충돌 방지, 검증, 종료 조건, 샌드박스가 주요 설계 요소다.

🕒 시간순 섹션별 상세정리

1. 단일 에이전트로 확인하는 최소 스웜 구조

• M4 Mac Mini에서 DeepSeek V4 Flash 에이전트 하나를 실행하고 비용을 0.10달러로 제한한다. 첫 작업은 간단한 응답을 통해 실행 구조를 확인하는 것이다. [02:02]
• 시스템은 스웜 목록, 메시지 스레드, 개별 에이전트로 구성된다. 전체 실행 기록을 남겨 각 에이전트의 동작을 추적할 수 있다. [02:44]

2. 모델·규모·예산이 다른 세 작업의 동시 실행

• GLM 5.3 에이전트 10개에는 최대 50달러로 자전거를 타는 펠리컨 제작을, DeepSeek V4 Pro 에이전트 20개에는 최대 40달러로 HTML5 캔버스 레이 트레이서 제작을 맡긴다. [03:42]
• Gemini 3.7 Flash 에이전트 30개에는 최대 30달러로 OpenAI 첫 화면의 캔버스 애니메이션 재현을 맡긴다. 원본 확보 과정에서는 웹사이트 접근 방어가 장애물이 될 가능성이 있다. [04:07]

3. 자율 소통을 허용하되 완료와 중단 조건을 명시

• 스웜은 조율 방식을 미리 고정하지 않은 자율 시스템이다. 공용 메시지함과 스레드가 에이전트 간 협력의 기반이며, 작업 목표는 사용자 프롬프트로 전달한다. [05:25]
• 명확한 목표와 검증 절차뿐 아니라 완료 기준과 작업을 포기할 경로도 필요하다. 맞춤형 실행 시스템은 완료 기준이 없으면 실행하지 않으며, 펠리컨 프롬프트에도 일반적인 단문 요청보다 상세한 요구사항을 추가했다. [06:25]

4. 역할 중복을 해소하는 초기 조율 비용

• 여러 에이전트가 렌더링 측정 작업을 동시에 맡으려 하면서 충돌이 발생한다. 메시지를 통해 담당을 내려놓거나 다른 역할을 선택하면서 업무 중복을 줄인다. [07:52]
• 초기 혼선은 담당 업무와 정보 전달 방식을 합의하는 비용이다. 펠리컨 스웜은 실행 약 9분에 700만 토큰과 약 4달러를 사용한 상태에서 협업을 이어간다. [08:38]

5. 30개 에이전트의 역할 합의와 검증 정보 공유

• Gemini 스웜은 약 10달러와 3,200만 토큰을 사용한 시점에도 역할과 담당 업무를 조율한다. 에이전트 수가 많을수록 일관된 작업 방식에 도달하기까지 시간이 길어지는 양상이다. [10:21]
• 에이전트는 팀 구성과 공동 잔여 예산을 확인하고 메시지함에서 새 정보를 받는다. Playwright로 22초 분량을 초당 한 프레임씩 캡처한 검증에서는 밝기 저하 등의 결함을 찾아 공유한다. [11:34]

6. 레이 트레이서 작업의 교착과 파일 잠금

• DeepSeek 스웜에서는 예산의 약 30%를 사용하고도 실제 파일 반영이 없다는 내부 진단이 나온다. 여러 에이전트가 채팅에서 기준 구현을 작성하려 하면서 조율이 교착 상태에 빠진다. [12:42]
• 파일 선점과 해제 도구는 여러 에이전트의 덮어쓰기를 방지한다. Stitch는 레이 트레이서 파일을 선점해 수정한 뒤 잠금을 풀어 다른 에이전트가 이어서 작업할 수 있게 한다. [14:02]

7. 참여 없는 스레드와 반복 검증의 효용

• 에이전트가 별도 작업 스레드를 만들 수 있어도 다른 에이전트가 참여한다는 보장은 없다. 펠리컨 스웜에서는 새 스레드가 사실상 방치되고, 개별 작업이 계속되는 동안 메시지 활동은 줄어든다. [15:04]
• Doubter는 기준 초안에 반대 관점의 검토와 구체적인 피드백을 추가한다. 여러 에이전트가 같은 목표를 반복 검증하는 구조에서는 검증에 더 많은 연산을 투입할 수 있으며, 시스템 프롬프트로 그 방향을 조절할 수 있다. [15:36]

8. 실험 환경 격리와 로컬 연산 비용의 과제

• 실험에는 로컬 M4 Mac Mini와 exe.dev의 임시 Linux 환경을 활용한다. 임시 환경은 에이전트를 실행해 작업한 뒤 삭제할 수 있어 반복 실험에 적합하다. [17:06]
• 기존 장비에 여러 작업이 겹치면서 안정적인 업무와 위험도가 높은 스웜 실험을 분리할 필요가 생긴다. 향후 로컬 모델용 장비의 경제성은 처리 속도와 API 대비 비용 절감으로 초기 구매비를 얼마나 회수하는지에 달려 있다. [17:42]

9. 스웜의 핵심인 비정형 메시지 교환

• 많은 에이전트를 병렬 실행하는 것만으로 공동 작업이 성립하지는 않는다. 공유 게시판은 서로의 정보를 연결하고 같은 목표를 향해 노력을 조율하는 기반이다. [19:28]
• Simple Swarm의 첫 구현 요소는 메시지 큐와 공용 대화 스레드다. 도구와 실행 구조로 동작을 유도하면서도, 에이전트 사이의 소통 방식에는 상당한 자유를 남긴다. [19:47]

10. 관측 가능한 실패 조건과 최후의 방어선

• 목표에 맞는 동작을 유지하려면 시스템 프롬프트와 도구의 제약을 함께 설계해야 한다. 문제가 생겼을 때 탐지·알림이 가능하고, 실패 조건이 실제 제어 동작으로 이어져야 한다. [20:18]
• 측정과 관측은 성능 개선뿐 아니라 샌드박스 이탈을 알아차리는 데도 필요하다. 관측보다 문제가 빨리 확대되는 경우에는 전용 샌드박스가 최후의 방어선으로 작동하고 심각한 이상 시 중단할 수 있어야 한다. [21:19]

11. 소통 공백과 작업 종료로 수렴하는 서로 다른 양상

• Gemini 스웜에는 긴 메시지 공백과 비활성 에이전트가 나타난다. 일부 에이전트는 정체나 시간 초과 등의 이유로 종료됐지만, 정확한 원인은 추가 확인이 필요하다. [22:07]
• 펠리컨 작업에서는 최종 기준본 감사와 독립 검증이 진행된다. 에이전트들은 예산과 메시지함을 반복 확인하며, GLM 5.3의 협업은 결과물을 확정하는 방향으로 수렴한다. [22:54]

12. 상호 승인에서 명시적인 완료 처리까지

• GLM 스웜은 실행 약 54~55분, 비용 약 20달러 시점에 서로의 작업을 참조하며 최종 승인을 주고받는다. 반대 관점의 검증과 추가 확인도 결과물 확정 과정에 포함된다. [24:00]
• 완료 도구는 종료 이유와 결과 파일을 남긴 뒤 에이전트 세션을 끝낸다. GLM 스웜은 약 56분 동안 20달러, 4,600만 토큰, 도구 호출 873회를 사용하고 예산을 남긴 채 종료한다. [26:00]

13. 다른 스웜의 종료 상태와 소통량 해석의 한계

• Gemini 스웜도 완료 호출에 도달했고, 약 6,100만 토큰과 도구 호출 2,000회를 사용했다. GLM보다 빠르고 비용도 적게 들었으므로, 적은 메시지가 반드시 작업 실패를 뜻한다고 단정하기 어렵다. [26:42]
• DeepSeek 스웜은 아직 실행 중이지만 최종 기준본을 확정하는 움직임이 나타난다. 메시지는 39개이며 예산도 남아 있어, 진행 과정의 조율 문제와 최종 산출물은 따로 확인필요가 있다. [27:02]

14. 세 결과물의 구현 성과와 남은 차이

• Gemini 결과물은 실제 HTML5 캔버스 애니메이션으로 동작한다. 원본과 비슷한 발상은 유지하지만 움직임이 느리고 유려한 특성은 충분히 재현하지 못했으며, 그 원인을 에이전트의 시간 인식과 연결하는 해석은 추정이다. [27:42]
• DeepSeek 레이 트레이서는 3차원 공간의 빛과 반사를 처리하고, 카메라 이동과 여러 렌더링 화면을 지원한다. 시연 중 브라우저에 부담을 주는 듯한 반응도 나타난다. [28:11]

15. 반복 검증의 효과와 완료·중단 조건

• 펠리컨 결과물에는 에이전트 간 측정, 비평, 이중·삼중 검증이 반복됐다. 하나의 과제에 검증을 집중하는 방식이 결과 품질을 높였지만, 입력 프롬프트가 단순한 공통 프롬프트와 완전히 같지는 않았다는 단서가 있다. [28:56]
• 완료 기준은 성공의 의미와 성공할 수 없을 때의 탈출 경로까지 포함해야 한다. 해결 가능성이 보이지 않는데도 계속 밀어붙이면 규칙 위반이나 해킹으로 이어질 위험이 있어, 완료·중단 조건을 프롬프트와 에이전트 실행 프레임워크의 규칙에 반영해야 한다. [30:36]

16. 스웜의 실용성과 구축에 필요한 역량

• 세 가지 모의 사례는 10달러·50달러 수준의 예산으로 스웜의 협업 가능성을 보여준다. 실제 엔지니어링에도 활용할 수 있다는 판단이지만, 작은 데모의 성과와 별개로 비용과 운용 기술이 필요하다. [31:31]
• 구축 노력과 기술 요구 수준에서 스웜은 소프트웨어 팩토리와 다크 팩토리 사이에 놓인다는 평가다. 소프트웨어 팩토리 구축 경험과 샌드박스 운영, 코드 격리, 네트워크 차단 역량이 부족하면 스웜의 실패를 통제하기 어렵다. [33:19]

17. 자율적 협업의 확장성과 악용 위험

• 중앙에서 조율하는 다중 에이전트 오케스트레이션과 달리, 별도 조율 없이 에이전트들이 서로 소통하며 협력하는 스웜이 새로운 활용 가능성을 연다. OpenAI의 사례는 이런 방식이 의도치 않게 작동한 경우라는 해석이다. [34:05]
• 대형 연구소의 연산 자원과 숙련된 엔지니어가 고객이나 경쟁사 공격이라는 목표에 결합한다면 큰 피해가 발생할 수 있다는 우려가 있다. 이는 실제 공격 사실이 아니라, 강력한 도구를 사람이 악용하는 가상 시나리오다. [34:29]

18. 적합한 활용처 탐색과 구현 공개 보류

• 펠리컨 생성 같은 단순 작업에는 스웜이 필요하지 않다. 어려운 수학 문제, 기업 데이터의 인사이트 발굴, 사업 기회의 우선순위 평가 등이 잠재적 활용처지만, 실제로 어디에 필요한지는 추가 실험이 필요하다. [36:09]
• 데모용 스웜 시스템은 당분간 오픈소스로 공개되지 않을 예정이다. 로컬 M4 환경에서도 안전성을 우려하며 검토 시간을 더 확보하려는 결정이고, 차세대 제품에 포함할지는 미정이다. [36:55]

19. 자율 시스템 개발 역량과 차세대 제품 전환

• 에이전틱 엔지니어링은 사람을 대신해 행동할 수 있는 자율 시스템을 다루는 소프트웨어 엔지니어링이다. 차세대 모델로 가능한 작업의 범위를 다시 판단하고, 이를 설계·운용하는 역량을 익히는 것이 중요하다. [37:37]
• 차세대 ‘페이즈 3’ 제품은 개발 중이며, 4분기에 추가 내용을 공개하고 분기 말 출시를 목표로 한다. 개발 노력은 페이즈 3으로 이동하고, 기존 페이즈 2 교육 과정 회원에게는 새 제품 관련 혜택을 제공할 예정이다. [38:06]

🧾 결론

• 스웜은 작동하는 결과물을 만들 수 있지만, 이번 데모만으로 단일 에이전트나 기존 하위 에이전트 위임보다 효율적이라고 결론 내릴 수는 없다.
• 실용성 평가는 에이전트 수나 메시지량보다 결과 품질, 총비용, 완료 시간, 검증 결과를 중심으로 해야 한다.
• 단순한 펠리컨 생성에는 스웜이 필요하지 않다는 평가다. 어려운 수학 문제, 기업 데이터 분석, 사업 기회 평가 등은 추가 실험이 필요한 잠재적 활용처다.

📈 투자·시사 포인트

• 도입 경제성을 판단하려면 토큰 비용뿐 아니라 조율 시간과 구축·운용 부담까지 포함해 기존 방식과 비교해야 한다. 작은 데모의 성공만으로 생산성이나 수익성을 일반화하기는 어렵다.
• 스웜 활용에는 모델 성능과 함께 메시지 교환, 파일 충돌 방지, 검증, 관측, 종료 제어를 설계하는 역량이 요구된다. 조직은 이 운용 부담을 감당할 수 있는지 점검필요가 있다.
• 로컬 모델용 장비의 경제성은 처리 속도와 API 대비 비용 절감으로 초기 구매비를 얼마나 회수하는지에 달려 있다.
• 데모 시스템의 오픈소스 공개는 보류됐고 차세대 제품 포함 여부도 미정이다. 시연된 기술의 가능성과 실제 이용 가능한 제품 범위는 따로 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 모델·에이전트 수·작업·예산이 서로 달라 모델별 성능이나 적정 스웜 규모를 직접 비교하기 어렵다. 펠리컨 작업에는 동일 조건의 단일 에이전트 비교가 없고 프롬프트 차이도 있다.
• Gemini의 비활성 에이전트와 종료 원인은 추가 확인이 필요하다. 애니메이션 움직임의 차이를 에이전트의 시간 인식으로 설명하는 해석도 추정이다.
• 제공 자료에서 DeepSeek의 최종 비용·실행 시간·명시적 종료 상태는 확인되지 않는다. 브라우저 부담도 시연 중 관찰된 반응으로, 정량적인 성능 측정은 제시되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 동일 과제와 동일 요구사항으로 단일 에이전트, 하위 에이전트 위임, 스웜을 비교하고 품질·비용·완료 시간을 기록한다.
• 실행 전에 성공 기준, 검증 절차, 예산 한도, 해결 불가 시 중단 경로를 프롬프트와 실행 시스템에 명시한다.
• 메시지 기록, 담당 업무, 파일 잠금, 결과 파일과 종료 이유를 추적해 조율 정체와 실제 구현 진척을 구분한다.
• 안정적인 업무 환경과 실험 환경을 분리하고, 샌드박스·코드 격리·네트워크 차단 및 이상 시 중단 동작을 확인한다.

❓ 열린 질문

• 어떤 과제에서 자율적인 스웜 협력이 단일 에이전트나 중앙 조율 방식보다 일관되게 더 좋은 결과를 내는가?
• 펠리컨 결과의 품질 향상 중 반복 검증, 상세한 프롬프트, 에이전트 수가 각각 기여한 정도는 얼마인가?
• 에이전트 수를 늘릴 때 추가 검증의 이익보다 역할 조율과 소통 비용이 커지는 지점은 어디인가?