RPG(Repository Planning Graph) 통일되고 확장 가능한 코드베이스 생성

RPG(Repository Planning Graph) 통일되고 확장 가능한 코드베이스 생성

1. 서론: 자동화된 소프트웨어 공학의 새로운 지평

최근 대규모 언어 모델(Large Language Models, LLM)의 발전은 소프트웨어 개발의 특정 영역, 특히 함수(function) 및 파일(file) 수준의 코드 생성에서 괄목할 만한 성과를 보여주었다.1 이러한 모델들은 주어진 명세에 따라 정교한 코드 조각을 생성하는 데 탁월한 능력을 입증하며, 개발 생산성 향상에 대한 기대를 높이고 있다. 그러나 이러한 미시적(micro-level) 성공에도 불구하고, 소프트웨어 공학의 궁극적인 목표 중 하나인 ’완전하고 일관된 소프트웨어 저장소(repository) 전체를 처음부터 생성하는 것’은 여전히 근본적인 도전 과제로 남아있다.1 이는 단순히 코드 라인의 양을 늘리는 문제가 아니라, 복잡하게 얽힌 파일, 클래스, 모듈 간의 의존성 네트워크를 체계적으로 설계하고 구현해야 하는 거시적(macro-level) 아키텍처의 문제이기 때문이다.

기존의 LLM 기반 접근법은 주로 자연어를 계획의 매개체로 사용한다. 하지만 자연어는 본질적으로 모호함과 장황함을 내포하고 있어, 복잡한 소프트웨어 구조를 충실하게 표현하는 데 한계를 드러낸다.1 장기적인 개발 과정에서 자연어 계획은 불안정한 기반이 되어, 의미가 불분명한 요구사항, 불일치하는 인터페이스, 의존성 누수, 그리고 점진적인 구조 붕괴와 같은 문제들을 야기한다.6 결과적으로 AI 에이전트는 개발 도중에 방향을 잃고, 최종 산출물은 유기적으로 연결된 시스템이 아닌, 파편화된 코드 조각들의 집합에 그치게 된다.6

이러한 배경 속에서 “RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation” 논문은 기존의 패러다임을 근본적으로 전환하는 새로운 접근법을 제시한다. 이 연구의 핵심 논지는, 저장소 수준의 코드 생성 문제는 더 나은 텍스트 생성 능력만으로는 해결할 수 없으며, 구조화되고 형식화된 계획 표현 방식이 필수적이라는 것이다. 이를 위해 본 논문은 ’저장소 계획 그래프(Repository Planning Graph, RPG)’라는 개념과 이를 구현한 ‘ZeroRepo’ 프레임워크를 제안한다. RPG는 비정형적인 자연어 계획을 기계가 해석 가능하고 결정론적인 그래프 구조로 대체하여, 소프트웨어의 고수준 기능 명세(무엇을 만들 것인가)와 저수준 구현 설계(어떻게 만들 것인가)를 단일 표현 체계로 통합한다. 본 기술 분석 보고서는 RPG와 ZeroRepo 프레임워크의 개념적 토대, 아키텍처, 작동 방식, 그리고 실험적 검증 결과를 심층적으로 분석하고, 이 기술이 자동화된 소프트웨어 공학 분야에 미치는 기술적 함의와 향후 과제를 비판적으로 고찰하고자 한다.

2. 부: 기존 코드 생성의 근본적 한계와 패러다임의 전환

대규모 언어 모델을 활용한 코드 생성의 가장 큰 난관은 개별 코드 조각의 품질이 아니라, 이들을 조합하여 하나의 일관된 시스템으로 구축하는 과정에서 발생한다. 이 문제의 근원은 계획과 구현을 매개하는 수단으로 자연어에 의존하는 기존 방식의 본질적인 결함에 있다.

자연어는 인간의 의사소통에는 효과적이지만, 복잡한 소프트웨어 시스템의 청사진 역할을 하기에는 부적합하다. 자연어는 “모호함과 장황함(ambiguity and verbosity)“이라는 태생적 한계를 가지며, 이는 소프트웨어 아키텍처의 엄밀함과 정밀성을 담보하기 어렵게 만든다.1 예를 들어, “사용자 인증 시스템 구현“이라는 자연어 계획은 모듈 간의 인터페이스, 데이터 흐름, 예외 처리 방식 등 필수적인 기술적 세부 사항을 명시하지 않는다. 이러한 불확실성은 개발의 장기적인 과정(long-horizon)에서 “불안정한 계획(shaky plan)“으로 작용하며, 다음과 같은 구체적인 문제들을 연쇄적으로 발생시킨다.6

  • 불일치하는 인터페이스 (Mismatched interfaces): 각기 다른 모듈을 생성할 때, LLM이 해석한 미묘한 의미 차이로 인해 함수 시그니처나 API 규약이 서로 맞지 않게 된다.

  • 의존성 누수 (Dependency leaks): 명시적인 의존성 관리가 부재하여, 특정 모듈이 다른 모듈의 내부 구현에 과도하게 의존하는 등 유지보수를 어렵게 만드는 구조가 형성된다.

  • 구조적 붕괴 (Crumbling structure): 프로젝트 규모가 커짐에 따라 초기 아키텍처의 일관성이 무너지고, 임시방편적인 수정이 누적되면서 전체 시스템은 “파편화된 코드 조각들의 집합(a collection of fragments)“으로 전락한다.6

이러한 문제들은 연구에서 지적하는 두 가지 주요 실패 모드(failure modes)로 구체화된다.7 첫째, **불안정한 제안 수준 계획(unstable proposal-level planning)**이다. 이는 시스템이 갖춰야 할 기능의 범위가 불완전하거나, 기능 간 중복이 발생하거나, 특정 기능에만 과도하게 치우치는 등 요구사항을 체계적으로 충족시키지 못하는 문제다. 둘째, **파편화된 구현(fragmented implementation)**이다. 지속적이고 전역적인 청사진이 없기 때문에, 각 부분을 독립적으로 생성하는 과정에서 코드의 일관성이 깨지고 의존성 관계가 무너진다.

결론적으로, 이 연구는 저장소 생성 문제를 단순한 ‘코딩’ 문제가 아닌 ‘아키텍처’ 문제로 재정의한다. 즉, LLM의 텍스트 생성 능력을 향상시키는 것만으로는 이 문제를 해결할 수 없으며, 소프트웨어의 구조와 의존성을 형식적으로 표현하고 강제할 수 있는 새로운 추상화 계층이 필요하다는 것이다. RPG는 바로 이 ’계획 표현(planning representation)’의 문제를 정면으로 다룬다. LLM을 건축가이자 건설 노동자로 동시에 활용하는 대신, RPG라는 정교한 설계도를 제공하여 LLM이 숙련된 건설 노동자의 역할에 집중하도록 만드는 패러다임의 전환을 제안하는 것이다. 이로써 문제는 ’어떻게 더 좋은 코드를 생성할 것인가’에서 ’어떻게 더 좋은 계획을 수립하고 따르게 할 것인가’로 이동하게 된다.

3. 부: RPG(Repository Planning Graph)의 개념적 토대와 아키텍처

RPG는 기존 코드 생성 방식의 근본적인 한계를 극복하기 위해 제안된 핵심 아이디어로, 소프트웨어 프로젝트의 전체 생명주기를 아우르는 구조화된 청사진 역할을 한다. 이는 단순한 데이터 구조를 넘어, AI 에이전트의 개발 프로세스 자체를 안내하고 제어하는 형식적 방법론이다.

3.1 제안(Proposal)과 구현(Implementation) 계획의 통합적 표현

소프트웨어 개발은 일반적으로 “점진적 계획(progressive planning)” 과정을 따른다. 이 과정은 크게 두 단계로 나뉜다. 첫 번째는 **제안 수준 계획(proposal-level planning)**으로, 기능적 범위와 핵심 역량을 정의하여 “무엇을 만들 것인가(what to build)“를 결정하는 단계다.7 두 번째는 **구현 수준 계획(implementation-level planning)**으로, 파일 구조, 클래스 설계, 데이터 흐름 등을 구체화하여 “어떻게 만들 것인가(how to build it)“를 결정하는 단계다.7 기존 방식에서는 이 두 단계가 분리되어 있거나, 모호한 자연어로 느슨하게 연결되어 계획의 일관성을 해치는 주된 원인이 되었다.

RPG의 가장 중요한 혁신은 이 두 가지 계획 단계를 “지속적이고 진화 가능한 단일 표현(a persistent and evolvable representation that unifies)“으로 통합한 데 있다.7 즉, 추상적인 기능 요구사항부터 구체적인 코드 구조에 이르기까지 프로젝트의 모든 정보를 하나의 그래프 안에 담아내는 것이다. 이 통합된 그래프는 모호한 자연어 문서를 대체하는 “명시적인 청사진(explicit blueprint)” 역할을 하며, 일관성 있는 장기 계획을 가능하게 하는 “간결하고 해석 가능한 기반(compact, interpretable basis)“을 제공한다.1 RPG는 프로젝트가 진행됨에 따라 점진적으로 상세화되고 확장될 수 있으므로, 초기 설계부터 최종 구현까지 일관된 단일 진실 공급원(Single Source of Truth)으로 기능한다.

3.2 RPG의 구조: 노드와 엣지를 통한 소프트웨어 청사진의 명세화

RPG는 방향성 그래프(directed graph)로, 그 구조는 소프트웨어의 기능적, 구조적 측면을 모두 명세하도록 설계되었다. 그래프의 핵심 구성요소인 노드(node)와 엣지(edge)는 각각 다음과 같은 역할을 수행한다.

3.2.1 노드(Nodes)

RPG의 노드는 계층적이면서 이중적 의미(dual-semantic)를 갖도록 설계되었다.6

  • 계층적 기능(Hierarchical Capabilities): 노드는 고수준의 기능적 요구사항(“데이터 분석 모듈”)에서부터 저수준의 구체적인 구현 단위(“calculate_mean 함수”)에 이르기까지 계층 구조를 형성한다. 이는 추상적인 기능 분해(functional decomposition)를 그래프 구조에 직접적으로 매핑한다.

  • 이중적 의미(Dual Semantics): 노드의 계층적 위치에 따라 구체적인 의미가 부여된다. 최상위 루트 노드(root nodes)는 폴더와 같은 디렉토리 구조를 나타내고, 중간 노드(intermediate nodes)는 소스 코드 파일이나 파일 그룹을, 그리고 가장 아래의 리프 노드(leaf nodes)는 개별 함수나 클래스를 명시한다. 이 구조 덕분에 추상적인 기능 설계가 물리적인 파일 시스템 레이아웃으로 자연스럽게 연결된다.

3.2.2 엣지(Edges)

엣지는 노드 간의 관계를 정의하며, 정적인 구조뿐만 아니라 동적인 상호작용과 개발 순서까지 명시한다.6

  • 의미론적 관계 및 구현 순서(Semantic Relations & Implementation Order): 엣지는 노드 간의 논리적 관계(예: 포함 관계, 상속 관계)와 개발의 선후 관계를 정의한다. 이를 통해 그래프의 위상 정렬(topological sort)이 가능해지며, 이는 곧 AI 에이전트가 따라야 할 개발 순서가 된다.

  • 데이터 흐름(Data Flows): RPG의 엣지는 단순한 의존성을 넘어 “타입이 명시된 데이터 흐름(typed data flows)“을 인코딩한다. 특히, 모듈 간 엣지(inter-module edges, 실선)는 실행 가능한 데이터의 이동(예: 데이터 로딩 모듈의 출력이 알고리즘 처리 모듈의 입력으로 사용됨)을 나타내고, 모듈 내 엣지(intra-module edges, 점선)는 파일 생성 순서나 함수 호출 관계를 나타낸다. 이는 시스템의 정적 구조뿐만 아니라 런타임 동작까지 모델링하는 핵심적인 특징이다.

이러한 구조를 통해 RPG는 단순한 파일 트리나 UML 클래스 다이어그램을 넘어선다. RPG는 그 자체로 하나의 **개발 프로세스 명세서(development process specification)**이다. 그래프의 방향성과 위상 정렬 순서는 AI 에이전트에게 무엇을, 어떤 순서로 만들고 검증해야 하는지를 명확하게 지시한다. 이는 “X 기능을 하는 저장소를 생성하라“는 선언적이고 개방된 문제를 “이 빌드 계획(RPG)을 순서대로 실행하라“는 절차적이고 결정론적인 문제로 변환시킨다.

이러한 변환은 확장성과 일관성을 달성하는 핵심 기제다. LLM은 더 이상 전체 저장소의 전역적인 상태를 컨텍스트 창 안에서 위태롭게 유지할 필요가 없다. 대신, 그래프의 현재 노드와 그 노드로 들어오는 엣지(지역적 의존성), 그리고 그 노드에서 나가는 엣지(구현해야 할 계약)에만 집중하면 된다. 이는 복잡한 소프트웨어 개발 문제에 대해 AI 에이전트가 효과적으로 ‘분할 정복(divide and conquer)’ 전략을 수행할 수 있도록 만드는 구조적 장치인 셈이다.

4. 부: ZeroRepo 프레임워크: 아이디어에서 실행 가능한 코드까지

ZeroRepo는 RPG라는 개념적 청사진을 실제 실행 가능한 코드로 변환하는 구체적인 “그래프 기반 프레임워크(graph-driven framework)“다.1 이 프레임워크는 고도로 체계화된 3단계 파이프라인을 통해, 최소한의 사용자 요구사항으로부터 복잡하고 완전한 소프트웨어 저장소를 생성해낸다. 이 과정은 잘 정립된 인간의 소프트웨어 개발 방법론을 AI 에이전트가 수행하도록 자동화한 것과 유사하다.

4.1 1단계: 제안 수준 그래프 구축 (Stage 1: Proposal-Level Graph Construction)

이 단계는 프로젝트의 초기 요구사항을 분석하고 고수준의 기능적 설계를 수행하는 과정에 해당한다.

  • 입력(Input): 프로세스는 사용자가 제공하는 “짧고 최소한의 명세(short specification)“로부터 시작된다.6 예를 들어, “표 형식 데이터를 위한 데이터 분석 라이브러리“와 같은 간결한 요구사항이 입력으로 주어진다.

  • 프로세스(Process): ZeroRepo는 이 명세를 기반으로, 150만 개 이상의 노드를 포함하는 “거대한 기능 트리(massive feature tree)“에서 관련 기능들을 검색하고 추출한다.6 이 기능 트리는 사전에 구축된 소프트웨어 기능 및 개념의 지식 베이스 역할을 한다.

  • 핵심 활동(Key Action): 이 단계의 핵심은 추출된 기능들을 논리적으로 재구성하고 관련 기능들을 모듈 단위로 그룹화하여 “높은 응집도(good cohesion)“를 갖도록 설계하는 것이다.6 예를 들어, 데이터 로딩, 필터링, 집계와 관련된 기능들을 하나의 ‘데이터 처리’ 모듈로 묶는 식의 자동화된 아키텍처 설계가 이루어진다.

  • 출력(Output): 이 단계가 끝나면 프로젝트가 구현해야 할 핵심 기능들과 그 기능들의 모듈 구조를 나타내는 추상적인 기능 그래프가 생성된다.

4.2 2단계: 구현 수준 그래프 상세화 (Stage 2: Implementation-Level Construction)

1단계에서 생성된 추상적인 기능 그래프를 구체적인 구현 계획으로 상세화하는 단계로, 소프트웨어의 상세 설계 과정에 해당한다.

  • 프로세스(Process): 기능 그래프는 파일 구조, 인터페이스, 데이터 흐름 등의 구체적인 구현 정보로 “증강(augmented)” 또는 “확장(expanded)“되어 완전한 RPG로 발전한다.6

  • 핵심 활동(Key Actions): 이 단계에서는 다음과 같은 구체적인 설계 결정들이 그래프에 인코딩된다.

  • 파일 스켈레톤 및 구조(File skeletons and structure): 각 모듈이 어떤 파일들로 구성될지, 디렉토리 구조는 어떻게 될지를 정의한다.7

  • 인터페이스 및 함수 시그니처(Interfaces and function signatures): 클래스와 함수의 이름, 파라미터, 반환 타입 등 명확한 인터페이스를 정의한다.6

  • 타입이 명시된 데이터 흐름(Typed data flows): 컴포넌트 간에 어떤 데이터가 어떤 형태로 전달되는지를 명시한다.6

  • 출력(Output): 이 단계의 결과물은 모든 구현 세부사항이 포함된 완전한 RPG다. 이 그래프 내에서는 자연스럽게 “위상적 순서(topological order)“가 나타나며, 이는 AI 에이전트에게 “무엇을 어떤 순서로 작성해야 하는지(what to write and in what sequence)“를 명확히 지시하는 실행 계획이 된다.6

4.3 3단계: 그래프 기반 코드 생성 및 테스트 주도 검증 (Stage 3: Graph-Guided Code Generation and Test-Driven Validation)

상세 설계가 완료된 RPG를 따라 실제 코드를 생성하고 검증하는 구현 단계다. 이 단계는 테스트 주도 개발(Test-Driven Development, TDD) 원칙을 충실히 따른다.

  • 프로세스(Process): ZeroRepo 프레임워크는 RPG를 “위상적 순서에 따라 순회(traverses the RPG in topological order)“하며, 의존성이 없는 노드부터 순차적으로 코드를 생성한다.7

  • 각 노드에서의 핵심 활동(Key Actions at Each Node):

  • 테스트 주도 개발(TDD): 각 리프 노드(함수 또는 클래스)에 대해, 시스템은 명세로부터 테스트 케이스를 먼저 생성한다. 그 후, 이 테스트를 통과할 때까지 코드 구현과 수정을 반복한다.9 이 과정을 통해 각 구성요소의 기능적 정확성이 원자적 수준에서 보장된다.

  • 그래프 기반 지역화 및 수정(Graph-Guided Localization and Editing): 코드 수정이나 디버깅이 필요할 때, RPG의 구조는 AI 에이전트가 변경이 필요한 코드 부분을 신속하게 찾고, 해당 변경이 어떤 의존성에 영향을 미치는지 파악하는 데 도움을 준다. 이는 개발 프로세스를 가속화하는 중요한 요소다.7

  • 검증(Validation): 단위 테스트, 회귀 테스트, 통합 테스트 등 단계적인 검증을 거쳐 모든 테스트를 통과한 코드만이 최종적으로 저장소에 반영(commit)된다.6

ZeroRepo의 3단계 파이프라인은 인간 개발팀이 사용하는 고도로 훈련된 애자일(Agile) 또는 스크럼(Scrum) 방법론을 AI 에이전트를 위해 자동화한 것과 같다. 1단계는 요구사항 수집 및 고수준 아키텍처 설계(스프린트 0), 2단계는 상세 설계 및 백로그 구체화(스프린트 계획), 그리고 3단계는 TDD를 포함한 반복적인 구현 스프린트에 해당한다. 여기서 RPG는 프로젝트 백로그, 아키텍처 설계 문서, 칸반 보드의 역할을 모두 수행하는 중심적인 산출물(artifact)이다. 따라서 ZeroRepo의 성공은 단순히 RPG라는 영리한 데이터 구조 때문만이 아니라, 자칫 혼란스러울 수 있는 LLM의 생성 과정에 입증된 소프트웨어 공학 ’프로세스’를 강제함으로써 예측 가능성과 품질을 확보했기 때문이라고 분석할 수 있다.

5. 부: RepoCraft 벤치마크를 통한 정량적 성능 검증

새로운 방법론의 우수성을 입증하기 위해서는 엄격하고 현실적인 평가 기준이 필수적이다. 이를 위해 연구팀은 기존 벤치마크의 한계를 넘어, 저장소 전체 생성 능력을 종합적으로 평가할 수 있는 ‘RepoCraft’ 벤치마크를 자체적으로 구축했다.

5.1 RepoCraft 벤치마크의 설계 철학과 의의

RepoCraft는 “장난감 수준의 설정(toy setups)“을 넘어서 실제 소프트웨어 개발의 복잡성을 반영하기 위해 설계되었다.6 기존 벤치마크들이 주로 코드 조각이나 단일 파일 생성에 초점을 맞춘 것과 달리, RepoCraft는 처음부터 끝까지(end-to-end) 완전한 저장소를 생성하는 과제를 평가한다.

  • 구성(Composition): 이 벤치마크는 널리 사용되는 6개의 실제 파이썬 프로젝트를 기반으로 총 1,052개의 태스크로 구성되어 있다. 이 프로젝트들은 scikit-learn, pandas, sympy, statsmodels, requests, django와 같은 유명 라이브러리 및 프레임워크의 아날로그(analogs)이다.8

  • 의의(Significance): 이러한 프로젝트들은 모듈화된 구조, 복잡한 의존성, 포괄적인 테스트 스위트를 갖추고 있어 “높은 수준의 엔지니어링实践(high-quality engineering practice)“을 대표한다.8 다양한 도메인(과학 컴퓨팅, 데이터 분석, 웹 프레임워크 등)을 포괄함으로써 벤치마크의 현실성과 범용성을 확보했다. 또한, LLM의 사전 학습 데이터에 포함되었을 가능성, 즉 데이터 유출(data leakage) 문제를 완화하기 위해 프로젝트의 이름과 설명을 어휘적으로 다른 형태로 의역(paraphrase)하는 조치를 취했다.8

  • 평가 기준(Evaluation Criteria): RepoCraft의 요구사항은 매우 엄격하다. AI 에이전트는 “최소한의 설명으로부터 전체 저장소를 구축하고 참조 테스트를 통과해야 한다”.6 평가는 단순히 코드 생성 여부를 넘어, 기능적 폭(functional breadth, 커버리지), 정확성(correctness, 테스트 통과율), 코드 규모(code scale), 그리고 독창성(novelty)이라는 다차원적인 지표를 통해 이루어진다.6

5.2 압도적인 성능 지표: 코드 규모, 기능 커버리지, 테스트 통과율 심층 분석

RepoCraft 벤치마크에서 ZeroRepo는 기존의 강력한 베이스라인 모델들과 비교하여 “상당한 우위(substantial lead)“를 보였다.6 주요 성능 지표를 분석하면 그 격차를 명확히 확인할 수 있다.

  • 코드 규모(Code Scale): ZeroRepo는 평균적으로 약 36,000 라인(Lines of Code, LOC)에 달하는 저장소를 생성했다. 이는 가장 강력한 베이스라인으로 평가된 Claude Code가 생성한 코드(약 9,230 라인)보다 약 3.9배, 그리고 다른 베이스라인 모델들(약 560 라인)보다는 약 64배 더 큰 규모이다.1 이는 RPG 기반 계획이 훨씬 더 크고 복잡한 소프트웨어를 체계적으로 구축할 수 있음을 시사한다.

  • 기능 커버리지(Functional Coverage): ZeroRepo는 목표 기능의 81.5%를 구현해내는 데 성공했다. 이는 Claude Code의 54.2%보다 27.3 퍼센티지 포인트(percentage points) 높은 수치로, 요구사항을 훨씬 더 포괄적으로 충족시켰음을 의미한다.1

  • 정확성 (테스트 통과율, Pass Rate): 생성된 코드의 품질을 직접적으로 나타내는 테스트 통과율에서 ZeroRepo는 69.7%를 기록했다. 이는 Claude Code의 33.9%를 35.8 퍼센티지 포인트나 상회하는 압도적인 결과다.1 이는 ZeroRepo가 단순히 많은 코드를 생성하는 것을 넘어, 실제로 작동하고 정확한 코드를 만들어낸다는 것을 증명한다.

이러한 정량적 결과들을 명확히 비교하기 위해 아래 표와 같이 정리할 수 있다.

표 1: ZeroRepo와 베이스라인 모델의 RepoCraft 벤치마크 성능 비교

지표ZeroRepoClaude Code (베이스라인)기타 베이스라인절대적 성능 향상 (vs. Claude Code)상대적 성능 향상 (vs. Claude Code)
코드 규모 (평균 LOC)~36,000~9,230~560+26,770~3.9배
기능 커버리지 (%)81.5%54.2%해당 없음+27.3 pp-
테스트 통과율 (%)69.7%33.9%해당 없음+35.8 pp-

이 표는 ZeroRepo가 코드의 양과 질 모든 측면에서 기존 최첨단 기술을 큰 폭으로 뛰어넘었음을 명백하게 보여준다. 이는 RPG라는 구조화된 계획 표현 방식이 대규모 코드 생성의 일관성과 정확성을 획기적으로 개선할 수 있다는 연구의 핵심 주장을 강력하게 뒷받침하는 경험적 증거다.

6. 부: RPG가 제시하는 핵심 기술적 이점과 함의

ZeroRepo가 RepoCraft 벤치마크에서 보여준 압도적인 정량적 성과는 RPG 접근법이 내포한 질적인 기술적 이점들에서 비롯된다. 논문의 분석 파트는 RPG가 단순한 성능 향상을 넘어, AI 기반 소프트웨어 개발의 근본적인 측면들을 어떻게 개선하는지를 심도 있게 조명한다.7

6.1 확장성 분석: 복잡도 증가에 따른 준선형적(Near-Linear) 성장

RPG의 가장 중요한 기술적 이점 중 하나는 확장성이다. 분석 결과, RPG를 사용했을 때 프로젝트에 요구되는 기능의 수나 최종 코드 라인의 양이 증가하더라도, 개발 복잡도가 “준선형적으로(near-linear)” 증가하는 것으로 나타났다.6 이는 계획에 필요한 예산이 충분하다는 전제 하에, 프로젝트의 규모가 커져도 시스템이 안정적으로 대처할 수 있음을 의미한다.

이는 “그래프가 없는 언어 전용 파이프라인(language-only pipelines without a graph)“이 복잡도가 일정 수준을 넘어서면 성능이 급격히 저하되며 “빠르게 한계에 부딪히는(quickly hit a plateau)” 것과 극명한 대조를 이룬다.6 자연어 계획은 프로젝트의 모든 구성요소와 그 관계를 하나의 거대한 텍스트 덩어리로 관리해야 하므로, 규모가 커질수록 일관성을 유지하는 비용이 기하급수적으로 증가한다. 반면, RPG는 전체 구조를 모듈화된 그래프로 표현하고, AI 에이전트는 각 시점에 그래프의 특정 부분에만 집중하면 되므로 복잡도를 효과적으로 제어할 수 있다. 이는 RPG가 진정으로 거대한 규모의 실제 산업용 저장소를 생성하기 위한 견고한 기반을 제공함을 시사한다.7

6.2 에이전트의 저장소 이해도 향상 및 개발 프로세스 가속화

RPG는 AI 에이전트에게 코드베이스의 전역적인 지도(global map)를 제공하는 역할을 한다. 이는 에이전트가 단순히 코드를 생성하는 것을 넘어, 전체 저장소의 구조를 “이해하고 탐색하는(understand and navigate)” 능력을 향상시킨다.12

논문은 지역화 로그(localization logs) 분석을 통해, RPG가 코드의 특정 부분을 찾고 수정하는 데 필요한 “검색 및 편집 단계(search and edit steps)를 30-50% 감소“시켰다고 보고한다.6 그래프 구조 덕분에 에이전트는 “어디를 봐야 할지, 어떤 의존성을 건드려야 할지, 그리고 변경 시 무엇이 깨질지(where to look, which dependencies to touch, and what will break upon changes)“를 명확히 알 수 있다.6 이는 초기 코드 생성뿐만 아니라, 이후의 유지보수 및 디버깅 과정, 즉 “에이전트 지역화(agent localization)“를 크게 가속화한다.1 결국 RPG는 LLM의 추론 과정을 코드베이스의 구조적 맥락 안에 고정시킴으로써, AI 에이전트를 더 효율적인 개발자로 만들어주는 것이다.

6.3 아키텍처 안정성, 제어된 혁신, 그리고 복잡한 의존성 모델링

RPG의 형식화된 구조는 소프트웨어 아키텍처의 품질을 보장하는 강력한 제약 조건으로 작용한다.

  • 아키텍처 무결성(Architectural Integrity): RPG는 “인터페이스를 안정화하고, 모듈 경계를 유지하며, 데이터 흐름을 정렬하는” 데 도움을 준다.6 그래프의 엣지는 모듈 간의 계약을 명시적으로 강제하여, 응집도는 높고 결합도는 낮은 바람직한 아키텍처를 유도한다.10

  • 제어된 혁신(Controlled Novelty): ZeroRepo 시스템은 단순히 기존 패턴을 복제하는 데 그치지 않는다. 분석에 따르면 생성된 기능의 약 11-13%는 새로운 독창적인 기능이었으며, 중요한 점은 이러한 새로운 기능들이 “아키텍처의 무결성을 깨뜨리지 않고(without breaking architectural integrity)” 추가되었다는 것이다.6 이는 RPG가 구조적 안정성과 창의적 기능 확장 사이의 균형을 맞추는 데 효과적임을 보여준다.

  • 복잡한 의존성 모델링(Modeling Complex Dependencies): RPG는 “모듈 간 데이터 흐름과 클래스 수준의 관계(inter-module data flows and class-level relations)“를 포함한 복잡한 의존성을 효과적으로 모델링할 수 있음이 입증되었다.7

궁극적으로 RPG 프레임워크는 소프트웨어 생성이라는 창의적 과정에 **예측 가능성(predictability)**과 **형식성(formality)**을 도입한다. 이는 AI 기반 코드 생성의 가장 큰 약점 중 하나였던 ’블랙박스’적인 예측 불가능성을 해결하는 중요한 진전이다. RPG는 “모호한 계획을 LLM과 엔지니어 모두가 동등하게 이해할 수 있는 형식적인 산출물(a formal artifact equally understood by both LLMs and engineers)“로 변환한다.6 위상적 순서, 안정적인 인터페이스, 명시적인 데이터 채널 등을 통해 확보된 예측 가능성은, RPG를 통해 생성된 코드베이스가 단순히 크거나 정확할 뿐만 아니라, 근본적으로 더 잘 **‘설계되었다(engineered)’**는 것을 의미한다. 이러한 코드베이스는 새로운 개발자(인간 또는 AI)가 참여하기 쉽고, 디버깅과 통합이 용이하며, 이는 실제 소프트웨어의 유지보수와 진화에 있어 매우 중요한 특성이다.

7. 부: 비판적 고찰 및 향후 과제

RPG와 ZeroRepo 프레임워크는 자동화된 소프트웨어 공학 분야에서 중요한 이정표를 제시했지만, 이 기술이 보편적으로 적용되기까지는 해결해야 할 내재적 한계와 현실적인 과제들이 존재한다.

7.1 시스템의 내재적 의존성과 한계

RPG 접근법은 “마법 지팡이(magic wand)“가 아니며, 그 성공은 몇 가지 중요한 전제 조건에 깊이 의존한다.6

  • 입력 품질 의존성: 시스템의 성능은 “초기 명세, 테스트, 그리고 전역 기능 트리(global feature tree)의 도메인 시나리오 커버리지 품질에 크게 의존한다”.6 만약 초기 요구사항이 불분명하거나, 제공된 테스트 스위트가 부실하거나, 기능 트리가 해당 도메인의 지식을 충분히 담고 있지 못하다면, 최종 산출물의 품질 역시 저하될 수밖에 없다.

  • 기능 트리 병목 현상: ZeroRepo의 1단계에서 활용되는 150만 개 이상의 노드를 가진 기능 트리는 이 시스템의 핵심 자산인 동시에 잠재적인 병목 지점이다. 이 거대한 지식 베이스를 구축하고, 최신 기술을 반영하여 유지보수하며, 새로운 도메인에 맞게 확장하는 것은 상당한 노력이 요구되는 비자명한(non-trivial) 과제다. 이 기능 트리의 존재 여부와 품질이 프레임워크의 적용 가능성을 결정하는 중대한 요소가 된다.

  • 도메인 특화 튜닝의 필요성: 논문에서도 언급하듯이, 복잡한 생태계에서는 “도메인 특화 튜닝과 프로젝트의 인프라 부분을 신중하게 처리하는 것“이 필요하다.6 이는 ZeroRepo를 새로운 도메인에 적용하는 것이 단순히 플러그 앤 플레이(plug-and-play) 방식으로 이루어질 수 없으며, 상당한 사전 준비와 커스터마이징이 필요함을 시사한다.

7.2 재현성 및 공개 소스 생태계에 대한 고찰

본 보고서 작성을 위해 수집된 자료들을 면밀히 검토한 결과, 연구에 사용된 ZeroRepo 프레임워크나 RepoCraft 벤치마크의 공식적인 공개 소스 저장소(GitHub repository)는 현재까지 확인되지 않았다.4

  • 명칭 혼동 문제: ‘ZeroRepo’ 또는 ’Zero’라는 이름은 다른 여러 공개 소스 프로젝트에서도 사용되고 있어 혼동의 여지가 있다. 예를 들어, SaaS 애플리케이션 보일러플레이트 생성 도구인 ‘Zero’ 14나, 본 연구와 무관한 추론(reasoning) 관련 프로젝트인 ‘Open-Reasoner-Zero’ 15 등이 존재한다. 따라서 본 논문에서 제시된 ZeroRepo는 이들과는 완전히 별개의, 비공개 프레임워크임을 명확히 인지할 필요가 있다.

  • 연구 재현성의 한계: 소스 코드와 벤치마크 데이터가 공개되지 않음으로써, 다른 연구자들이 이 연구 결과를 독립적으로 검증하거나, 제안된 방법론을 기반으로 새로운 연구를 수행하거나, 자신들의 새로운 방법을 이 최첨단(state-of-the-art) 베이스라인과 비교하는 것이 불가능하다. 이는 과학 연구의 핵심 원칙인 재현성(reproducibility) 측면에서 상당한 한계점으로 작용하며, 학계의 후속 연구 발전을 저해할 수 있다.

7.3 산업 적용 가능성과 미래 연구 방향 제언

이러한 한계에도 불구하고, 그래프 기반 계획이라는 패러다임은 산업 현장에서의 적용 가능성이 매우 높다. 특히 엔터프라이즈 소프트웨어, 임베디드 시스템, 과학 컴퓨팅 라이브러리와 같이 소프트웨어 아키텍처가 잘 정의될 수 있고, 재사용 가능한 기능 컴포넌트가 많은 도메인에서 큰 잠재력을 가질 것으로 기대된다.

이 기술을 더욱 발전시키고 실용화하기 위한 향후 연구 방향은 다음과 같이 제안될 수 있다.

  • RPG 구축 자동화: 현재는 거대한 기능 트리에 의존하는 RPG 생성 과정을, 자연어 요구사항 명세서나 UML 다이어그램과 같은 고수준의 산출물로부터 자동 또는 반자동으로 생성하는 방법에 대한 연구가 필요하다.

  • 동적 RPG 진화: 소프트웨어는 한 번 생성되고 끝나는 것이 아니라 지속적으로 변화하고 진화한다. 변화하는 요구사항과 코드 리팩토링을 처리하기 위해 RPG를 동적으로 업데이트하고 수정하는 메커니즘을 연구하여, 초기 생성을 넘어 전체 소프트웨어 생명주기에 걸쳐 RPG를 활용할 수 있도록 해야 한다.

  • 오픈소싱 노력: 연구 커뮤니티의 발전을 위해, 저자들 또는 제3의 연구 그룹이 RPG 개념의 공개 소스 구현체와 저장소 수준 생성 벤치마크를 개발하고 공유하는 노력이 절실히 요구된다. 이는 더 넓은 범위의 협력과 혁신을 촉진하는 기폭제가 될 것이다.

8. 결론: 소프트웨어 공학의 미래를 재정의하는 청사진

“RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation” 논문은 자동화된 소프트웨어 공학 분야에 중요한 전환점을 제시한다. 이 연구의 핵심 기여는 세 가지로 요약할 수 있다. 첫째, 제안과 구현 계획을 통합하는 새로운 표현 방식인 RPG의 도입. 둘째, RPG를 실제 코드로 구현하는 구체적인 프레임워크인 ZeroRepo의 개발. 셋째, 저장소 수준 생성 능력을 엄격하게 평가하기 위한 RepoCraft 벤치마크의 구축이다.7

본 연구는 대규모 코드 생성의 문제를 확률적이고 비구조적인 텍스트 합성의 영역에서, 결정론적이고 구조화된 계획 기반의 소프트웨어 엔지니어링 영역으로 이동시키는 패러다임의 전환을 성공적으로 입증했다. RPG는 모호한 자연어 지시를 명확하고 실행 가능한 아키텍처 청사진으로 대체함으로써, LLM 에이전트가 복잡한 소프트웨어를 체계적으로 구성하고 관리할 수 있는 길을 열었다.

결론적으로, RPG는 단순히 코드를 생성하기 위한 도구가 아니다. 이는 AI 에이전트가 소프트웨어를 아키텍처 수준에서 추론하고, 구축하며, 관리하는 방법에 대한 새로운 청사진이다. 이 연구는 AI의 역할이 단순한 ’코더(coder)’에서 전체 시스템을 조망하는 ’아키텍트(architect)’로 진화할 수 있는 가능성을 보여주었으며, 이는 더욱 정교하고 확장 가능한 자율적 소프트웨어 개발 도구의 등장을 예고하는 중요한 진전이라 할 수 있다.12

9. 참고 자료

  1. RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation, https://huggingface.co/papers/2509.16198
  2. RPG: A Repository Planning Graph for Unified and Scalable …, https://papers.cool/arxiv/2509.16198
  3. RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation, https://synthical.com/article/RPG%3A-A-Repository-Planning-Graph-for-Unified-and-Scalable-Codebase-Generation-7b15c31c-b0af-49ce-b197-ea4200dabf02?
  4. [2509.16198] RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation - arXiv, https://arxiv.org/abs/2509.16198
  5. RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation - Paper Detail - Deep Learning Monitor, https://deeplearn.org/arxiv/638503/rpg:-a-repository-planning-graph-for-unified-and-scalable-codebase-generation
  6. RPG for Code: How AI Assembles Entire Projects Using Graphs | by Dataism Lab - Medium, https://medium.com/@dataism/rpg-for-code-how-ai-assembles-entire-projects-using-graphs-c304ac8cf7b3
  7. RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation - arXiv, https://arxiv.org/html/2509.16198v1
  8. RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation - arXiv, https://arxiv.org/html/2509.16198v2
  9. ZeroRepo: Graph-Guided Repo Generation - Emergent Mind, https://www.emergentmind.com/topics/zerorepo-framework
  10. RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation (2509.16198v1) - Emergent Mind, https://www.emergentmind.com/papers/2509.16198
  11. RPG: A Repository Planning Graph for Unified and Scalable Codebase Generation, https://chatpaper.com/paper/189813
  12. Repository Planning Graph Enables Scalable Codebase Generation, Achieving Coherent Planning For Complete Repositories - Quantum Zeitgeist, https://quantumzeitgeist.com/repository-planning-graph-enables-scalable-codebase-generation-achieving/
  13. microsoft/repoclassbench: [ICML DMLR 2024] Repo that contains code for the paper titled: “Class-Level Code Generation from Natural Language Using Iterative, Tool-Enhanced Reasoning over Repository”. - GitHub, https://github.com/microsoft/repoclassbench
  14. commitdev/zero: Allow startup developers to ship to production on day 1 - GitHub, https://github.com/commitdev/zero
  15. Official Repo for Open-Reasoner-Zero - GitHub, https://github.com/Open-Reasoner-Zero/Open-Reasoner-Zero