AI에게 글쓰기를 맡기면 블로그가 자동화될까?

2편 — 글 한 편은 어떻게 웹페이지가 되는가 — 블로그의 구조를 만들다에서는 글을 담는 규칙을 정했다. 제목과 날짜, 본문, 사진의 위치와 공개 상태가 구분되면 AI에게도 명확한 일을 맡길 수 있다는 이야기로 끝났다.

그러면 다음 단계는 간단해 보인다.

AI에게 “블로그 글 하나 써줘”라고 하면 자동화가 끝나는 것 아닐까?

본문이 나오는 순간만 보면 그럴듯하다. 하지만 이 시리즈를 준비하면서 다룬 것은 본문만이 아니었다. 기존 글을 읽고, 실제 프로젝트와 설명이 맞는지 확인하고, 사진과 표를 넣고, 글 파일을 웹페이지로 바꾼 뒤 작은 화면에서도 확인해야 했다.

AI에게 무엇을 쓸지, 어떤 자료를 믿을지, 무엇이 실제 경험인지, 어떤 주장을 빼야 하는지, 언제 게시해도 되는지까지 모두 결정하게 두면 글의 주인이 흐려진다.

AI가 글을 쓸 수 있다는 것과, AI가 블로그를 운영할 수 있다는 것은 같은 말이 아니었다.

이번에는 ‘블로그 자동화 만들기’의 세 번째 기록으로, 글 한 편을 만드는 일을 나눠 보고 AI에게 어디까지 맡길지 살펴보려 한다.

이 그림은 작업을 나누기 위한 흐름도다. 모든 글에서 열 단계를 한 번씩만 거친다는 뜻은 아니다. 이 시리즈의 자료 조사는 외부 기사를 모으기보다 기존 글, 프로젝트 파일과 앞선 검증 결과를 읽는 데서 시작했다.

AI가 잘하는 일부터 나눠봤다

먼저 맡길 수 있었던 것은 이미 정한 내용을 정리하는 일이었다.

1편과 2편에는 제목, 설명, 이미지 경로와 공개 상태를 적는 규칙이 있다. 사진은 글 이름과 같은 폴더에 저장하고, 본문에는 정해진 이미지 표시 요소를 사용한다. 이런 기준을 다시 설명할 필요가 줄어들면 작업 지시도 구체적이 된다.

이번 글에서도 주제와 핵심 질문, 꼭 넣을 내용은 사람이 먼저 정했다. AI는 기존 글과 파일을 읽고 그 기준에 맞춰 초안을 구성하며, 반복되는 파일 형식을 적용하는 일을 맡는다.

• 내용 정리: 앞선 글과 프로젝트 자료에서 이번 주제에 필요한 내용을 추린다.
• 구성 잡기: 도입, 역할 구분, 주의할 점과 다음 글의 연결을 순서대로 놓는다.
• 문장 다듬기: 긴 설명을 나누고, 전문용어 앞에 쉬운 설명을 붙인다.
• 표와 도표 초안: 역할 차이를 표로 묶고, 순서가 중요한 부분은 흐름도로 옮긴다.
• MDX 형식 적용: 제목 정보와 이미지 경로, 설명, 크기를 기존 규칙에 맞춰 적는다.
• 검증 보조: 검사 명령을 실행하고 결과를 정리하며, 화면에서 빠진 이미지나 가로 넘침을 확인한다.

여기서 ‘잘한다’는 말은 AI가 언제나 맞다는 뜻이 아니다. 입력과 규칙이 분명하고, 결과를 확인할 수 있는 일부터 맡길 만했다는 뜻에 가깝다. 같은 틀을 반복해서 채우는 일과 글의 방향을 결정하는 일은 다르게 봐야 했다.

자동 검사도 AI의 판단과는 구분해야 한다. 검사 프로그램이 이미지 파일의 존재를 확인할 수는 있지만, 그 사진이 글의 주장을 제대로 뒷받침하는지까지 알아서 판단하는 것은 아니다.

사람이 남아야 하는 일

반대로 사람에게 남겨야 할 일은 생각보다 앞쪽에 있었다. 마지막에 오탈자만 확인하면 되는 구조가 아니었다.

이 시리즈의 시작은 ‘왜 직접 블로그를 만들려 하는가’였다. 그 이유와 실제 경험은 사람이 제공해야 한다. AI가 그럴듯한 이유를 만들어 주더라도, 내가 했던 판단이 아니면 내 기록이라고 할 수 없다.

무엇을 기록할지 정하는 일, 여러 작업 중 중요한 맥락을 선택하는 일, 글이 원래 방향과 맞는지 판단하는 일도 그렇다. 파일과 검증 결과는 확인할 근거가 되지만, 어떤 내용을 공개할지는 별도의 결정이다.

AI는 초안을 만들 수 있지만, 무엇이 ‘내 기록’인지 결정할 수는 없었다.

그래서 역할을 다음처럼 나눠 보았다. 이 표는 성능 점수나 사람과 AI의 작업 비율이 아니다. 현재 시리즈를 준비할 때의 책임과 보조 역할을 보여 준다.

실제 작업 화면에서도 이 경계를 확인할 수 있다. 아래는 이번 3편 준비 중 AI가 기존 구조를 확인하고 작업 범위를 설명하는 화면의 일부다. 계정과 다른 프로젝트가 보이는 주변 영역은 잘라 냈다. 초안과 공개 준비 상태, 배포를 구분해야 한다는 설명이 보인다.

이 화면이 글 전체의 정확성을 증명하는 것은 아니다. 다만 ‘글을 써 달라’는 요청만 남기는 대신, 기존 규칙과 검증 범위, 공개 경계를 함께 다루는 작업이라는 점을 보여 준다.

자동화하면 안 되는 것도 있었다

초안이 매끄럽게 읽히면 확인을 끝낸 글처럼 느껴질 수 있다. 하지만 문장이 자연스럽다는 것과 내용에 근거가 있다는 것은 다른 문제다.

이 시리즈에서는 실제 프로젝트가 기준이다. 예를 들어 N-Layer를 Next.js로 만들었다고 적으면 설명은 그럴듯할 수 있어도 현재 파일 구조와 맞지 않는다. 2편에서 확인한 실제 구현은 기존 HTML·CSS 사이트에 Node.js 기반 MDX 빌드를 붙인 구조다.

자동화 효과도 마찬가지다. ‘작성 시간이 절반으로 줄었다’고 쓰려면 전후 시간을 실제로 측정해야 한다. 이번 작업에서는 그런 데이터를 수집하지 않았다. 그래서 역할과 흐름을 설명할 뿐, 절감 수치나 성과를 만들어 넣지 않는다.

자동화에서 제외할 일도 적어 두었다.

• 확인하지 않은 사실을 자동으로 게시하는 일
• 겪지 않은 실패나 성공을 실제 경험처럼 만드는 일
• 측정하지 않은 수치를 성과로 표현하는 일
• 외부 자료를 원문과 출처 확인 없이 인용하는 일
• 계정 정보, 비밀값이나 공개하지 않을 화면을 포함하는 일
• 검토 중인 draft의 공개 상태를 임의로 바꾸는 일
• 검수와 별도 게시 결정 없이 운영 사이트에 배포하는 일

처음 떠올릴 수 있는 생각과 지금 준비하는 방식을 비교하면 차이가 더 분명해진다. 왼쪽은 검토 없이 올려도 된다는 초기 생각을 단순화한 그림이며, 실제로 그런 방식으로 게시했다는 기록은 아니다. 오른쪽은 이번 시리즈에서 사용하는 검토 단계를 포함한다.

지금은 AI가 스스로 시작해 끝까지 운영하는 시스템이 아니다. 사람이 요청하고, AI가 파일과 자료를 다루며, 준비된 검사 프로그램과 로컬 화면으로 결과를 확인하는 흐름이다. 확인 중 문제가 나오면 앞 단계로 돌아가 고쳐야 한다.

자동화의 핵심은 글쓰기가 아니었다

작업을 나누고 나니 ‘AI가 글을 얼마나 잘 쓰는가’만으로는 자동화를 설명하기 어려웠다.

같은 이미지 형식을 다시 적고, 제목 정보를 같은 순서로 넣고, 본문에 적힌 경로를 파일과 맞추는 일은 매번 새로 고민할 필요가 적다. 기존 구조를 따라 문서를 바꾸고, 표를 정리하고, 검사 결과를 묶는 일도 그렇다.

AI는 초안 생성뿐 아니라 이런 정리와 변환을 돕는다. 규칙이 같은 부분을 반복할 때 사람이 놓칠 수 있는 항목을 확인하는 보조 역할도 맡는다. 다만 검사 결과를 해석할 때도 무엇을 확인했고 무엇을 확인하지 못했는지 남겨야 한다.

AI가 글을 대신 쓰는 것이 자동화의 핵심이 아니었다. 사람이 반복할 필요가 없는 판단과 작업을 줄이는 것이 더 중요했다.

여기서 줄이려는 판단은 이미지 경로나 파일 형식처럼 이미 정한 규칙을 매번 다시 적용하는 일이다. 사실인지, 내 경험인지, 공개해도 되는지를 판단하는 일을 없애려는 것은 아니다.

이렇게 나누면 자동화의 목적도 달라진다. 사람을 제거하는 대신 반복 작업을 줄여, 사람이 글의 내용과 중요한 판단을 더 자세히 살펴볼 수 있게 하는 것이다.

그래도 마지막에는 사람이 남는다

글을 처음 만들 때는 draft, 즉 검토 중인 초안으로 둔다. N-Layer 파일에서는 published: false로 표시한다. 초안도 읽고 검사하지만 공개용 결과물에서는 글과 이미지가 빠진다. 로컬 초안 미리보기는 별도 결과물이다.

그다음 형식과 파일, 페이지를 검사한다. 이미지는 연결됐는지, 표가 작은 화면에서 페이지 밖으로 밀려나지 않는지, 앞선 글과 기존 페이지가 그대로 동작하는지 확인한다. 이런 검사는 필요하지만 본문의 모든 사실을 증명하지는 않는다.

사람은 경험과 의도, 사실관계, 민감한 정보와 공개 범위를 검토하고 게시 여부를 결정한다. 수정이 필요하면 초안으로 돌아간다. 공개 준비를 승인한 글만 published: true로 바꾼다.

published라는 이름은 이미 인터넷에 올라갔다는 뜻으로 읽힐 수 있다. 하지만 현재 구조에서는 공개용 빌드에 넣을지를 정하는 값이다. 실제 외부 반영에는 새 결과물의 배포가 필요하다.

이번 3편의 작업 범위도 작성, 검증과 커밋까지의 게시 준비다. 운영 사이트로의 push와 production 재배포는 포함하지 않았다. 공개 상태를 다룰 수 있다는 이유만으로 배포 권한까지 생기는 것은 아니다.

이 구분이 있어야 AI가 초안을 만드는 속도와 사람이 검토하는 속도가 달라도 무리하게 공개하지 않을 수 있다.

다음에는 잘못된 결과를 막는 일을 살펴보려 한다

1편에서는 기록을 담을 공간을 만들었고, 2편에서는 글이 웹페이지가 되는 구조를 살펴봤다. 이번에는 그 안에서 사람과 AI가 맡을 일을 구분했다.

그러자 다음 질문들이 남았다.

• AI가 틀린 내용을 쓰면 어떻게 알아챌까?
• 이미지가 다른 파일에 연결되면 어떻게 막을까?
• draft가 공개용 결과물에 들어가면 어떻게 찾을까?
• 빌드가 깨지면 게시를 멈출 수 있을까?
• 새 글을 넣다가 기존 사이트가 고장 나면 어떻게 확인할까?

자동화가 많아질수록, 글을 만드는 능력보다 잘못된 결과를 막는 능력이 더 중요해지기 시작했다.

이전 글: 2편 — 글 한 편은 어떻게 웹페이지가 되는가 — 블로그의 구조를 만들다

다음 글: 4편 — 자동화에서 가장 중요한 건 ‘만드는 것’이 아니라 ‘잘못 올리지 않는 것’이었다

이제는 잘 만드는 흐름에 더해, 잘못된 결과가 올라가지 않도록 멈추는 흐름도 생각할 차례다.