Nexar API 설명: 무엇인지, 어떻게 작동하는지, 그리고 이를 사용하는 사람들에게 무엇이 달라지는지

먼저 API가 무엇인지부터 살펴보겠습니다

API는 application programming interface의 약자입니다. 사람은 클릭하고 읽으면서 웹사이트를 이용합니다. 하지만 프로그램은 클릭할 수 없기 때문에, 정확한 질문을 던지고 자신이 이해할 수 있는 형식으로 정확한 답을 받을 수 있는 서비스 창구가 필요합니다. 그 창구가 바로 API입니다. Octopart는 사용자가 전자 부품을 검색하고 다양한 각도에서 정보를 확인할 수 있는 웹사이트입니다. 여기에는 어떤 업체가 해당 부품을 재고로 보유하고 있는지, 가격은 얼마인지, 라이프사이클 상태는 어떤지, 기술 속성은 무엇인지 등 다양한 정보가 포함됩니다. 특정 부품과 유사한 다른 부품을 찾기 위한 검색도 가능합니다. Nexar API는 이와 동일한 정보를 회사의 비즈니스 소프트웨어 시스템 안으로 직접 전달합니다.

Nexar API 사용의 이점

• 자체 도구에 통합: Nexar API의 최신 데이터를 맞춤형 Purchase Order Management 시스템이나 Product Lifecycle Management 시스템 같은 내부 시스템에 직접 내장할 수 있습니다.
• 공급 데이터 그 이상: Nexar API는 공급 정보와 함께 Altium 365 워크스페이스의 설계 데이터도 가져올 수 있으므로, 단일 통합만으로 소싱 데이터와 설계 데이터를 함께 불러올 수 있습니다.
• 팀 간 일관성 확보: 같은 쿼리를 사용하는 모든 사람은 같은 시점의 동일한 가격, 동일한 재고 수준, 동일한 단위를 동일한 값으로 받습니다. 따라서 수치는 사람 간, 보고서 간, 그리고 시간 경과에 따라서도 비교 가능하게 유지됩니다.
• 대규모 자동화: Nexar API를 사용하면 한 번에 최대 100개의 부품을 프로그래밍 방식으로 조회하고, 분당 최대 300개의 쿼리를 실행할 수 있습니다. 즉, 1분 안에 최대 30,000개의 부품을 분석할 수도 있습니다!

Nexar API

Nexar API는 주로 다음으로 구성됩니다: 

• 공급 데이터는 Octopart의 부품 정보입니다. API의 공급 측면에서는 9,500만 개가 넘는 부품에 접근할 수 있으며, 재고, 가격, 라이프사이클 상태, 리드타임, 데이터시트, 기술 속성, CAD 모델, 유사 부품 추천 등의 정보를 전자 부품 유통업체로부터 수집해 매일 업데이트합니다. 

• 설계 데이터는 Altium 고객을 위한 것으로, 프로젝트와 부품 세부 정보를 포함한 설계 워크스페이스의 내용을 다룹니다. 여기서 Nexar Data Model은 공개적으로 유용한 리소스입니다: Nexar Voyager. 데이터 모델에서는 각 작업에 어떤 대상을 다루는지 알려주는 접두사가 붙습니다: sup는 공급, des는 설계, adm은 계정 관리를 의미합니다.

예제 1: 원하는 응답 형태를 직접 기술하기

Nexar는 API용 쿼리 언어인 GraphQL을 사용합니다. 다른 API 인프라에서는 보통 고정된 데이터 블록을 요청하고, 전체를 받은 뒤 필요 없는 부분을 코드로 버려야 합니다. 하지만 GraphQL에서는 원하는 응답의 형태를 직접 작성하면, 그 형태 그대로 결과가 반환됩니다. 다음은 MPN(제조사 부품 번호)으로 검색하는 문서화된 형식입니다:

query MpnSearch { 

  supSearchMpn { 

    results { part { id  name  mpn } } 

  } 

} 

소리 내어 읽어보면 이렇습니다. 제조사 부품 번호를 기준으로 검색을 실행하고, 검색 결과 각각에 대해 부품 식별자, 이름, MPN을 알려줘. 그 외의 정보는 반환되지 않습니다. 더 많이 요청하면 더 많이 받을 수 있습니다. 실제 Altium 데모에서는 Renesas RA 패밀리의 RA0E2 마이크로컨트롤러를 검색해 해당 부품을 찾았고, 여기에 기술 사양을 추가로 요청하자 RoHS(유해물질 제한) 준수 플래그가 확인되었습니다. 또 데이터시트를 추가로 요청하자 파일 링크, 파일명, 생성일이 반환되었는데, 이는 Octopart가 사용 가능한 데이터시트를 점수화해 가장 적합한 것을 반환할 수 있기 때문입니다. 요청하기 전에는 그 어떤 정보도 전달되지 않습니다.

예제 2: 다양한 검색 방식

Octopart와 마찬가지로, Nexar API는 부품 검색 방식을 유연하게 제공합니다. 폭넓은 검색을 원한다면 부분 MPN으로 검색하거나 키워드 기반 검색을 할 수 있습니다. 원하는 항목을 정확히 알고 있다면 정확한 MPN으로 검색하면 됩니다.

보다 폭넓은 검색을 위해 API에서 사용할 작업은 ‘supSearch’입니다. 이 작업은 퍼지 매칭 검색을 수행합니다.

query search { 

  supSearch (q: "Current sensor") { 

    hits 

    results { 

      part { 

        id 

        name 

        shortDescription 

      } 

    } 

  } 

} 

위 예시에서 “current sensor”를 검색하면 검색 건수, 부품 ID, 이름, 그리고 해당 부품의 짧은 설명이 반환됩니다. 

'supMultiMatch 작업은 최대 100개의 부품 목록을 받아 MPN 또는 SKU(stock keeping unit) 기준으로 한 번에 매칭합니다. ‘supSearch’와 달리 ‘SupMultiMatch’를 사용할 경우 부분 일치는 모두 무시됩니다. 아래 예시는 두 개의 부품을 조회합니다:

query MultiSearch { 

  supMultiMatch (queries: [ 

      {mpn: "SY55855VKG", limit: 1}, 

      {mpn: "BAV99-7-F"}, 

  ]) { hits  parts { id  name  mpn } } 

} 

각 항목은 BOM(bill of materials)의 한 줄이 될 수 있으므로, 브라우저를 열지 않고도 전체 BOM에 대한 가격 산정이 가능합니다.

예제 3: 설계 측면과 데이터 쓰기

설계 데이터도 동일한 방식으로 동작합니다. ‘desWorkspaces’처럼 des 접두사가 붙은 작업은 Altium 365 워크스페이스 내부 데이터에 접근합니다. 데이터가 그래프 구조로 되어 있기 때문에, 시작 지점에서 바깥쪽 관계를 따라가며 조회할 수 있습니다. 예를 들어 워크스페이스에서 그 안의 설계들로, 다시 설계에서 그 안에 포함된 내용으로 이동할 수 있으며, 여기에는 넷과 부품 세부 정보부터 MCAD(기계 CAD) 및 위치 정보까지 포함됩니다. 어디까지 탐색할지, 그리고 각 단계에서 얼마나 많은 정보를 가져올지는 사용자가 선택합니다.

읽기만 있는 것은 아닙니다. mutation은 쓰기 작업입니다. 예를 들어 댓글 추가나 프로젝트 업로드 같은 작업이 여기에 해당합니다. 어떤 작업에 파일이 필요하다면 먼저 files.nexar.com/File/Upload의 Nexar 파일 서비스에 업로드해야 하며, 이때 design.domain, user.access, openid 스코프를 포함한 토큰을 전달해야 합니다. 그러면 아직 사용되지 않은 경우 24시간 동안 유효한 식별자가 반환되고, 이를 실제 요청에서 참조하게 됩니다. 이 식별자의 형식은 변경될 수 있으므로 내부 구조를 가정하지 말고 불투명한 값으로 취급해야 합니다.

이것이 업무에 가져오는 변화

이 API의 가치는 이미 각자의 업무에 시간을 쓰고 있는 세 가지 역할과, 그 시간 중 API가 어디를 되돌려주는지를 보면 가장 쉽게 이해할 수 있습니다.

조달 관리자 또는 바이어

EMS(전자 제조 서비스 제공업체)나 OEM(완성품 제조업체)에서 이 역할은 생산에 필요한 모든 부품이 재고에 있는지 확인하고, 납기일을 맞출 수 있는 유통업체를 찾고, 가격을 파악한 뒤 주문을 진행합니다. 이는 일주일에 몇 건 수준일 수도 있고, 하루에 50~100건일 수도 있습니다. 보통 이 업무는 스프레드시트에서 부품별로 하나씩 처리됩니다. MPN 하나를 입력하고, 재고를 확인하고, 유통업체 페이지로 클릭해 들어간 뒤, 다시 같은 과정을 반복하는 식입니다. 먼저 공인 유통업체를 확인하고, 재고가 전혀 없을 때에만 비공인 브로커까지 검색 범위를 넓히는 경우가 많습니다. 또한 많은 바이어는 밤사이 상황이 바뀌었을 수 있기 때문에 주문 직전에 한 번 더 재확인합니다.

이 모든 단계에는 앞서 설명한 API 대응 기능이 있습니다. API 쿼리 한 번이면 수백 번의 개별 조회를 대체할 수 있습니다. API의 authorized-only 필터를 사용하면 “우선 선호 공급처부터 확인하고, 없으면 범위를 넓힌다”는 습관을 수동 재검색이 아닌 설정으로 구현할 수 있습니다. 주문 직전 재확인은 정해진 일정에 따라 실행되고 변경 사항이 있을 때만 알려주는 작업으로 바뀝니다. 여기서 되돌려받는 것은 판단 자체가 아니라, 현재 판단을 소모시키고 있는 입력 작업과 탭 전환 시간입니다. 사전 협상된 계약 가격은 여전히 유통업체 측에 있으므로, API는 구매 주문 자체를 대체하는 것이 아니라 후보를 좁히고 변경을 포착하는 데 사용됩니다.

설계 엔지니어

OEM에서 이 역할은 블록 다이어그램부터 부품 선정, 회로도 캡처, 레이아웃, BOM 릴리스에 이르기까지 전기 설계 라이프사이클 전반을 책임집니다. 이들에게 가장 직접적인 제약은 명확합니다. 조달할 수 없는 부품은 곧 설계 문제라는 점입니다. 그래서 Octopart는 “이 부품을 실제로 구매할 수 있는가, 그리고 한 곳 이상에서 구할 수 있는가?”를 확인하는 검증 단계로 사용되며, 동시에 후보 부품을 찾고 비교하는 탐색 도구로도 활용됩니다. 유통업체 범위 자체가 하나의 신호가 되는데, 단 하나의 유통업체만 재고를 보유한 부품이나 여러 유통업체가 있더라도 전체 재고가 매주 감소하는 부품은 실제 조달 문제가 발생하기 전부터 이미 공급망 리스크를 의미합니다.

이 과정을 API로 실행하면, 이러한 확인이 더 이상 부품별 반사적 습관이 아니라 하나의 게이트가 됩니다. BOM의 모든 항목을 릴리스 시점에 검사할 수 있고, 단일 유통업체 의존, 낮은 재고, 라이프사이클 플래그 같은 위험 요소를 설계 승인 후 몇 달이 지나서가 아니라 서명 전에 드러낼 수 있습니다. 이것이 해결하려는 두려움은 구체적이고 비용이 큽니다. 즉, 설계에 반영된 뒤 부품이 EOL(end of life)이 되어 재설계를 강요하는 상황입니다. 데이터시트도 동시에 자체 도구로 가져올 수 있지만, 엔지니어는 당연히 그래야 하듯 최종 사양을 데이터시트 원문으로 다시 확인해야 합니다.

부품 엔지니어

주로 중대형 OEM, 특히 항공우주, 방위, 자동차, 의료 분야에서 볼 수 있는 역할로, 일반적으로 새로운 설계를 직접 만들지는 않습니다. 대신 이미 양산 중인 부품을 관리합니다. 승인된 부품 라이브러리를 최신 상태로 유지하고, 단종 위험을 위기로 번지기 전에 포착하며, 부품이 단종되었을 때 대체품을 검증하는 업무를 맡습니다. 위험 가능성이 있는 부품은 감시 목록에 올려 주기적으로 점검하는데, 이는 단종된 부품이 때때로 다시 시장에 나오기도 하기 때문입니다.

이 글에서 가장 분명한 성과는 자체 점검형 워치리스트입니다. 누군가가 목록을 다시 확인해야 한다는 사실을 기억하고 직접 재방문할 필요 없이, 예약된 쿼리가 목록을 순회하며 예외 사항을 보고합니다. 하나의 애플리케이션 안에서 공급 범위와 설계 범위를 함께 유지할 수 있기 때문에, 동일한 실행 과정에서 설계 측의 라이브러리를 읽고 공급 측의 실시간 시장 데이터와 비교할 수 있습니다. 그 결과 주기적으로 수작업으로 하던 감사를 상시 보고서로 전환할 수 있습니다. Octopart는 여전히 프로세스를 완결하기보다는 후보를 넓히는 역할을 합니다. 대체 후보 부품과 시장 가용성 정보는 여기에서 제공되지만, 형상, 장착성, 기능, 규정 준수, 수명주기 검증은 계속해서 PLM(제품 수명주기 관리) 도구와 전문 데이터 제공업체에서 수행됩니다.

세 가지의 공통점

이 세 가지 페르소나 모두 새로운 웹사이트를 방문하고 싶어 하는 것이 아닙니다. 이들이 원하는 것은 이미 자신이 작업 중인 시스템 안에서, 필요한 바로 그 순간에, 누군가가 직접 찾으러 가지 않아도 답이 도착하는 것입니다. 이것이 바로 API의 역할이며, Nexar가 스스로의 목적을 설명하는 방식과도 매우 가깝습니다. 즉, 정보를 민주화하고 사람들을 연결해 더 효율적으로 일하고 더 현명한 비즈니스 의사결정을 내릴 수 있도록 하는 것입니다.

설정 시작하기

1. 이메일 주소와 비밀번호 또는 Google, Facebook, Altium 365 자격 증명을 사용해 portal.nexar.com 에 등록하세요. 이미 Altium 365에서 SSO(싱글 사인온)를 사용 중인 조직은 그 방식으로 로그인할 수 있습니다.
2. 조직을 생성하거나 기존 조직에 참여하세요. 이 단계는 필수입니다. 기존 조직에 참여하려면 해당 조직의 구성원에게 초대를 요청하세요.
3. 등록이 완료되면 바로 사용할 수 있도록 사전 구성된 ‘Evaluation’ 애플리케이션이 제공됩니다. 원한다면 Apps로 이동해 추가 애플리케이션을 생성할 수도 있습니다.
4. API 대시보드에는 즉시 탐색해볼 수 있는 샌드박스 환경이 포함되어 있습니다. 데이터를 자신의 도구나 애플리케이션에 통합할 준비가 되면 Authorization 탭으로 이동해 인증 자격 증명을 가져올 수 있습니다.
5. 앱의 Authorization 탭에서 client ID와 client secret을 가져오세요. 이는 고정 자격 증명입니다. secret은 비밀번호처럼 취급해야 합니다.
6. 이를 액세스 토큰으로 교환하세요. Nexar는 OAuth 2.0(Open Authorization, version 2.0)을 사용하며, 토큰의 유효 기간은 24시간입니다. 공급 쿼리는 client credentials grant를 사용하고, design 및 adm 쿼리는 OpenID, design.domain, user.access 스코프를 사용하는 authorization code grant를 사용합니다.

위의 모든 예시는 애플리케이션 코드를 한 줄도 작성하기 전에 Nitro(구 Banana Cake Pop)나 Postman 같은 GraphQL 편집기에서 실행해볼 수 있습니다. 엔드포인트는 API용 api.nexar.com/graphql, 토큰용 identity.nexar.com/connect/token, 업로드용 files.nexar.com/File/Upload입니다. 

다음 단계

API가 실제로 동작하는 모습을 확인해보세요. Altium의 Platform API 책임자인 Rob Barton이 OnTrack 팟캐스트에서 Altium API의 발전 과정을 설명하고 Octopart 공급 데이터에 대해 실시간 쿼리를 실행합니다: Altium API Deep Dive: Opening PCB Data to Developers YouTube에서 확인할 수 있습니다.

에피소드를 들어보세요. OnTrack: The PCB Design Podcast, 진행은 Zach Peterson이 맡았습니다.

데이터 모델을 살펴보세요. Nexar Voyager는 GraphQL 스키마를 시각적으로 표현해 제공합니다.

문서를 읽어보세요. 전체 문서와 용어집은 support.nexar.com에서 제공됩니다. 실제 코드 예제는 NexarDeveloper GitHub에 게시되어 있습니다.