Obsidian wiki 노하우를 블로그 글로 옮기기 전에 정한 보안 기준

Obsidian에는 공개 글보다 훨씬 솔직한 메모가 쌓입니다. 막힌 지점, 계정 설정, 로컬 경로, 실패한 명령, 아직 정리되지 않은 생각이 같이 들어갑니다.

그래서 처음에는 이 노트를 그대로 블로그 글로 옮기면 좋겠다고 생각했습니다. 그런데 다시 보니 바로 공개하면 안 되는 정보가 꽤 많았습니다. Daejin Lab에서는 Obsidian wiki를 공개 원고 창고가 아니라, 보안 검수를 거쳐 블로그 글로 바꾸는 원천 자료로 쓰기로 했습니다.

먼저 나눈 세 공간

raw/inbox: 아직 정리되지 않은 관찰, 링크, 명령 결과, 캡처 메모
.omx/wiki: 반복해서 쓸 수 있는 판단 기준과 운영 원칙
src/content/blog: 사람이 검수한 공개 글

이 구분이 없으면 모든 메모가 바로 글감처럼 보입니다. 하지만 raw에는 아직 검증하지 않은 생각이 있고, wiki에는 내부 운영 기준이 있고, 공개 글에는 독자가 읽어도 되는 문장만 남아야 합니다.

특히 자동화 블로그에서는 이 경계가 더 중요했습니다. AI가 초안을 빠르게 만들수록 공개해도 되는 내용과 아직 내부에 남겨야 할 내용이 섞이기 쉽기 때문입니다.

공개해도 되는 것

Obsidian wiki에서 블로그 글로 옮겨도 좋은 내용은 대부분 판단 기준입니다.

직접 해결한 문제의 순서
자동화 작업 전후 비교
블로그 운영 체크리스트
AI 도구 사용 루틴
로컬 LLM 실험 기록
Search Console과 sitemap 확인 흐름
실수한 뒤 다시 정한 원칙

이런 내용은 Daejin Lab에 잘 맞습니다. 단순 정보 요약이 아니라, 실제로 겪은 문제와 그때 만든 기준이 들어가기 때문입니다.

예를 들어 “블로그 운영 자동화는 편합니다”라는 문장은 약합니다. 반대로 “초안은 AI가 만들 수 있지만, 공개 전에는 사람이 민감정보와 링크를 다시 봐야 한다”는 기준은 이 블로그에서 계속 쓸 수 있습니다.

공개하면 안 되는 것

반대로 아래 내용은 글감처럼 보여도 그대로 올리지 않습니다.

API 키와 토큰
개인 이메일과 계정명
환경 변수 파일의 실제 내용
로컬 실제 경로
Cloudflare, Google, GitHub 계정 식별값
아직 막지 않은 보안 취약점의 재현 절차
비공개 자동화 스크립트의 위험한 실행 방식
다른 사람의 글이나 유료 자료를 길게 옮긴 내용

이 항목은 검색엔진보다 먼저 운영자에게 위험합니다. 한 번 공개된 글은 RSS, 캐시, 검색 결과, 배포 기록에 남을 수 있습니다. 그래서 애매하면 공개 글로 옮기지 않고 raw나 wiki에 남겨둡니다.

제가 쓰는 변환 순서

Obsidian wiki에서 공개 글로 옮길 때는 아래 순서를 기준으로 잡았습니다.

1. 원본 노트를 읽는다.
2. 민감정보와 내부 식별값을 제거한다.
3. 공개해도 되는 판단 기준만 남긴다.
4. 실제 상황과 실패 과정을 붙인다.
5. 독자가 따라 할 수 있는 체크리스트로 바꾼다.
6. 내부 링크를 연결한다.
7. build와 publish check를 통과한 뒤 사람이 마지막으로 본다.

이 순서에서 중요한 부분은 2번과 7번입니다. 글을 잘 쓰는 것보다 먼저 공개하면 안 되는 값을 제거해야 합니다. 그리고 자동 검사를 통과해도 사람이 마지막에 읽어야 합니다.

글 안에 보안상 생략한 것을 밝히기

보안 때문에 뺀 정보는 숨기기보다 짧게 설명하는 편이 낫습니다.

실제 계정명과 로컬 경로는 공개하지 않았습니다.
대신 어떤 기준으로 분리했는지만 남깁니다.

이렇게 쓰면 독자는 왜 일부 값이 빠졌는지 이해할 수 있습니다. 글도 더 신뢰감 있게 읽힙니다. Daejin Lab은 튜토리얼처럼 모든 값을 보여주는 블로그가 아니라, 실제 운영에서 어디까지 공개할지 정하는 블로그에 가깝습니다.

git push 전에 한 번 더 멈추기

이 블로그는 git push 이후 Cloudflare Pages 배포로 이어집니다. 그래서 push는 사실상 발행 버튼에 가깝습니다.

이번에 발행 전에 확인할 수 있도록 아래 명령을 따로 만들었습니다.

npm run check:publish
npm run verify:publish

check:publish는 글의 frontmatter, 내부 링크, draft 노출, 위험 문자열을 빠르게 봅니다. verify:publish는 여기에 build까지 붙여서 더 강하게 확인합니다.

필요하면 git push 전에 자동으로 실행되게 할 수도 있습니다.

git config core.hooksPath .githooks

이 설정을 켜면 push 전에 발행 게이트가 실행됩니다. build가 실패하거나 draft가 노출되거나 위험한 문자열이 있으면 push가 멈춥니다.

공개 글로 바꾸며 확인한 것

이 글은 원래 내부 기준 메모에 가까웠습니다. 공개하기 전에 한 번 더 보니, 그대로 올리기보다 “어떤 정보는 빼야 하는지”를 먼저 설명하는 글이 낫겠다고 판단했습니다.

이번 글을 공개 상태로 바꾸면서 아래 항목을 다시 봤습니다.

단계	실제로 본 것
원본 노트	특정 계정이나 로컬 경로가 본문에 남지 않았는가
보안 제거	토큰, 이메일, 내부 식별값을 예시로도 노출하지 않는가
공개 기준	독자가 가져갈 수 있는 판단 기준만 남았는가
내부 링크	자동 발행 금지와 초안 검수 글로 자연스럽게 이어지는가
발행 전 검사	`npm run check:publish`를 통과하는가

관련 기준은 발행 버튼을 자동화하지 않기로 한 이유와 블로그 초안 검수 체크리스트에서도 같은 방향으로 잡았습니다. raw와 wiki의 역할은 로컬 작업 폴더를 자동 정리하기 전에 정한 기준과도 이어집니다.

push 전에 남기는 기준

Obsidian wiki는 Daejin Lab의 좋은 콘텐츠 원천입니다. 하지만 원본 노트를 그대로 공개하는 순간, 노하우와 위험 정보가 같이 나갈 수 있습니다.

그래서 git push 전에 아래 기준을 봅니다.

원본은 내부에 둔다.
판단 기준은 wiki에 정리한다.
독자에게 도움이 되는 부분만 공개 글로 바꾼다.
push 전에는 발행 게이트를 통과한다.

이 네 줄을 통과하지 못하면 공개 글이 아니라 내부 노트로 남깁니다. 지금은 글을 빨리 늘리는 것보다, 한 번 공개한 뒤에도 후회하지 않을 경계를 세우는 쪽이 더 중요합니다.

2026-05-31에 다시 보강한 공개 경계

애드센스 실패 뒤 이 글을 다시 읽으면서, raw/wiki와 공개 글의 경계를 더 눈에 보이게 남겨야겠다고 봤습니다. 내부 메모가 많은 사이트일수록 독창성은 생기지만, 동시에 공개하면 안 되는 값이 섞일 위험도 커집니다.

raw 메모, wiki 판단 기준, 민감정보 검수, 공개 블로그 글로 이어지는 공개 경계 흐름

Daejin Lab에서는 원본 메모를 그대로 공개하지 않습니다. 공개 글에는 독자가 가져갈 수 있는 판단 기준과 재현 가능한 범위만 남깁니다.

이번 재검토에서 이 글의 역할은 분명합니다. Daejin Lab이 AI로 글을 대량 생성하는 사이트가 아니라, 내부 운영 기록을 사람이 걸러 공개 글로 바꾸는 사이트라는 점을 보여줘야 합니다. 그래서 “무엇을 썼는가”만큼 “무엇을 공개하지 않았는가”를 설명하는 것이 중요했습니다.

참고한 공식 문서

공개 전 보안 검수와 콘텐츠 품질 기준은 아래 문서를 함께 참고합니다.

Obsidian 문서는 메모 관리의 전제, GitHub 문서는 비밀값 노출 위험, Google 문서는 공개 콘텐츠가 독자에게 고유한 가치를 줘야 한다는 기준을 확인하는 용도입니다. Daejin Lab의 운영 판단은 이 셋을 섞어서 “공개 가능한 기록만 남긴다”로 정리했습니다.

확인하지 않은 것

이 글은 모든 raw/wiki 노트를 안전하게 자동 변환하는 도구가 아닙니다. 특히 계정 화면, 로컬 경로, API 키, OAuth secret, 결제/광고 계정 정보는 자동 치환만 믿지 않고 사람이 다시 봐야 합니다.

FAQ

내부 wiki 내용을 공개하면 독창성이 높아지나요?

원본성이 생길 수는 있습니다. 하지만 그대로 공개하면 위험합니다. 공개 글에는 원본 메모의 결론, 판단 기준, 재현 가능한 범위만 남기는 편이 안전합니다.

로컬 경로도 숨겨야 하나요?

대부분 숨기는 쪽이 낫습니다. 경로 자체가 비밀은 아니더라도 사용자명, 프로젝트 구조, 내부 작업 방식이 같이 드러날 수 있습니다.

애드센스와 이 글의 관련은 무엇인가요?

Daejin Lab의 고유 가치는 내부 운영 기록에 있습니다. 다만 그 기록이 안전하게 공개 글로 바뀌는 과정이 보여야 “얇은 자동 생성 글”처럼 보이지 않습니다.

공개 글로 바꿀 때 남기는 흔적

내부 노트를 공개 글로 바꿀 때 모든 흔적을 지우면 글이 너무 일반론처럼 보입니다. 반대로 원본을 그대로 드러내면 위험합니다. 그래서 Daejin Lab에서는 중간 지점을 남기려고 합니다.

남길 것: 문제를 만난 순서, 판단 기준, 공개 URL, 명령 이름, 검증 결과
뺄 것: 계정명, 내부 경로, 토큰, 원본 캡처, 개인 메모의 감정적 표현
바꿀 것: 실제 값은 더미 예시나 공개용 카드로 재구성

이 기준을 쓰면 글이 안전해지는 동시에 더 사람답게 남습니다. “보안상 생략했습니다”라고만 쓰는 것보다, 어떤 종류의 정보를 왜 뺐는지 말하는 편이 낫습니다. 애드센스 관점에서도 이 글은 단순 정책 글이 아니라, Daejin Lab이 내부 자료를 어떻게 공개 가능한 경험 기록으로 바꾸는지 보여주는 역할을 합니다.

이 글을 공개 표면에 남기는 기준

이 글은 내부 노트를 공개하는 방법이 아니라, 내부 노트를 공개하지 않는 방법까지 포함해야 합니다. Daejin Lab의 고유성은 raw/wiki에 쌓이는 실제 기록에서 나오지만, 그 원본을 그대로 내보내면 사이트 신뢰가 아니라 위험이 됩니다.

그래서 이 글의 마지막 기준은 간단합니다. 독자가 가져갈 수 있는 판단 기준은 남기고, 계정·경로·토큰·원본 캡처는 빼는 것입니다. 이 선이 보여야 Daejin Lab이 자동 생성 글 묶음이 아니라, 내부 기록을 검수해 공개하는 사이트로 읽힐 수 있습니다.