인공지능이 코드를 이해하는 시대 – 인간이 만든 방식보다 더 똑똑할까?

소프트웨어를 해석하고 이해하는 기술은 단순히 ‘코드를 잘 짜는’ 문제를 넘어서, 이미 만들어진 프로그램을 어떻게 효율적으로 해체하고 재구성할 수 있는가에 대한 문제로 이어진다. 이른바 ‘리버스 엔지니어링(역공학)’이라 불리는 이 기술은, 특히 오래된 시스템을 현대 기술로 옮기거나 내부 작동 원리를 명확히 파악해야 할 때 필수적이다.

그런데 여기, 전통적인 리버스 엔지니어링 방식과 최신 인공지능 기술을 정면으로 비교한 연구가 있다. 킹스 칼리지 런던의 하난 시알라(Hanan Siala)와 케빈 라노(Kevin Lano) 교수는 이 논문에서 기존의 모델 기반 방식(MDRE)과 대형 언어 모델(LLM)을 리버스 엔지니어링 작업에 투입해 그 성능을 비교했다.
결과는? 꽤 흥미롭다.

리버스 엔지니어링이란 무엇인가?

소프트웨어 개발에서의 리버스 엔지니어링은, 완성된 코드로부터 원래 설계 구조나 명세(specification)를 추출해내는 과정이다. 즉, 일종의 ‘거꾸로 개발’이다.
이때 우리가 추출하고자 하는 명세는 단순한 주석이나 요약이 아닌, 형식 언어로 표현된 정확한 동작 조건과 제약사항들이다. 이 논문에서 사용된 명세 언어는 OCL(Object Constraint Language)로, UML(통합 모델링 언어)과 함께 프로그램의 논리를 정형화하는 데 사용된다.

두 가지 방법: MDRE vs LLM

연구팀은 두 가지 전혀 다른 접근을 실험했다.

MDRE(Model-Driven Reverse Engineering)
이 방식은 프로그램 코드를 구조적으로 분석하고, 사람이 정의한 변환 규칙에 따라 OCL 명세로 추출하는 것이다. 대표적인 도구는 AgileUML. 이 툴은 자바와 파이썬 코드를 UML/OCL로 정제하여 추상화해 준다.
LLM(Large Language Model)
GPT-4나 Mistral 같은 언어 모델을 활용해 코드로부터 OCL 명세를 추출하는 방식이다. 연구팀은 특히 Mistral-7B 모델을 활용해 직접 학습을 시켰으며, 이 훈련된 모델을 LLM4Models라 명명했다.

실험은 어떻게 했을까?

훈련을 위해 연구팀은 자바와 파이썬 코드 예제 각각 수만 개(자바 20,580건, 파이썬 25,684건)를 수집하고, 이에 해당하는 OCL 명세를 AgileUML로 자동 생성해 학습 데이터로 만들었다.

이후, 모델을 훈련하는 방식으로는 비용 효율적인 QLoRA(양자화된 저랭크 적응) 기술을 사용했다. 이 기술은 모든 파라미터를 다시 훈련시키지 않고도 정밀한 튜닝을 가능하게 한다. 즉, ‘똑똑한 AI’를 리버스 엔지니어링 작업에 특화된 전문가로 바꾸는 것이다.

그 결과는?

연구팀은 세 가지 접근 — AgileUML, 비훈련 LLM(GPT-4), 훈련된 LLM(LLM4Models) — 을 비교했다. 평가 기준은 다음과 같았다:

문법 정확성(Syntax): OCL 명세가 문법적으로 올바른가?
완전성(Recall): 코드의 정보를 얼마나 빠짐없이 반영했는가?
일관성(Precision): 생성된 명세가 코드의 실제 의미와 일치하는가?
형식 수준(Formality): 명세가 얼마나 명확하게 절차를 표현하는가?

결과 요약 (자바 기준)

접근 방식	문법 정확도	완전성	일관성	F1 점수	명시적 스타일
AgileUML	83%	87%	99%	0.93	100%
GPT-4 (미훈련)	33%	65%	71%	0.68	83%
LLM4Models	83%	96%	96%	0.96	100%

예제를 통해 보는 차이

다음은 자바 프로그램 중 하나인 ‘배열의 균형 인덱스를 찾는 함수’이다:

int sum = 0;
int leftsum = 0;
for (int i = 0; i < n; ++i)
    sum += arr[i];
for (int i = 0; i < n; ++i) {
    sum -= arr[i];
    if (leftsum == sum)
        return i;
    leftsum += arr[i];
}

AgileUML과 LLM4Models 모두 다음과 같은 구조적 OCL 명세를 생성한다:

for i : Integer.subrange(0, n-1) do (
  sum := sum + arr[i+1]
);

for i : Integer.subrange(0, n-1) do (
  sum := sum - arr[i+1];
  if leftsum = sum then return i;
  leftsum := leftsum + arr[i+1];
);

반면, GPT-4는 다음과 같은 ‘추상적’ 명세를 생성한다:

post: arr->subSequence(1, result - 1)->sum() =
      arr->subSequence(result + 1, n)->sum()

설명은 맞지만, 실제 동작을 다시 구현하거나 검증하기엔 정보가 부족하다. 사용자 입장에서 쓸 수 있는 결과가 아니었던 것이다.

단점은 없었을까?

물론 LLM 기반 방식에도 문제는 있었다. 특히 변수의 타입 추론, 반복문 변환에서 일부 오류가 발생했다. 그리고 다음과 같은 단점들이 GPT-4와 LLM4Models 모두에서 관찰되었다:

Hallucination: 코드에 없는 요소(예: 불필요한 제약 조건)를 추가하는 경우
불완전한 변수 추론: 특히 파이썬처럼 타입이 명시되지 않은 언어에서
복잡한 코드에 대한 과도한 단순화

하지만 이러한 문제는 LLM4Models에선 GPT-4보다 훨씬 덜 발생했으며, 추가적인 후처리나 검증 도구와 결합해 해결 가능성도 크다고 저자는 밝혔다.

그래서, 누가 이겼는가?

정답은: 둘 다 필요하다. 하지만 둘을 합치면 더 강하다.

AgileUML 같은 도구는 여전히 구조적 정확성이 뛰어나다. 하지만 LLM4Models는 훨씬 더 직관적이고 빠르게 명세를 생성한다. 특히 도메인 지식 없이도 누구나 LLM에게 코드를 보여주고 명세를 받을 수 있는 장점은 실무에서 매우 크다.

연구팀은 AgileUML로 만든 데이터를 LLM 학습에 활용했고, 그 결과 기존 방식의 장점을 AI가 흡수하게 된 셈이다.

다음은 어디로?

이 연구는 단순한 기술 비교가 아니다. 이는 리버스 엔지니어링의 미래가 AI와 사람의 협업에 있음을 시사한다. 더 많은 데이터와 도메인 확장을 통해, 앞으로는 코드를 명세로 바꾸고, 다시 새 프로그램으로 재구성하는 전 과정을 AI가 수행할 수 있을지도 모른다.

그리고 그렇게 된다면, 우리 모두의 코드가 언젠가는 AI 손에 의해 더 나은 방식으로 되살아날 수 있을 것이다.

출처

Siala, H., & Lano, K. (2025). A comparison of large language models and model-driven reverse engineering for reverse engineering. Frontiers in Computer Science, 7, 1516410. https://doi.org/10.3389/fcomp.2025.1516410