Obsidian 노트를 AI 작업 지시서로 바꾸는 법

Obsidian 노트를 AI에게 그대로 던지면 일이 빨라질 것 같지만, 실제로는 엉뚱한 방향으로 빨리 가는 일이 더 무섭다. 지금 기준의 결론은 단순하다. 개인 메모를 바로 프롬프트로 쓰지 않고, 목적·범위·금지·검증을 따로 적은 작업 지시서로 한 번 바꾼 뒤 넘긴다.

이 방식은 거창한 프롬프트 기술이 아니다. FMNOTE 글을 고치거나 WordPress 공개 상태를 확인할 때, 매번 같은 설명을 다시 쓰지 않으려고 만든 작은 운영 습관에 가깝다. 2026년 7월 기준으로는 이 습관 덕분에 글 수정, 내부링크 보강, 공개 URL 확인을 한 흐름 안에서 덜 헷갈리게 처리하고 있다.

처음 문제는 “노트를 많이 줬는데 왜 이상하지?”였다

증상은 꽤 뚜렷했다. Obsidian에 적어둔 배경 설명을 길게 붙이면 AI가 더 잘 이해할 줄 알았는데, 결과물은 오히려 산으로 갈 때가 있었다. 블로그 이름을 섞어 이해하거나, 공개 글에 넣으면 안 되는 내부 작업 표현을 살리거나, 검증이 끝나지 않았는데 완료 보고처럼 문장을 다듬는 식이었다.

AI가 일부러 이상하게 한 것은 아니었다. 내가 준 노트가 사람용 메모였기 때문이다. 사람은 문맥을 눈치로 채우지만, AI는 빠진 칸을 자기 방식으로 메운다. 그때 빠진 칸이 사이트, 작업 범위, 금지선, 완료 조건이면 결과가 크게 흔들린다.

실제 환경은 글쓰기와 운영이 붙어 있었다

내가 주로 쓰는 환경은 Obsidian 노트, WordPress 공개 글, Hermes나 Codex 같은 작업 도구, 브라우저 공개 확인이 함께 움직이는 구조다. 단순히 문장만 고치는 작업이면 문제가 작다. 하지만 FMNOTE처럼 애드센스 승인 회복을 목표로 둔 글은 본문 깊이, 내부링크, hero 이미지, canonical, robots meta까지 같이 봐야 한다.

그래서 지시서에는 “무슨 글을 고칠지”보다 “어디까지 건드려도 되는지”를 더 분명하게 적는다. 글 본문은 고쳐도 되지만 AdSense 검토 요청 버튼은 누르지 않는다. 공개 글은 보강해도 되지만 계정 설정, 결제, 추적 ID, 비밀값은 다루지 않는다. 이런 선이 없으면 AI가 선의로 일을 더 하다가 오히려 위험한 쪽으로 넘어갈 수 있다.

원인은 메모와 지시서의 목적이 달랐다는 점이다

개인 메모는 기억을 되살리는 도구다. 문장이 끊겨 있어도 되고, 나만 아는 줄임말이 있어도 된다. 작업 지시서는 다르다. 처음 읽는 사람이나 도구가 바로 실행할 수 있어야 한다. “아까 말한 그 글” 대신 글 ID와 URL이 있어야 하고, “적당히 고치기” 대신 어떤 검증을 통과해야 하는지 적혀 있어야 한다.

특히 공개 글을 다룰 때는 원재료와 공개 결과물을 나눠야 했다. 원재료에는 내부 경로, 작업 로그, 실패 기록이 들어갈 수 있다. 공개 결과물에는 독자가 따라 할 수 있는 기준과 검증 방법만 남긴다. 이 둘을 섞으면 글이 내부 운영일지처럼 보이고, 애드센스 관점에서도 방문자가 얻을 값이 약해진다.

내가 쓰는 지시서 칸은 일곱 개다

• 목적: 이 작업을 끝내면 무엇이 나아져야 하는지 한 문장으로 쓴다.
• 대상: 사이트, 글 ID, URL, 파일 이름처럼 실제로 만질 대상을 적는다.
• 현재 증상: 왜 손대는지, 어떤 문제가 반복됐는지 적는다.
• 금지선: 삭제, 계정 액션, 비밀값 출력, 승인 요청처럼 멈춰야 할 일을 적는다.
• 참고 근거: 이전 글, 계획 파일, 감사 JSON, 공개 URL처럼 확인 가능한 근거를 붙인다.
• 산출물: HTML, 체크리스트, 보고문처럼 받아야 할 형태를 정한다.
• 검증: 공개 URL 200, canonical, noindex 없음, 내부링크 수, 브라우저 확인처럼 끝난 뒤 볼 항목을 적는다.

이 칸을 다 채우면 프롬프트가 길어지지만, 이상하게 작업은 더 가벼워진다. AI가 추측해야 할 부분이 줄어들기 때문이다. 길게 설명하는 것보다 빠진 칸을 없애는 쪽이 효과가 컸다.

작업 지시서 예시는 이렇게 둔다

목적: FMNOTE 공개 글을 애드센스 신뢰 글로 보강한다.
대상: 글 ID 970, 공개 URL, 현재 WordPress 본문.
현재 증상: 본문이 짧고 실제 검증 근거가 약하다.
금지선: 비밀값 출력 금지, 계정 설정 변경 금지, AdSense 검토 요청 금지.
참고 근거: 회복 계획 파일, 콘텐츠 감사 JSON, 기존 내부링크.
산출물: 기존 hero 이미지를 유지한 HTML 본문과 짧은 검증 기록.
검증: 공개 200, canonical self, noindex 없음, 내부링크 2개 이상, 브라우저 확인.

이 정도면 다음 작업자가 사람이든 AI든 덜 헤맨다. “글을 좋게 고쳐줘”라고 쓰는 것보다 투박하지만, 실제 작업에서는 이쪽이 훨씬 안전했다. 특히 금지선은 친절한 문장이 아니라 브레이크다.

해결 순서는 노트 분리부터였다

해결은 새 도구를 붙이는 쪽이 아니었다. Obsidian 안에서 노트를 세 층으로 나눴다. 첫째는 내가 보기 위한 원재료 노트다. 둘째는 AI에게 넘길 작업 지시서다. 셋째는 블로그에 공개할 수 있는 설명 노트다. 같은 사건을 다루더라도 세 문서의 톤과 정보량은 다르다.

원재료 노트에는 실패 로그와 내부 판단을 조금 거칠게 남긴다. 작업 지시서에는 실행 조건과 금지선을 정리한다. 공개 설명 노트에는 독자가 자기 환경에서 따라 볼 수 있는 증상, 원인, 해결, 검증 기준만 남긴다. 이 구조로 바꾸니 글을 고칠 때도 AI가 내부 기록을 그대로 공개 문장처럼 다듬는 일이 줄었다.

블로그에 올릴 때 남기는 정보

공개 글에는 실제 비밀 경로나 계정값을 남기지 않는다. 대신 어떤 종류의 파일을 먼저 확인했는지, 작업 전후로 무엇을 비교했는지, 어떤 공개 URL을 열어 검증했는지는 남긴다. 독자에게 필요한 것은 내 로컬 경로가 아니라 자기 노트를 AI 작업 지시서로 바꿀 때 빠뜨리기 쉬운 기준이다.

FMNOTE 글에서는 이 선이 특히 중요했다. 애드센스 회복 작업은 단순 분량 늘리기가 아니라 “이 사람이 실제로 운영해본 내용을 쓰고 있는가”를 보여줘야 한다. 그래서 작업 경험은 살리되, 내부 계정이나 자동화 토큰처럼 공개하면 안 되는 값은 글 밖에 둔다.

검증은 노트가 아니라 결과물에서 한다

Obsidian 지시서가 좋아 보여도 마지막 판단은 공개 결과물에서 한다. 글을 수정했다면 WordPress REST에서 상태가 publish인지 다시 읽고, 공개 URL이 200으로 열리는지 본다. canonical이 자기 URL을 가리키는지, robots meta에 noindex가 없는지, hero 이미지가 빠지지 않았는지도 확인한다.

이 검증 기준은 AI 에이전트 크론 작업은 결과 파일부터 남겨야 덜 꼬인다에서 정리한 원칙과 이어진다. 작업이 끝났다는 말보다 결과 파일과 공개 화면이 더 믿을 만하다. AI 도구 역할을 나누는 기준은 Codex, OpenClaw, Hermes. 누가 뭘 해야 덜 꼬이나에 따로 적어뒀다.

맥 작업환경과 같이 봐야 하는 이유

Obsidian 지시서는 글쓰기 노트만의 문제가 아니었다. 맥미니를 AI 작업대로 쓰면서 권한, 경로, 브라우저 세션, 자동 실행 로그가 계속 얽혔다. 이 부분은 맥미니 M4를 AI 작업대로 쓰며 알게 된 것과 맥 AI 작업환경 세팅 체크리스트에서 이어서 볼 수 있다.

장기기억에 무엇을 남길지도 같은 문제다. 매번 지시서에 적을 기준과 다음 세션에도 남겨둘 기준은 다르다. 오래 가져갈 운영 규칙은 AI 에이전트 장기기억 설계 기준처럼 별도 기준으로 빼두는 편이 낫다.

지금 기준의 결론

Obsidian 노트를 AI 작업 지시서로 바꾼다는 말은 멋진 프롬프트를 만든다는 뜻이 아니었다. 내가 아는 배경을 AI가 실행 가능한 칸으로 다시 정리하는 일에 가까웠다. 목적, 대상, 증상, 금지선, 근거, 산출물, 검증이 보이면 결과가 덜 흔들린다.

완벽한 자동화보다 이 작은 정리가 더 자주 도움이 됐다. AI가 잘못 알아듣는 문제를 모델 탓으로만 돌리기 전에, 내가 넘긴 노트가 사람용 메모였는지 실행용 지시서였는지 먼저 보게 됐다. 솔직히 귀찮다. 그래도 공개 글과 계정이 얽힌 작업에서는 이 귀찮음이 안전장치였다.