ADR — 격자 표시명 체계 (수동 지정 구역 zone + 격자 좌표 산술)¶

요약

"홍대입구 A-14" 같은 사람용 격자 이름은 수동 지정 구역(zones) + 격자 좌표 산술로 결정. 결정 보완 (2026-08-10, MSG-349): 폴백 재료도 서버가 준다. MSG-341이 "폴백 미제공"으로 남겼던 지도 응답 3종(뷰포트·단일 격자·핫구역)에 행정동 이름 regionName(nullable)을 동봉했다. 구역 밖이 다수(구역 48개, dev 시드 109칸 중 90칸 밖)인데 그 3종만 이름 재료가 없어서, 클라이언트가 이름 하나를 얻으려고 탐험률 API를 병행 호출하거나 칸마다 단건 조회를 돌려야 했다 — "규칙은 서버로"의 절반만 달성된 상태였다. regionName은 구역 안 격자에도 항상 실린다: 앱 디자인(MVP ver 5) 실측에서 셀 선택 바텀시트·격자 상세의 위치줄("부산 부산진구 서면")이 시/구를 행정동 이름에서 얻는다. 조립 규칙은 응답 무관 한 줄로 통일: label = zoneName ? zoneName+" "+zoneCell : regionName. 기각 대안: 응답 상단 코드→이름 대응표(gzip이 반복을 이미 잡아 잘해야 본전, 흩어지면 최대 +56% — 실측), displayName 조립본(제목과 위치줄 두 조합을 못 만듦). 명명 규칙·폴백 번호 없음은 불변. 정본 스펙: docs/spec/MSG-349.md.

성능 판정 (2026-08-10): 빈 칸(미점령 격자) 클릭의 행정동 중심점 재판정(ST_Covers, MSG-349)은 무캐시 유지. dev 실측 워밍 후 0.2~1ms, GIST 버퍼 히트 4페이지 — regions 3,558행이 shared buffers 상주라 DB가 사실상 인메모리 캐시다. JVM 폴리곤 재구현은 판정 술어 이원화(경계 격자에서 저장 라벨과 어긋남)라 기각. 후속 트리거: 이 쿼리가 DB CPU 병목으로 실측되면 그때 gridId→regionName 결과 캐시(술어는 DB 한 곳 유지)로 대응한다.

결정 변경 (2026-08-07, MSG-341): 이름 계산 주체가 클라이언트에서 서버로 바뀌었다. 격자를 담는 조회 응답 9종(카드 리스트·단일 격자·뷰포트·도감·지역별 갤러리·친구 최근 격자·핫구역·장소 검색·영상 업로드 확정과 재생)이 zoneName("서면")과 zoneCell("A-14") 두 필드를 싣고, 클라이언트는 조립(zoneName + " " + zoneCell)과 구역 밖 행정동 폴백만 한다. 사유는 같은 명명 규칙을 웹·Android·iOS가 각자 한 벌씩 구현해야 하는 중복 제거 — MSG-325 진행 중 FE가 "조립만 하고 규칙은 갖지 않게 해달라"고 요청했다. 명명 규칙 자체(행 A=북단, 열 1=서단, 폴백은 번호 없는 행정동 이름, 겹침은 priority→zoneKey)와 픽스처 정본(src/test/resources/fixtures/zone-naming.json)은 불변이고, 아래 2026-07-30 항목의 "서버 이름 계산 유틸은 FE-local 산술 확정으로 미구현"만 폐기된다. 구현은 계약 인터페이스 ZoneNameQueryService(Owner A) — 요청당 zones 1회 로드 스냅샷(ZoneNameResolver)을 소비처가 받아 항목마다 정수 산술한다(N+1 방지). 이름은 저장하지 않아 zones 재시딩·수동 삭제가 다음 요청부터 즉시 반영된다. 정본 스펙: docs/spec/MSG-341.md. 상태 갱신 (2026-07-30): ~~MSG-234로 개발 보류~~ → 기계장치 구현·develop merge 완료(MSG-234 종결 — V8 zones 테이블·GET /api/zones·시더·테스트 23건). 보류 사유였던 "누가 그리나"(쟁점 3)는 공공데이터 자동 변환 + 검수로 해소(MSG-234 상권 작도 결정 공공데이터 검수). 남은 것은 데이터 시딩뿐 — MSG-259 진행 중(zones 0행이라 지금은 전부 행정동 폴백 표시, 시딩 즉시 "서면 A-14" 활성). 쟁점 3건 전부 해소: ①폴백 번호 없음 채택 ②겹침은 안 겹치게 그리기 + priority는 보험(전원 0) ③공공데이터 변환·검수(내부 드래그 도구 불요). 단 검색 후속(GET /api/search)은 ADR 장소 검색 카카오 로컬 프록시로 이관(2026-07-28), 서버 이름 계산 유틸은 FE-local 산술 확정으로 미구현(호출 경로 없음). 파이프라인 쉬운 설명: zone 표시명 데이터 파이프라인 해설. (이전 2026-07-23: MSG-167 후속에서 재확인·ver 5 디자인 전 화면 채택됐으나 상권 작도 리소스 미확정으로 보류였음 — 계약 보존본 FE 격자 계약 프론트-백 합의.) zones는 grid_y/x 정수 사각형(PostGIS 불필요), 이름 = zone명 + 행(A=북쪽)·열(서→동) 산술 — grids에 저장 안 해도 빈 격자도 즉시 계산. 유명 구역 아니면 행정동 폴백. 기각: 행정동만(홍대 안 나옴), 지하철역 반경 자동(가로수길류 미커버·경계 애매·역 개통 시 이름 변동). zones가 검색까지 풀어 네이버 SDK 결정도 강화. 한계: 남북 26행=2.6km.

이 노트로 답할 수 있는 질문¶

"홍대 A-14" 같은 격자 이름은 어떻게 만들어지나?
왜 지하철역 반경 자동 판정을 기각했나?
zones 테이블 구조와 이름 산술 규칙은?
유명 구역이 아닌 격자는 어떻게 표시되나?
구역 크기 한계는 얼마인가?
이름을 서버가 계산하나, 클라이언트가 계산하나?
남은 쟁점 3개는 뭔가?

맥락¶

시안은 "홍대입구 A-14"를 요구하는데 grid_id는 {grid_y}_{grid_x} 기계 식별자뿐. "홍대"는 행정동이 아니고(서교동/동교동), 통칭은 행정동으로도 역명으로도 일반화 안 됨(가로수길·경리단길).

선택지¶

① 행정동만 ② 지하철역 반경 자동 판정 ③ 수동 지정 zone + 산술.

결정¶

③ 채택. zones(name·region_code·min/max_grid_y/x·priority) 정수 사각형. row = max_grid_y - grid_y → A,B,C…(북쪽이 A), col = grid_x - min_grid_x + 1. 매칭 없으면 행정동 폴백. 검색도 zones→regions 2단 폴백으로 확장 — 네이버 SDK의 키워드 검색 부재가 무의미해져 ADR 지도 SDK 네이버 전환이 더 단단해짐.

근거¶

가로수길류 커버 · 커버리지 통제 · lazy insert여도 순수 산술이라 즉시 계산 · 외부 데이터 무의존(이름 안정).

영향¶

한계: 알파벳 26행 = 남북 2.6km — MVP 구역은 2.6km 이하로 제약.
쟁점: ① 행정동 폴백 번호 체계(추천: 번호 없이 "서교동"만) ② 구역 겹침(안 겹치게 그리는 운영 규칙 추천) ③ 서울 상권 30~50개를 누가 어떻게(드래그 내부 도구 제안).
후속: zones 마이그레이션 · 시딩 · 이름 계산 유틸(GridEncoder 옆) · GET /api/search · glossary에 용어 추가 · 디자이너 확인.