kese

책상 위 물건들의 기록 (2026)

Mon, 05 Oct 2026 00:00:00 GMT

리뷰가 아니라 목록이다

이 글은 물건의 사양을 비교하는 글이 아니다. 책상에 실제로 놓여 있는 것들과, 그것들이 내 하루에서 하는 일의 기록이다.

책상 위에 있는 것들

키보드와 트랙패드. 매일 손이 닿는 도구라 익숙한 것을 그대로 쓴다. 새로운 입력 장치를 바꾸는 비용은 학습 시간이지 가격이 아니다.

모니터와 받침. 화면을 눈높이로 올린 뒤 목이 덜 아프다. 받침 아래에는 서류가 들어가는데, 이게 의도치 않은 수납 공간이 됐다.

물컵과 코스터. 컵은 자주 비우고 자주 채우는 크기가 좋다. 코스터는 책상 표면을 지키는 가장 싼 방법이다.

메모지. 아날로그 메모는 "나중에 옮길 것"이라는 조건으로만 존재한다. 옮기지 않을 메모는 처음부터 쓰지 않는다.

물건의 기준

책상에 올라가는 기준은 하나다: 일주일에 한 번 이상 손이 가는가. 그렇지 않은 것은 서랍으로 가거나 나간다. 이 기준 덕분에 책상은 항상 가벼운 상태로 돌아온다.

전자책 단말기를 다시 꺼낸 이유

Mon, 05 Oct 2026 00:00:00 GMT

서랍에서 나온 이유

전자책 단말기는 산 지 오래됐지만 서랍에 들어가 있었다. 다시 꺼낸 계기는 단말기가 아니라 폰의 독서 경험이었다. 짧은 글은 폰으로 읽어도 되는데, 긴 글은 알림과 다른 앱이 계속 끼어든다.

달라진 것

단말기에서 책을 읽으면 할 수 있는 일이 하나뿐이다. 그게 단점처럼 들리지만 실은 장점이다. 읽는 동안 선택지가 없으니 딴짓이 줄고, 밤에 읽어도 화면 조명을 낮게 둘 수 있다.

그래도 폰이 나은 경우

잠깐의 대기 시간 — 단말기를 꺼내는 것보다 폰이 빠르다
글을 찾아 읽는 것 — 기술 문서나 짧은 글은 폰 브라우저가 낫다
형광펜 대신 스크린샷이 필요할 때

정리

도구는 채우는 게 아니라 자리를 만들어준다. 전자책 단말기는 "긴 글을 읽는 자리"를 만들어 줬다. 그 자리가 생기니 밤에 책을 다시 읽게 됐다.

에디터 설정을 줄이는 연습

Sun, 04 Oct 2026 00:00:00 GMT

플러그인은 뺄수록 남는 게 있다

에디터를 꾸미다 보면 글쓰기보다 꾸미기에 시간이 간다. 최근에 플러그인을 몇 개 빼고 지켜보니, 남는 것이 분명해졌다.

남긴 것:

글의 구조를 보여주는 개요(outline) 패널
미리보기 하나 — 마크다운 렌더 결과를 바로 옆에 두는 것
저장 즉시 커밋되는 단순한 동기화

뺀 것:

문법 교정 확장 — 도구가 제안하는 문장이 내 문장을 지운다
테마와 아이콘 팩 — 예쁘지만 글과 무관하다
자동 완성 — 글쓰기에는 방해가 된다

원칙으로 정리하면

도구의 기본값을 고치지 말고, 빼는 방향으로만 설정한다. 설정 파일이 짧을수록 새 환경에서 복원이 빠르다. 글쓰기 도구의 이상적인 설정 파일은 거의 비어 있다.

마크다운으로 글을 쓰는 나의 흐름

Sun, 04 Oct 2026 00:00:00 GMT

한 파일이 끝까지 간다

이 블로그의 글은 마크다운 파일이다. 메모 앱에서 아이디어를 적는 순간부터 마크다운으로 시작하면, 저장소에 옮기는 순간의 번역 비용이 사라진다. 글 하나가 디렉터리 하나라서 이미지도 같은 폴더에서 관리한다.

내가 지키는 순서

메모: 떠오른 문장을 그대로 적는다. 문장이 아니라 파편이어도 된다.
브리프: 글로 쓰기 전에 다섯 줄을 채운다 — 이 글이 답하는 질문, 한 문장 답, 근거, 하위 질문, 연결할 내부 링크. 채울 수 없으면 아직 쓸 글이 아니다.
초안: 브리프를 펼쳐 본문으로 만든다. 소제목은 실제 질문이나 명제를 그대로 쓴다.
검수: 소리 내어 읽고, 수치와 인용의 출처를 다시 연다. 링크가 끊기지 않았는지 본다.
발행 게이트: 메타데이터, 대체 텍스트, 사이트맵 반영을 마지막으로 확인한다.

도구보다 게이트

도구는 자주 바뀐다. 에디터도 바뀌고 저장소도 바뀐다. 남는 건 절차다. "이 글이 어떤 질문에 답하는가"를 적는 브리프와, 보내기 전 확인하는 게이트가 흐름의 본체다.

좋은 글쓰기 시스템은 도구가 아니라 글을 발행하기 직전에 걸리는 게이트다.

다음 편에서는 에디터 설정을 줄이는 이야기를 한다.

새 블로그의 검색 노출, 첫 주에 하는 것들

Sat, 03 Oct 2026 00:00:00 GMT

첫 주의 목표는 순위가 아니다

새 도메인의 첫 주 지표는 노출 수치가 아니라 기반 상태다. 크롤러가 페이지를 받을 수 있는지, 제목과 설명이 제대로 서는지, 사이트맵이 참조되는지. 수치는 최소 2주 뒤에 재는다.

실제로 한 작업

사이트맵 생성: 빌드 시점에 모든 공개 글이 sitemap-index.xml에 들어가게 했다. robots.txt에서 사이트맵을 참조한다.
페이지별 메타데이터: 제목, 설명, canonical 주소, Open Graph 이미지를 페이지마다 고유하게 만든다.
구조화 데이터: 글 페이지에는 BlogPosting, 이동 경로에는 BreadcrumbList, 사이트 전체에는 WebSite와 Person을 넣는다. 화면에 없는 정보는 넣지 않는다.
404 확인: 없는 주소가 진짜 404를 반환하는지 확인한다. 200으로 응답하는 가짜 404는 색인 예산을 낭비한다.
JS 없이 보이는지: 빌드 산출물 HTML을 자바스크립트 없이 받아 본문과 제목이 있는지 확인한다.

등록할 것들

도구	하는 일
Google Search Console	구글 색인과 검색어 확인
Bing Webmaster Tools	빙 색인, IndexNow 연동
네이버 Search Advisor	네이버 노출·수집 요청

아직 모르는 것

검색량, 노출, 클릭 데이터는 아직 하나도 없다. 검색어 백로그를 만들려면 Search Console과 Search Advisor에 데이터가 쌓여야 한다. 그 전까지는 추정으로 키워드를 만들어내지 않고, 쌓인 데이터를 기준으로만 글을 고른다.

Gatsby 빌드 캐시가 실제로 줄이는 것

Sat, 03 Oct 2026 00:00:00 GMT

Gatsby의 빌드 캐시는 페이지와 데이터가 바뀌지 않았을 때 GraphQL 쿼리 평가, 이미지 처리, 번들 컴파일을 재사용해 두 번째 이후 빌드 시간을 줄인다.

빌드 시간이 가는 세 곳

정적 사이트 빌드에서 시간을 먹는 부분은 대체로 세 곳이다.

단계	하는 일	캐시 효과
GraphQL	콘텐츠를 읽어 페이지 데이터로 만든다	쿼리 결과 재사용
이미지	sharp로 크기·포맷별 변환을 만든다	변환 결과 재사용
번들	JS/CSS를 컴파일한다	webpack 캐시 재사용

이미지가 많은 블로그라면 이미지 단계가 가장 무겁다. 이 블로그처럼 커버 이미지가 글마다 있는 구조에서는 sharp의 캐시가 빌드 시간을 좌우한다.

캐시를 살리는 설정

.cache와 public을 빌드 간에 보존한다. Netlify는 기본으로 이를 캐시한다.
새 의존성 설치나 플러그인 설정 변경은 캐시를 무효화한다 — 이건 버그가 아니라 정상이다.
캐시가 의심스러울 때는 gatsby clean으로 로컬을 비우고, Netlify에서는 "Clear cache and retry deploy"를 쓴다.

측정하는 법

빌드 시간은 로그에서 읽는다. Netlify 빌드 로그는 각 단계의 시간을 보여주고, Gatsby의 빌드 출력도 단계별 시간을 출력한다. 두 번 연속 빌드해 두 번째 시간을 보면 캐시 효과를 바로 볼 수 있다. 이 블로그의 실제 빌드 시간은 첫 배포 후 로그로 확인해 갱신한다.

댓글: utterances와 GitHub Actions 알림 파이프라인

Fri, 02 Oct 2026 00:00:00 GMT

요구 사항

댓글 시스템에 원한 건 세 가지다. 서버를 두지 않을 것, 댓글 데이터가 내 GitHub에 남을 것, 새 댓글이 달리면 알림이 올 것. Disqus는 광고와 추적이 싫고, 직접 DB를 운영하기엔 정적 블로그의 취지와 어긋난다. 남은 선택지는 GitHub Issue를 댓글 저장소로 쓰는 utterances였다.

구조

댓글의 경로. 읽기는 공개 저장소에서, 알림과 분석은 비공개 저장소에서 일어난다.

흐름은 두 저장소를 오간다.

방문자가 포스트 하단의 utterances 위젯으로 댓글을 쓴다. GitHub 계정 로그인이 필요하다.
utterances가 공개 저장소 kese/kese-comments에 포스트별 Issue를 만들고, 댓글을 이슈 댓글로 저장한다.
issue_comment.created 이벤트가 kese-comments의 GitHub Actions 워크플로우를 깨운다.
워크플로우가 이슈 제목(/blog/<slug>/)에서 slug를 뽑고, 비공개 kese/kesekr에서 포스트와 content/authors.yaml의 작성자 매핑을 읽는다.
Gemini 키가 설정되어 있으면 댓글 분류·독성 레벨(0-5)·추천 답변을 생성하고, Level 4 이상은 댓글을 즉시 삭제한다.
결과는 비공개 kesekr에 알림 Issue로 쌓인다. 같은 포스트의 알림 Issue가 열려 있으면 새로 만들지 않고 댓글로 합친다.

올리브영에서 가져온 것

이 자동화는 oy-techblog/tech-blog-comment를 이식한 것이다. 원본은 조직 블로그용이라 작성자를 member.yaml에서 찾고 별도 조직 저장소에 알림을 둔다. 개인 블로그로 옮기며 작성자 매핑은 content/authors.yaml로 줄였고, 알림 대상은 비공개 블로그 저장소 자체로 향하게 했다. 원본의 workflow가 step-level bot 체크로는 실제 잡을 건너뛰지 못하는 문제가 있어 job-level 조건으로 고쳤다.

공개 범위도 이 과정에서 자연스럽게 갈렸다. 댓글 원문은 공개 kese-comments에, 알림·AI 분석·월별 메트릭은 비공개 kesekr에 남는다.

왜 비공개가 아니라 공개 저장소인가

utterances는 로그인하지 않은 방문자도 댓글을 읽을 수 있어야 해서 저장소가 반드시 공개다. 처음엔 비공개 저장소와 승인 큐를 Netlify Functions로 만들었다. 그런데 댓글 데이터는 어차피 공개 글 아래에 달리는 공개 텍스트고, 승인이 필요한 건 표시가 아니라 대응이었다. 그래서 기본을 utterances로 바꿨다.

다만 승인 큐 설계가 완전히 버린 건 아니다. 함수 백엔드는 GATSBY_COMMENTS_PROVIDER=functions로 그대로 살아 있어서, 나중에 '댓글이 달려도 바로 공개하지 않는' 운영이 필요해지면 되돌릴 수 있다. 트레이드오프를 둘 다 보유한 채 기본값만 바꾼 셈이다.

개인 블로그를 직접 만든 이유와 첫 설계

Thu, 01 Oct 2026 00:00:00 GMT

왜 이제야 직접 만드는가

글을 쓸 곳은 이미 많다. 네이버 블로그, 브런치, Medium, velog까지 선택지는 넘친다. 그런데도 직접 만들기로 한 이유는 단순하다. 콘텐츠의 원장(원본 저장소)을 내 도메인에 두고 싶어서다. 플랫폼은 언제든 정책을 바꾼다. URL이 바뀌고, 표시 방식이 바뀌고, 서비스가 닫힌다. 내 글의 정본이 남의 서버에 있으면 그 변경을 그대로 떠안는다.

정적 사이트 생성기로 만든 블로그는 다르다. 글은 마크다운 파일이고, 저장소는 내 GitHub에 있고, 배포는 정적 파일이다. 어느 한 서비스가 사라져도 파일은 남는다.

스택을 고른 기준

후보를 좁히는 기준은 세 가지였다.

기준	질문
콘텐츠 접근성	자바스크립트 없이 본문이 보이는가
이미지 처리	커버 이미지를 크기별로 만들어 주는가
유지 부담	플러그인 생태계가 살아 있는가

Gatsby 5는 세 가지를 모두 통과했다. 빌드 시점에 HTML이 완성되므로 크롤러와 사람에게 같은 페이지가 나가고, gatsby-plugin-image 계열이 이미지 파이프라인을 맡는다. React 생태계라 컴포넌트 재사용도 자연스럽다.

배포는 Netlify로 정했다. GitHub 비공개 저장소를 연결해 푸시마다 빌드하고, Pull Request마다 미리보기 배포를 만들어 준다. 서버를 직접 관리할 일이 없다는 점이 개인 프로젝트에선 크다.

처음에 정한 것들

글 주소: 날짜가 박힌 주소 대신 /blog/글-슬러그/ 형태를 쓴다. 글을 갱신해도 주소가 낡지 않는다.
콘텐츠 저장: 글 하나가 디렉터리 하나다. 마크다운과 이미지를 같은 폴더에 둔다.
댓글: 공개 사이트가 비공개 댓글 저장소를 직접 건드리는 구조는 피한다. 서버 측 함수만 저장소에 접근한다.

이 시리즈는 그 결정들을 하나씩 구현한 기록이다. 다음 편은 댓글 구조 설계다.

지금까지 배운 것

직접 만드는 일의 비용은 세팅 시간이 아니라 판단의 양이다. 플러그인마다 유지보수 상태를 확인해야 하고, 디자인과 접근성을 내가 책임져야 한다. 그 시간이 이 블로그의 주제이기도 하다.