QuickBooks를 여러 사용자가 함께 Google Drive에 저장할 수 없는 이유

구체적인 내용을 살펴보기 전에, 이것이 일반적인 개념임을 이해하는 것이 중요합니다. 실제로 이 문제는 “클라이언트/서버 또는 공유 데이터베이스 파일 애플리케이션을 단일 사용자만 접근할 수 있도록 제어되지 않는 동기화 스토리지(예: Google Drive, DropBox, NextCloud 등)에 저장할 수 없는 이유”로 요약할 수 있습니다. QuickBooks는 1980년대 스타일의 애플리케이션에서 흔히 볼 수 있는 공유 데이터베이스 파일 메커니즘을 사용합니다. 즉, 하나의 파일 또는 파일 세트를 파일 공유 메커니즘으로 공유하고, 각 애플리케이션 사본이 이 파일에 접근하여 수정하는 방식입니다. Google Drive는 동기화 스토리지 메커니즘으로, 한 위치의 데이터를 다른 위치로 복사합니다. 동일한 파일에서 동시에 작업하는 사람들은 서로의 변경 사항을 덮어쓸 수 있으며, 이러한 변경 사항은 나중에 수동으로 조정하거나, 무시하거나, 동시에 작업하지 않도록 사용자를 제어해야 한다는 가정 하에 운영됩니다.

일부 다중 사용자 애플리케이션의 경우, 스토리지 시스템이 다른 사용자가 없을 때만 변경을 허용하도록 잠글 수 있는 상황에서만 동기화 스토리지를 활용할 수 있습니다. 이는 범용 파일 동기화에서는 실용적이지 않은 수준의 통합이 필요합니다. 이 기능을 구현한 대부분의 시스템은 범용 동기화 메커니즘이 아닌 데이터베이스 또는 애플리케이션 계층에 내장된 동기화 메커니즘을 사용합니다. 동기화 스토리지에서 데이터 무결성을 유지하려면, 한 번에 한 사람만 파일을 편집하고, 모든 잠재적 사용자가 해당 파일의 “저장” 후 업데이트를 받을 때까지 기다린 후, 다른 사용자가 파일을 편집하는 과정을 반복해야 합니다. 그러나 한 번에 한 명의 사용자만 파일을 수정할 수 있으며, 파일을 열어 편집하기 전에 다른 사용자의 업데이트를 받아야 합니다. 그렇지 않으면 시스템이 매번 어떤 변경 사항을 유지하고 어떤 것을 버릴지 사용자에게 물어봐야 합니다.

이 무결성 프로세스는 현실적으로 데이터베이스 파일에 적용할 수 없습니다. 파일은 빠르게 열고 편집하고 저장하는 방식이 아니라, 항상 열려 있고 지속적으로 접근되도록 설계되어 있습니다. 저장도 수동으로 이루어지지 않으며 항상 예측 가능하지도 않습니다. 일반적으로 저장은 사용 중에 지속적으로 이루어진다고 가정하지만, 캐싱으로 인해 이러한 저장 작업도 수동으로 제어하기 불가능할 수 있습니다. 하지만 이는 성능상의 이유로 필요합니다.

혼란은 종종 단일 사용자의 경우에서 발생합니다. 다른 사용자가 동시에 시스템에 접근할 걱정 없이 단일 사용자는 Google Drive나 Apple iCloud 같은 동기화 스토리지를 백업 메커니즘(자동으로 원격 복사본을 만드는 방식)으로 사용하거나, 파일을 수동으로 옮기지 않고도 한 위치에서 먼저 사용한 후 다른 위치에서 사용하기 위한 수단으로 활용할 수 있습니다. 단일 사용자가 위치 간 이동 시 캐시가 플러시되고 동기화 및 잠금이 완료될 충분한 시간을 확보하거나, 첫 번째 애플리케이션 인스턴스를 열어 두지 않았다면 비교적 안전한 시스템이라고 가정할 수 있습니다(하지만 완전히 보장할 수는 없습니다. 이 메커니즘은 경쟁 조건의 미세한 위험을 내포하고 있습니다). 단일 사용자 모드에서 동기화 스토리지를 안전하게 사용하는 “방법”이 있기 때문에, 비기술적인 회계 또는 재무 담당자들은 완전히 다른 개념인 다중 사용자 동시 접근도 작동할 것이라고 잘못 가정하는 경우가 많습니다. 그러나 이는 불가능합니다.

발생하는 문제는 여러 사용자 간의 경쟁 조건이며, 이것이 발생하지 않았다고 완전히 확신할 수 없습니다. 때로는 데이터가 단순히 잘못되어 경쟁 조건이 발생했음을 알 수 있으며, 숫자가 완전히 부정확해질 것입니다. 하지만 더 자주, 일부 트랜잭션은 검토한 후에도 단순히 손실됩니다.

예를 들어 보겠습니다. 사용자 1은 집에서 QuickBooks에 새로운 영수증을 입력합니다. 이 변경 사항은 로컬 컴퓨터에 저장되기 시작하고, 그 후 클라우드(온라인)의 Google Drive로 새 파일을 전달하기 시작합니다. 사용자 2는 이 시간 동안 사무실에서 송장에 대한 고객 결제를 입력하기 시작합니다. 사용자 2의 QuickBooks 데이터 파일은 열려 있어 사용 중에는 덮어쓸 수 없으므로, Google Drive로 전송되는 파일은 사용자 2에게 도달할 수 없습니다. 사용자 2가 변경 사항을 저장하면, 그의 사본도 Google Drive로 보내려 합니다. 이제 Google Drive는 동일하게 시작했지만 서로 완전히 다른 변경 사항을 가지고 있는 두 문서를 처리해야 하며, 어느 사본도 두 변경 사항을 모두 가지고 있지 않습니다. 이를 병합할 방법이 없으므로, 사용자 1을 마스터로 수락하고 사용자 2의 변경 사항을 버리거나(예: 우선순위 기준), 사용자 2의 변경 사항을 수락하고 사용자 1의 변경 사항을 버리거나(예: 최신 우선 기준), 또는 모든 변경 사항을 버리고 아무것도 수락하지 않을 수 있습니다. 어떠한 경우에도 모든 사용자의 재무 트랜잭션이 로컬에 저장된 후에도 유지되지 않습니다. 사용자 1 또는 사용자 2(또는 둘 다) 중 적어도 한 명은 저장했다고 믿었던 데이터가 갑자기 사라지는 경험을 하게 됩니다. 사용자가 더 많아질수록 문제는 커집니다.

문제의 일부는 파일 접근 수준에서 작업하고 전체 파일 수준에서 데이터를 동기화하고 공유할 때, 하나의 레코드나 행만 잠그거나, 트랜잭션을 분리하거나, 변경 사항을 병합할 방법이 없다는 것입니다. 파일은 단일 엔티티이며 변경된 것입니다. 전부 아니면 아무것도 아닙니다. 개별 QuickBooks 애플리케이션은 서로 직접, 또는 데이터베이스 파일을 통해 통신하여 쓰기, 저장, 읽기 등을 조율하여 이 문제를 해결할 수 없습니다. 각각은 파일의 고유한 사본을 가지고 있기 때문에, 다른 애플리케이션이 동시에 파일을 사용하려 한다는 것을 알 수 없으며, 통신을 허용하는 “공유” 요소가 없습니다. 사본들은 서로 연결되어 있지 않으며, 여기에 양자 상태는 관련이 없습니다. 그리고 느리거나 불안정한 인터넷 연결이 있을 때, 혹은 더 나쁘게는 인스턴스가 오프라인 상태일 때 하나 이상의 애플리케이션 인스턴스가 사용되는 잠재적 문제를 추가할 수 있습니다. 동기화가 최종적으로 발생할 때 덮어써야 하거나 덮어씌워져야 하는 수 시간 또는 며칠간의 변경 사항이 있을 수 있습니다. 우리는 거의 밀리초 단위가 아닌, 종종 며칠치 데이터를 이야기하고 있습니다.

로컬 공유 파일에서 이 문제가 해결될 때 사용하는 방법은 다면적입니다. 첫째, 파일의 사본이 아닌 단 하나의 파일만 존재합니다. 따라서 모든 변경 사항은 모든 애플리케이션 사본에 동시에 즉각적으로 제공됩니다. 하나의 애플리케이션 인스턴스가 파일에 데이터를 쓰려 할 때, 클러스터 파일 시스템이 SAN 작동을 허용하는 방식과 유사한 잠금 및 알림 메커니즘을 사용합니다. 이를 통해 변경이 이루어지고 있으며 다른 인스턴스들이 완료될 때까지 기다려야 하고, 계속하기 전에 데이터의 사본을 갱신해야 한다는 신호를 보낼 수 있습니다. 오직 하나의 인스턴스만 쓸 수 있으며 다른 모든 것은 기다려야 합니다. 잠금이 시작 전에 획득되고 완료 시 해제되므로 경쟁 조건이 없습니다. 그리고 모든 인스턴스는 데이터에 현재 접근 가능한 경우에만 작동하며, 연결이 끊기면 진행할 수 없습니다. 이는 중요한 데이터 무결성 보호 메커니즘입니다. 일부 애플리케이션은 이 메커니즘을 더 높은 수준으로 끌어올려 더 빠른 성능을 위해 공유 파일을 통하지 않는 직접 통신 채널을 추가합니다. 하지만 이 수준까지 가는 경우는 드문데, 그 수준에 도달하면 수십 년 된 설계에 현대적인 다중 사용자 시스템을 억지로 끼워 맞추는 것보다 현대적인 애플리케이션으로 이동하는 것이 훨씬 더 쉽기 때문입니다.

이 글이 회계사들이 왜 동기화된 파일이 작동할 것이라고 흔히 생각하는지, 그리고 “저는 운이 좋았던 것”이나 “다중 사용자 환경에 적용되지 않는 완전히 다른 시나리오에서 사용했던 것”이라고 말해야 할 때 “저에게는 잘 됐어요”라고 주장하는 이유, 그리고 왜 Google Drive, NextCloud, iCloud, DropBox 등을 QuickBooks 및 기타 레거시 스타일 애플리케이션과 함께 백업 및 데이터 전송에 절대적으로 사용할 수 있지만, 다중 사용자 접근 방법으로 사용하려는 시도는 고려할 수 없는지를 명확히 해주었으면 합니다. 데이터 무결성을 유지할 수 없기 때문입니다.