기술 요약: LLM 이 인간이 관여한 개발보다 더 나은 객체 지향 설계를 생성할 수 있는가?

문제 제기

대형 언어 모델 (LLM) 이 코드 생성 능력이 점차 향상되고 있지만, 다중 클래스 프로젝트에서 고품질의 **객체 지향 설계 (OOD)**를 생성할 수 있는 능력은 여전히 불분명합니다. 기존 연구는 주로 다음 사항에 초점을 맞추어 왔습니다:

1. 프로젝트 수준의 아키텍처가 아닌 문제 수준 (단일 메서드 또는 클래스) 에서의 기능적 정확성.
2. LLM 의 영향을 고려하지 않은 LLM 이전 (Pre-LLM) 기준선 (LLM 보조 인간 개발, 즉 PostAI 의 영향 반영 실패).
3. 구현된 코드의 유지보수성 및 구조적 품질이 아닌 고수준 산출물 (예: UML 다이어그램).

본 연구는 LLM 이 엔드투엔드로 생성한 프로젝트 (PureAI) 의 OOD 품질이 LLM 광범위한 도입 전 (PreAI) 과 후 (PostAI) 에 인간이 관여하여 생성된 프로젝트와 어떻게 비교되는지 이해하는 데 존재하는 격차를 해소합니다.

방법론

저자들은 대학원생용 Java 과제인 칼라 (Kalah) 보드 게임 구현을 사용하여 비교 사례 연구를 수행했습니다. 이 연구는 세 가지 저자 조건에 걸친 11 개의 데이터 세트를 분석했습니다:

1. PreAI (LLM 이전, 인간 관여): 주요 LLM 코딩 어시스턴트의 공개 출시 이전인 2021 년 3 월의 제출물 93 건.
2. PostAI (LLM 이후, 인간 관여): LLM 도구가 주류가 된 2024 년 8 월의 제출물 57 건.
3. PureAI (LLM 생성): OOD 지침의 구체성 (없음, 광범위, 구체적) 이 다른 세 가지 프롬프트 변형을 사용하여 세 가지 최신 모델 (gpt-5.4, gemini-2.5-pro, gemini-3.1-pro-preview) 로 수행한 810 회 이상의 생성 실행. 최대 5 회까지의 수정 반복 후 19 개 기능 테스트 케이스를 모두 통과한 실행만 유지되었습니다.

평가 지표

이 연구는 다차원 평가 프레임워크를 사용했습니다:

• OOD 지표: 가중치 부여된 클래스당 메서드 수 (WMC), 객체 클래스 간 결합도 (CBO), 메서드 간 결속력 부족 (LCOM), 상속 트리 깊이 (DIT), 클래스 수 (#Cl), 코드 라인 수 (LOC) 를 포함한 구조적 특성을 포착하는 13 가지 지표.
• 코드 스멜 밀도: 30 가지 감지된 스멜 유형 (메서드 수준 11 가지, 클래스 수준 19 가지) 의 프로젝트 수준 밀도를 크기 (KLOC) 로 정규화한 값.
• 도메인 모델링:
  • 개념 표현: 여섯 가지 핵심 도메인 개념 (Board, Game, Player, Pit, House, Store) 이 클래스로 명시적으로 모델링되었는지 여부.
  • 런타임 준수: 도메인 개념이 시사하는 요구사항과 일치하도록 인스턴스화된 객체의 수가 일치하는지 여부.

통계 분석

비교는 이진형이 아닌 지표에 대해서는 Cliff's delta($\delta$) 를 사용한 Mann–Whitney U 검정, 이진형 지표에 대해서는 오즈비 (OR) 와 함께 Chi-square 또는 Fisher 의 정확 검정을 사용했습니다. 결과는 Benjamini–Hochberg 절차를 사용하여 다중 비교 보정을 적용했습니다.

주요 기여

1. 최초 비교 분석: 프로젝트 수준 설정에서 PreAI, PostAI, PureAI 조건 간의 OOD 품질을 비교한 최초의 연구입니다.
2. 다차원 평가: 정량적 OOD 지표, 코드 스멜 분석, 요구사항 기반 도메인 모델링을 결합하여 설계 품질에 대한 포괄적인 관점을 제공합니다.
3. 과도한 단순화에 대한 경험적 증거: LLM 생성 코드는 종종 "깔끔한" (스멜 밀도가 낮은) 것으로 보이지만, 이는 종종 과도한 단순화 (결여된 추상화, 약한 책임 분리) 와 연관되어 있음을 증거로 제시합니다.
4. PostAI 경향에 대한 통찰: LLM 시대 (PostAI) 의 인간 관여 프로젝트는 PreAI 보다 PureAI(단순화) 에 더 가까운 설계 경향을 보이지만, 코드 스멜 감소는 동반하지 않음을 입증합니다.

결과

RQ1: PreAI, PostAI, PureAI 간의 차이

• 구조적 단순성 vs 과도한 단순화: PureAI 프로젝트는 인간 프로젝트에 비해 일반적으로 클래스 수가 적고, 총 복잡성, 크기, 결합도가 낮습니다. 그러나 이러한 "단순성"은 과도한 단순화와 상관관계가 있습니다:
  • 클래스당 평균 및 최대 백분율 복잡성/결합도가 더 높음 (부담이 더 적은 클래스에 집중됨).
  • 단일 클래스가 종종 여러 도메인 개념을 나타내므로 결속력이 낮음 (LCOM 증가).
  • 명시적으로 표현된 도메인 개념이 적음 (결여된 추상화).
• 코드 스멜: PureAI 프로젝트는 인간 관여 프로젝트에 비해 메서드 및 클래스 수준 모두에서 코드 스멜 밀도가 현저히 낮습니다.
• PostAI 수렴: PostAI 프로젝트는 많은 OOD 지표에서 PreAI 보다 PureAI 에 통계적으로 더 가깝습니다. 단순화와 결여된 도메인 개념에 대한 유사한 경향을 보입니다. 그러나 PureAI 와 달리 PostAI 프로젝트는 PreAI 보다 높은 코드 스멜 밀도를 가지며, 특히 메서드 수준에서 그렇습니다.
• 런타임 준수: 도메인 개념이 표현되면, PureAI 프로젝트는 일반적으로 인간 프로젝트보다 런타임에서 준수할 가능성이 더 높습니다.

RQ2: PureAI 에서 프롬프트 구체성의 영향

• 지침의 영향: 프롬프트 구체성을 높이는 것 (없음 $\to$ 광범위 $\to$ 구체적) 은 일반적으로 다음을 초래합니다:
  • 더 많은 클래스와 더 높은 총 복잡성/크기/결합도 (과도한 단순화에서 벗어남).
  • 클래스당 평균 및 최대 백분율 복잡성/결합도 감소.
  • 전반적 및 메서드 수준 코드 스멜 밀도 감소.
  • 도메인 개념 표현 개선 (모델에 따라 효과가 다름).
• 한계: 더 구체적인 프롬프트가 인간 관여 프로젝트와의 격차를 완전히 해소하지는 못합니다. 일부 모델 (예: O54) 의 경우, 광범위에서 구체적으로 구체성을 높여도 추가적인 개선이 제한적입니다.

중요성 및 함의

이 논문은 LLM 이 구현 세부 사항 (스멜이 적고 런타임 준수가 높은 코드 생성) 을 효과적으로 처리할 수 있지만, 명시적인 인간 지침 없이는 객체 지향 분해 및 책임 할당에는 어려움을 겪는다고 결론지었습니다.

• 과도한 단순화 위험: PureAI 프로젝트는 종종 더 단순하고 "스멜"이 적어 보이지만, 이는 적절한 추상화와 책임 분리의 부재를 감추고 있어 장기적인 유지보수성을 해칠 수 있습니다.
• PostAI 경고: LLM 도구의 가용성은 인간 개발자로 하여금 LLM 의 과도한 단순화 (결여된 개념) 를 모방하는 설계를 생성하게 할 수 있으며, 동시에 새로운 지역적 문제 (메서드 수준 스멜) 를 도입하여 생산성 향상을 상쇄할 수 있습니다.
• 인간 개입의 필요성: 고수준 분해 및 도메인 모델링에 대한 적절한 인간 지침은 여전히 중요합니다. 일반적이거나 심지어 구체적인 OOD 프롬프트에만 의존하는 것은 인간과 비교 가능한 설계 품질을 달성하기에 충분하지 않습니다.
• 검토 전략: LLM 보조 환경에서의 코드 검토는 기능적 정확성이나 지역적 코드 스멜뿐만 아니라 결여된 도메인 개념과 과도하게 단순화된 구조를 명시적으로 점검해야 합니다.

이 연구는 OOD 에서 LLM 을 가장 효과적으로 사용하는 방법은 도메인과 원하는 아키텍처를 이해하는 인간 전문가가 정의한 구조 내에서 구현을 위해 LLM 을 활용하는 것이라고 제안합니다.