Back-end web performance 컨설턴트

TTFB, 성능의 유리천장

Time To First Byte는 전체 렌더링 체인의 최저점을 결정합니다. 서버가 응답하기 전까지 브라우저는 아무것도 시작할 수 없습니다. TTFB가 800 ms라면 front-end가 완벽히 최적화되어 있어도 LCP는 1.5~2초 아래로 내려가기 어렵습니다.

이건 제가 감사(audit)에서 정기적으로 확인하는 사실입니다: 팀들이 lazy loading과 이미지 압축에 몇 주를 투자하지만, 진짜 병목은 카테고리 페이지에서 서버 응답 시간이 1.2초 걸리는 경우입니다. back-end가 처리되지 않는 한, front-end 최적화는 효과가 제한적입니다.

흔한 원인

back-end 성능 문제는 프로젝트마다 비슷합니다. N+1 쿼리 때문에 50개 상품 카탈로그를 표시하는 일이 데이터베이스 호출 200번으로 변하는 경우. 설정은 되어 있지만 너무 자주 무효화되거나 아예 무효화되지 않는 애플리케이션 cache. ERP, 검색 엔진, 재고 서비스 같은 서드파티 API에 대한 동기 호출 — 응답이 오기 전까지 렌더링을 가로막습니다.

Instrumentation이 출발점입니다. 요청 내부에서 무슨 일이 일어나는지 보이지 않으면, 우리는 추측합니다. Dynatrace, Datadog, NewRelic — 도구는 중요하지 않습니다. 중요한 것은 HTTP 요청을 end-to-end로 추적하고 시간이 정확히 어디서 소모되는지 보는 것입니다. e-commerce checkout에서 "서버가 8초 걸린다"와 "서버가 8초 걸리는데 그 중 5초는 ERP 응답을 기다린다"의 차이는 접근을 완전히 바꿉니다.

Cache와 무효화 전략

cache는 아마도 back-end에서 가장 강력하면서도 가장 과소활용되는 레버입니다. 잘 구성된 page cache는 트래픽이 많은 페이지에서 TTFB를 10배까지 줄일 수 있습니다. 하지만 진짜 복잡성은 무효화에 있습니다 — 가격이 바뀔 때, 상품이 품절될 때, 프로모션이 시작될 때.

제가 보는 대부분의 구현은 지나치게 공격적입니다(5분 cache로 오래된 가격을 제공), 혹은 지나치게 보수적입니다(매 변경마다 전역 무효화 — 사실상 cache가 없는 것과 같습니다). 효과적인 전략은 세분화되어 있어야 합니다 — 바뀐 것만 정확히 무효화하고, 전체 카탈로그는 건드리지 않습니다.

성능과 인프라 비용

요청당 CPU 사용량이 적은 back-end는 동일한 트래픽을 흡수하는 데 더 적은 서버가 필요합니다. 사용량 기반으로 과금되는 cloud 아키텍처에서는 코드 최적화가 청구서에 곧바로 반영됩니다. 최적화된 SQL 쿼리, 효율적인 cache, 병렬화된 외부 호출 — 모두 비용으로 환산됩니다. 사용자 체감 성능 향상은 비용 절감에 비하면 거의 보너스에 가깝습니다.