글은 진작에 작성했었지만 머뭇거리고 오랫동안 만지작거리다가 반년이 넘게 흘렀네요. 지금이라도 이렇게 올려봅니다.
기반 공부 더 열심히 하기
중학교까진 몰라도 고등학교만큼은 정말 열심히 공부를 했을 것 같습니다. 특히 영어하고 수학만큼은 아주아주 열심히 할 것 같아요. 아마 이 글을 보시는 분들은 이미 이 그 시기가 지나신 분이실 겁니다. 시기적으로는 이미 늦었죠. 그 시기는 돌아오지 않더라도 커리어 초반부터 기술과 동일하게 꾸준히 학습한다면 충분히 따라잡을 수 있다고 생각합니다.
대부분의 기술문서는 일단 영어로 처음 작성됩니다. 영어를 잘해야 새로운 기술을 더 빨리 배울 수 있고요. 양적으로도 영어로 만들어진 문서가 제일 많습니다. 스택오버플로도 영어를 사용하고요. 영어를 잘하면 검색을 정확하게 잘 할 수 있고 나오는 결과 역시 빠르게 잘 이해할 수 있죠. 그것뿐인가요. 대부분의 개발 언어들이 영어를 사용하기 때문에 실별자 네이밍에서도 영어 센스가 많이 필요합니다. 네이밍이 개발의 절반 이상에라는데에는 대부분의 개발자들이 동의하고 있죠.
영어를 잘하면 한국을 넘어 해외나 외국계 기업에도 취업할 수 있습니다. 세계적인 기업에서 일할수 있는 "기회"가 생길 수 있죠. 한국 개발자분들은 실력이 뛰어나신 분들이 많아서 영어만 된다면 해외 어디서든 인정받습니다. 저는 그나마 영어라도 열심히 공부한 편이라 이렇게 지금까지 개발자로 먹고사는 것 같아요. 그렇다고 술술 잘 읽는 것도 아닙니다. 모르는 단어도 많아서 사전도 찾고 구글 번역도 돌려가며 읽습니다. 일단 영어 공포증은 없습니다. 지금 이렇게 먹고사는 데에는 영어가 50% 이상은 했다고 생각합니다.
수학에 대한 생각은 개발자마다 다릅니다. "개발자에게 수학이 필요한가요?"라는 질문에 다양한 의견이 나오죠. 저는 수학은 개발 분야의 한계를 결정하는 요인 중에 하나라고 생각합니다. 저는 음악을 좋아해서 VSTi라는 기술을 이용해 가상악기를 만드는 것에 도전했었는데요. 프로그래밍 언어나 개발 환경 등은 아무 문제 없이 적응했었지만 오디오 기술에 대한 수학적인 내용들을 감당하기에는 너무 방대했어요. 수학 공부를 뒤늦게 열심히(?) 해봤지만 갈길이 멀었어요. 결국 그사이 목표가 조금 바뀌어서 잠시 접었지만 수학을 애초에 잘했던 사람이라면 목표가 바뀌기 전에 뭐 하나라도 해봤지 않았을까 싶습니다. 이렇게 수학을 포기한 자. 수포자라는 계급(?)을 뛰어넘는 게 너무 어렵습니다. 이점을 노린 책도 많이 나왔죠. 수학은 내가 하고 싶은 개발 분야로 진입하는데 걸림돌이 될 수 있구나라고 생각했습니다.
최근 중학생이되어 프로그래밍에 관심을 갖게된 조카에게 학교 공부가 중요하다고 말해주면서 영어와 수학만큼은 특별히 친해지라고 했습니다. 이렇게 말하고보니 제가 중학교때 귀가 닳도록 들었던 말 이기도 합니다. 잘 안 먹히겠네요.
작은 회사에서 많은 경험하기
우선 첫 회사는 작은 스타트업에서 많은 경험을 하고 싶습니다. 사실 1회차 때도 작은 웹에이전시부터 시작했지만 지금은 업계 환경이 달라졌으니 작은 스타트업에서 "우리" 서비스를 잘 만드는데 집중하면서 다양한 기술 분야에 경험을 쌓을 것 같습니다. 스타트업도 규모에 따라서 천차만별이지만 작은 스타트업이라면 (어쩔 수 없이) 다양한 기회가 주어질 거라고 생각합니다. 기술적으로는 적은 분업률에 기대어 BE, FE, 서버 인프라, 모바일까지 다양한 분야에 도전할 수 있는 기회를 얻을 수 있을 것이고요. 두각을 나타낸다면 일찍부터 일부 파트를 리딩 할 수 있는 기회나 조직장도 될 수 있겠죠. 규모가 있는 기업에서는 분업이 잘되어 있어 좀 더 깊이 있게 접할 수 있을 수는 있겠지만 다양한 경험을 하긴 힘듭니다. 리딩 할 수 있는 기회도 비교적 뒤늦게 얻을 수 있죠. 그게 잘못됐다는 건 아닙니다. 이렇게 가나 저렇게 가나 결국 분업된 한 부분의 전문가는 돼야겠죠. 다양한 경험은 덤이고요.
지금까지 그래왔듯 언제 어떻게 변할지 모를 이 바닥에서 발 빠르게 변화하고 적응할 때, 이런 다양한 경험들은 좋은 바탕이 될 수 있습니다. 특히 저 같이 비전공자 + 다른 일하다 전직한 사람은 정말 큰 도움이 됩니다. 지금 내가 하는 개발 분야는 현재 내가 좋아서 선택한 것이지 다른 분야를 못해서 나 어려워서가 아니죠. 언제든 상황에 따라 혹은 내 관심사의 변경에 따라 바꿀 수 있어야 한다고 생각합니다. 잡스의 한마디로 플래시를 버렸듯 말이죠.
요즘은 복지도 상향 평준화되어서 어디든 괜찮은 편입니다. 연봉도 괜찮고요. 투자 초기에 합류한다면 주식형 보상으로 대박도 노릴 수 있죠. 복불복이지만 실패하더라도 경험과 커리어는 남으니까요. 월급만 보장된다면 절대 손해 보는 장사는 아닙니다.
너무 개발개발하지 않기
이건 사람의 성향과 관심사에 따라 다를 수 있습니다만 너무 개발에만 올인하지 않겠습니다. 개발을 하고 있고 개발을 좋아하지만 우리가 만드는 건 결국 사람이 사용하는 소프트웨어라는 제품이잖아요. 잘 팔리는 것을 만들고 싶습니다. 개발자라고 해서 항상 코딩으로만 기여할 수 있는 것은 아닙니다.
어느 정도 경력이 쌓이면 개발 외의 스킬들이 점점 더 요구됩니다. 개발자로서 코딩을 잘해야 하는 것은 당연한 것이고 제일 많은 시간을 들여 학습하고 개선해야 하는 것도 당연합니다. 다만 지금 내 업무에 "필요한" 개발 스킬은 성장하는 것에 한계가 있고 현재 필요한 개발만 공부만 하는 것은 비효율적인 시기가 옵니다. 이미 많이 알아서요. 예를들어 프론트엔드 개발자가 프론트엔드만 공부하는 것을 말합니다. 한 3년만 실무와 함께 열심히 공부해도 그 이후부터는 효율이 떨어지죠. 그때 부터는 다른 언어나 다른 플랫폼을 공부하는 것이 전반적인 통찰과 시야를 넓힐 수 있는 방법이 됩니다. 근데 그것도 몇 년이 흐르면 효율이 떨어지고 점점 연차는 쌓여 기대받는 역량과 책임이 개발에만 국한되지 않게 됩니다. 실무에서 쓰지 않으면 금방 까먹기도 하고요. 제가 그렇습니다...
그러면 그때부터는 프로그래밍이 아닌 다른 분야에서 제품을 만드는 데 도움이 될만한 것들도 같이 공부같이 하면 좋은 것 같습니다. 가성비가 나오는 수준까지만 말이죠. 소프트스킬이라고 부르죠? 프로젝트가 잘 굴러가는데 필요한 스킬들도 관심 갖고 역량을 키울 것 같습니다. 초반에는 지금 내가 필요한 스킬은 아니라고 생각했는데 아니었어요. 초반부터 알아두면 좋다고 생각합니다. 오히려 개발자로 더 돋보일 수 있는 역량들이라고 생각합니다.
나아가 디자인과 UX 분야도 더 많이 관심을 갖고 싶습니다. 프론트엔드 개발자로서 그냥 경험에 의해 차츰 익혀진 것도 많은데요. 이게 책과 강의들을 찾아보면 신세계입니다. 디자인에 대한 재미있는 책도 많고요. 특히 개발자를 위한 디자인 책들도 있습니다. 그림 그리기에 대한 재미있는 책도 많죠. "잘 그리기 금지" 같은 책 말이죠. :)
하지만 무조건 제일 중요한 건 프로그래밍입니다. 뭐든 프로그래밍 실력이 기본으로 깔린 상태여야 하죠. 그래서 제일 비중을 두어야 하는 것도 프로그래밍이겠죠. 하지만 소프트 스킬에도 비중있는 우선순위로 관심을 갖고 개선하려고 노력할 겁니다. 우리는 혼자 일하는 게 아니고 결국 우리가 만드는 건 코드가 아니라 제품이니까요. 소프트 스킬은 다른 직종에서도 공통적으로 필요하다는 점은 추가적인 장점일 수 있겠네요.
조직장과 회사와 친하게 지내기
이 내용은 다소 민감할 수도 있을 것 같네요. 모두 제 개인의 소견일 뿐입니다.
저는 비교적 팀장 같은 바로 윗 조직장하고는 잘지내는 편이었어요. 업무를 떠나서 인간적으로 친해지려고도 노력을 많이 했었죠. 뭐 그렇다고 제가 아부나하는 예스맨은 아니었습니다. 그건 친한게 아니죠. 조직장과 회사와 잘 지내라고 하면 반발하시는 분도 계실거에요. 뭔가 권력의 노예가 되길 자처하는 찌질한 인간처럼 보일 수 있으니까요.
조직장과 회사라는 일종의 서비스(?)를 커리어에 적절히 잘 이용해먹어야 한다고 생각합니다. 그러기 위해서는 좋은 관계가 수반돼야 하죠.
조직장 주변을 자주 맴도는 사람들에게는 보통 좋지 않은 이미지가 생깁니다. 괜히 좋은 기회는 그런 친분이 있는 사람들에게만 주어지는 것 같고 왠지 입개발만 하는 것 같죠. 뭐 물론 그럴 수도 있습니다. 그런 경우는 조직장이 정말 무능한 조직장이겠죠. 하지만 대부분 오해일 뿐 그렇지 않습니다. 조직장은 바보가 아닙니다. 분명 도움이 되니까 곁에 두는 겁니다. 반대로 곁에 있으니 도움이 됩니다. 그건 조직원도 마찬가집니다.
조직장과 접점이 많을수록 내가 지금 무엇에 관심을 갖고 공부하고 있는지, 어떤 작업들을 하고 싶은지, 무엇을 잘하는지를 자연스럽게 어필할 수 있고요. 그러다 보면 관련된 일을 할 기회가 주어질 수 있습니다. 현재 진행되는 프로젝트나 업무에 대해 스몰톡으로 자주 이야기하며 피드백도 더 많이 받을 수 있고 나아가 여러모로 도움도 받을 수 있습니다. 그러니 업무가 더 수월해질 것이고 성과가 잘 나오겠죠. 일을 잘 해내니 조직장도 더 신뢰를 하게 됩니다. 그러면 더 좋은 기회나 도전적인 업무들을 제공할 것이고요. 또 동일한 패턴으로 잘 해내겠죠. 곁에서 업무의 진행사항들을 공적인 상황이나 사적인 상황에서 지속적으로 공유했을테니 조직장은 그 과정을 더 잘 이해하고 있을 겁니다. 동일한 업무를 완료했더라도 그 진행 과정을 알고 있는 것과 모르는 것은 큰 차이가 있습니다. 이런 것이 악용되면 정치라고 불리기도 하죠.
페이스북 디자인 부문 부사장 줄리 주오는 "팀장의 탄생"이란 책을 통해 "상사를 심판이 아닌 코치로 대해야 한다"라고 말합니다. 조직원의 성과 향상이 바로 본인의 성과 향상으로 이어지기 때문에 상사는 누구보다도 조직원이 성과를 내서 성공하길 바라는 사람입니다. 적극적으로 피드백을 요청하고 기회가 될때마다 도움을 청하고 고민을 털어놔야 합니다.
조직의 모든 인원이 조직장과 이런 관계를 유지할 수 있다면 그보다 좋은 조직은 없을 것 같습니다. 조직장, 조직원 모두의 워너비죠. :) 어떠한 이유로든 서로 우호적인 관계를 유지할 수 없고 오히려 적대적인 관계로 발전했다면 서로를 위해 팀을 옮기거나 빠른 퇴사가 답입니다. 버틸 이유가 없어요. 다름을 이해하는 것도 어느 정도 지 극적인 다름에는 타협이 없는 것 같아요. 극단적으로는 직장 내 괴롭힘으로 이어질 수 있다고 생각합니다. 조직원도 그렇지만 조직장도 괴롭힘을 당할 수 있습니다.
공유를 더 자주 하기
블로그에 글쓰기나 발표나 강연같이 외부에 공유하는 활동을 일찍부터 많이 할 것 같습니다. 저는 사람들 앞에 종종 나서는 편이지만 멍석이 제대로 깔린 상태에서는 울렁증이 심한 타입인데요. 그래서 경력 초반에는 울렁증도 있고 아는 것도 없어서 이런 핑계로 많이 피했습니다. 하고는 싶었지만 겁이 나서 아직은 아니야 했죠. 하지만 경력이 쌓일수록 사람들에게 기술적인 지식을 전달해야 하는 업무들이 늘어났고 자연스럽게 시작하게 됐습니다. 지금 생각해 보면 이렇게라도 시작하길 잘한 것 같아요. 공유 활동을 적극적으로 하면서부터 제 개발자로서의 삶이 많이 바뀌었다고 생각합니다. 직간접적으로 큰 도움이 됐습니다. 아직도 항상 긴장되고 떨리지만 조금이라도 더 빨리 시도해 볼 걸 하고 후회합니다.
공유는 꼭 엄청난 능력을 가진 사람들만 할 수 있는 것이 아닙니다. "내가 뭐라고~" 생각할 수 있지만 "뭐"가 아니기 때문에 오히려 더 쉽게 할 수 있는 겁니다. 소위 연예인 개발자들은 "뭐"기 때문에 쉽게 무언가를 공유할 수 없어요. 영향력이 크기 때문이죠. 누구나 남에게 도움이 될 수 있다는 선의로 자신의 지식이나 경험을 공유할 수 있습니다. 많은 사람들에게 공감을 받지 못할 수도 있어요. 뭐 어때요. 생각이 다를 순 있으니까요. 설사 틀린 내용을 공유하게 된다면 또 그것을 지적해 주시고 올바른 길로 인도해 주시는 분들도 많습니다. 거기서 또 배우는 거죠.
공유를 통해서 스스로 더 배울 수 있다는 것은 이미 많이 알려진 사실입니다. 어떤 형태로든 공유를 하려고 준비하다 보면 본인의 부족한 점을 발견하고 채우게 됩니다. 아인슈타인은 "쉽게 설명할 수 없으면 제대로 아는 게 아니다"라고 말을 하기도 했고요, 리처드 파인만은 자신이 배운 것을 쉽게 설명할 수 있을 때까지 다시 공부했다고 합니다. 그분들의 말씀이 항상 옳은 것도 아니고 모든 것에 적용되는 것도 아니지만 큰 울림이 돼서 적어도 동기 부여는 할 수 있을 것 같습니다. 이분들뿐 아니라 아는 것을 공유하는 것에 대한 통찰은 여기저기서 많이 볼 수 있습니다.
좀 더 실리적으로 생각하면 공유를 통한 자기 홍보효과도 무시하지 못합니다. 소위 많이 알려진 굇수님들은 대부분 공유를 통해 알려지셨죠. "나는 인기 따위는 신경 쓰지 않아"라며 외로운 인디 뮤지션 같은 겸손한 마음을 가질 수도 있습니다만 요즘 같은 세상엔 여러모로 유리한 조건을 얻을 수 있는 가능성이 커집니다. 저는 조금이라도 더 굇수님들을 닮아가고 싶습니다. 해외굇수, 토종굇수 모두요.
공유는 잘하고 못하고의 문제가 아니라 했고 안 했고의 문제라고 생각합니다. 그냥 하겠습니다.
운동을 더욱 열심히하기
지금도 어리지만 더 어렸던 시절, 열정이 넘쳤던 그때를 생각해 보면 무엇보다 중요한 건 체력인 것 같습니다. 그때는 체력이 중요한지도 몰랐지만 열정에는 반드시 체력이 뒤따라줘야 한다는 것을 새삼 깨닫습니다. 퇴근 후 자투리 시간을 활용하려 해도 이미 지쳐있는데 뭘 할 수 있겠어요. 나이를 먹을수록 열정이 줄어든다고 하는데 그 이유도 체력이 줄기 때문이 아닌가 하는 생각합니다.
체력을 기르는 데는 역시 운동만 한 게 없죠. 탄탄한 몸도 만들 수 있고요. 다양한 병도 예방할 수 있어요. 거기에 더해 정신적으로도 좋은 효과가 있는 것으로 알려져 있어요. 심지어 유산소 운동은 뇌세포까지 생성한다고 하죠.
오랫동안 두뇌를 연구했던 산제이 굽타 박사는 "킵샤프"란 책을 통해 젊고 건강하고 예리한 뇌를 만들기 위해 몇가지 방법을 제시했는데요. 그중에 운동은 "일주일에 최소 2일은 근력 운동을 하고 최소 5일은 30분 이상 운동을 하라"고 이야기합니다. 여기서 5일 에 30분 이상 운동은 걷기 운동만으로도 충분하다고 합니다. 주로 웨이트 트레이닝만 했던 저는 이 책의 내용을 계기로(그리고 허리 디스크로 인해 ㅜㅜ) 유산소 운동을 더 많이 하게 됐습니다.
요즘 주니어 개발자분들은 다들 스타일도 멋지시고 몸도 잘 가꾸시고 하는 것 같아서 보기 좋습니다. 그래요 이제 개발자들도 체크무늬 셔츠에 뿔테안경이 떠오르는 그런 구시대적인 이런저런 엉망진창 이미지가 아니라 건강한 몸에 스타일 멋지고 쿨하면서 스마트하고 냉철하지만 내 연인에겐 따뜻한 이미지를 가져보자고요 :) 컴퓨터만 챙기지 말고 나도 좀 챙겨 봐요.
커리어와 자신 모두를 잘 챙기시고 계시는 MZ개발자분들에게 요즘 많이 배웁니다.
마무리
지금 생각해 보면 조카가 개발자를 직업으로 가질 시기에는 지금과는 다른 환경일 거라 이 내용들은 큰 도움이 안 되겠네요. 영어도 번역 기술이 발전함에 따라 중요도가 달라질 수 있을 테니까요. 개발자, 프로그래머라는 직업은 남아있을까요?
꾸준히 공부하겠다, 기술적인 호기심을 더 갖겠다, 책을 더 많이 읽겠다 같은 당연한 이야기는 빼뒀습니다. 개발자라서가 아니라 본인 일을 좋아하고 열정을 가진 사람이라면 누구나 그렇게 하고 있으니까요.
현실에선 2회차라는 기회가 주어질 순 없겠죠 :) 그래서 한 가지 덧붙이면 항상 플랜 B를 발굴하려고 다양한 경험을 해야 할 것 같습니다. 현실은 2회차가 없으니 플랜 B라도 있어야죠. "한 우물을 파라"는 말이 있지만 또 "계란을 한 바구니에 담지 마라"라는 말도 있으니까요. 모든 격언이나 속담들은 창과 방패로 존재하는 것 같아요. 직업에 집중하지 말고 삶이라는 큰 숲을 보면서 나에게 맞는 방향으로 우물을 파야 할 것 같습니다.
저는 개발자를 프로그래머의 의미로 사용했어요. 프로그래머라는 단어로 대체할까 고민 많이 했었는데요. 개발자라는 단어가 요즘은 포괄적으로 더 많이 사용되기 때문에 개발자로 그대로 두었습니다. 디자이너, 기획자 등 제품개발에 참여하시는 모든 분들이 개발자라는 것에 동의합니다. 저는 그중 프로그래머에 대한 이야기를 더 첨가했습니다.
