이번에는 서버 운영을 맞춰, 설계한 파이프라인에 대해 글을 써보려고 합니다!처음에는 FastAPI 하나에 OCR 로직까지 모두 넣어서 빠르게 기능을 구현했습니다.(원래는 Redis + Celery 로 워커를 도입하려 했는데, 초기 PoC 단계에서는 추후 구현으로 둬야된다 하셔서 FastAPI 하나에 임베딩 모델 , OCR 로직도 나 넣었음... )하지만 실제로 서버를 운영해보니, 이 구조로 발생했던 문제가 Requirement 를 Docker 이미지에 설치하는데에서 발생하더라구요,기존에 FastAPI 는 서비스 레이어 로직 정도로만 구현해놨었고, Worker 를 따로 분리할 생각이었어서 ML 에 익숙한 라이브러리를 선택하는 것 보다 서비스 레이어 딴에 맞춰진 라이브러리들로 구성을 해놨었습니다. 다만, O..

FastAPI는 Python 기반이라 AI 모델 서빙용으로 많이 사용됩니다. (우선 제가 보통 FastAPI 를 그런 용도로 쓰기 때문에...ㅎㅎ)개발하다 보면 자연스럽게 이런 욕심이 생깁니다."사용자가 PDF를 올리면, BackgroundTasks로 넘겨서 OCR 돌리고 벡터 DB에 넣으면 되겠지?" 결론부터 말씀드리면, 토이 프로젝트면 괜찮지만 , 실무라면 서버가 위험해지더라구욥.... (갑자기 끊김..) 단순한 I/O 작업(이메일)과 CPU/GPU 집약적 작업(AI Inference)의 차이 때문일까요? 그런 거 같습니다.1. AI 작업, 기다리기??BackgroundTasks가 가볍고 좋은 이유는 주로 I/O Bound(네트워크 대기, 디스크 쓰기) 작업에 최적화되어 있기 때문입니다. 하지만 A..

[FastAPI] 미들웨어 - 작동 원리부터 ELK 연동을 위한 JSON 구조화 로깅까지FastAPI로 백엔드를 개발하다 보면 "모든 요청의 처리 시간을 재고 싶다"거나 "들어오는 모든 요청의 Body 데이터를 로그로 남기고 싶다"는 욕심이 생깁니다. 오늘은 FastAPI의 숨은 조력자 미들웨어(Middleware)의 모든 것을 파헤쳐 보고, 실무에서 ELK Stack이나 Sentry와 연동 가능한 'JSON 구조화 로깅' 미들웨어를 직접 구현해 보겠습니다.1. 미들웨어 아키텍처 클라이언트의 요청(Request)은 핵심 로직(API 엔드포인트)에 도달하기 위해 여러 겹의 미들웨어를 뚫고 들어갑니다. 처리가 끝나면 응답(Response)은 다시 그 미들웨어들을 거꾸로 통과해서 나갑니다.주의: 등록 순서..

1. 왜 미들웨어가 필요할까? FastAPI로 서버를 개발하다 보면 모든 API 엔드포인트에 공통적으로 적용해야 하는 기능들이 생깁니다. 예를 들어볼까요?"모든 API 요청에 대해 응답 속도를 측정하고 싶다.""들어오는 모든 요청(Request)의 헤더를 검사해서 보안을 강화하고 싶다.""서버에서 나가는 모든 응답(Response)에 특정 헤더를 추가하고 싶다."이런 기능을 구현하기 위해 수십, 수백 개의 API 함수마다 똑같은 코드를 반복해서 적는 것은 비효율적이며 유지보수를 지옥으로 만드는 지름길입니다. 이때 필요한 것이 바로 미들웨어(Middleware)입니다.오늘은 FastAPI의 기능 중 하나인 미들웨어의 개념과 작동 원리, 그리고 제가 사용하는 다양한 구현 패턴을 기록해보려고 합니당.2. 미..

[FastAPI] BackgroundTasks 심층 분석: 0.1초 응답의 비밀과 치명적 한계 (vs Celery, Custom Loop) FastAPI를 사용하는 가장 큰 이유 중 하나는 '비동기 처리를 통한 빠른 성능'입니다.하지만 API를 개발하다 보면 시간이 오래 걸리는 작업들을 마주하게 됩니다.회원가입 환영 이메일 발송 (SMTP 통신: 1~3초)이미지 업로드 후 썸네일 생성 (CPU 연산: 0.5~2초)외부 API로 로그 전송 (네트워크 I/O: 가변적)이때 사용자를 기다리게 하지 않고 "응답은 즉시(0.1초), 작업은 뒤에서" 처리하는 기술이 바로 BackgroundTasks입니다.하지만 이 기능은 만능이 아니며, 잘못 사용했다가는 서버 전체가 멈추거나 중요한 데이터가 증발할 수 있습니다.오..

저는 FastAPI를 사용하여 백엔드 API 서버를 구축하고 있었습니다. 데이터베이스 모델을 설계하고, 비즈니스 로직을 구현하고, 엔드포인트 별로 Pydantic 스키마를 정의하는 과정은 꽤나 순조로웠습니다. 구현된 기능 하나하나를 Swagger UI(Docs)와 Postman을 통해 테스트했고, 예상한 대로 완벽하게 JSON 데이터가 오고 가는 것을 확인했습니다. 제 로컬 환경의 Postman에서는 정상적으로 200 OK 응답을 받았으나, 크롬 개발자 도구의 콘솔 창은 붉은색 에러 메시지로 가득 차 있었습니다. 그리고 그 에러 로그 속에는 CORS 에러가 찍혀있었습니다. Access to XMLHttpRequest at 'http://localhost:8000/api/items' from orig..

최근 인턴 활동을 하며 회사 내의 폐쇄형 LLM 을 모델로 사용해, RAG 를 구축한 챗봇 서비스에 투입 되어 일을 맡고 있습니다. 어떤 아키텍처가 적합할지 고민을 하다가 제가 지금까지 어떤식으로 아키텍처를 설계해왔는지 AI 모델 서빙과 관련해 정리를 해볼까 합니다. (원래 하이브리드 서버 를 좋아하는 편이라 더 적합하지 않는 것일 수도 있어요 .. 하지만 정리는 좋은 거니까! ) 단순 AI 모델 서빙이라면 SpringBoot + FastAPI , 또는 Only FastAPI 로도, 이 구조만으로도 80%의 요구사항은 해결된다 생각하긴 합니다. 텍스트 감성 분석, 간단한 추천 시스템, 데이터 전처리 같은 작업은 HTTP 요청 한 번으로 충분하죠. 하지만 서비스가 성장하고 요구사항이 고도화되면, 우리는 '..

저는 하나의 언어나 프레임워크를 고집하기보다, 프로젝트의 성격에 맞춰 Spring Boot, Django, FastAPI를 자유롭게 오가는 편입니다. 사실 저의 첫 웹 개발은 대학교 1학년 때 배운 Python과 Django로 시작되었습니다. 하지만 실무를 경험하며 복잡한 비즈니스 로직을 처리할 때는 Spring Boot가 주는 견고함에 매료되었죠. 강력한 트랜잭션 관리, 익숙한 JPA, 그리고 DI 컨테이너가 주는 안정감은 대규모 서비스를 구축할 때 대체 불가능한 도구였습니다. 하지만, 서비스에 'AI'와 'LLM'이 들어오면서 상황은 다시 바뀌었습니다. 최근 ChatGPT API(OpenAI)를 래핑(Wrapping)해서 함수 호출 서버를 만들거나, 직접 학습시킨 모델을 서빙해야 하는 일이 많아졌습니..

PaddleOCR과 같은 딥러닝 라이브러리는 C++로 컴파일된 바이너리에 의존하기 때문에 CPU 아키텍처(x86 vs ARM)에 매우 민감합니다. 이 점을 강조하며 docker buildx가 왜 필요한지 실무에서 발생했던 문제 상황을 어떻게 해결했는지 정리했습니다. 최근 회사에서 운영 중인 RAG(Retrieval-Augmented Generation) 서비스를 위해 FastAPI와 PaddleOCR을 사용한 OCR 서버를 Docker 컨테이너로 띄워 사용하고 있었습니다.서비스가 안정화되면서 서버를 이전해야 할 일이 생겼는데, 여기서 예상치 못한 치명적인 문제가 발생했습니다."기존 서버(Intel/AMD)에서 잘 돌아가던 도커 이미지가, 새 서버(ARM/AWS Graviton/Mac M1 등)에서는 실행..

FastAPI 의존성 주입(DI) 마스터 시리즈 (2부)안녕하세요! 지난 1부에서는 우리가 API를 개발하며 겪는 문제점들과, 이를 해결하기 위한 의존성 주입(DI) 의 개념에 대해 알아보았습니다. 이번 2부에서는 FastAPI가 제공하는 강력한 도구인 Depends를 사용하여 직접 코드를 작성해 보겠습니다. 가장 기초적인 매개변수 주입부터 시작해서, 실무에서 필수적인 DB 세션 관리(yield)와 보안 인증까지 단계별로 정복해 봅시다!1. 기초: Depends로 공통 매개변수 중복 없애기API를 만들다 보면 페이징(Paging)이나 검색 기능처럼 여러 엔드포인트에서 똑같은 쿼리 매개변수를 받아야 할 때가 많습니다.1.1. 기존 방식의 문제점DI를 쓰지 않으면 모든 함수마다 똑같은 코드를 복사해야 합니..

FastAPI 의존성 주입(Dependency Injection) 심층 분석: 왜, 그리고 어떻게 사용하는가? 이번 포스팅에서는 FastAPI를 빠르고 견고하게 만들어주는 핵심 원리, 의존성 주입(Dependency Injection, DI) 시스템에 대해 심도 있게 알아보겠습니다. 현재 여러분이 겪고 있는 API 서버 개발의 문제점과 DI가 어떻게 그 해답을 제시하는지 명확히 이해하실 수 있을 것입니다.1. 복잡성 증가! 기존 API 서버 개발의 문제점프로젝트가 커질수록 API 서버 개발자는 다음과 같은 근본적인 어려움에 직면하게 됩니다.1.1. 복잡해지는 경로 함수와 공통 로직 관리게시판, 사용자 인증, 결제 처리 등 다양한 기능을 구현하다 보면, 실제 비즈니스 로직 외에도 여러 엔드포인트에서 공..