Kubernetes

FastAPI를 버리고 Spring Boot로 통합한 이유

초기 FastAPI 기반 Backend에서 Spring Boot 3.5.15와 Java 21 기반 통합 Platform으로 전환하면서, 왜 기술 스택을 바꾸게 되었는지 정리했습니다.

SeongwookBAE

• 7 min read
Share
FastAPI를 버리고 Spring Boot로 통합한 이유
Photo by Caspar Camille Rubin / Unsplash

Kubernetes Cluster Infra RCA Platform 개발 기록 7편

이전 글까지는 RCA 플랫폼을 기능 단위로 계속 확장하는 과정을 정리했습니다.

처음에는 FastAPI 기반 Backend가 있고, 별도의 Web Console이 붙고, Node Agent가 evidence를 보내는 구조였습니다.

초기 MVP를 만들기에는 FastAPI가 좋았습니다.

빠르게 API를 만들 수 있고, Python 기반 Node Agent와도 자연스럽게 이어졌습니다.
덕분에 cluster 등록, evidence request, RCA report 생성, webhook 처리 같은 초기 흐름을 빠르게 검증할 수 있었습니다.

하지만 프로젝트가 커지면서 점점 고민이 생겼습니다.

이 구조를 계속 유지하는 게 맞을까?

단순 API 서버라면 FastAPI로도 충분했습니다.
하지만 이 프로젝트는 점점 “운영 플랫폼”에 가까워지고 있었습니다.

FastAPI가 나빠서 버린 것은 아니었다

먼저 분명히 하고 싶은 것은, FastAPI가 나빠서 버린 것이 아니라는 점입니다.

FastAPI는 초기 개발 속도가 빠르고, API를 실험하기에 좋았습니다.

문제는 프로젝트의 성격이 바뀌었다는 점이었습니다.

처음에는 이런 구조였습니다.

FastAPI Backend
  -> cluster API
  -> evidence API
  -> RCA report API
  -> webhook API

하지만 시간이 지나면서 필요한 기능은 훨씬 많아졌습니다.

  • 인증과 role 기반 API 보안
  • DB migration
  • Web Console
  • report export
  • incident 관리
  • audit event
  • metric
  • scheduling
  • Spring AI 기반 LLM 연동
  • 운영 설정 관리

이 정도가 되면 단순 API 서버라기보다 하나의 Platform에 가까워집니다.

그래서 Backend, Web Console, 인증, DB, metric을 따로따로 붙이는 것보다, 하나의 Spring Boot 애플리케이션으로 통합하는 편이 더 낫다고 판단했습니다.

Spring Boot 3.5.15와 Java 21로 전환

전환 후에는 Platform을 Spring Boot 3.5.15와 Java 21 기반으로 정리했습니다.

구조는 이런 방향으로 바뀌었습니다.

기존:
FastAPI Backend
  + 별도 Web Console
  + Alembic migration
  + Python 중심 API 구조

변경:
Spring Boot Platform
  + 통합 API
  + 인증/권한
  + DB/Flyway
  + Web Console serving
  + Actuator/Micrometer
  + Spring AI 연동

이 전환에서 가장 크게 달라진 점은 “기능을 추가했다”가 아니라, 프로젝트의 중심축을 바꿨다는 점입니다.

이전에는 Backend API가 중심이고 Console은 붙어 있는 느낌이었다면, 전환 후에는 Spring Boot Platform 하나가 API, 인증, DB, Web Console, metric을 함께 담당하는 구조가 되었습니다.

이렇게 바꾸면 운영 플랫폼으로 확장하기가 더 자연스럽습니다.

Alembic에서 Flyway로

DB migration도 바뀌었습니다.

초기에는 Python Backend에 맞춰 Alembic을 사용했습니다.

하지만 Spring Boot로 통합하면서 migration도 Flyway로 옮기는 것이 자연스러웠습니다.

기존:
Python Backend
  -> SQLAlchemy
  -> Alembic migration

변경:
Spring Boot Platform
  -> JDBC
  -> Flyway migration

여기서 중요했던 것은 기존 구조를 완전히 버리는 것이 아니라, 기존 DB schema를 어떻게 승계할 것인가였습니다.

이미 Python/Alembic 기반으로 만든 schema가 있다면, 새 Spring Boot 구조에서 무작정 새로 만들 수는 없습니다.

그래서 기존 schema는 baseline으로 인정하고, 이후부터 Flyway가 migration을 관리하는 방향으로 생각했습니다.

이 부분은 운영 플랫폼 관점에서 중요했습니다.

데이터를 다루는 프로젝트에서는 코드 전환보다 DB 전환이 더 조심스럽기 때문입니다.

통합 Platform으로 바꾸면서 좋아진 점

Spring Boot로 통합하면서 가장 좋았던 점은 구조가 단순해졌다는 것입니다.

기존에는 Backend, Web Console, DB migration, 인증, metric이 분리된 느낌이 강했습니다.

전환 후에는 하나의 Platform 안에서 관리할 수 있게 되었습니다.

특히 다음 부분이 좋아졌습니다.

  • Spring Security로 인증/권한 구조 정리
  • Flyway로 DB migration 관리
  • Actuator/Micrometer로 운영 metric 제공
  • Spring AI로 LLM provider 연동
  • Web Console과 API를 같은 origin에서 제공
  • Java 21 기반으로 장기적인 유지보수 구조 확보

물론 전환 비용은 있었습니다.

이미 만든 FastAPI 코드를 그대로 쓸 수 없고, API와 모델, repository 구조를 다시 잡아야 했습니다.

하지만 프로젝트가 포트폴리오 수준을 넘어 운영 플랫폼처럼 보이려면, 이 전환은 충분히 의미가 있다고 판단했습니다.

Codex를 어떻게 활용했는가

이 전환은 단순 반복 구현이 많았습니다.

기존 FastAPI 쪽에서 만들었던 API 개념을 Spring Controller, Service, Repository 구조로 옮겨야 했고, migration 설정과 테스트도 다시 잡아야 했습니다.

전체 방향은 직접 정했습니다.

특히 다음 판단은 사람이 해야 한다고 생각했습니다.

  • FastAPI를 유지할지, Spring Boot로 전환할지
  • 어떤 기능을 Platform 안으로 통합할지
  • DB migration을 어떻게 승계할지
  • 인증과 권한을 어느 계층에서 처리할지
  • 운영 metric과 audit을 어떻게 볼지

반면 반복 구현은 Codex를 활용했습니다.

사람:
전환 방향 결정
기술 스택 선택
운영 플랫폼 구조 설계
DB 승계 기준 판단

Codex:
Controller/Service 반복 구현
DTO 정리
테스트 코드 보강
README 수정
migration 초안 정리

Codex는 전환 속도를 높이는 데 도움이 됐습니다.

하지만 “왜 전환해야 하는가”와 “어떤 구조가 더 운영 도구에 맞는가”는 직접 판단해야 했습니다.

이 단계에서 중요했던 점

이번 전환에서 가장 중요했던 것은 기술 스택 자체가 아니었습니다.

중요한 것은 프로젝트의 성격이 바뀌었다는 점이었습니다.

정리하면 기준은 이랬습니다.

  1. 초기 MVP에는 FastAPI가 적합했다
  2. 하지만 프로젝트가 운영 플랫폼으로 커지면서 통합 구조가 필요해졌다
  3. Spring Boot는 인증, DB, metric, scheduling, AI 연동을 한 애플리케이션 안에서 관리하기 좋았다
  4. DB migration은 Alembic에서 Flyway로 옮겼다
  5. 기존 schema 승계도 고려해야 했다
  6. Codex는 반복 구현에 활용하되, 전환 판단은 사람이 했다

개인적으로 가장 중요했던 문장은 이것입니다.

FastAPI가 나빠서 버린 것이 아니라, 프로젝트가 단순 API 서버에서 운영 플랫폼으로 바뀌었기 때문에 Spring Boot로 옮겼다.

마무리

이번 단계는 기능 추가보다 구조 전환에 가까웠습니다.

FastAPI 기반 Backend에서 Spring Boot 3.5.15, Java 21 기반 Platform으로 옮기면서 프로젝트의 중심이 바뀌었습니다.

이제 RCA 플랫폼은 API 서버, Web Console, 인증, DB migration, metric, LLM 연동을 하나의 구조 안에서 관리할 수 있게 되었습니다.

물론 전환 비용은 있었지만, 장기적으로는 더 안정적인 선택이었다고 생각합니다.

다음 글에서는 이 Spring Boot Platform 위에 React 19, TypeScript, Vite, Bootstrap 5 기반 Web Console을 어떻게 다시 구성했는지 정리해보겠습니다.