TLDR;
Astro Based Blog를 만들었습니다. Astro가 React를 라이브러리로 바라보는 관점에 동의해, 사용하게 되었습니다. EC2를 통해 서버를 직접 구성하고, Github Actions를 통해 CI/CD를 구성하였습니다. 앞으로 이 블로그를 통해 생각과 사고과정을 공유하고, 더 많은 사람들과 소통할 수 있는 기회를 만들고자 합니다.
블로그를 만들자
블로그를 만들어야겠다는 생각을 했습니다. 사실 생각을 한지는 오래됐는데, 여러번 그만두었습니다. 첫번째로 글을 쓰는게 취향이 아니라고 생각했고, 더구나 보여주고 돌아올 반응이 부끄럽거나 두려웠습니다. 둘째로 당시에는 Next.js를 활용하여 만드는 걸 시도했는데, DB 세팅, 인증 등 목적에 비해 작업 볼륨이 커져서 부담스러웠습니다. 그래도 올해에는 마음을 다잡고, 자신의 콘텐츠를 보다 의미있게 만들어야겠다는 생각을하며 다시 블로그를 만들기 시작했습니다.
어떻게 만들 것인가?
지난 번에는 그저 익숙한 툴을 사용해 만들기를 시작했다면, 이번에는 지난 과오를 교훈삼아 어떻게 만들 것인지 부터 고민했습니다. Vite가 인기가 있는 듯하여 스터디겸 Vite를 기반으로 개발을 시작해보려고 했습니다. 도구의 맥락을 이해하는게 중요하기 때문에, 공식문서를 읽으면서 Vite의 목적과 철학에 대해 이해하고자 했습니다. 읽으면서 Vite로 바닥 부터 개발하는 것도 꽤 좋은 경험이 될거라고 생각했지만, 여전히 작업의 볼륨이 증가하기 때문에 쉽지 않을 거라고 생각했습니다. 그러던 중, 우연히 공식문서에서 Astro에 대한 언급을 찾았습니다. 호기심에 공식문서를 읽어보니, Wordpress등과 성능을 비교하고 있더군요. 블로그를 쓰기 좋은 CMS인가? 하는 생각으로 더 들여다 보았습니다.
React를 라이브러리로 바라보다.
첫 인상은 PHP 같다는 느낌이었습니다. 각각의 html 페이지에 JS 로직이 섞여있는 느낌입니다. React 기반의 프레임워크들도 마찬가지입니다만, 가장 큰 차이점은 페이지가 서버에서 생성된다는 점입니다. Next.js와 같은 프레임워크들도 마찬가지로 서버에서 정적 HTML을 생성하고 hydration이라는 과정을 거쳐 event를 attach하는 방식을 도입해서 서버쪽에서 html을 내려주지만, 페이지를 불러올 때 페이지 전체가 hydration 되어야만 하고, 그로인해 초기 이벤트 결속이 느린 부분이 있습니다. 만약 과정을 await하는 함수라도 존재하면, hydration 속도는 실제로 체감될 정도로 느려집니다. 반면에 Astro는 우선 client측의 JS가 모두 제거된 html을 생성합니다. 그 후, 클라이언트에서 JS를 통해 이벤트를 다루거나 데이터를 불러와야 할 때, 특별한 지시어를 사용하여 해당 html 조각에 JS가 포함됨을 나타냅니다. Next.js가 암시적으로 구성된 client side의 JS를 hydration하기 위해 코드를 분석하는 시간이 없어지고, 지시어가 있는 부분만 hydration하게 되는 것입니다. Astro는 이를 islands structure라고 표현합니다. 이러한 접근은 React를 웹 전체를 구성하는 프레임워크가 아니라 DOM의 상태를 제어하기 위한 라이브러리로 바라보고 있음을 보여줍니다. Astro의 이런 접근은 평소 생각하고 있던 ‘React 중심의 웹 생태계가 기이하다’라는 생각을 재확인 시켜주었습니다. 그리고 앱 전체가 아니라 일부에 사용하는 모습을 통해 라이브러리로서의 React의 가치 또한 다시 한 번 확인시켜주었습니다.
EC2가 필요할까?
블로그 개발을 위한 프레임워크를 확정한 이후에는 어디에 배포할지를 고민해야 했습니다. github pages, firebase 등등 정적 웹사이트 혹은 웹 서버 자체를 배포할 수 있는 선택지가 많이 있습니다. 그 중에서도 EC2를 통하여 직접 웹 서버를 배포하는 것으로 가닥을 잡았습니다. 그렇게 선택한 이유는 서버가 없는 정적인 웹사이트로 ‘블로그’를 완결짓고 싶지 않았기 때문입니다. 필요하다면 서버를 통해 더 많은 기능을 추가할 수 있었으면 하였고, 다양한 개발에 대한 시나리오를 실험해보는 공간으로 삼을 수 있었으면 좋겠다고 생각했기 때문입니다. 그렇게 하기 위해서는 결국 ‘서버’가 필요했고, 보다 범용적인 AWS를 사용하기로 마음 먹었습니다. 또한 EC2를 통해 유닉스 기반 시스템, 그리고 클라우드에 대해 더 공부할 수 있다는 점도 기대할 수 있는 효과라고 생각했습니다.
CI/CD Pipeline
블로그 초기, CI/CD에 대해 고민해야할 필요까지는 없다고 생각합니다. 수동으로 배포를 해도 충분히 목적을 달성할 수 있겠죠. 하지만, 게으른 성격에 지속적으로 글을 쓰고, 업데이트를 이어나가려면 자동화된 파이프라인이 필요하다고 생각했습니다. 게으른 스스로를 잘 알기 때문에, 게으름을 극복할 수 있도록 미리 장치를 해두는 것입니다. 자동화의 가장 주목할만한 이점은 ‘누군가 대신 해준다’라는 뻔한 측면보다, ‘반복 수행 작업의 실수를 줄여준다’라는 측면이라고 생각합니다. 즉, 나(적어도 미래의 나)를 믿을 수 없으니, 내 외부에 관리자를 만들겠다라는 표현인 겁니다. Pipeline은 본 소스코드가 Github에서 관리되는 만큼, Github Actions를 사용하기로 했습니다. EC2를 활용하여 배포할 예정이니 self-hosted runner를 구성하였습니다. CD뿐만 아니라 CI에 있어서도 semantic-release를 사용해서 코드를 병합하는 과정에서 사람이 실수를 저지를 없애고자 했습니다. 특히 버전과 같은 경우에는 누락의 위험성을 높고, 제대로 관리 되지 않았을 때 존재 의미가 희미해진다고 생각했기 때문입니다.
WebServer
WebServer는 Nginx를 사용하기로 했습니다. 가장 범용적으로 사용되는 서버이기도 하고, 설정이 간편하기 때문입니다. 이 때 Docker는 사용하지 않기로 했는데, EC2를 저 비용으로 사용하기 위해서 t4g.micro 인스턴스를 사용했기 때문입니다. 낮은 리소스를 굳이 Docker에 까지 할당할 필요가 없다고 느꼈습니다.
블로그를 만들었습니다.
이렇게 블로그를 만들었습니다. 블로그를 만드는 과정에서도 ChatGPT와 많은 대화를 하면서 희미한 회색지대를 명쾌하게 밝혀나갔습니다. 지금은 ChatGPT와 대화 뿐이지만, 지속적으로 생각과 사고과정을 공유해서, 여러분들과 유익한 이야기를 나눠가고 싶습니다. 반응이나 댓글을 통해 피드백 주시고, 다양한 이야기 함께 나눌 수 있으면 좋겠습니다. 물론, 읽어주신 것만으로도 감사드립니다. 앞으로 다양한 글로 찾아 뵙겠습니다!