[PonsLink] 회의방보다 먼저 요청과 운영의 혼란을 정리해야 했다

처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대를 불러 말하고, 같은 화면에서 파일도 주고받으면 된다고 봤다.

실제 운영에서는 방이 열리기 훨씬 앞에서 제품이 무너졌다. 누가, 왜, 언제 만나려는지 정리되지 않은 채 DM과 문의가 흩어졌고, 정작 방에 들어가면 맥락이 비어 있었다.

그래서 제목이 회의 기능이 아니라 이 문장이 됐다. 회의방보다 먼저 요청과 운영의 혼란을 정리해야 했다.

요청과 운영 혼란이 커진 지점

방이 생긴 뒤에도 반복된 질문은 비슷했다.

• 이 링크는 누구용인가
• 지금 들어가도 되는가
• 이전에 나눈 용건은 어디에 있나
• 파일은 왜 방에서 따로 논란이 되나
• 상대가 안 보이면 내가 잘못 들어온 건가

실시간 기능 버그보다 먼저 온 것은 운영 질문의 폭주였다. host는 상담자이자 스케줄러이자 문지기 역할을 동시에 해야 했다. UI에 버튼이 늘어날수록 책임 경계는 흐려졌다.

특히 위험했던 패턴은 “일단 방 링크를 보내고 안에서 해결하자”였다. 링크는 빠르지만, 맥락 없는 입장을 기본 경로로 만들면 제품이 항상 복구 모드로 시작한다. 복구 UI를 아무리 다듬어도, 기본 경로가 복구면 운영은 계속 피곤하다.

배포 직후 대시보드가 초록이어도 안심할 수 없었다. 연결 성공률은 괜찮았는데 host의 수동 작업이 늘었다. 일정 확인, 용건 재질문, 파일 재전송, 권한 설명. 제품이 자동화해야 할 일이 사람 쪽으로 역류하고 있었다. 이 역류가 보이면 기능 추가보다 경계 재설정이 먼저다.

처음에는 방이 중심이면 충분할 줄 알았다

초기 가설은 “좋은 room shell이면 연결 문제가 풀린다”였다. Lobby, device setup, presence, chat, file을 한 껍데기에 넣으면 완성에 가까워 보였다.

1. 요청 단계가 제품 밖에 있었다 용건과 일정과 수락이 카톡/메일/폼에 흩어지면, 방은 매번 빈 맥락으로 시작한다.
2. 파일 전송의 리듬이 통화와 달랐다 영상은 잠시 버티면 되지만, 파일은 중간 실패가 전체를 무효로 만든다. 같은 방 UI에 병렬로 얹으면 설명 비용이 폭발한다.

추가로 세 번째 구멍도 있었다. 공통 기술 스택을 공통 제품 경계로 착각한 것이다. WebRTC를 쓰니 영상·채팅·파일·presence를 한 제품 이야기로 묶고 싶어졌다. 하지만 사용자가 실패를 느끼는 지점이 다르면, 기술 공통성은 제품 공통성의 근거가 되지 못한다.

가설이 틀린 이유는 구현 능력이 부족해서가 아니었다. 한 화면이 감당할 수 있는 약속의 개수를 과대평가했다. 제품은 기능 집합이 아니라 실패 설명의 집합이다. 설명 못 할 약속을 같은 껍데기에 넣으면, 결국 모든 장애가 “방이 이상해요”로 번역된다.

분리가 선명해진 순간

정량 지표보다 선명했던 건 host의 말이었다. “방 만들기 전에 이미 지친다.”

이 문장은 성능 그래프보다 제품 경계를 빨리 바꿔 놓았다. 개선 포인트가 코덱이 아니라 입장 전 워크플로로 이동했다.

또 다른 불만은 “파일이 실패하면 회의 전체가 불안해 보인다”는 것이었다. 전송 장애가 회의 제품의 신뢰까지 깎았다. 기능 하나는 살아 있어도, 얼굴은 같이 다친다. 이 관찰이 분리를 설득하는 데 기술 벤치마크보다 더 강했다.

숫자로 보면 전송 실패 비율이 낮아도 체감 피해는 클 수 있다. 회의 중 한 번의 파일 실패는 그 세션의 분위기를 바꾼다. 평균이 아니라 순간이 브랜드를 만든다. 그래서 나는 “낮은 실패율”보다 “실패가 어느 제품의 얼굴에 묻는가”를 먼저 보기 시작했다.

경계를 둘로 나누기

정리한 분리는 개념적으로 이렇다.

영역	남는 제품	하는 일
요청·일정·세션 권한	PonsLink	만남의 이유와 입장 자격
대용량 직접 전송	PonsWarp	서버가 파일을 소유하지 않는 전송
실시간 협업 방	PonsLink room	권한이 확인된 뒤의 상호작용

한 화면에 다 넣으면 브랜딩은 단순해 보여도, 실패 설명이 불가능해진다. 반대로 경계를 나누면 각 제품이 “무엇을 보장하지 않는지”를 말할 수 있다.

분리의 핵심은 레포를 쪼개는 일이 아니라 문장을 쪼개는 일이었다. “연결에 실패했습니다” 한 줄로는 요청 만료, 미디어 실패, 전송 실패를 구분할 수 없다. 제품 이름이 달라지면 지원 문장, 로그 축, 우선순위 기준도 달라진다.

경계를 나눈 뒤에는 핸드오프도 설계해야 한다. 회의 중 대용량 전송이 필요하면 PonsWarp로 넘기고, 전송 완료 사실을 다시 만남 맥락에 붙일 수 있어야 한다. 그냥 링크 두 개를 던져 주는 분리는 사용자에게 숙제만 늘린다. 제품 분리와 사용자 여정 분리는 같이 설계해야 한다.

구현·운영에 남긴 조건

• 요청 맥락 없는 방 생성은 기본 경로가 아니다
• 파일 전송 상세 UX를 회의 화면의 부가 버튼으로 숨기지 않는다
• PonsLink는 “연결의 운영”, PonsWarp는 “전송의 경로”를 맡는다
• 공통 기술(WebRTC)이 공통 제품 경계를 의미하지 않는다
• 장애 리포트에 제품 경계를 명시한다

마지막 줄이 생각보다 중요하다. 온콜에서 “WebRTC 이슈”로 뭉개면 회의 권한 문제와 전송 백프레셔 문제가 같은 티켓으로 섞인다. 경계가 문서에만 있고 운영 분류에 없으면, 분리는 아직 완료되지 않은 것이다.

코드 리뷰에서도 같은 기준을 썼다. 이 변경이 회의 상태 머신에 전송 세부상태를 추가하는가? 요청 없는 입장을 더 쉽게 만드는가? 실패 문장이 제품 이름을 가리는가? 예라면 구현이 좋아 보여도 경계를 다시 검토한다. 빠른 기능 추가보다 느린 경계 수호가 장기적으로 더 싸다.

분리 이후에도 남는 일

경계를 나눴다고 일이 끝나지 않는다. 사용자는 여전히 “회의하다가 파일 보내기”를 한 흐름으로 생각한다. 제품이 둘로 나뉘어도 여정은 이어져야 한다.

그래서 분리 이후 과제는 세 가지로 줄었다.

1. PonsLink에서 요청-권한-방 흐름을 기본 경로로 단단히 만들기
2. PonsWarp에서 전송 상태 설명을 화면 중앙 계약으로 고정하기
3. 둘 사이의 핸드오프를 “새 숙제”가 아니라 “이어지는 단계”로 만들기

브랜드를 나눈 이유는 기능을 줄이려는 게 아니었다. 실패를 정직하게 소유하려는 것이었다. 그 소유권이 분명할 때, 통합 경험도 다시 설계할 수 있다. 분리를 결정한 뒤에도 가장 자주 받은 질문은 “그래도 한 제품이면 안 되나?”였다. 가능하다. 다만 한 제품으로 가려면 내부적으로라도 실패 소유권을 둘로 나눠야 한다. 브랜드가 하나여도 상태 머신과 지원 문장과 로그 축이 하나일 필요는 없다.

반대로 브랜드를 나눈 뒤 자주 생기는 실수는 완전 단절이다. 사용자를 새 서비스로 던져 놓고 맥락을 끊으면, 분리는 엔지니어의 정리 강박처럼 느껴진다. 좋은 분리는 사용자에게 “책임이 이동했다”는 사실을 보여 주되, 할 일의 연속성은 유지한다. 회의 중 전송이 필요하면 왜 전송 화면으로 가는지, 끝나면 어떻게 돌아오는지가 보여야 한다.

조직 관점에서도 분리는 도움이 됐다. 회의 권한 이슈와 전송 백프레셔 이슈를 같은 주간 우선순위에서 싸울 필요가 줄었다. 각각이 자신의 실패 표를 갖고, 자신의 완료 정의를 갖는다. 작은 팀에서 이건 감정적 비용 절감이기도 하다. 모든 장애가 전 제품 장애가 되면 사람들은 쉽게 소진된다.

결국 내가 배운 기준은 이것이다. 통합은 기본값이 아니라 획득해야 하는 상태다. 실패 문장을 독립적으로 말할 수 있을 때만, 다시 한 화면의 통합 UX를 논의할 자격이 생긴다. 그 전 단계의 억지 통합은 데모용 편의일 뿐이다. 브랜드 분리를 외부에 설명할 때는 짧게 말하는 편이 좋았다. PonsLink는 만남의 운영, PonsWarp는 파일의 이동. 한 문장씩. 그 이상 길게 변명하면 아직 경계가 불안하다는 신호다.

내부적으로는 더 길게 적는다. 어떤 이슈가 어느 제품 백로그로 가는지, 어떤 로그 필드가 필수인지, 어떤 지원 매크로를 쓰는지. 외부 한 문장과 내부 운영 명세가 쌍으로 있어야 분리가 유지된다. 외부 문장만 예쁜 분리는 금방 다시 섞인다.

제품 이름을 나누는 일은 거창한 리브랜딩처럼 보이지만, 본질은 운영 언어의 분리였다. 같은 장애를 다른 이름으로 부르기 시작할 때 비로소 다른 해결책이 보인다. 나는 그 지점을 더 일찍 만들었더라면 회의 제품의 신뢰 손상을 줄일 수 있었을 거라고 본다. 같은 결론을 다음 주 우선순위 회의에서도 다시 꺼내 보려 한다.

제품 이름을 나누는 일은 거창한 리브랜딩처럼 보이지만, 본질은 운영 언어의 분리였다. 같은 장애를 다른 이름으로 부르기 시작할 때 비로소 다른 해결책이 보인다. 나는 그 지점을 더 일찍 만들었더라면 회의 제품의 신뢰 손상을 줄일 수 있었을 거라고 본다.

마치며

PonsLink/PonsWarp 분리는 마케팅용 브랜드 확장으로 시작하지 않았다. 회의방 하나에 요청 운영과 대용량 전송까지 욱여넣다 설명이 불가능해진 결과였다.

지금은 이렇게 질문한다. 이 기능이 실패했을 때, 어느 제품의 문장으로 말할 수 있는가?

답할 수 없으면 아직 같은 화면에 두면 안 된다. 브랜드를 나누는 일은 거창한 전략처럼 보여도, 실제로는 운영 가능한 실패 단위를 만드는 일에 가깝다.

다음에 비슷한 유혹이 오면, 기능 통합의 편리함보다 실패 문장의 결합도를 먼저 계산하겠다. 그 계산이 제품 지도가 된다.