Writing

주제: dev-retrospective/ponslink에 해당하는 글입니다.

주제

프로젝트

글 유형

75개의 글

2026년 8월 7일·PonsLink Technical Architecture·7 min

[PonsLink] WebRTC 시그널링과 TURN 인프라 구축 회고

실시간 제품을 만들면 처음엔 영상이 붙는 순간에 환호한다. 그다음 주부터는 NAT 뒤의 사용자, 회사 방화벽, 모바일 전환, 재연결 폭풍을 상대한다. PonsLink의 시그널링·TURN·SFU 구성은 그 실패를 제품 상태로 다루기 위한 결과다.

PonsLink개발회고WebRTCTURNSFU시그널링

2026년 8월 7일·PonsLink Technical Architecture·8 min

[PonsLink] 요청-세션 라이프사이클 설계 — 공개 데스크에서 자동 아카이브까지

PonsLink의 핵심 UX 원칙은 다섯 단계다. 방룸은 네 번째 단계에 불과하다. 이 글은 그 다섯 단계가 API·DB·프론트 라우트에 어떻게 내려앉는지 정리한다.

PonsLink개발회고Product Retrospective요청우선워크플로

2026년 8월 7일·PonsLink Technical Architecture·7 min

[PonsLink] 결제 연동과 웹훅 안정성 회고 — 다중 PG와 멱등성

결제는 "성공 페이지를 보여주면 끝나는 일"이 아니다. PonsLink는 Polar를 활성 공급자로 두고, PayPal·LemonSqueezy·Stripe 웹훅 경로를 함께 유지한다. 공급자가 늘수록 문제는 기능이 아니라 중복·지연·재시도다.

PonsLink개발회고Operations결제웹훅멱등성

2026년 8월 7일·PonsLink Technical Architecture·8 min

[PonsLink] 데이터 모델 설계 회고 — Postgres 두 개 DB, 37개 테이블

서비스를 오래 굴리면 스키마가 제품 결정을 배신한다. PonsLink도 예외가 아니었다. 한때는 "users 하나면 되겠지"로 시작했다가, 지금은 같은 Postgres 인스턴스 안에 두 개의 DB를 둔다. ponslink22테이블와 ponswarp15테이블. 이 글은 2026-08-07 실측 덤프를 기준으로 그 구조를 해설한다.

PonsLink개발회고ERDPostgres데이터모델

2026년 8월 7일·PonsLink Technical Architecture·7 min

[PonsLink] desk.ponslink.com은 어떻게 돌아가는가 — 배포 토폴로지 회고

PonsLink를 운영하면서 가장 자주 받는 질문은 단순하다. "이 서비스, 실제로 어떻게 붙어 있어요?" 마케팅 문구로는 "요청-우선 세션 데스크"라고 말하지만, 그 문장 뒤에는 nginx 한 줄, Node 컨테이너 한 개, Postgres 두 개의 DB, Redis, coturn, SFU, R2, 결제 공급자 네 곳이 동시에 움직인다. 이 글은 2026-08-07 기준 ssh pon...

PonsLink개발회고Architecture배포nginxWebRTC

2026년 7월 20일·PonsWarp 운영 노트·3 min

[PonsWarp] LAN에서 WebRTC가 한계에 부딪혔을 때, stripe가 아니라 cloud로 갈라졌다

대용량 파일을 브라우저끼리 직접 보내는 작업을 하면서 속도 문제를 만났을 때 가장 처음 떠올린 것은 더 빠른 채널을 여는 일이었다. 하지만 LAN에서도 WebRTC DataChannel은 일정 수준 이상으로 올라가지 않았고, 멀티 PC에서 striping을 시도했을 때

PonsWarpPonsLinkWebRTCLAN전송하이브리드

2026년 6월 29일·PonsLink Origin Story·5 min

[PonsLink] 실시간 방에서 상태가 어긋나는 순간을 먼저 봐야 했다

실시간 방은 처음 들어갈 때보다 다시 들어올 때 더 어렵다. 처음 입장은 빈 상태를 만들면 된다. 이미 채팅이 쌓이고 파일이 공유되고 화면 권한이 바뀐 뒤에 돌아오는 사람은, 연결만 성공하면 되는 게 아니라 같은 맥락으로 돌아와야 한다. 처음에는 그 차이를 얕봤다. 카메라와 마이크가 켜지는지, ICE가 붙는지처럼 눈에 보이는 연결 문제부터 고쳤다. 로그에 재연결 성공이 찍히면 일단 안심했다. 그런데 사용자 기억에 남는 사고는 다른 얼굴이었다. 한 사람은 새 파일을 보고, 다른 사람은 옛 목록을 본다. 권한은 서버에서 바뀌었는데…

PonsLinkMain ServicesRealtimeState SyncOperations

2026년 6월 29일·PonsLink Origin Story·3 min

[PonsLink] WebRTC Mesh는 단순했지만 한계도 빨리 드러났다

WebRTC Mesh는 단순했지만 한계도 빨리 드러났다. 작은 방에서는 매력적이지만, 방이 커지고 기능이 붙으면 브라우저 부담과 signaling 복잡도가 같이 올라간다. Mesh 화상회의를 볼 때는 연결 모양보다 어느 자원이 어느 참여자에게 쌓이는지가 중요하다. Mesh에서 한 참여자는 자기 카메라 영상을 상대마다 보내야 한다. 참여자가 늘수록 업로드 부담이 선형 이상으로 커진다.

PonsLinkMain ServicesWebRTCMeshRealtime

2026년 6월 29일·PonsLink Origin Story·3 min

[PonsLink] 화상회의 앱을 만들려다 협업 방을 만들게 됐다

처음에는 화상회의 앱을 만들면 된다고 생각했다. 카메라와 마이크가 켜지고 링크를 보내면 만남은 시작된다. 데모로는 충분했다. 그런데 실제로 사람을 만나게 해 보니 통화 전후의 빈칸이 더 크게 보였다. 상대는 방에 들어오기 전에 용건과 자료를 보내고, 통화가 끝난 뒤에는 다음 약속과 기록을 찾았다. 화면 안에서 대화가 잘 된 것만으로는 일이 이어지지 않았다.

PonsLinkMain ServicesWebRTCCollaborationProduct Retrospective

2026년 6월 29일·PonsWarp Origin Story·9 min

[PonsWarp] 파일 전송은 PonsLink 안에서 먼저 고장났다

파일 전송을 처음부터 별도 제품으로 생각한 건 아니었다. PonsLink 방에 사람이 붙어 있으니, 파일 하나 보내는 버튼 정도는 자연스러워 보였다. 붙여 보니 먼저 무너진 것은 버튼 위치가 아니라 **약속의 크기**였다. 사용자는 “파일 전송” 한 줄로 이해하지만, 제품은 연결·진행률·메모리·저장 완료·실패 후 재시도를 모두 설명해야 했다.

PonsWarpPonsLinkProduct RetrospectiveFile Transfer

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] Product Hunt보다 먼저 직접 판매를 봐야 한다고 판단했다

Product Hunt에 올리고 싶은 마음은 있었다. 공개 런치는 빠르게 반응을 모으고, 만든 사람에게는 출시했다는 확신을 준다. 하지만 그 확신이 실제 구매 의사와 같은지는 알 수 없다. 그래서 먼저 직접 팔아 보기로 했다. 한 사람에게 제품을 설명하고 가격을 말하는 동안, 랜딩 페이지의 문장만으로는 보이지 않던 질문이 나왔다. 누구에게 필요한지, 어떤 약속에 돈을 내는지, 설명이 막히는 지점이 어디인지였다.

PonsLinkFounder SalesLaunchValidation

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] DM은 워크플로가 아니라는 문장을 붙잡게 된 이유

DM은 시작점으로는 훌륭하다. 가볍게 말을 걸고, 상대의 온도를 확인하고, 링크 하나를 건네기에는 가장 빠른 채널이다. 문제는 그 다음이었다. 상담 요청이 DM 안에서 계속 이어지면 상태와 권한, 기록과 결제, 재방문 약속이 대화의 스크롤 속에 묻힌다. 사람이 기억하는 동안에는 굴러가지만, 문의가 겹치는 순간 운영은 기억력 게임이 된다.

PonsLinkCategory CreationMessagingWorkflow

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 첫 고객은 넓은 미팅 시장이 아니라 DM 상담을 받는 1인 전문가였다

첫 고객을 넓은 미팅 시장으로 잡으면 메시지가 바로 흐려진다. 상담도 하고, 회의도 하고, 파일도 주고받는 모든 사람을 고객이라고 부르는 순간 랜딩과 폼과 가격이 서로 다른 사람을 부른다. 나는 첫 고객을 DM 상담을 받는 1인 전문가로 좁혔다. 혼자 상담하고, 채널은 DM이며, 일정과 사전 질문을 정리하고 싶은 사람이다. 시장을 포기한 것이 아니라 지금 당장 관찰할 장면을 하나로 고른 것이다.

PonsLinkFounder SalesICPMarket

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 정식 유료 출시를 No-Go로 판단한 이유

정식 유료 출시를 앞두고 No-Go를 적었다. 기능이 모자라서가 아니었다. 결제는 붙었고 방도 열렸고 랜딩도 있었다. 겉으로는 Go라고 부를 근거가 충분했다. 하지만 돈이 움직인 뒤 운영자가 어떤 문장으로 설명할지는 정해지지 않았다. 실패하면 누구에게 무엇을 알려야 하는지, 환불과 보류를 어디에서 나눌지, 첫 고객을 누구라고 부를지 흔들렸다. 출시 버튼을 누르는 것보다 그 질문에 답하는 일이 먼저였다.

PonsLinkMarket ValidationNo-GoFounder Note

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 랜딩 페이지를 미팅 앱 소개에서 요청 선별 이야기로 바꿨다

랜딩 페이지를 미팅 앱 소개처럼 만들고 있었다. 기능 목록과 화면 캡처, 연결이 안정적이라는 설명을 앞에 놓으면 사람들이 PonsLink를 이해할 거라고 생각했다. 그런데 실제 사용 이유는 통화 품질이 아니었다. DM으로 들어온 요청을 정리하고, 누구와 어떤 이야기를 해야 하는지 미리 맞춘 뒤 덜 민망하게 만나는 일이었다. 랜딩이 제품을 설명하지 못하니 방문자는 익숙한 미팅 앱과 비교했고, PonsLink가 풀려는 문제는 첫 화면에서 사라졌다.

PonsLinkLanding PagePositioningConversion

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 요청 상태 토큰과 세션 입장 토큰을 같은 것으로 둘 수 없었다

요청 상태를 보는 토큰과 세션에 입장하는 토큰을 처음에는 비슷하게 취급했다. 하지만 상태 링크가 유출됐다고 입장 권한까지 열려서는 안 된다. 입장 토큰이 오래 살아 있으면 끝난 방에 다시 들어오는 문제도 생긴다. 상태 토큰은 읽기와 짧은 수명, 좁은 스코프를 가져야 했다. 입장 토큰은 승인과 결제 이후에 세션 단위로 발급하고, 방이 끝나거나 권한이 바뀌면 폐기할 수 있어야 했다. 이름이 비슷해도 책임은 달랐다.

PonsLinkSecurityTokenPermission

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 요청에서 룸까지 가는 길을 줄이는 것이 가장 어려웠다

요청에서 룸까지 가는 길을 줄이는 일이 기능 추가보다 어려웠다. 결제, 보류, 재요청, 일정 변경은 각각 필요한 예외였지만, 하나씩 붙이다 보니 사용자가 지나야 할 단계가 계속 늘었다. 각 단계는 옳아 보이는데 전체 경로는 길어졌다. 사용자는 지금 무엇을 결정해야 하는지 잃었고, 운영자는 예외를 설명하는 데 시간을 썼다.

PonsLinkMeeting FlowUXSimplification

2026년 6월 28일·PonsLink Product Operations·3 min

[PonsLink] 관리자 OTP 대시보드는 운영 책임을 화면으로 옮기는 일이었다

관리자 OTP 대시보드는 보안 기능처럼 보이지만 본질은 운영 책임을 화면으로 옮기는 일이었다. 예전에는 코드 발급과 예외 승인, 긴급 입장이 메신저에 흩어질 수 있었다. 그러면 기록이 남지 않고 누가 어떤 판단을 했는지도 흐려진다. OTP를 만들 수 있는 것만으로는 운영 도구가 되지 않는다. 언제 발급됐는지, 만료됐는지, 사용됐는지, 어떤 액터가 실행했는지가 한곳에서 보여야 한다. 그래야 예외를 허용한 뒤에도 그 예외가 어떻게 끝났는지 확인할 수 있다.

PonsLinkAdminOTPOperations

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 결제 성공 화면만으로 세션을 열 수는 없었다

결제 성공 화면은 기분 좋은 초록색이다. 하지만 그 화면만 보고 세션을 열면 안 됐다. 브라우저는 성공을 먼저 보여줄 수 있고, 웹훅은 늦게 도착할 수 있다. 같은 이벤트가 중복으로 들어오는 경우도 있다. 화면과 서버 상태를 같은 진실로 취급하면 권한 없는 입장이 열릴 수 있다. 성공 UI 뒤에는 pending access 상태가 필요했다. 서버가 결제 확정을 반영하기 전까지는 방을 열지 않고, 사용자는 지금 결제 확인 중이라는 사실을 알아야 한다. “결제 확인 중”과 “입장 가능”을 같은 화면 문장으로 뭉개면 기다림이 오류처럼…

PonsLinkWebhookPayment AccessOperations

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] Polar 결제 런칭은 체크아웃 버튼보다 준비 게이트가 더 중요했다

Polar 결제 런칭을 앞두고 체크아웃 버튼에 눈이 갔다. 버튼이 눌리는 순간을 런칭으로 생각하기 쉽지만, 실제 준비는 그보다 길었다. 요청의 질, 환불 정책 문장, 결제 실패 상태, 관리자가 멈출 수 있는 경로가 비어 있으면 결제만 먼저 열리는 셈이다. 체크아웃 전에 미완 요청을 결제해도 되는지, 성공과 실패와 대기를 어떻게 구분할지 확인했다. 결제가 성공해도 권한 부여가 끝나지 않을 수 있으므로 운영자가 상태를 확인하고 중단할 수 있어야 했다. 버튼은 마지막에 붙는 표면일 뿐, 그 앞의 조건이 런칭의 본체였다.

PonsLinkPolarPaymentLaunch

2026년 6월 28일·PonsLink Product Operations·3 min

[PonsLink] 플랜 집행은 버튼 비활성화가 아니라 제품 신뢰의 문제였다

플랜 집행을 버튼 비활성화로만 처리하면 화면은 조용해 보인다. 사용자는 오히려 왜 안 되는지 알 수 없어서 제품을 버그처럼 느낀다. 한도에 도달했는지, 결제가 필요한지, 현재 권한으로는 할 수 없는지에 따라 다음 행동도 달라져야 했다. 플랜 경계는 백엔드의 판정만으로 끝나지 않는다. UI에는 상태와 이유, 사용자가 선택할 수 있는 다음 행동이 함께 있어야 한다. 같은 비활성 버튼이라도 한도 소진과 권한 부족은 서로 다른 문제다. 둘을 같은 문장으로 처리하면 사용자는 무엇을 고쳐야 하는지 알 수 없다.

PonsLinkEntitlementProduct PolicyTrust

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 한도를 넘겨도 방문자 요청은 버리지 않기로 했다

한도에 닿으면 요청을 막아 버리기 쉽다. 구현도 단순하다. 더 이상 받지 않는다는 문장을 보여 주고 입력을 닫으면 된다. 나는 한도를 넘어도 방문자의 요청은 버리지 않기로 했다. 한도는 내 처리 용량이지, 상대가 가진 용건의 가치가 아니기 때문이다. 방문자는 입력창이 닫히면 서비스가 끝났다고 생각한다. 운영자는 그 기간에 들어온 요청이 있었다는 사실조차 보지 못한다. 용량을 보호하려다 수요의 신호까지 버리는 셈이다.

PonsLinkPlan EnforcementQuotaUX

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] Free 10건과 Pro 구조를 이렇게 나눈 이유

Free 10건과 Pro를 나눌 때 먼저 정한 것은 가격이 아니라 무료 사용자가 어디까지 제품을 이해해야 하는가였다. 기능을 잠가 결제를 유도하면 사용자는 제품을 경험하기 전에 벽을 만난다. 반대로 모든 것을 열어 두면 운영 비용과 요청 품질을 감당하기 어려워진다. Free는 요청을 보내고, 선별을 거쳐, 방에 들어가는 한 사이클을 끝까지 돌릴 수 있어야 했다. 그래야 사용자가 PonsLink의 약속을 판단할 수 있다. 제한은 기능을 숨기는 대신 사용량의 속도를 조절하는 쪽에 두었다. 10건이라는 숫자는 제품의 핵심 경험을 막지…

PonsLinkPricingPlanProduct

2026년 6월 28일·PonsLink Product Operations·3 min

[PonsLink] Google Form은 수집하고, PonsLink는 흐름을 이어야 했다

Google Form은 수집에 강하다. 배포가 쉽고 응답이 쌓인다. 부족했던 것은 그다음이었다. 응답은 스프레드시트에 남고, 일정은 다른 탭에 있고, 방은 또 다른 링크가 되면 사람이 직접 흐름을 이어 붙여야 한다. 사람이 여유가 있을 때는 스프레드시트와 일정과 방을 연결할 수 있다. 하지만 응답이 늘거나 담당자가 바뀌면 누가 다음 행동을 해야 하는지가 흐려진다. 수집 도구가 부족해서가 아니라, 수집 이후의 승인과 상태와 입장이 다른 곳에 흩어져 있기 때문이다.

PonsLinkComparisonFormWorkflow

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] Calendly와 PonsLink는 경쟁이 아니라 순서가 다르다

처음 기대와 실제 제약을 한 번 충돌시킨 뒤 선택 이유가 드러났다. Calendly와 Pon 다음에 남는 질문은 한 문장으로 충분하다. 일정을 먼저 잡는 방식과 요청을 먼저 확인하는 방식은 순서부터 달랐다. 일정을 먼저 잡는 방식과 요청을 먼저 확인하는 방식은 순서부터 달랐다. 처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. 돈을 받는 순간 제품의 무게가 달라졌다. 버튼 하나를 붙이면 끝날 줄 알았지만, 실제로는 누가 어떤 권한으로 언제 들어올…

PonsLinkComparisonCalendlyPositioning

2026년 6월 28일·PonsLink Product Operations·3 min

[PonsLink] 멘토링과 코칭 요청 폼에는 다른 질문이 필요했다

멘토링 요청과 코칭 요청을 같은 폼에 넣었다가 후회했다. 둘 다 대화인데, 필요한 재료가 달랐다. 멘토링은 경험 공유와 방향 제안이 중심이다. 코칭은 상대의 목표·장애물·다음 행동이 중심이다. 템플릿을 둘로 나눴다. 멘토링: 맥락, 이미 시도한 것, 기대하는 조언 범위. 코칭: 목표, 성공 기준, 지금 막힌 한 지점.

PonsLinkTemplateMentoringCoaching

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] 유료 상담은 결제보다 요청의 질을 먼저 봐야 했다

유료 상담을 붙이면 결제 연동부터 보고 싶어진다. 체크아웃과 영수증, 웹훅이 연결되면 제품이 완성된 것처럼 보인다. 현장에서는 결제가 되어도 요청의 질이 낮으면 상담이 망가졌다. 운영자는 준비되지 않은 만남을 수습하고, 상대는 돈을 냈는데 원하는 대화를 하지 못했다고 느낀다.

PonsLinkPaid ConsultationPaymentProduct

2026년 6월 28일·PonsLink Product Operations·1 min

[PonsLink] Meeting Records는 회의록이 아니라 요청 맥락의 연장이다

내가 필요했던 건 그전에 있었다. 요청 맥락이 회의 뒤로 이어지는 자리. 방에 들어가기 전 용건이 비면 회의록은 빈 대화를 예쁘게 정리할 뿐이다. 요청에 적힌 목표, 제약, 기대가 기록의 뼈대가 되어야 한다. 기록 화면 상단에 요청 요약을 고정했다. 회의 중 메모는 그 아래에 쌓인다. 끝난 뒤에도 "왜 만났는지"가 먼저 보인다.

PonsLinkMeeting RecordsOperationsKnowledge

2026년 6월 28일·PonsLink Product Operations·1 min

[PonsLink] 승인과 입장을 같은 순간으로 만들지 않기로 했다

요청을 수락했다고 바로 방에 들여보내면 편하다. 한동안 그렇게 했다. 승인은 "이 사람과 일해볼 만하다"는 결정이다. 입장은 "지금 이 세션에 들어와도 된다"는 결정이다. 둘을 묶으면 일정 전 링크 유출, 재입장 혼선, 결제 전 입장 같은 예외를 설명하기 어려워진다. 승인 후에도 입장 토큰은 따로 발급한다. 시간창, 세션 상태, 결제 조건을 통과해야 문이 열린다. 사용자는 단계가 늘어 보이지만, 막혔을 때 이유가 분리되어 보인다.

PonsLinkSession AccessSecurityUX

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] Request Status는 요청 제출 뒤의 침묵을 줄이기 위한 화면이었다

요청을 보내고 나면 방문자는 조용한 화면에 남는다. 접수됐는지, 읽혔는지, 보류인지, 거절인지 알 수 없다. 내부에서는 한 단계만 밀린 것일 수 있다. 바깥에서는 무시당한 느낌이 된다. 같은 지연도 상태를 보여 주느냐에 따라 전혀 다르게 해석된다. 요청이 접수됐다는 안내만으로는 부족했다. 방문자는 다음 행동을 알 수 없고, 운영자는 같은 질문에 계속 답해야 했다. “확인됐나요?”라는 DM은 내부에서 실제로 어떤 일이 진행되는지 보여 주지 못한다.

PonsLinkRequest StatusUXTrust

2026년 6월 28일·PonsLink Product Operations·1 min

[PonsLink] 좋은 요청, 보류할 요청, 거절할 요청은 문장 몇 줄에서 갈렸다

처음에는 편의를 위한 상태값처럼 보였다. 실제로는 문장 몇 줄로 사람을 나누는 운영 도구였다. 전부 수락하면 일정이 터진다. 전부 거절하면 문이 닫힌다. 문제는 중간이다. 정보가 부족한 요청을 수락해 버리면 방 안에서 다시 질문부터 시작한다. 보류를 "나중에"가 아니라 제품 상태로 올렸다. 무엇을 더 알아야 하는지, 상대에게 어떤 한 줄을 돌려줄지 보류 사유를 남기게 했다. 거절도 차갑지 않게, 분명하게.

PonsLinkScreeningOperationsDecision

2026년 6월 28일·PonsLink Product Operations·1 min

[PonsLink] 공개 요청 링크는 어디에 붙이느냐보다 앞 문장이 더 중요했다

공개 요청 링크를 어디에 붙일지 한참 고민했다. 프로필 바이오, 카톡 자동응답, 이메일 서명. 링크만 덩그러니 있으면 사람들은 자기 방식으로 쓴다. 긴 하소연, 한 줄 영업, 의미 불명 테스트 제출. 링크 앞에 기대 행동을 적었다. 무엇을 남기면 좋은지, 언제 답을 주는지, 어떤 요청은 받지 않는지.

PonsLinkGuidePublic LinkUsage

2026년 6월 28일·PonsLink Product Operations·2 min

[PonsLink] Public Desk는 문의 폼이 아니라 첫 번째 운영 게이트다

Public Desk를 처음 붙일 때는 문의 폼이라고 불렀다. 이름부터 틀렸다. 폼은 제출을 받지만, 제출된 요청을 어떻게 판단할지는 말해 주지 않는다. 운영자는 메일함에서 다시 읽고, 캘린더를 열고, 별도 링크를 보냈다. 방문자는 보냈으니 끝났다고 생각했지만 내부에서는 아직 분류도 되지 않은 상태였다.

PonsLinkPublic DeskUXOperations

2026년 6월 28일·PonsLink Product Operations·4 min

[PonsLink] DM 상담 요청을 바로 예약으로 보내지 않기로 한 이유

DM을 곧바로 캘린더 예약으로 보내면 시간은 잡히지만 상담의 용건은 비어 있었다. 요청을 먼저 확인해야 하는 이유를 정리했다.

PonsLinkProductRequest-firstFounder Note

2026년 6월 17일·PonsLink Deep Dive·2 min

[PonsLink] 결국 남은 것은 제품을 버티게 한 작은 경계들

겉으로 보이는 선택은 단순했지만, 안쪽에는 실패를 줄이려는 기준그 기준을 보여주지 않으면 글은 금방 보고서처럼 마른다. 다음에 남는 질문은 한 문장으로 충분하다. 결국 남은 것은 제품을 그래서 결론보다 그 결론까지 밀려간 과정을 먼저 보여주는 쪽으로 다시 잡는다. 처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. 처음에는 쉽게 정리할 수 있는 문제처럼 보였다. 그런데 직접 만들고 운영해보니 문장 하나로 접히지 않는 갈등이 남았다. 패턴을 테스트로…

PonsLink디자인패턴테스트RepositoryFacadePolicyWorker

2026년 6월 17일·PonsLink 알고리즘 노트·3 min

[PonsLink] PonsCast가 화면 공유 대신 DataChannel을 택한 이유

PonsCast를 만들며 화면 공유를 먼저 떠올린 것은 자연스러웠다. 화면 공유는 상대가 무엇을 보는지 바로 맞출 수 있다. 하지만 우리가 해결하려던 문제는 같은 화면을 복제하는 일이 아니었다. 각자가 가진 파일을 상대의 언어와 시간에 맞춰 함께 읽는 일이었다. 화면 공유는 쉬운 답처럼 보였지만 파일의 구조와 상태를 직접 다루기 어렵다. 보는 사람은 화면을 받지만 파일을 함께 읽고 조작하는 흐름과는 거리가 있다. 네트워크가 흔들리면 화면 전체가 영향을 받고 무엇을 기준으로 다시 맞출지도 분명하지 않다.

PonsLinkPonsCastTradeoffScreenShareSFUDataChannelP2P

2026년 6월 17일·PonsLink Deep Dive·3 min

[PonsLink] 결제 버튼보다 어려운 것은 입장 권한이다

돈을 받는 순간 제품의 무게가 달라졌다. 결제 버튼을 붙이면 끝날 줄 알았지만 실제로는 누가 어떤 권한으로 언제 세션에 들어올 수 있는지가 더 어려웠다. 결제 성공과 권한 부여, 세션 입장은 사용자에게 한 번의 흐름처럼 보인다. 운영에서는 서로 다른 사건으로 다뤄야 했다. 결제가 확인되지 않았는데 입장이 열리거나 결제는 됐는데 권한이 늦게 생기면 어느 화면을 진실로 볼지 설명할 수 없기 때문이다.

PonsLink결제PolarIdempotencyWebhookSessionAccess

2026년 6월 17일·PonsLink 알고리즘 노트·3 min

[PonsLink] 마이크와 PonsCast 오디오를 함께 살리는 라우팅

PonsCast 오디오를 방 안의 마이크와 함께 다루면서 소리를 한 줄의 미디어 스트림으로 볼 수 없다는 걸 알게 됐다. 사용자의 목소리와 파일에서 재생되는 소리는 출처와 역할이 다르다. 둘을 같은 방식으로 섞으면 말하는 사람의 목소리가 묻히거나 재생 소리가 예상하지 못한 방식으로 전달될 수 있다.

PonsLinkPonsCastAudioAudioContextMicrophoneMediaStream

2026년 6월 17일·PonsLink Deep Dive·2 min

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

DM이나 문의가 흩어져 들어오고, 정작 회의 전에 맥락이 사라지던 일방을 먼저 만들면 그 맥락을 제품 안에 담을 곳이 없다. 링크를 먼저 보내고 안에서 해결하자는 패턴은 빠르지만, 기본 경로가 복구 모드가 된다. host는 매번 "무슨 일로 오셨죠?"를 다시 묻는다. 에서 보면 요청 흐름은 PonsLink가 회의 도구보다 연결 설계에 가까워진 이유를 보여준다. 방은 결과일 뿐, 시작점이 아니다.

PonsLinkPublicDesk상태머신예약SessionAccessProductArchitecture

2026년 6월 17일·PonsLink 알고리즘 노트·3 min

[PonsLink] PonsCast 파일 감지와 캐시 전략의 기준

화면 공유와 파일 동기화는 비슷해 보이지만 “같은 시간을 공유한다”는 요구는 완전히 달랐다는 문제가 있었다. PonsCast 캐시는 같은 파일을 다시 읽는 비용과 재생의 흐름을 함께 봐야 했다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. PonsCast는 기능표에서 나온 아이디어가 아니었다. 언어가 잘 통하지 않는 사람과 같은 파일을 같은 시간에 보고 싶다는 꽤 개인적인 욕심에서 시작됐다.

PonsLinkPonsCastFileTypeDetectionIndexedDBCachePolicyQuotaExceeded

2026년 6월 17일·PonsLink Technical Architecture·11 min

[PonsLink] DataChannel 하나에 모든 메시지를 태우면 왜 위험할까

처음에는 DataChannel을 하나만 열어도 충분하다고 생각했다. 브라우저끼리 직접 붙고, 그 통로로 채팅도 보내고 파일 조각도 보내고 PonsCast 제어 메시지도 보내면 구조가 단순해 보였다. 방 안의 모든 실시간 메시지가 같은 길을 지나가니 디버깅도 쉬울 거라고 봤다. 그제야 제목으로 남긴 '[PonsLink DataChannel 하나에 모든 메시지를 태우면 왜 위험할까'이 기능 홍보가 아니라, 내가 붙잡고 있던 판단 기준에 가깝다는 걸 인정했다.

PonsLinkDataChannel파일전송화이트보드알고리즘Realtime

2026년 6월 17일·PonsLink 알고리즘 노트·3 min

[PonsLink] DataChannel 재생을 버티게 하는 백프레셔와 지터 버퍼

PonsCast는 파일을 보내는 기능보다 같은 시간을 공유하는 방식에 가까웠다. 화면 공유는 쉽게 떠올릴 수 있는 답이었지만, 내가 가진 파일을 상대의 언어와 속도에 맞춰 함께 보는 일은 화면을 복제하는 것과 달랐다. DataChannel 재생이 끊기면 이 차이가 바로 드러났다. 보내는 쪽이 계속 데이터를 밀어 넣으면 받는 쪽은 잠깐 뒤처진다. 그 차이가 쌓이면 재생은 끊기고, 같은 장면을 보고 있다는 약속도 무너진다. 내부에서는 버퍼가 조금 늘어난 것처럼 보여도 사용자에게는 불안정한 경험으로 남는다.

PonsLinkPonsCastBackpressureJitterBufferTokenBucketMSE

2026년 6월 17일·PonsLink Technical Architecture·4 min

[PonsLink] Mesh 연결은 단순해 보여도 순서가 제품 품질을 만든다

Mesh 연결은 단순해 보였다. 참여자끼리 직접 연결하면 작은 방에서는 구조를 이해하기 쉽다. 하지만 한 단계의 실패가 사용자에게는 연결 전체의 불안으로 보인다는 점이 곧 드러났다. 신호 교환과 입장 순서, 메시지 채널과 파일 채널이 정확히 맞아야 했다. 내부에서는 이벤트 하나가 늦은 것처럼 보여도 사용자는 연결됐다고 느끼지 못한다. Mesh의 단순함은 연결 수를 줄이는 데서 끝나지 않고 실패했을 때 무엇을 다시 시도할지까지 포함해야 했다.

PonsLinkWebRTCMeshICERealtime

2026년 6월 17일·PonsLink 알고리즘 노트·2 min

[PonsLink] DataChannel 위에 PonsCast 프로토콜을 올린 이유

PonsCast는 방 안에 붙인 미디어 기능으로 시작하지 않았다. 언어가 잘 통하지 않는 사람과 같은 파일을 같은 시간에 보고 싶다는 개인적인 필요에서 출발했다. 화면 공유를 쓰면 화면은 같아진다. 하지만 상대가 파일의 어느 부분을 보고 있는지, 같은 속도로 따라오고 있는지, 한쪽이 바뀐 내용을 다른 쪽이 놓치지 않는지는 별개의 문제였다. 내가 해결하고 싶었던 것은 같은 화면보다 같은 시간을 공유하는 일이었다.

PonsLinkPonsCastDataChannelBinaryStreamingMSEMediaSource

2026년 6월 17일·PonsLink Technical Architecture·3 min

[PonsLink] WebRTC 전에 신호 경계가 먼저 막아야 하는 것

WebRTC는 연결의 문을 열어 주지만 그 뒤의 질서까지 만들어 주지는 않는다. 신호 교환과 입장 순서, 메시지 채널과 파일 채널이 조금만 어긋나도 사용자는 연결 자체를 불안하게 느낀다. 브라우저가 직접 연결되면 서버 부담도 줄고 구조도 단순해질 것이라 기대했다. 그러나 연결 뒤의 상태 관리와 순서 보장, 실패 복구는 여전히 제품의 몫이었다. 연결이 성립했다는 이벤트만 전달해서는 방이 안정적으로 움직이지 않았다.

PonsLinkSocketIOWebRTCSignalingTURNReplay

2026년 6월 17일·PonsLink 알고리즘 노트·2 min

[PonsLink] 여러 내부 상태를 하나의 사용자 문장으로 접기

회의는 방에 들어온 뒤 시작되는 줄 알았다. 실제로는 그보다 앞에서 이미 시작된다. 누가, 왜, 언제 만나고 싶은지 모르면 좋은 방도 금방 비어 보인다. 그래서 요청 흐름을 먼저 받는 구조로 바꿨다. 요청을 받는 일은 사람을 거르는 장치가 아니라 서로의 시간을 덜 낭비하게 만드는 완충지대였다. 문제는 내부에 여러 상태가 생겼다는 점이다. 사용자에게 그 상태를 그대로 보여 주면 제품은 곧바로 내부 시스템처럼 보인다.

PonsLink상태머신RequestStateUXReservation

2026년 6월 17일·PonsLink Technical Architecture·3 min

[PonsLink] 서버가 미디어를 나르지 않을 때 남는 책임

서버가 미디어를 나르지 않으면 편해질 줄 알았다. 트래픽 비용이 줄고 인코딩 부담도 클라이언트 쪽으로 가니 운영이 단순해 보였다. 그 문장은 절반만 맞았다. 막상 해보니 사라지는 건 미디어 운반뿐이었다. 세션 권한, 기능 허용, 중계 자격, 업로드 주소, 방 권한, 실패 문장 번역은 그대로 남았다. 미디어를 안 나를수록 제어면 경계가 더 선명해야 제품이 안전해졌다.

PonsLinkBackendExpressBFFControlPlaneAPIKey

2026년 6월 17일·PonsLink Technical Architecture·2 min

[PonsLink] 놓친 이벤트와 중복 요청을 동시에 줄이는 법

놓친 이벤트와 중복 요청은 서로 다른 오류처럼 보이지만 사용자에게는 같은 결과로 남는다. 한 번 보낸 요청이 사라지거나, 같은 요청이 두 번 처리되면 화면의 상태와 실제 상태가 어긋난다. PonsLink의 요청 흐름을 만들면서 이 문제를 뒤늦게 분리했다. 요청을 먼저 받고, 상태를 바꾸고, 방이나 다음 단계로 넘기는 과정에서 이벤트가 한 번 빠져도 다시 확인할 수 있어야 했다.

PonsLinkReplayIdempotencyRedis결제

2026년 6월 17일·PonsLink Deep Dive·3 min

[PonsLink] 전역 상태처럼 보였던 런타임 버스

처음 기대와 실제 제약을 한 번 충돌시킨 뒤 선택 이유가 드러났다. 런타임 상태를 한곳에서 다루려면 각 상태의 책임과 경계를 먼저 정해야 했다. 다음에 남는 질문은 한 문장으로 충분하다. 처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. 처음에는 쉽게 정리할 수 있는 문제처럼 보였다. 그런데 직접 만들고 운영해보니 문장 하나로 접히지 않는 갈등이 남았다. 전역 상태처럼 보였던 런 겉으로 보이는 선택은 단순했지만, 안쪽에는 실패를 줄이려는 기준그…

PonsLinkZustand상태관리디자인패턴ReactRealtime

2026년 6월 17일·PonsLink 알고리즘 노트·2 min

[PonsLink] P2P 파일 전송에 작은 TCP가 필요했던 이유

P2P만 있으면 나머지는 따라올 거라고 믿었다. 같은 단어를 쓰더라도 제품 문맥이 다르면 답이 갈렸다. 그 갈림길을 숨기지 않는 쪽으로 썼다. 파일 전송은 보내고 받는 속도가 다르다는 사실부터 인정해야 했다. 처음 기대와 실제 제약을 한 번 충돌시킨 뒤 선택 이유가 드러났다. 보내는 일, 받는 일, 저장하는 일은 같은 줄에 서 있지 않았다. 하나라도 밀리면 사용자는 전체 전송이 실패했다고 느꼈다.

PonsLink파일전송AIMDOPFSDataChannel

2026년 6월 17일·PonsLink Deep Dive·2 min

[PonsLink] 입장 버튼 뒤에는 어떤 조건들이 숨어 있을까

문제를 크게 키운 건 복잡한 신기술보다, 책임을 어디에 둘지 흐린 채로 넘어간 작은 결정들이었다. 아래에서는 PonsLink을 중심으로, 깨진 가정과 다시 그은 경계를 순서대로 남긴다. 연결 뒤에도 방의 기준은 따로 필요했다. 상태, 권한, 기능의 무게를 제품이 대신 기억해야 비로소 방처럼 느껴졌다. 다음에 남는 질문은 한 문장으로 충분하다.

PonsLinkReactZustandWebRTCFrontendRoomLifecycle

2026년 6월 17일·PonsLink 알고리즘 노트·2 min

[PonsLink] 실시간 메시지는 모두 같은 줄에 서면 안 된다

실시간 메시지를 한 줄에 세우면 안 됐다. 채팅과 제어 메시지와 파일 조각은 모두 메시지이지만, 늦어졌을 때 사용자가 느끼는 피해가 같지 않다. 처음에는 단일 큐로 충분하다고 생각했다. 도착한 순서대로 처리하면 구현이 단순하고, 순서를 설명하기도 쉬워 보였다. 혼잡 구간에서 이 가정이 깨졌다. 파일 전송이 밀리면 제어 메시지까지 늦어지고, 사용자는 방 전체가 멈춘 것으로 느꼈다.

PonsLinkDataChannelQueueBackpressureRealtime

2026년 6월 17일·PonsLink Deep Dive·2 min

[PonsLink] PonsLink 기술 회고: 33편의 아카이브를 읽는 지도

PonsLink의 기술 회고를 여러 편 쓰고 나서야 반복되는 질문이 보였다. 새 기능을 붙였는가보다, 어느 책임을 어느 계층에 둘 것인가가 매번 더 어려운 결정이었다. 방, 요청, 결제, 실시간 연결은 겉으로는 서로 다른 주제다. 하지만 실제 운영에서는 한 사용자의 흐름으로 이어진다. 한 곳의 이름을 쉽게 정하면 다른 곳의 상태와 권한 설명도 함께 흔들렸다.

PonsLinkWebRTCP2P상태머신제품아키텍처개발회고

2026년 6월 17일·PonsLink Deep Dive·2 min

[PonsLink] 처음 열린 저장소에서 제품의 경계를 읽는 법

처음 열린 저장소를 보면 제품의 경계가 한눈에 보일 거라고 생각했다. 폴더 이름을 읽고, 기능을 분류하고, 용어 사전을 만들면 PonsLink가 무엇인지 설명할 수 있을 줄 알았다. 실제로는 반대였다. 같은 기능이 화면과 API, 연결 계층과 운영 문서에 서로 다른 이름으로 남아 있었다. 무엇을 만들었는지보다 왜 그 위치에 두었는지를 따라가야 전체 제품의 모양이 보였다.

PonsLink프로젝트구조아키텍처디렉터리ReactExpress

2026년 6월 17일·PonsLink Technical Architecture·3 min

[PonsLink] WebRTC offer 충돌을 피하는 상태 머신 설계

WebRTC offer 충돌은 내부의 상태 문제였지만 사용자에게는 연결이 멈춘 화면으로 보였다. 이를 상태 머신과 명시적인 복구 규칙으로 다룬 기록이다.

PonsLinkWebRTCNegotiationICE상태머신

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] 작업 기록을 다시 보니, 내가 만든 건 회의 앱보다 연결 방식에 가까웠다

PonsLink를 만들 때 처음에는 회의방 하나면 충분하다고 생각했다. 링크를 만들고 상대를 초대하고, 같은 화면에서 대화와 파일 전송을 제공하면 된다고 봤다. 연결 자체는 빠르게 만들 수 있었지만, 사람이 방에 들어온 뒤 무엇을 믿고 어떤 상태를 따라야 하는지는 별도의 문제였다. 사람은 링크만 타고 들어오지 않는다. 초대받은 방이 어떤 상태인지, 내가 무엇을 할 수 있는지, 상대가 지금 연결돼 있는지를 함께 확인한다. 연결에 성공했다는 표시만으로는 부족했다. 상태와 권한, 기능의 무게를 제품이 기억해 줘야 방이 안정적으로…

PonsLinkProduct RetrospectiveStorylineConnection

2026년 6월 15일·PonsLink Origin Story·4 min

[PonsLink] 작업 기록을 따라가니 아직 진행형인 이유가 보였다

작업 기록을 다시 읽으며 PonsLink가 아직 진행형인 이유를 알게 됐다. 회의방 하나를 만들면 링크를 보내고 같은 화면에서 대화와 파일을 주고받을 수 있을 거라 생각했다. 연결 자체는 열렸지만 그 뒤의 순서와 상태, 실패 복구는 제품이 직접 책임져야 했다. 신호 교환과 입장 순서, 메시지 채널과 파일 채널이 조금만 어긋나도 사용자는 연결됐다고 느끼지 못했다. 내부에서는 한 단계가 늦어진 것처럼 보여도 바깥에서는 기다림과 불신으로 남았다. 문제는 특정 기술 하나보다 책임을 정하지 않은 채 다음 작업으로 넘어간 데 있었다.

PonsLink커밋로그개발심리회고개발회고

2026년 6월 15일·PonsLink Origin Story·9 min

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

처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대를 불러 말하고, 같은 화면에서 파일도 주고받으면 된다고 봤다. 실제 운영에서는 방이 열리기 훨씬 앞에서 제품이 무너졌다. 누가, 왜, 언제 만나려는지 정리되지 않은 채 DM과 문의가 흩어졌고, 정작 방에 들어가면 맥락이 비어 있었다.

PonsLinkPonsWarp브랜딩제품분화개발회고

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] 보여 줄 것만 보여 주고 덜 부담스럽게 들어오게 하기

요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다. 서로의 시간을 덜 낭비하게 만드는 완충지대였다. 요청 흐름은 PonsLink가 회의 도구보다 연결 설계에 가까워진 이유를 보여준다. 링크를 만들고 상대에게 보내는 순간부터 이미 회의가 시작된다. 누가, 왜, 언제 만나고 싶은지 모르면 좋은 방도 금방 비어 보였다.

PonsLinkrequest-firstpublic-desk제품전략개발회고

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] 파일 전송은 결국 방 밖으로 독립해야 했다

파일 전송은 결국 방 밖으로 독립해야 했다. 처음에는 방 안에 두는 게 자연스러워 보였다. 사람이 붙어 있는데 파일 하나쯤 같이 보내면 될 줄 알았다. 방 UI 안의 파일 전송은 금방 이런 질문에 부딪혔다. 지금 업로드 중인가 peer 전송 중인가, 브라우저를 닫으면 이어받을 수 있는가, 상대가 새로고침하면 진행률은 어디로 가나.

PonsLinkPonsWarpProduct RetrospectiveFile Transfer

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] 파일 전송은 부가 기능이 아니라 제품의 균형 문제였다

파일이 커질수록 전송은 방 안의 부가기능이 아니라 별도 제품이 됐다. 보내고 받고 저장하는 세 부분의 균형을 다시 잡은 기록이다.

PonsLinkNO-GO출시보류검증개발회고

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] 다시 P2P로 돌아오며 PonsLink의 중심이 선명해졌다

중계 서버에 맡기던 것들을 클라이언트와 signaling 경계로 옮기자 실패가 "방이 안 열림" 하나로만 보이기 시작했다. P2P 데모는 두 브라우저에서 예쁘게 붙는데 실제는 권한 지연, 재입장, 네트워크 전환이 섞인다. 데모 성공률만 보면 제품이 완성된 것처럼 보이지만 사용자는 매번 다른 실패를 만난다.

PonsLinkPionMeshPolar가격정책개발회고

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] 좋은 방만으로는 실제 약속이 굴러가지 않았다

그래서 PonsLink의 방은 기능 묶음이 아니라 사용자의 부담을 줄이는 약속에 가까웠다. 좋은 방을 만드는 것만으로는 실제 약속이 굴러가지 않았다. 내부에서는 한 단계가 삐끗한 것처럼 보여도, 바깥에서는 기다림과 불신으로 남는다. 그래서 단순한 구현보다 실패했을 때의 흐름을 먼저 잡아야 했다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. 처음에는 방 하나를 잘 만들면 된다고 생각했다. 그런데 사람은 링크만 타고 들어오는 게 아니라 기대와 불안도 같이 들고 들어왔다.

PonsLinkProduct RetrospectiveRequest FirstMeeting RecordsOperations

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] 멋진 분산 구조보다 먼저 감당할 수 있는 제품이 필요했다

회의 링크를 만들고 상대에게 보내기만 하면 끝날 줄 알았다. 실제로는 그보다 앞에서 시작됐다. 누가, 왜, 언제 만나고 싶은지 모르면 방은 비어 있었다. 요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다. 서로의 시간을 덜 낭비하게 만드는 완충지대였다. 요청을 받는 쪽에서 상태와 권한, 흐름을 먼저 정리해야 이후 회의가 성립했다.

PonsLink요청관리결제운영개발회고

2026년 6월 15일·PonsLink Origin Story·12 min

[PonsLink] 더 큰 방을 꿈꾸자 PonsCast가 먼저 떠올랐다

영상 회의만 붙잡고 있으면 PonsLink는 작은 방에서 멈춘다. 더 큰 방을 상상하면 모든 사람이 카메라를 켜는 구조보다 말, 듣기, 방송, 다시 재생하는 흐름이 먼저 필요해진다. 이 판단은 ponslink-room-frontend/src/components/media/PonsCastReceiverViewer.tsx와 ponslink-room-frontend/src/hooks/usePonsCastReceiver.test.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과…

PonsLink오디오룸아바타피벗개발회고

2026년 6월 15일·PonsLink Origin Story·9 min

[PonsLink] 방은 있었지만 제품을 다시 지어야 했다

겨울에 다시 지어야 했던 건 UI가 낡아서가 아니었다. 방을 열 수는 있었지만 권한, 결제, 요청, 기록, 배포가 따로 움직이면 운영 가능한 제품이라고 부르기 어려웠다. 이 판단은 ponslink-room-frontend/src/pages/RequestAction.tsx와 ponslink-room-frontend/src/pages/SessionAccess.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과 실패했을 때 돌아갈 길에 있다. 같은 단어를 쓰더라도 제품 문맥이…

PonsLinkPonsCast안정화최적화개발회고

2026년 6월 15일·PonsLink Origin Story·3 min

[PonsLink] PonsCast는 같은 시간을 공유하고 싶어서 만든 기능이었다

처음에는 회의방 하나면 충분할 줄 알았다. 링크를 만들고, 상대에게 보내고, 같은 화면 안에서 말하고 파일을 주고받으면 된다고 봤다. PonsCast는 기능표에서 나온 아이디어가 아니었다. 언어가 잘 통하지 않는 사람과 같은 파일을 같은 시간에 보고 싶다는 꽤 개인적인 욕심에서 시작됐다. PonsCast가 방의 기능 확장과 파일 전송 분리 사이의 다리였음을 이어진다. 화면 공유는 쉬운 답처럼 보였지만 내가 가진 파일을 상대의 언어와 시간에 맞춰 함께 본다는 문제는 달랐다. 같은 화면보다 같은 시간이 더 중요했다.

PonsLinkProduct RetrospectivePonsCastCoWatchTranslation

2026년 6월 15일·PonsLink Origin Story·12 min

[PonsLink] 말로 부족한 순간마다 방은 맥락을 더 품어야 했다

방은 영상 영역 하나가 아니라 대화가 흘러간 맥락을 담는 컨테이너였다. 누가 들어왔고, 무엇을 공유했고, 어떤 결정을 남겼는지가 이어지지 않으면 다음 접속은 다시 처음부터 시작된다. 이 판단은 ponslink-room-frontend/src/pages/LoungeRequests.tsx와 ponslink-room-frontend/src/pages/LoungeMeetingRecords.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과 실패했을 때 돌아갈 길에 있다.

PonsLinkProduct RetrospectiveWhiteboardTranslationMeeting Records

2026년 6월 15일·PonsLink Origin Story·10 min

[PonsLink] 말만으로 부족한 순간, 기능은 계속 늘어났다

PonsLink가 위험해진 순간은 기능이 부족할 때가 아니라 기능이 너무 쉽게 붙을 때였다. 채팅, 파일, 화이트보드, CoWatch, PonsCast는 각각 좋아 보였지만, 방의 이유를 설명하지 못하면 전부 잡음이 된다. 이 판단은 ponslink-room-frontend/src/pages/Room.tsx와 ponslink-room-frontend/src/components/functions/chat/ChatPanel.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과…

PonsLinkCoWatch파일전송기능확장개발회고

2026년 6월 15일·PonsLink Origin Story·9 min

[PonsLink] 연결은 붙었지만 신뢰는 아직 만들어지지 않았다

영상이 켜지는 순간을 성공으로 보면 PonsLink는 너무 일찍 끝난다. 실제 상담이나 협업에서는 방에 들어온 사람이 누구인지, 어떤 권한을 받았는지, 끊겼다가 돌아왔을 때 무엇을 이어받는지가 더 오래 남는다. 이 판단은 ponslink-room-frontend/src/pages/Lobby.tsx와 ponslink-room-frontend/src/pages/Room.tsx를 함께 볼 때 더 분명해진다. 화면에서 보이는 기능은 결과이고, 실제 제품성은 그 기능이 열리는 조건과 실패했을 때 돌아갈 길에 있다.

PonsLink채팅화이트보드협업개발회고

2026년 6월 15일·PonsLink Origin Story·9 min

[PonsLink] 링크는 단순했지만, 뒤에서는 신호가 계속 엉켰다

PonsLink에서 가장 오래 남은 대비는 겉과 속의 차이였다. 사용자는 링크 하나를 클릭한다. 화면은 로비를 보여주고, 장치 권한을 묻고, 입장 버튼을 보여준다. 그러나 뒤에서는 SDP offer, SDP answer, ICE candidate, signaling room, peer identity, retry timer, TURN fallback이 계속 움직인다. 링크는 단순했지만, 그 단순함을 유지하려면 신호가 엉켰을 때도 제품이 침착해야 했다. [의 세부 기록이다. WebRTC 개념 자체는 [에서 더 넓게 다뤘다. 링크가…

PonsLinkProduct RetrospectiveSignalingWebRTCTrust Boundary

2026년 6월 15일·PonsLink Origin Story·9 min

[PonsLink] 두 달 동안 방 하나에 매달리며 배운 제품의 첫 얼굴

WebRTC를 처음 제품에 넣을 때는 “브라우저끼리 직접 붙는다”는 말이 거의 마법처럼 들렸다. 서버가 미디어를 전부 중계하지 않아도 되고, 작은 팀도 실시간 방을 만들 수 있을 것 같았다. 실제로 WebRTC는 강력했다. 다만 두 달 동안 방 하나에 매달리며 배운 것은 반대편이었다. **WebRTC는 연결의 문을 열어줄 뿐, 제품의 질서는 만들어주지 않는다.**

PonsLinkWebRTC개발회고화면공유디바이스전환

2026년 6월 15일·PonsLink Origin Story·5 min

[PonsLink] 나는 먼저 방을 만들었다, 제품 설명은 그다음이었다

방을 만들면 제품 설명은 나중에 따라올 줄 알았다. 영상이 되고, 채팅이 되고, 파일을 주고받고, 화이트보드까지 붙으면 사람들이 자연스럽게 이해할 거라고 생각했다. 기능이 쌓이면 제품이 된다고 본 셈이다. 실제로는 반대였다. 누가 왜 들어오는지, 어떤 요청이 먼저 있었는지, 돈을 받는다면 무엇에 대해 받는지, 결제 후 입장 권한이 어떻게 바뀌는지가 더 중요했다. 방은 보였는데 제품 설명은 계속 비었다.

PonsLinkProduct RetrospectiveRoom PageWebRTC

2026년 6월 15일·PonsLink Origin Story·8 min

[PonsLink] 한 번 놓친 연결에서 PonsLink가 시작된 이유

PonsLink를 만들기 시작한 이유는 기술 호기심보다 불편함에 더 가까웠다. 누군가를 다시 만나야 하는 순간이 오면, 지난 대화의 맥락을 처음부터 복구해야 했다. 메시지를 찾고, 파일을 다시 보내고, 왜 만나려 했는지 다시 설명하는 일이 반복됐다. 처음에는 이 문제를 “좋은 회의 링크가 없어서”라고 짧게 정리했다. 틀렸다. 링크는 쉽게 만들 수 있었다. 진짜 문제는 연결이 끊긴 뒤에 **맥락이 같이 사라진다**는 점이었다.

PonsLink개발회고창업실패실시간통신WebRTC

2026년 6월 15일·PonsLink Origin Story·4 min

[PonsLink] 계정 없이 링크 하나로 만나는 방을 만들고 싶었다

처음 PonsLink를 붙잡았을 때 내가 원했던 장면은 거창하지 않았다. 링크 하나만 던지면 상대가 별도 계정 없이 들어와서, 필요한 이야기를 나누면 끝나는 방. 회원가입 장벽이 만남의 속도를 늦추는 걸 보고 싶지 않았다. 그런데 계정 없는 링크를 "그냥 열린 방"으로 두면 금방 무너진다. 누구나 들어올 수 있으면, 권한·보관·악용 방지가 전부 제품 책임으로 남는다. 나는 이 지점에서 링크의 개방성과 권한의 명확함을 한덤어리로 푸는 착각을 했다.

PonsLinkProduct RetrospectiveRoomLink FirstNo Login