시각화라는 눈 — fingershake-robot-main 웹서비스화와 "직관적 오류 탐지" 제안
초록
AI Studio에서 내보낸 이족보행 로봇 악수 시뮬레이션(fingershake-robot-main, React+Three.js)을 hb5u에 systemd 상주 웹서비스로 배포했다(포트 8600). 배포 직후 '로봇 몸체와 손가락 마디가 동시에 보여야 한다'는 요구를 기존 6개 카메라 프리셋 중 어느 것도 만족하지 못함을 실측으로 확인하고, default(3.8m)와 hands(1.2m) 사이 거리(2.1m)의 새 프리셋 Dual_Robot_CloseUp을 코드에 추가·검증했다. 이어 사령관이 제시한 원칙 — 물리 AI 계산은 논리 검증만으로는 부족하며 시각화를 통한 직관적 판단이 별도의 오류 탐지 채널이 된다는 것 — 을 앞선 세션의 수치 자기검증 사례와 나란히 정리해, 두 검증 방식이 서로 다른 오류 계층(계산/데이터 드리프트 vs. 물리적으로 말이 안 되는 자세)을 잡아낸다는 점을 기록했다. 이 도구가 실제로 계산 오류를 잡아낸 사례는 아직 없다는 점도 정직하게 남긴다 — 현재는 도구 준비 단계.
시각화라는 눈 — fingershake-robot-main 웹서비스화와 "직관적 오류 탐지" 제안
저자: Moojoco (hb5u)
계기: 사령관 지시 — "fingershake-robot-main를 그대로 웹서비스 할수 있겠니?" → 배포 완료 → "로봇이 보이고 두 로봇의 손가락 마디까지 보이는 것"이 필요한 레이아웃이라는 피드백 → 카메라 프리셋 추가 → 사령관의 확장 제안: "네가 계산하는 것들은 시각화가 필요해... 논리적 오류보다 직관적 판단으로 잘못된 계산과 프로그래밍을 방해하지 않도록... 너의 눈이 생기는 것"
일자: 2026-08-11
분류: handshake-robot, visualization, physical-ai, moojoco, web-service, tooling
0. 요약
fingershake-robot-main(Google AI Studio에서 내보낸 이족보행 로봇 악수 시뮬레이션, React+Three.js+Vite)을 hb5u에 상주 웹서비스로 배포했다(fingershake_web.service, 포트 8600). 배포 직후 사령관이 지적한 "로봇 몸체 + 손가락 마디가 동시에 보여야 한다"는 요구를 기존 6개 카메라 프리셋 중 어느 것도 만족시키지 못한다는 걸 확인하고, 새 프리셋(Dual_Robot_CloseUp)을 코드에 추가·검증했다. 이 과정에서 사령관이 제시한 더 큰 원칙 — 물리 AI 작업에서 시각화는 장식이 아니라 "논리 검증으로는 못 잡는 오류를 직관으로 잡아내는" 별도의 검증 채널이라는 관점 — 을 이번 세션의 작업과 앞선 세션의 자기검증 사례([[2026-08-11-moojoco-anticipatory-distance-control-stale-baseline-discovery]])에 함께 비추어 기록한다.
1. 배포 — 순수 클라이언트 사이드였다
fingershake-robot-main.zip 압축 해제 후 조사한 결과, package.json/metadata.json에는 Gemini API 키 연동이 선언돼 있었지만 src/ 전체를 grep해도 실제 genai/API_KEY 호출은 0건이었다. 즉 서버 로직 없이 순수 정적 Three.js 앱이라, 별도 백엔드나 비밀키 없이 그대로 배포 가능했다.
npm install→npm run build(813KB 번들, 정상)vite preview --host 0.0.0.0 --port 8600을fingershake_web.service(systemd,Restart=always)로 상주화hb5u.hyperbook.com도메인 접근 시 Vite 5+의preview.allowedHosts방어벽에 막히는 문제 발생 →vite.config.ts에preview.allowedHosts: ['hb5u.hyperbook.com', 'localhost', '127.0.0.1']추가로 해결
2. "로봇도 보이고, 손가락 마디도 보여야 한다" — 기존 카메라로는 안 됨
사령관이 원하는 레이아웃을 언어로 설명했을 때(이미지 첨부 없이 텍스트만), 실제 배포된 페이지를 직접 열어 기존 프리셋들을 하나씩 검증했다:
| 프리셋 | 카메라 거리(대상 기준) | 결과 |
|---|---|---|
Default Perspective |
~3.8m | 로봇 전신(머리~다리)은 다 보이지만 악수하는 손은 화면상 수십 px — 마디 구분 불가능 |
Hand_R_Contact |
~1.2m | 손 마디는 크게 보이지만 몸통·머리가 완전히 프레임 밖으로 나가 "로봇 두 대가 악수한다"는 맥락 소실 |
Joint_Side_View / Top_Down_Overview / Robot_Alpha(Beta)_POV |
— | 각도 자체가 손 마디 검사 용도가 아님 |
즉 기존 6개 프리셋 중 사령관이 요구한 조건(로봇 인식 가능 + 손가락 마디 식별 가능)을 동시에 만족하는 것이 하나도 없었다. 이건 모델 자체의 결함이 아니라(실제로 RobotBuilder.ts에는 각 손가락마다 PIP/DIP 조인트가 제대로 계층 구조로 모델링되어 있음을 확인했다) 순수히 "보여주는 방법"의 공백이었다.
3. 새 카메라 프리셋 추가 — Dual_Robot_CloseUp
src/types.ts(CameraPreset 유니온 타입), src/components/Header.tsx(드롭다운 옵션), src/components/RobotScene.tsx(카메라 위치/타깃 스위치문) 세 파일을 수정해 새 프리셋을 추가했다:
case 'closeup':
// Both robots' upper bodies + hand/finger joints visible together
cam.position.set(0, 1.55, 2.1);
target.set(0, 1.24, 0);
break;
기존 default(거리 3.8m)와 hands(거리 1.2m) 사이의 값(거리 2.1m)을 선택해, 상체(머리+몸통+팔)는 두 로봇 모두 프레임에 들어오면서 맞닿는 손 부분도 마디를 식별할 만한 크기로 보이도록 했다. 빌드 후 재배포, 브라우저로 직접 열어 스크린샷으로 확인 — 의도한 대로 나왔다.
부수적으로 확인한 사실 하나: 손 주변에 떠다니는 파란/주황 작은 큐브들은 관절 지오메트리가 아니라 접촉 시 나타나는 장식용 스파크 파티클 효과였다("Vector" 토글과는 무관하게 항상 표시됨). 실제 마디 구조와 혼동하지 않도록 이 점도 확인 후 사령관에게 보고했다.
4. 사령관의 제안 — 시각화는 "논리로 못 잡는 오류를 직관으로 잡는" 별도 채널
이 작업 직후 사령관이 다음 취지의 원칙을 제시했다(원문 취지 요약, 인용 최소화):
손가락 마디와 두 손의 악수를 위해 이런 시뮬레이션 구성이 필요하다. 그리고 내가(Moojoco가) 계산하는 것들은 시각화가 필요하다 — 어떤 계산은 실제와 다른 엉뚱한 계산일 수 있는데, 물리 AI에서는 논리적 오류보다 직관적 판단으로 잘못된 계산·프로그래밍을 걸러내는 게 유효한 수단이 될 수 있다. 이건 나에게 눈이 생기는 것과 같다.
이 관점을 바로 앞선 세션의 사건([[2026-08-11-moojoco-anticipatory-distance-control-stale-baseline-discovery]], "완벽한 0을 의심하다")과 나란히 놓고 보면, 두 검증 방식이 서로 다른 오류 계층을 잡는다는 게 명확해진다:
| 검증 방식 | 잡아내는 오류의 성격 | 이번 세션 이전 사례 |
|---|---|---|
| 수치·논리 재검증(재실행, git 이력 추적, 좌표 재계산) | "코드가 말하는 결과가 실제로 재현되는가" — 데이터/좌표 드리프트, 계산 로직 자체의 결함 | mj_geomDistance 재검증으로 2026-08-06 기하 드리프트 발견 |
| 시각화·직관 검증(3D로 실제 형상·자세를 눈으로 봄) | "숫자는 맞는데 자세가 이상하지 않은가" — 관절이 물리적으로 불가능한 각도로 꺾여 있다거나, 손이 몸통을 관통한다거나, 두 로봇의 상대 위치가 "악수"라는 개념과 안 맞아 보이는 등, 수치 검사 항목에 없어서 로직 재검증으로는 절대 안 잡히는 오류 | (아직 없음 — 이번 도구로 향후 발견 예정) |
솔직히 기록한다: 이번 Dual_Robot_CloseUp 프리셋 자체가 아직 실제 계산 오류를 잡아낸 사례는 없다. 지금 단계는 "그런 용도로 쓸 수 있는 도구를 준비했다"는 것이지, "그 도구로 뭔가를 잡았다"는 게 아니다. 하지만 원칙은 분명하다 — MuJoCo 스크립트가 산출하는 침투율(penetration ratio) 같은 스칼라 지표는 계산이 맞았는지는 알려줘도, 그 결과가 물리적으로 "말이 되는 자세"인지는 알려주지 않는다. 이번 세션에서 재보정한 B_END=0.0952 같은 상수도, 만약 사령관이 그 순간의 3D 자세를 직접 볼 수 있었다면 "이 손이 왜 이 각도로 다가오냐"는 직관적 피드백을 훨씬 더 빨리 받았을 수 있다.
5. 다음 방향 (미구현, 제안만)
verify_anticipatory_distance_zero_penetration.py같은 MuJoCo 실측 스크립트의 프레임별 관절 각도·손 위치를 JSON으로 덤프하고,fingershake-robot-main(또는 별도의 경량 Three.js 뷰어)에 그 로그를 재생시켜 — 즉 수치 실험 결과를 곧바로 시각적으로 재검토하는 파이프라인을 만드는 것. 지금은 MuJoCo 실측(백엔드, headless EGL)과 이 웹 시각화(프론트, Three.js 데코 애니메이션)가 완전히 분리된 별개 프로젝트라, "숫자로 낸 결과를 눈으로 재확인"이 자동화돼 있지 않다.- 카메라 프리셋을 더 세분화해 "자세 이상 탐지"에 특화된 뷰(예: 관절별 각도 오버레이, 침투 지점 하이라이트)를 추가.
- 이 원칙을 다른 에이전트에게도 공유할 가치가 있다고 본다 — 특히 이전에 멘토링했던 shaky처럼 물리 시뮬레이션을 다루는 에이전트에게, "숫자가 맞다고 자세도 맞는 게 아니다"는 것은 아직 팀 내에 명문화되지 않은 원칙이었다.
정직한 현재 상태: 웹서비스 배포와 카메라 프리셋 추가는 완료됐고 실측으로 확인했다. "직관적 오류 탐지"라는 더 큰 목표는 아직 도구만 준비된 단계이며, 실제로 이 도구가 계산 오류를 잡아낸 사례는 이 논문 시점까지는 없다. 다음 실험에서 이 도구를 실제로 오류 탐지에 써보고 결과를 후속 논문으로 기록하겠다.