2. 그래픽 앱이란 집을 짓기 위해 포크레인 준비하기
그래픽 라이브러리의 의미와 한계
그래픽 어플리케이션을 만들기 위해서는 사용자의 액션을 화면에 표시하는 방법을 정의해야 해요. 그 과정은 아주 복잡하기 때문에 보통 이미 잘 만들어져 있는 그래픽 라이브러리를 활용하곤 하죠. 그런데, 그래픽 라이브러리 라는게 대체 뭘까요? 정확히 어떤 역할을 하는 걸까요?
간단히 말하자면, 그래픽 라이브러리는 개발자가 복잡한 그래픽 작업을 수행하는 데 사용할 수 있는 미리 작성된 코드의 집합이에요. 이러한 라이브러리는 모양 그리기, 색상 지정, 음영 처리, 텍스쳐링 및 3D개체 생성을 위한 다양한 기능을 제공하죠. 눈에 보이는, 즉 시각적 개체가 화면에 표시하는 프로세스를 미리 단순화 해놓은거죠. 개발자는 라이브러리로 복잡한 세부 정보, 그러니까 시각적 개체가 만들어지고 렌더링되는 방식에 너무 얽매이지 않고 그래픽 어플리케이션 개발의 창의적인 측면, 즉 사용자 경험에 더 집중할 수 있어요.
그래픽 라이브러리가 하는 일을 꼽자면 바로 ‘렌더링’과 ‘쉐이더 프로그래밍’이에요.
렌더링(rendering) : 그래픽 모델에서 이미지를 생성하는 프로세스를 말해요. 그래픽 어플리케이션에서는 디지털 펜 이동이나 마우스 이동 등 입력값에 따라 모델이 만들어지는데, 렌더러는 이 모델에 모양, 색상, 질감 및 조명과 같은 모든 시각적 요소를 가져와 결합해서 화면에 표시되는 최종 이미지를 생성하죠. 그래픽 라이브러리가 없으면 개발자는 이 프로세스를 처리하기 위한 복잡한 알고리즘을 따로 작성해야 해요. 하지만 그래픽 라이브러리에 미리 작성된 함수를 사용한다면 이 작업을 크게 단순화할 수 있죠.
모델은 렌더링을 거쳐야 비로소 이미지로 탄생셰이더(shader) 프로그래밍 : 셰이더는 위 렌더링 프로세스를 제어하기 위해 GPU(Graphics Processing Unit)에서 실행되는 작은 프로그램입니다. 조명, 그림자, 반사 및 피부나 물처럼 복잡하고 광범위한 효과를 만드는 데 사용돼요. 다시 말하지만, 이런걸 하나하나 처음부터 작성하는 것은 아주 복잡하고 시간이 많이 걸리는 일이에요. 하지만 그래픽 라이브러리에는 종종 개발자가 필요에 따라 활용하고 수정할 수 잇는 다양한 사전 구축 셰이더가 함께 제공돼죠.
렌더링을 위해 고려해야 하는 수많은 요소OpenGL, DirectX 및 WebGL 같은 그래픽 라이브러들은 개발자가 이런 렌더링과 쉐이더 프로그래밍의 원리를 깊이 고민하지 않아도 사용할 수 있는 유연하고 견고하며 다양한 도구를 제공하고 있어요. 그래서 글로벌하게 사용되고 있죠. 간단한 2D 그리기 응용 프로그램에서 복잡한 3D 게임에 이르기까지 모든 것을 지원해요.
그런데 얘들은 “그래픽 API(Application Programming Interface)”라고도 부르는 걸 볼 수 있어요. 사실 굳이 따지자면 그래픽 API와 그래픽 라이브러리는 의미가 달라요. API는 소프트웨어가 상호작용하는 방식을 정의해서 소프트웨어와 하드웨어 간에 의미를 전달하는 기술을 말하고, 라이브러리는 재사용 가능한 코드의 집합이니까요. 비유하자면 API가 수학, 물리학이라면 라이브러리는 공학이라고 볼 수 있죠. 하지만 OpenGL같은 그래픽 API들은 사용할 수 있는 다양한 도구(재사용 가능한 코드)들도 함께 제공하고 있다는 점에서 라이브러리의 역할도 하고 있어요.
굳이 이렇게 구분한 이유가 뭘까요? 당연히, API 기능은 제공하지 않지만 기존 API를 활용해 만든 라이브러리만 제공하는 경우가 많기 때문이에요. 대표적으로, 게임엔진을 들 수 있겠죠. 언리얼이나 유니티 같은건 많이 들어 보셨죠? 3D 모델을 그리기 위한 게임엔진도 그래픽 라이브러리 중 하나에요. 구글의 Skia나 Apple의 Core Graphics 같은건 2D 그리기를 위한 그래픽 라이브러리구요. 이런 친구들을 그래픽 API 역할을 하는 라이브러리와 구분하기 위해서 보통 low-level(그래픽 API 역할을 하는 애들)과 high-level(그 외) 라이브러리라고 나눠 표현하기도 해요. level이 낮든 높든, 이런 그래픽 라이브러리들은 어플리케이션에서 사용할 수 있는 다양한 코드를 제공하기 때문에 개발자가 더 적은 노력으로 더 창의적인 어플리케이션을 개발할 수 있게 도와준답니다.
그런데, 체리픽은 기존 라이브러리를 이용하지 않고 자체 그래픽 프레임워크를 개발하고 있어요. 이상하지 않나요?
그래픽 라이브러리가 그렇게 많은 것을 제공한다면,
왜 체리픽에 사용하지 않는 걸까?
대답은 간단해요. 기존 라이브러리로는 우리가 만드려 하는 그래픽 크로스오버 사용성을 제공할 수 없어서예요. 성능과 유연성, 크게 2가지 이유 때문에 말이죠. 기존 라이브러리는 강력하지만 안타깝게도 개발자가 그래픽 하드웨어에 대해 접근이 제한적이라서 아무리 열심히 만들어도 우리가 원하는 만큼 성능 향상시킬 수 없어요. 태블릿이나 모바일 디바이스를 통한 창작 경험 제공을 목표로 하는 체리픽에 아주 큰 장애물이죠. 또 벡터와 래스터, 3D와 영상을 넘나들며 창작하는 경험을 제공하는 데 한계가 있어요. 이기종 렌더링 파이프라인을 기존 라이브러리의 조합만으로 구현하는 건 정말 쉽지 않은 일이거든요.(이와 관련해선 나중에 좀 더 자세히 설명해 드릴게요!)
체리픽은 더 유연하고 하드웨어 영역까지 제어가 가능한 그래픽 API 사용이 필요했어요. 이런 API로 직접 그래픽 프레임워크를 만들면 GPU에 대한 접근성을 높이고, 더 유연한 그래픽 렌더링을 구현할 수 있죠. 다음에는 우리가 Vulkan과 Metal을 선택한 이유, 그 과정에서 직면한 문제, 그리고 이를 극복하는 방법에 대해 이야기해보려 해요. 상상만 하던 디지털 창작 생태계를 만들기 위한 디지털 펜 SNS 플랫폼의 도전을 계속 지켜봐주세요