오락실을 처음 찾는 사람에게는 영업시간과 가격만으로 충분하지 않을 때가 있다. 건물 안에서 입구를 찾는 방법이나 이용 전에 알아둘 안내처럼 정해진 입력란에 담기 어려운 내용도 필요하다. 메모는 이런 설명을 맡는 문서이며, 8월에는 내용을 읽고 고치는 과정까지 생각해 저장 방식을 바꿨다.

방문 안내와 문서 편집

예를 들어 입구 안내와 이용 시 주의사항을 한 메모에 적는다면, 문단과 목록으로 구분했을 때 필요한 내용을 찾기 쉽다. 문자열 하나로만 저장하면 이런 구분을 편집기와 읽기 화면이 각자 해석해야 한다. 수정할 때 모양이 달라지거나 설명이 한 덩어리로 붙을 여지가 생긴다.

공동으로 편집하는 안내에는 이전 내용과 작성자를 확인할 방법도 필요하다. 새 값을 덮어쓰기만 하면 무엇을 고쳤는지 돌아보기 어렵다. 다만 같은 상세 화면에 있는 메모, 공식 공지와 사진은 작성 주체와 보관할 자료가 다르므로 각각의 저장·권한 정책을 유지했다.

문서 구조와 수정본

메모는 Tiptap의 JSON 문서로 전달한다. JSON 문서는 문단, 목록, 강조를 각각의 구성 요소로 표현하므로 편집기와 읽기 화면이 같은 내용을 같은 구조로 이해할 수 있다. 화면에 보이는 서식을 문자열로 되돌렸다가 다시 추측하는 과정을 줄이는 선택이다.

flowchart TD
    accTitle: 메모 문서와 현재 선택의 분리
    accDescr: 오락실은 현재 메모 revision을 가리키고, 각 revision은 문서와 작성자를 보관한다. 이전 문서도 변경 이력으로 연결된다.
    A[오락실의 현재 메모 ID] --> N[새 문서 revision]
    N --> D[문서와 작성자]
    P[이전 문서 revision] --> L[변경 전후 이력]
    N --> L

저장한 한 시점의 문서를 revision, 즉 수정본으로 보관하고 오락실에는 현재 사용할 메모 ID를 둔다. 새 수정본을 만들어도 이전 것은 남아 있어 변경 전후를 비교할 수 있다. 위키 메모와 운영자가 발행하는 공지가 편집기를 함께 쓰더라도 작성 정책은 각 문서에 맞게 적용한다.

문서 검증과 저장 과정

문서 형식에 자유가 생기면 잘못된 구조가 들어올 가능성도 고려해야 한다. 편집기는 오락실 ID와 문서를 메모 API로 보내고, 서버는 쓰기 권한에 더해 루트, 자식 요소, 텍스트와 속성을 검증한다. 문서 크기와 재귀 탐색에도 제한을 두어 읽기 화면이 처리할 수 있는 자료를 받도록 한다.

정보 종류별 편집 메뉴. 메모도 오락실 문서의 한 영역으로 편집한다.

내용이 현재 문서와 같으면 기존 revision을 반환한다. 달라졌을 때는 작성자와 새 문서를 저장하고 현재 메모의 참조와 변경 이력을 함께 갱신한다. 이 처리를 한 트랜잭션에 넣으면 새 문서는 생겼는데 상세 화면이 옛것을 가리키는 부분 저장을 막을 수 있다. 화면은 응답으로 받은 문서를 반영한 뒤 상세 정보를 갱신한다.

sequenceDiagram
    accTitle: 같은 문서와 달라진 문서의 저장
    accDescr: 서버가 문서 구조와 쓰기 권한을 확인한 뒤 같은 내용에는 기존 기록을 반환하고 다른 내용에는 새 revision과 포인터 및 이력을 함께 저장한다.
    participant E as 메모 편집기
    participant S as 메모 API
    participant D as 저장소
    E->>S: 오락실 ID와 문서
    S->>S: 구조와 권한 검사
    S->>D: 현재 문서 비교
    alt 같은 내용
        S-->>E: 기존 revision
    else 다른 내용
        S->>D: 새 문서·포인터·이력 함께 저장
        S-->>E: 저장한 문서
    end

수정 이력의 활용과 유지 관리

이용자는 문단과 목록으로 정리된 안내를 읽고, 수정자는 같은 구조를 편집할 수 있게 됐다. 설명이 달라진 경우에는 이전 문서와 작성자를 확인하며, 변경 없는 저장에는 기존 수정본을 재사용해 불필요한 중복을 줄인다.

flowchart LR
    accTitle: 같은 문서를 편집하고 읽기
    accDescr: 저장된 문서 구조를 편집기와 읽기 화면이 공유하고 변경 이력에서는 이전 revision을 확인한다. 서식이 바뀌면 두 화면의 해석도 함께 맞춰야 한다.
    D[저장된 문서 구조] --> E[메모 편집]
    D --> R[메모 읽기]
    H[변경 이력] --> P[이전 revision 확인]

구조화한 문서는 유지 관리도 요구한다. 서식을 추가하려면 편집기뿐 아니라 검증과 표시 방법을 함께 맞춰야 하고, 과거 수정본을 보관할 공간도 필요하다. 별도 파일 게시와 메모 서식의 확장은 각각 관리하면서, 메모 이력이 다른 콘텐츠의 작성 권한까지 바꾸지 않도록 운영한다.

관련 글과 자료: 뮤즈캣 개발 과정