기업 블로그에 쓸 콘텐츠의 기획부터 생성까지 이어지는 파이프라인, 그 개발 과정에서의 시행착오와 현실적인 조언들, 그리고 아직 풀지 못한 한계들을 모두 공개했습니다. 시작부터 끝까지 한 시간이면 될 거라 생각했는데, 경험과 시행착오를 전부 꾹꾹 눌러 담다 보니 발표만 50분이었고, 구체적이고 다양한 질문도 계속 이어져 질의응답만 35분을 더 했습니다. 그만큼 밀도 높은 시간이었습니다.

후기에서 누군가는 “현업에서 겪은 시행착오와 그 과정에서 얻은 지식을 아낌없이 공유하는 대인배 세미나"라고 평하기도 했습니다. 다른 분들도 이렇게 표현해주셨습니다.

"본질에 다시 집중하게 된 계기."
"서비스 도입 사례로 시작했는데 업무의 본질까지 터치한 양질의 세미나."
“회사에서 어떻게 적용할지 고민이 많았는데, 방향이 잡혔어요”
“경험자가 풀어주는 콘텐츠 에이전트 구축 찐후기”

후기를 남겨주신 분 중 92%가 만족했던 그날의 이야기를 정리해, 자리에 함께하지 못하셨던 분들께도 전해드리려 합니다.

기업을 위한 블로그 에이전트 파이프라인

요즘IT는 지난 2026년 2월부터 기업 블로그용 콘텐츠를 기획하고 생성하는 에이전트를 만들어보는 실험을 시작했습니다. 4년 넘게 콘텐츠 플랫폼을 운영해온 콘텐츠 전문성과 요즘IT의 운영사인 위시켓의 기업 데이터, IT 매거진으로서 확보한 에이전트 관련 지식을 결합하면 ‘기업 블로그 에이전트’를 만들어볼 수 있겠다 싶었기 때문입니다. 변수가 많은 매거진의 콘텐츠보다는 정형화된 형식으로 만들 수 있는 기업 블로그 자동화가 더 쉽게 도전할 영역이라고 생각했고요. (물론 이는 잘못된 생각이었습니다)

이 파이프라인을 직접 만든 것은 요즘IT 팀원으로, 그로스파트 리드 장대청입니다. 그는 문예창작을 전공했고, 흔히들 말하는 ‘문과 직무’만 겪어왔죠. 그렇게 개발자가 아닌 도메인 전문가의 입장에서 에이전트를 만들어보는 것도 의미가 있을 것 같았습니다.

에이전트 파이프라인 데모

결론부터 말하면, 저희가 만든 건 담당자가 ‘조금만 고치면 쓸만한 초안’을 만드는 에이전트를 만들었습니다. 이 초안이 나오기 위해 필요한 건 진짜로 버튼 몇 개와 판단 몇 개뿐입니다. 실제로 요즘IT가 만든 파이프라인의 데모를 살짝 보여드리겠습니다. 아래 링크를 통해 보시면 더 이해가 쉽습니다.

파이프라인은 담당자가 “위시켓 블로그를 찾아올 만한 독자가 던질 법한 질문 하나”를 Slack 봇에게 던지는 것에서 출발합니다. 물론 단순해 보이는 이 입력 구조도 다양한 고민 끝에 나왔습니다. 콘텐츠의 주제, 방향, 목적, 그리고 독자가 누구인지를 담을 입력을 찾다 발견한 구성이죠.

위시켓은 IT 외주가 필요한 사람과 이를 개발할 수 있는 사람들을 연결하는 플랫폼인데요, 따라서 데모에서는 그러한 고객들을 고려해 “사내에 개발자가 없는 중소기업인데, 사업에 필요한 웹서비스를 외주로 만들려면 어디서부터 시작해야 하나요?”라는 질문을 던졌습니다.

약 15분 가량이 지나면 Slack 스레드에 응답과 함께 전략 보고서가 도착합니다.

URL로 어디서나 접근할 수 있는 이 전략 보고서에는 세 가지 탭으로 이뤄지는데, 각 탭에는 아래 내용이 나옵니다.

첫째, 리서치 결과: 입력한 질문에서 뽑아낸 키워드를 바탕으로 한 네이버와 구글 검색 결과, 검색량과 연관 키워드, 그리고 실제 ChatGPT·Claude·Gemini가 같은 질문에 어떻게 답했는지 정리한 GEO/SEO 전략
둘째, 컨텍스트: AI가 글을 쓸 때 참고할 회사·시장·고객 정보가 정리된 가드레일
셋째, 콘텐츠 기획안: 독자 페르소나와 그 독자가 단계별로 무엇을 궁금해하고 어떤 흐름으로 답을 찾아가는지가 정리된 유저 저니맵 형식의 기획안

이 전략 보고서 초안을 보고 마음에 들지 않는 부분이 있다면 Slack 스레드에서 그대로 수정 요청을 하고, 수정할 것이 없다면 승인을 합니다.

사람의 승인이 떨어져야만, 담당 에이전트가 글쓰기에 착수합니다. 그렇게 만들어진 결과물은 메인 콘텐츠 1편과 서브 콘텐츠 3편, 총 4편의 초안입니다.

글은 일반적인 기업 블로그와 똑같은 구조입니다. H2/H3 구조를 지키며, 본문에는 내용 이해를 도울 표, 체크리스트, 인용 박스가 들어 있습니다. 글의 흐름과 이어지는 CTA 배너, 사고 흐름을 돕는 FAQ까지 들어가 있습니다.

그뿐만이 아닙니다. 위시켓이 사용하는 CMS인 Webflow에 그대로 붙여 넣을 수 있도록 메타데이터와 HTML 임베드 코드, 그리고 GEO 대응을 위한 JSON-LD 구조화 데이터까지 함께 출력됩니다.

Slack에 질문 하나를 던진 것뿐인데, 한 시간여 만에 네 편의 초안과 발행에 필요한 거의 모든 자료가 준비된 것입니다.

에이전트 파이프라인 구조

이 결과물을 만든 파이프라인 구조는 다음과 같습니다.

이 파이프라인은 하나의 에이전트가 아닌, 리서처, 컨텍스트 빌더, 저니맵, 라이터, 어셈블러, 이렇게 총 5개의 에이전트로 구성되어 있습니다. (각각의 에이전트가 어떤 순서로 어떤 일을 하는지, 왜 이렇게 구성하게 되었는지, 만들면서 알게 된 것들은 무엇인지는 웨비나에서 소개합니다.)

꽤 괜찮은 파이프라인과 결과라고 생각하지만, 지금 시점에는 이 결과 자체가 중요한 건 아니라고 느꼈습니다. 더 중요한 건 그 결과물에 도달하기까지 8주간 일하며 겪어온 생생한 시행착오와 한계였습니다. 요즘 흔히 말하듯 “‘딸깍’하면 이렇게 나옵니다!”가 아니라 일상의 업무를 위한 에이전트를 만들 때 고려해야 할 것들, 특히 더 신경써야 할 것들, 만드는 과정에서 부딪히는 현실의 문제들을 더 중요하게 다루고자 했습니다.

가장 강조하고 싶은 건 하나입니다. AI한테 잘 시키려면, 내 일을 ‘분해’할 줄 알아야 한다는 것이었죠.

"에이전트를 만드는 작업이라는 게, 코드를 짜는 게 아니었습니다. 우리가 하는 일을 분해해서 글로 쓰는 것 그 자체였어요."

우리가 하는 일의 과정부터 그렇게 해서 얻고자 하는 결과까지, ‘일의 본질’을 낱낱이 분해할 수 있어야 에이전트의 성능이 더 올라간다는 사실, 하지만 그 분해가 그렇게 쉽지만은 않다는 것. 이 메시지가 더 중요한 부분이었습니다.

블로그 에이전트를 만들 때 가장 중요한 3가지

웨비나가 끝나고 후기 설문에서 "가장 도움이 된 부분"을 물었습니다. 응답을 모아보니 두 항목이 압도적이었습니다. 파이프라인 전체 구조, 그리고 시행착오와 해결 과정. 이 두 키워드가 거의 모든 응답에 등장했습니다. 이 키워드가 가장 잘 드러난 내용을 정리하니, 3가지 포인트가 나왔습니다. 실제로 모두 "어떻게 일을 분해할 것인가"에 대한 답의 일부이기도 합니다.

1. 에이전트 구조를 3번 갈아엎으며 배운 것

처음에는 에이전트 하나에 모든 일을 맡겼습니다. 리서치도, 기획도, 글쓰기도, 검수까지도. 다만, 지금의 에이전트는 역할이 복잡해질수록 멍청해집니다. 그래서 단순한 일을 시키기 위해 에이전트를 여러 개로 분리했죠. 첫 번째 전환이었고요.

에이전트를 늘렸는데도, 여전히 결과물은 아쉬웠습니다. 그럴 때마다 에이전트가 지켜야 할 규칙을 추가했습니다. "톤은 이렇게 잡아라", "구조는 이렇게 짜라". 규칙이 늘어날수록 에이전트는 그 규칙을 위반하지 않는 것에 모든 힘을 기울였습니다. 그러니 규칙을 위반하지는 않는 글이 나왔는데요, 좋은 글은 아니었습니다. 그렇게 위시켓 콘텐츠 마케터에게 결국 "이건 고쳐서도 못 쓸 것 같아요. 처음부터 제가 하는 게 나아요"라는 피드백을 받았죠. 여기까지 걸린 시간이 4주였습니다.

포기할까 하다가, 처음으로 돌아가 다시 물었습니다. "기업은 콘텐츠를 왜 만들까?" 답은 이랬습니다. “고객에게 우리가 전하고자 하는 바를 전달해서, 알게 하고, 고려하게 하고, 선택하게 하기 위해서.” 이 정의에서 출발해 일을 다시 분해했습니다. 분해 과정에서는 3가지 질문을 던졌습니다. 누구를 위해, 무엇을 줄 수 있는가, 어떻게 전달하는가. 이 질문의 끝에서 5개의 에이전트 구조가 자연스럽게 나왔습니다.

특히, 이 분해 과정에서 발견한 흥미로운 도구는 ‘유저 저니맵’입니다. 프로덕트 팀이 사용자 흐름을 설계할 때 쓰는 그 저니맵을 콘텐츠 기획에 그대로 끌어왔습니다. 기존에는 이 단계에서 마케팅 퍼널을 중심으로 적용했는데, 한계가 있다고 생각한 겁니다.

이제 사람들은 정보를 AI한테서 얻고는 합니다. 가장 먼저 나의 상황에 기반한 질문을 던져 검색의 선택지를 좁히죠. 그 선택지 안에 들지 못하면 후보에 들기조차 어렵습니다. 고객에게 우리가 전하고자 하는 바를 전하려면, 우선 그 답변 안에 들어야 합니다. 당연히 가장 먼저 고려해야 하는 것은 사용자의 상황과 그에 따른 질문 흐름입니다. 고객이 취하는 행동 단위로 정의된 마케팅 퍼널은 이러한 상황과 의도를 잡기 어려웠습니다. 그래서 더 세밀하게 사용자 흐름을 정의한 저니맵을 가져왔습니다. 그 덕분에 훨씬 자연스러운 맥락이 나왔죠.

2. 헤밍웨이가 원고를 100번 고쳤다는 말에서 시작된 3-pass 구조

기획을 받아 실제로 글을 쓰는 라이터 에이전트는 한 번에 글을 완성하지 않습니다. 세 번에 나눠 씁니다. 1pass에서는 구성을 잡아 초안을 쓰고, 2pass에서는 처음부터 다시 쓰되 데이터를 더 단단히 채우고, 3pass에서는 또 한 번 처음부터 다시 쓰되, 톤을 가다듬습니다. 핵심은 부분별로 수정하는 것이 아니라 앞선 글을 참조하되, 매번 새로 쓰며, 그때마다 다른 관점으로 쓰는 방식입니다.

이 구조는 다른 사람이 만든 에이전트 레퍼런스나 어떤 프로그램의 코드에서 온 것이 아닙니다. 에이전트를 만든 장대청 리드의 글쓰기 경험에서 출발한 구조입니다.

"헤밍웨이가 원고를 100번씩 고쳤다는 말이 있어요. 저도 이전에 글을 쓸 때는 매번 퇴고만 30번씩은 했거든요. 돌이켜 보니 그때도 통째로 잡고 앉아서 처음부터 다시 읽으며 썼어요. 특정 부분마다 훑어보며 쓰지 않고요. 대신 이번에는 어떤 관점으로 보자, 어떤 매체로 보자, 그렇게 컨셉만 바꿔가면서 했죠."

처음부터 이런 방식을 떠올린 건 아닙니다. 흔히 자료에서 찾아볼 수 있는 방식대로 리뷰 에이전트를 만들어 완성된 글에 점수를 매기게도 해봤습니다. 작동이 쉽지 않아 오류를 지적하는 에이전트를 만들고, 그렇게 지적받은 특정 부분만 골라 수정하게도 해봤습니다.

모두 만족스럽지 않았습니다. 결국 사람이 글을 다듬는 방식으로 돌아갔고, 기억을 살려 통째로 다시 쓰는 방식을 적용했습니다. 가장 나은 결과가 나오더군요. 이처럼 사람이 하는 작업을 정교하게 분해해서 옮겨놓는 게, 어떤 평가 시스템을 만들어 붙이는 것보다 효과가 좋다는 걸 두 달 사이 여러 번 확인했습니다.

3. 마크다운 파일로 검수받지 않는 이유

사실 에이전트가 만든 글은 마크다운(.md) 형식으로 출력됩니다. 처음에는 그 .md 파일을 그대로 동료에게 넘겨 피드백을 받았습니다. 그런데 묘한 일이 벌어졌습니다.

피드백을 요청받은 마케터가 그 파일을 그대로 클로드에 넣은 겁니다. ‘비판적으로 검토해달라’는 프롬프트와 함께요. 그렇게 나온 결과물의 95% 정도가 본인의 의견과 비슷하다고 피드백했습니다. 그 순간 이런 생각이 들었습니다. ‘이건 결국 내 클로드와 동료의 클로드가 의견을 주고 받는 게 아닌가?’

그래서 검수 환경을 다시 손봤습니다 .md 파일을 보여주는 대신, 위시켓 블로그에 실제로 발행되는 화면과 거의 똑같이 생긴 환경에서 글을 보게 만들었습니다. 표는 표대로, CTA 배너는 배너대로, 본문 폰트와 단락 간격까지 실제 발행 환경 그대로요.

사람은 글을 이해할 때 글자만 보지 않습니다. 단락의 크기, 줄 간격, 폰트, UI 구성에 따라 같은 내용도 다르게 인지합니다.

그리고 무엇보다, 결과가 실물로 존재할 때 사람은 책임감을 느낍니다. 그래서 마크다운 파일이 아니라 실제 발행 화면 위에서 글을 검토할 때 비로소, 사람이 자기 이름을 걸고 그 작업물을 관리한다는 감각이 생긴다고 가정했습니다. 이런 가정으로 파이프라인에서는 사람이 작업을 시작하는 ‘입구’와 ‘출구’, 마지막으로 사람이 개입할 지점을 신경 써서 디자인했습니다. 결국 나 혼자 쓸 파이프라인이 아니라 동료와 함께 쓰는 파이프라인이기 때문입니다.

왼쪽은 요즘IT 기업 블로그 에이전트가 만든 글의 출력 화면, 오른쪽은 위시켓 블로그 화면

블로그 에이전트로 끝까지 풀지 못한 것

이렇게 해서 ‘딸깍’하면 만족할 만한 글이 나오는 완벽한 파이프라인이 나왔다면 좋았겠지만, 그런 건 없었습니다. 여전히 풀지 못한 것이 많았고, 그건 혼자서는 풀 수 없는 일이었습니다. 한계는 두 가지였습니다.

도메인 지식이라는 천장

위시켓이 다루는 IT 아웃소싱 시장에는 단순한 정보로 환원되지 않는 미묘한 결이 있습니다.

예를 들어, 이런 외주 프로젝트에서 비용은 가장 많이 검색되는 주제이고, 의사결정의 큰 축이 됩니다. 그러나 실제 현장에서 오로지 비용만으로 의사결정을 내리면 프로젝트가 제대로 가기 어렵다고들 말합니다. 게다가 비용은 클레임이 나오는 가장 강력한 원인이 되기도 하죠. 그렇다고 사람들이 가장 궁금해 하는 정보를 무시할 수는 없습니다. 그러니 사례 기반으로 정보를 주면서도 균형은 갖추는 방향으로, 기업 블로그에서 매우 조심스럽게 다뤄야 합니다.

이런 미묘한 균형을 정확히 분해해서 알려주지 않으면 AI는 그대로 길을 잃습니다. 검색에서 가장 많이 나오는 정보인 ‘비용’을 그대로 기준으로 삼아 쓰기 마련이니까요. 두 달 동안 가이드 문서를 다듬어왔지만, 이 균형을 완전히 담아내지는 못했다고 느낍니다.

이에 실패한 가장 큰 이유는 에이전트를 만든 사람이 아웃소싱 시장을 모조리 이해하지 못하기 때문입니다. 위시켓 매니저들이 몇 만 건 넘는 프로젝트를 직접 연결하며 쌓은 지식은 그들의 머릿속에 있습니다. 그러니 이 분해 작업은 결국 한 사람의 머리에서 나올 수 있는 게 아닙니다. 마케팅, 영업, 운영, 고객지원처럼 여러 부서에 흩어져 있는 도메인 지식이 체계적으로 정리되어야 하는, 개인의 작업이 아니라 조직의 작업이었죠. 콘텐츠뿐만 아니라 모든 AX의 진짜 천장은 모델 성능이 아니라 이 ‘조직 차원의 도메인 지식 정리’에 있다는 것이 가장 크게 배운 것입니다.

AI 글쓰기 자체의 한계

이 한계를 얘기하기 전에, 발표 후반부에 참가자 분들에게 물은 질문을 그대로 다시 던져보겠습니다.

"아래 두 문단, 어떤 게 AI가 쓴 것 같나요?"

위의 글은 사람이 AI의 도움을 받아 쓴 것, 아래 글은 AI 에이전트가 쓴 날것 그대로입니다. 채팅창에는 “모두 AI다”, “1번이 AI다”, “2번이 AI다” 같은 답이 모두 비등하게 올라왔습니다.

저희는 콘텐츠를 오랫동안 만들어 온 사람들입니다. 그러니 “이 글이 이상하다” 같은 생각은 합니다. 다만 AI가 쓴 글에서 ‘정확히 무엇이 부족한가’를 손가락으로 짚어 말하기는 어렵습니다. 특히 한글은 영어와 흐름과 사용 구조가 꽤 다른 탓에, 해외에 알려진 정보를 그대로 쓰기도 어려웠습니다. 에이전트를 직접 구축한 장대청 리드도 AI가 생성한 글을 500개 정도 읽고 나서야 패턴을 더듬더듬 짚어볼 수 있었다고 합니다.

결국 내린 결론은 이런 영역은 사람이 마지막에 손을 대야 한다는 겁니다. 그리고 그 ‘마지막 작업’이 만들어내는 차이는 한동안 사라지지 않을 것 같습니다. 저희가 만든 파이프라인이 콘텐츠 마케터를 대체하는 도구가 아니라, 그분들이 더 본질적인 일에 집중할 수 있도록 돕는 도구라고 얘기하는 이유이기도 합니다.

블로그 에이전트 웨비나 다시보기

웨비나 발표와 Q&A를 녹화한 다시보기 영상, 발표에 사용한 슬라이드 PDF를 함께 다시 정리했습니다.

이 글에 다 풀어내지 못한 디테일이 많습니다. 정확히 무엇을 시도하고 무엇을 버렸는지, 5개의 에이전트의 동작은 어떠하며 각각 어떤 컨텍스트를 참고하는지, 도메인 지식을 분해하며 부딪힌 진짜 문제들까지.

이런 분께 권합니다

콘텐츠 AX 시리즈 1편과 2편을 읽고 "구체적으로 어떻게 시작해야 할지" 막연했던 분이라면, 이번 다시보기가 그 막연함을 꽤 좁혀줄 듯합니다. 팀에 콘텐츠 자동화를 제안해야 하는데 근거가 필요한 분, 비개발자가 만든 에이전트의 가능성과 한계를 한 번에 검증해보고 싶은 분들에게도 도움이 됩니다.

다만 이 영상이 처음부터 끝까지 따라할 수 있는 단계별 매뉴얼은 아닙니다. 이 한 시간 반짜리 웨비나는 두 달 사이 요즘IT가 부딪힌 질문들을 함께 따라가는 자리에 가깝습니다.

더 자세한 추천 대상과 구성, 가격은 아래 페이지에서 확인하실 수 있습니다.

장대청 리드가 발표를 시작하면서 한 말이 있습니다.

"AI의 가능성만 얘기하면 과대광고, 한계만 얘기하면 의미가 없다."

이번 웨비나는 AX라는 거대한 흐름 아래에서 살아남으려고 노력한 그 솔직한 좌표를 남기는 일이었습니다. 모든 질문에 대한 답을 드리지도 못했고, 후기에 적힌 어떤 분의 표현처럼 아직도 "공부를 더 하고 와야 알아들을" 부분도 있을 지 모릅니다.

하지만 한 가지는 분명합니다. 에이전트를 만드는 작업은 우리를 ‘분해’하는 작업이라는 겁니다. 그 분해 과정이 복잡하지 않다면 충분히 나누지 않았는지 고민해야 합니다. 그간 사람이 쌓아온 시간은 결코 작지 않으니까요. 그럼에도 이를 나눌 수만 있다면, 말 그대로 정말 뛰어난 생산성을 얻을 수 있다는 확신도 함께 생겼습니다.

앞으로도 요즘IT는 우리 스스로를 분해해 AI에게 일을 시키는 실험을 계속 해나갈 것입니다. 콘텐츠 기획부터 생성, 매거진과 SNS 운영까지 이어질 AX 이야기를 공유드리도록 하겠습니다. 기대해 주세요!

다시보기 + 발표 슬라이드 PDF 보기 →