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

PonsLink를 만들 때 처음에는 회의방 하나면 충분하다고 생각했다. 링크를 만들고 상대를 초대하고, 같은 화면에서 대화와 파일 전송을 제공하면 된다고 봤다. 연결 자체는 빠르게 만들 수 있었지만, 사람이 방에 들어온 뒤 무엇을 믿고 어떤 상태를 따라야 하는지는 별도의 문제였다.

링크 뒤에 따라오는 것들

사람은 링크만 타고 들어오지 않는다. 초대받은 방이 어떤 상태인지, 내가 무엇을 할 수 있는지, 상대가 지금 연결돼 있는지를 함께 확인한다. 연결에 성공했다는 표시만으로는 부족했다. 상태와 권한, 기능의 무게를 제품이 기억해 줘야 방이 안정적으로 느껴졌다.

이 지점에서 PonsLink의 방을 기능 묶음으로 보지 않게 됐다. 방은 사용자가 매번 다시 판단하지 않아도 되도록 약속을 보관하는 공간에 가까웠다. 연결이 끊겼을 때 무엇이 남고, 다시 들어왔을 때 어디서 이어지는지가 기능 목록보다 중요했다.

연결 성공과 경험의 차이

연결이 됐는데도 방이 불안하게 느껴지는 순간이 있었다. 권한이 보이지 않거나, 상태가 늦게 바뀌거나, 파일 전송 같은 기능이 대화의 흐름을 갑자기 무겁게 만들 때였다. 각각의 문제는 작아 보였지만 함께 쌓이면 사용자는 방 전체를 믿기 어려워진다.

그래서 제품이 대신 기억해야 할 기준을 분리해서 봤다. 누가 들어왔는지, 지금 가능한 동작이 무엇인지, 연결이 어떤 상태인지가 화면과 동작에서 일관돼야 했다. 회의 기능을 더하는 것보다 이 일관성을 먼저 세우는 편이 연결 방식이라는 제품의 본질에 가까웠다.

방을 작게 만드는 방법

방의 기능을 계속 늘리면 사용자가 얻는 것이 많아질 것 같지만, 실제로는 판단할 항목도 함께 늘어난다. PonsLink에서는 대화와 파일, 상태와 권한이 서로의 흐름을 방해하지 않는지부터 확인해야 했다. 필요한 기능을 넣되, 사용자가 그 기능의 존재를 매번 해석하게 만들지 않는 것이 기준이었다.

이 관점은 방 밖의 운영이나 파일 전송을 별도 흐름으로 나누는 결정에도 이어졌다. 모든 것을 한 화면에 넣는 것이 통합은 아니었다. 같은 맥락을 유지하면서도 각 기능이 자기 책임을 분명히 하는 편이 더 단단했다.

마치며

PonsLink에서 만든 것은 회의 화면보다 연결의 약속에 가까웠다. 링크를 열고 들어오는 순간부터 상태와 권한, 기능의 무게를 일관되게 전달해야 사람이 방을 믿을 수 있다. 연결 성공은 시작이고, 그 뒤의 맥락을 보존하는 일이 제품의 본체였다.