키워드 발견부터 글 보관까지 연결한 블로그 자동화 개발기

📖 소개

저는 키워드 레이더가 단순히 관심 키워드를 보여주는 화면에 머물지 않고, 지금 발행할 키워드를 고른 뒤 제목과 원고를 만들고 이미지까지 검수해 보관하는 도구가 되기를 원했습니다. 이번 작업에서는 각 기능이 따로 움직이던 문제를 확인하고, 키워드 발견부터 작성한 글 관리와 옵시디언 보관까지 하나의 흐름으로 연결했습니다.

작업 도중 ‘내 레이더’ 목록의 정렬 순서와 키워드 상세 화면의 ‘네이버 월간 검색 수요’가 맞지 않는다는 점도 발견했습니다. 처음에는 후보를 수집할 때 확인한 검색 수요를 기준으로 목록이 정렬된다고 이해했습니다. 그런데 코드를 다시 확인해 보니 목록 정렬에 사용한 검색 수요값은 신호 데이터에 남지 않았고, 키워드 상세 화면의 ‘네이버 월간 검색 수요’는 별도 API 요청으로 다시 조회하고 있었습니다. 따라서 두 값이 같은 시점과 기준으로 수집된 데이터인지 확인하기 어려운 구조였습니다. 화면에 보이는 숫자만 설명하는 데서 멈추지 않고, 실제 발행 판단에 도움이 되는 기준으로 정렬 방식을 다시 정하는 계기가 됐습니다.

🛠️ 진행 방법

개발에는 Codex를 사용했고, Next.js와 React로 작성된 기존 프로젝트의 화면·API·저장 구조를 함께 확인했습니다. 네이버 데이터랩의 전일 대비 관심 변화, 검색광고의 월간 검색 수요, 블로그 검색 API의 검색 결과 수, KLI와 판단 신뢰도를 서로 다른 역할로 나눴습니다. 완성 글은 기존 데이터베이스에 유지하면서 브라우저의 File System Access API와 IndexedDB를 이용해 사용자가 선택한 옵시디언 폴더에도 저장하도록 구현했습니다.

프롬프트 1 — 제목과 원고의 연결 흐름 정의

자 그러면 글감 선정을 위한 제목은 어떻게 나오게 만들 거야? 그리고 어떻게 플로우가 연결되는지 설명해 봐.

이 질문으로 제목 10개를 고정 공식에서 꺼내는 방식이 아니라, 키워드 데이터와 참고 글 패턴을 먼저 분석한 뒤 서로 다른 검색 의도로 생성하는 흐름을 확인했습니다. 제목을 저장할 때 검색 의도·참고 패턴·차별화 지점도 함께 보관하고, 같은 분석 결과를 원고와 이미지 생성까지 이어 주는 방향을 잡았습니다.

프롬프트 2 — 발행 효과를 위한 정렬 기준 결정

질문! 블로그 검색결과수, 전일대비 상승률순, kli의 판단신뢰도 중에서 내가 블로그글을 발행하는 입장에서 효과를 제대로 보려면 어떤 게 나을까?

이 질문에서는 하나의 수치로 모든 것을 판단하지 않았습니다. 판단 신뢰도는 데이터 필터, 전일 대비 상승률은 발행 시점, 블로그 검색 결과 수는 경쟁도, 월간 검색 수요는 최소 수요를 확인하는 기준으로 나눴습니다.

프롬프트 3 — 이미지 검수와 옵시디언 보관 구현

자 그러면 이 기능 넣는 걸로 수정하기로 하고, 보완할 사항을 또 알려줄게.
지금 글 만들기에서 글을 만들고 작성한 글로 들어가 보면, 작성한 글이 잘 나오고 맨 아래에 이미지가 표시돼.
그런데 첨부한 사진을 보면 이미지 5개가 나열된 건 좋은데, 아래 사항을 추가해 줘:
이미지 밑으로 다운로드 잘되는 건 그대로 놔두기
이미지 자체를 클릭했을 때는 이미지가 확대되는 창을 띄워서 보여주기
ESC(Escape) 키를 누르면 다시 원래 글이 있는 화면으로 나오게 하기
그리고 이미지가 글의 내용과 맞게 나와야 되는데, 마음에 안 들 때가 있을 거 아니야? 그때 이미지를 재생성하는 ‘재생성하기’ 버튼을 이미지 다운로드 뒤쪽에 하나 만들어야 될 것 같아.

완성된 이미지를 단순히 나열하는 데서 끝내지 않고, 크게 확인하고 마음에 들지 않는 한 장만 다시 만들 수 있도록 요청했습니다. 같은 작업 범위에서 옵시디언 저장 폴더 기억, KR-0001 관리번호, HTML 캡션 제거와 발행 화면의 복귀 동선도 함께 구현했습니다.

💡 결과와 배운 점

1. 글감 제목과 실제 원고가 같은 분석 결과를 사용하게 했습니다

내 레이더에서 키워드를 고르면 네이버 검색 API의 정확도순 참고 글과 검색 의도를 분석해 제목 후보를 만들고, 사용자가 저장한 제목에는 추천 근거와 패턴 정보가 함께 남도록 연결했습니다. 사용자가 ‘스타일 설정’에서 고른 문체도 글감에 스냅샷으로 저장해 원고 생성 단계에서 같은 스타일을 이어받게 했습니다. 네이버 검색 API의 정확도순은 개인별 실제 상위 노출 순위와 같다고 단정하지 않고 참고 데이터로만 사용했습니다.

2. ‘내 레이더’를 검색량 나열이 아니라 발행 기회 순서로 바꿨습니다

판단 신뢰도 70% 이상, 월간 검색 수요 100회 이상인 후보만 남기고 전일 대비 상승률이 높은 순으로 정렬했습니다. 상승률이 같으면 블로그 검색 결과 수가 적은 키워드, 그다음에는 KLI가 높은 키워드를 먼저 보여주도록 했습니다. 후보를 수집할 때 사용한 월간 수요값도 신호 데이터에 보존해 정렬 근거가 사라지지 않게 했습니다.

이 변경은 v0.7.4, 커밋 cbe2606으로 GitHub main에 반영했고 Vercel Production에도 배포했습니다. 당시 전체 테스트 81개, ESLint와 Production 빌드가 통과했으며 공개 페이지와 헬스 API가 HTTP 200으로 응답하는 것도 확인했습니다.

3. 원고 문맥을 읽고 서로 다른 실사 이미지 5장을 관리하게 했습니다

이미지마다 사람이나 책을 반복하는 대신 환경·사람·사물·과정·결과처럼 서로 다른 장면 역할을 나누고, 글의 문맥에 맞는 시네마틱 실사 이미지를 사용하도록 기존 생성 흐름을 유지했습니다. 작성한 글에서는 사진을 클릭해 확대할 수 있고, ESC나 닫기 버튼으로 돌아올 수 있습니다. 다운로드 버튼은 유지하면서 그 뒤에 현재 이미지만 다시 만드는 버튼을 추가했습니다. 과거 버전 미리보기에서는 재생성을 막아 저장된 기록이 바뀌지 않게 했습니다.

4. 작성한 글과 발행 준비 화면의 역할을 정리했습니다

완성 원고와 이미지, 생성 시각, 수정 시각과 버전은 기존 데이터베이스에 계속 저장합니다. ‘발행 준비’를 누른 사용자가 어디로 돌아가야 하는지 바로 알 수 있도록 그 버튼 아래에 ‘원고로 돌아가기’를 배치했습니다. HTML 다운로드 결과에서는 이미지 아래의 <figcaption>을 제거하고 접근성과 검색 이해에 필요한 alt만 남겼습니다.

5. 완성 콘텐츠를 옵시디언에 다시 활용할 수 있는 형태로 저장했습니다

사용자가 최상위 저장 폴더를 한 번 선택하면 브라우저가 폴더 권한을 기억하고, 화면에는 현재 폴더명과 경로 변경 기능을 계속 보여줍니다. 앱은 선택한 폴더 아래에 articles/KR-0001-대표키워드-글의관점/을 만들고 Markdown, HTML, assets/01.jpg부터 05.jpg까지 저장합니다. 날짜는 폴더가 아니라 Markdown 속성에 기록하고, 관리번호와 상대 경로, 저장 시각은 기존 프로젝트 DB에도 남깁니다.

옵시디언 저장과 이미지 확대·재생성 개선은 로컬 코드에서 테스트 83개, ESLint, Production 빌드까지 통과했습니다. 다만 이 부분은 사례 작성 시점에 아직 커밋하거나 Production에 배포하지 않았습니다.

시행착오: 코드 일부만 보고 목록이 월간 검색 수요순이라고 단정했다가, 사용자가 화면 값을 직접 비교하면서 정렬 근거값과 표시값이 분리돼 있다는 사실을 다시 확인했습니다. 또한 사례글 전용 볼트 경로를 블로그 콘텐츠 저장 경로로 잘못 제안해 두 경로의 목적을 분리했습니다.
도움 필요한 부분: 실제 인기 글의 공통 특징을 분석하려면 볼트에 글을 모으는 것만으로는 부족합니다. 발행 URL과 1일·3일·7일·14일 노출, 검색 유입과 조회수 데이터를 DB에 추가로 쌓는 기능이 필요합니다.
앞으로의 계획: 로컬 검증이 끝난 옵시디언·이미지 검수 기능을 커밋하고 배포한 뒤, 발행 성과를 키워드·제목·문체·본문 구조와 연결하는 피드백 루프를 만들 계획입니다.

📚 도움 받은 글 (옵션)

이번 작업에서는 별도의 외부 글을 인용하지 않았습니다. 실제 대화 기록, 프로젝트 코드, 네이버 API에서 수집한 데이터 구조와 테스트 결과를 기준으로 판단했습니다.

✅ Do (해야 할 것)

화면에 보이는 값과 실제 정렬에 사용하는 값이 같은 데이터인지 코드까지 확인하기
신뢰도·상승률·검색 수요·경쟁도의 역할을 분리해 발행 우선순위 정하기
제목을 만들 때 사용한 검색 의도와 참고 패턴을 원고까지 함께 전달하기
완성 이미지 전체를 확인하고 마음에 들지 않는 한 장만 다시 생성하기
Markdown·HTML·이미지와 DB 기록을 같은 관리번호로 연결하기

❌ Don't (하지 말아야 할 것)

코드 일부만 확인하고 화면의 정렬 기준을 단정하기
전일 대비 상승률만 보고 검색 수요가 거의 없는 키워드를 우선하기
글감 제목과 원고 생성 규칙을 서로 다른 흐름으로 관리하기
사례글 전용 볼트와 블로그 콘텐츠 저장 경로를 혼용하기
로컬 테스트 통과 상태를 Production 배포 완료로 표현하기

😈 정말 찐찐찐 마지막 할인가!!! 24기 AI 스터디 😈