성장
개발을 하면서 다른 개발자들의 역량을 지켜보고 무력감, 압도적인 아우라, 압박감(혹은 긍정적인 마인드셋으로 인한 동기부여)등을 느껴본적이 한번이라도 있는지 궁금하다 필자는 많다. 그 대상이 회사 동료일수때도 있었고 오픈소스에 상주하는 이상한 예술가(?)들로부터 느껴질때도 있었고 같은 나이에 건너건너 들어본 사람에게도 느낀적이 있다. 이런 기회가 누군가에게는 강하게 성장한 기회로 작용하기도 하지만, 누군가에게는 번아웃의 트리거포인트가 될때도 있다.. 왜그럴까?
바로 인지부하 때문일 것 같은데, 소프트웨어라는 학문은 아주 거대하며, 또 거대하고 정말 거대하다(!) 그렇기에 압도적인 누군가를 만나게 되면 오히려 강박감에 이것도 하고 저것도 해야될것같고지금 내가 잡고있는것이 가치없어보이기도 하며 남의 떡을 바라보게 된다. 나또한 그렇다. 당연하다 왜냐고? 소프트웨어 학문은 또 말하지만 아주 거대하고 내가 지금 어느위치인지 얼마나 잘하는지 어떤게 부족한지 파악하기가 굉장히 어렵기 때문이다.
소프트웨어 엔지니어는 프로그래밍이라는 행위를 통해 주어진 미션을 클리어하는 일을 한다. 그냥 클리어도 아니고 최대한 아끼고 최대한 많이 생산해내야 한다. 내가 지금 내린 의사결정이 최고가 아닐것이고 최선도 아닐 수 있다. 그러나 최선이 아닌지 맞는지를 인지하기가 어렵다. 그렇기에 내가 최선이라고 착각할 수도 있다. 개발자의 성장 또한 그러하다. 내가 지금 과연 목표한만큼 성장했을까 나의 위치는 내 연차에 비해 평범한 편일까? 모른다 그걸 정확한 지표로 평가해주는 타인은 어디에도 없을 것이다. (물론 간단한 피드백과 방향성은 조언해주는 사람이 있을 수도 있다.)
그럼 어떻게 나의 위치를 파악하고 내가 지금 가장 필요한 것을 파악할 수 있을까?
회고
질리도록 많이 들어보셨겠지만 그 방법은 회고다. 보통 계획 -> 시도 -> 실패 -> 회고 -> 계획.. 등등의 싸이클에 대한 성장이론을 들어본적이 있을것이다. (용어가 다를 수 있지만 대충 어떤 느낌인지는 감이 올 것이다) 왜 그럴까? 계획하지 않으면 시도할 수 없고, 시도하지 않으면 실패할 수 없으며, 실패하지 않으면 나의 문제점을 찾을수도 없다. 나의 약점은 정말 많다. 그러나 안보일 뿐이다. 보이는데 안보고싶을 수도 있다. 그렇기에 직면해야한다. 메타인지가 되어야한다.
우리의 뇌는 문제를 던져주면 그 문제를 해결하기 위해 연산을 하도록 설계되어 있다. 이것은 생존과도 직결된 문제다. 우리는 배가고프다고 인지하면 밥을 먹어야한다는 결론을 낸다. 주어진 미션이 생존과 가까워 질수록 뇌는 필사적으로 일하기 시작한다. 무게감이 다를순있지만 요지는 물음표를 던지고 그 물음표를 클리어하는것이 중요하다고 본다. 이건 회고 뿐만 아니라 공부에서도 자주 언급되는 내용이다. 일단은 회고하라 분명 나에게는 문제가 많을것이고 단지 지금은 블랙박스 상태일 뿐이다.
그러나 이 블랙박스를 한번에 화이트박스로 만들 수 없다. 그 이유는 나의 단점이 언제 눈에 띄는지 그 상황에 직면하지 않았을 것이기 때문이다. 그렇기에 여러가지를 경험해보라, 여러가지 후회를 하고 여러가지 시도를 해라. 그리고 회고해라 회고하지 않으면 그 경험은 경험이라고 치부할 수 없다. 회고록을 쓰든 이력서를 쓰든 명상을 하며 생각해보든 how는 선택에 맞기겠지만 개인적으로 글로 남기는걸 추천한다. 인간의 뇌는 기억을 쉽게 휘발하기 때문에 기록이라는 행위가 가장 좋다.
글을 작성하는데 무게감도 남다르며, 결과적으로 다시 꺼내볼 수 있다는 특징이 있기 때문이다. 회고록이라고 너무 거창하게 몇천줄 써야하나 생각하지마라 나는 10줄정도만 쓰면 된다고 생각한다 고에 관해서 내가 사용하는 프레임워크는 winswoopswow(www)이다. 잘한점, 아쉬운점, 놀라웠던점이나 발견 등으로 3개 주제로 3~5문장씩 작성해보는건데, 주기는 분기마다 하는걸 추천한다. 단 잘한점으로 나의 강점을 파악하고 아쉬웠던 점을 바라보며 내 강점은 더 살리고 아쉬웠던것을 없애기 위한 전략을 수립하자. 그리고 놀라웠던점은 그냥 추억팔이나 영감용으로 좋다
2차전직
소프트웨어 엔지니어라는 직책은 하나에 분야에 종속되지 않고 여러분야를 넘나들며 개발을 하는 의미를 내포하는 것 같다. (서버, 프론트엔드, DevOps, IoT, SRE 등)
그러나 보통의 개발자들은 자신만의 전공이 존재할 것이다. 그렇지만 이거 하나로 10년을 해먹을 생각이라면 별로 추천하지는 않는다. 안정적인 가치를 존중한다 라는 말은 하지 않겠다. 냐면 하나만 하면 안정적인 시대는 점점 끝나가고 있기 때문이다.
당신이 서버 개발자고 성장에 목이 말랐다면 서버에 대해 깊이있게 공부할 것이다. 그러나 언젠간 웬만한게 다 알고있는 지식이며 복습이 8할이 넘는 순간이 올거다. 때는 더 딥다이브를 할수도 있고 물론 서버기술자체가 그정도로 다 공부할 수 있을만큼 좁은 분야도 아니고 방대하지만 일하면서, 개발하면서 필요한 내용은 쉽게 마스터할 수 있다고 생각하는 편이다.
그럼 이제 뭘할까? 2차전직을 해야지, 머신러닝에 관심이 있으면 머신러닝을 공부해라 DevOps가 관심있다면 그쪽 분야를 공부해라
zero부터 다시 시작해야 될 것 같으신가? 먼길을 또 돌아야한다고 생각하시나요? 절대 아니다. 당신이 이전에 학습하고 쌓아놨던 경험은 더욱 빠르게 진리로 도달하게 도와줄 것이다. 분야에 1퍼센트보다 두 분야에 25퍼센트이 되는것이 더욱 달성하기 쉽고 성공한다는 말을 한다. 틀린말은 아닌것같다. 당연히 25퍼씩 되는건 쉽다. (25퍼 자체도 어렵겠지만 1퍼보다는 압도적으로 쉬운것은 사실이다. 지구에서 1퍼센트는 매우 어렵다)
그렇기에 다양하게 배워봐라. 그러나 하나만 명심해줬으면 한다. 당신이 하고싶은 것을 2차 전직으로 써라, 하고싶지도 않은데 의무적으로 해야할거같아서 책을 피는것은 삼가해줬으면 한다.
결론
개발자라는 직업의 직무는 굉장히 어려울 것 같지만, 사실은 또 가장 단순한 것 같다. 비즈니스를 코드로 구현하고, 개선하고, 자동화한다. 그리고 새로운걸 다시 구현하고 개선하고 자동화한다.
여기서 더 나아가면 하이앤드 레벨의 쿼리를 짜거나 시스템을 튜닝하거나 혹은 매니징과 결합해 조직의 생산성을 늘려볼 수도 있다. 결과적으로는 매니징이든 제네럴리스트든 한 분야만 파면 안된다는 결론이 나온다. 개발자의 역량에 대한 공식은 깊이 뿐만이 아니다. 깊이에 너비를 곱할수도 있다.
역량 = 깊이 x 넓이
당장 당신이 필요하다고 생각하는 역량이 깊이기반이라면 2차전직은 추천하지 않는다. 왜냐면 당신은 지금 맡은 분야에 소프트웨어 학문을 아직 당신이 만족한 기준만큼 성장하지 않았다고 스스로 생각하는 것이니까. 개발을 하다보면 슬슬 이정도면 다른거 해보고싶다 라는 생각이 들때가 있을거고 그 what이 명확해졌을때 슬슬 시작해보길 바란다. Hello World로 시작해보자.
개발자의 성장은 시도와 실패 회고의 반복이다, 이건 사업가들의 성공 공식과 비슷한 양상을 뛰지만 다른점은 부담감인 것 같다. 실패해도 괜찮다 다시 시도를 사업보다 더욱 자유로이 더욱 넓게 할 수 있으니까.
그것이 내가 생각하는 소프트웨어 개발에 대한 매력이 아닐까 싶다.
