https://www.wanted.jobs/events/pre_ob_fe_7
프리온보딩이란, HR기업인 원티드에서 일정 수준이상의 구직자와, 또한 구직자가 원하는 회사를 매칭 해주기 위하여 서로의 조건을 만족시켜줄 수 있도록 준비된 코스입니다.
코스 과정은 4주간 진행되며, 준비된 총 6번의 기업과제물을 받고, 실제로 구현하여 제출하는 과정을 거치게 됩니다.
프리 온보딩은 pre + Onboading의 직관적인 단어 조합으로,
사전에 조직문화,업무에 빠르게 적응할수 있도록 돕는 과정을 의미하기도 합니다.
매 과정은 개인 과제로서 구현하고 제출되지만, 동시에 팀 과제로서 모범사례 하나를 뽑아 제출하는 형식인것 같습니다.
저는 대부분의 경우 독학으로 웹개발을 공부하였고, 그것이 득이 될 경우도 있었지만, 사실 대부분의 경우에는 좋지 않았던것 같습니다. 코드 리뷰 또한 받을 수 없었고, 협업의 경우에도 결국 프론트엔드는 저 혼자밖에 없어서 다른 사람과 실질적으로 협업하는 경험도 전무하였습니다.
또한, 취업을 위해서 정말 이런저런 많은 것들을 건들여봤지만, 저에게 정말 필요한게 무엇인지 모른채 많은 시간을 허비해왔던것 같다라는 생각이 들던차에 원티드 프리온보딩 코스를 발견하게 되었습니다.
실제로 내가 기업의 기대에 만족하는 결과물을 낼수있을까?? 그럴 수 있는 실력이 있는걸까? 사실 이것이 가장 프리온보딩 코스에서 경험해보고 싶었던 부분이였습니다. 때문에 프리온보딩 코스를 지원하였습니다.
사실 프리온보딩을 지원하게 된 이유는 기업과제 이외에도, 커리큘럼에 대해 많은 흥미를 가지고 있었기 때문이기도 합니다.
개발 코드를 공부해오고는 있었지만, 이것이 맞는 방식인지. 실제로는 어떠한 방식으로 많이들 사용하고있는지, 또한 왜 그렇게 사용되고 있는지에 대해 관심이 있었는데. 프리온보딩에서 다루는 과정은 하나같이 모두 흥미를 끌만한 주제였습니다.
주 2회 강의를 진행하게 되는데, 첫 번째 강의는 간단한 오리엔 테이션, 참가 과제물에 대한 피드백, 그리고 Git,ESLint,Prettier 및 husky를 통한 자동화를 다루었습니다.
오리엔테이션의 앞부분에서는 기본적으로 과제 수행을 위한 지식 및 도움 제공을 해주지 않으며, 정답을 정해주고, 주입하는 교육이 아니라는것을 공지하였습니다.
기본적으로 프리온보딩이 추구하는 가치는 "동료 학습을 통해 지식을 공유하고 토론하는 과정을 통한 역량 향상"
그리고 커리큘럼에서 가르치고자 하는것은 시야가 확장되는 것 을 목표로 하는 과정이 될것이라 하였습니다.
주니어에게 있어 가장 중요한것은 현재의 기술 보다는, 성장 가능성이 더 중요하다는 것이며, 지식들 보다는, 왜 이걸 사용하는지, 적용하면 뭐가 좋은지에 대한 why에 대한 강조를 하셨습니다.
그저 독학을 통해서 주어진 지식을 습득만 해온 저에게 이런 발언 및 경험은 신선하고, 또한 어찌보면 낯설기때문에 어려울수있는 과정일 수도 있겠구나 라는 생각이 들었습니다. 하지만 동시에 이 과정을 견디고 적응한다면 분명히 좋은 결과가 있을것 같다라는 생각이 들었습니다.
선발과제에 대한 전체적인 피드백을 해주셨는데,
여기에서 중점으로 말씀해주신것중 기억에 남는것은 이런거였습니다.
기본적으로 보는건 readME,commitMsg,배포 또는 영상여부
그리고 추가적으로 파악하고자 하는건 코드의 스타일, 프로젝트 구조, 과제 수행태도, git활용 도 등을 언급하셨습니다.
과정 중 생각나는 조언들은, 컴포넌트의 가독성에 대해 언급해주셨는데
기본적으로 컴포넌트는 "논리적인 단위" 로서 잘 분해되어 사용되었는가를 의미하고,
의존성은 어떻게 설계되어있는지, 외부의 변화에 유연하게 대응할 수있는지에 대해서 말씀해주신것 들이였습니다.
사실 위와 같은 것들은 기본적으로도 중요한 것들이지만, 구직자 입장에서 중요한 이유는
이것들은 채용 담당자의 관심사를 끄는 주요 issue이기 때문입니다.
부실한 readMe, 관리되지 않은 gitMsg, 규칙성 없는 코드 포멧팅, 기능구현을 확인하기 어려운 과제, 허가되지 않은 라이브러리 사용 는 채용자 입장에서는 극악과 같은 것이였고
구직자는 기본적으로 이러한 사항들을 지양하며, 좋은 모습으로 관리하여 구직자에게 좋은 인상을 일차적으로 남겨야 합니다. 또한 그러한 관심이 그 사람에 대한 추가적인 관심까지 이어질수있어야 합니다. 그사람의 GitPage, 블로그 등과 같이 관심을 가질 수 있게하는 요소가 있어야 한다고 말씀하셨습니다.
이러한 부분은 제가 생각은 하고 있었지만, 잘 지키지 않고 있던 부분이였는데, 자세하게 설명해주시고, 충분히 납득가능하고 반성 할 수 있는 기회가 되었습니다.
Git은 분산 버전 관리시스템, 약간 풀어말하자면 코드의 버전 관리를 도와주는 시스템이며, GitHub는 Git의 원격 저장소입니다.
Git 자체만으로는 그저 로컬환경에서 버전을 관리하는것에 불과하지만, GitHub를 통해서 개인적인 Git을 타인과 공유하고, 팀원과 공동으로 작업할수있는 환경이 갖추어집니다.
GitHub와 같은 공동 작업 환경이 갖추어진 상황에서는, Git을 다루는것은 신중하여야 합니다. 혼자서 개발하는것이 아닌, 여러명과 개발하기때문에 이전 버전으로 되돌아 가야되는 상화잉 올수있고, 이전 버전에 대한 정보를 확인 해야 되는 과정이 있을수도있습니다.
이러한 과정에서 GitMsg가 제대로 작성되어 있지 않거나, 무성의하게 작성되어 있다면, 버전 관리가 매우 힘들고 복잡해질것입니다.
이러한 것을 위해서 commit시 Msg를 사용하는데, 이 Msg 규칙 또한 각자 다르게, 또는 같은 언어라도 다른 형식으로 사용되어진다면 이 또한 이전 상황과 크게 다르지 않을것입니다.
때문에 GitHub 환경에서는 통일된 GitMsg 를 사용하는것이 매우 중요하다 볼 수 있습니다.
추가적으로 알려주신것은, 불가피하게 작업중에 Commit을 하게 되는 과정이 있을수도있는데, 이러한 과정은 나중에 commit이 뒤죽박죽으로 섞여있게 하는 원인이 될 수 있기때문에, 이러한것은 git Squash를 사용하여 관리 할수 있다 말씀하셨습니다.
참고링크 : https://www.delftstack.com/ko/howto/git/git-squash-commits/
사실 ESLint,Prettier는 기존에도 사용하고 있던것들이였고, 중요성에 대한것은 많이 들어왔던것이였습니다.
기본적으로 개발자들은 각자의 코딩 스타일은 가지고있기때문에, 다른 스타일은 가진 개발자는 타인의 코드를 보기 어려울수있습니다.
때문에 협업을 하는 관계에서는 이러한 부분을 통일하기 위해 JS를 다루는 개발자들에서는 ESLint로 지양하는 문법을 어느정도 제한하고
Prettier를 사용하여 코드의 스타일은 교정하는데 사용하고있습니다.
대략적으로 위와 같은것들에 대한 설명, 그리고 설정에 대한 설명, 그리고 충돌을 막기 위한 라이브러리(eslint-config-prettier), 이전에 했던 정보는 다시 할 필요가 없으니 --cache, 그리고 .eslintcache는 ignore 파일에 추가해줘야 된다는것과 같은 추가설정 그외 설명이 이루어졌습니다.
마지막으로 이러한 작업이 반드시 지켜지도록 하는, GitHook을 사용하는 husky 에 대한 설명이 있었습니다.
husky는 GitHook을 사용하는데, 쉽게 설명하면 commit과 push 이전에 ESLint와 Prettier의 실행을 보장하는 라이브러리입니다.
husky의 사용법은 아래와 같습니다.
npm install husky --save-dev
npx husky install (처음 husky 세팅하는 사람만 실행)
npx husky install (husky에 등록된 hook을 실제 .git에 적용시키기 위한 스크립트)
package.json에 'husky install'설정 (clone 받은 사람이 이후 간단히 설정할 수 있기 위하여)
// package.json
{
"scripts": {
"postinstall": "husky install"
},
}
ESLint,Prettier의 scripts 설정
// package.json
{
"scripts": {
"postinstall": "husky install",
"format": "prettier --cache --write .",
"lint": "eslint --cache .",
},
}
add pre-commit, pre-push hook
npx husky add .husky/pre-commit "npm run format"
npx husky add .husky/pre-push "npm run lint"
이 과정을 통하여 husky를 사용하여 ESLint와 Prettier의 자동화를 보장 할 수있게 됩니다.
사실 첫 강의에서는 오레인테이션식으로 많은 것이 나오지 않지 않을까 생각했었는데, 오리엔테이션부터 husky까지 모든 강의가 모두 유익하고 배울점이 있는 강의였습니다.
저는 개발자의 기본소양이라고 말씀하신 readME와 GitMsg, Git페이지의 소홀이 매우 심각한 상태였었고, 블로그 또한 관리하지 않았었는데. 이러한 부분에선 다시금 문제를 깨달을 수 있었습니다.
또한 동료학습을 통하여 문제는 스스로 해결해야 한다는 신조 또한 4주간의 경험으로 배울 수 있을것이라 기대하고있습니다.
그리고 husky 를 통한 코드 포맷팅에 강제성 및 자동화 또한 강의의 목적이고자 했던 시야가 확장되는 것을 조금이지만 맛을 볼 수 있었던것 같습니다.
전체적으로 만족했던 첫 수업이였고, 앞으로가 매우 걱정되지만 기대되기도 하는 4주일것 같습니다.