# 인상적인 성능 향상이 중요하지 않을 때 > Clean Markdown view of GeekNews topic #30955. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30955](https://news.hada.io/topic?id=30955) - GeekNews Markdown: [https://news.hada.io/topic/30955.md](https://news.hada.io/topic/30955.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-30T09:11:29+09:00 - Updated: 2026-06-30T09:11:29+09:00 - Original source: [blog.colinbreck.com](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/) - Points: 1 - Comments: 1 ## Topic Body - 성능 최적화는 복잡한 시스템을 이해하고 제품을 개선하는 강력한 수단이지만, **10배 빠른 결과**도 실제 업무 방식이나 처리량을 바꾸지 못할 수 있음 - 쿼리 응답을 5~10분에서 30초~1분으로 줄여도, 사람이 기다리며 주의를 유지하는 **약 10초 임계값**을 넘으면 체감 효과가 제한됨 - 작업이 하루 1건·2건처럼 정수 단위로 묶이면 25~50% 개선만으로는 부족하며, 이동 시간을 포함해 각 작업이 **4시간 이하**가 되어야 하루 2건이 가능함 - 데이터 파이프라인에서는 느린 단계가 상류에 **백프레셔**를 걸기 때문에, 단일 단계가 크게 빨라져도 모든 병목이 풀리기 전까지 종단 간 처리량이 늘지 않을 수 있음 - 성능 개선은 개별 벤치마크가 아니라 원하는 결과를 기준으로 평가해야 하며, 주의 유지·작업 단위 증가·전체 처리량 같은 제약을 넘지 못하면 큰 개선도 실질 효과가 작음 --- ### 성능 수치와 실제 결과가 어긋나는 이유 - 성능 작업은 시스템을 더 효율적으로 만들고 고객에게 새로운 가능성을 열 수 있어 보람 있는 작업임 - 규모와 부하가 걸린 복잡한 시스템이 어떻게 상호작용하는지 **경험적으로 이해**하는 데도 도움이 됨 - 시스템을 가까이 다루는 과정에서 제품과 서비스를 개선할 아이디어가 나오며, 그중 일부는 성능 최적화와 직접 관련이 없음 - 다만 “10배 빠름”, “리소스 50% 감소”처럼 보기 좋은 성과도 숨은 제약을 넘지 못하면 기대한 변화를 만들기 어려움 ### 10초를 넘으면 사용자의 주의가 끊김 - 새 데이터베이스의 쿼리 성능을 개선해, 기존 데이터베이스에서 가장 비싼 쿼리가 **5~10분** 걸리던 것을 **30초~1분**으로 줄인 사례가 있음 - 이 결과는 10배 수준의 개선이었지만, 사용자 경험을 바꾸려면 또 한 번의 큰 개선이 필요했음 - 인간-컴퓨터 상호작용 연구에서는 사람이 전체 작업에 주의를 유지하는 한계를 약 **10초**로 봄 - 0.1초는 즉각적인 피드백으로 인식되는 임계값 - 약 1초는 작업 흐름이 이어지는 임계값 - 약 10초는 전체 작업에 대한 주의를 유지하는 임계값 - 진행 표시기나 예상 시간 같은 피드백은 주의 유지에 도움을 줄 수 있음 - 30초와 5분은 모두 10초를 넘기 때문에 사용자는 메시지를 확인하거나, 커피를 마시러 가거나, 대화를 시작하거나, 다른 작업으로 전환함 - 사용자가 몇 분 또는 몇 시간 뒤 돌아왔을 때 UI가 이미 로드되어 있다면, 실제 대기 시간이 30초였는지 5분이었는지는 업무 방식에 큰 차이를 만들지 않음 - 해당 프로젝트에서는 결국 다수의 쿼리를 **10초 이하**로 줄였고, 이전에는 타임아웃 때문에 불가능했던 일부 쿼리도 가능해짐 - 데이터 쿼리 지연뿐 아니라 메타데이터 쿼리 지연과 웹페이지 렌더링 시간도 전체 성능 개선에 중요했음 - 비동기 IO와 데이터 집계 개선으로 또 한 번의 10배 개선 가능성이 남아 있으며, 그렇게 되면 예전에는 몇 분 걸리던 쿼리가 1초 이하로 돌아올 수 있음 ### 하루 1건에서 2건으로 넘어가는 임계값 - 한 프로젝트에서는 수동 작업 자동화, 불필요한 단계 제거, 일부 병렬화, 나중에 비동기로 처리할 수 있는 단계 지연을 통해 전체 프로세스를 몇 시간에서 안정적으로 **1시간 미만**으로 줄임 - 개선 폭은 대략 **25~50%** 였지만, 전체 프로세스는 물류 제약 때문에 바뀌지 않았음 - 배관공, 전기공, 목수처럼 장소를 예약하고 이동한 뒤 작업을 완료해야 하는 경우를 생각할 수 있음 - 하루 8시간 일하고 한 장소의 작업에 8시간이 걸리면, 2~3시간을 아껴도 새 장소로 이동해 새 작업을 끝낼 시간이 없음 - 이동 시간을 포함해 각 작업이 **4시간 이하**가 되지 않으면 하루 2건을 완료할 수 없음 - 이런 임계값을 넘기 전까지는 중간 단계의 효율 개선이 생산량 증가로 이어지지 않음 - 성능에 집중한 덕분에 고객 경험에 직접 영향을 주는 **품질과 안정성 개선**도 함께 이뤄질 수 있음 - 프로덕션에서 돌파구가 되지 못한 작은 성능 개선도 테스트 환경의 반복 속도를 높여 기능 개발과 결함 해결을 빠르게 만들 수 있음 ### 백프레셔가 있는 파이프라인의 병목 - 많은 비즈니스 소프트웨어 인프라는 차량, 공장 장비, 모바일폰, 금융 거래 같은 여러 소스의 이벤트를 처리하는 **데이터 파이프라인**을 포함함 - 이벤트는 보통 내구성 있는 로그에 저장되고, 하류 서비스가 이를 소비해 처리함 - 대규모 고처리량을 위해 로그는 파티션되어야 하며, 하류 서비스는 배치, 파이프라이닝, 병렬성, 효율적인 메모리 할당, 동적 확장 같은 기법을 사용함 - 데이터 파이프라인의 병목은 시스템 동작이 서로 연관되어 있어 찾기 어려움 - 느린 단계는 의도적으로 상류 단계에 **백프레셔**를 검 - 병목이 여러 개 있으면 마지막 병목까지 제거되기 전에는 전체 처리량이 늘지 않음 - 파이프라인을 단계로 나누고 각 단계의 성능 특성과 한계를 이해하는 것은 좋은 엔지니어링 관행임 - 하지만 단일 단계를 여러 자릿수 규모로 개선해도 전체 처리량에는 영향이 없을 수 있음 - 처리량 개선에서 중요한 수치는 개별 단계의 벤치마크가 아니라 **종단 간 처리량**임 ### 병목을 찾는 경험적 접근 - 이런 시스템의 동역학과 병목을 이해하려면 파이프라인의 시작점부터 경험적으로 확인하는 방식이 유용함 - 예를 들어 분산 로그에서 이벤트를 읽고 버리는 단계부터 시작함 - 이 단계만으로 목표 처리량에 도달하지 못하면 하류 단계를 최적화해도 시간 낭비가 됨 - 데이터베이스에 초당 몇 행을 삽입할 수 있는지 같은 하류 벤치마크도 중요할 수 있지만, 분석은 **상류부터** 시작해야 함 - 복잡한 시스템과 성능을 이해하는 데는 시뮬레이션도 가치 있는 방법임 - Marc Brooker의 [Simple Simulations for System Builders](https://brooker.co.za/blog/2022/04/11/simulation.html) - [Try again: The tools and techniques behind resilient systems](https://www.youtube.com/watch?v=rvHd4Y76-fs) ### 성능 개선의 기준은 원하는 결과 - 성능 작업은 어렵지만, 복잡한 시스템을 깊이 이해하고 더 나은 제품을 만드는 훈련이기도 함 - 사람의 주의를 붙잡아야 한다면 약 **10초** 안에 응답해야 함 - 전체 작업 단위가 제약이라면 퍼센트 개선만으로는 부족하고, 하루 1건에서 2건으로 넘어갈 수 있어야 함 - 백프레셔가 있는 파이프라인의 처리량을 극대화하려면 한두 개 병목이 아니라 모든 병목을 해결해야 하는 경우가 많음 - 이런 제약을 넘지 못하면 10배 수준의 성능 개선도 원하는 결과를 만들지 못함 ## Comments ### Comment 60775 - Author: neo - Created: 2026-06-30T09:11:30+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/fok2dp/when_impressive_performance_gains_do_not) - 전체 처리량에 영향이 없는 단계 하나를 수십 배 개선하고 실망하는 경우라면, 여기서는 **[Amdahl's law](https://en.wikipedia.org/wiki/Amdahl's_law)** 를 짚을 만함 - 컴퓨터과학 전반의 여러 **법칙 이름 모음** 같은 게 있는지 궁금함 계속 새 법칙을 듣게 되는데, 자주 쓰이지 않을 만큼 틈새라서 다시 잊어버리곤 함. 그렇다고 그런 법칙들이 세대 지식으로서 유효하거나 유용하지 않다는 뜻은 아님 - 애초에 왜 전체 시간에서 아주 작은 조각만 차지하는 부분을 최적화하고 있었는지 의문임 **가이드가 나빴는지**, 성능 도구가 부족했는지 모르겠음. 의식적으로 영향이 거의 없는 일을 하려는 사람은 드물고, 보통 더 큰 문제가 숨어 있음 - 이런 일이 생기는 한 경로는 대략 이렇다고 봄 어떤 문제를 보다가 샘플링 결과에서 특정 함수가 크게 보이고, 잠깐 살펴보니 구현을 꽤 쉽게 개선할 수 있어 보임. 하지만 지금은 다른 일을 하는 중이라 “나중에 처리하자”고 미뤄둠 나중에 그 쉬운 개선을 떠올리고 시작하는데, 막상 수정이 생각보다 복잡해져도 **터널 비전**이 생기고 퍼즐을 풀고 싶어져 시간을 많이 쓰게 됨 실제로는 그 성능 문제가 사소했을 뿐임. 당시 보던 맥락 안에서 비율상 커 보였거나, 절대 시간이 별 의미 없었거나, CPU가 아니라 입출력에 막힌 상황일 수 있음. 일종의 **자기 자신에게 당한 nerd sniping**에 가까움 - Google에서 한 번, 파이프라인 일부를 최적화하겠다는 제안이 있었고 여러 사람이 그 부분이 전체 계산량의 **0.1% 미만**이라 전체 이득도 정의상 0.1% 미만이라고 설명했음 그래도 무시하고 최적화를 진행했고, 전체 개선이 0.1% 미만으로 나오자 당황했음. 도메인 지식이 있으면 직관적으로도 비싸지 않은 부분이었지만, 시간을 낭비하지 않게 하려고 실제 성능 비용 측정까지 도와줬음 - 추측으로 움직이거나, 항상 적용하는 **모범 사례**를 내면화했거나, 제한된 상황에서 본 실제 문제를 과도하게 일반화했을 수 있음 또는 벤치마크가 오해를 불러왔을 수도 있음. 모든 시스템이 운영 환경에서 모든 메서드나 프로세스의 비용을 쉽게 보여주지는 않음 이런 설명들은 정도 차이는 있지만 모두 기능 장애에 가깝고, 어떤 건 개인의 문제에 더 가깝고 어떤 건 환경의 문제에 더 가까움 - 가능한 이유가 몇 가지 있음 1. 재능 있는 주니어 엔지니어가 문제 해결은 배웠지만, **풀 가치가 있는 문제를 고르는 법**은 못 배운 경우임. 발견한 모든 비효율을 종단 간 영향과 무관하게 공격함. 운이 좋으면 누군가 가르쳐주고, 아니면 PM이 단단히 통제해야 하는 시니어 엔지니어로 정체됨 2. 종단 간 성능을 제대로 볼 수 없음. 시스템 어딘가 성능 저하가 있고 경영진은 압박하지만 제대로 된 모니터링 도입 권한은 못 받아서, 추측으로 여러 컴포넌트를 건드리다 하나가 맞기를 바람. 그러다 급한 불이 꺼지면 다시 사용자 기능 출시로 돌아감 3. 지금은 문제가 아니지만 곧 문제가 될까 봐 미리 고치는 경우임. 영향력이 충분하거나 야근을 밀어붙일 수 있으면 당장 보이는 효과가 없어도 진행함. 훌륭한 엔지니어도 미래에 중요하다고 믿으면 이런 일에 정치적 자본을 쓰고, 덜 좋은 엔지니어는 전부 태워버림 3.1. 하이퍼스케일러에서 일하면 사용자에게 전혀 보이지 않는 **계산량 0.1% 절감**만으로도 해변가 집값을 댈 만큼 손익에 영향이 생길 수 있음 4. 도전을 참지 못하는 경우임. 실제로 아무것도 바뀌지 않을 걸 알지만 CRUD 앱만 만들다 지루해졌고, 블로그에서 본 걸 시도해볼 기회가 생긴 것임. 무의미함의 무게를 덜려고 스스로를 nerd snipe하는 셈임 - 통념과 달리 많은 시스템은 몇 개의 병목으로만 구성되지 않음 흔한 프로그래밍 관행 자체가 전반적으로 느린 경우가 많음. 예를 들면 포인터가 잔뜩 있고 일반 할당자를 통한 **힙 할당**이 엄청 많은 객체지향 코드가 떠오름. 어디를 고쳐도 전체 시간에서 작은 조각이라, 최악의 경우 완전 재작성 외에는 해결이 안 됨. 운이 좋으면 점진적으로 재작성할 수 있음 병목이 두 개뿐이어도 서로 한 자릿수 배율 안에 있으면 최악의 병목을 완벽히 고쳐도 한 자릿수 배 개선조차 안 나옴. 많은 경우 글에서 말하듯 의미 있는 이득을 얻으려면 그보다 훨씬 더 크게 넘어야 함 또 컴퓨터는 병렬로 돌아가는 분산 시스템에 가까움. CPU 몇 개, GPU, 디스크, Ethernet 등이 있고, 프로세스 속도는 파이프라인에서 가장 느린 단계가 제한함. 그 단계를 고치면 다음으로 느린 단계가 제한하고, 최악에는 가장 느린 단계가 여러 개라 하나만 고쳐서는 아무 이득도 없음 그래도 이건 선의로 해석한 설명이고, 때로는 그냥 최적화 게임에 빠져 **우선순위**를 잃거나 실수하기도 함 - 사용자가 알아차리지 못하더라도 소프트웨어의 **계산 시간 절감**은 여전히 좋음 비용을 줄이고 확장을 더 쉽게 만들 수 있기 때문임 - 그건 복잡도 비용에 달려 있음 코드를 빠르게 만드는 대가로 과도한 **복잡도**가 들어오면, 유지보수성은 제쳐두더라도 장기적으로 성능을 해치는 후속 결과가 생김. 구조 변경 시 이제는 불필요해질 코드가 남는데, 그걸 이해하거나 제거하려면 전체 복잡도를 완전히 이해해야 하기 때문임 “더 빨라진다”는 이유가 복잡도나 유지보수성 우려를 무시해도 되는 **면죄부**가 되어서는 안 됨 - 지금 비슷한 상황에 있고, 여러 작은 프로젝트로 **5분 걸리던 쿼리**를 30초 미만으로 줄이고 있음 장기적으로는 충분하지 않다고 팀에 말하지만, 분명 개선이고 영향도 큼 고객 입장에서는 기다림이 격분할 수준에서 그냥 짜증나는 수준으로 내려감 지금 초점은 사용자별 성능이 아니라 전체 성능임. 5분, 10분, 30분짜리 프로세스 수십 개를 최적화하면 시스템의 다른 부분과 생기는 **경합**이 크게 줄어듦. 10분 동안 데이터베이스를 두들기는 건 매우 긴 시간이고, 결국 모든 것이 더 빨라져 모두가 이익을 봄