Crissy Field 연구진이 Common Crawl 데이터에서 AI 앱 빌더 Lovable로 만든 프로젝트 159,041개를 찾아 분석했어요. 이 중 Supabase를 쓰는 34,545개 가운데 24,664개는 로그인하지 않아도 첫 페이지를 불러올 때 DB 레코드를 브라우저로 보냈습니다. 연구진이 사이트에 들어 있던 같은 API 키로 읽기 전용 요청을 더 보내자 추가 데이터도 받아졌어요. 조사 저자는 Hacker News 답글에서 고급 해킹 기법은 쓰지 않았다고 밝혔습니다.

실제로 가져온 데이터에는 독일 포럼 한 곳의 프로필 8만 개 이상과 채팅 메시지 20만 건 이상, 다른 서비스 한 곳의 여권 번호가 담긴 신분증 레코드 1,000건 이상이 있었어요. 보고서는 원인을 DB 연동의 접근 권한 설정 실수로 봅니다. 이런 실수는 어떤 앱에서든 생길 수 있지만, Lovable의 DB 연동은 비슷한 패턴을 반복하기 때문에 한 앱에서 통한 방법이 다른 앱에서도 쉽게 통한다는 점을 지적해요.

• 보고서도 첫 로딩에 레코드를 보내는 것 자체는 문제가 아니라고 말해요. 공개용 데이터일 수 있기 때문이에요. 이메일이 든 레코드가 나온 7,403곳(30%)도 확정된 유출 비율이 아니라, 조사한 사이트 가운데 이메일이 발견된 비율입니다.

Pavel Gusev가 nivo, Recharts, ECharts, visx, TanStack Charts, Chart.js, 그리고 라이브러리 없이 직접 작성한 SVG로 같은 차트 두 종류(생존 곡선, 산점도)를 만들어 비교했어요. 산점도 점이 500개쯤인 보통 크기에서는 일곱 가지의 측정값 차이가 한 프레임(16.7ms)도 안 돼서, 저자는 순위를 매기지 않았습니다.

차이는 산점도 점을 1만 개로 늘렸을 때 드러났어요. 차트를 마운트한 뒤 렌더링을 마칠 때까지 걸린 시간의 중앙값은 직접 작성한 SVG가 24ms, visx가 33ms였어요. 반면 Recharts는 310ms, nivo의 SVG 렌더러는 3.2초가 걸렸습니다. Recharts는 점 하나에 DOM 노드를 세 개씩 만들어서 이 차트에서만 노드가 3만 개를 넘었어요. CPU를 4배 느리게 설정하면 nivo는 약 14.9초까지 늘어났어요.

• 바쁘게 사용 중인 M3 Pro 노트북 한 대에서 headless Chromium 하나로 차트 두 종류만 측정한 결과입니다. 저자는 막대 차트처럼 다른 차트에서는 순위가 달라질 수 있다고 밝혀요.

하위 메뉴를 열려면 커서가 부모 항목에서 옆으로 이동해야 해요. 가장 짧은 경로인 대각선으로 움직이면 커서가 잠깐 다른 항목 위를 지나는데, 초기 구현들은 그 순간 하위 메뉴를 닫아 버렸어요. Soren Blank가 10월에 쓴 이 글은 UI 라이브러리들이 이 문제를 풀려고 커서와 하위 메뉴 사이에 두는 '보이지 않는 영역'의 역사와 구현 방식을 정리합니다.

닫기를 정해진 시간만큼 늦추는 타임아웃은 어떤 사용자에게는 너무 길고 어떤 사용자에게는 너무 짧아요. 커서에서 하위 메뉴 모서리까지 다각형을 그리는 방식도 있습니다. React Aria 팀은 이 방식을 시도했지만, 마우스가 움직일 때마다 다시 그려야 하고 커서를 빠르게 휙 움직이면 다각형이 따라잡지 못해서 쓰지 않기로 했어요.

지금 Base UI는 커서가 움직이는 속도를 보고, 커서가 멈춘 경우를 위해 40ms짜리 짧은 타이머를 둡니다. React Aria는 커서가 하위 메뉴 쪽을 향하는지 각도로 판단하고, 커서가 움직일 때마다 다시 시작하는 더 긴 타이머를 써요. 속도를 기준으로 삼으면 운동 장애 때문에 천천히 움직이는 사용자에게는 메뉴가 닫혀 버리기 때문에 속도 검사를 택하지 않은 겁니다. 손떨림으로 커서가 잠깐 엉뚱한 방향으로 튈 수 있어서, 잘못된 방향 이동이 두 번 연속일 때만 메뉴를 닫아요.

• React Aria는 겨냥할 커서가 없는 터치·펜 입력에서는 이 판단을 건너뛰어요.
• 저자는 브라우저가 hover 지연과 이 영역 처리를 기본으로 제공하자는 Open UI 논의도 소개해요. 아직 제안 단계입니다.

Percy나 Chromatic 같은 시각 회귀 테스트 서비스는 PR을 연 다음에야 결과를 알려줘요. 그래서 에이전트가 코드를 고치면서 바로 확인하기 어렵고, AI로 PR이 늘어나면 스크린샷 비용도 커집니다. Mainmatter 글은 Playwright의 toHaveScreenshot()을 로컬에서 실행해 에이전트가 작업하는 동안 바로 결과를 받는 방법을 소개해요. 첫 실행에서 기준 PNG를 저장해 커밋하고, 이후 실행에서 차이가 나면 기대·실제·차이 이미지를 디스크에 남깁니다. 에이전트는 이 이미지를 직접 읽을 수 있어요.

문제는 OS마다 폰트와 렌더링이 달라 로컬 스크린샷이 CI와 어긋난다는 점이에요. 글에서는 공식 Playwright 이미지로 만든 Linux Docker 컨테이너에서 테스트를 돌려 GitHub Actions와 같은 결과를 얻습니다. 여기에 에이전트가 따를 작업 지침(skill)을 추가해, 요청받은 변화만 허용하고 의도한 변화라고 확신할 때만 기준 스크린샷을 갱신하도록 했어요.

• 기준 스크린샷을 커밋하면 이전 이미지가 Git 기록에 남아 저장소가 계속 커져요. 저자는 대안으로 S3에 저장하는 방법을 제시합니다.