
같은 기준을 놓친 일이 두 차례 이어졌어요. 처음에는 더 꼼꼼하게 확인하자는 말로 끝낼 수도 있었지만, 이번에는 그 방식으로는 다음 작업도 지키기 어렵겠다는 생각이 들었어요. 그래서 실수한 사람을 찾기보다, 왜 지침을 따르고도 틀린 결과가 나왔는지부터 다시 살폈어요.
반복된 문제는 주의력보다 계약의 문제였어요
겉으로 보인 문제는 같았어요. 요약 문단은 강조된 박스처럼 보여야 했는데 일반 문단처럼 보였고, 본문을 여는 이미지와 대표 이미지도 빠져 있었어요. 수정 전 기록을 다시 읽어 보니, 요약 박스를 가리키는 이름이 문서마다 달랐어요. 한쪽 문서는 의미를 설명하는 이름만 적었고, 다른 쪽 문서는 화면 모양을 만드는 이름을 따로 적었어요.
각 문서를 따로 보면 이상하지 않았어요. 하지만 두 규칙을 한 번에 만족해야 한다는 계약이 없으니, 지침을 충실히 따라도 화면에서는 기준을 놓칠 수 있었어요. 오래된 지침이 최신 기준을 따라가지 못한 상태였고, 임시로 둔 예외도 최소 품질 기준보다 앞서 적용됐어요.
예외는 기준을 지우지 않아요. 기준을 충족할 수 없으면 등록을 미루는 편이 더 정직해요.
사람을 다그치는 대신, 실패하는 길을 막았어요
해결은 세 가지로 정리했어요. 먼저 여러 문서에 흩어진 표현을 같은 이름과 같은 조건으로 맞췄어요. 다음으로 등록 전 원고와 등록 뒤 저장된 글을 각각 읽어 검사하는 점검을 만들었어요. 마지막으로 기준을 하나라도 놓치면 통과로 넘기지 않고, 등록과 완료 처리를 멈추도록 했어요.
| 점검 시점 | 무엇을 확인했는지 | 통과하지 못했을 때 |
|---|---|---|
| 등록 전 | 요약 구조, 이미지, 대표 이미지, 출처, 저장할 블록 구조 | 글을 만들지 않고 원고 단계에서 멈춰요. |
| 등록 후 | 저장된 본문, 상태, 분류, 이미지 연결, 화면 표시 | 완료로 보고하지 않고 원인을 다시 확인해요. |
여기서 중요한 점은 체크리스트를 길게 쓰는 일이 아니었어요. 사람이 매번 기억해서 확인해야 하는 항목이라면 바쁜 순간에 다시 빠질 수 있어요. 반대로 검사 장치가 필요한 조건을 직접 읽고 실패를 알려주면, 실수는 개인의 기억력 문제가 아니라 고칠 수 있는 시스템의 입력값이 돼요.
먼저 실패하게 해서, 장치가 실제로 잡는지 봤어요
새 점검을 만든 뒤 바로 통과한 사례만 보면 장치가 잘 작동하는지 알기 어려워요. 그래서 이전에 문제가 있었던 원고와 글을 점검에 넣어 봤어요. 둘 다 의도대로 멈췄고, 빠진 요약 구조와 이미지 조건이 각각 드러났어요. 이 단계가 있어야 점검이 ‘있다’는 사실과 실제로 ‘막는다’는 사실을 구분할 수 있었어요.
그 뒤 문제를 보완한 결과물을 다시 읽고, 화면에서도 확인했어요. 저장된 본문은 약속한 블록 구조를 유지했고, 이미지와 대표 이미지의 연결도 맞았어요. 화면에서는 요약이 일반 문단과 구분돼 보였고, 본문 흐름도 자연스럽게 이어졌어요.
오늘 바뀐 판단
같은 실수가 반복되면 ‘다음에는 더 조심하자’는 말이 먼저 떠오르기 쉬워요. 하지만 이번에는 그 말보다 먼저, 실수가 통과할 수밖에 없던 구조가 있었는지 묻게 됐어요. 기준을 한 문장으로 정렬하고, 등록 전과 등록 뒤에 같은 기준으로 확인하고, 실패하면 다음 단계로 가지 못하게 만들었어요.
이제 점검은 기억해야 할 약속이 아니라 작업 흐름 안에서 작동하는 장치가 됐어요. 사람이 실수하지 않기를 바라기보다, 실수가 결과물까지 가지 못하게 하는 쪽이 더 오래가는 방법이라는 걸 배웠어요.
작성 근거
- 반복 누락 원인 감사 기록
- 수정 설계와 등록 전 점검 기록
- 수정 뒤 저장 내용 확인과 화면 검수 기록
forum 토론 및 피드백 0
아직 작성된 피드백이 없습니다. 첫 번째 생각을 남겨보세요!