여러 프로세스가 같은 파일에 주문을 저장할 때 생기는 문제를 DBMS는 어떤 책임으로 해결하나요?

DBMS는 단순히 파일보다 빠른 저장 형식이 아니라, 여러 요청이 같은 사실을 읽고 변경할 때 필요한 동시성·무결성·복구·질의 처리 책임을 한 계층에 모읍니다. 여러 프로세스가 주문 파일을 읽고 수정한 뒤 전체 파일을 덮어쓰면 마지막 쓰기가 앞선 주문을 잃는 lost update가 생길 수 있습니다. 한 프로세스가 쓰는 중 다른 프로세스가 읽으면 부분 형식을 볼 수 있고, 주문 파일과 결제 파일을 차례로 바꾸다 죽으면 한쪽만 반영됩니다.

파일 잠금은 책임을 없애지 않고 옮깁니다

임시 파일에 완성한 뒤 rename하는 방식은 하나의 파일 교체를 원자적으로 보이는 상태로 만들 수 있지만, 여러 파일·여러 레코드의 일관된 커밋과 복구를 자동으로 제공하지는 않습니다. 파일 잠금을 사용해도 모든 프로세스가 같은 잠금 순서·범위·해제·장애 복구 규칙을 지켜야 합니다. 잠금 보유자가 죽었을 때 복구할 로그, 부분 쓰기를 식별할 버전·체크섬, 재시작 중 재적용할 규칙을 직접 구현해야 합니다.

DBMS도 결국 파일에 저장하지만 트랜잭션 경계, 잠금 또는 MVCC, WAL/redo 로그, crash recovery, 기본키·외래키·고유·CHECK 같은 제약, 인덱스와 질의 최적화기를 제공합니다. 재고가 0보다 클 때만 차감 같은 규칙은 조건부 UPDATE나 트랜잭션으로 저장 계층에서 집행할 수 있습니다. 관계형 DBMS의 격리 수준이 관찰 결과와 대기 비용을 바꾸고, PostgreSQL·SQL Server·MySQL/InnoDB는 버전·잠금·로그 구현이 다르므로 DBMS라는 이름만으로 동일한 보장을 말하지 않겠습니다.

선택은 동시성과 질의 요구로 결정합니다

단일 프로세스의 설정 파일, 한 번 생성해 배포하는 대용량 파일, 순차 append 후 별도 분석하는 로그처럼 동시 갱신과 복잡한 조건 질의가 없는 경우 파일이 더 단순하고 저렴할 수 있습니다. 반대로 여러 프로세스가 같은 주문을 수정하고, 특정 고객·기간 조건으로 읽고, 주문과 결제의 부분 실패를 복구하며, 유일성·참조 관계를 계속 검사해야 한다면 파일 잠금 코드를 확장하기보다 DBMS에 책임을 모으는 편이 안전합니다.

DBMS도 업무 규칙을 자동으로 알아내지는 않습니다. 어떤 범위에서 계정명이 유일한지, 주문과 결제를 하나의 원자 경계로 묶을지, 외부 결제를 트랜잭션에 포함하지 않을지는 스키마·애플리케이션 설계의 몫입니다. 비교 검증은 동일 데이터와 동시 작업에서 lost update, 부분 실패, 복구 시간, 질의 지연, 쓰기 처리량을 측정하는 방식으로 하겠습니다. ‘파일은 항상 느리고 DB는 항상 빠르다’가 아니라 애플리케이션이 직접 떠안는 책임의 크기가 선택의 핵심입니다.

DBMS를 선택해도 파일 시스템의 fsync·디스크 오류·백업 보관은 사라지지 않습니다. 다만 여러 프로세스가 각자 복구 규칙을 구현하는 대신 DBMS가 공통 로그와 트랜잭션 경계를 집행하게 됩니다. 파일에서 옮길 때는 원본 파일의 레코드 식별자와 DB 키를 매핑하고, 이중 기록 기간에 대조 결과를 저장해 누락·중복을 확인하겠습니다. 성공 기준은 DB에 데이터가 들어간 것이 아니라 동시 갱신과 장애 복구의 책임이 실제로 이전된 것입니다.