[인턴] 논문만 주면 코드가 나올까 — PaperCoder(Paper2Code) 읽기 (3) 실험 — 계획은 결과로 확인됐나
들어가며
1편에서 문제의식(논문은 많은데 코드는 20%)과 큰 그림을, 2편에서 planning·analysis·coding 세 단계가 실제로 도는 방식을 봤다. 남은 질문은 하나다. 그래서 이렇게 만든 코드가 정말 쓸 만한가?
이번 글은 논문 4장(Experiment)으로 들어간다. 어떤 벤치마크로, 무엇과 비교해, 어떻게 평가했는지(4.1)부터 시작해, 주요 결과와 분석(4.2), 그리고 생성된 레포가 실제로 돌아가는지(4.3)까지 따라간다.
1. 무엇으로 재는가 — 벤치마크·베이스라인·평가 설정
1.1 데이터셋 — Paper2CodeBench와 PaperBench
저자들은 평가를 위해 Paper2CodeBench 를 새로 만든다. OpenReview API로 ICLR·ICML·NeurIPS 2024의 통과 논문을 모으고, 코드가 공개돼 있고 전체 토큰 수가 70,000 미만인 것으로 거른다(레포가 현대 LLM의 처리 한계 안에 들어오게 하려는 조건이다). 그다음 GPT-4o로 모델 기반 평가를 돌려 품질을 확보하고, 각 학회에서 상위 30편씩, 총 90편을 고른다. 사람 평가용으로 21편을 추가로 둔다.
여기에 더해, 최근 공개된 PaperBench Code-Dev(ICML 2024 논문 20편, 사람이 단 논문별 루브릭 보유)도 평가 스위트에 넣는다. 이 루브릭으로 LLM 기반 평가를 돌려 구현이 맞게 됐는지 판정한다.
1.2 베이스라인 — 비교 대상이 애초에 없다
Paper2Code는 새로운 문제라, 직접 비교할 베이스라인이 존재하지 않는다. 그래서 자연어 입력(소프트웨어 요구사항 등)으로부터 레포 수준 코드를 만드는 인접 연구들과, PaperCoder 자신의 축소 변형(ablated variants)을 함께 놓는다.
- ChatDev — 역할별 LLM 에이전트가 구조화된 대화로 협업하는 멀티 에이전트 소프트웨어 개발 프레임워크
- MetaGPT — 표준운영절차(SOP) 원칙으로 조직된 역할 기반 멀티 에이전트
- Abstract — PaperCoder의 변형. 논문 초록만 보고 구현
- Paper — 전체 논문을 쓰되 단발(one-shot) 생성
- PaperCoder (Ours) — planning·analysis·coding 세 단계 full 프레임워크
PaperBench Code-Dev에서는 벤치마크가 제안한 BasicAgent(ReAct 스타일 툴 실행)와 IterativeAgent(다음 서브태스크를 반복 지시)를 함께 쓴다.
1.3 평가 설정 — 정답이 있을 때와 없을 때, 그리고 사람
정답 코드를 사람이 일일이 다는 건 비현실적이라, 저자들은 LLM-as-a-judge 흐름을 따라 두 프로토콜을 설계한다.
- Reference-based — 저자 공개 레포가 있을 때. 그 레포를 정답으로 두고, 논문을 맥락으로 함께 넣어 생성 레포를 채점한다. 모델이 컴포넌트를 식별하고 high·medium·low 심각도로 분류한 뒤 5점 Likert로 점수를 낸다. 신뢰성을 위해 8회 샘플링해 평균낸다.
- Reference-free — 저자 공개 레포가 없을 때. 오직 논문만 보고 같은 방식으로 채점한다.
- 사람 평가 — 그냥 사람이 아니라 해당 논문의 제1저자가 직접, 여러 방식으로 생성된 구현들을 보고 순위를 매긴다.
기본 평가 모델로는 o3-mini-high를 쓴다(강한 코드 이해·추론 능력 때문). reference-based에서 레포가 컨텍스트를 넘칠 땐 gpt-4o-2024-11-20으로 관련 파일을 골라 채점한다.
2. 주요 결과 — PaperCoder가 이긴다, 그리고 얼마나
2.1 메인 결과 — 모든 베이스라인을 앞선다
Table 1이 Paper2CodeBench 메인 결과다. PaperCoder가 모든 베이스라인을 일관되게 앞선다.
| 방법 | Ref-based (ICLR/ICML/NeurIPS 평균) | Ref-free (평균) |
|---|---|---|
| ChatDev | 약 2.9 | 약 4.0 |
| MetaGPT | 약 2.7 | 약 3.6 |
| Abstract | 약 2.4 | 약 3.0 |
| Paper (단발) | 약 3.2 | 약 4.2 |
| PaperCoder | 약 3.7~3.8 | 약 4.7~4.8 |
| Oracle (저자 레포) | N/A | 약 4.8 |
저자들의 해석은 이렇다. 이 성능 차이는 PaperCoder의 top-down 성향에서 온다. 전체 논문을 먼저 사려 깊게 분석한 뒤 생성하는 방식이, 짧은 요구사항에서 출발해 부풀려 나가는 기존의 bottom-up(역할극·SOP)보다 낫다는 것이다. 느슨하게 쓰인 긴 과학 문서를 다루는 데는 전체를 먼저 조망하는 쪽이 유리하다.
더 눈에 띄는 건, 비교 불가 설정인 Oracle(저자가 직접 공개한 레포) 과 견줘도 PaperCoder가 통계적으로 유의한 차이 없이 대등한 수준이라는 점이다. 저자가 짠 구현에 근접한 품질의 코드를 만들어 낸다는 뜻이다.
2.2 Reference-free는 믿을 만한 대리 지표인가
reference-free 프로토콜은 정답 레포가 없을 때 쓰라고 만든 것인데, 이게 reference-based의 믿을 만한 대리(proxy) 인지가 관건이다. 저자들이 두 평가의 순위 상관을 재 보니 Pearson 상관계수 $r = 0.79$ 로 강한 양의 상관이 나왔다. 정답 레포가 없어도 논문만으로 하는 reference-free 평가를 하나의 독립 지표로 쓸 수 있다는 근거다.
2.3 사람 평가 — 저자들이 봐도 PaperCoder가 1등
Table 2의 사람 평가에서도 PaperCoder가 최고 순위를 차지한다. 모델 기반 평가와 결과가 일치한다. 나아가 모델 기반 평가가 사람 판단의 합당한 대리인지 확인하려고 상관을 재 보니(Table 5), reference-based·reference-free 모두 사람 점수와 강한 순위 상관을 보인다(o3-mini-high 기준 0.78, 0.73). 사람 평가의 신뢰성 자체도 Cohen’s kappa 0.79(강한 일치)로 뒷받침된다.
2.4 PaperBench Code-Dev — 다른 벤치마크에서도 최고
Table 3에서 PaperCoder는 o3-mini-high와 Claude 3.5 Sonnet 두 모델 모두에서 가장 높은 replication score를 낸다. PaperBench용으로 설계된 베이스라인들을 큰 폭으로 앞선다.
| 모델 | o3-mini-high | claude-3.5-sonnet |
|---|---|---|
| BasicAgent | 5.1 | 35.4 |
| IterativeAgent | 16.4 | 27.5 |
| PaperCoder | 45.14 | 51.14 |
부록(Table 10)을 보면 더 큰 모델일수록 좋아지는 경향이 뚜렷하다. PaperCoder(o3)는 60.86% 까지 오른다. 벤치마크와 모델을 바꿔도 일관되게 통한다는 점에서 일반화 가능성과 견고성을 보여 준다.
2.5 백본을 바꾸면 — 추론 능력이 관건
Table 4는 PaperCoder의 백본 LLM을 바꿔 본 결과다. DS-Coder, Qwen-Coder, DS-Distill-Qwen, o3-mini-high를 비교하는데, 독점 모델인 o3-mini-high가 모든 설정에서 가장 좋다. 오픈소스 중에서는 DS-Distill-Qwen이 가장 낫고, 그다음이 Qwen-Coder, DS-Coder 순이다. 강한 추론 능력을 가진 백본을 고르는 게 중요하다는 결론이고, 그래서 저자들은 기본 백본으로 o3-mini-high를 쓴다.
3. 더 파고든 분석들
3.1 계획·분석 단계를 다듬으면 더 좋아진다
2편에서 본 ablation(단계를 하나씩 쌓을수록 성능이 오르는 곡선)에 더해, 저자들은 Self-Refine 를 붙인 실험도 한다. planning·analysis 단계에 검증-및-개선(verification-and-refinement) 스텝을 넣어 30편(학회당 10편)에서 평가했더니, 각 단계의 출력이 좋아질 뿐 아니라 뒤따르는 단계의 성능까지 함께 올랐다(Table 7). 특히 config file(2.93 → 3.93)과 architecture design(3.20 → 3.96)의 개선폭이 컸다. 앞 단계를 다듬는 것이 아래로 전파되며 downstream 오류를 줄인다는 뜻이다.
3.2 어떤 컴포넌트가 잘 옮겨지나
사람 주석자에게 Data Processing·Method·Evaluation의 핵심 요소를 짚게 하고, 실제로 얼마나 구현됐는지 재 봤다(Figure 5). Method 80%, Evaluation 79% 로 커버리지가 높다. 반면 오류의 상당수는 Data Processing 에서 나온다. 논문이 데이터 형식·전처리·로딩 절차를 자주 불충분하게 명세하기 때문이다. 코드를 못 짜서가 아니라, 논문에 안 적혀 있어서 못 옮기는 것이다.
한편 최상위 레포가 “바닥부터 시작하는 것보다 재현을 쉽게 해 주는가”라는 질문엔 92%가 그렇다고 답했다. 사람들이 PaperCoder를 고른 이유는 대체로 완성도(completeness), 깔끔한 구조, 논문에 대한 충실성이었다.
3.3 논문 유형·카테고리에 따라 다르다
발표 형식으로 나눠 보면(Figure 4), oral/spotlight 논문이 poster보다 살짝 높은 점수를 받는다. 인정받은 논문일수록 글이 명료해서 충실한 코드 생성으로 이어진다는 해석이다. 카테고리별로도(Figure 13) 차이가 있어, theory·interpretability가 높고(4.21, 3.97) RL/control·dataset이 낮다(각 3.38). 부록 실험에서는 Methodology 섹션을 제거하면 점수가 4.26 → 3.75로 크게 떨어져, 정확하고 명시적인 서술이 충실한 재현에 얼마나 중요한지를 재확인한다.
4. 실제로 돌아가는가 — 실행 가능성과 재현성
논문의 초점은 “완벽한 재현”이 아니라 “바닥부터 짜는 것보다 나은 충실한 출발점” 을 주는 것이다. 그래도 얼마나 실행에 가까운지는 확인해 볼 만하다.
4.1 실행 가능성 — 평균 0.81%만 고치면 된다
다섯 편의 논문에 대해 수동 실행 평가를 했다. 실행이 실패하면 코드를 직접 디버깅·수정하고 입력 데이터를 맞춰 성공시킨다. 그 결과, 성공적으로 돌리기까지 평균 0.81%의 코드 라인만 고치면 됐다. 그것도 대부분 deprecated API 갱신이나 데이터 타입 불일치 수정 같은 사소한 것들이다.
| 레포 | 수정 라인(.py) | 전체 라인 | 비율 |
|---|---|---|---|
| CoLoR | 2 | 1132 | 0.44% |
| cognitive-behaviors | 0 | 2060 | 0.29% |
| RADA | 10 | 1609 | 1.06% |
| Self-Instruct | 26 | 1334 | 2.02% |
| G-EVAL | 10 | 1374 | 1.02% |
| 평균 | 8 | 1251.5 | 0.81% |
부록의 오류 분류(Table 13)를 보면, 가장 흔한 실패 원인은 MissingDependency·ImportError·ModuleNotFoundError다. 알고리즘·로직 오류가 아니라 환경·패키징 문제가 지배적이라는 것이다. 실제로 환경 설정을 추론·복구하는 프롬프트를 덧붙이자 의존성 관련 실패가 사라졌다고 한다. 즉 이 오류들은 프레임워크의 본질적 약점이 아니다.
4.2 재현성 — 결과까지 맞는가
한 발 더 나가, 생성된 레포가 원 논문의 결과까지 재현하는지도 본다. PaperBench 10편과 Paper2CodeBench 사람 평가 세트 10편을 뽑아, 실행 오류가 날 때만 LLM 보조 디버깅을 자동 호출해 평가했다. PaperBench에서는 result match까지 포함한 전체 루브릭으로 채점했을 때 PaperCoder가 가장 높은 점수(28.46%) 를 냈고(Table 8), Paper2CodeBench에서도 디버깅 유무와 상관없이 모든 베이스라인을 앞섰다(Figure 6).
사례 연구(Table 18)에서는 다섯 레포 중 넷이 (적어도 부분적으로) 결과를 재현했고, 하나만 손실 함수 설계 이슈로 실패했다. 그 실패조차 논문이 손실 함수를 지나치게 단순하게 서술한 데서 비롯됐다는 분석이 붙는다. 다시 한 번, 병목은 코드 생성이 아니라 논문의 명세 부족 쪽이다.
5. 시리즈를 닫으며
세 편에 걸쳐 PaperCoder를 읽었다. 문제(논문은 많은데 코드는 20%뿐) → 방법(planning·analysis·coding으로 논문만으로 레포 생성) → 결과(모든 베이스라인을 앞서고, 저자 레포와 대등하며, 평균 0.81% 라인만 고치면 실행된다)로 이어지는 논리가 한 줄로 꿰인다.
인턴 첫 논문으로 이걸 붙잡길 잘했다 싶은 지점은, 결국 이 논문이 “LLM에게 큰 문제를 어떻게 잘게 나눠 맡길 것인가” 에 대한 하나의 모범답안이라는 데 있다. 단발 생성을 버리고, 계획을 네 조각으로 쪼개고, 실행 순서를 명시적으로 잡고, 각 단계를 앞 단계에 접지시키고, “지어내지 마라”를 반복해 못 박는 규율 — 이 설계 판단들이 실험에서 하나씩 값을 증명하는 흐름이 깔끔했다.
그리고 실험이 드러낸 가장 흥미로운 사실 하나는, PaperCoder의 한계가 대체로 코드 쪽이 아니라 논문 쪽에 있다는 것이다. Data Processing에서 오류가 몰리고, Methodology를 지우면 점수가 떨어지고, 재현에 실패한 유일한 사례조차 논문의 서술 부족 탓이었다. 재현성을 높이는 길이 더 나은 코드 생성기만이 아니라 더 명확한 논문 쓰기에도 있다는 것 — 코드 생성 논문을 읽고 나서 얻은, 조금 뜻밖의 교훈이다.
Leave a comment