기술 요약: 자연어 질문으로부터 복잡한 코드 분석기 생성하기

문제 정의

소프트웨어 개발에서는 개발자가 코드베이스의 전역 구조, 의미론, 잠재적 버그를 이해하기 위해 분석적 질문을 자주 제기합니다. 그러나 수천 개의 파일에 걸친 수백만 줄의 코드로 구성된 대규모 시스템에서 이러한 질문에 답하는 것은 상당한 어려움을 수반합니다:

1. 표준 도구의 한계: grep이나 IDE 검색 기능과 같은 도구는 구문적 또는 국소적 패턴 매칭에 국한되어 있으며, 복잡한 쿼리 (예: 생성자 내에서 오버라이드 가능한 메서드를 호출하는 메서드 찾기) 에 필요한 절차 간 추론이나 의미론적 분석을 수행할 수 없습니다.
2. 대규모 언어 모델 (LLM) 의 한계: LLM 은 자연스러운 인터페이스를 제공하지만, 컨텍스트 창 제약, 리소스 제한, 그리고 코드에 대한 구조화되고 지속 가능한 뷰의 부재로 인해 대규모 코드베이스에서는 어려움을 겪습니다. LLM 에 직접 프롬프트를 입력하면 일관성 없는 출력, 환각, 또는 빈 결과가 자주 발생합니다. 또한, 훈련 데이터의 부족과 언어의 "미묘한" 의미론 (사소한 변이가 구문적으로 유효하지 않거나 의미론적으로 퇴화된 쿼리로 이어질 수 있음) 으로 인해 복잡한 프로그램 분석 쿼리 (특히 CodeQL) 를 생성하는 것은 어렵습니다.

방법론: Merlin 시스템

저자들은 대규모 언어 모델 (LLM) 과 선언적 프로그램 분석 프레임워크인 CodeQL을 통합한 Merlin 시스템을 제시합니다. Merlin 은 자연어 질문을 실행 가능한 CodeQL 쿼리로 변환하며, 답변을 LLM 의 내부 텍스트 표현이 아닌 정적 분석 결과에 기반하여 도출합니다.

이 시스템은 세 가지 주요 구성 요소로 이루어진 워크플로우를 통해 작동합니다:

1. 질문 전처리

쿼리 생성 전에 Merlin 은 두 가지 핵심 산출물을 준비합니다:

• 자기 테스트 생성: LLM 에게 사용자의 목표와 일치하거나 일치하지 않아야 하는 구체적인 코드 예제 (테스트 케이스) 를 생성하도록 프롬프트합니다. 이러한 예제는 전체 코드베이스에 실행되기 전에 (구문적으로 올바르더라도 빈 결과를 생성하는) 퇴화된 쿼리를 감지하는 "시험" 역할을 합니다.
• 반복적 문서 검색: LLM 에게 필요한 CodeQL 구성 요소를 직접 나열하도록 요청하는 것 (이는 환각을 초래함) 대신, Merlin 은 RAG 기반의 반복 루프를 사용합니다. 먼저 사용자의 질문에서 키워드를 추출한 후, LLM 에게 이를 CodeQL 구성 요소에 매핑하도록 요청합니다. 시스템은 이러한 구성 요소를 공식 CodeQL 문서와 대조하여 검증하고, 존재하지 않는 구성 요소에 대한 피드백을 제공하며 유효한 세트가 확립될 때까지 반복합니다.

2. RAG 기반 쿼리 디버깅

LLM 은 사용자의 목표, 출력 스키마, 자기 테스트, 그리고 검색된 문서를 기반으로 초기 CodeQL 쿼리를 생성합니다. 이 쿼리는 CodeQL 컴파일러를 사용하여 컴파일됩니다.

• 컴파일러가 구문 오류를 반환하면, Merlin 은 오류 메시지를 추출하고 관련 구성 요소에 대한 관련 문서를 검색하여 LLM 에게 쿼리를 수정하도록 프롬프트합니다.
• 이 루프는 구문적으로 유효한 쿼리가 생성될 때까지 계속됩니다.

3. 보조 쿼리를 통한 의미론적 검증

구문적으로 유효한 쿼리조차도 의도된 의미론을 포착하지 못할 수 있습니다 (예: 지나치게 선택적이어서 빈 결과를 반환함). 이를 해결하기 위해 Merlin 은 보조 쿼리 (Assistive Queries) 를 활용합니다:

• 쿼리가 자기 테스트를 통과하지 못하면 (빈 결과를 반환), 시스템은 LLM 에게 보조 "보조" 쿼리를 생성하도록 프롬프트합니다.
• 이러한 쿼리는 원래 쿼리가 실패한 이유를 드러내기 위해 허용적 (예: 타입 또는 중간 속성 출력) 으로 설계됩니다.
• 보조 쿼리의 결과는 LLM 에게 피드백되어 의미론적 결함을 진단하고 원래 쿼리를 정제하는 데 사용됩니다.
• 이 "컴파일 - 테스트 - 보조" 루프는 쿼리가 자기 테스트에서 빈이 아닌 결과를 생성할 때까지 반복됩니다.

마지막으로, 검증된 쿼리가 전체 코드베이스에 실행되며, 생성된 CodeQL 쿼리가 정당성 근거로 함께 제공되는 표 형식으로 결과가 사용자에게 제시됩니다.

주요 기여

1. Merlin 시스템: 대규모 코드베이스에 대한 자유 형식의 자연어 질문에 신뢰성 있게 답하기 위해 LLM 을 프로그램 분석기 (CodeQL) 와 통합한 새로운 아키텍처.
2. 새로운 디버깅 기법:
   • CodeQL 훈련 데이터의 부족에도 불구하고 구문적으로 올바른 쿼리를 생성하기 위한 RAG 기반의 반복 절차.
   • 퇴화된 쿼리를 감지하기 위해 자동으로 생성된 코드 예제를 사용하는 자기 테스트 기법.
   • 후보 쿼리의 의미론적 결함을 드러내고 설명하기 위해 진단용 인쇄 문처럼 기능하는 보조 쿼리.
3. 실증적 평가: 벤치마크, 설문 조사, 사용자 연구를 포함한 포괄적인 평가를 통해 시스템의 효과성을 입증.

결과

실험적 평가 (벤치마크)

저자들은 13 개의 대규모 코드베이스에 걸쳐 SpotBugs(142 개의 감지기) 와 GitHub Security Lab(40 개의 쿼리) 에서 파생된 182 개의 자연어 질문에 대해 Merlin 을 평가했습니다.

• 재현율 (Recall): Merlin 은 베이스라인 접근법 (직접 LLM 답변, 디버깅 없는 LLM-to-CodeQL 생성) 보다 재현율 측면에서 현저히 우수했습니다. Merlin 은 거시 재현율 0.62, 미시 재현율 0.64를 달성한 반면, 베이스라인들은 종종 재현율에 어려움을 겪었습니다 (예: GPT-4o/CQL 의 미시 재현율 0.08).
• 정확도와 발견: 베이스라인들은 종종 문제를 놓쳤지만, Merlin 은 참조 분석기의 결과를 재현했을 뿐만 아니라 이전에는 알려지지 않은 위치도 식별했습니다. 사용자 설문 조사에 따르면, 이러한 "새로운" 발견물 중 많은 부분이 다른 도구가 놓친 실제로 관련 있는 코드 조각이었으며, 이는 인간 판단이 기준일 때 Merlin 이 참조 도구보다 더 높은 정확도와 재현율을 달성함을 시사합니다.
• 리소스 효율성: 전체 코드베이스를 LLM 에 업로드해야 하는 (파일 제한과 컨텍스트 창에 부딪히는) 베이스라인과 달리, Merlin 은 코드베이스와 독립적으로 쿼리를 합성하므로 프롬프트 길이와 계산 비용이 현저히 낮습니다.

사용자 연구

SEI CERT 코딩 표준 위반을 찾고 수정하는 임무를 수행한 18 명의 참가자 (학생 13 명, 전문가 5 명) 를 대상으로 한 동일 피험자 연구는 다음과 같은 결과를 보였습니다:

• 정확도: Merlin 에 대한 접근은 작업 정확도를 평균 3.8 배 증가시켰습니다. 개선은 복잡한 작업 (작업 T1: 5.6 배; 작업 T3: 4.9 배) 에서 가장 두드러졌고, 간단한 grep으로 해결 가능한 작업 (작업 T2: 1.6 배) 에서는 덜 두드러졌습니다.
• 효율성: Merlin 을 사용한 참가자들은 평균 31% 더 빠르게 작업을 완료했습니다.
• 행동 변화: Merlin 은 사용자 전략을 노동 집약적인 패턴 매칭 (정규식, 키워드 검색) 에서 고수준 추론으로 전환시켰습니다. 또한 "찾기" 단계에서 외부 AI 에 대한 의존도를 줄였으나, 저자들은 사용자가 Merlin 의 출력을 과도하게 신뢰할 위험이 있음을 지적했습니다.

중요성과 주장

이 논문은 Merlin 이 LLM 의 자연어 인터페이스와 프로그램 분석기의 엄격하고 구조화된 추론 사이의 간극을 성공적으로 메웠다고 주장합니다. 반복적 디버깅과 자기 테스트를 통해 복잡한 저리소스 분석 쿼리 (CodeQL) 생성의 특정 과제를 해결함으로써, Merlin 은 개발자가 대규모 코드베이스에서 포괄적이고 감사 가능하며 반복 가능한 분석을 수행할 수 있게 합니다.

저자들은 Merlin 이 단순한 챗봇이 아니라 검증 가능한 출력(생성된 CodeQL 쿼리) 을 생산하는 시스템임을 강조합니다. 이를 통해 개발자는 결과 뒤의 논리를 검증할 수 있습니다. 이 접근법은 순수 LLM 기반 추론의 불신뢰성과 전통적 정적 분석 도구의 경직성을 극복하여, 코드에 대한 깊은 의미론적 이해가 필요한 현대 소프트웨어 엔지니어링 작업에 대한 실용적인 해결책을 제공합니다.

논문은 범위에 대해 겸손하게, 현재는 버그 찾기 및 분석적 질문에 초점을 맞추고 있으며, 더 넓은 개발자 워크플로우, 상호작용적 디버깅, 비분석적 질문을 지원하기 위해서는 향후 작업이 필요하다고 인정합니다.