핵심 정리
- 영수증은 원본 결과를 공개하지 않고도 기록된 요청, 연산, 결과 해시, 사용량, 시점을 식별합니다.
- 해시 연결은 순서를 보존하며 연결된 한 기록을 바꾸면 뒤의 관계가 깨집니다.
- 머클 증명은 모든 영수증을 내보내지 않고도 특정 영수증이 배치에 포함됐는지 확인합니다.
요청 단위 영수증의 역할
영수증은 결과에 이의가 생겼을 때 고객이 조회하고 인용할 수 있는 기본 단위입니다. 안정적인 식별자와 기록 해시를 다시 계산할 수 있는 정규화 필드를 포함해야 합니다. 민감한 업무 데이터는 영수증 밖에 두거나 해시로 표현하는 편이 안전합니다.
모든 랜덤 바이트에 장기 증빙이 필요한 것은 아니므로 영수증 생성을 선택할 수 있습니다. 다만 정책은 명확해야 합니다. 영수증을 켠 요청은 정상적으로 기록하거나 명확한 실패를 반환해야 하며, 한도 초과 뒤 조용히 증빙만 누락해서는 안 됩니다.
해시 연결은 순서 변경을 드러냅니다
각 영수증에 같은 무결성 범위의 이전 영수증 해시를 포함하면 과거 기록의 순서를 바꾸거나 삭제하거나 수정했을 때 뒤의 연결 관계가 달라집니다. 모든 운영 장애를 막는 구조는 아니지만 사후 편집의 한 유형을 검증 과정에서 발견할 수 있습니다.
범위도 중요합니다. 고객별 체인을 사용하면 다른 고객의 기록을 공개하지 않고 해당 고객의 흐름을 확인할 수 있습니다. 검증 도구는 체인 식별자와 예상 순서 규칙을 알아야 합니다.
머클 증명은 배치 검증 비용을 줄입니다
머클 트리는 영수증 해시를 단계적으로 결합해 하나의 루트로 배치를 대표합니다. 특정 영수증의 포함 여부를 증명할 때는 영수증 해시와 경로의 이웃 해시, 루트만 있으면 됩니다. 검증 도구는 경로를 다시 계산해 결과 루트가 같은지 비교합니다.
이 증명은 기록된 배치에 영수증이 포함됐음을 보여줍니다. 루트를 별도 위치에 보관하거나 서명하거나 독립된 곳으로 전달하면 보증 범위가 넓어집니다. 같은 변경 가능한 시스템 안에만 루트가 있다면 독립성은 제한됩니다.
보관, 내보내기, 삭제는 하나의 정책으로 관리합니다
영수증 보관 기간은 고객의 검토 가능 기간과 계약에 맞춰야 합니다. 만료 작업은 영수증 본문뿐 아니라 관련 색인, 내보내기 파일, 복구 가능한 백업까지 같은 정책으로 처리해야 합니다. 삭제 전에 영수증, 체인 필드, 머클 증명, 검증 방법을 묶어 내보내는 절차가 필요할 수 있습니다.
- 정상 검증과 필드 변조 검증을 함께 시험합니다.
- 내보내기 생성과 다운로드도 감사 가능한 활동으로 기록합니다.
- 해시와 서명 알고리즘을 버전과 함께 공개합니다.
- 영수증 처리 실패와 DLQ 재처리 절차를 준비합니다.