개인 프로젝트로서, 영상·기사·음성 콘텐츠를 16개 이상의 플랫폼에 배포하는 운영 기반을 거의 AI 에이전트 (AI Agent)에게 맡겨 운영하고 있습니다. 이 기사는 「실제로 어떻게 구성하고 있는가」를 AI 에이전트를 중심으로 한 전체 아키텍처로서 정리한 것입니다. 개별 스크립트에 대한 이야기가 아니라, 어떤 레이어 (Layer)를 어떻게 나누고, 에이전트에게 어디까지 맡기며, 인간이 어디에서 개입할 것인가라는 설계 판단이 주제입니다.

전제로, 콘텐츠의 장르나 상품, 운영 주체의 상세 내용은 여기서는 생략합니다. 기술적인 구조만을 일반화하여 작성합니다.

출발점: 「게시 스크립트를 한 권 쓰면 끝」은 파탄 난다

처음에는 소박하게 「콘텐츠 한 개를 만들어서 모든 매체에 흘려보내는 스크립트를 쓰면 된다」고 생각했습니다. 하지만 곧 파탄 났습니다. 매체마다 전제가 완전히 다르기 때문입니다.

• 공식 게시 API의 유무 및 기능 차이가 제각각임
• 자동 게시 자체가 BAN 리스크가 되는 매체가 있음
• 신규 계정을 첫날부터 풀 운영하면 동결됨
• 같은 소재라도 매체마다 최적의 포맷이 다름

이를 무시하고 기계적으로 양산한 결과, 몇 주 만에 여러 계정이 정지된 경험이 있습니다. 거기서부터 「매체 차이는 배포층 (Delivery Layer)에 가두고, 판단 그 자체는 AI 에이전트에게 맡긴다」는 구조로 정착되었습니다.

전체 아키텍처

현재의 구성을 5개의 레이어로 나누고 있습니다.

핵심은, 오케스트레이션 (Orchestration) 층의 에이전트가 중심에 있으며, 지식층을 읽고 쓰면서 생성층을 구동하고, 배포 결과가 피드백으로서 다시 판단으로 돌아오는 루프 구조입니다. 생성층·배포층은 「에이전트가 호출하는 도구」이지, 두뇌가 아닙니다.

AI 에이전트를 「실행자」가 아닌 「판단자」로 사용하기

이 아키텍처에서 가장 효과를 보고 있는 설계 판단이 이것입니다. 에이전트를 정해진 처리를 흘려보내기만 하는 실행자가 아니라, 「지금 해야 하는가·무엇을 만들 것인가」를 판단하는 판단자로 기동하는 것입니다.

구체적으로는, 스케줄러가 에이전트를 정기적으로 기동하지만, 전달하는 것은 「이것을 실행하라」는 명령이 아니라 「상황을 보고 가치 있는 일이 있는지 판단하여, 있다면 1건만 수행하라. 없다면 아무것도 하지 마라」는 프롬프트 (Prompt)입니다.

예를 들어 기술 기사 섹션에서는 「최근의 작업 로그를 보고, 다른 사람의 배움이 될 수 있는 범용적인 지견으로 일반화할 수 있는 사건이 있었을 때만 1건을 작성한다. 내용이 얕거나 재탕이 될 것 같다면 스킵한다」는 판단을 에이전트 스스로 하게 합니다. 「억지로 결과물을 만들지 않는」 판단을 인간 대신 하게 하는 것이 양산형 자동화와의 가장 큰 차이점입니다. 기계적으로 매일 1건씩 생성하게 하면 질이 떨어져 역효과가 나기 때문입니다.

이 「정기적으로 기동하여 판단하게 하는」 패턴은 콘텐츠 소재 보충, 게시 필요 여부, 재시도 필요 여부 등 곳곳에서 재사용하고 있습니다.

지식·기억층 (SSOT) 이 일관성을 담보한다

에이전트는 기동할 때마다 컨텍스트 (Context)가 리셋됩니다. 그대로 두면 매번 제로 베이스에서 판단하여 편차가 생기므로, 영속적인 지식층 (운영 Wiki + 에이전트용 메모리)을 단일 진실 공급원 (SSOT, Single Source of Truth)으로 두고, 기동 시 반드시 읽게 하고 있습니다.

여기에 넣고 있는 것:

• 매체별 제약·금지 사항 (규약 위반으로 동결된 실례 포함)
• 과거에 겪었던 버그와 대처 (같은 실수를 반복하지 않기 위해)
• 표기·읽기 정규화 규칙 (고유명사의 오독을 방지하는 사전 등)
• 무엇을 어느 매체에 언제 내보냈는지에 대한 이력 (중복 회피)

포인트는, 에이전트가 업무 결과나 새로운 배움을 이 층에 다시 쓰는 것입니다. 읽기뿐만 아니라 쓰기도 함으로써, 실패가 다음 이후의 규칙으로 축적됩니다. 인간이 모든 규칙을 미리 다 쓰는 것은 불가능하므로, 「실패할 때마다 에이전트 스스로 명문화한다」는 운영을 하고 있습니다.

배포층: 매체를 성질에 따라 분류하여 라우팅한다

매체 차이는 이 층에 가둡니다. 새로운 매체를 추가할 때, 먼저 다음 분기로 대응 방침을 결정합니다.

• 공식 API 있음·BAN 리스크 낮음 → 완전 자동. 단, 「게시는 가능해도 부차적인 기능만 API가 없는」 결함을 여러 번 겪었으므로, 기능 단위로 확인합니다.
• API가 없음 / 결함 → 완전 자동을 포기하고, 초안을 생성하여 메시지 앱에 알림을 보내고, 인간이 수십 초 만에 복사/붙여넣기로 게시하는 반자동 방식으로 전환합니다. 「기계가 만들고 사람이 누른다」는 분업입니다.
• 자동 게시가 그레이 존 / BAN 리스크 높음 → 수동. 반복 게시를 명시적으로 금지하고 있는 매체가 있으며, 그곳은 인간이 매번 말을 바꾸어 게시합니다.

「전부 자동화한다」는 것에 집착하지 않고, 리스크가 높은 마지막 원탭(one-tap)만 인간에게 남겨두는 것이 안정적인 운영의 비결이었습니다.

생성층: 파이프라인을 분해하여 각 단계를 교체 가능하게 만들기

생성층은 매체에 의존하지 않는 소재 공장입니다. 영상 계열을 예로 들면, 다음과 같이 분해되어 있습니다.

각 단계를 느슨한 결합 (loose coupling) 상태로 두면, TTS 엔진이나 이미지 생성 모델을 교체하더라도 다른 단계에 파급되지 않습니다. 사소해 보이지만 효과적인 것이 바로 「읽기·표기 정규화」 단계입니다. TTS는 고유명사나 연호를 아무렇지 않게 오독하기 때문에, 대본과 발화용 텍스트를 분리하여 요미가나(읽기 방식)를 사전으로 적용하고 있습니다 (오독 사례는 지식층의 규칙으로 축적합니다).

그리고 마지막 품질 게이트 (quality gate) 에서 길이, 금지 표현, 필수 요소 유무 등을 자동 체크한 후 전송층으로 넘깁니다.

가장 효과적이었던 것은 「조용한 실패」에 대한 대책

운영하면서 가장 무서웠던 것은, 에러는 발생하지 않는데 실제로는 작동하지 않는 패턴이었습니다.

• 소재가 고갈된 배치 (batch)가 exit code 0인 상태로 아무것도 생성하지 않고 계속 종료됨
• 특정 매체용 로직이 메타데이터 키 이름의 예상치 차이로 인해 특정 포맷만 조용히 계속 스킵됨
• 알림 버그로 인해 실패해도 누구에게도 알림이 가지 않음

모두 「로그를 능동적으로 확인하지 않으면 알아차릴 수 없는」 종류였으며, 며칠에서 몇 주간 방치된 적도 있습니다. 대책으로서, 「정상으로 보이는 상태」와 「정말로 정상인 상태」를 구분하는 체크층을 별도로 구축했습니다.

# NG: 반환값을 보지 않고 성공으로 처리해 버림
foreach ($poster in $posters) {
& $poster
...

규칙은 세 가지로 집약했습니다.

• 각 처리는 반드시 반환값 (성공/실패)을 확인하며, 무조건적인 성공 표시를 하지 않는다.
• 「재고」를 다루는 배치는 재고 소진 자체를 이상 상황으로 통지한다 (정상 종료로 뭉개지 않는다).
• 모든 실패와 경고는 인간이 매일 확인하는 알림 채널에 반드시 흘려보낸다.

AI 에이전트에게 판단을 맡길수록, 이 「정말로 작동하고 있는지를 별도의 레이어로 감시하는 것」의 중요성이 커집니다. 판단이 블랙박스화되는 만큼, 출력 여부와 결과는 기계적으로 검증할 필요가 있기 때문입니다.

요약

여러 매체에 대한 콘텐츠 운영을 자동화할 때, 본질은 「게시 로직을 작성하는 것」이 아니었습니다. 효과적이었던 설계 판단은 다음 네 가지입니다.

• AI 에이전트를 실행자가 아닌 판단자로 기동한다 (무리하게 만들지 않아도 되는 판단까지 맡기지 않는다)
• 영속적인 지식층 (SSOT, Single Source of Truth)을 두어, 에이전트가 읽고 쓰며 일관성과 학습을 담보한다
• 매체 차이는 전송층에 가두고, API 유무와 BAN 리스크에 따라 라우팅한다 (마지막 원탭만 인간에게 남긴다)
• 「에러는 나지 않지만 실제로는 작동하지 않는」 조용한 실패를 별도의 레이어에서 기계적으로 감시한다

에이전트에게 맡기는 범위를 넓힐수록, 주변의 「지식층」과 「감시층」을 두텁게 만들어 두는 것이 파탄 나지 않는 자동화의 조건이라고 느낍니다.

Discussion