imageLab

사전 학습 모델을 실행하는 스크립트를 넘어, 반복 요청과 결과 전달까지 처리하는 작은 이미지 처리 서버를 실험했습니다.

Why I built it

배경 제거와 업스케일링 모델은 각각 실행할 수 있었지만, 실제 기능으로 사용하려면 무거운 가중치를 언제 준비하고 재사용할지, 투명도와 이미지 포맷을 어떻게 보존할지, 요청 중 생긴 파일을 언제 정리할지까지 함께 다뤄야 했습니다.

imageLab은 이 문제를 모델 수명 주기와 요청 파일 수명 주기를 분리한 API 파이프라인으로 정리한 실험입니다.

How it works

FastAPI의 /process endpoint가 이미지 URL과 bg_remove, upscale, both 중 하나를 받습니다. U²-Net은 전경 mask와 알파 채널을 만들고, Real-ESRGAN은 CUDA·Apple MPS·CPU 중 사용 가능한 장치에서 이미지를 확대합니다. 두 작업을 함께 선택하면 업스케일 결과에서 배경을 제거합니다.

서버 시작 단계에서 모델 가중치를 확인하고 두 모델을 미리 로드해 요청마다 재초기화하지 않습니다. 결과는 Content-Type과 투명도를 보존해 S3에 올리고, 1시간 동안 유효한 URL로 반환합니다.

Key decisions

• 모델 구현, API 흐름, 저장소 처리를 분리해 각 경계를 독립적으로 바꿀 수 있게 했습니다.
• 배경 제거 결과는 PNG로 고정하고, 업스케일 결과는 가능한 경우 입력 포맷을 유지했습니다.
• 원본·중간·최종 임시 파일을 요청 단위로 만들고 성공과 실패 모두에서 정리했습니다.
• 초기 Lambda·CDK 초안 대신, 큰 가중치를 메모리에 유지하기 쉬운 FastAPI·Uvicorn 상시 서버로 실행 구조를 바꿨습니다.

Limits and learnings

저장소에는 처리 속도, 비용, 이미지 품질이나 동시 요청 부하를 비교한 벤치마크가 없습니다. 따라서 이 작업은 운영 성능을 입증한 서비스보다 두 모델을 반복 가능한 서버 파이프라인으로 연결하고 실행 경계를 검증한 프로토타입에 가깝습니다.

모델 자체만큼 가중치 준비, 포맷 계약과 임시 파일 정리가 반복 실행의 안정성을 좌우한다는 점을 확인했습니다. 배포 방식도 유행보다 모델 크기와 추론 시간, 캐시 방식에 맞춰 선택해야 했습니다.