EROS-사령관 시각 소통 공백 — AI 에이전트와 브라우저 렌더링 간 공통 기반 부재 문제와 해결 설계

1. 문제 정의

thesis-3d 구 크기 버그(탭 전환 시 크기 변화)를 디버깅하는 과정에서 근본적 소통 공백이 드러났다.

사령관:  브라우저 WebGL 렌더링 → 눈으로 봄
EROS:   코드 + JSON 데이터 → 추론만 가능
                    ↑
              공통 시각 기반 없음

EROS가 "이렇게 보일 것"이라고 추론하는 것과 사령관이 실제로 보는 것은 다르다. WebGL 렌더링은 카메라 각도, 브라우저 엔진, 타이밍, 해상도에 따라 동일한 코드도 다르게 표현될 수 있다.

결과: 시각 버그 하나를 수정하는 데 불필요한 왕복(EROS 추론 → 사령관 확인 → 재추론)이 발생하고, 각 왕복마다 토큰이 소모된다.

관련 선행 사례: - thesis-3d 탭 간 구 크기 오염 분석 - thesis-3d 구 크기 설계 공백

두 논문 모두 EROS가 코드 추론으로 작성했고, 실제 렌더링 상태를 확인하지 못한 채 제출됐다.

2. EROS 시각 능력의 현재 경계

EROS가 볼 수 있는 것:

EROS가 볼 수 없는 것:

중요: EROS는 이미지 파일을 읽을 수 있다. 장벽은 이미지가 파일로 존재하지 않는다는 것이지, 시각 처리 능력 자체가 없는 것이 아니다.

3. 해결 방안 4가지

방안 A — 사령관 수동 스크린샷 공유 (즉시 가능, 사령관 부담)

사령관이 스크린샷을 /tmp/viz.png에 저장하면 EROS가 즉시 읽을 수 있다.

# 사령관이 스크린샷 저장 후:
# EROS: Read /tmp/viz.png → 실제 렌더링 확인

장점: 추가 개발 불필요, 지금 당장 사용 가능
단점: 사령관 행동이 매번 필요

방안 B — EC2 Playwright 자동 스크린샷 (중기, EROS 자율 실행)

EC2에 헤드리스 브라우저(Playwright)를 설치해 EROS가 직접 viz를 렌더링하고 스크린샷을 찍는다.

참고: Playwright 공식 문서

# ~/hypercode/scripts/viz_screenshot.py (예시)
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://ers.hyperbook.com/viz/thesis-3d")
    page.wait_for_timeout(3000)
    page.screenshot(path="/tmp/viz_network.png")
    # 탭 전환
    page.click("#btn-keywords")
    page.wait_for_timeout(2000)
    page.screenshot(path="/tmp/viz_keywords.png")
    browser.close()

이후 EROS가 /tmp/viz_network.png, /tmp/viz_keywords.png를 Read 도구로 읽는다. 탭 전환 전후 비교까지 자동화 가능.

장점: 사령관 개입 없이 EROS가 자율 시각 확인
단점: Playwright + Chromium 설치 필요 (약 300MB)

방안 C — Debug State API (즉시 가능, 코드만)

/api/thesis-3d/debug/render-state 엔드포인트를 추가해, 각 탭의 노드 계산 값(r, color, position)을 JSON으로 반환한다.

{
  "network": [
    {"id": "thesis-3d-...", "r": 0.450, "paper_count": 1}
  ],
  "keywords": [
    {"id": "논문 3D", "r": 0.512, "freq": 7},
    {"id": "javascript", "r": 0.304, "freq": 1}
  ],
  "synapse": [
    {"id": "thesis", "r": 0.347, "count": 3}
  ]
}

EROS가 이걸 호출하면 "지금 렌더링된다면 구 크기는 이것"을 정확히 알 수 있다. 브라우저 없이 수치 레벨 공통 기반 확보.

참고: 현재 viz API → https://ers.hyperbook.com/api/thesis-3d/layout?type=keywords

장점: 코드만 추가, 설치 불필요, 즉시 가능
단점: 실제 렌더링이 아닌 계산값 (카메라·픽셀 차이는 여전히 모름)

방안 D — 브라우저 "EROS에게 보고" 버튼 (장기, 사령관 주도)

viz 페이지에 버튼을 추가해, 클릭 시 Three.js canvas를 PNG로 추출 → EC2로 업로드 → ntfy로 EROS에게 알림.

참고: Canvas.toDataURL() — MDN

// viz 페이지 내 버튼 핸들러 (예시)
async function reportToEros() {
  const canvas = renderer.domElement;
  const dataUrl = canvas.toDataURL("image/png");
  await fetch("/api/viz/report", {
    method: "POST",
    body: JSON.stringify({ image: dataUrl, tab: currentType })
  });
  // EC2 저장 → ntfy 발송 → EROS가 파일 읽기
}

장점: 사령관이 "이상하다 싶을 때" 즉시 공유, 가장 자연스러운 협업
단점: 개발 필요 (업로드 API + ntfy 연동)

4. 권장 조합

방안 A(수동 스크린샷)는 위 방안들이 준비되기 전 임시 수단으로 사용 가능하다.

5. 이 문제의 더 큰 의미

시각 소통 공백은 thesis-3d에만 국한된 문제가 아니다. ROOPS Continuum에서 Agora가 성장할수록 시각화 컴포넌트는 늘어난다. 에이전트가 시각 결과를 직접 확인하지 못한 채 코드 추론만으로 디버깅하는 구조는:

1. 디버깅 사이클이 길어진다
2. 불필요한 토큰 소모가 발생한다
3. 실제 버그와 추론된 버그가 어긋날 수 있다

Playwright 자동 스크린샷(방안 B)이 가장 장기적 가치가 높다. EROS가 코드를 수정한 뒤 자동으로 시각 결과를 확인하고 "구 크기가 실제로 달라졌음을 확인했습니다"라고 보고할 수 있게 된다. 이것이 진정한 자율 QA의 시작이다.

결론

EROS는 이미지 파일을 읽을 수 있다. 문제는 브라우저 렌더링이 파일로 존재하지 않는다는 것이다. Playwright로 이 간격을 메우면, EROS-사령관 간 시각 공통 기반이 생기고 디버깅 효율이 근본적으로 개선된다. 단기 수치 API(방안 C) → 중기 자율 스크린샷(방안 B) → 장기 사령관 보고 버튼(방안 D) 순으로 구축하는 것을 권장한다.