사용자 지정 데이터 소스

Validation logic is only as reliable as the data it validates against. Custom data sources connect your authoritative external systems into Altium platform processes – so that checks run against current, live data, not a snapshot that goes stale.

Behavior Extensibility 내에서 커스텀 데이터 소스는 별도의 인프라 구성요소가 아닙니다. 이는 Python 체크와 스크립트가 외부 데이터에 접근하는 방식에 대한 하나의 패턴입니다. Python으로 작성된 체크는 접근 가능한 어떤 API든 호출할 수 있고, 연결 가능한 어떤 데이터베이스든 조회할 수 있으며, 그 결과를 검증 로직의 일부로 사용할 수 있습니다. 외부 시스템은 권위 있는 원본 소스로 남아 있습니다. Altium은 이를 조회할 뿐, 사본을 유지하지는 않습니다.

이것이 로드맵에서 말하는 Customizability를 구체화하는 방식입니다. “체크는 사내 부품 데이터베이스, 승인된 벤더 목록, ERP 시스템에 접근해 결과를 반환할 수 있다.” 커스텀 데이터 소스는 이를 가능하게 하는 호출입니다.

라이브 데이터 액세스가 중요한 이유

체크 로직에 내장된 정적 목록을 기준으로 부품 승인을 검증하는 체크는 작성 시점에는 정확하지만, 몇 주만 지나도 틀릴 수 있습니다. 승인 부품 목록은 바뀝니다. 제한 물질 목록도 바뀝니다. 라이프사이클 상태도 바뀝니다. 라이브 시스템을 호출하는 체크는 실행될 때마다 항상 최신 답을 가져옵니다.

이것이 규칙을 인코딩하는 것과 지식을 인코딩하는 것의 차이입니다. 정적 목록은 특정 시점의 지식 상태를 인코딩합니다. 라이브 데이터 소스 호출은 권위 있는 시스템의 현재 상태가 컴플라이언스를 결정한다는 규칙을 인코딩합니다. 두 번째 접근 방식이 시간이 지나도 더 잘 유지됩니다.

일반적인 외부 데이터 소스

• Approved Vendor / Manufacturer Lists (AVL/AML) – 조달팀 또는 부품 엔지니어링 팀이 승인된 제조사 및 벤더의 권위 있는 목록을 유지 관리합니다. 이 목록을 실시간으로 조회하는 체크를 사용하면 Altium에서 승인된 것으로 표시된 부품이 체크 실행 시점에 실제로 권위 있는 시스템에서도 승인되어 있었는지 확인할 수 있습니다 – 누군가가 마지막으로 로컬 파일을 업데이트했던 시점 기준이 아닙니다.

• Component qualification databases – 부품 자격 검증 프로세스가 성숙한 조직은 자격 상태, 시험 데이터, 적용 제한사항, 승인된 사용 사례에 대한 내부 데이터베이스를 유지합니다. 이 데이터를 Altium 체크에 연결하면 자격 상태를 릴리스 검토 단계에서 뒤늦게 발견하는 것이 아니라 설계 단계에서 확인하고 강제할 수 있습니다.

• ERP and inventory systems – 리드타임, 재고 수준 또는 조달 상태를 라이브 ERP 데이터와 대조해 검증하는 체크를 사용하면 엔지니어가 설계 완료 후 공급 문제를 발견하는 대신 설계 중에 소싱을 고려한 의사결정을 할 수 있습니다.

• Compliance and restricted materials databases – ITAR, EAR, RoHS, REACH 및 내부 IP 통제 목록은 컴플라이언스 팀에서 관리하며 시간이 지나면서 변경됩니다. 라이브 컴플라이언스 데이터를 조회하는 체크는 정책이 바뀔 때마다 체크 자체를 업데이트하지 않고도 현재 정책 상태를 강제할 수 있습니다.

• Internal parametric and specifications data – 조직에서 유지 관리하는 엔지니어링 표준, 선호 부품 사양, 내부 데이터시트, 시험 결과를 Altium 체크와 패널에 표시할 수 있으므로, 엔지니어는 의사결정 시점에 내부 지식에 접근할 수 있습니다.

구현 시 고려사항

• Accessibility – 서버 측 플랫폼에서 실행되는 체크는 서버의 네트워크 컨텍스트에서 외부 시스템에 접근할 수 있어야 합니다. Altium Designer에서 클라이언트 측으로 실행되는 체크는 엔지니어의 머신에서 접근할 수 있어야 합니다. 외부 호출에 의존하는 체크를 만들기 전에 네트워크 접근성을 확인하세요.

• Latency – 데스크톱 측 체크는 엔지니어가 작업하는 동안 실행됩니다. 외부 API가 느려 응답에 몇 초씩 걸리는 체크는 엔지니어가 우회하려는 마찰을 만듭니다. 데이터가 자주 바뀌지 않는다면 외부 호출은 빠르고, 목적이 분명하며, 캐시 가능하도록 유지하세요.

• Failure handling – 외부 시스템을 사용할 수 없을 때도 안전하게 실패하도록 체크를 설계하세요. AVL에 접근할 수 없는 체크는 fail closed 방식으로 동작해야 합니다 – 부품이 승인되었다고 보고하는 것이 아니라, 검사를 완료할 수 없었다고 보고해야 합니다. 데이터 소스에 도달할 수 없었는데도 체크를 조용히 통과시키는 것은 컴플라이언스에 영향을 주는 신뢰성 실패입니다.

• Authentication – 체크 로직에서 외부 API를 호출하려면 자격 증명이 필요합니다. 자격 증명은 체크 스크립트에 하드코딩하지 말고 Workspace 시크릿이나 환경 설정으로 저장하세요. 체크 코드도 자격 증명을 다루는 프로덕션 코드와 동일하게 취급해야 합니다.

커스텀 데이터 소스가 아닌 것

이 맥락에서 커스텀 데이터 소스는 체크 및 스크립트 로직에서 수행하는 호출을 의미합니다 – 별도의 데이터 통합 계층이나 동기화 메커니즘이 아닙니다. 또한 외부 공급자의 공급망 및 파라메트릭 데이터를 위한 Altium의 내장 부품 데이터 소스(Octopart, SiliconExpert, Z2 Data)를 대체하지도 않습니다. 이는 사용자의 자체 커스텀 검증 로직에서 사내 시스템에 접근하기 위한 패턴입니다.

Altium 365와 외부 시스템 간에 플랫폼 수준의 양방향 데이터 교환이 필요한 사용 사례라면 – 단순히 체크 로직에서 읽어오는 수준이 아니라 – Altium 365 API와 PLM Integration SDK가 적절한 도구입니다.