우선 현재는 개발단계기 때문에 모니터링 환경 (Prometheus/Grafana, ELK, Cloud Logging 등등,,,) 전혀 구축을 하지 않았으며, 클라우드 인프라를 이용하지 않고 온프레미스를 구축 중입니다.즉 , 로깅을 직접 해야된다는 뜻..사실 개발은 여러 개발자, 여러 서버를 각자 개인의 개발자가 확인해서 문제를 잡으면 되지만,, 전체 흐름에서 언제 터지는지 확인을 하는게 에러 잡기 가장 편하더라구요. 또한, 저희는 엔진엑스도 분리된 서버에 있고, 요청이 여러 대의 서버를 거쳐 들어오기 때문에“어디서 터졌는지”를 감으로 찾는 게 불가능해집니다. 특히 운영 중에는 “에러가 났다”보다 더 무서운 게, 에러가 났는데 어느 지점에서 문제가 시작됐는지 추적이 안 되는 상황이더라구요. 그래서 저는 이..

사내 챗봇/LLM 기능을 붙이면서, 답변을 한 번에 반환하는 게 아니라 토큰(혹은 chunk) 단위로 프론트에 흘려주는 SSE(또는 스트리밍 응답)를 구현해야 했습니다!(기존에 MVP 용으로 개발했던 FastAPI 서버를 다 버리고 다시 새롭게 구현..ㅜㅜ.이제는 처음부터 끝까지 제가 하나씩 고쳐가고 패키지 구조를 잡고, common 모듈로 분리할 수 있고,, 재사용성을 고려한 코드 설계를 할 수 있다는 장점이 보였지만..Spring 쪽을 하며 Fast 쪽도 하려니 조금 힘들 거 같아, SpringBoot 추가 기능 개발은 제 손을 떠나갔습니다..다만 FastAPI 로 MVC를 구현하는 것은 좀 오랜만이라 공부하며 하다보니 느릿느릿하게 개발하게 된 듯.. ) FastAPI에서 StreamingRespon..

[FastAPI] 30명 동시 접속 RAG 챗봇, 왜 FastAPI 비동기(Async)가 필수일까?일반적인 웹 서비스의 응답 속도는 0.1초 내외로 매우 빠릅니다. 하지만 LLM(거대 언어 모델) + RAG(검색 증강 생성) 기반의 챗봇은 이야기가 다릅니다. 답변 하나를 만드는 데 짧게는 3초, 길게는 30초 이상 걸리기 때문입니다.만약 30명이 동시에 질문을 던진다면 서버 내부에서는 어떤 일이 벌어질까요? 왜 여기서는 '비동기(Async)'가 선택이 아닌 필수인지 , 멀티쓰레드와 싱글쓰레드의 정확한 차이가 무엇인지, 어떤식으로 요청을 접수시켜야될지? 기록해보려 합니다.1. 상황 분석: 30명의 접속, 응답 시간 30초RAG 챗봇의 프로세스는 보통 3단계를 거칩니다.질문 임베딩: 질문을 벡터로 변환 (C..

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 - CORS 마스터 3부] 개발(Local) vs 운영(Prod) 환경 분리와 실전 트러블 슈팅지난 1부와 2부를 거치며 우리는 CORS의 개념을 익히고, 인증 정보가 포함된 요청까지 안전하게 처리하는 방법을 구현했습니다. 로컬 개발 환경에서 프론트엔드와 백엔드는 이제 완벽하게 소통하고 있습니다. 기능 개발이 완료되었으니, 이제 코드를 실제 서버에 배포할 차례입니다.하지만 여기서 우리는 마지막 난관에 봉착하게 됩니다. 2부에서 작성한 코드를 다시 한번 살펴보겠습니다. 소스 코드 내부에 http://localhost:3000이라는 로컬 주소가 하드코딩 되어 있습니다. 이 코드가 그대로 프로덕션 서버(AWS, GCP 등)에 올라간다면 어떻게 될까요? 실제 사용자는 https://my-serv..

[FastAPI - CORS 마스터 2부] 쿠키 인증(Credential) 이슈 해결과 보안을 위한 정교한 허용 전략지난 1부에서 우리는 allow_origins=["*"]라는 만능열쇠를 사용하여 네트워크 에러라는 급한 불을 껐습니다. 브라우저와 서버 사이의 장벽이 허물어졌고, API 통신은 원활해 보였습니다. 하지만 프로젝트가 고도화되면서 '사용자 인증' 기능을 붙여야 하는 순간에는 추가적인 인증을 넣었어야 합니다. 서비스의 핵심인 로그인 기능을 구현하기 시작했습니다. 보안성을 높이기 위해 단순한 토큰 전달 방식 대신, HttpOnly 쿠키에 세션 ID나 JWT를 담아 전달하는 방식을 채택했습니다. 프론트엔드 코드도 이에 맞춰 수정되었습니다. Axios와 같은 HTTP 클라이언트가 요청을 보낼 때 쿠키..

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

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

https://ye-seul0-0.tistory.com/2 [FastAPI - DI 마스터 01부] 복잡성 증가를 해결하는 의존성 주입(DI) 개념과 필요성FastAPI 의존성 주입(Dependency Injection) 심층 분석: 왜, 그리고 어떻게 사용하는가? 이번 포스팅에서는 FastAPI를 빠르고 견고하게 만들어주는 핵심 원리, 의존성 주입(Dependency Injection, DI) 시스템에 대ye-seul0-0.tistory.comhttps://ye-seul0-0.tistory.com/6 [FastAPI - DI 마스터 2부] Depends 사용법 기초부터 yield를 이용한 DB 연동까지 실전 정복FastAPI 의존성 주입(DI) 마스터 시리즈 (2부)안녕하세요! 지난 1부에서는 우리가 ..

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. 복잡해지는 경로 함수와 공통 로직 관리게시판, 사용자 인증, 결제 처리 등 다양한 기능을 구현하다 보면, 실제 비즈니스 로직 외에도 여러 엔드포인트에서 공..