데모 시연 동영상

발표 동영상

git-hub

 

엣지 AI 기반 자율제조 프레임워크 — 삽질에서 깨달음까지

Industrial Edge AI Solution Challenge 2026 Team Davinci | AMFX: Autonomous Manufacturing Framework with Edge AI

---

1. 처음 만난 PC를 포맷해야 합니다

수작업 절차

어떤 PC든 처음 받으면 하는 일:

1. 전원 버튼을 누른다
2. BIOS에 들어가 부팅 순서를 바꾼다
3. USB 설치 디스크를 꽂는다
4. OS를 설치한다 (언어, 키보드, 파티션, 사용자...)
5. 초기 설정을 한다

사람이 모니터 앞에 앉아서, 수십 번 키보드를 치는 반복 작업. 공장에서 100대, 1000대를 세팅한다면?

로봇과 자동화한다면?

빈 PC 앞에 로봇을 놓고,
전원을 켜고,
BIOS를 설정하고,
OS를 설치한다.

사람 개입 = 0

이걸 하려면 로봇이 해야 할 일: 보고(카메라) → 판단하고(AI) → 움직이고(IK) → 조작한다(HID)

6대 난제를 해결하기 위해 — 직접 공정을 만들었다

난제를 "선택"한 것이 아니다. 직접 공정을 만들어 데이터를 발생시켰더니, 6대 난제가 정말로 자연 발생했고, 하나씩 삽질하면서 해결했다.

로봇이 목표를 찾는다    → 위치가 틀리면?    → ⑤ 공정 제어
로봇이 버튼을 누른다    → 힘이 과하면?     → ② 이상징후
화면을 읽어야 한다     → OCR이 안 되면?   → ③ 품질 검사
BIOS/OS 설치를 판단    → 상황이 바뀌면?   → ① 맞춤형 AI
키보드를 입력해야 한다  → HID가 안 먹으면? → ① 맞춤형 AI
매 동작마다 기록한다    → 데이터는?         → ④ 파이프라인
외부 없이 동작해야     → 보안은?           → ⑥ Edge + 보안

그리고 또 하나의 난제를 식별했다:

★ 이 수작업을 자동화하려면 공정 자체를 새로 정의해야 한다 → ⑦ 공정 창출

스마트 팩토리의 본질: 기존 수작업을 그대로 자동화하는 것이 아니라, 자동화에 맞게 공정 자체를 재설계하는 것. "로봇이 USB를 꽂을 수 없다"는 한계에서 "전자 스위칭으로 물리 삽입 자체를 없앨 수 있지 않을까?"라는 공정 재설계 아이디어가 나왔다 (TS3USB30, 구상 단계). DigiKey가 말하는 Smart Factory 4.0의 핵심도 같다 — 자동화가 공정을 바꾸고, 바뀐 공정이 새로운 데이터를 만든다.

---

2. Phase 1: 물리 만능주의의 실패

"로봇이 전부 물리적으로 해야지" USB를 꽂고, 키보드를 치고, 화면을 읽고...

시도와 현실

시도	결과	원인
USB를 로봇으로 물리 삽입	Visual Servoing 0.07mm 수렴 성공! 근데... 삽입하려니까 밀린다	삽입력 필요, 백래시
카메라로 모니터 화면 촬영	ESP32-CAM → OCR 60%, LLM 매번 호출 → 비용 폭발	반사광 + 워핑

$30 서보 로봇의 한계

항목	현실
필요한 정밀도	±0.5mm
기어 백래시	~2mm
필요한 삽입력	~5N
힘 제어	불가능

사고: 서보 모터 2회 고장 — 장애 대응의 진화

1차 고장: IK 없이 고생

연속 고부하 → 서보 과열 → 배선 피복 녹음 → 기어 변형. 교체 후 캘리브레이션 절차가 없어 수작업으로 각도를 하나씩 맞추느라 수 일 소요.

2차 고장: IK + MCP로 빠른 복구

같은 증상 재발. 하지만 이번에는:

• IK 캘리브레이션 절차가 코드로 정립되어 있었고
• MCP 서버(amfx-ik-control)로 검증 자동화
• 서보혼 방향 역전(direction +1→-1) 발견 → 카메라 3대로 즉시 확인 → 수 시간 복구

모든 과정이 라벨링된 데이터로 저장

서보 교체, 캘리브레이션 시행착오, FK/IK 검증 결과 — 같은 DB row에 센서값+관절각도+TCP 좌표+작업 컨텍스트를 함께 기록. 고장 → 교체 → 복구 과정 자체가 이상징후 탐지 모델의 학습 데이터가 된다.

"고장이 나야 고장을 예방할 수 있다" — 1차는 고생, 2차는 절차화, 다음은 자동화.

IK(역기구학)란 무엇이고, 왜 이렇게 어려운가

**IK(Inverse Kinematics, 역기구학)**란 "로봇 끝(TCP)을 원하는 위치에 갖다 놓으려면 각 관절을 몇 도로 꺾어야 하는가"를 계산하는 것이다.

목표: TCP를 (200, 0, 275)mm에 놓아라
  → base를 몇 도? shoulder를 몇 도? elbow를 몇 도? wrist를 몇 도?
  → 이 역방향 계산이 IK

산업용 로봇은 엔코더(각도 센서)가 내장되어 있어 현재 각도를 정확히 안다. 그리고 제조사가 정밀 캘리브레이션 데이터를 제공한다. 하지만 $30 서보 로봇에는:

산업용 로봇	$30 서보 로봇
엔코더 내장 (0.01° 정밀도)	엔코더 없음 (PWM 신호만)
제조사 캘리브레이션 데이터	데이터시트 없음
링크 길이 정밀 가공	수작업 측정 (버니어 캘리퍼스)
감속기 백래시 < 0.1mm	기어 백래시 ~2mm
서보혼 정밀 결합	서보혼 방향이 교체마다 바뀜

따라서 IK를 동작시키려면 모든 파라미터를 직접 측정하고, 카메라로 검증하고, 시행착오로 맞춰야 한다. 이 과정이 IK 캘리브레이션이다.

IK 캘리브레이션에 필요한 절차

1. 링크 길이 측정 ? 각 관절 축 중심 사이의 물리 거리
2. 서보 홈 위치 측정 ? 각 관절을 알려진 자세(수평/수직)에 놓고 서보 각도 기록
3. 방향(direction) 결정 ? 서보 각도를 올렸을 때 팔이 어느 쪽으로 움직이는지 (+1/-1)
4. FK(순기구학) 수식 검증 ? 서보 각도 → TCP 좌표 계산이 실제와 맞는지 확인
5. IK(역기구학) 검증 ? TCP 좌표 → 서보 각도 계산 후 실제 이동, 오차 측정
6. 반복 ? 오차가 허용 범위 안에 들어올 때까지 파라미터 조정

이 절차를 서보 교체할 때마다 다시 해야 한다. 그래서 1차 고장 때는 수 일이 걸렸고, 2차에는 절차를 코드화+MCP 서버화하여 수 시간으로 단축했다.

---

IK 개발 — 수십 회의 시행착오, AI 분산 협업

$30 서보 로봇에는 엔코더도 없고, 데이터시트도 없다. 모든 것을 직접 측정하고 시행착오로 캘리브레이션했다.

IK 작업은 Claude 에이전트(오케스트레이션)와 Codex 5.3(기구학 전문 연산)에 분산하여 전문성을 강화했다. Codex 5.3에게 3대 카메라(Top View, Side View, Eye-in-Hand)의 실시간 이미지와 ArUco 마커 좌표를 제공하고, 카메라 이미지 기반의 마커 검증 IK 방식을 함께 고안했다.

기하학적 IK Solver 설계

6축이지만 FK/IK는 4축(base, shoulder, elbow, wrist_pitch)으로 풀었다. J5(wrist_roll)는 방향만, J6(gripper)는 개폐만 담당.

물리 각도 = home_physical + (servo_angle - servo_home) × direction

이 한 줄 수식의 4개 파라미터(servo_home, home_physical, direction, link_length)를 찾는 데 4일이 걸렸다.

ArUco 마커 기반 IK 캘리브레이션 방식

엔코더 없이 IK 정확도를 검증하려면 외부 관측이 필수다. OpenCV ArUco (DICT_4X4_50) 마커 시스템을 설계했다:

마커 ID	크기	부착 위치	용도
ID 0	3cm	로봇 TCP (펜 끝)	TCP 실측 위치 추적
ID 1~4	4cm	작업대 고정 (알려진 좌표)	Homography 계산 (pixel→mm 변환)
ID 5	3cm	타겟 (버튼 위치 등)	작업 목표 위치

IK 검증 절차:

1. 고정 마커 4개 감지 → Homography 행렬 계산 (pixel→world mm)
   ID 1: (150, +100)mm  ID 2: (150, -100)mm
   ID 3: (250, 0)mm     ID 4: (100, 0)mm

2. 로봇을 IK 목표 위치로 이동

3. Top View 카메라로 TCP 마커(ID 0) 촬영
   → pixel 좌표 → Homography 변환 → world 좌표 (mm)

4. Side View 카메라로 높이(z) 검증
   → 수직 방향 확인

5. FK 예측 좌표 vs 카메라 관측 좌표 비교
   → 오차 < 0.3mm이면 PASS

6. Eye-in-Hand 카메라로 근접 작업 시 미세 검증

이 방식으로 엔코더 없이도 카메라+마커로 FK/IK를 정량 검증할 수 있었다.

캘리브레이션 과정

단계	방법	시행착오
링크 길이	버니어 캘리퍼스로 직접 측정	3회 재측정 (축 중심점 찾기 어려움)
서보 홈 위치	서보를 물리적으로 수평/수직에 놓고 각도 기록	관절마다 기준이 다름
방향(direction)	서보 +10° → 카메라로 팔이 올라갔는지 내려갔는지 확인	엘보우 direction=-1 (서보↑→팔 앞으로) 발견에만 반나절
home_physical	vertical_90 제약조건 (어깨=90°일 때 팔이 수직)	수식 역산으로 -67.75° 도출

엘보우 서보혼 재장착 — 전체 재캘리브레이션

서보 과열 사고 후 기어 변형 → 서보 교체 → 서보혼 장착 각도가 바뀜 → FK 전체 틀어짐.

교체 전: servo_home = 72.75, direction = +1
교체 후: servo_home = 87.25, direction = -1
변환식: new_servo = 160 - old_servo

direction이 반전된 것을 발견하기까지 2시간. 카메라 top_view + side_view로 서보 각도를 +10° 올려보고, 팔이 어느 쪽으로 움직이는지 반복 확인. Codex 5.3이 카메라 이미지 3장(top, side, eye-in-hand)을 동시 분석하여 direction 역전 현상을 수치적으로 확인했다.

IK 검증 — 5개 포즈 + Round-Trip

포즈	목표 TCP (mm)	실제 오차	결과
Forward High	(200, 0, 275)	0.2mm	PASS
Left High	(150, 100, 275)	0.3mm	PASS
Right High	(150, -100, 275)	0.3mm	PASS (Left와 완벽 대칭)
Center Lower	(180, 0, 200)	0.2mm	PASS
Forward-Left Low	(200, 80, 200)	0.2mm	PASS
Round-Trip Home	시작→5포즈→복귀	0.0mm	PASS (완벽 일치)

검증 시 3대 카메라로 동시 촬영: Top View(XY 평면), Side View(XZ 평면), Eye-in-Hand(근접 확인). 각 포즈에서 ArUco 마커 감지 → Homography 변환으로 FK 예측 vs 실측 비교.

MCP 서버 — Single Source of Truth

포즈와 속도를 여러 곳에서 정의하면 불일치로 충돌 사고가 난다. MCP 서버 코드가 유일한 진실 소스:

• amfx-power-button: 전원 버튼 IK 포즈 + 속도 + 안전 가드
• amfx-ik-control: 일반 IK 이동 + 직선 삽입 + TCP 좌표 가드
• TCP x guard: z < 220mm일 때 x < 150mm 강제 — 로봇 TCP가 Target PC 본체와 충돌하는 것을 방지
• 절대 금지: 직접 curl로 로봇에 명령 → MCP 가드 우회 위험

Codex 5.3이 MCP 도구를 설계하여, 복잡한 IK 시퀀스를 단순한 도구 호출로 추상화했다:

MCP Tool: short_key  →  전원 켜기 (LIFT→APPROACH→PRESS 0.05s→RETRACT→PARK)
MCP Tool: long_key   →  강제 종료 (LIFT→APPROACH→PRESS 5.0s→RETRACT→PARK)
MCP Tool: move_tcp   →  IK 좌표 이동 (안전 가드 포함)

AI 에이전트는 IK 수식이나 서보 각도를 몰라도 short_key 한 번이면 전원 버튼을 누를 수 있다. IK의 복잡성을 MCP 도구 뒤에 숨겨서, 누구든(Claude든, Codex든, 사람이든) 안전하게 로봇을 제어할 수 있게 만들었다.

$30 서보 로봇으로 0.2mm FK/IK 정밀도를 달성한 것은 엔코더가 아니라 카메라 3대 + ArUco 마커 + 시행착오 캘리브레이션의 결과다. IK 전문 작업은 Codex 5.3에 분산하여, Claude(오케스트레이션) + Codex(기구학 연산) 협업 구조로 효율을 높였다.

---

3. 삽질 → 깨달음: 5단계 진화

물리 만능        →   전자 스위칭(구상)  →   센싱 품질     →   에이전트 효율    →   최적 분리
"로봇이 다 해야지"    TS3USB30 $4 제안     HDMI 캡처 $10      ReAct→Plan-Execute    물리: 전원 버튼만
→ 서보가 탔다         → USB 물리 삽입 한계  → OCR 60%→100%     → LLM 호출 30x↓       나머지: 전부 전자적

처음 계획 → 실제 구현 → 다음 아이디어

작업	처음 계획	실제 구현	다음 아이디어
USB	로봇이 물리 삽입	사람이 수동 1회 삽입 (백래시+삽입력 한계)	TS3USB30 전자 스위칭 ($4, 구상)
키보드	로봇이 물리 타이핑	Pico HID ($4) — UART→USB HID 에뮬레이션	구현 완료, 유지
화면 읽기	카메라로 모니터 촬영	ESP32-CAM WiFi 캡처 (OCR→AI 판독)	HDMI 캡처보드 ($10) 디지털 직접 수신
전원	로봇이 본체 버튼 누름	1mm 저압 스위치 + IK 프레스 (MCP short_key)	구현 완료, 유지

깨달음: "무엇을 물리적으로 할 것인가"의 경계를 찾는 것이 제조 라인 설계의 본질

---

4. 실제로 해본 것 — 2가지 물리 작업

사례 1: 전원 버튼 프레스

$30 서보 로봇으로 PC 본체 전원 버튼을 누른다.

문제: 본체 버튼 압력 > 서보 출력 → 누를 수 없음
해결: 1mm 저압 택트 스위치로 교체 → "힘"이 아니라 "정확도"로 전환
결과: MCP short_key 한 번이면 전원 ON (IK 0.2mm 정밀도)

IK 캘리브레이션 → MCP 도구화 → 반복 가능한 자동 전원 제어 완성.

사례 2: BIOS 설정 → Ubuntu 설치 전 과정 자율 수행

전원이 켜진 후, ESP32-CAM으로 모니터 화면을 촬영하고, Claude Agent가 화면을 해석해서 Pico HID로 키보드를 조작한다.

ESP32-CAM (WiFi) → 화면 캡처 (2048×1536)
       ↓
Claude Agent → 화면 상태 분류 + OCR → 다음 키 결정
       ↓
Jetson → HTTP → RPI4 → UART → Pico → USB HID → Target PC
       ↓
BIOS POST → F8 Boot Menu → USB 선택 → GRUB → Ubuntu Installer
→ 언어/키보드/네트워크/파티션/사용자 설정 → 설치 완료 → 재부팅 → 로그인

전 과정을 Claude Agent가 1회 완전 자율 수행에 성공했다.

단계	AI가 한 일
BIOS POST	화면에서 "Press F8" 인식 → F8 키 전송
Boot Menu	USB 드라이브 항목 OCR → 방향키+Enter
Ubuntu Installer	각 화면(언어, 파티션, 사용자 등)마다 판단 → 입력
설치 중	진행률 모니터링 → 10~20분 대기
완료 후	"Restart Now" 인식 → 클릭 → 재부팅 → 로그인

예상 못한 삽질: 보안과 절전

자율 설치 과정에서 OS/하드웨어 레벨의 예상 못한 장벽에 부딪혔다:

문제	증상	해결
Ubuntu 절전	설치 중 10분 무입력 → 화면 꺼짐 → ESP32-CAM 검은 화면 → Agent 판단 불가	설치 전 gsettings 절전 해제, 또는 주기적 키 입력으로 깨우기
Ubuntu 잠금화면	재부팅 후 자동 잠금 → 비밀번호 입력 필요 → Agent가 로그인 화면 인식 필요	화면 상태 분류에 login_screen 추가, 자동 비밀번호 입력
Pico USB 인식	Ubuntu가 Pico를 "새 장치"로 인식 → 팝업 → 설치 흐름 방해	Pico를 키보드+마우스로만 인식시키는 CircuitPython 설정
BIOS 보안 부팅	Secure Boot 활성화 → USB 부팅 거부	BIOS에서 Secure Boot 비활성화 단계 추가
SSD 고장 발견	설치 반복 중 디스크 에러 → 파티션 실패 → 설치 불가	AI가 에러 화면 판독 → SSD 불량 판단 → 물리 SSD 교체 (128GB)

SSD 고장은 의도한 시나리오가 아니었다. 자율 설치를 반복하다가 우연히 디스크 에러를 만났고, Agent가 화면 에러 메시지를 읽어 SSD 불량을 판단했다. 결과적으로 "이상징후 탐지 → 원인 진단 → 부품 교체"라는 실제 제조 현장의 장애 대응 시나리오를 경험하게 되었다.

소프트웨어만 짜면 될 줄 알았는데, OS의 보안/절전 정책이 자율 제어의 숨은 적이었고, SSD 고장까지 만났다.

---

5. 그래서 뭘 만들었나 — 핵심 숫자

지표	수치	설명
0.2mm	FK/IK 정밀도	6축 서보 로봇
0.07mm	Visual Servoing 수렴	ArUco + Homography
88x	Edge vs Cloud 속도	84ms vs 7,435ms
7/7	난제 해결	6대 + 공정 창출

시스템 아키텍처 — 통신 구조

┌──────────────────────────────────────────────────────────────────────┐
│                    Jetson Xavier NX (AI Hub, :8000)                    │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌──────────────┐  │
│  │ Claude     │  │ YOLO v8    │  │ Visual     │  │ Camera       │  │
│  │ Agent      │  │ TensorRT   │  │ Servoing   │  │ Manager      │  │
│  └─────┬──────┘  └────────────┘  └──────┬─────┘  └──┬───┬───┬───┘  │
│        │                                │            │   │   │      │
│        │  HTTP REST                     │ HTTP POST  │   │   │      │
├────────┼────────────────────────────────┼────────────┼───┼───┼──────┤
│        ▼                                ▼            │   │   │      │
│  ┌─────────────────────────────────────────────┐     │   │   │      │
│  │      Raspberry Pi 4 (Control Hub, :5000)      │     │   │   │      │
│  │                                               │     │   │   │      │
│  │  Flask API ←── HTTP REST ──→ Jetson           │     │   │   │      │
│  │     │                                         │     │   │   │      │
│  │     ├── I2C ──→ PCA9685 ──→ MG996R ×6 (로봇) │     │   │   │      │
│  │     ├── I2C ──→ INA219 (전류 센서, addr 0x41) │     │   │   │      │
│  │     └── UART /dev/ttyAMA0 @ 115200            │     │   │   │      │
│  │              │                                │     │   │   │      │
│  │              ▼                                │     │   │   │      │
│  │         Pico (CircuitPython)                  │     │   │   │      │
│  │              │ USB HID                        │     │   │   │      │
│  │              ▼                                │     │   │   │      │
│  │         Target PC (키보드/마우스)               │     │   │   │      │
│  └─────────────────────────────────────────────┘     │   │   │      │
│                                                       │   │   │      │
│  ┌─── USB 카메라 ────────────────────────────────────┘   │   │      │
│  │  Top View (/dev/video3, 640×480)                      │   │      │
│  │  Side View (/dev/video1, 640×480, 180° 회전)  ────────┘   │      │
│  │  Eye-in-Hand (/dev/video5 또는 RPI4 HTTP)  ──────────────┘      │
│  └──────────────────────────────────────────────────────────────┘    │
│                                                                      │
│  ┌─── WiFi ───────────────────────────────────────────────────┐     │
│  │  ESP32-CAM (192.168.0.50) ── HTTP GET /capture/hires       │     │
│  │  → Target PC 모니터 화면 캡처 (2048×1536)                    │     │
│  └────────────────────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────────────────┘

통신 프로토콜 요약

경로	프로토콜	용도
Jetson ↔ RPI4	HTTP REST (Ethernet)	로봇 제어, IK, HID 중계
RPI4 ↔ PCA9685	I2C (addr 0x40)	6축 서보 PWM
RPI4 ↔ INA219	I2C (addr 0x41)	전류 모니터링
RPI4 ↔ Pico	UART 115200 (GPIO14/15→GP0/GP1)	HID 키보드/마우스 명령
Pico → Target PC	USB HID	물리 키보드/마우스 에뮬레이션
Jetson ← ESP32-CAM	HTTP GET (WiFi)	화면 캡처 (2초 간격)
Jetson ← USB 카메라 ×3	USB (V4L2)	Top/Side/Eye-in-Hand 영상

배포 — OTA 없이 실시간 교체

OTA 인프라 대신 RPI4가 직접 제어 허브이므로 scp/ssh로 실시간 서버+코드 교체가 가능하다:

# Backend 코드 → RPI4 실시간 배포
scp -r backend/ rpi4:/home/arm/amfx/
ssh rpi4 "cd /home/arm/amfx && fuser -k 5000/tcp; nohup python run.py --production &"

# AI 코드 → Jetson 실시간 배포
scp -r jetson_ai/ jetson:/home/nvidia/amfx/
ssh jetson "cd /home/nvidia/amfx && fuser -k 8000/tcp; nohup uvicorn main:app --host 0.0.0.0 --port 8000 &"

• PDCA 반복 시 코드 수정 → 즉시 배포 → 즉시 검증 (수 분)
• 레거시: OTA 시스템 구축 + 펌웨어 빌드 + 배포 검증 = 수 일

구성 요약

• 4대 카메라: Top View + Side View + Eye-in-Hand + ESP32-CAM (화면 캡처)
• 2대 컴퓨터: Jetson (AI) + RPI4 (제어)
• 1대 로봇: 6축 MG996R (FK/IK)
• 1대 Pico: USB HID (키보드/마우스 에뮬레이션)

실제 시연 — 물리적으로 무엇을 했나

Claude 에이전트로 전원 버튼→Ubuntu 설치 전 과정을 1회 완전 수행했다.

물리 작업 1: 전원 버튼 프레스 (저압 스위치)

$30 서보 로봇은 데스크탑 PC 본체의 전원 버튼을 누를 만한 압력이 부족했다. 따라서 1mm 저압 택트 스위치로 교체하여, 정밀도 기반의 반복 작업으로 전환했다.

동작 시퀀스:
1. LIFT 포즈 이동 (안전 높이)
2. APPROACH 포즈 이동 (스위치 바로 위)
3. PRESS: shoulder 190→160 (speed=120) ? TCP가 스위치를 누름
4. HOLD: short=0.05s (전원 켜기) / long=5.0s (강제 종료)
5. RETRACT: shoulder 160→190 (복귀)
6. PARK 포즈 + emergency_stop

• 왜 저압 스위치인가: 본체 버튼 압력 > 서보 출력 → 힘 제어 불가 → "힘이 아니라 정확도"로 전환
• IK 정밀도: 0.2mm (기하학적 IK, 엔코더 없이 달성)
• TCP x guard: z < 220mm에서 x < 150mm 강제 — Target PC 본체와의 충돌 방지
• MCP 서버: 포즈/속도의 유일한 진실 소스, 외부 접근 차단

버튼 프레스 = 이상탐지용 정상 데이터 수집

버튼 프레스는 단순 동작이 아니라 이상탐지를 위한 정상 데이터 라벨링 작업이기도 하다. 매 프레스마다 같은 DB row에 기록:

{timestamp, 전류(INA219), 전압, joint_angles[6], TCP_xyz, action:"short_key", result:"success"}

이 데이터가 누적되면 "정상 버튼 프레스"의 전류/전압/관절각도 패턴이 형성되고, 이상값(서보 나사 풀림, 기어 마모, 부하 증가 등)을 탐지하는 기준선이 된다.

실제 사례 (오늘): 서보 모터 고정 나사가 풀어져 좌표가 틀어짐 → 누적된 정상 데이터와 비교하면 관절각도 편차로 즉시 감지 가능 → 나사 재체결 + IK 재조정으로 복구. 이런 장애까지 포함한 데이터가 이상탐지 모델의 학습 데이터가 된다.

작업 = 수집: 별도의 데이터 수집 공정 없이, 반복 작업 자체가 이상탐지 모델의 정상 기준선을 만든다.

물리 작업 2: USB 삽입 (수동) + Ubuntu 자동 설치

USB 물리 삽입은 서보 백래시 ~2mm + 삽입력 부족으로 로봇 자율 수행이 불가능했다. 따라서 USB는 사람이 1회 수동 삽입하고, 이후 전원 버튼→BIOS→Ubuntu 설치 전 과정을 Claude 에이전트가 자율 수행한다.

이 한계 인식이 TS3USB30 전자 스위칭 구상으로 이어졌다 — "물리를 줄이고 전자로 대체"

전원 버튼을 눌러 PC가 켜지면, Claude 에이전트가 ESP32-CAM으로 화면을 캡처하고 Pico HID로 키보드/마우스를 조작하여 Ubuntu 설치 전 과정을 자율 수행한다.

실행 체인:
Jetson (Claude Agent) ←HTTP→ ESP32-CAM (화면 캡처)
        │
        │ HTTP (POST /api/v1/hid/key, /type, /combo)
        ▼
RPI4 (HID relay) ←UART→ Pico ←USB HID→ Target PC

단계	수행 내용	AI 판단
BIOS POST	F8 → Boot Menu 진입	화면 상태 분류 → 키 결정
Boot Menu	USB 드라이브 선택	OCR로 항목 읽기 → 선택
GRUB	"Install Ubuntu" 선택	화면 인식 → Enter
Installer	언어, 키보드, 네트워크, 파티션, 사용자 설정	각 화면별 판단 → 입력
설치 진행	10~20분 대기	진행률 모니터링
완료	"Restart Now" 클릭	완료 화면 인식 → 재시작
First Boot	로그인 → 터미널 오픈 → 초기 설정	데스크탑 인식 → 명령 입력

1회 전체 수행 후, 이 수행 결과가 Edge MLOps의 입력 데이터가 된다.

---

6. 7대 난제 — 어떻게 해결했나

난제를 "선택"한 것이 아니다. 공정을 만들었더니 7개 전부 자연 발생했고, 삽질하면서 해결했다.

난제 매핑: 대회 문제 → 내 문제

#	난제	대회 문제 정의	AMFX에서 만난 문제
①	맞춤형 AI	공정 상태별 다른 판단이 필요한데, 범용 AI로는 느리고 비싸다	화면 상태별 다른 키 입력 필요, Cloud LLM 7초/판단
②	이상징후 탐지	장비 고장을 사전에 감지하여 가동 중단을 막아야 한다	서보 과열 → 기어 변형, 접촉 시 TCP 밀림
③	품질 검사	작업 결과가 정상인지 자동으로 판정해야 한다	버튼 눌림 성공/실패 판정, 화면 전환 확인
④	데이터 파이프라인	공정 데이터를 AI가 학습할 수 있는 형태로 수집해야 한다	전류만 쌓으니 맥락 없어 쓸 수 없었음
⑤	공정 제어	로봇이 정확한 위치에 반복적으로 도달해야 한다	서보 백래시 ~2mm, USB 삽입 불가
⑥	보안 + Edge	폐쇄망 제조 환경에서 인터넷 없이 AI가 동작해야 한다	Cloud 100% 의존 → 인터넷 없으면 멈춤
⑦	공정 창출	수작업이라 공정으로 정의조차 안 된 80%의 제조 영역	물리 삽입 불가 → 공정 자체를 재정의해야 했음

어떻게 해결했나

#	난제	삽질	해결	증거
①	맞춤형 AI	Cloud LLM 매번 호출 → 7초/판단, 비용 폭발	Cloud→Edge 점진 이관, DecisionTree 23규칙	84ms, 88x↑
②	이상징후 탐지	엘보우 서보 과열 → 기어 변형 사고	TorqueGuard: IK 시점에 좌표 기반 부하 사전 추정	Score 75→차단
③	품질 검사	YOLO 학습 데이터 없음, ESP32-CAM OCR 60%	ArUco 위치검증 + HDMI 캡처 OCR + AI 화면 판독	센서 퓨전
④	데이터 파이프라인	전류 데이터만 쌓으니 관절 맥락 없어 쓸 수 없었음	같은 row에 센서+관절각도+TCP 좌표 = 자동 라벨링	작업=수집
⑤	공정 제어	서보 백래시 ~2mm, 그리퍼 떨림, USB 삽입 불가	기하학적 IK 0.2mm + Visual Servoing 폐루프 0.07mm	0.2mm 정밀
⑥	보안 + Edge	클라우드 100% 의존 → 인터넷 없으면 멈춤	Edge 규칙 90% + LLM fallback 10% + 온프레미스 DB	오프라인 OK
⑦	공정 창출	물리 삽입 불가 → 공정 자체를 재정의해야 했음	전자 스위칭(구상) + HDMI 캡처 → 물리→전자 공정 전환 설계	바이브 제조

모든 난제의 공통 패턴: 더 좋은 기술을 쌓아서 해결한 게 아니라, 문제를 다시 정의해서 해결했다.

---

7. Edge MLOps — Cloud가 가르치고, Edge가 실행

왜 Edge가 필요한가?

이 시스템의 강점은 전원 버튼 → BIOS 설정 → OS 설치까지 전 과정을 AI가 자율 수행할 수 있다는 것이다. 하지만 Cloud LLM에 100% 의존하면 인터넷 없이 동작 불가, 호출당 수 초 지연, API 비용 누적 문제가 있다.

전 과정 중 BIOS 부팅 순서 변경(어떤 디스크로 부팅할지 선택)을 Edge MLOps PoC 대상으로 선택했다. 이유:

• BIOS는 네트워크 없는 환경 — Cloud 호출 자체가 불가능한 상황이 실제로 발생
• 화면 상태가 명확히 구분됨 — 규칙 기반 Edge 모델로 대체 가능성이 높음
• 전체 공정의 앞단 — 여기가 Edge로 동작하면 나머지도 같은 패턴으로 확장 가능

시간 제약으로 전체 공정이 아닌 BIOS 부팅 순서 변경을 PoC로 수행했다. Cloud LLM으로 먼저 전 과정을 검증하고, 이 중 한 구간을 Edge로 전환하는 과정을 증명했다.

출발점: Claude Agent로 전 과정 1회 물리 수행

처음부터 Tiny LLM? 성능 부족 → 프레임워크 자체 검증 불가.

그래서 먼저 고성능 Cloud LLM(Claude Opus)으로 전원 버튼→Ubuntu 설치 전 과정을 1회 완전 수행했다. 이 1회 수행 데이터가 Edge 경량 모델의 학습 데이터가 된다.

1회 수행 시 자동 수집되는 메타데이터:
├── 화면 캡처 (ESP32-CAM JPEG)     → 화면 상태 분류 학습용
├── LLM 판단 (action, reasoning)   → 규칙 엔진 추출용
├── 화면 상태 (screen_state)       → DecisionTree 학습용
├── HID 실행 결과 (success/fail)   → 보상 신호
└── Phase 전이 기록                → 상태 머신 설계용

우리의 접근: Cloud LLM으로 먼저 증명 → 수행 결과 메타데이터화 → Edge 모델로 점진 이관

4-Phase 전환

1. Prototype        2. Shadow           3. Edge Primary      4. Edge Only
Cloud LLM 100%  →   Edge 병렬 실행  →   Edge 먼저 시도   →   Cloud 호출 0%
공정 검증             자동 라벨링         LLM은 fallback        84ms, 오프라인

LLM → Edge 대체 결과

LLM이 하던 일	대체 Edge 모델	속도 개선
화면 상태 분류	ScreenClassifier (heuristic)	2,000ms → 5ms
화면 텍스트 읽기	PaddleOCR + TensorRT	2,000ms → 30ms
행동 결정	DecisionTree (23 규칙)	2,000ms → <1ms
센서 이상 감지	EdgeAnomalyDetector	threshold → ML
복잡한 판단/복구	LLM 유지 (10%)	fallback only

= **숙련공(LLM)**이 공정을 만들고 → **자동화 라인(Edge)**이 반복 실행하는 산업 최적화 패턴

보안: 제조 데이터가 외부로 나가지 않는 구조

① 데이터 유출 차단 — Edge 전환

이 시스템의 가장 큰 보안 위협은 Cloud LLM 호출이다. 화면 캡처, 공정 데이터, AI 판단 요청이 외부 서버를 경유한다.

	Cloud LLM 단계	Edge 전환 후
화면 데이터	외부 API 서버로 전송	Jetson 로컬 처리
판단 로직	외부 서버에서 실행	DecisionTree 로컬 실행
네트워크	인터넷 필수	오프라인 동작
데이터 유출	가능성 있음	물리적 불가

Edge 전환 후 Cloud 호출 0% → 모든 데이터가 로컬 장비 안에서 처리된다.

대기업은 이미 Enterprise LLM을 폐쇄망에 배포하여 Cloud 단계에서도 보안을 유지한다. 이 프로젝트의 Cloud→Edge 전환 패턴은 Enterprise LLM 환경에서도 동일하게 적용된다: 폐쇄망 LLM으로 검증 → Edge 모델로 이관 → 최종적으로 LLM 호출 없이 자율 동작.

② 장비 접근 통제 — SSH 키 인증

장비 간 통신은 SSH 키 기반 인증만 허용. 비밀번호 로그인 비활성화.

• RPI4, Jetson, Target PC 모두 id_ed25519 키 인증
• 배포(scp), 원격 제어(ssh), 로그 수집 전부 키 기반
• 실제로 RPI4 비밀번호 분실 → 키 인증만으로 운영 중

③ 물리적 격리 — HID 단방향 통신

Pico HID는 키보드/마우스 출력만 가능하다. Target PC의 데이터를 읽을 수 없다.

Pico → USB HID → Target PC: 키 입력, 마우스 이동 (출력만)
Pico ← Target PC: 전원 공급뿐 (데이터 수신 불가)

제어 시스템이 Target PC의 디스크, 네트워크, 메모리에 접근할 경로 자체가 없다.

---

8. PDCA 7회 — BIOS Boot Priority 자율 변경

Edge 규칙 엔진으로 BIOS 부팅 순서를 자율 변경. 양방향(SSD↔USB) 22 steps, Cloud 호출 0회.

반복 결과

회차	정확도	핵심 변경
1	0%	초기 규칙만
2	57%	bios_popup 상태 추가
3	86%	카운터 기반 규칙
4	100%	스텝 카운터 완성
5	57% ← 회귀!	OCR 추가 → 기존 기능 깨뜨림
6	86%	OCR 허위양성 제거
7	100%	카운터+OCR 안정

5회차 — 회귀의 교훈

"기능 추가(OCR)가 오히려 정확도를 깨뜨렸다" → 더 많은 기술 ≠ 더 좋은 결과 → 기존에 되던 것부터 지키고, 점진적으로 추가

최종 결과

방향	대상	단계 수	Edge 자율	Cloud 호출
SSD→USB	Kingston USB (Ventoy)	22 steps	100%	0회
USB→SSD	SSD (Ubuntu)	22 steps	100%	0회

7회 PDCA를 몇 시간 만에 돌렸다. 레거시 생산기술팀이라면? 수주~수개월.

---

9. Q1 설계 → Q3 실전: 답이 바뀌었다

Q1에서 설계한 답은 논문에서 나온 답이었고, Q3에서 재정의된 답은 로봇이 고장나고 서보가 타면서 나온 답입니다.

질문	Q1 설계 (1월)	Q3 실전 (3월)	패턴
이상을 미리 알 수 있나?	ML 예측 모델	TorqueGuard 좌표 기반 예방	우회
불량 검사를 AI로?	YOLO 비전 검사	센서 퓨전 (전류+비전+LLM)	퓨전
숙련자 경험 표준화?	if-else 규칙	IK 좌표 + 경험 DB + HIL	설계
데이터를 AI가 쓸 수 있게?	InfluxDB 파이프라인	같은 row에 센서+동작 = 라벨링	단순화
보안 보장 AI?	Secure Boot 암호화	클라우드↔로컬 전환 아키텍처	설계

Q1→Q3 변화의 공통 패턴

Q1 (설계)	Q3 (실전)	패턴
복잡한 인프라 (InfluxDB, MQTT, OTA)	단순한 구조 (SQLite, REST, scp)	단순화
단일 기술 의존 (YOLO만, ML만)	다중 접근 퓨전 (전류+비전+LLM)	퓨전
"더 좋은 도구"	"다른 접근"	우회

---

10. 바이브코딩 → 바이브 제조: AI가 PDCA를 수행할 수 있는 환경을 만들다

바이브코딩은 왜 가능한가?

바이브코딩이란 AI에게 의도를 말하면 AI가 코드를 생성하는 것이다. 이것이 가능한 이유는 개발 환경이 이미 AI-ready이기 때문이다:

AI에게 필요한 것	개발 환경에서는	이미 있는가?
눈 (상태 확인)	터미널 출력, 로그, 테스트 결과	O
손 (실행)	파일 읽기/쓰기, 명령어 실행	O
판단 기준	에러 메시지, 컴파일 결과, 테스트 통과	O
반복 구조	코드 수정 → 저장 → 실행 → 확인	O

개발자가 별도로 만들 것이 없다. IDE를 열고 AI에게 말하면 된다.

제조에서는 왜 안 되는가?

제조 환경은 AI-ready가 아니다. AI에게 "이 PC에 Ubuntu 설치해"라고 말해도 AI가 할 수 있는 게 없다:

AI에게 필요한 것	제조 환경에서는	있는가?
눈 (화면 확인)	모니터 앞에 사람이 앉아야 함	X
손 (키보드/마우스)	사람이 직접 입력해야 함	X
힘 (물리 조작)	버튼, USB, 케이블 = 사람 손	X
판단 기준	숙련자 경험, 매뉴얼	X
반복 구조	없음 (수작업이니까)	X

바이브 제조 = 이 X를 O로 바꾸는 것

이 프로젝트가 한 일의 본질: AI가 제조 PDCA를 수행할 수 있는 제어권과 환경을 만든 것.

AI에게 필요한 것	AMFX가 만든 것	구현
눈	ESP32-CAM + 카메라 3대	화면 캡처 → OCR/LLM 분석
손	Pico HID (키보드/마우스)	UART 명령 → USB HID 에뮬레이션
힘	6축 로봇 + IK + MCP	버튼 프레스, 물리 조작
판단 기준	Claude Agent + 화면 분류	화면 상태 → 다음 액션 결정
반복 구조	PDCA 자동화 루프	실행 → 확인 → 수정 → 재실행
감각	INA219 전류 + 관절 각도	이상탐지 정상 데이터 수집

바이브코딩:  개발자 → "로그인 폼 만들어줘" → AI가 코드 PDCA
바이브 제조: 엔지니어 → "이 PC에 Ubuntu 설치해줘" → AI가 공정 PDCA

차이: 바이브코딩은 환경이 이미 있고, 바이브 제조는 환경 자체를 만들어야 했다. 그 환경을 만든 것이 이 프로젝트다.

환경이 있으면 PDCA가 빨라진다

환경이 갖춰지면, AI가 사람 대신 PDCA를 수행한다:

생산기술 역할	레거시 (사람)	AMFX (AI)
공정 설계	엔지니어 경험 + CAD, 수 주	제약조건 분석 → 플랜 생성, 수 분
비전 셋업	카메라+렌즈+조명+티칭, 수 일	ESP32-CAM + LLM 분석, 수 분
동작 티칭	티칭펜던트 수동 교시, 수 일	IK 좌표 API + 카메라 검증, 수 분
불량 분석	숙련자 경험, 수 시간	AI 즉시 분석+추론, 수 초
24/7 가동	3조2교대, 인건비	무인 연속, $0

PDCA 1사이클이 수 주인 이유: "사람이 생각하고, 물리를 바꾸고, 사람이 확인"하기 때문. 환경을 만들면 AI가 생각+실행+확인을 대체 → 사이클이 수 분으로 줄어든다.

실제로 그랬다: PC 설치는 "딸깍"이었다

처음부터 딸깍은 아니었다. Ubuntu 설치 자동화는 삽질의 연속이었다:

• ESP32-CAM 화면 캡처 → 반사광, 왜곡, OCR 60% → 모니터 교체로 해결
• 절전 모드로 화면 꺼짐 → Agent 판단 불가 → 왜 멈췄는지도 모름
• Pico HID를 Ubuntu가 "새 장치"로 인식 → 팝업이 설치 흐름 방해
• BIOS Secure Boot → USB 부팅 거부 → 원인 파악에 시간 소모
• SSD 고장 → 설치 반복 중 우연히 발견

하지만 방향이 잡히자 딸깍이었다. 화면 캡처→판단→HID 입력→결과 확인이라는 PDCA 루프가 연결되니, 에이전트가 스스로 거의 모든 것을 해냈다. 마치 UI 기반 개발처럼 — 프레임워크가 잡히면 나머지는 흘러간다.

에이전트: BIOS 진입 → 부팅 순서 변경 → USB 선택 → Ubuntu 설치 → 로그인 → 초기 설정
사람:     (지켜봄)    (확인)           (지켜봄)     (지켜봄)        (확인)    (완료 확인)

사람의 역할은 실행이 아니라 중간 검증으로 바뀌었다. 이것이 바이브 제조의 핵심 — 어려운 건 모델이 아니라 환경을 만드는 것이다.

---

11. 실제 경험한 PDCA 가속 — 4가지 사례

사례 1: 버튼 프레스 캘리브레이션

• 레거시: 지그 설계→가공→장착→테스트→수정→재가공 = 수일~수주
• AMFX: IK 좌표 수정→API 호출→카메라 확인→재조정 = 수 분
• 하루에 50+ iteration, Z=250mm 최적점을 당일 발견

사례 2: USB 삽입 공정 재정의

• 레거시: 정밀 지그+가이드레일+공압 실린더 설계/제작 = 수 주
• AMFX: 서보잉 실패→AI와 대안 탐색→TS3USB30 전자 스위칭 구상 = 수 분
• "공정이 필요한가?" 자체를 AI와 재검토 → 공정을 전자적으로 재정의 (설계 완료, 부품 미구현)

사례 3: 화면 판독 비전 셋업

• 레거시: 비전 카메라+렌즈+조명+마운트+티칭+검증 = 수일~수주
• AMFX: ESP32-CAM 실패→HDMI 캡처 발견 = 수 분
• $10으로 "비전 셋업"이라는 공정 자체가 소멸

사례 4: 서보 열 손상 → 캘리브레이션 복구

• 레거시: 서보 교체→기구부 재조립→전체 재티칭→검증 = 수 일
• AMFX: 서보혼 재장착→AI와 방향/오프셋 재계산→자동 검증 = 수 시간
• direction=-1, hp=-67.75 도출. FK/IK 전체 검증까지 AI와 함께

공통점: 실패할수록 빨라진다 — 실패가 즉시 다음 PDCA의 입력이 됨

---

12. 경험 DB — 숙련공의 노하우를 데이터로

[사이클 1] PC 설치 → 실패 (BIOS 키 틀림)
  → 경험 DB: {board: "ASUS H81M-C", key: "F1"}

[사이클 2] 같은 보드 → DB 참조 → 즉시 성공
  → 경험 DB: {time: 25min, errors: 0}

[사이클 50] 새 보드 (Gigabyte) → 키 모름
  → AI 시행착오 → Del 키 발견
  → 경험 DB: {board: "Gigabyte B760", key: "Del"}

[사이클 100+] 대부분 플레이북만으로 완료
  → AI는 미지의 상황에서만 호출
  → 비용이 자연 수렴

레거시 vs AMFX 비교

	레거시	AMFX
노하우 저장	숙련공 머릿속	경험 DB
전수 방법	도제식 (년)	DB 복사 (초)
퇴직 시	노하우 소실	DB 영구 보존
새 공정	0부터 시작	유사 경험 재활용
다른 현장	파견 (월)	배포 (시간)

솔직한 비판: 이상탐지 모델 자체는 쉽다

요즘 AI 이상탐지는 데이터만 있으면 딸깍이다:

• AutoEncoder 계열로 정상 패턴 학습 → 이상 재구성 에러
• 시계열 모델 (LSTM, Transformer) → 패턴 이탈 탐지
• 전통 ML (Isolation Forest, One-Class SVM) → 충분히 잘 됨
• MLOps 파이프라인으로 데이터 갱신 → 모델 드리프트 대응

모델 선택은 어렵지 않다. 진짜 어려운 건:

1. 데이터를 어디서 구하나? — 공장에 센서 달고 수 개월 수집? 고장 데이터는 사고가 나야 생긴다
2. 어떤 데이터를 쌓아야 하나? — 전류만? 진동만? → 맥락 없으면 쓸 수 없다
3. 실제 이상을 만나봤나? — 논문의 벤치마크 데이터셋과 현장 데이터는 다르다

이 프로젝트의 접근: 공정을 직접 만들어서 데이터를 발생시켰다.

• 버튼 프레스 반복 → 정상 데이터 자동 누적
• 서보 나사 풀림, 기어 변형, 배선 용해 → 진짜 이상 데이터를 실제로 만났다
• 같은 row에 {전류, 전압, 관절각도[6], TCP좌표, 동작, 결과} → 맥락 있는 라벨링

데이터 파이프라인의 진짜 핵심: 같은 row에 센서+동작+결과를 넣는 것. 모델은 나중에 골라도 된다. 라벨링된 실제 데이터를 가진 것이 경쟁력이다.

반면, 에이전트 기반 PC 설치는 수 개월 데이터를 모을 필요가 없었다. PDCA 환경(눈+손+판단+반복)이 연결되는 순간 에이전트가 바로 작업을 시작했고, 사람은 중간 검증만 했다.

이상탐지: 데이터가 있어야 딸깍 → 데이터를 만드는 게 진짜 일 에이전트 작업: 환경이 있으면 딸깍 → 환경을 만드는 게 진짜 일 이 프로젝트는 둘 다 했다.

---

13. 솔직한 한계 — 이것도 인사이트

한계를 숨기지 않는 것이 경쟁력. 이 한계가 다음 로드맵을 만든다.

$30 서보 로봇으로 못 하는 것

작업	결과	원인	대응
USB 물리 삽입	불가능	백래시 ~2mm, 삽입력 부족	수동 1회 삽입 + TS3USB30 구상
PC 본체 전원 버튼	압력 부족	서보 출력 < 버튼 압력	1mm 저압 택트 스위치로 교체
반복정밀도	~3mm	기어 유격	IK 0.2mm + Visual Servoing 보정
힘 제어	불가	위치 제어만	"힘→정확도" 전환, 저압 부품 사용

이것을 인정하고, 전자 스위칭을 구상(TS3USB30, $4)한 것이 "더 비싼 로봇을 사자"가 아니라 **"공정을 재정의하자"**로 이어졌다.

한계 → 로드맵

현재 한계	개선 방향
기어 백래시	벨트/다이렉트 드라이브
구조 강성 부족	알루미늄 프레임+베어링
위치 제어만	토크/힘 제어 추가
힘 피드백 없음	FSR/로드셀 at TCP

SW 프레임워크(IK, Servoing, Agent)는 유효. HW가 바뀌어도 API 인터페이스로 분리 → 로봇 교체 시 SW 재사용 100%

---

14. 자율주행처럼, 자율제조에도 레벨이 있다

Level	자율주행	자율제조	AMFX 현재
L0	수동 운전	수동 조립	사람이 USB 꽂고 키보드 침
L1	크루즈 컨트롤	단일 자동화	로봇이 버튼만 누름
L2	부분 자율	로봇+AI, 사람 감시(HIL)	O 달성
L2→L3		일부 구간 완전 자율 달성	← 현재 AMFX
L3	조건부 자율	Plan-Execute, 예외 시만 사람	← 다음 목표
L4	고도 자율	WoL+HID+캡처 무인 N대	← 비전
L5	완전 자율	새 HW/OS도 자가 대응	← 미래

이미 L3에 진입하고 있는 근거:

구간	자율 수준	사람 개입
BIOS 부팅 순서 변경	Edge 100% 자율 (22 steps, Cloud 0회)	없음
전원 버튼 프레스	MCP 자율 (IK + 가드)	없음
Ubuntu 전체 설치	Cloud LLM 자율 (BIOS→설치→로그인)	없음
USB 물리 삽입	수동	사람이 꽂음 (물리 한계)
SSD 고장 교체	AI가 진단, 교체는 수동	예외 상황

사람이 개입하는 건 물리적 한계(USB 삽입)와 진짜 예외(하드웨어 고장)뿐이다. 이것이 L3의 정의 — "Plan-Execute, 예외 시만 사람" — 에 해당한다.

자율주행이 L2에서 L5로 가는 데 10년 걸렸다. 자율제조는 AI PDCA 가속 덕분에 훨씬 빠르게 진화할 수 있다 — 실제로 이 프로젝트에서 수 주 만에 L2→L3 진입을 경험했다.

---

15. $75 셀 — 프로토 공정 프레임워크

┌──────────────────────────────────────┐
│       Proto Process Framework          │
│                                        │
│  ┌────────┐ ┌────────┐ ┌────────┐    │
│  │ Cell 1 │ │ Cell 2 │ │ Cell 3 │ ...│
│  │ ESP32  │ │ ESP32  │ │ ESP32  │    │
│  │ Robot  │ │ Robot  │ │ Robot  │    │
│  │ HID    │ │ HID    │ │ HID    │    │
│  └───┬────┘ └───┬────┘ └───┬────┘    │
│      └──────────┼──────────┘          │
│            Edge AI Hub                 │
│          오케스트레이터                 │
│          + Claude API                  │
│          + 경험 DB                     │
└──────────────────────────────────────┘

셀 1대 원가: ESP32-CAM $5 + 로봇 $30 + Pico $4 + 전자 스위칭 $4 (구상) + HDMI 캡처 $10 = ~$75/셀 (목표)

적용 가능한 시나리오

분야	작업
IT 인프라	PC N대 OS 설치
교육	실험 장비 셋업 반복
품질 검사	외관/기능 검사
연구실	시약 투입/측정 반복
수공업	조립/포장 반복

산업용 로봇은 비싸고, 대기업만의 것이었다. $75 셀 + AI = "누구나 생산기술 엔지니어"

---

16. 성능 비교 요약

Edge vs Cloud

지표	Cloud LLM (Claude)	Edge 규칙 엔진	배율
추론 시간	7,435ms	84ms	88x
정확도	100% (기준)	100%	동일
네트워크	필수 (인터넷)	불필요 (오프라인)	-
비용/호출	~$0.01	$0	∞

PDCA 가속

지표	레거시 생산기술	AMFX (AI+전자제어)	배율
1 PDCA 사이클	6~18주	수 분	~1000x
측정 → 분석	사람 집계 (시간~일)	HDMI+OCR+AI 즉시 (초)	~100x
변경 반영	물리 재가공 (일~주)	GPIO/코드 수정 (초~분)	~1000x
야간/주말	작업자 부재 → 중단	무인 연속 가동	∞
재현성	작업자별 편차	동일 코드 = 동일 결과	100%

---

17. 우리가 배운 것

1. 공정을 만들면 난제는 자연 발생한다 — 선택이 아니라 발견

2. 한계에 부딪히면 AI가 "다른 길"을 제안한다 — 그게 더 싸고 빠르다

3. 실패할수록 빨라진다 — 실패가 즉시 다음 PDCA의 입력

4. 기술을 쌓는 것보다 문제를 재정의하는 것이 답이었다

---

핵심 한 줄

"수작업을 공정으로, 공정을 자율 생산라인으로"

---

Team Davinci — Industrial Edge AI Solution Challenge 2026 AMFX: Autonomous Manufacturing Framework with Edge AI