※ 부제 : 엘리베이터 옆 “배너” 이야기
멘토링을 합니다.
비슷한 질문이 반복됩니다.
멘토들이 모여 고민합니다.
한 번 정리해야 할 것 같아서, 정리해 봅니다.
주요 질문들
- 프론트엔드 개발자가 되고 싶은데 뭐부터 해야 할까요?
- 제가 맞게 공부하고 있는 걸까요?
- 어디까지 공부해야 할지 모르겠어요.
음. 왜 이런 질문들이 반복될까?
학생 개인의 문제는 아니라고 봅니다.
학교와 산업이 단절되어 있는 거죠.
개발자가 되는 데 특별한 요령이 있는 건 아닙니다.
지름길이 있는 것도 아니구요.
알면 쉬운데, 모르면 어려운 것들입니다.
깨우치는 건 요령만 알면 금방인데,
실력은 시간을 꾸준히 투자해야 늘어납니다.
프로그래밍은 지식배틀이 아닙니다.
경험과 훈련이 가져다주는 결과죠.
이 질문에 대한 답은 여러 번 했습니다.
지난 이야기들
(1) 42, 어떻게 공부해야 하나
(발행글) 발행한 지 한 달.
누적 조회수가 800회 정도 됩니다.
여기에 지원해야할까 말아야 할까.
지원자들이 꾸준히 읽고 있습니다.
(2) 42과정에 대해 솔직하게 물어보았습니다.
(발행글) 발행한 지 9개월.
누적 조회수가 3,500회 정도 됩니다.
매월 꾸준히 400회 이상 조회됩니다.
역시 지원자들이 꾸준히 보고 있습니다.
기업의 채용담당자들도 봅니다.
연락은 꾸준히 오고 있습니다.
(3) (기업설문) 어떤 개발자를 구하시나요?
(발행글) 발행한 지 한 달이 안되었고,
조회수가 7,000 회에 달합니다.
OKKY 등 개발자 커뮤니티에 글이 실리면서,
일파만파 퍼져나가고 있습니다. 아직도 …
42 학생들 뿐 아니라 일반 기업들도 봅니다.
일반 대학의 학생들도 봅니다.
이 글을 보고 (4) 번도 함께 읽습니다.
(4) 42졸업생들은 어떤가요?
(발행글) 발행한 지 한 달이 되었고,
조회수가 900회에 달합니다.
“개발자 인플루언서”들에게 전파했습니다.
많은 기업의 채용관련자들이 이 글을 읽었습니다.
아직도 읽히고 있고, 앞으로도 읽힐 겁니다.
간혹 전화가 옵니다.
“42 출신이라고 해서 면접을 봤는데말야 … “
평가는 냉정합니다.
프리라이딩은 불가능합니다.
문제는 취업하고 난 다음입니다.
시장의 기준은 변하지 않는다.
42 과정을 하든 SSAFY를 하든,
소마를 하든 네이버부스트캠프를 하든,
시장이 보는 시각은 변하지 않습니다.
CTO의 개인 취향이 아니라,
사업의 “생존방식”을 따르기 때문입니다.
거의 정해져 있습니다.
미디어 내용과 많이 다릅니다.
기업별로 채용기준이 조금씩 다르지만,
크게 보면 대동소이 합니다.
회사란 여러 명이 움직이는 조직입니다.
중요한 기술은 비싼 인력을 사오고,
필요한 기술은, 내부인력을 전환배치합니다.
절대로 신입사원을 불러 핵심기술을 맡기지 않습니다.
회사는 사회문제를 푸는 제품을 만들고
그걸 팔아 월급과 수익을 만듭니다.
채용이 된다는 건
그 회사의, 그 시점에 필요한 사람이라는 뜻입니다.
42 라고 해서 더 예쁘게 봐주고,
다른 과정이라고 안 예쁘게 보는
그런 일은 채용 현장에서 일어나지 않습니다.
42 문제를 풀면 취업이 되는 게 아니라,
수단과 방법을 가리지 말고,
나 자신을 그 수준에 이르게 해야 합니다.
뭐부터 공부해야 할까?
“개발자 로드맵”
개발자들이 일하면서 알게 된(필요한) 지식들을 로드맵 형식으로 배치한 겁니다.
프로젝트 할 때 어떤 걸 찾아봐야 하는지 참고할 수 있습니다.
- 프론트엔드 개발자 : https://roadmap.sh/frontend
- 백엔드 개발자 : https://roadmap.sh/backend
- DevOps 엔지니어 : https://roadmap.sh/devops
- 안드로이드 개발자 : https://roadmap.sh/android
- DBA (PostgreSQL) : https://roadmap.sh/postgresql-dba
- React 개발자 : https://roadmap.sh/react
- iOS 개발자 : https://github.com/godrm/mobile-developer-roadmap
“배너”로 만들어서, 엘레베이터 앞에 두었습니다.
“Developer Roadmap“, “Developer Skill Tree“
구글 검색을 하면 주루룩 나옵니다.
조금 다른 산업 분야도 있지만, 꽤 범용적인 로드맵입니다.
그런데 이걸 순서대로 공부했다고 개발자가 되는게 아닙니다.
개발자는 “알고 있는 사람”이 아니고,
“할 수 있는 사람” 입니다.
이거 앞에서부터 공부하면 하나도 이해 안됩니다.
시간도 오래 걸려서 해도해도 끝이 안 보입니다.
사례를 풀면서 하나씩 찾아보는 겁니다.
(1) 다 할 줄 알아야 하나요?
- 5년차 정도 되었을 땐 대부분 경험했거나 할 줄 알아야 합니다.
- 필요하면 찾아보고 활용할 수 있어야 합니다.
- 신입사원 때는 저렇게 성장할 수 있나를 눈여겨 봅니다.
(2) 으익, 저걸 언제 다하나요?
- 대학교 시험치는 게임이 아닙니다.
- 1단원부터 차근차근 진리 찾듯 공부하면 안됩니다.
- 필요할 때 습득하고, 이해하며 활용할 수 있으면 됩니다.
- 빠른 학습능력, 끈질긴 근성(Rigor), 논리적 사고능력 등이 필요합니다.
- 개발자가 되려면 지식을 완성시키는 게 아니라, 제품(or 기능)을 완성시켜야 합니다.
- 기초지식은 중요합니다. 하지만 그것도 변합니다.
(3) 그런 걸 어떻게 익히나요?
- 소프트웨어 개발은 기술, 기술은 “훈련”입니다.
- 근성은 “훈련”을 통해 길러집니다.
- 논리적 사고력도 “훈련”을 통해 기릅니다.
- 천재는 훈련을 안 해도 됩니다.
- 우리는 천재가 아니니까 열심히 하기로 합니다.
- 훈련은 모의 상황을 통해 합니다.
- 자신을 그런 곳에 많이 던져 놓아야 실력이 늘어납니다.
(4) 저걸 모르면 취업을 못하나요?
- 신입사원에게 기대하는 기술 세트가 있습니다.
- “취업형 기술”이라고 부르며, 외워서 따라하면 채용해주기도 합니다.
- 하지만, 오래 하려면 제대로 이해하고 응용할 수 있어야 합니다.
- 진지한 회사는 제대로 이해하는지 묻고,
- 덜 진지한 회사는 할 줄만 알면 뽑습니다.
- 가능하면 진지한 회사에 취업하면 좋겠습니다.
(5) 프로젝트를 꼭 해야 하나요?
- 개발자는 (1) 결과물(제품) (2) 재개발 능력, (3) 응용 능력으로 평가 받습니다.
- 프로젝트는 그걸 종합적으로 확인하고, 물어보기 가장 좋은 예제입니다.
- 실전에 가까울수록 좋고,
- 큰 실전이 아니라, 작은 실전이 질문하기 좋습니다.
(6) 42 과정에도 저게 있나요?
- 42 과제도 “프로젝트”입니다.
- 현업 문제들을 교육용으로 가공한 겁니다.
- 42 과제(2년차 포함)만 충실히 한다면, 채용하겠다는 기업들이 90% 나 됩니다.
- 과제를 통해 익혀야 할 것은 “현업처럼 일하는 방법”입니다.
- 현업처럼 일한다는 건 주어진 기한 안에 주어진 결과물을 만드는 것입니다.
- 내 몸에 익혀야 하는 건, 그걸 다시 만들고 응용할 수 있는 능력입니다.
- 그러려면 지식과 경험을 빠르게 흡수해야 합니다.
- “이론”도 중요하지만, 그것에만 집중하면 안됩니다.
(7) 저 기술들은 어떻게 익히나요?
- 저런 기술이 들어 있는 프로젝트를 해보는 겁니다.
- 그게 가장 빠릅니다.
- 가벼운 프로젝트는 github 에 많습니다.
- OS 레벨의 프로젝트는 별로 없습니다.
- 그건 42 Seoul 에 있습니다.
- 백엔드 개발자라면 OS 건드릴 일이 많습니다.
- 가능하면 42 Seoul 과정을 잘해 둡니다.
- 과제를 통과하는게 중요한 게 아니라, 다시 할 수 있게 되는 게 중요한 겁니다.
(8) 프로젝트는 어떻게 해야 잘하나요?
- 산업별, 회사별로 케바케입니다.
- 하지만, 반복되는 틀은 있습니다.
- 프로젝트를 시작하기 전 팀을 만듭니다.
- 솔로과제라도 팀을 만듭니다.
- 팀원들과 무얼 만들지 토론합니다.
- 어떻게 만들어야 할지 토론합니다.
- 무엇을 익혀야 할지 토론합니다.
- 어떻게 마무리해야 할지 토론합니다.
- 소통, 커뮤니케이션, 질문, 확인, 회고.
- 수학문제 풀듯이 집에서 혼자 하면 안됩니다.
- 잘하는 팀을 보며 요령을 배우거나, 직접 해보면서 방법을 익힙니다.
- 42 는 프로젝트 연습하기 좋은 과제들입니다.
(9) 너무 몰라서 힘들어요.
- 모르는 걸 가장 빨리 아는 방법은, 아는 사람에게 물어보는 겁니다.
- “정보의 습득은 폭넓고 빠르게 !!!”
- “내 걸로 만드는 과정은 스스로 끈질기게 !!!”
- 물어보고 아는 것이 가장 빠릅니다.
제대로 답해줄 사람 찾기, 잘 물어보기 스킬이 필요합니다. - 검색해 보는 것은, 넓고 다양합니다.
다만 제대로 된 정보 찾기가 어렵습니다.
그게 그건지 모를 수도 있습니다.
시간이 많이 들어갑니다. - 고민하고 깨닫는 건 ….
지식습득 방법이 아닙니다.
이렇게 정보를 습득하진 마세요.
도태됩니다.
개발자가 된다는 건,
개발자는 “자격증”을 얻으면 인정받는 사람이 아닙니다.
아무리 잘난 자격증도, 만들 수 없으면 인정받지 못합니다.
개발자가 된다는 건 내가 무엇을 만들 수 있도록 키워가는 게임입니다.
나에게 “좋은 경험”을 쌓게 해주고,
나에게 “좋은 지식”을 쌓게 해주고,
나에게 “좋은 동료”를 만들어 줍니다.
그래서,
무언가를 만들 수 있게 됩니다.
그걸 고객으로부터 인정받습니다.
여러 사람과 힘을 합쳐 더 크고 복잡한 걸 만들 수 있게 됩니다.
나를 이렇게 만들어가는 게임입니다.
개발자는 대부분 이렇게 훈련되어 있습니다.
42의 목표는 취업이 아닙니다.
개발자가 되는 겁니다.
취업은 “목표”가 아니라 “결과”입니다.
개발자가 되지 못했다면,
취업을 했더라도 버티지 못합니다.
회사가 인정하지 않기 때문입니다.
오늘을 넘길 수 있어도, 내일을 넘길 수는 없습니다.
평가는 멘토나 재단이 하지 않습니다.
평가는 회사가 합니다.
평가는 사회가 합니다.
평가는 고객이 합니다.
무언가를 만들 수 있다면 !!!
그게 누군가에게 도움이 된다면 !!!
나를 찾는 사람은 언제나 있습니다.
그래서 아쉬운 게 없습니다.
시장이 개발자를 찾는 이유는
뭔가 만들 사람이 필요하기 때문입니다.
어떤 결과물을 만들어야 하기 때문입니다.
나 자신을 개발자로 만들기 위해
여기 있는 시간을 쓰면 좋겠습니다.
요약
- 시장의 기준은 변하지 않는다.
그게 개발자 로드맵이다. - 다 알지 못해도 취업은 할 수 있다.
하지만, 결국은 저런 걸 하게 된다. - 42가 시장에 맞추는 거지, 시장이 42에 맞추지 않는다.
42가 실력이 없다면, 시장은 받아주지 않는다. - 과제는 시험이 아니다. 그냥 통과해선 아무것도 변하지 않는다.
과제는 실력을 쌓기 위한 재료다. 과제를 이용해 실력을 쌓아라. - 뭔가를 만들 수 있게 되는 게 실력이다.
목표는 외우는 것이 아니라, 할 수 있게 되는 것이다. - 개발자의 실력은, 프로그램으로 고객(유저)의 문제를 해결해주는 거다.
문제를 해결할 수 없다면 실력이 없는 거다.
그래서 문제 도출 능력, 소통 능력도 실력에 포함된다. - 협업이 필요한 건 더 크고 복잡한 걸 만들기 위해서다.
실력은 협업 과정까지 포함한다. 협업은 맨날 반복되는 일상이다.
협업 할 줄 아는 사람과 모르는 사람은 1년 만에 확연히 달라진다. - 개발자는 실력으로 평가 받는다.
실력은 돈을 내는 사람이 평가한다.
회사, 고객의 평가는 냉정하다. - 가장 먼저 동료로부터 실력을 인정받아라.
동료가 인정한다고 시장이 인정하는 건 아니지만,
동료가 인정하지 않는데, 시장이 인정할 리 없다. - 가장 빨리 성장하는 방법은, 잘 하는 사람을 따라하는 거다.
잘하는 사람에게 배우고, 못하는 사람에 가르쳐줘라. - 아쉬울 때 전화할 수 있는 동료 10명이 내 인생을 책임진다.
끝.