뉴스레터 봇 하나가 28개 AI 에이전트가 되기까지

처음엔 정말 별것 아니었습니다. 매주 아침 이커머스 뉴스를 모아 뉴스레터 한 통을 자동으로 써주면 좋겠다는, 딱 그 정도 생각으로 시작한 작은 스크립트였어요.

그게 2026년 3월 6일이었습니다. 첫 커밋 메시지는 "Initial commit: Datarize newsletter & blog automation agent" 한 줄이 전부였죠. 그로부터 약 석 달, 이 작은 봇은 1,015개의 커밋과 137번의 코드 리뷰를 거치며 28개의 AI 에이전트가 함께 일하는 시스템으로 자랐습니다. 뉴스 수집부터 블로그 작성, 다국어 번역, CMS 업로드, 이메일 발송, 고객 데이터 동기화, SEO 점검, 심지어 위키백과 문서 관리까지 — 각자 맡은 일이 다른 28개의 작은 일꾼들이 매일 돌아가고 있습니다.

이 글은 그 과정을 최대한 솔직하게 적은 기록입니다. 거창한 비전 선언문이 아니라, 사람 손이 거의 닿지 않는 시스템을 실제로 만들고 굴려보면서 우리가 무엇을 배웠는지에 대한 이야기예요. AI로 마케팅이나 콘텐츠 업무를 자동화해보려는 분이라면, 잘 만든 데모와 '매일 진짜로 돌아가는 시스템' 사이의 간극이 생각보다 크다는 걸 미리 느껴보시는 데 도움이 되면 좋겠습니다.

이 글에 나오는 숫자와 사건(시작일, 커밋 수, PR 수, 에이전트 구성)은 전부 저희 코드 저장소의 기록에서 그대로 가져온 값입니다. 외부 기술에 대한 설명에는 출처나 불확실한 부분을 따로 표시해 두었습니다.

왜 굳이 만들었나

이커머스 마케팅을 해보신 분이라면 알 거예요. 하루가 반복 작업으로 꽉 차 있다는 걸요. 아침마다 시장 동향을 확인하고, 그중 쓸 만한 걸 골라 글로 풀고, 한국어로 쓴 걸 일본어와 영어로 옮기고, CMS에 올리고, 검색엔진에 알리고, 소셜에 공유하고, 나중에 성과를 들여다봅니다. 하나하나는 어렵지 않아요. 그런데 이게 매일, 여러 언어로, 여러 채널에 걸쳐 반복되는 순간 사람의 하루를 통째로 잡아먹습니다.

저희가 세운 가설은 단순했습니다. 이 일들 대부분은 '판단'이 아니라 '작업'이라는 것. 무엇을 쓸지 정하고 결과물을 검토하는 판단은 사람이 하되, 그 사이의 지루한 손작업은 에이전트에게 넘길 수 있다면, 마케터는 정작 중요한 데 시간을 쓸 수 있겠다는 거였죠.

뉴스레터 한 통에서 시작했다

그래서 처음 만든 건 정말로 뉴스레터 한 통이었습니다. 매주 한국, 일본, 미국의 이커머스 트렌드를 모아 분석하고, 초안을 만들어 Notion에 올린 뒤 Slack으로 "검토해 주세요" 알림을 보내는 파이프라인. 그게 전부였어요.

지금 돌아보면 이때 내린 결정 하나가 의외로 중요했습니다. 바로 자동으로 만든 결과물을 곧장 세상에 내보내지 않고, 사람이 한 번 확인하는 단계를 처음부터 끼워 넣은 것입니다. AI가 초안을 쓰면 사람이 Slack에서 확인하고 내보낸다 — 이 '사람이 개입하는 지점(Human-in-the-loop)'은 이후 모든 에이전트가 물려받은 공통의 습관이 되었습니다. AI를 믿지 못해서가 아니라, 외부로 나가는 일에는 되돌릴 수 없는 게 많기 때문입니다.

기술 선택도 지금의 골격을 거의 그대로 갖추고 있었어요. 뉴스는 Tavily로 모으고, 글은 Claude로 쓰고, 썸네일은 Gemini로 배경을 만든 뒤 로고와 글자를 얹고, 발행은 Framer CMS에, 알림과 승인은 Slack으로, 스케줄은 GitHub Actions로 매일 아침 9시에. 작게 시작했지만, 한 번 자리 잡은 뼈대는 끝까지 갔습니다.

석 달 만에 28개가 된 이유

작은 뉴스레터 봇이 어떻게 28개로 불어났는지는 커밋 기록에 고스란히 남아 있습니다.

5월에 무슨 일이 벌어진 걸까요. 특별한 사건이 있었던 건 아닙니다. 그저 '에이전트를 하나 추가하고 운영하는 방식'이 한번 자리를 잡자, 새 에이전트를 만드는 비용이 뚝 떨어졌습니다. 같은 설정 로더, 같은 에러 처리 패턴, 같은 Slack 알림 규약을 재사용하니, 새 일꾼을 붙이는 게 점점 쉬워진 거죠.

그렇게 늘어난 에이전트들을 성격별로 묶으면 대략 이렇습니다. 트렌드를 모아 글과 백서를 만드는 콘텐츠 팀, 검색엔진과 소셜과 카페24와 이메일과 위키백과로 내보내는 배포 팀, 검색 순위를 점검하고 내부 링크와 키워드를 손보는 SEO 팀, HubSpot과 카카오 데이터를 맞추고 리드를 처리하는 CRM 팀, 그리고 GA4 성과를 모아 다음 전략에 반영하는 측정 팀.

솔직히 하나 덧붙이자면, 137개의 PR 중 상당수는 멋진 새 기능이 아니라 고치고(fix), 문서로 남기고(docs), 다듬는(chore) 작업이었습니다. 만드는 일보다 손보는 일이 더 많았어요. 이건 실패가 아니라 자동화 시스템의 정상적인 모습입니다. 매일 사람 없이 돌아가는 시스템은, 만든 만큼 계속 돌봐야 하니까요.

28개 에이전트는 어떻게 '같이' 일하나

여기서 자연스럽게 떠오르는 질문이 있죠. 에이전트가 28개나 되면 누가 이걸 다 지휘하나?

답은, 거대한 만능 프로그램 하나가 아니라 작은 일꾼들의 모임이라는 겁니다. 각자 독립적으로 실행되고, 각자의 주기로 돌고, 각자 맡은 책임만 집니다. 그리고 그 가운데에 이 일꾼들을 조율하는 지휘자 격 에이전트, Growth Orchestrator가 있습니다.

오케스트레이터가 하는 일은 사람 매니저와 비슷합니다. 일주일에 한 번, 먼저 지금 상황을 봅니다. GA4의 트래픽, 구글 서치 콘솔의 검색 순위 같은 지표를 읽어 목표(OKR) 대비 어디까지 왔는지 가늠하죠. 그다음 "이번 주에 뭘 하면 가장 도움이 될까"를 두고 후보 작업들을 점수로 매깁니다. 영향이 얼마나 클지, 효과가 날 확률이 얼마나 되는지, 실행이 얼마나 쉬운지를 곱해 우선순위를 내는 방식이에요. 그렇게 고른 상위 작업들을 적절한 워커에게 넘깁니다. 내부 링크는 링크 담당 에이전트에게, 메타 태그는 SEO 담당에게, 하는 식으로요.

중요한 건, 오케스트레이터가 일을 시키고 끝이 아니라는 점입니다. 워커가 한 일이 실제로 도움이 됐는지 끝까지 추적하고, 아니다 싶으면 되돌립니다. 사람이 했다면 깜빡했을 그 '사후 확인'을 시스템이 강제로 하게 만든 거죠. 그 감시가 구체적으로 어떻게 작동하는지가 다음 이야기입니다.

자율성에는 브레이크가 있어야 한다

에이전트가 알아서 일하게 두는 건 편하지만 위험합니다. 그래서 우리가 세운 원칙은 "자율적이라고 다 같은 권한을 주지는 않는다"였습니다. 모든 작업을 위험도에 따라 세 단계로 나눴어요.

가장 가벼운 일(이미지 대체텍스트, 메타 태그, 스키마 같은, 잘못돼도 쉽게 되돌릴 수 있는 것들)은 에이전트가 알아서 바로 반영합니다. 영향이 좀 더 큰 일(본문을 고치거나 여러 글에 내부 링크를 거는 것)은 곧장 반영하지 않고, 먼저 코드 리뷰(PR)로 올린 뒤 하루 동안 이상이 없는지 지켜보고 나서 적용합니다. 그리고 되돌릴 수 없는 일(이메일이나 소셜 발행, 콘텐츠 삭제처럼 한번 나가면 끝인 것들)은 무조건 사람이 Slack에서 버튼을 눌러줘야만 실행됩니다.

이 세 단계의 앞뒤를 두 명의 감시자가 지킵니다. 앞에는 Critic이 있어요. 어떤 작업이든 실행되기 전에 브랜드 톤에 맞는지, 사실이 아닌 걸 지어내진 않았는지, 투자 대비 효과가 있는지, 예전에 실패했던 패턴을 또 반복하는 건 아닌지를 따져봅니다. 통과하지 못하면 막거나, 위험도를 한 단계 올려 사람에게 넘깁니다. 뒤에는 Bandit이 있습니다. 작업이 반영된 뒤 성과를 추적하다가, 7일 안에 급락하면 즉시 차단하고, 21일에 걸쳐 통계적으로 판정해서 손해를 끼친 작업은 자동으로 원래대로 되돌립니다.

그리고 만약을 대비한 비상정지 장치, Kill Switch가 네 겹으로 걸려 있습니다. 되돌리는 일이 너무 잦아지거나, Critic이 모든 걸 다 통과시키는 이상한 상태(편향)가 감지되거나, 예산을 넘기거나, 한 주에 정한 작업 상한을 넘으면 시스템 전체가 스스로 멈춥니다. 물론 사람이 Slack에 /growth pause 한 줄을 쳐서 즉시 세울 수도 있고요.

이 모든 게 조용히 일어나면 불안하겠죠. 그래서 오케스트레이터는 매일 아침 Slack으로 보고합니다. 목표 진행률은 얼마인지, 어제 어떤 작업을 했는지, 비상정지 장치 상태는 괜찮은지, Critic이 남긴 회고는 무엇인지. 매주 한 번은 지난주 성과와 이번 주 계획을 정리해 보내고, 사람의 승인이 필요한 일이 생기면 그 자리에서 버튼이 달린 카드를 띄웁니다. Slack을 잘 안 보는 사람을 위해 같은 내용을 웹 대시보드에서도 볼 수 있게 해뒀어요. 요컨대, 에이전트는 알아서 일하되 자기가 무슨 일을 왜 했는지 끊임없이 사람에게 말을 겁니다.

운영하면서 비싸게 배운 것들

데모를 만드는 것과 매일 돌아가는 시스템을 운영하는 건 정말 다른 일이었습니다. 값을 톡톡히 치르고 배운 것 몇 가지를 나눌게요.

가장 무서운 건 '실패한 줄도 모르는 실패'였습니다. 한번은 외부 플랫폼에 글을 자동 등록하는데, 화면의 팝업이 일시적으로 안 떠서 6일 연속 조용히 실패한 적이 있어요. 어떤 API가 "접수했습니다(HTTP 202)"라고 답한 걸 발송 성공으로 착각한 적도 있고요. 검색엔진에 제출할 새 글이 없는 지극히 정상적인 상황을, 시스템이 '실패'로 분류해서 매주 거짓 경보를 울린 적도 있습니다. 여기서 배운 건 분명합니다. 자동화 시스템은 '할 일이 없어서 그냥 넘어간 것'과 '진짜로 실패한 것'을 정확히 구분해야 하고, 모르는 상태는 조용히 넘기지 말고 시끄럽게 알려야 한다는 것.

또 하나, 무언가를 고칠 때는 기존 걸 망가뜨리지 않는 방식을 기본으로 삼아야 했습니다. AI가 글 본문을 통째로 덮어쓰면, 사람이 공들여 넣어둔 입력 폼이나 디자인 요소가 한순간에 사라지는 사고가 날 수 있거든요. 그래서 관련 글 링크 같은 보조 정보는 본문을 건드리지 않는 별도 칸에 적게 했고, 본문을 손대는 에이전트는 작업 전에 원본을 백업해두고 위험한 패턴이 보이면 스스로 작업을 건너뛰도록 안전장치를 더했습니다.

그리고 같은 실수를 두 번 하지 않으려면 반드시 기록해야 했습니다. 이런 함정들은 그때 고치고 끝내는 게 아니라, '직관과 어긋나는 주의사항'이라는 문서에 차곡차곡 쌓았어요. 자동화 시스템에서 제일 비싼 건 코드가 아니라, '왜 이렇게 짰는지'에 대한 맥락이더라고요.

마지막으로 보안. AI가 만든 글이 HTML이나 메시지, 외부 링크로 흘러갈 때 생기는 위험(예를 들어 악성 스크립트 주입 같은)은 콘텐츠를 AI가 만든다고 사라지지 않습니다. 오히려 입력을 통제하기 어려운 만큼, 밖으로 나가는 출력을 더 꼼꼼히 검사하고 걸러야 했어요.

그래서 지금 뭐가 자동으로 돌아가나

지금 이 시스템은 사람의 개입을 최소화한 채 이런 일들을 합니다. 매일 아침 한국과 일본의 이커머스 트렌드를 모아 블로그 초안을 만들어 CMS에 올리고, GA4 데이터로 성과 리포트를 띄우고, SEO 상태를 점검하고, 새 글을 검색엔진에 알립니다. 평일 오후엔 발행된 글을 소셜용으로 바꿔 마케터의 승인을 기다리고, 매주 블로그 다이제스트를 1만 4천 명이 넘는 구독자에게 보내며, 경쟁사 콘텐츠를 분석하고 위키백과 문서를 부분적으로 손봅니다. 실시간으로는 들어오는 고객 문의에 응답하고 HubSpot, 카카오 데이터를 맞춥니다.

핵심은 사람을 대체한 게 아니라, 사람의 반복 작업을 대체했다는 점입니다. 전략을 세우고, 초안을 검토하고, 승인 버튼을 누르는 판단은 여전히 사람의 몫이에요. 에이전트는 그 사이에 있던 지루하고 손 많이 가는 노동을 가져갔을 뿐입니다.

솔직히 말하면, 한계도 분명합니다

이 시스템은 완성된 물건이 아니고, 분명한 한계가 있습니다. 도입을 고민하신다면 이 부분을 꼭 함께 봐주세요.

무엇보다 AI가 쓴 콘텐츠는 검수가 필수입니다. 사실이 아닌 걸 그럴듯하게 지어내는 일(할루시네이션)은 지금의 언어모델이 가진 본질적 특성이라, 자동으로 만든 초안을 사람 검토 없이 그대로 내보내는 건 위험합니다. 우리가 외부로 나가는 모든 발행에 사람 승인 단계를 둔 것도 그래서예요.

자동화가 운영 부담을 0으로 만들어주지도 않습니다. 만든 만큼 지켜보고 고쳐야 합니다. 137개의 PR 중 다수가 새 기능이 아니라 수정과 문서화였다는 사실이 그 증거고요. 게다가 우리가 기대고 있는 외부 플랫폼들(CMS, 검색엔진, 커머스 플랫폼)은 끊임없이 동작이 바뀌는데, 그 변화가 곧 우리 시스템의 장애가 됩니다. 재시도, 시간 제한, 백업 같은 방어적 설계가 선택이 아니라 필수인 이유죠.

마치며

작은 뉴스레터 봇 하나가 28개 에이전트 시스템으로 자라기까지, 정작 중요했던 건 화려한 모델이 아니라 반복할 수 있는 운영 원칙이었습니다. 실패를 한곳에 가두고, 사람이 마지막에 판단하게 하고, 함정을 기록하고, 출력을 통제한다 — 이 단순한 규칙들이 매일 돌아가는 시스템을 떠받쳤어요.

혹시 AI 에이전트로 마케팅이나 콘텐츠 업무를 자동화해보려 하신다면, 거대한 만능 에이전트 하나를 꿈꾸기보다 작고, 책임이 분명하고, 사람이 검토할 수 있는 에이전트부터 시작하시길 권합니다. 우리도 뉴스레터 한 통에서 시작했으니까요.

데이터라이즈는 이커머스 데이터를 기반으로 마케팅을 자동화하고 고도화하는 일을 합니다. 우리가 내부적으로 콘텐츠 파이프라인을 어떻게 자동화했는지 더 듣고 싶으시거나, 비슷한 고민을 함께 풀어보고 싶으시다면 언제든 편하게 이야기 나눠요.

출처에 대하여

• 프로젝트 시작일, 커밋과 PR 수, 월별 커밋 분포, 에이전트 구성: 데이터라이즈 마케팅 에이전트 저장소의 Git 기록과 내부 설계 문서에서 직접 확인한 값입니다(2026년 5월 30일 기준).

• 운영 중 겪은 사고 사례(팝업 실패, 본문 요소 소실, 정상 상황을 실패로 오분류한 일 등): 내부 사고 기록과 이를 고친 PR에서 가져왔습니다.

• AI 콘텐츠의 할루시네이션 한계: 대규모 언어모델에 대해 일반적으로 알려진 특성이며, 모델과 버전에 따라 정도는 다를 수 있습니다.