「코드를 빠르게」가 떠오르면 추측하지 말고 측정하세요.
도널드 크누스의 「섣부른 최적화는 만악의 근원」 격언처럼, 측정 없는 최적화는 오히려 코드를 망칩니다.
최적화 순서.
1) 「충분히 빠른가」 먼저 — 응답 100ms면 보통 충분, 50ms로 줄일 가치가 있는지.
2) 측정 — cProfile·py-spy·timeit.
3) 가장 큰 병목만 손봄.
4) 다시 측정해 효과 확인.
흔한 초보 실수.
1) 「+= 대신 join이 빠르대」 같은 미세 차이에 집착, 정작 병목인 DB 쿼리는 그대로.
2) 추측으로 코드 변경 — 더 느려진 줄 모름.
3) 한 번에 여러 최적화 — 어느 게 효과인지 모름.
큰 효과 영역.
1) 알고리즘 — O(N²) → O(N log N)이 100x 차이.
2) IO 최소화 — DB 100번 → 1번 배치 쿼리.
3) 캐싱 — 같은 계산 반복 회피.
4) 자료구조 선택 — list vs set vs dict.
5) 병렬화.
「충분히」가 핵심.
99%의 코드는 충분히 빠릅니다.
정말 느린 1%만 신경 쓰면 됨.
가독성·유지보수성을 희생할 만한 가치가 있는지 매번 자문.
빠른 코드보다 고치기 쉬운 코드가 장기적으론 더 가치 있음.
한 줄 요약
최적화는 측정 우선.
미세 차이 무시, 큰 병목(알고리즘·IO·캐싱)에 집중.
한 번에 하나, 다시 측정.
가독성 손해 볼 가치 있는지 매번 자문.
더 알아볼 것
- 크누스의 격언 전문
- Big-O 표기와 알고리즘
- 조기 최적화의 코드 부패
