솔직히 말해봅시다. 개발자들 사이에는 숫자에 대한 맹목적인 믿음이 있습니다. 초당 처리량(Throughput)이 높으면 무조건 좋은 시스템이고, 지연 시간(Latency)이 낮으면 무조건 성공한 아키텍처라고 생각합니다. 하지만 최근 Hacker News에 올라온 Stockfish(체스 엔진) 관련 이슈를 보면, 이런 단순한 접근이 얼마나 위험한지 뼈저리게 느낄 수 있습니다.
숫자는 거짓말을 하지 않지만, 숫자를 해석하는 맥락(Context)은 우리를 기만합니다. 오늘은 Lichess와 로컬 Stockfish의 성능 불일치 사례를 통해, 엔지니어가 '보이는 지표' 뒤에 숨겨진 진짜 병목을 찾는 법을 이야기해 보겠습니다.
1. 사건의 발단: 100만 노드 처리하는데 왜 더 느린가?
한 유저가 흥미로운 질문을 던졌습니다. Redmi Note 14 Pro 환경에서 두 가지 시나리오를 비교했는데, 결과가 모순적입니다.
시나리오 A (Lichess 웹 브라우저)
- 속도: 1 MN/s (초당 100만 노드 탐색)
- Depth 30 도달 시간: 2분 30초
시나리오 B (로컬 Native 바이너리 + Python)
- 속도: 600 kN/s (초당 60만 노드 탐색)
- Depth 30 도달 시간: 53초
직관적으로 보면 시나리오 A가 40% 이상 더 많은 노드를 처리하므로 더 빨라야 합니다. 하지만 실제 결과는 시나리오 B가 3배 가까이 빠릅니다. 여기서 많은 주니어 개발자들이 혼란에 빠집니다. "처리량이 높은데 왜 결과는 늦게 나오나요?"
이 질문에 답하지 못한다면, 당신은 클라우드 비용 청구서를 받고 나서야 후회하게 될 겁니다.
2. Vanity Metric(허영 지표)의 함정
웹 기반의 Lichess가 보여주는 1 MN/s는 전형적인 '허영 지표'일 가능성이 높습니다. 웹 어셈블리(WASM) 기반으로 돌아가는 브라우저 엔진은 UI 스레드와의 통신, 비동기 처리를 위해 자잘한 오버헤드를 껴안고 돕니다.
여기서 핵심은 '노드의 질(Quality of Nodes)'입니다.
로컬 네이티브 실행 파일은 불필요한 가지치기(Pruning)를 공격적으로 수행하며, 실제로 의미 있는 수(Valid Move)만 깊게 파고들었을 확률이 높습니다. 반면 웹 버전은 MultiPV(여러 수를 동시에 분석) 설정이 켜져 있거나, 시각적 효과를 위해 덜 중요한 노드까지 카운팅에 포함했을 수 있습니다.
엔지니어링에서 중요한 건 '얼마나 많이 했냐'가 아니라 '얼마나 유효한 일을 했냐'입니다. CPU가 헛도는 것(Spinlock)도 CPU 사용량 100%로 잡히는 것과 같은 이치입니다.
3. Depth(깊이)는 절대적인 척도가 아니다
또 하나 간과하기 쉬운 점은 'Depth 30'이라는 기준의 모호함입니다. 서로 다른 구현체에서 Depth 30은 같은 작업량을 의미하지 않습니다.
구현의 차이
- Lichess: 사용자의 경험을 위해 안정적인 평가 점수를 유지하려 넓은 탐색(Wider Search)을 수행할 수 있습니다.
- 로컬 Stockfish: 최단 시간 내에 최적의 수를 찾기 위해 좁고 깊은 탐색(Narrow & Deep Search)에 최적화되어 있습니다.
만약 여러분이 사내에서 "우리 서버가 타사보다 처리량이 2배 높습니다"라고 보고했는데, 실제 응답 속도(Latency)는 더 느리다면? 그건 자랑이 아니라 리소스 낭비(TCO 증가)를 자백하는 꼴입니다.
4. 생존을 위한 디버깅 체크리스트
이런 상황에서 '왜 느리지?'라고 막연해하지 말고, 다음 3단계로 파고들어야 합니다.
Step 1: I/O와 IPC 오버헤드 확인
로컬에서 Python을 썼다면 subprocess 모듈을 통한 표준 입출력(stdin/stdout) 오버헤드가 발생합니다. 하지만 이번 케이스처럼 로컬이 더 빠르다면, 이는 Native Binary의 최적화(AVX2, NEON 명령어 세트 활용)가 인터프리터 언어의 오버헤드를 상쇄하고도 남을 만큼 강력하다는 증거입니다. 브라우저 샌드박스 안의 WASM은 아무리 빨라도 Native의 SIMD 명령어를 100% 효율로 끌어다 쓰기 어렵습니다.
Step 2: 진짜 병목(Bottleneck) 측정
단순 N/s가 아니라 'Time to First Token'처럼 'Time to Depth X'를 핵심 KPI로 잡아야 합니다. 비즈니스 가치는 CPU를 얼마나 갈궜느냐가 아니라, 사용자가 언제 결과를 보느냐에서 나옵니다.
Step 3: 설정(Configuration) 1:1 비교
HN 댓글에서도 지적하듯, Hash Size(메모리), Thread 수, MultiPV 설정이 다르면 비교 자체가 성립되지 않습니다. 기본값(Default)을 믿지 마십시오. 라이브러리를 가져다 쓸 때는 config 파일을 까보는 게 엔지니어의 기본 소양입니다.
마치며: 화려한 대시보드 뒤를 보라
엔비디아에서 일하며 수많은 벤치마크를 보지만, 숫자는 의도를 가지고 가공되기 마련입니다. Lichess가 보여주는 높은 N/s는 사용자에게 "열심히 분석 중입니다"라는 심리적 안정감을 주기 위한 UI적 장치일 수도 있습니다.
여러분이 서버 개발자라면, 혹은 인프라를 담당한다면 기억하세요. 높은 Throughput이 늦은 Latency를 정당화할 순 없습니다. 보여주기식 지표에 취해 진짜 성능을 놓치지 마십시오. 오늘 당장 여러분의 모니터링 대시보드에서 '가짜 숫자'를 걷어내는 것부터 시작해 보길 권합니다.
