요금제 다운그레이드 UX: 적용 시점, 한도, 기존 작업

하위 요금제로 바꾸면 사용자가 이미 의존하고 있는 작업에서 할 수 있는 일이 달라집니다. 낮아지는 가격과 빠지는 기능 목록만으로는 충분하지 않습니다. 확정하기 전에 언제 변경되는지, 기존 프로젝트 같은 항목은 어떻게 되는지, 어떤 동작을 더 이상 할 수 없는지, 계정 관리자가 무엇을 되돌릴 수 있는지 설명해야 합니다.

확인 화면을 닫은 뒤에도 이 정보를 볼 수 있어야 합니다. 내일 워크스페이스에 돌아온 사람이 예전 이메일을 다시 읽거나 실패할 동작을 직접 눌러 보지 않고도, 다운그레이드가 예약된 상태인지 이미 하위 요금제가 적용된 상태인지 구분할 수 있게 하세요.

화면을 디자인하기 전에 다운그레이드의 적용 규칙을 정하세요

GitHub의 요금제 다운그레이드 안내(영문)는 개인·조직 계정 사용자에게 다음 청구일에 사용할 수 없게 되는 기능을 검토하도록 안내합니다. Pro에서 Free로 전환할 때 비공개 저장소의 고급 코드 검토 도구를 잃는 등 구체적인 결과도 설명합니다. 여기서 참고할 점은 구체성입니다. 새 요금제 이름만 보여 주지 말고 영향을 받는 작업을 설명하세요. GitHub의 데이터·기능 처리 정책을 다른 제품의 규칙으로 그대로 가져와서는 안 됩니다.

아래에서는 가상의 프로젝트 관리 앱에 있는 Harbor 워크스페이스를 예로 듭니다. 결제 관리자 다나는 2026년 10월 20일 Studio에서 Core로의 전환을 예약합니다. 변경은 다음 청구 기간이 시작되는 2026년 11월 1일 00:00(UTC)에 적용됩니다. 요금제 이름, 날짜, 한도, 정책은 모두 이 설명용 사례에만 해당합니다.

Harbor에는 웹사이트, 모바일 앱, 고객 포털, 고객 지원 센터, 브랜드 라이브러리라는 활성 프로젝트 다섯 개가 있습니다. Core는 프로젝트 생성·복제·복원 시 활성 프로젝트 수가 세 개를 넘지 않도록 제한합니다. 이미 한도를 초과해 존재하는 프로젝트는 기존 권한에 따라 계속 읽고 편집할 수 있습니다. 다운그레이드 자체가 프로젝트를 삭제하거나 보관 처리하지는 않습니다. 보관한 프로젝트는 활성 개수에 포함되지 않으며, 하나를 복원하면 활성 개수가 늘어납니다.

결제 관리 권한과 프로젝트 권한을 구분하세요

이 사례에서 결제 관리자는 요금제 변경을 예약하거나 아직 적용되지 않은 예약을 취소할 수 있습니다. 이 역할만으로 프로젝트 내용을 보거나 보관할 권한까지 생기는 것은 아닙니다. 나머지 역할도 다음과 같이 분명히 정의하세요.

다나에게 전체 사용량을 보여 주되 접근이 제한된 프로젝트 이름은 노출하지 마세요. 프로젝트 목록에는 다나가 볼 수 있는 제목만 포함할 수 있습니다. 요금제 한도에 부딪힌 편집자에게 필요한 것은 설명과 권한 있는 담당자에게 연락할 경로이지, 활성화된 결제 버튼이 아닙니다. 하위 요금제의 제한과 권한 부족은 동작을 할 수 없는 서로 다른 이유입니다.

확정하는 시점과 실제 적용 시점을 구분하세요

Stripe의 고객 포털 설정(영문)에서는 기간 종료 시 다운그레이드를 선택 사항으로 제공하며, 해당 설정의 기본값은 즉시 변경입니다. 기간 종료 시 적용 옵션은 같은 제품에 속한 가격 간 전환에 적용됩니다. 이는 적용 시점이 설정에 따라 달라진다는 근거이지, 모든 구독의 다운그레이드가 갱신일까지 기다린다는 규칙은 아닙니다.

Harbor의 확인 화면에는 “11월 1일 Core 전환 예약”이라고 쓰고 정확한 시간과 시간대를 덧붙여야 합니다. 그때까지 Studio가 유지된다는 점도 설명하세요. 나중에 적용될 변경에 “지금 다운그레이드”라고 쓰거나, 예약 직후 Core를 현재 요금제로 표시하지 마세요.

나중에도 참고할 요약에는 구체적인 날짜를 쓰세요. “12일 후”는 이메일이나 스크린샷에서 시간이 지나면 맞지 않는 표현이 됩니다. 사용자의 현지 시간도 보여 준다면 어떤 시간인지 표시하고, 결제 상세·확인 화면·알림에 같은 적용 시점이 반영되도록 하세요. 브라우저의 시계가 자정을 가리킨다고 해서 서버가 새 요금제를 적용했다는 뜻은 아닙니다.

기존 작업과 새 작업에 미치는 영향을 따로 설명하세요

“프로젝트가 한도를 두 개 초과했습니다”는 개수만 알려 줄 뿐, 그 결과는 설명하지 않습니다. Harbor의 영향 요약에서는 읽기, 편집, 보관, 생성, 복원을 구분해야 합니다. 이 사례는 기존 작업을 계속 허용하는 정책을 의도적으로 정한 것이며, 다른 제품에는 다른 규칙이 필요할 수 있습니다.

계산도 명확히 보여 주세요. Harbor의 프로젝트 다섯 개 중 두 개를 보관하면 활성 프로젝트가 세 개 남습니다. 한도에 도달한 상태이므로 여전히 새 프로젝트를 만들 수 없습니다. 세 번째 프로젝트까지 보관해야 두 개가 남고, 그때 생성 권한이 있는 사용자가 하나를 추가할 수 있습니다. 현재 초과분이 두 개라고 해서 “두 개를 보관하면 프로젝트를 만들 수 있습니다”라고 안내하지 마세요.

정리 제안을 다운그레이드를 완료하기 위한 필수 조건으로 바꾸지 마세요. 이 사례의 정책에서는 다나가 프로젝트 다섯 개를 모두 활성 상태로 둔 채 Core를 예약할 수 있습니다. 뷰어나 결제 관리자라는 이유만으로 프로젝트 생성 권한이 생기지도 않습니다. 요금제 한도는 추가로 확인할 조건이지, 역할별 권한 확인을 대신하는 조건이 아닙니다.

포괄적인 경고 대신 실제로 결정할 내용을 확인하세요

최종 확인 화면에는 Harbor, Studio → Core, 적용 시점, 현재 사용량, 구체적으로 제한될 동작을 함께 보여 주세요. 확인 버튼 옆에는 “기존 프로젝트 다섯 개는 모두 현재 권한을 유지합니다. 새 프로젝트 생성과 복원은 활성 프로젝트가 세 개 미만일 때 가능합니다.”처럼 결과를 설명합니다. 검토하던 맥락을 잃지 않고 이전 화면으로 돌아갈 수 있는 일반적인 경로도 제공하세요.

다나가 확정할 때 현재 요금제, 사용량, 권한, 예약된 변경을 다시 확인하세요. 다른 관리자가 요금제를 바꾸거나 별도의 변경을 예약했을 수 있습니다. 중요한 결과가 미리보기와 달라졌다면 차이를 설명하고 다시 결정하도록 해야 합니다. 다른 사람의 예약을 알리지 않고 덮어쓰지 마세요.

요청이 처리되는 동안에는 중복 제출을 막되 성공한 것처럼 표시하지 마세요. 결과가 불확실하다면 다시 시도하도록 안내하기 전에 워크스페이스의 실제 예약 상태를 조회해야 합니다. 성공 메시지는 다나가 버튼을 눌렀다는 사실이 아니라 예약이 기록되었음을 확인해야 합니다.

예약된 변경을 계속 보여 주고, 지원하는 범위에서 취소할 수 있게 하세요

예약 후 결제 페이지에는 “현재 요금제: Studio”와 “예약: 2026년 11월 1일 00:00(UTC)부터 Core”를 함께 표시해야 합니다. 관련 프로젝트에 미치는 영향을 다시 설명하고 재방문 시에도 같은 영향 요약을 제공하세요. 잠깐 나타나는 토스트만으로 워크스페이스에 앞으로 적용될 제한을 기록했다고 볼 수는 없습니다.

Harbor에서는 결제 관리자가 적용 시점 전에 다운그레이드 예약을 취소할 수 있습니다. 버튼은 “구독 취소”가 아니라 “다운그레이드 예약 취소”라고 표시하세요. 성공하면 Studio가 계속 유지되고 남아 있는 다운그레이드 예약이 없음을 알려 줍니다. 취소 요청과 적용 시점이 겹치면 서버 결과를 확인해야 합니다. 이미 Core가 적용된 뒤에도 취소할 수 있다고 약속하지 마세요.

11월이 되기 전에 사용량이 달라질 수도 있습니다. Harbor의 활성 프로젝트가 여섯 개로 늘면 요약도 여섯 개로 갱신해야 합니다. 다섯 개를 현재 개수인 것처럼 계속 보여 주지 마세요. 기존 작업에 대한 정책은 여전히 같지만 새 프로젝트를 추가할 자리를 확보하는 데 필요한 작업은 달라집니다. 영향을 받는 프로젝트 관리자에게 알리되, 권한 없는 수신자에게 청구 금액이나 제한된 프로젝트의 상세 정보를 노출하지 마세요.

제한에 부딪히는 위치에서 그 이유를 설명하세요

Core가 적용되었다는 확인을 받으면 현재 요금제로 표시하세요. 새 프로젝트 생성 동작 옆에는 “활성 프로젝트 5개. Core에서는 활성 프로젝트가 3개 미만일 때 새로 만들 수 있습니다. 기존 편집자는 계속 작업할 수 있습니다.”처럼 안내할 수 있습니다. 기존 프로젝트는 계속 보여 주세요. 워크스페이스를 업그레이드 요구 화면으로 가려 버리면 Harbor가 설명한 정책과 모순됩니다.

현재 사용자가 할 수 있는 동작만 제공하세요. 프로젝트 관리자는 자신이 보관할 수 있는 프로젝트를 검토하고, 편집자는 적절한 관리자에게 연락할 수 있습니다. 생성 권한이 있어도 다른 사람이 마지막 자리를 먼저 사용했다면, 서버가 생성을 거부한 뒤 입력한 프로젝트 이름을 보존하면서 바뀐 개수를 설명하세요. 아직 생성 중인 프로젝트가 이미 존재하는 것처럼 표현하지 마세요.

결제 변경과 기능 접근 상태가 아직 조정 중이라면 그 상태를 정확히 설명하세요. 예약 시간이 지났다는 이유만으로 “Core 사용 중”이라고 표시해서는 안 되며, 백엔드가 변경을 확인한 뒤에도 Studio 배지를 무기한 남겨 두어서도 안 됩니다. 어떤 상태를 최종 기준으로 삼고 어떻게 복구할지 개발팀과 합의하세요.

기능을 다시 쓰는 것과 청구 내역을 바꾸는 것을 구분하세요

이 사례에서는 다운그레이드를 예약해도 즉시 청구가 발생하지 않으며 현재 기간에 대한 크레딧도 생기지 않습니다. Core의 정기 요금은 새 기간부터 적용됩니다. 다운그레이드한다고 기존 미납 청구서나 별도 청구 항목이 없어지는 것은 아닙니다. 실제 적용될 청구 미리보기를 조회하세요. 세금이나 다른 항목이 영향을 줄 수 있다면 홍보용 가격표만으로 총액을 계산해 약속하지 마세요.

적용 시점 전에는 예약 취소로 Studio를 유지할 수 있습니다. 적용 후 Studio로 돌아가는 것은 별도의 요금제 변경이며, 그에 따른 가격, 적용 시점, 필요한 결제 확인 절차가 있습니다. 확정 전에 이 조건을 보여 주고, 서비스가 새 요금제의 이용 권한을 확인한 뒤에만 기능을 다시 활성화하세요. 청구서 이력까지 되돌릴 수 없다면 이 동작에 “실행 취소”라는 이름을 붙이지 마세요.

환불, 크레딧, 데이터 보관, 접근 복구는 각각 별도로 정해야 할 정책입니다. 크레딧을 제공하는 제품이라면 무엇에 적용되고 언제 반영되는지 알려 주어야 합니다. 복구를 보장할 수 없는 제품은 “업그레이드하면 모두 되찾을 수 있습니다”라는 말로 한계를 가려서는 안 됩니다. 결제 서비스 제공업체의 설정만으로 워크스페이스의 데이터 보관 정책이 정해지지는 않습니다.

Pixso에서 Harbor의 요금제 변경 결정을 디자인하세요

Pixso 파일에서 이 가상 앱의 화면 세 개를 연결해 만드세요. Harbor의 영향 미리보기, 예약된 변경 요약, 그리고 새 프로젝트를 생성할 수 없는 Core 적용 후 워크스페이스입니다. 프로젝트 개수, 날짜, 역할, 정책 문구를 일관되게 유지하세요. 이는 캔버스에서 디자인하는 구독 화면이며 Pixso 자체 결제 컨트롤이 아닙니다.

동료에게 다나 역할로 변경을 예약한 뒤 결제 화면에 다시 들어가 보도록 요청하세요. 현재 요금제를 알아보고, 11월 1일에 무엇이 바뀌는지 설명하며, 아직 적용되지 않은 다운그레이드만 취소할 수 있을까요? 두 번째에는 적용 이후의 프로젝트 관리자 역할로 확인하세요. 프로젝트 두 개를 보관하면 새 프로젝트를 만들 수 있는지 물어보세요. 그 판단 과정을 들으면 인터페이스가 실제 한도를 제대로 설명하는지 알 수 있습니다.

Pixso에서 명확한 요금제 다운그레이드 흐름을 디자인해 보세요 →

마지막으로 사용량 변경, 결제 관리자 권한 취소, 서로 충돌하는 예약, 결과가 불확실한 응답, 적용 시점과 맞물린 취소를 테스트하세요. 목표는 요금제 변경 요청이 성공하는 것만이 아닙니다. 어떤 작업을 계속 할 수 있는지, 특정 동작이 왜 제한되는지, 자신에게 실제로 허용된 복구 경로가 무엇인지 사용자가 이해할 수 있어야 합니다.