Formal Architecture Descriptors as Navigation Primitives for AI Coding Agents

1. 문제 정의 (Problem Statement)

LLM 기반 코딩 에이전트 (Claude Code, Cursor 등) 는 실제 대규모 코드베이스에서 작업을 수행할 때, 코드 수정보다는 방향성 없는 코드 탐색 (undirected codebase exploration) 에 툴 호출의 상당 부분을 소모합니다.

• 탐색의 역설 (Navigation Paradox): 컨텍스트 윈도우가 커짐에도 불구하고, 에이전트는 개발자의 머릿속에 있는 아키텍처 맥락을 재구성하기 위해 파일을 검색하고 (globbing), 심볼을 grep 하고, 모듈을 읽는 데 시간을 낭비합니다.
• 기존 접근법의 한계:
  • 자연어 기반 (CLAUDE.md 등): 개발자가 마크다운으로 작성한 컨텍스트 파일은 추론 비용을 20% 이상 증가시키지만, 작업 성공률에 통계적으로 유의미한 향상을 주지 못했습니다.
  • 자동화된 구조 추출 (Aider, RepoGraph 등): 구문적 관계는 추출하지만, 설계 의도 (design intent) 나 아키텍처 제약 조건을 포착하지 못합니다.
• 핵심 질문: 형식적인 아키텍처 기술자 (Formal Architecture Descriptors) 를 에이전트에 제공하면 탐색 오버헤드를 줄일 수 있는가?

2. 방법론 (Methodology)

저자는 intent.lisp 라는 S-식 (S-expression) 기반의 형식적 아키텍처 기술자 포맷을 제안하고, 이를 검증하기 위해 세 가지 보완적인 연구와 한 가지 관찰 연구를 수행했습니다.

2.1 제안된 포맷: intent.lisp

• 구조: 중첩된 S-식 트리로 프로젝트 아키텍처를 선언합니다. (Pillars, Components, Symbols 로 계층화)
• 생성 방식: 개발자가 자연어로 아키텍처 의도를 서술하면 LLM 이 이를 S-식으로 변환합니다. (직접 작성보다는 LLM 을 통한 생성이 주된 사용 시나리오)
• 선택 이유:
  • 문법적 위계 강제: 괄호 구조를 통해 계층 관계를 문법적으로 강제합니다.
  • 압축 효율성: 생산성 코드 (646K 줄) 기준 평균 34:1 의 압축률을 보입니다.
  • 오류 내성 (Graceful Error Degradation): JSON 은 구조 오류 시 전체 파싱 실패 (Atomic failure) 를 일으키지만, S-식은 오류 이전의 내용을 유지하며 구조적 완전성 오류를 감지합니다.

2.2 실험 설계

1. 제어된 실험 (Code Localization): 24 개의 Rust 코드 위치 특정 (Localization) 태스크를 수행하며, 조건 (Blind, S-expr, JSON, Markdown) 을 비교했습니다. (모델: Claude Sonnet 4.6, Temp=0)
2. 아티팩트 vs 프로세스 실험: 개발자가 코드 리팩토링 없이 자동 생성된 기술자 (AutoGen) 만을 사용한 경우와 수동으로 다듬은 기술자 (Curated) 를 비교하여 기술자 자체의 가치를 검증했습니다.
3. 생성 및 오류 내성 실험: 96 회 생성 및 96 회 오류 주입을 통해 다양한 포맷 (JSON, YAML, Markdown, S-expr) 의 파싱 신뢰도와 실패 모드를 분석했습니다.
4. 관찰적 현장 연구 (Field Study): 7,012 개의 Claude Code 세션 (Nov 2025–Apr 2026) 을 분석하여 형식적 기술자 도입 전후의 에이전트 행동 분산 변화를 측정했습니다.

3. 주요 기여 및 결과 (Key Contributions & Results)

3.1 탐색 단계 감소 (Navigation Reduction)

• 결과: 아키텍처 컨텍스트를 제공받은 에이전트는 탐색 단계가 33~44% 감소했습니다. (Wilcoxon signed-rank test, $p=0.009$, Cohen's $d=0.92$)
• 포맷 비교: S-식, JSON, YAML, Markdown 간 정확도나 단계 수에서 통계적으로 유의미한 차이는 발견되지 않았습니다. (모든 포맷에서 95% 정확도 달성)
• 의미: LLM 이 특정 포맷을 선호한다는 가설은 기각되었으며, 중요한 것은 포맷이 아니라 '구조화된 아키텍처 정보의 존재'임을 입증했습니다.

3.2 아티팩트의 직접적 가치 (Artifact Value)

• 결과: 인간의 개입이나 코드 리팩토링 없이 자동 생성된 기술자 (AutoGen) 를 사용한 경우, 맹목적인 탐색 (Blind) 대비 정확도가 80% → 100% 로 향상되었습니다. ($p=0.002, d=1.04$)
• 의미: 기술자의 가치는 개발자가 코드를 정리하는 '프로세스'에서 오는 것이 아니라, 기술자 파일 자체가 에이전트에게 직접적인 탐색 가치를 제공한다는 것을 증명했습니다.

3.3 에이전트 행동 분산 감소 (Behavioral Variance)

• 결과: 7,012 개의 세션 분석 결과, 형식적 기술자 도입 후 에이전트의 '탐색/수정 비율'의 IQR(사분위범위) 이 2.24 에서 1.08 로 52% 감소했습니다.
• 의미: 기술자가 에이전트의 최악의 행동 (과도한 탐색 등) 을 제한하여 행동의 일관성을 높였습니다.

3.4 포맷별 오류 내성 비교

• JSON: 구조 오류 발생 시 전체 파일 파싱 불가 (Atomic failure). 하지만 정적 오류는 21% 만 은밀하게 손상 (Silent corruption).
• YAML: 50% 의 오류가 의미 변경 없이 은밀하게 손상됨.
• S-식 (intent.lisp): 구조적 완전성 오류를 100% 감지하며, 오류 발생 시에도 이전 내용은 구조적으로 무결성을 유지합니다. 이는 자동화된 거버넌스에 유리합니다.

4. 의의 및 결론 (Significance & Conclusion)

1. 컨텍스트 엔지니어링의 패러다임 전환: "LLM 이 어떤 포맷을 더 잘 이해하는가?"라는 질문보다는, **"LLM 이 작성하고 읽을 때 치명적인 실패를 방지하는 포맷은 무엇인가?"**에 초점을 맞춰야 함을 시사합니다.
2. 확장성: 작은 프로젝트 (22K 줄) 에서 이미 유의미한 효과를 보였으며, 100K~470K 줄 규모의 대규모 코드베이스에서는 맹목적인 탐색이 훨씬 어렵기 때문에 효과가 더 클 것으로 예상됩니다. (압축률 34:1 이 코드베이스 크기에 따른 비용 증가를 상쇄)
3. 자동화의 가능성: 수동으로 다듬은 기술자보다 자동 생성된 기술자가 정확도 면에서 더 우수하거나 동등한 성능을 보여, 대규모 프로젝트에서의 자동화 파이프라인 구축 가능성을 열었습니다.
4. 도구화: intent.lisp 와 이를 생성/구독하는 도구 (Forge survey tool) 는 오픈소스로 공개되어, 에이전트 간 아키텍처 분할 및 협업의 기반이 될 수 있습니다.

요약하자면, 이 논문은 AI 코딩 에이전트의 비효율적인 탐색 행동을 해결하기 위해, 자연어가 아닌 형식적인 S-식 기반 아키텍처 기술자를 도입했을 때 탐색 단계가 크게 줄어들고 에이전트의 행동이 안정화됨을 실증적으로 증명했습니다. 특히 포맷의 문법적 특성 (S-식) 이 LLM 의 이해도 향상보다는 오류 내성과 압축 효율성 측면에서 더 큰 가치를 지닌다는 점을 강조합니다.