이해하기 쉬운 요금표를 디자인하는 방법

좋은 요금표는 사용자가 계산기를 켜거나 브라우저에 새 탭을 열지 않고도 세 가지 질문에 답할 수 있게 합니다. 내 업무에 맞는 플랜은 무엇일까요? 실제로 얼마를 내야 할까요? 이 플랜을 선택하면 다음에는 무엇을 하게 될까요?

실제 제품 정보를 레이아웃에 넣기 전까지는 간단한 일처럼 들립니다. 하지만 어떤 플랜은 편집자 다섯 명을 기본으로 제공하고, 다른 플랜은 편집자 수에 따라 과금합니다. 연간 결제액을 월 환산액으로 표시하기도 하고, 가장 중요한 기능이 똑같이 생긴 체크 표시 열두 개 아래 묻히기도 합니다. 카드가 세련되어 보여도 사용자가 결정을 내리기는 여전히 어려울 수 있습니다.

이 글의 계산과 구성 예시에는 가상의 협업 서비스인 Fieldnote를 사용합니다.

카드를 그리기 전에 사용자가 내려야 할 결정을 정의하세요

방문자가 어떤 결정을 내리기를 기대하는지 한 문장으로 적어 보세요. Fieldnote라면 ‘개인 연구자, 소규모 프로젝트 팀, 중앙 집중식 관리가 필요한 조직 중 자신의 상황에 맞는 워크스페이스 플랜을 선택한다’가 됩니다.

이 세 집단은 운영에 필요한 조건이 서로 다릅니다. 모든 요금 페이지에는 세 개의 열이 있어야 한다고 정하는 것보다 이런 필요에서 출발하는 편이 유용합니다. 유료 패키지가 하나뿐인 제품에는 비교표보다 가격 설명이 필요할 수 있습니다. 여러 제품을 따로 판매하는 서비스라면 먼저 제품을 선택하는 단계가 필요할 수도 있습니다. 본질적으로 다른 구매 대상을 나란한 열에 배치하면 실제로는 대체할 수 없는 선택지들이 서로 대체 가능한 것처럼 보일 수 있습니다.

실제로 선택을 바꾸는 정보가 무엇인지 제품 책임자에게 물어보세요. 이 예시에서는 활성 프로젝트 수, 기본 제공 편집자 수, 게스트 접근, 관리 기능이 중요합니다. 저장 공간도 플랜마다 다르지만, 이 서비스가 대상으로 삼는 독자가 처음 플랜을 고를 때 결정적인 기준이 될 가능성은 낮습니다. 이런 구분을 하면 페이지의 순서가 정해집니다. 먼저 자신에게 맞는지 판단하게 하고, 그다음 그 판단을 확인할 세부 정보를 보여 주는 것입니다.

디자인과 별도로 간단한 기준 정보표를 관리하세요. 각 플랜의 이름, 대상 사용자, 과금 단위, 기본 제공 수량, 이용 한도, 업그레이드 조건, 구매 경로를 기록합니다. 원자료에서 아직 결정되지 않았다고 한 항목은 미정으로 표시하세요. 보기 좋은 목업을 만들다가 빠져 있던 판매 정책까지 우연히 결정해 버려서는 안 됩니다.

기준 정보표는 수정 과정에서 내용이 서로 어긋나는 일도 막아 줍니다. 팀에서 기본 제공 편집자 수를 바꾸면 플랜 요약, 비교표의 해당 행, 계산기, FAQ를 모두 수정해야 할 수 있습니다. 이들을 우연히 같은 숫자를 담고 있는 별개의 문구로 보지 말고, 하나의 사실을 서로 다른 방식으로 보여 주는 표현으로 다루세요.

요금표 디자인: 먼저 후보를 좁히고, 그다음 비교하세요

플랜 카드와 기능 비교표의 역할은 다릅니다. 카드는 방문자가 고려할 후보를 추리는 데 도움이 됩니다. 비교표는 추린 후보가 구체적인 요구 조건을 충족하는지 확인하게 합니다. 모든 세부 정보를 카드에 담으려 하면 열이 길어지고, 플랜 간 차이를 찾기도 어려워집니다.

Figma의 요금 페이지 가이드는 간결한 플랜 소개와 더 자세한 비교표를 구분하고, 가격 가까이에 과금 단위를 명확히 표시하라고 권합니다. 이 글에서 제안하는 구성을 세울 때 유용한 기준입니다. Figma 요금 페이지 가이드.

Fieldnote의 Solo 카드는 혼자 진행하는 프로젝트를 위한 플랜임을 설명한 뒤 가격, 활성 프로젝트 한도, 게스트 접근 여부를 보여 줄 수 있습니다. Team 카드는 공동 연구를 위한 플랜임을 설명하고 가격, 기본 제공 편집자 수, 공동 프로젝트 용량을 보여 줄 수 있습니다. Organization 카드는 중앙 집중식 관리와 영업 상담을 거치는 구매 경로를 설명하면 됩니다. 견적을 받아야 하는 판매 모델이라면 마지막 카드에 공개 가격을 임의로 만들어 넣을 필요는 없습니다.

값이 서로 달라도 정보를 보여 주는 순서는 일관되게 유지하세요. 한 카드는 결제 조건을 버튼 아래에, 다른 카드는 가격 옆에 두면 독자는 정보 사이의 관계를 직접 찾아야 합니다. 정렬 자체가 설명의 역할을 합니다. 같은 위치에 놓인 정보는 같은 종류의 정보라는 뜻이 됩니다.

GitHub 요금 페이지를 두 단계로 살펴보세요

GitHub 요금 페이지는 플랜 요약과 상세 비교의 차이를 보여 주는 유용한 실제 사례입니다. 위쪽 플랜 영역은 선택할 수 있는 옵션과 구매 경로를 제시하고, 아래쪽 기능 비교표는 더 자세한 정보를 제공합니다. 캡처된 가격은 페이지 구성을 설명하기 위한 예시이므로 현재 판매 조건은 실제 페이지에서 확인하세요.

두 영역을 서로 다른 질문으로 살펴보세요. 요약에서는 우리 팀이 고려할 만한 옵션을 찾을 수 있나요? 비교표에서는 그 옵션을 후보에서 제외하게 할 결정적인 조건 하나를 확인할 수 있나요? 플랜을 처음 소개하는 카드와 구매 요건을 확인하는 표에는 서로 다른 정보 밀도가 필요하므로 이런 구분이 유용합니다. 비교표의 모든 행을 담은 카드는 더 이상 요약이라고 할 수 없습니다.

구매를 고려하는 사람에게 적합한 플랜을 고르고 어떤 결제 약정을 하게 되는지 설명해 달라고 하세요. 그 답을 보면 레이아웃이 실제로 무엇을 전달하는지 확인할 수 있습니다.

독자가 실제로 선택하는 청구액을 계산하세요

좌석당 과금의 별도 예시로 SeatMeter라는 가상의 서비스를 생각해 보겠습니다. 표시된 가격은 편집자당 월 12달러이며, 연간 결제에 최소 편집자 다섯 명이라는 조건이 붙습니다. 이때 세 명으로 구성된 팀이 매달 36달러만 내면 된다는 뜻은 아닙니다. 명시된 조건에 따르면 최소 연간 약정액은 12달러 × 5 × 12 = 720달러입니다.

개별 숫자가 모두 정확해도 요금 디자인은 이 지점에서 자주 실패합니다. 시각적 위계 때문에 월 환산액은 기억에 남지만 실제 결제액은 거의 눈에 들어오지 않기 때문입니다. 사용자에게 오늘 얼마가 청구될 것으로 예상하는지 설명해 달라고 하세요. 청구액 대신 단가를 답한다면 단가를 더 크게 표시하는 것으로는 오해를 해결할 수 없습니다.

절약 금액을 알리는 배지가 비교 기준을 가리지 않게 하세요. 연간 결제가 월간 결제 열두 번보다 20% 저렴하다면 어떤 월 요금을 기준으로 계산했는지 밝히세요. 프로모션이 첫 결제 기간에만 적용된다면 그 조건을 할인 금액 가까이에 두세요. 일시적인 혜택에 상시 혜택처럼 보이는 배지를 붙이면 각주로는 바로잡기 어려운 기대가 생길 수 있습니다.

기본 제공 용량도 같은 원칙으로 다뤄야 합니다. **‘편집자 다섯 명 기본 제공’과 ‘최소 다섯 명분 결제’**는 처음 이용하는 팀의 규모는 같게 만들 수 있어도 서로 다른 판매 규칙을 뜻합니다. 실제 규칙을 기준 정보표에 기록하고 카드, 비교표, 결제 단계로 이어지는 안내에서도 같은 의미로 표현하세요.

워크스페이스 단위 요금은 계산 방식이 다릅니다

금액, 통화, 과금 단위, 결제 약정을 함께 보여 주세요. 연간 구독을 월 환산액으로 표시한다면 연간 총 청구액도 같은 시각적 묶음 안에 있어야 합니다.

Fieldnote Team의 월간 결제 요금이 워크스페이스당 월 30달러라고 가정해 보겠습니다. 별도로 제공되는 워크스페이스 단위 연간 요금은 워크스페이스당 연 288달러이며, 월 환산액은 24달러입니다. 이해하기 쉬운 연간 플랜 카드라면 월 환산액을 주된 숫자로 보여 주고, 바로 이어서 연간 288달러가 청구된다고 설명할 수 있습니다. 방문자가 24달러씩 열두 번 나누어 결제할 수 있는지 스스로 추측하게 해서는 안 됩니다.

워크스페이스 요금과 좌석당 요금의 차이도 신중하게 설명해야 합니다. 여섯 명인 팀이 실제로는 여섯 배를 내야 한다면 ‘월 24달러’만으로는 불충분합니다. 정해진 수의 편집자가 가격에 포함되는지, 편집자마다 요금이 적용되는지, 최소 결제 수량이 있는지 보여 주세요. 수량에 관한 전제는 멀리 떨어진 툴팁 대신 가격과 같은 영역에 두세요.

사용량에 따라 금액이 달라진다면 계산기를 넣기 전에 과금 범위를 설명하세요. 계산 근거가 보이지 않는 계산기는 불확실한 가격을 정밀하게 확정된 가격처럼 보이게 할 수 있습니다. 어떤 사용량이 포함되는지, 무엇이 추가 요금을 발생시키는지, 표시된 예상액에 선택 항목이 포함되는지 밝히세요. 계산에 쓸 안정적인 단가가 없다면 대신 영업팀에 어떤 정보를 전달해야 하는지 설명하세요.

비교표의 한 행에 여러 단위를 섞지 마세요. 무엇을 어느 기간 동안 세는지 행에서 설명하지 않으면 한 셀의 ‘10’과 다른 셀의 ‘무제한’은 의미가 모호합니다. ‘활성 프로젝트’와 ‘한 달 동안 생성한 프로젝트’는 다릅니다. 숫자가 같아 보여도 이 차이 때문에 구매 결정이 달라질 수 있습니다.

결제 주기 전환을 조건의 변경으로 다루세요

월간 결제와 연간 결제를 전환하면 영향을 받는 모든 정보가 함께 바뀌어야 합니다. 대표 금액에 애니메이션을 적용하는 것만으로 끝나지 않습니다. 연간 총액, 절약 금액의 설명, 약정 문구, 구매 버튼이 연결되는 목적지가 모두 선택한 상태와 일치해야 합니다.

Fieldnote 예시에서는 월간 결제를 열두 달 유지하면 총 360달러이며, 연간 결제는 288달러입니다. 차이는 72달러로, 월간 결제 총액의 20%입니다. 절약 금액을 표시한다면 그 계산 기준을 분명히 하세요. 할인된 연간 금액을 다른 프로모션 요금과 비교하면 전달되는 의미가 달라집니다.

현재 선택한 옵션에는 모호하지 않은 라벨과 상태 표시가 필요합니다. 작은 스위치 양옆에 단어 두 개만 놓으면 왼쪽 라벨이 현재 값인지, 전환할 수 있는 다른 옵션인지 헷갈릴 수 있습니다. 선택된 옵션이 눈에 보이는 분할 선택 컨트롤은 프로토타입에서 동작을 설명하기가 더 쉬운 경우가 많습니다. 어떤 방식을 택하든 키보드로 조작할 때도 선택 상태를 알 수 있어야 하며, 색상에만 의존해서는 안 됩니다.

페이지 아래쪽의 플랜을 보면서 결제 주기를 바꿔 보세요. 어떤 결제 기간이 적용되는지 여전히 알 수 있나요? 긴 비교표 가까이에 결제 주기 라벨을 한 번 더 보여 주는 편이 화면 위로 멀리 사라진 컨트롤보다 유용할 수 있습니다. 가격의 맥락을 유지하는 데 필요하다면 반복해서 보여 줄 이유가 있습니다.

어떤 요소를 그대로 유지할지도 정하세요. 실제 상품 조건이 바뀌는 경우가 아니라면 방문자가 결제 주기를 바꿨다는 이유만으로 플랜 순서나 기능 한도가 달라져서는 안 됩니다. 예상치 못한 재배치는 두 상태를 비교하기 어렵게 하고, 독자가 보고 있는 도중에 서비스 자체가 바뀐 듯한 인상을 줄 수 있습니다.

실제 조건을 공정하게 비교할 수 있는 행을 만드세요

각 행은 하나의 질문을 제시하고 모든 플랜에 대해 답해야 합니다. ‘프로젝트 용량’에는 숫자가 들어갈 수 있습니다. ‘게스트 접근’에는 ‘포함’ 또는 ‘미포함’이 들어갈 수 있습니다. 어떤 플랜은 이메일 지원을, 다른 플랜은 전담 담당자를 제공한다면 ‘지원’ 항목에는 이를 설명하는 문구가 필요합니다. 체크 표시만으로는 이런 차이를 표현할 수 없습니다.

한 행에서는 같은 단위와 같은 수준의 구체성을 사용하세요. Solo 열에 ‘활성 프로젝트 3개’라고 썼다면 Team 열에는 ‘넉넉한 성장 공간’이라고 쓰지 마세요. 두 번째 문구는 표가 제공해야 할 비교를 피해 갑니다. 홍보 문구는 주변 설명에 두고, 셀에는 실제 한도를 적으세요.

제공하지 않는 것과 알 수 없는 것을 구분하세요. 대시는 이용 불가, 해당 없음, 미공개, 0을 모두 뜻할 수 있습니다. 그 차이가 중요하다면 뜻을 명시하는 단어를 쓰세요. 간결한 기호를 사용한다면 의미를 명확히 하고 보조 기술에도 그 의미가 전달되게 해야 합니다. 구매자가 빈 셀을 보고 기능 제한인지 게시 오류인지 추측하게 해서는 안 됩니다.

기능 이름도 일관되게 유지해야 합니다. 같은 기능을 첫 번째 플랜에서는 ‘공유 폴더’, 두 번째 플랜에서는 ‘협업 공간’이라고 부르면 실제로는 없는 업그레이드 차이가 있는 것처럼 보일 수 있습니다. 기능이 정말 달라진다면 구성원 수 증가, 더 긴 기록 보관 기간, 다른 권한, 다른 서비스 제공 약정 등 무엇이 바뀌는지 설명하세요.

독자가 알아볼 수 있는 질문을 기준으로 행을 묶으세요. Fieldnote라면 프로젝트 작업, 협업, 관리라는 구역을 둘 수 있습니다. 이런 묶음은 제품팀 내부의 담당 조직도를 재현하기보다 사용자가 답을 찾도록 도와야 합니다. 구매자가 공유 접근이라는 관점에서 생각한다면, 관련 기능을 여러 개발팀이 나누어 담당하더라도 그 정보를 찾는 경로는 분명해야 합니다.

‘이전 플랜의 모든 기능 포함’이라는 표현은 신중하게 사용하세요. 카드 길이는 줄어들지만 상위 플랜을 이해하려면 다른 곳을 다시 봐야 합니다. 짧은 개요에서는 허용할 수 있습니다. 하지만 비교표에서는 실제 값을 반복해서 보여 주는 편이 대체로 더 유용합니다. 각 행을 다른 행에 의존하지 않고 비교할 수 있기 때문입니다.

추천하는 이유를 함께 보여 주세요

강조한 플랜에는 누구에게 적합한지 설명이 있어야 합니다. ‘여러 프로젝트에서 연구 내용을 공유하는 팀을 위한 플랜’은 Fieldnote Team을 고려할 이유를 줍니다. 반면 ‘최고의 가성비’는 근거를 알려 주지 않은 채 판단을 받아들이라고 요구합니다. ‘가장 인기 있는 플랜’은 증거가 필요한 사실 주장입니다. 추천을 대신하는 장식으로 사용해서는 안 됩니다.

다른 선택지도 읽기 쉽게 유지하면서 강조를 통해 살펴볼 출발점을 제시하세요. 조금 더 강한 테두리, 작은 라벨, 절제된 배경 변화로도 가능합니다. 가운데 카드를 지나치게 크게 만들어 주변 조건을 훑어보기 어렵게 한다면 득보다 실이 큽니다. 사용자는 강조된 옵션도 다른 옵션과 비교해야 합니다.

강조 표시를 제거한 상태로 페이지를 확인해 보세요. 그러자 상품 조건을 이해할 수 없게 된다면 강조가 너무 많은 설명을 대신하고 있던 것입니다. 색으로 우선순위를 주기 전에도 플랜 이름, 대상 설명, 눈에 보이는 차이만으로 합리적인 선택이 가능해야 합니다.

좁은 화면에서도 선택의 차이를 숨기지 마세요

플랜 카드를 세로로 쌓는 것은 간단하지만 비교 기능을 유지하는 일은 더 어렵습니다. 플랜 하나가 화면 하나씩 차지하면 첫 플랜에 어떤 기능이 포함되어 있었는지 기억하는 일까지 사용자의 과제가 됩니다. 깔끔한 세로 레이아웃이라고 해서 자동으로 비교하기 쉬운 것은 아닙니다.

플랜 수가 적다면 세로로 쌓은 카드에서도 기능 순서를 일관되게 유지하세요. 비교표가 길다면 두 플랜을 선택해 비교하는 좁은 화면용 구성이나, 현재 위치를 분명히 알 수 있는 가로 스크롤 표를 고려하세요. 방문자가 주로 한 플랜을 읽는지, 여러 플랜의 특정 값을 비교하는지에 따라 적합한 방식이 달라집니다.

아코디언은 처음 보이는 길이를 줄여 주지만 정보를 숨기기도 합니다. 중요한 이용 제한과 결제 조건은 접힌 영역 밖에 두세요. 게스트 접근을 제공하는 플랜을 찾으려고 모든 플랜을 펼쳐야 한다면, 아코디언은 같은 수고를 더 많은 조작으로 나누어 놓았을 뿐입니다.

실제 데이터 표를 사용한다면 구조적 관계를 보존하세요. W3C의 표 튜토리얼은 보조 기술에서도 관계를 알 수 있도록 머리글 셀과 데이터 셀을 연결하는 방법을 설명합니다. 텍스트를 눈으로 보기 좋게 정렬한 그리드는 이와 동등한 구현이 아닙니다. W3C의 접근 가능한 표 튜토리얼.

좁은 화면에서는 구체적인 비교 과제로 테스트하세요. 편집자 여섯 명과 활성 프로젝트 스무 개를 지원하는 가장 저렴한 옵션을 찾아보는 것입니다. 이런 가상의 요구 조건을 쓰면 선택에 필요한 정보가 레이아웃 안에 유지되는지 확인할 수 있습니다. 페이지가 화면 폭 안에 들어오는지만 확인해서는 알 수 없는 부분입니다.

버튼의 행동을 실제 다음 단계와 맞추세요

버튼은 방문자가 곧바로 할 수 있는 행동을 설명해야 합니다. 체험 시작, 무료 워크스페이스 생성, 유료 구독 선택, 영업팀 문의는 서로 다른 단계입니다. 모두 ‘시작하기’로 통일하면 버튼 행은 일정하게 보이지만 어떤 일이 일어나는지는 모호해집니다.

중요한 조건은 해당 행동 가까이에 두세요. 체험에 결제 수단 등록이 필요하다면 사용자가 진행하기 전에 알려 주세요. 조직용 플랜이 상담으로 시작한다면 곧바로 결제할 수 있다는 인상을 주는 버튼을 피하세요. 목적은 카드 안에서 전체 구매 과정을 설명하는 것이 아니라 정확한 기대를 갖게 하는 것입니다.

이미 구독 중인 사용자도 고려하세요. 일반 방문자용 요금표는 이들을 중복 가입 절차로 보낼 수 있습니다. 실제 제품 구현에서는 현재 플랜 표시나 계정 설정으로 가는 경로가 필요할 수 있습니다. 프로토타입에 계정 로직을 구현하지 않더라도 이 상태를 기록해 두세요. 처음 방문하는 사람만을 기준으로 디자인을 평가하지 않게 됩니다.

선택할 수 없는 모든 경우를 비활성 버튼으로 표현하지 마세요. 이용 자격이 계정 조건에 달려 있다면 그 조건을 설명하세요. 설명 없이 비활성화된 컨트롤만으로는 사용자가 한도 때문인지, 일시적 오류인지, 의도된 규칙인지 판단할 수 없습니다.

캡처된 GitHub 카드에서 이 차이를 구체적으로 볼 수 있습니다. Team에는 ‘Continue with Team’이 있고, Enterprise에는 체험 시작과 영업팀 문의가 함께 있습니다. 두 번째 카드는 같은 플랜으로 들어가는 두 경로를 제시하는 것이지, 그 플랜의 기능 두 가지를 나열하는 것이 아닙니다. 검토할 때 각 경로를 따라가며 방문자가 다음에 어떤 정보를 입력해야 하는지 확인하세요. 버튼 색을 일관되게 유지해 시각적 리듬을 살리면서도 라벨은 다음 단계를 구체적으로 설명할 수 있습니다.

의사결정 과제로 초안을 검토하세요

검토자마다 답해야 할 질문이 있으면 시각 검토가 더 유용해집니다. 한 사람에게는 개인 사용자 상황을, 다른 사람에게는 성장 중인 팀의 상황을 주세요. 플랜을 선택하고 어떤 사실을 근거로 골랐는지 설명해 달라고 하세요. 그 판단 과정을 보면 막연하게 의견을 요청할 때는 놓칠 수 있는 모호함이 드러납니다.

Fieldnote에서는 프로젝트 두 개와 여러 게스트를 둔 연구자, 편집자 여섯 명인 팀, 조직 전체의 관리가 필요한 조직이라는 세 가지 과제를 사용할 수 있습니다. 강조된 플랜을 선택해서는 안 되는 상황도 포함하세요. 그렇지 않으면 시각적 강조가 작동하는지만 확인하게 되고, 비교표가 다른 결론도 뒷받침하는지는 알 수 없습니다.

그다음 각 사람에게 즉시 청구되는 금액과 결제 약정을 말해 달라고 하세요. 정답에 해당하는 문구가 페이지 어딘가에 있더라도 답이 틀리면 문제입니다. 자동으로 각주를 하나 더 붙이기보다, 실제 오해가 생긴 이유에 맞춰 설명의 위치를 옮기거나 문구를 다시 쓰세요.

의도적으로 다루기 까다로운 값도 넣어 표를 검토하세요. 긴 기능명, 제공되지 않는 기능, 협의로 가격을 정하는 플랜 등이 해당합니다. 개발할 때까지 미뤄도 되는 드문 레이아웃 예외가 아닙니다. 비교 구조가 실제 상품 조건을 표현할 수 있는지를 좌우하는 값들입니다.

OpenDesign에서는 HTML 미리보기로 이런 시각 검토를 진행할 수 있습니다. 오해를 유발하는 가격 묶음이나 정렬이 어긋나는 비교 행을 댓글로 지적하고, 해당 부분의 텍스트나 스타일을 수정해 표현을 다듬을 수 있습니다. 승인된 플랜 정보를 디자인 맥락으로 제공하세요. 요금 계산, 계정별 이용 자격, 결제 동작은 실제 구현된 흐름에서 확인해야 합니다.

페이지를 인계하기 전에 화면에 보이는 모든 가격과 한도를 기준 정보표와 대조하세요. 두 결제 상태, 모든 구매 버튼, 좁은 화면의 레이아웃을 확인하세요. 강조된 플랜이 정답이 아닌 경우까지 포함해, 독자가 적절한 선택과 그 조건을 정확히 설명할 수 있을 때 요금표가 준비된 것입니다.