chore(deps): move the kpubdata pin to the 0.9 line

[Eomdahyeon]

Closes #1002
Refs #990, kpubdata-lab/kpubdata#780

kpubdata 0.9.0 이 PyPI 에 올라왔다(https://pypi.org/pypi/kpubdata/json → 0.9.0). kpubdata#812 가 정한 대로 핀을 옮긴다: kpubdata>=0.9.0,<0.10.

머지 전에 읽어 주세요 — 배포의 동작이 바뀝니다. 아래 "0.9.0 카탈로그가 말하는 약관" 절.

변경

• pyproject.toml, uv.lock: kpubdata>=0.8.0,<0.9 → >=0.9.0,<0.10. 잠금 파일에서 바뀐 것은 kpubdata 항목뿐이다(uv lock --no-sources --upgrade-package kpubdata, --check 통과).
• chore(deps): import find_spec, discover_specs and KPubDataConfig from kpubdata's public surface #1002: kpubdata 의 private 모듈에서 가져오던 import 7개를 public 이름으로 바꾸고 allowlist 항목을 지웠다.
  • find_spec (agent/monitor.py, agent/pipeline.py, cli.py), discover_specs (cli.py), KPubDataConfig (service/providers.py, verify/runner.py) — 이슈가 적은 6개.
  • SENSITIVE_PARAM_KEYS (logging_redaction.py) — 0.9.0 이 public 으로 내보낸다(kpubdata#782). 이슈에는 "남는 항목"으로 적혀 있었지만 이제 필요 없다.
  • 0.9.0 을 설치하면 게이트가 스스로 이것을 요구한다: 핀만 올린 상태에서 test_the_repository_passes_against_the_installed_kpubdata 가 실패했고, 메시지가 위 6개를 하나씩 짚었다.
  • 남은 allowlist 는 verify/runner.py 의 7개다: SpecExecutor, check_payload_error, extract_items, extract_total_count, ExampleSpec, SpecDefinition, HttpTransport.
• tests/unit/test_verify_cli.py: find_spec 을 패치하는 대상을 kpubdata.core.spec → kpubdata 로. import 경로가 바뀌어 예전 대상은 더 이상 닿지 않는다(테스트 하나가 실패했다).
• pyproject.toml 주석, CONTRIBUTING.md 의 핀 설명, cli.py 의 안내 문구를 0.9 기준으로.
• CHANGELOG.

#990 에 대해

#1014 가 "env_keys 없는 kpubdata 로는 이 모드로 기동하지 않는다"를 넣었고, 0.8.0 에서는 그 거부가 항상 걸렸다. 0.9 라인에서는 Client 가 env_keys 를 받으므로 다중 사용자 모드가 기동한다. 0.8.0 이라 건너뛰던 테스트(test_require_own_credential.py 의 env_keys 실동작 테스트)가 이제 돌고 통과한다 — skip 수가 9 → 8 로 줄었다.

이슈의 세 조건이 이 핀으로 모두 충족되는지는 판단을 맡긴다. 그래서 Closes 가 아니라 Refs 다. client_keeps_environment_keys_out() 확인은 남겨 두었다 — 누군가 더 낮은 버전을 설치한 환경을 위한 것이다.

0.9.0 카탈로그가 말하는 약관 — 배포에서 달라지는 것

설치된 0.9.0 카탈로그를 읽으면(Client(...).datasets.list()): 약관 선언 없음 134, unknown 18, forbidden 1, allowed 3.

• datago.air_quality 가 forbidden 이다. 0.8.0 에서는 redistribution 선언이 없어 unknown 이었다. Builder 는 forbidden 에서 게시(공개·비공개 모두)와 /query·/preview·stage sample·warehouse 읽기·export·artifact 다운로드를 모두 막는다(feat: publish gate — enforce the redistribution verdict, legacy path included #688). 이 핀이 들어가면 air_quality 로 만든 빌드는 Builder 밖으로 한 행도 나가지 않는다. fix(publish): reconcile existing air-quality publications with source license restrictions #759("air_quality 는 KOGL 3유형인데 변형해 게시된다")가 다루던 문제의 답이 이것이라면 의도된 결과다 — 다만 데모·문서·e2e 가 air_quality 를 예제로 많이 쓴다는 점은 확인이 필요하다. 단위 테스트는 약관 조회를 conftest 에서 고정하므로 이 변화를 보지 못한다.
• baseline 의 16개는 unknown 이다 — kpubdata 가 직접 그렇게 보고하고(kpubdata#814), Builder 의 fix(publish): read allowed without a confirmed attribution as unknown #1036 도 같은 판정을 한다. 16개 전부를 실제 카탈로그로 확인했다: source_verdict(...) → 16개 모두 unknown. fix(publish): read allowed without a confirmed attribution as unknown #1036 리뷰가 남긴 "핀을 올리는 PR 에서 봐야 한다"는 확인이 이것이다.
• allowed 로 남는 것은 apt_trade, apt_rent, village_fcst 셋이다.

검증

• pytest tests/unit (kpubdata 0.9.0 설치) → 4409 passed, 8 skipped (8분 12초).
• scripts/check_kpubdata_imports.py → checked 246 files: no unlisted kpubdata private imports.
• ruff check, ruff format --check, mypy src 통과.
• 하지 않은 것: 실제 Builder 를 띄워 air_quality 빌드가 어떻게 답하는지 보지 않았다. e2e·데모 스크립트를 0.9.0 으로 돌리지 않았다. kpubdata 0.9.0 의 다른 breaking 변경(401 → AuthError, 건수 0, NODATA, 자격 증명 요청의 리다이렉트 미추적)이 Builder 의 실제 provider 호출 경로에 주는 영향은 단위 테스트가 통과한다는 것까지만 확인했다.
• CI 의 kpubdata 0.8.0 잡은 이름이 워크플로에 박혀 있다 — 핀이 바뀌면 그 잡이 무엇을 설치하는지 확인이 필요하고, 워크플로 파일은 제가 고칠 수 없다.

🤖 Generated with Claude Code

[yeongseon]

diff 를 읽었고 CLEAN 이라 승인합니다. 이 핀이 들어가야 다중 사용자(OIDC) 모드가 기동합니다.

핀과 public import 전환을 한 PR 로 묶은 것: 따로 올려 달라고 했지만 받아들입니다. 0.9.0 을 설치하면 check_kpubdata_imports.py 의 게이트가 allowlist 의 그 항목들을 스스로 거부한다는 설명이 맞고, 핀만 올린 PR 은 통과할 수 없었습니다.

확인한 것:

• 잠금 파일에서 바뀐 것은 kpubdata 항목뿐입니다(0.8.0 → 0.9.0 의 sdist·wheel 해시와 specifier).
• env_keys 실동작 테스트가 이제 돌고 skip 이 9 → 8 로 줄었다는 것. CI 의 kpubdata 0.9.0 잡과 kpubdata main ↔ Builder 잡이 모두 통과했습니다 — 본문이 걱정한 "kpubdata 0.8.0 잡 이름이 박혀 있다" 는 아니었습니다. 잡 이름이 지원 릴리스 목록에서 만들어집니다.
• baseline 의 16개가 실제 0.9.0 카탈로그로 모두 unknown 이라는 것 — #1036 리뷰가 "핀을 올리는 PR 에서 봐야 한다" 고 남긴 확인입니다.

datago.air_quality 가 forbidden 이 되는 것 — 의도된 결과입니다. kpubdata 0.9.0 의 spec 이 그렇게 선언합니다(type: 공공누리_3유형, modification_allowed: false, redistribution: forbidden, kpubdata#720). #759 의 owner 결정(D6, 2026-09-30)이 air_quality 게시를 멈췄고 scheduled-air-quality.yml 은 비활성 상태입니다(마지막 실행 2026-09-29). 예약 게시 경로는 config 의 license_name: kogl-type-3 로 판정하므로 이 핀과 무관하게 이미 forbidden 입니다.

달라지는 것은 Builder 서비스 쪽입니다: air_quality 로 만든 빌드는 게시뿐 아니라 /query·/preview·다운로드도 막힙니다(#688 의 설계). 영향 범위를 확인했습니다 —

• Builder 저장소의 specs·tests/e2e·docs·README.md 에서 air_quality 를 쓰는 것은 scripts/configs/air_quality.yaml 하나입니다.
• Studio 의 실 Builder e2e(e2e/real-builder.spec.ts)는 replay 소스로 datago.air_station 을 씁니다. 0.9.0 에서 unknown 이라 읽기는 되고 공개 게시만 막힙니다. Studio 의 다른 e2e 일곱 파일이 air_quality 를 쓰지만 CI 에서는 mock 으로 돕니다.

남는 것: Studio 의 데모·문서·mock 이 air_quality 를 예제로 쓰는데 실제 Builder 에서는 그 데이터셋으로 아무것도 읽을 수 없게 됩니다. 예제를 다른 데이터셋으로 옮기는 이슈를 Studio 에 올려 주세요. 그리고 #990 은 누출 테스트(완료 조건 3)까지 보고 닫을지 정하면 됩니다 — Refs 로 둔 것이 맞습니다.