Less Is More: Measuring How LLM Involvement affects Chatbot Accuracy in Static Analysis

1. 연구 배경 및 문제 정의 (Problem)

• 비구조화 vs 구조화: 소프트웨어 시스템의 요구사항이나 질문은 자연어 (비구조화) 로 존재하지만, 정적 분석 도구 (예: Joern) 는 CPGQL 과 같은 엄격한 문법과 시맨틱을 가진 도메인 특화 언어 (구조화) 로 쿼리를 작성해야 합니다.
• LLM 의 한계: LLM 은 자연어 이해는 뛰어나지만, 훈련 데이터에 상대적으로 적게 포함된 DSL(도메인 특화 언어) 의 정확한 문법과 시맨틱을 생성하는 데 어려움을 겪습니다. 특히 LLM 은 문법적으로 유효할지라도 의미적으로 틀린 "할루시네이션"을 생성하거나, 키워드와 식별자 간의 관계를 논리적으로 연결하는 데 실패할 수 있습니다.
• 연구 질문: 정적 분석 쿼리 생성 시 LLM 에 얼마나 많은 자유도 (Delegation) 를 부여해야 할까? 직접 생성 (Direct Generation) 이 좋은가, 아니면 중간 표현을 거치거나 에이전트 방식을 사용하는 것이 좋은가?

2. 방법론 (Methodology)

저자는 LLM 의 관여 정도를 독립 변수로 설정하여 세 가지 아키텍처를 비교했습니다. 평가는 오픈소스 Java 프로젝트 (Apache Commons Lang, OWASP WebGoat) 를 대상으로 한 20 개의 코드 분석 태스크 (구조적, 데이터 흐름, 복합적 3 단계 복잡도) 에 대해 수행되었습니다.

• 사용 모델: 4 개의 오픈 가중치 모델 (Llama 3.1/3.3, Qwen 2.5) 을 2 가지 규모 (7-8B, 70-72B) 로 테스트하여 모델 크기와 아키텍처의 상호작용을 분석했습니다.

• 세 가지 아키텍처:

  1. A1 (Direct Generation): LLM 이 CPGQL 쿼리 문자열을 직접 생성합니다. (가장 넓은 출력 공간)
  2. A2 (Structured Intermediate): LLM 이 미리 정의된 JSON 스키마에 맞는 구조화된 중간 표현을 생성합니다. 이후 결정론적 (Deterministic) 매핑 코드가 이를 CPGQL 로 변환합니다. (출력 공간 제한)
  3. A3 (Tool-Augmented Agentic): LLM 이 도구 호출 (Function Calling) 을 통해 다단계 루프 (ReAct 패턴) 로 작업을 수행합니다. 각 단계에서 도구를 선택하고 인자를 전달하며, 최종 답변을 합성합니다.

• 평가 지표:

  • Result Match: 생성된 쿼리의 실행 결과가 정답 (Ground Truth) 과 일치하는지 (문자열 일치 여부가 아닌 결과 집합 일치).
  • Execution Success: 쿼리가 실행 환경에서 오류 없이 실행되는지.
  • Token Consumption: 태스크당 소비된 토큰 수.

3. 주요 결과 (Key Results)

3.1 구조화된 중간 표현 (A2) 의 우월성

• 정확도: 모든 모델에서 A2(구조화된 JSON) 가 가장 높은 정확도를 보였습니다.
  • 대형 모델 (70B 이상) 에서 A1(직접 생성) 대비 15~25%p 향상.
  • 소형 모델 (7-8B) 에서도 3~5%p 향상.
• 이유: LLM 이 복잡한 DSL 문법 대신 제한된 스키마 필드 (쿼리 유형, 소스, 싱크 등) 만을 채우는 '분류 (Classification)' 작업으로 변환되었기 때문입니다. 이는 LLM 이 문법적 구조와 식별자 간의 관계를 연결하는 데 취약하다는 기존 연구 (Anand et al.) 와 일치합니다.

3.2 에이전트 방식 (A3) 의 실패

• 성능 저하: A3 는 모든 모델에서 가장 낮은 정확도 (15~25%) 를 기록했습니다.
• 비용 대비 효율: A3 는 A2 대비 약 8 배 더 많은 토큰을 소비하고, 태스크당 실행 시간도 훨씬 길었음에도 불구하고 정확도는 떨어졌습니다.
• 오류 누적: 다단계 도구 호출 과정에서 초기 단계의 작은 오류가 누적되어 전체 실패로 이어지는 현상이 관찰되었습니다. 또한, A3 가 성공한 태스크는 A2 가 성공한 태스크의 진부분집합 (Strict Subset) 에 불과하여, 에이전트 방식이 제공하는 고유한 장점은 없었습니다.

3.3 모델 크기와 아키텍처의 상호작용

• 대형 모델: JSON 스키마를 정확하게 채울 수 있어 A2 의 이점을 극대화했습니다.
• 소형 모델: A2 의 경우 스키마 준수 (Schema Compliance) 실패율이 35~47% 로 높았습니다. 즉, 소형 모델은 복잡한 DSL 문법 (A1) 을 작성하는 것보다 제한된 JSON 스키마를 채우는 것조차 어려워하는 병목 현상이 발생했습니다.

3.4 기타 발견 사항

• 정확한 문자열 일치 (Exact Match) 의 한계: 생성된 쿼리 문자열이 정답과 달라도 실행 결과는 동일한 경우가 많았습니다. 따라서 결과 기반 평가 (Result-based evaluation) 가 문자열 일치 평가보다 실제 유용성을 더 잘 반영합니다.
• 태스크 난이도: 데이터 흐름 (Data Flow) 및 복합 태스크는 에이전트 방식 (A3) 에서 특히 취약했으며, 소형 모델은 구조적 태스크 외에는 거의 해결하지 못했습니다.

4. 주요 기여 (Contributions)

1. 새로운 벤치마크: 자연어에서 CPGQL 로 변환하는 20 개의 태스크로 구성된 공개 벤치마크를 구축했습니다.
2. 통제된 비교 실험: LLM 관여 정도 (직접 생성, 구조화 중간 표현, 에이전트) 를 체계적으로 비교한 최초의 연구 중 하나입니다.
3. 실증적 증거: 형식적으로 구조화된 도메인 (DSL 생성) 에서는 LLM 의 출력을 구조화된 중간 표현으로 제한하고, 쿼리 생성을 결정론적 코드에 위임하는 것이 가장 효과적임을 증명했습니다.
4. 모델 크기 상호작용 발견: 구조화된 중간 표현의 이점은 대형 모델에서 두드러지지만, 소형 모델은 스키마 준수 능력에 의해 제한받음을 밝혔습니다.

5. 의의 및 결론 (Significance & Conclusion)

이 논문은 정적 분석과 같은 형식적 구조가 명확한 도메인에서 LLM 을 사용할 때, "LLM 에게 모든 것을 맡기기보다는 LLM 이 잘하는 부분 (자연어 이해, 분류) 만 맡기고, 나머지 (문법 생성, 실행) 는 결정론적 코드가 처리하는" 아키텍처가 최선임을 시사합니다.

• Less is More: LLM 의 관여를 줄이고 출력 공간을 제한할수록 정확도가 높아집니다.
• 실무적 시사점: 도구 개발자는 LLM 을 직접 코드 생성기로 사용하기보다, 스키마 기반의 중간 표현을 생성하는 분류기로 활용하고, 이를 파서로 변환하는 파이프라인을 구축해야 합니다.
• 에이전트 방식의 한계: 복잡한 도구 호출 루프는 오류를 누적시키고 비용을 증가시킬 뿐, 구조화된 도메인에서는 추가적인 이점을 제공하지 못합니다.

결론적으로, LLM 의 능력을 최대한 활용하면서도 정적 분석의 정확성을 보장하기 위해서는 LLM 의 자율성을 엄격하게 통제하는 구조화된 접근법이 필수적입니다.