Obsidian 메모를 Claude Code 지시서로 바꾸는 순서

지난주에 저는 Obsidian에 2000자쯤 되는 메모를 남겨둔 채, 다음 날 Claude Code에게 “그 체크아웃 버튼, 좀 고쳐줘”라고 부탁했습니다.

돌아온 건 버튼 수정에 더해서 헤더 여백 조정, 푸터 링크 순서 변경, 거기에 CSS 네이밍 규칙 정리까지 파일 3개 분량의 diff였습니다. 어느 것도 부탁하지 않았습니다. 왜 이렇게 됐냐면, 제가 메모를 통째로 붙여넣었기 때문입니다. 3일 전에 적어둔 “여기도 좀 신경 쓰이네”라는 혼잣말까지, 오늘의 지시와 똑같은 무게로 읽혀버린 거죠.

메모가 나쁜 게 아닙니다. 나쁜 건 메모를 “그대로 넘길 수 있는 것”이라고 생각한 저 쪽이었습니다. 긴 노트는 기록에는 어울리지만 작업 지시에는 어울리지 않습니다. 오늘은 이 간극을 메우는 틀, 그러니까 Obsidian 메모를 짧은 지시서로 바꾸는 순서를 적어보겠습니다.

핵심 요약

• 긴 메모를 통째로 붙이면 AI는 옛날 혼잣말과 오늘의 지시를 구분하지 못하고, 부탁하지도 않은 작업까지 벌립니다.
• 넘기는 건 네 가지뿐. “알고 있는 사실”, “정한 것”, “아직 모르는 것”, “다음 행동”. 여기에 “건드리지 않을 곳”과 “끝났다고 판단할 증거”를 더합니다.
• 완료 조건은 작게. 파일 하나, 화면 하나, 명령 하나로 좁히고, 빌드와 스크린샷까지 확인한 뒤 다음으로 넘어갑니다.
• 템플릿 프롬프트와, 메모를 지시서로 바꾸는 짧은 코드를 그대로 복사해 쓸 수 있습니다.
• AI에게 맡기는 건 “쓰기, 찾기, 고치기”. 사람이 정하는 건 “범위, 우선순위, 공개 여부”. 여기를 섞으면 사고가 납니다.

통째로 붙이면 왜 작업이 커지나

Claude Code는 움직임이 빠릅니다. 그래서 더더욱, 처음에 넘기는 정보가 넓으면 넓은 채로 전력 질주합니다.

메모에는 시간차가 있습니다. “버튼이 줄바꿈된다”는 오늘의 사실과, “그러고 보니 배색도 좀 낡았나”라는 1주일 전 감상이, 같은 목록의 항목으로 나란히 놓여 있습니다. 사람이라면 날짜나 맥락으로 구분해 읽지만, 붙여넣어진 AI에게는 어느 것이 살아 있는 지시인지 알 수 없습니다. 결국 친절한 마음으로 전부에 손을 댑니다.

또 하나. 메모에는 “정한 것”과 “아직 망설이는 것”이 섞여 있습니다. 망설임 부분까지 지시로 읽히면, AI가 멋대로 어느 한쪽으로 정해서 진행해 버립니다. 이게 제일 무섭습니다. 그래서 넘기기 전에, 사람 쪽에서 한 번만 분류해 둘 필요가 있습니다.

넘기는 건 네 가지뿐

분류의 축은 단순합니다. 다음 네 가지로 나눠 담기만 하면 됩니다.

1. 사실: 실제로 확인한 것. “375px 화면에서 버튼이 2줄로 줄바꿈된다”, “공개 URL은 맞다”처럼, 보면 누구나 동의할 수 있는 것.
2. 결정: 이미 정한 것. “무료 배포 PDF는 유료 교재보다 앞에 둔다”처럼, 논의가 끝나 흔들지 않을 방침.
3. 미확인: 아직 모르는 것. “어느 컴포넌트가 버튼의 여백을 갖고 있는지 불명”처럼, AI가 멋대로 채우게 하고 싶지 않은 구멍.
4. 다음 행동: 이번에 할 단 하나. “컴포넌트를 특정하고, 최소한의 CSS 변경을 적용하고, 모바일 폭에서 확인한다”까지 구체적으로.

여기에 두 가지를 더합니다. 건드리지 않을 곳(예: 인증 관련 파일은 이번에 손대지 않음)과, 끝났다고 판단할 증거(예: 빌드가 통과한다, 모바일 폭 스크린샷). 이 여섯 항목이 지시서의 알맹이입니다.

분류할 때 의식할 건, “미확인”을 지우지 않는 것입니다. 모르는 걸 솔직하게 남겨두면 AI가 거기를 먼저 질문해 줍니다. 반대로 미확인을 지우고 사실처럼 적으면, 틀린 전제 그대로 밀고 나갑니다.

AI에게 맡길 범위와, 사람이 정할 범위

맡겨도 되는 것과, 사람이 쥐고 있어야 하는 것을 처음에 선을 긋습니다. 여기가 애매하면 지시서를 만들어도 결국 흔들립니다.

공정	AI에게 맡긴다	사람이 정한다
범위	-	어느 파일, 화면으로 좁힐지
조사	컴포넌트나 코드를 찾는다	찾을 대상의 우선순위
구현	최소한의 변경을 쓴다	변경해도 되는 상한선
확인	빌드, 테스트를 돌린다	공개해도 되는지 최종 판단

표에서 보듯이 “찾기, 쓰기, 돌리기”는 AI가 잘합니다. 한편 “어디까지 할지”, “공개해도 되는지”는 사람이 쥡니다. 이 선을 지시서에 적어두면, AI가 범위를 넓히려 해도 스스로 멈춥니다.

복사해서 쓰는 프롬프트 템플릿

먼저 메모를 그대로 선택해서, 이 요청문 아래에 붙입니다. 분류 작업 자체를 AI에게 시키는 방식입니다.

다음 Obsidian 메모를, Claude Code용 짧은 지시서로 정리해 주세요.
출력은 아래 제목만 쓰고, 그 외에는 버리세요.

- 사실: 확인된 것만
- 결정: 이제 흔들지 않을 방침
- 미확인: 멋대로 채우지 말고, 불명인 채로 남길 것
- 다음 행동: 이번에 할 단 하나를 구체적으로
- 건드리지 않을 곳: 이번에 손대지 않을 파일이나 기능
- 증거: 끝났다고 판단할 확인 수단(빌드, 스크린샷 등)

오래된 감상이나 잡담은 "참고 메모"로 별도 칸에 모으고, 지시에는 섞지 마세요.

나온 지시서를 다시 읽으며, 미확인이 사실로 둔갑하지 않았는지, 다음 행동이 하나로 좁혀졌는지만 확인합니다. 문제가 없으면 이걸 그대로 CLAUDE.md나 이슈 코멘트에 붙여 구현을 부탁합니다. CLAUDE.md 작성법은 claude-md-best-practices에 자세히 정리해 두었습니다.

메모를 지시서로 바꾸는 검증 코드

손으로 하기 전에, 구조를 몸에 익히기 위한 작은 코드를 둡니다. Node.js로 동작합니다. 메모를 위의 여섯 항목으로 나눠 담고, Claude Code에게 넘길 한 장짜리 지시서로 조립하기만 하는 것입니다.

// 메모를 "사실, 결정, 미확인, 다음 행동"으로 나눠 담는다
const note = {
  title: "체크아웃 버튼이 모바일에서 줄바꿈된다",
  facts: ["375px 화면에서 버튼이 2줄로 줄바꿈된다", "공개 URL은 맞다"],
  decision: "무료 배포 PDF는 유료 교재보다 앞에 둔다",
  unknowns: ["어느 컴포넌트가 버튼의 여백을 갖고 있는지 불명"],
  nextAction: "컴포넌트를 특정하고, 최소한의 CSS 변경을 적용하고, 모바일 폭에서 확인한다",
  doNotTouch: ["인증 관련 파일"],
  proof: ["빌드가 통과한다", "375px 폭 스크린샷"],
};

// 여섯 항목을 한 장짜리 지시서 텍스트로 조립한다
function toBrief(item) {
  return [
    `목적: ${item.nextAction}`,
    `사실: ${item.facts.join(" / ")}`,
    `결정: ${item.decision}`,
    `미확인(멋대로 채우지 말 것): ${item.unknowns.join(" / ")}`,
    `건드리지 않을 곳: ${item.doNotTouch.join(" / ")}`,
    `증거: ${item.proof.join(" / ")}`,
  ].join("\n");
}

// 분류 누락을 기계로 점검하는 문지기
function checkBrief(item) {
  const missing = [];
  if (item.facts.length === 0) missing.push("사실");
  if (item.unknowns.length === 0) missing.push("미확인");
  if (!item.nextAction) missing.push("다음 행동");
  if (missing.length) {
    throw new Error(`분류가 부족합니다: ${missing.join(", ")}`);
  }
  return true;
}

checkBrief(note);
console.log(toBrief(note));

checkBrief가 수수하지만 중요한 핵심입니다. 사실이 비어 있거나, 미확인이 비어 있거나, 다음 행동이 빈 채로 지시서를 내려고 하면 여기서 멈춥니다. “일단 붙이고 보자”를 코드 단계에서 금지해 두면, 거친 메모가 그대로 AI로 흘러가는 사고가 줄어듭니다. 출력 결과를 그대로 이슈 코멘트나 인계 노트에 붙이면, 다음 작업에서도 같은 판단을 돌려 쓸 수 있습니다. 인계 노트 만드는 법은 claude-code-session-handoff-template이 참고가 됩니다.

이런 장면에서 효과가 있다

1. 글 개선을 부탁할 때

“이 글 좀 좋게 해줘”라고 통째로 던지면, AI는 본문을 전부 다시 쓰기 십상입니다. 그래서 지시서에 “검색 의도와 CTA 방침만 넘긴다”, “본문 전체 재작성은 금지”라고 적습니다. 사실은 지금의 제목, 결정은 동선 방침, 미확인은 약한 문단, 다음 행동은 제목 하나만 고치기, 이렇게 나눕니다. 그러면 diff가 작아지고, 되돌리기도 한순간입니다. Obsidian 연동 자체의 설정은 claude-code-obsidian-integration에 정리해 두었습니다.

2. 버그를 고칠 때

재현된 사실과, 아직 모르는 원인을 나눠서 넘기는 게 요령입니다. “375px에서 버튼이 줄바꿈된다”는 사실, “어느 컴포넌트가 여백을 갖는지”는 미확인. 여기를 섞어서 “원인은 CSS일 것”이라고 적어버리면, AI는 틀린 짐작 그대로 고치기 시작합니다. 미확인을 미확인인 채로 넘기면, AI가 먼저 거기를 조사해 줍니다.

3. 도입 상담을 받을 때

고객의 업무 메모를 그대로 보여주지 말고, “이번에 건드릴 범위”, “절대 건드리지 않을 범위”, “다음에 확인할 것”으로 나눠 넘깁니다. 운영 데이터나 결제 관련을 미확인인 채로 자동으로 손대게 하지 않습니다. 이 선 긋기를 지시서에 적어두기만 해도, 상담 자리에서 안심하고 화면을 공유할 수 있습니다.

흔히 저지르는 실패와, 그 고치는 법

제가 처음에 저지른 실패는 대체로 이 세 가지로 모입니다.

첫째는 vault 전체를 붙인 것. 오래된 결정과 지금의 제약이 섞여서, AI가 어느 쪽을 믿어야 할지 모르게 됐습니다. 고치는 법은 단순합니다. 붙이기 전에 위의 여섯 항목으로 분류하기만 하면 됩니다. 3일 전 감상은 “참고 메모”로 격리합니다.

둘째는 결정만 넘긴 것. “PDF를 앞에 둔다”고만 적었더니, AI는 왜 그러는지 몰라서 다른 장면에서는 반대로 했습니다. 사실과 이유를 세트로 남기면 응용이 됩니다.

셋째는 완료 조건을 크게 잡은 것. “전체적으로 정리해줘”라고 부탁하면, AI는 친절하게 범위를 넓힙니다. 파일 하나, 화면 하나, 명령 하나로 좁히고, 빌드와 스크린샷을 본 뒤 다음으로. 이것만으로 속도를 떨어뜨리지 않으면서 되돌리는 시간을 줄일 수 있습니다. 프롬프트를 좁히는 법은 claude-code-prompt-engineering-advanced도 함께 보세요.

자주 묻는 질문

Q. 메모를 전부 붙이는 것보다, 지시서를 만드는 게 더 손이 가지 않나요? 처음 몇 번은 그렇게 느낍니다. 하지만 통째로 던져서 커진 diff를 다시 읽고 되돌리는 시간이, 길게 보면 더 무겁습니다. 분류는 익숙해지면 1분이면 끝납니다.

Q. 분류도 AI에게 시켜도 되나요? 됩니다. 위의 프롬프트 템플릿이 바로 그 방식입니다. 다만 나온 지시서는 사람이 한 번 읽고, 미확인이 사실로 둔갑하지 않았는지만 확인하세요.

Q. CLAUDE.md와 지시서는 어떻게 다른가요? CLAUDE.md는 프로젝트 전체에서 변하지 않는 규칙 보관소, 지시서는 이번 작업 한 번 분량의 요청입니다. 지시서의 “결정”이 몇 번이고 반복해서 나오면, 그건 CLAUDE.md로 승격시키라는 신호입니다.

Q. Obsidian이 아니어도 쓸 수 있나요? 쓸 수 있습니다. Notion이든 그냥 텍스트 메모든 OK입니다. 중요한 건 도구가 아니라, 사실, 결정, 미확인, 다음 행동으로 나누는 사고 쪽입니다.

Q. 어디까지 AI에게 맡기고, 어디부터 사람이 정해야 하나요? “찾기, 쓰기, 돌리기”는 맡겨도 괜찮습니다. “범위를 어디까지 넓힐지”, “공개해도 되는지”는 사람이 쥡니다. 이 선을 지시서에 적어두는 게 요령입니다. AI에게 맡기는 법의 기초는 claude-code-for-non-engineers에서 설명합니다.

실제로 해본 결과

서두의 “부탁하지도 않은 파일 3개 사고” 이후, 저는 메모를 붙이기 전에 반드시 여섯 항목으로 분류하게 됐습니다.

실제로 같은 체크아웃 버튼 수정을, 이번에는 지시서로 만들어 넘겨봤습니다. diff는 파일 1개, CSS 몇 줄뿐. 헤더도 푸터도, 부탁하지 않은 것에는 일절 손대지 않았습니다. checkBrief로 미확인을 빈 채로 내려다가 한 번 막혀서, “어느 컴포넌트가 여백을 갖는지”를 덧붙인 뒤 넘긴 것도 효과가 있었던 것 같습니다. AI가 먼저 그 컴포넌트를 찾아줬으니까요.

확인한 건 두 가지. “미확인을 남기면, AI가 멋대로 채우지 않고 조사해 준다”는 것. 그리고 “다음 행동을 하나로 좁히면, diff가 작아져서 되돌리기 쉽다”는 것. 똑똑한 프롬프트를 찾는 것보다, 넘기기 전 1분의 분류 쪽이 결국 가장 빠르다는 게 지금의 실감입니다.

메모 분류에 익숙해지고, 다음으로 팀 전체에서 같은 틀을 돌리고 싶어지면, 진행 방식을 함께 설계하는 연수, 상담도 준비해 두었습니다.

공식 전제 조건은 Anthropic Claude Code getting started에서 확인할 수 있습니다.