kooboy blog

주니어의 첫 직장 현실과 대처법

May 27, 2020

JOBPERFORMANCEIMPACT

서론

이번 글은 개발자로서 첫 커리어를 시작하는 주니어 분들을 위한 직, 간접적인 경험을 토대로 한 소설과 같은 글을 준비해 봤다. 여러 안 좋은 상황들을 모아 가상의 환경을 그려낸 것이니 혹시라도 모든 사항에 해당된다면 (응?) 댓글로 알려 주시기 바란다. 이게 가상이 아닌 모든 짬뽕이 현실에서도 있을 수 있음을 글에 업데이트 하도록 하겠다.

기대

그 동안 수 많은 어려움과 도전, 긴장의 시간을 가진 끝에 드디어 최종적으로 한 회사와 채용이 확정되어 출근을 앞두게 되었다. 신나고 설렌다. 개발자로서 첫 직장이기 때문이다. 앞으로 XX 개발자 직무로서 회사에서 활약할 나의 모습을 상상하며 잠에 든다. 멋지게 Pull Request도 날리고, 동료들과 건설적인 코드리뷰 시간을 가지며, 회사 내부 기술 세미나를 통해 발표도 하고, 회사 기술 블로깅에 이름도 올리며 멋지게 성장하는 나의 모습.

내가 기여한 제품을 동네친구 가족 연인 생활코딩 많은 분들이 사용하며 FAN이 생길것까지 상상이 되니 날아갈 것만 같다. 회사 생활과 함께 동료들에 대한 기대 역시 넘치는 시기다. 디자이너는 힙한 디자인 시안 몇 개 중에 나에게 의견을 물어볼 것이고, 나는 센스있는 답변을 통해 디자이너 동료에게 개발자 치고 센스가 뛰어나다는 칭찬을 들을것이고, 꼼꼼한 기술 요구사항을 건네준 기획자 동료에게 부족한 부분을 코멘트 하며 더욱 완벽한 SR(Software Requirement, or Spec)을 완성해 나갈 것이다. 회사에서 진행되는 애자일 스크럼은 스크럼 리뷰, 데모 시연, 회고 및 플래닝을 통해 우리 개발팀의 퍼포먼스는 하늘을 찌를 것이며, 뿌듯한 마음으로 금요일 퇴근하여 주말엔 가족과 연인과 함께 서울숲으로 즐거운 피크닉을 갈 것이다. 피크닉이지만 나는 돗자리에서 클린 아키텍쳐를 읽으며 나의 기술적 성장에 게으르지 않을 것이다. 등등..

처참한 현실

회사에 출근하니 내가 생각했던 것들이 많이 다르다. 내가 너무 기대를 높게 한 것인가, 아니면 원래 이런 것인가. 어디 가서 물어보고 싶은데 회사 안에 누구한테 물어볼 사람도 없다. 회사 사수가 없기도 하고 있어도 물어볼 만한 상황이 아닌 것 같다. 멋진 Pull Request 는 커녕 도대체 git workflow가 어떻게 돌아가는지 고속도로 진입조차 못하고 있는 상황이다. 그 누구가 앉아서 친절하게 설명해 주지도 않는다. 스크럼을 하긴 하지만, 왜 저 카드가 중요한지, 유저 스토리는 있기나 한 것인지.. 이미 할 일은 주어졌는데, 왜 저 일을 해야 하는지, 디자인 시안은 부족한게 너무 많아서 개발자인 내가 디자인을 완성해야 한다. 물어보니 모든 팀원에게 상상력의 기회를 주기 위함이라고 한다. 요구사항은 수시로 변해서 저번주에 한 기능을 갖다 버려야 하는지, 아니면 고쳐 써야 하는지 도무지 감이 오지 않는다.

같이 일하는 동료와 상사는 너무 바빠서 내가 지금 무슨 고민을 하고 있는지 알지 못한다. 상담을 받고 싶어도 매일 야근하는 상사에게 도저히 도와달라는 이야기를 하는게 너무 창피하고 불편하다. 사실 용기내서 한 번 물어본적 있는데 있는 코드를 좀 더 들여다보라는 핀잔을 받았다. 코드리뷰 때 물어보지 왜 지금와서 물어보냐고 혼나서 그 다음부터 물어보기가 너무 불편하다. 사실 코드리뷰라고 해봤자 자기들끼리 코드 외적인 이야기 하다가 끝나서 이걸 코드리뷰라고 해야 하는지 의문이 들기도 하다. 원래 코드리뷰는 이렇게 하는건가? 그런 코드리뷰조차 바쁘면 그냥 이번은 넘어가자 하면서 스킵하기 일쑤다.

회사 대표는 외부에서 어떤 이야기를 듣고 오면 흥분해서 개발팀에 와서 침튀겨가면서 이걸 만들어야 한다고, 언제까지 가능하냐고 이야기하고 떠난다. 그럼 개발 팀장은 고민하다가 지금 만들고 있는거 잠시 넣어두고 저걸 만들어보자고 한다. 개발 팀장은 팀을 보호하고 최적의 퍼포먼스를 내기보단 스스로의 안위가 더 중요한것 같다.

어떻게 어떻게 개발을 완료 해서 배포에 태웠더니 프로덕션 라이브에서 큰 사고가 났다. 팀장은 코드를 이런 식으로 짜면 어떻게 하냐고 돌려 비판을 하신다. 모르는게 있으면 물어보고 결정하라고 하시는데 음, 어느 장단에 맞춰야 할지 모르겠다. 그것도 월요일날 하자는걸 팀장님 결정으로 급하다고 금요일 저녁 퇴근 전 배포해서 현재 밤 10시가 되도록 아직도 퇴근을 못 했고 고치는 중 이다. 아마 토요일인 내일도 아침 일찍 나와야 할 것 같다. 일요일은 서울숲에 가기로 했지만 머리속엔 온통 버그를 어떻게 고칠지로 가득 차 있을 것 같다. 가만.. 일요일은 출근 안해도 되나?

고민이 된다. 이제 2개월 밖에 안 됬다. 원래 개발자의 하루 하루가 이런건가. 누군가에게 속시원하게 듣고 싶다. 아침마다 하는 스탠드업이 정서적으로, 심리적으로 너무 불안정한 상태에서 해서 너무 조급하고 불안하다. 실수하면 어떻게 하지, 이걸 기간안에 못 끝내면 어떻게 하지, 걱정으로 뒤덮혀 코딩을 하게 된다. 좋은 설계, best practice, test code 이런 것은 엄두도 못 낸다. 빨리 만들어서 돌아가나 봐야 하는데 설계가 어떻니 마니는 배부른 이야기다. 당장 비슷한 코드 패턴을 복사해와서 붙여넣고 이 쪽 페이지에서 돌아가게 만들어야 한다. 모듈화? 재사용성? 여전히 배부른 소리다. 당장 내일 돌아가는 걸 보여줘야해서 예전 코드 패턴을 거의 duplicate 하고 있다. 모듈화, 재사용성, robust 이런건 일단 나중에 시간이 되면 리팩토링 할 때 고민을 해 보도록 하자. 그런데 뭐.. 그런 시간이 올까? 별로 그런 기대는 없다. 저 코드를 다시 만나게 될 나 자신과 또 동료, 후임자에게 벌써부터 미안하다. 인정받고 기여를 한다는 생각보단 소모되는 일회용품같은 느낌이 든다. 성장? 키 성장은 멈춘지 오래다.

그래도 조금 친분이 있는 다른 회사 개발자에게 물어보니 우리는 좋은 환경이란다. 거긴 사수도 없고 혼자 다 개발하고 혼자 요구사항도 만들어낸다고 한다. 완전히 내팽겨쳐버려져서 자기는 거의 너덜너덜 거린다고. 재수없는 라떼 사수라도 있어서 외로움이라도 없었으면 한다는 말에 그와는 더 이야기를 할 수가 없었다.

위 내용은 좀 극단적으로 만들언 낸 상상의 내용 입니다. 흥분하지 마세요.

고민과 불안

몸도 지치고 정신도 지친다. 멘토라고 할 사람은 회사에 없고, 개발하는 친구들도 많이 없어서 익명으로 개발자 커뮤니티에 하소연을 해 본다. 다른 익명의 여러 개발자 분들이 격려해주고, 그런 회사 하루라도 빨리 나오라고 부추긴다. 연봉도 만족스럽지 못한데 내가 왜 이 회사에, 이 팀에 이런 대우를 받으면서 있어야 하나 후회스럽다. 개발자로 커리어를 바꾼게 후회가 되기도 한다. 그 전엔 좀 더 좋은 연봉에, 좀 더 인정받으며 일했는데 지금은 너무 괴롭다. 다시 이전 직장에 이야기를 해 봐야 하는 생각까지도 해 봤다. 그래도 개발 공부하는 기간과 정성이 아까워서라도 다시금 마음을 고쳐잡기로 했다.

있어야 하나, 떠나야 하나

자 그럼 선택은 두 가지인것 같다. 여기 계속 있으면서 버텨야 하나, 아니면 떠나 다른 곳을 찾아야 하나. 오늘 글의 주제가 바로 여기에 있다. 이런 고민을 하는 분들께 도움이 되면 좋겠는데 글쎄 그게 잘 될지 모르겠다. 이런 상황, 혹은 비슷한 상황에 있는 신입 개발자 분들은 있어야 하나, 떠나야 하나 이 고민을 짧게는 수개월, 길게는 일년이 넘도록 하시는 분들을 봤다. 그리고 그 결과 계속 있는 분, 떠나는 분, 떠나려다 실패해서 이도 저도 아니게 된 분들을 수도 없이 관찰했다.

본질은 무엇인가

자 지금 이 상황과 고민의 본질에 대해서 이야기해보자. 일단 어떤 회사를 고르느냐에 대한 안목에 대해선 다른 글에서 이야기해보도록 하고, 오늘은 일단 회사에 들어온 이후의 이야기를 해야한다. 먼저 앞서 출근 전 기대를 많이 많이 했던 우리 꿈나무 개발자분들은 잘못이 없다. 회사의 현실은 회사마다 다르지만 출근했는데 회사가 너무 좋으면 그게 더 이상한거다. 왜냐하면 대부분의 회사가 별로 업무 만족도를 줄만한 상황이 아니기 때문이다. 그래서 회사를 갔는데 회사가 안 좋으면 그게 일반적인 것이다.

그래서 다시, 본질이 회사에 계속 있느냐, 떠나느냐가 아니다. 어느 한 쪽이 답이 될 수가 없다. 회사가 좋고 안 좋고에 너무 많은 내 정신적, 물리적 에너지를 소비하면 안 된다. 회사가 좋건 안 좋건 그게 나에게 가장 직접적, 궁극적으로 영향을 주는 것은 아니기 때문이다. 본질은 회사가 아니라 ‘나’에게 있다.

일단 회사의 환경이 좋으면 좋겠지만, 그렇지 않더라도 가장 중요한 것은 신입 개발자로서 내가 업무적 보람을 느끼며 꾸준히 성장하는가? 여야만 한다. 사실 믿기 어렵겠지만, 회사 환경이 좋건 나쁘건 언제나 장단점이 있기 마련이다. 아니 장점도 있다고? 워워, 흥분하지 말고 끝까지 읽어줬으면 좋겠다. 있다. 정말로.

회사와 팀은, (여기선 좋지 않은 상황의 회사, 팀) 모두가 좋아서 발전하지 않는다. 대부분 소수의 동기부여된, 잘 훈련된, 혹은 긍정적인 사람들로부터 집단이 변하고 발전하게 된다. 특히 초기에 그렇다. 즉 지금 내가 속한 팀과 회사가 여러가지로 별로라 한다면 내겐 선택권이 두 가지인데

  1. 내가 이 팀과 조직을 바꿔보는 도전을 해 보느냐
  2. 아니면 떠나느냐 이다.

아니 이제 막 취업한 신입 개발자가 팀, 회사를 바꾼다고? 그걸 지금 조언이라고 하느냐 따질 수 있다. (댓글로 따져 주시기 바란다). 화가 나실만 하다. 그러나 이 세상엔 언제나 그런 소수가 있다. 떠나는 것은 쉽다. 그리고 수도 없이 떠날 수 있다. 그것 역시 선택이기 때문에 전혀 비난하고 싶지 않다. 떠나서 더 좋은 조직으로 갈 수도 있기 때문이다. 그런데 진실은… 여기를 떠나 얼마나 더 좋은 조직으로 갈 수 있을 것이라 생각하는가? 그게 확률적으로 또 쉽지 않다. 아니면 그런 좋은 조직이 있고 발견했어도, 내가 거기에 갈 정도로 준비가 안 되어있을 확률이 높다. 좋은 조직은 더 좋은 동료를 모시기 원한다. 그렇지 않은 동료를 데려와 훈련시키는게 그 회사와 팀의 존재 목적이 아니기 때문이다.

따라서 결론은, 떠나는 것은 쉬우나 이 선택이 개인에게 도움이 될 확률은 극히 적다. 그냥 다음 회사가 좀 더 낫길 바라며 또 베팅하게 되는 것이다. 필자의 라떼 이야기 본론으로 들어가자면, 버티면서 무언가를 해 보는 옵션을 제안하고 싶다. 주의. 이것은 무지 어렵고 고통스럽고 거의 불가능에 가까운 일이 될 수 있다. 심신이 미약하거나 정신적으로 너무 연약한 분들은 시도조차 어려울 수 있다. 그럼에도 불구하고 이야기하는 이유는 이 도전은 성공해도 실패해도 결국 모든 유익은 시도한 그 개인이 얻어가기 때문이다.

회사에 코드리뷰가 제대로 되고 있지 않다? 신입이지만 내가 리서치해서 좋은 코드리뷰가 되려면 어떻게 해야 하는지 제안하고 세미나를 열자. 회사에 오래 개발하고 있는 분들께 물어보고 제안하고 그들의 생각과 이상은 어떤지 묻자. 사수가 회사에 없다면 채용해 달라고 부탁해 보고 거절당하면 외부 시니어를 만나 조언을 구하자. 이런 계기로 오히려 외부 개발자 커뮤니티 활동을 더 활발하게 할 수도 있는 것이다. 회사 대표가 너무 요구사항을 주 단위로 바꿔서 가져오면 한 번 싸워보자. 그렇게 너님 끌리는대로 요구사항을 바꾸는게 애자일이 아니고, 진정한 애자일 개발 방법론을 리서치하고, 현실적으론 어떤 것들부터 적용해야 하는지 직접 제안하고 시도해보자. 스탠드업 때 감정적으로 너무 불안하게 만드는 그 요소를 찾고, 담당자 혹은 팀장에게 솔직히 이야기해보자. 도저히 해결이 안 되고 있는 git conflict가 있다면 지나가던 동료에게 카페라떼 한 잔 타 드리면서 어려움이 있다고 도움을 요청해 보자. 그리고 그 도움에 대해 감사함을 또 표해보자.

나를 쏙 빼 놓고 안 좋은것만 나열하면 아무리 좋은 회사에 가도 흠은 보이기 마련이다. 그런데 초점을 외부가 아니라 ‘나’로 잡게 되면, 그 때부턴 내가 무엇을 해야 하는가로 문제가 바뀌게 된다. 회사가 원래 일하기, 개발하기 좋은 환경이었다면 퍼포먼스가 나고 신이 날 것이고, 그렇지 않는다면 퍼포먼스가 하루 아침에 나긴 어렵겠지만, 현재 좋지 않은 환경이 조금씩 바뀌는 것을 경험하게 될 것이다. 팀 안에서 이런 변화에 보수적이어 갈등이 생긴다면 그것 나름대로 그 갈등 안에서 무엇을 현실적으로 적용 가능한지, 무엇은 양보해야 하는지 또 알게 된다.

결론

회사에 대해선, 너무 사측 대변하는 입장일 수 있다고 오해하지 말아달라. 회사는 실망하게 마련이다. 회사가 나에게 무엇을 해 줄까를 너무 기대했을 때의 결과다. 내가 이 팀과 회사를 위해 무얼 할 수 있을까에 대한 고민을 하게 되면 오히려 내개 더 많은 기회가 찾아올 수 있다. 그 안에서 자연스럽게 성장할 수 있는 것이다. 성장을 무슨 완벽하게 큐레이션 된 커리큘럼 안에서 대학교 학위 따는 것처럼 할 수 있다고 생각했다면 정신 차리시라. 어느 곳에 놓여도 그 환경을 바꾸는 사람이 있는가 하면, 그 자리에서 불평만 하고 떠나는 사람도 있다. 그 환경을 변호하는 것이 아님을 다시 한 번 강조드린다. 그 환경은 좋을 수도 있고 나쁠 수도 있고, 좋다가 나쁠 수도 있고, 나쁘다가 좋을 수도 있다. 내가 제어할 수 없는 그런 환경에 초점을 맞추지 말고, 내가 제어할 수 있는 나의 선택과 노력에 집중해보자.

이 시기를 겪고 나면 이 팀, 회사가 변하든 말든, 나는 어떤 방향으로든 경험과 성장이라는 전리품을 얻게 된다. 이런 충분한 시도 뒤엔, 계속 남아도 되고 떠나도 된다. 이 회사에 얼마나 있는 것은 중요하지 않고, 정말 내가 이 팀에 임팩트 있는 존재였는가가 중요하다. 신입 개발자가 짧은 근무 기간 안에 개발 퍼포먼스를 내긴 어렵지만 불가능한 것도 아니다. 만약 시도해봤는데 거의 불가능 하다면, 그 팀에서 이뤄지고 있지 않은, 선배도 잘 모르는 영역을 파고들어 해결해 봐도 좋다. 전-혀 유닛 테스트가 안 되고 있는 상황에서 사람들이 배포 전 손으로 테스트하거나, 일단 용감하게 배포한 후에 고치는 상황이라면, 아무도 노하우를 가지고 있지 않은 유닛 테스트를 파 보고 적용해본다든지, 스크럼을 대충 하면서 애자일하다 하고 노래부르고 있다면, 어디 가서 돈을 내고서라도 책과 세미나를 통해 진짜 애자일, 현실적인 애자일은 무엇인지 공부해 온다든지.

어느 곳에 놓여도 그 환경을 바꾸는 사람이 있는가 하면, 그 자리에서 불평만하고 떠나는 사람도 있다.

환경이 좋지 않은데 불평만 하다가, 오히려 그 환경에 젖어드는 사람도 봤다. 어쩌다가 SI 회사에 가게 되었는데, 그 곳이 얼마나 별로인지 1시간 내내 신나게 연설을 하셨다. 본인이 속해있었던 조직의 단점을 말하셨지만 결국 그것이 스스로에게 침을 뱉고 있다는 것을 모르시는 것 같았다. 정말 안타깝다. 어느 누구는 그런 좋지 않은 환경 속에서도 무언가를 배우기 위해 노력했을텐데, 자기 조직의 흠만 이야기하는 사람에게서 좋은 점을 찾기란 하늘에 별따기다. 채용하는 우리는 당신의 그 안좋았던 회사에 관심이 있는 것이 아니라, 당신에게 관심이 있기 때문에 그렇다.

영향을 받으려 하지 말고 영향을 주려한다면 그 결과는 달랐을 수도 있다. 내가 신입이고 1년차이고 다 핑계일 수 있다. 당신도 언젠가 2년차가 될거고, 어느새 3년차 이상이 되서 이 핑계조차 댈 수 없는 시기가 금방 온다. 좋은 환경에 가면 서로가 좋은 영향을 주려고 노력하기 때문에 좋은 환경인 것이지, 좋은 환경에 유익을 얻으려고 하기 때문에 좋은 것이 아님을 다시 한 번 강조한다. 다음 옮기고 싶은 직장이 좋기를 바란다면, 나 스스로를 더 가꾸고 훈련시키는 것이 어찌보면 제일 빠른 길이기도 하다. 오늘은 여기까지…


경제적 사회적 배경에 상관 없이, 누구나 잠재력을 발휘할 수 있는 현장에 필요한 교육, 혁신적인 부트캠프 코드스테이츠 에서 일하고 있습니다.


Johnny Ilmo Koo

Welcome to Johnny Ilmo Koo's blog

...