실패한 면접에서 깨달은 개발

이번 포스트에서는 개발 직군이 갖추면 좋을 자세들을 필자의 경험 및 공부한 바를 통해 적어보고자 한다.

경험에 비추어 적는 필자의 생각이기 때문에 글을 읽는 독자의 생각과 상당히 다를 수 있다.

이 글은 ‘정답’을 구분하는 것이 아닌, 그에 가까운 ‘답’을 찾기 위한 과정이다.

독자에 따라 ‘정답’은 각기 다를 수 있으며, ‘답’을 찾는 과정은 다를 수 있다. 그러므로, 이 글을 한 개발자의 생각임을 명심하고 읽길 바란다.

단, 필자의 생각에 대한 논쟁은 언제나 환영한다.

목차

1. 개요

2. 산업기능요원을 위한 산업체 지원, 두 번의 실패, 그 중 한 번의 부끄러움

   2-1. 1차 면접, 우리는 그저 앱을 찍어내고 있지는 않은가?

   2-2. 2차 면접, 당장 앱을 처음부터 만들어내라고 하면 우리는 우리만의 스타트킷을 만들어놨는가?

   2-3. 3차 면접, 당신의 주력 언어는 무엇이며, 그 언어는 완벽히 숙지했는가?

3. 개발자로서, 프론트로서 생각해볼 일

   3-1. 프론트엔드 개발자의 역량

개요

이 글을 읽는 대부분은 개발자일 것이며 그 중 다수는 실무 경험이 5년 미만인 자들, 소위 주니어 개발자일 것이다.

필자 역시 21년 9월 기준 실무 개발은 3년 미만인 주니어 개발자며, 시니어 개발자가 되는 과정을 밟고 있다.

이러한 과정에서 경험을 통해 깨달은 것들을 적어, 다른 주니어 개발자에게 조금이나마 도움이 되고자 한다.

글의 주제에서 언급하였듯이 이 글은 실패한 면접에서 얻은 경험들을 바탕으로 이야기하고자 한다.

더불어, 앞으로 이어질 이 글의 시리즈는 경험 뿐만 아니라, 현재 재직 중인 회사, ‘랩이오사’ 개발자들에게 도움이 될 수 있는 것들을 위주로 적고자한다.

이러한 기회를 준 ‘랩이오사’에게 정말 감사를 표하며, 이 시리즈가 도움이 되길 고대한다.

(어떻게 하다보니 이미지는 넣지 못 할 것 같다..양해 부탁드리며 글을 시작한다.)

산업기능요원을 위한 산업체 지원, 두 번의 실패, 그 중 한 번의 부끄러움

최근, 병역 문제를 해결하기위해 두어 곳의 산업체 지원을 했다. 사실 산업기능요원이 되고자하면서 두 번 지원은 정말 노력을 들이지 않은 것이다. 실제로는 상당히 많은 곳에 지원하는 경우가 많기 때문이다.

하지만 산업체 지원에 힘을 들이는 것 보단, 현재 하는 일을 열심히 하면서 산업체 지원을 하고자 쉬엄쉬엄 준비를 하였으며, 결과는 두 번 다 실패하였다.

한 번은 1차 서류조차 통과하지 못했고, 다른 한 번은 3차 면접까지 도달했음에도 탈락했다.

이 때 3차 면접을 도달한 곳은 상당히 고된 과정을 겪었다.

1차로 비대면 면접을 받았으며, 2차는 4일의 시간이 주어진 미니 프로젝트, 3차는 대면 코드 리뷰와 사전에 고지받지 않은 코딩 테스트를 진행하였다.

지원한 회사는 React-Native를 프론트로 둔 회사였고, 1차로 받은 면접에서는 필자의 전반적인 개발 경험 및 React-Native에 대한 것들을 물어보았다.

2차는 위의 언어를 기반으로 현재 비트코인 시장의 시세를 불러와 스크린에 띄우는 프로젝트를 기간을 두어 개발하였다.

3차는 개발한 미니 프로젝트를 기반으로 회사 분들로부터 코드 리뷰(사실상 코드를 더 낫게 바꾸는 리뷰가 아닌 코드를 까내리기 바쁜 질 나쁜 리뷰)를 받았으며, 사전에 고지하지도 않은 코딩 테스트를 보았다. (정말 곤란하였다..)

위의 과정을 겪으면서 지원자로서 겪었던 감정이나 회사가 갖추었으면 하는 자세 등, 상당히 많은 이야기를 할 수 있지만, 이번 포스트는 면접 경험을 통해 깨달은 개발 디테일이므로 이에 대해 다뤄보고자 한다.

이러한 디테일은 1차, 2차, 3차 면접을 통해 겪었던 필자의 부끄러움이며, 대부분 개발에 대한 무지에서 나왔으므로, 이미 개발에 자신있고, 충분히 공부해 온 독자는 알고있는 이야기들일 수 있다.

그럼, 면접을 본 순서대로 얻은 디테일을 적어보고자 한다.

1차 면접, 우리는 그저 앱을 찍어내고 있지는 않은가?

1차 면접에서 제일 부끄러웠던 점은 ‘여태 무엇을 했는가’를 묻는 질문이 아닌, ‘여태 어떤 생각을 하며 개발을 했는가’였다.

필자의 첫 개발 실무 프레임워크인 React-Native부터 현재 회사에서 사용 중인 Flutter, Unity까지 모든 수단에 대한 정보는 인터넷에 상당히 많이 올라와있다.

하지만 처음 언어를 접하고나서 찾는 정보들은 그 언어를 통해 웹 혹은 앱을 개발하는 방법 뿐이고, 필자 역시 그랬다.

1차 면접에서 받았던 질문들 중 다수는 React-Native로 구성한 파일들이 어떤 역할을 하는지, 사용한 패키지는 어떤 원리도 돌아가는지를 묻는 질문들이 많았다.

예시로 몇개 간단히 든다면, React-Native로 만든 파일들 중 babel.config는 무엇을 하는지, webpack은 무엇이며 어떤 원리도 구동되는지, babel과 차이는 무엇인지 등이 있었다.

사실 위의 것들은 앱을 개발하는 데에 있어 몰라도 충분히 개발 가능한 것들이다.

다만, 이는 평소에 우리가 어떤 생각을 하며 개발에 임했는지 알 수 있다.

사소한 것들에 대하여 존재 이유를 찾고, 구동 원리를 충분히 의심해야한다.

그리하여 1차 면접에서 얻은 깨달음은 ‘앱을 구동하기 위한 코드만 찍어내는 것이 아닌, 원리를 의심하고 이해하는 습관’을 들여야한다는 것이다.

예를 들자면 아주 사소한 것들 즉, Unity는 무엇인가, 어떻게 돌아가는가, 설치 과정에서 왜 이러한 것들이 필요한가, 등을 최대한 놓치지 않고 찾아보며 개발하는 것이 좋다.

한 가지 언어 대해 공부하고 개발한 후 우리 머릿 속에 남겨야 하는 것은 그 언어의 작성법이 아닌, 그 언어의 장단점과 구동 원리여야 하기 때문이다.

2차 면접, 당장 앱을 처음부터 만들어내라고 하면 우리는 우리만의 스타트킷을 만들어놨는가?

2차 면접은 4일의 시간이 주어진 미니 프로젝트를 완성하는 것이었다. 이 때, 단순히 앱을 개발하는 것이 아니라 이 앱에 대한 ReadMe.md도 작성해야했다.

사실 필자가 최근까지 사용한 언어는 Flutter였고, React-Native로 앱을 처음부터 만드는 것은 꽤 오랜만이었다.

그리하여 프로젝트를 진행함에 있어 제일 신경쓰였던 점들은 바로 ‘폴더 관리’, ‘코드 설명에 대한 주석 처리’, ‘프로젝트 설명을 위한 ReadMe.md 작성’, 이 세 가지였다.

코드의 경우에는 프로그래머가 평소에 신경써야하는 것들이 많으므로, 코드 작성은 평소에 하던대로 작성하되 불필요한 부분이 있는지 신경써서 작성하면 된다.

단, 위에서 언급한 세 가지의 경우에는 이 프로젝트를 확인하는 자들(면접관 혹은 프로젝트 사용자)에게 제일 먼저 닿는 것들이다.

그러므로 상당히 신경 쓸 필요가 있으며, 기존에 진행했던 것들에서는 크게 신경쓰지 않았던 점들이다.

가장 좋은 것은 다수의 경험으로 자신에게 맞는 템플릿이 형성되어 있는 것이 최고지만, 필자는 그렇지 못했기 때문에 구글링을 열심히 하였다.

그리하여 2차 면접에서 깨달은 것은 위의 세 가지에 있어 ‘자신에게 맞는 프로젝트 생성 절차가 있는가’이다.

프로젝트를 개발하는 자라면 자신의 코드에 대해 폴더 규칙을 정립할 필요가 있으며, 코드를 효율적으로 설명할 주석, 프로젝트를 가독성있고 자세하게 설명할 ReadMe.md 작성법을 갖추어야 한다.

3차 면접, 당신의 주력 언어는 무엇이며, 그 언어는 완벽히 숙지했는가?

3차 면접은 대면으로 진행된 프로젝트 코드 리뷰와 사전에 미고지된 코딩 테스트였다.

코드 리뷰는 시간이 지난 지금 와서도 리뷰를 해주시는 분들이 필자의 코드를 발전시키기 위해 조언을 해주는 형태가 아닌, 그저 물어뜯는 형태였다는 점으로 생각이 든다. 정말 배울 점이 없다고 느끼기에 넘어가고, 미고지된 코딩 테스트에서 배울 점이 있었다.

사실 사전에 알려주지도 않고 코딩 테스트를 보면 응시자 입장에서는 정말 난처하다. 하지만 이만큼 응시자의 역량을 확인할 수 있는 방법도 없다고 판단한다. 물론 결론적으로는 나쁘다는 이야기지만 말이다.

이 때 정말 당황했던 것은 자신이 짜고자 하는 언어도 마음대로 정할 수 있다는 것이었다.

필자가 알고리즘 및 자료 구조를 공부할 때 사용했던 주력 언어는 C다.

다만, 요즘 들어 공부하고 있던 언어는 자바스크립트와 Dart이므로, 테스트를 자바스크립트로 보았다.

이 때, 자바스크립트와 Dart는 사실 인터넷의 힘을 많이 빌려 코드를 짜곤 한다.

그리하여 C로는 간단하게 해결할 문제를 굳이 자바스크립트로 해결하려 하니 마음대로 되지 않았고, 여기서 C로 바꾸기에는 너무 혼란했다.

즉, 이 면접에서 느낀 바는 ‘평소에 알고리즘 공부를 놓지 말고, 또한 그러한 문제에 봉착했을 시 해결할 주력 언어를 정하자.’는 것이다.

무슨 언어든 상관 없다. 자신이 자신감있게 문제를 풀 수 있는 언어면 된다.

평소에 잘 해놓도록 하자!

개발자로서, 프론트로서 생각해볼 일

이로써 면접 경험 안에서 깨달은 점들을 전부 이야기했다.

하나는 ‘코드 및 짜고자 하는 프로그램의 구동 원리를 의심하고 이해하자.,’이며, 다른 하나는 ‘자신에게 맞는 프로젝트 생성 절차를 확립하자.’이고, 마지막 하나는 ‘평소에 갑자기 코딩 문제를 풀 수 있는 주력 언어를 정하여 꾸준히 연습하자.’이다.

사실 이 모든 것은 개발 뿐 아니라 모든 직군에 해당된다.

자신이 하는 일에 대해 사소한 디테일도 놓치지 않으려 노력하고, 절차를 확립하며, 순발력과 문제 해결 능력을 높이자는 말과 같기 때문이다.

그렇다면 추가로 프론트엔드 개발자로서 생각해야하는 일을 몇 가지 적고 포스트를 마치고자 한다. 또한 다음 포스트의 일정으로는 각 언어나 프로세스에서의 디테일을 학습하여 조금씩 짚어보고자 한다.

프론트엔드 개발자의 역량

프론트엔드는 백엔드나 타 개발 직군에 비해 비교적 쉽고 진입장벽이 낮다는 인식이 잡혀있다.

하지만 조금이라도 프론트엔드 개발을 한 사람이라면 이는 결코 맞는 이야기가 아님을 알 수 있다.

프론트엔드의 진입장벽이 낮음은 어느정도 동의한다.

단, 이는 프론트엔드로 사용되는 언어가 쉽고 간단하게, 프로그래밍을 하는 자의 편의를 열심히 봐주도록 나왔기 때문이다.

실제로 그 언어를 사용하려면 위에서 언급하였듯, 앱을 만드는 코드를 찍어내지 않고, 자신이 공부하고, 원리를 관찰한 후 코딩을 하는 것이 올바른 작업이다.

이러한 과정을 거치기 위해서는 반드시 관련 지식을 학습하여야하고, 이는 결코 쉽지는 않을 것이다.

그리하여 프론트엔드 개발자가 갖추어야할 역량 중 첫 번째는 당연히 ‘코드를 분석하고 짤 줄 아는 능력’이다.

이 때 당연히, 그저 코드를 읽고 분석하는 능력이 아니라, 자신이 사용하는 프로젝트의 폴더 구성을 뜯어볼 줄 알아야하며, 그 과정에서 이미 짜여있는 코드를 읽고, 프로젝트가 구동되는 원리를 알 정도의 분석 능력을 이야기한다.



두 번째 역량은 ‘사용자 경험을 중시하는 능력’이다.

프론트엔드는 말 그 자체로 사용자에게 가까운 프로그램을 작성한다.

사용자에게 보여줄 화면 및 기능 등을 주력으로 개발하기 때문에, 사용자 경험을 중시하는 능력은 반드시 필요한 것이다.



마지막으로 이야기하고자 하는 역량은 ‘새 언어를 학습하는 능력’이다.

사실 프론트엔드로 실무를 하다보면, 프로젝트에 따라 언어가 여러 번 바뀌기도 한다.

그리하여 새로운 언어를 배울 기회가 많으며, 배워야만 실무에 투입이 가능하다.

하지만 다행히도 프론트엔드로 사용하는 것들은 대부분 원리가 비슷하기 때문에, 조금만 공부하다보면 이전에 사용한 언어들과 크게 차이가 없다는 것을 알 수 있다.

다만 여기서 그치지 않고, 이전 언어와 비교하여 장단점 및 원리를 파악할 줄 알아야한다.

그리하여, 경험이 쌓이면 추후에는 자신이 생각했을 때 최적의 언어를 사용하여 프로젝트를 개발할 수 있을 것이다.

Written by 상 한규

nic6@naver.com