퀴즈: 승인한 두 건은 아무 두 건이 아니다

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

1. 아침에 승인받은 대기 주문은 2건입니다. 오후에도 대기 주문이 2건이면 그대로 취소해도 되나요?

   1. 아니다. 고객·ID·버전·수량이 승인 내용과 같은지 확인한다
   2. 그렇다. 건수가 같으면 변경의 영향 범위도 같다고 본다
   3. 그렇다. 같은 WHERE 조건을 사용했다면 새 주문도 승인된 것이다
   4. 아니다. 새 주문을 포함하도록 기존 승인 목록을 자동 갱신한다

2. 승인 때 qty=7, revision=3이었고 지금 qty=7, revision=5입니다. 이 실습의 올바른 판단은?

   1. 수량이 같으므로 승인한 사실이 그대로라고 판단한다
   2. 버전이 달라졌으므로 현재 사실을 다시 확인하고 승인을 검토한다
   3. revision을 3으로 되돌리고 기존 승인을 그대로 실행한다
   4. 수량이 같으므로 나머지 고객 조건은 생략하고 처리한다

3. 승인 목록에 같은 주문 ID가 두 번 들어 있습니다. 검증기는 어떻게 처리하나요?

   1. 같은 주문을 두 번 취소하고 두 번의 변경으로 센다
   2. 마지막 항목만 남겨 입력 충돌을 조용히 해결한다
   3. 중복 대상을 ValueError로 거부하고 입력을 보존한다
   4. 첫 항목을 적용한 뒤 두 번째 항목의 실패만 무시한다

4. validate_targets가 새 list를 만들었지만 내부 dict는 입력과 공유합니다. 어떤 문제가 남나요?

   1. ID 정렬이 반드시 역순이 되어 SQL 문법 오류가 난다
   2. PostgreSQL이 같은 객체 주소를 보고 요청을 중복 제거한다
   3. 반환 목록이 비어 있지 않으므로 검증의 의미가 없어진다
   4. 반환 항목을 수정한 코드가 원래 승인 입력까지 바꿀 수 있다

5. 왜 주문 번호 True를 정수 1처럼 받아들이지 않나요?

   1. 논리값이 번호로 해석되는 승인 입력 오류를 막기 위해서다
   2. PostgreSQL의 모든 정수 열이 1을 금지하기 때문이다
   3. Python에서 True는 언제나 문자열로 저장되기 때문이다
   4. 동일한 주문의 재시도는 반드시 다른 번호여야 하기 때문이다

6. 함수에 tenant='blue'를 전달하면 호출자의 blue 고객 데이터 변경 권한도 검증되나요?

   1. 그렇다. 문자열이 SQL 조건에 들어가면 로그인 검증도 수행된다
   2. 아니다. 고객 범위 조건과 호출자의 권한 검증은 별도 책임이다
   3. 그렇다. 변경 ID가 고유하면 모든 고객의 데이터를 바꿀 수 있다
   4. 아니다. 권한 검증을 위해 tenant 조건은 UPDATE에서 빼야 한다