이미지 처리: 동기 리사이징 vs 백그라운드 큐, AI 웹앱에서 사용자 업로드를 빠르게 처리하는 방법

사용자 업로드 이미지, 어떻게 처리할 것인가

사용자가 프로필 사진을 업로드했을 때 일어나는 일을 생각해보자. 원본 이미지는 용량이 큰 경우가 많다. 이를 그대로 저장하면 스토리지 비용이 늘어나고, 웹에서 로드 시간이 길어진다. 그래서 대부분의 웹앱은 여러 크기의 썸네일(예: 200×200px, 400×400px)을 자동으로 만든다.

문제는 언제 이 리사이징을 할 것인가다. 업로드 직후 즉시 처리할 수도 있고, 백그라운드에서 천천히 처리할 수도 있다. 선택에 따라 사용자가 느끼는 속도와 서버 자원 사용이 크게 달라진다.

동기 리사이징: 빠른 응답의 환상

동기 리사이징은 업로드 요청이 들어오면 서버가 이미지를 즉시 처리하고 모든 썸네일을 만든 후 응답을 보낸다.

# 동기 방식 예시 (Flask)
@app.route('/upload', methods=['POST'])
def upload_image():
    file = request.files['image']
    original_path = save_file(file)  # 원본 저장
    
    # 즉시 리사이징 시작
    resize_and_save(original_path, 200)   # 썸네일 1
    resize_and_save(original_path, 400)   # 썸네일 2
    resize_and_save(original_path, 800)   # 썸네일 3
    
    return {'status': 'success'}, 200

장점:

• 응답 후 즉시 모든 이미지가 준비됨
• 코드가 단순하고 디버깅이 쉬움
• 작은 이미지나 트래픽이 적은 서비스에 충분

단점:

• 이미지가 클수록 응답 시간이 길어짐
• 그 동안 서버 스레드/프로세스가 점유됨
• 동시 업로드가 몰리면 그만큼 서버가 오래 바쁨
• AI 모델 추론이 필요하면 더 악화됨 (이미지 분류, 객체 감지 등)

백그라운드 큐: 빠른 응답과 안정성

백그라운드 큐는 업로드 요청을 즉시 받고, 리사이징 작업을 큐에 넣은 후 바로 응답을 보낸다. 별도의 워커가 큐에서 작업을 꺼내 처리한다.

# 백그라운드 큐 방식 예시 (Celery + Redis)
from celery import shared_task

@shared_task
def process_image(image_path):
    """워커가 실행할 작업"""
    resize_and_save(image_path, 200)
    resize_and_save(image_path, 400)
    resize_and_save(image_path, 800)
    # AI 추론도 여기서 가능

@app.route('/upload', methods=['POST'])
def upload_image():
    file = request.files['image']
    original_path = save_file(file)
    
    # 큐에 작업 추가 (즉시 반환)
    process_image.delay(original_path)
    
    return {'status': 'pending', 'image_path': original_path}, 202

장점:

• 업로드 응답이 빠름 (파일 저장만 함)
• 서버 메인 스레드가 다른 요청 처리 가능
• 동시 업로드가 몰려도 요청을 먼저 받아두고 워커가 차례로 처리함 (워커 수로 처리 속도 조절)
• 작업 실패 시 자동 재시도 가능
• AI 추론처럼 무거운 작업도 안정적으로 처리

단점:

• 클라이언트가 최종 완료를 기다려야 함 (폴링 또는 웹소켓)
• 큐 시스템(Redis, RabbitMQ) 추가 필요
• 아키텍처가 복잡해짐

실제 상황별 선택 기준

동기 리사이징을 쓸 때:

• 이미지 크기가 작음
• 트래픽이 매우 적음
• MVP 단계에서 빠르게 만들어야 할 때
• 리사이징만 필요하고 AI 처리는 없을 때

백그라운드 큐를 쓸 때:

• 이미지 크기가 크거나 업로드가 많음
• AI 모델 추론이 필요함 (분류, 태그 생성, 객체 감지)
• 사용자 경험을 우선시할 때
• 서버 안정성이 중요할 때
• 동시 업로드가 많을 때

하이브리드 접근:
일부 서비스는 둘을 섞는다. 예를 들어 가장 작은 썸네일(200×200)은 동기로 만들고, 나머지는 백그라운드에서 처리한다. 사용자는 빠르게 작은 이미지를 보고, 큰 이미지는 조금 나중에 로드된다.

백그라운드 큐 구축의 실제 난제

백그라운드 큐를 도입하면 새로운 문제가 생긴다:

• 상태 추적: 클라이언트가 처리 완료를 어떻게 알 것인가? 폴링하면 서버 부하가 늘고, 웹소켓은 복잡하다.
• 실패 처리: 워커가 중간에 죽으면? 작업이 손실될 수 있다. 큐 시스템이 영속성을 보장해야 한다.
• 순서 보장: 여러 워커가 동시에 작업하면 완료 순서가 뒤바뀔 수 있다.
• 모니터링: 큐에 작업이 쌓이고 있지는 않은지, 워커가 제때 처리하는지 감시해야 한다.

Redis는 간단하지만 영속성 설정에 따라 데이터 손실 위험이 있고, RabbitMQ는 안정적이지만 운영이 복잡하다. 클라우드 환경에서는 AWS SQS, Google Cloud Tasks 같은 관리형 큐 서비스를 고려할 수 있다.

성능 비교: 무엇이 달라지나

가정해보자. 사용자가 이미지를 업로드하고 서버가 썸네일 3개를 만든다고 하자.

동기 방식: 리사이징이 끝날 때까지 응답이 돌아오지 않고, 그동안 서버 워커가 점유된다. 동시 업로드가 늘면 뒤의 요청은 대기하게 된다.

백그라운드 큐: 파일을 저장한 직후 바로 응답하고, 리사이징은 워커가 뒤에서 처리한다. 사용자는 완료될 때까지 '처리 중' 상태를 보게 된다.

트래픽이 늘수록 이 차이는 커지고, 백그라운드 큐가 유리해진다.

초보자도 백그라운드 큐를 도입할 수 있나요?

Python 개발자라면 Celery + Redis 조합이 표준이다. 하지만 학습 곡선이 가파르다. 더 간단한 대안으로 Python-RQ가 있다. 또는 클라우드 함수(AWS Lambda, Google Cloud Functions)를 쓰면 인프라 관리 없이 백그라운드 작업을 실행할 수 있다. 비용 구조는 다르지만 운영 복잡도는 낮다.

동기 처리로 시작해도 나중에 큐로 바꿀 수 있나요?

가능하지만 비용이 든다. 코드를 리팩토링해야 하고, 큐 시스템을 도입해야 하며, 테스트도 다시 해야 한다. 그래서 처음부터 아키텍처를 고려하는 것이 낫다. 작은 프로젝트라도 백그라운드 큐 구조를 염두에 두면 나중에 확장이 쉽다.

리사이징 외에 백그라운드에서 할 수 있는 작업은?

AI 웹앱이라면 이미지 분류, 태그 자동 생성, 객체 감지, 얼굴 인식 등을 백그라운드에서 처리할 수 있다. 또한 썸네일 생성 후 CDN에 업로드하거나, 데이터베이스에 메타데이터를 저장하는 작업도 포함된다. 백그라운드 큐는 이미지 처리뿐 아니라 모든 무거운 작업의 표준 패턴이다.

결론: 서비스 규모에 맞는 선택

이미지 처리는 단순해 보이지만 서버 부하와 사용자 경험의 균형을 맞추는 중요한 결정이다. 작은 프로젝트는 동기로 시작해도 되지만, AI 처리처럼 오래 걸리는 작업이 있거나 트래픽이 늘 가능성이 있다면 처음부터 큐 구조를 염두에 두고 설계하는 것이 좋다.

직접 프로젝트에 적용해보고 싶다면, Vibeollio에 프로젝트를 등록해서 실제 사용자 피드백을 받아보자. 다른 개발자들의 댓글을 통해 어떤 아키텍처가 더 효과적인지, 어떤 도구를 선택했는지 배울 수 있다.