격주로 새 버전이 나오는 브라우저 시대 — Chrome 153, 2주 릴리스 주기가 크로스브라우징 QA에 묻는 것

퍼블리셔로 일할 땐 매달 정해진 루틴이 하나 있었어요.

새 브라우저 버전이 나오면 호환성 표를 열고 체크박스를 하나씩 채우고, 깨진 레이아웃이 보이면 회귀 목록에 올리는 일.

그 주기는 대체로 한 달이었어요.

크롬이 한 달에 한 번, 파이어폭스도 비슷하게 움직였으니까요.

그 “한 달”이라는 전제가 이번 달부터 흔들렸어요.

Chrome이 153 버전부터 메이저 릴리스 주기를 4주에서 2주로 줄였어요. 153은 2026년 9월 8일에 데스크톱·안드로이드·iOS로 순차 배포됐고, 다음 154는 2주 뒤인 9월 22일 예정이에요.

구글이 든 이유는 대충 이래요.

한 릴리스에 담기는 변경이 작아지니 문제가 생겨도 원인을 좁히기 쉽고, 배포 위험이 분산되고, 빠르게 도는 웹 표준·브라우저 경쟁에 맞춰 새 기능을 더 일찍 내보낼 수 있다.

보안 패치는 원래도 매주 나가던 거라 이 부분은 그대로예요.

재밌는 건 크롬 혼자만의 흐름이 아니라는 거예요.

Firefox도 154(2026년 8월 18일)를 마지막 4주 릴리스로 삼고 155(9월 1일)부터 2주로 갈아탔어요.

다만 Mozilla는 이걸 “실험”이라고 못 박았고, 문제가 생기면 되돌릴 수 있다는 단서를 달았어요.

짠 것도 아닌데 두 회사가 거의 동시에 같은 결론에 닿았다는 것 자체가, 유행이 아니라 방향이라는 신호로 읽혀요.

숫자로 보면 별거 아닌데, 실무자한텐 “확인 빈도”가 두 배로 뛰는 일이에요.

한 달에 한 번 정독하던 릴리스 노트를 격주로 봐야 한다는 뜻이니까요.

대신 간격이 좁아진 만큼 한 번에 훑을 변경의 총량은 줄어요.

”이번 달 대체 뭐가 바뀐 거지” 하고 몰아 보던 부담이 잘게 쪼개지는 셈이라, 매번은 오히려 가벼워지고요.

진짜 문제는 이 확인을 사람이 매번 브라우저 켜고 눈으로 하던 방식으론 감당이 안 된다는 거예요.

크로스브라우징 QA를 하던 때도 결국 같은 벽이었어요.

브라우저마다 화면을 찍어 나란히 놓고 비교하는 일은 손으로는 금방 한계가 오거든요.

지금 코드 베이스에도 똑같은 문제가 다시 나타난 셈이라, 이번엔 자동화로 풀기로 했어요.

퍼블리셔 시절 체크리스트의 핵심은 “이전과 달라진 부분만 콕 집어 본다”였어요.

Playwright의 스크린샷 비교가 정확히 그 일을 해요.

먼저 엔진을 프로젝트로 등록하고요.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
  ],
});

페이지마다 기준 스크린샷과 비교하는 테스트를 하나씩 둬요.

// tests/visual/writing.spec.ts
import { test, expect } from '@playwright/test';

test('글 목록 화면 시각 회귀', async ({ page }) => {
  await page.goto('/writing');
  await expect(page).toHaveScreenshot('writing-list.png', {
    maxDiffPixelRatio: 0.02,
  });
});

maxDiffPixelRatio로 허용 오차를 잡아두면 안티앨리어싱 같은 무시해도 되는 차이엔 실패하지 않으면서 실제 레이아웃 붕괴는 걸러내요.

이걸 CI에 물려두면 새 크롬·파이어폭스가 나올 때마다 사람이 먼저 알아채는 게 아니라 테스트가 먼저 빨간불을 켜고요.

릴리스가 격주로 촘촘해질수록 “달라진 데만 자동으로 골라주는” 이 구조의 값어치가 커져요.

물론 자동화된 시각 회귀는 “깨졌는가”는 잡아줘도 “왜 깨졌는가”는 안 알려줘요.

그건 여전히 릴리스 노트를 읽어야 아는 영역이고요.

그래서 격주 루틴으로 정한 건 두 가지예요.

하나는 Chrome 릴리스 노트를 2주 캘린더에 고정하는 것 — 몰아 읽지 않고 그때그때 짧게 보니 오히려 하나하나가 더 잘 들어와요.

다른 하나는 Origin Trial 목록을 같이 훑는 것.

아직 정식이 아니어도 곧 만날 API를 미리 봐두면, 릴리스 노트에 그 이름이 뜰 때 “아, 그거” 하고 반응하게 돼요.

벤더 프리픽스를 손으로 검색하며 caniuse를 새로고침하던 시절 습관과 본질은 같아요.

확인 대상이 CSS 프로퍼티에서 릴리스 노트로 바뀌었을 뿐, “새로 나온 걸 내 프로젝트가 어디까지 믿고 써도 되나”를 가늠하는 감각은 그대로 쓰여요.

너무 무겁게 받아들일 필요는 없다는 것도 같이 적어둘게요.

구글도 2주 주기를 모두에게 강제하진 않아요.

Extended Stable 채널은 8주 주기를 그대로 유지해서, 엔터프라이즈 관리 환경이나 Chromium을 임베드하는 조직은 이 채널로 옮겨 느긋한 주기를 쓸 수 있어요.

격주 추적이 부담스러운 팀은 사용자 브라우저 정책을 Extended Stable에 맞추고 QA 주기도 그에 맞춰 늦출 자유가 있다는 뜻이고요.

릴리스 주기가 짧아졌다고 웹 표준이 그만큼 빨리 바뀌는 것도 아니에요.

대부분은 버그 수정과 점진적 개선이고, 마크업·CSS에 실제로 영향을 주는 굵직한 변경은 여전히 드문드문 나와요.

시각 회귀 테스트가 잡아주는 것도 결국 “이번 릴리스는 별일 없었다”는 확인이 대부분일 거고요.

그 확인을 사람이 매번 눈으로 안 해도 된다는 게, 이번 변화에서 제가 챙긴 진짜 이득이에요.

브라우저가 격주로 버전을 올리는 시대에 사람이 할 일은 더 자주 지켜보는 게 아니라, 지켜보는 일을 자동화해서 정말 봐야 할 것만 남기는 쪽에 가까운 것 같아요.

격주로 새 버전이 나오는 브라우저 시대 — Chrome 153, 2주 릴리스 주기가 크로스브라우징 QA에 묻는 것

댓글