[SSUL] SI 신입개발자로 살아남기(13)

또!또!또! 신입이야!

 

오늘은 뭐 어느 누구의 잘못도 아니고 회사가 구데기라 발생하는 문제에 대해서 이야기를 하려고 하는데, 끊임없이 공급되는 신입에 대한 이야기다. 

일단 시작하기에 앞서 물론 나도 이 회사에 신입으로 들어왔으니 개발자로 커리어를 시작할 수 있었던 건 맞다. 하지만 나만 빼고 다 안돼! 이런 얘기가 아니라 그냥 구조적으로 문제가 있다는 얘기다.

 

중소 SI 기업의 경우엔 진짜 끔찍하게도 중,고급개발자가 없다. 중급은 그냥 우리 회사에서 초급이 중급이 된 케이스가 대부분이고, 고급은 당연히 제대로 된 고급 개발자분들이 있기도 하지만 솔직히 고급이 맞는지 모를 사람들도 꽤나 있다. 그래서 대부분 인구분포도가 극도의 피라미드를 그리거나, 더 심각한 데는 날먹 고급을 많이 주워와서 모래시계 형태로 날먹 고급입에 밥 넣어주는 초급이 잔뜩 있거나 그럴 거다. 

근데 이게 진짜 끔찍한 일인게, 이 취업난 속에 들어와서 아무 코토 몰라요..?라는 표정으로 앉아있는 신입개발자들을 탓할 수도 없는 노릇이고 회사에서도 중, 고급을 구하고 있다고는 하지만 진짜 이딴 회사를 중고급이 왜 오겠냐는 말에 나도 진심으로 공감하기 때문에 누구를 탓할 수가 없고 그저 회사가 구데기라 생기는 문제라고 생각할 수밖에 없다. 

 

그러면 신입이 많은게 뭐가 문제가 되나요?라는 질문을 할 수 있는데 잘 정리해서 설명해 보겠다. 

 

0. 신입이 할 수 있는 일이 많지가 않다. 

진짜 얼마 없는 상승욕구가 강력한 신입들이 있다면 나름대로 안보이는데서 엄청나게 공부하기 때문에 그 친구들 정도야 할 수 있는 게 많다. 하지만 일반적인 사람이라면 간단한 업무를 제외하곤 할 수가 없다. 대부분 학원, 부트캠프 발 비전공자 개발자고, 그거 수료하자마자 머릿속 백지장인데 알아야 뭘 하지.. 모르는데 대뜸 업무 시킨다고 뚝딱 해낼 수 있는 게 아니다. 

 

1. 명확한 레퍼런스가 없다. 

신입이 짠 코드가 죽이 됐든 밥이 됐든 어떤 누구도 피드백을 해줄 수가 없다. 신입들끼리 모아두면 서로 잘 모르기 때문에 코드 보면서 이게 맞나? 저게 맞나? 하게 되는데, 누군가 그걸 제대로 가이드를 해줘야 그게 올바른 방향으로 나아간다. 고민을 하는 것은 좋지만, 주니어의 입장에선 당연히 Best Practice가 있어야 그걸 보고 바른 길로 성장을 하는 건데, 가이드가 없으면 그건 뭐 개판이다 그냥...

언어 / 라이브러리 / 프레임 워크가 어떤 컨셉을 지향하면서 개발되었는지 제대로 된 이해도 없는 채로, 그냥 막무가내 개발을 하기 때문에 프로그램이 동작한다고 해도 문제가 많이 발생한다.

 

2. 일정에 차질이 생길 변수가 많아진다. 

SI 프로젝트는 일정에 맞추는게 가장 최우선인 프로젝트다. 근데 앞서 0번에서 말했듯 신입은 아무것도 모르고 할 수 있는 일이 많지가 않다. 근데 어쩌다 보니 뭔가 하나의 Flow을 혼자서 구현하게 됐다면? 그럼 어떤 일이 생기냐면 초반에 구현 제대로 못해서 버벅대다가 일정 얼마 안 남기고 테스트도 못해보고 겨우 개발만 끝마친다거나, 아예 개발을 못 끝내는 경우가 생긴다. 이런 식으로 일정을 못 맞추면 그냥 답 안 나오는 거임.. 단위테스트도 제대로 못했을 테니 당연히 통합테스트 때도 테스트할 때마다 버그 뻥뻥 터지지.. 코드는 이해한 거 없이 남들 코드 복붙만 잔뜩 해놔서 일관성 없으니 수정도 힘들고, 그래서 이 경우는 진짜 답이 안 나오는 거다.

 

자 그럼 오늘은 걍 글만 써재끼고 째는 게 아니라 뭔가 솔루션도 제안해야할 것 같아서 써보려고 하는데 당연히 그러면 안되겠지만 내가 중소 SI 신입으로 들어가서 신입의 입장이 되어 1인분을 하려면 어떻게 해야하는가? 를 얘기해봐야한다. 그래서 아래에 써둔 제안들만 지키면 진짜 1인분을 넘어서 머지않아 이야 잘한다 소리 들을지도 모른다.

 

1. 내 코드를 써보자. 

복붙은 그냥 무지성으로 갈긴다고 되는게 아니다. 그러니 처음엔 내가 생각하는대로 코드를 써보고 안되면 왜 안될까? 라는 의문을 가져본 다음에, 내거랑 용도가 비슷해보이는 남의 코드를 보고 일단 Ctrl + C에 손이 가는게 아니라 이 분은 어떻게 개발했지? 가 우선이 되어야한다는거다. 그리고 그걸 이해한 다음 그거랑 유사하게 내 코드를 써야한다. 완성이 좀 더뎌지겠지만, 어느 정도 내가 익숙해지면 내 코드 만으로도 개발이 가능해진다.

 

2. 레퍼런스를 꼭 찾아다녀보자.

이 레퍼런스라는건 꼭 타인의 코드를 이야기하는게 아니다. 개발을 하기 위해 참고할 수 있는 것들을 최대한 참고해봐야한다. 내가 영어가 안되고 코드가 어렵다고 하더라도 꼭 좋은 예제들을 찾고 개념을 쌓아올려야만한다. 그리고 내가 사용하는 도구의 공식 홈페이지는 진짜 제발 좀 봐줬으면 한다. React같은 경우엔 공홈에 진짜 많은 정보가 있고 걔네가 제시하는 룰만 지켜줘도 참 편하고 좋은데 영어 어렵고, 영어가 어려운 걸 극복하더라도 아예 개발자체 입문한지 얼마 안돼서 React 개념 자체가 좀 이해가 안되니까 안보는 분들 진짜 많이 봤다. 그리고 구글링을 습관화하는게 중요하다. 내가 아는게 없다면 어차피 다 경험이다! 써보면서 체화 시키겠다! 이런 말도 안되는 소리하지말고 지식을 좀 쌓은 다음에 쓰자. 물론 삽질한 걸 통해서 학습을 할 수야 있지만 그건 기업들이 말하는 직무에 대한 경험과는 전혀 다르다. 

 

3. 우리가 왜 이 프레임워크, 이 라이브러리로 개발하는지 이유를 꼭 생각해보자. 

별거 아닌 것 같긴한데, 프레임워크랑 라이브러리를 쓰는데는 당연히 이유가 있다. 근데 그 이유가 참 중요하다. 또 React를 예로 들건데, 신입개발자들 중에서 분명히 왜 React를 쓰는지도 모르고 개발하는 사람들 있을거다. 프레임워크 정의에 따라서 뭔가 편해지려고 쓰는건 맞는데 그게 뭐가 편하려고 쓰는지를 이해하지 않고 쓰기 때문에, 당연히 공부하는데 어려움이 생기고 단순히 암기만 하게 된다. 그러니 암기를 하지 말고 이해를 하자. React 왜 쓰는 건지 그거 좀 이해하고나면 React 제대로 쓰는데 얼마 걸리지도 않는다. 개발자가 공부해야한다는게 다른게 아니고 이런거다. 쓰는 법은 누구나 알지. 제대로 이해하고 쓰잔 얘기를 기업들이 하는거다.

 

4. 신입끼리 코드리뷰 하지 말자.

진짜 내가 아무것도 모른다. + 주변에 다른 사람들도 잘 모른다. 라는 가정이 모두 맞을 때 그 모르는 이들이 함께 모여서 코드리뷰는 하지 말자. 일단 코드리뷰의 목적은 위에 내가 써둔 1,2,3을 모두 포함한다. 위의 1,2,3을 혼자서 하면 진짜 오래 걸리기 때문에 효율성 있게 개발자의 성장을 만들어내기 위해서 잘 아는 누군가가 잘 모르고 개발을 하는 누군가에게 이렇게 하지말고 이렇게 하는게 맞다. 이렇게 쓰면 좋겠다. 라는 제안을 하기 위한 시간이 코드 리뷰다. 근데 신입끼리 코드리뷰 해봐야 얘기할 수 있는 내용이 한정적이고, 리뷰에서 나오는 피드백의 근거가 상당히 부족하기 때문에 오히려 제대로 이해하는데 방해만 되지 크게 도움이 되지 않는다.