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

장비가 고장났다는 보고를 확인한 지 몇 분 뒤, 화면의 상태가 다시 ‘정상’으로 바뀌었다. 정비가 끝난 줄 알고 담당자에게 연락했는데 돌아온 답은 달랐다. 아직 수리 중이었다. 정상이라는 값은 고장 전에 보낸 보고였고, 통신이 지연되면서 뒤늦게 도착한 것이었다.

이런 상황에서는 보고서의 내용이 틀리지 않았을 수도 있다. 두 보고 모두 작성 당시에는 사실이었다. 잘못된 것은 나중에 도착한 보고를 현재의 상태로 받아들인 처리 방식이다. 데이터를 정확하게 표현하고 서로 같은 뜻으로 읽도록 약속해도, 도착 순서와 재전송을 다루는 규칙이 없으면 화면은 현실과 어긋난다.

이번 글은 여러 체계가 장비 상태를 주고받는 가상 사례를 따라간다. 늦게 온 정보를 어디에 남길지, 같은 보고가 두 번 도착하면 어떻게 처리할지, 갱신이 멈춘 화면은 무엇을 보여주어야 할지까지 살펴본다. 실제 군 체계의 운용 방식이나 특정 제품의 구현을 재현한 사례는 아니다.

한줄 요약
도착 시각은 사실이 발생한 시각과 다르다. 현재 상태를 바꾸는 순서 기준과 같은 사건을 다시 처리하지 않는 규칙을 함께 정해야, 늦거나 반복된 보고가 화면과 집계를 흔드는 일을 줄일 수 있다.

나중에 온 ‘정상’ 보고가 더 오래된 정보일 수 있다

같은 장비가 10시에는 정상이었고 10시 3분에 고장났다고 가정하자. 정상 보고가 전송 과정에서 잠시 머물렀다면 고장 보고가 먼저 도착할 수 있다. 여러 통신 경로를 거치거나, 처리 담당 프로그램이 여럿이거나, 실패한 전송을 재시도하는 환경에서는 사건 순서와 처리 순서가 달라질 여지가 있다.

가상 사례: 장비 한 대의 보고 순서가 뒤바뀐 경우

보고 내용	상태 확인 시각	수신 시각	현재 화면 처리
정상	10:00	10:05	과거 이력으로 보존
고장	10:03	10:04	더 최근에 확인한 상태로 유지

위 표는 같은 출처의 시계가 일관되고, 보고가 장비의 상태 전체를 나타낸다는 전제에서 작성했다. 수신 시각만 비교하면 10시 5분에 들어온 정상 보고가 이긴다. 상태 확인 시각을 비교하면 10시 3분의 고장 보고가 더 새롭다. 따라서 연동 명세에 ‘최신 보고를 표시한다’고만 적어서는 부족하다. 무엇을 기준으로 최신이라고 부르는지까지 써야 한다.

예를 들어 Amazon SQS의 표준 큐는 메시지가 중복되거나 순서가 달라질 수 있는 서비스를 명시한다. 모든 통신 방식이 같은 성질을 갖는다는 뜻은 아니다. 사용하는 전달 수단이 무엇을 보장하는지 확인한 뒤, 그 보장 밖의 상황을 받는 프로그램에서 처리해야 한다.

시각 하나를 저장하면 늦어진 지점을 찾기 어렵다

보고에는 서로 다른 시각이 붙는다. 센서가 값을 측정한 시각, 프로그램이 메시지를 만든 시각, 중앙 서버가 받은 시각, 화면에 반영한 시각이다. 이들을 모두 ‘등록일시’ 하나로 묶으면 지연이 어디에서 생겼는지 추적하기 어렵다. 현장의 측정이 늦었는지, 전송이 밀렸는지, 서버에서 기다렸는지가 구분되지 않는다.

처음에는 상태를 확인한 시각과 받은 시각을 나누는 것부터 시작할 수 있다. 화면 갱신 시각도 따로 기록하면 수신 이후의 처리 지연을 살필 수 있다. 각 시각은 어떤 사건을 뜻하는지 정의하고, 시간대도 함께 맞춘다. 한국 시각인지 UTC인지 모르는 값끼리 빼서 지연 시간을 계산하면 엉뚱한 결과가 나온다.

시간대를 통일해도 장비의 시계가 틀려 있으면 해결되지 않는다. 두 출처의 시계가 다를 때 시각만으로 선후를 확정하는 데에는 한계가 있다. 송신 체계가 같은 장비의 변경마다 증가하는 순번이나 버전을 부여하도록 설계하면 그 출처 안의 순서를 판단하는 데 도움이 된다. 다만 재부팅 뒤 순번이 초기화되는지, 여러 송신자가 같은 번호를 만드는지까지 정해야 한다.

서로 다른 출처가 각자 부여한 51번과 52번을 비교해 어느 쪽이 더 최신이라고 결정할 수는 없다. 순번은 비교할 수 있는 범위 안에서만 의미가 있다. 여러 기관의 보고가 충돌하는 경우에는 담당 출처, 정정 권한과 확인 절차를 별도로 정해야 한다. 숫자 하나가 책임 기준을 대신해 주지는 않는다.

늦게 온 기록을 버리면 과거의 원인도 사라진다

오래된 정상 보고가 현재 화면을 바꾸지 못하게 했다고 해서 그 기록까지 삭제할 필요는 없다. 고장 직전에 정상으로 확인됐다는 사실은 장애 분석에 유용할 수 있다. 현재 상태를 보여주는 자료와 당시의 사건을 보관하는 이력을 나누면, 지금의 화면을 지키면서 과거 경과도 복원할 수 있다.

이 구분은 보고 내용이 상태 전체를 담을 때 비교적 간단하다. 보고가 ‘현재 재고는 20개’라면 오래된 전체 상태가 최신 상태를 덮지 못하게 할 수 있다. 반면 ‘부품 두 개를 사용했다’는 보고는 수량 변화를 뜻한다. 늦게 도착했다는 이유로 사용 사건을 버리면 재고가 실제보다 많아진다. 이미 반영한 사건인지 확인하고, 필요한 경우 집계를 다시 계산해야 한다.

따라서 오래된 메시지의 처리 규칙은 데이터 종류에 따라 달라진다. 전체 상태, 수량 변화, 취소와 정정은 같은 덮어쓰기 규칙으로 다룰 수 없다. 특히 과거 기록의 오류를 바로잡는 정정 보고는 사건 시각이 오래됐더라도 새롭게 적용할 변경일 수 있다. 정정 대상과 정정 버전을 명확히 남기는 이유다.

같은 보고가 두 번 도착해도 작업은 한 번만 반영해야 한다

송신자는 보고를 보냈지만 성공 응답을 받지 못했다. 상대방이 처리하지 못했을 수도 있고, 처리한 뒤 응답만 유실됐을 수도 있다. 확인이 안 되니 다시 보내는 것은 합리적인 선택이다. 수신자가 재전송을 새 사건으로 받아들이면 정비 건수가 두 번 늘고, 부품 두 개를 사용한 기록이 네 개 사용으로 집계될 수 있다.

이때 필요한 것은 장비 식별번호와 별개로 보고 사건을 식별하는 값이다. 장비 한 대에서는 서로 다른 사건이 계속 발생하므로 장비번호만으로 중복을 걸러서는 안 된다. 같은 사건의 재전송에는 같은 사건 식별값을 유지하고, 새로운 사건에는 다른 값을 부여하는 약속이 필요하다.

받는 프로그램은 사건 식별값을 확인해 처음 들어온 사건만 반영하고, 이미 처리했다면 같은 작업을 반복하지 않도록 설계할 수 있다. 같은 요청을 여러 번 처리해도 의도한 결과가 한 번 처리한 경우와 같도록 만드는 성질을 멱등성이라고 부른다. 매번 ‘상태를 고장으로 설정’하는 일과 매번 ‘고장 건수를 하나 증가’시키는 일은 반복했을 때의 결과가 다르다.

중복 확인과 업무 반영 사이도 살펴야 한다. 두 프로그램이 동시에 같은 보고를 받아 둘 다 ‘처리한 적 없음’이라고 판단할 수 있기 때문이다. 사건 식별값의 유일성을 데이터베이스에서 보장하고, 처리 표시와 업무 변경을 함께 확정하는 방법 등이 필요하다. 외부 시스템 호출까지 포함된다면 실패 구간을 따로 분석해야 한다. 처리 여부를 메모하는 것만으로 전체 작업이 한 번만 실행된다고 보장할 수는 없다.

중복 확인 기록을 얼마나 오래 보관할지도 정해야 한다. 기록을 하루 뒤 지웠는데 이틀 뒤 재전송이 들어오면 같은 사건을 새 사건으로 받아들일 수 있다. 보관 기간은 재시도 가능 기간과 장애 복구 절차를 함께 보고 정하는 운영 규칙이다. 같은 식별값으로 내용이 달라져 들어오는 경우에는 무조건 무시하기보다 충돌로 남겨 확인하는 편이 낫다.

갱신이 멈춘 ‘정상’ 표시는 정상의 증거가 아니다

마지막 보고가 정상이었다는 사실과 지금도 정상이라는 판단은 다르다. 통신이 끊긴 뒤 화면이 그대로 남아 있으면 사용자는 오래된 상태를 현재의 상태로 읽을 수 있다. 값 옆에 마지막 확인 시각이나 경과 시간을 표시하고, 일정 시간 새 보고가 없으면 확인 필요 상태로 구분할 수 있다.

갱신 지연을 곧바로 고장으로 표시해서도 안 된다. 장비가 고장난 경우와 통신이 끊겨 상태를 모르는 경우는 후속 조치가 다르다. ‘마지막 확인 상태: 정상’과 ‘현재 정보의 신선도: 확인 필요’를 별도로 보여주면, 아는 것과 아직 모르는 것을 함께 전달할 수 있다.

허용하는 정보의 나이는 업무에 따라 정한다. 월별 자산 통계와 이동 중인 플랫폼의 위치에 같은 만료 시간을 적용하기는 어렵다. 이 글의 예시 시각도 설명을 위한 값이며 권장 운용 기준이 아니다. 갱신 주기, 통신 지연, 판단 목적을 함께 보고 화면이 언제 경고해야 하는지 합의해야 한다.

C4I처럼 여러 출처의 상황 정보를 함께 보는 환경에서는 보기 좋게 정돈된 화면만으로 신뢰도를 판단하기 어렵다. 보고의 출처와 확인 시각, 갱신 지연을 볼 수 있어야 운용자가 정보의 한계를 고려할 수 있다. 오래된 위치를 이력에 남기는 것과 현재 위치로 표시하는 것은 다른 결정이다.

짧은 생각
정보통신과 지휘통제의 관점에서 화면을 보면, 빈칸을 없애는 일보다 모르는 상태를 드러내는 일이 더 필요할 때가 있다. 마지막으로 확인한 정상값을 계속 보여주는 화면은 편안하지만, 판단에 필요한 불확실성까지 가려 버릴 수 있다. 보고가 도착했다는 사실과 그 보고를 지금 믿고 사용할 수 있다는 판단 사이에는 운영자가 확인할 근거가 있어야 한다.

연동 시험에서는 순서를 일부러 뒤집어 본다

정상 보고 한 건을 보내 화면에 뜨는지 확인하는 시험만으로는 위의 문제를 찾기 어렵다. 다음 표처럼 입력 순서를 바꾸고 재전송과 중단을 넣어 보면 처리 규칙이 실제로 작동하는지 확인할 수 있다. 기대 결과는 업무 담당자와 개발자가 시험 전에 합의한다.

데이터 최신성·중복 처리 시험표

시험 입력	확인할 결과
새 상태 뒤에 오래된 전체 상태 전송	현재 값은 유지하고 과거 보고의 처리 근거를 남기는가
같은 사건을 두 번 전송	건수·재고·알림 등 부수 작업이 중복 반영되지 않는가
같은 사건을 동시에 수신	동시 처리에서도 한 사건으로 확정되는가
같은 식별값으로 다른 내용 전송	충돌을 발견하고 확인할 수 있는가
보고 중단 뒤 허용 시간 경과	마지막 상태와 정보 확인 필요를 구분하는가
과거 사건의 정정 또는 늦은 수량 변화 전송	오래됐다는 이유만으로 버리지 않고 정해진 재계산·정정 절차를 따르는가

화면 값뿐 아니라 왜 적용하거나 보류했는지도 확인할 수 있어야 한다. 사건 식별값, 출처, 시각, 순번과 처리 결과를 추적할 수 있으면 ‘값이 이상하다’는 신고를 특정 보고와 처리 단계로 좁힐 수 있다. 불필요한 민감정보까지 로그에 복사할 필요는 없지만, 판단 근거가 남지 않으면 같은 장애를 다시 분석하게 된다.

여기까지의 규칙은 데이터를 언제 현재 상태로 받아들일지 정하는 기준이다. 다음에는 출처가 서로 다를 때 무엇을 믿을지라는 문제가 남는다. 두 센서가 같은 대상을 서로 다른 위치로 보고한다면, 최신 시각 하나만 골라도 되는지부터 따져야 한다. 데이터 품질과 출처의 신뢰도는 이런 비교를 위한 다음 단계가 된다. 특히 군 C4I라면 이 문제는 더 심각해진다. 데이터를 신뢰할지, 시간을 신뢰할지의 문제가 아니라 둘다 포기할 수 없는 부분이라 군 정보체계라면 이런 부분을 좀더 신경써야 한다.