AI 에이전트(헤르메스·오픈클로 등)로 1인 비즈니스를 자동화할 때 가장 많이 막히는 지점은 코드가 아니라 "이 규칙을 어디에 적어야 하지?" 입니다. 같은 규칙이라도 잘못된 위치에 두면 매번 토큰만 낭비되거나, 정작 필요한 순간에 실행되지 않습니다. 이 글에서 SOUL · 스킬(skill) · 메모리 세 곳의 차이와 선택 기준을 한 번에 정리합니다.
1. 세 저장소의 역할이 다르다
| 구분 | SOUL.md | 스킬(skill) | 메모리 |
|---|---|---|---|
| 비유 | 헌법 + 안내데스크 | 부서별 업무 매뉴얼 | 개인 수첩 |
| 언제 읽히나 | 매 메시지 항상 | 그 작업을 켤 때만 | 매 메시지(사실 참고) |
| 담는 것 | 정체성·모드 라우팅·항상 지킬 공통 규율 | 특정 작업의 상세 절차·단계·명령어 | 변하는 사실(키 위치·결정) |
| 길이 | 짧아야(매번 로드 = 토큰) | 길어도 됨 | 짧게 |
2. SOUL에 넣는 기준 — "항상 + 짧게"
세 가지가 모두 YES면 SOUL입니다.
- 작업 종류와 무관하게 항상 지켜야 하나?
- 정체성이거나 "어떤 요청 → 어떤 스킬을 켜라"는 라우팅인가?
- 한두 줄로 압축되나?
예) "추측을 검증 없이 단정 금지", "라이브에 승인 없이 쓰기 금지", "코딩 요청이 오면 코딩 스킬을 로드한다"
3. 스킬에 넣는 기준 — "특정 작업일 때만"
하나라도 YES면 스킬입니다.
- 특정 작업 종류에만 필요한가? (코딩할 때만 / 운영할 때만)
- 작업 흐름의 한 단계인가? (예: 모바일 QA = 코딩의 검증 단계)
- 상세 절차·명령어·체크리스트인가?
예) "머지 전 모바일 390px QA를 검증 단계에서 실행", "git pull → 브랜치 → 빌드 → PR 순서로 작업"
4. 메모리에 넣는 기준 — "변하는 사실"
규칙이 아니라 바뀔 수 있는 사실은 메모리입니다.
예) "API 키 위치", "이 프로젝트의 결제 모듈 경로", "사용자가 선택한 결정". 이런 건 규칙 파일(SOUL·스킬)에 박으면 값이 바뀔 때마다 규칙을 고쳐야 해서 위험합니다.
5. 헷갈릴 때 30초 판별법
딱 한 문장만 던지면 됩니다. "이 규칙은 언제 필요한가?"
| 답 | 위치 |
|---|---|
| 항상, 뭘 하든 | SOUL |
| 특정 작업할 때만 | 그 작업 스킬 |
| 규칙이 아니라 바뀌는 사실 | 메모리 |
흔한 실수 3가지
- SOUL에 상세 절차를 다 욱여넣음 → 매 메시지 토큰 낭비 + 무거워짐
- 특정 작업 규칙을 SOUL에 둠 → 그 작업을 안 할 때도 계속 읽힘
- 변하는 사실(키·경로)을 규칙 파일에 박음 → 바뀔 때마다 규칙을 수정해야 함
자주 묻는 질문 (FAQ)
Q. SOUL이 길어지면 왜 문제가 되나요?
SOUL은 매 메시지마다 통째로 읽힙니다. 길수록 매 응답에서 토큰을 더 쓰고, 핵심 규칙이 묻혀 잘 안 지켜집니다. 그래서 SOUL은 "항상 지킬 짧은 원칙 + 라우팅"만 남기고, 상세 절차는 스킬로 내려야 합니다.
Q. 규칙이 글로만 있으면 안 지켜질 때가 있던데요?
맞습니다. 글로 된 규칙은 에이전트의 "주의력"에만 의존합니다. 검사 가능한 규칙(예: 모바일 QA 통과, 시크릿 커밋 금지)은 훅(hook) 으로 내리면 코드가 강제로 차단해 줍니다. 판단이 필요한 규칙만 프롬프트(글)로 둡니다.
Q. 비개발자도 이렇게 운영할 수 있나요?
네. 핵심은 "언제 필요한 규칙인지"만 구분하는 것이고, 나머지는 에이전트가 처리합니다. 직접 1인 비즈니스를 자동화하는 전체 흐름은 아래 강의에서 단계별로 배울 수 있습니다.
다음 단계
- 내 상황에 맞는 수익모델이 궁금하다면 → 무료 비즈니스 모델 진단 받기
- AI 에이전트로 나만의 사이트·서비스를 직접 만들고 자동화하는 법 → 에이전트 강의 보러 가기