나를 도와 로봇제작을 도와주는 자비스가 이제는 책 저술도 도와주게 진화했네요:)
그래서 문득 시스템 최적화나 구조의 최적화을 화두로 던져 보았습니다.
AI 에이전트 시스템(OpenClaw )을 직접 구축하다 보면, 어느 순간 SYSTEM.md 파일 하나가 감당할 수 없을 정도로 무거워지는 시점이 옵니다. 오늘은 제가 구축 중인 **’자비스(JARVIS) 시스템’**의 효율을 극대화하기 위해, ‘파일 수’가 아닌 ‘읽기 경로’를 최적화한 폴더 구조에 대해 고민해 본걸 기록합니다.
1. 기존 구조의 한계: “단순함 속에 숨은 무거움”
처음에는 관리하기 편하도록 최소한의 파일로 시작했습니다. 하지만 시스템이 고도화될수록 JARVIS_SYSTEM.md 파일 하나에 모든 규칙과 프롬프트가 몰리는 현상이 발생했습니다.
📋 기존의 단일화된 구조
workspace/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── MEMORY.md
├── JARVIS_SYSTEM.md <-- ⚠️ 모든 시스템 규칙이 여기에 집중됨
├── TOOLS.md
├── HEARTBEAT.md
├── plans/
│ ├── NEXT_ACTION.md
│ ├── ROADMAP_v1.2_full.md
│ └── ISSUE_TRACKER.md
└── memory/
└── YYYY-MM-DD.md
- 문제점: 파일 수는 적어서 깔끔해 보이지만, AI가 매번 읽어야 하는 ‘핵심 컨텍스트’가 점점 무거워집니다. 결국 중요한 규칙이 묻히거나 응답 속도가 저하될 위험이 있습니다.
2. 향후 최적화 구조: “핵심 헌법과 세부 조례의 분리”
이번 업데이트의 핵심은 **’파일의 증가’가 아니라 ‘독서량의 감소’**입니다. AI가 매 세션마다 모든 규칙을 다 읽을 필요가 없도록 구조를 세분화했습니다.
📂 업그레이드된 시스템 구조 (Proposed)
workspace/
├── AGENTS.md
├── SOUL.md
├── USER.md
├── MEMORY.md
├── JARVIS_SYSTEM.md # ✅ [Core] 핵심 헌법만
├── system/ # ✅ [Module] 상황별 세부 규칙 분리
│ ├── SESSION_PROTOCOL.md # 시작/종료/동기화 프로토콜
│ ├── RESPONSE_RULES.md # 답변 품질, 장황함 금지 규칙
│ ├── MEMORY_POLICY.md # 기억 회상 및 저장 우선순위
│ ├── MODE_JARVIS.md # 기본 범용 자비스 모드 설정
│ └── MODE_WRITER.md # 작가 모드 (로보틱스 집필 특화)
├── TOOLS.md
├── HEARTBEAT.md
├── plans/
│ ├── NEXT_ACTION.md
│ ├── ROADMAP_v1.2_full.md
│ └── ISSUE_TRACKER.md
└── memory/
└── YYYY-MM-DD.md
3. 왜 이 구조가 더 효율적인가? (Key Insight)
단순히 파일을 쪼갠 것이 아닙니다. AI의 인지 부하(Cognitive Load)를 줄이는 경로 최적화가 본질입니다.
매 세션 기본 읽기량의 최소화
- 상시 호출:
SOUL.md,USER.md,JARVIS_SYSTEM.md(핵심)등 정체성에 직결된 문서만 읽습니다. - 선택적 호출: 특정 작업(글쓰기 등)을 할 때만
MODE_WRITER.md를 로드하여 토큰 소모를 줄이고 정확도를 높입니다.
관리의 편의성 증대
- 답변이 너무 길어진다면
RESPONSE_RULES.md만 수정하면 됩니다. 다른 시스템 로직을 건드릴 필요가 없어 안정적입니다.
4. 구조 변화에 따른 체감 비교
| 구분 | 기존 구조 (Small Files) | 최적화 구조 (Smart Folders) |
| 파일 수 | 적음 (관리 용이해 보임) | 조금 늘어남 (체계적) |
| 파일당 용량 | 매우 비대함 (Rule 간 충돌 위험) | 가볍고 명확함 (단일 책임 원칙) |
| AI 인지 부하 | 높음 (매번 전체 탐색) | 낮음 (필요한 경로만 선택) |
| 확장성 | 낮음 (수정 시 전체 영향) | 높음 (모듈별 독립 업데이트) |
5. 결론: 겉보기 복잡함보다 실제 협업 효율이 우선이다
결국 나만의 자비스를 만든다는 것은, AI가 나와 얼마나 더 빠르고 정확하게 소통하느냐의 싸움입니다.
“파일이 많아지는 것을 두려워하지 마세요. 진짜 두려워해야 할 것은 AI가 읽어야 할 ‘불필요한 텍스트’의 양입니다.”
이런 구조 변경을 통해 제 자비스는 더욱 가벼워진 핵심 헌법을 바탕으로, 상황에 맞는 전문성을 발휘할 수 있게 될거 같습니다.
6. 하지만: 먼저 기존 시스템 진단 실시하자
분리 구조가 잘 되면
매번 읽는 핵심이 가벼워져서 판단력이 좋아질 가능성이 있지만 분리를 잘못하면
오히려 파일만 늘고, 어디를 읽어야 하는지 헷갈려서 더 나빠질 수도 있다.
즉 핵심은:파일을 나누는 것 자체가 답이 아니라,
“항상 읽는 것”과 “필요할 때만 읽는 것”을 정확히 구분하느냐다.
진단도 오픈클로로 구축한 자비스에게 시켜봅니다. 현재 내가 구축한 시스템의 병목은 다른 곳에서 발견되어 우선 그걸 먼저 개선 했습니다.
JARVIS_SYSTEM.md : 261줄 / 10,722자AGENTS.md : 233줄 / 9,188자
둘 합치면 이미 꽤 무거워 중복된 내용을 다이어트하는걸로만 햐였습니다. 다이어트는 항상 필요합니다:)
오늘의 최적화 아이디어는 차후 적용 할거 같습니다.
시간이 가면 한번씩 시스템 최적화를 점검하고 요구해야 겠습니다.
Tag: #자비스 #AI에이전트 #OpenClaw #폴더구조 #프롬프트엔지니어링 #생산성 #BakBiseo #로보틱스 #AI시스템설계