1. 스크럼 규칙을 정해보자.
- 데일리스크럼? →
이 관리
- 멘토가 생각하는 제일 중요한 가치
- 지속성장
- 학습하는 환경을 직접 만들어보는 것
- 나는 어떤 상황에서 몰입을 하는지
- 나는 무엇을 공부할 때 재미를 느끼는지
- 그래서 내가 성장하게 하는 트리거가 뭔지
- 나는 잘 성장하고 있는지
- 메타인지
- 함께 자라기
- 지속성장하는 과정을 같이 해보자.
- 공부는 혼자서 가능하다. 학습도 혼자할 수 있다.
- 일은 팀 단위로 하게 되고, 상호 피드백이 많이 필요하고, 성과 측정,
- 코드리뷰, 클린코드, 리액트, …
- 함께 일하는 방법에 대해서 깨우치는 과정
- 피드백이 중요함 → 피드백의 수단으로 데일리스크럼을 해보자 → 지속성장할 수 있는 환경, 트리거 같은 것들을 찾고 → 함께 성장하자
- 데일리스크럼은 피드백을 위한 수단
- 다른사람이 하는 어떤 활동들을 보고 나도 한 번 점검해보고, 다른 사람이 하는 일들도 점검해보고
- 피드백을 서로 주고 받고
- 결국에 같이 성장할 수 있게
2. 학습 목표를 정해보자.
- 피드백이 중요함 → 피드백의 수단으로 데일리스크럼을 해보자 → 지속성장할 수 있는 환경, 트리거 같은 것들을 찾고 → 함께 성장하자
- 개발자에 대해서 정의해보기 + 프론트엔드 개발자가 하는 일들에 대해서 조사하고 찾아보기
- javascript 자체에 대한 학습
- css, html
- vue, react
- api + network
- 왜 우리가 하필이면 javascript 라는걸 배워야 하는거지? Why?
- 우리가 공부하는 것들, 학습하는 것들이 어떤 가치가 있는지.
- 취준을 위해서 이 과정들을 겪고 있는데, 그렇다면 회사에서 javascript, frontend 라는 기술, 역할 등이 어떤 가치를 가져오고 있는지 → 어떻게 돈이 되는건데?
- 그래서 우리는 회사에 입사를 하게 되면, 정확히 어떤 일들을 하게 되는건지.
- 내가 하는 일을, 내가 공부하는 목적을, 명확하게 설명할 수 있어야 한다.
- 처음부터 react나 vue 같은 프레임워크를 배우는게 아니라, 왜 바닐라 자바스크립트를 먼저 딥하게 공부해야 하는걸까?
- 프레임워크가 굉장히 많은데, 왜 그 중에서 react를 배워야하는가.
- 프레임워크와 라이브러리의 차이점은 뭘까.
- 알고리즘은 왜 공부하는거지?
- 회사에서 얼마나 잘 쓰이는걸까?
- 자바스크립트가 언제까지 살아남을 수 있을까? 웹 어셈블리도 나오는데, 다른 언어로도 브라우저 환경에서 개발 가능한데 왜 자바스크립트를 써야만 하는 이유가 뭘까? 결국에는 사라지게 될까?
- 자기 생각을 이야기 하는 연습.
- 어떤 공부를 해야할 때, 그 공부를 해야하는 이유를 논리적으로 정리해보자.
- 프론트엔드는 기술이 왜이렇게 빨리 변할까 고민해보기.
- 백엔드와 프론트엔드를 나눠서 수업하는 이유에 대해 탐구해보기.
- 한국전자정부프레임워크는 자바인데, 이게 바뀔 수 있을까?(SI 업체 기준)
3. 무엇이든 질의응답, QnA
- Q. 취직할 때 어디까직 공부한건지
- 넓게 얕게 준비했다 → 이건 좋은 방법이 아니다 → 여러분들은 깊게 공부하면 좋고
- 멈출 수 있는 시점을 알아야 함 ( 정답은 없다 )
- 이걸 알 수 있는 방법은 프로젝트를 통해서
- 백엔드 관점에서 보자면, 우리 서비스는 1초당 100명을 수용해야돼 → 100명을 수용할 수 있는 수준까지는 공부를 해야됨. 혹시 모르니까 한 300명까지 수용할 수 있도록 알아보기.
- 내가 깊게 공부하는 것도 중요한데, 깊게 공부하는 사람이다 라는걸 어필하는것도 중요하다. ( 기록을 통해서 )
- 처음에 취준할 때
- 얕고 넓게 (좋은 방법 X)
- php, java, python, javascript, mysql, oracle, mssql, c, c#, node, typescript, …
- 공부의 목적이, 공부한걸로 서비스를 만들 때 최대한의 효과를 보고자 익힌게 아니라, 그냥 한 번 써보고 싶어서 공부한 것들이 대부분
- 기술면접 때 매우 취약했음
- 클로저가 뭔가요, 호이스팅이 뭔가요, 실행컨텍스트는 뭔가요, javascript는 메모리를 얼마나 많이 사용하고 있나요, 이벤트 루프가 뭔가요, node는 java랑 비교했을 때 어떤 이점이 있나요, 어떤 상황에서 뭘 써야 하나요,
- 이렇게 공부하면 안되겠구나!
- 아직 나는 공부를 많이 안한 것 같은데, 취업이 되어버렸음.
- 나 왜뽑았냐. 나 되게 못하는 것 같은데, 뭘 보고 뽑았냐.
- 교육(강사)을 병행 → 다른 사람을 가르칠줄 아는 사람이라면, 학습도 빠르게 할 것이다. → 가능성을 봤다
- 취업이라는건 기술도 중요하지만, 핏(문화)가 훨씬 중요하다.
- 내가 어떤 사람인지를 잘 인지를 해야한다
- 핏이 안맞는 기업 → 무조건 힘들다.
- 나는 논리가 중요한 사람인데, 팀원들이 일하는 방힉은 다 감정적이네? → 미치고 팔짝뜀
- 나는 재택근무가 굉장히 중요한데 여기는 무조건 출근을 원하네 → 힘들다.
- 나는 팀원들이랑 상호작하면서 같이 일하는게 좋은데, 이 사람들은 서로에게 관심이 없네 → 힘들다.
- Q. 현업에서 일하는 분들에게 여쭤보고시 싶은 것. 완전 신입 기준! 연봉을 얼마나 받고 싶은지.
- 신입 연봉은 거의다 내정이 되어 있음.
- 내규에 따르겠습니다.
- 신입의 경우, 연봉 산정의 근거를 이야기하기가 어렵다.
- 뚜렷한 성과 라는게 없고.
- 내가 할 수 있는 일의 범위도 애매하고.
- 그 회사의 평균 연봉으로 이야기를 한다거나.
- 경력은 이전에 했던 일들이 있고, 받았던 돈이 있어서, 나는 이정도는 받을만해!
- 보통 서비스 기업
- 스타트업 초봉 → 3600 ~ 4000, 4500
- 네카라쿠배 → 5000, 5500, 6000
- 토스, 당근 → 6000 ~ 6500
- …
- 차라리 낮게 부르기보단, 높게 부르자.
- Q. 책을 보면서 개념을 공부하는게 재밌다. 이걸 토대로 프로젝트를 진행하는게 힘들다(의욕이 없다). 멘토님은 어디서 그런 의욕이 나오는가
- 저는 책을 안 봄, 인강도 안 봄.
- 강의형 스터디를 토대로 공부.
- 일단 만들어 보고
- 코드리뷰 받고
- 그 다음에 강의를 보고 ( 답을 늦게 알려줌 )
- 실용적인 공부를 해볼 수 있음.
- 네트워크 공부를 했음 → 내가 네트워크를 직접 만들어보는 프로젝트를 해보면 어떨까?
- TCP/IP 7계층 (5계층)
- 계층 구조를 직접 설계해보고
- UI로도 표현해보고
- 서로 통신도 해보고
- 개발을 하는 사람들의 성향
- 과학자(사이언티스트) 성향 → 탐구하는걸 좋아함 ( 기술 자체에 대한 욕구 ) ( 알고리즘 )
- 엔지니어 적인 성향 → 기술을 어떻게 더 발전시킬 수 있을까 ( 프레임워크가 어떻게 구성된거지? 더 나은 코드가 뭐지? )
- 메이커 → 만드는거에 몰빵 ( 좋은 서비스를 만들고 싶다 )
- 프로젝트를 강제로 하는 방법
- 억지로 할 수 있는 환경을 구성해보자
- 팀 프로젝트
- 2인 1조
- …
예시)
Q. 왜 라는 질문에 스스로 답변을 해보면 좋다고 했는데, 기술을 빨리 배워야 하는 압박감. 어떻게 해야 “왜?” 라는 질문을 던져볼 수 있을까?
- 압박감 → 취업
- 어떤 사람들이 취업이 잘 될까? → 정량적인 레벨의 기술에 대한 지식이 있고, 깊이가 있는 사람.
- 나는 아직 정량적인 기술 레벨까지 도달하지 못했다 → 그래서 조급하다.
- A라는 사람과 B라는 사람이 있다. 프론트엔드 개발자를 뽑아야 한다.
- A → javascript는 공부해보지 않았음. 문제 해결 경험이 굉장히 많음 ( 꼭 javascript가 아니여도, 어떤 문제를 잘 해결하기 위해 도구를 적절하게 선택할줄 안다. javascript를 학습하게 된다면, javascript를 써야만 하는 이유가 있을 때 쓴다. ) → 대체로 A를 면접관들이 선택한다 → 행위에 대한 고민을 한다. 이 일을 꼭 해야 하는건가? 그 문제가 정말 문제인가? 내가 해결할 수 있는 문제가? 나 혼자 해결해야 하는 문제인가?
- B → javascript 공부 해봤음. 취준을 위해서 공부 했음. javascript 자체에 대한 이해도는 낮음. react 잘 씀. ui 구현 잘 함.
- 갑자기 A와 B에게 어려운 문제가 주어졌을 때, 어떤 사람이 더 문제를 잘 해결할 수 있을까?
- 이게 꼭 프론트엔드와 관련이 없을 수도 있음. 인프라와 관련된 문제일 수도 있고, 백엔드와 관련된 문제일 수도 있고, 기술적인 문제가 아닐수도 있음
- 이게 지금 당장은 안되더라도, 언젠가는 꼭 해야합니다. 순서가 중요하다기보단, 경험 자체가 중요하다.
Q. 이런 과정을 4개월정도 했었는데, 6개월 과정을 프론트만 깊이 배우는 과정인데, 긴 시간 동안 잘할 수 있는 팁이 뭘까요? 잘 했다 라고 느낄수 있을만한 마음가짐.
- 너무 짧은 시간동안 프론트와 백엔드를 같이 하다보니 어느 하나 깊이 한게 없는 것 같았다.
- 깊이 배우고 싶은 욕구가 있는 것 같다.
- 막연하게 만족도는 높을 것 같다라고 생각을 하고.
- 다른 사람과 나를 비교하는 것 → 나는 잘 한 걸까? → 나는 왜 이것밖에 안 돼지? → 내가 개발자를 해도 되는걸까? → 1인분을 할 수 있을까?
- 우리는 경쟁을 하는게 아니라, 협력을 하는거다. 협력하는 관계다. 함께 자라는 관계다.
- 주변 사람을 많이 활용하기. 멘토가 될 수도 있고, 팀원이 될 수도 있고.
- 피드백을 최대한 많이 받아보기.
- 성장할때 중요한건 “피드백”
- 25 ~ 30세가 될 때 동안, 매일 양치를 하는데, 어떻게 양치를 해야 좋은건지를 모른다. 그래서 찾아본다.
- 스스로에게 적절한 피드백을 줘야 하고,
- 다른 사람에게도 적절한 피드백을 줘야 하고,
- 피드백을 주고 받을 수 있는 환경을 만들어야 하고.
- 그 피드백을 체화 시켜야 하고.
- 함께 자라기
- 정리: 같이 공부하고, 피드백 해주자.