설비마다 말이 다릅니다: AAS가 요구 조건인 이유
자율형공장 지원사업 공고를 보면 요구 조건이 셋입니다. AI, 디지털트윈, 그리고 AAS입니다. 앞의 둘은 무엇을 말하는지 대충 짐작이 갑니다. 그런데 AAS는 말 자체가 낯설고, 업체 견적서에도 대개 한 줄로만 적혀 있습니다.


자율형공장 지원사업 공고를 보면 요구 조건이 셋입니다.
AI, 디지털트윈, 그리고 AAS입니다. 앞의 둘은 무엇을 말하는지 대충 짐작이 갑니다. 그런데 AAS는 말 자체가 낯설고, 업체 견적서에도 대개 한 줄로만 적혀 있습니다.
셋 중에서 가장 조용히 빠지는 항목이 이것입니다. 데이터를 모으는 항목과 한 줄에 묶여 있어서, 수집만 하고 AAS는 안 했는데도 견적서에서는 다 한 것처럼 보입니다.

AAS는 자산관리셸이라고 옮깁니다
Asset Administration Shell을 줄인 말입니다. 국제표준 IEC 63278에 정의돼 있습니다.
설비 하나하나에 씌우는 표준 껍데기라고 생각하시면 이해가 빠릅니다.
껍데기 안에는 그 설비가 무엇인지, 무엇을 할 수 있는지, 지금 어떤 상태인지가 정해진 형식으로 들어갑니다. 설비를 만든 회사가 다르고 나이가 달라도, 껍데기를 통해 보면 같은 형식으로 보입니다.
여기서 핵심은 껍데기의 형식이 국제표준으로 정해져 있다는 점입니다. 우리 공장에서만 쓰는 규칙이 아니라 밖에서도 통하는 규칙입니다.
왜 껍데기가 필요한가
설비마다 쓰는 말이 다르기 때문입니다.
같은 온도인데 어떤 설비는 temp로 적고, 어떤 설비는 T1이라고 적고, 어떤 설비는 한글로 적습니다. 단위도 다릅니다. 어떤 값은 섭씨이고 어떤 값은 이미 보정된 값입니다.
사람은 맞춰 읽습니다. 시스템은 못 읽습니다.
그래서 통합할 때마다 번역표를 만듭니다. 설비 열 대면 열 개, 새 설비가 들어오면 또 하나. 이 번역표는 대개 담당자 머릿속이나 엑셀 한 장에 있고, 그 사람이 바뀌면 같이 사라집니다.
AAS는 그 번역을 설비 쪽에 미리 붙여 두는 방식입니다. 읽는 쪽에서 매번 맞추는 게 아니라, 내보내는 쪽이 표준 형식으로 내보냅니다.
차이가 크게 나는 지점은 설비를 늘릴 때입니다
방식 | 설비 10대 | 설비 20대 |
|---|---|---|
번역표 | 맞출 곳 10 | 조합이 크게 늘어남 |
AAS | 형식 1개 | 형식 1개 그대로 |
번역표 방식은 설비가 늘어날수록 맞출 곳이 같이 늘어납니다. AAS 방식은 새 설비도 같은 형식으로 내보내니까 받는 쪽을 고칠 일이 줄어듭니다.
당장 설비 서너 대만 다루신다면 체감이 크지 않을 수 있습니다. 다만 라인을 늘리거나 공장을 하나 더 지을 계획이 있으시면 그때 차이가 드러납니다.

데이터를 모으는 것과 표준으로 통일하는 것은 다른 일입니다
이 문장이 이 글에서 가장 중요합니다.
수집은 값을 가져오는 일입니다. AAS는 그 값이 무엇을 뜻하는지를 정해진 형식으로 붙이는 일입니다.
수집만 하면 숫자는 쌓입니다. 그런데 반년쯤 지나서 그 숫자가 무엇이었는지 물어보면 답할 사람이 없습니다. 컬럼 이름은 남아 있는데 그게 어느 설비의 어느 지점이었는지, 단위가 무엇이었는지가 안 남습니다.
구분이 어려우시면 이렇게 생각하시면 됩니다. 수집은 배관을 놓는 일이고, AAS는 그 배관에 무엇이 흐르는지 표시를 붙이는 일입니다.
배관만 놓아도 물은 흐릅니다. 다만 나중에 어느 관에 무엇이 흐르는지 알려면 그때 다시 열어 봐야 합니다. 설비가 스무 대면 스무 번입니다.
견적서에서 이 둘이 한 줄에 묶여 있으면 반드시 나눠서 물어보셔야 합니다. 금액도 일정도 다른 작업입니다.
왜 정부 과제가 이걸 요구하는가
AI와 디지털트윈이 계산을 하려면 입력의 뜻이 정해져 있어야 하기 때문입니다.
같은 이름의 값이 공장마다 다른 것을 가리키면, 한 공장에서 만든 모델을 다른 공장에 적용하지 못합니다. 매번 처음부터 다시 만들어야 합니다. 그러면 사업의 목적인 확산이 안 됩니다.
그래서 표준이 요구 조건에 들어갑니다. 이 공장 하나를 잘 만드는 것이 아니라 다음 공장으로 넘어갈 수 있게 만드는 것이 조건인 셈입니다.
빠지는 방식도 대체로 비슷합니다. 처음 계획서에는 들어가 있는데, 구축 중에 일정이 밀리면 화면과 기능이 먼저 만들어지고 표준화가 뒤로 갑니다. 그리고 뒤로 간 것은 대개 안 돌아옵니다.
눈에 보이는 산출물이 없기 때문입니다. 화면은 시연할 수 있지만 표준화는 시연할 것이 없습니다.

껍데기 안에는 무엇이 들어가나
표준이 정한 것을 실무 언어로 옮기면 대체로 세 묶음입니다.
첫째, 이 설비가 무엇인가. 제조사, 모델, 일련번호, 설치 위치, 도입 시점 같은 것들입니다. 바뀌지 않는 정보이고, 대개 이미 어딘가에 있습니다. 문제는 그 어딘가가 대장 엑셀이고 최신이 아니라는 점입니다.
둘째, 이 설비가 무엇을 할 수 있는가. 처리 가능한 품목, 정격 속도, 허용 범위 같은 것들입니다. 이 묶음이 있어야 시스템이 "이 작업을 이 설비에 태울 수 있나"를 스스로 판단합니다.
셋째, 지금 어떤 상태인가. 가동·정지·알람, 현재 값, 최근 이력입니다. 실시간으로 바뀌는 부분이고 수집과 맞닿아 있습니다.
세 묶음 중 첫째와 둘째가 자주 빠집니다. 셋째는 수집 작업에 자연히 따라오는데, 앞의 둘은 따로 정리해야 하고 눈에 띄는 화면도 안 나오기 때문입니다. 그런데 나중에 계산을 시키려면 앞의 둘이 필요합니다.
어디서부터 만드나
설비 전부를 한 번에 하실 필요는 없습니다. 실무에서는 순서가 있습니다.
먼저 병목 공정의 설비부터 합니다. 라인 전체 성과를 정하는 자리이고, 여기 데이터가 정리되면 다른 공정을 안 건드려도 판단이 하나 늘어납니다.
그다음은 여러 시스템이 함께 보는 설비입니다. 품질과 생산이 같은 설비 데이터를 다르게 부르고 있으면 그 자리가 통역 비용이 제일 큰 곳입니다.
새로 들어오는 설비는 처음부터 표준 형식으로 받습니다. 발주 사양에 한 줄 넣는 것으로 되는 경우가 많고, 나중에 만드는 것보다 훨씬 쌉니다. 최근 설비는 제조사가 표준 형식을 제공하기도 합니다.
반대로 곧 교체할 설비는 뒤로 미루셔도 됩니다. 남은 수명이 짧은 설비에 표준화를 하면 그 작업이 같이 사라집니다.
견적서에서 확인할 세 가지
AAS가 별도 항목으로 잡혀 있습니까, 데이터 수집에 묶여 있습니까. 묶여 있으면 각각의 금액과 기간을 나눠 달라고 하십시오.
대상 설비가 몇 대이고 어느 항목까지 표준 형식으로 만듭니까. 전부인지 일부인지, 일부라면 무엇이 빠지는지.
새 설비가 들어오면 그 설비의 AAS는 누가 만듭니까. 우리가 만듭니까, 업체가 옵니까, 설비 제조사가 주고 옵니까.
3번이 나중에 부담이 됩니다. 처음 스무 대를 표준화해 놓아도 이후에 들어오는 설비가 그대로면 시간이 지날수록 다시 섞입니다.
지금 상태를 재보시려면
거창하게 시작하실 필요는 없습니다. 한 가지만 해 보시면 위치가 나옵니다.
설비 두 대를 골라서 같은 항목의 데이터를 나란히 놓아 보십시오. 예를 들면 가동 상태나 온도입니다.
이름이 같습니까
단위가 같습니까
값이 없을 때 표현하는 방식이 같습니까
셋 다 같으면 이미 어느 정도 정리된 상태입니다. 하나라도 다르면 그 차이를 누가 어디서 맞추고 있는지 확인해 보십시오. 대개 사람이 맞추고 있고, 그 사람 머릿속에만 있습니다.
이 확인은 시스템을 열어 보지 않아도 됩니다. 설비 담당자에게 두 설비의 항목 이름을 물어보시는 것으로도 대체로 답이 나옵니다. 바로 답이 안 나오면 그 자체가 지금 상태를 말해 줍니다.
우리 것으로 만들어 두면 남는 것
표준을 따르는 일의 값어치는 지원사업 자격만이 아닙니다.
설비 정보를 표준 형식으로 정리해 두면 그것 자체가 자산이 됩니다. 시스템을 바꿔도 따라가고, 새 업체가 들어와도 설명하는 시간이 줄고, 담당자가 바뀌어도 남습니다.
반대로 정리가 안 돼 있으면 매번 같은 일을 반복합니다. 새 프로젝트가 시작될 때마다 설비 목록을 다시 뽑고, 태그 이름을 다시 맞추고, 단위를 다시 확인합니다. 이 일은 견적서에 잘 안 잡히는데 실제로는 매번 몇 주씩 들어갑니다.
그래서 지원사업과 무관하게, 설비 대장을 한 번 제대로 정리해 두는 것만으로도 다음 프로젝트가 가벼워집니다. 표준 형식은 그 정리에 틀을 주는 것이라고 보시면 됩니다.
자주 받는 질문 둘
"설비가 오래돼서 아무 신호도 안 나오는데 AAS가 되나요."
됩니다. AAS는 설비가 스스로 만드는 것이 아니라 설비 바깥에 붙이는 껍데기이기 때문입니다. 신호가 안 나오면 상태 묶음은 비겠지만, 이 설비가 무엇이고 무엇을 할 수 있는지는 여전히 표준 형식으로 적어 둘 수 있습니다. 나중에 센서를 달면 그 자리에 값이 들어옵니다.
"MES나 ERP가 이미 있는데 또 만들어야 하나요."
기존 시스템이 설비 정보를 갖고 있다면 그것을 표준 형식으로 옮기는 일이 됩니다. 처음부터 조사하는 것보다 훨씬 가볍습니다. 다만 그 정보가 최신인지는 확인하셔야 합니다 — 설비 대장이 몇 년째 안 고쳐진 경우가 꽤 있습니다.
정리
AAS는 새 기능을 만드는 일이 아니라 이미 있는 값에 이름표를 다는 일에 가깝습니다. 그래서 눈에 띄는 화면이 안 나오고, 견적에서 제일 먼저 지워지기도 합니다.
다만 이걸 건너뛰면 그 위에 올리는 AI와 디지털트윈이 매번 새로 만들어져야 합니다. 요구 조건에 들어가 있는 이유가 거기 있습니다.
지원사업을 준비하고 계시지 않더라도 확인해 두실 값어치는 있습니다. 설비를 바꾸거나 시스템을 교체할 때 이전 데이터를 얼마나 가져갈 수 있는지가 여기서 갈리기 때문입니다. 형식이 정리돼 있으면 옮기는 일이고, 아니면 다시 만드는 일이 됩니다.
표준화가 왜 AI보다 먼저인지는 따로 적었습니다: 표준화 없이 AI 없다
이 글이 도움이 되셨다면 공유해 주세요
새 글이 올라오면 메일로 알려드립니다
제조 현장에서 확인한 것들을 기록합니다. 광고성 발송은 하지 않습니다.
제조 AI 성숙도 자가진단 — 회사 정보 없이 10문항이면 됩니다.

제조 AI 운영체제 VEXPLOR를 만들고 있습니다. 스마트공장 구축 현장에서 데이터 표준화·온톨로지·디지털트윈·자율형공장을 다루며, 이 블로그에는 현장에서 실제로 부딪힌 문제와 그때 내린 판단을 씁니다.
contact@wace.me이 문제를 실제 현장에서 풀고 있습니다
(주)웨이스는 제조 AI 운영체제 VEXPLOR로 데이터 표준화부터 자율형공장까지 만들어가고 있습니다. 우리 공장에 적용하면 어떤 모습일지 궁금하시면 편하게 물어보세요.
함께 읽어보세요
밤새 15번을 스스로 고친 루프, 무엇이 되돌릴 수 있게 했을까요
설비 수십 대가 맞물려 돌아가는 생산 라인을 3D로 재현하는 시뮬레이터를, 밤새 사람 없이 15라운드 돌렸습니다. 빌드 → 검증 → 수정 → 릴리스를 한 묶음으로 두고 그 묶음을 반복하게 한 것입니다. 아침에 결과를 열어 봤습니다.

진단 도구에 "채우지 않을 자유"를 넣었습니다
저희는 공장의 현황을 항목별로 매기는 진단 도구를 만듭니다. 값은 담당자에게 묻는 대신 회의 기록과 기존 자료로 자동으로 채워집니다.

시뮬레이션 화면이 보여주는 것과 엔진이 계산하는 것은 같을까
저희는 공장을 짓거나 바꾸기 전에 컴퓨터 안에서 먼저 돌려 보는 가상공장 소프트웨어를 만들고 있습니다. 지난 글에서는 왜 만드는지를 적었는데, 이번 글은 그 반대쪽에 있는 이야기입니다.
