gotchazipc

블로그를 다시 단순하게 만드는 중입니다

Thu, 01 Oct 2026 00:00:00 GMT

이 블로그는 글을 쓰는 도구와 공개하는 도구를 가능한 한 느슨하게 연결하려는 실험에서 시작했다. 원고는 평범한 Markdown으로 남기고, 사이트는 그 파일을 읽어 정적인 HTML을 만든다.

지금 중요하게 보는 것

글을 다른 도구로 옮겨도 내용이 그대로 남을 것
첫 화면을 보기 위해 큰 JavaScript bundle을 받지 않을 것
이미지나 영상이 긴 글의 스크롤을 방해하지 않을 것
기능을 추가하기 전에 실제 필요가 있는지 확인할 것

사이트의 형태는 아직 확정되지 않았다. 지금 보이는 화면은 글 목록, 본문, tag와 archive가 어느 정도의 밀도로 배치되는지 확인하기 위한 중간 결과다.

성능 점검 기준은 느린 페이지를 피하기 위해 확인할 것들에 정리했다.

좋은 기본값은 설명하지 않아도 동작하고, 필요하지 않을 때 존재감을 드러내지 않는다.

이 문장은 이번 작업의 기준을 간단히 요약한다. 기능보다 원고와 읽기 경험이 먼저다.

이 글은 화면 검토를 위한 임시 preview fixture이며 최종 게시물이 아니다.

원문 보기

느린 페이지를 피하기 위해 확인할 것들

Sat, 12 Sep 2026 00:00:00 GMT

페이지 속도는 숫자 하나로 설명되지 않는다. 첫 문장이 빨리 보이는지, 스크롤할 때 화면이 갑자기 움직이지 않는지, 링크를 누른 뒤 다음 문서가 자연스럽게 열리는지가 함께 작동한다.

기본 점검표

항목	확인할 내용
HTML	본문과 navigation이 JavaScript 없이 보이는가
이미지	실제 표시 크기에 맞는 파일을 내려받는가
영상	사용자가 누르기 전에 player를 만들지 않는가
글꼴	외부 font 요청 때문에 본문이 늦게 나타나지 않는가

측정 도구는 문제를 찾는 데 유용하지만, 긴 글을 직접 읽어 보는 과정도 필요하다. 특히 모바일에서는 작은 layout shift가 반복될 때 수치보다 더 크게 느껴질 수 있다.

content first
static HTML
media on demand

구현 단계에서는 이 세 줄을 유지하면서 각 기능이 정말 필요한 비용만 추가하는지 확인한다.

이 글은 화면 검토를 위한 임시 preview fixture이며 최종 게시물이 아니다.

원문 보기

작은 도구는 작게 유지하기

Tue, 08 Sep 2026 00:00:00 GMT

개인용 도구는 사용자가 한 명이라 요구가 단순해 보인다. 하지만 만드는 사람과 사용하는 사람이 같기 때문에 기능을 추가할 이유도 쉽게 늘어난다.

먼저 적어 둘 질문

지금 반복해서 겪는 문제가 무엇인가?
자동화하지 않아도 충분히 빠른가?
실패했을 때 원래 상태로 돌아갈 수 있는가?
다음 달에도 이 도구를 이해할 수 있는가?

예를 들어 파일 이름을 정리하는 명령은 다음처럼 입력과 출력을 분리하면 검토하기 쉽다.

type RenamePlan = {
  source: string;
  destination: string;
};

function preview(plan: RenamePlan[]) {
  return plan.map(item => `${item.source} -> ${item.destination}`);
}

실제 변경보다 preview를 먼저 제공하는 구조는 기능을 조금 늘리지만, 잘못된 자동화를 되돌리는 비용은 크게 줄인다.

이 글은 화면 검토를 위한 임시 preview fixture이며 최종 게시물이 아니다.

원문 보기

영화가 끝난 뒤 남는 장면

Fri, 04 Sep 2026 00:00:00 GMT

영화를 본 직후에는 줄거리보다 공간의 온도나 장면 사이의 간격이 먼저 남을 때가 있다. 정확한 대사를 옮기지 않아도, 화면이 어떤 속도로 움직였고 인물이 어느 순간 멈췄는지를 적으면 그날의 감각을 다시 찾을 수 있다.

감상을 남기는 순서

가장 먼저 떠오르는 장면 하나를 적는다.
그 장면 전후의 소리와 움직임을 적는다.
이해되지 않았던 부분은 결론을 내리지 않고 질문으로 남긴다.
며칠 뒤 다시 읽고 달라진 인상을 덧붙인다.

이 방식은 작품을 설명하기 위한 글보다 관람 경험을 보관하기 위한 글에 가깝다. 완성된 평론이 아니어도 되므로 기록을 시작하기가 쉽다.

기억은 장면을 그대로 저장하지 않고, 다시 떠올릴 때마다 조금씩 편집한다.

그래서 첫 기록의 날짜와 나중에 덧붙인 날짜를 함께 남겨 두는 편이 좋다.

이 글은 화면 검토를 위한 임시 preview fixture이며 최종 게시물이 아니다.

원문 보기

시스템 폰트로 시작하는 이유

Tue, 18 Aug 2026 00:00:00 GMT

새 사이트를 만들 때 font는 화면의 인상을 크게 바꾼다. 하지만 초기 단계에서는 특정 font 파일을 내려받는 것보다 운영체제가 이미 가진 글꼴로 문서 구조와 간격을 확인하는 편이 단순하다.

시스템 폰트를 사용하면 다음 항목을 먼저 볼 수 있다.

제목과 본문의 크기 차이가 충분한가
한글과 영문이 섞였을 때 행간이 안정적인가
긴 링크와 inline code가 모바일 폭에서 넘치지 않는가
굵기 차이가 light mode와 dark mode에서 모두 구분되는가

폰트 선택은 나중에 바꿀 수 있지만, 문서 구조가 복잡하면 글꼴만 바꿔서는 읽기 어려운 화면을 고치기 어렵다. 따라서 초기 검토에서는 구조와 여백을 먼저 본다.

이 글은 화면 검토를 위한 임시 preview fixture이며 최종 게시물이 아니다.

원문 보기