게임 목록의 가격이나 수량은 시간이 지나면서 바뀐다. 그렇다고 값을 고칠 때마다 다른 설치로 취급하면, 그 기체에 달린 고장신고와 이전 수정 내용을 이어 보기 어려워진다. 8월에는 설치 항목의 고정 ID와 시점별 값을 나누고, 목록 전체를 교체하던 요청을 항목별 추가·수정·삭제로 바꿨다.

공동 편집과 전체 목록 저장

오락실 문서는 여러 사람이 함께 편집한다. 예를 들어 두 이용자가 같은 목록을 연 뒤 한 사람은 가격을, 다른 사람은 수량을 수정할 수 있다. 각자 읽어 온 목록 전체를 저장하면 먼저 반영한 값이 뒤의 저장으로 되돌아갈 수 있다. 화면이 무엇을 바꿨는지에 더해 어떤 상태를 보고 시작했는지도 서버에 전해야 한다.

개편 전 게임 입력 화면. 폼에서 바뀐 내용을 항목별로 식별하고 이전 값과 비교할 수 있어야 했다.

수정할 때마다 항목 ID를 다시 만드는 방식에도 문제가 있다. 수량이나 가격의 변경은 기존 설치의 수정인데 ID가 달라지면 관련 이력과 신고의 연결이 끊기기 때문이다. 구조화한 변경 이력을 제공하려면 저장 요청도 같은 항목과 편집 기준을 식별할 수 있어야 했다.

flowchart TD
    accTitle: 전체 목록 교체에서 잃기 쉬운 두 가지 정보
    accDescr: 읽었던 목록 전체를 다시 저장할 때는 같은 항목인지와 어느 상태를 기준으로 수정했는지가 필요하다. 두 정보가 빠지면 연결과 동시 편집을 검증하기 어렵다.
    A[목록을 읽고 편집] --> B[목록 전체 교체 요청]
    B --> C[같은 항목인지 식별 필요]
    B --> D[읽었던 기준 상태 확인 필요]

설치 ID와 시점별 수정본

arcade_game_id는 오락실에 등록된 설치 항목을 계속 가리키는 ID다. 버전·수량·가격 같은 시점별 값은 revision에 보관한다. 카탈로그 ID가 제품 종류와 호환성을 설명한다면 이 ID는 특정 오락실의 설치를 식별한다.

고장신고의 game_id도 설치 ID를 참조한다. 게임을 고칠 때마다 신고에 전체 게임 내용을 다시 복사할 필요 없이 같은 대상을 따라갈 수 있다. 과거의 값은 revision으로 확인하고, 신고는 지속되는 설치에 연결하는 구성이다.

flowchart LR
    accTitle: 게임 식별자와 시점별 정보의 분리
    accDescr: 현재 batch 안의 revision은 유지되는 게임 항목 ID를 참조한다. 과거 revision과 고장신고도 같은 항목 ID로 연결된다.
    A[arcade.game_v2] --> B[현재 batch]
    B --> R[현재 revision]
    R --> I[arcade_game_id]
    O[과거 revision] --> I
    F[고장신고] --> I

게임 목록 전체의 한 시점 구성은 batch로 보관한다. arcade.game_v2가 현재 batch를 가리키고 과거 batch와 revision도 남는다. 요청에는 add·modify·remove를 담아 어떤 항목이 생기고 바뀌고 빠졌는지 알 수 있게 했다.

변경분 저장과 충돌 처리

편집을 시작한 batch ID를 base_state_id로 보낸다. 서버는 트랜잭션 안에서 권한과 현재 batch를 확인하고 기준이 일치할 때 변경분을 적용한다. 새 batch와 revision, 현재 참조와 변경 이력을 함께 저장하므로 관련 자료 중 일부만 바뀌는 상태를 막는다.

sequenceDiagram
    accTitle: 같은 A에서 시작한 두 게임 편집
    accDescr: 두 편집자가 A를 읽고 첫 편집자가 B와 포인터 및 이력을 함께 저장하면, A를 기준으로 제출한 두 번째 편집에는 서버가 409를 반환한다.
    participant E1 as 편집자 1
    participant S as 서버
    participant E2 as 편집자 2
    S-->>E1: 현재 batch A
    S-->>E2: 현재 batch A
    E1->>S: 기준 A와 변경분
    Note over S: B·포인터·이력 함께 저장
    S-->>E1: 저장된 B
    E2->>S: 기준 A와 변경분
    S-->>E2: 409 Conflict

예를 들어 두 사람이 A에서 시작한 뒤 첫 저장으로 B가 생겼다면, 여전히 A를 기준으로 한 두 번째 요청에는 409 Conflict를 반환한다. 화면은 입력 내용을 보존한다. 기준 ID만 최신 것으로 바꾸거나 자동 합치기를 하는 대신, 이용자가 최신 구성과 자신의 변경을 다시 살피도록 했다.

과거 구성의 복원과 저장 비용

수량이 2대에서 3대로 바뀌어도 설치 ID는 같으므로 수정 이력과 신고를 이어서 확인할 수 있다. 복원할 때는 편집 권한과 대상 기록의 오락실 소속을 확인한 뒤 현재 참조를 과거 batch로 옮긴다. 값을 하나씩 다시 조립하지 않고 보존한 전체 구성을 선택하는 방식이다.

flowchart LR
    accTitle: 과거 상태를 보존하는 복원
    accDescr: 현재 포인터를 과거 batch로 옮기고 새 복원 이력에 이동 전후를 기록한다. 기존 batch와 이력은 남는다.
    P[현재 포인터] -->|복원 후| A[과거 batch A]
    P -.->|복원 전| B[최근 batch B]
    L[새 복원 이력] -->|이전| B
    L -->|다음| A

B에서 A로 돌아가더라도 최근 B와 기존 A→B 이력은 삭제하지 않는다. B→A라는 새 복원 이력을 추가해 현재 값에 이른 과정을 볼 수 있게 한다. 대신 작은 변경에도 구성 전체의 revision을 저장하는 비용이 들고, 서로 다른 항목을 수정했어도 batch가 달라지면 충돌한다. 자동 병합보다 오래된 구성의 무심한 덮어쓰기를 막는 쪽을 우선한 선택이다.

관련 글과 자료: 구조화한 수정 이력 · 고장신고 · 뮤즈캣 개발 과정