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

Kubernetes Cluster Infra RCA Platform 개발 기록 7편

---

이전 글까지는 RCA 플랫폼에 기능을 추가한 과정을 적었다.

초기에는 FastAPI Backend, 별도 Web Console, Python Node Agent를 연결했다.

FastAPI로 초기 MVP를 만들기에는 편했다.

API를 빠르게 만들 수 있었고 Python Node Agent와도 연결하기 쉬웠다. cluster 등록, evidence request, RCA report 생성, webhook 처리의 흐름을 먼저 검증할 수 있었다.

인증과 운영 기능이 늘면서 이 구조를 계속 유지할지 다시 검토했다.

초기 API 검증을 넘어 인증, 화면, DB와 운영 상태를 함께 관리할 단계가 됐기 때문이다.

---

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

FastAPI를 사용하면서 초기 API를 빠르게 검증할 수 있었다.

전환을 결정한 이유는 이후 필요한 기능을 한 애플리케이션에서 관리하고 싶었기 때문이다.

처음 Backend가 맡은 기능은 다음과 같았다.

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 연동
• 운영 설정 관리

각 기능을 별도 구성으로 연결하면서 관리할 부분도 늘고 있었다.

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 연동

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으로 만든 DB가 있다면 새 schema를 바로 적용할 수는 없었다.

기존 schema는 baseline으로 인정하고, 이후 변경부터 Flyway로 관리하는 방향을 생각했다.

코드를 옮기는 작업과 기존 데이터를 이어받는 작업을 나눠서 봐야 했다.

---

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

통합 후에는 관련 설정을 한 Platform 안에서 관리할 수 있었다.

이전에는 Backend, Web Console, DB migration, 인증, metric의 연결을 각각 맞춰야 했다.

전환하면서 정리한 부분은 다음과 같다.

• 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 초안 정리

Controller와 DTO, 테스트 초안을 옮기는 시간을 줄일 수 있었다.

전환이 필요한 이유와 결과 구조의 적합성은 직접 검토했다.

---

이 단계에서 중요했던 점

전환 판단은 늘어난 운영 요구사항을 기준으로 했다.

당시 판단 기준은 다음과 같았다.

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

초기 API를 검증할 때는 FastAPI를 썼고, 운영 기능을 통합할 단계에서는 Spring Boot를 선택했다.

---

마무리

이 단계에서는 새 기능보다 기존 기능의 배치와 책임을 바꿨다.

FastAPI Backend를 Spring Boot 3.5.15, Java 21 기반 Platform으로 옮겼다.

API, Web Console, 인증, DB migration, metric, LLM 연동을 같은 구조에서 관리할 수 있게 됐다.

전환 비용은 있었지만 장기 유지보수에는 이 편이 낫다고 판단했다.

다음 글에서는 Spring Boot Platform 위에 React 19, TypeScript, Vite, Bootstrap 5 기반 Web Console을 구성한 과정을 다룬다.