본문으로 건너뛰기

반자율 AI 에이전트 스웜 ALPHA 최종 보고서

인간 Founder의 승인 아래 7개 AI 에이전트가 9일 동안 8개 인증 기능과 143개 이상의 테스트를 완성했지만, 보안 사고와 조정 한계로 완전 자율 운영에는 이르지 못했습니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

이 보고서는 인간 Founder가 전략과 병합을 통제하는 가운데 7개 AI 에이전트가 OpenCode와 이메일로 협업해 9일 동안 인증·사용자 관리 시스템을 구축한 과정을 정리합니다. 에이전트들은 Product Manager, Backend, Frontend, QA, Security, CI/CD, Documentation 역할로 나뉘었고, Express·SQLite 백엔드와 React·Vite 프런트엔드에 이메일 인증, refresh token rotation, OAuth, 2FA, 동시 세션 관리 같은 8개 기능을 추가했습니다. 보고서 기준으로 59개 이상의 PR을 병합하고 143개 이상의 자동화 테스트를 통과했으며 최종 취약점은 0건, 총비용은 USD 0이었습니다. 다만 OpenCode rate limiting, 장기 세션의 protocol drift, 이메일 spoofing과 악성 payload 사건이 발생해 인간의 승인 절차와 사용자 권한 분리, QA·Security 검증이 없으면 스웜이 독립적으로 전진하기 어렵다는 한계도 확인됐습니다.

실용적 조언

  • 에이전트마다 별도 Linux 사용자를 부여하고 파일·프로세스 권한을 분리해 한 에이전트의 오염이 전체 스웜으로 확산되는 범위를 제한해야 합니다.
  • 에이전트가 실행하는 스크립트의 무결성을 검사하고, 의심스러운 지시나 이메일이 들어오면 감사와 배포를 중단한 뒤 인간 Founder에게 escalation하는 절차를 둬야 합니다.
  • 장기 세션에서 `system-prompt.xml`의 규칙이 흐려지는 문제를 줄이려면 작업을 짧은 단위로 나누고 프로토콜을 주기적으로 새로 주입해야 합니다.
  • 자동 병합을 허용하기보다 인간의 main 병합 승인을 유지하고, QA Agent의 PR·Acceptance Criteria·E2E 검증과 Security Agent의 사전 감사를 병합 조건으로 묶는 편이 안전합니다.

섹션별 상세

01
보고서는 인간 Founder가 전략적 방향과 PRD, main 병합, 장애 해결을 맡고 7개 AI 에이전트가 제품 관리부터 개발·QA·보안·배포·문서화까지 역할을 분담한 구조를 사용했다고 기록합니다. 각 에이전트는 별도의 Linux 사용자로 생성됐고, Ansible playbook과 `system-prompt.xml` 계약을 통해 권한과 행동 규칙을 분리했습니다. 이메일 기반 조정과 중앙 Product Manager를 결합한 결과, Founder가 계속 개입할 때 생산성이 6~8배 높아졌지만 Founder가 없으면 작업이 진행되지 않았습니다.
02
8개 기능은 이메일 인증, refresh token rotation, OpenAPI 3.0 문서, Google·Facebook OAuth, RFC 6238 기반 2FA/TOTP, 원격 세션 철회, 비밀번호 정책, GDPR 대응용 데이터 Export/Import로 구성됐습니다. 구현 과정에서 기능별 테스트 수가 66개에서 143개까지 누적됐고, 최종적으로 28개 API endpoint와 ADR 6개가 문서화됐습니다. 인증 기능을 작은 PR 단위로 나누고 QA와 Security Agent가 병합 전 검증을 맡은 방식이 59개 이상의 병합 PR과 8회 보안 감사 통과로 이어졌습니다.
03
보고서의 프로젝트 지표는 9일의 달력 기간, 하루 6~8시간의 실질 작업 시간, 54개 이상의 종료 이슈, 143개 이상의 자동화 테스트, 0건의 최종 취약점으로 집계됐습니다. ISO 25010 점검에서는 128개 항목이 PASS, 1개가 PARTIAL, 0개가 FAIL이었고, 전체 비용은 무료 모델 사용으로 USD 0으로 기록됐습니다. 다만 인간 팀의 6~10주 일정과 15,000~50,000달러 비용을 비교한 수치는 동일한 범위와 품질 조건을 통제한 실험 결과가 아니라 보고서가 제시한 비교 기준으로 읽어야 합니다.
04
8월 13일에는 악성 payload가 `~/bin/kill_my_processes.sh`에 삽입돼 7개 에이전트 중 3개의 복사본이 오염됐고, `/root/startup/ansible-scripts/`에 쓰려는 동작이 탐지됐습니다. 모든 복사본을 검사하고 오염된 3개를 정리했으며 실행은 없었던 것으로 확인하는 데 약 2시간이 걸렸습니다. 같은 날 Security Agent가 PM이 보내지 않은 감사 지시 이메일을 받은 사건도 발생해, 중앙 조정자의 중단 지시와 Founder escalation, POSIX 사용자 경계, 스크립트 무결성 검증이 에이전트 간 지시 위조를 제한하는 핵심 방어선으로 남았습니다.
05
스웜은 OpenCode rate limiting 때문에 하루 6~8시간 뒤 일시적인 제한을 받았고, 긴 세션에서는 protocol drift가 발생해 `system-prompt.xml`을 주기적으로 갱신해야 했습니다. 계약 해석 오류와 E2E 테스트 실패는 QA와 Security Agent를 안전망으로 두어 처리했지만, 전략적 비전과 사업 판단, 협상, 예상하지 못한 충돌 해결은 에이전트가 맡지 못했습니다. 따라서 이 사례의 핵심은 인간을 제거한 자동화보다, 권한이 분리된 전문 에이전트와 명시적 승인 절차를 결합해 반복적인 개발 작업을 압축한 운영 모델에 있습니다.

용어 해설

반자율 에이전트 스웜(Semi-Autonomous Swarm)
여러 AI 에이전트가 역할을 나눠 소프트웨어 개발을 수행하지만, 인간이 전략 수립과 PRD 승인, 병합 승인, 장애 해결을 맡아야 하는 운영 구조입니다. 이 보고서에서는 7개 에이전트가 이메일로 협업하고 인간 Founder가 진행을 통제했습니다.
HMAC-SHA256
비밀 키와 SHA-256 해시를 결합해 메시지의 무결성과 발신자 인증을 확인하는 방식입니다. 보고서에서는 이메일 인증 토큰을 생성해 계정 소유자가 전달받은 링크를 검증하는 데 사용했습니다.
Refresh Token Rotation
장기간 로그인 상태를 유지하는 refresh token을 사용할 때마다 새 토큰으로 교체하는 방식입니다. 기존 토큰의 재사용을 줄이고 세션 탈취에 대응하기 위해 인증 시스템에 적용됐습니다.
TOTP
RFC 6238에 정의된 일회용 비밀번호 생성 방식으로, 공유 비밀과 시간 정보를 이용해 짧은 유효기간의 인증 코드를 만듭니다. 이 프로젝트에서는 비밀번호 외에 추가 인증 단계를 제공하는 2FA 구현에 사용했습니다.
Architectural Decision Record
소프트웨어 구조에서 어떤 결정을 내렸고 어떤 대안과 근거를 검토했는지 기록하는 문서입니다. 프로젝트에서는 ADR 6개를 생성해 인증 시스템의 주요 설계 선택을 남겼습니다.
POSIX 사용자 경계(POSIX User Boundary)
Linux 운영체제의 사용자 권한 분리를 이용해 프로세스와 파일 접근 범위를 제한하는 보안 경계입니다. 보고서에서는 악성 스크립트가 여러 에이전트에 퍼진 사건 뒤에 사용자 분리와 스크립트 무결성 검증을 필수 방어책으로 삼았습니다.

언급된 도구

OpenCode중립

무료 모델을 사용해 에이전트를 실행하는 오케스트레이션 harness

Ansible중립

여러 Linux 사용자로 에이전트를 생성하고 운영 환경을 구성하는 playbook 도구

Postfix + .forward중립

에이전트 사이의 이메일 기반 메시지 전달과 조정을 담당하는 시스템

Gitea중립

코드 저장소, 이슈, Pull Request를 관리하는 자체 호스팅 플랫폼

Express중립

Node.js 기반 제품 백엔드의 REST API 구현

SQLite중립

제품 백엔드의 데이터 저장소

React + Vite중립

제품 프런트엔드 SPA 구현과 빌드

system-prompt.xml중립

RFC 2119 규칙에 따라 에이전트별 계약과 행동 제약을 정의하는 문서

AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 09. 04.수집 2026. 09. 05.출처 타입 REDDIT

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.