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

플랜 집행을 버튼 비활성화로만 처리하면 화면은 조용해 보인다. 사용자는 오히려 왜 안 되는지 알 수 없어서 제품을 버그처럼 느낀다. 한도에 도달했는지, 결제가 필요한지, 현재 권한으로는 할 수 없는지에 따라 다음 행동도 달라져야 했다.

막는 이유를 같이 보여 주기

플랜 경계는 백엔드의 판정만으로 끝나지 않는다. UI에는 상태와 이유, 사용자가 선택할 수 있는 다음 행동이 함께 있어야 한다. 같은 비활성 버튼이라도 한도 소진과 권한 부족은 서로 다른 문제다. 둘을 같은 문장으로 처리하면 사용자는 무엇을 고쳐야 하는지 알 수 없다.

경계는 기술 선택에도 남는다

PonsLink의 다른 실험에서 Rust와 WASM을 검토한 이유도 비슷했다. 브라우저에서 큰 파일을 다룰 때 복사와 메모리 경계가 계속 문제였고, 네이티브의 규율을 빌리고 싶었다. 그렇다고 웹 제품이라는 제약을 없앨 수는 없었다. 플랜 집행 역시 욕심과 생존선 사이에서 책임을 명확히 하는 일이다.

빠른 코드보다 중요한 것은 사용자가 실패를 덜 만나게 하는 구조다. 사용자가 경계를 이해할 수 있으면 제한은 숨은 함정이 아니라 예측 가능한 제품 규칙이 된다.

마치며

플랜 집행은 버튼을 잠그는 기능이 아니라 약속한 범위를 설명 가능하게 지키는 일이다. 막아야 할 때 이유를 함께 말하는 것이 결제 유도보다 먼저다.