지금 시작하는 프론트엔드 개발자를 위한 조언
서적을 읽고 내용과 개인 생각을 정리한 글 입니다.
1. 학습 : 이론과 실전
프론트엔드 를 시작하려는 많은 개발자들이 커리어 로드맵을 따라 HTML, CSS, JS 를 먼저 배워야만 개발을 시작 할 수 있다고 생각 한다.
-> 물론 언어적 특성과 문법을 아는 것은 개발을 하는데 굉장히 큰 도움이 된다.
( 나도 그랬다... 하고 싶은데 방향을 못 잡아서 이런거 저런거 보다 언어 배우기 부터 했었다.)
하지만 그것이 개발의 전부는 아니다.
1.1 개발자로서 개발을 학습 할 때 두 가지의 영역
1.1.1 제품을 만드는 영역
말 그대로 제품을 만들어내는 능력
- 스펙을 분석해서 적절한 수준의 기술 스택을 선택하여 만들어내서 어딘가에 가치를 만드는 것
ex) 개인 블로그를 누구는 워드프레스, 누군가는 React 를 사용해서 블로그를 만든다.
이 영역에서 가장 중요하다고 생각 하는 것은 '문제를 해결하는 능력' 이라고 생각 한다.
- 만들어나가는 과정에서 다양한 문제들을 직면하고, 하나씩 해결해나가면서 제품을 만든다.
- 이게 중요한 이유는 특히 프론트엔드 개발자들은 유저들이 사용하는 제품을 만드는 것이 주된 업무이기 때문이다.
만약 이론을 아무리 많이 알고 있어도 제품을 만들 수 없다면 능력을 제대로 활용하기 있다고 보기 어렵고, 오히려 이론을 완벽히 이해했다고 보기 어려운 상태일 수도 있다.
1.1.2 원리를 이해하는 영역
원리를 이해하는 영역은 내가 만든 코드, 혹은 다른 사람이 만든 코드가 어떻게 동작하는지
ex) '자바스크립트 엔진이 어떻게 동작하는가', '렌더링 엔진은 어떻게 동작하는가' 등
원리를 이해하는 영역을 모른다고 제품을 만들지 못하는 것은 아니지만,
-> 좋은 제품을 만들기 위해서는 원리를 이해하고 있어야 한다.
원리를 이해해야 디버깅하기 좋은코드, 유지보수 하기 좋은 코드, 성능이 좋은 코드가 나온다.
-> 무엇보다 다른 사람의 코드를 리뷰 할 때도 명확한 이유를 바탕으로 리뷰할 수 있다.
위의 두 가지 영역은 뗄 수 없는 관계다.
개발자들에게 위의 영역들은 뗄 수 없는 관계임에도,
- 많은 개발자들이 원리에만 치우쳐 제품을 만들지 않거나
- 제품에만 치우쳐 원리를 이해하지 못하는 상황이 종종 존재한다.
위와 같은 상황이되면, 프로젝트는 많이 해봤지만 실속은 부족한 사람이 될 수 있고,
지식은 많지만 경험이 적은 사람이 될 수 있다.
1.2 솔루션
제품을 만드는 것만 초점을 맞추다보면 '이 코드가 왜 동작하는지 모르지만 어쨌든 동작은 하는 상태' 가 완성된다.
이를 방지하기 위해서는
- 개발을 하다가 원리가 이해되지 않았던 부분을 키워드별로 정리하고, 프로젝트가 끝나면 블로그나 개별적으로 정리해서 발행하는 습관을 들이면 좋다.
2. 학습 : 선택과 집중
이제 막 개발 공부를 시작했다면, 배워야 할 내용이 많다.
이 말은 개발 시장이 성숙해졌다는 증거이기도 하지만,
그 만큼 수준 높은 개발자를 요구한다는 것 이다.
최근 개발을 배우는 학생들에게서 공통적으로 보이는 것은 조급함 이며, 굉장히 많은 내용을 한 번에 습득 하려다가 중요한 지식을 습득하지 못하는 경우를 많이 본다.
예를 들어, 자바스크립트가 어떻게 동작하는가에 대한 디테일한 지식은 지금 단계의 여러분에게 필요하지 않을 수 있다.
- 오히려, 당장 코드 한 줄이라도 쳐보면서 친해지는 과정을 거치고
- 버그가 나도 당황하지 않고 에러 로그를 보는 습관을 들이거나
- 제품 하나가 돌아가기 위해 어떤 일을 해야 하는지 파악하는 등의 일들이 우선시 되야 한다고 생각 한다.
처음부터 너무 많은 지식을 습득해야 할 것 같다고 지레 겁먹지 말자.
-> 개발에서는 적어도 사용 사례를 이해하고 원리를 이해했을 때 더 이해가 잘된다고 생각하기 때문에, 개발에서의 학습 방법은 지금 내가 프로젝트에서 사용하고 있는 기술 중 모르는 것을 중점적으로 공부하자!
3. 비전공자 : CS 지식에 대해
만약 컴퓨터공학을 전공하지 않았다면 항상 '내가 비전공자 라서' 라는 생각이 들 수 있다.
-> 어떻게 보면 당연하다. 전공을 한 사람이 개발을 잘할 가능성이 높다.
역으로 전공자라면 다른 전공자들은 다 잘하는 것 같은데 유독 나만 못하는게 아닌가, 라는 생각이 들 수 있다.
3.1 CS 지식은 어떻게 공부할까요 ?
기초 CS 지식을 다루고 있는 책은 많다.
- <1일 1로그 100일 완성 IT 지식>
- <한 권으로 읽는 컴퓨터 구조와 프로그래밍>
문제 해결 능력을 키우기 위해서는 코드를 많이 작성하는 것도 중요하지만, 문제와 계속 마주하며 친해지는 것도 중요하다.
- <알고리즘 문제 해결 전략>
- <코딩 인터뷰 완전 분석>
책을 좋아하는 이유는, 저자의 여러 노하우를 흡수할 수 있기 때문이다.
3.2 조급해하지 말자
시장은 심플하게 동작한다. 기업은 여러분의 능력이 자사의 문제를 해결하고 비즈니스에 도움이 될 거라고 생각하면 여러분을 채용 한다.
지금 채용에 떨어졌다고 해서 1년 뒤 또는 3년 뒤에 또 떨어진다고 보기는 어렵다.
계속 도전하면 적절한 상황이 도래했을 때 얼마든지 합격이 가능하다.
만약 기업의 채용 과정에서 탈락했다고 본인의 실력이 부족하다고 생각하지는 않았으면 한다.
회사마다 원하는 인재의 수준이나 상황도 다르기 때문에 '내가 실력이 부족해서 떨어졌구나' 라고 생각하는 건 감정 소모에 불과하다.
여러분은 스스로 생각하는 것보다 충분히 잘하고 있을 수 있다.
4. 블로그 : 기억은 짧다
이 책의 독자 대부분은 나를 블로그나 강의, 강연을 통해 알게 되었을 테다.
내가 강의, 강연을 시작하게 된 계기는 블로그였다. 내 모든 실무와 관련된 경험은 나의 블로그 속에 녹아있다.
개발자가 블로그를 해야 하는 이유는 여러 가지가 있겠지만, 가장 중요한 이유는 우리가 겪는 이슈 대부분은 언젠가 우리의 기억속에서 사라지기 때문이다.
이렇게 될 경우 훗날 비슷한 이슈를 겪게 될 때 지금까지 한 수고를 반복할 가능성이 높다는 것이다.
블로그에 작성하면 좋은 점은
- 프로젝트를 하면서 마주했던 문제와
- 그 문제의 해결 방안이다.
블로그의 또 다른 역할은
- 내가 얼마나 많은 지식을 보유하고 있는지를 나타내준다는 것이다.
과거 나는 구글 검색엔진의 동작에 대한 글을 작성했다. 글을 써나가면서 구글 검색 엔진의 동작 방식을 깊게 공부했기 때문에 누군가가 내 블로그를 볼 때 '조은 님은 적어도 검색엔진의 동작 방식을 잘알겠구나' 라고 인지할 수 있을 것이다.
개발자의 실력 증명은 의외로 어렵다.
내가 네이버에 다녔으니까 나를 뛰어난 개발자라고 부를 수 있을까 ?
우아한 형제들에 다녔으니까 뛰어난 개발자라고 부를 수 있을까 ?
- 내가 거쳐온 회사가 나의 커리어에 도움이 될 수는 있겠지만, 어떤 회사에 다녔다는 사실 자체가 나의 실력을 일방적으로 증명해주지는 못한다.
4.1 아무튼 글쓰기
이 글을 읽는 대부분이 글쓰기에 거부감 또는 어색함을 느낄 거라 생각한다.
하지만, 지금은 본인이 충분히 관심만 가진다면 양질의 콘텐츠에 접근하는게 얼마든지 가능하다.
- <개발자의 글쓰기>
- <개발자를 위한 글쓰기 가이드>
글쓰기에서 무엇보다 중요한 것은 완성이다.
지금 좀 마음에 들지 않더라도 혹은 부족하게 느껴져도, 잘못된 내용이 아니라면 발행해야 완성이 되고 글에 생명이 불어넣어진다.
일단 공개해보자. 의외로 많은 사람이 당신의 글에서 도움을 얻을 것이다.
4.2 블로그의 목표가 취업을 위해서라면
예전에는 취업을 위해 블로그를 운영한다는 사실 자체에 분개했던 적도 있지만,
모든 것이 스펙이 되어가는 이 시대에는 취업을 위해 블로그를 운영하는 것은 나쁘지 않다고 생각한다.
오히려 나는 블로그가 더 좋은 직장으로 가기 위한 적절한 전략 중 하나라고 생각한다.
작성한 블로그의 내용은 면접 질문으로 이어질 가능성이 높다.
따라서 블로그를 작성할 때는, 어느 정도 본인이 이해하고 있는 내용을 작성하는 것이 중요하다.
Today I Learned (TIL)
주변에 많은 취업 준비생들이 작성한다.
작성하는 행위 자체는 나쁘지 않은 습관이지만, 많은 사람이 TIL 을 하나의 업무라고 생각하면서도 결과적으로 그다지 좋은 글을 작성하지 못하는 경우가 종종 있다.
누군가 쓰라고 하니까 쓰기는 하는데 스스로 TIL의 필요성을 인지하지 못하는 것이다,
TIL 은
- 기억이 휘발되기 전에 오늘 있었던 일들을 정리 하려는 목적
- 오늘 공부한 내용을 나중에 다시 갈무리하기 위해 키워드를 수집하려는 목적으로 쓴다.
- 따라서 TIL 그 자체로 취업 등에 전략적으로 사용하기는 어렵다.
적어도 주니어 개발자, 현업에서 일하는 개발자에게는 업무에서 익힌 내용을 바탕으로 매일 무엇을 공부하고 경험했는지 글로 정리해놓는 게 도움이 될 수 있다.
TIL 전략
- 작성에 30분 이상 쓰지 않는다. 일단 쓰는 데만 집중
- 공개되지 않은 장소에 올린다. 학습 내용을 공유하고 싶다면 별도 블로그 게시물로 작성
- 공개된 장소에 업로드한다면 일주일치를 몰아서 올린다.
5. 이력서
이력서를 쓰는 방법에 대해서는 많은 글이 존재한다.
하지만 나는 이력서에 어떤 걸 쓰지 말아야 하는가에 집중해보고자 한다.
좋은 이력서란 추상적인 영역으로 면접관의 주관에 따라 그 형태가 다를 수 있기 때문이다.
5.1 이력서는 카탈로그다
이력서는 스스로를 판매하기 위한 내용을 여러 회사에 공유하며
'나를 채용하면 당신들 비즈니스에 도움이 될 거야' 라는 내용을 담은 일종의 카탈로그다.
이력서에 어떤 내용을 담을 때 고민해보면 좋은 내용은
1. 다른 사람과 비교할 때 내가 가진 이점
2. 내가 회사의 비즈니스에 어떤 도움을 줄 수 있는지 이다.
5.1.1 보편적인 좋은 점을 작성하지 않기
예를 들어 '열정 있는', '개발을 즐기는', '어제보다 오늘 더 성장하는' 등의 다양한 키워드를 사용하겠지만 생각해보면 그렇지 않은 개발자는 드물다.
한 줄 평을 작성할 때는 면밀하게 자기 자신에 대해 고민할 필요가 있다.
예를 들어 '열정 있는 개발자' 라고 한다면,
- 일일 커밋을 2 ~ 3 년 동안 했다거나,
- 지속해서 공부한 내용을 정리했다거나,
- 토이 프로젝트를 많이 했다거나 하는 액션이 필요하다.
액션 없이 말로만 '열정 있는 개발자' 라고 하는 건 무의미하다.
5.1.2 내용을 꾸역꾸역 채우지 않기
이력서에 쓰는 내용은 정제된 언어로, 꼭 필요한 내용 위주로 작성한다.
서류를 검토하는 사람들은 여러 사람의 이력서를 보기 때문에 필요한 내용만 정리된 이력서를 선호하며, 너무 많은 내용은 노이즈로 인식 할 수 있다.
5.1.3 클론 코딩 프로젝트 Only
클론 코딩은 어떤 기술을 학습하는 데 도움을 주며, 방식 자체도 나쁘다고 할 수는 없다.
하지만, 학습을 위해서가 아니라 취업을 위해 클론 코딩을 사용하겠다면 조금은 전략적이 될 필요가 있다.
-
클론 코딩은 말 그대로 클론 코딩이어야 한다.
-> 많은 사람이 필요한 부분만 구현하고, 디테일은 놓치는 경우가 많다. -
목표 기업의 서비스를 클론해보는 것이 취업에 도움을 줄 수 있다.
-> 카카오에 지원한다면 카카오에서 제공하는 서비스를 클론해보고
-> 거기에서 UX를 개선한 형태로 프로젝트를 진행해 볼 수 있다.
-> 이것은 당신이 해당 회사에 관심을 가지고 있다는 걸 확실히 어필해준다.
중요한 것은
회사가 실제 겪고 있을 문제를 추측함과 동시에, 제품이 가진 문제를 개선하는 경험을 해보는 것이다.
5.2 그렇다면 이력서에 어떤 내용을 담을까 ?
이력서에 담아야 하는 건 현재까지 살아온 삶이 아니라,
앞으로 개발자로서 삶을 잘 영위해나갈 수 있다는 내용이다.
아래와 같은 내용을 넣으면 좋다.
- 내가 현재 보유하고 있는 기술들과 그 수준
- 내가 현재 관심을 가지고 있는 내용들
- 커리어와 직접 연관된 프로젝트의 정보
- 내가 담당한 부분 기능에 대한 Overview
- 내가 겪은 문제, 해결 방안
될 수 있다면
- (가능하다면) 블로그를 통해 내가 가진 지식을 증명
- (가능하다면) Github를 통해 프로젝트를 공유
- (가능하다면) 지금까지 진행한 커리어에 도움이 되는 프로젝트
-> 혹은 커리어에 직접 도움이 되지 않더라도 관심을 가질 수 있는 프로젝트
6. 면접
어느 회사의 면접을 보느냐에 따라 경험이 다르고, 면접 차수에 따라서도 면접 경험은 달라진다.
A 회사는 기술면접에 무게를 싣는 데 반해, B 회사는 인성 면접에 무게를 싣기도 한다.
또한, 경력인지 신입인지에 따라 면접의 형태는 달라진다.
6.1 면접이라는 자리
회사 입장에서는 지원자가 우리와 핏(Fit) 이 맞는지 체크하는 시간이며
동시에 지원자 입장에서는 자기와 핏이 맞는지 체크하는 시간이기도 하다.
다시말해, 면접을 보러 가는 자리라고 해서 일방적으로 기가 죽을 필요는 없다.
6.2 기술 자체에 대해 물어보는 질문
기술 면접에서 물어보는 내용 중 순수하게 기술 지식과 관련한 질문은 준비만 잘하면 의외로 쉽게 풀어나갈 수 있다.
- 최근 기술력이 뛰어나다고 평가받는 기업들은 대부분 기술 블로그를 운영하기 때문에 그것을 보는 것도 좋은 전략이 될 수 있다.
- 면접에서는 보통 그 회사에서 쓰는 기술에 대한 질문이 나올 가능성이 높다.
기술 질문에서는 단골로 등장하는 질문이 있기 때문에 그런 것들을 공부해두는 게 좋다.
6.3 경험에 대해 물어보는 질문
예를 들어, 리액트를 이용해서 에디터를 만들어본 경험이 있는 지원자가 있다면
- 왜 에디터에서 React 를 사용하셨나요? -> React 의 장점과 단점은 어떤 것이 있나요?
- 에디터 자체는 어떤 식을 구현하셨나요? -> Contenteditable 을 사용하셨나요?
- 자동 저장 기능도 고려하셨나요? -> 했다면 어떻게 구현하셨나요?
경험에 대해 물어보는 질문은 크게 문제에 대한 정의와 그 문제를 해결하는 파트로 나누어지고,
문제에 대한 정의는 면접관이 대부분 질문을 통해 내리게 된다.
-> 이 질문에 대한 해답을 본인의 경험을 바탕으로 답변한다.
경험에 대한 질문에서는 꼬리 물기 식의 질문이 많이 나와 심리적 압박감을 느낄 수 있다.
그러나 물어보는 내용 중 답이 정해진 질문은 없기 때문에, 최대한 본인이 알고 경험한 것을 적극 공유하는 것이 좋다.
6.4 회사에 대한 질문
많은 면접에서 '회사에 궁금한 점을 말해보세요' 라는 질문을 던진다.
이 질문은 내가 이 회사에 얼마나 관심이 있는지, 또 기술적으로 얼마나 성장을 원하고 있는 지
어필 할 수 있는 중요한 시간이다.
6.4.1 물어보며 좋은 질문들
- 면접 중 답변을 못했거나, 애매하게 답했다고 생각되는 지식들
- 내가 합류할 조직의 서비스에 대한 질문
- 조직의 기업 문화, 코드 문화에 대한 질문
- 조직의 일하는 방식에 대한 질문
- 기술 블로그 중 인상 깊었던 부분
책을 읽으며,
프론트엔드 개발자가 되고 싶다고 처음 준비할 때 부터 봤다면, 준비하는 방향과 방식이 많이 달랐을 것 같다. 또한 이력서나 면접 부분 등 그리고 전공자이지만 부족하다고 느끼는 CS 지식에 대한 학습 방향까지 이제 막 인턴을 하고있는 지금이라도 읽게 되서 다행이라고 생각한다.
이 게시물을 종종 다시 읽으면서 나의 방향성과 지식들을 풍성하게 채울 수 있는 길을 가도록 노력해야 겠다.
