구축한 개발 블로그에 처음쓰는 첫 글입니다. 블로그를 구축하면서 겪었던 경험들을 놓치지 않기 위해 기록으로 남깁니다. ## 블로그를 제작하게 된 이유 개발자로서 "글을 쓰고 기록으로 남겨야한다"의 마음과 아 내가 직접 만들어봐야하지 않겠나 라는 약간의 고집으로부터 시작했습니다. 원대한 마음을 품고 계획을 했으나.. 인생이 그렇듯 계획한대로만 흘러가진 않았습니다. ## 초기 계획 초기에는 클라이언트 + 서버로 동작하도록 구성해야겠다, 기왕이면 새로운 기술을 이용하자 라고 생각했고. 또 너무 많은 기술을 새롭게 배우면 러닝커브가 심하므로... DB쪽은 조금이라도 알고 있는, RDBMS를 써야겠다 생각했습니다. 따라서 기술 스택이 `(FE) Remix , (BE) Nest.js, mysql, (middle ware) nginx, (Iaas) AWS EC2, AWS RDS` 로 결정되었습니다. 신나게 Nest.js와 mysql을 연동하고 서버를 구축하고, Remix로 클라이언트측 서버를 개발하면서, EC2와 RDS를 통해서 개발 완료한 백엔드 서버를 띄우려는 때에, RDS를 쓰게되면 생각했던 예산과 맞지 않음을 깨달았고... (EC2 또한 마찬가지) 그 과정에서 스펙이 너무 오버 스펙이라는 생각이 들어서 계획을 수정하게됩니다 ## 최종 개발 계획 결국 내가 하려는건 나 혼자만 작성하고 올리는 개발 블로그를 운영하는게 목표였으니. 텍스트 위주인 포스트이니 DB가 딱히 필요하지 않을거라고 생각했고 그렇게되면 서버가 의미가 있나라는 생각이 닿아서
프론트단일 서비스를 구상하게됩니다. Next.js를 이용하며 프로젝트의 파일시스템으로부터 게시물 계층을 가져오는 방향으로 작성하면 될거라는 생각이 들었고. 글 작성하기 편하도록 + 간단한 DB 역할처럼 사용할 수 있도록 `.mdx` 와 `frontmatter`를 이용하기로 결정하고. 나에게는 좋은 무료 클라우드 시스템인 github가 있으니! AWS EC2 인스턴스 한개만 두고. t3.micro를 이용해서 운영하기로 맘 먹었습니다. ## 서비스 구조 서비스는 매우 단순한 구조를 가지고 있습니다. 외부에서는 sseoku.com 도메인으로 접속하면, AWS EC2 인스턴스 위에서 동작하는 Nginx가 요청을 받고, 이를 Next.js 앱으로 리버스 프록시하는 형태입니다.
Next.js는 pm2를 이용하여 백그라운드에서 실행되고 있으며, 블로그의 글들은 모두 .mdx 파일로 작성되어 정적 자원처럼 읽히는 구조입니다. Next.js의 App Router 기능을 활용하여 파일 기반 라우팅으로 포스트 페이지를 구성했고, frontmatter를 통해 메타데이터를 처리하고 있습니다.
정리하면, Nginx는 리버스 프록시 역할만 하고 있고, Next.js는 정적 HTML을 동적으로 생성하는 형태로 동작하고 있으며, DB 없이 파일 시스템 기반으로 모든 콘텐츠를 관리하고 있습니다. CI/CD는 GitHub Actions를 통해 main 브랜치에 푸시될 때 자동으로 빌드 후 EC2에 배포되도록 구성했습니다. 서비스 흐름도

## 자동 배포 구성 (GitHub Actions) 개발 블로그를 운영하면서 직접 배포 작업을 반복하는 것이 비효율적이라 판단되어, GitHub Actions를 이용해 자동 배포 파이프라인을 구성하게 되었습니다. CI/CD 파이프라인은 크게 코드 검사, 프로젝트 빌드, Lighthouse 성능 측정, EC2 서버 배포의 4단계로 나뉘며, main 브랜치에 푸시되었을 때 자동으로 실행되도록 설정되어 있습니다.
CI 단계 • 코드가 푸시되면 가장 먼저 타입 체크, ESLint, Prettier, 맞춤법 검사(cSpell)를 수행하여 코드 품질을 검증합니다. • 사소한 실수로 인해 빌드가 깨지지 않도록 안전망 역할을 하며, 이 단계에서 실패하면 이후 단계는 실행되지 않습니다.
빌드 단계 • .env 파일을 GitHub Secrets로부터 주입하고, 프로젝트를 빌드합니다. • sitemap 생성 스크립트를 실행하고, 필요한 파일들을 묶어서 build.tar.gz 형태로 압축합니다. • 이후 아티팩트를 업로드하여 다음 단계에서 사용할 수 있도록 합니다.
Lighthouse 단계 • PR 요청이 발생했을 때 실행되며, 실제 빌드한 프로젝트에 대해 Lighthouse CI를 수행합니다. • 성능, 접근성, SEO 등을 체크하고 HTML 리포트를 생성하며, 해당 리포트 링크를 PR 코멘트로 자동 등록하여 빠르게 확인할 수 있도록 합니다.
배포 단계 • EC2에 연결된 self-hosted runner를 통해 아티팩트를 다운로드한 뒤, 압축을 해제하고 pnpm install --prod를 수행합니다. • 이후 PM2를 통해 서비스가 실행되거나 리로드되며, /sitemap.xml에 반복적으로 헬스 체크를 수행하여 서비스가 정상적으로 올라왔는지 검증합니다. • 이 과정을 통해 푸시만으로도 완전 자동화된 무중단 배포가 이루어집니다. 서비스 흐름도

## 비용 처음으로 내가 직접 서비스를 운영하려다 보니 비용 문제를 생각 안할수 없었는데. 비용이 나간 항목들은 크게 다음과 같습니다. - AWS EC2 > t3.micro - AWS Routes EC2의 경우 3년 예약으로 걸어둬서 대략 17만원.. 이였던것으로 기억하며 Routes도 3년 11만원이였던것으로 기억합니다. 나름 합리적인 소비였다고 생각하며 기분이 좋더군요 ## 프로젝트 기간 회사 점심시간 1시간정도를 활용하여 개발 하였고 현재의 아키텍처로 정해진 기준으로는 프론트 개발에는 약 3개월 정도가 소요된 것 같습니다. 디자인·기획이 자주 변경되어서 해당 부분에 대한 기간 소요도 대략 삼주 정도 걸린 것 같군요 AWS관련 기술을 익히고 git actions을 통해서 CI/CD 작업을 자동화하는 부분에도 시간이 다소 소요되었습니다. 이래저래 기획했던걸 완성하고 나니 1년이 걸렸네요 그 기간동안 배운것도 굉장히 많고, 정말 무지한 부분이 많았다는걸 더 많이 느꼈습니다. ## 회고 프로젝트를 구상하면서 프론트 개발자라고는 하지만 이제까지 리액트 개발자에 가까웠고. 동작방식에 대한 이해나 실제 서비스를 구성하기 위해 적용해야할 것들이 많은데 해당 부분들에 대해 너무 무지하였던 부분이 반성되었습니다.
또 그로인해 앞으로 어떤 개발자가 되고 싶은지에 대해서도 다시 한번 생각하게 되는 계기가 되었구요. 프론트를 떠나서 앞으로 좀더 영역을 확장하고. 프론트 분야에 대해서는 더 깊게 파고드는 T자형 개발자. 모든 부분에 있어서 기본기 이상은 알아서 소통함에 있어서 드는 시간과 노력을 줄어들게 하는 엔지니어가 되고 싶습니다.
대 AI 시대에서 대체되지 않기 위하여 앞으로도 끊임없이 구르고 갈고 닦는 사람이 되보겠습니다.

2025년 08월

개발 블로그 제작기