B2C 네트워크 슬라이싱 상품은 어떻게 설계해야 하는가

‘항상 더 빠르다’는 상품 약속이 될 수 없다

상대적 우선 처리와 절대 최소 품질은 다른 계약이다. 상대적 우선 처리는 정해진 조건에서 구매자의 traffic을 비교 기준보다 먼저 처리하도록 설계하는 방식이다. 같은 cell과 시간창에서 일반 profile보다 높은 scheduling priority를 적용할 수 있지만, capacity가 모두 소진됐거나 외부 구간이 느리면 최종 속도는 함께 낮아질 수 있다. 이 약속은 ‘누구보다 항상 빠르다’가 아니라 ‘정해진 혼잡 조건과 관리 구간에서 우선 처리한다’에 가깝다.

절대 최소 품질은 더 강한 약속이다. 예를 들어 정해진 measurement point 사이에서 특정 시간창 동안 throughput이나 latency의 하한을 정한다. 숫자를 쓰는 순간 측정 지점, 통계 방식, sampling interval, 예외 조건과 failure 판정이 따라와야 한다. 구매 전에 feasibility와 남은 capacity를 확인하고, 지원할 수 없는 주문은 거절하거나 약속 수준을 낮춰야 한다. 판매량을 제한하는 admission control 없이 절대 하한을 넓게 약속하면 매출을 늘릴수록 이행 가능성이 떨어지는 역설이 생긴다.

3GPP의 QoS Flow, 5QI, ARP, GBR·GFBR·MFBR은 traffic treatment와 자원 수락·유지, 비트율 요구를 표현하는 기술 요소다. S-NSSAI는 Network Slice를 식별하고 PDU Session은 특정 slice에 속할 수 있다. 그러나 이 용어 하나가 소비자에게 보여 줄 보장, 전 구간 자원 예약, 장애 책임이나 환불을 자동 완성하지 않는다. 표준 기능을 상품 언어로 번역하려면 통신사가 실제로 관측·통제하는 범위를 다시 계약해야 한다.

필자는 첫 B2C 가설에서 약속을 두 층으로 나누는 편이 안전하다고 본다. 기본층은 정해진 시간·장소·앱·세션 안에서의 상대적 우선 처리다. 선택층은 충분한 capacity와 measurement endpoint를 확보한 구간에서만 판매하는 절대 하한이다. 두 층 모두 활성화 상태와 품질 증거, 저하 알림, fallback, remedy가 없다면 완성된 상품이 아니다.

상품은 시간·장소·앱·세션으로 잘라야 한다

행사 persona에게 중요한 것은 slice라는 이름이 아니라 자신의 방송 세션이 언제부터 어디까지 보호되는지다. 따라서 상품 설명의 첫 줄은 속도가 아니라 범위여야 한다.

‘시간’은 구매 가능 시각, 활성화 시작, 종료, 연장과 grace period를 정한다. 행사 시작 직전에 구매해도 즉시 적용되는지, 정책 배포에 시간이 필요한지, 자정이 지나면 자동 종료되는지 보여 줘야 한다. ‘장소’는 venue 전체인지 특정 stand·gate·fan zone인지, 이동 중 handover를 포함하는지 정한다. ‘앱’은 모든 traffic인지 승인된 streaming application인지, background upload까지 포함하는지 구분한다. ‘세션’은 하나의 PDU Session, 특정 device, 동시 사용 가능한 session 수와 재접속 규칙을 정한다.

대상 확인도 범위의 일부다. 가입 권한이 있어도 단말 modem·OS·policy와 application traffic binding이 지원되지 않으면 구매 후 기본 경로로 연결될 수 있다. 구매 버튼을 먼저 보여 주고 나중에 지원 불가를 알리는 대신, 대상 지역·시간, 단말, app version, 남은 capacity를 먼저 확인해야 한다. 확인할 수 없는 항목은 ‘지원됨’으로 추정하지 않고 조건부 또는 미지원으로 표시한다.

고객 약속은 한 문장으로 끝내지 않는다. 우선 처리인지 절대 하한인지, 측정 지점은 단말에서 managed edge까지인지, 외부 internet과 platform server는 제외되는지, 범위 밖으로 이동하면 무엇이 되는지 설명한다. 외부 cloud·application 장애, unsupported device, venue 전원·backhaul 문제, 긴급 통신 우선권과 초과 수요 같은 제외 조건도 구매 전에 보여 줘야 한다. 제외 조건이 길다고 약속이 약해지는 것은 아니다. 통제하지 못하는 부분을 숨길수록 remedy 비용과 불신이 커진다.

월정액과 행사·세션 이용권은 서로 다른 부담을 만든다

필자가 보는 두 모델의 tradeoff는 반복 매출과 공급 통제 사이에 있다. 월정액은 매번 결제할 필요가 없어 반복 이용자에게 편하고 통신사에는 반복 매출 가능성을 준다. 그러나 고객은 월정액을 ‘어디서나 쓸 수 있는 상시 혜택’으로 이해하기 쉽다. 일부 venue에서만 동작한다면 기대와 실제 범위가 어긋난다. 넓은 coverage, 지역별 capacity, 이동 중 continuity, 단말·앱 지원 편차와 상시 고객 지원이 운영 부담으로 돌아온다.

행사·세션 이용권은 시작과 종료, 장소와 판매량을 함께 제한하기 쉽다. 통신사는 event traffic forecast와 현장 capacity에 맞춰 판매 수량을 정하고 부족하면 stop-sell할 수 있다. 고객도 구매한 세션에서 무엇을 받는지 비교적 분명히 이해할 수 있다. 반면 사용 빈도가 낮고 행사 일정에 따라 매출이 흔들릴 수 있다. 짧은 시간에 eligibility 확인, 활성화, 장애 알림, 환불·credit 처리가 몰리므로 건별 운영비가 커질 수도 있다.

두 모델 가운데 하나를 정답으로 고르면 안 된다. 월정액이 반복 매출에 유리하다는 가설은 실제 반복 사용과 churn, coverage 비용을 확인해야 한다. 이용권이 통제하기 쉽다는 가설은 행사별 수요, 구매 전환, activation 실패와 remedy 비용을 확인해야 한다. 같은 persona를 대상으로 두 구매 단위를 시험하고, 매출뿐 아니라 제공 범위와 사람 개입 횟수까지 같은 기간에 비교해야 한다.

표의 구매 단위는 분석 가설이다. 실제 가격, 할인, 최소 이용 기간이나 수익성을 뜻하지 않는다. 월정액이라도 전국 상시 보장을 자동 의미하지 않고, 이용권이라도 절대 하한을 자동 제공하지 않는다.

두 표는 같은 두 모델을 다른 질문으로 비교한다. 첫 표는 고객이 무엇을 사는지 보여 주고, 둘째 표는 통신사가 무엇을 증명하고 감당해야 하는지 보여 준다.

구매 버튼보다 먼저 capacity와 admission을 설계해야 한다

상품 inventory는 추상적인 무제한 수량이 아니다. 시간·장소별 radio, transport, Core와 managed edge의 headroom, 예상 일반 traffic, 긴급·필수 traffic 우선순위, 이미 판매한 session을 함께 봐야 한다. 통신사는 행사 시작 전에 capacity forecast를 만들고, 판매 가능한 수량과 stop-sell threshold를 정하며, 조건이 악화되면 신규 주문을 거절하거나 더 약한 profile만 제시해야 한다.

Admission은 구매 시점 한 번으로 끝나지 않는다. 사용자가 다른 zone으로 이동하거나 단말을 바꾸고, 예상보다 많은 사람이 동시에 방송하고, transport나 edge 용량이 줄어들 수 있다. 따라서 activation 때 다시 확인하고, 사용 중에도 약속 이행 가능성을 관측해야 한다. 이미 판매한 고객을 보호하기 위해 신규 구매를 막을 수 있어야 하며, 긴급 traffic이나 기본 서비스 보호가 필요하면 유료 profile을 낮추는 규칙도 사전에 알려야 한다.

비구매 일반 이용자의 품질 보호는 이 상품의 외부 조건이 아니라 설계 제약이다. 유료 사용자를 늘릴수록 base service가 급격히 악화된다면 상품은 장기적으로 유지되기 어렵다. 필자는 내부 protection target과 capacity headroom을 정하고, 이를 침해하기 전에 판매를 멈추는 구조가 필요하다고 본다. 다만 혼잡한 무선망에서 모든 일반 이용자에게 어떤 절대 하한을 법적으로 보장해야 하는지, paid prioritization이 어디까지 허용되는지는 여기서 결론 내리지 않는다. 그 판단은 별도의 정책·법률 검토 범위다.

사용 중 증거가 없으면 고객은 약속을 확인할 수 없다

구매 성공 화면만으로 서비스가 활성화됐다고 볼 수 없다. 고객에게는 최소한 대상 단말·app·장소, 활성화 상태, 시작·종료 시각, 현재 적용 profile과 측정 가능 여부가 보여야 한다. 상대적 우선 처리라면 비교 기준과 적용 조건을 설명하고, 절대 하한이라면 measurement point·window·statistic을 보여 줘야 한다. 단말 속도 측정 하나를 전체 망의 증거로 일반화하지 않는다.

통신사 내부에서는 주문 ID, subscription, policy, PDU Session, S-NSSAI, QoS Flow, charging record와 assurance event를 연결할 수 있어야 한다. 외부 platform KQI를 계약에 포함한다면 app session과 network session의 correlation도 필요하다. 고객 화면에는 모든 내부 identifier를 노출할 필요가 없지만, ‘활성화됨’, ‘관측 중’, ‘목표 미달’, ‘범위 밖’, ‘fallback 적용’, ‘종료·원복’ 같은 상태는 숨기지 않아야 한다.

3GPP TS 32.255는 S-NSSAI·DNN·Tenant ID와 PDU Session charging information을 연결하고 account·rating·reservation control을 수행할 수 있는 구조를 정의한다. TS 28.530·28.535·28.536과 GSMA NG.116은 SLS, feasibility, management data, KPI와 assurance의 틀을 제공한다. 이 capability는 주문·사용·증거를 연결하는 기반이다. 그러나 월정액과 이용권 중 무엇을 팔지, 어떤 화면을 보여 줄지, 어떤 미달에 credit을 줄지, 사업이 수익을 내는지는 표준이 결정하지 않는다.

저하를 숨기지 말고 fallback과 remedy를 약속해야 한다

망이 목표를 지키지 못하는 순간은 상품 실패가 아니라 상품 계약이 드러나는 순간이다. 저하가 감지되면 먼저 고객에게 상태를 알려야 한다. 원인이 확정되지 않았더라도 ‘목표 미달 관측’, ‘범위 밖 이동’, ‘외부 service 확인 중’처럼 확인된 상태만 표시할 수 있다. 정상처럼 보이게 두고 사후에만 로그를 찾는 방식은 생방송처럼 시간 가치가 큰 서비스에 맞지 않는다.

Fallback은 기술팀의 비상 절차가 아니라 구매 조건이다. 기본 internet profile로 즉시 돌릴지, 더 낮은 guaranteed profile로 낮출지, 잠시 session을 중지하고 재활성화할지 정한다. Fallback 자체가 더 나쁜 결과를 만들 수 있으므로 application이 연결 변화에 어떻게 반응하는지도 시험해야 한다. 어떤 경우에도 ‘자동 fallback’이라는 말만으로 무중단을 약속하지 않는다.

Remedy는 실패의 원인과 고객 손실을 완전히 계산할 수 있을 때만 시작하는 것이 아니다. 통신사가 약속한 measurement에서 미달이 확인되면 연장, 재이용권, credit, 환불 검토, support escalation 같은 규칙을 실행할 수 있다. 실제 형태는 가격·계약·규제 검토 뒤 정해야 하므로 이 글은 특정 보상액을 제시하지 않는다. 중요한 것은 고객이 증거를 모아 여러 번 항의해야만 구제가 시작되는 구조를 피하는 일이다.

종료도 검증 대상이다. 행사나 세션이 끝나면 임시 policy와 session binding을 제거하고 기본 profile로 원복하며 charging state를 닫아야 한다. 종료 뒤에도 premium profile이나 과금이 남으면 다음 이용자의 capacity와 고객 신뢰를 동시에 해친다. 종료·원복 증거는 구매 영수증만큼 중요하다.

고객 여정은 일곱 상태로 닫힌다

대체 설명 대상과 단말을 확인한 뒤 구매·활성화·사용 증거·저하 알림과 fallback·remedy·종료와 원복까지 이어지는 일곱 상태다. 모바일에서는 위에서 아래 한 열로 읽히며, 실제 3GPP message sequence나 상용 계약 절차가 아니다.

• 1. 대상·단말 확인시간·장소·가입·단말·앱 지원과 남은 capacity를 구매 전에 확인한다.
• 2. 구매약속 수준, 범위, 제외 조건, 가격 단위 가설, fallback과 remedy에 동의한다.
• 3. 활성화policy·session 적용 성공 여부와 시작·종료 시각을 표시한다.
• 4. 사용 중 증거적용 profile, measurement 상태, 고객 KQI와 망 KPI의 경계를 보여 준다.
• 5. 저하 알림·fallback목표 미달·범위 이탈을 알리고 계약한 기본 경로 또는 낮은 profile로 전환한다.
• 6. Remedy확인된 증거에 따라 연장·재이용권·credit·환불 검토·지원 escalation을 실행한다.
• 7. 종료·원복임시 policy·session·charging state를 닫고 기본 연결로 돌아왔음을 확인한다.

이 여정의 핵심은 성공 화면이 아니라 상태 전이의 증거다. 대상 확인과 admission이 실패하면 구매하지 않는다. 구매 뒤 활성화가 실패하면 사용하지 않은 서비스로 처리한다. 사용 중 목표가 낮아지면 알림과 fallback이 먼저 움직인다. 종료 뒤에는 잔여 policy와 charging이 없어야 한다. 각 상태가 다음 상태로 넘어갈 조건을 갖출 때 고객 지원과 망 운영이 같은 사실을 보게 된다.

가격이 아니라 가격 단위를 먼저 검증한다

현재 공식 최신 가격·상품·매출 근거를 수집하지 않았으므로 특정 통신사 요금이나 상용 성공을 말할 수 없다. 대신 무엇을 한 단위로 팔 것인지 가설을 세울 수 있다. 월정액은 반복 eligibility와 사용 권리를 묶고, 행사 이용권은 venue와 time window를 묶으며, 세션 이용권은 device·app·session과 종료 조건을 묶는다. 시간 단위 추가 연장은 별도 order가 될 수 있다.

단위가 정해지면 비용도 같은 단위로 본다. 월정액 매출에는 상시 capacity·coverage·support 비용을 대응시키고, 행사 이용권 매출에는 event preparation, 현장 forecast, 짧은 activation window와 remedy 비용을 대응시킨다. 세션 매출에는 eligibility check, policy 배포, telemetry correlation, charging reconciliation의 반복 비용을 대응시킨다. 가격 숫자보다 먼저 한 건을 더 팔 때 추가되는 운영 비용과 risk가 줄어드는지 확인해야 한다.

필자가 보는 B2C Network Slicing의 출발점은 ‘항상 더 빠른 망’이 아니다. 특정 persona가 반복해서 겪는 문제를 시간·장소·앱·세션으로 자르고, 통신사가 실제로 통제할 수 있는 우선 처리 또는 최소 품질만 약속하며, capacity가 없을 때는 팔지 않는 상품이다. 그 약속은 activation과 사용 증거로 보이고, 저하되면 알림·fallback·remedy가 작동하며, 끝나면 깨끗하게 원복돼야 한다.

기술 capability는 이 계약을 실행할 도구를 제공한다. 상품은 그 도구를 고객이 이해할 범위·증거·책임으로 묶는 일이다. 월정액과 이용권의 승자는 지금 정할 수 없다. 실제 반복 수요, coverage expectation, admission failure, 사람 개입, remedy 비용과 재구매를 같은 기준으로 측정한 뒤에야 어떤 모델이 가치와 통제를 함께 만족하는지 판단할 수 있다.

공식 자료

• 3GPP TS 23.501 V18.11.0 — 5GS architecture and QoS
• 3GPP — Network Slice charging based on 5G Data Connectivity
• 3GPP TS 32.255 V19.3.0 — 5G data connectivity domain charging
• 3GPP TS 28.530 V19.0.0 — Management and orchestration concepts, use cases and requirements
• 3GPP TS 28.535 V19.0.0 — Communication service assurance requirements
• 3GPP TS 28.536 V19.2.0 — Network Slice assurance management services
• 3GPP — 5G Network slice management
• GSMA NG.116 V10.0 — Generic Network Slice Template

이미지 설명: 붐비는 공연 현장에서 한 창작자와 주변의 제한된 서비스 영역, capacity 확인 지점을 추상적으로 표현한 독창적 개념 이미지다. 실제 3GPP topology, message sequence, 표준 interface, 상용 상품 계약 또는 특정 통신사의 망 구성을 나타내지 않는다.