3.5 KiB
kind, slug, title, topic, topicName, project, status, sourceRevision, rootTreeNode, source
| kind | slug | title | topic | topicName | project | status | sourceRevision | rootTreeNode | source | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | the-guard-is-on-and-the-service-is-not | 가드와 journal 과 durability 검증기는 켜지고, 부를 서비스가 없었다 | assembly-ownership | 조립 소유권 — 통제와 그 의존을 같은 곳이 소유하기 | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:the-guard-is-on-and-the-service-is-not |
|
가드와 journal 과 durability 검증기는 켜지고, 부를 서비스가 없었다
admin 경로의 보호 장치는 조립되는데 파괴적 작업을 수행할 서비스는 자동설정하지 않는 구조가 함께 존재한다. 현재 판정은 정적 조립 분석에 근거하며 실제 admin 활성 부팅은 재현하지 않았다.
관계
- 파괴적 admin 작업은 자동설정하지 않는다 이 부재를 프로젝트가 의도한 결정으로 설명한다.
- @Bean이 있다는 것은 조립 증거가 아니다 보호 장치와 실제 실행 서비스를 분리해서 확인하는 기준이다.
문제
가드·journal·durability 검증 같은 주변 통제는 자동설정 경로에 올라가지만, 실제 파괴 작업을 수행하는 admin 서비스는 같은 방식으로 제공되지 않는다.
정적 분석에서 서비스 직접 참조와 조립 경로를 찾지 못했고, SSOT는 이 부재를 의도된 안전 경계로 기록한다. 문제는 보호 장치가 존재한다는 사실만 보고 admin 기능 전체가 제공된다고 오해할 수 있다는 점이다.
결론
이 구조는 “가드가 켜졌으니 서비스도 켜졌다”는 신호가 아니다. 파괴적 실행 서비스는 애플리케이션이 명시적으로 제공해야 하며, 플랫폼 자동설정은 그 서비스를 만들어 주지 않는다.
현재 머신에서 source repository를 다시 대조하지 못했으므로, 실제 admin 활성 부팅까지 확인했다고 주장하지 않는다.
검증 환경
sourceRevision : 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 현재 source repository 재대조 : UNVERIFIABLE 확인 방식 : SSOT에 기록된 조립 경로와 정적 참조 분석
재현 조건
- SSOT의 admin 자동설정 절에서 생성되는 guard·journal·validator를 확인한다.
- 파괴적 admin service 타입의 main 직접 참조와 생성 경로를 확인한다.
- 자동설정이 실행 서비스를 직접 제공하는지 분리해서 본다.
- 실제 부팅 재현은 source repository가 있는 환경에서 별도로 수행한다.
본문
보호 장치와 실행 서비스는 같은 능력이 아니다
가드는 호출을 허용할지 판정하고 journal은 실행 이력을 남긴다. durability validator는 전제 조건을 검사한다. 이 셋이 조립돼도 실제 파괴 작업을 수행할 service가 자동으로 생기지는 않는다.
부재를 의도된 경계로 읽는다
SSOT는 destructive admin operation을 플랫폼이 자동설정하지 않는 방향을 별도 Decision 후보로 분리한다. 따라서 서비스 부재는 현재 분석에서 우연한 누락으로만 다루지 않는다.
확인하지 못한 것
실제로 admin 기능을 켠 애플리케이션을 부팅해 “호출 대상이 없다”는 런타임 결과를 재현하지 않았다. 현재 결론은 sourceRevision에 대한 기존 정적 분석 범위다.