docs: 핸드오버에 2026-09-12 확인 결과·§4-1 완료·판단 2건 기록
§1: 미확인으로 남겨 둔 항목을 실제로 확인해 표 앞에 결과를 붙였다. 리드 CTA 와 v2 기준표는 이미 main 에 있고, Supabase 마이그레이션은 전부 적용됐으며, discovery_results 는 없다. supporters-viewclinic 의 /plan 이 404 인 것도 적었다. §2: feature/product-1.0 으로 합친 결과와, 핸드오버가 적지 않은 네 번째 브랜치 Productize(랜딩 SSR 프리렌더·robots/sitemap/llms.txt)를 적었다. §4-1: 완료로 바꾸고 정본 결정이 초안과 반대 방향임을 밝혔다. §5: haewon 이 답한 두 항목(Product 1.0 범위 b, supporters 정본)을 결정으로 적었다. §5-2 신설: 이번 세션에 내린 판단 2건을 발견·이유·한 것·되돌리는 법으로 남겼다. 영문 의료광고 고지를 승인 없이 번역하지 않기로 한 것과, 누락 탐지기가 상호만 찾아 지명으로 적힌 사실을 놓치던 것을 고친 내용이다. 빈 데이터로 빌드해 봐야 하드코딩이 드러난다는 것과, 게이트가 통과해도 빈 값이 만든 비문은 잡히지 않는다는 것을 함께 적었다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
e7a11ef67a
commit
b79565a6a6
@ -1,6 +1,6 @@
|
||||
# 다음 세션 핸드오버 · 2026-09-12 · INFINITH AI Discovery Product 빌드
|
||||
|
||||
작성 2026-09-11 · 작성자 Claude (haewon 세션) · 상태: 초안(haewon 검토 전)
|
||||
작성 2026-09-11 · 갱신 2026-09-12(토) · 작성자 Claude (haewon 세션) · 상태: §1 확인 완료, §4-1 완료
|
||||
하위 문서: 서포터즈 사이트 빌드 절차 `~/orca/workspaces/INFINITH/Productize/docs/NEXT_SESSION_2026-09-12_PRODUCT_BUILD.md`, 자동 빌드 상세 `…/NEXT_SESSION_SUPPORTERS_AUTOBUILD_v3.md`, 자동 채점 `docs/AI_DISCOVERY_BUILD2_HANDOVER.md`, 회고 `docs/INFINITH_AI_Discovery_Retrospective_2026-09-08.md`.
|
||||
|
||||
## 0. 세션 시작 시 붙여 넣을 프롬프트
|
||||
@ -17,6 +17,18 @@ INFINITH AI Discovery Product 빌드 세션. 제품은 "병원 URL 하나 → AI
|
||||
|
||||
## 1. 제품 여정과 현재 상태
|
||||
|
||||
> **2026-09-12 확인 결과.** 아래 표에서 "확인"으로 남겨 둔 두 항목은 이미 해결된 상태였다. 다음 세션은 이 전제로 시작한다.
|
||||
>
|
||||
> | 항목 | 이전 기재 | 실제 | 근거 |
|
||||
> |---|---|---|---|
|
||||
> | 랜딩 리드 CTA | 미머지 | **main 에 있음.** `feature/discovery-url-cta` 는 main 대비 ahead 0 / behind 22 인 낡은 포인터라 머지 대상이 아니다 | `DiscoveryLeadModal.tsx`·`DiscoveryLandingPage.tsx`·`20260831_discovery_leads.sql` 이 main 에 있고 blob 해시가 세 브랜치 동일 |
|
||||
> | AEO/GEO v2 기준표 | main 머지 여부 확인 필요 | **main 에 있음** | `aeoGeoRubricV2.ts`·`discoveryScoreV2.ts` blob 해시 세 브랜치 동일 |
|
||||
> | Supabase 마이그레이션 | 적용 상태 확인 필요 | **전부 적용됨.** `discovery_leads` 0행, `supporter_builds` 2행, `supporter_inputs` 0행 | REST 조회 HTTP 200 |
|
||||
> | `discovery_results` | (§4-3 대상) | **없음(HTTP 404).** §4-3 미착수 확정 | REST 조회 |
|
||||
> | launchd 폴러 | 설치됨 | **로드됨, 마지막 종료 코드 0** | `launchctl list` |
|
||||
> | 배포 | 3곳 | **4곳 모두 200.** 단 `supporters-viewclinic/plan` 은 404(2026-09-07 빌드라 플래너 이전 판) | HTTP 확인 |
|
||||
|
||||
|
||||
| 단계 | 고객이 보는 것 | 구현 | 위치 | 상태 |
|
||||
|---|---|---|---|---|
|
||||
| 1 진입 | `/discovery` 랜딩, "URL 입력으로 시작" | `DiscoveryLandingPage.tsx`, `DiscoveryLeadModal` → Supabase `discovery_leads` | 메인, 브랜치 feature/discovery-url-cta | 프리뷰만. **미머지, 마이그레이션 `20260831_discovery_leads.sql` 적용 여부 확인** |
|
||||
@ -40,7 +52,10 @@ INFINITH AI Discovery Product 빌드 세션. 제품은 "병원 URL 하나 → AI
|
||||
| Supabase | `supabase/migrations/` (`supporter_builds`, `supporter_builds_queue`, `discovery_leads`) + Edge Functions(기존 리포트 파이프라인) | 메인 | 적용 상태 확인 필요(CLI 토큰 만료 이력) |
|
||||
| 키 | Productize `.env`(TOUR_API·NAVER·OPENAI·YOUTUBE), 메인 `.env`(진단·QB) | | 회사 계정. 세션 시작 때 `grep -E "^KEY=." .env` 로 값 존재만 확인 |
|
||||
|
||||
세 브랜치는 서로 머지되지 않았다. `supporters/` 폴더가 양쪽에 있고 Base.astro 구현이 다르다(메인: i18n.ts 전역 전환·영어 홈; Productize: langswitch·영어 입구 /en/plan). 플래너·지도·헤더 CSS 는 같다.
|
||||
**2026-09-12 갱신**: feature/supporters-autobuild 와 feature/ai-sentiment-rubric 을 `feature/product-1.0` 으로 합쳤다. feature/discovery-url-cta 는 main 에 이미 담겨 있어 제외했다.
|
||||
핸드오버가 적지 않은 **네 번째 브랜치 `Productize`** 가 있다. 고유 커밋 1개(랜딩 SSR 프리렌더·메타/JSON-LD·robots/sitemap/llms.txt)를 갖고 main 대비 74 뒤이며 origin 에 올라가 있다. 랜딩의 AI 크롤러 가독성이라 AEO 와 직접 닿는데, 합칠지 버릴지 아직 안 정했다.
|
||||
|
||||
(아래는 머지 전 상태 기록) 세 브랜치는 서로 머지되지 않았다. `supporters/` 폴더가 양쪽에 있고 Base.astro 구현이 다르다(메인: i18n.ts 전역 전환·영어 홈; Productize: langswitch·영어 입구 /en/plan). 플래너·지도·헤더 CSS 는 같다.
|
||||
|
||||
## 3. 지금 되는 것 / 안 되는 것 (한 줄씩)
|
||||
|
||||
@ -59,7 +74,9 @@ INFINITH AI Discovery Product 빌드 세션. 제품은 "병원 URL 하나 → AI
|
||||
|
||||
## 4. Product 빌드 순서 (권장)
|
||||
|
||||
1. **브랜치 정리**: `main` 기준으로 feature/supporters-autobuild(워커·템플릿·v2 기준표·GA4) → feature/ai-sentiment-rubric(감성·플래너·지도·설계 v0.2) → feature/discovery-url-cta(리드 CTA) 순으로 머지. 충돌 지점은 `supporters/`(Base.astro 두 구현)와 `src/data/aeoGeoRubric*`·`discoveryScoreV2`. 결정: `supporters/` 는 템플릿(Productize) 구현을 정본으로 하고 뷰 샘플은 워커 폴더로 옮긴다(§5-4).
|
||||
1. ~~**브랜치 정리**~~ **완료 (2026-09-12, 브랜치 `feature/product-1.0`)**. feature/supporters-autobuild 는 main 의 상위집합이라 fast-forward 했고, feature/ai-sentiment-rubric 머지에서 충돌 8건이 났다. 겹친 22개 파일 중 실제로 다른 것은 9개뿐이었다. feature/discovery-url-cta 는 낡은 포인터라 제외했다.
|
||||
- **정본 결정(haewon)**: `supporters/`(뷰 수작업 샘플)를 정본으로 한다. 핸드오버 초안의 "템플릿을 정본으로" 와 반대 방향이다. `templates/supporters-astro/` 는 `npm run export:template` 로 `supporters/` 에서 생성되는 파생물이므로 구조적으로 맞아떨어진다.
|
||||
- Productize 쪽에만 있던 GA4 태그와 영문 법적 고지 처리를 정본으로 이식했다.
|
||||
2. **리드 → 큐 연결**: `discovery_leads` 마이그레이션 적용 → insert 시 `supporter_builds` 큐에 행 생성(DB 트리거 또는 폴러가 leads 도 읽기) → 워커가 evidence 부터 완주 → 미리보기 URL 을 `supporter_builds.preview_url` 에 기록 → 신청자에게 링크 회신(초기에는 수동 메일, `o2oteam@o2o.kr`).
|
||||
3. **진단 결과 런타임화**: `audit_aeo_geo.py` 출력 JSON 을 Supabase(`discovery_results`) 또는 스토리지에 저장하고 `/discovery/:id` 가 런타임에 읽는다. 기존 `DISCOVERY_RESULTS` 레지스트리는 샘플(뷰) 전용으로 남긴다. 사람 판정(v2Results 4항목)은 확인 패널에서 입력.
|
||||
4. **재빌드 자동화**: `supporter_inputs` insert → 큐 → `run.mjs --from data --from-supabase`. 색인 허용 빌드(`PUBLIC_INDEXABLE=true`)는 `approvedAt` 있는 글만 낸다는 규칙 유지.
|
||||
@ -70,15 +87,38 @@ INFINITH AI Discovery Product 빌드 세션. 제품은 "병원 URL 하나 → AI
|
||||
|
||||
## 5. haewon 결정 대기
|
||||
|
||||
1. **Product 1.0 범위**: (a) 진단 리포트만, (b) 진단 + 서포터즈 사이트 초안, (c) b + 측정·관리 구독. 랜딩 CTA 의 약속 범위가 달라진다.
|
||||
1. ~~**Product 1.0 범위**~~ **결정 (2026-09-12, haewon): (b) 진단 + 서포터즈 사이트 초안.** 랜딩 CTA 는 여기까지 약속한다. 측정·관리는 내부 참고로만 쓰고 약속하지 않는다. 남은 일은 §4-2 리드→큐 연결과 §4-3 진단 런타임화다.
|
||||
2. **가격 티어**(§4-7)와 계약 최소 기간·해지 조건(2026-04 문서의 P0 두 항목이 그대로 미결).
|
||||
3. **뷰 샘플 통일**: 메인 `supporters/` 를 워커 폴더(`~/supporters-builds/viewclinic`)로 옮기고 `view-supporters-sample` 을 워커 배포로 바꿀지. 옮기면 뷰의 영어 홈 `/en` 은 템플릿에 없으므로 템플릿에 영어 홈을 추가할지 함께 결정.
|
||||
3. ~~**뷰 샘플 통일**~~ **결정 (2026-09-12, haewon): 메인 `supporters/` 가 정본.** 템플릿은 `npm run export:template` 로 여기서 생성한다. 영어 홈 `/en` 은 템플릿에 추가했고 영문 사실이 없는 병원에서도 문장이 성립하도록 조각 단위로 조립한다(§5-2 판단 2). `view-supporters-sample` 배포 자리를 워커로 옮길지는 아직 안 정했다.
|
||||
4. **법무**: 외국인환자 유치업 등록 여부(플래너·숙소 링크), 의료광고 사전심의 대상 여부, 지원 관계 고지 문구(sponsorNotice). 이 세 가지는 색인 허용 전환의 전제.
|
||||
5. **도메인**: 별도 도메인 vs 병원 서브도메인(설계 v0.1 §3 2안). 서포터즈 실명 모집 방식.
|
||||
6. **워커 호스팅**과 GCP 계정(GA4 서비스 계정).
|
||||
7. **규칙표 잠정값**: 뷰·원진·오라클 `procedures.json` 의 provisional 값(출국 최소일·입원·실밥)을 병원 확인 뒤 공개할지, 공개 전까지 "병원 확인 전" 배지로 둘지.
|
||||
8. 서포터즈 빌드 하위 결정(하위 문서 §4)과 오라클 핸드오버 §3 미결은 그대로.
|
||||
|
||||
## 5-2. 2026-09-12 세션에서 내린 판단 (기록)
|
||||
|
||||
핸드오버에 없던 것을 작업 중에 발견해 판단한 두 가지다. 되돌리려면 아래 "되돌리는 법"대로 하면 된다.
|
||||
|
||||
### 판단 1. 영문 의료광고 고지를 병원 승인 없이 번역하지 않는다
|
||||
|
||||
- **발견**: 정본이 된 `supporters/src/lib/i18n.ts` 가 지원 관계 고지와 부작용 고지를 영문으로 번역해 푸터에 싣고 있었다. `site.json` 에 `sponsorNoticeEn` 은 없었고, 어디에도 병원 승인 표시가 없었다. Productize 쪽 구현은 같은 자리에서 번역을 거부하고 한국어 원문에 확인 대기 표기를 붙이고 있었다.
|
||||
- **왜 문제인가**: 지원 관계 고지와 부작용 고지는 의료법 56조와 추천보증 심사지침의 규율 대상이다. 문구를 임의로 번역하면 병원이 승인하지 않은 문장이 병원 이름으로 나간다. §5-4 법무가 미결이고 색인 허용의 전제로 적혀 있는 항목이다.
|
||||
- **한 것**: `Base.astro` 가 `site.json` 의 `sponsorNoticeEn` 과 factSheet 의 `sideEffectNoticeEn` 을 먼저 읽고, 없으면 한국어 원문을 싣고 "The English wording of these notices is pending clinic approval." 을 함께 낸다. `i18n.ts` 의 영문 `foot_sponsor`·`foot_side` 는 이 자리에 쓰지 않는다고 주석으로 표시했다.
|
||||
- **되돌리는 법**: 병원이 영문 문구를 확정하면 `site.json` 에 `sponsorNoticeEn`, factSheet 에 `sideEffectNoticeEn` 을 넣는다. 코드 수정은 필요 없고 확인 대기 표기가 자동으로 사라진다.
|
||||
|
||||
### 판단 2. 누락 탐지기를 고쳐 상호 밖의 고유 사실까지 잡는다
|
||||
|
||||
- **발견**: `export_template.mjs` 의 `CLINIC_RE` 가 상호(`뷰성형외과`·`viewclinic`)만 찾아서 지명으로 적힌 사실을 놓쳤다. 빈 데이터로 템플릿을 빌드하니 영어 홈이 `Founded 확인 대기 · Sinnonhyeon Station Exit 3` 를 냈다. 또 이 검사는 빌드 도구의 기본 인자(`--clinic viewclinic`) 때문에 늘 실패해 신호가 되지 못했다.
|
||||
- **왜 문제인가**: 템플릿은 모든 병원 사이트의 원본이다. 화면을 그리는 코드에 한 병원의 사실이 문장으로 박히면 다른 병원 화면에 **틀린 사실**이 나간다. 값이 비어 화면이 비는 것과 다르다.
|
||||
- **한 것**: 지명·건물 표현(`Sinnonhyeon`·`Bongeunsa`·`Gimpo`·`신논현`·`봉은사`·`19-storey`·`View Plastic`)을 패턴에 넣었다. 그리고 심각도를 나눠, 문장을 그리는 코드(`src/pages`·`layouts`·`components`·`lib`)에 남으면 내보내기를 멈추고, 데이터(`src/data`)와 빌드 도구(`scripts`)는 알림만 한다. 데이터는 워커가 병원마다 갈아끼우고 빌드 도구는 고객이 보지 않기 때문이다.
|
||||
- **곁가지로 잡은 것**: 같은 점검에서 영어 홈의 하드코딩 7곳(공항 경로·건물 층수·히어로 alt·영문 병원명·404 상호·히어로 칩·머리말 기본값 `VIEW SUPPORTERS`)과, 영문 사실이 없는 병원에서 문장이 `is a at .` 로 깨지는 문제를 함께 고쳤다. 게이트는 두 가지 모두 오류로 잡지 못한다.
|
||||
|
||||
### 여기서 배운 규칙
|
||||
|
||||
- **템플릿에 넣기 전 빈 데이터로 빌드해 본다.** 한 병원의 데이터로만 확인하면 하드코딩과 데이터 참조가 구별되지 않는다. 화면이 같아 보이기 때문이다.
|
||||
- **게이트가 통과해도 화면은 깨질 수 있다.** 게이트는 의료광고 문구와 금칙어를 보지, 빈 값이 만든 비문을 보지 않는다. 배포 전 로컬 확인이 필요한 이유다.
|
||||
|
||||
## 6. 함정 (제품 관점)
|
||||
|
||||
- **한 Vercel 프로젝트에 두 폴더**: 2026-09-11 Productize/supporters 와 메인 supporters 가 같은 프로젝트에 배포해 `/plan` 이 404 됐다. 지금은 Productize 쪽 연결을 껐다. 배포는 병원 폴더와 메인 supporters 에서만.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user