오늘은 Fable 5를 사용해 다른 모델로도 Fable 5처럼 사용할 수 있는 AI 에이전트 지침을 만드는 시도를 정리해 보려고 합니다. Fable 5가 성능이 워낙 좋다는 소식에 Fable 5가 너무 비싸니까 비슷한 걸 지침으로 만들 수 있을까? 라고 생각하고 시작했었습니다. 결론적으로 동일하게 동작하는 지침을 만드는 건 실패했지만, 기존에 사용하던 지침보다는 더 일을 잘하는 지침을 만드는 건 성공했습니다. (글 마지막 github link 첨부)
Fable 5와 유사하게 만들기 위해 사용한 방법
먼저 Fable 5에게 '다른 모델을 사용해도 Fable 5처럼 동작하는 지침을 만들어줘.'라고 요청했습니다.
Fable 5가 세세한 절차 지시를 기입하지 않아도 잘 한다고 했으니 그대로 사용해봤습니다. 원하는 목표만 주고 나온 결과물을 'Fable 5처럼 동작하게 잘 구성됐는지' 피드백 및 평가를 요청해 개선했습니다.
Fable 5로 초안 작성
→ 부족한 부분 피드백
→ 지침 수정
→ 실제 작업 상황을 대입해 검토
→ 다시 피드백
→ 구조와 표현 개선
에이전트 지침의 핵심 구성
완전하진 않지만 위와 같은 과정을 통해 완성한 지침은 목적과 예시를 제공하면 에이전트가 계획을 세우고 작업 및 검증까지 하도록 구현하는 것에 성공했습니다.
지침의 주요 구성
| 핵심 원칙 | 목적 파악, 모호함 처리, 불확실성 표시 |
| 작업 규율 | 범위 통제, 진행 상황 보고, 임의 수정 방지 |
| 분석 프로토콜 | 샘플 검증, 행 수 추적, 집계 결과 역산 |
| 설계 프로토콜 | 요구사항, 제약 조건, 대안과 트레이드오프 기록 |
| Orchestrator | 작업 분해, 위험도 판단, 실행 순서 계획 |
| Reviewer | 작성자와 별도 관점에서 결과물 검증 |
| Memory | 프로젝트에서 반복되는 교훈 저장 |
| State | 긴 작업의 단계와 검토 상태 기록 |
모호함을 처리하는 기준
에이전트가 모든 애매한 내용을 사용자에게 질문하면 작업 속도가 너무 느려집니다.
반대로 전부 임의로 판단하게 하면 결과물이 잘못된 방향으로 진행될 수 있습니다.
그래서 다음과 같이 지침이 만들어졌습니다.
가정이 틀렸을 때 결과물을 다시 만들어야 한다면 질문하고, 결과에 큰 영향이 없다면 합리적으로 가정한 뒤 가정 내용을 명시합니다.
예를 들어 날짜 컬럼이 생성일인지 수정일인지에 따라 분석 결과가 달라진다면 반드시 확인해야 합니다.
하지만 출력 파일 이름처럼 결과의 본질에 영향을 주지 않는 내용은 기본값을 사용해도 됩니다.
이 기준을 넣은 뒤에는 에이전트가 불필요한 질문을 반복하거나, 중요한 내용을 마음대로 판단하는 문제가 줄어들었습니다.
확인된 사실과 추정 구분하기
AI의 가장 위험한 문제 중 하나는 확실하지 않은 내용을 자연스럽게 사실처럼 작성한다는 점입니다.
이를 방지하기 위해 근거의 수준을 다음과 같이 구분했습니다.
| 확인됨 | 원본 파일이나 실행 결과로 직접 검증됨 |
| 추정 | 간접적인 근거를 바탕으로 판단함 |
| 가정 | 작업 진행을 위해 기본값으로 선택함 |
| 검증 필요 | 현재 자료만으로 확정할 수 없음 |
예를 들어 파일을 수정했다고 보고하려면 실제로 파일이 저장되었는지 확인해야 합니다.
테스트가 통과했다고 말하려면 테스트 명령어를 실행한 결과가 있어야 합니다.
도구로 확인하지 않은 작업은 완료했다고 보고하지 않도록 지침에 명시했습니다.
작성자와 검토자 분리하기
제가 기존에 사용하던 지침은 하나의 에이전트가 결과물을 만들고 스스로 다시 읽는 방식이었습니다.
이러면 에이전트가 자신이 만든 논리와 가정에 이미 영향을 받은 상태이기 때문에, 단순히 다시 읽는 것만으로는 문제를 찾기 어려워 다음과 같이 역할이 분리됐습니다.
Orchestrator
↓
Worker
↓
Reviewer
↓
수정 필요 여부 판단
↓
Worker 재작업
↓
Reviewer 재검증
여기서 실제 작업의 전체 흐름은 메인 에이전트가 관리합니다.
- Orchestrator: 작업 분해와 실행 계획을 제안
- Worker: 실제 분석, 코드 작성, 문서 작성 수행
- Reviewer: 결과물만 보고 오류와 누락 검토
- 메인 에이전트: 검토 결과에 따라 수정과 재검증 진행
Reviewer는 단순히 문장을 자연스럽게 고치는 역할이 아닙니다.
다음과 같은 관점으로 결과물을 공격적으로 검토하도록 구성했습니다.
- 요청사항을 모두 충족했는가?
- 결론이 근거에서 실제로 도출되는가?
- 수치와 행 수가 서로 모순되지 않는가?
- 추정이나 가정을 사실처럼 표현하지 않았는가?
- 요청하지 않은 범위까지 수정하지 않았는가?
- 이 결론을 반박할 수 있는 사례는 없는가?
대규모 분석을 위한 검증 절차
저는 주로 데이터 분석에 에이전트를 사용하는데, 기존에는 에이전트가 작업한 결과물에 대해서 실제로 결과에 문제가 없는지 검수하는 데 시간을 오래 사용했었습니다. 특히 많은 데이터를 한 번에 처리하면 중간 과정에서 발생한 오류를 찾기 어려웠습니다.
만들어진 지침에서는 다음과 같은 절차를 기본 원칙으로 넣어 기본적인 검수를 에이전트가 하도록 구현됐습니다.
전체 데이터 구조 확인
→ 소규모 샘플로 로직 검증
→ 처리 단계별 행 수 기록
→ 전체 데이터에 적용
→ 집계 결과를 원본 데이터로 역추적
→ 이상 여부 확인
예를 들어 데이터가 다음과 같이 변했다면 각 단계의 원인을 확인합니다.
원본 데이터: 100,000행
필터 적용 후: 82,000행
조인 후: 125,000행
중복 제거 후: 81,500행
조인 후 행 수가 예상보다 늘어났다면 바로 다음 작업으로 넘어가는 것이 아니라, 조인 키의 중복이나 다대다 관계를 먼저 확인합니다. 이런 검증 절차로 속도는 조금 줄었지만, 잘못된 분석 결과를 에이전트가 1차로 먼저 잡아냈습니다.
Cursor와 Claude Code에 적용한 구조
만든 지침은 하나의 문서로만 관리하지 않고, Cursor와 Claude Code에서 각각 사용할 수 있도록 구성했습니다.
저는 주로 Cursor로만 작업을 하는데 주변에는 Claude Code를 쓰는 사람들도 많아서 둘다 만들었습니다.
agent-thinking-guidelines/
├── docs/
│ ├── agent-thinking-guidelines.md
│ ├── agent-system-overview.md
│ └── multi-agent-orchestration.md
├── cursor/
│ ├── .cursor/rules/
│ ├── .cursor/skills/
│ ├── .cursor/agents/
│ ├── .cursor/memory/
│ └── .cursor/state/
└── claude/
├── CLAUDE.md
├── skills/
├── agents/
├── .claude/memory/
└── .claude/state/
docs/를 원본 지침으로 사용하고, 해당 내용을 Cursor와 Claude Code의 규칙 체계에 맞게 각각 변환했습니다.
원본 역할CursorClaude Code
| 핵심 원칙 | .cursor/rules/*.mdc | CLAUDE.md |
| 상황별 프로토콜 | .cursor/skills/ | .claude/skills/ |
| 서브에이전트 | .cursor/agents/ | .claude/agents/ |
| 프로젝트 기억 | .cursor/memory/ | .claude/memory/ |
| 작업 상태 | .cursor/state/ | .claude/state/ |
이렇게 구성한 이유는 도구별 파일 구조는 달라도, 에이전트가 따라야 하는 핵심 원칙은 하나의 원본에서 관리하기 위해서입니다. 한쪽 지침만 수정하고 다른 쪽을 놓치지 않도록 docs/를 SSOT(Single Source of Truth)로 사용했습니다.
세션 간 기억을 추가한 이유
AI와 작업하다 보면 이전 세션에서 이미 해결한 문제를 다음 세션에서 다시 설명해야 하는 경우가 많습니다.
이를 줄이기 위해 프로젝트에서 반복되는 교훈을 파일로 저장하도록 구성했습니다.
.cursor/memory/
└── timestamp-column.md
예시 내용은 다음과 같습니다.
요약: created_at은 데이터 생성일이 아니라 동기화 시점이므로 기간 분석 기준으로 사용하지 않습니다.
프로젝트의 기간 분석에서는 service_date를 기준으로 사용합니다.
created_at은 적재 및 동기화 상태를 확인하는 용도로만 사용합니다.
메모리는 한 파일에 모든 내용을 누적하지 않고, 한 가지 교훈을 하나의 파일로 관리하도록 했습니다. 세션 시작 시 모든 파일의 본문을 읽는 대신 첫 번째 요약 문장만 확인하고, 현재 작업과 관련된 메모만 자세히 읽게 구성했습니다.
직접 사용해 본 후기
현재까지 사용해 본 결과는 만족스럽습니다.
가장 크게 달라진 부분은 결과물 뿐만 아니라 작업 설계 편의성과 작업 과정의 안정성, 그리고 가성비였습니다.
설계 편의성
- 세세하게 지시하지 않고 작업 목표만 줘도 설계를 하고 애매한 건 물어봄
안정성
- 애매한 내용을 임의로 채우는 경우가 줄어듦
- 작업 범위를 벗어난 수정이 줄어듦
- 긴 작업에서도 현재 단계와 남은 작업을 확인하기 쉬워짐
- 데이터 분석 결과를 한 번 더 검증하는 흐름이 생김
- 완료했다고 보고한 내용과 실제 작업 결과가 비교적 잘 일치함
- 수정 요청 시 처음부터 다시 만드는 일이 줄어듦
가성비
- Composer 2.5로도 충분히 만족스러운 결과가 나옴
Fable 5와 같게 만들 수 있었는가?
결론적으로 Fable 5와 완전히 같게 만드는 것은 불가능했습니다.
지침을 잘 작성한다고 해서 모델 자체의 추론 능력이나 판단 능력이 올라가는 것은 아니기 때문입니다.
지침으로 개선할 수 있는 것은 주로 다음과 같은 행동 패턴입니다.
- 작업 전 요구사항 확인
- 모호함을 처리하는 방식
- 검증 절차 수행
- 불확실성 표시
- 작업 범위 통제
- 결과물 자체 검토
- 진행 상황과 오류 보고
반면 다음과 같은 부분은 사용하는 모델의 성능에 영향을 많이 받습니다.
- 복잡한 문제를 분해하는 능력
- 긴 문맥을 유지하는 능력
- 미묘한 오류를 발견하는 능력
- 새로운 상황에 규칙을 적절히 적용하는 능력
- 여러 도구와 에이전트를 안정적으로 조율하는 능력
따라서 이번 지침은 Fable 5를 복제한 결과물이라기보다는, Fable 5에서 만족스러웠던 작업 방식을 일반적인 에이전트 환경에 적용해 본 결과물에 가깝습니다. 완전히 동일하지는 않지만, 제가 원했던 방향에는 어느 정도 유사하게 만들어진 것 같습니다.
마무리
Fable 5와 완전히 같게 만들 수는 없었지만, Fable 5로 초안을 만들고 피드백과 개선을 반복하면서 그나마 유사한 방향으로 다듬어 본 결과 현재는 꽤 만족스럽게 사용하고 있습니다. 앞으로 사용해보면서 지속적으로 개선해볼 생각입니다.
에이전트 지침으로 뭘 써야하나 이것저것 테스트해보시거나, 직접 만들어보려고 시도 중이신 분들에게 도움이 되면 좋을 것 같습니다. 감사합니다.
