LLM-based Automated Architecture View Generation: Where Are We Now?

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

• 배경: 소프트웨어 아키텍처 뷰 (Architecture Views) 는 요구사항과 구현 사이의 가교 역할을 하며, 이해관계자의 요구에 맞춰 복잡한 시스템을 시각화하는 데 필수적입니다.
• 문제점:
  • 아키텍처 뷰의 수동 작성은 노동 집약적이며, 시스템이 복잡해질수록 유지보수가 어렵습니다.
  • 실제 분석에 따르면, 생성된 뷰의 75% 는 작성 후 업데이트되지 않아 구식 아티팩트가 됩니다.
  • 아키텍처 지식은 코드 주석이나 커밋 메시지에 분산되어 있어 전용 아티팩트로 관리되지 않는 경우가 많습니다.
• 연구 목적: 생성형 AI(대규모 언어 모델, LLM) 와 에이전트 (Agentic) 접근 방식을 활용하여 소스 코드에서 직접 아키텍처 뷰를 자동 생성할 수 있는지, 그리고 그 한계와 가능성은 무엇인지 실증적으로 평가하는 것입니다.

2. 연구 방법론 (Methodology)

이 연구는 340 개의 오픈소스 저장소를 대상으로 13 가지 실험 구성을 통해 4,137 개의 생성된 뷰를 분석했습니다.

가. 실험 설정

• 데이터셋: Migliorini et al. 의 데이터셋을 기반으로, UML(PlantUML) 표기법을 사용하는 340 개의 수동 코딩된 리포지토리를 선별했습니다.
• 사용 모델 및 에이전트:
  • LLM: DeepSeek V2.5, Claude 3.5 Sonnet, GPT-4o (코드 요약 및 뷰 생성용).
  • 에이전트:
    1. 일반 목적 에이전트 (GPA): Claude Code (SWE-bench 기반).
    2. 커스텀 에이전트 (ArchView): 아키텍처 도메인 지식, 관심사 (Concern) 명세, ISO/IEC/IEEE 42010 표준을 통합한 다중 에이전트 프레임워크.
• 프롬프트 전략: Zero-shot, One-shot, Few-shot 프롬프팅 기법을 적용하여 비교했습니다.
• 워크플로우:
  1. 코드 요약: 소스 코드를 계층적 (Hierarchical) 으로 요약하여 저장소 개요를 생성.
  2. 뷰 생성: 요약된 정보와 아키텍처 관심사 (예: 배포, 보안, 제어 흐름) 를 입력받아 PlantUML 코드 생성.
  3. 평가: 생성된 다이어그램을 Ground Truth 와 비교.

나. 평가 지표

• 자동화 평가 (LLM-as-a-Judge):
  • 명확성 (Clarity): 가독성, 레이블 정확도, 레이아웃.
  • 완전성 (Completeness): 필수 아키텍처 지식의 누락 여부.
  • 일관성 (Consistency): 표기법 및 구조적 패턴의 통일성.
• 이미지 유사도: SSIM(Structural Similarity Index) 등을 사용하여 시각적 유사성 측정.
• 인간 평가: 정확도 (Accuracy) 와 세부 사항 수준 (Level of Detail) 에 대한 전문가 평가 (블라인드 테스트).

3. 주요 기여 (Key Contributions)

1. 대규모 실증 평가: 340 개의 리포지토리와 13 가지 실험 구성을 통해 생성된 4,137 개의 아키텍처 뷰에 대한 대규모 데이터셋과 평가 결과를 제공.
2. 성능 분석: 특정 아키텍처 관심사 (Control Flow, Deployment 등) 와 품질 속성 (Maintainability, Security 등) 에 따른 모델 성능의 차이를 심층 분석.
3. 재현성 패키지: 모든 데이터셋, 프롬프트, 스크립트를 공개하여 향후 연구를 지원.

4. 연구 결과 (Results)

가. 접근 방식별 성능 비교 (RQ1)

• 커스텀 에이전트 (ArchView) 의 우위: ArchView 가 모든 지표에서 가장 우수한 성능을 보였습니다.
  • 명확성 실패율: 22.6% (가장 낮음).
  • 세부 사항 성공률: 50%.
  • 인간 평가: 자동화 평가와 인간 평가 간의 괴리가 가장 작았습니다.
• 프롬프팅 기법: Few-shot 프롬프팅이 Zero-shot 대비 명확성 실패율을 9.2% 감소시켰으나, 개선 폭은 제한적이었습니다.
• 일반 목적 에이전트 (Claude Code): 도구 접근성이 있음에도 불구하고 가장 낮은 성능을 보였습니다 (명확성 실패율 71.8%). 이는 아키텍처 추상화 능력이 부족하여 코드 레벨의 세부 사항에 머무르는 경향이 있었기 때문입니다.

나. 표기법 및 세분화 (Granularity) 의 영향 (RQ2)

• 표기법 복잡도: 단순한 '상자 (Box)' 표기보다 '상자 + 화살표 + 아이콘'과 같은 풍부한 표기법이 사용될 때 SSIM 점수가 38% 이상 향상되었습니다. 이는 LLM 이 구조적 단서를 더 잘 활용함을 시사합니다.
• 세분화 수준: 고도 (High), 중도 (Medium), 저도 (Low) granularity 간 통계적으로 유의미한 차이는 발견되지 않았습니다. 다만, 고도 뷰에서 구조적 유사성 (SSIM) 은 높았으나 의미적 품질 (LLM Quality) 은 감소하는 경향이 있었습니다.

다. 아키텍처 관심사 및 품질 속성별 성능 (RQ3)

• 성공적인 생성: **제어 흐름 (Control Flow)**과 데이터 흐름 (Data Flow) 뷰가 가장 높은 신뢰도와 성능을 보였습니다.
• 어려운 생성: **일반 문서화 (General Documentation)**와 보안 (Security) 관련 뷰는 시각적, 의미적 모두에서 실패율이 높았습니다.
• 품질 속성: 기능 적합성 (Functional Suitability) 이 SSIM 점수가 가장 높았으나, 호환성 (Compatibility) 은 SSIM 은 낮았지만 의미적 품질은 높게 나타나는 등 지표 간 괴리가 존재했습니다.

5. 논의 및 시사점 (Discussion & Significance)

가. 핵심 발견

• 구문적 유효성 vs. 의미적 정확성: LLM 은 문법적으로 유효한 PlantUML 코드를 생성할 수 있지만, 아키텍처 추상화 (Architectural Abstraction) 수준에서는 실패하는 경우가 많습니다. 즉, 코드의 구조는 잘 파악하지만 시스템 전체의 아키텍처 의도를 파악하지 못합니다.
• 도메인 지식의 필수성: 일반 목적의 코딩 에이전트만으로는 아키텍처 뷰 생성이 불가능하며, **도메인 특화 지식 (ArchView 와 같은 커스텀 에이전트)**과 관심사 명세가 반드시 통합되어야 합니다.
• 평가 지표의 한계: 픽셀 수준의 유사도 (SSIM) 는 아키텍처 정확성을 보장하지 못합니다. 의미적 정확성을 평가하기 위한 새로운 평가 프레임워크가 필요합니다.

나. 실무적 시사점

• 보조 도구로서의 LLM: LLM 은 완전한 자율 아키텍트 (Autonomous Architect) 가 아니라, **도구 (Assistive Tool)**로 활용해야 합니다. 생성된 뷰는 초기 문서화나 레거시 시스템 이해를 위한 '시작점 (Starting Point)'으로 유용하지만, 최종 검증은 인간 전문가의 개입이 필요합니다.
• 코드 요약의 병목: 아키텍처 뷰 생성의 성패는 소스 코드 요약의 정확도에 직접적으로 의존합니다. 고수준 추론을 위한 코드 요약 기술의 발전이 선행되어야 합니다.

다. 결론

이 연구는 LLM 기반 아키텍처 뷰 생성이 기술적으로 가능하지만 아직 초기 단계임을 보여줍니다. 특히 **커스텀 에이전트 (ArchView)**가 도메인 지식을 통합함으로써 기존 접근법보다 월등히 나은 성능을 입증했습니다. 향후 연구는 더 정교한 코드 요약 기술, RAG(검색 증강 생성) 를 통한 외부 지식 통합, 그리고 아키텍처 특화 평가 지표 개발에 초점을 맞춰야 합니다.