블로그 글 한 편을 처음부터 끝까지 직접 쓰면 보통 두세 시간이 걸립니다. 주제 정하고, 목차 잡고, 자료 찾고, 문장을 다듬는 시간까지 합치면 그렇습니다. 그래서 많은 사람이 AI 블로그 글쓰기에 기대를 겁니다. 실제로 “OO에 대한 블로그 글 써줘”라고 한 줄만 넣으면 3분 만에 글 한 편이 나옵니다. 문제는 그 글을 그대로 올리면 안 된다는 데 있습니다. 이 글에서는 AI에게 초안을 맡기되 사람이 반드시 손봐야 하는 지점을 나눈 4단계 워크플로우를 정리합니다.
AI에게 통째로 맡기면 안 되는 이유
AI가 만든 글을 그대로 발행했을 때 생기는 문제는 크게 세 가지입니다. 하나씩 성격이 다릅니다.
- 사실이 틀립니다. 특히 버전 번호, 도구 가격, CLI 옵션 이름처럼 자주 바뀌는 정보가 그렇습니다. 그럴듯한 문장 안에 섞여 있어서 읽을 때는 잘 걸러지지 않습니다.
- 경험이 없습니다. “저는 이걸 세 번 실패하고 나서야 알았습니다” 같은 문장은 AI가 만들 수 없습니다. 만들어내면 그건 거짓말입니다. 그런데 독자가 끝까지 읽게 만드는 건 대체로 그런 문장입니다.
- 문장이 다 비슷합니다. 도입부마다 “오늘날 급변하는 환경에서”로 시작하고, 마무리마다 “여러분도 꼭 시도해 보세요”로 끝납니다. 몇 편만 쌓여도 사이트 전체가 균질해 보입니다.
구글 검색 품질 가이드라인은 콘텐츠의 생성 방식이 아니라 독자에게 도움이 되는가를 본다고 밝히고 있습니다. 즉 AI를 썼다는 사실 자체가 문제가 아니라, 사람이 검증하지 않은 채 나간 부정확하고 무색무취한 글이 문제입니다. 애드센스 심사 기준도 같은 방향입니다.
4단계로 나누는 이유
핵심은 AI에게 글 전체를 시키지 않고 단계별로 시키는 것입니다. 단계를 쪼개면 각 단계마다 사람이 개입할 지점이 생기고, 잘못된 방향으로 3천 자를 쓴 뒤에 되돌리는 일이 없어집니다.
| 단계 | 누가 하나 | 걸리는 시간 | 결과물 |
|---|---|---|---|
| 1. 목차 잡기 | AI 제안 → 사람 확정 | 10분 | 확정된 H2 목록 |
| 2. 섹션별 초안 | AI | 15분 | 섹션별 초벌 문장 |
| 3. 사람이 다듬기 | 사람 | 30~40분 | 경험·수치·검증이 들어간 본문 |
| 4. 기계 점검 | 스크립트 | 1분 | 분량·상투어·미처리 표시 리포트 |
합치면 한 시간 남짓입니다. 직접 쓸 때의 두세 시간에 비하면 절반 이하지만, AI에게 통으로 맡길 때의 3분보다는 훨씬 깁니다. 그 차이가 발행해도 되는 글과 안 되는 글을 가릅니다.
1단계 — 목차만 먼저 받는다
첫 프롬프트에서 본문을 못 쓰게 막는 게 중요합니다. 목차가 틀린 상태로 본문이 나오면 전부 버려야 하기 때문입니다. 그리고 사람이 채워야 할 자리를 [경험], [확인]처럼 표시로 남겨두게 시킵니다. 나중에 이 표시가 그대로 남아 있으면 아직 덜 다듬은 것입니다.
너는 IT 블로그 편집자다. 아래 조건으로 글의 "목차만" 만들어라. 본문은 쓰지 마라.
주제: 윈도우에서 파이썬 가상환경 설정하기
독자: 파이썬을 3개월 배운 직장인. 터미널은 익숙하지 않다.
검색 의도: "가상환경이 왜 필요한지"가 아니라 "지금 당장 어떻게 만드는지"
요구사항:
- H2 6개, 각 H2마다 다룰 내용을 한 줄로 요약
- 쉬운 순서대로 배치. 설치 없이 되는 방법을 먼저.
- 내가 직접 경험을 넣어야 할 자리를 [경험]으로 표시
- 수치나 사실 확인이 필요한 자리를 [확인]으로 표시
나온 목차는 그대로 쓰지 말고 반드시 손봅니다. 보통 순서가 어색하거나, 독자가 이미 아는 내용을 앞에 길게 배치합니다. 목차 단계에서 5분 쓰는 게 본문 단계에서 30분 아낍니다.
2단계 — 섹션 하나씩만 시킨다
목차가 확정되면 본문을 요청하는데, 이때도 한 번에 한 섹션씩만 받습니다. 통째로 요청하면 섹션 사이에 같은 말이 반복되고, 특정 섹션만 고치고 싶어도 전체를 다시 받아야 합니다.
아래 목차의 3번 섹션만 본문으로 써라. 다른 섹션은 건드리지 마라.
<목차>
(위에서 확정한 목차를 그대로 붙여넣기)
</목차>
조건:
- 800자 내외, 존댓말, 문장은 짧게
- 코드는 실제로 실행되는 것만. 주석으로 때우지 마라
- "혁신적인", "놀라운", "~에 불과합니다" 같은 표현 금지
- 확실하지 않은 버전 번호나 가격은 쓰지 말고 [확인]이라고만 남겨라
금지어 목록을 프롬프트에 직접 넣는 게 생각보다 효과가 큽니다. 상투어를 미리 막아두면 3단계에서 지울 문장이 눈에 띄게 줄어듭니다.
3단계 — 사람이 반드시 하는 일
여기가 이 워크플로우에서 가장 오래 걸리고, 가장 생략하고 싶어지는 단계입니다. 하지만 이 단계를 건너뛰면 앞의 두 단계를 할 이유도 없어집니다. 아래 항목은 AI가 대신할 수 없는 것들입니다.
- 표시된 자리를 채웁니다.
[경험]자리에 실제로 겪은 일을 씁니다. 겪은 적이 없으면 그 항목을 지웁니다. - 사실을 확인합니다.
[확인]자리의 버전·가격·옵션 이름을 공식 문서에서 직접 확인합니다. 확인이 안 되면 문장에서 뺍니다. - 코드를 실행해 봅니다. 복사해서 그대로 돌려봅니다. 안 돌아가는 코드가 하나 있으면 그 글 전체의 신뢰가 무너집니다.
- 도입부를 다시 씁니다. AI가 쓴 첫 문단은 대체로 일반론입니다. 독자가 겪는 구체적인 상황으로 바꿉니다.
- 문장을 자릅니다. AI 문장은 길고 수식이 많습니다. 한 문장에 한 가지만 남기고 나머지는 다음 문장으로 넘깁니다.
3단계를 다 끝냈는데도 “내가 쓴 글 같지 않다”는 느낌이 들면, 대체로 경험이 안 들어간 것입니다. 정보만 있고 사람이 없는 글은 어디서든 읽을 수 있어서 다시 찾아올 이유가 없습니다.
4단계 — 발행 전 기계 점검
사람 눈으로는 상투어가 몇 번 나왔는지, 표시가 남았는지 잘 안 보입니다. 이건 스크립트가 훨씬 잘합니다. 마크다운 초안 파일을 넣으면 분량·소제목 수·상투어·미처리 표시를 한 번에 알려주는 스크립트입니다.
# draft_check.py - 초안을 발행 전에 기계적으로 점검한다
import re
import sys
# AI 초안에서 반복적으로 튀어나오는 상투어
CLICHES = [
"혁신적", "획기적", "놀라운", "손쉽게", "다양한",
"~에 불과합니다", "여러분", "중요한 역할을", "핵심적인",
]
def check(path):
text = open(path, encoding="utf-8").read()
body = re.sub(r"```.*?```", "", text, flags=re.S) # 코드블록 제외
chars = len(re.sub(r"\s", "", body))
headings = len(re.findall(r"^##\s", text, flags=re.M))
blocks = len(re.findall(r"```", text)) // 2
print(f"본문 {chars}자 / 소제목 {headings}개 / 코드블록 {blocks}개")
if chars < 1500:
print(" [부족] 1,500자는 넘기세요")
if not 5 <= headings <= 8:
print(" [조정] 소제목은 5~8개가 적당합니다")
if blocks < 2:
print(" [부족] 실행되는 코드 예제가 2개는 필요합니다")
for word in CLICHES:
hits = body.count(word)
if hits:
print(f" [상투어] {word} x{hits}")
for line in body.split("\n"):
if len(line.strip()) > 120:
print(f" [긴문장] {line.strip()[:40]}...")
left = re.findall(r"\[(경험|확인)\]", text)
if left:
print(f" [미처리] 표시가 {len(left)}개 남았습니다")
if __name__ == "__main__":
check(sys.argv[1])
python draft_check.py 초안.md로 실행합니다. 상투어 목록은 자기 글에서 실제로 자주 나오는 표현으로 계속 채워 넣으면 점점 쓸모가 커집니다.
내가 얼마나 고쳤는지 재보기
워크플로우가 익숙해질수록 3단계를 대충 넘어가고 싶어집니다. 그걸 막는 가장 간단한 방법은 숫자로 보는 것입니다. 초안 파일과 최종본 파일을 비교해서 유사도를 계산합니다.
# how_much_i_edited.py - AI 초안을 내가 얼마나 고쳤는지 센다
import difflib
import sys
draft = open(sys.argv[1], encoding="utf-8").read()
final = open(sys.argv[2], encoding="utf-8").read()
ratio = difflib.SequenceMatcher(None, draft, final).ratio()
print(f"초안과 최종본 유사도: {ratio * 100:.1f}%")
if ratio > 0.8:
print("거의 안 고쳤습니다. 그대로 올리기엔 위험합니다.")
elif ratio > 0.5:
print("적당히 손봤습니다.")
else:
print("사실상 새로 썼습니다. 초안 단계를 더 짧게 가도 됩니다.")
# 실제로 바뀐 문장만 뽑아 보기
for line in difflib.unified_diff(
draft.split("\n"), final.split("\n"), lineterm="", n=0
):
if line.startswith(("+", "-")) and not line.startswith(("+++", "---")):
print(line[:100])

유사도가 80%를 넘는다면 사실상 AI 글을 그대로 올리는 것입니다. 경험상 50~60% 근처가 나올 때 글이 가장 읽을 만했습니다. 파이썬 기본 라이브러리만 쓰므로 따로 설치할 게 없습니다.
주의할 점
- 초안 파일을 지우지 마세요. 4단계 비교에 필요하고, 나중에 “AI가 뭘 잘못 짚었는지” 돌아볼 때도 자료가 됩니다.
- 회사 내부 정보를 프롬프트에 넣지 마세요. 무료 요금제는 입력 내용이 모델 개선에 쓰일 수 있습니다. 설정에서 학습 사용 여부를 먼저 확인하세요.
- 상투어 목록을 남의 것으로 쓰지 마세요. 사람마다 AI가 밀어 넣는 표현이 다릅니다. 자기 글 서너 편을 훑어보고 직접 만드는 게 정확합니다.
- 목차까지 AI에게 맡기고 끝내지 마세요. 목차는 글의 관점입니다. 관점이 AI 것이면 본문을 아무리 고쳐도 남의 글입니다.
마무리
전부 한 번에 도입할 필요는 없습니다. 오늘은 1단계만 해보세요. 다음 글을 쓸 때 본문 요청 대신 “목차만 만들어라”로 시작하고, 나온 목차를 직접 고쳐보는 것까지가 첫걸음입니다. 그것만으로도 글을 쓰다가 방향을 잃는 일이 줄어듭니다. 점검 스크립트는 초안이 서너 편 쌓인 뒤에 붙여도 늦지 않습니다.
다음 글에서는 개발하다 자주 만나는 VS Code의 Git 인증 오류를 원인별로 나눠 해결하는 방법을 다루겠습니다.