밑줄은 PDF 안에 갇혀 있고, 내 머릿속 기억은 흐려지고, 그 사이를 연결해주는 정리된 노트가 없는 상태. 논문 작성 단계에서 이게 진짜 문제가 됐다.
이 글은 Claude(Opus)와 PDF 하이라이트를 자동 추출하고, 맥락 설명·태깅·연구 연결까지 해주는 리딩로그 스킬(/readlog)을 만든 과정이다. 이 과정에서 확인한 것: 단순 자동화를 넘어 AI의 ‘지능’을 수집 단계에 투입하면, 나중에 활용할 때 만족스럽다는 것, 그리고 “이거 되나?” 싶으면 바로 테스트하는 습관이 워크플로우를 바꾼다는 것.
밑줄은 PDF 안에 갇혀 있다
논문이나 책을 읽을 때 밑줄은 열심히 친다. PDF 리더 앱(Highlights)으로 색깔별로 구분하면서 꽤 성실하게 읽는 편이다. 문제는 그 다음이다. 밑줄들을 정리하는 게 귀찮아서 계속 미루고, 어노테이션이 잔뜩 붙은 PDF만 쌓여간다.
논문을 쓸 때 “분명 그 책에서 이런 말을 했는데…” 하며 PDF를 다시 열고, 어노테이션을 하나하나 훑고, 그래도 안 나오면 다른 PDF도 열어보고. 겨우 찾으면 페이지 번호 확인하고 인용 서식을 맞추고. 읽은 건 많은데 활용률이 떨어졌다. 읽기(input)와 쓰기(output) 사이에 간극이 있었다.
”혹시 PDF에서 밑줄을 뽑을 수 있어?”
리딩을 하면서 나중에 쓸 것 같은 인용문을 정리해두고 있었다. 밑줄 친 문장을 하나하나 복사해서 붙여넣고, 페이지 번호 입력하고, 그 아래에 내 노트를 달고 있었다. 그러다가 AI 시대에 이것은 휴먼의 투머치 노가다이다 라는 판단이 들어서, Claude에게 물어봤다.
“나는 하이라이트 앱으로 PDF를 읽고 있어. 밑줄을 치고 나서 그걸 복사하고 매번 페이지 적어서 인용문을 정리하는 게 번거로워. 워크플로우 개선을 위한 제언?”
Claude가 여러 옵션을 제시했는데, 그중 하나가 “PDF 파일에서 어노테이션을 직접 읽어보겠다”는 것이었다. 바로 테스트했다.
“지금 몇 개 밑줄 쳤어. 읽어볼 수 있어?”
Claude가 PyMuPDF라는 라이브러리로 PDF를 열었고, 내가 Highlights 앱에서 친 밑줄 3개가 페이지 번호와 함께 정확히 추출됐다. 복사-붙여넣기가 한 번에 사라진 순간이었다. 이제 밑줄만 치면 된다. “리딩로그 정리해줘” 한 마디면 Claude가 PDF에서 내가 밑줄 친 부분을 전부 뽑아준다.
밑줄 색깔마다 의미가 다르다 — 6색 분류와 RGB 캘리브레이션
밑줄을 추출하는 것까지는 해결됐는데, 새로운 니즈가 생겼다. 나는 밑줄을 칠 때 색깔마다 다른 의미를 부여한다. 노란색은 일반 인용문, 주황색은 저자의 핵심 논지, 빨간색은 나한테 특히 중요한 대목. 이걸 클로드가 고려해서 인용문을 들고 와야 했다.
Claude와 함께 6색 하이라이트 분류 체계를 설계했다.
| 색상 | 의미 | Claude의 처리 |
|---|---|---|
| 노랑 | 일반 인용문 | 맥락 설명 + 태깅 |
| 주황 | 저자의 핵심 논지 | 맥락 설명 + 요점 정리 + 태깅 |
| 빨강 | 나한테 핵심 | ★ 표시 + 맥락 설명 + 요점 + 내 연구와 연결 제안 + 태깅 |
| 연두 | 사료 인용문 | 출전 자동 찾아 기입 + 태깅 |
| 청록 | 참고문헌 | 레퍼런스 리스트로 정리 + 태깅 |
실제로 구현하려니 한 가지 난관이 있었다. PDF 리더 앱마다 하이라이트 색상의 RGB 값이 다르다. “노란색”이라고 해도 앱마다 정확한 색상 코드가 다르기 때문에, 색상 분류가 제대로 되려면 캘리브레이션(색상 보정) 과정이 필요했다. Highlights 앱에서 6가지 색상을 모두 칠한 테스트 PDF를 만들고, Claude에게 각 색상의 정확한 RGB 값을 측정하게 해서 분류 정확도를 맞췄다.
인용문만 봐서는 맥락이 기억나지 않는다
밑줄 추출과 색상 분류까지 해결했지만, 또 다른 문제가 있었다. 읽은 지 한참 지나면 인용문만 봐서는 그 앞뒤 맥락이 기억나지 않는다. “저자가 왜 이 말을 했지? 어떤 흐름에서 나온 거지?” 결국 PDF를 다시 열어서 앞뒤 내용을 확인해야 한다. 이러면 리딩노트를 만든 의미가 반감된다.
내가 원한 건, PDF를 굳이 다시 열지 않고도 인용문이 등장한 맥락을 떠올릴 수 있는 것이었다. 그리고 이건 단순 자동화가 아니라 Claude의 ‘지능(Intelligence)‘으로 해결할 수 있겠다는 생각이 들었다.
처음에는 회색 하이라이트를 활용했다. 원래 리딩할 때 안 쓰던 색깔이었는데, “이 근처 맥락이 되는 문장”을 회색으로 밑줄 쳐서 Claude에게 알려주는 용도로 전환했다. 회색으로 밑줄 친 문장은 인용문으로 저장하지 않고, Claude가 맥락을 파악하는 재료로만 쓴다.
쓰다 보니 그것도 귀찮아졌다. 그래서 나중에는 회색 밑줄이 없으면 Claude가 해당 인용문이 등장하는 페이지 앞뒤를 직접 읽고 맥락을 파악하게 했다. 회색 밑줄은 “내가 특별히 맥락을 짚어주고 싶을 때”만 쓰는 선택 사항이 됐다.
결과적으로 이제 리딩노트를 읽으면, 각 인용문 위에 Claude가 작성한 간략한 배경 설명이 붙어 있다. 어차피 내가 읽은 책이니까, 짧은 설명만으로도 “아, 저자가 이런 맥락에서 이 말을 했었지” 하고 바로 떠올릴 수 있었다.
메모장에서 시작해서 도구로 진화하다
이 도구는 3주에 걸쳐 점진적으로 진화했다. 처음부터 완성된 설계가 있었던 게 아니라, 쓰면서 불편한 지점이 나올 때마다 기능을 추가하거나 변경하는 방식이었다.
**1단계: 처음에는 “리딩할 때 이렇게 해줘”라는 규칙을 텍스트 파일 하나에 적어놓고, “리딩로깅 하자”라고 말하면 Claude가 그 파일을 읽고 따라가는 방식이었다. 일종의 메뉴얼이다.
**2단계: 쓰다 보니 “세션 시작할 때 확인할 것, 색상별 처리 규칙, 태깅 방법” 등을 좀 더 체계화해서, Claude Code의 /명령어 형식으로 정리했다. “리딩로깅 해줘” 대신 /reading-session이라고 치면 정해진 절차대로 진행되는 식이다.
**3단계: 쓰다 보니 욕심이 생겼다. 이미 “문헌을 인벤토리에 등록하는 도구”, “리딩노트 파일을 생성하는 도구” 등을 따로 만들어 쓰고 있었는데, 리딩로깅을 할 때마다 이 도구들을 하나하나 따로 호출하는 게 번거로웠다. 결국 이 모든 걸 하나의 스킬로 묶어서 /readlog라는 명령어 하나로 기존 도구들과의 연동까지 포함해 전체가 돌아가게 만들었다.
/readlog PDF경로
이 한 줄이면:
- 문헌이 내 시스템 내에 등록되어 있는지 확인 (없으면 자동 등록)
- 리딩노트 파일이 있는지 확인 (없으면 자동 생성)
- 내 연구 주제와의 연결 맥락 질문
- PDF에서 하이라이트 추출 + 6색 분류
- 각 인용문에 맥락 설명 작성
- 자동 태깅 + 연구 연결 제안
- 리딩노트에 저장 + 버전 관리(Git 커밋)
까지 전부 자동으로 진행된다.
결과
| 항목 | BEFORE | AFTER |
|---|---|---|
| 정리 빈도 | 귀찮아서 미룸 → 안 함 | 밑줄만 치면 자동 정리 |
| 인용문 찾기 | PDF 여러 개 열어서 수동 검색 | 태그 검색으로 즉시 |
| 맥락 기억 | ”왜 이걸 밑줄 쳤지?” 다시 책 펼침 | 맥락 설명이 붙어 있어 바로 회상 |
| 논문 쓰기 | 인용문 찾느라 시간 허비 | ”이 주제 관련 인용문 찾아줘” → 바로 출력 → 각주 삽입 |
| 밑줄 활용도 | PDF에 갇혀 있음 | 검색·인용 가능한 마크다운 노트 |
논문 쓸 때 체감이 크다. “그 책에서 이 주제에 대해 저자가 뭐라 했는지 관련 인용문 출력해줘” → Claude가 태그와 맥락 설명을 기반으로 바로 찾아줌 → “이걸 논문에 각주로 넣어줘”로 이어지는 흐름이 가능해졌다.
다음 계획
지금까지의 리딩로그는 개별 문헌 단위 전처리를 한 것이다. 한 권의 책/논문을 읽고, 그 안의 인용문을 추출하고, 맥락을 설명하고, 태깅하는 것. 다음 단계는 이렇게 쌓인 개별 노트들을 재료로 복수 문헌을 가로지르는 메타 전처리를 하려고 한다.
- 주제별 종합분석노트: 특정 주제에 관한 여러 저자의 논문/책의 인용문을 한 곳에 모아 비교 — 누가 뭐라고 했고, 어디서 갈리는지
- 저자별 시계열 분석노트: 한 저자가 시간에 걸쳐 자신의 논지를 어떻게 다듬어갔는지 한눈에 파악
개별 문헌에 달아둔 태그와 맥락 설명이 이 메타 전처리의 재료가 될 것이다. 수집 단계에서 AI가 해둔 전처리가, 분석 단계에서 다시 한 번 AI의 재료가 되는 구조.
협업 관찰
내가 한 것: “혹시 PDF에서 밑줄을 뽑을 수 있어?”라고 가능성부터 물어보기. 불편함을 말하고, 내가 원하는 워크플로우를 전달하기. 인용문을 어떻게 관리하고 싶은지, 나중에 활용도를 높이려면 각 인용문에 무슨 정보가 붙어 있어야 하는지 생각해서 Claude에게 전달하기.
Claude가 한 것: PDF 어노테이션 추출 방법 제안(PyMuPDF), RGB 캘리브레이션 실행, 인용문 주변 텍스트를 직접 읽고 맥락 설명 작성, 자동 태깅, 연구 연결 제안, 기존 도구들을 하나의 스킬로 통합.
키는 Claude가 잡았다: 나는 너가 어디까지 할 수 있냐고 물어봤고, Claude가 제안하고, 계획하고, 실행했다. 다만, 대화 과정에서 스크립트로 돌릴 부분(추출, 색상 분류)과 AI의 지능이 투입되어야 할 부분(맥락 설명, 태깅, 연구 연결)을 구분하기를 명확히 요청한 것이 도움이 되었다.
배움 포인트
단순 자동화를 넘어 AI의 ‘지능’을 수집 단계에 투입하면, 활용 단계의 비용이 줄어든다. PDF에서 밑줄 뽑기 자체는 파이썬 코드면 된다. 여기에 맥락 설명, 태깅, 연구 연결 제안을 더한 것이 이 도구의 차별점이다. 수집 단계에서 AI가 해둔 전처리가, 논문 작성 단계에서 다시 AI의 재료가 되는 구조다.
“이거 되나?” 싶으면 바로 테스트하는 습관이 워크플로우를 바꾼다. “PDF에서 밑줄을 코드로 읽을 수 있어?”라는 질문 하나가 복사-붙여넣기를 없앴다. Claude에게 가능성을 물어보고 바로 테스트해보는 것이, 워크플로우 개선의 가장 빠른 경로였다.
처음부터 완벽한 도구를 만들 필요 없다. 읽고 쓰는 일상을 영위하는 와중에 도구를 직접 사용해가면서 다듬으면 된다. “이 색도 구분이 필요하네” 싶으면 바로 추가하고, 불편하면 바로 고치는 식으로 3주간 점진적으로 다듬었다.