hbyang
d32df10cf7
런타임은 한 줄도 안 바뀌었다. 채널을 모르게 만들어 둔 것이 여기서 값을 했다 — 새로 생긴 것은 형식 변환(kakao_bot)과 대화 상태(channel)뿐이다. ★★ 오픈빌더는 서명을 주지 않는다. URL 만 알면 누구나 때릴 수 있고 userRequest.user.id 를 위조하면 그 사장님 행세를 한다 — 1단계의 신원 연결이 통째로 무의미해지는 자리다. 공유 시크릿(헤더 X-Agent-Secret, compare_digest) + 선택적 KAKAO_BOT_ID 대조로 막고, 시크릿이 없으면 엔드포인트가 404 다 (401 은 "여기 뭔가 있다" 를 알려 준다). - router/v1/agent/kakao_bot: 카카오 형식을 아는 유일한 파일. 헤더·경로 두 경로 - services/agent/channel: 신원(★ 토큰을 발급하지 않는다) · 가게 고르기 · 확인 - 0022: owner_kakao_links 에 current_place_id · pending_* 빌더 화면과 다른 것 셋: - 로그인 토큰이 없다 → 발화자 키로 사장님을 찾는다 - place_id 가 URL 에 없다 → 여럿이면 추측하지 않고 되묻는다. 임의로 첫 가게를 고르면 사장님은 엉뚱한 가게를 고쳐 놓고도 모른다 - 확인을 되돌려 줄 프론트가 없다 → 서버가 pending 을 든다. ★ 3분 만료가 없으면 한참 뒤의 "네" 한 마디에 묵은 발행이 돈다 5초 벽은 DEADLINE_SEC=4.0 으로 끊고, 어떤 실패도 200+안내다 — 메신저에서는 500 도 침묵으로 보인다. 밟은 것: execute_lambda 는 람다 반환값을 그대로 준다(CRUD 관례가 (ErrorType,값)). 우리 람다가 객체만 돌려주자 언패킹 TypeError 가 났고, 라우터가 예외를 삼켜 화면에는 안내 한 줄만 보였다 — 원인이 안 보이는 종류다. test_kakao_webhook.py 17 passed. 전체 841 passed / 53 failed(이전과 동일). npm run lint 통과 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| 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_owner_social_accounts.sql | ||
| 0012_place_faqs_template_source.sql | ||
| 0013_job_progress.sql | ||
| 0013_place_social_posts.sql | ||
| 0014_search_console.sql | ||
| 0015_users_token_version.sql | ||
| 0016_alert_outbox.sql | ||
| 0017_place_posts.sql | ||
| 0018_place_reviews.sql | ||
| 0019_place_posts_scheduled_date.sql | ||
| 0020_place_posts_generation_meta.sql | ||
| 0021_owner_kakao_links.sql | ||
| 0021_places_notify_email.sql | ||
| 0022_owner_kakao_links_conversation.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 에 남는다. 이미 있는 번호는 건너뛴다.