개발/Frontend

아이폰에서 크롬은 크로미움이 아니라구요?

dev-power 2025. 12. 19. 19:41

크롬 브라우저를 쓴다고 해서 모두가 같은 브라우저를 쓰는 건 아닙니다.

 

맥북에서 크롬을 쓰는 당신과, 아이폰에서 크롬을 쓰는 당신은 사실 완전히 다른 브라우저를 쓰고 있다고 할 수 있겠습니다. 심지어 유럽에 사는 친구와 한국에 사는 당신도 같은 "크롬"이라는 이름 아래 다른 경험을 하고 있을 수 있죠.

 

무슨 소리냐구요? 천천히 풀어보겠습니다.

 

 

 

브라우저 엔진이란?

브라우저는 두 부분으로 나뉩니다. 우리 눈에 보이는 껍데기(UI)와, 실제로 웹페이지를 그려내는 엔진입니다.

 

자동차에 비유하면 이해가 쉽습니다. 같은 현대차 외관이라도 안에 현대 엔진이 들어갈 수도 있고, 도요타 엔진이 들어갈 수도 있죠. 겉보기엔 같아 보여도 가속력도 다르고 연비도 다릅니다.

 

크롬은 크로미움 프로젝트 기반의 Blink 엔진을 쓰고, 사파리는 WebKit 엔진을 씁니다. 이 둘은 웹 표준을 해석하는 방식이 조금씩 다릅니다. CSS 속성 하나를 적용해도 미묘하게 다르게 렌더링되고, JavaScript API 지원 시기도 다릅니다.

 

참고로 크로미움이라는 건 구글의 오픈소스 브라우저 프로젝트 이름입니다. 여기엔 웹페이지를 렌더링하는 Blink 엔진과 JavaScript를 실행하는 V8 엔진이 포함되어 있죠.

 

 

 

아이폰에선 모든 브라우저가 Safari다

애플은 iOS에서 특이한 규칙을 만들어뒀습니다. "앱스토어에 올라가는 모든 브라우저는 WebKit 엔진을 써야 한다"는 것입니다. 그래서 아이폰에서 크롬을 깔아도, 파이어폭스를 깔아도, 심지어 엣지를 깔아도 내부적으론 전부 사파리랑 똑같은 WebKit 엔진을 씁니다. 크롬 특유의 Blink 엔진? 아이폰에선 쓸 수 없습니다.

 

이게 왜 문제일가요? 개발자 입장에서 생각해 봅시다. 맥북에서 크롬으로 열심히 테스트했는데 "크로미움 엔진에서는 완벽하게 작동하네!"라고 안심했다가, 정작 아이폰 크롬에선 버그가 터지는 겁니다. 왜냐하면 아이폰 크롬은 Blink 가 아니라 웹킷이거든요.

 

더 황당한 건, 크롬 앱을 깔아놓고도 사파리와 동일한 렌더링 제약을 받는다는 점입니다. 예를 들어 WebKit에서만 발생하는 CSS 버그가 있다면, 그 버그는 아이폰의 크롬에서도 똑같이 나타납니다.

 

 

 

유럽은 예외, 한국은?

유럽에서는 상황이 다릅니다. EU의 디지털시장법(DMA)이 2024년 3월부터 실질적으로 적용되기 시작하면서, 애플이 iOS에서 WebKit 이외의 브라우저 엔진도 허용하도록 강제됐거든요.

 

이에 따라 애플은 iOS 17.4부터 EU 지역 한정으로 다른 브라우저 엔진을 사용할 수 있게 문을 열었습니다. 이론적으로는 유럽 아이폰 사용자가 진짜 Blink 엔진으로 작동하는 크롬을 쓸 수 있게 된 거죠.

 

같은 아이폰인데 유럽에선 A 엔진, 한국에선 B 엔진. 이상하죠?

 

한국을 포함한 아시아권은 아직 이런 규제가 없어서, 여전히 모든 브라우저가 WebKit을 강제로 씁니다. 애플이 자발적으로 한국에도 이를 적용할 가능성은... 글쎄요.

 

 

 

이런 점이 실제로 어떤 문제를 만들까요?

크로스 브라우징 테스트가 복잡해진다

"데스크톱 크롬, 안드로이드 크롬, iOS 크롬" 이 셋을 전부 테스트해야 합니다. 이름은 같아도 내부는 다르니까요. 특히 CSS 애니메이션이나 최신 JavaScript 기능을 쓸 때 차이가 두드러집니다.

 

예를 들어 backdrop-filter 같은 CSS 속성은 Blink 에선 잘 작동하지만, Webkit에선 vendor prefix(-webkit-backdrop-filter)를 붙여야하는 경우가 있습니다. 데스크톱 크롬에선 멀쩡하게 돌아가던 블러 효과가 아이폰 크롬에선 안 나타나는 식이죠.

 

 

PWA 기능 제한

Progressive Web App을 만들 때도 문제가 생깁니다. Blink 기반 브라우저들은 PWA를 적극 지원하지만, WebKit은 일부 기능을 제한합니다.

 

푸시 알림을 예로 들면, 안드로이드 크롬에선 웹 앱에서도 푸시 알림을 받을 수 있지만, iOS 사파리(그리고 iOS 크롬)에선 2023년이 되어서야 겨우 지원되기 시작했습니다. 그것도 제약이 많은 형태로요.

 

 

디버깅이 까다로워진다

버그 리포트를 받았다고 칩시다. "아이폰 크롬에서 로그인이 안 돼요!" 이게 크롬의 문제인지, WebKit의 문제인지, iOS의 문제인지 구분하기가 어렵습니다.

 

맥북에 Safari Technology Preview를 깔아서 테스트해 볼 수는 있지만, 여전히 iOS 환경과는 미묘하게 다릅니다. 결국 실제 아이폰 기기로 테스트하는 게 가장 확실한데, 이게 또 시간과 비용이 들죠.

 

 

 

실제 디바이스 테스트는 필수

실제 디바이스에서의 테스트는 필수입니다. 만약 아이폰이 없다면, BrowserStack이나 LamdaTest 같은 서비스를 쓰면 실제 아이폰 환경에서 테스트할 수 있습니다. 

 

특히 결제나 로그인처럼 중요한 기능은 반드시 실제 iOS 기기로 확인해야 합니다. 시뮬레이터로는 못 잡는 버그들이 있을 수 있거든요.

 

 

 

결국 선택은 애플의 손에

애플이 왜 이렇게 WebKit을 고집하는지는 명확합니다. 앱스토어 생태계를 지키려는 거죠. 웹 앱이 너무 강력해지면 굳이 네이티브 앱을 만들 필요가 없어지고, 그럼 애플의 30% 수수료도 사라지니까요.

 

유럽에서는 규제로 인해 이 벽이 허물어지고 있지만, 한국에서는 언제 바뀔지 모릅니다. 당분간은 "크롬이라고 다 같은 크롬이 아니다"라는 사실을 기억하면서 개발하는 수밖에 없습니다.

 

웹 개발이 어려운 이유 중 하나죠. 같은 코드를 써도 환경에 따라 다르게 작동하니까요. 하지만 이게 또 개발을 재미있게 만드는 요소이기도 합니다. 모든 환경에서 잘 작동하는 걸 만들었을 때의 뿌듯함이란... 이라고 하면 안되겠죠?

 

 

 

 

참고 자료:

 

 

'개발 > Frontend' 카테고리의 다른 글

Next.js 안 써도 괜찮아, React SEO 최적화 총정리  (10) 2025.12.10
다크모드 어떻게 하냐구요? 디자인 토큰 쓰세요  (0) 2025.12.06
또 CSS 고민하세요? styled-components와 Tailwind 중 정답 알려드림  (0) 2025.12.01

'개발/Frontend'의 다른글

  • 현재글아이폰에서 크롬은 크로미움이 아니라구요?

관련글

티스토리툴바