옵시디언 마크다운을 Claude Code로 연결해 자동 업무 엔진 만들기

웹 클리퍼가 가져온 쓰레기 데이터부터 치우기

웹에서 긁어온 마크다운 파일은 광고와 메뉴 바 같은 노이즈 덩어리입니다. 이런 텍스트가 섞여 있으면 RAG(검색 증강 생성) 성능이 눈에 띄게 떨어집니다. 실제로 정제되지 않은 데이터는 모델의 주의력을 분산시키지만, 깔끔하게 정리된 마크다운은 검색 정확도를 높입니다. 불필요한 텍스트를 쳐내면 로컬 LLM이 먹어 치우는 토큰도 30% 이상 줄어드니 돈 아까울 일도 없습니다.

파이썬의 BeautifulSoup 라이브러리를 써서 이 노이즈를 걷어내야 합니다.

1. 터미널에서 pip install beautifulsoup4 lxml을 입력해 환경을 잡습니다.
2. 스크립트에서 decompose() 메서드로 .ad-container나 .nav-menu 같은 불필요한 CSS 클래스를 통째로 지웁니다.
3. lxml 파서로 본문만 추출해 마크다운으로 저장하고 옵시디언 보관소에 넣습니다.
   이렇게 하면 모델이 핵심 내용에만 집중하게 되어 헛소리(환각)를 덜 하고, 토큰 소모량도 25% 수준으로 뚝 떨어집니다.

Claude Code가 길을 잃지 않는 폴더 설계

파일이 수백 개로 불어나면 아무리 똑똑한 모델도 컨텍스트를 놓칩니다. 그냥 파일을 쌓아두지 말고 정보의 상태에 따라 구역을 나누십시오. 저는 PARA 프레임워크를 비틀어 3단계(01_Raw_Inbox, 02_Processed_Wiki, 03_Project_Action) 구조를 씁니다. Claude Code가 어떤 정보를 믿고 참조할지 물리적인 가이드라인을 주는 겁니다.

에이전트가 헤매지 않도록 파일 이름과 터미널 옵션을 활용합니다.

1. 모든 파일 이름 앞에 YYYY-MM-DD를 붙여서 정보가 얼마나 싱싱한지 알려줍니다.
2. Claude Code를 실행할 때 --newer-than 옵션을 써서 최근 24시간 안에 바뀐 파일만 읽게 만듭니다.
3. 03_Project_Action 폴더에는 작업 상태가 적힌 파일만 둡니다.
   이 구조를 잡으면 Claude가 보관소 전체를 뒤적거리는 멍청한 짓을 안 합니다. 덕분에 10분씩 걸리던 검색이 30초면 끝납니다.

YAML 메타데이터로 검색의 구멍 메우기

단순한 텍스트 검색은 이 문서가 '중요한지' 아니면 '끝난 일인지' 구분하지 못합니다. 그래서 문서 상단에 YAML Frontmatter를 넣어야 합니다. 메타데이터가 있으면 Claude Code에게 훨씬 정교한 명령을 내릴 수 있습니다.

지식 창업자의 업무 엔진에 필요한 필드는 세 가지면 충분합니다.

1. 주제를 나누는 topic, 중요도를 따지는 source_importance, 작업 상태인 status를 노트 맨 위에 적습니다.
2. 옵시디언의 'YAML Toolkit' 플러그인으로 기존 파일 수백 개에 이 규칙을 한 번에 먹입니다.
3. Claude Code의 설정 파일(CLAUDE.md)에 "status가 Doing인 문서만 보고 업무 리스트를 짜라"고 적어둡니다.
   매일 아침 2시간씩 자료 정리하던 고역에서 해방되어 10분 만에 업무 브리핑을 받을 수 있는 상태가 됩니다.

명령어 한 줄로 끝내는 데일리 브리핑 루틴

터미널 기반의 Claude Code는 쉘 스크립트와 만났을 때 진짜 힘을 발휘합니다. 출근해서 명령어 하나만 치면 어제 공부한 내용을 분석하고 오늘 보낼 메일 초안까지 뽑아주는 엔진이 완성됩니다. 아침마다 뭘 먼저 할지 고민하며 에너지를 낭비할 필요가 없습니다.

자동화 루틴은 다음과 같이 짭니다.

1. claude --bare 명령어를 넣은 쉘 스크립트(.sh 또는 .bat)를 만들어 초기 구동 속도를 높입니다.
2. find -mtime -1 명령을 스크립트에 섞어 최근 하루 동안 만든 노트만 Claude에게 넘깁니다.
3. Claude Code의 PostToolUse 기능을 써서 생성된 메일 초안의 오타를 고치고 특정 폴더에 자동 저장하게 만듭니다.
   메일 한 통 쓰는 데 30분씩 걸리던 시간이 5분으로 줄어듭니다.

데이터 폭발에 대처하는 계층적 참조 전략

파일이 천 개를 넘어가면 20만 토큰의 컨텍스트 윈도우도 금방 찹니다. 이때부터는 모든 파일을 읽히는 게 아니라, 전체 지도의 역할을 하는 master_index.md를 먼저 보게 하는 2단계 방식을 써야 합니다. 이 방식은 API 호출 횟수를 60% 가까이 줄여줍니다.

성능을 유지하려면 컨텍스트 관리를 영리하게 해야 합니다.

1. 전체 토큰 소모를 다음과 같은 구성으로 이해하고 관리합니다.$$T_{total} = T_{system} + T_{index} + T_{active\_files} + T_{history}$$
2. Claude Code가 마스터 인덱스를 먼저 읽고 질문에 답하는 데 꼭 필요한 파일 경로만 찾게 합니다.
3. 찾아낸 경로의 파일만 추가로 읽어 답변을 만들고, 대화가 길어지면 /compact 명령어로 이력을 요약합니다.
   이 계층 구조를 도입하면 데이터가 아무리 쌓여도 버벅거림 없이 즉각적인 의사결정 지원을 받을 수 있습니다.