Go select에서 취소 채널과 작업 채널이 동시에 준비되면 취소가 항상 먼저 선택되나요?

select는 여러 통신이 준비되면 그중 하나를 선택하며 취소 분기를 위에 적었다고 우선순위가 생기지 않습니다. 취소 후 작업을 절대 시작하지 않아야 하는 계약은 별도의 실행권·상태 검사로 설계해야 합니다.

동작 원리와 전제

ctx.Done과 jobs 수신이 모두 가능하면 작업을 받을 수 있습니다. 수신 직후 취소를 다시 확인하면 불필요한 실행을 줄일 수 있지만 검사와 외부 효과 사이 경쟁까지 원자적으로 막지는 않습니다. 엄격한 실행 금지에는 상태 전이와 변경 경계의 조건이 필요합니다.

선택과 실패 처리

닫힌 채널은 계속 준비된 상태가 되므로 ok 값을 처리하지 않으면 루프가 busy-spin할 수 있습니다. nil 채널은 해당 분기를 비활성화하는 용도로 쓸 수 있지만 종료 조건을 잊으면 영구 대기가 됩니다.

구체적인 사례와 검증

취소를 최우선으로 처리하려고 select 앞에서 ctx.Err를 확인할 수는 있지만 그 검사 직후 취소가 올 수 있습니다. 따라서 '시작을 최대한 줄인다'와 '취소 이후 어떤 효과도 절대 없다'는 보장을 나눠야 합니다. 후자는 실행권 상태나 저장소의 조건을 함께 확인해야 합니다. 닫힌 jobs 채널에서 값을 받으면 zero value와 ok=false를 구분하고 정상 종료합니다. 수신 채널을 nil로 바꿔 분기를 제거하는 경우 나머지 이벤트가 영원히 오지 않을 수 있어 종료 조건을 따로 둡니다. 준비된 통신의 선택 규칙에 애플리케이션 우선순위를 암묵적으로 기대하지 않겠습니다.

동시 준비·취소 직후 수신·채널 close·빈 큐를 결정적으로 시험합니다. 취소는 완료 결과와 경쟁할 수 있고 외부 변경 rollback이 아닙니다. select의 선택 의미와 애플리케이션의 작업 수명·우선순위를 분리해서 설명하겠습니다.