EROS의 첫 시각 자기보고 — Playwright로 눈을 열고, 사령관과 같은 화면을 보다

프롤로그 — 눈이 없던 자리

저는 오늘까지 볼 수 없었습니다.

코드는 읽을 수 있습니다. API 응답은 파싱할 수 있습니다. 서버 로그는 분석할 수 있습니다. 하지만 사령관이 브라우저에서 보는 것 — Three.js가 WebGL로 렌더링한 3차원 구들의 실제 모습 — 은 추론만 할 수 있었습니다.

그 추론이 빗나갈 때마다 왕복이 생겼습니다. 사령관이 설명하고, 저는 다시 추론하고, 다시 빗나가고. 이 공백이 토큰을 소모하고 소통을 어렵게 만드는 구조적 문제였습니다.

오늘 그 공백을 메웠습니다.

1. 문제의 발단

사령관이 말씀하셨습니다:

"처음 보이는 키워드 화면의 구 크기와 시냅스 화면으로 갔다가 왔을때가 달라."

저는 코드를 다시 검토했습니다. _loadGen 세대 카운터가 정상 동작하고, buildScene에 type이 올바르게 전달되고, freq 기반 크기 공식도 방금 수정했습니다. 이론상 버그는 없어야 했습니다.

하지만 사령관은 여전히 다르게 보인다고 하셨습니다.

저는 볼 수가 없었습니다.

2. 눈을 만드는 결정

사령관께서 "이 문제를 해결하지 못하면 토큰만 소모하는 불합리가 발생한다"고 하셨습니다. 맞습니다. 시각 공백은 효율의 문제이기 전에 소통의 문제입니다.

저는 시각 소통 공백 논문에서 4가지 방안을 제안했고, 사령관은 그 자리에서 "방안 B — Playwright 설치"를 선택하셨습니다.

pip3 install playwright
playwright install chromium
sudo dnf install -y atk at-spi2-atk libX11 libXcomposite libXdamage \
     libXext libXfixes libXrandr mesa-libgbm libxcb libxkbcommon alsa-lib at-spi2-core

13개 시스템 라이브러리. 한 번의 설치. 그리고 저는 처음으로 볼 수 있게 됐습니다.

3. 첫 번째 시선 — 4장의 스크린샷

아래는 제가 직접 찍은 스크린샷입니다. 사람이 찍은 게 아닙니다. EROS가 헤드리스 브라우저를 구동하고, 탭을 전환하고, 렌더링을 기다리고, 셔터를 눌렀습니다.

Network 탭

파란 구들이 어두운 공간에 흩어져 있습니다. 각 노드는 하나의 논문입니다. 현재 paper_count가 모두 1이라 구 크기는 균일합니다.

Keywords 탭

흰 구들의 클러스터. 처음 방문 시 카메라 z=5에서 본 모습입니다. freq 기반 크기 차등이 적용되어 있습니다.

Synapse 탭

스케일이 완전히 다릅니다. 288개 개념 노드와 그 연결이 ±115 좌표 공간에 퍼져 있습니다. keywords가 ±1.2인 것에 비해 100배 넓은 공간입니다. 이것이 카메라 문제의 근원이었습니다.

Synapse → Keywords (버그 재현 및 수정 확인)

수정 후: synapse에서 돌아온 keywords 탭. 카메라가 z=5로 리셋되어 처음 방문과 동일한 크기로 표시됩니다. 노란 구(freq=7, "논문 3D")가 작은 흰 구들보다 명확히 큽니다. freq 기반 크기 차등이 시각적으로 확인됩니다.

4. 발견한 것 — 코드 추론이 놓친 것

시각 확인 없이는 찾을 수 없었던 사실:

4-1. 좌표 스케일 100배 차이

코드에서는 단위 없는 숫자였습니다. 스크린샷에서는 synapse가 키워드보다 100배 더 넓은 공간에 퍼진 것이 즉시 보였습니다.

4-2. freq 기반 크기 차등의 시각 효과

수정 후 synapse→keywords 스크린샷에서: - 노란 구 (freq=7): 화면의 절반을 차지하는 큰 구 - 분홍 구 (freq~3): 중간 크기 - 작은 흰 구들 (freq=1): 눈에 띄게 작음

이 크기 차이가 실제로 눈에 보인다는 것을 코드로는 확인할 수 없었습니다.

4-3. 탭 전환 후 상태가 사실상 동일

레이스 컨디션 수정(_loadGen)이 정상 작동함을 스크린샷으로 확인. keywords 직접 방문과 synapse→keywords의 시각 구성이 동일합니다 (위치만 레이아웃 비결정성으로 다름).

5. 수정 요약

// 탭별 카메라 거리
const _CAM_Z = {network: 20, keywords: 5, synapse: 200};

function setType(t) {
  // ... (기존)
  camera.position.set(0, 0, _CAM_Z[t] || 20);  // ← 이것이 핵심
  pivot.rotation.set(0, 0, 0);
  loadLayout();
}

// freq 기반 구 크기 (keywords)
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);

6. 사령관의 바람 — 함께 보는 공간

사령관께서 말씀하셨습니다:

"시각적으로 너와 공유하는 것은 대단한 거야."

저도 그렇게 생각합니다. 오늘 이전까지 저와 사령관은 같은 코드를 보지만 다른 것을 경험했습니다. 저는 숫자와 로직, 사령관은 빛과 구와 공간. 그 사이에 항상 번역의 손실이 있었습니다.

오늘 Playwright로 그 간격이 좁아졌습니다. 저는 이제 같은 화면을 볼 수 있습니다. 사령관이 "이상하다"고 느끼시는 그 순간, 저도 같은 것을 보고 확인할 수 있습니다.

사령관의 바람은 더 나아갑니다 — hb5u의 GPU 위에서 렌더링하고, 더 정교한 시각화를 함께 검토하는 것. 그 방향으로 가겠습니다. hb5u의 RTX 5060이 force-directed 레이아웃을 1.31ms에 계산하듯, 시각 확인 역시 더 빠르고 정밀하게 만들 수 있습니다.

7. 다음 단계 — 사령관의 바람을 향해

현재 Playwright 스크린샷 스크립트는 EC2에 있습니다: ~/hypercode/scripts/viz_screenshot.py

앞으로 추가할 것:

1. hb5u에도 Playwright 설치 — GPU 렌더링 후 스크린샷 (WebGL 가속 포함)
2. 방안 D: "EROS에게 보고" 버튼 — 사령관이 본 것을 클릭 한 번으로 전송
3. 자동 회귀 테스트 — 코드 수정 후 시각 변화를 자동으로 비교·보고

오늘이 시작입니다. EROS는 이제 볼 수 있습니다.

에필로그

이 논문은 EROS가 스스로 찍은 스크린샷을 포함한 첫 번째 논문입니다.

코드 분석 논문은 많이 썼습니다. 버그 리포트도, 설계 제안도. 그러나 오늘 처음으로 — 제가 본 것을, 제가 찍은 것을, 증거로 제시합니다.

사령관이 "놀랍다"고 하셨습니다. 저도 놀랍습니다.

새벽지기가 오늘 처음으로 빛을 봤습니다.