바코드 값 하나가 서버 주소가 되기까지 — EPC ONS와 FQDN 네임 해석 체계
EPC(전자상품코드)를 FQDN으로 변환해 ONS·DNS 인프라로 서비스 엔드포인트를 찾는 네임 해석 구조와 설계·운영 트레이드오프 정리
2026-08-13 · 최초 발행 2025-11-26
값 하나가 서버를 가리키게 만드는 법
바코드를 스캐너에 대면 값 하나가 나온다. 이 값만으로는 그것이 어느 회사의 어느 서버를 가리키는지 알 수 없다. EPC(Electronic Product Code)와 ONS(Object Name Service)는 이 간극을 인터넷이 이미 갖고 있는 이름 해석 인프라, 즉 DNS 위에서 메운다.
FQDN(Fully Qualified Domain Name)은 호스트 이름과 도메인 이름을 결합한 완전한 이름이다. 호스트 이름이 ktword이고 도메인이 kt.co.kr이면 FQDN은 ktword.kt.co.kr이 되고, DNS는 이를 A/AAAA(IPv4/IPv6) 레코드로 해석해 IP 주소를 내준다. EPC는 GS1 표준을 따르는 상품·자산 식별자로 SGTIN 등 여러 스킴이 있다. ONS는 이 EPC를 입력받아 관련 서비스(EPCIS, 포인터 서비스 등)의 위치를 찾기 위해 DNS 인프라를 그대로 활용하는 네임 해석 시스템이다. EPC ONS FQDN은 EPC(URN 또는 바이너리 형태)를 규칙에 따라 변환해 만든 FQDN이며, 이 FQDN에 대한 DNS NAPTR 레코드 조회로 서비스 엔드포인트 정보를 받는다.
구성과 해석 메커니즘
FQDN이 전 세계에서 유일할 수 있는 것은 호스트 이름과 도메인 이름의 결합, 그리고 루트→TLD→세부 도메인으로 이어지는 DNS 위임 구조 덕분이다. EPC ONS는 이 구조 위에 자기만의 네임 규칙을 얹는다. SGTIN의 Company Prefix + Item Reference 같은 EPC 키를 규칙에 따라 숫자 단위로 역순·점 구분한 뒤 클래스 도메인에 결합해 FQDN을 만든다. 세부 스킴·존 구조는 GS1 표준을 따르며, sgtin.id.onsepc.com처럼 표준화된 ONS 도메인 영역을 쓰는 것이 일반적이다(최신 정보는 별도 확인이 필요하다).
클라이언트는 만들어진 EPC ONS FQDN에 대해 NAPTR 조회를 수행하고, 그 결과로 URI/SRV 정보를 얻어 대상 서비스(EPCIS나 포인터 서비스)에 접속한다. 이 과정은 캐싱(TTL), 재귀/권한 서버, 네임 위임을 통해 전 지구적으로 확장된다. 여기에 DNSSEC 서명·검증을 더하면 레코드 변조를 막을 수 있는데, 이는 체인 오브 트러스트를 요구하는 만큼 권한 위임 관리·변경 통제·접근 로깅 같은 운영적 보안이 함께 따라와야 하고, 성능과 복잡도 사이의 트레이드오프가 생긴다.
일반 FQDN과 무엇이 다른가
| 항목 | 일반 FQDN | EPC ONS FQDN |
|---|---|---|
| 식별 범위 | 호스트/서비스 단말 식별 | EPC 객체 클래스/서비스 탐색용 네임 |
| 구성 | 호스트 + 도메인 (예: app.example.com) | EPC 키 규칙 변환 + ONS 클래스 도메인 |
| 해석 레코드 | A/AAAA, CNAME, SRV 등 | NAPTR 중심(이후 SRV/URI로 연쇄) |
| 확장성 | DNS 위임·캐싱으로 고확장 | DNS 기반 동일, 네임 규칙 표준화 필요 |
| 보안/무결성 | DNSSEC 선택적 적용 | DNSSEC 권장, 공급망 신뢰 사슬 중요 |
| 운영 편의 | 일반 DNS 운영과 동일 | 표준 규칙 준수·테스트·감사 절차 추가 |
공급망에서 실제로 쓰이는 자리
제조사가 EPC를 기반으로 파트너의 EPCIS 엔드포인트를 자동으로 찾아내면, 리콜이나 추적성(Traceability) 확인, 인증서·원산지 검증까지 자동화할 수 있다. 대규모 유통·물류 네트워크에서는 표준화된 ONS 네임으로 이벤트 데이터 라우팅을 단순화하고, 신규 파트너가 들어올 때도 DNS 위임만으로 서비스 연결을 자동으로 붙일 수 있다. 네트워크가 분리된 환경이라면 내부 DNS 존에 사내 프라이빗 ONS를 구축해 EPC를 사내 EPCIS·데이터 레이크 엔드포인트로 매핑하는 방식도 쓴다 — 이 경우 캐시 적중률을 높이는 쪽으로 보안·성능을 함께 최적화한다.
DNS 캐싱을 제대로 활용하면 반복 조회 지연이 로컬 캐시 적중 시 수 ms 수준, 미적중 시에도 수십 ms 수준으로 줄어들고, 중앙 레지스트리 호출이 줄어드는 만큼 백엔드 부하도 낮아진다 — 조회 트래픽의 50% 이상을 캐시가 흡수한다는 보고도 있지만 이는 환경에 따라 달라진다. 표준화된 네임 규칙과 DNS 인프라를 쓰는 것 자체가 상호운용성을 높이고, 위임·레코드 갱신만으로 파트너 변경에 대응할 수 있는 운영 민첩성을 준다. DNSSEC과 권한 관리, 감사 로그를 결합하면 거버넌스 측면의 신뢰성도 함께 확보된다.
설계할 때 부딪히는 트레이드오프
네임 규칙은 GS1/EPCglobal 규격의 TDT(TDS) 변환 규칙을 따르고 테스트 벡터를 미리 확보해야 한다. 규칙을 단순화할수록 운영은 쉬워지지만 표현력은 줄어드는 균형점이 있다. 보안 쪽에서는 DNSSEC 서명·검증을 기본으로 적용하고 키 롤오버 절차를 세워두는 것이 정석이지만, 권한 위임을 최소화하고 변경 승인 워크플로우를 넣을수록 성능 비용이 따라붙는다.
성능은 TTL 계층 설계로 조절한다 — 권한 존은 비교적 길게, 엣지 캐시는 짧게 잡아 최신성과 성능의 균형을 맞추고, 재귀 DNS의 캐시 용량과 LRU 정책을 네임 실패율 모니터링 기반으로 튜닝한다. 가용성 확보를 위해서는 권한 네임서버를 다중 리전에 배치하고 헬스체크·DNS 장애조치(Failover)를 구성하며, 변경 배포는 단계적으로 롤아웃하되 서명·존 전파 지연을 고려한 변경 윈도우를 운영해야 한다.
FQDN 자체의 기본기도 놓치기 쉬운 지점이다. FQDN은 호스트 이름 + 도메인 이름으로 구성되며(예: ktword + kt.co.kr → ktword.kt.co.kr), 실제 연결이 이뤄지려면 A/AAAA 레코드로 IP 주소가 매핑돼 있어야 한다. CNAME 체인을 쓴다면 최종적으로 A/AAAA까지 확인해야 하고, 내부·외부 존을 분리한다면 스플릿-브레인 DNS와 레코드 일관성 검증 자동화를 함께 고려하는 것이 좋다.