도입부: 온프레미스에서 k8s, Ceph, 클라우드, LaaC까지 빠르게 밀어붙였지만 정작 안정성을 확보하지 못해 신뢰를 잃었던 경험을 정리해봅니다. 이 글을 통해 “전환을 성공으로 보이게 하는 것”과 “운영 가능한 상태로 만드는 것”의 차이를 얻어가실 수 있습니다.
우리가 했던 전환: 기술 부채를 한 번에 청산하려던 욕심
출발점은 전통적인 온프레미스 APM 환경이었습니다. 여기서 다음을 거의 동시에 추진했습니다.
- Kubernetes 클러스터 구축
- Ceph 도입(스토리지 계층까지 플랫폼화)
- 클라우드 전환
- LaaC/형상관리 기반 운영(사실상 GitOps 지향)
지금 돌아보면 문제는 “기술 선택이 틀렸다”라기보다, 전환의 핵심 가치(안정성)를 검증하기 전에 복잡도를 먼저 올린 것이었습니다. 전환 자체는 화려해 보였지만, 운영의 관점에서 “언제든 안전하게 바꿀 수 있는 상태”가 아니었습니다.
장애는 트래픽이 아니라 ‘휴먼에러’에서 터졌습니다
흥미롭게도 네트워크/트래픽 기반의 구조적 장애는 거의 없었습니다. 대신 치명타는 전환 과정의 세팅/운영 휴먼에러였습니다.
- 세팅 과정에서 휴먼에러로 장시간 장애 2건
- 배포 과정에서 HTTP 500번대 웹 접속 오류 유발
이 경험이 남긴 인상은 기술적으로는 더 아팠습니다.
- “인프라가 복잡하고 어렵다”
- “만지면 깨진다”
- “이전보다 안정성이 떨어졌다”
이 인상은 한 번 각인되면, 이후 어떤 개선을 해도 회복 비용이 큽니다. 결국 인프라는 기술이 아니라 팀 신뢰로 굴러가는데, 그 신뢰를 잃었습니다.
1년이 지나도 마이그레이션이 끝나지 않았던 이유
전환을 장기화시킨 건 단순히 일이 많아서가 아니었습니다. 복잡도가 높아질수록 아래가 동시에 발생합니다.
- 변경 1건당 영향 범위가 커짐(배포/스토리지/네트워크가 얽힘)
- “검증해야 할 것”이 기하급수로 증가
- 장애가 나면 원인 추적이 길어짐(특히 1인 운영 환경에서는 더 치명적)
결국 “계속 개선하면 언젠가 안정화된다”는 믿음으로 1년을 썼지만, 복잡성이 해소되지 않으면 안정성도 따라오지 않는다는 결론에 도달했습니다. 그래서 저는 현 접근의 실패를 인정해야 한다고 봅니다.
B2B + 저트래픽 + 1인 운영: 우리가 놓친 전제
대화에서 결정적이었던 조건은 이 조합이었습니다.
- 현재 트래픽이 거의 없는 B2B
- “월 100만원도 아깝다”는 비용 압박
- 관리 인력 1명
- 단, 데이터 유실은 0이어야 함
- 그리고 역설적으로 GitOps의 편안함은 분명히 유효했음
여기서 핵심은 “플랫폼의 선진성”이 아니라 운영 모델이 조직 조건과 맞는가입니다. 저트래픽/1인 운영에서 k8s+Ceph는 “효율화”가 아니라 “상시 복잡도”가 되기 쉽습니다. 반대로 GitOps는 잘라서 쓰면(관리 범위를 제한하면) 1인 운영에서 큰 힘이 됩니다.
인사이트: “안정성·단순화·비용”을 동시에 잡으려면, 무엇을 포기할지 먼저 정해야 합니다
저는 이번 실패에서 세 가지를 배웠습니다.
1) 안정성은 ‘장애가 없었던 기록’이 아니라 ‘실수해도 덜 망하는 구조’입니다
우리 장애의 대부분은 트래픽이 아니라 변경 과정에서의 실수였습니다. 그러면 안정성은 다음 질문으로 바뀝니다.
- 배포/설정 변경을 내가 실수해도 쉽게 복구할 수 있는가?
- 영향 범위를 작게 쪼갰는가?
- 복구 절차가 자동화/문서화되어 있는가?
2) GitOps는 만능이 아니라 “적정 범위”가 있을 때 편안합니다
1인 운영에서 GitOps의 장점은 분명합니다.
- 변경 이력 추적
- 드리프트 방지
- 롤백 가능성
- 환경 재현성
다만 플랫폼 자체(k8s/Ceph)를 GitOps 범위에 깊게 포함시키면, “선언적으로 편하다”가 아니라 “변경이 너무 자주/넓게 번진다”로 뒤집힐 수 있습니다. 저는 앞으로 GitOps의 적용 범위를 ‘얇은 레이어’로 줄이는 방향을 더 진지하게 보려고 합니다.
3) “데이터 유실 0”은 비용을 올리는 요구사항이 아니라, 설계를 명확히 하는 요구사항입니다
데이터 유실 0은 사실상 RPO=0에 가까운 요구입니다. 그런데 이게 어디까지의 장애를 의미하는지(디스크/노드 수준인지, IDC/리전급인지) 정의하지 않으면, 비용과 복잡도가 끝없이 커집니다.
- “디스크 1개/노드 1대 장애까지 유실 0”과
- “리전 장애에서도 유실 0”
은 완전히 다른 게임입니다.
그래서 결론: 실패를 인정하는 게 다음 선택을 가능하게 합니다
지금 저는 “더 잘하면 되지 않을까”를 내려놓고, 안정성과 단순화, 그리고 비용을 기준으로 대안을 다시 세우는 단계로 가야 한다고 생각합니다. 특히 1인 운영이라면 “기술 스택의 멋”보다 “실수했을 때 복구 가능한가”가 훨씬 중요했습니다.
마무리: 이렇게 구성된 인프라를 불안함으로 운영할지, 새로 새롭게 시작할지 선택에 기로에 서 있습니다. 무엇보다 중요한건 실패를 인정하고 끝나는 것이 아니라 끝까지 서비스에 책임을 지는 것이라 생각합니다. 어느 방향이던 사용자에게 가장 중요한 것은 안정성이라는 것을 통감하며 끝 맺음과 또 다른 시작을 해보겠습니다.