요소 생성·대치의 큰그림. 모양(sheet json)을 고치고, 의미(RLSC)로 판단하고, 테마에 맞춘다 — 이 세 축이 어디서 만나는지를 데이터 층 · 서버 · 클라이언트 런타임 순으로 편다.
하나의 디자인이 세 가지 표현으로 동시에 존재한다. 그리는 것은 모양, 판단하는 것은 의미, 색을 맞출 곳은 테마다.
structure_json
저장소마다 이름이 다르다 — 엔진은 PageData/PageJson,
iui 는 Doc/Sheet, MORDOR 는 느슨한 PageJson
(pipeline/common/type/pageJson.ts:314).
상속 관계가 아니라 각자 필요한 필드만 다시 선언한 것이라 구조적으로 호환되어 그냥 넘겨 쓴다.
자세한 해부는 sheetJson 해부도.
comp-sign 시그니처(structureHash)로 후보를 검색하고 하나를 고른다.
서버가 돌려주는 것은 후보키와 파일 URL이고, 큰 컬럼은 브라우저가 따로 받아 온다.
export async function resolveCandidates(matched: MatchedCandidate[]) { return Promise.all(matched.map(async (c) => { const [textMap, textNodeRoles] = await Promise.all([ fetchSignatureJson<TextMap>(c.textMapUrl), fetchSignatureJson<TextNodeRoles>(c.textNodeRolesUrl), ]); return { componentKey: c.componentKey, variant, textMap, textNodeRoles, ... }; })); }
이 payload 가 §3의 입력이 된다. 서버·브라우저 경계의 전체 지도는 web-2 역할 분담.
생성과 대치가 같은 경로를 쓴다. 코드가 실제로 부르는 순서는 아래와 같다.
원본 도식은 role 폰트 → 내용 → 스타일 → 이미지 였지만,
코드는 내용(:108) → role 폰트(:110) → 스타일(:116) → 이미지(:129) 다.
폰트 주입이 contentMappedSheetJson 을 입력으로 받으므로 순서가 뒤바뀔 수 없다.
여기가 도식과 코드가 가장 크게 갈리는 곳이다. "Style Meta 에 맞춘다"는 두 개의 서로 다른 구현을 하나로 뭉뚱그린 서술이었다.
| A. 내용시각화 (이 흐름) | B. AI 프레젠테이션 | |
|---|---|---|
| 진입 | TemplateStyleMapper.getMappedStyles | applyColorMapping |
| 테마 출처 | 런타임 추출 — getTemplateV2ByIdx 로 템플릿 페이지를 받아 buildColorProfile() | 오프라인 파일 — getTemplateStyleMetadata → styleMetadataFileUrl fetch |
| 테마 타입 | ColorProfile = { groups } | ThemeRegistry |
| 적용 함수 | recolorComponent(profile, targetBgHex, sheet) | 같은 iui 패키지의 색 매핑 |
| Component RLSC | 쓰지 않는다 — 계약 호환용으로 받기만 한다 | — |
| 캐시 | StyleMapperMemoryCache (최대 20) | fetch 결과 |
/** * 현재 페이지의 template 테마를 기반으로 매핑된 스타일을 반환 * @param _componentRlsc - 상위 StyleMapper 계약 호환을 위해 받지만 * recolor API에서는 사용하지 않음 */ public override async getMappedStyles( componentDoc: PageJson, _componentRlsc: StructuredContent, // ← 밑줄 = 미사용 componentOriginId?: number, )
v2 8단계는 이 경로가 아니다
mapComponentToThemeV2(slots → keys → Visual Tree → features → candidates →
scorer → Hungarian → apply)는 실재하지만
(v2/index.ts:8-15),
miricanvas-web-2 어디에서도 부르지 않는다.
현재 사용처는 iui 저장소 안의 문서와 평가 스크립트(scripts/style-mapper-eval.ts 등)뿐이다.
런타임이 실제로 쓰는 것은 같은 패키지의
recolor.ts:3181 recolorComponent 이고,
테마는 recolor.ts:1849 buildColorProfile 이 만든다.
v2 는 다음 세대이고, 지금 프로덕션은 recolor 다.
| 단계 | 파일 · 줄 | 저장소 |
|---|---|---|
| 4단계 오케스트레이션 | buildMappedComponentSheetJson.ts:91-138 | web-2 |
| 1 · 내용 대치 | buildSignatureMappedSheetJson.ts | web-2 |
| 2 · role 폰트 | _utils/ApplyRoleFontsToTextNodes.ts | web-2 |
| 3 · 스타일 대치 | TemplateStyleMapper.ts | web-2 |
| 3-내부 · recolor | color-mapper/recolor.ts:3181 | iui |
| 3-내부 · 테마 추출 | color-mapper/recolor.ts:1849 | iui |
| 3-차세대 · v2 8단계 | color-mapper/v2/index.ts:88 미사용 | iui |
| 4 · 이미지 대치 | replaceComponentImages.ts | web-2 |
| AIP 테마 경로 | style_replacement/colorMapping.ts | web-2 |
| RLSC 생산 | pipeline/common/type/pageJson.ts:314 | aippt |
대치 3종(내용 · 스타일 · 이미지)은 전부 모양(sheet json)을 고친다. 판단 근거는 의미(RLSC) — 단 검색·폰트·이미지 게이트에서만이고, 색 재배정에는 들어가지 않는다. 색의 목적지는 현재 템플릿에서 추출한 ColorProfile 이다.