길리랩blog

PML, 사람과 기계가 함께 읽는 제품 데이터 언어

Auto-ID센터가 제안한 XML 기반 제품 데이터 언어 PML의 스키마 구조와 EPCIS·B2MML·JSON 대비 위치, 도입 절차를 정리한다.

2026-08-13 · 최초 발행 2025-11-26

EPC 코드는 "이 태그가 어떤 개체를 가리키는지"만 말해준다. 그 개체가 지금 어떤 상태이고 어디에 있으며 어떤 환경에 놓여 있는지를 사람도 읽고 기계도 파싱할 수 있는 형태로 적어야 할 때, PML(Product Markup Language)이 등장한다. Auto-ID센터(MIT)가 EPC 네트워크 전반에서 물체·시스템·공정·환경 정보를 일관되게 기술하기 위해 제안한 XML 기반 언어다.

제품·시스템·공정·환경을 하나의 문서로

PML은 제품(Product), 관련 시스템(System), 공정(Process), 물체 관련 환경(Environment)의 상태·속성·관계를 기술하는 XML 기반 마크업 언어다. Auto-ID센터의 EPC 네트워크 구상(Savant, ONS, EPC 코드)에서 상위 계층 데이터 표현 표준으로 제안됐고, EPC 이벤트와 환경 데이터를 문서화해 MES·ERP·WMS 같은 응용 시스템과 교환하는 것을 목적으로 한다. 지금은 EPCglobal EPCIS/CBV가 산업 표준으로 정착했고, PML은 연구·파일럿·내부 표준 형태로 일부 활용된다(최신 사양·호환성은 확인이 필요하다).

PML을 PML답게 만드는 특징

XML 네이티브 언어로서 XML Schema(XSD) 기반의 강한 구조화를 갖추고, 네임스페이스로 도메인을 확장한다. 스키마 버전 관리와 파생 타입으로 단계적 확장이 가능하다.

Auto-ID/EPC 연계에 최적화돼 있어 EPC(Serialized GTIN 등) 식별자, 리더·안테나, 리드 타임, 위치, 센서치를 포함하는 구조를 갖는다. Savant·미들웨어에서 수집→정제→PML 문서 변환→저장·배포로 이어지는 파이프라인을 전제로 한다.

객체-시스템-공정-환경을 통합 모델링한다. Object(Product/Asset), ProcessStep(작업 이력), Resource(설비·도구), Environment(온도·습도·진동)를 기술하고, 동일 문서 안에서 참조 ID로 관계 링크를 유지한다.

사람과 컴퓨터가 동시에 읽을 수 있다. 의미 있는 태그명과 계층 구조로 가독성을 확보하고, XSD 검증을 통해 품질을 보장하며 스키마 기반 IDE·툴링을 지원한다.

전송·API 바인딩이 유연하다. 초기에는 SOAP/HTTP 바인딩을 가정했지만 현재는 REST와 메시지 브로커(Kafka, MQTT)로도 적용 가능하며, TLS 전송 암호화나 XML DSig 메시지 서명 같은 보안 계층도 얹을 수 있다.

데이터가 문서로 굳어지는 과정

입력은 RFID·EPC 리드 이벤트, 센서(온도·습도), 마스터 데이터(제품·로트)다. 처리는 정제·중복 제거→PML 생성→XSD 검증→저장(EPCIS/PML 저장소)→쿼리·구독 순으로 흐른다. 출력은 운영 시스템(MES/ERP/WMS/PLM), 대시보드, 규제 보고로 이어진다.

⤢✕입력실패성공중복신규RFID ReaderEPC 이벤트Sensor환경 측정Master Data카탈로그PML 생성/매핑XSD 검증격리 큐/재시도트랜잭션 시작중복검사(키:eventTime+EPC+readerID)멱등 처리/무시PML/EPCIS 저장커밋쿼리 API/서빙MES/ERPWMS/TMSAnalytics/BI

트랜잭션·락·일관성은 이벤트 키 기반 UPSERT로 멱등성을 보장하고, 저장소 수준의 ACID 트랜잭션을 적용한다. 검증 실패나 중복이 발생하면 보정 큐로 분기한다.

실제로 도입하려면 이런 절차를 거친다

먼저 대상 엔티티(제품·자산·공정·환경)와 수명주기 경계(L1~L4 시스템)를 정의하고, 교환 목적(추적·모니터링·규제 보고)을 명확히 한다. 다음으로 코어 스키마(XSD)와 도메인 확장 네임스페이스를 설계하고 용어사전·코드셋을 관리한다(CBV, UN/CEFACT 코드 재사용이 권장된다). 수집·미들웨어 단계에서는 리더·게이트웨이를 설정하고 이벤트 정규화, 시퀀스·타임스탬프 정책을 세우며 변환 매퍼(PML/EPCIS)와 XSD 검증기를 배치한다. 저장소·쿼리 단계에서는 EPCIS DB, 네이티브 XML DB(eXist-db), RDBMS(XML 타입) 중에서 선택하고 조회 API(필터: EPC/장소/시간/조건)와 구독·웹훅을 설계한다. 마지막으로 스키마 버전 정책과 마이그레이션 규칙, 호환성 테스트를 정하고 SLA·재처리 큐 모니터링과 보안·감사로깅 체계를 운영에 넣는다.

어디에서 실제로 쓰이는가

제조 WIP·공정 추적에서는 공정 진입·종료 이벤트와 설비자원 매핑을 PML로 기록하고, MES와 양방향 연계해 실시간 WIP 잔량과 병목을 분석한다. 콜드체인·물류 모니터링에서는 팔레트 EPC와 온습도 시계열을 PML 환경 노드로 캡처하고, 규격 초과 시 예외 이벤트를 발행해 TMS 재할당을 자동화한다. 자산 관리·서비스 이력에서는 설비 EPC, 유지보수 작업, 교체 부품 내역을 PML 문서로 통합해 감사·컴플라이언스 보고를 자동화한다. 공급망 추적성·리콜 대응에서는 시리얼 단위 이동 경로를 PML/EPCIS에 축적해 리콜 범위 계산과 대상 리스트를 자동 산출한다.

도입이 만드는 숫자

통합 비용은 포인트-투-포인트 매핑 대비 인터페이스 개발·유지비를 2040% 절감할 수 있다(사례 기반 추정, 환경 의존). 데이터 품질은 스키마 검증·멱등 처리로 이벤트 오류·중복을 50% 이상 줄일 수 있다. 리드 타임은 자동 수집과 실시간 가시화로 재고조사·검수 리드 타임을 1025% 단축할 수 있다. 감사·규제 대응성 면에서는 표준화된 문서 보관으로 감사 소요 시간이 줄고 재현성이 확보된다.

EPCIS·B2MML·JSON과 비교하면

항목 PML (XML) EPCIS (Event Standard) B2MML (ISA-95 XML) JSON/커스텀 스키마
성능 XML 파싱 오버헤드 중간 이벤트 모델 최적화, 우수 복잡도 높아 비용 큼 경량, 최고
확장성 네임스페이스로 우수 이벤트 필드 확장 제한적 모델 포괄적, 무거움 자유도 높음, 난립 위험
일관성 XSD로 강한 일관성 표준 이벤트/CBV로 강함 제조 도메인 강함 팀 역량 의존
안정성 스키마 검증/서명 용이 성숙 생태계, 매우 높음 산업계 채택 높음 구현 품질 편차
운영 편의 XML 툴 풍부, 장문서 관리 부담 레퍼런스 구현 다수 모델 학습 곡선 큼 쉬움, 거버넌스 필요

선택 기준은 명확하다. 광범위한 EPC 이벤트 상호운용이 목표라면 EPCIS가 우선이고, 내부 표준화된 문서 교환·감사 친화 XML이 필요하면 PML이 적합하다. 제조 ISA-95 연계는 B2MML, 경량 API·프론트엔드 통신은 JSON이 낫다.

보안·거버넌스에서 챙겨야 할 것

데이터 보안은 전송 계층 TLS와 저장 시 민감 필드(EPC 시리얼) 마스킹·토큰화로 시작하며, XML Signature·Encryption으로 무결성·기밀성을 강화한다. 트랜잭션·멱등성은 이벤트 키(eventTime, EPC, readerID, seqNo)를 설계하고 At-least-once 전송에 멱등 처리를 더해 메시지 중복·순서를 보장한다. 스키마 거버넌스는 SemVer 기반 버전 관리와 하위 호환 우선의 확장 원칙, 테스트팩(XSD+샘플 문서) 배포와 계약 테스트 자동화로 이뤄진다. 관측 가능성 확보를 위해 파이프라인 단계별로 유효성 실패율, 중복율, 처리지연 p95를 계량하고 데드레터 큐와 자동 재처리 시나리오를 운영한다.

PML 문서와 파서 구현 예시

전제조건: Python 3.11+, lxml 설치(pip install lxml). 내부 XSD 검증은 생략했지만 프로덕션에서는 XSD 필수 적용이 권장된다.

예시 PML 문서(XML):

<?xml version="1.0" encoding="UTF-8"?>
<PML xmlns="urn:autoid:specification:pml:1">
  <Header>
    <DocId>pml-2025-11-23-0001</DocId>
    <CreationTime>2025-11-23T09:15:30Z</CreationTime>
    <SchemaVersion>1.0</SchemaVersion>
  </Header>
  <Object>
    <EPC>urn:epc:id:sgtin:0614141.112345.400</EPC>
    <Class>GTIN-0614141-112345</Class>
  </Object>
  <Event>
    <EventTime>2025-11-23T09:15:00Z</EventTime>
    <ReaderId>reader-DC1-GATE-A</ReaderId>
    <Location>GLN-8801234.DC1.DockA</Location>
    <Action>ADD</Action>
  </Event>
  <Environment>
    <Sensor type="temperature" uom="Cel">3.8</Sensor>
    <Sensor type="humidity" uom="%RH">72.1</Sensor>
  </Environment>
  <Process>
    <StepId>RECEIVING</StepId>
    <Operator>op-1298</Operator>
  </Process>
</PML>

간단 파싱 코드(Python):

from lxml import etree

XMLNS = {"p": "urn:autoid:specification:pml:1"}

def parse_pml(xml_bytes: bytes):
    root = etree.fromstring(xml_bytes)
    epc = root.findtext("p:Object/p:EPC", namespaces=XMLNS)
    event_time = root.findtext("p:Event/p:EventTime", namespaces=XMLNS)
    reader = root.findtext("p:Event/p:ReaderId", namespaces=XMLNS)
    sensors = root.findall("p:Environment/p:Sensor", namespaces=XMLNS)
    env = {(s.attrib.get("type") or "unknown"): float(s.text) for s in sensors}
    return {"epc": epc, "event_time": event_time, "reader": reader, "env": env}

if __name__ == "__main__":
    with open("sample.pml.xml", "rb") as f:
        doc = f.read()
    data = parse_pml(doc)
    print(data)

운영 팁으로는 파싱 전 XSD 검증(소스 신뢰 경계)과, 이벤트 키 생성(epc+event_time+reader)을 통한 멱등 처리가 있다.

PML이 지향하는 지점은 처음부터 분명했다 — 사람과 컴퓨터가 공용으로 이해할 수 있는 XML 기반 제품 데이터 기술 언어다. Auto-ID/EPC 환경에서 물체·시스템·공정·환경 정보를 통합 표현해 상호운용성과 감사 가능성을 높인다. 지금은 EPCIS가 대외 상호운용 표준으로 우세하지만, 내부 문서화·감사 중심 워크로드에서는 PML의 구조적 강점이 여전히 유효하다. 신규 도입 시에는 EPCIS 연계·호환 전략과 스키마 거버넌스를 병행하는 하이브리드 접근이 현실적이다.

PMLXMLEPC데이터표준상호운용성