성균관대학교 시스템컨설턴트그룹 (SCG) · 2022 – 2026

교내 실사용 서비스 약 15개의 Kubernetes · GitOps 전환

서비스마다 배포 방식이 달랐고 일부는 10년 넘은 레거시였다. 한 번에 옮기지 않고 의존성부터 확인해 순차 전환했다.

제원

서비스마다 배포 방식이 달랐다. PM2로 도는 것도 있고 Docker로 도는 것도 있었다. 10년 이상 된 레거시 프로젝트는 로컬 파일시스템과 특정 서버 환경에 강하게 묶여 있었다.

운영 방식의 상당 부분이 사람의 경험에 의존했다. 어떤 서버에서 무엇이 돌고 있는지가 문서가 아니라 기억에 있었다.

한 번에 전부 옮기지 않았다. 서비스별로 stateless인지 stateful인지, 로컬 파일시스템과 DB에 어떻게 의존하는지, 파일을 어디에 저장하는지, 중단 시 영향과 복구 가능성이 어떤지를 먼저 확인했다.
이전 가능한 서비스부터 Kubernetes로 단계적으로 옮겼다. 옮길 수 없는 것은 옮기지 않고 이유를 기록했다.
원하는 상태를 Git에 정의하고 ArgoCD로 클러스터와 동기화했다. Helm으로 서비스별 차이를 값으로 분리했고, GitHub Actions가 이미지 빌드를 담당했다.
ArgoCD가 Sync 상태인 것으로 배포 확인을 끝내지 않았다. 배포 후 Pod가 실제로 교체됐는지, 컨테이너 상태가 정상인지, 서비스가 응답하는지까지 확인했다. 선언된 상태와 실제 동작은 같지 않을 수 있다.
Vault로 Secret을 관리해 인증정보가 코드나 일반 설정에 노출되지 않도록 했다. Grafana 기반 모니터링을 운영하면서 Health Check 결과와 실제 서비스 상태의 차이도 함께 다뤘다.

그림 gitops loop

Sync 상태는 배포 확인이 아니다. 실제 응답까지 본다.

운영 서비스

~15

교내에서 실제 사용되는 웹서비스.

최장 레거시

10y+

로컬 파일시스템과 서버 환경에 강하게 의존.

etcd 장애, 단일 장애점, 노드 장애, 고가용성, stateful workload와 persistent storage, DB를 클러스터 내부에 둘지 외부에 둘지 — 이 항목들은 운영 과정에서 검토하고 팀 내에서 논의한 것이며, 내가 직접 구축한 구성이 아니다.
인프라 구성 관리 도구(Terraform, Ansible 등)는 사용하지 않았다.
단체 인프라는 팀 단위로 운영했고, 나는 총괄과 기술 의사결정을 맡았다.