A framework for assessing the capabilities of code generation of constraint domain-specific languages with large language models

이 논문은 LLM 이 일반 프로그래밍 언어보다 도메인 특화 언어 (DSL) 코드 생성 능력이 떨어지는 문제를 해결하기 위해, 생성된 코드의 잘 형성됨과 정확성을 평가하는 프레임워크를 제안하고 이를 OCL 및 Alloy 와 같은 제약 언어에 적용하여 실험적 통찰과 개선 방안을 제시합니다.

핵심

🍳 핵심 비유: 요리사 (AI) 와 레시피 (프로그래밍 언어)

이 연구의 주인공은 **거대한 데이터를 먹고 자란 AI 요리사 (대형 언어 모델, LLM)**입니다. 이 요리사는 수많은 레시피를 보고 배워서 "이 재료로 이런 요리를 만들어줘"라고 하면 요리를 해줍니다.

하지만 문제는 레시피의 종류입니다.

1. 인기 있는 레시피 (Python, Java 등): 인터넷에 레시피가 수백만 개 있어서 요리사가 아주 잘합니다.
2. 전문가용 레시피 (OCL, Alloy 등): 특정 목적 (예: 시스템의 안전 규칙, 데이터베이스 제약 조건) 만 위한 아주 작고 전문적인 레시피입니다. 레시피가 거의 없어서 요리사가 당황하거나 엉뚱한 요리를 만들어냅니다.

이 논문은 **"이 전문 레시피 (DSL) 를 요리할 때 AI 가 얼마나 잘하는지, 그리고 어떻게 하면 더 잘하게 할 수 있는지"**를 평가하는 **새로운 평가 시스템 (프레임워크)**을 제안했습니다.

---

🔍 연구 내용: 무엇을 확인했나요?

연구진은 이 평가 시스템을 이용해 4 가지 다른 AI 요리사 (GPT-4, Llama 등) 를 시험했습니다. 그리고 다음과 같은 4 가지 실험을 해보았습니다.

1. 언어에 따라 실력이 다를까? (Target Language)

• 결과: 당연히 Python(인기 언어) 이 압도적으로 잘했습니다. 거의 100% 완벽한 요리를 냈죠.
• 전문 언어 (OCL, Alloy) 는? 요리사가 레시피를 잘 몰라서 재료를 잘못 섞거나 (문법 오류), 레시피의 의도와 다른 요리를 내는 (오류) 경우가 많았습니다. 특히 작은 AI 모델들은 전문 레시피를 아예 못 만들기도 했습니다.

2. 어떤 AI 요리사를 써야 할까? (LLM Selection)

• 결과: GPT-4가 가장 훌륭했습니다. 반면, 오픈소스 모델 (무료로 공개된 모델) 은 전문 레시피를 다룰 때 너무 많이 망쳤습니다.
• 교훈: 전문적인 일을 시킬 때는 무조건 가장 똑똑하고 훈련된 AI 를 써야 합니다.

3. 지시하는 방법 (프롬프트) 이 중요할까? (Prompt Engineering)

• 결과: 의외로 지시 방법 (레시피 설명 방식) 에 따른 차이는 크지 않았습니다.
• 이유: AI 가 이미 해당 언어를 잘 알고 있다면, 지시를 어떻게 내리든 결과는 비슷했습니다. 하지만 AI 가 언어를 잘 모르면 지시를 아무리 잘해도 소용없었습니다.
• 교훈: AI 가 언어를 잘 안다면, 복잡한 지시보다는 간단한 지시가 오히려 비용도 절약하고 효율적입니다.

4. 실수를 고치는 과정이 도움이 될까? (Code Repair & Multiple Attempts)

• 결과: 가장 중요한 발견!
  • 한 번에 여러 번 시도하기 (Multiple Attempts): 같은 주문을 3 번 내보면, 그중 하나는 잘 만들어질 확률이 높아집니다.
  • 실수 고치기 (Code Repair): AI 가 엉뚱한 요리를 내면, "이거 잘못됐어, 고쳐줘"라고 하면 AI 가 고쳐서 다시 내옵니다.
  • 결론: 여러 번 시도하고, 틀리면 고치게 하는 것이 가장 좋은 결과를 냈습니다. (물론 비용은 더 들지만요.)

---

💡 이 연구가 우리에게 주는 교훈 (요약)

이 논문은 개발자나 AI 를 사용하는 사람들에게 다음과 같은 실용적인 조언을 줍니다.

1. 도구를 잘 고르세요: 전문적인 언어 (DSL) 를 다룰 때는 무조건 가장 똑똑한 AI 모델을 선택하세요. 작은 모델은 전문 분야에서는 쓸모가 없을 수 있습니다.
2. 지시보다 반복이 중요: AI 가 언어를 잘 안다면, 지시를 길게 적는 것보다 **"여러 번 시도해봐"**라고 하거나 **"틀리면 고쳐줘"**라고 하는 것이 훨씬 효과적입니다.
3. 한 번에 여러 개 시키세요: 같은 분야의 규칙들을 한 번에 묶어서 요청하면, AI 가 서로 충돌하지 않고 일관된 요리를 만들어냅니다. 하나씩 따로 시키면 AI 가 기억을 못 해서 앞뒤가 안 맞을 수 있습니다.

🎁 결론

이 논문은 **"AI 가 코드를 잘 쓰게 하려면, 무조건 지시를 잘 짜는 게 아니라, 알맞은 AI 를 고르고, 실수를 고쳐주는 과정을 거치는 것이 더 중요하다"**는 사실을 증명했습니다. 마치 요리사가 처음부터 완벽할 수는 없으니, 맛을 보고 고쳐주는 과정이 결국 최고의 요리를 만든다는 것과 같습니다.

기술 요약

이 논문은 대규모 언어 모델 (LLM) 을 사용하여 텍스트 명세로부터 제약 도메인 특화 언어 (Constraint DSLs, 예: OCL, Alloy) 의 코드를 생성할 때의 능력을 평가하기 위한 일반적인 평가 프레임워크를 제안하고 있습니다. 또한, 이 프레임워크를 활용하여 OCL, Alloy 와 같은 DSL 과 범용 프로그래밍 언어 (Python) 에 대한 LLM 의 성능을 비교 분석했습니다.

다음은 논문의 주요 내용을 기술적으로 요약한 것입니다.

1. 문제 정의 (Problem)

• LLM 의 DSL 성능 저하: LLM 은 Python, Java 등 데이터가 풍부한 범용 프로그래밍 언어 (GPL) 에서는 뛰어난 코드 생성 능력을 보이지만, 데이터가 부족한 도메인 특화 언어 (DSL), 특히 형식적인 제약 언어 (OCL, Alloy) 에서는 성능이 크게 떨어집니다.
• DSL 생성의 고유한 어려움:
  • 저자원 (Low-resource): 학습 데이터가 부족하여 문법과 의미론을 정확히 학습하기 어렵습니다.
  • 이중 작업 관리: 제약 조건을 생성할 때 해당 제약이 적용될 도메인 모델 (스키마) 과 제약 조건 자체를 동시에 관리해야 합니다.
  • 선언적 특성: 절차적 언어와 달리 실행보다는 검증 (Verification) 이 필요하며, 전역적 (Global) 인 제약 조건들이 서로 상호작용하여 의도치 않은 부작용을 일으킬 수 있습니다.
• 평가의 부재: 생성된 코드의 품질 (형식적 정확성 및 논리적 정확성) 을 체계적으로 평가할 수 있는 표준 프레임워크가 부족합니다.

2. 방법론 (Methodology)

저자들은 LLM 기반 코드 생성의 품질을 평가하기 위해 모듈형 평가 프레임워크를 설계하고 구현했습니다.

• 프레임워크 구조:
  1. 프롬프트 빌딩 (Prompt Building): 다양한 프롬프트 템플릿 (9 가지), 증강 기법 (도메인 설명, 모델 설명 포함 등), 그리고 작업 전달 방식 (배치, 순차, 고립) 을 파라미터화하여 구성합니다.
  2. 코드 생성 및 추출: 선택된 LLM 에게 프롬프트를 전송하고 생성된 코드를 추출합니다. 여러 번의 시도 (Multiple attempts) 를 지원합니다.
  3. 형식성 검증 (Well-formedness Check): 생성된 코드가 해당 언어의 문법 규칙을 따르는지 파서 (Parser) 를 통해 검증합니다. 실패 시 코드 수리 (Code Repair) 과정을 거쳐 LLM 에게 오류 메시지를 제공하고 수정을 요청합니다 (단, 1 회 수리만 시도).
  4. 정확성 검증 (Correctness Check): 형식성이 검증된 코드가 주어진 명세를 충족하는지 확인합니다.
     • LLM-as-a-Judge: 생성된 코드를 LLM 이 직접 평가하여 정답 여부를 판단하는 방식을 주력으로 사용했습니다.
     • 수동 평가: 일부 데이터에 대해 인간 전문가가 수동으로 검증하여 자동 평가의 신뢰도를 측정했습니다.
• 실험 설정:
  • 대상 언어: OCL, Alloy (DSL), Python (GPL).
  • 사용 LLM: GPT-4o, GPT-4o-mini, DeepSeek Coder 6.7B, Llama 3.1.
  • 데이터셋: 기존 연구의 데이터를 기반으로 도메인 설명을 추가하여 30 개의 도메인 모델과 182 개의 제약 조건으로 구성된 데이터셋을 구축했습니다.
  • 규모: 총 약 98,397 개의 코드 생성 작업을 평가했습니다.

3. 주요 기여 (Key Contributions)

1. 유연한 평가 프레임워크: 프롬프트 템플릿, LLM 선택, 코드 수리, 다중 시도 등 코드 생성 과정의 모든 결정을 파라미터화하여 다양한 시나리오를 체계적으로 비교할 수 있는 모듈형 프레임워크를 제안했습니다.
2. DSL 코드 생성에 대한 심층 연구: OCL 과 Alloy 와 같은 제약 언어의 생성 난이도와 한계를 분석하고, 이를 범용 언어 (Python) 와 비교하여 기존 데이터셋에 합성 데이터를 추가했습니다.
3. 대규모 실험 및 최적 설정 도출: 90,000 건 이상의 실험을 통해 다양한 설정 조합의 영향을 분석하고, 특정 작업 유형에 가장 효과적인 설정을 도출했습니다.

4. 실험 결과 (Results)

• 언어별 성능 차이:
  • Python: LLM 이 가장 높은 성능 (형식성 및 정확성 모두) 을 보였습니다.
  • OCL 및 Alloy: Python 에 비해 형식성 (Well-formedness) 과 정확성 (Correctness) 모두에서 성능이 현저히 낮았습니다. 특히 Open-source 모델 (DeepSeek, Llama) 은 제약 관련 코드를 생성하는 데 거의 실패했습니다.
  • 원인: DSL 은 niche 연산자 (예: Alloy 의 집합 연산자) 가 많고 표준 라이브러리가 부족하여 LLM 이 문맥을 잘못 이해하거나 할루시네이션 (허위 사실 생성) 을 일으키기 쉽습니다.
• LLM 모델별 성능:
  • GPT-4o가 모든 언어에서 가장 우수한 성능을 보였습니다.
  • GPT-4o-mini는 Python 과 Alloy 에서는 좋았으나 OCL 에서는 성능이 떨어졌습니다 (OCL 학습 데이터 부재 추정).
  • Open-source 모델은 제약 DSL 생성에는 실용성이 낮았습니다.
• 프롬프트 엔지니어링의 영향:
  • 프롬프트 템플릿의 선택은 언어와 모델 조합에 따라 일부 유의미한 차이를 보였으나, 전반적으로는 모델이 언어에 익숙한 경우 프롬프트 최적화의 효과가 미미했습니다.
  • 가장 적은 토큰을 사용하는 간단한 프롬프트 (PT1) 가 효율성 면에서 권장되었습니다.
• 다중 시도 및 코드 수리:
  • 다중 시도 (Pass@k): 시도 횟수를 늘리면 (k=3) 정확도가 선형적으로 증가했습니다.
  • 코드 수리: 초기 생성 코드가 틀렸을 때 LLM 에게 수정을 요청하면 정확도가 10~20% 향상되었습니다.
  • 최고 전략: '다중 시도'와 '코드 수리'를 결합하는 것이 가장 높은 정확도를 달성했으나, 비용 (LLM 호출 횟수) 이 가장 많이 듭니다.
• 작업 전달 방식:
  • 여러 제약 조건을 한 번에 배치 (Batch) 로 전달하는 것이 개별적으로 전달하는 것보다 일관성이 높고 통합 오류가 적었습니다.

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

• 실무 가이드라인 제시:
  • 저자원 DSL 의 경우 모델 선택이 프롬프트 엔지니어링보다 더 중요합니다.
  • 모델이 언어를 잘 알고 있다면 복잡한 프롬프트보다는 기본 검증과 다중 시도, 코드 수리를 활용하는 것이 효율적입니다.
  • 동일한 도메인의 여러 제약 조건은 하나의 프롬프트로 묶어 전달하는 것이 좋습니다.
• 연구적 의의: 이 연구는 LLM 이 DSL 코드 생성에 직면한 한계를 명확히 규명하고, 이를 평가하고 개선하기 위한 체계적인 방법론을 제공했습니다. 특히 "LLM-as-a-Judge"를 대규모 평가에 적용한 사례는 향후 연구에 중요한 기준이 됩니다.
• 향후 과제: RAG(검색 증강 생성) 기술 통합, LLM 에 검증 도구 (Tool) 제공 (MCP 등), 그리고 파인튜닝을 평가 프레임워크에 통합하는 방향이 제시되었습니다.

요약하자면, 이 논문은 LLM 이 범용 언어에 비해 제약 DSL 에서 겪는 어려움을 체계적으로 분석하고, 적절한 모델 선택과 다중 시도/수리 전략이 프롬프트 최적화보다 더 결정적인 요소임을 입증했습니다.