FastAPI가 기존 프레임워크들을 밀어내고 선택받는 3가지 핵심 원리와 아키텍처를 정리해 봅니다.
FastAPI의 가장 큰 무기는 이름 그대로 속도입니다.
기존 Flask는 동기 방식으로 동작하여, 한 번에 하나의 request만 처리하고 다음 request는 대기해야 했습니다. 반면 FastAPI는 내부적으로 Starlette이라는 비동기 프레임워크를 사용하여 비동기 I/O를 완벽하게 지원합니다.
async def와 await 키워드를 사용해 DB 조회를 하거나 AI 모델을 추론하는 동안, 서버가 멈춰있지 않고 다른 Client의 request를 동시에 처리할 수 있어 트래픽 병목 현상을 획기적으로 줄여줍니다.
Python은 본래 변수에 어떤 값이든 들어갈 수 있는 동적 타입 언어입니다. 이 유연함은 코딩할 때는 편하지만, 서버 간 통신에서는 치명적인 런타임 에러를 유발합니다.
FastAPI는 Type Hinting과 Pydantic 라이브러리를 결합하여 이 문제를 해결합니다.
개발자가 Request Body로 들어올 Data Structure의 타입을 명시해 두면, FastAPI가 알아서 데이터를 parsing 하고 타입을 검사합니다. 만약 클라이언트(Spring Boot 등)가 Integer 자리에 String을 보낸다면, 개발자가 별도의 예외 처리 코드를 짜지 않아도 FastAPI가 즉시 422 Unprocessable Entity 에러를 반환하며 잘못된 데이터를 차단해 줍니다.
FastAPI의 라우팅 시스템은 극도로 직관적입니다. 프론트엔드의 router와 달리, 백엔드의 Router는 외부의 request를 알맞은 함수로 연결하는 실제 네트워크 통제소 역할을 합니다.
@app.post("/predict")
async def predict_image(file: UploadFile = File(...)):
return {"status": "success"}
위 코드처럼 @app.post라는 Decorator를 사용해 HTTP Method(POST)와 Endpoint URL(/predict)을 맵핑합니다. 이 구조 덕분에 외부 서버(Spring Boot)가 던진 request가 정확히 어느 함수에게 도달해야 하는지 명확하게 설계할 수 있습니다.
백엔드 개발자들의 가장 큰 고충 중 하나는 프론트엔드 팀이나 외부 연동 팀을 위해 API 명세서를 작성하고 유지보수하는 일입니다. 코드가 바뀌면 문서도 매번 수정해야 하기 때문입니다.
FastAPI는 코드를 작성하는 즉시, OpenAPI 표준 규격에 맞추어 Swagger UI라는 대화형 API 문서를 자동으로 생성해 줍니다. 서버를 띄우고 /docs 주소로 접속하기만 하면, 현재 서버에 어떤 endpoint들이 열려 있는지, 어떤 Parameter를 보내야 하는지 웹 화면에서 바로 확인하고 테스트까지 진행할 수 있습니다.