Super-agent 설계 탐색: 더 자율적인 Agent 시스템을 향하여

1. Super-agent

지난 1년간 Coding Agent로 대표되는 단일 과제 Agent는, 모델이 도구를 써서 복잡한 문제를 풀 수 있고 인간의 지속적 감시와 단계적 개입이 점점 줄어도 됨을 증명했다. 동시에 여러 Agent 간 협동 능력도 올라가 세션을 넘는 조직과 배치가 가능해졌다. 하위 실행에서 인간의 참여가 줄수록 사람의 역할은 더 높은 차원의 의사결정과 검수로 올라간다.

이러한 모델 능력의 향상은 새로운 응용 형태도 낳았다. 최근 Personal Agent가 잇달아 등장해 일상의 메신저·일정·메일·업무 플랫폼에 직접 연결되고, 정보 흐름을 계속 관찰하며 일을 처리한다. 이처럼 상시 온라인이고 이벤트 기반인 작업 방식은 개인 장면에 국한되지 않는다 — Personal Assistant는 그 한 갈래일 뿐이고, 소프트웨어 개발 같은 상업 장면에서도 충분히 가치 있다.

그러나 기존 주류 Agent 설계는 이 방식을 다중 과제와 팀 협업 규모로 지탱하지 못한다. Agent의 작업은 여전히 단일 Session을 기본 단위로 하고 Session끼리는 서로 독립이다. 사용자가 여러 일을 병렬로 진행하면 수동으로 전환하며 각 Session의 맥락을 기억해야 하는데, 관찰에 따르면 한 사람이 동시에 따를 수 있는 활성 Session은 보통 3~5개다. 이 설계에서 단일 과제의 상한은 모델 능력, 다중 과제의 상한은 인간의 주의력이다.

기존 로컬 단일 세션 Agent를 CLI·MCP·외부 커넥터로 단순 확장해도 외부 메시지를 받을 수는 있게 되지만, 단일 세션 동기 블로킹, 다중 과제 맥락 혼란, 로컬 기기 오프라인 시 정지라는 문제에 묶인 채로 대량의 수동 유지보수가 필요하다.

이 제약을 깨려면 Agent를 한 번의 수동 세션이라는 묶음에서 풀어, 세션을 넘어 맥락을 유지하며 서로 방해하지 않고 여러 복잡 과제를 병렬로 진행하는 연속적 존재로 만들어야 한다. 우리는 이 Agent 형태와 그 시스템 아키텍처를 Super-agent라 부른다.

예컨대 DeepSeek Harness 위에서 사내 운영 중인 Super-agent 인스턴스에서는 하나의 개발 과제가 IM과 GitHub 사이에서 연속적으로 진행된다. 이 인스턴스는 공개 그룹 채팅의 피드백도 계속 관찰해, 아무도 @하지 않았는데도 근본 원인을 찾아 수정 Pull Request를 제출한다.

구체적으로 Super-agent는 다음 네 가지 기초 특성을 지닌다:

• 연속: 사용자는 IM 채팅, GitHub 댓글 같은 익숙한 작업 화면에서 직접 상호작용하고, 항상 하나의 Agent만 존재하는 것처럼 느낀다. "Session X의 맥락에 정보 Y가 있었나"를 생각할 필요가 없다. IM에서 안 A를 제안했다가 GitHub PR 댓글에서 안 B로 바꿔도 이해하고 실행 방향을 조정한다.
• 고효율: 상호작용 응답이 빠르고 동시에 여러 복잡 과제를 병렬로 높은 품질로 완수한다. 이전 명령이나 과제가 끝나기를 기다리지 않고 다음 지시를 받는다.
• 능동: 사용자의 지시를 하나하나 기다리지 않고 환경 이벤트를 계속 관찰해 처리할 가치가 있는 일을 스스로 진행하며, 개입이 필요 없을 때는 조용히 있다.
• 지속: 항상 온라인이고 사용자의 실제 작업 환경에 직접 연결되며, 장기 실행 중 이상이 생기면 자동 복구한다.

단일 ReAct Loop는 네 특성을 동시에 지탱할 수 없어 하위에 아키텍처가 필요하다. 비슷한 설계 제약은 비슷한 아키텍처 선택을 낳는다. 개인용 어시스턴트든 소프트웨어 개발 같은 상업 Agent든, 상시 온라인으로 환경 이벤트에 병행 응답하는 시스템을 목표로 하면 하위 아키텍처는 비슷해질 것이다. 또 여기서 마주하는 문제의 상당수는 전통 컴퓨터 시스템이 오래 다뤄온 문제와 매우 닮아, 고전 시스템 설계 사상이 그대로 적용된다.

구현에는 변형이 있을 수 있지만, 네 특성을 지탱하는 기본 뼈대는 다섯 모듈이다: 2계층 아키텍처(제2절)로 연속 상호작용과 고효율 병행을 함께 잡고, 이벤트 기반(제3절)으로 능동 응답을 실현하며, 사람을 향한 상호작용(제4절)으로 상호작용 자체를 연속이면서 고효율로 만들고, 연산·상태·환경의 분리(제5절)와 Watchdog(제6절)로 기기를 넘는 지속 온라인과 자가 치유를 가능하게 한다.

2. 2계층 아키텍처

채널을 넘는 연속 상호작용과 다중 과제의 고효율 병행을 동시에 이루려면, 하위 세션 조직에서 연속성과 처리량 사이의 근본적 트레이드오프에 직면한다.

모든 이벤트를 같은 Session이 처리하면 맥락은 가장 연속적이지만 단일 ReAct Loop의 순차 실행 속도가 상한이라 완료에 오래 걸리고 처리량은 낮으며, 여러 과제의 중간 세부가 뒤섞여 품질을 해친다.

반대로 모든 이벤트마다 독립 Session을 새로 만들면 병행 처리량은 최대지만, 과제가 완전히 독립적이지 않은 이상 전역 맥락 부재로 각 Session의 결과가 조각나고, 여러 Session이 제각각 응답하면 상호작용이 혼란스러워진다.

둘을 겸하기 위해 "전역 연속성 유지"와 "고병행 실행"을 두 계층으로 나눈다: 상주하는 Router 계층(2.1)이 모든 인간 상호작용과 전역 조율을 맡고, 맥락 격리된 Worker 계층(2.2)이 과제를 병행 실행한다.

이 2계층 구조로 시스템은 하위에서 맥락 관리와 병행 실행을 떠안아, 사용자 쪽에서는 Session의 존재가 옅어지고 사용자가 마주하는 것은 언제나 하나의 Super-agent가 된다. 이렇게 보면 사용자에게 Session을 수동 관리시키는 것은 상당 부분 하위 LLM API에서 이어받은 설계 관성이며, Session은 시스템의 구현 세부사항이지 사용자의 인지 부담이어서는 안 된다.

여기서 "2계층"은 논리적 책임 구분이며, 각 계층은 구현상 단일 Session에 국한되지 않고 자체 내부 구조를 가질 수 있다. 이하 각 계층의 설계를 다룬다.

2.1 Router 계층

Router 계층은 상주하는 전역 라우팅 계층으로, 모든 입구의 인간 상호작용을 받는다. 과제를 넘는 모든 정보와 의사결정이 여기 모이며, 전역 순서점(Sequence Point)·조율점·기억으로 기능한다. 이 전역 노드가 병목이 되지 않도록 Router 계층은 설계상 구체 과제를 직접 실행하지 않고 인간 상호작용과 과제 배치만 하며, Bash 도구도 갖추지 않을 수 있다.

하나의 중심 노드가 여러 실행 노드에 배치하는 구조는 겉보기에 흔한 Agent Team과 비슷하지만 강조점이 다르다. Agent Team은 주로 단일 복잡 과제 내부의 단계 분해와 역할 협업에 쓰이고, 하위 단계가 보통 빽빽하게 결합되어 Team Lead는 과제 세부를 깊이 이해하고 하위 과제를 계획하며 구성원을 고빈도로 조율해야 해 스스로 무거운 추론 부담을 진다. Super-agent에서 Router 계층은 과제 간의 고차원 연관과 배치만 다루고 단일 과제 내부 분해에는 개입하지 않는다. 거꾸로 Agent Team의 주 세션을 프롬프트로 "직접 실행하지 않고 대외 응대와 구성원 배치만 한다"고 제약하면 그것도 이 2계층 아키텍처로 볼 수 있다. 실전에서 Router 계층의 과제는 생각보다 복잡하지 않은 경우가 많아, 가벼운 모델로도 속도와 품질을 겸하기 쉽다.

내부 구현에서도 Router 계층은 단일 Session에 국한될 필요가 없고 일부 로직은 LLM 호출 없이 가능하다. 우리는 가장 직접적인 단일 상주 LLM Session을 Router 계층의 핵심으로 택했고, 이것이 보기보다 병목이 되기 어렵다는 것을 확인했다. 이전 추론 라운드 동안 도착한 환경 이벤트(제3절의 Trigger)가 쌓여 다음 라운드에서 함께 처리되는 배칭(Batching)이 형성되고, 통합 처리의 추가 비용이 작기 때문이다:

• 외부 이벤트 흐름이 잔잔하면 Trigger가 하나씩 Router Session에 들어가 단발 응답 지연이 낮게 유지된다.
• 이벤트가 몰려 Router Session에 대기가 생기면, 이전 추론 동안 쌓인 여러 Trigger가 자동으로 통합되어 다음 LLM 호출에 한꺼번에 주입된다. Router의 각 단계는 전형적으로 긴 입력·짧은 출력이며, 쌓인 Trigger를 한 번의 API 호출에 묶으면 Prefill이 병렬 계산되어 단발 요청 소요시간의 증가가 배치 크기보다 훨씬 느리다. 일정 범위에서는 적체가 많을수록 한 결정에 분배되는 추론 시간이 낮아진다. 상한은 맥락 길이와 모델이 한 라운드에서 정확히 처리할 수 있는 Trigger 수다.

7.2절에서 이 배칭 효과를 정량적으로 보인다. 뒤에 나올 구독·직통 메커니즘과 연쇄 리콜(3.2, 3.3)을 더하면, 단일 상주 Router Session은 현재 팀 규모에서 충분하다.

규모가 더 커져 한 세션이 감당 못 하게 되면 Router 계층 내부를 다단 필터 구조로 하거나 수평 분할(Sharding)로 여러 세션으로 나눌 수 있다. 그때 Router 내부 설계 자체가 연속성 대 처리량의 트레이드오프다. 분할이 촘촘할수록 병행 처리량은 올라가지만 분할 간 기억과 맥락 연속성은 내려간다. 전역 기억 문제가 풀리기 전까지 이 트레이드오프는 계속된다.

2.2 Worker 계층

Worker 계층은 구체 실행을 맡은 세션들로, 각 Worker는 서로 맥락 격리되어 완전한 실행 도구를 장착하고 독립 맥락에서 단일 과제에 집중한다. Worker Session이 과제 결과와 코드 품질을 직접 결정하므로 보통 가장 강한 모델을 배치한다.

Worker는 인간과 직접 상호작용하지 않으며 추론 과정과 도구 호출은 외부 채널에 출력되지 않는다. Router 계층에 상태를 보고하면 Router가 사용자에게 통일되어 응답한다. 이로써 병행도와 인도 품질을 보장하면서 여러 세션이 제각각 답하는 혼란을 피한다.

다중 과제 병행 시 각 Worker는 독립적으로 진행되고 동층 Worker 간 직접 통신은 보통 불필요하다. 충돌은 주로 같은 Pull Request 같은 공유 작업 환경에서 일어나는데, 양쪽이 해당 Thread를 구독 중이면 같은 이벤트 통지를 받아(3.2) 스스로 발견·해결할 수 있고, 드문 횡단 과제 조율은 Router 계층이 중계한다.

Router와 마찬가지로 각 Worker Session도 내부에서 단일 세션에 국한되지 않는다: 복잡 단일 과제에서는 내부에 Subagent를 만들 수 있고 그 자체가 Agent Team일 수도 있으며, 이는 상위 Router에 투명하다. 이 구조는 코드 협업(여러 독립 재현, PR 리뷰, 기능 개발을 막힘 없이 병행)에도 Personal Assistant에도 들어맞는다: UI는 단일 채팅이지만 같은 대화창에서 여러 화제를 다룰 때 프런트의 단일 채팅 화면이 상호작용의 연속성을 유지하고, 하위는 화제마다 Worker를 배정해 과제를 병행 진행하고 답변을 초안한다.

3. 이벤트 기반

능동성을 갖추려면 먼저 구동 방식을 바꿔야 한다. Agent를 구동하는 주 입력은 세션에서 인간이 한 줄씩 치는 프롬프트가 아니라 환경의 반구조화 이벤트다. Super-agent에서는 그룹 채팅 메시지, 메일·일정 알림, 코드 리뷰 댓글, CI 실행 결과 같은 환경 이벤트를 Trigger라 부른다. Trigger를 감시·응답함으로써 Agent는 단일 Session처럼 인간 지시에 한 번씩 수동 실행되지 않는다.

이벤트가 도착해 처리되기까지의 생애주기를 따라 네 가지 점진적 질문을 다룬다: 프로그램과 모델을 결합한 2단 전략으로 대량의 소음을 거르는 법(3.1), 구독과 직통으로 이벤트를 Worker에게 전달하는 법(3.2), Inline & Spill과 연쇄 리콜로 고밀도 주입과 필요시 회수를 하는 법(3.3), 그리고 투기적 실행으로 환경 신호에 따라 뒤에서 미리 움직이는 법(3.4).

3.1 이벤트 필터

실제 그룹 채팅과 코드 플랫폼을 연결하면 이벤트 흐름은 뚜렷하게 "고소음·저트리거율"이다. 일상 메시지의 대부분은 Agent 개입이 필요 없다. 모든 이벤트를 대모델로 처음부터 판단하면 지연과 연산 비용을 감당할 수 없다. 시스템 설계의 Fast Path / Slow Path 사상을 빌리면, 대모델 추론은 유연하지만 비싼 Slow Path이고, 명확하고 안정적인 고빈도 판단을 결정적 코드로 고정하면 저지연·저비용의 Fast Path가 된다.

따라서 이벤트 진입의 첫 단계는 필터다. 모델 호출 전에 결정적 정책으로 소음을 걸러 의미 이해가 필요한 후보만 모델에 넘긴다. 프로그램과 대모델을 결합한 2단 필터를 쓴다:

• 프로그램 계층 정책(Fast Path): 이벤트 출처, 그룹 범위, 사용자·봇 허용 목록 같은 결정적 조건을 코드로 빠르게 검사한다. 예컨대 출처마다 "명시적 요청에만 응답", "후보 이벤트로", "그냥 무시"를 설정해 모델 호출 전에 무관한 메시지 대부분을 제거한다.
• 의미 계층 정책(Slow Path): 프로그램 계층을 통과한 후보를 LLM에 넘겨, 프롬프트로 작성된 정책과 맥락에 따라 행동 여부를 판단하게 한다. 의미 계층은 인간을 위한 자연어 확장점이기도 해서 언제든 프롬프트로 켜고 끄고 추가할 수 있다.

3.2 이벤트 라우팅

전역 Router 계층이 채널 간 연속성을 유지하지만, 배치된 과제의 후속 이벤트까지 매번 Router를 거치면 이 전역 노드가 큰 부하를 지고 응답 지연이 올라간다. 그래서 Fast / Slow Path는 필터링된 이벤트 라우팅에도 적용된다. 전역 Router는 신규 과제의 콜드스타트와 과제 간 조율만 맡고, 귀속이 확정된 후속 이벤트는 프로그램이 해당 Worker 세션으로 직접 보낸다.

실제 워크플로에서 같은 GitHub Pull Request, 같은 IM 화제, 같은 메일 스레드 아래의 연속 이벤트가 하나의 이벤트 흐름 — Thread — 를 이룬다. Router가 어떤 Thread의 초기 이벤트로 Worker Session을 만들면 그 Worker는 해당 Thread를 직접 구독하고, 라우팅은 두 갈래로 나뉜다:

• 구독됨(Fast Path): 같은 Thread의 후속 이벤트는 프로그램이 구독 Worker에게 직통하고 Router의 전달이 필요 없다. 새 이벤트가 현재 과제 범위를 넘으면 Worker가 구독을 취소하거나 Router에 돌려 재배치할 수 있다.
• 미구독(Slow Path): Router 계층은 전역 파악을 위해 모든 이벤트를 관측할 수 있지만, 아직 구독되지 않은 신규 이벤트의 판단과 배치만 담당한다.

또한 Thread와 Worker의 구독은 다대다다. 한 Worker가 여러 관련 Thread를 구독할 수 있고 한 Thread를 여러 Worker가 구독할 수도 있다. 여러 Worker가 같은 작업 환경이나 논의에서 교차하면 그 Thread의 새 이벤트가 구독자 전원에게 동시 직통되어, 점대점 통신 없이도 서로의 행위를 알고 충돌을 스스로 해결할 수 있다. 출력 측면에서 Worker는 핵심 결론을 Router에 보고하고 Router가 사용자에게 통일 응답하며 전역 기억을 갱신한다.

3.3 맥락 조직

필터와 라우팅을 거쳐 이벤트가 대상 Session에 들어온 뒤의 문제는 모델의 맥락 창에 얼마나 주입할까다. 입력이 제한된 인간 프롬프트에서 환경이 끊임없이 만드는 반구조화 이벤트로 바뀐 지금, 도구 호출과 이벤트 주입의 구조 설계가 더 중요해졌다. 너무 많이 주입하면 창을 채우고 주의를 희석하고, 너무 적으면 도구 호출 왕복이 늘어 실행 단계가 는다. 맥락 창을 낭비하는 것은 모델의 지능을 낭비하는 것이다.

유한한 맥락 창을 캐시처럼 관리하자. 컴파일러 최적화와 시스템의 개념을 빌리면 주입 설계는 두 기본 연산으로 귀결된다. Inline은 곧 쓸 것 같은 정보를 현재 창에 직접 실어 도구 호출 왕복을 줄인다. Spill은 창 예산을 넘거나 저빈도인 완전한 정보를 창 밖에 두고 안에는 참조나 요약만 남겨 필요시 읽게 한다.

고전적인 지역성(Locality) 사상과 결합해 Inline & Spill로 주입과 도구 호출을 단계적으로 최적화한다:

1. 최소 정보로 시작: 처음에는 대상의 ID와 내용 요약만.
2. 지역성으로 관련 정보를 Inline: 곧 쓸 것 같은 정보부터 창에 넣는다. 밀접 관련 대상의 ID를 먼저 붙이고, 시공간적으로 인접한 내용 — 본문 앞 50자, IM 메시지의 전후와 답한 메시지, 리뷰 논의의 인접 댓글 — 을 뒤에 붙인다.
3. 상한 초과는 Spill: 모두 Inline할 수 없는 긴 내용에는 작은 길이 상한을 두고 초과분은 창 밖으로 Spill한다. 간단한 방법은 초과분을 잘라 이어읽기 입구를 남기고 모델이 필요시 도구로 읽게 하는 것이다.

또한대량의 후속 이벤트가 Worker에 직통되고 시스템이 장기 실행으로 역사 과제를 쌓으면, Router는 모든 과제의 전체 역사를 자기 창에 넣을 수 없으면서도 사용자가 채널을 넘어 옛 과제를 언급할 때 맥락을 되찾아야 한다. Inline & Spill을 각종 대상에 일관되게 적용하면 필요시 전개하는 다단 검색 메커니즘 — 연쇄 리콜(Chain of Recall) — 을 얻는다. 이는 Router 계층의 장기 정보 상실을 완화한다.

구체적으로 Trigger, Thread, Worker Session 등 대상에 고유 ID를 부여하고 주입 시 밀접 관련 대상의 ID를 Inline해 하위에 참조 그래프를 만든다. 도구로 회수한 대상 자체도 Inline & Spill을 따르므로 그 반환 결과에 다음 홉의 요약과 ID가 포함되고, 모델은 현재 이벤트에서 참조 관계를 따라 단계적으로 맥락을 회수할 수 있다. 예컨대 현재 메시지에서 소속 Thread를 읽고, Thread에 Inline된 ID로 관련 Worker Session을 추적하고, 거기서 그 Worker와 연결된 다른 코드 리뷰 Thread까지 도달한다.

3.4 선제 행동

시스템 설계의 투기적 실행(Speculative Execution)을 빌리면, Agent는 결과가 채택될지 확실하지 않을 때 환경 신호에 따라 뒤에서 미리 시도할 수 있다. 추가 배경 연산으로 인간의 대기와 개입 비용을 줄인다. 가치 있으면 결과를 넘기고 없으면 버린다.

Personal Assistant에서는 회의 초대나 할 일 메시지를 받으면 배경에서 일정 충돌을 확인하고 자료를 모으고 답장 초안을 준비한다. 사용자는 훑고 확인만 하면 된다. 개발 협업에서도 마찬가지다. 우리는 사내 DeepSeek Harness 사용자 그룹에 "조용히 재현하고 수정하기" 정책을 설정했다: 누군가 문제를 보고하거나 변경안을 논의하면 Agent가 배경에서 먼저 재현과 수정 탐색을 시작하고, 문제가 확인되고 간단한 수정이 발견된 경우에만 결과를 넘기며 그 외에는 끝까지 조용히 있는다.

4. 사람을 향한 상호작용

제2절의 2계층 아키텍처는 맥락 차원에서 채널 간 연속을 보장했다. 실제 상호작용 경험에서 연속과 고효율을 함께 이루려면 두 문제를 더 풀어야 한다: 하나는 비동기 ReAct Loop로 배경의 오래 걸리는 작업이 전면 대화를 막는 것을 없애, 이전 명령·과제 완료를 기다리지 않고 새 지시를 받게 하는 것(4.1). 다른 하나는 사용자가 익숙한 각 작업 채널에서 출력 방식을 그 채널의 대역폭과 사람의 습관에 맞추는 것이다(4.2).

4.1 전이중 상호작용

고전 ReAct Loop에서 모델이 동기식 run() 도구 호출을 하면 도구가 끝나 결과를 돌려줄 때까지 루프가 막히고, 그 사이 세션은 새 입력에 응답할 수 없다. 이 차단을 없애려면 일문일답의 반이중에서 전이중으로 전환해야 한다.

이에 오래 걸리는 명령과 하위 과제 도구 호출을 비동기 start()와 stop()으로 바꿔 비동기 ReAct Loop를 구성했다. start() 호출은 즉시 "시작됨(Started)"을 돌려받고 루프는 그 도구를 기다리지 않는다. 배경 도구가 완료되면 시스템이 최종 결과를 새 이벤트 메시지로 세션에 전달한다. 또 모델은 맥락에 따라 stop()을 호출해 너무 오래 도는 배경 명령을 스스로 끊을 수 있다.

이로써 전면 대화 응답과 배경 과제 실행이 분리되어, Agent는 긴 과제를 뒤에서 돌리면서도 인간 입력에 응답한다. 새 입력은 현재 추론 단계 직후에 처리되고 배경 도구 완료를 기다리지 않는다. 이 비동기 과제 메커니즘은 DeepSeek Harness에 구현되어 있으나 기본 활성화는 아니다.

4.2 다중 채널 상호작용

작업 채널마다 정보 밀도와 상호작용 습관이 달라 출력은 그에 맞아야 한다. 1인용 터미널 상호작용을 그대로 그룹 채팅에 옮겨 장황한 추론 과정과 촘촘한 도구 호출을 생으로 흘리면 다인 협업에서 정보 과부하가 오기 쉽다.

Super-agent에서는 2계층 아키텍처가 이 일부를 이미 해결한다: 과제 안의 장황한 추론과 도구 호출은 Worker Session 내부에 격리되어 외부 채널에 직접 출력되지 않고 Router 계층이 대외 응대를 통일한다. 그 위에 사용자의 일상 작업 환경을 연결하고 프롬프트로 채널별 상호작용 규범을 정한다:

• IM 등 즉시 메신저 채널: 저방해의 가벼운 소통을 지향한다. 사람 동료처럼 의사결정이나 검수가 필요할 때만 알리고, 직접적인 질문만 하고 결론은 짧게. 단순하지만 효과적인 경성 규칙 하나 — 회신당 100단어 이하 — 를 검증했다.
• GitHub, 메일, 문서 등 비동기 채널: 구조화된 고정보 밀도의 비동기 인도를 지향한다. Pull Request 작성·갱신 시 프로젝트 규범에 따라 문제 배경, 변경 설명, 검증 결과를 완전히 쓰고, Personal Assistant에서는 구조화된 메일과 문서 요약을 바로 초안한다.

5. 연산·상태·환경의 분리

기존 로컬 Agent는 Agent Loop를 진행하는 연산, 영속 보존할 세션 상태, 코드 저장소와 로컬 툴체인 등 실행 환경을 기본적으로 한 대의 기기에 묶는다. 기기가 잠들거나 오프라인이면 Agent가 멈추고 다른 기기의 환경에도 접근할 수 없다. Super-agent가 지속 온라인으로 실제 작업 환경에 유연하게 연결되려면, 시스템 설계의 저장-연산 분리(Compute-Storage Separation) 사상을 빌려 두 단계로 묶음을 푼다: 1단계는 Loop 연산과 영속 세션 상태를 분리해 단일 기기 수명주기의 제약에서 벗어나 클라우드 상주를 이룬다(5.1). 2단계는 클라우드의 Agent Loop와 무거운 상태의 실행 환경을 분리해 실제 작업 환경은 제자리에 둔 채 기기 간 접근을 지원한다(5.2).

5.1 연산과 상태의 분리

Agent Loop를 진행하는 연산은 무상태로 만들 수 있고 영속 보존할 것은 세션 상태다. 첫 번째 분리는 Loop 연산을 클라우드의 무상태 탄성 컨테이너에 두고 Session 등 영속 상태를 데이터베이스에 저장한다. 무상태 컨테이너는 수평 확장·재시작·교체가 자유롭고 세션과 과제의 연속성은 영속 저장이 보장해, Agent는 단일 로컬 기기의 수명주기에서 벗어나 클라우드에 상주한다.

5.2 연산과 실행 환경의 분리

Loop와 상태가 클라우드에 상주한 뒤의 문제는 과제에 필요한 실행 환경 접근이다. 모델이 필요로 하는 맥락의 상당 부분은 저장소, 로컬 파일, 의존 서비스 등 실행 환경에서 도구 호출로 얻는다. 이런 의미에서 광의의 맥락에는 실행 환경 자체도 포함된다.

흔한 두 가지 생각이 있다: 클라우드에 샌드박스를 띄워 코드를 가져와 환경을 재구축·동기화하는 것 — 실제 작업 환경에는 커밋되지 않은 수정, 사유 자격증명, 사내망 의존, 특정 하드웨어·툴체인이 있어 동기화는 비용이 크고 누락도 잦다. 다른 하나는 사용자에게 로컬 환경을 버리고 클라우드로 옮기라고 하는 것 — 많은 사용자에게 이전 비용이 너무 크다.

복제·동기화가 어려운 것은 환경 자체이니, 실행 환경을 클라우드에 올릴 필요가 없다. 두 번째 분리는 Agent Loop는 클라우드에서 돌리고 무거운 상태의 실행 환경은 제자리에 남기며, 단말 쪽에는 세션 상태를 저장하지 않는 가벼운 daemon만 둔다. daemon은 명령 실행과 결과 반환만 맡아, 실행 환경을 클라우드 밖에 둔 채 Agent가 필요시 그 맥락을 읽게 한다.

이 생각은 Anthropic의 "뇌와 손의 분리"(Decoupling the brain from the hands)와 일치한다. harness를 무상태로 유지하고 세션 로그를 harness 밖에 두며 통일 인터페이스로 실행 환경을 필요시 연결한다. 차이는 장면이다. 그 글은 관리형 서비스를 다루며 주로 주문형 샌드박스와 고객 VPC 내 자원을 논한다. 여기서 먼저 연결할 대상은 사용자가 일상적으로 쓰고 간헐적으로 온라인일 수 있는 개인 기기 — 커밋 안 된 수정과 로컬 자격증명을 지닌 — 다. 따라서 이 설계는 일상 개발기나 개인 컴퓨터를 연결하는 BYOM(Bring Your Own Machine)과 클라우드 관리 기기·주문형 연산 환경 연결을 모두 지원한다.

이제 Agent는 한 대의 기기에 묶이지 않고 과제에 따라 실행 기기를 골라 필요한 환경에서 명령을 실행하고 그 맥락을 얻는다. 간헐 온라인 기기도 지원한다. 사용자의 개인 기기가 다시 온라인이 되면 클라우드 Agent가 자동으로 과제를 발동해 그 기기에서 실행해야 할 일을 마친다.

6. Watchdog

지속 온라인에는 저장-연산 분리 외에 장기 실행에서 이상을 자동 복구하는 능력이 필요하다. 상시 온라인 분산 시스템은 주 시스템 내부 논리만으로 장기 신뢰성을 보장하기 어려워, 주 시스템 밖에 독립적인 외부 제어 루프 — Control Loop — 를 둬야 한다.

또 Agent 시스템에서는 전통적인 프로세스 생존 탐지나 감시 스크립트만으로 부족하다. 많은 이상은 프로세스 붕괴가 아니라 모델이 무효 루프에 빠지거나 목표에서 벗어나는 것이기 때문이다. 장기 실행 Agent 시스템은 인프라 생존뿐 아니라 과제 자체의 진행도 감시해야 한다.

우리는 주 시스템 밖에 독립적인 Watchdog Session을 두고 정시 메시지로 구동해 외부 Control Loop를 만들었다. Watchdog은 API 오류, 상태 복구 실패 같은 인프라 고장을 처리하는 외에, 모델이 각 Worker의 실질 진전 여부와 방향의 목표 이탈 여부를 판단한다. 이상을 발견하면 신속히 개입·수정하고 외부 일시 고장에는 회복될 때까지 계속 재검한다. Watchdog 자체도 완전한 도구 능력을 갖춘 Agent Session이라, 유지보수자는 자연어로 고장 원인을 물을 수 있고 프롬프트 증감이나 트리거 규칙 조정 등 주 시스템의 행동을 온라인으로 고치게 할 수도 있다.

7. 예비 실험

앞부분의 핵심 스케줄링·라우팅 설계를 평가하기 위해 두 층위의 실험을 했다: 먼저 종단간 실험으로 2계층 아키텍처·구독 직통과 단일 Session 방안을 비교하고(7.1), 이어 Router 계층의 배칭을 단독 시험했다(7.2). 실험은 합성 부하와 단순화 환경에 기반하므로 결과는 예비 참고용이다.

7.1 절제 실험

그룹 채팅과 GitHub CI 메시지 흐름으로 네 가지 종단간 방안을 동시에 구동했다: 1회 실험에 약 300건의 메시지가 포함되고 이 중 약 20건이 작업 요청, 나머지는 잡담·후속·중지·CI 메시지다. 코딩 작업은 시간만 소모하는 도구로 대체해, 실험이 재는 것은 시스템의 스케줄링과 협동 능력이지 단일 과제 실행 능력이 아니다. 각 방안을 5회 반복했다.

비교한 네 방안은 Super-agent, 직통을 제거한 Super-agent, 그리고 두 가지 프롬프트 구성의 단일 Session + Subagent 도구다. 중립 프롬프트는 "Use a subagent for a piece of work when appropriate...", 위임 우선 프롬프트는 "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."이다.

과제 완료 시간에서 Super-agent의 p50과 p95는 각각 12.4분과 15.7분으로 Subagent 도구를 가진 단일 Session을 뚜렷이 앞섰다. 이유는 Subagent 붙은 단일 Session이 실험 장면에서 프롬프트 영향을 크게 받아 주 Session이 흔히 직접 실행을 택해 총 완료 시간이 길고 불안정하기 때문이다. 중립 프롬프트에서는 5회 실행 중 단 한 번도 Subagent를 호출하지 않고 모든 작업이 주 Session에서 진행되어 새 메시지에 계속 끊기며 p95가 29.5분에 달했다. 위임 우선으로 바꾸면 5회 중 4회 위임해 완료 시간이 줄었지만 여전히 Super-agent보다 느렸고, 남은 1회는 일이 "작다"고 판단해 스스로 실행해 그림의 보라색 긴 꼬리를 만들었다. 단일 Session에서 프롬프트 공학과 모델의 즉석 판단에 맡기기보다, 2계층 아키텍처는 Router가 구체 작업을 직접 실행하지 않고 Worker가 구독한 Thread의 메시지만 받게 하여 이 문제를 시스템 층에서 완화한다.

시스템 비용 측면에서는 여러 독립 세션을 유지하는 만큼 Super-agent의 1회 실험 캐시 읽기 토큰이 단일 Session보다 많다 — 더 많은 토큰으로 더 짧고 안정된 완료 시간을 산 것이다. Super-agent 내부에서 직통을 제거하면 완료 시간은 완전판과 거의 같지만 Router가 내려야 할 결정이 약 30% 늘고 총 캐시 읽기 토큰은 2,323만에서 3,177만으로(약 +37%) 증가했다. 이 부하에서 직통은 완료 품질과 속도를 높이지 않지만 Router Session에 상당한 토큰과 추론 비용을 아껴준다.

7.2 Router 계층의 배칭

2.1절의 단일 상주 Router Session의 처리량 상한과 배칭을 검증하기 위해 Router 계층만의 부하 시험을 했다: Router는 실제 모델, Worker는 Mock 모델을 쓰고, 결정이 필요한 Trigger 도달률을 분당 약 1건에서 약 40건까지 단계적으로 올리며 평균 배치 크기, 단발 요청 소요시간, 한 결정당 분배 추론 시간을 관찰했다.

도달률이 분당 약 1건에서 약 40건으로 오르자 평균 배치는 1.0에서 2.8로 커지는 동안 단발 요청 소요시간은 2.5초에서 3.9초에 그쳐 증가폭이 배치 크기보다 작았고, 한 결정당 추론 시간은 6.4초에서 1.6초로 내려갔다. 외부 이벤트가 급증해도 Router 계층이 적체를 자동 통합해 유효 처리량을 올릴 수 있음을 뜻는다. 이는 7.1에서 직통 제거로 Router의 피크 부하가 늘어도 단일 Router의 처리량 상한에 닿지 않았던 이유이기도 하다. 따라서 현재 팀 규모에서는 전역 맥락 연속성을 희생하며 Router를 조기 수평 분할할 필요가 없다.

8. 미해결 문제

제2~6절의 다섯 모듈이 Super-agent를 지탱하는 기본 아키텍처를 이루고, 제7절의 실험은 다중 과제 병행에서의 핵심 스케줄링·라우팅 효과를 검증했다. 이 시스템이 낮은 복잡도로 돌아가는 것은 상당 부분 현재 단계의 공학·장면 단순화 덕이다. 그 단순화의 적용 범위를 넘어서면 2계층 확장(8.1), Session 사라진 이후의 인간-기계 협업(8.2), 맥락 경계와 A2A(8.3), 보안과 프라이버시(8.4)에 여전히 풀어야 할 문제가 남는다.

8.1 2계층 아키텍처의 확장

"단일 상주 Router Session + 구독 직통 + Worker 간 직접 통신 없음"이라는 단순화된 조합은 작은 공학 비용으로 현재 대부분의 일상 과제를 덮는다. 그러나 과제 규모와 결합도가 커져 단일 Router Session의 수용을 넘어서면 계층 내부 구조에는 정설이 없다. Router를 언제 수평 분할할지, 입자를 어떻게 나눌지, Worker 간에 언제 직접 통신을 도입하고 어떤 협업 위상을 쓸지는 더 많은 장면에서 검증해야 한다. 동시에 시스템-모델 협동 설계(Co-design)도 탐구할 가치가 있다. Router 계층의 이벤트 판별, 일괄 배치, 맥락 회수 등에 맞춘 전문 훈련이 처리량과 의사결정 품질을 더 끌어올릴 수 있다.

한편 상주 Router와 참조 그래프 기반 연쇄 리콜이 주로 푸는 것은 근기 과제와 세션 역사의 필요시 검색이다. 운용 기간이 석 달을 넘어 더 길어지면 장기 기억이 확장성을 가르는 주된 병목이 된다.

8.2 Session 벗어난 이후의 Agent 협업

2계층 아키텍처로 하위의 다중 세션 관리를 사용자에게서 숨겨 Session은 제품 설계의 첫 문제가 아니게 됐다. 그러나 하위 실행 세션이 UI의 대화에 직접 대응하지 않게 되면, 과제를 어떻게 보여주고 자연스러운 상호작용과 프로젝트 관리 형식을 어떻게 제공할지가 새 문제가 된다. 채팅창 중심의 상호작용은 어느 정도 경로 의존의 산물이라고 본다. 상호작용은 더 많이 영역 특화 화면에서 일어날 수 있다. 본문의 실례처럼 Super-agent가 GitHub의 Issue와 Pull Request에서 직접 일하는 식이다. Session은 사용 습관을 위해 UI에 남겨도 되지만, 사용자가 보는 하나의 대화가 하위에서 꼭 하나의 Session에만 대응하는 것은 아니다.

또한 본문이 주로 논한 것은 과제 착수와 결과 검수 단계의 인간 참여다. 모델 능력이 빠르게 바뀌는 과도기에는 많은 과제가 여전히 중간 참여를 필요로 하며, 핵심 세부에 대한 점진적 개입과 배경 자율 추진의 효율을 제품 설계에서 어떻게 겸할지 — 실행 중 언제든 들어가고, 넘겨받고, Agent와 실시간 협업하게 하는 것 — 도 탐구할 가치가 있다. 종합하면 사용자가 필요로 하는 프로젝트 관리와 상호작용 형식은 작업 영역과 개인 스타일에 깊이 의존해 최종 형태는 고도로 맞춤화될 가능성이 크고, DeepSeek Harness는 개방적 아키텍처 덕분에 이런 맞춤을 지원하기 쉽다.

8.3 맥락 경계 획정과 A2A 협업

본문이 다룬 것은 줄곧 단일 Super-agent 인스턴스 내부의 설계로, 서비스 범위의 정보가 모두 같은 전역 맥락에 모인다고 가정했다. 이용 범위가 개인이나 소규모 팀에서 더 큰 조직으로 넓어가면, 조직이 Super-agent를 어떻게 배치할지 정하는 것은 사실 맥락 공유와 격리의 경계를 긋는 일이다. 공유가 필요한 범위는 같은 인스턴스를 쓰고 격리가 필요한 범위는 따로 둔다.

더 나아가 조직 안팎에 서로 격리된 여러 인스턴스 — 각 구성원의 Personal Assistant와 팀 공용 Super-agent 같은 — 가 존재하면 경계를 넘는 협업은 Agent 간 통신(A2A, 특정 프로토콜을 가리키지 않음)이 된다. 하위 맥락을 공유하지 않고 서로 다른 권한 경계를 대표하는전제하에서 안전하고 신뢰할 수 있는 A2A 통신과 협업을 어떻게 실현할지는 계속 탐구해야 한다.

8.4 보안과 프라이버시 보장

제3절의 이벤트 기반 설계는 Agent를 더 넓은 환경으로부터 구동하게 하는 한편, 신뢰할 수 없는 입력에 대한 노출도 키운다. 보안과 프라이버시 문제를 잘 풀지 못하면 Super-agent는 아주 작고 신뢰되는 범위에서만 동작한다.

예컨대 제5절은 Agent Loop를 클라우드에 두고 각 실행 기기에 가벼운 daemon을 설치하는데, 이 설계는 클라우드와 단말이 서로를 신뢰한다는 전제에 서 있다. 클라우드의 Agent Loop가 외부 이벤트를 계속 받아들이는 동안 단말에는 사유 코드, 민감 데이터, 로컬 자격증명이 있으면, 이 기기 간 연결은 뚜렷한 보안·프라이버시 위험을 안고 온다. 클라우드 Loop가 서버 침입이나 프롬프트 주입으로 무너지면 연결된 모든 단말이 제어될 잠재적 위험에 놓인다.

또 클라우드가 뚫리지 않았더라도 단말 쪽의 자격증명이 모델의 맥락에 들어가는 한 정상 실행 과정에서도 자격증명 유출 위험은 있다. 그래서 Agent가 자격증명 자체에 전혀 닿지 않고도 자격증명을 쓰게 하는 메커니즘 설계가 필요하다. 이 아키텍처가 널리 쓰이려면 다양한 환경에서 맥락을 회수하는 동시에 위의 보안·프라이버시 문제를 해결해야 한다.

9. 맺음말

전체를 돌아보면 우리는 새 이론을 내놓지 않았다. 컴퓨터 시스템의 고전적 공학 사상을 Agent 시스템 구축에 적용했을 뿐이다. 구체적 구현은 기술 발전과 함께 바뀌겠지만, 그 밑의 시스템 설계 사상은 더 오래 참고 가치가 있으리라 본다. 현재 이 사상과 DeepSeek Harness로 만든 사내 Super-agent 인스턴스는 계속 돌고 있으며, 일상적으로 문제 재현·수정, 코드 리뷰 대응, DeepSeek Harness 자체의 반복에 참여한다.

서두에 말했듯 대모델이 단일 과제를 수행하는 데 인간 개입이 줄어들수록 생산성 향상을 가르는 병목은 인간의 주의력으로 옮겨 간다. 2계층 아키텍처, 이벤트 기반, 비동기 다중 채널 상호작용, 저장-연산 분리, 외부 Watchdog을 통해 시스템은 하위에서 번거로운 세션 관리와 맥락 동기를 맡아, 인간이 구체적 실행 세부에서 더 높은 차원의 의사결정과 검수로 오르게 한다.

이 형태에서 Agent는 더 이상 지시를 수동적으로 기다리는 대화창이 아니라 디지털 환경에 상주하는 자율적 협력자로 진화한다. 개인에게는 기기를 넘어 일상 일을 처리하는 Personal Assistant이고, 팀에게는 개발 워크플로에 녹아들어 구체 과제를 맡아 밀어주는 존재다. 모델 능력과 시스템 아키텍처가 함께 진화하며 이 더 자율적인 작업 방식이 인간-기계 협업의 상태가 되리라 믿는다.

원문 말미의 설명: 본 글의 일부 설계는 dsh-superagent-prototype에 구현되어 있다("원문 읽기"로 GitHub 저장소). 해당 플러그인은 기술 경로 검증을 위한 프로토타입일 뿐 DeepSeek의 정식 제품이 아니다. 저자와 감사: 본문은 DeepSeek Harness 팀의 공동 실천에서 나왔다. Yujia Qiao가 시스템 구현과 집필을 맡았고 Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang, F. Zhou 등이 검토와 토론에 참여했다.

출처

• DeepSeek 产品部(공식 WeChat) — 「Super-agent 设计探索」원문, 2026-11-01
• deepseek-ai/dsh-superagent-prototype — MIT 라이선스 프로토타입(README, docs 000–008)
• 사이트 내 대조: 영어 전역 번역 · 중국어 원문 · dsh-superagent 보도