블로그 프로젝트 | 블로그 기획과 디자인

시작하며

블로그를 하는 이유와 직접 만들게 된 계기

그동안 공부하고 프로젝트를 진행하며 작성했던 기술 글들을 제가 원하는 UI/UX로 온전히 표현하고 싶었습니다. 여기에 더해 예전부터 앨범을 듣고 평점과 후기를 남기던 개인 기록이 있었는데, 메모장에 흩어두기보다는 하나의 독립된 아카이브에 모아 단일 도메인 안에서 체계적으로 관리하고 싶다는 생각이 들었습니다.

기존 블로그 플랫폼들을 여럿 써보았지만 불필요한 광고, 제약이 많은 URL 구조 등 매번 아쉬운 점이 남았습니다. 특히 음악 평점과 앨범 아카이빙은 제가 원하는 방식으로 데이터를 다룰 수 있는 플랫폼이 전무했기에 결국 직접 구축하는 길을 택했습니다.

재기획 당시 설정한 핵심 목표는 크게 두 가지였습니다.

• 운영비의 최소화 (Zero-Cost Idle): 일반적인 조회는 정적 캐시로 대응하고, 로그인·앨범 등록·투표·댓글처럼 실제 데이터 쓰기가 일어나는 요청만 서버리스 함수가 처리하도록 설계합니다. 트래픽이 간헐적인 개인 사이트 특성상, 유휴 상태에서 비용이 0에 수렴하는 아키텍처가 아니라면 장기적인 유지가 어렵다고 판단했습니다.
• 지속 가능한 웹 디자인 (Sustainable Web Design): 데이터 전송량, 불필요한 서버 연산, 클라이언트 기기의 전력 소모를 줄여 디지털 탄소 발자국을 최소화하는 설계 방식을 지향합니다. AI와 대규모 데이터 인프라의 급격한 팽창으로 전력 소비와 환경 부담이 커지는 시점에서, 웹 프론트엔드 레벨에서도 리소스를 낭비하지 않는 구조를 만들고자 했습니다.

기획과 디자인

기획은 재작년 Astro 기반으로 구성해 두었던 개인 블로그 프로젝트의 설계 자산을 가져오는 것에서 출발했습니다. 이미 검증된 UI 결정은 그대로 채택하고, 부족한 부분만 새로 채웠습니다. 음악 아카이브 영역은 초기 아이디어 단계였기에 데이터 모델링부터 화면 설계까지 사실상 새로 진행했습니다.

블로그 영역은 **지속 가능한 웹 디자인(Sustainable Web Design)**을 핵심 지향점으로 삼았습니다. 과거 레딧에서 인상 깊게 보았던 '고양이 로고가 들어간 미니멀 개인 블로그'를 레퍼런스로 삼았으나, 당시 아카이빙을 해두지 못해 아쉽게도 링크를 다시 찾지는 못했습니다. (추후 찾게 되면 꼭 기록해 둘 예정입니다.)

음악 아카이브 요소가 들어가면서 순수 텍스트 중심의 완전한 탄소 저감 웹과는 다소 거리가 생겼지만, 아래와 같은 리소스 절감 기법들을 적극 적용해 타협점을 찾았습니다.

적용한 리소스 절감 기법

• 이미지 최적화 및 레이지 로딩: 앨범 커버 이미지를 WebP/AVIF 등 최신 포맷으로 압축 변환하고, 화면에 바로 보이는 일부(첫 진입 히어로 이미지 등)만 즉시 로드하고 나머지는 뷰포트 진입 시점에 로드되도록 처리해 불필요한 초기 데이터 전송량을 최소화했습니다.
• 다크 모드 지원과 초기 렌더링 최적화: OLED 디스플레이에서 어두운 픽셀 표현 시 소비 전력이 줄어든다는 점에 착안해 다크 테마를 선택지로 제공했습니다(기본값은 라이트). 저장해 둔 테마 값을 React가 화면을 그리기 전에 인라인 스크립트로 먼저 적용해, 페이지를 열 때 잘못된 테마가 잠깐 보였다가 바뀌는 깜빡임(FOUC)을 방지했습니다.
• 순수 CSS를 이용한 3D 및 인터랙션: Three.js나 Canvas 같은 무거운 WebGL 라이브러리를 끌어오는 대신, 브라우저 하드웨어 가속을 활용하는 순수 CSS 3D 트랜스폼(transform-style: preserve-3d, perspective)을 사용해 메인 스레드 연산 부담과 클라이언트 배터리 소모를 최소화했습니다.

웹 프레임워크 선택

Next.js 를 선택한 이유

블로그를 비롯한 콘텐츠 중심의 웹사이트를 구축할 때 흔히 고려되는 선택지는 리액트 기반의 Gatsby였습니다. Gatsby는 정적 사이트 생성(SSG) 생태계에서 오랜 역사를 지녔고, Netlify에 인수된 이후에도 꾸준히 사용되어 왔습니다. 최근에는 아일랜드 아키텍처(Islands Architecture)를 앞세운 Astro 역시 큰 주목을 받고 있습니다. 저 또한 해당 프로젝트를 재작년 Astro를 이용해 제작하다가 다른 프로젝트로 미뤄두었다가 요구사항(음악기록)이 추가되면서 Next.js로 프레임워크를 전환하게 되었습니다.

① 최근 정적 사이트(SSG) 생태계의 트렌드 변화

최근 몇 년간 프론트엔드 렌더링 생태계는 정적과 동적의 경계를 허무는 방향으로 빠르게 진화했습니다.

1. '순수 정적(Pure SSG)'에서 '하이브리드 렌더링'으로의 전환
   빌드 시점에 모든 HTML을 생성하는 전통적인 SSG는 콘텐츠 양이 늘어날수록 빌드 시간이 선형적으로 증가합니다. 이를 해결하기 위해 정적 캐싱 속도를 유지하면서 백그라운드에서 주기적/온디맨드로 페이지를 갱신하는 ISR(Incremental Static Regeneration)이나, 정적 셸에 스트리밍 동적 컴포넌트를 결합하는 PPR(Partial Prerendering) 같은 하이브리드 전략이 표준으로 자리 잡았습니다.

2. 아일랜드 아키텍처(Islands Architecture)와 Zero JS 지향
   Astro 등이 주도하는 방식으로, 페이지 전체를 자바스크립트 번들로 감싸는 대신 대부분을 순수 정적 HTML로 렌더링하고 사용자 인터랙션이 필요한 컴포넌트(Island)에만 최소한의 JS를 주입합니다. 콘텐츠 중심 사이트에서 뛰어난 로딩 속도(LCP, INP)를 보장하는 장점이 있습니다.

3. 정적 사이트와 풀스택 웹 애플리케이션의 결합
   단순 정보 전달용 블로그라도 댓글, 좋아요, 조회수 카운팅, 관리자 인증, 실시간 인터랙션 등 동적 기능이 필수가 되었습니다. 이에 따라 정적 빌더 단독 구조보다는 서버리스/엣지(Edge) 인프라와 자연스럽게 통합되는 풀스택 프레임워크의 활용도가 높아졌습니다.

② 정적 콘텐츠를 넘어 동적 인터랙션과 백엔드 기능의 필요

단순 마크다운 렌더링을 넘어 앨범 평점 관리, 앨범 이상형 월드컵, 익명 댓글, 관리자 인증처럼 데이터베이스에 직접 '쓰기(Write)' 작업을 수행하는 백엔드 레이어가 필수적이었습니다.

초안에서는 Astro(프론트엔드) + AWS Lambda 위의 Spring Boot(백엔드) 조합을 고려했으나, 레포지토리와 배포 파이프라인을 이원화해 운영하는 것은 개인 프로젝트 관점에서 유지보수 오버헤드가 과도하다고 판단했습니다. 단일 코드베이스 안에서 프론트와 API 라우트를 함께 다룰 수 있는 풀스택 환경이 필요했습니다.

③ Java/Spring Boot 대비 서버리스 환경에서의 비용 및 레이턴시 이점

Java/Spring Boot는 상시 가동 컨테이너나 VM 환경에서는 견고하고 강력하지만, 트래픽이 간헐적인 개인 프로젝트의 Serverless(AWS Lambda) 환경에서는 뚜렷한 한계가 존재했습니다.

• 콜드 스타트(Cold Start) 지연: JVM 구동 및 Spring Context 로딩(Bean 의존성 주입 등)으로 인해, 유휴 상태 후 첫 요청 시 수 초 이상의 응답 지연이 발생합니다.
• 최적화 복잡도: AWS SnapStart나 GraalVM Native Image(Spring Native)로 지연을 완화할 수 있지만, 런타임 제약과 긴 빌드 시간, 디버깅 복잡도로 인해 1인 개발 환경에서 생산성이 떨어집니다.
• 경량 런타임의 이점: Next.js의 Route Handlers / Server Actions를 Vercel이나 경량 서버리스 환경에 배포할 경우, 가벼운 Node.js/Edge 런타임을 통해 밀리초 단위의 콜드 스타트로 서버리스의 비용 및 관리상 이점을 누릴 수 있었습니다.

기능 구현과 시행착오

구체적인 데이터베이스 연동, 인증 구조, 성능 최적화 과정에서 겪은 시행착오들은 이어지는 후속 글을 통해 자세히 다룰 예정입니다.

프로젝트를 마무리하며

기획 단계에서 여러 레퍼런스를 검토하고 아키텍처를 고민했던 만큼, 그리고자 했던 형태의 개인 아카이브가 완성되어 만족스럽습니다. 기존에 흩어져 있던 글들을 검토하고 보완하여 이관하는 작업에는 시간이 다소 걸리겠지만, 앞으로 학습하고 개발하며 겪은 고유한 경험들을 양질의 글로 꾸준히 기록해 나갈 계획입니다.

참고자료