[Hermes + Claude Code + Obsidian] 다중 역할 전문직을 위한 AI 운영 메모리 설계 — 마스터의 지식 vault와 에이전트의 작업기억을 나누는 방법

AI 운영 메모리 설계 요약

한 사람이 여러 역할을 한꺼번에 떠안고 살아가는 사람이라면, 한 명의 AI 비서에게 모든 일을 시키다 보면 어느 순간 응답이 어딘가 어긋난다는 걸 알게 된다. 그래서 일곱 명의 에이전트를 역할별로 나누고, 그들의 작업기억을 마스터의 지식 vault 바깥에 따로 두는 구조를 하루 동안 만들어 봤다. 핵심은 맥락의 오염이 조용히 사라진다는 점이다.

바쁘시면 이것만 읽어도 돼요:

- 사용한 도구: Claude Code(VSCode 확장, Opus 4.7)와 Obsidian. 외부 서비스는 부르지 않고 로컬에서 마무리.

- 출발점: 본업, 학회 운영, 작은 조직의 살림, 가족과의 시간, 개인 재무 — 다섯 가지 영역이 한 명의 AI 비서에 섞여 응답이 자꾸 어긋나곤 했다.

- 첫 번째 결정: 일곱 명의 에이전트를 3-tier(캐논 → 운영 카드 → 런타임 로더) 구조로 정리해 도구 어디서나 부를 수 있게 했다.

- 두 번째 결정: 에이전트들의 작업기억(brain) 을 나의 다른 지식들 vault 바깥으로 옮겼다. git만 동기화하고 Obsidian Sync는 일부러 비웠다.

- 결정적인 한마디: 설계를 거의 승인할 무렵 "이렇게 나누면 어떤 문제가 생길까?" 하고 물었더니, 아홉 가지 예상되는 문제점과 그 완화책을 차분히 정리해 주었다. 그 답이 설계를 한 번 더 단단하게 만들었다.

- 뜻밖의 보너스: 처음엔 헤르메스 에이전트 구조에만 쓰려고 했는데, 같은 원리가 Claude Code의 일반 작업이나 Codex 같은 다른 도구에서도 그대로 쓰일 수 있다는 걸 알게 됐다.

---

AI 운영 메모리 설계가 필요한 사람들

- 한 사람이 본업과 부업, 가족과 개인의 일을 동시에 떠안고 살아가는 다중 역할 전문직 — 이를테면 임상가, 자문역, 강의자, 1인 사업자, 작은 조직의 운영자.

- ChatGPT나 Claude를 매일 쓰지만 "이 대화가 어느 모드인지" 매번 다시 깔아주는 일이 조금 피곤해지기 시작한 분.

- Obsidian 같은 지식관리 도구를 쓰면서 AI 에이전트를 본격적으로 들여놓고 싶은 분.

- "AI에게 일을 시키는 단계"를 넘어 "AI를 내 일터에 맞게 천천히 설계하고 싶은" 분.

---

AI 운영 메모리 설계 전 문제점

한 명의 AI 비서에게 하루 종일 일을 시키다 보면, 어느 순간 이상한 일이 벌어진다.

오후에는 일터에서 만난 어려운 사례를 정리해 달라고 했다가, 저녁에는 학회의 공지 메일을 다듬고, 밤에는 아이의 분수 곱셈을 함께 설명한다. 같은 창에서 일어나는 일이라 맥락이 자연스럽게 이어진다. 그러다 보면 이런 일이 생긴다.

가족과 보내는 시간에 효율이라는 말이 슬며시 끼어든다. 아이와 분수를 설명하는데 어디선가 "이 시간을 최적화하려면…" 같은 표현이 따라 나온다. 마음에서 곱게 받아들이기가 어렵다.

진지한 사례 정리에 어울리지 않는 카피라이팅이 섞인다. 신중하게 다뤄야 할 개념화를 부탁했는데, 어디선가 "사람들에게 매력적으로 다가가는…" 같은 마케팅 어조가 묻어 나온다.

학회의 공지를 만들 때는 학술 단체의 격조에 어울리지 않는 가벼운 농담조가 끼어든다. "여러분의 많은 참여~!" 같은 표현. 부드럽게 다시 고쳐야 한다.

이게 단순히 "프롬프트를 더 잘 짜면 되는 일"이 아니라는 걸 알게 되었다. 한 명의 비서에게 다섯 가지 다른 모드를 매일 갈아 끼우게 만드는 비용 자체가 본질에 가까운 일이었다. 매번 "지금은 이쪽 모드", "지금은 저쪽 모드"라고 깔아주는 시간이 알게 모르게 쌓이고, 화요일 오후가 좀처럼 가벼워지지 않았다.

이미 vault에는 일곱 명의 에이전트(모피어스·오라클·네오·트리니티·페퍼·자비스·란초)의 페르소나 문서가 있었다. 그런데 그 문서들은 vault 안에 잘 정리된 상태로만 머물러 있었다. Claude Code에서 실제로 부를 수 있는 형태가 아니었다. 있지만 잘 쓰이지 않는 상태였던 셈이다.

---

AI 운영 메모리 설계에 사용된 도구

- 도구: Claude Code (VSCode 확장)

- 모델: Claude Opus 4.7 (fast 모드)

- 에디터: VSCode와 Obsidian을 나란히

- 저장소와 동기화: vault는 Obsidian Sync로, brain은 git으로

- 외부 API: 사용하지 않음. 로컬에서 완결

- 소요 시간: 약 2시간 30분 (오후 12:46부터 15:15까지, 단일 세션)

---

AI 운영 메모리 설계 작업 과정

SOUL.md를 만들어야 할까라는 질문에서 시작

처음 AI에게 던진 질문은 이런 것이었다.

```

hermes-agents 폴더 구조를 이용해서 맥미니에 에이전트를 설치하고 운용하려고 해. 각 Agent별로 무엇을 더 해야 할까? SOUL.md를 만들어야 하나? 조사하고 검토하여 알려줘.

```

"SOUL.md"라는 표현은 내가 속한 스터디(헤르메스 메가진화)에서 들어 본 것이었다. 스터디장이신 DECK님이 자신의 brain 시스템을 친절히 보여주실 때 등장하는 개념이었다. 그런데 AI는 이런 답을 차분히 돌려주었다.

> "SOUL.md는 Claude Code나 Agent SDK의 표준 개념은 아닙니다. 다른 일부 에이전트 프레임워크에서 쓰는 이름이고, Claude Code 기준으로는 .claude/agents/<name>.md가 비슷한 역할을 합니다. 그대로 옮겨심기 전에, 어떻게 우리 환경에 맞출지 먼저 정해야 합니다."

그 한마디가 첫 번째 깨달음이 되었다. 남의 용어를 그대로 가져오지 말고, 내가 쓰는 도구의 표준 메커니즘과 어떻게 맺을지 먼저 정리하는 일. 그 결과로 우리만의 3-tier 정체성 분리가 자연스럽게 나왔다.

• 정체성 캐논 (기존 vault 문서): 거의 변하지 않는 페르소나와 목적

• 운영 카드 SOUL.md (새로 신설): 캐논의 운영 인덱스, 출력 규칙, 안전 게이트

• 런타임 로더 (`.claude/agents/`): 위 두 파일을 자동으로 합성하는 얇은 셸

이 분리 덕분에 한 곳을 고치면 다른 곳이 자동으로 따라오고, 진실의 출처가 한 군데로 명확해졌다.

스터디장의 brain 구조를, 그대로 베끼지 않고 "적응 매트릭스"로 변환

며칠 전 헤르메스 메가진화 스터디의 스터디장이신 DECK님이 자신의 brain 시스템 구조를 자세히 풀어 공유해 주셨다. START_HERE.md → SCHEMA.md → shared/ → profiles/main, pkm, dev, ops/... 같은 구조였다. 솔직히 처음에는 그대로 옮기고 싶은 마음이 컸다. 잘 짜인 구조였으니까.

그런데 그대로 옮기는 대신 AI에게 이렇게 부탁했다.

```

이 내용을 별도의 참고 마크다운 파일로 저장해주고, 이 구조를 최대한 활용하여, hermes가 작업 시작할 때 읽고 시작하는 폴더 구조를 만들어줘. obsidian폴더 안에, My_Vault와 대등한 위치의 폴더에 2nd_BRAIN 폴더를 만들어서, 이 폴더를 참조하여 작업이 진행되면 좋겠어. 그렇게 해서 My_Vault(마스터의 지식) ↔ 2nd_BRAIN(에이전트의 작업기억)이 분리될 수 있도록 해주고.

```

AI가 돌려준 결과에서 가장 마음에 든 것은, DECK님의 원본을 그대로 잘 보존하면서도 아홉 가지 항목에 대해 "원본 vs 우리 적응"의 차이와 이유를 매트릭스로 정리해 둔 것이었다. 몇 줄만 옮겨 보면 이런 식이다.

이렇게 항목별로 차이를 짚으니, 어느덧 남의 시스템이 우리 시스템이 되어 있었다. DECK님이 친절히 풀어 주신 구조가 우리에게 출발점이 되었고, 그 위에 우리 환경의 살을 붙이는 일이 자연스러웠다. 헤르메스 메가진화 스터디의 좋은 점이 거기 있었다. 다들 자기가 쓰는 구조를 친절하게 풀어 보여 주고, 그 위에서 각자의 환경에 맞게 응용해 갈 여지를 넉넉히 남겨 둔다. 정답을 하나로 좁히지 않는다.

설계를 거의 승인할 무렵, "이렇게 분리되면 어떤 문제가 있을까?"

가장 인상에 남는 순간이다. AI가 제시한 Plan을 거의 받아들이려다가, 잠시 멈추고 이렇게 물었다.

```

이렇게 진행되더라도, 에이전트를 통한 여러 생산물은 옵시디언 싱크가 되는 폴더로 지정해두면 상관 없겠지? 이리 분리되었을 때 예상되는 문제가 있을까?

```

AI는 그 자리에서 아홉 가지 비용과 완화책을 차분히 정리해 주었다. 몇 가지만 옮기면 이런 것들이었다.

첫째, 정체성 카드(SOUL.md)가 바뀌었는데 brain의 압축본이 따라 바뀌지 않으면 모순이 생긴다. 그래서 동기화 절차를 첫 번째 procedure로 박아 두기로 했다.

둘째, 여러 대의 컴퓨터가 git을 통해 brain을 공유하다 보면 충돌이 생길 수 있다. Obsidian Sync 같은 영리한 3-way merge가 brain에는 없으니까. 그래서 "작업 전에 pull, 작업 후에 push"라는 작은 습관을 두기로 했다.

셋째, 매 호출마다 파일 아홉 개가 자동으로 로드되니 토큰 비용이 누적될 수 있다. 그래서 페이지마다 150줄을 목표로 잡고 비대해지면 따로 archive로 옮기기로 했다.

그리고 네 번째부터 아홉 번째까지 더 있었다.

이 답을 받고서야 Plan을 다시 승인했다. AI가 자기 설계의 약점을 솔직히 짚어 주는 순간이 협업의 본질에 가깝다는 걸, 그 자리에서 알게 되었다. "더 좋은 안 줘"라고 묻는 것보다, "이게 어디서 깨질까"를 묻는 쪽이 훨씬 빠른 검증이라는 것도.

외부 스킬 설치가 막히자, 방금 만든 시스템이 첫 실전이 되어 주었다

작업이 거의 끝나갈 무렵, 다른 분이 만든 외부 스킬을 설치해 보려고 했다. 그런데 안전 분류기가 일시 차단되어 외부 스크립트를 가져올 수 없었다.

여기서 우회로를 택했다. 방금 만든 시스템 자체로 블로그 포스트를 한 편 써 보자. 모피어스(라우팅)에서 네오(콘텐츠)로 가는 파이프라인을 그대로 돌렸다.

결과는 조금 뜻밖이었다. 라우팅 로그가 자동으로 04-logs/ 폴더에 일자별로 쌓였고, 초안은 03-drafts/에 frontmatter(작성자, 민감도, 검토 필요 여부, 원래 요청 등)와 함께 자동으로 저장되었다. 안전 규칙도 잘 작동했다. "발송했습니다" 같은 실행 시뮬 표현이 단 한 번도 나오지 않았다.

의도하지 않게 첫 실전 검증을 통과한 셈이었다. 외부 도구가 막힌 일이 오히려 자기 시스템을 빨리 검증할 기회가 되어 주었다. 그런 일이 가끔 있다.

처음엔 한 가지를 만들려다, 일반 작업으로도 쓸 수 있게 되었다

여기서 한 가지 뜻밖의 보너스를 얻었다.

처음 출발할 때는 헤르메스 에이전트 일곱 명을 운용하기 위한 구조만 머릿속에 있었다. 그런데 작업이 끝나고 나니, 같은 원리가 일반적인 Claude Code 작업이나 Codex 같은 다른 도구를 쓸 때도 그대로 적용된다는 걸 알게 되었다.

서브에이전트 등록 방식, @-include로 정체성과 작업기억을 합성하는 메커니즘, vault와 brain을 분리하는 폴더 구조, sensitivity 상속 같은 출력 규칙 — 이 모든 것이 헤르메스에만 묶인 이야기가 아니었다. 다른 일반 프로젝트에서 코드 작업을 할 때도 똑같이 쓸 수 있는 패턴이었다.

이게 헤르메스 메가진화 스터디의 좋은 점이기도 한 것 같다. 스터디에서 배우고 함께 만든 구조가 한 가지 용도에만 묶이지 않는다. 각자가 자기 환경, 자기 지식관리 방식에 맞춰 응용하고 통합할 여지가 넉넉하다. DECK님께 받은 brain 구조가 헤르메스 에이전트 운용에 쓰이고, 동시에 일반 코드 작업에도 쓰이고, 누군가에겐 또 다른 형태로 쓰일 수 있다는 것. 그 유연함이 이 접근의 가장 큰 장점이지 싶다.

---

AI 운영 메모리 설계 결과

Before vs After

결과물

• 일곱 명의 에이전트를 Claude Code의 /agents 명령으로 vault 어느 폴더에서나 부를 수 있다

• 작업기억(2nd_BRAIN) 폴더에 34개 파일과 회귀 점검 질문 10개

• 첫 실전 작업으로 이 글의 초안이 자동으로 만들어졌다 (작성자는 네오)

• 같은 패턴을 일반 코드 작업에도 들고 갈 수 있게 되었다

---

AI 운영 메모리 설계에서 배운 점

효과적이었던 것

첫째, AI에게 "내 설계의 약점이 뭐야?"라고 직접 물어보기. "더 좋은 안 줘"보다 훨씬 빠른 검증이 된다. 아홉 가지 비용과 완화책이 그렇게 나왔다.

둘째, 역할별로 에이전트를 분리하기. 한 명의 비서에게 다섯 가지 모드를 매일 갈아 끼우게 하는 비용 자체가 본질이다. 분리하면 맥락의 오염이 조용히 사라진다.

셋째, 표준 용어가 아닌 개념을 만나면 먼저 "내 환경에 어떻게 맞출지" 정리하기. SOUL.md처럼 다른 프레임워크에서 가져온 표현을 그대로 채택하지 말고, 내가 쓰는 도구의 표준 메커니즘과 어떻게 매핑할지를 AI와 함께 먼저 정한다.

이렇게 하면 잘 안 되더라

다른 사람의 시스템을 그대로 적용하면 잘 안되는 듯하다. 늘 "원본 vs 내 적응"의 매트릭스를 함께 만드는 편이 좋다. 환경과 맥락이 다르면 같은 구조도 다르게 작동한다.

AI가 처음 제시한 Plan을 곧장 승인하는 것. 한 번 멈추고 "분리되면 무슨 문제가 있을까", "이게 어디서 깨질까" 묻는 시간이 의외로 큰 차이를 만든다.

에이전트의 작업기억을 마스터의 지식 vault에 같이 두는 것. 진실의 출처가 둘이 되면 어느 게 맞는지 알 수 없게 된다. 폴더부터 분리해 두는 편이 낫다.

---

AI 운영 메모리 설계의 다른 업무 적용

이 구조는 한 사람이 여러 역할을 동시에 떠안는 일을 하는 분이면 누구에게나 옮길 수 있다. 자문역에게는 분야별 사건과 자문, 강의자에게는 수업 콘텐츠와 학생 응대, 작은 사업의 운영자에게는 마케팅과 고객 응대와 재무, 상담가에게는 사례 정리와 교육 자료와 자기 돌봄. 영역의 이름이 다를 뿐 원리는 같다.

공통 원리는 세 가지로 좁혀진다. 역할별로 에이전트를 정의하기. 정체성과 작업기억의 폴더를 따로 두기. AI에게 자기 설계의 약점을 직접 물어보기.

그리고 무엇보다, 이 구조가 헤르메스 같은 특정 시스템에만 묶이지 않는다는 점이 좋다. 한 번 만들어 두면 다른 도구로 일할 때, 다른 프로젝트를 시작할 때도 같은 패턴이 그대로 살아남는다. 각자가 쓰는 지식관리 방식, 도구, 일터의 모양에 맞춰 천천히 응용하고 통합해 갈 수 있다. 정답이 하나로 좁혀지지 않는 자리에서 자라는 구조다.

---

AI 운영 메모리 설계의 향후 계획

다음 단계는 Discord와 Telegram 브릿지다. 지금은 맥미니에서만 부를 수 있지만, 디스코드와 텔레그램 봇을 만들면 휴대폰이나 다른 컴퓨터에서도 메시지 한 줄로 모피어스를 부를 수 있게 된다. 일과 일 사이의 짧은 틈에도 "오라클, 이 케이스 정리해 줘"가 가능해진다.

그다음은 30일 운영 후 실측 평가다. 회귀 점검 질문 열 개로 시스템이 stale해지지 않았는지 주에 한 번씩 점검하고, 어떤 에이전트가 잘 쓰이고 어떤 게 안 쓰이는지를 보면서 프롬프트를 다듬어 갈 예정이다. 한 달이라는 시간이 충분한지 부족한지는 가 봐야 알겠지만.

---

AI 운영 메모리 설계에 대한 감사의 말

이 작업의 절반은 헤르메스 메가진화 스터디의 스터디장이신 DECK님께 돌아간다. brain 폴더의 구조와 운영 원리를 자세히 풀어 공유해 주신 덕분에, 우리는 빈 종이에서 출발하지 않을 수 있었다. 그 친절함이 없었으면 이 구조는 한참 더 늦게, 훨씬 거친 모양으로 나왔을 것이다.

스터디의 분위기도 함께 짚어 두고 싶다. 한 가지 정답으로 좁혀 가는 것이 아니라, 각자가 자기 환경에 맞춰 변형하고 응용해 갈 여지를 늘 넉넉히 남겨 둔다. 누군가의 brain은 숨김 폴더에, 누군가의 brain은 vault 옆에. 누군가의 프로파일은 작업 모드별로, 누군가의 프로파일은 에이전트 일곱 명에 일대일로. 그 다양함을 모두 좋다고 말해 주는 자리라는 게 귀하다.

---