도입부: K8s를 배우고 자격증도 따고 이직도 했는데, 막상 현업에서는 장애와 운영 부담이 커지며 번아웃이 오는 순간이 있습니다. 이 글에서는 제가 겪은 “마이그레이션 이후의 진짜 일(운영 안정화/표준화)”과, 정체감·불안을 줄이기 위해 무엇을 우선순위로 잡아야 했는지 정리해봅니다.
“마이그레이션 마무리”의 착각: (1) 이관 ≠ (2) 운영 안정화 ≠ (3) 팀 표준화
저는 한동안 “K8s 마이그레이션을 마무리하면 숨통이 트이겠지”라고 생각했습니다. 그런데 실제로는 마무리의 기준이 여러 겹이었습니다.
- (1) 워크로드 이관 완료: 서비스가 쿠버네티스에서 뜬다
- (2) 운영 안정화: 장애/배포/스케일링이 예측 가능하고, 대응 비용이 낮다
- (3) 팀 표준화·확산: 누구나 같은 방식으로 운영하고, 책임과 절차가 정리됐다
문제는 (2)가 막히면 (3)은 구조적으로 불가능해진다는 점입니다. 장애가 빈번한 상태에서는 표준화를 논의할 여유도, 신뢰도, “다 같이 바꾸자”는 동력도 사라집니다. 결국 “마이그레이션은 했는데 일이 더 늘었다”는 상황이 됩니다.
번아웃의 트리거: 고위험 변경이 ‘개발 환경 절차’로 운영에 들어온 순간
제가 겪었던 치명적인 사건들은 공통점이 있었습니다. **환경 분리/갱신 같은 변경 작업이 운영 트래픽과 스토리지까지 한 번에 흔드는 큰 블라스트 레디우스(blast radius)**를 가졌다는 점입니다.
사례 1) EKS 환경 분리 중 하드코딩으로 운영 ALB가 비정상 동작
- 환경을 나누는 과정에서 하드코딩된 요소 때문에 운영 ALB가 제대로 작동하지 않는 상태가 발생했습니다.
- “설정 드리프트(configuration drift)”가 생기기 쉬운 구조였고, 재현/검증이 어려웠습니다.
사례 2) 온프레미스 RKE2 인증서 갱신 → 노드 멈춤 → Ceph 깨짐 → 전 서비스 사용 불가
- 인증서 갱신 작업 중 클러스터 노드가 멈췄고, 이어 Ceph 클러스터까지 깨지며 운영 중이던 모든 서비스가 사용 불가가 됐습니다.
- 더 뼈아팠던 건 “다른 클러스터에서도 했으니 괜찮다”는 유사성 가정이 실제 환경 차이(의존성/부하/스토리지 상태/운영 트래픽) 앞에서 무너졌다는 점입니다.
이때부터 제 머릿속에 박힌 문장은 이거였습니다.
- “이건 내 실수다.”
- “팀 신뢰를 잃었다.”
- “아무것도 손대고 싶지 않다.”
긴장감과 업무과중이 쌓인 상태에서, 한 번의 크리티컬 장애가 트리거가 되어 번아웃이 폭발했습니다.
문제를 “개인 실수”가 아니라 “시스템 부재”로 재정의하기
여기서 저는 관점을 바꿔야 했습니다. 물론 제 책임이 있습니다. 하지만 이 문제를 “개인의 실수”로만 정의하면 남는 건 죄책감과 위축뿐입니다. 반대로 이렇게 재정의하면 다음 액션이 달라집니다.
- 개인 실수: 더 조심하자, 더 공부하자, 더 야근하자
- 시스템 부재: 고위험 변경에 필요한 가드레일(절차/롤백/리허설/중지선)이 없다 → 시스템을 만든다
운영에 들어간 서비스라면 “속도”보다 “안전”의 비중을 올려야 합니다. 특히 인증서 갱신/스토리지/클러스터 업그레이드 같은 작업은 실패를 전제로 설계해야 합니다.
제가 특히 크게 느낀 건 이 부분입니다.
- 장애를 0으로 만든 다음에 가드레일을 세우는 게 아니라
- 가드레일을 먼저 세워서 장애 대응 비용을 낮추는 게 현실적이라는 점입니다.
알림이 있는데도 번아웃이 오는 이유: 기준 없는 알림은 “소음”이 된다
저희는 알림을 초기부터 사용하고 있었습니다. 그런데 운영이 시작되니 알림이 “안전장치”가 아니라 “소음 제조기”가 되었습니다.
- 오탐/정탐을 나누는 기준이 없다
- 심각도(Severity) 기준이 없다
- 무엇이 “사람을 깨워야 하는 사건”인지 정의가 없다
결국 온콜은 계속 울리고, 피로는 누적되고, 중요한 알림은 묻히고, 팀은 더 불안해집니다.
제가 세우고 싶었던 최소 기준: “페이징은 사용자 영향 중심”
알림을 만들 때 지표를 더 붙이는 것보다 먼저 필요한 건 정의였습니다.
- 새벽에 울리면 반드시 사람을 깨워야 하는 사건 = 사용자 영향이 명확한 사건
- 예:
5xx 비율 > X%,p95 latency > Yms,성공률 < Z%,가용성 저하
- 예:
- 그 외는 페이징이 아니라 티켓/대시보드로 내려서 운영 부담을 조절
여기서 핵심은 “알림의 수”가 아니라 알림의 목적과 라우팅입니다. 같은 경고라도 누군가를 깨워야 하는지, 아침에 처리해도 되는지, 관찰만 하면 되는지 레벨이 나뉘어야 했습니다.
“현업 성과로 연결되는 활동” vs “불안을 달래기 위한 활동”을 가르는 기준
처음에 제가 던졌던 질문으로 돌아가면, 지금 제 상황에서 답은 꽤 분명해졌습니다.
- 현업에서 바로 성과로 연결되는 활동
- 운영 안정화(2번)를 위한 가드레일 만들기: 변경 절차, 롤백 플랜, 리허설, 동결 기준, 알림 기준(SLO/SLI/Severity)
- 블라스트 레디우스 줄이기: 변경을 작게 쪼개고(단계적 전환), 되돌릴 수 있게 설계
- 불안을 달래기 위한 활동
- 자격증/도전 자체가 당장 운영 리스크를 낮추지 못하는데도 “안 하면 불안해서” 붙잡는 학습들
- “더 공부하면 해결될 것”이라는 환상 아래, 실제로는 운영 시스템 개선을 미루는 행동들
저는 K8s 자격증이나 Kubestronaut 같은 목표가 나쁘다고 생각하지 않습니다. 다만 번아웃 구간에서는 **‘내 불안을 진정시키는 공부’보다 ‘팀의 불안을 줄이는 운영 시스템’**이 더 즉각적인 신뢰 회복으로 이어졌습니다.
마무리: 마이그레이션의 끝은 “이관”이 아니라 “운영이 덜 아픈 상태”입니다
제가 겪은 정체감과 번아웃은 “노력 부족”이 아니라, 마이그레이션 이후에 등장하는 **운영 안정화의 현실(절차/롤백/알림 기준/변경관리)**을 개인이 감당하려 했던 데서 커졌습니다. 이제는 더 잘 버티는 사람이 되기보다, 실패해도 무너지지 않는 시스템을 만드는 쪽으로 제 에너지를 쓰려고 합니다.
