제품을 만들 때 가장 빨리 사라지는 것은 코드가 아니라 판단의 맥락입니다. 어떤 라이브러리를 골랐는지, 왜 지금은 서버를 두지 않았는지, 왜 기능을 넣지 않았는지 같은 결정은 당시에는 선명하지만 며칠만 지나도 “그때 그게 최선이었나?”로 흐려집니다.
이 공간은 그 맥락을 보관하기 위한 작업 기록에 가깝습니다. 거창한 기술 미디어를 만들려는 것이 아니라, 작은 제품을 직접 만들면서 선택의 기준을 남기려는 쪽에 가깝습니다. 다만 기록의 기준은 가볍게 두지 않으려고 합니다. 읽는 사람이 “무엇을 했는지”보다 “어떤 기준으로 판단했는지”를 가져갈 수 있어야 하기 때문입니다.
좋은 기록은 결론보다 기준을 남긴다
개발 기록이 얇아지는 순간은 대체로 비슷합니다. 도구 이름과 결과만 남기고, 선택의 조건을 생략할 때입니다.
예를 들어 “Astro를 썼다”는 정보만으로는 재사용 가치가 낮습니다. 하지만 다음 질문에 답하면 기록은 설계 문서가 됩니다.
- 이 프로젝트는 어떤 트래픽과 운영 비용을 가정했나
- 검색엔진이 읽어야 하는 본문은 어디까지 정적 HTML로 보장할 것인가
- 다국어 URL과 canonical, alternate 링크는 어떻게 유지할 것인가
- 나중에 앱, 문서, 블로그가 갈라질 때 어떤 경계를 남겨둘 것인가
그런 질문을 글의 기본 단위로 삼습니다. 완성된 정답보다 판단 가능한 근거를 남기는 쪽을 선택합니다.
작은 제품일수록 운영 비용이 제품성을 결정한다
초기 제품은 기능보다 운영 비용이 먼저 발목을 잡는 경우가 많습니다. 서버를 하나 더 두면 자유도는 늘지만, 배포, 장애, 보안 업데이트, 로그, 비용 관리가 함께 따라옵니다. 반대로 정적 사이트는 표현의 제약이 있지만 읽기 성능과 운영 단순성이 강합니다.
첫 공개 표면은 블로그입니다. 사용자가 가입하거나 데이터를 저장하는 영역이 아니라, 제품을 만들며 축적되는 생각과 기술 노트를 보여주는 영역입니다. 그래서 첫 버전의 기준은 명확합니다.
- 본문은 빌드 시점에 HTML로 생성한다
- 글은 Markdown으로 관리하고 Git 이력에 남긴다
- SEO 메타, 사이트맵, RSS, 다국어 대체 링크는 자동 생성한다
- 검색, 댓글, CMS처럼 서버가 필요한 기능은 필요가 증명될 때 붙인다
이 기준은 “작게 만들자”는 감상이 아니라 제품의 생존 비용을 낮추기 위한 설계입니다.
앞으로 남길 것
이곳에는 세 종류의 글을 남깁니다.
첫째, 제품 판단입니다. 기능을 넣은 이유만큼 넣지 않은 이유도 기록합니다. 작은 제품은 무엇을 하지 않을지 정하는 시간이 길어질수록 방향이 선명해집니다.
둘째, 구현 기록입니다. Astro, GitHub Pages, 콘텐츠 컬렉션, 다국어 라우팅, SEO 구조화 데이터처럼 실제로 운영에 영향을 주는 기술 선택을 다룹니다. 단순 튜토리얼보다 “이 조건에서는 왜 이 구성이 맞았는가”에 집중합니다.
셋째, 운영 회고입니다. 배포 후 검색 노출, 페이지 속도, 글 구조, 유지보수 비용이 어떻게 변하는지 기록합니다. 제품은 배포한 순간 끝나는 것이 아니라 운영하면서 기준이 계속 수정되기 때문입니다.
참고한 기준
앞으로의 글은 가능하면 공식 문서와 공개 표준을 기준점으로 삼습니다. 검색 노출은 Google Search Central에서 권장하는 기본 구조를 우선 확인하고, 정적 배포와 도메인 연결은 GitHub Pages 문서를 기준으로 검증합니다. 콘텐츠 모델은 Astro Content Collections처럼 실제 빌드 단계에서 검증 가능한 방식에 맞춥니다.
기록이 쌓이면 초기 제품 판단을 되돌아볼 수 있는 문서가 됩니다. 오늘의 선택이 내일의 유지보수 비용을 줄이는지, 아니면 미래의 발목을 잡는지 계속 확인해 보겠습니다.
이어서 읽기
이 기록 방식이 실제 배포 흐름과 어떻게 연결되는지는 글을 관리하고 배포하는 방식에 정리했습니다. 서버를 두지 않는 선택이 어떤 장점과 한계를 갖는지는 정적 블로그를 선택한 이유에서 더 구체적으로 다룹니다.