GDSC GIST 2기에 떨어졌습니다!

 몇몇 사실들을 되짚어봅시다. 나는 분명히 GDSC GIST 2기에 지원했고, 떨어졌습니다. 그 사실을 알고 나서 맨 처음 한 일은 내 인스타그램 계정에 이 사진을 올린 뒤, 그것을 프로필 상단에 고정하는 일이었습니다. 나는 이 행동은 대부분의 사람들이 하지 않는 비일상적인 행동이라는 것을 알고 있고, 그럼에도 불구하고 합리적인 행동이라는 사실을 알고 있습니다. 나도 부끄러움 같은 인간적 감정을 느낍니다만, 적지 않은 케이스에서 감정은 합리적 사고를 하는 데 방해가 되고 저는 이번의 사례 또한 그런 사례 중 하나라고 느꼈습니다. 요컨대 합리적 사고를 하려면 부끄러움을 뛰어넘을 필요가 있다는 것입니다.

 

 하지만 설명이 약간 부족한 것 같습니다. 이 사실을 집어들고 나서 내가 무슨 생각을 했는지에 대해 여기에 글을 씁니다.

 

 제 기준에서 말하는 거긴 하지만, 면접은 완전히 성공적이었습니다. 다시 말하지만 제 기준에서요. 듣는 사람이 나를 뭐라고 생각하는지에 상관없이, 나는 내가 GDSC에서 하고 싶은 것이 무엇인지를 명확히 말했습니다. 그러니까 던져야 할 질문은 단 하나입니다. "후회할 만한 일이 없었는가?" 이 대답에 "예"라고 대답할 수 있다면 면접은 성공적입니다. 아니라면, 안타까운 일이죠. 저는 여기에 대고 "예"라고 대답할 수 있었습니다.

 

 그러나 그렇다면 문제가 생깁니다. 난 후회할 만한 일을 만들지 않았는데, 대체 왜 나는 지금 이 자리에서 부정적인 감정을 느끼고 있는 걸까? 비유를 하나 들어 봅시다. 여러분이 백준 문제를 풀고 있습니다. 첫 번째 시도에서 "틀렸습니다"가 나왔습니다. A는 살짝 당황하지만, 이내 적당한 edge 케이스를 넣어서 어디가 잘못됐는지 찾을 수 있었습니다. 이제 A의 마음에 근심이란 없습니다. B 친구의 경우는 약간 다릅니다. B 친구는 가능한 모든 edge 케이스를 다 넣어 본 뒤 올바른 결과를 얻었습니다. 인터넷을 뒤져서 10만 개짜리 데이터를 찾아서 넣어 보기도 했습니다. 그래도 올바른 결과를 얻었습니다. B는 언제나 올바른 결과를 얻었지만 B의 마음은 편치 않습니다. 어쨌든 백준 사이트는 B에게 "틀렸습니다"를 보여주고 있기 때문입니다. 참 슬프지 않습니까? 저는 이 글을 쓰는 10월 13일 기준으로 백준을 666문제 풀었고, 이럴 경우 가장 잘 작동하는 해결책이 무엇인지를 경험적으로 알고 있습니다. 가장 확실한 방법은, 코드를 처음부터 다시 짜는 것.

 

 제가 무슨 말을 하고 싶은지 알겠습니까? 계획을 처음부터 다시 짜야 한다는 말입니다.

 

 두 문장은 상당히 모순적으로 들립니다. "후회할 만한 일이 없었다 / 계획을 처음부터 다시 짜야 한다". 하나하나 뜯어 보면, 제 생각에는 그렇게까지 모순적이지는 않다고 생각합니다. 이를 설명하기 위해서는, 결국에는 내가 짜 놓았던 계획이 뭐였는지에 대해 생각해보는 것이 필수적이겠죠. 나는 내가 다음과 같은 일에 관심 있다고 말했습니다. 객체 지향 프로그래밍. 적절한 자료구조를 통한 최적화. C++20. 제네릭 프로그래밍과 간단한 수준의 템플릿 메타프로그래밍. 함수형 프로그래밍과 간단한 수준의 모나드. 그리고 무엇보다도 가장 중요한 디자인 패턴. GDSC 자소서를 다시 들여다봤는데, 대략 이 정도의 관심사가 나오는군요. 이것들은 대부분 제가 개인적으로 작업하고 있는 연습용 프로젝트인 ffffff.cpp 프로젝트에서 튀어나온 것이고, 객지프 기말과제였던 Mint Choco에서 나온 것도 살짝 있습니다. 전자 프로젝트는 저 혼자서 지금까지 1300줄을 작업했고 후자 프로젝트는 2명이서 2200줄을 작업했습니다. Mint Choco를 작업할 때 난 굉장히 행복한 사람 중 하나였으니 ffffff.cpp에 대해 한번 말해 봅시다. 

 

 Mint Choco는 한글이나 Word 같은 걸, 할 수 있는 데까지만 아주 간단하게 구현하는 일종의 토이 프로젝트였죠. (간단한데 왜 2200줄이지...) 이것이 '프로그램'인 데 반해서 ffffff.cpp는 프로그램이 아닙니다. 라이브러리입니다. 라이브러리도 프로그램이라고 부르고 싶다면 할 말은 없겠지만, 어쨌든 ffffff.cpp를 컴파일하면 그 결과는 입력도 없고 출력도 없는 바이너리 코드가 된다는 말입니다. 대충 이 친구가 뭐 하는 친구인지 설명을 하자면, ffffff.cpp는 C++에서의 함수형 프로그래밍을 도와주는 라이브러리입니다. 처음에 이걸 시작할 때만 해도 전 아무 생각이 없었는데, ffffff.cpp를 시작하고 나서 한 2주 됐나? 저는 이 '라이브러리를 만든다'는 게 생각보다 괴랄한 일임을 깨닫게 됩니다. 직접 코드를 보시죠.

 

 무서워 보이지만 사실 별 건 없습니다. 저건 그냥 합성함수를 구현해주는 클래스의 일부분일 뿐이에요. 그러니까 사실 사용법 자체는 합성함수를 배운 고1이라면 누구나 쓸 수 있습니다. 그리고 C++ 특으로 lvalue rvalue 나눠서 복붙 케이스워크해야 되기 때문에, 사실 코드의 4분의 1만 이해하면 나머지 4분의 3은 금방 이해할 수 있어요!

 

 진짜 무서운 건 따로 있겠죠. 이 간단한 합성함수 구현을 만들기 위해 저 사진에만 C++ 개념이 몇 개나 들어갔냐는 겁니다. 대충 열거해 보자면, 

 

 1. 템플릿 2. 컴파일 타임 표현식 constexpr 3. universial reference (&&) 4. 퍼펙트 포워딩 5. 템플릿 파라미터 팩 6. requires 절 7. type_traits 라이브러리 8. lvalue/rvalue 케이스워크 9. std::invoke, std::apply / std::move

 

 뭐... 겁나 많단 말입니다. 라이브러리를 만들기 위해 C++을 잘 알게 되는 건 좋은 일입니다만, 반작용으로 한 가지 문제점이 생깁니다. 이걸 같이 할 사람을 구할 수가 없다는 문제점. 지스트는 좋은 학교입니다. 전전컴 학생이 한 학년당 60명밖에 되지 않는다는 점만 빼면요. 제가 아는 한 저는 이 학교에서 C++을 공부하는 사람을 별로 본 적이 없습니다. 솔직히 말하면, 현업에서 C++을 쓴다는 사람을 단 한 명 만났어요. 저는 데브나이트에서 이 사람을 만난 뒤 매우 큰 환희를 느꼈습니다. "무조건 친해져야겠다!!"라고 생각했어요. 그분은 말하기로는 C++보다는 프론트엔드에 더 자신이 있다고 하셨지만... 상관은 없었습니다. C++을 하는 사람만이 얻을 수 있는 공감대 같은 것이 있어요.

 

 C++을 사용함으로써 얻을 수 있는 X같음은 다른 언어에서는 감히 체험도 하지 못할 소중한 감정일 겁니다. 함수를 쓸 때도 인자에다가 일일이 레퍼런스를 붙여줘야 하고, 똑같은 함수를 const만 뺀 채로 두 번씩 구현해줘야 하며(C++11부터 lvalue/rvalue 레퍼런스가 생기면서 구현해야 할 양이 가끔씩 4배가 되기도 합니다), Java 사용자들은 밥 먹듯이 쓰는 virtual 함수도 최대한 최적화해 보겠답시고 CRTP 같은 이상한 패턴을 만들어내고, 컴파일 타임 타입 안전성을 달성하기 위해 for문도 못 쓰고 recursion만으로 튜링 완전한 Template Metaprogramming을 만들어내는...

 

 혹시 <포드 v 페라리>라는 영화를 보셨나 모르겠습니다. C++을 하는 사람들은 어쩌면 그 레이서들을 가장 닮아 있을 것 같기도 합니다. 말하자면 속도에 미쳐 있는 사람이라는 거죠!

 

 하지만... 레이싱도 관객이 봐 줘야 그걸로 돈도 벌어먹고 하는 것. 저는 GDSC에서 떨어지고 나서, 결국 가장 근본적인 질문을 던져야 할 때가 왔음을 알아차렸습니다.

 

 "결국에 나는 어떤 개발자가 될 건가?"

 

 GDSC 면접을 보기 30분 전, 저는 기술 면접에서 물어볼 만한 질문들을 추리고 있었습니다. 제가 생각했던 질문 리스트는 대략 이렇습니다. 위의 리스트를 다시 가져와 봅시다. 객체 지향 프로그래밍. 적절한 자료구조를 통한 최적화. C++20. 제네릭 프로그래밍과 간단한 수준의 템플릿 메타프로그래밍. 함수형 프로그래밍과 간단한 수준의 모나드. 디자인 패턴. 이 중에서 함수형 프로그래밍은 일단 나올 일이 없습니다(컴파일러 시간에 교수님이 함수형 아는 사람 손 들어 보라고 했더니 나 혼자만 들었던 기억이). 당연히 모나드도 안 나오겠죠. C++20도 기대하면 안 됩니다. 제네릭 프로그래밍도 템플릿 메타프로그래밍도. Trie 자료구조는 물어볼 수도 있겠으나(일단 수만 교수님은 Mint Choco 발표할 때 물어보셨음) GDSC랑은 살짝 방향성이 안 맞는 감이 있으니, 결국 남은 건 세 가지였습니다. 4 Pillars of OOP에 대해 물어보거나, SRP나 OCP 같은 객체 지향 프로그래밍 원칙에 대해 물어보거나, 디자인 패턴 중 하나에 대해 물어보거나. 그래서 나는 스트래터지 디자인 패턴이 뭘 하는 친구인지, 데커레이터는 또 뭐 하는 친구인지, 프록시는 또 뭔지에 대해서 어떻게 하면 쉽게 설명할 수 있을지에 대한 전략을 짜고 있었습니다.

 

 예상한 것들은 모두 면접 문제로 나오지 않았습니다. 그리고는 리드님께 이런 말을 들었죠.

 "아쉽지만 GDSC에서 디자인 패턴 스터디를 만들기는 힘들 것 같아요..."

 

 그렇습니다. 생각해보면 말이죠, 아주 중요한 사실을 잊고 있었습니다. GDSC에서는 웹, 앱, AI/ML 분과를 받지 디자인 패턴 분과를 받지 않는다는 사실. 진짜 너무나 당연한 사실이었는데 말이죠. 그걸 대체 왜 모르고 있었을까요?

 

 하지만 다시 생각해보면, 모르고 있었던 게 아닙니다! 저는 좋아하는 사람 앞에 설 때 빼고는 바보 멍청이가 아니니까요. 전 단지 디자인 패턴을 배우고 싶었기에, 디자인 패턴 스터디를 만들고 싶다고 썼습니다. 그게 다입니다. 그리고 사실은, 진짜로 만들 수 있을 거라고 생각했습니다. 그래도 함수형 프로그래밍보다는 디자인 패턴을 배울 사람들이 훨씬 더 많겠지. 1500쪽짜리 <전문가를 위한 C++> 책 완전 독파 스터디보다는 디자인 패턴 스터디를 할 사람이 훨씬 더 많겠지. 그렇게 생각했어요. 

 

 정말로, 정말로 말입니다.

 

 저는 사실 욕심이 많았습니다. Mint Choco 작업을 할 때 C++로 2명이서 2주 만에 2200줄을 찍어냈을 때, 그 욕심을 처음으로 느꼈습니다. 이거, 잘하면 더 높은 곳까지 갈 수도 있겠다. 2명이서 2주 만에 2200줄을 찍어낼 수 있게 했던 원동력은 당연히 객체 지향 프로그래밍 패러다임입니다. 저는 패러다임에 완전히 경도되어 있었던 인간이었어요. 프론트엔드 같은 실전 기술보다는, 그보다 밑에 있는 이론적인 것들에 더 끌렸습니다. 그리고 객체 지향을 한번 끝까지 공부해 보고 싶었습니다. 그래서 디자인 패턴을 공부하겠다고 했고요.

 

 나는 내가 이 험난한 개발자 업계에서, 상당히 마이너한 무언가를 파고 있다는 사실을 분명히 알고 있었습니다. 디자인 패턴 스터디를 만들겠다는 제안은 꿈과 타협이라는 두 가지 성질을 모두 갖고 있었습니다. "어쨌든 지스트에서는 C++ 스터디 같은 건 못 만들겠지." 같은 생각에서 나오는 타협과, 더 좋은 개발자가 되겠다는 꿈. 저는 어느 날, 이 타협이 실제로는 전혀 타협이 아니라는 사실을 깨달았습니다.

 

 지스트에서는 디자인 패턴 스터디를 만들 수 없습니다. 아마도 말입니다.