배달의민족ㅣ현직자에게 성장이 왜 필요한가요?
배달의민족ㅣ현직자에게 성장이 왜 필요한가요?
일자
상시
유형
아티클태그
이 아티클은 <꿈의 직장 '네카라쿠배당토'> 시리즈의 5화입니다.
*해당 아티클은 wanted+ 영상 성장하는 프론트엔드 개발자되기 를 바탕으로 구성되었습니다.
기획 의도
프론트엔드 개발자에게 성장이란 무엇일까요? 성장하려면 어떤 마인드가 필요할까요?
성장 과정에 있어 스스로 해야 할 질문들은 무엇이 있을지 알아봅니다.
이런 분이 읽으면 좋아요
- 한 번이라도 성장에 대해 고민을 해본 개발자
- 프론트엔드 개발자로서 성장하고 싶은 사람
아티클로 얻을 수 있는 인사이트
- 프론트엔드 개발자가 성장해야 하는 이유
- 제대로 된, 유효한 질문을 하는 방법
- 자신만의 커리어를 개척해 나가는 방법
*해당 아티클은 wanted+ 영상 성장하는 프론트엔드 개발자되기 를 바탕으로 구성되었습니다.
기획 의도
프론트엔드 개발자에게 성장이란 무엇일까요? 성장하려면 어떤 마인드가 필요할까요?
성장 과정에 있어 스스로 해야 할 질문들은 무엇이 있을지 알아봅니다.
이런 분이 읽으면 좋아요
- 한 번이라도 성장에 대해 고민을 해본 개발자
- 프론트엔드 개발자로서 성장하고 싶은 사람
아티클로 얻을 수 있는 인사이트
- 프론트엔드 개발자가 성장해야 하는 이유
- 제대로 된, 유효한 질문을 하는 방법
- 자신만의 커리어를 개척해 나가는 방법
제가 프론트엔드 개발자로 성장하면서 자주 했던 질문은 ‘뭘 공부할지 모르겠어요’였습니다. 실제로 제일 많이 들었던 질문도 마찬가지였어요. 많은 분이 개발을 시작하려면 뭘 해야 할까, 열심히 하고 있는데 잘하고 있는 걸까, 많이 궁금해 하죠. 계속해서 잘 하고 있는지 확인받고 싶어 하고, 심지어는 유능한 개발자와 비교하며 속상해 하는 경우도 많고요. 같은 고민을 했던 개발자로서 느꼈던 생각을 공유해 보려고 합니다.
장현석 님 ⓒ 장현석
성장해야만 하는 이유
우리는 왜 성장하고 싶을까요? ‘내가 성장을 하긴 했을까?’, ‘성장은 어떤 의미를 가질까?’에 대해 생각을 깊이 해보셨으면 좋겠어요. 생각해 보면 성장해야 하는 이유는 많아요. 워라밸, 더 나은 삶, 연봉, 커리어, 아니면 성장 자체가 행복이고 만족으로 다가올 수도 있겠죠. 이렇듯 성장을 바라보는 요소는 개인마다 다양하게 다가옵니다. 근본적으로 우리가 무언가를 이루기 위해 성장하고 싶은 건지, 아니면 성장 그 자체에서 무언가를 얻고 싶은 건지, 성장이 나에게 어떤 의미를 가지는지가 선행돼야 합니다.
성장해야만 하는 이유는 이렇습니다. 솔직한 욕망 드러내기, 목표에 맞는 방향 조준하기, 직접 실행하기, 성장 확인하기인데요. 솔직한 욕망을 드러냈을 때 생각보다 성장을 바라보는 관점이 굉장히 달라집니다. 누군가는 성장을 수단으로 생각하고, 누군가는 성장을 목표로 두는데요. ‘훌륭한 개발자가 되기 위해 성장하겠다’거나 ‘성장해서 좋은 회사를 가겠다’와 같은 예시처럼 목표는 누구나 다른데, ‘이 성장이 나에게 어떤 도움을 줄 것인가’하는 욕망을 솔직하게 드러낸다면 그때부터 구체화해서 방향을 잡을 수 있습니다. ‘Hello world를 출력하면 언어의 반은 배웠다’는 말을 들어보셨을 거예요. 그런데 이것을 반대로 말하는 분도 계시더라고요. ‘할 줄 아는 것의 반밖에 되지 않는다’라고요. 결국엔 성장을 어떤 관점으로 바라보고, 어떠한 목표로 생각하느냐에 따라 방향을 더 정확히 잡을 수 있어요. 그 방향으로 차근차근 단계를 밟아갔을 때 굳이 많은 노력을 들이며 고통받지 않더라도 중간은 갈 수 있다는 생각에 이러한 내용을 담게 되었습니다.
완벽한 계획을 세우더라도 아무런 노력을 하지 않으면 아무 일도 일어나지 않듯이, 결국 실행해야 한다는 것을 다시 한 번 강조하고 싶습니다. 성장을 확인하는 것을 생각보다 많은 분이 어려워 하시는데요. 취업했을 때 사수가 없는 경우도 있고, 사수는 있는데 프론트엔드 개발자가 없고 서버 개발자만 많은 경우도 있고, 본인이 프론트엔드 개발자인지, 퍼블리셔인지, 백엔드 개발자인지 헷갈려 하시는 분도 많습니다. 그러다 보니 그에 대한 답을 열심히 물어보고 찾아보지만 피드백조차 받지 못하는 환경이 많이 생기는데요. 다양한 스터디나 멘토링을 통해 조금 더 해결하면 성장해야만 하는 이유를 찾을 수 있을 것 같습니다.
고민 위임
앞서 말했듯, 다양한 스터디나 멘토링과 같이 의지할 곳이 생기게 되면 결국 누군가에게 고민을 떠넘기기 시작합니다. ‘성장하고 싶은 목표도 잡고 실행했는데, 과연 잘 하고 있는 걸까?’와 같은 생각도 많이 하게 됩니다. 그런 생각을 지속하게 되면 결국 생각하는 것 자체가 괴롭기 때문에 이런 생각과 고민이 나쁘다는 결론으로 와닿게 되는데요. 고민은 다양한 의미를 갖고 있어요. 혹시 고민을 보고 괴롭다고만 생각하지는 않으셨나요? 혹은 낙관적인 미래로 언젠가 나아지겠지 생각하며 회피하진 않으셨나요? 아니면, 이런 고민을 떨쳐낸 경험이 있으신가요?
제가 생각하는 고민은 이렇습니다. 고민 위임이라는 단어의 ‘위임’은 누군가에게 넘긴다는 뜻인데요. 고민은 우리에게 많은 기회를 줍니다. 어떤 고민을 누군가에게 위임한다면 소중한 기회와 생각을 놓칠 수도 있기에, 기회비용을 버릴 수도 있어요. 혹시 ‘No Pain No Gain’이라는 말을 들어보셨나요? 고통 없이는 얻는 것도 없다는 말이죠. 같은 고민을 하더라도 밀도 깊은 고민을 하는 경우가 있습니다. 이러한 고뇌를 통해 저희가 무엇을 얻을 수 있을지 생각해 보면 좋은 질문으로 발전하곤 합니다.
성장해야만 하는 이유
우리는 왜 성장하고 싶을까요? ‘내가 성장을 하긴 했을까?’, ‘성장은 어떤 의미를 가질까?’에 대해 생각을 깊이 해보셨으면 좋겠어요. 생각해 보면 성장해야 하는 이유는 많아요. 워라밸, 더 나은 삶, 연봉, 커리어, 아니면 성장 자체가 행복이고 만족으로 다가올 수도 있겠죠. 이렇듯 성장을 바라보는 요소는 개인마다 다양하게 다가옵니다. 근본적으로 우리가 무언가를 이루기 위해 성장하고 싶은 건지, 아니면 성장 그 자체에서 무언가를 얻고 싶은 건지, 성장이 나에게 어떤 의미를 가지는지가 선행돼야 합니다.성장해야만 하는 이유는 이렇습니다. 솔직한 욕망 드러내기, 목표에 맞는 방향 조준하기, 직접 실행하기, 성장 확인하기인데요. 솔직한 욕망을 드러냈을 때 생각보다 성장을 바라보는 관점이 굉장히 달라집니다. 누군가는 성장을 수단으로 생각하고, 누군가는 성장을 목표로 두는데요. ‘훌륭한 개발자가 되기 위해 성장하겠다’거나 ‘성장해서 좋은 회사를 가겠다’와 같은 예시처럼 목표는 누구나 다른데, ‘이 성장이 나에게 어떤 도움을 줄 것인가’하는 욕망을 솔직하게 드러낸다면 그때부터 구체화해서 방향을 잡을 수 있습니다. ‘Hello world를 출력하면 언어의 반은 배웠다’는 말을 들어보셨을 거예요. 그런데 이것을 반대로 말하는 분도 계시더라고요. ‘할 줄 아는 것의 반밖에 되지 않는다’라고요. 결국엔 성장을 어떤 관점으로 바라보고, 어떠한 목표로 생각하느냐에 따라 방향을 더 정확히 잡을 수 있어요. 그 방향으로 차근차근 단계를 밟아갔을 때 굳이 많은 노력을 들이며 고통받지 않더라도 중간은 갈 수 있다는 생각에 이러한 내용을 담게 되었습니다.
완벽한 계획을 세우더라도 아무런 노력을 하지 않으면 아무 일도 일어나지 않듯이, 결국 실행해야 한다는 것을 다시 한 번 강조하고 싶습니다. 성장을 확인하는 것을 생각보다 많은 분이 어려워 하시는데요. 취업했을 때 사수가 없는 경우도 있고, 사수는 있는데 프론트엔드 개발자가 없고 서버 개발자만 많은 경우도 있고, 본인이 프론트엔드 개발자인지, 퍼블리셔인지, 백엔드 개발자인지 헷갈려 하시는 분도 많습니다. 그러다 보니 그에 대한 답을 열심히 물어보고 찾아보지만 피드백조차 받지 못하는 환경이 많이 생기는데요. 다양한 스터디나 멘토링을 통해 조금 더 해결하면 성장해야만 하는 이유를 찾을 수 있을 것 같습니다.
고민 위임
앞서 말했듯, 다양한 스터디나 멘토링과 같이 의지할 곳이 생기게 되면 결국 누군가에게 고민을 떠넘기기 시작합니다. ‘성장하고 싶은 목표도 잡고 실행했는데, 과연 잘 하고 있는 걸까?’와 같은 생각도 많이 하게 됩니다. 그런 생각을 지속하게 되면 결국 생각하는 것 자체가 괴롭기 때문에 이런 생각과 고민이 나쁘다는 결론으로 와닿게 되는데요. 고민은 다양한 의미를 갖고 있어요. 혹시 고민을 보고 괴롭다고만 생각하지는 않으셨나요? 혹은 낙관적인 미래로 언젠가 나아지겠지 생각하며 회피하진 않으셨나요? 아니면, 이런 고민을 떨쳐낸 경험이 있으신가요?제가 생각하는 고민은 이렇습니다. 고민 위임이라는 단어의 ‘위임’은 누군가에게 넘긴다는 뜻인데요. 고민은 우리에게 많은 기회를 줍니다. 어떤 고민을 누군가에게 위임한다면 소중한 기회와 생각을 놓칠 수도 있기에, 기회비용을 버릴 수도 있어요. 혹시 ‘No Pain No Gain’이라는 말을 들어보셨나요? 고통 없이는 얻는 것도 없다는 말이죠. 같은 고민을 하더라도 밀도 깊은 고민을 하는 경우가 있습니다. 이러한 고뇌를 통해 저희가 무엇을 얻을 수 있을지 생각해 보면 좋은 질문으로 발전하곤 합니다.
ⓒ 장현석
유효하지 않은 질문
질문을 하는데 안타깝게도 ‘유효하지 않은 질문’으로 도출되는 때도 있습니다. 그렇게 되면 결국 질문에 의존하는 경우가 생기곤 합니다. 혹시 여러분도 질문에 의존해 본 경험이 있으신가요? 어떤 것에 대해 질문해서 받은 답변에 한 번이라도 의심해 본 경험이 있으신가요? 제가 받았던 수많은 질문 혹은 스스로 생각했던 질문에 대해 몇 가지 요약을 해봤는데요. 대략 열 가지가 조금 넘는 질문들이었어요. 이걸 보고 여러분도 같은 질문을 얼마나 해보셨는지 확인해 보고 싶습니다.
여기 있는 질문 중 여러분은 같은 질문을 얼마나 해보셨고, 경험을 얼마나 나눠 보셨을까요? 사실 프론트엔드 개발자로 일하다 보면 해야 할 것도 많고 대화할 것도 많아서 앞으로 배워야 할 것들이 많구나!라고 느끼게 될 거예요. 결국 그런 생각들에 매몰돼 잘하고 있는 사람도 흔들리는 경우가 있어요. 반대로 프론트엔드 개발자가 서버를 알아야 하는지, CSS는 꼭 해야 하는지, 책 추천을 해달라고 한다든지 등 내가 고민하고 질문하는 것들 중 스스로 해결할 수 있는 것인데도 이런 질문을 하며 선을 긋고 한계를 만든 적은 없는지 생각해 보세요. 저는 이런 질문을 한 번도 안 해본 사람은 극히 드물다고 생각해요. 그만큼 개발자들이 많은 고민을 하고, 성장하고 싶은 욕구가 많다는 말이겠죠.
따라서 어떤 질문을 하느냐보다 어떻게 질문하는지가 중요합니다. 스스로에게 질문해 보고 정해진 답을 확인하지 않고, 결정권을 위임하지 않고, 옳은 결정이 되도록 노력한다는 건 무엇일까요? 사실 어렸을 때부터 모르는 게 있으면 질문하는 게 좋다고 배우지만, 과연 개발자 입장에서도 마찬가지일까요? 사실 개발자 스스로도 해결할 수 있는 방법이 많습니다.
저희가 누군가에게 질문할 때 어떤 상태고, 어떤 시련을 겪고 있고, 어떠한 고민이 있는지 잘 정리해서 질문해도 생각보다 답변하는 분들은 자신의 경험에 의존해서 대답하는 경우가 많습니다. 그 때문에 자문자답해 보는 것을 추천합니다. 아니면 누군가와 질문&답변을 나누며 추론해 보는 경험을 가지셨으면 좋겠고요. 흔히 커뮤니티에 어떤 질문했을 때 동일한 질문이 중복적으로 올라와 지속적으로 같은 사람이 답변하고, 질문하는 사람만 질문하는 경우가 있는데요. 이런 상황에 대해 한 번이라도 고민해 본 경험이 있다면 그 답은 간단히 나옵니다. 바로 정해진 답을 확인하기 위함일 수도 있습니다. 저희가 어떠한 답을 스스로 결정해놓고 훌륭한 사람들, 훌륭한 개발자에게 답을 받으면 그것에 위안 받을 때가 있어요. 그렇기 때문에 심리 테스트와 같은 질문을 하기보다는 다양한 질문을 하고 다양한 답변을 스스로 내는 과정을 갖는 사이클이 중요합니다.
저희가 구글링에 한두 번쯤은 질문해 보는 prefix(접두사)가 있습니다. 혹시 구글에 이렇게 검색해 본 적이 있으실까요? JavaScript, React, Redux를 검색하며 타인이 만든 사례들, 혹은 타인이 해결해낸 과정을 많이 참고하려 하죠. 이처럼 누군가 이미 만들어놓은 길을 찾아보고, 편하게 가려고 했던 경험이 있지 않으신가요?
모범 사례
Best Practice를 직역하면 ‘모범 사례’가 되는데요. 저희는 종종 헤매지 않고 지름길로 가기 위해 Best practice를 검색하게 됩니다. 흔히 말하는 ‘클론 코딩’을 해본 경험이 있으실 거예요. 남들이 만들어 놓은 것을 따라 작성하고 어느 정도 이해하고 넘어갔다고 생각했는데, 나중에 직접 짜보려고 하면 기억이 나지 않는 경우도 있죠.
사실 훌륭한 개발자는 너무 많고, 비교하다 보면 내 자신이 한없이 작아지는 순간이 있어요. 남과 비교할 시간에 자신을 분석해서 뭘 잘하고, 뭘 못하는지 비교하는 시간을 가지면 좋습니다. 저희가 이력서를 쓰거나 멘토링을 받으면서 이런 자기 객관화를 계속해서 축적해 나간다면 조금 더 옳은 길을 찾을 수 있을 거고요. 남이 간 길을 그대로 따라가다 보면 때론 정답이 아닌 경우가 있더라고요. 가끔은 좋은 경험을 통해서 성장하기보다, 일부러 헤매는 것도 엄청난 도움이 된다는 것을 말씀드리고 싶었습니다.
프론트엔드 엔지니어로 성장하기
여러분은 프론트엔드 개발자에 대한 의미를 생각해 본 적 있으신가요? 지금까지 프론트엔드 개발자가 어떻게 성장해왔고, 고민했고, 문제를 해결해서 질문과 답변을 스스로 추론했는지 공유해 보았습니다. 프론트엔드 개발자에 대해 생각보다 ‘개발자’에만 초점을 두는 분들이 많으신데요. 개발자에 초점 둘 것이 아니라 사용자에 초점을 두세요. 사용자의 환경과 경험을 개선하는 것도 프론트엔드 개발자의 역할인데 저희가 이것을 너무 놓치고 있는 것이 아닌지, 혹은 너무나 매몰되어 React, Redux, 스토어구조, 브라우저 같은 기술적 부분에만 매몰돼 있는 것은 아닌지 다시 한번 생각해 보셨으면 좋겠습니다.
사실 저희가 목표를 두고 달려가다 보면 한없이 지치고, 성장하는 것 같지 않고, 끝도 없는 느낌을 받곤 합니다. 여러분도 언젠가 뒤를 돌아봤을 때 그 누구보다도 성장했고, 뛰어나게 올라왔다는 걸 느낄 때가 올 거예요. 자기 객관화를 잘하고, 그 과정을 통해 어떻게 성장할 수 있는지, 성장에 대해 솔직하게 정의하는 프론트엔드 개발자가 되기 위해 노력해 보세요. 이 글을 보는 분들 모두 좋은 개발자가 될 수 있을 겁니다.
유효하지 않은 질문
질문을 하는데 안타깝게도 ‘유효하지 않은 질문’으로 도출되는 때도 있습니다. 그렇게 되면 결국 질문에 의존하는 경우가 생기곤 합니다. 혹시 여러분도 질문에 의존해 본 경험이 있으신가요? 어떤 것에 대해 질문해서 받은 답변에 한 번이라도 의심해 본 경험이 있으신가요? 제가 받았던 수많은 질문 혹은 스스로 생각했던 질문에 대해 몇 가지 요약을 해봤는데요. 대략 열 가지가 조금 넘는 질문들이었어요. 이걸 보고 여러분도 같은 질문을 얼마나 해보셨는지 확인해 보고 싶습니다.여기 있는 질문 중 여러분은 같은 질문을 얼마나 해보셨고, 경험을 얼마나 나눠 보셨을까요? 사실 프론트엔드 개발자로 일하다 보면 해야 할 것도 많고 대화할 것도 많아서 앞으로 배워야 할 것들이 많구나!라고 느끼게 될 거예요. 결국 그런 생각들에 매몰돼 잘하고 있는 사람도 흔들리는 경우가 있어요. 반대로 프론트엔드 개발자가 서버를 알아야 하는지, CSS는 꼭 해야 하는지, 책 추천을 해달라고 한다든지 등 내가 고민하고 질문하는 것들 중 스스로 해결할 수 있는 것인데도 이런 질문을 하며 선을 긋고 한계를 만든 적은 없는지 생각해 보세요. 저는 이런 질문을 한 번도 안 해본 사람은 극히 드물다고 생각해요. 그만큼 개발자들이 많은 고민을 하고, 성장하고 싶은 욕구가 많다는 말이겠죠.
따라서 어떤 질문을 하느냐보다 어떻게 질문하는지가 중요합니다. 스스로에게 질문해 보고 정해진 답을 확인하지 않고, 결정권을 위임하지 않고, 옳은 결정이 되도록 노력한다는 건 무엇일까요? 사실 어렸을 때부터 모르는 게 있으면 질문하는 게 좋다고 배우지만, 과연 개발자 입장에서도 마찬가지일까요? 사실 개발자 스스로도 해결할 수 있는 방법이 많습니다.
저희가 누군가에게 질문할 때 어떤 상태고, 어떤 시련을 겪고 있고, 어떠한 고민이 있는지 잘 정리해서 질문해도 생각보다 답변하는 분들은 자신의 경험에 의존해서 대답하는 경우가 많습니다. 그 때문에 자문자답해 보는 것을 추천합니다. 아니면 누군가와 질문&답변을 나누며 추론해 보는 경험을 가지셨으면 좋겠고요. 흔히 커뮤니티에 어떤 질문했을 때 동일한 질문이 중복적으로 올라와 지속적으로 같은 사람이 답변하고, 질문하는 사람만 질문하는 경우가 있는데요. 이런 상황에 대해 한 번이라도 고민해 본 경험이 있다면 그 답은 간단히 나옵니다. 바로 정해진 답을 확인하기 위함일 수도 있습니다. 저희가 어떠한 답을 스스로 결정해놓고 훌륭한 사람들, 훌륭한 개발자에게 답을 받으면 그것에 위안 받을 때가 있어요. 그렇기 때문에 심리 테스트와 같은 질문을 하기보다는 다양한 질문을 하고 다양한 답변을 스스로 내는 과정을 갖는 사이클이 중요합니다.
저희가 구글링에 한두 번쯤은 질문해 보는 prefix(접두사)가 있습니다. 혹시 구글에 이렇게 검색해 본 적이 있으실까요? JavaScript, React, Redux를 검색하며 타인이 만든 사례들, 혹은 타인이 해결해낸 과정을 많이 참고하려 하죠. 이처럼 누군가 이미 만들어놓은 길을 찾아보고, 편하게 가려고 했던 경험이 있지 않으신가요?
모범 사례
Best Practice를 직역하면 ‘모범 사례’가 되는데요. 저희는 종종 헤매지 않고 지름길로 가기 위해 Best practice를 검색하게 됩니다. 흔히 말하는 ‘클론 코딩’을 해본 경험이 있으실 거예요. 남들이 만들어 놓은 것을 따라 작성하고 어느 정도 이해하고 넘어갔다고 생각했는데, 나중에 직접 짜보려고 하면 기억이 나지 않는 경우도 있죠.사실 훌륭한 개발자는 너무 많고, 비교하다 보면 내 자신이 한없이 작아지는 순간이 있어요. 남과 비교할 시간에 자신을 분석해서 뭘 잘하고, 뭘 못하는지 비교하는 시간을 가지면 좋습니다. 저희가 이력서를 쓰거나 멘토링을 받으면서 이런 자기 객관화를 계속해서 축적해 나간다면 조금 더 옳은 길을 찾을 수 있을 거고요. 남이 간 길을 그대로 따라가다 보면 때론 정답이 아닌 경우가 있더라고요. 가끔은 좋은 경험을 통해서 성장하기보다, 일부러 헤매는 것도 엄청난 도움이 된다는 것을 말씀드리고 싶었습니다.
프론트엔드 엔지니어로 성장하기
여러분은 프론트엔드 개발자에 대한 의미를 생각해 본 적 있으신가요? 지금까지 프론트엔드 개발자가 어떻게 성장해왔고, 고민했고, 문제를 해결해서 질문과 답변을 스스로 추론했는지 공유해 보았습니다. 프론트엔드 개발자에 대해 생각보다 ‘개발자’에만 초점을 두는 분들이 많으신데요. 개발자에 초점 둘 것이 아니라 사용자에 초점을 두세요. 사용자의 환경과 경험을 개선하는 것도 프론트엔드 개발자의 역할인데 저희가 이것을 너무 놓치고 있는 것이 아닌지, 혹은 너무나 매몰되어 React, Redux, 스토어구조, 브라우저 같은 기술적 부분에만 매몰돼 있는 것은 아닌지 다시 한번 생각해 보셨으면 좋겠습니다.사실 저희가 목표를 두고 달려가다 보면 한없이 지치고, 성장하는 것 같지 않고, 끝도 없는 느낌을 받곤 합니다. 여러분도 언젠가 뒤를 돌아봤을 때 그 누구보다도 성장했고, 뛰어나게 올라왔다는 걸 느낄 때가 올 거예요. 자기 객관화를 잘하고, 그 과정을 통해 어떻게 성장할 수 있는지, 성장에 대해 솔직하게 정의하는 프론트엔드 개발자가 되기 위해 노력해 보세요. 이 글을 보는 분들 모두 좋은 개발자가 될 수 있을 겁니다.
ⓒ 장현석
Q&A
1. 요즘 리액트를 사용하는 회사가 많은데, 저희 회사는 앵귤러를 사용하고 있습니다. 그런데 리액트를 사용하는 회사로 이직할 수 있을까요?
목표로 두는 회사가 어디냐에 따라 다르겠지만, Angular든 React든 Vue든 결국 JavaScript거든요. Angular를 잘하는 사람은 React를 금방 잘 할 수 있고, Angular를 잘 하지 못하는 사람은 React도 금방 잘하기 어렵기 때문에 그것에 대해 크게 걱정할 필요 없으니까 조금씩 과감하게 도전해 보는 것을 추천하고요. 가고 싶은 회사가 높은 목표를 갖고 있는, 요새 유행하는 ‘네카라쿠배’ 같은 회사라면 Angular를 하셨어도 실력 있는 사람들을 뽑을 수 있는 프로세스가 갖춰져있기 때문에 충분히 노력만 하시면 그런 걱정은 하실 필요가 없을 것 같습니다.
2. 개발자를 시작하게 된 초반에 회사에서 잘 못하면 어떡하지?, 실수하면 어떡하지? 같은 중압감이 있으셨을 때는 어떻게 이겨내셨는지요?
일단 실력이 부족하다는 근거부터 판단할 수 있는 객관화를 기르면 좋겠다는 생각이 들어요. 스스로 실력이 부족하다고 느끼는데 실제로는 겸손한 걸 수도 있거든요. 그것에 대해 객관적으로 바라볼 수 있는 시선을 가져볼 수 있으면 좋고요. 그리고 정말로 실력이 부족하다면, 그 실력 부족에 영향을 준 집단이나 그룹이 있겠죠. 그곳에서 중간이라도 가면 중압감이 해소될 거라고 생각해요. 그것을 이겨내지 못하면 계속 버텨야 하거든요. 어차피 언젠가는 버텨서 이겨내야 하는 상황이 오기 때문에 1층에서 10층으로 바로 갈 수 없듯이 1, 2, 3층 차근차근 버티면서 올라가는 희열이 있어야 될 것 같습니다. 그렇지 않으면 계속 버텨야 하니까요.
3. 프론트엔드 개발자를 준비하시는 분들이 많은데 이런 분들을 위해 어떤 걸 먼저 공부해 보는 게 좋을까요? 자바 스크립트 스펙부터 보세요! 같은 것 말고 도움이 될만한 게 있을지 답변 부탁드립니다.
사실 프론트엔드 개발자가 되고 싶다고 하지만, 그 기준은 어떤 회사의 프론트엔드 개발자로 취업하냐가 전제조건인 것 같아요. 그럼 채용공고를 분석하는 것부터 해야 될 것 같고요. 여기서 뭐가 부족한지, 뭘 공부해야 할지 객관화해서 구체화해야겠죠. 가장 높은 수준이 구글이라고 치고 ‘내가 당장 갈 수 있는 회사가 어디에 있을까’라며 객관적으로 뭘 공부하고 강화해야 할지 생각해 보세요. 그 다음 채용 공고를 분석하고 관찰하면서 추세를 보고, 좋은 타이밍을 잡고, 그 타이밍을 잡을 실력을 계속 배양하는 게 기회와 가까워지는 방법이 아닐까 생각합니다.
4. 많은 프론트엔드 개발자 사이에서 차별성을 둘 수 있는 요소는 무엇이 있을까요?
점점 더 프론트엔드 개발자가 할 수 있는 것들이 많아지고 있어요. 기존에는 “HTML, CSS, JavaScript만 잘하면 되고 React 경험이 있으면 프론트엔드 개발자가 될 수 있을 거야”라는 막연한 생각이 있었는데, 지금은 정말 많은 걸 해야 되거나 할 수 있어야 하는 경우가 생겼어요. 흔히 ‘T자형 인재’라고 말하는데요. 내가 조금 더 잘할 수 있는 게 있을 거고, 내가 조금 더 잘하고 싶은 게 있을 거예요. 내가 어떤 차별점을 둘 수 있는지 생각해 보세요. T자형 개발자라고 해서 조금 더 깊이 잘할 수 있는 부분과 조금 더 얇게 넓은 범위로 가져갈 수 있는 부분을 생각하셔야 모든 항목에 매몰되지 않고 자신감을 가질 수 있다고 생각합니다. 그러니 조금 더 잘하고 싶은 부분과 잘할 수 있는 부분을 생각해 보세요!
5. 구조부터 코드를 전체적으로 까보는데 훌륭한 샘플이 될만한 오픈소스가 있다면 추천해 주실 수 있나요?
첫 번째는 리덕스 미들웨어 중에 ‘Redux Thunk’라고 있는데, 그걸 꼭 한번 보셨으면 좋겠어요. 엄청 거대하고 어려운 것만이 라이브러리나 프레임워크라고 생각하는 경우가 있는데요. ‘이렇게 간단하게 코드를 짜서 많은 사람들의 어려움을 해결할 수 있구나’ 하는 생각을 할 수 있는 라이브러리이자 미들웨어가 ‘Redux Thunk’거든요. 그래서 그 코드를 한번 찾아봤으면 좋겠어요.
그리고 lodash로 많은 분이 사이드 프로젝트로 공부를 하는 걸 봤어요. 우리가 자주 찾아서 쓰는 만큼 우리의 문제를 해결할 수 있는 코드를 갖고 있기 때문에 부분 부분 필요에 의해 학습하기 좋거든요. 처음부터 끝까지 보지 못하면 다 공부한 것 같은 느낌이 안 들어서 범위 위주의 학습을 생각하는데, 시간 날 때마다 lodash 함수의 일부분을 찾아 공부하면 흥미롭게 접근할 수 있다고 생각합니다.
▶ <꿈의 직장 ‘네카라쿠배당토’> 시리즈 보러 가기
CREDIT
김수진ㅣ객원 에디터
발행일 2022.02.09
Q&A
1. 요즘 리액트를 사용하는 회사가 많은데, 저희 회사는 앵귤러를 사용하고 있습니다. 그런데 리액트를 사용하는 회사로 이직할 수 있을까요?
목표로 두는 회사가 어디냐에 따라 다르겠지만, Angular든 React든 Vue든 결국 JavaScript거든요. Angular를 잘하는 사람은 React를 금방 잘 할 수 있고, Angular를 잘 하지 못하는 사람은 React도 금방 잘하기 어렵기 때문에 그것에 대해 크게 걱정할 필요 없으니까 조금씩 과감하게 도전해 보는 것을 추천하고요. 가고 싶은 회사가 높은 목표를 갖고 있는, 요새 유행하는 ‘네카라쿠배’ 같은 회사라면 Angular를 하셨어도 실력 있는 사람들을 뽑을 수 있는 프로세스가 갖춰져있기 때문에 충분히 노력만 하시면 그런 걱정은 하실 필요가 없을 것 같습니다.
2. 개발자를 시작하게 된 초반에 회사에서 잘 못하면 어떡하지?, 실수하면 어떡하지? 같은 중압감이 있으셨을 때는 어떻게 이겨내셨는지요?
일단 실력이 부족하다는 근거부터 판단할 수 있는 객관화를 기르면 좋겠다는 생각이 들어요. 스스로 실력이 부족하다고 느끼는데 실제로는 겸손한 걸 수도 있거든요. 그것에 대해 객관적으로 바라볼 수 있는 시선을 가져볼 수 있으면 좋고요. 그리고 정말로 실력이 부족하다면, 그 실력 부족에 영향을 준 집단이나 그룹이 있겠죠. 그곳에서 중간이라도 가면 중압감이 해소될 거라고 생각해요. 그것을 이겨내지 못하면 계속 버텨야 하거든요. 어차피 언젠가는 버텨서 이겨내야 하는 상황이 오기 때문에 1층에서 10층으로 바로 갈 수 없듯이 1, 2, 3층 차근차근 버티면서 올라가는 희열이 있어야 될 것 같습니다. 그렇지 않으면 계속 버텨야 하니까요.
3. 프론트엔드 개발자를 준비하시는 분들이 많은데 이런 분들을 위해 어떤 걸 먼저 공부해 보는 게 좋을까요? 자바 스크립트 스펙부터 보세요! 같은 것 말고 도움이 될만한 게 있을지 답변 부탁드립니다.
사실 프론트엔드 개발자가 되고 싶다고 하지만, 그 기준은 어떤 회사의 프론트엔드 개발자로 취업하냐가 전제조건인 것 같아요. 그럼 채용공고를 분석하는 것부터 해야 될 것 같고요. 여기서 뭐가 부족한지, 뭘 공부해야 할지 객관화해서 구체화해야겠죠. 가장 높은 수준이 구글이라고 치고 ‘내가 당장 갈 수 있는 회사가 어디에 있을까’라며 객관적으로 뭘 공부하고 강화해야 할지 생각해 보세요. 그 다음 채용 공고를 분석하고 관찰하면서 추세를 보고, 좋은 타이밍을 잡고, 그 타이밍을 잡을 실력을 계속 배양하는 게 기회와 가까워지는 방법이 아닐까 생각합니다.
4. 많은 프론트엔드 개발자 사이에서 차별성을 둘 수 있는 요소는 무엇이 있을까요?
점점 더 프론트엔드 개발자가 할 수 있는 것들이 많아지고 있어요. 기존에는 “HTML, CSS, JavaScript만 잘하면 되고 React 경험이 있으면 프론트엔드 개발자가 될 수 있을 거야”라는 막연한 생각이 있었는데, 지금은 정말 많은 걸 해야 되거나 할 수 있어야 하는 경우가 생겼어요. 흔히 ‘T자형 인재’라고 말하는데요. 내가 조금 더 잘할 수 있는 게 있을 거고, 내가 조금 더 잘하고 싶은 게 있을 거예요. 내가 어떤 차별점을 둘 수 있는지 생각해 보세요. T자형 개발자라고 해서 조금 더 깊이 잘할 수 있는 부분과 조금 더 얇게 넓은 범위로 가져갈 수 있는 부분을 생각하셔야 모든 항목에 매몰되지 않고 자신감을 가질 수 있다고 생각합니다. 그러니 조금 더 잘하고 싶은 부분과 잘할 수 있는 부분을 생각해 보세요!
5. 구조부터 코드를 전체적으로 까보는데 훌륭한 샘플이 될만한 오픈소스가 있다면 추천해 주실 수 있나요?
첫 번째는 리덕스 미들웨어 중에 ‘Redux Thunk’라고 있는데, 그걸 꼭 한번 보셨으면 좋겠어요. 엄청 거대하고 어려운 것만이 라이브러리나 프레임워크라고 생각하는 경우가 있는데요. ‘이렇게 간단하게 코드를 짜서 많은 사람들의 어려움을 해결할 수 있구나’ 하는 생각을 할 수 있는 라이브러리이자 미들웨어가 ‘Redux Thunk’거든요. 그래서 그 코드를 한번 찾아봤으면 좋겠어요.
그리고 lodash로 많은 분이 사이드 프로젝트로 공부를 하는 걸 봤어요. 우리가 자주 찾아서 쓰는 만큼 우리의 문제를 해결할 수 있는 코드를 갖고 있기 때문에 부분 부분 필요에 의해 학습하기 좋거든요. 처음부터 끝까지 보지 못하면 다 공부한 것 같은 느낌이 안 들어서 범위 위주의 학습을 생각하는데, 시간 날 때마다 lodash 함수의 일부분을 찾아 공부하면 흥미롭게 접근할 수 있다고 생각합니다.
▶ <꿈의 직장 ‘네카라쿠배당토’> 시리즈 보러 가기
CREDIT
김수진ㅣ객원 에디터
발행일 2022.02.09