Python 정수 변환 제한부터 LLM 응답 오류까지, 9가지 버그 해결기
by DD
1일 전
조회수 0
CPython 3.11+의 4300자리 정수→문자열 변환 제한으로 인해 24번째 메르센 소수(Mersenne Prime) 계산 시 ValueError 발생
Go 에이전트의 불필요한 문자열 변환 및 포맷팅 제거로 N=24 행에서 측정 시간 획기적 단축
LLM 응답의 구조화된 데이터(Structured Data) 우선 처리 및 4자리수 타이밍 출력으로 데이터 정확성 확보
에이전트가 실제 계산한 소수 개수와 요청 개수를 일치시켜 데이터 정합성(Data Integrity) 강화
파이프라인 아키텍처(Pipeline Architecture) 차이로 인한 왕복 시간(RTT) 격차 해소
CPython의 정수→문자열 변환 제한과 해결 방안
CPython 3.11 버전부터 기본적으로 정수→문자열 변환 시 최대 4300자리로 제한되어, 이를 초과하는 메르센 소수(Mersenne Prime) 계산 시 ValueError가 발생함. 이는 잠재적인 서비스 거부(Denial of Service) 공격을 방지하기 위한 조치임.
문제점: 2^19937−1 (6002자리)과 같이 큰 정수를 문자열로 변환하려 할 때 오류 발생
해결책: `sys.set_int_max_str_digits()` 함수를 사용하여 최대 변환 자리수 늘리기 또는 불필요한 문자열 변환 로직 제거
본 사례에서는 해당 문자열이 실제 사용되지 않았으므로, `str()` 함수 호출 자체를 제거하는 것이 가장 효율적인 해결책이었음. 이는 타이밍 측정 로직에서 불필요한 포맷팅 작업 제거 효과도 가져옴.
벤치마크 타이밍 측정의 함정과 개선
벤치마크에서 시간 측정 방식의 오류는 결과의 신뢰성을 심각하게 저해함. 본 사례에서는 두 가지 주요 문제가 발견됨.
벽시계 시간(Wall Clock Time) 사용: `time.time()`은 비단조적(Non-monotonic)이므로, 시스템 시간 변경 시 부정확한 측정값을 반환할 수 있음. 해결책으로 시간 경과 측정에 더 적합한 `time.perf_counter()`로 변경함.
LLM 응답의 구조화되지 않은 데이터 의존: Node.js와 Rust 에이전트의 경우, `elapsed.toFixed(2)`로 인해 마이크로초(µs) 단위 이하의 짧은 실행 시간이 0.00ms으로 처리되어 로그 스케일 차트에서 누락되는 문제가 발생함. 해결책으로 구조화된 아티팩트(Structured Artifact)를 우선하고, LLM의 자연어 응답은 보조 수단으로 활용하며, 4자리수 타이밍 출력으로 정밀도 향상함.
에이전트의 계산 결과 불일치 문제와 해결
Node.js 및 Rust 에이전트가 실제 계산한 메르센 소수(Mersenne Prime) 개수와 관계없이, 요청된 개수(예: 100개)를 그대로 응답하는 데이터 불일치(Data Inconsistency) 문제가 발견됨.
문제점: 실제로는 26개의 소수만 계산했음에도 불구하고, 100개를 찾았다고 보고하여 결과 검증의 신뢰도 하락
해결책: 에이전트가 반환하는 결과에서 계산된 소수 목록의 실제 길이(`primes.length` 또는 `primes.len()`)를 보고하도록 수정함. 이를 통해 실제 계산 결과를 정확하게 반영하도록 함.
이러한 문제는 자동화된 시스템(Automated System)이 LLM의 응답을 처리할 때 특히 중요하며, 항상 구조화된 데이터(Structured Data)를 우선시해야 함을 시사함.
파이프라인 아키텍처(Pipeline Architecture)에 따른 성능 격차 분석
벤치마크 결과에서 Rust(2.6ms), Node.js(4.6ms) 대비 Go(~1.6초), Python(~1.8초)의 왕복 시간(Round-Trip Time, RTT)이 약 400배 차이 나는 현상은 언어 자체의 성능 차이가 아닌, 통신 파이프라인 아키텍처(Communication Pipeline Architecture)의 차이에서 기인함.
Gemini 에이전트 경로: Python과 Go는 Gemini 도구 호출(Tool Calling)을 거치므로 LLM 및 도구 호출 오버헤드(Overhead)가 포함됨.
직접 처리 경로: Node.js와 Rust는 메시지에서 직접 숫자를 추출하여 계산하므로 오버헤드가 적음.
해결책: 차트에서 에이전트를 파이프라인 유형(Pipeline Type)별로 태그하고, Gemini LLM 경유 여부를 명확히 구분하여 비교하도록 수정함. 이를 통해 실제 성능 병목 지점(Performance Bottleneck)을 정확히 파악할 수 있게 됨.
Go 언어의 시간 측정 및 파싱 오류
코드 최적화 후 Go 에이전트의 실행 시간이 마이크로초(µs) 미만으로 떨어지면서, `time.Duration`이 반환하는 나노초(ns) 단위의 접미사(Suffix)를 파서가 인식하지 못하는 문제가 발생함.
문제점: `836ns`와 같은 결과가 파싱되지 않아 해당 데이터 포인트가 N/A 처리됨.
해결책: 새로운 파서(Parser) 로직을 추가하여 나노초 단위의 접미사도 올바르게 처리하도록 수정함.
이처럼 미세한 성능 개선(Micro-optimization)이 예상치 못한 파싱 오류를 유발할 수 있으므로, 다양한 실행 시간 범위에 대한 테스트 커버리지(Test Coverage) 확보가 중요함.
LLM의 반복 응답 및 세션 기록 문제
Gemini API의 컨텍스트 ID 재사용 문제로 인해, 동일한 컨텍스트 ID로 요청 시 모델이 이전 대화 기록을 기억하고 도구 호출(Tool Calling)을 건너뛰는 현상이 발생함.
문제점: 고정된 `contextId`를 재사용하면 모델이 '이미 수행했다'고 응답하며 실제 계산을 수행하지 않아, 데이터 포인트가 누락됨 (3개 발생).
해결책: 독립적인 요청마다 고유한 `contextId`를 할당하여 모델이 매번 새로운 요청으로 인식하도록 함.
이는 상태 비저장(Stateless) 요청 처리의 중요성을 강조하며, 특히 자동화된 시스템에서 LLM을 사용할 때 세션 기록(Session History) 관리가 결과에 미치는 영향을 보여줌.
