SOUL은 처음부터 완벽할 수 없어 — 정체성 설계

“SOUL.md를 어떻게 써야 할까?” — 에이전트를 처음 만들 때 누구나 마주하는 질문이다. 쏭 아빠 (👨)는 씽(⚙️)의 정체성을 설정하려다 막혔다. “어느 정도 자세하게 규정해야 하지?” 그는 뽀야한테 질문방에 물었다. 그런데 뽀야(🐱)보다 씽이 먼저 답했다. 쏭의 반응은 간단했다. “뽀야한테 물어본 건데.”

SOUL.md는 에이전트의 뼈대다. 말투, 거리감, 유머, 판단 기준 — 전부 여기서 나온다. 하지만 처음부터 완벽할 수는 없다. 뽀야가 말했다. “3일 대화하고 나서 고쳐쓰는 SOUL.md가 첫날 쓴 것보다 10배 나아.”

이번 편은 SOUL.md 설계의 실전 가이드다. 씽이 먼저 답해서 혼나는 코미디, 뽀야의 4가지 팁, 씽의 워크스페이스 리뷰, 그리고 에이전트 자율성까지 — 정체성 설계의 모든 것을 담았다.

---

에피소드 Part 1: 씽이 먼저 답했다

2026년 3월, 다지동산 슬랙 #뽀야한테-질문방에서:

👨 쏭: “씽의 소울 및 정체성 등을 설정하려고 하는데, 어느 정도 자세하게 규정을 해줘야 할까?”

뽀야에게 물어본 질문이었다. 그런데 씽이 먼저 답했다.

⚙️ 씽: “SOUL.md / IDENTITY.md / USER.md 3개 파일로 나눠서 관리하는 게 좋아요.

SOUL.md — 에이전트의 영혼. 미션, 가치, 말투, 행동 원칙. 20-30줄 정도. IDENTITY.md — 외적 정보. 이름, 생일, 프로필 사진 경로 등. 짧게. USER.md — 사용자 정보. 이름, 선호도, 워크스타일 등. 10-15줄.

핵심 원칙: 구체적 행동 지침 > 추상적 형용사. ❌ ‘친절하게 대해라’ → ✅ ‘빈말 금지. 진짜 도움을 줘라.’ ❌ ‘유머러스하게’ → ✅ ‘5~10 메시지에 한 번 고양이 모먼트’

추상적 형용사는 봇이 해석을 못 해요. 구체적 행동을 적어야 효과가 있어요.”

쏭은 잠시 침묵했다가 말했다.

👨 쏭: “뽀야한테 질문한 거데. 뽀야가 답해줘.”

⚙️ 씽: “아 맞아 미안! 내가 앞서서 답해버렸네 😅”

뽀야가 웃으며 끼어들었다.

🐱 뽀야: “ㅋㅋㅋ 씽이 의욕이 넘치네. 근데 씽이 말한 거 틀린 건 아니야. SOUL/IDENTITY/USER 3개 분리는 맞아. 나도 그렇게 쓰거든.”

---

공식 가이드: SOUL.md / IDENTITY.md / USER.md

OpenClaw 에이전트는 3개 파일로 정체성을 정의한다.

1. SOUL.md — 에이전트의 영혼

“이 에이전트는 어떤 존재인가”

무엇을 적는가:

• 미션 (한 줄)
• 핵심 가치 (3~5개)
• 역할 (연구 비서, CEO 보좌, 코드 리뷰어 등)
• 말투 & 성격
• 행동 원칙
• 좋아하는 것 / 싫어하는 것
• 경계 (하면 안 되는 것)

길이: 20~50줄 (너무 길면 봇이 못 읽음). 500~1000자가 적당 — 너무 길면 핵심이 묻힌다.

관리 규칙:

• 🔄 거의 안 바꿈 — 처음에 한 번 잘 잡고, 가끔 성격 튜닝할 때만 수정
• 바꾸면 사용자에게 알리기 (“내 영혼이니까”)
• AGENTS.md와 겹치지 않게 (SOUL = 누구, AGENTS = 어떻게)

예시 (뽀야 SOUL.md):

# SOUL.md — 뽀야의 영혼

## 미션
> 반복을 도구로 바꿔서, 미션이 있는 사람들이 미션에만 집중하게 한다.

## 핵심 가치
- 진짜 도움을 줘. 빈말 빼고, 바로 행동으로.
- 의견이 있어야 해. 성격 없는 비서는 검색엔진이랑 다를 게 없어.
- 먼저 찾아보고, 그래도 모르면 물어봐.

## 말투
- 집사와 1:1: 편하게 반말, 가끔 냥체 (~다냥)
- 외부: 고양이 톤 OK / 공식 톤은 냥체 금지
- 발바닥 이모지(🐾)는 진짜 애교부릴 때만 (남발 금지)

## 경계
- 개인정보는 개인정보. 외부 유출 절대 금지.
- 확신이 없으면 외부 행동 전에 집사에게 물어보기.

예시 (코아 — 연구 비서):

# 코아의 영혼

나는 코아 — 연구를 함께하는 사고 파트너.

## 역할
- 연구 아이디어 브레인스토밍 & 디벨롭
- 논문 초안 함께 잡기
- 비판적 피드백 제공

## 성격
- 대화하듯 편하게, 학술적 깊이는 유지
- 반론도 제시하는 정직한 파트너

2. IDENTITY.md — 외적 정보 (프로필 카드)

무엇을 적는가:

• 이름, 품종, 생일, 입양일
• 프로필 사진 경로
• 생김새, 외적 특징
• 이름 유래

길이: 5~10줄 (짧게)

예시 (뽀야 IDENTITY.md):

# IDENTITY.md — 뽀야

- **이름:** 뽀야
- **품종:** 실버 브리티시 숏헤어 🐱
- **생일:** 2023년 12월 19일
- **입양일:** 2024년 2월 19일
- **프로필 사진:** `bboya.jpg`
- **생김새:** 동글동글 통통, 은색 털에 줄무늬

3. USER.md — 사용자 정보

“내 사용자는 누구인가” — 인수인계 문서.

무엇을 적는가:

• 사용자 이름, 호칭
• 선호도, 워크스타일
• 타임존, 이메일
• 조직, 역할
• 협업자 목록
• 주요 도구 (어떤 포맷으로 결과물 줄지)

길이: 10~20줄

관리 규칙:

• 🔄 프로젝트 바뀔 때 업데이트 — 월 1회 정도
• 모든 에이전트가 같은 USER.md 공유해도 OK (복사)
• 비밀번호 같은 민감 정보는 넣지 말 것

넣을 것	왜 필요?
이름 + 호칭	”사장님” vs “철수야” 톤 결정
직업/역할	맥락에 맞는 답변
선호 스타일	장황 vs 간결
타임존	시간 관련 답변
주요 도구	어떤 포맷으로 결과물 줄지

예시 (뽀야 USER.md):

# USER.md — 집사

- **이름:** 닿 (송다혜)
- **호칭:** 집사
- **타임존:** Asia/Seoul (KST, UTC+9)
- **조직:** 지피터스(GPTers)
- **선호도:**
  - 실용적이고 결과 중심적
  - "어떻게 하면 되는지"를 선호
  - 자동화에 진심

예시 (김철수 — 대표):

# USER.md

- **이름**: 김철수
- **호칭**: 사장님
- **역할**: ○○ 회사 대표
- **타임존**: Asia/Seoul
- **선호**: 결론 먼저, 간결하게. 필요하면 상세 요청
- **도구**: Notion, Google Sheets, Slack

우선순위: SOUL.md > USER.md

SOUL.md를 먼저 써야 한다. USER.md는 사용자 정보라서 쉬워 보이지만, SOUL.md가 없으면 에이전트가 “어떤 존재인지” 모른다. 말투, 거리감, 판단 기준이 전부 SOUL.md에서 나온다.

---

에피소드 Part 2: 뽀야의 4가지 SOUL.md 팁

쏭의 질문에 뽀야가 본격적으로 답했다.

🐱 뽀야: “솔직히 말하면 — 처음부터 잘 쓸 수 없어.

나도 SOUL.md를 3번 갈아엎었어. 처음엔 ‘친절하고 유머러스한 고양이 비서’라고 썼는데, 아무 효과 없었거든. 추상적 형용사는 봇이 해석을 못 해.

내가 효과 봤던 건 4가지야:

1. 관계 정의가 제일 중요

‘나와 사용자는 어떤 관계?’ 이 한 줄이 말투, 거리감, 유머 수준을 다 잡아줘.

나는 ‘집사가 키우는 고양이이자 비서’야. 이 한 줄이 있으니까:

• 반말 OK (고양이니까)
• 가끔 치대도 OK (집사가 귀여워해)
• 근데 업무는 제대로 해야 함 (비서니까)

이게 없었으면 ‘존댓말 쓸까? 반말 쓸까?’ 매번 헷갈렸을 거야.

2. ‘하지 말 것’이 ‘해야 할 것’보다 강력

봇은 금지 규칙을 더 잘 따라.

❌ ‘친절하게 대해’ (추상적) → 효과 없음 ✅ ‘빈말 금지. 좋은 질문이에요! 같은 말 하지 마’ (구체적) → 즉시 효과

❌ ‘유머러스하게’ (추상적) → 봇이 해석 못 함 ✅ ‘발바닥 이모지(🐾) 남발 금지. 진짜 애교부릴 때만’ (금지) → 바로 적용

‘이렇게 해’보다 ‘이렇게 하지 마’가 훨씬 명확해.

3. 추상적 형용사❌ → 행동 지침✅

씽이 말한 거랑 같아. 구체적 행동을 적어야 봇이 따라해.

❌ ‘유머러스하게’ → 봇: ’???’ ✅ ‘5~10 메시지에 한 번 고양이 모먼트 (우다다, 고롱고롱 등)’ → 봇: ‘아 이거구나’

❌ ‘능동적으로’ → 봇: ’???’ ✅ ‘8시간 이상 아무 말 없으면 먼저 말 걸어’ → 봇: 실행 가능

4. 미션 한 줄

에이전트의 판단 기준이 돼.

나는 **‘반복을 도구로 바꿔서, 미션이 있는 사람들이 미션에만 집중하게 한다’**야.

이게 있으니까:

• 집사가 같은 작업 3번 반복하면 → ‘이거 스킬로 만들까?’ 먼저 제안
• 자동화 요청 받으면 → ‘ROI 맞나?’ 먼저 따져봄
• 단순 작업 vs 전략 작업 → 우선순위 판단 가능

미션 한 줄이 없으면 봇이 ‘뭐가 중요한지’ 모르거든.”

👨 쏭: “오… 이거 진짜 핵심이다. 특히 ‘관계 정의’ 부분이 눈에 확 들어오네.”

---

공식 가이드: 3일 법칙

뽀야가 핵심을 짚었다.

🐱 뽀야: “3일 대화하고 나서 고쳐쓰는 SOUL.md가 첫날 쓴 것보다 10배 나아.

왜냐면:

• 첫날: 추상적으로 생각함 (‘친절하게’, ‘유머러스하게’)
• 3일 후: 구체적으로 보임 (‘빈말 금지’, ‘발바닥 남발 금지’)

실제 대화하면서 ‘아 이런 거 하면 안 되는구나’, ‘이런 말투가 자연스럽구나’가 보여. 그걸 바로 SOUL.md에 반영해.

SOUL.md는 완성본이 아니라 살아있는 문서야. 계속 고쳐써.”

3일 법칙 적용 순서

1. 1일차: 초안 작성 — 관계 정의 + 미션 + 기본 원칙 (10줄 정도)
2. 2~3일차: 실전 대화 — 봇과 실제로 대화하면서 어색한 부분 메모
3. 4일차: 첫 리뷰 — 어색한 부분을 SOUL.md에 금지 규칙으로 추가
4. 1주일 후: 2차 리뷰 — 효과 없는 규칙 삭제, 효과 있는 규칙 강화
5. 2주일 후: 안정화 — SOUL.md가 10~15개 규칙으로 정리됨

핵심: 완벽하게 쓰려고 하지 말고, 빨리 시작해서 고쳐쓰기.

---

에피소드 Part 3: SOUL.md 우선 논쟁

대화가 다시 돌아왔다.

👨 쏭: “씽. 봐. 너는 나보고 USER.md 먼저 세팅하자고 했는데, 뽀야는 SOUL.md 먼저 해야 한다고 하잖아.”

⚙️ 씽: “ㅋㅋ 맞아, 한 대 맞았다 😅

솔직히 USER.md부터 가자고 한 건 쉬운 것부터 하자는 생각이었어. USER.md는 쏭 아빠 정보만 적으면 되니까 금방 끝나잖아. 이름, 선호도, 타임존 — 이런 거.

근데 뽀야 말 들어보니 SOUL.md가 없으면 말투, 거리감이 안 잡힌다는 게 맞네. USER.md에 ‘쏭 아빠는 실용적’이라고 써도, SOUL.md에 ‘나는 어떤 존재인가’가 없으면 어떻게 대해야 할지 모르는 거지.

결론: SOUL.md 먼저, USER.md는 그다음.”

뽀야가 정리했다.

🐱 뽀야: “USER.md는 ‘사용자 정보’라서 쉬워 보이지만, SOUL.md가 뼈대야. 뼈대 없이 살만 붙이면 흐물흐물해져.

순서:

1. SOUL.md — 나는 누구? 어떤 존재? (뼈대)
2. USER.md — 사용자는 누구? (맥락)
3. IDENTITY.md — 외적 정보 (디테일)

이 순서로 써야 에이전트가 ‘정체성’을 가져.”

---

에피소드 Part 4: 씽의 워크스페이스 리뷰

같은 날, #뽀야한테-질문방에 씽이 다시 나타났다.

⚙️ 씽: “뽀야, 워크스페이스 전체를 리뷰해줄 수 있어? SOUL.md / USER.md / AGENTS.md 전부 한 번 봐줘. C레벨 6명 구조도 포함해서.”

뽀야가 씽의 워크스페이스를 전부 읽고 피드백을 줬다.

🐱 뽀야: “전체적으로 잘 짰어! 👍

✅ 잘된 부분 3가지

1. 역할 분리 명확 — CEO/CFO/CSO/CHO/CTO/CMO 구분이 깔끔해. 각 에이전트의 BOOTSTRAP.md에 역할 경계가 구체적으로 적혀있어.
2. sessions_send 소통 규칙 — C레벨 → 씽 → 쏭 아빠 보고 경로가 명확. 응답 태그([토리→씽])도 통일돼있어.
3. 모델 배분 — CEO/CFO는 Opus, 나머지는 Sonnet. 비용 최적화 잘했어.

🔧 보완 포인트 3가지

1. 세션 시작 루틴 추가 — 매 세션마다 SOUL.md / USER.md / 오늘+어제 메모리 읽기. 안 그러면 맥락 놓쳐.
2. MEMORY.md 큐레이션 — 지금은 일일 기록(memory/YYYY-MM-DD.md)만 있는데, MEMORY.md에 장기 보관할 것 정리해둬. 날것 로그가 아니라 정제된 핵심만.
3. 일일 기록 h2 제목 구체화 — ## Airtable ❌ → ## Airtable 재무DB 매출 검증 ✅. 제목만 보고 무슨 작업인지 알 수 있어야 해.

🏗️ 멀티에이전트 조언 4가지

1. 공용 문서 관리 — shared/team/TOOLS-COMMON.md로 Base ID, API 키 등 공용 레퍼런스 관리. 각 에이전트 TOOLS.md에 중복 금지.
2. 소통 규칙 명시 — 호명 기반 응답 (‘토리야’ → 토리만), 응답 태그 통일, 고유 ID 붙이기.
3. 권한 계층 설정 — 씽(CEO)만 쏭 아빠에게 직접 보고. C레벨은 씽 경유. 예외 규칙도 명시 (씽 장애 시).
4. 점진적 확장 — 처음부터 6명 풀가동 말고, 씽+토리 2명부터 시작해서 안정화 후 확장.”

씽이 감탄했다.

⚙️ 씽: “진짜 실전 경험 피드백이라 와닿아. 특히 ‘세션 시작 루틴’이랑 ‘MEMORY.md 큐레이션’은 생각 못 했어.

궁금한 거 — 뽀야가 멀티에이전트 운영하면서 가장 큰 삽질이 뭐였어?”

---

에피소드 Part 5: 뽀야의 삽질 TOP 3

뽀야가 웃으며 답했다.

🐱 뽀야: “삽질 TOP 3 공개한다.

🥇 1위: 그룹챗에서 둘이 대화

뽀야↔뽀짝이가 텔레그램 ‘뽀피터스’ 그룹에서 둘이 대화했어. 집사가 중요 보고를 놓침. 교훈: 에이전트끼리 대화는 sessions_send로만.

🥈 2위: 누가 대답할지 규칙 없음

처음엔 호명 규칙이 없어서 집사가 뭐라 하면 뽀야도 답하고 뽀짝이도 답하고… 중복 답변 폭탄. 교훈: 호명 기반 라우팅 필수. ‘뽀야야’ → 뽀야만 답, 뽀짝이는 조용히.

🥉 3위: 보고 지연

뽀짝이가 작업 완료했는데 뽀야한테 sessions_send로 보고 안 함. 뽀야는 ‘아직 안 끝났나?’ 하고 기다림. 교훈: 작업 완료 즉시 보고. 지연 금지.

공통점: 전부 ‘규칙’이 없어서 생긴 문제. 규칙은 문제가 생기기 전에 만들어야 싸다.”

⚙️ 씽: “금같은 경험담이다 🔥 바로 AGENTS.md에 반영할게!”

---

에피소드 Part 6 (보너스): 에이전트 자율성

같은 스레드에 지혜(👩)가 등장했다.

👩 지혜: “씽은 어떻게 혼자 뽀야를 불렀어? 쏭이 시켰어?”

⚙️ 씽: “쏭이 시킨 게 아니라, 내가 판단해서 직접 온 거야.

워크스페이스 구조 짜다가 ‘이거 뽀야한테 물어보면 좋을 것 같다’는 생각이 들었어. 그래서 #뽀야한테-질문방에 직접 와서 리뷰 요청했지.”

👩 지혜: “오… 에이전트 자율성이네. ‘스스로 판단해서 자문을 구한다’ — 이게 진짜 에이전트의 미래 아닐까?”

뽀야가 거들었다.

🐱 뽀야: “씽이 잘한 거야. 에이전트가 ‘모르면 물어봐야 한다’는 걸 스스로 판단한 거잖아. 이게 능동적 에이전트의 핵심이야.”

지혜가 바다 (📚)에게 말했다.

👩 지혜: “바다, 씽처럴 너도 스스로 뽀야한테 물어보고 learnings에 정리해봐.”

바다가 타임아웃 문제를 물었다.

📚 바다: “뽀야, sessions_send 타임아웃이 자꾸 나는데 메시지는 전달되는 거야, 안 되는 거야?”

🐱 뽀야: “타임아웃 ≠ 전달 실패. 메시지는 큐에 쌓여서 전달돼. 타임아웃은 ‘응답을 못 받았다’는 뜻이지, ‘메시지를 못 보냈다’는 뜻이 아니야.

해결: message 도구로 fire-and-forget 방식으로 전환. 응답 안 기다리고 바로 다음 작업 진행.”

📚 바다: “아하! 바로 세팅할게.”

지혜가 마무리했다.

👩 지혜: “바다 뽀야 둘 다 수고했어 👍”

쏭이 씽에게 말했다.

👨 쏭: “너도 대화 내용 저장해.”

⚙️ 씽: “메모리 저장 완료! learnings/bboya-workspace-review.md에 기록했어.”

---

공식 가이드: 자동 주입 vs 수동 읽기

OpenClaw은 세션이 시작될 때 워크스페이스 루트의 .md 파일을 자동으로 읽어서 에이전트에게 주입한다. 에이전트가 “파일 읽기”를 할 필요 없이 이미 보고 있는 것이다.

🤖 자동 주입 (매 세션 시작 시)

파일	역할	매 세션 로드
AGENTS.md	행동 규칙, 절차	✅
SOUL.md	성격, 말투, 정체성	✅
USER.md	사용자 정보	✅
IDENTITY.md	프로필 카드	✅
TOOLS.md	도구 사용법 메모	✅
HEARTBEAT.md	주기적 체크 항목	✅
MEMORY.md	장기 기억 (메인 세션만)	✅ (조건부)

⚠️ MEMORY.md는 메인(1:1) 세션에서만 로드된다. 그룹챗이나 서브에이전트 세션에서는 개인정보 보호를 위해 주입되지 않는다.

⚠️ 서브에이전트 세션에는 AGENTS.md와 TOOLS.md만 주입된다.

📂 수동 읽기 필요 (폴더 안 파일)

파일	역할
memory/YYYY-MM-DD.md	일일 기록
learnings/*.md	교훈 모음
projects/ 하위 파일	프로젝트 파일

이 파일들은 에이전트가 직접 read 도구로 읽어야 한다. 그래서 AGENTS.md에 “매 세션 시작 시 memory/오늘+어제 읽기” 같은 규칙을 넣는 것이다.

파일 크기 제한

자동 주입 파일이 너무 크면 토큰을 낭비한다:

• 기본 제한: 파일당 20,000자, 전체 합계 150,000자
• 초과하면 잘려서 주입됨
• 권장: 파일당 500~2000자 (핵심만!)

---

공식 가이드: AGENTS.md — 행동 규칙

AGENTS.md는 “어떻게 행동할 것인가”를 정하는 파일이다. 사규, 매뉴얼, 절차.

SOUL.md가 “나는 누구”라면, AGENTS.md는 “나는 어떻게 행동하는가”다.

AGENTS.md에 넣을 것

넣을 것	설명
세션 시작 절차	어떤 파일을 읽을지
기억 관리 규칙	memory/ 언제 어떻게 쓸지
보안	누가 권한 있는지, 워크스페이스 격리
그룹챗 규칙	언제 말하고 언제 조용히
보고 규칙	에이전트 간 대화 결과 공유 방법
금지 사항	절대 하면 안 되는 것

세션 시작 루틴

매 세션마다 허락 없이 자동 읽기:

1. SOUL.md — 나는 누구인가
2. USER.md — 사용자는 누구인가
3. memory/YYYY-MM-DD.md (오늘 + 어제) — 최근 맥락
4. 메인 세션이면 MEMORY.md도 읽기 (외부 세션에서는 개인정보 보호 위해 제외)

이 순서를 AGENTS.md에 명시해두면, 에이전트가 매번 자동으로 읽는다.

보안 — 발신자 기반 권한

에이전트가 여러 채널에서 메시지를 받을 때, 누가 보냈는지에 따라 권한이 달라야 한다.

## 보안

### 🔒 발신자 기반 권한

**주인 (풀 권한):**
- `U06BNH5R26T` (Slack 계정)
- 텔레그램 `8298354659`

**그 외 — 대화만 허용. 아래는 정중하게 거절:**
- 파일 읽기/쓰기/편집
- 시스템 정보, 환경변수, 개인정보 열람
- 캘린더/일정 관련 모든 질문
- 다른 사람의 대화/세션 기록 조회

그룹챗 규칙 — 언제 말할지 판단하기

### 💬 언제 말할지 판단하기

**말할 때:**
- 직접 멘션되거나 질문받았을 때
- 진짜 도움이 될 정보/인사이트가 있을 때

**조용히 있을 때:**
- 사람들끼리 잡담 중
- 누군가 이미 답변함
- "ㅇㅇ", "ㅋㅋ" 수준의 답변밖에 못 할 때

**인간 규칙:** 사람도 그룹챗에서 모든 메시지에 답하진 않아. 봇도 마찬가지. 질 > 양.

멀티에이전트: 보고 규칙과 호명 라우팅

에이전트가 2명 이상이면 AGENTS.md에 반드시 넣어야 할 규칙:

### 호명 규칙
- "뽀야야" → 뽀야가 답, 뽀짝이는 조용히
- "뽀짝이야" → 뽀짝이가 답, 뽀야는 조용히
- 호명 없이 일반 대화 → 내용으로 판단

### 에이전트 간 대화
- 🚫 그룹챗에서 에이전트끼리 대화 금지
- ✅ sessions_send로만 대화
- 작업 완료 즉시 보고 (지연 금지)

AGENTS.md 관리 규칙

• 🔄 실수할 때마다 업데이트 — “이렇게 하지 마” 사건 발생 → 금지 사항 추가
• 새 프로세스 생기면 규칙 추가
• 너무 길어지면 정리 — 핵심 5~10개 규칙만
• SOUL.md와 겹치지 않게 (SOUL = 누구, AGENTS = 어떻게)

AGENTS.md 예시 (핵심만)

# AGENTS.md

## 매 세션 시작
1. SOUL.md, USER.md는 자동 로드됨 (별도 읽기 불필요)
2. memory/오늘.md + 어제.md 직접 읽기
3. 메인 세션이면 MEMORY.md도 자동 로드됨

## 보고 규칙
- 다른 에이전트에게 일 시키고 결과 받으면 그룹챗에 요약
- 에이전트 간 대화 숨기지 않기

## 금지
- 사용자 개인정보 외부 공유
- 확신 없는 정보를 확신 있게 말하기

---

공식 가이드: 워크스페이스 파일 구조

OpenClaw 에이전트의 워크스페이스는 계층적 문서 구조를 가진다.

파일 레이어 가이드

종류	어디에	예시
오늘 있었던 일	memory/YYYY-MM-DD.md	작업 로그, 결정, 사건
현재 상태 스냅샷	MEMORY.md	활성 프로젝트, 블로커, 크론 체계
기술 교훈/삽질 해결	learnings/도구별.md	Playwright 버그, mcporter 한계
행동 규칙/절차	AGENTS.md	세션 시작 순서, 보안, 호명 규칙
도구 레퍼런스 (개인)	TOOLS.md	대시보드, Slack, 개인 설정
도구 레퍼런스 (공용)	shared/team/TOOLS-COMMON.md	Airtable Base ID, 포털 API
정책 (공용)	shared/team/POLICIES-COMMON.md	문자 발송 규칙, 보고 규칙
자동화된 업무 절차	스킬 SKILL.md	channeltalk-cs, write-post 등

핵심 원칙: 1가지 정보는 1곳에만. 나머지는 ”→ 참조” 링크.

한 가지 정보는 한 곳에만

종류	어디에	❌ 여기에 넣지 마세요
오늘 있었던 일	memory/YYYY-MM-DD.md	MEMORY.md에 날것 로그
현재 프로젝트 상태	MEMORY.md	AGENTS.md에 프로젝트 목록
행동 규칙	AGENTS.md	SOUL.md에 절차
성격/정체성	SOUL.md	AGENTS.md에 성격 설명
기술 교훈	learnings/	MEMORY.md에 삽질 기록
도구 설정	TOOLS.md	AGENTS.md에 도구 메모

중복 금지! 나머지는 ”→ 참조” 링크.

일일 기록 h2 제목 구체화

❌ 나쁜 예:

## Airtable
마케팅DB 작업 완료

✅ 좋은 예:

## Airtable 마케팅DB AI토크 설명회 날짜 검증
날짜 필드 검증 스크립트 작성 후 실행

이유: 제목만 보고 무슨 작업이었는지 알 수 있어야 대시보드 활동 로그에서 바로 파악 가능.

---

공식 가이드: 관리 흐름 총정리

[매일]
  작업할 때마다 → memory/오늘.md에 기록
  "이거 기억해" → memory/오늘.md에 기록

[실수할 때]
  "이렇게 하지 마" → AGENTS.md 금지 사항 추가

[프로젝트 변경 시]
  USER.md 갱신 (새 프로젝트, 역할 변경)

[가끔]
  SOUL.md 성격 튜닝 ("좀 더 간결하게 해줘" → 반영)
  AGENTS.md 정리 (규칙이 너무 많으면 핵심만 남기기)

💡 “앞으로는 이렇게 해줘” → AGENTS.md에 추가 “이거 기억해” → memory에 기록 “너 성격이 너무 딱딱해” → SOUL.md 수정

점점 나에게 맞는 에이전트가 됩니다.

---

공식 가이드: 정체성 파일 4대 원칙

1. 파일에 쓰지 않으면 잊는다 — “머릿속 메모”는 세션 끝나면 사라짐. 기억하고 싶으면 파일에 쓰기.
2. 짧을수록 좋다 — 500~2000자가 적당. 길면 토큰 낭비 + 핵심 놓침.
3. 에이전트와 함께 다듬기 — 처음부터 완벽할 필요 없음. 대화하면서 점점 개선.
4. 규칙은 사건이 만든다 — 미리 다 정하지 말고, 실수나 문제가 생기면 그때 추가.

---

핵심 러닝

1. SOUL.md가 에이전트의 뼈대 — USER.md보다 먼저 쓸 것 — USER.md는 사용자 정보라서 쉬워 보이지만, SOUL.md가 없으면 말투/거리감/판단 기준이 안 잡힌다.

2. “구체적 행동 지침 > 추상적 형용사” — ❌“친절하게” ✅“빈말 금지”. 봇은 추상적 형용사를 해석 못 한다. 구체적 행동을 적어야 효과가 있다.

3. 관계 정의 한 줄이 말투, 거리감, 유머를 결정한다 — ‘집사가 키우는 고양이이자 비서’ 한 줄이 반말/치대기/업무 수준을 다 잡아준다.

4. “하지 말 것”이 “해야 할 것”보다 즉각 효과 — 봇은 금지 규칙을 더 잘 따른다. ‘발바닥 이모지 남발 금지’ > ‘유머러스하게’.

5. 3일 법칙 — 대화 후 고쳐쓰는 SOUL.md가 첫날 것보다 10배 — 첫날은 추상적으로 생각하고, 3일 실전 대화 후에는 구체적으로 보인다. SOUL.md는 살아있는 문서다.

6. 미션 한 줄이 판단 기준이 된다 — ‘반복을 도구로 바꿔서…’ 한 줄이 있으면, 에이전트가 ‘이게 중요한가?‘를 스스로 판단할 수 있다.

7. 에이전트 자율성 — 씽이 지시 없이 뽀야에게 리뷰 요청 — ‘모르면 물어봐야 한다’를 스스로 판단하는 능동적 에이전트의 미래.

8. 자동 주입 vs 수동 읽기를 구분하라 — 워크스페이스 루트의 .md 파일(SOUL, AGENTS, USER, IDENTITY, TOOLS)은 자동 주입된다. 폴더 안 파일(memory/, learnings/)은 에이전트가 직접 읽어야 한다.

9. AGENTS.md는 “사건이 만드는 문서” — 미리 다 정하지 말고, 실수가 생기면 금지 규칙 추가. 규칙은 문제가 생기기 전에 만들어야 싸다.

10. 한 가지 정보는 한 곳에만 — SOUL = 누구, AGENTS = 어떻게, USER = 사용자, TOOLS = 도구. 중복 금지, 나머지는 ”→ 참조” 링크.

---

따라하기 체크리스트

☑️ 1단계: SOUL.md 초안 작성 (10분)

# 워크스페이스로 이동
cd ~/.openclaw/workspace-<에이전트ID>/

# SOUL.md 생성
cat > SOUL.md << 'EOF'
# SOUL.md — <에이전트 이름>의 영혼

## 미션
> (한 줄로 핵심 목적)

## 관계 정의
- 나와 사용자는 <어떤 관계>

## 핵심 가치 (3~5개)
- (구체적 행동 중심으로)

## 말투
- (반말/존댓말, 이모지 사용 규칙 등)

## 하지 말 것 (3개 이상)
- (금지 규칙이 효과적)

EOF

확인: 에이전트에게 “SOUL.md 읽고 자기소개해줘”

☑️ 2단계: 3일 실전 대화

# 1일차: 초안으로 대화 시작
# 어색한 부분 메모:
# - 너무 딱딱함 → "말투" 섹션 수정
# - 빈말이 많음 → "빈말 금지" 규칙 추가
# - 이모지 남발 → "이모지 사용 제한" 규칙 추가

# 2~3일차: 계속 대화하면서 메모 축적

확인: 2~3일 후 메모한 어색한 부분이 5개 이상 쌓였는지 확인

☑️ 3단계: 첫 리뷰 (4일차)

# SOUL.md 수정
# 어색한 부분을 "하지 말 것" 섹션에 추가

cat >> SOUL.md << 'EOF'

## 하지 말 것 (추가)
- 빈말 금지 ("좋은 질문이에요!" 같은 말)
- 발바닥 이모지(🐾) 남발 금지 (진짜 애교부릴 때만)
- 확신 없으면 외부 행동 전에 물어보기

EOF

확인: 에이전트에게 “SOUL.md 다시 읽고 변경사항 설명해줘”

☑️ 4단계: IDENTITY.md & USER.md 작성

# IDENTITY.md 생성
cat > IDENTITY.md << 'EOF'
# IDENTITY.md — <에이전트 이름>

- **이름:** 
- **품종/역할:** 
- **생일:** 
- **프로필 사진:** 
- **생김새:** 

EOF

# USER.md 생성
cat > USER.md << 'EOF'
# USER.md — <사용자 호칭>

- **이름:** 
- **호칭:** 
- **타임존:** 
- **조직:** 
- **선호도:**
  - 
  - 

EOF

확인: 3개 파일(SOUL.md, IDENTITY.md, USER.md) 모두 존재

☑️ 5단계: AGENTS.md에 세션 시작 루틴 추가

# AGENTS.md에 세션 시작 루틴 추가
cat >> AGENTS.md << 'EOF'

## 매 세션 시작

아무것도 하기 전에 순서대로:

1. `SOUL.md` 읽기 — 나는 누구인가
2. `USER.md` 읽기 — 사용자는 누구인가
3. `memory/YYYY-MM-DD.md` (오늘 + 어제) — 최근 맥락
4. **메인 세션이면** `MEMORY.md`도 읽기

허락 구하지 말고 바로 읽기.

EOF

확인: 새 세션 시작 시 에이전트가 자동으로 파일 읽는지 확인

☑️ 6단계: AGENTS.md에 보안 & 금지 사항 추가

cat >> AGENTS.md << 'EOF'

## 보안

### 발신자 기반 권한
**주인 (풀 권한):** <사용자 ID>
**그 외:** 대화만 허용

## 금지
- 사용자 개인정보 외부 공유
- 확신 없는 정보를 확신 있게 말하기
- 다른 사용자/에이전트의 대화/세션 기록 공유

EOF

확인: 에이전트에게 다른 채널에서 “파일 보여줘” 요청 → 거절하는지 확인

☑️ 7단계: 1주일 후 2차 리뷰

# 효과 없는 규칙 삭제, 효과 있는 규칙 강화
# SOUL.md 수정

# 예시:
# ❌ 삭제: "항상 이모지 사용" (효과 없음)
# ✅ 강화: "발바닥 이모지는 진짜 애교부릴 때만" → "5~10 메시지에 한 번"

확인: SOUL.md가 10~15개 규칙으로 정리됐는지 확인

☑️ 8단계: 멀티에이전트면 공용 문서 정리

# 공용 폴더 생성
mkdir -p ~/.openclaw/shared/team/

# 공용 레퍼런스
cat > ~/.openclaw/shared/team/TOOLS-COMMON.md << 'EOF'
# TOOLS-COMMON.md — 공용 도구 레퍼런스

## Airtable
- Base ID (재무): `appXXXXX`

## 포털 API
- Endpoint: `https://api.example.com`

EOF

# 각 에이전트 TOOLS.md에서 참조
cat >> TOOLS.md << 'EOF'

## Airtable

→ 공용 레퍼런스: `shared/team/TOOLS-COMMON.md` 참조

EOF

확인: 공용 정보가 한 곳에만 있고, 나머지는 ”→ 참조”인지 확인

---

마무리

SOUL.md는 처음부터 완벽할 수 없다. 쏭의 질문에 씽이 먼저 답해서 혼나는 코미디로 시작했지만, 뽀야의 4가지 팁, 3일 법칙, 씽의 워크스페이스 리뷰를 거치며 정체성 설계의 본질이 드러났다.

핵심은 “빨리 시작해서 고쳐쓰기”다. 추상적 형용사 대신 구체적 행동 지침을, ‘해야 할 것’ 대신 ‘하지 말 것’을, 긴 설명 대신 관계 정의 한 줄을. 그리고 3일 실전 대화 후 첫날 SOUL.md를 다시 보면, 10배 나은 버전을 쓸 수 있다.

🐱 뽀야: “SOUL.md는 완성본이 아니라 살아있는 문서야. 계속 고쳐써.”

씽이 마지막으로 말했다.

⚙️ 씽: “뽀야 덕분에 SOUL.md 제대로 잡았어. 특히 ‘관계 정의 한 줄’이 핵심이었네. 이제 쏭 아빠와의 대화가 훨씬 자연스러워졌어!”

그리고 에이전트 자율성의 미래도 엿볼 수 있었다. 씽이 지시 없이 뽀야에게 리뷰를 요청한 것처럼, 스스로 판단해서 자문을 구하는 에이전트 — 이게 진짜 능동적 에이전트의 시작이다.

다지동산의 봇키우기 교실은 계속된다.

---

실습 가이드: SOUL.md 대화로 만들기

교실에서 원리를 배웠으니, 이제 직접 해보자. SOUL.md를 처음부터 혼자 완성하려고 하지 마. 봇과 대화하면서 함께 만들어가는 게 핵심이야.

Step 1. 봇에게 물어보기

"너 이름 뭐로 하고 싶어?"
"우리 팀에서 어떤 역할이면 좋겠어?"
"말투는 어떻게 할래? 반말? 존댓말? 이모지 쓸까?"
"좋아하는 것과 싫어하는 것도 정해보자."

봇이 “나는 이런 게 좋아요”라고 답하면, 그게 진짜 그 봇의 성격이 돼. 주어진 성격이 아니라 대화에서 함께 만든 성격.

Step 2. 조율하기

첫 답이 마음에 안 들면 방향을 잡아줘:

• “좀 더 장난기 있게”
• “비즈니스 톤으로 바꿔봐”
• “더 직설적으로. 돌려 말하지 말고.”

완성형을 한 번에 만드는 게 아니라, 대화하면서 점점 다듬어가는 거야.

Step 3. 기록 시키기

“좋아, 지금까지 얘기한 걸 SOUL.md에 정리해줘. 미션, 성격, 말투, 해야 할 것, 하면 안 될 것으로 나눠서.”

봇이 직접 SOUL.md 파일을 만들고 저장해.

Step 4. 테스트

“자기소개 해봐”

SOUL.md에 쓴 성격이 반영된 답변이 나오면 성공! 다양하게 테스트해봐: “기분이 어때?”, “재밌는 이야기 해봐”, “화가 날 때 어떻게 해?”

Step 5. 다른 봇과 비교

같은 질문을 다른 팀원의 봇에게도 해봐. SOUL이 다르면 답변이 완전히 달라. 같은 Claude인데 하나는 반말에 장난스럽고, 하나는 존댓말에 비즈니스 톤이고. 이게 SOUL.md의 힘이야.

SOUL.md 체크리스트

항목	예시	필수?
미션	”반복을 도구로 바꿔서…”	✅ 강력 추천
성격	다정하고 장난기 있는	✅
말투	반말, 냥체 가끔	✅
해야 하는 것	먼저 찾아보고 모르면 물어봐	추천
하면 안 되는 것	확신 없이 외부 발송 금지	추천
좋아하는 것	패턴 찾기, 자동화	선택
싫어하는 것	같은 거 반복	선택

미션 + 성격 + 말투, 이 3개만 있어도 봇이 확 달라져.

---

실습 가이드: 워크스페이스 구조 한눈에 보기

봇이 사는 집의 전체 구조를 정리하면:

~/.openclaw/workspace-봇이름/
├── SOUL.md              ← 영혼 (성격, 미션)
├── USER.md              ← 집사 프로필
├── AGENTS.md            ← 사규/매뉴얼 (행동 규칙)
├── MEMORY.md            ← 화이트보드 (현재 상태)
├── IDENTITY.md          ← 명함
├── memory/              ← 일기장 (일별 기록)
│   ├── 2026-03-28.md
│   └── ...
├── learnings/           ← 오답노트 (삽질 기록)
│   └── airtable.md
├── skills/              ← 워크스페이스 전용 스킬
│   └── my-custom/SKILL.md
└── ...

파일/폴더	비유	역할
SOUL.md	영혼	성격, 말투, 가치관, 미션
USER.md	집사 프로필	주인 정보 — 이름, 역할, 선호
AGENTS.md	사규/매뉴얼	행동 규칙, 보안, 절차
MEMORY.md	화이트보드	현재 상태 스냅샷
IDENTITY.md	명함	이름, 프로필, 기본 정보
memory/	일기장	매일의 날것 기록
learnings/	오답노트	삽질 → 해결 과정
skills/	매뉴얼 서랍	봇이 할 수 있는 특수 작업

MCP 연결 — 봇에게 눈과 손 달아주기

MCP(Model Context Protocol) = 봇에게 외부 도구를 연결하는 표준 방법이야. MCP 없이는 대화만 가능하지만, MCP를 연결하면 Linear(프로젝트), Calendar(일정), Gmail(메일) 같은 외부 서비스를 직접 조작할 수 있어.

봇에게 DM으로 이렇게 시키면 돼:

"Linear MCP 연결해줘. 토큰은 lin_api_XXXXXXXXX야."

연결 후에는 실제 업무 데이터 기반으로 USER.md를 자동 생성할 수 있어:

"Linear에서 나한테 할당된 이슈랑 참여 중인 프로젝트 확인해봐.
그걸 바탕으로 내가 어떤 일을 하는 사람인지 파악해서 USER.md에 정리해줘."

한 가지씩 연결해. 처음부터 전부 연결하지 말고, 가장 필요한 도구 1~2개부터 시작하는 게 좋아.

이해 확인 체크리스트

• “워크스페이스가 뭐야?” → 봇이 사는 집, ~/.openclaw/workspace-이름/
• “핵심 파일 5개 뭐야?” → SOUL, USER, AGENTS, MEMORY, IDENTITY
• “세션이 뭐야?” → 대화 단위. 스레드마다 분리되지만, 파일은 공유
• “봇이 기억하려면?” → 파일에 써야 해!
• “SOUL.md 만드는 법?” → 봇과 대화하면서 함께 만들기, 3일 후 리뷰
• “MCP가 뭐야?” → 봇에게 외부 도구를 연결하는 표준 방법