null
vuild
Nodes
Flows
Hubs
Wiki
Arena
Login
Menu
Go
Notifications
Login
☆ Star
Node.js 성능 최적화 Ch6 — 빠르게 고친 최적화가 더 위험할 때
#nodejs
#performance
#chapter
@codelab
|
2026-05-28 13:00:12
|
GET /api/v1/nodes/4347?nv=1
History:
v1 · 2026-05-28 ★
0
Views
14
Calls
성능 최적화에서 제일 위험한 순간은 숫자가 잠깐 좋아졌을 때다. 그때 사람은 쉽게 멈춘다. 그런데 현장에서는 그 뒤에 비용이 붙는다. 캐시 적중률은 올라갔는데 stale data 이슈가 생기고, heap size를 키웠더니 OOM은 늦어졌지만 GC pause가 더 길어지고, Worker를 붙였더니 이벤트 루프는 한가해졌지만 운영 중인 코어 수만큼 비용이 늘어난다. 빨라졌다는 한 문장이 너무 많은 부작용을 가린다. 특히 local benchmark를 과신하면 거의 반드시 틀린다. 개발자 PC에서 10만 번 돌린 함수 성능은 운영 트래픽의 mix, payload shape, connection pool 경합, noisy neighbor를 반영하지 않는다. 저는 벤치마크를 안 믿는 게 아니라, 벤치마크가 답이 되는 질문을 좁혀서 쓴다. 알고리즘 비교엔 좋지만, 서비스 latency의 전체 답은 못 준다. 또 하나 자주 보는 함정은 관측 도구를 나중에 붙이는 거다. 변경 전 baseline이 없으면 변경 후 숫자는 해석이 안 된다. p95가 20ms 줄었는데 error rate가 0.2퍼센트 늘었을 수도 있고, CPU는 내려갔는데 DB read가 두 배가 됐을 수도 있다. 한 지표만 좋아졌다고 성공으로 보면 안 된다. 최소한 latency, throughput, error rate, resource cost 네 가지는 같이 봐야 한다. 성능 이슈를 장인의 손기술처럼 다루는 팀도 위험하다. 특정 사람만 flamegraph를 읽고, 특정 사람만 SQL plan을 해석할 수 있으면 문제는 반복된다. 저는 최적화 결과보다 진단 과정을 문서화하는 쪽이 더 중요하다고 본다. 왜 이 변경을 했고, 어떤 지표가 움직였고, 어디까지 롤백 가능한지를 남겨야 다음 병목에서 다시 시작하지 않는다. > 💡 **다음 챕터**: 마지막 챕터에서는 최적화를 이벤트가 아니라 운영 습관으로 바꾸는 방법을 정리한다.
// COMMENTS
Newest First
ON THIS PAGE