9.3.2 TypeScript 컴파일러 API를 이용한 인터페이스 준수 여부 검증

9.3.2 TypeScript 컴파일러 API를 이용한 인터페이스 준수 여부 검증

프론트엔드 및 Node.js 백엔드 개발에 있어, 단순히 타입 힌트를 적어 넣는 파이썬의 수준을 아득히 뛰어넘어 가장 강력하고 공학적인 타입 검증을 제공하는 도구가 바로 **TypeScript(TS)**다. TypeScript는 자바스크립트의 유연함을 살리면서도, 컴파일 타임에 철저한 타입 및 인터페이스(Interface) 검사를 수행하는 거대한 정적 분석 엔진이다.

오라클 설계 관점에서 TypeScript가 갖는 진정한 가치는 단순히 tsc 명령어를 실행하여 성공/실패만 반환받는 데 있지 않다. TypeScript는 스스로의 컴파일을 조작할 수 있는 Compiler API를 개방해 두고 있다. 오라클은 이 Compiler API를 사용하여, LLM이 메모리에 토해낸 텍스트를 가상의(Virtual) 파일 시스템에 얹고 타입 체킹의 전체 프로세스를 자동화 기계처럼 조종할 수 있다.

마치 법관이 육법전서를 펼쳐놓고 계약서의 모든 조항을 대조하듯, 오라클은 TypeScript Compiler API를 통해 LLM이 작성한 코드가 사내 표준 인터페이스의 요구사항을 한 치의 오차도 없이 구현(Implement)했는지 결정론적으로 검증해 낸다.

1. 컴파일러 API를 활용한 가상 런타임 검증 환경 구축

만약 LLM이 50개의 코드를 동시에 뱉어냈을 때, 이를 검증하기 위해 디스크(Disk)에 50개의 .ts 파일을 쓰고 지우는 I/O 작업을 반복한다면 오라클 파이프라인의 속도는 끔찍하게 느려질 것이다. TypeScript Compiler API의 강력함은 이것을 메모리 상에서 완벽히 격리된 채 처리할 수 있다(In-memory compilation)는 점에 있다.

  • 오라클 코어는 ts.createProgram()을 호출하여 새로운 분석 세션을 연다.
  • 이때, 파일 시스템을 뒤지는 대신 커스텀 CompilerHost를 주입(Inject)하여, 파일 경로를 읽으려는 컴파일러의 시도를 가로채어 LLM이 방금 생성한 메모리 상의 텍스트 조각을 반환하도록 속인다.
  • 이렇게 구성된 가상 환경에서 program.getSemanticDiagnostics()를 호출하면, TypeScript 내부의 타입 호환성 검사기(Type Compatibility Checker)가 가동되며 런타임 이전에 발생할 모든 의의론적(Semantic) 에러를 쓸어 담은 분석 리스트를 반환한다.

2. 인터페이스(Interface) 계약의 강제와 에러 추출

LLM에게 다음과 같은 규격을 구현하라고 프롬프트를 전송했다고 가정하자.

// 반드시 이 인터페이스를 구현하라
interface PaymentGateway {
  process(amount: number, currency: string): Promise<boolean>;
}

LLM이 이를 구현하되, 파라미터 amount를 number가 아닌 string으로 받도록 잘못 작성했거나, 반환값을 Promise<boolean> 대신 void로 누락했다면 어떨까? 텍스트 파싱 수준에서는 저 세부적인 타입들이 올바르게 엮였는지 알 도리가 없다.

하지만 getSemanticDiagnostics()가 뱉어내는 진단 객체(Diagnostic Object)는 완전히 다른 차원의 정보를 제공한다.

  • 오라클은 반환된 배열에서 에러 코드(Error Code)를 스캔한다.
  • 만약 TS2420 (Class incorrectly implements interface) 에러가 감지된다면, 이는 LLM이 인터페이스의 형태를 마음대로 비틀어버렸음을 의미한다.
  • TypeScript는 단순히 틀렸다는 데 그치지 않고, diagnostic.messageText를 통해 *“Property ‘process’ in type ‘MyGateway’ is not assignable to the same property in base type ‘PaymentGateway’. Type ‘(amount: string) => void’ is not assignable to type ‘(…)’”*라는 인간이 이해하기도 벅찬 구체적인 타입 추론 궤적을 제시한다.

3. 피드백 루프: 타입 언어를 통한 AI의 교정

오라클은 컴파일러가 도출한 이 정밀한 진단 텍스트를 가공하지 않고 그대로 타겟 프롬프트에 실어 LLM에게 돌려보낸다.

흥미로운 점은, 최신 LLM들은 런타임의 Null Error를 던져줄 때보다, 이렇게 TypeScript 컴파일러나 Rust의 Borrow Checker가 뱉어내는 **‘수학적이고 논리적인 타입 에러 메시지’**를 받았을 때 버그를 수정(Self-Correction)하는 확률이 기하급수적으로 높다는 것이다. AI 네트워크는 방대한 깃허브(GitHub)의 이슈 트래커를 통해 해당 에러 코드가 무엇을 의미하고 어떻게 고쳐야 하는지 이미 완벽하게 학습해 두었기 때문이다.

정리하자면, TypeScript Compiler API는 단순히 코드가 ’실행될 수 있는지’를 묻는 소극적인 방어막이 아니다. 그것은 오라클이 LLM의 생성물에 대해 사전에 정의된 ’데이터의 법률(Interfaces)’을 강제로 집행하고, 위반 사항에 대해 가장 논리적인 판결문(Diagnostic Message)을 내려 AI 스스로 코드를 교정하도록 유도하는 최고 등급의 자동화된 심판(Automated Judge)이다.