‘백업 완료’ 뒤에 남은 파일까지: 전시 이미지 데이터 정합성 검증

백업에서는 무엇을 ‘같다’고 볼지 먼저 정해야 합니다

원본과 사본을 비교하려면 같다는 판단의 기준이 필요합니다. 파일 이름이 보인다는 이유만으로 내용이 보존됐다고 말할 수 없고 파일 개수가 맞더라도 개별 파일의 상태가 다를 수 있습니다.

이번 검증에서는 파일 수와 크기, 체크섬을 대조 기준으로 사용했습니다. 체크섬은 파일 내용으로부터 계산한 값을 비교하는 방법으로, 내용이 달라졌는지 확인하는 데 활용할 수 있습니다.

파일 수

비교 대상에 포함된 원본과 사본의 개수가 맞는가?

파일 크기

개별 파일의 저장 크기가 일치하는가?

체크섬

파일 내용에 대해 계산한 비교 값이 일치하는가?

각 기준은 서로 보완합니다. 하나의 값만 맞는다고 전체 백업의 모든 조건을 확인했다고 보지는 않습니다. 비교 대상과 대응 관계도 함께 정해져 있어야 합니다.

정상적으로 끝난 전송만으로는 충분하지 않았습니다

백업은 시작해서 끝나는 과정입니다. 그 사이에 연결이 끊기거나 같은 파일이 다시 전달되면 처음의 정상 경로와 다른 조건을 만나게 됩니다.

G사에서는 전송 중단과 같은 파일의 재업로드 조건을 재현했습니다. 그 결과로 저장된 데이터를 원본과 대조해 누락이나 중복이 생길 수 있는 지점을 확인했습니다.

사용자가 언제나 한 번의 시도로 작업을 마치지는 않습니다. 그래서 이런 조건을 살핍니다. 다시 실행할 수 있는 기능이라면 다시 실행한 뒤의 데이터도 설명할 수 있어야 합니다.

정상 동작을 확인하는 테스트와 중간에 어긋난 흐름을 확인하는 테스트는 다른 질문을 합니다. 백업에서는 최종적으로 남는 사본이 중요하므로 두 경로를 함께 볼 필요가 있습니다.

데이터의 차이를 개발이 재현할 수 있는 문제로 바꿨습니다

사본이 원본과 다르다는 결과만 전달하면 수정의 시작점이 부족할 수 있습니다. 어떤 조건에서 어떤 대상이 달라졌는지 알아야 개발팀이 같은 상황을 다시 확인할 수 있습니다.

검증에서 확인한 차이는 재현 조건과 함께 정리했습니다. 원본과 사본을 비교한 결과를 수정 순서를 정할 수 있는 결함 기록으로 바꾼 것입니다.

이미지가 보이는지 여부만으로는 부족합니다. 사용자가 열어볼 수 있는 사본이라도 누락된 파일이 남아 있을 수 있고 일부 파일의 상태가 다른 문제도 별도로 살펴야 합니다.

검증 결과가 실제 수정으로 이어지려면 데이터의 차이와 그 차이를 만든 조건이 연결돼 있어야 합니다.

테스트 결과와 함께 다시 확인할 기준을 남겼습니다

프로젝트를 통해 데이터가 어긋나는 조건과 대조 기준이 남았습니다. 파일 수·크기·체크섬이라는 비교 기준은 백업 결과를 다시 확인할 때 사용할 수 있는 출발점이 됐습니다.

결함 목록은 특정 시점의 문제를 설명합니다. 비교 기준은 이후의 결과를 같은 질문으로 살펴볼 수 있게 합니다. 두 가지를 함께 남기는 것이 이번 검증의 의미입니다.

다만 데이터 대조와 재해복구 체계 전체의 검증은 범위가 다릅니다. 이 사례는 이미지 백업의 정합성을 검증한 프로젝트이며 서비스 전체의 복구 시간이나 모든 장애에 대한 복구를 보장하는 사례는 아닙니다.

검증에서 확인한 것을 정확히 설명해야 그 결과를 사용하는 운영자도 무엇을 근거로 판단할 수 있는지 알 수 있습니다.

확인의 대상을 화면에서 자산으로 옮겼습니다

G사 사례는 기능 테스트의 대상을 어디에 두느냐에 따라 검증의 내용이 달라질 수 있음을 보여줍니다. 백업 버튼과 완료 안내를 중심으로 보면 화면의 흐름을 확인하게 됩니다. 보존해야 할 이미지를 중심에 두면 원본과 사본의 관계를 확인하게 됩니다.

이 프로젝트에서는 대량의 이미지 데이터를 대조하고 전송 과정의 예외를 재현했습니다. 그 결과를 수정 가능한 문제와 반복해서 사용할 비교 기준으로 남겼습니다.

백업 검증의 마지막 질문은 작업이 끝났는지가 아닙니다. 필요한 데이터가 의도한 상태로 남았는지입니다.