28초 걸린 사용자 조회 API 병목 분석

관리 플랫폼의 사용자 조회 API가 약 2,000건을 가져오는 데 28초 정도 걸렸습니다. 필터 조건을 넣은 요청은 64초가 걸렸고, 전체 조회에서는 504 응답이 발생했습니다.

요청 하나의 응답 시간만 보면 어디를 먼저 고쳐야 할지 알기 어려웠습니다. Splunk 로그에서 같은 trace_id를 따라가며 서비스별 소요 시간을 확인하고 코드를 대조했습니다. 이 글의 범위는 병목 분석과 개선안 정리까지입니다.

클라이언트 대기 시간과 백엔드 처리 시간

64초가 걸린 요청을 추적했을 때 백엔드에는 다음 기록이 남아 있었습니다.

세 구간의 합은 약 147.2초입니다. 이 비율은 브라우저에서 기다린 64초가 아니라 백엔드 구간 기록을 기준으로 계산한 값입니다.

BFF의 Read Timeout은 60초였지만 뒤쪽 서비스는 그 이후에도 처리를 계속하고 있었습니다. 클라이언트에서 요청이 끝난 시각과 백엔드의 처리 완료 시각이 달라, 한쪽 로그만 보면 실제로 오래 걸린 구간을 놓칠 수 있었습니다.

외부 서비스의 사용자별 반복 호출

목록을 조회한 뒤 사용자마다 부가 정보를 가져오고 있었습니다. 조회한 사용자가 늘면 외부 HTTP 호출도 같은 수만큼 늘어나는 구조였습니다. 가장 긴 상태별 조회에서는 이 반복 호출이 큰 비중을 차지했습니다.

먼저 외부 서비스가 배치 조회를 제공하는지 확인할 필요가 있었습니다. 지원한다면 ID를 모아 여러 사용자의 정보를 한 번에 가져올 수 있습니다. 다만 한 번에 받을 수 있는 개수와 응답 형식에 따라 배치를 나누는 처리가 필요할 수 있습니다.

배치 API를 사용할 수 없다면 캐시도 후보였습니다. 반복 요청을 줄일 수 있지만 갱신 주기와 오래된 정보를 허용할 범위를 정해야 합니다. 아직 적용하지 않아 실제로 얼마나 빨라질지는 확인하지 못했습니다.

연관 데이터의 추가 쿼리

사용자 목록에서는 역할과 소속 같은 연관 데이터를 추가로 조회하고 있었습니다. 당시 분석에서는 건당 약 14~15ms의 비용이 목록 크기에 따라 누적되는 부분을 찾았습니다.

Fetch Join과 Entity Graph를 개선 후보로 검토했습니다. 두 방법을 적용한다고 실제 SQL이 항상 하나가 되는 것은 아닙니다. 필요한 데이터와 관계에 맞춰 가져오는 범위를 정하고, 생성된 SQL과 호출 수를 다시 확인해야 합니다.

이 비용과 앞의 외부 호출 시간은 서로 다른 조회 경로에서 분석한 내용입니다. 모든 수치를 같은 요청의 시간처럼 더하지 않았습니다.

서버에서 처리할 조회 범위

DB 조회에는 최대 건수 제한이 있었지만, 화면에서 사용할 페이지를 서버가 나눠 반환하는 구조는 아니었습니다. 프런트엔드가 전체 결과를 받은 뒤 페이지를 나눠 보여주고 있었습니다.

서버 페이지네이션을 도입하면 한 번에 읽고 전송할 양을 줄일 수 있습니다. 대신 화면의 검색·정렬 조건도 서버 조회와 맞춰야 합니다. 페이지네이션만 추가해도 모든 타임아웃이 사라진다는 뜻은 아닙니다. 페이지 안에서 사용자별 외부 호출이 계속되면 해당 비용은 남습니다.

개선 순서

분석 결과 사용자별로 반복되는 외부 호출을 먼저 줄이고, 연관 데이터 조회와 서버 페이지네이션을 이어서 검토하는 순서로 정리했습니다. 클라이언트의 대기 시간이 끝난 뒤에도 백엔드 처리가 계속되고 있다는 점도 확인했습니다.

여기까지는 병목을 찾고 개선 순서를 정한 결과입니다. 배치 조회·캐시·Fetch Join 등을 적용해 응답 시간이 얼마나 줄었는지 확인한 기록은 아니므로, 실제 개선 효과는 변경 후 같은 조회 조건으로 다시 비교해야 합니다.

이 글로 Identity Platform 시리즈의 성능 분석 부분을 마칩니다. 전체 흐름은 시리즈 허브에서 볼 수 있습니다.