Lucy.SpaceLucy.Space.

cover

LUCY.SPACE.

1. 프로젝트 개요

기간: 2024.10 - 2024.12

인원: Frontend(1명)

설명: 개발 블로그 및 포트폴리오 제작 개발

링크: 깃허브 | 배포페이지


2. 담당 역할

프론트엔드 개발

3. 개발 환경 및 기술 스택

Frontend: Next.js, React.js, Tailwindcss, TypeScript
배포: Vercel

4. 주요 기능

✅ Next.js 하이드레이션 시 발생하는 다크 모드 깜빡임 문제 해결 ⇒ 하이드레이션 이전에 로컬 스토리지에서 테마 값을 불러오도록 스크립트 주입하여 깜빡임 방지
✅ Notion API를 활용하여 포트폴리오 데이터를 동적으로 가져와 자동 동기화
✅ 메인 페이지에 Pixi.js를 활용하여 그래픽 및 애니메이션 효과 구현
✅ 메타 태그, 오픈 그래프 설정 등을 통해 검색 최적화 개선

5. 기술적 도전 & 해결 방법

🚀 문제 1: 포트폴리오 정보 수정 및 추가 시 유지보수 비용 증가

📌 문제 상황:

프로젝트 및 이력서를 수정할 때마다 포트폴리오 페이지도 별도로 수정해야 하므로 유지보수 비용 증가

📌 원인 분석:

Notion을 기반으로 이력서와 포트폴리오를 작성하지만, 수정이 발생할 경우 포트폴리오 페이지도 직접 수정한 후 배포해야 하는 비효율적인 과정이 필요함.

🎯 해결 과정 및 적용한 접근법:

1. Notion SDK를 활용하여 수정 프로세스 간소화

Next.js가 Notion SDK를 사용한 페이지를 Static 페이지(SSG)로 처리
Notion에서 수정해도 즉시 반영되지 않음
자동 동기화가 불가능하여 유지보수 비용 증가

🚀 문제 2: Notion 이미지 로딩 최적화 (LCP 10s → 2.3s)

📌 문제 상황:

Notion API로 호출하는 이미지 URL 사용 (LCP 10s)
DevTools 분석 결과: 총 이미지 로딩 시간 2.84초 중 2.82초가 API 응답 대기 시간

🎯 해결 과정 및 적용한 접근법:

✅ 1. Vercel Edge 네트워크 사용 (LCP 8s → 6.3s)

프록시 이미지 API 도입하여 Notion S3 URL 대신 Vercel Edge 네트워크 활용
priority 속성 추가하여 중요한 이미지가 먼저 로딩되도록 설정
API 라우트에서 캐싱(stale-while-revalidate 캐싱 전략) 적용

✅ 2. API 응답 대기 시간 문제점 찾기 (LCP 6.3s → 4.8s)

Next.js next/image 비활성화 후 테스트하여 성능 영향 분석
프록시 서버를 통한 이미지 요청 방식이 병목이라는 점 발견
기본 img 태그로 변경하여 불필요한 프록시 경유 없이 직접 요청

✅ 3. Cloudinary 라이브러리 사용 (LCP 3.8s → 2.3s)

이미지 자체의 최적화 부족으로 파일 크기 및 로딩 속도 문제 발생
Cloudinary를 활용하여 이미지 저장 시 크기 조정 및 WebP 변환 적용
Cloudinary CDN을 통해 글로벌 엣지 서버에서 캐싱하여 성능 최적화