오래전에 만든 파일을 발견하면 먼저 열 수 있는 프로그램부터 찾게 된다. 익숙한 창이 다시 뜨면 자료도 되살아난 듯한 느낌이 들 것이다. 하지만 프로그램을 실행하는 일과 원래 자료를 보존하는 일은 다르다. 나는 복구를 시작하기 전에 어떤 파일을 그대로 남기고 무엇을 확인할지부터 적는 편이 낫다고 생각한다.
10월 29일 GeekNews에서 다시 소개된 winevdm은 64비트 Windows에서 오래된 16비트 Windows 프로그램을 실행하기 위한 프로젝트다. 새 버전이 오늘 발표됐다고 확인한 것은 아니다. 공식 README는 지원 대상과 함께 DOS 에뮬레이션이 불완전하다는 제한도 밝힌다. GitHub 본문 접근이 지연되어 공개된 공식 원문 README로 내용을 확인했다.
참고 원문: 관련 원문을 직접 읽기
창이 뜬다는 말의 범위
프로그램의 첫 화면이 보인다고 모든 자료를 정확히 읽었다고 말할 수는 없다. 저장 형식과 글꼴, 날짜 해석, 연결된 외부 파일이 따로 있을 수 있다. 그래서 실행 성공을 자료 복구 성공으로 바꾸기 전에 실제로 필요한 내용을 정해야 한다. 이 글은 특정 오래된 프로그램을 설치하거나 파일을 변환한 기록이 아니다.
가상의 주소록 파일을 예로 들어 보자. 스무 개의 연락처가 들어 있고 이름, 전화번호, 메모가 있다고 가정한다. 복구의 목표는 옛 프로그램의 모양을 그대로 보는 것이 아니라 이 세 필드를 빠짐없이 읽는 일일 수 있다. 실제 개인 연락처를 쓰지 않은 설명용 예시이며 개인정보를 공개 자료로 옮기라는 뜻이 아니다.
이 목표라면 원본 파일을 보존한 사본에서 작업하고, 확인한 결과를 별도 이름으로 남기는 절차를 제안할 수 있다. 원본의 크기와 해시, 복사 시각을 적어 두면 나중에 어떤 파일을 열었는지 구분하기 쉽다. 해시가 같다는 사실은 복사 내용의 일치를 알려 줄 뿐 파일이 정상이라는 보증은 아니라는 점도 함께 기억한다.
모양과 의미를 따로 대조하기
주소록을 화면에서 읽을 수 있다면 행의 개수와 각 필드의 의미를 비교한다. 스무 줄이 나온다는 것만으로 충분하지 않다. 이름과 메모가 서로 바뀌지 않았는지, 앞자리 0이 필요한 값이 숫자로 바뀌지 않았는지, 줄바꿈이 남았는지 확인해야 한다. 이는 가상 시험 설계이며 실제 변환기의 오류를 발견했다는 주장은 아니다.
내보내기 파일도 같은 기준으로 본다. 널리 읽을 수 있는 형식으로 저장했다고 해서 정보가 자동으로 보존되지는 않는다. 구분 문자와 문자 인코딩, 날짜 표현에 따라 읽는 도구의 해석이 달라질 수 있다. 따라서 내보낸 사본을 다시 읽어 본 결과와 원본을 읽은 결과를 대조하는 과정이 필요하다.
한 가지 형식만 남길 필요는 없을 수 있다. 눈으로 확인할 수 있는 기록과 기계가 읽을 수 있는 자료는 쓰임이 다르다. 다만 여러 사본을 만들수록 어느 것이 원본에서 왔는지 기록해야 한다. 파일 이름에 “최종”을 반복하기보다 원본, 작업 사본, 변환 결과를 구분하고 작업 일지를 짧게 남기는 편이 낫다.
실행 환경도 자료의 일부인가
옛 프로그램이 요구하는 환경은 그 자체로 중요한 맥락이 될 수 있다. 운영체제와 프로그램 버전, 필요한 주변 파일을 적어 두면 결과를 해석하기 쉽다. 하지만 호환 도구가 있다는 이유로 출처를 모르는 실행 파일을 바로 실행하거나 보안 기능을 끄는 식으로 넘어갈 수는 없다. 신뢰할 수 있는 출처와 권한, 분리된 시험 환경이 먼저다.
winevdm의 기능 목록은 가능한 접근 한 가지를 알려 준다. 내 자료에 맞는지와 실행 권한이 있는지는 별도로 확인해야 한다. 공식 설명의 안정판과 개발 중 버전도 구분할 필요가 있다. 최신이라는 이름만으로 더 안전한 복구 경로라고 고르지 않는다. 이 글에서는 설치나 레지스트리 변경 절차를 안내하지 않는다.
실행이 어려워도 할 수 있는 보존 작업은 남는다. 원본을 덮어쓰지 않고 파일 목록과 출처, 관련 문서를 정리하는 일이다. 무엇이 들어 있는지 확인하지 못한 상태라면 그 상태를 그대로 적는다. “복구 완료”라고 이름 붙이는 것보다 다음 사람이 이어서 살필 자료를 정확하게 남기는 것이 유용할 수 있다.
완료의 기준도 미리 정해 두면 좋겠다. 필요한 필드를 읽었는지, 사람이 확인할 수 있는 사본이 있는지, 작업 경로가 기록됐는지를 각각 묻는다. 실행 화면 캡처 하나는 그중 일부의 근거일 뿐이다. 복구 대상이 그림이나 음악이라면 소리와 색, 시간 길이처럼 확인해야 할 속성도 달라진다.
확인할 파일이 많다면 전체 개수만 세기보다 유형을 나누어 표본을 정할 수 있다. 짧은 문서와 긴 문서, 그림이 포함된 자료, 외부 참조가 있는 자료는 실패 방식이 다를 수 있다. 표본 검토를 전체 성공으로 보고하지 않고 확인한 유형과 수량을 남긴다. 일부를 열어 본 사실과 모든 자료가 보존됐다는 결론 사이에는 추가 검증이 필요하다.
사본의 위치만 적지 말고 확인한 날짜도 적는다. 마지막으로 열어 본 시점이 오래됐다면 현재도 읽을 수 있다고 단정하지 않는다. 보존은 한 번 붙이는 완료 표시보다 다시 확인할 수 있는 기록에 가깝다.
나는 오래된 도구를 다시 만나는 즐거움을 좋아하는 마음과 자료를 보존하는 책임을 함께 두고 싶다. 첫 창이 뜨는 순간이 목적의 끝은 아닐 수 있다. 다음에 오래된 파일을 발견한다면 실행 버튼을 찾기 전에, 무엇이 남아 있어야 복구라고 부를 수 있는지 한 문장부터 적어 보려고 한다.
함께 읽기: 자료 저장과 실패를 묻는 질문
