투모Physical AI Forward Deployed Engineer
5.0 (1)투모로로보틱스
경력근거: 휴머노이드 기반 로봇 시스템의 고객사 현장 배포 및 운영 안정화
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
투모로로보틱스 FDE 는 휴머노이드 로봇을 고객사 현장에 배포·운영 안정화하고, 운영 이슈를 분석해 동작·통신·시스템을 개선하며 원격 모니터링·로그·장애 분석 체계로 현장 노하우를 내재화합니다. 운영 로그를 규칙으로 분류해 정상·점검·중단을 가르고 반복 장애를 묶는 이 게이트는 그 핵심(현장 배포 안정화·장애 분석·노하우 자산화) 기술을 정면으로 보여줍니다. 휴머노이드 제어·로봇 파운데이션 모델 깊이는 포트폴리오로 증명되지 않으므로 주장하지 않고 면접에서 솔직히 다룹니다. 운영 신호를 분류 규칙·장애 묶음으로 잇는 사슬은 단순 로그 대시보드 맥락으로는 그대로 만들 수 없습니다.
휴머노이드 로봇 시스템을 고객사 현장에 배포하고 운영을 안정화합니다. 운영 모니터링 게이트가 직접 정렬됩니다.
원격 모니터링·로그 수집·장애 분석 체계를 다룹니다. 장애 패턴 묶음 알림이 환경과 정렬됩니다.
현장 결과물·엔지니어링 노하우를 내부 솔루션으로 내재화하고 제품 개선으로 잇습니다. 장애 추이 집계가 자산화와 정렬됩니다.
현장 로봇 운영 로그(동작 성공·통신 상태·센서 이상 점수)를 받아, 규칙(동작 실패·통신 끊김·센서 이상·결측)으로 정상·점검·중단을 정하고 반복 장애를 묶어 알립니다. 정답 여부는 운영 임계 규칙으로 결정하고, LLM 은 장애 사유 설명·태깅 보조만 맡습니다. 로봇 제어 자체의 옳고 그름이 아니라 현장 운영 가능 여부의 객관 게이트입니다.
투모로로보틱스 FDE. 현장 로봇 로그를 보며 계속 돌릴지 점검할지 멈출지 매번 판단하고 반복 장애를 손으로 찾던 일을, 한 게이트에서 로그·판정·장애 묶음을 함께 보고 싶은 사람입니다.
운영 로그를 한 스키마로 묶으면, (a) 동작 실패·통신 끊김·센서 이상을 규칙으로 잡아 중단을 정하고, (b) 판정 근거를 로그 인용으로 풀며, (c) 여러 로봇·현장의 로그를 끊김 없이 분류하고 반복 장애를 묶어 알립니다.
운영 로그를 받아 규칙으로 정상·점검·중단을 정하고 반복 장애를 묶어 알리는 동작하는 게이트입니다. 로그는 현장 운영을 가정한 더미로 시작합니다(실 로봇·ROS 연동은 2·3주차).
분류 판정을 심은 정답·검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
로봇·현장별 장애율과 중단 사유 분포를 누적 집계해 약한 로봇·현장을 보여주는 화면입니다.
분류 시나리오 12종(정상·동작 실패·통신 끊김)을 넣으면, 정상·점검·중단 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(센서 점수 null·미등록 로봇·로봇 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 40건 중 정상/중단 판정이 일치한 게 36건(약 90%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 투모로로보틱스의 실 로봇 로그와 실 검토자가 있어야 측정 가능합니다. 이 게이트는 그 연동을 바로 붙일 수 있는 상태까지 만듭니다
이건 실 로봇·실데이터 없이 혼자 만든 포트폴리오입니다. 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실연동 준비 상태로 솔직히 설명합니다
이 포트폴리오는 운영 로그 분류 규칙 + 장애 패턴 묶음 + 중단 가드 기술을 보여줍니다. 휴머노이드 로봇 제어·로봇 파운데이션 모델·ROS 실제 제어 노하우는 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 센서 점수 결측·미등록 로봇·로봇 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 분류만 통과시키는 게 아님을 보여줍니다
중단은 단일 신호로 단정하기 어렵습니다. 이 게이트는 동작·통신·센서 이상을 함께 보고 임계를 넘을 때만 중단을 정하며, 애매하면 중단 대신 점검으로 돌립니다
로봇·현장 표기가 제각각입니다. 정규화로 같은 로봇으로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 운영 임계·신호가 더미와 다르므로 규칙을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
현장 로봇 운영 분류 로그. 분류 규칙이 가장 먼저 질의하는 테이블입니다. 센서 점수 결측·미등록 로봇·로봇 표기 흔들림을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| event_id | robot_raw | robot_id | action_ok | comm_ok | anomaly_flag | sensor_score | label | ts |
|---|---|---|---|---|---|---|---|---|
| ro_001 | 휴머노이드1 | hm1 | true | true | false | 0.95 | normal | 2026-03-04T09:00 |
| ro_002 | 휴머노이드1 | hm1 | false | true | true | 0.5 | halt | 2026-03-04T10:00 |
| ro_003 | 이송로봇A | agv_a | true | false | false | 0.8 | halt | 2026-03-04T11:00 |
| ro_004 | 이송 로봇A | agv_a | true | true | true | 0.6 | inspect | 2026-03-04T12:00 |
| ro_005 | 신규로봇X | — | true | true | false | 0.88 | inspect | 2026-03-04T13:00 |
아래 Zod 스키마에 맞는 로봇 운영 60행 JSON 배열로 생성합니다. 로봇 2~3대, 정상 위주에 점검·중단을 섞습니다. label 규칙: action_ok=false 또는 comm_ok=false → halt, anomaly_flag=true(동작·통신 정상) 또는 robot_id=null 또는 sensor_score=null → inspect, 그 외(동작·통신·이상 없음 & 고센서) → normal.
{"type":"object","properties":{"event_id":{"type":"string"},"robot_raw":{"type":"string"},"robot_id":{"type":["string","null"]},"action_ok":{"type":"boolean"},"comm_ok":{"type":"boolean"},"anomaly_flag":{"type":"boolean"},"sensor_score":{"type":["number","null"]},"label":{"type":"string","enum":["normal","inspect","halt"]},"ts":{"type":"string"}},"required":["event_id","robot_raw","robot_id","action_ok","comm_ok","anomaly_flag","sensor_score","label","ts"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 분류만 통과시키는 함정 회피): (1) 같은 로봇의 표기 별칭('휴머노이드1'/'휴머노이드 1', '이송로봇A'/'이송 로봇A'처럼 robot_master 로 정규화돼야 함) 3건 이상, (2) 미등록 로봇(robot_id=null) 2건, (3) 결측: sensor_score 가 null 인 행 1~2건, (4) 경계값 — 동작 실패(action_ok=false)·통신 끊김(comm_ok=false) 각 2건, (5) 이상 신호만 있는(anomaly_flag=true, 동작·통신 정상) inspect 케이스 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.{"type":"object","properties":{"event_id":{"type":"string"},"robot_raw":{"type":"string"},"robot_id":{"type":["string","null"]},"action_ok":{"type":"boolean"},"comm_ok":{"type":"boolean"},"anomaly_flag":{"type":"boolean"},"sensor_score":{"type":["number","null"]},"label":{"type":"string","enum":["normal","inspect","halt"]},"ts":{"type":"string"}},"required":["event_id","robot_raw","robot_id","action_ok","comm_ok","anomaly_flag","sensor_score","label","ts"]}| Python | 운영 로그 파서·분류 규칙·장애 묶음 로직의 구현 언어입니다 |
| ROS | 로봇 동작·센서·통신 신호의 출처(로그 토픽)를 가정한 입력 소스입니다 |
| Linux | 현장 엣지 장비에서 게이트가 도는 운영 환경을 가정합니다 |
| Zod | 운영 로그와 게이트 출력의 런타임 형식 검증입니다 |
| React | 로봇·현장별 운영 그리드·분류 카드·장애 묶음을 렌더하는 프레임워크입니다 |
| Claude | 장애 사유 설명·태깅 보조 LLM(판정은 규칙)입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(분류가 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(로봇·현장별 장애 추이)로 진행합니다.
운영 로그 1건의 분류 카드. 결정·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 로봇 제어 옳고 그름이 아니라 현장 운영 가능 여부 게이트입니다.
{"type":"object","properties":{"event_id":{"type":"string"},"robot_id":{"type":["string","null"]},"decision":{"type":"string","enum":["normal","inspect","halt"]},"factors":{"type":"array","items":{"type":"string","enum":["action_fail","comm_loss","anomaly","unmapped_robot","missing_metric"]}},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["event_id","robot_id","decision","factors","reason","evidence","hedge"]}[
{
"input_ref": "ro_002 (동작 실패 + 이상)",
"output": {
"event_id": "ro_002",
"robot_id": "hm1",
"decision": "halt",
"factors": [
"action_fail",
"anomaly"
],
"reason": "동작이 실패하고 센서 이상까지 떠 현장에서 계속 돌리면 위험합니다. 안전을 위해 즉시 중단합니다.",
"evidence": "action_ok=false, anomaly_flag=true",
"hedge": "동작 실패라 안전을 위해 중단합니다"
}
},
{
"input_ref": "ro_003 (통신 끊김)",
"output": {
"event_id": "ro_003",
"robot_id": "agv_a",
"decision": "halt",
"factors": [
"comm_loss"
],
"reason": "통신이 끊겨 로봇 상태를 신뢰할 수 없습니다. 원격 제어·모니터링이 안 되는 상태라 중단합니다.",
"evidence": "comm_ok=false",
"hedge": "통신 끊김이라 중단합니다"
}
},
{
"input_ref": "ro_005 (미등록 로봇)",
"output": {
"event_id": "ro_005",
"robot_id": null,
"decision": "inspect",
"factors": [
"unmapped_robot"
],
"reason": "로봇이 마스터에 없어 정상을 단정하지 않습니다. 동작·통신은 정상이라 로봇 등록·임계 설정을 위해 점검으로 둡니다.",
"evidence": "robot_id=null, action_ok=true",
"hedge": "미등록 로봇이라 임계 설정 후 판단이 필요합니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 분류 규칙(동작실패/통신끊김→halt·이상/미등록/결측→inspect·통과→normal)과 일치하는지 봅니다. 3. evidence 가 입력 로그의 실제 값 인용인지 토큰 매칭으로 확인합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 검토자 2명이 비동기로 분류를 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.