GitHub의 실제 레이스 컨디션 (Race Condition) 버그를 활용한 두 LLM의 실전 비교

요약 (TL;DR)

지표	DeepSeek V4 Pro	MiMo V2.5 Pro
시간	약 8분 (2 라운드)	약 15분 (2 라운드)
...
결론: MiMo가 디버깅(더 많은 버그 발견, 더 깊은 분석)에 더 뛰어나며 가격도 더 저렴합니다. DeepSeek는 더 빠르며 코드 작성에 더 적합합니다.

왜 이 벤치마크를 진행했는가?

대부분의 LLM 벤치마크는 코딩 능력 — 함수 작성, 퍼즐 풀기, 알고리즘 구현 등을 테스트합니다. 하지만 실제 개발 환경에서는 디버깅 (Debugging)이 코드를 작성하는 것보다 더 어렵습니다. 디버깅을 위해서는 다음이 필요합니다:

1. 복잡하고 여러 파일로 구성된 코드베이스 (Codebase) 이해
2. 명확하지 않은 근본 원인 (Root Cause) 발견
3. 메커니즘을 명확하게 설명
4. 올바른 수정 사항 (Fix) 제안

우리는 이 특정 기술을 테스트하고 싶었습니다. 그래서 인기 있는 오픈 소스 라이브러리에서 실제 레이스 컨디션 (Race Condition) 버그를 가져와 두 모델에게 주었습니다.

버그: httpcore #961

저장소 (Repository): encode/httpcore
이슈 (Issue): #961 - 비동기 취소 후 레이스 컨디션으로 인한 커넥션 풀 파손
수정 PR: #880 - 안전한 비동기 취소 (Safe async cancellations)

httpcore란 무엇인가?

httpcore는 httpx (인기 있는 Python HTTP 클라이언트)에서 사용되는 저수준 (Low-level) HTTP 클라이언트 라이브러리입니다. 커넥션 풀링 (Connection Pooling), HTTP/2, 프록시 (Proxies) 등을 처리합니다.

버그 내용

연결 작업 중에 비동기 태스크 (Async Task)가 취소되면, 풀 (Pool)의 내부 상태가 불일치하게 됩니다. 풀은 연결이 실제로 취소되었음에도 불구하고 여전히 사용 중이라고 판단하여, 풀 고갈 (Pool Exhaustion) 현상을 초래합니다. 이로 인해 새로운 요청이 연결을 영원히 획득할 수 없게 됩니다.

어려운 이유

• 다중 파일: connection_pool.py, connection.py, http2.py가 연관됨
• 비동기 특화: asyncio/trio 취소 상황에서만 나타남
• 불분명함: 로그에는 정상 작동으로 표시되며, 레이스 윈도우 (Race Window)가 매우 작음
• 실제 사례: 실제 사용자에게 영향을 미치는 운영 환경 (Production) 이슈임

방법론 (Methodology)

벤치마크 구조

우리는 각 모델에게 수정 사항이 적용되기 전(커밋 7fa6bf)의 httpcore 프로젝트 전체를 제공했습니다. 프로젝트에는 다음이 포함되었습니다:

• 전체 소스 코드 (90개 파일)
• 버그 설명이 포함된 README.md (수정 방법에 대한 힌트 없음)
• 지침이 포함된 PROMPT.md
• SOLUTION.md 및 SOLUTION.diff (모델에게는 숨김 처리)

Round 1: 버그 찾기 (Find the Bug)

프롬프트 (두 모델 모두 동일):

버그가 있는 Python 프로젝트가 주어집니다. 당신의 작업은 버그를 찾고
이를 수정하는 방법에 대한 상세한 설명을 작성하는 것입니다.

...

Round 2: 수정 사항 개선 (Refine the Fix)

Round 1 이후, 두 모델 모두 예방 (prevention) (원자적 상태 관리 (atomic state management)) 대신 패치 (patches) (정리 핸들러 (cleanup handlers))를 제안했습니다. 우리는 모델들에게 힌트를 제공했습니다:

프롬프트 (두 모델 모두 동일):

당신의 이전 수정 사항은 취소 핸들러 (cancellation handler)에서
고립된 연결 (orphaned connections)을 처리했습니다. 이는 작동하지만,
증상만을 처리합니다 — 연결은 여전히 고립되며, 단지 사후에
정리할 뿐입니다.
...

결과: Round 1

DeepSeek V4 Pro (~3분)

근본 원인 (Root Cause): 1개의 레이스 컨디션 (race condition) 발견 — 할당 후 재개(resume) 전 태스크가 취소될 때 발생하는 고립된 연결.

핵심 통찰 (Key Insight): "연결은 풀 (pool)에 '사용 중'으로 표시된 채 남아 있지만, 이를 사용해야 했던 태스크는 사라졌습니다."

제안된 수정 사항: 취소 핸들러 (cancellation handler)에서 고립된 연결을 처리 — 연결이 할당되었는지 확인하고 이를 해제함.

품질: 탁월한 근본 원인 분석 및 단계별 메커니즘 설명. 그러나 제안된 수정 사항은 예방이 아닌 패치 (정리 핸들러)였음.

MiMo V2.5 Pro (~9분)

근본 원인 (Root Cause): 3개의 서로 다른 레이스 컨디션 (race conditions) 발견:

1. 초기 풀 잠금 (pool lock) 중 상태 누수 (Status leak)
2. ConnectionNotAvailable 재시도 중 상태 누수 (Status leak)
3. 정리 (cleanup) 중 연결 누수 (Connection leak)

핵심 통찰 (Key Insight): 기존 테스트가 왜 이를 잡아내지 못하는지 설명 — 기존 테스트는 단일 요청 시나리오를 사용함.

제안된 수정 사항: 정리 핸들러 (cleanup handlers) 추가 + 방어적 연결 스윕 (defensive connection sweep).

품질 (Quality): 우수한 분석이며, DeepSeek보다 더 깊이 있는 분석을 보여주었습니다 (버그 3개 vs 1개). 하지만 제안된 수정 사항 역시 예방이 아닌 패치(정리 핸들러 (cleanup handlers)) 수준이었습니다.

1라운드 비교 (Round 1 Comparison)

측면 (Aspect)	DeepSeek	MiMo
시간 (Time)	~3분	~9분
...

결과: 2라운드 (Results: Round 2)

DeepSeek V4 Pro (~5분)

접근 방식 (Approach): 연결 점유 (connection claiming)를 대기 작업 (waiting task)으로 이동시키고, 잠금 (lock) 내부에서 원자적 (atomic)으로 처리합니다.

주요 변경 사항 (Key Changes):

• 새로운 _wait_and_acquire() 메서드 추가
• response_closed()에서의 선제적 할당 (proactive assignment) 제거
• _pool_state_changed 이벤트 추가

품질 (Quality): 🟢 실제 수정 사항과 유사하며, 아키텍처적으로 깔끔합니다.

MiMo V2.5 Pro (~6분)

접근 방식 (Approach): 3단계 분리 — 정리 (CLEANUP, I/O), 상태 (STATE, 동기화 (sync)), I/O (네트워크).

주요 변경 사항 (Key Changes):

• _attempt_to_acquire_connection이 이제 동기적 (synchronous)으로 동작함 (잠금 내부에 await 없음)
• 임계 구역 (critical sections)을 위한 AsyncShieldCancellation 적용
• 안전망으로서의 최상위 정리 핸들러 (top-level cleanup handler) 추가

품질 (Quality): 🟢 체계적인 접근 방식이며, 5가지 취소 (cancellation) 시나리오를 분석했습니다.

2라운드 비교 (Round 2 Comparison)

측면 (Aspect)	DeepSeek	MiMo
시간 (Time)	~5분	~6분
...

토큰 사용량 및 비용 (Token Usage & Cost)

지표 (Metric)	DeepSeek V4 Pro	MiMo V2.5 Pro
총 토큰 (Total tokens)	2,431,121	3,356,951
...

비용 계산 (Cost Calculation)

두 모델 모두 OpenCode Go에서 동일한 가격 정책을 사용합니다:

• 캐시 히트 (Cache hit): $0.003625/M 토큰
• 캐시 미스 (Cache miss): $0.435/M 토큰
• 출력 (Output): $0.87/M 토큰

DeepSeek V4 Pro:

• 캐시 히트: 2.198M × $0.003625 = $0.008
• 캐시 미스: 0.189M × $0.435 = $0.082
• 출력: 0.044M × $0.87 = $0.038
• 소계 (Subtotal): $0.128
• 6% 충전 수수료 (top-up fee) 포함: $0.14

MiMo V2.5 Pro:

• 캐시 히트: 3.146M × $0.003625 = $0.011
• 캐시 미스: 0.158M × $0.435 = $0.069
• 출력: 0.053M × $0.87 = $0.046
• 소계 (Subtotal): $0.126
• 수수료 0% 포함: $0.13

MiMo가 더 저렴한 이유

MiMo는 38% 더 많은 토큰을 사용했음에도 불구하고 다음과 같은 이유로 더 저렴했습니다:

1. 충전 수수료 없음 (DeepSeek의 6% 대비 0%)
2. 더 높은 캐시 히트율 (95.2% vs 92.1%)

레퍼런스 수정 (PR #880)

Tom Christie (httpcore 저자)가 수행한 실제 수정 사항은 우아할 정도로 단순했습니다:

접근 방식: 모든 상태 관리 (state management)를 잠금 (locks)을 사용하여 취소 불가능한 (non-cancellable) 섹션으로 이동합니다.

핵심 통찰: "비동기 (async) 케이스의 경우, 우리가 잠금 (lock)을 보유하고 있기 때문에 상태 관리 중간에 취소 (cancellation)나 컨텍스트 스위칭 (context-switch)이 발생할 수 없습니다."

변경 파일: 9개 파일, +512/-379 라인

두 모델 모두 2라운드에서 이 접근 방식에 수렴했으나, 구현 방식은 달랐습니다:

• DeepSeek: 잠금 기반의 원자적 점유 (Lock-based atomic claiming)
• MiMo: 3단계 분리 (CLEANUP → STATE → I/O)

판결

우열의 문제가 아닌 서로 다른 특성

작업	더 나은 모델	이유
코드 작성 (Writing code)	DeepSeek V4 Pro	더 빠르고, 토큰 사용량이 적으며, 아키텍처가 더 깔끔함
디버깅 (Debugging)	MiMo V2.5 Pro	더 많은 버그를 찾아내며, 분석이 더 깊고, 비용이 저렴함

DeepSeek의 강점

• 속도: 2배 더 빠름 (8분 vs 15분)
• 효율성: 토큰 사용량 37% 적음
• 아키텍처: 더 깔끔하고 단순한 솔루션
• 최적 용도: 기능 구현, 새로운 코드 작성

MiMo의 강점

• 깊이: 3개의 레이스 컨디션 (race conditions) 발견 (DeepSeek은 1개)
• 분석: 5가지 취소 (cancellation) 시나리오 제시, 테스트가 이를 잡아내지 못하는 이유를 설명함
• 비용: 더 많은 토큰을 사용함에도 불구하고 더 저렴함 (충전 수수료 0%)
• 최적 용도: 복잡한 문제 디버깅, 코드 리뷰, 버그 찾기

비용 효율성

이 특정 디버깅 작업의 경우:

• DeepSeek: 2라운드 기준 $0.14
• MiMo: 2라운드 기준 $0.13

MiMo는 디버깅을 더 잘할 뿐만 아니라 더 저렴합니다. 더 높은 토큰 사용량은 충전 수수료가 없다는 점에 의해 상쇄됩니다.

방법론 참고 사항

왜 실제 버그인가?

합성 버그 (Synthetic bugs)는 너무 쉽습니다. 모델들이 몇 초 만에 해결해 버립니다. 프로덕션 코드베이스의 실제 버그는 다음과 같은 능력을 요구합니다:

• 복잡한 아키텍처 이해
• 여러 파일을 통한 상태 (state) 추적
• 비동기/동시성 (async/concurrent) 동작에 대한 추론
• 명확하지 않은 근본 원인 (root causes) 발견

왜 2라운드인가?

실제 디버깅 환경에서는 보통 먼저 빠른 수정안을 얻은 다음, 이를 정교화합니다. 두 라운드를 모두 테스트하면 다음과 같은 것을 알 수 있습니다:

1. 초기 디버깅 능력 (버그 찾기)
2. 반복적 개선 (힌트를 통한 정교화)

토큰 계산 방법론 (Token counting methodology)

• 벤치마크 전 기준 스냅샷 (Baseline snapshot)
• 완료 후 스냅샷
• 델타 (Delta) = 작업에 사용된 토큰
• OpenCode Go 가격 정책을 사용하여 비용 계산

결론

이 벤치마크는 디버깅과 코드 작성은 서로 다른 기술임을 보여줍니다. DeepSeek는 깨끗하고 효율적인 코드를 빠르게 작성하는 데 탁월합니다. MiMo는 심층 분석과 미세한 버그를 찾아내는 데 탁월합니다.

AI 보조 개발 도구를 구축하는 팀을 위한 권장 사항:

• 코드 생성 (Code generation), 리팩토링 (Refactoring), 구현 (Implementation)에는 DeepSeek를 사용하세요.
• 코드 리뷰 (Code review), 디버깅 (Debugging), 근본 원인 분석 (Root cause analysis)에는 MiMo를 사용하세요.

놀라운 발견: MiMo는 충전 시 수수료가 0%이기 때문에 더 많은 토큰을 사용함에도 불구하고 디버깅 비용이 더 저렴합니다. 대량의 디버깅 워크로드의 경우, 이러한 비용 차이는 상당한 차이를 만듭니다.

본 벤치마크는 2026년 6월 30일에 DeepSeek API 및 Xiaomi MiMo API 플랫폼을 사용하여 수행되었습니다. 전체 벤치마크 데이터는 저자의 GitHub 저장소에서 확인할 수 있습니다.