pncad›문서›2026-08-17 세션 — poincad2 S1 스키마 v2 그릴링 + 로드맵 페이지 등록
9.9 KB · 수정 2026-08-17 19:42
목차

2026-08-17 세션 — poincad2 S1 스키마 v2 그릴링 + 로드맵 페이지 등록

기록: [코디]

논의·대안

S0(설계 확정)이 끝난 상태에서 S1 스키마 v2 착수 전 그릴링을 걸었다. 가구 CAD 데이터모델의 갈림길 9개를 사실로 받쳐 놓고 하나씩 물었다.

먼저 로컬 덤프(reference/catalog-2026-08-17/)에서 사실 확인: - DIVDIR='A'(25행) = 서브아티클 삽입 — DIVIDER에 존 분할부재가 아니라 아티클명이 들어있다 (BC_1DR_1SD, $DM_SUBARTICLE, Plant_05). 대부분 imos 데모. V/H/I 말고 4번째 분할방향. - LINDIV2는 5행뿐 → 모델링 대상 아님(원문만 보존). - 아티클당 존 노드 = 중앙값 8 · 최대 60 → 177종 존트리 전량 스냅샷해도 데이터가 아주 작다. - anglprim.DIMCALCFX/Y/Z(아티클 치수 자체를 수식 파생) 사용 = X 14 / Y 167 / Z 299종. - CP distinct 756종 중 Rv 포함 270종 → Rv를 파라미터로 빼면 124종(146종 감소). 일반가구_AS_Rv# 24 · 주방가구_AS_Rv# 21 · 일반가구_칸막이_Rv# 17 · 일반가구_FS_Rv# 16.

대안 축: - 카탈로그 정본 = 존트리 스냅샷(데이터) vs 타입 생성기(코드) vs 하이브리드 - 완성/재단 치수 = 완성 정본·재단 파생 vs 재단 정본 vs 둘 다 독립 - 변수 스코프 = 3단(카탈로그→현장→인스턴스) vs 2단 vs imos VARCAT 동형 - 서랍 N단 = 존트리 자식으로 전개 vs fill 안에 접기(imos DRAWERZONE 방식) - 노브 = 편집지점 포인터 vs 트리 변형 패치 vs 문서만

결정

페페 답(2026-08-17): 1. 카탈로그 정본 = 존트리 스냅샷. 19타입은 UI 노브 그룹 메타데이터일 뿐. 근거 = LINDIV이 이미 비율+고정 혼합이라 W/D/H 변경 시 파라메트릭 전파가 공짜, S7 imos 100% 일치 검증이 가장 쉽다. 2. 엣지는 치수 계산에 반영 안 한다 — 자재 두께로만 계산. 부재는 치수 1세트만 갖고, 엣지는 변 4개 레코드로 따로 붙여 엣지밴딩 길이 산출·도면 표기에만 쓴다. 재단치수는 필드가 아니라 BOM 출력 시 cut(part) 함수 한 군데서 만든다(지금은 항등). 3. 변수 스코프 3단 = 카탈로그 기본 → 현장(오더) 프리셋 → 인스턴스 오버라이드. 해석 순서 = 인스턴스 > 현장 > 카탈로그. 지시⑥(D·H 일괄 / W만 수동)과 정확히 일치. 4. 도어 = 존의 fill 종류 하나 + emit:false. imos도 도어를 존트리 안에 넣는다 (anglelem PARTTYPE='D' 623행) → 변환기가 그대로 옮기면 끝. 뷰 토글 = emit:false 노드 숨기기. 5. 저장 = 카탈로그/씬 2파일, 계산결과는 저장 안 하고 열 때 재계산. 6. 존 노드 = faces(존의 벽면 4장) + split(자식을 가르는 선반/칸막이) 둘로 분리 — imos와 동형 (anglelem vs TOPSHELF/BOTSHELF/DIVIDER 1053/937/1392행). 부재 주소는 존경로에 안 이어붙인다. 7. 서랍 N단은 존트리 자식 존으로 전개한다. imos가 DRAWERZONE으로 뺀 건 anglzone에 못 넣어서지 설계가 아니다. 전개하면 "서랍통 가로 = 그 존의 내경 Wz" 원칙이 공짜로 성립. 8. 배치 좌표 = 벽 + 가로오프셋 + 바닥높이({wall,x,z}). 룸플랜 개념 안 끌고 들어옴. 9. 노브 = 존트리 안 편집지점 포인터 3종(변수값 / LINDIV 문자열 / fill 교체). 구조를 새로 만드는 노브(아일랜드=레이어 추가 등)는 두지 않고 별개 카탈로그 항목으로 남긴다.

코디 라우틴 결정: LINDIV은 원문 문자열로 저장(평가결과는 런타임만) · DIVDIR='A' 서브아티클은 kind:"subarticle" 자리만 두고 1차 미구현.

  1. CP = (파트 × 자재 × Rv) 3축 조합 (페페 설명 → 코디 재추천 채택). 페페 설명으로 CP의 정체가 바뀌었다 — CP는 ①주방/일반 15T·18T 자재 구분 ②천판·지판·밴드·측판 등 파트별 구분 ③이동선반·고정선반은 계산식이 단순한데 imos에서 세부 지정에 시간이 오래 걸려 필요한 수량만큼 일일이 만든 것. 즉 CP 상당수가 imos UI 한계가 만든 중복이다. 실측이 이걸 받쳤다: 덤프 CP 756종 중 Rv 붙은 270종이 Rv를 숫자 파라미터로 빼면 124종으로 접힌다. → CP를 마스터로 베끼지 않고 3축으로 풀되 _imos 원문은 항상 보존(S7 대조·역변환).

작업 중 발견 — ★ LINDIV이 정본, children은 그 결과. imos anglzone에 편집 후 남은 고아 존 행이 있다: 자식 있는 존 3,185개 중 세그먼트 수와 자식 수 정확히 일치 1,430 / 불일치 198(12.2%), 그리고 불일치는 항상 자식이 더 많다(diff ≥ 0, top/bot/divider 개수와 무상관). 1:1:1 → 1:1로 고쳤을 때 세 번째 존 행이 안 지워진 흔적. → validate()가 불일치를 에러로 잡고, S2 변환기는 세그먼트 수만큼만 가져오고 나머지는 버리고 로그에 남긴다. LINDIV1이 빈 문자열인데 자식이 있는 존 184건은 자식 수만큼 균등분할로 읽는다.

자체검증에서 잡힌 내 오류 3건(코드가 맞고 기댓값이 틀렸다): 찬넬 분할은 지판 15T가 높이를 먼저 먹어 641/64(720−64 아님) · 지판 깊이는 뒤판 앞까지 535 · 선반 깊이는 535−Rv18=517. 그리고 도어 판정을 role로 하면 밑장_SDO_noHandle을 놓친다 → 원문 CP명으로 판정하도록 수정.

산출물·커밋

S2 (같은 세션에서 이어서 완료)

페페 지시 2건 반영

  1. "몸통규격표 RDL을 봐라" → SPEC-BOM.md. imos BINDATA의 001 몸통규격표(229KB)를 base64로 무손실 추출·해독. 발견 = 부재↔아티클 조인 IDBGRPS.HIGHARTID · PRODCODE 코드표 (01측판~08서랍재 / 11속대류·12좌대류·13걸레받이문틀재·14경판몸통재도어 / 21도어·33.1EP 제외) · imos↔PFS 다리 = PROADMIN.ARTICLENO = PFS field.field_no · 지시②의 현장·주방일반·몸통칼라 = PROADMIN.COLOUR2~5 · 치수 칸 = FWIDTH*FLENG(PART_V만 뒤집고 FLOOR 버림).
  2. "치수 추측에서 시간 뺏기지 마라, 가구 KB 참고해라" → imos CP 테이블이 정본임을 확인하고 전량 이식. 가구전문가 에이전트 판정 = KB는 imos CP 필드 수준 값을 갖고 있지 않다(교과서·카톡마이닝 실무값 위주), 내 imos 실측값은 전부 정확, 치수는 imos CP를 1차 소스로 쓰라는 권고. 이 이식만으로 일치율이 배로 뛰었다.

페페 확정 (같은 세션)

다음

관계