설계 6단계, 실전 3단계 — AI 파이프라인은 왜 날씬해지는가
6개 에이전트로 깔끔하게 설계한 AI 파이프라인이, 실전 테스트 3회 만에 3단계로 줄어든 이야기. 설계의 우아함과 실전의 효율 사이에서 배운 것들.
- 배경: AI 에이전트 파이프라인을 설계할 때 역할을 잘게 나누면 좋을 거라 생각했는데, 실전에서는 오히려 비효율이 됐어요
- 핵심 인사이트: 파이프라인의 단계 수는 설계가 아니라 실전이 결정한다는 걸 알게 됐어요
- 이런 분에게: AI 에이전트를 여러 개 연결해서 자동화를 만들고 있는데, “이거 너무 복잡한 건 아닌가?” 고민 중인 분
에이전트 6개, 완벽한 설계
AI한테 일을 시킬 때, 역할을 잘게 나누면 좋다는 이야기 많이 들어보셨을 거예요. “하나의 에이전트에 하나의 역할.” 소프트웨어 설계의 단일 책임 원칙처럼요.
저도 그렇게 생각했어요.
AI가 블로그 글을 대신 써주는 콘텐츠 파이프라인을 만들 때, 처음 설계한 구조는 이랬어요.
사진 분석 → 리서치 → 콘텐츠 전략 → 글쓰기 → 톤 보정 → 품질 검증6단계. 각 단계마다 전담 에이전트가 하나씩. 사진 분석기는 사진만 보고, 전략 에이전트는 목차만 짜고, 글쓰기 에이전트는 글만 쓰고. 역할이 깔끔하게 나뉘어 있으니까 관리도 쉽고, 문제가 생기면 어디서 생겼는지도 바로 알 수 있을 거라고 생각했어요.
종이 위에서는 정말 우아한 설계였어요.
실전에서 벌어진 일
그런데 실제로 돌려보니까, 이상한 일이 일어나더라고요.
E2E 테스트를 3번 하면서 관찰한 건데요. 6단계로 설계해놨지만, 실제로 실행할 때는 콘텐츠 전략 에이전트를 따로 부르지 않고 있었어요. 글쓰기 에이전트한테 목차를 직접 전달하고 있었고, 톤 보정 에이전트도 따로 돌리지 않았어요. 품질 검증도 별도로 실행하지 않았고요.
자연스럽게 수렴한 실전 흐름은 이거였어요.
사진 분석 → 글쓰기 → 저장3단계. 설계의 반.
처음에는 “테스트니까 대충 한 거겠지” 하고 넘어갔는데, 세 번째 테스트에서도 같은 패턴이 반복되니까 깨달았어요. 이건 제가 대충 한 게 아니라, 6단계가 실전에서는 비효율적이었던 거예요.
왜 줄어들었을까
돌이켜보면 원인은 명확했어요.
콘텐츠 전략과 글쓰기를 분리한 게 오히려 비용이었어요. 전략 에이전트가 목차와 사진 배치를 설계해줘도, 글쓰기 에이전트가 실제로 글을 쓸 때는 맥락을 처음부터 다시 파악해야 했거든요. 하나의 에이전트가 전략과 작성을 동시에 하면 이 맥락 전환 비용이 사라져요.
톤 보정도 마찬가지였어요. 글쓰기 에이전트가 이미 톤 가이드를 내장하고 있었기 때문에, 별도 에이전트가 톤을 다시 다듬을 필요가 거의 없었어요. 글쓰기 에이전트의 셀프 리뷰로 충분한 수준이었고요.
품질 검증은 너무 단순했어요. 파일 저장하고 체크리스트 확인하는 건, 별도 에이전트를 부를 만한 복잡도가 아니었어요.
한마디로, 역할을 나눈 건 좋았는데 나누는 비용이 나눈 이점보다 컸던 거예요.
그런데 단계가 늘어나야 할 때도 있더라고요
여기서 반전이 하나 있어요.
파이프라인 단계를 줄인 거의 같은 시기에, 오히려 단계를 하나 추가해야 하는 상황도 겪었어요.
글쓰기 에이전트가 만든 콘텐츠를 읽어봤는데, 소스 자료에는 없는 이야기가 들어가 있더라고요. 회고 노트를 기반으로 글을 쓰라고 했는데, 정작 오프닝은 회고와 상관없는 “비행기 안에서 글이 더 잘 써진다”는 내용으로 시작하고 있었어요.
소스를 대조해보니까, 그 회고 파일 안에 다른 주제의 메모 요약이 섞여 있었고, AI가 그중에서 가장 시각적으로 눈에 띄는 소재를 골라버린 거였어요. “무기력”보다 “비행기”가 이미지가 선명하니까요.
톤 검수 에이전트는 이 문제를 잡지 못했어요. 톤은 완벽했거든요. 점수도 0.95점. 하지만 무엇을 쓰느냐와 어떻게 쓰느냐는 다른 축이에요. 톤 검수는 “어떻게”만 보고 있었어요.
그래서 콘텐츠 리뷰어라는 에이전트를 새로 만들었어요. 소스 원문과 결과물을 대조해서 “이 글이 소스의 핵심을 제대로 반영하고 있는가?”를 확인하는 역할. 이 단계를 추가하고 나서야 비로소 회고 노트의 본질인 무기력과 루틴 설계 이야기가 제대로 콘텐츠에 담겼어요.
줄일 때와 늘릴 때의 차이
같은 시기에 단계를 줄이기도 하고 늘리기도 했으니까, “그래서 뭐가 맞는 건데?” 싶으실 수 있어요.
정리해보니까 기준이 보이더라고요.
줄여야 할 때: 앞 단계의 출력을 뒷 단계가 거의 그대로 반복하는 경우. 콘텐츠 전략 에이전트가 목차를 짜줘도 글쓰기 에이전트가 맥락을 처음부터 다시 파악해야 했던 것처럼요. 분리의 비용이 이점보다 크면 합치는 게 맞아요.
늘려야 할 때: 기존 단계들이 놓치고 있는 검증 축이 있는 경우. 톤은 잡지만 콘텐츠 정합성은 확인하지 않던 것처럼요. 빈 축이 보이면 그건 별도 단계로 분리할 가치가 있어요.
결국 단계의 수는 “역할이 몇 개냐”가 아니라 **“각 단계가 고유한 가치를 만들어내느냐”**로 결정되더라고요.
실전이 알려준 것들
최종적으로 수렴한 파이프라인은 이렇게 됐어요.
사진 분석 → 리서치(필요할 때만) → 글쓰기(전략+톤 내장) → 콘텐츠 리뷰 → 저장6단계에서 시작해서, 3개를 합치고, 1개를 새로 넣었어요. 어떤 건 과했고, 어떤 건 빠져 있었던 거예요. 이걸 종이 위에서는 절대 알 수 없었을 거예요.
실전 테스트에서 발견한 사소하지만 실용적인 것도 있었어요. 글쓰기 에이전트가 사용자한테 질문을 6개씩 던지고 있었는데, 그중 절반은 에이전트가 스스로 검색하면 되는 것들이었어요. “주소를 아시나요?” 같은 질문. 질문은 정보를 얻는 행위이기도 하지만, 동시에 사용자의 시간과 인내심을 쓰는 행위거든요. 최대 3개로 제한하고, 스스로 해결할 수 있는 건 묻지 않도록 바꿨어요.
파일 이름도 그랬어요. 2026-04-01_14:30_restaurant.md라는 규칙으로 설계했는데, 실제로 파일 목록을 보니까 어떤 파일이 어떤 글인지 알 수가 없더라고요. 2026-04-01_오바마연탄구이_restaurant.md로 바꾸니까 바로 식별이 됐어요. 시간 정보보다 장소 이름이 훨씬 실용적이라는 건, 파일 목록을 직접 보기 전까지는 생각하지 못했어요.
인사이트
이 경험에서 얻은 교훈을 정리하면 세 가지예요.
설계는 가설이고, 실전이 검증이에요. 6단계로 역할을 깔끔하게 분리한 설계는 이론적으로 우아했지만, 실전에서는 맥락 전환 비용이 분리의 이점을 넘어섰어요. 설계를 실전에 맞추는 유연함이 필요하더라고요.
“줄이기”와 “늘리기”의 기준은 같아요. 고유한 가치를 만드는 단계인가? 맞으면 유지하거나 추가하고, 아니면 합치거나 빼면 돼요. 무조건 적은 게 좋은 것도, 많은 게 좋은 것도 아니에요.
디테일은 실사용이 결정해요. 질문 수, 파일 이름 규칙 같은 건 사소해 보이지만, 실제로 써보면 생산성에 직결돼요. 규칙은 만들고 나서 실사용 후에 확정하는 게 맞아요.
마무리
혹시 지금 AI 파이프라인이나 자동화 워크플로우를 설계하고 계신다면, 처음부터 “최적의 단계 수”를 찾으려고 하지 않아도 괜찮아요. 일단 역할을 나눠보고, 돌려보고, 실전이 알려주는 대로 조정하면 돼요. 설계가 틀렸다는 게 아니라, 설계는 출발점이지 도착점이 아니라는 거예요.
저도 6단계가 3단계가 되고, 다시 4단계가 될 줄은 몰랐거든요.