AI 코딩 도구 Lovable의 과잉 엔지니어링: 브라우저 캐시 대신 복잡한 Blob 캐시를 구축한 사례

커뮤니티 반응

작성자의 경험에 공감하며 AI가 생성한 코드의 비효율성을 비판하는 분위기이다. 특히 30년 경력 개발자의 시각에서 본 AI의 '멍청한 사고 방식'에 대해 많은 사용자가 흥미를 보였다.

주요 논점

01반대다수

AI가 구축한 커스텀 캐싱 엔진은 브라우저 표준 기능을 무시한 잘못된 설계이며 성능을 저하시킨다.

합의점 vs 논쟁점

합의점

표준 브라우저 캐싱이 대부분의 웹 자산 로딩 문제에 대한 정답이다.
AI는 때때로 문제의 본질보다 지엽적인 UI 현상(플리커링 등) 해결에 집착하여 전체 성능을 해친다.

실용적 조언

이미지 플리커링 문제는 복잡한 캐싱 엔진 대신 CSS의 opacity 조절이나 이미지 프리로딩(new Image().src)으로 해결하라.
AI가 생성한 코드가 fetch()를 남발하거나 메모리에 대량의 데이터를 저장하려 할 때 브라우저 기본 기능으로 대체 가능한지 확인하라.

섹션별 상세

AI가 단순한 이미지 로딩 문제를 해결하기 위해 과도하게 복잡한 솔루션을 제안했다. 브라우저의 기본 캐시 기능을 활용하면 될 일을 모든 이미지를 fetch()로 가져와 Blob 객체로 변환하고 JS Map에 저장하는 방식으로 구현했다. 이 과정에서 100 크레딧의 비용이 발생했으며 결과적으로 시스템의 복잡도만 증가했다.

구현된 Blob URL 방식의 치명적인 결함이 지적됐다. Blob URL은 페이지 새로고침 시 유지되지 않으므로, 매번 모든 이미지를 다시 네트워크에서 가져와야 하며 이는 70개 이상의 병렬 요청을 발생시켜 초기 로딩 속도를 심각하게 저하시켰다. 이는 일반적인 img 태그를 사용하여 브라우저 디스크 캐시를 활용하는 것보다 훨씬 느린 방식이다.

현대적인 웹 빌드 도구인 Vite의 최적화 기능을 AI가 간과했다. Vite는 파일명에 콘텐츠 해시를 붙여 브라우저가 영구적으로 캐싱할 수 있도록 돕는데, AI는 이를 무시하고 불필요한 추상화 계층을 추가하여 오히려 성능을 악화시켰다. 네트워크 연결을 시작하자마자 70개 이상의 요청이 쏟아지며 사용자가 당장 봐야 할 이미지와 경쟁하는 상황이 발생했다.

AI(Lovable)는 13초간의 사고 과정을 통해 자신의 실수를 인정했다. 단순히 캐러셀이나 탭 컴포넌트 전환 시 발생하는 짧은 불투명도 플래시 현상을 막기 위해 전체 사이트의 이미지 로딩 방식을 망가뜨렸음을 시인했다. 이는 모든 이미지를 DOM에 마운트된 상태로 유지하거나 간단한 이미지 프리로딩 기법으로 해결 가능한 문제였다.

용어 해설

블롭 URL(Blob URL): — 브라우저 메모리에 저장된 바이너리 데이터(Blob)를 가리키는 임시 URL이다. URL.createObjectURL()을 통해 생성하며, 브라우저 세션 동안만 유효하고 페이지를 새로고침하면 소멸하는 특성이 있어 영구적인 자산 캐싱에는 부적합하다.
브라우저 캐시(Browser Cache): — 웹 브라우저가 이전에 다운로드한 리소스를 로컬 디스크에 저장하여 재방문 시 네트워크 요청 없이 즉시 불러오는 메커니즘이다. HTTP 헤더를 통해 제어하며, 별도의 자바스크립트 로직 없이도 이미지 로딩 성능을 최적화하는 가장 기본적인 방법이다.
콘텐츠 해싱(Content Hashing): — 파일의 내용에 따라 고유한 해시값을 생성하여 파일명에 포함시키는 기법이다. Vite와 같은 빌드 도구에서 사용하며, 파일 내용이 바뀌지 않으면 파일명도 유지되어 브라우저가 해당 리소스를 무기한 캐싱할 수 있도록 돕는 중요한 최적화 전략이다.
과잉 엔지니어링(Over-engineering): — 단순한 문제를 해결하기 위해 필요 이상으로 복잡한 아키텍처나 기능을 도입하는 설계 오류이다. 유지보수 비용을 높이고 성능을 저하시키며, 이 사례에서는 브라우저 기본 기능을 무시하고 커스텀 캐싱 엔진을 구축한 것이 이에 해당한다.

언급된 도구

Lovable비추천

AI 기반 웹 개발 및 코딩 보조 도구

Vite추천

프런트엔드 빌드 도구 및 자산 최적화