신입 개발자가 되기 위한 마인드 관리와 스토리

신입 개발자가 되기 위해서는 어떤 마인드를 가져야할까?

개발자 아이콘 제작자: Flat Icons - Flaticon

 

이것에 대하여 내가 할 수 있는 말이 있을까?

나는 현업으로 약 7년, 현재는 SW개발 관련 교육업 관련 업무를 약 4~5년째 하고 있다.

내가 취업 시장에 접어들었을 때,

알고리즘의 경우, 취업 시 SW 평가가 처음 도입이 됐을 때 무난하게 Pass 할 정도였고,

취업을 하고나서는 전문가까진 아니지만 어느정도 문제해결능력에 대한 기본기,

응용방법을 잘 쓰는 정도로 역량을 향상했다. 

개발은 눈에 바로 보이는 것을 좋아해서 처음엔 웹으로 접근했고,

그다음엔 C#, C++ 을 주로 다뤘고, 여러 아웃풋을 만들어서 시장에 내놓았다.

큰 프로젝트도 맡기도하고, 한때는 부러지기도 하고

혼자 앱 개발하여 반영도 하고, 어려운 문제도 몇 백개씩 해결하는 등 여러 개발 경험을 쌓았다.

UI, UX, PM 등 각 다른 팀과의 협업과 소통, 그리고 Merge를 하기 위한 코드 최적화 

이전의 개발 양산품을 더 유지보수 쉽고 기능적 구분/발전 가능성 있게 개발하기 위한 디자인패턴 적용 등...

신입 때에 겪었던 나의 고충은 지금도 여전히 신입들이 겪고 있기에 

각기 회사와 팀, 상사 등에 따라 성격이 모두 다양하지만

공통적으로 생각하고 접근할 수 있고, 미리 알면 좋은 것들을 정리해보고자 한다.

 

주로 하는 질문들 중 기억에 나는 건 우선 다음과 같다.

 

1. 프로젝트와 알고리즘 등 공부를 하는데, CS공부는 언제해야할까요?

CS공부를 하는 이유부터 생각해보자. 왜 해야하는가? 

CS공부는 기술면접을 위해 공부를 한다.

기술면접은 어떤 위주로 진행이 될까? 

해당 기업 또는 업무에 대한 전문지식(기초)를 보기 위함이다.

나의 경험에 따르면, 어느정도 개인/팀프로젝트가 있는게 좋고 거기에 따라 CS공부가 자체적으로 될 것이고,

그 외에 해당 기업의 특정한 업무를 선택해서 간다면, 거기에 맞는 CS공부를 하면 된다.

근데 이것도 우선순위를 꼭 줘야할까?

"OOO 기술에 대해 설명해보세요" 라고 물어보면 정말 꿀! 이겠지만,

"OOO 기술의 문제점은 무엇이고, 본인이 생각하는 해결방법을 설명해보세요" 라고 하면 조금 난감하긴 하다.

그래서 CS공부는 무수히 많은 테스트케이스 중에 하나 나오는 거라 생각되고,

시간대비 ROI가 나오지않는다 생각된다.

취업에 막바지가 됐을 때, 약 2주정도 전에 암기하는게 어찌보면 효율적이지 않을까?

그외의 CS에 대한 내용은 나의 경험에서 나온 이야기를 하는게 베스트라 생각한다.

각 언어, 프레임워크, 기술에는 거기에 최적화된 알고리즘들이 들어가는데,

기본기는 다 비슷하다. 그 기본기만 기초적으로 알자.

 

2. 알고리즘 공부하는데 하나를 잡는데 너무 오래걸립니다. 하나를 쭉 보는게 좋을까요?

최대 한 시간은 넘기지말자. 

근데 이건 두 가지로 구분이 된다.

(1) 접근 방법을 아예 모른다. (2) 접근을 했지만 허들을 못 넘어서 90점에서 넘지 못 한다.

접근 방법의 경우, 넉넉히 잡아서 1시간정도 생각은 해보자. 시험은 최대 3시간까지 주어지니깐.

허들을 못 찾는 경우는 그때 만든 코드를 절대 잊지말고 복기하고 수정을 하고 암기하자. 

습관이 무서우니, 나중에 똑같은 실수를 하기 때문이다.

(1), (2) 둘 다 잘 풀어놓은 다른 사람 생각법과 코드를 참고하자.

코드의 경우, 클린코드, 메모리 절약코드 등.. 너무 짧은건 패스하자. 우린 배워야하니까 잘 펼쳐놓은 코드가 좋다.

 

3. 신입에게 원하는 인재상? 신입 개발자에게 원하는 게 있을까요?

신입 개발자가 어색하고 긴장을 많이하는 것처럼, 선배 개발자들도 어떻게 접근해야 부담스럽지 않게 같이 업무할 수 있을까? 등.. 생각을 많이 한다.

원하는 것은 없다. 신입 개발자에게 맡길 수 있는 코드가 서버 구조 변경? 신규 기능 개발? 을 주지 않는다. 

어차피 선배 개발자가 다 수정하거나 재개발해야하고, 오히려 더 일에 버든을 만드는 것이기 때문이다.

* 기업의 규모, 프로젝트의 규모에 따라 코드에도 "히스토리성 코드"가 무조건 있기 마련이다.

  신입 개발자가 딱! 보고, 어라? 이건 나도 이렇게 개발 안 하겠다~ 하고 고치면,

  우리 코드말고 다른 개발자의 서비스에 에러가 날 수도 있다... 

  이렇게 반영한 이유 중 큰 이유는 의사결정이 너무 늦게 됐고 출시를 빨리 해야할 때 거의 발생한다.

그래서 처음에 맡기기 좋은 것은 디폴트적으로 선배개발자가 커버할 수 있는 업무를 줄 것이며,

그것은 전체를 훑어보는 업무, 전체 테스트케이스를 돌리는 업무, 선배 코드들 Merge시 코드리뷰 같이 보기, 특정한 부분에 이벤트적으로 들어가는 곳에 코드 넣기 (주로 if문 하나로 해결) 등이 있다.

처음엔 매우 간단한 것부터 시작하고, 분리 가능한 코드를 구현하고, 전체 서비스 기능을 보는 업무를 많이 한다.

그래서 취업 시장에 들어가서 면접에서 했던 기술적인 질의응답과는 다르게,

해당 기술에 대한 이론적인 이해도만 적절히 갖춰만 있고, 나머지는 회사 와서 빠른 시간내에 구글링하며 찾아가며 문제해결하면 될 것이다.

 

4. 가고싶은 곳은 OO인데, 저는 AA를 지금 하고 있습니다. OO에서 쓰는 BB를 이제라도 공부해야할까요?

기업은 많고, 하고 싶은 것은 정해져있다.

그렇다면 내가 가고싶어하는 기업은 많아봤자 몇 개가 안 되는 경우가 대부분일 것이다.

나 같은 경우에는,

맡고 싶은 특정한 업무로 구분은 하지 않았고,

눈에 보이냐 / 안 보이냐 / 안 보일 시 성능 위주로 하고 싶나. 로 구분했다.

나도 신입 시절, 프론트엔드를 하고싶어요~ 라고 생각하며 프론트엔드를 오래 개발지만,

프론트엔드 자체가 매력적이고 눈에 보이고 성과가 바로 보이는 업무이긴 하지만,

혼자 개발하고 런칭할 것이 아닌 이상, 업무에 대한 시스템적인 프로세스와 팀 분위기가 제일 중요하다.

이말은 즉, 내가 생각 없었던 백엔드에 갔어도 팀 자체가 개인의 성장과 웍벨런스가 있다면 백엔드도 재미있게 했을 것이다.

* 나는 운좋게도 좋은 선후배를 만나서 여러 서비스를 런칭도 하고, 밤샘도 해보고 (밤샘할 때 남으신분들이 다 긍정적인 마인드라 좋았다.) 특히 내가 막힌 부분을 내 자리에 와서 옆에서 코드리뷰하며 알려주시면서 수정해줄 때, 그 때 정말 많은 것을 배울 수 있었다. 그래서 프론트엔드를 하다가도 미들웨어 부분도 개발해보고, API 제공하는 업무도 해보고,

DB관련 업무도 해보고, 다양한 업무를 할 수 있었다 

정리하면, 내가 정한 기술력의 업무를 갈 수 있으면 가는게 베스트긴하지만,

그걸 기다리는 동안에 좋은 업무 환경과 발전가능성 있는 나를 만들 수 있는 경험들을 놓칠 수도 있다는 것이다.

이것은 직접 경험해봐야하긴 하지만, 어느정도 적당히 네임벨류가 있다고 생각되면 그쪽에 지원하는 것도 좋은 선택이며,

필요시 회사 내에서 업무를 변경도 할 수 있으니 (특히 개발자는 그런 부분에 자유롭다) 들어 와서, 1~2년정도 후에 변경을 해보자. 

* 내 지인 개발자들만 해도, 한 회사에서 3번의 업무를 변경했고, 프론트/백엔드, 지금은 그냥 웹서비스 하나를 맡아서 다 하고있다

* 다른 지인은 웹서비스를 맡다가 DB 관련 업무로 희망해서 옮겼고, 지금은 보안 관련 개발 업무를 하고 있다. 

 

또 생각나는 질문들이 있으면 정리하겠다.

 

 

 

 

 

국비 지원 SW개발자 양성과정: 비전공자부터 전공자까지의 준비와 현업 준비에 필요한 것