개념
공장에는 배포 창이 없다
웹 서비스는 새벽에 배포하고, 문제가 생기면 되돌린다. 공장은 다르다. 24시간 3교대로 도는 라인에서 멈춤은 그 자체로 손실 이고, 멈춘 뒤 다시 정상 생산에 들어가기까지 준비 시간이 또 든다. 그래서 MES·게이트웨이·수집 서비스는 몇 주에서 몇 달을 재시작 없이 돈다.
이 조건이 QA 에게 뜻하는 것은 하나다. 하루짜리 시험으로는 보이지 않는 결함군이 따로 있다. 그리고 그 결함군은 발견 시점이 운영 2~3개월째이기 때문에, 발견되면 이미 수십만 대의 데이터가 영향을 받는다.
시간이 지나야 드러나는 결함의 형태
장기 가동에서 드러나는 결함은 대개 "서서히 나빠진다" 는 모양을 갖는다.
메모리 누수 — 실적 1건마다 몇 KB 가 회수되지 않는다. 하루 4,000대면 하루 수십 MB, 두 달이면 한계에 닿는다. 증상은 응답 지연 → 타임아웃 → 재전송 → 실적 중복 순으로 번진다. 모듈 62 레슨 4 의 중복 결함이 여기서 발생한다.
자원 핸들 누수 — 소켓·파일 핸들·DB 커넥션이 닫히지 않는다. 메모리보다 먼저 한계에 닿는 경우가 많고, 증상이 "갑자기 전부 안 된다" 로 나타나 원인 파악이 어렵다.
테이블·인덱스 증가로 인한 성능 저하 — 측정값을 전수 저장하는 라인에서는 테이블이 하루 수십만 행 늘어난다. 조회문이 처음에는 0.2초였는데 3개월 뒤 8초가 된다. 기능은 그대로인데 택트를 못 맞춘다.
로그·임시 파일로 디스크 고갈 — 가장 흔하고 가장 허무한 중단 원인이다. 회전(rotation) 설정이 없거나, 설정은 있는데 특정 로그만 빠져 있다.
누적 오차·카운터 포화 — 32비트 카운터가 한 바퀴 돌거나, 부동소수 누적 합계가 벌어진다. 시퀀스 번호가 최대치에 닿아 발급이 멈추는 경우도 있다.
시계·일정 경계 — 월말, 분기말, 연말, 서머타임(해외 공장), 윤년 2월 29일. "작년에는 됐는데" 로 보고되는 결함의 대부분이 여기다.
스케줄 작업의 겹침 — 야간 배치가 점점 길어져 다음 날 배치 시작 시각을 넘긴다. 두 배치가 같은 데이터를 동시에 건드려 정합성이 깨진다.
장기 가동 시험은 "오래 돌리기" 가 아니다
소크 테스트(soak test) 를 "72시간 돌려 보기" 로만 이해하면 72시간을 쓰고도 아무것도 못 얻는다. 얻으려면 세 가지가 설계돼 있어야 한다.
1) 부하가 운영과 닮아야 한다. 실적만 쏟아붓는 시험은 실제 혼합을 재현하지 못한다. 운영 부하의 구성은 보통 이렇다 — 실적 수신(지속), 측정값 저장(지속), 조회 화면(교대 시작·종료에 몰림), 작업 지시 다운로드(제품 교체 시), 배치(야간), 설비 알람(산발적). 각 요소의 비율과 시간대 분포 를 운영 로그에서 뽑아 시험 부하로 만든다. 모듈 16 레슨 2 의 부하 유형 구분이 그대로 쓰인다.
2) 관찰 지표가 정해져 있어야 한다. 시험 중 기록할 것을 미리 정한다.
| 분류 | 지표 | 판정 관점 |
|---|---|---|
| 자원 | 힙·RSS·핸들 수·커넥션 수·디스크 | 우상향 추세가 있는가 |
| 처리 | 초당 실적 처리량, 큐 길이 | 시간이 갈수록 떨어지는가 |
| 응답 | 조회·다운로드 응답 시간 분포 | 꼬리(p99) 가 길어지는가 |
| 정합성 | 레슨 4 의 정합성 규칙 결과 건수 | 0건이 유지되는가 |
| 로그 | 오류·경고 발생률 | 특정 시점부터 늘어나는가 |
판정은 절대값이 아니라 추세 로 한다. 힙 사용량 1.2GB 자체는 결함이 아니고, 24시간에 걸쳐 단조 증가하는 것이 결함이다.
3) 기준선이 있어야 한다. 첫 2시간의 값을 기준선으로 잡고, 12시간·24시간· 48시간·72시간 구간의 값을 같은 방식으로 비교한다. 기준선 없이 끝 값만 보면 "원래 그 정도인지" 를 판단할 수 없다.
시험 기간은 가장 긴 주기 사건을 최소 2번 포함 하도록 정한다. 야간 배치가 하루 한 번이면 최소 48시간, 월말 처리를 보려면 월말 경계를 통과시키거나 업무 시각을 조작한 전용 환경 을 쓴다.
비정상 종료와 복구 — 판정 기준은 정합성이다
연속 가동의 반대쪽 면이 복구다. 공장에서 비정상 상황은 예외가 아니라 연간 일정표에 있는 사건 이다. 정기 보수를 위한 계획 정전, 낙뢰로 인한 순단, 네트워크 장비 교체, 서버 패치 재시작.
여기서 QA 가 흔히 쓰는 판정 기준 "복구 후 정상 동작한다" 는 쓸 수 없다. 화면이 열리고 실적이 올라가면 정상처럼 보이지만, 끊긴 동안의 데이터가 어떻게 됐는지 는 별개 문제다. 복구 시험의 판정 기준은 셋이다.
- 손실 없음 — 끊긴 동안 설비가 만든 제품의 실적이 모두 올라왔는가
- 중복 없음 — 복구 과정에서 같은 건이 2번 올라가지 않았는가
- 순서·상태 일관 — 공정 순서와 재공 상태가 복구 후에도 성립하는가
세 기준 모두 레슨 4 의 정합성 조회문으로 판정 한다. 복구 시험은 결국 정합성 시험의 특수한 조건이다. 그래서 레슨 4 를 먼저 하고 이 레슨을 한다.
버퍼가 복구의 핵심이다
끊김을 견디는 방식은 어딘가에 쌓아 두는 것 뿐이다. 쌓이는 곳이 어디인지에 따라 견디는 시간과 잃는 양이 달라진다.
| 버퍼 위치 | 견디는 시간 | 한계에 닿으면 |
|---|---|---|
| 설비 내부 메모리 | 수십 분~수 시간(용량 고정) | 오래된 것부터 버림 또는 설비 정지 |
| 현장 게이트웨이 디스크 | 수 시간~며칠 | 디스크 고갈 |
| 메시지 큐 | 설정에 따름 | 적재 정책에 따라 거부 또는 폐기 |
| MES 수신 테이블 | 사실상 무제한 | 여기까지 왔으면 끊김이 아님 |
QA 가 확인할 질문은 네 개다.
- 용량은 얼마이고, 몇 분/몇 시간 분량인가? "1,000건" 이 아니라 "택트 22초 라인에서 6시간 분량" 으로 환산해 둔다. 환산해 두면 "정전 2시간은 견딘다" 를 바로 말할 수 있다
- 한계를 넘으면 무엇을 버리는가? 오래된 것을 버리는지, 새 것을 안 받는지, 설비를 멈추는지. 설비를 멈추는 선택 이 데이터 입장에서는 가장 안전하다
- 복구 시 몰려 올라오는 양을 받을 수 있는가? 6시간 분량이 한꺼번에 들어오면 평시의 수십 배 부하다. 이때 타임아웃이 나면 재전송이 돌고 중복이 생긴다
- 버퍼가 비었는지 아는 방법이 있는가? 복구 완료 판정의 근거가 필요하다. "큐 길이 0" 같은 관찰 가능한 지표가 없으면 언제 시험을 끝낼지 모른다
전원과 통신은 다른 사건이다
자주 뭉뚱그려지지만 성격이 다르다.
통신 두절 — 설비는 계속 생산한다. 제품은 계속 나오고 데이터만 쌓인다. 복구 후 밀린 데이터의 몰림 이 문제다. 두절 시간에 비례해 위험이 커진다.
정전 — 설비가 멈춘다. 멈추는 순간 설비 안에 제품이 남는다. 전원 복구 후 작업자는 그 제품을 꺼내거나, 남은 공정을 수동으로 처리하거나, 폐기한다. 시스템은 이 세 가지를 모두 표현할 수 있어야 한다. 그리고 쓰다 만 데이터 가 남는다 — 트랜잭션 중간, 파일 기록 중간, 캐시 미반영.
서버만 재시작 — 설비는 돌고 통신 상대만 사라진다. 통신 두절과 비슷하지만, 서버 쪽에 처리 중이던 건 이 남는다. 그 건을 다시 처리하는지, 버리는지, 중복이 되는지가 시험 대상이다.
순단(수 초 이내) — 가장 흔하고 가장 많이 놓친다. 재연결은 되는데 그 사이 보낸 1~2건이 사라지거나 2번 들어간다. 자동 재연결 로직이 멱등을 보장하지 않으면 여기서 중복이 쌓인다.
실설비·실전원을 건드리는 시험은 승인 사항이다
이 레슨의 시험은 성격상 설비를 멈추는 조작 과 가까워진다. 분명히 해 둔다.
- 전원 차단·브레이커 조작·통신선 분리를 QA 가 임의로 하지 않는다. 전기 작업 자격과 설비 담당 승인, 안전 조치(에너지 차단·잠금·표지) 가 전제다. 이 레슨의 실습 과제는 전부 설계·문서·시뮬레이터 과제 로 구성했다
- 실제 환경에서 할 수 있는 것은 소프트웨어 계층의 차단 이다 — 서비스 중지, 방화벽 규칙으로 포트 차단, 가상 네트워크 분리, 컨테이너 정지. 이것도 대상 환경 담당자의 승인을 받고, 시험 시간과 되돌리기 절차를 합의한 뒤 한다
- 운영 라인에서는 하지 않는다. 시험은 시뮬레이터·에뮬레이터 환경(레슨 3) 이나 전용 시험 라인에서 한다. 운영 라인에서의 복구 확인은 계획 정전 일정에 합승 해 관찰하는 형태가 현실적이다
- 장애 주입의 일반 기법과 안전 원칙은 모듈 46 레슨 6 에서 다룬다. 여기서는 그 기법을 공장 데이터 흐름에 적용하는 부분만 본다
실무에서 왜 필요한가
제조 프로젝트의 가동 초기 몇 달에 터지는 사고는 대부분 이 레슨의 범위에 있다. 기능 시험은 통과했고 사용자 교육도 끝났는데, 2개월째에 "오후만 되면 느려진다", 3개월째에 "월말에 배치가 안 끝났다", 그리고 어느 날 정전 복구 후 "어제 실적이 1,200대인데 창고에는 1,180대" 가 올라온다.
이 사고들의 공통점은 발견이 늦어서 보정이 비싸다 는 점이다. 그리고 가동 직후는 QA 조직의 신뢰가 결정되는 시기다. 가동 전에 소크 시험과 복구 시험을 해 두면 두 가지를 얻는다 — 결함을 미리 잡는 것과, 견디는 한계를 숫자로 말할 수 있게 되는 것 이다. "정전 2시간까지는 데이터 손실이 없고, 그 이상이면 설비 버퍼가 차서 오래된 것부터 버립니다" 라고 말할 수 있는 QA 는 운영 회의에서 위치가 다르다.
그리고 이 시험의 산출물은 운영 문서로 직접 넘어간다. 버퍼 용량 환산표는 정전 대응 절차서가 되고, 복구 후 정합성 조회문 묶음은 복구 점검표가 된다.