부모 고루틴의 recover로 자식 고루틴 panic을 잡을 수 없는 이유는 무엇인가요?

panic unwind는 고루틴별 호출 stack 안에서만 진행됩니다. 부모 고루틴에 defer func(){ recover() }()를 등록해도 go worker()로 시작한 자식 고루틴의 stack이 부모 frame을 통과하지 않으므로 자식 panic을 회복하지 못합니다. 부모가 channel을 읽는 것도 stack recovery가 아니라 통신일 뿐입니다.

errs := make(chan error, 1)
go func() {
    defer func() {
        if v := recover(); v != nil { errs <- fmt.Errorf("worker: %v", v) }
        close(errs)
    }()
    doWork()
}()
err := <-errs

T0에 parent가 자신의 defer를 등록하고 T1에 child를 시작합니다. T2에 child에서 panic이 나면 child defer만 후보가 됩니다. child defer가 직접 recover하면 T3에 panic을 error로 바꾸어 channel로 보내고 종료합니다. parent는 T4에 error를 읽고 context 취소나 다른 worker 정리를 결정합니다. child에 recovery가 없으면 parent의 defer는 실행되지 않고 panic은 process-level 장애가 될 수 있습니다.

복구는 외부 side effect rollback이 아닙니다. child가 DB commit이나 API 호출을 끝낸 뒤 panic하면 그 효과는 남을 수 있으므로 transaction, idempotency key, 보상 상태가 필요합니다. 반복 작업이라면 recover한 panic을 재시작 가능한 오류와 영구 실패로 분류하고, channel close owner를 worker supervisor로 명시해 송신과 close 경쟁도 막아야 합니다. 예를 들어 child가 buffered channel에 한 번만 오류를 보내고 종료하게 하면 parent가 늦게 읽어도 recovery 경계가 송신에서 막히지 않습니다. 여러 worker가 같은 channel을 쓸 때는 각 worker가 close하지 않고 supervisor만 종료 시점을 결정해야 합니다.