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

회의 링크를 만들고 상대에게 보내기만 하면 끝날 줄 알았다. 실제로는 그보다 앞에서 시작됐다. 누가, 왜, 언제 만나고 싶은지 모르면 방은 비어 있었다. 그리고 방이 비어 있는 날마다, 제품 밖에서 벌어진 일 — 카톡으로 오간 용건, 메일로 확인한 일정, 폼으로 접수된 문의 — 이 회의의 실체였다. 제품은 그 모든 것의 바깥에 있었다.

이야기의 앞 편들에서 방은 계속 좋아지고 있었다. 화면 공유에서 PonsCast로, 협업 화이트보드에서 오디오 룸으로 — 방 안의 문제들은 하나씩 답을 찾았다. 그런데 정작 제품을 하루에 한 번 이상 쓰는 사람은 나뿐이었다. 방이 좋아질수록 이상한 기분이 들었다. 무대는 완성돼 가는데 공연이 시작되지 않는다. 초대받은 사람들이 무대로 오는 통로가 없었기 때문이다.

이 시점의 PonsLink는 기술적으로 자신만만했다. 오디오 룸과 아바타로 방향을 잡았고(앞 편), 방은 안정화 단계에 접어 있었다. 문제는 기술이 아니라 제품의 나이였다. 기술은 청년이고 제품 운영은 갓 시작한 아이였다. 요청은 어디서 받고, 결제는 어떻게 받고, 예약은 누가 관리하는가 — 이 질문들에 대한 답이 전부 제품 밖에 있었다.

제품 밖의 운영이 어떤 모양인지 문장으로 옮기면 이렇다. 상담 요청이 카톡으로 온다. 용건을 물어본다. 답이 오면 일정을 조율한다. 조율이 끝나면 방 링크를 만들어 보낸다. 결제 이야기가 있으면 계좌를 알려주고 입금을 기다린다. 확인되면 방을 다시 안내한다. 회의가 끝나면 후속 문의가 어느 채널로든 온다. 이 일곱 단계에서 제품이 맡은 것은 다섯 번째뿐이었다. 제품이 있는데 운영은 메신저 위에서 돌아가는, 이 롤이 처음 보는 운영자에게는 이해가 안 되는 구조였고, 나에게는 매일 반복되는 현실이었다.

요청이 방보다 먼저인 이유

요청을 먼저 받는 일은 사람을 거르는 장치가 아니었다. 서로의 시간을 덜 낭비하게 만드는 완충지대였다. 요청을 받는 쪽에서 상태와 권한, 흐름을 먼저 정리해야 이후 회의가 성립했다.

이 생각이 굳어진 계기는 운영의 반복 작업이었다. 상담 요청이 오면 먼저 해야 할 일은 연결이 아니라 이해였다. 누구와, 무슨 용건으로, 어느 정도의 시간을 쓸 회의인지. 이 세 가지가 정리되지 않은 요청을 방으로 보내면, 방 안에서 같은 질문을 다시 하게 된다. 방 안에서 용건을 확인하는 시간은 회의 시간이 아니라 준비 시간의 연장이고, 그 준비는 제품 밖의 메신저에서 더 어색하게 이뤄졌다.

완충지대라는 비유가 정확한 이유는, 요청 단계가 양쪽의 기대를 맞춰주기 때문이다. 요청하는 사람은 "내 문제가 전달됐다"는 확인을 받고, 받는 사람은 "이 요청을 받을지 말지 판단할 정보가 있다"는 여유를 얻는다. 링크가 곧바로 오는 세상에서는 이 둘 다 없다. 상대는 예고 없이 연결되고, 나는 맥락 없이 응답한다. 완충이 없는 회의는 시작부터 피로하다.

결제가 흐름에 없던 것도 같은 부류의 문제였다. 유료 상담을 상정하는 제품에서 결제는 "회의가 끝난 뒤 정산"이 아니라 "요청이 받아들여질 때의 약속"이었다. 약속의 시점이 제품 밖에 있으면 상태가 흩어진다 — 결제했는지, 결제했는데 일정이 바뀌면 어쩌는지, 취소는 누가 확인하는지. 이 모든 질문이 메신저 대화로 흘러가면, 운영자는 대화 기록이라는 검색 불가능한 장부로 회사를 운영하게 된다.

여기서 깨달은 것은 순서의 문제였다. 분산 구조, 상태 동기, 메시 — 이런 "멋진" 주제들은 방 안의 이야기다. 그런데 방 안에 들어올 사람이 누군지도 모르는 상태에서 방 안의 이야기를 다듬는 것은, 초대장 주소가 없는 파티 음식을 준비하는 일이었다. 먼저 지어야 하는 것은 요청의 구조였다.

순서를 바꾸는 결정은 기존 작업을 버리는 것처럼 느껴진다. 방 안의 기능들은 버리는 게 아니었다 — 방은 여전히 제품의 심장이었다. 바꾼 것은 작업의 방향이었다. 지금까지는 심장부터 만들고 혈관을 나중에 붙이려 했다면, 이제는 혈관(요청·결제·운영)이 심장 앞에 와야 한다는 판단이었다. 혈관이 없는 심장은 튼튼해도 아무것도 살리지 못한다.

운영 상태를 제품에 넣다

한 번 실패한 뒤에야 경계를 다시 잡았다. 링크 하나로 시작하되 내부에서는 상태와 권한을 더 꼼꼼히 잡는 방식으로 돌아왔다.

구체적으로 바꾼 것은 세 겹이다. 첫째, 요청에 상태를 주었다. 접수됨 → 검토 → 수락/보류/거절 — 요청이 문장에서 상태를 가진 객체가 되면, 운영자는 기억이 아니라 화면으로 일할 수 있다. 상태 전이가 명시적이면 보류 사유도 기록되고, 거절도 문장이 아니라 절차가 된다.

상태를 도입하면서 얻은 부수적 이득이 하나 더 있었다. 상태가 있으면 시간이 있다. 요청이 언제 접수됐고 언제 검토로 넘어갔는지가 남으면, 운영의 리듬 — 하루 중 요청이 몰리는 시간, 검토가 밀리는 요일 — 이 데이터가 된다. 제품 밖의 메신저로 운영할 때는 이런 것이 전부 증발한다. 대화 기록 속 어딘가에 있지만, 아무도 다시 읽지 않는다.

둘째, 결제와 권한을 흐름 안으로 들였다. 유료 상담이라면 결제가 흐름의 어느 지점에서 어떤 권한을 여는지가 제품 안에서 답해야 했고, 제품 밖의 계좌 이체 확인이 회의의 전제가 되어서는 안 됐다. 권한이 결제에 묶이면 자연스럽게 다음 질문이 따라온다 — 결제 전엔 무엇을 볼 수 있나, 세션 입장은 누가 허용하나. 이 질문들이 나중의 세션 접근 설계로 이어진다.

셋째, 운영 화면을 만들었다. 요청 목록, 상태 변경, 다음 일정 — host가 머릿속에 들고 있던 운영 상태를 제품이 대신 들게 하는 것. 개인 제품의 운영 화면은 화려할 필요가 없다. 필요한 것은 "지금 내가 뭘 결정해야 하나"가 한 화면에 보이는 것이다.

세 겹을 다 도입한 뒤 운영이 바뀐 정도는 극적이지 않았다. 다만 달라진 감각이 하나 있었다. 제품 밖에서 운영할 때는 하루를 마치며 "뭘 놓쳤나"를 검토해야 했는데, 상태가 제품 안에 있으면 놓친 것이 화면에 남는다. 검토가 기억의 문제에서 화면의 문제로 바뀐 것 — 개인 운영자에게 이 전환은 기능 목록 몇 개보다 큰 변화였다.

요청·결제·운영을 제품 안으로 들이면서 알게 된 사실 하나 더. 운영이 제품 밖에 있으면 제품의 다른 결정들도 왜곡된다. 예컨대 방의 기능 우선순위를 정할 때 "운영에서 어떻게 쓰일까"를 알 수 없으니 감으로 정했다. 요청 흐름이 제품 안에 들어오니 방의 어떤 기능이 실제 회의에서 쓰이는지 흐름 위에서 보이기 시작했다. 운영 데이터는 제품 개선의 연료인데, 운영이 제품 밖에 있으면 연료 공급 자체가 끊긴다.## 멋진 구조와 감당 가능한 제품 사이

이 시기의 판단을 한 문장으로 정리하면 이렇다. 분산 구조는 자랑스러웠지만, 운영은 구조를 자랑하기 전에 감당돼야 했다. 실시간 제품의 회고담은 대개 확장성 이야기로 가득한데, 1인 운영자의 제품에서 먼저 터지는 병목은 확장성이 아니라 운영 손이었다. 요청마다 사람이 손으로 정리하는 부분이 하나라도 남으면, 사용자가 늘 때마다 그 손이 먼저 마모된다.

"감당할 수 있는"이라는 수식을 붙인 이유도 이것이다. 제품의 기능이 아무리 좋아도 운영자가 감당하지 못하면 그 제품은 존재할 수 없다. 감당 가능성은 기능 추가의 필터가 된다. 이 기능을 넣으면 운영 손이 하나 늘어나는가 — 답이 예이면 기능 자체의 매력과 무관하게 보류한다. 방의 기능은 많았지만 요청의 흐름이 없던 시절, PonsLink는 매력적인 기능을 운영 불가능한 포장에 담아둔 상태였다.

같은 기준으로 뒤집어 보면, 운영을 제품 안으로 들이는 일은 기능 추가가 아니라 기능의 조건 정비였다. 이미 있던 방과 연결이 제대로 쓰일 길을 만드는 작업. 새로운 것을 더하는 것보다 이미 있는 것이 제대로 닿게 하는 일이 개인 제품 초기에 더 시급하다는 판단 — 이것이 07편의 결론이자, 이후 요청 선별 흐름 전체의 출발점이다.

기준은 이렇게 바뀌었다. 기능을 더하는 것보다 다음 상태를 설명할 수 있게 만드는 것. 요청이 지금 어느 단계인지, 다음에 누구의 행동이 필요한지 — 이 문장이 화면에 없으면 운영은 계속 사람의 기억에 의존한다. 요청을 먼저 받는 쪽에서 상태와 권한을 정리하는 것이 회의보다 먼저였다.

이 시기의 결정이 뒤의 제품 구조를 크게 바꿨다. 요청이 상태를 가지자, 요청과 방이 분리됐다. 방은 실시간 연결의 공간이고 요청은 운영의 흐름인데, 둘을 같은 화면에 얹으면 요청의 상태 변화가 방의 연결 상태 표시와 섞여서 서로의 신뢰를 깎는다. 요청을 독립된 흐름으로 두자 방은 단순해졌고, 요청 화면은 운영 화면이 됐다. 나중에 공개 요청 링크와 세션 입장 토큰으로 이어질 길도 여기서 열렸다 — 요청이 상태를 가진 순간부터, 그 상태의 문을 여는 권한이라는 개념이 필요해졌기 때문이다.

돌아보면 이 시기에 배운 것은 우선순위의 종류를 구분하는 일이었다. 기술 부채는 나중에 갚아도 서비스가 돌아가지만, 운영 부채는 사용자가 매번 이자를 치른다. 제품 밖에서 흩어지던 요청을 제품 안으로 들이는 것은 화려한 기능이 아니었지만, 그것이 PonsLink가 "회의 도구"에서 "상담 운영 도구"로 성격을 찾아가는 첫걸음이었다. 멋진 분산 구조보다 먼저, 감당할 수 있는 제품이 필요했다.

이 시리즈에서 이 편의 위치를 돌아보면, 앞선 편들이 방의 성능과 형태를 다뤘다면 이 편부터 시선이 방 바깥으로 나온다. 다음 편(08)에서는 다시 기술로 돌아가지만 방향이 다르다 — 서버 중심에서 P2P로의 피벗인데, 그 피벗조차 이제는 "멋진 구조"가 아니라 "감당 가능한 제품"이라는 같은 기준 위에서 판단된다. 기준이 바뀌면 같은 기술 결정도 다른 이유로 내려진다. 이것이 이 시리즈에서 07편이 놓인 자리의 의미다.