바로가기 개요 ⓪ AS-IS → TO-BE 카테고리 개편 ⓪-2 카테고리 타입별 공급량 비교

바디 컴포넌트 카테고리별 공급 진단

Component Type 17종 × 사이즈 × 블록수 × visual_focus · build_supply_data.py로 실서버에서 재생성

막대·셀에 마우스를 올리면 상세값이 나옵니다. 왼쪽 메뉴에서 세부 페이지로 이동하세요.
⓪ AS-IS → TO-BE 카테고리 개편
구 카테고리(categories, 소문자 snake_case 13종) → 신 Component Type(PascalCase 17종). 상세 기준은 category_classification.md
가장 큰 변화 3가지
1
grid 하나 → 5종으로 세분화
이전에는 "나열형"이면 전부 grid 한 카테고리였다. 이제는 정보 구조에 따라 List · RadialList · BigNumber · Takeaway · QuoteTestimonial 5종 중 하나로 더 정확하게 분류된다.
2
grid_with_images 타입 자체를 없앰
"이미지가 들어간 것"은 더 이상 별도 타입이 아니다. 각 타입 안에서 visual_focus=Image 속성 하나로 표현한다 — 타입과 속성을 섞어 쓰던 것을 분리했다.
3
circular_list → RadialList로 통합
가운데 하나를 중심으로 퍼지는 hub&spoke 형태도 결국 방사형 나열이라, 별도 타입을 만들지 않고 RadialList에 함께 묶었다.
⓪-2 카테고리 타입별 공급량 비교 — AS-IS vs TO-BE
AS-IS = data/body_key.csv(2026-07-27 export, 재태깅 전 구 categories) status=ACTIVE –건 · TO-BE = 프로덕션 Postgres bodies ⋈ masters(body_id) WHERE masters.page_role IN ('Role.Page.Content','Role.Page.NoUse') AND bodies.status='active' (조회일 2026-08-11) –건 — 같은 바디로 매칭하지 않고, 각 시점의 active 모집단을 독립적으로 집계
전체 active 바디 증감
–
–
AS-IS (구 카테고리, 2026-07-27) TO-BE (신 Component Type, 2026-08-11)
AS-IS 분포 (14종 — 13종 + 미분류)
TO-BE 분포 (17종)
바로가기 ★ maxCandidates 조작 ① 타입 불일치 확률 ①-2 타입별 후보수 분포 ①-3 보완 필요 수량
★ maxCandidates 조작 — 운영값을 바꿔가며 타입별 영향 확인
프론트는 백엔드가 넘긴 후보 풀에서 균등 랜덤으로 1개를 뽑는다. 풀 maxCandidates칸을 요청 타입으로 다 못 채우면 남는 칸은 등급 6(타입 불일치)이 채우고, 그만큼 다른 타입이 렌더될 확률이 생긴다.
10
전체 평균 타입 불일치 확률
–
모든 타입·프레임 균등 가중
타입 불일치 확률 30% 이상 타입
–
17종 중 — 3회 중 1회 이상 엉뚱한 타입
보완 필요 수량 합계
–
전 타입이 풀을 채우게 하는 최소 추가 건수
트레이드오프 — 슬라이더를 낮추면 타입 불일치 확률은 즉시 내려가지만, 풀이 작아지는 만큼 같은 바디가 반복 노출될 확률이 올라간다(세션 내 다양성 저하). 열린 논점 (n) maxCandidates 5 vs 10이 바로 이 균형점을 찾는 문제다.
① 타입 불일치 확률 — 그 타입을 골랐을 때 다른 타입이 렌더될 확률
1 − 평균( min(요청타입 후보수, maxCandidates) ÷ maxCandidates ) · 후보수는 등급 1~5(top-1 일치 + top-2·3 일치) 중 사이즈가 맞는 전량
연한 바 = top-1 태깅만 셀 때 (참고용, 과대추정) 진한 바 = 실제 오타율 (top-2·3 구제 반영) 회색 = 오타율 0 (문제 없음)
①-2 타입별 후보수 분포 — 풀을 채울 재고가 있는가
Content 프레임 1,252개 각각에서 "사이즈가 맞는 이 타입 후보가 몇 개 있는지" 센 뒤, 후보가 적은 프레임부터 많은 프레임까지 줄 세웠다. 회색 막대 = 대부분(80%) 프레임이 속하는 범위, 점 = 딱 중간(중앙값)인 프레임의 후보 개수. 붉은 선 = 지금 설정된 풀 크기(maxCandidates)
점(대표 프레임)이 붉은 선보다 왼쪽이면 절반 이상의 프레임에서 풀을 못 채운다 = 구조적 공급 부족. 회색 막대의 오른쪽 끝(후보 많은 쪽 10%)까지 왼쪽이면 어떤 프레임에서도 못 채운다는 뜻.
①-3 보완 필요 수량 — 몇 개를 어떤 크기로 만들면 되는가
현재 maxCandidates 기준. 추가 바디를 – 이하로 만들면 Content 프레임의 95%에 들어가므로, 그 프레임군의 최소 후보수를 maxCandidates까지 끌어올리는 개수
보완 필요 수량 0 = 이미 모든 프레임에서 풀을 채운다. 이 표가 곧 디자인팀 요청서다 — 타입 · 개수 · 최대 크기 · 블록수가 다 들어있다.
바로가기 ③ Information Type 비중 ④ 바디 사이즈 커버리지 ⑤ 타입×블록수 히트맵 ⑥ 타입×블록수 공급 분포 ⑦ 타입×visual_focus 분포
③ Information Type(대분류)별 공급 비중
미태깅 260건 포함, 검색 풀 1,473건 기준
Enumeration이 717건(49%)으로 압도적이고, Hierarchy는 54건(3.7%) · Highlight는 37건(2.5%)뿐이다. 미태깅 260건은 그 자체로 Sequence 전체(262건)와 맞먹는 규모라, 태깅 작업만 마쳐도 이 분포가 크게 바뀐다.
④ 바디 사이즈 → 커버 가능한 Content 프레임 %
보충 스펙 산출 기준. 어떤 크기로 만들면 몇 %의 프레임에 들어가는가
모든 타입이 1,100 × 480 이하 변형을 최소 1개씩 가지면 프레임의 94.2%를 커버할 수 있다. 반면 1,650×640처럼 큰 규격은 28%밖에 못 덮는다 — 지금 Versus의 최소 규격이 1,598×447(커버 71%)에 머물러 있는 것도, Staircase가 1,549×527(74%)인 것도 이 때문이다.
⑤ 타입 × 블록수 — '타입 유지' 커버리지 %
top-1 일치 & 사이즈 fit & 블록수 일치 후보가 1개 이상인 프레임 비율. 낮을수록 등급 2 이하로 추락(내용 누락·재생성)
  • 사선 해칭 = 조치 필요 — 이 블록수 조합은 의미상 성립하는데 커버리지가 50% 미만이다.
  • 회색 N/A = 애초에 의미상 성립하지 않는 조합이다(SWOT·Quadrant는 블록 4개 고정, Versus는 2개 중심). 공급도 0건이라 문제로 취급하지 않는다. 단, 범위 밖이어도 실제 공급이 있으면 N/A 대신 수치를 그대로 보여준다.
  • Pyramid 블록5 · NestedScope 블록5 · Cycle 블록6 · Takeaway 블록2는 공급이 0건이라, 사이즈를 아무리 맞춰도 커버리지가 100% 추락한다.
⑥ 타입 × 블록수 공급 분포
블록수는 순서 있는 값이라 단일 색 순차 램프(연함→진함). List(572건)는 스케일 지배로 제외
Transformation·Versus는 공급이 블록 2개짜리에 몰려있어 3개 이상을 비교해달라는 요청을 받을 수 없다. Pyramid·Quadrant·SWOT·Staircase·NestedScope·Cycle은 블록 5~6개짜리 공급이 전혀 없다.
⑦ 타입 × visual_focus 분포
다중 태깅 전개, 타입 내 비율(%). List 제외
  • Comparison·Hierarchy 계열은 Plain(강조 없음)에 치우쳐 있다 — Versus 24건 중 18건, Quadrant 23건 중 17건, HierarchicalTree 15건 중 10건, Pyramid 30건 중 15건이 Plain이다. CLAUDE.md에 적힌 "강조 평탄화" 문제가 이 데이터에 그대로 드러난다.
  • 반대로 NestedScope는 9건 중 8건이 Metric(수치 강조)에 쏠려 있어, Plain 표현을 요청하면 고를 대안이 거의 없다.
표로 보기 — 타입별 전체 수치 (현재 maxCandidates 반영)
타입 불일치 확률%이 헤드라인 지표 — 30% 이상은 붉게 표시된다.
  • 풀미달% — 풀 maxCandidates칸을 다 못 채우는 프레임의 비율
  • 완전소실% — 후보가 0개인 프레임의 비율
  • 후보수 — 프레임 1개당 요청 타입 후보 개수의 분위수(p10/중앙/p90)
  • 밴드미달% — 타입은 맞지만 프레임보다 작아서 등급 3으로 떨어지는 비율
밴드미달%이 높은데 소실%은 낮은 Takeaway(36.3%)·HierarchicalTree(22.8%)는 공급 문제가 아니라 밴드 정책 문제다 — 타입별 scaleToleranceRate 검토 대상(열린 논점 g).