Obsidian 노트가 AI 작업 지시서로 정리되는 장면형 이미지
| |

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

Obsidian 노트가 AI 작업 지시서로 정리되는 장면형 이미지

Obsidian은 처음엔 그냥 메모장처럼 썼다. 지금은 조금 다르다. AI에게 일을 맡기기 전에 기준을 남겨두는 곳에 가깝다. 대화창에서 매번 같은 설명을 반복하기 귀찮아서 프로젝트마다 목표와 금지사항을 노트에 적기 시작했는데, 해보니 이게 꽤 중요했다.

AI가 일을 못해서 문제가 생기는 경우도 있지만, 내가 기준을 흐리게 줘서 이상한 방향으로 성실하게 달리는 경우가 더 많았다. 이게 은근히 무섭다. 틀린 방향인데 속도는 빠르다. 그래서 요즘은 작업을 시키기 전에 노트부터 정리한다.

그냥 메모와 지시서는 다르다

개인 노트는 내가 알아보면 된다. 문장이 끊겨 있어도 되고, 나만 아는 별칭이 있어도 된다. 그런데 그걸 AI에게 넘길 때는 다르다. 목적, 대상, 하지 말아야 할 일, 확인 기준이 분리되어 있어야 한다. 특히 블로그와 연결될 때는 공개해도 되는 내용과 빼야 할 내용을 먼저 나눠야 한다.

예전에는 “이 글 좀 고쳐줘”처럼 던져도 될 줄 알았다. 그런데 블로그가 여러 개가 되면 그 말이 너무 위험해진다. FMNOTE인지, PREBUY인지, Tistory인지, WordPress인지, 공개 글인지 비공개 테스트인지가 빠지면 AI는 나름대로 해석한다. 그리고 그 해석이 항상 내가 원한 방향은 아니다.

내가 노트에 꼭 넣는 것

  • 목적: 이 작업을 왜 하는지 한 줄로 적는다.
  • 범위: 어떤 사이트, 글, URL, 파일을 만질지 적는다.
  • 금지: 삭제, 계정 변경, 민감정보 출력처럼 조심할 일을 적는다.
  • 참고: 이전 결정이나 관련 문서를 연결한다.
  • 검증: 끝난 뒤 확인할 공개 URL과 화면 상태를 적는다.

이 정도만 적어도 결과가 꽤 달라진다. 특히 금지사항은 길게 쓸 필요가 없지만 꼭 있어야 한다. “삭제하지 말고 초안 처리”, “비밀번호나 토큰은 출력하지 않기”, “공개 발행 전 확인받기” 같은 문장은 귀찮아 보여도 실제 사고를 줄인다. 이런 문장 하나가 나중에 꽤 든든하다.

블로그 글로 바꿀 때 남기는 선

개인 노트를 그대로 블로그에 올리면 위험하다. 경로, 계정명, 내부 구조, 작업 중 나온 실수까지 너무 많이 드러날 수 있다. 그래서 공개 글로 바꿀 때는 전체 흐름은 남기고 실제 실행값은 뺀다. 독자에게 필요한 건 내 비밀 경로가 아니라 같은 실수를 줄이는 순서다.

예를 들어 실제 vault 경로나 보관함 파일명은 공개할 필요가 없다. 대신 어떤 종류의 문서를 먼저 읽었고, 어떤 규칙을 기준으로 삼았고, 작업 후 어떤 URL을 확인했는지는 남겨도 된다. 이 선을 지키면 글은 개인적이면서도 보안상 부담이 줄어든다.

작업 지시서 예시

목적: FMNOTE 글을 개인 기술노트형으로 보정한다.
범위: fmnote.com 공개 글과 신뢰 페이지.
금지: 비밀번호, 토큰, 계정명 출력 금지. 삭제 대신 초안 처리.
검증: 공개 URL 200, canonical, robots, sitemap 확인.
보고: 변경한 글과 남은 리스크를 한국어로 요약.

이 정도로 적어두면 다음 작업자가 사람이든 AI든 덜 헤맨다. 특히 “삭제 대신 초안 처리” 같은 문장은 실제 사고를 줄이는 데 도움이 된다. 사소해 보이지만, 막상 자동화 도구를 붙여보면 이런 사소한 선이 제일 중요했다.

FMNOTE에 쓰는 이유

FMNOTE에 이런 글을 남기는 이유는 단순하다. AI 도구를 써보면 멋진 기능보다 운영 기준이 더 자주 문제를 만든다. 어떤 모델을 쓰는지보다 어떤 노트를 먼저 읽히는지, 어떤 작업은 멈추게 하는지, 결과를 어디서 확인하는지가 실제 품질을 좌우했다.

Obsidian은 그 기준을 적어두기 좋은 자리였다. 대화창은 지나가고, 기억은 섞이고, 사람도 까먹는다. 노트에 남겨두면 다음 작업 때 다시 꺼낼 수 있다. 물론 노트도 엉망이면 소용없다. 그래서 요즘은 “내가 읽는 메모”와 “AI에게 넘길 지시서”를 조금 다르게 쓴다.

지금 기준의 결론

AI에게 일을 맡길 때 중요한 건 멋진 프롬프트 한 줄보다 작업 기준을 나누는 습관이었다. 목적, 범위, 금지, 검증이 분리되어 있으면 결과가 덜 흔들린다. 완벽하진 않아도 다음 사람이 이어받을 수 있다. 나중에 내가 다시 봐도 덜 민망하다. 이 정도면 꽤 큰 장점이다.

이어서 볼 글

Similar Posts