기존 GitHub Pages 블로그를 Astro로 옮겼다. 원래는 Jekyll로 운영하고 있었고, 따로 만들어둔 Blogger 스킨도 있었다. Blogger 스킨을 먼저 만들고 나서 그 모양을 최대한 유지하는 방향으로 GitHub Pages 블로그를 다시 만든 셈이다.
처음에는 프레임워크만 바꾸고 글을 옮기면 금방 끝날 줄 알았다. 실제로 해보니 글보다 이미지 경로, 카테고리, 검색, 댓글, 모바일 화면처럼 블로그 주변에 붙어 있는 기능을 정리하는 데 시간이 더 많이 들었다.
Astro를 선택한 이유
GitHub Pages에 올리는 블로그라 서버 기능이 많이 필요하지 않았다. 글을 마크다운으로 관리하면서 정적 파일로 빌드할 수 있으면 충분했고, 기존 Jekyll보다 화면 구조와 컴포넌트를 직접 다루기 편한 쪽을 원했다.
Astro는 필요한 부분에만 JavaScript를 사용하면서 대부분을 정적 HTML로 만들 수 있다. 글 페이지처럼 내용이 중심인 사이트에 잘 맞아 보였고, 기존 마크다운 글도 크게 바꾸지 않고 가져올 수 있었다.
다만 Jekyll 저장소를 그대로 Astro로 바꾸는 일은 아니었다. 기존 글의 frontmatter와 폴더 구조를 새 콘텐츠 스키마에 맞춰 정리해야 했고, Jekyll에서 당연하게 처리되던 주소나 템플릿 동작도 다시 구현해야 했다.
글과 폴더 구조 정리
글 하나를 폴더 하나로 관리하고, 그 안에 index.md와 글에서 사용하는 이미지를 함께 넣는 구조로 바꿨다.
src/content/posts/
└── 01.DEV/
└── Flutter/
└── flutter-week-02/
├── index.md
└── example.webp처음에는 마크다운 파일과 이미지가 서로 다른 위치에 있어 경로를 확인하기 번거로웠다. 지금 구조에서는 글을 옮기거나 지울 때 관련 파일의 범위를 바로 알 수 있다. 수업 자료처럼 이미지가 많은 글도 한 폴더 안에서 정리할 수 있어서 관리하기 편해졌다.
각 글에는 제목, slug, 작성일, 카테고리 같은 정보를 넣었다.
---
title: Flutter 2주차 수업 정리
slug: flutter-week-02
description: Flutter 2주차 수업 개발 환경과 프로젝트 구조
publishedAt: '2025-03-11'
categories: Flutter
math: false
---Astro의 콘텐츠 스키마로 필수 항목과 형식을 검사하도록 했다. 글이 많아지면서 날짜나 slug를 잘못 적는 일이 생길 수 있는데, 빌드 전에 오류를 찾을 수 있다는 점이 괜찮았다.
이미지가 가장 큰 작업이었다
마이그레이션하면서 학교 수업 정리 글도 블로그로 옮겼다. 특히 데이터베이스시스템 글에는 캡처 이미지가 많아서 저장소 크기와 페이지 로딩이 걱정됐다.
이미지는 가능한 경우 WebP로 변환하고, Astro의 이미지 최적화를 거치도록 했다. 원본을 그대로 올렸을 때보다 파일 크기가 크게 줄었고, 이미지가 많은 글도 생각보다 부담 없이 빌드됐다.
이미지 파일명과 마크다운 경로를 함께 바꿔야 해서 이 부분은 수작업으로 했다면 상당히 오래 걸렸을 것 같다. 글 폴더 안에 이미지를 같이 두는 구조로 바꾼 것도 이 작업 이후였다.
Blogger 스킨과 화면 맞추기
기존 Blogger 스킨과 GitHub Pages 스킨은 거의 같은 모습으로 만들었다. 완전히 같은 코드를 사용하는 것은 아니어서 한쪽을 수정하면 다른 쪽의 간격이나 반응형 동작도 따로 확인해야 했다.
데스크톱에서는 본문과 우측 사이드바의 폭, 사이드바를 접었을 때 본문이 가운데로 오는 위치를 조정했다. 모바일에서는 사이드바가 글 아래로 내려가면서 생기는 좌우 여백과 글 목록의 간격을 주로 손봤다.
실제 휴대폰으로 보기 전에는 눈에 잘 들어오지 않던 문제가 많았다. 이전 글·전체 글·다음 글 버튼이 두 줄로 갈라지거나, 상단 메뉴가 화면 끝에 너무 붙거나, 글 목록만 다른 영역보다 좌우 여백이 좁은 식이었다. 개발자 도구의 모바일 화면만 보는 것과 직접 휴대폰에서 사용하는 것은 차이가 있었다.
테마와 코드 블록
라이트 모드와 다크 모드를 모두 다시 조정했다. 처음에는 기존 색을 조금씩 바꾸는 정도였는데, 다크 모드에 네온 계열의 강조색을 사용하면서 전체 배경과 본문 글자색도 같이 손봐야 했다. 강조색만 바꾸면 링크나 테두리가 지나치게 튀었고, 본문 색을 연하게 잡으면 긴 글을 읽기 어려웠다.
코드 블록은 일반 본문과 확실히 구분되도록 고정폭 글꼴, 줄 간격, 내부 여백과 문법 강조 색상을 따로 적용했다. Copy, Copied 같은 문구는 복사 아이콘과 완료 아이콘으로 바꿨다.
#include <iostream>
using namespace std;
int main() {
cout << "Hello, Astro!" << '\n';
return 0;
}글을 읽는 화면은 기능보다 작은 간격과 색 차이가 더 크게 느껴졌다. 한 번에 디자인을 끝내기보다 실제 글을 여러 화면 크기로 보면서 조금씩 수정하는 쪽이 나았다.
검색과 SEO
정적 블로그라도 글이 많아지니 검색이 필요했다. 빌드된 페이지를 기준으로 검색 인덱스를 만들고, 검색 결과에서 제목과 본문을 찾을 수 있도록 했다.
사이트맵, RSS, canonical URL, Open Graph 정보와 구조화 데이터도 함께 정리했다. 검색엔진에 글이 반드시 잘 노출된다고 보장할 수는 없지만, 적어도 크롤러가 페이지와 글 정보를 읽는 데 문제가 없는 구조를 만들려고 했다.
빌드 후에는 생성된 글 페이지 수, 설명이 빠진 글, 내부 링크 오류를 검사한다. 콘텐츠 원본도 별도로 검사해서 중복 slug나 존재하지 않는 이미지 경로를 배포 전에 찾을 수 있게 했다.
GitHub Pages 배포
Astro에서 정적 파일을 빌드한 뒤 GitHub Actions로 GitHub Pages에 배포한다. 글을 커밋하고 main 브랜치에 푸시하면 빌드와 배포가 이어지는 구조다.
Markdown 작성
→ 콘텐츠 검사
→ Astro 빌드
→ 검색 인덱스 생성
→ 결과물 검사
→ GitHub Pages 배포예전보다 빌드 과정은 조금 복잡해졌지만, 문제가 있는 글이 그대로 배포되는 경우는 줄었다. 로컬에서 전체 검사를 통과하면 실제 배포 결과도 어느 정도 예상할 수 있다.
옮기고 나서
Astro로 바꿨다고 글을 쓰는 방식 자체가 크게 달라진 것은 아니다. 여전히 마크다운 파일을 만들고 이미지를 같은 폴더에 넣는다. 달라진 점은 글과 화면 구조를 내가 원하는 방식으로 정리하기 쉬워졌고, 문제가 생겼을 때 어느 부분을 수정해야 하는지 비교적 명확해졌다는 것이다.
반대로 직접 관리할 부분도 늘었다. 검색, 댓글, 테마, 반응형 화면과 배포 설정을 모두 확인해야 하고, 작은 디자인 수정도 Blogger 스킨과 함께 맞추려면 일이 두 배가 된다.
그래도 기존 글과 수업 자료를 한곳에 모으고 나니 별도 저장소에 흩어져 있을 때보다 찾기 편하다. 블로그를 완전히 새로 만든 것보다는, 그동안 쌓인 글을 계속 관리할 수 있는 형태로 정리한 작업에 가까웠다.
아직 글을 더 써봐야 불편한 점을 알 수 있겠지만, 현재까지는 Jekyll에서 Astro로 옮긴 선택이 나쁘지 않았다고 생각한다.
흠…
라고 AI에게 긴 작업 후 회고글을 쓰게 시켰다.
굉장히 긴 작업이었고, 더운 날씨에 잠이 오지 않아 밤낮이 바뀐 상태로 이틀 정도 Codex 토큰을 녹이면서 작업했다. 1주치 한도 잠금 해제 같은 것을 받아둔 게 있었는데 그걸 두 개나 썼으니 꽤 긴 작업이었다.
가장 먼저 했던 것은 Blogger 스킨 제작이었다. Blogger 스킨은 XML 파일 하나 안에 모든 내용을 넣어야 했고, 어떻게 돌아가는지 알기 어려워서 예전에는 다른 곳에서 구한 스킨의 모양만 바꿔 사용하거나 무료 스킨을 받아 꽤 오랫동안 사용했었다. 몇 달 전까지만 해도 4,000줄이 넘는 파일을 읽고 깔끔하게 새로 스킨을 만드는 작업은 잘 되지 않았던 것으로 기억한다. 최근은 아니지만 Blogger 스킨을 다시 만들려고 시도했던 적도 있었는데… 이번에는 성공했다.
기존에 받아두었던 무료 스킨은 Blogger 템플릿의 구조를 파악하는 참고 자료로 사용했다. 스킨 안에는 특정 사이트로 이동시키는 리다이렉션과 그 동작을 알아보기 어렵게 만든 난독화 코드도 들어 있었는데, Codex가 해당 부분을 풀어서 어떤 식으로 동작하는지 분석했다. 기존 코드를 그대로 손보는 데서 끝내지 않고 새 템플릿에서는 그런 코드와 외부 의존성 없이 필요한 구조와 기능을 다시 작성했다. 이후에는 실제로 사용하면서 발견한 작은 문제를 하나씩 수정해 마무리했다.
어느 정도 완성되었을 때 GitHub Pages도 비슷한 형태로 재작성하도록 시켰다. Jekyll에서 가끔 오류가 나면 이전에는 그냥 업로드를 포기했었는데, 지금은 그럴 필요가 없어졌다. 무언가 시켜보면 GitHub Actions가 돌아가는 것까지 혼자 확인하면서 작업하고 있다.
GPT-2보다는 내가 실력이 확실히 더 좋았던 것으로 기억한다. 코딩을 잘하지 못하는 학생이 오픈북 시험에서 GPT를 사용했을 때보다 내가 받은 점수가 높기도 했다. GPT-3 때부터는 지치거나 내가 따라가기 어려운 부분에서 많이 사용하기 시작했고, Cursor가 나왔을 때는 감탄하면서 점점 AI에 의존하는 비중이 커졌다. 지금은 직접 코드를 작성하는 비중이 많이 줄었다. 가끔 문제를 풀면서 직접 코드를 쓰고 머리를 사용하는 것을 다행이라고 생각해야 할까… 복잡하게 얽힌 코드도 분석해 주는 세상이 왔으니, SNS에서 더 이상 난독화가 큰 의미가 없다는 이야기가 나오는 것도 이해가 간다.
Jekyll 블로그를 쓸 때도 조금씩 수정하다가 금방 한도에 도달해서 멈췄던 것 같은데, 이제는 이런 작업까지 가능한 세상이 왔다.
Astro로 개발한 다른 블로그를 찾아보다가 꽤 괜찮은 디자인의 GitHub 블로그를 발견하기도 했다. 블로그 글을 이용해 그래프를 만들고 메인 화면에 보여주는 기능도 있었는데, 내 블로그의 성격에는 꼭 필요하지 않은 것 같아 넣지 않았다. 어떤 기능을 더 넣을지 고민하기도 했지만, 추가하기 시작하면 끝이 없기도 하고 지금은 깔끔하게 두는 편이 좋아 보인다.
이전 블로그 구조에서도 글을 폴더로 묶고 그 안에 이미지를 바로 넣었다면 관리가 더 편했을 것 같다. Jekyll로 글을 쓰는 다른 사람들의 블로그 구조를 참고하다 보니 그렇게 할 생각은 하지 못했다. 지금 만들어둔 구조에서는 공부한 내용이나 필요한 것을 정리하기가 더 편하지 않을까 싶다. 이전에 수업을 정리했던 저장소를 블로그 글로 옮기는 일도 Codex에게 시켰고, 혼자 800개가 넘는 이미지를 읽고 압축하면서 순서와 이미지 경로까지 정리했다. 너무 심한 것 아닌가…? 원래는 내가 직접 쓴 글은 AI로 다듬지 않는 편인데. 불필요한 이야기가 있을까봐 이 부분도 글을 검토하도록 지시했다.
Comments