대표와 직원이 안심하고 쓰려면 저장 버튼을 누른 뒤 다시 열었을 때 같은 자료가 있어야 한다. 화면이 성공을 보여 줬는데 서버가 다시 시작된 뒤 문서가 사라진다면 입력 편의는 의미를 잃는다. 이 작업의 클라우드 운영 기록은 회사 PC가 꺼져도 사용하는 요구와, 데이터를 언제 영구 저장으로 인정할지를 함께 다뤘다. 나는 서버에 올렸다는 말보다 저장 성공이 어떤 확인 뒤에 나오는지 설명하는 것이 더 중요하다고 본다.
실행할 공간과 보관할 공간을 나눴다
보관된 설계에서 실행 환경의 디스크는 작업을 위한 공간이고, 복구할 데이터의 확정본은 별도 저장소에 둔다. 시작할 때 마지막 확정 자료를 가져오고 변경이 끝나면 새 보관본을 만든 뒤 현재 버전의 기준을 갱신하는 방식이다. 어느 저장소를 정본으로 삼는지 먼저 정해야 한다. 지금 실행 중인 파일이 보인다는 사실만으로 나중에도 복구된다고 말할 수는 없다.
문서와 첨부가 서로 다른 곳에 있다면 어느 범위가 같은 확정 상태인지도 정해야 한다. 데이터베이스만 돌아왔는데 명세서 원본은 없는 상태를 전체 복구라고 부를 수 없다. 이 프로젝트의 운영 설명은 받은 원본과 관련 기록이 어떻게 보관본에 포함되는지 다룬다. 실제 자료를 공유한 것은 아니지만, 글에서는 문서 값과 그 근거 파일이 함께 찾아져야 한다는 설계 원리를 남길 수 있다.
저장 성공은 확정된 보관 뒤에 응답한다
당시 운영 설명은 변경 데이터의 불변 보관본과 현재 버전 포인터가 확정된 뒤 성공을 응답하는 흐름을 적었다. 보관 실패가 나면 마지막 확정 상태를 기준으로 복원한다. 작업 디스크에 쓰기만 했는데 성공을 먼저 알리는 방식과 다른 약속이다. 사용자에게는 저장이 조금 느리게 느껴질 수 있으므로 처리 중 상태와 실패 안내도 그 계약을 설명해야 한다.
응답을 받지 못했다고 실제 저장도 실패했다고 단정할 수는 없다. 보관은 끝났는데 네트워크가 끊겼을 수 있다. 같은 요청을 다시 확인할 식별자가 있으면 이미 처리한 결과를 조회하고 중복 생성을 피할 수 있다. 반대로 매번 새 요청으로 보내면 같은 전표가 두 개 생길 수 있다. 저장의 신뢰성은 서버 안의 쓰기뿐 아니라 응답이 사라진 경계에서도 정의돼야 한다.
백업 파일과 복구 검사는 다른 산출물이다
백업 생성 메시지는 파일을 만들었다는 근거다. 실제로 읽어서 같은 자료를 되살릴 수 있는지는 별도의 검사다. 보관된 전체 점검 기록은 운영 자료의 백업을 별도 경로에 복원해 구조와 행 내용을 비교한 범위를 설명하며, 실제 업무 데이터베이스를 교체하지 않았다는 점도 남겼다. 운영 복구와 격리된 복구 연습을 구별한 것이다. 성공한 연습이 곧 현재 운영 장애를 해결했다는 뜻은 아니다.
검토할 때는 전표 목록만 돌아오는지 보는 것으로 끝내지 않는다. 첨부 원본과 설정, 관련 이력과 버전이 함께 보존되는지 확인한다. 복구 전후를 같은 위치에 덮어쓰면 비교할 원본을 잃을 수 있으므로 별도 대상에서 검사하는 편이 좋다. 실제 운영 교체는 현재 상태와 작업 범위를 다시 확인한 뒤 다룰 일이다. 이 글을 쓰기 위한 자료 분석이 운영 자료를 복구할 권한을 뜻하지는 않는다.
대표가 믿을 수 있는 저장 문구
저장 중, 보관 완료, 결과 확인 필요 같은 상태는 직원이 다음에 무엇을 해야 하는지 알려 준다. 무조건 실패라고만 표시하면 이미 저장된 전표를 새로 만들 수 있고, 무조건 완료라고 표시하면 보관하지 못한 내용을 닫아 버릴 수 있다. 프로그램이 확실히 아는 상태와 확인이 필요한 상태를 나누면 대표에게 보여 주는 현황도 과장되지 않는다. 저장 문구와 재시도 동작은 함께 설계해야 한다.
이번 글은 제공된 운영 설명과 선택한 저장·복구 코드에서 당시 구조를 확인했다. 현재 ERP를 배포하거나 운영 서버를 재시작하고 복구한 결과는 아니다. 독자가 적용한다면 저장 실패, 보관 후 응답 유실, 실행 환경 재생성과 첨부가 있는 자료의 복구를 합성 환경에서 확인해야 한다. 회사에 맞춘 기능이 아무리 직관적이어도 그 입력을 다시 찾을 수 있어야 실제 업무 도구가 된다. 저장의 완성도는 성공 표시와 복구 가능한 근거가 같은 뜻일 때 판단할 수 있다.