jotso.net — “좋소판별기”. 회사 이름을 넣으면 국민연금 공공데이터로 그 회사의 연봉·퇴사율·소멸위험을 판정해 주는 서비스다.

겉보기엔 밈 사이트인데, 뜯어 보니 공공데이터 제품의 교과서에 가까웠다. 이 글은 외부에서 관측 가능한 것만으로 구조를 분해하고, 따라 만들 수 있는 패턴으로 체계화한 기록이다.

먼저 못 박아 둘 것. 나는 이 서비스의 서버 코드도 DB도 볼 수 없다. 확인할 수 있는 건 클라이언트로 내려오는 것 — HTTP 헤더, HTML, 번들, sitemap, 그리고 운영자가 스스로 공개한 계산식 문서뿐이다. 아래에서 [실측] 은 내가 직접 요청해 확인한 것, [추정] 은 그로부터의 추론이다. 섞지 않는다.


1. 이 서비스가 푼 문제

구직자가 중소기업을 볼 때 진짜 알고 싶은 건 하나다. “여기 가도 되나?”

기존 답은 전부 결함이 있다. 잡플래닛·블라인드는 리뷰 기반이라 표본이 편향되고(불만 있는 사람이 더 쓴다) 회사당 리뷰가 0건인 곳이 대부분이다. 채용공고의 연봉은 회사가 쓴 자기소개다. 신용평가는 B2B용이고 개인이 못 본다.

좋소판별기의 답은 “사람들이 실제로 어떻게 행동했는지를 정부 기록으로 본다” 이다. 리뷰를 안 쓴다. 직원이 몇 명 들어오고 몇 명 나갔는지, 회사가 국민연금 보험료를 얼마나 냈는지만 본다. 말이 아니라 행동을, 그것도 신고 의무가 있는 기록으로.

이게 이 제품의 근본 설계다. 나머지는 전부 여기서 파생된다.


2. 실측한 기술 스택

$ curl -sSL -D - https://jotso.net/
HTTP/2 200
cache-control: max-age=14400, s-maxage=86400, stale-while-revalidate
vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
via: 1.1 Caddy
x-nextjs-cache: HIT
x-powered-by: Next.js
cf-cache-status: HIT
server: cloudflare

여기서 [실측] 으로 확정되는 것:

항목 근거
Next.js App Router vary: RSC, Next-Router-State-Tree — RSC 페이로드 협상 헤더는 App Router에만 있다
ISR / 풀 라우트 캐시 사용 x-nextjs-cache: HIT (회사 페이지 첫 요청은 MISS)
Caddy 리버스 프록시 뒤 자체 호스팅 via: 1.1 Caddy — Vercel 배포였다면 이 헤더가 없다
Cloudflare CDN server: cloudflare, cf-cache-status
Tailwind CSS 번들 CSS에 --tw-* 커스텀 프로퍼티
CSS 총 44KB _next/static/css/*.css 실측

[추정] via: Caddy + Cloudflare 조합은 Vercel이 아닌 VPS 자체 운영을 강하게 시사한다. 3.9만 페이지를 ISR로 굴리면서 CSS 44KB에 그친 건 Tailwind 퍼지가 제대로 걸렸다는 뜻이다.

캐시 전략이 영리하다. max-age=14400(브라우저 4시간) / s-maxage=86400(CDN 24시간) / stale-while-revalidate. 원본 데이터가 월 단위로 갱신되는 국민연금 공공데이터라서, 하루 이틀 낡아도 아무 문제가 없다. 데이터 신선도에 캐시 TTL을 정확히 맞춘 것이다.


3. 4층 아키텍처

관측된 것을 층으로 정리하면 이렇게 된다.

L4  확산층    OG카드 · 이상형월드컵 · 시상식 · 주간드롭 · 알림
              ↑ 공유되는 단위를 만든다
L3  페이지층   38,921 회사 + 228 지역 + 20 업종 + 랭킹/시상식 허브
              ↑ 검색엔진이 걸어들어올 표면을 만든다
L2  파생지표층  좋소력 · 회전율 · 추정연봉 · 착취지수 · 소멸위험도
              ↑ 원본에 없는 '판단'을 만든다  ← 진짜 IP는 여기
L1  데이터층   국민연금 사업장 · DART 감사보고서 · 금융공공데이터
              ↑ 누구나 받을 수 있는 공개 데이터

핵심은 L1이 아니라 L2가 자산이라는 점이다. 원본 데이터는 아무나 받는다. 경쟁 우위는 “그걸로 무엇을 계산해 내느냐”에서 나온다.


4. L1 — 원본 데이터 3종

운영자가 /about-metrics에서 직접 밝힌 출처다.

  1. 국민연금공단 공공데이터 — 사업장별 가입자 수, 취득(입사)·상실(퇴사) 신고, 고지보험료. 월 단위 시계열.
  2. 금융감독원 전자공시(DART) — 상장·외감 법인의 매출·영업이익·부채·1인평균급여.
  3. 금융위원회 금융공공데이터 — 비외감 중소법인 재무. (급여·감사의견·분기 실적은 빠짐)

여기서 눈여겨볼 설계가 하나 있다. 커버리지가 서로 다른 3개 소스를 계층으로 쌓았다. 국민연금은 거의 모든 사업장을 덮지만 재무가 없다. DART는 재무가 풍부하지만 외감 법인만이다. 금융공공데이터가 그 사이를 메운다.

그래서 화면에서 연봉 표기가 회사마다 달라진다 — 실제로 관측된다.

  • 뱅크샐러드 → “공시연봉 6,991만”
  • 스위코진광 → “추정연봉 3,995만”

운영자 설명과 정확히 일치한다. “연봉은 DART 공시 1인평균급여를 우선 쓰고 없으면 국민연금 추정”. 소스 우선순위(fallback chain)를 UI 라벨에까지 노출한 것이다. 이건 뒤에서 다시 다룬다.


5. L2 — 이 제품의 진짜 발명

5-1. 연봉 역산: 한 줄짜리 아이디어

전체 제품에서 가장 영리한 지점은 이 한 줄이다.

\[\text{월기준소득} = \frac{\text{1인당 고지보험료}}{0.09}, \qquad \text{추정연봉} = \text{월기준소득} \times 12\]

국민연금 보험료율은 9%로 법에 고정돼 있다. 그리고 사업장별 고지보험료는 공개 데이터다. 그러면 나눗셈 한 번으로 그 회사 직원의 평균 소득이 나온다.

아무도 연봉을 공개하지 않았는데 연봉이 계산된다. 리뷰도, 설문도, 크롤링도 필요 없다. 제도가 강제한 기록에서 제도가 의도하지 않은 정보를 뽑아낸 것이다.

그리고 운영자는 이 지표의 치명적 한계를 스스로 먼저 적어 놓았다.

기준소득월액 상한(월 637만 원, 2025.7~2026.6) 이 있어 고소득은 상한에서 잘려 실제보다 낮게 잡힐 수 있다. 성과급·비과세는 반영되지 않는 추정치.

이 숫자는 내가 1차 출처로 따로 확인했다. 보건복지부는 2025년도 제1차 국민연금심의위원회 결과로 기준소득월액 상한액을 617만 원 → 637만 원으로 조정하고 2025년 7월부터 적용한다고 밝혔다. 운영자가 적어 둔 괄호 안 기간(2025.7~2026.6)까지 정확하다.

상한이 월 637만 원이면 연 7,644만 원에서 값이 천장에 붙는다. 즉 이 추정연봉은 고연봉 회사를 구분하지 못한다. 네이버든 카카오든 다 똑같이 상한에 눌린다.

그런데 여기에 붙인 대응이 좋다.

절대 추정연봉은 소득상한으로 왜곡되지만, 업종 내 상대 위치는 그 영향이 적습니다.

절대값이 못 미더우면 분위(percentile)로 바꿔서 쓴다. 같은 업종 표본의 P25·P50·P75 안에서 어디인지만 말한다. 표본 30곳 미만 업종은 아예 표시하지 않는다. 지표의 결함을 숨기지 않고, 결함이 덜 먹히는 표현형으로 갈아탄 것이다.

5-2. 회전율 — 흔한 오해를 이름으로 막았다

\[\text{회전율} = \frac{\text{그 달 취득 인원} + \text{상실 인원}}{\text{재직 인원}}\]

퇴사만이 아니라 입사와 퇴사를 더한다. 그리고 운영자가 직접 경고를 붙였다.

입사와 퇴사를 더하므로 100%여도 전원이 나갔다는 뜻은 아니다(드나든 총량).

지표 이름이 오해를 부를 수 있는 지점에 미리 반례를 박아 둔 것이다. 게다가 건설·병원·의원·학교·보건처럼 인력이 본래 자주 드나드는 업종은 평균 산정에서 제외한다. 구조적으로 회전이 높은 업종을 섞으면 비교가 무의미해지기 때문이다.

과거에 쓰던 ‘도망지수’라는 자극적인 이름도 “이 평균 회전율을 100배 한 같은 값” 이라며 통합해 버렸다고 밝혔다. 지표를 늘리는 대신 줄인 기록을 공개한 셈이다.

5-3. 소멸위험도 — 예측이라고 부르지 않았다

이 부분이 가장 인상적이다. 회사 페이지에 이렇게 뜬다.

소멸위험도 2% · 앞으로 18개월 이 회사와 비슷한 패턴(규모·1년 인원 변화·퇴사 압력)을 보였던 회사 1,146,404곳21,645곳이 18개월 안에 사라졌어요. 예측이 아니라 과거 비슷한 회사들의 결과 통계입니다.

\[\text{소멸위험도} = \frac{\text{유사 패턴 코호트 중 소멸한 회사 수}}{\text{유사 패턴 코호트 전체}}\]

이건 모델 예측이 아니라 매칭된 코호트의 경험적 기저율(empirical base rate) 이다. 머신러닝 모델을 붙여 “AI가 예측한 폐업 확률”이라고 부르는 게 훨씬 그럴싸하고 마케팅도 잘 됐을 것이다. 그런데 그렇게 하지 않았다.

114만 건이라는 코호트 크기를 그대로 노출한 것도 중요하다. 분모를 보여 주면 독자가 신뢰도를 스스로 판단할 수 있다. 2%라는 숫자만 던지는 것과 “114만 곳 중 2.1만 곳”이라고 말하는 건 완전히 다른 정직성이다.

소멸 정의의 한계도 붙어 있다. “소멸 = 국민연금 사업장 인원 소멸 기준(법적 폐업·합병·코드변경이 포함될 수 있음)”.

5-4. 착취지수 — 두 소스를 곱해서 만든 지표

\[\text{착취지수} = \frac{\text{1인당 연봉}}{\text{1인당 영업이익}} \times 100(\%)\]

국민연금(연봉) × DART(영업이익). 서로 다른 데이터셋을 결합해야만 나오는 값이다. 화면에서는 이렇게 표현된다.

직원 1명이 영업이익 7,126만원 벌어다 주는데, 추정연봉은 3,995만원 — 벌어다 주는 돈의 56%만 가져감

여기에도 한계가 붙는다. “100%를 넘으면 벌어다 준 것보다 더 받는다는 뜻이라 표시하지 않습니다.”적자 기업에서는 이 지표가 무의미해지므로 아예 숨긴다. 계산이 되는데도 안 보여 주는 판단이다.

5-5. 등급 컷을 수능에 맞췄다

73점 이상=정승, 58점=확정, 47점=향기, 23점=간보는, 그 아래는 희귀. 이 컷은 수능 등급(1등급 상위 4%·2등급 11%·3등급 23%)에 맞춰 두어 ‘상위 몇 %’로도 환산해 보여줍니다.

0~100 점수는 그 자체로 의미가 없다. 31점이 좋은 건지 나쁜 건지 모른다. 그래서 한국인이 몸으로 아는 척도인 수능 등급 백분위에 컷을 정렬했다. 낯선 지표를 익숙한 척도에 얹는 것 — 이건 통계가 아니라 인지 설계다.

5-6. 축이 부족하면 빠진다

회사 페이지에는 “장부 좋소력 3축“(부실·분배·생산성)으로 표시됐는데, 방법론 문서에는 5축(처우·부실·분배·생산성·착취)이라고 적혀 있다. 모순이 아니다. 같은 페이지에 답이 있다.

측정에 필요한 공시 항목이 없는 축은 빠집니다.

데이터가 없으면 0으로 채우거나 평균으로 대체하지 않고 축 자체를 제거한다. 결측을 임의값으로 메우면 점수가 조용히 오염된다. 이건 우아한 성능 저하(graceful degradation)를 지표 설계에 적용한 사례다.


6. L3 — 프로그래매틱 SEO의 정석

sitemap을 실측했다.

sitemap.xml → sitemapindex, 5개 샤드
shard 0: 8,117 · 1: 7,835 · 2: 7,763 · 3: 7,816 · 4: 7,655
합계 39,186 URL

경로별 분포 [실측]:

경로 개수 역할
/company/{사업장ID} 38,921 엔티티 페이지 (롱테일)
/region/{시도-시군구} 228 지역 허브
/industry/{대분류}/{세분류} 20 업종 허브
/rankings/{지표} 6 score·turnover·churn·low_salary·avg_tenure·extinction_risk
/awards/{부문} 3 u_turn·steady_hell·mass_exodus
/graveyard /drops /worldcup 3 참여형

엔티티 페이지 + 허브 페이지 + 랭킹 허브의 전형적 3단 구조다. 회사 페이지에서 지역 허브와 업종 허브로 나가고, 허브가 다시 회사로 돌려보낸다. 실제로 회사 페이지 하나에서 다른 회사로 나가는 내부 링크가 23개 있었다 [실측] — 같은 업종·같은 지역 회사들이다.

메타데이터도 전부 데이터에서 자동 생성된다.

<title>주식회사스위코진광 연봉·직원수·퇴사율 — 좋소판별기</title>
<meta name="description" content="직원 48명 · 추정연봉 3,995만원 · 퇴사율 4% · …">

타이틀에 검색어(“연봉·직원수·퇴사율”)를, 설명에 실제 수치를 박았다. 설명이 회사마다 전부 다르다 — 대량 페이지의 최대 함정인 중복 콘텐츠를 데이터로 피한 것이다. JSON-LD는 Organization + BreadcrumbList [실측].

여기서 가장 흥미로운 결정

회사 페이지는 스스로 “전국 좋소 30.7만 개 기준” 이라고 밝힌다. 그런데 sitemap에 올린 회사는 38,921개 — 약 12.7% 뿐이다.

[추정] 이건 의도적인 크롤 예산(crawl budget) 관리로 보인다. 30만 개를 전부 색인 요청하면 대부분이 저품질 씬 페이지로 평가되어 사이트 전체 품질 점수를 끌어내린다. 데이터가 충분한 회사만 골라 sitemap에 올리고, 나머지는 존재하되 색인을 강요하지 않는 전략이다. 양이 아니라 밀도를 택했다.


7. L4 — 공유되는 단위를 제품으로 만들었다

OG 카드가 곧 제품이다

/og/{사업장ID}회사마다 다른 PNG가 서버에서 생성된다 [실측].

content-type: image/png
1200 x 1200 (정사각)
cache-control: public, immutable, max-age=31536000

카드 한 장에 들어 있는 것: 회사명 / 등급 라벨(“별에서 돌아온 좋소”) / 연봉 분위 / 인원 시계열 스파크라인 / 좋소력 점수 31 / 한 줄 판정(“큰 흠은 없어요. 탕비실 상태로 최종 판단하세요.”) / CTA “나도 해보기”.

클릭하지 않아도 결론이 전달된다. 카톡 대화방에 이미지 하나가 뜨면 그걸로 이미 정보 전달이 끝난다. 그리고 카드 하단의 “나도 해보기”가 다음 검색을 부른다.

\[\text{검색} \to \text{판정} \to \text{카드 공유} \to \text{수신자 호기심} \to \text{검색}\]

1200×1200 정사각을 고른 것도 우연이 아닐 것이다 [추정] — 카카오톡 공유 미리보기는 정사각에 가까운 비율에서 잘리지 않는다. 캐시는 immutable에 1년이라 재생성 비용이 사실상 0이다.

호기심 갭을 UI로 만들었다

홈 랭킹 카드의 1위 자리에는 회사명 대신 이렇게 떠 있다 [실측].

1 1위는 어디일까? 탭해서 공개   공개 2 주식회사 건우전력 — 회전율 165% 3 주식회사 더이음 — 회전율 139%

2위부터는 다 보여 주고 1위만 가린다. 정보를 감춘 게 아니라 한 번의 상호작용을 유도하는 장치다. 지역 랭킹에도 같은 패턴이 있다(“좋소력 1위 동네는 어디일까?”).

같은 데이터를 5가지 포맷으로 재활용

원본 시계열 하나로 콘텐츠 표면을 계속 늘린다.

  • /rankings — 지표별 상시 순위 6종
  • /awards — 서사가 있는 부문. 기사회생(반토막 → 저점의 1.5배 회복한 V자), 꾸준한 지옥(추세는 평평한데 변동성만 큰 회사), 단체탈출(한 달 새 순퇴사 30%+)
  • /graveyard — “별이 된 좋소”. 연도별 폐업 수 시계열(2016년 99 → 2020년 764)
  • /drops주 단위 총정리(“2026년 33주차 · 8월 10일~16일”)
  • /worldcup — 이상형 월드컵 포맷의 회사 토너먼트

주간 드롭이 특히 영리하다. 원본 데이터는 월 단위인데 콘텐츠는 주 단위로 낸다. 재방문 주기를 데이터 갱신 주기보다 짧게 만든 것이다.


8. 체계화 — 재사용 가능한 패턴 9개

이 사이트에서 뽑아낼 수 있는, 도메인 무관하게 쓰이는 패턴들이다.

① 제도가 남긴 흔적을 역산하라. 강제 신고 의무가 있는 데이터에는 신고자가 의도하지 않은 정보가 남는다. 보험료율이 고정이면 보험료에서 소득이 나온다. 규제는 데이터 생성기다.

② 말이 아니라 행동을 측정하라. 리뷰(말)는 편향되고 희소하다. 입·퇴사 신고(행동)는 전수에 가깝고 거짓말할 유인이 없다.

③ 커버리지가 다른 소스를 폴백 체인으로 쌓아라. 넓지만 얕은 소스(국민연금)를 기반으로, 좁지만 깊은 소스(DART)를 우선 적용. 그리고 어느 소스를 썼는지 UI에 라벨로 노출(“공시연봉” vs “추정연봉”).

④ 절대값이 못 미더우면 분위로 바꿔라. 상한에 눌린 추정치라도 같은 모집단 안에서의 상대 순위는 살아남는다. 지표를 버리지 말고 표현형을 바꿔라.

⑤ 결측은 채우지 말고 축을 빼라. 0이나 평균으로 임퓨팅하면 오염이 조용히 전파된다. 축을 제거하고 “빠졌다”고 말하는 편이 정직하고 안전하다.

⑥ 예측이라고 부르지 마라. 코호트 기저율을 계산했으면 “비슷한 회사 N곳 중 M곳이 그랬다”고 말하라. 분모를 노출하면 신뢰도 판단이 독자에게 넘어간다.

⑦ 낯선 점수를 익숙한 척도에 정렬하라. 0~100은 아무 의미 없다. 수능 등급 백분위에 컷을 맞추면 설명 없이 이해된다.

⑧ 공유 단위를 서버에서 렌더링하라. 클릭 없이 결론이 전달되는 이미지 카드 + 되돌아오는 CTA. 엔티티마다 다른 OG 이미지를 만들고 immutable로 캐싱하면 비용은 0에 수렴한다.

⑨ 대량 페이지는 밀도로 걸러라. 30만 개 중 3.9만 개만 sitemap에 올린다. 색인 요청량이 아니라 색인 통과율이 사이트 품질을 결정한다.


9. 비판 — 내가 관측한 약점

칭찬만 하면 분석이 아니다.

9-1. 사업장 코드 변경이 ‘대량 퇴사’로 보인다

/drops 의 “2026년 6월, 사라진 직원수 TOP10”에 이런 항목이 있다 [실측].

  1. 두산에너빌리티(주) 5,462명 → 506명 (-4,956) · 2026-06
  2. 금호타이어주식회사 1,949명 → 178명 (-1,771)

[추정·중요] 대기업에서 한 달 만에 인원의 90%가 사라지는 건 실제 감원보다 사업장 코드 분할·이관·재편일 가능성이 훨씬 높다. 그리고 이 함정은 운영자 스스로 방법론 문서에 적어 둔 것이다 — “합병·코드 변경도 섞일 수 있음”.

한계를 알고 문서화했지만, 그 한계가 가장 크게 작용하는 랭킹 화면에는 경고가 붙어 있지 않다. 방법론 페이지를 읽지 않은 사람에게 이 화면은 “두산에서 5천 명이 잘렸다”로 읽힌다. 문서의 정직성이 UI까지 전파되지 않은 지점이다.

9-2. 소수 인원 회사의 비율 지표

운영자도 “직원 10명 미만은 1~2명 변동에도 비율 지표가 크게 흔들립니다” 라고 밝혔다. 그런데 홈 피드에는 인원 5명·6명 회사가 좋소력 점수와 함께 노출된다 [실측]. 5명 중 1명이 나가면 회전율 20%다. 표본이 작을수록 자극적인 숫자가 나오고, 자극적인 숫자일수록 랭킹 상위에 오른다. 구조적으로 노이즈가 상단에 배치되는 편향이 있다.

9-3. 이름이 판정을 선행한다

“좋소판별기”라는 이름과 “정승/확정/향기” 같은 등급 라벨은 재미있지만, 점수가 나오기 전에 프레임을 정해 버린다. 좋소력 31점을 받은 회사는 통계적으로 중간인데(상위 47%), 브랜드 전체가 “좋소인가 아닌가”를 묻고 있으므로 중립적 결과도 부정적으로 읽힌다. 면책 문구(“단정적 평가가 아닙니다”)를 모든 페이지 하단에 넣어 방어하고는 있다.


10. 정리 — 이 제품이 진짜 증명한 것

기술적으로 새로운 건 하나도 없다. Next.js App Router, Tailwind, ISR, sitemap 샤딩, 동적 OG 이미지 — 전부 표준 도구다. 데이터도 전부 공개된 것이다.

그런데도 이 서비스가 성립하는 이유는 L2, 파생지표층에 들인 노력 때문이다.

  • 보험료율이 9% 고정이라는 걸 알아챈 것
  • 상한에 눌린다는 걸 알고 분위로 갈아탄 것
  • 예측 모델을 붙이고 싶은 유혹을 참고 코호트 기저율에 머문 것
  • 데이터가 없는 축을 채우지 않고 뺀 것
  • 계산식과 한계를 전부 공개한 것

공공데이터 제품에서 해자는 데이터 접근권이 아니다. 데이터는 누구나 받는다. 해자는 “이 숫자를 어디까지 믿어도 되는지 아는 것”, 그리고 그 경계를 사용자에게 그대로 말해 주는 것이다.

계산식을 통째로 공개했는데도 따라 하기 어려운 이유가 여기 있다. 공개된 건 공식이고, 공개되지 않은 건 그 공식이 어디서 깨지는지 알아내기까지의 시행착오다.


관측 방법과 한계

  • 이 분석은 2026-08-11 KST 시점의 외부 관측이다. 사용한 수단은 curl(헤더·HTML·sitemap·OG 이미지)과 운영자 공개 문서 /about-metrics 뿐이다.
  • 서버 코드·DB 스키마·인프라 구성·트래픽·수익 구조는 확인하지 못했다. 이 글에 그에 대한 서술이 없는 이유다.
  • Next.js·React의 정확한 버전은 번들에서 추출하지 못해 명시하지 않았다. App Router 사용은 vary 헤더로 확정된다.
  • 계산식과 한계 문구는 모두 운영자가 /about-metrics 및 각 페이지에 직접 게시한 텍스트를 인용한 것이며, 내가 재구성하거나 추정한 공식이 아니다.
  • 회사별 수치(스위코진광 등)는 예시로 인용한 관측값이며, 특정 기업에 대한 평가가 아니다. 원 사이트의 고지와 같이, 공공데이터 기반 자동 추정치는 실제 경영·신용 상태에 대한 단정적 평가가 아니다.

References

  1. 좋소판별기 — https://jotso.net/
  2. 좋소판별기 「지표는 어떻게 계산하나요」(계산식·한계 공개 문서) — https://jotso.net/about-metrics
  3. 좋소판별기 소개 — https://jotso.net/about
  4. 「국민연금공단국민연금 가입 사업장 내역20260723」, 공공데이터포털 — https://www.data.go.kr/data/15083277/fileData.do
  5. 금융감독원 전자공시시스템(DART) — https://dart.fss.or.kr/
  6. 금융위원회 — https://www.fsc.go.kr/ (좋소판별기가 밝힌 ‘금융공공데이터’ 출처. 개방시스템 사이트는 집필 시점 외부에서 접속되지 않아 직접 확인하지 못했다.)
  7. 보건복지부 보도자료 「국민연금, 기초연금 올해 2.3% 더 받는다 — 2025년도 국민연금 급여액·기초연금 기준연금액 인상 및 국민연금 기준소득월액 상·하한액 조정」 — https://www.mohw.go.kr/board.es?act=view&bid=0027&list_no=1484263&mid=a10503000000 (1차 — 상한액 617만 → 637만 원, 2025년 7월 적용)
  8. 국민연금공단 「국민연금 기준소득월액 상·하한액 조정 안내」 — https://www.nps.or.kr/pnsgdnc/newgdnc/getOHAE0001M1.do?menuId=MN24000897&pstId=NE202500000000030479
  9. Next.js App Router — generateSitemapshttps://nextjs.org/docs/app/api-reference/functions/generate-sitemaps