영업시간이 바뀐 오락실을 이용자가 바로 고쳤더라도, 운영자의 승인을 기다리는 동안 다른 방문자는 예전 시간을 읽게 된다. 공개 전에 오류를 살피는 절차가 최신 정보의 반영도 늦추는 것이다. 12월에는 허용된 수정을 먼저 반영하고 이후 이력으로 확인하는 사후 검토를 선택했다. Delta에서는 영역별 저장과 변경 이력, 필요한 경우의 별도 공개 요청을 통해 이를 적용했다.

수정 요청과 승인 대기

기존에는 이용자의 요청을 운영자가 읽고 실제 데이터에 반영했다. 잘못된 요청을 먼저 걸러낼 수 있다는 장점이 있지만, 정상적인 수정도 같은 순서를 기다려야 한다. 장소와 참여자가 늘수록 정보를 아는 사람이 수정할 수 있는 시점보다 운영자가 메일과 요청을 읽을 시간이 반영 속도를 결정하게 된다.

모든 수정을 같은 방식으로 열기보다는, 문제가 생겼을 때 추적하고 되돌릴 수 있는 영역부터 바꾸기로 했다. 영업시간처럼 일상적으로 고치는 값은 이력과 함께 저장하고 사후에 확인한다. 공개 여부나 별도 판단이 필요한 기본 정보는 요청으로 받는다. 검토를 유지하면서 정상적인 수정의 대기 시간을 줄이려는 선택이었다.

전환은 한 번에 끝나지 않았다. 2025년 12월에는 영업시간을 즉시 반영했지만 공개된 기본 정보 변경은 요청으로 남겼다. 2026년 3월에는 공개 문서의 기본 정보도 직접 반영하도록 넓혔다. 따라서 12월의 정책 결정이 곧 모든 저장 경로의 동시 전환을 뜻하지는 않는다.

flowchart TD
    accTitle: 수정의 성격에 따라 반영 시점을 나누기
    accDescr: 허용된 일상 수정은 이력과 함께 반영하고 공개 판단이 필요한 요청은 운영자의 확인을 기다린다.
    U[로그인한 이용자의 수정] --> D{수정의 성격}
    D -->|즉시 수정 허용| A[저장과 이력 기록]
    D -->|공개 판단 필요| Q[별도 검토 요청]
    A --> R[사후 검토]
    Q --> O[운영자 판단 후 반영]

작성자 확인과 새 장소의 공개 요건

사후에 수정을 확인하려면 먼저 작성자를 알아야 한다. 서버는 로그인한 계정에서 작성자를 얻어 이력에 남긴다. 브라우저가 보낸 임의 이름을 그대로 쓰면 실제로 누가 고쳤는지 확인할 수 없기 때문이다. 다만 작성자를 식별할 수 있다고 모든 공개 판단을 그 계정에 맡기지는 않는다.

새 장소를 작성할 때는 검색에 나오지 않는 비공개 초안으로 시작한다. 초안 저장과 공개는 서로 다른 절차가 필요했다. 초기에는 작성자와 현재 공개 및 폐점 상태를 확인한 뒤, 공개 요청을 arcade_ticket_request에 남겨 검토하도록 했다.

3월 말에는 공개 전환도 서버가 요건을 검사해 직접 반영하도록 바꿨다. 요청자가 작성자인지, 이미 공개됐거나 폐점한 문서는 아닌지 확인한다. 게임과 연락처, 또는 영업시간과 사진 등 필요한 자료도 검사한다. 운영자의 개별 승인을 줄이더라도 새 장소에 필요한 정보를 갖췄는지 확인하는 과정은 유지한 것이다.

영역별 버전과 현재 참조의 갱신

수정 내용을 되돌릴 수 있으려면 이전 값을 남겨야 한다. 영업시간은 기존 값을 덮어쓰지 않고 새 arcade_hour 레코드로 만들며, 문서의 hour가 현재 사용할 레코드를 가리킨다. 기본 정보와 소통 창구, 편의 정보, 게임도 영역별 기록과 현재 참조로 나눠 한 영역만 독립적으로 고칠 수 있다.

현재 참조를 바꾸는 공통 처리는 이전 값을 읽고 새 값을 적용하면서 arcade_changelog에 변경 영역인 changed, 전후 상태인 from과 to, 작성자인 by를 남긴다. 현재 참조 갱신과 이력 저장을 같은 DB 트랜잭션으로 묶으면, 새 내용은 공개됐는데 그 변경 이력은 없는 상태를 피할 수 있다.

다만 영업시간의 새 레코드는 이 공통 트랜잭션 전에 만든다. 현재 참조 갱신이 실패하면 새 레코드 삭제를 시도하는 방식이다. 버전 생성부터 전부 한 트랜잭션인 것은 아니며, 함께 확정되는 대상은 이용자가 읽는 현재 참조와 그 변경 이력이다.

sequenceDiagram
    accTitle: 현재 참조와 변경 이력을 함께 확정하기
    accDescr: 새 영역 기록을 만든 뒤 현재 참조와 작성자가 포함된 변경 이력을 같은 데이터베이스 트랜잭션으로 갱신한다.
    participant U as 편집자
    participant S as 서버
    participant D as 데이터베이스
    U->>S: 인증 정보와 영업시간 수정
    S->>D: 새 영업시간 기록 생성
    S->>D: 현재 참조 변경과 from·to·by 저장
    D-->>S: 함께 커밋하거나 취소
    S-->>U: 저장 결과

사후 검토의 대상과 비교 자료

사후 검토는 어느 오락실의 어떤 영역을 누가 고쳤는지 찾는 데서 시작한다. 이어 전후 상태인 from과 to를 비교한다. 예를 들어 가격 한 항목을 고친 경우와 영업시간을 모두 비운 경우는 다르게 살펴야 한다. 시각만 나열한 활동 목록보다 실제 값을 비교할 자료가 필요한 이유다.

변경 이력이 있다고 그 내용이 현장과 일치한다고 단정할 수는 없다. 이력은 이전 상태를 읽고 확인할 자료를 제공한다. 별도 검토 요청도 운영자에게 살펴볼 대상을 알리는 수단이므로, 접수만으로 문서 수정이나 계정 제재까지 완료된 것은 아니다. 실제 내용과 필요한 조치는 운영자가 확인해야 한다.

이전 상태의 복원과 계정 조치

잘못된 수정이 발견되면 해당 영역의 이전 상태를 골라 현재 참조를 되돌린다. 복원 대상이 같은 오락실의 같은 영역인지도 검사해야 한다. 다른 문서의 ID를 연결하면 과거로 돌아가는 대신 자료의 관계를 잘못 만드는 결과가 생기기 때문이다.

복원 후에도 원래 변경 이력은 남는다. 되돌린 작업 자체를 새 이력으로 저장해 검토자가 수정과 복원을 모두 볼 수 있게 한다. 문서 복원만으로 작성자의 권한을 자동 제한하지는 않는다. 잘못된 내용을 바로잡는 작업과 계정에 필요한 조치는 각각 확인할 필요가 있다.

flowchart TD
    accTitle: 복원과 운영 판단의 경계
    accDescr: 실제 변경을 비교하고 같은 오락실과 영역의 이전 상태를 선택해 복원한다. 복원은 새 이력으로 남고 계정 조치는 별도 판단이다.
    S[현재 상태와 변경 이력] --> A[전후 내용 비교]
    A -->|문제 확인| C[같은 문서와 영역의 이전 상태 선택]
    C --> R[현재 참조 복원과 새 이력]
    A -->|운영 판단 필요| O[별도 검토와 조치]

반영 속도와 검토 운영

허용된 수정은 이제 운영자가 요청을 열어 보는 시점까지 기다리지 않아도 된다. 그만큼 검토 전의 잘못된 정보가 노출될 가능성은 있다. 따라서 이력 보관과 검토 요청, 복원 기능을 갖추고 실제로 기록을 확인하는 운영이 필요하다. 반영 속도를 높이는 효과는 이런 후속 작업을 계속할 수 있을 때 유지된다.

관련 기록: 뮤즈캣 개발 과정

관련 업데이트

• 주차장 정보 추가 & 비공개 오락실 노출 범위 변경