5GC SBI는 왜 HTTP/2 서비스 호출을 중심으로 구성되는가?

5G 코어가 서비스 기반 아키텍처를 채택하면서 네트워크 기능 간 관계는 크게 바뀌었습니다. AMF, SMF, UDM, PCF, NSSF, AUSF 같은 기능은 더 이상 고정된 점대점 프로토콜 인터페이스를 통해서만 메시지를 교환하지 않습니다. 대신 각 NF가 자신의 기능을 서비스 형태로 제공하고, 다른 네트워크 기능이 필요할 때 이를 사용합니다.

이 모델에서는 한 NF가 다른 NF에서 리소스를 조회하거나, 새로운 컨텍스트를 생성하고, 기존 리소스를 갱신하거나, 더 이상 필요하지 않은 리소스를 삭제할 수 있습니다. 통신 패턴은 자연스럽게 요청 → 리소스 작업 → 응답 형태가 됩니다. HTTP 메서드, URI, 상태 코드, JSON은 이러한 서비스 상호작용을 표현하는 실용적인 방법을 제공합니다.

간단한 SBI 프로토콜 스택은 다음과 같이 나타낼 수 있습니다.

애플리케이션/JSON → HTTP/2 → TCP → IP → Ethernet

JSON은 애플리케이션 데이터를 어떻게 표현할지를 정의합니다. HTTP/2는 요청과 응답을 전송하기 위해 구성합니다. TCP는 신뢰성 있는 전달을 제공하고, IP는 주소 지정과 라우팅을 담당하며, Ethernet은 하위 네트워크에서 프레임을 운반합니다.

이는 N2, N3, N4 같은 인터페이스와 상당히 다릅니다. N2는 NGAP, N4는 PFCP를 사용하고 사용자 평면에서는 일반적으로 GTP-U를 사용합니다. 서비스 기반 인터페이스는 서비스 통신의 전송 프레임워크로 HTTP/2를 사용합니다. 이는 단순한 프로토콜 교체가 아니라, 미리 정의된 인터페이스 메시지를 교환하는 방식에서 서비스를 호출하는 방식으로 바뀐 5GC 설계 철학을 반영합니다.

예를 들어 AMF가 특정 가입자의 접속 관리 가입 데이터를 필요로 하면, AMF는 NF 소비자로 동작하고 NF 제공자 역할을 하는 UDM에 리소스를 요청합니다. 소비자는 주로 어떤 리소스에 접근할지, 어떤 작업을 수행할지, 어떤 결과가 반환되는지를 알면 됩니다. 개별 서비스 절차마다 완전히 별도의 전송 메커니즘을 설계할 필요가 없습니다.

HTTP/2는 이러한 환경에서 매우 실용적인 장점도 제공합니다. 여러 서비스 요청이 하나의 TCP 연결을 공유할 수 있습니다. 네트워크 기능 간 SBI 상호작용은 자주 발생하기 때문에, API 호출마다 새 TCP 연결을 반복해서 설정하면 불필요한 연결 관리 오버헤드가 발생합니다.

HTTP/2는 HTTP/1.1과 비교해 어떤 전송 문제를 해결하는가?

HTTP/2가 HTTP/1.1의 전체 애플리케이션 모델을 대체한 것은 아닙니다. GET, POST 같은 메서드는 그대로 존재하고 기본적인 요청-응답 모델도 같습니다. 주요 변화는 데이터를 구성하고 전송하는 방식에 있습니다.

5GC에서 중요한 것은 웹페이지를 더 빨리 불러오는 것이 아닙니다. 핵심 가치는 HTTP/2가 네트워크 기능 사이에서 대량으로 발생하는 동시 API 호출에 더 효율적인 연결 모델을 제공한다는 점입니다.

하나의 연결이 여러 Stream을 동시에 운반할 수 있다

HTTP/1.1은 지속 연결을 지원하지만 하나의 연결에서 동시 처리하는 데에는 여전히 한계가 있습니다. 전통적인 많은 환경에서는 병렬 처리를 늘리기 위해 여러 TCP 연결을 열며, 이는 클라이언트와 서버 양쪽 모두에 연결 관리 오버헤드를 추가합니다.

HTTP/2는 멀티플렉싱을 도입합니다. 하나의 TCP 연결 안에 여러 독립적인 Stream이 동시에 존재할 수 있습니다. 새 요청은 이전 트랜잭션이 완전히 끝날 때까지 기다릴 필요가 없습니다. 여러 Stream의 Frame이 동일한 연결 위에서 교차되어 전송될 수 있습니다.

5GC SBI 환경에서 AMF가 다른 NF와 HTTP/2 연결을 설정한 뒤에도 그 연결은 한 번에 하나의 API 요청만 처리하는 데 제한되지 않습니다. 여러 서비스 작업이 서로 다른 Stream을 사용할 수 있으며, 각 Stream은 자체 요청과 응답을 운반합니다.

TCP 연결 수가 줄어들면 연결 관리 오버헤드도 감소하므로, 5G 코어 네트워크 기능 사이에서 자주 발생하는 서비스 상호작용에 적합합니다.

HTTP 메시지는 바이너리 Frame으로 전송된다

HTTP/1.x는 대체로 텍스트 지향적입니다. 요청 줄, 헤더, 메시지 본문은 명확한 텍스트 구조로 표현됩니다. HTTP/2는 전송 형식을 바꾸고 프로토콜 정보를 바이너리 Frame으로 운반합니다.

HTTP 헤더는 보통 HEADERS Frame에 실리고, 실제 애플리케이션 페이로드는 DATA Frame에 실릴 수 있습니다. 수신 측은 Frame 헤더에 있는 정보, 특히 Stream Identifier를 사용해 특정 Frame이 어느 Stream에 속하는지 판단한 다음 완전한 HTTP 메시지로 재구성합니다.

그래서 Wireshark에서 HTTP/2를 캡처하면 하나의 완전한 HTTP 텍스트 블록처럼 보이지 않는 경우가 많습니다. 대신 HEADERS, DATA, 기타 Frame 유형이 연속해서 나타납니다.

반복되는 헤더를 매번 전체 전송할 필요는 없다

SBI API 트래픽에서는 HTTP 헤더가 반복적으로 나타납니다. 모든 요청이 같은 헤더 필드를 매번 전체 형태로 전송한다면 중복 오버헤드는 빠르게 커집니다.

HTTP/2는 헤더 압축에 HPACK을 사용합니다. 간단히 말하면 양쪽이 헤더 테이블을 유지하여 자주 반복되는 필드를 매번 전체 텍스트로 다시 보내는 대신 인덱스로 표현할 수 있습니다.

헤더가 많이 반복될수록 압축 효과도 커집니다. 네트워크 기능이 비슷한 API를 반복해서 호출하면 메서드, 경로, 공통 헤더 같은 필드가 계속 등장하므로 HPACK은 중복 전송을 줄이는 데 특히 효과적입니다.

HTTP/2는 Server Push도 정의한다

HTTP/2에는 Server Push 메커니즘이 포함되어 있고 PUSH_PROMISE Frame이 정의되어 있습니다. 이를 통해 클라이언트가 관련 리소스를 하나씩 명시적으로 요청하기 전에 서버가 먼저 제공할 수 있습니다.

다만 5GC SBI를 이해할 때 Server Push가 가장 중요한 개념은 아닙니다. 실제 SBI 분석에서는 연결 재사용, 멀티플렉싱, Stream, Frame, 헤더 압축, API 요청-응답 모델이 훨씬 중요합니다.

Connection, Stream, Message, Frame은 어떻게 이해해야 하는가?

HTTP/2에서 혼동하기 쉬운 부분 중 하나는 Connection, Stream, Message, Frame이라는 용어가 함께 등장한다는 점입니다. 각각을 따로 외우기보다 계층 관계로 이해하는 것이 훨씬 쉽습니다.

Connection은 기반이 되는 TCP 연결입니다. TCP 세션이 설정되면 HTTP/2 트래픽은 이 연결을 통해 전송됩니다.

Stream은 Connection 내부의 논리적 양방향 채널입니다. 각 Stream에는 고유한 정수 식별자가 있습니다. 하나의 TCP 연결 안에 여러 Stream이 동시에 존재할 수 있으며, 이것이 HTTP/2 멀티플렉싱의 기반입니다.

Message는 논리적인 HTTP 요청 또는 응답을 나타냅니다. 예를 들어 AMF가 UDM에 GET 요청 Message를 보내면 UDM이 해당 응답 Message를 반환할 수 있습니다.

Frame은 HTTP/2가 실제 전송에 사용하는 더 작은 단위입니다. 하나의 Message는 하나 이상의 Frame으로 구성될 수 있습니다. 대표적인 예는 다음과 같습니다.

• HEADERS Frame: HTTP 헤더 정보를 운반합니다.

• DATA Frame: 애플리케이션 페이로드 데이터를 운반합니다.

• 기타 Frame 유형: 연결 관리, 흐름 제어 및 기타 HTTP/2 기능을 지원합니다.

관계는 다음과 같이 정리할 수 있습니다.

하나의 Connection에는 여러 Streams가 포함됩니다. Stream은 요청과 응답 Messages를 운반하며, 각 Message는 하나 이상의 Frames로 구성됩니다.

HTTP/2 Frame 헤더에는 Length, Type, Flags, 예약 비트, Stream Identifier 같은 필드가 포함됩니다. Stream Identifier는 해당 Frame이 어느 논리 Stream에 속하는지 수신 측에 알려 주기 때문에 특히 중요합니다.

여러 Streams의 Frames가 교차된 순서로 도착해도 수신 측은 Stream ID를 이용해 올바른 데이터를 연결하고 재조립할 수 있습니다. 이것이 HTTP/2가 하나의 TCP 연결에서 여러 동시 트랜잭션을 효율적으로 운반할 수 있게 하는 핵심 메커니즘입니다.

5G 코어 엔지니어에게 이 개념은 패킷 분석에서 특히 중요합니다. 캡처 파일에서 패킷이 서로 인접해 있다는 이유만으로 SBI 트래픽을 같은 트랜잭션으로 묶어서는 안 됩니다. Stream ID, URI, HTTP 메서드, 응답 상태를 함께 봐야 합니다.

JSON과 RESTful API는 어떻게 5GC 기능을 리소스로 만드는가?

HTTP/2가 답하는 것은 서비스 트래픽을 어떻게 효율적으로 전송할 것인가라는 문제입니다. 5GC SBI의 애플리케이션 모델을 실제로 정의하는 것은 RESTful API와 리소스 지향 설계의 결합입니다.

REST는 아키텍처 스타일입니다. 핵심 개념 중 하나는 비즈니스 객체를 리소스로 표현하고, 각 리소스에 고유한 URI를 부여한 다음, HTTP 메서드로 해당 리소스에 작업을 수행하는 것입니다.

5GC에서 “리소스”는 웹사이트와 관련된 일반적인 객체에만 한정되지 않습니다. 가입자 데이터, SM Context, PDU Session 관련 객체 또는 네트워크 기능이 유지하는 다른 상태를 나타낼 수 있습니다.

예를 들어 특정 가입자의 접속 관리 가입 데이터에는 하나의 URI를, 세션 관리 가입 데이터에는 다른 URI를 사용할 수 있습니다. 소비자 관점에서 작업은 더 이상 단순히 다음과 같은 형태가 아닙니다.

“특정 UDM 시그널링 절차를 호출한다.”

대신 다음과 같이 바뀝니다.

특정 리소스에 GET, POST, PUT/PATCH 또는 DELETE 작업을 수행한다.

HTTP 메서드는 리소스에 어떤 작업을 할지 정의한다

일반적인 작업은 다음과 같이 이해할 수 있습니다.

• GET: 리소스를 조회하거나 읽습니다.

• POST: 리소스를 생성하거나 정의된 작업을 호출합니다.

• PUT / PATCH: 기존 리소스를 갱신합니다.

• DELETE: 리소스를 삭제합니다.

서버는 요청을 처리한 뒤 결과를 나타내는 HTTP 상태 코드를 반환합니다.

200 응답은 일반적으로 처리가 성공했고 데이터가 반환되었음을 나타냅니다. 201 응답은 보통 리소스가 성공적으로 생성되었음을 의미합니다. 204 응답은 응답 본문 없이 작업이 성공했음을 나타낼 수 있습니다. 4xx 응답은 주로 요청, 리소스 또는 권한 문제를 의미하며, 5xx 응답은 일반적으로 서버 측 처리 문제를 나타냅니다.

이 상태 코드는 5GC 장애 분석에서 매우 유용합니다. HTTP/2 연결이 설정되었다고 해서 서비스 작업 자체가 성공한 것은 아닙니다. 요청한 URI, HTTP 메서드, NF 제공자가 반환한 상태 코드를 계속 확인해야 합니다.

JSON은 실제 비즈니스 데이터를 운반한다

SBI 애플리케이션 페이로드는 일반적으로 JSON으로 표현됩니다. JSON은 키-값 구조에 기반한 가벼운 데이터 교환 형식으로 문자열, 숫자, 불리언 값, 배열, 객체, 중첩 데이터 구조를 표현할 수 있습니다.

즉 HTTP/2의 DATA Frame은 페이로드를 운반하고, 그 Frame 안의 JSON이 애플리케이션 데이터의 실제 의미를 정의합니다.

엔지니어링 관점에서 HTTP/2와 JSON을 같은 프로토콜 계층으로 봐서는 안 됩니다. HTTP/2는 전송을 구성하고, JSON은 애플리케이션 데이터를 표현하며, RESTful API는 리소스와 그 리소스에 수행할 수 있는 작업을 정의합니다.

5GC SBI 리소스 URI는 어떻게 구성되는가?

리소스 개념을 이해하면 SBI URI의 구조도 훨씬 쉽게 이해할 수 있습니다. 리소스 경로는 임의로 정해지는 것이 아니라 구조화된 계층을 따릅니다.

일반적인 형식은 다음과 같이 나타낼 수 있습니다.

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

각 부분에는 명확한 역할이 있습니다.

• apiRoot: 서비스에 접근하기 위한 루트 주소로, 보통 http(s)://host(:port) 형식입니다.

• apiName: 네트워크 기능이 제공하는 특정 SBI API 또는 서비스 이름입니다.

• apiVersion: API 버전으로, 예를 들면 v1입니다.

• apiSpecificResourceUriPart: 특정 리소스 또는 작업을 식별하는 경로입니다.

예를 들어 접속 관리 가입 데이터와 세션 관리 가입 데이터는 모두 UDM에서 제공될 수 있지만 서로 다른 리소스 경로를 사용합니다. 따라서 URI를 보면 소비자가 정확히 어떤 리소스를 요청하는지 명확히 확인할 수 있습니다.

SMF의 PDU Session 서비스도 같은 기본 개념을 따릅니다. 서로 다른 SM Contexts와 PDU Session 관련 리소스는 각각 고유한 URI를 가지며, 생성, 조회, 변경, 해제에는 서로 다른 HTTP 메서드가 사용됩니다.

이런 리소스 지향 설계는 엔지니어가 SBI 인터페이스를 바라보는 방식을 바꿉니다. “Message A → Message B” 같은 전통적인 순서만 외우는 대신, SBI 상호작용을 다음처럼 분석할 수 있습니다.

서비스 → 리소스 → 메서드 → URI → 상태 코드 → JSON 본문

요청 메시지 이름과 응답 메시지 이름을 맞추는 전통적인 통신 방식만으로 5GC SBI를 보면 아키텍처가 단편적으로 느껴질 수 있습니다. 이를 API 기반 리소스 모델로 보면 논리가 훨씬 명확해집니다.

Wireshark에서 SBI 트랜잭션을 어떻게 추적해야 하는가?

HTTP/2 개념을 이해한 뒤에는 이를 실제 패킷 분석에 적용해야 합니다. 하나의 TCP 연결이 여러 HTTP/2 Streams를 동시에 운반할 수 있으므로, 송신 IP와 수신 IP만으로 필터링하면 서로 관련 없는 여러 SBI 트랜잭션이 같은 캡처 안에 섞여 남을 수 있습니다.

실용적인 방법은 먼저 NF 소비자와 NF 제공자의 IP 주소를 확인하고, 그다음 관련 Stream ID로 분석 범위를 좁히는 것입니다.

예를 들어 특정 요청이 Stream ID 1을 사용한다면 서버 주소와 해당 Stream ID를 함께 사용해 대응하는 요청-응답 트랜잭션에 속한 Frames만 분리할 수 있습니다.

트래픽을 필터링한 뒤에는 다음 정보를 중점적으로 확인합니다.

• Stream ID: Frames가 같은 논리 Stream에 속하는지 확인합니다.

• HEADERS: HTTP 메서드, Path, 기타 헤더 필드를 확인합니다.

• DATA: 트랜잭션에 JSON 애플리케이션 페이로드가 포함되어 있는지 확인합니다.

• 상태 코드: NF 제공자가 요청을 어떻게 처리했는지 나타냅니다.

• URI: 실제로 접근한 서비스, API 버전, 리소스를 식별합니다.

효율적인 장애 분석은 전송 계층에서 시작해 위로 올라가는 방식입니다. 먼저 TCP 연결이 설정되었는지 확인합니다. TCP가 동작하지 않으면 HTTP/2나 RESTful API 통신의 기반 자체가 없습니다.

다음으로 HTTP/2 계층에 정상적인 HEADERS와 DATA Frames가 있는지 확인하고, Stream ID를 이용해 올바른 트랜잭션과 연결합니다.

그다음 HTTP 메서드와 URI가 예상한 작업과 일치하는지 확인합니다. 많은 SBI 문제는 네트워크 연결성 때문이 아니라 잘못된 리소스 경로, API 버전 오류, 잘못된 HTTP 메서드에서 발생할 수 있습니다.

이후 HTTP 상태 코드를 확인합니다. 4xx 응답이면 요청 문법, 존재하지 않는 리소스, 권한, 애플리케이션 파라미터를 살펴봐야 합니다. 5xx 응답은 NF 제공자 내부의 처리 문제 가능성을 더 강하게 나타냅니다.

HTTP 요청이 올바르게 전달되었다는 것을 확인한 뒤에야 JSON 페이로드를 자세히 분석하는 것이 좋습니다.

전체 SBI 장애 분석 경로는 다음과 같이 정리할 수 있습니다.

TCP → HTTP/2 연결 → Stream → HEADERS → 메서드/URI → DATA/JSON → 상태 코드

이 접근법을 사용하면 처음에는 매우 “인터넷 방식”처럼 보이는 5GC 프로토콜도 익숙한 계층형 엔지니어링 문제로 정리할 수 있습니다. 하위 계층에서는 연결성을, 중간에서는 HTTP/2 전송 동작을, 상위에서는 API 리소스와 비즈니스 데이터를 확인합니다. 그러면 장애 경계를 훨씬 쉽게 찾을 수 있습니다.

더 넓은 5GC 아키텍처 관점에서 SBI가 HTTP/2를 사용하는 이유는 단순히 HTTP/1.1보다 최신이기 때문이 아닙니다. 더 근본적인 이유는 5G 코어가 NF 기능을 서비스로 구성하기 때문에 빈번한 API 호출, 동시 서비스 상호작용, 리소스 지향 접근을 효율적으로 지원할 수 있는 통신 모델이 필요하기 때문입니다.

HTTP/2는 Connections, Streams, Frames를 제공합니다. 멀티플렉싱은 연결 활용도를 높이고, HPACK은 반복 헤더 오버헤드를 줄이며, 바이너리 프레이밍은 구조화된 전송 형식을 제공합니다. JSON은 애플리케이션 데이터를 운반하고, RESTful API는 리소스와 그 리소스에 수행되는 작업을 정의합니다. 이 요소들이 함께 5GC 서비스 기반 인터페이스의 완전한 통신 모델을 구성합니다.

자주 묻는 질문

HTTP/2와 RESTful API는 같은 것인가?

아닙니다. HTTP/2는 Connections, Streams, Frames 같은 메커니즘을 정의하는 HTTP 전송 프로토콜입니다. REST는 애플리케이션 객체를 리소스로 표현하고 URI와 HTTP 메서드를 통해 그 리소스에 접근하는 방식을 정의하는 API 아키텍처 스타일입니다. 5GC SBI는 HTTP/2 위에서 RESTful 방식의 API를 사용합니다.

Stream ID 0이 일반적인 SBI 애플리케이션 요청을 운반할 수 있는가?

아닙니다. Stream ID 0은 프로토콜 계층에서 특별한 역할을 하며 일반 애플리케이션 Stream으로 사용되지 않습니다. 실제 SBI 요청을 분석할 때는 비즈니스 트랜잭션에 할당된 0이 아닌 Stream ID를 확인해야 합니다.

SBI의 apiRoot에 반드시 IP 주소가 들어가야 하는가?

반드시 그렇지는 않습니다. apiRoot의 논리 형식은 http(s)://host(:port)입니다. host는 네트워크 아키텍처와 서비스 검색 메커니즘에 따라 해당 서비스 엔드포인트를 식별합니다. URI를 분석할 때는 apiRoot를 apiName, apiVersion, 리소스별 경로와 구분해서 보는 것이 좋습니다.

HTTP/2가 바이너리 프레이밍을 사용하는데도 왜 DATA Frame 안에서 JSON을 볼 수 있는가?

바이너리 프레이밍은 HTTP/2가 프로토콜 데이터를 구성하고 전송하는 방식을 의미합니다. 애플리케이션 계층 페이로드 자체까지 바이너리 형식을 사용해야 한다는 뜻은 아닙니다. DATA Frame은 여전히 JSON을 운반할 수 있습니다. JSON은 5GC 애플리케이션 필드를 정의하고, HTTP/2는 해당 페이로드를 적절한 Stream에 넣어 전송합니다.

HTTP 200 응답이면 전체 5GC 절차가 성공했다고 볼 수 있는가?

아닙니다. HTTP 200은 해당 시점에서 특정 HTTP 요청이 정상 처리되었다는 뜻일 뿐입니다. 하나의 완전한 5GC 절차에는 여러 네트워크 기능 사이의 여러 서비스 호출이 포함될 수 있습니다. 전체 종단 간 절차가 성공했다고 판단하려면 URI, JSON 내용, 전후 시그널링 순서도 함께 확인해야 합니다.