[1일 1프로젝트] 백엔드의 끝 - nginx

About this offer

[Backend] Uvicorn, FastAPI, Nginx의 역할 분담과 비동기(ASGI)의 비밀 (feat. C#과의 차이점) 웹 백엔드 아키텍처를 공부하다 보면 꼭 마주치는 조합이 있습니다. 바로 Nginx + Uvicorn + FastAPI입니다. "요청을 받아서 처리한다"는 점에서 다 비슷해 보이지만, 실제 내부를 들여다보면 각자의 역할이 명확히 나뉘어 있습니다. 이번 글에서는 이 세 가지 기술의 관계를 현실적인 비유로 알아보고, 많은 개발자들이 헷갈려하는 파이썬 비동기(ASGI)의 스레드 모델을 C#과의 비교를 통해 완벽하게 정리해 보겠습니다. 1. 한눈에 보는 역할 분담 (식당 비유 🏢) 이들의 관계는 '대형 종합 식당'의 운영 구조와 완전히 같습니다. Nginx (종합 안내 데스크 / 문지기): 세상 모든 사람(인터넷 외부)을 상대하며, 입구에서 자물쇠(HTTPS)를 풀어주고 손님을 적절한 구역으로 안내합니다. Uvicorn (고성능 서빙 로봇 / ASGI 서버): Nginx가 들여보낸 손님의 주문을 받아서 주방에 빛의 속도로 전달하고, 요리가 나오면 손님에게 배달합니다. 파이썬 코드를 읽을 줄 아는 통역사입니다. FastAPI (주방의 메인 셰프 / 웹 프레임워크): Uvicorn이 준 주문서(요청)를 바탕으로 데이터베이스를 뒤지거나 비즈니스 로직을 수행하여 진짜 요리(결과 데이터)를 만들어냅니다. 2. 현실적인 대작전 시나리오: 아이돌 콘서트 티켓팅 오픈! 🎬 사용자 1만 명이 동시에 예매 버튼을 눌렀을 때 내부에서 일어나는 실제 흐름입니다. 1단계: Nginx의 철통 방어 (HTTPS & 로드밸런싱) HTTPS 복호화: 손님들이 보낸 요청은 암호화(HTTPS)되어 있습니다. Nginx는 맨 앞에서 이 자물쇠를 번개 같은 속도로 풀어냅니다. (뒤쪽 엔진들의 연산 부담을 줄여줌) 로드밸런싱: Nginx 뒤에 Uvicorn 엔진 3대(A, B, C 포트)를 대기시켜 두고, 1만 명의 요청을 골고루 쪼개서 분배합니다. (Reverse Proxy 역할) 2단계: Uvicorn의 ASGI 비동기 마법 (초고속 접수) 구식 서버(WSGI)는 앞 손님의 요리가 끝날 때까지 뒤 손님을 대기시킵니다. 반면 Uvicorn(ASGI)은 1번 손님의 주문을 주방(FastAPI)에 던진 후, 주방이 데이터베이스를 조회하느라 멈춰 있는 시간(약 0.5초)을 가만히 기다리지 않습니다. "어, 1번 손님 조회 중이야? 오케이, 그럼 난 그 사이에 2번, 3번, 4번 주문 계속 받을게!" 하며 요청을 멈춤 없이 접수합니다. 3단계: FastAPI의 영리한 일 처리 (비동기 셰프) FastAPI 코드가 async def로 짜여 있다면, 셰프 역시 멀티태스킹의 신이 됩니다. 1번 주문의 DB 응답을 기다리는 동안 2번 주문을 처리하고, 1번 DB 결과가 도착하면 하던 걸 잠깐 멈추고 1번 요리를 완성해 Uvicorn에게 던집니다. 컴퓨터 세계에서 가장 느린 'I/O 대기 시간(DB 조회, 외부 API 호출)'을 완전히 재활용하는 구조입니다. 3. 라우팅 이후, 실제 코드는 어떤 스레드가 처리할까? 🤔 FastAPI가 내부적으로 스레드를 어떻게 쓰느냐는 개발자가 코드를 어떻게 짰느냐(async def vs def)에 따라 완전히 달라집니다. 1 async def로 짰을 때: 멀티태스킹의 신, 싱글 스레드 @app.get("/ticket")async def book_ticket(): await db.check_seat() # DB를 기다리는 동안 스레드는 다른 일을 하러 감 return {"status": "success"} 동작 방식: 별도의 프로세스나 스레드가 새로 생성되지 않습니다. Uvicorn의 단 하나의 메인 스레드 위에서 돕니다. 원리: await를 만나는 순간, 메인 스레드는 작업을 옆으로 치워두고 즉시 다음 손님의 요청을 처리합니다. 이벤트 루프(Event Loop)가 완료 신호를 주면 다시 돌아와 마무리합니다. (Context Switching 비용 최소화) 2 그냥 def로 짰을 때: 스레드 풀(Thread Pool)의 도우미들 @app.get("/heavy-job")def heavy_job(): time.sleep(2) # 메인 스레드를 얼려버리는 Blocking 코드 return {"status": "done"} 동작 방식: 파이썬에서 일반 def 코드가 멈추면 메인 스레드 전체가 얼어버립니다(Blocking). 원리: 이를 막기 위해 FastAPI는 내부적으로 '스레드 풀(Thread Pool)'이라는 서브 스레드(임시 직원)를 깨워 일을 넘깁니다. 메인 스레드는 자유 몸이 되어 다음 손님을 받고, 서브 스레드가 백그라운드에서 일을 처리합니다. 💡 참고 (Process는 언제 쓰나요?): 파이썬은 GIL(Global Interpreter Lock) 제약 때문에 하나의 프로세스 내에서 멀티 스레드를 써도 CPU 연산을 동시에 할 수 없습니다. 따라서 멀티코어 CPU를 100% 쓰려면 uvicorn main:app --workers 4처럼 Uvicorn 프로세스 자체를 여러 개 띄우고, 맨 앞의 Nginx가 이 프로세스들에게 요청을 분산해야 합니다. 4. ⚠️ 닷넷(C#) 개발자가 가장 흔하게 하는 착각! (C# vs Python 비동기) C# 개발자가 파이썬 FastAPI 생태계에 오면 엄청난 문화 충격(Culture Shock)을 겪습니다. 이름은 같은 async/await인데 스레드가 작동하는 방식이 정반대이기 때문입니다. 항목 C# (Task 기반 비동기) 🖥️ Python FastAPI (이벤트 루프) 🐍 기본 사상 멀티 스레드 기반 (스레드가 기본적으로 많음) 싱글 스레드 기반 (스레드가 기본적으로 1개) async 안 썼을 때 메인 스레드가 그대로 멈춤 (Blocking) FastAPI가 스레드 풀에 일을 넘겨 메인 스레드를 살림 async 썼을 때 await 시 스레드 풀의 다른 스레드로 작업이 넘어가서 실행됨 Microsoft Learn await 시 동일한 메인 스레드를 유지하며, 대기 시간 동안 눈알만 딴 데 돌려 다른 요청을 받음 C#에서의 비동기: 기본적으로 풍부한 멀티 스레드 풀을 활용합니다. 비동기를 써야 스레드 풀의 다른 직원에게 효율적으로 일을 넘기며(Task) 스레드를 나눠 씁니다 Microsoft Learn. FastAPI에서의 비동기: GIL 제약 때문에 "스레드 1개만 지독하게 굴리자"는 싱글 스레드 사상(Node.js와 유사)입니다. 비동기(async)를 써야 메인 스레드 하나로 광속 멀티태스킹이 일어나고, 비동기를 안 쓰면(def) 메인 스레드가 죽는 걸 막으려고 프레임워크가 억지로 스레드 풀을 켜서 유배를 보내는 구조입니다. 📝 총정리 및 결론 Nginx는 문앞에서 포트를 분배하고 암호(HTTPS)를 풀어주는 총괄 매니저입니다. Uvicorn은 Nginx에게 받은 요청을 파이썬 객체로 번역하는 비동기 엔진입니다. FastAPI에서 async def를 쓰면 단 하나의 메인 스레드가 징검다리 건너듯 비동기로 모든 요청을 광속 처리합니다. FastAPI에서 def를 쓰면 메인 스레드가 멈추는 걸 방지하기 위해 내부 스레드 풀(서브 스레드)로 작업을 토스합니다.