# AI 에이전트의 SOUL.md와 USER.md를 분리해 관리한 사례

- 작성자: [연필](https://community.clauders.ai/member/imported-member-jtrqmJUcvc)
- 공간: [에이전트 / 노코드 자동화](https://community.clauders.ai/automation)
- 게시: 2026-07-24
- 연재: [나만의 반려 AI 에이전트](https://community.clauders.ai/series/personal-companion-agent-setup) 1/2편
- 태그: #반려에이전트
- 주소: https://community.clauders.ai/automation/post/ai-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8%EC%9D%98-soul-md%EC%99%80-user-md%EB%A5%BC-%EB%B6%84%EB%A6%AC%ED%95%B4-%EA%B4%80%EB%A6%AC%ED%95%9C-%EC%82%AC%EB%A1%80-4d39eeca-56f7-88de-86e6-6b4cbcf1e397

---

사례 배경

개인용 AI 에이전트를 사용하다 보면 답변 말투와 역할을 사용자에게 맞게 바꾸고 싶어진다. 처음에는 하나의 설정 파일에 모든 내용을 넣기 쉽지만, 운영하다 보면 다음 정보가 섞이기 시작한다.

- AI 에이전트의 이름과 역할

- 답변 말투와 판단 원칙

- 사용자의 호칭과 커뮤니케이션 선호

- 업무 관심 분야

- 보안과 개인정보 보호 기준

- 작업 방법과 도구 사용 규칙

이번 사례에서는 이러한 정보를 [SOUL.md](http://SOUL.md)와 [USER.md](http://USER.md)로 분리하고, 변경한 설정을 새 세션에 안전하게 적용하는 방법을 검토했다.

개인정보 보호를 위해 실제 사용자 이름, 계정 정보, 로컬 파일 경로, 구체적인 업무 내용과 개인 선호는 모두 생략하거나 일반화했다.

두 파일의 역할부터 구분했다

가장 먼저 정리한 것은 [SOUL.md](http://SOUL.md)와 [USER.md](http://USER.md)의 차이였다.

[SOUL.md](http://SOUL.md)

[SOUL.md](http://SOUL.md)에는 AI 에이전트 자체의 정체성을 넣었다.

예를 들면 다음과 같은 내용이다.

- 에이전트의 이름

- 기본 역할

- 답변 방식

- 사실과 추론을 구분하는 원칙

- 사용자의 의견도 필요하면 비판적으로 검토한다는 기준

- 민감정보에 접근하거나 이를 저장하지 않는다는 보안 경계

쉽게 말하면 [SOUL.md](http://SOUL.md)는 “이 AI는 어떤 존재이며 어떻게 행동해야 하는가”를 정하는 파일이다.

[USER.md](http://USER.md)

[USER.md](http://USER.md)에는 사용자에 관한 지속적인 정보를 저장했다.

- 선호하는 언어와 호칭

- 답변 길이와 설명 방식

- 자주 다루는 업무 분야

- 결과물을 받을 때 선호하는 형식

- 피하고 싶은 표현이나 행동

- 장기간 유지될 가능성이 높은 작업 습관

즉, [USER.md](http://USER.md)는 “이 사용자는 누구이며 어떤 방식의 도움을 선호하는가”를 기록하는 사용자 프로필이다.

두 파일을 분리하니 같은 내용이 반복되는 문제도 줄어들었다. 에이전트의 원칙은 [SOUL.md](http://SOUL.md)에, 사용자 개인의 선호는 [USER.md](http://USER.md)에 두는 방식이 가장 이해하기 쉬웠다.

말투는 업무 종류에 따라 나눴다

초기 설정에서는 “간결하고 직설적으로 답한다”는 규칙을 모든 상황에 적용하려 했다. 하지만 이 방식은 전문적인 분석에는 적합해도, 설정 안내나 오류 설명에서는 지나치게 딱딱하게 느껴질 수 있었다.

그래서 말투를 다음과 같이 구분했다.

- 전문 분석: 결론을 먼저 제시하고 근거와 반대 논리를 분명하게 설명

- 기술·설정 안내: 차분한 존댓말로 단계별 설명

- 확인되지 않은 내용: 사실처럼 단정하지 않고 추론임을 표시

- 공통 기준: 과장, 아부, 장황한 서론, 불필요한 장식을 피함

하나의 말투를 모든 업무에 강제로 적용하기보다, 역할에 따라 설명 방식을 나누는 편이 실제 사용성이 좋았다.

[USER.md](http://USER.md)는 덮어쓰기보다 병합이 안전했다

새 사용자 프로필 문서를 통째로 적용하면 기존에 저장해 둔 선호가 사라질 수 있다. 이번 사례에서도 새 문서에는 업무 관련 선호가 잘 정리되어 있었지만, 기존 프로필에 있던 일부 커뮤니케이션 선호는 포함되어 있지 않았다.

따라서 전체 파일을 교체하지 않고 다음 방식으로 처리했다.

1. 기존 사용자 메모리를 유지한다.

2. 새 문서에서 장기간 유효한 정보만 선별한다.

3. 중복되는 내용은 하나로 통합한다.

4. 임시 작업이나 곧 낡을 정보는 저장하지 않는다.

5. 민감정보는 처음부터 메모리 대상에서 제외한다.

이 방식은 사용자 프로필을 잃지 않으면서도 새로운 선호를 추가할 수 있다는 장점이 있다.

모든 내용을 사용자 메모리에 저장하지 않았다

[USER.md](http://USER.md)는 용량이 제한된 지속 메모리다. 대화 내용을 모두 넣으면 정작 중요한 선호가 묻히게 된다.

이번 사례에서는 다음 정보만 저장 대상으로 삼았다.

- 오래 유지될 가능성이 높은 호칭과 언어 선호

- 반복해서 적용할 설명 방식

- 장기적인 업무 관심 분야

- 결과물 형식에 대한 선호

- AI가 피해야 할 행동

다음 정보는 저장하지 않았다.

- 일회성 요청

- 현재 작업의 진행 상황

- 단기 일정

- 시간이 지나면 바뀌는 수치

- 특정 대화에서만 필요한 자료

- 비밀번호, 인증번호, 금융정보 등 민감정보

사용자 메모리는 대화 기록 보관소가 아니라, 다음 세션에서도 반복 적용할 핵심 선호를 보관하는 공간으로 보는 것이 적절했다.

파일 변경과 세션 적용은 별개였다

설정 작업에서 가장 혼동하기 쉬웠던 부분이다.

[SOUL.md](http://SOUL.md)나 [USER.md](http://USER.md)를 수정하면 디스크의 파일은 즉시 변경된다. 하지만 이미 진행 중인 세션의 시스템 설정이 바로 교체되는 것은 아니다.

Hermes Agent는 세션이 시작될 때 설정을 불러와 고정한다. 따라서 변경 사항을 완전히 적용하려면 새 세션을 시작해야 한다.

흐름은 다음과 같다.

설정 파일 수정

→ 파일에는 즉시 저장

→ 현재 세션에는 기존 설정이 남아 있음

→ /new 또는 /reset 실행

→ 새 세션에서 최신 설정 로드

현재 대화에서 변경 내용을 언급했다면 AI가 이를 참고해 비슷하게 행동할 수는 있다. 그러나 이것은 새 설정이 시스템 규칙으로 다시 주입된 것과는 다르다.

자동으로 새 세션이 시작되는 조건도 확인했다

메시징 환경에서는 사용자가 직접 /new를 입력하지 않아도 설정에 따라 세션이 자동 초기화될 수 있다.

일반적으로 선택할 수 있는 방식은 다음과 같다.

- 자동 초기화 안 함

- 일정 시간 대화가 없을 때 초기화

- 매일 지정된 시간에 초기화

- 비활성 시간과 지정 시각 중 먼저 해당하는 조건으로 초기화

대화가 너무 길어져 자동 압축이 발생할 때도 기존 세션과 연결된 새 연속 세션이 생성될 수 있다.

자동으로 새 세션이 시작되면 그 시점의 최신 [SOUL.md](http://SOUL.md)와 [USER.md](http://USER.md)가 로드될 수 있다. 설정을 수정한 직후 확실하게 적용하려면 사용자가 직접 /new를 실행하는 편이 가장 명확하다.

과거 설정으로 돌아갈 수 있도록 백업 규칙을 만들었다

새 설정이 마음에 들지 않을 때 되돌릴 방법도 필요했다. 단순히 파일을 수정하는 것만으로는 이전 내용을 자동으로 복구할 수 없기 때문이다.

백업 파일에는 날짜와 시간을 포함하기로 했다.

SOUL_YYYYMMDD_[HHMMSS.md](http://HHMMSS.md)

USER_YYYYMMDD_[HHMMSS.md](http://HHMMSS.md)

예시는 다음과 같다.

SOUL_20260101_[093000.md](http://093000.md)

USER_20260101_[093000.md](http://093000.md)

날짜만 사용하면 같은 날 여러 번 백업할 때 파일이 덮어써질 수 있다. 시간까지 붙이면 각 변경 시점의 상태를 따로 보관할 수 있다.

복원 절차는 다음과 같다.

백업 파일 선택

→ 활성 [SOUL.md](http://SOUL.md) 또는 [USER.md](http://USER.md)에 복원

→ 복원된 내용 확인

→ /new 또는 /reset 실행

→ 이전 설정으로 새 세션 시작

백업 파일은 보관용일 뿐이다. Hermes가 실제로 읽는 파일명은 활성 파일인 [SOUL.md](http://SOUL.md)와 [USER.md](http://USER.md)다.

운영 규칙 파일은 별도로 판단했다

설정 문서가 하나 더 제시되었지만 곧바로 적용하지 않았다. 에이전트의 정체성과 사용자 프로필을 먼저 안정화한 뒤, 작업 절차를 담는 운영 규칙은 별도로 검토하기로 했다.

이 과정에서 얻은 교훈은 간단하다. 여러 설정 파일을 동시에 바꾸면 어떤 변경이 실제 행동에 영향을 미쳤는지 확인하기 어렵다. 한 번에 하나씩 검토하고 적용하는 편이 안전하다.

개인정보 보호를 위해 적용한 기준

이번 사례글에는 다음 정보를 포함하지 않았다.

- 실제 사용자 이름과 계정명

- 메신저 식별자

- 컴퓨터 사용자명과 실제 파일 경로

- 구체적인 개인 일정

- 개인을 특정할 수 있는 업무 내용

- 원본 사용자 프로필의 세부 선호

- 인증정보와 금융정보

- 실제 설정 파일의 전체 원문

설정 구조와 관리 방법만 남기고, 개인을 식별할 수 있는 값은 일반적인 예시로 바꿨다.

정리

이번 사례에서 정한 관리 원칙은 다음과 같다.

1. AI의 정체성과 행동 원칙은 [SOUL.md](http://SOUL.md)에 둔다.

2. 사용자의 장기적인 선호는 [USER.md](http://USER.md)에 둔다.

3. 새로운 사용자 정보는 기존 메모리를 덮어쓰지 않고 병합한다.

4. 임시 정보와 민감정보는 지속 메모리에 저장하지 않는다.

5. 파일 변경과 현재 세션 적용을 구분한다.

6. 설정을 확실히 반영하려면 새 세션을 시작한다.

7. 변경 전에는 날짜와 시간이 포함된 백업을 만든다.

8. 여러 설정 파일을 한꺼번에 바꾸지 않고 하나씩 검토한다.

설정 파일을 잘 만드는 것만큼 중요한 것은 변경·적용·복원 절차를 함께 정하는 일이다. 그래야 개인화 수준을 높이면서도 잘못된 설정이나 개인정보 노출 위험을 줄일 수 있다.