블로그 자동화를 이야기할 때 가장 먼저 주목받는 단계는 대개 글 생성이다. 키워드를 모으고, 주제를 정하고, 흐름을 설계하는 과정도 중요하지만, 많은 사람들은 결국 “그래서 글은 자동으로 얼마나 잘 써지느냐”에서 자동화의 가치를 판단한다. 문제는 여기서 기대가 너무 커지기 쉽다는 점이다. 자동화 도구를 붙이면 사람이 쓰는 글 수준의 결과가 바로 나올 것처럼 느껴지지만, 실제로는 그렇게 단순하지 않다.
특히 OpenClaw 기반으로 블로그 자동화를 구성할 때는 처음부터 완성 글을 뽑아내겠다는 접근보다, 일정 수준 이상의 초안을 안정적으로 생산하는 흐름을 만드는 쪽이 훨씬 현실적이다. 이 차이를 이해하지 못하면 결과가 조금만 어색해도 “자동화는 별로다”라고 판단하게 되는데, 실제 문제는 자동화 자체보다 설계 방식에 있는 경우가 많다. 같은 모델을 써도 입력 구조와 프롬프트 설계, 저장 방식, 후처리 기준에 따라 결과 품질은 꽤 크게 달라진다.
이번 단계는 시리즈 안에서도 꽤 중요하다. 앞 단계에서 키워드를 수집하고, 주제를 문장 형태로 정리했다면 이제는 그 주제를 바탕으로 글의 뼈대를 만드는 차례다. 이때 만들어야 하는 것은 발행 직전의 완성 원고가 아니라, 사람이 검토하고 다듬을 수 있는 초안이다. 초안을 잘 만드는 자동화는 생산성을 올리지만, 초안 없이 완성본만 바로 뽑으려는 자동화는 오히려 품질 문제를 키우는 경우가 많다.
먼저 알아둘 점
글 초안 생성 자동화는 단순히 API 한 번 호출해서 긴 텍스트를 받는 작업이 아니다. 실제로는 입력 데이터 정리, 프롬프트 설계, 생성 결과 저장, 재사용 가능한 형식 관리까지 포함한 작은 파이프라인에 가깝다. 이 구조를 먼저 이해해야 왜 어떤 글은 자연스럽고, 어떤 글은 비슷비슷하게 나오는지 설명할 수 있다.
또 하나 중요한 점은, 초안 생성 단계의 목표를 분명히 잡아야 한다는 것이다. 예를 들어 정보형 블로그라면 핵심 개념, 사용 맥락, 흔한 실수, 주의점까지 들어간 문단형 초안을 만드는 것이 중요하지, 문장을 화려하게 꾸미는 것이 우선은 아니다. 반대로 후기형 글이라면 지나치게 정리된 문장보다 실제 사용감처럼 읽히는 흐름이 더 중요할 수 있다. 즉, 글 생성 자동화는 “얼마나 길게 쓰느냐”보다 “어떤 목적의 초안을 일관되게 만들 수 있느냐”가 더 중요하다.
초보자가 가장 자주 하는 실수는 프롬프트 하나만 잘 만들면 모든 문제가 해결될 것처럼 생각하는 것이다. 하지만 실제로는 프롬프트만큼 입력 주제의 품질도 중요하고, 저장 형식도 중요하며, 이후 사람이 손보기 쉬운 구조로 결과가 나오느냐도 중요하다. 자동화는 한 군데만 잘 만든다고 끝나지 않는다. 전체 연결이 매끄러워야 체감 품질이 올라간다.
글 초안 생성 자동화의 기본 흐름
OpenClaw 기준으로 보면 글 초안 생성 단계는 보통 아래 순서로 흘러간다.
1. 주제 데이터 불러오기
2. 주제 유형에 맞는 프롬프트 만들기
3. 모델에 요청 보내기
4. 초안 결과 저장하기
5. 이후 검토 단계로 넘길 수 있게 구조화하기
이 흐름이 중요한 이유는, 이후 단계에서 문제가 생겼을 때 원인을 빨리 분리할 수 있기 때문이다. 예를 들어 글이 너무 반복된다면 모델 문제일 수도 있지만, 실제로는 프롬프트 템플릿이 늘 같아서 그런 것일 수 있다. 반대로 문단 구조가 엉성하다면 저장 문제는 아닐 가능성이 높다. 단계를 분리해두면 어디를 고쳐야 할지 판단하기 쉬워진다.
1단계. 주제 데이터 불러오기
글 초안 생성은 이전 단계에서 정리한 주제를 바탕으로 시작한다. 여기서 중요한 건 주제가 너무 짧지 않아야 한다는 점이다. 단순 키워드 하나만 던지면 결과가 애매해질 가능성이 크다. 가능하면 주제는 이미 문장형으로 정리된 상태가 더 좋다. 예를 들어 “OpenClaw 설정”보다는 “OpenClaw 초기 설정 시 자주 막히는 부분 정리” 같은 형태가 초안 품질에 더 유리하다.
import json
def load_topics(path="topics.json"):
with open(path, "r", encoding="utf-8") as f:
return json.load(f)
이 코드는 단순하지만 실제 흐름에서 꼭 필요한 부분이다. 자동화는 결국 이전 단계 데이터를 다음 단계가 안정적으로 받는 구조여야 한다. 파일 형식이 제각각이거나, 어떤 글은 문자열이고 어떤 글은 딕셔너리면 이후 단계에서 예외 처리가 늘어나고 관리가 복잡해진다.
실제로 운영해보면 여기서부터 차이가 난다. 주제 데이터가 깨끗하게 정리돼 있으면 생성 단계가 단순해지고, 그렇지 않으면 프롬프트에서 주제를 보정하느라 불필요한 조건이 늘어난다. 이런 부분은 겉으로 잘 안 보이지만 자동화 안정성에는 큰 영향을 준다.
2단계. 프롬프트를 주제에 맞게 구성하기
많은 사람들이 글 생성 자동화에서 가장 먼저 건드리는 부분이 프롬프트다. 그만큼 중요하긴 하지만, 여기서도 욕심을 줄이는 게 오히려 결과를 좋게 만든다. 조건을 너무 많이 넣으면 글이 딱딱해지고, 반대로 조건이 너무 적으면 뜬금없는 방향으로 흘러갈 수 있다. 핵심은 글 유형에 맞는 최소한의 구조를 주는 것이다.
def create_prompt(topic):
return f"""
다음 주제를 바탕으로 블로그 글 초안을 작성해줘.
주제: {topic}
작성 조건:
- 한국어로 작성
- 자연스럽고 읽기 쉬운 문장
- 정보 중심 설명
- 장점만 쓰지 말고 주의할 점도 포함
- 문단형으로 작성
- 과장 표현은 피할 것
"""
이 정도 프롬프트는 시작용으로 꽤 무난하다. 중요한 건 너무 복잡하게 만들지 않는 것이다. 예를 들어 소제목 개수, 문장 길이, 문체, SEO 문구, 강조 문장, 금지 표현까지 한 번에 많이 넣으면 오히려 결과가 부자연스럽게 나오는 경우가 많다. 특히 자동화에서는 프롬프트가 길어질수록 매번 비슷한 패턴이 강화되기 쉽다.
또 실제로는 글 주제의 성격에 따라 프롬프트를 조금 나누는 편이 더 낫다. 사용법 안내형, 비교형, 문제 해결형, 개념 설명형은 구조가 다르기 때문이다. 모든 주제를 하나의 템플릿으로 처리하면 생산은 빨라도 결과가 획일적으로 느껴질 수 있다. 승인용 글을 염두에 둔다면 이 부분은 더 중요하다. 포맷 반복감이 심하면 글의 고유성이 약해 보일 수 있기 때문이다.
3단계. 모델에 요청 보내서 초안 생성하기
이제 실제로 초안을 생성한다. 여기서는 모델 호출 코드 자체보다, 결과를 어떤 단위로 받고 어떻게 저장할지를 함께 생각하는 것이 중요하다. 예를 들어 글 한 편씩 저장할지, 여러 편을 한 번에 생성할지에 따라 운영 방식이 달라진다. 초반에는 한 번에 많이 돌리기보다 한 편씩 생성하고 품질을 확인하는 쪽이 훨씬 안전하다.
from openai import OpenAI
client = OpenAI()
def generate_draft(prompt):
response = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[
{"role": "user", "content": prompt}
]
)
return response.choices[0].message.content
이 코드는 기본 구조로는 충분하다. 다만 실전에서는 예외 처리와 로그 기록이 함께 들어가는 편이 좋다. 요청이 실패했는지, 응답이 비어 있는지, 혹은 너무 짧게 생성됐는지 정도는 기록해두는 것이 이후 운영에 도움이 된다. 자동화는 한 번 잘 돌아간다고 끝이 아니고, 계속 반복할수록 어디에서 흔들리는지가 중요해지기 때문이다.
또 하나 자주 생기는 문제는 “초안은 생성되는데 다 비슷해 보이는 경우”다. 이건 모델 성능 문제라기보다 입력 주제와 프롬프트가 지나치게 유사해서 생기는 경우가 많다. 결국 자동화 품질은 모델 하나로 결정되지 않는다. 주제, 템플릿, 생성 주기, 검토 기준이 같이 움직여야 결과 차이가 난다.
4단계. 초안을 저장하고 관리하기
글 초안 자동화에서 의외로 자주 가볍게 보는 부분이 저장이다. 하지만 저장 구조가 엉성하면 나중에 어떤 초안이 어떤 주제에서 나왔는지 추적하기 어렵고, 수정한 버전과 원본을 구분하기도 힘들어진다. 자동화는 결과물을 많이 만들어내기 때문에, 저장 구조가 나쁘면 오히려 수작업보다 더 지저분해질 수 있다.
def save_draft(topic, content, output_dir="drafts"):
import os
os.makedirs(output_dir, exist_ok=True)
safe_name = topic.replace(" ", "_").replace("/", "_")
path = os.path.join(output_dir, f"{safe_name}.txt")
with open(path, "w", encoding="utf-8") as f:
f.write(content)
return path
이 정도만 해도 초안 관리가 꽤 편해진다. 실제 운영에서는 여기에 생성 날짜, 주제 유형, 사용 여부 같은 메타데이터를 함께 저장하는 경우도 많다. 그래야 이미 쓴 주제를 다시 생성하는 일을 줄일 수 있고, 비슷한 주제가 반복되는 패턴도 빨리 잡을 수 있다.
5단계. 한 번에 연결해서 실행하는 기본 흐름
각 단계가 나뉘어 있어도, 실제 사용 시에는 한 번에 실행할 수 있어야 자동화라고 부르기 쉽다. 아래처럼 간단히 연결해두면 주제를 읽고, 프롬프트를 만들고, 초안을 생성하고, 저장하는 흐름이 완성된다.
def run_draft_pipeline():
topics = load_topics()
for topic in topics:
prompt = create_prompt(topic)
draft = generate_draft(prompt)
saved_path = save_draft(topic, draft)
print(f"저장 완료: {saved_path}")
if __name__ == "__main__":
run_draft_pipeline()
이 코드는 구조 이해용으로도 좋고, 시작용 파이프라인으로도 무난하다. 물론 실전에서는 중복 생성 방지, 실패 시 재시도, 글 길이 확인 같은 장치가 추가되면 더 안정적이다. 하지만 처음부터 너무 많은 예외 처리를 넣는 것보다, 기본 흐름을 먼저 안정적으로 만들고 하나씩 확장하는 편이 훨씬 현실적이다.
직접 해보면 자주 막히는 부분
실제로 이 단계를 돌려보면 가장 먼저 느끼는 문제는 “초안이 생각보다 비슷하다”는 점이다. 특히 같은 분야의 글을 연속으로 생성하면 도입부 표현과 문단 구조가 반복되기 쉽다. 이건 자동화 단계에서 거의 반드시 한 번은 겪게 되는 문제다. 그래서 승인용 블로그를 목표로 한다면, 주제 유형을 섞고 프롬프트 톤을 조금씩 다르게 나누는 작업이 꽤 중요하다.
또 다른 흔한 문제는 “길이는 긴데 내용이 비어 보이는 초안”이다. 이것도 모델이 못 써서라기보다 프롬프트가 너무 추상적이거나, 주제가 지나치게 넓어서 생기는 경우가 많다. 예를 들어 “블로그 자동화란?” 같은 넓은 주제는 무난하지만 뻔한 결과가 나올 가능성이 높다. 반대로 “OpenClaw 블로그 자동화에서 초안 생성 단계가 중요한 이유”처럼 조금 더 좁혀주면 결과가 선명해진다.
그리고 초안을 곧바로 발행본처럼 취급하는 것도 위험하다. 자동 생성 텍스트는 겉으로 보면 자연스럽지만, 실제 읽어보면 문장 사이 연결이 어색하거나 같은 뜻을 반복하는 경우가 꽤 있다. 그래서 초안 생성 자동화는 생산성을 높이는 도구로 보는 것이 맞고, 품질 검토를 완전히 없애는 도구로 보면 실망하기 쉽다.
왜 완성 글이 아니라 초안 자동화가 더 현실적인가
이 부분은 승인용 글에서도 중요하다. 자동화 관련 글이 저가치처럼 보이는 이유 중 하나가 “그대로 복붙해서 대량 발행하는 구조”처럼 읽히기 쉬워서다. 그런데 실제로 품질을 유지하려면, 초안까지만 자동으로 만들고 사람이 중간에서 판단을 넣는 편이 더 안정적이다. 특히 도입부, 핵심 설명, 실제 판단 문장은 사람이 조금 손보는 것만으로도 글의 개성이 훨씬 살아난다.
초안 자동화의 장점은 분명하다. 빈 화면에서 시작할 필요가 없고, 글의 뼈대를 빠르게 확보할 수 있다. 하지만 자동화 결과를 그대로 최종본으로 쓰려 하면 같은 표현 반복, 지나치게 교과서적인 문장, 애매한 결론 같은 문제가 더 눈에 띈다. 그래서 이 단계의 목표는 “완벽한 글”이 아니라 “수정할 가치가 있는 초안”을 안정적으로 만드는 데 두는 것이 맞다.
이런 방식이 실제 운영에서 더 안정적이다
내 기준으로는 한 번에 많은 글을 무작정 생성하는 방식보다, 하루 단위로 주제 수를 제한해서 초안을 만들고 검토하는 흐름이 더 낫다. 이유는 간단하다. 자동화는 양이 늘수록 품질 관리가 어려워지기 때문이다. 처음에는 주제 3개 정도만 골라 초안을 만들고, 어떤 패턴이 반복되는지 확인한 뒤 프롬프트를 손보는 편이 훨씬 효율적이다.
또 초안 생성 프롬프트를 하나로만 두지 말고, 최소한 두세 가지 버전으로 나누는 것이 좋다. 예를 들어 개념 설명형은 배경과 오해하기 쉬운 부분을 강조하고, 사용법형은 준비 단계와 막히는 지점을 강조하는 식이다. 이렇게만 해도 결과물의 느낌이 꽤 달라진다. 승인용 글에서 반복감을 줄이려면 이런 작은 차이가 생각보다 중요하다.
아쉬운 점이나 주의할 점
글 초안 생성 자동화는 생산성 면에서는 확실히 도움이 되지만, 잘못 쓰면 글이 너무 비슷해지거나 고유성이 약해질 수 있다. 특히 같은 프롬프트, 같은 톤, 같은 소제목 구조를 계속 쓰면 독자 입장에서도 기계적인 느낌이 난다. 검색엔진 관점에서도 이런 반복성은 장기적으로 불리할 수 있다.
또 API 호출 비용과 생성 시간도 무시할 수 없다. 처음에는 재미있어서 많이 돌리게 되지만, 정작 다듬지 못한 초안만 쌓이면 오히려 관리 부담이 커진다. 그래서 초안 자동화는 “많이 만드는 기술”이 아니라 “쓸 만한 초안을 꾸준히 만드는 기술”로 보는 편이 더 맞다.
정리
OpenClaw 블로그 자동화 4단계에서 중요한 것은 글을 자동으로 완성하는 것이 아니라, 수정할 가치가 있는 초안을 안정적으로 생성하는 흐름을 만드는 것이다. 주제를 불러오고, 프롬프트를 설계하고, 모델에 요청을 보내고, 결과를 저장하는 구조를 분리해두면 이후 품질 보정 단계로도 자연스럽게 이어진다.
이 단계는 자동화 전체에서 가장 눈에 띄는 구간이지만, 동시에 가장 오해받기 쉬운 구간이기도 하다. 완전 자동을 목표로 하면 실망하기 쉽고, 초안 자동화를 목표로 하면 오히려 결과가 훨씬 현실적이고 안정적이다. 결국 잘 되는 자동화는 멋진 한 번의 생성보다, 매번 다듬기 쉬운 초안을 일정하게 만드는 구조에서 나온다.