게시글 조회 성능 최적화(N+1) 및 렌더링 예외 처리

게시글 목록 조회 시 발생하는 속도 저하 문제를 해결하기 위해 데이터베이스 쿼리 효율성을 점검했다. ORM 사용 시 빈번하게 발생하는 N+1 문제를 식별하고 joinedload를 적용하여 성능을 최적화했다. 또한 개발 테스트 데이터로 인해 발생하는 이미지 로딩 오류를 프론트엔드 예외 처리 로직으로 해결했다.

게시글 목록 조회 지연과 N+1 문제 식별

서버리스(AWS Lambda) 환경의 Cold Start 영향을 제외하고도, 게시글 목록 로딩 시 비정상적인 딜레이가 관측되었다. crud_community.py의 get_posts 함수 실행 계획을 분석한 결과, 전형적인 N+1 문제가 발생하고 있음을 확인했다.

게시글 목록을 가져오는 1번의 쿼리 이후, 각 게시글(Post)의 작성자(User) 정보를 조회하기 위해 게시글 개수(N)만큼의 추가 SELECT 쿼리가 실행되고 있었다. 이는 게시글 10개를 렌더링하기 위해 총 11번의 DB 네트워크 통신을 유발하여 전체 응답 속도를 저하시키는 원인이 되었다.

Eager Loading 적용 및 정렬 로직 구현

문제를 해결하기 위해 SQLAlchemy의 joinedload 옵션을 사용하여 Eager Loading(즉시 로딩)을 적용했다. 이는 메인 쿼리 실행 시 SQL JOIN 문을 생성하여 연관된 테이블(User)의 데이터를 단일 트랜잭션으로 가져오는 방식이다.

Python

 

# 수정 전: Lazy Loading으로 인한 N+1 발생
def get_posts(db: Session, skip: int = 0, limit: int = 10):
    return db.query(Post).offset(skip).limit(limit).all()

# 수정 후: Eager Loading 적용
from sqlalchemy.orm import joinedload

def get_posts(db: Session, skip: int = 0, limit: int = 10):
    return db.query(Post)\
        .options(joinedload(Post.author))\
        .order_by(Post.created_at.desc())\
        .offset(skip).limit(limit).all()

코드를 수정한 결과 쿼리 실행 횟수가 11회에서 1회로 감소했으며, 네트워크 왕복 비용(RTT)이 줄어들어 체감 로딩 속도가 개선되었다. 추가적으로 order_by 구문을 명시하여 게시글 최신순 정렬 기능도 함께 구현했다.

테스트 데이터 이미지 404 에러 처리

성능 최적화와 별개로 브라우저 콘솔에 이미지 관련 404(Not Found) 에러가 다수 발생하는 현상을 확인했다. 개발 단계에서 Swagger UI 테스트 시 이미지 필드의 기본값인 문자열 "string"이 DB에 그대로 저장된 것이 원인이었다.

운영 DB 데이터 클렌징에 앞서, PostCard 컴포넌트에 이미지 URL 유효성 검증 로직(post.image !== "string")을 추가하여 잘못된 요청을 클라이언트 단에서 차단했다.

Insight

ORM의 Lazy Loading 특성은 코드를 간결하게 만들지만, 연관 관계가 있는 데이터 목록 조회 시 치명적인 성능 저하를 유발할 수 있음을 확인했다. joinedload와 같은 옵션을 통해 쿼리 실행 시점을 명시적으로 제어해야 한다. 또한 더미 데이터나 유효하지 않은 입력값에 대한 처리는 백엔드의 데이터 정제뿐만 아니라, 프론트엔드의 방어 코드(Defensive Programming)가 병행되어야 안정적인 서비스를 유지할 수 있다.