어려운 것을 해야겠다는 강박

본론부터 읽고 싶다면 여기서부터 읽으면 된다.

“어려운 것을 해야 겠다”라는 강박은 인정욕이 있는 사람이면 누구나 가지게 된다. 나도 그 중 하나이기도 했고, 여전히 그런 경향을 가지고 있다. 지금 와서 생각해보면 미숙한 결정을 내렸다고 생각할 때가 굉장히 많은데, 가령 이런 것들이 있었다.

학부생 시절의 실수

1. 엄청나게 멋진 동아리 홈페이지를 만들겠다는 강박
   • 2017년 기준으로, 내가 다니던 학교에서는 동아리 홈페이지가 있는 IT 동아리가 없다시피 했었다. 다른 학교는 있는데, 우리학교는 왜 없지? 라는 생각이 들어서 다른 학교에 있는 개발 동아리가 어떻게 운영되어 왔는지 최대한 찾아보기도 했다. 그 중에는 동아리 위키, 동아리 전용 이슈트래커 등등 멋있어 보이는 것들이 있었다.
   • 내가 다른 학교의 동아리 생태계를 부러워했던 만큼, 나도 역시 다른 학교에서 부러워할 수준의 생태계를 만들고 싶었다. 그 중 대외적으로 어필하기 쉬운 수단 중 하나가 IT 동아리로서의 인프라 구축이었다. 그래서 미디어위키 기반의 위키를 도입하고, 레드마인도 직접 설치해보고, 그 외에도 다양한 도구들을 도입해보기도 했다. 당연히 도입은 실패로 끝났다.
   • 어떤 인프라를 도입하는 것의 당위성이 충분히 설득되기 힘들기도 했고, 정말 필요하게 되는 순간도 없었기 때문이다. 단순히 구글 드라이브로 해결이 되는 것들인데 굳이 미디어위키로 지식 관리 시스템을 도입을 해야 했냐면 지금은 굉장히 후회되는 결정이기도 했다. 그 과정에서 불신의 씨앗이 피어나기도 했다.
   • 홈페이지를 만들려는 시도도 여러번 했지만, 만든다는 것 그 자체에만 의미를 두고, 정말로 필요한걸 만들려고는 하지 않았다. 후술할 기술스택 이슈도 있어서 몇번을 갈아엎기도 하고, 이 과정에서도 마찰이 있었다. 결국에는 Github Page에 동아리 소개 페이지를 만드는 것 정도로만 끝냈다.
2. 타 학교와 견줄 수 있는 수준으로 높은 수준의 알고리즘 스터디를 하겠다는 강박
   • 알고리즘 동아리를 대표하고 직접 발품파는 사람이었다보니, 다른 학교에서도 부러워하는 스터디, 혼자 공부하는 것과는 다르게 배워갈 수 있는 스터디를 운영해야 겠다는 강박이 있었다.
   • 가령, 예를 들자면… Brute Force/DP/Greedy/이분탐색/DFS/BFS/다익스트라/Minimum Spanning Tree 등 기본적인 알고리즘을 공부하는 것이 일반적이지만, 여기다 고급 알고리즘 트랙을 개설해서 확률론적 알고리즘/병렬 이분 탐색/아호-코라식/sqrt decomposition 등 난이도가 비교적 높은 것 위주로 강의자료를 준비했다. 물론, 이렇게 해놓고 대회에서 좋은 성적을 얻진 못했다. ¹
   • 사실 나 말고도 비슷한 접근을 했던 사람들도 있었던 모양이다. 그런 사태를 보면서 누군가는 이런 평가를 했었다. "A + B 덧셈문제도 포드-풀커슨 알고리즘으로 푸시겠어요" ^{2 3}

사회로 진출하고 나서의 실수

1. 남들이 시도하지 않는 힙한 기술스택으로 셀프 브랜딩을 해야겠다는 강박
   • Rails라던가 Django라던가 기술스택 베이스는 이미 있었지만, 이력서에 적을 프로젝트 만큼은 Elixir 기반의 웹 프레임워크인 Phoenix로 만들어야겠다는 강박이 있었다. 동아리 홈페이지도 마이너한 스택으로 혼자 개발하려고 했고, 포트폴리오용 프로젝트도 그렇게 접근했다. 실무에서는 혼자 일하는 것이 아니고, 다른 사람들과 같이 일하는 것이기 때문에 같이 참여하는 사람을 고려하는 것이 중요하다는걸 뒤늦게 깨달았다. 마이너한 스택은 필연적으로 리소스가 충분하지 않기 때문에 삽질하는 시간이 심각하게 병목이 되었고, 진행속도는 더디게 되어 완성되는게 없다시피 했다.
   • 결과적으로는 제대로 된 프로젝트를 하나 만든게 없는 사람이 되었고, 이미 알고 있는 기술 스택의 숙련도는 말할 것도 없다. 제품을 잘 만드는 것에는 관심이 없었다. 실전으로 개발할때도 아웃풋이 그닥 좋게 나오지도 못했다.
2. 기술적인 역량을 어필해야겠다는 강박
   • 마이크로서비스 아키텍쳐, 디자인 패턴 도입, 테스트 커버리지 100%, kubernetes 기반의 클러스터 구축 등등 맥락에 적절하지 않은 것들을 내 역량을 증명하기 위해서 도입하려고 했던 적이 있다. 물론, 거기에 충분한 대화가 들어가지 않았고, 고집도 있었다. 흔히들 이력서 주도 개발이라고 표현하는 것인데, 비즈니스적인 임팩트가 없는 것은 물론이고 프로젝트에서 그렇게 필요한 것도 아니었다. 단순히, 나를 위한 것 그 이상 그 이하도 아니었다.
   • 한 때는 이러한 시도 조차 하려고 하지 않는 것을 게으른 것으로 취급하기는 했었다. 지금 생각하면 어리석은 생각이었다. 시도하는 것으로 인해 이후에 유지보수 하는 사람들이 기술 부채로 어떻게 고생을 할 것인지, 시도하는 것으로 인해 독보적으로 얻을 수 있는 장점이 무엇인지 신중하게 생각하지 않는 것이 문제라는 것을 뒤늦게 깨달았다.

이런 실수들을 반복하다보니, 어려운 것을 해야겠다는 강박이라는 것이 여러모로 해로운 것이라는 사실을 깨달았다. 뭐 이미 지난 세월은 지난 세월이고, 앞으로 그런 실수를 반복하지 않으면 된다. 그러기 위해서는 의식적으로 노력하면 된다.

소프트웨어 업계에서는 YAGNI 라는 격언이 있다. You Ain’t Gonna Need It. 즉, 당장 필요하지 않은 기능을 구현하지 말라는 것이다. 이것은 개발자들이 코딩을 할 때, 불필요한 기능을 구현하지 않도록 하기 위한 원칙이다. 여기서 더 나아가서, 어려운 것을 해야겠다는 강박도 마찬가지로 적용할 수 있다. 당장 필요한 것도 아닌데, 어려운 것을 해야겠다는 강박으로 인해 불필요한 시간과 에너지를 낭비해서는 안된다.

시간은 한정되어 있고, 그 시간에 사용할 수 있는 리소스도 한정되어 있다. 그 시간 안에 할 수 있는 노력과 의지력의 총량도 당연히 제한되어 있다. 쉬운 것들 위주로 해내더라도, 어려운 것들을 해내는 것보다 더 적은 노력으로 더 많은 임팩트를 낼 수 있다. 거기다가 어떻게 리소스를 투입해왔고, 어떤 결과가 나왔는지에 따라 나에 대한 신뢰도가 달라질 수 있다. 어려운 것도 해내는 나의 가치를 애써 증명하기 위해, 어려운 것을 해야겠다는 강박은 버릴 필요가 있다. 당장 필요한 순간에 내가 할 수 있는 것을 잘하고, 단순하게 해결하는 것만으로도 애쓰지 않아도 내 가치는 증명이 된다.

위에서 언급한 실수들이 꼭 나쁜 영향을 준 것은 아니었다. 결과적으로 실패한 경험들이긴 했지만, 그 경험들을 통해 배운 것들이 있었기 때문이다. 함수형 프로그래밍을 일찍이 접하면서 가독성있고 예측이 가능한 코드를 짜는 버릇이 생겼고, 어려운 알고리즘을 공부하면서 어지간한 알고리즘 문제는 쉽게 보이게 되었고, 기술 스택 도입에 실패한 여러 경험을 통해 기본을 집중해서 잘해야 한다는 결론에 도달했기 때문이다.

실패하는 과정에서 잃은 사람들도 있었지만, 그 과정에서 얻은 사람들도 많았다.

어려운 것을 시도하는 행위 자체는 나의 성장에 도움이 될 수 있기 때문에 분명 가치가 있다. 어려운 것을 시도하다가 실패할 수도 있다. 실패하는 것이 꼭 나쁜 것만은 아니다. 하지만, 어려운 것을 해내는 나의 가치를 증명하기 위해 나만의 리소스가 아닌 것을 희생하는 행위은 지양해야 한다.