포트폴리오 페이지 (I AM INWOO) 회고

개발 시작 : 2023년 9월 20일

배포 시작 : 2023년 10월 12일 (총 22일)

https://github.com/stripy1026/portfolio

GitHub - stripy1026/portfolio

 

 

 

FRONTEND:

Next.js 13.4.19 (App router)

react 18.2.0

typescript 5.2.2

tailwindcss 3.3.3

 

DB:

mongoose 7.6.1 (MongoDB ODM)

typegoose 11.6.0

 

 

---

 

최초 배포 성능 테스트

 

 

---

 

포트폴리오 기획 때 고민했던 것

1. 프론트엔드 개발자는 웹 페이지를 만드는 게 직업인데, 프론트엔드를 희망하면서 포트폴리오를 웹 페이지로 만들지 않는 것은 뭔가 좀 이상하지 않나?

2. 인터넷에 돌아다니는 포트폴리오들을 많이 확인해 봤는데, 다들 랜딩페이지에 공을 들였다. 나도 랜딩페이지를 잘 꾸미고 싶은데, 남들이 다 하는 애니메이션 말고 나만이 가진 특색을 살리고 싶다.

 

 

랜딩 페이지 제작

곧바로 생각이 떠올랐다. 물리학과 재학 시절, 나는 뇌과학에 아주 관심이 많았다.

그래서 통계물리를 공부하기 위해 통계물리 연구실에 들어갔고,

지도교수님은 나에게 졸업논문으로 Abelian Sandpile Model 을 undirected graph 에서 시뮬레이션 했을 때 기존 모델처럼 Self-Organized Criticality 를 보이는지 아닌지를 증명해보는 것이 어떠냐는 말씀을 하셨다.

비전공자를 위해 아주 간단히 설명하자면, 모래상자에 모래 알갱이를 하나씩 떨어뜨릴 때, 모래가 어느정도 쌓이다가 무너지게 되는 현상이 언뜻 불규칙하게 일어나는 듯 하지만, 통계물리적으로 어떤 패턴이 있다. 이것을 실생활에도 적용시켜서 뇌의 학습 과정이나, 복잡한 도로의 교통체증, 인터넷의 네트워크 등 서로 상호작용하는 개체가 굉장히 많은 곳에서 패턴을 분석하고 연구할 수 있다.

그래서 나는 Abelian Sandpile Model 을 공부했고, 그 시절엔 코딩에 대해 전혀 모르는 상태였지만,

어떻게든 파이썬으로 꾸역꾸역 모델을 만들어 시뮬레이션을 했었다.

그리고 그 때 모래상자가 쌓이고 무너지는 모습이 심미적으로도 굉장히 아름답다고 생각했다.

 

그래서 지금은 그 때와 비교해 코딩 실력 자체가 늘었으니, 이것을 자바스크립트로 구현해서 랜딩 페이지에서 시뮬레이션 하는 모습을 보여주면 좋겠다는 생각이 들었다.

처음 시뮬레이션을 돌렸을 때, 검은 배경에 흰색 모래알갱이가 쌓이다가 무너져서 주변으로 퍼지는 모습이 마치 우주가 팽창하는 모습과 비슷하다는 생각이 들었고, 아싸리 더 우주처럼 보이기 위해 알고리즘과 인자들을 조금 조작한 뒤 랜딩 페이지 제목을 UNIVERSE 라고 지었다.

 

 

UI / UX 와 디자인 고민

이번 포트폴리오 페이지를 만들면서 가장 많이 실력이 늘었던 부분이다.

나는 이력서는 PDF 로 담백하게 기술적인 정보들을 담고, 포트폴리오 페이지는 최대한 사람들을 사로잡을 수 있게 구현하는 것을 목표로 했다.

따라서 포트폴리오 페이지를 만들기 위해 내가 기존에 가졌던 CSS 실력을 월등히 키워야 함을 느꼈다.

내 첫 웹 프로젝트 때는 CSS 라이브러리로 emotion 을 사용했었고,

두 번째 1인 토이프로젝트 때는 tailwindcss 를 사용했었다.

그 때 나는 CSS 실력이 매우 처참해서 디자인을 거의 버렸음에도 불구하고, tailwindcss 의 강력함과 편의성을 체감한 상태였다.

따라서 이번 프로젝트에서는 tailwindcss 의 공식문서를 깊게 탐독하며, 내가 이것으로 할 수 있는 기능들이 무엇인지 전부 읽고 적용시키려 노력했다.

결과적으로, 이번 프로젝트를 개발하며 나는 내 머릿속에 있는 디자인을 웹 페이지로 그대로 구현할 수 있는 CSS 실력을 얻게 되었다.

 

 

공식문서의 소중함

이번 프로젝트로 뼈저리게 느낀 두 번째 소중한 경험.

프론트엔드 기술을 배우기 전, 42에서 약 2년간 C를 공부하면서 내가 느낀 것은,

C의 공식문서들이 너무 너무 빼곡하고 눈이 아파서 읽기가 힘들다는 것이었다. (옛날에 만들어졌으니 이해는 한다)

당시 완전한 뉴비의 입장에서, 나는 자연스럽게 공식문서보다는 구글링을 통한 StackOverflow 와 잡다한 블로그들의 정보를 수집하는 데에 많은 시간을 보냈었다..

따라서 react 와 next.js 를 처음 배울 때에도, 유데미와 인프런의 인강에 많이 의존했고, 부족한 정보들을 자연스레 구글링으로 찾아보게 되었다. (지금 와서 생각하면, 처음 배우는 기술에 친숙해지기 위한 목적으로 인강은 나쁘지 않은 선택이다)

 

하지만 이로 인한 불편함은 점점 쌓이고 있던 차였다.

구글링으로 긁어온 정보들은 outdated 된 경우도 많고, 아예 잘못된 경우도 많고, 나에게 적용되지 않는 경우도 많았다.

따라서 나는 고통을 감내하며 next.js 를 비롯한 내가 사용한 프레임워크와 라이브러리들의 공식문서를 정독할 결심을 하고, 공식 페이지의 docs를 읽기 시작하는데 어라?

각각의 문서들은 버전별로 기능이 깔끔하게 정리가 되어있었고, 찾는 기능을 검색하기도 쉬웠고, 모든 객체들과 함수들의 사용법과 prop들이 아주 가독성 좋게 정리가 잘 되어있었다.

거의 떠먹여주는 수준으로, 내가 원하는 모든 정보들이 그곳에 보기좋게 잘 놓여져 있었다.

나는 이것을 마음껏 읽고, 내 프로젝트에 적용하고, 내 입맛에 맞게 응용하는 데에 아무런 문제가 생기지 않았다.

또한 구글링을 했을 때에는 전혀 설명해주지 않았던 중요한 feature 들, limitation 들이 공식문서에는 낱낱히 적혀있었다.

단적인 예시로, 나는 이전 프로젝트에서 useEffect 를 빈번하게 사용하면서, useEffect 의 return 값에 cleanup 함수를 넣어줌으로써 컴포넌트가 unmount 되기 전 시점 (componentWillUnmount) 에 cleanup 함수를 호출할 수 있다는 사실을 몰랐었다.

 

나는 큰 깨달음을 얻고, 정보를 학습하는 알고리즘을 새롭게 고치게 되었다.

1. 공식문서를 찾아본다.

2. 공식문서를 봐도 이해가 안되거나 정보가 부족한 경우, 구글링을 통해 이해한다.

3. 그럼에도 문제를 해결 못 했을 시, 주변에 물어본다.

 

 

Stable 버전의 소중함

이번 프로젝트를 진행하면서 느낀 세 번째 소중한 경험.

첫번째 Next.js 프로젝트에서 pages router 로 개발을 한 뒤,

다음 프로젝트에서 app router 를 쓸까 pages router 를 쓸까 고민을 했었다.

그리고 공식문서에서 읽은 다음과 같은 문장으로 인해 이번에는 app router 를 쓰기로 결정했다.

The Next.js App Router is a new paradigm for building applications using React's latest features. If you're already familiar with Next.js, you'll find that the App Router is a natural evolution of the existing file-system based router in the Pages Router.
For new applications, we recommend using the App Router. For existing applications, you can incrementally adopt the App Router. It's also possible to use both routers in the same application.

Next 측에서는 app router 를 쓰기를 매우 권장하고 있었다. app router 가 Next.js 가 갈 방향이고, app router 는 이제 안정화 되었으며, pages router 로 개발하던 프로젝트에도 단계적으로 app router 를 적용할 것을 권장하고 있었다.

공식문서를 찬찬히 읽어본 결과, app router 는 기본적으로 서버 컴포넌트를 생성하고, 기존의 방식보다 더 깔끔한 지시문인 'use client', 'use server' 등을 사용한다는 것이 마음에 들었다. app router 를 공부하며 새로운 기능들을 이용해 개발해나갔다. 즐거웠다.

 

버그를 만나기 전까지는 말이다.

사실 자잘한 버그들은 크게 신경쓰지 않았다.

문제는 dev server 에서 자꾸만 Server is running out of memory: restart the node server 에러를 띄우며 종료되는 것이 너무 거슬렸다.

결국 Next.js 의 깃헙에 들어가서 이슈를 찾아봤고, 나는 그곳에서 심연을 보았다.

공식문서에는 적혀있지 않은 큰 그림자가 그곳에 있었다.

특히나 내가 겪고 있는 개발 서버의 메모리 문제에 대한 이슈는, 개발자도 정확한 원인을 찾지 못하고 있는 중이었다.

그곳에는 수많은 이슈 리포터들과, 버그 프로세스가 명확하지 않아서 문제를 찾기가 힘들다는 개발자들의 전쟁이 벌어지고 있었다.

한 가지 다행인 것은, dev server 에서만 이러한 문제가 나타나는 것이었다.

나는 언제 해결될 지 모르는 이 버그를 해결하고 갈 것인가, 개발할 때만 좀 불편하더라도 안고 갈 것인가를 고민했고,

결국 후자를 선택했다.

사실 이 버그를 시간이 오래 걸리더라도 해결했으면 쓸 말이 더 많았을지도 모른다. 혹은 아직도 버그를 해결하느라 배포하지 못했을수도.

앞으로는 프로젝트를 시작할 때 버전 선택에 대해, 내가 정말 꼭 필요한 기능이 있어서 그 버전을 선택하는 지에 대해 고민을 많이 해야겠다.