비동기와 트레이싱 — 무엇이 느리고 무엇이 비싼지 어떻게 아나

30초 걸리는 RAG 응답에서 검색이 1초, LLM 생성이 28.7초를 쓰고 있다면 벡터 DB 튜닝은 전체의 3.6%를 건드리는 일이다. 그런데 관측 없이 감으로 최적화하면 이 판단을 정확히 거꾸로 하기 쉽다. 눈에 보이는 것이 검색 쪽 코드이기 때문이다.

이 글은 그 판단을 데이터로 바꾸는 방법을 다룬다. 비동기가 실제로 무엇을 줄이는지(그리고 무엇을 줄이지 않는지), 트레이싱으로 어느 단계가 병목인지 가르는 법, 그리고 API 키와 예산 상한으로 비용 사고를 막는 구조까지 이어진다. 토큰 비용 구조에서 정리한 절감 레버들의 전제가 되는 측정 계층이다.

용어 정리

비동기 — 무엇을 줄이고 무엇을 줄이지 않나

비동기 메소드는 특정 작업이 완료될 때까지 프로그램 전체를 멈추지 않고 다른 작업을 계속 수행할 수 있게 한다.

문서 5개를 각각 LLM으로 요약하는 작업(1건당 2초)을 가정하면 차이가 분명해진다.

핵심은 LLM 호출이 CPU 작업이 아니라 네트워크 I/O 대기라는 점이다. 대기 시간에는 CPU가 놀고 있으므로, 그 시간에 다른 요청을 보내면 총 소요시간이 순차 합계가 아니라 가장 느린 하나 수준으로 수렴한다.

LangChain의 동기·비동기 대응

import asyncio

# 동기 — 순차 처리
results = [chain.invoke(q) for q in questions]

# 비동기 — 병렬 처리
async def run_all(questions):
    return await asyncio.gather(*[chain.ainvoke(q) for q in questions])

results = asyncio.run(run_all(questions))

# batch — 동시 실행 수를 제어하며 병렬 처리
results = chain.batch(questions, config={"max_concurrency": 5})

batch는 동기 함수지만 내부적으로 병렬 실행한다. max_concurrency로 동시 호출 수를 제한할 수 있어, 레이트 리밋이 있는 API에는 asyncio.gather보다 batch 쪽이 안전한 경우가 많다.

효과가 있는 곳과 없는 곳

"비동기를 썼더니 빨라졌다"는 서술은 반쪽이다. 정확히는 I/O 대기가 지배적인 구간을 병렬화해 처리량(throughput)을 높인 것이다.

단일 요청의 지연(latency)은 비동기로 줄지 않는다. 이 둘을 구분하지 못하면 CPU 바운드 구간에 async를 붙여 놓고 왜 안 빨라지는지 묻게 된다.

트레이싱 — 무엇이 병목인지 가르는 도구

트레이싱은 실행의 단계별 입출력·소요시간·토큰을 기록한다. 이것이 답을 주는 문제들은 다음과 같다.

셋째 행이 중요한 이유는 합계만 보면 병목이 어디인지 알 수 없다는 데 있다. 단계별로 갈라 보기 전에 손을 대면 엉뚱한 곳을 고치게 되는데, 메시지 브로커에서 밀린 양이 늘 때 소비자부터 늘리면 오히려 나빠지는 진단 순서 문제도 같은 형태다.

관측은 두 계층으로 나뉜다.

프로젝트 계층 — 무엇이 비싼가

예시 대시보드를 읽어 보면 각 컬럼이 어떤 신호가 되는지 드러난다.

llama3-agent 행이 전형적인 이상 신호다. 에러율 12%에 P50이 18.39초 — 에이전트가 루핑하거나 로컬 모델이 느린 패턴이다. Total Cost가 비어 있는 것은 로컬 모델이라 API 과금이 없다는 뜻으로 읽는다. 비용이 0이라고 해서 공짜가 아니라, 비용이 다른 장부(GPU·전력)로 옮겨 갔을 뿐이다.

Run 계층 — 어디가 느린가

1개 실행을 열면 검색된 문서뿐 아니라 LLM의 입출력 원문까지 기록된다. 그래서 검색 알고리즘을 바꿔야 할지 프롬프트를 바꿔야 할지 판단할 수 있다.

전형적인 트레이스 워터폴이다.

이 트레이스가 말하는 것: 30초 응답의 95.6%가 LLM 생성이고 검색은 1.08초에 불과하다.

이 상태에서 벡터 DB를 튜닝하거나 인덱스를 바꾸는 것은 최대 3.6%를 건드리는 일이다. 개선해야 할 것은 모델 교체 · 출력 길이 축소 · 스트리밍 도입이다.

이것이 "기능보다 관측을 먼저 깐다"는 원칙의 근거다. 측정이 없으면 가장 눈에 띄는 코드를 고치게 되고, 그것이 병목일 확률은 낮다.

설정

from dotenv import load_dotenv

load_dotenv()

관측 도구에도 반출 기준을 똑같이 적용해야 한다. 트레이싱은 프롬프트와 검색 문서 원문을 외부 SaaS로 전송한다.

로컬 LLM을 도입하는 이유가 데이터 반출 통제인 조직이라면, 관측 도구만 예외로 두는 것은 논리가 맞지 않는다. 민감 데이터를 다루면 마스킹 정책을 걸거나 셀프호스팅 옵션을 검토하고, 그것이 어렵다면 개발·스테이징에만 붙이고 프로덕션은 자체 지표로 가져간다.

예산 상한 — 비용 사고를 구조로 막는다

관측이 "얼마나 썼는지"를 알려준다면, 예산 상한은 "얼마까지만 쓰게" 만든다. 둘은 같은 문제의 앞뒤다.

두 값을 어떻게 잡느냐가 설계다. 프로덕션에서 monthly budget을 실제 예상치에 딱 맞게 잡으면 트래픽이 튀는 날 서비스가 통째로 멈춘다. 반대로 너무 넉넉히 잡으면 안전장치 역할을 못 한다.

실무 절충은 예상치의 1.5~2배를 budget으로, 예상치의 1배 지점을 email threshold로 두는 것이다.

조직 단위 키 관리

키를 서버에 가두는 구조는 보안만의 문제가 아니다.

프록시 지점이 있어야 사용자별 쿼터·캐싱·모델 라우팅·감사 로그를 걸 수 있다. 토큰 비용 절감 레버 대부분이 이 지점에서만 구현 가능하다.

키가 유출되면 타인이 그 키로 호출한 비용이 발급자에게 청구된다. API 키는 편의를 위한 식별자가 아니라 결제 수단에 직결된 자격증명으로 취급해야 한다.

비용·관측·모듈화·거버넌스에서 반복해 부딪히는 판단은 RAG 운영 Q&A에 문답으로 모았다.