2026년 3월 11일

WIM × 팔란티어: "공장의 두뇌"를 설계하다

팔란티어의 Foundry-Apollo-AIP 아키텍처에서 영감을 받아, WIM Robot AI Box를 "산업용 로봇 AI 운영 체제"로 재포지셔닝하는 과정을 기록한다.

이전 글에서 팔란티어의 제품 구조를 해부했다. Ontology라는 공유 레이어 위에 Foundry(데이터 통합), Apollo(배포), AIP(AI 연결)가 올라가는 구조. 그걸 쓰면서 계속 한 가지 생각이 떠나지 않았다.

“이 구조, WIM이랑 똑같잖아.”

팔란티어가 기업의 파편화된 데이터를 통합한다면, WIM은 공장의 파편화된 로봇을 통합한다. 팔란티어가 데이터 위에 AI를 얹어 실제 액션을 만든다면, WIM은 로봇 위에 AI를 얹어 실제 모션을 만든다. 우연의 일치가 아니다. 문제 구조가 동형이다.

그래서 진지하게 브레인스토밍을 했다. 팔란티어의 아키텍처에서 WIM이 배울 수 있는 것, 그리고 이것이 제품 포지셔닝을 어떻게 바꾸는지.

구조적 동형: 왜 닮았는가

Palantir	WIM	공통 본질
기업 내 분산된 데이터 소스	공장 내 분산된 로봇 브랜드/프로토콜	파편화된 시스템의 통합
Ontology (의미론적 데이터 모델)	WIM SDK (로봇 제어 추상화)	현실 세계의 소프트웨어 표현
FDE (Forward Deployed Engineer)	WIM 현장 엔지니어	제품을 들고 현장에 들어감
AIP Bootcamp (5일 가치 증명)	WIM 1주일 도입	보여주는 세일즈
Apollo (어디서든 배포)	검정 박스 Appliance + OTA	엣지 환경 배포
AIP (LLM + Ontology = 액션)	Claude Code + SDK = 로봇 제어	AI가 현실에 개입
데이터 플라이휠	파라미터 플라이휠	시간이 갈수록 강해지는 해자

두 회사 모두 “파편화된 현실 세계 시스템 위에 소프트웨어 추상화 계층을 얹고, 그 위에 AI를 연결해서 실제 액션을 만들어내는” 같은 구조다.

영감 1: Physical Ontology (← Foundry)

팔란티어의 가장 강력한 개념은 Ontology다. 기업의 모든 데이터를 “사람, 이벤트, 자산, 관계”라는 의미론적 모델로 표현하는 것. (상세 분석)

WIM의 SDK는 지금 함수 라이브러리다. 이것을 Physical Ontology로 진화시키면 어떨까.

[현재] SDK API 함수 호출
  move_joint(joint_id=1, angle=30)
  set_welding_params(current=200, voltage=25)

[Physical Ontology]
  Robot("야스카와 GP25")
    → has Tool("아크 용접 토치")
    → working on Workpiece("SUS304 T-Joint, 두께 3mm")
    → executing Process("V-groove 아크 용접")
        → with Parameters(소재=SUS304, 이음=V-groove → 최적값 자동 매핑)

LLM이 raw API 대신 의미론적 객체를 다루게 되면:

코드 생성 정확도가 올라간다
소재-이음 조합에서 최적 파라미터가 자동 매핑된다
데이터 플라이휠이 구조화된다: “어떤 소재 × 어떤 이음 × 어떤 도구 조합의 최적값”

팔란티어가 “데이터를 통합”하는 게 아니라 “현실 세계의 의미론적 모델을 만든다”인 것처럼, WIM도 “로봇을 제어”하는 게 아니라 **“공장 현장의 물리적 온톨로지를 만든다”**로 생각할 수 있다.

영감 2: WIM Ops Dashboard (← Gotham)

팔란티어 Gotham은 전장의 모든 정보를 하나의 화면에서 보여주는 상황인식(Situational Awareness) 시스템이다.

WIM에 적용하면: 공장 바닥의 Gotham.

지금 Robot AI Box는 Claude Code 터미널에서 제어하고 끝이다. 공장장은 로봇 상태를 한눈에 볼 수 없다. 그런데 타겟 고객(공장장, 생산기술팀)이 매일 쓰는 것은 “로봇 프로그래밍”이 아니라 **“생산 모니터링”**이다.

대시보드가 있으면:

제품 판매 시 데모 효과 극대화 (대시보드 하나 보여주면 가치가 즉시 체감)
구독 매출의 근거 (“대시보드 + 분석 + 알림”은 월정액에 자연스러움)
멀티로봇, 멀티공장 확장할 때 필수 인프라

이건 “있으면 좋은 것”이 아니라, “플랫폼”이라고 말하려면 반드시 있어야 하는 것이다. CLI만 있는 건 “도구”이지 “플랫폼”이 아니다.

영감 3: WIM Fleet Management (← Apollo)

Apollo의 핵심은 소프트웨어를 클라우드, 온프레미스, 에어갭 환경 어디서든 배포하고 관리하는 것이다. Hub-Spoke 모델에서 Spoke가 Hub에서 업데이트를 “pull”하는 방식.

WIM의 검정 박스(Appliance) 모델에 직접 적용된다:

[WIM Cloud Hub]
    ├── SDK 버전 관리
    ├── Safety Layer 정책 배포
    ├── 파라미터 라이브러리 동기화
    └── 텔레메트리 수집
         │
    Pull 모델
         │
    ├── [공장 A - Hub]
    │     ├── Box 1 → Yaskawa GP25 (용접)
    │     ├── Box 2 → Doosan M1013 (그라인딩)
    │     └── Box 3 → FANUC CRX (픽앤플레이스)
    │
    └── [공장 B - Hub]
          └── Box 4 → ABB IRB 6700 (폴리싱)

Apollo에서 배울 것:

Pull 모델: Box가 Hub에서 업데이트를 가져옴 → 공장 방화벽/보안 정책 친화적
롤백: 모든 SDK 업데이트 즉시 복원 가능 (제조업 필수)
Air-gap 지원: 인터넷 없는 공장도 로컬 업데이트
암호학적 서명: SDK/Safety Layer 변조 방지 (안전 인증에 유리)

지금 당장은 아니지만, Box 10대 이상 팔리는 시점부터 필수다. 아키텍처만 미리 설계해두면 된다.

영감 4: Task Agent (← AIP Agent Studio)

AIP의 최신 진화는 Agent Studio(에이전트 생성/관리)와 Evals(AI 성능 평가)다.

현재 WIM: Claude Code에서 매번 자연어로 명령.

진화: 반복 작업을 Agent로 저장하고 자동 실행.

[WIM Task Studio]
├── "야간 용접 루틴" Agent
│     → 매일 22:00 시작
│     → 경로 A → B → C 순서
│     → 완료 후 Quality Eval 자동 실행
│     → 불량 감지 시 알림 + 정지
│
├── "신규 워크피스 셋업" Agent
│     → 3D CAD 입력 → 경로 자동 생성
│     → 드라이런 → 승인 후 실행
│
└── "멀티로봇 협업" Agent
      → Robot 1: 용접 → Robot 2: 그라인딩 (자동 핸드오프)

그리고 AIP Evals처럼 Quality Evals:

[WIM Quality Evals]
├── 용접: 비드폭 편차, 언더컷, 전류 안정성 → A등급
├── 그라인딩: 표면 거칠기 Ra, 힘 추종 오차 → A-등급
├── P&P: 비전 정확도, 위치 오차 → A+등급
└── Safety: 위험 차단율 100%, 오탐률 0.3%

이 평가 데이터가 쌓이면 → “WIM을 쓰면 용접 불량률이 X% 감소합니다” 같은 정량적 영업 근거가 된다.

영감 5: WIM Bootcamp (← AIP Bootcamp)

팔란티어의 AIP Bootcamp는 전통적 세일즈 사이클(데모 → 제안서 → 검토 → PoC → 파일럿 → 계약, 6~12개월)을 뒤집었다. 고객이 5일 만에 직접 프로덕션급 유스케이스를 만들고, 보고 나서 계약한다. 이 방식이 Q3 2025 미국 상업 TCV $13.1억(+342% YoY)을 만들었다.

WIM은 이미 “1주일 도입” 모델을 가지고 있다. 이것을 WIM Bootcamp로 공식화하면:

Day	내용
1	Robot AI Box 연결, 로봇-센서 셋업
2	고객의 실제 공정(용접/그라인딩) 첫 실행
3	파라미터 튜닝, 품질 최적화
4	현장 담당자 교육, 자립 운영 시작
5	결과 리포트 + 추가 확장 논의

핵심: 만들어주는 게 아니라 같이 만든다. 고객 담당자가 직접 자연어로 로봇을 제어하는 경험을 하면 → 계약 저항이 소멸한다.

이름을 붙이는 것 자체가 마케팅이다. “현장 투입”은 비용 항목이지만, “WIM Bootcamp”는 브랜드 자산이다.

포지셔닝 전환

이 모든 영감을 합치면, WIM의 포지셔닝이 바뀐다.

	현재	새 포지셔닝
정체성	로봇 제어 박스 (HW 제품)	공장 로봇 운영 플랫폼
메시지	”어떤 로봇이든, 말하면 움직인다"	"어떤 로봇이든, 어떤 공정이든, AI로 통합 운영”
고객이 사는 것	박스 1대	공장 로봇 오퍼레이션의 지능화
가치 단위	로봇 1대당 제어	공장 전체의 생산성·품질·효율
경쟁 프레임	vs 로봇 프로그래밍 도구	vs 공장 자동화의 파편화 자체

원라이너: “The AI Operating System for Industrial Robots”

박스는 여전히 판다. 하지만 박스는 플랫폼이 공장에 들어가는 물리적 진입점이지, 제품 자체가 아니다. 팔란티어가 서버를 납품하는 회사가 아닌 것처럼.

제품 진화 로드맵

Phase 1 (현재)     Phase 2 (6-12mo)    Phase 3 (12-24mo)    Phase 4 (24mo+)
─────────────────────────────────────────────────────────────────────
WIM Core           + WIM Ops           + WIM Fleet          + WIM AI Platform
(= Foundry 초기)   (= Gotham)          (= Apollo)           (= AIP)

SDK + Safety       + 대시보드           + 멀티Box 관리       + Task Agent
Protocol Drivers   + 실시간 모니터링    + OTA 업데이트       + Quality Evals
Claude Code 연동   + 알림/알럿          + 버전 관리/롤백     + Physical Ontology
단일 로봇          + 생산 KPI          + Air-gap 지원       + 크로스팩토리

대상별 메시지

대상	현재	새 포지셔닝
공장장	”로봇을 말로 제어하세요"	"공장의 모든 로봇을 한 화면에서 운영하세요”
SI 업체	”어떤 로봇이든 하나의 인터페이스"	"고객 공장에 AI 로봇 운영 체제를 구축하세요”
로봇 OEM	”당신의 로봇에 AI를 추가하세요"	"당신의 로봇을 AI 플랫폼 생태계에 연결하세요”
투자자	”로봇 AI HW 제품"	"팔란티어가 데이터에 한 것을, 로봇에 하는 회사”

마지막 줄이 중요하다. 파편화된 시스템 통합 → 소프트웨어 추상화 → AI 연결 → 플랫폼 이펙트. 구조가 동일하니까 투자자가 즉시 이해한다.

냉정한 체크

여기서 한 가지. 지금 WIM은 야스카와 1개 브랜드, 1개 현장 수준이다. “공장의 모든 로봇을 통합 운영하는 플랫폼”은 비전이지 현재 상태가 아니다.

팔란티어도 초기에 이 문제를 겪었다. 과대 포장으로 비판받았고, 실제로 되는 게 뭐냐는 질문에 시달렸다. 넘긴 방법:

비전은 크게, 증명은 구체적으로 — “비전은 X이고, 지금 Y 현장에서 Z를 증명했다”
Bootcamp로 직접 보여주기 — 말이 아니라 5일 안에 결과를 보여줌
한 고객에서 깊이 파고 확장 — 넓게 가지 않고, 한 고객에서 완벽한 레퍼런스를 만든 후 확장

WIM에 적용하면:

외부: “The AI Operating System for Industrial Robots”

내부: “야스카와 용접 현장에서 완벽하게 작동하는 것을 먼저 증명한다. 그게 되면 두산, FANUC으로 확장한다. 그게 되면 ‘플랫폼’이 말이 아니라 현실이 된다.”

비전과 현실 사이의 간극을 인정하면서, 비전을 향해 매 분기 구체적 증거를 쌓는 것이 핵심이다.

다음 할 것

이 브레인스토밍의 결과물:

팔란티어 제품별 WIM 대응 분석
포지셔닝 전환: “박스” → “플랫폼”
제품 로드맵 설계 (Phase 1-4)
플랫폼 데모 프로토타입 제작
사업 계획서에 플랫폼 비전 반영
WIM Ops 대시보드 MVP 설계
투자자 피칭 내러티브 구조화

관련 글:

← All posts