LLM의 토큰 사용량, 응답 시간을 어떻게든 줄여보고 싶다!!

요즘 OSSCA(오픈소스 아카데미)에서 ESLint 오픈소스 참여 과정을 진행하고 있다.

eww

ESLint 동작 원리를 하나씩 진행하다 보니 자연스럽게 정적 분석을 이해하게 됐는데, 여기서 쓰이는 ESTree(AST) 구조가 생각보다 너무 흥미로웠다. 파일 내 태그와 코드를 노드(Node) 단위로 쪼개서 정밀하게 분석하는 걸 보면서, 문득 머릿속에 질문 하나가 떠올랐다.

"ESLint가 코드를 노드 단위로 핀포인팅해서 분석하는 것처럼, RAG 전처리할 때도 웹 문서를 AST 노드로 정제해서 넘겨주면 토큰과 속도를 비약적으로 아낄 수 있지 않을까?"

문제 인식 : 기존 Chunk RAG의 지독한 토큰 낭비

보통 RAG라고 하면 웹 사이트나 문서 전체를 적당한 길이(500자~1000자)의 Chunk 단위로 뚝뚝 자른 뒤, 이걸 임베딩해서 Vector DB에 넣고 검색하는 방식을 떠올린다. 물론 이렇게 하면 구현도 쉽고 텍스트 검색도 빠르다.

 

하지만 쓸 때마다 늘 아쉬웠던 점이 있었다. 필요 없는 쓰레기 정보(노이즈)까지 너무 많이 읽는다는 것. 그리고 내 소중한 토큰을 낭비한다.

 

HTML을 그냥 글자 수대로 자르다 보니, 헤더 메인 메뉴, 푸터, 레이아웃 CSS, 관련 글 추천, 심지어 본문 옆의 잡다한 부연 설명까지 전부 Chunk에 섞여 들어간다. 결국 전처리 단계에서 노이즈를 전혀 걸러내지 못하는 셈이다.

 

안 그래도 귀한 LLM 입력 토큰(Input Token)을 이런 무의미한 노이즈로 채운다는 게 솔직히 너무 아까웠다.

토큰만 많이 먹는 게 아니라, LLM이 읽어야 할 분량이 늘어나니 첫 토큰이 나올 때까지 대기 시간(TTFT)도 길어지고, 문맥이 오염되어서 환각(Hallucination)이 생길 확률도 높아진다.

"ESLint처럼 파싱해 보면 어떨까?" (AST RAG 아이디어)

ESLint는 자바스크립트 코드를 읽을 때 문자열을 통으로 보지 않는다. ESTree라는 추상 구문 트리(AST)로 변환한 뒤, 우리가 찾고자 하는 특정 노드(FunctionDeclaration, Identifier 등)만 집중해서 규칙을 검사한다.

웹 문서나 라이브러리 API 문서를 RAG에 넣을 때도 똑같이 할 수 있지 않을까?

1. HTML/문서를 AST / DOM 트리 구조로 파싱한다.
2. 핵심 정보가 들어있는 Semantic Anchor 노드만 추적한다.
   • (예: <code>, <pre>, 메서드 시그니처, 핵심 파라미터 타입 등)
3. 나머지 무의미한 노드(메뉴, 푸터, 광고, 쓸데없는 부연 설명)는 트리 단에서 통째로 가지치기(Pruning)한다.
4. 남은 핵심 노드만 아주 짧고 명확한 Compact Markdown(150토큰 내외)으로 직렬화해서 LLM에 건넨다.

Chunk RAG처럼 글자 수대로 뭉텅이 잘라 넣는 게 아니라, ESLint가 AST 노드를 짚어내듯 정확히 필요한 시그니처 노드만 핀포인팅해서 정제해 주는 방식이다.

Chunk RAG vs AST RAG 간단 비교

구분	기존 Chunk RAG	AST 기반 RAG (아이디어)
자르는 기준	단순 글자 수 / 단락 단위	의미 있는 구문 노드(Node) 단위
노이즈 제어	불필요한 메타데이터/태그 다 섞임	트리 단계에서 불필요 노드 가지치기
주입 토큰량	보통 4,000 ~ 5,000 토큰	~150 토큰 (핵심 정보만 소량 주입)
정확도	확률적 유사도 (잘린 텍스트에 의한 문맥 손실)	결정론적 구문 노드 추출 (환각 0% 지향)

정리하며

OSSCA에서 ESLint의 정적 분석 원리를 배우지 않았다면 그냥 "RAG 쓰면 원래 토큰 많이 먹고 느린가 보다" 하고 넘어갔을지도 모른다.

하지만 코드의 의미 단위(AST Node)를 분석하는 정적 분석 방식을 RAG의 파싱 전처리 과정에 이식한다면, 토큰 비용 감축(90%+)+응답 속도 개선+환각 차단이라는 세 마리 토끼를 한 번에 잡을 수 있지 않을까 싶다.

 

다음 단계로는 실제 Java 21이나 TypeScript 공식 API 문서를 대상으로, 이 AST 노드 정제 파이프라인(PoC)을 직접 코드로 구현해 보고 기존 Chunk RAG 대비 토큰이 얼마나 줄어드는지 벤치마크를 측정해 볼 예정이다.