← 미리디 아카이브

MORDOR RLSC 증분 추출 2026-08-26 코드 실측

I.I. Structuriser (IIS)

증분 정보 구조화기. 미리캔버스에 신규 기능이 생겼을 때 자체 모델(Structuriser)을 재학습하지 않고, 이미 뽑아 둔 Old RLSC 위에 델타만 얹어 New RLSC를 만드는 2단계 추출 레이어다. 아키텍처는 2026-05-26에 확정됐고 코드 구현체는 아직 없다 — 그래서 이 문서의 절반은 "델타가 꽂힐 자리가 코드에서 어디인가"다.

아키텍처 확정 구현체 없음 Jira MOR-1425 · 1426 · 1427 · 1448 aippt-prisonbreak 실측

목차

  1. §1아키텍처 — 한 줄과 도해
  2. §2왜 필요한가 — 제3의 경로
  3. §3두 원칙과 그 코드 선례
  4. §4흡수 대상 4건 — 델타가 꽂힐 자리
  5. §5파이프라인 좌표 — 코드에서 어디에 끼우나
  6. §6이미 있는 선례 셋
  7. §7현황 · 열린 결정
  8. §8코드 링크 색인
§1

아키텍처 — 한 줄과 도해

기존 파이프라인은 ALSC → Structuriser → RLSC 한 방이다. IIS는 그 뒤에 한 칸을 더 끼운다 — 기존 결과물을 고치지 않고 입력으로 받아서, 신규 정보만 더한 새 결과물을 낸다.

현재 → IIS 도입
ALSC
시트를 평탄화한 절대좌표 중간 데이터
parseAsStructuredContent
Structuriser
자체모델 / GPT — 변경 최소화
AgenticRLSCStructuriserManager
Old RLSC
기존 결과물 — 그대로 보존
rlsc_results
I.I. Structuriser
Proprietary LLM · 임시 레이어
delta: 신규 role·type·속성
New RLSC
신규 정보가 반영된 결과물
→ 컴포넌트 추출로

데이터가 충분히 쌓인 뒤 — IIS 소멸 경로
ALSC
같은 입력
New Structuriser
Old→New 쌍을 학습 데이터로 재학습
New RLSC
직접 생성 — IIS 불필요
2026-05-26 회의 확정. IIS가 만드는 Old → New 쌍이 그대로 재학습 데이터가 되므로, IIS는 자기를 없애기 위해 존재하는 레이어다. 정본: incremental-information-structuriser-blueprint.md

단계별 contract

단계입력출력비고
Structuriser (기존)ALSCOld RLSC자체모델 / GPT — 변경 최소화
IISOld RLSC (+ ALSC · sheet context)New RLSC델타: 신규 role · type · 속성
(미래) New StructuriserALSCNew RLSCOld→New 를 학습 데이터로 재학습
§2

왜 필요한가 — 제3의 경로

미리캔버스에 신규 차트 타입이 붙거나, 도형에 텍스트를 넣을 수 있게 되거나, 보조텍스트·BigNumber 같은 새 텍스트 role이 생기면 선택지는 원래 둘뿐이었다.

선택지 A

자체모델 재학습

Case 4 MLLM을 신규 element/role 마다 다시 학습한다.

비용 · 리스크 · 리드타임이 크다. 프롬프트·모델을 건드리면 영향 범위를 예측하기 어렵다 — 기존 추출이 어떻게 흔들릴지 모른다.

선택지 B

방치

일단 둔다.

신규 기능 정보가 RLSC에 영원히 반영되지 않는다. 검색·대치·컴포넌트 추출이 모두 RLSC를 근거로 돌기 때문에, 그만큼 정합성 공백이 남는다.

선택지 C — IIS

델타만 얹는다

Old RLSC를 읽기 전용 입력으로 두고, 신규 정보만 추가해 New RLSC를 만든다.

기존 Structuriser는 손대지 않으니 회귀 위험이 격리되고, 쌓인 Old→New 쌍이 나중에 재학습 데이터가 된다.

Native Element 와 IIS 의 경계

신규 요소가 전부 IIS 대상은 아니다. ALSC 변환만으로 결정적으로 처리되면 IIS는 불필요하다 — 그 경로를 blueprint 는 Native Element path 라 부른다.

케이스대응
ALSC 변환만으로 처리 (결정적)Native Element path — IIS 불필요ExtendableShapeItem → SVG (MOR-1416)
RLSC role · 속성 추가IIS 2단계 추출보조텍스트, BigNumber, 신규 ChartType
§3

두 원칙과 그 코드 선례

원칙 1 — Rule-first

LLM을 부르기 전에 결정적 규칙으로 처리할 수 있는 델타를 먼저 뗀다. 차트의 BarType/ChartType 분류처럼 시트에 답이 적혀 있는 것은 rule layer가, 가짜 차트 판별처럼 rule의 한계 영역만 LLM이 맡는다.

이 원칙은 이미 이 레포의 습관이다. 바디 컴포넌트 3축 분류에서 Information Type과 Visual Focus는 모델에게 묻되 답을 버리고 코드로 유도한다 — 규칙으로 결정되는 값을 모델에 맡기면 흔들린다는 같은 이유다.

Rule-first 의 기존 사례 — 모델에게 묻고 답을 버린다 visual-layout-label/component-labels.ts:61-103
/**
 * Component 1순위 → Information Type.
 *
 * 세 축을 각각 모델에게 물으면 "Component 는 Timeline 인데 Information Type 은 Comparison"
 * 같은 체계 위반이 나온다. 1순위가 정해지면 상위 분류는 하나로 결정되므로 코드에서 유도해
 * 위반을 구조적으로 차단한다.
 */
export const IT_OF_COMPONENT: Readonly<Record<ComponentTypeValue, InformationTypeValue>> = {
  [ComponentType.BigNumber]:  InformationType.Enumeration,
  [ComponentType.Timeline]:   InformationType.Sequence,
  // …
};

/** 구조가 강제하는 Visual Focus. 프롬프트에도 같은 규칙이 있지만 모델이 빠뜨릴 수 있어 코드에서 확정한다. */
export const FOCUS_OF_COMPONENT = {
  [ComponentType.BigNumber]: VisualFocus.Metric, // 수치가 주인공인 것이 이 타입의 정의
  [ComponentType.Timeline]:  VisualFocus.Index,  // 날짜·연도 레이블이 각 항목의 표식
};

IIS의 rule layer가 새로 발명할 것은 없다 — 이 패턴을 델타 판정에 옮겨 붙이는 것이다.

원칙 2 — 속성별 전용 Structuriser

범용 IIS 하나로 모든 델타를 처리하지 않는다. 차트 전용 · 텍스트 role 전용처럼 좁게 나누면 프롬프트가 짧아져 비용이 내려가고 정확도가 올라간다. Jira 구조가 그대로 이 분할을 따른다 — MOR-1425가 skeleton, 1426·1427·1448이 각 전용 Structuriser다.

MOR-1425 가 나머지를 blocks 한다
MOR-1425
IIS 파이프라인 설계 · 구현 (skeleton)
Old/New RLSC versioning 확정
MOR-1426 · 차트 전용
BarType · ChartType 식별, 가짜 차트 패턴 구분
MOR-1427 · 텍스트 role 전용
보조텍스트 · BigNumber
MOR-1448 · Layout Type 증분
신규 Layout Type 정보 편입
§4

흡수 대상 4건 — 델타가 꽂힐 자리

각 항목마다 "코드에서 지금 무엇이 비어 있는가"를 실측으로 붙였다. 델타의 목적지가 특정되지 않으면 IIS는 설계도로만 남는다.

MOR-1426

신규 차트 타입 — BarType · ChartType 식별, 가짜 차트 판별

7월 목표 선행: 신규 템플릿 디자인

차트 델타의 rule layer 는 사실상 이미 있다. 시트의 vizType·chartType 문자열을 캐논 문자열로 정규화하는 결정적 매핑이 ALSC 추출 단계에 박혀 있고, 매핑에 없는 신규 타입은 ChartType.Unknown sentinel 로 떨어져 명시적으로 표시된다. 즉 "신규 차트 타입이 들어왔다"는 신호를 코드가 이미 낸다 — IIS 가 받을 트리거가 준비돼 있는 셈이다.

rule layer — 캐논 정규화 + Unknown sentinel structuredContent/chartElementAttribute.ts:90-129
/**
 * 원본(레거시 소문자 스네이크 / 엔진 vizType) → 캐논(RLSC ChartType 값) 정규화 매핑.
 * 게이지(GaugeItem)의 vizType 은 세부(HOR/HALF/ARC/FULL)까지 있으나 RLSC 에서는
 * 막대형(BAR_GAUGE)·원형(CIRCLE_GAUGE) 두 종으로 합쳐 표현한다.
 */
const LEGACY_TO_CANONICAL: Record<string, string> = {
  vertical_bar: 'BAR_CHART_VER',  horizontal_bar: 'BAR_CHART_HOR',
  BAR_GAUGE_HOR: 'BAR_GAUGE',     BAR_GAUGE_VER: 'BAR_GAUGE',
  CIRCLE_GAUGE_HALF: 'CIRCLE_GAUGE', /* … */
};

/**
 * 매핑 안 되거나 타입이 없으면 `ChartType.Unknown` 을 반환한다.
 * 과거엔 `VerticalBar` 로 떨어뜨렸으나, 미지원 신규 타입·빈 차트·오타가
 * 세로막대로 둔갑해 문제가 조용히 가려지는 문제가 있어 명시적 sentinel 로 바꿨다.
 */
export function normalizeChartTypeToSchema(rawType: string): ChartType {
  const canonical = LEGACY_TO_CANONICAL[rawType] ?? rawType;
  return CHART_TYPE[canonical] ?? ChartType.Unknown;
}

BarType 은 별도 필드가 아니다. 가로/세로 구분은 원문 타입 문자열과 axisFlip 을 조합해 seriesAxis: 'rows' | 'columns' 로 환원된다 (:131-142). RLSC 스키마가 차트에서 들고 있는 값은 네 개뿐이다 — chartType · rowCount · columnCount · seriesAxis (layoutStructure.ts:246-261).

실제로 터진 적이 있다. 2026-06-29 프로덕션에서 에디터가 차트 데이터 위치를 chartPropsdataVizProps 로 옮겼는데 추출 코드가 옛 자리만 읽어 차트 노드 하나 때문에 레이아웃 39개의 추출이 통째로 실패했다. 신규 차트 타입이 아니라 시트 내부 구조가 바뀐 경우였고, 해법은 IIS가 아니라 입력 매핑을 넓히는 것이었다 — RLSC 출력 모양은 그대로 두고 읽는 자리만 늘렸다.

구·신 구조를 한 함수로 흡수 — 출력은 불변 jsonToStructuredContent.ts:261-299
// - 구버전: props.chartProps ({ type, dataSource, options.axisFlip ... })
// - 신버전(version 3.0.0~): props.dataVizProps ({ vizType, datasource, ... })
// 둘 다 없는 ChartItem 도 prod 입력으로 존재하므로 옵셔널 체이닝으로 방어한다.
const chartProps   = props?.chartProps;
const dataVizProps = props?.dataVizProps;

const rawType = chartProps?.type       ?? dataVizProps?.vizType    ?? '';
const matrix  = chartProps?.dataSource ?? dataVizProps?.datasource ?? [];
// …
const chartType = normalizeChartTypeToSchema(rawType);
if (chartType === ChartType.Unknown) { /* 로깅 — 조용히 가려지지 않게 */ }

가짜 차트 판별도 이미 rule 로 한 겹 있다. 유효 컴포넌트 v3.4 · v3.5 정의의 조건 2b/2c 가 "표/차트면 진짜 Role.Element.* element 가 있어야 한다"로 가짜 표·차트를 풀에서 제외한다 (valid-component-meta/v3_5.ts:56-66). IIS가 LLM으로 맡을 몫은 이 rule 이 못 잡는 잔여다.

MOR-1427

신규 텍스트 role — 보조텍스트 · BigNumber

backlog

RLSC role 어휘의 정본은 워크스페이스 패키지 packages/structured-layout/src/role-v2.ts 다. 여기에 Role.Element 8종 · Role.LayoutContainer 12종 · Role.Page 5종이 있고, 린터의 isValidRole() 이 이 네임스페이스를 재귀 순회해 유효 집합을 만든다. 보조텍스트도 BigNumber도 여기에 없다 — 델타가 꽂힐 자리는 정확히 이 파일의 Element 블록이다.

role 어휘 정본 — Element 8종에 신규 role 이 없다 packages/structured-layout/src/role-v2.ts:18-58
export const Element = {
  Title:       'Role.Element.Title',
  Subtitle:    'Role.Element.Subtitle',
  Highlight:   'Role.Element.Highlight',
  Description: 'Role.Element.Description',
  Separator:   'Role.Element.Separator',
  Marker:      'Role.Element.Marker',
  Decoration:  'Role.Element.Decoration',
  Background:  'Role.Element.Background',
} as const;   // ← 보조텍스트 · BigNumber 없음

⚠ BigNumber 는 이미 있지만 다른 축이다

BigNumber 라는 이름은 코드에 이미 존재한다 — 단 RLSC 텍스트 role 이 아니라 바디 컴포넌트 3축 분류(VLL)의 Component Type 17종 중 하나다 (component-labels.ts:16-34). labels.ts 의 VLL 14종과도 이름이 겹치지만 별개 상수라고 파일 헤더가 못 박아 둔다. MOR-1427 이 요구하는 것은 세 번째 어휘 — Role.Element.* 에 들어갈 텍스트 role 이다. 이름 충돌을 그대로 두면 나중에 셋을 구별할 수 없다.

보조텍스트의 현재 대체 경로. 2026-06-06 스레드에서 정원석은 Header/Footer 지정 시 제거보다 Role 교체가 안전하다며 "IIS로도 가능, 당장은 Description 전환"으로 정리했다. 실제 린터에도 그 규칙이 있다 — INVALID_TEXT_ROLE_IN_PAGE_HEADER_FOOTER 는 PageHeader/Footer 내부 Text Decoration 을 Description 으로 바꾼다 (ruleDefinitions.ts). 보조텍스트 role 이 없어서 Description 으로 뭉개고 있는 상태가 곧 정합성 공백의 실체다.

MOR-1448

Layout Type 증분 — 신규 Layout Type 정보 편입

2026-05-26 blueprint 이후 생성

Layout Type 은 유효 컴포넌트 풀의 포함·제외 기준으로 직접 쓰인다. 구조 시각화 전용 타입 일부(Graph · VennDiagram · LayeredDiagram · Gantt · Quadrant · ZStack)가 v3 정의에서 의도적으로 제외돼 있고, 그 제외분을 다시 넣었을 때 Bad/Perfect 비율이 어떻게 변하는지가 별도 실험(MOR-1461 · MOR-1477)으로 돌고 있다. 즉 Layout Type 은 검색 품질에 직결돼서, 신규 타입이 RLSC에 안 들어오면 그 페이지들은 풀에서 조용히 빠진다.

블루프린트에는 이 티켓이 없다. 2026-05-26 blueprint 의 workstream 은 MOR-1425·1426·1427 셋뿐이고, MOR-1448 은 2026-07-24 논의 문서에서 "I.I.S.(MOR-1425/1448/1426/1427) 언제 다시 시작할지" 로만 등장한다 — 나중에 IIS 하위로 붙은 항목이다.

MOR-1416

도형 텍스트 입력 — "확장형 도형"은 IIS 불필요

Native path

ExtendableShapeItemALSC 변환 테이블에서 결정적으로 SVG 로 떨어진다. LLM이 개입할 판단이 없으니 IIS 대상이 아니다.

결정적 nodeType → RLSC type 매핑 (MOR-1326) pipeline/common/util/structuredContent.ts:22-46
export const JSON_TYPE_TO_SCHEMA_TYPE = {
  TextItem:            ContentElementKeyType.Text,
  ShapeItem:           ContentElementKeyType.SVG,
  ExtendableShapeItem: ContentElementKeyType.SVG,   // ← Native path (:41)
  ChartItem:           ContentElementKeyType.Chart,
  GaugeItem:           ContentElementKeyType.Chart,
  // …
};

단, "확장형 도형" 전체가 끝난 문제는 아니다. Native 표현이 가능한 ExtendableShapeItem IIS 불필요이고, 텍스트를 품은 확장형 도형은 엔진 쪽에서 별도 분리 경로를 탄다 (web-2 SplitExtendableShapeItemWithText).

§5

파이프라인 좌표 — 코드에서 어디에 끼우나

"RLSC 추출과 컴포넌트 추출 사이"를 코드로 옮기면 두 워커 사이다. rlsc-worker 가 RLSC를 만들어 rlsc_results 에 쓰고, extract-design-object-worker 가 그걸 읽어 컴포넌트를 뽑는다. IIS 는 이 두 워커 사이에 끼거나, rlsc_results 를 다시 읽는 두 번째 패스로 들어간다.

실제 코드 좌표 — 삽입 지점 두 곳
rlsc-worker.ts :321
parseAsStructuredContent(layout.json_sheet_data, 'json')
시트 → ALSC
rlsc-worker.ts :354-363
new AgenticRLSCStructuriserManager(...).process()
ALSC → Old RLSC
◆ 삽입 지점 A — 인라인
같은 워커 안에서 델타를 얹고 New RLSC로 저장
process() 반환 직후 · 저장 직전
rlsc-worker.ts :367-382
rpc('save_agentic_rlsc_result' | 'save_custom_rlsc_result')
rlsc_results · rlsc_meta.extractorVersion (:379)
◆ 삽입 지점 B — 별도 패스
저장된 Old RLSC 를 다시 읽어 New RLSC row 를 새로 쓴다
MOR-1425 의 versioning 결정에 달림
extractAndSaveDesignObjects.ts :63-75
from('rlsc_results').eq('type','agentic') → best iteration
여기서 어느 RLSC를 고를지가 갈린다
A는 빠르지만 Old RLSC 가 남지 않아 재학습 데이터가 사라진다. B는 Old·New 를 모두 보존하지만 row 를 어떻게 구분할지(rlsc_results 확장 vs 별도 table)가 먼저 정해져야 한다 — 그게 MOR-1425 다.

이미 있는 두 개의 손잡이

다행히 versioning 과 source 구분의 자리는 이미 뚫려 있다.

rlsc_meta.extractorVersion
RLSC 저장 시 추출기 버전을 함께 적는다. IIS 통과 여부·IIS 버전을 표시할 자리로 그대로 쓸 수 있다.
rlscSource 4종
컴포넌트 추출이 이미 'llm' | 'custom' | 'agentic' | 'human' 중 어느 RLSC를 쓸지 고른다. New RLSC 는 다섯 번째 값이 된다.
§6

이미 있는 선례 셋

IIS 는 백지에서 시작하지 않는다. "이미 뽑은 RLSC 를 나중에 고친다"는 행위, "어휘를 버전으로 이중화한다"는 행위, "재학습 없이 유지되는지 판정한다"는 행위가 각각 프로덕션 코드로 존재한다. IIS 가 하는 일은 이 셋에 LLM 을 더하는 것이다.

1

rule-only 2단계 보정이 이미 돈다 — CUSTOM_RLSC_TYPE_REMAP_FROM_SHEET

External Custom Structuriser(MOR-1580)가 남긴 유효하지 않은 type(예: Unknown)을, 시트에서 nodeType 을 조회할 수 있을 때만 MOR-1326 매핑으로 고친다. 구조가 IIS 와 똑같다 — 이미 나온 RLSC 를 입력으로 받아 델타만 고치고, 원본(rlsc_results custom)은 건드리지 않고 결과를 linter_results.rlsc 에만 쓴다. 다른 점은 하나, LLM 이 없다는 것뿐이다.

custom-rlsc-type-remap-from-sheet.ts:10-34"sheet 조회 불가하거나 매핑 결과가 유효 type이 아니면 skip". 실패 시 조용히 물러나는 이 계약도 IIS 가 그대로 물려받을 만하다.

2

role 어휘는 이미 v1 · v2 이중화돼 있다

src/common/schema/role.tsRole.Presentation.* 계열(v1)과 packages/structured-layout/src/role-v2.tsRole.* 계열(v2)이 동시에 존재하고, detectRoleVersion() 이 값만 보고 어느 세대인지 판별한다. 린터의 유효 집합은 v2 만 쓴다 — getAllRoleValues() 주석이 "v1 role 값들 추가하지 않음" 이라고 못 박는다.

schema.utils.ts:128-152 · linter/index.ts:200-216 — Old/New RLSC 를 어휘 세대로 구분하는 패턴이 이미 검증된 상태다.

3

"재학습 없이 유지되는가"를 판정하는 모듈이 있다 — structuriser-verify

Background Extractor 도입으로 Structuriser 입력이 full ALSC → foreground ALSC 로 바뀌었을 때 재학습 없이 RLSC 추출이 유지되는지를 페이지 단위로 자동 판정하려고 만든 모듈이다(MOR-1472). 3계층 판정 — ① 유효성 게이트 ② baseline 대비 변화 ③ 귀책(structuriser 인가 BE 인가) — 이 구조는 IIS 델타 검증에 그대로 재사용할 수 있다. 질문만 바꾸면 된다: "BE 때문인가 Structuriser 때문인가" → "IIS 델타 때문인가 원본 RLSC 때문인가".

structuriser-verify/AGENTS.md · 모듈 전체

§7

현황 · 열린 결정

구현체는 없다

src/lib/incrementalInformationStructuriser/ 는 존재하지 않는다. 2026-08-26 기준으로 aippt-prisonbreak 전체에 incremental 이름의 소스 디렉터리가 없고, IIS 는 문서 9편(docs/projects/mordor/)에만 산다. miricanvas-web-2 에는 Structuriser 라는 문자열조차 없다 — IIS 는 전적으로 MORDOR 영역이다.

항목상태 (근거 시점)
아키텍처확정 — 2026-05-26 회의 (Confluence 통합 회의록 + IIS 개발 논의)
코드없음 — 2026-06-11 기준 그대로, 2026-08-26 실측 확인
블로킹 구조MOR-1425(skeleton)가 MOR-1426 · 1427 · 1448 을 blocks
담당q3 TPM 이예림 → 류민 이관, 실무 후보 이강윤
진행6월 중순부터 멈춤 — 2026-07-24 논의에 "류민님께 물어볼 것: I.I.S. 언제 다시 시작할지"
6월 말 우선순위IIS 개별 feature 보다 MOR-1421 전체 재추출이 앞. 이어 MOR-1422 Search Signature v2 pool (blocking MOR-1423 · 1424)
차트 IIS 시점7월이 현실적 — 신규 템플릿 디자인·summarizer 선행 필요
대체된 접근MOR-1409 (rlscDiffChecker / updater) Hold — IIS 2단계 추출로 대체
scope 재정렬MOR-1042 (BarType) · MOR-1317 (ChartType) → MOR-1426 으로 흡수

먼저 정해야 하는 것

MOR-1425

Old / New RLSC 를 어디에 담나

rlsc_results 를 확장할지 별도 table 을 둘지가 미결이다. 이게 §5 의 삽입 지점 A/B 를 결정한다.

MOR-1427

BigNumber 이름 충돌

VLL Component Type 17종에 이미 BigNumber 가 있다. RLSC 텍스트 role 로 같은 이름을 쓰면 세 어휘(VLL 14종 · Component 17종 · Role.Element)가 구별 불가능해진다.

배포 경계

role 추가는 패키지 변경이다

role-v2.ts@miri-unicorn/structured-layout 워크스페이스 패키지다. role 하나를 더하면 이 패키지를 쓰는 45개 파일이 함께 영향을 받는다.

§8

코드 링크 색인

줄 번호는 아래 커밋 기준 실측이며, 링크는 permalink 다. 전부 워킹트리가 해당 커밋과 같은 상태에서 읽었다.

역할경로레포
IIS 아키텍처 정본 (문서)docs/projects/mordor/incremental-information-structuriser-blueprint.mdaippt
시트 → ALSC (rule layer · nodeType 매핑)pipeline/common/util/structuredContent.ts:22-46aippt
Structuriser 본체 (Old RLSC 생성)agentic-rlsc-structuriser/manager/AgenticRLSCStructuriserManager.tsaippt
Structuriser 런타임 role 정책tool-calling/policy/role/specifications.md:22-51aippt
◆ IIS 삽입 지점 — RLSC 생성·저장 seamworkers/rlsc-worker.ts:354-382 seamaippt
RLSC 버전 표기 자리workers/rlsc-worker.ts:379 rlsc_meta.extractorVersionaippt
컴포넌트 추출 — RLSC 선택designObject/extractAndSaveDesignObjects.ts:63-75aippt
컴포넌트 추출 — rlscSource 4종designObject/extractAndSaveDesignObjects.ts:155-170aippt
MOR-1426 · 차트
ChartType enum · 스키마 (UNKNOWN sentinel)pipeline/common/type/layoutStructure.ts:202-261aippt
캐논 정규화 · seriesAxis 판정structuredContent/chartElementAttribute.ts:76-142aippt
chartProps / dataVizProps 이중 매핑jsonToStructuredContent.ts:261-299aippt
DataVizProps 최소 타입 정의jsonToStructuredContent/types.ts:288-301aippt
가짜 표 · 차트 제외 rule (조건 2b/2c)valid-component-meta/v3_5.ts:55-66aippt
0629 차트 추출 실패 조사 (문서)issue-reports/rlsc-chart-datavizprops-extraction-failure.mdaippt
엔진 CHART_TYPE — 신규 타입의 출발점engine-util/src/chart/constants.ts:35-42 체크아웃 구버전web-2
MOR-1427 · 텍스트 role
◆ role 어휘 정본 (v2) — 델타 목적지packages/structured-layout/src/role-v2.ts:18-58 targetaippt
role 어휘 v1 (Role.Presentation.*)src/common/schema/role.ts:13-33aippt
v1 / v2 판별 · 유효 집합schema.utils.ts:128-152 · linter/index.ts:200-216aippt
BigNumber — VLL Component Type (별개 축)visual-layout-label/component-labels.ts:16-34aippt
Rule-first 선례 — 모델 답을 코드로 덮음visual-layout-label/component-labels.ts:61-103aippt
VLL 14종 (또 다른 어휘)visual-layout-label/labels.ts:11-27aippt
Native path · 선례
ExtendableShapeItem nodeType 선언pipeline/common/type/pageJson.ts:298aippt
rule-only 2단계 보정 (IIS 의 rule 판 원형)custom-rlsc-type-remap-from-sheet.ts:10-59aippt
재학습 없이 유지되는지 판정하는 검증 모듈structuriser-verify/AGENTS.mdaippt
확장형 도형 텍스트 분리 (엔진)engine/converter — SplitExtendableShapeItemWithTextweb-2

⚠ 문서와 코드가 다른 곳 넷

role 어휘가 두 개다. blueprint 는 "RLSC role 추가"라고만 쓰지만, 코드에는 Role.Presentation.*(v1)과 Role.*(v2)이 공존하고 린터 유효 집합은 v2 만 쓴다. 신규 role 은 packages/structured-layout/src/role-v2.ts 에 넣어야 하고, 그건 src/ 밖의 워크스페이스 패키지 변경이다.

BigNumber 는 이미 코드에 있다 — 단 RLSC role 이 아니라 VLL Component Type 이다. 정의문이 말하는 "신규 텍스트 role BigNumber"와 같은 이름 · 다른 축이다.

MOR-1448 은 blueprint 에 없다. 2026-05-26 workstream 은 1425·1426·1427 셋이고, Layout Type 증분은 2026-07-24 논의 문서에서야 IIS 하위로 등장한다.

MORDOR 가 가리키는 엔진 SSoT 경로가 로컬 web-2 체크아웃에 없다. 추출기 주석은 신규 차트 구조의 정본을 packages/engine/node-props-schema/src/nodes/DataVizPropsSchema.ts 로 지목하지만 (types.ts:288-295), feature/mordor 브랜치 a5e7ed9(2025-12-08) 체크아웃에는 그 src 가 없고 빌드 산출물 dist/type/…/DataVizPropsSchema.d.ts 만 있다. 같은 체크아웃의 엔진 CHART_TYPE6종뿐인데 MORDOR 는 이미 10종 + UNKNOWN 을 매핑한다 — 엔진에서 먼저 늘고 MORDOR 가 뒤따르는 구조이므로, 이 표의 web-2 줄 번호는 현재 엔진 상태가 아니라 이 체크아웃 기준으로 읽어야 한다.

한 줄 결론

IIS 는 자기를 없애기 위해 존재한다

신규 기능이 생길 때마다 자체모델을 재학습하는 것은 비싸고, 방치하면 RLSC 에 정합성 공백이 남는다. IIS 는 그 사이의 제3의 경로다 — 기존 결과물을 건드리지 않고 델타만 얹어 정합성을 메우고, 그렇게 쌓인 Old→New 쌍이 곧 재학습 데이터가 되어 New Structuriser 를 만든다. New Structuriser 가 서면 IIS 는 사라진다.

코드 관점에서 남은 일은 셋이다 — rlsc_results 에 Old/New 를 어떻게 담을지 정하고 (삽입 지점 A/B), role-v2.ts 에 신규 role 을 어떤 이름으로 넣을지 정하고, structuriser-verify 의 3계층 판정을 델타 귀책으로 돌려쓰는 것. 아키텍처는 이미 확정됐고, 자리도 이미 뚫려 있다.