OpenClaw 를 버리고 Hermes 로 간 이유

지난 편에서, 브레인에 MCP 를 달고, 에이전트가 창고에 쓰는 손을 얻었다고 했다. 그런데 그 이야기에는 전제가 하나 숨어 있다. 창고를 쓰는 쪽, 즉 에이전트가 제대로 서 있어야 한다는 전제다. 3부가 묻는 것은 창고를 쓰는 쪽이 누구인가인데, 그 쪽을 통째로 갈아탄 일이 이 편의 중심이다. MCP 가 붙은 뒤로 얼마 지나지 않아, 에이전트 플랫폼을 OpenClaw 에서 Hermes 로 바꿨다. 이유는 하나, 남의 버그였다. 지난 편 끝에서 예고한, 겉으로는 읽는 일을 하는 것처럼 보이면서 뒤에서 사람의 몫을 하던 도구들의 이야기는 그다음 편에서 풀기로 하고, 이 편은 그 도구들이 달려 있던 플랫폼의 이야기다. 하나씩 보자.

게이트웨이와 페어링

그때까지 에이전트 플랫폼으로 쓰던 것은 OpenClaw 였다. 게이트웨이가 중심에 있고, 그 주위에 디바이스들이 웹소켓으로 붙는 구조다. Slack 브리지도 그 게이트웨이 위에 얹혀서, 슬랙의 메시지를 에이전트로 흘려보냈다. 연구실의 대화는 슬랙에서 오가니, 그 자리에서 창고에 물어볼 수 있게 하려는 것이었다. 내 짐작이지만, 그 목적이 브리지를 들인 이유였을 것이다.

 

디바이스는 하나하나 페어링으로 등록된다. 진단 명령을 돌려보면, 등록된 디바이스가 다섯 대였다. 맥의 CLI 하나, 리눅스의 CLI 하나, 윈도우와 맥의 웹채팅 각 하나, 그리고 맥북 하나가 노드와 운영자 역할을 겸했다. 토큰마다 역할과 scopes 가 붙고, 운영자에게는 관리와 승인과 페어링 권한이 주어졌다. 페어링이라는 절차가 이 플랫폼의 일상이었다.

 

 

유월 초의 진단 기록을 보면, 이 플랫폼은 이미 그때부터 삐걱거리고 있었다. 진단은 게이트웨이가 안 돌고 있다고 말하면서, 같은 화면의 아래쪽에서는 게이트웨이가 돌고 있다고 말했다. 같은 진단 안에서 서로 모순된 보고가 나온 것이다. 게이트웨이 같은 서비스도 두 개가 잡혔는데, 하나는 게이트웨이 이름의 등록 서비스였고, 다른 하나는 또 다른 이름의 것이었다. 문서는 이렇게 적고 있었다. 한 기계에는 게이트웨이를 하나만 두라고. 두 개가 같은 자격증명을 두고 충돌할 수 있다는 뜻이었다. 진단은 또, 메모리 검색이 켜져 있는데 임베딩 제공자가 없어서 의미검색이 동작하지 않을 것이라는 경고도 함께 내놓았다. 게이트웨이는 버전 관리자에 들어 있는 Node 로 돌고 있었는데, 문서는 그 버전이 올라가면 게이트웨이가 깨질 수 있다고 경고했다. 기능이 요구사항을 채운 것은 열네 개였고, 요구사항이 빠진 것은 서른셋이었다. 플러그인은 여섯 개가 올라와 있고 서른 개가 꺼져 있었는데, 오류는 하나도 없었다. 오류가 없다는 말이 잘 돌아간다는 말은 아니었던 셈이다. 켜져 있는 것과 동작하는 것이 다르다는 그 문장은, 이 시리즈가 나중에 온몸으로 겪을 주제를 이미 예고하고 있었다.

 

 

pairing required

문제는 그 페어링에서 났다. 어느 날 Slack 브리지가 연결을 거부하기 시작했다. 이유는 한 줄, pairing required. 게이트웨이 쪽에서 보면, 이 디바이스는 아직 페어링이 안 된 것처럼 보였다. 등록된 디바이스 목록에는 분명히 다섯 대가 있고, 그중 슬랙과 통하는 쪽의 토큰도 살아 있는데도, 연결만 하면 페어링이 필요하다고 되돌아왔다.

 

그때부터가 삽질이었다. 로컬에서 승인을 눌러도 소용없었고, 토큰을 다시 받아도 소용없었다. 진단 명령도, 게이트웨이 재시작도, 전부 무효였다. 꺼져 있는 기기가 같은 슬랙 자격증명을 점유해 충돌했다는 사실도 이 무렵의 기록에 남아 있는데, 그 충돌이 어떻게 해서 페어링 오류까지 이어졌는지는 기록에 없어서, 여기서는 충돌이 있었다는 사실만 남겨두고 메커니즘은 짐작으로 채우지 않는다.

 

 

이 버그의 안쪽이 왜 그랬는지도 모른다. 고쳐야 할 대상이 남의 코드였고, 그 코드는 내가 열어볼 수 있는 구석이 마땅치 않았다. 시도해 볼 수 있는 것은 다 해봤고, 그 시도들이 전부 무효였다는 것만 기록에 남아 있다. 남의 코드의 버그는, 내 코드의 버그와 다르다. 내 코드는 열어서 고칠 수 있지만, 남의 코드는 그 안쪽을 모른 채 시도만 반복하게 된다.

 

플랫폼을 붙들고 있던 마지막 시도도 그 무렵에 있었다. 칠월 초의 기록에는, OpenClaw 위에서 로컬 vLLM 을 붙이느라 타임아웃과 재시도 사이를 오간 흔적이 남아 있다. 한 번 타임아웃이 나면 그 제공자는 일정 시간 요청을 거부하는 상태로 들어가고, 재시도 없이 게이트웨이를 통째로 재시작해야 풀린다. 추론 설정을 낮추고, 요청 타임아웃을 늘리고, 그렇게 한 바퀴를 다 돌아도 뭔가가 매번 어딘가에서 걸렸다. 도구 하나를 붙이는 일이 이렇게 험하면, 플랫폼 자체가 문제라는 생각이 들 수밖에 없다.

구조로 회피하는 쪽으로

교체를 검토한 것은 그 무렵이다. 다른 플랫폼이 궁금해서가 아니라, 이 버그가 이 플랫폼의 구조에서 나온 것인지가 궁금했다. Hermes 를 들여다보니, 페어링이라는 개념 자체가 없었다. 디바이스를 등록하고 토큰을 승인하는 단계가 아예 없다. 인증의 설계가 다르니, 페어링 버그가 설계상 생길 자리가 없다.

 

이 대목이 이 편의 핵심이다. 똑같은 버그를 만났을 때, 패치로 고치는 것과 설계로 회피하는 것은 다르다. 패치는 그 버그가 또 나오면 다시 고치면 되지만, 설계로 회피하면 그 버그가 설계상 존재하지 않으므로 다시 만날 일 자체가 없다. OpenClaw 의 페어링 버그는 고칠 수 없었고, Hermes 에는 고칠 페어링 버그가 애초에 없었다. 고칠 수 없는 버그를 만났을 때 우회로를 찾는 대신, 구조가 다른 쪽으로 옮기는 선택, 그것이 이 전환의 내용이었다.

 

전환은 그렇게 순식간에 끝났다. 칠월 첫째 주의 기록에는 OpenClaw 위에서 로컬 vLLM 을 붙이느라 애쓰던 흔적이 남아 있고, 그다음 주의 기록에는 Hermes 가 원격 서버의 모델을 메인으로 물고 있다. 그 사이 어느 날 플랫폼이 바뀌었던 것이다. 정확한 날짜는 기록에 없어서, 이 둘 사이였다는 것만 남겨둔다. 브레인의 MCP 도 브레인 쪽 코드가 표준이라 그대로 살아남았고, 창고를 쓰는 손은 플랫폼이 바뀌어도 같은 모양으로 붙어 있었다.

 

 

조용히 거부하는 기본값

Hermes 로 옮기고 나서도 삽질이 하나 더 있었다. Slack 브리지가 메시지를 받고도 대답하지 않았다. 연결이 안 된 것처럼 보였다. 그런데 이상한 점은, 메시지에 입력 표시가 떠 있다는 것이었다. 받기는 하는데, 대답만 안 하는 상태였다. 연결 문제라면 입력 표시조차 안 떠야 하는데, 입력 표시가 뜨니까 어딘가에서 요청이 받아지고 있다는 뜻이었다.

 

원인은 설정의 기본값이었다. Hermes 의 보안 기본값은, 허용 목록, allowlist 가 비어 있으면 외부에서 온 요청을 전부 거부한다. 거부인데, 조용히 거부다. 메시지는 받고, 입력 표시는 치고, 그다음이 없다. 오류도 로그도 남기지 않으니, 네트워크 쪽을 먼저 의심하게 된다. 연결을 확인하고, 재시작하고, 그러고도 대답이 없어서 이번에는 설정을 열어보았고, 그제서야 허용 목록이 비어 있다는 것을 발견했는데, 거부가 조용해서 오류 로그가 없었으니 원인을 찾는 데 그만큼 시간이 걸렸다. 허용 목록에 채널을 넣으니 그제서야 대답이 돌아왔다. 죽었는지 살았는지 알 수 없는 채로 조용히 거부당하는 상태, 그것이 이 삽질에서 제일 고약한 부분이었다. 차라리 큰 소리로 거절해 주는 편이 나았다.

 

결론 대신

돌아보면, 이 전환에서 가장 시간이 아깝지 않았던 결정은 버그를 고치려는 시도를 그만둔 것이었다. 로컬 승인, 토큰 재발급, 진단, 재시작, 그 모두가 무효였고, 무효임을 확인하는 데 쓴 시간이 플랫폼을 통째로 바꾸는 시간보다 길었다. 이 전환의 전후로 남아 있는 기록은 진단 출력과 세션 기록 몇 개뿐이라, 시도한 순서나 그날의 심경 같은 것은 기록이 남긴 것만 썼다. 기억은 기록이 아니어서, 이 편에서는 기억만으로 채운 자리에 짐작이라는 말을 붙였다. 고칠 수 없는 남의 버그를 만났을 때, 우회가 아니라 교체가 답인 경우가 있다. 이 편의 결론은 그것 하나다.

 

브리지는 Hermes 위에서 다시 살아났고, 그다음 문제는 다른 곳에서 나타났다. 대답이 오는 데 걸리는 시간이었다. 받아들이고 나서야 보인 것이지만, 플랫폼을 바꾸는 일은 그 자체로 끝이 아니라, 그 위에서 문제가 어디서 나는지가 달라지는 일이었다. 그 이야기는 다음 편에서 풀어야겠다.