9.5.3 링킹 에러(Linking Error) 분석을 통한 참조 무결성 확인

C++이나 Rust와 같은 시스템 언어에서 컴파일(Compile)은 단지 전체 파이프라인의 절반에 불과하다. 개별 소스 코드가 각각의 오브젝트 파일(.o 혹은 .obj)로 완벽하게 변환되었다(컴파일 성공) 하더라도, 마지막 순간에 이 조각들을 하나의 실행 가능한 바이너리(Binary)로 꿰매는 **링커(Linker)**의 단계를 통과하지 못하면 그 코드는 실패작이다.

LLM은 종종 함수에 대한 선언(Declaration)만 덜렁 적어놓고, 어딘가에 있어야 할 그 함수의 실제 구현체(Implementation)를 작성하는 것을 잊어버리거나(Hallucinated Function), 동적 공유 라이브러리(.so, .dll)의 함수를 호출해 놓고 빌드 스크립트에 링킹 플래그(-l)를 주입하는 것을 누락하곤 한다.

오라클 환경 구축에서 링킹 파이프라인은 LLM이 생성한 코드가 다른 파일, 다른 라이브러리와 물리적(Physical)으로 결합될 수 있는 상호운용성(Interoperability)을 갖추었는가를 검증하는 가장 핵심적인 관문이다.

1. Undefined Reference 탐지와 외부 종속성 환각 판별

가장 악명 높고 흔하게 발생하며, LLM 코드 생성기가 자주 일으키는 링킹 에러는 **Undefined reference to 'function_name' (LNK2019 등의 심볼 확인 실패)**이다.

LLM에게 *“최적화된 정렬 알고리즘을 사용해라”*라고 지시했을 때, LLM이 fast_sort(data);라는 함수를 호출하는 코드를 작성했다 치자. 컴파일러는 어딘가에 fast_sort라는 선언이 있겠거니 하고 구문 검사를 넘겨버릴 수 있다(특히 C++의 헤더 파일 분리 환경에서 더욱 그렇다). 그러나 최종 링킹 단계에서 링커는 프로젝트 전체를 뒤져봐도 fast_sort의 실제 코드가 존재하지 않음을 깨닫고 빌드를 멈춘다.

이것은 단순한 오타가 아니라 명백한 **‘참조 환각(Reference Hallucination)’**이다.

• 오라클 파사드(Oracle Facade)는 ld나 lld 링커가 던지는 에러 로그에서 undefined reference 키워드를 정규식으로 추출한다.
• 이 에러가 감지되면 오라클은 LLM에게 *“당신이 호출한 fast_sort 함수는 현재 코드베이스 내에 존재하지 않습니다(Undefined Symbol). 이 함수의 실제 구현체를 추가로 작성하거나, 표준 라이브러리의 함수(예: std::sort)로 수정하십시오”*라는 피드백을 전달하여 잃어버린 심볼(Symbol)을 채우도록 강제한다.

2. Duplicate Symbol (중복 정의) 및 ODR 위반 색출

반대로, LLM이 문맥을 너무 열정적으로 해석한 나머지 이미 시스템에 존재하는 함수나 전역 변수를 다시 한번 전역(Global) 스코프에 선언해 버리는 경우도 있다. 이는 C++ 등에서 악명 높은 ODR(One Definition Rule) 위반으로 직결된다.

이때 링커는 Multiple definition of 'function_name' 에러를 출력한다.

• 오라클 시스템은 이 ODR 위반 에러를 포착하는 즉시, LLM이 컨텍스트(Context Length)를 제대로 파악하지 못해 타 컴포넌트의 책임을 월권(Overreach)했다고 간주한다.
• 이에 대한 자가 수정(Self-correction) 프롬프트는 *“현재 프로젝트의 다른 파일에서 이미 해당 이름의 객체가 선언되어 참조 충돌이 일어났습니다. 변수명을 로컬 스코프로 캡슐화(Encapsulation)하거나 static 키워드를 사용하여 외부 링킹을 차단하십시오”*와 같이 링커의 관점에서 구체적으로 제시되어야 한다.

3. ABI(Application Binary Interface) 불일치의 차단

C++과 Rust, 혹은 C 라이브러리를 바인딩(FFI, Foreign Function Interface)하는 고도의 저수준(Low-level) 코드를 LLM이 생성할 때 링킹 오라클의 가치는 절정에 달한다.

LLM이 C 라이브러리의 함수를 호출하면서 C++ 측에 extern "C" 블록을 씌우는 것을 잊어버리면, C++ 컴파일러는 함수 이름을 제멋대로 맹글링(Name Mangling)해버린다. 결과적으로 함수는 분명히 존재하지만, 링커는 맹글링된 엉뚱한 이름을 찾다가 에러를 뿜어낸다.

오라클의 링킹 분석 계층은 이러한 ABI 레벨의 에러를 감지하여 LLM에게 extern "C" 래핑이 누락되었는지 검토하라는 고차원적인 시스템 경고를 날려준다. 링킹 오라클은 소스코드를 ‘파일’ 단위가 아니라 전체 시스템을 관통하는 거대한 톱니바퀴의 맞물림(Integration) 과정으로 바라본다. 이 엄격한 검증을 거친 후에야 우리는 AI가 생성한 조각(Segment)이 다른 인간 엔지니어들의 코드와 하나의 바이너리로 온전히 용접(Welding)될 수 있음을 수학적으로 보장할 수 있다.