사업편 · B2B 네트워크 슬라이싱 상품화

B2B 네트워크 슬라이싱은 왜 반복 가능한 상품이 되기 어려운가

고객별 애플리케이션·단말·장소·시간·보안·SLA 요구가 설계·구축·검증·운영 비용으로 누적되는 과정을 따라가며, 맞춤형 네트워크 슬라이싱이 반복 판매 가능한 B2B 상품이 되기 위한 경계를 살핀다.

글 · TelcoNexus최초 발행 2026-08-14조회수 확인 중

한 공장에서 Network Slicing을 기술적으로 구현하는 데 성공했다면, 같은 상품을 다른 공장에도 그대로 팔 수 있을까. 일반 독자가 가장 먼저 묻는 질문은 단순하다. “이미 되는 기술이라면 고객만 늘리면 되는 것 아닌가?” 그러나 한 번의 구축 성공과 반복 판매 가능한 상품은 같은 말이 아니다. 첫 번째 고객을 위해 엔지니어가 요구사항을 해석하고 망을 조정해 줄 수는 있다. 고객이 늘어날 때마다 같은 설계·시험·조율을 처음부터 반복해야 한다면 매출과 함께 비용도 거의 같은 속도로 늘어난다.

필자는 B2B Network Slicing의 핵심 난제를 기술의 가능성보다 **변형의 경계**에서 찾는다. 고객은 단지 slice 하나를 사는 것이 아니다. 애플리케이션·단말·장소·시간·보안·SLA/SLS 요구를 함께 가져온다. 통신사는 그 요구를 Radio Access Network(RAN), Transport Network(TN), Core Network(CN), 비(非) 3GPP 영역과 운영 체계에 번역해야 한다. 서로 다른 고객 요구를 제한된 입력과 검증된 구성으로 흡수하지 못하면 ‘상품’이라는 이름 아래 고객별 프로젝트가 계속 생긴다.

스마트팩토리의 여러 업무 흐름이 요구사항·설계·구축·검증·운영의 다섯 관문을 지나며 비용 블록이 누적되는 모습을 추상적으로 표현한 편집 이미지 — 고객 요구가 설계·구축·검증·운영으로 이어지면서 사람·시스템·자원 비용이 누적되는 관계를 표현한 개념 이미지다. 실제 3GPP topology, message sequence, 상용 구축도 또는 특정 통신사의 망 구성이 아니다.

반복 가능한 상품과 고객별 프로젝트는 무엇이 다른가

반복 가능한 표준 상품은 모든 고객에게 똑같은 망을 준다는 뜻이 아니다. 고객이 선택할 수 있는 범위, 지원 단말과 애플리케이션, coverage 유형, 품질 등급, 구축 옵션, 검증 방식과 운영 책임이 미리 정의돼 있다는 뜻이다. 새로운 주문은 이 경계 안에서 parameter를 선택하고 이미 검증한 조합을 배치한다. 반면 고객별 프로젝트는 주문이 들어온 뒤에야 요구를 해석하고 구조와 시험 기준, 운영 조직, 가격을 함께 만든다.

반복 가능한 표준 상품과 고객별 프로젝트
질문	반복 가능한 표준 상품	고객별 프로젝트
요구사항	제한된 profile에서 선택	고객별로 다시 해석
망 구성	검증된 조합을 재사용	별도 설계·조정 가능
검증	공통 시험과 인수 기준	현장별 기준을 협의
가격	옵션·등급별 산정 규칙	견적 단계에서 계산
운영	정해진 책임·지원 등급	별도 조직·절차 가능

표의 오른쪽이 나쁘다는 뜻은 아니다. 공장, 항만, 공항처럼 물리 환경과 업무 중요도가 다른 현장에는 맞춤 설계가 필요할 수 있다. 문제는 맞춤 범위를 통제하지 않은 채 표준 상품처럼 반복 판매한다고 가정할 때 생긴다. 어떤 차이는 선택 가능한 옵션이고, 어떤 차이는 새로운 엔지니어링 프로젝트인지 구분해야 원가와 납기를 설명할 수 있다.

고객 요구는 하나의 SLA 숫자로 끝나지 않는다

3GPP TS 28.541의 ServiceProfile에는 최대 단말 수, coverage area, 상·하향 latency, mobility, availability, throughput, 단말 밀도와 활동성, 신뢰도, 데이터 양, 위치·동기 요구, 인증·권한, N6 보호, 연결할 data network 같은 속성이 포함된다. 이것은 기업 요구를 표현할 공통 어휘를 제공한다. 다만 속성 목록이 곧 완성된 상품 catalogue는 아니다. 고객이 어떤 값을 원하고 통신사가 어떤 조합을 지원할지 별도로 정해야 한다.

‘애플리케이션’은 traffic의 방향, burst, session 지속 시간과 허용 가능한 지연을 바꾼다. ‘단말’은 modem·주파수·인증·정책 지원과 설치 형태를 바꾼다. ‘장소’는 indoor coverage, 이동 경로, 기지국·전송 접근성, 현장 설비와의 접점을 바꾼다. ‘시간’은 상시 제공인지 생산 교대나 특정 작업 window인지, peak가 언제인지 결정한다. ‘보안’은 public network와의 분리 수준, 인증, data network 연결, 현장 시스템과의 경계를 바꾼다. ‘SLA/SLS’는 latency나 availability 숫자뿐 아니라 측정 위치, 통계, 관측 주기, 제외 조건과 책임을 필요로 한다.

GSMA의 Generic Network Slice Template(GST)와 Network Slice Type(NEST)도 여러 산업 요구를 공통 속성으로 기술하고 customer-specific 값을 담는 틀을 제공한다. 이 표준화는 중요한 출발점이다. 하지만 같은 template을 쓴다고 해서 현장 환경, 용량, 단말 적합성, 비 3GPP 구간, 운영 책임까지 같아지는 것은 아니다. 표준은 질문의 형식을 맞춰 주지만 모든 답을 하나로 만들지는 않는다.

스마트팩토리는 혼재하는 traffic과 현장 변경을 함께 보여 준다

스마트팩토리에는 영상 검사·CCTV, AGV와 mobile robot, robot arm이나 controller, 작업자 단말처럼 성격이 다른 traffic이 동시에 존재할 수 있다. 모든 흐름에 같은 latency·reliability·mobility 요구를 적용할 이유는 없다. 고정 설비는 Ethernet이 적합할 수 있고, 일반 업무는 Wi-Fi를 사용할 수 있으며, 이동성과 일관된 관리 범위가 중요한 흐름에는 5G가 후보가 될 수 있다. 특정 무선 기술 하나가 모든 현장을 자동으로 대체한다고 전제해서는 안 된다.

5G-ACIA는 flexible assembly, cooperative robot, AGV, mobile inspection 같은 산업 use case와 다양한 Non-Public Network 배치 선택지를 함께 설명한다. 생산 line을 재구성할 때 cable 제약을 줄이려는 요구는 무선의 장점과 연결될 수 있다. 그러나 use case를 선택하면 곧바로 구축안이 정해지는 것은 아니다. public network와의 통합 수준, 공유 또는 전용 자원, spectrum, 현장 Core와 application 연결, 운영 주체를 다시 선택해야 한다.

이 사례의 의미는 ‘스마트팩토리라면 5G가 정답’이라는 결론이 아니다. 같은 고객 안에서도 traffic마다 요구가 달라 slice와 QoS profile, data path, 단말, 측정 지점을 나눠야 할 수 있다는 점이다. 필자는 유선·Wi-Fi·5G를 경쟁하는 한 줄의 순위가 아니라 현장 업무별로 조합하는 설계 재료로 본다. 그러므로 첫 현장의 성공 구성을 다음 현장에 복사하기 전에 무엇이 공통이고 무엇이 현장 고유인지 분해해야 한다.

비용은 요구사항에서 운영까지 단계마다 누적된다

3GPP TS 28.530은 Network Slice lifecycle을 preparation, commissioning, operation, decommissioning으로 구분한다. 준비 단계에는 design, capacity planning, onboarding과 평가가 들어가며, commissioning에서는 필요한 자원과 구성을 만든다. 운영 단계에서는 activation, supervision, KPI monitoring, resource planning, modification과 deactivation을 수행한다. 즉 slice를 ‘한 번 설정하고 끝나는 기능’으로 보면 반복 비용을 놓치게 된다.

B2B Network Slicing 비용의 누적 경로

대체 설명 고객 요구가 요구사항, 설계, 구축, 검증, 운영의 다섯 단계를 지나며 사람·시스템·자원 비용이 누적되는 흐름이다. 모바일에서는 위에서 아래 한 열로 읽힌다. 실제 3GPP message sequence, 물리 topology 또는 상용 계약 절차가 아니다.

1. 요구사항앱·단말·장소·시간·보안·SLS를 해석하고 범위를 합의한다.
2. 설계RAN·TN·CN·현장망, shared/dedicated 자원과 측정 지점을 결정한다.
3. 구축정책·연결·장비·Core·운영 시스템을 구성하고 현장에 통합한다.
4. 검증단말·traffic·coverage·부하·장애 조건을 시험하고 인수 증거를 만든다.
5. 운영품질을 감시하고 변경·용량·incident·정산·고객 조율을 지속한다.

단계는 앞에서 뒤로 한 번만 흐르지 않는다. 검증에서 coverage 부족이 드러나면 설계와 구축으로 돌아간다. 운영 중 생산 line, 단말 수, traffic demand나 coverage가 바뀌면 용량 계획과 slice subnet 구성을 수정할 수 있다. TS 28.530도 서비스 요구 변경과 지리적 capacity demand 변화가 subnet과 TN 변경으로 이어질 수 있음을 다룬다. 반복 상품의 원가는 최초 구축비뿐 아니라 이 되돌림의 빈도와 사람 개입 시간까지 포함해야 한다.

전용 자원은 기본값이 아니라 비용이 큰 선택지다

B2B 요구가 높다고 해서 언제나 별도 Core나 장비가 필요한 것은 아니다. GSMA GST는 shared resource와 dedicated resource를 구분할 수 있게 하고, 5G-ACIA의 NPN 자료도 public network와 통합된 방식부터 더 독립적인 배치까지 여러 선택지를 제시한다. 고객 요구가 기존 공유 자원과 검증된 구성으로 충족된다면 재사용하는 편이 반복성에 유리하다.

반대로 물리적·논리적 분리, data locality, availability, latency, 규제나 운영 통제 요구가 높으면 현장 user plane, 별도 management component, radio·transport 증설 또는 더 독립적인 Core 구성이 필요할 수 있다. 이것은 ‘전용 Core가 우수하다’는 서열이 아니라 요구와 비용의 교환이다. 별도 장비를 넣는 순간 장비 구매만 늘어나는 것이 아니다. 공간·전원·회선, software lifecycle, 보안 patch, 예비품, monitoring, 현장 출동과 교체 책임이 함께 생긴다.

따라서 전용 구성은 영업 문구가 아니라 명시적 option이어야 한다. 어떤 요구에서 shared 구성이 탈락하는지, 전용 구성으로 무엇을 더 보장하는지, 누가 자산을 소유하고 운영하는지, 종료할 때 어떻게 회수하거나 전환하는지를 견적 전에 정해야 한다. 이 경계가 없으면 필요 이상의 CAPEX를 투입하거나, 반대로 필요한 투자를 가격에 반영하지 못할 수 있다.

조율과 운영 조직도 원가다

TS 28.530의 SLA negotiation 절차는 coverage area, 사용자 수와 분포, traffic demand, mobility, latency 같은 SLS를 협의하고 feasibility를 확인하며, RAN·TN·CN과 비 3GPP domain 사이를 조정하는 과정을 보여 준다. 이는 표준이 특정 조직도를 강제한다는 뜻은 아니다. 다만 한 고객의 약속을 여러 기술 영역이 함께 이행해야 하므로 책임과 정보 흐름을 정하지 않으면 사람이 접점을 메우게 된다.

고객 담당자는 생산 업무와 변경 일정을 이해해야 하고, 무선·전송·Core 담당자는 자원과 정책을 맞춰야 한다. 보안 담당자는 인증과 data path 경계를 검토하고, 단말·application 담당자는 traffic 식별과 compatibility를 확인한다. 운영센터는 monitoring과 incident를 처리하고, service manager는 SLS report와 변경 요청, 책임 분쟁을 조정한다. 작은 pilot에서는 몇 사람이 겸임할 수 있지만 고객 수가 늘면 이 역할의 총 시간이 OPEX가 된다.

5G-ACIA의 산업용 SLS 자료도 공장별 SLS가 use case, brownfield 조건, business requirement와 현지 규정에 따라 달라질 수 있으며, 계약·monitoring·운영과 유지보수 책임을 명확히 해야 한다고 설명한다. 필자는 여기서 ‘전담팀이 항상 필수’라고 단정하지 않는다. 대신 표준 지원 조직으로 처리할 수 없는 예외가 몇 건인지, 고객별 회의·설계·시험·보고에 몇 시간이 드는지를 상품 원가에 포함해야 한다고 본다.

과금 기능이 있다고 가격표가 생기지는 않는다

3GPP TS 32.255는 S-NSSAI, DNN, tenant ID 같은 business identifier를 charging 정보에 담고, account·rating·reservation control을 구현할 수 있는 표준 기능을 설명한다. 이것은 사용량과 대상을 식별하고 과금 체계와 연결할 수 있다는 뜻이다. 어떤 가격을 붙여야 하는지, 설계비·장비비·운영비를 누가 지불하는지, 현재 시장에서 수익성이 검증됐는지는 말해 주지 않는다.

반복 가능한 가격 규칙을 만들려면 최소한 다섯 층을 분리해야 한다. 첫째는 요구 분석·설계·현장 통합·인수 시험의 일회성 engineering 비용이다. 둘째는 radio·transport·Core·현장 장비와 license의 CAPEX 및 감가·회수 구조다. 셋째는 monitoring, software 유지, support, 변경, 현장 출동의 반복 OPEX다. 넷째는 capacity와 shared resource를 예약하거나 peak demand에 대비하는 기회비용이다. 다섯째는 약속 불이행과 재작업 가능성을 흡수할 위험 여유와 margin이다.

고객별 견적만 계속 만들면 비용을 누락하기 쉽고 영업 기간도 길어진다. 반대로 모든 것을 단순 월정액 하나에 넣으면 사용량이 적은 고객이 전용 자원 비용을 함께 부담하거나, 고비용 고객을 낮은 가격으로 받아들이게 될 수 있다. 필자가 보는 현실적인 방향은 공통 기반료, SLS·coverage·단말 규모별 등급, 전용 자원 option, 일회성 integration fee, 변경·지원 등급을 분리하는 것이다. 이것은 확인된 현재 통신사 가격표가 아니라 비용을 빠뜨리지 않기 위한 분석 틀이다.

5G-ACIA의 산업용 5G ROI 자료도 use case별 기술·경제 목표와 KPI, 회사별 cost model, 가격 가정의 신중한 평가가 필요하다고 설명한다. 특정 사례의 ROI 숫자를 다른 현장에 그대로 옮길 수는 없다. 서비스 수익이 투자와 운영비를 상회해야 의미가 있다는 원칙은 맞지만, 그 여부는 실제 고객별 demand, 재사용률, 사람 개입, 자산 수명과 계약 기간으로 검증해야 한다.

반복성을 높이는 일은 선택지를 줄이고 증거를 재사용하는 일이다

상품화를 위해 가장 먼저 할 일은 모든 요구를 받아 주는 것이 아니라 지원 범위를 선언하는 것이다. 예를 들어 application traffic profile을 몇 종류로 제한하고, 인증된 단말 목록과 site archetype, coverage 조사 입력, shared/dedicated 구성 option, SLS 등급을 정한다. 각 조합에 reusable design template, capacity rule, configuration package, acceptance test와 monitoring dashboard를 연결한다.

두 번째는 예외의 문턱을 만드는 것이다. 표준 profile로 수용되는 주문은 정해진 절차와 가격 규칙으로 처리한다. 새로운 단말, 특수한 data path, 검증되지 않은 latency·availability, 별도 Core나 현장 장비가 필요하면 표준 주문이 아니라 engineering change로 분류한다. 이때 추가 설계비와 일정, 재검증 범위를 드러내야 한다. 예외를 숨기는 대신 가격과 책임을 분리해야 다음 고객에게 같은 실수를 반복하지 않는다.

세 번째는 증거를 재사용하는 것이다. 단말 인증 결과, site survey 입력, 부하 시험 방법, SLS 측정 정의, 인수 기준, monitoring 항목과 책임 matrix를 template으로 남긴다. 다만 이전 시험 결과를 새로운 현장에 그대로 적용해서는 안 된다. 무엇이 동일해야 재사용할 수 있는지와 현장별로 다시 확인할 항목을 함께 적어야 한다. 반복성은 검증을 없애는 것이 아니라 공통 검증과 현장 검증의 경계를 안정시키는 데서 생긴다.

이때 필자는 상품 책임자가 판매 건수 외의 운영 지표도 봐야 한다고 본다. 표준 profile 안에서 끝난 주문 비율, 기존 configuration과 test evidence를 재사용한 비율, 고객별 설계·회의·현장 작업 시간, activation까지 걸린 기간, 운영 중 change request 수를 함께 기록하면 어느 예외가 원가를 키우는지 드러난다. 예외가 반복되면 다음 catalogue option으로 승격할지, 계속 별도 project로 남길지 결정할 수 있다. 반대로 한 고객에게만 필요한 기능이라면 반복 매출을 기대해 공통 platform에 서둘러 넣지 않는 편이 비용 경계를 지키는 방법이다.

AI를 활용해 요구사항 분류, 구성 추천, 시험 자동화, 이상 탐지와 운영 보조를 줄일 가능성은 있다. 그러나 어떤 업무를 자동화할 수 있고, 데이터·오류·책임 경계를 어떻게 검증할지는 별도의 후속 검토 대상이다. 이 글에서는 AI가 고객 인수 기준, 현장 검증, 변경 승인이나 운영 책임을 자동으로 대신한다고 결론 내리지 않는다.

맞춤형 기술을 팔려면 맞춤의 한계를 먼저 상품화해야 한다

B2B Network Slicing이 반복 가능한 상품이 되기 어려운 이유는 고객 요구가 많다는 한 문장으로 끝나지 않는다. 애플리케이션·단말·장소·시간·보안·SLS의 차이가 설계 선택을 바꾸고, 그 선택이 구축 자원과 검증 범위를 바꾸며, 다시 운영 조직과 CAPEX/OPEX, 가격 규칙을 바꾼다. 이 연결을 끊어 보이면 한 번의 기술 성공을 반복 매출로 오해하게 된다.

필자는 표준 상품과 고객별 프로젝트 사이에 명확한 선을 긋는 것이 출발점이라고 본다. 공통 profile과 검증된 조합은 반복 판매하고, 별도 Core·장비·특수 SLS·새 단말과 현장 통합은 선택적 engineering으로 가격과 일정을 드러낸다. 그리고 주문 수보다 공통 구성 재사용률, 고객별 사람 개입 시간, 검증 반복률, 운영 OPEX와 실제 수익을 함께 본다. 기술을 덜 맞춤화하자는 말이 아니다. 어떤 맞춤을 같은 방식으로 다시 제공할 수 있는지 증명해야 비로소 프로젝트가 상품으로 바뀐다.