Hermes 이틀 사용 후 개발자가 느낀 다소 섬뜩한 경험

먼저 배경을 좀 설명하자면, 나는 백엔드 개발자이고 십여 년의 백엔드 개발 경력이 있으며, 평소에 각종 AI 코딩 도구를 다뤄서 Cursor, Claude Code 모두 써봤다. 얼마 전 업계에서 다들 "새우 키우기"(OpenClaw)를 이야기하길래 한바탕 해봤지만, 별 실용적인 응용은 없었다. 그 바람이 지나가자 "말"이 또 나왔고, 나는 유행을 따라 Hermes를 시험해봤다. 국내에서는 다들 "귀족마"라고 부르는데, 아이콘이 날개 달린 말 머리라 꽤 외우기 쉽다.

이걸 한동안 써봤는데, 다른 건 별로 놀랍지 않았다. 그러다 어느 날 밤 내가 오래된 프로젝트의 버그를 고치다가, 김에 그것에게 "이 함정 좀 기억해둬"라고 하고는 잠들었다. 다음 날 아침 내가 입도 떼기 전에, 그것이 어제 그 함정의 해결 단계를 고스란히 새 세션의 맨 앞에 붙여둔 것이었다.

그 순간 나는 마음속으로 철렁했다.

이건 기억력이 좋은 문제가 아니다. 이건 그것이 스스로 자신을 위해 운영 매뉴얼을 작성한 것이고, 심지어 내가 예전에 위키에 적어둔 것보다도 더 명확하게 썼다.

이때서야 귀족마의 이 skill 시스템이, 내가 생각하기에 가장 저평가된 부분이라는 걸 알게 됐다. 오늘은 까지도 않고 치켜세우지도 않고, 이것에 대해 이야기해보려 한다.

먼저 내가 전에 계속 잘못 알고 있던 것 하나

나는 줄곧 "자기 진화"라는 게 굉장히 신비롭게 들려서, 스스로 가중치를 미세 조정하고 몰래 똑똑해지는 그런 것인 줄 알았다. 이름만 봐도 무서웠다——"self-improving", 이 단어는 AI 업계에서 너무 남용돼서, 제품 열 개 중 아홉 개가 이걸 미끼로 쓴다.

그런데 Hermes의 이것은, 소박해서 오히려 좀 실망스럽다.

그 논리는 한마디로 이렇다: 기억할 가치가 있는 경험을 하나 배우면, 그것을 Markdown 파일 하나로 써서 하드디스크에 저장하고, 다음에 읽는다.

미세 조정도 없다. 학습도 없다. 모델 파라미터는 단 한 번도 건드리지 않았다.

나는 나중에 비유를 하나 생각해봤는데, 정확하지 않을 수 있지만 이해하기는 쉽다: 그것은 수영을 배운 게 아니라, 수영 교본을 노트에 베껴 두고 다음에 물에 들어갈 때 바로 펼쳐보는 것이다. 교본은 베낄수록 늘어나지만, 그 자신은 여전히 그 자신이다.

(여기서 너는 "겨우 이거?"라고 생각할 수 있다——조급해하지 마라, 뒤에 나오는 게 핵심이다.)

그것이 기억하는 건 대체 무엇인가

Hermes는 "기억"을 세 덩어리로 나누는데, 내가 처음 봤을 때 이 분류는 뭔가 있다고 느꼈다. 왜냐하면 내 머릿속이 돌아가는 방식과 정말 좀 비슷했기 때문이다:

- 하나는 Memory라 부르고, "너는 어떤 사람이고 무엇을 좋아하는가"를 기억한다——예를 들어 나는 그것에게 "이 사용자는 shell에서 cat 쓰는 걸 싫어하니 Read를 쓰게 하라"고 기억시킨 적이 있다. 이런 건 매번 대화 시작할 때 로드된다.

- 하나는 Session Search라 부르고, "우리가 전에 무슨 이야기를 했는가"를 기억한다——역사 대화를 SQLite에全文 검색을 더해 저장하고, 기억나면 찾아본다.

- 세 번째 덩어리가 바로 skill로, "이 일을 어떻게 하는가"를 기억한다——단계, 명령, 함정, 어떻게 검증하는가.

앞의 두 덩어리는 다른 agent에도 있고, 별 차이가 없다. 진짜 다른 건 세 번째 덩어리다: 그것이 기억하는 건 "무슨 일이 일어났는가"가 아니라 "어떻게 해야 맞는가"이다.

실제로 어떻게 생겼는지 skill 파일 하나를 보여주겠다(이건 내가 test-driven-development라는 공식 skill에서 뽑아오게 한 것이다):

--- name: test-driven-development description: Use when implementing any feature or bugfix, before writing implementation code. version: 1.1 .0 author: Hermes Agent (adapted from obra/superpowers) --- # When to Use 어떤 기능을 구현하거나 버그를 고치기 전. # Procedure RED-GREEN-REFACTOR: 먼저 실패할 테스트를 쓰고, 다음으로 통과시키는 최소 구현을 쓰고, 마지막에 리팩터링한다. # Pitfalls 구현을 먼저 쓰고 테스트를 나중에 보충하지 마라——그건 주객이 전도된 것이다. # Verification 테스트 전부 초록, 커버리지 하락 없음.

저 description 필드 보이는가? 그건 사람이 보라고 쓴 게 아니라 "skill 선택기"가 보라고 쓴 트리거 단어다. 더 정확하게 쓸수록, 다음에 그것을 써야 할 때 더 믿음직하다. 그리고 본문에 기록된 건 전부 교훈이지流水账이 아니다——하나의 함정은, 재사용 가능한 규칙 하나에 "왜 이렇게 하면 안 되는가" 한마디를 더한 것이지, "그날 오후 PR #1234가 터졌다"가 아니다.

이 점은 꽤 감탄했다. 나는 내 노트를 항상流水账으로 적어서, 나중에 돌아보면 아예 보고 싶지 않다.

그것은 어떻게 "자라나는가"

이 부분은 나도 시간을 좀 들여야 이해가 됐는데, 공식 문서가 꽤 난해하게 써놨기 때문이다. 간단히 말하면 하나의 순환 구조다:

언제 쓰는가? 시스템 프롬프트에서 그것에게 요구하기를, 다음과 같은 경우에는 절차를 skill로 저장해야 한다: 복잡한 일을 해냈을 때(대략 5회 이상의 도구 호출이 들었을 때), 벽에 부딪혔다가 우회했을 때, 내가 방식을 바로잡아줬을 때, 혹은 색다른 워크플로를 발견했을 때.

다 쓰고 나서 누가 보는가? 매 라운드 대화가 끝나면, Hermes는 "조용한 모드"의 복사본을 fork해서, 너를 방해하지 않고 방금 그 라운드를 전문적으로 복기한다: 사용자가 장기적으로 유용한 선호를 뭔가 흘렸는가? 우리가 또 복잡하고 성공적인 다단계 절차를 실행해서 고정할 가치가 있는가? 이건 사실 AI 업계에서 유명한 Reflexion(성찰) 패러다임인데, 그들이 기본으로 켜진 백그라운드 스레드로 만들어놓은 것이다. 시끄러우면 끌 수도 있고, 수동 /refine으로 바꿀 수도 있다.

가장 관건적인 설계——점진적 공개. 내가 처음에 가장 걱정했던 건: skill이 쌓일수록 컨텍스트가 터지지 않을까? 내 컴퓨터에서 다른 agent를 돌리면 자주 터진다. Hermes의 해법은 계층 로딩인데, 이건 칭찬해야겠다, 정말 세심하게 생각했다:

- Level 0: 시스템 프롬프트에 각 skill의 이름에 한 문장 소개만 넣고, 총 대략 3k token이며, 항상 거기 있다;

- Level 1: 이번에 쓸 만하다고 판단되면, 그제서야 skill_view로 전체 내용을 읽어온다;

- Level 2: 세부 사항이 필요하면, 다시 개별 참고 파일을 읽는다.

장점이 뭐냐면——skill이 10개에서 수백 개로 늘어도, 너가 매 라운드 쓰는 token은 거의 늘지 않는다. 그것은 "필요에 따라 펼치기"로 "경험이 많음"과 "매번 저렴함"이라는 본래 모순되는 두 가지를 동시에 해냈다. 이건 나는 어쨌든 생각 못 했는데, 꽤 묘하다.

또 "Curator"(큐레이터)라는 역할이 있는데, "잊는 일"을 전담한다: 장기간 쓰지 않는 skill은 오래된 것으로 표시됐다가 보관 처리된다; 선택적으로 중복된 것들을 합칠 수도 있다. 그것은 삭제하지 않고, 백업을 갖춰 롤백할 수 있다. "잊음"조차 그들이 명시적으로 설계에 넣었다는 점을, 나는 전에 정말 눈치채지 못했다.

왜 굳이 Markdown이어야 하고, 모델을 건드리지 않는가

나도 처음엔 궁금했다, 왜 직접 미세 조정해서 똑똑하게 만들지 않는가. 나중에 그들 개발자 중 한 명의 인터뷰를 보고서야 이해됐다.

skill 파일은 반드시 사람이 읽고, 검토하고, diff할 수 있고, 옮길 수 있어야 한다. 그것은 agentskills.io라는 개방 표준을 따르는데, 뜻인즉 네가 Hermes를 위해 쓴 skill을, 이론상 다른 호환 agent에서 쓸 수 있고, 특정 한 회사에 묶이지 않는다는 것이다.

더 깊이 들어가 보면, 이 녀석은 "학습"을 git으로 관리할 수 있는 텍스트 파일로 만들어 버렸다. 새로 작성한 각 스킬을 마치 동료의 PR을 리뷰하듯이 바로 리뷰할 수 있다. 회사에 둔다면 "모델이 몰래 바뀌는" 것보다 훨씬 안심이 된다. 우리 상사가 AI가 몰래 자기를 고치고 있다는 걸 알았다면 아마 그 자리에서 바로 금지시켰을 것이다.

진실을 좀 말하자면: 이것도 함정이 있다

칭찬만 할 수는 없다. 써 보니 확실히 대가가 있다. 이 몇 가지는 네가 꼭 알아두는 게 좋다:

첫째는 토큰 소모 다. 자기 개선 루프는 매번 대략 15%에서 25% 정도 토큰을 더 쓴다(이건 제3자가 측정한 것이지 내가 지어낸 게 아니다). 내 개발 머신으로 일주일 돌려 보니 청구서가 평소보다 좀 두꺼워졌다.

둘째는 더 성가신데, 바로 잘못 기록한다 는 점이다. 기본적으로 쓰기 승인은 꺼져 있다. 즉 이 녀석이 "마음대로 쓴다". 한 번은 내게 틀린 프로세스를 기록해 두었는데, 그것도 내 이전 테스트 스크립트 안의 주석에 휘둘린 결과였고, 그 뒤 이틀 동안 같은 실수를 계속하다가 한참 만에야 이 녀석이 잘못 기록한 걸 발견했다. 그래서 내 제안은, 인터넷에 연결되거나 오래 켜 두는 것이라면 skills.write_approval과 memory.write_approval을 모두 켜서, 쓰기 전에 먼저 네게 묻게 하라는 것이다.

셋째는, 가장 오해하기 쉬운 부분인데: "말해도 기억 못 한다"는 사실 설계된 것 이다. 기억은 대화가 시작될 때 찍는 스냅숏이라, 이번 턴에 기록시킨 것은 다음 대화에 가서야 반영된다. 나는 처음에 버그인 줄 알고 가서 이슈를 올렸더니, 상대는 프리픽스 캐시를 지키기 위해 일부러 그런 거라고 했다.

그러니 보다시피, Hermes가 주는 것은 스스로 경험을 쌓는 "동료"다. 하지만 진짜 동료처럼, 너는 그에게 규칙을 세워 주고 코드 리뷰를 해 줘야 한다. 전부 믿어서는 안 된다.

나의 개인적인 생각

좀 옆으로 새서 말해 보자면. 보통의 챗봇은 매번 처음부터 시작한다. 마치 얼굴을 영영 기억 못 하는 창구 직원 같다. Hermes는 "자본"을 쌓는다. 그 경험은 복리로 불어난다.

나는 가끔 생각한다. 사람도 절차적 기억에 의존해 반복 동작을 본능으로 만든다고. Hermes는 스킬 시스템에 의존해 반복 과업을 SOP로 만든다. 본질적으로는 같은 일이다. 일회성 노동을 재사용 가능한 것으로 침전시키는 것.

이 "말"을 한동안 길러 보면서 가장 깊게 느낀 것은 이 녀석이 얼마나 똑똑한가가 아니라, 정말로 "자란다"는 점이었다. 모델이 똑똑해지는 그런 성장이 아니라, 옆에 있는 노트가 점점 두꺼워지는 성장이다.

한번은 친구 왕(老王)에게 이 얘기를 했더니, 그가 한마디 했다: "너 이거 AI를 기르는 게 아니라, 스스로 책장을 정리하는 사서를 기르는 거야." 나는 그의 말이 꽤 정확하다고 생각했다. 비록 그가 "사서"라는 단어를 잘못 읽었지만, 뜻은 통했다.

그래서 맨 처음 그 오싹하던 느낌으로 돌아가 보면, 지금은 그렇게 무섭지 않고 오히려 좀 기대된다. 미래에 에이전트들끼리 겨루는 것은 어쩌면 정말로 어느 한 번 누가 더 똑똑한가가 아니라, 누구의 에이전트가 쌓아 둔 믿을 만한 SOP가 가장 많고 가장 정확한가 일지도 모른다.

너는 "스킬 쓰기, 기억하기" 권한을 완전히 이 녀석에게 맡길 자신이 있나? 아니면 반드시 사람의 승인 절차를 하나 둬야 하나? 어쨌든 나는 지금 승인을 켜 두고 있다. 좀 겁이 난다. 댓글로 이야기해 보자?