플랫폼 정책을 허용·차단 한 축으로 교체 - #955
Merged
Merged
Conversation
- 옛 route 3값(SUPPORTED·HEADLESS_FIRST·UNSUPPORTED)과 허가 boolean 은 서로 다른 질문(등록을 받나 / 어떻게 가져오나 / 실측했나 / 브라우저를 써도 되나)에 한 축으로 답하고 있었다. 그래서 '허가 없는 HEADLESS_FIRST' 같은 모순 조합이 DB 에 저장 가능했고 실제로 dev 에 좀비 행 3개가 있었다
- 축을 하나로 좁힌다: DomainAccess { ALLOWED, BLOCKED }. 행이 없으면 기본 흐름이라 정책 테이블은 예외만 담고, 두 값 모두 실제 동작을 가져 기록 전용 값이 사라진다. 모순 조합은 표현 자체가 불가능해진다
- '어떻게 가져오나'(HEADLESS_FIRST)는 최적화였고 불완전 승격이 들어온 뒤로는 정책 없이도 같은 결과에 도달해 값을 넣을 유인이 사라졌다. 축에서 제거하고, 필요해지면 별도 컬럼으로 되살린다(성격이 다른 것을 한 축에 넣지 않는다)
- BLOCKED 검사를 extractor 로 나가는 유일한 출구(HttpProductLinkExtractor)에 둔다. 등록 경계만 막던 종전 구조는 차단 지정 이전에 담긴 아이템의 재파싱·새로고침이 그대로 나갔다 - '거부 의사를 확인한 곳에 매번 다시 두드리지 않는다'는 계약이라 성능 판단이 아니다
- ALLOWED 는 '플랫폼의 명시적 허락을 받았다'는 뜻이고 그 결과로 렌더 서비스의 우회 수단이 열린다. 근거(permissionRef) 없이는 켤 수 없게 입력 경계와 엔티티 불변식 양쪽에서 막는다
- 테이블을 이관하지 않고 새로 만든다. 같은 HEADLESS_FIRST 라도 kream 은 차단이고 store.kakao 는 차단이 아니라 기계적 매핑이 성립하지 않는다. 시드도 두지 않는다 - 근거 없이 채우면 좀비 행이 생긴 경로를 그대로 반복한다
- 백오피스 3열을 2열로 개편하고 값 이름이 그대로 박혀 있던 CSS 클래스까지 함께 고친다. 허가 체크박스는 ALLOWED 값에 흡수됐다
- 옛 테이블은 이 마이그레이션에서 지우지 않는다. 코드가 참조를 끊은 배포가 한 바퀴 돈 뒤 별도 마이그레이션으로 제거한다(blue-green 공존 구간에서 구버전이 아직 읽는다)
|
Important Review available on request
Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment ⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Discord 스레드 연동용 메타데이터입니다. discord-pr-bot 워크플로가 자동 생성하며, 수정·삭제하면 PR 과 Discord 알림 연동이 끊깁니다. |
This was referenced Aug 16, 2026
- core 가 아는 것은 "이 도메인이 허락을 받았는가" 하나여야 하는데, 주석과 백오피스 문구가 "우회 수단(지문 보정·프록시)", "정적 fetch → 안 되면 브라우저" 처럼 렌더 모듈의 구현을 서술하고 있었다. 수단이 바뀌면 core 쪽 서술만 조용히 낡으므로 "기본 수단 / 적극적인 수단" 으로 올리고, 무엇을 쓸지는 추출 모듈이 정한다는 사실까지만 남긴다 - 타입·필드·스키마·계약에는 원래 수단 어휘가 없었다. 이번에 걷어낸 것은 전부 주석과 운영자 대면 문구다 - 백오피스 정책 설명은 문장을 개조식으로 풀었다 — 한 항목이 한 사실을 져야 갈래끼리 세로로 훑어 비교된다 - 축 교체 후 남아 있던 잔재를 함께 정리했다: 삭제된 클래스를 가리키던 주석(ExtractionRoutingPolicy · ExtractionPlatformPolicyEntity), 옛 정책 값 이름(UNSUPPORTED 정책 후보 → BLOCKED), 화면 제목의 "추출 라우팅 정책" → "도메인 접근 정책" - 필드명 extractionRoutingPolicy 를 accessPolicy 로 바꿨다. 타입은 이미 DomainAccessPolicy 인데 이름만 옛 축을 가리키고 있었다 - 3열 시절의 죽은 CSS(rowspan 병합 규칙, 제거된 허가 체크박스의 .check·.badge.allowed·.badge.denied)를 지웠다 - 코드와 어긋나 있던 주석도 정정했다. 추가 폼 기본값이 BLOCKED 인데 주석은 "기본값이 SUPPORTED 인 이유" 를 설명하고 있었다 — 값이 둘뿐이라 "아무것도 안 바꾸는 값" 이 없고, 되돌리기 쉬운 쪽을 기본에 둔다는 근거로 다시 썼다
This was referenced Aug 19, 2026
m-a-king
added a commit
that referenced
this pull request
Aug 19, 2026
- 단계 배포(add → 양쪽 공존 → drop)의 마지막 단계다. #955 에서 새 테이블을 만들고 코드 참조를 전부 끊었지만, blue-green 공존 구간의 구버전 인스턴스가 부팅 때 이 테이블을 읽어(@PostConstruct findAll) 그때는 남겨 뒀다. 그 배포가 dev·prod 를 한 바퀴 돌아 이제 지운다 - 행을 옮기지 않는다. 옛 route 3값은 새 축으로 기계적 매핑이 성립하지 않아(같은 HEADLESS_FIRST 라도 kream 은 차단, store.kakao 는 아님) 새 테이블을 비운 채 시작했고, 여기서 되살릴 근거도 없다. reason 에 남아 있던 실측 메모를 보존할지 물었으나 새로 가는 쪽으로 결정했다 - 별도 테스트는 두지 않는다. 통합 테스트가 빈 DB 에 전체 마이그레이션을 새로 적용하므로 이 DROP 의 순서·성립 여부가 그 실행으로 검증된다
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Situation
route3값(SUPPORTED·HEADLESS_FIRST·UNSUPPORTED)과 허가 boolean 두 축으로 갈라져, 서로 다른 질문 네 개(등록을 받나 / 어떻게 가져오나 / 실측했나 / 어디까지 허락됐나)에 답하고 있었다.HEADLESS_FIRST+ 허가 없음은 화면에 "브라우저 직행"으로 보이는데 실제로는 아무 일도 안 일어나는 상태이고, dev 에 그런 좀비 행이 3개 실재했다.Task
Action
축을 하나로
DomainAccess { ALLOWED, BLOCKED }. 행이 없으면 기본 흐름이라 정책 테이블은 예외만 담고, 두 값 모두 실제 동작을 가져 기록 전용 값이 사라진다. 모순 조합은 표현 자체가 불가능해진다.ALLOWEDBLOCKEDcore 는 허락만 알고, 수단은 모듈이 해석한다
계약으로 나가는 값은
authorized한 비트다. 원장의 세 상태를 모듈이 알아야 하는 만큼만 투영한 것이라 1:1 매핑이 아니다.ALLOWEDauthorized: trueauthorized: falseBLOCKED"등록을 받을 것인가"는 우리 서비스의 결정이라 모듈이 알 이유가 없다. 그래서
BLOCKED는 계약을 타지 않고 core 에서 끝난다.같은 이유로 어휘도 core 에 두지 않는다. 주석과 백오피스 문구를 "기본 수단 / 적극적인 수단"으로 올리고, 무엇을 쓸지는 추출 모듈이 정한다는 사실까지만 남겼다. 타입·필드·스키마·계약에는 원래 수단 이름이 없었고, 이번에 걷어낸 것은 전부 주석과 운영자 대면 문구다.
최적화는 뺀다
"어떻게 가져오나"(
HEADLESS_FIRST)는 최적화였고, 불완전 승격이 들어온 뒤로는 정책 없이도 같은 결과에 도달해 값을 넣을 유인이 사라졌다. 축에서 제거하고 필요해지면 별도 컬럼으로 되살린다. 성격이 다른 것을 한 축에 넣지 않는다.차단은 출구 한 곳에서
BLOCKED검사를 extractor 로 나가는 유일한 출구에 뒀다. 등록 경계만 막던 종전 구조는 차단 지정 이전에 담긴 아이템의 재파싱·새로고침이 그대로 나갔다. "거부 의사를 확인한 곳에 매번 다시 두드리지 않는다"는 계약이라 성능 판단이 아니다.허락에는 근거를
ALLOWED는 적극적인 수단을 여는 값이라 근거(permissionRef) 없이는 켤 수 없다. 입력 경계와 엔티티 불변식 양쪽에서 막는다.이관하지 않고 새로 만든다
같은
HEADLESS_FIRST라도 kream 은 차단이고 store.kakao 는 차단이 아니라 기계적 매핑이 성립하지 않는다. 시드도 두지 않는다. 근거 없이 채우면 좀비 행이 생긴 경로를 그대로 반복한다. 쿠팡·네이버 등은 당분간 실패로 흐르지만 그건 "아직 판단하지 않았다"의 정직한 반영이고, 판단이 서면 백오피스에서 넣는다.축 교체 후 남은 잔재 정리
어휘를 걷다 보니 앞 커밋이 놓친 자리가 함께 나왔다.
ExtractionRoutingPolicy·ExtractionPlatformPolicyEntity)UNSUPPORTED 정책 후보→BLOCKED 정책 후보)extractionRoutingPolicy→accessPolicy. 타입은 이미DomainAccessPolicy인데 이름만 옛 축을 가리키고 있었다BLOCKED인데 주석은 "기본값이 SUPPORTED 인 이유"를 설명하고 있었다. 값이 둘뿐이라 "아무것도 안 바꾸는 값"이 없고, 되돌리기 쉬운 쪽을 기본에 둔다는 근거로 다시 썼다Result
연관 이슈