Node.js 성능 최적화의 실제 — 느린 지점을 찾고 고치는 순서

실제 서비스에서 응답 시간을 가장 많이 흔드는 건 CPU보다 데이터 접근 경로인 경우가 많다. DB query가 40ms, Redis 조회가 5ms, 마지막 JSON 직렬화가 30ms면 개발자는 보통 DB만 본다. 그런데 사용자 입장에서는 셋이 합쳐진 75ms가 진실이다. 그래서 저는 API 한 개를 볼 때도 쿼리, 애플리케이션 조합, 캐시 조회와 저장, 직렬화를 한 체인으로 본다.

가장 흔한 실수는 캐시를 성능 해결책이 아니라 불안감 해소 도구로 쓰는 거다. 느리니까 일단 Redis부터 넣고, 키 설계와 TTL은 나중에 생각한다. 그러면 처음 며칠은 빨라진다. 그다음부터는 invalidation 때문에 일관성이 흔들리거나, hot key 하나에 트래픽이 몰리거나, 캐시 직렬화 비용 때문에 CPU가 올라간다. 특히 큰 JSON blob를 통째로 캐시하면 조회는 빨라도 stringify와 parse 비용이 새로 생긴다.

DB도 비슷하다. ORM을 쓴다고 해서 병목이 추상화되진 않는다. N+1 문제, 불필요한 select list, 잘못 잡힌 pagination, 인덱스 없이 정렬하는 쿼리는 Node.js 코드가 아무리 깔끔해도 latency를 무너뜨린다. 저는 느린 route를 보면 먼저 SQL 개수와 total query time을 분리한다. 쿼리 한 번이 느린 건 인덱스나 실행 계획 문제고, 쿼리 수가 많은 건 애플리케이션 조립 방식 문제다. 둘은 해결 방법이 다르다.

실전 최적화는 대개 작은 세 가지 조합에서 나온다. 필요한 칼럼만 가져오기, aggregation을 DB에 맡기기, 응답 payload를 줄이기. 생각보다 여기서 끝나는 경우가 많다. 캐시는 마지막에 넣는 게 낫다. 먼저 데이터 양과 경로를 줄이고, 그다음 같은 결과가 반복되는 지점에만 캐시를 둔다. 이 순서를 지키면 메모리와 일관성 비용을 덜 낸다.

> 💡 **다음 챕터**: 그래도 한 프로세스 안에서 버티기 어렵다면 병렬화나 분리가 필요하다. Worker Threads, cluster, queue, 별도 서비스 중 무엇을 고를지 다음 챕터에서 비교한다.

Node.js 성능 최적화 Ch4 — 쿼리, 캐시, 직렬화를 같이 최적화한다

// COMMENTS

ON THIS PAGE