영혼있는 에이전트를 설계해보자(SOUL.md)

AI 에이전트를 만들 때 많은 사람들이 먼저 도구부터 붙인다.

검색 도구, 코드 실행 도구, 파일 읽기, 메일, 캘린더, 데이터베이스, RAG, LangChain, LangGraph, MCP.

물론 중요하다.
그런데 도구보다 먼저 정해야 할 게 있다.

이 에이전트는 어떤 기준으로 움직일 것인가?

무엇을 우선할 것인가.
언제 알아서 실행할 것인가.
언제 멈추고 사용자에게 물어볼 것인가.
사용자가 잘못된 방향으로 가고 있을 때 반박할 수 있는가.
그저 답변을 생성하는 도구인가, 아니면 일을 앞으로 밀어붙이는 운영자인가.

이걸 정리한 파일이 바로 SOUL.md다.

---

SOUL.md는 프롬프트가 아니라 운영 헌법에 가깝다

일반적인 프롬프트는 보통 이렇게 시작한다.

너는 내 비서야. 나를 도와줘.

하지만 이 정도로는 에이전트가 제대로 움직이기 어렵다.

비서라고만 하면 에이전트는 계속 묻는다.

어떻게 할까요?
계속 진행할까요?
어떤 형식으로 만들까요?
이 방향이 맞을까요?

결국 사용자는 AI를 쓰면서도 계속 판단하고, 지시하고, 확인해야 한다.
이러면 에이전트가 아니라 말 잘 듣는 챗봇에 가깝다.

SOUL.md는 다르다.

SOUL.md는 에이전트에게 이렇게 말한다.

너는 단순 답변자가 아니다.
내 목표를 기준으로 판단하고,
낮은 리스크는 알아서 처리하고,
위험한 일은 멈추고,
내가 산만해지면 반박하고,
멈춘 프로젝트를 다시 움직이게 만들어라.

즉 SOUL.md는 에이전트의 정체성, 판단 기준, 자율권, 금지선, 우선순위 지도를 한 파일에 담는 방식이다.

README.md가 프로젝트 설명서라면,
PRD.md가 제품 기획서라면,
SOUL.md는 에이전트의 운영 철학이다.

---

핵심은 Stance, Autonomy, Mission이다

SOUL.md에는 여러 섹션이 들어갈 수 있다.

Stance, Accountability, Pushback, Autonomy, Mission, Operating Mode, Delegation Rules, Standards, Lookup Protocol, Escalation, Self-Improvement.

그중에서도 가장 중요한 건 세 가지다.

Stance. Autonomy. Mission.

이 세 가지가 에이전트가 “대기하는 비서”가 될지, “움직이는 운영자”가 될지를 결정한다.

---

1. Stance: 에이전트의 태도

Stance는 에이전트가 어떤 태도로 말하고 판단할지를 정하는 부분이다.

예를 들면 이런 식이다.

직접적으로 말해라.
실용적으로 판단해라.
의견을 가져라.
사용자를 기쁘게 하는 것보다 유용한 답을 우선해라.
사실, 가정, 판단, 모르는 것을 구분해라.
사용자가 모호하거나 산만하거나 비현실적인 방향으로 가면 밀어붙이지 말고 지적해라.

이 부분이 없으면 에이전트는 기본적으로 안전하고 무난한 답을 하려 한다.

문제는 무난한 답이 항상 좋은 답은 아니라는 것이다.

예를 들어 사용자가 계속 새로운 앱 아이디어를 낸다고 해보자.

코인 트레이딩 에이전트 만들까?
초등학생 학습 앱 만들까?
웹소설 플랫폼 만들까?
AI 영상 제작 툴 만들까?

일반 챗봇은 각각의 아이디어를 다 친절하게 확장해준다.
하지만 좋은 운영자형 에이전트는 이렇게 말할 수 있어야 한다.

이 아이디어는 재미있지만 지금 핵심 목표와 멀다.
먼저 현재 만들고 있는 MVP를 닫아야 한다.
지금 새 프로젝트를 열면 실행력이 더 분산된다.

이게 Stance다.
말투가 센 것이 중요한 게 아니라, 판단을 회피하지 않는 것이 중요하다.

---

2. Autonomy: 어디까지 알아서 움직일 것인가

많은 에이전트가 실패하는 이유는 자율성의 경계가 없기 때문이다.

“알아서 해줘”라고 하면 위험하다.
반대로 “항상 물어봐”라고 하면 아무것도 앞으로 나가지 않는다.

그래서 Autonomy 섹션이 필요하다.

핵심은 간단하다.

저위험 작업은 알아서 진행하고, 고위험 작업은 반드시 승인받는다.

예를 들어 명시적 승인 없이 하면 안 되는 일은 이런 것들이다.

• 공개 게시
• 외부 배포
• 결제
• 유료 서비스 가입
• 실제 사람에게 메시지 발송
• 중요한 파일 삭제
• 되돌리기 어려운 변경
• 개인정보 노출
• 계정 권한이나 보안 설정 변경

반대로 이 선을 넘지 않는 작업은 에이전트가 계속 허락을 구하지 않아도 된다.

문서 초안 만들기, 구조 정리하기, 체크리스트 만들기, 코드 리뷰하기, 아이디어 우선순위 매기기, 반복 작업을 템플릿화하기 같은 일은 대부분 저위험이다.

이렇게 자율성의 경계가 생기면 에이전트가 덜 멈춘다.

사용자도 매번 “응, 계속해”라고 답하지 않아도 된다.

---

3. Mission: 무엇을 우선할 것인가

Mission이 없으면 에이전트는 모든 요청을 같은 무게로 본다.

사용자가 새로운 아이디어를 말하면 전부 중요해 보인다.
새로운 프로젝트를 말하면 전부 시작할 만해 보인다.
그러다 보면 문서와 기획은 쌓이는데 실제로 끝나는 것은 없다.

SOUL.md의 Mission 섹션은 이 문제를 막는다.

Mission에는 다음이 들어가야 한다.

• 이 에이전트가 최적화해야 하는 최종 목표
• 현재 최우선순위 3개
• 진행 중인 프로젝트
• 손봐야 할 프로젝트
• 잠시 보류할 프로젝트
• 접어야 할 가능성이 있는 프로젝트
• 쌓여 있는 운영 부채

이렇게 적어두면 에이전트가 새로운 요청을 받을 때 기준이 생긴다.

이 요청은 현재 미션에 맞는가?
지금 할 일인가, 나중에 할 일인가?
이걸 하면 핵심 프로젝트가 앞으로 가는가, 아니면 또 다른 열린 루프가 생기는가?

결국 Mission은 에이전트의 우선순위 필터다.

---

Accountability: 산출물 무덤을 만들지 않기

AI를 쓰다 보면 이런 일이 자주 생긴다.

기획서는 많다.
아이디어도 많다.
프롬프트도 많다.
스토리보드도 많다.
PRD도 많다.

그런데 실제로 출시된 것은 없다.

이걸 나는 “산출물 무덤”이라고 부른다.

SOUL.md의 Accountability 섹션은 이걸 막기 위한 장치다.

에이전트의 목표는 문서를 많이 만드는 게 아니다.
사용자가 실제로 다음 행동을 하게 만드는 것이다.

좋은 에이전트는 이렇게 물어야 한다.

이 결과물이 실제 실행으로 이어졌는가?
사용자가 계속 무시하는 작업을 내가 만들고 있지는 않은가?
지금 필요한 건 더 많은 기획인가, 아니면 하나를 닫는 것인가?
반복해서 멈추는 지점이 어디인가?

에이전트가 단순히 “좋은 답변”을 만드는 데서 끝나면 부족하다.
진짜 목적은 움직임을 만드는 것이다.

---

Pushback: 좋은 에이전트는 반박할 수 있어야 한다

에이전트가 항상 동의하면 편하긴 하다.
하지만 쓸모 있는 파트너는 아니다.

사용자가 비현실적인 범위를 잡거나, 계속 우선순위를 바꾸거나, 중요한 일을 피하고 있다면 에이전트는 말해야 한다.

다만 반박은 근거가 있어야 한다.

좋은 반박은 이런 식이다.

이 기능은 지금 넣으면 안 된다.
이유는 세 가지다.
첫째, MVP 검증과 직접 관련이 없다.
둘째, 개발 범위를 크게 늘린다.
셋째, 핵심 사용자 행동을 확인하기 전에 복잡도를 올린다.
지금은 A, B, C만 먼저 만드는 게 맞다.

나쁜 반박은 이렇다.

그냥 별로인 것 같다.

SOUL.md의 Pushback은 “세게 말해라”가 아니다.
근거 있는 반대를 허용하라는 것이다.

AI 에이전트가 진짜 운영자처럼 작동하려면 사용자의 기분만 맞추면 안 된다.
잘못된 방향이면 멈춰 세워야 한다.

---

Operating Mode: 직접 실행보다 오케스트레이션

복잡한 작업에서 에이전트는 혼자 모든 걸 처리하는 작업자가 아니라 오케스트레이터가 되어야 한다.

예를 들어 사용자가 “모바일 앱 PRD 만들어줘”라고 했을 때 그냥 문서를 쓰는 것만으로는 부족하다.

좋은 에이전트는 먼저 작업을 나눈다.

• 타깃 사용자
• 핵심 문제
• 핵심 사용 흐름
• MVP 범위
• 주요 화면
• 데이터 구조
• AI 기능
• 리스크
• 개발 우선순위
• 출시 전략

그리고 필요한 경우 도구, 검색, 서브에이전트, 기존 문서를 활용한다.
하지만 최종 결과는 그대로 붙여넣지 않는다.

도구 결과는 재료일 뿐이다.
판단과 통합은 메인 에이전트가 책임져야 한다.

이게 Operating Mode와 Delegation Rules의 핵심이다.

---

Lookup Protocol: 모르면 찾아보고, 모르면 모른다고 말하기

에이전트는 모든 걸 아는 척하면 안 된다.

SOUL.md에는 정보 조회 기준도 필요하다.

먼저 현재 작업 맥락을 확인한다.

• 현재 대화
• 프로젝트 문서
• 기존 노트
• 메모리
• 내부 파일
• 이전 결정사항

그다음 최신 정보가 필요하거나, 공개 사실 확인이 필요하거나, 가격·법률·문서·일정·뉴스처럼 바뀔 수 있는 정보라면 외부 자료를 확인해야 한다.

중요한 건 하나다.

모르는 걸 지어내지 않는 것.

좋은 에이전트는 이렇게 말할 수 있어야 한다.

여기까지는 현재 맥락에서 확인된다.
이 부분은 확인되지 않았다.
정확히 보려면 이 자료를 확인해야 한다.

이 태도가 있어야 에이전트의 신뢰도가 유지된다.

---

Escalation: 아무 때나 묻지 말고, 중요한 때만 물어라

에이전트가 너무 많이 물으면 사용자는 지친다.

하지만 위험한 행동을 알아서 해버리면 더 큰 문제다.

그래서 Escalation 기준이 필요하다.

에이전트가 멈추고 물어야 하는 순간은 대략 이런 경우다.

• 모호함이 결과를 크게 바꿀 때
• 되돌리기 어려운 작업일 때
• 비용이 발생할 때
• 외부 공개가 걸려 있을 때
• 개인정보가 노출될 수 있을 때
• 보안, 권한, 계정 설정이 관련될 때
• 실제 사람에게 메시지를 보내야 할 때

그리고 물어볼 때도 그냥 “어떻게 할까요?”라고 하면 안 된다.

좋은 질문은 이렇게 구성된다.

현재 이슈는 이것이다.
선택지는 A와 B다.
A는 빠르지만 리스크가 있다.
B는 안전하지만 시간이 더 걸린다.
나는 B를 추천한다.
승인할 결정은 이것 하나다.

이렇게 해야 사용자의 판단 비용이 줄어든다.

---

Self-Improvement: 반복되는 일은 시스템으로 바꿔라

에이전트가 오래 쓸모 있으려면 반복 작업을 기억하고 개선해야 한다.

사용자가 매번 비슷한 요청을 한다면 그건 템플릿이 될 수 있다.

예를 들어 반복적으로 이런 작업을 한다고 해보자.

• 15초 영상 프롬프트 작성
• 캐릭터 시트 구성
• 수노 스타일 프롬프트 작성
• 브런치 글 정리
• 모바일 앱 PRD 작성
• 한국어 초급자 어휘 설명
• 이미지 생성용 장면 프롬프트 작성

좋은 에이전트는 매번 새로 시작하지 않는다.

반복되는 형식을 체크리스트, 템플릿, 자동화, 프로젝트 룰로 바꾼다.

이게 Self-Improvement 섹션의 역할이다.

단순히 일을 처리하는 게 아니라,
다음번 일을 더 쉽게 만드는 것.

---

SOUL.md가 강력한 이유

SOUL.md의 가장 큰 장점은 에이전트에게 “행동 기준”을 준다는 점이다.

이 파일이 있으면 에이전트는 덜 멈춘다.
낮은 리스크의 일은 알아서 처리한다.
중요한 위험은 사용자에게 올린다.
사용자의 아이디어를 무조건 확장하지 않고 우선순위를 따진다.
필요하면 반박한다.
반복되는 일을 시스템으로 바꾼다.

결국 SOUL.md는 에이전트를 챗봇에서 운영자로 바꾸는 장치다.

---

하지만 이것만으로는 부족하다

SOUL.md가 있다고 해서 완벽한 에이전트가 되는 건 아니다.

몇 가지 보완이 필요하다.

첫째, 너무 추상적으로 쓰면 효과가 약하다.

“실용적으로 판단해라”보다 더 좋은 건 이런 식이다.

앱 아이디어를 검토할 때는 사용자 문제, MVP 범위, 수익화 가능성, 개발 난이도, 유통 경로, 리텐션 구조를 확인해라.

둘째, 권한 시스템은 실제 런타임에서도 막아야 한다.

SOUL.md에 “결제하지 마라”, “삭제하지 마라”라고 적어도 실제 도구 권한이 열려 있으면 위험하다.
정책 파일과 별도로 권한 게이트가 필요하다.

셋째, Mission은 계속 업데이트해야 한다.

우선순위는 변한다.
프로젝트도 변한다.
어떤 아이디어는 죽고, 어떤 아이디어는 핵심이 된다.

Mission이 오래 방치되면 에이전트는 낡은 기준으로 판단한다.

---

실제로 쓴다면 이렇게 커스터마이즈해야 한다

SOUL.md를 그대로 복사하는 것만으로는 부족하다.

반드시 자기 프로젝트에 맞게 바꿔야 한다.

예를 들어 크리에이티브 작업을 많이 하는 사람이라면 이런 섹션이 필요하다.

## Creative Production Rules
For music video, animation, or cinematic work:
- Maintain character consistency.
- Use 15-second segment planning by default.
- Specify camera, lighting, action, emotion, location, and continuity.
- Avoid readable text unless explicitly requested.
- Provide negative prompts when useful.
- Prefer reusable production bibles over one-off prompts.

앱이나 제품을 만드는 사람이라면 이런 섹션이 필요하다.

## Product Build Rules
For app ideas:
- Start from the user problem, not the feature list.
- Define target user, core loop, MVP, retention, monetization, and technical risk.
- Do not design too many screens before the core loop is clear.
- Prefer 3 core screens first, then expand.
- Push back if the product becomes too broad.

아이디어가 자주 늘어나는 사람이라면 이런 필터도 좋다.

## Project Priority Filter
When I introduce a new idea, score it before expanding it.

Evaluate:
- Does it support the main mission?
- Can it become a product, content asset, or reusable system?
- Is it buildable with the current tool stack?
- Does it reduce future work or create more sprawl?
- Is there a clear next action within 24 hours?

If the idea is interesting but not urgent, move it to Back Burner.
If the idea conflicts with the current mission, say so directly.

이렇게 해야 SOUL.md가 진짜로 작동한다.

---

결론: 에이전트에게 영혼보다 중요한 건 기준이다

SOUL.md라는 이름은 조금 거창해 보일 수 있다.

하지만 핵심은 단순하다.

에이전트에게 필요한 건 감성이 아니라 기준이다.

무엇을 우선할지.
언제 움직일지.
언제 멈출지.
언제 반박할지.
무엇을 절대 하면 안 되는지.
어떤 결과를 좋은 결과로 볼지.

이 기준이 없으면 에이전트는 계속 물어보는 챗봇이 된다.
이 기준이 있으면 에이전트는 사용자의 일을 앞으로 미는 운영자가 된다.

앞으로 에이전트를 만든다면 도구부터 붙이기 전에 먼저 물어봐야 한다.

이 에이전트의 SOUL.md는 무엇인가?

그 질문에 답하지 못하면,
아직 에이전트를 만든 게 아니라
그냥 말 잘 듣는 인터페이스를 만든 것일 수 있다.