콘텐츠로 이동

백로그 구조 — 2026-09-27

열린 이슈 85건의 분류와 순서다. 이 문서는 제안이다 — High 승격과 Epic 확정은 사람이 한다(POLICY 14절).

Epic 은 라벨이다

이전에는 EPIC-A ~ EPIC-G 를 이슈 본문 텍스트로 적었다. 두 가지가 잘못됐다.

  • 글자가 뜻을 담지 않는다. EPIC-G 를 읽으면 표를 찾아야 하고, 그 표에 적힌 "User Onboarding" 은 EPIC-G 보다 짧다.
  • 가리키는 대상이 없었다. 열린 Epic 이슈가 0개다. 57개 이슈 본문이 존재하지 않는 것을 참조하고 있었다.

라벨로 옮겼다. 검색·필터가 되고, 이름이 곧 뜻이다.

이것은 POLICY 2.1절을 바꾸는 일이다 — 그 절은 Epic 을 Project 필드와 sub-issue 로 기록하라 했고 "표에 없는 라벨은 만들지 않는다" 고 했다. 그래서 개정 근거를 POLICY 2.1.1절에 적었고, 5절의 EPIC-A ~ EPIC-G 는 대체됨으로 표시했다. 정책을 어긴 채로 두지 않는다.

라벨 뜻 건수
epic:trust 검증·증거·drift·provenance 13
epic:warehouse table · snapshot · SQL · query run 14
epic:governance 정책·라벨·CI 강제 16
epic:byok credential·격리·누출 9
epic:policy 약관·라이선스·PII·publish gate 9
epic:datasets catalogue → spec, provider 온보딩 10
epic:distribution 버전·이미지·릴리스·공급망 5
epic:brand 브랜드·용어 6
epic:onboarding 키 입력·probe·첫 경험 3

epic:warehouse 와 epic:brand 는 새로 만들었다. 이전 분류에 맞는 칸이 없어서 웨어하우스 작업이 trust·distribution 으로 흩어지고, 브랜딩과 i18n 이 "User Onboarding" 에 들어가 있었다 — EPIC-G 에 15건이 몰린 것이 그 증상이다.

제목에 접두사를 붙이지 않는다

GOV-01:, WH-03:, BRAND-02: 같은 접두사를 57건에서 제거했다.

그것은 백로그 문서의 일련번호이고 이슈의 이름이 아니다. 목록을 훑는 사람에게 아무 뜻이 없고, 라벨이 이미 담는 정보를 중복하고, 백로그 문서가 번호를 다시 매기면 틀린 이름이 된다.

제목은 무엇이 문제인지 말한다. 분류는 라벨이 한다.

2026-09-29 개정. 유형(type)은 이제 제목의 Conventional Commits 접두사가 원본이고 type:* 라벨은 거기서 파생된다 — POLICY 2.1.3절. 위 결정은 백로그 일련번호에 대한 것이고 그대로 유효하다.

지금 막고 있는 것은 결정이다

85건 중 11건이 본문에서 "사람의 결정이 먼저 필요하다" 고 말한다. 그리고 그 결정 대부분이 세 덩어리로 모인다.

D-01 — 스키마·식별자 계약

K#461  formatted numeric 처리 정책
K#481  페이지 경계 타입 혼재

둘은 하나의 결정이다. 따로 구현하면 같은 것을 두 번, 다르게 정하게 된다.

정해야 하는 것: 어떤 컬럼이 identifier 인가(법정동코드·PNU·우편번호는 숫자가 아니다), "1,200" 을 정규화할지, 캐스팅 실패를 strict·quarantine·keep_source 중 무엇으로 다룰지.

막고 있는 것:

B#702  identifier wire 계약        — 어떤 컬럼이 identifier 인지 알아야 한다
B#622  Bronze streaming            — 전체를 본 뒤 타입을 정하면 streaming 이 불가능하다
B#698  JOIN cardinality            — 한쪽이 정수로 캐스팅되면 JOIN 이 안 맞는다

D-02 — 배포 모드 (단일 사용자 / 다중 사용자)

B#682  키 비저장 ADR
B#635  ENFORCE_OWNERSHIP 기본값

막고 있는 것:

B#683  ephemeral credential context
B#684  사용자 간 캐시 차단 (이 결정이 우선순위를 바꾼다)
B#679  관리자 역할 범위 (a)/(b)/(c)
S#409  관리자 화면

D-03 — 데이터 정책 모델

K#524  약관 매트릭스
B#677  17개 데이터셋의 공공누리 유형

막고 있는 것:

K#525  spec 정책 필드
B#688  publish gate
B#689  PII 마스킹
B#694  dataset card

세 덩어리에 속하지 않는 결정 6건

D-01~D-03 은 서로 얽힌 큰 결정이고, 나머지는 각자 독립적이다.

이슈 정해야 하는 것
K#479 RecordBatch.meta 를 transport 가 채우나 어댑터가 채우나. 그리고 어떤 키를 공개 계약으로 굳히나
K#464 previous_status 를 저장할지, 전이 이력을 어디에 둘지
B#648 이어받기가 "같은 입력이면 같은 결과" 주장 안에 있나 밖에 있나
B#636 마이그레이션 후 scripts/pipeline/ 을 지울지, 과거 산출물의 출처로 남길지
B#701 자원 상한을 무엇으로 재나 — 엔진 교체는 이 측정 뒤의 문제다
K#512 감사 결과의 MERGE·CLOSE 판정 확정

S#424 는 이 목록에서 빠졌다 — BRAND.md 가 결정을 끝냈다.

결정에 막히지 않은 것

지금 진행할 수 있는 것들이다.

이슈 왜 지금 가능한가
B#699 immutable snapshot + CAS 웨어하우스의 기반이고 선행 결정이 없다
K#521 secret 분리 + protected environment 설정 작업이고 D-02 와 무관하다
K#520 정책을 설정으로 강제 — 9개 항목 중 8개 아래 참고
B#690 버전 단일화 선언·태그가 어긋난 것을 맞추는 일이다
S#421 Kubi → Ask KPubData 브랜드 결정이 끝났다(BRAND.md)
K#517 주석 영어화 정책 확정(ADR 0003), 진행 중

K#520 은 통째로 막힌 것으로 적혀 있었지만(Blocked by: #507) 실제로는 한 항목만 25절에 걸린다 — 경로 기반 R-레벨 labeler다. R0~R3 정의가 없으면 자동 부여 규칙을 쓸 수 없다. 나머지 8개(브랜치 보호, 봇 병합 권한 제거, CODEOWNERS — 경로는 이미 열거돼 있다, Environments 승인, CI 의 git diff --exit-code, 생성물 --check, 주석 게이트)는 25절과 무관하다.

주의: K#520 의 첫 항목 "사람 리뷰 1건 필수"가 #545 가 보고한 상태를 만든 원인이다. 관리자가 한 명인 동안 그 요구는 만족될 수 없다. 두 이슈를 같이 결정해야 한다.

순서 제안

B#699(immutable snapshot)가 웨어하우스 작업 대부분의 선행이므로 먼저다.

1  B#699  immutable snapshot + CAS
       └─ B#700 drift baseline 격리
       └─ B#704 multi-table SQL
       └─ B#705 snapshot GC·backup
       └─ B#703 materialize-only
       └─ S#417 My Tables

2  D-01 결정  →  K#461 + K#481  →  B#702, B#622, B#698

3  D-02 결정  →  B#683, B#684, B#679, S#409

4  D-03 결정  →  K#525, B#688, B#689, B#694

병행 (결정 무관)
   K#520 · K#521 · K#522 · K#523   증거 파이프라인
   B#690 · S#411 · B#692           배포 산출물
   S#421~425                       브랜드
   K#517                           주석 영어화

뒤로 미룬 것 — 2026-09-27

우선순위를 매기지 않는다는 아래 원칙에는 예외가 없지만, 오너가 내린 순서 결정은 기록한다. 그것은 이 문서가 추정한 것이 아니라 결정된 사실이다.

주석·docstring 영어화는 뒤로 간다

이슈 건수
kpubdata#517 kpubdata#518 3,275 (src 769 · tests 2,386 · scripts 120)
kpubdata-builder#710 3,878 (255개 파일)
kpubdata-studio#427 2,145 (TS/TSX)

합계 9,298건이다. 이슈는 남기고 착수하지 않는다.

이유가 분명하다. 이 작업은 동작을 하나도 바꾸지 않는다. 같은 시간에 builder#699(immutable snapshot)를 하면 웨어하우스 작업 6건이 풀린다. 번역은 기여자가 실제로 늘 때 가치가 생기고, 그때까지는 부채가 늘지 않게만 두면 된다.

그래서 게이트는 남긴다

builder#711 은 번역이 아니라 새 부채를 막는 검사다. 래칫이므로 기존 3,878건을 동결하고 늘어날 때만 실패한다. 이것을 같이 미루면 미루는 동안 숫자가 계속 커진다.

미루는 것과 막는 것은 다른 일이다. 앞의 것은 비용이 크고 뒤의 것은 이미 끝났다.

이 결정이 바뀌는 조건

  • 외부 기여자의 PR 이 들어오기 시작한다
  • 한국어를 모르는 사람이 이슈를 연다
  • src/ 의 public API docstring 이 문서 사이트에 노출된다

셋 중 하나가 일어나면 src/ 의 docstring 부터 다시 올린다 — help() 에 나오는 것이 먼저다.

같은 날, 철회 — 2026-09-27

오너가 이 결정을 되돌렸다. 위 세 조건이 발생한 것이 아니라 방침 변경이다. src/ 루트 모듈(공개 API)부터 다시 올린다 — 한 조각이 한 브랜치·한 PR 이고, #517 을 우산 이슈로 둔다. 게이트(builder#711 래칫)는 그대로 유지한다.

되돌린 이유를 덧붙이지 않는다. 위의 비용 계산이 틀려서가 아니라, 같은 시간을 어디에 쓸지 오너가 다시 정한 것이다.

우선순위는 이 문서에서 정하지 않는다

POLICY 8절의 High 조건은 Impact: · Blocks: · Evidence: 를 요구하고, 14절은 High 승격을 사람의 일로 둔다. 그리고 우선순위를 둘 곳이 아직 없다 — GOV-02 의 GitHub Project 가 project scope 없이 막혀 있고, POLICY 는 우선순위를 Project 필드로만 관리하라고 한다.

근거가 없는 이슈 35건이 있다. High 로 올리려면 그 35건 중 해당하는 것에 Evidence: 를 먼저 채워야 한다. 그것이 GOV-05(K#510)의 실제 작업이다.

관련