연구 논문에는 에이전트가 읽을 수 있는 주장 파일이 필요합니다

2026년 5월 15일, Arquimedes Canedo는 paper.json을 제안했다. 이는 연구 논문이 PDF 옆에 안정적인 주장 ID, 명시적인 범위 제한, 그림별 재현 명령, 안정적인 정의 ID를 노출할 수 있게 하는 동반 JSON 파일이다.¹

그 작은 파일은 큰 문제를 가리킨다.

연구 에이전트는 이제 논문을 읽고, 주장을 추출하고, 출처를 인용하고, 그림을 재현하고, 후속 작업을 만들고, 범위를 요약한다.¹ 산문은 여전히 인간 독자를 위한 역할을 한다. 그러나 산문만으로는 에이전트가 잘못된 하위 주장을 인용하거나, 근거를 넘어 일반화하거나, 재현 명령을 지어내거나, 기억에 의존해 정의를 다시 만드는 여지가 너무 크다.

연구 논문에는 에이전트가 읽을 수 있는 주장 파일이 필요하다. 논문은 에이전트에게 그 논문이 무엇을 주장하는지, 무엇을 주장하지 않는지, 핵심 용어가 어떻게 작동하는지, 근거가 그림과 코드에 어떻게 연결되는지를 표현하는 타입이 있는 표면을 제공해야 한다.

TL;DR

에이전트가 읽을 수 있는 주장 파일은 논문을 산문만 있는 산출물에서 논문과 주소 지정 가능한 근거 표면이 결합된 산출물로 바꾼다. PDF는 인간을 위한 객체로 남는다. 주장 파일은 에이전트에게 안정적인 ID, 범위 경계, 정의, 재현 명령을 제공한다.

paper.json 제안은 구체적인 스키마와 작동 예시 저장소로 그 필요성을 보여준다. 초안은 다섯 가지 관례를 설명한다. 안정적인 주장 ID, 명시적인 주장하지 않음 목록, 그림별 정확한 셸 명령, 손으로 작성한 JSON 파일 하나를 통한 최소 실용 준수, 안정적인 정의 ID다.¹ 동반 저장소에는 paper.json, schema.json, validator.py, resolve.py, PDF, Typst 원본이 포함되어 있다.²

더 넓은 에이전트 연구 묶음도 같은 방향을 뒷받침한다. Argus는 심층 연구를 무차별 병렬 검색이 아니라 근거 조립으로 다룬다.³ ACDL은 에이전트 맥락에 형식적 설명 언어를 제공한다.⁴ 탐색 연구는 에이전트가 행동하기 전에 검증 가능한 점검 지점이 필요하다는 점을 보여준다.⁵ 에이전트 설계 아키텍처 연구는 에이전트가 과학적 주장을 생성할 때 논문 수준 재현성의 중요성을 높인다.⁶

실용 규칙은 간단하다. 인간을 위해 산문을 공개하고, 에이전트를 위해 주장 파일을 공개하라.

핵심 요점

논문 저자를 위해: - 주장, 정의, 정리, 그림, 후속 작업에 안정적인 ID를 추가하라. - 범위 제한을 끝부분 근처에 숨긴 방어적 산문이 아니라 일급 필드로 작성하라.

검토자를 위해: - 스키마가 유효한지만 보지 말고, 기계가 읽을 수 있는 주장이 논문과 일치하는지 확인하라. - 오래되었거나 과장된 주장 파일을 인용 위험 결함으로 다루라.

연구 에이전트 제작자를 위해: - 논문을 요약, 인용, 재현하거나 그 위에 작업을 쌓기 전에 주장 파일을 가져오라. - 작업이 정확한 범위에 의존할 때 주장 ID와 정의 ID를 인용하라.

학술지와 저장소를 위해: - 저자에게 전체 플랫폼 채택을 요구하기 전에 PDF 옆에 둘 수 있는 부담이 낮은 파일을 허용하라. - 구조는 자동으로 검증하고, 의미 검토는 인간과 전문 에이전트에게 맡기라.

왜 산문 논문은 연구 에이전트에 실패하는가?

학술 산문은 근거를 서사로 압축한다.

그 서사는 인간에게 도움이 된다. 세심한 독자는 완곡한 표현을 따라가고, 절을 비교하고, 어떤 결과가 어떤 주장을 뒷받침하는지 추론하며, 논문이 어디에서 멈추는지 알아차릴 수 있다. 에이전트는 논문을 다르게 처리하는 경우가 많다. 에이전트는 시간과 맥락 제한 속에서 훑고, 나누고, 검색하고, 인용하고, 요약하고, 새 산출물을 구성한다.

이로 인해 예측 가능한 실패 양상이 생긴다.

Canedo는 이런 실패 중 여럿을 직접 지적한다. 하위 주장에는 논문 내부 인용 핸들이 부족하고, 범위 과확장은 산문 요약을 통해 지나가며, 그림 명령은 종종 논문 밖 코드 저장소에 놓인다.¹

해결책은 논문을 대체하는 것이 아니다. 해결책은 논문의 주장을 더 쉽게 주소 지정할 수 있게 하는 인터페이스를 추가하는 것이다.

주장 파일에는 무엇이 들어가야 하는가?

에이전트가 읽을 수 있는 주장 파일은 에이전트가 가장 자주 오용하는 요소를 드러내야 한다.

paper.json 작동 예시는 초안 버전, 저장소 URL, 저자 메타데이터, 초록, 주장, 범위 제외, 재현 명령, 스키마 기반 검증을 포함한다.² 그 스키마는 id, title, version, status, authors, abstract, claims, does_not_claim, reproducibility 같은 핵심 필드를 요구한다.²

구조가 진실을 증명하지는 않는다. 구조는 진실을 검토 가능하게 만든다.

이 구분은 중요하다. paper.json 파일은 검증기를 통과해도 의미적 정확성, 완전성, 그림 재현 품질을 증명할 수 없다고 명시한다.² 오래된 주장 파일은 에이전트가 지저분한 산문보다 깔끔한 필드를 더 신뢰할 수 있기 때문에 주장 파일이 없는 것보다 더 해로울 수 있다.

따라서 표준에는 두 층이 필요하다.

1. 구조 검증: 파일이 파싱되고, 필수 필드를 포함하며, 선언된 ID를 보존하는가?
2. 의미 검토: 파일이 논문을 충실하게 대표하는가?

저자는 첫 번째 층을 자동화할 수 있다. 검토자는 두 번째 층을 책임져야 한다.

안정적인 주장 ID가 왜 중요한가?

주소 지정 가능한 단위가 논문 전체뿐이면 에이전트는 너무 거칠게 인용한다.

논문에는 방법 주장, 평가 주장, 한계 주장, 벤치마크 주장, 후속 주장 등이 들어 있을 수 있다. 인간 독자는 논문을 인용하면서 어느 부분이 중요한지 설명할 수 있다. 에이전트는 그 논문 전체 인용을 모호한 권위 토큰으로 바꾸는 경우가 많다.

안정적인 주장 ID는 에이전트에게 더 작은 목표를 준다.

Canedo의 초안은 주장 ID 검색에 대한 파일럿 근거를 보고한다. 더 어려운 개념 검색 조건에서 JSON 주장을 사용한 에이전트는 평균 2점 만점에 1.20점을 받았고, 산문을 검색한 에이전트는 2점 만점에 0.60점을 받았다.² 논문은 이 결과를 대규모 증명이 아니라 파일럿 근거로 표시한다.²

그 신중함은 제안을 더 낫게 만든다. 요점은 첫 파일럿이 분야를 끝냈다고 가장하는 데 있지 않다. 요점은 저자에게 더 나은 검토 객체를 만들라고 요구하는 데 있다.

주장 ID는 검토자가 더 날카로운 질문을 하게 한다.

• 에이전트가 C1을 인용했는가, 아니면 논문 전체를 인용했는가?
• 요약이 C2의 한정 조건을 보존했는가?
• 하위 시스템이 명령을 확인하지 않고 C3 위에 구축했는가?
• 에이전트가 정의 ID를 결과 주장과 혼동했는가?

이 질문들은 “요약이 그럴듯하게 들렸는가?”보다 낫다.

왜 범위 제한에는 자체 필드가 필요한가?

한계가 산문에 숨어 있으면 에이전트는 논문을 과장하는 경우가 많다.

논문은 벤치마크가 다섯 작업을 다룬다거나, 방법이 특정 환경을 필요로 한다거나, 결과가 통제된 설정 밖으로 일반화되지 않는다고 말할 수 있다. 인간 독자는 그 뉘앙스를 붙잡을 수 있다. 에이전트 요약은 한 번 재작성한 뒤 한정 조건을 떨어뜨릴 수 있다.

명시적인 does_not_claim[] 필드는 재사용 전에 범위 제한을 보이게 만든다.

paper.json 제안은 자체 작업에 대한 여러 제외 항목을 나열한다. C1, C2, C3가 증명되었다고 주장하지 않고, 검증기가 의미적 정확성을 보장한다고 주장하지 않으며, 그 관례가 에이전트의 읽기 문제를 해결한다고 주장하지 않고, 모든 학술 메타데이터 표준과 호환된다고 주장하지 않는다.²

그 목록은 에이전트에게 유용한 것을 준다. 인용할 수 있는 경계다.

범위 필드는 평가자에게도 도움이 된다. 에이전트 요약이 “paper.json은 주장 ID가 에이전트 인용 정확도를 높인다는 것을 증명한다”라고 말하면, 평가자는 그 문장을 does_not_claim[] 필드와 비교해 과확장을 표시할 수 있다. 필드가 없으면 평가자는 산문에서 범위를 추론해야 한다.

왜 그림 명령은 주장 옆에 있어야 하는가?

재현은 종종 명령 경계에서 실패한다.

많은 논문이 저장소를 가리킨다. 정확한 그림 명령은 스크립트, Make 대상, 노트북, README 메모, 또는 명확하지 않은 위치에 있을 수 있다. 에이전트는 저장소를 검색해 그럴듯해 보이는 명령을 조립할 수 있다. 실행된 적 없는 그럴듯한 명령은 위험한 확신을 만든다.

에이전트가 읽을 수 있는 주장 파일은 재현 명령을 직접 나열해야 한다.

paper.json 작동 예시는 검증기 생성, paper.typ에 대해 paper.json 검증, Typst 논문을 PDF로 컴파일하는 명령을 포함한다.² Canedo의 초안은 JSON이 제공한 재현 명령이 저장소를 가리키는 산문 방법 절보다 그림 명령 검색을 개선했다는 파일럿 근거를 보고한다.²

명령 필드는 겸손해야 한다.

에이전트는 명령 필드를 성공으로 간주해서는 안 된다. 명령 필드는 에이전트가 실행하고, 기록하고, 보고할 목표를 제공한다.

정의는 어디에 들어가는가?

정의는 주장보다 더 큰 피해를 줄 수 있다.

잘못된 주장은 보통 한 문장에서 실패한다. 잘못된 정의는 그 용어를 쓰는 이후 모든 문장을 감염시킨다. 산문에서 정의를 재구성하는 에이전트는 논문 내부 용어처럼 들리지만 저자의 의미에서 벗어난 어휘를 만들 수 있다.

안정적인 정의 ID는 그 위험을 다룬다.

Canedo의 다섯 번째 관례는 정의에 안정적인 ID를 부여하며, 초안은 나중 재사용에서는 저자가 쓴 정의가 에이전트가 재구성한 정의보다 우선해야 한다고 주장한다.¹ 저장소의 해석기는 #C1, #D1, #T1, #F1 같은 조각 식별자를 지원하며, ID를 주장, 정의, 정리, 후속 항목에 매핑한다.²

그 장치는 하위 시스템에 중요하다.

주장 파일은 용어를 주소 지정 가능하게 만들어야 한다. 에이전트는 정의를 적용하기 전에 정의를 인용하거나 해석해야 한다.

연구 에이전트는 주장 파일을 어떻게 사용해야 하는가?

에이전트에는 읽기 절차가 필요하다.

논문을 요약하거나 인용하기 전에 연구 에이전트는 다음을 해야 한다.

1. 가능하면 논문의 주장 파일을 가져온다.
2. 파일 구조를 검증한다.
3. 요청된 주장, 정의, 그림, 정리, 후속 ID를 해석한다.
4. 작업에 실제 중요성이 있을 때 해석된 항목을 PDF와 교차 확인한다.
5. 모든 요약에서 범위 제한을 보존한다.
6. 적절한 격리 환경 안에서만 재현 명령을 실행한다.
7. 명령 출력, 누락 파일, 실패한 점검을 근거로 보고한다.
8. 주장 파일에 필요한 항목이 없을 때만 산문으로 되돌아간다.

그 절차는 검토 묶음을 만들어야 한다.

목표는 더 많은 문서 작업이 아니다. 목표는 뒷받침 없는 인용을 줄이는 것이다.

더 넓은 에이전트 연구 묶음은 어떻게 같은 방향을 가리키는가?

최근 에이전트 연구는 같은 주제로 계속 돌아온다. 에이전트에는 근거 없는 유창함이 더 필요한 것이 아니라 구조화된 근거 표면이 필요하다.

Argus는 심층 연구를 근거 조립으로 다룬다. 이 시스템은 Searcher와 Navigator를 사용하며, Navigator는 공유 근거 그래프를 추적하고 누락된 근거 조각을 향해 검색 작업을 보낸다.³ 이 설계는 논문이 에이전트가 조립할 수 있는 근거 조각을 노출해야 한다는 필요성을 강화한다.

ACDL은 맥락 설명을 목표로 한다. 저자들은 에이전트 시스템에 프롬프트와 상호작용 기록이 단계에 걸쳐 어떻게 진화하는지를 설명하는 정확하고 읽기 쉬운 언어가 필요하다고 주장한다.⁴ 주장 파일은 논문 층에서 병렬적인 일을 한다. 논문의 주장, 정의, 명령이 에이전트 맥락에 어떻게 들어가야 하는지를 설명한다.

탐색 연구는 또 다른 각도를 더한다. “Look Before You Leap”은 에이전트가 행동하기 전에 핵심 상태, 객체, 사용 가능성을 발견했는지 검증하는 지표인 Exploration Checkpoint Coverage를 소개한다.⁵ 연구 에이전트도 논문을 인용하거나 재사용하기 전에 같은 규율이 필요하다. 행동하기 전에 주장, 정의, 제한, 명령을 발견해야 한다.

AIRA는 중요도를 높인다. AIRA-Compose와 AIRA-Design 논문은 새 기반 모델 아키텍처를 제안하고 기준선 대비 하위 작업 향상을 보고하는 다중 에이전트 아키텍처 검색을 설명한다.⁶ 에이전트가 과학적 설계 주장을 생성할 수 있다면, 그런 주장을 설명하는 논문에는 기계가 읽을 수 있는 경계와 재현 고리가 필요하다.

ARIS는 전체 범주에 맞는 실패를 명명한다. 장기 실행 연구 에이전트는 근거 지원이 불완전하거나, 잘못 보고되거나, 실행자의 틀에서 물려받을 때 그럴듯하지만 뒷받침 없는 성공을 만들어낼 수 있다.⁷ 주장 파일은 연구 에이전트가 산문만으로 된 뒷받침 없는 틀을 물려받을 여지를 줄인다.

패턴은 일관된다. 진지한 연구 에이전트에는 명시적인 근거 객체가 필요하다.

저자는 지금 무엇을 공개할 수 있는가?

저자는 시작하기 위해 학술지 승인을 기다릴 필요가 없다.

첫 버전은 논문 옆에 둘 수 있다.

{
  "id": "my-paper",
  "title": "My Paper Title",
  "version": "0.1.0",
  "status": "draft",
  "repository": "https://github.com/example/my-paper",
  "claims": [
    {
      "id": "C1",
      "statement": "The method improves retrieval accuracy on benchmark X under condition Y.",
      "evidence": ["figure-2", "table-1"]
    }
  ],
  "does_not_claim": [
    "The method improves retrieval accuracy outside benchmark X."
  ],
  "definitions": [
    {
      "id": "D1",
      "term": "retrieval accuracy",
      "definition": "The percentage of queries whose top-ranked result matches the labeled answer."
    }
  ],
  "reproducibility": {
    "environment": "Python 3.11",
    "commands": ["python scripts/reproduce_figure_2.py"]
  }
}

첫 파일은 다섯 가지 질문에 답해야 한다.

1. 에이전트가 인용할 수 있는 정확한 주장은 무엇인가?
2. 에이전트가 추론을 거부해야 하는 주장은 무엇인가?
3. 어떤 정의가 안정적으로 유지되어야 하는가?
4. 어떤 명령이 근거를 재현하는가?
5. 에이전트가 읽은 주장 표면은 어느 버전인가?

그 최소값은 에이전트에게 더 안전한 출발점을 준다. 또한 논문이 바뀔 때 검토자에게 구체적인 차이를 제공한다.

검토자와 플랫폼은 무엇을 확인해야 하는가?

검토자는 유효한 JSON 파일에 형식적으로 도장만 찍어서는 안 된다.

파일을 논문과 비교해야 한다.

플랫폼은 그 작업의 일부를 자동화할 수 있다.

JSON 문법, 필수 필드, ID 형식, 중복 ID, 누락 참조, URL 도달 가능성, 명령 존재, 버전 메타데이터를 확인할 수 있다. 또한 에이전트에게 주장 파일과 산문을 비교하게 하고 인간을 위한 검토 묶음을 만들게 할 수 있다.

인간 검토가 여전히 의미를 결정한다. 자동화는 어긋남을 보이게 할 뿐이다.

표준은 무엇을 거부해야 하는가?

에이전트가 읽을 수 있는 주장 파일은 채택할 만큼 작고, 의미 있을 만큼 엄격해야 한다.

세 가지 유혹을 거부하라.

첫째, 플랫폼 의존성을 거부하라. PDF 옆의 파일 하나가 어떤 저자도 채택하지 않는 새 플랫폼보다 낫다. Canedo의 초안은 최소 실용 준수가 새 도구 체계나 플랫폼 등록이 아니라 손으로 작성한 JSON 파일 하나를 요구해야 한다고 주장한다.¹

둘째, 가짜 확실성을 거부하라. 스키마는 형태를 검증할 수 있다. 의미적 진실은 증명할 수 없다. 주장 파일은 무엇을 증명하는지, 무엇을 증명하지 않는지, 검토자가 어긋남을 어떻게 확인할 수 있는지를 말해야 한다.

셋째, 숨은 전략을 거부하라. 에이전트에는 비공개 저자 프롬프트가 아니라 근거 핸들이 필요하다. 공개 주장 파일은 주장, 정의, 제한, 명령을 노출해야 한다. 비공개 동료 검토 메모, 숨은 평가 기준표, 인증 정보, 공개되지 않은 데이터 경로를 노출해서는 안 된다.

좋은 표준은 비밀 장치를 신뢰하라고 요구하지 않으면서 모호성을 줄인다.

가치 있는 표준

가치 있는 논문은 인간 독자를 설득하는 데 그치지 않는다. 미래의 독자, 에이전트, 검토자, 제작자가 그 작업을 늘려 해석하지 않고 재사용할 방법을 제공한다.

에이전트가 읽을 수 있는 주장 파일은 논문의 경계를 더 쉽게 점검하게 만들어 논문을 더 신뢰하기 쉽게 해야 한다.

표준은 간단하다.

• 모든 중요한 주장에 주소를 부여하라.
• 모든 범위 제한에 필드를 부여하라.
• 모든 핵심 정의에 안정적인 ID를 부여하라.
• 모든 재현된 그림에 정확한 명령을 부여하라.
• 모든 에이전트가 논문을 좁게 인용할 이유를 부여하라.

연구 에이전트는 계속 논문을 읽을 것이다. 저자는 에이전트가 산문을 긁어가게 둘 수도 있고, 근거를 위해 만들어진 표면을 제공할 수도 있다.

두 번째 길은 더 나은 인용, 더 안전한 요약, 신뢰할 수 있는 닻이 없는 그럴듯한 주장의 감소를 만든다.

빠른 요약

연구 논문에는 에이전트가 읽을 수 있는 주장 파일이 필요하다. 에이전트가 이미 학술 작업을 요약하고, 인용하고, 시험하고, 재사용하기 때문이다. 산문만으로는 에이전트가 하위 주장 대신 논문 전체를 인용하고, 범위를 과장하고, 명령을 지어내고, 정의에서 벗어날 여지가 너무 크다.

paper.json은 실용적인 출발점을 제공한다. 안정적인 주장 ID, 명시적인 범위 제외, 그림별 명령, JSON 파일 하나를 통한 최소 실용 채택, 안정적인 정의 ID다.¹ 작동 저장소는 스키마 검증, 해석기, 구체적인 예시 파일을 더한다.²

가장 좋은 첫 버전은 작다. 주장, 비주장, 정의, 재현 명령, 버전 메타데이터, 저장소 링크면 된다. 파일은 논문을 대체해서는 안 된다. 논문을 에이전트가 더 안전하게 읽을 수 있게 해야 한다.

FAQ

에이전트가 읽을 수 있는 주장 파일이란 무엇인가?

에이전트가 읽을 수 있는 주장 파일은 논문 옆에 있는 구조화된 파일로, 주장, 범위 제한, 정의, 재현 명령, 관련 메타데이터를 에이전트가 검색하고 인용할 수 있는 형식으로 노출한다.

paper.json은 PDF를 대체하는가?

아니다. PDF는 인간이 읽을 수 있는 논문으로 남는다. 주장 파일은 에이전트가 논문 주장을 더 안전하게 인용하고 시험할 수 있도록 주소 지정 가능한 근거 표면을 제공한다.

paper.json은 어떤 문제를 해결하려 하는가?

paper.json은 반복되는 에이전트 읽기 실패를 겨냥한다. 잘못된 하위 주장 인용, 범위 과확장, 숨은 그림 명령, 불안정한 정의다.¹

스키마를 통과하면 주장 파일이 올바르다는 뜻인가?

아니다. 스키마는 필수 필드, ID, 구조를 검증할 수 있다. 인간 또는 전문 에이전트의 검토가 여전히 주장 파일이 논문을 충실하게 대표하는지 확인해야 한다.

저자는 무엇부터 포함해야 하는가?

저자는 안정적인 주장 ID, does_not_claim[] 절, 안정적인 정의, 정확한 재현 명령, 저장소 URL, 주장 파일 버전부터 시작해야 한다.

참고문헌