블로그 제작을 처음부터 끝까지 자동화하는 방법

저는 Ming입니다. vm0에서 제품 디자인과 더불어 콘텐츠 운영도 제가 맡은 일의 일부인데, 예상보다 훨씬 손이 많이 가는 일이었습니다. 워크플로 설계, 일러스트레이션, 이미지 제작, CMS 작업, 번역까지요. 다음은 제가 그 일을 어떻게 조금씩 해내고 있는지에 대한 이야기입니다.

콘텐츠는 제가 여기서 하는 일 중 하나입니다

vm0에서 제 하루는 대부분 제품 디자인과 우리의 Next.js 코드베이스 사이에 나뉩니다. 하지만 콘텐츠 운영도 제 몫이고, 막상 시작하고 보니 성과를 내는 블로그에는 정말 많은 것이 들어간다는 것을 깨달았습니다. 꾸준한 산출, 제대로 된 키워드 리서치, 브랜드와 일관된 비주얼, 괜찮은 메타 설명, 그리고 우리가 지원하는 네 개 언어로의 번역이 필요합니다.

이 일을 본격적으로 하기 시작했을 때, 게시물 하나에 거의 하루가 통째로 들었습니다. 알고 보니 글쓰기는 그중 작은 조각에 불과했습니다. 시간의 대부분은 글쓰기 주변의 제작 작업에 들어갔습니다. 적절한 키워드 찾기, 커버 아트 만들기, CMS에서 필드를 제대로 채우기, 로케일마다 그것을 다시 하기 같은 것들이었죠.

그래서 저는 그 파이프라인의 가능한 한 많은 부분을 Lucas에게로 점차 옮겼습니다. Lucas는 제가 제 일상 업무를 중심으로 Zero 위에서 만든 AI 마케팅 에이전트입니다. 그는 "마케팅 매니저"로 구성되어 있고, 그의 범위는 마케팅과 관련된 모든 것입니다. 블로그 제작이 오늘날 가장 잘 갖춰진 부분이고, 제가 시간이 지나며 스킬과 커넥터를 추가하면서 그는 계속 성장합니다.

지금 Lucas는 우리의 Strapi 헤드리스 CMS, 우리의 Ahrefs 계정, 팀 Slack, 웹 채팅, 브랜드 일관성 있는 일러스트레이션을 위한 내부 draw 스킬, 그리고 글쓰기 메커니즘을 위한 표준 copywriting 스킬에 접근할 수 있습니다.

아래에서는 이 AI 블로그 자동화가 실제로 어떻게 작동하는지 짚어 보겠습니다. Lucas가 어떻게 모호한 프롬프트를 받아 주제와 키워드로 분해하고, 게시물을 작성하고, 커버를 그리고, 텍스트를 자연스러운 번역에 통과시키고, 우리의 헤드리스 CMS에 네 개 로케일 초안을 안착시키는지 말이죠. 그런 다음 제가 여기까지 어떻게 왔는지, 그리고 무엇을 의도적으로 사람(여전히 대부분 저)에게 남겨 두는지 이야기하겠습니다.

제가 Lucas를 사용하는 방식: 웹 앱과 Slack

여러 채팅 말풍선이 하나의 AI 에이전트로 모이는 모습

저는 주로 vm0의 웹 채팅을 통해 Lucas와 작업합니다. 그것은 제가 그와 함께 개요 잡기, 초안 작성, 커버 반복 작업, 편집을 거치며 앉아 있는 딥워크 인터페이스입니다. 긴 스레드, 긴 컨텍스트, 채팅 채널에서는 어색했을 종류의 주고받기 말이죠.

Lucas는 공유 진입점으로서 우리의 팀 Slack에도 연결되어 있습니다. 저는 휴대폰에서 거기로 빠른 프롬프트를 떨어뜨리고, 팀의 나머지 사람들도 그를 호출할 수 있습니다. 블로그 순번을 맡은 누구든 같은 방식으로 게시물을 시작합니다. 두 인터페이스에 걸쳐 같은 에이전트, 같은 컨텍스트입니다.

일반적인 프롬프트는 어떤 모습인가

Lucas에게 보내는 제 프롬프트는 보통 짧습니다. 최대 세 문장이죠. 대표적인 예시는 다음과 같습니다.

Lucas, 효과적인 주간 회의를 운영하는 방법에 대한 튜토리얼을 써 줘. 회의 구조, 흔한 함정, 그리고 원격 팀의 몰입을 유지하는 방법을 다뤄 줘. 튜토리얼 스타일로, SEO 친화적으로, 마지막에 Zero를 사용하라는 CTA로 끝내 줘. 초안 링크만, 발행은 하지 마.

그게 브리프 전부입니다. 메시지 하나. 개요도, 키워드 목록도, 디자인 브리프도, 분량 목표도 없습니다. Lucas가 거기서부터 알아서 합니다.

이 형식에 도달하기까지 시간이 좀 걸렸습니다. 초기에는 에이전트가 모든 것을 일일이 적어 줘야 한다고 가정했기 때문에 훨씬 긴 브리프를 썼고, 그러다 대부분의 컨텍스트는 매 프롬프트가 아니라 그의 상시 지시(standing instructions)와 스킬에 속한다는 것을 깨달았습니다. 프롬프트는 방아쇠이고, 나머지 구성이 무게를 짊어집니다.

Lucas가 주제와 키워드를 분석하는 방식

여러 키워드 태그에서 선택된 하나의 키워드로 좁혀지는 깔때기

Lucas의 첫 행보는 모호한 프롬프트에서 구조를 추출하는 것입니다. 위와 같은 요청에 대해 그의 작업 노트는 이런 모습입니다.

주제: 효과적인 주간 회의 운영하기
형식: 튜토리얼 → 번호 매긴 단계, 구체적인 예시, "이렇게 하세요" 식 표현
암시된 청중: 팀 리드, 원격 매니저, 창업자
필수 섹션: 회의 구조, 흔한 함정, 원격 몰입
CTA: 독자를 Zero로 유도
제약: 초안 URL만, 발행하지 않음

그런 다음 그는 키워드를 고릅니다. 이것은 제가 시작했을 때 가장 직관이 없었던 콘텐츠 마케팅 부분이라, 제가 키워드 작업을 요청할 때마다 Lucas가 따를 루틴을 만들어 주었습니다. 그가 자율적으로 실행하는 스킬이 아니라, 그저 제가 그에게 맡기는 순서입니다.

Ahrefs에서 후보를 끌어옵니다. 그는 주제 문구에 대해 Ahrefs API를 호출하여, 월간 검색량, 키워드 난이도(KD), 상위 주제, SERP 의도가 담긴 롱테일 변형을 받아옵니다.
난이도로 필터링합니다. 저는 그에게 단호한 규칙을 주었습니다. KD < 30. vm0는 권위가 제한적인 비교적 새 도메인이라, 높은 KD 키워드를 좇는 것은 아직 우리에게 맞지 않습니다. 초기에는 롱테일이 이깁니다.
우리의 Strapi 색인과 교차 참조합니다. 그는 Strapi REST API를 통해 CMS에서 발행된 모든 슬러그를 끌어와, 우리가 이미 다루는 키워드는 제거합니다. 자기 잠식(cannibalization)은 없습니다.
의도를 제품 적합성과 맞춥니다. 키워드의 의도는 우리의 활용 사례 라이브러리와 양립해야 합니다. "효과적인 주간 회의 운영 방법" → 운영 / 팀 관리 → 적합. "도쿄 최고의 라멘" → 검색량이 아무리 많아도 부적합.
하나를 고릅니다. 필터링된 목록에서 그는 검색량이 가장 높은 옵션을 골라 게시물의 척추로 삼습니다. 예를 들어 remote weekly meeting best practices 처럼요.

온페이지 SEO에 대해서는 간단한 휴리스틱을 적용합니다. 타깃 키워드를 제목, 최소 하나의 H2, 그리고 첫 100단어 안에 넣습니다. 동의어와 관련 문구는 전체에 자연스럽게 엮습니다. 적합한 곳에는 관련 게시물 두세 개로 내부 링크를 답니다. 그 후에는 자연스럽게 쓰되 키워드 남발은 하지 않습니다.

게시물의 구조(여섯 또는 일곱 개의 H2, 각 단계 아래의 "Tip:" 콜아웃, 마지막의 CTA)는 제가 여러 게시물에 걸쳐 예시로 쌓아 올린 튜토리얼 템플릿에서 나옵니다.

커버가 그려지는 방식

커버는 제가 블로그 제작에서 가장 신경 쓰는 부분입니다. 한편으로는 제가 디자이너이기 때문이고, 한편으로는 독자가 한 글자도 읽기 전에 보는 것이기 때문입니다. 또한 게시물이 X나 LinkedIn에서 공유될 때의 Open Graph 이미지이기도 하고, 우리 블로그 색인을 스톡 사진의 벽이 아니라 하나의 간행물처럼 보이게 만드는 것이기도 합니다.

제가 원한 룩에는 스톡 사진이 선택지가 아니었고, 일러스트레이션을 하나하나 브리핑하는 것은 게시물당 제작 비용을 감당할 수 없게 만들었을 겁니다. 그래서 저는 draw라는 Zero 스킬을 만들었습니다. 다섯 가지 일을 하는 200줄짜리 Python 스크립트입니다.

두 가지 입력을 받습니다. 은유(무엇을 스케치할지)와 색상(친근한 이름 더하기 hex 기준값).
그것들을 고정된 프롬프트 템플릿에 넣어 나머지 구성을 고정합니다. 따뜻한 회색 배경 #eeeeee, 선택한 색상으로 캔버스 중앙에 놓인 수채화 얼룩, 그 위의 손으로 그린 잉크 스케치, 좌상단 (25, 25)의 vm0 로고.
구성된 프롬프트를 fal.ai의 nano-banana-pro 모델에 16:9로 보냅니다.
PNG를 내려받습니다. 거의 흰색에 가까운 픽셀을 정확히 #eeeeee로 다시 정규화하여 배경이 결코 어긋나지 않게 합니다. 1600×900으로 업스케일합니다. 투명한 vm0 로고를 그 위에 알파 합성합니다.
결과물을 vm0의 CDN에 업로드하고 URL을 출력합니다.

일반적인 호출은 다음과 같습니다.

python draw.py \
  --metaphor "a tilted hourglass with sand draining into a small open notebook, a sparkle near the rim" \
  --color-name "dusty rose" \
  --color-hex "#e08b96" \
  --upload

두 가지 입력만 있으면 나머지 브랜드는 일관되게 유지됩니다. 저는 보통 게시물의 주제에 어울리는 색상을 고릅니다. 더 따뜻한 튜토리얼 스타일 글에는 코랄이나 세이지, 좀 더 기술적인 글에는 파랑이나 라벤더, 발표에는 머스터드 옐로를 씁니다. 몇 가지 반복되는 색상이 블로그 색인을 서서히 알아볼 수 있는 팔레트로 바꿔 놓습니다.

제가 어렵게 깨달은 것은, 지렛대는 모델에 있지 않다는 점입니다. 지렛대는 템플릿에 있습니다. 모델이 구성, 팔레트, 레이아웃을 자유롭게 고르게 두면 커버마다 다른 브랜드처럼 보였습니다. 그것들을 고정하고 은유만 고르게 두면 게시물마다 룩이 일관되게 유지됩니다.

기사 안의 스폿 아트(이 게시물의 섹션 사이에 보이는 더 작은 그림들)를 위한 illustration이라는 자매 스킬도 있습니다. 같은 아이디어입니다. 고정된 스타일, 은유와 색상만 변합니다. 다만 16:9 커버 대신 정사각형 1024×1024 아트에 맞춰 조정되어 있습니다.

이미지 SEO에 대한 짧은 메모. 같은 커버 이미지가 게시물의 Open Graph 및 Twitter Card 자산으로 연결되어 있어, 소셜 공유가 그것을 깔끔하게 가져갑니다. Strapi는 업로드 시 미리 크기 조정된 네 가지 변형(thumbnail, small, medium, large)을 자동 생성하지만, 아직 기사 본문이 srcset을 통해 그것들을 로드하도록 연결하지는 못했습니다. 작은 프론트엔드 TODO입니다. 인라인 일러스트레이션은 Lucas가 임베드할 때 마크다운에 설명적인 대체 텍스트(alt text)가 작성됩니다. Strapi의 커버 자체 alternativeText는 제가 여전히 채워 넣고 싶은 부분입니다.

게시물이 작성되는 방식

왼쪽의 세로 개요가 오른쪽으로 펼쳐져 채워진 문단 블록과 팁 전구로 확장되는 모습

주제, 키워드, 커버가 고정되고 나면 초안 작성은 대체로 기계적입니다. Lucas는,

먼저 개요를 잡습니다. 여섯 또는 일곱 개의 H2, 각각 명확한 역할을 가집니다. 문제 제시, 단계별 지침, "Tip:" 콜아웃, 요약, CTA.
copywriting 스킬을 사용해 각 H2를 산문으로 확장합니다. 목소리(짧은 문장, 구체적인 예시, 통할 때는 2인칭, 가끔의 건조한 유머)는 스킬 자체가 아니라 제가 Lucas의 상시 지시에 담아 둔 규칙에서 나옵니다.
각 단계 아래에 실용적인 "Tip:" 콜아웃을 더합니다. 대부분의 독자가 훑어 읽기 때문에 튜토리얼에 유용하며, 콜아웃은 긴 콘텐츠를 헤쳐 나갈 경로를 줍니다.
게시물의 description 필드를 작성합니다. Strapi는 이를 80자로 제한하므로, 짧게 유지되고 사람이 쓴 것처럼 읽힙니다. 기사 부제이자 OG/Twitter 카드 설명으로 쓰입니다.
제품 이름을 명시하고 무료 워크스페이스로 링크하는 CTA로 마무리합니다.

첫 초안은 보통 프롬프트 후 2~3분이면 돌아옵니다. 저는 그것을 읽고, 목소리가 어긋난 곳에 톤 조정을 요청하며, Lucas는 자리를 잡을 때까지 반복합니다. 첫 초안은 그대로 내보낼 수 있는 경우가 드뭅니다. 보통 거의 다 와 있지만 살짝 어긋나 있고, 바로 그곳에 제 검토 시간의 대부분이 들어갑니다.

초안이 Strapi에 안착하는 방식

일시정지 아이콘이 위에 떠 있는 가운데, 포장된 초안 꾸러미가 CMS 우편함에 놓이는 모습

우리는 Strapi를 헤드리스 CMS로 사용합니다. articles 콘텐츠 타입에는 cover(미디어), author와 category(관계), locale(문자열), 그리고 본문이 들어가는 blocks 다이내믹 존이 있습니다.

Lucas의 CMS 동기화 흐름은 다음과 같습니다.

커버 PNG를 /api/upload에 POST합니다. 반환된 documentId를 저장합니다.
/api/articles?status=draft에 제목, 설명(80자 이하, Strapi가 강제함), 슬러그, 로케일, cover/author/category 관계를 숫자 ID로, 그리고 마크다운 본문이 담긴 하나의 shared.rich-text 블록과 함께 POST합니다.
결정적으로 중요한 점: publishedAt을 생략합니다. Strapi는 null을 초안 상태로 취급합니다.
vm0의 초안 패턴을 사용해 미리보기 URL을 반환합니다. https://www.vm0.ai/{locale}/blog/posts/{slug}?status=draft.

Strapi v5에 대한 주의 사항. 공개 REST API는 특정 콘텐츠 타입에서 publishedAt을 덮어쓸 수 있는데, 이는 API를 통해 만든 "초안"이 조용히 라이브로 넘어갈 수 있다는 뜻입니다. 해결책은 초안 쓰기 시 해당 필드를 제거하는 작은 DB 마이그레이션입니다.

슬러그 전략도 SEO에 중요합니다. 우리는 슬러그를 번역하는 대신, 네 개 로케일 전체에 걸쳐 하나의 정규(canonical) 슬러그를 사용합니다. /de/blog/posts/remote-weekly-meeting-best-practices의 독자는 /en의 독자와 같은 URL 구조를 보고, 우리의 백링크 프로필은 번역된 URL 전반으로 쪼개지지 않습니다. 그 로케일 관계로부터 hreflang 링크 태그를 내보내는 것은 작은 프론트엔드 TODO입니다. 아직 내보내지는 못하고 있습니다.

i18n 번역이 작동하는 방식

중앙 문서가 EN, DE, JA, ES로 표시된 네 개의 작은 사본으로 펼쳐지는 모습

vm0는 네 개 로케일로 출시됩니다. 영어, 독일어, 일본어, 스페인어입니다. 우리는 게시물을 Google 번역에 돌리지 않습니다. 값싼 경로는 목소리를 파괴하고, 올바른 경로는 관용구를 적응시킵니다.

Lucas는 먼저 EN 초안을 만들고, 반환된 documentId를 포착한 다음, 자연스럽게 번역된 페이로드와 함께 세 번의 후속 PUT /api/articles/{documentId}?locale=de(그리고 ?locale=ja, ?locale=es) 호출을 보냅니다. Strapi는 그것들을 같은 정규 문서의 로케일 변형으로 취급하므로, 네 버전이 어드민과 프론트엔드 로케일 전환기에서 연결된 채로 유지됩니다.

제가 그에게 준 번역 규칙은, 대부분 잘못된 출력에 부딪히고 바로잡으면서 나온 것입니다.

대상 언어에서 이미 영어 외래어인 기술 용어는 번역하지 않습니다. "API", "CMS", "agent", "prompt"는 JA와 DE에서 영어로 남습니다. 둘 다 번역하면 어색하게 느껴집니다.
관용구는 자연스럽게 적응시킵니다. "kills your Friday"를 독일어로 직역하면 횡설수설이 되고, 같은 은유의 현지 버전은 자연스럽게 통합니다.
CTA를 로케일별로 다시 조율합니다. 명령형은 DE에서 더 강압적으로 느껴지므로 톤을 낮추고, JA 버전은 보통 정중한 권유로 부드럽게 만듭니다.
제목을 길이에 맞게 다시 조율합니다. 독일어 제목은 영어 대응물보다 약 30% 길어지는 경향이 있습니다. 일본어 제목은 짧아지는 경향이 있습니다. Lucas는 로케일별로 60자 SERP 잘림 한계 아래로 제목을 유지합니다.

다국어 콘텐츠 발행은 예전에 가장 많은 시간을 잡아먹던 워크플로 부분이었습니다. 이제는 같은 에이전트 실행의 마지막 단계일 뿐입니다.

자동화되지 않는 것

짧지만 중요한 섹션입니다. 이 워크플로의 모든 것이 자동화되는 것은 아니며, 그것은 의도적입니다.

전략 수준의 주제 선정. Lucas는 주제 안에서 키워드를 고르지만, 주제 자체는 저에게서 나옵니다. 보통 제품 출시, 고객 대화, 또는 로드맵 변화에서요.
최종 편집 검토. 저는 모든 초안을 내보내기 전에 읽습니다. 특히 EN 버전을요. 톤, 기술적 주장의 정확성, 내부 제품 맥락에 대한 언급은 모두 사람의 눈이 필요합니다.
제가 유창하지 않은 언어에 대한 원어민 검토. 저는 독일어를 유창하게 읽지 못합니다. DE 초안은 발행 전 최종 검토를 위해 원어민 리뷰어에게 갑니다.
홍보. X에 게시하기, 구독자에게 보내기, 커뮤니티에 공유하기는 지금은 여전히 수동입니다.

요점은 저를 루프에서 빼는 것이 아닙니다. 저를 정말로 제가 필요하지 않은 루프의 부분들에서 빼는 것입니다.

제가 이 워크플로에 다다른 과정

저는 어느 주말에 앉아서 이것을 설계한 것이 아닙니다. 어떤 단계가 제 시간을 잡아먹는지 알아차리면서, 게시물 하나하나에 걸쳐 축적된 것입니다.

제가 알아차린 것은, 자동화할 가치가 있는 부분이 창의적인 부분이 아니라는 것이었습니다. 그것은 연결하는 부분들이었습니다. 키워드 끌어오기, 커버 렌더링, 업로드 호출, 로케일 펼치기, 미리보기 URL 형식 맞추기 말이죠. 정직하게 추적해 보니, 저는 실제 글쓰기보다 실무 처리에 더 많은 시간을 쓰고 있었습니다.

그래서 저는 그 실무 처리를 점차 에이전트로 옮겼습니다. 모델은 글을 쓰고, 에이전트는 이것저것 옮기는 일을 처리합니다. 무엇을 쓸지, 어떤 목소리여야 할지에 대한 결정은 여전히 제가 내리지만, 더 이상 조각들을 꿰매는 사람은 아닙니다.

제게 실무에서의 콘텐츠 자동화는 결국 "AI가 블로그를 쓴다"가 아니었습니다. 그것은 결국 "AI가 글쓰기 주변의 모든 것을 처리해 주어, 내가 실제로 글을 들여다볼 시간을 갖는다"가 되었습니다.

비슷한 것을 시도해 보고 싶다면

여러분이 비슷한 처지에 있다면, 원하는 것보다 많은 모자를 쓰고 있고 그중 하나가 콘텐츠라면, 이 대부분은 재현 가능합니다.

에이전트에게 지속적인 역할과 스킬을 부여할 수 있는 에이전트 플랫폼(우리는 Lucas가 사는 Zero를 사용합니다).
기존 도구로의 커넥터: 여러분의 CMS, 키워드 리서치 도구, 이미지 생성기, Slack.
여러분의 브랜드에 맞춘 작은 스킬 모음(우리의 경우 커버를 위한 draw와 톤을 위한 copywriting).
컨텍스트를 짊어지는 상시 지시, 그래서 프롬프트가 짧게 유지될 수 있도록.

무료 Zero 워크스페이스 시작하기 →

가입하기 전에 더 많은 에이전트 워크플로를 보고 싶다면, 우리의 활용 사례 라이브러리에 엔지니어링, 제품, 마케팅, 운영 전반에 걸쳐 바로 복사해 쓸 수 있는 자동화 19가지가 있습니다.

Lucas를 구체적으로 복제하고 싶다면, 에이전트를 만들고, 그에게 마케팅 매니저 역할을 주고, Strapi(또는 여러분의 CMS) + Ahrefs + 이미지 생성 도구를 연결하고, 여러분 것을 본떠 만든 draw 스킬과 여러분의 브랜드 목소리를 담은 copywriting 스킬을 추가하세요. 그는 여러분의 첫 프롬프트에서 나머지를 알아낼 것입니다.