[PonsLink] 방을 만들기 전에 요청을 먼저 받는 이유

방을 만들기 전에 요청을 먼저 받는 이유.

DM이나 문의가 흩어져 들어오고, 정작 회의 전에 맥락이 사라지던 일방을 먼저 만들면 그 맥락을 제품 안에 담을 곳이 없다.

맥락 없이 열린 방의 비용

링크를 먼저 보내고 안에서 해결하자는 패턴은 빠르지만, 기본 경로가 복구 모드가 된다. host는 매번 "무슨 일로 오셨죠?"를 다시 묻는다.

에서 보면 요청 흐름은 PonsLink가 회의 도구보다 연결 설계에 가까워진 이유를 보여준다. 방은 결과일 뿐, 시작점이 아니다.

처음에는 회의방 하나면 충분할 줄 알았다

초기에는 방 하나면 충분할 줄 알았다. 그런데 요청 단계가 제품 밖(카톡/메일/폼)에 흩어지면 방은 매번 빈 맥락으로 시작한다.

용건을 먼저 수집해야 세션 권한도, 이후 기록도 의미를 갖는다.

깨진 가정: 방이 제품의 중심이다

가정이 틀린 이유는 사용자가 기대하는 흐름 때문이다. 왜 만나는지 → 수락/일정 → 같은 맥락으로 입장 → 통화 후 추적. 방은 3번만 해결된다. 1·2·4가 비면 연결은 됐는데 일이 안 끝난다.

경계 재배치: 요청이 권한으로 바뀌는 경로

1. public desk에서 요청 접수
2. host 확인, 필요 시 booking/결제 상태 부착
3. 결과가 session authority로 변환
4. room은 그 authority를 소비
5. 통화 후 기록이나 후속 액션으로 복귀

room은 독립 서비스가 아니라 요청이 통과하는 한 단계가 된다. 연결 실패도 특정 단계의 복구 사건이 된다.

구현·운영에 남긴 조건

• 요청 없는 빈 방은 기본 경로가 아니다
• 요청 id로 방/세션/기록을 추적한다
• 실패 문장은 요청/권한/미디어를 구분한다
• 방 생성보다 요청→권한 경로를 먼저 설계한다

마치며

방을 만들기 전에 요청을 먼저 받는 건 순서 습관이 아니라, 맥락이 사라지지 않게 하는 제품 경계다.

지금은 이렇게 본다. 연결 기술이 문을 열어도, 문 앞에 어떤 용건을 세워 두느냐가 제품이 정한다. 요청이 먼저여야 방이 의미를 갖는다. 다음에 방 제품을 다시 만지면 요청 수집을 기본 경로로 그리고 시작하겠다.