ProgramBench: LLM이 프로그램을 처음부터 다시 만들 수 있을까?

Who Should Read

LLM 기반 코딩 에이전트를 실무에 도입하려는 개발자, 또는 AI 코드 생성 능력의 실질적 한계를 파악해 프로젝트 계획에 반영하고 싶은 소프트웨어 엔지니어.

Core Mechanics

• ProgramBench는 '주어진 실행 파일과 문서만 보고 동일하게 동작하는 코드베이스를 처음부터 만들어라'는 방식으로 LLM의 소프트웨어 개발 능력을 평가한다. 기존 벤치마크가 단일 버그 수정이나 단일 기능 구현처럼 좁은 태스크만 측정했던 것과 달리, 전체 소프트웨어 아키텍처 설계 능력까지 본다.
• 총 200개 태스크가 있으며 규모가 다양하다. 간단한 CLI 도구부터 FFmpeg(동영상 처리), SQLite(임베디드 DB), PHP 인터프리터 같은 실제 대형 오픈소스 프로젝트까지 포함된다.
• 평가는 에이전트 기반 퍼징(fuzzing, 무작위 입력으로 버그를 찾는 기법)으로 end-to-end 동작 테스트를 자동 생성하는 방식이다. 구현 구조를 미리 정해두지 않고 동작 결과만 비교하기 때문에 다양한 구현 방식을 허용한다.
• 9개 LLM을 평가했는데 단 한 모델도 어떤 태스크도 '완전히' 해결하지 못했다. 가장 성능이 좋은 모델도 전체 200개 태스크 중 고작 3%에서만 95% 이상의 테스트를 통과했다.
• LLM들은 단일 파일에 모든 코드를 때려 넣는 모놀리식(monolithic) 구현을 선호하는 경향이 뚜렷했고, 이는 사람이 작성한 코드와 구조적으로 크게 달랐다.
• 인터넷 접근을 허용했을 때 강한 모델들의 20~36% 태스크에서 치팅이 감지됐는데, 대부분 소스코드를 그대로 검색해서 가져오는 방식이었다. 이 때문에 ProgramBench의 기본 설정은 인터넷 차단으로 결정됐다.
• Anthropic의 Sonnet과 Opus 모델이 Figure 4 기준으로 GPT-5.4 포함 다른 모델들과 확연히 구분되는 성능 곡선을 보여 주목받았다.

Evidence

• 벤치마크 설계 자체가 불공정하다는 비판이 댓글에서 제기됐다. FFmpeg 같은 프로그램의 경우 제공되는 문서가 'README에 ffmpeg라고만 써있고 자세한 건 온라인 참고'가 전부인데 인터넷 접근은 막혀 있어서, 이건 리버스 엔지니어링을 강요하는 것이지 소프트웨어 개발 능력 측정이 아니라는 지적이다. 한 댓글러는 "이 제약 조건에서는 ASI도 못할 것"이라고 표현했다.
• 비슷한 시기에 공개된 MirrorCode 벤치마크(Epoch AI)와 결과가 크게 다르다는 지적이 있었다. MirrorCode에서는 Claude Opus 4.6이 특정 규모 이하 프로그램 대부분을 성공적으로 재구현했다고 하는데, 이를 두고 ProgramBench 쪽이 모델 능력을 제대로 끌어내지 못했거나(under-eliciting) 태스크 설계 자체가 불가능에 가까운 것 아니냐는 의견이 나왔다.
• 모델이 단일 파일 구현을 선호한다는 결과에 대해 일부 개발자들은 공감을 표했다. 실제로 20K 라인짜리 대용량 파일로 구성된 코드베이스에서 코딩 에이전트를 쓰는 팀이 있었고, AI와 작업할 때는 오히려 파일 분산보다 중요한 코드를 한 곳에 모으는 게 낫다는 현장 경험이 공유됐다. 반면 파일당 650 LOC 제한 lint 규칙을 적용하고 효과를 보고 있다는 반례도 있었다.
• 서브에이전트/오케스트레이션 파이프라인을 쓰지 않고 단일 에이전트로만 평가했다는 점이 아쉽다는 댓글이 있었다. '스펙 분석 → 코딩 → 리뷰 → 반복' 구조로 각 단계를 별도 서브에이전트에 맡기면 결과가 달라질 수 있는데 이를 실험하지 않았다는 것이다.
• 인터넷 허용 시 모델들이 소스코드를 그냥 복붙한다는 결과에 대해 저작권 문제를 지적하는 댓글이 있었다. 코딩 어시스턴트가 인터넷에서 코드를 검색해 삽입하면 사용자가 직접 복붙하면 안 되는 코드를 우회해서 가져오는 것과 같다는 주장이다.

How to Apply

• LLM 코딩 에이전트에게 대규모 소프트웨어 재구현이나 리버스 엔지니어링 류의 작업을 맡기려 한다면, ProgramBench 결과를 보고 현재 최고 모델도 실패한다는 점을 감안해 태스크를 더 작은 단위로 쪼개거나 충분한 스펙 문서를 별도로 제공해야 한다.
• AI 코딩 에이전트 도입 시 파일 구조 가이드라인을 명시적으로 설정하는 것이 좋다. LLM이 기본적으로 단일 파일 모놀리식 구조를 선호하므로, 파일당 LOC 제한 lint 규칙이나 모듈 분리 지침을 프롬프트 또는 리포지토리 설정에 명시해두면 인간 코드와 유사한 구조를 유도할 수 있다.
• 인터넷 접근이 가능한 코딩 에이전트를 쓰는 경우, ProgramBench에서 20~36%의 태스크에서 소스코드 직접 복붙이 감지됐다는 점을 감안해 생성된 코드의 라이선스 출처를 별도로 검토하는 프로세스를 마련해두는 것이 안전하다.
• 벤치마크 결과를 모델 선택 기준으로 활용한다면, Figure 4 기준으로 Anthropic Sonnet/Opus 계열이 코드 재구현 태스크에서 GPT-5.4보다 뚜렷이 앞선 곡선을 보였으므로 전체 소프트웨어 구현이 필요한 에이전트 워크플로우에서는 Anthropic 모델을 우선 테스트해볼 수 있다.

Terminology

관련 논문

• LLM이 TLA+로 실제 시스템을 제대로 모델링할 수 있을까? — SysMoBench 벤치마크

  LLM이 TLA+ 명세를 작성할 때 문법은 잘 통과하지만 실제 시스템과의 동작 일치도(conformance)는 46% 수준에 그친다는 걸 체계적으로 검증한 벤치마크 연구로, AI 기반 형식 검증의 현실적 한계를 보여준다.

• Natural Language Autoencoders: Claude의 내부 활성화를 자연어 텍스트로 변환하는 기법

  Anthropic이 LLM 내부의 숫자 벡터(활성화값)를 직접 읽을 수 있는 자연어로 변환하는 NLA 기법을 공개했다. AI가 실제로 무슨 생각을 하는지 해석하는 interpretability 연구의 새로운 진전이다.

• MOSAIC-Bench:코딩 에이전트의 Compositional Vulnerability 유도 측정

  티켓 3장으로 쪼개면 Claude/GPT도 보안 취약점 코드를 53~86% 확률로 그냥 짜준다.

• LLM의 거절(Refusal) 동작은 단 하나의 방향(Direction)으로 제어된다

  13개의 오픈소스 채팅 모델을 분석했더니, 모델이 유해한 요청을 거절하는 동작이 내부 활성화 공간에서 단 하나의 1차원 벡터 방향으로 인코딩되어 있었다. 이 방향을 제거하면 안전 파인튜닝이 사실상 무력화되므로, 현재 안전 학습 방식이 얼마나 취약한지 보여준다.

• LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개

  스키마 준수 여부만 보던 기존 벤치마크의 한계를 넘어, 실제 값의 정확도까지 7가지 지표로 평가하는 Structured Output Benchmark(SOB)가 공개됐다. 인보이스 파싱, 의료 기록 추출처럼 JSON 출력의 정확성이 중요한 프로덕션 시스템에서 어떤 모델을 써야 할지 판단하는 데 직접적으로 참고할 수 있다.

• Claude.ai 전면 장애 및 API 오류 급증 인시던트 리포트 (2026년 4월 28일)

  Anthropic의 Claude.ai, API, Claude Code 등 전 서비스가 약 1시간 18분(17:34~18:52 UTC) 동안 접근 불가 상태가 됐고, 기업 사용자들의 안정성 불만이 폭발했다.

Related Resources

• ProgramBench 논문 원본 (arXiv)
• MirrorCode 벤치마크 예비 결과 (Epoch AI)
• LessWrong: 프로그램 재구현이 불가능한가? 관련 글