Metal by Example | 왜 결국 메탈인가?
28 AUG 2014 | 기타
이전의 두 포스트에서 우리는 메탈 프레임워크의 핵심에 대해 공부했습니다. 이번 포스트에서는 오브젝트가 어떻고 프로토콜이 어떻고 하는 구현에 관한 이야기에서 조금 물러나, 메탈 프레임워크 자체를 주제로 이야기하려고 합니다. 우리는 앞으로 더 많은 수학, 더 많은 수식, 더 많은 코드, 그리고 더 심오한 예제 프로젝트를 작성하게될 것입니다. 나는 필요하다고 생각했습니다 이 블로그를 만든 동기가 무엇이었는지 설명하는 일, 그렇게 해야 앞으로 마주할 어려운 포스트를 헤치워나가는데 힘이 될 것이라고 생각했습니다. 이번 포스트에서는 제가 생각하는 메탈 프레임워크란 무엇인지, 무엇이 될 수 있는지, 왜 다른 사람들이 이것을 배우는 일을 돕는지에 대해 설명할 것입니다.
하드웨어와 소프트웨어 사이의 최전선에서
앱이나 도구를 만드는 우리들로서는, 앱스트랙션 레이어의 시작과 끝을 어디쯤에 두면 좋을지 마음대로 결정할 수 있습니다. 가장 위에서는, 언리얼 엔진을 이용해 코드 한 줄 없이 크로스 플랫폼을 지원하는 어플리케이션을 제작할 수 있죠. 조금 내려가면, 적당한 두께의 앱스트랙션을 거쳐 SpriteKit이나 SceneKit을 이용해 씬그래프와 머티리얼을 구성하는 코드를 작성할 수 있구요. 조금 더 내려가면 OpenGL이나 GLES API를 이용해 버텍스 버퍼나 GLSL 셰이더를 생성하는 코드를 작성할 수도 있구요. iOS 8 부터는 얕던 깊던, 대부분의 앱스트랙션 레이어를 걷어내고 메탈 프레임워크를 이용할 수도 있습니다.
메탈 프레임워크가 로우-레벨이긴 하지만 여전히 앱스트랙션 레이어라는 사실을 알아야합니다. 만일 앱스트랙션 레이어가 아니었다면 커맨드 인코더가 존재할 이유도 없었겠죠. 직접 로우-레벨 GPU 인스트럭션을 작성하고 버퍼에 담아 GPU에 제출해야했을겁니다. Library와 Function 오브젝트도 없었을겁니다. 직접 기계어로 셰이더를 작성하고 GPU에 업로드 해야했겠죠. 여기서 끝이 아닙니다. 수면에서 심해로, 어플리케이션 레이어와 운영체제 레이어를 지나 아득히 깊은 곳에서 하드웨어와 커널을 연결하는 드라이버 소프트웨어를 떠올려보세요. 이 드라이버 역시 앱스트랙션 레이어 중 하나입니다.
메탈 프레임워크는 iOS 상에서 그래픽스 프로그래밍을 수행할 수 있는 가장 낮은 단계의 앱스트랙션 레이어라는 점에서 특별합니다. 이 사실은 메탈 프레임워크를 강력하게 만드는 동시에, 학습 곡선을 가파르게 만들기도 합니다.
누구를 위한 것인가
바로 위에서는 앱이나 도구를 만드는 개발자라고 이야기 했지만, 앱을 만드는 개발자와 도구를 만드는 개발자는 사실 많은 면에서 다릅니다. 대부분의 개발자는 주어진 목표를 빠르게 달성하기위해 하이-레벨 앱스트랙션을 선택할 것입니다. 로우-레벨 프레임워크가 제공하는 강력함을 희생하고서 말이죠. 동시에 그러한 선택은 개발을 진행하는데 필수적이지 않은 디테일을 생략할 수 있게 만들어줍니다. 많은 케이스에서 이 선택은 아주 합리적입니다.
그렇지만 적지 않은 이들은 메탈 프레임워크를 선택할 것입니다. 다른 개발자가 사용할 수 있는 툴이나 프레임워크를 만들기 위해서일까요? 기기의 잠재력이 어디까지인지 탐사하고, 최대한의 성능을 이끌어내기 위한 것일 수도 있습니다. Metal by Example 시리즈는 바로 그런 분들을 위해 작성되었습니다.
언제 필요한 것인가
메탈 프레임워크는 아직도 개발 중에 있는 신생 프레임워크입니다. 많은 기기에서 지원하는 상태도 아닙니다. 하드웨어적으로나 소프트웨어적으로나, 당장 오는 iOS 8 세대 기기들에서 OpenGL ES를 대체할 것이라는 보장도 없습니다. 그렇지만 애플은 점점 더 많은 메탈-컴패티블 장치들을 출시하는 중이고 이 메탈-컴패티블 장치들은 많은 사용자를 확보할 것입니다. 메탈 프레임워크를 이용해 무언가를 만드는 일이 납득되는 시기가 올 것이고, 결국엔 메탈 프레임워크를 사용할 수 밖에 없는 시기도 올 것입니다. 메탈 프레임워크 뿐만 아니라 메탈 프레임워크를 기저로 하는 다른 프레임워크를 포함해서요.
당장 가까운 미래를 점쳐볼까요? 흔히 아는 서드 파티 툴이나 프레임워크의 개발자들은 그들이 제공하던 프로그램에 엄청난 성능을 자랑하는 이 메탈 프레임워크에 대한 호환성을 제공하려고 안달이 날 겁니다. 호환되는 장치에서는 메탈 프레임워크를 이용해 프로그램을 구동할 수 있게요.
적당히 결론 지으면, 당장 이 블로그는 얼리 어답터를 위한 곳이라는 뜻입니다. 기술에 관해 오묘한 점이 하나 있다면, 그것은 기술이 끊임없이 변한다는 사실입니다. 지금은 완전히 새롭고 최첨단으로 보이는 기술이 몇 년 사이에 완전히 보편적인 것이 되기도 하니까요.
iOS는 되고 macOS는 안되나?
메탈 프레임워크는 CPU와 GPU를 아주 긴밀하게 연결하는 특별한 하드웨어에서 작동하도록 설계되었습니다. 맥을 포함한 외장(=discrete) 그래픽카드를 사용하는 장치에서는 메탈 프레임워크가 제공하는 많은 이점이 사라집니다. 안타까운 소식이네요.
좋은 소식이 있다면, 메탈 프레임워크를 구동하는 맥이 완전히 말도안되는 생각은 아니라는겁니다. 사실 개인적인 생각으로는 그렇게 될 수 밖에 없다고 생각합니다. 결국 애플은 언젠가 ARM 기반 맥을 출시할테니까요. ARM 칩셋(현재 iOS 기기에 장착된)은 메탈 프레임워크가 돌아가기에 알맞은 환경입니다. 설계적으로만 보았을땐 ARM 기반 맥을 기다리지 않더라도, 당장 맥 제품군 중 몇 가지에서 메탈 프레임워크를 구현할 수 도 있을겁니다. 오직 내장 그래픽을 사용하는 MacBook Air 같은 경우 말이죠. 인텔 CPU를 장착한 이 맥은 CPU 칩 내부에 그래픽 유닛이 함께 장착되어(=내장 그래픽), CPU와 GPU가 상대적으로 가까이 연결되어있습니다. 메탈 프레임워크를 이용해 유의미한 그래픽 성능 향상을 기대할 수 있겠네요.
문제는 단 하나입니다. 애플이 언제 행동을 개시하느냐!
연산 라이브러리로서
메탈 프레임워크의 주요한 기능이 채-고 성능의 그래픽 연산을 제공하는 것이라는 사실은 자명합니다. 그렇지만 빼놓을 수 없는 점이 몇가지 있습니다. 메탈 프레임워크는 병렬 컴퓨팅이나 벡터 연산을 위한 cool한 API를 제공합니다. 하드웨어 가속을 통한 병렬 컴퓨팅은 물리 또는 약학을 포함한 연구 영역에서 활동하는 이들이 관심 가질만한 사항입니다. OpenCL은 역시 cool한 아이디어였지만 플랫폼 확보에 괄목할 만한 성과를 보이지 못했고, iOS 에도 역시 채택되지 못했습니다. 이러한 공백을 메탈 프레임워크가 채웁니다. 병렬 컴퓨팅을 요구하는 어플리케이션을 제작하는데 메탈 프레임워크가 활약할 것이라는 사실은 너무나 당연합니다!
물론 이 블로그에서는 그래픽에 관한 주제를 주로 다룰 예정이지만, 컴퓨트 커널을 이용해 비슷한 연산을 적어도 두 배, 많으면 100 배까지도 빠르게 수행하는 묘기를 보여드리지 않고 그냥 넘어간다면, 개인적으로 미련이 남을 것 같습니다. 메탈 프레임워크를 이용한 컴퓨팅에 관한 포스트 역시 머지않아 소개해드릴 것입니다.
앞으로 할 일
언제나 그렇듯, 이 블로그는 커뮤니티를 위해 존재하는 것임을 분명히 하려고 합니다. 제가 포스트에서 다루었으면 하는 주제가 있다면 주저없이 연락해주세요. 덧글과 이메일 모두 열려있습니다. 저는 이 블로그를 메탈 프레임워크에 관한 야무진 정보를 제공하는 사이트로 만들고자 합니다. 그리고 마지막에는 이 블로그를 책으로 만들어 정리할 것입니다. community-driven 좋은 게 뭐겠어요? 앞으로 작성할 포스트의 컨텐츠와 방향을 정하는데 여러분의 도움이 필요합니다. 많은 의견 보내주세요!
벌써부터 이 블로그의 존재를 퍼뜨려주시고, 덧글과 메일로 응원의 말을 남겨주시는 분들께 심심한 감사를 전합니다. 저는 이 블로그를 통해 웹 상에서 이제껏 받아본 적 없는 관심을 받고있음을 느낍니다. 앞으로도 여러분의 기대와 성원에 보답하고자 합니다. 감사합니다.
이 포스트는 Warren Moore 선생님의 Metal by Example 시리즈를 의역한 것입니다.