5G 코어는 더 이상 사람 간 통신만을 위해 설계되지 않습니다. 커넥티드카, 스마트 팩토리, 스마트 캠퍼스, 원격 의료, 드론 등 다양한 산업 애플리케이션은 서비스 상황에 따라 네트워크 자원에 동적으로 영향을 주거나 사업자로부터 승인된 네트워크 상태 정보를 얻어야 하는 경우가 늘고 있습니다. 새로운 요구가 생길 때마다 사업자가 AMF, SMF, PCF, UDM 등 여러 네트워크 기능의 설정을 수동으로 바꿔야 한다면, 수직 산업 전반에 5G를 대규모로 확산하기는 매우 어렵습니다.

이때 필요한 것이 NEF(Network Exposure Function)입니다. NEF는 5GC와 AF(Application Function) 사이에 위치해 코어망 내부 기능을 외부 애플리케이션이 사용할 수 있는 표준 인터페이스로 변환합니다. 동시에 보안 제어, 정보 변환, 파라미터 전달도 수행합니다. 제3자 애플리케이션 입장에서 NEF는 단순한 API 게이트웨이가 아니라 사업자의 5G 코어 기능 체계로 들어가는 통제된 관문입니다.

5GC에 NEF가 필요한 이유

4G의 사업 모델은 주로 B2C 중심이었습니다. 네트워크가 연결성을 제공하고 가입자는 모바일 인터넷을 통해 다양한 애플리케이션에 접속했습니다. 5G에서는 모델이 B2B2X로 확대되어 개인 사용자뿐 아니라 제조, 교통, 캠퍼스, 의료 등 산업 플랫폼과 더 깊고 자동화된 상호작용을 지원해야 합니다.

따라서 중요한 질문은 산업 애플리케이션이 사업자의 네트워크 기능을 안전하면서도 표준화된 방식으로 어떻게 활용할 수 있는가입니다.

예를 들어 특정 구역의 생산 단말에 더 예측 가능한 QoS를 제공하거나, 애플리케이션 트래픽을 공장에 가까운 로컬 데이터 네트워크로 유도하려는 산업 기업을 생각해 볼 수 있습니다. 통합된 기능 개방 메커니즘이 없다면 애플리케이션 플랫폼은 여러 코어망 기능에 직접 연결하고 벤더별로 다른 설정을 구현해야 할 수 있습니다. 이는 통합 복잡성을 높이고 더 많은 내부 코어망 인터페이스를 노출합니다.

NEF는 산업 애플리케이션과 5GC 사이에 공통 경계를 만듭니다. 외부 AF는 AMF, SMF, PCF, UDM, UPF의 내부 세부 사항을 모두 이해할 필요가 없으며 NEF를 통해 표준을 준수하는 서비스 요청만 제출하면 됩니다. 이후 NEF가 적절한 5GC 네트워크 기능과 연동하고 결과를 애플리케이션 측에 반환합니다.

이 방식은 원래 수동 조정과 정적 설정에 의존하던 일부 요구를 표준 서비스 호출로 전환해, 사업자가 파트너에게 네트워크 기능을 더 자동화된 방식으로 개방할 수 있게 합니다.

5GC에서 NEF의 위치

NEF는 5GC 네트워크 기능과 AF 사이에 배치됩니다. AF는 비즈니스 로직을 담당하는 애플리케이션 계층 기능 엔터티로, 사업자가 소유하거나 관리하는 신뢰 애플리케이션일 수도 있고 사업자 신뢰 도메인 밖의 제3자 애플리케이션 플랫폼일 수도 있습니다. 제3자 애플리케이션에 내부 코어망 기능에 대한 무제한 접근을 허용할 수 없으므로 통제된 상호작용은 NEF를 통해 처리됩니다.

인터페이스 관점에서 NEF는 서로 다른 두 환경을 연결합니다. 북향으로는 비디오 플랫폼, 커넥티드카 플랫폼, 산업 제어 시스템과 같은 AF를 지원하고, 남향으로는 5GC 내부 네트워크 기능과 연결되어 요청 서비스에 따라 SMF, PCF, UDM 등과 통신합니다.

NEF는 4G의 SCEF에서 발전했지만 적용 범위는 훨씬 넓습니다. SCEF는 주로 특정 IoT 사용 사례와 관련됐지만, 5GC의 NEF는 사람 중심과 기계 중심 애플리케이션을 폭넓게 지원하며 서비스 기반 기능 개방 프레임워크의 핵심 요소가 되었습니다.

NEF는 단순한 메시지 전달 이상의 역할을 합니다. 핵심 책임에는 네트워크 기능과 이벤트 개방, 외부 애플리케이션 정보를 3GPP 네트워크에 안전하게 제공, 외부·내부 형식 간 정보 변환, 필요 시 다른 네트워크 기능의 데이터를 받아 저장하거나 이후 다시 개방하는 기능이 포함됩니다.

NEF가 수신한 일부 정보는 UDR에 저장할 수 있어 단일 NEF 인스턴스에 계속 종속될 필요가 없습니다. 또한 NEF는 PFD 기능을 지원해 더 정확한 애플리케이션 탐지와 정책 처리의 기반을 제공할 수 있습니다.

다섯 가지 핵심 기능의 개방 방식

NEF의 가치는 결국 개방할 수 있는 서비스에서 나옵니다. 실제 5GC 배포에서는 주요 기능을 QoS 개방, 네트워크 이벤트 구독, 트래픽 유도, 파라미터 프로비저닝, PFD 관리의 다섯 영역으로 구분할 수 있습니다. 이는 산업 애플리케이션과 사업자 네트워크 사이에서 자주 요구되는 상호작용을 대표합니다.

QoS 기능 개방

QoS 기능 개방을 통해 파트너 애플리케이션은 특정 서비스 플로우에 필요한 서비스 품질을 요청할 수 있습니다. 예를 들어 비디오 애플리케이션이 기존 PDU 세션에서 동작 중일 때 사용자가 더 높은 화질의 서비스를 선택하면 AF가 NEF를 통해 해당 트래픽 플로우에 강화된 QoS를 요청할 수 있습니다.

NEF가 요청을 받으면 PCF 같은 코어망 기능과 조정합니다. PCF는 정책 로직을 적용하고 SMF 및 다른 네트워크 자원과 연동해 해당 서비스 플로우에 적절한 QoS 처리를 설정합니다.

핵심은 단순히 단말에 더 많은 대역폭을 할당하는 것이 아닙니다. 애플리케이션이 표준 인터페이스를 통해 서비스 요구를 표현할 수 있게 하면서 정책 결정과 네트워크 자원 적용은 계속 5GC가 통제하도록 하는 것입니다.

이동성 및 네트워크 이벤트 구독

제3자 AF는 NEF를 통해 UE 연결 끊김 여부, 재접속 가능 상태, 현재 또는 마지막 확인 위치, 로밍 상태, 통신 실패 사유, 다운링크 데이터 전달 상태 등 UE 관련 네트워크 이벤트를 구독할 수도 있습니다.

이러한 이벤트는 서로 다른 코어망 기능이 탐지합니다. AMF는 UE 도달 가능성, 연결 상실, 특정 통신 장애를 탐지할 수 있고, UDM은 로밍 상태나 일부 식별자 연계 변경 정보를 제공할 수 있습니다. SMF는 다운링크 데이터 전달 관련 상태를 보고할 수 있습니다.

AF가 모든 네트워크 기능에 직접 연결할 필요는 없습니다. AF는 NEF를 통해 이벤트 구독을 생성하고, NEF가 관련 네트워크 기능에 필요한 내부 구독을 설정합니다. 대상 이벤트가 발생하면 코어망이 NEF에 알리고, NEF는 구독 조건에 따라 외부 AF로 이벤트 알림을 전달합니다.

이 메커니즘은 단말 상태에 따라 자동화된 비즈니스 로직을 실행해야 하는 산업 애플리케이션에 특히 유용합니다. 외부 플랫폼이 UE 상태를 계속 폴링하는 대신 실제 이벤트가 발생할 때 알림을 받을 수 있습니다.

트래픽 유도

NEF는 AF의 Traffic Influence 요청을 받아 특정 UE 또는 서비스의 트래픽을 Local DN(Local Data Network)으로 유도할 수도 있습니다. Local DN은 DNAI로 식별되며 일반적으로 엣지 컴퓨팅이나 지역 배치 서비스와 연관됩니다.

예를 들어 자동화 공장에서는 산업 제어 서버가 생산 현장 가까운 로컬 네트워크에 배치될 수 있습니다. 애플리케이션 플랫폼은 NEF를 통해 5GC에 사용자 평면 경로 조정을 요청해 관련 단말 트래픽이 적절한 Local DN으로 라우팅되도록 할 수 있습니다.

NEF가 UPF를 직접 제어하는 것은 아닙니다. 요구사항을 정책 제어 절차로 전달하고, 이후 PCF와 SMF가 정책 및 사용자 평면 구성을 처리합니다. 상황에 따라 SMF는 UPF를 재선택하거나 기존 경로의 UPF를 추가·교체·제거해 트래픽 유도를 완료할 수 있습니다.

안전한 파라미터 프로비저닝

외부 AF는 NEF를 통해 일부 사용자 관련 파라미터를 5GC에 제공할 수도 있습니다. 그렇다고 애플리케이션이 코어망 파라미터를 자유롭게 수정할 수 있다는 뜻은 아니며, 제공 가능한 정보 범위는 엄격히 통제됩니다.

대표적인 예로 Expected UE Behaviour와 일부 Network Configuration Parameters가 있습니다. Expected UE Behaviour는 단말의 예상 이동 특성을 설명할 수 있고, 네트워크 구성 파라미터에는 최대 응답 시간, 허용 가능한 다운링크 데이터 전송 지연, UE가 도달 불가능할 때 버퍼링할 권장 다운링크 패킷 수 등이 포함될 수 있습니다.

NEF는 승인된 파라미터 요청을 UDM으로 전달하고, UDM은 UDR과 연동해 관련 데이터를 읽고 갱신합니다. 해당 데이터 변경을 구독한 AMF나 다른 네트워크 기능은 갱신된 파라미터를 받아 후속 네트워크 처리에 사용할 수 있습니다.

PFD 관리

PFD(Packet Flow Description)는 애플리케이션 탐지에 사용하는 규칙 집합으로 이해할 수 있습니다. 제3자 AF는 NEF를 통해 애플리케이션 식별 정보를 생성할 수 있습니다. 생성된 규칙은 UDR에 저장되고, SMF가 NEF를 통해 가져온 뒤 애플리케이션 탐지를 위해 UPF로 전달할 수 있습니다.

기본 포트나 주소만으로 트래픽을 식별하는 것보다 PFD는 더 구체적인 애플리케이션 특성을 표현할 수 있습니다. 예를 들어 비디오 서비스는 특정 URL 패턴이나 다른 트래픽 특성으로 식별할 수 있어, 네트워크가 해당 트래픽을 적절한 정책 처리 규칙에 더 정확하게 매핑할 수 있습니다.

NEF의 실제 기술적 가치

아키텍처 관점에서 NEF의 가장 중요한 역할은 새로운 전달 노드를 추가하는 것이 아니라 관리 가능한 기능 개방 계층을 만드는 것입니다. 외부 AF는 서비스 지향 인터페이스를 보지만, 5GC 내부의 실제 작업은 계속 PCF 정책 제어, SMF 세션 관리, UDM 데이터 관리, UPF 사용자 평면 처리 등이 수행합니다.

따라서 NEF를 일반적인 API 게이트웨이로만 보면 안 됩니다. 외부 비즈니스 요청과 3GPP 코어망 기능의 관계를 이해하면서 양측 간 보안 제어, 정보 변환, 절차 조정을 수행해야 합니다.

NEF는 다른 네트워크 기능을 대체하지도 않습니다. QoS 적용은 여전히 정책 제어와 세션 자원 구성에 의존하고, 네트워크 이벤트는 해당 NF가 탐지합니다. 사용자 평면 경로는 SMF 같은 기능이 조정하며 사용자 관련 데이터는 UDM과 UDR이 유지합니다. NEF의 역할은 이러한 내부 기능을 통제되고 표준화된 방식으로 개방하는 것입니다.

이 기능은 5G B2B2X 서비스에 특히 중요합니다. 산업 애플리케이션은 5GC 내부 토폴로지 전체를 이해하거나 각 네트워크 기능에 독자 인터페이스를 만들 필요가 없습니다. 표준 개방 메커니즘으로 네트워크 요구를 제출할 수 있습니다. 동시에 사업자는 코어망 경계에 대한 통제권을 유지하면서 선택된 네트워크 기능을 신뢰 파트너가 사용할 수 있는 서비스로 전환할 수 있습니다.

실제적으로 NEF는 5G 코어가 주로 연결성을 제공하는 네트워크에서 산업 애플리케이션에 네트워크 기능을 직접 개방할 수 있는 플랫폼으로 발전하도록 돕습니다.

자주 묻는 질문

모든 AF는 사업자 네트워크 밖에 배치해야 합니까?

아닙니다. AF는 사업자가 소유하거나 관리하는 신뢰 애플리케이션일 수도 있고 사업자 신뢰 도메인 밖의 제3자 애플리케이션일 수도 있습니다. AF 유형에 따라 접근 방식과 보안 처리가 달라질 수 있습니다.

비즈니스 데이터는 항상 NEF 로컬에 저장됩니까?

아닙니다. NEF가 받은 일부 정보는 UDR에 저장한 뒤 다른 네트워크 기능이나 후속 절차에서 사용할 수 있습니다. 따라서 데이터 저장이 하나의 NEF 인스턴스에 계속 종속될 필요는 없습니다.

Local DN과 UPF는 같은 것입니까?

아닙니다. Local DN은 특정 애플리케이션이나 데이터 서비스를 호스팅하는 로컬 데이터 네트워크이고, UPF는 5GC의 사용자 평면 네트워크 기능입니다. 트래픽은 적절한 UPF 경로를 거쳐 지정된 Local DN에 도달할 수 있지만 두 기능의 역할은 다릅니다.

UPF가 자체적으로 PFD 규칙을 생성합니까?

아닙니다. PFD 규칙은 AF가 제공하고 NEF를 통해 관리할 수 있습니다. SMF가 관련 규칙을 가져와 사용자 평면에서 더 정확한 애플리케이션 탐지를 수행하도록 UPF에 전달합니다.