두 번째 빌드. 이 글 자체가 이번에 만든 파이프라인(md 커밋 → 자동 발행)으로 게시된 첫 글입니다.

문제

격주 빌드 루프가 돌기 시작했는데 글의 집이 없었다. 리포트 01은 원페이지의 접이식 블록과 repo README에 임시로 살고 있었고, 글이 쌓일 아카이브와 “md를 쓰면 자동으로 발행되는” 경로가 없으면 루프의 유지비가 커진다.

만든 것 / 버린 것

• 만든 것: Astro 기반 /blog. 카테고리 3탭(빌드·학습·취미), 개시 글(리포트 01), RSS·sitemap·robots·canonical, 그리고 push → GitHub Actions → 자동 배포 파이프라인.
• 버린 것: 그래프 뷰(옵시디언식)와 글→퀴즈 자동 생성. 각자 온전한 빌드 한 회를 받을 체급이라 후속으로.

AI에게 맡긴 것

Astro 기본 골격 전체(생성 도구 없이 파일 직접 작성), 레이아웃·목록·상세·카테고리 페이지, SEO 세트, Actions 워크플로우, 리포트 01의 아티클 이식.

직접 판단한 것

• 블로그를 링크드인 개설보다 먼저 (순서 결정)
• 그래프·퀴즈를 후속으로 분리 (4시간 안에 다 넣고 싶은 유혹 거부)
• 네이밍: “러닝 로그”를 **“학습 로그”**로, 소개는 “만들고 배운 것을 기록합니다.” 한 문장으로
• 기존 원페이지 보존 전략 승인: public/에 원본 그대로 두어 기존 페이지가 깨질 위험을 구조적으로 차단

검증

비교 검사로 원페이지가 한 글자도 달라지지 않았음을 증명하고, 로컬 빌드·프리뷰 확인 후 배포. 완료 기준 5개 전부 달성. 푸시 후 36초 만에 자동 배포되며 “md 추가 → push → 반영”이 실증됐다. 제한 시간 21분.

막힌 것

• 파일을 public/으로 옮기자 편집 도구가 새 경로의 재읽기를 요구했다. 다시 읽고 진행.
• 셸 작업 디렉토리가 명령마다 초기화돼 빌드 명령이 한 번 빈 디렉토리에서 실패했다. 경로 명시로 해결.
• 사소한 것들이지만, 기록해 두면 다음에 같은 곳에서 안 넘어진다.

Q&A

Q. 첫 빌드에서 “프레임워크는 과잉”이라더니 왜 이제 Astro인가 — 문제의 체급이 변했다. 정적 한 장은 바닐라가 맞았고, 계속 쌓이는 콘텐츠 시스템은 콘텐츠 도구가 맞다. “도구는 문제 크기에 맞게”라는 같은 기준의 일관된 적용이다.

Q. 21분이면 문제가 너무 쉬웠던 것 아닌가 — 이번 회차의 난이도는 코드가 아니라 전환 설계(기존 페이지를 깨뜨리지 않는 전환 경로)와 파이프라인 실증에 있었다. 남은 시간은 다듬기가 아니라 표준 장비(SEO 세트) 장착에 썼다.

회고

• 늘어난 것: 발행이 md 커밋 1개로 줄었다. 범위 절단 속도가 빨라졌다. “막힌 것”을 기록하는 습관을 시작했다.
• 다음에 고칠 것: 사용자에게 보이는 이름·문구는 빌드 시작 전에 확정할 것. 이번에도 배포 직전에 네이밍 수정이 들어왔다. 이름은 코드보다 먼저 정하는 게 싸다.