Enabling Global, Human-Centered Explanations for LLMs: From Tokens to Interpretable Code and Test Generation 논문 정리

한 줄 요약

이 논문은 코드 생성 LLM을 “맞았는지”만 평가하지 말고, 무엇을 근거로 생성했는지를 개발자가 이해할 수 있는 수준에서 보자고 제안한다.

핵심 도구는 CodeQ다.

CodeQ는 모델이 참고한 토큰을 그대로 보여주는 데서 멈추지 않는다.

토큰을 다음과 같은 개발자 친화적 개념으로 묶는다.

조건문
반복문
식별자
문장
들여쓰기
테스트 코드 맥락
focal method

그다음 수천 개의 예측을 모아, 모델의 전역적 reasoning 패턴을 분석한다.

결론은 분명하다.

코드 생성 모델은 사람처럼 깊은 의미를 먼저 보는 것이 아니라, 꽤 자주 얕은 문법적 단서에 기대어 예측한다.

왜 이 논문이 필요한가

코드 LLM 평가는 보통 정확도 중심이다.

예를 들면 다음과 같다.

정답과 문자열이 일치하는가
테스트를 통과하는가
CodeBLEU 점수가 높은가
HumanEval에서 pass@k가 좋은가

이런 지표는 유용하다.

하지만 중요한 질문 하나를 놓친다.

모델이 왜 그 코드를 생성했는가?

정답을 냈더라도 이유가 불안정할 수 있다.

예를 들어 모델이 조건문의 의미를 이해해서 코드를 만든 것이 아니라, 단순히 들여쓰기나 특정 변수명 패턴을 보고 다음 토큰을 맞혔을 수 있다.

이 경우 정확도는 높아도 신뢰는 위험하다.

기존 설명 방식의 한계

기존 XAI 기법은 대체로 로컬 설명에 강하다.

하나의 입력과 하나의 출력에 대해 “이 토큰이 중요했다”를 보여준다.

문제는 두 가지다.

첫째, 토큰 단위 설명은 너무 잘게 쪼개져 있다.

개발자는 if, self, =, 줄바꿈 같은 개별 토큰보다, “조건문”, “식별자”, “문장 구조” 같은 개념으로 코드를 이해한다.

둘째, 로컬 설명만으로는 모델의 습관을 알기 어렵다.

모델이 반복적으로 문법 단서에 의존하는지, 테스트 생성에서 어떤 코드 영역을 주로 보는지, 자연어 설명이 어느 정도 영향을 주는지는 많은 샘플을 모아야 보인다.

Crop 포인트: 초록색 rationale 토큰이 그대로 최종 설명이 되는 것이 아니라, 개발자가 이해할 수 있는 코드 개념으로 단계적으로 묶이는 흐름이 핵심이다.

CodeQ의 핵심 아이디어

CodeQ는 코드 LLM 설명을 네 단계로 바꾼다.

모델이 특정 토큰을 생성할 때 참고한 입력 토큰을 찾는다.
그 토큰을 코드 개념으로 매핑한다.
많은 예측 결과를 모아 전역 통계를 만든다.
heatmap, 빈도표, dependency map으로 설명한다.

수식으로 보면 복잡하지만, 직관은 단순하다.

“모델이 본 조각”을 “개발자가 이해하는 개념”으로 번역하고, 이를 대량으로 집계한다.

Crop 포인트: CodeQ의 가치는 rationalization 자체보다, 토큰 설명을 개념 단위로 줄이고 전역 설명으로 확장하는 중간 과정에 있다.

설명 단위: 토큰이 아니라 코드 개념

CodeQ는 토큰을 여러 계층의 개념으로 묶는다.

코드 완성에서는 AST와 자연어 품사 정보를 활용한다.

대표 개념은 다음과 같다.

identifier
statement
conditional
loops
operators
indentation
comment
string
noun
verb

이렇게 하면 모델이 개별 토큰 하나에 반응했는지보다, 어떤 종류의 코드 구조에 의존했는지를 볼 수 있다.

Crop 포인트: 개별 토큰을 Semantic, Non Semantic, Natural Language in Code 같은 상위 묶음으로 올려야 전역 분석이 가능해진다.

테스트 생성에서는 조금 다른 관점이 필요하다.

JUnit 테스트를 만들 때 모델이 참고하는 것은 단순한 토큰이 아니다.

특히 중요한 것은 테스트 대상 메서드와 그 주변 코드다.

논문은 eWASH의 context window 개념을 사용해 입력 코드를 다음 영역으로 나눈다.

class
focal method
constructor
method signature
field

Crop 포인트: 테스트 생성 설명에서는 전체 클래스보다 focal method와 그 주변 맥락이 어떤 테스트 코드로 이어지는지가 핵심이다.

CodeQ가 rationale을 찾는 방식

논문은 모델의 예측을 유지하는 데 필요한 최소한의 입력 조각을 찾는다.

절차는 탐욕적으로 진행된다.

처음에는 아무 토큰도 선택하지 않는다.

그다음 현재 예측 확률을 가장 크게 높이는 토큰을 하나씩 추가한다.

이 과정을 반복해, 특정 출력 토큰을 설명하는 입력 토큰 집합을 만든다.

중요한 점은 이것이다.

CodeQ는 여기서 멈추지 않는다.

토큰 단위 rationale은 너무 희박하고 불안정하다.

그래서 CodeQ는 이를 개념 단위로 바꾼 뒤, 여러 샘플과 여러 trial을 합쳐 전역 신호를 만든다.

Crop 포인트: 토큰 간 영향 관계를 바로 해석하지 않고, 개념 간 영향 관계로 축소한 뒤 전체 데이터셋 수준에서 합치는 과정이 중요하다.

실험 설정

논문은 CodeQ를 두 가지 코드 생성 상황에 적용했다.

1. Python 코드 완성

사용 모델은 codeparrot-small이다.

decoder-only Transformer
약 110M 파라미터
Python 코드 완성 실험
50K Python snippet에서 testbed 구성
네 가지 prompt 유형 사용
각 prompt마다 rationale을 30회 샘플링
총 12K개의 생성 시퀀스 분석

네 가지 prompt 유형은 다음 차이를 본다.

signature와 잘린 body만 있는 경우
docstring, signature, body가 함께 있는 경우
docstring과 signature만 있는 경우
docstring만 있는 경우

즉, 코드 구조가 많은 입력과 자연어 설명이 많은 입력에서 모델의 reasoning이 어떻게 달라지는지를 본다.

2. Java 테스트 생성

사용 모델은 BART-large다.

encoder-decoder 구조
Methods2Test 데이터셋 사용
focal method와 JUnit test 쌍을 분석
1K개 샘플 사용
source code와 generated test 사이의 rationale 분석

이 설정은 CodeQ가 decoder-only 모델뿐 아니라 encoder-decoder 모델에도 적용될 수 있음을 보이기 위한 것이다.

결과 1: 토큰 설명은 약하고 시끄럽다

토큰 수준 설명은 신호가 약했다.

개별 토큰이 예측에 기여하는 정도는 대부분 매우 낮았다.

논문은 token-level rationale의 중앙값이 대체로 0.012 미만이라고 보고한다.

하지만 토큰을 코드 개념으로 묶으면 상황이 달라진다.

개념 수준에서는 많은 프로그래밍 카테고리가 0.06~0.07 수준의 중앙값을 보였다.

대략 6배 강한 신호다.

불확실성도 크게 줄었다.

토큰 수준에서 높던 설명 분포의 엔트로피가 개념 수준으로 집계되자 약 50% 감소했다.

이 결과는 CodeQ의 전제를 뒷받침한다.

개별 토큰 설명은 개발자에게도, 통계적으로도 불안정하다.

개념 단위 설명이 더 적합하다.

결과 2: 모델은 의미보다 문법 단서를 자주 본다

Python 코드 완성에서 모델은 다음 범주를 자주 rationale로 사용했다.

structural
statements
expression
punctuation
identifiers

반대로 다음처럼 의미가 더 강한 범주는 훨씬 덜 사용됐다.

loops
conditionals
asserts
bool

이 결과는 중요하다.

사람 개발자는 코드를 볼 때 조건, 반복, 불리언 로직, 예외 처리 같은 의미 구조를 먼저 생각하는 경우가 많다.

하지만 모델은 더 자주 표면적 패턴을 본다.

즉, 모델은 “프로그램의 의도”보다 “코드처럼 보이는 구조”에 더 많이 기대는 경향을 보인다.

결과 3: 입력 맥락이 바뀌면 reasoning도 바뀐다

모델은 고정된 방식으로만 reasoning하지 않았다.

입력에 코드 구조가 많을 때는 문법적 단서와 자기 의존성이 강했다.

예를 들어 특정 구조를 생성할 때, 같은 종류의 기존 구조를 다시 참고하는 경향이 나타났다.

반대로 docstring 중심 입력에서는 자연어 단서가 더 중요해졌다.

자연어의 명사나 설명이 identifier, statement, object-oriented concept 같은 코드 구조 생성에 영향을 줬다.

이 점은 CodeQ가 단순히 “모델은 문법만 본다”고 결론내리지 않는다는 뜻이다.

더 정확히는 다음과 같다.

모델은 사용 가능한 prompt 정보에 따라 문법적 단서와 의미적 단서 사이를 이동한다.

다만 전반적으로 얕은 문법 단서의 비중이 크다.

결과 4: 테스트 생성에서는 focal method가 중요하다

Java 테스트 생성 실험에서는 source code의 어떤 부분이 generated test에 영향을 주는지 분석했다.

가장 중요한 영역은 예상대로 focal method였다.

논문은 평균 영향도를 다음처럼 보고한다.

focal method: 약 0.50
method signature: 약 0.22
class: 약 0.14
field: 약 0.006

흥미로운 점은 field다.

확률 영향도는 낮았지만, token 수 기준으로는 큰 비중을 차지했다.

즉, field는 강한 단서라기보다 넓게 깔린 배경 정보에 가깝다.

Crop 포인트: 테스트 생성에서는 대각선의 자기 의존성뿐 아니라, focal method와 signature가 여러 target concept으로 이어지는 관계를 봐야 한다.

결과 5: 사람과 모델의 설명은 잘 맞지 않았다

논문은 37명의 참가자를 대상으로 사용자 연구를 진행했다.

참가자는 Python, Java, ML 기반 코드 생성 경험을 가진 연구자와 학생이었다.

사용자 연구의 핵심 질문은 두 가지였다.

CodeQ 설명이 실제로 유용한가
모델의 rationale이 사람의 reasoning과 맞는가

유용성 평가는 긍정적이었다.

89%: 모델 fine-tuning에 유용할 수 있다
84%: 모델 출력 해석에 유용하다
81%: 입력과 출력 사이의 관계 추론에 유용하다
78%: AST 기반 코드 완성 설명이 informative하다
79%: context-level 테스트 생성 설명이 informative하다

하지만 readability는 상대적으로 낮았다.

AST 기반 시각화 readability: 52%
context-level 시각화 readability: 59%

즉, 개념은 유용하지만 시각화는 더 개선할 여지가 있다.

가장 중요한 결과는 alignment다.

사람이 선택한 rationale과 모델 rationale의 겹침은 낮았다.

코드 완성: 0.074
테스트 생성: 0.306

이 수치는 모델과 사람이 같은 이유로 코드를 생성한다고 보기 어렵다는 뜻이다.

이 논문이 말하는 신뢰

이 논문에서 신뢰는 “모델을 더 믿자”가 아니다.

오히려 더 정확히는 calibrated trust에 가깝다.

모델을 믿어도 되는 경우와 의심해야 하는 경우를 구분하자는 것이다.

CodeQ는 다음 상황에서 특히 유용하다.

모델이 문법 단서에 과하게 의존하는지 확인할 때
특정 코드 개념을 잘못 학습했는지 진단할 때
fine-tuning 데이터가 어떤 개념을 보강해야 하는지 볼 때
테스트 생성 모델이 focal method를 제대로 참고하는지 확인할 때
사람의 reasoning과 모델 rationale이 어디서 갈라지는지 볼 때

정확도 지표는 이런 질문에 답하지 못한다.

CodeQ는 이 빈틈을 메운다.

한계

논문도 한계를 명확히 인정한다.

첫째, 실험 모델은 최신 대형 모델이 아니다.

codeparrot-small과 BART-large는 분석 가능성과 계산 비용을 고려한 선택이다.

둘째, CodeQ는 white-box 접근이 필요하다.

모델 내부 확률과 fine-tuning이 필요하기 때문에, 폐쇄형 API 모델에는 바로 적용하기 어렵다.

셋째, 토큰을 어떤 개념으로 묶을지는 설계 선택이다.

AST 기반 taxonomy는 타당하지만, 다른 taxonomy를 쓰면 결과가 달라질 수 있다.

넷째, 사용자 연구는 탐색적이다.

다른 설명 기법과의 정식 비교 실험은 포함되지 않았다.

실무적 시사점

이 논문은 코드 LLM을 평가할 때 다음 관점을 추가하라고 말한다.

정답을 냈는가?

여기서 멈추지 말고,

무엇을 보고 정답을 냈는가?

까지 봐야 한다.

특히 코드 생성 도구를 실제 개발 워크플로에 넣는다면, 다음 질문이 중요해진다.

모델이 의미를 보고 있는가
변수명과 들여쓰기 같은 표면 단서에 끌려가고 있는가
테스트 생성에서 focal method를 제대로 반영하는가
모델의 reasoning이 개발자의 reasoning과 얼마나 다른가

CodeQ는 이 질문들을 전역적으로 다룬다.

개별 예측 하나의 설명이 아니라, 모델의 반복되는 습관을 드러낸다.

그 점에서 이 논문은 코드 LLM 해석 가능성을 “토큰 설명”에서 “개발자 중심 개념 설명”으로 옮기는 시도다.

핵심 정리

정확도만으로는 코드 LLM을 신뢰하기 어렵다.
토큰 수준 설명은 너무 작고 노이즈가 크다.
CodeQ는 토큰 rationale을 코드 개념으로 매핑한다.
개념 수준 집계는 설명 신호를 강화하고 불확실성을 줄인다.
코드 완성 모델은 의미 구조보다 문법적 단서에 자주 의존했다.
테스트 생성에서는 focal method와 method signature가 중요한 단서였다.
사람과 모델의 rationale은 크게 어긋났다.
CodeQ의 목적은 신뢰를 무작정 높이는 것이 아니라, 신뢰와 의심을 조정하는 것이다.

Source

Dipin Khati, Daniel Rodriguez-Cardenas, David N. Palacio, Alejandro Velasco, Michele Tufano, Denys Poshyvanyk. Enabling Global, Human-Centered Explanations for LLMs: From Tokens to Interpretable Code and Test Generation. ICSE ’26, Rio de Janeiro, Brazil.
arXiv: https://arxiv.org/abs/2503.16771
DOI: https://doi.org/10.1145/3744916.3787764
Online Appendix: https://github.com/WM-SEMERU/code-rationales/

'AI 생성 글 정리 > modeling' 카테고리의 다른 글

Training Language Models to Self-Correct via Reinforcement Learning 논문 정리 (0)	2026.04.21
[STaR: Self-Taught Reasoner Bootstrapping Reasoning With Reasoning] 논문 정리 (1)	2026.04.21
The Sparsely-Gated Mixture-of-Experts Layer 논문 정리 (0)	2026.04.21
GShard 논문 정리 (1)	2026.04.21
LoRA: Low-Rank Adaptation of Large Language Models 논문 정리 (0)	2026.04.21