LLM Latency PoC

[hyunbin1]

현재 당면한 문제

• 멀티 에이전트 중 분석에 해당하는 Analytics 에이전트의 Latency가 43초 이상으로 발생한다.
• 이에 대한 원인으로는 CSV 분석을 시행할 시 확률론적인 LLM의 출력을 결정론적인 결과로 변환하는 과정에서 자가 수정(Self-Correction) 루프가 반복적으로 수행되는 문제일 가능성이 매우 높다고 판단하여, 이를 가설로 정의한다.

Analytics LLM의 역할과 책임:

• Analytics LLM은 사용자의 의도를 제공받았을 때 데이터를 분석하고, 해석하는 역할을 한다.
• LLM의 특성은 방대한 데이터를 해석하는데 강점을 두고 있다. 따라서 SNS의 방대한 데이터 + 이전의 분석 성공 시나리오 데이터를 각각의 "해석"을 기반으로 종합적이고 정확한 "판단"을 주요 책임으로 둔다.

---

병목이 발생된 원인에 대한 가능성 제시

1. 직렬적 생성-실행-수정 루프의 반복

• LLM이 코드를 생성하고, 실행 환경에서 에러를 확인한 뒤, 다시 프롬프트를 구성해 모델에게 넘기는 한 번의 사이클은 많은 시간을 소모한다.
• 토큰 생성 속도의 물리적 한계: LLM은 결과물에 대한 출력을 순차적으로 생성하므로, 파이썬 코드를 작성하는 것 자체가 물리적인 시간 비용이 발생한다. 특히 AI 산업에서 모든 기업이 가장 병목이라고 생각하는 비용은 연산 추론시간이 아니라 I/O 부분이라는 점을 고려했을 때, 이는 어떻게 프로젝트에 적용할지 고려해 볼만한 고민점이다.
• API 지연 시간의 누적: 외부 API를 사용할 경우, 1회 호출당 발생하는 네트워크 및 추론 대기 시간이 루프 횟수만큼 배수로 늘어난다. 이 루프가 내부적으로 3~4번만 반복되어도 40초를 가볍게 넘긴다. 네트워크 관련된 비용도 측정 후 단축할 수 있는 방법을 확인해야 한다.

2. 데이터 주입에 따른 프롬프트 처리 지연

• 분석 에이전트가 CSV의 로우 데이터를 프롬프트에 직접 포함하고 있다면 입력 토큰 수가 급격히 증가하고, 모델이 이를 읽고 첫 번째 토큰을 뱉어내기까지 걸리는 시간(Time to First Token) 또한 급격히 증가한다. 컨텍스트가 길어질수록 모델이 데이터의 엉뚱한 부분을 참조하거나 코드 문법을 틀릴 확률이 높아져, 결과적으로 1번에서 언급한 수정 루프를 더 많이 유발하는 악순환이 생긴다.

3. 확률론적 모델에게 결정론적 문법을 강제하는 비효율

• LLM은 본질적으로 확률에 기반해 작동한다. 반면 파이썬 코드는 공백 하나, 오타 하나로도 실행이 불가능한 결정론적 영역이다. 따라서 확률론적 모델이 엄격한 문법 컴파일을 통과하기 위해 백트래킹을 반복하는 구조 자체가 병목으로 고착화될 수 있다.

---

해결하기 위한 방법론

1. 결정론적 코드 수행 영역의 완전한 분리

• LLM이 프롬프트 내부에서 직접 데이터를 분석하거나 유추하게 하지 않고, 데이터 분석을 위한 완성된 파이썬 스크립트만 1회성으로 생성하도록 역할을 제한하는 방식이 제안될 수 있다. 즉, LLM은 '코드 작성'만 수행하고, 실제 연산과 데이터 처리는 격리된 파이썬 런타임 환경에서 결정론적으로 처리하여 루프 횟수를 최소화하는 것이다. Python은 데이터 분석에 강점을 가지고 있기 때문에, 분석은 결정론적인 Python에서 진행하고, 이에 대한 결과와 이전의 분석 성공 시나리오 데이터만을 결합하여 해석과 판단을 요청하는 방법이 된다.

2. 구조화된 출력 및 문법 제어 (Grammar-Constrained Decoding) -> 이부분은 이미 완료된 사항이다. 실제로 완료됐는지 검토만 진행하면 된다.

• LLM이 자유 형식의 텍스트나 코드를 출력하는 것이 아니라, 데이터 분석에 필요한 특정 API 호출 형태나 정의된 스키마(JSON Schema 등)에 맞추어 답변하도록 토큰 생성 단계에서 제어하는 기술이다. 텍스트 파싱 오류나 포맷 불일치로 인해 발생하는 회귀 및 재시도 루프를 원천적으로 차단할 수 있다.

3. 추측성 실행 및 병렬화 (Speculative Execution & Parallel Branching)

• 단일 경로로 코드를 실행하고 에러가 나면 수정하는 순차적 방식 대신, 처음부터 데이터 분석을 위한 몇 가지 유망한 접근 경로(예: 데이터 필터링 방식 A, B, C)를 병렬로 생성하여 동시에 검증하는 방식이다. 단일 경로의 실패로 인한 대기 시간을 제거하고, 병렬로 성공한 결과 중 최적의 분석본을 선택하여 시간을 단축한다.
• 단일 경로로 코드를 실행하고 에러 발생 시 수정하는 순차적 방식 대신, 데이터 분석을 위한 복수의 유망한 접근 경로를 동시에 생성하여 검증한다. 단일 경로 실패로 인한 대기 시간을 제거하고, 병렬로 성공한 결과 중 최적의 분석본을 선택하여 시간을 단축한다.
  • 단축 원리: LLM의 텍스트 출력 속도와 외부 서버 통신 대기 시간은 지연의 주요 원인이다. 추측성 병렬 실행은 컴퓨팅의 멀티프로세싱 개념을 도입하여 시행착오를 동시에 처리하므로, 실패한 경로의 소모 시간이 성공한 경로의 시간 뒤에 숨겨져 사용자가 체감하는 대기 시간이 단축된다.
  • 기존 방식 (순차적 자기 수정): 코드 A 작성(5초) $\rightarrow$ 실행 및 에러(2초) $\rightarrow$ 코드 B 수정(5초) $\rightarrow$ 실행 및 에러(2초) $\rightarrow$ 코드 C 수정(5초) $\rightarrow$ 실행 성공(2초) 과정으로 총 21초가 소요되며, 오류가 증가할수록 지연 시간이 선형적으로 늘어난다.
  • 추측성 실행 및 병렬화 방식: 정답 확률이 높은 코드 A, B, C를 동시에 생성하고, 격리된 샌드박스 환경 3곳에서 동시에 실행한다. 일부 경로에서 에러가 발생하더라도 단번에 성공한 경로의 결과만을 채택하여 다음 단계로 이동한다. 전체 소요 시간은 1회 실행 시간인 약 7초 내외로 단축된다.

4. 데이터 메타데이터화 및 컨텍스트 경량화

• CSV 파일의 전체 내용을 에이전트에 입력하는 방식은 토큰 처리 비용과 모델의 연산 시간을 크게 증가시킨다. 데이터의 스키마, 컬럼별 요약 통계량(데이터 타입, 결측치 비율, 고유값 샘플 등)만 담은 메타데이터(Data Profile)를 먼저 생성하여 에이전트에 제공하면, 입력 토큰 수가 줄어들어 추론 속도가 빨라지며 데이터 오인으로 인한 에러 발생률도 낮아진다.

---

PoC 진행 방향

ㅋ정확도를 유지하면서 지연 시간을 줄이기 위해 단계 별로 병목을 격리하여 가설을 검증하는 PoC 단계를 진행한다.

• 1단계: 로그 및 상태 추적 메커니즘 구축 (Baseline 측정)
  에이전트 내부에서 발생하는 LLM 호출 횟수, 생성된 코드, 파이썬 실행 에러 내용, 각 턴(Turn)별 소요 시간을 기록한다. 43초 중 자가 수정 루프가 몇 번 돌았고, 실제 연산에 얼마가 쓰였는지 정량화한다. 이는 명확하게 CSV 데이터를 분석하는 과정에서 발생된 문제인지 혹은 네트워크에 관련된 부분이 문제인지를 모니터링을 우선적으로 적용하여 식별해야 한다.

• 2단계: 데이터 프로파일러 도입 테스트 (방법론 中 1, 4번 적용)
  전체 CSV 대신 df.info(), df.describe() 형태의 텍스트 요약본만 분석 에이전트에 입력값으로 전달하는 실험을 진행한다. 이를 통해 컨텍스트 크기 축소가 정확도와 지연 시간에 미치는 영향을 확인한다.

• 3단계: 코드 생성 전용 소형 모델(SLM) 라우팅 테스트 (그저 이런 방법론이 있다는 것을 제안하는 것이며, 실제로는 2단계에서의 결과물을 보고 또 다른 Trade Off 를 진행하게 될 것 같다.)
  분석 에이전트 전체를 무거운 범용 모델로 사용하는 대신, 코드 생성에 특화되고 속도가 빠른 오픈소스 소형 모델이나 특정 태스크 전용 API로 교체하여 정확도 유지 여부와 프롬프트 실행 속도를 파악한다.