[인턴] 논문만 주면 코드가 나올까 — PaperCoder(Paper2Code) 읽기 (1) 문제의식과 개요
들어가며
DIS 연구실 학부 인턴을 시작하며 처음 붙잡은 논문이 PaperCoder(원문 제목은 Paper2Code: Automating Code Generation from Scientific Papers in Machine Learning, ICLR 2026)다. LG AI Research·KAIST·DeepAuto.ai가 함께 낸 이 논문은 제목만 봐도 하려는 게 분명하다. 머신러닝 논문을 넣으면, 그 논문을 구현한 코드 레포지토리를 통째로 뽑아내겠다는 것이다.
이번 글은 논문 전체를 다 뜯기 전에, Abstract와 Introduction만 먼저 정리한다. 방법론의 세부(planning·analysis·coding 각 단계가 프롬프트로 어떻게 도는지)나 실험 결과·한계는 다음 글로 미루고, 여기서는 “이 논문이 왜 필요했고, 무엇을 하겠다고 선언했는가”만 붙잡는다. 논문 리뷰는 결국 저자가 어떤 문제 앞에 서 있었는지를 먼저 이해하는 데서 출발한다고 보기 때문이다.
1. 문제 — 논문은 있는데 코드가 없다
논문이 출발점으로 삼는 사실은 좀 답답한 현실이다. 재현성(reproducibility) 은 과학의 심장인데, 머신러닝에서 그 재현이 유독 어렵다. 문서가 불완전하고, 실험 디테일이 빠져 있고, 데이터나 도구에 접근이 안 되고, 무엇보다 코드 자체가 공개되지 않는다.
논문이 인용하는 숫자가 인상적이다. 2024년 top-tier 머신러닝 학회에 통과된 논문 중 코드 구현을 함께 공개한 비율이 평균 19.5% 에 그친다. 부록의 표를 보면 ICLR 2024가 21.2%, ICML 2024가 16.7%, NeurIPS 2024가 20.6%다. 다섯 편 중 한 편꼴로만 코드가 있다는 뜻이다.
| 학회 | 통과 논문 수 | 코드 공개 | 비율 |
|---|---|---|---|
| ICLR 2024 | 2,207 | 467 | 21.2% |
| ICML 2024 | 2,610 | 435 | 16.7% |
| NeurIPS 2024 | 4,006 | 825 | 20.6% |
| 평균 | 2,941 | 576 | 19.5% |
그래서 무슨 일이 벌어지나. 연구자들은 논문에서 방법과 실험을 역공학(reverse-engineering) 으로 되짚어 코드를 다시 짠다. 시간과 품이 엄청나게 드는 이 과정이, 결과적으로 과학 전체의 속도를 늦춘다. 문제의 뿌리는 단순하다. 논문은 있는데, 그걸 돌려 볼 코드가 없다.
2. 왜 LLM인가, 그리고 기존 접근의 한계
한편으로 최근 LLM은 자연어와 코드를 이해·생성하는 능력이 빠르게 좋아졌고, 어떤 시나리오에서는 도메인 전문가에 근접하거나 넘어서기도 한다. 이 흐름을 타고 과학 연구 워크플로를 LLM으로 가속하려는 시도들이 늘고 있다 — 새 연구 가설을 짜내는 아이디에이션 단계부터, 실험을 검증·개선하는 후반 단계까지.
그런데 논문이 짚는 핵심 빈틈이 여기 있다. 이런 기존 연구들 상당수가 “이미 존재하는 구현”에 기대고 있다는 것이다. 사전 구현된 코드베이스, 부분 코드 스니펫, 혹은 잘 정의된 API가 있다고 가정하고 그 위에서 실험을 돌린다. 1장에서 본 현실 — 코드가 애초에 없는 게 80%인 세계 — 과 정면으로 어긋난다. 구현이 없어서 힘든 건데, 구현이 있다고 전제해 버리면 정작 제일 아픈 곳을 못 건드린다.
그래서 저자들이 던지는 질문이 이렇게 벼려진다.
사전 코드도, API도, 부가 자료도 없이 오직 논문만으로 충실한(faithful) 구현을 만들어 내는 게 가능한가?
이 질문에 답하려고 만든 게 PaperCoder다.
3. PaperCoder는 무엇을 하겠다는가
PaperCoder는 멀티 에이전트 LLM 프레임워크다. 사전 구현이나 스켈레톤 코드 같은 인공물 없이, 논문 $R$ 하나를 코드 레포지토리 $C$ 로 옮기는 것을 목표로 한다. 그냥 “LLM에 논문 던지고 레포 전체를 한 번에 뱉어라”라고 시키는 순진한 방식(naive)이 왜 안 되는지도 논문은 분명히 한다. 논문은 복잡하고, 현재 모델은 롱컨텍스트에 한계가 있으며, 파일 간 의존성과 전역 구조를 일관되게 유지하기가 어렵다. 단발(single-pass) 생성으로는 감당이 안 된다.
그래서 택한 전략이 작업을 잘게 쪼개 각 단계를 전문화된 에이전트에 맡기는 것이다. 사람 개발자·연구자가 레포지토리를 짜는 전형적인 생애주기를 흉내 내, 세 단계로 나눈다.
- Planning(계획) — 무엇을 구현할지 고수준 로드맵을 세우고, 클래스·시퀀스 다이어그램으로 시스템 아키텍처를 그리고, 파일 간 의존성과 실행 순서를 정하고, 설정 파일(config)을 만든다.
- Analysis(분석) — 각 파일·함수가 정확히 무슨 일을 해야 하는지, 입출력·다른 모듈과의 상호작용·알고리즘적 제약을 파일 단위로 해석한다.
- Coding(생성) — 앞 단계에서 정해진 실행 순서에 따라, 의존성을 인지한 채 모듈식 코드를 순차 생성한다.
큰 그림만 보면 “위에서 아래로(top-down)” 다. 논문 전체를 먼저 사려 깊게 분석하고 계획을 세운 뒤에 코드를 쓴다. 뒤에 나올 실험에서 저자들은 이 top-down 성격이, 짧은 요구사항에서 출발해 부풀려 나가는 기존의 bottom-up 방식(역할극 기반이나 표준운영절차 기반)보다 낫다고 본다. 느슨하게 쓰인 긴 과학 문서를 다루는 데는 전체를 먼저 조망하는 쪽이 유리하다는 것이다. 여기까지가 Abstract·Introduction이 예고하는 방법론의 뼈대이고, 각 단계가 실제로 어떤 프롬프트로 도는지는 다음 글에서 본다.
4. 무엇으로, 어떻게 평가하겠다는가
Introduction은 검증 방식의 큰 틀도 미리 밝혀 둔다. 저자들은 ICLR·ICML·NeurIPS의 최신 논문들을 추려 Paper2CodeBench 라는 벤치마크를 새로 만들고, 최근 공개된 PaperBench 도 평가 스위트에 함께 넣는다. 그리고 평가를 세 결로 돌린다.
- 모델 기반 평가 — 저자 공개 레포가 있으면 그걸 정답으로 쓰는 reference-based, 없으면 논문만 보고 판단하는 reference-free 두 설정으로 나눈다.
- 사람 평가 — 그것도 그냥 사람이 아니라 해당 논문의 저자(제1저자) 가 직접 자기 논문의 구현들을 비교·평가한다.
Introduction이 앞세우는 결과 몇 개만 옮겨 두면 이렇다. PaperCoder가 생성한 레포의 88% 가 베이스라인 대비 최고로 평가됐고, 사람 심사자의 92% 가 “생성된 레포가 실제로 도움이 된다”고 답했다. 또 실행 오류가 나는 경우에도, 성공적으로 돌리기까지 고쳐야 하는 코드가 전체 라인의 평균 0.81% 에 불과했다고 한다. 완벽한 재현을 노린 게 아니라, 바닥부터 짜는 것보다 나은 충실한 출발점을 주는 게 목표라는 이 논문의 태도가 이 숫자들에 배어 있다.
5. 첫 글을 닫으며 — 무엇을 잡고 무엇을 남겼나
Abstract와 Introduction만 놓고 보면 이 논문의 논리는 한 줄로 꿰인다.
논문은 많은데 코드는 20%뿐이다(문제) → LLM은 코드를 잘 짜지만 기존 시도는 “이미 있는 코드”에 기댄다(빈틈) → 그러니 논문만으로 레포를 만들자, 단발 생성 말고 planning·analysis·coding 세 단계로 나눠서(제안) → 새 벤치마크와 저자 평가로 그게 통함을 보이겠다(검증).
인턴 첫 논문으로 이걸 고른 이유도 여기 있다. “재현성”이라는 큰 문제를, 데이터로 뒷받침된 문제 정의부터 시작해 명료한 설계로 좁혀 가는 흐름이 깔끔해서다. 특히 순진한 단발 생성을 왜 버렸는지, 그 대신 왜 top-down으로 계획을 먼저 세우는지가 이 논문의 핵심 판단인데, 그 판단이 실제 프롬프트와 실험에서 어떻게 살아나는지는 아직 열어 두었다.
다음 글에서는 3장 Method로 들어가, planning의 네 하위 단계(overall plan → architecture design → logic design → configuration)와 analysis·coding이 각각 어떤 프롬프트와 입력으로 도는지를 하나씩 뜯어보려 한다. 특히 아키텍처 설계만 넣었을 때 오히려 성능이 떨어졌다가 logic design이 파일 의존 순서를 잡아 주자 회복되는 대목은, “무엇을 만들지”와 “어떤 순서로 만들지”를 왜 굳이 나눴는지를 보여 주는 지점이라 눈여겨볼 생각이다.
Leave a comment