RCA 결과를 운영자가 이해할 수 있게 만들기: Web Console 설계

Kubernetes Cluster Infra RCA Platform 개발 기록 4편

지난 글에서는 Node Agent를 실제 Kubernetes 클러스터에 올리기 위해 DaemonSet, Helm Chart, smoke test 구조를 정리했습니다.

이제 Agent가 증거를 수집하고, Backend가 RCA report를 만들 수 있는 흐름은 어느 정도 잡혔습니다.

그 다음 고민은 이것이었습니다.

report가 만들어졌다고 해서, 운영자가 바로 이해할 수 있을까?

RCA 플랫폼은 단순히 JSON을 반환하는 API 서버로 끝나면 안 된다고 생각했습니다.

운영자는 장애 상황에서 빠르게 보고, 판단하고, 다음 행동을 정해야 합니다.
그래서 이번 단계에서는 Web Console을 붙이면서 RCA 결과를 어떻게 보여줄지 고민했습니다.

왜 Web Console이 필요했나

초기에는 API만 있어도 개발 흐름을 확인할 수 있었습니다.

curl로 cluster를 등록하고, evidence request를 만들고, report를 조회하면 최소 기능은 검증할 수 있습니다.

하지만 실제 운영 도구라면 이야기가 달라집니다.

운영자는 장애 상황에서 긴 JSON을 하나하나 읽고 싶지 않습니다.

필요한 것은 이런 화면입니다.

• 어떤 클러스터에서 문제가 발생했는지
• 어떤 노드가 영향을 받았는지
• RCA report가 언제 생성됐는지
• 원인 후보가 무엇인지
• 어떤 근거로 그렇게 판단했는지
• 추천 조치가 얼마나 위험한지
• 추가로 확인해야 할 것은 무엇인지

즉, Web Console은 단순한 UI가 아니라 운영자가 RCA 결과를 이해하는入口라고 볼 수 있습니다.

처음 Console에서 보여주고 싶었던 것

처음부터 화려한 대시보드를 만들 생각은 없었습니다.

우선 운영자가 꼭 봐야 하는 정보만 정리하려고 했습니다.

크게는 세 가지 화면을 생각했습니다.

Cluster 목록
  -> 등록된 클러스터 확인

RCA Report 목록
  -> 최근 장애 분석 결과 확인

RCA Report 상세
  -> 원인 후보, 근거, 추천 조치 확인

중요한 것은 많은 정보를 한 번에 보여주는 것이 아니라, 먼저 요약을 보여주고 필요할 때 근거로 내려갈 수 있게 하는 것이었습니다.

장애 상황에서는 화면이 복잡하면 오히려 판단이 느려질 수 있습니다.

그래서 report 목록에서는 핵심만 보여주고, 상세 화면에서 drilldown하는 방향으로 잡았습니다.

report는 결론보다 근거가 중요하다

RCA report에서 가장 조심해야 하는 부분은 “그럴듯한 결론”입니다.

예를 들어 화면에 이렇게만 나온다고 해보겠습니다.

Possible root cause:
container runtime issue

이 문장만 보면 뭔가 분석된 것처럼 보입니다.

하지만 운영자 입장에서는 바로 다음 질문이 생깁니다.

• 어떤 evidence를 보고 판단했는가?
• containerd가 실제로 죽은 것인가?
• socket 접근 권한 문제는 아닌가?
• kubelet log에는 어떤 내용이 있었는가?
• CNI나 DNS 증상도 같이 있었는가?

그래서 Web Console에서는 report의 결론만 보여주는 것이 아니라, 판단 근거를 같이 볼 수 있어야 한다고 봤습니다.

즉, UI의 목적은 “AI가 말한 답을 보여주는 것”이 아니라, 운영자가 그 답을 검증할 수 있게 하는 것이었습니다.

Policy 판단을 화면에 드러내기

이 프로젝트에서 계속 중요하게 본 것은 Policy Engine입니다.

RCA 결과가 어떤 조치를 추천하더라도, 그 조치가 안전한지는 별도로 판단해야 합니다.

예를 들어 이런 조치들이 있을 수 있습니다.

• kubelet 상태 확인
• containerd 재시작 검토
• 노드 cordon/drain
• CNI 설정 확인
• 디스크 정리
• 추가 로그 수집

이 중 어떤 것은 안전하지만, 어떤 것은 운영 중인 서비스에 영향을 줄 수 있습니다.

그래서 Web Console에서도 policy classification을 명확히 보여주는 것이 중요했습니다.

AUTO_SAFE
APPROVAL_REQUIRED
GITOPS_PR_ONLY
NEVER_AUTO_EXECUTE
MANUAL_INVESTIGATION

운영자가 report를 봤을 때 단순히 “무엇을 해야 하는지”만 보는 것이 아니라,
“이 조치가 얼마나 위험한지”까지 함께 봐야 한다고 생각했습니다.

특히 AI가 포함된 시스템에서는 이 부분이 더 중요합니다.

AI가 제안한 내용을 그대로 실행하는 것이 아니라, 정책 기준을 거쳐 운영자가 판단할 수 있게 해야 하기 때문입니다.

API와 Console을 붙이면서 생긴 문제

Web Console을 붙이면서 단순히 화면만 만드는 것이 아니라, Backend API와의 연결도 같이 정리해야 했습니다.

이 과정에서 신경 쓴 부분은 다음과 같습니다.

• 로그인 세션 처리
• 권한이 없는 API 접근 시 에러 표시
• Backend 연결 실패 처리
• report가 없을 때의 빈 상태 화면
• API 응답 형식이 바뀌었을 때의 방어 코드
• readiness check와 smoke test 연동

개발할 때 자주 생기는 문제 중 하나는 Backend는 정상인데 Console이 깨지는 경우입니다.

예를 들어 API 경로가 조금 바뀌었거나, 응답 필드 이름이 바뀌었거나, 인증 방식이 바뀌면 화면에서는 바로 에러가 날 수 있습니다.

그래서 Console에서는 에러를 너무 조용히 숨기지 않도록 했습니다.

운영자가 봤을 때 “아무것도 안 뜨는 화면”보다는,
“Backend 연결 실패”, “권한 없음”, “report 없음”처럼 상태를 구분해서 보여주는 것이 더 낫다고 봤습니다.

Codex를 어떻게 활용했는가

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

어떤 정보를 먼저 보여줄지, report 상세에서 어떤 근거를 보여줘야 할지, policy 판단을 왜 화면에 드러내야 하는지는 직접 고민해야 하는 부분이었습니다.

반면 반복적인 UI 코드나 API 호출 코드, 에러 처리 패턴은 Codex를 활용했습니다.

예를 들면 이런 작업입니다.

• report 목록 UI 구성
• cluster 목록 UI 구성
• API fetch 함수 정리
• 에러 메시지 처리 패턴 보강
• empty state 화면 구성
• README에 Console 실행 방법 정리
• smoke test에서 Console 확인 흐름 추가

Codex는 화면을 빠르게 만드는 데 도움이 됐습니다.

하지만 “어떤 화면이 운영자에게 필요한가”는 사람이 판단해야 한다고 생각했습니다.

역할을 나누면 이렇게 볼 수 있습니다.

사람:
운영자 관점 설계
report 정보 우선순위 결정
policy 노출 방식 판단
에러 상태 구분 기준 결정

Codex:
반복 UI 구현
API 호출 코드 정리
에러 처리 패턴 보강
문서 초안 정리

이 단계에서 가장 중요했던 점

이번 단계에서 가장 중요하게 본 것은 “보기 좋은 UI”가 아니었습니다.

중요한 것은 운영자가 장애 상황에서 빠르게 이해할 수 있는 UI였습니다.

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

1. report 목록에서는 핵심 정보만 보여준다
2. 상세 화면에서는 판단 근거까지 따라갈 수 있게 한다
3. AI 결과처럼 보이는 문장도 evidence와 함께 보여준다
4. 추천 조치는 policy level과 함께 보여준다
5. 에러는 숨기지 말고 상태별로 구분해서 보여준다
6. Console과 Backend 연결은 smoke test로 최소 검증한다
7. Codex는 구현 보조로 쓰고, 운영자 관점 설계는 사람이 한다

개인적으로는 3번과 4번이 가장 중요했습니다.

AI가 포함된 RCA 도구라면, 결과가 그럴듯해 보이는 것보다 근거와 위험도가 함께 보이는 것이 더 중요합니다.

마무리

이번 단계에서는 RCA report를 운영자가 실제로 볼 수 있는 형태로 만들기 위해 Web Console을 붙였습니다.

단순히 JSON을 예쁘게 보여주는 화면이 아니라,
운영자가 report 목록을 보고, 상세 화면에서 근거를 확인하고, 추천 조치의 위험도를 판단할 수 있는 구조를 목표로 했습니다.

이 과정을 거치면서 프로젝트가 조금 더 “운영 도구”에 가까워졌다고 느꼈습니다.

Backend가 분석하고, Agent가 증거를 모으고, Console이 운영자에게 판단 가능한 형태로 보여주는 구조가 잡히기 시작했기 때문입니다.

RCA report는 결론보다 근거가 중요하고, 조치 제안은 항상 위험도와 함께 보여야 한다.

다음 글에서는 이 프로젝트를 Docker Compose와 배포 패키징 구조로 정리하면서, 로컬에서 전체 플랫폼을 실행하고 검증할 수 있게 만든 과정을 정리해보려고 합니다.