blog.atj.sh (this)

블로그 주인

전성훈이다.

블로그를 시작하는 이유

글쓰기를 연습하고, 내 경험과 생각을 다른 사람에게 나누려고 한다.

블로그를 만든 이유

소프트웨어 개발자로써 평소에 학습하고 싶은 프레임워크와 언어, 툴들이 있었다.

• Rust lang - 프로그래밍 언어
• axum - Rust 기반 웹 프레임워크
• AWS Lambda - 컴퓨팅 인프라스트럭쳐
• PostgreSQL - DB
• SvelteKit - Svelte 기반 웹 프레임워크
• Cloudflare Pages - 무료 웹 호스팅 서비스
• Supabase - BaaS & 무료 PostgreSQL 호스팅 서비스

이것들을 최단시간에 학습할 방법은 없을까 고민하다가, 이것들로 내 전용 블로그를 하나 만들면 좋을 것 같다고 생각했다. 그러면 학습도 되고, 평소에 필요했던 내 전용 블로그 플랫폼도 만들 수 있으니까 나한테는 이득이었다. 실제로 블로그를 만들 때 위 기술들을 전부 사용했다.

기술적 특징

백엔드 부분은 Rust 언어로 구현했다. axum 웹 프레임워크를 사용했으며, 배포는 AWS Lambda 인프라에 되어 있다.

데이터는 PostgreSQL 데이터베이스에 저장되며, Supabase에서 무료로 제공하는 인스턴스 안에 저장된다. 개인 블로그용으로는 충분히 넉넉한 양 같아 보였다.

프론트엔드는 SvelteKit 프레임워크로 구현하였다. SSR을 적극적으로 활용한다. 유저가 상호작용하는 대부분의 코드는 SvelteKit의 서버 코드로 구현되어 있으며, 웹 브라우저까지 노출되지 않는다. form도 마찬가지이며, form 검증 또한 서버 부분에서 이루어진다. 프론트엔드 코드는 Cloudflare Pages에 배포되어 있다.

블로그를 만들며 만난 난관들

Cloudflare Pages와 Vercel, SvelteKit

프론트엔드 배포에 이슈가 하나 있었다. 사실은 프론트엔드를 Vercel에 배포하고 끝내려고 했었는데, Vercel에 배포하고 보니 서버가 생각보다 느린 것이었다. 처음에는 AWS Lambda에 배포된 백엔드와 Supabase의 PostgreSQL을 의심했었는데, 정작 로컬에서 Lambda 서버를 호출할 때에는 속도가 하나도 느리지 않은 점이 이상했다.

그래서 프론트엔드 배포 위치를 바꾸기로 결정했다. 후보군은 많지 않았다. Netifly, Cloudflare Pages, Vercel 셋 중 하나를 고르거나, AWS 인프라에 내가 직접 배포하는 방법을 택해야 했다. 특히 SSR을 적극 활용하도록 구현된 코드로써는 정적 빌드도 어려운 상황이었기 때문에, 셋 중에서 고르지 못하면 내가 직접 SvelteKit을 배포해야 하는 작업을 진행해야 했을 것이다.

그런데 그 와중에 Cloudflare의 대시보드 인프라에 장애가 발생했다. 하필 Cloudflare Pages에 애플리케이션을 배포해볼 때 발생해서, 제대로 된 테스트를 처음에는 할 수 없었다. 이틀 정도 기다리니까 장애가 해결된 모양인지, 정상적으로 배포해볼 수 있었다.

다행히도 Cloudflare Pages는 무난한 성능을 뽑아주는 것을 확인할 수 있었다. 특히, 이전에 Cloudflare Pages에 리액트 앱을 배포해본 적이 있었기 때문에, SvelteKit 앱 배포 또한 어렵지 않았다. 다만, 원래는 프론트엔드 패키지 매니저로 bun을 사용하고 있었는데, SvelteKit에 bun을 사용한 빌드 옵션이 존재하지 않아 bun 사용을 포기하는 일이 있었다. 나중에 bun 지원이 추가되면 다시 사용해볼 의향이 있다.

배포 자체는 바로 진행했으나 Cloudflare Pages에 배포된 후 앱이 '500 에러'를 내며 작동하지 않는 현상이 발생했다. SSR까지는 작동하나 내부 로직 어딘가에서 작동하지 않는 모양이었다. 분석해본 결과, Cloudflare Pages의 js 실행 환경(Cloudflare Workers)의 문제인 것으로 확인되었다. fetch 함수의 일부 기능이 지원되지 않아 서버(백엔드, AWS Lambda)로부터의 데이터 로딩에 실패하는 것이었다. 그래서 fetch 함수 호출 시 불필요한 코드를 삭제했는데, 그랬더니 잘 작동했다. 당시 수정 커밋

Rust & AWS Lambda

AWS Lambda로 배포하고 도메인 주소를 할당하는 작업은 Mini Dice 서비스를 구현해보며 이미 해본 작업이라 별로 어렵지 않았다. 이 당시에도 AWS Lambda로 배포하고 API Gateway(HTTP)를 통해 외부에 접근할 수 있도록 설정했었는데, 동일한 방식으로 설정하니 어렵지 않게 도메인 연결까지 진행할 수 있었다. 참고로 도메인은 AWS Route 53을 통해 관리되고 있었기에 작업이 더 쉬웠다.

AWS Lambda용으로 axum을 빌드하는 과정 또한 어렵지 않았다. AWS에서 직접 제공하는 `lambda_http` rust crate를 사용하면 일반 axum 앱처럼 코드를 작성하고 AWS Lambda에 배포할 수 있다. 로컬 테스트 또한 코드 변경없이 `cargo lambda watch` 명령어로 진행할 수 있었다. 생각보다 편해서 놀랐다.

첫 버전을 만들고서 느낀 점

기분이 좋았다. 그리고 Rust 언어로 뭘 만들어본 적이 한 번도 없었는데, 웹 애플리케이션을 하나 만들어보니 Rust에 대한 자신감이 생겼다 (원래는 무서웠다). 나중에는 더 복잡한 앱을 만들어볼 생각이다. 위에 언급한 Mini Dice 서비스를 Rust로 포팅해보는 것도 재밌을 것 같다. SvelteKit 또한 신선하고 든든한 느낌이 들어 나쁘지 않았다. CSS 지원이 내장되어 있고 어렵지 않아 좋았다. 타입 지원 또한 굉장히 잘 되어있는 것에 놀랐다. 아쉬운 부분이 많지 않았다. 물론 수박 겉 핥기 식으로 써본 상태이긴 하지만, Svelte의 기본적인 템플릿 문법과 데이터 바인딩을 써볼 수 있어서 좋았다.

이후에는 코드 정리와 디자인 개선, 그리고 관리자 페이지 개선에 힘써볼 생각이다. 현재 소스코드 전체적으로 코드 중복이 심한 편이다. 비즈니스 로직을 함수화하지 않고 여기저기에 가져다 써서 발생한 문제인데, 알고 있는 디자인 패턴들을 적용해서 이를 해결해보려고 한다. 평소에는 NestJS의 DI 시스템에 친숙해져 있었는데, DI 시스템 없이 백엔드를 짜본 것이 오랜만이라 코드 중복이 더 심한 경향이 있는 것 같다. 코드를 리팩토링하며 디자인 패턴을 다시 돌아볼 기회를 가질 수 있을 것 같다. 디자인은 최대한 심플하게 가져가고, 관리자 페이지는 내가 편한 방향으로 디자인하면 되니까 큰 문제는 아니다.

참고로 광고는 아직 달 생각이 없으며, 통계/유저 추적 기능 또한 아직 생각이 없고, 댓글 기능도 아직은 생각이 없다. 그런데 댓글은 구현이 쉬운 편일텐데, 필요하면 구현할 생각은 있다. 아, 대신 웹사이트에 다크 모드는 꼭 넣고 싶다. 내가 다크 모드 중독자라 그렇다.

소스코드

https://github.com/ATJSH/rust-blog에서 원본 소스코드를 확인할 수 있다.

개선할 점들

https://github.com/atjsh/rust-blog/issues에서 확인할 수 있다.