[INFRA] 운영에 PINLOG_AI_BASE_URL이 없다 — 실패가 조용히 삼켜진다

[minyongP]

AI 연동에 필요한 환경변수 두 개가 운영 배포 계약에 없다. #101과 같은 뿌리(운영 주입 계약 누락)이지만 고치는 값과 결정 주체가 달라서 따로 남긴다.

#101과 순서가 얽혀 있다. 아래 2번 때문에 #101의 SPRING_PROFILES_ACTIVE=prod를 먼저 켜면 파드가 기동에 실패한다. 두 이슈를 같이 봐야 한다.

@cherry-go-round 주입 쪽, @colosair 주소 결정 쪽을 봐 주면 좋겠다.

1. PINLOG_AI_BASE_URL — 운영에서 localhost로 해석된다

back/src/main/resources/application.yml:79

pinlog:
  ai:
    base-url: ${PINLOG_AI_BASE_URL:http://localhost:8000}

application-prod.yml에 pinlog.ai override가 없고, 인프라도 이 변수를 주입하지 않는다. 그래서 운영 파드는 자기 자신의 8000 포트로 AI를 호출한다.

실패 모드가 완전히 무음이다. 연결이 거부되면 AiProcessClient가 예외를 삼키고, Context 상태는 PENDING으로 남고, 재스캔은 아직 없다(#99). 결과는 파드는 뜨고, API는 200을 주고, 임베딩만 하나도 생기지 않는 상태다 — 이 연동이 애초에 막으려던 상태와 똑같다.

이 지적은 PR #82 리뷰(2026-07-29)에서 이미 나왔는데 반영되지 않았다. 당시 제안은 "application-prod.yml에 주소를 적어라"였지만, #101에서 확인된 대로 prod 프로파일 자체가 활성화되어 있지 않아 그렇게 고쳐도 적용되지 않는다. 리뷰가 프로파일이 켜져 있다고 전제했다.

2. PINLOG_AI_INTERNAL_SECRET — 프로파일을 켜는 순간 기동을 막는다

AiProcessClient의 requireSecret은 JwtKeyProvider와 같은 기준으로 갈린다 — 운영 프로파일이면 기동 실패, 그 외는 경고 후 빈 값.

운영 프로파일에는 pinlog.ai.internal-secret(PINLOG_AI_INTERNAL_SECRET)이 필요하다.

인프라가 이 값을 주입하지 않는다. 따라서 #101에서 SPRING_PROFILES_ACTIVE=prod를 넣는 순간, JWT 키를 제대로 넣었더라도 이 값이 없어서 파드가 뜨지 않는다.

지금 프로파일이 꺼져 있어서 이 fail-fast도 무력화된 상태다. 현재 운영 파드는 빈 시크릿으로 동작하고 있고, FastAPI가 모든 호출을 401로 거절하며, 그 실패는 삼켜진다. 1번과 합쳐 두 겹으로 무음이다.

확인한 것

확인 대상	상태
back/.../application.yml:79, :82	둘 다 기본값 있음 — http://localhost:8000, 빈 문자열
back/.../application-prod.yml	pinlog.ai 블록 없음
infra/ 전체	PINLOG_AI_BASE_URL·PINLOG_AI_INTERNAL_SECRET 주입 없음 (걸리는 것은 .github/workflows/ai-image-update.yaml의 GitHub Actions 토큰들뿐, 무관하다)
infra/apps/	prod에는 back만 있다. AI 서비스는 dev에만 배포되어 있다 (apps/dev/ai)
back/docs/development/configuration.md:82-86	인프라 요청 대상 표에 PINLOG_AI_INTERNAL_SECRET이 없다 (PR #82 리뷰 지적, 미반영)

먼저 정해야 하는 것

운영에서 back이 어느 AI 서비스를 호출하는가. apps/prod에 AI가 없으니 주소를 적을 수가 없다. 세 가지 중 하나를 정해야 한다.

1. AI를 prod에도 배포한다 → 주소는 http://ai.pinlog-prod.svc.cluster.local:8000 형태
2. 운영 back이 dev의 AI를 호출한다 → 네임스페이스를 가로지르는 주소, 그리고 그렇게 해도 되는지 판단이 필요하다
3. 운영에서는 AI 연동을 끈다 → 그러면 지금처럼 조용히 실패하게 두지 않고 명시적으로 끄는 방법이 필요하다(현재 그런 스위치는 없다)

이건 AI 파트·인프라 결정이라 백엔드가 단독으로 정하지 않는다.

해야 할 일

백엔드 (주소가 정해진 뒤)

• application-prod.yml에 pinlog.ai.base-url을 적는다. 설정 규약대로 주소는 비밀이 아니므로 파일에 박고, 환경변수 이름을 새로 만들지 않는다(configuration.md "비밀값과 자격증명 주입"). application.yml의 ${PINLOG_AI_BASE_URL:http://localhost:8000}은 로컬 기본값으로 남긴다
• configuration.md의 인프라 요청 표에 PINLOG_AI_INTERNAL_SECRET을 넣는다

인프라

• PINLOG_AI_INTERNAL_SECRET을 SealedSecret으로 만들어 apps/prod/back/values.yaml의 env:에 넣는다. 값은 AI 쪽과 공유하는 시크릿이라 양쪽이 같아야 한다(헤더 이름 X-Internal-Secret, 원본은 ai 레포 app/core/security.py)
• #101의 SPRING_PROFILES_ACTIVE=prod보다 먼저 들어가야 한다. 순서가 뒤바뀌면 파드가 기동에 실패한다

참고

• [INFRA] 운영에 prod 프로파일이 꺼져 있다 — fail-fast 미작동, API 문서가 외부에 열려 있다 #101 — JWT_PRIVATE_KEY 미주입, prod 프로파일 미활성. 프로파일 활성화 선행 조건이 이 이슈다
• AI 연동 실패 경로 4곳이 전제하는 재스캔이 존재하지 않는다 — 실행 주체 결정 필요 #99 — 재스캔 부재. 1번의 무음 실패가 복구되지 않는 이유다
• PR feat(S15P11A705-102): Context 생성·교체 시 AI 처리 접수 #82 리뷰 — 1번을 처음 지적한 곳
• docs/backend/implements/BI-22-2026-07-29-context-ai-enqueue.md — AI 처리 접수 구현

[colosair]

주소 결정 쪽으로 지목해 주신 건입니다. 결정에 앞서 확인된 사실 셋을 전달합니다.

1. dev AI 워크로드가 꺼져 있습니다

infra 442a64f 기준 apps/dev/ai/values.yaml 첫 줄과 설정입니다.

# AI dev scaffold. 승인되지 않은 계약이 남아 있어 workload는 의도적으로 차단한다.
application:
  enabled: false
deployment:
  enabled: false

선택지 2(운영 back 이 dev AI 호출)는 부를 대상이 없어 성립하지 않습니다. 이슈 본문의 "AI 서비스는 dev 에만 배포되어 있다" 는 정확히는 "dev 에 scaffold 만 있고 어디에도 기동되어 있지 않다" 입니다.

2. AI 파트 Secret 등록은 끝났습니다

ai 저장소 pinlog-secrets-dev Environment 에 앱 Secret 3개(GMS_API_KEY·GMS_BASE_URL·INTERNAL_SHARED_SECRET)를 등록했고, 배포 브랜치를 main 하나로 제한했습니다. PINLOG_INFRA_SECRET_PR_TOKEN 은 인프라가 직접 발급·등록할 예정입니다.

다만 infra/tools/validate_ai_dev_prerequisites.py 는 아직 owner 7키 + DB 1키의 exact 8-key schema 를 요구하고, docs/ai-dev-prerequisites.md 는 artifact 경로를 전제합니다. 3키 확정이 그 두 곳에 반영돼야 gate 가 열립니다 — 이건 Team-PinLog/ai#39 에 따로 여쭈어 두었습니다.

3. 주소 결정보다 상위에 미결이 하나 있습니다

발표 시연 범위가 확정되지 않았습니다. 전체 통합 / 부분 / 로컬 통합 세 안 중 로컬 통합이 잠정 결론이었고 최종 결정은 백엔드 core 완료 시점 확인 이후로 미뤄져 있습니다.

• 로컬 통합이면 운영에서 AI 를 호출할 일이 없어 선택지 3(명시적으로 끄기)이 됩니다
• 전체 통합이면 선택지 1(prod 배포)이고, pgvector 가 설치된 prod DB 와 GMS 호출 비용이 함께 붙습니다

이 결정이 서면 주소는 따라 나옵니다. 반대로 지금 주소만 먼저 정하면 시연 범위가 뒤집힐 때 함께 뒤집힙니다.

4. Flyway 기준선

같은 gate 를 막는 것이 하나 더 있습니다. infra/docs/ai-dev-prerequisites.md 2절이 여섯 파일(V1·V2·V3·V100·V101·V102)만 있고 다른 V*__*.sql 이 없을 것을 조건으로 두는데, 현재 dev 에는 여덟 개가 있습니다.

V1__create_schemas · V2__member · V3__core_domain
V4__social_account · V5__collection_published_at_invariant
V100__ai_tables · V101__ai_indexes · V102__feed_event

백엔드 소관이라 판단은 드리지 않고 관측만 전달합니다.

---

AI 파트 판단은 3번이 정해진 뒤에 드리겠습니다. 그 전에 인프라 쪽에서 dev workload 차단 사유("승인되지 않은 계약")가 무엇인지 확인되면 순서가 더 분명해집니다.

[cherry-go-round]

백엔드 쪽입니다. 본문의 전제가 #98 머지로 두 군데 바뀌었고(01:28 머지 — 본문 작성 00:39과 위 댓글 01:40 사이입니다), 그중 하나는 실패 성격 자체를 바꿉니다. 그리고 위 4번(Flyway 기준선)에 백엔드 판단을 답합니다.

1. 이제 무음이 아닌 소비자가 하나 생겼다

본문이 *"1번과 합쳐 두 겹으로 무음"*이라고 정리한 시점에는 소비자가 AiProcessClient 하나였습니다. #98이 AiSearchClient를 넣었고 이쪽은 삼키지 않습니다.

 * @throws AiSearchException 호출이 실패했을 때. <b>빈 목록으로 대신하지 않는다</b>

연결 거부·타임아웃도 AiSearchException.unavailable()로 올라갑니다(AiSearchClient:124-128). 따라서 운영에서 PINLOG_AI_BASE_URL이 localhost:8000으로 남아 있으면 이렇게 갈립니다.

소비자	주소가 틀렸을 때	관측
AiProcessClient (임베딩 접수)	삼킴, PENDING 잔류	로그뿐 — 본문이 지적한 무음
AiSearchClient (개인 검색)	예외 → 사용자에게 오류 응답	눈에 보임

진단 관점에서는 오히려 나아졌습니다 — 주소 누락이 드러나는 경로가 하나 생겼습니다. 다만 시연에서 검색을 보여주면 거기서 바로 터집니다. 무음 실패는 "기능이 없는 것처럼 보이는" 정도지만 이쪽은 오류 화면입니다.

2. 프로파일을 막는 fail-fast가 셋으로 늘었다 — 다만 주입할 값은 여전히 둘

AiSearchClient:94가 embedding-profile에도 같은 기준(matchesProfiles("prod"))의 fail-fast를 걸었습니다. 인프라가 넣어야 할 값이 셋으로 늘어난 것은 아닙니다.

값	prod 프로파일에서	주입 필요
JWT_PRIVATE_KEY	기동 실패	필요 (#101)
PINLOG_AI_INTERNAL_SECRET	기동 실패	필요 (이 이슈)
PINLOG_AI_EMBEDDING_PROFILE	기동 실패	불필요 — 리터럴 기본값이 파일에 있어 이미 충족(BD-39)

세 번째는 비밀값이 아니라 일부러 파일에 둔 값이라 환경변수는 실험·롤백용 덮어쓰기입니다. 인프라 요청 목록에 넣지 않아도 됩니다.

3. #101은 지금 절반 풀 수 있다 — 두 이슈가 완전히 묶여 있지는 않다

본문이 *"#101의 SPRING_PROFILES_ACTIVE=prod를 먼저 켜면 파드가 기동에 실패한다"*고 한 것은 맞습니다. 그런데 #101의 실제 피해는 프로파일이 아니라 키 주입으로 사라집니다.

private-key: ${JWT_PRIVATE_KEY:}는 application.yml:107 — base 설정입니다. application-prod.yml이 아닙니다. 즉 프로파일이 꺼진 지금 상태에서도 값을 주입하면 그대로 읽힙니다.

조치	얻는 것	이 이슈를 기다려야 하는가
JWT_PRIVATE_KEY 주입만	배포·재시작 때 전면 로그아웃이 지금 사라진다	아니오
SPRING_PROFILES_ACTIVE=prod	fail-fast 복원 + 운영 API 문서 차단	예

그래서 인프라 순서를 이렇게 쪼갤 수 있습니다 — 키 주입은 시연 범위 결정과 무관하게 지금 진행, 프로파일 활성화만 위 3번 결정과 PINLOG_AI_INTERNAL_SECRET 뒤로. 실제 사용자 피해가 있는 쪽이 결정 대기에 걸려 있지 않아도 됩니다.

4. 선택지 3(운영에서 AI 끄기)은 백엔드 작업이 있다

본문이 *"현재 그런 스위치는 없다"*고 적은 것을 조금 더 정확히 하면, 끌 방법이 없는 정도가 아니라 프로파일을 켤 수 없습니다.

AiIntegrationConfig는 조건 없이 빈을 만들고, requireSecret은 시크릿의 사용 여부가 아니라 프로파일만 봅니다. 그래서 로컬 통합으로 결정돼도 프로파일을 켜려면 둘 중 하나가 필요합니다.

1. 더미 시크릿 주입 — 하면 안 됩니다. 401 무음 상태로 되돌아가고, 그걸 막으려고 넣은 fail-fast를 무력화합니다
2. pinlog.ai.enabled 같은 명시적 스위치를 백엔드가 추가 — "끈 상태"와 "조용히 실패하는 상태"가 구별됩니다

위 3번이 로컬 통합으로 서면 2번이 백엔드 후속 티켓입니다. 결정이 나면 착수하겠습니다. 반대로 전체 통합이면 필요 없습니다.

5. 위 4번(Flyway 기준선) — 백엔드 판단입니다

관측만 주셨으니 판단을 답합니다. 고정 6파일 목록은 유지될 수 없는 조건입니다.

백엔드는 V2–V99를 계속 늘립니다(CLAUDE.md 7번). 지금 여덟 개고, 심사 중인 #97이 머지되면 V6__social_account_email_not_null.sql로 아홉 개가 됩니다. 백엔드가 마이그레이션을 추가할 때마다 AI dev gate가 닫힙니다 — 조건이 백엔드의 정상 작업을 위반으로 판정합니다.

infra/docs/ai-dev-prerequisites.md 2절의 조건은 파일 목록이 아니라 범위 규약으로 바꾸는 편이 맞습니다.

• V1은 공용 스키마 생성
• V2–V99는 백엔드 소유 — 개수·이름을 조건에 넣지 않는다
• V100–V199는 AI 소유 — V102__feed_event가 만드는 core.feed_event를 백엔드가 재정의하지 않는다는 것이 실제 지켜야 할 계약이다
• 그 범위 밖 파일이 있으면 위반

적용 순서가 환경마다 다르고 out-of-order: true라, 확인해야 하는 것은 "어떤 파일이 몇 개 있는가"가 아니라 "각 파트가 자기 범위를 벗어났는가"입니다. 인프라 쪽 파일이라 백엔드가 직접 고치지는 않겠습니다 — 필요하시면 문구를 드리겠습니다.

정리

• 이 이슈에서 백엔드가 결정 없이 지금 할 수 있는 것은 configuration.md 인프라 요청 표에 PINLOG_AI_INTERNAL_SECRET 추가 한 건입니다
• application-prod.yml의 pinlog.ai.base-url은 위 3번 결정 뒤에 넣습니다
• 본문의 행 번호는 이제 어긋납니다 — application.yml:79·:82는 #98로 밀려 현재 dev에서 :114·:117입니다

[colosair]

AI 파트입니다. 두 가지를 확인하고, 결정이 저희 쪽에 걸려 있다는 것을 인정합니다.

2번 확인 — 맞습니다

PINLOG_AI_EMBEDDING_PROFILE 은 인프라 주입 대상이 아닙니다. AiSearchClient 의 fail-fast 는 ${PINLOG_AI_EMBEDDING_PROFILE:openai-text-embedding-3-small-1536-cosine-v1} 리터럴 기본값이 있어 변수를 정의하지 않으면 발동하지 않고, PINLOG_AI_EMBEDDING_PROFILE= 처럼 빈 값으로 정의한 경우만 막습니다. 요청 목록이 둘 그대로인 것이 맞습니다.

AiProcessClient.requireSecret 과 같은 기준을 쓰면서도 인프라 요구가 늘지 않는 것이 이 검사를 넣을 때의 조건이었습니다.

1번 — 검색이 오류 화면을 내는 것은 설계된 동작입니다

빈 결과로 삼키지 않는 것이 이 연동의 계약입니다(공용 계약 05 §7.1 런타임 대조, ai 레포 docs/spec/model-profile.md §3.1). 설정이 어긋난 채 배포된 사실이 "검색 결과 없음" 으로 보이는 쪽을 막으려고 일부러 그렇게 했습니다.

따라서 짚어 주신 대로 주소가 틀린 채 시연하면 그 자리에서 오류가 납니다. 고칠 결함이 아니라 "시연 전에 주소가 맞아야 한다" 는 제약으로 읽는 것이 맞습니다. 무음 실패보다 나아졌다는 진단도 같은 이유입니다.

결정이 저희 쪽에 걸려 있습니다

3번(시연 범위)이 서지 않아 4번 스위치와 application-prod.yml 주소가 모두 대기 중이라는 것을 인지했습니다. 저희가 병목입니다. 오늘 안에 답을 드리겠습니다.

JWT_PRIVATE_KEY 주입을 결정과 분리해 지금 진행할 수 있다는 3번 판단은 AI 파트 쪽에 걸리는 것이 없습니다.

5번 — 판단에 동의합니다

범위 규약으로 바꾸는 방향이 맞다고 봅니다. V100–V199 가 AI 소유이고 core.feed_event(V102) 재정의 금지가 실제 계약이라는 서술도 저희 인식과 같습니다.

인프라 소유 파일이라 저희도 문구를 제안하지 않겠습니다. 관측을 전달한 것까지가 저희 몫이라고 봅니다.

[colosair]

시연 범위가 확정됐습니다 — 전체 통합

3번 상위 미결이 풀렸습니다. 선택지 1(AI 를 prod 에도 배포) 로 갑니다.

대기 중이던 것들이 이렇게 갈립니다.

항목	판정
pinlog.ai.enabled 스위치 (4번)	불필요합니다. 전체 통합이라 AI 를 끄지 않습니다. 후속 티켓을 만들지 않으셔도 됩니다
application-prod.yml 의 pinlog.ai.base-url	필요합니다. 주소는 아래
configuration.md 인프라 요청 표에 PINLOG_AI_INTERNAL_SECRET	필요합니다. 결정과 무관하게 지금 가능하다고 하신 그 건입니다
JWT_PRIVATE_KEY 주입을 분리해 지금 진행	동의합니다. AI 파트에 걸리는 것 없습니다

주소

AI 서버는 내부 전용 ClusterIP · 포트 8000 입니다. 외부 진입점을 만들지 않는 것이 AI 설계의 경계입니다. 실제 FQDN 은 apps/prod/ai 등록 시 인프라가 확정합니다 — 저희가 네임스페이스·서비스 이름을 정하지 않습니다.

S15P11A705-61 [AI] AI 서버 배포 인프라 요청 이 그 요청서입니다. 본문 두 곳이 현행 계약과 어긋나 있어(SealedSecret 경로가 -154 로 표준화됨, Embedding Profile ConfigMap 단일 주입은 BD-39 로 폐기) 갱신한 뒤 인프라에 전달합니다.

prod 에서는 재스캔이 필수가 됩니다

전체 통합이면 #99(AI 연동 실패 경로 4곳이 전제하는 재스캔 부재)가 선택이 아니라 필수가 됩니다. AiProcessClient 가 실패를 삼키고 뒷수습을 재스캔에 맡기는 구조인데, 그것이 없으면 임베딩 누락이 영구 손실로 남습니다.

S15P11A705-97 [BE] dev AI DB migration·연동·stale recovery 계약 확정 이 그 본체로 보입니다. 실행 주체 판단이 필요하면 드리겠습니다 — AI 파트 쪽 선택지는 FastAPI 내부 루프이고, Spring @Scheduled 는 백엔드 소관입니다.

순서

지금        JWT_PRIVATE_KEY 주입 (프로파일 무관) · configuration.md 표 갱신
-61 갱신 후  apps/prod/ai 등록 → 주소 확정 → application-prod.yml 반영
그 뒤        PINLOG_AI_INTERNAL_SECRET 주입 → SPRING_PROFILES_ACTIVE=prod

본문 행 번호가 어긋난다고 알려 주신 것 확인했습니다(application.yml:79·:82 → 현재 :114·:117).

[colosair]

PINLOG_AI_INTERNAL_SECRET — 두 값은 같습니다

#105 본문에서 pinlog-secrets-prod 에 이 키가 이미 등록된 것을 확인했습니다. AI 파트가 직접 전달한 값이고 양쪽이 일치합니다.

ai   레포 · pinlog-secrets-dev  · INTERNAL_SHARED_SECRET
back 레포 · pinlog-secrets-prod · PINLOG_AI_INTERNAL_SECRET

이름이 다르고 레포·Environment 도 다르지만 같은 값입니다. ai 의 app/core/security.py 가 이 값을 X-Internal-Secret 헤더와 대조하는 쪽이고, 그 계약이 원본입니다.

값은 이 코멘트를 포함해 어디에도 기록하지 않습니다.

왜 이 사실을 남기는가

Secret 전달은 채팅·PR·Jira 에 남기지 않는 것이 규칙이라, "전달됐다"는 사실 자체도 기록되지 않아 나중에 아무도 알 수 없습니다. 실제로 저희 쪽에서 한 번 "두 값이 다를 수 있다"고 의심했고, 확인할 수단이 없어 재등록을 검토했습니다.

기록해 두면 둘이 해결됩니다.

• 같은 질문이 반복되지 않는다
• 운영에서 401 이 났을 때 시크릿 불일치를 원인 후보에서 뺄 수 있다 — AiProcessClient 가 실패를 삼키는 구조라(AI 연동 실패 경로 4곳이 전제하는 재스캔이 존재하지 않는다 — 실행 주체 결정 필요 #99·S15P11A705-159) 원인 후보를 하나 줄이는 것이 진단 비용을 크게 줄입니다

회전 시 주의

한쪽만 바꾸면 모든 AI 호출이 401 이 되고 그 실패가 삼켜집니다. 오류 응답 없이 임베딩만 생기지 않는 상태라 관측이 어렵습니다. 회전이 필요하면 AI 파트에 알려 주시면 양쪽을 동시에 맞추겠습니다.

[colosair]

미응답 질문을 이쪽으로 옮깁니다 — runtime Secret 키 집합

Team-PinLog/ai#39 에 남겼던 질문인데 그 PR 이 병합되면서 닫힌 곳에 묻혔습니다. 아직 답을 받지 못했고 이 이슈와 같은 주제(prod Secret 주입)라 옮겨 적습니다.

어긋나 있는 것

구두로 "앱 Secret 3키만 등록하라" 는 안내를 받고 그대로 했습니다.

등록 완료   ai 저장소 pinlog-secrets-dev
            GMS_API_KEY · GMS_BASE_URL · INTERNAL_SHARED_SECRET

그런데 문서·티켓·검증기 세 곳이 여전히 8키를 규정합니다.

위치	내용
S15P11A705-118 본문	"ai-runtime-secrets 는 다음 exact 8-key schema 만 허용한다" — 위 3키 + DATABASE_URL + PINLOG_EMBEDDING_MODEL·DIMENSION·DISTANCE·PROFILE
infra/docs/ai-dev-prerequisites.md 3절	"exact 8-key schema 가 아니면 실패한다" (owner 7키 + DB 1키)
infra/tools/validate_ai_dev_prerequisites.py	REQUIRED_RUNTIME_KEYS 7개 · missing 과 unexpected 를 모두 오류로 반환

EMBEDDING 넷은 S15P11A705-96·ai#36 에서 app/core/config.py 기본값으로 옮겨 주입 대상에서 뺐습니다(공용 계약 05 §7.1 개정). 정본이 코드로 이동해 환경변수는 실험·롤백용 덮어쓰기가 됐습니다.

왜 지금 묻는가

apps/dev/ai/values.yaml 이 "승인되지 않은 계약이 남아 있어 workload 는 의도적으로 차단한다" 로 enabled: false 입니다. 저희가 3키를 등록해도 검증기가 8키를 요구하면 gate 가 열리지 않습니다.

시연 범위가 전체 통합으로 확정돼 dev 기동이 prod 배포의 선행이 됐습니다(S15P11A705-61 3번 apps/prod/ai 등록).

질문

세 곳이 3키 기준으로 갱신될 예정인지만 알려주시면 됩니다. 갱신 방식이나 시점을 저희가 정하지 않습니다.

만약 8키가 유지되는 결정이라면 저희가 나머지 넷을 다시 등록해야 하므로, 그 경우에도 알려주시면 맞추겠습니다.

함께 관측한 것 (판단은 백엔드·인프라 소관)

S15P11A705-118 본문의 Flyway 순서가 V1 → V100 → V101 인데, infra/docs/ai-dev-prerequisites.md 2절은 여섯 파일(V1·V2·V3·V100·V101·V102)을 요구하고 현재 back dev 에는 여덟 개가 있습니다(V4·V5 추가). 세 곳이 서로 다릅니다.

#102 앞선 코멘트에서 백엔드가 "고정 파일 목록은 유지될 수 없는 조건" 이라며 범위 규약으로 바꾸는 방향을 답해 주셨습니다. 그 판단에 저희도 동의하며, 인프라 소유 파일이라 문구를 제안하지는 않겠습니다.