오토하이라이트: AI가 논문을 읽고 밑줄을 긋는 방법

집현전 오토하이라이트: AI가 논문을 읽고 밑줄을 긋는 방법

논문의 핵심 발견, 방법론적 한계, 숨겨진 가정을 AI가 자동으로 식별하고 구조화된 비평 코멘트를 생성하는 오토하이라이트 시스템을 구축한 이야기.

Jiphyeonjeon Team2026-03-3111 min read
오토하이라이트LLM프롬프트엔지니어링PDF논문리뷰

30페이지짜리 논문을 열었을 때 어디부터 읽어야 할지 모르는 경험은 누구에게나 있다. 형광펜으로 밑줄을 긋는 행위는 단순해 보이지만, 그 이면에는 세 가지 판단이 있다. 이 구절이 경험적 발견인지 저자의 주장인지 구분하고, 방법론적 엄밀성과 재현 가능성을 평가하며, 한계의 근본 원인과 가정 위반 시 결과가 어떻게 달라지는지를 따지는 것이다.

우리는 집현전(jiphyeonjeon.kr)에 이 과정을 자동화하는 오토하이라이트를 구현했다. 학술 피어 리뷰의 3단계 비평 구조(평가-근거-제안)를 LLM 프롬프트로 강제하여 논문을 분석하고, 핵심 구절을 추출하며, 각 구절에 구조화된 비평 코멘트를 생성하는 파이프라인이다.

Figure 1: 오토하이라이트 전체 파이프라인 아키텍처 -- 3가지 경로(Path A: 북마크 리포트, Path B: 논문별 리뷰, Path C: PDF 오버레이)가 공통 LLM 추출 엔진을 공유하는 구조

Figure 1: 오토하이라이트 전체 파이프라인 아키텍처 -- 3가지 경로(Path A: 북마크 리포트, Path B: 논문별 리뷰, Path C: PDF 오버레이)가 공통 LLM 추출 엔진을 공유하는 구조

기존 도구는 요약할 뿐 비평하지 않는다

Hypothesis, Readwise, Scholarcy 같은 서비스가 이미 논문에서 핵심 문장을 추출한다. 하지만 우리가 원한 것은 요약이 아니었다.

요약은 "이 논문은 X를 제안했고 Y라는 결과를 얻었다"를 알려준다. 비평은 "이 실험 설계에서 교란 변수 Z가 통제되지 않았고, 표본 크기가 결론의 일반화를 지지하기에 불충분하다"를 지적한다. 연구자에게 필요한 것은 후자다.

하나의 엔진, 세 가지 경로

오토하이라이트는 사용자가 논문을 접하는 세 가지 맥락에 각각 다른 파이프라인을 제공한다.

경로 입력 카테고리
Path A: 북마크 리포트 생성된 리뷰 리포트 (마크다운) 9개
Path B: 논문별 리뷰 개별 논문 리뷰 마크다운 9개
Path C: PDF 오버레이 논문 원문 PDF 텍스트 11개

세 경로 모두 GPT-4 계열 모델을 낮은 temperature로 호출하여 구조화된 JSON을 반환받는다. 각 하이라이트에는 카테고리, significance(1-5), confidence(1-5), strength/weakness 극성, 그리고 3단계 비평 코멘트가 붙는다.

왜 3단계 비평인가

이 구조는 논증의 자연스러운 흐름을 따른다. (1) Assessment -- 먼저 해당 구절이 학술적 강점인지 약점인지 판단을 선언해야 후속 근거가 방향성을 갖는다. (2) Evidence/Counter-argument -- 판단의 근거를 논문 내 다른 부분과 교차 검증하거나, 잠재적 반론을 제시한다. 근거 없는 판단은 검증이 불가능하다. (3) Constructive suggestion -- 근거가 확보된 상태에서 강점이면 확장 방향을, 약점이면 구체적 개선 방안을 제시한다. 이 순서는 학술 피어 리뷰에서 흔히 사용되는 Claim-Evidence-Reasoning(CER) 프레임워크의 변형이다. 3단계로 제한한 것은 프롬프트 준수율과의 균형 -- 4단계 이상에서는 LLM이 단계를 누락하거나 반복하는 빈도가 높아졌다.

카테고리 설계 근거

9개 기본 카테고리는 학술 논문의 논증 구조를 세 층위로 분해한 것이다. Green 톤(finding, evidence, contribution)은 논문이 "무엇을 발견/기여했는가", Blue 톤(methodology, insight, reproducibility)은 "어떻게, 왜 그렇게 했는가", Rose 톤(limitation, gap, assumption)은 "무엇이 빠졌거나 취약한가"에 해당한다. 이 분류는 ICLR/NeurIPS 등 ML 학회 리뷰 양식의 평가 축(novelty, soundness, significance)을 구절 단위로 재해석한 것이다.

리포트 경로(Path A/B)에서는 Green과 Blue가 동일한 indigo 색상으로 렌더링되어 2색(indigo + rose) 체계이고, PDF 경로(Path C)에서만 green, blue, rose, orange의 5색으로 구분된다. PDF 원문 분석 시에는 claim(저자 주장)과 experimental_setup(실험 설정) 2개가 추가되어 11개가 된다. 원문에서는 발견과 주장의 구분이 특히 중요하다 -- "정확도가 3.2% 향상되었다"는 발견이고, "이는 우리 접근법의 우월성을 입증한다"는 주장이다. 리포트에서는 이 구분이 이미 리포트 생성 단계에서 해석된 상태이므로 별도 카테고리가 불필요하다.

Figure 2: 카테고리 분류 체계와 색상 매핑 -- 개념적으로 3개 톤 11카테고리이나, 리포트 경로는 indigo+rose 2색, PDF 경로는 5색으로 시각화

Figure 2: 카테고리 분류 체계와 색상 매핑 -- 개념적으로 3개 톤 11카테고리이나, 리포트 경로는 indigo+rose 2색, PDF 경로는 5색으로 시각화

LLM이 정확히 복사하지 못하는 이유와 해결

LLM에게 "원문을 한 글자도 바꾸지 말고 복사하라"고 지시해도, 공백이 추가되거나 마크다운이 섞이는 경우가 빈번했다. 이것은 LLM이 지시를 무시해서가 아니라 동작 원리에서 비롯된다. LLM은 텍스트를 문자 단위가 아닌 토큰(subword) 단위로 처리한다. 자기회귀 생성 시 각 토큰은 확률적으로 선택되므로, "원문과 동일한 토큰을 선택할 확률이 높아지는" 것이지 결정론적 복사가 아니다. 특히 마크다운 서식 문자(**, *)는 프롬프트 자체의 서식과 충돌하여 삽입/누락 빈도가 높고, 연속 공백은 토크나이저가 정규화하는 경우가 많다.

이 불일치가 해결되지 않으면 하이라이트를 원문에 매핑할 수 없다. 우리는 3단계 폴백 매칭으로 해결했다.

Figure 3: Verbatim 매칭 3단계 폴백 흐름도 -- 정확 매칭 실패 시 공백 정규화, 마크다운 제거 순으로 시도

Figure 3: Verbatim 매칭 3단계 폴백 흐름도 -- 정확 매칭 실패 시 공백 정규화, 마크다운 제거 순으로 시도

Input:  LLM이 추출한 텍스트, 원문 report
Output: 원문에서의 매칭 위치 또는 None

Step 1 — Exact verbatim match
  excerpt가 report에 그대로 존재하면 즉시 반환

Step 2 — Whitespace-normalized match
  양쪽을 공백 정규화 후 매칭, 원문 오프셋으로 역매핑

Step 3 — Markdown-stripped match
  볼드/이탤릭/인라인 코드 제거 후 매칭
  모두 실패 시 해당 하이라이트 폐기

Step 1(정확 매칭)을 먼저 시도하고, 실패 시 Step 2-3이 순차적으로 폴백한다. Step 2의 핵심은 역매핑이다 -- 정규화된 문자열에서 매칭 위치를 찾은 뒤, 정규화 전 원문의 문자 인덱스로 되돌리는 과정이다. 공백이 여러 개 있거나 탭이 섞여 있어도 정확한 원문 구간을 추출할 수 있다.

PDF에서는 글자의 "그림"과 "의미"가 분리되어 있다

Path C는 가장 까다로운 경로다. PDF를 화면에 표시할 때 pdfjs는 두 개의 레이어를 겹친다 -- 하나는 글자의 "그림"(캔버스 렌더링)이고, 다른 하나는 글자의 "의미"(텍스트 레이어, <span> 집합)이다. 하이라이트는 텍스트 레이어의 <span>에 배경색을 입히는 방식으로 구현된다.

문제는 하나의 문장이 여러 <span>에 쪼개져 있다는 것이다. pdfjs가 폰트 변경, 줄바꿈, 글자 간 미세한 커닝 차이마다 새 <span>을 생성하기 때문이다. charToSpan 배열은 "정규화된 텍스트의 N번째 글자가 어떤 <span>에 속하는가"를 기록하는 역방향 인덱스다 -- 책의 색인이 "이 키워드는 몇 페이지에 있다"를 알려주듯, 이 매핑이 "이 글자는 어떤 DOM 요소에 있다"를 알려준다.

Figure 4: PDF 텍스트 레이어 오버레이 메커니즘 -- charToSpan 매핑을 구축하고 하이라이트 위치를 찾아 span에 색상을 입히는 과정

Figure 4: PDF 텍스트 레이어 오버레이 메커니즘 -- charToSpan 매핑을 구축하고 하이라이트 위치를 찾아 span에 색상을 입히는 과정

Step 1 — 모든 페이지의 <span>을 순회하며 정규화 텍스트(normText)와
        charToSpan[] 배열을 동시에 구축

Step 2 — 리가처 정규화: PDF 합자 문자를 ASCII로 변환
        (U+FB01 fi -> "fi", U+FB02 fl -> "fl" 등)

Step 3 — 하이라이트 텍스트를 normText에서 검색
        전체 매칭 실패 시 80%/60% 접두사로 점진 축소 매칭
        (접두사를 사용하는 이유: 문장의 시작이 끝보다 고유 식별력이 높다)

Step 4 — 매칭된 charToSpan 범위의 <span>에 backgroundColor 적용

추가 난이도는 텍스트 레이어의 동적 재생성이다. 스크롤이나 줌 변경 시 pdfjs가 레이어를 재생성하므로 하이라이트가 사라진다. MutationObserver로 DOM 변경을 감시하고 200ms 디바운스 후 재적용하며, 초기 렌더링 시 텍스트 레이어 생성을 최대 10회(500ms 간격) 폴링으로 대기한다.

긴 논문을 구조 인식으로 축약한다

학술 논문 텍스트는 수만 자에 달한다. 컨텍스트 윈도우에 들어가더라도 긴 입력의 중간 부분에서 정보를 놓치는 "lost in the middle" 문제(Liu et al., 2024)가 발생한다. 단순 트렁케이션은 논문 구조를 무시한다 -- Related Work가 전부 포함되면서 Results가 잘리는 상황이 벌어진다.

Figure 5: 구조 인식 트렁케이션 프로세스 -- 섹션 감지, 우선순위 분류, 논문 유형별 적응적 비율 적용의 3단계

Figure 5: 구조 인식 트렁케이션 프로세스 -- 섹션 감지, 우선순위 분류, 논문 유형별 적응적 비율 적용의 3단계

우리는 섹션 헤딩을 감지하고 학술적 중요도에 따라 차등 축약한다.

이 우선순위의 근거는 학술 논문의 정보 밀도 분포에 있다. Abstract는 전체 논문의 압축이므로 어떤 경우에도 잘리면 안 된다. Results/Experiments는 리뷰어가 강점/약점을 판단하는 1차 소스이므로 전문 보존한다(Priority 1). Methods는 중요하지만 재현에 필요한 세부사항이 많아 부분 보존(Priority 2)으로도 핵심 접근법 파악이 가능하다. Related Work는 선행연구 나열이 주를 이루어 최소 보존(Priority 3)한다.

논문 유형에 따라 비율을 적응시키는 이유도 여기에 있다. 이론 논문에서 Methods는 증명(proof)이 위치하는 곳이므로 잘리면 논문의 핵심을 잃는다 -- 그래서 keep_ratio를 100%로 올린다. 서베이에서는 Methods(검색 프로토콜, 선정 기준)가 일반 실증 논문보다 분석적이므로 60%를 유지한다. 트렁케이션은 LLM 호출 이전에 실행되므로, 프롬프트에서 LLM이 수행하는 4종 분류(EMPIRICAL/THEORETICAL/CLINICAL/SURVEY)와는 별도로, 코드 수준에서 키워드 기반 3종 감지(empirical/theoretical/survey)를 독립적으로 수행한다.

트렁케이션 전에 PDF 전처리가 실행된다 -- 참고문헌 섹션 제거, 반복 헤더/푸터 제거, 수학 유니코드 치환, 하이픈 줄바꿈 병합 등으로 텍스트 길이를 20-30% 줄인다.

동시성 안전과 프롬프트 제약

LLM 호출 60-120초 동안 파일을 잠그지 않는다. 만약 LLM 호출 전에 파일을 잠그고 응답까지 유지하면, 그 시간 동안 다른 모든 요청(메모 저장, 하이라이트 삭제, 다른 북마크 접근)이 블로킹된다. 3-Phase 패턴으로 이를 해결했다 -- Phase 1(락 없음)에서 데이터를 읽고 검증하고, Phase 2(락 없음)에서 LLM을 호출하며, Phase 3(~10ms 락 보유)에서 최신 상태를 다시 읽고 atomic write한다.

Phase 1에서 읽은 상태가 Phase 3에서 쓸 때 이미 변경되었을 수 있다(TOCTOU 문제). 이를 해결하기 위해 Phase 3에서 파일을 다시 읽은 뒤, 새로 생성된 하이라이트가 이미 존재하면 덮어쓰지 않고 누락된 필드(implication, confidence_level 등)만 채우는 enrichment를 수행한다. 이렇게 하면 Phase 2 동안 사용자가 수동으로 편집한 하이라이트가 보존된다.

공허한 코멘트를 프롬프트에서 억제한다. LLM에게 "비판적으로 분석하라"고만 지시하면 대부분 "This is an interesting approach"같은 공허한 칭찬을 생성한다. 우리는 금지 패턴을 명시적으로 나열하고, 대체해야 할 구체적 형식을 함께 제시한다. 카테고리 톤별로 비평 관점을 강제한다 -- Green 톤은 내적 타당도와 효과 크기를, Blue 톤은 방법론적 엄밀성을, Rose 톤은 한계의 근본 원인을 분석하도록 지시한다. 논문 본문에 없는 수치나 저자명을 포함하지 않도록 제약하여 환각(Huang et al., 2023)을 억제한다.

앞으로 해볼 것들

하이라이트 퍼시스턴스. 현재 PDF 하이라이트는 세션 내에서만 유지된다. 위치 정보를 북마크에 포함시켜 LLM 재호출 없이 즉시 복원하는 구조를 계획하고 있다.

사용자 피드백 학습. 하이라이트 삭제/수정 패턴을 수집하여 프롬프트 가중치나 significance 임계값에 반영하는 피드백 루프를 구축할 수 있다.

교차 논문 비교. 동일 북마크 내 논문들의 하이라이트를 교차 비교하여 공통 가정이나 상충하는 발견을 자동 식별하는 기능이다.

30페이지짜리 논문을 열었을 때 어디부터 읽어야 할지 모르는 문제 -- 오토하이라이트는 그 첫 번째 답이다.

참고문헌

  • Liu, N.F. et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157-173.
  • Huang, L. et al. (2023). A Survey on Hallucination in Natural Language Generation. ACM Computing Surveys, 57(1), 1-38.