크롬 2주 출시 주기, 연간 26번으로 늘어나는 게 맞습니다
2026년 9월 8일, Chrome 153부터 4주 주기가 2주로 바뀝니다.
사용자에겐 조용한 변화지만, 개발자와 기업 담당자에겐 조용하지 않습니다.
지금 크롬은 몇 버전이고, 9월엔 어디까지 가나
2026년 3월 26일 현재 안정화 버전은 Chrome 147입니다. (출처: Wikipedia — Google Chrome, 2026.03.11 기준 147.0.7727.3) 지금 기준으로 9월 8일까지 약 5.5개월이 남아 있고, 4주 주기로 계산하면 그 사이 약 6개의 버전이 더 나옵니다. Chrome 153이 9월 8일에 2주 주기의 첫 번째 버전이 됩니다.
공식 발표에 따르면 153 이후 일정은 이렇습니다. Chrome 154 베타가 8월 31일, 안정화가 9월 22일. Chrome 155 베타가 9월 8일, 안정화가 10월 6일. (출처: Chrome for Developers 공식 블로그, 2026.03.03) 즉 9월 한 달 안에 153·154 두 개의 안정화 버전이 나옵니다.
예전 4주 주기였다면 154는 10월 말에야 나왔을 겁니다. 한 달이 통째로 당겨집니다.
13회에서 26회로 — 연간 업데이트 수가 두 배가 됩니다
크롬의 출시 주기 역사를 정리하면 이렇습니다. 2010년 출시 초기에는 6주 주기였고, 2021년 Chrome 94부터 4주로 단축됐습니다. (출처: Chromium Blog, 2021년 3월) 이번 발표로 2026년 9월부터 2주가 됩니다. 15년 만에 출시 속도가 세 배 빨라진 셈입니다.
수치로 보면 영향이 더 명확합니다.
| 시기 | 출시 주기 | 연간 업데이트 횟수 | 두 업데이트 사이 간격 |
|---|---|---|---|
| 2010~2021 | 6주 | 8~9회 | 42일 |
| 2021~2026.08 | 4주 | 약 13회 | 28일 |
| 2026.09~ (예정) | 2주 | 약 26회 | 14일 |
개발자 입장에서 이 숫자가 의미하는 건 단순합니다. 사이트 호환성 테스트를 1년에 13번 하던 걸 26번 해야 합니다. CI/CD 자동화가 없는 팀에겐 14일이 굉장히 빡빡합니다. (출처: byteiota.com 분석, 2026.03.10)
빠를수록 불안정하다는 건 이번엔 맞지 않는 이유
💡 공식 발표문과 실제 릴리즈 범위 변화를 같이 놓고 보니, 이 변화가 왜 “더 빠름 = 더 불안정”이라는 공식을 따르지 않는지가 보였습니다.
출시 주기가 짧아지면 당연히 테스트 시간이 줄어들고 버그가 많아질 것이라고 생각하기 쉽습니다. 그런데 구글은 정반대 논리를 내세웠습니다. “릴리즈 빈도는 높아지지만, 각 릴리즈에 담기는 변경 범위가 작아진다”는 겁니다. (출처: Chrome for Developers 공식 블로그, 2026.03.03 — “While releases will be more frequent, their smaller scope minimizes disruption and simplifies post-release debugging.”)
4주치 변경사항을 한 번에 묶어서 내는 것보다, 2주치씩 나눠서 내면 문제가 생겼을 때 어느 변경에서 비롯됐는지 파악하기가 훨씬 쉽습니다. 이건 개발 방법론에서 “작은 배포가 안전하다”는 원칙과 같은 맥락입니다.
실제로 크롬은 2023년부터 이미 주 단위 보안 업데이트를 별도로 운영해 왔습니다. (출처: BleepingComputer, 2026.03.03) 이번 변경은 그 위에 기능 릴리즈 주기를 추가로 좁히는 겁니다. 완전히 새로운 실험이 아니라 기존 보안 업데이트 패턴의 연장선입니다.
기업 담당자라면 Extended Stable을 먼저 확인해야 합니다
💡 “기업도 2주 주기를 따라야 한다”고 오해하기 쉬운데, 공식 Enterprise 문서에는 아예 별도 채널이 명시되어 있습니다.
가장 많이 오해하는 부분입니다. 이번 2주 주기 전환은 일반 안정화 채널에만 해당됩니다. Extended Stable 채널은 기존 8주 주기가 그대로 유지됩니다. (출처: Google Chrome Enterprise 공식 문서, support.google.com/chrome/a/answer/16942104, 2026년 기준)
구조를 간단히 설명하면, 안정화 버전은 2주마다 새 마일스톤이 나오고, Extended Stable은 8주마다 바뀝니다. 그 사이 6주 동안 Extended Stable은 같은 마일스톤을 유지하면서 보안 수정사항만 주간 단위로 백포팅받습니다. 즉 152→156으로 올라가는 동안 Extended Stable은 152를 8주 동안 씁니다.
⚠️ Extended Stable의 한계
보안 수정사항이 기술적으로 백포팅 불가능한 경우, 안정화 채널에서만 제공될 수 있습니다. “가능한 경우”라는 단서가 붙어 있어서, 완전히 동일한 보안 수준을 보장하지는 않습니다. (출처: Chrome Enterprise 공식 문서)
Extended Stable은 현재 Windows·Mac 관리 기기에서만 사용 가능하며, iOS·Android 모바일에서는 지원하지 않습니다. TargetChannel 정책으로 전환할 수 있습니다.
경쟁 브라우저와의 속도 차이가 벌어집니다
💡 구글의 공식 발표문에는 경쟁 브라우저가 언급되지 않았습니다. 그런데 발표 시점의 맥락을 같이 보면 다른 그림이 나옵니다.
구글은 이번 변경이 “AI 경쟁과 무관하다”고 TechCrunch에 밝혔습니다. 그런데 발표 타이밍이 묘합니다. OpenAI의 ChatGPT Atlas 브라우저, Perplexity의 Comet 브라우저가 시장에 진입한 직후였습니다. TechCrunch는 “구글이 AI 브라우저 경쟁사들과 싸우기 위해 출시 속도를 높이는 것”이라고 직접 분석했습니다. (출처: TechCrunch, 2026.03.03)
브라우저 시장 점유율을 보면 Chrome 65%, Safari 20%, Firefox 3% 수준입니다. (출처: byteiota.com, 2026.03.10 기준 추정치) Arc Browser의 월간 사용자 100만 명 이상, Brave의 월간 5,000만 명은 Chrome 절대 과반 앞에서 소수지만, 이 브라우저들이 Chrome보다 훨씬 빠르게 기능을 내놓는다는 점이 문제였습니다. Brave는 월 단위, Arc는 주 단위로 업데이트합니다.
Firefox는 4주 주기를 그대로 유지할 예정이고, Safari는 macOS 릴리즈에 묶여 있어 연간 1~2회 대형 업데이트가 전부입니다. Chrome 26회, Firefox 13회, Safari 2회. 플랫폼 API와 CSS 기능이 Chrome에서 먼저 나오고 타 브라우저에서 수개월 뒤에 따라오는 구조가 지금보다 더 뚜렷해집니다.
9월 전에 개발자가 준비해야 하는 것들
Chrome 153 안정화 날짜인 9월 8일까지 약 5개월이 남아 있습니다. 지금 당장 무언가를 바꿔야 하는 건 아니지만, 준비하지 않으면 9월 이후에 사이트가 깨지는 걸 2주마다 뒤늦게 발견하는 상황이 반복됩니다.
① CI/CD 파이프라인에 Chrome Beta를 추가하세요
새 주기에서 Chrome Beta는 안정화 3주 전에 나옵니다. 지금의 4주 전보다 짧아집니다. Beta를 자동 테스트 매트릭스에 추가하면 안정화 버전 배포 전에 깨진 부분을 잡을 수 있습니다. 수동 테스트로 2주를 버티는 건 현실적으로 어렵습니다.
② 기업 환경이라면 Extended Stable 전환 여부를 지금 판단하세요
오래된 내부 웹 앱이나 수동 QA 사이클을 유지 중이라면 Extended Stable이 현실적인 선택입니다. 단, 일부 보안 패치가 빠질 수 있다는 점은 보안팀과 사전 합의가 필요합니다. 전환은 Chrome Enterprise 관리 콘솔에서 TargetChannel 정책으로 처리됩니다.
③ 일반 사용자라면 사실상 할 것이 없습니다
크롬은 백그라운드에서 자동 업데이트됩니다. 체감하는 변화는 재시작 안내가 지금보다 조금 더 자주 뜨는 정도입니다. 버전 번호가 빠르게 올라가는 게 불안하게 보일 수 있지만, 각 버전의 변경 범위가 작아지기 때문에 대부분의 경우 아무 문제 없이 넘어갑니다.
자주 묻는 것들 — Q&A
마치며 — 이 변화가 실제로 불편해지는 사람은 따로 있습니다
솔직히 말하면, 일반 사용자에게 이번 변경은 거의 티가 나지 않습니다. 크롬은 어차피 알아서 업데이트되고, 재시작 알림이 조금 더 자주 뜨는 게 전부입니다. 변화의 충격은 두 그룹에 집중됩니다. 하나는 수동 QA 사이클을 유지하는 기업 개발팀이고, 다른 하나는 Chrome 버전 정보를 파싱하거나 버전 번호에 의존하는 자동화 시스템을 운영하는 팀입니다.
기업 담당자라면 9월 전에 Extended Stable 전환을 진지하게 검토할 필요가 있습니다. 개발자라면 CI/CD 파이프라인에 Chrome Beta 테스트를 추가하는 게 9월 이후를 편하게 보내는 가장 현실적인 준비입니다. 기다렸다가 출시 후 대응하면, 14일이 생각보다 금방 지나갑니다.
구글이 경쟁 압력을 공식적으로 인정하지 않은 채 “플랫폼 발전을 위한 결정”이라고만 밝힌 건 좀 아쉬웠습니다. 하지만 방향 자체는 틀리지 않습니다. 작은 변경을 자주 내는 게 큰 변경을 가끔 내는 것보다 나쁘지 않습니다. 문제는 준비가 안 된 팀이 이 속도를 얼마나 따라올 수 있느냐입니다.
📎 본 포스팅 참고 자료
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 2026년 9월 이후 실제 적용 시 공식 Chrome 릴리즈 채널을 통해 최신 내용을 확인하시기 바랍니다. 수치·날짜는 Chrome for Developers 공식 블로그(2026.03.03) 기준이며, Chromium Dash(chromiumdash.appspot.com/schedule)에서 최신 일정을 직접 확인할 수 있습니다.
댓글 남기기