문제
내전 운영에는 참가자 확인과 팀 편성뿐 아니라 운영진 선발 시험, 모집과 대기열 관리, 규정 안내가 필요했습니다. 운영자가 여러 명이면 같은 명단을 동시에 고치거나, 시험과 모집 도중 상태가 달라지는 상황도 다뤄야 했습니다.
선택한 방법
Match: 두 운영자가 같은 명단을 바꿀 때
PR #10에서 공동 편집을 구현했습니다. 예를 들어 두 운영자가 같은 명단을 열고 한 명은 참가자를 추가하고 다른 한 명은 팀 위치를 바꾸면, 마지막 저장으로 전체 상태를 교체하는 방식은 먼저 저장한 변경을 잃게 할 수 있습니다. 화면에 다른 사람의 변경을 빨리 표시하는 일과 서버에서 덮어쓰기를 막는 일은 별도의 문제였습니다.
공유 명단에 revision을 두고 Redis의 비교와 갱신을 Lua로 한 번에 처리했습니다. 서버가 값을 읽은 뒤 별도 요청으로 저장하면 두 요청이 같은 revision 검사를 모두 통과할 수 있기 때문입니다. 기대 revision이 맞으면 다음 revision으로 저장하고, 맞지 않으면 최신 상태가 포함된 conflict를 반환합니다.
PR #10의 클라이언트는 충돌 시 서버의 최신 명단을 반영하고, 다른 운영자가 먼저 수정했으므로 필요한 변경을 다시 적용하라고 안내합니다. 명단과 팀 위치를 하나의 revision으로 검증해 참가자와 배치가 일관된 상태로 저장되도록 했습니다.
Match: 공유할 데이터와 갱신 방식을 제한
공유 세션에는 Discord ID, 참가 순서와 선택적인 팀 위치를 저장하고, 표시할 배틀태그와 역할별 티어는 유저 시트에서 읽어 복원합니다. 참가자의 상세 정보를 세션마다 복제하면 유저 시트 수정 후 서로 다른 티어를 보게 될 수 있어, 식별자와 배치를 중심으로 계약을 정리했습니다. Discord ID가 없거나 중복된 참가자, 불완전한 팀 위치는 검증에서 거부합니다.
이 공동 편집은 WebSocket이 아닌 polling으로 구현했습니다. PR #10에서는 짧은 주기의 조회와 로컬 변경 전송을 구분하고, 저장 중이거나 아직 보내지 않은 변경이 있으면 조회로 화면을 덮지 않도록 했습니다. 숨겨진 탭의 polling도 건너뜁니다. 이후 PR #17에서는 기존 응답에 접속자와 최근 변경 정보를 추가하고, 인증된 작업자 정보와 만료 시간을 사용했습니다.
기존 조회 경로 안에서 접속자와 최근 변경을 함께 전달하고, 최종 저장은 revision 검사로 검증합니다. 화면의 공동 작업 안내와 서버의 저장 규칙을 분리해 구성했습니다.
Match: 테스트와 협업 범위
공동 편집 API는 기존 스냅샷 공유와 같은 Vercel Function 안에서 mode로 구분했습니다. Hobby 플랜의 함수 수 제한을 맞추면서도 기존 공유 코드는 그대로 동작하도록 배포 단위를 정리했습니다.
PR #10의 저장소 테스트는 정상 갱신 뒤 revision 증가와 stale 저장의 conflict 응답을 확인합니다. 계약 테스트에는 참가·대기 순서와 팀 위치 보존, 중복 ID와 일부만 채워진 팀 위치 거절이 포함됩니다.
인증과 대진표 UI를 개선한 다른 기여자의 변경도 같은 저장소에 병합되어 있습니다. 제 개인 기여는 위 공동 편집의 저장 계약·API·훅·UI 연결과 접속자 표시를 중심으로 확인할 수 있습니다.
Exam: 시험 시간을 서버에서 관리하도록
관리자 시험 웹은 Discord 로그인, 응시 코드, 답안 저장과 제출, 문제은행과 채점을 다룹니다. 제가 작성한 PR #4에서는 시험 정지·재개와 시간 연장 기록을 서버에서 처리하고 응시 화면에 반영했습니다. 만료·제출된 시험의 변경 제한, 소유자와 관리자 권한, 반복 요청 시 상태 보존을 다루는 회귀 검사도 함께 추가했습니다. PR #5에서는 테스트 응시를 일반 관리 현황에서 분리했습니다.
Gather Bot: 모집 상태와 복구 경계를 설계
Python과 SQLite로 모집 반응, 확정 참가자와 대기열, 티어 수집을 다루는 Discord 봇을 개발했습니다. 내전별 Session Actor로 이벤트를 처리하고, 재시작 시 세션과 알림 상태를 복구하는 구조입니다. 담당 변경에는 대타 모집, 대기실 배정과 관련 마이그레이션 및 테스트가 포함됩니다. 현재는 Match 자동 연동 없이 독립적으로 개발·테스트하고 있습니다.
Docs: 규정과 참여 안내를 함께 유지
Astro 기반 문서 사이트에 규정, 참가 안내와 FAQ를 정리하고 관련 도구의 진입점을 연결했습니다. 참여 안내와 알림 규칙을 수정한 커밋이 남아 있습니다. 운영자가 도구 사용과 규정 확인을 함께 이어갈 수 있도록 구성했습니다.
확인한 결과
Match는 운영진의 팀 편성과 결과 공유에 사용되고 있으며, 공동 편집과 접속자 표시 변경이 포함된 코드의 운영 배포 기록을 확인할 수 있습니다. Exam도 시험 시간 제어와 테스트 응시 분리를 반영해 배포했고, 운영 가이드는 GitHub Pages로 제공합니다. Gather Bot은 모집 상태와 재시작 복구를 다루는 개발·테스트 단계입니다.
이 사례는 하나의 웹 화면을 만드는 작업을 넘어, 공동 편집의 충돌 처리, 시험 상태의 서버 관리, 봇의 이벤트 처리와 복구, 운영 문서까지 다룬 경험입니다. 각 도구의 담당 구현은 아래 PR과 저장소에서 확인할 수 있습니다.
근거
- Match
- 운영진 내부 사용팀 편성과 결과 공유
- Exam
- 관리자 시험 웹 구현·배포
- Gather Bot
- 개발·테스트 단계