왜 이 툴을 만들었나
논문 리뷰는 늘 같은 지점에서 시간을 많이 씁니다. PDF를 열고, 초록과 실험을 다시 읽고, 블로그 형식으로 맞추고, 마지막으로 GitHub 블로그 저장소에 옮기는 일이 반복됩니다. 하나씩 하면 어렵진 않지만, 매번 손이 많이 갑니다.
이번에 만든 도구는 이 반복을 줄이기 위한 작은 작업용 툴입니다. 목표는 거창한 자동 요약기가 아니라, 내가 실제로 계속 쓸 수 있는 글쓰기 보조 도구를 만드는 것이었습니다. 논문을 넣으면 바로 게시해버리는 기계가 아니라, 초안을 빠르게 만들고 사람이 손볼 위치를 분명하게 남겨주는 쪽에 더 가깝습니다.
이번 글에서 강조하고 싶은 점
이 도구를 설명할 때 특정 모델 이름을 앞세우는 건 핵심이 아니라고 느꼈습니다. 실제로 중요한 건 어떤 LLM을 붙였는가보다, 논문을 블로그 글로 바꾸는 흐름을 얼마나 다루기 좋게 잘게 나눴는가였습니다.
그래서 이 툴은 Codex가 읽고 수정하기 좋은 구조를 먼저 잡았습니다.
- 입력은
PDF,arXiv ID,arXiv URL,topic - 출력은
Jekyll 포스트,papers/index.md,assets/papers/... - 게시는 생성된 파일만 골라서
git add -> commit -> push - 긴 본문 수정은 포스트 전체를 다시 쓰기보다 섹션 단위로 보강
이렇게 해두면 Codex로 고치든, 내가 직접 고치든, 어디를 건드려야 하는지가 명확해집니다.
실제로 무슨 일을 하나
이 저장소의 CLI는 paper-blog 하나로 시작합니다. 진입점은 단순하지만, 안쪽은 역할이 꽤 또렷하게 나뉘어 있습니다.
cli.py: 어떤 작업을 할지 받는 입구pipeline.py: 추출, 초안 생성, 검수, 렌더링까지 묶는 중심 흐름render.py: 블로그 포스트와 인덱스를 Jekyll 형식으로 출력publish.py: 생성된 파일만 골라 Git으로 올리는 게시 단계
내가 특히 마음에 들었던 건 publish.py의 방식이었습니다. 저장소 전체를 한 번에 올리는 게 아니라, 방금 생성된 포스트와 인덱스만 추적해서 커밋합니다. 그래서 글 하나 올릴 때 블로그 다른 작업과 섞이지 않습니다.
사용 흐름은 어떻게 되나
실제로 쓰는 명령은 몇 개 안 됩니다.
환경이 제대로 잡혔는지 먼저 확인할 때:
paper-blog doctor특정 논문 하나를 초안으로 만들 때:
paper-blog draft --arxiv-id 2509.15753 --site-dir /path/to/Kkubuck.github.io여러 편을 큐레이션 파일로 한 번에 만들 때:
paper-blog compose --input examples/cod_top20_recent_plus_benchmarks.json --site-dir /path/to/Kkubuck.github.io이미 올라간 글의 본문을 더 길게 보강할 때:
paper-blog expand-sections --site-dir /path/to/Kkubuck.github.io --cache-dir downloads/tablecheck게시까지 한 번에 하고 싶으면 마지막에 --publish를 붙이면 됩니다.
paper-blog draft --arxiv-id 2509.15753 --site-dir /path/to/Kkubuck.github.io --publish이 정도로 인터페이스를 줄여두니, 도구가 커져도 실제 사용법은 복잡해지지 않았습니다.
Codex와 잘 맞는 이유
이번 작업을 하면서 느낀 건, Codex가 잘 도와주는 건 마법 같은 추론 자체보다도 명확한 입출력 계약이 있는 반복 작업이라는 점이었습니다. 이 도구는 그 조건에 잘 맞습니다.
예를 들어:
- 어떤 논문을 넣었을 때 포스트 파일이 어디에 생성되는지 고정돼 있고
- 인덱스 파일이 어디서 갱신되는지도 정해져 있고
- 게시 단계가 어떤 파일만 올리는지 코드에서 분명하고
- 이미 생성된 글을 다시 보강하는 경로도 따로 있습니다
이런 구조 덕분에 Codex로 작업할 때도 안정감이 있습니다. “어디를 어떻게 바꿔야 할지”가 드러나 있기 때문입니다. 그냥 거대한 스크립트 하나를 돌리는 구조였다면, 지금처럼 블로그 글 톤을 바꾸거나 게시 흐름만 따로 고치기가 훨씬 어려웠을 겁니다.
글을 만들 때 기준으로 둔 것
처음에는 그림을 자동으로 넣고, 검수 로그도 공개 포스트에 보여주는 방향까지 같이 만져봤습니다. 그런데 블로그에서 읽히는 글은 생각보다 더 단순해야 했습니다.
지금은 기준을 이렇게 잡았습니다.
- 공개 포스트에는 불필요한 내부 로그를 보이지 않음
- 글은 한국어 본문 중심으로 정리
- 논문은 섹션 구조가 살아 있도록
초록 / 서론 / 제안방법 / 실험을 분리 - 성능 비교는 이미지보다 표로 다시 적는 편이 더 읽기 좋으면 표를 우선
즉, 이 도구의 목표는 “가능한 걸 다 보여주는 것”이 아니라 “블로그 글로 읽히는 결과를 안정적으로 만드는 것”에 더 가깝습니다.
블로그와 툴 저장소를 나눈 이유
중간에 한 번 크게 방향을 바꾼 부분도 있습니다. 처음에는 블로그와 생성 툴을 한 저장소에 같이 두려고 했는데, 막상 그렇게 두니 블로그는 툴 소개 페이지처럼 보이고, 툴 저장소도 문서와 코드가 섞여서 흐릿해졌습니다.
그래서 지금은 둘을 분리했습니다.
- 블로그 저장소는 글과 페이지가 중심
- 툴 저장소는 코드와 테스트, 예시 입력이 중심
이 분리가 생각보다 중요했습니다. 블로그는 읽는 공간이고, 툴 저장소는 만드는 공간이라는 게 훨씬 선명해졌기 때문입니다.
지금 버전에서 만족하는 점
지금 버전이 완벽하진 않지만, 적어도 “논문을 읽고 블로그에 올린다”는 작업이 하나의 흐름으로 연결돼 있다는 점은 꽤 만족스럽습니다. 논문 하나를 읽고 정리하는 과정이 더는 메모, 로컬 파일, 블로그 저장소 사이에서 흩어지지 않습니다.
또 하나 좋은 점은, 이 툴이 특정 모델 홍보 문서처럼 보이지 않는다는 점입니다. 이 프로젝트의 중심은 모델이 아니라 워크플로입니다. PDF를 받아, 근거를 모으고, 글을 만들고, 블로그에 반영하는 과정 자체가 이 도구의 핵심입니다.
앞으로 더 손볼 부분
아직 남은 것도 분명합니다.
- 표 자동 재구성이 더 안정적이어야 하고
- 분야가 바뀌는 논문에도 본문 톤이 덜 흔들려야 하고
- 게시 전에 사람이 마지막으로 확인하기 좋은 프리뷰도 더 좋아질 수 있습니다
그래도 지금 시점에서는, “논문 리뷰를 블로그에 정리하는 일을 덜 번거롭게 만들어주는 도구”로서는 충분히 의미 있는 첫 버전이라고 생각합니다.