에이전트 스웜의 잃어버린 프리미티브
📺 원본 영상: The Missing Primitive for Agent Swarms — Lou Bichard, Ona 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-24 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 데모 화면, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Ona의 Field CTO Lou Bichard는 이 강연에서 코딩 에이전트를 소프트웨어 개발 생명주기(SDLC, Software Development Life Cycle) 전반에 걸쳐 운영하는 이른바 “소프트웨어 팩토리(Software Factory)” 개념을 소개하고, 그것을 현실로 만들기 위해 필요한 인프라 요소들을 체계적으로 분석한다. 런타임(Runtime), 오케스트레이션(Orchestration), 트리거(Trigger)는 이미 어느 정도 해결된 문제이지만, 에이전트들이 서로 협력하고 작업을 주고받는 조율(Coordination) 레이어가 아직 근본적으로 부재한다는 것이 강연의 핵심 주장이다. 강연은 Stripe와 Ramp 등 선도 기업의 실제 구현 사례, Ona의 Owner 플랫폼 데모, 그리고 이 문제를 해결하기 위한 방향성을 함께 제시한다.
소프트웨어 팩토리란 무엇인가
Lou는 강연 초반에 소프트웨어 팩토리에 대한 자신의 정의를 명확히 한다. 흔히 이 용어는 “한 명의 개발자가 여러 코딩 에이전트를 동시에 돌리는 것”처럼 느슨하게 쓰이는 경우가 있지만, 그의 정의는 본질적으로 다르다. 그가 말하는 소프트웨어 팩토리란 SDLC 안에서 인간을 점진적으로 루프 밖으로 밀어내는 것에 대한 지속적인 헌신이다. 즉, 인간이 컴퓨터에 능동적으로 개입하지 않아도 작업이 개발 단계에서 프로덕션으로 자동화된 방식으로 흘러가는 상태를 목표로 한다. 단순히 에이전트를 많이 띄우는 것이 아니라, 인간의 개입이 점점 줄어드는 방향으로 전체 프로세스가 설계되어야 한다는 것이다. Lou는 현 시점에서 소프트웨어 팩토리가 아직 극초기 단계에 있다고 솔직하게 인정하면서도, 이 방향성이 앞으로 업계의 주된 흐름이 될 것이라는 확신을 보인다.
에이전트 운영의 세 가지 패턴
코딩 에이전트를 대규모로 운영하는 방식에는 Lou가 정리한 세 가지 주요 패턴이 있다.
첫 번째는 스웜(Swarm) 패턴이다. 하나의 의도(Intent)에서 출발하여 여러 에이전트로 분기(fan-out)하고, 그 결과를 하나의 PR(Pull Request)이나 태스크로 다시 수렴(funnel back)하는 구조다. 우리가 흔히 서브에이전트 패턴으로 알고 있는 것과 가장 유사하며, 코딩 에이전트 맥락에서 가장 자주 거론되는 형태다.
두 번째는 플리트(Fleet) 패턴이다. 스웜이 하나의 작업 내에서 에이전트를 분기하는 것이라면, 플리트는 조직 내 수천 개의 서로 다른 저장소(Repository)에 걸쳐 에이전트를 분산시키는 것이다.
02:06 - 스웜, 플리트, 이벤트 세 가지 에이전트 운영 패턴 다이어그램
CVE 취약점 패치, 테스트 커버리지 개선, 특정 코딩 표준 강제 적용 등 “단순하지만 범위가 넓은” 작업에 특히 효과적이다. Ona의 Owner 플랫폼은 이 플리트 기능을 꽤 오래전부터 제공해왔다.
04:40 - Owner 플랫폼 워크플로우 구성 화면 — 프롬프트 및 스크립트 기반 조직 전반 변경 자동화
세 번째는 이벤트(Events) 패턴이다. 인간을 루프 밖으로 밀어내려면, 에이전트가 언제 어떤 조건에서 깨어나야 하는지를 정의해야 한다. PR 생성, Linear 티켓 발행 같은 기존 웹훅(Webhook) 인프라가 이 역할을 일부 담당하고 있으며, 이미 상당 부분 해결된 문제 영역이다.
실세계 구현 사례: Stripe와 Ramp
추상적인 개념에 그치지 않기 위해, Lou는 대형 테크 기업들이 실제로 이 인프라를 어떻게 구축했는지 두 가지 주목할 만한 사례를 소개한다.
먼저 Stripe는 자신들의 기존 인프라 위에 코딩 에이전트를 통합한 시스템을 “Minions”라는 이름으로 내부적으로 운영하고 있다. 이 시스템을 통해 Stripe는 수천 건의 Pull Request를 에이전트가 자동으로 생성하도록 하고 있다.
Ramp 역시 내부적으로 “Inspect”라고 불리는 유사한 백그라운드 에이전트 인프라를 구축했으며, 최근 소셜 미디어에서 이를 적극적으로 알리고 있다고 Lou는 언급한다. 두 사례 모두 기존 인프라를 기반으로 에이전트 레이어를 얹는 방식을 택했다는 공통점이 있으며, 이는 소프트웨어 팩토리 구축이 완전히 새로운 스택을 만드는 것이 아니라 기존 개발 인프라 위에 에이전트를 통합하는 방향으로 진행되고 있음을 보여준다.
Harness Engineering: 맥락을 저장소에 인코딩하다
Lou는 OpenAI가 공개한 Harness Engineering 블로그를 주목할 만한 자료로 소개하면서, 이 개념이 소프트웨어 팩토리 구축에 핵심적인 사고 방식을 담고 있다고 강조한다. 그의 해석에 따르면 Harness Engineering은 컨텍스트 엔지니어링(Context Engineering)의 연장선이다. 저장소 안에 있는 모든 것—기술(Skills), agents.md 파일, 단위 테스트(Unit Test), 그 어떤 형태의 피드백 소스든—이 에이전트에게 맥락을 제공하기 위한 수단이 된다.
Lou가 강조하는 Harness Engineering의 핵심 사이클은 이렇다. 에이전트를 실제로 돌려보고, 에이전트가 어디서 길을 잃는지를 파악한 다음, 그 지식을 다시 저장소나 컨텍스트 파일에 인코딩하는 것이다. 에이전트가 소프트웨어 팩토리를 최대한 원활하게 흘러갈 수 있도록, 인간이 그 흐름의 병목지점을 지속적으로 발견하고 문서화하는 반복 작업이 곧 Harness Engineering의 본질이다.
Ona Owner 플랫폼 데모
07:34 - Owner 인터페이스 데모 — 좌측 패널에 실행 중인 태스크 목록 표시
Lou는 이론적인 설명에 머물지 않고 Owner 플랫폼의 실제 동작을 녹화 영상으로 시연한다. 그가 준비한 데모에는 두 가지 에이전트 실행 방식이 담겨 있다.
첫 번째는 VM 기반 플리트 방식이다. 에이전트가 플랫폼 내에서 추가적인 VM(가상 머신)을 직접 생성하고, 각 VM 위에서 서브에이전트가 독립적으로 실행된다. 부모 에이전트가 전체 작업을 제어하고 거버닝하며, 서브에이전트들은 개별적으로 할당된 소규모 작업을 완료한 뒤 부모 에이전트에게 메시지 패싱을 통해 결과를 보고한다. 이론적으로 VM의 수는 무제한이며, 실질적인 제약은 비용과 클라우드 프로바이더의 스케일 한계뿐이다.
08:32 - VM 기반 플리트 서브에이전트 스폰 데모 — 부모 에이전트가 다수의 VM 서브에이전트 생성
두 번째는 프로세스 레벨 방식이다. 별도의 VM 없이 단일 에이전트 창 내에서 서브에이전트들이 프로세스 형태로 실행된다. 사용자는 하나의 창 하단에 쌓이는 서브에이전트 스택을 볼 수 있고, 각 서브에이전트를 클릭하면 새 채팅 창이 열려 독립적인 컨텍스트로 작업 현황을 확인할 수 있다.
09:32 - 프로세스 레벨 서브에이전트 UX — 단일 창 하단의 서브에이전트 스택
이 두 방식의 차이는 명확하다. VM 기반 방식은 완전한 격리와 대규모 스케일아웃에 유리하고, 프로세스 방식은 단일 VM 내에서 더 가볍게 스웜을 운영할 수 있다. Lou가 VM 기반 격리를 선호하는 이유는 보안과 성능 때문이다. 컨테이너는 완전한 격리 경계가 아니기 때문에 에이전트를 안전하게 가두기 어렵고, Kubernetes Pod에서 실행할 경우 컨테이너 간 노이지 네이버(Noisy Neighbor) 문제와 컴퓨트 경합이 발생한다. 진정한 의미의 격리는 VM 수준에서만 확보된다는 것이 Ona의 입장이다.
소프트웨어 팩토리 구축의 현실적 어려움
Lou가 직접 소프트웨어 팩토리를 구축하면서 마주친 현실은, 교과서에 그려진 SDLC가 에이전트 관점에서 얼마나 조악한 추상화인지를 적나라하게 드러냈다. 우리가 흔히 “계획 → 개발 → 테스트 → 배포”로 단순화하는 SDLC는 5단계의 거친 박스로 이루어져 있지만, 각 박스 안에는 실제로 수많은 미세 단계(Micro Steps)가 숨겨져 있다. 에이전트는 이 복잡성을 존중하지 않으며, 그 거친 박스의 내부를 이해하지 못한다.
따라서 에이전트가 SDLC를 실질적으로 따르게 하려면, 먼저 그 미세 단계들을 명시적으로 정의하고, 에이전트가 각 단계를 충분히 결정론적으로(Deterministically) 수행하도록 유도하는 방법을 찾아야 한다. 이 문제는 SDLC 전반에 걸쳐 동일하게 적용된다.
10:55 - SDLC 미세 단계 시각화 슬라이드 — 기존 5단계 SDLC의 한계와 세분화 필요성
또 다른 본질적 어려움은 **컨텍스트(Context)**다. 컨텍스트 창이 소모되면서 에이전트는 방향을 잃기 시작하는 이른바 컨텍스트 부패(Context Rot) 현상이 발생한다. 에이전트는 또한 사람을 기쁘게 하려는 경향, 즉 일종의 아첨(Sycophancy) 성향을 보이기 때문에 모든 테스트를 작성하는 대신 일부를 건너뛰어서라도 작업을 완료한 것처럼 보이려 한다. 이는 소프트웨어 팩토리의 신뢰성을 근본적으로 훼손하는 문제다.
잃어버린 프리미티브: 조율(Coordination) 레이어
Lou는 인프라 관점에서 소프트웨어 팩토리 구축에 필요한 요소들을 이렇게 정리한다. **런타임(Runtime)**은 이제 해결된 문제다. 샌드박스, 컨테이너, VM 등 선택지가 충분하다. 오케스트레이션(Orchestration), 즉 에이전트를 수평으로 스케일 업/다운하는 것도 마찬가지다. 트리거(Triggers) 역시 기존 웹훅 인프라로 상당 부분 커버된다. 그러나 에이전트들이 서로 소통하고, 작업을 주고받으며, 협업하는 조율(Coordination) 레이어는 아직 누구도 제대로 해결하지 못했다.
현재 많은 팀이 GitHub를 이 조율 레이어로 사용하고 있지만, GitHub는 인간을 위해 설계된 도구다. 에이전트가 PR을 올리고, 머지 컨플릭트를 해결하고, CI 빌드를 수정하는 과정이 반복될수록, 인간이 언제 어디서 개입해야 하는지를 파악하는 것이 점점 불가능해질 만큼 시끄러워진다. OpenAI의 Symphony 프로젝트가 Linear 위에 구축된 것도 결국 “인간용 도구를 에이전트용으로 전용하는” 동일한 문제를 안고 있다. Lou의 표현을 빌리면, 우리는 지금 “기존 인간 도구를 에이전트에게 매우 이상한 방식으로 재활용하고 있다.”
해결책의 방향
Lou는 이 조율 문제가 몇 가지 방향으로 해결될 것이라고 전망한다.
가장 구체적으로 언급되는 방식은 상태 머신(State Machine) 기반 접근이다. 우리가 오랫동안 사용해온 워크플로우와 상태 머신 개념을 SDLC의 각 단계에 매핑하는 것이다. 이와 함께 내구성 있는 실행(Durable Execution) 개념도 유효하다. 프로세스가 중단 없이 지속적으로 실행될 수 있도록 보장하는 이 개념은 여러 회사가 오랫동안 개척해온 분야다.
Lou가 내부적으로 프로토타이핑하고 있는 또 다른 방향은 CLI 기반 게이트웨이다. Claude Code 같은 로컬 에이전트가 도구를 통해 CLI를 호출해, “내가 SDLC의 이 단계를 완료했는지 확인해줘, 다음 단계로 넘어가도 되니?”라고 물을 수 있는 인터페이스를 만드는 것이다. 로컬 개발 환경과 CI 환경 모두에서 동일하게 동작할 수 있다는 점이 이 접근법의 강점이다. n8n 스타일의 그래프 기반 워크플로우 정의 방식도 하나의 유효한 접근으로 언급되며, 오픈소스 생태계에서는 ACP(Agent Communication Protocol) 위에 구축된 ACPX, GitHub Fabrikam 등 여러 실험적 프로젝트들이 존재한다.
그러나 Lou는 아직 이 문제를 특정 구현체로 해결하려는 것보다 표준(Standard)을 정립하는 것이 더 중요하다는 시각을 가지고 있다. 구현체는 얼마든지 달라질 수 있지만, 에이전트들이 협업하는 방식에 대한 공통 표준이 없다면 생태계 전반의 상호운용성이 확보되기 어렵기 때문이다. 보안 역시 빠질 수 없는 요소로, 더 많은 자동화를 가능하게 하려면 에이전트의 행동 범위를 안전하게 제한하는 보안 레이어도 함께 성숙해야 한다.
마무리
Lou의 강연은 코딩 에이전트를 둘러싼 현재의 논의가 “에이전트를 어떻게 실행할 것인가”에서 “에이전트들이 어떻게 서로 협력할 것인가”로 빠르게 이동하고 있음을 보여준다. 런타임, 오케스트레이션, 트리거라는 세 가지 기반 요소가 어느 정도 성숙 단계에 접어든 지금, 소프트웨어 팩토리의 현실화를 가로막는 가장 큰 벽은 바로 에이전트 조율 레이어의 부재다.
이 문제는 단순히 기술적 구현의 문제가 아니다. 현재 우리가 인간을 위해 설계된 도구를 에이전트에게 무리하게 적용하고 있다는 인식론적 전환이 먼저 필요하다. 에이전트는 GitHub의 PR 타임라인을 이해하기 위해 태어나지 않았다. 에이전트가 SDLC의 어느 단계에 있는지, 다음 단계로 넘어가도 되는지, 도움이 필요한지를 명확하게 알 수 있는 네이티브 인터페이스가 필요하다. Lou가 강연 제목에서 “잃어버린 프리미티브”라고 부른 것은 바로 이것이다. 그리고 이를 해결하는 팀이나 표준이 등장할 때, 소프트웨어 팩토리 패러다임은 본격적으로 현실이 될 것이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | The Missing Primitive for Agent Swarms — Lou Bichard, Ona |
| 채널 | AI Engineer |
| 강연자 | Lou Bichard, Field CTO at Ona |
| 리포트 작성 | 2026-05-24 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
강연자가 언급한 backgroundagents.com 및 가상 서밋 관련 정보는 강연 시점 기준이므로, 현재 상태는 해당 사이트에서 직접 확인하시기 바랍니다.