아파트 관리비 평균 조회, 비교 기준부터 맞추는 법

3줄 요약

같은 단지 공용관리비 1,700원/㎡을 여섯 개 평균에 대보니 -6.36%에서 +23.74%까지 나왔습니다. 폭이 30.10%p이고 부호까지 뒤집혔습니다
관리비 오픈API 응답에는 면적 필드가 없습니다. ㎡당 단가를 만들려면 기본정보 API를 따로 불러야 하는데, 그 면적은 통계 화면의 면적과 기준이 다릅니다
우리 단지가 비싼지 따지기 전에 지역·단지유형·세대수 구간·난방방식 네 개를 먼저 고정하십시오

1,160.2원. 1,289.8원. 1,373.9원. 1,445.3원. 1,651.4원. 1,815.5원.

여섯 개 다 K-apt 공동주택관리정보시스템이 내놓는 2025년 ㎡당 월평균 공용관리비입니다. 최저와 최고가 1.56배 차이인데, 어느 것도 틀린 값이 아닙니다. 순서대로 경남 전체, 1,500~2,999세대, 전국 아파트만, 전국 전 단지유형, 서울 아파트만, 서울 전 단지유형입니다.

관리비 명세서를 받고 "우리 단지가 비싼가"를 확인하려면 이 중 하나를 골라야 합니다. 저는 그 선택을 자동화하려고 오픈API 문서를 읽기 시작했는데, 정작 발이 걸린 곳은 API가 아니라 비교 기준이었습니다.

1. 무엇을 고정해야 하는가

비교 기준을 고르는 순서를 먼저 표로 두겠습니다. 이 표의 각 행을 아래 섹션에서 근거로 채웁니다.

고정 항목	왜 고정해야 하는가	고정하지 않으면
단지유형	연립·다세대·도시형생활주택이 ㎡당 단가를 끌어올립니다	전국 아파트 1,373.9 대신 전 유형 1,445.3을 쓰게 되어 5.20% 관대해집니다
지역	서울 1,815.5 vs 경남 1,160.2로 1.56배 격차가 있습니다	지역 평균 대신 전국 평균을 쓰면 서울 단지는 무조건 비싸게 나옵니다
세대수 구간	150~299세대 1,639.5 vs 1,500~2,999세대 1,289.8으로 1.27배입니다	소규모 단지가 규모의 경제를 못 누린 것을 "관리 부실"로 오독합니다
난방방식	지역난방은 난방비가 개별사용료로 넘어갑니다	총액 비교가 회계 분류 차이를 실력 차이로 착각합니다
발생월	최신 월은 수집이 진행 중입니다	반쯤 채워진 달을 확정치로 읽습니다
면적 정의	통계는 주거전용면적, API는 관리비부과면적입니다	분모가 달라 단가가 체계적으로 낮게 나옵니다

네 번째까지가 통계 조회 조건이고, 다섯째와 여섯째는 자동화할 때만 걸립니다. 화면에서 손으로 볼 때는 뒤 두 개가 안 보이기 때문에 오히려 자동화 쪽이 위험합니다.

왜 이 네 개인가

K-apt 통계 화면은 지역, 단지유형, 세대수 구간, 난방방식을 각각 따로 걸 수 있습니다. 걸지 않으면 전국 전체 평균이 나오는데, 그 값은 전국 21,723개 단지를 한 줄로 눌러 놓은 숫자입니다. 우리 단지와 조건이 비슷한 집단이 아니라 그냥 전부입니다.

2. 같은 단지를 여섯 기준에 대본 결과

서울에 있는 200세대 개별난방 아파트를 가정하겠습니다. 공용관리비가 ㎡당 1,700원이고 전용면적이 84.96㎡라고 하겠습니다.

# 같은 단지 하나를 여섯 개 기준값에 대보는 계산
# 기준값은 K-apt 「관리비등 세부항목 지역별 평균」 2025-01~12 연평균 (원/㎡, 주거전용면적)
BASE = {
    "전국 · 전 단지유형":    1445.3,
    "전국 · 아파트만":       1373.9,
    "서울 · 전 단지유형":    1815.5,
    "서울 · 아파트만":       1651.4,
    "150~299세대 · 전 유형": 1639.5,
    "개별난방 · 전 유형":    1412.2,
}
MINE, AREA = 1700.0, 84.96      # 우리 단지 단가와 전용면적

for name, base in BASE.items():
    pct = (MINE - base) / base * 100        # 기준 대비 비율
    won = (MINE - base) * AREA              # 월 금액 환산
    print(f"{name:<24}{base:>8.1f}{pct:+8.2f}%{won:+10,.0f}원")

기준	기준값(원/㎡)	우리 단지 판정	월 차액
전국 · 아파트만	1,373.9	+23.74%	+27,705원
개별난방 · 전 유형	1,412.2	+20.38%	+24,451원
전국 · 전 단지유형	1,445.3	+17.62%	+21,639원
150~299세대 · 전 유형	1,639.5	+3.69%	+5,140원
서울 · 아파트만	1,651.4	+2.94%	+4,129원
서울 · 전 단지유형	1,815.5	-6.36%	-9,813원

폭이 30.10%p입니다. 월 금액으로는 -9,813원에서 +27,705원까지 37,518원 벌어지고, 연 450,220원입니다. 같은 명세서 한 장을 놓고 "1년에 45만원 더 내고 있다"와 "12만원 덜 내고 있다"가 동시에 성립합니다.

어느 기준이 맞는가

조건을 많이 맞춘 쪽입니다. 이 단지는 서울에 있고 아파트이므로 서울·아파트만(1,651.4)이 여섯 개 중 가장 가깝고, 판정은 +2.94%입니다. 그런데 세대수까지 맞추면 서울·아파트·150~299세대라는 더 좁은 집단이 필요하고, K-apt는 조건을 동시에 걸 수 있으니 실제로는 그 값을 조회해야 합니다. 위 표에 그 칸이 없는 이유는 조건을 좁힐수록 모수가 줄어 값이 흔들리기 때문이고, 어디서 멈출지는 결국 판단입니다.

조건을 좁히다 멈추는 지점

저는 세 개까지만 겁니다. 지역, 단지유형, 세대수 구간입니다. 난방방식은 총액을 볼 때만 걸고 공용관리비만 볼 때는 빼는데, 개별난방과 지역난방의 공용관리비 차이가 350.1원/㎡인 반면 개별사용료 차이는 1,016.8원/㎡로 세 배 가까이 크기 때문입니다. 공용관리비 쪽에서는 난방방식이 큰 변수가 아닙니다.

3. 오픈API는 ㎡당 단가를 주지 않습니다

여기가 자동화를 시작하면 바로 걸리는 자리입니다. 관리비 오픈API 응답에는 금액만 있고 면적이 없습니다.

# 1단계: 단지코드 확보 (시군구 단위)
curl -G "https://apis.data.go.kr/1613000/AptListService4/getSigunguAptList4" \
  --data-urlencode "serviceKey=${KEY}" \
  --data-urlencode "sigunguCode=11680" \
  --data-urlencode "numOfRows=100"
# 응답: kaptCode, kaptName, as1(시도), as2(시군구), bjdCode

# 2단계: 그 단지의 경비비 (금액만 나오고 면적은 없습니다)
curl -G "https://apis.data.go.kr/1613000/AptCmnuseManageCostServiceV3/getHsmpGuardCostInfoV3" \
  --data-urlencode "serviceKey=${KEY}" \
  --data-urlencode "kaptCode=A10027875" \
  --data-urlencode "searchDate=202607"
# 응답: kaptCode, kaptName, guardCost

# 3단계: 면적은 기본정보 API에서 따로 (kaptMarea = 관리비부과면적)
curl -G "https://apis.data.go.kr/1613000/AptBasisInfoServiceV5/getAphusBassInfoV5" \
  --data-urlencode "serviceKey=${KEY}" \
  --data-urlencode "kaptCode=A10027875"
# 응답에 kaptMarea, privArea, kaptTarea 세 가지 면적이 함께 옵니다

면적 필드가 세 개인 자리

기본정보 응답에는 kaptMarea(관리비부과면적), privArea(단지 전용면적 합), kaptTarea(연면적)가 같이 옵니다. 그런데 K-apt 통계 화면의 ㎡당 단가는 주거전용면적 기준입니다. 즉 통계와 비교하려면 분모를 privArea 계열로 맞춰야 하고, kaptMarea를 쓰면 분모가 커져 단가가 체계적으로 낮게 나옵니다.

두 면적의 비율이 단지마다 얼마나 벌어지는지는 확인된 근거가 없습니다. 단지별 공용면적 설계에 따라 달라지므로 상수로 환산할 수 없고, 자동화한다면 두 값을 모두 저장해 두고 어느 분모를 썼는지 결과에 같이 남기는 편이 안전합니다.

금액이 전부 문자열로 오는 자리

명세상 금액 필드는 전부 type: string입니다. 빈 문자열과 0이 섞여 오는데 둘의 뜻이 다릅니다. 미입력과 실제 0원을 같은 값으로 접으면 평균이 조용히 낮아집니다.

def to_won(v):
    """빈 값(미입력)과 실제 0원을 구분해서 반환합니다."""
    if v is None or str(v).strip() == "":
        return None                      # 미입력 — 평균 계산에서 제외
    return int(str(v).replace(",", ""))  # 천단위 구분자 방어

def per_sqm(cost, area):
    """면적이 없거나 0이면 단가를 만들지 않습니다."""
    if cost is None or not area:
        return None                      # 분모 결측을 0으로 채우면 안 됩니다
    return round(cost / area, 1)

4. 통계 쪽에서 조용히 틀린 값이 나오는 자리

항목을 더하면 총액을 넘는 자리

2025년 연평균 여덟 비목을 단순히 더하면 1,500.1원/㎡인데, 같은 화면의 공용관리비는 1,445.3원/㎡입니다. 103.79%로 54.8원/㎡ 초과합니다. K-apt가 각 비목 평균을 그 비목을 부과한 단지만 모수로 잡기 때문입니다. 승강기가 없는 단지는 승강기유지비 평균에서 빠지고, 자치관리 단지는 위탁관리수수료 평균에서 빠집니다.

비목	원/㎡	공용관리비 대비
일반관리비	654.1	45.26%
경비비	408.2	28.24%
청소비	242.6	16.79%
수선유지비	107.6	7.44%
승강기유지비	42.8	2.96%
위탁관리수수료	20.0	1.38%
지능형 홈네트워크 유지비	13.7	0.95%
소독비	11.1	0.77%
단순합	1,500.1	103.79%

그래서 비목별 비중을 원 그래프로 그리면 합이 100%를 넘습니다. 항목 비중을 자동 계산하는 코드를 짤 때 이 초과를 오류로 잡아 예외를 던지면 매달 멈춥니다.

난방방식이 회계 분류를 바꾸는 자리

지역난방 단지의 관리비 총액은 3,876.5원/㎡, 개별난방은 2,755.7원/㎡로 1.41배입니다. 실력 차이로 읽으면 안 됩니다. 시행령 제23조 제3항 제4호가 지역난방 단지의 난방비와 급탕비를 "사용료 등"으로 분류하기 때문입니다. 개별난방 세대는 도시가스사에 직접 내니 관리비에 아예 나타나지 않습니다. 같은 이유로 개별사용료 격차가 1.95배까지 벌어집니다. 전기요금 누진구간이 9월에 원위치하는 계산을 정리할 때도 같은 문제를 겪었는데, 청구서에 찍힌 숫자가 어느 칸에 들어가느냐가 비교 가능성을 결정합니다.

광주와 전남이 한 칸에 들어간 자리

2026년 K-apt 통계는 광주와 전남을 「전남광주통합특별시」 한 줄로 제공합니다. 과거 연도도 같은 스키마로 재집계됩니다. 시도 코드 17개를 하드코딩한 스크립트는 여기서 키를 못 찾고 떨어지고, 광주 단지를 광주 평균과 비교하는 일은 지금 불가능합니다.

5. 관리비가 오르는 이유는 거의 한 가지입니다

인건비 성격 항목을 더하면 1,257.0원/㎡로 공용관리비의 86.97%입니다. 일반관리비 안에서 인건비 비중은 92.68%입니다.

항목	원/㎡	공용관리비 대비
일반관리비 중 인건비	606.2	41.94%
경비비	408.2	28.24%
청소비	242.6	16.79%
합계	1,257.0	86.97%

시행령 별표 2는 청소비와 경비비를 "용역 시에는 용역금액, 직영 시에는 인건비·피복비 등"으로 정의합니다. 최저임금을 관리비에 연동시키는 조항은 없지만, 원가 구성이 이렇게 되어 있으면 결과는 같습니다. 2026년 최저임금은 시간급 10,320원으로 전년 대비 2.89% 올랐고(고용노동부고시 제2025-47호, 2025-08-05 제정), 인건비 비중 86.97%를 곱하면 이론 기여는 2.51%p입니다. 실제 공용관리비는 2024년 1,402.6원에서 2025년 1,445.3원으로 3.04% 올랐습니다.

차이 0.53%p 안에 물가와 계약 갱신 시차가 들어 있습니다. 위탁 단지는 용역계약이 갱신될 때 반영되므로 인상 시점과 관리비 반영 시점이 어긋납니다. 우리 단지 관리비가 올해 유독 많이 올랐다면 작년에 계약이 갱신됐는지부터 보는 편이 빠릅니다.

6. 자동화를 어디까지 하고 멈출 것인가

전량 수집은 개인이 할 수 없는 규모입니다.

대상	단지 × 엔드포인트	월 호출 수
공용관리비	21,723 × 17	369,291
개별사용료	21,723 × 10	217,230
장기수선충당금	21,723 × 4	86,892
기본정보(면적)	21,723 × 1	21,723
합계	—	695,136

개발계정은 일 5,000건입니다. 한 달분을 한 번 받는 데 139일이 걸리고, 매달 받으려면 일 22,836건이 필요해 한도의 4.6배입니다. 벌크 조회나 증분 조회 파라미터가 없어 단지×월 단건 호출만 됩니다. 전국 분석은 운영계정 전환과 활용사례 등록이 사실상 전제 조건입니다.

단지 몇 곳부터 회수되는가

2026년 최저임금 10,320원으로 시간값을 매기고, 파이프라인 구축을 6시간(인증키 발급부터 면적 정규화까지), 화면에서 단지 하나의 한 달분을 확인하는 데 3분, 스크립트로는 0.5분이라고 하겠습니다.

조회 규모	절약 시간값	순익
5단지 × 12개월	25,800원	-36,120원
10단지 × 12개월	51,600원	-10,320원
20단지 × 12개월	103,200원	+41,280원
50단지 × 12개월	258,000원	+196,080원

손익분기는 144회입니다. 우리 단지 하나만 매달 보는 용도라면 12년이 걸리므로 만들 이유가 없습니다. 이사 후보를 스무 곳쯤 놓고 최근 1년을 훑는 상황에서 처음 회수됩니다. 공공 API 자동화의 손익분기를 오피넷으로 최저가 주유소를 찾을 때도 계산해 봤는데, 그때도 결론은 같았습니다. 조회 횟수가 적으면 화면이 이깁니다.

스크래핑으로 우회할 수 없는 이유

K-apt는 robots.txt를 제공하지 않습니다. 2026-09-09 확인 시 /robots.txt 요청이 400 Request Blocked로 차단됐고, 회원가입 약관(시행 2009-06-01)에도 크롤링·자동 수집 금지 조항은 없습니다. 다만 같은 약관 제12조는 사전 승낙 없는 영리행위를 금지하고, WAF가 비정상 패턴 요청을 실제로 막습니다. 금지 조항이 없다는 사실을 허용 근거로 읽을 수는 없습니다. 동일한 데이터가 오픈API로 전량 나오므로 우회할 이유도 없습니다.

조회 전에 훑을 체크리스트

□ 우리 단지 조건 확인 — 시도 / 단지유형 / 세대수 / 난방방식 / 전용면적
□ K-apt 지역별 평균에서 위 조건을 걸어 기준값을 뽑는다 (전국 평균 그대로 쓰지 않는다)
□ 발생월은 두 달 전으로 맞춘다 (2026-09 조회 → 2026-07분)
□ 공용관리비와 개별사용료를 섞지 않는다. 난방방식이 다르면 총액 비교는 하지 않는다
□ 비목 비중을 계산하면 합이 100%를 넘는다는 것을 알고 본다
□ API로 단가를 만들 때는 분모를 privArea 계열로 맞추고 어느 면적을 썼는지 기록한다
□ 판정이 ±5% 안이면 차이가 아니라고 본다 (기준 선택만으로 30%p가 움직인다)

마지막 항목이 이 글의 요지입니다. 우리 단지가 평균보다 3% 비싸다는 계산은, 기준을 하나 바꾸면 6% 싸다로 바뀝니다. 그 정도 폭이라면 애초에 비교로 답할 질문이 아니고, 명세서에서 어느 비목이 튀는지를 직접 보는 편이 낫습니다. 항목별로 보면 모수 문제는 남지만 최소한 부호는 뒤집히지 않습니다.

옵시디언 3기기 동기화, 유료 결제 없이 구글 드라이브로 끝내기

8월 25, 2026

이 블로그 검색

하루 로그