모델에서 공개 지표까지

왜 지표를 만드는가

BLOCK의 도시는 건물, 조명, 이동, 기업, 행정경계처럼 서로 다른 형태의 데이터로 남습니다. 하나하나가 도시의 한 단면을 보여주지만, 수집 주기와 공간 단위가 제각각이라 그대로는 비교할 수 없습니다. 연구의 첫 목적은 이 신호들을 같은 기준 시점, 같은 도시 단위로 맞추는 것입니다.

두 번째 목적은 서비스 운영입니다. 지도에서 도시를 비교하거나, 날씨를 예보하거나, 전력 수요와 발전 잠재량을 함께 보려면 재현 가능한 계산 규칙이 필요합니다. 결과가 바뀌었을 때 원천 데이터의 변화인지 모델의 변화인지 추적할 수 있어야 합니다.

여기에 PLAYCITY만의 조건이 하나 더 있습니다. 이 도시에는 계량기가 없습니다. 전기 요금 고지서도, 관측소도, 주민등록부도 없습니다. 현실의 통계가 무언가를 세어서 만든다면, 가상 도시의 지표는 남아 있는 흔적에서 역산해야 합니다. 켜져 있는 조명, 등록된 건물, 저장된 월드 파일이 전부입니다.

그래서 PLAYCITY의 지표는 대부분 대리지표(proxy)입니다. 조명으로 전력을, 건물 세대수로 인구를 대신 말합니다. 대리지표 자체는 문제가 아닙니다. 현실 통계도 표본과 추정에 기댑니다. 문제는 대리지표가 관측값처럼 보일 때 생깁니다. 조명 합계에 와트를 붙이면 전력계처럼 읽히고, 건물 세대수에 명을 붙이면 인구조사처럼 읽힙니다. 숫자는 단위를 얻는 순간 사실인 척하기 시작합니다.

절차가 필요한 이유가 여기 있습니다. 이 절차는 지표를 정확하게 만들지 않습니다. 정확한지 아닌지를 말할 수 있게 만듭니다. 무엇을 관측했고 어디서부터 가정인지, 그 경계가 문서에 남아 있어야 나중에 누군가 이 값을 의심할 때 답할 수 있습니다.

실측값, 등록 자료, 모델 산출값은 화면과 문서에서 서로 구분해 표시합니다.

공통 연구 절차

서비스마다 입력은 달라도 공개 지표를 만드는 절차는 네 단계로 통일합니다.

절차가 같다는 말은 추상적으로 들립니다. 그래서 실제로 발행된 세 지표가 이 네 단계를 각각 어떻게 채우는지 나란히 놓았습니다. 입력도 단위도 다르지만 단계의 순서와 이름은 같습니다.

세 지표의 공통점이 하나 더 있습니다. 셋 다 관측값이 아닙니다. 조명은 전력이 아니고, 합성 날씨는 예보가 아니며, 건물 세대수는 사람이 아닙니다. 절차의 마지막 단계가 "결과와 한계를 함께 배포합니다"인 이유입니다.

공개 지표의 공통 계산 틀

원천 관측값 x를 모델 f로 변환하고, 경계 c에 속하는 가중치 w로 합칩니다. 점이 경계 안에 완전히 들어오는 자료는 w=1, 격자 면적을 나누는 자료는 교차 비율을 씁니다. 어떤 방식을 썼는지는 지표마다 고정합니다.

전력은 하나의 신호로 계산하지 않습니다

전력 화면의 출발점은 최신 인공 조명 스냅샷입니다. 자연광을 뺀 발광 블록의 광량을 16블록 청크별로 더하고, 필요에 따라 64블록과 256블록 격자로 합칩니다. 이 값은 계량기에 찍히는 소비 전력이 아니라, 도시의 밤 활동을 대신 보여주는 관측 대리지표(proxy)입니다.

도시별 수요는 조명만으로 정하지 않습니다. 최신 인구와 가구 수, 도시 운영 기간, 경제 활동 지수와 실물 활동량을 함께 사용합니다. 오래 운영된 대도시와 이제 막 등록된 소도시는 조명량이 같더라도 수요 구조가 다르다고 보기 때문입니다. 다섯 항을 더한 값이 도시 수요 대리지표가 됩니다.

절차의 두 번째 단계가 여기서 그대로 나타납니다. 각 항에는 환산 계수가 붙는데, 그 계수는 관측으로 보정한 값이 아니라 사람이 정한 가정입니다. 화면에 보이는 MW와 GWh도 도시끼리 견주기 위한 표시용 레이블이지 계량기로 보정한 물리량이 아닙니다. 인구와 가구를 함께 넣는 구조 역시 현실 수요를 추정한 회귀 결과가 아니라, 도시 규모의 서로 다른 신호를 뭉개지 않으려는 규칙입니다.

계산식과 계수, 그리고 어느 항이 도시 순위를 좌우하는지는 노트 005에 있습니다. 계수를 이 글에도 적어 두면 값이 바뀔 때 두 문서가 갈라지므로, 전력 지표의 근거는 노트 005 한 곳에만 둡니다.

날씨는 시간과 공간을 함께 보존합니다

날씨 화면은 모델 실행과 입력 프레임, 셀 상태를 기준으로 움직입니다. 기온, 습도, 구름, 강수 확률·강도, 기압, 바람을 같은 시점의 격자로 묶고, 지도에 쓰는 릴리스와 도시별 요약을 따로 만듭니다.

지도는 응답 크기를 줄이려고 1024블록과 2048블록 단위의 저해상도 격자를 사용합니다. 도시 예보는 같은 모델 실행 안에서 행정경계에 들어오는 셀만 집계합니다. 지금부터 48시간은 3시간 간격으로, 주간 화면은 최대 7일까지 보여 줍니다. 지난 30일 기록 역시 실제 관측이 아니라 보관해 둔 모델 산출 이력입니다.

이 구조 덕분에 한 화면에서 월드 전체의 공간 패턴과 특정 도시의 시간 변화를 함께 볼 수 있습니다. 또 원본 셀 상태와 공개용 격자, 도시 요약을 나눠 두었기 때문에 응답 속도를 지키면서 단계마다 결과를 다시 확인할 수 있습니다.

여기서 다루는 것은 날씨가 화면에 도달하는 경로까지입니다. 모델이 셀마다 날씨를 어떻게 만드는지, v6가 v5의 무엇을 고쳤는지는 노트 003에 있습니다. 전력과 마찬가지로 계수와 검증 결과의 근거는 그쪽 한 곳에 둡니다.

검증과 한계

모델은 완성된 정답이 아니라 계속 검토해 나가는 도구입니다. PLAYCITY는 다음 항목을 기본 검증 대상으로 둡니다.

• 같은 원천 스냅샷과 계수를 넣으면 같은 결과가 다시 나오는지 확인합니다.
• 전체 합계와 도시 경계 안 집계 합계의 차이를 기록해, 경계 밖에 있거나 분류되지 않은 데이터를 찾습니다.
• 시간이 지나도 순위와 값이 갑자기 튀지 않는지 스냅샷을 비교합니다.
• 실측과 등록 자료, 모델 산출값을 화면과 문서에서 구분해 표시합니다.
• 계수나 집계 규칙을 바꾸면 모델 버전과 발행물에 바꾼 이유를 남깁니다.

지금의 모델은 가상 도시의 등록 상태와 서비스 데이터 품질에 좌우됩니다. 경계가 없거나 최신 스냅샷이 빠진 지역은 실제보다 적게 집계될 수 있고, 화면에 표시되는 현실 단위가 실제 소비·생산량을 보장하지도 않습니다.

이 절차를 실제로 적용한 결과는 개별 노트에 있습니다. 각 노트는 계산식과 계수, 검증한 범위, 그리고 그 지표로 말할 수 없는 것을 함께 적습니다. 계수와 검증 결과의 최종 근거는 이 글이 아니라 각 노트입니다.