AI로 콘텐츠를 만들어본 적 있다면, 이런 경험이 있을 겁니다. 클로드나 ChatGPT에 "블로그 글 써줘"라고 시키는 걸로 시작하는 겁니다. 바로 뭔가 나오긴 합니다. 그런데 톤을 고치고, 배경을 다시 설명하고, 몇 번을 더 주고받아야 쓸 만한 결과가 나옵니다. 매번 그렇습니다.
한 편을 만드는 건 이래저래 됩니다. 문제는 이걸 매주 반복해야 할 때입니다. 같은 브랜드 톤으로, 같은 품질 기준으로, 꾸준히. 채팅창에서 한 편씩 만드는 방식으로는 이 반복을 감당하기 어렵습니다.
저희 팀(요즘IT)은 이 문제를 정면으로 풀어보고 있습니다. 무엇을 쓸지 결정하고 목적에 맞는 글을 써내기까지의 과정을, AI 에이전트 여러 개가 알아서 돌아가는 파이프라인으로 만드는 실험입니다. 이 이야기를 이전에 한 번 공유했고, 그 글을 본 분들을 대상으로 수요조사를 진행했습니다. 91명이 응답해주셨는데, 숫자 몇 개가 눈에 띄었습니다.
➡️ 이전 글12분 49초 만에 한 달치 기획이 나왔다: 콘텐츠 AX 실험기보러가기
AI를 쓰고는 있습니다. 그런데 워크플로우까지 만들어본 분들은 거의 없었고 많은 분들께서 부분적으로 활용하고 있다고 하셨습니다.
이 데이터를 보면서, 또 주변 콘텐츠 담당자들의 반응을 살펴보면서 한 가지 생각이 들었습니다. 저희가 공유했던 콘텐츠 자동화 파이프라인이라는 것에 관해 각자 기대하는 것, 그리는 그림이 다를 수 있겠다는 것입니다.

이번 글에서는 블로그 콘텐츠를 자동으로 작성해주는 에이전트라는 것에 어떤 기대와 그림을 갖고 계시면 좋을지, 일종의 멘탈 모델을 제안하려 합니다. "AI한테 채팅으로 시키는 것"과 "에이전트 기반 워크플로우를 만드는 것"은 뭐가 다른지, 그리고 그 차이를 만드는 게 왜 .md 파일인지에 관한 이야기입니다. 이 정리를 거치면 세미나에서 다룰 파이프라인 구조와 에이전트의 작동 원리가 훨씬 선명하게 와닿을 겁니다.
수요조사에서 47%가 응답한 "부분적으로 활용하고 있다"의 실체는, 아마 이런 모습일 겁니다. 클로드나 ChatGPT를 열고, 몇 가지 맥락을 주고, "이 주제로 블로그 글 써줘"라고 합니다. 결과를 보고 톤을 조정하고, 몇 번 더 주고받은 뒤 괜찮은 부분을 복사해서 문서에 붙여넣습니다. 혹은 품질 좋은 글을 만드는 각자만의 프롬프트 노하우가 있으시겠죠.

나쁜 방식이 아닙니다. 초안을 잡거나 아이디어를 확장하는 데는 꽤 효과적이고, 대부분의 실무자가 여기서 상당한 시간을 절약하고 있을 겁니다.
하지만 이 방식에는 천장이 있습니다. 매번 사람이 대화를 시작하고, 결과를 판단하고, 다음 단계를 지시해야 합니다. "한 편을 잘 만드는 것"은 가능하지만, "매주 3편을, 일관된 품질로, 같은 브랜드 톤을 유지하면서 만들어내는 것"은 이 구조에서 어렵습니다. 사람이 빠지는 순간 멈추니까요.
그러면 자동화하면 되지 않느냐고 할 수 있습니다. 그런데 '자동화'라는 단어도 범위가 넓습니다. MAKE나 Zapier를 써보신 분들은 아시겠지만, 노코드·로코드 툴로 트리거와 액션을 연결해서 반복 업무를 자동으로 처리하는 것도 자동화입니다. 이때 LLM이 필요 없는 경우도 많습니다.
저희가 만들고 있는 것은 이것과 다릅니다. 에이전트는 단순히 트리거에 반응하는 게 아니라, 스스로 판단하고 실행합니다. LLM이 두뇌라면 에이전트는 그 두뇌에 손과 발까지 붙은 것입니다. 매번 사람이 맥락을 주입하거나 프롬프트를 바꾸는 게 아니라, 에이전트가 맥락과 프롬프트를 스스로 참조해서 결과물을 내놓도록 하는 시스템입니다. 이전 글에서는 조금 더 친숙한 '콘텐츠 자동화'라는 표현을 썼지만, 저희가 만들고 있는 것은 기업 블로그 에이전트라고 표현하는 것이 더 맞습니다. 세미나 제목이 '블로그 에이전트'라는 다소 낯설어 보이는 이름이 된 이유이기도 합니다.
그러면 채팅으로 시키는 것과 에이전트 기반 워크플로우는 구체적으로 뭐가 다를까요?

첫째로, 역할이 나뉘어 있습니다. 채팅에서는 하나의 AI에게 모든 걸 시킵니다. "이 키워드로 리서치해서 블로그 글 기획안 만들어줘." 리서치도, 판단도, 구조 설계도 하나의 대화창 안에서 이루어집니다.
에이전트 파이프라인에서는 다릅니다. 리서치하는 에이전트, 그 결과를 보고 판단하는 에이전트, 글의 구조를 설계하는 에이전트가 따로 있습니다. 각자 맡은 일만 합니다.

왜 이렇게 나눌까요. 하나에게 전부 시키면 리서치도 얕아지고 판단도 얕아지기 때문입니다. 사람도 마찬가지입니다. 콘텐츠 마케터가 키워드를 디깅하는 시간, 그 키워드를 평가하는 시간, 글의 구조를 잡는 시간은 각각 다른 종류의 집중을 요구합니다. 에이전트도 같습니다.
저희도 처음에는 하나의 에이전트에 여러 역할을 넣었다가, 결과가 얕아지는 문제를 겪었습니다. 어떻게 나눴고 뭐가 달라졌는지는 세미나에서 실제 사례로 보여드립니다.
둘째, 맥락이 미리 저장되어 있습니다. 채팅에서 콘텐츠를 만들 때, 매번 "우리 회사는 이런 서비스를 하고 있고, 톤은 이렇고, 지난달에 이런 글을 발행했으니 겹치지 않게" 설명해야 합니다. 빠뜨리면 아무 회사나 쓸 수 있는 범용적인 글이 나옵니다.
워크플로우에서는 이 맥락이 파일로 미리 세팅되어 있습니다. 에이전트는 매번 같은 맥락 위에서 일합니다. 저희 경험으로는, 같은 에이전트라도 위시켓의 브랜드 프로필과 기발행 글 260편의 DB를 넣어주느냐에 따라 결과물의 성격이 완전히 달라졌습니다. 맥락 없이 돌리면 "아무 기업 블로그에나 실릴 법한 글", 맥락을 입히면 "위시켓 블로그에서만 나올 수 있는 글"이 나오기 시작했습니다.

셋째, 사람이 개입하는 지점이 설계되어 있습니다. 채팅에서는 AI가 뭔가를 내놓을 때마다 사람이 판단해야 합니다. 에이전트 워크플로우에서는 사람이 개입해야 하는 지점이 미리 정해져 있습니다. 리서치도, 분류도, 기획안 작성도 자동으로 돌아가고, 특정 단계가 완성되면 그때 사람이 봅니다.
이건 단순히 편해지는 것 이상의 의미가 있습니다. 데이터를 긁어모으고 정리하는 건 AI가 더 빠르고, "이 키워드가 우리 비즈니스에 정말 필요한 주제인가"를 판단하는 건 사람이 더 잘합니다. 워크플로우는 이 역할 분담을 구조화한 것입니다. 구체적으로 어디서 사람이 개입하고, 왜 그렇게 설계했는지는 세미나에서 다룹니다.
그러면 이 구조는 어떻게 만드는 걸까요? 에이전트의 핵심은 코드가 아니라 업무 매뉴얼입니다. 그 매뉴얼이 실제로 어떤 형태이고, 어떤 도구로 에이전트에게 전달되는지를 이야기해보겠습니다.

에이전트가 명령에 따라 돌아간다고 했습니다. "어떤 역할을 맡고 있는지, 어떤 순서로 작업하는지, 어떤 기준으로 판단하는지." 이 명령들이 .md라는 파일 형식으로 정리됩니다.
.md는 마크다운(Markdown)의 확장자입니다. 프로그래밍 언어가 아닙니다. 자연어로 구조화해서 적어놓은 텍스트 파일입니다. 제목에 #을 붙이고, 목록에 -를 붙이는 정도의 간단한 서식 규칙이 있을 뿐입니다.
예를 들어 리서치 에이전트의 매뉴얼은 이런 식입니다.

이게 에이전트의 명세서입니다. 코드가 아닙니다. "이런 순서로 해라", "이 단계에서는 판단하지 마라" 같은 지시를 자연어로 적어둔 것입니다.
이런 .md 파일이 파이프라인 안에서 세 가지 역할을 합니다. 에이전트의 역할과 작업 순서를 정의하는 것도 .md 파일이고, 브랜드 톤이나 집필 스타일 같은 맥락을 담아두는 것도 .md 파일이고, 에이전트가 참조하는 가이드도 .md 파일입니다. 앞서 설명한 세 가지 차이, 즉 역할 분리, 맥락 저장, 검토 포인트를 실제로 구현하는 수단이 전부 이 .md 파일인 셈입니다.
그런데 .md 파일만으로는 에이전트가 돌아가지 않습니다. 이 매뉴얼을 읽고 실행하는 환경이 필요합니다. 저희는 클로드 코드를 사용했습니다. 일반 채팅과 결정적으로 다른 점은, AI가 파일을 직접 읽고 쓸 수 있다는 것입니다. 매뉴얼을 읽고, 매뉴얼대로 작업을 처리하고, 결과를 파일로 저장합니다. 채팅에서 매번 맥락을 입력해야 했던 한계가 여기서 해결됩니다.
그리고 이 매뉴얼을 처음부터 사람이 혼자 쓸 필요도 없습니다. "리서치 에이전트의 역할 명세를 만들어줘"라고 시키면, AI가 명세 초안을 작성합니다. 사람은 그 초안을 보고 "판단은 이 단계에서 하지 마", "출력 형식은 이렇게 바꿔줘" 같은 식으로 수정하면 됩니다.
결국 사람이 해야 하는 일은 두 가지입니다. "이 업무가 어떤 순서로, 어떤 기준으로 돌아가야 하는지"를 아는 것. 그리고 AI가 만든 초안을 보고 "이건 맞다, 이건 아니다"를 판단하는 것. 코딩 능력이 아니라, 자기 업무를 정확히 아는 것이 핵심입니다.
그런데 이 모든 걸 개발자가 아닌 콘텐츠 전문가가 실행했습니다. 콘텐츠를 매일 기획, 편집, 제작하는 사람이 직접 만들었는데, 그 과정에서 콘텐츠 마케팅에 필요한 도메인 지식을 실제 콘텐츠 마케터와 LLM의 도움을 더해 채워갔습니다.
그게 가능한 이유는 콘텐츠를 만드는 방식과 좋은 품질의 콘텐츠를 평가할 수 있는 눈, IT 미디어를 운영하면서 가질 수밖에 없었던 에이전트에 관한 약간의 관심과 지식, 그리고 LLM의 도움 덕분입니다.
에이전트를 만드는 방식에 정답은 없습니다. 내가 내 업무 전문성을 바탕으로 일을 어떻게 나누어 어떤 기준을 가지고 만들지를 판단하는 것이 가장 중요합니다.

이 글에서는 채팅과 에이전트 기반 워크플로우가 뭐가 다른지, 그리고 그 차이를 만드는 .md 파일이 어떤 것인지를 정리했습니다. 세미나에서는 여기서 한 발 더 들어갑니다.
저희가 설계한 6단계 파이프라인의 전체 구조, 각 단계에서 에이전트를 어떻게 나눴고 왜 그렇게 나눴는지, 사람이 개입하는 지점은 어디에 두었는지를 공유합니다. 기획 단계에서 에이전트를 쪼개고 재설계한 과정, 도메인 지식을 주입하면서 부딪힌 벽, 생성된 콘텐츠의 품질이 어디까지 왔고 무엇이 아직 부족한지. 또 최근에는 에이전트 구성을 바꿔 좀더 간단한 구성으로 시도하고 있는데, 그 이야기도 들려드립니다. '다 된다'가 아니라 실제로 해보니 가능한 것, 한계인 것들을 솔직하게 공유합니다.
이 블로그 에이전트 구축은 조직의 AX만큼이나 콘텐츠 담당자 한 명이 할 수 있는 것이 아니었습니다. 물론 혼자서 만들 수는 있지만, 만드는 과정에서뿐 아니라 만드는 데 필요한 데이터를 확보하는 데에는 개인만이 아닌 조직 차원의 노력이 필요할 수 있다는 것도 깨달았습니다. 이런 이야기를 솔직하게 공유합니다.
기업 블로그나 콘텐츠 마케팅을 담당하면서 AI 자동화를 검토 중인 분, "에이전트"라는 개념이 궁금한데 실제 사례를 먼저 보고 싶은 분, 직접 자동화 파이프라인을 만들어보고 싶은데 전체 그림이 안 잡히는 분이라면 도움이 될 겁니다.
특히 개발자가 아닌 콘텐츠 전문가가 만든 것이기 때문에 기업 블로그 업무를 에이전트화하는 것에 관한, 지금 시장엔 없는 가장 현실적인 이야기들이 담겨 있을 것입니다. 기업의 내부 데이터 소스를 블로그 글과 어떻게 연결시킬지, 채팅창(세션)마다 매번 달라지는 생성 품질을 어떻게 유지할지, 요즘 마케팅 씬에서 큰 화두인 GEO에 맞춤한 콘텐츠를 발행한다는 것의 현실적인 의미가 무엇인지, 이런 고민이 저희 작업 과정에 고스란히 녹아 있습니다.

결국 자동화의 출발점은 AI가 아니라, 내 업무입니다. 내가 하는 일이 어떤 순서로 돌아가는지, 어디서 판단이 필요한지, 그 판단에 뭘 참고하는지. 이걸 정리할 수 있으면, 에이전트를 만들 준비가 된 겁니다.
콘텐츠 담당자를 위한 기업 블로그 에이전트의 가능성과 한계
일시: 4월 17일(금) 저녁 7시
형식: 온라인 라이브(Zoom) · 발표 30분 + Q&A 20분
얼리버드: 11,900원 (4/16까지)➡️ [세미나 신청 링크]
수요조사에서 "체계적으로 활용하고 있다"고 답한 분은 91명 중 4명이었습니다. 이 글과 세미나가 그 비율을 바꾸는 데 도움이 되면 좋겠습니다.
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.