우리는 종종 새로운 라이브러리를 설치하고, 서버 엔드포인트를 추가하고, npm 패키지를 하나 더 얹는다. 그런데 정작 브라우저와 HTTP 스펙이 이미 준비해둔 도구는 외면해왔다. 최근 dev.to를 중심으로 세 개의 브라우저·웹 표준 API가 동시에 재조명받고 있다. Canvas API 기반 클라이언트 사이드 이미지 압축, CSS @layer, 그리고 16년 만에 등장한 HTTP QUERY 메서드다. 세 기사가 각각 다른 맥락에서 쓰였지만, 읽고 나면 하나의 메시지로 수렴한다. 우리가 복잡하게 우회했던 문제들이, 사실 플랫폼 레벨에서 이미 해결됐거나 해결되고 있다.
Canvas API로 이미지를 서버 없이 압축한다는 것의 진짜 의미
이미지 압축 이야기를 꺼내면 대부분 서버 사이드 처리나 Cloudinary 같은 SaaS를 먼저 떠올린다. 그런데 dev.to에 게재된 Canvas API 압축 기사는 다른 출발점에서 시작한다. "무료 온라인 압축 도구에 올리는 사진은 서버로 전송된다—그 이후 어떻게 되는지 당신은 모른다." 프라이버시 문제를 전면에 내세운 이 프레이밍이 인상적이다.
핵심은 HTMLCanvasElement.toBlob()이다. 이미지를 캔버스에 그린 뒤 MIME 타입과 품질 값(0~1)을 지정해 Blob으로 추출하면 끝이다. JPEG, PNG, WebP, AVIF 모두 지원한다. 실측 결과는 꽤 인상적이다. PNG를 WebP로 변환하면 평균 87% 용량 절감, JPEG를 AVIF로 변환해도 87%다. WebP는 같은 시각적 품질 기준에서 JPEG 대비 25~35% 작고, AVIF는 WebP보다 또 20~30% 작다.
여기서 놓치기 쉬운 기술적 포인트가 하나 있다. 6000×4000 픽셀 사진을 캔버스에 풀 해상도로 그리면 메모리를 70MB 이상 잡아먹는다. 이를 해결하는 스텝다운 리사이징—목표 크기의 두 배가 될 때까지 해상도를 절반씩 줄이는 방식—은 메모리 크래시를 막는 동시에 한 번에 축소할 때보다 오히려 디테일을 더 잘 보존한다. 브라우저가 이미 제공하는 API를 제대로 쓰려면 이런 실행 맥락까지 설계해야 한다.
프론트엔드 성능 관점에서 이 접근의 가치는 명확하다. 업로드 전 클라이언트에서 이미지를 압축하면 LCP(Largest Contentful Paint)에 직접 영향을 주는 이미지 전송 크기가 줄어든다. 서버 비용은 0이고, 사용자 데이터는 기기 밖으로 나가지 않는다. Core Web Vitals 개선과 프라이버시 확보를 동시에 챙기는 설계—이걸 외부 서비스 없이 브라우저 네이티브로 구현할 수 있다는 사실을 많은 팀이 아직 실감하지 못하고 있다.
!important를 내려놓게 만드는 CSS 아키텍처 변화
CSS @layer는 2022년부터 Chrome 99, Firefox 97, Safari 15.4에서 모두 지원되고 있다. 그런데 여전히 대부분의 프로젝트에서 !important와 ID 셀렉터 스태킹이 발견된다. dev.to의 해당 기사가 지적하는 핵심은 예리하다. "이건 셀렉터 문제가 아니라 아키텍처 문제가 셀렉터 옷을 입고 있는 것이다."
@layer의 작동 방식은 간단하다. 레이어 선언 순서가 캐스케이드 우선순위를 결정하고, 레이어 간에는 특이성(specificity) 계산 자체를 건너뛴다. utilities 레이어의 .hidden은 base 레이어의 section > main > article .btn보다 항상 이긴다—셀렉터 무게가 아니라 레이어 순서가 법이기 때문이다. Tailwind의 preflight나 서드파티 리셋을 낮은 레이어에 밀어 넣으면 !important 없이 내 스타일이 항상 이긴다.
흥미로운 마이그레이션 안전장치도 있다. 어떤 레이어에도 속하지 않는 언레이어드(unlayered) 스타일은 모든 명명 레이어보다 높은 우선순위를 갖는다. 기존 CSS를 건드리지 않고 서드파티 임포트부터 레이어에 집어넣는 점진적 도입이 가능한 이유다. 폴리필도 없고, 빌드 스텝도 불필요하다. 3년째 프로덕션 브라우저에서 지원되는 기능이 이제야 팀 표준으로 자리잡아야 할 타이밍이다.
16년 만의 새 HTTP 메서드가 채우는 빈자리
2026년 6월, RFC 10008로 HTTP QUERY 메서드가 표준화됐다. GET의 안전성(safe)과 POST의 바디 유연성을 동시에 가진 메서드다. 복잡한 검색 조건을 URL 쿼리스트링에 구겨 넣거나, 읽기 전용 요청에 POST를 남용하는 오랜 타협이 드디어 해결책을 얻었다.
QUERY는 명시적으로 safe이자 idempotent다. 네트워크가 끊겨도 클라이언트가 안전하게 재시도할 수 있고, 캐싱 레이어도 이 요청이 서버 상태를 바꾸지 않는다는 걸 알 수 있다. POST /orders/search, POST /users/filter 같은 관례적 우회 패턴 대신 QUERY /orders로 의도가 명확한 API를 설계할 수 있게 된다. Spring Boot, Express, FastAPI 등 주요 프레임워크의 지원은 아직 초기 단계지만, 방향은 분명하다.
세 API가 동시에 재조명받는 이유
이 세 흐름을 같이 놓고 보면 공통 패턴이 보인다. 모두 외부 의존 없이 플랫폼이 직접 제공하는 해법이고, 모두 잘못된 우회로가 만든 기술 부채를 정리한다. Canvas로 이미지를 서버 없이 압축하고, @layer로 !important 없이 캐스케이드를 설계하고, QUERY로 POST 남용 없이 복잡한 조회를 표현한다.
AI 도구로 빠르게 프로토타이핑하는 지금의 개발 흐름에서 이런 네이티브 API들은 특히 중요하다. 외부 패키지 의존성 없이 브라우저와 HTTP 스펙만으로 해결할 수 있는 영역이 넓어질수록, AI가 생성하는 코드의 복잡도도 줄어들고 유지보수 비용도 낮아진다. Cursor나 Claude로 Canvas 압축 컴포넌트를 프로토타이핑하거나, @layer 기반 디자인 시스템 보일러플레이트를 빠르게 생성하는 시나리오는 이미 충분히 현실적이다.
지금 팀에서 해볼 수 있는 것들
내일 바로 적용 가능한 순서로 정리하면 이렇다. Canvas API 이미지 압축은 파일 업로드 플로우가 있는 서비스라면 오늘 당장 클라이언트 사이드 전처리 레이어로 넣을 수 있다. 서버 부하와 LCP를 동시에 줄인다. CSS @layer는 신규 컴포넌트부터 레이어 선언을 도입하고, Tailwind preflight를 layer(reset)으로 격리하는 것부터 시작하면 된다. HTTP QUERY는 프로덕션 적용 전이지만, 신규 API 설계 문서에서 POST 남용 패턴을 마킹해두고 프레임워크 지원 시점을 모니터링할 가치가 있다.
브라우저와 웹 표준은 우리가 생각하는 것보다 훨씬 빠르게 성숙해왔다. 우리가 라이브러리를 설치하고 서버를 추가하는 동안, 플랫폼은 조용히 그 해법을 내장해두고 있었다. 지금 팀의 기술 부채 중 상당 부분은 '네이티브 API를 몰랐거나, 알았지만 쓰지 않은' 선택에서 시작됐을 가능성이 높다.