3개월 간 안드로이드 개발을 배우고 어쩔 수 없는 회사 사정으로 나오게 된 후 앱 개발을 계속 배우며 나아가는 것과 웹으로 다시 시작하는 것을 고민했었고 웹으로 넘어가기로 마음먹은 후 다시 리액트나 CSS에 익숙해지기 위해 블로그를 만들어 보기로 결심했다. 그리고 면접을 보면서 지금 당장 서비스가 되는 사이트는 포트폴리오로서 가치가 충분하다고 생각했었다.

사실 내가 만들어 보자고 생각했던 것은 아니고 같은 회사 동기였던 분이 블로그를 만들고 배우는 것이 많다고 하셔서 만들게 되었고 기술 스택이나 가끔 하면서 모르는 부분들을 조언받을 수 있어서 큰 도움이 되었다.

그리고 결과적으로 모르는 것들을 많이 배울 수 있었고 라이트 하우스와 같은 지표를 기반으로 개발하니 개발 역량이 향상된 것 같다.

프론트 : Next.js, TailwindCSS, Redux, Redux tool kit, SWR, react-md-editor, react-markdown

백 : Next.js, Prisma

배포 : Vercel(프론트), PlanetScale(DB), CloudFlare(DNS, CDN, SSL)

리액트를 사용하는 것을 잊어버리진 않았지만, 자신은 없었기 때문에 자신감을 회복하는 것이 최우선이라 생각했다.

그리고 useMemo, useCallback과 같은 사용할 일이 거의 없는 훅을 한번 사용해 보는 것도 내가 모르는 것을 배울 기회가 될 것 같았다. 재활용성에 중심을 두고 커스텀 훅, 함수, 컴포넌트 작성에 신경을 써봤다.

useRef의 사용 방법이 가상돔을 조작하는 것인지만 알고 있던 것을 컴포넌트의 전 생애주기를 통해 유지되는 것과 같이 모르던 개념도 알게 되었다.

useMemo의 경우 오히려 잘못사용하면 앱의 메모리를 잡아먹어서 불이익을 받을 수 있고 리액트팀에서도 오히려 사용을 권장하지 않는다. 모든 훅이나 기술들의 기능을 다 익히는 것은 불가능하고 내가 알고 있는 기능들을 적재적소에 사용하면서 꼭 필요하다면 그때 필요한 것을 알게 되면 된다고 생각하게 되었다.

SSR, SSG는 회사에서 인턴으로 있었을때 과제로 진행한 적이 있었는데 그때 이걸 왜 사용하는지 모르겠어서 왜 좋은지 뭐가 안좋은지 알고 싶었다.

SSR과 SSG의 차이점과 그 이점들을 알게되었다. 그 외에도 SSG의 fallback 속성에 따라 SSG가 SSR을 이용하는 것, SSR을 사용한다면 어찌되었든 사용자들은 빈 화면을 보고 있어야하는데 이것을 어떻게 해결해야할 것인가에 대한 고민도 하게되었지만 결론은 내리지 못했고 SSR에서 사용하는 코드는 이름과 일치하게 서버에서만 사용되는 함수임으로 따로 api를 만들어서 사용하지 않고 함수로 결과물을 내는 것이 가능하다는 것을 알게 되었을때 덕분에 CSR과 SSR의 차이점을 체감할 수 있어서 조금 더 명확하게 알게되었다.

Hydration 에러를 많이 마주치게 되었는데 클라이언트에서 생성하는 new Date가 서버에서 내려주는 시간 정보가 달라서 나는 에러였는데 이건 생각도 못했던 점이라 이제 좀 더 벡엔드와 프론트는 조금 더 거리가 있다는 것을 깨달게 되었다.

사실 이번 프로젝트에서 상태관리가 필요한 일은 없었고 내가 여태까지 개인 프로젝트나 팀 프로젝트를 진행하면서도 context api가 해주는 역할 이상으로 상태관리가 필요한 일은 없었다. 그런데 지금 리액트를 배운지 반년이 넘어가는데도 Recoil 강의를 듣는 것 이외에 한 번도 사용해본 적이 없다는 것을 알게 되고 한번은 사용해 봐야겠다고 생각해서 기술 스택에 넣은 후에 사용할 곳을 찾았고 사용하게 되었다. tool kit을 사용하긴 했지만, 생각보다 어렵지 않았다.

라이브러리에 라이브러리를 추가해서 사용한다는 것이 신기했었지만 리덕스를 사용하는 것보다 난이도가 엄청나게 낮아진다는 것을 알게 되었다. 생각보다 어려운 것은 없었지만 처음이라 코드를 처음부터 내가 작성할 수 없었지만, 공식문서를 따라가면서 작성해 개념은 잡을 수 있었다. 확실히 사용하니까 전에는 못했던 기능을 추가할 수 있어서 재미있는 경험이었다. 하지만 지금까지 상태관리가 엄청 중요하다거나 많이 사용하는 상황이 나온다는 것은 공감하지 못했다.

상태 관리와 같이 너무 눈에 보인 게 느리거나 작동하지 않는 것이 보이지 않는 한 성능에 대한 지표가 없어서 그냥 넘어갔었지만, 이번에는 라이트 하우스라는 웹의 성능 지표를 알려주는 툴을 알게 되어 도입하고 신경 써서 코드를 생각하며 작성할 수 있었다.

내가 지금 어떤 점에서 잘못을 하고 있고 개선점을 알려주기 때문에 쉽게 문제점을 인지하고 고칠 기회가 생겼고 점수를 메긴다고 하니 의욕이 생겼다. 앞으로도 라이트 하우스나 다른 지표나 어드바이저가 있다면 사용할 의향이 생겼다.

tailwind가 모바일형 디자인에 더 적합하다는 소문을 듣고 이번엔 반응형을 무조건 공을 들이며 진행했다. 기준은 내가 가진 갤럭시 S10, iphone13 pro, 크롬 반응형에서 제공해주는 기기들..

웹만 생각하면서 조금씩만 줄이며 반응형을 했었던 때와 다르게 한 땀씩 다른 것을 비교해가면서 다른 CSS를 하는 것 같아 힘들 때도 있었지만 이 정도면 코드를 새로 작성하는 수준은 아니라서 괜찮았었다.

더 집중해서 반응형도 반응형이지만 화면의 크기에 따라서 정보를 어떤 식으로 나타낼지를 생각해볼 기회였고 이걸 화면의 반응형뿐만 아니라 사용하는 사용자에 따라 제대로 필요한 정보를 잘 보이고 내주는 것이 내가 하는 일에 대한 책임이라고 다시 상기할 수 있었던 것 같다.

솔직히 포폴용으로만 사용하려고 했는데 생각보다 재밌게 만들기도 했고 열심히 만들어서 애정이 가게 되었고 계속 기능을 추가하고 유지 보수를 하며 이용할 것 같다.

Next Tailwind 와 같은 코어 스택은 한번은 배우고 들어가는 거라 모르는 것도 많지 않을 것이고 어렵지도 않을 거라고 생각했지만 내가 직접 설계하면서 만들어보니 새로운 개념을 배우는 것도 많았고 CSS도 생각보다 어려웠다. 다른 개발자들이 왜 사이드를 하면서 역량을 키워내 갈 수 있는지 알 수 있었고 나도 가끔은 내가 필요하거나 재밌어 보이는 기술들이 나온다면 남는 시간에 사이드를 해보면 좋을 거 같다고 생각된다.

프론트는 앱을 배우다가 와서 처음엔 좀 헤매며 시작했지만, 일주일 정도 지나자 적응이 되었고 내 기준에 의하면 잘 적응이 완료되었다. SSR을 이용해 보는 것은 처음이라 새롭게 배우는 것들이 많아서 좋았고 라이트 하우스를 도입하면서 LCP FCP 같은 개념들도 알게 되어서 최적화라는 것을 하기 위해선 어떤 것들이 필요한지 이런 점에 있어서 Next가 왜 편한지 알게 되었다. ex) next/image

만약 더 추가할 것이 있다면 jest나 storybook을 이용해 테스트 코드를 작성해볼 것 같다.

벡엔드는 ORM을 사용해 데이터를 가공해 보내주는 것뿐이지만 생각보다 코드를 깎았고 예외 상황, 많은 상황에 대한 분기 등 복잡한 알고리즘이 필요하다는 것을 알게 되어서 적어도 일주일에 한 번쯤은 문제를 계속 풀어야겠다고 생각했고 생각보다 재미있었다.

배포는 DX가 엄청나다는 vercel, planetscale, cloudflare를 사용했는데 확실히 편하지만, 만약 돈을 내게 되는 상용으로 넘어간다면 비용이 엄청 비싸지기 때문에 cloudflare를 제외하고는 확실히 상용 서비스에서는 사용하지 않을 것 같다.

하지만 cloudflare는 비용도 싸고 개발자에게 편안한 기능들을 많이 제공해주고 있어서 인기가 높아지고 있어서 사용하는 회사들도 많아질 것 같다. 확실히 아무것도 안 하고 vercel, cloudflare를 서로 도메인을 통해 연결만 한다면 DNS, CDN, SSL을 한 번에 처리할 수 있고 페인트 시간까지 줄여주는 기능까지 있어 좋았다.