멀티플레이어 룸
라이브 노밍·캘리브레이션 세션을 Potato 안에서 진행합니다. 블라인드 투표, 호스트의 공개, 토론, 그리고 그 세션이 어떤 성과를 냈는지 보여주는 실시간 Krippendorff 알파 미터를 제공합니다.
v2.7.0의 새 기능
멀티플레이어 룸은 주석 작업을 혼자 하는 일에서 여럿이 함께하는 실시간 세션으로 바꿉니다. 여러 어노테이터가 같은 항목을 동시에 다루며, 그 과정에서 작동하는 사회적 역학은 단지 일어나는 데 그치지 않고 측정됩니다. LLM도, 외부 서비스도, 새 의존성도 필요 없습니다.

룸 종류는 세 가지입니다.
| 종류 | 무슨 일이 일어나는가 |
|---|---|
| Norming(기준 맞추기) | 전원이 블라인드로 투표하고, 호스트가 결과를 공개하고, 그룹이 토론하며, 누구든 투표를 바꿀 수 있습니다. 실시간 일치도 미터가 블라인드 α와 토론 후 α를 나란히 보여줍니다. |
| Huddle(판정) | 팀이 지금 의견이 갈리는 항목들을 차례로 훑으며, 각자의 원래 주석을 맥락으로 함께 보여줍니다. 실시간 판정 세션입니다. |
| Shadow(참관) | 교육 중인 사람이 참관자로 참여해, 호스트가 텍스트의 어느 부분을 강조하는지까지 포함해 실시간으로 주석하는 모습을 지켜봅니다. |
Norming 룸이 필요한 이유
주석 팀은 이미 화면 공유로 노밍 회의를 하고 있고, 그 결과는 누군가의 메모 속에만 남습니다. 룸은 그 세션을 도구의 일부로 만들고 계측합니다.
- 블라인드가 먼저. 공개 전에는 구성원이 누가 투표했는지는 보지만 무엇에 투표했는지는 보지 못합니다. 서버에서 강제하므로 첫인상이 실제로 독립적입니다.
- 공개는 곧 측정입니다. 블라인드 투표는 공개된 뒤에는 바뀌지 않습니다. 공개 이후의 모든 변경은 어떤 값에서 어떤 값으로 바꿨는지, 그 시점의 다수 의견은 무엇이었는지와 함께 기록되므로 구성원별 동조 기록이 남습니다.
- α 미터가 “이게 할 만한 일이었나?”에 답합니다. Krippendorff 알파는 공개된 항목에 대해 두 번 계산됩니다. 블라인드 투표 기준과 현재 투표 기준입니다. 그 차이가 세션의 노밍 효과이며, 진행되는 동안 화면에 표시됩니다.
구성
rooms:
enabled: true
who_can_create: any # "any" logged-in user, or "admin" only
persist_votes: true # final votes write into members' annotation state
poll_interval_ms: 1500 # client sync cadence (500–30000)
max_members: 12 # per room (2–100)
schema: sarcasm # optional; defaults to the first radio/likert scheme룸은 하나의 단일 선택 스킴(radio 또는 likert)에 투표합니다. schema를 설정하지 않으면 annotation_schemes에 있는 그런 스킴 중 첫 번째가 사용됩니다.
세션 진행하기
- 서버를 시작하고, 로그인한 뒤, **
/rooms**를 엽니다. - 룸을 만듭니다(종류와 항목 수 지정).
MKT4QP같은 여섯 글자 코드가 부여됩니다. 코드에는 헷갈리는 글자가 쓰이지 않으므로 소리 내어 읽어 줄 수 있습니다. - 다른 사람들은 로비 목록에서, 또는
/rooms/<CODE>를 열어 참여합니다. - 투표하고, 호스트가 공개하고, 사이드 채팅에서 토론하고, 설득되면 투표를 바꾸고, 호스트가 다음 항목으로 넘어갑니다. 마지막 항목이 끝나면 룸은 세션 요약과 함께 닫히며, 호스트는 전체 이벤트 로그를 내려받을 수 있습니다.
Huddle
생성할 때 Huddle을 고르면 룸의 스킴에서 어노테이터들의 의견이 현재 갈리는 항목이 최대 200개까지 룸에 채워집니다. 원래 주석은 투표 패널 위에 맥락으로 표시됩니다. 불일치는 주석 상태에서 실시간으로 계산되므로 판정 서브시스템을 활성화할 필요가 없습니다.
Shadow 세션
Shadow 룸에서는 호스트를 제외한 전원이 참관자로 참여합니다. 참관자는 투표할 수 없지만 호스트의 투표, 공개, 텍스트 선택을 약 1.5초의 지연을 두고 볼 수 있습니다. 호스트가 현재 선택한 부분은 참관자 화면에 황색으로 강조됩니다.
영속화와 장애 복구
모든 룸은 이벤트 소싱 방식입니다. 각 변경(참여, 투표, 공개, 변경, 메시지, 진행, 종료)은 다음 파일에 JSON 한 줄을 덧붙입니다.
<output_annotation_dir>/rooms/room-<CODE>.jsonl
룸 상태는 그 로그를 그대로 재생한 결과이므로, 진행 중인 룸은 서버를 재시작해도 살아남습니다. 이 로그는 세션의 감사 기록 역할도 합니다. 블라인드 투표, 타임스탬프, 토론, 그리고 공개 이후의 모든 변경과 그때의 다수 의견 맥락이 담깁니다. GET /rooms/api/<CODE>/export(호스트 또는 관리자)는 로그와 계산된 지표를 JSON으로 반환합니다.
persist_votes: true(기본값)이면 호스트가 다음으로 넘어갈 때 공개된 항목에 대한 각 구성원의 최종 투표가 평소의 주석 상태에 기록됩니다. 룸에서 한 작업은 실제 주석으로 집계되며 기존의 모든 내보내기 경로로 흘러갑니다.
클라이언트는 커서를 붙여 /events를 폴링하며 동기화합니다. WebSocket을 쓰지 않으므로 스레드 기반 개발 서버에서도, 어떤 WSGI 배포에서도 룸이 동작합니다.
API 요약
| 엔드포인트 | 메서드 | 대상 |
|---|---|---|
/rooms, /rooms/<code> | GET | 로그인 사용자(페이지) |
/rooms/api/list, /rooms/api/disagreements | GET | 로그인 사용자 |
/rooms/api/create | POST | who_can_create에 따름 |
/rooms/api/<code>/join, /leave, /vote, /message, /presence | POST | 구성원 |
/rooms/api/<code>/state, /events?since=N | GET | 구성원 |
/rooms/api/<code>/reveal, /advance, /close | POST | 호스트 |
/rooms/api/<code>/export | GET | 호스트 또는 관리자 |
추가 자료
- 심리측정 — 어노테이터별 능력과 항목 난이도. 거기서 드러난 코드북 문제를 바로잡는 자리가 룸입니다
- 판정과 불일치 해소 — Huddle에 대응하는 비동기 방식
- 주석 지침 작성하기
- 원본 문서