AIVEX는 왜 '하이브리드 컴퓨팅'을 선택했는가

판정이 한 번 늦으면 라인 전체가 밀립니다

제조 현장의 비전검사는 초당 수십 장의 이미지를 실시간으로 판정하는 작업입니다. 검사 한 건이 지연되면 그 지연은 해당 제품 하나에서 끝나지 않고 라인 전체의 택트 타임(takt time)을 밀어냅니다. 판정이 틀리면 불량을 흘려보내는 미검이거나 양품을 걸러내는 과검이고, 둘 다 수율과 비용에 그대로 반영됩니다.

그래서 시스템을 설계할 때 가장 먼저 결정해야 하는 것은 알고리즘의 종류가 아니라 연산의 위치입니다. 이 계산을 장비 안에서 처리할 것인가, 서버로 보낼 것인가. 저희가 이 질문에 내린 답은 둘 중 하나를 고르는 것이 아니라, 둘을 모두 쓰되 역할을 겹치지 않게 나누는 것이었습니다.

잘하는 일이 아니라 못하는 일을 기준으로 나눴습니다

연산의 위치를 정할 때 저희가 기준으로 삼은 것은 각 환경이 잘하는 일이 아니라 구조적으로 못하는 일이었습니다.

검사 장비 안에서 도는 연산은 네트워크를 타지 않습니다. 트리거가 걸린 자리에서 곧바로 판정이 나오므로 응답이 밀리초 단위에 머물고, 통신이 끊겨도 라인은 그대로 돕니다. 원본 이미지가 장비를 벗어날 일도 없습니다. 대신 장비의 연산 자원은 지금 지나가는 제품을 판정하는 데 거의 전부 쓰이고 있습니다. 같은 자원으로 수만 장 규모의 재학습을 돌릴 수는 없습니다. 검사 장비는 판정을 하고, 학습은 하지 못합니다.

클라우드는 반대편에 있습니다. 여러 라인과 여러 사이트의 운영 현황을 한자리에서 보고, 모델의 이력을 추적하고, 언제 어떤 학습이 돌았는지를 관리하려면 이 계층이 필요합니다. 그러나 판정 요청이 네트워크를 왕복하는 순간 응답 시간이 회선 상태에 묶이고, 학습을 이 계층에 올리려면 원본 이미지가 고객사 경계를 벗어나야 합니다. 클라우드는 실시간 판정을 못하고, 원본 이미지는 받아서도 안 됩니다.

그러면 학습은 어디에서 도는가. 남는 자리는 고객사 서버실입니다. 장비만큼 시간에 쫓기지 않으면서 고객의 네트워크 경계 안에 있는 유일한 환경이고, 저희가 학습 노드를 여기에 두는 이유입니다. 하이브리드라고 하면 흔히 학습을 클라우드로 올리는 구조를 떠올리지만, 저희 구조에서 클라우드로 올라가는 것은 학습 연산이 아니라 그 학습이 무엇을 가지고 언제 무엇을 만들었는지에 대한 기록입니다.

[표 1] 계층별로 하는 일과 하지 않는 일

그래서 계층을 셋으로 나눴습니다

저희는 검사의 라이프사이클을 장비 계층, 공장 계층, 클라우드 계층의 세 층으로 나누고 각 층이 맡을 일의 경계를 고정했습니다. 앞의 두 계층은 모두 고객사 안에 놓입니다. 판정은 장비 안에서 끝나고, 원본 이미지 보관과 학습 연산은 같은 공장의 서버실에서 이루어지며, 클라우드는 그 학습을 요청하고 결과를 추적하는 MLOps 플랫폼만 맡습니다. 계층을 나눈 것 자체보다, 어떤 트래픽이 계층을 넘어가고 어떤 트래픽은 넘어가지 못하게 할 것인지를 정한 쪽이 실질적인 설계였습니다.

[표 2] 3계층 구성과 계층 간에 오가는 데이터

계층 사이를 오가는 데이터는 다음과 같습니다. 장비와 공장 사이에서는 검사 결과와 원본 이미지가 올라가고 재학습된 모델이 내려옵니다. 공장과 클라우드 사이에서는 검사 이력과 학습 결과 메타데이터가 올라가고 학습 요청과 관리 명령이 내려옵니다.

판단은 장비 안에서 끝냅니다

장비 계층에는 세 가지가 들어갑니다. 물류 제어 시스템이 투입과 이송, 배출을 관장하면서 검사존에 제품이 들어오는 순간 검사 트리거를 발생시킵니다. 실시간 검사 시스템이 그 트리거를 받아 딥러닝 모델과 룰 기반 알고리즘을 함께 돌려 즉시 판정을 냅니다. 운영 콘솔이 장비의 실시간 제어와 모니터링을 담당하고 검사 결과를 1차로 저장합니다.

두 시스템은 속도와 디바이스 연동성 때문에 네이티브 언어로 구현되어 검사 PC 한 대 안에 함께 올라갑니다. 촬상면이 많거나 알고리즘이 무거운 장비에서는 검사 PC를 여러 대 두고 검사 시스템을 여러 벌 병렬로 구동합니다.

이 계층에 판정을 붙들어 둔 이유는 단순합니다. 판정이 클라우드까지 왕복하는 구조라면 라인 속도가 네트워크 상태에 인질로 잡힙니다. 네트워크가 죽어도 라인은 죽지 않아야 한다는 것이 저희가 가장 먼저 세운 원칙입니다.

학습도 공장 안에서 돕니다

공장 계층은 고객사 서버실에 놓입니다. 검사이력·수율 관리 플랫폼이 각 장비의 운영 콘솔에서 검사 결과를 수집해 시각화하고, 과검과 미검을 다시 확인하는 화면을 제공합니다. 이미지 전송 에이전트가 검사 PC에 쌓인 이미지를 같은 사이트의 스토리지로 옮기고, 학습 노드가 그 이미지를 보관하면서 실제 학습 연산을 수행합니다.

이 계층의 핵심은 학습 인스턴스가 클라우드가 아니라 여기에 있다는 점입니다. 이미지는 장비에서 같은 공장 안의 서버로만 이동하고, 재확인과 라벨링, 학습 실행, 그리고 학습 결과로 나온 모델 파일까지 전부 고객사 자원 위에 남습니다. 민감한 제조 이미지 원본이 고객의 네트워크 경계를 벗어나는 구간 자체가 존재하지 않습니다.

클라우드에는 MLOps 플랫폼만 둡니다

클라우드 계층에는 MLOps 플랫폼과 메타데이터 데이터베이스를 둡니다. 장비의 운영 콘솔이 장비를 다루고 공장의 관리 플랫폼이 검사 이력을 다루는 것처럼, MLOps 플랫폼은 학습과 모델을 다룹니다. 학습을 요청하고, 배포된 모델의 버전을 확인하고, 여러 사이트의 운영 현황을 한자리에서 보는 일이 여기에서 이루어집니다. 메타데이터 데이터베이스에는 어떤 데이터로 어떤 모델이 언제 만들어졌는지가 기록됩니다.

학습 연산은 이 계층에서 일어나지 않습니다. 클라우드는 학습을 실행하는 곳이 아니라, 공장 안에서 실행된 학습을 사람이 관리할 수 있게 만드는 곳입니다. 여러 고객사와 여러 라인에서 올라온 운영 메타데이터가 이 계층에 쌓이면서 개선 노하우가 축적됩니다. 정리하면 클라우드에는 요청과 기록만 흐르고, 원본 이미지와 학습 연산은 고객사 경계 안에 남습니다.

데이터는 한 방향으로만 흐르지 않습니다

세 계층은 위아래로 쌓인 조직도가 아니라 데이터가 돌아 나가는 경로입니다. 정방향으로는 현장에서 만들어진 검사 결과와 원본 이미지가 같은 공장 안의 학습 노드로 올라가고, 클라우드로는 그 과정에서 생긴 이력과 메타데이터만 전달됩니다. 역방향으로는 클라우드에서 내려온 학습 요청이 공장 서버의 학습 노드를 돌리고, 거기서 재학습된 모델이 각 검사 장비로 배포됩니다. 모델 파일이 클라우드를 거쳐 오는 것이 아니라, 만들어진 자리에서 곧바로 라인으로 내려갑니다.

이 루프가 한 바퀴 돌 때마다 현장에서 걸러진 과검과 미검이 다음 모델의 학습 데이터가 됩니다. 검사 장비는 판정만 하는 단말이 아니라 학습 데이터를 만들어 내는 지점이 되고, 모델은 배포된 시점에 고정되지 않고 라인이 돌아가는 동안 함께 갱신됩니다.

루프가 유지되려면 네 가지 원칙이 깨지지 않아야 합니다. 판정 트래픽은 장비 안에서 완결되어야 라인 속도가 보호되고, 원본 이미지와 학습 연산은 고객사 안에 남아야 보안과 컴플라이언스가 성립하며, 클라우드는 관리와 기록 역할에만 머물러야 사이트를 늘리기 쉽고, 이 셋이 지켜져야 루프가 도는 만큼 판정 정확도가 실제로 올라갑니다.

한쪽으로만 갔다면 어디가 무너지는지

전부 온프레미스로 가는 선택지를 먼저 검토했습니다. 저희 구조에서는 학습 연산이 이미 고객사 안에서 돌기 때문에, 남은 관리 계층까지 고객사에 넣는 것이 불가능한 선택은 아니었습니다. 다만 그렇게 하면 고객사마다 학습 이력과 모델 버전을 관리하는 시스템을 따로 세우고 따로 운영하게 되므로, 한 사이트에서 얻은 개선 노하우가 다른 사이트로 넘어가지 못합니다. 관리 도구의 설치와 업데이트 부담도 고객사가 떠안게 되어 총소유비용이 올라갑니다. 여러 라인과 여러 고객사의 운영 현황을 묶어서 보는 일도 불가능해집니다.

반대로 전부 클라우드로 가면 세 가지가 한꺼번에 걸립니다. 판정 경로에 네트워크 지연이 끼어들어 택트 타임이 무너지고, 학습을 위해 원본 이미지를 외부로 내보내야 하므로 보안 요건을 통과하기 어려우며, 통신 장애가 곧 라인 정지가 되어 가용성이 떨어집니다.

그래서 어느 한쪽에 몰아넣는 대신 관심사별로 담당 계층을 갈랐습니다. 각 관심사를 그 계층에 둔 이유는 아래와 같습니다.

[표 3] 관심사별 담당 계층과 배치 근거

이 구조가 현장에서 만드는 차이

첫째로 라인 속도가 네트워크 상태와 분리됩니다. 회선이 불안정한 날에도 판정 속도는 변하지 않습니다. 둘째로 민감한 제조 이미지가 고객의 물리적 경계 밖으로 나가지 않으므로, 보안 검토 단계에서 막히는 구간이 줄어듭니다. 학습까지 같은 경계 안에서 끝나기 때문에 반출 승인을 받아야 하는 데이터가 애초에 생기지 않습니다. 셋째로 현장 데이터로 재학습된 모델이 정기적으로 라인에 반영되어, 도입 시점의 성능이 그대로 유지되는 것이 아니라 시간이 지날수록 나아집니다. 넷째로 신규 라인이나 신규 고객사가 늘어도 클라우드의 관리 계층은 그대로 확장되므로 사이트가 늘어나는 만큼 운영 부담이 비례해서 늘지 않습니다. 마지막으로 비용이 예측 가능해집니다. 학습 서버를 포함한 현장 설비는 한 번 투자하는 자산이고, 클라우드는 관리 계층만 올라가 있어 이미지 전송량이나 학습량이 늘어도 클라우드 비용이 따라 뛰지 않습니다.

도입을 검토하신다면

저희가 하이브리드 구조를 택한 이유는 아키텍처 다이어그램을 복잡하게 그리기 위해서가 아닙니다. 라인은 멈추면 안 되고, 데이터는 새면 안 되며, 모델은 그 자리에 머물러서는 안 된다는 세 가지 요구가 현장에서 동시에 들어오기 때문입니다. 이 셋을 한꺼번에 만족시키려면 연산을 한 곳에 몰아둘 수 없습니다.

비전검사 시스템 도입을 검토하고 계시다면, 어떤 벤더의 구조든 세 가지를 확인해 보시기를 권합니다. 네트워크가 끊겼을 때 판정이 멈추는지, 원본 이미지가 어디에 저장되고 학습은 어느 서버에서 도는지, 그리고 도입 6개월 뒤에도 모델이 계속 좋아지고 있는지입니다. 논의 하시는 벤더가 이 세 질문에 모두 답할 수 있지 않다면 언제든지 저희의 문을 두드려 주십시오.