권한 대조 검사가 배치 어댑터 13개 중 9개만 봤다 — 넓힌 결과와 파기 권한 결정

[kcrmin]

왜 이 이슈가 있나

#264 가 제재 만료 실패의 원인을 보이게 만들었고, 그 원인은 권한이었습니다(#267 로 수정). 그런데
그것은 네 번째 사례이고, #253 의 권한 대조 검사가 그것을 놓쳤습니다.

원인은 파일 필터입니다.

// ExecutedSqlPrivileges.adapterSources — 놓친 버전
name.endsWith("JooqAdapter.java") || name.endsWith("Store.java")

backend-batch 가 이름을 부르는 어댑터는 13개인데 이 필터는 9개만 봅니다. 제외된 넷:

AccountSanctionJdbcAdapter     ← #264 에서 실제로 실패한 것
AccountRetentionJpaAdapter
IdentityExpiryJdbcAdapter
BatchEvidenceJdbcAdapter

일부만 보는 권한 검사는 갖지 않은 커버리지를 보고합니다. 그것이 이 검사의 존재 이유와 정반대입니다.

필터를 넓히면 나오는 것 — 전체 목록

*Adapter.java·*Store.java·*Consumer.java·*Writer.java·*Resolver.java 로 넓혀 돌린 결과입니다.
#267 이 부여한 제재 관련 항목은 제외했습니다.

INSERT identity.account_lifecycle_events              ← AccountLifecycleJpaCommandAdapter
INSERT identity.account_lifecycle_command_receipts    ← AccountLifecycleJpaCommandAdapter
UPDATE identity.account_security_states               ← AccountLifecycleJpaCommandAdapter
UPDATE identity.refresh_token_families                ← AccountLifecycleJpaCommandAdapter, IdentityExpiryJdbcAdapter
INSERT identity.account_retention_obligations         ← AccountLifecycleJpaCommandAdapter
UPDATE identity.account_retention_obligations         ← AccountRetentionJpaAdapter (+ bare for update)
INSERT identity.account_identifier_quarantines        ← AccountLifecycleJpaCommandAdapter
UPDATE identity.account_identifier_quarantines        ← AccountRetentionJpaAdapter (+ bare for update)
INSERT identity.account_retention_execution_attempts  ← AccountRetentionJpaAdapter
UPDATE identity.login_identities                      ← AccountRetentionJpaAdapter
UPDATE identity.account_emails                        ← AccountRetentionJpaAdapter
INSERT identity.authentication_events                 ← IdentityExpiryJdbcAdapter
UPDATE identity.delegated_authorizations              ← IdentityExpiryJdbcAdapter (+ bare for update)
INSERT identity.delegated_authorization_events        ← IdentityExpiryJdbcAdapter

DELETE identity.account_preferences                   ← AccountRetentionJpaAdapter
DELETE identity.refresh_token_families                ← AccountRetentionJpaAdapter
DELETE identity.password_reset_requests               ← AccountRetentionJpaAdapter
DELETE identity.password_credentials                  ← AccountRetentionJpaAdapter
DELETE identity.recovery_codes                        ← AccountRetentionJpaAdapter
DELETE identity.recovery_code_sets                    ← AccountRetentionJpaAdapter
DELETE identity.email_verification_requests           ← AccountRetentionJpaAdapter
DELETE identity.account_emails                        ← AccountRetentionJpaAdapter
DELETE strategy.strategy_edit_leases                  ← AccountRetentionJpaAdapter
DELETE strategy.validation_runs                       ← AccountRetentionJpaAdapter
DELETE strategy.strategy_documents                    ← AccountRetentionJpaAdapter
DELETE strategy.strategies                            ← AccountRetentionJpaAdapter

왜 그냥 부여하지 않았나

아래 DELETE 들은 계정 파기 경로입니다 — 비밀번호 자격증명, 복구 코드, 이메일, 전략 문서를 지웁니다.
보존·파기 정책이 요구하는 것이 맞다면 정당하지만, 권한 검사를 고치는 부수 효과로 배치 역할에 파기
권한을 주는 것은 잘못된 순서입니다. 해당 잡들(account-closure·dormancy·retention)은 Development
에서 플래그로 꺼져 있어 지금 실패하지도 않습니다.

필요한 결정

1. 파기 권한을 배치 역할에 줄 것인가. 준다면 그 근거(보존 정책 문서)를 명시하고, DELETE 는 파기
   경로가 실제로 지우는 테이블에만 한정한다. 주지 않는다면 그 잡들은 다른 주체가 실행해야 하며 그것을
   기록한다.
2. 넓힌 필터를 병합할 것인가. 병합하면 위 목록이 해소되기 전까지 CI 가 빨갛다. 결정과 함께 같은
   변경에서 들어가는 것이 맞다.
3. bare for update 세 건(account_retention_obligations·account_identifier_quarantines·
   delegated_authorizations)은 Fix backend release failure on run input pin row lock #241·batch 역할에 bot.continuation_deadlines UPDATE 가 없어 FOR UPDATE 잠금이 거부된다 #251 과 같은 함정이다 — 잠금이 필요한지부터 묻고, 필요하면 권한을
   맞추고 불필요하면 잠금을 없앤다.

참고

이 목록은 identity·strategy 만입니다. trading·backtest·pipeline 역할은 2026-08-09 에 좁은
필터로 훑어 "구멍 없음" 으로 기록했는데, 그 판정도 같은 이유로 불완전합니다. 넓힌 필터로 다시 훑어야
합니다.