이찬주

팝업 현장에서 결제가 제대로 되지 않아 고객이 그냥 돌아서는 장면을 본 뒤, 문제는 단순한 에러 하나가 아니라 매출과 신뢰가 바로 같이 깨질 수 있다는 점이라고 봤습니다.

그래서 예약·구매·관리자마다 달라지던 결제 생성 방식을 정리해 승인 확정을 하나의 엔드포인트로 수렴시켰고, 다날 AUTH -> BILL 흐름을 공통 Payment 모델과 domainType 전략으로 묶어 orderId·tid·결제 상태를 일관되게 추적했습니다. 인프라 단에서는 결제 관련 변경이 배포 중 흔들리지 않도록 EKS, Argo CD, Argo Rollouts 기반 운영 환경과 canary 기준을 함께 정리했습니다.

그 뒤로는 승인 기준과 변경 포인트를 한곳에서 관리할 수 있게 됐고, 운영 기간 동안 결제 드랍 및 관련 CS 없이 서비스했습니다.

상시 큰 트래픽을 받는 서비스는 아니었지만, 팝업 시작 시점이나 운영 이벤트가 붙는 순간에는 부하 편차가 생겼고 그 타이밍에 배포까지 겹치면 결제 흐름이 흔들릴 수 있었습니다.

그래서 기본 트래픽은 고정 EC2로 받고 피크 구간만 Karpenter 기반 ARM64 Graviton Spot 노드로 확장하도록 나눴습니다. k6 부하 테스트와 Datadog 지표를 함께 보며 readiness, graceful shutdown, RDS connection pool 한계를 확인해 DB pool과 warm capacity도 같이 조정했습니다.

그 뒤에는 트래픽이 얼마나 큰지보다, 피크 구간과 배포 직후 무엇을 먼저 확인해야 하는지 팀 안에서 같은 기준으로 설명할 수 있게 됐습니다.

처음에는 카페 내 영상으로 사람들의 반응을 분석해 주는 것이 핵심 가치일 거라고 생각했지만, 정말 중요한 질문은 고객이 그 정보에 실제로 돈을 낼 것인가였습니다.

그래서 카페 영상 데이터를 PDF 리포트로 제공하는 파이프라인을 직접 만들고, Lambda 기반 serverless와 AMI 기반 Spot 인스턴스를 나눠 비용 구조까지 맞춰가며 검증했습니다. 다만 실험을 거듭할수록 이 방식은 확장성과 법적 제약 면에서 오래 가져가기 어렵다고 봤고, 이후에는 태블릿 설문과 카페 쿠폰을 연결해 현장에서 즉시 반응을 확인하는 방식으로 방향을 돌렸습니다.

그 결과 브랜드·기업 고객이 진짜로 원하는 것은 분석 정보 자체보다 물품 판매를 직접 돕는 운영 수단에 더 가깝다는 걸 확인했고, 제품 방향도 판매 중심 운영 플로우로 피봇하게 됐습니다.

기존 2노드 microCeph 구성에서 노드 제거 중 정합성이 깨져 큰 데이터 손실이 발생했고, 그때 더 크게 보인 문제는 장애 자체보다 다음에 같은 일이 터졌을 때 누가 어떤 순서로 살릴 수 있는지 기준이 비어 있다는 점이었습니다.

그래서 클러스터를 다시 세우면서 물리 하드웨어와 디스크 구성을 정리하고, Ceph 3-copy를 활용할 수 있도록 3개 노드를 최대한 대칭적으로 맞췄습니다. 또 사용 가능한 장비가 3대뿐이어서 모든 노드가 control·storage·compute 역할을 함께 가지는 구조를 선택했고, 이기종 CPU 환경에서도 동작하는 인스턴스 정책과 실제 VM 라이브 마이그레이션까지 검증했습니다.

그 결과 한 노드 장애를 가정해도 다른 노드로 역할을 넘길 수 있는 운영 기준과 health check·내부 모니터링을 구축했고, 복구 순서와 점검 포인트를 문서로 남겨 후속 운영 인원이 같은 기준으로 대응할 수 있게 했습니다.

내부 툴·QA·개발용 워크로드를 VM으로 하나씩 운영하다 보니 목적과 기준이 점점 흐려졌고, 새 워크로드를 개별 Docker HA로 반복 구성하는 방식도 오래 버티기 어렵다고 봤습니다.

그래서 kubeadm 기반 3 Master HA 클러스터를 구성하고 OpenStack Cloud Controller Manager, Octavia, Cinder CSI를 연동해 Kubernetes LoadBalancer와 PVC 요청이 실제 OpenStack 리소스로 이어지도록 검증했습니다.

그 뒤로는 워크로드를 VM이나 개별 HA로 따로 설명하는 대신, 어떤 성격의 워크로드를 어떤 기준으로 올릴지 공통 플랫폼 관점에서 정리할 수 있게 됐습니다.

Skyline과 수동 요청 처리만으로는 학생 사용자의 클라우드 경험도, 운영자 업무 부담도 같이 해결하기 어려웠고, 그대로 두면 결국 OpenStack을 아는 사람만 쓸 수 있는 환경에 머물 거라고 봤습니다.

그래서 OpenStack 기반 교내 클라우드를 더 쉽게 쓰게 하는 통합 콘솔 플랫폼을 기획했고, 초기 8명 팀을 12명 규모로 확장해 디자인·프론트·Auth·OpenStack의 4개 서브그룹 체계로 재구성했습니다. 동시에 공통 아키텍처, 문서, Git 이슈·MR 규칙, 학생 사용 흐름에 맞는 API 계층과 서비스 개념을 먼저 정리해 복잡한 원개념이 그대로 노출되지 않게 했습니다.

그 결과 핵심 기능만 만든 팀이 아니라, 다음 개발 인원이 이어받아 확장할 수 있는 문서·API 기준·협업 구조까지 함께 남길 수 있었습니다.

초기 팀이 아이디어와 요구사항을 빠르게 정리하고 공유할 수 있도록, 실시간 기획 플랫폼을 만드는 것이 목표였습니다.

저는 백엔드 개발과 인프라 운영을 맡았고, 실시간 협업 기능은 Liveblocks, Sendbird 같은 SaaS를 적극 활용해 직접 모든 기반 기능을 다시 만들기보다 제품 경험 완성에 집중했습니다. 배포와 장애 알림 체계도 함께 구성해 운영 부담을 줄였습니다.

SW인재페스티벌 최우수상과 AJOU SOFTCON 최우수상·인기상을 수상했습니다.

GitOps 기반 배포 환경을 직접 구성해보며, 작은 팀이 어떤 순서로 인프라와 배포 기준을 잡아가는지 학습하기 위해 진행한 프로젝트입니다.

이 과정에서 Terraform, Helm, Ansible을 사용해 보며 각각의 역할과 기초적인 사용법을 익혔고, 선언형 인프라와 배포 자동화 흐름을 실습 형태로 경험했습니다.