[위블로그 1편] 원하는 글감에서 생성·발행·검색 노출까지

들어가며

위블로그는 사용자가 쓰고 싶은 주제나 키워드를 넣으면, 관련 글감을 찾고 출처를 확보한 뒤 블로그 글을 생성·발행하는 AI 블로그 서비스입니다. 사용자는 글감을 고르고 생성 조건을 정합니다. 서비스는 참고 자료를 모으고, 글 구조를 맞추고, 공개 주소에 글을 발행합니다. 문제는 단순하지 않았습니다.

사용자가 원하는 글감이 검색에 노출될 수 있는 콘텐츠가 되려면, 생성 앞뒤의 흐름을 어떻게 구성해야 할지가 핵심 질문이었습니다.

키워드 입력 · 자동완성 후보 선택
  ↓
글감 생성: 글 설명 · 목차 · 출처 준비
  ↓
사용자 검수: 승인 또는 제외
  ↓
승인한 글감을 발행 대기로 이동
  ↓
예약 발행 또는 지금 발행 선택
  ↓
본문 생성과 구조 검사 · 블로그 발행
  ↓
도메인 연결 · 공개 주소 확인
  ↓
검색 노출과 외부 접근 관찰

사용자가 먼저 막힌 곳은 글감이었습니다

처음부터 글 생성 자체가 가장 큰 문제였던 것은 아닙니다. LLM은 문장을 만들 수 있었습니다. 사용자가 먼저 막히는 지점은 “무슨 글을 쓰면 좋지?”였습니다.

큰 키워드는 경쟁이 세고, 수요가 없는 키워드는 써도 찾아올 사람이 없습니다. 초보 사용자가 그 사이에서 쓸 만한 주제를 고르기는 쉽지 않았습니다. 그래서 구글과 네이버 자동완성을 글감 후보의 출발점으로 삼았습니다. 예를 들어 특수건강검진 하나를 넣으면 후보 7개가 바로 나왔고, 각 후보 옆에는 어느 검색엔진에서 가져왔는지 표시했습니다.

자동완성은 사람들이 실제로 검색창에 입력한 표현을 찾는 단서라고 봤습니다. 두 엔진을 동시에 불러 합쳤고, 이 단계에서는 별도 유료 검색 API 비용 없이 후보를 모을 수 있었습니다. 한 번 찾은 후보는 7일간 저장했습니다.

다만 자동완성은 성과를 보장하지 않습니다. 자동완성에 나온다고 새 블로그가 상단에 오르거나 유입이 생기는 것도 아닙니다. 이 단계에서 필요했던 건 수익이 보장된 키워드가 아니라, 사용자가 빠르게 살펴볼 수 있는 글감 후보였습니다. 이 구현은 별도 글인 검색 자동완성에서 글감 후보를 모은 과정에 더 자세히 정리했습니다.

지식iN 질문에서 후보를 뽑는 방식도 시도했지만 닷새 만에 접었습니다. 분야별 질문 밀도가 고르지 않았고, 질문 제목과 본문을 검색어로 다듬는 시간이 길었기 때문입니다. 자동완성을 택한 기준은 수익성이 입증됐다는 것이 아니라, 여러 분야에서 사용자가 빠르게 후보를 확인할 수 있느냐였습니다.

키워드를 글감으로 만들고, 검수한 뒤 발행 시점을 정했습니다

자동완성에서 키워드를 고르는 일과 그 키워드로 어떤 글을 쓸지 정하는 일은 달랐습니다. 같은 키워드라도 교통 접근성을 설명할 수도 있고, 실제 거주 후기를 바탕으로 생활환경을 정리할 수도 있습니다. 그래서 선택한 키워드로 곧바로 완성 글을 발행하기보다, 글의 방향과 참고 근거를 먼저 확인할 수 있는 글감을 만들었습니다.

키워드 하나를 설명·목차·출처가 있는 글감으로 구체화했습니다

생성한 글감에는 제목뿐 아니라 글 설명, 목차, 출처를 함께 붙였습니다. 글 설명은 무엇을 다룰지 보여주고, 목차는 독자의 어떤 질문에 답할지 구체화합니다. 출처는 그 내용을 뒷받침할 참고 자료를 사용자가 살펴보는 출발점이었습니다.

아래는 글감을 펼쳐 검수하는 화면입니다. 키워드 설정과 누적 글감을 나누고, 누적 글감 안에서는 검수 대기, 발행 대기, 발행 반영, 제외 상태를 구분했습니다.

화면의 두 글감은 모두 양평역 입지 분석이라는 키워드에서 나왔지만, 다루는 질문은 달랐습니다. 첫 글감은 여의도·강남 출퇴근, 학군, 재개발에 따른 생활환경 변화처럼 입지 전반을 다룹니다. 두 번째 글감은 실제 거주 후기를 바탕으로 주차, 소음, 통학과 생활 인프라를 살펴봅니다. 사용자는 제목만 보고 고르는 대신, 펼쳐진 목차와 출처를 보며 자신의 블로그에 필요한 방향인지 판단할 수 있었습니다.

출처가 표시됐다는 사실만으로 내용 검증이 끝난 것은 아닙니다. 이 화면에서는 어떤 자료를 바탕으로 글을 만들려는지 확인할 수 있게 했습니다. 참고 자료가 글 설명과 맞는지, 목차의 질문을 뒷받침하는지는 검수할 때 함께 살펴볼 내용이었습니다.

검수 대기에서 승인하거나 제외하고, 승인한 글감만 발행 대기로 옮겼습니다

글감이 만들어지면 사용자는 검수 대기에서 내용을 확인했습니다. 글의 방향이 맞으면 글감 승인을, 발행 대상으로 삼지 않을 글감에는 글감 제외를 선택했습니다. 여러 항목을 체크하면 화면 위의 선택 글감 승인 또는 선택 글감 제외로 한 번에 처리할 수도 있었습니다.

이때 승인은 글감의 방향을 확정하는 단계이며, 공개 블로그에 즉시 발행하는 동작은 아니었습니다. 승인한 글감은 발행 대기로 이동하고, 사용자는 그다음에 언제 발행할지 정했습니다. 글감을 준비하는 일과 외부에 공개하는 일을 분리해, 생성된 후보 중 어떤 내용을 실제 글로 이어갈지 사용자가 선택할 수 있게 했습니다.

첨부 화면에서는 검수 대기 2개, 발행 대기 6개, 발행 반영 7개, 제외 21개가 표시됩니다. 이 숫자는 화면을 캡처한 시점의 상태별 글감 수이며, 처리 속도나 서비스 전체 발행량을 뜻하지 않습니다.

발행 대기에서 예약 발행과 지금 발행을 선택했습니다

검수를 마친 뒤에는 사용자가 공개 시점을 정할 수 있도록 예약 발행과 지금 발행을 제공했습니다. 예약 발행은 준비된 글감을 정해진 일정에 맞춰 발행하는 방식이고, 지금 발행은 예약 시각까지 기다리지 않고 발행을 진행하는 방식입니다. 공통적으로 사용자가 승인해 둔 글감을 실제 블로그 글로 이어가는 단계였습니다.

예를 들어 같은 키워드로 만들어진 두 글감을 모두 승인했더라도, 두 글을 동시에 공개해야 하는 것은 아닙니다. 사용자는 필요한 글을 지금 발행하거나, 이후 일정에 맞춰 예약 발행할 수 있습니다. 글감을 검수할 시점과 독자에게 공개할 시점을 따로 정할 수 있다는 점이 중요했습니다.

출처 확보부터 글 생성·발행까지 연결하기

사용자가 검수한 글감이 실제 본문으로 이어질 때도 글마다 구조가 달라지지 않도록 생성 규칙을 정했습니다. 검색 상단 글을 뜯어보니 질문형 제목, 본문 위의 즉문즉답 요약, 항목마다 3~5줄로 나눈 목차와 본문, FAQ와 참고 자료가 반복됐습니다. 이걸 “권장 가이드”로만 두면 글마다 결과가 달라집니다. 그래서 생성기가 반드시 지키는 규칙으로 넣었습니다.

가장 엄격하게 둔 규칙은 출처였습니다. 출처를 찾지 못하면 글을 만들지 않았습니다. 문장이 자연스럽다는 이유만으로 발행하면 보기 좋은 글만 쌓이고, 나중에 확인할 근거는 남지 않습니다.

출처 규칙은 특히 건강, 금융처럼 잘못된 정보의 비용이 큰 주제에서 중요했습니다. 생성 전에 참고할 문서를 찾고, 근거가 준비되지 않으면 다음 단계로 넘기지 않았습니다. 예시 글에도 공공기관 자료를 출처로 넣었습니다.

출처 수집은 가장 오래 걸리고 비싼 단계이기도 했습니다. 외부 검색 API는 부를 때마다 비용이 나갔기 때문에 어느 단계가 몇 번 호출됐는지, 무엇 때문에 실패했는지, 캐시로 넘어갔는지부터 나눠 봤습니다.

그다음에야 줄일 단위가 보였습니다.

• 같은 주제의 형제 글감은 검색 결과를 공유합니다.
• 한 번 찾은 문서는 7일간 캐시해 재사용합니다.
• 계속 실패하는 사이트는 비싼 재시도를 반복하지 않습니다.
• 외부 API 사용 상태는 문제가 되기 전에 알림으로 확인합니다.

이 부분은 AI 블로그 파이프라인 비용을 줄인 과정에 상세 구현을 따로 남겼습니다. 이 글에서는 중요한 판단만 남깁니다. 출처를 붙이는 원칙은 품질 규칙이었고, 캐시와 로그는 그 원칙을 반복 가능한 비용 안에 넣기 위한 장치였습니다.

생성한 글은 공개 주소에서 열려야 했습니다

글은 생성했다고 끝나지 않습니다. 공개 주소에서 열리고, 검색엔진이 읽을 수 있어야 합니다. 개인 콘솔에는 지금 어느 단계인지, 남은 작업이 무엇인지, 다음 발행이 언제인지를 한 흐름으로 보여줬습니다.

회고 당시 정리한 개선 전후 수치는 다음과 같았습니다.

키워드를 모두 받은 뒤 다음 화면으로 넘기는 대신, 먼저 시작하고 뒤에서 받도록 바꿨습니다. 전체 계산량을 없앤 것은 아니었습니다. 사용자가 처음 기다리는 순서를 바꾼 것입니다.

구글 색인을 목표로 커스텀 도메인을 필수로 삼았습니다

글을 생성하고 공개 주소에 발행하는 것만으로 검색에서 발견되는 것은 아니었습니다. 위블로그에서는 구글 색인을 목표로 운영할 블로그에 커스텀 도메인 연결을 필수로 삼고, witim.blog의 서브도메인 사용을 지양하는 방향을 잡았습니다. 원하는 사람만 주소를 꾸미는 기능이 아니라, 검색 노출을 목표로 한 제품 운영 기준이었습니다.

기본 주소로 발행한 글과 개인 도메인으로 발행한 글을 site: 명령으로 직접 확인했을 때, 검색 결과에서 발견되는 비율이 크게 달랐습니다.

위 수치는 당시 site: 검색으로 확인한 결과를 정리한 것입니다. 검색 결과에서 실제로 확인한 개별 페이지는 당시 구글에 색인되어 검색에 제공된 페이지로 볼 수 있습니다. 구글 공식 문서도 site: 결과를 색인되어 검색에 제공되는 URL 목록으로 설명합니다.

이 비교는 주제나 발행 시점, 외부 링크 조건을 맞춘 실험은 아니었습니다. 따라서 차이의 원인을 도메인 하나로 단정하지는 않았습니다. 다만 이 관찰을 바탕으로, 위블로그에서는 기본 서브도메인에 계속 발행하기보다 커스텀 도메인을 연결해 검색 노출을 검증하기로 했습니다.

이는 위블로그의 운영 판단이지, 구글이 서브도메인을 색인하지 않는다는 뜻은 아닙니다. 구글 공식 FAQ는 색인·순위 관점에서 서브폴더와 서브도메인 중 선호하는 방식이 없다고 설명합니다. 커스텀 도메인을 연결해도 색인이나 상위 노출이 보장되지는 않습니다.

당시 살펴본 워드프레스와 인블로그도 처음부터 도메인 구매·연동을 강조하고 있었습니다. 사용자가 외부에서 도메인을 사고, DNS를 설정하고, 연결 상태를 확인해야만 실험을 시작할 수 있다면 글 생성 기능이 좋아도 중간에서 막힙니다. 그래서 도메인 검색, 결제, 등록, 연결 확인을 제품 안으로 넣었습니다. workb.xyz에서 witim.blog를 거쳐 커스텀 도메인 연결을 기본 흐름으로 잡았고, 회고 당시에는 블로그 201개 중 36개가 자기 도메인을 쓰고 있었습니다. 이 숫자는 당시 적용 현황이며, 전체 블로그의 전환이 끝났다는 의미는 아닙니다.

도메인 연결에서는 “요청을 보냈다”와 “서비스가 열린다”를 구분했습니다. 실패하면 자동으로 전액 환불했고, 실제 서비스가 열렸을 때만 연결된 상태로 바꿨습니다. 대표 주소를 정하지 않아 사이트 전체가 색인에서 빠진 적도 있었습니다. 구현 세부는 커스텀 도메인 연결 자동화 글에 따로 썼습니다. 중요한 것은 구매 요청과 연결 완료를 구분하고, 실제로 글이 열리는 주소를 확인하는 일이었습니다. 커스텀 도메인 자체가 구글 색인을 보장하는 것은 아닙니다.

검색 노출과 AI 접근은 서로 다른 신호였습니다

발행과 도메인 연결을 마친 뒤에는 일반 검색 결과부터 확인했습니다. 2026년 9월 18일 구글에 로그인하지 않은 시크릿 모드에서 두 검색어를 다시 검색했습니다. site:로 특정 도메인을 지정하지 않아도 발행한 블로그 글이 일반 검색 결과에 나타났습니다.

두 화면에서 확인한 것은 일반 검색 결과에 글이 노출됐다는 사실까지입니다. 이 결과는 색인 지원을 구현했다는 사실과도 다르고, 검색 순위가 계속 유지된다거나 실제 유입으로 이어진다는 뜻도 아닙니다.

일반 검색 노출과 별개로 AI 답변의 인용과 크롤러 접근도 살펴봤습니다.

출처 기반 구조로 만든 글이 구글 AI 개요에 출처로 인용되는 장면을 실제 답변 화면에서 봤습니다. 나중에 병원·부동산으로 PoC를 좁힐 때 이 경험이 기술적인 출발점이 됐습니다.

또 서버 접속 기록으로 어느 AI 크롤러가 어떤 글에 접근했는지를 글 단위로 관찰했습니다. 검색 순위표만으로 보이지 않는 외부 접근을 사용자가 제품 안에서 확인하게 만든 화면입니다.

하지만 이 둘은 같은 결과가 아닙니다. 크롤링 대시보드에서 보여준 읽힘·인용 수치는 제품의 집계 기준에 따른 관찰값입니다. 답변 화면에서 직접 확인한 사례와는 구분해서 봤습니다. 크롤러의 방문만으로 실제 답변의 인용을 증명할 수는 없기 때문입니다.

마무리하며

1편에서 확인한 것은 “사용자가 넣은 글감이 출처 있는 글로 생성되고, 공개 주소에 발행되며, 검색과 AI 접근을 관찰할 수 있는 흐름”이었습니다. 자동완성에서 고른 키워드는 설명·목차·출처가 있는 글감으로 이어졌고, 사용자는 검수 후 승인한 글감을 예약 발행하거나 지금 발행할 수 있었습니다. 출처 규칙은 이 흐름에서 생성 품질의 하한선을 잡았습니다. 도메인 연결은 생성된 글을 사용자의 공개 주소에서 운영하기 위한 조건이었습니다.

동시에 한계도 분명했습니다. 기술적으로 작동하는 서비스를 만들었다는 사실만으로 누가 돈을 내고 계속 쓸지는 알 수 없었습니다.

그 질문은 베타 사용자를 만나고 나서야 드러났습니다. 이어지는 2편에서는 사용자 질문과 행동을 보고 위블로그의 고객, 온보딩, 제공 가치를 어떻게 다시 정의했는지를 다룹니다.