블로그
로그인

문서를 고친 뒤 새로 생긴 결함을 찾는 법 — 저희 개정 78건에서 5건이 나왔습니다

공정에는 불량률이 있고, 누구나 그 숫자를 관리합니다. 그런데 고치는 작업의 불량률은 잘 따지지 않습니다. 결함을 찾는 일에는 검사와 판정과 기록이 붙는데, 찾아낸 것을 반영하는 일은 "처리 완료" 한 줄로 넘어갑니다. 지적 78건을 반영했으면 78건이 없어진 것으로 칩니다.

(주)웨이스 대표이사

목차
  1. 확인하는 방법: 반영 건수가 아니라 다음 검증에서 새로 나온 건수
  2. 새 결함은 3가지 형태로 나왔습니다
  3. 가장 많이 빠지는 것은 인용처입니다
  4. 막는 규칙 3가지
  5. 정리

공정에는 불량률이 있고, 누구나 그 숫자를 관리합니다. 그런데 고치는 작업의 불량률은 잘 따지지 않습니다. 결함을 찾는 일에는 검사와 판정과 기록이 붙는데, 찾아낸 것을 반영하는 일은 "처리 완료" 한 줄로 넘어갑니다. 지적 78건을 반영했으면 78건이 없어진 것으로 칩니다.

제조 AI 운영체제 VEXPLOR를 만드는 웨이스가 문서 개정 한 판에서 이 비율을 확인해 봤습니다. 지적 78건을 반영한 뒤 다음 검증에서 그 개정이 새로 만든 결함이 5건 나왔습니다. 약 6%입니다. 이 글은 그 숫자를 어떻게 구하는지, 새 결함이 어떤 형태로 나오는지, 무엇으로 막는지를 정리합니다.

확인하는 방법: 반영 건수가 아니라 다음 검증에서 새로 나온 건수

  • 개정 전에 받은 지적 수를 적습니다. 이번 판은 78건이었습니다.

  • 반영이 끝나면 같은 기준으로 다시 검증합니다.

  • 다음 검증에서 나온 결함을 둘로 나눕니다. 원래 있던 것이 아직 남은 것, 그리고 직전 개정이 새로 만든 것입니다.

  • 뒤의 것을 반영 건수로 나누면 고치는 작업의 불량률이 나옵니다. 이번 판은 5 ÷ 78, 약 6%였습니다.

핵심은 「처리 완료 78건」을 결과로 보지 않는 것입니다. 그 숫자는 작업 도구가 보고한 것이고, 문서가 실제로 좋아졌는지는 다음 검증에서 새로 나온 결함까지 확인해야 드러납니다.

새 결함은 3가지 형태로 나왔습니다

하나, 중복을 없애다 중복이 생깁니다.

절 표제가 겹친다는 지적을 받고 이름을 바꿨더니, 바꾼 이름이 바로 아래 자식 표제와 같아졌습니다. 두 곳에서 났습니다. 지적받은 줄만 보고 그 아래 줄을 보지 않으면 이렇게 됩니다.

둘, 수치를 조정하다 단위가 틀립니다.

목차의 점선 폭을 줄이면서 공백을 한글 한 글자 폭으로 계산했는데, 실제 공백은 그보다 좁습니다. 한 줄만 과하게 줄었고, 19줄의 총폭을 재 보고서야 그 줄이 혼자 벗어난 것이 보였습니다.

셋, 명확하게 고치면 숨어 있던 어긋남이 드러납니다.

산식을 명시했더니 목표치가 계산으로 맞지 않았습니다. 재공재고를 36% 줄인다고 적혀 있었는데, 산식을 쓰고 보니 분모인 처리량이 함께 27% 늘어나는 구조라 계산값은 49.6%였습니다.

세 번째는 나쁜 일이 아닙니다. 가려져 있던 것이 드러났으니 고칠 수 있습니다. 다만 고친 즉시 검산하지 않으면 그 어긋남이 다음 검증까지 그대로 남습니다. 고친 사람은 잘 고쳤다고 느끼기 때문에 가장 놓치기 쉬운 형태이기도 합니다.

가장 많이 빠지는 것은 인용처입니다

지표 이름과 산식과 근거 표기를 고쳤는데, 그 표기를 인용하는 다른 9곳이 옛 값으로 남았습니다. 한 지표는 문서 안에서 5번 인용되고 있었습니다.

원본은 한 줄이 바뀌었고, 선 끝의 9곳은 그대로입니다
원본은 한 줄이 바뀌었고, 선 끝의 9곳은 그대로입니다

고친 곳은 새 값이고 인용한 곳은 옛 값이면 문서가 자기 자신과 어긋납니다. 이 상태는 고치기 전보다 나쁩니다. 고치기 전에는 전부 틀렸지만, 고친 뒤에는 어느 쪽이 맞는지 알 수 없기 때문입니다.

막는 규칙 3가지

  • 문구를 고치면 바로 위·아래 줄을 함께 읽습니다. 첫 번째 형태가 여기서 잡힙니다.

  • 그 문구를 인용하는 다른 곳을 전수로 찾습니다. 인용처 9곳이 여기서 잡힙니다.

  • 수치나 산식을 고쳤으면 고친 즉시 목표값으로 검산합니다. 세 번째 형태가 여기서 잡힙니다.

두 번째 규칙은 사람에게 맡기지 않는 편이 낫습니다. 웨이스는 문서를 만드는 빌드 스크립트 안에 "이번 개정이 없애려던 문구가 정말 0건인가"를 되묻는 검사를 넣었습니다. 다음 판에서 검증팀이 놓친 5번째 인용을 이 검사가 잡았습니다. 고친 사람은 자기가 고친 곳을 보고, 남은 곳을 찾는 일은 기계가 더 정확합니다.

이 글을 한 장으로 요약하면 이렇습니다 — 고치는 작업의 불량률은 반영 건수가 아니라 다음 검증에서 새로 나온 결함으로 확인합니다
이 글을 한 장으로 요약하면 이렇습니다 — 고치는 작업의 불량률은 반영 건수가 아니라 다음 검증에서 새로 나온 결함으로 확인합니다

정리

  • 고치는 작업에도 불량률이 있습니다. 반영 건수가 아니라 다음 검증에서 새로 나온 결함 수로 봅니다.

  • 새 결함은 대개 3가지 형태로 나옵니다. 고친 줄의 위·아래, 단위, 그리고 명확하게 고치자 드러난 어긋남입니다.

  • 가장 많이 빠지는 것은 인용처이고, 그것은 빌드 안의 검사로 잡습니다.

WACE(웨이스)는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만드는 회사다.

이 글이 도움이 되셨다면 공유해 주세요

PDF 저장

작성자

(주)웨이스 대표이사

제조 AI 운영체제 VEXPLOR를 만들고 있습니다. 스마트공장 구축 현장에서 데이터 표준화·온톨로지·디지털트윈·자율형공장을 다루며, 이 블로그에는 현장에서 실제로 부딪힌 문제와 그때 내린 판단을 씁니다.

contact@wace.me

새 글이 올라오면 메일로 알려드립니다

제조 현장에서 확인한 것들을 기록합니다. 새 글이 올라오면 보내 드리고, 언제든 해지할 수 있습니다.

우리 공장은 지금 어느 단계일까요?

제조 AI 성숙도 자가진단 — 회사 정보 없이 10문항이면 됩니다.

이 문제를 실제 현장에서 풀고 있습니다

표준 테이블과 온톨로지 관계 위에 시스템을 올리는 이유를 정리해 두었습니다.