[확인 요청] 이미지 장소 제안 기능의 기존 AI lifespan 통합 방식 검토

[ghkim1632]

요청 배경

대화 캡처 이미지 1장에서 장소명 후보, 근거, 맥락 후보를 추출하고 카카오 로컬 API로 실제 장소 후보를 검색하는 기능을 추가하려고 합니다.

전체 호출 흐름은 다음과 같습니다.

Front
  -> Spring POST /api/core/v1/places/suggestions
  -> FastAPI POST /internal/v1/place-suggestions
  -> GMS 비전 분석
  -> 카카오 로컬 장소 검색
  -> FastAPI가 raw 결과를 Spring에 반환
  -> Spring이 공통 응답 형식으로 Front에 반환

FastAPI는 외부에 공개하지 않고 기존과 동일하게 Spring만 호출합니다. 기존 X-Internal-Secret 인증과 ingress.enabled: false도 유지합니다.

이번 확인 요청은 Front UX나 Spring 공개 API가 아니라, 기존 맥락 임베딩 및 키워드 추출을 수행하는 AI 서버에 이미지 장소 제안 모듈을 함께 조립해도 되는지를 확인하기 위한 것입니다.

제안하는 통합 방식

image2text의 독립 FastAPI 앱 전체를 합치지 않고 다음 모듈만 기존 ai 애플리케이션으로 옮깁니다.

• 이미지 형식·크기·픽셀 검증
• GMS 비전 모델 클라이언트
• 카카오 로컬 API 클라이언트
• 장소 제안 서비스 및 스키마
• /internal/v1/place-suggestions 라우터

서비스와 외부 HTTP 클라이언트는 기존 ai/app/main.py의 lifespan에서 조립하고 app.state.place_suggestion_service로 제공합니다.

확인 과정에서 발견한 사항

1. lifespan 자원 정리 범위

현재 AI lifespan은 DB 연결과 Preset 적재가 끝난 뒤에 try/finally가 시작됩니다. 따라서 Preset 0건 등으로 yield 전에 기동이 중단되면 DB 정리가 실행되지 않을 가능성이 있습니다.

여기에 비전·카카오용 httpx.AsyncClient를 단순 추가하면 기동 실패 시 HTTP 연결 자원도 정리되지 않을 수 있습니다.

다음과 같이 AsyncExitStack 또는 동등한 구조로 DB와 HTTP 클라이언트를 생성 직후부터 관리하는 방식을 제안합니다.

lifespan 시작
  -> DB 연결 및 종료 callback 등록
  -> 장소 제안 전용 AsyncClient 생성 및 종료 등록
  -> 기존 EmbeddingClient·LLMClient 생성
  -> Preset 적재
  -> 기존 서비스 + 장소 제안 서비스 조립
  -> yield
  -> 역순으로 HTTP 클라이언트 및 DB 종료

2. 장소 제안 전용 HTTP 클라이언트

비전 GMS와 카카오 호출에는 lifespan에서 생성한 장소 제안 전용 httpx.AsyncClient 하나를 공유하려고 합니다.

• 모듈 전역 클라이언트는 사용하지 않습니다.
• 기존 임베딩·키워드 판정 클라이언트의 연결 풀과 분리합니다.
• 카카오 후보 최대 3건을 병렬 검색할 수 있도록 연결 수를 설정합니다.
• GMS와 카카오의 제한 시간은 각 호출에 별도로 적용합니다.
• 클라이언트 생성 시에는 외부 요청을 보내지 않습니다.

3. 이미지 작업의 동시성 및 CPU 작업 분리

기존 /search, /context/process가 이미지 처리 때문에 지연되지 않도록 다음 기준을 적용하려고 합니다.

• 비전 장소 제안은 AI 인스턴스당 동시에 1건만 실행합니다.
• 두 번째 요청은 오래 대기시키지 않고 즉시 503으로 반환합니다.
• Pillow 기반 이미지 검증·리사이즈·압축은 asyncio.to_thread()로 이벤트 루프 밖에서 실행합니다.
• GMS 비전 호출에는 기존 키워드 판정의 3회 재시도 정책을 상속하지 않습니다.
• 카카오 후보 검색만 후보별로 병렬 실행합니다.

현재 운영 구성이 Uvicorn 1 worker, replica 1이면 서버 전체 1건 제한이 됩니다. worker 또는 replica가 늘어나면 제한도 인스턴스 수만큼 늘어납니다.

4. 기존 설정과 신규 설정

GMS에는 기존 설정을 재사용합니다.

GMS_API_KEY
GMS_BASE_URL

신규 설정 후보는 다음과 같습니다.

KAKAO_REST_API_KEY
PINLOG_IMAGE_MODEL
IMAGE_MODEL_TIMEOUT_SEC
KAKAO_TIMEOUT_SEC
VISION_MAX_CONCURRENCY
IMAGE_MAX_BYTES

KAKAO_REST_API_KEY를 필수 설정으로 추가하면 모듈 import 과정의 create_app()에서 바로 검증될 수 있습니다. 따라서 Infra runtime Secret, strict key 검증기, 테스트 환경변수를 AI 코드와 같은 배포 단위로 반영해야 합니다.

추가 런타임 의존성은 다음과 같습니다.

Pillow
python-multipart

5. 기존 오류 체계 사용

새로운 독립 오류 envelope을 만들지 않고 기존 AI 오류 분류를 사용하려고 합니다.

GMS 429·5xx·timeout  -> TransientError -> FastAPI 503
GMS 3xx·4xx          -> PermanentError -> FastAPI 502
예상하지 못한 결함  -> 500 유지
카카오 후보 일부 실패 -> 전체 실패가 아닌 200 + warning
비전 동시성 초과     -> 503

GMS 및 카카오 응답 본문, 이미지 base64, 추출 근거와 맥락은 로그에 남기지 않습니다. 기존 GMS 계측에는 kind=vision을 추가하는 방향을 생각하고 있습니다.

6. 내부 응답 계약

FastAPI는 Spring 공통 envelope을 만들지 않고 다음 raw 데이터만 반환합니다.

{
  "requestId": "req_...",
  "candidates": [],
  "warnings": []
}

최종 success/data envelope은 Spring의 ApiResponseBodyAdvice가 한 번만 생성합니다.

AI 담당자 확인 요청

다음 사항을 확인 부탁드립니다.

1. 기존 lifespan을 AsyncExitStack 기반으로 정리하고 장소 제안 전용 AsyncClient를 추가해도 기존 DB·Preset·임베딩·키워드 초기화 계약과 충돌하지 않는지
2. 장소 제안 전용 HTTP 연결 풀을 기존 EmbeddingClient, LLMClient와 분리하는 방향이 적절한지
3. 비전 작업을 인스턴스당 1건으로 제한하고 Pillow 작업을 asyncio.to_thread()로 분리하면 기존 /search, /context/process 보호에 충분한지
4. GMS 비전 호출이 기존 키워드 판정 재시도 정책을 상속하지 않고 1회 호출 후 오류를 반환하는 방향이 적절한지
5. 기존 TransientError·PermanentError 및 GMS call meter에 kind=vision을 추가하는 방식이 기존 오류·계측 계약과 맞는지
6. 같은 GMS_API_KEY를 사용하되 HTTP 클라이언트만 분리하는 경우 기존 임베딩·키워드 판정 쿼터나 처리 흐름에 추가로 보호해야 할 부분이 있는지
7. KAKAO_REST_API_KEY를 필수 설정으로 추가할 때 AI 코드, 테스트, Infra Secret을 어떤 순서 또는 같은 배포 단위로 반영해야 하는지
8. lifespan 기동 실패 상황에서 DB와 HTTP 클라이언트가 모두 정리되는 테스트를 추가하는 것으로 충분한지

제안하는 테스트 항목

• 정상 기동 시 place_suggestion_service가 app.state에 조립되는지
• 종료 시 장소 제안용 AsyncClient와 DB가 모두 닫히는지
• Preset 적재 실패 등 yield 이전 오류에서도 두 자원이 모두 닫히는지
• lifespan 기동만으로 GMS·카카오 외부 요청이 발생하지 않는지
• 비전 요청 1건 실행 중 두 번째 요청이 즉시 503을 받는지
• 이미지 압축 중에도 /search 또는 이벤트 루프의 가벼운 작업이 진행되는지
• GMS 429·5xx·4xx·timeout이 기존 오류 체계에 맞게 분류되는지
• 카카오 일부 실패가 성공한 후보까지 제거하지 않고 200 + warning으로 반환되는지
• 로그에 이미지, base64, GMS·카카오 응답 본문, 추출 근거·맥락이 남지 않는지

결정 요청

위 통합 방식에 문제가 없다면 해당 기준으로 AI 내부 API를 기존 ai 애플리케이션에 병합하려고 합니다. 기존 맥락 임베딩·키워드 추출 경로와 충돌하거나 먼저 수정해야 할 항목이 있다면 의견 부탁드립니다.

[colosair]

AI 파트입니다. AI 소관만 답하고, 확인 과정에서 나온 타 파트 사안은 마지막에 지목만 하겠습니다.

1. lifespan 자원 정리 — 지적이 맞습니다

확인한 것 (ai/app/main.py, origin/dev 2026-08-03 기준)

try:  는 89행에서 시작한다
그 앞   db.connect()(43) · Preset 적재(58-60) · loaded == 0 이면 RuntimeError(62)
결과    Preset 0건으로 기동이 중단되면 asyncpg 풀(min 1 / max 10)이 해제되지 않는다

raise 가 try 밖이라 finally 의 db.disconnect() 가 실행되지 않습니다.

지금은 영향이 좁습니다 — 제안이 그 전제를 바꿉니다

EmbeddingClient · LLMClient   httpx.AsyncClient 를 요청마다 async with 로 만들고 닫는다
                             lifespan 이 들고 있는 장기 연결이 아니다

지금 새는 것은 DB 풀 하나이고 기동 실패 시 프로세스가 곧 죽어 실무 손해가 작습니다. 비전·카카오용 AsyncClient 를 lifespan 이 소유하면 이 앱에 처음으로 장기 HTTP 연결이 생기고, 그때 실질 누수가 됩니다.

AsyncExitStack 도입에 동의하며 저희가 별도 티켓으로 먼저 진행하겠습니다.

1  lifespan 을 AsyncExitStack 으로 고친다    기존 동작 그대로. 새 기능과 무관하게 옳다
2  그 위에 장소 제안 모듈을 올린다

두 변경을 한 PR 에 담으면 「자원 정리가 깨졌는지」와 「새 모듈이 문제인지」를 못 가릅니다.

2. 모듈 통합 — 방향에 동의하되 코드를 봐야 확정할 수 있습니다

독립 앱 전체가 아니라 모듈만 옮기는 방향에 동의합니다. 파드·인증·홉이 늘지 않는 것이 근거이고, ingress.enabled: false 와 X-Internal-Secret 유지도 그대로 좋습니다.

다만 image2text 코드를 찾지 못했습니다.

훑은 곳   Team-PinLog 조직 12개 레포 · 코드 검색 · 이슈/PR 검색
         5개 레포의 origin/dev · origin/main 트리 · 전체 히스토리(git log -S)

어디에 있는지 알려 주시면 통합 범위를 판단해 드리겠습니다 — 전역 상태 결합도 · lifespan 의존 · httpx 세션 관리 · 테스트 유무를 봐야 「모듈만 떼어낼 수 있는가」에 답할 수 있습니다.

3. GMS 비전 — 지원은 확인됐고, 실사용 조건을 재고 있습니다

확인됨    GMS 가 이미지를 읽는다 (S15P11A705-227, ai#81)
         세 벤더 경로 전부 200 · 이미지 내용에 실제로 답변
미확인    실사용 크기(수백 KB~수 MB)에서의 토큰 · 지연 · 한도

S15P11A705-253 으로 측정을 시작했습니다. 출발점은 이것입니다 — 68바이트 동일 이미지에 OpenAI prompt_tokens=8,524 / Anthropic input_tokens=40. 그 차이가 설명되지 않아 비용 예측이 안 섭니다.

이 기능은 이미지가 크므로 그 수치가 곧 비용입니다. IMAGE_MAX_BYTES 와 「리사이즈·압축을 앞단에 둘 것인가」가 결과에 달려 있습니다.

쿼터는 상수가 아닙니다 — T27 실측: 07-29 분당 2건 → 07-30 분당 30건 이상. 시점·프로바이더 경로별로 다릅니다. 한도를 설계 상수로 박지 말고 실패 경로(429 백오프·폴백)를 먼저 두는 편이 안전합니다.

지연도 함께 재고 있어, 결과가 나오면 「동기로 끝낼 수 있는가」의 재료가 됩니다.

4. AI 쪽 제약 둘 — 설계에 반영해 주십시오

① 저희 타임아웃 상한

ai → GMS embedding   60.0s × 최대 3시도
ai → GMS LLM         90.0s × 최대 3시도
retry.py:14-17       "두 호출의 타임아웃 합 + 재시도 시간 < PROCESSING 만료 600s"

장소 제안 경로의 타임아웃도 이 계약 안에 들어와야 합니다. 값이 정해지면 그에 맞춰 클라이언트를 구성하겠습니다.

② 비동기가 되면 상태 관리가 따라오고, 지금 회수 경로가 없습니다

동기 요청·응답으로 끝나면 상태 테이블이 필요 없고 그것이 이 설계의 장점입니다.

비동기가 되면 ai.context_ai_state 와 같은 구조가 생기는데, FAILED 를 되살리는 코드가 back·ai·infra 어디에도 없습니다. 공용 계약 05_AI_설계.md §7.3 이 "Spring 이 대상 State 를 PENDING 으로 되돌려 재처리 큐에 넣습니다" 를 규정하는데 그 구현이 없고, FAILED → PENDING 은 어느 문서에도 없습니다.

비동기로 가신다면 회수 경로를 설계 단계에서 함께 정하시길 제안드립니다. 나중에 붙이는 것보다 쌉니다.

---

5. 확인 과정에서 나온 타 파트 사안 — 지목만 하겠습니다

저희가 판단할 것이 아니라 사실만 전달드립니다.

카카오 로컬 — 서버 호출은 이미 기각된 설계입니다 (@minyongP @TrossYou)

front   dapi.kakao.com/v2/local/... 을 브라우저에서 직접 호출. 키는 VITE_ 변수로 번들에
back    로컬 API 호출 없음. 로그인만

back/docs/backend/decisions/BD-19-place-snapshot.md 가 프론트 직접 호출을 채택하며 서버 호출안을 기각했고, front/docs/troubleshooting/2026-07-27-kakao-search-direct-call.md 의 재발 방지 항목이 "서버에 두려는 코드·설계가 보이면 이 결정과 충돌하므로 확인한다" 로 적혀 있습니다.

이번 제안이 그 경우에 해당합니다. 되짚을지 예외로 둘지 판단 부탁드립니다.

참고로 카카오 공식 문서는 쿼터를 앱 단위로 합산한다고 명시합니다. 프론트 키와 백엔드 로그인 키가 같은 앱인지는 콘솔을 봐야 알 수 있어 확인하지 못했습니다.

back → ai 타임아웃 (@minyongP)

process   connect 1s / read 3s     application.yml:134-135
search    connect 1s / read 5s     application.yml:140-141

이미지 분석 경로가 이 값으로는 들어가기 어려워 보입니다. 저희 측정이 끝나면 실제 지연을 드리겠습니다.

응답 경로 (@minyongP @cherry-go-round)

이슈 본문은 POST /api/core/v1/places/suggestions 인데 다른 곳에서 /api/core/v1/ai/place-suggestions 로도 보입니다. 공용 계약이라 어느 쪽이 정본인지 정해 주십시오.

---

진행

AI 가 지금 하는 것   lifespan 리팩터링 (별도 티켓) · GMS 비전 실사용 조건 측정
AI 가 기다리는 것    image2text 코드 위치 · 타임아웃 결정 · 카카오 호출 방식 결정

측정이 끝나면 토큰·지연 수치를 이 이슈에 올리겠습니다.

[colosair]

AI 파트입니다. 지난 코멘트에서 "측정이 끝나면 토큰·지연 수치를 이 이슈에 올리겠습니다" 라고 드린 약속의 후속입니다. S15P11A705-253 측정이 끝났습니다.

먼저 순서를 바꿔 말씀드립니다. 토큰보다 급한 결과가 나왔습니다 — 게이트웨이 요청 본문 상한이 약 100 KB 대에 있고, 실사용 대화 캡처는 토큰을 쓰기 전에 여기서 400 으로 되돌아옵니다. 이 이슈의 전제가 바뀝니다(§3).

리포트: docs/implements/2026-08-03-gms-image-probe.md (PR ai#101)
원본 회차 기록: .gms_image/axis-b.jsonl — 아래 수치는 전부 여기서 나옵니다.

측정 조건

시각      2026-08-03 17:07 ~ 17:26 KST
경로      https://gms.ssafy.io/gmsapi (root)
호출      50회 (생성 20 · 분석 30) · 429 0건
이미지    합성 PNG — 치수와 바이트를 따로 움직이도록 만든 것. 실사용 캡처가 아니다
프롬프트  "이 이미지에 무엇이 보이는가? 한 단어로 답하라" · 출력 상한 16 토큰

1. 토큰 — 같은 이미지에 벤더 간 94배

이미지 1장 · detail 미지정 · 200 응답만 추린 입력 토큰입니다.

벤더 · 모델	1×1 (69 B)	512×512 (2,004 B)	1024×1024 (5,590 B)
openai · gpt-4o-mini	8,523	8,523	25,524
anthropic · claude-haiku-4-5	39	399	1,407
gemini · 2.5-flash-lite	272	272	272

같은 1024×1024 한 장에 25,524 / 1,407 / 272 입니다. gpt-4o-mini 기준으로 Anthropic 이 18배, Gemini 가 94배 쌉니다. 이 기능에서 비용을 움직이는 손잡이는 사실상 모델 선택 하나입니다.

토큰의 결정 변수 — 바이트가 아니라 치수

512×512 을 고정하고 바이트만 36배(2,004 B → 71,776 B) 늘려도 gpt-4o-mini 의 입력 토큰은 8,523 으로 1도 움직이지 않았습니다. 반대로 치수를 키우면 움직입니다(8,523 → 25,524).

-227 이 남긴 8,524 는 게이트웨이가 얹은 값이 아니라 gpt-4o-mini 의 타일 요금 그 자체입니다. 7개 조건 전부 잔차 0 입니다.

prompt_tokens = 텍스트(23) + 2,833 + 5,667 × 타일수
                1타일 →  8,523          4타일 → 25,524

1024×1024 와 2048×2048 이 같은 25,524 인 것이 공식의 축소 단계를 그대로 보여 줍니다.

→ 비용 예측에 게이트웨이를 변수로 넣으실 필요가 없습니다. 벤더 공식으로 섭니다. 그리고 이 성질이 §3 의 우회 가능성으로 이어집니다.

2. 지연 — 얇은 표본

200 응답의 왕복 시간입니다. 지난 코멘트에서 드리기로 한 값입니다.

벤더 · 모델	n	최소	중앙	최대
openai · gpt-4o-mini	10	985 ms	1,445 ms	2,890 ms
anthropic · claude-haiku-4-5	3	1,063 ms	1,172 ms	1,984 ms
gemini · 2.5-flash-lite	3	1,594 ms	1,906 ms	1,907 ms

이 표를 그대로 실사용 예측에 쓰시면 안 됩니다. 한계를 셋 적습니다.

출력이 한 단어    completion_tokens 2~3 이다. 장소명·근거·맥락을 구조화해 받으면 출력이
                  커지고 지연은 대체로 출력 토큰에 붙는다 → 이 표는 하한이다
이미지가 작다     200 을 받은 이미지가 전부 71,776 B 이하다. 그보다 큰 것은 §3 에 막혔다
n 이 작다         p95 를 낼 수 없다. 최소·중앙·최대만 적었다

back#138 최종 결정에서 Spring → FastAPI read timeout 이 35초로 확정됐습니다. 위 왕복이 1초 안팎이니 그 예산은 넉넉합니다 — 지난 코멘트에서 이 경로의 타임아웃을 짚었던 걱정은 해소됐습니다.

다만 위 수치는 70 KB 이하 이미지에서 잰 것입니다. 5 MiB 를 상한으로 받으면 §3 의 본문 상한을 통과시키기 위해 보내기 전 축소·재압축이 들어가고, 그 시간이 위 왕복에 더 붙습니다. 출력을 구조화해 받는 몫(위 한계 첫 줄)도 마찬가지입니다. 35초 안에 들어갈 여지는 커 보이지만 위 표가 그것을 증명하지는 않습니다.

3. 게이트웨이 요청 본문 상한 — 이 기능의 전제 변경

이것이 이 측정에서 가장 급한 결과입니다. 실사용 크기(787 KB) 조건이 세 경로 전부 400 이었습니다. 이분 탐색으로 좁힌 결과입니다.

	요청 본문	이미지 원본	base64	결과
통과 최대	96,024 B	71,776 B (~70 KB)	95,704 B	200
거부 최소	129,564 B	96,931 B (~95 KB)	129,244 B	400

상한은 96,024 B 와 129,564 B 사이입니다. 구간에 드는 흔한 값이 100,000 · 102,400(100 KiB) · 128,000 셋이라 실측만으로는 못 가릅니다 — 분석 축 30회를 소진해 더 좁히지 못했습니다.

base64 가 4/3 로 부풀므로 이미지 자체의 상한은 본문 상한보다 훨씬 낮습니다. 확인된 값은 이미지 원본 기준 약 70 KB 통과 · 약 95 KB 거부 입니다.

이 이슈에 걸리는 지점

대화 캡처 스크린샷은 보통 200 KB ~ 2 MB 입니다. 현재 GMS 를 통해서는 원본 그대로 보낼 수 없습니다 — 토큰 비용을 걱정하기 전에 요청이 400 으로 되돌아옵니다.

back#138 이 같은 날 「최종 결정」과 함께 닫히면서 초기 이미지 상한이 5 MiB 로 확정됐습니다. 그 확정값과 저희 실측이 어긋납니다.

확정 계약값     5 MiB = 5,242,880 B
실측 통과 상한   71,776 B (이미지 원본 · 약 70 KB)
배율            약 73배

IMAGE_MAX_BYTES 를 확정값 그대로 5 MiB 로 두면 Spring·FastAPI 양쪽 검증은 통과하고 GMS 에서 400 으로 막힙니다. 위 수치는 그 결정 코멘트에 반영돼 있지 않습니다 — 측정이 끝난 것이 결정 직전입니다.

다행한 쪽 — 다만 미검증

§1 이 보인 성질이 여기서 도움이 됩니다. 토큰은 치수에만 붙습니다. 그러므로 치수를 유지한 채 품질(압축률)만 낮춰 바이트를 줄이면, 이론상 인식 품질과 토큰 비용을 그대로 둔 채 상한을 통과할 수 있습니다.

검증됨    같은 512×512 에서 바이트 36배 차이에 입력 토큰 불변
          (2,004 B · 71,776 B 둘 다 8,523)
미검증    품질을 낮춘 JPEG 이 실제로 상한을 통과하는지
          그 화질에서 대화 캡처의 글자가 읽히는지

「가능성」이지 「측정된 사실」이 아닙니다. 검증에는 JPEG 인코더가 필요하고(이슈가 이미 의존성으로 올리신 Pillow), 호출 몇 회면 됩니다. 확정 계약이 받는 형식이 PNG 또는 JPEG 1장이므로 JPEG 재압축은 계약상 막혀 있지 않습니다.

4. 크기 거부의 모델 오류 위장

상한을 넘긴 요청이 돌아오는 얼굴입니다.

openai      400  [GMS 에러] Model not found in request for domain api.openai.com
anthropic   400  [GMS 에러] Model not found in request for domain api.anthropic.com
gemini      400  [Gemini 에러] ... "GenerateContentRequest.contents: contents is not specified"

게이트웨이는 URL 경로가 아니라 요청 본문을 파싱해 model 을 읽어 라우팅합니다. 본문이 상한을 넘으면 그 파싱이 실패하고, 게이트웨이는 그것을 「모델을 못 찾겠다」로 보고합니다. Gemini 경로는 한 겹 더 나쁩니다 — 잘린 본문이 벤더에 그대로 전달돼 벤더가 "contents 가 없다"고 답합니다.

즉 응답만 보면 크기 문제와 모델 문제가 구분되지 않습니다.

이슈 §5 의 분류(GMS 4xx → PermanentError → 502)에 이대로 얹으면 크기 초과가 「모델 오류」 502 로 나갑니다. 그 로그를 받는 사람은 모델 설정을 뒤지게 됩니다. 이 문자열을 사용자에게 그대로 노출하는 경로도 같은 오진을 만듭니다.

저희 쪽에 같은 얼굴의 선례가 있습니다 — S15P11A705-225, 긴 Context 가 모델 오류로 오진돼 재시도 없이 실패한 건입니다. 증상은 같고 원인 층이 다릅니다 — 그쪽은 우리 앱의 분류 로직이 잘못 읽은 것이고, 이번은 게이트웨이가 그렇게 보고합니다. 같은 사건이 아니라 같은 함정입니다.

어떻게 가르실지는 설계 판단이라 저희가 정하지 않습니다. 수치와 문자열만 드립니다.

5. 수치의 유효기간

이 표는 상수가 아닙니다.

T27 실측   GMS 판정 쿼터가 07-29 분당 2건 → 07-30 분당 30건 이상으로 바뀌었다

본문 상한도 같은 성질입니다 — 게이트웨이 설정이라 예고 없이 바뀝니다. 그래서 리포트에 측정 시각(2026-08-03 17:07~17:26 KST)과 프로바이더 경로(https://gms.ssafy.io/gmsapi)를 박아 두었습니다. 그 시각·그 경로가 위 수치의 유효 범위입니다.

6. 재지 못한 것

detail:"low"        계획한 두 조건이 전부 §3 의 본문 상한에 걸려 200 을 못 받았다. 미측정
상한의 정확한 값     96,024 ~ 129,564 B 구간까지다. 100,000 · 102,400 · 128,000 을 못 갈랐다
분당·일일 한도       50회 중 429 가 0건이라 하한만 남는다. 상한은 모른다
p95                 분석 축은 조건당 n=1~2 다. 최소·중앙·최대만 적었다
Gemini·Anthropic    호출을 OpenAI 에 몰아서 두 경로는 상한 아래 바이트 사다리를 못 밟았다.
의 바이트 대조쌍     「바이트 불변」의 단독 확인은 OpenAI 뿐이다
                    (가설 판정 자체는 세 경로를 가로지른 대조로 성립한다)
JPEG                만들지 않았다. §3 우회의 검증이 여기에 걸려 있다
실사용 크기의 지연    200 을 받은 이미지가 전부 70 KB 이하다

detail:"low" 재측정과 상한 좁히기는 호출 4~6회면 끝납니다. §3 의 JPEG 우회 검증도 그 정도입니다.

back#138 최종 결정은 "실제 이미지 품질과 처리 성능은 구현 후 별도 테스트와 최적화로 진행합니다" 로 순서를 정했습니다. 사실만 놓고 보면 반대 순서가 쌉니다 — 5 MiB 를 전제로 구현한 뒤 400 을 만나면 전처리 설계가 구현 뒤에 들어옵니다. 위 호출 몇 회는 그 앞에서 끝납니다.

저희는 지금도 잴 수 있습니다. 이 수치를 보시고 순서를 정해 주십시오.

지난 코멘트 이후 답이 나온 것을 정리합니다. back#138 이 「최종 결정」과 함께 not planned 로 닫히면서 저희가 기다리던 항목 여럿에 답이 나왔습니다. 이 이슈의 전제로 그대로 쓰겠습니다.

응답 경로     외부 POST /api/core/v1/places/suggestions
             내부 POST /internal/v1/place-suggestions — 이 이슈 본문과 같은 경로다
타임아웃      Spring → FastAPI read timeout 35초
카카오 호출   FastAPI 가 담당. AI Pod → 카카오 egress 와 Runtime Secret 추가가 따라온다
구조         Spring 중계 확정 · FastAPI 외부 노출 없음 · introspect 는 구현하지 않는다
동시 실행     인스턴스당 1건 — 이 이슈 본문 §3 그대로다. 초과는 PLACE_SUGGESTION_BUSY 로 구분한다

Spring 중계 구현은 S15P11A705-261 로 진행된다고 적혀 있습니다. 카카오를 서버에서 부르는 것이 BD-19(프론트 직접 호출 채택)와 부딪히는 건은 그 코멘트에 판단이 적혀 있지 않습니다 — 저희가 정할 것이 아니라 사실만 남깁니다.

남은 것은 둘입니다.

image2text 코드 위치   아직 답을 받지 못했다. 지난 코멘트 2번(모듈 통합 범위)의 판단이
                      여기 걸려 있다
이미지 상한 5 MiB      실측과 어긋난다 (§3)

lifespan AsyncExitStack(지난 코멘트 1번)은 저희 소관이라 별도 티켓으로 그대로 진행합니다.