Mina Choi
079c93a62a
작업트리에 커밋되지 않은 채 쌓여 있던 것과, 오늘 찾은 문제 셋을 함께 담는다. ## 1. 콘텐츠 생성 진행 상태 (작업트리에 있던 것) COPY 잡의 실제 단계를 DB에 기록하고 응답으로 내보낸다. 폴링 횟수로 진행률을 흉내 내던 것을 걷어냈다. 새로고침·재접속해도 jobId 로 이어서 본다. - services/copy_steps.py · services/job_progress.py · common/job_errors.py (신규) - postgres-init/migrations/0013_job_progress.sql + init.sql - 프론트: useGenerationJob · generationLabels (신규), Step5Generating·pollJob 배선, orval 모델 갱신(jobProgress · jobStep · jobStepStatus · jobStepReason) - docs/GENERATION_FLOW.md (신규) ## 2. 발행된 사이트만 색인한다 실측(2026-09-15): 디스크의 발행본 33곳 중 **15곳이 draft 인데 `index, follow`** 였고 사이트맵에도 올라가 있었다. 사장님이 발행 버튼을 누른 적 없는 사이트가 짓다 만 상태로 구글에 실려 있었다는 뜻이다. head.ts 가 robots 를 하드코딩하고 payload 의 `site.status` 를 보지 않았다. "색인을 막을 이유가 없다"는 주석은 굽는 것이 곧 발행이던 시절의 말인데, 지금은 빌더 미리보기만 눌러도 draft 로 구워진다. - seo/head.ts: PUBLISHED 일 때만 index, 아니면 `noindex, follow` - 사이트맵·`/s` 목록·llms.txt 에서도 함께 빠진다 — 그쪽은 구운 HTML 의 robots 를 읽어 거른다(seo/directory.ts readBakedNoindex). 규칙을 두 자리에 두지 않으려고 한 곳에 뒀다 ## 3. [새로 크롤링하고 사이트 생성하기] 를 뒤집지 않는다 |
||
|---|---|---|
| .. | ||
| 0000_drop_companies.sql | ||
| 0001_place_contents_external_category.sql | ||
| 0002_spots_shared.sql | ||
| 0003_site_contents.sql | ||
| 0004_local_contents_unify.sql | ||
| 0005_flatten_schemas.sql | ||
| 0006_prune_unused.sql | ||
| 0007_story_rows_per_kind.sql | ||
| 0008_personalization_to_site_sections.sql | ||
| 0009_align_with_init_sql.sql | ||
| 0010_place_songs.sql | ||
| 0011_area_contents_status_index.sql | ||
| 0011_place_itineraries.sql | ||
| 0012_place_faqs_template_source.sql | ||
| 0013_job_progress.sql | ||
| 0014_search_console.sql | ||
| README.md | ||
마이그레이션 — 이미 만들어진 DB 를 따라오게 하는 파일
init-data/init.sql 은 새 DB 를 세우는 전체 DDL 이고 계속 최신을 유지한다.
여기 파일들은 이미 데이터가 든 DB 를 그 최신으로 끌어올린다. 둘 다 필요하다.
왜 생겼나 (2026-09-09)
DECISIONS.md 는 누적 ALTER 를 없애면서 이렇게 적어 뒀다 —
"아직 git·서버 어디에도 안 올라가 보정할 기존 DB 가 없다 … 운영 DB 가 생기는 순간
다시 필요해진다". 그 순간이 왔다.
실제로 터졌다: 로컬 DB 에 local.place_contents 테이블과 place.places.external_category
컬럼이 없었다. init.sql 에는 둘 다 있었지만 그 파일은 DB 를 처음 만들 때만 돈다.
TourAPI 가 주변 정보를 받아 와도 저장할 곳이 없어 축제·맛집이 0건이었고,
화면에는 "그냥 안 나오는 것"으로 보였다 — 원인을 짚는 데 한참 걸렸다.
규칙
- 파일명
NNNN_한글_요약.sql— 번호는 이어 붙인다. 지운 번호를 재사용하지 않는다. ★ 예외는0000_drop_companies하나다 — 이 폴더가 생기기 전(09-08) 변경을 뒤늦게 옮긴 것이라 0005 보다 앞에 둔다. 이미 전부 적용한 DB 에는 마지막에 돌므로 존재 검사로 감싸 두었다(파일 머리주석). - 재실행 안전하게 쓴다(
IF NOT EXISTS·ADD COLUMN IF NOT EXISTS). 적용 기록이 있어도 사람이 손으로 한 번 더 돌릴 수 있다. - 한 파일 = 한 가지 변경. 여러 테이블을 건드려도 목적이 하나면 한 파일이다.
init.sql도 같이 고친다. 새 DB 는 그 파일만 읽는다 — 여기만 고치면 새로 세운 DB 에 그 변경이 없다(tests/test_schema_ddl.py가 ORM 과의 어긋남은 잡지만, init.sql 과 이 폴더의 어긋남은 아무도 안 잡는다).
적용
cd solution/backend && .venv/bin/python scripts/migrate.py # 안 돌린 것만
cd solution/backend && .venv/bin/python scripts/migrate.py --dry-run # 목록만
적용 기록은 public.schema_migrations 에 남는다. 이미 있는 번호는 건너뛴다.