*업무 에이전트* 의 *관리* — *폴더* 가 *맥락 의 저장소* 가 되는 *6 구획 패턴* 과 *반복 업무 의 맥락 유지* 의 본질

월간 경영 성과 리뷰 에이전트. 매달 첫째 주. 지난 달 의 실적, 사업 계획, 채널 별 KPI 를 모아 *원인 분석 + 리스크 알림 + 경영진 요약 을 만드는 동일 한 흐름 의 반복.

처음 *세팅 에 2 주. 두 번째 부터 *세 시간. 왜 그렇게 *극적 차이 가 나는가. 프롬프트 가 *능숙 해서? — 아니다. 세팅 의 진정한 결과 물 이 프롬프트 가 아니라 *폴더 였기 때문이다*.

위 의 도식 — context, inputs, workflow, agents, outputs, review 의 6 개 폴더 — 그저 *저장 의 구획 이 아니다. *이게 *반복 업무 의 맥락 을 *외부 화 한 *영구 적 기억 의 *6 가지 층. 그 분리 의 지혜 가 업무 에이전트 의 *진짜 자산.

이 글은 위 도식 의 *6 폴더 구조 의 각 폴더 의 *역할 + 그 분리 의 *이유 + 반복 업무 의 *맥락 유지 의 *본질 을 9 년차 백엔드 개발자 + Claude Code 사용자 의 시각 으로 밀도 있게 정리한다.

함께 보면 좋은 자매편 :

• Multi-Agent Deep Dive — 에이전트 의 *오케스트레이션 시각
• AI 코딩 의 한계 + 5 가지 안티 스파게티 기준 — 맥락 의 부재 가 *AI 의 *근본 한계
• Function Calling Deep Dive — 에이전트 의 *행동 메커니즘

---

TL;DR — 한 줄 결론

업무 에이전트 의 진짜 경쟁력 은 *프롬프트 의 정교 함 이 아니라 *폴더 의 구조 의 *정직 함. LLM 은 *세션 마다 *기억 을 잊는다. 그러나 *반복 업무 의 *진가 는 *어제 와 같은 맥락 의 *유지 의 *효율. 그 사이 의 *모순 의 해결자 가 *폴더. context (변하지 않는 것) / inputs (매번 다른 입력) / workflow (한번 정한 흐름) / agents (도구) / outputs (결과) / review (사람의 책임) 의 6 가지 분리 가 N 번째 실행 의 *깨끗한 재 시작 을 가능 케 한다. 폴더 는 *Agent 의 *외부 두뇌.

---

1. *반복 업무 의 *진짜 비용 — *재 진입 의 인지 부하**

1.1 “왜 *처음과 두 번째 가 *완전히 다른가”

첫 번째 의 *경영 성과 리뷰 에이전트 작성 :

• 조직 의 *KPI 의 정의 를 *프롬프트 에 *설명 — 30 분.
• 어느 시스템 에서 *어떤 데이터 를 *어떻게 끌어오는 지 의 위치 설명 — 1 시간.
• 지난 분기 의 *기준 / 비교 대상 / 색상 코드 — 1 시간.
• 경영진 의 *읽는 방식 의 *선호 (요약 길이, 시각 화 의 종류, 결론 의 위치) — 2 시간.
• 법무 / 준법 의 *주의 항목 — 1 시간.
• 프롬프트 의 *시행 착오 — 3 ~ 4 시간.

총 *반나절 ~ 하루.

다음 달 의 *같은 작업 — 프롬프트 를 *재 사용 하면 *되지 않을까. 그런데 LLM 의 *세션 이 *완전히 잊었다. 그 모든 *맥락 을 *다시 설명 해야* 한다. 반나절 의 *재 진입 비용 이 매달 반복 됨.

1.2 *재 진입 비용 의 *진짜 정체**

비용 의 종류	매달 의 반복 시
조직 의 *KPI 정의 의 *재 설명	조직 이 안 바뀌면 *불필요
데이터 위치 의 *재 알림	시스템 이 안 바뀌면 *불필요
경영진 의 *선호 의 *재 학습	경영진 이 안 바뀌면 *불필요
법무 의 *주의 항목 의 *재 입력	법 이 안 바뀌면 *불필요
프롬프트 의 *시행 착오	흐름 이 안 바뀌면 *불필요
이번 달 의 *실적 / 메모	반드시 필요

위 표 의 *5 분 의 1 만 (이번 달 의 실적 만) 진짜 새 다. 나머지 5 분의 4 는 *동일. 그러나 세션 의 *기억 의 부재 가 *그 동일성 을 *매번 새로 처리*.

이게 *반복 업무 의 *진짜 비용 의 *본질 — 변하지 않는 것 의 *변하는 것 처럼 *반복 적 *재 입력.

1.3 해결 의 *핵심 통찰

변하는 것 과 변하지 않는 것 의 물리 적 분리. 변하지 않는 것 은 *영구 저장 하고 N 번째 부터 는 *건드리지 않음. 변하는 것 만 *새로 채움.

이 *분리 의 *물리 적 구현 이 *폴더.

---

2. 6 폴더 패턴 — *왜 *6 개 인가**

도식 의 6 폴더 — context / inputs / workflow / agents / outputs / review. 과도해 보임. 3 ~ 4 개 면 안 되나?

답 — 각 폴더 의 *변화 의 *주기 가 *근본 적으로 다름. 그래서 *분리 가 *필연.

폴더	변하는 주기	누가 변경
context	연 단위 (조직 / 도메인 의 큰 변화 시)	프로젝트 리드
inputs	매 실행 마다 (월간 / 주간)	현업 / 자동 ETL
workflow	분기 / 반기 (프로세스 개선 시)	프로젝트 리드 + AI 엔지니어
agents	분기 (도구 추가 / 교체 시)	AI 엔지니어
outputs	매 실행 마다 (생성 결과)	에이전트 자동 생성
review	매 실행 마다 (사람 의 검토)	현업 / 경영진 / 법무

6 폴더 가 *6 가지 의 *수명 의 분리. 변화 의 *주기 가 *서로 다른 것 을 *같은 폴더 에 두면 *변경 의 *경계 가 *흐려져 — 유지 보수 의 *재앙.

이게 Hexagonal Architecture 의 *6 폴더 판본. 백엔드 의 *port / adapter / domain 의 분리 와 동일 한 *지혜 의 *영역 화*.

---

3. 각 폴더 의 *해부 — *6 가지 의 *역할 의 본질**

3.1 *context — *변하지 않는 *세계 의 정의**

도식 의 첫 줄 — “업무 배경, 조직 맥락, 보험 상품/채널/지표 정의”.

포함 :

• 조직 의 *부서 구조 + 책임 분배
• 비즈니스 도메인 의 *용어 정의 사전 (보험 상품 / 채널 / 거래 / 정산)
• 측정 지표 의 *계산 식 + 비교 기준
• 법 / 규정 / 준법 의 *주의 항목 정리
• 시스템 의 *위치 + 권한 + 데이터 흐름
• 경영진 / 의사 결정자 의 *읽기 의 선호

특징 :

• 수십 KB ~ 수 MB 의 *텍스트.
• 연 1 ~ 2 회 의 *큰 갱신.
• 한 번 작성 의 *시간 = 수 일 ~ 수 주.
• N 번째 부터 의 *재 사용 가치 = 거의 무한.

반복 업무 의 *맥락 유지 의 *주된 자원. 이 폴더 가 *없으면 *N 번째 도 *처음 처럼. 이 폴더 가 *있으면 *N 번째 가 *N+1 번째 의 *시작 점.

3.2 *inputs — *매 실행 의 *새로운 재료**

도식 의 두 번째 줄 — “월간 실적, 사업 계획, Forecast, 협업 메모, 대시보드”.

포함 :

• 지난 달 의 *수치 데이터 (CSV / Excel)
• 현업 의 *주관 적 메모 / 코멘트
• 외부 시장 정보 / 경쟁사 동향
• Forecast 의 *최신 갱신
• 대시보드 의 *스크린 샷 / 링크

특징 :

• 매 실행 마다 *완전 교체 (또는 누적 보관 + 인덱스).
• 시간 표시 가 *필수 — 2026-06/, 2026-07/ 같은 날짜 폴더 분기 권 장.
• 민감 정보 의 *집중 — 보안 통제 의 *주요 영역.

매월 의 *유일한 *새로움 의 *진짜 정체. 이 폴더 만 매번 교체 한다는 사실 자체 가 반복 업무 의 *효율 의 *증거.

3.3 *workflow — *흐름 의 *문서 + 자동 화 의 결합**

도식 의 세 번째 줄 — “기존 업무 프로세스 와 AI 중심 으로 재 설계한 업무 흐름”.

포함 :

• 각 단계 의 *순서 도 / 다이어그램
• 각 단계 의 *입력 / 출력 의 *형식
• 예외 처리 / 분기 의 *명세
• 각 단계 의 *수행 주체 (사람 / 에이전트)
• 실행 스크립트 / 자동 화 도구 의 *진입 점

특징 :

• 분기 / 반기 단위 의 *개선.
• 문서 (markdown / 다이어그램) + 코드 (script / yaml) 의 *혼재.
• 재현 가능성 의 *근간. 팀 의 *교대 시 의 *교본.

프로세스 의 *명문화 가 *반복 의 *재현 의 *기반. 흐름 이 *문서 화 안 되어 있으면 *각 실행 이 *각자 의 변형 으로 조용히 표류.

3.4 *agents — *도구 의 *카탈로그**

도식 의 네 번째 줄 — “월간 경영 성과 리뷰 에이전트, 사업 계획 갱신 에이전트, 채널 성과 진단 에이전트, 리스크 시나리오 분석 에이전트”.

포함 :

• 각 에이전트 의 *목적 의 *한 문장 정의
• 각 에이전트 의 *프롬프트 템플릿
• 각 에이전트 의 *도구 (function / API) 의 *선언
• 각 에이전트 의 *맥락 의 어디 까지 의 *접근 권한
• 각 에이전트 의 *출력 의 *형식 의 *명세

특징 :

• 분기 단위 의 *추가 / 교체.
• 각 에이전트 의 *독립 적 유지 보수 가능.
• 재 사용 의 *주체 — 다른 업무 의 *에이전트 의 *재 활용 가능.

에이전트 의 *집합 의 *명시 화 가 *시스템 의 *관찰 가능성. 어느 에이전트 가 *어느 일 을 *하는지 가 *카탈로그 의 *형태로 *외부 화.

3.5 *outputs — *생성물 의 *영구 보관**

도식 의 다섯 번째 줄 — “경영진 판단 을 위한 요약, 원인 후보, 시나리오 비교, 확인 필요 질문”.

포함 :

• 최종 보고서 (PDF / Slide / Notion)
• 중간 분석 결과 (CSV / JSON)
• 시각화 의 *이미지 / 차트
• 경영진 에 게 제출 한 *공식 버전
• 에이전트 의 *추론 의 *흔적 (trace)

특징 :

• 매 실행 마다 *완전 신규.
• 날짜 폴더 분기 + 영구 보관.
• audit / 후 분석 의 *재료.
• outputs 의 *과거 분 이 *다음 inputs 의 *비교 기준 으로 재 진입.

결과 의 *축적 이 *조직 의 *학습 의 *축적. outputs 폴더 의 *깊이 가 *그 조직 의 *AI 활용 의 *역사.

3.6 *review — *사람 의 *책임 의 *명시 적 영역**

도식 의 여섯 번째 줄 — “사람 이 승인 해야 할 가정, 숫자, 리스크, 준법 검토 항목”.

포함 :

• 에이전트 가 *세운 가정 의 *목록
• 경영진 의 *판단 이 필요한 *분기 점
• 리스크 의 *심각도 평가 와 *대응 안
• 준법 / 법무 의 *검토 가 필요한 *항목
• 현업 의 *최종 승인 의 *기록 (서명, 코멘트, 일자)

특징 :

• 매 실행 마다 *생성.
• 사람 의 *진정한 *책임 의 *영역.
• audit trail 의 *핵심.
• 에이전트 의 *오류 의 *발견 점.

이 폴더 가 *없으면 *에이전트 의 *결정 의 *책임 이 *흐릿함. AI 시대 에 *사람 의 *역할 의 *명시 적 보존 의 *마지 막 보루.

---

4. *반복 업무 의 *맥락 유지 — *6 폴더 의 *진가**

4.1 *N 번째 실행 의 *깨끗한 시작**

월간 리뷰 의 *2026 년 7 월 실행 :

1. context/ — 6 월 과 동일. 변경 없음. 그대로 사용.
2. inputs/2026-07/ — 새 폴더 생성. 7 월 의 *실적 / 메모 / Forecast 만 채움.
3. workflow/ — 분기 별 갱신 일정 의 경계 가 *아니라면 *그대로.
4. agents/ — 그대로.
5. outputs/2026-07/ — 빈 폴더 생성. 에이전트 가 채울 곳.
6. review/2026-07/ — 빈 폴더 생성. 경영진 / 현업 의 *기록 의 곳.

시작 의 *준비 시간 = *30 분 (inputs 의 채움 만).

이게 반복 업무 의 *진가. 처음 실행 의 *반나절 의 비용 이 *N 번째 부터 는 *30 분 으로 극적 압축.

4.2 *맥락 의 *전 달 의 *3 가지 방법**

세션 마다 기억 을 잊는 *LLM 에 맥락 을 *어떻게 *전달 하는가 — 3 가지 패턴.

1. *Prompt 에 *모두 *복사 붙여 넣기**

"""
[context.md 의 *전체 내용 *수십 KB*]
[inputs/2026-07/* 의 모든 데이터]
이번 달 의 경영 성과 를 분석 해줘.
"""

• 장점 — 단순. 세팅 의 *0 노력.
• 단점 — 컨텍스트 윈도우 의 *낭비. 비용 ↑. 변경 시 *모든 프롬프트 *수정.

2. *Retrieval (RAG) — *질문 에 *관련 부분 만 *동적 로드**

사용자 의 *질문 → 벡터 검색 → context 의 *관련 부분 만 *프롬프트 에 *첨부*.

• 장점 — 비용 ↓. 큰 맥락 도 *처리 가능.
• 단점 — 연결성 의 *손상 가능 — 부분 만 보면 *전체 의 *흐름 의 *맥락 의 *상실.

3. *Memory (지속 저장소) — *Claude Code 의 *auto memory 패턴**

• 세션 의 *주요 학습 을 *영구 저장.
• 다음 세션 시 *시스템 프롬프트 에 *자동 주입.
• 세션 간 *학습 의 *누적.

Claude Code 의 *현재 기능 — 내 *9 년 의 *경험 의 *직접 적 검증. 세션 마다 *새로 설명 하지 않아도 되는 *놀라운 편안함.

6 폴더 가 *이 *3 가지 방법 의 *어느 것 에도 *맞게 *작동 — 원시 적 으로 prompt 에 넣을 수도 있고, RAG 의 *문서 저장소 가 될 수도 있고, Memory 의 *영구 적 *추가 학습 데이터 가 될 수도 있음.

4.3 *맥락 의 *오염 방지**

반복 실행 의 *함정 — *지난 달 의 *outputs 가 *이번 달 의 *prompt 에 *섞이는 *오염.

❌ 위험 한 패턴 :
   에이전트 가 *전체 outputs/* 를 *읽어 *지난 달 의 *결론 을 *이번 달 에 *반복*.

✅ 안전 한 패턴 :
   - inputs/2026-07/ 만 읽음.
   - context/ 의 *불변 의 정의* 참조.
   - 지난 달 의 outputs 는 *명시 적 비교* 가 *원할 때 만* 한정 적 참조.

6 폴더 의 *물리 적 분리 가 *이 오염 방지 의 *기반. 모든 inputs 를 *날짜 폴더 로 *분리 한 것 이 그 자체 가 *안전 장치.

---

5. *Claude Code 의 *Memory + Skill 시스템 과 의 *연결**

9 년 의 *최근 *6 개월 — Claude Code 의 *memory + skill 시스템 의 직접 적 사용.

5.1 Memory 의 *대응 — *context + review

Claude Code 의 *~/.claude/projects/<project>/memory/ :

• 사용자 의 *역할 / 선호 / 피드백 / 프로젝트 의 *영구 적 *상태.
• 세션 마다 *자동 로드.

이게 *위 의 *context 폴더 와 *review 폴더 의 *합성. 변하지 않는 것 + 사람 의 *피드백 의 *축적.

5.2 Skill 의 *대응 — *workflow + agents

Claude Code 의 *~/.claude/skills/ (또는 plugins/skills) :

• 반복 가능 한 *지식 의 *문서 화 + 활성 화.
• 상황 별 *자동 호출.

위 의 *workflow 폴더 + agents 폴더 의 *합성. 흐름 + 도구 의 *재 사용 가능한 형태.

5.3 *Inputs / Outputs 의 *대응 — *그 때 마다 *생성**

세션 별 의 *현재 작업 의 *작업 디렉토리. Inputs 와 outputs 가 *그 안에 *공존. 세션 종료 시 *outputs 가 *git 으로 *영구 화.

Claude Code 의 *memory + skill + 작업 디렉토리 가 *위 의 *6 폴더 의 *Claude Code 적 *번역. 동일 한 패턴 의 *다른 표현. 개발자 의 *작업 환경 에 *그대로 적용 가능.

---

6. *실무 적 *적용 — *내 *13 개 레포 의 *예상 매핑**

9 년 차 의 *내 가 *이 *6 폴더 패턴 을 *내 *13 개 *개인 레포 + 업무 의 *반복 작업 에 *적용 한다면.

6.1 *settlement 의 *주간 운영 리뷰**

settlement-ops/
├── context/
│   ├── architecture-overview.md           # 시스템 구조 변하지 않는 부분
│   ├── alert-thresholds-and-runbooks.md   # 각 알림 의 의미 + 대응
│   ├── team-rotation-policy.md            # 온콜 의 *룰
│   └── slo-and-error-budget.md            # SLO 정의 + 현재 예산
├── inputs/
│   ├── 2026-W25/                          # 이번 주
│   │   ├── alerts.json                    # 7 일 알림 덤프
│   │   ├── metrics-snapshot.json
│   │   └── incidents.md                   # 사고 의 자유 기술
│   └── 2026-W24/                          # 지난 주 (비교)
├── workflow/
│   ├── weekly-review-process.md           # 흐름 정의
│   └── run-weekly-review.sh               # 진입 점
├── agents/
│   ├── alert-pattern-analyzer.md          # 알림 패턴 의 분석 에이전트
│   ├── error-budget-burner.md             # SLO 소진 의 분석
│   └── runbook-suggester.md               # 개선 안 제안
├── outputs/
│   └── 2026-W25/
│       ├── summary.md                     # 경영 / 팀 공유 의 요약
│       ├── action-items.md                # 후속 작업
│       └── trace/                          # 에이전트 의 추론 흔적
└── review/
    └── 2026-W25/
        ├── human-decisions.md             # 내 결정 의 기록
        └── approved-runbook-updates.md    # 룰북 의 *공식 갱신

매주 의 *준비 = 2 시간. 모든 맥락 이 *6 개 폴더 에 *외부 화.

6.2 *lemuel-xr 의 *분기 별 신학 검증**

lemuel-xr-theology-review/
├── context/
│   ├── tradition-and-tone.md              # 보수적 정통 톤 의 정의
│   ├── disputed-points-policy.md          # 분쟁 의 *처리 방식
│   └── reviewer-team.md                   # 신학 검토 위원회 의 구성
├── inputs/
│   └── 2026-Q3/
│       ├── new-meditation-drafts/         # 분기 의 새 묵상
│       └── scene-changes.md               # Scene 분기 의 변경
├── workflow/
│   └── theology-review-flow.md
├── agents/
│   └── theology-reviewer.md               # 자매편 의 *lemuel-theology-reviewer 에이전트
├── outputs/
│   └── 2026-Q3/
│       ├── approved-content/
│       └── disputed-flagged/
└── review/
    └── 2026-Q3/
        ├── committee-decisions.md         # 위원회 의 결정 기록
        └── disputed-notes.md              # 분쟁 의 공개 적 기록

6.3 *fashion-desgin 의 *시즌 별 컬렉션 계획**

비슷한 패턴 — brand-context, seasonal-inputs, design-workflow, trend-analyzer-agent, outputs, human-curator-review.

결론 — 이 *6 폴더 패턴 은 *도메인 의 *경계 가 백 엔드 / 신학 / 디자인 등 완전히 다른 분야 에도 *동일 하게 적용. 추상화 의 *완전 한 보편성.

---

7. *반 패턴 — *6 폴더 가 *깨지는 *5 가지 방법**

9 년 의 *경험 의 *위험 신호.

1. *context 가 *늘어나지 않는다** — *조직 의 변화 가 반영 안 되어 *작동 안 함. 분기 별 *재 점검 필요.
2. *inputs 의 *날짜 분리 가 *없다** — *오염 의 시작. 반드시 YYYY-MM/ 또는 YYYY-WW/ 분기.
3. *workflow 가 *문서 만 있고 스크립트 가 없다** — *재현 의 *암묵 적 영역 잔존. 실행 가능 한 코드 까지 정리.
4. *agents 가 *겹친다** — *어느 에이전트 가 *어느 일 인지 *흐릿함. 명확한 책임 분리.
5. *review 가 *빈다** — *사람 의 *책임 이 *증발. AI 의 *결정 의 *공식 적 승인 의 *기록 의 *부재 가 *법적 위험.

이 5 가지 의 *반 패턴 의 *주기 적 *자가 검수 가 6 폴더 의 *건강 의 *근간.

---

8. *결론 — *폴더 의 *6 가지 의 *영원한 의미**

처음 도식 을 다시 본다.

• context — 변하지 않는 것 의 *영구 화.
• inputs — 변하는 것 의 *날짜 적 *분리.
• workflow — 흐름 의 *명문화.
• agents — 도구 의 *카탈로그 화.
• outputs — 결과 의 *축적.
• review — 사람 의 *책임 의 *명시 적 영역.

6 가지 가 *각자 의 *수명 의 *주기 의 *분리. 그 분리 가 *반복 업무 의 *N 번째 실행 의 *맥락 유지 의 *전제 조건.

“AI 시대 의 *업무 에이전트 를 *관리 한다” 는 것은 프롬프트 의 *튜닝 이 아니라 폴더 의 *구조 의 *디자인. 그 구조 의 *6 가지 분리 가 조직 의 *반복 업무 의 *9 가지 어려운 문제 (재 진입 / 오염 / 책임 / 재현 / 변화 / 확장 / 감사 / 보안 / 비용) 의 공통 근본 의 *해결.

매달 의 *첫 째 주 의 *경영 성과 리뷰 가 N 번째 부터 는 *30 분 으로 압축 되는 비밀 — 바로 *이 *6 폴더 의 *조용한 *근면.

---

다음 으로 *권 하는 읽기**

• 원 도식 의 *출처 (가능 하다면) — 이런 패턴 을 *현장 에서 *체계화 한 글 / 책 의 *원작.
• Anthropic 의 *Building Effective Agents (2024 공개) — 에이전트 의 *구조 적 패턴.
• Memory in LLM Applications — RAG / Long-term memory / Context window 의 *교과서 적 정리.
• 자매편 — 내 Multi-Agent Deep Dive + AI 코딩 의 한계.

다음 글 — 이 *6 폴더 패턴 을 *내 *13 개 레포 + Claude Code 의 *memory / skill 시스템 에 *적용 한 *실제 적용 사례 3 편 의 시리즈 — 곧.