마지막으로(?) 하고 싶은 이야기
- 마인드셋? 정신교육?
- 취준 → 어떤 마음가짐이 필요할까? + 어떤 인재가 되어야할까?
주니어 / 신입 개발자
- 아는게 많지 않은 상태인게 맞다.
- “신입의 허들이 높은 것 같다” → 정말 높은가? → 그런건 아닌 것 같다
- 지식을 너무 잘 접할 수 있기 때문이 아닌가
- 개발과 관련된 지식이 굉장히 많다.
- 왠지… 이것도 해야될 것 같고, 저것도 해야될 것 같고, …
- Vue, React, Typescript, css, scss, Test, ……
- 이것들을 다 알아야 할까? → 굳이? 몰라도 된다.
- 줌인터넷 다닐 때
- 신입 공채
- 팀 TO 1명
- 1명을 뽑을라고 했는데, 지원자가 300명.. 정도…?
- 팀에서 사용하는 기술 스택
- Java + Spring Boot
- MySQL
- JPA
- Hibernate
- QueryDSL
- Vue
- javascript
- node
- typescript
- …
- 최종 2명
- A → Java X, JPA X, Spring X, javascript, node (인턴을 할 때, 인턴을 하던 회사에 어떤 해결해야되는 문제가 있어서 그 때 익혀서 배운 것)
- B → Java + Spring + JPA + Vue + ….
- 본인(멘토)또한 B 스타일로 공부했었는데, 이 때 잘못되었다는 것을 알았던…
- 결국에 A를 뽑았다.
- 기본기가 튼튼하다.
- 기술 = 문제해결을 위한 도구
- 필요하면 그 때 익혀서 배우면 되지. 뭘 굳이 지금 다 전부 공부할 필요가 있을까?
- 자기가 아는 것들에 대해서는 굉장히 잘 답변 하는 스타일
- 자기가 해온 것들에 대해서는 모르는게 거의 없는
- 자기만의 가치관 / 철학 / 가능성을 보여줄 수 있는 수단도 필요하다.
- 스스로를 보면서 든 생각.
- 팀 내에서는 React + Next 를 이용하여 개발 중
- 본인(멘토)은 입사하기 전까지 실무에서 React를 써본적이 없었음.
- Vue에 대해서 꽤 상세하게 알고 있었고, 내부적으로 어떻게 돌아가는지도 알고 있었고, 거의 Vue를 거의 직접 만들다싶이 해보기도 했고.
- 단순하게 React를 잘 쓰는 사람보다는 괜찮을 것 같다? 라는 판단을 하지 않았을까…
- 기술을 왜 공부하는가
- 문제해결을 잘 하기 위해서
- 문제해결을 꼭 기술로 해야하는가? 그건 아니다.
- 기술외적인 방식으로 문제해결이 가능하다.
- 기술적인 문제를 잘 해결하기 위해선 다양한 지식을 알면 당연히 좋다.
- 기술을 모르는 상태여도, 어떤 기술을 사용하면 될지 접근할줄 안다면 괜찮다.
- CS는 꼭 필요할 수 있다 → 다양한 기술의 원천이 되기 때문.
- 자료구조
- 알고리즘 (에디터 / 빌더 같은거 만들 때에는 어느정도 쓰일 수 있음)
- 네트워크
- 브라우저
- 백엔드 개발자의 런타임 = 운영체제
- 프론트엔드 개발자의 런타임 = 브라우저
- 브라우저가 굉장히 많다.
- IE ( 크로미움 엣지… )
- 파이어폭스
- 사파리 → 새로운 IE 같은놈
- 구글 크롬
- 크로미움….
- ….
- 운영체제마다 브라우저가 다를 수 있다.
- 모바일환경 ( 삼성 브라우저 )
- 아이폰의 사파리
- 아이폰의 크롬
- 안드로이드의 크롬
- …
- 취업을 하고 나서는 어떻게 해야 좋을까?
- “성과” → 개발을 잘 한다고 성과를 만들어낼 수 있을까? → 아닌 것 같은데?
- 개발을 잘 해서, 이걸 잘 이용을 해서 회사에 어떤식으로든 득이 되게 하면 성과가 된다.
- CI/CD (자동화)
- 문화 (코드리뷰, 스크럼, …)
- 채용
- 인재 추천
- 팀 단위로 이직
- 줄줄이 소세지처럼 딸려오는 경우
- A를 데려왔더니, A가 B를 데려오고, B가 C를 데려오고, …
결론
- “얼만큼” 많이 공부했는가 보다, “어떻게” 공부 했는가가 중요하다.
- 양이 중요한게 아니라, 질이 중요하다.
- 하나를 하더라도 깊게 하면 좋다 ⇒ 끝까지 파고들어라! 라기보단, 적어도 내가 만들어놓은 것들에 대해서는 잘 설명할줄 알아야 한다.
- 왜 이렇게 했는지, 어떻게 동작하는지, 어떻게 개선할 수 있는지, 어디까지 고려했는지 등등
- “나의 가능성”을 보여줄 수 있는 활동을 하자.
- 기록 챌린지 → 나의 가치관과 철학을 보여주자.
- 나는 기술을 공부할 때 이런 관점(하나를 하더라도 제대로 하자)으로 공부하고 있어!
- “피드백”에 대해서 곰곰이 생각해보자.
- 나에게 어떤 피드백들이 도움이 되었는지.
- 내가 준 피드백이 상대방에게 어떤 도움이 되었는지.
- 나에게 불필요한 피드백은 뭔지 → 상대방에게 잘 알려주기.
- “도움이 되는 도움을 주자” “도움이 안 되는 도움은 굳이 받지 말자”
- 내가 한 이야기를 토대로 상대방에게 어떤 변화가 생겼는지 잘 관찰해보자.
- 문제 해결의 수단 (소프트스킬)
- 우리 팀이 어떻게 해야 효율적으로 일할 수 있을까?
- 우리 팀의 동기(일을 잘 하고 싶은 마음 이라던가)를 어떻게 해야 만들 수 있을까?
- 회고를 어떻게 해야 잘할 수 있을까?
- ….
- 팀 전체의 역량을 끌어올린다거나
- 꼭 팀이 아니더라도, 부사수 혹은 동료의 역량을 끌어올린다거나
- 나의 역량을 끌어올린다거나
- 결과적으로 이 모든게 팀 혹은 회사에 도움이 되는 일
- 결과적으로 성과가 되는 일
- 지금은 바운더리가 “나” 까지일 수 있지만, 프로그래머스 데브코스가 끝났을 때 “우리” 까지 넓힐 수 있으면 좋겠다.
- 기술은 혼자서 공부할 수 있지만, 기술 외적인건 혼자서 공부할 수 없다.
-끝-
이 침묵…
QnA
혜성님의 질문 - 기본기가 좋다는게 좋다는게 구체적으로 어떤 의미일까?
- 코딩을 잘 해야된다.
- 구현 하는 것에 익숙하다.
- “설계/클린코드 등에 너무 집중하면 구현 자체를 못하는 경우도 생긴다”
- 구현은 할줄 알아야 한다.
- 구현한 결과를 토대로 개선하는건 나중에 생각해도 된다.
- 코드 자체를 잘 이해하고 있어야 한다.
- ES5, ES6+
- 클라이언트 / 서버 등에 대한 개념을 명확하게 구분하고 있는지
- javascript → 브라우저(웹) API를 사용 (DOM, BOM, CSSOM, Web API)
- node → File System, I/O, … (OS 특화 작업)
- 브라우저 자체에 대해 얼만큼 이해하고 있는가
- 브라우저가 어떻게 렌더링을 하고 있는지
- 이걸 이해 해야 렌더링 최적화 라는걸 할 수 있는데
- React, Vue 등에서도 렌더링 최적화를 할 때 결국 브라우저를 기준으로 하게 된다.
- 반대로, Server Component 같은걸 이용할 때에는 서버의 특성을 이해해야 한다.
- 서버와 브라우저가 서로 렌더링 최적화를 하는 방법이 다를 수 있는데, 그냥 단순하게 프레임워크 쓴다고 렌더링 최적화가 된다고 생각하면 큰 오산
- CSS 들이 어떻게 쓰이는지를 아는 것보다, CSS 라는 시스템이 어떻게 만들어졌는지를 이해하는 것
- 블록킹 / 논블록킹 / 동기 / 비동기
- Canvas를 이용해서 렌더링 시스템을 만들 수 있는가?
- text parser
- DOM 구조로 구조화
- 데이터를 기반으로 좌표 계산
- Style Parser 같은걸 만들어서 CSSOM으로 구조화
- DOM + CSSOM 이용해서 canvas에 직접 렌더링
- 프레임워크 → 상위의 개념 (기본기 이상의 개념)
- 언어 → 기본기
- 런타임 ( OS, 브라우저 ) → 기본기
- 브라우저 vs OS → OS 훨씬 기본
- “문제해결” 자체에 대한 고민 → 기본기
- 기본기를 토대로 “구현” “실현” 하는 것
세진님 질문 → Vue, React, Typescript 등 이것저것 다 알아야할 것 같지만… 결국에는 문제를 해결하는게 제일 중요한 것 같은데 강의는 다 배우고 있는데 어떤 마인드로 보면 좋을까?
- 어떤 상황에 이 기술을 쓰는게 효과적일까?
- 무조건 도입하면 좋은가?
- 현재 상황에 맞는 기술 스택이 있는데, 이걸 내가 판단할 수 있는가?
- 내가 공부하는 것들이 나에게 주어진 문제를 해결할 때 적합한가 → 이걸 판단하기 위해선 결국 기술에 대해 어느정도는 알고 있어야 한다.
- 상태관리 라이브러리
- redux
- recoil
- jotai
- zustand
- mobx
- react-query
- swr
- …
- 뭘 기준으로 선택하고 판단해야 좋을까?
- 같이 써도 좋은게 있지 않을까?
- 그럼 이 라이브러리들은 어떤 문제를 해결하기 위해서 나왔을까?
- typescript는 어떤 문제를 해결하기위해 나왔을까?
- react는 어떤 문제를 해결하기 위해 나왔을까?
- 그렇다면 react랑 똑같은 고민을 토대로 나온 라이브러리들은 없을까?
- react를 쓰는 모습이 굉장히 부자연스럽다.
- 그렇다면 어떤 방법이 있을까?
- 그 방법이 효과적인가?
결국 판단을 하기 위해선, 기술에 대해 어느정도는 잘 알고 있어야 한다.
설득할 때 필요하다. 내가 기술에대해서 잘 아는게. 잘 이해하는게. 경험한게.
CS 지식을 어떻게 공부했는가?
- 학교 수업에서 배운 것들 위주로 복습
- 복습할 수 있는 책을 사서 공부
- 의도적으로 CS 공부해야지! 라고 했던적은 사실 많이 없었음…
- 네트워크 정도만 따로 책을 사서 본다거나
- 내가 만든 서비스를 배포했을 때
- 이거랑 연관된 CS지식은 뭐가 있을까?
- 클라우드에 배포했다면
- CPU를 내가 만든(혹은 배포한) 어플리케이션이 어떻게 쓰고 있는지
- 메모리의 사용량을 판단한다거나
- 메모리 누수가 언제 발생하는지
- 메모리 누수가 왜 발생하는지
- CPU와 메모리
- 프로세스와 스레드
- 휘발성 데이터와 비 휘발성 데이터
- …
- 브라우저에서 프로세스를 어떻게 사용하는지
- 크롬은 대체 왜 메모리를 이렇게 미친듯이 많이쓸까?
- 브라우저와 연관된 CS는 뭐가 있을까?
- 프론트엔드 개발자 ⇒ 네트워크는 무조건 필수
- http
- 브라우저(클라이언트)가 서버와 어떻게 통신을 하고 있는지 (최소한의 지식. 네트워크)
아무말 대잔치 (하고 싶은 이야기)
- 슬프네요… ㅠㅠ 🥲🥲
- 더울 때 → 넥쿨러
- 아이스크림
- 팥빙수
- 수박
- 냉면
- 콩국수
- …
- 여름에 포도?
