--- kind: CASE slug: registry-column-too-short-for-its-own-path title: 레지스트리 컬럼이 38자 경로에서 짧아 "더 짧은 경로를 적는" 우회를 유혹했다 topic: schema-ownership-and-capability-streams project: clean-architecture-backend-template status: 게시 전 sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 rootTreeNode: case:registry-column-too-short-for-its-own-path evidenceCapturedOn: 2026-09-01 assets: - key: registry-column-too-short-for-its-own-path file: ../../../final/evidence/rendered/registry-column-too-short-for-its-own-path.svg evidence: - ../../../final/evidence/raw/registry-column-too-short-for-its-own-path.txt source: - 원본 분석 절은 final/document.md#a05 §8.4 이다. --- # 레지스트리 컬럼이 38자 경로에서 짧아 "더 짧은 경로를 적는" 우회를 유혹했다 능력 스키마 레지스트리의 스트림 경로 컬럼이 32자였다. 실제 스트림 경로가 그보다 길어 거절됐고, 오류 메시지는 컬럼 이름을 부르지 이유를 말하지 않았다. ## 관계 - **독립 Flyway 스트림과 baseline version 0** 이 레지스트리가 기록하는 대상이다. - **두 트리가 다 V1부터 번호를 매겨 공유 history가 하나를 건너뛸 수 있었다** 스트림 경로가 길어진 이유와 연결된다. ## 문제 능력 스키마 레지스트리는 각 능력의 스키마 스트림 경로를 기록한다. 그 컬럼이 32자였다. 능력별 스트림 경로는 그보다 길다. 능력 이름과 디렉터리 구조가 경로에 들어가기 때문이다. ## 결론 컬럼이 자기가 기록해야 할 경로보다 짧았다. 이 상태의 위험은 실패 자체가 아니라 우회의 유혹이다. 오류가 컬럼 길이를 말하므로, 가장 쉬운 대응은 경로를 짧게 바꾸는 것이다. 그러면 경로가 구조를 반영하지 않게 되고 다음 능력에서 같은 문제가 다시 난다. 수정은 컬럼을 넓히는 것이었다. 그리고 두 위치가 같은 테이블을 만들기 때문에 양쪽 다 넓혀야 했다. 마이그레이션 헤더가 그 이유를 적는다. 한쪽으로만 마이그레이션한 배포는 여전히 32자를 넘는 스트림 경로를 거절하고, 그 오류는 이유가 아니라 컬럼 이름을 부른다는 것이다. 번호 선택에도 근거가 있다. 두 트리가 샘플 컴포지션에서 하나의 위치 목록으로 병합되므로 버전 공간을 공유한다. 샘플이 이미 몇 개 번호를 갖고 있어서 그것들을 피해야 했다. 중복 버전은 Flyway 가 해결하는 병합 충돌이 아니라 기동 거부다. ## 검증 환경 데이터베이스 : PostgreSQL 마이그레이션 도구 : Flyway 확인 방식 : 마이그레이션 헤더의 사후 기록 확인 소스 수정 : x ## 재현 조건 1. 컬럼을 넓히는 마이그레이션의 헤더를 읽는다. 번호 선택 근거와 두 위치 문제가 적혀 있다. 2. 원래 컬럼 정의를 확인한다. 3. 같은 테이블을 만드는 다른 위치를 확인한다. ## 본문 `schema_stream`이 `varchar(32)`였고 작성 당시 모든 스트림에 맞았으며 `'db/migration/jpa/notification-platform'`(38자)에서 안 맞기 시작했다. ## 컬럼 폭이 맞지 않기 시작한 경로 :::evidence key="registry-column-too-short-for-its-own-path" alt="분석 문서 final/document.md#a05 에서 이 기록의 근거 절을 그대로 잘라낸 3줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md#a05 발췌 — 3줄" zoom="true" ::: ## 실패 모드가 나쁜 종류다 모든 면에서 올바른 등록이 `value too long`으로 마이그레이션 타임에 실패하고, **뻔한 우회책은 스트림의 실제 경로가 아닌 더 짧은 경로를 기록하는 것**이며, 스키마가 어디서 왔는지에 대해 거짓말하는 레지스트리는 없는 것보다 나쁘다. ## 128로 넓힌 이유 `capability_id`가 이미 `varchar(128)`이고 **하나의 bound가 두 개보다 추론하기 쉽다.** ## 확인하지 못한 것 32자를 넘는 경로로 삽입해 거절을 재현하지 않았다. 이 기록은 마이그레이션 헤더에 근거한다. 없음