왜 PonsLink를 만들었는지부터 파일 전송 분리까지 읽는 대표 흐름
처음 PonsLink를 붙잡았을 때 내가 원했던 장면은 거창하지 않았다. 링크 하나만 던지면 상대가 별도 계정 없이 들어와서, 필요한 이야기를 나누면 끝나는 방. 회원가입 장벽이 만남의 속도를 늦추는 걸 보고 싶지 않았다. 그런데 계정 없는 링크를 "그냥 열린 방"으로 두면 금방 무너진다. 누구나 들어올 수 있으면, 권한·보관·악용 방지가 전부 제품 책임으로 남는다. 나는 이 지점에서 링크의 개방성과 권한의 명확함을 한덤어리로 푸는 착각을 했다.
PonsLink를 만들기 시작한 이유는 기술 호기심보다 불편함에 더 가까웠다. 누군가를 다시 만나야 하는 순간이 오면, 지난 대화의 맥락을 처음부터 복구해야 했다. 메시지를 찾고, 파일을 다시 보내고, 왜 만나려 했는지 다시 설명하는 일이 반복됐다. 처음에는 이 문제를 “좋은 회의 링크가 없어서”라고 짧게 정리했다. 틀렸다. 링크는 쉽게 만들 수 있었다. 진짜 문제는 연결이 끊긴 뒤에 **맥락이 같이 사라진다**는 점이었다.
방을 만들면 제품 설명은 나중에 따라올 줄 알았다. 영상이 되고, 채팅이 되고, 파일을 주고받고, 화이트보드까지 붙으면 사람들이 자연스럽게 이해할 거라고 생각했다. 기능이 쌓이면 제품이 된다고 본 셈이다. 실제로는 반대였다. 누가 왜 들어오는지, 어떤 요청이 먼저 있었는지, 돈을 받는다면 무엇에 대해 받는지, 결제 후 입장 권한이 어떻게 바뀌는지가 더 중요했다. 방은 보였는데 제품 설명은 계속 비었다.
WebRTC를 처음 제품에 넣을 때는 “브라우저끼리 직접 붙는다”는 말이 거의 마법처럼 들렸다. 서버가 미디어를 전부 중계하지 않아도 되고, 작은 팀도 실시간 방을 만들 수 있을 것 같았다. 실제로 WebRTC는 강력했다. 다만 두 달 동안 방 하나에 매달리며 배운 것은 반대편이었다. **WebRTC는 연결의 문을 열어줄 뿐, 제품의 질서는 만들어주지 않는다.**
PonsLink에서 가장 오래 남은 대비는 겉과 속의 차이였다. 사용자는 링크 하나를 클릭한다. 화면은 로비를 보여주고, 장치 권한을 묻고, 입장 버튼을 보여준다. 그러나 뒤에서는 SDP offer, SDP answer, ICE candidate, signaling room, peer identity, retry timer, TURN fallback이 계속 움직인다. 링크는 단순했지만, 그 단순함을 유지하려면 신호가 엉켰을 때도 제품이 침착해야 했다. [의 세부 기록이다. WebRTC 개념 자체는 [에서 더 넓게 다뤘다. 링크가…
영상이 켜지는 순간을 성공으로 보면 PonsLink는 너무 일찍 끝난다. 실제 상담이나 협업에서는 방에 들어온 사람이 누구인지, 어떤 권한을 받았는지, 끊겼다가 돌아왔을 때 무엇을 이어받는지가 더 오래 남는다. 이 판단은 ponslink-room-frontend/src/pages/Lobby.tsx와 ponslink-room-frontend/src/pages/Room.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과 실패했을 때 돌아갈 길에 있다.
PonsLink가 위험해진 순간은 기능이 부족할 때가 아니라 기능이 너무 쉽게 붙을 때였다. 채팅, 파일, 화이트보드, CoWatch, PonsCast는 각각 좋아 보였지만, 방의 이유를 설명하지 못하면 전부 잡음이 된다. 이 판단은 ponslink-room-frontend/src/pages/Room.tsx와 ponslink-room-frontend/src/components/functions/chat/ChatPanel.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과…
방은 영상 영역 하나가 아니라 대화가 흘러간 맥락을 담는 컨테이너였다. 누가 들어왔고, 무엇을 공유했고, 어떤 결정을 남겼는지가 이어지지 않으면 다음 접속은 다시 처음부터 시작된다. 이 판단은 ponslink-room-frontend/src/pages/LoungeRequests.tsx와 ponslink-room-frontend/src/pages/LoungeMeetingRecords.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과 실패했을 때 돌아갈 길에 있다.
처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. PonsCast는 기능표에서 나온 아이디어가 아니었다. 언어가 잘 통하지 않는 사람과 같은 파일을 같은 시간에 보고 싶다는 꽤 개인적인 욕심에서 시작됐다. PonsCast가 방의 기능 확장과 파일 전송 분리 사이의 다리였음을 이어진다. 화면 공유는 쉬운 답처럼 보였지만 내가 가진 파일을 상대의 언어와 시간에 맞춰 함께 본다는 문제는 달랐다. 같은 화면보다 같은 시간이 더 중요했다.
겨울에 다시 지어야 했던 건 UI가 낡아서가 아니었다. 방을 열 수는 있었지만 권한, 결제, 요청, 기록, 배포가 따로 움직이면 운영 가능한 제품이라고 부르기 어려웠다. 이 판단은 ponslink-room-frontend/src/pages/RequestAction.tsx와 ponslink-room-frontend/src/pages/SessionAccess.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과 실패했을 때 돌아갈 길에 있다. 같은 단어를 쓰더라도 제품 문맥이…
영상 회의만 붙잡고 있으면 PonsLink는 작은 방에서 멈춘다. 더 큰 방을 상상하면 모든 사람이 카메라를 켜는 구조보다 말, 듣기, 방송, 다시 재생하는 흐름이 먼저 필요해진다. 이 판단은 ponslink-room-frontend/src/components/media/PonsCastReceiverViewer.tsx와 ponslink-room-frontend/src/hooks/usePonsCastReceiver.test.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과…
회의 링크를 만들고 상대에게 보내기만 하면 끝날 줄 알았다. 실제로는 그보다 앞에서 시작됐다. 누가, 왜, 언제 만나고 싶은지 모르면 방은 비어 있었다. 요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다. 서로의 시간을 덜 낭비하게 만드는 완충지대였다. 요청을 받는 쪽에서 상태와 권한, 흐름을 먼저 정리해야 이후 회의가 성립했다.
그래서 PonsLink의 방은 기능 묶음이 아니라 사용자의 부담을 줄이는 약속에 가까웠다. 좋은 방을 만드는 것만으로는 실제 약속이 굴러가지 않았다. 내부에서는 한 단계가 삐끗한 것처럼 보여도, 바깥에서는 기다림과 불신으로 남는다. 그래서 단순한 구현보다 실패했을 때의 흐름을 먼저 잡아야 했다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. 처음에는 방 하나를 잘 만들면 된다고 생각했다. 그런데 사람은 링크만 타고 들어오는 게 아니라 기대와 불안도 같이 들고 들어왔다.
중계 서버에 맡기던 것들을 클라이언트와 signaling 경계로 옮기자 실패가 "방이 안 열림" 하나로만 보이기 시작했다. P2P 데모는 두 브라우저에서 예쁘게 붙는데 실제는 권한 지연, 재입장, 네트워크 전환이 섞인다. 데모 성공률만 보면 제품이 완성된 것처럼 보이지만 사용자는 매번 다른 실패를 만난다.
파일이 커질수록 전송은 방 안의 부가기능이 아니라 별도 제품이 됐다. 보내고 받고 저장하는 세 부분의 균형을 다시 잡은 기록이다.
파일 전송은 결국 방 밖으로 독립해야 했다. 처음에는 방 안에 두는 게 자연스러워 보였다. 사람이 붙어 있는데 파일 하나쯤 같이 보내면 될 줄 알았다. 방 UI 안의 파일 전송은 금방 이런 질문에 부딪혔다. 지금 업로드 중인가 peer 전송 중인가, 브라우저를 닫으면 이어받을 수 있는가, 상대가 새로고침하면 진행률은 어디로 가나.
요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다. 서로의 시간을 덜 낭비하게 만드는 완충지대였다. 요청 흐름은 PonsLink가 회의 도구보다 연결 설계에 가까워진 이유를 보여준다. 링크를 만들고 상대에게 보내는 순간부터 이미 회의가 시작된다. 누가, 왜, 언제 만나고 싶은지 모르면 좋은 방도 금방 비어 보였다.
처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대를 불러 말하고, 같은 화면에서 파일도 주고받으면 된다고 봤다. 실제 운영에서는 방이 열리기 훨씬 앞에서 제품이 무너졌다. 누가, 왜, 언제 만나려는지 정리되지 않은 채 DM과 문의가 흩어졌고, 정작 방에 들어가면 맥락이 비어 있었다.
작업 기록을 다시 읽으며 PonsLink가 아직 진행형인 이유를 알게 됐다. 회의방 하나를 만들면 링크를 보내고 같은 화면에서 대화와 파일을 주고받을 수 있을 거라 생각했다. 연결 자체는 열렸지만 그 뒤의 순서와 상태, 실패 복구는 제품이 직접 책임져야 했다. 신호 교환과 입장 순서, 메시지 채널과 파일 채널이 조금만 어긋나도 사용자는 연결됐다고 느끼지 못했다. 내부에서는 한 단계가 늦어진 것처럼 보여도 바깥에서는 기다림과 불신으로 남았다. 문제는 특정 기술 하나보다 책임을 정하지 않은 채 다음 작업으로 넘어간 데 있었다.
PonsLink를 만들 때 처음에는 회의방 하나면 충분하다고 생각했다. 링크를 만들고 상대를 초대하고, 같은 화면에서 대화와 파일 전송을 제공하면 된다고 봤다. 연결 자체는 빠르게 만들 수 있었지만, 사람이 방에 들어온 뒤 무엇을 믿고 어떤 상태를 따라야 하는지는 별도의 문제였다. 사람은 링크만 타고 들어오지 않는다. 초대받은 방이 어떤 상태인지, 내가 무엇을 할 수 있는지, 상대가 지금 연결돼 있는지를 함께 확인한다. 연결에 성공했다는 표시만으로는 부족했다. 상태와 권한, 기능의 무게를 제품이 기억해 줘야 방이 안정적으로…
처음에는 화상회의 앱을 만들면 된다고 생각했다. 카메라와 마이크가 켜지고 링크를 보내면 만남은 시작된다. 데모로는 충분했다. 그런데 실제로 사람을 만나게 해 보니 통화 전후의 빈칸이 더 크게 보였다. 상대는 방에 들어오기 전에 용건과 자료를 보내고, 통화가 끝난 뒤에는 다음 약속과 기록을 찾았다. 화면 안에서 대화가 잘 된 것만으로는 일이 이어지지 않았다.
WebRTC Mesh는 단순했지만 한계도 빨리 드러났다. 작은 방에서는 매력적이지만, 방이 커지고 기능이 붙으면 브라우저 부담과 signaling 복잡도가 같이 올라간다. Mesh 화상회의를 볼 때는 연결 모양보다 어느 자원이 어느 참여자에게 쌓이는지가 중요하다. Mesh에서 한 참여자는 자기 카메라 영상을 상대마다 보내야 한다. 참여자가 늘수록 업로드 부담이 선형 이상으로 커진다.
실시간 방은 처음 들어갈 때보다 다시 들어올 때 더 어렵다. 처음 입장은 빈 상태를 만들면 된다. 이미 채팅이 쌓이고 파일이 공유되고 화면 권한이 바뀐 뒤에 돌아오는 사람은, 연결만 성공하면 되는 게 아니라 같은 맥락으로 돌아와야 한다. 처음에는 그 차이를 얕봤다. 카메라와 마이크가 켜지는지, ICE가 붙는지처럼 눈에 보이는 연결 문제부터 고쳤다. 로그에 재연결 성공이 찍히면 일단 안심했다. 그런데 사용자 기억에 남는 사고는 다른 얼굴이었다. 한 사람은 새 파일을 보고, 다른 사람은 옛 목록을 본다. 권한은 서버에서 바뀌었는데…