Redis 3차 대규모 배포 장애 회고 — 기술·프로세스·조직의 복합 사고

2025-07-10, Redis 3차 대규모 배포일. 14:00 배포 예정이었지만 당일 오전부터 이슈가 겹치며 16:30으로 밀렸다. 초반엔 문제 없어 보였으나 저녁 시간대로 가면서 상황이 급격히 악화됐다.

18:26~18:38: 운영자가 서버 상의 velocity 템플릿을 vi로 직접 수정하면서 일부 서버에서 홈메인 화면이 미노출되기 시작했고, 곧 전체 서버로 확산되어 약 9분간 홈메인이 완전 먹통이 됐다.
같은 시간대(18:29~18:35): 마케팅팀의 프로모션 설정 실수로 모든 상품에 대규모 가격 오류(예: -18만 원, 0원)가 발생했다.
18:47~18:57: 긴급 롤백·재기동·stage 버전 재배포를 거쳐 18:57에야 전체 화면이 정상화됐다.

결과적으로 배포 일정이 크게 틀어졌고, 서비스 신뢰도와 팀 컨트롤 능력에 타격이 왔다.

이번 사건은 기술적 원인뿐 아니라, 의사결정·운영 프로세스·조직적 상호작용이 얽힌 전형적인 ‘사람·프로세스·시스템’ 복합 사고였다.

1. 사전 준비와 컨텍스트의 누락

배포 전 확인해야 할 항목(새로 추가된 gnb 형식 2종의 영향 범위, redis-api의 exists 체크 변경 등)을 적시에 확인하지 못했다. 결과적으로 배포가 2시간 30분 지연됐고, 피로·압박 속에서 성급한 판단이 나왔다.

2. 템플릿의 숨은 의존성 (기술 부채)

moduleMain.vm 같은 템플릿은 한 모듈에서만 쓴다고 보이기 쉽지만, 홈메인 등 다른 화면이 해당 블록의 존재를 전제로 의존하고 있었다. mdulShopGb 조건을 제거하자 홈메인에서 분기가 비어 불안정한 HTML이 생성됐고, 페이지 렌더링이 실패했다.

3. 긴급 대응 방식의 문제 (vi 직접 편집)

긴급 패치로 서버에 접속해 파일을 vi로 직접 수정하는 선택이 이루어졌다. 소규모 텍스트 변경이 빠를 수 있으나, 배포 파이프라인·환경 차이·인코딩·캐시 등의 변수를 무시하게 만들며, 동일 코드가 여러 화면에서 다르게 동작하는 상황에서 치명적이었다.

4. 동시다발적 인시던트와 인지 부조화

템플릿 이슈와 마케팅 프로모션 실수가 거의 같은 시간대에 터지며, 팀은 원인 판단과 우선순위 결정에 혼선을 겪었다.

5. 운영 권한·절차의 모호성

누가 어떤 상황에서 서버 파일을 직접 수정할 수 있는지 명확하지 않았다. 현장 판단으로 vi 수정이 용인됐고, 여러 사람이 개입해 합의는 됐지만 결과적으로 잘못된 결정이 내려졌다.

즉시 대응

서버 직접 편집 금지

긴급 변경도 반드시 배포 파이프라인(빌드 → 테스트 → 배포)을 통해 진행하도록 정책화했다. 서버 파일 직접 수정은 특별 승인 절차 없이 금지한다.

긴급 패치 프로세스 정의

심각도·영향 범위 기준으로 (1) 빠른 롤백, (2) 긴급 배포(파이프라인), (3) 직접 수정(극히 예외적, 감사 기록 필수)으로 분류했다.

템플릿 의존성 가시화

moduleMain.vm 등 핵심 템플릿 파일에 대해 의존성 맵을 작성했다. 어떤 페이지가 어떤 템플릿 블록을 포함하는지 문서화하고, 정적 템플릿 참조 스캐너 도입을 검토했다.

배포 전 체크리스트 강화

Redis 관련 변경이 있는 경우, 의존하는 모듈/화면 목록을 사전 식별해 테스트 케이스에 포함한다. 배포 D-1/D-0 체크리스트에 ‘영향받는 템플릿/변수/관리자 페이지 변경’ 항목을 추가했다.

운영·마케팅 교차 검증 루틴 도입

프로모션/캠페인 대규모 변경 시 운영팀 또는 QA가 사전 시뮬레이션으로 확인하도록 프로세스를 개선했다.

이 밤은 기술적 실수 한두 개가 아니라, 조직·문화·프로세스의 총체적 약점을 통째로 드러냈다.

이런 경험은 쓰라리지만, 팀의 성장을 촉진하는 귀한 자양분이기도 하다.