attach identity 검증에 SDK 경유 deploymentId 회수 활용 — getSchemeUri()/getAppsInTossGlobals().deploymentId (3.0 실기기 확인)

[DaveDev42]

배경 (2026-07-08 실기기 관측, 31146 / qa-3x-cell.4)

3.0 런타임 실기기에서 gate-probe(sdk-example #284)로 확인한 ground truth:

• 페이지 서빙 호스트는 <appName>.private-web.tossmini.com (4-label, private-apps 아님) — #760의 tossmini-계열 확대가 정확히 커버.
• _deploymentId는 여전히 페이지 URL로 미전파 (in-app gate가 3.0 런타임에서 무신호 차단 — host allowlist·_deploymentId 전제가 2.x 계약에 결합 #760/attach 페이지 매칭이 _deploymentId 전파(2.x 계약)에 결합 — 3.0 런타임에서 connected 후 무한 대기 #763 전제 재확인).
• SDK getSchemeUri()가 원본 launch scheme URI 전문을 반환 — _deploymentId + 뒤에 붙인 debug/relay/at/host 쿼리까지 그대로. 값은 콘솔 deploymentId와 일치 확인.
• getAppsInTossGlobals()에 deploymentId 키가 직접 존재 (그 외 brandDisplayName/brandIcon/brandPrimaryColor).
• getOriginalSchemeURI류 미문서 API는 window/globals 어디에도 없음 (탐색 결과 not found).

제안

#764의 relay-wss 매칭은 transport-수준 필터로 유지하되(브리지 불요·run-고유), attach 후 identity 검증을 SDK 경유로 보강할 수 있다:

1. attach 직후 Runtime.evaluate로 window.__sdkCall('getSchemeUri') 또는 getAppsInTossGlobals().deploymentId를 조회해 기대 deploymentId와 대조 — 불일치면 stale 페이지로 간주하고 계속 대기.
2. in-app gate B2가 3.0 계열에서 "보고만" 하던 deploymentId를 globals에서 회수해 정확히 보고 (provenance 복원).

주의: scheme URI 전문에는 relay/at 시크릿이 포함된다 — 대조는 deploymentId 부분만 추출해서 하고, 전문을 로그/리포트/gate-reason으로 반환 금지 (SECRET-HANDLING).

관련

• in-app gate가 3.0 런타임에서 무신호 차단 — host allowlist·_deploymentId 전제가 2.x 계약에 결합 #760 (gate 3.0 계열 확대, 머지), attach 페이지 매칭이 _deploymentId 전파(2.x 계약)에 결합 — 3.0 런타임에서 connected 후 무한 대기 #763/fix(mcp): attach 페이지 매칭에 run-scoped relay wss 매칭 — 3.0 런타임 connected 후 무한 대기 해소 #764 (relay-wss 매칭, 머지)
• sdk-example M1 epic: devtools MCP 견고성·사용성 — 1.0 출시 품질 #284 (측정 브랜치 probe)