9.4.5 사용되지 않는 변수(Unused Variables) 및 임포트(Imports) 정리

9.4.5 사용되지 않는 변수(Unused Variables) 및 임포트(Imports) 정리

LLM이 코드를 생성하는 방식은 인간과는 근본적으로 다르다. 인간은 필요한 라이브러리를 하나씩 생각하며 임포트(Import)하고, 로직을 짜 내려가면서 변수를 선언한다. 반면, LLM은 방대한 컨텍스트 상에서 이전에 보았던 코드 패턴이나 자신이 방금 전까지 출력했던 텍스트의 확률 분포에 의존하여 코드를 ’스트리밍(Streaming)’한다.

이러한 특성 때문에 AI가 생성한 코드베이스에는 필연적으로 무수한 **‘데드 코드(Dead Code)’**가 쌓이게 된다. 쓰지도 않을 import os, import json을 파일 최상단에 습관적으로 선언하거나, 중간에 로직의 방향이 바뀌었음에도 이전에 선언해 둔 temp_index = 0 같은 변수를 지우지 않고 방치하는 현상이다.

이러한 잔여물들은 로직의 실행 자체를 방해하지는 않으므로 런타임 테스트(Unit Test)에서는 무사 통과된다. 하지만 엔터프라이즈 환경에서 이 데드 코드가 패키징(Packaging)되어 배포될 경우, 불필요한 메모리 점유, 번들(Bundle) 사이즈 구대화, 그리고 가장 치명적인 보안 취약점 레이어의 증가라는 끔찍한 연쇄 효과(Butterfly Effect)를 낳는다.

오라클 환경 구축 시 이 데드 코드를 탐지하고 소각하는 역할은 정적 린팅 파이프라인의 핵심 임무 중 하나다.

1. 정적 스코프 분석(Lexical Scope Analysis)을 통한 데드 코드 색출

ESLint(no-unused-vars)나 파이썬의 Flake8, Ruff 같은 정적 분석 도구를 오라클 엔진에 파이핑(Piping)하면, 코드가 실행되기 전에 소스 파일 공간의 모든 변수를 추적할 수 있다.

  • 오라클은 AST 기반의 **심볼 테이블(Symbol Table)**에 코드 내 선언된 모든 임포트(Import), 함수명, 변수명을 등록한다.
  • 이후 순회망이 실행 로직을 따라가면서 해당 심볼이 ‘Read(읽기)’ 되거나 ‘Execute(실행)’ 되는지를 카운팅한다.
  • 분석 종료 후 참조 카운트가 0인 심볼이 발견된다면, 오라클은 이를 즉시 적발하여 데드 코드로 규정한다.

2. 오토 픽스(Auto-Fix)를 통한 무관용 소독(Sanitization)

린팅 파이프라인에서 발견된 데드 코드는 앞서 언급한 ’가독성 문제’나 ’타입 에러’와 달리 LLM에게 프롬프트로 역주입할 가치가 전혀 없다. (“당신이 쓰지 않는 import sys를 남겼으니 지워서 다시 보내라”) 라는 피드백은 값비싼 LLM 호출 비용(API Cost)을 쓰레기통에 처박는 행위다.

데드 코드 정리는 전적으로 **정적 도구단에서의 자동화된 삭제 프로세스(Automated Pruning)**로 해결해야 한다.

  • 오라클 파이프라인에 코드가 진입하면 먼저 autoflake (Python) 같은 전처리 스크립트를 가동한다. 
    # 무의미한 임포트와 사용되지 않는 변수를 텍스트 변경률 계산 이전에 기계적으로 소각
autoflake --in-place --remove-all-unused-imports --remove-unused-variables target_code.py

*   JavaScript 환경에서는 ESLint의 `--fix` 플래그나 TypeScript의 `organizeImports` API를 호출하여 이 작업을 대신한다.

## 3.  데드 코드 누적률(Dead Code Accumulation Rate)의 모니터링


오라클은 단순히 코드를 지우고 끝내서는 안 된다. 만약 특정 코드 생성 세션에서 LLM이 만들어낸 변수의 30%가 데드 코드 처리되어 잘려 나갔다면, 이는 심각한 **할루시네이션(Hallucination)**의 전조 증상이다.

*   로직을 어떻게 구상할지 갈피를 못 잡고 여러 가지 방안(변수)만 나열해 두었을 확률이 높다.
*   오라클 설계자는 `Autoflake`나 린터가 오토 픽스로 날려버린 '토큰 건수' 혹은 '라인 수'를 추적하여, 이 수치가 파일 변동률의 10%를 넘어설 경우 해당 빌드를 Warning 상태로 처리하고, 프롬프트 엔지니어링 팀에 "프롬프트의 목적성이 분명하지 않음"이라는 피드백을 전달해야 한다.

AI는 망설이지 않지만, 그 결과물에는 분명히 '갈팡질팡한 흔적(Dead Code)'이 남는다. 가동되지 않는 변수와 불필요한 임포트는 코드베이스를 무겁게 만드는 비계(Fat)와 같다. 오라클의 린팅 파이프라인은 이 팻(Fat)들을 컴파일러에 도달하기 전 미리 걷어내는 가장 빠르고 효율적인 정육점 칼(Butcher's Knife)이어야 한다.