두 보고가 서로 다르다면? 데이터 품질과 원출처를 확인하는 방법

화면에는 같은 차량의 위치가 두 곳에 표시되어 있다. 한 보고는 동쪽 출입구를, 다른 보고는 서쪽 주차장을 가리킨다. 둘 다 방금 수신했고 차량번호도 같다. 담당자는 더 늦게 들어온 보고를 선택하려다가 멈춘다. 두 위치 중 어느 쪽이 맞는지 판단할 근거가 화면에 없기 때문이다.

앞선 글에서는 늦게 도착한 보고와 반복 수신을 다루었다. 이번에는 순서를 정리한 뒤에도 남는 문제를 살펴본다. 서로 다른 출처가 같은 대상을 다르게 보고하면, 가장 최근의 값이라는 이유만으로 현재 상태를 확정하기 어렵다. 무엇을 관측했고 어떤 과정을 거쳐 전달했는지 확인해야 한다.

아래 차량과 위치 보고는 설명을 위해 만든 가상 사례다. 독자가 연동 자료나 상황 화면을 검토할 때 사용할 수 있도록, 충돌의 원인을 좁히는 순서와 확인 항목을 함께 구성했다.

한줄 요약
보고가 충돌하면 먼저 같은 대상·같은 시점·같은 기준을 비교하고 있는지 확인한다. 그다음 최초 관측과 전달·변환의 이력을 대조해야 한다. 서로 다른 화면에 같은 값이 뜬다는 사실만으로 독립된 확인이 늘어난 것은 아니다.

두 점을 비교하기 전에 같은 차량인지부터 확인한다

A 체계의 차량번호 72와 B 체계의 차량번호 72가 같은 차량을 뜻한다는 보장은 없다. 기관별로 번호를 부여했다면 우연히 번호가 겹칠 수 있다. 차종과 소속이 비슷하다는 이유로 두 기록을 연결해도 다른 차량의 위치를 한 차량의 이동으로 읽게 된다. 비교의 시작은 값의 우열보다 대상의 동일성이다.

이 사례에서는 두 체계가 공통 차량 식별자를 사용하고 실제로 같은 차량을 가리킨다고 가정한다. 그래도 시각을 맞춰야 한다. A는 10시 정각의 위치를, B는 10시 8분의 위치를 보고했을 수 있다. 차량이 그 사이 이동했다면 두 보고는 충돌하지 않는다. 화면에 함께 나타난 두 점을 같은 순간의 두 관측으로 오인한 것이다.

좌표 기준도 같은지 확인한다. 위도와 경도의 순서, 좌표계, 단위가 다르면 숫자를 그대로 옮겨 지도에 찍을 수 없다. 이 단계에서 생긴 차이를 센서 성능 문제로 넘기면 정상적인 관측값까지 의심하게 된다. 대상, 관측 시각, 표현 기준을 먼저 맞춘 뒤에야 서로 다른 관측 결과를 비교할 수 있다.

가상 위치 보고: 같은 시각으로 보이지만 생성 과정은 다르다

구분	A 체계의 보고	B 체계의 보고
관측 대상	공통 차량 식별자 V-72	공통 차량 식별자 V-72
관측 시각	10:00에 직접 측정	09:52에 직접 측정
화면의 표시 시각	관측 시각 10:00	예측값 생성 시각 10:00
위치의 성격	센서 관측값	이전 관측과 이동 가정으로 계산한 값
추가 확인	측정 환경과 오차 정보	마지막 직접 관측, 계산 방법과 가정

표에서 B의 10시 위치는 10시에 새로 관측한 값이 아니다. 9시 52분의 위치를 바탕으로 차량이 계속 이동한다고 계산한 결과다. A와 B를 모두 ‘10시 위치’로 표시하면 직접 관측과 예측의 차이가 사라진다. 화면에 표시한 시각이 무엇의 시각인지 확인해야 하는 이유다.

형식이 맞는 값과 현실을 맞힌 값은 다르다

위도 입력칸에 허용 범위를 벗어난 숫자가 들어오면 프로그램이 오류를 찾기 쉽다. 반대로 범위 안의 숫자가 들어왔다고 해서 실제 차량이 그곳에 있다는 사실까지 확인되는 것은 아니다. 다른 차량의 정상적인 좌표를 잘못 연결해도 형식 검사는 통과한다.

데이터 품질을 점검할 때는 검사에 통과했다는 사실과 현실을 얼마나 잘 나타내는지 나누어 보아야 한다. 영국 정부의 데이터 품질 프레임워크도 품질을 사용 목적에 맞게 평가하도록 설명한다. 그 관점을 이 사례에 적용하면, 허용 범위 안의 좌표인지와 실제 차량 위치를 반영하는지는 별도 질문이 된다.

입력칸이 모두 채워진 기록도 오류가 있을 수 있다. 위치와 시각, 식별자가 빠짐없이 들어 있어도 식별자를 잘못 붙였다면 목적에 맞는 정보가 아니다. 검토자는 ‘빈칸이 없다’는 검사 결과를 ‘맞는 보고’라는 판단으로 바꾸지 않아야 한다.

모든 항목을 한 개의 품질 점수로 압축하는 방식도 조심해서 사용해야 한다. 위치 확인이 필요한 업무에서 연락처의 빈칸과 좌표 오류에 같은 비중을 주면, 평균 점수는 높아도 실제 판단에 필요한 항목은 부실할 수 있다. 사용할 업무를 먼저 정하고 그 업무를 흔드는 오류를 따로 표시하는 편이 낫다.

세 화면이 동의해도 최초 관측은 한 번일 수 있다

중앙 상황 화면과 부서 화면, 모바일 화면이 모두 동쪽 출입구를 가리킨다. 세 곳에서 확인했으니 동쪽 위치가 더 믿을 만하다고 느끼기 쉽다. 그러나 세 화면이 같은 센서의 보고를 복사해서 보여주는 구조라면 새롭게 확인한 관측은 하나도 늘지 않았다.

같은 정보가 여러 통로로 들어오는 일과 서로 다른 근거가 같은 결론을 지지하는 일은 구분해야 한다. 기관이나 시스템의 이름만 보면 출처가 여럿으로 보이지만, 끝까지 따라가면 최초 관측 하나에서 갈라진 보고일 수 있다. 전달 경로가 늘어났다는 이유로 관측의 독립성까지 늘어난 것으로 계산하면 확신을 과도하게 높이게 된다.

이를 확인하려면 마지막으로 보낸 체계뿐 아니라 원자료를 만든 장비나 담당자, 원보고의 식별값과 이후 처리 이력을 남겨야 한다. 어느 단계에서 좌표를 변환했는지, 보정이나 예측을 거쳤는지 알아야 같은 원자료에서 나온 결과들을 연결할 수 있다.

W3C의 PROV 문서군은 자료와 그것을 만들어 낸 활동, 책임 주체의 관계를 표현하고 교환하는 방법을 다룬다. 여기서는 세부 표기법보다 ‘이 결과가 어떤 자료와 처리에서 나왔는가’를 추적한다는 관점이 유용하다. 이런 생성·변환의 계보가 있어야 복사된 보고와 별도의 관측을 구별할 실마리가 생긴다.

원출처를 기록했다고 그 보고가 참으로 인증되는 것은 아니다. 최초 센서의 측정이 잘못되었을 수도 있다. 계보는 정확성을 대신 보장하는 표지가 아니라, 무엇을 확인하고 어디를 고쳐야 할지 찾아가는 근거다.

두 위치의 가운데를 고르면 실제로 없던 위치가 생긴다

동쪽 출입구와 서쪽 주차장의 중간을 현재 위치로 정하면 양쪽 보고를 고르게 반영한 듯 보인다. 하지만 서로 다른 차량을 잘못 연결했거나 한쪽 좌표 변환이 틀렸다면, 중간점은 오류 두 개를 섞은 결과다. 실제 차량이 한 번도 지나지 않은 건물 안을 가리킬 수도 있다.

관측을 결합하는 계산은 비교 조건이 맞고 오차에 대한 가정이 성립할 때 의미가 있다. 같은 대상의 같은 시점 위치인지, 각각 어떤 오차를 갖는지, 두 관측이 같은 원자료에 의존하는지를 살펴야 한다. 이 글의 사례에서는 그 조건을 확인하지 않았으므로 단순 평균을 정답으로 제시할 수 없다.

출처마다 고정 순위를 매기는 것에도 한계가 있다. 평소 위치 측정이 좋았던 센서가 특정 환경에서 성능이 떨어질 수 있고, 담당자가 입력한 보고는 현장 확인을 거친 값일 수도, 다른 화면을 보고 옮긴 값일 수도 있다. 출처의 평판과 이번 보고의 관측 조건을 함께 보아야 한다.

가상 사례의 A와 B라면 우선 B를 예측 위치로 표시하고 마지막 직접 관측 시각을 함께 보여준다. A가 직접 관측했다는 이유만으로 즉시 확정하지는 않는다. 대상 연결과 측정 환경을 점검하고, B와 차이가 커진 원인이 이동 가정의 실패인지 확인한다. 필요하면 현장에 재확인을 요청한다. 이것은 사례를 위한 처리 제안이며 모든 체계에 적용되는 운용 규칙은 아니다.

충돌을 남기는 화면이 담당자에게 더 많은 일을 알려준다

현재 위치 한 칸만 허용하는 화면은 프로그램이 어느 값을 선택했는지 보여주지만, 왜 선택했는지는 가리기 쉽다. 담당자가 선택 결과를 검토하려면 사용한 관측과 보류한 보고를 함께 열어 볼 수 있어야 한다. 원본을 지우고 최종값만 남기면 판단을 되돌아볼 자료도 사라진다.

표시할 정보는 크게 세 가지로 나눌 수 있다. 먼저 각 출처가 무엇을 보고했는지 남긴다. 다음으로 비교 과정에서 어떤 차이를 발견했는지 기록한다. 마지막으로 누가 어떤 규칙에 따라 현재 화면에 반영하거나 보류했는지 남긴다. 관측 자료와 분석 결과, 사람이 확정한 상태가 구분되면 추정값이 원관측처럼 재전송되는 일도 줄일 수 있다.

‘확인 필요’라는 표시에는 후속 절차가 붙어야 한다. 누가 어느 근거를 재확인할지 정하지 않은 채 충돌 표시만 쌓아 두면 담당자의 부담만 커진다. 추가 관측이 들어왔을 때 기존 판단을 재검토하는 조건과 정정 권한도 함께 설계한다.

지휘통제 정보체계에서는 지도 위의 한 점이 여러 보고와 처리의 결과일 수 있다. 운용자가 매번 모든 자료를 열어 볼 수는 없더라도, 필요할 때 원출처와 관측·추정의 구분, 충돌 여부를 확인할 수 있어야 한다. 화면을 단순하게 만드는 일과 판단의 근거를 없애는 일은 따로 다루어야 한다.

짧은 생각
정보통신과 지휘통제의 관점에서는 보고 수보다 서로 다른 근거가 얼마나 있는지가 더 궁금하다. 같은 관측을 여러 화면에 복사하면 공유 범위는 넓어지지만 새로운 사실이 추가되지는 않는다. 하나의 깔끔한 결론을 보여주기 전에, 그 결론을 다시 확인할 길을 남겨 두는 설계가 필요하다고 생각한다.

보고가 다를 때 사용할 여섯 가지 확인 질문

아래 표는 앞의 사례를 바탕으로 구성한 검토 순서다. 앞 단계에서 다른 대상이나 다른 시각임을 확인했다면 센서 신뢰도를 비교하기 전에 그 차이를 먼저 해결한다. 정답을 자동으로 고르는 공식이 아니라, 담당자가 확인해야 할 자료를 빠뜨리지 않기 위한 점검표다.

충돌하는 보고의 원인을 좁히는 점검표

확인할 질문	찾아볼 자료	다음 조치
같은 대상을 가리키는가?	식별자 발급 범위와 체계 간 대응 관계	다른 대상이면 연결 오류 수정
같은 순간을 비교하는가?	관측 시각, 예측 시각, 시간대	이동이나 시간 차이부터 구분
같은 기준으로 표현했는가?	좌표계, 단위, 변환 이력	기준을 맞춘 뒤 다시 비교
별도로 관측한 근거인가?	최초 보고 식별값과 전달 계보	복사된 보고를 별도 확인으로 세지 않음
관측과 추정을 구분했는가?	측정 조건, 오차 정보, 계산 방법	불확실성을 표시하고 필요한 근거 추가
누가 확정하고 정정하는가?	처리 기준, 검토 책임자, 정정 이력	충돌 보류·재확인·재판단 절차 지정

시험할 때는 서로 다른 시스템 두 곳에 동일한 원보고를 보내 보아도 좋다. 화면에는 보고가 두 개로 나타나더라도 동일한 관측에서 나온 자료임을 추적할 수 있어야 한다. 이어서 직접 관측과 예측을 같은 표시 시각으로 입력해, 두 자료가 같은 종류의 확인으로 집계되는지 살핀다. 시험의 기대 결과는 업무 담당자와 미리 정한다.

다음 단계에서는 관측 조건을 정리한 여러 보고가 정말 같은 대상을 가리키는지 더 깊이 다룰 수 있다. 서로 다른 센서가 각각 번호를 붙인 이동체를 하나의 대상으로 연결하는 문제다. 데이터가 늘어날수록 필요한 것은 무조건 합치는 기능보다, 잘못 연결했을 때 다시 분리할 수 있는 근거가 된다.

함께 읽으면 좋은 글

보고의 순서와 재전송을 다루는 기준은 앞선 글에서 확인할 수 있다.

 

늦게 도착한 데이터가 최신 정보를 덮어쓰면? 순서와 중복을 다루는 방법

 

늦게 도착한 데이터가 최신 정보를 덮어쓰면? 순서와 중복을 다루는 방법

참고자료

품질의 사용 목적과 생성 이력의 개념은 아래 공식 문서를 참고했다. 차량 사례, 비교표와 검토 절차는 이 글에서 구성했으며, 특정 군 체계의 규격이나 실제 장애를 옮긴 자료가 아니다.

• 영국 정부 — The Government Data Quality Framework: 사용 목적에 맞춘 데이터 품질 평가와 유효성·정확성의 구분.
• W3C — PROV-Overview: 자료의 생성과 처리, 관련 주체를 표현하는 출처 정보의 개요.
• W3C — PROV Model Primer: 자료·활동·주체와 생성·파생 관계의 설명.