낡은 정보는 배포조차 안 되게 만든 1인가구 위키, '혼서가'
정보의 진짜 문제는 '틀림'이 아니라 '낡음'
세금, 복지, 주거 같은 생활정보를 검색하면 항상 마주치는 문제가 있습니다. 분명 어딘가에서 정리된 글을 찾긴 했는데, 그게 언제 기준인지 알 방법이 없다는 것이죠. 세법이나 복지 기준은 매년 바뀌는데, 2년 전 숫자가 아무렇지 않게 검색 상위에 떠 있고 읽는 사람은 그게 낡았다는 사실조차 알아채기 어렵습니다.
이런 문제의식에서 출발한 프로젝트가 바로 **혼서가**입니다. 1인가구가 실제로 부딪히는 세금·주거·금융·행정·복지 등 8개 분야를 다루는 위키 사이트인데, 접근 방식이 꽤 인상적입니다. "나중에 업데이트해야지"라는 흔한 함정을 아예 기술적으로 불가능하게 만들었거든요.
정보가 낡으면 빌드 자체가 실패한다
혼서가의 모든 페이지에는 last_verified(마지막 확인일)와 review_before(재검증 마감일)가 프론트매터로 박혀 있습니다. 그리고 빌드 파이프라인이 이렇게 짜여 있습니다.
velite → verify-content → next build → verify-design → pagefind
이 중 verify-content 단계에서 벌어지는 일이 핵심입니다.
review_before가 지난 페이지가 하나라도 있으면 → 빌드 자체가 실패합니다(process.exit(1)). 이 페이지뿐 아니라 그날 배포하려던 다른 모든 수정사항까지 같이 막혀버립니다.- 카테고리별 재검증 주기(annual/biennial/triennial)를 넘기면 → 경고가 뜹니다.
- 출처 신뢰도가 낮은(tier 4 이하) 페이지만 있으면 → 경고가 뜹니다.
last_verified필드가 아예 없으면 → Velite의 Zod 스키마 검증 단계에서 애초에 통과되지 않습니다.
즉, 오래된 정보를 방치한 채 다른 작업을 계속하는 게 구조적으로 불가능합니다. 마감이 지나면 사이트 전체 배포가 멈추기 때문에, 관리자가 손을 대지 않을 수 없는 구조를 만든 셈이죠.
재검증 주기는 분야마다 다르게 설정돼 있습니다. 변화가 잦은 세금·금융·주거는 매년(annual), 행정·건강안전은 2년(biennial), 비교적 안정적인 생활·관계사회·노후는 3년(triennial) 주기이며, 필요하면 페이지 단위로 개별 조정도 가능합니다.
출처도 그냥 "어디서 봤다"가 아니라 데이터로 관리
각 페이지의 출처(sources)는 이름, URL, 신뢰도(tier), 확인 날짜를 갖춘 구조화된 데이터로 관리됩니다.
- tier 1: 국세청, 복지로, 국토부 등 소관 기관의 1차 자료
- tier 2: 국가법령정보센터의 조문
- 그 아래: 보도자료, 언론 기사 등
이 구조가 스키마로 강제되기 때문에 "출처 없는 정보"는 물리적으로 존재할 수 없습니다. 그리고 확실하지 않은 부분은 얼버무리지 않고 정직하게 표시합니다. 아직 발표되지 않은 시행계획이나 기관마다 표기가 엇갈리는 수치 등, 현재 304곳에 '확인 필요' 배지가 붙어 있습니다. 모르는 걸 아는 척하는 것보다는 훨씬 나은 태도라는 생각이 듭니다.
기술 스택은 가볍고 서버 비용은 0원
- Next.js 정적 export
- Velite — MDX 프론트매터를 Zod 스키마로 검증
- Pagefind — 빌드 타임에 정적 검색 색인을 생성해 클라이언트에서 검색 지원
- Cloudflare Pages에 배포하며, 서버가 없어 운영비가 들지 않습니다.
광고는 현재 없고, 나중에 붙이더라도 기초생활수급·주거급여·의료급여 같은 페이지에는 넣지 않을 계획이라고 합니다. 문맥광고 특성상 이런 페이지에는 소액대출·채무통합 광고가 붙기 쉬운데, 이는 사이트의 취지와 정면으로 배치되기 때문입니다.
솔직하게 밝힌 한계들
이 프로젝트가 특히 눈길을 끄는 건, 스스로 드러낸 한계를 숨기지 않는다는 점입니다.
- 페이지 수에 수학적 상한이 생긴다. 현재 101페이지의 재검증 주기를 합산하면 연 84회, 주 평균 1.6페이지꼴로 재검증 작업이 발생합니다. 페이지가 200개로 늘면 주 3.2페이지가 되어, 그때부터는 신규 콘텐츠 생산 여력을 재검증이 전부 잠식하게 됩니다. 게다가 마감이 고르게 분산되지 않고 특정 시기에 몰리는 문제도 있습니다. 예를 들어 2027년 1월에만 19페이지의 마감이 겹치는데, 하필 연말정산과 기준중위소득이 동시에 바뀌는 달이라 실제 업무량도 그 시기에 폭증합니다. "빌드 가드"라는 안전장치를 넣은 대가로 확장성에 제약이 생긴 셈입니다.
- 계산기가 1개뿐입니다(월세 세액공제). "내가 얼마 받을 수 있나"가 이용자들이 가장 궁금해할 질문인데, 아직은 표와 공식으로만 안내하고 있습니다.
- 구글 색인 지연 이슈. 얼마 전까지 구글 색인이 20페이지에서 멈춰 있었는데, 알고 보니 구글이 사이트맵을 6월에 한 번 읽은 뒤 2개월간 재크롤링을 하지 않아 그사이 추가된 66페이지가 아예 발견되지 않고 있었습니다. 사이트맵을 재제출하자 117페이지로 색인이 바로 잡혔습니다. robots.txt나 canonical 설정에는 문제가 없었고, 단순히 재크롤링이 안 온 것뿐이었습니다. 비슷한 구조의 사이트를 운영 중이라면 사이트맵의 '마지막 읽은 날짜'를 주기적으로 점검해볼 만합니다.
마무리하며
정보의 정확성보다 정보의 신선도에 주목하고, 그걸 사람의 의지가 아니라 빌드 파이프라인이라는 기술적 장치로 강제한 접근이 인상적입니다. 완벽하진 않지만, 한계까지 투명하게 공개하는 태도 자체가 신뢰를 쌓는 방식이라는 생각이 듭니다. 개발자 입장에서도 "낡은 콘텐츠를 어떻게 관리할 것인가"라는 고민에 좋은 참고 사례가 될 것 같습니다.