Flyway, Incident, Audit까지 묶어 운영 플랫폼으로 다듬기

Kubernetes Cluster Infra RCA Platform 개발 기록 9편

지난 글에서는 React 19, TypeScript, Vite, Bootstrap 5 기반으로 Web Console을 다시 구성한 과정을 정리했습니다.

이번 글은 마지막 전환 정리입니다.

Spring Boot와 React로 구조를 바꾼 뒤, 이제 남은 문제는 이것이었습니다.

이 프로젝트를 단순 RCA 도구가 아니라 운영 플랫폼처럼 만들려면 무엇이 더 필요할까?

장애 분석 도구는 report만 만든다고 끝나지 않습니다.

운영 환경에서는 기록, 추적, 감사, metric, 보존 정책이 필요합니다.

그래서 이번 단계에서는 Flyway, incident, audit, metric, retention 같은 운영 기능을 묶어서 정리했습니다.

Flyway로 DB migration 관리하기

Spring Boot로 통합하면서 DB migration은 Flyway로 관리하게 되었습니다.

RCA 플랫폼은 DB에 많은 정보를 저장합니다.

• cluster
• node agent
• evidence request
• evidence bundle
• RCA report
• incident
• action request
• audit event
• user session

이런 데이터는 운영 기록이기 때문에 schema 관리가 중요합니다.

초기에는 Python/Alembic 기반 schema가 있었지만, Spring Boot 구조로 오면서 Flyway가 migration을 담당하는 방향으로 바뀌었습니다.

중요한 것은 기존 DB를 무시하지 않는 것이었습니다.

이미 Alembic 기반으로 만들어진 DB를 사용하는 경우도 고려해야 했기 때문에, 기존 schema는 baseline으로 승계하고 이후 migration부터 Flyway로 관리하는 방향을 잡았습니다.

기존 DB:
Alembic schema
  -> baseline

새 구조:
Flyway migration
  -> 이후 schema 변경 관리

이런 방식이 있어야 프로젝트가 단순 재작성으로 끝나지 않고, 기존 구조를 이어받을 수 있습니다.

Incident 개념이 필요했던 이유

처음에는 RCA report 하나하나가 중심이었습니다.

하지만 실제 장애는 report 하나로 끝나지 않을 수 있습니다.

예를 들어 같은 노드에서 storage 문제, kubelet 문제, runtime 문제가 시간상 이어질 수 있습니다.

이 경우 report가 여러 개 생겨도 실제로는 하나의 incident일 수 있습니다.

그래서 incident 개념이 필요했습니다.

여러 evidence signal
  -> 시간상 인접
  -> causal rule로 연결
  -> 하나의 incident로 묶기

incident가 생기면 운영자는 개별 report보다 장애 흐름 전체를 볼 수 있습니다.

어떤 신호가 먼저 발생했고, 어떤 문제가 뒤따랐으며, 최종적으로 어떤 root cause 후보가 올라왔는지 보기 쉬워집니다.

RCA 플랫폼이 조금 더 실무적으로 보이기 시작하는 지점이 바로 여기였습니다.

Audit event를 남겨야 하는 이유

운영 플랫폼에서는 “누가 무엇을 했는가”가 중요합니다.

특히 이 프로젝트처럼 cluster 등록, report export, action request, approval, 삭제 같은 기능이 있다면 audit event는 필수에 가깝습니다.

예를 들어 이런 기록이 남아야 합니다.

• 누가 로그인했는가
• 누가 cluster를 등록했는가
• 누가 report를 조회했는가
• 누가 export를 다운로드했는가
• 누가 action을 승인하거나 거절했는가
• 누가 cluster를 삭제했는가

이 기록이 있어야 나중에 문제가 생겼을 때 추적할 수 있습니다.

RCA 플랫폼은 장애를 분석하는 도구이기도 하지만, 동시에 운영자가 사용하는 관리 도구입니다.

관리 도구라면 audit은 선택 기능이 아니라 기본 기능에 가깝다고 생각했습니다.

Metric과 observability

플랫폼 자체도 관찰 가능해야 합니다.

장애를 분석하는 도구가 정작 자기 상태를 보여주지 못하면 운영하기 어렵습니다.

그래서 Micrometer, Actuator, Prometheus metric을 통해 플랫폼 상태를 볼 수 있게 정리했습니다.

보고 싶은 metric은 이런 것들입니다.

• Agent offline 상태
• heartbeat lag
• evidence 수집 시간
• RCA report 생성 시간
• analysis queue 상태
• dead-letter 발생 여부
• LLM 호출 결과
• notification 실패 여부

이런 metric이 있으면 RCA 플랫폼 자체가 느려졌는지, Agent가 멈췄는지, report 생성이 지연되는지 확인할 수 있습니다.

운영 도구는 남의 장애만 보는 것이 아니라, 자기 자신도 관찰 가능해야 합니다.

Retention policy가 필요한 이유

RCA 플랫폼은 데이터를 계속 저장합니다.

evidence, report, incident, audit event가 계속 쌓이면 DB가 무한히 커질 수 있습니다.

그래서 retention policy가 필요했습니다.

하지만 단순히 오래된 데이터를 지우는 방식이면 위험합니다.

열려 있는 incident나 승인 대기 중인 action, report와 연결된 evidence를 무작정 지우면 데이터 무결성이 깨질 수 있습니다.

그래서 보존 정책은 조심스럽게 접근해야 했습니다.

지워도 되는 데이터
  -> 참조가 끝난 오래된 evidence
  -> 만료된 session
  -> 닫힌 incident 관련 오래된 데이터

지우면 안 되는 데이터
  -> 열린 incident
  -> 승인 대기 action
  -> report와 연결된 evidence

운영 플랫폼에서는 “잘 저장하는 것”만큼 “안전하게 정리하는 것”도 중요하다고 느꼈습니다.

Codex를 어떻게 활용했는가

이번 단계에서도 전체 방향은 직접 잡았습니다.

Incident가 왜 필요한지, audit event에 무엇을 남겨야 하는지, metric으로 무엇을 봐야 하는지, retention에서 어떤 데이터를 지우면 안 되는지는 직접 판단해야 했습니다.

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

사람:
운영 기능 우선순위 결정
incident 개념 설계
audit 대상 판단
metric 기준 결정
retention 안전 기준 검토

Codex:
Flyway migration 초안 작성
repository 테스트 보강
audit event 반복 구현
metric endpoint 정리
문서 초안 작성

Codex는 구현 속도를 높이는 데 도움이 됐습니다.

하지만 운영 데이터의 의미와 위험성은 직접 판단해야 했습니다.

이 단계에서 중요했던 점

이번 단계에서 가장 중요하게 본 것은 “운영 기록”이었습니다.

장애 분석 도구는 장애가 발생한 순간만 도와주면 안 됩니다.

장애가 끝난 뒤에도 기록이 남아야 하고, 나중에 다시 확인할 수 있어야 하며, 누가 어떤 판단을 했는지도 추적할 수 있어야 합니다.

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

1. DB schema는 Flyway로 관리한다
2. 기존 Alembic schema 승계도 고려한다
3. 개별 report를 incident 흐름으로 묶는다
4. 중요한 사용자 행동은 audit event로 남긴다
5. 플랫폼 자체 metric을 제공한다
6. retention policy로 데이터를 안전하게 정리한다
7. Codex는 구현을 돕지만 운영 판단은 사람이 한다

개인적으로 가장 중요했던 것은 4번과 5번이었습니다.

운영 도구는 사용자의 행동도 기록해야 하고, 자기 자신의 상태도 보여줘야 합니다.

마무리

이번 단계에서는 RCA 플랫폼을 운영 도구답게 다듬었습니다.

Flyway로 DB migration을 관리하고, incident 개념으로 여러 신호를 묶고, audit event로 중요한 행동을 기록하고, metric과 retention policy까지 정리했습니다.

이 과정을 거치면서 프로젝트는 단순히 “장애 원인을 말해주는 도구”에서 조금 더 플랫폼에 가까워졌습니다.

장애 분석 도구는 report를 만드는 것에서 끝나면 안 되고, 기록하고, 추적하고, 공유하고, 다시 검증할 수 있어야 한다.

이제 남은 것은 실제 장애 시나리오를 더 많이 만들고, Agent가 수집한 evidence가 어떤 RCA report로 이어지는지 데모를 강화하는 일입니다.

다음 글을 쓴다면, 실제 장애 시나리오를 만들어 이 플랫폼이 어떻게 evidence를 수집하고 incident를 구성하는지 보여주는 방향으로 정리해보고 싶습니다.