일반적인 AI 는 코드를 볼 때 "이 코드가 뭐 하는 거지?"라고 추측만 합니다. 하지만 **코드 월드 모델 (CWM)**은 다릅니다. 이 로봇은 코드를 실행할 때 매 순간마다 "지금 변수 a 는 5 다, b 는 10 다"라고 소리쳐서 모든 상태를 말해줍니다.
마치 수학 문제를 풀 때, 답만 쓰는 게 아니라 "1+1=2, 2+2=4..."라고 모든 계산 과정을 소리 내어 말하면서 문제를 푸는 학생과 같습니다. 이렇게 하면 실수를 바로잡기 쉽죠.
하지만 이 연구는 **"이렇게 모든 걸 말해도 왜 여전히 실수가 생길까?"**를 파헤쳤습니다.
🔍 발견한 두 가지 큰 문제 (실패 원인)
연구진은 이 로봇이 실수하는 두 가지 주요 패턴을 발견했습니다.
1. "입이 너무 빨라져서 지쳐버린 경우" (토큰 예산 초과)
상황: 로봇이 코드를 실행할 때, 매 단계마다 현재 상태를 모두 말해야 합니다.
비유: 만약 친구가 "오늘 점심 뭐 먹었어?"라고 물었을 때, 당신이 "아침에 밥 먹었어, 점심에 국수 먹었어, 저녁에..."라고 매일 아침부터 저녁까지의 모든 식사 기록을 한 번에 다 말해야 한다면?
문제: 프로그램이 길어지거나 반복문 (Loop) 이 많으면, 로봇이 상태를 설명하는 말 (토큰) 이 너무 길어져서 입구 (메모리) 가 꽉 차버립니다.
결과: 로봇이 말을 다 끝내기도 전에 "죄송합니다, 더 이상 말할 수 없습니다"라고 중도 포기해버립니다. (이를 Truncation이라고 합니다.)
2. "문자열 (String) 을 다룰 때의 혼란" (토큰화의 함정)
상황: 숫자나 리스트는 잘 처리하지만, **문자 (String)**를 다룰 때 자꾸 실수합니다.
비유: 로봇은 문자를 볼 때 "문자 그대로" 보는 게 아니라, **레고 블록처럼 잘게 쪼개진 조각 (Subword Token)**으로 봅니다.
예: "apple"이라는 단어가 있을 때, 로봇은 "a", "pp", "le"로 나눕니다.
그런데 "apple"이 문장 속에 들어오면, "ap", "ple"로 나뉠 수도 있습니다.
문제: 로봇은 "이 조각이 원래 단어의 일부였나?"를 매번 헷갈려 합니다. 특히 "문자 뒤집기"나 "문자 자르기" 같은 작업을 할 때, 조각이 섞여버려서 실제 의미와 다른 답을 내놓습니다.
결론: 로봇의 눈 (토큰화 방식) 이 문자를 제대로 보지 못해서 생기는 문제입니다.
🧪 실험: "원인을 정확히 찾아내기"
연구진은 이 문제를 해결하기 위해 두 가지 실험을 했습니다.
1. "문자 vs 숫자" 대결
실험: 복잡한 프로그램 구조 없이, 단순히 함수를 여러 번 겹쳐서 (Composition) 결과를 내게 했습니다.
결과: 숫자, 리스트, 불린 (True/False) 은 100% 정확했습니다. 하지만 **문자 (String)**만 깊어지면 정확도가 뚝 떨어졌습니다.
의미: 프로그램 구조가 복잡해서가 아니라, 문자라는 데이터 타입 자체를 다루는 방식에 문제가 있다는 것을 증명했습니다.
2. "장기 기억력" 테스트 (Code S5 벤치마크)
실험: 128 단계나 되는 긴 명령어 순서를 따라가게 했습니다. (예: "A 와 B 를 바꾸고, 그다음 C 와 D 를 바꾸고...")
발견: 로봇이 실수하는 이유는 상태를 기억하지 못해서가 아니라, "다음에 뭘 할지"를 잘못 예측해서였습니다.
비유: 로봇이 "다음에 A 와 B 를 바꾸세요"라고 잘못 말하면, 그 이후의 모든 계산이 엉망이 됩니다.
해결: 연구진이 "다음 명령어는 내가 정해줄게, 너는 상태만 기억해"라고 도와주자 (Teacher Forcing), 로봇은 128 단계까지도 90% 이상 정확하게 상태를 추적했습니다.
의미: 로봇의 기억력 (Transformer 구조) 자체는 나쁘지 않습니다. 다만, 스스로 다음 명령어를 예측하는 과정에서 실수가 쌓이면 전체가 망가진다는 뜻입니다.
💡 결론 및 시사점
이 연구는 우리에게 다음과 같은 교훈을 줍니다:
문자 처리가 약점이다: AI 가 코드를 잘 이해하려면, 문자를 다룰 때 더 정교한 눈 (토큰화 방식 개선) 이 필요합니다.
완벽한 감독은 비효율적이다: 매 순간 상태를 다 말하게 하는 방식은 정확도는 높이지만, 너무 많은 자원을 잡아먹습니다. (입이 너무 빨라져서 지치는 문제)
미래의 방향: 앞으로는 "모든 상태를 다 말하게" 하는 대신, 중요한 순간만 골라서 말하게 하거나, 더 효율적인 기억 구조 (선형 순환 신경망 등) 를 도입해야 코드를 더 길고 정확하게 실행할 수 있을 것입니다.
한 줄 요약:
"AI 가 코드를 실행할 때 모든 과정을 소리 내어 말하게 하면 정확해지지만, 문자 처리에는 약점이 있고, 말이 너무 길어지면 지쳐서 포기하며, 다음 단계 예측을 잘못하면 전체가 망가진다는 것을 발견했다."
논문 개요
이 논문은 **코드 월드 모델 (Code World Models, CWMs)**의 성능 한계와 오류 원인을 심층적으로 분석합니다. CWM 은 프로그램 실행 시 매 명령어마다 명시적인 런타임 상태 (변수 값, 제어 흐름 등) 를 예측하도록 훈련된 언어 모델로, 자연어 추론 대신 실행 기반의 내부 검증을 가능하게 합니다. 저자들은 실제 코드 벤치마크와 통제된 실험을 통해 CWM 이 직면한 두 가지 주요 실패 모드 (토큰 예산 소모 및 문자열 상태 표현의 취약성) 와 장기적 상태 추적의 한계를 규명했습니다.
1. 문제 정의 (Problem)
CWM 은 코드 실행을 "상태 - 행동" 시퀀스로 모델링하여 소프트웨어 공학 벤치마크에서 뛰어난 성과를 보였습니다. 그러나 다음과 같은 근본적인 의문점이 남아 있었습니다:
왜 CWM 은 실패하는가? 밀집된 상태 공개 (dense state reveals) 가 장기적 추적 문제를 완전히 해결했는지, 아니면 여전히 국소적 의미 실행 (local semantic execution) 에서 오류가 발생하는지.
오류의 본질: 실패가 프로그램 구조의 복잡성 때문인지, 아니면 데이터 타입 (특히 문자열) 의 표현 방식이나 토큰화 (tokenization) 의 한계 때문인지.
장기적 추적: Transformer 아키텍처가 긴 시퀀스 동안 상태를 정확하게 유지할 수 있는지, 아니면 행동 생성 (action generation) 단계에서 오류가 발생하여 후속 상태를 망가뜨리는지.
2. 방법론 (Methodology)
저자들은 CWM 의 성능을 두 가지 관점에서 분석하기 위해 다음과 같은 실험을 설계했습니다.
가. 실제 코드 벤치마크 분석 (Real-Code Benchmarks)
데이터셋: CruxEval-O 와 HumanEval 을 사용하여 CWM 의 실행 정확도를 평가했습니다.
오류 분류: 실패 사례를 '토큰 예산 소모 (Truncation)'와 '의미론적 실행 오류 (Semantic Errors)'로 분류하고, 데이터 타입별 오류 분포를 분석했습니다.
나. 통제된 기능적 조합 실험 (Controlled Functional Composition)
목적: 프로그램 구조를 고정하고 데이터 타입만 변경하여 특정 데이터 타입의 취약성을 격리했습니다.
실험: 부울, 비트연산, 수학, 리스트, 딕셔너리 등 7 가지 비문자열 타입과 문자열 타입에 대해 깊이가 5 인 함수 조합 (Composition) 을 수행했습니다.
개입 (Intervention): 실패한 샘플에 대해 중간 변수를 명시적으로 추출하거나 문자열 연산을 문자 단위 루프로 분해하는 코드 분해 (Code Decomposition) 를 적용하여 오류 원인을 진단했습니다.
다. 장기적 상태 추적 벤치마크 (Long-Horizon State Tracking)
벤치마크: Code S5 (Symmetric group on 5 elements) 퍼뮤테이션 (순열) 추적 태스크를 사용했습니다. 이는 N개의 스왑 (swap) 연산을 수행한 후 최종 변수 상태를 예측하는 작업입니다.
교차 검증:
Baseline: 모델이 다음 명령어와 상태를 모두 예측하도록 함.
Teacher Forcing: 정답인 명령어 (Ground-truth action) 를 주입하고 상태 예측만 평가하여, '행동 생성 오류'와 '상태 전파 오류'를 분리했습니다.
3. 주요 결과 (Key Results)
가. 두 가지 지배적인 실패 모드 (Two Dominant Failure Regimes)
토큰 예산 소모 (Token-Budget Exhaustion):
밀집된 상태 공개는 짧은 프로그램에서는 효과적이지만, 깊은 중첩 루프나 무한 루프 패턴, 긴 문자열 처리 시 실행 트레이스가 토큰 제한 (예: 8K) 을 초과하여 잘립니다.
이는 모델의 실행 능력 부족이 아니라, 상태 공개 방식의 비효율성에서 기인합니다.
문자열 상태의 취약성 (Brittleness in String-Valued State):
CruxEval-O 와 HumanEval 에서 실패의 상당 부분 (각각 73%, 44%) 이 문자열 관련 오류였습니다.
통제 실험 결과: 비문자열 데이터 (리스트, 딕셔너리 등) 에서는 깊이가 5 인 조합에서도 100% 정확도를 보였으나, 문자열 데이터에서는 깊이가 증가함에 따라 정확도가 급격히 하락했습니다 (깊이 5 에서 25% 까지).
원인:서브워드 토큰화 (Subword Tokenization) 의 불연속성입니다. 예를 들어, 분리자 "-."가 단독으로는 하나의 토큰이지만, 문자열 "a-.-.b" 내에서는 다른 토큰 시퀀스로 분해되어 모델이 패턴 매칭을 실패하게 만듭니다.
나. 장기적 상태 추적의 원인 규명
행동 할루시네이션 (Action Hallucination): 긴 시퀀스 (128 단계) 에서 정확도가 떨어지는 주된 원인은 상태 업데이트 오류가 아니라, 다음 명령어 (Action) 를 잘못 생성하는 것이었습니다.
Teacher Forcing 효과: 정답인 명령어를 주입하면 (상태 전파만 평가), Transformer 기반 CWM 은 128 단계 이상에서도 90% 이상의 정확도를 유지했습니다.
결론: CWM 의 장기적 추적 실패는 아키텍처의 상태 추적 능력 부족이 아니라, 행동 생성의 불확실성이 누적되어 발생하며, 밀집된 상태 공개는 상태 전파 자체는 잘 수행하게 합니다.
4. 주요 기여 (Key Contributions)
CWM 오류의 체계적 분류: 실제 코드 벤치마크에서 토큰 예산 소모와 문자열 표현의 취약성이 주요 실패 원인임을 규명했습니다.
문자열 표현의 한계 증명: 프로그램 구조가 단순하더라도 서브워드 토큰화의 불연속성으로 인해 문자열 상태 추적이 불안정함을 통제 실험을 통해 입증했습니다.
장기적 추적 메커니즘 해부: Transformer 기반 CWM 이 밀집된 상태 공개 하에서는 장기적 상태 전파가 가능하지만, 행동 생성 (Action Generation) 오류가 전체 실패를 주도함을 보였습니다.
향후 연구 방향 제시:
효율성: 밀집된 상태 공개의 토큰 비용 문제를 해결하기 위해 희소 관측 (sparse observation) 하에서 상태 전파가 가능한 아키텍처 (선형 재귀 RNN, 상태 공간 모델 등) 의 필요성 강조.
표현 방식: 토큰화 불연속성을 해결하기 위해 바이트 레벨 (Byte-level) 이나 토큰 없는 (Tokenizer-free) 접근법의 필요성 제기.
5. 의의 및 시사점 (Significance)
이 논문은 코드 월드 모델이 단순히 "코드를 실행하는 것"을 넘어, 어떻게 상태를 표현하고 추적하는지에 대한 깊은 통찰을 제공합니다.
아키텍처적 시사점: Transformer 가 긴 시퀀스 상태 추적을 위해 밀집된 상태 공개 (Dense Supervision) 에 의존하고 있음을 보여줍니다. 이는 효율성을 위해 상태 공개를 줄이려면 Transformer 대신 순환 신경망 (RNN) 이나 상태 공간 모델 (Mamba 등) 과 같은 아키텍처가 필요함을 시사합니다.
데이터 표현의 중요성: LLM 의 코드 실행 능력 향상을 위해서는 토큰화 전략을 재고하거나, 문자열과 같은 데이터 타입에 더 안정적인 표현 방식을 도입해야 함을 강조합니다.
실용적 적용: CWM 을 활용한 코드 생성 및 검증 시스템의 신뢰성을 높이기 위해서는 긴 실행 트레이스에서의 토큰 효율성 개선과 문자열 처리의 정확도 향상이 필수적입니다.
결론적으로, 이 연구는 CWM 의 현재 한계를 진단하고, 더 효율적이고 견고한 코드 실행 에이전트를 구축하기 위한 방향성 (아키텍처 변경 및 표현 방식 개선) 을 제시합니다.