성능 문제의 80%는 생각보다 단순하다

성능 문제의 80%는 생각보다 단순하다

성능 문제가 발생하면 우리는 자연스럽게 복잡한 원인을 떠올린다. 분산 시스템의 병목, 네트워크 지연, 락 경합, GC 튜닝 같은 것들이다. 그래서 프로파일링 도구를 붙이고, 인프라를 점검하고, 구조를 다시 설계해야 할 것 같은 느낌을 받는다. 하지만 실제로 현장에서 마주하는 성능 문제의 상당수는 그렇게 거창하지 않다. 오히려 아주 기본적인 부분에서 발생하는 경우가 훨씬 많다.

대표적인 사례가 N+1 쿼리다. 리스트를 조회한 뒤, 각 요소마다 추가 쿼리를 날리는 구조는 코드 상에서는 자연스럽게 보일 수 있다. 하지만 데이터가 늘어나는 순간, 쿼리 수가 기하급수적으로 증가하면서 성능이 급격히 나빠진다. 문제는 이 패턴이 코드 리뷰 단계에서는 쉽게 눈에 띄지 않는다는 점이다. 실제 데이터 규모에서 테스트해보기 전까지는 잘 드러나지 않는다.

또 다른 흔한 원인은 불필요한 반복이다. 이미 한 번 계산한 값을 다시 계산하거나, 같은 데이터를 여러 번 순회하는 구조는 생각보다 자주 등장한다. 작은 데이터에서는 문제가 없지만, 처리량이 커지는 순간 비용이 눈덩이처럼 불어난다. 특히 중첩 루프 안에서 발생하는 연산은 단순한 코드 몇 줄로도 큰 병목을 만들 수 있다.

과도한 직렬화도 자주 간과되는 문제다. 객체를 JSON으로 변환하고, 다시 파싱하는 과정은 편리하지만 비용이 적지 않다. 특히 대량의 데이터를 주고받는 상황에서는 이 변환 과정 자체가 병목이 된다. 필요 이상의 필드를 포함하거나, 불필요하게 깊은 구조를 유지하는 것도 성능에 영향을 준다.

흥미로운 점은 이런 문제들이 대부분 “복잡한 최적화” 없이도 해결된다는 것이다. N+1 쿼리는 적절한 조인이나 배치 조회로 해결할 수 있고, 반복 계산은 캐싱이나 구조 변경으로 줄일 수 있다. 직렬화 문제도 데이터 구조를 단순화하거나 필요한 필드만 전송하는 방식으로 개선할 수 있다. 즉, 근본적인 해결책은 대개 기본에 있다.

이런 문제들이 반복되는 이유는 성능을 “나중에 고려할 것”으로 미루는 경우가 많기 때문이다. 기능이 먼저고, 성능은 나중이라는 접근 자체는 현실적이다. 하지만 기본적인 비용 구조를 이해하지 않은 채 코드를 작성하면, 나중에 수정해야 할 범위가 훨씬 커진다.

또 하나 중요한 포인트는 측정이다. 막연히 “느린 것 같다”는 느낌만으로는 정확한 원인을 찾기 어렵다. 실제로 어디에서 시간이 쓰이고 있는지를 확인해보면, 예상과 전혀 다른 지점이 병목인 경우도 많다. 그래서 간단한 로그나 프로파일링만으로도 문제의 상당 부분을 빠르게 좁힐 수 있다.

결국 성능 최적화의 시작은 복잡한 기술이 아니라, 기본적인 패턴을 점검하는 것이다. 쿼리가 얼마나 발생하는지, 데이터가 몇 번 순회되는지, 불필요한 변환이 없는지를 확인하는 것만으로도 많은 문제를 해결할 수 있다.

그래서 성능 문제가 생겼을 때는 한 번쯤 이렇게 생각해볼 필요가 있다.
이게 정말 복잡한 문제일까, 아니면 우리가 이미 알고 있는 단순한 문제일까.
그 질문에서 출발하면, 해결의 방향도 훨씬 명확해진다.