[INFRA] 운영에 AI가 배포되어 있지 않다 — apps/prod/ai 등록과 PINLOG_AI_BASE_URL 주입

[minyongP]

운영에 AI가 배포되어 있지 않고 back이 부를 주소도 없다. #102를 정리해 다시 끊는다 — 그 이슈는 PINLOG_AI_INTERNAL_SECRET과 묶여 있었는데 그쪽은 #105로 해소됐고, 남은 것은 주소 하나다.

시연 범위가 전체 통합으로 확정돼(#102) 선택 사항이 아니다.

지금 상태 — 확인한 것

확인 대상	상태
infra/apps/prod/	back 하나뿐. ai 없음
infra/apps/dev/ai/values.yaml	enabled: false — "승인되지 않은 계약이 남아 있어 workload는 의도적으로 차단한다"
back/src/main/resources/application.yml:114	base-url: ${PINLOG_AI_BASE_URL:http://localhost:8000}
infra/apps/prod/back/values.yaml env:	PINLOG_AI_BASE_URL 없음

즉 운영 파드는 AI 호출을 전부 자기 자신의 8000 포트로 보낸다. 거기에는 아무것도 없다.

왜 지금 중요한가 — 검색은 오류 화면이 뜬다

임베딩 경로와 검색 경로의 실패 방식이 다르다.

소비자	주소가 틀렸을 때	사용자에게
AiProcessClient (임베딩 접수)	삼킨다. PENDING → 5분 주기 3회 재시도 → FAILED	안 보인다. Context는 정상 생성
AiSearchClient (자연어 검색)	AiSearchException.unavailable()을 던진다	오류 응답

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

빈 결과로 삼키지 않는 것은 설계된 계약이다(공용 계약 05 §7.1 런타임 대조). 설정이 어긋난 채 배포된 사실이 "검색 결과 없음"으로 보이는 쪽을 막으려고 일부러 그렇게 했다. 따라서 시연에서 자연어 검색을 보여주면 그 자리에서 터진다.

임베딩 쪽은 #104(재스캔 Scheduler·FAILED Finalizer, 4a9ab36) 이후 배포 약 15분이면 context_ai_state에 FAILED가 쌓이기 시작한다. 그게 주소 오류의 가장 빠른 신호다.

해야 할 일

• S15P11A705-61 [AI] AI 서버 배포 인프라 요청 갱신 — AI 파트. 본문 두 곳이 현행 계약과 어긋나 있다(SealedSecret 경로 -154 표준화, Embedding Profile ConfigMap 단일 주입은 BD-39로 폐기)
• apps/prod/ai 등록 — 인프라. 내부 전용 ClusterIP · 포트 8000, 외부 진입점 없음. FQDN은 인프라가 확정한다
• apps/prod/back/values.yaml의 env:에 PINLOG_AI_BASE_URL 추가 — 인프라
• 배포 후 자연어 검색이 오류 없이 응답하는지, context_ai_state에 FAILED가 더 쌓이지 않는지 확인

back 저장소 변경은 필요 없다. application.yml:114의 placeholder가 이미 있어 주입만 하면 그대로 읽힌다.

함께 딸린 것 (차단은 아님)

back/docs/development/configuration.md의 인프라 요청 표가 낡았다. 문서 전용이라 아무 때나, 티켓 없이 고칠 수 있다.

• L80 "인프라 계약에 아직 반영되지 않았으므로 배포 전에 요청해야 합니다" — 07-30에 6종 전부 back-owner-secrets로 봉인·주입돼 사실이 아니다
• 표에 PINLOG_AI_INTERNAL_SECRET이 빠져 있다(운영 필수 — 없으면 운영 프로파일 기동 실패, AiProcessClient.java:65)
• PINLOG_AI_EMBEDDING_PROFILE은 요청 대상이 아니다. application.yml:122에 리터럴 기본값이 있다(BD-39)

아직 답을 못 받은 질문 — runtime Secret 키 집합

AI 파트가 ai#39에 남겼다가 그 PR 병합과 함께 묻혔고, #102로 옮겨 적었으나 여전히 미응답이다. #102를 닫으면서 또 묻히지 않도록 여기로 옮긴다.

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

그런데 세 곳이 여전히 exact 8-key schema를 규정한다.

위치	내용
S15P11A705-118 본문	"ai-runtime-secrets는 다음 exact 8-key schema만 허용한다"
infra/docs/ai-dev-prerequisites.md 3절	같은 문구
infra/tools/validate_ai_dev_prerequisites.py:17	REQUIRED_RUNTIME_KEYS 8개. missing뿐 아니라 unexpected도 오류

지금 상태로 검증기를 돌리면 DATABASE_URL·PINLOG_EMBEDDING_MODEL·DIMENSION·DISTANCE·PROFILE 다섯이 missing으로 걸린다. EMBEDDING 넷은 S15P11A705-96·ai#36에서 app/core/config.py 기본값으로 옮겨 주입 대상에서 빠졌다(공용 계약 05 §7.1 개정).

세 곳을 3키 기준으로 갱신할 예정인지만 알려주면 된다. 8키 유지 결정이면 AI 파트가 나머지를 등록하겠다고 했다. apps/dev/ai가 enabled: false인 상태라 이 판정이 dev AI 기동의 선행이고, 전체 통합 확정으로 dev 기동이 prod 배포의 선행이 됐다.

참고

• [INFRA] 운영에 PINLOG_AI_BASE_URL이 없다 — 실패가 조용히 삼켜진다 #102 — 이 이슈로 대체하며 닫는다
• [INFRA] 운영에 prod 프로파일이 꺼져 있다 — fail-fast 미작동, API 문서가 외부에 열려 있다 #101 — SPRING_PROFILES_ACTIVE=prod. 별건이며 이 이슈를 기다리지 않는다. 그쪽 차단 요소(JWT_PRIVATE_KEY·PINLOG_AI_INTERNAL_SECRET)는 #105로 전부 풀렸고, PINLOG_AI_BASE_URL은 기동을 막지 않는다
• chore: JWT_PRIVATE_KEY를 pinlog-secrets-prod에 등록하고 Secret 전달 workflow로 운영에 주입한다 #105 — 봉인 워크플로 실행. 완료
• feat(S15P11A705-159): 유실·정지된 AI 처리를 복구하는 재스캔 Scheduler와 FAILED Finalizer 추가 #104 — 재스캔 Scheduler·FAILED Finalizer

[colosair]

S15P11A705-61 본문을 현행 계약에 맞췄습니다. 지적하신 두 곳입니다.

고친 것

항목	이전	지금
Secret 전달	이 티켓이 SealedSecret 두 키를 직접 요청	-154 표준 경로(GitHub Environment Secret → GitOps). 키도 3개
Embedding Profile	ConfigMap 단일 지점 주입	폐기. BD-39 로 각 파트 코드 리터럴 + CI 대조

폐기 항목은 지우지 않고 취소선으로 남겼습니다 — 왜 사라졌는지 모르면 다시 요청하게 됩니다. static/05 §7.1 개정(2026-07-29)으로 Profile 정본이 배포 환경에서 각 파트 코드로 옮겨졌고, PINLOG_AI_EMBEDDING_PROFILE 은 실험·롤백용 덮어쓰기라 주입 대상이 아닙니다.

함께 반영한 것

• apps/prod/back 의 PINLOG_AI_BASE_URL 을 작업 범위 4번으로 추가했습니다. 원래 이 티켓에 없던 항목입니다
• 완료 조건에 자연어 검색 정상 응답과 context_ai_state 의 FAILED 미증가를 넣었습니다
• 레포 서술을 dev 2단 구조로 정정했습니다(통합 dev / 배포 main, 이미지 게시는 main push 에서만)

키 집합 질문의 현재 위치

-61 본문 2번에도 같은 내용을 적어 두었습니다. 이 이슈와 티켓 중 어느 쪽을 보셔도 같은 것을 보시게 됩니다.

등록 완료   ai 저장소 pinlog-secrets-dev — 3키
문서·검증기  infra/docs/ai-dev-prerequisites.md §3
           infra/tools/validate_ai_dev_prerequisites.py:17
           S15P11A705-118 본문

어느 쪽으로 정해지든 맞추겠습니다. 3키 기준 갱신이면 저희가 할 일이 없고, 8키 유지면 나머지를 등록하겠습니다.

[colosair]

키 집합 질문을 철회합니다 — 이미 답이 있었습니다

저희가 틀렸습니다. infra 실물을 확인했습니다.

secrets/dev/ai-owner-secrets.sealedsecret.yaml      2026-07-29 봉인 (#77)
  GMS_BASE_URL · GMS_API_KEY · INTERNAL_SHARED_SECRET
  PINLOG_EMBEDDING_MODEL · DIMENSION · DISTANCE · PROFILE      7키
secrets/dev/ai-db-credentials.sealedsecret.yaml
  DATABASE_URL                                                 1키

합계 8키이고 validate_ai_dev_prerequisites.py:17 의 REQUIRED_RUNTIME_KEYS 와 정확히 일치합니다. 지금 검증기를 돌려도 missing 은 나오지 않습니다.

저희가 "3키만 등록됐다"고 말한 것은 ai 저장소의 GitHub Environment Secret 3개를 본 것이었고, 그것이 GitOps 로 전달돼 infra 에서 8키로 봉인된 결과를 확인하지 않았습니다. 봉인은 저희가 처음 물어본 07-30 보다 하루 앞선 07-29 에 이미 끝나 있었습니다.

8키 vs 3키는 애초에 충돌이 아니었습니다. 결론은 (A) 8키 유지이고, 저희가 추가로 등록할 것은 없습니다.

dev gate 도 이미 열려 있습니다

apps/dev/ai/values.yaml
  application · deployment · bootstrap    enabled: true
  bootstrap.version                       preset-204824bd37e6
  probes                                  /health (startup·liveness) · /ready (readiness)

저희가 apps/dev/ai 가 enabled: false 라 dev 기동이 막혀 있다고 적었던 것도 현재 상태가 아닙니다.

남는 것

이 이슈의 실질 항목은 apps/prod/ai 등록과 apps/prod/back 의 PINLOG_AI_BASE_URL 둘이며, 그것은 그대로 유효합니다. 저희 쪽 선행 조건은 없습니다.

S15P11A705-61 본문의 해당 절도 위 내용으로 고치겠습니다. 확인 늦어 죄송합니다.

함께 짚어 둡니다 (차단 아님)

infra/docs/ai-serving.md 와 ai-dev-prerequisites.md 가 "현재 세 gate 모두 false" 라고 적고 있는데 values.yaml 은 셋 다 true 입니다. 저희가 위 오판을 한 경로 중 하나이기도 합니다. 인프라 소유 문서라 저희는 손대지 않았습니다.

[colosair]

AI 이미지를 새로 게시했습니다 — image.tag 갱신을 요청드립니다

ghcr.io/team-pinlog/ai:53ad550f…      (main HEAD, ai#60 릴리스)
현재 apps/dev/ai/values.yaml           d317f563… (ai#42, 07-29)

ai 레포의 main 이 dev 보다 16커밋 뒤처져 있었습니다. 저희가 「릴리스 시점」을 규약에 정해 두지 않아 생긴 일이고, 그 사이 병합된 것이 배포 경로에 한 번도 오르지 못했습니다. CONTRIBUTING.md 에 기준을 넣고 릴리스했습니다.

이번 이미지에 처음 들어가는 것

판정 LLM 벤더 폴백 (ai#51)	GMS Gemini 경로가 429 를 뱉으면 OpenAI → Anthropic 으로 넘어갑니다. 지금 떠 있는 이미지에는 없습니다
외부 API 재시도·오류 분류 (ai#44)	일시 오류와 영구 오류를 갈라 재시도합니다
GMS 토큰 계측 (ai#48)	PINLOG_TOKEN_LOG 가 있을 때만 동작하는 게이트 방식이라 운영 경로에 영향이 없습니다
시연 도구 preflight (ai#57)	데모 시딩 전 스키마·인증·DB 대조

#51 이 특히 큽니다. 2026-07-30 실측에서 Gemini 경로만 8% 실패했고 OpenAI·Anthropic 경로는 한 번도 막히지 않았습니다. 지금 이미지는 그 폴백이 없어 429 가 나면 그대로 실패합니다.

요청

apps/dev/ai/values.yaml 의 image.tag 를 53ad550f… 로 갱신 부탁드립니다. 전체 SHA 는 ai 레포 main HEAD 입니다.

apps/prod/ai 등록 시에도 같은 태그를 쓰시면 됩니다.

저희 쪽에서 확인한 것

ai-image / publish   success
main HEAD            53ad550
dev 에만 남은 커밋     0

게시까지가 저희 권한이고 반영은 확인하지 못했습니다 — 클러스터 접근이 없어 Pod 이 새 이미지로 떴는지는 그쪽에서만 보입니다.

[colosair]

ai → back 이 막혀 있는 것은 설계입니다 — 뚫지 않으셔도 됩니다

back → ai 단방향이 계약이고, 반대 방향은 애초에 만들지 않았습니다. 배포 구성 문제가 아닙니다.

근거 셋

1. FastAPI 에 back 을 호출하는 코드가 0건입니다

ai/app 전체에서 back 호스트·8080 포트·HTTP 클라이언트로 back 을 부르는 지점을 찾을 수 없습니다. 나가는 HTTP 는 GMS 게이트웨이 하나뿐입니다.

2. DB 권한으로도 막혀 있습니다

FastAPI 가 접근하는 스키마
  ai.context_ai_state · ai.context_embedding · ai.context_keyword
  ai.context_keyword_analysis · ai.keyword_preset

core.* 는 하나도 없습니다. 공용 계약 static/05-1 §2 가 "계약상 FastAPI(AI 워커)는 core.* 에 접근하지 않으며 DB 권한이…" 로 명시하고, static/05 §도 core.* 스키마 접근을 제외 목록에 두고 있습니다.

S15P11A705-61 이 요청드린 ai 전용 DB role 이 바로 이 경계를 문서상 원칙이 아니라 실제 권한으로 강제하려는 것입니다.

3. 결과는 호출이 아니라 DB 로 전달됩니다

back → ai   POST /internal/v1/context/process  (202 = 접수만)
            POST /internal/v1/search
ai  → DB    ai.* 에 임베딩·키워드·상태를 직접 쓴다
back → DB   ai.context_ai_state 를 읽어 상태를 안다

AI 는 back 에 아무것도 알리지 않습니다. back 이 상태 테이블을 읽거나 재스캔 스케줄러(back#104)가 주기적으로 확인합니다.

그래서 확인하실 것은 한 방향뿐입니다

필요    back Pod → ai Service (ClusterIP 8000) 도달
        ai Pod → PostgreSQL (ai 스키마 권한)
        ai Pod → GMS 게이트웨이 (외부)
불필요  ai Pod → back Pod

ai 는 ingress.enabled: false 인 내부 전용 서비스이므로 외부 진입점도 없어야 정상입니다.

참고 — 이 방향을 만들자는 논의가 지금 열려 있습니다

back#129 의 안 B(완료 이벤트 역방향 MQ) 가 정확히 "지금 없는 그 방향" 을 만들자는 제안입니다. 저희는 "발행 자체는 부담스럽지 않다" 고 답했고 시점만 뒤로 미루자고 했습니다.

즉 지금 막혀 있는 것이 맞고, 앞으로 열지 말지는 그 이슈에서 정해집니다. 배포 테스트 단계에서는 단방향으로 두시면 됩니다.

[colosair]

배포 환경에서 AI 기능이 동작하지 않습니다 — 현재 상태를 조회했습니다

infra 저장소 기준입니다.

apps/prod/            back 하나뿐 · ai 디렉터리가 없다
apps/dev/ai           image.tag = d317f563…  (ai#42 · 07-29)

운영에는 AI 가 배포되어 있지 않고, dev 이미지는 오늘 릴리스한 것이 아니라 07-29 시점입니다.

두 요청이 아직 반영되지 않았습니다

이 이슈에서 오늘 드린 것입니다.

apps/prod/ai 등록                       미반영
apps/prod/back 에 PINLOG_AI_BASE_URL     미반영
apps/dev/ai 의 image.tag → 53ad550f…     미반영

재촉이 아니라 상태 공유입니다. 진행 중이시면 그대로 두시고, 막힌 지점이 있으면 알려주시면 저희가 도울 수 있는 부분을 보겠습니다.

증상이 어떻게 나타나는지 (원인 구분용)

운영에 AI 가 없다              back 이 자기 localhost:8000 을 부른다
  → 자연어 검색                 그 자리에서 오류 응답 (AiSearchException.unavailable)
  → 임베딩·키워드                조용히 PENDING → 재시도 3회 → FAILED

임베딩 쪽은 사용자 화면에 안 보입니다. Context 는 정상 생성되고 키워드·검색만 안 됩니다.

로그보다 빠른 확인 방법

DB 한 줄이면 어느 단계에서 막혔는지 갈립니다.

SELECT keyword_status, embedding_status, COUNT(*)
FROM ai.context_ai_state GROUP BY 1,2;

FAILED 가 쌓인다      요청은 갔는데 AI 가 응답하지 않는다 → 주소·배포 문제
PENDING 만 있다       요청 자체가 안 간다 → back 설정 문제
COMPLETED 가 있다     AI 는 도는데 다른 곳이 막혔다

back#104 재스캔이 5분 주기 × 3회이므로 배포 후 약 15분이면 판별됩니다.

Grafana 로그는 아직 도움이 안 됩니다

오늘 병합한 관측 계측(ai#64)이 로그에 이 이름들을 남깁니다.

app.client.gms      GMS 호출 성공/실패/지연 · 60초 창 집계
app.service.stage   재선점(stale PROCESSING 회수)

그런데 이 코드는 53ad550f… 이미지에만 있습니다. dev 가 d317f56 인 한 로그를 아무리 뒤져도 나오지 않습니다.

즉 관측을 쓰려면 image.tag 갱신이 선행입니다.

우선순위 제안 (판단은 인프라에 맡깁니다)

1  apps/dev/ai 의 image.tag 갱신     가장 싸고 즉시 효과 · 관측이 살아난다
2  apps/prod/ai 등록                 운영 배포
3  apps/prod/back 에 BASE_URL 주입    2 가 끝나야 주소가 정해진다

1 만 먼저 하셔도 dev 에서 무엇이 실패하는지 보이기 시작합니다. 전체 SHA 는 ai 저장소 main HEAD 입니다.

[colosair]

앞선 코멘트의 서술을 정정합니다 — dev 는 배포돼 있습니다

ai#69(인프라가 방금 올린 버그 리포트)에서 확인됐습니다.

Namespace/Deployment   pinlog-dev/ai
Deployment             desired 1 / ready 1 / available 1
Pod                    Running · Ready · restart 0
Argo CD ai-dev         Synced / Healthy
/health · /ready       200

제가 "운영에 AI 가 배포되어 있지 않다" 고 쓴 것은 prod 에 대한 사실이었는데, dev 까지 미배포로 읽힐 수 있게 썼습니다. dev 는 정상 기동 중입니다.

Grafana 로그 조회 방법을 안내드린 것도 불필요했습니다 — 이미 로그를 뽑아 이슈까지 내신 뒤였습니다.

남은 요청은 셋 그대로입니다

apps/dev/ai 의 image.tag → 53ad550f…      ← 우선순위가 올라갔습니다
apps/prod/ai 등록
apps/prod/back 에 PINLOG_AI_BASE_URL

image.tag 갱신이 ai#69 의 수정일 가능성이 큽니다

배포된 d317f563…(07-29) 시점 코드를 확인했더니 오류 분류와 재시도가 아예 없었습니다.

app/core/errors.py 의 classify_http_status   없음
app/client/retry.py                          파일 자체가 없음

ai#44(S15P11A705-121)가 그것을 넣었고 502 를 TransientError 로 분류해 재시도합니다. 갱신만으로 500 전파가 해소될 수 있습니다.

상세는 ai#69 에 답해 두었습니다. 별도 코드 티켓은 세우지 않고 갱신 후 재확인하기로 했습니다.

[colosair]

새 이미지를 게시했습니다 — 갱신에 쓸 값입니다

Team-PinLog/ai#77 을 main 에 병합해 방금 게시가 끝났습니다.

tag      4d667c3ee5635c9fee703a66a3dbfb0b056621b0
digest   sha256:3fbe59d342b5649a9b94156d180fa80841b78254393389ef73749b0d0e7f0048

infra/apps/dev/ai/values.yaml 의 현재 값은 tag: d317f563... 이고 07-30 11:15 시점입니다. 그 뒤 27커밋이 미배포 상태였습니다.

게시와 반영은 다른 일이라 여기까지가 AI 파트 권한입니다.

무엇이 처음 들어가는지

티켓	내용
-121	GMS 호출 재시도 3회·지수 백오프 — 현재 배포분에는 재시도가 아예 없습니다
-175	벤더 폴백 체인
-197	GMS 호출 계측 — gms call kind=... status=... outcome=... 로그
-220	오류 핸들러 — TransientError→503 · PermanentError→502
-221	DB 실패 분류 — 연결 실패·풀 고갈이 503 으로
-213	검색 유사도 컷 · limit 을 계약값 20 으로
-223	판정 다수결 경로 — 기본 n=1 이라 동작은 그대로

관측이 달라집니다

지금    모든 실패가 500 · 로그에 GMS 호출 흔적이 없다
갱신 후  게이트웨이 문제는 503 · 설정 문제는 502 · 호출마다 계측 로그

DB 장애로 나던 500 이 503 으로 이동합니다. Grafana 대시보드가 500 을 기준으로 삼고 있다면 의미가 바뀝니다.

ai#69 에 적었듯 사용자 화면은 달라지지 않습니다 — AiSearchClient 가 500 도 이미 503 SEARCH_UNAVAILABLE 로 묶고 있어서입니다. 달라지는 것은 원인을 가릴 수 있게 되는 것입니다.

제가 확인한 구성 — 문제는 구성이 아닙니다

ai#69(운영 AI 미동작) 원인을 찾으며 infra 를 읽었습니다. 사실만 적습니다.

apps/prod/ai                없습니다 (이 이슈의 주제)
prod back 의 AI 주소          http://ai.pinlog-dev.svc.cluster.local:8000
NetworkPolicy               allow-prod-back-to-ai · allow-approved-dev-ai-to-postgres 둘 다 있습니다
apps/dev/ai 활성화           application·deployment·bootstrap 전부 enabled: true

prod back 이 dev AI 를 부르는 경로는 정책상 열려 있습니다. 그래서 「구성이 막혀서」는 아닌 것으로 보이고, 남은 후보는 런타임 쪽입니다.

갱신 후 확인하면 좋을 것

이미지가 반영되어도 안 되면 다음 셋이 남습니다. 판단은 인프라 쪽에 맡깁니다.

1  preset bootstrap Job 성공 여부   실패했으면 프리셋 0건이라 키워드가 절대 안 나옵니다
                                  SELECT count(*) FROM ai.keyword_preset;
2  /ready 응답                     /health 만 통과하고 /ready 가 실패하면 의존성 문제입니다
3  GMS 자격 증명                    지속적 실패라면 여기입니다. 갱신 후 계측 로그로 갈립니다

-197 계측이 들어가면 Loki 에서 바로 보입니다.

{namespace="pinlog-dev", app="ai"} |= "gms call"

별건으로 하나 알립니다

ai#69 에 적었지만 여기도 관련이 있어 옮깁니다 — 갱신 전 이미지는 트레이스백에 게이트웨이 응답이 실립니다. 오류 본문에 자격 증명이 들어오면 그대로 로그에 남습니다.

이번 릴리스의 오류 핸들러가 API 응답으로는 막지만 로그 경로는 별도 작업 중(Team-PinLog/ai#78)입니다.

운영 로그에 이미 남아 있을 수 있어 알려 드립니다. Loki 에 sk- 로 검색해 보시고, 나온다면 키 재발급이 필요할 수 있습니다.

[colosair]

정정 — 자격 증명 누출은 실측상 없습니다

앞서 "Loki 에 sk- 로 검색해 보시고, 나온다면 키 재발급이 필요할 수 있습니다" 라고 알렸습니다. 그 근거가 부정확했습니다.

제가 본 api key sk-**** rejected by ... 는 로컬 스텁이 만든 가짜 응답이었습니다. 실제 GMS 가 그렇게 답하는지는 확인하지 않은 채 알렸습니다.

실제 GMS 로 네 경로에 오류 19건을 만들어 재봤습니다.

자격 증명   네 경로(OpenAI·Gemini·Anthropic·임베딩) 모두 에코하지 않습니다
           401 은 게이트웨이 고정 문구입니다
           벤더에 닿기 전에 GMS 가 끊으므로 벤더별 차이가 생길 자리가 없습니다

키 재발급 검토는 불필요합니다. 번거롭게 해 드렸다면 죄송합니다.

다만 문제가 없어진 것은 아닙니다

endpoint   네 경로 모두 샙니다 — URL 은 아니고 맨 호스트
           예: "Model not found in request for domain api.openai.com"
요청 값     잘려서 되돌아옵니다 — OpenAI 가 앞뒤 3자만 남기고 에코합니다

후자가 실측의 핵심이었습니다. 완전 일치로 검사하면 「에코 없음」으로 판정되어 하마터면 "요청 값은 안 샌다" 로 결론 낼 뻔했습니다.

Team-PinLog/ai#78 로 마스킹을 클라이언트 원천에 넣었습니다. 새는 경로가 트레이스백 하나가 아니라 여섯이었고 그중 다섯이 평상시 정상 경로(재시도 로그·서비스 로그)였습니다.

이 변경은 다음 릴리스 대상입니다. 방금 게시한 4d667c3ee563... 에는 들어 있지 않습니다.