마이크로칩 10월
This page was machine-translated and may differ from the original. View original

[Interview] Bae Chang-yong, Novicom Pro, "'Nigel AI' Industry-Specialized AI for Test Engineers"

Preferred source on GooglePublished2026.10.29 11:30


“‘Nigel AI’ 테스트 엔지니어 위한 산업 특화 AI”


테스트·계측 전문 지식으로 실제 프로젝트 환경 이해 개발 워크플로 지원

LabVIEW·TestStand 등 개발 환경 직접 통합 하드웨어 설정·코드 생성


[편집자주]Nigel AI는 최신 LLM에 NI의 테스트·계측 전문성을 결합한 산업 특화 AI로, 코드 생성보다 신뢰할 수 있는 테스트 결과를 빠르게 확보하는 것에 초점을 맞춘다. LabVIEW·TestStand 등 개발 환경에 직접 통합돼 하드웨어 설정, 코드 생성, 분석·디버깅을 지원하며, 엔지니어가 검증과 승인 권한을 유지하도록 설계됐다. NI는 향후 Nigel을 테스트 계획부터 분석·리포트까지 수행하는 AI 에이전트로 발전시켜 엔지니어가 더 높은 수준의 설계와 판단에 집중하도록 지원할 계획이다. 이에 본지는 12월1일 웨비나를 진행하는 누비콤 NI사업부 배창용 프로와 만나 인터뷰를 통해 AI가 바꾸는 시험·계측 기술의 미래와 실전 활용법에 대해 들어봤다.




■ 최근 ChatGPT, Claude 등 생성형 AI가 소프트웨어 개발 방식을 크게 바꾸고 있다. 테스트 및 계측 분야에서도 AI가 중요한 화두가 된 이유는


생성형 AI가 코드 작성 속도를 바꿨다면, 테스트·계측 분야에서 AI가 풀어야 할 과제는 ‘신뢰할 수 있는 결과를 얼마나 빨리 얻느냐’다.


반도체, 전력전자, 모빌리티, 로보틱스처럼 여러 도메인이 한 제품 안에서 맞물리면서 테스트 시스템도 다중 도메인 구조로 바뀌고 있고, 측정 데이터의 양도 폭발적으로 늘었다.


그런데 테스트 엔지니어링은 원래 코딩 업무가 아니다.


엔지니어는 대부분의 시간을 테스트 전략을 세우고, 시스템 아키텍처를 설계하고, 하드웨어를 연결하고, 측정 결과를 해석하는 데 쓴다.


코드는 중간 단계일 뿐이고, 병목이 되는 경우는 드물다.


게다가 이 분야에는 다른 소프트웨어 분야에 없는 제약이 있다.


결정론적 타이밍과 하드웨어 동기화가 보장되어야 하고, 안전 제약이 있으며, 실수의 대가가 때로는 돌이킬 수 없는 결과를 초래한다.


범용 AI로 텍스트 코드를 대량 생성하면 처음에는 빠르지만, 유지보수와 디버깅, 검증 과정에서 그 이점이 쉽게 상쇄된다.


그래서 테스트·계측 분야에서 AI가 화두가 된 진짜 이유는 코드 자동 생성이 아니다.


계획부터 설계, 실행, 디버깅, 분석까지 하드웨어와 연결된 워크플로 전체를 가속하면서도 결과의 신뢰성을 지키는 것이다.


피지컬 AI와 산업 AI가 확산될수록 AI가 학습하고 판단하는 근거, 즉 측정 데이터의 신뢰성은 더 중요해진다.


이제 질문은 “AI를 쓸 것인가”가 아니라 “어떤 AI를 신뢰할 수 있는가”다.


■ Nigel AI를 한 문장으로 정의한다면? 또한 Nigel AI가 ChatGPT, Claude 같은 범용 LLM과 가장 다른 점은 무엇인지


한 문장으로 정의하면, Nigel AI는 최신 LLM에 NI의 테스트·계측 전문성과 실제 개발환경의 정보를 결합한, 테스트를 위해 설계된 AI입니다. 범용 LLM과의 차이는 세 가지로 말씀드릴 수 있다.


첫째, 도메인의 깊이와 하드웨어 맥락이다.


범용 모델은 정밀 측정 방법론, 하드웨어 동기화, 리얼타임 실행 같은 영역을 깊이 학습하지 못했다.


Nigel은 NI가 50년 가까이 쌓은 테스트 전문 데이터와 제품 문서로 이 공백을 채우고, 시스템에 연결 된 DAQ와 PXI 같은 하드웨어, 열려 있는 VI와 프로젝트를 직접 파악한다.


일반론이 아니라 지금 내 시스템에 맞는 답을 준다.


둘째, 환경 ‘옆’이 아니라 환경 ‘안’에서 일한다는 점이다.


범용 챗봇이 준 텍스트 코드를 옮기고 검증하는 건 엔지니어의 몫이지만, Nigel은 LabVIEW, TestStand, FlexLogger, InstrumentStudio에 내장돼 있다.


2026년 7월 릴리스부터는 Author 모드로 동작한다.


엔지니어가 쓰는 팔레트, 예제, 프로젝트 파일 중 신뢰할 수 있는 구성 요소를 찾아 조립하고, 결과를 검증한 VI를 생성한다.


그리고 엔지니어가 각 단계를 보고 승인해야만 반영된다.


셋째, 엔터프라이즈 환경을 위한 보안과 확장성이다.


전송 데이터는 TLS와 mTLS, 저장 데이터는 AES-256으로 보호되고, 사용자의 질문과 응답은 AI 학습에 쓰이지 않는다.


MCP 서버로 사내 코드 템플릿, 회로도, 제품 사양 같은 자체 IP도 연결할 수 있다.


마지막으로, Nigel은 특정 모델에 묶여 있지 않다.


현재는 ChatGPT 5.4, Codex, o4-mini 등 OpenAI의 5개 모델 중에서 작업 성격에 맞는 모델을 골라 쓸 수 있고, 2027년 2월부터는 Claude와 ChatGPT의 최신 모델이 추가되어 함께 선택할 수 있게 된다.


즉 범용 AI 기술이 발전하면 Nigel도 그 발전을 그대로 흡수하고, 그 위에 NI의 테스트·계측 전문성을 더하는 구조다.


여러 솔루션 사이에서 타협할 필요 없이, 가장 앞선 모델과 테스트 전문성을 함께 쓸 수 있다는 뜻이다.


■ 생성형 AI 시대에도 LabVIEW가 여전히 강력한 이유는 무엇이라고 생각하는지


AI가 코드를 쓰는 시대일수록, 그 코드를 얼마나 빨리 신뢰할 수 있느냐가 경쟁력이 되기 때문다.


NI의 수석 엔지니어 크리스 로벅(Chris Roebuck)은 테스트 팀의 질문이 “코드를 작성하는 데 얼마나 걸리는가”에서 “그 코드를 신뢰하는 데 얼마나 걸리는가”로 바뀌고 있다고 말한다.


코드 작성 비용이 0에 가까워지면 병목은 신뢰가 되고, 신뢰는 얼마나 빨리 읽고, 검토하고, 검증할 수 있느냐에 달려 있다.


저는 이 관점에서 LabVIEW의 강점을 세 가지로 본다.


첫째, 검증 가능성이다.


AI가 Python이나 C#으로 대량의 텍스트 코드를 쏟아내면 검토 자체가 새로운 병목이 된다.


실제로 AI로 테스트 애플리케이션을 만들어 본 엔지니어들은 초기 속도는 인상적이지만 유지보수, 디버깅, 인수인계에서 그 이점이 줄어든다고 말한다.


LabVIEW의 그래픽 데이터플로는 병렬 구조와 데이터 흐름, 노드 간 의존성을 한눈에 보여주기 때문에, AI가 만든 코드도 엔지니어가 빠르게 검토하고 디버깅할 수 있다.


둘째, 하드웨어 계층이다.


NI는 Python API도 제공하고, 목적이 분명한 작업에는 충분히 효과적이다.


하지만 시스템 아키텍처, 리얼타임 실행, 결정론적 타이밍, 엄격한 하드웨어 동기화가 필요한 영역은 LabVIEW의 플랫폼 통합이 가장 깊고, 범용 AI가 줄 수 있는 것은 가장 적은 곳이다.


셋째, 검증된 자산이다.


LabVIEW에는 수십 년간 현장에서 검증된 측정·신호처리 IP와, 큐 기반 메시지 처리기나 상태 머신 같은 디자인 패턴이 있다.


Nigel은 이 자산을 새로 만들지 않고 가져다 조립한다.


기존에 검증된 코드와 설계 패턴을 활용하면 개발 속도를 높이면서 유지보수 부담도 줄일 수 있다.


■ 웨비나에서 하드웨어 설정 자동화를 데모로 보여주실 예정인데, 실제 프로젝트에서는 얼마나 많은 시간을 절감할 수 있는지


정확한 절감 폭은 시스템 규모와 엔지니어의 숙련도에 따라 다르지만, 시간이 줄어드는 지점은 분명하다.

AD
나는 엔지니어다


코드를 쓰기 전의 ‘준비’와 코드를 쓴 후의 ‘검토’다.


새 cDAQ나 PXI 모듈, 박스형 계측기로 측정 시스템을 구축할 때 시간은 대부분 코드 주변에서 쓰인다.


어떤 드라이버가 필요한지, 팔레트 어디에 함수가 있는지, DAQmx 태스크를 어떻게 나눌지 찾고, 초기화부터 종료, 에러 처리까지 반복적인 배선을 하는 일이다.


이번 데모는 세 가지 실제 하드웨어 구성으로 진행한다.


첫째는 cDAQ 기반 모터 모니터링이다.


10 S/s 온도와 채널당 25.6 kS/s 진동처럼 샘플링 속도가 다른 신호를 별도 태스크로 나누고, RMS·피크 분석과 TDMS 저장까지 포함한 VI를 생성한다.


둘째는 Agilent 전원공급기와 DMM을 VISA로 함께 제어하고 CSV로 기록하는 박스형 계측기 데모다.


셋째는 PXIe-5110 오실로스코프와 PXIe-5413 신호발생기를 niScope, niFgen 드라이버와 병렬 루프로 제어하는 PXI 데모다.


Nigel은 NI MAX를 열지 않고도 연결된 장비를 확인하고, 요구사항을 바탕으로 아키텍처를 제안한 뒤, 프롬프트에서 실제 VI까지 생성한다.


드라이버와 매뉴얼을 뒤지며 손으로 쌓던 초기 구축 작업이 요구사항 정리와 검토 중심의 작업으로 바뀌는 것이다.


그만큼 엔지니어는 시스템 설계와 데이터 해석이라는 본연의 일에 더 많은 시간을 쓸 수 있다.


다만 데모에서 꼭 함께 보여드리려는 점이 있다.


프롬프트에 하드웨어 조건과 요구사항을 구체적으로 적을수록 결과가 정확해지고, 생성된 코드가 하드웨어 조건에 맞는지는 엔지니어가 검증해야 한다는 점이다.


Nigel은 판단을 대신하는 도구가 아니라 이해, 설계, 생성에 드는 시간을 줄여주는 도구다.


■ Nigel AI를 처음 검토하는 기업이라면 어디서부터 시작하는 것이 좋을지. 또한 Nigel AI를 가장 빨리 활용할 수 있는 업무 영역은 무엇인지


기존 아키텍처와 IP를 버리고 새로 시작할 필요는 없다.


기존에 사용하던 코드와 개발환경을 유지하면서, 반복적인 작업부터 AI를 적용해 보는 것이 좋다.


먼저 평가 기준을 바로 세우시길 권한다. “AI가 특정 도구를 대체할 수 있는가”보다 중요한 질문은, 도입하려는 AI가 이미 구축한 아키텍처, 지식재산, 엔지니어링 판단과 함께 작동하는가, 아니면 처음부터 다시 시작하라고 요구 하는가이다.


현재 사용 중인 개발환경과 업무 특성을 고려해 도입 가능성을 검토하는 것이 좋다.


실무적으로는 환경 점검이 첫 단계다.


Nigel은 LabVIEW Professional, TestStand Development System 이상, 또는 LabVIEW+ Suite의 유효한 소프트웨어 서비스 계약에 포함되어 있고, 라이선스가 NI 계정에 연결되어 있어야 한다.


VI 생성 기능은 LabVIEW 2026 Q3 이상에서 쓸 수 있다.


VI 생성은 LabVIEW Professional에서 주 25회, LabVIEW+ Suite에서 주 50회 제공되므로, 팀의 개발 물량에 맞는 에디션을 고르면 된다.


보안팀과 데이터 처리 구조도 미리 검토해 두시면 도입이 수월하다.


가장 빨리 효과를 보는 영역은 리스크는 낮고 반복은 많은 업무다.


첫째, 레거시 코드 분석이다.


문서화가 부족한 VI나 TestStand 시퀀스의 목적, 구조, 변수 설정을 Nigel이 몇 초 만에 설명해 준다.


둘째, 측정 코드 생성이다.


DAQmx 수집 코드나 타사 PnP 계측기 드라이버 기반의 표준 측정 VI, 스펙 문서 기반 TestStand 시퀀스 초안을 프롬프트로 만들 수 있다.


셋째, 하드웨어 셋업과 온보딩이다.


FlexLogger와 InstrumentStudio에서 센서 사양, 채널과 로깅 설정을 안내받아 첫 측정까지 빠르게 도달하고, 신규 인력의 학습 시간도 줄일 수 있다.


이렇게 성과를 확인한 뒤 MCP 서버로 사내 코드 템플릿과 제품 사양을 연결해, Nigel이 우리 회사의 맥락 안에서 일하도록 확장하면 된다.


■ 마지막으로 AI 시대를 준비하는 엔지니어들에게 전하고 싶은 메시지가 있다면


AI를 수용한다는 것은 판단을 AI에 넘기는 것이 아니라, 엔지니어가 더 높은 수준의 판단에 집중하게 되는 것이다.


Emerson 테스트 및 측정 사업부의 CTO 케빈 슐츠(Kevin Schultz)는 “오늘 AI를 수용하는 사람이 미래의 테스트 리더가 될 것”이라고 말했다.


저는 여기에 한 가지를 덧붙이고 싶다.


미래의 리더는 AI를 자신의 도메인 지식과 결합하는 사람이라는 점이다.


코드 작성 비용은 빠르게 0에 가까워지고 있다.


그만큼 엔지니어의 가치는 무엇을 측정할지 정하고, 시스템을 설계하고, 결과를 신뢰할 수 있는지 판단하는 데로 옮겨간다.


엔지니어의 역할은 코드를 짜는 사람에서 아키텍트이자 리뷰어로 올라간다.


이때 가장 강력한 무기는 여전히 도메인 전문성이다.


AI가 만든 결과가 물리적으로 맞는지 알아보는 눈은 현장 경험에서 나오기 때문이다.


Nigel도 같은 원칙으로 설계됐다.


2025년 어드바이저, 2026년 작성자를 거쳐, 2027년 이후에는 테스트 계획부터 분석과 리포트까지 워크플로를 오케스트레이션하는 에이전트로 진화한다.


그 과정에서도 원칙은 변하지 않는다.


엔지니어는 모든 단계를 볼 수 있고, 엔지니어의 승인 없이는 아무것도 반영되지 않는다.


테스트에서 최종 산출물은 결국 신뢰다.


지금 작은 업무부터 AI와 함께 일하는 방식을 익히시고, 그 신뢰를 만드는 엔지니어가 되길 바란다.


누비콤은 NI 총판 대리점이자 AI 파트너로서 그 여정을 처음부터 끝까지 함께할 것이다.


하드웨어 기반의 데이터 수집과 측정 시스템 구축부터 테스트 자동화, 데이터 관리와 분석, 그리고 Nigel 기반의 AI 워크플로 오케스트레이션까지, 전 과정을 컨설팅하고 솔루션으로 제공해 드릴 수 있다.


여러분의 AI 기반 테스트 혁신에 가장 가까운 파트너가 되겠다.

To request a correction, reply or follow-up report on this article, see how to file a request. Previously published statements are collected in corrections & replies.
배종인 기자
배종인 Reporter

Comments