이 문서는 Super-agent(슈퍼 에이전트)라는 새로운 에이전트 시스템 아키텍처를 제안하고, 기존 에이전트 시스템의 한계를 극복하며 인간의 개입 없이도 지속적으로 작동하는 자율적인 시스템을 만드는 방법을 설명합니다. 특히, 2단계 아키텍처, 이벤트 기반 설계, 비동기 다중 채널 상호작용, 컴퓨트-스토리지 분리, 외부 Watchdog(감시자) 개념을 통해 에이전트가 여러 작업을 동시에 처리하고 환경 변화에 능동적으로 반응하며, 지속적으로 온라인 상태를 유지하는 방안을 제시합니다. 이로써 인간은 저수준의 실행보다는 고수준의 의사 결정과 승인에 집중할 수 있게 됩니다.

1. 현재 에이전트 시스템의 한계

최근 코딩 에이전트와 같은 단일 작업 에이전트들이 모델이 도구를 사용하여 복잡한 문제를 해결하는 능력을 보여주면서, 인간의 지속적인 모니터링과 단계별 개입의 필요성이 점점 줄어들고 있어요. 또한, 모델들이 여러 에이전트를 조율하는 능력이 향상되어 여러 세션에 걸쳐 작업을 조직하고 스케줄링하는 것이 현실적으로 가능해졌죠. 사람들의 역할이 저수준 실행에서 고수준 의사 결정과 승인으로 점차 옮겨가고 있는 추세입니다. 🚀

"사람들의 역할이 저수준 실행에서 고수준 의사 결정과 승인으로 점차 옮겨가고 있습니다."

하지만 현재 주류를 이루는 에이전트 디자인은 여러 작업이나 팀 전체에 걸쳐 이러한 작업 방식을 지원하는 데 어려움을 겪고 있어요. 여전히 단일 세션을 기본적인 작업 단위로 사용하고 있으며, 세션 간에는 고립성이 존재합니다. 사용자가 여러 작업을 동시에 실행할 때, 각 세션을 수동으로 전환하고 내용도 일일이 기억해야 하는 불편함이 있어요. 경험상 한 사람이 동시에 추적할 수 있는 활성 세션은 보통 3~5개 정도라고 해요. 즉, 단일 작업은 모델 능력에 따라 제한되지만, 다중 작업은 인간의 주의력에 의해 제한되는 상황인 거죠. 🤯

기존의 로컬 단일 세션 에이전트에 CLI(명령줄 인터페이스)나 외부 커넥터를 추가하여 외부 메시지를 받을 수 있게 해도 기본적인 한계는 여전합니다. 이러한 에이전트는 여전히 단일 동기 세션으로 실행되어 긴 작업에서 블록되고, 다른 작업의 컨텍스트가 뒤섞이며, 로컬 장치가 오프라인이 되면 모든 것이 중단됩니다. 이런 시스템을 유지하려면 많은 수동적인 노력이 필요해요.

2. Super-agent의 개념 및 특징

이러한 한계를 극복하려면 에이전트를 수동으로 제어되는 단일 세션으로부터 분리해야 합니다. 대신, 에이전트는 세션 간에 컨텍스트를 유지하고 여러 복잡한 작업을 동시에 처리하며, 작업들이 서로 간섭하지 않는 지속적인 개체여야 해요. 우리는 이러한 에이전트와 그 시스템 아키텍처를 Super-agent라고 부릅니다. ✨

예를 들어, DeepSeek Harness에서 실행되는 저희 내부 Super-agent 인스턴스는 IM(인스턴트 메시징)과 GitHub를 통해 동일한 개발 작업을 계속 이어갈 수 있습니다. 또한, 공개 그룹 채팅에서 피드백을 모니터링하고, 아무도 자신을 멘션하지 않아도 스스로 근본 원인을 찾아내서 이를 수정하기 위한 Pull Request를 열기도 해요. 정말 신기하죠? 😮

"저희 내부 Super-agent 인스턴스는 IM과 GitHub를 통해 동일한 개발 작업을 계속 이어갈 수 있습니다." "아무도 자신을 멘션하지 않아도 스스로 근본 원인을 찾아내서 이를 수정하기 위한 Pull Request를 열기도 합니다."

IM 그룹 채팅과 GitHub Pull Request 검토 전반에서 동일한 작업이 계속됩니다.

에이전트가 공개 그룹 채팅을 모니터링하고, 멘션 없이도 버그를 찾아 수정하기 위한 Pull Request를 엽니다.

저희는 Super-agent가 다음 네 가지 기본적인 특징을 가지고 있다고 생각합니다:

• 지속성 (Continuous): 사용자는 IM 채팅이나 GitHub 댓글과 같이 이미 작업하는 곳에서 에이전트와 직접 상호작용할 수 있으며, 항상 하나의 에이전트처럼 느껴집니다. 세션 X에 정보 Y가 있는지 고민할 필요가 없어요. 예를 들어, 사용자가 IM에서 플랜 A를 요청하고 나중에 GitHub Pull Request 댓글에서 플랜 B로 전환하면, 에이전트는 변경 사항을 이해하고 작업을 조정합니다.
• 생산성 (Productive): 빠르게 응답하고, 여러 복잡한 작업을 동시에 높은 수준으로 완료합니다. 이전 명령이나 작업이 끝나기 전에 다음 지시를 받을 수 있어요.
• 능동성 (Proactive): 단계별 지시를 기다리지 않습니다. 환경의 이벤트를 모니터링하고, 처리할 가치가 있는 모든 것에 대해 행동하며, 그렇지 않으면 조용히 있습니다.
• 영구성 (Persistent): 항상 온라인 상태를 유지하며, 사용자의 실제 작업 환경에 직접 연결되고, 장기 운영 중 발생하는 이상 현상에서 자동으로 복구됩니다.

하나의 ReAct(사고 및 행동) 루프만으로는 이 네 가지 특징을 모두 제공할 수 없기 때문에, 이러한 특징들은 시스템 아키텍처에서 비롯되어야 합니다. 유사한 설계 제약 조건은 유사한 아키텍처를 만들어내는 경향이 있어요. 항상 온라인 상태를 유지하고 환경 이벤트에 동시적으로 반응하는 시스템이 목표일 때, 개인 에이전트와 소프트웨어 개발과 같은 상업적 작업용 에이전트는 유사한 디자인으로 귀결될 것으로 예상합니다. 이러한 시스템을 구축하는 것은 컴퓨터 시스템 분야에서 오랫동안 연구된 많은 문제와 유사하며, 따라서 해당 분야의 많은 고전적인 설계 아이디어도 여기에 적용될 수 있어요.

구현 방식은 다양하겠지만, 저희는 이 네 가지 특징을 지원하는 기본 프레임워크를 다섯 가지 모듈로 구성한다고 생각합니다.

Super-agent의 전체 아키텍처

• 2단계 아키텍처 (Section 2): 지속적인 상호작용과 생산적인 동시성을 모두 제공합니다.
• 이벤트 기반 설계 (Section 3): 에이전트를 능동적으로 만듭니다.
• 전이중 다중 채널 상호작용 (Section 4): 사용자와의 각 상호작용을 지속적이고 생산적으로 유지합니다.
• 컴퓨트, 상태, 환경 분리 (Section 5): 에이전트를 장치 전반에 걸쳐 영구적으로 온라인 상태로 유지합니다.
• Watchdog (감시자) (Section 6): 이상 현상으로부터 자동으로 복구되도록 돕습니다.

3. 2단계 아키텍처: 라우터 및 워커 계층

채널 전반의 지속적인 상호작용과 작업 전반의 생산적인 동시성을 모두 지원하려면 시스템이 세션을 조직하는 방식에서 연속성과 처리량 사이의 근본적인 절충점이 필요합니다.

모든 이벤트를 하나의 세션으로 라우팅하면 해당 세션이 모든 것을 보기 때문에 가장 연속적인 컨텍스트를 제공해요. 하지만 ReAct 루프는 한 번에 한 단계씩 실행되므로, 단일 세션이 작업할 수 있는 속도에 한계가 있어서 작업 시간이 길어지고 처리량이 낮아집니다. 또한, 다른 작업의 중간 세부 정보가 하나의 컨텍스트에 섞여 결과의 품질을 저하시킬 수 있어요. 😥

모든 이벤트에 대해 새로운 세션을 부여하는 것은 이 절충점을 반대로 뒤집는 방식입니다. 이는 동시 처리량을 극대화하지만, 작업이 완전히 독립적이지 않을 때 공유 전역 컨텍스트가 부족하여 결과가 단절될 수 있어요. 여러 세션이 사용자에게 개별적으로 응답하면 상호작용이 혼란스러워지기도 합니다.

지속성과 처리량을 모두 얻기 위해, 우리는 작업을 두 개의 계층으로 나눌 수 있습니다. 장기 실행 라우터 계층 (Router layer)은 모든 인간 상호작용과 전역 조정을 처리하여 전역 연속성을 유지하고, 컨텍스트가 격리된 워커 계층 (Worker layer)은 높은 동시성으로 작업을 실행합니다.

두 단계 아키텍처: 라우터 계층은 모든 라우팅과 외부 상호작용을 처리하고, 여러 격리된 워커 세션은 작업을 동시에 실행합니다.

이 2단계 아키텍처를 사용하면 시스템이 컨텍스트 관리와 동시 실행을 담당하므로, 사용자는 세션에 대해 거의 생각할 필요 없이 항상 동일한 Super-agent와 작업할 수 있습니다. 사용자가 세션을 직접 관리하게 하는 것은 주로 저수준 LLM API에서 가져온 디자인 습관일 뿐이에요. 세션은 시스템의 구현 세부 사항이어야 하며, 사용자에게 정신적인 부담을 주어서는 안 됩니다. 👍

기존 디자인에서는 세션이 두 가지 역할을 수행했어요. 모델의 컨텍스트를 관리하고, 사용자의 프로젝트 관리 단위가 되는 것이죠. 제품이 기본 세션으로부터 분리되면, 프로젝트 관리는 더 이상 세션 경계를 따를 필요가 없습니다. 사용자에게 어떤 상호작용 및 작업 관리를 제공할지는 별개의 제품 질문이 되는데, 이는 나중에 다시 다룰게요.

이 두 단계는 책임의 논리적 구분일 뿐이며, 각 계층이 단일 세션으로 구현될 필요는 없으며, 각기 자체적인 내부 구조를 가질 수 있습니다. 다음 두 섹션에서 이 두 계층을 차례로 설명합니다.

3.1. 라우터 계층 (Router Layer)

라우터 계층은 모든 진입점에서 인간 상호작용을 받는 장기 실행 전역 라우팅 계층입니다. 모든 교차 작업 정보와 결정이 이곳에서 모이므로, 시스템의 전역 시퀀스 지점, 조정 지점, 메모리 역할을 합니다. 이 단일 전역 노드가 성능 병목이 되는 것을 막기 위해, 라우터 계층은 자체적으로 작업을 실행하도록 설계되지 않았어요. 오직 인간과 상호작용하고 작업을 디스패치하며, Bash 도구 없이도 실행될 수 있습니다.

하나의 중앙 노드가 여러 실행 노드에 작업을 디스패치하는 이 구조는 일반적인 에이전트 팀과 비슷해 보이지만, 둘은 초점이 다릅니다. 에이전트 팀은 보통 하나의 복잡한 작업을 단계별로 나누고, 이를 담당하는 역할을 조정합니다. 이러한 단계들이 밀접하게 연결되어 있기 때문에, 팀 리더는 종종 작업의 깊은 이해를 바탕으로 하위 작업을 계획하고 구성원들을 자주 조정해야 하며, 이는 많은 추론 부담으로 이어집니다. Super-agent에서 라우터 계층은 단순히 작업을 디스패치하고 고수준에서 작업 간의 관계를 추적할 뿐입니다. 개별 작업을 세분화하지는 않아요.

반대로, 에이전트 팀도 2단계 아키텍처로 작동할 수 있습니다. 이를 위해서는 프롬프트가 메인 세션이 자체적으로 작업을 실행하는 것을 막고, 외부 상호작용 및 개별 작업을 독립적으로 처리하는 구성원들에게 디스패치하는 것으로 제한해야 합니다. 저희 경험상, 라우터 계층의 작업은 예상보다 간단하며, 더 가벼운 모델로도 속도와 품질을 모두 제공할 수 있습니다.

내부적으로 라우터 계층도 단일 세션일 필요는 없으며, 일부 로직은 LLM이 전혀 필요하지 않을 수도 있습니다. 저희는 가장 직접적인 디자인인 단일 장기 실행 LLM 세션을 선택했고, 이것이 생각보다 처리량 병목이 될 가능성이 적다는 것을 발견했어요. 그 이유는 환경 이벤트(섹션 3의 트리거)가 한 추론 턴 동안 도착하면 대기열에 쌓여 다음 턴에서 함께 처리되기 때문입니다. 즉, 배치 처리가 이루어지는 것이죠. 이벤트를 함께 처리하는 것은 오버헤드를 거의 추가하지 않습니다.

• 외부 이벤트가 꾸준한 속도로 도착할 때, 트리거는 라우터 세션에 하나씩 도달하고 각 응답은 빠르게 돌아옵니다.

• 이벤트가 한꺼번에 도착하여 라우터 세션에서 대기열에 쌓일 때, 이전 턴 동안 축적된 트리거는 자동으로 병합되어 다음 LLM 호출에 함께 주입됩니다. 라우터 세션은 경량 상호작용 및 디스패치만 수행하므로, 각 단계는 일반적으로 긴 입력과 짧은 출력을 가집니다. 하나의 LLM API 호출로 병합된 트리거는 Prefill(사전 채우기) 동안 병렬로 계산되므로, 요청당 시간은 배치 크기보다 훨씬 느리게 증가합니다. 따라서 특정 지점까지는 백로그가 클수록 결정당 상각된 추론 시간이 낮아집니다. 이 한계는 컨텍스트 길이와 모델이 한 턴에 정확하게 처리할 수 있는 트리거 수에 따라 달라집니다.

  7.2절에서 배치 처리 효과를 정량화한 실험을 다루고 있습니다. 구독 및 통과(섹션 3.2)와 기억의 사슬(섹션 3.3)과 결합된 단일 장기 실행 라우터 세션은 컨텍스트를 지속적으로 유지하며, 현재 저희 팀 규모에는 이미 충분합니다.

시스템이 하나의 세션으로 감당하기 어려울 정도로 성장한다면, 라우터 계층은 내부적으로 다단계 필터링 구조를 사용하거나, 수평 샤딩을 통해 여러 세션으로 분할될 수 있습니다. 이때 내부 디자인은 지속성과 처리량 사이의 동일한 절충점으로 귀결됩니다. 샤딩이 세분화될수록 라우터 계층의 동시 처리량은 증가하지만, 샤드 간에 공유되는 메모리 및 컨텍스트는 줄어들게 됩니다. 이 절충점은 전역 메모리 문제가 해결될 때까지 계속될 것입니다.

3.2. 워커 계층 (Worker Layer)

워커 계층은 작업을 실행하는 세션으로 구성됩니다. 각 워커는 격리된 컨텍스트와 모든 실행 도구를 가지고 있으며, 단일 작업에 전념합니다. 워커 세션은 각 작업의 결과와 코드의 품질을 직접 결정하므로, 일반적으로 가장 유능한 모델이 필요합니다.

워커는 인간과 직접 상호작용하지 않습니다. 그들의 추론 과정과 도구 호출은 외부 채널에서 벗어나 있어요. 대신, 각 워커는 라우터 계층에 자신의 상태를 보고하며, 라우터 계층이 사용자에게 모든 응답을 처리합니다. 이러한 방식으로 시스템은 여러 세션이 개별적으로 응답하는 혼란 없이, 동시성과 출력 품질을 모두 유지할 수 있습니다.

작업이 동시에 실행될 때, 각 워커는 자체 작업을 수행하며, 동료 워커들은 보통 직접 통신할 필요가 없습니다. 워커 간의 충돌은 동일한 Pull Request와 같은 공유 작업 환경에서 발생하는 경향이 있습니다. 관련된 워커들이 모두 해당 환경의 스레드를 구독하는 한, 그들은 동일한 이벤트 알림(섹션 3.2)을 받고 스스로 충돌을 감지하고 해결할 기회를 가집니다. 라우터 계층은 작업 간 조정이 필요한 몇 안 되는 경우를 중계합니다.

라우터 계층과 마찬가지로, 워커도 내부적으로 단일 세션일 필요는 없습니다. 복잡한 작업을 위해 워커는 하위 에이전트를 생성하거나, 그 자체가 에이전트 팀이 될 수 있으며, 이는 상위 라우터 계층에는 투명합니다. 동일한 구조가 코드 협업에도 적용됩니다. 예를 들어, 문제 재현, Pull Request 검토, 기능 개발과 같은 독립적인 작업들이 서로를 방해하지 않고 동시에 진행될 수 있습니다. 개인 에이전트 시나리오에도 적합하며, 비록 개인 에이전트가 보통 단일 채팅 페이지만 제공하더라도, 사용자가 해당 채팅에서 여러 주제를 동시에 논의할 때, 페이지는 대화를 지속적으로 유지합니다. 그동안 백엔드는 각 주제에 대해 별도의 워커를 디스패치하여 작업을 수행하고 답변을 병렬로 작성할 수 있습니다.

4. 이벤트 기반 설계: 능동적인 에이전트 구현

Super-agent를 능동적으로 만들려면 먼저 시스템을 구동하는 방식을 변경해야 합니다. 에이전트의 주요 입력은 더 이상 인간이 세션에 하나씩 입력하는 프롬프트가 아니라, 환경에서 발생하는 반정형화된 이벤트입니다. Super-agent에서는 그룹 채팅 메시지, 이메일, 캘린더 알림, 코드 검토 댓글, CI(지속적 통합) 결과와 같은 이러한 환경 이벤트를 트리거(Triggers)라고 부릅니다. 에이전트는 트리거를 듣고 응답하기 때문에, 단일 세션 에이전트처럼 각 실행 전에 인간의 명령을 기다릴 필요가 없습니다. 🙌

아래 하위 섹션에서는 환경 이벤트가 도착해서 처리되는 과정을 네 단계로 나누어 설명합니다.

4.1. 두 단계 필터링: 노이즈 제거

실제 그룹 채팅이나 코드 플랫폼에 연결되면, 시스템은 낮은 트리거 비율의 시끄러운 이벤트 스트림을 보게 됩니다. 일상적인 메시지의 대부분은 에이전트의 조치가 필요 없어요. 대규모 모델이 모든 이벤트를 처음부터 판단하게 하면 너무 많은 지연이 발생하고 컴퓨팅 자원을 너무 많이 사용하게 될 겁니다. 😥 컴퓨터 시스템의 Fast Path / Slow Path 아이디어를 빌려와, 우리는 대규모 모델 추론을 유연하지만 값비싼 Slow Path로 취급합니다. 빈번하고 잘 정의되고 안정적인 판단은 대신 결정론적 코드가 되어 저지연, 저비용의 Fast Path 역할을 할 수 있습니다.

따라서 시스템은 모든 들어오는 이벤트를 먼저 필터링합니다. 결정론적 정책은 대규모 모델이 호출되기 전에 노이즈를 제거하며, 의미론적 이해가 필요한 후보 이벤트만 모델로 전송됩니다. 우리는 프로그래밍 정책과 대규모 모델을 결합한 2단계 필터링을 사용합니다.

• 프로그래밍 정책 (Fast Path): 코드에서 이벤트 소스, 그룹, 사용자 또는 봇 허용 목록과 같은 결정론적 조건에 대해 빠른 승인 검사를 실행합니다. 예를 들어, 각 소스는 "명시적 요청에만 응답", "후보 이벤트로 취급", 또는 "무시"로 설정할 수 있어요. 이러한 검사는 모델이 호출되기 전에 대부분의 관련 없는 메시지를 걸러냅니다.
• 의미론적 정책 (Slow Path): 프로그래밍 검사를 통과한 후보 이벤트는 LLM으로 전달되어, 컨텍스트와 프롬프트로 작성된 정책을 기반으로 행동 여부를 결정합니다. 의미론적 단계는 자연어 확장 지점 역할도 하므로, 인간은 프롬프트를 통해 언제든지 정책을 켜거나 끄거나 새로운 정책을 추가할 수 있습니다.

2단계 필터링: 프로그래밍 정책이 먼저 대부분의 관련 없는 메시지를 걸러내고, 의미론적 정책이 나머지를 판단합니다.

4.2. 구독 및 통과 (Subscription and Pass-through)

섹션 2의 전역 라우터 계층은 채널 전반의 상호작용을 지속적으로 유지합니다. 하지만 할당된 작업에 대한 모든 후속 이벤트가 라우터 계층을 거쳐야 한다면, 이 단일 전역 노드가 과도한 부하를 겪고 응답 속도를 늦출 수 있습니다. 따라서 Fast / Slow Path 분리는 필터링된 이벤트 라우팅에도 적용됩니다. 라우터 계층은 새 작업의 콜드 스타트와 작업 간 조정만 처리하며, 코드는 후속 이벤트를 해당 이벤트를 소유하는 워커 세션으로 직접 전달합니다.

실제 워크플로우에서 동일한 GitHub Pull Request, IM 주제 또는 이메일 체인에 대한 연속적인 이벤트는 스레드(Thread)라는 이벤트 스트림을 형성합니다.

스레드 예시: 동일한 IM 주제 또는 GitHub Pull Request 아래의 연속적인 트리거가 스레드를 형성합니다.

라우터 계층이 스레드의 첫 번째 이벤트에 대해 워커 세션을 생성하면, 해당 워커는 스레드를 직접 구독합니다. 그 이후부터는 이벤트 라우팅이 아래 두 가지 경로 중 하나를 따릅니다.

• 구독됨 (Subscribed, Fast Path): 코드는 스레드의 후속 이벤트를 구독된 워커에게 직접 전달하므로, 라우터 계층은 더 이상 전달을 위해 다른 도구 호출이 필요 없습니다. 새 이벤트가 현재 작업을 벗어나면, 워커는 구독을 해지하거나 이벤트를 라우터 계층으로 다시 전달하여 다시 디스패치될 수 있도록 합니다.
• 미구독됨 (Unsubscribed, Slow Path): 라우터 계층은 여전히 모든 이벤트를 볼 수 있으므로 전역 상태를 추적할 수 있지만, 아직 구독자가 없는 새 이벤트만 평가하고 디스패치합니다.

구독 및 통과: 초기 이벤트는 라우터 계층을 통해 구독된 워커를 생성하고, 동일한 스레드의 후속 이벤트는 해당 워커로 직접 전달됩니다.

스레드와 워커 간의 구독은 다대다(many-to-many)입니다. 한 워커는 여러 관련 스레드를 구독할 수 있으며, 한 스레드는 여러 구독된 워커를 가질 수 있습니다. 워커들이 동일한 작업 환경이나 토론에서 겹칠 때, 공유 스레드의 각 새 이벤트는 모든 구독자에게 동시에 직접 전달됩니다. 그러면 워커들은 다른 워커들이 무엇을 하고 있는지 알게 되고, 직접적인 통신 없이도 스스로 충돌을 해결할 기회를 가집니다. 출력 측면에서 워커들은 여전히 주요 결론을 라우터 계층에 보고하며, 라우터 계층이 사용자에게 모든 응답을 처리하고 전역 메모리를 동기화합니다.

4.3. 인라인 및 유출, 기억의 사슬 (Inline & Spill and Chain of Recall)

이벤트가 필터링되어 대상 세션으로 라우팅된 후, 다음 질문은 모델의 컨텍스트 창에 얼마나 많은 정보를 넣을 것인가입니다. 입력은 더 이상 제한된 수의 인간 프롬프트가 아니라, 환경이 지속적으로 생성하는 반정형화된 이벤트이므로, 도구 호출과 이벤트 주입 설계가 더욱 중요해집니다. 너무 많이 주입하면 창이 가득 차서 모델의 주의를 분산시킵니다. 너무 적게 주입하면 모델이 컨텍스트를 읽기 위해 계속해서 도구를 호출해야 하여 실행 단계가 추가됩니다. 컨텍스트 창을 낭비하는 것은 모델의 지능을 낭비하는 것과 같아요. 😥

따라서 우리는 제한된 컨텍스트 창을 캐시(cache)로 취급할 수 있습니다. 컴파일러 최적화 및 컴퓨터 시스템에서 빌려온 용어를 사용하면, 컨텍스트 주입은 두 가지 기본 작업으로 귀결됩니다.

• 인라인 (Inline): 곧 필요할 가능성이 있는 정보를 현재 컨텍스트 창에 직접 넣어 추가적인 도구 호출 왕복을 줄입니다.
• 유출 (Spill): 예산을 초과하거나 거의 사용되지 않는 정보는 창 외부로 전체 정보를 보관하고, 창에는 참조 또는 요약만 남겨두어 모델이 필요할 때 전체 정보를 온디맨드로 읽을 수 있도록 합니다.

컴퓨터 시스템 설계의 고전적인 아이디어인 지역성(locality)과 결합하면, 인라인 및 유출(Inline & Spill)은 이벤트 주입과 도구 호출을 단계별로 개선할 수 있습니다.

1. 최소 정보로 시작: 처음에는 모델에 현재 객체의 ID와 내용의 요약만 제공합니다.
2. 지역성을 통해 관련 정보 점진적으로 인라인: 모델이 곧 필요할 가능성이 있는 것을 인라인합니다. 밀접하게 관련된 객체의 ID로 시작한 다음, 공간적으로나 시간적으로 인접한 내용을 추가합니다. 예를 들어, 내용의 처음 50자, 메시지 주변의 IM 메시지와 해당 메시지가 답장하는 메시지, 동일한 코드 검토 토론의 인접 댓글 등이 있습니다.
3. 한도 초과 시 내용 유출: 전체를 인라인할 수 없는 긴 내용에는 작은 길이 제한을 설정하고, 초과되는 내용은 창 외부로 유출합니다. 이를 위한 간단한 방법은 내용을 잘라내고, 모델이 필요할 때 나머지를 읽기 위해 도구를 호출할 수 있도록 내용이 계속되는 위치에 포인터를 남겨두는 것입니다.

라우터 계층 자체도 컨텍스트 문제를 가지고 있습니다. 많은 후속 이벤트가 워커에게 직접 전달되고, 과거 작업이 장기 실행되면서 쌓이므로, 라우터 계층은 모든 작업의 전체 기록을 컨텍스트 창에 보관할 수 없습니다. 그러나 사용자가 다른 채널에서 오래된 작업을 언급하면, 라우터 계층은 해당 작업의 컨텍스트를 복구해야 합니다. 시스템의 모든 종류의 객체에 인라인 및 유출을 일관되게 적용하면, 온디맨드, 다단계 검색 메커니즘인 기억의 사슬 (Chain of Recall)이 제공됩니다. 이는 라우터 계층이 장기 실행 동안 잃는 이전 정보의 양을 줄여줍니다.

기억의 사슬: 각 호출된 객체는 다음 단계 객체의 ID를 인라인하여, 컨텍스트가 참조를 따라 단계별로 확장될 수 있도록 합니다.

시스템은 트리거, 스레드, 워커 세션과 같은 객체에 고유 ID를 부여하고, 객체를 주입할 때 밀접하게 관련된 객체의 ID를 인라인합니다. 이 ID들은 객체들을 참조 그래프로 연결합니다. 도구 호출을 통해 호출된 각 객체도 인라인 및 유출을 따르므로, 반환된 결과는 다음 단계 객체의 요약과 ID를 인라인합니다. 현재 이벤트에서 시작하여 모델은 이러한 참조를 따라 필요한 만큼 컨텍스트를 단계별로 호출할 수 있습니다.

예를 들어, 모델은 현재 메시지의 스레드에서 시작하여 인라인된 ID를 따라 관련 워커 세션으로 이동한 다음, 해당 워커에 연결된 다른 코드 검토 스레드를 찾을 수 있습니다.

4.4. 투기적 실행 (Speculative Execution)

우리는 컴퓨터 시스템에서 투기적 실행 개념도 빌려왔습니다. 환경 신호를 기반으로, 에이전트는 결과가 사용될지 알기 전에 백그라운드에서 작업을 시작합니다. 추가적인 백그라운드 컴퓨팅을 사용하여 사람들이 기다리는 시간을 줄이고 개입해야 하는 횟수를 줄이는 것이죠. 유용한 것으로 판명된 결과는 전달되고, 나머지는 버려집니다. 🗑️

개인 에이전트 시나리오에서, 회의 초대 이메일이나 할 일 메시지가 도착하면, 에이전트는 달력 충돌을 확인하고, 배경 정보를 수집하며, 백그라운드에서 답변 초안을 작성할 수 있습니다. 그러면 사용자는 초안을 검토하고 보내기만 하면 됩니다. 동일한 접근 방식이 R&D 협업에도 적용됩니다. 예를 들어, 저희 내부 DeepSeek Harness 사용자 그룹에서는 "조용히 재현하고 수정"하는 정책을 설정했어요. 누군가 문제를 보고하거나 제안된 변경 사항을 논의할 때, 에이전트는 먼저 백그라운드에서 문제를 재현하고 수정 사항을 찾으려고 시도합니다. 문제가 확인되고 간단한 수정 사항이 발견된 후에만 결과를 전달합니다. 그렇지 않으면, 내내 조용히 있습니다. 🤫

"그룹이 해결책을 논의하는 동안, Super-agent는 이미 백그라운드에서 수정 사항이 포함된 Pull Request를 열었습니다."

투기적 실행 예시: 그룹이 해결책을 논의하는 동안, Super-agent는 이미 백그라운드에서 수정 사항이 포함된 Pull Request를 열었습니다.

5. 전이중 다중 채널 상호작용

섹션 2의 2단계 아키텍처는 컨텍스트 수준에서 채널 전반의 상호작용을 지속적으로 유지합니다. 하지만 일상적인 상호작용을 지속적이고 생산적으로 만들려면 두 가지 문제를 더 해결해야 합니다. 바로 상호작용 방식과 상호작용이 일어나는 장소입니다. 첫 번째는 시간 소모적인 백그라운드 작업이 포그라운드 대화를 방해하지 않도록 하는 것입니다. 비동기 ReAct 루프가 이를 해결하여, 세션이 이전 명령이나 작업이 끝나기를 기다리지 않고 언제든지 새로운 지시를 받을 수 있도록 합니다(섹션 4.1). 두 번째는 에이전트 응답의 내용과 세부 수준을 각 통신 채널과 사람들이 그곳에서 소통하는 방식에 맞춰 조정하는 것입니다(섹션 4.2).

5.1. 비동기 ReAct 루프

고전적인 ReAct 루프에서 모델이 동기적인 run() 도구 호출을 하면, 도구가 완료되고 최종 결과를 반환할 때까지 루프가 차단됩니다. 그때까지 세션은 사용자로부터 새로운 것에 응답할 수 없습니다. 이러한 차단을 제거하려면 대화를 턴 기반, 반이중 모드에서 전이중 모드로 전환해야 합니다.

고전적인 ReAct 루프와 비동기 ReAct 루프 비교: 비동기 호출은 즉시 시작됨 알림을 반환하고, 백그라운드 도구가 실행되는 동안에도 세션은 새 메시지에 응답할 수 있습니다.

이를 위해 우리는 시간 소모적인 명령 및 도구 호출을 비동기적인 start() 및 stop() 호출로 대체하여 루프를 비동기 ReAct 루프로 만듭니다. start() 호출은 즉시 "시작됨"을 반환하며, 루프는 도구를 기다리지 않습니다. 백그라운드에서 도구가 완료되면, 시스템은 그 최종 결과를 새로운 이벤트 메시지로 세션에 전달합니다. 컨텍스트에 따라 모델은 너무 오래 실행되는 백그라운드 명령을 종료하기 위해 stop()을 호출할 수도 있습니다.

포그라운드 대화가 백그라운드 작업과 분리되면서, 에이전트는 시간 소모적인 작업이 백그라운드에서 실행되는 동안에도 사람들에게 응답할 수 있습니다. 새로운 입력은 백그라운드 도구가 완료된 후가 아니라, 현재 추론 단계가 끝나는 즉시 처리됩니다.

DeepSeek Harness는 이미 이러한 비동기 작업 메커니즘을 구현하고 있지만, 아직 기본적으로 활성화되어 있지는 않습니다.

5.2. 다중 채널 적응

사람들은 그룹 채팅, 이메일, GitHub 토론에서 다르게 소통합니다. 에이전트는 각 채널에 맞춰 세부 수준과 응답 방식을 모두 조정해야 합니다. 자세한 추론 및 도구 호출 로그는 단일 사용자 터미널에는 적합할 수 있지만, 이를 그룹 채팅에 그대로 게시하면 참가자들에게 정보 과부하를 줄 수 있습니다. 🤯

Super-agent에서는 2단계 아키텍처가 이미 이 문제의 일부를 해결합니다. 각 작업의 자세한 추론 과정과 빈번한 도구 호출은 워커 세션 내에 머물고 외부 채널로 직접 전달되지 않으며, 라우터 계층이 모든 외부 상호작용을 처리합니다. 그 외에도 시스템은 사용자가 매일 사용하는 작업 환경에 연결되어야 하며, 각 채널에 대한 상호작용 규범을 프롬프트를 사용하여 설정해야 합니다.

• IM 및 기타 인스턴트 메시징 채널: 소통을 가볍게 하고 사람들을 가능한 한 적게 방해합니다. 인간 동료처럼, 의사 결정이나 승인이 필요할 때만 사람들에게 알리고, 직접적인 질문만 하며, 짧은 결론을 제공합니다. 저희가 확인한 간단하고 효과적인 규칙 중 하나는 답변당 100단어 제한입니다.
• GitHub, 이메일, 문서와 같은 비동기 채널: 구조화되고 정보 밀도가 높은 출력을 제공합니다. 예를 들어, Pull Request를 생성하거나 업데이트할 때, 프로젝트의 규칙에 따라 전체 문제 배경, 변경 설명, 검증 결과를 작성합니다. 개인 에이전트 시나리오에서는 구조화된 이메일과 문서 요약을 직접 작성합니다.

6. 컴퓨트-스토리지 분리 및 실행 환경 분리

기본적으로 로컬 에이전트는 세 가지를 하나의 장치에 묶습니다. 에이전트 루프를 실행하는 컴퓨트, 지속되어야 하는 세션 상태, 그리고 코드 저장소나 로컬 도구 체인과 같은 실행 환경이죠. 장치가 절전 모드에 들어가거나 오프라인이 되면 에이전트가 중단되고, 다른 장치의 환경에는 접근할 수 없습니다. Super-agent를 영구적으로 온라인 상태로 유지하고 작업에 필요한 실제 작업 환경에 연결하려면, 우리는 컴퓨터 시스템의 컴퓨트-스토리지 분리를 빌려와 이 세 가지를 두 단계로 분리합니다.

6.1. 컴퓨트와 세션 상태 분리

먼저, 컴퓨트를 세션 상태와 분리하여 에이전트를 단일 시스템의 수명 주기에서 해방시키고 클라우드에서 영구적으로 온라인 상태를 유지하게 합니다(섹션 5.1). 에이전트 루프를 실행하는 컴퓨트는 무상태(stateless)일 수 있으며, 세션 상태만 지속되어야 합니다. 따라서 첫 번째 분리 수준은 이러한 컴퓨트를 무상태의 탄력적인 클라우드 컨테이너에서 실행하고, 세션 및 기타 영구 상태를 데이터베이스에 보관합니다. 컨테이너는 확장되거나, 재시작되거나, 교체될 수 있으며, 영구 스토리지는 세션과 작업의 연속성을 보존합니다. 절전 모드에 들어가거나 오프라인이 되는 로컬 장치는 더 이상 에이전트를 중단시키지 않으며, 에이전트는 클라우드에서 영구적으로 온라인 상태를 유지합니다. ☁️

6.2. 클라우드 에이전트 루프와 실행 환경 분리

에이전트 루프와 세션 상태가 클라우드에 있으면, 다음 질문은 에이전트가 작업에 필요한 실행 환경에 어떻게 접근하느냐는 것입니다. 모델이 작업하는 컨텍스트의 대부분은 코드 저장소, 로컬 파일, 종속 서비스 및 기타 실행 환경에 대한 도구 호출에서 나옵니다. 넓게 정의하면, 컨텍스트에는 실행 환경 그 자체가 포함됩니다.

두 가지 일반적인 접근 방식이 있습니다. 첫 번째는 클라우드에서 샌드박스를 시작하고, 코드를 가져와서 환경을 재구축하고 동기화하는 것입니다. 하지만 실제 작업 환경에는 커밋되지 않은 로컬 변경 사항, 개인 자격 증명, 인트라넷 서비스에 대한 종속성, 특정 하드웨어 또는 도구 체인이 포함되는 경우가 많아요. 이 모든 것을 동기화하는 것은 비용이 많이 들고, 무언가를 놓치기 쉽습니다. 두 번째는 사용자에게 로컬 환경을 포기하고 작업을 클라우드로 옮기도록 요구하는 것으로, 많은 사용자에게는 너무 비용이 많이 드는 이전입니다. 🙅‍♀️

복사하고 동기화하기 어려운 부분은 환경 그 자체이므로, 에이전트 루프와 함께 클라우드로 옮길 필요가 없습니다. 두 번째 분리 수준은 에이전트 루프를 클라우드에서 실행하고, 상태가 많이 필요한 실행 환경은 제자리에 두는 것입니다. 각 엔드포인트에는 가벼운 데몬(daemon)만 필요하며, 이는 세션 상태를 유지하지 않고 명령을 실행하고 결과를 반환하는 역할만 합니다. 실행 환경은 클라우드 외부에 남아 있고, 에이전트는 필요에 따라 해당 환경에서 컨텍스트를 읽습니다.

Anthropic의 연구는 동일한 접근 방식을 취합니다. 하네스는 무상태를 유지하고, 세션 로그는 외부에 저장되며, 실행 환경은 통합 인터페이스를 통해 필요에 따라 연결됩니다. 차이점은 대상 시나리오에 있습니다. Anthropic의 문서는 관리형 서비스를 설명하며 주로 온디맨드로 생성되는 샌드박스와 고객 VPC 내의 리소스에 대해 논의합니다. 우리는 먼저 커밋되지 않은 변경 사항과 로컬 자격 증명을 보유하고 간헐적으로만 온라인 상태일 수 있는, 사람들이 매일 사용하는 개인 장치를 연결해야 합니다. 따라서 우리 디자인은 BYOM (Bring Your Own Machine)을 지원하여 사용자의 자체 개발 장치나 개인 컴퓨터를 클라우드 에이전트에 연결합니다. 또한 클라우드 호스팅 머신과 온디맨드로 생성되는 컴퓨트 환경도 지원합니다.

결과적으로, 에이전트는 더 이상 하나의 머신에 묶이지 않습니다. 작업에 필요한 환경에서 명령을 실행하고 컨텍스트를 읽으면서 실행 장치 간에 전환할 수 있습니다. 심지어 간헐적으로만 온라인 상태인 장치와도 작업할 수 있습니다. 사용자의 개인 장치가 다시 연결되면, 클라우드 에이전트는 해당 장치에서 실행해야 하는 작업을 자동으로 시작하고 완료합니다. 아래 다이어그램은 컴퓨트, 영구 상태 및 실행 환경이 두 단계로 분리된 결과적인 구조를 보여줍니다.

컴퓨트-스토리지 분리 및 분리된 실행 환경: 클라우드에서 에이전트 루프는 영구 상태와 분리되어 있으며, 엔드포인트 데몬을 통해 필요에 따라 다양한 실행 환경에 접근합니다.

7. Watchdog(감시자): 영구적인 온라인 상태 유지

섹션 5의 컴퓨트-스토리지 분리만으로는 영구적인 온라인 상태를 유지하기에 부족합니다. 시스템은 장기 실행 중 발생하는 이상 현상으로부터 자동으로 복구되어야 합니다. 영구적으로 온라인 상태인 분산 시스템은 자체 내부 로직에만 의존한다면 오랫동안 안정적으로 유지되기 어렵습니다. 주 시스템 외부의 독립적인 제어 루프가 필요해요.

에이전트 시스템은 또한 전통적인 프로세스 활성도 프로브나 모니터링 스크립트 이상의 것이 필요합니다. 많은 이상 현상은 충돌이 아닙니다. 프로세스는 여전히 실행 중이지만, 모델이 비생산적인 루프에 갇히거나 목표에서 벗어났을 수 있습니다. 따라서 장기 실행 에이전트 시스템은 인프라 활성도뿐만 아니라 작업 진행 상황도 모니터링해야 합니다.

우리의 외부 제어 루프는 주 시스템 외부에서 실행되고 스케줄된 메시지에 의해 구동되는 독립적인 Watchdog(감시자) 세션입니다. Watchdog은 API 오류나 실패한 상태 복구와 같은 인프라 오류를 처리합니다. 또한, 모델을 사용하여 각 워커가 실질적인 진행을 하고 있는지, 아니면 전체 목표에서 벗어나고 있는지를 판단합니다. 이상 현상을 즉시 수정하고, 일시적인 외부 오류가 해결될 때까지 계속 재확인합니다.

Watchdog 자체가 도구 세트를 완비한 에이전트 세션이므로, 관리자는 자연어로 왜 특정 문제가 발생했는지 물어볼 수 있습니다. 또한, 시스템이 실행되는 동안 주 시스템의 동작을 수정하도록 할 수도 있습니다. 예를 들어, 프롬프트를 추가하거나 제거하거나 트리거 규칙을 조정하는 식이죠. 🐕‍🦺

8. 실험 결과

우리는 두 가지 수준에서 핵심 스케줄링 및 라우팅 설계에 대한 예비 실험을 수행했습니다. 전체 시스템 수준과 라우터 계층 단독 수준입니다. 엔드 투 엔드 실험은 2단계 아키텍처와 단일 세션 디자인을 비교하고, 구독 및 통과 메커니즘의 효과를 측정합니다(섹션 7.1). 두 번째 실험은 라우터 계층에서의 배치 처리를 테스트합니다(섹션 7.2). 이 실험들은 합성 워크로드와 단순화된 환경을 사용했으며, 설정의 일부는 더 엄격할 수 있으므로 아래 결과는 단지 지표일 뿐입니다.

8.1. 엔드 투 엔드 성능 비교

그룹 채팅 및 GitHub CI 메시지 스트림에 의해 구동되는 네 가지 엔드 투 엔드 디자인이 동시에 실행되었습니다. 각 실행에는 약 300개의 메시지가 있었고, 그 중 약 20개가 작업 요청이었습니다. 나머지는 비공식적인 채팅, 후속 조치, 취소, CI 메시지였습니다. 코딩 작업은 단순히 시간을 소모하는 도구로 시뮬레이션되었으므로, 실험은 개별 작업을 실행하는 시스템의 능력이 아니라 시스템의 스케줄링 및 조정 능력을 측정합니다. 각 디자인은 5회 실행되었습니다.

네 가지 디자인은 다음과 같습니다.

• Super-agent
• Pass-through 없는 Super-agent
• 서브에이전트 도구가 있는 단일 세션 (두 가지 다른 프롬프트 사용)
  • 중립 프롬프트: "적절할 때 서브에이전트를 사용하세요..."
  • 위임 우선 프롬프트: "채팅의 모든 메시지가 당신에게 도달하므로, 스스로 실행하는 작업은 새 메시지로 인해 계속 중단됩니다. 각 작업을 자체 서브에이전트에 위임하는 것을 선호하고, 작은 일만 직접 하세요..."

각 4가지 디자인별 작업 요청 누적 도착 및 누적 완료 (5회 실행 평균; 메시지 간격 및 작업 지속 시간 1/4 축소; 모델 호출 시간 미축소)

참고: 각 디자인은 5회 실행되었습니다. 작업 완료 시간은 작업 요청부터 결과 메시지까지 측정됩니다.

Super-agent는 p50에서 12.4분, p95에서 15.7분 만에 작업을 완료하며, 서브에이전트 도구가 있는 단일 세션보다 확연히 빠릅니다. 단일 세션 디자인은 이 실험에서 프롬프트에 크게 의존하기 때문에 느려집니다. 주 세션이 종종 작업을 직접 수행하기로 결정하여 완료 시간이 길고 불안정해집니다. 중립 프롬프트에서는 5회 실행 중 모델이 서브에이전트를 호출하지 않았습니다. 모든 작업이 주 세션에서 실행되었고, 새 메시지가 계속해서 이를 방해하여 p95가 29.5분에 도달했습니다. 위임 우선 프롬프트에서는 5회 실행 중 4회에서 모델이 위임했습니다. 완료 시간은 다소 단축되었지만, 전반적으로 Super-agent보다 여전히 길었습니다. 나머지 1회 실행에서는 모델이 작업을 "작은" 것으로 판단하여 직접 수행했는데, 이는 그림에서 보라색의 긴 꼬리(long tail)를 만들었습니다. 단일 세션은 위임 여부를 결정하기 위해 프롬프트 엔지니어링과 모델의 즉각적인 판단에 의존해야 합니다. 2단계 아키텍처는 이 문제를 시스템 수준에서 완화합니다. 라우터는 작업을 직접 실행하지 않으며, 각 워커는 자신이 구독하는 스레드의 메시지만 받습니다.

Super-agent는 여러 독립적인 세션을 유지하므로, 단일 세션 디자인보다 실행당 더 많은 캐시 읽기 토큰을 사용하며, 이는 토큰을 사용하여 더 짧고 안정적인 완료 시간을 얻는 절충점입니다. Pass-through 없는 Super-agent는 Super-agent와 거의 동일한 시간 내에 작업을 완료하지만, 라우터가 실행당 약 30% 더 많은 결정을 내리고, 총 캐시 읽기 토큰은 23.2M에서 31.8M으로 약 37% 증가합니다. 따라서 이 워크로드에서는 pass-through가 작업을 더 빠르거나 더 좋게 완료시키지는 않지만, 라우터 세션의 토큰 사용량과 추론 오버헤드를 상당히 줄여줍니다.

8.2. 라우터 계층 배치 처리 효과

섹션 2.1에서 설명한 배치 처리로 단일 장기 실행 라우터 세션이 얼마나 많은 부하를 처리할 수 있는지 알아보기 위해, 라우터 계층을 단독으로 스트레스 테스트했습니다. 라우터는 실제 모델을 호출했고, 워커들은 목업 모델을 사용했습니다. 우리는 결정이 필요한 트리거의 도착률을 분당 약 1개에서 약 40개로 단계별로 높였습니다. 각 속도에서 평균 배치 크기, 요청당 시간, 결정당 상각된 추론 시간을 측정했습니다. 라우터가 디스패치하기 전에 여러 단계에 걸쳐 추론하거나 도구 호출을 통해 컨텍스트를 호출할 수 있으므로, 결정은 여러 LLM 요청에 걸쳐 발생할 수 있어서 결정당 시간이 요청당 시간을 초과할 수 있습니다.

트리거 도착률에 따른 라우터 세션의 배치 크기, 요청당 시간, 결정당 상각된 추론 시간

위 그림에서 보듯이, 결정이 필요한 트리거의 도착률이 분당 약 1개에서 약 40개로 증가할 때, 평균 배치 크기는 1.0에서 2.8로 증가합니다. 요청당 시간은 2.5초에서 3.9초로만 증가하여 배치 크기보다 느리게 증가하며, 따라서 결정당 상각된 추론 시간은 6.4초에서 1.6초로 감소합니다. 즉, 외부 이벤트가 한꺼번에 도착할 때, 라우터 계층은 쌓여 있던 이벤트를 자동으로 병합하여 유효 처리량을 높입니다. 배치 처리는 섹션 7.1의 결과도 설명합니다. pass-through를 제거하면 라우터의 최대 부하가 증가했지만, 단일 라우터는 여전히 처리량 한계에 도달하지 않았습니다. 따라서 현재 팀 규모에서는 전역 컨텍스트 연속성을 희생하면서 라우터 계층을 성급하게 샤딩할 필요가 없습니다.

9. 향후 과제

섹션 2부터 6까지는 Super-agent의 기본 아키텍처를 구성하는 다섯 가지 모듈을 설명했습니다. 섹션 7의 실험은 많은 작업이 동시에 실행될 때 핵심 스케줄링 및 라우팅 메커니즘이 작동함을 보여줍니다. 시스템이 비교적 단순하게 유지될 수 있었던 것은 현재 단계에서 엔지니어링 설계와 지원하는 시나리오를 모두 단순화했기 때문입니다. 이러한 단순화를 넘어, 네 가지 영역에서 여전히 미해결 문제들이 남아 있습니다.

9.1. 2단계 아키텍처 확장

지금까지는 단일 장기 실행 라우터 세션, 구독 및 통과, 그리고 워커 간 직접 통신 없음이라는 간단한 조합으로 대부분의 일상적인 작업을 낮은 엔지니어링 비용으로 처리해 왔습니다. 라우터 세션 하나로 감당할 수 없을 정도로 작업이 커지고 밀접하게 연결되면, 각 계층에 대한 올바른 구조는 아직 확정되지 않았습니다. 라우터 계층을 언제 얼마나 세분화하여 샤딩해야 하는지, 그리고 피어 워커들이 언제 직접 통신해야 하는지, 어떤 협업 토폴로지에서 통신해야 하는지 알아내기 위해 더 많은 시나리오를 테스트해야 합니다. 🧪 시스템과 모델을 공동 설계하는 것도 탐색할 가치가 있는 또 다른 방향입니다. 이벤트 판단, 배치 디스패치, 컨텍스트 호출과 같은 라우터 계층 작업을 위해 모델을 특별히 훈련하면 라우터 계층의 처리량과 의사 결정 품질이 더욱 향상될 수 있습니다.

메모리 또한 시스템 확장의 한계입니다. 장기 실행 라우터 계층은 기억의 사슬(Chain of Recall)과 함께 주로 최근 작업 및 세션 기록의 온디맨드 검색을 처리합니다. 시스템이 몇 달 이상 실행되면 장기 메모리가 주요 병목 현상이 될 것입니다.

9.2. 세션 없는 에이전트 작업

2단계 아키텍처는 사용자로부터 다중 세션 관리를 숨기므로, 세션은 더 이상 제품 설계의 주요 관심사가 아닙니다. 하지만 기본 실행 세션이 인터페이스의 대화와 직접적으로 매핑되지 않게 되면, 사용자에게 작업을 어떻게 제시하고 어떤 형태의 상호작용 및 프로젝트 관리가 자연스럽게 느껴질 것인가 하는 새로운 질문이 생깁니다. 우리는 채팅 창이 상호작용의 중심이 된 것이 부분적으로는 경로 의존성 때문이라고 생각합니다. 더 많은 상호작용이 도메인별 인터페이스로 이동할 수 있으며, 이는 GitHub 이슈 및 Pull Request에서 직접 작동하는 우리 Super-agent 인스턴스의 경우와 같습니다. 사용자들이 익숙하기 때문에 세션이 인터페이스에 남아 있을 수도 있지만, 사용자가 보는 하나의 대화가 하나의 기본 세션에 반드시 대응할 필요는 없습니다.

이전 섹션에서는 주로 작업 시작과 승인 시의 인간 상호작용에 대해 다루었습니다. 하지만 모델이 빠르게 개선되는 이러한 전환기에는 여전히 많은 작업이 중간에 사람의 개입을 필요로 합니다. 제품 설계가 자율적인 백그라운드 작업의 효율성을 잃지 않으면서 사용자가 핵심 세부 사항에 단계별로 개입할 수 있도록 하는 방법을 탐색할 가치가 있습니다. 예를 들어, 사용자는 백그라운드 실행 중 언제든지 개입하거나, 인계받거나, 에이전트와 실시간으로 작업할 수 있습니다. 🤝

전반적으로, 사용자가 필요로 하는 프로젝트 관리 및 상호작용은 작업 도메인과 개인 스타일에 따라 크게 달라지므로, 최종 디자인은 고도로 맞춤화될 가능성이 높습니다. DeepSeek Harness는 개방형 아키텍처를 가지고 있어 이러한 맞춤화를 더 쉽게 지원합니다.

9.3. 컨텍스트 경계 및 에이전트-대-에이전트(A2A) 통신

지금까지 우리는 단일 Super-agent 인스턴스의 설계에 대해 논의했으며, 그 범위 내의 모든 정보가 하나의 전역 컨텍스트에 수집된다고 가정했습니다. 사용이 개인 및 소규모 팀에서 대규모 조직으로 확장됨에 따라, Super-agent를 어떻게 프로비저닝할지는 사실상 어떤 컨텍스트를 공유하고 어떤 컨텍스트를 격리할지 결정하는 문제가 됩니다. 공유 컨텍스트가 필요한 조직의 일부는 하나의 인스턴스를 공유하고, 격리가 필요한 각 부분은 자체 인스턴스를 갖게 됩니다.

격리된 인스턴스가 조직 내 또는 조직 간에 존재하게 되면, 경계를 넘나드는 협업은 A2A 통신이 됩니다. 예를 들어, 각 구성원의 개인 에이전트와 팀의 공유 Super-agent 간의 통신이 그렇죠. 여기서 A2A는 특정 프로토콜이 아니라 일반적인 에이전트-대-에이전트 통신을 의미합니다. 우리는 아직 기본 컨텍스트를 공유하지 않고 각각 다른 권한 경계를 나타내는 에이전트들이 어떻게 안전하고 신뢰할 수 있게 통신하고 협업할 수 있을지 해결해야 합니다.

9.4. 보안 및 프라이버시

섹션 3의 이벤트 기반 설계는 더 넓은 범위의 환경이 에이전트를 구동할 수 있도록 하지만, 에이전트를 더 많은 신뢰할 수 없는 입력에 노출시키기도 합니다. 보안과 프라이버시가 잘 처리되지 않으면, Super-agent는 매우 작고 신뢰할 수 있는 범위 내에서만 작동할 수 있습니다. 🔒

예를 들어, 섹션 5의 디자인은 에이전트 루프를 클라우드에서 실행하고 실행 장치에 경량 데몬을 설치합니다. 이는 클라우드와 엔드포인트가 서로를 신뢰한다고 암묵적으로 가정합니다. 그러나 클라우드 호스팅 에이전트 루프는 계속해서 외부 이벤트를 수신하는 반면, 엔드포인트 장치에는 개인 코드, 민감한 데이터, 로컬 자격 증명이 포함되어 있습니다. 이 둘을 연결하는 것은 상당한 보안 및 프라이버시 위험을 초래합니다. 서버 측 침입이나 프롬프트 인젝션이 에이전트 루프를 손상시키면, 연결된 모든 엔드포인트 장치가 탈취될 수 있습니다. 🚨

클라우드가 전혀 손상되지 않더라도 자격 증명이 유출될 수 있습니다. 엔드포인트의 자격 증명이 모델의 컨텍스트에 들어갈 수 있는 한, 일반적인 실행 과정에서 노출될 수 있습니다. 따라서 에이전트는 자격 증명을 보지 않고도 사용할 수 있는 방법이 필요합니다. 이러한 아키텍처가 더 널리 사용되려면, 이러한 보안 및 프라이버시 문제를 해결하면서도 다양한 환경에서 컨텍스트를 호출할 수 있는 능력을 유지해야 합니다.

결론

이 디자인은 새로운 이론을 제안하기보다는, 컴퓨터 시스템의 고전적인 엔지니어링 아이디어를 에이전트 시스템 구축에 적용합니다. 기술이 발전함에 따라 특정 구현은 변경되겠지만, 그 뒤에 있는 시스템 설계 아이디어는 더 오랫동안 유용하게 유지될 것이라고 믿습니다. 이러한 아이디어와 DeepSeek Harness를 기반으로 구축된 저희 내부 Super-agent 인스턴스는 이미 지속적으로 실행되고 있습니다. 이는 문제 재현 및 수정, 코드 검토 응답, DeepSeek Harness 자체 개발에 매일 도움이 되고 있습니다. 😊

서두에서 언급했듯이, 대규모 모델은 개별 작업에 대한 인간의 개입을 점점 덜 필요로 하므로, 추가적인 생산성 향상의 병목 현상은 인간의 주의력으로 이동하고 있습니다. 2단계 아키텍처, 이벤트 기반 설계, 비동기 다중 채널 상호작용, 컴퓨트-스토리지 분리, 그리고 외부 Watchdog이 함께 작동하여 시스템이 세션 관리 및 컨텍스트 동기화와 같은 지루한 작업을 대신 처리할 수 있도록 합니다. 그러면 사람들은 실행 세부 사항에서 벗어나 더 높은 수준의 의사 결정과 승인으로 나아갈 수 있습니다.

이러한 방식으로 구축된 에이전트는 더 이상 지시를 기다리는 채팅 창이 아닙니다. 그것은 사람들이 사용하는 디지털 환경에서 지속적으로 온라인 상태를 유지하는 자율적인 협력자가 됩니다. 개인에게는 장치 전반의 일상 업무를 돕는 개인 에이전트가 될 수 있습니다. 팀에게는 R&D 워크플로우의 일부가 되어 작업을 맡아 진행시킵니다. 모델과 시스템 아키텍처가 함께 발전함에 따라, 이러한 더욱 자율적인 작업 방식이 인간-에이전트 협업의 표준이 될 수 있다고 믿습니다. 🚀