STILL CODING / NOTES
Architecture 개발 노트
Architecture
여러 앱에서 Architecture을(를) 다루며 남긴 노트 5편입니다.
-
게임을 아홉 개로 늘려도 로비가 가벼운 이유 — Direct Play의 게임 모듈 구조
Direct Play가 게임 10개를 하나의 로비에서 다루기 위해 만든 카탈로그와 지연 로딩 레지스트리, 게임 모듈 계약, 순수 로직 분리를 설명합니다. 독립 앱 두 개를 같은 계약에 맞춰 옮긴 코드도 다룹니다.
-
사진은 서버를 거치지 않는다 — Direct Play가 게임 자원을 P2P로 나눠 주는 법
사진퍼즐처럼 방장이 올린 사진이 게임의 재료인 앱에서, 서버에 사진을 저장하지 않고 참가자에게 전달하기 위해 Direct Play가 만든 자원 요청 라우팅, 16,000자 청크 전송, 해시 검증, 실패 처리를 정리합니다.
-
방에도 수명이 있다 — 알람으로 청소하고 하루 500방으로 지키는 Direct Play의 서버 비용 설계
Direct Play는 설정 중 1시간 뒤 삭제, 활동 없이 3일 뒤 보관, 보관 후 7일 뒤 삭제를 예약합니다. Durable Object 알람으로 방을 정리하는 방법, 쓰기를 줄이는 장치, 하루 500방 한도를 전역 객체 하나로 세는 방법을 코드로 정리합니다.
-
스파이 게임의 진행 규칙 — 역할 확인, 투표, 마지막 추리
4~12명이 함께하는 Direct Play 스파이 게임의 투표와 결선, 마지막 추리 규칙을 설명합니다. 로컬 코드로 확인한 제한 시간 처리와 진행 상태 복원의 한계도 기록합니다.
-
서버는 방만 만든다 — CollaBoard의 WebRTC P2P 협업 구조
팀 자료를 서버에 저장하지 않는 협업 도구를 만들기 위해 CollaBoard가 선택한 시그널링, 메시와 스타 토폴로지, 16KB 청크 전송, 입장 보안 설계를 정리합니다.