퀴즈: 변경 결과를 증거로 설명하기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 승인 ID는 1·2·5, 감사 ID는 1·2·31이며 각각 세 건이다. 어떻게 보고해야 하는가?

   1. 세 건씩 맞으므로 전체 완료이며 ID 차이는 표현상의 차이로 처리한다.
   2. 승인 밖 31과 감사가 없는 5를 분리해 조사할 항목으로 남긴다.
   3. 현재 주문 수가 세 건이면 승인 목록을 감사 ID로 덮어써 일치시킨다.
   4. 31을 5로 자동 변환하면 보고 건수를 유지하면서 문제를 해결할 수 있다.

2. 기본 Read Committed에서 BEGIN 뒤 승인·감사·현재 행을 순서대로 SELECT했다. 무엇을 주의해야 하는가?

   1. 같은 연결의 조회이므로 다른 연결의 커밋은 어떤 경우에도 보이지 않는다.
   2. SELECT가 여러 번이면 데이터가 자동 잠겨 모든 업무 변경이 차단된다.
   3. BEGIN만 있으면 세 쿼리는 항상 첫 번째 조회 순간의 값을 반환한다.
   4. 다른 연결이 중간에 커밋하면 문장마다 다른 시점의 자료가 섞일 수 있다.

3. 감사는 승인과 정확히 맞지만 현재 행의 revision이 감사의 이후 revision보다 크다. 이번 분류는?

   1. 과거 확정은 인정하되 현재는 후속 차이로 분리하고 완료 주장을 보류한다.
   2. 현재 상태 문자열만 cancelled이면 revision 차이를 무시하고 일치로 센다.
   3. 과거 확정 자체가 없었던 것으로 간주해 감사와 승인 ID를 모두 삭제한다.
   4. 보고서 생성 중 현재 revision을 감사 값으로 낮춰 원래 상태를 만든다.

4. 누군가 보고 판정을 complete로 바꾸고 해시도 다시 계산했다. 필요한 검사는?

   1. 해시가 새 내용과 맞으면 변경 승인과 실행 근거를 보지 않아도 된다.
   2. 파일 크기가 원본과 비슷하면 문장 편집으로 보고 그대로 허용한다.
   3. 원 증거에서 기계 판정과 고객 설명을 다시 계산해 번들과 비교한다.
   4. UTC 시각이 있으면 작성자를 인증한 것이므로 판정을 신뢰할 수 있다.

5. 완성 바이트를 임시 파일에 썼지만 os.replace 전에 예외가 났다. 요구한 결과는?

   1. 보고가 시작됐으므로 이전 파일을 지우고 빈 파일을 최종 결과로 남긴다.
   2. 기존 완성본을 보존하고 이번 호출이 만든 임시 파일만 정리한다.
   3. 이전 파일을 새 파일 앞에 붙여 두 보고서의 내용을 모두 유지한다.
   4. 실패한 파일을 정상 이름으로 바꾸고 사용자가 다시 읽게 한다.

6. 저장된 보고서의 해시와 내부 대조가 모두 통과했다. 어떤 주장을 할 수 있는가?

   1. DB가 지금도 같은 상태이고 보고서를 만든 사람이 정당한 담당자임을 증명했다.
   2. 관측 시각을 공격자가 바꿀 수 없으므로 별도 수집 경로 확인은 필요 없다.
   3. 전체 고객 시스템의 상태가 동시에 수집됐으므로 외부 API도 검증됐다.
   4. 이 형식의 바이트·증거·결론이 내부적으로 맞지만 현재 상태나 출처 인증은 별도다.