선박 배포 모니터링 UI/UX 개선 전략

1. 서론: UI 설계의 한계를 넘어 배포 파이프라인 분석이 필요했던 이유

Nextree 기획자로서 111척 이상의 선박의 배포를 관리하는 배포 모니터링 시스템의 UI/UX 개선을 맡게 되었습니다. 각 선박은 ISS, Vizend, Blueone 등 독립적인 시스템으로 구성되며, 이는 다시 수많은 Kubernetes Pod(서비스) 단위로 쪼개져 운영되는 복잡한 구조였습니다.

기존 UI는 이러한 기술적 파편화를 화면에 그대로 노출하고 있었습니다. 운영자가 특정 선박의 장애를 파악하려면 하위 서비스들의 상태를 일일이 탐색해야만 했고, 이는 심각한 인지 부하와 운영 효율 저하로 이어졌습니다. 저는 이 문제의 본질이, '복잡한 배포 메커니즘을 사용자 의사결정 구조로 치환하지 못한 것'에 있다고 판단했습니다.

이 문제를 해결하기 위해 단순한 UI 개선이 아니라, 배포 파이프라인과 실행 구조를 해석하고 이를 사용자 의사결정 구조에 맞게 재구성하는 것을 목표로 설정했습니다.

2. 현상 분석: 파편화된 모니터링 구조의 한계 (As-is)

기존 시스템은 다음과 같은 한계를 가지고 있었습니다.

첫째, 과도한 탐색 단계입니다.

선박 검색 이후 상세 화면에 진입하고, 다시 시스템 탭으로 이동해야 서비스(Pod) 상태를 확인할 수 있는 구조였습니다. 이로 인해 어떤 선박이 어떤 서비스에서 장애가 발생했는지 즉시 파악이 어려워, 장애 발생 시 즉각적인 대응이 어려웠습니다.

둘째, 일괄 배포와 선박 단위의 통합 배포 상태 정의 부재입니다.

한 선박 내에서도 여러 시스템과 해당 시스템 내에도 서비스들이 존재하며, 서비스마다 배포 진행 단계 및 상태가 상이합니다. 이처럼 서비스 간 상태가 혼재되어 있다 보니, 선박 전체를 하나의 단위로 묶어 상태를 정의하거나 일괄 배포를 수행하기 위한 공통 가이드라인이 부족한 상태였습니다.

셋째, 핵심 배포 상태의 비가시성입니다.

Failed(배포 실패), Staged(사용자 수동 승인 대기)와 같이 즉각적인 조치가 필요한 배포 상태가 메인 화면에서 노출되지 않아, 운영자는 어떤 선박을 우선적으로 확인해야 하는지 빠르게 판단하기 어려웠습니다. 결과적으로, 정보는 존재하지만 운영자의 의사결정을 지원하는 형태로 구조화되어 있지 않은 상태였습니다.

3. 기술적 분석: 배포 프로세스 및 구조 분석

육상-선상 배포 프로세스

구조적 특성

첫째, 비동기 배포 프로세스입니다.

각 서비스는 이미지 다운로드, 빌드, 배포, 실행까지 소요되는 시간이 각기 다릅니다. 이로 인해 동일한 선박 내에서도 서비스별로 상태가 변경되는 시점에 차이가 발생합니다.

둘째, 서비스 간 의존성 문제입니다.

특정 서비스만 업데이트될 경우 의존 관계에 있는 서비스들 간의 프로세스가 꼬이거나 오류가 발생할 위험이 존재했습니다.

셋째, '안전핀' 역할의 Staged 상태입니다.

Staged 상태는 사용자 승인 시점을 통해 서비스 간 배포 타이밍을 동기화하는 전략적 제어 지점입니다.

4. 설계 전략: 상태를 “의사결정 기준”으로 재구성하기

첫째, 위험도 기반 상태 우선순위 정의

Fail > Deploying > Deployed 순으로 단순화하여 즉시 대응 대상 식별이 가능하도록 했습니다.

둘째, 하향식 상태 집계 구조

하위 서비스 중 가장 위험한 상태가 상위 상태를 결정하도록 설계했습니다.

셋째, 시스템 상태 병렬 배치

ISS, Vizend, Blueone을 수평 구조로 배치하여 탐색 없이 전체 상태 파악이 가능하도록 했습니다.

5. 핵심 의사결정

[과제 1] Staged 유지 vs 자동화

구조는 유지하되 자동화와 UI 단순화를 통해 운영 부담을 줄였습니다.

[과제 2] 예외 대응 설계

6. 성과

복잡한 배포 상태를 선박 단위 의사결정 정보로 변환하여 운영 효율과 대응 속도를 크게 개선했습니다.

7. 결론

시스템 구조를 이해하고 이를 사용자 의사결정 구조로 변환하는 것이 UI 설계의 핵심임을 확인했습니다.