부업으로 일을 하고 있는 프로그래머스 교육 역량 팀에서 프론트엔드 신입 및 프론트엔드 개발자가 갖춰야 할 실무 능력에 대해서 이야기를 나누면 좋겠다고 이야기하셔서 생각해볼 수 있는 시간이 있었다.
들어가기에 앞서서 나는 프론트엔드로 5년차, 실무로 4년 정도 일을 하고 있지만, 매일매일 한없이 부족함을 느끼고 있는 주니어이다. 지금 내가 글을 쓰고 있는 이 시점에서도 내가 이걸 평할 자격이 있을까? 라는 생각이 들지만 그래도 신입일때를 떠올려보며 현 시점에서 느끼는 것들을 정리하면 좋을 것 같아 글을 쓰려고 한다.
프론트엔드 신입 개발자들의 상향 평준화
프론트엔드 개발 기술들 (React, Next.js등)이 있지만 이런 기술들은 뒤로 하고(어차피 구글링 치면 비슷비슷한 내용이다) 이 부분 부터 짚고 넘어가려고 한다. 나는 신입 분들의 이력서를 보고 면접도 보는 역할도 하고 있으며, 프로그래머스에서 멘토링을 2기째 진행중에 있다.
이 업무를 하면서 느낀 점은 신입분들의 이력서가 날로 높아지고 있고, 상향 평준화되어 가고 있다는 것이다. 프로그래밍 국비지원코스가 우후죽순 생기고 있고, 특히 프론트엔드는 입문이 매우 쉽다보니 상대적으로 비전공자의 유입이 많다.
상향 평준화로 인해 변별력이 적어진 구현능력
프론트엔드 구현은 매우 쉽다. Udemy나 인프런등의 강의를 듣고 조금만 따라하면 번듯한 웹페이지는 뚝딱 만들어진다. 그리고 조금만 적성 + 재능만 있다면 그리 어렵지 않게 현대화된 웹사이트를 만들 수 있을 것이다.
실제로도 멘토로서 참여한 프론트엔드 데브코스의 최종 프로젝트에서는 백엔드와 협업하여 웹사이트를 하나 만들게 되는데, 조금만 예쁜 디자인이 가미가 되면 꽤 멋있는 결과물이 나온다. 이런 포트폴리오들이 상당히 많이 이력서로 들어온다.
이 말은 추후 프론트엔드에서 경력을 키워나갈때 구현 능력을 강점으로 내세우기가 어렵다는 뜻도 된다. 일반인의 입장(사용자의 입장)에서 봤을때 10년 경력의 프론트엔드가 만든 웹사이트나, 5개월 배운 신입이나 겉보기엔 별반 다르지 않기 때문이다.
또한 데스크탑, 모바일 기기들의 성능이 워낙 좋아지고 있기 때문에 불편한 임계점 이상이라면 (로딩시 3초 이상으로 걸린다는 등), 고수준의 웹사이트가(넷플릭스 등) 아닌 이상 성능차이를 크게 느끼기도 어렵다.
회사에서 우수한 프론트엔드 신입 뽑기
이 주제는 조심스러운게 내가 중소기업, 스타트업에서는 근무를 해봤지만 대기업은 해보지 않았기 때문이다. 이 부분을 감안하고 보면 좋을 것 같다.
계속 공부를 해나가는지
github 잔디로 평가하고 싶지는 않지만 (나도 적어서) 참고할만한 여지는 된다. 꼭 1일 1커밋이 아니라 계속 코딩을 하고 있다는 걸 확인 할 수 있다. 잔디를 클릭해보면 어떤 코드를 작성했는지 보이기 때문에 코딩 스타일을 확인하기도 좋다.
학원에서 최종 프로젝트로 끝난 결과물들을 끝났다고 나몰라라 하는게 아니라, 개선하려고 한 노력이 있는 것도 꽤 좋은 것 같다.
고민이 드러나는 코드를 작성하는지
자신만의 고민이 별로 드러나지 않는 코드들이 많이 보인다. 강의 코드를 그대로 치고 이걸 진지하게 생각해보지 않았다면 대답할 수 없다. 예를 들어 유저에게 연속적인 경험을 제공하기 위하여 로그인 토큰을 쿠키에 저장한다고 하자.
XSS공격이 일어날수도 있는데 이걸 어떻게 방지할지refresh토큰을 받아오는 로직들을 쓰셨는데 왜 refresh 토큰이 필요한 것인지- 인증이 필요한 페이지에서 새로고침을 할 경우 재인증 로직은 어떻게 처리할 것인지, 이때 오류가 생길 경우 어떻게 처리할지
httponly쿠키를 사용할 경우 서버와의 프로세스는 어떻게 가져갈 것인지- 만료된 쿠키를 백그라운드에서 어떻게 갱신할 수 있는지
나타날 수 있는 예외상황이 굉장히 많지만 코드는 너무 단순한 경우가 있는데 이건 고민을 많이 안해봤다는 증거이다. 화려한 포트폴리오를 보고 면접을 진행했지만, 정작 아쉬운 면접자들이 꽤 있었다.
문서화 (자신의 코드를 설명할 수 있는 능력)
신입들에게 프론트엔드 과제를 내는데 놀랍게도 README가 없는게 90퍼센트이다. 도대체 왜 작성을 하지 않는 것일까
- 코드를 실행하는 방법
- 해당 프로젝트에 대한 설명
이 두 가지는 최소한 명시를 해놔야 하고 더 나아간다면 특이점이 있는 곳이라던가 중점적으로 봐줬으면 하는 부분들, 컨벤션에 대한 내용, 어떤 순서로 구현했는지도 써두면 다른 사람이 코드를 파악하기 한결 수월해진다.
이는 코드를 짤때도 드러난다. 일단 코드를 치는 사람이 있고, 머릿속으로든 글로 적든 정리한다음 코드를 치는 사람이 있다. 쉬운 코드야 그냥 작성하면 그만이지만 복잡한 로직은 글로 적어봐야 어떤 예외사항이 나올지 예측할 수 있다.
글로든 말로든 어떤 로직을 설명할 수 없다면 그 사람은 해당 로직에 대한 코드를 작성할 수 없다는게 내 지론이다
(지극히 주관적) 블로그를 쓰는지
개인 블로그를 운영하고 있고, 포스팅이 많다면 이력서를 검토하는 입장에서 꽤나 반갑다. 그 사람의 생각을 그대로 알 수 있다는 장점이 있다. 어떤 일을 했는지, 어떤 코드를 작성했고, 공유하고 싶은 것은 무엇인지, 글을 쓰는 스타일은 어떠한지 요즘 어떤 기술관심사를 가지고 있는지 확인할 수 있다. 때로는 그래서 이력서보다 블로그가 훨씬 더 훌륭한 개발자 이력서라고 생각한다.
Github 코드를 볼수 있지만, 어디까지나 남의 코드를 읽는 것은 상당히 뇌를 사용하는 일이라 피곤하다. 업무 도중에 이력서를 검토해야 하는데, 집중하면서 다른 프로젝트의 코드를 읽어본다는 건 쉽지 않은 일이다.
하지만 학원에서 강제로 쓰게한 스타일의 블로그는 의미가 많이 줄어든다. 특히 velog에 이런 무미건조한 학원스타일의 글들이 많이 올라오는데, 편견에서 자유롭기 위해서라도 자신만의 블로그를 만들어 보는걸 추천한다.
(마무리) 내가 생각하는 프론트엔드 개발자 그리고 시니어
프론트엔드 개발자로 커리어를 시작했고, 계속해서 시니어로 발전해나고 싶은 욕심이 드는 단계에서 작성해보는 글이다.
지금은 신기술을 배우는 건 잠시 뒤로 미뤄둔 상태이다. 어차피 새로나온 프론트엔드 기술들은 해결하고자 하는 문제가 있다. 이 본질만 잘 파악하면 얼마든지 이른시일안에 배울 수 있다는 자신감이 있기 때문이다.
지금의 내 관심사를 소개한다.
리팩토링, 클린 코드등 추후에 고통받지 않기 위한 코드 작성법가상 면접 사례로 배우는 대규모 시스템 설계(서적)과 같은 대규모 서비스들의 구축방법- 5명 이상의 개발자들 사이에서 효율적인 협업
공통 디자인시스템에서 재사용성이 높은 코드 설계- 백엔드 DB 및 인프라
시니어로 발돋움하기 위하려면 여러 방면의 문제에서 해결방안을 제시할 수 있어야 한다고 생각한다. 그러려면 프론트엔드에 국한한게 아니라 웹 전반에 대한 이해도를 높이는게 좋을 것 같다고 생각한다.