ONS 서버, EPC 코드가 제품정보 서버 주소를 찾는 법

RFID 리더가 EPC 코드 하나를 읽었다고 해서 곧바로 "이 상품의 유효기간은 언제까지다"라는 정보가 나오지는 않는다. EPC는 그 자체로 아무 의미도 담지 않은 식별자일 뿐이고, 그 식별자가 어느 서버에 어떤 정보로 존재하는지 찾아주는 계층이 따로 필요하다. 그 역할을 하는 것이 ONS(Object Name Service)다.

주소록이지 데이터 저장소가 아니다

ONS는 EPC 코드를 입력으로 받아 PML(Physical Markup Language) 서버의 네트워크 엔드포인트를 반환하는 DNS 기반 이름 해석 서비스다. 제품정보 데이터는 저장하지 않고, 신뢰 가능한 PML 서버 주소를 제공하는 포인터 역할만 한다. 표준 기반은 DNS NAPTR(Regex 기반 리다이렉션) 레코드로, EPC 네임스페이스를 PML URI로 매핑한다. EPCglobal ONS 규격과 RFC 3403(NAPTR)에 기반해 동작하며, 세부 도메인 정규화 규칙은 최신 규격을 확인해야 한다.

역할을 나누면 명확해진다. ONS는 "주소록", PML 서버는 "데이터 저장소", 사반트(Savant)는 "클라이언트/오케스트레이터"다. 이 구분이 조회 흐름을 단순화하고 확장성을 확보하는 기반이 된다.

맞물려 돌아가는 구조

DNS/NAPTR 기반 주소 해석은 EPC 네임스페이스를 도메인으로 정규화하고 NAPTR 레코드로 PML URI 목록을 반환한다. 우선순위·가중치 기반으로 다중 엔드포인트를 지원해 장애 시 대체 경로를 제공한다.

PML 서버 주소 정의는 PML(XML/JSON) 스키마 기준으로 제품 마스터·로트·개체 정보를 제공하며, HTTPS 엔드포인트를 권장한다. URI 패턴을 합의하면 사반트가 정형화된 조회를 할 수 있고, 버전 관리와 스키마 호환성 관리가 필요하다.

사반트(Savant) 연동은 RFID 리더로부터 EPC를 수집한 뒤 ONS에 질의하고, PML 서버에서 제품정보를 조회해 상위 애플리케이션에 전달하는 과정이다. 캐시, 재시도, QoS 제어, 배치·실시간 혼합 처리 전략이 여기에 적용된다.

캐싱·확장성은 DNS TTL과 사반트 로컬 캐시로 응답 지연을 최소화하고, 엣지·지사 단에 ONS 캐시 레졸버를 두는 것이 권장된다. 대규모 조회량에도 수평 확장이 용이하며, CDN·DNS anycast로 글로벌 지연을 최적화할 수 있다.

보안·신뢰성 측면에서는 ONS 구간에 DNSSEC로 무결성을, PML 구간에 TLS로 기밀성·상호 인증을 구현한다. 레이트 리미트와 쿼리 서지 보호, 폐쇄망 프라이빗 ONS 구성으로 민감한 EPC를 보호할 수 있다.

조회가 실제로 흐르는 순서

입력은 EPC 코드(예: SGTIN), 조회 정책(실시간·배치), 캐시 상태다. 처리는 1) EPC→ONS 도메인 정규화, 2) DNS NAPTR 질의→PML URI 목록 수신, 3) 우선순위 기반 PML 서버 HTTPS 조회, 4) PML 응답 파싱 및 사전 정의 스키마 매핑 순으로 진행된다. 출력은 제품 기본정보·로트·유통기한·규격 등의 PML 데이터이며, 사반트가 이를 상위로 전달한다.

⤢✕

ONS가 미응답이거나 NXDOMAIN을 반환하면 로컬 캐시나 세컨더리 ONS로 재시도하며 백오프·써킷브레이커를 적용한다. PML 서버 오류 시에는 대체 엔드포인트로 전환하거나 읽기 전용 캐시를 반환하고 SLA 기반으로 지연 허용치를 관리한다. 일관성은 TTL 기반 점진적 업데이트, 변경 시 롤링 업데이트와 캐시 무효화 전략으로 유지한다.

실무에서 이 조회가 쓰이는 곳

유통·리테일 매장 재고에서는 실시간 입고 스캔이 ONS→PML로 제품속성을 로드해 POS·OMS와 동기화한다. 신상품 롤아웃 시 중앙 PML만 업데이트하면 지점에 별도 배포 없이 반영된다. 제약·의료 콜드체인에서는 시리얼라이제이션 EPC 조회로 PML의 로트·유효기간을 검증하고 불일치 시 알림을 보낸다. 리콜 상황에서는 EPC 범위 질의로 회수 대상을 자동 식별한다. 제조 추적성·AS에서는 EPC로 BOM·제조이력 PML을 조회해 현장 AS 앱에 부품 호환 정보를 제공하며, 공급업체별 프라이빗 ONS로 데이터 경계를 분리한다. 국경 간 공급망에서는 글로벌 루트 ONS가 지역 PML로 라우팅하고, 로밍 장비는 엣지 ONS 캐시로 지연을 최소화한다.

어떤 아키텍처를 고를 것인가

옵션	성능	확장성	일관성	안정성	운영 편의
퍼블릭 루트 ONS 중심	WAN 지연 영향, 캐시 시 양호	글로벌 네임서버 확장 용이	TTL 기반 최종적 일관성	루트 장애 시 리스크 존재	운영 단순, 의존성 높음
프라이빗 ONS(기업 전용)	사내 저지연	권한 분할로 수평 확장	변경 통제 용이	외부 영향 최소화	운영 비용/전문성 요구
엣지 ONS 캐시(지사/공장)	현장 초저지연	지사 단위 증설 용이	캐시 갱신 지연 고려	WAN 단절에도 조회 지속	캐시 정책/관리가 필요

운영에서 절충해야 하는 지점들

네임 설계와 버전 관리에서는 EPC→도메인 정규화 규칙을 일관되게 유지해야 하고, 변경 시 이중 게시(구/신 NAPTR)로 이행 기간을 운용한다. TTL이 짧으면 신속하게 갱신되지만 쿼리가 늘어나므로 적정 TTL(5~30분)이 권장된다.

보안·프라이버시는 ONS 구간의 DNSSEC 서명·검증, PML 구간의 mTLS·권한 토큰(OAuth2)으로 다룬다. DNSSEC의 서명·검증 오버헤드는 무결성 강화와 맞바꾸는 비용이다.

가용성·장애 대응은 다중 NAPTR(우선순위/가중치), 애니캐스트 DNS, PML 다중 리전 구성으로 확보한다. 이중화 비용 증가는 RTO·RPO 개선과 맞바꾼다.

관측성·SLO 측면에서는 ONS 질의 성공률·지연 p95, PML 응답 코드·스키마 유효성을 모니터링하고, 에러 버짓 기반 출시 관리로 변경을 안정적으로 추진한다.

NAPTR 레코드를 직접 조회해보기

전제조건: Linux/macOS, dig 설치, BIND 9.18+ 또는 호환 DNS 서버. 도메인은 예시 도메인 ons.example.com을 사용한다(실서비스 아님).

예시 NAPTR 레코드(zone 파일 조각):

; EPC 클래스용 예시 ONS 도메인 (도메인 정규화 규칙은 표준 참조)
5.4.3.2.1.1.1.1414160.sgtin.id.ons.example.com. 300 IN NAPTR 100 10 "u" "EPC+PML" \
"!^.*$!https://pml.example.com/sgtin/!" .

조회 예시:

dig +short NAPTR 5.4.3.2.1.1.1.1414160.sgtin.id.ons.example.com
; 예상: "100 10 U EPC+PML ... https://pml.example.com/sgtin/"

실제 ONS 도메인 구성·정규화는 EPCglobal ONS 최신 명세를 확인해야 한다. PML 서버는 HTTPS/TLS와 인증·인가 계층 적용이 권장된다.

이 계층이 만드는 실제 효과

성능 면에서는 캐시 적중 시 ONS 해석 지연이 사내 기준 15ms, 미적중 WAN 조회는 2080ms 수준이다. 엣지 캐시를 배치하면 총 조회 시간이 30~60% 단축된다. 정확성·일관성 면에서는 표준 스키마(PML)를 강제 적용해 제품정보 오류율이 마스터데이터 중복 제거 기준으로 50% 이상 감소한다. 운영 효율에서는 신규 제품·리콜 정보를 중앙 게시만으로 전 지점에 무배포 반영할 수 있어 운영 변경 리드타임이 70% 단축된다. 확장성·복원력 면에서는 다중 NAPTR·다중 PML 엔드포인트 구성으로 장애 시 자동 페일오버가 가능해 글로벌 서비스 연속성을 확보한다.

ONS는 EPC와 PML 서버 사이를 잇는, 눈에 띄지 않지만 없으면 조회 자체가 성립하지 않는 해석 계층이다. 사반트가 이 계층을 통해 PML 제품정보를 조회·전달함으로써 RFID 기반 애플리케이션의 확장성과 일관성, 기민성이 확보된다. DNS/NAPTR, 캐시, DNSSEC, PML 보안 설계를 포함한 프라이빗·엣지 혼합 아키텍처가 실무에서는 가장 안정적인 선택지다.