git 저장소가 없어 히스토리·협업 기반이 아예 없던 상태를 연다.
함께 문서를 재편했다. 그동안 문서가 있어도 "이 제품이 뭘 푸는가"와
"어떻게 도는가"를 담은 문서가 없어서, 목표 문장이 backend/frontend
README 두 곳에 복붙돼 있었다 — 상위 문서가 없어 아래로 샌 것이다.
신설
README.md 레포 진입점 + 문서 지도 + 문서 규칙 4가지
AGENTS.md 에이전트·신규 합류자용 함정 목록과 규약
(CLAUDE.md 는 여기로 걸린 심볼릭 링크)
docs/PRODUCT.md 제품 정의 — 문제·사용자·원칙·**non-goals**·성공 기준
docs/ARCHITECTURE.md payload 경계·발행 파이프라인·서빙 결정·앱 분리 설계
이동
backend/docs/DECISIONS.md → docs/DECISIONS.md
백엔드만의 결정이 아니다. 게다가 코드 주석 ~25곳이 이미
`docs/DECISIONS.md` 로 적고 있어 레포 루트 기준으로는 그게 맞다.
갱신
docs/DEPLOY.md 서빙 결정 반영 — nginx 정적 서빙이 지금 경로(3절),
Azure 는 나중에 켤 때(4절)로 분리
docs/ARCHITECTURE.md 사이트 = 한 장(2026-08-31) 구조 반영
docs/COLLECTION_SEO_AEO_FLOW.md
robots.txt·sitemap.xml 은 오리진 루트에만 굽는다는 점 명시
frontend/site/scripts/prerender.ts
헤더 주석의 렌더 보고서 경로가 실제(422줄)와 달라 수정
.gitignore
★ CLAUDE.md 를 더 이상 무시하지 않는다. 에이전트 지침은 팀과 모든
에이전트가 공유하는 규약이라 커밋해야 한다 — 무시하면 클론한 사람이
"배포 후 republish_all.py 필수" 같은 함정을 전달받지 못한다.
개인용 오버라이드는 ~/.claude/CLAUDE.md 에 둔다.
152 lines
7.2 KiB
Python
152 lines
7.2 KiB
Python
"""상호 → 네이버 플레이스 id 해석.
|
|
|
|
지역검색 API 가 플레이스 id 를 주지 않아, 모바일 통합검색 결과 원문에서 상호가 일치하는
|
|
id 를 골라낸다. 이 판정이 틀리면 **남의 가게를 이 가게의 공식 채널로 등록**하게 되므로,
|
|
"비슷한 것 중 첫 번째"를 고르지 않는 것까지 여기서 지킨다.
|
|
|
|
네트워크는 타지 않는다 — 원문 조각을 직접 만들어 판정 규칙만 본다.
|
|
"""
|
|
import pytest
|
|
|
|
from services.external import naver_place_lookup as lookup
|
|
|
|
|
|
# 항목 사이를 채우는 잡음. ★ 조회 창(_CONTEXT_BEFORE + _CONTEXT_AFTER)보다 길어야 한다 —
|
|
# 실제 원문은 1.3MB 에 항목이 몇 개뿐이라 항목끼리 멀지만, 픽스처를 촘촘히 만들면
|
|
# 옆 항목의 상호가 창 안에 들어와 엉뚱한 id 가 잡힌다(테스트가 실제로 그렇게 잡아냈다).
|
|
_FILLER = "<div class=\"noise\">방문자 리뷰 블로그 리뷰 사진 더보기</div>" * 40
|
|
|
|
|
|
def _html(*entries: tuple[str, str]) -> str:
|
|
"""검색 결과 원문 흉내. (상호, place id) 를 순서대로 심는다.
|
|
|
|
실제 원문은 id 주변에 리뷰 키워드·블로거 닉네임이 잔뜩 끼어 있고 상호는 그 사이에
|
|
박혀 있다. 그래서 판정도 '조각 안에 상호가 들어 있는가' 로 한다 — 그 모양을 재현한다.
|
|
"""
|
|
parts = []
|
|
for name, place_id in entries:
|
|
parts.append(
|
|
_FILLER
|
|
+ f'<li><a href="/place/{place_id}">'
|
|
f'<span class="name">{name}</span>'
|
|
f'<span class="tag">주차하기 편해요</span></a></li>'
|
|
+ _FILLER
|
|
)
|
|
return "<html><body><ul>" + "".join(parts) + "</ul></body></html>"
|
|
|
|
|
|
def test_ampersand_in_name_is_matched_through_the_entity():
|
|
"""검증: 상호에 `&` 가 있고 원문에는 `&` 로 인코딩돼 있다.
|
|
기대결과: 찾는다.
|
|
|
|
★ 실측(2026-08-28) '누에베 풀빌라&리조트'. 이 한 글자 때문에 place id 를 못 찾아
|
|
화면이 '네이버 플레이스 못 찾음' 을 띄웠고, 사장님이 네이버 지도에서 주소를 직접
|
|
복사해 붙여넣어야만 진행됐다 — 10곳 중 1곳이 여기서 막혔다.
|
|
"""
|
|
html = _html(("누에베 풀빌라&리조트", "1064005604"))
|
|
assert lookup._match_in_html(html, "누에베 풀빌라&리조트") == "1064005604"
|
|
|
|
|
|
def test_plain_name_still_matches():
|
|
"""검증: `&` 도 엔티티도 없는 평범한 상호.
|
|
기대결과: 그대로 찾는다 — 위 수정이 기존 경로를 건드리지 않았다."""
|
|
html = _html(("보사노바 커피로스터스 강릉점", "37093035"))
|
|
assert lookup._match_in_html(html, "보사노바 커피로스터스 강릉점") == "37093035"
|
|
|
|
|
|
def test_punctuation_differences_are_ignored():
|
|
"""검증: 네이버는 '스테이,머뭄' 처럼 구두점을 넣어 표기한다.
|
|
기대결과: 구두점·공백 차이는 무시하고 같은 가게로 본다."""
|
|
html = _html(("스테이, 머뭄", "1133638931"))
|
|
assert lookup._match_in_html(html, "스테이머뭄") == "1133638931"
|
|
assert lookup._match_in_html(html, "스테이,머뭄") == "1133638931"
|
|
|
|
|
|
def test_unrelated_name_is_not_matched():
|
|
"""검증: 원문에 id 는 있지만 그 상호는 없다.
|
|
기대결과: None — ★ '비슷한 것 중 첫 번째' 를 고르면 남의 가게를 등록하게 된다."""
|
|
html = _html(("통나무파크", "13149475"), ("도치돌알파카목장", "11111111"))
|
|
assert lookup._match_in_html(html, "제주양떼목장") is None
|
|
|
|
|
|
def test_correct_id_is_picked_among_several():
|
|
"""검증: 후보가 여럿 섞인 원문에서 특정 상호를 찾는다.
|
|
기대결과: 그 상호에 붙은 id 를 고른다(앞에 있는 다른 id 가 아니라)."""
|
|
html = _html(
|
|
("통나무파크입구", "99999999"),
|
|
("통나무파크 전기차충전소", "88888888"),
|
|
("누에베 풀빌라&리조트", "1064005604"),
|
|
)
|
|
assert lookup._match_in_html(html, "누에베 풀빌라&리조트") == "1064005604"
|
|
|
|
|
|
def test_empty_name_never_matches():
|
|
"""검증: 상호가 빈 문자열이다.
|
|
기대결과: None — 빈 문자열은 어떤 조각에도 '들어 있으므로' 아무 id 나 잡힌다."""
|
|
html = _html(("통나무파크", "13149475"))
|
|
assert lookup._match_in_html(html, "") is None
|
|
assert lookup._match_in_html(html, " ") is None
|
|
|
|
|
|
async def test_find_place_ids_returns_only_the_ones_it_found(monkeypatch):
|
|
"""검증: 후보 3건 중 2건만 원문에 있다.
|
|
기대결과: 찾은 2건만 담긴다 — 못 찾은 상호는 빠지고, 검색은 **한 번만** 나간다."""
|
|
calls: list[str] = []
|
|
|
|
async def _fake_fetch(query: str):
|
|
calls.append(query)
|
|
return _html(("누에베 풀빌라&리조트", "1064005604"), ("통나무파크", "13149475"))
|
|
|
|
monkeypatch.setattr(lookup, "_fetch_search_html", _fake_fetch)
|
|
|
|
found = await lookup.find_place_ids(
|
|
"누에베 풀빌라 제주 애월읍",
|
|
["누에베 풀빌라&리조트", "통나무파크", "여기없는가게"],
|
|
)
|
|
|
|
assert found == {"누에베 풀빌라&리조트": "1064005604", "통나무파크": "13149475"}
|
|
assert calls == ["누에베 풀빌라 제주 애월읍"], "후보 수만큼 부르면 네이버가 429 로 막는다"
|
|
|
|
|
|
async def test_find_place_ids_is_empty_when_search_fails(monkeypatch):
|
|
"""검증: 검색 자체가 실패했다(네이버가 막았거나 네트워크 오류).
|
|
기대결과: 빈 dict — 호출측이 URL 직접 입력 경로로 안내한다. 예외로 터뜨리지 않는다."""
|
|
|
|
async def _fake_fetch(query: str):
|
|
return None
|
|
|
|
monkeypatch.setattr(lookup, "_fetch_search_html", _fake_fetch)
|
|
assert await lookup.find_place_ids("아무거나", ["가게"]) == {}
|
|
|
|
|
|
@pytest.mark.parametrize(
|
|
"raw, expected",
|
|
[
|
|
("누에베 풀빌라&리조트", "누에베풀빌라리조트"),
|
|
("스테이, 머뭄", "스테이머뭄"),
|
|
("A-1 Cafe (본점)", "a1cafe본점"),
|
|
(None, ""),
|
|
],
|
|
)
|
|
def test_normalize(raw, expected):
|
|
"""검증: 비교용 정규화 규칙.
|
|
기대결과: 공백·구두점·`&` 가 사라지고 소문자로 떨어진다."""
|
|
assert lookup._normalize(raw) == expected
|
|
|
|
|
|
def test_nearby_entries_can_steal_the_id__known_limit():
|
|
"""검증: 두 업소가 조회 창(앞 600자 + 뒤 300자)보다 가깝게 붙어 있다.
|
|
기대결과: **앞 항목의 id 가 잡힌다** — 현재 구현의 알려진 한계다.
|
|
|
|
★ 이건 통과를 축하하는 테스트가 아니라 경계를 적어 두는 테스트다.
|
|
판정이 'id 주변 원문 조각에 상호가 들어 있는가' 라서, 항목이 창보다 촘촘하면
|
|
옆 가게 상호가 창 안에 들어온다. 실제 검색 원문은 1.3MB 에 항목이 몇 개뿐이라
|
|
지금은 부딪히지 않지만, 네이버가 결과를 압축해 내려주면 그날로 남의 가게가 잡힌다.
|
|
막으려면 id 와 상호를 같은 항목 안에서 묶어 읽어야 한다(창 기반 판정을 버려야 한다).
|
|
"""
|
|
dense = (
|
|
'<li><a href="/place/11111111">앞가게</a></li>'
|
|
'<li><a href="/place/22222222">뒷가게</a></li>'
|
|
)
|
|
assert lookup._match_in_html(dense, "뒷가게") == "11111111"
|