SOUL·USER·MEMORY를 섞지 않기 위한 제 작업 기준

Windows 환경을 기준으로 작성했습니다.AI가 초안을 도운 부분도 사람이 다시 확인합니다.

작성일·최종 확인일: 2026-08-29

Hermes Agent를 오래 쓰기 시작하면 “이 내용은 어디에 적어야 하지?”라는 문제가 생깁니다. 역할 지침, 사용자의 선호, 프로젝트 사실, 오늘의 진행 상태가 한 파일에 들어가면 처음에는 편합니다. 시간이 지나면 오래된 상태가 규칙처럼 남고, 다른 업무의 정보가 현재 답변에 섞입니다. 제가 운영안을 만들 때 SOUL, USER, MEMORY를 나누는 이유는 파일 이름을 예쁘게 정리하기 위해서가 아니라 정보의 수명과 책임을 구분하기 위해서입니다.

이 글은 Hermes 프로필을 업무별로 나누거나 지속 메모리를 사용하려는 사람을 위한 개인 작업 노트입니다. 아래 예시는 가상 프로젝트를 위한 문장입니다. 실제 고객, 사용자, 실행 결과를 설명하지 않습니다. Hermes의 메모리 구조와 설정은 제품 업데이트에 따라 달라질 수 있어 2026-08-29에 공식 Persistent Memory와 Profiles 문서를 기준으로 확인했습니다.

먼저 용어보다 질문 네 개를 쓴다

이 정보가 에이전트의 행동 방식을 정하는가
여러 업무에서 반복되는 사용자 선호인가
다음 세션에도 필요한 안정적인 사실인가
오늘이나 이번 주에 바뀔 수 있는 현재 상태인가

첫 질문은 SOUL, 둘째는 USER, 셋째는 MEMORY의 후보입니다. 넷째는 대개 어느 기억 파일에도 넣지 않고 CSV, 이슈 트래커, 작업 목록 같은 상태 원본에 둡니다. 실제로는 경계가 겹칠 수 있습니다. 그럴 때 저는 “이 문장을 바꾸려면 무엇을 확인해야 하는가”를 봅니다. 사용자의 의사 확인이 필요한 선호인지, 프로젝트 파일을 읽어야 하는 사실인지, 작업 완료로 즉시 바뀌는 상태인지에 따라 위치가 달라집니다.

기준 환경과 전제

Windows에서 하나 이상의 Hermes 프로필을 사용하는 구성
프로필마다 역할과 업무 범위가 다를 수 있음
현재 진행 상태는 별도의 파일이나 시스템에서 조회
비밀값은 기억 파일이 아닌 승인된 비밀 저장 위치에서 관리

중요한 전제가 있습니다. 프로필 분리는 상태와 설정의 분리이지 파일 접근 샌드박스가 아닙니다. 공식 Profiles 문서는 각 프로필이 자체 설정, 비밀값, SOUL, 메모리, 세션, 기술 등을 가지지만 로컬 백엔드의 파일 접근은 운영체제 사용자 권한을 따른다고 설명합니다. 다른 프로필을 만들었다고 해서 다른 폴더를 기술적으로 못 읽는다고 가정하지 않습니다.

SOUL: 무엇을 하고 어떻게 멈출지

SOUL에는 프로필의 역할, 말투보다도 행동 원칙과 경계를 먼저 적습니다. “친절하게 답한다”보다 “외부 게시 전 대상과 최종 내용을 보여 주고 승인을 기다린다”가 운영에 더 직접적입니다. 현재 작업 건수나 특정 문서의 마감 상태처럼 곧 바뀌는 내용은 넣지 않습니다.

# 가상 예시
이 프로필은 내부 콘텐츠 초안과 검토 자료를 준비한다.
외부 게시, 고객 메시지 발송, 결제, 삭제는 사용자의 명시적 승인 전 실행하지 않는다.
현재 상태를 묻는 요청에서는 승인된 상태 원본을 다시 읽는다.
대상이 모호하면 추측하지 않고 후보를 보여 준다.

이 예시는 실제 SOUL 파일의 전체 템플릿도, 현재 설치에서 검증된 구성도 아닙니다. 내용의 종류를 보여 주기 위한 문장입니다. 지침이 너무 길어지면 중요한 경계가 묻힙니다. 세부 작업 절차는 skill이나 프로젝트 문서로 옮기고 SOUL에는 프로필 전반에 적용되는 원칙을 남깁니다.

USER: 사용자에 관한 안정적인 선호

Hermes 공식 Persistent Memory 문서는 built-in store에서 user와 memory 대상을 구분합니다. USER에는 언어, 답변 길이, 선호하는 결과 형식처럼 여러 세션과 업무에서 다시 쓸 사용자 선호를 둡니다. “한국어로 답한다”, “파일을 바꾸면 변경 경로를 함께 보고한다” 같은 항목이 후보가 될 수 있습니다.

USER에 사용자의 사생활을 가능한 한 많이 모으는 것은 목적이 아닙니다. 작업에 필요하고 사용자가 유지하기 원하는 정보만 적습니다. 일회성 요청인 “오늘은 표로 정리”를 영구 선호로 저장하지 않습니다. 주소, 연락처, 계정 식별정보처럼 민감한 값은 편리하다는 이유로 넣지 않습니다.

좋은 후보: 결과는 한국어로 작성하고 파일 경로를 함께 보고한다.
나쁜 후보: 오늘 검토할 초안이 4개 남았다.
저장 금지: 비밀번호, API 키, 인증 코드, 고객 개인정보

위 문장도 분류 예시입니다. 실제 사용자 선호나 작업 수량을 주장하지 않습니다. 선호가 바뀌면 기존 항목을 수정하거나 제거하고 서로 모순되는 문장을 쌓아 두지 않습니다.

MEMORY: 다시 쓸 안정적인 사실과 교훈

MEMORY에는 다음 세션에서도 필요한 환경 사실, 프로젝트 관례, 검증된 절차상의 교훈을 짧게 둡니다. 예를 들어 “이 프로젝트는 UTF-8 CSV를 상태 원본으로 사용한다”는 실제 프로젝트에서 확인됐다면 후보가 됩니다. 아직 확인하지 않은 경로나 도구 버전을 추정해 저장하지 않습니다.

Hermes 공식 문서에 따르면 built-in memory는 세션 시작 시 시스템 프롬프트에 로드되고 문자 제한이 있습니다. 제한을 넘는 내용을 자동으로 조용히 버리는 구조로 생각해서는 안 됩니다. 짧고 서로 겹치지 않는 항목을 유지하고, 오래된 항목은 통합하거나 제거해야 합니다. 메모리는 문서 창고가 아니라 다음 판단에 필요한 작은 인덱스에 가깝게 운영합니다.

후보: sample 프로젝트의 테스트 명령은 프로젝트 문서의 현재 명령을 따른다.
후보 아님: 어제 테스트가 실패했다.
이유: 전자는 안정된 절차를 가리킬 수 있지만 후자는 원인과 현재 상태가 바뀐다.

“어제 실패”가 중요하다면 이슈나 작업 로그에 근거와 함께 남깁니다. MEMORY에는 해결 뒤에도 재사용할 수 있는 교훈만 검토해 저장합니다. 예를 들면 특정 파일을 바꾸기 전에 어떤 검증을 해야 한다는 원칙입니다. 단, 그것도 실제로 확인된 내용이어야 합니다.

현재 상태: 기억이 아니라 원본에서 다시 읽는다

콘텐츠 작성 중, 검토 대기, 게시 완료 같은 값은 계속 바뀝니다. 이런 상태를 MEMORY에 저장하면 다음 세션에서 오래된 문장이 현재 사실처럼 보일 수 있습니다. 저는 상태를 CSV, 데이터베이스, 이슈 트래커처럼 갱신과 조회가 가능한 원본에 둡니다. 에이전트에는 “상태 질문을 받으면 원본을 다시 읽는다”는 원칙만 남깁니다.

원본을 정했다면 식별자와 수정 권한도 정합니다. 표시 이름이 같아도 내부 ID는 유일해야 하고, 조회 결과가 둘 이상이면 멈춥니다. 상태 업데이트 뒤에는 같은 레코드를 다시 읽어 값이 바뀌었는지 확인합니다. MEMORY 문장을 고쳤다는 사실로 업무 상태 업데이트를 대신하지 않습니다.

단계별 정리 방법

현재 SOUL, USER, MEMORY 후보 문장을 복사해 별도 검토 문서에 모읍니다.
각 문장 옆에 행동 원칙, 사용자 선호, 장기 사실, 현재 상태를 표시합니다.
현재 상태는 원본 파일이나 시스템으로 옮기고 조회 방법을 정합니다.
비밀값과 불필요한 개인정보는 저장하지 않고 노출됐다면 폐기·삭제 절차를 따릅니다.
중복되거나 충돌하는 기억을 하나의 확인된 문장으로 정리합니다.
새 세션을 열어 역할 경계와 사용자 선호가 예상대로 적용되는지 확인합니다.
상태 질문에는 기억이 아니라 원본 조회가 일어나는지 검증합니다.

실제 파일을 바꾸기 전에는 백업과 변경 범위를 확인합니다. Hermes 설정을 바꿀 때 인터넷 예시를 보고 파일 전체를 덮어쓰기보다 공식 CLI와 현재 도움말을 사용합니다. SOUL 변경은 새 세션에서 깨끗하게 확인하는 편이 낫습니다. 기존 세션은 이전 프롬프트 상태를 계속 사용할 수 있다는 점도 공식 Profiles 문서에서 확인할 수 있습니다.

실용 예시: 문장을 어디에 둘까

외부 게시 전에 승인을 받는다는 프로필 전반의 행동 경계라면 SOUL에 둡니다. 사용자는 체크리스트 형식을 선호한다는 여러 작업에서 확인되고 유지하기로 한 선호라면 USER 후보입니다. 프로젝트가 특정 테스트 도구를 사용한다는 저장소에서 확인된 안정적 사실이라면 MEMORY 후보입니다. 8월 원고는 검토 중이다는 상태 원본에 둡니다.

문장만 보고 자동 분류하지는 않습니다. “외부 게시 전 승인”이 특정 프로젝트 한 곳에만 적용된다면 프로젝트 문서나 해당 skill에 두는 편이 맞을 수 있습니다. “체크리스트 선호”도 그날 한 번 요청한 형식이라면 저장하지 않습니다. 저장 여부는 반복 가능성과 사용자의 기대를 함께 봅니다.

흔한 실패와 좋지 않은 방식

첫 번째는 대화 중 나온 모든 내용을 기억에 저장하는 것입니다. 용량을 채울 뿐 아니라 틀린 추정과 일회성 상태가 다음 세션에 들어옵니다. 두 번째는 USER를 고객 데이터베이스처럼 쓰는 것입니다. 사용자 프로필은 작업에 필요한 선호를 위한 곳이지 연락처와 민감정보를 모으는 곳이 아닙니다.

세 번째는 두 에이전트 프로세스가 같은 프로필을 함께 쓰게 하는 방식입니다. 공식 문서는 두 writer가 같은 home에 자동 메모리를 쓰면 서로의 상태가 섞일 수 있으므로 에이전트마다 프로필을 나누라고 안내합니다. 공유 지식이 필요하면 검증 가능한 외부 원본이나 공식 memory provider 방식을 검토합니다. 네 번째는 프로필 분리를 샌드박스로 믿고 광범위한 파일 권한을 그대로 두는 것입니다.

검증 체크리스트

SOUL에는 프로필 전반의 역할과 행동 경계만 남겼는가
USER에는 사용자가 유지하기 원하는 안정적인 선호만 있는가
MEMORY의 사실은 실제 원본에서 확인할 수 있는가
오늘의 진행률과 임시 할 일을 별도 상태 원본에 두었는가
중복되거나 서로 모순되는 항목을 정리했는가
새 세션에서 변경된 경계와 선호를 확인했는가
상태 질문 때 원본을 다시 읽는가
두 에이전트가 같은 프로필에 동시에 쓰지 않는가
프로필을 파일 접근 샌드박스로 오해하지 않았는가

보안과 개인정보 메모

SOUL, USER, MEMORY는 세션과 시스템 프롬프트에 영향을 주는 운영 데이터입니다. 공개 예시나 지원 요청에 파일을 통째로 붙이지 않습니다. 실제 사용자명, 로컬 절대경로, 고객 정체, 토큰, 인증 코드가 들어 있는지 먼저 봅니다. 비밀값은 어느 기억 저장소에도 두지 않고 제공자가 권장하는 비밀 관리 방식으로 분리합니다. 기억 삭제와 원본 시스템의 데이터 삭제는 서로 다른 작업이므로 개인정보 삭제 요청이 있다면 관련 저장 위치를 각각 확인해야 합니다.

공식 참고 링크와 관련 작업 노트

도구 실행과 답변의 차이를 먼저 정리하려면 Hermes Agent와 일반 채팅 비교 노트를, 변하는 상태의 저장 구조가 필요하면 CSV 레지스트리 작업 노트를 이어서 봅니다. 제가 마지막에 확인하는 기준은 하나입니다. 이 문장이 내일 바뀐다면 기억에 넣기 전에 상태 원본부터 찾습니다.