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

결제·정산 현장에서 프레임워크 선택이 남다른 이유

일반적인 서비스 팀에서 "어떤 프레임워크를 쓸까"는 생산성과 생태계의 문제다. 그런데 결제와 정산을 직접 운영하는 팀에게는 차원이 하나 더 붙는다. 트랜잭션 무결성, 멱등성 처리, 정산 오차 추적 — 이것들은 프레임워크 선택이 잘못되면 단순히 버그가 나는 게 아니라 실제 돈에 오차가 생기거나 고객 클레임으로 이어지는 문제다. HEDVION 팀이 Spring Boot와 FastAPI 사이에서 기준을 세우게 된 맥락은 바로 이 지점에서 시작한다.

우리가 AI 관련 기능을 서비스에 붙이기 시작한 건 정산 자동화의 마지막 5%를 해결하기 위해서였다. 규칙 기반 로직으로 커버할 수 없는 예외 케이스 — 금액이 일치하지 않는 부분 정산, 환불과 취소가 혼재된 트랜잭션 묶음, 거래 파트너사마다 다른 정산 주기 — 가 누적될수록 수작업 처리 비용이 눈에 띄게 커졌다. 이 문제를 LLM 기반으로 풀어보려 했을 때 Python 생태계를 피할 수 없었고, 그게 FastAPI를 진지하게 검토하게 된 계기다.

FastAPI가 레이더에 들어온 진짜 이유

Python 생태계가 머신러닝에서 강하다는 건 모두가 안다. 우리가 실제로 체감한 차이는 SDK 릴리즈 시차였다. 주요 LLM 프로바이더의 Python SDK는 새 기능이 나오면 보통 26주 안에 프로덕션 수준으로 안정화된다. Java 바인딩이 같은 수준의 안정성에 도달하기까지는 23개월이 걸리는 경우가 많았고, 커뮤니티 예시나 오류 사례가 쌓이는 속도도 현저히 느렸다. 빠르게 AI 파이프라인을 실험하고 프로덕션에 올려야 하는 상황에서 이 시차는 무시할 수 없는 개발 비용이다.

FastAPI 자체의 설계도 AI 파이프라인 레이어에 잘 맞는다. Pydantic 기반의 요청·응답 스키마 정의는 LLM 출력을 구조화된 데이터로 변환하는 과정에서 특히 유용하다. 동일한 역할을 Spring Boot로 구현하면 DTO 클래스, 검증 어노테이션, 파서를 따로 관리해야 한다. 간단한 AI 파이프라인 엔드포인트 하나를 만드는 데 FastAPI는 5080줄이면 충분했고, 동일한 기능의 Spring Boot 구현은 120180줄 수준이었다. 코드량 자체보다 중요한 건 변경 주기다. AI 파이프라인은 프롬프트 교체, 모델 스왑, 파이프라인 재구성이 잦은데, 코드 구조가 가벼울수록 반복 속도가 빠르다.

Spring Boot를 포기할 수 없는 이유 — 결제 도메인의 특수성

FastAPI의 장점이 분명함에도 결제·정산 코어 로직을 Spring Boot에 유지하는 데는 타협 없는 이유가 있다. 결제 트랜잭션은 실패 모드가 명확해야 한다. 결제 요청이 들어왔을 때 네트워크가 끊기면 멱등성 키를 기반으로 같은 트랜잭션이 두 번 처리되지 않아야 하고, 정산 집계 중 오류가 발생하면 전체 배치가 원자적으로 롤백되어야 한다. JPA와 Spring Transaction의 조합은 이 패턴을 오랜 시간 검증된 방식으로 구현할 수 있다. Python ORM 생태계도 빠르게 발전하고 있지만, 현재 우리 팀이 Spring Data JPA로 이미 구현해 놓은 복잡한 도메인 모델 — 결제 상태 머신, 정산 배치 집계, 환불 추적 — 을 Python으로 마이그레이션하는 데 드는 리스크를 정당화할 근거가 없다.

무엇보다 결제 로직의 버그 비용은 비대칭이다. 오류 하나가 수백 건의 정산 오차로 번질 수 있고, 그 파급은 코드 수정보다 훨씬 긴 시간이 걸리는 대외 정산 조정으로 이어진다. 익숙하지 않은 스택에서의 학습 곡선은 이 리스크를 불필요하게 높인다. 스택 선택은 기술적 최선의 문제가 아니라, 문제가 생겼을 때 팀이 얼마나 빠르게 원인을 찾고 고칠 수 있느냐의 문제다.

두 스택을 공존시킬 때의 실제 트레이드오프

두 언어, 두 런타임, 두 배포 파이프라인을 유지하는 운영 비용은 실제로 발생한다. HEDVION처럼 인원이 적은 팀에서는 이 오버헤드가 더 직접적으로 느껴진다. 로컬 개발 환경 세팅부터 달라지고, CI/CD 파이프라인을 각각 관리해야 하며, 장애가 났을 때 어느 서비스의 문제인지 추적하는 데도 시간이 걸린다.

우리가 실제로 측정한 수치를 공유하면, FastAPI 서비스를 별도 컨테이너로 분리하면서 인프라 비용은 기존 대비 약 20~30% 증가했다. 더 큰 비용은 운영 컨텍스트 스위칭이다 — 같은 날 Python 비동기 디버깅과 Java 트랜잭션 문제를 동시에 다뤄야 할 때 팀의 집중력이 분산된다. 이 오버헤드를 감수할 가치가 있는지는 결국 FastAPI 레이어가 가져다주는 실질적 성과로만 판단한다. AI 파이프라인 하나가 주당 수작업 처리 시간을 4시간 줄여준다면, 인프라 비용 증가와 운영 복잡도는 충분히 상쇄된다. 그 성과가 없는 상황에서 두 스택을 병용하는 건 복잡도를 사는 일이다.

실전 시나리오: 정산 예외 처리에 AI를 붙이다

구체적인 예를 들면 이해가 빠르다. 우리 팀이 실제로 구성한 파이프라인 중 하나는 미매칭 정산 트랜잭션 자동 분류다. 파트너사로부터 들어오는 정산 파일에는 매월 평균 2~5%의 트랜잭션이 자동 매칭 규칙으로 처리되지 않는다. 금액 불일치, 날짜 범위 차이, 거래 ID 포맷 불일치가 원인인 경우가 대부분이다. 기존에는 이것을 담당자가 매월 수작업으로 검토했다.

아키텍처는 이렇다. Spring Boot 정산 서비스가 미매칭 트랜잭션을 감지하면, FastAPI AI 서비스에 HTTP POST로 해당 데이터를 전달한다. FastAPI 서비스는 LLM과 임베딩 기반 유사도 검색을 결합해 "이 트랜잭션은 어떤 정산 항목과 매칭될 가능성이 높은가"를 분류하고, 신뢰도 점수와 함께 후보를 반환한다. Spring Boot 서비스는 이 결과를 받아 신뢰도 임계값(현재 0.85) 이상인 경우만 자동 확정하고, 그 이하는 담당자 검토 큐에 넣는다. AI 서비스가 다운되더라도 Spring Boot 쪽 로직은 "AI 미응답 → 수동 검토 큐"로 폴백한다. 코어 정산 로직은 AI 서비스의 가용성에 의존하지 않는다. 이 구조로 미매칭 트랜잭션 중 약 68%가 자동 확정으로 처리되기 시작했고, 담당자의 수작업 시간은 월 기준 약 18시간에서 6시간으로 줄었다.

바로 써먹을 수 있는 판단 기준

두 스택을 병용할지 결정할 때 우리가 실제로 쓰는 체크리스트다.

FastAPI를 선택하는 조건: 해당 기능이 Python 라이브러리(LLM SDK, 벡터 DB, 임베딩)를 핵심 로직으로 사용하는가? 변경 주기가 잦은 실험적 파이프라인인가? 장애가 나도 코어 서비스에 영향이 없도록 격리할 수 있는가? 세 가지 모두 해당하면 FastAPI가 맞다.

Spring Boot를 유지하는 조건: 해당 기능이 트랜잭션 무결성, 멱등성, 도메인 상태 머신과 연관되어 있는가? 버그 비용이 직접적인 금전 오차로 이어지는가? 팀의 주력 역량이 Java에 있는가? 하나라도 해당하면 Spring Boot를 벗어나지 않는다.

공존 시 반드시 지킬 규칙: FastAPI 레이어에는 비즈니스 로직을 두지 않는다 — AI 파이프라인만 있어야 한다. 두 서비스 간 통신은 REST로 단순하게 유지하고, gRPC나 메시지 큐는 팀 규모가 그것을 운영할 여력이 생길 때 도입한다. 서비스 간 API 스키마는 코드보다 먼저 문서화한다. 로그와 트레이싱은 두 스택에 처음부터 동일한 기준으로 적용하지 않으면, 장애 추적에서 반드시 후회한다. 그리고 가장 중요한 원칙 하나 — FastAPI 서비스는 항상 Spring Boot 서비스 입장에서 "없어도 코어가 돌아가는" 의존성으로 설계한다. AI 서비스 가용성에 결제 흐름이 종속되는 순간 장애 반경이 예상보다 훨씬 커진다.

"어떤 프레임워크가 더 좋은가"는 여전히 잘못된 질문이다. "이 기능이 망가졌을 때 어떤 일이 일어나는가"를 먼저 묻는 것이 결제·정산 팀다운 접근이다.

— by slecs