OODEval: Evaluating Large Language Models on Object-Oriented Design

이 논문은 객체 지향 설계 (OOD) 평가를 위한 벤치마크 OODEval 과 인간 평가 데이터셋 OODEval-Human, 그리고 통합 평가 지표 CLUE 를 제안하고, 이를 통해 29 개의 대규모 언어 모델의 OOD 수행 능력을 심층 분석하여 높은 문법적 정확도에도 불구하고 의미적 결함이 존재함을 규명했습니다.

핵심

1. 연구의 배경: "코딩은 잘하는데, 설계는 왜 못 할까?"

지금까지 AI 를 평가할 때는 주로 "이 코드가 실행되나요?" (문법 오류가 없나요?) 같은 작은 단위의 테스트를 많이 했습니다. 하지만 소프트웨어 개발에서 가장 중요한 것은 전체적인 설계도를 그리는 일입니다.

• 비유: AI 가 **벽돌 하나를 쌓는 일 (코딩)**은 아주 잘하지만, **건물 전체의 설계도 (OOD, 객체 지향 설계)**를 그리는 일은 아직 서툴다는 것입니다.
• 문제점: 설계를 평가할 수 있는 '공식 시험지'나 '자동 채점기'가 없어서, AI 의 설계 능력을 제대로 측정하지 못했습니다.

2. 연구의 해결책: 새로운 시험지와 채점기 만들기

연구팀은 이 문제를 해결하기 위해 세 가지 큰 도구를 만들었습니다.

① OODEval (새로운 시험지)

• 무엇인가요? AI 에게 "이 기능을 구현해 줘"라는 요구사항을 주고, 그에 맞는 **설계도 (클래스 다이어그램)**를 그리게 하는 50 개의 문제입니다.
• 특징: 문제 난이도를 '초급, 중급, 고급'으로 나누어, AI 가 복잡한 구조를 얼마나 잘 이해하는지 테스트합니다.

② OODEval-Human (인간 학생들의 답안지)

• 무엇인가요? 대학생 940 명이 실제로 이 시험을 치고, 교수님이 점수를 매긴 실제 답안입니다.
• 목적: "AI 가 대학생보다 잘할까?"를 비교하고, 새로운 채점기가 인간 교수님의 점수와 얼마나 일치하는지 확인하기 위해 만들었습니다.

③ CLUE (새로운 자동 채점기)

• 무엇인가요? 기존에는 AI 가 그린 설계도와 정답을 단순히 글자 비교 (BLEU 등) 로만 했지만, 이 방법은 구조적인 의미를 놓칩니다.
• 비유: 정교한 비교기입니다. 단순히 "단어가 같나요?"가 아니라, "클래스 이름이 의미 있는가?", "함수가 잘 정의되었는가?", "클래스 간의 연결 관계 (상속, 포함 등) 가 논리적인가?"까지 구조와 의미를 모두 파악해서 점수를 줍니다.

3. 주요 발견 (결과)

🏆 AI 의 능력: "문법은 완벽하지만, 의미는 엉망"

• 문법 (Pass@1): AI 가 그린 설계도 코드가 문법적으로 틀린 경우는 거의 없습니다. (90% 이상 성공)
• 의미 (CLUE 점수): 하지만 실제 의미는 다릅니다. AI 는 클래스 이름이나 속성은 잘 뽑아내지만, 함수 (메서드) 를 만들거나 클래스 간의 복잡한 관계를 연결하는 데는 큰 실수를 합니다.
• 비유: AI 는 아름다운 건물의 외관은 완벽하게 그리지만, 내부 배관이나 전기 배선을 연결하는 데는 실패하는 건축가입니다.

🥊 AI vs 인간 학생

• 평균 비교: AI 의 평균 점수는 평균적인 대학생보다 낮습니다. 특히 복잡한 문제일수록 차이가 커집니다.
• 최고 수준 비교: 하지만 최고 성능의 AI (예: Qwen3-Coder-30B) 는 평균적인 대학생 수준에는 거의 도달했습니다.
• 한계: 하지만 가장 뛰어난 학생 (99 점 이상) 과는 여전히 격차가 있습니다. AI 는 아직 '천재' 학생을 완전히 따라잡지 못했습니다.

📈 무엇이 AI 성능을 좌우할까?

1. 모델 크기: 파라미터가 큰 모델이 더 잘합니다.
2. 전문성: 일반 AI 보다 코딩에 특화된 AI(Code LLM) 가 훨씬 잘합니다.
3. 지시 따르기: "지시사항을 잘 따르도록 훈련된 (Instruction Tuned)" 모델이 더 좋습니다.
4. 추론 능력: "생각하는 과정 (Reasoning)"을 거치는 모델이 무조건 좋은 것은 아닙니다. 오히려 코딩 특화 모델이 더 나을 때도 있습니다.

⚠️ AI 가 자주 하는 실수

• 가장 흔한 실수: 중요한 클래스를 빼먹거나, 클래스 간의 연결 관계를 잘못 그리는 경우입니다.
• 특이한 실수: 요구사항에 없는 불필요한 기능을 만들어내거나 (할루시네이션), 코드를 설계도 대신에 써버리는 경우 등입니다.
• 잘하는 모델: DeepSeek, GPT-4o, 그리고 오픈소스 모델인 Gemma3와 Qwen3-Coder 시리즈가 상대적으로 실수가 적고 안정적입니다.

4. 이 연구가 우리에게 주는 교훈

1. 교육 현장의 변화: AI 가 대학생 평균 수준까지 설계도를 그릴 수 있게 되었으니, 학교에서는 단순한 결과물 제출보다는 설계 과정을 설명하거나 구두 시험을 보는 등 새로운 평가 방식을 도입해야 합니다. (AI 가 답안을 대신 써주는 것을 막기 위해)
2. 모델 선택:
   • 고성능이 필요하면 Qwen3-Coder-30B 같은 큰 모델을 쓰세요.
   • 자원이 부족하면 Gemma3-4B-IT 같은 작은 모델도 surprisingly 잘합니다.
   • 비용 효율을 원하면 DeepSeek-R1 같은 API 가 좋습니다.
3. 미래 연구: 앞으로는 AI 가 더 복잡한 설계 (클래스가 많고 관계가 복잡한) 를 할 수 있도록 훈련시켜야 합니다.

💡 한 줄 요약

"AI 는 이제 소프트웨어 설계도 그리기를 배우기 시작했지만, 아직 인간 전문가나 뛰어난 학생만큼 정교하지는 않습니다. 하지만 빠르게 성장하고 있으니, 우리는 AI 를 어떻게 활용하고 통제할지 준비해야 합니다."

기술 요약

논문 개요: OODEval (객체 지향 설계 평가)

이 논문은 최근 소프트웨어 공학 분야에서 대두된 대규모 언어 모델 (LLM) 의 객체 지향 설계 (OOD, Object-Oriented Design) 능력을 체계적으로 평가하기 위한 새로운 프레임워크를 제안합니다. 기존 연구들이 주로 코드 생성 (코드 레벨) 에 집중했던 반면, 요구사항 분석부터 클래스 다이어그램 설계까지의 소프트웨어 설계 단계에서의 LLM 성능은 표준화된 벤치마크와 자동 평가 지표의 부재로 인해 충분히 연구되지 않았습니다.

1. 연구 문제 (Problem)

• 평가 공백: 기존 LLM 평가 벤치마크의 92% 가 요구사항 및 설계 단계 (8%) 를 제외한 프로그래밍 보조 및 품질 관리에 집중되어 있음.
• 데이터 부족: 객체 지향 설계를 평가할 수 있는 공개된 표준 벤치마크 데이터셋이 부재하며, 기존 데이터셋은 단순하거나 이미지 형식이라 자동 평가가 어려움.
• 평가 지표의 한계: 기존 텍스트 매칭 (BLEU 등) 은 클래스 다이어그램의 구조적/의미적 정보를 포착하지 못하며, 도메인 특화 평가 방법들은 재현성이 낮거나 세부 요소 (속성, 메서드, 관계) 평가에 미흡함.

2. 방법론 (Methodology)

가. 새로운 벤치마크 구축

1. OODEval (자동 평가용 벤치마크):
   • 구성: 요구사항 텍스트에서 클래스 다이어그램 (PlantUML 코드) 을 생성하는 50 개의 작업으로 구성.
   • 난이도: 단순 (Simple), 중간 (Moderate), 어려움 (Hard) 3 단계로 세분화 (각각 16, 17, 17 개).
   • 특징: 클래스 수, 속성/메서드 수, 관계 수, 요구사항 가독성 (Flesch-Kincaid 점수) 등을 기반으로 복잡성을 정량화.
2. OODEval-Human (인간 평가용 벤치마크):
   • 구성: 4 개의 OOD 과제에 대한 940 개의 학부생 제출 솔루션과 강사 점수를 포함.
   • 목적: LLM 과 인간 (학부생) 의 성능 비교 및 새로운 평가 지표의 인간 평가와의 상관관계 검증.
   • 처리: 학생 제출물 (이미지) 을 PlantUML 코드로 자동 변환 후, 3 인 이상의 검토자가 수동으로 검증하여 정확도 확보.

나. 새로운 평가 지표: CLUE (Class Likeness Unified Evaluation)

• 개념: 참조 설계 (Reference) 와 후보 설계 (Candidate) 간의 구조적 및 의미적 유사성을 종합적으로 평가하는 자동 지표.
• 구성:
  • 전체 지표 (clue): 클래스, 속성, 메서드, 관계의 유사성을 가중치로 통합.
  • 세부 지표: clue-class, clue-attribute, clue-method, clue-relation.
• 기술적 특징:
  • 최적 매칭 (Optimal Matching): 헝가리 알고리즘을 사용하여 참조 모델과 후보 모델의 요소 간 최적 매칭을 수행 (명칭이 달라도 의미적 유사성을 고려).
  • 의미적 임베딩: CodeBERT 모델을 활용하여 문자열 (클래스명, 메서드명 등) 간의 의미적 유사성 (Cosine Similarity) 계산.
  • 관계성 평가: 관계의 유형 (연결, 집계, 상속 등) 과 다중성 (Multiplicity) 을 고려한 특수한 유사도 함수 적용.
• 검증: 15 개의 하이퍼파라미터를 베이지안 최적화 (Bayesian Optimization) 를 통해 학습하여, 인간 점수 (OODEval-Human) 와의 상관관계 (Pearson 계수 0.59) 를 극대화.

다. 실증 연구 (Empirical Study)

• 대상: 29 개의 다양한 LLM (오픈소스/상용, 코드 특화/일반, 추론 모델 등) 평가.
• 평가 방식: 각 모델이 50 개의 OODEval 태스크에 대해 5 개의 샘플을 생성 (총 7,250 개 출력).
• 측정 지표: 문법적 정확도 (Pass@1), 의미적 정확도 (CLUE 점수).

3. 주요 결과 (Key Results)

가. 전반적 정확도 (RQ1)

• 문법 vs 의미: LLM 들은 PlantUML 코드의 문법적 정확도 (Pass@1) 는 매우 높음 (80% 이상) 하지만, 의미적 정확도 (CLUE) 는 상대적으로 낮음.
• 약점: 클래스 이름과 속성 생성은 우수하나, 메서드 생성과 클래스 간 관계 (Relationship) 정의에서 심각한 결함이 발생. 특히 난이도가 높은 (Hard) 태스크에서 성능 저하가 뚜렷함.

나. 인간 vs LLM 비교 (RQ2)

• 평균 성능: 평균 LLM 성능은 평균 학부생 성능보다 현저히 낮음 (특히 메서드와 관계 생성에서 30~50% 이상 격차).
• 최고 성능: 최상위 LLM (Qwen3-Coder-30B 등) 은 평균 학부생 수준에 근접하거나 일부 지표에서 약간 상회함.
• 한계: 하지만 최고 수준의 인간 (Expert) 에 비해서는 여전히 큰 격차가 존재함.

다. 모델 특성 분석 (RQ3)

• 성공 요인:
  • 파라미터 규모: 모델 크기가 클수록 성능 향상.
  • 코드 특화: 일반 모델보다 코드 특화 모델 (CodeLlama, DeepSeek-Coder 등) 이 성능이 우수함.
  • 지시 미세 조정 (Instruction Tuning): Base 모델보다 Instruction-Tuned 모델이 압도적으로 우수함.
• 실패 요인: 추론 능력 (Reasoning) 이 있는 모델 (예: DeepSeek-R1) 이 비추론 모델보다 우월하다는 명확한 증거는 발견되지 않음 (모델 아키텍처 차이로 인해).

라. 태스크 특징 분석 (RQ4)

• 성능 저하 요인: 클래스 수, 메서드 수, 관계 수, 일반화 (상속) 관계 비율이 증가할수록 성능이 급격히 떨어짐.
• 가독성: 요구사항 텍스트의 가독성이 낮을수록 성능이 저하됨.
• 영향 없음: 속성 (Attribute) 수의 증가는 성능에 큰 영향을 미치지 않음.

마. 실패 사례 분석 (RQ5)

• 주요 오류: 키워드 오류, 클래스/관계 누락, 메서드 생략, 관계 유형 오용 (예: 집계와 조합 혼동) 이 가장 흔함.
• 우수 모델: DeepSeek 시리즈, GPT 시리즈, Gemma3-IT, Qwen3-Coder-30B 는 오류 유형이 적고 전반적 성능이 우수함. 특히 Gemma3-IT 시리즈는 오류 다양성이 가장 낮음.

4. 주요 기여 (Key Contributions)

1. OODEval 벤치마크: 요구사항부터 설계까지의 50 개 OOD 태스크를 포함한 최초의 표준 벤치마크 (3 단계 난이도).
2. OODEval-Human 데이터셋: 940 개의 학부생 솔루션과 강사 점수를 포함한 인간 평가 데이터셋 (LLM 과 인간 비교 및 지표 검증용).
3. CLUE 지표: 구조적/의미적 정보를 통합한 자동 평가 지표 세트로, 인간 평가와 높은 상관관계를 보임.
4. 포괄적 실증 연구: 29 개 LLM 과 인간을 대상으로 한 대규모 평가 및 모델/태스크 특성에 대한 심층 분석.

5. 의의 및 시사점 (Significance)

• 모델 개선 방향: LLM 의 메서드 생성 및 관계 추론 능력을 강화해야 함을 시사. 코드 특화 모델의 미세 조정 (Fine-tuning) 이 효과적임.
• 모델 선택 가이드:
  • 고성능 로컬 배포: Qwen3-Coder-30B 추천.
  • 자원 제약 환경: Gemma3-4B-IT (소규모지만 정확도 우수).
  • 상용 API: DeepSeek-R1 (비용 대비 성능 우수).
• 교육적 시사점: 최상위 LLM 이 평균 학생 수준에 근접함에 따라, AI 를 이용한 학업 부정을 방지하기 위한 평가 방식 변경 (프로세스 중심 평가, 구두 변명 등) 이 필요함. 동시에 AI 를 활용한 학습 도구로서의 적극적 활용 방안 모색 필요.
• 벤치마크 확장: 더 복잡한 설계 (많은 클래스/관계, 상속 관계) 를 포함한 데이터셋 구축 필요.

이 연구는 LLM 이 소프트웨어 설계 단계에서 얼마나 유용한지, 그리고 어떤 한계가 있는지를 체계적으로 규명하여, 향후 LLM 기반 소프트웨어 공학 도구 개발 및 교육 전략 수립에 중요한 기초를 제공합니다.