이행(Cutover) — 되돌릴 수 있게 나가라

한 줄 요약

이행은 배포가 아니라 여러 팀이 정해진 순서로 움직이는 작업이고, 그 성패는 롤백을 숫자로 된 기준으로 미리 정해 두었는가에 달려 있다.

왜 기준을 미리 정하는가

"문제 생기면 롤백하죠" 는 계획이 아니다. 새벽 세 시에 사람들이 지쳐 있을 때 '문제' 의 정의는 사람마다 다르고, 그 자리에서 판단하려 하면 늘 같은 일이 벌어진다 — 조금만 더 보자가 반복되다가 되돌릴 수 있는 시간을 넘긴다.

그래서 임계값과 관측 구간, 그리고 판단 시한을 계획서에 적어 둔다. "04:00 까지 스모크가 통과하지 않으면 되돌린다" 처럼 시각이 박혀 있으면, 그 시각에 판단하는 사람은 용기를 낼 필요가 없다. 이미 정해진 것을 실행하면 된다.

이행은 '배포'가 아니다

개발자에게 배포는 파일을 올리고 서비스를 재기동하는 일이다.
SI 에서 이행(移行, cutover) 은 그것보다 훨씬 넓다.

[사전]  이행 계획 승인 · 백업 · 공지 · 서비스 중단 안내 · 배치 정지 · 연동 상대 통보[본작업] DB 스키마 반영 → 데이터 이관 → 애플리케이션 배포 → 설정 반영 → 기동[검증]  스모크 테스트 → 핵심 업무 시나리오 → 연동 시스템 상호 확인 → 배치 재개[종료]  이행 결과 보고 → 상황실 운영 → 롤백 판단 시한 경과

한 번에 여러 팀이 정해진 순서로 움직인다. 그래서 이행에는 체크리스트와
타임라인이 있고, 각 항목에 담당자와 예상 소요, 그리고 '기대 결과'가 붙는다.
기대 결과가 없으면 그 항목이 성공했는지 아무도 판정할 수 없다.

롤백은 계획이 아니라 '기준'이다

"문제 생기면 롤백하죠"는 계획이 아니다. 새벽 3시에 사람들이 지쳐 있을 때
'문제'의 정의는 사람마다 다르다. 그래서 숫자로 된 기준을 미리 정한다.

| 지표 | 임계값 | 관측 구간 | 조치 |
| --- | --- | --- | --- |
| 주문 API 오류율 | 5% 초과 | 10분 | 롤백 |
| 로그인 응답시간 p95 | 3초 초과 | 15분 | 관찰 후 재평가 |
| 배치 지연 | 60분 초과 | 1회 | 롤백 |
| 데이터 정합성 불일치 | 1건이라도 | 즉시 | 롤백 |

그리고 롤백 판단 시한을 정한다. "새벽 4시까지 검증이 통과하지 않으면
무조건 되돌린다." 이 시한이 없으면 새벽 6시에도 "조금만 더 보자"가 반복되고,
결국 업무 시작 시간에 반쯤 고장 난 시스템으로 문을 연다.

백업 없이 시작하지 않는다

이행 체크리스트의 1번은 항상 백업이다. 그리고 백업은 '떴다'가 아니라
'복구가 된다' 를 확인해야 한다. 받아 본 적 없는 백업은 백업이 아니다.

최소한 이 셋은 챙긴다.

• DB 백업 (그리고 복구 소요 시간 실측치 — 3시간 걸리는 복구는 새벽 이행에서 롤백 수단이 아니다)
• 애플리케이션 산출물 (이전 WAR/JAR + 설정 파일)
• 설정 파일 (톰캣 server.xml, context.xml, nginx conf, 방화벽 정책, 배치 스케줄)

특히 설정 파일 백업을 빠뜨리는 사고가 흔하다. 애플리케이션은 태그로 되돌렸는데
server.xml 의 커넥터 설정이나 DB 커넥션 풀 크기는 누가 언제 바꿨는지 모르는 상태가 된다.

스모크 테스트 — 5분 안에 끝나야 한다

이행 직후 하는 스모크 테스트는 '기능이 다 되는지'가 아니라
'치명적으로 망가지지 않았는지' 를 5분 안에 확인하는 것이다.

• 서비스가 포트를 열고 응답하는가 (헬스체크)
• 로그인이 되는가
• DB 커넥션이 살아 있는가 (조회 1건)
• 연동 상대 시스템으로 나가는 호출이 되는가 (핵심 인터페이스 1건)
• 에러 로그에 새로운 예외가 쏟아지고 있지 않은가

이걸 자동화된 스크립트로 만들어 두면 새벽에 손이 떨려도 판정이 흔들리지 않는다.
사람이 화면을 눌러 보는 스모크 테스트는 사람이 피곤할수록 부정확해진다.

통합테스트에서 자주 터지는 것들

이행 전 통합테스트에서 나오는 결함은 패턴이 있다.

1. 환경 차이 — 개발계에서만 되는 것. 원인 1위는 설정 파일과 방화벽,
2위는 DB 데이터 상태(개발계엔 있는 코드값이 운영계엔 없음).
2. 연동 타이밍 — 상대 시스템 배치가 03:00 에 도는데 우리 배치가 02:50 에 돈다.
문서에는 둘 다 "새벽 배치"라고만 적혀 있었다.
3. 문자셋과 길이 — 한글 3바이트(UTF-8) vs 2바이트(EUC-KR). 컬럼 길이 20 에
한글 10자를 넣으려다 UTF-8 에서 잘린다.
4. 권한 — 운영계 DB 계정은 개발계보다 권한이 좁다. CREATE TEMP TABLE 이
안 되는 걸 이행 당일에 알게 된다.

이 넷을 이행 전에 운영계와 동일한 구성의 검증계에서 한 번 리허설하면
대부분 걸러진다. 리허설을 건너뛴 이행은 새벽에 즉흥 연주를 하게 된다.

이행 결과 보고서

새벽 작업이 끝나면 결과 보고서를 쓴다. 형식은 회사마다 다르지만 반드시 들어가는 것:

• 실제 시작/종료 시각과 계획 대비 차이
• 수행한 작업 목록과 각 결과
• 발생한 이슈와 조치 내역 (조치 못 한 것도 적는다)
• 백업 파일 위치와 롤백 절차 (안정화 기간 내내 참조된다)
• 다음 근무일 확인 사항

이 문서를 성실히 쓰면 안정화 기간의 장애 분석이 절반으로 줄어든다.
"오픈 때 뭐 바꿨죠?"에 답할 수 있는 유일한 문서이기 때문이다.

현장에서 만나는 모습

이행 실패의 전형은 기술 문제가 아니라 순서 문제다.

• 배치를 안 세우고 데이터 이관을 시작해서, 이관 중에 들어온 건이 누락된다.
• 연동 상대에게 통보하지 않아서, 상대 시스템이 우리 정지 구간에 전문을 보내고 그게 전부 실패로 쌓인다.
• 백업을 뜬 시각이 스키마 변경 뒤라서, 되돌리려는 순간 되돌릴 것이 없다.

그리고 검증 단계에서는 스모크 테스트가 길어지는 것이 문제가 된다. 5 분 안에 끝나지 않는 스모크는 판단 시한을 잡아먹어, 정작 되돌릴지 말지 정할 시간을 남기지 않는다. 스모크는 "핵심 업무가 도는가" 만 보고, 나머지는 상황실에서 본다.

이행 결과 보고서에 실제 백업 파일명을 적게 하는 것도 같은 이유다. "백업 완료" 라고만 적힌 보고서는 정작 필요할 때 어느 파일인지 알려 주지 못한다.