사우나우

처음엔 좋은 곳 몇 백 곳만 골라 담을 생각이었어요. 그런데 지도 서비스에서 "내 주변"을 눌렀는데 아무것도 안 뜨면 그 순간 앱이 죽거든요. 커버리지가 먼저였습니다.

검색 결과를 긁는 방식은 처음부터 안 봤어요. 그렇게 하면 "목욕탕"이라고 검색해서 나오는 곳만 모이는데, 제가 찾고 싶었던 건 그 검색에 안 걸리는 쪽이었거든요. 호텔 지하나 리조트 안에 있는 사우나는 상호에 목욕탕이라는 낱말이 없어요. 인허가는 그런 걸 안 가리고 다 갖고 있습니다. 그래서 공공데이터포털 목욕장업 인허가를 통째로 받아 왔어요. 영업 상태로 거르고, 상호랑 업태 문자열에서 찜질방·온천·24시를 추론해서 플래그로 심었습니다. 좌표가 아예 없는 행이 1.3% 있어서 그것만 카카오 로컬로 주소 지오코딩을 태웠고요. 주변 검색은 애플리케이션에서 계산하지 않고 PostGIS RPC 하나로 끝냈어요.

동기화를 붙이면서 한 번 걸렸습니다. 폐업으로 바뀐 행을 지우면 거기 매달린 찜이랑 기록이 같이 날아가요. 삭제가 아니라 상태만 바꾸는 쪽으로 갔고, 에디터가 손으로 채운 컬럼은 아예 upsert 매핑에서 빼서 동기화가 덮지 못하게 했습니다.

6천 곳을 깔고 나니 더 큰 문제가 보였어요. 후기가 하나도 없었습니다. 리뷰 쓰는 기능을 만들어 봤자 첫날 사용자가 볼 건 빈 화면이고, 목욕탕은 애초에 방문 증명이 안 나와서 사람이 모여도 잘 안 쌓이는 업종이거든요. 우리 리뷰를 기다리는 건 답이 아니었어요.

그런데 후기가 없는 게 아니라 리뷰 칸에 없는 거였습니다. 사람들은 목욕탕 다녀온 이야기를 블로그에 써요. 온도도 거기 있고요 — "사우나실 90도 넘어요" 같은 문장으로. 그래서 우리 리뷰 대신 남의 후기를 빌려오기로 했습니다. 네이버 검색 Open API 로 매장 상호를 던져 관련 글만 추렸어요. 본문을 복제하면 안 되니까 제목·발췌·원문 링크·작성일만 저장하고 표시는 링크아웃으로 했습니다. 남의 글로 콜드스타트를 넘긴 셈이에요.

영업시간이랑 요금표는 검색 API 로 안 나와서 네이버 플레이스 SSR 페이지를 파싱했어요. 처음엔 정규식으로 긁었는데 favicon 만 나오더라고요. __APOLLO_STATE__ 를 JSON 으로 파싱하니까 그때부터 제대로 잡혔습니다. 여기서 한참 고쳐 썼는데, 영업시간을 처음엔 잡히는 대로 다 넣었어요. 목욕탕 업종은 네이버도 값이 없는 경우가 흔해서 부분 정보를 넣으면 오히려 틀린 정보가 됩니다. 풀 스케줄이 확인될 때만 채우게 바꿨고, 요금표는 후기 텍스트에서 숫자를 뽑는 파생 스크립트를 따로 뒀어요.

네이버 업체제공 사진을 받으려다 캡차에 막혀서 수집 불가로 결론 내고, Google Places API 로 방향을 틀었어요. 결제까지 붙였습니다.

그런데 구글은 그 사진을 누가 올렸는지 구분할 방법이 없어요. authorAttributions 에 올린 계정 표시명만 있고 업주인지 손님인지는 안 나옵니다. 같은 이름의 카페 사진이 목욕탕 상세에 걸리기 시작했어요. 두 달쯤 뒤에 네이버 쪽을 다시 봤더니 캡차가 걸린 건 특정 경로였고, 영업시간 때문에 이미 매번 받아오던 페이지 안에 사진 원본 URL 이 그대로 있었습니다. mediaSource 로 업체제공·방문자·블로그연동이 갈려서 업체제공만 고를 수도 있었고요. 방문자 사진은 저작자가 개인이라 안 건드렸어요.

출처를 네이버로 뒤집으면서 원칙 하나를 세웠습니다. 어떤 경로로 받았든 이미지는 전부 우리 Storage 에 재호스팅해서 거기서만 서빙해요. remotePatterns 에 제3자 호스트를 아예 등록하지 않아서 외부 핫링크가 구조적으로 불가능합니다. 출처랑 원본 URL 은 서버 전용이라 클라이언트로 안 내려가고요. 결국 구글 경로는 스크립트 진입점에 가드를 박아 아예 못 돌게 막았어요. 이미 적재된 1,700여 장은 네이버 업체사진이 없는 매장의 폴백으로 남겨 두고, 소스 우선순위에서 네이버가 항상 위에 오게 했습니다. 런타임은 구글을 호출하지 않아요.

기획할 때 로그인은 비목표였어요. 디바이스 식별로 충분하다고 봤거든요. 찜이랑 메모를 로컬 스토리지에 넣었는데, 써보니까 폰에서 찜해둔 곳이 노트북에서 안 보여요. 기기를 바꾸면 그냥 사라지고요. 목욕탕은 "다음에 가봐야지" 하고 담아두는 서비스라 이게 치명적이었습니다. Supabase Auth 로 계정을 붙이고 찜·메모를 DB 로 옮겼어요. 옮기고 나서도 손볼 게 남았는데, 비로그인 상태에서 하트를 누르면 아무 일도 안 일어나는 게 제일 나빴습니다. 로그인 시트를 띄워 유도하고, 찜 페이지랑 기록 탭도 비로그인 전용 화면을 따로 그렸어요. 낙관적 업데이트를 쓰고 있어서 쓰기가 실패하면 상태를 되돌리는 것도 양쪽에 붙였고요.

사진 업로드도 마찬가지였어요. 모더레이션 부담 때문에 처음부터 뺐는데, 크롤로 모은 사진이 매장당 몇 장 안 되는 곳이 꽤 많았습니다. 결국 사진만 열기로 했어요. 혼자 운영하는 서비스라 사람이 검수하는 구조는 못 만드니까 파이프라인 전체를 자동으로 짰습니다. 인증 → 킬스위치 → 레이트리밋(1인 1일 10장) → 타입·크기 검증 → sharp 로 EXIF 회전 반영하고 리사이즈해서 WebP 재인코딩 → Vision SafeSearch 모더레이션 → 게시. insert 가 실패하면 이미 올라간 Storage 객체를 롤백해요. 모더레이션은 페일 클로즈드로 했습니다. 키가 없거나 호출이 실패하면 통과가 아니라 거부예요. 아무도 안 보고 있는 서비스라 미검증 이미지가 공개되는 쪽을 막는 게 맞았어요. 그래도 무언가 새면 재배포 없이 사진·후기 노출을 통째로 끌 수 있게 런타임 킬스위치를 뒀고, 관리자용 사진 관리·신고 처리 화면도 붙였습니다.

반대로 접은 것도 있어요. "다녀옴" 3초 체크인은 원래 핵심이었습니다. 객관식으로 가볍게 남기면 그게 쌓여서 온도나 혼잡도 같은 값이 갱신되는 그림이었거든요. 그런데 로그인을 붙이고 나니 로컬 방문기록이 계정 동기화랑 겹쳤고, 무엇보다 아무도 안 누를 버튼을 상세 화면 제일 좋은 자리에 두고 있었어요. 버튼을 걷어내고 그 자리를 계정 기반 메모로 대체했습니다.

기능이 붙을수록 화면 전환이 굼떴어요. 특히 지도에서 "내 주변"을 누르면 위치 받고, 데이터 받고, 지도 SDK 받는 게 순서대로 돌아서 몇 초씩 흰 화면이었습니다.

홈·지도·읽을거리를 ISR 로 프리렌더하고, 지도는 셸을 먼저 그린 뒤 캐시된 좌표로 즉시 이동시키면서 데이터랑 SDK 를 병렬로 받게 바꿨어요. 목록은 windowing 을 넣었고, 스켈레톤은 실제 레이아웃과 같은 모양으로 다시 그렸습니다. 모양이 다르면 로딩이 끝나는 순간 화면이 튀어서 오히려 더 느리게 느껴지거든요.

체감을 손보는 작업이 생각보다 길게 이어졌어요. 바텀시트 그랩 히트 영역이 좁아서 잘 안 잡히던 것, 매장을 고르면 좌측 패널에 가려진 위치로 센터링되던 것, 스플래시가 끝나기도 전에 위치 권한 팝업이 뜨던 것까지. 하나씩은 사소한데 모이면 완성도가 갈립니다.

범용 라인 아이콘을 쓰다 보니 목욕탕이랑 찜질방이 구분이 안 됐어요. 둘 다 그냥 물방울이나 건물 모양이 되더라고요. 이 서비스는 용어 자체가 콘텐츠라서 그게 안 읽히면 곤란했습니다.

그래서 반복되는 용어마다 전용 플랫 SVG 를 그려서 한 폴더에 모았어요. 대형 씬이랑 16~20px 칩을 짝으로 만들어서, 같은 용어가 홈에서든 지도에서든 같은 그림으로 읽히게 했습니다. 팔레트는 CSS 토큰 한 곳에서만 고치고요. 칩은 다색이라 currentColor 틴트가 안 먹혀서, 활성·비활성 어느 쪽에서도 또렷하게 보이도록 둥근 토큰 배경 위에 얹는 규칙을 따로 뒀어요.

로고까지 갔습니다. 좌상단만 각진 판 모양 마크를 만들어서 앱 아이콘·파비콘·OG·헤더를 전부 교체했어요. OG 이미지는 satori 가 SVG 그라디언트를 못 받아서 div 두 장을 쌓아 같은 그림을 다시 그렸습니다. 마크 색을 바꾸면 두 곳을 같이 고쳐야 하는 부채가 남아 있어요.

어느 시점부터는 새 기능보다 "이 값이 맞나"를 확인하는 쪽이 대부분이었어요. 헬스장·복지관 부속 목욕시설 189곳이 일반 목욕탕처럼 노출되던 것, 전남·광주 행정통합으로 같은 매장이 두 번 들어온 것, 네이버 매칭이 같은 건물 다른 업소를 잡던 것.

헬스장 건은 기획이랑 정면으로 부딪혔습니다. 숨은 목욕탕까지 다 보여주자고 인허가 전수를 깔았는데, 그 전수 안에는 헬스장 샤워실이랑 복지관 부속 목욕시설도 들어 있거든요. 목욕하러 갈 곳을 찾는 사람한테 "◯◯휘트니스사우나"가 섞여 나오면 그 순간 목록 전체가 못 믿을 것이 됩니다. 지우지는 않고 venue_type='community' 로 분류해서 기본 발견 대상에서만 뺐어요. 숨은 곳을 판다는 원칙은 호텔·리조트 부속에서 지키고, 목욕 목적이 아닌 시설은 접었습니다. 반대로 호텔 부속은 "호텔·리조트·콘도" 같은 일반어로만 잡았더니 상호에 그 낱말을 안 쓰는 곳이 전부 일반 목욕탕으로 샜어요. 도미인 서울 강남, 노보텔앰배서더강남, 소노캄 각 지점 같은 것들요. 브랜드명을 규칙에 넣되 일반 목욕탕 상호와 겹치는 낱말은 뺐습니다 — "파라다이스목욕탕"이나 "리베라목욕탕"이 호텔로 분류되면 안 되니까요. "하얏트"는 단독으로 안 쓰고 그랜드·파크·리젠시 접두형만, "라한"은 도로명 "청라한내로"에 걸려서 제외했어요.

축 자체가 좁았던 것도 이때 드러났습니다. 상단 칩이 목욕탕·찜질방·24시·숙박이었는데, 사람들이 실제로 나누는 기준이랑 안 맞았어요. "세신만 하는 1인샵"이랑 "효소찜질"은 완전히 다른 경험인데 둘 다 목욕탕에 섞여 있었거든요. 문제는 그게 목욕장업 인허가에 거의 없다는 거였어요. 세신샵은 업종이 다르고 효소찜질은 데이터에 아예 안 잡힙니다. 그래서 네이버 검색으로 따로 긁는 경로를 팠고, 세신샵은 별도 카테고리로 만들어 일반 목욕탕 필터에서 빠지게 했어요. 새 카테고리마다 전용 칩 일러스트도 그렸습니다 — 세신샵은 하늘색 세신 침대에 초록 때수건, 효소는 모래언덕에 파묻힌 사람.

검증 스크립트도 이때 키웠어요. Storage 와 DB 정합성을 맞춰보는 감사, 고아 객체 정리, 중복 매장 병합, 디렉터리 사이트 후기 제외 같은 것들이요. 판단이 애매한 행은 지우지 않고 needs_review 로 적재만 하고 노출에서 뺐습니다. 매장 소개문은 Claude Code CLI 를 헤드리스로 돌려서 생성하는데, API 키가 아니라 로그인된 플랜으로 돌아가고 결과에 코드펜스가 섞여 나와서 JSON 추출을 방어적으로 해뒀어요. 아직 전 매장에 적용하지는 못했습니다.