Writing

시리즈: ponslink-deep-dive에 해당하는 글입니다.

주제

프로젝트

글 유형

7개의 글

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

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

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

PonsLink디자인패턴테스트RepositoryFacadePolicyWorker

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

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

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

PonsLink결제PolarIdempotencyWebhookSessionAccess

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

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

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

PonsLinkPublicDesk상태머신예약SessionAccessProductArchitecture

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

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

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

PonsLinkZustand상태관리디자인패턴ReactRealtime

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

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

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

PonsLinkReactZustandWebRTCFrontendRoomLifecycle

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