Reliability of Large Language Models for Design Synthesis: An Empirical Study of Variance, Prompt Sensitivity, and Method Scaffolding
본 연구는 선호도 기반 프롬프팅이 UML 클래스 다이어그램 생성 시 설계 의도 준수를 향상시키지만, 비결정성과 모델 간 편차를 완전히 제거하지는 못함을 실증적으로 규명하여 신뢰할 수 있는 LLM 기반 소프트웨어 설계를 위해서는 효과적인 프롬프팅과 함께 모델의 거동과 견고성을 고려해야 함을 시사합니다.
이 연구는 인공지능을 요리사로, 소프트웨어 설계 (UML 도면) 를 요리로, 그리고 사용자의 명령을 레시피로 비유합니다.
기존의 문제 (단순 번역):
예전에는 AI 가 "소고기, 감자, 양파를 넣으세요"라고 하면, 단순히 그 재료들을 그릇에 담아주는 수준이었습니다. (문법적으로 맞는 도면은 그렸지만, 실제로 먹기 좋은 요리인지는 몰랐습니다.)
하지만 좋은 요리사는 재료뿐만 아니라 "소고기는 먼저 볶아야 하고, 감자는 나중에 넣어야 한다"는 **요리 원리 (설계 원칙)**를 알아서 적용해야 합니다.
이 연구의 목표:
AI 가 단순히 재료를 나열하는 것을 넘어, **맛있는 요리 (훌륭한 소프트웨어 설계)**를 만들어낼 수 있는지, 그리고 **같은 레시피를 줘도 매번 같은 맛을 내는지 (안정성)**를 테스트했습니다.
🔍 실험 내용: 세 가지 요리법 (프롬프트 전략)
연구진은 세 가지 다른 AI 요리사 (ChatGPT, Claude, Gemini) 를 불러와 같은 재료 (병원 청구 시스템, 센서 네트워크) 로 요리를 시켰습니다. 이때 세 가지 다른 방법을 사용했습니다.
기본 레시피 (Standard Prompting):
"이 재료를 이용해 요리를 해줘."라고만 말함.
결과: AI 가 알아서 하길 바랐지만, 대부분 재료만 나열하고 조리법을 무시했습니다.
엄격한 규칙 레시피 (Rule-injection):
"소고기는 반드시 먼저 볶고, 감자는 절대로 태우지 마라"고 구체적인 규칙을 적어줌.
결과: 규칙을 외우려다 오히려 혼란이 와서, 일부 AI 는 더 엉망진창이 되었습니다. (지시사항이 너무 많으면 AI 가 당황함)
선호도 기반 레시피 (Preference-based Prompting) - 🌟 이 연구의 핵심
"이런 요리법은 나쁜 예고, 이쪽은 좋은 예야. 너는 좋은 예처럼 만들어줘."라고 비교 예시를 보여줌.
결과: AI 가 "아, 이런 식으로 하면 더 좋은구나!"라고 깨닫고, 규칙을 외우지 않아도 **요리 원리 (설계 원칙)**를 자연스럽게 적용했습니다.
📊 주요 발견: "요리사마다 성향이 다르다"
가장 흥미로운 점은 같은 레시피를 줘도 AI 요리사마다 결과가 완전히 달랐다는 것입니다.
Claude (클로드):
성향: 매우 일관성이 좋습니다. 같은 레시피를 10 번 줘도 거의 똑같은 요리를 냅니다.
단점: 가끔은 너무 보수적이어서 중요한 재료를 빼먹기도 합니다. (안정적이지만 창의성 부족)
ChatGPT:
성향:원리를 잘 이해합니다. 좋은 예시를 보여주면 가장 잘 따라 합니다.
특징: 실수가 있더라도 매번 같은 실수를 반복합니다. (예측 가능한 실수)
Gemini (제미니):
성향:매우 불안정합니다. 같은 레시피를 줘도 10 번 할 때마다 요리 모양이 다릅니다.
문제: 재료가 너무 많으면 (복잡한 설계) 혼란을 겪어 엉망이 됩니다.
💡 결론: 무엇을 배울 수 있을까?
이 연구는 우리에게 다음과 같은 교훈을 줍니다.
단순히 "명령"만 내리면 안 된다: AI 에게 "잘해줘"라고만 하면 안 됩니다. 좋은 예시와 나쁜 예시를 비교해 보여주며 **취향 (선호도)**을 가르쳐야 더 좋은 설계가 나옵니다.
AI 모델 선택이 가장 중요하다: 똑같은 일을 시켜도 누구를 쓰느냐에 따라 결과가 천차만별입니다. 중요한 설계 작업에는 변덕이 심한 AI 보다는 일관성 있는 AI를 선택하는 것이 더 중요합니다.
복잡해질수록 AI 는 힘들어한다: 간단한 요리 (단순 설계) 는 잘하지만, 정교한 코스 요리 (복잡한 시스템 설계) 가 필요하면 AI 는 여전히 원리를 완벽하게 이해하지 못합니다.
🎯 한 줄 요약
"AI 가 소프트웨어 설계도를 그릴 때, 단순히 지시만 내리는 것보다 '좋은 예시'를 보여주고, 안정적인 AI 요리사를 고르는 것이 성공의 열쇠입니다."
이 연구는 AI 가 이제 단순한 '그림 그리는 도구'를 넘어, 우리가 믿고 의지할 수 있는 '설계 파트너'가 되기 위해서는 기술적 능력뿐만 아니라 행동의 안정성도 함께 검증해야 함을 강조합니다.
1. 연구 배경 및 문제 제기 (Problem)
문제의 본질: 최근 대규모 언어 모델 (LLM) 은 자연어 설명에서 UML 클래스 다이어그램을 생성하는 등 소프트웨어 엔지니어링 자동화에 널리 적용되고 있습니다. 그러나 기존 연구들은 주로 **문법적 유효성 (Syntactic Validity)**에 초점을 맞추었으며, 이는 **설계 품질 (Design Quality)**을 보장하지 못합니다.
전환의 필요성: 현재 LLM 기반 모델링은 단순한 '텍스트 - 다이어그램 번역 (Translation)'에 머무르고 있습니다. 즉, 텍스트의 명사/동사를 클래스/속성으로 매핑하는 수준에 그칩니다. 반면, 진정한 **설계 합성 (Design Synthesis)**은 명시적 지시가 없어도 요구사항에서 암묵적인 설계 원칙 (추상화, 캡슐화 등) 과 디자인 패턴 (GoF 패턴 등) 을 추론하여 적용하는 능력을 요구합니다.
신뢰성 (Reliability) 의 부재: 생성형 AI 는 본질적으로 비결정론적 (Non-deterministic) 입니다. 프롬프트의 미세한 변화 (문장 재구성) 나 반복 실행 시에도 일관된 아키텍처를 산출하지 못하면, 하류의 구현 단계로 오류가 전파될 수 있어 실제 산업 적용에 큰 리스크가 됩니다.
연구 질문 (RQs):
RQ1: 도메인 설명만 주어졌을 때 LLM 이 설계 원칙을 만족하는 다이어그램을 생성할 수 있는가?
RQ2: 제안된 방법이 명시적 규칙 주입 없이도 패턴 일관성 구조의 출현을 유도하는가?
RQ3: 반복 실행 및 프롬프트 변형에 대해 생성된 설계의 강건성 (Robustness) 은 어떠한가?
RQ4: 도메인 복잡도 증가가 설계 원칙 준수 및 행동 안정성에 미치는 영향은 무엇인가?
2. 연구 방법론 (Methodology)
실험 설계:
모델: ChatGPT 4o-mini, Claude 3.5 Sonnet, Gemini 2.5 Flash (총 3 개 모델).
벤치마크: 두 가지 도메인 (병원 청구 시스템 - 중등도 복잡도, 센서 네트워크 - 고도 복잡도). 각 도메인에는 3 가지의 다른 문장 구조 (Paraphrased prompts) 를 사용.
프롬프트 전략 (3 가지):
Standard Prompting: 도메인 설명만 제공 (Baseline).
Rule-injection Prompting: 설계 원칙과 규칙을 명시적으로 프롬프트에 주입.
Preference-based Few-shot Prompting (제안 방법): 좋은 설계와 나쁜 설계의 예시를 대조적으로 제시하여, LLM 이 객체 지향 원칙과 패턴 일관성을 만족하는 설계를 선호하도록 유도하는 방식. (RLHF 와 유사하지만 경량화된 Few-shot 방식).
반복 실행: 각 조건당 10 회 반복 실행.
총 실험 횟수: 2(도메인) × 3(프롬프트) × 3(모델) × 3(전략) × 10(반복) = 540 회 실험.
평가 지표:
구조적 정확도 (M1.1): 전문가가 설계한 참조 모델과 비교한 정밀도 (Precision), 재현율 (Recall), F1 점수.
설계 원칙 준수 점수 (M1.2): 추상화, 캡슐화 등 OOAD 원칙 준수 여부 (0~1 점).
패턴 출현 점수 (M1.3): Observer, Strategy 패턴 등의 암묵적 적용 여부.
안정성 지수 (SI, M1.4): 반복 실행 및 프롬프트 변형에 따른 출력의 분산 정도 (높을수록 일관성 좋음).
3. 주요 기여 및 결과 (Key Contributions & Results)
A. 설계 원칙 및 패턴 준수 (RQ1, RQ2)
Preference-based 접근법의 우위: 명시적인 규칙 주입 (Rule-injection) 보다 **선호 기반 프롬프팅 (Preference-based prompting)**이 설계 원칙 준수와 패턴 일관성 구조 생성에 더 효과적이었습니다.
모델별 차이:
Claude: 구조적으로 일관된 다이어그램을 생성했으나, 공통 행동을 슈퍼클래스로 추상화하는 데 실패하는 경향이 있었습니다.
ChatGPT: 선호 기반 설정에서 가장 높은 설계 원칙 준수를 보였으나, 중복 상속 관계 등의 오류가 발생했습니다.
Gemini: 구조적 오류 (순환 상속, 누락된 클래스 등) 가 가장 많았으며, 규칙 주입 시 오히려 성능이 저하되는 경향을 보였습니다.
규칙 주입의 한계: 설계 규칙을 명시적으로 주입하는 것만으로는 LLM 의 설계 추론 능력을 근본적으로 향상시키지 못했습니다.
B. 행동적 신뢰성 및 안정성 (RQ3)
모델 의존적 행동 (Model-dependent Behavior): 프롬프트 전략보다 모델 선택이 설계 신뢰성에 더 큰 영향을 미쳤습니다.
Claude: 동일한 프롬프트에 대해 반복 실행 시 매우 높은 **디코딩 안정성 (Decoding Stability)**을 보였습니다. (구조가 일관되게 유지됨).
ChatGPT: 설계 발판 (Scaffolding) 이 정의되면 예측 가능한 행동을 보였으며, 오류가 무작위적이지 않고 체계적이었습니다.
Gemini: 프롬프트 변형과 반복 실행 모두에서 **높은 변동성 (Variability)**을 보였습니다. 클래스 수와 관계가 자주 바뀌어 아키텍처 드리프트 (Architectural Drift) 가 발생했습니다.
의미적 일관성 = 구조적 일관성: 의미는 비슷하더라도 구조가 달라지는 경우가 많아, 아키텍처 작업에서는 구조적 일관성이 필수적입니다.
C. 복잡도 증가에 따른 영향 (RQ4)
성능 저하: 센서 네트워크 (고도 복잡도) 시나리오로 넘어가면 모든 모델의 성능이 저하되었습니다.
암묵적 패턴 추론의 실패: 특히 이벤트 기반 아키텍처에서 Observer 패턴을 암묵적으로 추론하는 데 모든 모델이 실패했습니다. 이는 LLM 이 명시적 단서가 없는 동적 행동 의존성을 파악하는 데 한계가 있음을 시사합니다.
4. 연구의 의의 및 결론 (Significance & Conclusion)
패러다임의 전환: LLM 기반 설계 생성은 단순한 '기능 (Capability)'의 문제가 아니라 **'신뢰성 (Reliability)'**의 문제로 재정의되어야 합니다.
모델 선택의 중요성: 효과적인 프롬프팅 전략도 중요하지만, **모델의 고유한 행동 특성 (Behavioral Characteristics)**을 고려한 모델 선택이 아키텍처 신뢰성을 확보하는 데 더 결정적일 수 있습니다.
평가 기준의 확장: 문법적 정확성뿐만 아니라 **행동적 안정성 (Behavioral Stability)**과 구조적 일관성을 평가의 핵심 기준으로 포함해야 합니다.
향후 과제: 선호 기반 프롬프팅은 유망하지만, 복잡한 도메인과 암묵적 패턴 추론에는 여전히 한계가 있습니다. 향후에는 명시적 아키텍처 추론 모듈과의 하이브리드 접근, 비결정론 감소를 위한 미세 조정 (Fine-tuning) 및 앙상블 기법 등의 연구가 필요합니다.
핵심 요약: 이 연구는 LLM 이 UML 다이어그램을 생성할 때, 단순한 번역을 넘어 설계 합성을 수행하기 위해서는 선호 기반 프롬프팅이 유용하지만, 여전히 모델별 행동 안정성이 설계 품질을 좌우하는 핵심 변수임을 실증적으로 증명했습니다. 특히 복잡한 도메인에서는 LLM 의 암묵적 패턴 추론 능력이 부족하며, 신뢰할 수 있는 소프트웨어 설계를 위해서는 모델 선택과 강건성 확보가 필수적입니다.