본문으로 건너뛰기
목록으로 돌아가기
기술
16 분

Semantic Scholar를 데이터 플랫폼으로 읽기: 논문 검색 뒤의 ID·그래프·재현성

플랫폼 논문과 실제 API 응답을 대조하며 ID 연결, 요약·임베딩의 한계, 릴리스 재현성을 정리합니다. 주간 논문 다이제스트, 근거 검색 RAG, 분석 저장소의 구현 예시도 담았습니다.

박효열 (Hyoyoul Park)
#Semantic Scholar#데이터 플랫폼#논문#RAG#API

2026-09-13 확인. Semantic Scholar에 등록된 논문의 논문을 API로 식별하고, arXiv 개정판 v2와 PDF 본문, 현재 API 명세·데이터셋 릴리스 정보를 함께 읽었다. 논문이 설명하는 시스템, 직접 확인한 응답, 이 글에서 제안하는 구현을 구분한다.

이 논문에서 가져갈 세 가지

Semantic Scholar의 중요한 자산은 검색 화면 뒤에서 문헌을 같은 식별자로 연결하고, 그 위에 기계가 활용할 특징을 쌓는 데이터 플랫폼이다. 논문을 읽고 바로 가져갈 만한 내용은 세 가지다.

  1. PDF에서 글자를 꺼내는 일과 논문·저자·인용 관계를 식별하는 일은 다른 문제다. 검색 품질의 상당 부분은 이 연결을 얼마나 잘 만드는지에 달려 있다.
  2. 요약, 인용 의도, 분야 분류, 임베딩은 서로 다른 모델이 만든 파생 데이터다. 원문 사실과 모델의 판단을 같은 신뢰도로 취급하면 안 된다.
  3. 최신 정보를 조회하는 API와 동일 시점의 분석을 재현하는 데이터셋 릴리스는 용도가 다르다. 실제 서비스에는 둘의 역할을 나눈 설계가 필요하다.

이 글은 새로운 거대언어모델의 성능을 증명하는 논문을 소개하는 것이 아니다. 여러 데이터 소스와 모델을 조합해 학술정보 기반 서비스를 운영하는 시스템·플랫폼 설명 논문을 데이터 엔지니어 관점에서 읽는다. 논문 §1–4

어떤 논문이며, 어느 버전을 읽었나

Rodney Kinney와 Semantic Scholar 팀의 The Semantic Scholar Open Data Platform은 2023년 1월 24일 처음 공개됐고, arXiv의 현재 개정 이력은 2025년 4월 25일의 v2를 가리킨다. 따라서 소개 페이지에 남은 초판 요약과 개정 본문의 수치를 섞지 않는 것이 출발점이다. arXiv 버전 이력

v2 PDF의 Table 1은 논문 노드 약 2억 2,500만 개, 저자 노드 1억 500만 개, 인용 연결 28억 개를 적고 있다. 이는 논문에 기재된 규모이며 2026년의 실시간 집계가 아니다. 표의 캡션은 2025년 5월을 기준으로 적지만, 앞쪽 본문에는 2023년 1월이라는 문장이 남아 있고 v2 제출일은 2025년 4월이다. 기준 시점 표기에 불일치가 있어 이 숫자로 정확한 성장률을 계산하지 않았다. v2 PDF, Table 1

이 불일치가 플랫폼의 존재나 구조를 부정하지는 않는다. 다만 논문·웹페이지·API에서 읽은 숫자마다 버전, 관측 시각, 집계 대상을 함께 기록해야 한다는 좋은 사례다. 저자 노드 수도 중복 해소 결과이므로 실제 연구자의 정확한 인구수와 동일시할 수 없다.

PDF가 검색 가능한 학술 그래프가 되기까지

논문의 구조를 단순화하면 다음과 같다.

출판사 · Crossref · arXiv · 웹 수집 · 사람의 정정
                         ↓
              메타데이터와 PDF 수집
                         ↓
       문자 추출 → 페이지 영역 인식 → 텍스트 역할 구분
                         ↓
         논문 중복 해소 · 저자 식별 · 인용 연결
                         ↓
       S2AG: 논문 · 저자 · 출판 장소와 그 관계
                         ↓
       TLDR · 인용 의도 · 분야 분류 · 임베딩
                         ↓
        조회·검색 API / 추천 API / 데이터셋 릴리스

이 그림은 설명을 위한 재구성이다. 실제 처리는 일부 단계가 병렬로 작동하거나 같은 입력을 공유할 수 있다. 논문은 50개 이상의 소스와 사람의 정정 데이터를 입력으로 설명하며, 전체 구성요소를 하나의 모델로 묶지 않는다. 논문 Figure 1, §3

1. PDF 추출은 문자의 역할까지 복원하는 작업이다

논문이 설명하는 추출 단계는 문자·읽기 순서 추출, 시각적 영역 인식, 텍스트 구간의 의미 분류로 나뉜다. LayoutParser와 I-VILA 등으로 본문, 제목, 저자, 표, 그림 설명, 참고문헌을 구분하고 구조화한다. 논문 §3.2

여기서 실무적으로 중요한 점은 같은 문자열이라도 위치와 역할에 따라 의미가 달라진다는 것이다. 참고문헌 속 저자 이름을 현재 논문의 저자로 잘못 읽으면 저자 그래프가 틀어진다. 표 캡션을 본문과 무관한 문장으로 나누면 검색은 성공해도 답변 근거는 약해진다. 문헌 RAG에서 무작정 글자 수로 나누기 전에 섹션과 인용 구조를 보존해야 하는 이유다.

2. 이름을 ID로 바꾸는 일이 그래프의 핵심이다

같은 논문이 arXiv와 출판사에 함께 있을 수 있고, 개정되면서 제목이 달라지기도 한다. 저자는 동명이인이 있거나 이름 표기가 다를 수 있다. 논문은 논문 중복 해소에 S2APLER, 저자 식별에 S2AND, 소속기관 정규화에 S2AFF 같은 별도의 시스템을 설명한다. 논문 §3.3

여기서 배울 설계는 “제목이 같으면 같은 논문”이라는 규칙을 넘어서는 것이다. 후보를 좁히는 blocking, 후보 쌍의 유사도 계산, 군집화가 각각 맡는 역할이 있다. 잘못 합치면 다른 연구가 사라지고, 합쳐야 할 것을 나누면 같은 연구가 추천 목록에 여러 번 나온다. 중복 제거율만 높이는 것이 목표가 될 수는 없다.

3. 요약과 임베딩은 관측 사실 위에 추가한 판단이다

파생 특징논문에서 설명하는 역할읽을 때 주의할 점
TLDR짧은 자연어 요약으로 읽을 후보를 빠르게 고른다실험 조건과 예외가 압축되므로 최종 검증을 대신하지 못한다
인용 의도배경 설명, 방법 사용, 결과 비교를 구분한다해당 논문을 지지한다는 판정이나 진실성 점수가 아니다
영향력 있는 인용인용 문맥과 특징에 기반해 중요 연결을 표시한다사람의 독립 평가와 같지 않고 분류 오류도 가능하다
분야 분류논문에 하나 이상의 연구 분야를 붙인다미분류·다중 분류를 허용해야 한다
SPECTER 계열 임베딩논문의 제목·초록과 학술 관계를 활용해 문헌을 표현한다임베딩 버전이 다르면 같은 벡터 공간이라고 가정하면 안 된다

논문은 각 특징의 모델과 관련 연구를 제시한다. 모든 기능이 최신 LLM 하나의 판단으로 만들어진다는 설명은 틀리며, 이 글도 개별 모델의 정확도를 새로 측정하지 않았다. 논문 §3.4, Table 3

현재 문서와 실제 응답에서 확인한 내용

논문 한 편을 직접 조회했다

이 글의 대상 논문을 다음 방식으로 조회했다. fields로 필요한 속성만 요청하면 응답 크기와 이후 처리 범위를 줄일 수 있다.

curl --fail-with-body --get \
  'https://api.semanticscholar.org/graph/v1/paper/cb92a7f9d9dbcf9145e32fdfa0e70e2a6b828eb1' \
  --data-urlencode 'fields=title,year,externalIds,corpusId,publicationDate,openAccessPdf'

2026-09-13 작업 중 성공한 조회에서 확인한 일부 값은 다음과 같다. 데이터 출처는 Semantic Scholar다.

{
  "paperId": "cb92a7f9d9dbcf9145e32fdfa0e70e2a6b828eb1",
  "corpusId": 256194545,
  "title": "The Semantic Scholar Open Data Platform",
  "year": 2023,
  "publicationDate": null,
  "externalIds": { "ArXiv": "2301.10140" },
  "openAccessPdf": {
    "url": "http://arxiv.org/pdf/2301.10140",
    "status": "CLOSED",
    "license": null
  }
}

이는 응답에서 선택한 필드의 기록이며, 전체 응답이나 영구적인 상태를 뜻하지 않는다. 특히 PDF 주소가 존재하지만 status는 CLOSED, license는 null이었다. 주소가 있다는 이유로 재사용 허가를 추정하거나, 이 상태값 하나로 arXiv 원문이 실제로 비공개라고 결론 내릴 수 없다. 이 논문의 원문과 라이선스는 arXiv에서 별도로 확인했다. Graph API 명세, 논문 원본과 라이선스

날짜도 마찬가지다. year: 2023에서 2023-01-01을 만들어 정확한 발행일처럼 저장하면 관측하지 않은 정보를 추가하게 된다. 연도와 일자를 별도 필드로 두고, 미확인 날짜는 그대로 남기는 편이 낫다.

조회 API와 릴리스 데이터의 차이

현재 Datasets API에서 latest를 조회했을 때 릴리스 ID는 2026-09-09였다. 목록에는 papers, paper-ids, citations, tldrs, embeddings-specter_v1, embeddings-specter_v2, s2orc, s2orc_v2 등이 있었다. s2orc_v2의 README는 이를 s2orc의 대체 데이터셋으로 설명한다. 이 관찰은 작은 릴리스 메타데이터 조회이며, 전체 데이터셋을 다운로드하거나 레코드 수를 실측한 것은 아니다. 확인한 릴리스

또한 Graph API의 문자열 paperId와 bulk 데이터의 corpus 식별자를 구분해야 한다. paper-ids는 SHA 형태 ID와 corpus ID의 연결 및 primary 여부를 제공한다. 데이터셋마다 대소문자까지 포함한 필드명이 다를 수 있으므로, 실제 스키마를 읽고 내부 표준인 corpus_id 등으로 변환한다. 서로 다른 식별자를 이름이 비슷하다는 이유로 바로 join하지 않는다.

조회 예제 파일은 논문 한 편과 릴리스 메타데이터만 읽는다. Python 표준 라이브러리를 사용하며 선택적으로 환경변수 S2_API_KEY를 받는다. 실행 결과에는 조회 시각과 고정된 릴리스 주소를 남긴다.

python3 semantic-scholar-inspect.py > observation.json

이 작업에서는 성공 응답 외에 HTTP 429도 실제로 관찰했다. 첨부 예제는 실패 시 성공 결과를 만들거나 반복 요청하지 않고 종료한다. 운영에서는 Retry-After, 제한된 backoff, 캐시와 동시성 제한을 적용한다. 공식 안내의 초기 API 키 한도는 1 RPS이며, 무인증 사용자의 공유 한도는 개인별 보장량이 아니다. API 이용 안내

어떻게 활용하면 유의미한가

예시 A: 주간 논문 다이제스트

이 블로그처럼 정기적으로 연구를 소개한다면 Semantic Scholar를 후보 발견과 메타데이터 보강에 활용할 수 있다.

관심 주제 검색·추천 → 후보 ID 저장 → DOI/arXiv 식별자 대조
                              ↓
                   이미 소개한 연구와 중복 확인
                              ↓
               원문에서 방법·결과·한계·버전 확인
                              ↓
                    선별 이유를 담아 다이제스트 작성

인용 수는 읽을 순서를 정하는 보조 신호로 쓰되, 최신 논문의 품질을 판정하는 문턱으로 쓰지 않는다. 새 논문은 인용이 쌓일 시간이 없기 때문이다. “이번 주 발표”와 “이번 주 플랫폼에서 처음 발견”도 분리한다. 논문의 publicationDate가 비어 있으면 다른 출처에서 확인하거나 날짜 미확인으로 남긴다.

기존 글과 중복을 검사할 때는 arXiv 버전 접미사를 제거한 기본 ID, DOI, S2의 ID 매핑을 함께 사용하되, 개정판을 별도 소개할 가치가 있는지도 판단한다. 이 흐름은 이 글의 제안이며 현재 블로그 자동화를 변경했다는 뜻은 아니다.

예시 B: 논문 근거를 찾아주는 RAG

S2AG는 후보 문헌과 인용 관계를 찾고, 사용 가능한 구조화 본문은 근거 구간을 찾는 데 활용할 수 있다. 구현에서 저장할 최소 단위는 “문장 텍스트”보다 조금 더 풍부해야 한다.

문헌 ID + 원문 버전 + 섹션 + 구간 위치 + 원문 URL
        + 데이터 릴리스 + 추출기/임베딩 버전

초록에서 관련 있어 보이는 문헌을 찾은 뒤 본문 근거를 확인하고, 최종 답변의 주장마다 해당 구간을 연결한다. 원문을 확보하지 못한 논문에는 초록만 확인했다는 범위를 표시한다. 전체 S2AG의 논문 수를 곧바로 사용 가능한 전문 수로 계산하지 않는다.

논문의 v2는 passage 검색에 키워드와 벡터 검색을 함께 사용하는 구조도 설명한다. 이를 참고해 모델명·방법명처럼 정확한 표기가 중요한 질의에는 키워드 검색을 유지하고, 표현이 다른 유사 주제에는 임베딩을 보완적으로 적용할 수 있다. 실제 성능 개선은 우리 질의 집합의 근거 회수율과 잘못된 출처 연결률로 검증해야 한다. 논문 §4.1

예시 C: 재현 가능한 학술 데이터 분석 저장소

장기간의 인용 그래프나 분야 변화를 분석한다면 API를 논문마다 반복 호출하는 것보다 릴리스 단위 수집이 적합하다. 논문은 전체 스냅샷과 증분 변경을 제공하는 구조를 설명하고, 현재 Datasets 명세도 변경분의 삽입·교체와 삭제를 구분한다. Datasets API

고정 release_id
  → 파일·스키마 목록 기록
  → 원본 보관
  → 내부 ID/날짜/관계 테이블로 정규화
  → 변경분 upsert + 삭제분 적용
  → 중복·연결·행 수 검사
  → 검증된 릴리스를 분석에 공개

아래 SQL은 공급자 원본 스키마가 아니라 내부 저장소 설계 예시다. 동일 릴리스에서만 인용 연결 양쪽을 대조한다.

SELECT c.citing_corpus_id, c.cited_corpus_id
FROM citations c
LEFT JOIN papers src
  ON src.release_id = c.release_id
 AND src.corpus_id = c.citing_corpus_id
LEFT JOIN papers dst
  ON dst.release_id = c.release_id
 AND dst.corpus_id = c.cited_corpus_id
WHERE c.release_id = :release_id
  AND (src.corpus_id IS NULL OR dst.corpus_id IS NULL);

결과가 있으면 원본의 미해결 참조, 수집 누락, ID 변환 오류, 릴리스 불일치 중 무엇인지 조사한다. 필터링한 일부 문헌만 보관하는 저장소라면 외부 문헌으로 향하는 연결이 정상일 수도 있으므로 무조건 오류로 삭제하지 않는다.

증분 갱신에서는 삭제를 빠뜨리지 않는 것이 중요하다. 업데이트만 계속 append하면 중복 해소로 합쳐지거나 사라진 레코드가 남아 분석이 왜곡될 수 있다. 중간 실패 뒤 같은 변경분을 다시 적용해도 같은 결과가 되도록 만들고, 모든 관련 테이블의 검증이 끝난 뒤 릴리스 체크포인트를 전진시킨다. 실시간 API로 보강한 값은 별도의 관측 시각을 기록해 고정 스냅샷 결과와 섞이지 않게 한다.

과대해석하지 말아야 할 부분

설명바로 따라오지 않는 결론
수억 편의 논문 레코드를 제공한다수억 편의 전문을 모두 내려받을 수 있다
저자와 논문의 중복을 해소한다동명이인·개정판·잘못된 병합 문제가 완전히 사라졌다
인용 수와 영향력 분류가 있다연구의 진실성이나 재현성을 평가한 점수다
요약과 임베딩을 제공한다원문 검증 없이 자동 게시해도 된다
공개 API와 데이터셋이 있다모든 본문과 파생 데이터의 이용 조건이 같다
관련 서비스와 비교한 표가 있다현재 모든 분야와 기능에서 다른 플랫폼보다 우수함을 입증했다

이 논문은 플랫폼의 구조와 제공 자원을 설명하는 데 강하지만, 전체 파이프라인에 대한 독립적인 최신 정확도 감사나 우리 서비스의 성능 보장은 아니다. 분야별 수집 범위, 언어, 초록·전문의 가용성, 인용이 축적된 기간을 확인해야 한다. 분야는 다중 분류될 수 있으므로 분야별 수를 더해 전체 논문 수를 만들지 않는다.

이용 조건도 계층을 나눠 읽어야 한다. 공식 API 약관은 API 사용 조건, 각 데이터셋의 라이선스, 포함된 제3자 원문의 조건을 별개로 다룬다. 확인한 릴리스의 papers 등은 ODC-BY를 표시하지만, 그 사실만으로 포함된 모든 전문의 재배포·상업적 이용을 일괄 허용한다고 해석해서는 안 된다. 서비스에 사용할 데이터셋 README와 원문 조건을 확인하고 Semantic Scholar 출처를 남긴다. API 라이선스, 릴리스별 README

실제로 적용한다면

작게 시작한다면 관심 분야의 대표 논문 20편을 정해 ID 연결, 날짜·초록·전문 누락, 추천의 중복부터 확인하겠다. 그다음 실제 질문 20개로 후보 검색과 근거 회수를 평가하고, 반복 조회량이 커질 때 snapshot 수집을 검토한다. 이 숫자는 논문의 실험 규모가 아니라 시작하기 위한 제안이다.

평가 기준은 단순한 수집 건수보다 동일 연구의 중복률, 잘못 연결된 ID, 날짜 미확인 비율, 원문 근거를 연결할 수 있는 비율이 유용하다. 인용 그래프 분석에는 미해결 연결과 릴리스 적용 누락을 추가한다.

이 논문은 AI 제품의 성능을 모델 선택만으로 설명하기 어렵다는 사실을 잘 보여준다. 문서를 구조화하고, 같은 대상을 같은 ID로 연결하고, 모델이 만든 특징의 출처와 버전을 보존하는 일이 검색과 추천을 실제로 쓸 만하게 만든다.

출처와 확인 범위