Theory of Code Space: Do Code Agents Understand Software Architecture?

이 논문은 AI 코드 에이전트가 소프트웨어 아키텍처를 이해하고 일관된 구조적 신념을 유지하는 능력을 평가하기 위해 '코드 공간 이론 (ToCS)'이라는 새로운 벤치마크를 제안하고, 에이전트의 능동적 탐색, 구조화된 신념 유지, 그리고 모델 크기에 따른 신념 안정성 등 세 가지 핵심 발견을 제시합니다.

핵심

이 논문은 **"AI 코딩 도우미들이 정말로 소프트웨어의 전체적인 구조를 이해하고 있을까?"**라는 아주 중요한 질문을 던집니다.

기존의 AI 테스트들은 "이 문장을 번역해 줘"나 "이 작은 버그를 고쳐 줘" 같은 단순한 미션만 평가했습니다. 하지만 실제 개발자는 수십 개의 파일이 서로 얽혀 있는 복잡한 프로젝트를 다룰 때, AI가 "어디에 뭐가 있는지"를 모르고 엉뚱한 코드를 짜는 경우가 많다고 호소합니다.

저자는 이 문제를 해결하기 위해 **'TOCS (코드 공간 이론)'**라는 새로운 시험을 만들었습니다. 이 시험을 쉽게 비유해서 설명해 드릴게요.

---

🗺️ 비유: "어둠 속에서 지도 그리기"

상상해 보세요. 여러분이 완전히 어두운 방에 갇혔습니다. 이 방은 거대한 도서관처럼 수많은 책장 (파일) 이 있고, 책장 사이에는 보이지 않는 연결고리 (의존성) 가 있습니다.

1. 과제: 여러분은 이 방의 정확한 지도를 그려야 합니다.
2. 제한 조건:
   • 한 번에 모든 책장을 볼 수 없습니다. (부분 관측성)
   • 책장을 하나씩 열어볼 수 있지만, 한정된 횟수만 허용됩니다. (예산)
   • 책장을 열 때마다, AI 는 **"지금까지 본 것을 바탕으로 방의 구조를 어떻게 이해했는지"**를 종이에 적어내야 합니다. (신념 상태 외부화)
3. 목표: 방을 다 돌아다닌 후, 그리는 지도가 실제 방의 구조와 얼마나 일치하는지 확인합니다.

이 논문은 바로 이 과정을 통해 AI 가 '지도'를 그리는 능력을 평가합니다.

---

🔍 놀라운 발견 3 가지

이 시험을 4 가지 기본 전략과 6 가지 최신 AI 모델 (GPT, Claude, Gemini 등) 에게 시켰더니, 예상치 못한 세 가지 결과가 나왔습니다.

1. "혼자서 탐험하는 것 vs 모두 보여주기" (Active-Passive Gap)

• 상황: 어떤 AI 는 혼자서 하나씩 책장을 찾아다니며 (Active) 지도를 그리는 게 더 잘하고, 어떤 AI 는 처음부터 모든 책장을 한눈에 보여줘서 (Passive) 지도를 그리는 게 더 잘했습니다.
• 비유: 어떤 학생은 혼자서 미로 속을 헤매며 길을 찾는 게 더 잘하고, 어떤 학생은 미로 지도를 처음부터 다 보여주고 길을 찾는 게 더 잘하는 것과 같습니다.
• 의미: "혼자서 탐험하는 능력" 자체가 AI 모델마다 천차만별이라는 뜻입니다. 모든 AI 가 똑같이 잘하는 게 아닙니다.

2. "메모지를 계속 보는 것의 효과" (Self-Scaffolding)

• 상황: AI 가 그리는 지도 (메모) 를 계속 기억하게 해주는지, 아니면 지우고 새로 쓰게 하는지에 따라 결과가 달랐습니다.
• 비유: 어떤 AI 는 이전 메모를 계속 보고 다음 단계를 계획하면 훨씬 똑똑해지지만 (GPT), 어떤 AI 는 메모를 계속 보여줘도 전혀 도움이 안 되거나 오히려 혼란스러워합니다 (Gemini).
• 의미: AI 가 자신의 이전 생각을 "스스로 가르치는 도구"로 쓸 수 있는지는 모델마다 다릅니다.

3. "작은 AI 가 더 기억력이 좋다?" (Belief State Instability)

• 상황: 가장 놀라운 점은 작은 모델이 중간중간 그리는 지도를 완벽하게 기억하는 반면, 더 크고 강력한 모델은 중간에 갑자기 "아까 본 건 뭐였지?" 하며 이전 정보를 다 잊어버리는 (붕괴) 현상이 발생했습니다.
• 비유: 작은 아이는 "어제 본 빨간 문, 오늘 본 파란 창문"을 정확히 기억하는데, 똑똑한 대학생은 "어제 뭐 봤더라?" 하며 기억을 잃어버리는 기이한 일이 일어났습니다.
• 의미: 모델이 크다고 해서 무조건 기억력이나 구조 이해력이 좋은 건 아닙니다.

---

💡 이 연구가 우리에게 주는 메시지

1. AI 는 코드를 '읽을' 수는 있지만, '이해'는 못 할 수도 있습니다.
   AI 가 파일 내용을 다 읽었다고 해서, 그 파일들이 어떻게 연결되어 있는지 (아키텍처) 를 제대로 이해하는 건 별개의 문제입니다.

2. 단순한 테스트로는 부족합니다.
   기존 테스트는 AI 가 "정답을 맞췄는지"만 봤지만, 이 연구는 AI 가 **어떻게 생각했는지 (과정)**를 계속 추적해서 봅니다.

3. 향후 개선 방향:

   • AI 가 구조를 그리는 능력을 훈련시켜야 합니다.
   • AI 가 자신의 이전 생각을 참고하도록 도와주는 시스템이 필요합니다.
   • 어떤 AI 는 "혼자서 찾아다니는 것"이 좋고, 어떤 AI 는 "한눈에 보여주는 것"이 좋으니, 모델에 맞는 방법을 골라야 합니다.

🎯 결론

이 논문은 **"AI 가 코딩을 잘하려면, 단순히 문법을 아는 게 아니라 건물의 설계도 (아키텍처) 를 머릿속에 그리고 유지할 줄 알아야 한다"**고 말합니다. 그리고 지금의 AI 들은 그 '설계도 그리기' 능력에서 아직 많이 부족하고, 모델마다 그 실력이 매우 다르다는 것을 증명했습니다.

이 연구는 앞으로 더 똑똑한 코딩 AI 를 만들기 위한 중요한 나침반이 될 것입니다.

기술 요약

1. 연구 배경 및 문제 정의 (Problem)

대규모 언어 모델 (LLM) 은 코드 생성 벤치마크 (HumanEval 등) 에서 뛰어난 성능을 보이지만, 실제 다중 파일로 구성된 복잡한 소프트웨어 저장소 (Repository) 를 수정하거나 유지보수할 때는 실패하는 경우가 많습니다. 기존 연구들은 에이전트가 소프트웨어 아키텍처에 대한 일관된 내부 이해 (Architectural Belief) 를 형성하고 유지하는 데 실패한다는 점을 지적합니다.

• 핵심 문제: 에이전트가 부분적 관찰 (Partial Observability) 하에서 코드를 탐색할 때, 파일들을 단순히 읽는 것을 넘어 모듈 간의 의존성, 데이터 흐름, 설계 의도 등을 통합된 '인지 지도 (Cognitive Map)' 로 구축하고 이를 업데이트하는 능력이 부족함.
• 기존 벤치마크의 한계: SWE-bench 등은 패치 정확도를 측정하지만, 에이전트가 아키텍처를 어떻게 이해하고 있는지 (Belief State) 를 측정하지는 않음.

2. 제안된 방법론: TOCS (Theory of Code Space)

저자들은 공간 추론 벤치마크인 'Theory of Space (TOS)'를 소프트웨어 공학 영역으로 확장한 TOCS라는 새로운 벤치마크를 제안합니다.

2.1 환경 및 작업 공간

• 프로시저리얼 생성 코드베이스: 파이썬 기반의 '파이프라인 (Pipeline)' 아키텍처 패턴을 가진 코드를 자동 생성합니다.
• 부분적 관찰 (Partial Observability): 에이전트는 전체 코드를 한 번에 보지 못하며, 예산 (Budget, 기본값 20) 내에서 다음 행동을 선택해야 합니다.
  • LIST: 디렉토리 목록 확인 (내용 없음).
  • OPEN: 파일 내용 전체 확인 (비용 1).
  • SEARCH: 파일 위치 및 라인 번호 검색 (내용 없음).
  • INSPECT: 심볼의 시그니처 및 문서화 확인 (비용 1).
• 인지 지도 프로빙 (Cognitive Map Probing): 에이전트가 매 3 행동마다 현재 아키텍처에 대한 믿음 (Belief) 을 구조화된 JSON 형식으로 외부에 명시하도록 강제합니다. 이는 에이전트의 내부 상태를 측정하기 위한 것입니다.

2.2 평가 지표

• 의존성 F1 (Dependency F1): 에이전트가 추론한 의존성 그래프와 실제 (Ground Truth) 그래프의 일치도.
• 불변성 발견 (Invariant Discovery): 코드베이스에 숨겨진 아키텍처 제약 (예: "A 모듈은 C 를 직접 import 하면 안 됨") 을 찾아내는 능력.
• Active-Passive Gap (APG):
  • Active: 에이전트가 직접 파일을 선택하여 탐색.
  • Passive: 에이전트가 모든 파일 (또는 오라클이 선정한 파일) 을 한 번에 제공받음.
  • 이 두 조건의 성능 차이를 통해 에이전트의 '탐색 전략'과 '정보 처리 능력'을 분리하여 분석합니다.

3. 주요 실험 및 결과 (Key Results)

4 가지 규칙 기반 베이스라인과 6 개의 최첨단 LLM(GPT-5.3-Codex, Claude Sonnet 4.6, Gemini 시리즈 등) 을 대상으로 실험한 결과는 다음과 같습니다.

3.1 주요 발견 1: 모델 의존적인 Active-Passive Gap

• GPT-5.3-Codex: 능동적 탐색 (Active) 이 수동적 전체 제공 (Passive-Full) 보다 성능이 더 높았습니다 (APG = -0.22). 모든 파일을 한 번에 주면 정보 과부하 (Information Overload) 로 인해 의존성 파악이 어려워지는 것으로 분석됨.
• Gemini 2.5 Flash: 반대로 수동적 전체 제공이 능동적 탐색보다 성능이 더 높았습니다 (APG = +0.23). 점진적 탐색보다 전체 맥락을 한 번에 보는 것을 선호하는 경향.
• 의미: '능동적 탐색' 자체가 모든 모델에게 내재된 능력이 아니며, 모델 아키텍처에 따라 최적의 정보 입력 방식이 다름을 시사.

3.2 주요 발견 2: 자기 발판 (Self-Scaffolding) 의 모델 의존성

• 프로빙 (JSON 출력) 을 컨텍스트에 유지하는지 여부 (Scratchpad):
  • GPT-5.3-Codex: 이전의 JSON 지도를 컨텍스트에 유지하면 성능이 14 포인트 이상 크게 향상됨. 에이전트가 자신의 이전 추론을 '외부 메모리'로 활용하여 자기 발판을 세우는 능력 보유.
  • Gemini 2.5 Flash: 컨텍스트 유지 여부에 따라 의존성 파악 성능은 변하지 않음 (불변성 발견에는 도움).
• 결론: 자기 발판 (Self-scaffolding) 은 모델마다 작동 메커니즘이 다름.

3.3 주요 발견 3: 믿음 상태의 불안정성 (Belief State Instability)

• Gemini 2.5 Pro: 초기에는 좋은 지도를 만들었으나, 한 번의 프로빙에서 이전에 발견했던 정답을 모두 잃는 '치명적인 붕괴 (Catastrophic Collapse)' 발생.
• Gemini 3 Flash: 최근 편향 (Recency Bias) 으로 인해 최근 확인한 파일만 보고 이전 정보는 잊어버림.
• Gemini 2.5 Flash (가장 작은 모델): 모든 프로빙에서 정답을 잃지 않고 지속적으로 믿음을 유지함.
• 의미: 믿음 상태 유지 능력은 모델의 규모 (Size) 와 비례하지 않으며, 학습 목표나 프롬프트 처리 방식에 더 의존적임.

3.4 아키텍처 제약 발견 능력

• LLM 에이전트들은 규칙 기반 베이스라인보다 4 가지 유형의 의존성 (Import, API Call, Registry Wire, Data Flow) 을 모두 발견하는 데 성공했습니다.
• 특히 규칙 기반 방식이 찾지 못하는 '데이터 흐름 (Data Flow)' 및 '레지스트리 연결 (Registry Wires)' 같은 시맨틱 의존성을 LLM 이 잘 파악했습니다.

4. 기여 및 의의 (Contributions & Significance)

1. 새로운 벤치마크 TOCS 공개: 소프트웨어 아키텍처 이해도를 평가하기 위해, 에이전트가 부분적 관찰 하에서 구조화된 믿음 (Belief) 을 구축하고 업데이트하는 능력을 측정하는 최초의 오픈소스 벤치마크를 공개했습니다.
2. 코드 에이전트의 한계 규명: 최신 LLM 들이 코드 생성은 잘하지만, 아키텍처적 '믿음 (Belief)'을 일관되게 유지하고 외부화 (Externalize) 하는 데는 심각한 격차가 있음을 증명했습니다.
3. 설계 통찰 (Design Lessons):
   • 프롬프트의 중요성: 프롬프트의 모호함이 모델의 '외부화 실패'로 오인될 수 있음을 지적 (예: Edge type 혼동).
   • 상태 관리의 필요성: 에이전트가 아키텍처를 이해하려면 단순한 검색이 아닌, 구조화된 상태 (Structured State) 를 유지하고 업데이트하는 메커니즘이 필요함을 시사.
4. 향후 방향 제시:
   • AST 기반 정적 분석과 LLM 의 시맨틱 분석을 결합한 하이브리드 접근법.
   • 아키텍처 믿음을 구조화된 형식으로 신뢰성 있게 외부화하도록 모델을 학습시키는 것.
   • 에이전트의 탐색 전략 최적화 (어떤 파일을 열지 결정하는 능력).

5. 결론

이 논문은 AI 코드 에이전트가 단순히 코드를 생성하는 것을 넘어, 복잡한 소프트웨어 시스템의 아키텍처를 '이해'하고 '유지'하는 데는 여전히 근본적인 한계가 있음을 보여줍니다. 특히 능동적 탐색 능력, 자기 발판 효과, 믿음 상태의 안정성이 모델마다 극단적으로 다르게 나타난다는 점은, 향후 더 강력한 코드 에이전트를 개발하기 위해서는 모델의 내부 상태 관리 메커니즘과 탐색 전략에 대한 새로운 연구가 필요함을 강력히 시사합니다.