feat. 클럽하우스
지난주 목요일에는 클럽하우스를 틀어놓고 하루 종일 나무를 깎았다. 오전 5시에 일어나기 시작하면서부터 우드 카빙을 하는 취미가 생겼다. 주문한 조각칼과 블랭크라고 부르는 만들어질 물건에 맞게 잘린 나무토막을 가지고 젓가락을 깎으면서 나는 조금 신난 상태다.
마침 연휴가 시작되었으니 잠깐 동안 나무를 깎으며 시간을 보내는 김에 지난주에 설치만 해놓고 켜보지도 않은 클럽하우스를 한번 써보면 좋겠다는 생각이었다. 이후 내가 정신을 차리고 일어났을 땐 이미 6시간이 지난 상태였다. 저녁 6시쯤 앉아 작업을 시작했는데 일어날 땐 자정이 다 되어 있었다. 왜 사람들이 클럽하우스에서 헤어 나올 수 없다는 건지 이해가 되었다. 나는 저녁 루틴을 할 시간을 놓쳤다는 게 충격이었는데 더 충격적인 건 저녁 8시에 지인과 온라인 약속을 완전히 잊고 말았다는 것이다. 그 충격 때문에 이후로 클럽하우스에는 들어가지 않고 있다.
아무튼 그날 내가 있었던 방은 개발자들이 가벼운 스몰토크를 하는 방이었는데, 의도는 그런 거였지만 어쩐지 진로상담처럼 비전공자나 취준생, 학생분들이 여러 가지 질문을 하고 패널(?)이라고 해야 할지 상주하고 있는 토커들이 대답을 해주고 있었다. 사실 최근 관심사가 좋은 사람을 만나고 같이 일하는 것이었기 때문에 취업을 하고자 하는 사람들이 어떤 고민을 하고 있는지 어디에 관심이 있는지 자연스레 귀 기울이게 되었다. 그리고 현업에 계신 분들이나 면접을 해본 실무자들의 입장도 궁금했다. 좋은 사람을 뽑을 수 있는 팁이 있을 것 같았기 때문이다.
생각보다 해외에 살며 개발을 하고 있는 사람들이 그 자리에 많이 있었고, 내가 들어갔을 땐 해외취업에 대한 이야기를 하고 있었다. 그다음은 취준생, 개발자로 전향하고자 하는 사람, 컴퓨터공학과 학생, 개발자는 아니지만 마케팅 또는 개발자와의 업무를 위해 개발 지식을 알고 싶은 사람 등등 다양한 상황의 사람들이 질문을 했다.
즉석 질문에 답을 하는 자리라 깊은 이야기가 나올 수 있는 상황이 아니었다고는 하지만 질문자의 질문도 답변자의 응답도 뭔가 아쉽다는 느낌을 받을 수밖에 없었는데 다른 분야도 마찬가지이겠지만 개발자라는 직업 역시나 직접 실무를 경험해보지 않은 사람들에겐 명확하게 이해되지 않는 장벽이 있다는 걸 느꼈다.
그건 경험해보지 못한 사람의 unknown unknown 같은 것이다. 이전에 "모르는 것을 모른다는 것"이란 글을 쓴 이후로 이 내용을 인용할 때가 꽤 많다는 걸 느끼고 있다. 개발을 할 때도 이 영역이 적용이 되는데, 개발하면서 어려운 부분 중 하나가 자원을 예측하는 것이다. 예측이 불가능하다는 것을 알기 때문에 많은 기업들이 애자일 방식으로 개발 프로세스를 바꾸고 있긴 한데, 그럼에도 예측이 선행되지 않으면 일이 진행되지 않기 때문에 예측을 해야 한다는 사실이 좌절스러울 때가 많다. 이럴 때 일정은 거의 찍기나 다름없기 때문이다. 개발자들이 공부를 되게 많이 하는 이유는 도태되지 않기 위해서도 있겠지만 이런 불확실한 상황을 줄이기 위해서 더 많은 지식을 갈구하는 사람들도 많을 것이라 생각한다.
개발을 해보지 않은 사람들은 곧바로 이런 unknown unknown 영역을 마주하게 된다. 그렇기 때문에 질문이 본질을 벗어나는 경우가 생길 수밖에 없다. 그래서 실무자가 보았을 때는 왜 그런 고민을 하는 건지 이해할 수 없는 질문을 하게 되는 것이다. 그래서 많은 대답들이 어차피 신입에게 큰 기대를 하지도 않고 들어오면 다시 배우니까 걱정하지 말라는 전혀 도움되지 않는 말로 수렴이 되어버리는 것 같다.
그런데 정말 실제로 경험하는 수밖에 없는 걸까? 나는 학교를 다닐 때에도 항상 궁금했었다. 도대체 이 과목들이 내가 무슨 일을 할 수 있도록 도움을 주는 걸까? 운영체제는 어디에 도움이 되는 걸까? 자료구조는? 알고리즘은? 이 과목들은 컴퓨터공학에서 필수적이고 중요한 과목에 속한다. 도대체 왜 그런 거지? 난 이것들이 중요하다고 해서 열심히 배우긴 했지만 지금에 와서 느끼는 건 다 헛소리라는 것이다.
특정 분야나 도메인, 어떤 역할을 맡을지가 명확하지 않으면 중요한 것도 정할 수가 없다. 모든 개발자가 자료구조나 알고리즘을 잘해야 한다고 생각하지만 사실은 그렇지 않다. 당신이 프런트엔드에 관심이 있으면 알고리즘을 활용할 일은 거의 없다. 백엔드 개발자여도 특수한 경우를 제외하고는 알고리즘을 직접 짜는 경우가 드물다. 많은 컴퓨터공학 학생들과 비전공자가 혼란스러워하는 이유는 왜 해야 하는가에 대한 콘텍스트가 없기 때문이다. 언제 어떤 상황에서 이런 알고리즘이 필요하다는 이야기가 나와야 하는데 그냥 알고리즘이 중요하다고 하면 뜬구름 잡는 소리일 뿐이다.
중요한 것은 모든 개념과 언어는 특정 상황에서 특정 필요에 의해 만들어졌다는 것이다. 내가 배우는 것이 어떤 상황에서 왜 필요할까를 이해한다면 즉, 배움의 목적을 이해한다면 불필요한 학습방식을 버릴 수 있고 더 빨리 목표에 도달할 수 있다. 그러면 개발을 배우고자 하는 사람들이 물어야 할 질문은 뭘까? 먼저 스스로가 어떤 분야에 관심이 있는지를 자기 자신에게 물어봐야 한다. 지속할 수 있는 힘이 거기서 나오기 때문이다. 자신이 사람들을 즐겁게 만드는 데 설레는지 사람들이 더 나은 환경에서 더 나은 사람이 될 수 있도록 돕는데 설레는지 무엇이 자신에게 뛰쳐나가고 싶은 힘을 주는지를 생각해보자. 자기 자신이 아니라 타인을 생각하는 이유는 이미 목적이 자기 자신을 향해 있기도 하고 결국 개발을 하는 건 누군가를 위한 제품을 만드는 일이기 때문이다. 취미로 하는 게 아니라면 말이다.
그런데 그걸 찾은 게 어려울 수는 있다. 그래서 다양한 분야의 기초개념을 익히는 것이라고 한다면 필수과목들이 조금은 이해가 된다. 물론 그 과목들이 어디에 필요한 것인지 알았을 때 말이다. 사실은 각 과목은 백그라운드를 형성하는 내용이 많아서 원하는 도메인, 원하는 업무와 일대일 매칭이 되지 않을 수도 있다. 더 나은 방법은 관심 가는 회사들이 어떻게 일하는지 지켜보는 것이다. 그리고 소프트웨어 프로젝트가 어떻게 진행되는지 전체적인 구조를 알고 있으면 좋다. 그건 도메인에 따라 조금씩 달라지긴 하지만 비교적 독립적으로 할 수 있는 또는 해야 하는 일에 대한 콘텍스트를 이해할 수 있는 뷰를 제공하기 때문이다.
소프트웨어 공학에 대한 수업이 있다면 꼭 들어보길 권한다. 학교에서도 이 과목은 조금 등한시되는 경향이 있긴 한데 학교를 다니지 않고 다른 방법으로 배운다면 더더욱 접하기가 어려운 것 같다. 대부분 코딩을 먼저 배우게 되는데 프로그래밍 스킬이 필수적인 것은 사실이지만 그것만으로는 할 수 있는 일의 단편적인 것밖에 이해하지 못한다.
정리하자면 전체적인 시각을 가질 수 있는 방법, 지식이 필요하다는 것이다. 전체적인 시각을 볼 수 있는 방법은 특정 언어를 공부하는 것도 영어를 배우는 것도 아니다.
그리고 알아둬서 나쁠 거 없으니까 배우는 게 좋다는 논리는 정말 최악일 수밖에 없다. (이걸 알고리즘에서는 Brute-force라고 부른다.) 우리의 시간은 한정되어 있고 우리가 바라는 목적을 달성하는데 필요한 것들을 익히는 데만도 시간이 부족하다.