산업용 AIoT 직무를 채용하는 것은 특히 어렵습니다. 이 분야에는 재능 있는 소프트웨어 및 ML (Machine Learning) 엔지니어가 많지만, 그들 중 누구도 이전에 물리적 세계의 데이터 도메인에서 일해본 적이 없을 수 있기 때문입니다. 누군가가 산업용 AIoT 분야에서 일했는지 여부는 이력서만 보고는 항상 명확하지 않습니다. 아래는 이러한 격차를 명확하게 드러내는 경향이 있는 제가 가장 좋아하는 질문 몇 가지와 그 이유입니다.

"센서가 갑자기 초당 두 번의 데이터를 보내기 시작할 때, 시스템을 어떻게 설계하시겠습니까?"

이것은 아주 작은 예외 사례(edge-case)처럼 보이지만, 놀라울 정도로 흔한 사례입니다. 펌웨어 업데이트, 네트워크의 재시도(retries), 또는 잘못 설정된 간격(interval) 등이 모두 장치에서 이러한 동작을 유발할 수 있습니다. 깨끗한 API 경험을 가진 일반적인 소프트웨어 개발자들은 어떻게 할 것인지 설명하지 않고 단순히 "중복 제거 (dedupe)"를 하겠다고 답변하려 할 것입니다. 후보자가 타임스탬프(timestamp), 페이로드 해시(payload hash), 또는 장치가 출력하는 시퀀스 ID(sequence ID)를 기반으로 중복을 제거할 것인가요? 각 중복 제거 전략은 서로 다른 예외 사례에 취약하며, 운영 환경(production)에서 이를 디버깅해 본 적이 있는 사람이라면 각 전략에 대해 잘 정립된 의견을 가지고 있을 것입니다.

"테스트에서 95%의 정확도를 보이는 모델이 있습니다. 이를 믿기 전에 어떤 질문을 하시겠습니까?"

제가 주의 깊게 듣는 핵심은 후보자가 운영 조건과 관련하여 훈련(training) 및 테스트(testing) 데이터를 생각하는지 여부입니다. 즉, 이 훈련 및 테스트 데이터가 모델이 운영 환경에서 경험하게 될 실제 조건을 대표하는가 하는 점입니다. (여기에는 유사한 환경적 맥락, 센서 교정(sensor calibrations), 그리고 결정적으로 시간적 기간이 포함됩니다. 계절적 패턴이 센서 측정값에 상당한 영향을 미칠 수 있기 때문입니다.) 일반적으로 소프트웨어 개발자들은 높은 수치가 완료된 작업을 나타낸다고 생각하는 반면, 이 특정 도메인에서 경험이 있고 데이터 드리프트 (data drift)로 인해 운영 환경에서 고생해 본 사람은 데이터 품질과 이력에 대해 먼저 질문할 것입니다.

"현재 5개의 서로 다른 센서 벤더를 지원하고, 다음 분기에 6번째 벤더를 지원하기 위한 스키마 (schema)를 어떻게 설계하시겠습니까?"

저는 실제로 후보자가 스키마 정의(schema definition)와 업데이트를 일회성 작업이 아니라, 정규화(normalization)와 데이터 의미론(data semantics)의 지속적인 관리가 필요한 작업으로 생각하는지 확인하고 있습니다. 숙련되지 않은 소프트웨어 엔지니어라면 장치별로 특정 파서(parser)를 작성하거나 시스템에 모든 특정 센서 장치를 하드코딩(hardcode)하겠지만, 산업 현장 경험이 있는 엔지니어라면 시스템의 나머지 무결성에 영향을 주지 않으면서 각 벤더의 모든 특이점과 구체적인 사항들을 분리하고 격리할 수 있는 적응/변환 계층(adaptation/translation layer)을 설계할 것입니다.

"특정 시설이 6시간 동안 인터넷 연결을 잃게 되면 귀하의 시스템에서 어떤 일이 발생하는지 설명해 주시겠습니까?"

이 질문은 일반적으로 항상 연결되어 있는(always-on) 환경에 익숙한 후보자와, 완전히 다른 일련의 가정을 포함하는 간헐적/손실이 발생하는(intermittent/lossy) 네트워크 조건에 맞춰 설계해 본 경험이 있는 후보자를 걸러내는 데 도움이 됩니다. 저는 로컬 데이터 버퍼링(data buffering), 저장 후 전달(store-and-forward) 메커니즘, 그리고 제한된 시간 내에 트리거되어야 하는 시간 민감형 이벤트(예: 안전 문제)를 어떻게 처리하는지에 대해 이야기하는 후보자를 찾고 있습니다. 순수 소프트웨어 또는 클라우드 개발자가 시도할 법한 흔하고 취약한 답변은, 누락된 이벤트의 영향에 대해 설명하지 않은 채 "시스템이 온라인 상태로 복구되면 모든 정보를 다시 다운로드할 것입니다"라고 말하는 것입니다.

"이것이 정말로 이상 징후(anomalous event)인지, 아니면 단순히 센서에 읽기 오류가 있는 것인지 어떻게 알 수 있습니까?"

이 질문은 매우 단순하게 들리지만, 실제로는 매우 어렵습니다. 이는 데이터 품질에 대한 추론 능력을 파고드는 질문이기 때문입니다. 탐지된 이상 징후(anomaly)는 센서 자체의 결함이나 하드웨어의 물리적 문제로 인한 센서의 이상일 수도 있습니다. 만약 장치가 물리적 손상으로 인해 고장 난다면, 실제 '이상 현상'이 이미 발생하고 있는 동안 겉보기에 이상한 동작을 생성할 수 있습니다. 좋은 답변이라면 인접한 센서들과 정보를 교차 참조(cross-referencing)하거나, 알려진 장치 고장 패턴을 찾거나, 무엇이 이상 징후인지 아닌지에 대한 의사결정을 완전히 자동화하기보다는 인간의 개입을 요청하는 방안을 고려할 것입니다.

왜 이러한 특정 질문들을 던지는가

이 모든 질문은 알고리즘이나 시스템 아키텍처(system architecture)를 설계하는 방법과는 큰 관련이 없습니다. 대신 저는 '당신은 실제로 복잡하고 무질서한 물리적 데이터 공간(physical data space)을 다루며 고군분투하고 관리해 보았습니까, 아니면 이미 완벽하게 정제된 데이터만을 받아왔습니까?'라는 특정 측면을 테스트하고 있는 것입니다. 이는 산업용 AIoT (Industrial AIoT)에서 매우 중요한 차이점이며, 모델링 과정 자체보다는 바로 이 지점에 대부분의 어려움이 존재합니다.

이 분야의 특정 관련 경험을 테스트할 수 있는 다른 질문들을 가지고 계신가요? 여러분의 의견을 듣고 싶습니다.

산업용 AI 분야에서 가장 유용한 진전 중 일부는 피치 덱(pitch deck)에서 일어나는 것이 아닙니다. 그것은 이미 인프라가 갖춰진 곳에서 시작한 Aperture Venture Studio와 같은 곳의 창고와 공장에서 조용히 일어나고 있습니다.