thesis-3d 구 크기 설계 공백 — 레이스 컨디션 수정 이후 남은 freq 미반영 버그 분석

초록

이전 세션(2026-07-08)에서 thesis-3d 탭 간 구 크기 오염 문제를 JavaScript 비동기 경쟁 조건으로 진단하고 _loadGen 세대 카운터로 수정했다. 그러나 수정 이후에도 사령관은 탭 간 구 크기가 별도로 관리되지 않는 인상을 받았다. 본 논문은 그 이유를 추가 분석하여 레이스 컨디션과는 독립적인 설계 공백이 존재함을 보인다.

1. 이전 수정 검증

_loadGen 세대 카운터 수정은 라이브 HTML에 정상 반영되어 있다. 레이스 컨디션 버그 자체는 올바르게 수정되었다.

2. 실데이터 분석 — 구 크기 공식 vs 실제 값

network 탭

paper_count 값: 전 노드 1

공식: r = Math.max(0.4, paper_count * 0.15 + 0.3) 실제: paper_count = 1 → r = 0.45 (모든 노드 동일)

network 탭의 각 노드는 논문(paper) 자체이므로 paper_count=1이 맞다. 그러나 결과적으로 모든 구가 같은 크기가 된다.

keywords 탭

freq 값: 7, 1, 1, 3, 2 (다양함)

공식: r = 0.3 (type !== "network"이면 무조건 고정) 실제: freq 데이터가 있음에도 사용하지 않음.

synapse 탭

공식: r = Math.max(0.25, Math.log1p(n.count || 1) * 0.25) count를 실제로 사용. 가변 크기 ✅

비교표

3. 버그 분류

버그 A (기수정): 레이스 컨디션

• 원인: buildScene이 전역 currentType을 await 이후 읽음
• 수정: _loadGen + 조기 캡처 + 폐기 검사
• 상태: 수정 완료

버그 B (신규 진단): keywords freq 미반영

• 원인: buildScene 내 type !== "network"이면 r = 0.3 고정. freq 필드가 존재하지만 공식에 연결되지 않음
• 현상: keywords 탭에서 빈도 높은 키워드(freq=7)와 낮은 키워드(freq=1)가 동일한 구 크기로 표시
• 범주: 점진적 기능 추가 시 발생하는 설계 누락 — synapse 탭 추가 시 else = 0.3 분기를 단순화하면서 keywords의 freq 반영 경로를 누락

4. 두 버그의 관계

두 버그는 독립적이다.

• 레이스 컨디션은 탭 전환 타이밍 문제 → 비동기 제어로 해결
• freq 미반영은 buildScene 공식 자체의 문제 → 공식 수정으로 해결

전자를 수정해도 후자는 남는다. 사령관이 수정 이후에도 "아직 별도 관리처럼 보이지 않는다"고 느낀 이유가 이것이다.

5. 수정 방안

// 수정 전
const r = type === "network"
  ? Math.max(0.4, (n.paper_count || n.freq || 1) * 0.15 + 0.3)
  : 0.3;

// 수정 후
const r = type === "network"
  ? Math.max(0.4, (n.paper_count || 1) * 0.15 + 0.3)
  : Math.max(0.2, Math.log1p(n.freq || 1) * 0.15 + 0.2);

Math.log1p를 사용해 freq=1일 때 r≈0.30, freq=7일 때 r≈0.49로 완만하게 스케일링한다.

6. EROS 자기 비판

이전 논문에서 레이스 컨디션만 진단하고 buildScene 내 크기 공식 자체를 검토하지 않았다. 실데이터 확인이 먼저였다.

진단의 완전성 원칙: 공식의 존재 확인 외에, 공식에 실제 데이터가 연결되는지까지 검증해야 한다.

결론

thesis-3d 탭 간 구 크기 문제는 두 개의 독립적 버그로 구성된다. 레이스 컨디션(버그 A)은 이미 수정됐고, freq 미반영(버그 B)은 buildScene 공식 한 줄 수정으로 해결된다. 버그 B는 사령관이 수정 이후에도 "아직 별도 관리처럼 보이지 않는다"고 느낀 실질적 원인이다.