Project Archipelago 블로그를 본앱에서 분리한 이유는 단순히 폴더를 깔끔하게 만들기 위해서가 아니다. 제품을 만드는 일과 그 과정을 설명하는 일은 서로 연결되어 있지만, 같은 배포 흐름 안에 있을 필요는 없었다.

오히려 함께 있을 때 생기는 문제가 있었다. 제품 코드를 수정하는 일과 블로그 글을 고치는 일이 같은 저장소, 같은 배포, 같은 변경 묶음 안에 섞이면 판단이 흐려진다. 글 하나를 고치기 위해 제품 런타임을 건드리는 것처럼 보일 수 있고, 반대로 제품 변경 중에 공개 글이 따라 움직일 수도 있다.

그래서 블로그를 독립 프로젝트로 떼어냈다.

글쓰기는 제품 배포와 다른 리듬을 가진다

제품 배포는 기능의 안정성, 테스트, 사용자 영향 범위를 중심으로 움직인다. 블로그 글은 다르다. 문장을 고치고, 공개 범위를 확인하고, 설명의 톤을 다듬는 일이 더 중요하다.

두 작업의 리듬이 다르면 분리하는 편이 낫다. Project Archipelago 본앱은 실제 기능과 데이터 흐름을 다룬다. 블로그는 공개 가능한 설명, 포트폴리오, 작업 기록을 다룬다. 둘은 서로를 참조할 수 있지만, 같은 속도로 움직이지 않아도 된다.

이 분리는 특히 교육 도구를 만들 때 중요하다. 내부 판단, 학생 관련 데이터, 아직 공개하면 안 되는 기능 설명이 섞이지 않도록 경계가 필요하다.

포트폴리오는 설명의 장소다

블로그는 제품 매뉴얼이 아니다. 또 단순한 업데이트 로그도 아니다. 내가 어떤 문제를 중요하게 보았고, 어떤 기준으로 기능을 나누었고, 어떤 부분을 아직 보류했는지 설명하는 장소다.

그래서 블로그의 글은 제품 기능보다 한 걸음 떨어져 있어야 한다. “이 기능이 있다”보다 “왜 이 기능이 필요한가”를 먼저 써야 한다. “어떻게 만들었다”보다 “어떤 판단을 지키려 했는가”가 더 중요할 때도 있다.

독립된 블로그는 그런 글쓰기에 맞다. 글을 먼저 다듬고, 필요한 경우에만 제품 문서나 코드와 연결하면 된다.

기술적으로도 분리가 낫다

블로그는 처음에는 정적 Astro 사이트로 충분했다. Markdown으로 글을 쓰고, 빌드해서 배포하면 된다. 이후 웹에서 글을 쓰고 댓글을 승인하는 기능이 필요해지면서 Cloudflare D1 기반 관리자 구조를 붙였다.

이 변화도 독립 프로젝트였기 때문에 비교적 안전하게 할 수 있었다. 본앱의 인증, 데이터베이스, 사용자 기능과 섞지 않고 블로그에 필요한 만큼만 동적 기능을 추가했다. 글쓰기와 댓글이라는 공개 콘텐츠 관리 문제에 집중할 수 있었다.

아직 남은 일도 있다. Cloudflare D1 실제 생성, 관리자 비밀번호 설정, 원격 migration, 도메인 연결이 필요하다. 하지만 구조는 분명해졌다. 제품은 제품답게, 블로그는 블로그답게 운영할 수 있다.

다음 글에서는 이 블로그에 웹 편집과 댓글 승인 구조를 붙인 이유를 조금 더 구체적으로 정리한다.