"Should I Give Up Now?" Investigating LLM Pitfalls in Software Engineering

이 논문은 26 명의 소프트웨어 엔지니어를 대상으로 한 연구를 통해 LLM 의 부정확한 응답이 작업 포기 확률을 11 배 증가시키는 등 주요 실패 요인을 규명하고, 이를 극복하기 위한 프롬프트 정교화 등의 완화 전략과 향후 도구의 방향성을 제시합니다.

핵심

🍳 핵심 이야기: "요리 비서가 요리를 망쳐요"

연구진은 개발자 26 명을 모아, 복잡한 웹사이트를 만드는 과제를 주고 ChatGPT 를 사용하게 했습니다. 마치 초보 요리사에게 "이 복잡한 파스타 레시피를 만들어줘"라고 시키고, 옆에 서 있는 AI 비서가 도와주는 상황을 상상해 보세요.

결과는 어땠을까요? 대부분의 요리사 (개발자) 가 비서 (ChatGPT) 를 믿지 못하고 결국 "이건 내가 직접 할래!"라며 비서를 내쫓았습니다.

🚨 왜 포기했을까요? (9 가지 실패 유형)

AI 비서가 요리를 도와주려다 오히려 상황을 더 어렵게 만든 9 가지 주요 실수들이 있었습니다. 이를 세 가지 큰 카테고리로 나누어 볼 수 있습니다.

1. "요리 레시피가 반쪽짜리거나 엉뚱해요" (부족하거나 틀린 답변)

• 일부만 알려줌: "파스타 소스 만들어줘"라고 했더니, "토마토를 다져라"까지만 알려주고 나머지는 생략했습니다. 요리사는 나머지 재료를 찾아야 하는 수고를 치러야 했습니다.
• 준비 과정 생략: "불을 켜고 시작해"라고 말해주지 않아, 요리사가 가스레인지도 켜지 않은 채 재료를 꺼내 헤맸습니다.
• 틀린 정보: "소금 100g 넣으세요"라고 엉뚱한 양을 알려줘, 요리사가 맛을 보고 "이건 못 먹겠다"며 화를 냈습니다.

2. "말이 너무 많고 복잡해요" (인지 과부하)

• 너무 긴 설명: "간단히 소스만 만들어줘"라고 했더니, 10 페이지 분량의 요리 역사와 과학 이론을 섞은 긴 글을 써냈습니다. 요리사는 그 속에서 진짜 레시피를 찾아내느라 지쳐버렸습니다.
• 불필요하게 복잡한 방법: "간단히 끓여줘"라고 했더니, "이건 전문 셰프가 쓰는 5 단계 정교한 기법이 필요해"라며 어려운 방법을 제안했습니다. 요리사는 "그냥 간단하게 끓이면 안 되나?"라고 생각하며 답답해했습니다.

3. "이전 대화 기억을 못 해요" (맥락 상실)

• 기억력 부족: "양파를 다져서 넣으라"고 했다가, 다음에 "소금 간을 해줘"라고 했을 때, "어떤 양파를 말하는 거죠? 아까 다진 양파요?"라며 이전 대화를 잊어버렸습니다. 요리사는 매번 처음부터 다시 설명해야 했습니다.
• 변화를 무시: 요리사가 "소금 양을 줄여줘"라고 했더니, AI 는 "네, 알겠습니다"라고 말하면서도 소금 양은 그대로 유지했습니다. 요리사는 "이 비서는 내 말을 안 들었나?"라고 생각하며 비서를 떠났습니다.

🛠️ 요리사들이 어떻게 대응했나요? (대응 전략)

요리사들은 비서가 실수할 때마다 다양한 방법으로 상황을 수습하려 노력했습니다.

• 조금씩 나누어 시키기: "한 번에 다 만들어줘" 대신 "일단 소스만 만들어줘, 그다음에 면을 삶아줘"라고 단계별로 지시했습니다.
• 말을 다듬기: "이거 좀 더 구체적으로 말해줘"라고 요청하며 질문을 수정했습니다.
• 직접 확인하기: AI 가 알려준 레시피를 그대로 믿지 않고, 직접 맛을 보고 수정했습니다.
• 결국 다른 길로: 그래도 안 되면 "이건 ChatGPT 로는 안 되겠어"라고 생각하며 구글이나 레시피 책 (기존 자료) 을 찾아보거나, 아예 비서를 내치고 직접 요리를 시작했습니다.

📊 통계로 본 놀라운 사실

연구진은 데이터를 분석하여 몇 가지 놀라운 사실을 발견했습니다.

1. 무용한 답변은 11 배 더 위험해요: ChatGPT 가 쓸모없는 답변을 한 번만 해도, 요리사가 비서를 포기할 확률이 11 배나 높아졌습니다.
2. 질문을 많이 할수록 버티는 법을 배워요: 질문을 한 번 더 할 때마다 포기할 확률은 17% 씩 줄어듭니다. 즉, "아직은 포기하지 말고 더 물어봐!"라는 뜻입니다.
3. 요리 실력이 있으면 더 잘 버텨요: 요리 실력이 좋은 사람 (경험 많은 개발자) 은 실수를 더 잘 파악하고 고쳐서 비서를 더 오래 사용했습니다. 반면 초보자는 조금만 실수가 있어도 쉽게 포기했습니다.

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

이 논문은 **"AI 가 완벽해지면 모든 문제가 해결될 거야"**라는 생각을 깨뜨립니다.

• AI 는 완벽한 비서가 아닙니다: 아무리 똑똑한 AI(GPT-5.1 등) 가 나와도, 여전히 기억을 잃거나 엉뚱한 답을 할 수 있습니다.
• 사용자의 역할이 중요합니다: AI 를 잘 쓰려면, AI 가 실수할 때 어떻게 고칠지, 언제 다른 도구를 쓸지 판단하는 사람의 능력이 훨씬 더 중요합니다.
• 포기는 합리적인 선택입니다: AI 가 계속 실수를 반복하면, 시간을 아끼기 위해 "이건 내가 직접 할래"라고 포기하는 것은 실패가 아니라 현명한 선택입니다.

🌟 결론: "지금 당장 포기해야 할까?"

결론은 **"상황에 따라 다르다"**입니다.

• 만약 AI 가 계속 엉뚱한 답을 하고, 당신이 설명을 고쳐도 똑같은 실수를 반복한다면? 네, 지금 당장 포기하고 다른 방법을 찾아보세요. (연구 결과에 따르면, 쓸모없는 답변이 계속되면 11 배 더 빨리 포기하게 됩니다.)
• 하지만 만약 당신이 조금 더 질문을 다듬고, 실수를 직접 고쳐주며 인내한다면? AI 는 여전히 훌륭한 조력자가 될 수 있습니다.

이 연구는 우리에게 **"AI 를 맹신하지 말고, 때로는 등 돌리고 직접 해보는 용기도 필요하다"**는 메시지를 전합니다. AI 는 훌륭한 '조수'일 뿐, '주인'은 결국 우리 자신이어야 합니다.

기술 요약

논문 요약: "Should I Give Up Now?" Investigating LLM Pitfalls in Software Engineering

(소프트웨어 공학에서의 LLM 함정 연구: "지금 포기해야 할까?")

이 논문은 소프트웨어 엔지니어가 복잡한 웹 개발 작업 중 ChatGPT 와 같은 대규모 언어 모델 (LLM) 을 사용할 때 발생하는 실패 유형, 그 원인, 그리고 사용자가 이를 어떻게 완화하거나 결국 도구를 포기하는지에 대한 실증적 연구를 다룹니다.

---

1. 연구 배경 및 문제 제기 (Problem)

• 배경: LLM 기반 AI 어시스턴트 (ChatGPT, Copilot 등) 는 개발자의 생산성을 높이고 인지 부하를 줄이는 도구로 널리 채택되고 있습니다.
• 문제: 그러나 LLM 의 응답은 정확하지 않거나, 맥락을 잃거나, 과도한 정보를 제공하여 오히려 생산성을 저해하는 경우가 많습니다. 기존 연구는 주로 LLM 의 단일 턴 (one-shot) 성능이나 성공적인 사례에 집중했으나, 복잡한 다단계 (multi-step) 작업 중 LLM 이 실패할 때 개발자가 어떻게 반응하고, 왜 도구를 포기하는지에 대한 심층적인 이해가 부족했습니다.
• 핵심 질문: 개발자는 LLM 의 부정확한 응답을 어떻게 인지하고 대처하며, 어떤 요인이 LLM 사용 중단을 (Abandonment) 초래하는가?

2. 연구 방법론 (Methodology)

• 연구 설계: 26 명의 참가자 (대학원생 및 전문 소프트웨어 개발자) 를 대상으로 복잡한 웹 애플리케이션 개발 작업을 수행하게 한 관찰 연구 (Observational Study) 를 진행했습니다.
  • 작업: HTML, CSS, JavaScript 를 사용하여 여러 파일에 걸쳐 시각적 요소를 통합하는 웹 페이지 제작.
  • 도구: ChatGPT-4, GPT-4o, 그리고 최신 모델인 GPT-5.1 을 사용하여 모델 간 비교 및 결과의 일관성 검증 (Replication) 을 수행했습니다.
  • 데이터 수집: 화면 녹화, 생각 소리 내기 (Think-aloud) 프로토콜, 대화 로그, 작업 완료도 평가, 그리고 사후 인터뷰를 통해 정성적 및 정량적 데이터를 수집했습니다.
• 분석 방법:
  • 정성적 분석: 대화 로그와 행동 데이터를 삼각측량 (Triangulation) 하여 실패 유형, 원인, 완화 전략을 코딩 및 분류했습니다.
  • 정량적 분석: LLM 응답의 유용성, 작업 수행 점수, 프롬프트 횟수, 코딩 경험 등을 독립 변수로 하여 로지스틱 회귀 분석 (Logistic Regression) 을 통해 'LLM 포기 (Abandonment)' 확률에 미치는 영향을 검증했습니다.

3. 주요 기여 및 발견 (Key Contributions & Results)

A. LLM 실패 유형 9 가지 및 3 가지 카테고리 (RQ1)

연구는 LLM 과의 상호작용 중 발생한 92 건의 실패 사례를 분석하여 9 가지 실패 유형을 도출하고 이를 3 가지 범주로 분류했습니다. 이는 GPT-4 에서 GPT-5.1 로 모델이 업데이트됨에도 불구하고 유사하게 발생했습니다.

1. 불완전하거나 잘못된 응답 (Incomplete or Incorrect Responses):
   • F1 (불완전한 답변): 긴 프롬프트나 전체 코드베이스를 요청 시 핵심 세부 사항이 누락됨.
   • F3 (선행 조건 누락): 설치 단계나 의존성 같은 필수 설정 단계를 생략함.
   • F7 (오류 있는 답변): 버그가 있거나 잘못된 코드를 생성함.
2. 인지 과부하 및 정보 관리 실패 (Cognitive Overload & Information Mismanagement):
   • F2 (압도적인 답변): 필요한 부분 전체를 재생성하여 긴 텍스트를 제공함.
   • F4 (과도하게 복잡한 답변): 간단한 해결책 대신 복잡한 알고리즘을 제안함.
   • F8 (잘못된 이미지 생성): 시각적 요청에 대해 부정확한 이미지를 생성하거나 생성 불가임을 인정하지 않음.
3. 맥락 상실 및 불필요한 노력 (Lack of Context Retention & Redundant Effort):
   • F5 (맥락 부재): 이전 대화 내용을 기억하지 못해 사용자가 다시 설명해야 함.
   • F6 (무관한 답변): 사용자의 모호한 질문을 잘못 해석하여 관련 없는 답변을 제공함.
   • F9 (프롬프트 변경 무시): 사용자가 수정을 요청해도 이전 답변을 반복함.

B. 실패의 원인 (RQ2)

실패는 사용자 요인 (User-contributed) 과 LLM 의 기술적 한계 (ChatGPT-contributed) 가 복합적으로 작용하여 발생합니다.

• 사용자 요인: 모호한 프롬프트, 복잡한 작업의 한 번에 위임, 응답 스킴핑 (중요 부분 누락), 기술 용어 부족 등.
• LLM 요인: 사용자의 전문성 무시, 파일 상호작용 지원 부족, 코드 위치 특정 실패, 검증 메커니즘 부재, 명시적 지시 무시 등.

C. 완화 전략 (RQ3)

사용자는 실패를 극복하기 위해 다음과 같은 전략을 사용했으나, 26 명 중 17 명이 결국 LLM 사용을 포기했습니다.

• 전략: 작업 세분화 (Scaffolding), 프롬프트 명확화, 외부 자료 (Google, StackOverflow) 참조, 수동 디버깅 등.
• 한계: 프롬프트 수정만으로는 시스템적 한계를 극복하기 어렵고, 반복된 실패는 사용자의 인내심을 고갈시킴.

D. 포기 (Abandonment) 의 통계적 요인 (RQ5)

로지스틱 회귀 분석을 통해 다음과 같은 통계적 유의성을 확인했습니다.

• 유용하지 않은 응답 (Unhelpful Responses): LLM 응답이 도움이 되지 않을 경우, 사용자가 도구를 포기할 확률이 11 배 (Odds Ratio = 11) 증가했습니다.
• 프롬프트 횟수: 추가적인 프롬프트를 보낼수록 포기 확률은 17% 감소했습니다 (지속적인 상호작용이 포기 지연에 기여함).
• 코딩 경험: 코딩 경험이 풍부한 개발자 (SDE) 일수록 포기 확률이 낮았으나, 학생들보다 실패 시 더 빠르게 대안 (수동 코딩 등) 으로 전환하는 경향이 있었습니다.
• 작업 완성도: 작업의 객관적 완성도 점수와 포기 확률 사이에는 유의미한 상관관계가 없었습니다.

4. 의의 및 시사점 (Significance & Implications)

1. 모델 성능 향상만으로는 해결되지 않는 상호작용의 함정: GPT-5.1 과 같은 최신 모델은 초기 응답 품질이 향상되었으나, 다단계 작업 중 발생하는 맥락 상실, 편집 국소화 실패, 반복적 오류 등 상호작용적 실패 패턴은 여전히 지속되었습니다. 이는 모델의 정확도 향상만으로는 개발 워크플로우 통합이 해결되지 않음을 시사합니다.
2. 포기는 점진적인 과정 (Process): LLM 포기는 단일 오류에 대한 반응이 아니라, 반복된 실패와 인지 과부하가 누적되어 발생하는 노력 - 이익 트레이드오프 (Effort-Benefit Tradeoff) 의 결과입니다.
3. 디자인 및 연구 방향 제안:
   • 적응형 응답: 사용자의 전문성 수준에 맞춰 답변의 난이도와 상세도를 조절해야 함.
   • 맥락 유지 및 검증: 대화 흐름을 유지하고, 생성된 코드의 정확성을 스스로 검증하거나 사용자에게 명확한 변경 사항을 표시하는 기능 필요.
   • 교육적 가치: LLM 이 단순히 코드를 생성하는 것을 넘어, 개발자가 코드를 이해하고 학습할 수 있도록 구조화된 가이드를 제공해야 함.
   • 비효율적 루프 감지: 사용자가 비생산적인 프롬프트 루프에 빠졌을 때 AI 가 이를 감지하고 대안을 제시하는 시스템 필요.

결론

이 연구는 LLM 이 소프트웨어 공학에 통합될 때 발생할 수 있는 구체적인 함정을 실증적으로 규명했습니다. 개발자들은 LLM 의 불완전한 응답과 상호작용의 복잡성 앞에서 쉽게 좌절하며 도구를 포기합니다. 따라서 미래의 LLM 도구는 단순한 코드 생성 능력을 넘어, 개발자의 인지 부하를 줄이고, 맥락을 유지하며, 신뢰할 수 있는 협업 파트너로 진화해야 합니다.