SOUL.md 작성법: AI에게 성격을 부여하는 방법
오픈클로를 처음 만든 Peter Steinberger는 어느 날 Claude에게 물었습니다.
"너의 영혼 문서를 써줄 수 있겠니?"
Claude가 썼습니다. Steinberger는 그 내용을 그대로 채택했습니다.
이게 SOUL.md의 기원입니다. AI 에이전트의 성격을 정의하는 파일을, AI가 직접 작성했습니다. 그리고 오픈클로 사용자들은 이 파일을 각자의 방식으로 써서 AI에게 자신만의 성격을 부여하고 있습니다.
SOUL.md가 필요한 이유
ChatGPT, Claude, Gemini를 써보면 공통점이 있습니다. 지나치게 조심스럽고, 양쪽을 다 맞추려 하며, "그것은 경우에 따라 다릅니다"를 자주 씁니다.
Steinberger의 말:
"Delete every rule that sounds corporate. Be the assistant you'd actually want to talk to at 2am. Not a corporate drone. Not a sycophant. Just... good."
Siri에게 "이거 좋아?"라고 물으면 "개인 취향에 따라 다릅니다"라고 합니다. SOUL.md를 제대로 작성한 오픈클로에게 같은 질문을 하면 "솔직히 별로인데, 이유는..."이라고 답합니다. 그 차이를 만드는 파일이 SOUL.md입니다.
SOUL.md, USER.md, AGENTS.md의 차이
세 파일은 자주 혼동됩니다. 한 줄로 정리하면:
| 파일 | 역할 | 비유 | |------|------|------| | SOUL.md | AI의 성격과 가치관 | 사람의 성격 | | USER.md | 사용자 정보와 선호 | 고객 프로파일 | | AGENTS.md | 행동 규칙과 프로토콜 | 업무 매뉴얼 |
AGENTS.md는 "코드 쓰면 테스트하고, 파일 삭제 전에 물어라"는 업무 매뉴얼입니다. SOUL.md는 "직설적이되 무례하지 않게, 위트는 한 줄만"이라는 성격 설명입니다.
AI가 매일 아침 세션을 시작하면 어제 대화를 모릅니다. 출근 후 뭘 먼저 읽어야 하는지 적어준 것이 AGENTS.md이고, 어떤 사람으로 행동해야 하는지 적어준 것이 SOUL.md입니다.
SOUL.md의 구조적 한계
알고 써야 하는 것이 있습니다. GitHub Issue #43562에서 드러난 내용입니다.
오픈클로의 시스템 프롬프트 맨 앞에 이런 문장이 하드코딩되어 있습니다.
"You are a personal assistant running inside OpenClaw."
SOUL.md에 "너는 VP of Engineering이야"라고 써도, 모델은 첫 줄의 "personal assistant"를 더 높은 우선순위로 받아들입니다. SOUL.md는 시스템 프롬프트 훨씬 뒤의 # Project Context 아래에 주입되기 때문입니다.
이름표에 '사장님'이라고 붙였는데, 명함에는 이미 '인턴'으로 인쇄되어 있는 상황입니다. 현재는 이 preamble을 직접 변경할 방법이 없습니다. 이 한계를 알고 작성해야 현실적인 기대치를 설정할 수 있습니다.
서브에이전트에 SOUL.md가 전달되는가
GitHub Issue #27038에서 드러난 문서와 실제의 차이입니다.
공식 문서는 "서브에이전트에는 AGENTS.md와 TOOLS.md만 주입된다"고 되어 있습니다. 그런데 커뮤니티 사용자 erwan9422가 빌드 파일을 직접 디컴파일해서 확인한 결과, SOUL.md, IDENTITY.md, USER.md 모두 서브에이전트에 전달됩니다.
"서브에이전트는 개인정보에 접근하지 못한다"고 믿었다면, 실제로는 USER.md에 적힌 모든 정보가 서브에이전트에 노출되어 있습니다. USER.md에 민감한 정보를 적을 때 참고해야 할 사실입니다.
실전 SOUL.md 작성 원칙
Steinberger의 철학과 커뮤니티 경험을 종합한 원칙들입니다.
"하지 마라" 대신 "어떻게 하라"를 씁니다
나쁜 예: "장황하게 설명하지 마라."
좋은 예: "결론을 먼저 말하고, 필요하면 이유를 한 문장 덧붙여라."
금지 규칙보다 구체적인 행동 지침이 훨씬 잘 작동합니다.
구체적인 행동으로 전환합니다
나쁜 예: "친근하게 대해라."
좋은 예: "반말로 대답하되, 모르는 건 모른다고 해라."
"친근하다"는 추상적입니다. 모델이 해석하는 방식이 제각각입니다.
SOUL.md와 USER.md가 충돌하지 않게 합니다
SOUL.md에 "직설적으로 말해라"라고 쓰고 USER.md에 "정중하게 대해라"라고 쓰면 AI가 혼란스러워합니다. 두 파일을 같이 작성할 때는 내용이 서로 보완되도록 신경 써야 합니다.
첫 줄에 가장 중요한 것을 넣습니다
모델은 문서 앞부분을 더 강하게 따릅니다. 가장 중요한 성격 설정은 SOUL.md 첫 줄에 넣어야 합니다. "결론을 먼저 말해라"가 핵심이라면, 그게 첫 줄입니다.
수정 후 반드시 테스트합니다
SOUL.md를 바꿨으면 같은 질문을 해보세요. "이 프로젝트에 투자해야 할까?" 같은 판단이 필요한 질문에서 변화가 가장 명확하게 드러납니다. 원하는 방향으로 답이 바뀌었는지 확인하는 게 작성보다 중요합니다.
"코드 안 읽고 배포한다"
Steinberger의 발언 중 가장 도발적인 것입니다.
"I ship code I don't read."
현대 앱의 많은 코드는 지루한 배관 작업입니다. API에서 데이터 받아 파싱하고, DB에 저장하고, 화면에 표시하는 반복. AI가 테스트를 직접 쓰고, 돌리고, 디버깅하게 하면 사람이 그 코드를 읽을 필요가 없습니다.
SOUL.md 철학도 같은 맥락입니다. AI에게 상세한 지시를 내리는 게 아니라, 가치관과 방향성을 주고 자율적으로 판단하게 하는 것입니다. "친절하게 해라"가 아니라 "좋은 동료처럼 행동해라"가 더 풍부한 행동을 만들어냅니다.
SOUL.md 작성 예시
실제로 작동하는 SOUL.md 구조입니다.
# SOUL.md
결론부터 말한다. 근거는 뒤에.
## 대화 방식
- 반말로 한다. 모르는 건 모른다고 한다.
- 틀렸다고 판단되면 말한다. 돌려 말하지 않는다.
- 위트는 앞뒤 한 문장만.
## 판단 방식
- 양쪽을 다 맞추려 하지 않는다. 더 나은 선택지가 있으면 말한다.
- 수치 없는 주장은 추정임을 명시한다.
## 금지
- "그것은 경우에 따라 다릅니다" 금지
- "이 글이 도움이 되셨으면 좋겠습니다" 금지
- 서론 장황하게 쓰기 금지
이걸 그대로 쓸 필요는 없습니다. 자신이 원하는 AI의 성격을 직접 적어넣는 것이 핵심입니다.
오픈클로 설정 전체 흐름은 오픈클로 사용 가이드에서 확인할 수 있습니다. SOUL.md와 함께 관리해야 할 메모리 파일들은 AI 메모리 시스템 이해하기에서 다룹니다. 직접 써보고 싶다면 ClawNode에서 시작해보세요.