[PonsLink] 파일 전송은 부가 기능이 아니라 제품의 균형 문제였다
파일 전송은 처음엔 방 안의 작은 부가기능처럼 보였다. 그런데 파일이 커질수록 이 기능은 방 전체를 흔드는 별도 제품이 됐다. 이 편은 PonsLink 출시 직전에 내린 No-Go 판단 — 파일 전송을 이대로 띄우지 않기로 한 결정 — 이 무엇을 보고 나온 것인지, 그리고 No-Go가 남긴 것에 대한 기록이다.
시작은 순진한 기대였다. "회의 중에 파일도 주고받을 수 있으면 편리하지 않을까" — 이 문장은 맞았다. 틀린 것은 그 편리함이 구현량과 무관하게 성립한다는 가정이었다. 파일을 주고받는 기능은 텍스트 채팅과 같은 난이도가 아니었다. 텍스트는 실패하면 다시 보내면 되지만, 파일은 실패하면 "지금까지 받은 것"이 남고 그것이 오히려 혼란을 만든다. 절반만 받은 파일은 완전한 파일이 아니라 부패한 기대다.
전송을 한 줄로 볼 수 없었다
보내는 일, 받는 일, 저장하는 일은 같은 줄에 서 있지 않았다. 하나라도 밀리면 사용자는 전체 전송이 실패했다고 느꼈다.
이 세 단계가 왜 한 줄에 서기 어려운지를 뜯어보면, 전송은 사실 세 제품의 합작이라는 게 보인다. 보내는 일은 발신 브라우저의 메모리·디스크·네트워크와 싸우고, 받는 일은 DataChannel의 흐름 제어와 싸우고, 저장하는 일은 브라우저의 저장 정책과 싸운다. 세 환경의 실패 조건이 전부 다른데, 사용자가 보는 것은 하나의 진행 바뿐이다. 진행 바는 세 실패 중 하나라도 나오면 끝난다. 발신 90% + 수신 90% + 저장 실패 = 사용자 눈에 0%.
이 곱셈 구조가 부가기능에게 잔인한 이유는, 어느 한 단계만 완성해서는 개선이 안 보인다는 것이다. 발신을 완벽하게 고쳐도 저장이 깨지면 성공률은 그대로 0에 수렴한다. 부가기능의 공수로는 세 단계를 동시에 끌어올릴 수 없으니, 개선 투자 대비 체감이 나오지 않는 함정이었다.
시선을 반대로 돌리면 감춰진 사실이 하나 더 있다. 이 세 단계 중 어느 하나라도 "알아서 잘 되는" 것은 없었다. 발신은 사용자 기기의 여건에 따라, 수신은 회선과 상대 기기에 따라, 저장은 브라우저 종류와 버전에 따라 각자 다르게 실패했다. 하나의 진행 바 뒤에서 세 종류의 불확실성이 경쟁하는 구조 — 부가기능 시절의 파일 전송은 이 경쟁의 심판 없이 굴러가고 있었다.
구체적인 실패 양상도 하나 적어둔다. 큰 파일을 방 안에서 보내면 — 이때만 해도 브라우저 저장이 파일 전체를 메모리에 들고 가야 하는 경우가 있었다 — 회의 자체가 느려지는 것처럼 느껴졌다. 발신자 입장에서는 "PonsLink가 무거워졌다", 수신자 입장에서는 "회의가 끊긴다". 실제 원인이 전송의 저장 단계에 있어도 증상은 회의 제품의 얼굴로 나타났다. 이때부터 파일 전송 문의는 전부 "PonsLink가 불안정하다"는 언어로 도착했다. 기능의 실패가 제품의 이름으로 불리는 순간, 그 기능은 이미 별도의 운영 책임을 갖게 된 것이다.
부가기능 시절의 이 기능이 특히 위험했던 이유는 위치였다. 회의방 안에 있었기 때문에, 전송이 실패하면 그 실패가 회의 제품 전체의 신뢰로 번졌다. "PonsLink에서 파일 전송이 안 된다"는 문장은 기술적으로는 부정확해도 사용자의 지갑에서는 참이었다. 얼굴이 같으면 사고도 같이 나는 것이다.
별도 제품으로 본 이유
파일 전송을 제품의 균형 문제로 다시 보았다. 보내는 쪽과 받는 쪽의 상태를 동시에 보여주고, 저장 실패도 같은 흐름으로 처리해야 전체 전송이 성공했다고 느끼게 만들었다.
"균형"이라는 단어를 쓴 이유는, 전송의 실패가 회의의 실패처럼 지각될 때 두 기능의 무게 균형이 무너지기 때문이다. 회의 제품 안에서 파일 전송은 회의의 무게보다 무거워져서는 안 된다. 파일이 커질수록 전송의 실패 확률과 체감 비용이 커지니, 균형은 자연히 깨진다. 깨진 균형을 되돌리는 방법은 둘뿐이었다 — 전송을 완성해 회의보다 가볍게 만들거나, 전송을 밖으로 꺼내 저울에서 빼거나.
"별도 제품으로 본다"는 말은 분리해서 나중에 만들자는 뜻 이전에, 품질 기준을 따로 세우자는 뜻이었다. 회의 제품의 기준 — 연결되면 성공 — 을 파일 전송에 적용하면 안 되고, 전송 제품의 기준 — 끊겨도 재개되고, 검증되고, 저장까지 완결돼야 성공 — 을 적용해야 한다. 이 기준을 방 안의 부가기능이 감당할 수 없다는 것이 No-Go 판단의 핵심이었다.
두 제품의 기준 차이를 표로 그리면 더 선명하다.
| 축 | 회의 제품 기준 | 전송 제품 기준 |
|---|---|---|
| 성공 정의 | 연결 유지 | 검증된 완전 수신 |
| 실패 대응 | 재입장 | 지점부터 재개 |
| 상태 표시 | 참석자 접속 상태 | 조각·파일 단위 진행 |
| 실패 비용 | 회의 중단 | 시간·대역폭 전체 손실 |
같은 방 안에서 두 기준을 동시에 충족하려면 UI도 두 벌이 필요하고, 상태 표시도 두 벌이 필요하다. 한 화면에서 두 벌의 진행 바와 두 벌의 실패 문장이 경쟁하면 사용자는 어느 것도 신뢰하지 못한다. 부가기능이라는 형태가 아니라, 부가기능이라는 위치가 문제였다.
선택지는 셋이었다. 하나, 부가기능인 채로 출시한다 — 작은 파일만 되더라도 출시하고 손본다. 둘, 출시를 미루고 전송을 제품급으로 다듬는다. 셋, 방에서 전송을 떼어낸다. 첫 번째의 문제는 "작은 파일만 됩니다"라는 설명이 회의 제품의 신뢰를 계속 깎는다는 것이었다. 두 번째는 회의 제품의 출시까지 함께 미룬다는 비용이었다. 세 번째는 전송이 이미 방 안에서 쓰이고 있었다는 점에서 완전한 분리가 아니라 균형의 재조정이 필요했다.
셋 선택지를 놓고 가장 오래 고민한 것은 첫 번째였다. "출시하고 보자"는 압박은 외부가 아니라 내 안에서 컸다. 만들어둔 기능을 숨기는 것은 낭비처럼 느껴진다. 그 낭비감을 뒤집어 보면 이렇다 — 완성되지 않은 기능을 출시하는 것은 낭비가 아니라 부채다. 사용자가 겪을 실패 하나하나가 갚아야 할 빚이고, 빚은 첫인상의 이자로 계산된다. 숨긴 기능은 보관 비용이 들지만, 나쁜 첫인상은 회복 비용이 든다. 두 비용의 크기를 비교하면 보류가 싸다.
결정은 No-Go — 출시 보류 — 였다. 이유는 이렇다. 출시는 제품의 첫인상이고, 첫인상에서 "전송이 깨진 회의 도구"라는 인상이 한 번 생기면 회수하는 비용이 보류 비용보다 크다. 기능이 살아 있어도 얼굴은 같이 다친다는 것을, 방 안에서 전송을 운영하며 이미 몸으로 배운 상태였다.
No-Go를 내리는 것이 쉬웠던 건 아니었다. 출시 일정도 잡혀 있었고, "출시하면 배우는 게 많다"는 정론도 참이었다. 그 정론에 대한 반박이 결정의 근거였다. 배울 것은 배우지만, 첫 사용자가 겪을 실패의 종류가 미리 보였다. 이미 운영 중에 관찰된 실패 — 저장 실패, 회의 느려짐, 진행 바 신뢰 붕괴 — 는 "출시하고 배우기"로 얻는 새로운 교훈이 아니라 이미 학습이 끝난 교훈이었다. 이미 배운 교훈을 사용자에게 유료로 반복시키는 것은 학습이 아니라 전가였다.
No-Go가 남긴 것
No-Go는 부정적 판단처럼 보이지만 실제로는 제품 구조를 정리한 결정이었다. 이 판단 뒤로 파일 전송은 방에서 점점 분리됐고 — 이후 편들과 PonsWarp의 탄생으로 이어진다 — PonsLink는 회의와 상담 운영에 집중할 수 있게 됐다. 지금 돌아보면 No-Go가 막은 것은 출시가 아니라 "두 제품이 서로의 신뢰를 깎는 구조"였다.
No-Go를 기록으로 남기는 것이 중요한 이유도 있다. 보류된 결정은 기록하지 않으면 몇 달 뒤 다시 같은 논쟁으로 돌아온다. "이제 됐나?"라는 질문에 답하려면, 그때 왜 안 됐는지의 기준이 남아 있어야 한다. 전송이 제품급 품질 — 재개·검증·저장 완결 — 에 도달했는가. 이 기준이 나중에 PonsWarp가 스스로에게 적용한 RC1 게이트의 씨앗이 됐다.
기록의 실용적 효과도 있었다. No-Go 이후 전송 관련 기능 제안이 올라올 때마다 "아직 PonsLink 안에서는 아니다"라는 답이 기준선에서 나왔다. PonsWarp라는 별도 제품으로 분리된 뒤에도 이 기준은 그대로 이전됐다 — 재개, 검증, 저장 완결이 안 되면 출시가 아니다. 하나의 No-Go 기록이 두 제품의 출시 기준을 정한 셈이다.
No-Go 판단에서 배운 것은 "출시"라는 단어의 무게를 다시 재는 일이었다. 출시는 완료 선언이지 희망 선언이어서는 안 된다. 완료의 기준이 기능 목록이 아니라 각 기능의 품질 기준이 되어야 한다는 것 — 이 관점은 나중에 전송 제품에서 게이트라는 형태로 완성된다. PonsLink의 첫 No-Go가 PonsWarp의 게이트 문화의 출발점이었다는 것이 이 편이 시리즈에서 맡은 의미다.
또 하나 남은 것은 실패를 부정하지 않는 태도다. No-Go는 "전송이 실패한다"는 사실을 인정한 결정이었다. 실패를 인정하지 않으면 보류도 불가능하다 — "괜찮을 것이다"라는 희망이 판단을 대신하기 때문이다. 출시 직전에 가장 필요한 능력은 새 기능을 만드는 힘이 아니라, 자기 제품의 현재 품질을 정직하게 측정하는 힘이었다. 이 편의 No-Go는 그 측정의 첫 기록이다.
마치며
파일이 커질수록 전송은 별도 제품이 되었고, 그 제품의 균형을 먼저 잡아야 했다. No-Go는 기능을 버린 결정이 아니라 각 제품이 자기 기준을 갖게 한 결정이었다. 회의 도구와 전송 도구가 같은 진행 바를 공유하던 시절은, 둘 다 불행했던 시절이었다.