데브그라운드 주니어 2019 후기

2019-12-24

⏱ 읽기 소요 시간: 17 분

개발자가 갖추어야 할 9가지 기술- 박종천

1년~ 5년 정도 Hard Skill을 익히는 게 중요하다.
회사에서 성공하는 사람은 남들이랑 잘 지내는 사람이다.
다른 사람들과 의견 소통을 하고 아이디어를 합치고 하는 것이 일을 잘하는 것이다.

이력서, 자기소개서에서 중점적으로 보는 부분

내가 왜 이 회사를 선택했는가라는 내용이 있는가를 본다.
왜 당신이 이 회사에 오고 싶은지
당신은 이 회사에 와서 무엇을 할 수 있는가
협업을 잘 하는가

채용의 목표는 잘하는 사람을 뽑는게 아니라, 못하는 사람을 안 뽑기 위한 것이다.
이걸 아는 게 중요하다.

회사 입장에서는 뭘 알아서 와도 입사하면 새로 가르쳐야 한다.
무조건 공부하고 버리는 게 이 업계의 트렌드이다.
개발자에 대한 평가
- 이 사람이 빠르게 배울 수 있느냐 → 똑똑한가
- 부지런한가
- 착해야 한다.(다른 사람을 속이거나 하는 사람은 뽑지 X)

Vision

회사와 팀, 내 인생의 비전이 일치해야 일하기 편해진다.

벤자민- 나는 세상을 배우는 사람과 배우지 않는 사람으로 나눈다.

내가 그 일을 잘하는가 못하는가가 중요한 게 아니다.
꾸준히 배우고 성장하는 게 중요하다.

개발자로서의 자기관리

우리 조직 말고 다른 조직의 사람을 한 달에 한 명씩 1년만 만나봐라.
사람을 만나는 게 중요하다.
한 달에 책 한 권씩 읽어봐라.
이렇게 2가지만해도 큰 변화다.

시간 관리

자기관리는 시간관리다. (돈도 마찬가지)

필요한 데에 쓰는 것
낭비하는 것
투자하는 것

본인이 사용한 시간을 1주일동안 위의 3가지 항목으로 나눠서 분석해보고 계획하자.

낭비를 0으로 줄이고 투자를 극한으로 30%로 올려야 한다.
- ex) 책을 1주일에 1 권 읽고, 운동은 1주일에 1시간
주니어 시기에는 최대한 시간 투자를 해야 한다.
공부하고 사람들 만나고, 영어를 공부해라.
지금부터 영어를 미친듯이 해놓아야 나중에 돌아온다.

AI: 막막해하는 당신에게- 임태규

AI란 무엇인가?

4차 산업혁명: 현재 진행형
사람 대신 AI

1. 기본적으로 언어를 많이 알아야 한다.

프로그래밍 언어

기본적인 언어를 잘 알되, 해석하는 능력을 키워야 한다.
→ 코드 리뷰를 잘해야 한다. 다른 사람의 코드를 보고 의도를 명확하게 파악하고,
본인이 코드를 짰을 때 다른 사람이 의도를 명확하게 파악할 수 있게 짤 수 있어야 한다.
한 언어만 깊게 파서 잘 알아두면, 언어들은 비슷한 점이 많으므로 쉽게 배울 수 있게 된다.

2. 언어를 알고 있는데, 어떻게 활용하지?

기본적으로 Data Structure를 알고 있어야 한다.
어떨 때 어떤 자료구조를 써야 하지?가 중요하다.
연습 밖에 방법이 없다.
최소한 10문제 이상 풀어보기

이력서, 면접

나 자신을 잘 세일즈 해야 한다. (회사에서 원하는 기술과 방향으로)
반드시 프로젝트를 진행했을 때, 장점, 단점, 가치를 반드시 얘기할 수 있어야 한다.
- ex) 각각 이런 Function들이 있고, 이런 key들이 있고
  1초가 걸리는 이슈가 있었고, 이를 1/ms로 줄였다는 식으로 본인이 이슈를 해결한 경험을 얘기할 수 있어야 한다.
실패한 프로젝트는 없다. 끝내지 않은 프로젝트만 있을 뿐이다.
무슨 일이든 이것이 성공하든 실패하든 끝을 보자. (무얼 만들기로 했으면 그 끝을 보자.)

이 프로젝트에서 내가 얻은 게 뭐고, 실패했던 것, 보안할 것들을 > 체크리스트로 만들고 보안해나가자.

Time & Work

Time management(30 minutes)

출근을 하면, 16개의 셀(30분 단위)로 나누고 셀마다 할 일을 나누어 적기

Work management

해야 할 것
할 수 있는 것
하지 말아야 할 것- 내가 손대면 오늘 죽겠다하는 것들

하지 말아야 할 것이 줄어들고, 할 수 있는 것이 늘어날 수 있도록 시간 관리를 하자.

So. What would you sell?

능력은 무궁무진하다. 내 능력을 어떻게 세일즈할까를 잘 고민해보고 표현해야 한다.

Q&A

파이썬을 중점적으로 깊게 파는 게 중요하다.
선형대수, 확률, 물리
수학을 모르고 라이브러리만 사용한다면, 한 단계를 더 나아갈 수 없다.
수식을 알고 있다면, 머릿속에 있는 생각을 수식으로 만들고 알고리즘으로 표현할 수 있다.

내가 주니어 개발자 때 알았더라면 좋았을 것들

Part1. 김태현

연봉을 떠나서 그 업계의 1위 회사를 가라.
다만 지역이 달라서 접근성이 떨어져서 그렇지 개발을 한국인이 못하는 것이 아니다.
비슷한 실력에 한국에서 잘하면 삼성이나 네이버 가는거고,
미국에서 비슷한 실력이면 구글, 페이스북 등 가는 것이다.
30대 초반이라면, 직접 실리콘밸리에 가서 일하는 걸 추천한다.
꾸준히 코딩 공부를 하자.
- leetCode에서 준비를 함 (700~800 문제가 있음)
- 미디엄 레벨로 20분 안에 풀 수 있으면 통과할 수 있음
- 200~300문제를 풀면, 패턴이 보이기 때문에 이 정도 문제를 푼다.
코딩에 장점이 있는건 스크립트 언어가 편하다.
하루에 한 문제씩이라도 공부할 것
아마존도 분기나 반기마다 한 번씩 한국에 와서 개발자들을 채용한다.
일하면서 비자 문제가 해결되면 실리콘 밸리 어느 회사든지 가서 일할 수 있다.
가장 중요한 것: 영어 공부하라.

미리 준비하자.
기회가 훨씬 더 많다.
너무 좁은 시장 안에서 가둬서 생각하지 마라.
시야를 넓혀라.

part2. 정도현

Learn and Be Curious와 Dive Deep

Learn and Be Curious

뭔가 궁금한 게 있을 때 궁금증을 가지고 최대한 밑바닥까지 파고 들어가자.

Dive Deep

호기심이야말로 개발자 힘의 원천이다.
특정 주제를 깊이 있게 읽는 게 필요하다.
어려운 책이라도 여러 번 반복해서 읽고 이해하려고 노력하라.
자꾸 쉽고 얇은 책을 찾는데, 시간과 노력, 끈기를 충분히 투자해서 파보자.

멋진 이력을 가지는 법

현재의 이력서와 미래의 이력서를 함께 유지하라.
1년에 최소 2번은 업데이트 하자.
미래에 내가 가지고 싶은 이력서를 만들자.
이 2가지 이력서를 어떻게 일치시킬 것인가를 고민해보고,
정기적으로 점검하자.

참고 링크:http://bit.ly/resume4developer
현재의 이력서에 도움이 되지 않는다면, 이직을 심각하게 고려해보자.
- 주니어 개발자일 때는 이직에 실패해도 그 데미지가 상대적으로 적다.
- 나중에는 당장 월급을 주는 곳으로 가게 된다.
- 주니어 때 이직을 적극적으로 해보자.
- 주니어 때 저축 꼭 하자.
  - 돈을 많이 모아두지 않으면, 나중에 돈 때문에 하기 싫은 일도 해야 하기 때문이다.

글쓰기와 개발자

좋은 개발자는 좋은 작가이다.

추천 도서
- 코딩호러가 들려주는 진짜 소프트웨어 개발 이야기
- 조엘 온 소프트웨어

코딩을 잘하기 위해서는 글쓰기를 열심히 하는 것도 도움이 된다.
내가 하는 일과 배운 것들에 대해 체계적으로 정리하는 능력을 기르면, 개발에서 어떤 일을 하든지 도움이 된다.

최고의 학습법

영어 공부

영어로 된 커뮤니티가서 말을 붙여보자.

이직의 적정 주기

1년 반이면 한 팀의 업무에 익숙해진다.
2 ~ 3년이면 이직을 하자.(평균 3년)
이직이 아니면, 회사 내에서 롤을 바꾸는 등의 사내에서 기회를 찾자.

sns보다 잘하는 개발자들 github이나 블로그를 follow를 하자.
기술적인 면에서 1년에 하나 정도 새로운 언어를 배우자.
- But, 그 중에 하나 정도는 깊게 이해하자.(자신만의 무기 만들기)
블로그를 가장 추천한다.
- 내가 오늘 뭘 배웠는지, 기술적으로 궁금한 것 등 학습 이력을 남기자!

성장을 바라는 프론트엔드 개발자를 위한 제언- 김민태

성장을 바라보는 두 가지 시선

1. 내가 생각하는 성장 VS 내가 상상하는 성장

내가 상상하는 성장과 생각하는 성장의 괴리를 좁히는 것이 중요하다.
나만의 호흡과 전략. 의미있는 훈련이 필요하다.
굉장히 긴 마라톤이다.
조급해하면 지는 것이다.

어떤 긴호흡?
- 목표, 실행, 피드백, 충전, 목표, 실행, 피드백, 충전, 목표…
가장 핵심적인 것
- 목표를 아주 작게 구체적으로 세우고, 실제로 실행하고, 실행한 것에 대해 반드시 피드백을 받아야 한다.
- 피드백을 받고 중간 목표를 다시 세우고…
- 마라톤이므로 중간에 멈추지 않고 달려가려면, 중간에 휴식이 있어야 한다.
개발자로 생활하면서 중간에 건강이 안좋아진다.
스스로 에너지가 바닥나서 번아웃이 오면 회복이 안될 수 있다.

2.타인이 바라보는 성장 VS 타인이 평가하는 성장

타인이 바라보는 것이 스펙

성장을 위한 결심만으론 부족하고 객관화를 위한 측정 지표를 만들자.
결심한 목표와 형태가 적절한가? - 달성 기준은 무엇인가? - 성장 목적은 무엇인가?
왜 그 기술을 선택했는지 등 Why에 대한 고민이 필요하다.

멘토에 대한 두 가지 생각

멘토가 필요한 이유 VS 멘토가 없어야 하는 이유

멘토링에서 효과적인 방법

1:1 멘토링이 효과가 가장 좋다.

Why?
- 코칭을 해주는 사람이 나에 대해 많이 알면 알수록 나의 문제점을 짚어줄 수 있다.

성장에 영향을 주는 환경

중요도 순서대로 나열해보자.
태도 > 동료> 회사> 멘토 > 기술

이 중에서도 태도를 배우는 게 가장 어렵다.

열정을 가지고 있어서 주위 사람들에게도 영감을 줄 수 있는가

상대적으로 가장 배우기 쉬운 건 기술이다.
배움을 가장 많이 주는 건 동료이다.
- 동료에게 배움을 받으려면 열린 마인드를 가지고 있어야 한다.

어떤 걸 배워야 할까?

나는 정말 어떤걸 배워야하는지 모르는가?
지름길은 없다. 하지만 시간은 없다.
조급해하지 마라!
시간은 우리의 편이다. 어차피 마라톤이다.
내 호흡에 맞는 시간 관리법을 만들자.
조언은 내것으로 만드는 게 중요하다.
성장 로드맵에 정답은 없다.

정리

성장은 환경에 적응하는 것이다.
환경은 시간이 흐르면 계속 바뀐다.
만들어야하는 소프트웨어, 요구사항, 해결해야 하는 문제가 바뀐다.
그러므로 성장해야만 한다.
끊임없이 나 자신에게 질문하자.
ex) 지금 핫한 기술도 내년에 망할 수 있다.
ex) 변한 환경에서 내가 눈치채지 못하고 있는 것은 무엇이지?

본인만의 싸이클을 찾자.

어떻게 성장할 것인가?
- 싸이클이 2주짜리, 한 달짜리 등등 본인에게 맞는 싸이클이 있다.

해봐야 안다!

혼자 성장할 수 있는 상태를 만들어야 한다.(자가 학습이 가능한 상태)
- 다음에 배울 것을 내가 스스로 정하고, 실행하고 객관적으로 평가, 피드백하고
  이걸 끊임없이 반복하면서 성장해나가는 과정
- 홀로서기할 수 있는 상태로 어떻게 만들 것인가.
개인 프로젝트를 반드시 하라.
- 주변 동료들이 불편해하는 걸 살펴봐서 그런걸 만든다.
- 동료들에게 제공해준다.

오픈소스 속에서 성장하기- 강대명

회사 업무를 통해 성장하자.

토이 프로젝트https://github.com/naver/arcus
Redishttps://github.com/antirez/redis
- 딱 주제와 상관없는 다른 것들은 굳이 고치지 말자.
- 남들이 올리는 이슈에서 간접적으로 겪을 수 있다.

오픈 소스 접근 방법

내가 많이 쓰는 오픈소스를 고르자.(결국 볼 수 밖에 없다.)
내가 충분히 익숙한 언어로 구현되었는가? (익숙한 언어가 아니면 공부해야함)
- Kafka: Scala(core)/Java
- Kubernates: Go
기반 지식을 충분히 이해하고 있는가?
- Linux는 운영체제, Spark는 분산처리에 대해 알아야 함
- 전체 모든 지식이 아니라 필요한 부분의 배경 지식이 필요하다.
  - ex)Timing Attack
커뮤니티는 활발한가?
- PR을 던졌을 때 리뷰를 받을 수 있어야 한다.
- 좋은 답변 얻을 수 있다.

오픈 소스 공부의 세속적인 장점

업무에 필요한 툴에 대한 이해도가 더 높아진다.
취업이나 이직시, 내가 이 부분을 공부하고 있다는 근거가 되어준다.
- 해당 기술을 구현하는 오픈소스에 공헌하고 있다.

오픈 소스 학습법

장애가 났을 때, 전체를 한 번에 보려고 하지 말고 그 부분만 보는 연습을 하자.

지식의 특징

배워서 남주면, 더 이해도가 높아진다.

데브그라운드 주니어를 다녀온 후 느낀 점

먼저 개발자의 길을 걷고 있는 분들의 다양한 경험담들을 들을 수 있어 즐거웠던 세미나였다.
주니어들이 가장 많은 고민을 하는 학습 방법이나 다각도의 방향에 대해 알 수 있었다.

DeveloperSeminar & Conference