DeepSeek V4 Pro, MiMo V2.5 Pro, DeepSeek V4 Flash, MiMo V2.5, GLM 5.2, 그리고 Kimi K2.6을 실제 운영 환경의 버그를 대상으로 종합 비교한 결과 — 각 솔루션의 아키텍처 분석 포함

요약 (TL;DR)

모델	소요 시간	비용	캐시 히트율 (Cache Hit)	발견된 버그	V2 접근 방식	V2 = 참조 모델?
DeepSeek V4 Flash	~7분	$0.040	93.3%	1 (고유함)	아키텍처 기반 (Architectural)	✅ 예
...
주요 결과:

• 가장 저렴함: DeepSeek V4 Flash ($0.04) — 다른 어떤 모델도 잡아내지 못한 고유한 버그를 발견함
• 최고의 디버거: MiMo V2.5 Pro (다른 모델들이 1개를 찾을 때 3개의 버그 발견)
• 모든 모델이 2라운드에서 예방(prevention) 방식으로 수렴함 — 하지만 서로 다른 아키텍처를 통해 달성함
• 1라운드에서 격차 확인: 모든 모델이 기본적으로 정리(cleanup) 사고방식을 취함; 예방을 위해서는 가이드가 필요함

왜 이 벤치마크인가?

대부분의 LLM 벤치마크는 코딩 능력, 즉 함수 작성이나 퍼즐 풀기를 테스트합니다. 하지만 디버깅은 코드를 작성하는 것보다 더 어렵습니다. 다음과 같은 능력이 필요하기 때문입니다:

1. 복잡하고 여러 파일로 구성된 코드베이스(codebases)를 이해할 것
2. 명확하지 않은 근본 원인(root causes)을 찾아낼 것
3. 메커니즘을 명확하게 설명할 것
4. 적절한 아키텍처를 갖춘 올바른 수정안을 제안할 것

우리는 httpx에서 사용되는 프로덕션 라이브러리인 httpcore의 실제 Race Condition(경쟁 상태) 버그를 대상으로 이를 테스트했습니다.

버그: httpcore #961

저장소: encode/httpcore
이슈: #961 - 비동기 취소 후 Race Condition으로 인한 커넥션 풀(Connection Pool) 파손
수정 PR: #880 - 안전한 비동기 취소 (Safe async cancellations)

연결 작업 중에 비동기 작업(async tasks)이 취소되면, 풀(pool)의 내부 상태가 불일치하게 됩니다. 풀은 연결이 실제로 취소되었음에도 불구하고 여전히 사용 중이라고 판단하게 되며, 이는 **풀 고갈(pool exhaustion)**로 이어집니다 — 즉, 새로운 요청이 결코 연결을 획득할 수 없게 됩니다.

어려운 이유:

• 다중 파일 (Multi-file): connection_pool.py, connection.py, http2.py
• 비동기 특화 (Async-specific): asyncio/trio 취소(cancellation) 시에만 나타남
• 비명확성 (Non-obvious): 로그에는 정상 작동으로 표시됨
• 실무 사례 (Real-world): 실제 사용자에게 영향을 미치는 운영 환경(production) 문제

방법론 (Methodology)

각 모델은 수정 사항이 적용되기 전의 httpcore 프로젝트 전체를 전달받았습니다. 두 라운드로 진행되었습니다:

라운드 1: 버그를 찾고, 메커니즘을 설명하며, 수정 방안을 제안합니다.

라운드 2: 모든 모델에 동일한 프롬프트 제공 — 패치(patch) 수준을 넘어 예방(prevention) 단계로 유도하기 위해 "원자적 상태 관리 (atomic state management)"에 대한 힌트를 제공합니다.

라운드 1: 버그 찾기

모든 모델이 핵심 문제인 '비동기 태스크가 취소될 때 발생하는 고아 연결 (orphaned connections)'을 찾아냈습니다. 하지만 발견한 내용, 제안한 수정 방안, 그리고 분석의 깊이는 모델마다 달랐습니다.

DeepSeek V4 Pro

시간: 약 3분 | 비용: 총 $0.14의 일부

발견 내용: 1개의 레이스 컨디션 (race condition) — 할당 후 태스크가 취소될 때 발생하는 고아 연결.

설명된 메커니즘: 코드를 포함한 5단계 단계별 설명. _attempt_to_acquire_connection 내의 FIFO 가드(guard)와 고아 상태가 왜 큐(queue)를 차단하는지를 정확히 식별함.

놓친 부분: RC2 (ConnectionNotAvailable 재시도 누수), RC3 (aclose 중 연결 누수), 초기 락(lock) 블록 내부의 취소.

제안된 수정안:

except BaseException as exc:
    async with self._pool_lock:
        if status in self._requests:
...

아키텍처: 반응형 정리 (Reactive cleanup) — 고아를 감지하고, 이를 해제한 뒤, 다음 대기자에게 재할당함.

장점 (Pros):

• ✅ 주요 레이스 컨디션(race condition)을 처리함
• ✅ 해제된 연결을 재할당하려고 시도함
• ✅ 기존 코드에 대한 변경이 최소화됨

단점 (Cons):

• ❌ 락(lock) 내부에서 await self._attempt_to_acquire_connection(s) 호출 — 새로운 취소 구간(cancellation window)을 생성함
• ❌ RC1만 처리함. RC2와 RC3를 놓침
• ❌ 근본 원인을 해결하지 못함 — 상태(state)와 I/O가 여전히 뒤섞여 있음

판결 (Verdict): 분석은 훌륭하나 수정안은 불완전함. 일반적인 케이스에는 작동하지만 새로운 레이스 구간을 도입함. 치료제가 부분적으로 병을 만들어내는 격임.

MiMo V2.5 Pro

소요 시간: ~9분 | 비용: 총 $0.13 중 일부

발견 사항: 3가지의 뚜렷한 레이스 컨디션 (Race Condition) (다른 모델은 1개 이상을 발견하지 못함):

1. RC1: 초기 풀 잠금(pool lock) 중 상태 누수 (Status leak) — async with pool_lock 내부의 _close_expired_connections() 또는 _attempt_to_acquire_connection() 도중 취소(cancellation)가 발생하면 self._requests 내의 상태가 남게 됨.

2. RC2: ConnectionNotAvailable 재시도 중 상태 누수 (Status leak) — Python 예외 의미론 (Exception semantics): except 블록 내부의 예외는 형제(sibling) except 핸들러를 우회함. 재시도 중 발생하는 CancelledError는 while True 루프를 완전히 종료시킴.

3. RC3: 정리(cleanup) 중 연결 누수 (Connection leak) — await connection.aclose() 이후 self._pool.pop(idx)가 실행됨. 만약 aclose() 도중 취소되면 pop()이 실행되지 않음.

핵심 통찰 (Key insight): 기존 테스트가 왜 이를 잡아내지 못하는지 설명함 — 기존 테스트는 단일 요청 시나리오를 사용함. 또한 Python 예외 의미론(형제 except 블록은 서로의 예외를 잡지 못함)을 식별함.

제안된 수정안 (Proposed fix):

# Part 1: 최상위 안전망 (Top-level safety net)
try:
    while True:
...

아키텍처: 심층 방어 (Defense in depth) — 다층 보호 구조.

장점 (Pros):

• ✅ 세 가지 레이스 컨디션을 모두 잡아냄 — 1라운드에서 이를 수행한 유일한 모델
• ✅ 방어적 스윕 (Defensive sweep)이 멱등성 (Idempotent)을 가짐
• ✅ 최상위 핸들러가 초기 잠금 블록으로부터의 취소를 잡아냄
• ✅ 기존 코드 구조를 크게 변경하지 않음

단점 (Cons):

• ❌ 여전히 사후 대응적 (Reactive)임 — 연결이 고아(orphaned)가 된 후 정리됨
• ❌ _close_expired_connections()가 여전히 잠금 내부에서 비동기(async)로 작동함 — 스윕 도중 RC3가 여전히 발생 가능함
• ❌ 더 단순한 접근 방식보다 코드 양이 많음

판결 (Verdict): 최고의 1라운드 수정안. 3개의 버그를 모두 찾았고, 3개 모두에 대한 방어책을 제안함. 하지만 여전히 예방이 아닌 패치(patch) 수준임.

DeepSeek V4 Flash

소요 시간: ~3분 | 비용: 총 $0.040 중 일부

발견 사항: 다른 어떤 모델도 잡아내지 못한 독특한 버그 (Unique bug):

# 파일: httpcore/_async/connection.py, 97행
# 버그: except Exception은 CancelledError를 잡지 못함
# Python 3.8+에서 CancelledError는 BaseException임
...

중요한 이유: 이것은 풀(pool) 수준의 레이스 컨디션 (Race Condition)과는 별개의 버그입니다. 풀에 대한 완벽한 수정이 이루어지더라도, 연결(connection) 수준의 핸들러는 CancelledError를 놓치게 됩니다. 하나의 코드베이스에 두 개의 버그가 존재하는 셈입니다.

제안된 수정안: 1줄 — Exception → BaseException.

아키텍처: 적절한 추상화 수준에서의 최소한의 수정.

장점:

• ✅ 정확하고 최소한임 — 1줄이며, 부작용(side effects)이 없음
• ✅ 서로 다른 추상화 수준 — 다른 모델들이 풀(pool) 로직을 살펴볼 때, Flash는 연결(connection) 처리를 살펴봄
• ✅ 풀(pool)에 대한 완벽한 수정이 있어도 지속되는 버그를 포착함
• ✅ 리스크 제로 — 이전 동작의 엄격한 상위 집합(superset)
• ✅ 새로운 코드 없음 — 단지 더 넓은 범위의 catch 절을 사용함

단점:

• ❌ 풀(pool) 수준의 레이스 컨디션을 해결하지 못함 — 이것은 다른 버그임
• ❌ 풀(pool) 메커니즘을 설명하지 않음 — 연결(connection) 수준에 집중함
• ❌ 불완전해 보일 수 있음 — '그' 버그가 아닌 다른 버그를 찾아냄

판결: 탁월한 측면 사고(lateral thinking). 다른 추상화 수준에서 버그를 찾아냈습니다. 풀(pool) 수준의 수정과 결합되면 이 해결책은 더욱 강력해집니다. 단독으로는 풀(pool) 고갈(exhaustion) 문제를 해결하지 못합니다.

MiMo V2.5 (저렴함)

시간: ~4분 | 비용: 총 $0.067 중 일부

찾아낸 내용: 1개의 레이스 컨디션 (Race Condition) — 고아 연결 (orphaned connections). 2가지 변형을 제안함: (A) 핸들러 + (B) try/finally.

제안된 수정안:

async with self._pool_lock:
    self._requests.append(status)
    try:
...

아키텍처: 예외 안전성 (Exception safety) — try/finally를 통해 정리(cleanup)를 보장함.

장점:

• ✅ 가장 단순한 변경 — 기존 코드를 감싸는 방식
• ✅ 조건 인식 — connection is None인 경우에만 제거함
• ✅ 새로운 메서드 없음

단점:

• ❌ 여전히 락(lock) 내부에서 I/O 발생 (await _close_expired_connections())
• ❌ RC1만 포착함. RC2와 RC3는 놓침
• ❌ 연결(connection)이 할당된 경우 — except 블록이 이를 처리하지 못함
• ❌ 반응적(Reactive) — 고아(orphan)가 생성된 후, 그제서야 정리됨

판결: 빠른 수정안이지만, 프로덕션 환경에 바로 적용하기에는 부족함. 핫픽스(hotfix)용으로는 충분함.

Kimi K2.6

시간: ~23분 | 비용: 총 $1.04 중 일부

발견 내용: 1개의 레이스 컨디션 (race condition). 가장 짧은 1라운드 결과 (57줄). FIFO 가드 (FIFO guard)와 고아(orphan)가 풀(pool)을 차단하는 이유를 정확하게 설명함.

제안된 수정안: MiMo cheap와 동일함 — lock 본문을 try/finally로 감쌈.

아키텍처 (Architecture): MiMo cheap와 동일함. 장점과 단점이 모두 동일함.

장점:

• ✅ 가장 짧은 1라운드 솔루션
• ✅ 일반적인 케이스에 대해 정확함

단점:

• ❌ MiMo cheap와 동일한 문제점

판결: 깔끔하고 최소한임. 하지만 동일한 아키텍처적 약점을 가짐.

GLM 5.2

시간: ~20분 | 비용: 총 $1.28 중 일부

발견 내용: 1개의 레이스 컨디션 (race condition). 핵심 관찰 사항 — 비대칭적 정리 (asymmetric cleanup): 두 개의 예외 처리기 (exception handlers)가 서로 다른 동작을 수행함.

핵심 통찰: 첫 번째 처리기 (240–248행)는 상태(status)만 제거함. 두 번째 처리기 (265–268행)는 완전한 정리를 위해 response_closed()를 호출함. 이 비대칭성이 바로 설계 문제임.

제안된 수정안:

except BaseException as exc:
    with AsyncShieldCancellation():
        if status.connection is not None:
...

아키텍처 (Architecture): 통합된 정리 (Unified cleanup) — 두 처리기가 동일한 작업을 수행하도록 만듦.

장점:

• ✅ 아키텍처적 문제를 식별함 — 단순히 누락된 줄이 아니라 비대칭적 설계를 지적함
• ✅ 큐 (queue) 재평가 — 다음 대기 중인 요청을 승격시킴 (큐 정체 (Queue Stall) 해결)
• ✅ 두 가지 케이스 모두 처리 — 연결이 할당된 경우 vs 할당되지 않은 경우

단점:

• ❌ lock 내부의 await 호출 — 여전히 취소 가능 구간 (cancellation windows)이 존재함
• ❌ 반응적 (Reactive) — 고아(orphans)가 생성된 후 정리됨
• ❌ response_closed()의 재평가 루프를 중복함

판결: 1라운드에서 가장 뛰어난 문제 진단. 하지만 수정안의 품질이 분석의 품질에는 미치지 못함.

1라운드 요약

모델	발견된 버그	수정 유형	새로운 Race Window 생성 여부?	라인 수
DeepSeek Pro	1	Cleanup handler (정리 핸들러)	Yes (lock 내부의 await)	~80
...
주요 관찰 사항: 모든 모델이 1라운드에서 cleanup thinking (정리 중심 사고) 방식을 기본으로 채택했습니다. 즉, "문제를 감지한 후 수정한다"는 방식입니다. 문제를 사전에 방지하는 방식("문제가 발생할 수 없도록 구조를 재설계한다")을 제안한 모델은 없었습니다. 이는 예방(prevention)이 정리(cleanup)보다 더 어려운 추론 패턴임을 시사합니다.

2라운드: 패치에서 예방으로

"원자적 상태 관리 (atomic state management)"라는 힌트가 제공되자, 모든 모델이 정리 방식에서 예방 방식으로 전환되었습니다. lock 본문 내부에는 await 지점이 전혀 없어야 한다는 핵심 통찰은 공통적이었습니다. 하지만 구현 방식은 아키텍처 측면에서 서로 달랐습니다.

DeepSeek V4 Pro — Lock 기반 원자성 (Lock-based Atomic)

소요 시간: ~5분

아키텍처: 연결 점유(connection claiming) 과정을 response_closed() (Task B)에서 wait_for_connection() (Task A)로 이동합니다. 각 태스크는 lock 내부에서 자신의 연결을 직접 점유합니다.

이전: Task B가 Task A에 연결을 할당함 (proactive, 선제적)
이후: Task A가 자신을 위한 연결을 점유함 (reactive, 반응적이지만 원자적)

주요 변경 사항:

• 새로운 공유 이벤트 _pool_state_changed 도입
• 수동 lock 관리를 포함한 새로운 메서드 _wait_and_acquire() 도입
• response_closed()에서의 선제적 할당 제거

장점:

• ✅ 명확한 책임 분리 — 각 태스크가 자신의 생명주기를 직접 관리함
• ✅ 가장 단순한 멘탈 모델: 대기(wait) → 점유(claim) → 사용(use) → 해제(release)
• ✅ 5가지 취소 시나리오 분석 (가장 철저함)

단점:

• ❌ 수동 lock 관리 (__aenter__/__aexit__)는 취약함
• ❌ FIFO 가드 하에서의 Busy-polling 발생
• ❌ lock 해제 시점에 미세한 윈도우(micro-window) 발생 (안전망에 의해 완화됨)

레퍼런스(Reference)와의 비교: 아키텍처(누가 점유하는가)는 다르지만 동일한 보장을 제공합니다. 레퍼런스가 더 단순합니다.

MiMo V2.5 Pro — 3단계 분리 (Three-phase Separation)

소요 시간: ~6분

아키텍처: 3단계로 구성. Lock 본문 내 await 지점 = 0개.

Phase 1: CLEANUP — 만료되거나 유휴 상태인 연결 식별 (I/O)
Phase 2: STATE — 추가(append), 스윕(sweep), 획득(acquire) (동기 (sync))
Phase 3: I/O — 대기(wait), 요청 전송 (network)

주요 변경 사항 (Key changes):

• _attempt_to_acquire_connection → 동기 (sync), (bool, List[connection]) 반환
• _close_expired_connections → 동기 (sync), List[connection] 반환
• Phase 1 및 2를 위한 AsyncShieldCancellation 적용

장점 (Pros):

• ✅ Lock 내 await 없음 — 수학적으로 증명 가능
• ✅ 수집 후 폐쇄 (Collect-then-close) — I/O를 배치 처리하거나 재시도 가능
• ✅ 반환 값이 명시적임

단점 (Cons):

• ❌ 반환 타입 변경으로 인해 기존 호출자(callers)의 코드가 깨짐
• ❌ 더 많은 코드 양 (~350행)
• ❌ Shield 오버헤드

참조 모델과의 비교 (Comparison to reference): 동일한 아키텍처, 동일한 보장. 코드 양은 더 많지만 더 정형화(formal)되어 있음.

DeepSeek V4 Flash — 참조 품질 (Reference Quality)

소요 시간: ~4분

아키텍처: 참조 모델과 동일 — Lock 내부에는 상태(state)를, 외부에는 I/O를 배치. 더 깔끔한 명명 규칙(naming).

_attempt_to_acquire_connection → 동기 (sync), List[connection] 반환
_close_expired_connections → _mark_expired_connections (동기 (sync))

주요 변경 사항 (Key changes): MiMo Pro와 동일하지만, 더 나은 명명 규칙과 더 적은 코드 양을 가짐.

장점 (Pros):

• ✅ 가장 깔끔한 구현 (~200행)
• ✅ 가장 빠른 V2 (~4분)
• ✅ AsyncShieldCancellation이 필요 없음

단점 (Cons):