파일에서 DB로 옮기는 일은 내용을 복사하는 작업보다 “어느 저장소가 현재 쓰기의 권위인가”를 바꾸는 프로토콜에 가깝습니다. 먼저 한 시점의 기준 상태와 그 뒤 변경을 연결하고, 누가 옛 저장소에 계속 쓸 수 있는지 차단한 뒤, 실패 시 어느 방향으로 복구할지 정해야 합니다. 이 관점이 있으면 원자 파일 교체와 여러 저장소 사이의 transaction을 구별할 수 있습니다.
파일 잠금과 중단 쓰기 복구
두 프로세스가 주문 파일을 읽어 각각 수정하고 전체 파일을 덮으면 뒤 쓰기가 앞 변경을 잃을 수 있습니다. 잠금으로 모든 writer를 직렬화할 수 있어도 쓰기 도중 프로세스가 죽으면 부분 내용이 남을 수 있습니다. 잠금 소유자가 사라져 잠금이 풀린 것과 파일이 일관된 것은 다릅니다.
주문 파일을 바로 덮지 말고 임시 파일에 새 내용을 끝까지 쓴 뒤 파일 데이터를 내구적으로 flush하고 rename으로 교체한 다음, 디렉터리 이름 변경도 내구적으로 flush하면 한 파일의 교체가 한 번에 보이는 형태를 만들 수 있습니다. 다만 이 원자성·내구성은 파일시스템 조건에 달려 있으므로 사용 환경이 실제로 보장하는 범위를 확인해야 합니다.
주문 파일을 먼저 rename하고 결제 파일을 다음에 rename하면 첫 교체 뒤 프로세스가 죽을 때 한쪽만 새 버전이라서 두 작업 전체가 하나의 transaction으로 되지 않습니다.
DBMS 공통 책임과 업무 규칙 경계
| 책임 | 파일 기반에서 직접 필요한 것 | DBMS에서 활용할 것 |
|---|---|---|
| 동시 변경 | 모든 프로세스의 lock·순서 | transaction·잠금·MVCC |
| 무결성 | 중복·참조·상태 검사 | PK·UNIQUE·FK·CHECK·조건 갱신 |
| 중단 복구 | WAL·manifest·checksum·재생 | 엔진 로그·crash recovery |
| 질의 | 직접 탐색·색인 유지 | index·optimizer |
| 백업 | 일관 snapshot·증분 보관 | 제품별 backup·로그 복원 |
DBMS도 파일·OS·저장장치 위에서 동작하므로, 커밋한 데이터를 어디까지 보존할지는 내구성(durability) 설정과 저장장치 조건에 달려 있습니다. 계정명이 유일해야 하는지와 외부 결제를 어떤 업무 기록과 묶을지는 DBMS가 자동으로 알아내지 않으므로, 필요한 제약과 transaction 경계를 업무 규칙으로 설계해야 합니다. 반대로 파일 하나의 설정, 바뀌지 않는 대형 산출물, 순차 append 로그처럼 동시 질의와 관계 제약이 단순한 경우에는 파일이 더 적절할 수 있어 항상 DB가 더 빠른 선택은 아닙니다.
이전 기준 snapshot과 이후 변경 기록
상태 추적의 한 예로 snapshot 위치가 로그 500이고 복사가 진행되는 동안 update 501과 delete 502가 생겼다면, 초기 적재만 끝낸 DB에는 옛 레코드가 남습니다. 로그 501–502를 재생한 뒤 삭제 tombstone까지 대조해야 새 권위 후보가 됩니다. 예상 결과는 재시작해도 checkpoint 500에서 동일한 증분을 다시 적용해도 최종 상태가 변하지 않는 것입니다.
동시 쓰기가 있는 파일을 복사만 하면 스캔 앞부분은 옛값이고 뒷부분은 새값인 혼합본이 될 수 있습니다. 쓰기를 잠시 멈춰 기준 snapshot을 고정하거나, 버전 manifest와 로그 위치를 기준으로 일관된 snapshot을 정한 뒤 snapshot 시작·종료 사이의 변경을 증분으로 재생해야 이후 변경 경계를 잃지 않습니다. 어느 manifest와 로그 위치까지 복사·재생했는지를 저장하지 않으면 변경을 빠뜨리거나 두 번 적용할 수 있습니다.
초기 적재 때 파일 레코드의 안정 ID를 DB 키에 매핑한 뒤, 업데이트뿐 아니라 삭제·재생성·순서 변경도 같은 변경 기록으로 남겨야 합니다. 파일에 성공한 다음 DB 쓰기가 실패하거나 그 반대가 되면 두 저장소의 상태가 갈라지는 dual-write 틈이 생기므로, 파일과 DB에 차례로 직접 쓰는 방식만으로는 복구 경계를 만들 수 없습니다.
전환 전에는 파일을 권위로 두고 내구 로그를 DB에 재생하거나, 시스템이 지원하는 일관된 경계 또는 변경을 내구 저장해 전달하는 outbox를 사용한 뒤 어느 위치까지 반영됐는지 추적해야 합니다.
그림을 글로 읽기
- 일관 파일 snapshot·로그 위치
- DB 초기 적재·ID 매핑
- 증분 변경·삭제 재생·대조
- 최종 변경 장벽·writer 전환
- DB가 새 권위
- 일관 파일 snapshot·로그 위치 → DB 초기 적재·ID 매핑: 기준 데이터
- DB 초기 적재·ID 매핑 → 증분 변경·삭제 재생·대조: 동시 변경 연결
- 증분 변경·삭제 재생·대조 → 최종 변경 장벽·writer 전환: 누락·중복 검증
- 최종 변경 장벽·writer 전환 → DB가 새 권위: 옛 writer 차단
건수 일치와 데이터 내용 대조
파일을 계속 권위로 둘지 DB로 옮길지는 관계 제약·동시 질의·복구 요구가 실제로 커졌는지로 판단합니다. 장애를 진단할 때는 마지막 파일 manifest, DB 적재 checkpoint, 보류 행 집합, 각 writer의 권위 설정을 한 시간축에 놓고 “누락”과 “뒤늦은 옛 쓰기”를 구분합니다. 건수만 맞고 checkpoint가 없으면 전환 완료의 증거로 보지 않습니다.
값·삭제 표시·참조·고유키·합계·버전을 대조합니다. 100행 대 100행이어도 서로 다른 주문이 들어 있을 수 있습니다. 변환 규칙·인코딩·시간·숫자 정밀도·NULL 표현을 명시하고 오류 행은 보류 집합에 내구 기록합니다. checkpoint만 올려 건너뛰지 않습니다.
전환 장벽에서 옛 writer의 마지막 반영 위치를 확정하고 DB가 그 지점까지 따라왔는지 확인합니다. 웹 경로뿐 아니라 배치·관리 도구·오래된 worker도 옛 파일 쓰기를 멈춰야 합니다. 로컬 설정 하나만 바꾸고 다른 프로세스가 계속 쓰게 두면 두 권위가 생깁니다.
역전환과 새 변경의 역방향 전파
DB 전환 뒤 정상 쓰기가 발생했는데 옛 파일 snapshot으로 돌아가면 새 주문이 사라집니다. rollback 가능한 기간에는 역방향 반영·쓰기 중단 후 대사·독립 복구 계획이 필요합니다. 원본 파일을 보관한다는 사실만으로 무손실 rollback이 되는 것은 아닙니다.
옛 파일 정리에는 보관·개인정보·복구 기간·최종 참조를 확인합니다. DB 이전 성공은 데이터가 들어갔다는 사건이 아니라 동시성·복구·질의의 권위가 실제로 옮겨진 상태입니다.
중단 위치별 전환 검증
동시 갱신·파일 부분 쓰기·snapshot 중 삭제·DB 적재 실패·증분 재전달·최종 장벽·전환 후 rollback을 합성 데이터로 시험합니다. 효과 중복·누락·최종 권위와 재시작 결과를 대조합니다. 현재 작업에서는 실제 파일 저장 시스템을 DB로 이전하지 않았습니다. 본문은 이전 프로토콜의 학습 설명입니다.