API 요청 목록이 느려질 때

API 엔드포인트가 처음엔 빨랐는데 시간이 지나면서 느려지거나, 특정 페이지에서만 느린 경우가 있다. 이런 상황은 보통 데이터량이 늘어났거나, validation 로직이 비효율적이거나, 데이터베이스 쿼리가 문제인 경우다.

현재 성능 확인

API 응답 시간을 직접 측정한다.

curl -i 'https://example.com/api/items?page=1'

응답 헤더의 Content-Length와 실제 응답 시간을 확인한다. 만약 응답이 몇 초 걸린다면 문제가 있는 것이다.

validation 로직 검토

API 요청 처리 순서를 파악한다:

1. 요청 파라미터 검증 - 페이지 번호, 정렬 기준 등이 올바른가
2. 권한 검증 - 사용자가 이 데이터에 접근할 권한이 있는가
3. 데이터베이스 쿼리 - 적절한 인덱스를 사용하는가
4. 응답 데이터 포맷팅 - 불필요한 필드 변환이 있는가

각 단계마다 시간이 얼마나 걸리는지 로그를 추가해서 측정해본다.

데이터베이스 쿼리 최적화

느린 쿼리를 찾는다. 만약 필터링할 컬럼이 인덱싱되지 않았다면, 쿼리가 전체 테이블을 스캔하게 된다.

SELECT * FROM items WHERE status = 'active' ORDER BY created_at DESC LIMIT 20;

this 쿼리가 느리다면:

• status 컬럼에 인덱스가 있는가
• created_at 컬럼에 인덱스가 있는가
• 페이지 번호가 매우 높을 때 (예: 1000번째 페이지) 특히 느려지는가

N+1 문제 확인

각 아이템마다 추가 쿼리를 실행하는 N+1 문제가 없는지 확인한다. 예를 들어 아이템 100개를 가져올 때, 각 아이템의 작성자 정보를 위해 100번의 추가 쿼리를 하면 매우 느려진다.

응답 크기 확인

한 번에 반환하는 데이터 크기를 줄인다:

1. 필요한 필드만 선택 (SELECT * 대신 명시적으로)
2. 한 페이지당 아이템 수 조정
3. 관계 데이터는 ID만 반환하고, 필요할 때만 상세 조회

최종 확인

1. 같은 파라미터로 여러 번 요청해서 캐싱이 작동하는지 확인
2. 다양한 페이지 번호로 테스트 (특히 높은 페이지)
3. 로그나 모니터링에서 병목 지점 추적

작은 최적화가 쌓이면 전체 성능이 크게 개선된다.