Codex와 함께 블로그를 만들고 배포하기

작업 목표

이번 작업의 목표는 Codex를 이용해 개인 기술 블로그의 현재 상태를 확인하고, AWS 기반 배포 환경을 정리한 뒤, 구매한 도메인을 블로그 주소로 사용할 준비를 하는 것이었다.

블로그는 Markdown 파일을 글로 사용하고, 빌드 결과물을 S3에 올린 뒤 CloudFront로 배포하는 정적 사이트 구조다. 글은 content/posts/{category-slug} 폴더에 추가하고, 카테고리는 Codex 사용하기, Unity, C#, WPF, MVC Framework로 나누어 관리한다.

Codex에게 작업 맥락 전달하기

이 블로그는 한 번에 처음부터 끝까지 만든 것이 아니라, 이전 채팅에서 진행한 작업 요약을 Codex에게 전달하고 이어서 작업하는 방식으로 만들었다.

새 채팅을 시작할 때는 아래처럼 프로젝트의 핵심 정보를 먼저 알려주었다.

블로그 저장소: https://github.com/jjr2930/MyBlog
로컬 clone 위치: D:\Work\Blog
배포 URL: https://d28clw01bix5iw.cloudfront.net/
S3 버킷: joojungyeolblog
CloudFront Distribution ID: E3SQ1R7U3B4MHU
블로그는 Markdown 기반 정적 사이트
글 위치: content/posts/{category-slug}/*.md
카테고리: Codex 사용하기, Unity, C#, WPF, MVC Framework
카테고리 페이지:
  /categories/codex/
  /categories/unity/
  /categories/csharp/
  /categories/wpf/
  /categories/mvc-framework/
GitHub에서 글을 작성하고, 아직 자동 배포는 붙이지 않음

이렇게 정리된 정보를 먼저 넘겨주면 Codex가 저장소 구조를 다시 파악하는 시간을 줄일 수 있다. 또한 어떤 파일을 수정해야 하는지, 어떤 AWS 리소스를 기준으로 설명해야 하는지, 현재 자동화가 어디까지 되어 있는지 바로 이어서 판단할 수 있다.

이번 글도 Codex에게 "현재까지의 작업을 Codex 사용하기 카테고리로 문서화하자"고 요청해서 작성했다. 이후 로컬 브라우저에서 글을 확인하고, 필요한 문장을 추가하거나 섹션을 다듬는 식으로 블로그 내용을 계속 개선했다.

현재 블로그 구조

블로그의 기본 흐름은 다음과 같다.

Markdown 글
→ 정적 HTML 빌드
→ S3 버킷 업로드
→ CloudFront 배포
→ 사용자 접속

현재 배포는 CloudFront 주소로 접속할 수 있고, 나중에 Route 53에서 구매한 도메인을 CloudFront에 연결하면 사용자는 직접 구매한 도메인으로 블로그에 들어올 수 있다.

AWS 액세스 키 정리

이전 작업에서 AWS Access Key가 채팅에 노출되었기 때문에, 먼저 기존 키를 삭제하거나 비활성화해야 했다. 액세스 키는 한 번 외부에 노출되면 다시 안전하다고 보기 어렵기 때문에, 사용하지 않고 새 키로 교체하는 것이 맞다.

IAM에서 액세스 키를 정리하는 기본 순서는 다음과 같다.

IAM 사용자 선택
→ Security credentials
→ Access keys
→ 기존 키 비활성화 또는 삭제
→ 새 키 생성

새로 만든 키는 로컬 CSV 파일로 보관하되, 절대 Git에 커밋하지 않아야 한다. Codex로 배포 작업을 할 때도 키 값을 채팅에 출력하지 않고, 필요한 명령을 실행할 때만 임시 환경 변수로 사용하는 방식이 안전하다.

도메인과 인증서

AWS에서 구매한 도메인을 CloudFront 블로그 주소로 사용하려면 ACM 인증서가 필요하다. 여기서 중요한 점은 CloudFront에 연결할 인증서는 서울 리전이 아니라 반드시 us-east-1 리전에서 만들어야 한다는 것이다.

인증서 생성 흐름은 다음과 같다.

ACM us-east-1에서 인증서 요청
→ 도메인과 www 도메인 추가
→ DNS validation 선택
→ Route 53에 검증용 CNAME 생성
→ 인증서 상태가 Issued가 될 때까지 대기

검증 시간이 초과되었다면 대부분 ACM이 요구한 CNAME 레코드를 공개 DNS에서 찾지 못한 경우다. Hosted Zone이 잘못되었거나, 도메인의 네임서버와 Route 53 Hosted Zone의 NS 레코드가 맞지 않거나, 검증 레코드를 만들지 않은 경우를 먼저 확인해야 한다.

CloudFront에 도메인 연결하기

인증서가 Issued 상태가 되면 CloudFront 배포에 도메인을 추가할 수 있다.

CloudFront 배포 선택
→ Alternate domain name에 도메인 추가
→ us-east-1 ACM 인증서 선택
→ Route 53에서 A/AAAA Alias 레코드를 CloudFront로 연결

이렇게 연결하면 https://구매한도메인 또는 https://www.구매한도메인 주소로 블로그에 접속할 수 있다.

로컬에서 블로그 확인하기

블로그를 배포하기 전에 로컬에서 확인할 수 있도록 개발 서버를 사용한다.

cd D:\Work\Blog
npm run dev

서버가 실행되면 브라우저에서 아래 주소로 접속한다.

http://localhost:4173/

처음에는 파일을 수정한 뒤 직접 다시 빌드해야 했지만, scripts/serve.mjs를 수정해서 content, public, scripts 폴더의 변경을 감지하도록 만들었다. 이제 글이나 스타일을 수정하면 자동으로 다시 빌드되고, 브라우저에서 새로고침하면 최신 화면을 확인할 수 있다.

정리

이번 작업으로 Codex를 이용해 블로그의 로컬 확인 흐름, AWS 키 관리 주의사항, CloudFront용 도메인 인증서 준비, Route 53 연결 절차를 정리했다.

중요한 점은 Codex에게 새 작업을 맡길 때 현재 상태를 짧고 정확하게 알려주는 것이다. 저장소 위치, 배포 주소, 주요 AWS 리소스, 글 위치, 카테고리 구조처럼 작업을 이어가는 데 필요한 정보를 먼저 주면 Codex가 훨씬 빠르게 실제 수정 작업으로 들어갈 수 있다.

다음 단계는 ACM 인증서 검증을 정상적으로 완료한 뒤, CloudFront 배포에 실제 도메인을 연결하고 Route 53 Alias 레코드를 설정하는 것이다.