40대 개발자의 회고... 몇 살까지 개발할 수 있을까
2021년 새해 첫날입니다.
모두들 새해 복 많이 받으시고, 코로나로 어려운 시기인데, 다들 힘내시길 바랄게요. 올해에는 좋은 일만 가득하시길 바랍니다.
"40대 개발자의 회고... 나는 몇 살까지 개발할 수 있을까?" 라는 주제로 글을 써봤습니다.
시간순으로 주저리주저리 작성했는데요. 지루하고, 감동도 없는 글입니다. 일기는 일기장에 써야 하는데... 내일 다시 읽어보고 오글거리면 글을 지울 수도 있습니다.
이 글에서 등장하는 사람들에 대한 악의적인 감정은 전혀 없습니다.
제가 만났던 모든 분들은 모두 고마우신 분들입니다.
아무 생각 없었던 20대 후반
내가 신입 개발자로서 처음 회사를 다니기 시작했던 2007년에는, 개발자가 40살이 되면 모두 PM이나 팀장이 된다고 생각했었다. 당시 팀장급이 대부분 30대 후반이었고, PM 또는 팀장이 되지 못하면 치킨집을 차린다는 얘기를 진담처럼 얘기했었다. 요즘엔 농담처럼 얘기하지만, 그 당시에는 개발자 치킨집 드립이 진담이었다. 세월이 흘러 나는 40대 개발자가 되었고 불행인지 다행인지 나는 아직도 개발자로 살아가고 있다.
나는 그동안 어떻게 살아왔는가... 앞으로 나는 몇 살까지 더 개발할 수 있을까?
대학을 졸업한 직후인 2007년 모 IT 솔루션 회사에 취직해서 사회생활을 시작했고, 크고 작은 SI 프로젝트에 참여했었다. 금융, 미디어, 유통, 포털 등 다양한 업종에 자체 개발 솔루션을 고객사의 요청에 맞게 커스터마이징해서 구축하는 프로젝트였다. 당시 주요 기술은 ASP.NET(닷넷, C#)이었고, 기타 잡다한 기술(MS-SQL, HTML, 자바스크립트 등) 풀스택 기술을 함께 배웠던 시절이다.
13년이 지난 지금 기억에 남는 건...
- 사무실에서 담배를 피우던 PM
- 주말 출근자 서류 명단을 집어던지던 고객사 PM
- 프로젝트 중 프리랜서가 단체로 도망가서, 도망간 프리랜서들의 소스코드를 밤새워 수정했던 일
- 투입 개발자가 200명이 넘었던 차세대 프로젝트 참여했을 때 아침출근 시 긴 줄을 기다린 후 출근부에 사인을 하면서 사무실에 입장하던 기억
SI 프로젝트를 하면서 정말 수많은 일을 겪었었다. 오랜 시간이 지났으니깐 좋은 추억으로 간직하고 이 글에서는 자세히 다루진 않겠다.
라떼는...
기술 역량에 고민하지 않았던 30대 초중반
서른 살이 된 나는 SK커뮤니케이션즈(이하 컴즈)라는 회사에 대리 1년차로 이직하게 되었다. 당시 나의 핵심 기술은 닷넷 프레임워크 기반의 ASP.NET(C#, 이하 닷넷)이었는데, 전국민이 사용했던 싸이월드 및 네이트 포털의 대다수 프로젝트에서 닷넷 기술을 사용했었다. 닷넷 기술을 사용했던 몇 안되는 포털회사였고 기업문화가 정말 좋은 회사로 유명했기 때문에 오래 전부터 정말 가고 싶었던 회사였다. 입사 당시 임직원이 1400명이 넘는 대기업이었지만, 내가 입사한 해(2011년) 여름 싸이월드 해킹 사고를 기점으로 회사의 경영은 급격히 악화되었다. 신규 사업은 대부분 실패하게 되었고, 경영악화 심화로 결국 두 번의 희망퇴직을 시행하였다. 일부 직원은 SK 플래닛으로 이동을 했지만, 수많은 직원이 희망퇴직으로 회사를 떠나게 되었다. 당시 1400명이었던 SK컴즈는 필자가 5년을 근무하고 퇴사할 때쯤 300명이 되었다. 얼마나 많은 직원이 퇴사했는지 상상할 수도 없는 엄청난 숫자이다. 불행인지 다행인지 그런 상황에서도 나는 5년 동안 네이트 포털 메인(시작페이지)이라는 똑같은 업무를 했고,
5년동안 단 한 번도 업무 변경을 하지 않았다. 단 한 번도...
그렇게 한 가지 업무만 고집했던 5년 동안 30대 청춘의 반이 지나갔다. 그래도 5년 동안 웃으면서 다닐 수 있었던 이유는 같이 일했던 훌륭한 동료들 때문이었을 것이다. 컴즈에서는 좋은 사람들을 정말 많이 만났고, 업무에 대한 자부심이 매우 컸다. 만약 내가 희망퇴직으로 다른 회사에 이동했었다면 내 삶이 많이 바뀌었겠지만, 회사에 남았던 그때의 선택을 전혀 후회하진 않는다. 시간이 지나서 돌이켜보면 13년 회사 생활 중에 가장 그립고 좋았던 곳은 SK컴즈 시절이다. 후회되는 일은... 퇴사 직전 매너리즘에 빠졌을 때 동료 기획자에게 몇 번 짜증을 냈던 나의 모습이다.
그곳에서 정말 열심히 일했다. 그곳에서 나는 정말 눈부신 청춘을 보냈는데, 함께 일했던 그들에게 나란 사람도 정말 좋은 사람으로 기억되고 있을까?
라떼는 말이야.....
하지만,
너무 늦게 깨달아버린 개발자 커리어에 대한 고민
많이 늦었지만 36살이 되어서 개발자로서의 커리어에 심각하게 고민을 시작했다. 컴즈에서 ASP.NET(닷넷, C#), PHP, 자바&스프링 등 잡다한 기술을 필요할 때 잡다하게 사용했었는데, 기술에 대한 깊이가 없었다. 게다가 5년 동안 같은 업무를 했고, 신규 프로젝트를 수행할 기회는 거의 없었다. 네이트 포털 메인을 신규 플랫폼으로 전환하는 프로젝트를 했지만, PHP 기반의 사내 프레임워크로의 전환이었기 때문에, 그마저도 개발자로서 큰 성장을 이루진 못했었다. 다시 한번 더 말하지만, 그럼에도 불구하고 5년 동안 행복하게 다녔던 이유는, 좋은 분들과 함께 근무했기 때문이라고 생각한다. 당장 나의 기술적 성장보다는 좋은 사람과의 생활이 더 중요하다고 생각했다.
컴즈에서 관리되지 않는 PHP 기반의 사내프레임워크로 유지보수 하는 업무가 나의 커리어에 더이상 도움이 되지 않는다는 생각이었다. 수차례 면담 끝에 나는 퇴직을 결심하였고, 자바&스프링 기술을 주도적으로 수행할 수 있는 컴즈보다 작은 포털회사(이하 회사B)에 시니어 개발자로 이직하게 되었다.
이때부터 나는 고민했던 것 같다. 나는 몇살까지 개발할 수 있을까?
계속 변경되는 직책@
팀원, 팀장, 부팀장, 팀원, 다시 부팀장으로...
30대 중후반을 보낸 '회사B'에서의 3년 6개월동안 나는 관리자와 개발자 사이에서 많은 고민을 했다. 회사에서는 내가 중간관리자로서의 역할을 해주길 원했다. 입사하고 몇 달 만에 팀장이 되었는데, 거의 매일 회의에 참석했고, 개발 이외의 업무를 많이 했다. 당시 필자가 리드했던 팀의 팀원은 15명 정도였고, 그 이후 9명(팀장일 때 4명, 부팀장일 때 5명)의 신규 인력을 채용하였는데, 입사 이력서를 총 300장은 넘게 읽었을 것이다. 당시 팀원들이 진행하는 모든 프로젝트의 일정, 리소스, 사람문제 등을 조율하였고, 핵심 의사결정을 해야 하는 직책이었다. 정말 바빴다. 비록 반년 만에 조직개편으로 인해서 팀은 반토막이 되었고, 시간이 지날수록 나의 의사결정권은 없어지기 시작했지만... 암튼 당시에 일주일에 최소 3일은 야근했었던 것 같다. 개발도구(IDE)를 열어볼 수 있는 시간은 하루에 1시간도 되지 않았다.
뭐가 그리 바빴는지... 아니면 부족한 나의 개발실력에 대한 핑계일까...
자바&스프링 개발을 하고 싶어서 이직했는데, 직책자라는 굴레 속에서 개발 외 업무를 챙기는 일에 정신없는 하루를 보내고 있었다.
당시 나는 팀장이라는 직책은 나에게 적성이 잘 맞는 것처럼 보였다. 좋은 팀을 만들어가는 과정에서 성장하는 주니어 개발자들을 보면서 큰 보람을 느꼈던 것 같다. 사실 내가 해준건 아무것도 없다. 그들이 알아서 잘 성장한 거라고 생각한다. 당시에는 내가 잘하고 있었다고 바보같이 착각했었다. 지금 생각해보면 정말 부질없던 착각이었다.
10년 가까이 개발자로 살아왔던 사람이 갑자기 팀장이 되었으니, 얼마나 의욕이 넘쳤을까, 너무 개인적인 개발팀 문화를 만들어가려는 내 적극적인 행동에 경영진은 어떻게 판단했을까?
정확히 1년 만에 팀장으로서 자격이 없다는 얘기를 통보받고, 보직 해임되었다.
자격이 없는 것은 분명했다. 아키텍처를 만드는 기술역량이 부족했고, 핵심 기술(자바&스프링)에 대한 역량도 매우 낮았다. 결정적으로, 경영진에는 반대 의견을 자주 전달했다. 팀원들에게는 Yes 맨이었지만, 불합리하게 생각되는 일에 대해서는 경영진에 적극적으로 No 맨이었다. 무슨 배짱이었을까? 나는 사내 정치에 매우 미숙했고, 어리숙했으며, 주변의 이간질에는 속수무책으로 당하고 있었다.
나는 팀장에서 해임된 후 부팀장이라는 새로운 직책을 통보받는다. 부팀장이라는 직책에서도 개발을 많이 하지 못했으며, 팀장이었을 때의 업무를 그대로 이어받았다. 바뀐 건 그나마 있던 권한이 전부 사라졌고, 내 의견은 아무도 들어주지 않았다. 회사에서는 나에게 경영진이 결정한 내용을 팀원에게 잘 전달하길 원했다. 그때는 나란 사람이 앵무새 같은 역할이라고 생각해서, 당시에는 불만이 많았었다.
하지만, 그게 바로 중간관리자의 핵심 역할이라는 사실을 너무 뒤늦게 깨달았다.
경영진과 구성원을 연결해주고, 경영진의 비전과 방향성을 구성원에게 잘 전달해야 하는 것이다.
당시에 나는 그 역할을 수행하기에는 너무 부족한 사람이었다. 팀장의 역할에 대해서 어느 누구도 나한테 가르쳐준 적이 없었다. 시니어 개발자가 되고, 나이가 되면 자연스럽게 찾아오는 중간관리자, 팀장이라는 직책에 대해서 어느 누구도 설명해주지 않았기 때문에 나는 그 역할을 수행하면서 많은 시행착오를 겪었던 것 같다. 한편으로는, 회사의 젊은 개발자들이 너무 부러웠다. 아무생각없이 개발만 할 수 있다면 얼마나 좋을까? 나는 개발자로서의 커리어는 끝날 것만 같고 두려웠다. 이러다가 결국 치킨집을 차리게 되는 걸까? 치킨집도 경쟁이 치열하다고 하는데, 과연 내가 잘할 수 있을까? 3년 6개월 동안 회사에서 나는 수차례 보직이 변경되었다. (내 의지는 아니었다)
팀원 -> 팀장 -> 부팀장 -> 팀 이동 후 팀원 -> 부팀장 -> 퇴사...
아쉬웠지만 미련은 없었다. 인정받지는 못했지만, 나름 열심히 했고, 좋은 사람을 많이 만났다. 쓴소리를 많이 들었지만, 지금 돌이켜보면 모두 고마운 분들이다. 이때의 경험이 없었다면 나는 성장하지 못했을지도 모른다.
3년 6개월 관리자와 개발자 사이에서 고민했던 시간들은 전화위복이 될 것이라고 스스로 위로를 했지만, 흘러버린 시간은 너무 야속했다. 그렇게 눈부신 30대 청춘이 인생무상처럼 지나가버렸고, 너무 많은 시간이 흘러버렸다. 40살이 되기 직전에 나는 그 회사를 도망나오듯이 퇴사하게 되었다.
몇 살까지 개발할 수 있을까?
개발자로서 어떻게 살아가는 게 지혜로운 삶일까?
시니어 개발자
5년전에도 시니어개발자였던 나는 당시에 시니어 개발자로서 역할을 제대로 했었을까? 마흔살이 된 지금까지 난 단한번도 시니어 개발자로서 역할을 제대로 수행하지 못했다. 자격지심이 아니라 팩트이다. 같이 일했던 주변 개발자들은 나를 어떻게 평가할까? 실력 없는 나이많은 개발자로 기억하겠지... 그들의 기억속에 나란 사람은 어떤 개발자로 남아있을까?
고민이 많아지는 밤이다. 지금 회사에서도 나는 시니어 답지 않은 시니어 개발자이다.
그들의 기억속에 나는 어떤 개발자로 기억될까?
(이런저런 고민...TMI)
관리자 or 개발자... 아니면 다른 직종에 도전?
이런저런 별 생각을 다 했다.
2016년에 팀장 직책을 맡았을 때 개발팀의 기술부채를 적극적으로 개선하고, 기술블로그를 만들고, 사내 기술 스터디를 기획하고, 개발자의 자율성을 최대한 존중하는 등 좋은 개발 조직문화를 만들려고 노력했었다. 2021년 현재 Developer Relations 로 유명한 배민에서는, 16년 당시에 기술블로그를 처음 시작했했었고, Developer Relations 이라는 개념도 잘 알려지지 않았던 시절이다. 필자도 Developer Relations 에 대해서 한참 후에 알게 되었다. 나는 단지, 당시에 팀원들이 좋은 개발환경에서 개발할 수 있도록 도와주는 역할을 하고 싶었던 것 같다. 하지만, 좋은 결과를 만들지는 못했다. 시행착오가 많았다. 기술블로그에 글을 쓰라고 강요했던 나를 싫어했던 팀원들도 있었을 것이다.
최근에 나는 개발자를 때려치우고, Develper Relations 관련 업무를 해봐도 좋을 것 같다는 생각을 해서 몇몇 회사에 지원하였지만, 관리자 및 개발자로 살았던 삶과는 전혀 다른 도전이었다. 아쉽지만, 평범한 나이 많은 개발자인 나를 Developer Relations로 채용하는 회사는 단 한 곳도 없었다.
또 다른 고민은 교육자로서의 고민이었다. 어렸을 때 선생님이 꿈이었는데, 누군가에게 지식을 공유하고, 알려주는 일에 대해서 매우 큰 보람을 느끼는 성격이다. 최근 몇 년 동안 주니어 개발자들과 무료 스터디를 수차례 진행했었는데 괜찮은 경험이었다. 개발자 때려치우고 교육자의 길을 가는 것은 어떤가?라는 고민도 해봤지만, 역시 나는 교육자로서의 역량은 더 많이 부족하단 생각이었다.
어쨌든, 많은 고민 끝에 내가 그나마 제일 잘하는 건 개발이고, 결국, 앞으로 개발자로 어떻게든 버텨야 한다는 결론을 내렸지만, 사실 지금도 걱정이다.
나는 몇살까지 개발할 수 있을까?
그래서, 난 몇 살까지 개발할 수 있을까?
포털회사에서 9년 가까이 평범한 개발자 및 관리자로 30대 청춘을 모두 보낸 이후... 나는 40살전후에 여러 회사를 전전하고 있다. 너무 생소했던 이커머스 업계로 이직했지만 1년 4개월 만에 퇴사하였고, 현재는 전혀 다른 도메인의 회사에 와서 새로운 기술을 배워가면서 어렵지만 묵묵하게 커리어를 이어가고 있다. 물론, 나이와 경력으로 인해서, 어딜가든 나는 시니어 개발자로서의 역할을 병행해야 한다.
새해가 되었고, 나는 41살이 되었다.
나는 몇 살까지 개발할 수 있을까?
개발자로 롱런할 수 있는 방법을 고민중이지만, 아직 명확한 정답을 찾지 못했다. 긍정적인 마음으로 행복하게 지낼려고 노력중이다.
아마도, 비슷한 또래에서는 같은 고민을 하고 있는, 이 글을 공감할 수 있는 40 전후 개발자분들이 많을 것이다. 삶이란 정답이 없는 것 같다. 각자의 삶의 방식, 각자의 길을 다들 묵묵히 걷고 있을 것이다.
이 글을 읽는 모든 분들이 걷고 있는, 각자의 길을 응원하겠다.
주저리주저리... 글을 쓰고 다시 읽어보니...
이상한 글을... 쓴거 같은데... 새해가 되어서 마음이 싱숭생숭해서 그런거다. 이해해주길 바라며, 마무리하긴 아쉬워서 몇자 더 남기겠다.
너무 일기같이, 주저리주저리 작성한 것 같네요. 비슷한 또래의 40대 전후의 개발자들은 조금이라도 공감하실 것 같습니다. 사회생활 경험이 많지 않은 취준생, 주니어 개발자들은 전혀 공감이 되지 않을 것 같습니다. 취준생에게 조금이라도 도움이 되길 바라는 마음에, 몇 글자 더 남깁니다. 제 커리어를 보셨으면 이제 아셨겠지만 정말 평범한 개발자이며, 제가 잘나서가 아니라, 조금이라도 도움이 되었으면 하는 마음으로 작성합니다.
취준생, 주니어 개발자에게 하고 싶은 말
좋은 선배(멘토)를 적극적으로 만나세요.
사실 필자는 좋은 선배가 주변에 많지 않았었다. 아니, 사실 몇 분 계셨지만 그분들의 얘기를 귀담아듣지 않았었다. 필자의 경험에 의하면, 취준생 및 주니어 개발자들은 훌륭한 선배 개발자를 많이 만나야 한다. 코로나 시국으로 인해서 오프라인 모임이 없어서 만남의 기회가 많이 줄었지만, 잘 찾아보면 좋은 선배, 멘토를 온라인으로 찾을 수 있을 것이다. 그리고, 좋은 선배와 많은 얘기를 나누길 바란다. 당장 좋은 선배를 찾을 수 없다면, 좋은 개발 동료라도 만들기를 바란다. 옆에 있는 동료가 누군가를 존경하고 있다면, 같이 존경하면 된다. 좋은 선배는 몇명 없다. 기회를 놓치지 말고 인맥 네트워크를 꼭 만들기를 바란다.
그리고, 절대로... 혼자 공부하지 말자!!
취업에 성공하면, 공부는 이제 시작에 불과합니다.
필자가 면접관으로 신입 채용을 했을 때, 어떤 지원자의 말이 아직도 기억이 난다.당시 회사에 지원했던 비장한 각오의 취업준비생 한분께서.....
지원자 : "몇 달째 열심히 공부했고, 수많은 회사에 지원했지만, 전부 떨어졌습니다. 이번이 마지막이라 생각합니다. 그동안 열심히 공부했지만, 이번에 채용이 안된다면 다른 일을 찾아볼까 생각 중이에요."
나 : 신입사원으로 우리 회사에 들어오시면, 단지 시작에 불과해요. 어차피 개발자는 계속 공부해야 하고, 길게 보셔야 할 것 같아요. 최종 합격 결과는 알수없지만, 만약 우리 회사에 채용이 안되어도, 공부를 포기하지 마시고... 좀 작은 회사에 가셔서라도 개발자로 계속 커리어 이어가시길 바랄게요."
취준생의 힘든 마음을 잘 알아서... 실력도 없는 면접관 주제에, 주제넘게 이런 말을 했었다. 면접 중이라서 '당신은 불합격'이라고 대놓고 말은 할 수 없었기에... 조심스럽게 돌려서 말했는데 당시에 내가 너무 무책임한 위로를 했던 것 같다. 필자가 하고 싶었던 말은, 취업은 시작에 불과하다는 사실이다. 개발자는 눈앞에 보이는 취업만 생각해서는 안된다. 개발자의 삶은 길게 봐야 하며, 끊임없이 공부해야 한다. 취준생 때 공부를 정말 열심히 해서, 좋은 회사에 취업을 한 이후 더 많은 공부를 하게 된다.
결국 개발자는 끊임없이 공부해야 합니다.
기록하고, 공유하고, 피드백받고, 다시 기록하고...
사람의 기억력은 한계가 있다. 새로운 기술이 쏟아져 나오고, 평생 공부해야 하는 상황에서 기록하지 않으면 나중에 다 까먹는다. 지혜롭게 기록하는 습관이 매우 중요하다. 단, 무조건 낙서하듯이 기록만 하는 것은 좋지 않다. 기록하고 정리한 것을 누군가에게 공유해야 한다. 좋은 선배가 주변에 있다면 기록한 것을 리뷰를 요청해보자. 선배의 피드백을 받아서 다시 수정하고, 이런 기록과 공유의 반복 작업을 해야 한다.
기술블로그를 당장 시작하라.
github 계정 없는 개발자는 지금 당장 github 을 시작해라.
기술에 대한 균형 감각을 유지하면서, 한두 개의 언어에 대해서는 전문가가 되길..
개발자로 살아오면서 필자가 제일 부족했던 점은, 기술에 대한 깊이가 없었다는 사실이다. 이 글은 어떤 특정 기술 하나만 평생 해야 한다는 얘기는 아니지만, 한두 개의 기술에 대해서는 전문가가 되는 것이 좋다. 물론, 특정 기술에 너무 집착할 필요가 없고, 비주류 언어를 하고 있다고 해서 좌절하지 않기를 바란다. 필자는 뒤늦게 자바&스프링을 선택하였지만, 코틀린도 괜찮고, Go도 상관없다. 특정 기술에 어느 정도 전문가가 된다면 다른 언어를 사용하는 것에 대해서도 어려움이 전혀 없을 것이다.
기술에 대한 균형 감각을 반드시 유지하면서, 특정 언어에 전문가가 되길 바란다.
신기술과 레거시 기술에 대해서도 균형 감각이 중요하다. 무조건 신기술만 집착하는 주니어 개발자를 많이 봐왔지만, 신기술이 무조건 좋은 소프트웨어를 잘 만들어주진 않는다. 반대로, 레거시 기술만으로 업무를 하고 있다면, 신기술에 관심을 갖고 최신 트렌드에 적극적으로 참여하는 것이 좋다.
신기술과 레거시에 대한 균형 감각이 정말 중요하다.
번외로, 기술도 중요하지만,
변화하는 환경 속에서 빠르게 대응할 수 있는 '유연한 소프트웨어'를 만드는 것이 더 중요하다.
오래전에 필자가 작성한 글인데, 시간 되면 읽어보길 바란다.
https://brunch.co.kr/@springboot/35
https://brunch.co.kr/@springboot/173
사내 프레임워크에 너무 집착하지 마세요.
주니어 개발자와 스터디를 진행하면서 깜짝 놀란 적이 있다. 과제를 확인 중에, 필자가 경험한 사내 프레임워크와 매우 유사한 구조를 보게 되었다. 회사 소스를 복사한 것은 아니라서 보안적으로 문제가 되지는 않았지만, 패키지 구조가 매우 유사했다. 너무 궁금해서 회사가 어디냐고 물어보니, 필자가 경험했던 프레임워크의 회사였다. 이 주니어 개발자의 코드는 창의성은 거의 없었고, 프레임워크라는 틀에 갇혀서 코드를 작성하고 있었다. 기존 패키지의 틀에서 조금만 벗어나서 고민해보면, 객체지향적으로 개선할 수도 있었던 상황이었다. (근데, 반전은 스터디 인원 중에서는 제일 개발을 잘해서, 칭찬 위주로 리뷰를 드리긴 했다.)
필자가 직책자로 일할 때 경영진의 의견에 제일 크게 반대했던 일중 하나는 사내 프레임워크 구축이었다. 사내 프레임워크가 무조건 나쁘다는 건 아니다. 단지, 제대로 관리되지 않는 사내 프레임워크를, 사내 정치적인 이유로(예를 들어서 개발자 인력 리소스를 아끼는 목적)으로 구축하는 것에 대해서는 매우 부정적인 생각이다. 사내 프레임워크를 회사의 여러 서비스에 도입하게 되면, 눈앞에 보이는 개발 리소스를 절약할 수 있다. 게다가 표준 기술을 동일하게 적용할 수 있다는 큰 장점이 있다. 그래서 눈에 보이는 1~2년 정도는 어느 정도 효과를 볼 수 있다. 하지만, 프레임워크를 오랫동안 관리하지 않으면 나중에는 엄청난 기술 부채가 될 것이다. 또한 개발자의 창의성을 심각하게 저해하며, 개발자를 단지 소모품(개발 리소스)의 개념으로 여기는 것에 대해서 부정적인 생각이었다. 물론, 창의성이 무조건 좋다고 말하는 것은 아니다. 회사라는 공동체 조직에서 각자 하고 싶은것만 할수 없다는 사실은 잘 알지만, 그럼에도 불구하고 그 프레임워크라는 틀 안에서 너무 갇혀 있지 않아야 한다는 말을 전해주고 싶다. 필자는 이런 프레임워크의 단점을 예상하고 미리 경고한 것이었다.
필자가 경험했던 회사에서의 프레임워크는 좋은 리더와 함께했기 때문에 잘 관리되고 있을 것으로 추측이 된다. 잘 관리만 된다면, 회사내 각 프로젝트에 잡다하게 사용 중인 기술의 표준을 맞출 수 있다는 큰 장점이 있다. 이 글에서는 사내 프레임워크가 좋다, 나쁘다 를 논하고 싶지는 않다.
단지, 내가 하고 싶은 말은 주니어 개발자들은 정해진 틀 안에서 너무 갇혀 있지 않기를 바라는 마음이다.
지금도 취업을 준비하는 분들에게..
취업은 쉬운 일이 아니다. 게다가 지금 코로나 시대라서 더 힘든 상황이라는 것을 잘 알고 있다. 사회 선배로서, 너무 안타깝고, 해줄 수 있는 게 없어서 미안한 마음이다. 그냥 무심코 던진 힘내라는 무책임한 말은 아무 도움이 되지 않는다는 사실을 나는 잘 알고 있다.
필자가 면접관을 하면서 느낀 점은, 면접관들도 모든 걸 알지 못한다는 사실이다. 아무리 뛰어난 면접관도 모르는 기술이 있을 것이다. 취업을 준비하다보면 실무 면접을 많이 보는데, 면접관의 압박면접에 실망을 하고 좌절을 하게 될 수도 있다. 결과에 너무 실망하지 말자. 너무 좌절하지 않기를 바란다. 본인의 부족한 부분에 대해서 적당한 자극(?)만 받으면 된다. 침착하게 차분히 준비하길 바란다.
40대 개발자의 회고로 시작해서... 취준생에게 해주고 싶은 말로 글의 내용이 산으로 갔지만, 어쨌든 이 글을 읽는 모든 개발자들이 행복했으면 좋겠다. 나 또한 이런 글을 쓰면서 생각이 잘 정리가 되었다.
나이와 상관없이 개발자로서의 더 많은 도전을 하겠다!!
올해는 좀 더 행복한 개발자로 살아가겠다는 다짐으로 이 글을 마무리하겠다.
