metal 관련 영상을 보니, 갑자기 여태까지 봐 왔던 것들이 생각나면서 자연스럽게 "흑역사"가 떠오르네요. 왜냐구요? metal shader 언어가 c++11 기반이라네요. metal api는 [object message]; ... objective-c로 설명되어 있는 거죠. 그러니까, swift를 열심히 보고 있는데, 속도 10배라는 metal은 objective-c 로 나왔고, metal shader라는 건 c++ 이다.. .... 그러니까, c, c++, objective-c, swift를.. 섞어치면 된다는 거죠. 포팅도 좀 해 가면서.. 흠.. ..... 애플 잠깐만.. 잠깐만 이리 와봐.. 야 이런 ㅅㅂㄹX.... 너 설마 LLDM 이니, LLVM 이니 해 가면서 디버깅하면 어셈도 좀 보여 주겠다는 거 아니지.. 아니겠지... 는 무슨 그럴 거 같구만. 야.. 넌 좀 맞아야... 라고 하고 싶은데.. 갑이 애플이니 뭐. ㅠ.ㅠ 머리가 고생해야죠. ㅠ.ㅠ
이런 명언이 생각납니다. "편해질 것이다, 단 안다면"... ㅠ.ㅠ
제가 프로그램을 배운 건 전공으로 배운 게 아니라 인연이 되다보니 90년대 초에 c를 가장한 b 마지막 버젼 정도를 배우게 됩니다. 이 때 흑역사는 처음 생각나는 게.. scanf. 시험에 나오고 틀리고, 엄청 중요한 것처럼.. 그러나.. 지금은 뭐 쓸 일이 없어요. 지금은 함수 자체가 버그다라고 생각합니다. 그 다음은 포인터.. 이건 아주 질기게 이어지는 건데 무려 20년 가까이 제 흑역사의 메인이 되는 겁니다. 지겨워요. 포인터와 배열을 섞어치면서 2중 배열이니, 3중 배열이니, 이게 또 자료구조랑 연결이 되고.. 안 빠지는 곳이 없어요. 하지만, 자바 좀 쓰면서 앞으론 포인터 안 쓸거라 믿게 되죠. 오... 어리석도다. ㅠ.ㅠ 그런 쓸 데 없는 거 신경 안 써도 돼라고 게임 배우는 얘들에게 선언 한 적이 있는데, "최대 흑역사"입니다. ㅠ.ㅠ 뭐 지금이야 포인터로 자료구조 건드릴 일도, 2중 배열 이런 거 쓸 일도 없고, smart pointer니 해 가면서 원래랑 많이 다르니까 우기고 또 우기면 모양만 포인터를 쓴다고 할 수도 있긴 하겠죠.. 아무튼 "최대 흑역사". ㅠ.ㅠ
생각해 보니 쓸데없이 신경 쓴 것들이 엄청 많네요. 예를 들면 performance 속도. 원래 c는 속도는 느리지만 쉽다고 배웠습니다. 그 때는 어셈 쓰던 분들이 꽉 잡고 있던 때라 지금으로 치면.. ... "가장 쉽고 허접해 보이는 지금 언어" 수준으로 쳐다보던 때죠. basic, cobol, fortran 등등이 있긴 했지만, 그 곳이 그런 건 취급도 안 하는 분위기였던지라.. 뭔 분위기가 참. 그래서, 전공도 아니지만 배우게 됩니다. 나중에 잘 쓸 수 있을 거라고 배웠는데.. 개뿔. ㅠ.ㅠ 아무튼, 속도 문제로 c 하는 사람들과 c++ 하는 사람들이 싸우다가, 다시 c++하는 사람들이 자바하는 사람들하고 싸우는 거 보니 참.. 옆에서 보면 어이없슴입니다. 제 흑역사는 아니지만, 많은 사람들의 "흑역사"죠.
그 다음에 c++을 건드리게 되는데, 이유는 object. 프로그램 크기가 커 가니, c로는 못 짜겠다. c++ class를 써라... 재사용이 어떻게, 상속이 어떻고, encapsulation이 어떻고.. 물론, 이런 것들도 흑역사가 됩니다. class단계 재사용은 거의 없지요. third party library가 날라다니는 판에 내가 만든 클래스를 재사용 할 이유가 없잖아요. 좋은 거 나오면 돌아가기만 하는 거 버리고 갈아타야지. 상속??? 이거 아주.. 스파게티 코드를 없애기 위해서 decoupling!!! 이러면서 다른 한 쪽에선 상속이 좋아요.. 이러는 거 아니죠. 상속 때문에 프로그램 짜다가 포기한 적이 있어요. 왜냐? 상속으로 중요 코드가 coupling되어 있었던 겁니다. 커플링?? 커플.. 다 짤라줘야 되는 거죠. 오유 정신!!! 솔로 천국!!! 진실입니다. 상속처럼 꽉 이어진 couple이 어디 있겠어요. 현실 오브젝트를 생각하면 상속이 맞는데, 그러다보니 하나를 건드리면 연쇄적으로 쫙.. 바뀌는데, 그 영향을 이해하는 것도 문제고, 폴리모피즘이라고 썼던 곳에서는 뭔지도 모를 에러가 나고.. 책은 상속을 써라, 이렇게 나오고.. 지금은 interface > inheritnace 라고 되어 있죠. ... 이 때 이후로 책을 좀 불신합니다. 아무튼, 답이 없는 관계로 패턴을 보게 되고, 패턴을 보게 되면서 자바를 보게되는 거죠. 패턴은 자바책이 많았던 지라.
패턴을 보면서 알게 된 사실. encapsulation.. 이게 좀 이상하다는 겁니다. 왜냐? state이나 strategy 쓰다보면, 클래스끼리 정보를 주고 받아야 되는데, 정보 은닉을 하자니 엄청 복잡해지고, 패턴을 아는 사람이라면 인터페이스만 가져다 쓰지, 다른 클래스를 건드릴리가 없거든요. 그러다, python을 좀 보게 되는데, 거기 명언이 있더군요.
질문 : python 변수를 싱글톤처럼 쓰고 싶은데 방법 없나요? 글로벌이라... ㅠ.ㅠ
답 : "잘 쓰면 됩니다."
헉.. 어차피 사람이 쓰는 거 그거 건드리지 말라고 하면 된다는 거죠. 이 때부터 캡슐화는 대충 하게 되고, objective-c로 넘어오니까.. private, public, protected 이런 게 없어요. ... 없네. 파일 범위내에서 서로 접근하는 거라, 상속을 해도 header에 없으면 접근이 안 되는 뭐... 이런 .... 이쯤 되면, 캡슐화는 흑역사가 되는 거죠. 원래 별 신경 안 쓰다가 언어 차원에서 지원을 안 하니, 오히려 더 편합니다.
전공도 아니고, 어찌하다보니 여러 언어를 배우고 되고, 그러다 보니 방법론도 여러가지 알게 됐는데, 폭포수, OOP, TDD 등등.. 뭐 많은 방법을 배워서.. 여기는 전부 써 먹고 있어요. ㅠ.ㅠ 다른 의미의 흑역사. OOP 각 단계가 폭포수에서 쓰던 단계를 적당히 가져오는 거고, TDD는 일견 완전히 달라 보이는데, 이건 알고보면 프로그래머들이 워낙 고수라 하다보니 "패턴" 이런 수준이니. ㅠ.ㅠ "패턴을 활용한 리팩토링"이란 책을 보시면 이해하실 겁니다. 일단, 써 봐 쉽지!!! 많이 쓰다보면 신세계가 보일거야 (폭포수, OOP, 패턴 이런 건 기본 아니겠어 ㅋㅋㅋㅋ) 켄트 이분도 굉장히 애플스런 분인 듯 하네요. 요즘은 아키텍쳐를 봐야 되는지 심각하게 고민 중입니다. 이런 거 까지 알 필요가 없기를. ㅠ.ㅠ
그래서, 결론이 뭐냐구요? metal이 흑역사가 될 것인가? 사실 그건 중요한 게 아니라, 그냥 생각나는 거고, 지금 중요한 것은... 알고 있는 거 전부 다 써야 된다는 겁니다. ...... 애플 쉽게 쓰게 해 준다더니.. ㅠ.ㅠ 스티브 형님도 그렇고 이분들이 참 "뻥"과 "삐끼질"에 일가견이 ......
그러니까 대망의 결론!!!! 일단, opengl 정도는 아시죠. 개념은 그게 그거니까, directX라도... shader 언어야 쉽잖아요. (로직은 잊어주는게.. 정신 건강에.. ㅠ.ㅠ) 그럼 metal를 써 보세요. 빨라집니다. 에라이... 인생 다 그렇지 뭐. ㅠ.ㅠ