Rails 블로그 운영 점검표: 화면보다 먼저 데이터 경로를 확인하라

2026.07.13

운영 점검은 사용자 흐름에서 시작한다

/up이 200을 반환한다고 블로그 전체가 정상인 것은 아니다. health endpoint는 프로세스가 요청을 받을 수 있다는 사실만 알려 줄 뿐, 발행 scope, 검색, 이미지 저장소, background job, Atom feed가 정상이라는 보장은 없다. 운영 점검은 방문자와 관리자의 핵심 흐름을 작고 반복 가능한 probe로 나누는 것이 좋다.

공개 경로에서는 홈의 최신 발행 글, 상세 페이지, 검색, 페이지네이션, Atom feed, sitemap을 확인한다. draft slug를 직접 요청했을 때 노출되지 않는지도 점검한다. 관리자 경로에서는 로그인하지 않은 /admin/** 요청이 차단되고, 제한된 QA 글의 작성과 삭제가 정상 동작해야 한다.

데이터베이스와 queue 상태 확인하기

Rails 8의 다중 SQLite 구성에서는 primary만 확인해서는 부족하다. production 점검 task가 네 DB에 각각 연결하고 schema를 읽도록 만든다. 파일 존재 여부뿐 아니라 migration 적용 상태, writable volume, 업무 데이터의 기본 관계를 함께 확인한다.

primary: connection, schema, published post count
cache: connection, schema, cache write/read/delete
queue: connection, schema, ready/failed job count
cable: connection, schema

Solid Queue를 Puma 내부에서 실행한다면 실제로 작은 검증 job을 넣고 완료될 때까지 기다린다. failed_jobs = 0만 확인하면 worker가 완전히 멈춘 상태도 정상으로 오인할 수 있다. 반대로 운영 데이터 삭제를 수행하는 job을 probe로 사용하지 말고, 부작용 없는 전용 job이나 테스트 레코드를 사용한다.

저장소와 이미지 경로 점검하기

S3 점검은 bucket 목록 조회 한 번으로 끝내지 않는다. 서버에서는 test prefix에 작은 객체를 PUT, HEAD, GET, DELETE하고, 삭제 뒤 다시 조회한다. 브라우저에서는 canonical origin에서 Direct Upload의 OPTIONS와 PUT을 확인한다. 이 둘은 서로 다른 네트워크와 CORS 경계를 검증한다.

이미지가 포함된 QA 글을 발행한 뒤 상세 페이지에서 다음 항목을 확인한다.

원본 대신 의도한 WebP variant가 제공되는가
이미지 width와 height가 HTML에 있어 layout shift를 줄이는가
커버가 목록에는 노출되지 않고 상세와 OG에만 나타나는가
삭제 뒤 원본과 variant가 purge되는가
unattached blob과 failed job 수가 기준선으로 돌아오는가

테스트 key와 QA 글에는 식별 가능한 prefix를 사용하되 credential이나 presigned URL 전체를 로그에 남기지 않는다.

캐시와 성능 회귀 찾기

warm cache만 측정하면 첫 방문의 N+1과 렌더링 비용을 숨길 수 있다. 홈, 상세, feed를 각각 cold와 warm 상태로 요청하고 SQL query budget을 기록한다. feed에서 여러 글의 Active Storage dimension을 읽을 때 blob metadata가 항목마다 조회되지 않는지 확인한다.

Markdown renderer의 출력 계약을 바꿨다면 cache version을 올리고 fragment와 meta description이 같은 version을 쓰는지 테스트한다. 이전 version의 값을 미리 저장한 뒤 새 렌더링 결과가 반환되는 회귀 테스트가 있어야 한다. 성능 측정은 최소 수십 회 요청의 median과 p95를 기록하며, 로컬 QEMU 결과와 native production 결과를 섞지 않는다.

프런트엔드에서는 모바일 폭의 horizontal overflow, CLS, focus 표시, 44px 터치 영역, prefers-reduced-motion을 확인한다. Turbo 뒤로가기를 사용한 뒤에도 코드 복사 버튼처럼 동적으로 생성된 요소가 실제로 동작하는지 테스트한다.

일일·주간·릴리스 점검을 분리하기

모든 검사를 매분 실행할 필요는 없다. 비용과 위험에 따라 주기를 나눈다.

일일 점검

health, 홈, feed, sitemap 상태
failed job과 최근 backup timestamp
디스크 사용량과 네 DB 파일 증가 추세
S3 인증 및 짧은 객체 round trip

주간 점검

Litestream 네 DB의 sync -wait와 txid 일치
unattached blob과 오래된 QA object 정리
cold query budget과 대표 페이지 응답 시간
운영 인증서 만료일과 NAS 용량

릴리스 점검

전체 테스트, lint, 보안 및 dependency audit
migration 상태와 production image의 비루트 실행
실제 브라우저 글 작성·업로드·발행·댓글·삭제 흐름
재시작 영속성, 이전 이미지 롤백, 격리 volume 복구 훈련

실패를 기록 가능한 신호로 만들기

각 probe는 단순한 성공/실패뿐 아니라 요청 시각, 단계, HTTP 상태, DB 이름, job 식별자를 남겨야 한다. 다만 cookie, credential, presigned query, 댓글 IP 같은 민감값은 기록하지 않는다. 장애가 나면 최근 배포, DB 쓰기, S3 브라우저 요청, queue, backup 순서로 상관관계를 좁힌다.

점검이 만든 QA 글과 객체는 마지막 단계에서 제거하고, 제거 결과도 다시 조회한다. cleanup이 실패하면 전체 점검을 성공으로 표시하지 않는다. 좋은 운영 점검표는 항목이 많은 문서가 아니라 “어느 경계에서 무엇이 실패했는지”를 빠르게 알려 주는 실행 가능한 계약이다.