보행 접근성 점수(워커빌리티 스코어): 계산 방법과 활용법

보행 접근성 점수는 하나의 질문에 답합니다. 이 현관에서 도보 거리 안에 일상생활이 얼마나 들어오는가? 식료품점, 약국, 학교, 공원, 식사할 곳입니다. 이 모든 것을 0에서 100 척도의 숫자 하나로 압축하기 때문에 부동산 포털, 이주 정보 사이트, AI 어시스턴트가 모두 이 지표를 채택했습니다.

숫자는 표시하기 쉽지만 정확하게 계산할 가치가 있습니다. 같은 도시의 두 주소가 완전히 다른 동네에 놓일 수 있기 때문입니다. 이 가이드는 먼저 계산 방법을 설명한 뒤 실제 데이터에 적용합니다. MapAtlas POI API를 사용해 유럽 20개 도시의 40개 주소에 대한 보행 접근성 인덱스를 계산했고, 그 결과는 이 점수가 도시가 아니라 주소에 속한다는 사실을 보여줍니다.

보행 접근성 점수가 측정하는 것

보행 접근성 점수는 근접성 지표입니다. 하나의 좌표에서 걸어서 갈 수 있는 일상 목적지를 세고, 각각의 필수 정도와 거리에 따라 가중치를 적용합니다.

이 정의에서 세 가지 결론이 따라 나오며, 숫자를 게시하는 곳이라면 어디든 세 가지 모두 함께 밝힐 만합니다.

이것은 도시가 아니라 주소의 속성입니다. 3 km 떨어진 두 아파트가 30점 이상 차이 나는 일은 흔하며, 이제는 주장이 아니라 데이터로 보여줄 수 있습니다.

존재 여부를 측정하지, 품질을 측정하지 않습니다. 점수는 300 m 거리에 슈퍼마켓이 있다는 사실은 압니다. 그 슈퍼마켓의 물건이 잘 갖춰져 있는지, 비싼지, 일요일에 문을 닫는지는 알지 못합니다.

거리를 측정하지, 수고를 측정하지 않습니다. 평지 1 km와 오르막 1 km는 모두 1 km로 계산됩니다. 지형, 횡단보도, 보도 상태는 계산에서 완전히 빠져 있습니다.

이는 방법의 결함이 아니라 숫자 하나가 담을 수 있는 범위의 한계입니다.

보행 접근성 점수를 계산하는 방법

어떤 구현이든 결국 같은 세 단계로 정리됩니다.

1단계: 주소를 좌표로 변환합니다

먼저 주소를 geocode해서 위도와 경도로 변환하십시오. 이 매칭의 정밀도가 이후 모든 단계의 상한을 결정합니다. rooftop 수준의 매칭은 원점을 건물 자체에 놓지만, 우편번호 수준의 매칭은 수백 미터 떨어진 곳에 떨어질 수 있고, 보행 스케일에서는 이 차이가 답을 바꿉니다.

geocoder가 매칭 정밀도 필드를 반환한다면 그 값을 사용하고, street 수준보다 거친 결과로 계산한 점수는 근사치라고 표기하십시오.

2단계: 보행 생활권 안에 있는 것을 수집합니다

다음으로 무엇을 도보 거리로 볼지 정합니다. 선택지는 두 가지이고, 이 선택은 보기보다 중요합니다.

반경은 좌표에서 1 km 이내의 모든 것을 가져옵니다. 빠르고 저렴하며 재현 가능하지만, 도로망을 전혀 고려하지 않습니다. 다리가 없는 강 건너 400 m 지점의 상점도 바로 옆집처럼 계산됩니다.

isochrone은 실제 경로를 따라 도보 15분 안에 정말로 도달할 수 있는 폴리곤 안의 모든 것을 가져옵니다. 요청당 비용은 더 들지만, 대신 강, 철도, 고속도로, 막다른 길을 올바르게 처리합니다.

아래 인덱스는 반경 1 km를 사용합니다. 공개된 벤치마크는 검증하려는 누구나 재현할 수 있어야 하기 때문입니다. 실제 서비스의 매물 기능에는 isochrone을 사용하십시오.

3단계: 카테고리마다 곡선으로 채점한 뒤 가중치를 적용합니다

마지막으로 집계 결과를 점수로 바꿉니다. 여기서 단순 개수는 통하지 않습니다. 레스토랑이 40곳인 동네가 10곳인 동네보다 네 배 걷기 좋지는 않으며, 첫 번째 슈퍼마켓은 스무 번째보다 훨씬 중요합니다. 그래서 각 카테고리는 수확 체감 곡선으로 채점합니다.

// One category, scored 0..1. `target` is the count that earns full marks.
const componentScore = (count, target) =>
  Math.min(1, Math.log(1 + count) / Math.log(1 + target));

// Weighted sum across categories gives the headline 0..100 number.
const score = components.reduce(
  (total, c) => total + componentScore(counts[c.key], c.target) * c.weight,
  0,
);

실질적인 역할은 로그가 합니다. 슈퍼마켓이 0곳에서 1곳이 되면 구성 요소 점수가 크게 오르지만, 30곳에서 31곳이 되는 변화는 거의 반영되지 않습니다. 사람들이 동네를 체감하는 방식과 대체로 일치합니다.

그다음 가중치를 적용합니다. 아래는 저희가 사용하는 가중치와 그 근거입니다.

가중치는 사실이 아니라 판단이므로, 확인하고 조정할 수 있도록 저희 값을 공개합니다. 가족 대상 포털이라면 학교 가중치를 높일 수 있고, 학생 임대 사이트라면 대신 교통과 음식 가중치를 높일 수 있습니다. 공개된 가중치가 있어야 다른 제품 안에서도 이 숫자를 재현할 수 있습니다.

어느 정도가 좋은 점수인가

점수는 구간과 함께 읽을 때 실행에 옮기기 쉬워집니다. 아래 구간은 뒤에 나오는 유럽 표본으로 보정했으므로, 중간대 숫자는 실제 유럽 동네의 모습을 나타냅니다.

이 구간은 주소 주변 시설의 공급량을 설명할 뿐, 그곳까지 걸어가는 경험을 설명하지 않는다는 점을 기억하십시오.

MapAtlas Walk Index: 유럽 20개 도시

유럽 20개 도시마다 두 개의 주소, 즉 중앙 광장과 약 5에서 8 km 떨어진 외곽 주거지구에 이 방법을 적용했습니다. 모든 집계는 2026년 7월 28일에 반경 1 km 안에서 MapAtlas POI API로 수집했습니다.

두 점 사이의 격차가 순위보다 훨씬 중요합니다. 도심 주소는 평균 94점이었고, 같은 도시의 외곽 주거지 주소는 평균 73점이었습니다. 파란 점이 상단에 몰려 있는 이유는 유럽 도심이 구조적으로 밀집해 있기 때문이며, 실제 편차를 보여주는 것은 초록 점입니다.

표에서 세 가지가 두드러집니다.

표본에서 도시 내부 격차가 가장 큰 곳은 Rome이며, 53점 차이입니다. Piazza Venezia는 93점인 반면, 여전히 시내에 있는 Ponte Mammolo는 40점입니다. 그 외곽 좌표 1 km 안에서 API가 찾은 것은 슈퍼마켓 4곳, 음식점 19곳, 녹지 6곳이었고, 도심에서는 각각 85곳, 1129곳, 149곳이었습니다.

Warsaw는 외곽 주소가 앞서는 유일한 도시입니다. Ursynów는 84점으로 Old Town의 82점을 앞섭니다. Ursynów가 식료품점, 학교, 클리닉, 공원을 설계 단계에서 포함한 계획 주거지구이기 때문입니다. 역사적인 도심과 한 주를 보내기 좋은 곳은 같지 않습니다.

Barcelona와 Athens는 하락 폭이 거의 없어 각각 2점과 7점에 그칩니다. 두 도시 모두 연속적인 중층 밀집 시가지가 관광 중심부를 훨씬 넘어서까지 시설 공급을 이어갑니다.

도시 평균이 잘못된 숫자인 이유

한 도시를 분해해 보면 그 원리가 분명하게 드러납니다.

모든 구성 요소가 동시에 떨어집니다. 식료품은 93에서 34로, 음식은 96에서 41로, 학교는 93에서 39로 내려갑니다. 카테고리 하나가 빠져서 비슷한 동네의 점수를 끌어내린 것이 아니라, 성격이 다른 장소입니다.

포털이 이 두 주소에 모두 "Rome, 보행 접근성 93"이라는 라벨을 붙이면 어떤 일이 벌어질지 생각해 보십시오. 외곽 아파트를 보러 온 구매자는 도심을 기대하고 도착하고, 현장 방문이 매물 설명을 정정하게 됩니다. 매물마다 자체 좌표로 점수를 계산하면 이 간극이 사라지고, 구매자는 페이지의 나머지 내용도 신뢰할 이유를 얻습니다.

점수가 알려주지 않는 것

숫자와 함께 밝힐 만한 한계가 네 가지 있습니다.

존재는 품질이 아닙니다. 1 km 안의 레스토랑 여섯 곳은 훌륭하든 형편없든 같은 점수를 받습니다. 점수는 이용 가능성만 측정하기 때문입니다.

평지와 급경사의 점수가 동일합니다. 근접성 계산에서 지형은 보이지 않으므로, Lisbon이나 Zurich 같은 도시에서는 점수가 낙관적으로 읽힙니다.

데이터 커버리지는 국가마다 다릅니다. 저희 데이터셋은 대중교통 노드를 보고하지만 채점하지는 않습니다. 정류장 단위 태깅 밀도가 국가 간에 너무 달라서 공정한 비교가 어렵기 때문입니다. Zurich가 그 이유를 보여줍니다. 쿼리는 Paradeplatz 1 km 안에서 대중교통 노드를 단 하나만 반환했는데, 이는 스위스 트램에 관한 사실이 아니라 태깅상의 산물입니다. 이를 채점했다면 확신에 찬 틀린 숫자가 나왔을 것이므로 제외하고 그 이유를 밝혔습니다.

스냅샷은 추세가 아닙니다. 이 수치는 2026년 7월 28일 기준이고 시설은 새로 열리거나 문을 닫으므로, 계산한 점수에는 반드시 날짜를 함께 게시하십시오.

부동산 매물에 보행 접근성 점수를 추가하는 방법

구매자는 매물에 관해 묻기 전에 동네에 관해 묻습니다. 그 질문에 페이지 안에서 답하는 매물은 방문자를 검색 엔진으로 보내지 않고 붙잡아 둡니다.

구현은 네 단계로 정리됩니다.

1. 매물 주소를 geocode하십시오. 데이터 수집 시점에 한 번만 처리하고 좌표를 매칭 정밀도와 함께 저장합니다. 페이지를 볼 때마다 geocode하지 마십시오.
2. 해당 좌표의 보행 생활권을 요청하십시오. 도보 15분 pedestrian isochrone을 만든 뒤 그 안의 amenity 개수를 집계합니다.
3. 자체 가중치를 적용하고 결과를 캐시하십시오. 동네는 며칠이 아니라 몇 달 단위로 바뀌므로 월 단위나 분기 단위 갱신으로 충분합니다.
4. 숫자와 근거를 함께 렌더링하십시오. 점수, 구성 요소별 내역, 그리고 그 뒤에 있는 실제 장소 이름을 보여줍니다.

마지막 단계에는 부수적인 이점이 하나 더 있습니다. 어떤 주소 주변에 무엇이 있는지 물었을 때 AI 검색 엔진은 실제 장소 이름이 나열된 블록을 인용할 수 있지만, 숫자만 있으면 인용할 것이 없습니다. 블록을 structured data로 마크업하면 기계가 읽을 수 있는 형태도 됩니다.

{
  "@context": "https://schema.org",
  "@type": "Residence",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Via dei Fori Imperiali 1",
    "addressLocality": "Rome",
    "addressCountry": "IT"
  },
  "additionalProperty": {
    "@type": "PropertyValue",
    "name": "Walkability score",
    "value": 93,
    "maxValue": 100,
    "measurementTechnique": "Weighted amenity density within a 15 minute walking isochrone",
    "valueReference": "Computed 2026-07-28"
  },
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "Supermarkets within a 15 minute walk", "value": 12 },
    { "@type": "LocationFeatureSpecification", "name": "Primary schools within a 15 minute walk", "value": 4 }
  ]
}

여기서 두 필드가 출처 정보를 담고 있습니다. measurementTechnique는 숫자가 어떻게 만들어졌는지 밝히고, 계산 날짜는 값과 함께 이동합니다. 덕분에 answer engine이 두 가지를 모두 애매한 표현 없이 그대로 반복할 수 있습니다.

이 점수가 쓰이는 곳

상업적 가치 순으로 대략 세 곳입니다. 부동산 매물에서는 점수가 동네에 관한 질문에 페이지에서 바로 답합니다. 이주와 임대 검색에서는 사용자가 건물보다 생활 방식을 먼저 기준으로 삼아 필터링합니다. 그리고 AI 어시스턴트는 "이 지역은 걷기 좋은가요?"라는 질문에 매물로 보내지 않고 직접 답하는 비중을 계속 늘리고 있습니다.

세 번째 영역이 가장 빠르게 변하고 있습니다. 계산 방법과 실제 장소 이름을 함께 공개한 날짜가 있는 점수는 answer engine이 인용할 구체적인 근거가 됩니다.

기반 데이터는 GeoEnrich API가 한 번의 호출로 좌표 주변의 amenity 개수와 장소 이름을 반환하고, Isochrone API가 그 집계 기준이 되는 보행 생활권을 생성합니다. 채점 가중치는 여러분의 제품 안에 두어, 각자의 사용자층이 중요하게 여기는 바를 반영하게 하십시오.

요약

보행 접근성 점수는 한 좌표 주변 일상 목적지를 거리에 따라 감쇠시켜 가중 합산한 값입니다. 주소를 geocode하고, 보행 생활권 안에 있는 것을 수집한 뒤, 카테고리마다 곡선으로 채점하고 가중치를 적용하십시오.

도시 단위가 아니라 주소 단위로 계산하십시오. 저희 20개 도시 표본에서 도심은 평균 94점, 외곽은 73점이었고 Rome 한 도시 안에서만 53점 차이가 났습니다.

그리고 숫자와 함께 방법을 공개하십시오. 가중치, 생활권, 수집 날짜, 그리고 점수가 의도적으로 측정하지 않는 것들입니다.