5G 코어의 서비스 기반 인터페이스(SBI)를 문제 해결할 때 많은 엔지니어가 같은 문제에 부딪힙니다. AMF가 SMF로 보내는 요청 본문에 SUPI, DNN, S-NSSAI, TAI, PDU Session ID, 5QI 같은 익숙한 필드가 포함되어 있어도 그 메시지가 실제로 유효한지 판단하기는 여전히 쉽지 않습니다. 필드는 문자열로 인코딩해야 할까요, 정수로 인코딩해야 할까요? 정해진 값 범위가 있을까요? 아무 값이나 사용할 수 있을까요, 아니면 미리 정의된 열거값 중에서 선택해야 할까요? 객체 안에 다른 중첩 파라미터를 포함할 수 있을까요?

이러한 질문의 답을 정하는 것이 SBI 공통 데이터 타입입니다. 서비스 기반 인터페이스는 AMF, SMF, UDM, PCF, NRF 같은 네트워크 기능을 아우르지만, 많은 기본 파라미터는 특정 NF 하나에만 속하지 않습니다. 각 서비스가 이 값을 제각각 정의한다면 규격에 불필요한 중복이 생기고, 같은 가입자 식별자나 QoS 파라미터가 API마다 다르게 표현될 수 있습니다. 따라서 SBI 트래픽을 분석할 때는 HTTP 메서드와 리소스 URI만 확인해서는 충분하지 않습니다. HTTP/2는 요청을 어떻게 전송할지 정의하고, JSON은 데이터를 어떻게 표현할지 정의하며, 공통 데이터 타입은 더 근본적인 질문인 각 JSON 파라미터가 어떤 형식과 검증 규칙을 따라야 하는지를 정의합니다.

공통 데이터 타입은 어떤 문제를 해결하는가?

공통 데이터 타입은 전체 5GC 서비스 기반 API 환경이 공유하는 하나의 “데이터 어휘”로 볼 수 있습니다. 어떤 데이터 타입은 AMF 요청에 나타나면서 동시에 SMF, UDM, PCF에서도 참조될 수 있습니다. 특정 인터페이스 하나에 속하는 것이 아니라 여러 서비스에서 재사용할 수 있는 표준화된 정의를 제공합니다.

IPv4 주소를 예로 들어 보겠습니다. 각 NF가 주소를 문자열로 표현하는 방식을 따로 정의해서는 안 됩니다. MCC와 MNC에 정해진 길이와 형식이 있는 PLMN 정보도 마찬가지이며, SUPI, GPSI, PEI 같은 가입자 및 장비 식별자도 각각 고유한 인코딩 규칙을 따릅니다. 일관된 정의가 있어야 서로 다른 NF 사이의 RESTful API가 정보를 안정적으로 교환할 수 있습니다.

공통 데이터 타입은 NF 전용 타입과도 구분해야 합니다. 공통 타입은 여러 인터페이스에 반복해서 나타나는 객체를 다루고, 특정 네트워크 기능에만 고유한 업무 객체는 해당 29 계열 규격에 정의됩니다. 실제로 하나의 SBI API가 두 종류의 데이터 타입을 모두 참조하는 경우가 많습니다.

적용 범위는 네트워크 주소보다 훨씬 넓습니다. 공통 정의에는 일반 파라미터, 가입 및 식별 정보, 5G 네트워크 데이터, QoS, 과금, 추적 정보와 기타 재사용 가능한 객체가 포함됩니다. 이들이 함께 SBI 메시지 파라미터의 기반 데이터 모델을 구성합니다.

세 가지 기본 데이터 구조는 어떻게 다른가?

구조적인 관점에서 SBI 파라미터는 일반적으로 단순 데이터 타입, 열거 타입, 구조화 데이터 타입의 세 범주로 나눌 수 있습니다. 개별 파라미터 이름을 외우는 것보다 이 세 범주를 이해하는 편이 훨씬 실용적입니다. Wireshark 캡처, API 문서, OpenAPI 정의에서 보게 되는 대부분의 필드가 이 모델에 들어맞기 때문입니다.

단순 데이터 타입은 가장 낮은 수준의 기본 구성 요소입니다. 문자열, 정수, 숫자, 날짜, 날짜-시간, 불리언 등이 포함됩니다. 5GC에서는 이러한 기본 타입에 값 범위, 인코딩 형식, 정규식 패턴과 같은 추가 제약 조건이 함께 적용되는 경우가 많습니다.

예를 들어 IPv4 주소는 기술적으로 문자열로 표현되지만, 아무 문자열이나 유효한 것은 아닙니다. 정해진 IPv4 형식을 따라야 합니다. IPv6 주소, IPv6 프리픽스, MAC 주소도 각각 고유한 형식 요건이 있습니다. Uint16, Uint32, Uint64는 부호 없는 정수의 값 범위를 정의합니다. URI는 URI 형식 규칙을 따라야 하고, DateTime 값은 지정된 날짜-시간 형식을 사용해야 합니다.

규격에서는 Ipv4AddrRm, DateTimeRm, Uint32Rm처럼 Rm 접미사가 붙은 타입도 자주 정의합니다. 이 타입들은 대응되는 기본 타입과 같은 하위 형식을 사용하지만 OpenAPI의 nullable 속성을 포함하므로 필드가 null 값을 가질 수 있습니다.

열거 타입은 선택형 필드처럼 동작합니다. 값은 미리 정의된 집합에서 선택해야 합니다. 예를 들어 AccessType은 3GPP_ACCESS와 NON_3GPP_ACCESS를 구분합니다. PduSessionType은 IPV4, IPV6, IPV4V6, UNSTRUCTURED, ETHERNET 등의 값을 가질 수 있습니다. CoreNetworkType은 5GC 또는 EPC를 나타낼 수 있습니다.

열거의 목적은 모호성을 없애는 것입니다. 소비 측에서는 비슷한 뜻이라는 이유로 임의의 문자열을 만들어 사용할 수 없고, 규격에 명시된 값 중 하나를 사용해야 합니다. 문제 해결 과정에서 자주 보는 상황도 바로 이것입니다. 필드 이름은 맞지만 열거값이 유효하지 않아 API가 요청을 거부하거나 잘못 해석하는 경우입니다.

구조화 데이터 타입은 여러 속성을 하나의 완전한 객체로 결합합니다. 각 속성은 다시 단순 타입, 열거 타입 또는 다른 구조화 객체를 참조할 수 있어 계층형 모델을 만듭니다.

ProblemDetails가 대표적인 예입니다. type, title, status, detail, instance, cause, invalidParams 같은 필드를 포함할 수 있습니다. TAI도 PLMN ID와 TAC를 결합한 구조화 객체입니다. GUAMI는 한 단계 더 나아가 PLMN ID와 AMF ID를 결합합니다. 이 단계에서는 SBI 분석을 개별 필드만으로 할 수 없으며 객체 내부 속성 간의 관계도 함께 봐야 합니다.

식별 및 네트워크 파라미터는 어떻게 구성되는가?

실제 패킷 캡처에서는 가입, 식별, 5G 네트워크 관련 데이터가 가장 흔한 SBI 파라미터에 속합니다. SUPI는 가입자를 식별하고, GPSI는 외부 가입자 식별자, PEI는 영구 장비 식별자를 나타냅니다. DNN은 데이터 네트워크를 식별하고, NF Instance ID는 특정 NF 인스턴스를 고유하게 식별합니다.

이들 대부분은 단순한 문자열처럼 보이지만 핵심은 문자열 내부의 인코딩 규칙입니다. SUPI에는 IMSI 또는 NAI 표현이 들어갈 수 있고, GPSI에는 MSISDN 또는 External Identifier가 들어갈 수 있습니다. 다시 말해 문자열로 정의되었다고 해서 아무 문자열이나 유효한 것은 아닙니다.

5G 네트워크 관련 타입은 이러한 기본 식별자를 바탕으로 세션과 위치 정보를 표현합니다. PduSessionId는 PDU Session을 식별합니다. MCC와 MNC는 PLMN 식별 정보의 일부를 구성합니다. TAC는 Tracking Area Code를 나타내고 NrCellId와 EutraCellId는 각각 NR 셀과 E-UTRA 셀을 식별합니다.

구조화 객체는 이러한 기본 파라미터를 더 높은 수준의 데이터 모델로 결합합니다. S-NSSAI는 SST와 선택적 SD를 사용해 네트워크 슬라이스를 표현합니다. TAI는 PLMN ID와 TAC를 결합합니다. NCGI는 PLMN ID와 NR Cell ID를 결합해 NR 셀을 식별하며, ECGI는 E-UTRA에서 비슷한 역할을 합니다.

UserLocation은 더 높은 수준의 추상화입니다. 접속 유형에 따라 NR Location, E-UTRA Location 또는 Non-3GPP Access Location을 포함할 수 있습니다. NR Location 자체도 TAI, NCGI, 위치 타임스탬프, 지리 정보를 포함할 수 있습니다.

이는 SBI 데이터 모델의 모듈형 설계를 보여 줍니다. MCC, MNC, TAC, Cell ID 같은 기본 요소를 먼저 표준화한 뒤 PLMN ID, TAI, NCGI, UserLocation 같은 상위 객체로 결합합니다. 각 서비스가 전체 위치 파라미터 집합을 다시 정의할 필요 없이 API가 이 객체들을 그대로 재사용할 수 있습니다.

QoS, 과금, 추적 데이터도 왜 표준화해야 하는가?

SBI 트래픽은 가입자 식별자와 네트워크 위치만 전달하는 것이 아닙니다. QoS 정책, 사용량 정보, 네트워크 추적 데이터도 여러 NF 사이를 오가므로 이 값들 역시 일관된 데이터 정의가 필요합니다.

QoS 파라미터 중 QFI는 QoS Flow를 식별하고, 5QI는 5G QoS Identifier를 나타냅니다. BitRate는 값과 단위로 전송률을 나타내며, Packet Delay Budget은 지연 예산을, Packet Error Rate와 Packet Loss Rate는 전송 품질을 설명합니다.

QoS 정책에서도 다양한 열거 타입이 사용됩니다. PreemptionCapability는 어떤 서비스가 다른 곳에 할당된 자원을 선점할 수 있는지를 나타냅니다. PreemptionVulnerability는 기존 자원이 더 높은 우선순위 서비스에 의해 회수될 수 있는지를 나타냅니다. QosResourceType은 NON_GBR, NON_CRITICAL_GBR, CRITICAL_GBR 등의 값을 구분합니다.

이러한 기본 필드는 ARP, AMBR, Dynamic 5QI, Non-Dynamic 5QI 같은 구조화 객체로 결합됩니다. 이를 통해 SMF, PCF 및 관련 네트워크 기능은 우선순위, 비트 전송률, 지연, 선점 동작 같은 개념을 동일한 방식으로 교환할 수 있습니다.

과금 데이터도 같은 설계 원칙을 따릅니다. ChargingId, RatingGroup, ServiceId는 비교적 단순한 데이터 타입이고, QoSFlowUsageReport에는 QFI, 수집 시작·종료 타임스탬프, 상향·하향 트래픽량이 포함될 수 있습니다. VolumeTimedReport는 정해진 시간 구간 동안의 PDU Session 사용량을 나타낼 수 있습니다.

추적 관련 타입은 네트워크 추적 정보를 표준화합니다. TraceDepth는 열거값을 사용해 서로 다른 추적 수준을 표현하고, TraceData는 Trace Reference, Trace Depth, NE Type 등의 파라미터를 결합합니다. 이를 통해 각 NF가 서로 호환되지 않는 자체 추적 필드 세트를 정의하는 것을 막습니다.

이러한 예는 공통 데이터 타입이 단순히 “몇 개의 JSON 필드”만 표준화하는 것이 아니라, 서로 다른 코어 네트워크 서비스가 동일한 업무 및 네트워크 개념을 어떻게 이해할지를 표준화한다는 점을 보여 줍니다. QoS, 위치, 과금 정보, 가입자 식별자가 여러 NF 사이를 이동해야 한다면 먼저 일관된 데이터 모델이 필요합니다.

실제 문제 해결에서 데이터 타입을 어떻게 활용할 수 있는가?

흔한 엔지니어링 실수 중 하나는 JSON 메시지에서 필드가 존재하는지만 확인하고 데이터 타입과 관련 제약 조건은 확인하지 않는 것입니다. 더 효과적인 방법은 HTTP 계층과 데이터 모델을 함께 살펴보는 것입니다.

먼저 호출되는 서비스와 리소스 URI를 확인합니다. 다음으로 요청 또는 응답 본문에서 대상 필드를 찾습니다. 필드를 찾은 뒤에는 값 자체에서 멈추지 말고, 어떤 데이터 타입을 참조하는지, 필수인지 선택인지, Cardinality가 무엇인지, 열거형인지, Format 또는 Pattern 제한이 있는지 확인해야 합니다.

IPv4 필드가 사람이 보기에는 IP 주소처럼 보여도 정의된 형식을 충족하지 않으면 유효하지 않은 입력입니다. 마찬가지로 PduSessionType 값이 일반 언어로는 이해되더라도 지정된 열거값 중 하나가 아니라면 API 정의에 맞지 않습니다.

구조화 데이터는 재귀적으로 확장해 확인해야 합니다. UserLocation이 나타나면 객체에 NR, E-UTRA 또는 Non-3GPP 위치 정보 중 무엇이 포함되어 있는지 확인합니다. TAI가 나타나면 PLMN ID와 TAC를, S-NSSAI가 나타나면 SST와 선택적 SD를 확인합니다. 타입 참조를 계층별로 따라가야 JSON 객체가 API 모델에 맞는지 판단할 수 있습니다.

서버가 요청을 거부할 때는 ProblemDetails도 자세히 확인할 가치가 있습니다. HTTP 상태 코드 외에도 detail, cause, invalidParams 정보를 제공할 수 있습니다. 이 필드가 있다면 일반적인 HTTP 4xx 응답에서 멈추지 않고 API 요구사항을 위반한 구체적인 파라미터부터 문제 해결을 시작할 수 있습니다.

파라미터 표를 외우는 것보다 데이터 모델 관점이 더 유용한 이유는?

5GC SBI 공통 데이터 타입의 수가 많기 때문에 모든 필드, 정규식, 값 범위를 외우는 방식은 금방 비효율적이 됩니다. 더 나은 방법은 데이터 모델 관점을 갖는 것입니다. 단순 타입은 가장 작은 데이터 단위를 정의하고, 열거 타입은 허용되는 상태를 제한하며, 구조화 타입은 이런 단위를 결합해 5GC 서비스가 직접 사용할 수 있는 객체를 만듭니다.

이 관점에서는 SUPI, MCC, TAC, QFI가 더 이상 고립된 파라미터가 아닙니다. 가입자, 위치, 세션, QoS, 과금, 추적 모델을 구성하는 기본 요소가 됩니다. 서로 다른 NF가 SBI를 통해 서비스를 일관되게 호출할 수 있는 이유 중 하나는 이러한 공통 타입이 안정적이고 재사용 가능한 데이터 의미 체계를 제공하기 때문입니다.

따라서 익숙하지 않은 5GC API를 읽을 때 첫 질문은 “이 메시지에 필드가 몇 개인가?”가 아니라, 각 필드가 어떤 타입을 참조하는지, 객체가 어떻게 중첩되는지, 어떤 제약이 최종 JSON의 유효성을 결정하는지여야 합니다. 이 방법에 익숙해지면 처음 보는 SBI 서비스라도 완전히 새로운 파라미터 표를 외우지 않고 OpenAPI와 데이터 타입 정의를 계층별로 따라가며 분석할 수 있습니다.

자주 묻는 질문

SBI 공통 데이터 타입을 정의하는 3GPP 규격은 무엇인가?

주로 TS 29.571, 5G System; Common Data Types for Service Based Interfaces에 정의되어 있습니다. 이 규격은 SBI 서비스 사이에서 공유되는 재사용 가능한 데이터 구조를 정의합니다. NF 전용 서비스와 데이터 타입은 SMF 서비스의 TS 29.502, UDM 서비스의 TS 29.503처럼 해당 29.5xx 규격에 정의됩니다.

OpenAPI의 nullable 속성은 실제 JSON 메시지에서 어떻게 나타나는가?

nullable로 정의된 필드는 보통 Rm 접미사가 붙은 타입을 통해 JSON 본문에 명시적으로 null 값을 포함할 수 있으며, 이는 현재 유효한 값이 할당되지 않았음을 뜻합니다. 이는 필드 자체가 완전히 없는 것과 다릅니다. 필드가 없으면 해당 파라미터가 적용되지 않거나 제공되지 않았다는 뜻일 수 있고, 명시적인 null은 이전에 설정된 값을 지우는 것처럼 특정한 의미를 가질 수 있습니다.

SBI 공통 데이터 타입은 벤더마다 달라질 수 있는가?

정의 자체는 규격 수준에서 표준화되어 있지만 실제 제품에서는 구현 차이가 나타날 수 있습니다. 일부 벤더는 선택 필드의 일부만 구현할 수 있고, 특정 API에는 벤더 전용 확장이 포함될 수 있으며, 열거값 검증의 엄격성도 달라질 수 있습니다. 이러한 차이는 상호운용성 시험에서 자주 확인하는 항목입니다.

필드가 공통 타입인지 NF 전용 타입인지 빠르게 구분하는 방법은?

가장 직접적인 방법은 OpenAPI 정의에서 $ref 경로를 확인하는 것입니다. 참조가 TS 29.571에 정의된 공통 schema를 가리키면 일반적으로 공유 SBI 데이터 타입입니다. 현재 서비스 규격 내부에 정의된 schema를 가리키면 대체로 NF 전용 타입입니다. SUPI, TAI, S-NSSAI, ProblemDetails처럼 자주 재사용되는 타입을 알고 있으면 패킷 분석에서도 더 쉽게 식별할 수 있습니다.

패킷 캡처에서 Rm 타입과 일반 타입은 어떻게 다른가?

값이 null이 아닌 경우 두 타입 모두 같은 기반 형식을 사용하므로 JSON 표현은 사실상 동일합니다. 차이는 OpenAPI 모델 수준에 있습니다. Rm 타입은 필드가 null을 포함할 수 있게 합니다. 캡처된 필드가 명시적으로 null 값을 가지면 nullable 정의를 사용하고 있다고 볼 수 있습니다. 반대로 정상적인 유효값이 들어 있으면 그 값만으로 schema가 일반 타입을 참조하는지 대응되는 Rm 타입을 참조하는지 판단할 수 없습니다.