하루만에 홈페이지 만들기 with Astro
업데이트:
하루만에 홈페이지 만들기 with Astro
법인도 만들었겠다, 드디어 회사 홈페이지를 만들기로 했다. 이런 건 보통 귀찮기도 하고 급한일이 아니라서 미루게 되는데, 불현듯 어느날, 무언가 홀린 사람처럼 “지금이야” 싶었다. 프론트엔드 디자인을 구경하다가, 문둑 머리속에서 내가 만들고 싶은 홈페이지 모습이 선명하게 그려졌다. 마치 스파크가 튀듯 말이다. 그리고 그 순간부터 몰입했다. 정말, 그 몰입의 순간 만큼은 우주에 나 혼자, 노트북 한 대만 있는 느낌이었다. 그만큼 즐거운 순간이었고, 그렇게 해서 탄생한 결과물이 바로 이 홈페이지다.
이 글은 그 과정의 기록이다.
혹시 당신도 나처럼 언젠가 만들겠지…라고 미루고 있다면, 이 글이 그 날이 되길 바라며.
우선 개발 과정의 전체 큰 흐름은 위 그림과 같다. 시작은 로컬에서 개발을 하고 github에 push하면 github과 연동되어 있는 CloudFlare에서 코드 변화를 감지한 후, 빌드를 진행한 후에 최종적으로 홈페이지가 배포되는 방식이다. 즉, 코드 한 줄만 수정하고 푸시하면 바로바로 홈페이지가 최신 상태로 반영된다. 물론 처음부터 이렇게 구성하려던 건 아니었다. 한 단계씩 거치면서 적절한 다음 스텝을 찾는 방식으로 진행했다. 그래서 이 글에선 단순히 결과만 보여주는게 아니라, 각 선택의 배경도 함께 이야기해보려 한다. 왜 그렇게 했는지, 무엇이 더 편했는지 같은 이야기들 말이지.
우선 홈페이지에 어떤 내용을 담을지 간단히 화면 기획부터 시작했다. 어떤 페이지가 필요할지, 버튼은 어디에 둘지, 아이템은 어떻게 배치할지… 그럼 이 기획 페이지는 뭘로 만들까? 처음엔 피그마가 떠올랐다. 요즘 다들 쓰고, 나도 예전에 써봤으니까. 게닥 피그마는 코드 변환도 되니까 개발에도 도움이 되겠지 싶었다. 하지만 너무 오랜만에 써서일까, 좀 낯설었다. 이 상태라면 익숙해지는데도 시간이 필요하다. 하지만 이번엔 그럴 시간이 없었다. 이런 방향으로가면 개발기간이 너무 길어질 것만 같았다. 이번 프로젝트의 목적은 피그마 공부가 아닌 최대한 빠르게 홈페이지 완성하기 였고, 결국엔 가장 빨르게 내 손이 움직이는 툴, 파워포인트를 선택했다. 파워포인트는 디자인 툴은 아니지만 기획에는 딱이었다.
화면 기획 단계에서 가장 먼저 한 일은 어떤 페이지들을 넣을지 정하고, 그에 따른 상단 메뉴를 어떻게 구성하는지 결정하는 것이었다. 페이지 수가 많아질수록 홈페이지 구조도 복잡해지기 때문에, 전체 구성을 먼저 그려보는게 중요했다. 결국 나의 경우엔 대메뉴와 소메뉴로 나눠진 상단 메뉴 구조가 필요하겠다고 판단했다. 그 다음엔 각 메뉴에 해당하는 페이지를 어떻게 구성할지 대략적으로 구상했다. 물론 이 단계에서 정하는 내용은 나중에 달라질 가능성이 매우 크므로 지나치게 상세하게 하는 것보다는 크게 윤곽을 잡는다는 느낌으로 접근하는 것이 좋겠다. 물론 처음부터 완벽하게 디자인하면 구현할 때 고민이 적어지니까 장단점이 있는 것 같다. 나의 경우에는 기획은 어짜피 구현하면서 바뀌기 마련이라, 큰 윤곽만 잡고 시작하는게 훨씬 효율적이라고 생각했다.
화면 기획이 끝났다면, 다음 단계는 어떤 플랫폼으로 개발할지 결정해야한다. 내가 고민한 후보는 세 가지. 지킬, 휴고, 아스트로가 그것이다. 먼저 언급된 툴일수록 개발이 쉽고 빠르며, 코드없이도 구축 가능하다. 반면 뒤로 갈수록 난이도도 높고 개발 시간도 늘어난다. 처음에는 지킬을 생각했다. 내 기술 블로그도 지킬로 만들었던 경험이 있었고, 내가 지금 만들 홈페이지도 정적 페이지 몇개면 충분했기 때문에, 지킬을 사용하면 금방되겠거니 했다. 게다가 지킬은 github pages와 궁합이 좋아서 코드만 올리면 알아서 빌드되고 배포까지 되어 공수도 크게 줄어든다.
그렇게 지킬로 개발하기로 결정하고 요즘 어떤 테마가 있는지 살펴봤다. 기술 블로그 만든지도 어느새 5년이 넘어가니 그 사이 테마가 더 다양해졌더라. 너무 오랜만이라 감도 좀 익힐겸, 적당한 테마를 고르고 clone 한후 내 repo에 push….그런데 build fail이 뜬 것이다. github에 코드를 push 하면 깃헙액션이 알아서 빌드를 해주는데, 문제는 그 깃헙액션이였다. 깃헙액션은 말로는 우리에게 빌드를 자동으로 해준다고 하지만 우리는 이미 알고있다. 자동으로 해준다는 말 이면에는 문제가 생겼을때 우리가 손댈 수 있는 영역돋 그만큼 제한된다는 뜻을 말이다. 고생 안하려고 지킬 템플릿 쓰는건데 깃헙 액션이랑 싸울 생각을 하니… 벌써 지친다. 그래서 결론은, 지킬은 이만 보내주기로했다. 잘 가라, 그동안 즐거웠다. 그래. 새로운 시작엔 새로운 툴이지.
그래 이 참에 휴고를 써보자. 휴고는 지킬보다는 손이 더 가긴하지만, 이정도면 다른 일하면서도 홈페이지 관리할 수 있겠다는 생각이 들었다. 그런데 문제는 템플릿이었다. 휴고 템플릿 중에 내가 원하는 스타일이 없었다는 것. 내가 원하는 디자인은 화면 상단에 가로형 메뉴바가 있고, 대메뉴를 클릭시 드롭다운으로 소메뉴가 나오는 구조였다. 그런데 휴고 템플릿 중에는 그런 구조가 드물었고, 있다 하더라도 다지인이 너무 별로였다. 홈페이지는 회사의 얼굴이자 첫인상인데 이런 디자인으로는 도저히 만족할 수 없었다. “이건 좀 아닌데…“하는 생각이 계속 들더라. 그래서 휴고도 탈락. 아쉽게도 패스…
이제 남은건 아스트로. 솔직히 말하면, 코딩은 되도록 피하고 싶었다. 왜냐하면 공수도 많이 들고, 귀찮기도 하고, 무엇보다 다른 할일도 너무 많기 때문이었다. 하지만 결국은 생각했다. 개발자면 개발해야지..라는 마음으로 아스트로 템플릿을 보는데 방금 휴고 템플릿을 보고 와서 그런가? 너무 예뻤다. 그래, 이정도는 되야 홈페이지지!라는 생각과 함께 오랜만에 개발 본능이 샘솟았다. 마침 내가 원하는 화면구성이 있어서 템플릿을 받고 vscode를 실행하고 드디어 코드를 짜기 시작했다.
잠깐, 아스트로가 뭔지 잘 모른다면 이렇게 생각하면 된다. 아스트로(Astro) 는 자바스크립트 기반 정적 웹사이트 개발을 위한 프론트엔드 프레임워크이다. 아스트로 자체는 자바스크립트 및 타입스크립트로 개발되었고 아스트로 컴포넌트(.astro) 내부에서도 자바스트립트 및 타입스크립트를 사용할 수 있다. 또한 아스트로는 정적 사이트 구축을 목표로 하므로 HTML과 CSS 중심으로 작동하므로, 웹 개발을 조금만 해봤다면 진입장벽도 낮은 편이다. 아스트로 파일 내부에서는 일반적인 HTML과 유사한 구조를 사용해 친숙하게 다가갈 수 있다. 게다가 React, Vue, Svelte 등과 같은 다양한 프레임워크와 함께 사용할 수 있다는 장점이 있다.
마음에 드는 astro 템플릿을 선택하고 git에서 clone 했다. 그 다음부터 본격적인 개발에 돌입했는데, 먼저 홈화면을 만들고, 상단 메뉴를 구성한 후, 각 메뉴별로 화면을 만들기시작했다. 작업 순서는 단순했다. 페이지 틀을 만들고, 내용을 채워넣은 후, 다자인을 다듬었다. 이 과정에서 로컬에서는 npm run dev 명령어로 바로바로 디자인 확인하면서 수정했다. 프론트엔드의 매력은 바로 이거다. 내가 바꾸면 바로 보인다. 백엔드와는 또 다른, 눈으로 보이는 개발의 즐거움인 것이다.
화면 개발이 마무리될 즈음, “이제 어디에 배포하지?”라는 고민이 시작됬다. 이 고민과 함께 도메인을 어디서 구매할지도 고민했다. netlify 등 여러 후보를 생각해봤지만 최종적으로 cloudflare를 선택했다. 이유는 단순했다. 도메인 구매와 소스코드 빌드와 배포를 한꺼번에 할수있다는 장점이 마음에 들었다. cloudflare와 내 Github 레포지토리를 연동하면 커밋만 하면 cloudflare가 바로 배포하는 구조였다. 이제 배포방식도 정해졌으니 로컬에서 마지막 빌드 테스트까지 마친 후. 드디어 github에 최종 push를 했다.
그리고나서 cloudflare에 연결 후 빌드가 잘되는지 확인하는데,
역시 로컬에서의 빌드와 클라우드에서의 빌드는 달랐다.
또 한번의 삽질 타임.
개발자라면 누구나 한번 쯤은 이런 경험이 있을 것이다.
“로컬에서는 되는데 서버에서는 안돼요..”
익숙한 상황이었다. 삽질을 통해 몇가지 코드를 수정한 끝에 무사히 배포를 할 수 있었다.
참고로 Cloudflare에서는 SSR(Server-Side Rendering)과 Static(정적 사이트 생성) 두 가지 방식의 배포를 모두 지원한다.
Static 방식은 빌드 시점에 HTML 파일을 미리 생성해서 배포하는 방식이고, 변경이 자주 없는 콘텐츠를 다룰때 많이 사용하는 방식이다. 이 방식은 유저가 페이지를 요청하면 이미 만들어져있는 정적 HTML, CSS, JS 파일로 바로 응답하는 형태이다. 이 방식은 응답 속도가 빠르다는 장점이 있으나 페이지 변경시 다시 빌드하고 배포해야한다는 특징이 있다. 사용 방법은 astro.config.mjs 파일에서 output: “static” 으로 작성하면 사용가능하다.
SSR(Server-Side Rendering) 방식은 사용자의 요청이 들어올때마다 서버에서 HTML을 실시간을 생성하는 방식이다. 빌드 시간은 짧지만 요청마다 서버 실행이 필요해서 속도는 다소 느릴 수 있다. 사용방법은 astro.config.mjs 파일에서 output: server 으로 작성하면 사용가능하다. 이 방법은 주로 대시보드나 사용자 로그인 정보 표시가 필요한 사이트에서 사용된다.
나는 정적 페이지만 있으면 충분하니까 static 방식을 선택했다.
이렇게 배포를 한 홈페이지를 보는데, 드디어 내 집에 처음으로 대문이 생긴 기분이었다. 물론 지금까지 내가 소중하게 운영하던 기술블로그도 있지만 홈페이지는 조금 다르게 다가왔다. 우리 회사의 이름을 걸고, 내가 만든 디자인과 구조로, “이게 나의 공간이다”라고 말해주는 느낌이랄까. 이제 막 첫 대문을 연 집에 앞으로 어떤 이야기들을 채워나갈지, 스스로도 꽤 기대된다.
그렇게 배포를 하고 나서 주변사람들에게 홍보를 했는데, 그제서야 눈에 안보이던 수정사항들이 하나둘 보이기 시작했다. 결국 배포 하자마자 바로 패치 모드에 돌입했는데, 다행히 지인들의 제보가 큰 도움이 되어, 실제 사용자 관점에서 필요한 수정 포인트들을 빠르게 반영할 수 있었다. 역시 혼자만의 시선으론 놓치는 부분이 많다. 운영은 혼자하지만, 완성은 함께 만들어가는구나 싶었다. 배포는 끝이 아니라 진짜 시작을 의미한다.
참 신기하게도, 배포 전에는 멀쩡해 보였던 것들이 막상 세상에 공개하고 나면 아쉬움으로 다가온다. 하지만 그게 자연스러운 것 같다. 진짜 완성은 배포 이후에야 시작되니까 말이다. 그러헥 피드백을 반영하고, 수정을 거듭하면서 현재의 홈페이지가 완성되었다.
그리고나서 검색엔진최적화(SEO, search engine optimization) 설정도 해주고 구글 애널리틱스 연결해서 내 홈페이지의 발자취를 느낄 수 있도록 마무리했다. 그리고 몇 분 후 애널리틱스 화면에 실시간 접속 3명이 떴다. 그 순간 심장이 두근거렸다. 이 세상 어딘가에서 누군가가 내가 만든 홈페이지를 보고 있구나.
이렇게 나의 홈페이지 만들기 드디어 완성!