클라우드 콘솔을 쓰다 보면 누구나 한 번쯤 겪는 순간이 있다. VM 하나 생성해놓고 대시보드에서 상태가 바뀔 때까지 새로고침을 연타하는 그 경험. 카카오클라우드 팀도 이 문제를 잘 알고 있었고, 결국 콘솔 전체를 뜯어고치기로 결정했다.
API 호출 지옥에서 탈출하기
기존 카카오클라우드 콘솔의 구조는 대부분의 클라우드 서비스와 비슷했다. 화면을 그릴 때마다 각 서비스의 API를 직접 호출하고, 여러 응답을 조합해서 하나의 뷰를 만드는 방식. VM 목록 하나 보여주려면 컴퓨트 API, 네트워크 API, 볼륨 API를 각각 부르고 클라이언트 사이드에서 합쳐야 한다.
규모가 커지면서 문제가 드러났다. 서비스가 늘어날수록 API 조합의 복잡도가 폭발적으로 증가하고, 상태 변경 감지는 주기적 폴링에 의존할 수밖에 없었다. "Creating" 상태에서 "Running"으로 바뀌는 걸 확인하려면 5초마다 API를 때려야 했다. 사용자 경험도, 서버 부하도 좋을 리 없다.
이건 카카오클라우드만의 문제가 아니다. 거의 모든 클라우드 콘솔이 초기에 이 패턴으로 시작한다. 서비스 API가 이미 존재하니까 콘솔은 그걸 호출해서 화면에 뿌리면 되지 않느냐는 논리. 서비스 3~4개까지는 통한다. 10개를 넘기면 유지보수 지옥이 열린다.
CDC + ETL + SSE — 데이터가 흐르는 콘솔
3월 13일 공개된 새 콘솔의 핵심은 "데이터 중심 콘솔(Data-centric Console)"이라는 설계 원칙이다. 겉보기엔 거창하지만 파이프라인 구조를 뜯어보면 꽤 명쾌하다.
각 서비스의 데이터 변경을 CDC(Change Data Capture)로 실시간 감지한다. Debezium과 Kafka 조합이 그 역할을 맡는다. 변경 이벤트가 ETL 파이프라인을 거치면서 콘솔 전용 데이터 계층에 적재된다. 여기서 핵심은 ETL 단계에서 복잡한 비즈니스 로직을 미리 변환해서 저장한다는 점이다. 화면 렌더링 시점에 무거운 계산이 필요 없어진다.
마지막 퍼즐은 SSE(Server-Sent Events)다. 변경된 데이터를 즉시 브라우저로 푸시한다. 새로고침 버튼을 누를 이유가 사라진다.
이 구조의 장점은 "실시간"에 그치지 않는다. 콘솔이 서비스 API에 직접 의존하지 않기 때문에, 서비스 쪽에서 API 스펙을 바꿔도 콘솔에 미치는 충격이 줄어든다. ETL 계층이 완충 역할을 하는 셈이다. 반대 방향으로도 이득이 있다 — 콘솔에서 필요한 데이터 형태를 자유롭게 가공할 수 있어서, 새로운 뷰를 추가하는 속도도 빨라진다.
WebSocket 대신 SSE를 택한 점도 눈에 띈다. 클라우드 콘솔은 서버→클라이언트 단방향 푸시가 대부분이라 양방향 통신이 필요한 WebSocket은 오버스펙이다. SSE는 HTTP 위에서 동작하고 로드밸런서 호환성도 좋아서 인프라 운영 입장에서 훨씬 가볍다.
Module Federation이라는 선택
프론트엔드도 동시에 바뀌었다. Webpack Module Federation 기반 마이크로프론트엔드 구조를 도입했다. 각 서비스 팀이 자기 콘솔 모듈을 독립적으로 개발하고 배포할 수 있다. 한 서비스의 모듈에 버그가 있어도 다른 서비스 화면에는 영향을 주지 않는 격리 구조다.
서비스가 20개, 30개로 늘어날 때 이게 결정적으로 중요해진다. 모놀리식 콘솔에서는 배포 한 번이 전체 장애 리스크를 안고 있었는데, 그 부담이 서비스 단위로 쪼개진다.
왜 하필 지금이었나
카카오클라우드가 이 시점에 대규모 리아키텍처를 단행한 배경에는 몇 가지 맥락이 겹친다.
서비스 수가 임계점을 넘었다. Compute, Networking, Storage, Analytics, AI까지 카테고리가 확장되면서 기존 방식의 한계가 운영 비용으로 체감됐을 가능성이 높다. AWS나 GCP 콘솔 경험이 사실상 벤치마크가 된 상황도 무시할 수 없다. 후발주자가 기능만 따라가서는 승산이 없고, 아키텍처 수준에서 우위를 가져가야 한다. 실시간 반영은 그 차별화의 한 축이 될 수 있다.
3월 릴리즈에서 VM, VPC, Load Balancing, DNS, IAM 같은 핵심 인프라 서비스에 먼저 적용하고 나머지를 순차 전환하겠다는 전략도 읽을 거리가 있다. 빅뱅 전환이 아니라 증명하면서 확장하는 접근이다. 새 아키텍처가 실제로 운영 부하를 줄이는지, 개발 속도가 빨라지는지 데이터를 모은 뒤 확대하겠다는 의미다.
장밋빛만은 아닌 부분
CDC 파이프라인은 운영 복잡도를 확 끌어올린다. Kafka 클러스터 관리, Debezium 커넥터의 스키마 변경 대응, ETL 변환 로직의 버전 관리까지 — 콘솔팀이 짊어져야 할 인프라 부담이 만만치 않다.
서비스별 데이터 모델이 독립적으로 진화하는 MSA 환경에서, ETL 계층이 오히려 새로운 병목이 되지 않을지도 지켜봐야 한다. "API 호출 지옥"을 "파이프라인 관리 지옥"으로 바꾼 건 아닌지.
그럼에도 콘솔이라는 제품의 정체성을 "API 래퍼"에서 "데이터 뷰어"로 재정의한 시도 자체는 주목할 만하다. KT Cloud, NHN Cloud, 네이버 클라우드까지 한국 클라우드 플레이어들이 모두 비슷한 고민을 안고 있을 텐데, 카카오클라우드가 먼저 답을 내놓았다. 이 구조가 서비스 규모가 두세 배 커졌을 때도 버텨주는지 — 올해 하반기쯤이면 윤곽이 잡힐 것이다.