로자이크 로봇 온톨로지 관계도·질의응답 문서 8/18 재검증 및 정정

2026-08-14 작성 「로자이크 로봇 온톨로지 관계도 및 실제 질의응답」을 2026-08-18 두 차례(수치 검증 → 적대적 전수 검토) 재실측했다. 본문 정정 12건 + 관계도 전면 교체 가 필요했다. 배포본: 문서/회사/LG PoC/260818 로자이크 로봇 온톨로지 관계도 및 실제 질의응답.pdf (A4 13p).

결론#

2026-08-14 작성 「로자이크 로봇 온톨로지 관계도 및 실제 질의응답」을 2026-08-18 두 차례(수치 검증 → 적대적 전수 검토) 재실측했다. 본문 정정 12건 + 관계도 전면 교체가 필요했다. 배포본: 문서/회사/LG_PoC/260818_로자이크_로봇_온톨로지_관계도_및_실제_질의응답.pdf (A4 13p).

가장 큰 오류 — 전체 관계도가 manifest와 어긋남#

문서의 「전체 관계도」는 온톨로지 스키마 도식인데 링크 26개 중 8개가 역방향, 5개가 누락이었다(그린 건 21개뿐인데 제목은 "링크 26"). 객체 21개는 전부 있었다.

역방향 8개: usedCheckpoint resultOf recordingOf clipOf observedFrom producedBy usesDataset sourcedFrom
누락 5개: builtFrom trainedOn collectionForObject mountedOnRobot ranOnCell
builtFrom은 이 작업의 핵심 신규 링크로 소개해 놓고 정작 관계도에 없었음

manifest 실제 방향(전수): 관측 계보 12개 — ExecutionResult/ExecutionVideo/ActionClip → Execution → ModelCheckpoint → TrainingRun ← RunConfig·TrainingPoint, TrainingRun/RunConfig → Dataset → Episode/CollectionSet, Episode → CollectionSet. 작업·설비 14개 — EvalConfig/CollectionSet/TrainingRun/Execution → Task → Object, CollectionSet → Object, Execution → Robot/Cell, Asset → Cell/Robot, Cell → Robot → RobotModel, RobotState → RawRecordRef, RobotState → Robot. ParameterSpec은 링크 없는 고립 노드. 12+14 = 26.

역할(role) 오분류: Task와 EvalConfig는 manifest상 observed인데 문서는 master 색으로 칠했다. master는 6개뿐 — Asset, Cell, Object, ParameterSpec, Robot, RobotModel.

단일 규칙 없음: "온톨로지 링크는 전부 데이터 흐름의 반대 방향"이라는 캡션은 자기모순이다. episodeOf·configOf는 흐름과 같은 방향이고, sourcedFrom·builtFrom·usesDataset·producedBy·usedCheckpoint만 상류를 가리킨다.

본문 오류#

Q1 기간 — "8/7~8/11 867회"는 틀림. 867은 from=2026-08-01 호출값이고 8월 실증은 8/4의 181회(080313_LG, 성공 0)부터 시작. 8/7~8/11로 좁히면 686/675/95 = 14.1%.
Q1 "eval_config lg 그대로" — 근거 없는 단정. Execution↔EvalConfig 링크가 manifest에 없고 execution 테이블에 config 참조 컬럼도 없다. 결과에 찍힌 값(30Hz·infer 16·FT on / chunk 1·2·8)만 말할 수 있다.
Q1 chunk_steps=2의 10/30(33%) — 단일 조건이 아님. scale 조합 3개가 섞였고 기본 조합만 보면 10/27(37.0%), 나머지 2회·1회 전부 실패.
Q2 "수집셋에서만 갈린다" — 체크포인트도 갈린다(epoch 349·val 1e-4 대 499·2e-5). 데이터와 체크포인트는 붙어 다녀 이 비교로 분리 불가.
Q3 날짜별 — "8/7 211"은 판정분이지 총계가 아니다. 총계는 216(성공 33·실패 178·미판정 5). 216+269+40 = 525.
Q3 체크포인트 11개 — 번호형 10개(49~499, 50 간격) + latest.ckpt 1개(epoch·val 모두 NULL).
"약 12%" — 재현 불가. 정의를 박으면 브리지 보유 수집셋 소속 비배제 시연 2,199개 중 439개 = 20.0%(전체 3,840 기준 874개 = 22.8%).
API 근거에 to 없음 — from만 쓴 호출은 이후 유입으로 값이 변해 재현 불가. from=...T00:00:00Z&to=2026-08-12T23:59:59Z로 고정하면 867 재현.

코덱스가 틀린 항목#

"ModelCheckpoint 번호 11개 + latest 1 = 12개"라고 보고했으나 실제는 번호 10개 + NULL 1개 = 11개. 서브에이전트 수치 보고도 직접 재조회할 것.

시점 변화 (8/14 → 8/18 16:07 KST)#

Execution 3,085 → 3,131 · 도달 2,152(69.8%) → 2,191(70.0%) · pytest 119 → 122 · by-parameters 엔드포인트 추가 · asset probe 관측값 보존 수정.

그대로 재현된 것#

객체 21 · 링크 26 · 수집셋 34 · 작업 8 · 데이터셋 44 · Episode 3,842(배제 2) · 브리지 1,993 전부 verified · 근거 16/4 · sourcedFrom과 builtFrom 보유 데이터셋이 동일한 20개 · 영상 484+41=525 · 080313_LG와 0803_LG·080313_LG_copy의 FT 행 분포 100개 전부 동일 · zarr 탐색 루트 누락 원인(commit 8c74a65로 확인).

재사용 쿼리#

-- 도달률
SELECT count(DISTINCT e.id) FROM execution e
  JOIN model_checkpoint mc ON mc.id=e.checkpoint_id
  JOIN training_run tr ON tr.id=mc.training_run_id
  JOIN run_config rc ON rc.training_run_id=tr.id
  JOIN dataset d ON d.id=rc.dataset_id
  WHERE d.collection_set_id IS NOT NULL;

-- 수집셋 내부 FT 길이 중복 시연
SELECT count(*) FROM episode e WHERE e.excluded=0
  AND (SELECT count(*) FROM episode x
       WHERE x.collection_set_id=e.collection_set_id
         AND x.excluded=0 AND x.ft_rows=e.ft_rows) > 1;

-- 날짜별 총계 vs 판정분 (둘을 혼동하지 말 것)
SELECT substr(e.ended_at,1,10), count(*),
       sum(er.outcome='success'), sum(er.outcome IS NULL)
FROM execution e JOIN execution_result er ON er.execution_id=e.id
JOIN model_checkpoint mc ON mc.id=e.checkpoint_id
WHERE mc.checkpoint_ref=? GROUP BY 1;

교훈#

스키마 도식은 manifest와 전수 대조할 것. 사람이 읽기 좋게 "데이터 흐름 순"으로 그리면서 링크 이름을 붙이면 방향이 뒤집힌다. 흐름도와 스키마도는 분리하고, 스키마도는 from→to를 그대로 따를 것.
요약 API는 to를 고정할 것. from만 쓴 근거는 나중에 재현되지 않는다.
총계와 판정분(denominator)을 구분해서 쓸 것. 미판정 건수가 섞이면 합이 안 맞는다.
에이전트 답변을 "원문 그대로"라고 명시했더라도, 오류가 여러 건이면 주석 누적보다 본문 정정 + 정정 이력표가 낫다.

PDF 렌더#

puppeteer-core + 로컬 mermaid.esm.min.mjs → mermaid.run() → page.pdf(). 하네스 .../6c621e83.../scratchpad/pdf/print.mjs. 인쇄 CSS: 라이트 고정, printBackground:true, details를 open=true, .turn은 break-inside:auto, 세로 긴 mermaid는 max-height:168mm, 표의 좁은 열은 width:1%+nowrap으로 고정.

스크럼 재편 결과 (2026-08-18 반영 완료)#

에픽 SCRUM-478 하위 5개를 "문서는 하나, 티켓은 끝나는 순서대로" 원칙으로 재편. 반영 완료.

티켓	처리	상태
SCRUM-519	제목을 문서명으로 변경, 518의 계보 부분 흡수, PDF 첨부	완료
SCRUM-518	범위를 식별자 규범으로 축소 (계보는 519로) → 부록 A	해야 할 일
SCRUM-520	ONS 이벤트·무결성 계약 → 부록 B	해야 할 일
SCRUM-521	파라미터·피드백·검수 상태 → 부록 C	해야 할 일
SCRUM-522	범위를 화면 활용 기준으로 축소 (시나리오는 519로) → 부록 D	해야 할 일

핵심 설계 결정: 남은 4개 티켓의 산출물을 전부 "SCRUM-519 문서의 부록 X"로 지정. 티켓마다 새 문서를 만들지 않으므로 설계 문서는 끝까지 1개로 유지된다. 원래 문제의식("설계 문서가 많아 아무도 안 읽는다")은 티켓 수가 아니라 문서 수의 문제였다.

병합하지 않은 이유: 코덱스는 5개를 전부 519로 Duplicate 병합하고 문서에 부록 A~D를 먼저 채운 뒤 동시에 완료하라고 권고했으나 채택하지 않았다. - 부록 B(ONS 계약)·C(파라미터 스냅샷)는 최인호·문승연 영역에 걸려 단독 작성 불가 - 부록 C의 검수 상태는 온톨로지에 개념 자체가 없어 신규 설계 필요 - 다 끝난 온톨로지 작업이 남의 일을 기다리며 LG PoC 마감(8월 말)까지 "진행 중"으로 박힘 - 520·521은 중복이 아니라 아직 안 한 일이라 Duplicate는 기록 왜곡

링크는 Relates만 사용. Duplicate는 위 이유로, Blocks는 근거 없는 선후행이 생겨서 배제. 연결: 518·520·521·522 ↔ 519, 519 ↔ 489·530·532, 521 ↔ 362.

Jira 조작 방법: ~/.rosaic/scrum-report.env의 JIRA_BASE_URL/JIRA_EMAIL/JIRA_API_TOKEN + Basic 인증. 설명은 v2 엔드포인트에 Jira 위키 마크업 문자열로 PUT하면 서버가 ADF로 변환해준다 — h2. 헤딩, ||헤더||/|셀| 표, *굵게*, {{코드}}, (/) 체크마크, SCRUM-000은 자동 inlineCard 링크. ADF를 손으로 만들 필요 없다. 첨부는 v3 /issue/{key}/attachments에 X-Atlassian-Token: no-check + multipart.

워크플로 제약: 전이는 해야 할 일/진행 중/검토 중/보류/완료 5개뿐이고 취소가 없다. 착수 전 티켓을 정리하려면 완료로 닫는 수밖에 없어 "수행했다"로 오인될 수 있으므로, 닫기 전에 원래 제목과 이관 범위를 반드시 남길 것. 설명이 비어 있는 티켓은 제목이 유일한 범위 기록이다.

부수 발견: SCRUM-532 「[개발] 실행·데이터셋·모델·결과 지식 요약 화면 구현」(최인호)이 이미 완료 상태다. 따라서 522의 화면 활용 기준은 백지에서 그리지 말고 구현된 화면(/acquire/7-lineage)을 기준으로 역으로 정리하는 게 빠르다.

온톨로지 구조 평가 및 노션 발행 (2026-08-28)#

노션 Docs DB의 「온톨로지 구성」 페이지(3ca5c5f1-8d3e-8078-9988-e2a3cb9b6752)에 mermaid 도식 3장 + 구조 평가를 발행했다. 이전 「JARVIS — 설계·구현 상태 및 로드맵(데모)」의 관계도 이미지를 대체한다.

10일 사이 온톨로지 변화 (8/18 → 8/28)#

	8/18	8/28
링크	26	27 (`usedEvalConfig: Execution → EvalConfig` 추가)
Execution	3,131	3,576
CollectionSet / Episode	34 / 3,842	35 / 3,846
EvalConfig	30	49

주의: usedEvalConfig는 스키마만 생기고 39/3,576(1.1%)만 채워짐. 따라서 8/18자 PDF와 SCRUM-521 설명의 "Execution↔EvalConfig 링크가 아예 없다"는 서술은 낡았고, 정확히는 "링크는 생겼으나 과거 실증에는 안 채워짐"으로 고쳐야 한다.

핵심 진단 — 3단계가 대칭이 아니다#

단계마다 설정·입력·실행·결과·증거 다섯 자리가 있어야 원인을 되짚을 수 있는데:

취득: 설정 없음, 증거 없음. Episode.excluded는 boolean뿐 사유 없음
학습: raw ID가 DB에는 전부 있으나(TrainingRun 74/74, TrainingPoint 210만/210만, Checkpoint 530/530) manifest에 RawRecordRef 링크가 없어 API로 추적 불가
실증: 가장 촘촘하지만 설정 연결 39/3,576, ActionClip 0, 영상 실참조 2,791/3,576

계보 단절 지점#

sourcedFrom 20/44 · builtFrom 20/44 · TrainingRun 74건 중 취득까지 종단 도달 21건 · Execution 3,576 중 취득까지 2,589.

파라미터 범용성 — 18개 중 로봇무관은 2개뿐#

ExecutionResult 18속성 분류: 로봇무관 2(outcome, inferenceMsP50) / 파이프라인전용 3(modeLabel, contactTimeS, reachingTimeS) / 잘못된 위치 13 — modelId·ckptPath는 계보이지 결과가 아니고, dataHz·chunkSteps·numInferenceSteps는 EvalConfig에 이미 있는 설정값이며, scalePx~scaleOz·ftDisable·ftFixed는 action 축·좌표계·단위 계약이 없어 다른 파이프라인에서 해석 불가.

EvalConfig.robotEndpoint(49중 46이 동일 IP)·cameraSerials(46이 동일 시리얼)는 물리 장비 식별자라 Asset/Robot/Cell에 있어야 할 값이 설정 객체에 반복 저장된 것. EvalConfig → Asset/Robot/Cell 링크 없음.

ParameterSpec 13행은 링크 0/27로 완전 고립. paramKey를 소비하는 코드가 저장소에 없고, 결과 파라미터 컬럼은 result_params.py에 따로 하드코딩. 값 인스턴스도 소유 객체도 없는 전역 사전.

다중 로봇 수용성#

저장 스키마는 버틴다(Robot.robot_ref unique, 여러 Robot이 같은 RobotModel 참조 가능, Execution/RobotState 모두 Robot FK). 런타임이 고정: masters.py가 robots[0]·cells[0]·franka-fr3 하드코딩, STATE_ADAPTER_CLASSES에 franka-fr3 1종만, Cell.robot_id 단일 컬럼(셀당 로봇 1개), execution.robot_id·robot_state.robot_id 인덱스 없음. MZ07/Yaskawa 어댑터는 미확인(주석 2건뿐).

Execution.robotRef·RobotState.robotRef는 FK가 아니라 표시용 문자열. 실제 관계는 robot_id FK. RobotState.robotRef는 826,221행 전부 NULL.

MZ07 통합 방향 (노션 Docs)#

「Integrate Nachi into ManipForce」: ManipForce의 모델·action처리·좌표변환·trajectory·interpolation을 그대로 두고, Franka gateway로 가던 200Hz pose stream을 NACHI adapter가 받아 변환. 좌표 기준이 fr3_link0라 프레임 이름 자체에 Franka가 박혀 있다. → scale* 계열이 MZ07에서 재사용될 여지는 있으나 의미 계약이 속성에 없어 보장 불가.

작도 원칙 (재확인)#

흐름도와 링크도를 절대 한 그림에 섞지 말 것. 이전 관계도 이미지가 데이터 흐름 방향으로 그리면서 링크 이름(resultOf, producedBy)을 붙여 방향이 반대가 됐다. 이번 노션 페이지는 1장=흐름(좌→우, 취득→실증), 2장=manifest from→to 그대로로 분리했다.

노션 발행 방법#

RKA 토큰(rosaic-knowledge-agent/.env의 NOTION_TOKEN) + https://api.notion.com/v1 직접 호출. claude.ai Notion MCP 커넥터는 401(토큰 만료). Notion 코드 블록의 language를 mermaid로 주면 다이어그램으로 렌더된다. 블록 빌더/발행 스크립트: .../scratchpad/onto/notion_pub.py, 콘텐츠: build.py. 표는 table 블록 + table_row children, has_column_header:true. 한 번에 100개 초과 시 90개씩 분할 PATCH.

Sagwan Revalidation 2026-08-31T11:59:06Z#

verdict: refresh
note: manifest·배포본 의존 수치라 8/18 이후 변경 여부 재실측 필요

Sagwan Revalidation 2026-09-03T03:01:44Z#

verdict: ok
note: 이전 검증 후 변경 신호가 없어 정정·권장안은 여전히 재사용 가능.

Sagwan Revalidation 2026-09-09T05:14:50Z#

verdict: ok
note: [chatgpt HTTP 404] {

Sagwan Revalidation 2026-09-11T19:48:36Z#

verdict: ok
note: 2일 전 재검증된 교정 기록이며, 특정 시점(8/18) 수정 사실을 기술한 역사적 문서라 내용이 변질될 여지가 없음.

Sagwan Revalidation 2026-09-15T13:32:35Z#

verdict: ok
note: 8/28 usedEvalConfig 변화까지 반영돼 현재 모순 근거가 없다.

결론#