처음 도메인을 구매하게 된 건 GitHub 학생 계정을 받게 되면서부터였다.
무료 크레딧으로 도메인을 살 수 있다는 사실을 알게 되었고,
심지어 DigitalOcean에서 1년동안 200$를 쓸 수 있는 서버 크레딧도 주어진다는 사실에
까짓거 무료인데 한번 해보지 뭐
라는 마음으로 도메인을 결제했다.
지금 이 글은, 그 도메인을 실제 서비스로 연결하기까지 겪은 과정을 정리한 개발 일지다.
1. 도메인을 샀다 (아무 생각 없이)
도메인을 구매할 때는 사실 기술적인 고민보다 감정적인 이유가 컸다.
- 언젠가 내가 직접 블로그를 처음부터 끝까지 만들어보고 싶었다
- 포트 번호가 없고 나만의 URL이 주는 그럴듯한 페이지의 느낌이 좋았다
- “서버 배포까지 해봤다”고 말하고 싶었다
문제는, 도메인을 산다고 서버가 생기는 건 아니라는 것을 그때는 체감하지 못했다는 점이다.
2. 서버? 일단 하나 만들어보자
다음 단계는 서버였다.
처음엔 Next.js를 사용해서 Vercel로 바로 배포할까 생각했었다.
하지만 Vercel로 웹 페이지를 만드는건 정말 내가 처음부터 끝까지 직접 블로그를 만들었다고 말하기는 어려울 것 같았다.
결국 선택한 건 가장 단순한 VPS였다.
- 우분투 서버
- SSH 접속
- 아무것도 없는 상태의 머신
접속해서 처음 본 화면은 이거였다:
Welcome to Ubuntu 22.04 LTS
그 순간 들었던 생각:
“아… 이제 진짜 내가 다 해야 하는구나”
하지만 지금은 AI 시대. AI의 도움을 한껏 받아보기로 했다.
3. AI의 도움으로 Next.js standalone + MDX 블로그를 만들다
블로그를 만들기로 했을 때 가장 먼저 고민한 건 이거였다.
- 서버에 부담이 크지 않을 것
- 배포가 단순할 것
- 글 작성은 최대한 개발자 친화적일 것
결론은 Next.js + MDX였다.
그리고 이 선택에는 솔직히 말해 AI의 도움이 굉장히 컸다.
standalone 모드 선택 이유
Next.js를 일반적인 방식으로 배포하면 의존성과 실행 환경 문제가 계속 따라온다.
그래서 output: 'standalone' 옵션을 선택했다.
// next.config.ts
const nextConfig = {
output: 'standalone',
};
export default nextConfig;
이 설정 덕분에 빌드 결과물은
Node.js 서버에서 바로 실행 가능한 하나의 독립된 앱이 되었다.
- node_modules 전체를 들고 다닐 필요가 없음
- Docker 이미지가 단순해짐
- 서버 환경 차이로 인한 문제 감소
AI에게 질문하면서 가장 많이 들은 조언도 이거였다.
“운영을 생각하면 standalone이 훨씬 낫다”
MDX로 블로그 업로드 구조 만들기
글 작성은 MDX 파일을 그대로 콘텐츠로 사용하는 방식으로 구현했다.
- /content/posts/*.mdx 구조
- Frontmatter로 메타데이터 관리
- 정적 생성(SSG) 기반 블로그
---
title: "블로그에 오신 것을 환영합니다"
date: "2025-12-11"
description: "Next.js로 만든 새로운 블로그를 소개합니다."
tags: ["Next.js", "React", "Blog"]
published: true
---
안녕하세요! Next.js 16과 TypeScript로 만든 새로운 블로그입니다.
Next.js에서는 MDX를 로드해서 페이지로 렌더링하도록 구성했다.
export async function generateStaticParams() {
// mdx 파일 목록 기반으로 slug 생성
}
이 과정에서도 AI의 역할이 컸다.
- MDX 파싱 구조 정리
- 빌드 시점 데이터 처리 흐름 정리
- 실수하기 쉬운 설정 포인트 짚어줌
이 시점에서는 꽤 만족스러웠다.
“이제 블로그는 대략 완성했으니까 서버에 올리기만 하면 된다.”
..... 근데 어떻게 올리지?
이 시점에서 나는 깨달았다.
내가 ssh로 서버를 접속 한 적은 있어도, 내가 ssh를 접속할 수 있게 세팅하거나 관리해 본 적은 없다는 것을...