Code Roulette: How Prompt Variability Affects LLM Code Generation

이 논문은 프롬프트의 변이가 LLM 의 코드 생성 품질에 미치는 영향을 정량화하기 위해 특정 작업이나 모델에 구애받지 않는 평가 파이프라인을 제안하고, 이를 통해 얻은 실험 결과와 오픈소스 코드를 공유합니다.

핵심

🍳 제목: "레시피의 작은 변화가 요리에 미치는 영향 (Code Roulette)"

1. 연구의 배경: 왜 이걸 연구했을까요?

요즘은 누구나 AI(대형 언어 모델) 에게 "이거 만들어줘"라고 말하면 코드를 짜줍니다. 마치 요리사에게 "오늘 저녁 뭐 먹지?"라고 묻는 것과 비슷하죠.

하지만 문제는 사람마다 같은 음식을 설명하는 방식이 다르다는 점입니다.

• 사람 A: "소금 좀 넣어서 간을 맞춰줘."
• 사람 B: "간을 적당히 해줘."
• 사람 C: "소금 조금만."

이 세 가지 말은 본질적으로 같은 뜻이지만, AI 요리사가 이 말들을 들었을 때 만들어내는 요리의 맛 (코드) 이 완전히 달라질 수 있을까요? 만약 "소금"을 "소금"이라고 오타를 내거나, "간"을 "맛"이라고 바꿔 말하면 AI 는 당황해서 엉뚱한 요리를 내놓을까요?

이 연구는 바로 **"AI 요리사가 말투의 작은 변화에 얼마나 민감하게 반응하는지"**를 측정하는 실험입니다.

2. 실험 방법: "AI 요리사 테스트"

연구자들은 4 명의 유명한 AI 요리사 (GPT-4o, Claude, Gemini, Llama 등) 를 불러모아 다음과 같은 테스트를 진행했습니다.

• 기본 레시피 (프롬프트): "파이썬으로 계산기를 만들어줘."라는 기본 명령을 줍니다.
• 변형 실험 (Augmentation): 이 명령을 조금씩 망가뜨려 봅니다.
  1. 타이핑 실수 (Typos): "계산기"를 "계산기" (키보드 옆 키 누름) 로 바꿈.
  2. 유의어 교체 (Synonyms): "만들어줘"를 "작성해줘"로 바꿈.
  3. 문장 재구성 (Paraphrasing): "파이썬으로 계산기 만들어줘"를 "파이썬 언어를 써서 계산기 기능을 구현해 줘"라고 다르게 표현.

그리고 AI 가 만들어낸 코드가 원래 코드와 얼마나 다른지 TSED라는 자 (코드 구조 비교 도구) 로 측정했습니다.

3. 주요 발견: 놀라운 결과들

① 오타는 치명적이다 (타이핑 실수)

• 비유: 요리사에게 "소금"이라고 말하려다 실수로 "송금"이라고 말하면, 요리사는 당황해서 완전히 다른 요리를 만들거나 요리를 포기합니다.
• 결과: AI 는 오타에 매우 민감했습니다. 명령에 아주 작은 오타만 있어도 AI 가 만들어낸 코드는 완전히 엉뚱한 방향으로 변했습니다.

② 단어 바꾸기는 덜 민감하다 (유의어/재구성)

• 비유: "소금" 대신 "간"이라고 하거나, "소금 좀 넣어" 대신 "간을 맞춰줘"라고 해도 요리사는 대충 이해하고 비슷한 요리를 만듭니다.
• 결과: 단어를 바꾸거나 문장을 살짝 다르게 써도 AI 는 비교적 견고하게 같은 코드를 만들어냈습니다.

③ AI 가 배운 적이 있는 문제는 강하다 (데이터 오염)

• 비유: 요리사가 이미 레시피 책에 있는 유명한 요리를 만들 때는, 사용자가 말을 조금 실수해도 "아, 그거죠?" 하고 금방 알아맞힙니다. 하지만 새로운 요리를 시키면 조금만 말투가 달라져도 당황합니다.
• 결과: AI 가 훈련 데이터에 이미 많이 접한 유명한 문제 (LeetCode 구형 문제) 는 오타가 있어도 코드가 잘 변하지 않았습니다. 하지만 AI 가 처음 보는 새로운 문제나, 연구진이 직접 만든 독창적인 문제에서는 작은 말실수에도 코드가 크게 달라졌습니다.

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

이 연구는 우리에게 중요한 메시지를 줍니다.

1. AI 는 완벽하지 않다: 우리가 "똑같은 뜻"이라고 생각해도, AI 는 말투나 오타 하나에 따라 완전히 다른 코드를 뽑아낼 수 있습니다.
2. 신뢰를 쌓는 방법: AI 코드를 믿고 쓰려면, 사용자가 명령을 내릴 때 얼마나 정확해야 하는지, 혹은 AI 개발자가 어떻게 AI 를 더 튼튼하게 만들어야 하는지 이해해야 합니다.
3. 새로운 기준 필요: 기존에 AI 성능을 평가할 때 쓰던 문제들은 AI 가 이미 다 외워서 (훈련 데이터에 있어서) 너무 쉽게 풀고 있었습니다. 진짜 실력을 보려면 AI 가 처음 보는 새로운 문제로 테스트해야 합니다.

🎯 한 줄 요약

"AI 에게 코딩을 시킬 때, 우리가 실수한 오타나 말투의 작은 변화만으로도 AI 가 만들어내는 코드가 완전히 달라질 수 있다는 것을 증명했습니다. 즉, AI 와 대화할 때는 말을 정확하고 명확하게 해야 한다는 교훈을 줍니다."

이 연구는 앞으로 우리가 AI 와 더 잘 소통하고, 더 안정적인 코드를 얻기 위한 첫걸음이 될 것입니다.

기술 요약

논문 요약: Code Roulette (프롬프트 변동성이 LLM 코드 생성에 미치는 영향)

1. 문제 정의 (Problem)

대형 언어 모델 (LLM) 을 활용한 코드 생성은 소프트웨어 개발의 진입 장벽을 낮추고 개발 속도를 높이는 혁신적인 도구로 자리 잡았습니다. 그러나 생성된 코드의 품질과 기능은 사용자가 입력한 프롬프트의 질에 크게 의존합니다.

• 핵심 문제: 사용자의 배경, 교육 수준, 소프트웨어 개발에 대한 친숙도에 따라 동일한 요구사항을 표현하는 프롬프트가 다르게 작성될 수 있습니다.
• 불확실성: 현재 LLM 은 사용자의 요구사항을 완벽하게 이해한다고 확신할 수 없으며, 프롬프트의 사소한 변화 (오타, 동의어 교체, 문장 재구성 등) 가 생성된 코드의 구조나 기능에 얼마나 민감하게 반응하는지 정량화된 연구가 부족합니다.
• 목표: 입력 프롬프트의 변동성 (Variability) 에 대한 LLM 의 민감도를 측정하여, 코드 생성 과정의 신뢰성을 높이고 표준화된 출력을 위한 가이드라인을 마련하는 것입니다.

2. 방법론 (Methodology)

저자들은 프롬프트 변동성에 대한 LLM 의 민감도를 측정하기 위해 모델 및 작업에 독립적인 (agnostic) 평가 파이프라인을 설계했습니다.

• 평가 파이프라인 (Algorithm 1):

  1. 기준선 설정: 원본 프롬프트 ($p$) 로 $n$개의 독립적인 코드 샘플을 생성하여 기준 데이터셋 ($C_{ref}$) 을 만듭니다.
  2. 프롬프트 증강 (Augmentation): 증강 함수 $F$를 사용하여 프롬프트에 변형을 가합니다. 변형 비율 ($r \in [0, 1]$) 을 0 에서 1 까지 단계적으로 증가시키며 변형된 프롬프트를 생성합니다.
  3. 코드 생성: 변형된 프롬프트로 다시 $n$개의 코드 샘플 ($C_{aug}$) 을 생성합니다.
  4. 거리 측정: 생성된 변형 코드와 기준 코드 간의 불일치를 거리 함수 $D$로 계산하고 평균 거리를 도출합니다.

• 사용된 증강 기법 (3 가지):

  1. 키보드 오타 (Keyboard Typos): QWERTY 키보드에서 인접한 키로 문자를 무작위 교체 (NLPaug 라이브러리 사용).
  2. 동의어 교체 (Synonyms): WordNet 기반의 동의어로 단어를 무작위 교체.
  3. 개사 (Paraphrasing): LLM(Gemini) 의 번역/개사 기능을 활용하여 어휘는 바꾸되 의미는 유지하는 문장 생성.

• 거리 측정 지표:

  • TSED (Tree Similarity of Edit Distance): 생성된 코드의 문법적 (Syntactic) 구조 차이를 측정하는 지표.
  • 선정 이유: BLEU 나 BERT Score 와 같은 일반 텍스트 유사도 지표는 코드 평가에 적합하지 않음 (범위 제한, Ceiling 효과, 계산 비용 등). TSED 는 0(완전 다름) 에서 1(완전 동일) 사이의 값을 가지며, 코드가 기능적으로 정확하더라도 구조가 다르면 사용자에게 다른 구현체로 보일 수 있다는 점을 고려하여 일관성 (Consistency) 측정에 초점을 맞춤.

• 데이터셋:

  1. LeetCode (Old): 기존에 널리 알려진 문제들 (LLM 학습 데이터에 포함되었을 가능성이 높음).
  2. LeetCode (New): 2025 년 3 월에 게시된 최신 문제 (학습 데이터 미포함).
  3. Our Dataset: 저자들이 직접 제작한 22 개의 개방형 (Open-ended) 과제 (시뮬레이션, 알고리즘, 게임 등). 정답이 하나로 정해지지 않은 문제들.

• 평가 대상 모델: GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash, Llama 3.3 70B (Temperature=0 으로 설정하여 무작위성 최소화).

3. 주요 결과 (Key Results)

• 증강 기법별 민감도 차이:

  • 키보드 오타: 모든 모델에서 가장 민감하게 반응. 변형 비율이 0.0~0.6 사이에서 코드 유사도 (TSED) 가 급격히 하락 (약 0.3 수준까지 감소). 이는 오타가 프롬프트의 가독성을 해쳐 모델의 이해를 방해함을 시사.
  • 동의어 및 개사: 오타에 비해 상대적으로 강건 (Robust). 초기 변형 시 유사도가 약간 하락하지만, 그 이후에는 완만하게 감소. 특히 Gemini 2.0 Flash는 동의어 변형에 가장 강건한 성능을 보임.

• 데이터셋별 차이 (데이터 오염 현상):

  • LeetCode (Old): 변형에 대한 민감도가 가장 낮음. 모델이 학습 데이터에 포함된 문제를 인식하여 변형된 프롬프트에서도 일관된 코드를 생성함 (데이터 오염 효과).
  • LeetCode (New): 학습 데이터에 포함되지 않았으나 표준적인 코딩 문제이므로 여전히 높은 안정성을 보임.
  • Our Dataset (직접 제작): 가장 높은 민감도를 보임. 프롬프트의 10% 만 변형해도 TSED 가 0.5 이하로 급락. 이는 모델이 학습 데이터에 없는 새로운 유형의 문제에서는 프롬프트의 작은 변화에도 출력 구조가 크게 달라질 수 있음을 의미.

• 모델 간 비교:

  • GPT-4o mini 와 Gemini 2.0 Flash 는 변형 없는 프롬프트에서도 높은 일관성 (0.9 이상) 을 보임.
  • Llama 3.3 과 Claude 3 Haiku 는 변형 없는 프롬프트에서도 상대적으로 불안정한 경향을 보임.

• 통계적 유의성: Friedman 검정 및 Kruskal-Wallis 검정을 통해 증강 비율과 데이터셋에 따른 민감도 차이가 통계적으로 유의미함 ($p < 0.001$) 을 확인.

4. 주요 기여 (Key Contributions)

1. 새로운 평가 절차 제안: 특정 프로그래밍 작업이나 LLM 모델에 구애받지 않고, 프롬프트 증강에 대한 민감도를 측정하는 범용 평가 파이프라인을 제시.
2. 다양한 LLM 에 대한 민감도 분석: 4 개의 주요 LLM 을 대상으로 오타, 동의어, 개사 등 다양한 변형에 대한 실험적 증거를 제공.
3. 오픈 소스 및 데이터셋 공개: 연구 재현을 위한 코드와 새로운 개방형 프로그래밍 과제 데이터셋을 공개하여 커뮤니티에 기여.

5. 의의 및 시사점 (Significance)

• 신뢰 구축: LLM 기반 코드 생성 시스템의 신뢰성을 높이기 위해, 사용자의 프롬프트 작성 방식 (배경 지식, 표현 차이) 이 결과에 미치는 영향을 정량적으로 이해할 수 있는 기반을 마련.
• 개발 가이드라인: 민감도가 높은 경우 (예: 오타 발생 시), 사용자에게 추가적인 안내를 제공하거나 프롬프트를 정규화하는 기술이 필요함을 시사.
• 데이터 오염 문제 제기: 기존 벤치마크 (LeetCode 등) 를 사용할 경우 모델이 학습 데이터를 기억하여 과대평가될 수 있음을 경고하고, 새로운 데이터셋의 중요성을 강조.
• 미래 연구 방향: 단순한 1 단계 상호작용을 넘어 대화형 (Dialog) 상호작용, 다단계 파이프라인, 그리고 사용자의 배경에 따른 문제 분해 (Problem Decomposition) 방식의 차이를 모델링한 연구로 확장 가능.

이 연구는 LLM 이 생성하는 코드의 구조적 일관성이 프롬프트의 미세한 변화에 얼마나 취약한지를 보여주며, 보다 견고하고 신뢰할 수 있는 AI 기반 소프트웨어 개발 환경을 구축하기 위한 중요한 통찰을 제공합니다.