DanzzaN

개인사이트 설계와 운영의 의사결정 - Codex 대화

2026-09-1012 개인사이트의 목적·정보 구조·기술·배포·비용을 비교하며 채택한 이유를 증류했다. 구체적인 D-001D-016과 구현·배포 상태는 프로젝트 결정 기록과 Current가 소유한다. 이 노트는 다른 프로젝트에서도 다시 물을 수 있는 판단을 연결한다.

찾아온 사람이 읽는 구조

DanzzaN은 자신은 자리에 계속 있고 관심 있는 사람이 와서 보는 구조라고 설명했다. 발표 자료·광고 문구와 적극적인 PR을 기본으로 삼지 않는다. 이를 바탕으로 작성자가 차린 주제·문서 배치와 명시적 링크를 기본 동선으로 선택했다. 방문자 보기 전환의 가능성은 남겼고, 글 전개 선호와 시각 디자인은 별도 선택으로 두었다.

기업 기술 블로그를 참고한 것은 해당 기업을 선호해서가 아니라 구조와 글 구성을 관찰하기 위해서였다. 여러 작성자의 글과 글꼴·색감까지 조사한 결과를 개인 선호와 자동으로 합치지 않았다. 관찰, 재사용할 분석, 사용자가 고른 표현, 실제 채택 결정을 구분하는 사례다. 근거는 사이트의 태도와 분석 정리다.

링크 구조를 고른 뒤에도 관계 종류·이유·의미 방향을 별도 필드와 UI로 제공할 필요가 있는지는 다시 판단했다. DanzzaN은 파일명이나 본문에서 관계를 알 수 있으면 충분하다고 정정했다. 링크의 출발·대상을 유지하는 것과 관계의 의미를 별도 메타데이터로 입력하는 것은 서로 다른 요구다.

원천 Markdown을 그대로 읽는 문서 작성

2026-09-12 DanzzaN은 사이트에서 별도 이름을 덧씌우기보다 원천 Markdown의 제목과 본문을 그대로 보여준다는 점을 문서 작성에 반영하도록 요청했다. 관심 있는 사람이 정리된 내용을 찾아와 읽는 자리라는 태도를 유지하고, 방문자 유입·자기 홍보를 중심으로 구성하거나 발표 자료·광고의 표현을 쓰는 방향을 지양한다.

제목은 목록·검색·그래프·본문 링크에서 무엇을 읽게 될지 예상할 수 있게 쓴다. Atomic은 주장과 적용 범위를 드러내고, Map·Project·Source는 각 문서의 역할에 맞게 이름을 정한다. 도입·소제목은 다루는 내용과 문단 사이의 흐름을 드러내며, Map은 묶음·순서·링크 주변 설명을 함께 살핀다. 제목의 길이를 줄이는 것 자체를 목표로 삼거나 모든 글에 같은 전개·문체를 적용하지 않는다. 글 전개와 문체에 대한 개인 선호는 아직 정하지 않았다. 관계가 제목이나 본문으로 충분히 드러나면 별도 관계 필드를 추가할 필요도 없다.

문장을 다듬어도 주장·근거·인용·출처·불확실성과 개인 기록의 원래 목적을 보존한다. Markdown은 의미·문장·구조·연결을, 화면은 글자 크기·읽기 폭·여백·시각적 강조·같은 내용의 중복 표시를 맡는다. 화면에 맞추려고 원천을 과도하게 줄이거나 별도 사이트용 제목을 만들지 않는다. 기존 노트에서 효과를 확인할 범위부터 적용하고, 앞으로의 작성 기준은 VAULT_RULES > 작성과 연결에 둔다.

프로젝트의 읽기 흐름 원천의 「후속 선택과 문서 작성 방향」에서는 문서 작성 항목이 Codex의 검토 제안이었다. 이 절은 이번 Second Brain 반영 요청에서 DanzzaN이 직접 제시한 기준을 함께 대조해 정리한 채택 범위다. UI 원문의 저자 조언을 개인 취향으로 바꾼 것이 아니며, 읽기 흐름 A의 선택을 특정 글 전개·폰트·색의 승인으로 확대하지 않는다.

정본과 제공 경로

프로젝트의 코드·계획·운영 기록은 프로젝트 저장소, 개인 지식은 개인 Vault가 소유한다. 콘텐츠 입력·수정은 기존 AI·MCP 경로로 하고 사이트는 문서·그래프·현황 조회를 맡는다. 이 때문에 웹 편집기나 공개 MCP를 추가하는 것을 기본 요구로 삼지 않았다.

문서·링크·검색은 같은 버전의 게시 묶음으로 생성하고, 운영 관측은 별도 API로 읽는 C를 선택했다. 본문 갱신 주기와 운영 관측 주기를 한 주기로 묶지 않으면서, 본문과 검색의 버전이 섞이지 않게 하려는 선택이다. 갱신 실패 때 기존 문서를 유지하는 것과 최근 갱신이 성공했다고 표시하는 것도 구분했다.

사이트 콘텐츠는 공개를 기본으로 하고 치명적인 정보만 예외로 두었다. 미완성·개인적인 내용·공개 표시 부재를 자동 비공개 사유로 삼지 않으며, 홈에 배치하는 선택도 공개 여부와 별개다. 예외를 적용할 때에는 본문뿐 아니라 제목·첨부·검색·연결·과거 게시물의 제공 경로를 함께 본다. 이 원칙을 프로젝트 저장소의 공개 설정이나 PC의 임의 파일 공개로 확대하지 않는다. 데이터와 갱신 설계를 대조했다.

재사용할 기능과 새로 배울 책임

Next.js의 친숙함, Astro의 후보 적합성, Quartz의 Obsidian 문서 처리와 기존 링크·백링크·검색을 비교했다. 다른 도구에도 호환 수단이 있음을 확인한 뒤, 현재 요구에서 가져올 기능이 많은 Quartz를 선택했다. 이름난 도구나 호환 가능 여부 하나보다 실제 원천을 얼마나 그대로 살릴 수 있는지를 보았다.

Go 선택에는 다른 프로젝트의 경험도 들어갔다. DanzzaN은 FastAPI를 팀 프로젝트에서 충분히 사용할 예정이므로 개인사이트에는 Go를 골랐다. FastAPI가 부족하거나 모든 프로젝트에서 Go가 우월하다는 결론이 아니다. 직접 설치하는 EC2 운영도 구현·운영의 책임을 이해하며 배우려는 맥락에서 선택했다.

기술 비교를 대안 세 개로 임의 제한하거나 전체 조합을 한꺼번에 늘리는 대신, 문서 렌더링·운영 API·배포 책임처럼 선택이 달라지는 축으로 나눠 좁혔다. 채택한 방향 안의 일상적인 작업은 이어가고 계획과 달라지는 선택이 생길 때 다시 비교한다는 진행 방식도 확인했다.

운영 단계와 비용의 목적

v1 전에는 로컬 빌드·배포, 운영을 시작한 뒤 CI로 전환하기로 했다. 이는 자동화를 포기한다는 뜻이 아니라, 현재 단계와 반복 운영 단계에서 맡길 일을 구분한 선택이다. 실행 서버는 생성된 묶음을 제공하고 빌드 책임은 분리했다.

비용 우려를 처음에는 월 총예산처럼 다룰 수 있었지만 DanzzaN은 “자원비용은 상관 없지 요청 폭주에 대한 예방책이니까”라고 정정했다. 평소 유지비와 외부 요청에 따라 늘어나는 비용을 나눠야 한다. 필요한 경우 사이트 제공 중단도 허용했으므로 항상 제공하는 것만이 최우선 조건은 아니었다.

CloudFront 정액제 Free를 선택한 뒤에도 원본 우회, DNS 조회, 인증서 갱신·관리 경로를 따로 보았다. AWS 안에서 처리하는 Route 53 선택은 운영 도구를 늘리지 않으려는 판단이었고, DNS가 웹 차단의 보호 범위 밖이라는 점도 확인했다. 자동 중단·수동 재개를 채택했으며 제한 수치는 측정으로 정하기로 했다. 한 계층의 차단을 전체 비용 상한으로 표현하지 않는다.

t4g.small 한시 체험과 다른 사양에도 사용할 수 있는 계정 크레딧을 구분했던 과정은 ‘무료’의 조건을 읽는 사례다. 당시 금액·종료일·서비스 기능을 영구적인 지식으로 고정하지 않고 실제 사용할 시점에 공식 조건과 계정 적용을 확인한다.

측정이 답한 질문

실제 브라우저 탐색에서 첫 방문·문서 이동·검색·새로고침·상태 조회는 서로 다른 요청 수와 전송량을 보였다. 방문 횟수 하나로 모든 비용을 계산하지 않고 경로·캐시·전송량을 연결해야 한다. EC2 내부의 짧은 부하 시험 통과는 공개 인터넷 경로·TLS·CDN·장시간 처리량이나 차단·복구의 검증을 대신하지 않는다. 정확한 수치와 환경은 측정 기록에 둔다.

원천과 연결

그래프 뷰

백링크