표준의 PHASE 3는 목적을 한 문장으로 밝힌다. 부품 공급자, MRO, 운영자, 인증 당국 사이의 프로토콜을 정의한다는 것이다. 동시에 무엇을 하지 않는지도 분명히 선택한다. ARP4754A(항공기 및 시스템 개발), ARP4761A(안전성 평가), DO-178C(항공용 소프트웨어), DO-254(항공용 전자 하드웨어)는 이미 어떤 증거가 존재하고 누가 그것을 만드는지를 정의하고 있다. PHASE 3는 자신의 프로토콜 스키마가 이 문서들의 메시지 유형을 반영할 뿐 재정의하지 않는다고 명시한다. 실무적으로 이는 WIA 메시지가 증거를 운반할 뿐, 그 증거를 낳은 계획·분석·검토를 대신하지 않는다는 뜻이다.
제1장에서 밝혔듯 PHASE 3 문서의 나머지 본문은 비행조종·유압·연료 계통에 관한 공학 내용이며, 이는 제3장에서 이미 다루었다. 따라서 프로토콜 자체는 세 가지 출처를 엮어 구성된다. PHASE 3 서문(네 가지 역할), PHASE 2의 다섯 작업 그룹(그 역할들이 쓸 수 있는 동사), 부속서 E의 구현 노트(시각 동기화, 보존 기간, 스키마 진화)이다. 이 장은 그 사이의 빈틈을 확립된 항공 실무로 메우되, 표준이 아직 규정하지 않은 내용을 이 책이 제안하는 경우에는 그 사실을 분명히 표시한다.
한 회사가 여러 역할을 맡을 수 있다. 자체 정비 조직을 가진 항공사는 운영자이자 MRO이고, 수리 조직 승인도 보유한 1차 공급자는 공급자이자 MRO이다. 프로토콜이 관심을 두는 것은 법인이 아니라 메시지를 보낼 때의 역할이다. 책임은 그 작업이 수행된 근거 승인에 귀속되기 때문이다.
설계 승인 소지자(형식증명·부가형식증명 소지자, 또는 부품의 경우 TSO·PMA 소지자)는 PHASE 3에 다섯 번째 역할로 나오지 않는다. 실제로는 서비스 불리틴을 발행할 때 공급자 역할로, 승인을 신청할 때 인증 패키지 교환을 통해 행동한다. 이 책은 이 단순화를 따르되, 모든 메시지에 발신자의 승인 번호를 남겨 필요할 때 그 구분을 되살릴 수 있게 한다.
| 역할 | 발신 | 수신 | 주요 작업 그룹 |
|---|---|---|---|
| 공급자 | 부품 신원(P/N, S/N), FAI 보고서, 적합성 인증서, 신품용 8130-3 / Form 1, (설계 소지자를 대신할 때) 서비스 불리틴 | 인증 결정, AD 적용성 질의 | componentCatalog, traceability, certificationPackage, serviceBulletin |
| 운영자 | 장착·탈거 이벤트, 비행시간과 사이클, AD/SB 이행 기록 | 출고 증명서, SB, AD, MRO 발견 사항 | maintenanceEvent, traceability, serviceBulletin |
| MRO | 공장 발견 사항, Inspection 레코드, 수리·개조 기록, 정비 출고 증명서 | 탈거 사유, 출생 이력, 적용 AD | maintenanceEvent, traceability |
| 당국 | 승인 결정, 증명서 확인 결과, 감항성 개선지시 | 인증 패키지, 사건 및 SUP 보고 | certificationPackage, serviceBulletin |
프로토콜과 공유 스프레드시트를 가르는 것은 네 가지 규칙이다. 첫째, 모든 메시지에는 책임지는 발신자가 하나 있다. 발신자는 조직과 승인 번호로 식별되며, 그 메시지를 정정할 수 있는 것도 발신자뿐이다. 둘째, 레코드는 추가만 가능하다. 잘못된 항목은 제자리에서 고치지 않고, 그것을 참조하는 새 항목으로 대체한다. 감사자는 결정이 내려진 시점에 무엇이 사실로 믿어졌는지를 볼 수 있어야 하기 때문이다. 셋째, 모든 메시지의 대상은 세 값의 조합이다. 제작사, 부품번호, 일련번호가 그것이며, 데이터베이스 식별자가 아니다. AircraftComponent의 id 필드는 한 시스템 안에서만 유효하지만, 세 값의 조합은 명판에 새겨져 있다. 넷째, 종이 문서가 여전히 우선한다. 규정이 서명된 출고 증명서를 요구하는 곳에서 WIA 메시지는 그 증명서를 참조하고 운반할 뿐, 그것을 대체하지 않는다.
표준은 작업 그룹의 이름은 정하지만 공통 봉투(envelope)는 정의하지 않으며, 참조 SDK는 요청 본문만 그대로 보낸다. 독립된 조직 사이의 교환에는 그 이상이 필요하다. 중복 제거용 식별자, 발신자, 대상 조합, 두 개의 시각, 그리고 서명이다. 아래 봉투는 이 장의 나머지 절에서 사용하는 구조이다. 표준의 규칙(필드 추가 방식의 확장, PHASE 2가 매니페스트에 이미 쓰는 DSSE 서명)과 일치하도록 이 책이 제안하는 것이며 규범 스키마가 아니다. 모든 값은 가상의 것이다.
{
"messageId": "0d9c2f6e-5b1a-4c55-9d3e-2a71c4e0b8a4",
"idempotencyKey": "mro-kr-017:wo-2026-00418:inspection:1",
"operationGroup": "maintenanceEvent",
"originator": {
"role": "mro",
"organisation": "Example Aero Repair Co.",
"approvalRef": "EXAMPLE-145-0000"
},
"subject": {
"manufacturerCage": "0XXX0",
"partNumber": "EX-4410-203",
"serialNumber": "EXS-00117"
},
"subjectSequence": 42,
"occurredAt": "2026-03-14T06:20:00Z",
"recordedAt": "2026-03-14T06:31:12Z",
"supersedes": null,
"payload": { },
"signature": { "format": "dsse", "keyId": "mro-kr-017-2026" }
}subjectSequence와 두 시각은 6.6절에서 설명한다. supersedes는 추가 전용 규칙을 구현하는 수단이다. 비어 있는 payload에는 작업별 객체가 들어가며, 6.3절의 정비 이벤트가 그 예이다.
일련번호는 공급자에서 태어난다. 새 설계나 변경된 설계의 첫 유닛이 출하되기 전에 세 가지가 성립해야 한다. 설계가 승인되었을 것, 제작 공정이 그 설계에 합치하는 부품을 만든다는 것이 입증되었을 것, 그리고 각 유닛이 출고 문서와 함께 나갈 것. 프로토콜은 이 셋을 모두 담아야 하며, ComponentStatus 필드는 증거가 존재할 때에만 움직여야 한다.
항공우주 초도품 검사(FAI) 표준인 AS9102는 제작 공정이 공학 정의의 모든 요구 사항에 합치하는 부품을 만든다는 것을 완전하게, 문서로 검증하도록 요구한다. 보고서는 세 양식으로 구성된다. 부품번호 책임(어떤 부품, 어떤 개정판, 어떤 하위 조립체), 제품 책임(원자재, 특수공정, 기능 시험과 각각의 승인 공급원 및 증명서), 특성 책임(치수, 주기 사항, 규격 요구 등 모든 설계 특성과 그 측정 결과)이다. FAI는 첫 생산분의 대표 유닛으로 수행하며, 설계·제작 공정·공급원·치공구·생산 장소가 바뀌거나 표준이 정한 기간보다 오래 생산이 중단되면 전체 또는 부분적으로 다시 수행해야 한다.
프로토콜 관점에서 중요한 점은 FAI는 공정에 속하고 출고 증명서는 유닛에 속한다는 것이다. 따라서 일련번호 EXS-00117의 WIA 레코드는 해당 부품번호와 개정판을 포괄하는 FAI 보고서를 참조해야 하며, 그것을 복제해서는 안 된다. FAI를 무효로 만드는 변경은 시스템에서 보여야 한다. 레코드의 도면 개정판이 참조된 FAI가 다루는 개정판보다 새롭다면 그 레코드는 불완전한 것이며, 유닛은 다음 단계로 넘어가서는 안 된다.
각 유닛에는 두 문서가 따라간다. 적합성 인증서(CoC)는 출하품이 구매 주문과 해당 도면에 합치한다는 공급자의 진술이다. 이는 상업적 품질 문서이며, 하위 공급자에게 발주할 때 대부분의 구매 주문이 요구한다. 출고 증명서(authorized release certificate), 곧 미국의 FAA Form 8130-3과 유럽의 EASA Form 1은 규제 문서이다. 신품의 경우 제작 승인 아래 발행되며, 승인된 설계 자료에 대한 합치와 안전 운용 가능 상태를 증명한다. 같은 양식은 이후 정비 조직이 작업 후 부품을 출고할 때도 쓰이며, 무엇을 했는지를 나타내는 상태 칸(예를 들어 신품, 오버홀, 수리, 검사·시험, 개조)을 함께 기재한다.
WIA 레코드에서 출고 증명서는 두 곳에 나타난다. 문서 자체 또는 그 문서에 대한 통제된 참조는 maintenanceEvent나 출고 메시지와 함께 이동한다. 문서를 식별하는 데이터(양식 종류, 추적 번호, 발행 조직, 상태·작업)는 metadata에 보관해야 하는데, 참조 타입 AircraftComponent에 전용 필드가 없기 때문이다. 반면 Certification 객체는 설계 수준의 승인, 곧 어떤 기준으로 어느 당국이 어떤 증명서 번호로 승인했는지를 기술하며, 같은 설계 승인을 받은 모든 유닛이 공유한다.
제1장에서 여섯 가지 ComponentStatus 값을 소개했다. 여기서 이 값들은 프로토콜 상태가 되며, 모든 전이는 그것을 정당화하는 메시지를 지목해야 한다. 표 6-2는 이 책이 유효하다고 보는 전이를 나열한다. 표준은 전이 표를 공개하지 않는다. 아래 표는 생애주기에서 도출한 것으로, 구현 규칙으로 채택하고 제8장에서 설명하는 상호운용 프로파일에 선언해야 한다.
| 전이 | 계기 | 발신자 | 존재해야 하는 증거 |
|---|---|---|---|
design → testing | 시험품 제작 및 합치 확인 | 공급자 / 설계 소지자 | 시험품 합치성 검사 기록, 시험 계획 참조 |
testing → certified | 설계 승인 취득(TC/STC, TSO 인가, PMA 또는 동등 승인) | 당국(신청자가 기록) | compliance: true인 Certification 객체, 확인 가능한 증명서 번호 |
certified → production | 첫 유닛 출고 | 공급자 | P/N과 개정판을 포괄하는 FAI 보고서, CoC, 해당 유닛의 8130-3 / Form 1 |
production → maintenance | 공장 입고를 위한 탈거 | 운영자 | 사유와 탈거 시점 비행시간·사이클을 담은 탈거 기록 |
maintenance → production | 작업 후 사용 복귀 | MRO | Inspection 레코드, 수행 작업, 정비 출고 증명서 |
production 또는 maintenance → retired | 수명 한계 도달, 경제적 수리 불가, 폐기 | 운영자 또는 MRO | 처분 기록, 수명 한계 부품·불합격 부품의 절단 훼손 증거 |
retired → 모든 상태 | 허용하지 않는다. 실수로 폐기 처리된 부품은 상태를 되살리지 않고 대체 레코드로 바로잡는다. | ||
두 가지를 주의해야 한다. 첫째, 이 열거형은 설계 수준 상태와 유닛 수준 상태를 섞고 있다. design, testing, certified는 부품번호를, production, maintenance, retired는 일련번호를 기술한다. 일련번호마다 레코드를 하나씩 두는 구현은 보통 유닛 레코드를 곧바로 production으로 생성하고, 그 이전 상태는 설계 수준 레코드에 둔다. 둘째, "장착됨"이나 "재고" 상태가 없다. 이 책은 제1장의 관례를 이어 production을 "출고되어 사용 가능한 상태"로 보고, 장착과 탈거는 정비 이벤트로 기록한다.
부품의 기록된 일생 대부분은 최초 출고 이후에 펼쳐진다. 착륙장치 사이드 브레이스나 유압 펌프는 여러 항공기를 오가며 탈거·수리·재장착을 수없이 반복할 수 있고, 매번의 방문은 다음 소유자가 의존하게 될 기록을 남긴다. PHASE 2가 "정비 조치를 기록·조회·질의한다"고 설명하는 maintenanceEvent 작업 그룹이 이 이력을 운반한다.
traceability 그룹으로 이력과 미결 감항성 개선지시를 조회한다.Inspection 레코드가 하나씩 생기며, 방법은 표준의 열거형(visual, ultrasonic, radiographic, magnetic-particle, eddy-current)에서, 결과는 pass, fail, conditional 중에서 고른다.maintenance에서 production으로 돌아간다.conditional 결과는 열거형에서 가장 많은 정보를 담은 값이자 가장 오용하기 쉬운 값이다. 이는 부품이 조건을 붙여서만 허용 가능하다고 판정되었다는 뜻이다. 재확인이 필요한 한계 내 발견 사항, 검사 간격이 줄어든 수리, 또는 특별 허용이 그런 경우이다. findings 설명도 nextInspectionDate(또는 그에 상당하는 비행시간·사이클 한계)도 없는 조건부 결과는 프로토콜상 불완전하며, 수신 시스템은 이를 거부해야 한다. 많은 반복 검사가 달력 시간이 아니라 사이클로 정해지는데 참조 타입에는 날짜 필드만 있으므로, 이 책은 예시처럼 사이클 기반 한계를 날짜와 함께 이벤트 페이로드에 저장한다.
maintenanceEvent 페이로드(가상의 값, Inspection 외 필드명은 이 책의 제안){
"eventType": "shopVisit",
"workOrder": "WO-2026-00418",
"component": {
"partNumber": "EX-4410-203",
"serialNumber": "EXS-00117",
"type": "landing-gear"
},
"removal": {
"reason": "scheduled",
"aircraftRegistration": "HL-EXMP",
"removedAt": "2026-02-27",
"hoursSinceNew": 18250,
"cyclesSinceNew": 9410,
"cyclesSinceLastShopVisit": 4620
},
"approvedData": ["CMM 32-11-41 rev 12 (example)"],
"inspections": [
{
"id": "insp-0001",
"inspectionDate": "2026-03-12",
"inspector": "EX-INSP-203",
"method": "magnetic-particle",
"result": "pass"
},
{
"id": "insp-0002",
"inspectionDate": "2026-03-13",
"inspector": "EX-INSP-203",
"method": "eddy-current",
"result": "conditional",
"findings": "Corrosion pitting at lug bore, blended within CMM limits; repeat check required",
"nextInspectionDate": "2027-03-13"
}
],
"repeatInspection": { "cyclesLimit": 2000, "whicheverFirst": true },
"release": {
"form": "EASA Form 1",
"trackingNumber": "EX-F1-2026-0331",
"statusWork": "repaired"
},
"statusTransition": { "from": "maintenance", "to": "production" }
}세 가지 세부 사항에 주목할 만하다. 검사자는 사람 이름이 아니라 자격 인가 코드로 식별된다. 수십 년 동안 여러 회사가 공유할 기록에 개인정보를 남기지 않기 위해서이다. 비행시간과 사이클은 부품 레코드가 아니라 이벤트에 들어간다. 그것은 특정 시점에 관한 사실이기 때문이며, 현재 누적값은 이벤트 흐름을 합산해 얻는다. 그리고 검사 레코드는 참조 타입의 Inspection 모양을 그대로 쓰므로, 이미 SDK의 addInspection을 호출하는 MRO 시스템은 변환 없이 이를 만들어 낼 수 있다. 다만 침투 탐상 검사는 표현할 수 없다. 방법 열거형에 침투 탐상 값이 없기 때문이며, 이 공백은 제7장에서 다룬다.
PHASE 2는 serviceBulletin 그룹을 "감항성 개선지시를 발행하고 확인하는" 곳으로 설명한다. 이 표현은 항공 분야가 엄격히 구분해 온 두 문서를 하나로 합쳐 버리며, 둘을 합친 프로토콜은 잘못된 이행 기록을 만들어 낸다.
| 항목 | 감항성 개선지시(AD) | 서비스 불리틴(SB) |
|---|---|---|
| 발행 주체 | 인증 당국(예: 미국은 14 CFR Part 39에 따라, 유럽은 EASA, 한국은 국토교통부) | 설계 승인 소지자 또는 제작사 |
| 법적 효력 | 운영자에게 강제되며, 이행 전까지 항공기는 감항성이 없다 | 권고 사항이다. 다만 AD, 운영자의 승인된 프로그램, 계약으로 강제될 수 있다 |
| 주요 내용 | 불안전 상태, 적용 대상, 요구 조치, 이행 기한, 대체 이행 방법 | 상세 작업 지침, 부품, 작업 시간, 적용 범위, 경보·선택 등의 구분 |
| 관계 | 특정 SB 개정판의 수행을 요구하는 경우가 많다 | AD가 참조하면 명시된 적용 대상에 대해 강제 사항이 된다 |
| 이행 기록 | 방법, 일자, 비행시간·사이클과 함께 필수. 반복 조치는 다음 도래 시점까지 추적 | 수행 시 기록하며, 개조 상태가 부품의 형상을 바꾼다 |
그래서 이 책은 이 그룹의 모든 메시지에 AD 또는 SB 값을 갖는 directiveKind를 부여하고, SB를 강제하는 AD 메시지는 그 SB의 번호와 개정판을 참조하도록 요구한다. 이 구분은 부속서 E의 스키마 진화 규칙상 필드 추가에 해당하므로, 이를 무시하는 소비자를 깨뜨리지 않는다.
흐름은 네 단계이며, 각각이 별도의 메시지이다. 발행: 발신자가 적용 대상과 함께 지시를 공표한다. 적용성 판정: 각 운영자와 MRO가 자기 기단과 재고에 대해 이를 평가한다. 확인: 각 수신자는 수신을 확인하고 자기 일련번호 중 무엇이 해당되는지를 밝힌다. 해당 품목이 없을 때도 없다고 명시한다. 이행: 조치가 끝나면 해당 일련번호마다 이행 기록을 붙인다.
데이터 모델의 가치가 드러나는 곳이 적용성이다. 적용 대상이 단순히 부품번호 하나인 경우는 드물다. 전형적인 지시는 어떤 부품번호에 적용되되, 명시된 범위의 일련번호에만, 그리고 특정 개조를 아직 받지 않은 유닛에만 적용된다. 이를 판정하려면 레코드가 세 가지를 갖고 있어야 한다. 개정 부호나 대시 번호를 포함한 부품번호, 일련번호, 그리고 개조 상태(이미 수행된 SB 목록)이다. 참조 AircraftComponent는 앞의 둘을 담고 있고, 개조 상태는 전용 필드가 표준화될 때까지 metadata에 둔다. 이것이 없으면 traceability 그룹을 통한 질의는 과다 보고, 곧 이미 개조된 유닛까지 해당된다고 표시하는 결과밖에 낼 수 없고, 이는 시스템 전체에 대한 신뢰를 갉아먹는다.
되풀이되는 함정이 두 가지 있다. 반복 AD는 한 번 이행으로 끝나지 않는다. 매 수행이 비행시간, 사이클 또는 달력 시간으로 다음 도래 시점을 정하며, 레코드는 그 시점을 계속 이어 가야 한다. 또 부품이 한 운영자에서 다른 운영자로 옮겨 가면 AD 상태도 함께 옮겨 간다. 새 운영자는 이전 소유자의 항공기 수준 기록에 기대지 않고 부품 자신의 이력만으로 어떤 지시가 수행되었고 다음 조치가 언제인지를 알 수 있어야 한다.
certificationPackage 그룹은 다섯 그룹 가운데 가장 민감하다. PHASE 2는 이를 FAA, EASA, 한국 당국에 인증 증거를 제출하는 그룹으로 설명하고, 형식증명 당국 측 호출자에게는 상호 TLS(mTLS)를 요구한다. SDK는 이를 두 메서드로 노출한다.
requestCertification(componentId, standard)는 POST /components/{id}/certify를 보내며, 반환 타입은 { requestId }이다.verifyCertification(certificateNumber)는 GET /certifications/{certificateNumber}/verify를 보내며, 반환 타입은 { valid, details }이다.이 호출들이 무엇을 나타낼 수 있는지는 정확히 해 둘 필요가 있다. 인증 당국은 API로 설계를 승인하지 않는다. 형식증명, TSO 인가, PMA는 인증 계획, 적합성 입증, 합치성 검사, 시험 입회, 발견 사항 종결로 이어지는 하나의 사업을 통해 얻는다. 이 사업은 신청자와 당국 사이에서, 또는 위임 승인을 가진 조직과 함께 진행된다. 프로토콜이 모델링하는 것은 그 사업 안에서의 증거 제출과 사업이 끝난 뒤의 결과 확인이다. requestId는 제출물을 추적하는 손잡이일 뿐이며, 성공 응답은 패키지가 접수되었다는 뜻이지 무엇이 승인되었다는 뜻이 아니다.
requestCertification을 호출하고, 돌려받은 requestId를 설계 수준 레코드에 저장한다.requestId 아래 각각 새 메시지로 교환된다.standard, authority, certificateNumber, issueDate, expiryDate, compliance를 담은 Certification 객체를 기록하고, 설계는 certified로 전이한다.verifyCertification을 호출할 수 있으며, 명시적인 긍정 응답이 아닌 모든 결과는 "확인되지 않음"으로 다루어야 한다.참조 클라이언트는 네트워크 요청을 보내지 않는다. 내부 makeRequest 메서드는 request 이벤트를 내보낸 뒤 { success: true, data: body }를 돌려주어, 보낸 것을 그대로 되돌려 준다. 따라서 requestCertification의 "응답"은 requestId 없이 { standard: "WIA-SPACE-016" }이고, 본문을 보내지 않는 verifyCertification의 data는 undefined이다. SDK를 대상으로 작성한 코드는 실제 서버에서도 올바르게 동작해야 하며, 이는 실패 시 닫힌 쪽(fail closed)으로 판정해야 한다는 뜻이다.
import { WIAAircraftComponentClient } from '@wia/aircraft-component';
const client = new WIAAircraftComponentClient({
apiKey: process.env.WIA_API_KEY ?? '',
timeout: 60000,
});
client.on('error', (err) => console.error('[wia] 요청 실패', err));
async function submitPackage(componentId: string): Promise<string> {
const res = await client.requestCertification(componentId, 'WIA-SPACE-016');
const requestId = res.data?.requestId;
if (!res.success || !requestId) {
// 참조 SDK는 요청 본문을 되돌려 주므로 여기서 requestId가 없다.
throw new Error('제출이 접수 확인되지 않음: 제출 완료로 표시하지 말 것');
}
return requestId;
}
async function acceptAtGoodsReceipt(certificateNumber: string): Promise<boolean> {
const res = await client.verifyCertification(certificateNumber);
// 명시적인 true만 수락한다. undefined, 오류, 시간 초과는
// 모두 "확인되지 않음"이며 부품을 격리한다.
return res.success === true && res.data?.valid === true;
}Certification.compliance에도 같은 원칙이 적용된다. 그 값으로 이익을 보는 쪽이 설정한 불리언은 주장일 뿐 증거가 아니다. 수신 시스템은 증명서 번호가 발행 당국의 원천에서 확인될 때에만 이를 받아들여야 하며, expiryDate가 지나면 다시 확인해야 한다. 형식증명처럼 유효 기한이 없는 승인도 있다. 참조 타입에서 expiryDate는 필수이므로, 이런 승인을 자리 표시용 날짜와 함께 Certification 객체에 억지로 넣어서는 안 된다. 제4장의 권고대로 metadata.approvalBasis에 기록해야 소비자가 잘못된 만료 경보를 내지 않는다.
부품의 이력은 여러 조직이, 여러 시스템에서, 때로는 오프라인으로, 수십 년에 걸쳐 기록한다. 시각과 순서에 대한 명시적 규칙이 없으면 같은 이력도 참여자마다 다르게 서술된다.
표준의 부속서 E는 1초 미만의 기한이 동기화된 시계에 달려 있으며, 이 표준이 다루는 대부분의 기한에는 stratum-2 서버를 쓰는 NTPv4로 충분하고, 결정론적 연동이 필요한 현장에는 PTP를 권장한다고 적고 있다. 회사 간 기록 교환에 1초 미만의 정밀도가 필요한 경우는 드물지만, 각 시각 값의 의미는 분명해야 한다. 그래서 6.1절의 봉투는 시각을 두 개 갖는다. occurredAt은 검사나 탈거 같은 물리적 사건이 일어난 시각으로 발신자가 진술한 값이고, recordedAt은 발신자의 시스템이 레코드를 확정한 시각이다. 둘 다 UTC 기준 ISO 8601로 쓴다. 이틀 늦게 입력된 탈거 기록도 이렇게 하면 두 사실 모두에 대해 정직해진다.
아무리 잘 동기화된 벽시계 시각이라도 조직을 가로지르는 순서의 기준으로는 믿을 수 없다. 봉투에 subjectSequence를 더하는 이유이다. 이는 해당 부품의 권위 있는 이력을 보유한 시스템이 일련번호마다 증가시키는 계수로, 소비자는 이것으로 누락(41번 메시지가 없다)을 발견하고 늦게 도착한 메시지를 재정렬할 수 있다. 비행시간과 사이클은 두 번째 물리적 검사 수단이 된다. 앞선 레코드보다 신품 이후 사이클이 적다고 주장하는 레코드는 입력 오류이거나, 서로 다른 두 부품이 한 신원을 공유하고 있다는 신호이다. 어느 쪽이든 절차를 멈춰야 한다.
격납고, 정비 공장, 본사 사이의 네트워크는 끊어지며, 재전송 때문에 검사 기록이 두 벌 생기는 것은 기록이 사라지는 것만큼 해롭다. 그래서 프로토콜은 최소 한 번 전달(at-least-once delivery)을 전제한다. 발신자는 확인 응답을 받을 때까지 재전송하고, 모든 수신자는 중복을 제거한다. idempotencyKey는 발신자가 자기 업무 식별자(예를 들어 조직, 작업 지시, 레코드 종류, 순번)로 정하므로, 프로세스가 비정상 종료된 뒤 기억을 잃은 채 재시도해도 같은 키가 만들어진다. 이미 아는 키를 받은 수신자는 변경을 다시 적용하지 않고 원래 결과를 돌려준다. 부하 때문에 요청을 거절할 때 수신자는 PHASE 2가 RFC 6585를 근거로 규정한 대로 HTTP 429와 Retry-After 헤더로 응답하고, 발신자는 최소한 그 시간만큼 기다린다.
공유 레코드의 갱신, 곧 SDK의 PUT /components/{id}에는 낙관적 동시성 제어가 필요하다. 발신자는 자신이 읽은 버전을 밝히고, 수신자는 그 뒤 레코드가 바뀌었으면 갱신을 거부한다. 이벤트를 추가하는 방식은 애초에 충돌 대부분을 피하게 해 준다. 비행시간, 사이클, 상태 변화를 여러 당사자가 덮어쓰는 필드가 아니라 이벤트로 두어야 하는 이유가 하나 더 있는 셈이다.
운항 정비 현장과 정비 공장은 안정적인 연결 없이 일하는 경우가 많다. 권장 방식은 저장 후 전달(store and forward)이다. 현장 시스템은 작업하는 순간 메시지를 만들고 서명한 뒤 occurredAt 시각과 함께 대기열에 넣었다가, 연결이 돌아오면 보낸다. 메시지가 서명되어 있고 멱등성 키를 갖고 있으므로 중간 시스템을 거쳐도 출처가 사라지지 않으며, 며칠 늦게 도착해도 수신자는 순번대로 적용할 수 있다. 피해야 할 것은 본사에서 원래 발신자 신원 없이 종이 기록을 다시 입력하는 일이다. 그렇게 하면 MRO의 기록이 사무실의 기록으로 바뀌고 책임 소재가 끊어진다.
공급자 운영자 MRO 당국
| | | |
|-- 패키지(요청) ------------------------------------------------->| [certificationPackage]
|<------------------------------------------------- 승인 / 증명서 -|
| FAI(AS9102), CoC, 8130-3 / Form 1 |
|-- 신원 + 출고 ------>| | | [componentCatalog, traceability]
| |-- 증명서 확인 --------------------------->| [certificationPackage]
| |-- 장착 이벤트 | | [maintenanceEvent]
| |<------------------------------------ AD --| [serviceBulletin]
|-- SB(설계 소지자 대행) ->| | | [serviceBulletin]
| |-- 확인 + 적용성 |
| |-- 탈거 이벤트 ---->| | [maintenanceEvent]
| | |-- 이력 조회 | [traceability]
| | |-- 검사, 수리 | [maintenanceEvent]
| |<-- Form 1 출고 ----| |
| |-- 장착 / AD 이행 기록 | [maintenanceEvent]
| | ... (공장 입고 반복) ... |
| |-- 퇴역 + 절단 훼손 기록 | [maintenanceEvent]이 그림은 traceability 그룹이 왜 중심에 있는지를 보여 준다. 모든 화살표가 같은 대상에 기록을 더하며, 나중에 오는 참여자, 곧 리스 반납 뒤의 새 운영자, 열 번째 공장 입고를 맡은 MRO, 사건 뒤의 조사관은 모두 그 흐름에서 부품을 재구성한다. 표준의 부속서 E는 대부분의 감사 기대를 충족하는 보존 하한으로 7년을 제시하고, 규제 당국이 더 긴 기간을 요구하면 배포 정책이 그 기간을 늘려야 한다고 규정한다. 수명 한계 부품과 일련번호 관리 부품의 출생 이력은 흔히 부품 수명 전체와 그 이후까지 보관된다. 프로토콜은 7년을 메시지 로그의 최소치로 다루어야 하며, 부품 이력의 상한으로 여겨서는 안 된다.
아래 실패들은 이 책이 지어낸 가상의 범주가 아니라, 부품 추적 시스템이 나쁜 부품을 들이거나 좋은 부품을 내치는 전형적인 경로이다. 각각에는 프로토콜 수준의 방어책이 있다.
미승인 부품이란 승인된 절차에 따라 제작되거나 정비되지 않았거나, 승인된 설계 자료에 합치하지 않는 부품을 말한다. 위조품, 미승인 공급원의 부품, 서류가 위조된 부품, 폐기되었다가 공급망에 다시 들어온 부품이 모두 여기에 속한다. FAA는 미승인 의심 부품(SUP)의 식별과 보고에 관한 지침을 자문회람(AC) 21-29로 발행하고 있으며, 다른 당국도 비슷한 보고 제도를 운영한다. 프로토콜은 두 가지로 돕는다. 첫째, 진품이라면 가져야 할 이력을 질의할 수 있게 해서, 이력 없이 도착한 부품이나 이력이 폐기 기록에서 끝나는 부품이 눈에 띄게 한다. 둘째, 누군가 부품 인수에 서명하기 전에 입고 검사에 기계적 점검을 제공한다. 출고 증명서를 확인하고, 명판의 세 값을 레코드와 대조하며, 상태가 production인지 확인하는 것이다. SUP 보고 자체도 대상에 연결된 메시지여야 그 일련번호를 가진 모든 보유자가 경고를 볼 수 있다.
이력의 빈틈, 곧 누락된 공장 입고, 설명되지 않는 사이클 급증, 이관 기록 없는 운영자 변경은 부품이 나쁘다는 증거는 아니지만, 부품이 좋다는 증거를 없앤다. 수명 한계 부품에서는 잔여 수명을 확정할 수 없어 부품을 쓸 수 없게 될 수도 있다. 방어책은 다음과 같다. 대상별 순번으로 빈틈을 찾아낼 수 있게 하고, 비행시간·사이클의 단조 증가 검사로 앞뒤가 맞지 않는 이력을 찾아내며, 운영자 간 이관을 누적 이력을 담은 독립 메시지로 규정해 가장 흔한 빈틈을 막는다.
두 데이터베이스를 합치면 같은 일련번호가 두 번 나타나는 일이 흔하다. 제작사나 부품번호가 다른 서로 다른 부품인 경우는 정당하다. 표기만 조금 다르게 두 번 기록된 한 부품인 경우도 있고, 드물게는 같은 신원을 단 물리적 부품 두 개 가운데 하나가 자신이 주장하는 부품이 아닌 경우도 있다. 대상을 제작사·부품번호·일련번호의 세 값 조합으로 규정하는 프로토콜 규칙은 첫 번째 경우를 해결한다. 두 번째와 세 번째는 자동으로 해결할 수 없다. 데이터 이전 시에는 문서화된 규칙에 따라 표기(대소문자, 앞자리 0, 구분 기호)를 정규화하고, 남은 충돌은 모두 사람이 검토하도록 표시하며, 이력을 조용히 병합해서는 절대 안 된다.
| 실패 사례 | 데이터에 드러나는 모습 | 방어책 |
|---|---|---|
| 미승인 의심 부품 | 이력 없음, retired에서 끝나는 이력, 확인에 실패하는 출고 증명서 | 입고 시 필수 확인, 대상에 연결된 SUP 보고 메시지, 실패 시 거부 원칙 |
| 끊어진 출생 이력 | subjectSequence의 빈틈, 감소하는 사이클, 이관 기록 없는 소유자 변경 | 대상별 순번, 단조 증가 계수, 명시적 이관 메시지 |
| 이전 후 중복 S/N | 같은 S/N에 기간이 겹치는 두 레코드 | 세 값 조합 키, 문서화된 정규화, 충돌에 대한 사람의 검토 |
| 재전송으로 인한 중복 이벤트 | 몇 초 간격의 동일한 검사 기록 두 건 | 발신자가 정하는 멱등성 키, 수신자의 중복 제거 |
| AD/SB 혼동 | 선택 SB가 기한 초과로 추적되거나, AD가 이행 없이 "확인"으로만 기록됨 | directiveKind, 확인과 이행 메시지의 분리 |
| 참조 클라이언트 맹신 | 시험에서 모든 호출이 "성공" | 실제 서버를 대상으로 시험, 누락 필드는 실패로 처리 |
마지막 행은 다시 강조할 가치가 있다. 시뮬레이터의 프로토콜 탭은 성공한 호출을 나열한 고정 로그를 출력하고, SDK는 입력을 그대로 되돌려 준다. 둘 다 교환의 모양을 익히는 데는 유용하지만, 통합이 올바른지는 알려 주지 않는다. 그것을 알려 주는 테스트 벡터와 적합성 증거는 제8장에서 설명한다.
ComponentStatus의 모든 전이는 이름 붙은 증거로 정당화되어야 하며, retired는 종착 상태이다.Inspection 레코드, 승인 자료 참조, 정비 출고를 운반한다. conditional 결과에는 발견 사항과 다음 검사 한계가 필요하다.occurredAt과 recordedAt, 순번, 멱등성을 갖춘 최소 한 번 전달, 오프라인 현장의 저장 후 전달을 사용한다. 7년 보존은 로그의 하한일 뿐 부품 이력의 상한이 아니다.