우리는 또 다른 AI Wrapper를 원하지 않았습니다 — 그래서 엔지니어링 팀을 위한 고속 Hermes

이 글은 Hermes Agent Challenge를 위한 제출물입니다.

우리의 목표는 또 다른 AI Wrapper (Wrapper)를 만드는 것이 아니라, 실제 엔지니어링 거버넌스 (Governance) 워크플로우 내에서 전문화된 자율 작업자 (Autonomous Workers)들을 조정하는 지속적인 오케스트레이션 레이어 (Orchestration Layer)로서 Hermes Agent가 어떻게 작동하는지 탐구하는 것이었습니다.

오늘날 대부분의 AI 시스템은 여전히 근본적으로 더 나은 인터페이스 안에 감싸진 싱글 스레드 (Single-threaded) 어시스턴트입니다.
프롬프트 (Prompt)를 입력하면 모델이 응답하고, 거기서 워크플로우가 끝납니다.

하지만 우리의 문제는 달랐습니다.

지난 몇 년 동안 우리는 동문 그룹, 비즈니스 운영자, SaaS 플랫폼, 그리고 커뮤니티 엔지니어링 팀들과 긴밀히 협력해 왔습니다. 한 가지 반복되는 문제가 모든 곳에서 나타났습니다:

사람들은 단순히 AI가 생성한 텍스트를 원하는 것이 아니었습니다.
그들은 워크플로우 인텔리전스 (Workflow Intelligence)를 원했습니다.

그들은 다음과 같은 능력을 갖춘 시스템을 원했습니다:

• 기술적 작업 조정 (Coordinating technical tasks),
• 운영 리스크 평가 (Evaluating operational risks),
• 실행 흐름 계획 (Planning execution flows),
• 구조화된 엔지니어링 결정 합성 (Synthesizing structured engineering decisions),
• 그리고 여러 자율 작업자 (Autonomous Workers)에 걸쳐 안정적으로 작동하는 능력.

그 깨달음은 결국 우리를 Hermes Agent로 이끌었습니다.

또 다른 챗봇 (Chatbot)을 원해서가 아니었습니다.

오케스트레이션 (Orchestration)을 탐구하고 싶었기 때문입니다.

핵심 아이디어 (The Core Idea)

우리는 스스로에게 간단한 질문을 던지기 시작했습니다:

Hermes가 대화형 어시스턴트처럼 행동하는 것을 멈추고, 관리형 오케스트레이션 레이어 (Managerial Orchestration Layer)처럼 행동하기 시작하면 어떤 일이 벌어질까?

그 질문이 우리 실험의 토대가 되었습니다.

그 결과물은 Gotihub Hermes Crew였습니다.

이 이름 자체에 프로젝트 뒤에 숨겨진 철학이 담겨 있습니다.

Gotihub는 **속도 (Speed)**를 의미하는 벵골어 단어 Goti (গতি)에서 유래되었습니다.

우리는 자율적인 엔지니어링 작업자들이 실제 거버넌스 (Governance) 워크플로우 내에서 빠르고, 신뢰할 수 있으며, 구조적으로 조정될 수 있는지 탐구하고 싶었습니다.

그 결과, Hermes에 의해 조정되는 전문화된 자율 작업자들을 통해 GitHub 리포지토리 (Repositories)를 분석할 수 있는 고속 멀티 에이전트 (Multi-agent) 엔지니어링 오케스트레이션 시스템이 탄생했습니다.

프로젝트 링크 (Project Links)

라이브 데모 (Live Demo)

https://crew.gotihub.com

GitHub Repository

https://github.com/apurba-labs/gotihub-hermes-crew

왜 우리는 단일 모놀리식 에이전트 (Single Monolithic Agent)를 원하지 않았는가

다음 사항들을 처리하는 하나의 거대한 프롬프트 창 (Prompt Window)은:

• 보안 분석 (Security analysis),
• 아키텍처 감사 (Architecture auditing),
• 로드맵 계획 (Roadmap planning),
• 그리고 경영진용 종합 보고 (Executive synthesis)

빠르게 비용이 많이 들고, 불안정해지며, 제어하기 어려워집니다.

따라서 하나의 모델이 모든 것을 동시에 생각하도록 강요하는 대신, 우리는 다음과 같이 분리했습니다:

실행 (Execution)과 거버넌스 (Governance)의 분리

실행 계층 (Execution Layer)

특화된 Gemma 워커 (Workers)들이 집중된 엔지니어링 작업들을 독립적으로 수행합니다.

거버넌스 계층 (Governance Layer)

Hermes가 해당 워커들이 생성한 결과물들을 조정(Coordinate), 종합(Synthesize) 및 관리(Manage)합니다.

이러한 분리는 프로젝트에서 가장 중요한 아키텍처 결정이 되었습니다.

멀티 에이전트 아키텍처 (The Multi-Agent Architecture)

우리의 오케스트레이션 파이프라인 (Orchestration pipeline)은 네 가지 주요 단계를 따릅니다:

1. SecurityAgent가 리포지토리 보안 분석을 수행합니다.
2. ArchitectureAgent가 구조적 및 유지보수 가능성 상태를 평가합니다.
3. PlanningAgent가 엔지니어링 로드맵 권장 사항을 생성합니다.
4. Hermes Master가 모든 것을 구조화된 관리 보고서로 종합합니다.

중요한 세부 사항은 첫 번째 단계가 병렬로 실행된다는 점입니다.

우리는 순차적인 블로킹 파이프라인 (Sequential blocking pipelines) 대신, 의도적으로 Python의 네이티브 비동기 실행 모델 (Asynchronous execution model)을 사용했습니다.

asyncio.gather를 이용한 1단계 병렬성 (Stage 1 Concurrency)

첫 번째 오케스트레이션 계층은 여러 특화된 워커들을 동시에 실행합니다:

• SecurityAgent
• ArchitectureAgent

두 에이전트 모두 asyncio.gather() 오케스트레이션 블록 내에서 실행됩니다.

이를 통해 우리는 다음과 같은 요소들을 탐구할 수 있었습니다:

• 병렬 리포지토리 분석 (Concurrent repository analysis),
• 격리된 엔지니어링 책임 (Isolated engineering responsibilities),
• 그리고 구조화된 작업 전문화 (Structured task specialization).

AI를 하나의 거대한 컨텍스트 창 (Context window)으로 취급하는 대신, 우리는 이를 조정된 엔지니어링 크루 (Engineering crew)처럼 취급했습니다.

시스템 워크플로우 아키텍처 (System Workflow Architecture)

다음은 시스템을 구동하는 오케스트레이션 워크플로우입니다:

워크플로우는 의도적으로 다음과 같이 분리되었습니다:

• 병렬 실행 (concurrent execution),
• 계획 합성 (planning synthesis),
• 그리고 실행 오케스트레이션 (executive orchestration).

이러한 구조를 통해 통합된 엔지니어링 보고서를 생성하면서도 각 책임 영역을 격리된 상태로 유지할 수 있었습니다.

오케스트레이터 (Orchestrator)로서의 Hermes

이 지점이 바로 Hermes가 진정으로 흥미로워지는 부분입니다.

우리의 아키텍처에서 Hermes는 원시 저장소 (raw repositories)를 직접 파싱하지 않습니다.

대신, Hermes는 관리적 합성 계층 (managerial synthesis layer)처럼 동작합니다.

워커 에이전트 (worker agents)는 다음을 생성합니다:

• 요약 (summaries),
• 이슈 보고서 (issue reports),
• 신뢰도 점수 (confidence scores),
• 엔지니어링 권장 사항 (engineering recommendations).

그 후 Hermes는 다음을 수행합니다:

• 중복 해결 (resolves overlap),
• 에이전트 간 결론 합성 (synthesizes cross-agent conclusions),
• 실행 요약 생성 (generates executive summaries),
• 그리고 구조화된 JSON 출력 생성 (produces structured JSON outputs).

다시 말해:

워커는 실행하고,
Hermes는 통제합니다.

이러한 오케스트레이션 철학은 우리가 에이전트 시스템 (agent systems)에 접근하는 방식을 완전히 바꾸어 놓았습니다.

멀티 서브도메인 인프라 설계 (Multi-Subdomain Infrastructure Design)

시스템이 진화함에 따라, 우리는 오케스트레이션 아키텍처만으로는 충분하지 않다는 것을 깨달았습니다.

인프라 분리 (infrastructure separation) 또한 필요했습니다.

따라서 우리는 여러 서브도메인과 격리된 라우팅 계층을 사용하여 생태계를 배포했습니다:

• gotihub.com → 기업 사이트 (corporate site)
• agl.gotihub.com → SaaS 엔진 (SaaS engine)
• crew.gotihub.com → Hermes 오케스트레이션 플랫폼 (Hermes orchestration platform)

백엔드에서는 다음과 같이 작동합니다:

• FastAPI가 오케스트레이션을 처리하고,
• Docker가 런타임 격리 (runtime isolation)를 관리하며,
• Nginx가 인그레스 트래픽 (ingress traffic)을 라우팅하고,
• Ollama가 로컬 추론 (local inference)을 구동하며,
• Hermes가 합성 계층 (synthesis layer)을 조정합니다.

가장 중요한 점은:

추론 백본 (inference backbone)은 공용 인터넷에 직접 노출되지 않았다는 것입니다.

내부 AI 백본 아키텍처 (Internal AI Backbone Architecture)

배포 토폴로지 (deployment topology)는 경량 오케스트레이션 메시 (lightweight orchestration mesh)에 더 가까운 형태로 진화했습니다:

이를 통해 여러 서비스가 다음을 공유할 수 있었습니다:

• 하나의 중앙 집중식 추론 코어 (centralized inference core),
• 격리된 애플리케이션 라우팅 (isolated application routing),
• 그리고 내부 전용 AI 통신 (internal-only AI communication).

우리가 직면한 실제 엔지니어링 문제들

이 프로젝트는 순탄하지 않았습니다.

그리고 솔직히 말해서, 바로 그 지점에서 대부분의 배움이 일어났습니다.

로컬 컴퓨팅 병목 현상 (The Local Compute Bottleneck)

우리의 초기 오케스트레이션 실행은 매우 느렸습니다.

한 실제 텔레메트리 (telemetry) 세션은 다음과 같았습니다:

[TELEMETRY] GitHubLoader가 5.91초 만에 8개의 파일을 가져왔습니다.

[Orchestrator] 전체 파이프라인 시작 중...
...

병목 현상은 오케스트레이션이 아니었습니다.

그것은 다음과 같았습니다:

• 과도하게 큰 리포지토리 컨텍스트 (repository context),
• 로컬 추론 지연 시간 (local inference latency),
• 장황한 프롬프트 체인 (verbose prompt chains),
• 그리고 거대한 토큰 생성 오버헤드 (massive token generation overhead).

이 차이는 중요했습니다.

왜냐하면 이는 아키텍처 자체는 확장 가능하다는 것을 의미했지만, 추론 전략 (inference strategy)은 최적화가 필요하다는 뜻이었기 때문입니다.

우리가 최적화한 것들

우리는 결국 다음과 같은 방식으로 런타임 (runtime)을 개선하기 시작했습니다:

• 리포지토리 컨텍스트 크기 축소,
• 중요한 엔지니어링 파일 우선순위 지정,
• 불필요한 토큰 생성 제한,
• 합성 페이로드 (synthesis payloads) 축소,
• 그리고 비동기 오케스트레이션 경계 (async orchestration boundaries) 개선.

모든 파일을 동일하게 취급하는 것을 중단하자 시스템은 극적으로 더 안정적이 되었습니다.

방어적 실패 엔지니어링 (Defensive Failure Engineering)

가장 중요한 교훈 중 하나는 구조화된 출력 (structured output) 실패에서 왔습니다.

대규모 오케스트레이션 체인은 가끔 다음과 같은 결과를 반환했습니다:

• 잘못된 형식의 JSON (malformed JSON),
• 부분적인 합성 블록 (partial synthesis blocks),
• 또는 불완전한 매니저 응답 (incomplete manager responses).

파이프라인의 붕괴를 허용하는 대신, 우리는 다음을 추가했습니다:

• 폴백 실행 경로 (fallback execution paths),
• JSON 클린업 레이어 (JSON cleanup layers),
• 방어적 파싱 (defensive parsing),
• 그리고 구조화된 실패 복구 (structured failure recovery).

이는 우리가 프롬프트 엔지니어 (prompt engineers)보다는 시스템 엔지니어 (systems engineers)처럼 생각하도록 강제했습니다.

Hermes가 실제로 잘 작동했던 이유

CrewAI와 같은 프레임워크는 대화형 에이전트 파이프라인 (conversational agent pipelines)을 빠르게 조립하는 데 매우 뛰어납니다.

하지만 우리의 탐구는 약간 다른 부분에 집중했습니다:

• 지속적인 오케스트레이션 (persistent orchestration),
• 구조화된 엔지니어링 출력 (structured engineering outputs),
• 거버넌스 중심의 워크플로 (governance-oriented workflows),
• 그리고 격리된 작업자 책임 (isolated worker responsibilities).

우리는 Hermes가 대화형 어시스턴트처럼 작동하기보다는 엔지니어링 조정 레이어 (engineering coordination layer)처럼 작동하기를 원했습니다.

그 차이점이 이 프로젝트의 전체 철학이 되었습니다.

우리를 가장 매료시킨 것

가장 흥미로운 부분은 AI가 텍스트를 생성할 수 있는지 여부가 아니었습니다.

자율적인 작업자 (autonomous workers)들이 실제 운영 시스템 내부에서 신뢰할 수 있게 협업할 수 있는지 여부였습니다.

그것은 대화의 흐름을 완전히 바꿉니다.

다음과 같이 묻는 대신:

“AI가 질문에 답할 수 있는가?”

우리는 다음과 같이 묻기 시작했습니다:

“AI 작업자들이 엔지니어링 거버넌스 워크플로 (engineering governance workflows) 내부에서 책임감 있게 협업할 수 있는가?”

Hermes는 우리가 그 미래를 탐구할 수 있는 실질적인 방법을 제공했습니다.

그리고 솔직히 말해서, 그 탐구는 단순히 또 다른 AI 래퍼 (AI wrapper)를 만드는 것보다 훨씬 더 가치 있는 일이 되었습니다.

구축 기술

• Hermes Agent
• FastAPI
• Python AsyncIO
• Ollama
• Gemma 3
• Docker
• Nginx
• SQLite
• Next.js

마치며

이 프로젝트는 여전히 진화하고 있습니다.

우리는 다음과 같은 요소들을 적극적으로 최적화하고 있습니다:

• 오케스트레이션 런타임 (orchestration runtime),
• 추론 효율성 (inference efficiency),
• 스트리밍 텔레메트리 (streaming telemetry),
• 구조화된 합성 (structured synthesis),
• 그리고 거버넌스 신뢰성 (governance reliability).

하지만 우리가 배운 가장 큰 사실은 이것입니다:

자율 시스템은 고립된 챗봇처럼 행동하는 것을 멈추고, 조정된 엔지니어링 작업자처럼 행동하기 시작할 때 진정으로 흥미로워진다.

그것이 우리가 Hermes를 통해 탐구하고자 했던 미래입니다.

그리고 우리는 그 미래를 향해 계속해서 구축해 나갈 생각에 설렙니다.