④ 1인 개발·운영 · 기록
이 사이트를 혼자 만들고 한 달 방치한 기록
무료로 돌게 만든 자동화는 한 달간 하루도 안 빠지고 돌았다. 멈춘 건 사람이 하는 일이었다. 무엇을 접었고 어떤 전제가 틀렸는지 남겨둔다.
이 사이트는 혼자 만들고 혼자 운영한다. 정적 사이트 생성기로 글을 렌더하고, 매일 도는 수집기가 기술 동향을 모으고, 커밋하면 자동 배포된다. 서버도 데이터베이스도 없고 운영비는 0 이다.
만들어놓고 한 달을 손대지 않았다. 그 한 달이 오히려 쓸 만한 기록이 됐다.
읽기 전에 한 번 골라보기
한 달간 아무도 손대지 않았다. 무엇이 가장 먼저 멈췄을까?
기계는 멈추지 않았다
수집기는 32일간 하루도 빠지지 않고 돌아 자동 커밋 32개를 쌓았고, 그 커밋마다 재배포가 돌아 사이트는 계속 최신이었다. 같은 기간 새 글은 0편이다. 무료로 돌게 만든 쪽은 방치를 견뎠고, 사람이 해야 하는 쪽이 먼저 멈췄다.
무료로 돌게 만든 것들
처음 정한 제약은 하나였다. 돈이 들면 안 된다. 개인 프로젝트에 월 구독을 붙이면 관심이 식는 순간 그게 먼저 아깝다. 그래서 세 가지를 그 제약 안에서 만들었다.
- 동향 수집. 소스에서 읽어 중복을 제거하고 발췌를 요약으로 쓴다. 처음엔 요약에 LLM 을 붙이려 했는데, 붙이지 않고 만들어보니 발췌만으로도 읽을 만했다. API 키도 비용도 없다.
- 정기 실행. 저장소에 딸린 자동화가 하루 한 번 수집기를 돌리고 결과를 커밋한다. 무료 사용량 안에서 끝난다.
- 배포. 정적 출력이라 커밋이 곧 배포다. 서버 관리가 없다.
한 달 뒤에 확인해보니 자동 커밋이 32개 쌓여 있었다. 하루도 빠지지 않았다. 내가 그 사실을 몰랐던 건 확인하지 않았기 때문인데, 그게 이 구조의 장점이자 함정이다 — 조용히 잘 도는 자동화는 잘 돌고 있다는 사실도 알려주지 않는다.
- 매일 수집 — 자동 커밋 32개
- 커밋마다 재배포
- 비용 0
- 알림도 없었다(볼 사람이 나뿐이라)
- 새 글 0편
- 도구 비교 실험 미실행
- 방향 결정 보류
- 지침 파일 정리 미룸
접은 것들
만든 것보다 접은 것이 기록으로 더 값을 한다. 안 남겨두면 같은 것을 또 만든다.
정적 HTML 프로토타입. 처음에는 손으로 쓴 HTML 한 장으로 목표 화면을 만들었다. 레이아웃과 색을 빠르게 확인하는 데는 좋았는데, 문서가 열 편을 넘자 네비게이션과 목차를 손으로 유지하는 게 불가능해졌다. 정적 사이트 생성기로 옮기고 프로토타입은 참고용으로만 남겼다. 접은 신호는 명확했다 — 글 한 편 추가에 손댈 파일이 세 개를 넘었을 때.
도구 역할 분리 글. 세 도구의 자리를 나누는 글을 계획했다가 지웠다. 그중 하나를 실제로 쓰지 않고 있었기 때문이다. 안 써보고 비교하는 글은 이 프로젝트가 피하려는 바로 그 글이다.
주제를 AX 하나로 좁힌 것. 이게 가장 큰 폐기다. 처음에는 AX(업무 구조 재설계) 하나만 다루기로 했다. 그런데 이틀에 열네 편을 몰아 쓰고 나서 한 달간 한 편도 못 썼다. 주제가 좁아서 직접 해본 재료가 먼저 바닥난 것이다. 실제로 배우고 있는 범위는 그보다 넓었는데 억지로 한 주제에 붙이지 않으려니 쓸 게 없었다. 결국 범위를 다섯 갈래로 넓혔다. 접은 신호는 한 달 0편이었다.
계획했던 비교 컴포넌트. 화면 목업에 축 필터가 붙은 비교 표를 넣어뒀는데, 실제 글의 비교는 세 줄에서 네 줄이었다. 필터는 줄이 많을 때만 값을 한다. 만들지 않기로 하고 그 이유를 적어뒀다 — 나중에 같은 것을 다시 그리지 않기 위해.
틀렸던 전제 두 개
“이름을 바꾸면 기존 링크가 깨진다.” 프로젝트 이름을 바꾸면서 배포 URL 도 함께 바뀌니 예전 주소로 공유한 링크는 못 살린다고 판단했다. 실제로 확인해보니 예전 주소가 그대로 최신 배포를 서빙하고 있었다. 저장소 쪽도 예전 주소가 리다이렉트로 이어졌다. 손실을 감수하기로 하고 옮겼는데, 감수할 손실이 없었다. 확인하기 전에 판단했던 것이다.
“요약에는 LLM 이 필요하다.” 자동 수집을 설계할 때 요약 품질을 걱정해서 유료 호출을 전제로 잡았다. 발췌만 쓰는 버전을 먼저 만들어보니 읽는 데 지장이 없었다. 유료 옵션은 스위치로 남겨뒀지만 한 번도 켜지 않았다.
둘 다 같은 실수다. 확인할 수 있는 걸 확인하지 않고 전제로 삼았다. 앞의 것은 비용을 지불할 뻔했고, 뒤의 것은 실제로 비용을 붙일 뻔했다.
문서로 적은 규칙과 빌드가 막는 규칙
가장 만족스러운 변경은 기능이 아니라 제약이었다.
글마다 분류와 검증 정보를 넣기로 정하고 지침 파일에 적어뒀다. 그런데 지침은 지켜지지 않을 수 있다. 그래서 콘텐츠 스키마에 두 가지 검사를 넣었다.
- 아직 제대로 해보지 않은 주제에서는 “이렇게 하면 된다” 류의 글을 쓸 수 없다. 그 조합이면 빌드가 실패한다.
- 출처를 적었으면 확인한 날짜도 적어야 한다. 없으면 빌드가 실패한다.
지키라고 적어두는 것과 안 지키면 안 도는 것의 차이는 크다. 특히 혼자 할 때 그렇다 — 리뷰해줄 사람이 없으니 규칙을 어기는 걸 아무도 안 잡아준다. 문서에 적은 규칙은 나를 설득해야 하고, 빌드에 넣은 규칙은 나를 막아준다.
지금 남은 판단
한 달을 놓친 뒤 내린 결정은 자동화를 늘리는 게 아니었다. 재료가 나오는 범위로 주제를 다시 잡는 것이었다. 무료 자동화는 방치를 견뎠으니 더 손댈 이유가 없었고, 병목은 분명히 사람 쪽이었다.
그래서 다음에 확인할 것은 하나다. 범위를 넓힌 뒤에 실제로 글이 계속 나오는가. 이건 지금 답할 수 없고, 다음 한 달이 답한다. 그때 이 문서에 결과를 덧붙인다.
- 초안 작성. 한 달 방치의 결과(자동 커밋 32개 vs 새 글 0편), 접은 것 네 가지, 틀렸던 전제 두 가지, 규칙을 빌드로 옮긴 이유 (성숙도: 탐색 중)
- 범위를 넓힌 뒤 글이 실제로 계속 나오는지 — 다음 한 달의 결과를 덧붙인다