Spring Boot 와 FastAPI 사이에서 — 우리 팀의 분기점

우리 팀에 Spring Boot 는 오랜 기본값이었다. JVM 생태계가 익숙하고, 타입 시스템이 강하고, 엔터프라이즈 연동에서 선택지가 넓다. 그런데 AI 관련 기능을 서비스에 붙이기 시작하면서 FastAPI 를 진지하게 고려하게 됐다. 두 프레임워크 사이에서 우리가 어떤 기준으로 결정을 내렸는지 정리해 둔다.

왜 FastAPI 가 등장했는가

Python 생태계는 머신러닝과 데이터 관련 라이브러리에서 압도적이다. LLM SDK, 벡터 DB 클라이언트, 임베딩 라이브러리 대부분이 Python 을 1순위로 지원한다. Java 바인딩이 있더라도 Python 쪽이 더 최신이고, 커뮤니티 예시도 풍부하다.

FastAPI 는 이 생태계의 접착제 역할을 한다. 타입 힌트 기반의 자동 문서 생성, 비동기 지원, 의존성 주입이 간결하게 설계되어 있다. AI 파이프라인을 감싸는 API 레이어로서는 작성 속도가 빠르다.

Spring Boot 가 여전히 맞는 상황

그러나 Spring Boot 를 완전히 대체하려는 생각은 없다. 우리 서비스의 주요 도메인 — 사용자 관리, 결제 흐름, 정산 로직 — 은 여전히 Spring Boot 로 운영한다. 이유는 몇 가지다.

첫째, 트랜잭션과 영속성 레이어다. JPA 와 Spring Data 의 조합은 복잡한 도메인 모델을 다룰 때 검증된 도구다. Python ORM 들이 발전하고 있지만, 우리가 익숙한 수준의 안정성을 FastAPI 로 구현하려면 추가 학습 비용이 필요하다.

둘째, 팀 역량이다. 팀원 대부분이 Java 경험이 더 길다. 낯선 스택으로 생산성 임계값을 넘는 데까지 시간이 걸린다. 스택 선택은 기술적 최선보다 현재 팀 역량과 더 긴밀하게 연결되어 있다.

셋째, 운영 복잡도다. 두 언어, 두 런타임, 두 배포 파이프라인을 유지하는 것은 분리된 가치가 있을 때만 합리적이다. 무조건 분리하면 유지보수 비용이 늘어난다.

우리가 내린 분기 기준

결론적으로 우리 팀은 이렇게 기준을 잡았다.

• Python 라이브러리를 핵심으로 쓰는 AI 파이프라인: FastAPI
• 도메인 로직, 결제/정산, 복잡한 트랜잭션: Spring Boot
• 단순 CRUD, 대시보드 API: 기존 스택에 붙이는 것이 유지보수에 유리

두 프레임워크가 통신해야 할 때는 HTTP 로 연결한다. gRPC 나 메시지 큐를 쓰기에는 팀 규모가 작아 오버헤드가 크다. REST 로 경계를 나누고 각자의 역할에 집중하는 방식이 현재 우리 팀에는 맞다.

정리

“어떤 프레임워크가 더 좋은가”가 아니라 “지금 이 문제에 어떤 스택이 맞는가”가 올바른 질문이다. 두 도구 모두 잘 만들어져 있고, 각자의 영역이 있다. 팀 역량과 도메인 특성을 기준으로 판단하면 결정이 훨씬 쉬워진다.

— by slecs