React.js로 개발을 하다 절대 경로 설정을 추가하게 되었다. TypeScript의 경우 tsconfig.json 파일을, JavaScript의 경우 jsconfig.json 파일만 추가하면 되었기 때문에 그리 어렵지 않게 설정할 수 있었다.

 

하지만 문제는 절대 경로를 추가하니 eslint에서 문법이 이상하다고 계속 경고를 울렸다.

 

이 이슈도 좀 유명한 이슈였는지 검색하니 여러 가지 방법이 나왔고, 여러 방법을 시도하던 중 eslint에서 'import/no-unresolved' 옵션을 아래와 같이 설정해주면 된다고 하여 이 이슈도 해결할 수 있었다.

"rules": {
   "import/no-unresolved": [
      2, 
      { "caseSensitive": false }
   ],
   // 또는
    "import/no-unresolved": "off",
}

 

나 같은 경우 다른 설정은 작동하지 않아 "off"로 해결할 수 있었는데, 이 문제를 해결하는 글들을 읽어보며 "import/no-unresolved"가 정확히 어떤 옵션인지는 설명해주지 않아 나의 호기심을 자극했다.

 

다행히 GitHub에 이에 관련된 글이 있어, 이 부분을 알 수 있게 되었다. 아래 링크를 첨부하겠다.

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-unresolved.md

 

원글을 읽는 것이 가장 좋겠지만, 시간이 없거나 영어를 잘 못 읽는 분들을 위해 간단히 정리하자면

 

경로의 파일이 unresolved하는 일이 없도록 하는 옵션인 것 같다. 그래서 이름부터 import/no-unresolved다. 정확히는 import로 가져온 파일 혹은 모듈이 unresolved가 되지 않도록(no)하는 옵션이다.

 

친절한 이 옵션은 import 뿐만 아니라 require, define 등의 CommonJS 혹은 AMD도 지원을 해준다.

심지어 CommonJS 혹은 AMD를 { commonjs: true/false, amd: true/false } 옵션을 통하여 감지할지 말지를 정해줄 수도 있다!

 

그리고 한 가지 옵션을 더 설명하자면 "caseSensitive"라는 옵션이 있는데, 파일 경로가 틀린 것을 감지하는 옵션이다.

당연히 기본적으로는 켜져있어서 true이고, 끄고 싶다면 false로 바꾸어주면 된다.

절대 경로의 경우에는 flie system의 실제 경로와 맞지 않기 때문에 lint에서 빨간 밑줄을 띄우게 되고, 이 옵션을 끄게되면 이제 더이상 실제 경로와 틀리다는 경고성 밑줄이 뜨게 되지 않는 것이다.

 

그리고 또 여러 가지 옵션이 더 있는데, 자세한 사항은 위의 GitHub 링크 들어가서 읽어보면 좋을 것 같다.

 

다시 한번 더 링크

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-unresolved.md

반응형

의문의 시작

- 개발을 하던 도중, 이 글의 제목과 같은 의문이 생겼다.

- 이 의문이 무엇인지에 대하 간단히 설명하자면 useEffect, useCallback, useMemo, useLayoutoff 같은 hook은 인자로 callback 함수와 deps를 받는다. 이 때 deps에 넣은 값이 변경되면 callback을 다시 실행한다.

- hook의 사용법이나 어떻게 동작하는지 알고 싶다면 관련된 다른 글을 보거나, 아래의 공식 문서를 읽는 것이 도움이 될 것이다.

https://ko.reactjs.org/docs/hooks-reference.html

 

- 다시 본론으로 돌아가, 이런 의문이 생긴 이유는 hook의 deps에 object를 넣는 일이 생겼다. object를 넣었을때는 어떤 경우에 콜백 함수가 실행될까라는 의문이 들었다. object 내부의 프로퍼티가 바뀌었을때도 감지해서 콜백 함수가 실행될까? 혹은 key, value가 같은 object로 바뀌었을때는 콜백함수가 실행될까라는 의문이 들었다.

- 결론적으로 설명하면, objectA !== objectB가 성립되면 콜백 함수가 실행되었다. 즉 내부의 프로퍼티 변경을 감지하는 것이 아닌 단순히 객체의 주소 값만을 비교하고 달라지면 콜백 함수를 실행하는 것이였다.

- 따라서 당연한 이야기겠지만, 테스트를 해 보았을때 objectState의 프로퍼티를 변경하거나, 프로퍼티를 변경한 후 그 객체를 다시 setState 해줘도 콜백함수는 실행되지 않았다.

 

동작 원리

- 물론 여기까지만 봐도 짐작으로 deps의 변화를 어떻게 감지하는지 유추가 되지만, 정확히 어떻게 돌아가는지 확인하고 싶어서 찾아보기 시작했다. 처음에는 TypeScript에 정의된 deps의 타입을 찾아보았다. deps의 타입은 dependencyList라고 나오고 배열 안에 값이 들어가는 것만 확인할 수 있었다.

- 그 다음으로 찾아본 것은 React의 GitHub 코드를 찾아보았지만 너무 방대한 나머지 처음에는 찾다 포기를 하였다.

- 이에 관련된 글이 있을까 싶어 찾아보다가 믿음직하고 설명도 잘 되어 있는 글을 찾았다. 바로 netlify의 기술 블로그?였다.

https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-react-hooks-really-work/

 

- 또한 이 글을 읽고 다시 React 공식 GitHub를 찾아보니 deps의 동작 부분을 확인하고 이해할 수 있었다.

 

- 결론적으로 얻은 결론은 단순히 새로운 deps 배열과 기존 deps 배열을 for문으로 돌면서 값을 하나하나 비교해서 값이 하나라도 다르다면 콜백 함수를 실행시켜주는 식이였다.

- 그 비교는 단순히 a===b를 통한 비교였고, 따라서 오브젝트의 프로퍼티가 달라지면 그 부분은 확인할 수 없었다.

- 물론 React에서는 불변성을 지키기 위해 오브젝트의 프로퍼티를 바꿀 때는 새로운 오브젝트를 생성하기 때문에 대부분의 경우 이 부분이 문제가 되지는 않을 것이다.

 

- React 공식 GitHub에서 이러한 동작을 여러 부분에서 확인할 수 있지만, 가장 쉽게 이해할 수 있는 부분은 아마 이 부분인 것 같다.

https://github.com/facebook/react/blob/149b420f63903bcfb99455337a376c75384f86af/packages/react-devtools-shared/src/backend/renderer.js#L1378

반응형

<읽기 전 주의> 이 글은 외국 블로그를 퍼온 문익점 글입니다. 읽은 블로그가 틀린 내용을 담고 있다면 이 내용도 틀릴 수 있습니다!

- 출처

https://hackernoon.com/why-import-react-from-react-in-a-functional-component-657aed821f7a

글쓰면서 공식 문서도 참고했으니 틀릴 가능성은 낮을 것 같다... 물론 영어를 잘못 읽었거나 내용을 잘못 이해했다면 틀렸을 가능성도 있으니 출처도 한 번씩 들어가 읽는 걸 추천한다.

 

궁금해진 이유

- 토이프로젝트를 하기 위해 lint 설정을 처음부터 다시 할 일이 있었는데, lint 설정을 마치니  'React' must be in scope when using JSX 라는 오류가 떴다.

- 이 오류의 원인을 찾아보니 컴포넌트 파일(.jsx) 안에 import React from 'react' 가 빠져있어서 발생하는 오류라고 했다.

- 오류를 보니, 저 줄을 왜 함수형 컴포넌트에는 항상 넣을까라는 궁금증이 들었다. 심지어 이 줄이 없어도 문제 없이 돌아가기는 한다.

- 그래서 이유를 찾아봤고, 이에 대해 정리된 블로그가 있어 번역 및 정리해보았다.

 

이슈의 원인

- 원인은 바로 BABEL과 JSX이다.

 

- JSX 엘리먼트는 단지 React.createElement()를 호출하는 편리한 문법에 불과하다.

(공식문서 참조 : https://ko.reactjs.org/docs/react-api.html#creating-react-elements)

 

- 따라서 BABEL로 JSX인 함수형 컴포넌트를 트랜스파일링하면 React.createElement를 이용한 코드로 변경된다. 그렇기 때문에 React.createElement를 호출하기 위하여 React가 필요한 것이다.

 

그런데 안써도 된다?

- 하지만 React 17부터는 안써도 된다. 왜냐면 새로운 방법의 JSX 변환을 사용하기 때문이다.

 

관련 내용 블로그 : https://dev.to/titungdup/you-no-longer-need-to-import-react-from-react-3pbj

공식 문서 : https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

 

- 따라서 쓰기 귀찮으신 분은 lint 설정을 변경하여 에러를 무시하도록 한 후 React 17 혹은 그 이후의 버젼을 사용하면 된다.

 

 

 

 

 

마지막으로 다시 한 번 출처

https://hackernoon.com/why-import-react-from-react-in-a-functional-component-657aed821f7a

https://ko.reactjs.org/docs/react-api.html#creating-react-elements

https://dev.to/titungdup/you-no-longer-need-to-import-react-from-react-3pbj

https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

 

 

반응형

입사할 때 추천 + 선물 받은 책인데, 아직까지 못 읽고 있었다. ㅠㅠ

사실 책 표지가 너무 옛날 책 느낌이라 별로 끌리지 않아 미루고 미루고 있었다..

제목도 뭔가 외국 도서인데 한 2003년에 출시되었는데 번역된 느낌이라서 끌리지 않았는데.. 놀랍게도 한국인 저자에 2018년도 초판 발행이었다.

지금부터라도 천천히 읽으려고 펴봤는데, 내용이 정말 좋아서 정리하려고 한다.

뭔가 부캠에서 마스터(멘토)분들이 많이 해주신 말씀이 있는데, 그 때도 와닿는 내용들이었는데, 지금 보니까 더 강하고 새롭게 와닿아서 이 책 내용들을 읽으며 본 내용 및 내 생각들을 정리해보려한다.

 

2021/7/20

 

회고하자.

- 부캠에서 많이 듣고 하던 것들이었는데, 막상 일을 시작하고는 거의 하지 못했다.

- 회고를 하며 내가 하는 일들을 더 개선할 수 있는 방법들을 생각하고 실천해서 다음에 할 땐 실수를 덜 하고, 더 효율적으로 효과적으로 작업을 해야겠다.

 

즐기자.

- 취업 전에는 취미로 개발을 할 정도로 즐겼는데, 이상하게 취업을 하고 나서는 퇴근하고 개발 공부를 예전만큼 하지는 않는 것 같다.

- 입사 후 3개월까지도 열심히 했는데 뭔가 코로나의 여파인지, 아니면 이제 무의식적으로 일이라고 여겨서인지, 예전만큼 즐기지 못하는 것 같다.

- 일이라고 생각하지말고 예전처럼 즐겨야겠다. (근데 출근할 때는 좀 즐거운데), 이상하게 집에서 할 때는 스트레스를 받는 기분이다. 

- 집에서 개발을 하면 뭔가 일과 삶이 섞이고 무너지는 기분이라서 그런 것 같기도 하다.

- 부캠할 때, 개발은 장거리 마라톤이라고, 그리고 일과 일이 아닌 것을 분리해야한다고, 그래서 재택하더라도 출근/퇴근하는 것처럼 밖을 한바퀴 돌고 들어오라고 하셨는데, 이제 그 말의 의미를 알 것 같다. 

- 취미는 취미로 내버려두고, 전업으로 하고 싶지 않다는 사람들의 말을 이제는 조금은 이해할 수 있을 것 같다.

- 그래도 즐겁게 개발을 지속가능하게, 오래오래할 수 있는 방법을 찾아야 할 것 같다.

 

발전하자

- A라는 일을 하기 위한 B라는 일을 하고, B라는 일을 개선하기 위한 C라는 일을 하자

- 이 말의 의미를 부캠할 때는 크게 못 느꼈는데, 요즘은 많이 느끼는 것 같다.

- 더 잘하기 위한 방법을 더 잘하기 위한 방법을 더 잘해보자 ㅎㅎ

- 블로그도 이제 좀 다시 써봐야겠다.

 

 

 

2021/7/22

 

어려운 일을 해라

- 이 말은 어려운 개발을 해라라는 의미보다, 사람들과 소통하는 등의 업무를 하라는 뜻이다. 코파일럿이 나온 지금 더욱더 중요한 말인 것 같은데, 주어진 스펙을 개발하는 개발자가 아니라 요구사항을 분석하고, 요구를 이해하고 오히려 제안하는 등 컴퓨터가 하기 힘든 일을 잘하는게 중요한 것 같다.

- 이말은 간단히 말하면 답이 있는 문제, 측량이 가능한 그런 문제가 아닌, 답이 없는 문제, 측정이 어렵고 당장 눈에는 안 보이지만 어려운 것들을 하라는 말이다.

- 조금은 논점에서 벗어나지만, 이 부분을 읽으면서 예전에 대학생 때 프로젝트하면서 요구하면 '다 해주는 개발자'로 불렸던게 기억난다. 요구사항을 들고오면 다 구현해주었다. 물론 실력이 모자랐기에 아주 깔끔하고 완벽하게 개발해주지는 못했지만...그 때 기억나는게, 돌아가는 예시 사이트를 들고오면 그대로 해주겠다고 했었는데...참 패기로웠던 것 같다.

- 물론 또 다시 생각해보면, 요구사항을 다 들어주지는 않았다. 요구 사항을 들고오고, 예시 사이트를 들고오면, 어떤 부분이 적용되길 바라는지, 왜 이 부분을 넣고 싶은지, 이런 저런 이야기를 해주면서 요구사항을 디벨롭하며 필요 없는 부분은 쳐내고, 필요한 부분은 더 발전시켰던게 생각나서, 나름 잘 살았던 것 같다. 정말로 논점에서 벗어난 이야기인 것 같지만..

 

계속 의식하면서 일해라

- 이 부분은 더 읽어봐야 알겠지만, 간단하게 말하면 양치질 30년한다고 양치 전문가가 되지 않듯이 의식하면서 일을 해야한다!

 

 

2021/10/17

 

사실 이 책을 다 읽은지는 꽤 되었다. 근데 블로그 관리를 하지 않아서...ㅠ

책 내용이 괜찮아서 나중에 생각날때 다시 읽겠지만 기억나는 요점은 간단히 정리하자면

애자일하게, 결과를 짧게 짧게 낼 수 있도록 하고, 그에 대한 회고를 하며 단점을 보완해서 나아지자! 라는게 이 책의 핵심인 것 같다.

 

글이 용두사미가 된 것 같은데, 나중에 시간이 나면 더 정리해보아야겠다.

반응형

'Coding > 읽은 책들' 카테고리의 다른 글

해커와 화가  (0) 2020.07.16
알고리즘 도감 : 그림으로 배우는 알고리즘 26  (1) 2018.07.20

댓글을 보다가 연락하고 싶어도 방법이 없었다는 말을 보고 간단한 소개 남겨봅니다.

 

이메일 : puba5@naver.com

반응형

2017년 배그(배틀그라운드) 열풍이 있었을때, 어떻게하면 배그를 잘 할 수 있을까를 많이 찾아봤었다.

 

간단하게 할 수 있는 게임 내 옵션 설정 같은 게임 시스템을 이용한 설정부터 시작해서,

어떻게하면 프레임 드랍(화면 끊김)이 안 일어나는지, 마우스 감도 조절을 어떻게해야 잘 되는지 등등 많은 방법을 찾아봤다.

 

찾은 방법들은 대부분 더 쾌적한 플레이를 제공해주었지만, 내 게임 내 점수가 올라가며 더욱더 잘하는 상대들을 만나며 미묘한 차이가 승패를 좌우했다.

 

그래서 결국 하드웨어인 마우스 또한 찾아보게 되었다.

여러 pc방을 돌아다니며 플레이해 본 결과, fps(총게임)에서 제일 중요한 것은 마우스라는 것을 느꼈다.

또한 사실 모니터, 키보드도 중요하지만, 그런건 pc방에 들고 다닐 수 없기에, 마우스만 따로 구매해서 pc방에 들고다니며 사용했었다.

 

마우스를 찾아보고 공부하다보니, 게이밍 마우스 뿐만 아니라 사무용 마우스에 대해서도 어느 정도 알게 되었고, 그래서 이렇게 글을 쓰게 되었다.

 

 

게이밍 마우스

먼저 게이밍 마우스에 대해 결론부터 말하면 '로지텍 무선 마우스'이다.

 

일단 pc방 투어를 다니며 마우스를 다 써봤는데, 다른 회사의 마우스는 기대에 정말 못 미쳤다.

 

일단 전용 프로그램이 이상했다. 감도 조절을 하는데, 소프트웨어가 먹통인 경우가 많았다.

무슨 말이냐면, 윈도우 기준으로 윈도우 자체 제공하는 마우스 감도 조절 설정이 있고, 게이밍 마우스 회사마다 제공하는 감도 조절 프로그램이 있다.(물론 모든 회사에서 제공하진 않는다.)

 

그러면 로지텍의 경우 윈도우 감도 설정이 '3'이든 '10'이든 로지텍이 800이면 800의 속도를 내주는데, 다른 회사는 '3' * 800 이렇게 두 개 다 조정해야하는 경우가 많았다. 정확히는 윈도우 감도를 무시한다는데, 무시를 안하는 경우가 많아서 많이 애먹었다.

물론 집에서만 한다면 세팅을 한번 해놓으면 문제 없겠지만, 여러 환경에서 플레이하는 나의 입장에선 그렇지 못했다.

 

그리고 두번째는 개인적인 이유지만, 생각보다 그립감이나 그런 여러 가지가 별로 좋지 못했다. 근데 이건 개인적인 취향이긴한데, 로지텍 g102의 그립감을 이기는 마우스는 별로 보지 못했다.

 

그리고 유선.. 유선도 나쁘지 않은데, 선이 하면 할수록 정말 거슬린다.

이건 진짜 플레이하면 할수록 느낄 것이다.

 

개인적으로 마우스 번지(마우스 선 고정대)가 하나 있으면 유선도 충분할 것 같지만, 번지 가격이 생각보다 만만치 않다.

요즘 무슨 마우스 가격도 많이 내려서 차라리 무선 사는게 나은 것 같다.

 

솔직히 말하면 무선의 단점은 배터리를 계속 사야한다는 점 빼고는 없는 것 같고, 

로지텍의 같은 경우는 내구성(사용을 좀 오래하다보면 더블클릭이 되는 이슈가 있다) 빼고는 정말 잘 만든 제품 같다.

 

구매해서 사용해본 제품

사실 말한대로 여러 제품을 사용해봤지만, 지금 집에서 오랫동안 사용하고 있는 제품은 3가지이다.

g102

  - 국민 게이밍 마우스다. 피시방 가면 아마 대부분 이 친구가 있을 것이다. g pro도 외관은 똑같아서 헷갈릴 수 있다.

  - 손이 작은 사람에게도 어울리고, 가벼워서 롤 같은 게임을 할 때 좋은 것 같다. 개인적으로 제일 마음에 든 마우스이고, 유선 버전을 찾아 헤매다가 g304가 출시해, 바로 구매했다.

  - 유선인 거랑 로지텍 고질적 문제인 더블클릭이 문제이다.

 

g304

  - g102 무선 버젼이다.

  - 사실 g102는 저가형이라 재질도 엄청 고급스럽지는 않다. g304도 마찬가지

  - 하지만 성능 자체는 좋아서 이 마우스를 요즘 계속 사용중이다.

 

g603

  - 얘는 무게도 무겁고, 크기도 크다.

  - 이 친구는 g102, g304와 다르게 고급형이라 가격도 비싸지만, 재질이나 자잘한 디테일이 매우 좋다.

  - 사실 무게는 취향차이지만, 처음에는 매우 적응이 안됐다.

  - 이게 사실 무거우면 마우스의 조그마한 움직임이 중요한 게임에서 좋긴하다. 예를 들면 에임이 중요한 배그라던지..배그라던지

  - 반대로 많이 움직이는 게임, 예를 들면 롤이나 오버워치는 가벼운 마우스가 좋아서 얘는 잘 안 어울리긴한다.

  - 하지만 진리의 케바케이다..필자 같은 경우 이 마우스로 모든 게임을 소화해냈다.

  - 얘의 장점은 건전지로 무게 조절이 가능하다는 점! 건전지가 최대 2개까지 들어가는데, 한개만 넣어도 작동이 되서, 이걸 이용해서 무게 조절이 가능하다.

 

 

 

결론

솔직히 무슨 게임을 하고, 나의 손 크기, 모양이 어떤지에 따라 인생 마우스는 케바케다.

나처럼 피시방 투어를 한번 하든가, 하이마트 같은 곳을 가보든가 해서 만져보는게 최선이겠지만, 그게 아니라면 이런 글들이나 유튜브를 보고 판단하는게 최선인 것 같다.

사실 당근 마켓이 잘 발달된 우리나라에서는 마우스가 좀 싸게 나왔다 싶으면 사보고 좀 써보다가 파는 것도 나쁘지 않은 선택인 것 같다. 

렌탈이라 생각하면 충분한 값을 하는 것 같아서 말이다.

사실 마우스는 출시 주기가 좀 길기 때문에 중고가 방어가 잘 되는 편이다. 사실 다른 게이밍 장비에 비해 그리 비싸진 않지만, 큰 비중을 차지하기 때문에 여기에 좀 투자해서 게임 실력이 부족해서 받는 스트레스를 줄이는 것이 인생 전체로 보면 최고의 투자가 아닐까 싶다.

 

 

 

반응형

잊기 전에 2020년에 본 코딩테스트 느낌을 적어보려한다.

참고로 테케가 없다는 것은 아예 없다는 게 아니라 1-3개의 기본적인 테케만 준다는 것이다.

모든 점수와 평가는 주관적이며 상대적이다.

☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★☆ ★

공채

 

- 라인

알고리즘이나 난이도는 어렵지 않다.

하지만 주어진 시간이 적고 테케도 적어 구현하기가 조금 어렵다.

그리고 가장 큰 어려움은 문제 수는 많은데 시간은 적다.

하지만 문제의 난이도는 어렵지 않은 편이라 풀어볼만 하다.

이상한 알고리즘을 물어보거나, 이상한 테케를 요구하는 억지스러운 문제가 없어서 좋았다.

 

알고리즘 난이도 :  

구현 난이도 :  

테스트케이스 X

종합적 체감 난이도(시간도 고려) 

 

 

- 카카오

그 유명한 카카오 코테.

문제 난이도는 제일 어려웠다. 그리고 깔끔했다.

다른 코테가 사설 모의고사라면 카카오는 수능 같은 느낌.

 

대회처럼 생소한 알고리즘을 요하는 것은 아니라서 좋았다.

대표적인 알고리즘을 숙지하고, 응용할 줄 알아야한다.

그리고 그 문제를 구현하는 것도 어려운 편.

다행인 건 테스트케이스를 많이 준다는 점.

우리나라 IT 기업 공채에서 가장 어려운 코테인 것 같다. 

 

알고리즘 난이도 :  

구현 난이도 :  

테스트케이스 O

체감 난이도(시간도 고려)

 

 

- 네이버

쉽다. 시간도 적다. 하지만 그만큼 쉽다.

네카라 중 제일 쉬운 코테 난이도. 네카라뿐만 아니라 다른 기업과 비교해도 쉬운 편이다.

하지만 시간이 정말 적고 테케가 없어, 시간 조절을 조금 잘못하면 말릴 수 있으니 조심할 것.

문제는 깔끔하다.

 

알고리즘 난이도 :  

구현 난이도 :  

테스트케이스 X

체감 난이도(시간도 고려) 

 

 

- 쿠팡

문제 자체는 어렵지 않았다.

요하는 알고리즘도 어려운 편은 아니었다.

시간도 부족하지 않았다.

하지만 문제 규모가 좀 있고, 테스트케이스를 주지 않아 꼼꼼함을 요구하는 느낌이었다.

문제 규모가 있기 때문에 테케를 꼼꼼히 살펴봐야한다.

하지만 규모가 있는 것 치고 더럽지 않았다.

네이버 매운맛 느낌이었다.

 

알고리즘 난이도 :  

구현 난이도 :  

테스트케이스 X

체감 난이도(시간도 고려) 

 

- 11번가

문제도 쉽고 시간도 많이준다.

테케를 안주지만, 의미 없을 정도로 쉽다.

사실 IT 기업 코테만 봐서, 상대적으로 많이 쉬웠던 걸 수도 있다.

 

알고리즘 난이도 :  

구현 난이도 :  

테스트케이스 X

체감 난이도(시간도 고려) 

 

 

- NHN

알고리즘은 쉽다. 다만 예외가 많아 구현이 힘들다.

소위 말하는 좀 구현이 까다로운 문제인 것 같다.

삼성 코테를 보지 않아 정확히는 모르지만, 이야기만 들으면 삼성 같은 느낌 같다.

언어 제한이 있어서 그 점이 힘들었다.

 

문제 내신 분이 백준 문제 좋아하는 느낌...

시간은 충분했던 것 같다.

 

알고리즘 난이도 :  

구현 난이도 :  

테스트케이스 X

체감 난이도(시간도 고려) 

 

 

공채 코테 전체적인 평

비유하자면, 카카오는 불수능, 라인은 물수능 느낌. NHN은 어려운 사설 모의고사 문제 느낌이고, 쿠팡은 좀 어려운 교육청 모의고사, 네이버는 쉬운 교육청 모의고사 느낌이었다.

 

대회 같은 곳에선 생소한 알고리즘도 가끔 나오는데, 다행히 기업 코테에서는 그런 알고리즘이 안나와서 좋았던 것 같다.

 

물론 다 개인적인 의견이다. 문제를 내신 분이 당연히 나보다 더 알고리즘을 잘 아실테고,

문제를 내실 때다 의도가 있기 때문에 테케가 빡빡하거나, 문제의 규모를 크게 내거나, 생소한 알고리즘 문제를 내셨을테니까.

이것들을 감히 내가 평가할 수는 없다고 생각한다.

 

그래서 그냥 이 글은 개인적인 의견으로만 봐주셨으면 한다.

그리고 이런 느낌이구나하고 느낌만 가져가서 준비에 도움이 되었으면 한다.

 

개인적인 난이도는 카카오 > 라인 >> NHN = 쿠팡 >> 네이버 >> 11번가였다.

 

문제는 아마 프로그래머스나 백준 같은 곳에 있을 수도 있으니 한 번 찾아보는 것도 좋을 것 같다.

반응형

5개월의 부스트캠프 과정이 끝났다.

 

작년의 내가 2019 부스트캠프 글들을 보며 할까말까 고민하였는데, 아마 내년 여름쯤 이 글을 보며 2021 부스트캠프 지원할까말까 고민하겠지..

 

길다면 길고, 짧다면 짧은 기간이었다.

 

반팔을 입어도 더운 한여름에 시작했고, 롱패딩을 입어도 추운 한겨울에 끝났으니 말이다.

 

이 글을 읽는 사람은 자신이 한 부스트캠프를 회고하며 추억을 감상하려 읽는 사람도 있을 것이고,

 

부스트캠프가 어떤 것인지, 지원할건지 말건지 고민하시는 분이 읽을 것이다.

 

나는 지원 여부를 고민하는 사람을 대상으로 이 글을 풀어나가려고한다.

 

먼저 부스트캠프에 대하여 소개하자면, 네이버 커넥트 재단에서 진행을 하는 프로그램이고, 5개월 동안 웹 풀스택 과정을 JS로 익힌다. 

물론 올해에는 iOS도 있고, 매해마다 종목?은 다른 것 같다.

 

나는 웹을 하고 싶어 웹풀스택을 지원했고, 1번의 자소서와 2번의 코테를 통과하여 부스트 캠프 챌린지를 시작하게 되었다.

 

부스트캠프는 챌린지 과정과 멤버쉽 과정이 있는데,

챌린지는 하루하루 간단한 미션이 주어지는 과정이고, 멤버쉽은 주 단위의 긴 흐름을 가져가는 프로젝트를 진행하는 과정이다.

 

따라서 챌린지에는 좀 더 얕고 넓은 지식을 배울 수 있고, 멤버쉽에서는 좀 더 깊은 지식을 배울 수 있었다.

 

내 경험상으로 말해주자면, 만약 자신이 플젝은 좀 해봤지만,

플젝을 하면서 느끼는 '돌아는 가는데 왜 돌아가는지 모르겠다' 혹은 'CS가 왜 중요한지 모르겠다'라는 생각이 들고, 이 궁금증을 해결해보고 싶다면 정말 강추다.

특히 챌린지 과정이 많이 도움이 될 것이다.

 

플젝을 많이 진행하고, 학교에서 과제를 하며 막히기는 했지만 성공을 했지만, 그 근본적인 지식을 잘 알지 못하였다.

물론 근본적인 지식을 공부를 하고, 궁금증을 해결하기 위하여, 구글링을 하고, 야크 털을 깎았지만, 과연 이렇게하는게 맞을지?라는 의문이 많이 들었었다.

 

강의를 들으면 오히려 물음이 더 생겼고, 공식 문서에는 모르는 내용이 한가득이었고, 블로그를 읽으면서 이게 정말 맞는걸까라는 의문을 수도없이 가졌다.

 

이 해답을 부스트캠프 챌린지 과정에서 얻었다.

여기서는 정해진 답을 알려주지 않는다. 다만 학습하는 법을 알려준다.

새로운 얕고 넓은 개념을 하루하루 던져주며, 이것을 학습하고, 과제를 해결한다.

 

이 과정을 팀원들과 함께 하고, 마스터(멘토라고 생각하면 편하다)의 강의를 통하여 내가 가장 크게 얻은 것은

 

야크 털 깎기나 공식 문서를 보는 등 지금까지 내가 가려는 길의 방향은 맞았다는 것을 알게 된 것이다.

그리고 이를 더 빠르게 가는 방법과, 그리고 계속해서 방향을 잃지 않는 법을 배웠다.

 

한마디로 요약하자면, 뭔가 열심히는 하고 있는데, 내가 가는 방향이 맞는가 의심스럽다면 챌린지를 들어라! 

 

그리고 멤버쉽은 그 깨닳음을 다지는 시간이었다.

어떤 것이 중요하고, 어떤 방향으로 나아가야할지 알았다면, 이제 그 방향으로 나아가는 과정이 멤버쉽이라고 생각한다.

 

사실 챌린지가 끝나고 많이 고민했었다.

챌린지 과정을 통해 내가 원하던 답을 찾았고, 이제는 좀 더 해보고 싶은 것들을 하거나, 취업을 빠르게 하고 싶었기 때문이다.

 

스타트업에 들어가든가 한번 스타트업을 차려보든가, 아니면 해보고 싶었던 토이플젝을 할까.

정말정말 많이 고민을 했었다.

 

학생이라는 신분에서 스타트업에 도전을 해보고 싶었고, 학생이라는 신분에서 할 수 있는 토이플젝을 해보고 싶었다.

 

하지만 스타트업은 하지 말라던 사회생활을 좀 했던 친구의 조언과 내공을 기르라던 교수님의 조언이 떠올라

고민 끝에 나는 멤버쉽 과정을 진행하였다. 

 

그리고 사실 코로나 시대에 취업이 안된다, 안된다는 주변의 말들이 많았고, 부스트캠프 과정이 끝난 후 취업 연계를 해준다는 이 2가지 정보 또한 나를 흔들리게 했던 것 같다.

사실 부스트캠프 채용 연계가 아니더라도 챌린지에서 얻은 깨닳음으로 다른 곳에서라도 열심히하면 취업은 잘 할 것 같았는데, 주변의 걱정이 심했다...

그 놈의 코로나...그 놈의 취업...

 

 

개인적으로 플젝 경험이 많지 않다면 멤버쉽 과정을 강추하고, 플젝 경험이 있더라도 멤버쉽 과정을 추천한다.

 

개발에 열정이 있는 사람들과 조금은 특별한? 프로젝트 경험을 쌓을 기회는 없을테니까

물론 마지막 플젝 이외에는 포폴에는 사용할 수 없는 플젝들이었다 ㅎㅎ

 

하지만 팀원들과 협업하고 지식 공유를 하는 경험은 정말 많은 도움이 된 것 같다.

 

개인적으로 이미 플젝은 많이 해보았다? 생각을 하여 나는 구현보다는 학습에 치중을 두어서 많은 구현은 하지 않았다.

아마 플젝을 많이 해본 분들은 비슷한? 구현을 하는 기분이라 그렇게 신박한 경험은 아닐 것이다. 물론 얻어갈 것이 없다는 말이 절대절대 아니다. 

 

상대적으로 플젝 경험이 없는 사람보다는 덜 유익할 것이고, 플젝 경험이 많이 없는 사람에게는 정말 정말 이 과정을 추천한다.

 

개인적으로? 감히 말해보자면 이미 플젝을 많이 해보았고, 앞으로 좋은 플젝 기회가 많은 분들은 멤버쉽이 아니라 다른 플젝을 하셔도 괜찮을 것 같다. 예를 들면 인턴 기회가 있다든가, 정말 좋은 팀원들과 토이 플젝을 할 기회나, 스타트업 같은걸 해볼 생각이 있다든가 하는 말이다. 

 

하지만 그런게 아니라면 혹은 그렇다하더라도 부스트캠프 멤버쉽은 정말 정말 성장하기 좋은 기회일 것이다.

그리고 개발에 열정이 있는 좋은 동료들을 만날 정말 좋은 기회이다.

 

나에게 운이 좋게도 부스트캠프라는 기회가 주어져서 정말 좋았고, 다시 돌아간다해도 주저없이 부스트캠프를 선택하지 않을까 싶다.

 

다만 아쉬운 점은 올해 온라인으로 진행되었다는 점이...많이 아쉽다...

 

그리고 마지막으로 한마디만 더 말하자면 부스트캠프가 쉽고 편한 만능의 길이라 생각이 들겠지만,

그리 편한 길은 아니다. 부스트캠프 기간, 특히 챌린지 기간 동안은 정말 많이 불태웠던 것 같다...

하지만 힘든만큼 얻어가는 것 또한 많은 것 같다.

개발과 개발 외적으로...

반응형

+ Recent posts