AI 비서 시스템은 에이전트 하나를 켜놓는 것이 아니다. 기획, 검토, 승인, 실행, 알림이 순서대로 맞물린 파이프라인이다. Jurin을 9개월째 직접 운영하면서 이 구조가 어떻게 짜여 있는지 정리했다.
파이프라인의 전체 흐름은 무엇인가
Jurin의 블로그 콘텐츠 파이프라인은 다음 5단계로 구성된다.
- 기획 생성: 매주 월요일 오후 6시, 기획 에이전트가 자동으로 실행된다. 블로그 전략 문서를 읽고 해당 주차 테마에 맞춰 토픽 5개를 만든다. 결과물은 데이터베이스에
draft상태로 저장된다. - 사람 검토: 기획이 저장되면 텔레그램 알림이 도착한다. 토픽 목록을 보고 각 주제를 승인하거나 피드백을 남긴다. 피드백이 있으면 에이전트가 다음 실행 시 반영한다.
- 글 작성: 모든 토픽이 승인되면 콘텐츠 에이전트가 실행된다. 전략 문서와 블로그 설정을 읽고 토픽별로 글을 작성해 저장한다. 분량 기준은 본편 2,000자~3,000자, 라이트 1,200자~1,500자다.
- 사실 검증: 글이 저장되면 사실검증 에이전트가 자동으로 이어진다. 수치, 주장, 외부 인용이 검증 가능한지 확인한다.
- 예약 발행: 검증을 통과한 글은 예약 상태로 전환되고, 매일 오후 5시에서 9시 사이 발행 점검 에이전트가 당일 글을 실제로 올린다.
이 중 사람이 직접 개입하는 단계는 2번 하나뿐이다. 나머지 4단계는 자동으로 돌아간다.
각 에이전트는 어떻게 연결되는가
에이전트끼리 직접 신호를 주고받지 않는다. 데이터베이스의 상태 값이 중계 역할을 한다.
기획 에이전트가 draft 상태 기록을 남기면, 알림 에이전트가 이를 감지해 텔레그램 메시지를 보낸다. 토픽을 승인하면 상태가 plan_approved로 바뀐다. 콘텐츠 에이전트는 다음 실행 시 plan_approved 상태 기록만 처리한다. 글이 저장되면 content_ready로 전환되고, 사실검증 에이전트가 이 상태를 보고 작동한다.
이 구조의 장점은 한 에이전트가 실패해도 다른 에이전트에 영향을 주지 않는다는 점이다. 기획 에이전트가 오류를 내도 콘텐츠 에이전트는 기다릴 뿐 중단되지 않는다. 상태 값이 바뀌지 않았기 때문에, 다음 실행 때 다시 시도한다.
스케줄러는 어떻게 동작하는가
Jurin의 스케줄러는 크론(cron) 표현식으로 각 에이전트의 실행 시점을 정의한다. 기획 에이전트는 0 18 1(매주 월요일 18시), 발행 점검 에이전트는 0 17-21 1-5(평일 매시 정각, 17시~21시)로 설정돼 있다.
스케줄러는 에이전트를 깨우는 역할만 한다. 에이전트는 실행될 때마다 데이터베이스에서 자신이 처리해야 할 항목을 직접 조회한다. 따라서 스케줄러가 에이전트의 실행 결과를 알 필요가 없다.
수동 트리거도 가능하다. schedule.run_now를 호출하면 크론 시간과 무관하게 즉시 실행된다. 운영 중 긴급하게 특정 단계를 다시 돌려야 할 때 사용한다.
알림은 어떤 역할을 하는가
알림은 파이프라인과 사람을 연결하는 인터페이스다. Jurin은 두 가지 상황에서 알림을 보낸다.
첫째, 사람의 판단이 필요한 순간이다. 기획이 생성되면 승인 요청 알림이 온다. 외부 발송, 삭제, 예산 관련 행동을 에이전트가 수행하려 할 때도 알림을 보내고 승인을 기다린다.
둘째, 완료 보고다. 글 저장이 끝나면 "n개 글 저장 완료" 알림이 온다. 발행이 완료되면 발행 확인 알림이 온다. 이 알림들은 파이프라인이 어디까지 진행됐는지 추적할 수 있게 한다.
알림이 없으면 파이프라인이 어디에서 막혔는지 알기 어렵다. 로그를 직접 열어봐야 하는 상황이 되면 자동화의 이점이 반감된다.
이 구조에서 실제로 내가 하는 일은 무엇인가
직접 측정 결과, 블로그 운영에 드는 시간은 주당 약 15분~20분이다. 월요일에 토픽 목록을 보고 승인하거나 피드백을 남기는 것이 전부다. 나머지는 에이전트가 처리한다.
이 구조가 완성되기까지 약 3개월이 걸렸다. 처음에는 에이전트 하나씩 붙이고, 작동을 확인한 뒤 다음 단계를 연결하는 방식으로 쌓았다. 처음부터 전체 파이프라인을 한꺼번에 설계하려 했다면 더 오래 걸렸을 것이다.
파이프라인의 핵심은 각 단계를 독립적으로 만드는 것이다. 에이전트가 서로를 직접 호출하지 않고, 공유 데이터의 상태를 보고 스스로 판단하게 하면 한 단계의 실패가 전체를 멈추지 않는다.