42경산 제 4차 명사 초청 특강
- 일시: 2024.08.29.(목) 10:00 ~11:30
- 장소: (재)경산이노베이션아카데미 1층 유니버스룸
- 주제
1부: 42학습방법, 개발자의 성장 등(약 20분)
2부: 커리어멘토링(부트캠프가 전부가 아냐) (약40분) - 강연방식: 관련 현업 종사자 6명의 패널 토의 형식으로 진행
- 강연자
1) 이민석: (현)국민대학교 교수, (전) 42서울 초대 학장
2) 오종안: (전)42서울 상근 멘토
3) 박은종: (현) 커널 360 리드 멘토, (전)42서울 상근 멘토
4) 박희민: (현)상명대학교 컴퓨터학부 교수
5) 이일민: 토비의 스프링 저자
6) 유저스틴: (현) 마이크로소프트 DevAdvocate
강연 내용 정리본
처음은 이민석교수님의 강연으로 시작했다. 교수님이라고 하셔서 단순하게 학술적인 얘기만 해주실 줄 알았는데,
이 분야의 취업에 대한 핵심적인 틀과 포인트를 확실하게 말씀해주셔서 큰 도움이 된 것 같다.
아래는 교수님의 말씀과 Q&A 등을 정리한 것을 바탕으로 간단하게 기록해봤다!
휴대폰으로 타이핑해가면서 기록했는데 빠진 부분도 많다. 노트북을 들고 왔어야해..
일반적으로 Framework 공부에 시간 많이 쓰지만,
신입으로 들어가려면 알고리즘은 코딩 테스트 때문에 꼭 필요하다고 하셨다.
하지만, 정말 많은 고민을 통해서 알고리즘 공부 하지말고, 답을 보면서 패턴을 많이 공부하는게 중요!
이 뜻은 코드 답을 본다 (X) / 어떤 그림, 방식 등이 있는지 본다 (O) 이므로 코드만 보고 치우지는 말자..
(데이터를 그림으로 그리고 어떤 플로우가 있는지.. 등)
CS Core 지식 질문들이 프로페셔널하게 소통이 가능한지 파악하는 커트라인의 큰 기점이 되는 부분이다.
CS 지식들을 쌓은 뒤, 그 이후 영역부터는 데이터가 쌓여서 경험이 된다고 하셨다.
나도 CS를 그냥 공부만 하는 게 아니라 추후에 면접때 답변할 수 있을 만큼 정리하고 따로
CS Q&A를 정리할 생각이 있었는데 꼭 해야할 것 같다!
이 분야가 안맞다고 생각하면 빨리 포기하는게 나을 수도 있다고 하셨다.. (나는 잘맞는 것도 같은데.. 모르겠다)
언덕을 올라가고 다음 언덕을 바라볼 때가 재미 포인트!
사진으로 역량 성장과정을 보니 아직까지는 굉장히 낮은 지점에서 언덕을 오르락내리락 하고있는 것 같다.
정답이 없는 문제들이 많다. 평소에 답을 구하는 것이 아니라 이 문제가 뭔지에 대해서 생각하는 것이 더 중요하다.
문제 해결에 의미가 없고 과정이 중요! 과제를 풀었다는 그 사실보다는 뭘 배웠는지에 대해서 더 생각해보자!
PBL (Project based learning)
회사가 관심있는 건 어떤 걸 만들었냐가 아니라 그 프로젝트를 통해 뭘 배웠는가 이다!
토론과 해결과 평가를 통해 배워야할 것을 잘 습득했는지 파악할 필요가 있다.
그를 위해서 42 시스템에서는 동료학습과 동료평가가 있는 것!
동료학습은 가르치면서 배우는 것 (Learning by teaching), 오류가 난 코드를 통해 같이 배우는 것이다.
그냥 누군가에게 배운다는 것만 배우는 것이 아니라, 누군가에게 가르치려고하는 그 과정도 나에게 배움이다.
성장의 재정의 - 새로운 것을 배워나가는게 아니고, 새 제품을 만들수 있는, 제품화 하는 역량을 습득해 나가는 것이다.
우리가 한 언어만 배우는 게 중요한 게 아니라, 그 언어를 통해 프로그래밍의 역량을 쌓아 새 언어가 주류가 되어도
새 제품을 만들 수 있는 그런 역량 습득이 중요한 것이라고 하셨다!
좋은 성과나 보람이 재미라고 정의 되어있는데, 이 재미의 단위를 쪼개는 것이 중요하다!
따라서 일을 조금씩 짤라서 결과를 확인하는 것이 중요하다고 하셨다. 목표를 잘게 쪼개서 점진적으로!
나도 과제 하나만을 성과의 기준으로 잡지말고, 과제 안에서 어떤 함수 하나하나를 성과나 목표로 보고
그렇게 점진적으로 풀어나가는 것도 좋을 것 같다.
위 사진은 잘 성장하고 있는 개발자인지 확인하는 자가진단표이다.
해당되는 부분도 많지만, 더 필요할 내용도 정말 많은 것 같다..
깃허브 리포지토리에 협업의 흔적 많이 남기라고 하셨다. 단순히 공부한 것만 기록하면 깃허브를 활용한 큰 의미가 없다.
그리고 코딩에 얼마나 주에 시간을 쓰는지 파악해보며 내 역량을 잘 파악해보라고 하셨다! (약.. 25시간..? 잘모르겠다.)
협업과 네트워크에 대해서도 언급해주셨는데,
이직이 잦은 it업계에서 어떤 직원이 나갔을때 메꿀수있는게 협업이라고 하셨다. (즉 서로 뭘 하는지 알고있는 관계)
그래서 이 협업이 가능한 사이라는 것은 '대타가능한 이해와 역량 관점의 평가가 가능한 사이'로 정의하셨다.
서로의 커리어에 네트워크로 동작할 수 있는 사이가 되는 것이다. 쟤가 뭘 잘하는지를 알아야 하는 사이!
(이후 부터는 Q&A 내용인데, 답변에서 도움되는 부분이 많았다.)
Q1) 깊이있게 공부하는 것이 더 중요? 폭넓게 다양하게 공부하는 것이 더 중요?
A 1-1)
다양하게 하는건 언제든지 할 수 있지만 프로젝트 할때 깊이있게 제대로 공부하는게 좋다.
어떻게 돌아가는지를 알아야 추후에 나오는 프레임워크나 언어를 이해할 수 있을 것이다.
어떤 프레임워크를 잘아는것보다 그 프레임워크가 아니더라도 이해하고 개발할 수 있는게 중요.
프레임워크를 만들어보는 과정을 커널360에서 진행중이라고 하셨는데 이미 스프링 프레임워크를
해봤고 내부과정을 이해하고 있기 때문에 프레임워크에 대한 이해도로 제작 가능.
A 1-2)
무엇을 위해서 서비스를 만들고 존재하는지를 파악. 기업입장에서는 기술적완성도보다 돌아가는게 더 중요하다.
이 어플의 소비자는 누구인가 그런 관점. 결국 잘 돌아가는지가 제일 중요하다!
잘 돌아가면 그 이후에 성장하면서 코드를 다듬는다. (리팩토링..)
서비스를 딜리버리하는 관점에서는 깊이보다는 더 빠르게 이 코드를 완성시켜 잘돌아가게 하는것이 중요할 수도 있다.
A 1-3)
중요한건 회사에 들어가는 게 먼저이다.
그렇다면, 회사에 더 들어가기 좋은 방법은?
-> 내가 할줄아는 능력을 보여야함. 그러려면 이력서 통과를 해야함.
제목을 재미있게 써야한다 -> 주제가 정말 많이 겹친다. (단순하게 ~~~개발. 이런건 그냥 노룩패스가 됨.)
깊이 있게 공부한 티를 제대로 내야한다. -> 실사용자에게 ~~개발. 특정 기술을 언급.
면접에 불러다가 질문해보고 싶을 만한 이력서. 제목을 제대로 자기 PR하기.
한눈에 뭘 했는지 알수있게 적고, 제대로 어떤 수치가 있어야함 숫자!!
(앱을 10개 개발했다. 논문을 10개를 썼다. 데이터 양이 100만개였다. 이런식으로.)
깊이 있게 했으면 사용한 기술을 나열하기. 어쨌든 기술면접 담당자를 만나는게 중요.
이게 뭐지 신기하네?가 나오는 제목이나 주제.Q2) 현직에서 모르는 게 생길 때 동료학습이 잘 이뤄지는지? 어떤 마음가짐으로 배워야 잘 배울 수 있는지?
A 2-1)
질문도 억지로하고 답변도 억지로 하고 그렇게 해나가야만 배우는 과정이 된다.
성과가 생기다보면 덜 억지가 된다. 회사에서도 마찬가지로 억지로 배워야함.
모르는 걸 가지고 협업을 하기때문에.
A 2-2)
(협업과 도구의 상관관계에 있어서 답변)
협업은 도구가 아니다. 협업을 할줄 아는 상태에서 도구를 써야 하지, 협업을 못하면 도구가 독이 된다.
개발 프로세스와 문화를 도구로 했으나, 사실은 도구는 도구일뿐이다.
협업은 태도의 문제. 코드를 공격하는거지 사람을 공격하는게 아니다!
다른방법을 제시했을때 같이 해보는게 협업.
이슈 트래커를 범위 좁히지x, 사용에 제약을 두지말고 여러 방법으로 이용
A 2-3)
단체교육은 누구에게도 맞출수 없다. (잘하는사람 기준? 못하는사람 기준?)
내가 소극적인데 적극적으로 바꾸기? 절대 어렵다. 연기하라. 소극적이라도 적극적으로 연기하라.Q3) 42경산이 low level로 배우는데, 문제 해결력에는 도움이 되지만 어떻게 정리해야할지?
지금 배우는 게 low level인데 다른 과정을 준비할 때 어떤 부분에서 생각을 가지고 준비해야할지?
A 3-1)
해커톤을 가보면 js 쓰는데, 굉장히 빨리 배운다는 것을 알것이다.
그만큼 c로 공부해보면 다른 언어에 대해서도 쌓인다.
이론을 잘 아는것을 어떻게 어필하는가. 면접에서 1분만에 다 털린다. 자연스럽게 드러난다!
(ex. 미니쉘 -> ipc에 대해 설명해보세요. 등)
그 많은 이론들을 하나하나 다 코드와 이론을 맵핑할 수 있는가? 그게 로우레벨 공부가 잘 되있는 것이다.
A 3-2)
뽑는 사람은 뭘 배웠는지 알텐데, 그걸 확인했을때 실제 아는 지 증명해야함.
(프로세스와 쓰레드의 차이같은 질문.) -> 답변 못하면 관심이 없는 것에 대한 결과!
따라서 결과적으로 프로그래밍에 덕질을 해야함.
뽑는 사람 입장에서는 언어를 다 아는게 맞다.
프론트엔드 로그인 + 백엔드 게시판 -> 만들었지만 코테하면 다 떨어짐.
99퍼센트가 라이브로 못만든다. 포트폴리오에 써놔봤자 못한다.
포트폴리오의 프로젝트는 무조건 본다. (외형 안봄)
화면 캡쳐해서 올리면 의미가 없다. 받는 사람의 입장을 이해하라.
프로젝트에서 어떤 경험을 했는데?가 중요함. 이문제를 이렇게 해결했어요. 이런게 필요함.
어떤 걸 안쓰는 추세면 왜 안쓰는지 알아야하고, 어떤 언어를 많이쓴다면 왜 쓰는지도 알아야함.
A 3-3)
42하면서 사이드프로젝트를 안해서 자바 관련 회사를 못들어갈거라 생각해서 안갔다는 사람이 있는데,
못들어갈 건 아닌거 같다. 원하는 포지션이 타겟팅 되어있다면 여기서 배우는건 쓸데없는 게 아니다.
포트폴리오-> 회사에서 열심히 안본다!! 부트캠프에서 한 포트폴리오를 쓰면
거의 CTO들한테 물어보면 아예 안본다고도 함. (면접간 친구들은 포트폴리오 관심없던데요 라고함.)
게시판을 만들었다 -> DB설계를 어케했니? = 결국 이론를 물어본다 뭘배웠는가에 대한 질문.
뭐를 만들었는지 보다 뭐를 아는지 뭘 배웠는지.
이 문제에서 공부해야하는 기본지식을 배워라. 라는 목표로 42를 진행해야함!
그런식으로 공부한다면 그런 이론적 백그라운드를 갖추게 된다. 그런 사람들을 뽑을 것이다.
(포트폴리오가 실제로 메리트가 없을 수 있지만, 무조건 있긴 해야한다...)
A 3-4)
취업할 수 있는 회사의 종류나 분야는 아주 다양하다.
오로지 코딩테스트만 하는 구글코리아도 있음.
같이 일하기 좋아보이는 사람을 뽑는것도 있다.
얘기가 잘 통하고 문제푸는 방식이나 이런게 잘맞나.
전략적으로 어떤 회사의 어떤 직군을 갈지 해당 채용에 집중해서 지원 전략을 짜고 간다.
서로 호감이 가는지 같이 일할수있는지 파악함.
내가 취업하고자 하는 분야에서의 뽑는 방식을 타겟팅 하기 ! 코테면 코테에 집중하고, 등등..
A 3-5)
선배의 말 (우테코 싸피 가라 등등) 테크트리나 커리어패스에 대한 조언으로 들릴 수 밖에 없다.
사회생활은 정답이 없다. 옛날거라도 안고치는 건 잘돌아가기 때문일 수 있다.
최선의 선택은 할 수 있다. 정답은 없고 논리를 잘 만들어야 한다.
스토리를 쌓아가며 결정을 하게된 근간을 만든다. 그런얘기를 하다보면 그동안 자기가 쌓아온 경험과
지식들을 녹여서 얘기할 수 있을것이다.
A 3-6)
까다롭게 뽑는 회사가 더 좋은 회사다라는 의견.
세상에 회사는 진짜 많은데, 특정 회사를 목표로 하지말고 서류를 굉장히 많이 내라! (100~200장)
질문 많이해라!! 면접에서 질문 있으신가요?물으면 질문 꼭해야함!!!
면접을 많이 보다보면 회사를 보는 눈이 생긴다.
회사를 알아보는 과정이 이력서를 많이 내는것이다!!
이력서를 몇장내야 취업하나 -> 평균 130장냄. / 이직을 할때 250장을 냈다고함.
이 회사가 어떤 회사인지 파악해서 내보면, 그중에 해봤자 5개정도 면접본다.
공부도 중요하지만 회사를 알아보는것도 중요.
모든 제조업계열에서 소프트웨어 개발자를 뽑고있음.
저 회사가 내가 마음에 든다면 그때부턴 내가 갑이다. 두려워하지말고 회사를 많이 알아보도록.
Q4) 상황에 휩쓸리지 않고 자신의 페이스를 지키는 방법?
A 4-1)
상황이 안좋아지면 삶을 관찰모드로 바꿨다.
세상은 나를 중심으로 돌아간다. 절대 망하지 않는다 걱정마라.
A 4-2)
남이랑 비교하고 과거를 파헤칠 필요가 없다.
남들이 만든 한계는 깨기 쉽다. 하지만 자기가 만든 한계는 정말 깨기어렵다.
이미 시도를 할수없는 상태다. 근자감으로 밀어붙여라.