대량 검증 작업 흐름: 많은 번호를 한 번에

목록에 번호가 수천 건 쌓여 있으면 한 건씩 확인하는 방식은 곧 한계에 부딪힙니다. 대량 검증 작업 흐름은 계산 속도보다 앞뒤 단계에서 성패가 갈립니다. 이 글에서는 입력을 정리하는 순서, 결과를 나누는 기준, 그리고 나중에 같은 작업을 되풀이할 때 필요한 기록을 정리합니다.

대량 검증이 어려운 이유는 무엇인가요?

검증 계산 자체는 값싼 연산입니다. 문제는 그 앞뒤입니다. 입력이 여러 창구에서 모이면 형식이 제각각이고, 같은 값이 다른 표기로 두 번 들어오고, 빈 칸과 잘못된 구분 기호가 섞입니다. 계산을 아무리 빠르게 해도 이 잡음이 그대로 남으면 결과를 믿을 수 없습니다.

두 번째 어려움은 결과의 해석입니다. 한 건짜리 검사에서는 판정 하나를 보여주면 충분하지만, 대량에서는 왜 실패했는지가 사유별로 나뉘어야 담당자가 손을 댈 수 있습니다. 세 번째는 재현성입니다. 같은 목록을 다음 달에 다시 돌렸을 때 무엇이 달라졌는지 비교하려면 실행 단위의 기록이 필요합니다.

정리 단계를 왜 먼저 두어야 하나요?

정리를 계산과 섞으면 실패의 원인이 흐려집니다. 값이 어긋난 이유가 입력 형식 때문인지 산술 규칙 때문인지 구분되지 않기 때문입니다. 정리를 별도 단계로 빼 두면 계산 단계는 이미 다듬어진 값만 받고, 실패 사유도 한 층으로 좁혀집니다.

정리 단계에서 할 일은 정해져 있습니다. 앞뒤 공백을 제거하고, 사람이 읽기 위해 끼운 구분 기호를 걷어내고, 문자를 대문자로 통일하고, 빈 값을 걸러냅니다. 이 과정을 거친 값과 원본 값을 함께 보관해야 나중에 되짚을 수 있습니다. 정리 규칙을 세우는 관점은 번호 검증의 원리 편의 정규화 설명과 같습니다.

결과를 어떤 갈래로 나누나요?

한 덩어리 성공과 실패로 나누면 담당자가 할 수 있는 일이 없습니다. 사유별로 나눠야 다음 행동이 정해집니다.

이 다섯 갈래를 파일 단위로 집계해 두면 작업의 성격이 보입니다. 형식 불일치가 많으면 수집 경로를 손봐야 하고, 산술 불일치가 많으면 옮겨 적는 단계를 봐야 합니다. 제도 미상이 많으면 규칙 목록을 보강할 차례입니다.

어느 값을 기준으로 보고해야 하나요?

원본 값과 정리된 값을 함께 보고해야 합니다. 정리된 값만 남기면 담당자가 원본 파일에서 그 줄을 찾을 수 없습니다. 보통 행 번호를 기준으로 삼고, 원본 문자열과 판정, 적용한 규칙 이름을 한 줄에 담습니다.

적용한 규칙 이름도 반드시 남깁니다. 같은 값이 어느 규칙으로 검사되었느냐에 따라 판정이 달라질 수 있기 때문입니다. 특히 후보가 여러 개인 제도에서는 어떤 후보를 적용했는지가 결과의 의미를 바꿉니다. 이 문제는 국가별 신분증 검증 편에서 다중 후보 처리로 설명했습니다.

나눠서 처리하는 기준은 무엇인가요?

한 번에 처리할 양을 정하는 기준은 메모리와 실패 복구입니다. 목록 전체를 메모리에 올리는 방식은 대개 처음에는 잘 돌지만, 목록이 커지면 어느 시점에 멈춥니다. 일정 단위로 잘라 처리하고 조각마다 결과를 남기면 중간에 멈춰도 이어서 다시 돌릴 수 있습니다.

조각의 크기를 정할 때는 한 건의 처리 비용보다 조각 하나를 마무리하는 데 드는 고정 비용을 봅니다. 조각이 너무 작으면 시작과 마무리 부담이 커지고, 너무 크면 실패 시 되돌아가는 범위가 넓어집니다. 어느 쪽이든 조각 번호를 결과에 남기면 나중에 부분 재실행이 가능합니다.

정리 단계에서 걸러낸 값도 그냥 버리지 않습니다. 빈 값이 몇 건이었는지, 같은 값이 몇 번 겹쳤는지를 집계에 남기면 입력 경로의 문제를 찾을 수 있습니다. 특정 창구에서 온 값만 비어 있다면 그 경로의 형식이 다른 것입니다. 중복이 많다면 수집 단계에서 같은 목록을 두 번 읽고 있을 가능성이 큽니다.

중복을 합칠 때는 어느 쪽을 남길지 기준을 정해야 합니다. 같은 값이라도 입력 시각이나 출처가 다르면 어느 것을 대표로 삼을지에 따라 결과가 달라집니다. 보통 가장 최근 값을 남기고 나머지는 참조로 보관하는 방식이 무난합니다. 합친 결과에는 몇 건이 합쳐졌는지 남겨 두면 나중에 목록이 줄어든 이유를 설명할 수 있습니다.

자동 판정이 끝난 뒤에도 사람이 봐야 하는 값이 남습니다. 산술이 어긋난 값, 여러 후보에 걸치는 값, 규칙이 없어 판정하지 못한 값이 그렇습니다. 이 세 갈래는 자동으로 결론을 낼 수 없으므로 담당자에게 넘기는 목록을 따로 만들어야 합니다.

넘길 때는 판정 결과만 주지 말고 원본 값과 그 값이 들어온 위치를 함께 줍니다. 담당자는 원본을 봐야 고칠 수 있고, 위치를 알아야 원천을 손볼 수 있습니다. 또 어느 규칙으로 검사했는지도 함께 적어야 담당자가 같은 판정을 재현할 수 있습니다. 이렇게 넘긴 목록은 다음 실행에서 개선 효과를 확인하는 자료로도 쓰입니다.

개발자를 위한 메모: 반복 실행을 견디는 구조

• 실행마다 실행 식별자를 만들고 결과 파일 이름에 넣습니다. 두 번 돌린 결과를 섞이지 않게 합니다.
• 입력의 지문을 남깁니다. 같은 목록인지 다른 목록인지 판단할 근거가 있어야 이전 결과와 비교할 수 있습니다.
• 판정 사유를 코드값으로 저장하고 문구는 화면에서 만듭니다. 문구가 바뀌어도 집계가 흔들리지 않습니다.
• 실패한 줄을 따로 모아 다시 입력할 수 있는 형태로 내보냅니다. 전체를 다시 돌리는 것보다 빠릅니다.
• 처리량과 소요 시간을 함께 기록합니다. 다음 실행의 조각 크기를 정하는 자료가 됩니다.

이 글의 결과 표와 예시 값은 작업 흐름을 설명하기 위해 구성한 것이며, 실제 사람이나 조직의 번호가 아닙니다. 실데이터를 다룰 때는 원본 값을 그대로 노출하지 말고 필요한 범위만 남기고, 보관 기간과 접근 권한을 먼저 정해야 합니다.

다음 단계

작은 목록으로 다섯 갈래 분류가 실제로 어떻게 나오는지 번호 검증 도구에서 확인해 보고, 이 흐름을 인터페이스 설계로 옮기는 방법은 API 경계에서의 검증 편에서 이어서 읽어 보세요.