논문 PDF를 옵시디언(Obsidian)으로 옮기려는 질문에, 표·그림은 원본에서 따오는 Zotero 기반 자작 파이프라인이 공개됐다

27일 밤 9시 반을 넘기며 더배러의 대화는 학벌과 커리어 이야기에서 실무 쪽으로 옮겨 왔다. 9시 41분, 질문 하나가 올라왔다. 논문을 옵시디언 노트로 옮길 때 Zotero 플러그인으로 긁어오는 쪽과 LLM으로 md 파일을 새로 만드는 쪽 가운데 무엇이 나으냐는 물음이었다.

혹시 zotero 플러그인을 통해서 obsidian으로 노트를 긁어오는 게 글자인식률이 괜찮을까요? 아니면 같은 문서를 LLM으로 md파일을 생성하는 게 나은 방법일까요?

질문의 기준은 글자 인식률이었다. 질문을 올린 참여자는 조금 뒤 OCR과 표 인식에 Mineru pdf 같은 도구를 써도 한계가 있다고 털어놨다. 다른 도구를 먼저 써 본 뒤 나온 질문으로 보인다.

표와 그림은 새로 만들지 않는다

답은 다른 참여자가 논문 관리 프로그램 Zotero를 뼈대로 직접 만든 논문 큐레이션 시스템으로 돌아왔다. PDF를 먼저 텍스트와 이미지로 나누고, 논문 하나마다 폴더를 따로 만들어 담는다. 그래서 질의응답을 할 때 관련 figure가 함께 따라붙어 인용된다고 했다.

표와 그래프는 새로 생성하지 않고 원본에서 따오는 방식이다. 이 참여자는 시스템을 통째로 올려 뒀다며 쓰는 도구도 밝혔다.

일단 제가 만든 시스템 통으로 올려뒀으니 참고해보세요. OpenDataLoader랑 PyMuPDF 두개 + Gemini 멀티모달 기능 씁니다.

또 다른 참여자는 Docling을 추천했다. 질문 하나에 자작 시스템 전체와 대안 도구가 30여 분 만에 돌아온 셈이다.

옮겨 적기보다 원본 지키기

질문은 Zotero냐 LLM이냐의 양자택일이었지만, 돌아온 답은 PDF를 쪼개 원본 조각을 그대로 보존하는 쪽에 가까웠다. 텍스트는 뽑아 쓰되 표·그림은 다시 만들지 않는다는 원칙에는, 새로 그린 표보다 원본이 믿을 만하다는 판단이 깔린 것으로 보인다. 인식 도구의 한계를 먼저 겪은 질문자와 원본 보존을 택한 답변자가 같은 문제를 다른 쪽에서 만난 셈이다.

답변 자체도 양자택일을 비켜 갔다. 시스템은 Zotero를 뼈대로 두고 Gemini 멀티모달 기능도 함께 쓴다. 두 선택지 가운데 하나를 버리기보다 둘을 이어 붙인 절충으로 볼 수 있다.

논문을 폴더 단위로 쪼개 figure까지 함께 인용되게 한 설계는, 노트를 옮기는 일이 결국 나중에 묻고 답하기 위한 준비라는 점도 보여 준다. 같은 날 새벽 이 방에서는 한 참여자가 과제 보고서를 여러 에이전트에게 나눠 맡기고 Markdown 정본에서 hwpx 조판본을 뽑는 방식을 소개했다. 연구 문서를 md 중심으로 다루는 실무가 하루 사이 두 번 화제에 오른 셈이다.

다만 공개된 시스템의 실제 인식률이나 Docling과의 비교 결과는 이날 대화에 나오지 않았다.