LLM 추론 실패 케이스 모음 왜 자꾸 삐끗할까

LLM 추론 실패 케이스 모음 왜 자꾸 삐끗할까

 

LLM 추론 실패 연구는 많지만, 서로 다른 커뮤니티의 결과가 파편처럼 흩어져 있어 “지금 무엇이 어디까지 밝혀졌는지”가 잘 보이지 않는 경우가 많습니다. 2602.06176v1은 이 혼란을 2축 택소노미로 정리해 연구 지도를 만든다는 점에서, 그 자체가 중요한 기여로 읽힙니다.

택소노미가 주는 연구 지도, 그러나 ‘분류’에서 ‘설명’으로 더 가야 합니다

이 논문의 가장 큰 장점은 2축 택소노미가 “정리용 그림”에 그치지 않고, 실제로 논문 전체의 구조를 끌고 간다는 점입니다. 저자들은 추론 유형을 비체화(non-embodied)와 체화(embodied)로 나누고, 비체화는 다시 비형식(informal, 직관/편향/휴리스틱)과 형식(formal, 논리/수학/코드)으로 쪼갭니다. 동시에 실패의 성격을 근본적(fundamental), 응용특이(application-specific limitations), 강건성(robustness issues)으로 구분해 “추론 유형 × 실패 유형”의 격자를 만듭니다. Figure 1에서 이 격자 구조를 한 장에 요약하고, 이후 각 장(비형식/형식/체화)을 그 구조에 맞춰 전개합니다.

이 접근은 논문이 말하는 목표, 즉 파편화된 문헌을 “한 장의 지도”로 얹는 데 확실히 효과적입니다. 예컨대 근본 실패에는 reversal curse, working memory 한계(특히 proactive interference), 인지 편향 등이 들어가고, 응용특이는 ToM(Theory of Mind) 불안정이나 MWP 일반화 실패, 3D 체화에서의 affordance/planning 오류 같은 도메인 묶음이 들어갑니다. 강건성 이슈는 의미 보존 변형(옵션 순서 바꾸기, 변수명 바꾸기, 도덕 딜레마 패러프레이즈 등)에도 출력이 크게 흔들리는 현상들을 한데 묶어 설명합니다.

다만 사용자의 비평(A)처럼, 이 2축이 “원인 설명”이라기보다 “분류 도구”에 머무르는 순간이 있습니다. 논문도 각 실패에 대해 원인과 완화를 언급하지만, 축 자체는 인과를 말하지 않습니다. 그래서 경계 케이스에서 교차 분류가 애매해집니다. 예를 들어 “수학 word problem의 강건성 붕괴”는 형식 추론이면서 동시에 강건성 이슈(변형에 취약)이고, 또 working memory/주의 분산 같은 근본 요소와도 엮입니다. 이런 경우 독자는 “그래서 이 격자에서 어디에 ‘속하는지’가 핵심인가, 아니면 라벨을 여러 개 붙이는 게 핵심인가”를 묻게 됩니다.

저는 이 논문이 한 단계 더 강해지려면, “멀티라벨(교차 분류)을 기본 원칙으로 인정하는 선언”이 필요하다고 봅니다. 즉 ‘깔끔한 칸’에 넣는 것이 아니라, (주 라벨, 부 라벨)을 명시하는 규칙을 두는 방식입니다. 예를 들어 (추론유형=Formal, 실패유형=Robustness)을 주 라벨로, (실패유형=Fundamental, 원인 후보=working memory/주의 분산)을 부 라벨로 붙이는 식입니다. 이렇게 하면 분류가 ‘태그 나열’처럼 느껴지는 위험을 줄이면서도, 서베이가 가진 정리의 장점은 유지할 수 있습니다.

또 하나의 개선 포인트는 “지도 사용법”을 독자 행동으로 변환하는 것입니다. 서베이는 결국 독자가 자신의 문제를 진단하고, 어떤 문헌을 먼저 읽어야 할지 안내해 줄 때 실용성이 커집니다. 따라서 논문이 제공하는 큰 분류를 그대로 가져와, 독자가 자기 프로젝트(예: 고객상담 에이전트, 코드 생성, 로봇 플래너)를 어디에 얹을지 빠르게 판단할 수 있는 체크리스트가 있으면 좋습니다. 아래 표는 그 취지로, 논문의 축을 “현장 진단 질문”으로 바꿔 정리한 것입니다.

현장 진단 질문	의심해야 할 축(우선순위)
동일 의미의 프롬프트/옵션 순서/변수명 변경에 성능이 크게 흔들리나요	강건성(perturbation 기반 스트레스 테스트)
특정 도메인(의료/윤리/로봇)에서만 유독 실패가 집중되나요	응용특이(도메인 지식·규범·환경 제약)
도메인 불문하고 ‘업데이트를 놓침/이전 정보에 끌림/단계 수행이 붕괴’가 반복되나요	근본(working memory, next-token objective 등)

요약하면, 이 논문은 “정리”라는 서베이의 본령을 잘 수행했고, 특히 서로 다른 연구 흐름을 같은 좌표계에 올려놓는 데 성공했습니다. 다만 다음 단계는, 그 좌표계가 교차 사례를 자연스럽게 담을 수 있도록 멀티라벨 원칙을 더 분명히 하고, 분류를 독자의 진단 행동으로 연결하는 쪽으로 확장하는 일이라고 봅니다.

강건성 스트레스 테스트는 강점, 그러나 ‘왜 흔들리는가’는 등급화가 필요합니다

이 논문에서 실용성이 가장 높은 부분 중 하나는 “강건성 실패”를 공통 방법론으로 끌어올린 점입니다. 저자들은 의미가 보존되는 작은 변형에도 출력이 크게 흔들리는 사례들을 폭넓게 묶습니다. 예컨대 MCQ 보기 순서 재배열, 코드에서 함수/변수 이름 변경, 도덕 딜레마의 패러프레이즈 같은 변형은 문제의 의미를 바꾸지 않는데도 성능이 떨어질 수 있습니다. 그리고 이런 변형을 자동화해 대규모 스트레스 테스트로 확장하는 것이 강건성 이슈 탐지의 핵심 패러다임이라고 정리합니다.

여기까지는 매우 설득력 있습니다. 실제 서비스에서도 ‘사용자 말투/서술 순서’는 수시로 바뀌고, 그 변형에 취약한 시스템은 배치 환경에서 신뢰를 잃기 쉽기 때문입니다. 문제는 사용자의 비평(B)처럼, “원인→완화”가 종종 ‘가능한 가설’의 수준에서 멈춘다는 점입니다. 논문은 예를 들어 working memory 한계, 자기회귀(next-token prediction) 목표의 구조, self-attention의 집중 분산 같은 근본 원인을 언급하고, 완화로 CoT, retrieval augmentation, fine-tuning, multimodality, 아키텍처 혁신 등을 제안합니다. 하지만 많은 경우 “왜 이 완화가 이 실패를 줄이는가”가 동일한 강도로 연결되기 어렵고, 결과적으로 ‘현상 요약 + 원인 후보 + 처방 후보’의 병렬 나열처럼 읽히는 구간이 생깁니다.

저는 이 문제를 “서베이의 한계”로만 넘기기보다, 서베이의 신뢰도를 높이는 방식으로 정리할 수 있다고 봅니다. 핵심은 ‘원인-완화 연결의 증거 수준’을 등급화하는 것입니다. 예를 들어 다음과 같은 3단계만 도입해도 독자는 훨씬 안전하게 읽을 수 있습니다.

가설 수준입니다: 메커니즘이 그럴듯하나, 개입 실험이 부족한 경우입니다.

상관 수준입니다: 특정 완화(예: CoT) 적용 시 성능이 오르지만, 무엇이 원인인지 분해가 부족한 경우입니다.

개입-검증 수준입니다: 특정 내부 메커니즘을 겨냥한 조작(예: 특정 attention head 수정, 데이터 증강의 특정 변형만 추가)이 실패 감소를 재현적으로 보여준 경우입니다.

논문은 이미 일부 사례에서 ‘근본 원인’의 가능성을 구체적으로 언급합니다. 예컨대 working memory/억제 통제/인지 유연성 같은 인간 실행기능 개념을 통해 LLM의 오류를 설명하고, proactive interference가 인간보다 더 크다고 지적합니다. 또 self-attention이 복잡한 과제에서 집중이 분산될 수 있고, next-token objective가 “숙고”보다 “통계적 완성”을 선호할 수 있다는 원인 후보를 제시합니다. 이런 지점들은 등급화가 붙을 때 더 빛납니다. 독자는 “이 설명이 어느 정도 검증된 연결인가”를 즉시 파악하고, 연구/개발 우선순위를 정할 수 있기 때문입니다.

현장 관점에서 강건성 축을 더 잘 쓰는 방법도 제안할 수 있습니다. 논문이 말하는 perturbation 패러다임을 서비스 운영으로 옮기면, 다음과 같은 ‘실천 팁’이 됩니다.

의미 보존 변형 세트를 사전에 정의해야 합니다: 옵션 순서, 표기 단위(%, 분수), 변수명, 인물/지명 치환, 문장 길이, 문체 등입니다.

변형을 “테스트”에서 끝내지 말고 “학습/튜닝 데이터”에도 주입해야 합니다: 논문도 데이터 다양화가 강건성에 도움을 주지만 비용이 크고 일반화가 어렵다고 언급합니다. 따라서 최소 범위라도 핵심 변형만 주입하는 것이 현실적입니다.

실패 로그를 축 기준으로 라벨링해야 합니다: (추론유형/실패유형) 라벨을 붙여야, 같은 완화(예: RAG)가 어떤 실패에는 도움이 되지만 어떤 실패에는 도움이 안 되는지 분해가 가능합니다.

결국 이 논문이 만든 지도에서 “강건성”은 가장 바로 적용 가능한 축입니다. 다만 그 다음은, 흔들림의 원인을 설명하는 문장들을 ‘증거 수준’으로 정리해 독자가 과장 없이 받아들이게 만드는 작업이라고 봅니다.

에이전트 시대의 빈칸, 멀티턴 실패를 ‘별도 장’으로 올려야 실용성이 커집니다

사용자 비평(C)은 지금 시점에서 특히 중요합니다. 논문도 스스로 인정하듯, 멀티턴 및 인터랙티브 컨텍스트는 실제 배치 환경에 더 가깝지만 문헌에서 과소대표되어 있고, 서베이도 그 영향을 받습니다. 즉, ‘현장’에서 가장 자주 터지는 종류의 실패(도구 사용, 장기 계획, 환경 피드백, 종료 조건, 안전한 복구)가 지도에서는 상대적으로 얇게 다뤄질 수 있습니다.

논문은 그나마 Explicit Social Reasoning에서 Multi-Agent System(MAS) 문헌을 다루며, 핵심 난제를 (1) long-horizon planning, (2) communication/ToM, (3) robustness/adaptability로 정리합니다. 또한 표준 LLM이 next-token objective로 최적화되어 있어 “다단계·공동조건 목적”에서 깊은 추론이 부족할 수 있고, ToM 취약이 조정 실패로 이어질 수 있으며, 시스템 레벨에서 역할 명세/교차검증/종료 체크가 없으면 오류가 연쇄될 수 있다고 서술합니다. 완화로는 belief tracking, 구조화된 커뮤니케이션, inspector/challenger 에이전트 같은 레이어를 제안합니다.

하지만 여기서도 ‘분류 vs 설명’ 문제가 반복됩니다. 에이전트 실패는 단순히 “추론 유형(비체화/체화)”과 “실패 유형(근본/응용특이/강건성)”만으로는 충분히 포착되지 않는 경우가 많습니다. 에이전트는 (입력→출력) 단발이 아니라, (행동→환경변화→새 관측→다음 행동)의 루프이며, 실패는 루프의 어디에서든 발생합니다. 예를 들어 같은 논리 오류라도, 단발 QA에서는 ‘오답’으로 끝나지만, 에이전트에서는 (도구 오사용→잘못된 상태 업데이트→오류 누적→종료 실패)로 번질 수 있습니다. 이때 “원인이 무엇이고 완화가 무엇인지”를 말하려면, 실패를 시간축(턴/스텝)과 시스템축(모델/툴/메모리/검증기)에서 함께 봐야 합니다.

그래서 저는 이 서베이가 에이전트 시대의 실용성을 더 얻으려면, 최소한 다음 중 하나가 필요하다고 봅니다.

에이전트/인터랙티브 실패를 별도 장으로 격상해야 합니다: 논문이 인정한 공백을 ‘부록’이 아니라 ‘중심’으로 끌어올리는 방식입니다.

또는 제3의 보조 축을 도입해야 합니다: 예컨대 “단발(single-shot) vs 멀티턴(multi-turn) vs 환경루프(agentic)” 같은 상호작용 수준 축입니다.

그리고 완화는 ‘스택’으로 제시해야 합니다: 프롬프트/CoT 같은 모델 내부 기법만이 아니라, 종료 체크, 도구 호출 검증, 되돌리기(rollback), 상호검증, 실패 감지 후 안전한 축소 모드 같은 운영 메커니즘을 표준 레시피로 정리하는 것입니다.

논문이 제안하는 “평가 인프라” 방향은 이 문제를 해결할 단초가 됩니다. 저자들은 지속적으로 업데이트되는 실패 벤치마크, 일반 벤치마크에 failure injection 원칙 적용, 동적/이벤트 기반 벤치마크, 부분 비공개/동적 진화형 스위트 등을 제안합니다. 이것을 에이전트에 연결하면, ‘한 번의 문제’가 아니라 ‘연속된 에피소드’에 failure injection을 넣는 형태로 자연스럽게 확장할 수 있습니다. 예컨대 (도구 응답 지연, 부분 실패, 모호한 관측, 이벤트 규칙 변경)을 에피소드 중간에 주입하고, 에이전트가 복구하는지 보는 평가가 가능합니다.

정리하면, 이 논문은 연구 지도를 잘 그렸고 그 지도는 “지금까지의 파편”을 통합하는 데 큰 역할을 합니다. 다만 앞으로의 현장은 에이전트 중심으로 더 빠르게 이동하고 있으므로, 멀티턴/인터랙티브 실패를 지도 한복판으로 옮기는 순간 이 서베이의 실용성은 훨씬 커질 것이라고 봅니다.

(결론: 이 논문은 2축 택소노미로 파편화된 ‘추론 실패’ 문헌을 한 장의 연구 지도로 정리한 점이 핵심 성과입니다. 다만 경계 사례 교차 분류 원칙, 원인-완화 연결의 증거 등급화, 멀티턴/에이전트 실패의 별도 강화가 필요하다는 비평이 핵심입니다.)

자주 묻는 질문 (FAQ)

Q. 이 논문이 말하는 2축 택소노미는 무엇을 의미하나요 A. 추론 유형 축은 비체화와 체화로 나누고, 비체화는 비형식(직관)과 형식(논리/수학/코드)으로 다시 나눕니다. 실패 유형 축은 근본적 실패, 응용특이 한계, 강건성 이슈로 나누어 “추론 유형 × 실패 유형” 격자를 만듭니다.

Q. 강건성 실패는 왜 ‘의미 보존 변형’으로 평가하나요
A. 보기 순서 변경, 변수명 변경, 패러프레이즈처럼 의미가 동일한 변형에서도 출력이 크게 흔들리면, 정답률이 높아도 신뢰성이 낮을 수 있습니다. 논문은 이런 변형을 자동화해 대규모 스트레스 테스트로 적용하는 것을 공통 탐지 패러다임으로 정리합니다.

Q. 에이전트(멀티턴) 실패가 과소대표되면 무엇이 문제인가요
A. 실제 배치 환경은 대화가 길고 도구·피드백 루프가 존재해, 단발 QA에서 보이지 않던 오류 누적·종료 실패·복구 실패가 자주 발생합니다. 논문도 멀티턴/인터랙티브 컨텍스트가 문헌에서 과소대표되어 있고 향후 벤치마크 다양화가 필요하다고 인정합니다.

[출처]
https://arxiv.org/html/2602.06176v1