안정화 기간과 SM 으로의 인수인계

한 줄 요약

안정화는 남은 버그를 고치는 시간이 아니라 운영 조직이 스스로 굴릴 수 있게 만드는 시간이고, 이걸 오해하면 계약이 끝난 뒤에도 전화가 온다.

왜 이게 문제인가

급한 일과 중요한 일이 정확히 반대 방향에 있기 때문이다. 오픈 직후에는 장애와 문의가 쏟아지므로 하루가 대응으로만 채워지고, 운영 문서화와 지식 이전은 "이번 주만 넘기고" 로 계속 밀린다.

그렇게 안정화 기간이 끝나면 SM 담당자는 시스템을 모른 채 인수받는다. 그 결과가 몇 달 뒤 새벽 두 시의 전화다 — 계약은 끝났는데 물어볼 사람이 당신뿐이라서. 안정화의 성과는 "장애가 몇 건이었나" 가 아니라 "이제 우리 없이 돌아가는가" 로 재야 한다.

안정화 기간은 보통 3~6개월이다

계약서에 '안정화 기간'이라는 항목이 있다. 오픈 직후 일정 기간 동안 수행사가
장애 대응과 초기 결함 수정을 책임지는 구간이다. 이 기간의 성격을 오해하는
신입이 많다. 안정화는 '남은 버그를 고치는 시간'이 아니라
'운영 조직이 스스로 굴릴 수 있게 만드는 시간' 이다.

그래서 안정화 기간에 해야 할 일은 세 갈래다.

1. 실제 장애·문의 대응 (급한 일)
2. 운영 문서화 — 운영자 매뉴얼, 장애 대응 절차서, 배치 운영 가이드 (중요한 일)
3. 지식 이전 — SM 담당자 교육, 동행 근무, 인수인계 확인서 (계약상 의무)

급한 일에만 매달리면 안정화가 끝나는 날 SM 담당자는 아무것도 모른 채 남는다.
그리고 6개월 뒤 새벽 2시에 당신에게 전화가 온다. 계약은 끝났는데 전화는 온다.

오픈 직후 일주일에 실제로 무슨 일이 일어나는가

| 시점 | 전형적인 이슈 |
| --- | --- |
| 오픈 당일 오전 | 로그인 폭주 — 전 직원이 동시 접속. 커넥션 풀·세션 설정이 첫 관문 |
| 1~2일차 | 화면 오류 문의. 대부분 데이터 문제(코드값 누락, 이관 데이터 이상) |
| 3일차 | 첫 야간 배치 결과 이상. 데이터 이관 경계 조건 |
| 1주차 | 월말/주간 업무 최초 수행. "이 화면 어디 있어요?" 문의 급증 |
| 1개월 | 첫 월 마감. 통계·정산 숫자가 안 맞는다는 신고 |

패턴이 보인다. 오픈 직후 이슈의 다수는 코드 결함이 아니라 데이터와 설정이다.
그래서 이행 때 만든 데이터 검증 스크립트와 설정 백업이 안정화 기간 내내 쓰인다.

장애 대응의 표준 흐름

현장에서는 이 순서를 벗어나면 대개 더 나빠진다.

1. 접수·기록      언제, 누가, 무슨 화면에서, 어떤 메시지2. 영향 범위 파악  전체인가 일부인가. 특정 사용자/특정 데이터만인가3. 임시 조치      서비스 복구 우선 (재기동, 우회, 기능 임시 차단)4. 원인 분석      로그·모니터링·최근 변경 이력5. 항구 조치      코드/데이터/설정 수정과 배포6. 재발 방지      모니터링 추가, 검증 로직 추가, 문서 갱신

3번과 4번의 순서를 바꾸지 마라. 원인을 다 파악한 뒤 조치하겠다는 태도는
장애 시간을 늘린다. 다만 3번을 하면서 증거는 반드시 남긴다 — 재기동 전에
스레드 덤프와 로그를 확보하지 않으면 원인을 영원히 못 찾는다.
"일단 재기동했더니 됐어요"가 세 번 반복되면 네 번째엔 재기동으로도 안 된다.

결함 관리 대장과 '결함 vs 요구사항' 싸움

안정화 기간의 가장 큰 갈등은 이것이다.

> 고객 — "이거 안 되잖아요, 결함이니 고쳐 주세요."
>
> 수행사 — "그건 요구사항에 없던 겁니다. 추가 개발입니다."

이 싸움에서 근거가 되는 것이 요구사항정의서와 RTM 이다.
그래서 1개월 차에 만든 문서가 8개월 차에 회사를 지킨다.

결함 관리 대장은 이렇게 관리한다.

결함 ID / 등록일 / 등록자 / 현상 / 재현 절차 / 심각도(치명·중·경) / 담당자 / 조치일 / 조치 내용 / 판정(결함/요청/문의)
판정 열이 핵심이다. 판정 없이 다 고쳐 주면 프로젝트가 끝나지 않는다.

심각도 기준도 미리 합의한다. 보통 '치명'은 업무 중단, '중'은 우회 가능,
'경'은 불편. 심각도에 따라 대응 시간(SLA)이 다르다.

SM(유지보수) 으로 넘어갈 때 넘겨야 할 것

인수인계 확인서에 목록이 들어간다. 실무적으로 이 정도는 있어야 한다.

시스템 구성도 (서버·포트·계정·경로 — 실물과 일치하는 것)
배포 절차서와 롤백 절차서 (실제로 한 번 따라 해 본 것)
배치 목록: 스케줄, 선후행 관계, 실패 시 조치
인터페이스 목록: 상대 시스템, 담당자 연락처, 장애 시 연락 순서
계정 목록: DB, WAS, OS, 외부 시스템 (그리고 비밀번호 관리 주체)
알려진 이슈와 임시 조치 목록 — 이걸 숨기면 안 된다. 어차피 3주 안에 드러난다
모니터링 항목과 임계값

유지보수 단계의 일은 무엇인가

SM 은 '고장 나면 고치는 일'이 아니다. 실제 업무 비중은 대략 이렇다.

40% 변경 요청 (법 개정, 업무 규칙 변경, 화면 추가)
25% 정기 작업 (배치 모니터링, 월/분기 마감 지원, 백업 확인)
20% 문의 응대
15% 장애 대응

그래서 SM 담당자에게 필요한 능력은 '빠른 개발'이 아니라
'영향 범위를 정확히 판단하는 능력' 이다. 컬럼 하나 늘리는 요청이
연동 시스템 세 곳에 영향을 준다는 걸 아는 사람이 좋은 SM 이다.
그 판단의 근거는 결국 인터페이스정의서와 테이블정의서다.
문서는 프로젝트가 끝나고 나서 진짜 값을 한다.

현장에서 만나는 모습

오픈 첫 주는 순서가 거의 정해져 있다.

당일 오전에는 로그인이 몰린다. 전 직원이 같은 시각에 접속하므로 커넥션 풀과 세션 설정이 첫 관문이고, 여기서 막히면 시스템이 아니라 오픈 자체가 실패한 것처럼 보인다. 1~2 일차에는 화면 오류 문의가 들어오는데, 상당수는 결함이 아니라 "예전 시스템과 다르다" 는 이야기다. 이걸 결함으로 받으면 결함 대장이 며칠 만에 수백 건이 되고, 진짜 결함이 그 안에 묻힌다.

그래서 이 시기에 가장 중요한 문서가 결함 대장의 분류 기준이다. 결함인지 신규 요구사항인지를 그때그때 정하면 매번 싸움이 되지만, 기준이 먼저 있으면 판정은 사무가 된다.

인수인계도 마찬가지다. 마지막 주에 몰아서 하는 교육은 남지 않는다. SM 담당자가 실제 장애를 함께 대응해 본 횟수가 인수인계의 진짜 지표다.