EsoLang-Bench: Evaluating Genuine Reasoning in Large Language Models via Esoteric Programming Languages

이 논문은 대규모 언어 모델이 기존 코드 생성 벤치마크에서 높은 점수를 얻는 것이 단순 암기에 불과할 수 있음을 지적하며, 데이터 오염 가능성이 낮은 에소테릭 프로그래밍 언어를 활용한 'EsoLang-Bench'를 통해 모델들의 진정한 추론 능력을 평가했을 때 기존 벤치마크 점수와 극명하게 대비되는 낮은 성능을 확인했다고 요약할 수 있습니다.

핵심

🎭 비유: "유명 배우 vs. 즉흥극 배우"

지금까지 AI(대형 언어 모델) 들의 실력을 평가할 때는 유명 배우에게 익숙한 대본을 주고 연기를 시켰습니다.

• 기존 방식 (HumanEval 등): "이 대본 (파이썬 코드) 을 보고 다음 장면을 연기해 봐."
• 결과: AI 는 대본을 이미 다 외우고 있었거나, 비슷한 대본을 수백 번 본 적이 있어서 90~95% 만점을 받았습니다.
• 문제점: AI 가 진짜로 상황을 이해해서 연기한 걸까, 아니면 그냥 암기해서 대본을 읊은 걸까? 우리는 알 수 없었습니다.

이 논문은 **"유명 배우에게 완전히 낯선, 즉흥극 (에소테릭 언어) 을 시켜보자"**고 제안합니다.

🌟 새로운 실험: "에소테릭 언어 (Esolang) 벤치마크"

연구진은 AI 에게 완전히 낯선 5 가지의 이상한 언어로 코드를 짜게 했습니다. 이를 EsoLang-Bench라고 부릅니다.

1. 왜 이런 이상한 언어를 썼을까요?

이 언어들은 현실에서 쓸모가 전혀 없습니다.

• 브레인퍽 (Brainfuck): 8 개의 기호만 쓰는 언어.
• 위트스페이스 (Whitespace): 공백, 탭, 줄바꿈만 의미 있는 언어.
• 셰익스피어 (Shakespeare): 연극 대본처럼 코드를 쓰는 언어.

핵심 이유: AI 를 훈련시킬 때, 이런 쓸모없는 언어 데이터를 넣을 이유가 전혀 없습니다. (경제적으로 비합리적이기 때문). 그래서 AI 가 이 언어를 **암기했을 가능성은 0%**에 가깝습니다. 만약 AI 가 이걸 잘 푼다면, 그것은 진짜 추론 능력이 있는 것입니다.

2. 실험 결과: "실망스러운 진실"

최고급 AI 모델 5 개를 이 언어로 테스트해 봤습니다. 결과는 충격적이었습니다.

• 기존 테스트 (파이썬): 90% 이상 정답 (유명 배우가 익숙한 대본을 잘 연기).
• 새로운 테스트 (에소테릭 언어): 0~11% (완전 엉망진창).

비유하자면:

"유명 배우가 익숙한 셰익스피어 연극은 완벽하게 했지만, 갑자기 '고양이 발소리만 내며 춤추는' 즉흥극을 시키자마자 완전 멍해져서 아무것도 못 했다는 뜻입니다."

특히, 중간 이상 난이도의 문제는 모든 AI 가 **0%**를 기록했습니다. AI 는 아주 간단한 문제 (Easy) 는 겨우 1~2 개 풀었지만, 조금만 복잡해지면 완전히 멈춰 섰습니다.

🔍 왜 이런 일이 일어났을까? (원인 분석)

연구진은 몇 가지 흥미로운 원인을 발견했습니다.

1. 암기 vs. 이해: AI 는 익숙한 언어의 '패턴'을 외워서 푼 것이지, 논리적으로 '이해'해서 푼 것이 아니었습니다.
2. 힌트도 소용없음: "이전 예시를 보여줄게 (Few-shot)"라고 해줘도 소용없었습니다. AI 는 새로운 언어의 기본 원리를 모르면, 예시를 보여줘도 연결할 수 없었습니다.
3. 실수 유형:
   • 브레인퍽 같은 언어: 문법 (기호) 은 대충 맞췄는데, 논리가 엉망이었습니다. (문법은 외웠지만 뜻은 몰랐음)
   • 위트스페이스 같은 언어: 아예 문법 (공백) 을 인식조차 못 했습니다. (데이터가 너무 없어서 아예 처음 보는 것)

🚀 그래도 희망은 있다? (에이전트 시스템)

단순히 AI 에게 "코드를 짜라"고만 시키지 않고, AI 가 직접 코드를 실행해보고 오류를 수정하는 '에이전트' 시스템을 만들어 테스트했습니다.

• 방법: AI 가 코드를 짠 뒤, 컴퓨터가 "오류났어!"라고 알려주면, AI 가 그 오류를 보고 다시 고치는 과정을 반복했습니다.
• 결과: 이 방식이 가장 잘 작동했습니다. 하지만 여전히 난이도가 높은 문제는 풀지 못했습니다.
• 교훈: AI 는 **피드백 (오류 메시지)**을 통해 조금 더 잘 배울 수 있지만, 근본적인 '추론 능력'이 부족하면 한계가 명확합니다.

💡 이 연구가 우리에게 주는 메시지

이 논문은 우리에게 진짜 중요한 질문을 던집니다.

"우리가 AI 에게 점수를 매길 때, AI 가 진짜로 똑똑한지, 아니면 그냥 시험지를 미리 보고 암기했는지 구별하고 있나요?"

• 기존 벤치마크: AI 가 시험지를 미리 보고 암기했는지 알 수 없어서, AI 가 너무 똑똑한 것처럼 착각하게 만들었습니다. (Goodhart 의 법칙: 지표가 목표가 되면 그 지표는 무의미해진다)
• 이 연구의 제안: 쓸모없는 이상한 언어로 테스트하면, AI 가 암기할 수 없기 때문에 진짜 추론 능력만 남습니다.

🏁 결론

이 논문은 **"AI 가 진짜로 생각할 수 있는가?"**를 확인하기 위해, 완전히 새로운 언어로 시험을 치르게 했습니다. 결과는 AI 가 아직 진짜 '이해'와 '추론'에는 미치지 못하며, 대부분 '암기'와 '패턴 인식'에 의존하고 있다는 것을 보여줍니다.

앞으로 AI 를 평가할 때는 익숙한 문제가 아니라, AI 가 처음 보는 낯선 문제를 던져주어 진짜 실력을 확인해야 한다는 교훈을 줍니다. 마치 유명 배우에게 낯선 즉흥극을 시켜보아야 그 배우의 진짜 실력을 알 수 있는 것과 같습니다.

기술 요약

EsoLang-Bench: 희소 언어를 통한 대규모 언어 모델의 진정한 추론 능력 평가

이 논문은 현재 대규모 언어 모델 (LLM) 이 코드 생성 벤치마크에서 기록하는 높은 점수가 실제 추론 능력보다는 **암기 (memorization)**에 기반한 것일 수 있다는 문제의식을 제기합니다. 저자들은 이를 해결하기 위해 EsoLang-Bench라는 새로운 벤치마크를 소개하며, 난해한 프로그래밍 언어 (Esoteric Programming Languages) 를 사용하여 모델의 진정한 계산적 추론 능력을 평가합니다.

1. 문제 제기 (Problem)

• 기존 벤치마크의 한계: HumanEval, MBPP 등 기존 코드 생성 벤치마크는 모델이 훈련 데이터에 포함된 문제를 단순히 패턴 매칭하거나 암기하여 높은 점수를 얻는 '벤치마크 게임화 (gaming)' 현상이 심화되었습니다.
• 데이터 오염 (Data Contamination): 훈련 코퍼스에 벤치마크 문제가 포함되어 있어, 모델이 실제 추론 없이도 정답을 유추할 수 있게 되었습니다.
• 진정한 추론의 부재: 모델이 새로운 도메인이나 언어 구조에 적응하여 알고리즘적 문제를 해결하는 '전이 가능한 추론 (transferable reasoning)' 능력을 측정할 수 있는 방법이 부족합니다.

2. 방법론 (Methodology)

2.1. EsoLang-Bench 데이터셋

• 난해한 프로그래밍 언어 (Esolang) 활용: 훈련 데이터에 거의 존재하지 않는 5 가지 난해한 언어를 선정했습니다.
  • Brainfuck: 메모리 테이프 조작, 포인터 산술.
  • Befunge-98: 2 차원 스택 기반, 비선형 제어 흐름.
  • Whitespace: 공백, 탭, 개행 문자만 의미 있는 문법.
  • Unlambda: 변수 없는 순수 함수형 언어 (조합자 논리).
  • Shakespeare: 연극 대본 형태의 문법으로 계산 수행.
• 데이터 희소성: 이 언어들은 GitHub 저장소가 Python 대비 1,000~100,000 배 적어, 사전 훈련 (pre-training) 에 포함될 경제적 동기가 없습니다. 따라서 모델의 성능은 훈련 데이터 암기가 아닌 실시간 학습과 추론에 기반해야 합니다.
• 문제 구성: 총 80 개의 프로그래밍 문제를 4 가지 난이도 (Easy, Medium, Hard, Extra-Hard) 로 구성했습니다. 각 문제는 자연어 설명과 6 개의 입력 - 출력 테스트 케이스를 포함하며, Python 과 동일한 알고리즘적 논리를 요구하지만 난해한 언어로 구현해야 합니다.

2.2. 실험 설정

• 평가 대상 모델: GPT-5.2, O4-mini, Gemini 3 Pro, Qwen3-235B, Kimi K2 등 5 개의 최첨단 LLM.
• 프롬프트 전략:
  • Zero-Shot (지시사항만 제공)
  • Few-Shot (3 개의 예시 코드 제공)
  • Self-Scaffolding (인터프리터 피드백을 통해 모델이 스스로 코드 수정)
  • Textual Self-Scaffolding (코더와 비평가 에이전트 분리)
  • ReAct Pipeline (계획 - 실행 - 비평의 3 단계)
• 에이전트 시스템 평가: Codex, Claude Code 등 도구를 직접 사용할 수 있는 에이전트 시스템의 성능도 비교했습니다.

3. 주요 기여 (Key Contributions)

1. EsoLang-Bench 도입: 데이터 오염과 게임화가 불가능한, 진정한 OOD(Out-of-Distribution) 추론 능력을 측정하는 최초의 벤치마크를 제안했습니다.
2. 컨텍스트 학습의 한계 규명: OOD 작업에서 Few-Shot 학습이 성능 향상에 유의미한 기여를 하지 못함을 실험적으로 증명했습니다. 이는 ICL(In-Context Learning) 이 사전 훈련 데이터의 존재 여부에 크게 의존함을 시사합니다.
3. 에이전트 시스템의 중요성: 인터프리터 피드백 루프와 효율적인 컨텍스트 관리를 가진 에이전트 시스템이 정적 프롬프트보다 우월한 성능을 보임을 확인했습니다.
4. 오류 분석: 모델이 문법 (Syntax) 은 어느 정도 학습할 수 있으나, 알고리즘적 논리 (Semantics) 를 적용하는 데 근본적인 한계가 있음을 발견했습니다.

4. 실험 결과 (Results)

4.1. 극심한 성능 격차

• 전체 정확도: 기존 벤치마크에서 8595% 의 정확도를 기록하던 최첨단 모델들도 EsoLang-Bench 에서는 **011%**의 정확도만 달성했습니다.
• 난이도별 성능: 모든 모델이 Easy(쉬움) 등급에서는 일부 문제를 해결했으나, Medium, Hard, Extra-Hard 등급에서는 **0%**의 정확도를 기록했습니다. 이는 모델이 단순한 패턴 매칭은 가능하지만, 복잡한 알고리즘적 추론은 불가능함을 의미합니다.

4.2. 프롬프트 전략별 성과

• Few-Shot의 무력화: Zero-Shot 과 Few-Shot 간의 성능 차이는 통계적으로 유의미하지 않았습니다 (평균 +0.8%p). 이는 사전 훈련 데이터에 해당 도메인이 없을 때 예시가 학습을 돕지 못함을 보여줍니다.
• Self-Scaffolding 의 우위: 인터프리터의 직접적인 실행 피드백 (실제 출력 vs 기대 출력) 을 제공하는 Self-Scaffolding 전략이 텍스트 기반 비평 (Textual Self-Scaffolding) 보다 더 효과적이었습니다. 이는 추상적인 피드백보다 구체적인 실행 오류가 OOD 작업에서 더 강력한 학습 신호가 됨을 시사합니다.
• 에이전트 시스템의 성과: 직접 인터프리터에 접근하고 컨텍스트를 관리하는 에이전트 시스템 (Codex, Claude Code) 은 비에이전트 모델보다 2~3 배 높은 성능 (최대 13.8%) 을 보였으나, 여전히 Easy 등급에 국한되었습니다.

4.3. 언어별 차이

• Befunge-98: 상대적으로 가장 높은 성능 (최대 11.2%) 을 보였으며, 이는 GitHub 에 상대적으로 더 많은 자료가 존재하기 때문으로 추정됩니다.
• Whitespace: 모든 모델이 100% 컴파일 오류를 기록했습니다. 이는 토크나이저가 공백을 처리하는 방식과 훈련 데이터의 절대적 부재가 결합된 결과로 보입니다.

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

• 진정한 추론 능력의 측정: EsoLang-Bench 는 모델이 새로운 언어와 문법을 문서와 피드백을 통해 학습하고 알고리즘을 적용할 수 있는 '인간과 유사한 학습 능력'을 측정합니다.
• 안전한 평가 프레임워크: 데이터 오염과 게임화가 경제적으로 비합리적인 언어를 사용함으로써, 모델의 실제 능력을 왜곡 없이 평가할 수 있는 기준을 마련했습니다.
• 향후 방향: 현재 모델들은 단순한 I/O 작업이나 반복 구조는 처리할 수 있으나, 복잡한 상태 관리나 다단계 알고리즘에는 실패합니다. 이는 LLM 이 여전히 '패턴 검색기'에 가깝고, 진정한 '추론 엔진'이 되기 위해서는 근본적인 아키텍처나 학습 방식의 변화가 필요함을 시사합니다.

이 연구는 AI 벤치마크의 신뢰성을 높이고, 모델의 실제 한계를 파악하여 고위험 분야에서의 배포를 신중하게 결정하는 데 기여할 것으로 기대됩니다.