제7장: 통합·품질체계·정비 프로그램

7.1 AS9100D·AS9145와의 매핑

표준의 PHASE 4는 짧은 목적 선언으로 시작한다. 지속 감항성 증거의 패키징, 형식증명 당국에 제출하는 서명된 증명, 그리고 "이 PHASE의 객체 유형을 AS9100D 및 AS9145 품질경영 요구에 매핑하는 것"을 정의한다는 것이다. 그러나 명세서는 두 품질 표준의 이름만 들 뿐 매핑 내용은 적지 않았다. 이 절은 그 빈자리를 채운다. 매핑이 있어야 WIA 레코드가 개발자에게 깔끔한 데이터에 그치지 않고 심사원에게 쓸모 있는 증거가 되기 때문이다.

데이터 표준이 품질경영시스템의 언어를 써야 하는 이유

인증된 제품에 들어가는 항공기 부품을 설계·제작·정비하는 조직은 모두 품질경영시스템(QMS)을 운영한다. 실제로는 거의 언제나 AS9100D(유럽에서는 EN 9100, 아시아에서는 JISQ 9100으로 발행)이거나, 정비 조직용 AS9110, 유통업체용 AS9120 같은 부문별 변형이다. AS9100D는 ISO 9001:2015의 구조 위에 항공우주 고유의 요구사항을 더한다. 형상관리, 제품 안전, 위조 부품 방지, 초도품 검사, 특수공정 관리, 핵심 특성 관리 등이 여기에 속한다.

심사원은 데이터베이스가 있느냐고 묻지 않는다. 이 일련번호가 올바른 소재 로트로 만들어졌음을 어떻게 아는지, 열처리 협력업체의 승인은 어디 있는지, 현행 도면 개정판에 대한 초도품 검사 보고서는 무엇인지를 보여 달라고 한다. 이런 질문마다 WIA 객체 안에 분명한 자리가 있다면 WIA 구현은 QMS 증거의 일부가 된다. 그렇지 않다면 매번 심사 전에 수작업으로 대조해야 하는 또 하나의 시스템이 될 뿐이다.

조항별 매핑

아래 표는 부품 레코드와 가장 직접 관련된 AS9100D 조항을, 그 증거를 담을 수 있는 WIA-SPACE-016 객체와 짝지은 것이다. types.ts의 참조 타입에 알맞은 필드가 없으면 그 사실을 밝히고, 추가형 확장이 합의될 때까지 구현이 쓸 수 있는 metadata 키를 제시했다. 마지막 열의 키 이름은 이 책의 제안이며 표준이 정의한 이름이 아니다.

표에서 두 가지를 읽을 수 있다. 첫째, 공백의 대부분은 연결의 문제이다. WIA 레코드는 부품 자체는 잘 식별하지만, 심사원이 이미 보관하고 있는 문서(도면 개정판, FAI 보고서, 출고 증명서, 부적합 보고서)를 가리키지 않는다. 둘째, Certification 객체는 성격이 다른 두 가지를 하나로 뭉쳐 놓았다. 설계 수준의 승인(TSO 인가, 부가형식증명, 부품제작자증명)과 물리적 품목 하나에 대한 출고 문서(FAA Form 8130-3 또는 EASA Form 1)는 발행 주체도, 유효 기간도, 의미도 다르다. 이후 버전에서 객체가 분리되기 전까지 구현은 예컨대 metadata.certificateKind로 자신이 보유한 것이 어느 쪽인지 기록해야 한다.

AS9145: 첫 부품 이전에 품질을 계획한다

AS9145는 선행 제품 품질 계획(APQP)과 양산 부품 승인 절차(PPAP)를 항공우주에 맞게 옮긴 표준이다. 신제품 도입을 다섯 단계로 나눈다. 계획, 제품 설계·개발, 공정 설계·개발, 제품·공정 유효성 확인, 그리고 양산·사용·인도 후 단계이다. 대표적 산출물로는 설계 및 공정 고장모드영향분석(DFMEA, PFMEA), 관리 계획서, 측정 시스템 분석, 공정 능력 연구, 초도품 검사, 그리고 마지막에 고객이 승인하는 PPAP 제출물이 있다.

이 단계들은 생각보다 ComponentStatus 열거형과 잘 맞는다. design은 앞의 두 단계에, testing은 공정 설계와 유효성 확인에 해당하고, certified로의 전이는 유효성 확인 증거가 갖추어지기 전에는 일어나서는 안 된다. production은 양산 단계에 대응한다. 구현자가 지켜야 할 실무 원칙은 상태 전이 자체가 하나의 품질 이벤트라는 것이다. FAI 기록과 PPAP 승인 참조 없이 testing에서 production으로 넘어간 전이는 머지않아 심사 지적사항이 된다. 잘 설계된 구현은 그런 전이를 조용히 기록하지 않고 거부한다.

형상관리와 위조 부품 방지

형상관리는 한 가지 질문을 끝없이 되풀이한다. 지금 눈앞에 있는 실물이 승인된 설계가 기술하는 바로 그 품목인가? 부품 레코드의 관점에서 이는 부품번호만으로는 부족하다는 뜻이다. 같은 부품번호가 여러 도면 개정판으로 존재할 수 있고, 서비스 불리틴이 번호를 바꾸지 않은 채 부품을 개조할 수도 있다(이때 개조 상태는 명판에 표시된다). partNumber만 저장하는 레코드는 형상 질문에 답할 수 없다. 구현은 도면 개정판과 반영된 개조 목록을 함께 보관하고, 그중 하나라도 바뀌면 작성자·사유·근거 문서가 필요한 갱신으로 다루어야 한다.

위조 부품과 미승인 의심 부품(6장에서 실패 사례로 다루었다)은 같은 동전의 뒷면이다. AS9100D 8.1.4항은 원제작사나 인가된 제작사로부터의 조달, 문서 검증을 포함하여 위조 부품을 방지하는 프로세스를 계획하고 관리하도록 요구한다. WIA가 보탤 수 있는 몫은 크지 않지만 실질적이다. 발행 주체에 대한 verifyCertification 호출, 그리고 소유권이 바뀔 때마다 서명되는 추적 체인이다. 둘 다 부품과 표식에 대한 물리적 검사를 대신하지는 못하지만, 서류상의 이력을 사후에 지어내기 어렵게 만든다.

7.2 특수공정과 Nadcap

특수공정이란 그 결과를 완성품에 대한 후속 검사나 시험으로 완전히 검증할 수 없는 공정을 말한다. 열처리가 대표적이다. 잘못된 온도로 시효 처리한 7075 단조품은 올바른 것과 겉보기에 똑같고 경도마저 공차 안에 들 수 있지만, 파괴 인성과 응력부식균열 저항성은 손상되었을 수 있다. 제품이 스스로 옳음을 증명할 수 없으므로 대신 공정이 증명되어야 한다. 검증된 절차, 자격을 갖춘 작업자, 교정된 장비, 그리고 매 회차의 기록이 그 수단이다.

어떤 공정이 "특수"한가

목록은 물리 법칙이 아니라 고객과 품질체계가 정하지만, 대체로 다음을 포함한다. 열처리, 화학 처리(양극산화, 도금, 화성 피막, 화학 밀링), 코팅, 용접과 브레이징, 비파괴 검사, 복합재 제작과 접착, 쇼트 피닝 등 표면 강화, 그리고 일부 측정·검사 활동이다. PHASE 4 명세서는 용접, 열처리, NDT, 화학 처리, 복합재를 나열하며, Nadcap 프로그램은 이들을 포함해 더 넓은 범위를 다룬다.

Nadcap 개요

Nadcap은 특수공정에 대한 산업계 주도 인정 프로그램으로, Performance Review Institute(PRI)가 운영한다. 주요 완제기·엔진 제작사들이 태스크 그룹에 참여해 공정 분야(commodity)별 심사 체크리스트를 작성하고, 공급자는 그 체크리스트에 따라 심사를 받는다. 참여 제작사들은 개별 고객 심사 대신 이 인정을 인정한다. 인정은 공정 분야별, 사업장별로 부여된다.

명세서에 적힌 심사 주기("6~12개월마다 사후 심사, 2~3년마다 재인증")는 Nadcap의 실제 운영 방식을 나타내지 않으므로 사용해서는 안 된다. Nadcap 인정 기간은 실적(merit)에 따라 달라진다. 공급자는 12개월 주기로 시작하고, 양호한 심사 실적을 유지하면 인정 기간을 18개월 또는 24개월로 늘릴 수 있다. 세부 기준은 PRI와 태스크 그룹이 정하고 수시로 바뀌므로, 구현은 만료일을 계산하지 말고 실제 인정서의 만료일을 저장해야 한다.

공정 기록을 일련번호에 연결하기

추적성의 관점에서 특수공정 기록은 어떤 일련번호가 어느 회차를 거쳤는지를 말해 줄 때만 쓸모가 있다. 열처리로 한 번의 장입에는 수십 개의 부품이 들어갈 수 있고, 화학 처리 라인은 한 조에서 배치 전체를 처리하며, NDT 기술자는 한 근무조 동안 피팅 한 로트를 검사할 수 있다. 공정 이탈이 발견되면 질문은 언제나 "그 장입에 어떤 부품이 있었나?"이고, 그 답은 몇 주가 아니라 몇 분 안에 나와야 한다.

참조 AircraftComponent에는 공정 이력을 담을 필드가 없으므로, 아래 레코드는 이를 metadata에 담는 한 가지 방법을 보여 준다. metadata.processRecords 아래의 모든 내용은 규범적 구조가 아니라 예시 확장이며, 식별자와 인정서 번호는 지어낸 자리표시자이다.

{
  "id": "cmp-7f3a91",
  "type": "landing-gear",
  "status": "production",
  "partNumber": "EXAMPLE-MLG-TL-0042",
  "serialNumber": "TL-000731",
  "manufacturer": "Example Forge & Machining",
  "manufacturingDate": "2026-03-18",
  "metadata": {
    "materialLot": "HEAT-EX-55120",
    "processRecords": [
      {
        "process": "heat-treatment",
        "specification": "customer process spec, rev C",
        "sourceAccreditation": {
          "program": "Nadcap",
          "commodity": "heat treating",
          "expires": "2027-01-31"
        },
        "loadId": "FURN2-2026-0311-04",
        "completed": "2026-03-11"
      },
      {
        "process": "penetrant-inspection",
        "specification": "customer NDT spec, rev F",
        "operatorCertification": "EN 4179 level 2",
        "result": "accept",
        "completed": "2026-03-15"
      }
    ]
  }
}

이 예시에서는 필드 이름보다 두 가지 설계 선택이 더 중요하다. 첫째, 인정 상태를 공정이 수행된 날의 모습 그대로, 자체 만료일과 함께 기록했다. 그래야 나중에 인정이 만료되더라도 공급원이 승인된 동안 만든 부품이 소급해서 무효가 되지 않는다. 둘째, 열처리 장입에 고유 식별자를 주었다. 그래야 "FURN2-2026-0311-04 장입에 어떤 일련번호가 있었나?"라는 역방향 질문에 레코드 전체를 대상으로 한 간단한 조회로 답할 수 있다.

7.3 정비 프로그램

부품이 운용에 들어가면 그 레코드를 움직이는 주체는 제작사에서 운영자의 정비 프로그램으로 옮겨 간다. 그 프로그램이 어떻게 만들어지는지 알면, 어떤 검사 일자와 주기가 레코드에 들어가는지, 왜 그런 형태로 표현되는지를 이해할 수 있다.

MSG-3에서 운영자 프로그램까지

수송류 항공기의 초기 정기 정비는 Airlines for America(A4A)가 관리하는 MSG-3 방법론으로 개발된다. 정비심의위원회(MRB) 또는 제작사·운영자·당국으로 구성된 작업반이 각 계통, 구조 항목, 구역을 분석하고, 그 결과는 당국이 승인하는 정비심의위원회 보고서(MRBR)로 발행된다. 제작사는 이 작업들을 실무 정보와 묶어 정비계획문서(MPD)를 낸다. 각 운영자는 MPD를 바탕으로 자신의 운용률, 환경, 신뢰성 자료에 맞춘 승인된 정비 프로그램을 만든다.

MSG-3는 작업 중심이다. 계통과 동력장치에 대해서는 윤활·보급, 작동 또는 육안 점검, 검사 또는 기능 점검, 복원, 폐기 같은 작업 유형이 도출된다. 구조에 대해서는 우발 손상, 환경 열화(주로 부식), 피로 손상의 세 가지 열화 원인을 평가한다. 그 이전 MSG-2의 용어는 정비 프로세스를 하드 타임, 온컨디션, 컨디션 모니터링으로 구분했다. 이 용어들은 지금도 일상적으로 쓰이며, 특정 부품이 어떻게 관리되는지 설명하는 데 여전히 유용하다.

점검 패키지와 주기

운영자는 작업들을 점검 패키지로 묶는다. 흔히 쓰는 이름은 라인 점검, A 점검, C 점검, 그리고 중정비 구조 점검(지금도 D 점검이라 부르기도 한다)이다. 명세서에 인용된 주기(예: "A 점검은 500~800 비행시간마다", "D 점검은 6~10년마다")는 일부 기단에서는 그럴듯하지만 표준값이 아니다. 주기는 기종별 MPD와 운영자별 프로그램이 정하며, 일부 최근 프로그램은 문자 점검을 아예 쓰지 않고 작업마다 개별 주기로 계획한다(균등화 정비 또는 작업 기반 정비). WIA 구현은 점검 이름에서 도래 시점을 유도해서는 결코 안 된다.

WIA 구현이 반드시 다루어야 할 것은 하나의 작업 주기가 흔히 여러 단위로 표현된다는 사실이다. 비행시간, 비행 사이클, 달력 시간이 함께 주어지고 "먼저 도래하는 것"이 규칙이 된다. 참조 Inspection 타입은 달력 필드인 nextInspectionDate만 제공한다. 주도 변수가 사이클인 부품(착륙장치, 여압 구조)에는 이것으로 충분하지 않다. 현실적인 방법은 nextInspectionDate를 운용률로 계산한 예측값으로 두고, 지배 한계를 명시적으로 함께 싣는 것이다.

{
  "id": "insp-2026-0412",
  "inspectionDate": "2026-04-12",
  "inspector": "MRO-EX / stamp 118",
  "method": "eddy-current",
  "result": "pass",
  "findings": "No indications at lug bore, both sides.",
  "nextInspectionDate": "2027-02-01",
  "metadata": {
    "taskReference": "operator AMP task, example ref 32-11-01-210",
    "interval": { "flightCycles": 3000, "calendarMonths": 24, "rule": "whichever-first" },
    "atInspection": { "flightCycles": 18450, "flightHours": 31200 },
    "forecastBasis": "fleet average utilisation, recomputed monthly"
  }
}

여기서 nextInspectionDate는 운용률에 따라 움직이는 예측값일 뿐이며, 권위 있는 도래 시점은 주기와 검사 시점의 누적값이다. 둘을 함께 보관해야 나중에 날짜가 왜 바뀌었는지 설명할 수 있다.

7.4 비파괴 검사 방법

비파괴 검사(정비에서는 NDI, 제작에서는 흔히 NDT라 부른다)는 부품을 손상하지 않고 결함을 찾아내는 기법들의 집합이다. 대부분의 Inspection 기록 뒤에 있는 물리적 활동이 이것이며, 어떤 방법을 썼느냐에 따라 기록이 주장할 수 있는 범위가 정해진다. 같은 피팅에 대해 육안 검사의 "합격"과 와전류 검사의 "합격"은 같은 진술이 아니다.

주요 방법

육안 검사는 일반 육안과 상세 육안으로 나뉘며 조명, 거울, 확대경, 보어스코프를 쓴다. 지금도 가장 흔한 방법으로, 부식, 충격 손상, 누유, 빠진 체결재, 눈에 보일 만큼 큰 균열을 찾는다. 침투 탐상 검사는 색이나 형광을 띤 액체를 모세관 현상으로 표면 개구 결함에 스며들게 한 뒤, 여분을 닦아 내고 현상제로 다시 끌어내어 지시 모양을 보이게 한다. 다공성이 아닌 재료라면 어디에나 쓸 수 있지만 표면에 열린 결함만 찾는다.

자분 탐상 검사는 강자성 부품을 자화한다. 표면이나 표면 바로 아래의 균열은 자기장을 교란해 누설 자속을 만들고, 여기에 미세한 철 입자가 모여 눈에 보이는 선이 된다. 알루미늄, 티타늄, 오스테나이트계 스테인리스강, 복합재에는 쓸 수 없으므로 기체 구조 대부분에는 부적합하지만, 강재 착륙장치와 엔진 마운트 부품에서는 주력 방법이다.

와전류 검사는 프로브 코일로 도전성 부품에 교류 전류를 유도한다. 균열은 전류 경로를 끊어 코일의 임피던스를 바꾼다. 감도는 표면 근처에 집중되며, 표준 침투 깊이는 다음과 같다.

δ = 1 / √(π · f · μ · σ)

  f  여기 주파수 (Hz)
  μ  투자율 (H/m); 비자성 합금은 μ0 = 4π × 10⁻⁷
  σ  전기 전도도 (S/m)

예시(설명용): 2024-T3 알루미늄, 전도도 약 30 % IACS
  σ ≈ 0.30 × 58 MS/m ≈ 17.4 MS/m,  f = 100 kHz
  δ ≈ 1 / √(π × 10⁵ × 4π × 10⁻⁷ × 1.74 × 10⁷) ≈ 0.38 mm

이 식은 표면 균열에는 높은 주파수를, 겹침 이음의 2층 균열과 부식에 의한 두께 감소에는 낮은 주파수를 쓰는 이유를 설명해 준다.

초음파 검사는 고주파 음파를 부품 안으로 보내 반사파를 듣거나(펄스 에코) 투과 신호의 손실을 본다(투과법). 내부 결함을 찾고 두께를 측정하며, 층간 박리와 접착 분리를 탐지하는 복합재의 주된 검사 방법이다. 위상배열 프로브는 빔을 전자적으로 조향·집속하여 단일 파형 대신 영상을 만든다. 방사선 투과 검사는 X선이나 감마선원을 써서 흡수 차이를 필름 또는 디지털 검출기에 기록한다. 기공, 개재물, 이물질, 허니콤 내부의 수분 침투를 보여 주지만, 빔 방향과 나란하지 않은 균열에는 둔감하고 방사선 안전 관리가 필요하다.

방법의 선택과 기록

표는 참조 열거형의 공백을 드러낸다. 가장 널리 쓰이는 방법 중 하나인 침투 탐상에 해당하는 값이 없다. 일상 정비에서는 덜 흔하지만 적외선 열화상, 전단 간섭법, 음향 방출도 빠져 있다. 열거형에 값을 더하는 일은 형식상 추가형 변경이지만, 부속서 E의 규칙("새로운 선택 필드 같은 추가형 변경은 호환성을 깨지 않는다")으로 열거형 문제가 정리되지는 않는다. 옛 목록으로 엄격하게 검증하는 소비자는 "penetrant"를 담은 레코드를 거부할 것이기 때문이다. 표준의 새 버전이 값을 추가하기 전까지 안전한 선택은 findings에 가장 정직한 설명을 적고 실제 방법은 metadata.ndiMethod에 기록하는 것이다. 검증을 통과하려고 침투 탐상을 visual로 적는 일은 절대 없어야 한다.

모든 NDI 기록에는 세 가지 사실이 더 따라가야 한다. 이것이 없으면 "합격"을 평가할 수 없기 때문이다. 사용한 절차(대개 제작사 비파괴 검사 매뉴얼의 작업), 검사자의 자격 수준(항공우주 NDT 인원은 보통 NAS 410 또는 EN 4179에 따라 자격을 받는다), 그리고 장비와 대비 시험편의 식별 및 교정 상태이다. 참조 타입에는 자유 텍스트인 inspector 하나뿐이다.

7.5 피로와 손상 허용

검사 주기가 존재하는 이유는 대부분 피로 때문이다. 항공기 구조는 돌풍과 기동으로 비행마다 수천 번, 여압으로 비행마다 한 번 하중을 받고, 그 한 번 한 번이 어떤 단일 하중으로도 시작되지 않았을 균열을 조금씩 진전시킨다. 이에 대응하는 설계 철학은 세 가지였다. 안전 수명(safe-life) 설계는 큰 분산 계수를 두고 균열이 예상되기 전에 부품을 퇴역시킨다. 착륙장치 부품과 일부 엔진 부품에는 지금도 쓰인다. 페일 세이프(fail-safe) 설계는 대체 하중 경로를 두어 부재 하나가 파손되어도 구조 전체를 잃지 않게 한다. FAR/CS 25.571이 수송류 기체에 요구하는 손상 허용(damage tolerance)은 결함이 존재한다고 가정하고, 그 결함이 임계 크기에 이르기 전에 검사로 발견됨을 보인다.

S-N 곡선과 마이너 법칙

안전 수명 해석은 S-N 곡선에서 출발한다. 일정 응력 진폭 S에서 파단까지의 사이클 수 N을 시편이나 부품으로 측정한 것이다. 실제 운용 하중은 여러 진폭이 섞여 있으며, 이를 합산하는 가장 널리 쓰이는 방법이 팜그렌-마이너 선형 누적 손상 법칙이다.

D = Σ nᵢ / Nᵢ        관례상 D가 1에 이르면 파단으로 예측

예시(설명용 수치이며 재료 데이터가 아님):
  블록 1: N₁ = 100 000인 수준에서 n₁ = 20 000 사이클   → 0.20
  블록 2: N₂ =  25 000인 수준에서 n₂ =  5 000 사이클   → 0.20
  D = 0.40   → 예측 수명의 40 % 소진

마이너 법칙은 하중 순서 효과를 무시하고, 시험 결과는 D = 1 주변에 넓게 흩어진다. 안전 수명 한계에 큰 계수가 붙는 이유가 이것이다. 기록 시스템이 안전 수명을 계산해서는 안 된다. 그 역할은 승인된 한계와 소진된 사이클을 정확히 저장하는 것이다.

여기서 5장의 경고를 다시 한 번 강조한다. SDK의 도우미 함수 ComponentAnalyzer.estimateFatigueLife는 N = 10^(8 − 3·log10(S/Su))를 구현하는데, 응력 S가 극한 강도 Su와 같을 때 1억 사이클을 돌려준다. 극한 강도까지 하중을 받는 실제 부품은 한 사이클에 파단된다. 이 함수는 반면교사일 뿐이며 StructuralAnalysis.fatigueLife의 값을 만드는 데 써서는 안 된다.

균열 성장: 파리스 법칙

손상 허용은 균열의 발생이 아니라 성장을 다룬다. 선형 탄성 파괴역학은 균열 선단의 응력장을 응력확대계수 K로 기술하며, 중간 영역의 성장 속도에서 사이클당 균열 진전량은 응력확대계수 범위의 거듭제곱 법칙을 따른다. 이것이 파리스 법칙이다.

da/dN = C · (ΔK)^m          ΔK = Y · Δσ · √(π · a)

  a    균열 길이 (m)               N   사이클 수
  Δσ   응력 범위 (MPa)             Y   형상 계수 (무차원)
  C, m 균열 성장 시험에서 얻은 재료 상수

파괴 인성 Kc로부터 임계 균열 길이:
  a_c = (1/π) · (Kc / (Y · σ_max))²

적분 (Y 일정, m ≠ 2):
  N(a₀→a₁) = [a₀^(1−m/2) − a₁^(1−m/2)] / [C · (Y·Δσ·√π)^m · (m/2 − 1)]

예제 — 모든 값은 설명용이며 설계 자료가 아님:
  C = 1 × 10⁻¹¹ (m/cycle, ΔK 단위 MPa·√m), m = 3, Y = 1.0
  Δσ = σ_max = 150 MPa (R = 0), Kc = 60 MPa·√m

  a_c = (1/π) · (60 / 150)² ≈ 0.0509 m ≈ 51 mm
  가정 초기 결함          a₀    = 1.27 mm
  신뢰성 있게 탐지 가능한 크기 a_det = 5 mm (선택한 NDI 방법 기준)

  a₀   → a_c 성장: N ≈ 251 000 사이클
  a_det → a_c 성장: N ≈ 103 000 사이클

  각각에 예시 계수 2를 적용하면:
    검사 개시 시점 ≈ 251 000 / 2 ≈ 125 000 사이클
    반복 검사 주기 ≈ 103 000 / 2 ≈  51 000 사이클

이 수치는 일부러 단순하게 잡았고, 실제 구조 상세보다 훨씬 관대하다. 체결 구멍의 응력 집중은 Y를 1보다 훨씬 크게 만들고, 실제 하중 스펙트럼은 일정 진폭이 아니며, 적용 계수는 형식증명 소지자가 승인받은 방법론의 것을 따른다. 예제가 보여 주는 것은 FAR/CS 25.571이 요구하는 논리이다. 검사 개시 시점은 가정 초기 결함의 성장에서, 반복 주기는 탐지 가능 크기에서 임계 크기까지의 성장에서 나오며, 탐지 가능 크기는 검사 방법에 달려 있다. 방법을 상세 육안에서 와전류로 바꾸면 탐지 가능 크기가 줄고, 성장 구간이 넓어지며, 주기를 늘릴 수 있다. Inspection 기록의 방법 필드가 사소한 세부 사항이 아닌 이유가 여기에 있다.

명세서의 "검사 개시는 계산 수명의 50%", "반복 검사는 10,000 비행마다"라는 서술은 이 논리에서 나오지 않으므로 규칙으로 써서는 안 된다.

광역 피로 손상, 유효 한계, 부식

손상 허용은 균열이 하나씩 생긴다고 가정한다. 기체가 노후하면 겹침 이음을 따라서처럼 비슷한 구조 상세 여러 곳에서 작은 균열이 동시에 나타날 수 있고, 이들이 합쳐져 어느 한 균열도 탐지되기 전에 잔류 강도를 떨어뜨릴 수 있다. 이것이 광역 피로 손상(WFD)이다. 미국의 14 CFR Part 26은 대형 수송기의 형식증명 소지자에게 정비 프로그램을 뒷받침하는 공학 자료의 유효 한계(LOV)를 비행 사이클이나 비행시간으로 정하도록 요구하며, 운영자는 추가 승인 조치 없이 그 한계를 넘어 운항할 수 없다. EASA도 비슷한 요구를 두고 있다. WIA 레코드에서 LOV는 개별 부품이 아니라 항공기의 속성이지만, 그 구조에 장착된 부품은 그 결과를 그대로 물려받는다.

부식은 구조 열화의 또 다른 주된 원인이다. 수송기 운영자는 부식 방지 및 관리 프로그램(CPCP)을 운영하며, 부식 발견 사항을 심각도에 따라 등급화하고 작업 주기에 반영한다. 부식 발견 사항은 등급과 위치를 붙여 Inspection.findings에 기록해야 기단 추세를 분석할 수 있다.

StructuralAnalysis에 무엇을 담는가

참조 StructuralAnalysis 객체는 적용 하중, 계산 응력, 안전계수, 사이클 단위 피로 수명, 일자, 해석자를 담는다. 1장에서 다룬 정적 강도 확인의 결과를 기록하기에는 충분하지만 손상 허용 해석에는 부족하다. 손상 허용 결과에는 최소한 가정 초기 결함, 탐지 가능 크기와 그 방법, 임계 크기, 검사 개시 시점과 반복 주기, 승인된 해석 보고서의 참조가 필요하다. 표준이 그런 객체를 정의하기 전까지 구현은 보고서 참조와 승인된 개시 시점·주기를 저장해야 하며, 오독을 부르는 단일 "피로 수명" 숫자를 저장해서는 안 된다.

7.6 증거 패키지

PHASE 4는 두 가지를 요구한다. 지속 감항성 증거를 CycloneDX 1.5 문서로 패키징할 것, 그리고 in-toto Attestation Framework 1.0으로 작성하고 Sigstore(DSSE 봉투와 Rekor 투명성 로그 항목)로 서명한 증명을 당국에 제출할 것이다. 명세서는 형식의 이름만 들고 항공기 부품이 그 형식에 어떻게 들어가는지 예시를 주지 않는다. 이 절은 하나의 방안을 제안한다.

부품을 자재 명세서로 기술하기

CycloneDX는 소프트웨어 자재 명세서(SBOM) 형식으로 출발했지만, 하드웨어(device)와 내장 소프트웨어(firmware)를 위한 구성요소 유형이 있고, 어떤 구성요소에든 이름–값 쌍의 properties를 붙일 수 있다. 이것만으로도 항전 LRU를 하드웨어 부품번호, 탑재 소프트웨어 부품번호, 일련번호와 함께 기술하고 WIA 레코드를 가리킬 수 있다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-05-02T08:14:00Z",
    "component": {
      "type": "device",
      "bom-ref": "lru-vhf-00417",
      "name": "VHF transceiver (example)",
      "version": "HW mod status 3",
      "supplier": { "name": "Example Avionics" },
      "properties": [
        { "name": "wia:partNumber",   "value": "EX-VHF-9000-01" },
        { "name": "wia:serialNumber", "value": "00417" },
        { "name": "wia:componentId",  "value": "cmp-a02c55" },
        { "name": "wia:status",       "value": "maintenance" }
      ]
    }
  },
  "components": [
    {
      "type": "firmware",
      "bom-ref": "sw-vhf-ops",
      "name": "VHF operational software (example)",
      "version": "EX-SW-VHF-0305",
      "hashes": [
        { "alg": "SHA-256",
          "content": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08" }
      ]
    }
  ],
  "dependencies": [
    { "ref": "lru-vhf-00417", "dependsOn": [ "sw-vhf-ops" ] }
  ]
}

wia: 속성 이름은 이 책의 제안이다. CycloneDX는 속성 이름이 문자열이기만 하면 되므로, 이름공간 접두어를 붙여 다른 분류 체계와의 충돌을 피했다. 소프트웨어 부품번호가 해시와 함께 독립된 구성요소로 기록되었다는 점에 주목하라. 이는 4장에서 지적한 공백, 곧 참조 AircraftComponent 타입에 소프트웨어 부품번호를 둘 자리가 없다는 문제를 메운다. 무엇이 탑재되어 있는지의 권위 있는 목록은 부품 레코드가 아니라 BOM이 된다.

검사를 증명하기

BOM은 품목이 무엇인지를 말한다. 증명(attestation)은 그 품목에 누가 무엇을 했는지를 말한다. in-toto Statement는 암호학적 다이제스트로 식별되는 주체(subject)와 선언된 유형의 술어(predicate)를 감싼다. 아래의 술어 유형은 설명을 위해 지어낸 것이다. WIA-SPACE-016은 술어 유형을 정의하지 않았으며, 이를 신뢰하려면 작업반이 먼저 공표해야 한다.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "wia-record/cmp-7f3a91.json",
      "digest": { "sha256": "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae" }
    }
  ],
  "predicateType": "https://example.org/wia-space-016/inspection/v0.1",
  "predicate": {
    "inspectionId": "insp-2026-0412",
    "method": "eddy-current",
    "result": "pass",
    "procedure": "NDT manual task (example ref)",
    "inspectorQualification": "EN 4179 level 2",
    "organisationApproval": "Part-145 approval reference (example)"
  }
}

Statement는 직렬화되어 base64로 인코딩된 뒤 DSSE 봉투(payloadType은 application/vnd.in-toto+json)에 담겨 서명된다. Sigstore를 쓰면 서명자는 조직 신원에 결합된 단기 인증서를 사용할 수 있고, 서명은 Rekor 투명성 로그에 기록된다. 그 덕분에 누구든 나중에 사설 인증기관을 신뢰하지 않고도 증명이 언제 만들어졌고 변조되지 않았는지 확인할 수 있다. cosign attest와 cosign verify-attestation 같은 도구가 이 단계를 수행한다.

서명이 기록을 참으로 만들지는 않는다. 서명은 누가 언제 무엇을 주장했는지를 증명할 뿐, 검사가 올바르게 수행되었음을 증명하지 않는다. 그 가치는 사후 변경을 탐지할 수 있게 하고 모든 주장에 책임 주체를 묶어 둔다는 데 있으며, 이것이 바로 출생 이력 추적에 필요한 것이다.

보존

부속서 E는 7년 보존 기간이면 대부분의 관할에서 ISO/IEC 17065 심사 기대를 충족하며, 규제 당국이 더 긴 기간을 요구하면 배포 정책이 보존 기간을 늘려야 한다고 적고 있다. 항공기 부품에서는 "더 긴 기간"이 흔하다. 수명 한계 부품의 상태와 부품의 출생 이력을 입증하는 기록은 부품이 운용되는 동안 계속 따라다녀야 하고, 퇴역 이후까지 보관되는 경우도 많다. 따라서 7년은 감사 로그의 하한으로 보아야 하며 부품 레코드의 수명으로 보아서는 안 된다. 서명된 패키지는 투명성 로그 항목과 함께 보관해야 서명 인증서가 만료된 뒤에도 검증할 수 있다.

7.7 기존 시스템 연동

빈 데이터베이스에서 WIA 구현을 시작하는 조직은 없다. 공급자는 품목 마스터와 로트 추적을 갖춘 ERP를, MRO 조직은 작업지시서와 공장 발견 사항을 담은 정비 정보 시스템을, 항공사는 수십 년을 거슬러 올라가는 장착 부품 이력을 가진 기술 기록 시스템을 운영한다. WIA 구현은 이런 시스템과 데이터를 주고받으면서도 서로 어긋나는 두 번째 진실을 만들지 않을 때에만 성공한다.

기존 산업 어휘

이미 확립된 두 계열의 명세가 상당 부분을 다루고 있다. Airlines for America가 관리하는 ATA Spec 2000은 항공 공급망의 전자상거래 표준으로, 부품의 영구 표식과 자동 식별(부품의 2D 코드), 출고 증명서와 신뢰성 자료의 전자 교환 등을 포함한다. ATA iSpec 2200과 그 전신인 ATA 100은 정비 매뉴얼 전반에 쓰이는 챕터-섹션-주제 번호 체계를 정의하며, S1000D는 공통 소스 데이터베이스에 기반한 기술 간행물의 국제 명세이다. WIA 레코드는 이들 중 어느 것도 대체하지 않으며, 이들을 참조해야 한다. 가장 즉각적인 활용은 각 부품에 ATA 챕터를 붙이는 것이다. 그래야 레코드를 매뉴얼, 작업 카드, 신뢰성 보고서와 결합할 수 있다.

이 표는 아홉 개의 ComponentType 값만으로는 연동에 너무 거칠다는 점도 보여 준다. avionics는 통신, 항법, 지시·기록 계통을 모두 아우르므로, 유형으로 검색하면 VHF 무선기부터 비행자료기록장치까지 전부 나온다. metadata.ataChapter에 ATA 챕터를 저장하면 부족한 해상도를 적은 비용으로 보탤 수 있다.

식별자 대조

이관 프로젝트는 형식보다 식별자에서 훨씬 자주 실패한다. 부품번호는 대시가 있기도 없기도 하고, 뒤에 공백이 붙거나 대소문자가 다르며, ERP가 붙인 공급자 접두어를 달고 들어온다. 같은 일련번호를 두 제작사가 부여할 수 있다. 대체된 옛 부품번호가 오래된 기록에 남아 있다. 개조 후 재식별되어 명판을 두 개 단 부품도 있다. 다음 원칙이 대조를 정직하게 지켜 준다.

• 키는 가정하지 말고 조합한다. 물리적 부품의 자연 식별자는 제작사(가능하면 CAGE 코드 또는 그에 준하는 코드), 부품번호, 일련번호의 조합이다. P/N도 S/N도 단독으로는 고유하지 않다.
• 대조는 정규화해서, 저장은 표식 그대로. 후보를 찾을 때는 공백을 지우고 대소문자를 통일하되, 식별자는 명판과 출고 증명서에 적힌 그대로 보관한다. 이 둘은 한 글자도 다르지 않아야 한다.
• 대체와 재식별은 이벤트로 기록한다. 개조 후의 새 부품번호는 새 품목이 아니라 같은 실물의 새 상태이다. 이 연결을 잃으면 출생 이력이 끊긴다.
• 조용히 병합하지 않는다. 정규화하면 같은 키가 되지만 이력이 서로 다른 두 원천 기록은 중복이 아니라 발견 사항이다. 두 원천을 함께 첨부해 충돌 대기열에 올리고, 자격 있는 사람이 판단하게 한다.

참조 SDK에는 현실적인 제약이 하나 더 있다. ComponentSearchQuery는 유형, 상태, 제작사, 인증 필요 여부, 재료 유형으로 거를 수 있지만 부품번호나 일련번호로는 거를 수 없어서, 대조 키로 조회하는 데 쓸 수 없다. 아래 스케치는 내보낸 레코드를 로컬에서 대조하고, 병합하는 대신 충돌을 보고한다.

import type { AircraftComponent } from '@wia/aircraft-component';

const norm = (s: string): string => s.replace(/[\s-]/g, '').toUpperCase();

function naturalKey(c: AircraftComponent): string {
  const cage = String(c.metadata?.cageCode ?? c.manufacturer);
  return [norm(cage), norm(c.partNumber), norm(c.serialNumber)].join('|');
}

interface Conflict { key: string; records: AircraftComponent[]; reason: string; }

function reconcile(records: AircraftComponent[]): {
  unique: AircraftComponent[]; conflicts: Conflict[];
} {
  const byKey = new Map<string, AircraftComponent[]>();
  for (const r of records) {
    const k = naturalKey(r);
    byKey.set(k, [...(byKey.get(k) ?? []), r]);
  }
  const unique: AircraftComponent[] = [];
  const conflicts: Conflict[] = [];
  for (const [key, group] of byKey) {
    if (group.length === 1) { unique.push(group[0]); continue; }
    const asMarked = new Set(group.map(g => `${g.partNumber}/${g.serialNumber}`));
    conflicts.push({
      key,
      records: group,
      reason: asMarked.size > 1
        ? '표식상 식별자가 다름: 명판과 출고 증명서 확인'
        : '식별자는 같고 이력이 별개: 병합 전 검토',
    });
  }
  return { unique, conflicts };
}

참조 구현이 주는 것과 주지 않는 것

@wia/aircraft-component SDK는 타입과 함께 부품, 해석, 검사, 인증에 대한 엔드포인트를 정의하지만, makeRequest 메서드는 서버를 호출하지 않고 요청 본문을 모의 데이터로 되돌려 준다. PHASE 2가 이름을 든 maintenanceEvent, serviceBulletin, traceability 작업 그룹에 대한 메서드는 없다. 명세서가 참조하는 api/openapi.yaml 파일은 저장소에 존재하지 않으며, PHASE 4는 CycloneDX, in-toto, Sigstore의 이름만 들 뿐 WIA 고유의 술어나 속성을 정의하지 않는다. 따라서 연동 프로젝트는 이 영역에서 스스로 선택을 하고 그것을 문서로 남겨야 한다. 이 장의 제안은 그런 선택의 일관된 한 묶음이며, 나중에 추가형 변경으로 표준에 편입될 수 있도록 작성했다.

장 요약

• 심사원이 묻는 AS9100D 질문마다 WIA 레코드 안에 분명한 자리가 있을 때 레코드는 품질 증거가 된다. 현재 공백의 대부분은 도면 개정판, FAI 보고서, 출고 증명서, 부적합 보고서로의 연결이 없다는 것이다.
• ComponentStatus 전이는 AS9145 단계와 맞물리며, 유효성 확인 증거가 없는 전이는 기록할 것이 아니라 거부해야 한다.
• 특수공정은 부품이 아니라 기록으로 증명된다. 공정 회차는 일련번호에 연결해야 하고, Nadcap 인정 만료일은 계산하지 말고 저장해야 한다.
• 정비 주기는 MSG-3 분석에서 MRBR, MPD, 운영자 프로그램을 거쳐 나오며, 흔히 여러 단위로 표현되고, 점검 이름에서 유도할 수 없다.
• NDI 방법은 검사가 무엇을 증명하는지를 정하고, 탐지 가능 균열 크기를 통해 검사 주기까지 정한다. 참조 열거형에는 침투 탐상이 빠져 있다.
• 손상 허용 주기는 가정 크기, 탐지 가능 크기, 임계 크기 사이의 균열 성장에서 나온다. 단일 "피로 수명" 숫자나 SDK의 estimateFatigueLife가 그 해석을 대신할 수 없다.
• CycloneDX는 내장 소프트웨어를 포함한 부품을 기술할 수 있고, Sigstore로 서명한 in-toto Statement는 모든 주장에 책임 주체를 묶고 변조를 드러낸다. 7년은 보존의 하한일 뿐 부품 레코드의 수명이 아니다.
• 연동의 성패는 식별자 대조에 달려 있다. 제작사·P/N·S/N으로 키를 조합하고, 식별자는 표식 그대로 저장하며, 충돌하는 이력을 조용히 병합하지 않는다.