PostgreSQL 테이블 건수로 자가호스팅 회사 시스템이 실제로 도는지 확인하기

넉 달 동안 집에 있는 미니PC에 혼자 쓸 회사 시스템을 붙였습니다. 정보를 모아 요약하는 것, 글을 발행하는 것, 아침 브리핑, 채널 지표, 컨디션 기록, 문서 템플릿까지 부서 이름을 붙여가며 하나씩 만들었습니다. 그 묶음을 닫기 전에 운영 DB(PostgreSQL)에 테이블마다 몇 건이 들어 있는지 직접 물어봤습니다.

결과부터 적으면, 정보 수집 테이블에는 18,542건이 쌓여 있었고 문서 템플릿 테이블은 0건이었습니다. 지표 테이블은 화면을 배포한 지 2주가 지났는데 3건뿐이었습니다. 컨테이너 상태만 보면 전부 정상이었는데, 건수를 세니 도는 것과 안 도는 것이 갈렸습니다. 아래는 어떻게 셌는지와 숫자별로 무엇을 확인했는지입니다.

도커로 띄운 PostgreSQL에서 테이블 건수 세는 명령

DB는 도커 컨테이너로 돌고 있어서, 컨테이너 안의 psql 로 들어가 조회했습니다. 실제로 쓴 접속 명령은 이것입니다.

docker exec calm-prod-postgres psql -U postgres -d calm_dev

테이블 하나의 정확한 건수는 count(*) 로 셉니다.

SELECT count(*) FROM research_items;

이 DB에는 테이블이 60개 있어서 하나씩 세기 번거로웠습니다. 전체를 한 번에 훑을 때는 PostgreSQL 통계 뷰를 보면 됩니다.

SELECT relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

n_live_tup 은 통계로 잡아 둔 추정치라서 정확한 숫자가 아닙니다. 이 목록으로 0에 가깝거나 생각보다 적은 테이블을 먼저 고르고, 그 테이블만 count(*) 로 다시 세는 순서가 편합니다.

인프라가 살아 있는지부터 확인

테이블을 세기 전에 바닥이 도는지 봤습니다. 9월 4일 기준으로 컨테이너 11개가 떠 있었고, Postgres 컨테이너는 3주, 외부로 나가는 Cloudflare 터널은 7주째 끊기지 않고 돌고 있었습니다. AI 호출 기록은 누적 13,753건이었습니다.

컨테이너가 언제부터 떠 있는지는 docker ps 의 STATUS 칸(Up 3 weeks 같은 값)에서 보입니다. 여기까지는 문제가 없었습니다. 문제는 그 위, 각 부서가 실제로 데이터를 쌓고 있느냐였습니다.

손대지 않아도 쌓이는 테이블 다섯 개

테이블	하는 일	9월 4일 건수
research_items	새벽 정보 수집·요약	18,542
content_topics	글 주제 후보	226
publications	글 발행	96
channel_daily_stats	채널 일별 지표	92일치
briefings	아침 브리핑	70

정보 수집이 압도적이었습니다. 새벽에 유튜브·RSS·커뮤니티를 긁어 요약한 항목이 18,542건이고, 그걸 묶은 아침 다이제스트는 83일치가 나갔습니다. 이 다섯 개는 제가 따로 손대지 않아도 매일 늘어납니다.

처음 센 건 8월 26일이었고, 그때 정보 수집은 16,740건, 발행은 89건, 브리핑은 61건이었습니다. 한 번만 세면 많다는 것만 알 수 있는데, 날짜를 두고 두 번 세면 지금도 늘고 있는지가 보입니다.

몇 건에서 멈춘 테이블: 건강 기록 3건, 문서 템플릿 0건

health_records            3
doc_templates             0

컨디션 부서는 루틴 체크가 100건이었고 건강 기록은 3건이었습니다. 매일 체크만 하면 되는 칸은 습관이 붙었는데, 따로 값을 적어야 하는 칸은 세 번 쓰고 끝났습니다. 같은 부서 안에서도 손이 한 번 더 가는 쪽이 정확히 안 쓰이고 있었습니다.

문서 템플릿은 0건이었습니다. 고장이 아니라 안 만든 것입니다. 8월에 고객 일이 계속 들어왔고, 회사 시스템을 만드는 일과 돈 버는 일 중에 매번 고객 쪽을 골랐습니다. 세어본 뒤에는 이걸 미룬 일이 아니라 안 하기로 한 일로 옮겼습니다. 혼자 쓰는 문서를 템플릿으로 찍어낼 이유가 없어서입니다. 다시 만드는 조건도 적어뒀습니다. 이 문서를 저 말고 다른 사람이 같이 고치게 되면 그때 만듭니다.

배포한 지표 화면에 데이터가 3건뿐이던 이유

8월 26일에 처음 셌을 때 지표 테이블은 이랬습니다.

metric_points             3

지표를 모아 보여주는 화면은 8월 12일에 배포했습니다. 배포는 성공했고 화면도 열렸습니다. 그런데 2주 동안 들어온 데이터가 3건이었습니다. 수집기를 붙여 놓고 실제로 도는지 확인하지 않았던 것입니다.

다음 날인 8월 27일에 일간 수집 스케줄러를 붙였습니다. 정보조사·콘텐츠·비서실·채널·컨디션 같은 부서에 걸친 13개 소스에서 매일 값이 들어오게 했고, 처음 센 날로부터 나흘 뒤인 8월 30일에 다시 셌습니다.

metric_points            42

숫자는 열네 배가 됐습니다. 그런데 그 화면을 보고 정한 건 아직 하나도 없었습니다. 3에서 42가 된 건 수집기가 붙었다는 뜻이지 제가 그 화면을 보게 됐다는 뜻은 아니었습니다. 건수는 데이터가 들어오는지까지만 알려주고, 누가 그걸 쓰는지는 알려주지 않습니다.

에러 없이 2주 멈춰 있던 자동 배포

같은 주에 하나가 더 나왔습니다. 이 서버는 Watchtower 가 GitHub 컨테이너 레지스트리(ghcr.io)에서 새 이미지를 받아와 배포하는 구조인데, 이 자동 배포가 2주 전부터 멈춰 있었습니다. 레지스트리에 접근하는 토큰(ghcr PAT)이 만료된 것이 원인이었고, 그동안 어디에서도 경고가 뜨지 않았습니다. 컨테이너는 옛 이미지로 계속 잘 돌았기 때문에 겉으로는 정상이었습니다.

이번에는 배포가 멈추면 알려주는 감지를 같이 붙였습니다. 비슷하게 토큰 만료로 블로그 자동 발행이 멈췄을 때 확인한 순서와 결과물 기준 헬스체크는 GitHub 토큰 만료로 멈춘 자동 발행 찾기에 따로 적었습니다.

지표 화면과 자동 배포는 둘 다 겉으로는 정상이었고, 동시에 아무 일도 안 하고 있었습니다. 숫자를 안 셌으면 이 둘을 계속 만든 것으로 계산했을 겁니다.

건수 다음에 셀 것: 열어본 날짜

이 표로 보면 “못 만들었다”는 틀립니다. 정보 수집 18,542건, 발행 96건, 브리핑 70건이 쌓여 있습니다. “다 만들었다”도 틀립니다. 문서 템플릿이 0건입니다. 맞는 문장은 만든 개수는 늘었는데 하루는 그만큼 안 바뀌었다는 것입니다.

그래서 9월에는 새로 만들지 않기로 했습니다. 목록에는 일정 관리, 연락처 정리, 돈 흐름 보기가 남아 있지만, 그보다 이미 만든 것을 매일 열어보게 되는 자리까지 끌고 가는 일을 먼저 합니다. 하루에 한 번 열게 되면 남기고, 그래도 안 열면 왜 안 여는지 보고 고치거나 버립니다.

다음에 같은 쿼리를 돌릴 때는 건수 말고 열어본 날짜를 셀 생각입니다. 화면에 들어온 데이터와 제가 그 화면을 연 기록이 따로 있어야 3에서 42로 간 것과 하루가 바뀐 것을 구분할 수 있습니다. 대시보드 숫자를 읽을 때 생기는 비슷한 착각은 대시보드에 없는 지표는 0이 아니라 안 잰 것입니다에 적었습니다.