yuchi's development

C++이 일반화되면서 아주 바보같은 관행이 생겼는데 나는 이걸 ‘멍청한 추상화’라고 부른다.

소켓 프로그래밍을 처음 시작하면…열에 아홉 정도는 CSocket이란 클래스를 만든다. 18년전에 나도 그랬다.
18년전에 내가 짠 코드는 똥이었다. 그리고 그 시절이나 지금이나 소켓 프로그래밍 초짜들이 만드는 CSocket은 십중팔구 똥이다.

단순히 소켓 디스크립터를 랩핑하고 관련 함수를 몇개 넣은 이 클래스는 대개 block mode에 싱글스레드를 기준으로 만들어진다.
여기서 I/O모델이 바뀌면 멀티 스레드가 들어가고 작동 방식이 왕창 바뀐다.
IOCP / select poll / Event Select 등등 I/O모델이 바뀌면 대개 살릴 수 있는 코드가 거의 없다.

예전에도 몇번인가 말한적 있지만 여기선 다이어그램 이쁘게 그려가며 설계(라 쓰고 허세라 읽는다)를 해봐야 소용이 없다. 실제 동작원리를 빠싹하게 알기 전엔 쓰레기같은 추상화만 반복할 뿐이다.

DirectX프로그래밍을 하면 대개 CVertexBuffer와 CIndexBuffer 그리고 CTexture를 만든다. 음..이 경우는 DX 7->8->9->11까지도 약간의 유지보수를 거쳐 계속 사용하곤 한다.
근데 DX12가 되면 살릴 수 있는 코드가 없다. API이름이 바뀐게 문제가 아니고 DX12에서 멀티스레드를 필히 써야하고 리소스 리네이밍같이 드라이버에서 자동화해서 지원해주는 것들이 몽창 빠지다보니 단순히 캡슐화한 코드는 쓸수가 없다. 오히려 디버깅하다보면 빌어먹을 클래스들을 하나씩 벗겨내게 된다. 결국 시간 지나고 보면 다 분해해서 최대한 raw API호출을 한 상태로 전체적으로 재설계에 들어갈 수 밖에 없다.

나는 가능하면 추상화 하지 말자는 주의다.
성능 문제는 일단 접어두고 제일 큰 문제는 어설픈 추상화야말로 코드를 알아보기 어렵게 만드는 주범이기 때문이다.

대개는 무조건 추상화부터 하려고 한다. 해당 플랫폼과 API에 대해서 빠싹하게 아는게 아닌데 추상화부터 한다. 그래서 결함(버그가 아니다)투성이의 클래스가 만들어진다. 물론 그걸 되게 뿌듯해하지. 그리고 재앙이 시작된다. 후임자가 결함을 고치려면 그 빌어먹을 클래스를 뜯어내야 한다. 이것도 후임자가 실력있고 의욕있을때나 가능하다. 보통 후임자들은 전임자보다도 더 떨어지는 경우가 많으므로 그 이해할 수 없는 클래스를 뜯어내기 보단 그 위에 한겹 더 씌운다.
그리고 다음 후임자는 또 위에다 바보같은 클래스를 씌운다. 전임자의 코드는 똥으로 보이는 경향이 있는데 그래서 그 똥을 보지 않으려고 그 위에다 클래스를 또 씌운다. 야 전임자 코드가 똥같으면 차라리 그 클래스 뽀개고 새 클래스로 대체해. 위에다 또 씌우지 말고.

크로스 플랫폼 지원을 위해 추상화가 필요하다고도 주장하는데 틀린 소린 아니다. 그런데 그 방법이 또 문제다.
아까처럼 소켓 디스크립터를 감싸는 정도의 CSocket따위로 크로스플랫폼 지원이 될것 같아? 전혀 아니올시다.
여기서 가장 큰 문제는 최초로 추상화를 시도하는 시점에서, 예를 들면 CSocket을 처음 만들던 시점에서 여러 플랫폼에 대한 이해가 없는 경우가 많다는 것이다. Windows 기반에서 CSocket을 만들었을 당시에, 리눅스라든가 다른 플랫폼의 소켓 API에 대한 지식이 없을 가능성이 매우 높다.(대부분의 경우 다른 플랫폼은 고사하고 Windows에서 제공하는 I/O모델만 해도 엄청 많은데 그중에 하나도 제대로 아는게 없다.)
물론 대부분의 경우 처음짠 네트워크 코드가 정상작동할리 없으므로 정말로 크로스플랫폼 지원을 해야할 날은 오지 않지만. 하여간 크로스 플랫폼 지원할 날이 왔을때 이런 식으로 만든 클래스가 전혀 도움이 되지 않는다.

경험상 다른 플랫폼으로 갈때는 차라리 베이스로 하나의 OS, 하나의 API를 결정해두고 가는 것이 좋다.
win32가 주플랫폼이라면 그냥 win32로 짜고 다른 OS의 버전에서 win32 API와 모양이 똑같은(혹은 거의 같은) 함수 껍데기를 만들고 그 안에 해당 OS에서 비슷한 기능을 구현하면 된다.
이렇게 하면 적어도 멍청한 추상화 클래스를 모두 숙지할 필요가 없다. 하나의 OS에만 익숙한 프로그래머라도 다른 OS의 버전도 작업할 수 있다. 가장 좋은 점은 확실히 동작하는 신뢰할 수 있는 버전이 하나는 존재하게 된다는 것이다.

그리고 계속 언급했지만 멀티스레드라든가 비동기 I/O에 관련해서 함수단위로는 똑같은 기능을 보장하기 어려울 수 있다.
따라서 크로스플랫폼을 위한 추상화라면 개별 함수의 작은 단위의 기능보다는 좀더 큰 단위의 기능으로 추상화하는 것이 낫다.
그래픽스의 예를 들면 CVertexBuffer와 CTexture보다는 RenderBox()라든가 RenderCharacter()라는 식으로 큰 덩어리의 기능을 추상화시켜서 각각 구현하는게 훨씬 현실적이고 유연하다.

정리한다.
내가 전에 설계하지 말라고 한적 있지?
설계 뽕, C++ 뽕, 객체지향 뽕, 디자인패턴 뽕 맞은 이들에게 고하노니…
빠싹하게 내부를 알기 전엔 추상화도 하지 마라.
그 추상화 똥될거 뻔하거든.

잠이 안오는데 갑자기 지난 18년간 API돌아가는건 하나도 모르면서 미친듯이 쓰레기같은 추상화를 해왔던 놈들(물론 초창기의 나도 포함해서)이 생각나서 적어봤다.