---
kind: CONCEPT
slug: messaging-admin-api-c03
title: 서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다
topic: schema-and-wire-models
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: concept:messaging-admin-api-c03
evidenceCapturedOn: 2026-09-01
assets:
  - key: messaging-admin-api-c03
    file: ../../../final/evidence/rendered/messaging-admin-api-c03.svg
  - key: messaging-admin-api-c03-diagram
    file: ../../../final/assets/diagrams/messaging-admin-api-c03.svg
evidence:
  - ../../../final/evidence/raw/messaging-admin-api-c03.txt
source:
  - 원본 분석 절은 analysis/messaging/messaging-admin-api.md#L185 이다.
module: messaging-admin-api
---

# 서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다

8개 필드. 그중 requestedBy 가 생성자에서 4-eyes 를 강제한다.

## 본문

<!-- body:start -->

`ApprovalGrant` 는 8개 필드다. 그중 `requestedBy` 가 생성자에서 4-eyes 를 강제한다. "우회할 수 없는 자리에 표현했다" — 검사기가 아니라 **record 생성자**에 두었으므로, 서명 대상 객체가 존재하는 것 자체가 4-eyes 통과를 뜻한다.

## canonicalForm 이 길이 접두 인코딩인 것

버전 접두 `"v1"` 이 앞에 있어 형식 교체 여지를 남긴 것도 의도적으로 보인다. 이 규칙이 계획 다이제스트 쪽에는 적용되지 않았다 — §12.3(b).

## 승인 검증이 도는 순서

:::evidence key="messaging-admin-api-c03-diagram" alt="다이제스트 대조에서 윈도우로 일치가 건너가고 윈도우에서 서명 파싱으로 기간 안이 건너가고 서명 파싱에서 HMAC 으로 형식 통과가 건너간다" caption="승인 검증이 도는 순서" zoom="false"
:::

**다이제스트 대조 → 윈도우 → 16진 파싱 → HMAC**. 다이제스트를 먼저 보는 이유가 주석에 있다.

## ApprovedReplayPlan 참조 위치

:::evidence key="messaging-admin-api-c03" alt="코드베이스에서 ApprovedReplayPlan 를 검색한 출력 11줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ApprovedReplayPlan 코드베이스 검색 — 11줄 · exit 0" zoom="true"
:::

## 검증하는 쪽은 반드시 서명할 수도 있다

`sign(...)` 이 같은 클래스에 public 으로 있고, javadoc 이 그 위험을 스스로 명시한다. 이 문장과 대칭키 선택이 만드는 구조적 결과가 §17 의 한 항목이다.

## javadoc 이 세지 않는 두 검사

실제 분기는 여섯이다. 5번에는 별도 인라인 주석이 있어 의도된 검사임이 분명하다. "검사는 있는데 클래스 javadoc 이 세지 않는" 두 항목이, 동시에 **어떤 테스트에도 도달하지 않는** 두 항목이다(`EVD-303`, §12.1).

## dry run 을 항상 허용하는 근거

"the way to make operators plan before they act is to make planning free". 이것은 보안 완화가 아니라 행동 설계다.

## 토폴로지를 두 번 보는 이유

`ApprovedReplayPlan` 생성자(`:19-52`)와 `requireExecutable(now, currentTopologyVersion)`(`:54-85`)이 토폴로지를 **두 번** 본다. 승인이 서명된 토폴로지와 계획이 계산된 토폴로지가 다를 수 있으므로 둘 다 현재와 대조한다.

## 진행처럼 보이는 루프

`ApprovedRedrivePlan` 은 같은 네 검사에 더해 `loopAcknowledged` 를 별도 필드로 갖고, `requireExecutable` 의 마지막 분기가 그것을 강제한다. "진행처럼 보이는 루프" 는 이 리프에서 반복되는 관점이다 — 대시보드에서 옳아 보이는 실패를 타입으로 막는다.

<!-- body:end -->