투기형과 유틸리티형은 무엇으로 구분하나

같은 NFT라도 브랜드가 어떤 문구로 소개하느냐에 따라 투기형과 유틸리티형으로 갈립니다. "한정 수량이라 가치가 오를 것"이라는 식의 소개는 투기형 프레이밍입니다. 반대로 "이 NFT를 보유한 회원만 신제품 출시 전 팝업 스토어에 우선 입장할 수 있다"는 식으로 구체적 행동과 혜택을 못박으면 유틸리티형입니다. 업계에서는 이 구분을 공식 용어로 규정한 기관은 없지만, 마케팅 실무자들이 반복적으로 쓰는 기준입니다. 12code 라이브러리는 이 구분을 기준으로 삼아, 이 과목 전체에서 시세·투자수익을 암시하는 표현을 쓰지 않고 유틸리티 관점으로만 설계 방법을 다룹니다.

유틸리티 설계의 3가지 축

실무에서 유틸리티를 설계할 때는 크게 세 축으로 나눠 생각하면 정리가 쉽습니다. 첫째는 거래 혜택 축입니다 — 자사몰 특정 카테고리 할인, 무료배송, 우선 배송 같은 구매 관련 혜택입니다. 둘째는 접근권 축입니다 — 오프라인 팝업 우선 입장, 한정판 제품 우선 구매권, 비공개 커뮤니티(디스코드 등) 입장권처럼 "먼저 접근할 권리"입니다. 셋째는 인증·기록 축입니다 — 브랜드와 함께한 이력(특정 캠페인 참여, 오프라인 행사 방문)을 지갑에 남겨, 그 이력에 따라 다음 혜택의 등급을 나누는 방식입니다. 신세계 푸빌라 사례처럼 등급별 혜택을 디스코드 커뮤니티와 함께 운영하는 구조가 이 접근·인증 축을 결합한 예로 보도됐습니다.

왜 광고 소재에서 "투자" 뉘앙스를 빼야 하나

구글 광고정책은 승인된 카테고리 밖에서 가상자산의 매매·교환을 유도하는 광고를 원천 금지 항목으로 분류합니다. 멤버십 NFT라도 광고 문구에 "가치 상승", "리셀 가능", "한정 수량이라 지금 사야 함" 같은 표현이 들어가면 이 금지 카테고리로 오인돼 반려될 위험이 있습니다. 메타 역시 NFT 자체는 사전허가가 필요 없다고 명시하면서도 거래·스테이킹·스왑을 다루는 광고는 별도 심사 대상으로 분리합니다. 결국 광고 소재 단계에서부터 "무엇을 할 수 있는가"만 말하고 "얼마의 가치가 있는가"는 말하지 않는 원칙을 지켜야, 9강에서 다룰 빅테크 광고 반려 리스크를 줄일 수 있습니다.

유틸리티를 지속 공급할 계획을 먼저 세운다

유틸리티형으로 설계해도 초반 혜택 한두 개로 끝나면 결국 투기형과 비슷한 실패를 겪습니다 — 실사용 가치가 사라지면 유저는 그 NFT를 더 이상 쓸모없는 자산으로 인식하게 됩니다. 이 리스크는 7강에서 다룰 실패 사례 분석의 핵심 원인이기도 합니다. 그래서 기획 단계에서부터 최소 분기별로 새 혜택을 추가할 로드맵, 그리고 혜택이 소진되거나 프로그램을 종료할 때의 안내 절차까지 함께 설계해야 합니다. 스타벅스 오디세이가 종료 시 회원의 잔여 활동 마감일을 명확히 공지하고 자산 이전 경로(니프티 게이트웨이)를 마련했던 방식은, 종료 계획까지 설계에 포함해야 한다는 실무 시사점으로 참고할 만합니다.

실행 전 체크리스트

기획안을 확정하기 전에 다음을 점검하는 걸 권합니다. 이 NFT를 보유하면 구체적으로 어떤 행동(할인·입장·구매)이 가능한지 한 문장으로 설명할 수 있는가. 그 혜택을 오프라인·온라인에서 실제로 검증할 운영 절차가 있는가. 광고 소재 초안에 투자·시세 관련 단어가 섞여 있지 않은가. 최소 1년 이상 유틸리티를 추가 공급할 예산·인력이 배정돼 있는가. 이 네 가지에 모두 답할 수 없다면, 정식 발행 전에 소규모 팝업이나 한정 이벤트로 먼저 테스트해보는 편이 안전합니다.

등급 설계에서 흔히 겪는 실수

등급별 혜택을 설계할 때 가장 흔한 실수는 등급 수를 너무 잘게 나누는 것입니다. 등급이 5단계, 10단계로 늘어날수록 운영팀이 각 등급의 혜택을 오프라인·온라인에서 동시에 검증해야 하는 부담이 커지고, 유저 입장에서도 "내가 지금 어느 등급인지, 다음 등급까지 뭐가 더 필요한지"를 이해하기 어려워집니다. 웹2 마일리지 제도에서 이미 검증된 3~4단계 등급 구조(예: 기본·실버·골드·VIP)를 그대로 웹3 멤버십에 옮기는 편이, 새로운 등급 체계를 처음부터 설계하는 것보다 유저 학습 비용이 낮습니다. 등급 명칭이나 발행 방식만 NFT로 바꾸고, 등급 논리 자체는 이미 검증된 웹2 CRM 구조를 재사용하는 것도 실무적으로 합리적인 선택입니다.