실록 품질팀 · · 실무 미스 · 조회 2

변경관리 없이 SOP를 고치면 생기는 일 — 현장 실수 사례

"이거 한 줄만 고치는 건데 굳이 변경관리까지…" — 품질 현장에서 가장 위험한 문장 중 하나입니다. SOP 개정은 문서 통제(4.2.4)의 대상이고, 통제를 건너뛴 개정은 작은 편의가 큰 부적합으로 돌아오는 전형적 경로입니다.

실제로 자주 벌어지는 장면들을 따라가 봅니다.

장면 1 — "급해서 먼저 고치고 결재는 나중에"

생산에서 문제가 생겨 SOP의 검사 기준을 급히 바꿔야 했습니다. 담당자는 파일을 열어 수치를 수정하고, "결재는 이번 주 안에 올리자"며 넘어갑니다.

문제는 그 사이에 개정본이 이미 작업에 쓰였다는 것입니다. 승인 없이 효력이 발생한 절차서로 만든 제품은, 나중에 결재가 붙어도 "그 기간 동안 통제되지 않은 절차로 생산했다"는 사실을 지울 수 없습니다. 심사관은 승인일과 시행일, 생산 기록의 날짜를 나란히 놓고 봅니다.

장면 2 — 신구 대비 없이 "내용 보완"으로 끝난 개정

개정은 결재를 거쳤는데, 무엇이 바뀌었는지 아무도 정확히 모릅니다. 이력란에는 "내용 보완"만 있습니다. 반년 뒤 문제가 생겨 "언제부터 이 기준이었나"를 역추적하려는데, 어느 개정에서 그 문장이 들어왔는지 증명할 수 없습니다.

변경은 결과물(새 버전)만 남기는 게 아니라 차이(redline)를 남겨야 방어됩니다. "이 문장이, 이 사유로, 이 개정에서 바뀌었다"가 증명되지 않으면 변경 통제는 형식만 갖춘 셈입니다.

장면 3 — 연쇄 영향을 놓친 개정

SOP 하나를 고쳤는데, 그 절차가 참조하던 양식(Form)과 하위 작업지침(WI)은 그대로입니다. 개정된 SOP는 4단계를 요구하는데 양식에는 3단계 칸만 있습니다. 현장은 어느 쪽을 따라야 할지 모릅니다.

변경은 영향 범위를 함께 봐야 합니다. 설계·프로세스 변경에서 연쇄 영향 검토가 요구되는 것(7.3.9 설계변경의 사고방식)과 같은 이치로, 문서 변경도 "이걸 바꾸면 무엇이 함께 바뀌어야 하는가"를 묻지 않으면 반쪽짜리입니다.

장면 4 — 폐기했어야 할 구버전이 계속 쓰인다

개정본이 시행됐는데 구버전 SOP가 현장 바인더에 그대로 있습니다. 신입은 그 바인더를 보고 구버전대로 작업합니다. 개정의 목적이 통째로 무너지는 순간입니다.

시행과 동시에 이전 현행본은 폐기·회수되어야 합니다. 개정은 "새 걸 올리는 일"이 아니라 "헌 걸 확실히 내리는 일"까지 포함합니다.

왜 변경관리는 절차가 아니라 방어선인가

위 네 장면의 공통점은, 개정 자체는 옳았다는 것입니다. 틀린 건 개정을 통제 없이 했다는 사실 하나입니다. 변경관리는 관료적 절차가 아니라, 나중에 "우리는 이 변경을 이렇게 통제했다"고 증명하기 위한 증거 생성 장치입니다. 문제가 생겼을 때 시정조치(8.5.2)의 출발점도 결국 "언제, 무엇이, 왜 바뀌었나"라는 변경 이력입니다.

자주 묻는 질문

Q. 오타 수정도 변경관리를 거쳐야 하나요?
효력 있는 현행 문서의 내용을 바꾸는 것이라면 원칙적으로 통제 대상입니다. 다만 조직은 경미한 변경에 대한 간소화 경로를 절차로 미리 정의해 둘 수 있습니다. 핵심은 "즉흥적으로 건너뛰는 것"과 "정해진 경로로 간소화하는 것"의 차이입니다.

Q. 소급 시행일을 지정하면 안 되나요?
지정할 수 있지만, 결재일보다 이른 시행일은 "승인 전에 이미 쓰였다"는 의심을 부릅니다. 소급이 불가피하면 그 사유와 서면 합의 증빙을 함께 남겨야 방어됩니다.

Q. 변경 통제를 하면 개정이 너무 느려집니다.
느린 건 통제 자체가 아니라, 통제가 수작업일 때입니다. 신구 대비 첨부·결재선·시행/폐기 처리가 한 시스템에서 자동으로 이어지면, 통제를 지키면서도 개정 속도는 오히려 빨라집니다.


"한 줄만 고치는 건데"가 위험한 이유는, 그 한 줄이 통제 밖에서 효력을 갖는 순간 시스템 전체의 신뢰가 그 한 줄만큼 새기 때문입니다. 변경은 빠르게 해도 됩니다. 다만 통제 안에서 빠르게 해야 합니다.

문서관리 때문에 같은 고통을 겪고 계시다면, 실록이 어떻게 해결하는지 살펴보세요.

댓글 0

첫 댓글을 남겨보세요.