솔직하게 말씀드리고 싶습니다. 이 프로젝트를 시작했을 때, 저는 이것이 실제로 작동할 것이라고 믿지 않았습니다.

겸손하게 말하는 것이 아닙니다. 무료 API 티어와 노트북 한 대만으로 한 사람이 해내기에는 이 아이디어가 너무 야심 차다고 진심으로 생각했습니다. GitHub Issue를 읽고, 코드베이스를 이해하며, 작동하는 코드를 작성하고, 테스트를 실행하고, 다른 AI로부터 코드 리뷰를 받은 뒤, Pull Request를 여는 완전 자율형 AI 말입니다. 인간의 개입(Human in the loop)은 없습니다. 어떤 단계에서도 승인을 위해 클릭할 필요가 없습니다.

하지만 작동합니다. 그리고 처음으로 전체 프로세스가 실제로 완료되었을 때, 저는 GitHub에 올라온 Pull Request를 꼬박 1분 동안 멍하니 바라보았습니다.

시작이 된 순간

새벽 1시에 버그 티켓을 검토하고 있었습니다. 아주 간단한 수정이었습니다. 부끄러울 정도로 간단했죠. 함수 이름을 바꾸고, 테스트 두 개를 업데이트하는 것 말입니다. 실제 작업은 15분이었지만, 적절한 파일을 찾고, 테스트가 어디에 있는지 기억해 내고, PR 설명을 작성하는 등의 컨텍스트 스위칭(Context switching)에 40분이 걸렸습니다.

그리고 저는 생각했습니다. '만약 내가 그 과정을 전혀 할 필요가 없다면 어떨까?'

'만약 AI가 내가 더 빨리 타이핑하도록 도와준다면'이 아닙니다. '내가 평범한 영어로 문제를 설명하고 그냥 자리를 떠나버린다면 어떨까' 하는 것이었습니다.

내가 만든 것

네 명의 에이전트. 각각 특정한 역할을 맡고 있습니다.

**Architect (설계자)**는 저장소(Repo)를 읽고, 가장 관련 있는 파일들을 열어 코드베이스 구조를 이해한 뒤, 구체적인 구현 계획을 생성합니다. 이 계획을 GitHub Issue에 댓글로 게시하여 사용자가 그 사고 과정을 볼 수 있게 합니다.

**Coder (개발자)**는 새로운 클라우드 샌드박스(Sandbox)를 실행하고, 저장소를 클론(Clone)하며, Architect의 계획에 따라 코드를 작성하고, 린터(Linter)를 실행하고, 커밋(Commit)한 뒤 테스트 스위트(Test suite)를 실행합니다. 테스트가 실패하면 에러를 읽고, 수정하고, 다시 시도합니다. 총 세 번의 시도가 주어집니다.

**Reviewer (리뷰어)**는 git diff를 한 줄씩 읽습니다. 하드코딩된 비밀 정보(Secrets), SQL 인젝션(SQL injection) 위험, 누락된 입력 검증(Input validation), 잘못된 에러 처리(Error handling) 등을 확인합니다. 승인(APPROVED)을 반환하거나 구체적인 이유와 함께 다시 돌려보냅니다.

**PR Agent (PR 에이전트)**는 무엇이 왜 변경되었는지, 그리고 테스트 결과가 어떠했는지에 대한 전체 설명을 포함하여 초안 Pull Request를 생성합니다.

단순한 기능 요청(feature request)에 대해 이 모든 과정이 약 4분 만에 실행됩니다.

단순히 GPT를 호출하는 것과 무엇이 다른가

많은 "자율형 AI (autonomous AI)" 데모들은 하나의 에이전트가 무언가 작동할 때까지 루프를 돌며 몇 가지 도구(tools)를 호출하는 방식입니다. 이 방식은 중요한 측면에서 다릅니다.

에이전트들은 완전히 분리된 역할과 분리된 도구를 가지며, 서로의 내부 추론(internal reasoning)을 볼 수 없습니다. Architect는 Coder가 무엇을 생각하는지 알지 못합니다. Reviewer는 Architect가 무엇을 계획했는지 알지 못합니다. 각 에이전트는 자신에게 필요한 정보만 전달받습니다.

에이전트들 사이에서 경로를 지정하는 Supervisor(관리자)는 순수 Python의 if/else 로직으로 구성됩니다. 다음에 무엇을 할지 결정하는 LLM은 없습니다. 이는 의도적인 선택이었습니다. 제어 흐름(control flow)이 환각(hallucination)을 통해 무한 루프에 빠지는 것이 아니라, 예측 가능하기를 원했습니다.

코드는 실제로 실행됩니다. 이 부분은 사람들이 과소평가하는 지점입니다. 이는 시뮬레이션이 아닙니다. Coder는 실제 git, 실제 컴파일러, 실제 테스트 러너(test runners)가 포함된 실제 Ubuntu 샌드박스(sandbox)를 가집니다. 테스트를 실행할 때, 그것은 실제 테스트 결과입니다. 테스트가 실패하면, 그것은 실제 실패입니다. 에이전트는 실제 에러 출력(error output)을 읽고 이를 실제로 수정해야 합니다.

내가 사용한 스택

이 모든 것은 무료 티어(free tiers)에서 작동합니다.

Groq는 Llama 3.1에 대해 하루 500,000개의 토큰을 제공합니다. 이는 비용을 전혀 지불하지 않고도 하루에 여러 번 스웜(swarm)을 실행하기에 충분한 양입니다. E2B는 몇 초 만에 생성되어 임의의 코드를 안전하게 실행할 수 있는 클라우드 샌드박스를 제공합니다. LangGraph는 에이전트 그래프(agent graph)를 처리합니다. FastAPI는 백엔드를 서빙합니다. Next.js는 WebSocket을 통해 브라우저로 에이전트의 실시간 로그를 스트리밍하여, 에이전트가 하는 모든 생각을 실시간으로 지켜볼 수 있게 합니다.

전체 시스템은 명령어 하나로 배포됩니다.

아무도 말하지 않는 부분

블로그 포스트에서는 자율형 에이전트를 구축하는 것이 깔끔하게 들립니다. 하지만 현실은 이 정도 규모의 AI 모델들이 정말로 이상한 행동을 한다는 것입니다.

모델이 존재하지 않는 도구를 호출하려고 시도했습니다. 무려 11번 연속으로 말이죠. 시스템 프롬프트(system prompt)에서 호출하라고 명령해놓고, 정작 도구를 실제로 추가하는 것을 잊어버렸기 때문입니다.

도구(tool) 결과가 추가될 때마다 메시지 기록(message history)이 늘어났기 때문에, 12,000 토큰 제한에서 13,000 토큰 요청이 발생했습니다.

에이전트가 클라우드 샌드박스(cloud sandbox)를 사용하려고 시도했을 때 아직 부팅 중이었기 때문에, 첫 번째 git clone은 항상 실패했습니다.

탐지 로직(detection logic)에 Java 브랜치가 없었고, 모델이 Python 파일이 하나도 없는 코드베이스에서 pytest를 계속 재시도했기 때문에, Java 프로젝트에서 테스트 러너(test runner)가 무한 루프를 돌았습니다.

이것들은 이론적인 예외 사례(edge cases)가 아닙니다. 이 모든 일들이 첫 번째 실제 테스트 실행 중에 발생했습니다. 스웜(swarm)이 깨끗하게 실행될 때까지 이 문제들을 하나씩 해결하는 과정이 실제로 가장 많은 시간이 걸렸습니다.

제대로 작동할 때의 느낌

저는 예전에 만든 JavaFX Brick Breaker 게임에 최고 점수 추적기(high score tracker)를 요청하는 GitHub 이슈(issue)를 생성했습니다. 설명을 입력하고 제출 버튼을 누른 뒤, 브라우저에서 로그를 지켜보았습니다.

Architect는 BrickBreak.java를 열어 800줄의 게임 코드를 읽고 점수 계산 방식이 어떻게 작동하는지 이해한 뒤, GitHub 이슈에 계획을 게시했습니다. Coder는 ScoreManager.java를 처음부터 새로 만들고, 이를 게임에 연결했으며, 두 파일을 컴파일하고, 올바르게 연결되었는지 확인했습니다. Reviewer는 차이점(diff)을 확인하고 승인했습니다. GitHub에는 무엇이 왜 수행되었는지 정확히 설명하는 설명이 포함된 풀 리퀘스트(pull request)가 나타났습니다.

저는 그중 단 한 줄도 직접 작성하지 않았습니다.

기계가 당신의 코드를 이해하고 올바르게 확장하는 것을 지켜보는 것은 정말 기묘한 경험입니다. 이것은 자동 완성(autocomplete)처럼 느껴지지 않습니다. 무언가 선을 넘었다는 느낌이 듭니다.

이것의 실체

이것은 개인 프로젝트입니다. 제품도 아니고, 스타트업도 아니며, 가동 시간 SLA(uptime SLA)가 있는 것도 아닙니다. 저는 할 수 있는지 확인하기 위해, 그리고 멀티 에이전트 시스템(multi-agent systems)에 대해 읽기만 하는 대신 내부적으로 실제로 어떻게 작동하는지 이해하기 위해 이것을 만들었습니다.

이것은 프로덕션 준비(production ready)가 된 상태가 아닙니다. 에이전트들은 여전히 복잡한 코드베이스에서 실수를 저지릅니다. Architect는 때때로 프로젝트 구조를 잘못 읽습니다. Coder는 가끔 컴파일은 되지만 의도를 놓치는 코드를 작성합니다. 그것은 괜찮습니다. 목적은 결코 완벽한 시스템을 만드는 것이 아니었기 때문입니다.

핵심은 실질적인 무언가를 구축하고, 실제 문제에 부딪히며, 작동할 때까지 하나씩 해결해 나가는 것이었습니다. 그리고 그것은 작동합니다.

저는 이 프로젝트 하나를 통해 LLM 컨텍스트 관리 (context management), 토큰 예산 (token budgets), 결정론적 라우팅 (deterministic routing) 대 LLM 기반 라우팅 (LLM-driven routing), 그리고 샌드박스 실행 환경 (sandbox execution environments)에 대해 제가 구축했던 그 어떤 것보다 더 많은 것을 배웠습니다. 그것이 진정한 가치입니다.

이것은 오픈 소스입니다

코드를 깊이 파헤쳐 보거나, 로컬에서 실행해 보거나, 여러분만의 에이전트 프로젝트를 위한 아이디어를 얻고 싶다면:

github.com/Sowaiba-01/devops-swarm

세 가지 무료 API 키가 필요합니다: Groq, GitHub, 그리고 E2B입니다. 나머지는 Docker Compose가 처리합니다. 브라우저에서 실시간으로 흐르는 로그 스트림을 지켜보는 것은 정말 즐거운 경험입니다.