목표 주도 방식으로 몇 주 동안 계속 실행되는 멀티 에이전트 시스템 구축기

멀티 에이전트 시스템을 만드는 방법에는 흔히 볼 수 있는 잘못된 형태들이 몇 가지 있습니다. 제 생각으로는, 이러한 형태로 에이전트를 조직하더라도 정말 복잡한 태스크를 완수할 수는 없습니다. 본 기사에서는 먼저 그 이유를 설명하고, 다음에 제가 현재 채택하고 있는 방식과 이를 통해 얻은 결과를 소개합니다.

🚫 세 가지 잘못된 형태

1. 역할 주도 (Role-driven) 👔

프로그래머, 매니저, 테스터, QA를 각각 한 개씩 만들어 개발팀처럼 움직이는 형태입니다. 각 에이전트는 자신의 컨텍스트를 가지고 있습니다. 분담은 명확하게 보이지만, 역할 간의 정보는 대화로 주고받기 때문에, 전달할 때마다 조금씩 빠지거나 어긋나게 됩니다. 오래 진행하면 모두가 이야기하는 내용이 더 이상 같지 않게 됩니다.

2. 평면적으로 나열된 에이전트 무리 (Flat group of agents) 🍳

예를 들어 독립적인 컨텍스트를 가진 프로그래머를 10개 나열하는 형태입니다. 공통의 목표도 심판도 없기 때문에, 어떤 에이전트도 말만 하고 손을 움직이지 못하는 상태에 빠집니다. 즉, Overcooked(오버쿡) 상태로, 인원은 많은데 요리는 거의 나오지 않습니다 😇

3. 직렬 파이프라인 (Sequential pipeline) 🔗

A의 출력을 B에, B의 출력을 C에 전달하는 형태입니다. 문제는 어딘가 하나의 노드의 낮은 품질 출력으로 전체 컨텍스트가 쉽게 오염될 수 있다는 것입니다. 앞에서 조금 잘못되면 뒤가 전부 끌려가기 때문에, 복잡한 태스크는 좀처럼 완료할 수 없습니다.

저는 계속해서, 에이전트가 자체 반복(self-iteration)을 통해 복잡한 문제를 풀 수 있게 될 때까지는 상업적인 가치가 전혀 없다고 생각해 왔습니다. 그래서 제가 개인적으로 최선의 해결책 중 하나라고 생각하는 방식을 소개합니다.

🧮 왜 수학 문제부터 시작했나

개방된 문제에 대한 에이전트의 능력에 대해서는 신중한 입장을 취하고 있습니다. 다만, 에이전트와 본질적으로 잘 맞는 상황이 하나 있습니다. 명확하게 정의되고 검증할 수 있는 수학 문제입니다.

이러한 문제는 탐색 공간이 거대하고, 인간의 시간이나 계산 자원만으로는 부족하기 때문에, 여러 에이전트에게 병렬로 처리시키는 것이 가장 적합합니다. 게다가, 해를 찾는 것은 어렵지만, 그것을 검증하는 것은 쉽습니다. 대량의 시도는 에이전트가 담당하고, 정오 판단은 결정론적인 프로그램이 담당합니다. 이는 바로 에이전트가 가장 잘 할 수 있는 분담입니다.

🏗️ 시스템 설계

제가 설계한 시스템에서는, 인간이 하는 일은 목표와 체커(checker)를 정의하는 것뿐입니다. 무리가 목표를 태스크로 분해하고, 병렬로 움직이는 코딩 에이전트에게 할당하며, 검증하고, 머지하거나 롤백하고, 다음 라운드를 계획합니다. 체커를 통과할 때까지 자체 반복을 계속합니다 🔁

몇 주 동안 문제없이 실행하기 위해 특히 중요하다고 생각하는 설계가 몇 가지 있습니다.

🧊 목표는 동결(Frozen)된다

맨 위에 최종 목표가 있고, 그 아래에 검수 가능한 마일스톤이 있으며, 마일스톤마다 체커가 붙어 있습니다. 에이전트는 새로운 태스크를 제안할 수 있지만, 제안 파일이 통과해야 하며, 스키마와 규칙의 검사를 통과한 것만 추가됩니다. 최종 목표 자체는 변경할 수 없습니다. 오래 실행하는 데 가장 무서운 것은, 에이전트가 몰래 목표를 수정해 버리는 것입니다.

✅ 완료는 체커가 결정한다

완료 여부는 에이전트 자신이 결정하는 것이 아닙니다. 테스트가 모두 통과했고, 게다가 테스트가 최소 1건이라야만 완료로 간주합니다. 결과를 분석할 수 없는 0/0도 실패 처리입니다.

📁 파일당 담당자는 한 명

하나의 파일에는 담당자가 오직 한 명뿐입니다. 각 에이전트는 자신 전용의 git worktree에서 작업하며, 서로 간섭하지 않습니다.

🚪 머지 게이트(Merge Gate)

머지하기 전에 또 하나의 관문이 있습니다. 먼저 main에 머지하고, main 위에서 테스트와 타입 체크를 다시 실행하여, 실패하면 즉시 롤백합니다. 브랜치에서는 녹색인데 main에 넣으면 빨간색이 되는 일은 실제로 일어납니다.

📜 기록은 추가(Append)만 가능하다

기록은 모두 추가만 하고, 덮어쓰지 않습니다. 각 라운드에서 무엇을 했고 결과가 어땠는지를 전부 남기고, 다음 라운드의 계획은 그것을 읽어서 세웁니다. 프로세스가 실패해도, supervisor가 중단된 라운드를 무효화하고 재큐(re-queue)합니다. 목표를 달성하거나, 예산을 소진하거나, 2라운드 연속으로 완전히 똑같아서 진척이 없으면 스스로 멈춥니다.

🌩️ 실제로 실행해 보니

주로 무료 프레임 모델을 사용하여 2주 연속으로 구동했습니다. 도중에 호스트가 2번 재부팅되었습니다. 처음에는 제 코드의 버그를 의심했지만, 결국 머신 재부팅이 원인이라는 것을 알고 시스템은 아카이브에서 복구되었고, 데이터는 전혀 손실되지 않았습니다. 모델 엔드포인트가 다운되기도 했지만, 다른 모델로 전환하여 계속 구동했습니다.

이 2주 동안 시스템 자체의 검사 게이트가 실제 결함 16건을 발견했습니다. 때로는 에이전트가 '한 단계 더' 나아갈 방식을 찾았지만, 가짜 이름으로 제출하지 않고 그대로 삭제했습니다 🫡

🏆 성과

1. F₂ 상의 4×4 행렬 곱셈

목표는 엄격한 랭크 ≤ 47, 즉 AlphaTensor가 Nature 2022에서 발표한 수치입니다. 에이전트는 기존 결과를 전혀 참고하지 않고 제로(zero)부터 탐색하여, 13 라운드의 자율 계획을 거쳐 랭크 49라는 고전적인 결과(2단 Strassen)를 재발견했습니다. 현재도 진행 중입니다 🚀

2. Erdős–Straus 추측 대규모 검증

모든 n ≤ 10⁷에 대해 4/n = 1/x + 1/y + 1/z를 검증했습니다. 에이전트는 스스로 4세대의 솔버를 작성하여, 최종 세대는 전체 범위를 0.9초 만에 돌파합니다 ⚡

나아가, 1976년부터 멈춰 있던 3×3 행렬 곱셈의 랭크 ≤ 22 문제에도 87 라운드를 도전했습니다. 해결되지는 않았지만, 시스템은 해결되지 않았다는 것을 계속해서 보고하고 있습니다.

🗺️ 다음 단계

앞으로는 주로 두 가지에 집중할 것입니다.

• M8을 랭크 47까지 끌어올리는 것
• 더 길고 어려운 태스크에서, 목표부터 검증된 성과까지 사람의 개입 없이 도달하게 하는 것

Discussion