이번 글에서는 C++ 개발자로써 Data-Oriented Design을 세상에 소개한 Mike Acton이라는 사람의 유명한 CppCon 발표를 다뤄보고자 한다. 

발표자 Mike Acton은 2014년 당시에 Insomniac Games의 엔진 디렉터였으며, 플레이스테이션을 비롯한 여러 콘솔 디바이스에서 게임을 구현하기 위해 다양한 노력들을 해왔다. 이후 Unity3d Engine의 기술 디렉터를 역임하였으며, 이 시기에 Unity Engine에 ECS(Entity Component System)이라는 Data-Oriented Design GameObject 시스템 개발을 주도한 것으로 알려져 있다.

2014년도에 그가 CppCon에서 발표한 “Data-Oriented Design and C++”는 지금까지도 많은 사람들에게 회자되고 있는 명강연이다. 개인적으로도 약 1시간 30분 가량의 발표동안 단 한순간도 눈을 뗄 수가 없었다. 너도나도 C++는 로우레벨 언어라고들은 쉽게 말하지만, 정말 C++로 로우레벨을 다룬다는 것이 무엇인지 이 발표에서는 제대로 보여주며, 이를 통해 "Data-Oriented Design"의 덕목이 어떻게 실현될 수 있는지를 역설한다. 

1. Data-Oriented라는 것이 실제로 무엇인가?

그는 가장 먼저 Data-Oriented Design principle들을 다음과 같이 소개했다.

The purpose of all programs, and all parts of those programs, is to transform data from one form to another.

Mike는 먼저 프로그램이라는 개념에 대해서 이렇게 정의하였다. 요컨대 이런 것이다.

• 계산기란 수식 데이터를 정답 데이터로 변환하는 프로그램이다.
• 게임이란 게임 속 세상을 구성하는 데이터와 사용자의 입력 데이터를 화면 데이터으로 1초에 60번씩 변환하는 프로그램이다.
• 운영체제란 메모리에 있는 데이터와 사용자의 입력데이터를, 메모리에 저장될 또 다른 데이터와 화면 출력으로 컴퓨터가 꺼질 때까지 변환하는 프로그램이다.

If you don't understand the data you don't understand the problem.

데이터를 이해하지 못하면 문제를 이해하지 못한 것이라니 실로 데이터 중심의 사고가 아닐 수 없다.
반대로 말해 문제를 제대로 이해하려면 데이터를 먼저 잘 이해해야 하며 데이터가 다르다면 문제 역시 다른 것이고, 이에따라 문제가 서로 다르다면 솔루션 역시 서로 다르다고 설명했다.
이때 어떤 문제에 대한 솔루션 비용(Cost of solving problem)을 이해하지 못했다면, 그것은 문제를 이해한 것이 아니며, 하드웨어를 이해하지 못한다면 문제의 솔루션 비용도 판단할 수 없다고 말했다.
요약하자면, Data-Oriented design으로 문제를 푼다는 것은 데이터와, 해결하려는 문제와, 해법의 비용과, 해법을 수행하는 환경 모든 것에 대한 이해가 수반되어야 한다. 이로써 사용성, 유지보수성, 디버깅 용이성들도 결국엔 데이터와 연관된 문제라는 것이다.

Rule of Thumbs

1. 데이터란 하나가 있다면, 여러 개도 있다. 항상 시간 축 위에서 고려하기 위해 노력하라. Context를 더 많이 알 수록 더 나은 솔루션을 얻을 수 있다. 필요한 데이터를 무시하지 마라.
2. 즉각적인 I/O나 프로그램의 Pre-built data에서부터 하드디스크같은 원본 데이터에 접근하는데에는 모두 각기다른 시간이 소모됨을 유의해라.
3. Reason must prevail. 소프트웨어란 컴퓨터과학 연구실 어느 열정어린 박사의 마법같은 환상 위에서 실행되는 것이 아니라, 철저히 현실 속에서 현실의 데이터를 다루는 것이다.

2. 흔히 알려진 세가지 거짓말

Mike는 우리가 경계하고 경계해야할 프로그래머 업계에 널리 퍼진 3가지 거짓말을 다음과 같이 정의했다.

거짓말 1. 소프트웨어는 플랫폼이다.

하드웨어야말로 플랫폼이다. 같은 문제에 대해 구글의 거대한 서버팜과 손바닥만한 조그마한 아두이노가 같은 솔루션을 취할 수는 없다. 하드웨어마다 서로 다른 물리적인 제약과 유한한 자원이 있는데 어떠한 소프트웨어 솔루션도 이로부터 독립적일 수는 없다. 현실이란 당신의 이론적이고 추상적인 문제에서 맞딱드릴 장애물 같은 것이 아니다. 현실이 문제 그 자체다.

거짓말 2. 코드는 실제 세계에 대한 모델링 기반으로 설계되어야 한다

실제 세계를 모델링 한다는 것은 대개 다루려는 실제 데이터를 뒤로 숨기는 것이다. 그런데 이는 1) 프로그램이 좋은 유지보수성을 갖게 만드는 것과 2) 문제를 풀기위해 데이터의 속성을 잘 이해하는 것의 차이를 쉽게 혼동하게 만든다. 개념적으로 깔끔하게 추상화하여 모델링을 잘하면 1)을 성공적으로 달성할 수 있겠지만, 그것이 반대로 2)를 굉장히 어렵게 만들 수도 있다는 것이다.

예를 들어 chair에 대해 모델링 한다면, 가장 기본이 되는 chair로부터 여러가지가 파생될 것이다. 하지만 의자라는 개념 그 자체는 문제도 아니고 데이터도 아니다. 다뤄야하는 실제 문제는 그보다는 ‘부서지는 의자’, ‘앉을 수 있는 의자’, ‘장식용 의자’ 등등을 구분하여 이를 각각 알맞게 처리하는 것이며, 이 때 chair라는 공통 속성이 있다는 것은 그다지 유용한 정보가 아니다.

모델링은 대개 문제를 보다 단순한 개념으로 이상화하고자 시도하지만, 문제를 문제 그 자체보다 더 단순하게 만들 수는 없다. 모델링은 좋은 비유, 좋은 스토리 텔링이 될 수는 있지만 문제 해결에서도 무조건 좋지만은 않다.

거짓말 3. 코드는 데이터보다 중요하다.

코드는 단지 어떤 데이터를 다른 어떤 데이터로 바꾸기 위함이 목적이다. 여기서 중요한 것이 과연 코드일까 데이터일까? 프로그래머가 책임감을 가져야 하는 것은 코드일까 코드가 만들어내는 데이터일까?

그래서 이를 잘 구분하기 위해서는 가장 먼저 다뤄야할 데이터가 무엇인가에 대해 정확히 아는 것이 중요하다고 말한다. 따라서 코드는 주어진 제약조건 속에서 데이터를 잘 가공하기 위한 도구 그 이상 그 이하도 아니라고 강하게 주장한다.

이어서 Mike는 이 세 가지 거짓말들이 가져온 악영향을 이렇게 소개했다.

• 나쁜 코드 퍼포먼스
• 나쁜 동시성
• 나쁜 최적화 가능성
• 나쁜 안정성
• 나쁜 테스트성

여기까지 들었을 때 들었던 의문은, 저 부작용들이 과연 저 세가지 거짓말 때문에 일어나는 것들일까? 였다. 곰곰히 생각해보면, 많은 개발자들이 사랑해 마지않는 '클린XX' 개념들 중에 좋은 코드 퍼포먼스, 좋은 동시성, 좋은 최적화 가능성을 이야기 하는 것은 접해본 적이 별로 없는 것 같다. 그보단 유연하고 깔끔하고 유지보수성 높은 코드를 작성하는 것에 좀 더 치중했지 않았나? 하는 생각이다.
 

3. Dictionary LookUp을 구현해보세요.

Mike는 곧바로 간단한 예시를 보여주었다. Dictionary LookUp기능을 구현하기 위한 코드를 작성할 때, 으레 개발자들은 위와 같은 그림을 머릿속에 그릴 것이다. Key-Value Pair로 구성되어 있으니 실제로 구현할 때도 메모리에 이런 모양으로 데이터 레이아웃을 구성했을 것이다. 떠오르는대로 작성해보자면 아래와 같을 것이다.

template<typename KEY_TYPE, typename VALUE_TYPE>
struct Dictionary
{
VALUE_TYPE operator[](const KEY_TYPE& key);
std::vector<std::pair<KEY_TYPE, VALUE_TYPE>> data;
};

 
하지만 곧바로 Mike는 이런 아이디어가 바로 위에서 말한 "Code-first Design"이며, 이러한 설계가 놓친 맹점을 바로 이렇게 짚어준다.
 
"Key와 Value 모두 동등한 확률로 필요할까? 아니다. 우리는 대부분의 시간을 Key 목록을 조회하는데 사용할 것이다. Value는 우리가 정말로 얻고자 하는 Key값에 대해서만 한 번 필요하다. 엄밀히 말해, Key와 Value는 개념적으로는 쌍을 이루지만 실질적으로는 연관성이 없다."

사실 생각해보면, 우리가 Dictionary에서 무언가를 조회하는 동안에는 다른 Key에 해당하는 Value들은 전혀 궁금하지 않다. 도서관에서 원하는 책을 찾기 위해 이동하는 길에 보이는 모든 책을 다 꺼내볼 필요가 없는 것처럼, Key목록을 조회하는 동안 캐시라인 위에 Value들까지 올릴 필요가 전혀 없다는 뜻이다.

"Code-first Design"이 아니라 "Data-first Design"을 한다면, 실제로 Dictionary의 메모리는 이렇게 생겨야 한다는 뜻이다. 이렇게 하면 CPU 캐시 상에 Value들은 올라올 일이 없고, 적절한 Index가 정해진 시점에만 한 번 로드되기 때문에 훨씬 효율적인 코드가 된다는 주장이다.

template<typename KEY_TYPE, typename VALUE_TYPE>
struct Dictionary
{
VALUE_TYPE operator[](const KEY_TYPE& key)
{
	return values(keyToIndex(key));
}

int keyToIndex(const KEY_TYPE& key);
std::vector<KEY_TYPE> keys;
std::vector<VALUE_TYPE> values;
};

4. "플랫폼에 대한 이해가 중요하다."

여기까지는 그럭저럭 따라올만 하다고 생각했는데, Mike가 갑자기 CPU CYCLE표를 보여주니 다소 당황스럽다. 그러나 그는 정신 차릴 시간을 주지 않고 폭주기관차처럼 설명을 이어간다.
위의 표는 AMD cpu에서 sin, cos, tan 같은 삼각함수연산을 위한 명령어가 실행되는데 걸리는 시간을 나타낸다. 여기서 말하는 Latency란 CPU CYCLE을 의미한다. 즉 위의 표에 의하면 AMD에서 Float point Sin 함수를 연산하는데 일반적으로 60~146 CYCLE를 소모한다고 한다. 밑도끝도 없이 갑자기 이 표를 왜 보여주지? 라고 생각했을 때 곧바로 본론으로 넘어간다.

위의 표에 의하면, L1 캐시에 있는 메모리에 접근하는 것은 고작 3 CYCLE밖에 들지 않지만, 기존의 캐시라인으로부터 물리적으로 멀리 떨어진 주소의 메모리에 접근을 시도하면 와장창 캐시 미스가 발생하여 Main Ram까지 다녀오는데 200+ CYCLE이 소요된다. 위의 삼각함수 연산에 드는 비용이 140 사이클 정도 이내인 것을 고려하면 상당히 무거운 비용이라고 할 수 있다.
위의 Dictionary 예제에서 만약 VALUE_TYPE이 큰 사이즈의 타입이라면, Data-Oriented Design으로 설계하지 않은 코드에서는 Key를 조회하는 매 Iteration마다 캐시 미스가 발생, 즉 200+CYCLE의 연산량을 소모할 것이다.
이 슬라이드를 보며 지난날의 과오를 되돌아보니 내가 CPU에게 저지른 죄가 너무 많아 정신이 아득해진다.

정신을 추스를 겨를도 없이, 이번엔 좀 더 강한 팩트 폭행이 가해진다. 위의 코드는 일반적으로 게임엔진에서 많이 사용되는 코드이다. 코드를 보아하니 2차원 공간에서 위치와 속도를 지닌 객체에 대해 모델링한 것으로 보인다.  그런 다음 UpdateFoo함수를 보면 m_Foo라는 어떤 magnitude 값을 계산하는 함수가 있는 것을 볼 수 있다. 이런 디자인은 거의 대부분의 GameEngine에서 볼 수 있는 디자인이다. 이 클래스만 보면, GameObject가 어떤 프로퍼티를 가지고 있고 어떤 기능들을 가지고 있는지 한 눈에 알아볼 수 있다. 아주 잘 짜여진 코드라고 . 할 수 있겠다. "Code-First Design"에서는 말이지.
 
자 이제 이런 가정을 해볼 수 있다. 이 GameObject 사이즈는 최소 60 byte쯤 될 것이다. m_Name과 m_Foo 사이에 훨씬 더 많은 멤버가 선언되어 있다면 그보다 훨씬 커질 수도 있다. 하지만 여전히 m_Foo는 객체의 시작점에서 가장 멀리 떨어진 주소에 있을 것이다. 그러면 이제 아래의 UpdateFoo함수를 기계어로 번역한 결과를 보자.

 
즉 UpdateFoo 함수에서 실제 중요한 로직을 수행하는데는 40cycle이지만 필요한 데이터를 로드하는 데에는 400 cycle이 소모되었다.
이렇게 숫자로 놓고보면 정말 어마어마한 낭비가 아닐 수 없다.
그런데 게임에는 GameObject가 십수개 있는 것이 아니라 천개 만개씩 존재하기도 한다. 엄청난 규모의 Scene에서는 한 번에 10만개 가량의 GameObject가 존재할 수도 있다. 그런 상황에서도 만약 GameObject 구조체가 위와 같이 설계되어 있다면, 이런 종류의 연산을 할 때마다 실제로 전체 문제에서 CPU 자원은 10%밖에 활용을 못한다는 뜻이다.

이 또한 컴파일러님께서 다 알아서 해주지 않을까 희망을 품는 불경한 자들을 위해 Mike는 이렇게 덧붙인다. 컴파일러 기술이 아무리 나날이 발전한다 하더라도, 코드 상에 선언된 클래스 구조까지 최적화 해주지는 못한다. 아무리 컴파일러가 열심히 최적화 해준다고 하더라도, 여기서는 전체 문제의 10% 내외에서만 그 능력이 발휘된다는 뜻이다.
 

5. Code-first가 이렇게나 위험합니다.

슬라이드의 후반에서는, Mike는 주저없이 유명한 오픈소스 게임엔진인 Ogre의 클래스 구조를 적나라하게 고발한다. Node는 일종의 GameObject 클래스인데, 여기에는 총 5개의 문제가 있다고 지적한다.
1) Cant' re-arrange memory

이렇게 정의된 멤버 변수들은 메모리 액세스 패턴을 예측하기가 매우 어렵기 때문에 컴파일러에서 re-arrange를 시도조차 할 수 없다. 무엇이 자주 읽혀지고 무엇이 자주 쓰여지는지, 이렇게 객체의 모든 멤버 변수가 한 번에 선언되어 있는 상황에서 컴파일러가 할 수 있는 것은 제한 적이다.
 
2) Bools and last-minute decision making

Node라는 객체는 GameObject이기 때문에 실제로 상당히 많은 숫자의 Instance가 한 번에 존재할 것이다. 그리고 개별 GameObject마다 동작유형, 관리 방식 등등도 모두 다를 것이다. 표시된 변수 이름들이 아마 이런 것들을 제어하기 위한 Boolean Flag 값일 것이다. 문제는 이 정보가 Node 인스턴스 안에 있다는 것이다. 따라서 어떤 Node가 어떻게 동작할 것인지는 실제로 그 Node의 메모리에 직접 접근해서 까봐야지만 즉, Last-minute에서야 알 수 있다는 뜻이다.
위에서 예시로 Dictionary LookUp을 예로 들자면 Value가 자신과 매칭된 Key값을 들고 있어서, Dictionary 조회를 할 때 모든 Value를 다 까보면서 Key가 매칭되는지 확인하는 것과 마찬가지라는 뜻이다.
 
3) Over-generalization

지나치게 일반화 되어서 객체 하나가 너무 많은 역할을 담당하고 있는 것이 문제라고 주장한다.
1. 많은 Property들로 인해 Property들에 대한 read/write를 효율적으로 관리하기가 어려워질 것이다.
2. 생성자와 소멸자에서 불필요한 read/write가 일어날 것이다.
3. 가상함수가 많아지기 때문에 vtable 참조가 많아지면서 I-cache 역시 효율적으로 관리되지 못할 것이다.
4. 객체가 가질 수 있는 State가 기하급수적으로 복잡해진다. 여기 존재하는 Boolean Flag만으로도 2^7 개 이상의 State를 가질 수 있다.
 
4) Undefined or under-defined constraints

생성자에서 mName 멤버는 msNameGenerator.generate()라는 함수에서 생성한 것을 그대로 받아서 할당한다. 변수명에서 유추할 수 있듯이 String은 길이 자체도 가변적인데, generator라는 함수가 넘겨주는 값이 어떤 것일지 이 코드에서는 도저히 예측할 수가 없다. 매우 우 긴 이름을 가지고 있다면 이 Node는 다른 Node들에 비해 훨씬 큰 메모리를 차지할 가능성이 존재한다. Mike는 이런 이유 하나만으로도 객체 Instance에 String 멤버 변수를 사용하는 것은 '일반적으로 나쁘다' 라고 덧붙인다.
 
5) Over-solving

마지막 한 줄까지도 남김없이 탈탈 털린다. 대체로 needUpdate 함수는 이 인스턴스가 가진 멤버들이 최신화되어야 한다고 flag를 켜주거나 최신화를 수행하는 함수이다. 그런데 초기화 시점에 반드시 최신화가 필요할까? 생성자에서 초기화된 값 그 자체로도 최신상태일 수도 있지 않을까? 아무튼 알잘딱으로 잘 해줬으면 하는 개발자의 얕은 뜻을 컴파일러는 깊이 알지 못한다. 
 

6. 우리는 어떻게 해야 하나요?

훌륭한 오픈소스 게임엔진인 Ogre를 뼛속까지 탈탈 터는 장면을 눈앞에서 목도했을 때 참석자들의 표정까지 화면에 담기지는 않았겠지만, 아마 모두가 망연자실한 표정이었을 것이다. Mike는 이들을 위해 위에서 지적한 문제들에 Data-Oriented Design 관점에서 어떻게 재설계할 수 있는지도 친절하게 정답을 알려준다. 그것까지 이 글에 담기에는 내용이 매우 많기 때문에귀찮고 영상을 통해 직접 확인하기를 바란다.

끝으로, Mike는 앞서 소개 했던 세 가지 거짓말들에 대해서 다음과 같이 진실을 바로잡으며 마무리한다.
* 하드웨어가 여러분의 플랫폼입니다.
* 이상적인 세계를 모델링 하지 마세요. 실제로 다루려는 데이터 자체에 집중하세요.
* 당신은(프로그래머로써) 데이터를 가공하는 것에 책임이 있지, 좋은 코드를 작성하는 것에 있지 않습니다.
 

7. 마치며

Data-Oriented Design의 효용성과 실용성에 대해서는 여전히 의견이 분분할 것이다. 그러나 이 발표자가 자신이 주장하는 바와 개념에 대해서 화두를 던지고 결론까지 도달하는 발표자의 논리 전개 과정은 그 누구도 토달 수 없도록 현실에 기반하여 실증적으로 진행되었다. 나도 꽤나 성능에 민감한 개발자에 속하고, 하드웨어 성능을 극한까지 끌어올리는 것을 좋아하지만 이 사람은 그 이상이었다. 발표를 끝까지 봤을 때 CPU로 하는 한 편의 차력쇼를 보는 느낌이라고 할까.

끝으로 20분에 걸친 질의응답 세션도 정말 예술이다. “이건 data-oriented가 아니라 Cache-oriented design 아닌가요?”라거나 “당신 C++개발자가 맞기는 한가? 대부분 C아니면 어셈블리어들인데?” 같은 공격적인 질문들도 더러 있었다. 하지만 그는 시종일관 단단하고 확신에 찬 어조로 답변하곤 했다.

그의 말 중에 가장 인상 깊었던 것은, "알아요. 하지만 저는 어딘가에서 이런 것들을 신경쓰는 엔지니어들도 있다는 사실을 알리고 싶었습니다." 라는 말이었다. 이토록 자신의 업에 대한 확고한 철학과 신념은 어디에서 나오는 것일까? 새삼 존경스러운 마음이 일었다.

1. 서론

오늘날 소프트웨어 개발에서 성능은 중요한 요소로 자리 잡고 있다. 어느 시점부터 프로그래밍 언어의 덕목이라 함은 쉬운 사용성에 더 기울어지고 있는 요즘이지만, 그런 것들로 인해 게임 개발, 그래픽 프로그래밍, 실시간 데이터 처리 애플리케이션 등에서 요구하는 고성능 지향의 최적화가 덩달아 용이해지지는 않는다. 다시 말해 아무리 더 넓은 저변의 사용자를 지향하고, 더 편한 사용성, 더 쉬운 개발을 지향하는 언어가 나온다 하여도, 그것으로 개발된 프로그램이 실행되는 환경이 변하지는 않았다. 우리는 여전히 가산기-누산기-레지스터의 구조로부터 만들어진 CPU 위에서 실행되는 프로그램을 만들고 있다.

그렇다고 해서, 어떤 문제를 좀 더 풀기 쉬운 형태의 개념으로 해석하고 풀이하고 고찰하는 것의 가치와 의미가 퇴색되지는 않는다. 그로써 고안된 수많은 프로그래밍 패러다임과 디자인 패턴은 지금도 계속해서 어둠 속을 헤매는 개발자들에게 길잡이 별이 되어주고 있다. 전통적인 객체 지향 설계(Object-Oriented Design, OOD)는 그중에서도 아주 오랜 기간 동안, 그리고 지금까지도 우리가 프로그래밍으로 풀어내고자 하는 문제에 대한 편리한 모델링 도구로써 많은 개발자들에게 사랑받고 있는 개념이다. 그러면서도 동시에 최근에는 데이터 중심 설계(Data-Oriented Design, DOD)가 주목받고 있는 것은 왜일까를 이 시리즈를 통해 고민해보고자 한다.

그 첫 번째로써, 이번 글에서는 우선 OOP와 DOD의 개념을 비교하고, 각각의 장단점과 실제 예제를 통해 기존 프로그래밍 패러다임들에 대해 DOD가 도전하는 영역들을 탐구해보고자 한다.

2. 객체 지향 설계(OOP)의 개념과 활용

2.1 OOP의 기본 개념

객체 지향 프로그래밍(Object-Oriented Programming, OOP)은 현실 세계의 개념을 객체라는 단위로 모델링하여 소프트웨어를 개발하는 프로그래밍 패러다임이다. 객체는 **데이터(속성)**와 해당 데이터를 조작하는 **함수(메서드)**를 함께 묶어 하나의 단위로 관리한다.

OOP의 주요 특징:

• 캡슐화(Encapsulation): 데이터와 함수를 하나의 객체로 묶어 외부로부터 데이터를 보호하고, 객체 내부의 구현 세부 사항을 숨긴다.
• 상속(Inheritance): 기존 클래스의 속성과 메서드를 새로운 클래스가 물려받아 코드 재사용성을 높인다.
• 다형성(Polymorphism): 동일한 인터페이스를 통해 다양한 객체를 처리할 수 있어 코드의 유연성을 높인다.
• 추상화(Abstraction): 복잡한 시스템을 단순화하여 핵심적인 부분에 집중할 수 있게 한다.

2.2 강아지 멍멍 고양이 야옹

OOP의 개념을 한 번이라도 접해본 사람이라면 누구나 익숙한 동물 울음소리를 모델링하는 간단한 프로그램이다.

#include <iostream>
#include <vector>

// 추상 클래스: Animal
class Animal {
public:
    // 순수 가상 함수: 각 동물이 자신의 울음소리를 구현해야 함
    virtual void makeSound() const = 0;

    // 가상 소멸자: 상속받은 클래스의 소멸자를 올바르게 호출하기 위해 필요
    virtual ~Animal() = default;
};

// 구체적인 동물 클래스: Dog
class Dog : public Animal {
public:
    void makeSound() const override {
        std::cout << "멍멍" << std::endl;
    }
};

// 구체적인 동물 클래스: Cat
class Cat : public Animal {
public:
    void makeSound() const override {
        std::cout << "야옹" << std::endl;
    }
};

int main() {
    // Animal 포인터를 저장하는 벡터
    std::vector<Animal*> animals;

    // 동적 할당을 통해 객체 생성
    animals.push_back(new Dog());
    animals.push_back(new Cat());

    // 다형성을 활용하여 각 동물의 makeSound() 호출
    for (const auto& animal : animals) {
        animal->makeSound();
    }

    // 메모리 해제
    for (auto& animal : animals) {
        delete animal;
    }

    return 0;
}

• Animal은 추상 클래스로, makeSound()라는 순수 가상 함수를 가진다.
• Dog와 Cat 클래스는 Animal을 상속받아 makeSound()를 오버라이딩한다.
• main() 함수에서는 Animal* 타입의 포인터를 저장하는 벡터를 사용하여 다양한 동물 객체를 관리한다.
• 루프를 통해 각 동물의 makeSound()를 호출할 때 다형성이 적용되어 실제 객체의 메서드가 호출된다.

2.3 OOP가 넓은 범위에서 유용하게 사용된 이유

• 현실 세계의 모델링 용이성: 현실의 사물과 개념을 객체로 표현하여 프로그래밍에 적용하기 쉽다.
• 코드 재사용성 향상: 상속과 캡슐화를 통해 코드의 중복을 줄이고 유지보수를 용이하게 한다.
• 유연한 코드 구조: 다형성을 통해 새로운 기능 추가나 변경에 유연하게 대응할 수 있다.
• 캡슐화를 통한 안정성 확보: 객체 내부의 데이터를 보호하여 코드의 안정성과 신뢰성을 높인다.
• 추상화를 통한 복잡성 관리: 복잡한 시스템을 단순화하여 핵심 로직에 집중할 수 있다.

3. 객체 지향 설계의 한계와 문제점

위에서 설명한 바와 같이 OOP는 많은 장점을 가지고 있지만, 특히 성능이 중요한 분야에서는 몇 가지 한계를 드러낸다.

3.1 메모리 비효율성

• 메모리 산재: 객체들이 힙(Heap)에 동적 할당되어 메모리 상에서 연속적이지 않은 위치에 존재한다.
• 캐시 미스(Cache Miss) 증가: 메모리 상에 산발적으로 위치한 데이터를 접근하면 CPU 캐시의 효율이 떨어져 성능 저하를 유발한다.

예시:

// 엔티티 클래스
class Entity {
public:
    virtual void update() = 0;
    virtual ~Entity() = default;
};

// 다양한 엔티티 객체 생성
std::vector<Entity*> entities;
entities.push_back(new Player());
entities.push_back(new Enemy());
// ...

// 엔티티 업데이트
for (auto& entity : entities) {
    entity->update();
}

• 각 엔티티 객체는 힙 메모리에 동적으로 할당되며, 메모리 주소가 연속적이지 않다.
• 루프를 통해 객체를 순회할 때 메모리 접근 패턴이 불규칙하여 캐시 미스가 발생한다.

3.2 동적 바인딩 오버헤드

• 가상 함수 호출: 다형성을 구현하기 위해 가상 함수를 사용하며, 이는 런타임에 실제 함수가 결정되는 동적 바인딩을 필요로 한다.
• 오버헤드 발생: 가상 함수 테이블(V-Table)을 참조하여 함수를 호출하는 과정에서 추가적인 메모리 접근과 연산이 발생한다.

3.3 데이터 접근의 비효율성

• 캡슐화로 인한 제약: 객체 내부의 데이터를 보호하기 위해 private 또는 protected로 선언하여 직접 접근이 불가능하다.
• 함수를 통한 간접 접근: 데이터에 접근하거나 변경하기 위해서는 접근자(getter)나 설정자(setter) 함수를 사용해야 하며, 이는 추가적인 함수 호출 오버헤드를 발생시킨다.

3.4 복잡성 증가

• 과도한 상속 구조: 깊은 상속 계층은 코드를 이해하고 유지보수하는 데 어려움을 준다.
• 디자인 패턴의 남용: 필요 이상으로 복잡한 디자인 패턴을 적용하면 오히려 코드의 가독성과 이해도를 떨어뜨린다.
• 디버깅의 어려움: 다형성과 동적 바인딩으로 인해 버그의 원인을 추적하기 어려울 수 있다.

4. 데이터 중심 설계(DOD)의 등장과 필요성

4.1 DOD의 기본 개념

데이터 중심 설계(Data-Oriented Design, DOD)는 프로그램의 중심을 데이터에 두고, 데이터의 배치와 처리 방식을 최적화하여 성능을 극대화하는 프로그래밍 패러다임이다.

• 데이터 주도 접근: 프로그램의 핵심은 데이터이며, 코드는 데이터를 변환하거나 이동시키는 도구로 본다.
• 메모리 레이아웃 최적화: 데이터가 메모리에 연속적으로 배치되도록 설계하여 CPU 캐시의 효율을 높인다.
• 일괄 처리 방식: 동일한 작업을 여러 데이터에 반복적으로 수행하여 분기(branch)를 최소화하고, 벡터화(vectorization)를 통한 병렬 처리를 용이하게 한다.

[OOP 방식]
+-----------------+    +-----------------+    +-----------------+
|   Entity 객체    |    |   Entity 객체    |    |   Entity 객체    |
| - position      |    | - position      |    | - position      |
| - velocity      |    | - velocity      |    | - velocity      |
| - update()      |    | - update()      |    | - update()      |
+-----------------+    +-----------------+    +-----------------+

[메모리 상의 배치]
객체1 위치: 메모리 주소 0x1A2B
객체2 위치: 메모리 주소 0x3C4D
객체3 위치: 메모리 주소 0x5E6F

[DOD 방식]
positions: [pos1][pos2][pos3][...]
velocities: [vel1][vel2][vel3][...]

4.2 DOD가 효과적인 분야

DOD가 효과적일 것으로 기대되는 분야는 대개, 하드웨어의 성능을 극한까지 끌어올려 더 빠르고 넓은 대역폭의 연산을 요구하는 분야이다.

• 게임 개발: 수천에서 수백만 개의 엔티티를 실시간으로 업데이트해야 하는 상황에서 성능 향상이 필수적이다.
• 그래픽 렌더링: 대량의 버텍스(vertex)와 픽셀(pixel) 데이터를 처리할 때 캐시 효율이 중요하다.
• 과학 계산 및 시뮬레이션: 방대한 데이터를 고속으로 연산해야 하는 분야에서 유용하다.
• 빅데이터 처리: 대용량 데이터의 분석과 처리에서 메모리 접근 패턴의 최적화가 성능을 좌우한다.

5. DOD의 실제 예제

5.1 DOD의 특징

예제를 탐구해보기에 앞서 DOD가 가진 특징을 다시 한 번 환기해보자.

CPU 캐시와 메모리 접근:

• CPU 캐시는 메모리 접근 속도를 향상시키기 위한 작은 크기의 고속 메모리이다.
• 캐시 히트(Cache Hit): 필요한 데이터가 캐시에 존재하여 빠르게 접근할 수 있는 경우.
• 캐시 미스(Cache Miss): 필요한 데이터가 캐시에 없어서 메인 메모리에서 가져와야 하는 경우.

데이터의 연속성:

• 데이터가 메모리에 연속적으로 배치되면 한 번의 메모리 접근으로 여러 데이터를 캐시에 로드할 수 있다.
• 이를 통해 캐시 히트율을 높이고 성능을 향상시킬 수 있다.

벡터화(Vectorization):

• SIMD(Single Instruction Multiple Data): 하나의 명령어로 여러 데이터를 동시에 처리하는 기술.
• 루프 내의 연산이 단순하고 데이터가 연속적이면 컴파일러가 자동으로 벡터화하여 SIMD 명령어를 사용할 수 있다.

5.2 게임 엔진의 엔티티 업데이트 예제

목표: 다수의 엔티티의 위치를 매 프레임마다 효율적으로 업데이트한다.

5.2.1 OOP 방식의 구현

#include <vector>

// 엔티티 기본 클래스
class Entity {
public:
    virtual void update() = 0;
    virtual ~Entity() = default;
protected:
    float position;
    float velocity;
};

// 플레이어 클래스
class Player : public Entity {
public:
    void update() override {
        position += velocity;
        // 추가적인 플레이어 로직...
    }
};

// 적 클래스
class Enemy : public Entity {
public:
    void update() override {
        position += velocity;
        // 추가적인 적 로직...
    }
};

int main() {
    std::vector<Entity*> entities;

    // 엔티티 생성 및 추가
    for (int i = 0; i < 1000; ++i) {
        if (i % 2 == 0)
            entities.push_back(new Player());
        else
            entities.push_back(new Enemy());
    }

    // 매 프레임마다 업데이트
    for (auto& entity : entities) {
        entity->update(); // 가상 함수 호출
    }

    // 메모리 해제
    for (auto& entity : entities) {
        delete entity;
    }

    return 0;
}

위의 코드는 객체지향 프로그래밍이 익숙한 사람들에게는 더할나위 없이 편안한 코드일 것이다. 하지만 우리의 CPU는 생각이 좀 다르다.

• 가상 함수 호출로 인한 오버헤드
  • 동적 바인딩 비용: entity->update() 호출 시 가상 함수 테이블(vtable)을 참조하여 실제 함수를 결정한다. 이 과정에서 추가적인 메모리 접근과 연산이 필요하며, 이는 CPU 파이프라인의 예측 불가능성을 높여 성능 저하를 유발한다.
  • 인라인화 불가: 컴파일러는 가상 함수를 인라인화할 수 없으므로, 함수 호출 오버헤드가 제거되지 않는다.
• 메모리 비연속성으로 인한 캐시 효율 저하
  • 힙 메모리의 산재: new 연산자를 통해 동적으로 할당된 객체들은 메모리 상에서 연속적으로 배치되지 않을 수 있다.
  • 캐시 미스 증가: 엔티티 객체들이 메모리 전역에 흩어져 있으므로, 루프 내에서 entity->update()를 호출할 때마다 CPU 캐시에 로드되지 않은 메모리 영역에 접근하게 되어 캐시 미스가 발생한다.
• 메모리 사용량 증가
  • 추가적인 메타데이터: 가상 함수 테이블 포인터(vptr) 등 객체 지향 특성으로 인해 각 객체의 메모리 크기가 증가한다.
  • 메모리 단편화: 동적 메모리 할당으로 인해 메모리 단편화가 발생하여 메모리 사용 효율이 떨어진다.
• 복잡한 상속 구조로 인한 유지보수 어려움
  • 상속 계층의 증가: 다양한 엔티티 타입을 지원하기 위해 상속 구조가 깊어지면, 코드의 복잡도가 높아지고 이해하기 어려워진다.
  • 의도치 않은 동작: 상속 및 다형성으로 인해 발생하는 예기치 않은 버그를 디버깅하기 어렵다.

5.2.2 DOD 방식

#include <vector>
#include <cstddef>

// 엔티티 데이터 구조체
struct EntityData {
    std::vector<float> positions;
    std::vector<float> velocities;
};

// 엔티티 업데이트 함수
void updateEntities(EntityData& data) {
    size_t count = data.positions.size();

    // 루프 벡터화를 위해 단순한 연산 유지
    for (size_t i = 0; i < count; ++i) {
        data.positions[i] += data.velocities[i];
    }
}

int main() {
    EntityData entities;

    // 데이터 초기화 (예시로 1000개의 엔티티 생성)
    for (int i = 0; i < 1000; ++i) {
        entities.positions.push_back(static_cast<float>(i));
        entities.velocities.push_back(0.5f);
    }

    // 매 프레임마다 업데이트
    updateEntities(entities);

    return 0;
}

위의 구현을 살펴보면, 기존의 AoS(Array of Struct)에서 SoA(Struct of Array) 방식으로 변경된 것을 알 수 있다. 이를 통해 우리가 기대해볼 수 있는 장점은 다음과 같다.

• 캐시 효율 향상
  • 연속적인 메모리 배치: positions와 velocities 벡터의 데이터는 메모리에 연속적으로 저장된다.
  • 캐시 히트율 증가: 연속된 메모리 접근으로 인해 CPU 캐시에 한 번에 여러 데이터가 로드되어 캐시 히트율이 높아진다.
  • 공간 지역성(Spatial Locality): 인접한 메모리 주소에 접근하므로 캐시의 효율이 극대화된다.
• 오버헤드 감소
  • 가상 함수 제거: 동적 바인딩이 없으므로 함수 호출 오버헤드가 감소한다.
  • 인라인화 가능: updateEntities 함수는 컴파일러가 인라인화하여 함수 호출 오버헤드를 제거할 수 있다.
• 컴파일러 최적화 용이
  • 루프 벡터화: 단순한 반복문은 컴파일러가 자동으로 SIMD 명령어를 사용하도록 최적화할 수 있다.
  • 분기 최소화: 복잡한 조건문이나 가상 함수 호출이 없어 CPU 파이프라인이 효율적으로 동작한다.
• 메모리 사용량 감소
  • 필요한 데이터만 저장: 불필요한 메타데이터가 없으므로 메모리 사용량이 감소한다.
  • 메모리 단편화 감소: 동적 메모리 할당이 최소화되어 메모리 단편화가 줄어든다.
• 데이터 처리의 단순화
  • 일괄 처리 가능: 동일한 연산을 대량의 데이터에 적용하기 쉽다.
  • 병렬 처리 용이: 데이터 간의 의존성이 낮아 멀티스레딩이나 GPU를 활용한 병렬 처리가 가능하다.

요약

• 데이터 배치의 최적화는 캐시 효율 향상으로 이어지고, 이는 곧 프로그램 성능의 향상으로 연결된다.
• 가상 함수 제거로 인해 동적 바인딩 오버헤드가 없어지고, 이는 CPU 파이프라인의 효율적 활용을 가능하게 한다.
• 컴파일러 최적화의 용이성은 코드의 단순화에서 비롯되며, 이는 실행 속도 개선을 가져온다.

5.2.3 파티클 시스템 예제

목표: 대량의 파티클을 실시간으로 업데이트하며, 성능을 최적화한다.

OOP 방식:

class Particle {
public:
    void update() {
        position += velocity;
        life -= decay;
    }
private:
    float position;
    float velocity;
    float life;
    float decay;
};

std::vector<Particle> particles;

// 파티클 초기화
for (int i = 0; i < 100000; ++i) {
    particles.emplace_back(/* 초기값 */);
}

// 매 프레임마다 업데이트
for (auto& particle : particles) {
    particle.update();
}

그런데 위의 구현에는 아래와 같은 문제가 있다.

• 메모리 비연속성
  • 객체의 크기 증가: 각 Particle 객체는 여러 멤버 변수를 포함하므로 크기가 크다.
  • 메모리 배치의 비효율성: std::vector<Particle>은 내부적으로 연속된 메모리를 사용하지만, 객체의 크기가 커서 캐시 라인에 더 적은 수의 객체가 들어간다.
  • 캐시 미스 증가: 루프 내에서 각 객체의 데이터를 접근할 때 캐시 미스가 발생할 가능성이 높아진다.
• 함수 호출 오버헤드
  • 인라인화 제한: 멤버 함수 update()는 인라인화되지 않을 수 있으며, 함수 호출 오버헤드가 발생한다.
• 컴파일러 최적화 어려움
  • 복잡한 데이터 구조: 객체 내부의 데이터에 대한 의존성이 높아 컴파일러가 벡터화 최적화를 수행하기 어렵다.
• 메모리 사용량 증가
  • 불필요한 데이터 저장: 모든 파티클이 동일한 속성을 가지는 경우에도 각 객체마다 데이터를 저장하여 메모리 낭비가 발생한다.

DOD 방식:

struct ParticleData {
    std::vector<float> positions;
    std::vector<float> velocities;
    std::vector<float> lives;
    std::vector<float> decays;
};

void updateParticles(ParticleData& data) {
    size_t count = data.positions.size();

    // 루프 벡터화를 위해 단순한 연산 유지
    for (size_t i = 0; i < count; ++i) {
        data.positions[i] += data.velocities[i];
        data.lives[i] -= data.decays[i];
    }
}

ParticleData particles;

// 파티클 초기화
for (int i = 0; i < 100000; ++i) {
    particles.positions.push_back(/* 초기값 */);
    particles.velocities.push_back(/* 초기값 */);
    particles.lives.push_back(/* 초기값 */);
    particles.decays.push_back(/* 초기값 */);
}

// 매 프레임마다 업데이트
updateParticles(particles);

이렇게 구현을 변경했을 때 우리가 얻을 수 있을 것으로 기대되는 장점은 다음과 같다.

• 메모리 접근 효율 극대화
  • 데이터의 연속성: 각 속성별로 데이터를 연속된 메모리에 저장하여 캐시 효율을 높인다.
  • 캐시 히트율 향상: 루프 내에서 인접한 메모리 주소를 순차적으로 접근하므로 캐시 미스가 감소한다.
• 벡터화 최적화 가능
  • 단순한 연산 구조: 각 속성별로 동일한 연산을 수행하므로 SIMD 명령어를 사용한 벡터화가 가능하다.
  • 컴파일러 최적화 지원: 컴파일러가 자동으로 루프를 벡터화하여 성능을 향상시킨다.
• 메모리 사용량 최적화
  • 필요한 데이터만 저장: 파티클별로 필요한 속성만 저장하여 메모리 낭비를 줄인다.
  • 메모리 단편화 최소화: 동적 할당을 최소화하여 메모리 관리 효율을 높인다.
• 병렬 처리 용이
  • 데이터 독립성: 파티클 간의 데이터 의존성이 없으므로 멀티스레딩이나 GPU를 활용한 병렬 처리가 가능하다.
  • 스케일링 가능성: 데이터 양이 증가해도 병렬화를 통해 성능 저하를 최소화할 수 있다.
• 함수 호출 오버헤드 감소
  • 단일 함수 사용: updateParticles 함수 하나로 모든 파티클을 업데이트하여 함수 호출 오버헤드를 줄인다.
  • 인라인화 가능성: 단순한 함수 구조로 인해 컴파일러가 인라인화하여 성능을 개선할 수 있다.

6. 복습

이번 글에서 특히 중요한 용어들을 다시 한 번 짚고 넘어가자.

• CPU 캐시(Cache)
  • 정의: CPU와 메인 메모리 사이에 위치한 고속 메모리로, 자주 사용되는 데이터를 저장하여 메모리 접근 속도를 향상시킨다.
  • 계층 구조: 일반적으로 L1, L2, L3 캐시로 구성되며, L1이 가장 빠르고 용량이 적다.
  • 중요성: 프로그램의 성능은 캐시 히트율에 크게 영향을 받으며, 캐시 효율을 높이는 것이 성능 최적화의 핵심이다.
• 캐시 미스(Cache Miss)
  • 정의: CPU가 필요한 데이터를 캐시에서 찾지 못하고 메인 메모리에서 가져와야 하는 상황.
  • 종류:
    • Cold Miss: 처음 접근하는 데이터로 인해 발생.
    • Conflict Miss: 캐시의 한정된 크기로 인해 발생하는 충돌로 인한 미스.
    • Capacity Miss: 캐시 용량이 부족하여 발생.
  • 영향: 캐시 미스가 발생하면 메모리 접근 지연이 생겨 프로그램의 성능이 저하된다.
• 동적 바인딩(Dynamic Binding)
  • 정의: 프로그램 실행 중에 함수 호출이 결정되는 방식으로, 가상 함수를 통해 구현된다.
  • 가상 함수 테이블(V-Table): 클래스의 가상 함수 주소를 저장하는 테이블로, 동적 바인딩 시 사용된다.
  • 오버헤드: 동적 바인딩은 추가적인 메모리 접근과 연산을 필요로 하여 성능에 부정적인 영향을 줄 수 있다.
• 벡터화(Vectorization)
  • 정의: 하나의 명령어로 여러 데이터를 동시에 처리하는 기술로, SIMD 명령어를 활용한다.
  • SIMD(Single Instruction Multiple Data): 동일한 연산을 여러 데이터에 동시에 수행하는 병렬 처리 방식.
  • 장점: 벡터화를 통해 연산 속도를 크게 향상시킬 수 있다.
  • 조건: 데이터가 연속적이고, 연산이 단순하며, 데이터 간 의존성이 없어야 한다.
• 메모리 단편화(Memory Fragmentation)
  • 정의: 메모리 할당과 해제가 반복되면서 사용되지 않는 작은 메모리 조각들이 생겨 전체 메모리 사용 효율이 떨어지는 현상.
  • 종류:
    • 외부 단편화: 사용되지 않는 메모리 블록들이 흩어져 있어 큰 메모리 요청을 처리할 수 없는 경우.
    • 내부 단편화: 할당된 메모리 블록 내에 사용되지 않는 공간이 남아 있는 경우.
  • 해결 방법: 메모리 풀(Memory Pool) 사용, 메모리 할당 전략 개선 등이 있다.
• 공간 지역성(Spatial Locality)
  • 정의: 한 번 접근한 메모리 주소 근처의 주소를 곧바로 다시 접근하는 경향.
  • 중요성: 공간 지역성을 높이면 캐시 효율이 향상되어 프로그램 성능이 개선된다.
  • 관련 개념: 시간 지역성(Temporal Locality)은 동일한 메모리 주소를 짧은 시간 내에 반복해서 접근하는 경향을 말한다.
• 인라인화(Inlining)
  • 정의: 함수 호출을 함수의 본체로 대체하여 함수 호출 오버헤드를 제거하는 컴파일러 최적화 기법.
  • 조건: 함수가 충분히 작고, 컴파일러가 인라인화가 성능에 도움이 된다고 판단할 때.
  • 제한 사항: 가상 함수나 재귀 함수는 인라인화가 불가능하거나 제한적이다.

이러한 용어들은 이번 글에서 데이터 중심 설계(DOD)의 중요성을 이해하는 데 핵심적인 개념들이다. 특히 CPU 캐시의 작동 원리와 캐시 효율이 프로그램 성능에 미치는 영향을 잘 이해해야 DOD의 장점을 최대한 활용할 수 있다.

7. 앞으로의 방향

이번 글을 통해 DOD가 가질 수 있는 기술적인 이점을 조명해보았다. 앞으로 이 시리즈를 통해 기존에 흔히 알려진 OOP 방식의 프로그래밍이 자칫 재앙적인 성능 하락을 일으킬 수 있는 부분들을 찾아 자세히 살펴보고, DOD관점에서 재설계를 해보며 다양한 실험들을 해보고자 한다. 이 과정을 통해 한 사람의 프로그래머로써 우리가 개발한 프로그램이 실행되는 하드웨어와 보다 더 친해지고, 또한 프로그램의 성능을 한계까지 끌어올리는 짜릿한 엔지니어링의 시간을 가져볼 것이다. 

1) CPU vs GPU

resultRGB = colorRGB_0 * (1.0 - alpha) + colorRGB_1 * alpha;
resultRGB = colorRGB_0  + alpha * (colorRGB_1 - colorRGB_0);

위와 아래의 코드는 Algebra관점에서 보면 같은 수식이지만 GPU에서는 처리하는 속도가 아래의 것이 더 빠르다.(그리고 부동소수점 누적오차도 더 적다.) 이것을 Multiply, then Add Operation 즉 MAD Operation이라고 하는데 GPU는 이러한 형태의 연산이 Single-cycle만에 계산되도록 설계되어있기 때문이다. GPU에서는 Interpolation연산이 매우 빈번하게 일어난다. 한 Pixel의 특정값을 결정할 때 두 개의 기준점의 사이값을 취하는 것이 일반적이기 때문이다. 그런데 a와 b사이의 Interpolation 값을 구하는 공식이 x = a + t(b-a) (0<t<1) 즉, MAD Operation인 것을 보면 이러한 속성이 얼마나 유용한 것인지 알 수 있다. CPU의 코드를 짤때도 이러한 MAD Operation이 연산횟수도 더 적고 누적오차도 적어지기 때문에 습관적으로 이것을 사용하면 좋다.

이러한 GPU의 연산능력을 보다 범용적으로 사용하기 위해 General-Purpose GPU(GPGPU)라는 개념이 등장했다. NVIDIA 그래픽 카드 한정으로 CUDA라는 SDK를 활용할 수 있지만 OpenGL과 같이 OpenCL이라는 라이브러리를 사용해서도 GPGPU 프로그래밍을 할 수 있다. 하지만 모든 종류의 연산에서 이러한 GPGPU가 CPU보다 항상 우월한 것은 아니고 일반적으로 서로 종속관계가 없는 다차원의 데이터 즉, 병렬로 연산을 구성하기 좋은 데이터를 처리하는데 유용하다. 가장 좋은 예가 이미지 프로세싱이다. 1920*1080짜리 이미지는 픽셀들이 모두 독립적이기 때문에 2073600차원의 벡터라고 볼 수 있는데(단색 이미지일 때) 어떤 이미지 필터를 개발한다면 픽셀값을 독립적으로 계산하는 것이기 때문에 CPU보다는 GPU를 이용하는 것이 훨씬 효율적일 것이라는 뜻이다.

하지만 아직까지 우리가 사용하는 모든 OS는 CPU기반으로 동작하기 때문에 GPU 연산은 필연적으로 CPU와 연동할 수 밖에 없다. 메모리관리와 스케줄링 등을 GPU로 구현한 OS가 등장한다면 이야기는 달라지겠지만 아마 그보다는 멀티코어 컴퓨팅의 발전을 기다리는 것이 훨씬 합리적일 것이다. 때문에 GPU로 방대한 양의 데이터를 처리하기 위해서는 RAM이나 Disk의 Memory에 있는 데이터를 GPU와 연동된 Memory Unit와 주고받는 과정이 추가된다. 일반적인 컴퓨팅에서도 가장 병목이 일어나는 곳이 Disk Read/Write인 만큼 이 작업이 결코 가볍지 않기 때문에 GPU를 이용하는 것에 있어 세심한 주의가 필요하다. 자칫하면 병렬작업을 CPU로 처리하는 것보다도 느려질 수 있기 때문이다.

2) State Machine

그럼 이 GPU라는 연산장치는 어떻게 사용하는 걸까? 애초에 x86/x64 아키텍처의 연산기에서 돌아가도록 컴파일되는 코드들을 가지고 어떻게 아예 설계가 다른 연산기에서 동작하도록 한다는걸까? OpenGL의 동작원리를 이해하기 위해서는 이 질문에 대해 먼저 생각해볼 필요가 있다. OpenGL은 다른 프로그래밍 언어가 CPU에서 동작하는 언어로 직접적으로 GPU의 자원을 관리할 수 있도록 해주지는 않는다. 대신 GPU의 자원을 하나의 상태기계(State Machine)으로써 취급하여 명령을 전달한다. 따라서 OpenGL은 오로지 헤더로만 이루어져 있고 이에 대한 구현은 GPU 내부에 이루어져 있다. 이런 관점에서 보면 OpenGL은 어떤 라이브러리나 SDK라기 보다는 선언 그 자체로 GPU의 스펙인 것이다. 

다시 정의해보자면 OpenGL의 함수들은 GPU를 포함한 Graphics Hardware라는 상태기계를 제어할 수 있는 명령들이라고 할 수 있다. 이러한 명령집합을 우리의 코드와 함께 엮어서 다양한 방면으로 응용할 수 있는 것이다. 상태 기계란 현재의 상태를 정의하는 수많은 변수의 집합과 같다. 따라서 상태기계의 제어 명령어는 크게 두가지로 나뉠 수 있다. 하나는 상태기계의 변수를 변경하는 State-Changing 명령과 다른 하나는 상태기계의 현재 상태를 사용하여 특정 동작을 수행하는 State-Using 명령이다. 때문에 일반적으로 Native Graphics Context에서는 그림 그리는 함수 한두 줄 만으로도 그림을 그리지만 OpenGL에서 그림을 그리기 위해서는 State-Changing과 State-Using 명령을 순서에 맞게 잘 조합해서 사용해야 하기 때문에 이보다 좀 더 복잡하다.

아래는 화면에 간단하게 삼각형을 그리는 코드이다. 실제로 그림을 그리라고 명령을 내리는 코드는 가장 밑의 세 줄뿐이지만 이것을 수행하기 위해 위에서 어마어마한 전처리가 필요한 것을 볼 수 있다. 이것에 대해 이해하기 위해서는 OpenGL의 렌더링 파이프라인에 대해 이해하고 OpenGL의 어떤 상태집합을 사용할 수 있는지 알고 있어야 한다. 하지만 언제나 OpenGL은 거대한 상태변수의 집합으로 이루어진 상태기계라는 사실을 염두에 두고, 어떤 것이 State-Changing인지 어떤 것이 State-Using인지 구별하며 접근한다면 보다 어렵지 않게 OpenGL과 가까워질 수 있을 것이다.

const char *vertexShaderSource = "#version 330 core\n"
"layout (location = 0) in vec3 aPos;\n"
"void main()\n"
"{\n"
"   gl_Position = vec4(aPos.x, aPos.y, aPos.z, 1.0);\n"
"}\0";
const char *fragmentShaderSource = "#version 330 core\n"
"out vec4 FragColor;\n"
"void main()\n"
"{\n"
"   FragColor = vec4(1.0f, 0.5f, 0.2f, 1.0f);\n"
"}\n\0";
 
 
float vertices[] = {
    -0.5f, -0.5f, 0.0f,
     0.5f, -0.5f, 0.0f,
     0.0f,  0.5f, 0.0f
};
 
unsigned int VBO, VAO;
glGenVertexArrays(1, &VAO);
glGenBuffers(1, &VBO);
glBindVertexArray(VAO);
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);
glEnableVertexAttribArray(0);
glBindBuffer(GL_ARRAY_BUFFER, 0);
glBindVertexArray(0);
 
 
int vertexShader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertexShader, 1, &vertexShaderSource, NULL);
glCompileShader(vertexShader);
int fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragmentShader, 1, &fragmentShaderSource, NULL);
glCompileShader(fragmentShader);
int shaderProgram = glCreateProgram();
glAttachShader(shaderProgram, vertexShader);
glAttachShader(shaderProgram, fragmentShader);
glLinkProgram(shaderProgram);
glDeleteShader(vertexShader);
glDeleteShader(fragmentShader);
 
 
glUseProgram(shaderProgram);
glBindVertexArray(VAO);
glDrawArrays(GL_TRIANGLES, 0, 3);

위의 코드를 실행하면 아래와 같은 결과가 나온다. 삼각형의 색깔은 어디서 결정된 것인지 재미로 한 번 찾아보자.

3) OpenGL Object

앞에서 설명했듯이, OpenGL은 상태기계로써 다양한 상태변수의 집합으로 이루어져 있다. 이 상태변수가 바로 이제부터 다룰 OpenGL Object이다. Object의 종류에는 Texture, RenderBuffer, FrameBuffer, VertexArrayBuffer, UniformBuffer, ShaderProgram 등이 있다. 이러한 Object들을 State-changing 함수를 이용해 값을 설정하여 렌더링에 필요한 정보를 저장한 뒤, State-using 함수를 이용해 화면에 프레임을 렌더링하는 것이다. OpenGL은 렌더링 파이프라인이 이미 정해져 있지만 이 Object들을 개발자가 자유롭게 구성할 수 있기 때문에 다양한 렌더링을 구현할 수 있는 것이다. 아래의 그림을 보자. 버퍼에 저장된 값을 불러온 뒤, Vertex Shader와 Fragment Shader가 실행되고(중간에 Geometry Shader가 종종 포함되기도 한다.), 결과값이 화면에 렌더링 된다. 이러한 과정을 통틀어 렌더링 파이프라인이라고 한다. 예를 들면, Texture Object에 표현하고 싶은 물체의 질감정보를 입력하고, Vertex Object에 3D 물체에 대한 다각형 꼭짓점 정보를 입력한 뒤, Uniform Object에 카메라 변환에 필요한 회전행렬 정보 등을 입력한 뒤 ShaderProgram을 링크한 다음 개발자가 원하는 시점에 OpenGL의 State-Using 함수를 실행하면 화면에 그림이 그려지는 것이다.