저는 'Physical AI'라는 단어를 크게 사용하고 싶지는 않습니다. 제가 가진 것은 로봇이나 운동 제어 기술이 아니라, Sony MESH의 근접 센서를 브라우저에 연결한 작은 작품과 기계의 진동 데이터를 이용해 이상 감지를 시도했던 해커톤 기록, 이 두 가지 실측 데이터뿐입니다. 본 글에서는 이 두 가지를 나란히 놓고, 물리 세계에서 오는 값을 상대할 때 무엇을 확인했는지에 대해 쓰고자 합니다.
최근 'Physical AI'라는 단어를 자주 접하게 됩니다. 거창한 이야기를 하고 싶게 만드는 단어이지만, 제가 가진 것은 실제 장치 하나의 로그와 평가를 세 번 잘못했던 기록 하나가 전부입니다. 업계 동향이나 정의를 논할 만큼의 자료는 없습니다. 따라서 본 글에서는 제가 실측한 범위에 한정하여, 거기서 보인 것만을 쓰겠습니다. 각 현장에서 무엇을 개선했는지는 이미 다른 글로 작성했습니다. 여기서는 그 내용을 반복하기보다는, 두 가지를 나란히 놓았을 때 비로소 보이게 되는 '확인 방법' 자체에 대해 이야기합니다.
확인하기 전에는 직관을 믿고 있었다
두 프로젝트는 공통된 형태가 있습니다. 처음 직감으로 세운 가정이 있었는데, 그것을 실제 장치나 데이터 로그로 계산해 보니, 그 가정보다 현실이 무너져 있던 경우입니다.
MESH 블록 장난감에서는 '반응이 느리다'라는 감각이 먼저였고, 공식 문서의 '정시 알림은 500ms마다'라는 설명으로 충분하다고 생각했습니다. 진동 데이터 이상 감지에서는 '행(row) 수가 수십만 개니까 어느 정도 규모의 데이터겠지'라는 막연한 믿음이 먼저였습니다. 둘 다 로그를 실제로 세어보기 전까지는, 확인하지 않은 채 믿고 있던 가정들이었습니다.
이러한 확인 과정은 도표로 나타내면 다음과 같습니다.
사이아(彩): 근접 값의 신뢰도에 대하여
사이아는 Sony MESH의 밝기 블록을 Web Bluetooth를 이용해 브라우저에 직접 연결한 단일 HTML 파일 작품입니다. 전용 앱이나 중계 서버를 사용하지 않으며, 외부 라이브러리나 이미지, 폰트도 불러오지 않습니다. 네트워크로 아무것도 보내지 않습니다. 팀원들과 이틀간의 해커톤 형식 워크숍을 통해 만들었습니다. 블록에 손을 가까이 가져가면 화면 속 '모찌'가 움푹 꺼지고, 멀어지면 작은 모찌가 날아갑니다. 같은 조작은 공중에서 별을 모으는 미니게임으로도 활용됩니다.
2026년 9월 13일에 실제 장치로 확인한 내용을 기록합니다. Mac의 Chrome으로 밝기 블록에 연결하여, 204초 동안 4,111회의 알림을 수신했습니다. 평균적으로는 약 49.7ms 간격이며, 초당으로는 약 20회입니다. 4,111회 모두에서 체크섬(checksum)이 일치하는 것도 확인했습니다. 근접 값 자체는 손이 없을 때는 26이 가장 많고 (최소 24), 손을 가까이 가져가면 최대 671까지 올라갑니다.
이것들은 추측이 아니라, 실제로 로그를 추출하여 센 수치입니다. 아직 확인하지 못한 부분도 있습니다. 움직임 블록은 연결 안정성이 좋지 않습니다. 버튼 블록은 실제 장치 동작을 기록하고 있지 않습니다. iPhone과 iPad는 Web Bluetooth를 지원하지 않아, 블록으로는 작동시키고 손가락으로만 가지고 놀 수 있습니다. 아이나 요양 중인 시간대에 의미가 있을지는 아무것도 확인하지 못했습니다.
근접 값의 변화는 손을 가까이 가져가는 길이와 떼는 속도의 두 축으로 읽어, 다섯 가지 손동작에 분류했습니다. 0.25초 미만으로 떼는 '촙', 0.7초와 2.5초를 경계로 한 '짧게/길게/쥐기', 근접성의 흔들림이 작게 유지되는 채 12초가 지속되는 '지속', 피크에서 0.15초 이내인지 또는 그 이후인지를 나누는 '훅/살짝'입니다. 이 분류는 모찌의 반응 강도나 날아가는 수에 직결됩니다.
사람 신체 측면의 설계는 당사자 멤버와 물리치료사(理学療法士)의 조언을 바탕으로 결정했습니다. 수액 주입 중에는 팔을 크게 움직이기 어려운 경우가 있다는 현장의 목소리를 듣고, 기본 동작을 '가져다 대기만 하는 것'으로 한정했습니다. 모찌 점프에서는 살짝 떼면 하강 속도가 느려집니다. 손을 빠르게 움직일 수 없는 사람도 별을 잡기 쉽게 하기 위한 조정입니다. 별을 놓쳐도 점수는 내려가지 않습니다. 실패라는 상태 자체가 이 작품에는 없습니다.
작품 전체는 index.html
하나의 파일로 완결되며, 모찌(もち)나 별, 배경은 모두 Canvas에서 그 자리에서 그려집니다. 모찌의 목소리나 신음 소리는 Web Audio를 이용해 합성하며, 마이크를 사용하는 '목소리' 기능도 음량만 읽을 뿐 녹음이나 전송은 하지 않습니다. 소스 코드는 열람용으로 공개되어 있으며, 이용은 허가제입니다. 자동 테스트는 Playwright로 64건을 준비했으며, 여기에는 실제 장치의 밝기 블록에서 실제로 촬영한 10.4초 분량의 210회 로그를 기록된 시각에 맞춰 재생하는 테스트가 포함되어 있습니다. 가상의 값이 아닌, 실측된 센서 파형 그 자체를 재생하여 앱의 반응을 확인하고 있다는 점이 이 프로젝트에서 가장 실제 장치와 유사하다고 생각합니다.
진동 데이터: 행 수는 표본 수가 아니었다
진동 데이터 이상 탐지에서는 기계의 진동을 측정한 시계열 센서 데이터로, 한 해커톤 과제에 참여했습니다. 평가는 F1 점수를 기준으로 리더보드가 있는 제출 형식으로 이루어졌습니다. 여기서 언급하는 수치는 대회 실데이터 그 자체가 아니라, 같은 구조를 합성 데이터로 재현한 공개 리포지토리의 수치입니다. 이유는 나중에 설명하겠습니다.
배포된 데이터는 행(row)만 보면 규모가 큰 테이블이었습니다. 하지만 행을 운전 조건의 변화 추이에 따라 배열해 보니, 일정한 운전점에서 측정하는 구간이 단계적으로 운전점을 올리며 이어지는 '스윕(sweep)' 형태임을 알 수 있었습니다. 레이블은 행이 아니라 스윕, 즉 기계 개체 단위로 붙어 있습니다. 행 수가 많다는 것은 개체당 측정 지점의 수가 많다는 것이지, 표본 수가 많다는 의미는 아니었습니다.
여기서 첫 번째 누수(leak)를 발견했습니다. 행이나 트라이얼 단위로 무작위하게 분할하면, 같은 기계의 다른 시점 데이터가 학습용과 평가용 양쪽에 섞이게 됩니다. 모델은 이상 여부를 구분하고 있는 것이 아니라, 그 기계의 지문(fingerprint)을 기억하는 것만으로도 높은 점수가 나오게 됩니다. 공개된 리포지토리(vibration-anomaly-lab)에서는 이 현상을 10개체(그중 2개체가 고장난 상태)의 완전한 합성 데이터로 재현했으며, 행이나 트라이얼 단위로 무작위하게 분할했을 때는 30개의 시드 모두에서 개체 수준의 F1 점수가 1.000에 도달했습니다. 반면, 기계 전체를 통째로 빼내어 평가하는 분할 방식으로 전환하자 평균 0.758까지 떨어졌고, 1.000에 도달한 경우는 30개 시드 중 12건에 불과했습니다. 또한, 원시 특징(raw feature)만으로 기계의 개체 번호를 평균 정확도 0.859(우연일 경우 0.100)로 맞힐 수 있다는 것도 확인되었으며, 이것이 누수의 정체입니다. 이 리포지토리 역시 열람용으로 공개되어 있으며, 이용은 허가제입니다.
수정 후에도 누수는 두 번 더 형태를 바꾸어 나타났습니다. 첫째는 채점 시스템 자체에서, 둘째는 공개된 점수를 통해 정답에 관한 정보가 읽힐 수 있다는 것이었습니다. 그리고 공개된 점수를 본 후에 어떤 모델을 최종적으로 사용할지 결정한 행위 자체가 또 하나의 누수가 되어 있었습니다. 첫 번째 분할의 누수는 데이터 자르기 방식만 고치면 되었지만, 이후 두 가지는 데이터 자체의 문제가 아니라 '자신이 점수를 어떻게 다루었는지' 쪽에 있었습니다.
대책 자체는 특별하지 않습니다. 기계를 통째로 격리하여 평가에 사용하고, 최종적으로 어떤 모델을 사용할지 공개된 점수를 보기 전에 결정하는 것입니다. 이 두 가지가 전부입니다. 효과를 본 것은 방법론의 복잡함이 아니라, 언제, 어떤 정보를 보고 판단했는지라는 순서였습니다.
두 가지를 나란히 놓고 보니 보인 것
아야(彩)는 49.7ms마다 도착하는 근접값을 그대로 믿을 수 있을지 4,111번의 체크섬으로 확인하고 있었습니다. 센서에서 피드백까지의 루프는 밀리초 단위로 빠른 루프입니다. 진동 데이터 쪽은 행 수를 다시 세는 것부터 시작하여, 분할-채점-모델 선택이라는 세 지점에서 누수를 겪었습니다. 이쪽은 평가 그 자체의 정확성을 확인하는, 좀 더 느린 루프입니다.
속도도, 의심하는 대상도 완전히 다릅니다. 그럼에도 근간에는 같은 질문이 있다고 생각합니다. 실제 장치나 데이터에서 온 값을 자신의 추측대로 믿는 것이 아니라, 세어보고 확인할 수 있는가 하는 것입니다. Physical AI라는 이름을 내세우기 전에 확인해 봐야 할 것은 아마 이 지루한 작업일 겁니다.
만들어보면서
두 프로젝트를 나란히 써보면서 스스로도 의외였던 점은 공통점이 '센서'나 '이상 탐지'가 아니라, 확인하는 형태 그 자체였다는 것입니다. 아야를 만들 때는 반응 지연을 공식 문서의 설명으로 이해하고 있었고, 진동 데이터에 직면했을 때는 행 수의 많음을 표본 수의 많음과 착각했습니다. 둘 다 실제로 로그를 찍어 세기 전까지는 그럴듯한 착각 상태였습니다.
이 글을 쓰기 전에는 두 가지 작품을 별개의 이야기로 가지고 있었습니다. 나란히 놓고 보니, 한쪽은 수십 밀리초(ms)의 피드백이고 다른 쪽은 평가 설계라는, 다루는 시간 길이가 완전히 다른 작업임에도 불구하고, 하는 일의 골격은 같다는 것을 깨달았습니다. 바로 숫자를 보고 자신의 가정을 무너뜨리는 지점입니다.
다음에 하고 싶은 것은 이 두 가지를 더 가깝게 만드는 것입니다. 센서 로그를 진동 데이터 때와 같은 검증의 시각으로 다시 살펴보거나, 평가 설계의 개념을 더 빠른 루프 프로젝트에 가져가 보려고 합니다. 이번에 확인된 것은 여기까지이며, 아동이나 재활 과정에서 의미가 있는지 여부, Physical AI 전체의 동향과 정의는 아직 제 역량 밖입니다.
논의(Discussion)
