Spring Boot 3 시대에 FastAPI 를 계속 쓰는 이유
Spring Boot 가 익숙한 팀에서 일하면서도 내 사이드와 작은 내부 도구에 FastAPI 를 계속 쓰는 이유.
회사 본진은 Spring Boot 다. 그런데 내가 만지는 작은 내부 도구 / 자동화는 거의 다 FastAPI. 왜 갈라놓는가 — 한 번 정리.
FastAPI 가 더 빠른 영역
- 단발 도구: URL 단축기, 메트릭 그래프 봇, 슬랙 webhook 처리. Spring Boot 의
mvn spring-boot:run첫 부팅보다 FastAPI 의uvicorn이 압도적으로 빠르다. - Python 생태계와 가까울 때: Pandas, anthropic SDK, feedparser. 같은 언어 안에서 끝.
- 타입 + 검증이 본 기능과 가까울 때: Pydantic 모델이 곧 요청/응답 스키마, 그리고 OpenAPI 가 자동 생성. Spring 의 DTO + Bean Validation + springdoc 조합보다 행수가 적다.
Spring Boot 가 더 빠른 영역
- 여러 사람이 같이 만지는 큰 서비스: 합의된 구조 (Layered, DI, AOP) 가 협업에 더 강하다.
- 결제·정산 같은 무거운 도메인: 트랜잭션, 락, 분산 캐시 — JVM 생태계의 검증된 도구가 더 많다.
- 운영 monitoring: Actuator 가 거의 다 박혀 있다. FastAPI 는 직접 만든다.
작은 도구의 손익 계산
내부 도구를 FastAPI 로 만들면 30분에 working prototype, 일주일에 운영 안정화. Spring Boot 로 같은 도구를 만들면 안정화는 빠른데 첫 prototype 까지가 길다. 작은 도구는 prototype 가 빠를수록 가치가 큰 영역.
다음에는 다르게 할 한 가지
본진 언어로 모든 도구를 통일하려는 충동을 누른다. 도구의 크기와 수명에 따라 언어를 갈라놓는 게 결국 손이 덜 가는 길이었다. “통일이 멋있어 보여서” 같은 이유로 큰 망치를 작은 못에 쓰지 않는다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.