Mina Choi
9d25ed613e
최상단을 프로젝트 단위로 평평하게 둔다 — o2o-negosium 과 같은 규약이고, 이 레포만
다르게 갈 이유가 없다. negodata/{backend,front} 가 프로젝트 안에서 f/b 를 가르는 선례,
lps-admin/ 이 백엔드 없이 프론트만 가진 최상단 폴더의 선례다.
backend/ frontend/{admin,site,shared} → solution/{backend,front,site,shared} + admin/
## 왜
내부 라우트(/local-content, /places/:id/seo)의 이름과 화면 코드가 사장님 번들에
그대로 실려 나가고 있었다. UserRole.DEVELOPER 주석의 "고객사에 존재를 노출하지 않는다"를
번들이 깨고 있었다 — 라우트 가드는 화면을 가리지 번들은 못 가린다.
번들을 갈라 확인했다: 사장님 dist 에서 local-content · /places · SeoAudit 이 전부 0건이다.
그 과정에서 두 곳이 더 새고 있었다.
- AppShell 의 NAV 배열이 내부 메뉴를 하드코딩하고 있었다. 앱을 가른 뒤에도 dist 에
local-content 가 남아서 찾았다. 메뉴는 이제 앱이 prop 으로 들고 온다.
- EditorHeader·BuilderPage·LoginPage 가 /places 로 링크하고 있었다. 그 화면이 admin 으로
나갔으니 사장님 앱에서는 404 다. 링크를 걷어내고 LoginPage 기본 도착지는 '/' 로 바꿨다
(앱마다 홈이 다르고 각 라우터의 '/' 가 이미 그걸 안다).
## admin 에 백엔드를 두지 않았다
내부 화면이 부르는 훅이 전부 router/v1/{place,fact,local,validator} 에 이미 있다.
자체 백엔드를 두면 place·fact·link 를 같은 DB 에 대고 두 번 구현하게 된다.
대가는 solution/backend 가 죽으면 admin 도 멈추는 것 — 내부 도구라 감수한다.
## admin 의 `@` 는 solution/front/src 를 가리킨다
내부 화면이 쓰는 API 클라이언트·UI·수집 배선이 solution 에 한 벌만 있고 그 파일들끼리도
`@/...` 로 서로를 부른다. admin 에서 `@` 를 자기 src 로 잡으면 그 참조가 전부 깨진다
(실측 TS2307 14건). 복제하는 길도 있지만 RecollectPanel 주석이 금지한다 —
"수집 경로를 두 벌 만들면 확정 게이트"가 갈라진다.
admin 자기 파일만 `@admin` 이고, 의존 방향은 admin → solution 한 쪽뿐이다.
admin 이 여는 빌더는 다른 오리진이라 절대 URL + 새 탭이다(admin/src/lib/solutionUrl.ts).
react-router Link 로 두면 admin 안에서 라우트를 찾다 404 다.
## 그 밖
- npm 워크스페이스 루트를 레포 루트로 올렸다(admin 이 solution 밖이라).
- docker-compose 를 255→174줄로 줄이고 admin(:3002) 서비스를 넣었다. ADMIN_BIND 기본값은
127.0.0.1 — 0.0.0.0 으로 열면 앱을 가른 의미가 없다.
- 발행 호스트를 프론트 .env 에 따로 적지 않는다. compose 가 루트의 SITE_PUBLIC_HOST 를
VITE_PUBLISH_HOST 로 흘려보낸다 — 두 곳에 적으면 canonical 과 화면 주소가 조용히 갈라진다.
- nginx/site.conf 를 git 에서 빼고 .example 만 남겼다(.env·*.toml 과 같은 규약).
compose 가 bind mount 하므로 클론 직후 복사해야 한다 — 없으면 Docker 가 그 자리에
디렉토리를 만들어 nginx 가 설정 없이 뜬다.
- config.test.toml.example 을 추가했다. 없으면 클론한 사람이 pytest 를 아예 못 돌린다
(conftest import 단계에서 죽는다). 외부 API 키는 전부 빈값이다 —
APP_ENV=test 가 .env 를 안 읽는 이유를 여기서 우회하면 안 된다.
- 경로가 한 칸 깊어져 test_schema_ddl(parents[2]→[3]) 과 test_site_theme 을 고쳤다.
검증: front·admin·site 전부 lint 0 / build 0. 백엔드 514 passed.
남은 4건(test_build_publish 3 · test_snapshot 1)은 이 변경 전부터 실패하던 것으로,
손대지 않은 메인 체크아웃에서 같은 4건이 같게 실패하는 것을 확인했다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019uYhHQdssRubirPirrdJJC
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"
|