들어가며우연히 HTTP 완벽 가이드를 번역하신 분의 블로그를 발견했다. 최근 이 책을 읽기 시작했는데, 어딘가에서 스쳐 지나가며 본 "HTTP 완벽 가이드 읽는 법"에 관한 글이 생각나 검색했다. 검색 결과 가장 상단에 있던 글이 바로 그분의 글이었다. 단순히 번역가가 아니라 개발자로서의 면모가 돋보였는데, 다른 글들을 읽어보니 이분은 진정한 개발자라는 느낌이 강하게 들었다. 그렇게 여러 블로그 글을 읽어 내려가던 중, 한 번쯤 내가 고민했던 내용을 다룬 글이 있어 나도 학습한 내용을 짧게나마 정리해보고자 한다.깔끔하게 커밋하기참된 개발자란 꼼꼼해야 한다는 생각이 든다. 이전에 나의 사수 역할을 해주셨던 분도, 현재 사수 역할을 맡고 계신 분도 대단한 실력자이시다. 두 분의 공통점은 실력도 뛰어나지만 무..

최근 NestJS를 학습하기 시작했다. 이유는 크게 두 가지 정도가 있는데, 1. 회사 사수분이 풀스택이셨다. 사실 백엔드 개발자라고 말하는게 맞겠지만, 리액트도 어느정도 할 줄 아는 분이셨다. 다른 팀들과의 커뮤니케이션은 원래 사수분이 모두 도맡아 하셨는데.. 이직을 하시고 나선 많은 커뮤니케이션을 담당하고 있다. 웹개발자가 아닌 다른 팀원분들은 프론트엔드 / 백엔드에 대한 이해가 딱히 없으셨다. 나한테 백엔드는 너무 먼 영역이라 생각됐지만 ML개발자 분들에겐 웹개발잔데 뭘 분류해? 이런 느낌으로 다가오나 보다. 사수분은 모든 이슈에 대해 다른 팀 팀원들에게 이런 저런 이유들을 잘 설명해주셨다. 하지만 요즘 나한테 이런 저런 질문을 해주시다 보면 나는 종종 "이건 백엔드 문제라.. 다른 분한테 여쭤보세..

코드스쿼드를 수료하고 약 1년의 시간이 지났다. 취준이라는 핑계로 그 동안 어떠한 회고도 하지 않았는데, 이제 입사일이 확정이 되어 마음의 어느정도 여유를 찾아 지난 여정을 정리해보고자 한다. 돌아볼 회 回 , 돌아볼 고 顧 다른 개발자 분들의 블로그를 돌아다니다 보면, '회고' 라는 단어를 많이 접한다. 회고는 어떤 뜻일까? 일반적으로 회고回顧  와 회상回想은 비슷한 의미로 쓰인다. 나는 한자를 잘 모르지만 회상은 의미 그대로 지나간 일을 돌이켜 생각해본다는 뜻인 반면, 회고는 과거를 돌아보며 마음에 새기고 반성한다는 의미가 더해져있다고 한다.   많은 시행착오가 있었다. 개발에 대한 공부법에도, 나라는 사람의 가치관을 정립하는 데에도 일직선으로 걷진 못했다.  학창 시절에 시험을 보고나서 틀린 문제를..

들어가며 이슈트래커는 webpack으로 구성돼있었다. CRA의 너무나도 느린 dev server 구동 속도를 개선하고자, 또 번들러를 학습하려는 목적으로 직접 webpack으로 개발 환경을 구성했었다.  webpack으로 구성된 환경은 CRA와 비교했을 때 어느정도 차이는 있었다. 약 12초 정도 걸리던 dev server 구동 시간을 9초대로 줄일 수 있었다.  하지만 요즘 CRA는 새로운 프로젝트에서 아무도 사용하지 않고, 다른 프로젝트에서 직접 webpack을 구축하는 경우는 적었다. Next가 아닌 이상 대부분 vite를 이용해 프로젝트 환경 설정을 했다.  다른 프로젝트에서 vite의 개발 서버 시작 시간은 굉장히 짧다. webpack과 비교해서 짧은 수준이 아닌 10배 정도의 차이를 보인다. ..

들어가며기존에 리액트로 만들어졌던 오놀을 넥스트로 포팅을 하면서, 그리고 웹 성능 지표에 대해 학습을 했기에 성능을 측정해보고 개선점이 있는 곳들은 개선을 해보고 싶었다.  Lottie 파일 최적화하기포텐데이에서 진행했던 프로젝트였기에 거의 일주일 안되는 기간동안 프로젝트를 만들어야 했다. 랜딩 페이지의 애니메이션을 디자이너분이 많이 고심하면서 수정사항이 잦았기에 매번 복잡한 애니메이션의 CSS를 수정하는게 부담으로 다가왔다. 디자인 수정 요구 사항을 빠르고 정확하게 반영하기 위한 방법이 없을까 찾아보다가 로띠를 사용하는게 가장 적절하다는 생각이 들었다. 하지만 포텐데이는 꽤 예전에 진행했고, 지금은 다들 바쁘시기에 디자이너 분에게 로띠 파일의 png 파일을 webp로 변경해달라고 말씀 드리기 어려웠다...

들어가며오픈소스에 컨트리뷰트를 하면서 테스트 코드의 중요함을 느낀적이 있다. 내가 진행한 프로젝트와는 비교할 수 없이 많은 코드양과 사용자 수. 내가 작성한 코드의 사이드 이펙트가 미칠 영향을 가늠하기가 어려웠다. 그 때 테스트 코드의 힘을 많이 느꼈다. 내가 작성한 코드가 다른 수백명의 사람이 작성한 코드에 영향을 끼치지 않고 + 내가 수정/구현하고자 하는 부분이 정상적으로 동작하는지에 대한 자신감을 줬다.  오놀에서 접근성 개선 작업을 하며 문득 UI에 어떤 변화가 있진 않을까? 키보드 대응 같은 기능적인 측면을 추가할 때 다른 기능이 잘 동작하지 않으면 어떡하지?라는 불안 요소가 있었다. 오픈 소스에서 내게 자신감을 줬던 테스트. 내가 불안한 포인트들을 테스트를 통해 직접 확인하지 않아도 제거하고 ..