WAT 프레임워크: 에이전트와 코드를 나누는 이유
여기까지 잘 따라오셨습니다.
1편에서 에이전틱 워크플로우는 배포하는 순간 에이전트가 빠진다는 얘기로 끝냈죠.
그럼 실제로 배포되는 건 뭘까요?
이번 편의 답은 WAT 프레임워크입니다.
WAT 프레임워크는 일을 Workflows(절차서), Agent(판단), Tools(실행 코드) 세 층으로 나누고, 판단은 에이전트에게, 반복 실행은 결정론적인 코드에게 맡기는 구조입니다.
구조 없이 Claude Code를 쓰면 어떻게 되나?
사물함을 떠올려 보면 쉽습니다.
과목별 종이를 정리 없이 사물함에 던져 넣어도 A를 받을 수는 있어요.
그런데 종이 더미를 뒤지다 잊어버리고 잃어버리죠.
Claude Code도 그냥 말을 걸면 꽤 잘하지만, 구조가 없으면 금방 엉망이 됩니다.
그래서 바인더와 폴더 역할을 하는 게 WAT입니다.
W, A, T는 각각 무슨 일을 하나?
W(워크플로우)는 마크다운으로 쓴 지시서입니다.
사실상 자연어라 누구나 읽을 수 있고, 직무 기술서나 SOP에 가까워요.
A(에이전트)는 Claude Code 자체, 곧 두뇌입니다.
워크플로우를 읽고, 어떤 도구를 언제 쓸지 정하고, 고장 나면 조사해서 적응합니다.
지시서를 받아 담당에게 일을 나눠 주는 프로젝트 매니저라고 보면 됩니다.
T(도구)는 실제 일을 하는 Python 스크립트입니다.
도구 하나는 웹사이트 스크래핑, PDF 생성처럼 한 가지 일만 해요.
말하자면 "못생긴 코드가 사는 곳"이고, 사용자는 건드릴 필요가 없습니다.
셰프에 비유하면 더 쉽습니다.
셰프(에이전트)는 레시피(워크플로우)를 읽거나 직접 만들고, 달걀과 밀가루(도구)를 씁니다.
"순서와 구조가 없으면 도구는 쓸모없다"는 말이 이 비유의 핵심입니다.
예를 들면 이렇습니다.
"X사 가격을 조사해서 PDF 보고서를 만들어 줘"라고 하면,
에이전트가 워크플로우를 읽고 웹 검색, 스크래핑, 분석, PDF 생성 도구를 순서대로 부릅니다.
사용자는 단계를 하나도 매핑하지 않아요.
왜 굳이 에이전트와 코드를 나누나?
WAT용 CLAUDE.md에 흔히 넣는 문장이 있습니다.
AI가 모든 단계를 직접 처리하면 정확도가 빠르게 떨어진다는 뜻입니다.
제 식으로 풀면, 단계마다 작은 오차가 쌓여 다섯 번째쯤엔 열에 넷이 실패하는 구조예요.
설계 판단은 이렇습니다.
AI는 같은 입력에도 결과가 달라지는 비결정론적인 존재예요.
1편에서 짚었듯이 AI 자동화 빌더의 일은 "비결정론적인 프로세스를 가능한 한 결정론적으로 만드는 것"이고요.
그러니 어떤 도구를 쓸지, 오류를 어떻게 풀지처럼 판단이 필요한 곳만 에이전트에게 맡기고, 매번 똑같이 돌아야 하는 실행은 코드로 고정하는 겁니다.
결과가 흔들릴 수 있는 단계 수 자체를 줄이는 셈이죠.
WAT 프로젝트 폴더는 어떻게 생겼나?
WAT 프로젝트의 기본 구조는 이렇습니다.
프로젝트/
├── CLAUDE.md # 프로젝트 지시서, WAT 규칙
├── workflows/ # 마크다운 워크플로우 (예: competitor analysis)
├── tools/ # Python 도구 (예: discover competitors, generate competitor PDF)
├── 임시 폴더/ # 중간 산출물, 임시 파일
└── .env # API 키 보관
CLAUDE.md에는 보통 세 층의 정의, 90%와 59% 얘기, 운영 방식, 자기 개선 루프, 파일 구조가 들어 있습니다.
운영 방식은 "기존 도구부터 찾고, 실패하면 오류를 읽고 스크립트를 고쳐 다시 시도하고, 워크플로우를 최신으로 유지한다"는 내용이에요.
예를 들어 채용 공고를 모으는 워크플로우 파일("scrape job listings")에는 목표, 입력(검색어, 최대 페이지 수, 출력 경로), 쓸 도구, 단계, 출력, 엣지 케이스, 오류 처리가 들어갑니다.
시키지 않아도 프레임워크 덕분에 엣지 케이스와 오류 처리가 들어갑니다.
배포하면 W와 T만 올라간다
스케줄이나 웹훅으로 배포하면 올라가는 건 워크플로우와 도구입니다.
에이전트는 빠져요.
오히려 이게 좋습니다.
배포된 자동화는 예측 가능하고 결정론적이어야 하니까요.
만들 때는 에이전트가 옆에서 고치고, 돌릴 때는 검증된 코드만 도는 구조인 셈입니다.
체리시사인에 WAT를 도입해 보니
저는 AI 점성술 앱 체리시사인을 직접 개발해 운영하고 있습니다.
2026년 9월 중순, 체리시사인 개발 루프에 WAT 구조를 도입했습니다.
W는 workflows/ 폴더(예: workflows/fix_bug.md)와, 분석 프롬프트를 바꿀 때마다 제가 주는 검사 기준입니다.
A는 그 기준을 읽고 고칠지, 다시 검사할지, 저에게 보고할지 판단하는 AI예요.
T는 Playwright로 실제 브라우저에서 도는 E2E 테스트처럼 매번 같은 방식으로 실행되는 검사입니다.
여기에 lessons/ 폴더를 하나 더 뒀습니다. 버그를 해결할 때마다 기록이 쌓이는 곳이에요.
규칙은 하나입니다. 같은 문제가 두 번째면 워크플로로 올린다.
lessons의 기록이 반복되면 확인 순서를 워크플로우 파일로 승격하는 거죠. CLAUDE.md에 넣는 자기 개선 루프와 같은 방향입니다.
자가 수정은 최대 3번까지만 돌고, 그다음엔 저에게 보고하게 했어요.
왜 하필 3번인지, lessons/가 실제로 잡아낸 버그와 숫자는 [3편 링크]에서 자세히 풀어보겠습니다.
마치며
판단은 에이전트에게, 반복 실행은 코드에게, 절차는 마크다운에게.
WAT는 AI를 더 많이 쓰는 방법이라기보다 AI가 맡을 범위를 정확히 좁히는 설계에 가깝습니다.
다음 3편에서는 Claude Code로 실제로 만드는 흐름과, 체리시사인에서 이 구조로 제 개입 시간이 얼마나 줄었는지 구체적인 숫자로 보여드릴게요.
AI 워크플로우 자동화 잘 하는 법, 직접 적용 후기
여기까지 잘 따라오셨습니다.1편에서는 AI 워크플로우 자동화가 무엇인지, 2편에서는 에이전트와 코드를 나누는 WAT 프레임워크를 다뤘죠.이제 마지막으로 잘 하는 법과, 제가 실제 제품에 어떻
kasts91.tistory.com
참고: Build & Sell with Claude Code (10+ Hour Course), https://www.youtube.com/watch?v=mpALXah_PBg