RCA 플랫폼을 관리 가능한 형태로 다듬기

Kubernetes Cluster Infra RCA Platform 개발 기록 6편

---

지난 글에서는 Backend, DB, Web Console을 Docker Compose로 묶어 로컬에서 전체 흐름을 실행한 과정을 적었다.

컴포넌트를 함께 실행할 수 있게 된 뒤에는 관리 기능을 정리했다.

이번에는 큰 기능 확장보다 등록한 데이터와 분석 결과를 관리하는 데 집중했다.

작업은 세 가지였다.

1. cluster를 안전하게 삭제할 수 있게 만들기
2. RCA report를 export할 수 있게 만들기
3. README와 문서를 현재 구조에 맞게 정리하기

---

cluster 삭제 기능이 필요했던 이유

초기에는 분석 대상 cluster를 등록하는 기능부터 만들었다.

Agent 설치 정보와 evidence request가 등록된 Kubernetes 클러스터를 기준으로 생성되기 때문이다.

등록만 가능하면 잘못 등록하거나 시험에 사용한 cluster가 계속 남는다.

그래서 cluster 삭제 기능을 추가했다.

삭제할 때는 관련 데이터도 함께 검토해야 했다.

node, evidence request, RCA report가 해당 cluster를 참조할 수 있기 때문이다.

영향받는 데이터를 확인하고, 실수로 실행하지 않도록 권한과 확인 절차를 두기로 했다.

문제:
cluster 삭제가 너무 쉬우면 운영 데이터가 실수로 사라질 수 있음

수정 방향:
삭제 시 cluster 이름 확인
admin 권한 요구
관련 데이터 처리 흐름 명확화

삭제 요청자의 권한과 대상 cluster 이름을 함께 확인하도록 했다.

---

confirm_name을 둔 이유

다른 cluster를 실수로 지우는 일을 줄이려고 했다.

삭제 버튼에 더해 대상 cluster 이름을 한 번 더 입력하는 방식을 생각했다.

DELETE /api/clusters/{cluster_id}

body:
{
  "confirm_name": "my-cluster"
}

입력한 이름과 실제 삭제 대상이 맞는지 확인하는 절차다.

입력 과정이 늘어나더라도 운영 데이터 삭제에는 이 확인이 필요하다고 봤다.

---

RCA report export 기능

RCA report export도 추가했다.

Console 밖에서 분석 결과를 공유하거나 보관할 일이 있었기 때문이다.

예상한 용도는 다음과 같았다.

• 장애 보고서로 공유해야 할 때
• 팀 내부 회고 자료로 남겨야 할 때
• incident 기록으로 보관해야 할 때
• 다른 시스템에 첨부해야 할 때
• 포트폴리오나 데모 자료로 정리해야 할 때

우선 JSON 형태로 report를 내보낼 수 있게 했다.

PDF나 HTML도 고려할 수 있었지만, 먼저 구조화된 원본 결과를 제공하기로 했다.

JSON은 이후 다른 포맷으로 변환하거나 외부 시스템과 연동할 때도 사용할 수 있었다.

RCA report
  -> JSON export
  -> 공유 / 보관 / 후처리 가능

화면에서 확인한 분석 결과를 파일로 남길 수 있게 된 것이다.

---

운영 도구는 “기록”이 중요하다

장애가 끝난 뒤에도 당시 분석을 다시 확인할 수 있어야 했다.

수집한 evidence, root cause candidate, 추천 조치를 함께 남기려고 했다.

report export를 이 기록을 공유하는 경로로 사용했다.

회고할 때 확인할 질문은 다음과 같았다.

• 왜 장애가 발생했는가?
• 어떤 근거로 판단했는가?
• 어떤 조치를 검토했는가?
• 비슷한 장애를 다음에 어떻게 줄일 수 있는가?

export한 report를 이런 확인과 공유에 사용할 수 있도록 했다.

---

README를 다시 정리한 이유

기능을 추가하면서 README와 실제 코드 사이에도 차이가 생겼다.

초기 README는 프로젝트의 큰 방향을 설명하는 수준이었다.

Backend, Node Agent, Web Console, Helm Chart, Docker Compose, LLM Analyzer, Policy Engine, report export가 들어간 현재 구조를 다시 반영해야 했다.

처음 보는 사람이 README로 프로젝트의 범위와 실행 방법을 파악할 수 있도록 정리했다.

다음 항목을 명시했다.

• 이 프로젝트가 애플리케이션 장애 분석기가 아니라 클러스터/노드/Linux RCA 플랫폼이라는 점
• LLM은 보조 역할이며, 직접 조치를 실행하지 않는다는 점
• Agent는 read-only evidence collector로 시작한다는 점
• Policy Engine이 추천 조치의 위험도를 분류한다는 점
• Docker Compose와 Helm Chart로 실행 및 배포 흐름을 제공한다는 점
• report export와 Web Console로 운영자가 결과를 확인할 수 있다는 점

소개 문서와 실제 제공하는 기능이 맞도록 고친 작업이었다.

---

Codex를 어떻게 활용했는가

반복적인 API 구현과 문서 초안에는 Codex를 활용했다.

필요한 기능, 삭제 위험, 확인 절차는 직접 검토했다.

작업 범위를 다음처럼 나눴다.

사람:
cluster 삭제 위험성 판단
confirm_name 같은 안전장치 설계
report export가 필요한 이유 정리
README 방향과 표현 검토

Codex:
삭제 API 반복 구현
export 응답 구조 정리
테스트 케이스 보강
README 초안 정리
문장 다듬기

Codex로 구현과 문서 작성 시간을 줄였다.

삭제 정책과 보호 절차가 의도대로 적용됐는지는 직접 확인했다.

---

이 단계에서 중요했던 점

등록 이후에 데이터를 어떻게 관리할지 정리한 단계였다.

기준은 다음과 같았다.

1. cluster 삭제는 admin 권한과 확인 절차를 둔다
2. 삭제는 편의성보다 안전성을 우선한다
3. RCA report는 export 가능해야 한다
4. report는 화면에서 끝나는 정보가 아니라 운영 기록이어야 한다
5. README는 실제 구조와 계속 맞춰야 한다
6. Codex는 반복 구현에 활용하되, 위험 판단은 사람이 한다

특히 2번과 4번을 함께 봤다.

삭제에는 확인 절차가 필요했고, 보존할 분석 결과는 외부로 꺼낼 수 있어야 했다.

---

마무리

cluster 삭제와 report export를 추가했다.

삭제에는 실수 방지 절차를 넣었고, export한 report는 운영 기록으로 남길 수 있도록 했다.

README도 당시 구조와 기능에 맞춰 고쳤다.

cluster 등록부터 evidence 수집, report 조회와 export, 데이터 관리까지의 흐름을 정리했다.

다음 글에서는 전체 구조를 돌아보고 아쉬웠던 점과 앞으로 보완할 기능을 적으려고 했다.