Daejin Lab 운영 원칙을 먼저 정했습니다
Daejin Lab은 AI 도구와 개발 자동화를 다루는 블로그입니다. 그래서 더 조심해야 할 부분이 있습니다. 주제가 AI라고 해서 글까지 일괄 초안처럼 보이면, 사이트의 신뢰도가 바로 떨어질 수 있기 때문입니다.
이 블로그는 “AI로 글을 찍어내는 곳”이 아니라, 실제로 개인 프로젝트를 만들고 운영하면서 남기는 기록에 가깝게 운영하려고 합니다. 이번 글은 그 기준을 공개적으로 남기기 위한 운영 원칙입니다.
시작 배경은 Daejin Lab을 시작합니다에 적어두었습니다. 이 글에서는 그 이후 실제 운영하면서 계속 지키려는 기준만 따로 정리합니다.
1. 자동 발행은 하지 않습니다
AI 도구는 초안 작성, 아이디어 정리, 체크리스트 생성에 도움이 됩니다. 하지만 최종 발행까지 자동으로 넘기지는 않습니다.
초안 작성: 도구 도움 가능
사실 확인: 직접 확인
경험 구분: 직접 해본 것과 조사한 것 분리
최종 발행: 사람이 확인한 뒤 진행
이 기준은 단순히 안전해 보이기 위한 문구가 아닙니다. 실제로 Search Console, sitemap, Cloudflare Pages 같은 주제는 화면에 표시되는 상태와 공개 URL의 실제 응답이 다를 수 있습니다. 그래서 글로 쓰기 전에 npm run build, 공개 URL 확인, sitemap 응답 확인 같은 절차를 거치려고 합니다.
글 발행 전에는 최소한 아래 질문을 봅니다.
이 글에 실제로 해본 작업이 들어갔는가?
명령어, URL, 파일 경로, 판단 기준 중 하나라도 남겼는가?
조사한 내용과 직접 경험을 섞어 쓰지 않았는가?
광고·제휴·개인정보 관련 표현이 실제 운영과 맞는가?
2. 직접 겪은 문제를 우선 기록합니다
Daejin Lab의 좋은 글은 일반적인 설명보다 운영 중 실제로 부딪힌 문제에서 나옵니다.
예를 들면 이런 기록입니다.
Search Console에서 sitemap.xml이 가져올 수 없음으로 표시됨
astro.config.mjs의 site URL과 robots.txt sitemap URL을 맞춤
공개 /sitemap.xml은 200 application/xml로 응답함
Googlebot 유사 요청으로도 접근 가능함
그래서 파일을 더 바꾸기보다 재제출 후 대기하기로 판단함
이런 내용은 짧아도 사이트 고유의 경험입니다. 반대로 “sitemap은 SEO에 중요합니다” 같은 문장만 반복하면 다른 사이트와 구분되기 어렵습니다. 실제 sitemap 흐름은 Search Console에서 sitemap 가져올 수 없음이 뜰 때 확인한 것에 이어서 정리했습니다.
3. 글 수보다 보강 기록을 봅니다
AdSense를 생각하면 글 수를 늘리고 싶은 마음이 먼저 듭니다. 하지만 30개 글을 빠르게 채우는 것보다, 얇은 글을 다시 읽고 실제 경험을 덧붙이는 일이 더 중요하다고 봅니다.
현재 운영 기준은 아래와 같습니다.
30개 글을 기본선으로 둔다
짧은 글부터 경험 문단을 보강한다
카테고리별 대표 글을 만든다
소개/문의/개인정보/광고고지 페이지를 실제 운영 내용에 맞춘다
Search Console 색인이 쌓일 시간을 둔다
2026-05-08 기준으로 Daejin Lab은 글 35개, sitemap URL 47개 상태입니다. 숫자만 보면 빈 사이트 느낌은 줄었지만, AdSense 준비 기준에서는 대표 글의 밀도와 내부 연결이 더 중요합니다. 그래서 핵심 12개 글을 먼저 보강하는 방식으로 방향을 바꿨습니다.
AdSense 쪽 판단은 첫 20개 글 이후 다시 본 AdSense 준비 상태와 AdSense를 고려한 필수 페이지 구성에 연결해두었습니다.
3-1. 이번 보강 스프린트에서 적용한 기준
이번에는 새 글을 더 늘리기보다 이미 공개된 핵심 글을 먼저 손봤습니다. 기준은 단순했습니다.
방문자가 처음 볼 가능성이 높은 글인가?
AdSense 검토자가 사이트 정체성을 이해하는 데 도움이 되는가?
실제 운영 중 겪은 오류, 대기, 판단 기준이 들어가는가?
내부 링크로 다음 글을 자연스럽게 이어줄 수 있는가?
그래서 시작 글, 운영 원칙, AdSense 준비 글, Search Console 글, 정적 블로그 구축 글을 우선순위로 잡았습니다. 글 수를 늘리는 것보다 대표 글이 실제 운영 기록처럼 읽히는지가 더 중요하다고 봤습니다.
4. 개발 기록은 검증 결과를 남깁니다
개발 자동화 글에는 가능하면 실행한 명령어와 확인한 결과를 남기려고 합니다.
npm run build
git status --short --branch
공개 URL 200 확인
sitemap URL 개수 확인
robots.txt의 Sitemap 선언 확인
모든 글에 명령어가 들어갈 필요는 없지만, 개발/SEO/배포 글에서는 결과가 있어야 신뢰가 생깁니다. Daejin Lab은 이 부분을 운영 기록의 중심으로 삼으려고 합니다.
반대로 외부 계정 로그인, AdSense 신청, Search Console 콘솔 조작, 배포를 유발하는 git push 같은 작업은 자동으로 넘기지 않습니다. 글로 정리하거나 로컬에서 검증하는 것과, 실제 외부 서비스에 영향을 주는 작업은 분리합니다.
5. 공개하지 않을 정보도 정합니다
개인 프로젝트 기록이라고 해서 모든 것을 공개할 필요는 없습니다. 특히 자동화와 개발 도구를 다루다 보면 파일 경로, 토큰, 계정 정보, 개인 메모가 글에 섞일 수 있습니다.
Daejin Lab에 공개하지 않을 기준은 아래입니다.
API 키, 토큰, 세션 정보
개인 계정 화면의 민감한 캡처
비공개 메모나 개인 폴더 내용
구체적인 수익·계정 심사 화면 중 공개가 부담스러운 정보
다른 사람에게 영향을 줄 수 있는 자동 실행 절차
대신 공개 가능한 범위에서 명령어 구조, 검증 순서, 판단 기준을 남기려고 합니다. 예를 들어 키 값 자체는 공개하지 않지만, API 키를 안전하게 관리하는 기본 원칙처럼 관리 기준은 글로 남길 수 있습니다.
6. 다음 블로그로 확장하기 전에 기준을 고정합니다
장기적으로는 여러 개인 블로그를 운영하고 싶지만, 지금은 Daejin Lab이 먼저입니다. 1호 블로그에서 글 작성, 빌드, 배포, 색인 확인, AdSense 준비 흐름이 안정되어야 다음 블로그로 확장할 수 있습니다.
다음 블로그를 열기 전 기준은 아래처럼 잡았습니다.
Daejin Lab sitemap 상태 안정화
대표 글 일부 색인 확인
핵심 12개 글 보강 완료
브랜드 기본 자산 정리
커스텀 도메인 여부 결정
지금 남긴 약속
Daejin Lab은 빠르게 커지는 블로그보다, 운영 기록이 쌓이는 블로그를 목표로 합니다.
AI 도구는 계속 다루되, 글의 중심은 도구 소개가 아니라 실제 사용, 실패, 수정, 판단 과정에 두겠습니다. 이 기준이 지켜져야 나중에 다른 블로그로 확장할 때도 같은 운영 모델을 재사용할 수 있다고 봅니다.