AI 블로그 초안 작성 프로그램 만들기: 실행 예제로 배우는 설계·검사·저장

AI 활용 제작 기록 · 블로그 초안 작성 도구

메모와 사진은 있지만 첫 원고를 쓰기 막막하다면, AI에 전달할 자료를 정리하고 결과를 확인하는 작은 도구부터 만들어 볼 수 있다. 이 글에서는 실행 가능한 예제 → 입력·출력 비교 → 검사 코드 → 실제 개인용 프로그램의 설계 순서로 살펴본다.

내가 만든 프로그램은 자료로 AI 초안을 생성하고, 원고를 수정·검토한 뒤 네이버에 임시저장하는 도구다. 독자가 먼저 따라 할 수 있도록 핵심 기능만 분리한 별도 브라우저 예제를 제공한다. 전체 개인용 앱과 실습 예제의 범위는 구분해서 설명한다.

먼저 작은 버전부터 실행해 보기

처음부터 로그인 연결과 사진 업로드까지 만들 필요는 없다. 자료로 요청문을 만들고, AI 응답을 검사해 검토용 원고로 저장하는 작은 프로그램부터 시작하면 된다. 이 글에는 직접 열어 볼 수 있는 예제와 전체 소스를 함께 준비했다.

초안 작성 실습 예제·전체 소스 다운로드 ZIP

ZIP을 압축 해제한 뒤 index.html을 Chrome이나 Edge로 연다. 설치 명령이나 API 키는 필요하지 않다. core.js는 같은 폴더에 두어야 한다. 이 예제는 기존 개인용 프로그램의 핵심을 단순화한 별도 실습이며, 네이버에 접속하거나 발행하지 않는다. AI에 요청문을 전달하고 응답을 가져오는 단계는 직접 복사·붙여넣기로 진행한다.

① 가상 자료로 화면부터 확인한다

페이지를 열면 가상 자료가 들어 있다. 「AI 요청문 만들기」 → 「예시 응답 넣기」 → 「응답 검사」를 차례로 누른다. 정상이라면 “구조 검사 통과 · 사실 확인은 별도” 메시지와 검토용 원고가 나타난다. 예시 응답은 설명을 위해 직접 작성한 고정 자료이며, 실제 AI 실행 결과나 실제 방문 후기는 아니다.

원자료와 문장을 비교한 다음 「원자료·문장·사진 설명을 직접 대조했습니다」를 체크하면 「검토용 초안.md 저장」 버튼을 사용할 수 있다. Markdown은 제목과 본문을 담는 텍스트 형식이다. 메모장이나 코드 편집기로 열 수 있으며, Word 문서나 네이버 발행 글이 아니다.

② 내 메모로 바꾸고 AI 응답을 받아 본다

자료 입력란에서 topic은 주제, facts는 원고에 써도 되는 사실, photos는 사진 설명이다. ID는 사실과 사진을 구별하는 이름표다. F1·F2 같은 사실 ID와 P1·P2 같은 사진 ID를 서로 겹치지 않게 작성한다. 처음에는 사진 없이 "photos": []로 시작해도 된다.

{
  "topic": "메모를 글 초안으로 정리하기",
  "facts": [
    {"id": "F1", "text": "메모를 주제별로 나눠 정리한다."},
    {"id": "F2", "text": "확인하지 않은 정보는 따로 표시한다."},
    {"id": "F3", "text": "초안은 직접 검토한 뒤 발행한다."}
  ],
  "photos": []
}

위 입력도 실습용 예시다. 자신의 주제와 사실로 바꾼 뒤 「AI 요청문 만들기」를 누른다. 만들어진 요청문을 사용하는 AI 서비스의 대화창에 직접 붙여넣고, 받은 JSON 응답을 「AI 응답 JSON」 입력란에 넣는다. JSON은 프로그램이 제목·문단·근거를 구분해 읽을 수 있도록 정해 놓은 데이터 형식이다. 문장의 표현은 AI 실행마다 달라질 수 있다.

「응답 검사」에서 오류가 나오면 오류 문구와 응답을 AI에게 전달해 수정하거나 직접 고친다. 요청문 복사가 막히는 브라우저에서는 입력란의 글자를 선택해 Ctrl+C로 복사한다. 자료를 AI 서비스에 붙여넣으면 그 서비스로 전송되므로 공개해도 되는 연습 자료부터 사용한다. 이 예제는 API를 호출하지 않지만, 사용하는 AI 서비스의 요금과 이용 제한은 별도다.

③ 일부러 오류를 만들어 검사해 본다

「가상 자료 넣기」와 「예시 응답 넣기」로 돌아온 뒤, 응답의 첫 fact_ids에 있는 F1을 F999로 바꿔 검사한다. 입력에 F999가 없으므로 “없는 근거 ID F999”가 나타나고 저장 버튼은 비활성화된다. 사진 ID를 P999로 바꾸거나 제목 끝에 00.jpg를 붙이는 경우도 수정 대상으로 표시된다.

마지막 항목이 중요하다. 본문을 “방문객이 매일 500명이다”로 바꾸고 기존의 유효한 ID를 남기면 구조 검사를 통과할 수 있다. 검사 프로그램은 ID가 있는지 확인할 뿐 그 자료가 문장을 의미상 뒷받침하는지 판단하지 않는다. 근거를 적게 하는 기능과 근거를 검증하는 기능은 다르다.

예제를 내 프로그램으로 바꾸는 방법

전체 소스의 index.html은 화면과 버튼 동작, core.js는 요청문 구성·응답 검사·Markdown 변환을 담당한다. 두 파일로 나눈 이유는 화면을 고쳐도 검사 규칙을 따로 확인할 수 있게 하기 위해서다. AI가 글을 만드는 부분과 프로그램이 형식을 검사하는 부분을 구분해서 읽으면 구조가 단순해진다.

근거와 사진 연결을 확인하는 핵심 코드

실제 예제의 검사 로직을 짧게 줄이면 아래처럼 읽을 수 있다. 입력 ID를 집합으로 만들고, 응답이 참조한 ID가 그 안에 있는지 확인한다. 다운로드한 core.js에는 빈 값과 배열 형식 등 추가 검사도 들어 있다.

const facts = new Set(data.facts.map(x => x.id));
const photos = new Set(data.photos.map(x => x.id));

for (const id of paragraph.fact_ids) {
  if (!facts.has(id)) errors.push(`없는 근거 ID ${id}`);
}
for (const id of paragraph.photo_ids) {
  if (!photos.has(id)) errors.push(`없는 사진 ID ${id}`);
}

원고나 입력 자료를 수정하면 검사 결과와 검토 체크를 취소한다. 검사한 뒤 내용을 바꿔 놓고 이전 결과로 저장하는 상황을 막기 위해서다. 미리보기는 AI 응답을 HTML로 실행하지 않고 텍스트로 표시한다. 응답에 태그가 들어 있더라도 화면 코드로 실행하지 않는 구조다.

코드를 처음 수정한다면 이 요청부터 시작한다

예제 폴더를 AI 코딩 도구에서 열고 다음처럼 요청해 볼 수 있다. 단순히 “블로그 프로그램 만들어 줘”라고 하기보다 유지할 동작과 추가할 기능을 구체적으로 정하는 편이 검토하기 쉽다. 아래는 수정 요청의 예시이며 이미 구현된 추가 기능을 뜻하지 않는다.

이 폴더의 index.html과 core.js를 읽고 수정해 줘.
현재 자료 입력 → 요청문 생성 → 응답 검사 → 검토용 저장 흐름은 유지해 줘.
첫 변경은 facts를 JSON 대신 표에서 입력할 수 있게 하는 것이야.
표에 ID, 사실 내용, 삭제 버튼을 두고 행 추가 버튼을 넣어 줘.
ID 중복과 빈 내용은 막아 줘.
자료를 고치면 이전 검사 결과와 검토 체크를 취소해 줘.
외부 통신이나 자동발행 기능은 추가하지 마.
정상 입력과 중복 ID 입력으로 동작을 확인해 줘.

다음에는 글 종류별 요청문, 수정 전후 비교, 문단 옆 근거 표시 순서로 확장할 수 있다. AI API 연결은 로컬 검사 흐름이 안정된 뒤 별도로 추가하는 편이 좋다. 현재 예제에는 API 연결이나 사진 분석 기능이 없으며, 브라우저 대화창에서 응답을 직접 가져온다.

예제에서 확인한 범위

정상 예시의 미리보기와 검토 체크에 따른 저장 버튼 활성화를 브라우저에서 확인했다. 없는 근거 ID를 넣으면 오류가 표시되고 저장 버튼이 비활성화되는 것도 확인했다. 별도 검사 스크립트에서는 JSON 오류, 중복 ID, 없는 사진, 제목 오염, 섹션 누락과 의미 검증의 한계를 확인하고 예시 Markdown 파일을 생성했다.

앞의 고정 예시와 별개로 실제 Gemini 응답 한 건도 확인했다. 이는 모델의 일반적인 생성 품질이나 네이버 연동 성공을 평가한 것이 아니다. 브라우저 다운로드 완료 확인은 여전히 남아 있다. ZIP에는 동일 변환 함수로 만든 example-draft.md를 포함했다. Node.js가 있다면 node verify.cjs로 검사 로직을 다시 확인할 수 있다.

실제 Gemini 응답으로 확인한 범위

가상 입력·실제 Gemini 응답·Markdown 결과 ZIP 다운로드 — 입력과 결과를 파일별로 대조할 수 있다. 실제 AI 응답 파일에는 API 키나 개인 자료가 들어 있지 않다.

2026년 10월 14일, ZIP에 들어 있는 sample.json의 가상 자료로 예제의 요청문을 만들고 Gemini 3.5 Flash-Lite에 한 번 전달했다. 입력은 실제 방문 기록이나 개인 사진이 아닌 공개용 연습 자료다. 반환된 JSON에는 제목 하나, 본문 두 절과 근거 ID가 들어 있었고 예제의 구조 검사를 통과했다.

같은 예제의 Markdown 변환 함수로 .md 파일을 만들고 내용을 열어 확인했다. 첫 절은 “실제 방문 후기가 아니다”와 자료를 두 항목으로 나누는 내용을, 둘째 절은 발행 전 원자료와 사진의 개인정보를 확인하는 내용을 담았다. 각 문단은 제공한 F1·F2·F3을 참조했다. 이 결과는 가상 자료 한 번의 실행이며 다른 자료에서 사실성이 보장된다는 뜻은 아니다.

글쓰기에서 줄이고 싶었던 작업

원고 작성에는 성격이 다른 작업이 섞여 있다. 실제 경험과 판단을 적는 일은 글쓴이가 해야 하지만, 흩어진 메모를 소제목으로 나누거나 사진 파일을 확인하고 같은 서식을 반복 적용하는 일은 프로그램이 도울 수 있다. 그래서 글의 재료를 준비하는 단계와 AI가 문장으로 정리하는 단계, 사람이 확인하는 단계를 나눴다.

예를 들어 직접 방문한 장소를 다루는 글과 제품 정보를 비교하는 글은 같은 말투로 만들면 안 된다. 정보만 제공한 제품에 대해 “써 보니 편했다”라고 쓰면 실제 경험이 아닌 후기가 된다. 글 종류에 따라 프롬프트를 나누고, 경험하지 않은 내용을 경험한 것처럼 쓰지 않도록 규칙을 넣었다. 이 규칙이 있어도 생성 결과를 읽고 확인하는 과정은 필요하다.

입력부터 임시저장까지의 구조

화면은 React와 Vite, 로컬 서버는 Python과 FastAPI로 구성했다. 화면에서 요청을 보내면 서버가 초안 생성이나 에디터 입력 작업을 시작하고, 진행 상태를 화면에 돌려준다. 시간이 걸리는 작업은 별도 작업으로 관리하므로 글을 만들고 있는지, 수정 중인지, 저장에 실패했는지 확인할 수 있다.

작성 규칙과 핵심 처리는 화면 코드에서 분리했다. 화면을 바꿔도 프롬프트나 검사 규칙이 함께 바뀌지 않도록 한 것이다. 프로젝트의 주요 파일은 다음 역할을 맡는다.

현재 AI 연결은 API를 호출하는 방식이 아니라 로그인된 AI 서비스의 브라우저 대화창을 사용하는 방식이다. Chrome의 원격 디버깅 연결을 이용해 요청을 입력하고 응답을 받는다. 따라서 서비스 화면이나 응답 복사 방식이 바뀌면 연결 코드도 점검해야 한다. API 기반 앱과 같은 구조라고 설명하거나, 웹 구독이 무제한 자동화 권한을 제공한다고 볼 수는 없다. 해당 서비스의 이용 조건도 별도로 확인해야 한다.

프롬프트에는 문체보다 재료와 경계를 먼저 넣었다

“자연스럽게 글을 써 줘”만으로는 어떤 사실을 써도 되는지 정하기 어렵다. 작성할 주제, 직접 적은 메모, 제공한 사진, 확인한 정보, 쓰면 안 되는 표현을 함께 전달하도록 구성했다. 경험 글과 정보 글을 구분하는 것도 이 단계에서 처리한다.

다음은 입력과 요청의 관계를 보여주는 가상의 예시다. 실제로 방문하거나 생성한 결과를 뜻하지 않는다.

글 종류: 직접 경험한 기록
주제: 동네 도서관에서 책 찾기
내 메모:
- 원하는 책이 서가에 없어서 직원에게 문의했다.
- 다른 지점에 있는 책은 예약 안내를 받았다.
사진: 안내판, 검색 화면
확인하지 않은 것: 다른 지점의 운영 시간

작성 조건:
- 메모에 없는 방문 경험을 추가하지 않는다.
- 확인하지 않은 운영 시간은 단정하지 않는다.
- 사진에 개인정보가 있는지는 발행 전에 직접 확인한다.
- 문의 과정과 확인한 결과를 구분해서 정리한다.

방법을 설명하는 글에는 조사 기능을 연결했다. 실제 조사 프롬프트에는 공식 사이트와 도움말을 먼저 확인하고, 확인하지 못한 메뉴나 버튼 이름은 만들어 쓰지 말라는 조건이 들어 있다. 자료마다 내용이 다르면 차이를 남기고, 어디서 알았는지 출처를 붙이도록 했다. 조사 결과는 최종 사실 판정이 아니라 글을 쓰기 전 검토할 자료다.

상위 검색 글을 참고하는 기능도 있다. 다루는 항목이나 검색 의도를 파악할 수 있지만, 다른 사람의 경험을 내 경험으로 옮기거나 문장을 바꿔 붙이는 방식으로 사용하면 안 된다. 공식 자료와 직접 확보한 정보가 무엇인지 구분하고, 최종 원고에 독자에게 필요한 설명이 추가됐는지 확인해야 한다.

AI 응답을 검사하고 같은 대화에서 고쳤다

생성된 답변은 문자열 그대로 에디터에 넣지 않는다. 먼저 제목, 소제목, 본문, 사진 등 블록으로 나누고 글 종류에 맞는 규칙을 검사한다. 검사 결과에는 문제의 종류와 고치는 방향이 들어간다. 수정이 필요한 항목이 있으면 같은 AI 대화창에서 다시 요청한다.

현재 구현의 핵심 흐름을 읽기 쉽게 줄이면 다음과 같다. 아래 코드는 구조를 설명하는 발췌·축약본으로, 단독 실행용 전체 프로그램은 아니다.

clip = ch.ask(prompt)
parsed = D.parse(clip)
checks = D.check(parsed, kind, sub, keyword, photo_count)
bad = sum(1 for grade, *_ in checks if grade == "bad")

tries = 0
while bad and tries < retry:
    tries += 1
    fix = P.fix_message(checks, parsed, kind, sub)
    clip2 = ch.ask(fix)
    parsed2 = D.parse(clip2)
    checks2 = D.check(parsed2, kind, sub, keyword, photo_count)
    bad2 = sum(1 for grade, *_ in checks2 if grade == "bad")

    if bad2 <= bad:
        clip, parsed, checks, bad = clip2, parsed2, checks2, bad2
    else:
        break

수정 횟수에 상한을 둔 이유는 계속 다시 쓰게 한다고 원고가 좋아지지는 않기 때문이다. 규칙 검사에서 문제 수가 늘어나면 앞 원고를 유지하고 자동 수정을 멈춘다. 문제가 줄어든 원고를 선택하더라도, 그 점수가 사실의 정확성이나 글의 가치를 증명하지는 않는다. 사람이 읽어야 알 수 있는 오류는 별도로 남는다.

예를 들어 문장 길이와 소제목 구성은 검사하기 쉽지만, 사진 설명이 실제 장소와 맞는지, 내가 느끼지 않은 감정을 만들어 썼는지, 원문 자료를 잘못 이해했는지는 규칙만으로 확인하기 어렵다. 그래서 화면에서 원고를 고치고 다시 검사할 수 있도록 했다.

사진은 순서보다 원고와의 연결이 중요했다

사진을 폴더 순서대로 넣으면 본문과 맞지 않는 위치에 들어갈 수 있다. 현재 초안 생성에서는 선택된 사진을 줄여 AI에 첨부하고, 파일 이름을 함께 전달해 원고에서 참조하도록 한다. 사진 첨부가 일부 실패하면 파일 이름을 지정하지 않는 프롬프트로 되돌리는 처리도 있다. AI가 전달받지 못한 사진을 본 것처럼 배치하지 않도록 하기 위해서다.

사진을 줄이는 작업은 전송량을 줄이지만, 작은 글씨나 세부 사항을 읽기 어려워질 수 있다. 메뉴판의 가격이나 안내문 문구처럼 정확한 값이 필요한 내용은 원본을 직접 확인한다. 사진이 AI 서비스로 전송되는 기능을 사용할 때는 인물·연락처·회사 자료 등 보내도 되는 정보인지 먼저 확인해야 한다.

개발 중에는 본문에서 캡처 자리를 하나 지우자 뒤의 사진이 한 칸씩 밀리는 문제가 있었다. 이를 처리하기 위해 원고의 각 자리에 연결된 파일 정보를 기준으로 사진 번호를 다시 정리하도록 바꿨다. 사진 번호가 아니라 이 문단에 어떤 파일이 붙어야 하는지를 유지하는 것이 중요했다.

또 다른 문제는 제목 끝에 이미지 파일명인 00.jpg가 붙은 것이었다. 현재 전송 처리에는 제목이 이미지 확장자로 끝나면 입력을 중단하는 검사가 들어 있다. AI 문장을 잘 생성하는 것뿐 아니라, 파일 정보가 글 내용에 섞이지 않도록 막는 일도 필요했다.

임시저장 성공을 따로 확인했다

화면에 글이 보인다는 것과 저장됐다는 것은 다르다. 에디터 입력 후 저장 버튼을 누르고, 저장된 글 수가 이전보다 늘었는지 확인하는 처리를 넣었다. 실제 저장 함수는 다음과 같다.

def save_draft(c, ctx, wait=4.5):
    n0 = c.js(SAVE_COUNT_JS, context_id=ctx)
    note = c.js(CLICK_SAVE_JS, context_id=ctx)
    time.sleep(wait)
    n1 = c.js(SAVE_COUNT_JS, context_id=ctx)
    return note, n0, n1

# 호출한 쪽에서 저장 여부 판정
ok = isinstance(n0, int) and isinstance(n1, int) and n1 > n0

저장이 확인돼야 작업 폴더에 저장 시각을 남기고, 설정에 따라 에디터 탭을 닫는다. 저장 개수가 늘지 않으면 성공으로 처리하지 않고 사람이 확인할 수 있도록 화면을 남긴다.

이 판정에도 한계가 있다. 기존 임시저장 글을 덮어쓰면 개수가 늘지 않을 수 있고, 숫자가 늘었어도 사진이나 본문 일부가 빠졌을 가능성은 남는다. 따라서 첫 설정이나 네이버 화면 변경 후에는 임시저장 목록에서 글을 다시 열어 제목·본문·사진을 확인해야 한다. 현재의 개수 검사는 저장 결과 전체를 검증하는 방법은 아니다.

태그 입력에는 발행 설정창을 여는 과정이 있지만, 그 안의 최종 발행 버튼은 누르지 않도록 구현했다. “발행 버튼을 전혀 건드리지 않는다”라고 설명하기보다 설정창을 여는 동작과 실제 공개하는 동작을 구분한다고 설명하는 편이 정확하다.

현재 범위와 남은 과제

현재는 자료 입력, AI 초안 생성, 규칙 검사와 수정, 원고 편집, 사진 연결, 네이버 임시저장까지 이어지는 개인용 도구다. 자동 검사로 글의 사실성을 보장하거나, 검색 노출과 수익을 보장하는 기능은 없다. 응답 생성 시간과 입력 시간도 자료와 서비스 상태에 따라 달라져 일정한 절약 시간을 제시하지 않는다.

네이버 에디터 입력은 브라우저를 조작하는 구현이다. 임시저장까지만 한다고 해서 네이버가 공식적으로 허용한 연동이라고 단정할 수는 없다. 네이버는 사전 허락 없이 자동화 수단으로 기계적인 패턴의 글을 반복 게재하는 행위를 제한 대상으로 설명한다. 이 도구의 범위와 플랫폼 이용 조건을 별도로 확인해야 한다. 네이버 블로그 서비스 운영정책

앞으로 보완할 부분은 원고 버전 비교, 사진과 문단의 연결 확인, 저장 결과의 재확인이다. AI 연결도 서비스 화면에 의존하는 부분을 줄이고, 허용된 연동 방식으로 교체할 수 있도록 다른 처리와 분리해 두는 것이 중요하다.