
Hermes 80% 속도 향상, Goooo의 AI 예측·실행 엔진도 더욱 가속화
요약
Nous Research가 Hermes Agent v0.19.0을 출시하며 콜드 스타트 시간을 80% 단축했습니다. 이번 업데이트는 Goooo의 AI 예측 및 실행 엔진인 SPYDER 아키텍처의 효율성을 높여 시장 시그널에 대한 빠른 대응을 가능하게 합니다.
핵심 포인트
- Hermes Agent 초기화 시간 4.3초에서 0.9초로 약 80% 단축
- 추론 프로세스의 실시간 토큰 단위 스트리밍 출력 지원
- Gooo AI 엔진(SPYDER)의 핵심 컴포넌트로서 분석 및 실행 속도 향상
- 예측 시장 환경에서 빠른 시그널 탐지와 주문 실행을 위한 인프라 최적화

작성자: Goooo 팀
Nous Research는 7월 20일, Hermes Agent v0.19.0을 출시하였으며, 이번 버전을 Quicksilver Release라고 명명했습니다. 이번 업데이트는 주로 성능, 태스크 전달, 보안 승인, 실행 환경의 분리 등의 영역에 초점을 맞추어, Hermes 전체의 운용 효율을 더욱 향상시켰습니다.
그중에서도 가장 눈에 띄는 변화는 모델과의 첫 번째 인터랙션(Interaction)이 시작되기 전의 콜드 스타트(Cold Start) 초기화 시간이 약 4.3초에서 0.9초로 단축된 것입니다. 이는 약 80%에 가까운 절감입니다. 동시에, Hermes는 추론 프로세스의 실시간 스트리밍(Streaming) 출력을 기본적으로 지원하며, 태스크 실행 및 결과 전달 메커니즘도 더욱 개선했습니다.
이번 업데이트는 Goooo가 현재 구축하고 있는 기술 아키텍처(Architecture)에도 직접적인 효과를 가져옵니다. Hermes는 Goooo AI 시그널 엔진인 SPYDER의 핵심 컴포넌트(Component) 중 하나로, Agent의 추론, 도구 호출(Tool Call), 태스크 실행 프로세스의 일부를 담당하고 있습니다. OpenClaw의 멀티 에이전트(Multi-Agent) 오케스트레이션(Orchestration) 시스템, 그리고 Goooo의 Execution Engine과 함께 Goooo의 인텔리전트 분석·실행 인프라를 구성합니다.
이 아키텍처에서 SPYDER는 뉴스, 시장 데이터, 온체인(On-chain) 데이터, 기타 정보 소스로부터 시그널을 읽어 분석하는 역할을 담당합니다. OpenClaw는 여러 Agent 간의 태스크 분해와 협업을 담당하며, Hermes는 구체적인 태스크 실행과 추론을 담당합니다. 그리고 Execution Engine은 리스크 체크, 실행 판단, 주문 라우팅(Routing)을 담당합니다.
Hermes의 성능, 안정성, 안전 메커니즘은 Goooo가 시그널을 탐지한 후 분석 완료, 그리고 실행에 이르기까지의 전체적인 효율에 직접적인 영향을 미칩니다. 시장 시그널을 지속적으로 처리하고 여러 예측 시장과 연결해야 하는 시스템에게 있어, 기반이 되는 Agent 인프라의 모든 업그레이드는 분석 속도, 전략 대응, 실행 품질의 추가적인 향상으로 이어집니다.
Hermes가 더 빨라짐에 따라, Goooo의 AI 예측·실행 엔진도 동시에 가속화됩니다.
속도야말로 알파(Alpha)이다
Hermes v0.19.0에서의 가장 직접적인 성능 향상은 콜드 스타트 시의 첫 응답 시간이 약 4.3초에서 0.9초로 단축된 것입니다. 이는 약 80%에 가까운 개선입니다. 이 최적화는 CLI, Gateway, TUI, Desktop, Cron 등 여러 실행 환경을 대상으로 합니다. 또한 Hermes는 추론 프로세스의 실시간 스트리밍 출력을 기본 모드로 채택하였으며, 응답 표시 방식도 기존의 행(Line) 단위 렌더링에서 토큰(Token) 단위 렌더링으로 변경했습니다.
이를 통해 Agent는 태스크를 수신한 후, 더 빠르게 초기화를 완료하고 즉시 모델 추론 프로세스로 이행할 수 있게 됩니다.
일반적인 Q&A나 콘텐츠 생성 상황에서는 몇 초의 차이가 주로 사용자 경험에 영향을 미칩니다. 하지만 예측 시장 환경에서는 시간에 대한 요구가 더욱 높습니다. 갑작스러운 뉴스, 정책 발표, 경기 전개, 온체인 자금 이동, 매크로 경제 데이터 발표 등은 매우 짧은 시간 내에 시장의 재가격 형성을 일으킬 수 있습니다. 시스템이 더 빨리 시그널을 인식하고 판단을 완료하여 주문을 보낼 수 있을수록, 실제 체결 가격은 시그널 발생 시점의 시장 상태에 가까워집니다.
Gooo 전체 시스템의 실행 플로우(Flow)에 주목하면, 크게 Signal, Prompt, Orchestrate, Action의 4단계로 분류할 수 있습니다.
SPYDER는 먼저 Bloomberg, Dune, Glassnode, Arkham 등의 데이터 소스로부터 뉴스, 온체인 활동, 자금 흐름, 시장 가격 시그널을 가져옵니다. 그 후, 시스템은 원래의 시그널을 구체적인 태스크로 변환하며, Agent가 이벤트에 대한 영향, 관련 시장, 잠재적인 가격 차이를 분석합니다. 그리고 멀티 에이전트 오케스트레이션을 통해 교차 검증을 수행하며, 최종적으로 Execution Engine이 리스크 체크, 포지션 계산, 주문 라우팅을 실행합니다.
이 프로세스의 총 지연 시간 (Latency)은 여러 요소로 구성됩니다. 여기에는 데이터 도달 시간, 시그널 인식 시간, Agent 기동 시간, 모델 추론 시간, 멀티 Agent 협업 시간, 리스크 체크 시간, 주문 전송 시간이 포함됩니다.
Hermes는 콜드 스타트 (Cold Start) 초기화 시간을 약 3.4초 단축하여, 새로운 세션, 새로운 Agent 인스턴스, 또는 스케줄 태스크가 처음으로 추론 프로세스에 진입할 때 발생하는 고정적인 오버헤드 (Overhead)를 줄여줍니다. 독립적인 Agent, Cron 태스크, 병렬 전략 인스턴스를 빈번하게 기동해야 하는 시스템에서는 이러한 개선 효과가 각 콜드 스타트 시마다 지속적으로 발휘됩니다. SPYDER가 여러 이벤트, 데이터 소스, 예측 시장을 동시에 추적하는 경우, 누적적인 시간 절감 효과는 더욱 커집니다.
예측 시장 그 자체에서도, 기본적인 거래 구조가 속도의 중요성을 결정합니다.
Polymarket과 Kalshi는 모두 WebSocket을 통한 실시간 데이터 인터페이스를 제공하며, 오더북 (Order Book)의 변화, 거래 정보, 시장 상태 업데이트를 전송합니다. Polymarket의 Market Channel은 가격 레벨의 변화, 최신 체결 가격, 최선의 매수·매도 주문을 지속적으로 전송할 수 있습니다. Kalshi의 WebSocket 역시 마찬가지로 오더북 변화, 거래, 주문 상태의 실시간 업데이트를 지원합니다. 시장 데이터는 이벤트 스트림 (Event Stream) 형식으로 지속적으로 변화하며, 거래 시스템은 업데이트를 수신한 후 신속하게 대응해야 합니다.
마찬가지로, 주문 집행 또한 시간의 영향을 받습니다.
Polymarket을 예로 들면, 시장가 주문은 실제로는 체결 가능한 가격을 가진 지정가 주문에 의해 실행되며, 주문은 오더북에 존재하는 유동성과 즉시 매칭됩니다. 시스템이 몇 초 늦게 주문을 전송할 경우, 최적의 가격이나 체결 가능 수량은 이미 변해 있을 수 있습니다. 원래 0.52달러로 체결 가능했던 컨트랙트가 시장의 초기 가격 조정 후에는 0.56달러까지 이동할 수 있습니다. 최종 결제 금액이 1달러가 되는 바이너리 컨트랙트 (Binary Contract)의 경우, 이 4센트의 차이는 잠재적 이익 폭이 48센트에서 44센트로 축소됨을 의미하며, 진입 비용은 약 7.7% 상승합니다.
우리는 이러한 변화가 특히 유동성이 낮은 시장에서 더욱 두드러질 것이라고 생각합니다. 오더북의 깊이가 제한적인 경우, 큰 주문은 여러 가격대의 유동성을 연속적으로 소비할 수 있습니다. 그 경우 지연은 체결 가격, 체결 가능 수량, 슬리피지 (Slippage) 수준에 동시에 영향을 미칩니다. 방향성 판단에서 우위를 가진 전략이라 하더라도, 최종적으로는 충분히 빠른 집행을 통해 그 판단을 실제 이익으로 전환해야 합니다.
예측 시장은 실시간 정보를 어떻게 흡수하는가
2026년 6월, 볼로냐 대학교의 경제학자 Giovanni Angelini와 Luca De Angelis는 논문 「When Do Markets Fully Process Public Information? Evidence from Real-Time Prediction Markets」를 발표했습니다. 연구팀은 Kalshi 상의 NBA 실시간 승패 계약과 NBA의 플레이 바이 플레이 (Play-by-Play) 데이터를 분 단위로 매칭하였으며, 최종적으로 1,438경기, 2,876건의 계약, 40만 건 이상의 계약·분 단위 관측 데이터를 분석 대상으로 삼았습니다.
연구자들은 경기 전 가격과 실시간 경기 상황을 기반으로 승률 베이스라인 모델을 구축하고, 모델에 의한 승률 변화와 Kalshi 계약 가격의 변화를 비교했습니다. 그 결과, 모델이 산출한 승률이 1분 이내에 1퍼센트 포인트 변화했을 때, Kalshi의 매수·매도 호가 중간 가격은 동일 기간 동안 평균 약 0.64퍼센트 포인트밖에 변화하지 않았으며, 나머지 조정은 그 후 몇 분에 걸쳐 지속적으로 가격에 반영되는 것이 확인되었습니다.
이 결과는 3점 슛, 점수 역전, 연속 득점 등의 정보가 이미 완전히 공개된 경우에도, 예측 시장이 가격 조정을 완료하기까지는 일정 시간이 필요함을 보여줍니다. 유동성이 충분히 존재하는 경우 중요한 경기 정보는 비교적 신속하게 흡수됩니다. 반면, 매수·매도 스프레드 (Spread)가 크고 거래량이나 미결제 약정 (Open Interest)이 적은 시장에서는 단기적인 가격 반응 부족이 더욱 명확하게 나타납니다.
또 다른 참고 사례는 Rajat M. Barot과 Arjun S. Borkhatariya가 2026년 4월에 발표한 논문 「PolySwarm: A Multi-Agent Large Language Model Framework for Prediction Market Trading and Latency Arbitrage」입니다.
PolySwarm은 Polymarket을 위해 멀티 에이전트 (Multi-Agent) 기반의 실시간 거래 프레임워크를 설계했습니다. 이 시스템은 50가지의 서로 다른 분석 역할을 보유하며, 시장 평가마다 기본적으로 25개의 에이전트 (Agent)를 추출하여 동일한 이벤트에 대해 병렬적인 판단을 실행합니다. 그 후, 에이전트 간의 컨센서스 (Consensus)와 시장의 내재 확률을 통합합니다. 핵심 스캔 프로그램은 5초마다 Polymarket의 활성 시장을 읽어 들여 유동성, 기대값, 리스크 조건을 충족할 경우 CLOB API를 통해 주문을 전송합니다.
논문에서는 클라우드형 대규모 언어 모델 (LLM) API의 단일 호출에는 통상 1~5초가 소요된다고 지적합니다. 하나의 시장 판단에 여러 에이전트의 병렬 추론 (Parallel Inference)이 필요한 경우, 모델 호출 속도 자체가 일부 단기적인 기회의 유효 시간 범위를 초과할 수 있습니다. 따라서 PolySwarm은 병렬 추론, 결과 캐싱 (Caching), 대규모 모델과 소규모 모델의 계층적 호출 등을 통해 전체적인 레이턴시 (Latency)를 제어합니다.
이 두 가지 사례는 시장과 시스템이라는 두 가지 관점에서 속도의 중요성을 보여줍니다. Kalshi의 실증 데이터는 공개 정보가 예측 시장 가격에 완전히 반영되기까지 수 분이 걸린다는 것을 보여줍니다. 반면, PolySwarm의 시스템 설계는 에이전트 시스템 자체의 추론 레이턴시가 실행 가능한 시간 범위의 상당 부분을 소비할 수 있음을 보여줍니다.
Goooo에게 있어 특정 이벤트의 방향성을 인식하는 것은 첫 번째 단계에 불과합니다. 시스템은 동시에 Polymarket, Kalshi, ZKPM, HXRO 등 여러 시장의 가격, 유동성, 거래 규칙, 실행 비용을 비교하여 종합 조건이 더 나은 시장으로 주문을 전송해야 합니다.
동일한 이벤트가 두 시장에서 각각 0.54달러와 0.57달러로 제시되어 있다고 가정해 봅시다. Goooo가 두 시장을 동일한 이벤트로 인식한 후, 규칙 검증, 가격 차이 분석, 리스크 체크, 주문 라우팅 (Routing)을 완료해야 합니다. 처리 속도가 빠를수록 시스템이 더 낮은 가격을 확보할 가능성이 높아집니다. 다른 트레이더들이 뒤따라오면 두 시장의 가격은 통상 점진적으로 수렴하며, 초기 3센트의 가격 차이도 줄어들게 됩니다.
따라서 Hermes가 4.3초에서 0.9초로 단축된 의의는 시스템 전체의 흐름을 따라 이해할 수 있습니다.
더 빠르게 추론 단계에 진입하고, 더 빠르게 태스크 분해를 완료하며, 더 빠르게 멀티 에이전트 협업을 시작하고, 더 빠르게 결과를 실행 엔진 (Execution Engine)으로 전달함으로써, 결과적으로 시그널 발생부터 주문 전송까지의 총 시간을 단축합니다.
1초 미만으로 줄어든 최초 콜드 스타트 (Cold Start) 오버헤드는 Goooo가 태스크를 수신한 후 모델 추론 단계로 전환하기까지의 시간을 직접적으로 단축합니다. 고정 지연 시간이 1초 감소할 때마다 시스템은 더 빠르게 분석을 시작할 수 있으며, 시그널 발생 시점의 시장 상태에 더 가까워져 시장의 재가격 형성으로 인한 슬리피지 (Slippage)나 수익 손실을 줄일 수 있습니다.
예측 시장에서는 판단이 거래 방향을 결정하고, 속도가 그 판단을 어떤 가격으로 포지션 (Position)에 전환할 수 있는지를 결정합니다. 따라서 Goooo 시스템에서 속도야말로 알파 (Alpha)입니다.
성능 향상에서 시스템 수준의 신뢰성으로
속도는 Quicksilver에서 가장 이해하기 쉬운 업그레이드입니다. 하지만 장기간 가동되며 외부 도구를 호출하고 실제 거래 환경에 참여하는 에이전트 시스템에게 실행 속도는 기초 능력의 일부일 뿐입니다.
성숙한 에이전트 인프라스트럭처에는 다음과 같은 세 가지 중요한 과제를 해결해야 합니다.
그것은 에이전트가 어느 범위까지 자율적으로 행동할 수 있는지, 완료된 태스크를 안정적으로 제공할 수 있는지, 그리고 서로 다른 전략과 실행 환경 간에 명확한 분리를 유지할 수 있는지에 대한 점입니다.
Quicksilver는 이 세 가지 방향성을 중심으로 지능형 승인(Intelligent Approval), 태스크 전달(Task Delivery), Profile 라우팅 메커니즘을 더욱 개선했습니다. Goooo에게 있어 이러한 능력은 Execution Engine의 리스크 관리, 태스크 상태의 지속성, 그리고 여러 시장과 여러 전략을 병렬로 실행할 때의 전체적인 안정성에 직접적인 영향을 미칩니다.
기본적으로 활성화된 보안 자율성
또 다른 주목할 만한 변화는 Quicksilver가 지능형 승인 메커니즘을 기본 기능으로 설정했다는 점입니다.
Hermes가 잠재적으로 위험이 있는 명령을 감지하면, 시스템은 먼저 모델로 전달하여 1단계 심사를 실시합니다. 그곳에서 명령의 목적, 영향 범위, 잠재적 리스크를 판단합니다. 동시에, 사전에 설정된 강제 거부 규칙은 최고 우선순위를 유지합니다. 시스템이 yolo 모드로 동작하고 있더라도, 명령이 명확히 금지된 조작에 해당할 경우 실행 프로세스는 즉시 중단됩니다.
이 메커니즘을 통해 Agent에게는 2층 구조의 보안 보호가 제공됩니다.
모델은 컨텍스트에 기반한 판단이 필요한 조작을 담당합니다. 예를 들어, 특정 도구 호출(Tool Call)이 현재의 태스크 목표에 부합하는지, 명령에 이상한 파라미터가 포함되어 있는지, 실행 결과가 다른 시스템에 영향을 미칠 가능성이 있는지 등을 판단합니다.
인간이 사전에 설정한 하드 룰(Hard Rule)은 안전 경계를 제어합니다. 여기에는 특정 디렉토리에 대한 접근 금지, 고위험 명령 실행 금지, 특정 민감 권한의 제한 등이 포함됩니다. 모델은 규칙에 의해 허용된 범위 내에서 판단하고 행동할 수 있지만, 이러한 기반이 되는 제한 사항을 변경하거나 회피할 수는 없습니다.
이 설계는 자동 매매 시스템에서 특히 중요합니다. Trading Agent는 계정 권한, 자금 포지션, 시장 주문, 외부 데이터 소스에 접근합니다. 단 한 번의 잘못된 도구 호출, 이상한 파라미터 입력, 또는 전략 판단의 오차는 직접적인 자금 리스크로 전환될 가능성이 있습니다. 따라서 거래 시스템에는 자율적인 판단 능력과 명확한 리스크 경계가 모두 필요합니다.
Gooo의 Execution Engine은 이미 유사한 아키텍처를 채택하고 있습니다. 각 전략은 실행 단계에 들어가기 전에 포지션 규모 관리, 일관성 체크, 리스크 평가, 실행 조건 검증을 통과해야 합니다.
예를 들어, Agent는 시장 시그널에 기반하여 특정 이벤트에 거래 기회가 존재한다고 판단하고, 주문 방향이나 실행 시장을 제안할 수 있습니다. 하지만 최종적인 포지션 상한, 단일 거래 리스크, 가격 괴리, 시장 화이트리스트, 전략 권한 등은 Execution Engine 내에 사전에 설정된 규칙에 의해 관리됩니다.
전략 제안이 리스크 임계값을 초과하거나, 시장 가격이 당초의 시그널로부터 이미 괴리된 경우, 시스템은 포지션을 축소하거나 실행을 일시 중지하거나 주문을 직접 거부할 수 있습니다.
Agent는 시장을 이해하고 의사결정을 생성하는 역할을 맡으며, Execution Engine은 모든 의사결정이 제어 가능한 범위 내에서 실행되는 것을 보장합니다.
Hermes는 지능형 승인과 하드 거부 규칙을 결합함으로써 Agent의 안전한 실행 능력을 더욱 강화했습니다. 그리고 이는 Goooo의 전체적인 아키텍처와도 일치합니다.
즉, Agent에게는 충분한 자율 행동 능력을 부여하면서도, 자금·권한·리스크는 항상 명확한 경계 내에서 관리된다는 설계입니다.
완료된 작업은 사라져서는 안 된다
Quicksilver는 중요한 인프라 개선 중 하나로 영속화 전달 장부(Persistent Delivery Ledger)를 추가했습니다.
기존의 실행 흐름에서는 모델이 이미 추론을 완료하고 최종 결과를 생성했더라도, 결과가 반환되기 전에 Gateway가 크래시(Crash), 재부팅 또는 연결 끊김을 일으킬 경우 해당 태스크의 출력 결과가 정상적으로 전달되지 않을 가능성이 있었습니다. 상위 시스템 입장에서 보면 태스크는 여전히 실패한 상태가 되며, 이미 소비된 추론 시간이나 계산 리소스도 계속 사용할 수 없게 됩니다.
영속화 전달 장부는 이미 완료되었으나 아직 정상적으로 전달되지 않은 응답을 기록합니다. Gateway에 중간 장애가 발생하더라도 시스템은 복구 후에 전달 프로세스를 계속할 수 있으며, 결과가 모델과 하류(Downstream) 시스템 사이에 정체되는 것을 방지합니다.
이 기능은 Agent 기반의 거래 시스템에서 특히 중요합니다. 하나의 거래 태스크는 통상적으로 시그널 인식, 시장 분석, 전략 판단, 리스크 체크, 주문 집행 등 여러 단계를 거쳐 처리됩니다. 각 단계에서 대응하는 상태와 결과가 생성되며, 이는 다음 모듈로 전달됩니다.
예를 들어, Agent가 이미 특정 이벤트의 분석을 완료하여 거래 방향, 대상 시장, 권장 가격을 확정했더라도, 그 결과가 Execution Engine(실행 엔진)으로 전송되기 전에 유실된다면 시스템은 실행 기회를 놓칠 수 있습니다. 더욱 심각한 경우에는 주문 자체는 이미 전송되었음에도 불구하고 확인 결과가 정상적으로 반환되지 않을 경우, 상위 시스템은 해당 주문이 미실행 상태인지, 일부 체결(Partial Fill)된 상태인지, 아니면 이미 완료되었는지 판단할 수 없습니다.
따라서 Agent 시스템은 각 태스크가 어느 단계까지 실행되었는지, 어떤 결과가 생성되었는지, 그리고 그 결과가 다음 모듈에 의해 수신되었는지를 기록해야 합니다. 이상이 발생하더라도 시스템은 명확하게 정의된 상태로부터 처리를 계속할 수 있으며, 주문의 중복 전송이나 완료된 태스크를 놓치는 것을 방지할 수 있습니다.
Goooo의 실행 파이프라인은 여러 데이터 소스, Agent, 그리고 예측 시장을 연결하고 있습니다. 태스크 상태의 지속성은 시스템의 안정성에 직접적인 영향을 미칩니다. 영속화된 전달 장부(Persistence Delivery Ledger)는 Gateway 장애로 인한 결과 유실을 줄이고, 태스크 복구, 상태 검증, 이상 추적을 위한 더욱 완전한 기반을 제공합니다.
실제 자금이 관여하는 시스템에서 안정성이란 통상 가동 시에 얼마나 많은 태스크를 처리할 수 있는가만을 의미하지 않습니다. 시스템이 중단된 후 각 태스크의 상태를 정확하게 복구할 수 있는가도 중요합니다. Hermes의 전달 메커니즘 개선을 통해 이미 완료된 분석이나 의사결정을 확실하게 다음 단계로 전달하는 것이 가능해졌으며, Goooo 전체의 실행 파이프라인은 지속성과 추적 가능성을 더욱 높이고 있습니다.
격리 능력을 기본 기능으로
Quicksilver는 Profile 기반의 메시지 라우팅 메커니즘을 새롭게 도입했습니다. 하나의 Gateway는 서버, 채널 또는 특정 스레드에 따라 태스크를 서로 다른 Profile에 할당할 수 있습니다. 각 Profile은 독립된 설정, Skills, Memory, 그리고 키(Key) 환경을 가지며, 하나의 Gateway 인프라 위에서 여러 그룹의 Agent를 동시에 구동할 수 있습니다.
예를 들어, 개발자는 업무용 서버를 work Profile에 연결하고, 개인 이용 채널을 personal Profile에 연결할 수 있습니다. 두 환경은 각각 고유한 태스크 규칙, 장기 Memory, 도구 권한, 액세스 인증 정보를 개별적으로 로드합니다. Quicksilver는 나아가 여러 Profile을 가진 Gateway의 내결함성(Fault Tolerance)도 강화했습니다. 단일 Profile에서 설정 오류가 발생하더라도 다른 Profile은 계속해서 가동될 수 있습니다.
이 기능은 Goooo의 멀티 마켓 실행 아키텍처와 높은 친화성을 가집니다.
Goooo는 서로 다른 종류의 전략을 동시에 운용해야 합니다. 일부 전략은 매크로 데이터나 정치 이벤트를 추적하고, 일부 전략은 스포츠 경기나 실시간 배당률(Odds)을 처리하며, 또 다른 일부 전략은 온체인(On-chain) 자금 흐름이나 시장 간 가격 차이 분석에 특화되어 있습니다. 각 전략이 이용하는 데이터 소스, 시장 계정, 리스크 임계값, 실행 권한에는 각각 차이가 있습니다.
Profile 격리를 이용함으로써 Goooo는 각 전략 유형별로 독립된 실행 환경을 구축할 수 있습니다. 예를 들어, Polymarket 전략에서는 대응하는 시장 인터페이스, 지갑 권한, 이벤트 Memory만을 로드합니다. Kalshi 전략에서는 독립된 계정 인증 정보, 컴플라이언스 규칙, 주문 파라미터를 사용합니다. 연구형 Agent는 더 많은 데이터 소스에 접근할 수 있지만, 실제 자금 집행 권한은 가지지 않습니다.
리스크 레벨 또한 Profile에 따라 분류할 수 있습니다. 저리스크 전략에는 제한적인 자동 실행 한도를 부여하고, 고리스크 전략에는 추가 승인을 요구하며, 시뮬레이션 전략에서는 분석 결과만을 생성하는 등의 운용이 가능합니다. 각종 태스크는 병렬로 실행되면서도 설정, Memory, 권한의 경계를 명확하게 유지할 수 있습니다.
또한, Quicksilver는 Bitwarden과 1Password의 키 소스(Key source)도 도입했습니다. API Key와 계정 인증 정보는 Agent 기동 시 패스워드 관리 시스템으로부터 가져올 수 있으며, 여러 Vault에 대한 동시 접속, 변수 충돌 처리, 키의 취득 출처 추적도 지원합니다. 이를 통해 기밀 인증 정보를 집중 관리할 수 있으며, 장기간 평문(Plaintext) 형태의 .env 파일에 저장할 필요가 없어집니다.
Goooo에게 있어 이는 전략 로직과 액세스 인증 정보를 더욱 분리할 수 있음을 의미합니다. 각 Agent는 현재 태스크를 완료하는 데 필요한 권한만을 획득하며, 특정 시장 계정이나 키에 문제가 발생하더라도 그 영향 범위를 해당 Profile 내로 한정할 수 있습니다.
시스템이 여러 데이터 소스에 접속하고, 다양한 전략을 실행하며, 서로 다른 시장 계정을 관리해야 하는 경우, 격리 능력은 운영 안정성과 보안에 직접적인 영향을 미칩니다. Hermes는 Profile 라우팅, 설정 분리, 키 관리를 Gateway 계층으로 통합하여, Goooo가 더 많은 시장과 전략으로 확장할 수 있는 더욱 명확한 기반 아키텍처(Base architecture)를 제공합니다.
더 큰 비전
v0.18.0 출시 이후, Hermes는 약 2,245건의 코드 커밋(Code commit)을 완료했고, 약 1,065건의 Pull Request를 머지(Merge)했으며, 약 3,300건의 Issue를 해결하였고, 450명 이상의 개발자가 컨트리뷰션(Contribution)에 참여했습니다.
이러한 수치는 Hermes가 이미 활발하고 지속적으로 진화하는 오픈소스 에코시스템(Open source ecosystem)을 형성하고 있음을 보여줍니다. 다양한 개발자와 실제 이용 시나리오에서 발생하는 니즈가 모델 호출, 도구 연동, 권한 관리, 태스크 복구, 멀티 환경 배포 등 기반 기능의 지속적인 개선을 추진하고 있습니다.
실제로 Agent 업계 전체는 새로운 발전 단계로 진입하고 있습니다. 초기 Agent 제품은 주로 모델 호출, 도구 이용, 태스크 오케스트레이션(Task orchestration)을 중심으로 발전해 왔습니다. 하지만 Agent가 거래 계정, 기업 데이터, 결제 시스템, 그리고 실제 자금과 연결되게 됨에 따라, 시스템이 장기간 안정적으로 가동될 수 있는지가 제품 능력을 평가하는 중요한 기준이 되고 있습니다.
모델 능력은 Agent가 얼마나 복잡한 태스크를 이해하고 처리할 수 있는지를 결정합니다. 반면, 인프라는 그 능력들을 지속적이고 신뢰성 있게 실제 환경에 투입할 수 있는지를 결정합니다. 이 두 가지가 결합됨으로써 하나의 Agent 시스템이 최종적으로 얼마나 큰 비즈니스 규모를 지원할 수 있는지가 결정됩니다.
이것이 Goooo가 Hermes나 OpenClaw와 같은 오픈소스 인프라를 지속적으로 채택하고 있는 중요한 이유입니다. 오픈소스 커뮤니티는 Agent의 범용적인 실행 능력을 지속적으로 개선하고, Goooo는 이벤트 인식, 시맨틱 얼라인먼트(Semantic alignment), 확률 분석, 크로스 마켓 비교, 실행 라우팅, 리스크 관리 등 예측 시장 그 자체에 더 많은 리소스를 집중할 수 있습니다.
이러한 역할 분담을 통해 Goooo는 새로운 모델, 새로운 데이터 소스, 새로운 시장에 더욱 신속하게 연결될 수 있으며, 동시에 기반 에코시스템의 진화에 맞춰 시스템 운영 효율을 지속적으로 향상시킬 수 있습니다.
Gooo의 장기적인 목표는 글로벌 예측 시장을 연결하는 지능형 조정·실행 레이어(Layer)를 구축하는 것입니다. 예측 시장이 계속 성장함에 따라 동일한 이벤트가 여러 플랫폼에 동시에 존재하게 됩니다. 각각의 시장은 고유한 사용자 구조, 유동성, 가격 수준, 결제 규칙을 가지고 있습니다. 사용자가 진정으로 필요로 하는 것은 이러한 차이를 이해하고, 여러 시장 간의 분석, 비교, 실행을 완료할 수 있는 통합 시스템입니다.
AI Agent는 이 시스템에서의 핵심적인 실행 유닛(Execution unit)입니다. 실시간 정보를 읽고, 이벤트 변화를 이해하며, 다양한 데이터와 도구를 호출하고, 다른 Agent와 연계하면서 최종적인 의사결정을 완성합니다. Agent 인프라가 성숙해짐에 따라, 이 능력은 단일 태스크 실행에서 장기간 가동 가능한 멀티 마켓형 지능형 네트워크로 발전해 나갈 것입니다.
Quicksilver Release는 Agent 인프라가 새로운 발전 단계로 나아가고 있음을 보여줍니다. Hermes는 Agent 실행 프레임워크에서 복잡한 비즈니스 시스템을 뒷받침할 수 있는 범용 인프라로 점진적으로 진화하고 있습니다.
Hermes 커뮤니티가 지속적으로 진화함에 따라, 더 많은 기반 기능이 Goooo의 기술 체계에 도입되어 더 많은 예측 시장과의 연결, 더 많은 전략 운영, 그리고 더 복잡한 예측·실행 태스크에 대한 대응을 지원할 것입니다.
Nous Research와 Hermes 커뮤니티 전체의 Quicksilver Release 완성을 축하합니다. Goooo는 앞으로도 이러한 기술적 진전을 활용하여 글로벌 예측 시장을 향한 인텔리전트 분석·실행 네트워크의 발전을 계속해 나갈 것입니다.
Goooo.io에 접속하여 Goooo 시스템에 대해 더 자세히 확인해 보세요.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기