결정 01
검증 규칙을 한 벌만 쓴다
- 문제
- 이전 프로젝트에서는 클라이언트와 서버에서 각각 정규식으로 검증했습니다. 규칙이 두 벌이라 한쪽만 고치는 실수가 나기 쉬웠고, 코드도 길었습니다.
- 선택
- Zod 스키마를 하나 정의하고 클라이언트 폼과 서버 처리에서 같은 스키마를 임포트해 썼습니다.
- 결과
- 코드가 짧아졌고, 규칙이 어긋날 여지가 사라졌습니다. 타입까지 스키마에서 뽑아 쓸 수 있다는 점이 가장 큰 이득이었습니다.
01개요
취업을 위해 만든 포트폴리오 사이트입니다. 결과물 자체보다는, 그 시점에 공부하고 있던 것들을 실제 프로젝트에 적용해 보는 자리로 삼았습니다.
당시 익히고 있던 것이 Zod와 Docker였습니다. 이전 프로젝트에서 문의 폼 검증을 정규식으로 직접 짰던 기억이 있어, 이번에는 Zod로 클라이언트와 서버 양쪽을 같은 스키마로 검증해 보기로 했습니다. Docker는 개발 환경과 배포 환경을 분리해 구성하는 연습이었습니다.
그리고 Lottie 애니메이션을 넣었다가 성능 문제를 만났습니다. 애니메이션 파일이 생각보다 커서 페이지를 새로고침할 때마다 다시 받아 오느라 초기 로딩이 눈에 띄게 느려졌습니다. 이 문제를 해결하는 과정이 이 프로젝트에서 가장 많이 배운 부분이었습니다.
devkbs는 이 사이트의 데이터를 물려받되 구조와 디자인은 전부 새로 만든 후속작입니다.
02기술 결정
문제가 무엇이었고, 무엇을 골랐고, 그래서 어떻게 됐는지.
결정 02
무거운 애니메이션 데이터를 세션에 캐시한다
- 문제
- Lottie JSON이 커서 페이지를 새로고침할 때마다 다시 받아 왔습니다. 초기 화면에 있는 애니메이션이라 로딩 지연이 그대로 첫인상이 됐습니다.
- 선택
- 처음 받은 데이터를 Session Storage에 저장하고, 이후 로드에서는 저장된 것을 먼저 쓰도록 했습니다.
- 결과
- 새로고침 시 재요청이 사라져 초기 로딩이 개선됐습니다. 이때 '보기 좋은 것에도 비용이 있다'는 감각을 얻었습니다.
결정 03
개발·배포 환경을 Docker로 나눠 본다
- 문제
- Docker를 학습 중이었지만 튜토리얼만으로는 실제 쓰임새가 손에 잡히지 않았습니다.
- 선택
- 개발용과 프로덕션용 Dockerfile을 따로 작성하고 compose로 실행 환경을 구성해 봤습니다.
- 결과
- 이미지 레이어와 빌드 캐시가 왜 중요한지 직접 겪으며 이해했습니다. 배포 환경을 코드로 남긴다는 개념도 이때 잡혔습니다.
03주요 기능
Zod 기반 문의 폼
클라이언트와 서버가 같은 스키마로 검증하고 Nodemailer로 메일을 보냅니다.
Lottie 애니메이션 + 캐싱
Session Storage에 애니메이션 데이터를 캐시해 재요청을 없앴습니다.
Intersection Observer 스크롤 연출
스킬 섹션이 화면에 들어올 때 순차적으로 나타납니다.
Weather API 연동
현재 날씨를 가져와 화면에 표시하는 소소한 장치.
Docker 환경 구성
개발용과 배포용 이미지를 분리해 구성.
04화면
Desktop
Mobile · 반응형
01
02
03
04
05회고
개인 프로젝트는 '배우고 있는 것을 실제로 써 보는 자리'로 쓸 때 가장 효율이 좋다는 걸 알게 됐습니다. 튜토리얼을 따라 하는 것과, 내 프로젝트의 실제 문제에 적용하는 것은 남는 것이 다릅니다.
애니메이션이나 시각 효과는 비용이 없는 것처럼 보이지만 그렇지 않습니다. Lottie 파일 하나 때문에 첫 화면이 느려지는 걸 보고, 이후로는 시각 요소를 넣을 때 용량과 로딩 시점을 먼저 확인하게 됐습니다.
이 사이트를 만들고 2년 뒤에 devkbs를 다시 만들면서, 그때의 나와 지금의 나 사이에 무엇이 달라졌는지 확인할 수 있었습니다. 그때는 '무엇을 쓸 수 있는가'를 보여주려 했다면, 지금은 '무엇을 왜 그렇게 결정했는가'를 남기려 합니다.