프로젝트
쓰는 쪽만 보고 만든 사이트를 읽는 쪽에서 열었다
글을 쌓는 장치는 만들었지만 독자가 키워드로 찾고 긴 글을 훑고 코드를 가져가는 길은 부족했다. 검색·목차·코드 복사·분량 표시와 이동 경로를 보완하며 확인한 선택과 한계를 정리한다.
#기록 아티클 목록
프로젝트
「비공개 모드」라고 이름 붙였는데 비공개가 아니었다
도메인을 붙이고 나서 사이트를 검색에서 빼는 스위치를 넣고 「비공개 모드」라고 불렀다. 이름을 「색인 차단 모드」로 고친 뒤, Google 공식 문서와 현재 Worker 구성을 다시 대조해 이 설정이 보장하지 않는 범위까지 정리했다.
프로젝트
커밋 39개에서 시작한 저장소 감사는 61개에서 끝났다
39번째 커밋에서 기준선을 잡아 61번째 병합 커밋까지 진행한 저장소 감사 기록. 미실행 검사와 기존 실패도 기준선에서 분리하고, 보류한 의존성이 Worker 추가 뒤에도 배포 런타임에 도달하는지 다시 확인했다.
프로젝트
카테고리를 아무리 나눠도 읽는 순서는 안 고쳐졌다
한 줄로 이어지는 여덟 편이 목록에서 항상 마지막 편부터 읽혔다. 카테고리를 쪼개 보다가 이게 분류의 문제가 아니라는 걸 알고, 순서를 별도의 축으로 분리한 기록. 출처를 분류로 만들지 않기로 한 이유까지.
프로젝트
공개 범위를 사람이 아니라 명령이 확인하게 했다
초기 /resume 한 경로의 빌드 결과물 검사에서 현재의 /resume·/share/shell 상시 비노출 검사와 전역 색인 차단 검사로 확장한 과정을 정리한다. 명령이 확인하는 범위와 검색 제외·접근 제어의 차이도 함께 구분한다.
프로젝트
배포 경로를 갈아타고, 옛 경로를 지우기까지 닷새가 걸렸다
임시 주소의 사이트를 Cloudflare Workers Static Assets로 옮긴 뒤 옛 빌드 경로를 걷어 냈다. 당시의 정적 전용 배포와 지금의 /share 전용 Worker, 검증된 dist를 올리는 현재 배포 경계를 시점별로 다시 정리한 기록.
프로젝트
PC 두 대를 오가며 깨지는 지점만 명령 하나로 걷어냈다
집과 회사에서 같은 저장소를 만지면 git이 옮기지 않는 것들 때문에 한쪽에서만 빌드가 깨진다. 동기화를 새로 만드는 대신 깨지는 지점 하나만 자동화한 기록과, AI 사용량을 PC별로 나눠 저장해야 했던 이유.
프로젝트
관리자 저장에서 오탈자까지 「업데이트」로 표시되지 않게 했다
관리자 편집 저장에서는 공개 상태·내용 변경·게시일 이후라는 세 조건으로 수정일을 갱신한다. 볼트 재반입은 별도 규칙이라는 경계와 수정 크기별 공개 원칙을 함께 정리했다.
프로젝트
자격증명 검사를 경고가 아니라 중단으로 뒀다
실습 기록에는 토큰이 섞여 들어온다. 경고만 띄우고 저장은 되게 할 생각이었다가 중단으로 바꾼 이유와, 강제 통과 버튼을 두지 않은 이유. 그리고 그 검사가 콘텐츠 파일만 보고 있었다는 것을 나중에 발견한 기록.
프로젝트
관리자 화면이 필요했는데 사이트를 서버 렌더링으로 바꾸지 않았다
브라우저에서 글을 쓰고 이미지를 끌어다 놓는 편집 화면이 필요했다. 그것을 사이트 안에 두면 쓰기 API가 공개 사이트에 함께 올라간다. 편집 편의와 공개 표면을 맞바꾸지 않으려고 관리자를 저장소의 scripts/ 안에 두고 공개 배포 산출물에서 제외한 기록.
프로젝트
코드 리뷰에서 나온 지적이 대부분 같은 모양이었다
만든 지 일주일 된 저장소를 리뷰했더니 지적의 절반이 「같은 사실이 두 곳에 적혀 있다」였다. 다섯 건을 단일 소스로 합친 과정과, 잠시 어긋났던 AI 활용 표시 원칙을 다시 맞춘 이력을 정리한다.
프로젝트
볼트는 저장소 밖에 두고 관리자 큐만 좁혔다
옵시디언 볼트 전체를 저장소와 동기화하지 않고 관리자의 반입 대기열을 30-publish로 좁혔다. CLI는 임의 노트와 --publish를 받는 별도 진입점이며, 두 경로가 공통 변환·민감정보 검사를 쓰는 범위와 한계를 정리했다.
프로젝트
형식이 틀린 글은 배포가 아니라 빌드에서 멈추게 했다
카테고리 오타 하나가 목록에서 조용히 빠지는 글을 만든다. 콘텐츠 스키마와 교차 파일 검증으로 어긋난 값을 배포 전에 막고, 개발일지의 카테고리 예외와 오류·경고의 현재 경계를 다시 정리한 기록.
블로그를 시작하며: AI와 보안을 검증 가능한 기록으로 남기기
빠른 요약보다 출처와 확인 범위가 남는 기술 기록을 지향하는 이유를 정리했습니다. AI의 도움을 받은 내용에서 직접 실습한 결과와 문서로 대조한 사실, 아직 확인하지 못한 가정을 구분하는 운영 원칙을 설명합니다.