Automata V.20 | 🤘아시아 최초로 열린 Hermes Agent 세션에 다녀왔어요!

출처: Automata 직접 촬영 - Hemres Agent 세션 포스터

지난 토요일 (2026년 5월 9일), Sionic AI와 Nous Research가 공동 주최한 아시아 최초 Hermes Agent 커뮤니티 모임에 다녀왔습니다. 천 명이 넘는 지원자 중 200명 정도만 추첨으로 선발되는 자리였는데, 운 좋게 그 안에 들 수 있었어요. 행사에는 Hermes Agent를 직접 활용하고 있는 빌더 18명이 모여 각자의 경험과 인사이트를 발표해 주셨어요. 주말임에도 이렇게 많은 분들이 시간을 내주셨다는 것 자체가, Hermes Agent에 대한 관심이 얼마나 뜨거운지를 보여주는 것 같았습니다.

오늘 뉴스레터에서는 여러 세션들 중 인상 깊었던 발표들을 소개해 드릴게요.

듣는 웹에서 협업하는 웹으로

김찬홍님 발표

김찬홍님이 Hermes Agent로 시각장애인이 어떻게 손쉽게 쿠팡에서 선물을 고를 수 있는지 시연하고 있다.

시각장애인이 웹 브라우저를 사용하는 방법을 직접 본 적 있으신가요? 시각장애인 연구자 김찬홍님의 시연을 보면서 느낀 건, 생각보다 훨씬 고단한 과정이라는 거였어요. 기존 웹페이지는 철저히 보는 사람 기준으로 설계되어 있기 때문에, 시각장애인은 VoiceOver 같은 스크린 리더에 의존해 웹 엘리먼트를 하나하나 탐색하며 버튼이나 입력창을 찾아야 해요. 원하는 정보 하나를 얻기 위해 수십 번 탭을 누르고, 읽히는 텍스트를 귀로 추적해야 하는 이 방식은 생산성 측면에서 큰 병목이 됩니다.

Hermes Agent가 이 문제에 의미 있는 해답이 될 수 있다는 걸 이번 발표를 통해 알게 됐어요. Hermes Agent는 기본 기능으로 STT(음성→텍스트)와 TTS(텍스트→음성)를 모두 지원하는데, 이를 활용하면 시각장애인이 하고 싶은 작업을 말로 설명하는 것만으로 에이전트가 브라우저를 열고, 검색하고, 정보를 취합해 정돈된 결과를 다시 음성으로 읽어줄 수 있어요. 더 흥미로운 시사점은, 에이전트가 잘 접근하고 조작할 수 있는 웹/앱 구조가 곧 장애인 접근성이 높은 구조와 일치한다는 점이에요. 에이전트 친화적인 웹을 만드는 것 자체가 모두를 위한 접근성을 높이는 방향으로 수렴하고 있는 겁니다. AI 에이전트의 발전이 기술적 혁신에 그치지 않고 사회적 선순환으로 이어질 수 있다는 걸 이번 사례가 잘 보여줬어요.

Ouroboros with Hermes Agent

나정환님 / 이재규님 발표

출처: Q00/ouroboros Github repository

바이브 코딩이나 에이전트에게 일을 시킬 때 "어떻게 질문해야 최적의 결과가 나올까?"와 "에이전트가 멋대로 결정하는 걸 어떻게 막을까?" 와 같은 고민해본 적 있지 않나요? 작은 작업이라면 그냥 다시 시키면 되지만, 규모 있는 프로젝트를 에이전트와 함께 진행할 때는 프롬프트 구체화 문제와 할루시네이션 문제가 동시에 발목을 잡아요. 이재규님이 오픈소스로 개발한 Ouroboros는 이 두 문제를 겨냥한 Agent OS예요. "Stop prompting. Start specifying." — 즉흥적인 프롬프팅을 멈추고, 명세부터 시작하라는 거죠. Hermes Agent를 포함한 다양한 런타임 (Claude Code, Codex CLI, OpenCode 등)위에서 동일한 워크플로우 명세로 동작하는 추상화 레이어에요.

Ouroboros는 계획 수립 자체를 수학적으로 검증 가능한 단계로 정형화해요. 첫 번째 단계인 Socratic Interview에서 전담 에이전트가 절대 코드를 만들지 않고 "당신은 지금 무엇을 가정하고 있나요?"만 캐물어요. "태스크 CLI를 만들고 싶어요"라는 막연한 요청이 "태스크란 무엇인가? 삭제 가능한가, 아카이브 가능한가? 개인용인가, 팀용인가?"라는 세부적인 질문으로 파고들며 기존 프롬프를 구체화하는 작업을 거쳐요. 이 과정에서 내가 생각하지도 못한 질문을 맞닥드리게 될 수 있어요. 이 과정은 감으로 끝나는 게 아니라 수식으로 측정되고, 모호성 점수 (Ambiguity Score)가 0.2 이하로 떨어져야만 다음 단계로 넘어가요.

출처: https://rmathd23.tistory.com/65 - 더블 다이아몬드 프로세스

명확성이 확보되면 프로젝트 관련 디테일한 정보가 담긴 Seed를 생성하여 Double Diamond 시스템이 작동하는데, Ouroboros는 이걸 두 단계로 분리해요. ① 첫 번째 다이아몬드는 태스크 관련 질문을 발산(Discover) → 명료성으로 수렴(Define)하고, ② 두 번째 다이아몬드는 설계 옵션을 발산(Design) → 검증된 산출물로 수렴(Deliver)해요. "이해하지 못한 것을 설계할 수 없다"는 원칙을 기반으로 Ouroboros는 아주 체계적으로 에이전트가 결과물을 수행해 나가게 하는거죠.

정리하면, AI 코딩의 병목은 모델의 성능이나 하네스보단, 사용자의 불분명한 프롬프트가 병목이라는 점이에요. 그리고 그 병목을 Ouroboros가 해결해 주는거죠.

Karpathy LLM Wiki: Hermes로 만드는 복리형 에이전트

김효열님 발표

수많은 논문을 에이전트에게 던져주고, "이 분야의 핵심 트렌드가 뭐야?"라고 물어본 적 있으신가요? 이런 방식을 흔히 RAG라고 하죠. LLM이 그럭저럭 답을 내놓긴 하지만, 다음 날 같은 질문을 다시 던지면 어제와 미묘하게 다른 답이 돌아옵니다. 어제 힘들게 파악한 논문 간의 관계, 모순되는 주장들, 교차 참조 포인트들... RAG시스템은 이 모든 걸 기억하지 못해요.

RAG는 구조적으로 매 쿼리마다 백지에서 다시 시작하는 시스템이기 때문입니다. 문서를 청크로 쪼개고, 벡터로 검색하고, 그때그때 답을 합성하는 방식은 단순한 질문엔 잘 작동하지만, 수십 개 문서를 가로지르는 심층 분석이나 시간이 지나도 누적되어야 하는 리서치 작업엔 근본적인 한계가 있습니다. Andrej Karpathy는 이 문제를 해결하기 위해 LLM Wiki라는 솔루션을 제안했아요. RAG처럼 매번 원본 문서에서 답을 끌어내는 대신, LLM이 소스를 읽고 직접 구조화된 위키 페이지로 합성해서 저장해두는 것입니다. Karpathy는 이를 소프트웨어 컴파일에 빗댑니다. "파일은 재료고, LLM Wiki는 완성된 요리입니다. RAG는 배고플 때마다 매번 요리하는 것"이라고 표현합니다. 한 번 컴파일된 지식은 교차 참조와 모순이 이미 정리된 상태로 존재하고, 이후 모든 쿼리는 이 위에서 작동합니다.

LLM Wiki는 세 가지 핵심 기능으로 운영되요.

Ingest(수집·합성): 새로운 소스(문서, 논문, 링크 등)가 들어오면 LLM이 이를 읽고 핵심 개념을 추출해 wiki/ 디렉터리 안의 마크다운 페이지로 작성하거나 기존 페이지를 업데이트합니다. 단순 저장이 아닌 다른 문사와의 교차 참조와 모순 감지까지 수행하는 단계예요.
Query(질의): 사용자가 질문하면 LLM은 원본 파일이 아닌 이미 정리된 위키 페이지를 기반으로 답변을 생성하고, 유의미한 통찰이 나오면 이를 새 위키 페이지로 다시 저장해 지식이 축적됩니다.
Lint(유지보수): 주기적으로 위키 전체를 감사해 고아 페이지(다른 문서들과 연관이 없는 페이지/문서), 모순되는 주장, 언급만 되고 페이지가 없는 개념 등을 탐지하고 정리합니다.

개인 지식 위키 관리 작업을 LLM이 대신하는 셈입니다. 전체 구조는 raw/(불변 원본) → wiki/(LLM 유지 관리 지식) → CLAUDE.md/AGENT.md(운영 스키마)의 3계층으로 설계되어 있어요. Hermes Agent는 이 LLM Wiki 패턴을 빌트인 스킬로 기본 탑재하고 있어서, 별도 설정 없이 Hermes Agent에서 바로 LLM Wiki를 사용할 수 있어요. 개인 위키를 어디서 관리할지를 나타내는 WIKI_PATH 환경 변수만 지정하면 에이전트가 질문과 입력 문서에 따라 Ingest·Query·Lint 전 과정을 자율적으로 수행해줍니다.

여기저기 흩어져 있는 지식이나 문서들을 한 곳에서 관리하며, 각 문서간의 연관성을 연결해 새로운 아이디어를 창출해보고 싶으면, 원하는 에이전트와 함께 LLM Wiki를 한번 사용해 보는것을 추천드려요.