Sunny Yoon

Sunny Yoon

인간은 노력하는 한 방황하는 법이다

-파우스트-

[하이에나 커리어] 신입 프론트엔드 개발자가 6개월동안 배운 것

Date:     Updated:

카테고리:

태그:

6개월, 코딩 우다다다

image

🚀신입

사실 개발자로 일을 하기 전에는, 몇가지 오만한 생각들이 있었다. 어차피 특정 기술적인 부분에 있어서는 모든것을 검색을 통해서 해결할 수 있을거라고 생각했다. 또한 귀찮은 UI등은 GPT에게 맡기면 되는데, 개발자로써 현업에서 일을 하면서 어떤 것들을 배울 수 있을지 의문이 있었다.

일다 뻔한 것들을 알게 되었다. 뭐 짧게 적으면 아래와 같은 것들일 것이다.

  • 약속시간은 잘지키자
  • 직장 내 인간관계는 어쩌고…
  • 개발속도와 코드의 퀄리티를 잘 조율 어쩌고..
  • 협업을 할때는 공격적이지 않게 의견을 잘 피력…
  • 기록을 잘하면 뭐가 좋다더라… 등등


🚀깨달음

그냥 뻔한 이야기들이지만 사람들과 부딪히면서 알게되는 그러한 것들이다. 나의 조약한 경험은 다른 곳들에서도 쉽게 들을 수 있는 이야기들일 것이다.

오만한 신입개발자보다, 사회성이 훨씬 좋거나, 갖은 역경을 뛰어넘으신 분들은 이미 훨씬 잘 알고 있을 부분들일 것이다. 따라서, 6개월동안 기술적으로 깨달음을 얻은 부분들, 즉, 공부한 부분들에 대해서 짧게 적어보고자 한다.

필자가 일을 시작하기 전에 궁금했지만, 잘 나오지 않았던, 기술적으로 어떤 부분을 더 고민하고, 공부하게 되었는지에 대한 내용을 주아아악 적어보도록 하겠다.


🚀프론트엔드

  1. useState는 state as a snapshot이 중요하다
  2. useReducer는 기존상태에 의존을 많이할 때 사용하기 좋다
  3. SendBird깃을 보면 useCallback을 사용하는 예제가 잘 나온다.
  4. 거대한 json을 만들때, webWorker를 이용해서 만들면 렉도 안걸리고 좋다.
  5. undo/redo를 구현할 때, 커맨드 패턴을 사용하면 편하다
  6. i18n으로 다국어를 쉽게 제공할 수 있다.
  7. 탭을 만들 때, 인덱스를 이용하면 편하다
  8. MVVM 패턴으로 비즈니스 로직을 분리할 수 있다.
  9. 하지만 관심사를 분리하는것을 중심적으로 생각하는게 더욱 깔끔한 코드를 도출할 확률이 높아진다.
  10. 나의 코드는 쉽게 오용되기도 한다.
  11. 내가 타인의 코드를 망칠수도 있다.
  12. factory패턴을 이용하면 생성자 시그니쳐가 바뀌어도 의존성 떼어낼 수 있다. 오용 확률도 줄어든다.
  13. any쓸바에는 unknown으로 쓴다.
  14. mobx는 best Practice도 없다. 아주 다양한 방식으로 사용될 수 있다.
  15. mobx는 class로 만들어야 devTool에서 디버깅이 된다.
  16. 웹에서 로컬파일들을 가져올 때, 한번에 여러개의 파일을 선택하는 코드는 단일파일 선택과 조금 다르다.
  17. requestAnimationFrame내부에서 굳이 Performance.now()를 사용할 필요가 없다.
  18. 유저가 할 수 있는 액션들에 대해 미리 객체로 정의해 두고, 해당 객체의 특징을 찾아서 실행시키는 패턴으로 관심사를 모아둘 수 있다.
  19. 복사하려는 객체를 포인팅해두고 붙여넣기보다는, clipboard를 만들어서 일시적으로 따로 들고있는게 더 좋다.
  20. 클릭당한 Anchor Element 기준으로 모달창을 띄워줄수도 있다.
  21. observer에서 subscriber들에게 리렌더링을 시켜줄 수 있다.
  22. CRACO를 통해 webpack config파일을 설정해 줄 수 있다.
  23. CRA에서 vite로의 전환은 많은 사이드 이펙트를 줄 수도 있다. 문제없이 마이그레이션 될수도 있다.
  24. vite에서 파일명이 한글일시, 파일 추가를 인식못할 때도 있다.
  25. react-script start는 변환,번들링, 서버실행, 워커실행 등 다 해준다.
  26. useMemo는 렌더링 방지가 아닌, 성능 최적화용이다. 즉, 굳이 렌더링을 막는것은 성능 최적화의 범주가 아니다.
  27. gitlab에서 ci돌릴 때는, gitlab runner를 띄워줘야된다.
  28. github은 github action으로 쉽고 편하게 잘된다.
  29. synology는 NAS를 만들어주는 회사다. 그리고 엄청나게 구린 CPU가 들어가있다.
  30. 읽기힘든 코드도 어떤 의도가 담겨있다. 오늘따라 내가 그냥 글을 읽기 싫은건 아닌지 스스로 점검해봐야 한다.
  31. eslint는 생성된 AST를 기준으로 검사를 한다
  32. 클라이언트에서도 나름의 db가 있다.
  33. jest로는 canvas에 대해 테스트하기 힘들다, e2e로가면 훨씬 작성이 쉬워지긴 하는 것 같다.
  34. cypress는 공식문서가 정말 별로다.
  35. 엣지서버에서 이것저것 간단한 컴퓨팅을 더 해줄 수 있다.
  36. rehydration을 할 때에는, API 슬라이스에는 적용시키지 않는 것이 좋다.
  37. 프록시객체를 통해 특정 객체의 변경사항을 인지시킬수 있다.
  38. 리시버의 프로토타입의 프록시객체에 this로 메소드가 바인딩 되어있으면, 실행주체가 애매모호 해 진다.
  39. reflection을 통해 애매모호한 리시버를 제대로 바인딩시켜줄 수 있지만, 잘 쓰일 것 같지는 않다.
  40. 스토리북으로 UI를 쉽게 체크할 수 있다.
  41. 자바스크립트 런타임에서는 Turbo모드가 있다.
  42. Optimize될 수 있는 코드로 잘 작성하면 Turbo모드를 통해 빠르게 실행되지만, 통상 optimizing은 자주 취소된다.
  43. wasm는 optimizing의 취소가 거의 없다.
  44. Teachable Machine등 tensorFlow.js를 사용하면 웹에서 학습을 시킬수 있다.
  45. CUDA를 직접 호출하기 어려운 웹에서는, 쉐이더로 꼼수를 써서 잘 넘길 수 있다.
  46. WebGPU에서는 GPGPU가 가능하다.
  47. three.js에서도 이제, compute()함수 지원으로 webGPU의 GPGPU활용이 가능하다.
  48. tensorFlow.js등에서 이미 webGPU에 대한 기능을 넣어두었다.
  49. view-transition api가 이제는 리액트에서도 된다.
  50. VAC패턴을 통해서 .tsx에서의 뷰로직을 정말로 분리할 수 있다.
  51. SRP원칙을 단일 함수가 하나의 동작을 해야한다고 오해하는 사람들이 많다.
  52. 현재 우리 레포의 코드는, 우리의 의사소통방식의 결과물을 보여준다.
  53. 리액트 18에서 동시성 출현, 외부 상태관리 라이브러리들으 tearing발생 위험이 있어 useSyncExternalStore을 넣기도 한다.
  54. mobx등 외부 라이브러리들은, 자체적으로 useSyncExternalStore을 넣어두었다.
  55. 개발자들의 동일 실수가 반복된다면, 시스템에 문제가 있는 건 아닌지 생각 해 봐야한다.
  56. eslint, pullRequest 템플릿, husky, push block 등으로 안전망을 구축할 수도 있다.
  57. 복잡한 시스템에 대한 설정은.. 구성원들의 성격, 현재 상황 등을 고려하고 완만한 합의를 통해 설정되어 나가야 한다.
  58. pre-processor를 통해 더 일관성있는 경험을 줄 수 있다.
  59. faker.js로 mocking data를 쉽게 만들 수 있다.
  60. faker.js 개발자는 아파트에서 사제폭탄을 제조하다 붙잡히기도 했다.
  61. 내게는 어렵지만, 멋있어보였던 TDD도 개발 방법론중 하나일 뿐이다.
  62. git 명령어를 통해 내가 전체프로젝트에서 몇줄이나 기여를 했는지 알 수 있다.
  63. cherry-pick으로 쉽게 쌓아올릴 수 있다.
  64. 적절한 rebase는 코드리뷰하는사람을 편하게 해준다.
  65. react-flow로 노드시스템을 쉽게 만들 수 있다.
  66. TS프로젝트 위에 JS를 올리는건 쉽다.
  67. MD5, SHA등 암호화된 해쉬알고리즘은, 그렇지 않은 알고리즘보다 10배이상의 차이가 난다.
  68. 놀랍게도 JSON.stringify할때, 파일의 변형이 일어난다.
  69. Automatic Batching은 17버전부터 되기는 했지만, 18버전부터 제대로 돌아갓다.
  70. Suspense도 17버전부터 있었지만, production에는 사용이 권고되지 않았다.
  71. 애니메이션의 weight를 조절해서 여러개의 애니메이션을 섞을수도 있다.
  72. GLB는 GLTF와 완전한 동일한 형식이지만, GPU가 바로 읽을 수 있는 binary 형태로 치환한 것이였다
  73. HDRI env는 백그라운드만 끄고, 빛 정보만 이용할수도 있다.
  74. mouseDown, mouseMove, mouseUp를 따로 등록하지 않고, Down시 Move와 Up에 대한 이벤트를 그 때 등록해주고 이벤트를 제거해주는 방식으로 다양한 경우의 수를 customizing할 수 있다.
  75. GPU가 없으면 모니터에 아무것도 보이지 않는다.
  76. 복잡한 요구사항이 있을수록 babylon.js는 three보다 강력하다.
  77. issue남긴게 함께 머지되면, (고작이걸로 나도?(꾸벅))컨트리뷰터가 된다. 어차피 무얼 컨트리뷰트 했느냐가 더 중요하다.
  78. 내 리액트 앱도, PWA를 통해 ios와 안드로이드 앱스토어에 올릴 수 있다.
  79. 게임시장이 영화시장보다 훨씬 크다.
  80. attach를 통해, 컴포넌트를 상위 컴포넌트에 prop으로 붙여줄 수 있다.
  81. forwardRef로 ref를 내려줄 수도 있다.
  82. 몽고 DB비밀번호에 @골뱅이 문자를 넣을때는 %40으로 넣어주어야 한다.
  83. SPIR-V위에 GLSL과 WGSL이 있다.
  84. MUI에서 popper은 position fixed가 사용가능하다.
  85. MUI에서 popover은 항상 anchor를 필요로 한다.
  86. MUI의 Menu도 내부적으로 popover엘리먼트를 가지고 있다.
  87. MUI를 커스터마이징 해서 쓰려다가, 숨어있는 잔버그에 시간을 빼앗길 수 있다.
  88. console.trace() 로 범인을 찾을 수 있다.
  89. beforeunload 이벤트로 사용자가 브라우저를 나가기는 감지할 수 있다.
  90. 브라우저 정책상 beforeunload는 커스터마이징이 안된다.
  91. 브라우저 정책상 특정사이트에 접속하자마자 음악이 나오게 할 수 없다.
  92. network-size를 보면 해당 데이터가 캐슁되어있는지 쉽게 볼 수 있다.
  93. Promise.all() 메소드로 프로미스객체들을 기다렸다가 모아서 처리해줄 수 있다.
  94. pnpm(performant npm)과 private npm은 다르다.
  95. code Artifact 혹은 verdaccio로, npm이 아닌곳에 private하게 배포할 수 있다.
  96. 블렌더에서 보여지는것은 내부(선택가능한) 렌더링 엔진에따라 완전히 다르다.
  97. commonJS 방식은 런타임까지 가봐야 (동적으로) 라이브러리를 불러올지 말지 결정할 수 있기 떄문에, tree shaking이 제대로 이루어지지 않는다
  98. useLayoutEffect로 깜빡임 현상을 줄일 수 있다.
  99. 색상이 (-0.1, -0.9 등)음수면 전부 0으로 처리된다.
  100. 애플 홈페이지의 애니메이션들은 png의 연속으로 되어있었다.
  101. 모달쓸때, createPortal로 가는게 편하다.
  102. tagged template literal로 평가된 값을 따로 받을 수 있다.
  103. styled component에서 dev는 node.appendChild로 추가된다
  104. styled component에서 prod는 insertRule방식으로 추가된다
  105. perspective카메라는 원근감이 있지만 orthogonal카메라는 원근감이 없다.
  106. instancing과 batching은 다르다.
  107. instancing은 무조건 이득이고, dynamic-batching은 극히 제한적인 상황에서 아주 조금 이득이다.
  108. 이미지에 alt를 잘 넣어주자
  109. 소스맵이 잘못 생성되기도 한다.
  110. null처리에 대해 다들 다양한 입장을 가지고 있다.
  111. rayTracing과정은 일반 그래픽파이프라인의 역순으로 생각하면 편하다.
  112. modifier로 쉽게 모델링을 할 수 있다.
  113. GLTF를 GLB로 압축할 때, ASCII(4바이트)를 base64값으로 바꾸기 때문에 33%의 용량차이가 난다. (8/6 배 차이남)
  114. uniformBuffer혹은 storageBuffer를 이용해, 쉐이더 내의 값을 조작해 줄 수 있다.
  115. 나도모르는 사이에 terser에서 이것저것 실행된다.
  116. scroll-Y액션을 통해, scroll-X의 값도 조절해줄수 있다.
  117. 핀토스를 해본 사람들은 OS 스케쥴링 게임을 더 재미있게 할 수 있다.
  118. 패키지 설치 전, Production에서도 필요한지 생각하고 설치하자
  119. SWC는 Rust로 작성되어있고, 병렬처리가 가능하기때문에 빠르다
  120. babel플러그인을 사용하면, 스타일컴포넌트르 쓸 때,개발자가 작성한 원래 이름을 개발자도구에서 볼 수 있다.
  121. npm 7버전부터는 피어 의존성 충돌에 대해 에러를 뱉아준다.(–legacy-peer-deps)


🚀마치며

입사전의 신입 개발자때는 무엇이든지 만들 수 있다고 (패기롭게)생각했지만, 어떤 버그던 하루내에 잡을 수 있다고 (호기롭게)생각했지만, 일을 하며 나의 부족함들을 속속들이 알 수 있었다. 유지보수가 용이하며 남들도 읽기 좋은코드들을 어떻게 잘 만들지에 대한 이해가 부족했던 것 같다. 사실 이해의 영역인지도 모르겠다. 고민이 부족했던 것 같다

신입에서 책임을 지는 자리로 올라갈수록, 좋은구조에 대한 나름의 철학이 생기고, 이를 통해 다른 사람들에게 긍정적인 영향을 미칠 수 있는 능력이 필요해 지는것이 아닌가 싶다.

지금 열심히 해두어야, 나중에 다른사람들에게도 타당한근거와 함께 좋은방향을 옵션중 하나로 내밀 수 있으며, 신뢰를 얻을 수 있지 않나 싶다.

실력이 없으면 신뢰를 얻기 어려운 분야 중 하나인 것 같다. 신입의 시각에서는 그러한 것 같다. 하지만, 구글과 GPT에 검색하면 1분안에 얻을 수 있는 그것들, 그걸 무얼 조금 더 알았느냐가 아니라, 이것들을 쌓아 좋은 식견을 만들어 나가는것이 핵심이라고 생각한다.

오만했던 (예비)개발자가 어떻게 바뀌어나가는지 조금씩 꾸준히 기록해볼까 한다.


🌜 Thank you for reading it. Please leave your comments below😄

맨 위로 이동하기

career 카테고리 내 다른 글 보러가기

댓글 남기기

최근 글 10 개 :)