Stateful Agent Orchestration (SAO): AI 에이전트의 기억의 벽을 넘는 방법론
2026년 1월 13일
서론: AI 에이전트의 "기억상실" 문제
Claude, GPT, Gemini—AI 에이전트는 이제 개발 현장에서 없어서는 안 될 존재가 되었습니다. 코드 리뷰, 버그 수정, 새로운 기능 구현, 문서 작성. 그들은 놀라울 정도로 유능합니다.
단, 하나의 세션 동안만요.
기존 AI 에이전트:
Session 1 → [인증 기능 설계 완료] → 세션 종료 → 기억 소멸 💨
Session 2 → "인증 기능 이어서 해주세요" → "무슨 말씀이신가요?"
이것이 우리가 "기억상실 문제"라고 부르는 현상입니다.
대규모 프로젝트에서는 이 문제가 치명적입니다. 일주일에 걸쳐 설계한 아키텍처도, 3일 동안 쌓아온 구현 경위도, 새로운 세션이 시작되는 순간 제로가 됩니다. 매번 처음부터 다시 설명하고, 매번 같은 실수를 반복하게 됩니다.
SAO(Stateful Agent Orchestration)는 이 문제를 해결하기 위해 탄생한 방법론입니다.
SAO란 무엇인가
SAO(Stateful Agent Orchestration)는 AI 에이전트의 기억 제한을 문서 기반 상태 영속화로 해결하는 방법론입니다.
한마디로 말하면, "AI의 뇌 외부에 영구적인 기억을 두는" 접근 방식입니다.
SAO 적용 후:
Session 1 → [작업] → 상태를 문서에 저장 📝 → 세션 종료
Session 2 → 문서에서 상태 복원 📖 → [이어서 작업]
사람이 프로젝트 인수인계 자료를 만들듯이, AI 에이전트도 "인수인계 가능한 형식"으로 작업 상태를 저장합니다. 다음 세션(또는 다음 에이전트)은 그 자료를 읽고 작업을 이어갈 수 있습니다.
구체적인 예시로 이해하기
개념만으로는 이해하기 어려우니, 먼저 구체적인 예시로 SAO의 동작을 살펴보겠습니다.
예시 1: ToDo 앱에 인증 기능 추가하기
기존 ToDo 앱에 "사용자 인증 기능"을 추가하는 프로젝트입니다.
Phase 구성
| Phase | 이름 | 설명 |
|---|---|---|
| 1 | 인증 기반 | Supabase Auth 설정, DB 스키마, 기본 API |
| 2 | Google 인증 | OAuth 설정, 로그인 버튼, 콜백 처리 |
| 3 | 이메일 인증 | 회원가입/로그인 폼, 유효성 검사 |
| 4 | 비밀번호 재설정 | 재설정 이메일, 새 비밀번호 설정 화면 |
SAO가 없는 경우 (기존 방식)
【1일차】
Claude: DB 스키마를 설계하고 Supabase Auth를 설정했습니다
→ 세션 종료
【2일차】
User: 어제 이어서 해주세요
Claude: 죄송합니다, 어디까지 진행되었나요? 무엇을 설계했나요?
User: 음, DB 스키마랑... (설명에 10분)
Claude: 이해했습니다. 그러면... (다시 처음부터 확인하면서 진행)
SAO가 있는 경우
【1일차】
Claude: Phase 1 Step 2까지 완료했습니다
→ README.md에 진행 상황 기록
→ "Step 3: API 구현 미착수" 명기
→ 세션 종료
【2일차】
Claude: README.md 확인... Phase 1 Step 3부터 재개합니다
→ 설명 없이 즉시 이어서 작업 시작
실제로 생성되는 문서
SAO 프로젝트에서는 다음과 같은 문서가 생성·업데이트됩니다:
# Phase 1: 인증 기반
| 진행 상황 | `진행 중` 🔄 |
| 시작일 | 2026-01-10 |
| 담당 | Claude |
## Step별 진행 상황
### Step 1: DB 스키마 생성
| 상태 | `완료` ✅ |
- [x] users 테이블 생성
- [x] sessions 테이블 생성
- [x] 마이그레이션 적용 확인
### Step 2: Supabase Auth 설정
| 상태 | `완료` ✅ |
- [x] 프로젝트 설정 확인
- [x] 인증 프로바이더 활성화
- [x] 리다이렉트 URL 설정
### Step 3: 인증 API 구현
| 상태 | `미착수` |
- [ ] 회원가입 엔드포인트
- [ ] 로그인 엔드포인트
- [ ] 로그아웃 엔드포인트
## 업데이트 이력
| 날짜 | 작성자 | 내용 |
|-----|-------|------|
| 2026-01-10 | Claude | Step 1-2 완료 |
다음 세션에서는 이 README를 읽기만 하면 "Step 3부터 시작"이라고 즉시 판단할 수 있습니다.
예시 2: 대규모 리팩토링 (1주일 이상)
레거시 REST API를 GraphQL로 마이그레이션하는 프로젝트. 50개 이상의 엔드포인트가 있어 한 세션으로는 도저히 끝낼 수 없습니다.
Phase 구성과 의존관계
Phase 1: 기반 구축 (GraphQL 서버 설정, 스키마 설계)
│
├──► Phase 2: 사용자 계열 API (User, Profile, Settings)
│
├──► Phase 3: 콘텐츠 계열 API (Post, Comment, Like)
│
└──► Phase 4: 알림 계열 API (Notification, Subscription)
│
↓
Phase 5: 구 API 폐기
Phase 1 완료 후 Phase 2-4는 병렬로 진행할 수 있습니다. 모두 완료되면 Phase 5로 진행합니다.
세션을 넘나드는 실행
【월요일】Session 1: Phase 1 완료
【화요일】Session 2: Phase 2 Step 1-3 완료
【수요일】Session 3: Phase 2 완료, Phase 3 시작
【목요일】Session 4: Phase 3 Step 1-2 완료 ← 여기서 블로커 발생
【금요일】Session 5: 블로커 해소, Phase 3 완료
【다음 주 월요일】Session 6: Phase 4 완료
【다음 주 화요일】Session 7: Phase 5 완료 → 프로젝트 완료 🎉
7개의 세션을 넘나들어도 각 세션에서 에이전트는 "지금 어디에 있는지", "다음에 무엇을 해야 하는지"를 즉시 파악할 수 있습니다.
SAO의 구조
구체적인 예시로 이미지를 잡았으니, SAO의 구조를 자세히 살펴보겠습니다.
네 가지 기둥
SAO는 네 가지 원칙에 기반합니다.
1. 목표 정의: Why / What / Success State
SAO에서는 단순히 "무엇을 할지(What)"만 정의하는 것이 아니라, "왜 하는지(Why)"와 "성공하면 무엇이 가능해지는지(Success State)"를 명확히 정의합니다.
┌─────────────────────────────────────────────────────────────┐
│ Why (왜 하는가?) │
│ → 현재 문제점, 페인 포인트, 동기 │
├─────────────────────────────────────────────────────────────┤
│ What (무엇을 만드는가?) │
│ → 구체적인 기능, 산출물 │
├─────────────────────────────────────────────────────────────┤
│ Success State (완료 후 무엇이 가능해지는가?) │
│ → 완성 후의 세계, 사용자가 할 수 있게 되는 것 │
└─────────────────────────────────────────────────────────────┘
왜 이것이 중요한가?
AI 에이전트는 구현 중에 수많은 판단을 내려야 합니다. "이 기능이 필요한가?" "이 엣지 케이스는 대응해야 하는가?"
"What"만으로는 판단할 수 없습니다. "Why"와 "Success State"가 있으면 에이전트가 자율적으로 판단할 수 있습니다.
# design.md 예시
## Why (배경/동기)
현재 ToDo의 완료/미완료는 나만 알 수 있다.
팀과 공유하고 싶지만, 매번 스크린샷을 찍어서 Slack에 올리는 것은 번거롭다.
## What (만들 것)
ToDo 리스트 공유 기능을 구현한다.
## Success State (성공 후의 세계)
- 팀원이 링크 하나로 다른 사람의 ToDo 리스트를 볼 수 있다
- "오늘 뭐 했어?"라고 묻지 않아도 진행 상황을 알 수 있다
이 정의가 있으면, 구현 중에 "알림 기능도 추가해야 할까?"라고 고민될 때 "Success State 달성에 필요한가?"로 판단할 수 있습니다. 답은 "아니오, 볼 수 있으면 충분하다"입니다.
이 목표 정의는 프로젝트 전체와 각 Phase의 두 계층에서 수행됩니다(자세한 내용은 아래 "목표의 계층 구조"에서 설명).
2. 구조화된 문서
{project}/
├── README.md # 진입점, 전체 진행 상황
├── design.md # 비전, 설계 철학
├── phase1/
│ ├── README.md # Phase 진행 상황, 체크리스트
│ └── implementation-plan.md # 상세 구현 계획
├── phase2/
│ └── ...
└── phase3/
└── ...
문서 구조 자체가 프로젝트 구조를 반영합니다. README를 열면 현재 위치를 알 수 있고, design.md를 읽으면 목표 방향을 알 수 있습니다.
3. 명시적 상태 관리
Phase/Step 상태 전이:
미착수 ───→ 진행 중 ───→ 완료
│
↓
블로킹 중
"대충 끝났다"는 허용되지 않습니다. 모든 Phase, 모든 Step에 명시적인 상태가 부여됩니다. 체크리스트의 ✅가 객관적인 진행 상황을 나타냅니다.
4. 표준화된 인수인계
세션 시작 시(인수인계를 받는 쪽):
- 프로젝트 README 읽기 → 전체 상황 파악
- design.md 읽기 → 비전과 설계 철학 이해
- 현재 Phase README 읽기 → 상세 진행 상황 파악
- implementation-plan.md 읽기 → 구체적인 구현 방법 확인
- 작업 시작
세션 종료 시(인수인계를 하는 쪽):
- 체크리스트 업데이트
- 상태 업데이트
- 업데이트 이력에 추가
- 미완료 태스크 명기
- 커밋 및 푸시
이를 통해 "다음 에이전트에게 무엇을 전달해야 하는지" 고민할 필요가 없어집니다. 프로토콜을 따르기만 하면 됩니다.
프로젝트 구조: Project → Phase → Step
SAO는 계층 구조로 프로젝트를 관리합니다.
Project (프로젝트 전체)
│
├── Phase 1 (큰 작업 단위)
│ ├── Step 1 (구체적 태스크)
│ ├── Step 2
│ └── Step 3
│
├── Phase 2
│ └── ...
│
└── Phase N
Project: 달성하고자 하는 최종 목표입니다. "인증 시스템 구현" 등이 해당됩니다.
Phase: 의미 있는 중간 마일스톤입니다. Phase 단위로 "완료"라고 말할 수 있는 상태가 됩니다.
Step: 구체적인 태스크입니다. 한 세션에서 완료할 수 있는 크기로 설정합니다.
Phase 설계의 5요소
각 Phase는 다음 다섯 가지 요소로 정의됩니다:
┌─────────────────────────────────────────────────────────────┐
│ Phase N: {Phase 이름} │
├─────────────────────────────────────────────────────────────┤
│ 1. Purpose (목적) │
│ → 이 Phase에서 달성하는 것 │
│ │
│ 2. Why It's Needed (왜 필요한가) │
│ → 왜 이 Phase가 먼저 필요한가, 이전 Phase와의 관계 │
│ │
│ 3. Goals (목표) │
│ → 이 Phase에서 구현하는 기능적 요구사항 │
│ → 형식: "사용자는 ~할 수 있다" / "시스템은 ~할 수 있다" │
│ │
│ 4. Success Criteria (성공 기준) │
│ → 객관적으로 검증 가능한 완료 조건 │
│ │
│ 5. Dependencies (의존관계) │
│ → 먼저 완료되어야 하는 Phase │
└─────────────────────────────────────────────────────────────┘
Goals: 기능적 요구사항 열거
SAO의 Goals 정의의 특징은 "이 Phase에서 구현하는 기능적 요구사항"을 명확히 열거하는 것입니다.
# Phase 1: 인증 기반의 Goals
- 사용자가 이메일 주소로 회원가입할 수 있다
- 사용자가 로그인/로그아웃할 수 있다
- 페이지 새로고침 후에도 세션이 유지된다
- 미인증 사용자가 보호된 페이지에 접근할 수 없다
왜 기능적 요구사항으로 작성하는가?
- 검증이 명확: "할 수 있다/없다"로 완료를 판단할 수 있다
- 범위가 명확: 무엇을 만들지가 구체적으로 알 수 있다
- 다음 Phase로의 연결: Phase 1에서 실현한 기능이 Phase 2의 전제가 된다
Phase 1의 Goals가 달성되지 않으면 Phase 2 구현이 어렵습니다. 이 연쇄가 의존관계에 "이유"를 부여합니다.
구체적 예시: 인증 시스템의 Phase 설계
### Phase 1: 인증 기반
#### Purpose
인증에 필요한 DB, API, 설정을 구축한다
#### Why It's Needed
Google 인증도 이메일 인증도 이 기반 위에 구축된다
#### Goals
- 사용자가 이메일 주소로 회원가입할 수 있다
- 사용자가 로그인/로그아웃할 수 있다
- 페이지 새로고침 후에도 세션이 유지된다
#### Success Criteria
1. users 테이블에 테스트 사용자를 생성할 수 있다
2. /api/auth/session이 정상적인 응답을 반환한다
3. 인증 미들웨어가 미인증 요청을 401로 거부한다
#### Dependencies
- None
목표의 계층 구조
"네 가지 기둥"에서 설명한 Why / What / Success State는 프로젝트 전체의 목표입니다. SAO에서는 이에 더해 각 Phase에도 목표를 정의합니다.
┌─────────────────────────────────────────────────────────────┐
│ 프로젝트 전체 목표 (design.md) │
│ │
│ Why: 왜 이 프로젝트가 필요한가 │
│ What: 무엇을 만드는가 │
│ Success State: 완료 후 무엇이 가능해지는가 │
│ │
│ → "북극성". 길을 잃었을 때 돌아갈 곳 │
├─────────────────────────────────────────────────────────────┤
│ Phase 1 목표 │ Phase 2 목표 │
│ │ │
│ Purpose: 이 Phase에서 달성하는 것 │ Purpose: ... │
│ Why It's Needed: 왜 먼저 필요한가 │ Why It's Needed: ... │
│ Goals: 기능적 요구사항 │ Goals: ... │
│ Success Criteria: 완료 조건 │ Success Criteria: ... │
└─────────────────────────────────────────────────────────────┘
프로젝트 전체의 Success State에 도달하기 위해 각 Phase의 Goals를 달성해 나갑니다. 이 계층 구조가 대규모 프로젝트를 "분할 정복"하는 메커니즘입니다.
기존 설계서·계획서와의 차이
SAO는 "AI 에이전트를 위한 설계서"입니다. 기존 설계서·계획서와는 몇 가지 점에서 다릅니다.
1. 계획은 "제안"이지 "명령"이 아니다
기존 계획서:
계획 → 승인 → 실행 (계획대로)
변경 필요 → 변경 신청 → 재승인 → 실행
SAO 계획서:
계획 → 실행 시작 → 현실과의 차이 발견 → 자율적 판단·수정 → 특기하여 기록
SAO에서는 implementation-plan은 "완벽한 계획서"가 아닌 "제안"으로 취급합니다.
에이전트는 다음과 같은 자세로 작업에 임합니다:
- 계획을 의심한다: 계획이 현실과 괴리될 가능성을 항상 인식
- 부족함을 보완한다: 계획에 부족함이 있으면 후속 스텝의 내용을 먼저 확인
- 자율적으로 판단한다: 후속 스텝으로도 보완되지 않으면 스스로 판단하여 추가 구현
- 특기한다: 계획 외 추가 구현은 Phase README의 진행 상황에 반드시 특기
## 업데이트 이력 (특기 사항 예시)
| 날짜 | 작성자 | 내용 |
|-----|-------|------|
| 2026-01-13 | Agent | Step 2 완료. 계획에 없는 에러 핸들링 추가 구현 (이유: API 사양 변경으로 인해) |
2. "독자"가 AI 에이전트이다
기존 설계서:
- 사람이 읽고 "이해"하는 것을 전제
- 행간을 읽음, 암묵적 양해
- 다이어그램으로 시각적 전달
SAO 설계서:
- AI 에이전트가 "즉시 상태를 파악"할 수 있는 것을 전제
- 모든 것이 명시적, 모호함 배제
- 텍스트 기반으로 구조화 (마크다운)
# 기존 설계서에서 흔한 기술
"인증 기능을 구현한다. 상세는 별도 협의."
# SAO에서의 기술
### Phase 1: 인증 기반
| 진행 상황 | `진행 중` 🔄 |
#### Goals
- 사용자가 이메일 주소로 회원가입할 수 있다
- 사용자가 로그인/로그아웃할 수 있다
- 페이지 새로고침 후에도 세션이 유지된다
#### Success Criteria
1. 회원가입 후 로그인이 되는지 확인
2. 로그아웃 후 보호된 페이지에 접근할 수 없는지 확인
3. "상태"가 일급 시민이다
기존 프로젝트 관리:
- 진행 상황은 회의에서 구두 보고
- 상태는 Excel이나 Jira에서 별도 관리
- 설계서와 진행 관리가 분리
SAO:
- 진행 상황이 문서 자체에 포함됨
- 상태가 설계서의 일부
- 설계서를 읽으면 진행 상황도 알 수 있음
문서를 여는 순간 "지금 어디에 있는지"를 알 수 있습니다.
4. "인수인계"가 전제이다
기존 설계서:
- 작성한 사람이 구현하는 경우가 많음
- 인수인계는 예외적인 이벤트
- 인수인계 시 "인수인계 자료"를 별도 작성
SAO:
- 매 세션마다 인수인계가 발생하는 것이 전제
- 인수인계 프로토콜이 표준화
- 문서 자체가 인수인계 자료
AI 에이전트는 매번 "기억상실"합니다. 그래서 모든 세션이 "인수인계"이며, 문서는 항상 "다음 에이전트가 읽는다"는 전제로 작성됩니다.
비교표
| 관점 | 기존 설계서 | SAO 설계서 |
|---|---|---|
| 독자 | 사람 | AI 에이전트 |
| 계획의 취급 | 명령 (따름) | 제안 (비판적으로 평가) |
| 상태 관리 | 별도 시스템 | 문서에 포함 |
| 인수인계 | 예외 이벤트 | 매 세션 발생 |
| 모호함 | 허용 (행간을 읽음) | 배제 (모든 것 명시) |
| 목표 정의 | What 중심 | Why + What + Success State |
SAO를 사용해야 하는 경우
사용해야 하는 경우
- 한 세션으로 완료되지 않는 규모 — 여러 날, 여러 주에 걸친 프로젝트
- 3개 이상의 Phase가 있음 — 단계적 구현이 필요
- 여러 에이전트/사람이 관여 — 인수인계가 발생
- 일주일 이상 소요 — 기억의 영속화가 필요
사용하지 않아도 되는 경우
- 한 세션으로 완료 가능
- 단순한 버그 수정
- 독립적인 작은 태스크
오버헤드를 고려하세요. SAO는 문서 작성 비용이 듭니다. 작은 태스크에는 적합하지 않습니다.
장점과 단점
장점
| 장점 | 설명 |
|---|---|
| 지속성 | 세션이 끊겨도 작업을 계속할 수 있다. 가장 큰 장점 |
| 투명성 | 진행 상황이 가시화된다. "지금 어디에 있는지"를 한눈에 알 수 있다 |
| 재현성 | 다른 에이전트라도 동일한 프로토콜을 따르면 작업을 인수인계할 수 있다 |
| 품질 보증 | 각 Step에 완료 조건이 정의되어 있어 "대충 끝났다"가 없다 |
단점
| 단점 | 설명 |
|---|---|
| 오버헤드 | 문서 작성·업데이트 비용이 든다. 작은 태스크에는 적합하지 않다 |
| 초기 학습 비용 | SAO 방법론을 이해하고 템플릿 사용법을 익혀야 한다 |
| 경직성의 위험 | 계획에 지나치게 집착하면 유연성이 떨어진다. 비판적 접근이 필요 |
지금 바로 시도해보기
SAO는 npx 명령어 하나로 프로젝트에 도입할 수 있습니다.
빠른 시작 (Claude Code용)
# 프로젝트 루트 디렉토리에서 실행
npx init-sao-claude
이것만으로 다음이 설정됩니다:
.claude/
├── sao/
│ └── concepts/
│ ├── README.md # SAO 방법론 해설
│ └── templates/ # 프로젝트 템플릿
│ ├── project-readme.md
│ ├── design.md
│ ├── phase-readme.md
│ └── implementation-plan.md
└── commands/
├── sao-starter.md # /sao-starter 명령어
└── sao-step.md # /sao-step 명령어
사용법
설정 후 Claude Code에서 다음 명령어를 사용할 수 있습니다:
/sao-starter my-feature
→ 새로운 SAO 프로젝트 "my-feature"를 생성합니다. Claude가 요구사항을 인터뷰하고 Phase 구성을 제안합니다.
/sao-step my-feature
→ 프로젝트 "my-feature"의 다음 Step을 실행합니다. 완료되면 자동으로 상태를 업데이트합니다.
실제 흐름
User: /sao-starter auth-system
Claude: 인증 시스템에 대해 알려주세요.
1. 무엇을 실현하고 싶으신가요?
2. 대상 사용자는 누구인가요?
3. 필수 기능은 무엇인가요?
...(인터뷰)
Claude: 다음 Phase 구성으로 진행하겠습니다:
- Phase 1: 인증 기반 (DB, 기본 API)
- Phase 2: 로그인/회원가입 UI
- Phase 3: 비밀번호 재설정
- Phase 4: 세션 관리 강화
괜찮으신가요?
User: OK
Claude: 프로젝트를 생성했습니다.
.claude/sao/projects/active/auth-system/
/sao-step auth-system 으로 구현을 시작할 수 있습니다.
User: /sao-step auth-system
Claude: Phase 1 Step 1부터 시작합니다.
...(구현)
Step 1 완료. 상태를 업데이트했습니다.
다음은 /sao-step auth-system 으로 Step 2를 실행할 수 있습니다.
다음 세션에서도:
User: /sao-step auth-system
Claude: README.md 확인... Phase 1 Step 2부터 재개합니다.
...(설명 없이 즉시 이어서 작업)
요약
SAO(Stateful Agent Orchestration)는 AI 에이전트의 기억 제한이라는 근본적인 문제에 대한 실용적인 해결책입니다.
네 가지 기둥:
- 목표 정의 (Why / What / Success State)
- 구조화된 문서
- 명시적 상태 관리
- 표준화된 인수인계
사용 사례:
- 대규모 프로젝트
- 여러 세션/여러 에이전트가 관여하는 작업
- 지속적인 개발
지금 바로 시작:
npx init-sao-claude
AI 에이전트는 우수합니다. 그러나 그 능력을 대규모 프로젝트에서 발휘하려면 "기억의 벽"을 넘는 구조가 필요합니다.
SAO는 그 벽을 넘기 위한 하나의 답입니다.