위성 대 L3 실험에서 임의로 정한 것

본문 「11/27 까지 위성과 L3 중 무엇을 먼저 하나」의 동반 문서

이 실험은 「정해지지 않은 정책은 실험 쪽에서 정하고, 없는 코드는 실험용으로 구현해, 실제와 다르지만 방향은 같게 한 조건」에서 돌았다. 이 문서는 그렇게 정한 것을 모두 적는다. 항목마다 다섯 가지를 적었다.

• 무엇을 정했나
• 왜 그렇게 정했나
• 다른 선택지
• 결과를 어느 쪽으로 기울이나
• 실제 서비스에서는 누가 무엇을 정해야 하나

여기 적은 실험 코드는 모두 원격에 반영되지 않은 실험 코드다. 파일 · 함수 이름만 적는다. 레포 main 의 코드는 그렇다고 밝힌다. 프롬프트 전문은 실험 사이트 부록(https://vs-sat-l3.miridih.app 「프롬프트 전문」)에 실린다. 여기서는 핵심 문단만 인용한다.

조건 기호는 본문과 같다.

• ① 기준
• ② 위성(감점 · 가점 켬) · ②′ 위성(감점 · 가점 끔)
• ③ 현실 L3 · ④ 위성 + 현실 L3
• ⑤ 이상 L3(합성 대리)
• ①-49 · ③-49: 45종 어휘 재생성

1. 가정 목록

• A-1위성 추출
• A-2컴포넌트 제목 · 부제
• A-3위성 감점 10 · 가점 3
• A-4못 채운 위성 글 비우기
• A-5현실 L3 노출 규칙
• A-6L3 생성
• A-7이상 L3
• A-8L3 생성 어휘
• A-9다른 경계 글은 비우지 않는다
• A-10풀
• A-11⑤ 표본과 어휘
• A-12짝 선호
• A-13그림 없는 장은 BAD
• B-1–B-11추가로 정한 것

추가로 정한 것

2. 프롬프트

전문은 실험 사이트 부록 「프롬프트 전문」에 있다. 아래는 핵심 문단의 원문이다.

2-1. L3 생성 프롬프트 — V3(18종) · V1(45종)의 포함 권유 문장

두 판 모두 ## 컴포넌트 블록 절에 아래 한 줄을 싣는다.

• entity.components 는 이종 컴포넌트의 포함 관계를 적을 때만 쓴다 (아래 "이종 컴포넌트" 절).

## 이종 컴포넌트 절은 「두 모양을 구분해서 적는다. 무엇이 다른지는 시각 영역이 겹치는지로 갈린다.」로 시작한다. 그 뒤에 포함 → 병치 → 판별 순으로 이어진다.

포함 (containment)

한 컴포넌트의 시각 영역 안에 다른 컴포넌트가 들어간다. 부모 entity 아래 components 로 자식 컴포넌트를 매단다. entity 가 곧 슬롯이므로 거기 매달면 자식의 위치가 정해진다.

포함 예시는 V3 와 V1 이 자식 type 만 다르다.

# V3 (18종 — BigNumber 가 없어 HighlightedMessage)
components:
  - type: Enumeration.List
    structure:
      entities:
        - label: 1분기
          components:
            - type: TextBasedCommunication.HighlightedMessage
              structure:
                entities:
                  - { label: 매출, items: ["15억원"] }
        - label: 2분기
          components:
            - type: TextBasedCommunication.HighlightedMessage
              structure:
                entities:
                  - { label: 매출, items: ["21억원"] }
# V1 (45종) — 같은 자리의 자식이 KPIKeyMetric.BigNumber { label: 매출, value: 15, unit: 억원 }

판별

자식이 부모의 특정 항목에 속하는 내용이면 포함이다. 항목마다 반복되는 수치나 강조가 여기 해당한다. 서로 독립된 덩어리면 병치다. 한쪽을 지워도 다른 쪽이 그대로 성립하면 병치다. 겹치는 배치(overlap)는 적지 않는다. 현재 구조에서 발생하지 않는다.

• 예시와 판별 문장이 모두 「항목마다 자식」 꼴을 권한다. 공급은 86% 가 「entity 하나에 자식 하나」다.
• 병치 절 길이는 판마다 다르다(V3 2,468자 · V1 428자). V3 병치 절에는 「이 레벨에서는 넓은 그릇을 좁은 종으로 연다」 같은 형제로 떼라는 지시가 더 있다. 포함 절은 V3 770자 · V1 740자로 거의 같다.
• V1(병치 절이 짧은 판)에서도 L3 형이 2/399 였다. 그래서 「V3 병치 절이 포함을 밀어냈다」만으로는 설명이 안 된다(해석).

2-2. 위성 제목 덧붙이기 프롬프트 (A-2, 시스템 프롬프트 전문)

너는 시각 요약(Visual Summary) 문서의 각 컴포넌트에 붙일 제목과 부제를 정한다.
입력: 원문과, 그 원문으로 이미 만든 시각 요약 문서(JSON, 컴포넌트 목록).
할 일: 컴포넌트마다 그 컴포넌트를 슬라이드 한 덩어리로 보여 줄 때 위에 얹을 짧은 제목(title)과, 있으면 좋은 한 줄 부제(subtitle)를 정한다.
규칙:
- 원문의 언어를 따른다. 원문에 있는 말을 우선 쓰고, 없는 사실을 지어내지 않는다.
- title: 20자 안팎의 명사구. 컴포넌트가 하나뿐이면 문서 title 과 같거나 비슷해도 된다.
- subtitle: 원문에 그 컴포넌트를 설명하는 짧은 문장·기준·단위·출처가 있을 때만 40자 안팎으로. 없으면 null.
- 컴포넌트 안의 항목(entity) 글을 그대로 되풀이하지 않는다.
- 문서의 다른 칸은 바꾸지 않는다. 제목·부제만 낸다.
출력(JSON 하나): {"components": [{"index": 0, "title": "...", "subtitle": "..." 또는 null}, ...]} — 입력 컴포넌트 수와 순서 그대로.

사용자 메시지는 「원문: … / 시각 요약 문서(JSON): …」다. 규칙에 「항목 글을 되풀이하지 않는다」가 있는데도, 사람 검수 대체에서 「같은 글 두 번」 결함이 5장 나왔다. 컴포넌트가 하나뿐이면 「문서 title 과 같거나 비슷해도 된다」는 규칙이 본문 첫 글과 겹치는 경우가 있는 것으로 보인다(해석).

2-3. L3 유리 원문 생성 프롬프트 (가상 원문 50)

포함 DO 의 구조(바깥 · 안쪽 표현, 항목 수, 칸 종류)를 주고 그 구조에 맞는 원문을 쓰게 했다. 모델은 gpt-5.6-luna · medium 이다. 핵심 규칙 원문은 아래와 같다.

3. 구조가 원문에서 뚜렷이 드러나야 한다: - 바깥 항목 수와 각 항목의 제목이 분명하다(번호 · 소제목 · 줄바꿈). - 안쪽 표현이 그 바깥 항목 안에 속하는 내용으로 쓰인다(그 항목의 수치, 그 항목의 단계, 그 항목의 강조문, 그 항목의 인용 등). 다른 항목으로 떼어 놓으면 뜻이 깨지게 쓴다. - 안쪽 항목 수도 구조와 같게 맞춘다. 수치 칸은 실제 숫자 + 단위로, 시점 칸은 연도 · 날짜로 쓴다.
4. … 구조를 설명하는 낱말(「바깥 항목」 · 「안쪽 표현」 · 「조직도 1개」 · 「하위 1」 · 컴포넌트 이름 등)은 원문에 쓰지 않는다. 원문은 내용만 담는다.

• 실명 · 실존 회사는 쓰지 않게 했다(「김OO 팀장」 · 「A사」 꼴).
• 구조 낱말이 원문에 새어 나온 것은 0건이다.
• 원문이 구조를 아는 LLM 의 글이라 「핵심 수치: 85% …」 같은 줄 머리말이 자주 보인다 → L3 에 유리하다.

2-4. 짝 선호 판정 프롬프트 (A-12)

당신은 프레젠테이션 시각화 품질 평가자다. 사용자가 쓴 원문 하나와, 그 원문을 슬라이드 한 장(또는 이어지는 몇 장)으로 시각화한 결과 두 개(장 A, 장 B)를 본다. 두 결과 가운데 원문을 더 잘 시각화한 쪽을 고른다.

보는 것: 내용(빠짐 · 틀림 · 지어냄) · 구조(묶음 · 순서 · 위계 · 비교 관계) · 읽힘(잘림 · 겹침 · 넘침) · 완결(빈 자리 · 임시 문구 · 무관한 글). 보지 않는 것: 색, 그림 · 사진 · 장식의 취향, 장 전체의 여백과 배치 취향, 장 제목 유무.

차이가 작거나 한쪽이 낫다고 말할 근거가 분명하지 않으면 same 이다. 답 형식: JSON {"answer": "A" | "B" | "same", "reason": "한 문장"}.

(위 「보는 것」 줄은 원문의 네 항목을 한 줄로 줄인 것이다. 원문 전문은 사이트 부록에 있다.)

• 「장 제목 유무」를 보지 않게 했다. 위성 제목 칸이 생긴 것만으로 ② 가 이기지 않게 하려는 것이다.
• 그래도 제목 칸 때문에 글 배치가 달라진 효과는 판정에 들어간다.

3. 정책

4. 결과에 쓰지 않은 것 · 확인하지 못한 것

• 감점 값 사다리(×0.5 · ×2)는 돌리지 않았다. 켬 · 끔 두 점뿐이다.
• 위성 비우기가 E3 결함을 늘린 몫과, 감점이 그것을 막은 몫은 감점 유무만 다른 비교에서 나온 해석이다. 셀 근거를 다 열어 보지는 않았다.
• 나눠 담기(threading)에서 위성 제목이 쪽마다 어떻게 반복되는지는 따로 재지 않았다.
• 글자가 든 도형은 위성 규칙상 deco 로 가서 frame 에 오르지 않는다. 그 수는 세지 않았다.
• 사람 검수 대체 40장은 에이전트 판정이다. 사람 판정으로 확정하지 않았다.

5. L3 조합(⑤ 합성기)

실험 코드는 compose-l3.ts 다(원격 미반영).

5-1. 알고리즘

1. 부품 만들기. L3 형 문서마다 질의를 둘로 나눈다.
   • 부모 질의: 자식을 뗀 컴포넌트, 문서 title 유지.
   • 자식 질의: 자식 컴포넌트마다 L1 문서, title = 그 entity label.
   • 둘 다 ② 와 같은 서버 · 풀 · 대치 규칙으로 검색해 1위 장을 대치 · 렌더한다(부품 11장, 실패 0).
2. 부모 장에서 entity 상자 찾기.
   • label 바인딩(글이 같은 것, 없으면 깊이 0 label 순번)으로 entity 의 unit 을 찾는다.
   • 그 unit 에 묶인 RLSC 잎 노드 전부의 렌더 bbox 합집합을 구한다(루트 그룹 기준, 중간 그룹 오프셋을 더함).
3. 변형 A · B.
   • A(strict): 2 의 합집합 그대로.
   • B(넓힘): 폭은 entity 상자 중 가장 넓은 폭, 높이는 아래 이웃 entity 위까지. 마지막 entity 는 줄 간격만큼만 늘린다.
4. 자리 비우기.
   • 그 unit 의 label 말고 글 노드(items · value)를 지운다.
   • 자식 자리는 label 아래와 오른쪽 중 넓은 쪽이다. 그 영역이 상자의 20% 미만이면 상자 전체를 쓴다.
   • 자식이 여럿이면 세로로 나눈다.
5. 축소 · 배치.
   • 자식 장 루트 그룹(w × h)을 s = min(Rw/w, Rh/h) 로 줄인다.
   • 모든 후손의 bbox · tightBoundingBox · curveBoundingBox 에 s 를 곱한다. props.text.textTree 의 fontSize · letterSpacing 에도 s 를 곱한다(TextItem 과 도형 글 모두). LineItem 두께도 같다.
   • 가운데에 놓고, 부모 루트 그룹의 맨 위(마지막 자식)로 넣는다.
6. 판정. 합성 장 JSON 을 판정 CSV 한 행으로 내고, 같은 원문의 ② 장과 짝 선호로 비교한다.

5-2. 변형 A · B 의 차이와 축척

5-3. 남은 약점

• entity label 중복. 자식 질의 title 을 entity label 로 두었다. 그래서 자식 장 맨 위에 부모 label 과 같은 글이 한 번 더 나온다.
• 자식 배경 사라짐. 장 바탕색은 장 데이터에 있어 따라오지 않는다. 자식은 투명 바탕으로 얹힌다.
• 크기. 부모 entity 상자는 원래 짧은 글 크기라 자식이 아주 작아진다.
• 내용 · 상자. 짝 선호 사유에 내용 누락 · 깨진 상자가 있었다.
• 넷 모두 ⑤ 를 불리하게 기울인다.

5-4. 실제 조합 설계라면 필요한 것 (제안)

• 크기 하한. 자식 글이 읽히는 최소 축척(또는 최소 글자 크기)을 정하고, 그 아래면 포함 대신 병치로 내린다.
• 위계. 부모 label · 자식 제목 · 자식 본문의 글자 크기 순서를 정한다. 같은 글이 두 번 나오지 않게 자식 제목 규칙을 정한다.
• 레이아웃 재배치. 부모 entity 상자를 자식이 들어갈 만큼 키우고, 이웃 entity 를 다시 배치한다. 지금처럼 부모 장을 고정한 채 줄여 넣는 방식으로는 하한을 지키기 어렵다.
• 배경 · 장식. 자식 장의 바탕과 카드 테두리를 가져올지 정한다.
• Page Layout DB. entity 칸마다 들어갈 수 있는 자식 크기 · 종횡비를 미리 알아야 한다. 로드맵의 09 Page Layout DB 가 이것을 담는 자리이고, 05 조합 단계가 그것을 쓴다.
• 이 다섯이 L3 조합 포함의 작업량을 「대」로 만든다(본문 1-2).