핵심 요약
- 개발 도중 '작업량이 많아서 느린 게 당연하다'고 넘겨짚는 것은 대부분 분석 없는 핑계에 불과하다는 개발자의 비판 글입니다.
- 실제로는 알고리즘 결함, 하드웨어 성능 미활용, 불필요한 중복 연산 등으로 인해 최대 100배 이상의 성능 차이가 발생할 수 있습니다.
- 하드웨어의 물리적 한계치까지 철저히 프로파일링하지 않은 채 직관만으로 성능 문제를 정당화해서는 안 된다고 짚었습니다.
요약 소프트웨어 개발 과정에서 어떤 프로그램이나 시스템(X)의 처리 속도가 느릴 때 흔히 "할 일이 많아서 느린 건 당연하다"는 식의 변명이 나오곤 합니다. 하지만 유명 개발자 아르세니 카풀킨(Arseny Kapoulkine)은 이러한 주장이 대부분 문제에 대한 면밀한 분석 없이 발화자의 막연한 직관에 의존한 성급한 결론이라며 반박했습니다.
저자는 프로그램이 느린 진짜 원인이 '작업량' 자체가 아닌 구조적 문제일 가능성이 훨씬 높다고 지적합니다. 첫째, 데이터베이스 인덱스가 누락되는 등 알고리즘 자체의 복잡도가 비효율적인 경우입니다. 둘째, 동일한 아이디어라도 구현 방식에 따라 10배 이상의 성능 차이가 날 수 있으며, 프로파일링 없이는 병목 지점을 찾을 수 없습니다. 셋째, 최신 하드웨어의 성능(SIMD, 멀티스레딩, 캐시 효율 등)을 전혀 살리지 못해 최대 100배에 달하는 성능 손실이 발생하는 경우입니다. 넷째, 캐싱이 부실하거나 불필요한 계산을 반복하는 등 애초에 하지 않아도 될 작업을 처리하고 있는 경우입니다. 심지어 C++ 컴파일러가 느린 것처럼 문제 해결의 기본 전제나 틀 자체가 비효율적인 경우도 있습니다.
물론 하드웨어의 물리적 한계치(Speed of light calculation, 예: 메모리 대역폭 한계 도달 등)를 완벽히 분석한 끝에 "정말 할 일이 많아서 느리다"고 결론짓는 예외적인 경우도 존재합니다. 그러나 현실에서는 하드웨어, 데이터, 구현 코드에 대한 철저한 프로파일링 없이 "느린 게 당연하다"고 합리화하는 경우가 대부분이라는 것이 글의 핵심 비판입니다. 참고로 제목의 'X'는 특정 SNS(구 트위터)가 아닌 수학적 변수를 의미합니다.
Sponsored · 광고