크롬·안드로이드·플러터를 그리는 2D 엔진, Skia
Skia는 구글이 주도하는 오픈소스 2D 그래픽 엔진으로, 크롬과 안드로이드, 플러터 같은 소프트웨어가 텍스트와 도형을 화면에 그릴 때 쓰인다. CPU·GPU 백엔드와 핵심 API 개념, 실무 성능에 미치는 영향을 정리했다.
Skia 엔진은 정확히 무엇을 하나
Skia는 화면에 픽셀을 직접 칠하는 저수준 2D 렌더링 엔진이다. 버튼의 사각형, 아이콘의 곡선, 문단의 글자 하나까지 결국 누군가는 픽셀 좌표로 바꿔 화면 버퍼에 써야 하는데, 그 궂은일을 대신 맡는 부품이라고 보면 된다. 구글이 주도해 개발하는 C++ 오픈소스 라이브러리다. 구글이 2005년 Skia사를 인수해 2008년 BSD 라이선스로 공개했고, 공식 문서(skia.org)에 따르면 지금도 구글이 후원·관리한다.
Skia가 맡는 그리기 작업은 대략 이렇게 나뉜다.
- 선과 곡선, 다각형 같은 벡터 도형과 복잡한 경로(path)
- 글꼴을 실제 글자 모양으로 바꾸는 텍스트 렌더링
- 이미지 디코딩과 합성, 크기 조정
- 그라디언트, 그림자, 블러 같은 효과와 필터
- 투명도 합성과 클리핑(잘라내기)
핵심은 이 모든 작업을 플랫폼마다 제각각인 그래픽 API 위에서 똑같이 돌아가도록 감싼다는 점이다. 개발자는 ‘사각형을 그려라’라고만 말하고, 그것을 어느 운영체제에서 어떤 저수준 API로 그릴지는 Skia가 안에서 알아서 처리한다. 덕분에 같은 렌더링 코드를 여러 환경에 재사용할 수 있다.
어떤 제품이 Skia를 쓰나
가장 널리 알려진 사용처는 웹 브라우저다. 크로미엄 기반 브라우저는 웹 페이지의 도형과 텍스트를 그릴 때 Skia를 쓰고, 안드로이드의 그래픽 스택에서도 오래 쓰여 왔다. Skia 공식 문서는 크롬과 크롬OS, 안드로이드, 플러터, 모질라 파이어폭스를 대표 사용처로 명시한다. 즉 스마트폰 화면 상당 부분이 이 엔진을 거쳐 그려진다고 봐도 큰 무리가 없다.
앱 프레임워크 쪽에서도 쓰임새가 넓다.
- 플러터는 오랫동안 렌더링 백엔드로 Skia를 사용해 왔다. 다만 플러터 공식 문서에 따르면 iOS는 자체 엔진 임펠러(Impeller)로 전환돼 Skia로 되돌릴 수 없고, 안드로이드도 API 29 이상에서는 임펠러가 기본이다. 웹 렌더러(canvaskit·skwasm)는 여전히 Skia를 쓴다.
- 리액트 네이티브에는 쇼피파이가 만든 Skia 바인딩 @shopify/react-native-skia가 공개되어 있어, 커스텀 그래픽이나 애니메이션을 그릴 때 활용된다.
- 정밀한 벡터 렌더링이 필요한 그래픽 편집기나 데스크톱 앱에서 채택되는 경우도 있다. 리브레오피스는 7.0 버전(2020년)부터 윈도우 기본 드로잉 백엔드로 Skia를 채택했다.
정리하면 브라우저와 모바일 운영체제, 크로스 플랫폼 앱 프레임워크가 공통으로 기대는 그래픽 토대에 가깝다. 주니어라면 ‘내가 쓰는 UI 프레임워크 밑에 이런 공용 엔진이 깔려 있을 수 있다’ 정도만 감을 잡아도 충분하다.
CPU와 GPU 백엔드는 어떻게 나뉘나
Skia는 같은 그리기 코드를 여러 백엔드로 내보낼 수 있다. 크게는 CPU가 한 픽셀씩 계산해 채우는 소프트웨어 래스터 방식과, 그래픽 카드에 일을 넘기는 GPU 방식으로 갈린다.
CPU 방식은 GPU를 쓸 수 없거나, 화면 밖 이미지를 미리 만들어 두는 것처럼 결과가 예측 가능하고 이식성이 좋아야 하는 상황에 어울린다. 반대로 화면을 초당 수십 번 다시 그리는 스크롤이나 애니메이션에서는 GPU 방식이 유리하다. 60Hz 화면은 한 프레임을 약 16.7ms 안에 끝내야 하는데, 픽셀 단위 병렬 계산을 GPU에 맡기는 쪽이 이 예산을 지키기 쉽기 때문이다. Skia의 GPU 경로는 내부적으로 OpenGL, Vulkan, Metal 같은 플랫폼 API 위에서 동작한다. 이 중 애플 기기 쪽 GPU 층이 어떻게 생겼는지는 Metal 프레임워크 글에서 따로 다뤘다.
GPU 백엔드는 세대에 따라 이름이 다르다. 오래 쓰인 가네시(Ganesh)와, 최신 그래픽 API에 맞춰 새로 설계된 그래파이트(Graphite)로 나뉜다. 크로미엄 공식 블로그는 2025년 7월 크롬의 래스터 백엔드를 그래파이트로 전환하기 시작했다고 발표했다. 애플 실리콘 맥부터 적용됐고, 맥북 프로 M3 기준 모션마크 1.3 벤치마크 점수가 15% 올랐다고 밝혔다.
| 백엔드 | 설계 기준 그래픽 API | 현재 위치 |
|---|---|---|
| 가네시(Ganesh) | OpenGL 중심 | 오래 쓰인 기존 기본 백엔드 |
| 그래파이트(Graphite) | Metal·Vulkan·D3D12 | 크롬이 애플 실리콘 맥부터 기본 전환(2025년 7월) |
실무에서 이 이름을 외울 필요는 없지만, 같은 Skia라도 어떤 백엔드로 도느냐에 따라 성능과 버그 양상이 달라질 수 있다는 점은 기억해 둘 만하다. 특정 기기에서만 재현되는 렌더링 문제를 만났을 때, 백엔드 차이가 원인 후보에 오르기 때문이다.
핵심 API 개념 몇 가지
Skia를 직접 다루면 몇 가지 객체를 반복해서 만나게 된다. 이름은 언어 바인딩마다 조금씩 다르지만 개념은 비슷하다.
- 캔버스(Canvas, C++ API명 SkCanvas): 실제로 그리기 명령을 받는 도화지다. 사각형과 경로, 텍스트를 그리라는 호출이 여기로 모인다.
- 페인트(Paint, SkPaint): 색과 선 두께, 안티앨리어싱, 필터처럼 ‘어떻게 그릴지’를 담는 설정 묶음이다.
- 패스(Path, SkPath): 직선과 곡선을 이어 만든 도형의 윤곽이다. 아이콘이나 차트의 복잡한 모양을 표현할 때 쓴다.
- 서피스(Surface, SkSurface): 그린 결과가 실제로 저장되는 대상이다. 화면일 수도 있고, 메모리 속 오프스크린 버퍼일 수도 있다.
흐름은 대체로 ‘서피스에서 캔버스를 얻고, 페인트 설정을 준비한 다음, 캔버스에 도형과 텍스트를 그린다’로 이어진다. 이 구조를 알아두면 다른 그래픽 라이브러리를 볼 때도 개념이 쉽게 옮겨 붙는다. 이름만 바뀔 뿐 도화지·붓·모양·저장 대상이라는 뼈대는 비슷하기 때문이다.
실무에서는 언제 신경 쓰게 되나
대부분의 앱 개발자는 Skia를 직접 호출하지 않는다. UI 프레임워크가 알아서 감싸주기 때문이다. 그래서 이 엔진의 존재감은 보통 성능 문제나 렌더링 버그를 파고들 때 드러난다. 지금 쓰는 크롬이 어떤 백엔드로 도는지는 주소창에 chrome://gpu를 입력하면 나오는 그래픽 기능 상태 페이지에서 확인할 수 있다.
예를 들어 리스트를 빠르게 스크롤할 때 끊김이 생긴다면, 매 프레임 다시 그리는 비용이 큰 요소가 있는지 의심해 볼 수 있다. 그림자나 블러는 픽셀마다 주변 픽셀을 여러 번 샘플링해야 하고 반투명 겹침은 오프스크린 버퍼 합성을 유발하기 때문에, 보기엔 단순해도 남발하면 저사양 기기에서 프레임이 떨어지곤 한다. 화면 밖 버퍼에 미리 그려 재사용하는 캐싱이 왜 성능에 도움이 되는지도 이 그리기 파이프라인을 알면 자연스럽게 납득이 된다.
주니어라면 지금 당장 Skia의 함수 이름을 외울 필요는 없다. 대신 내 UI가 결국 저수준 그래픽 엔진을 거쳐 픽셀이 된다는 큰 그림을 갖고 있으면, 성능 튜닝이나 렌더링 이슈를 만났을 때 어디부터 들여다봐야 할지 감이 훨씬 빨리 잡힌다. 도구 이름보다 그 아래에서 벌어지는 일을 이해하는 편이 오래 남는 자산이 된다.