defer 함수 안에서 helper를 통해 recover를 호출하면 왜 panic을 잡지 못할 수 있나요?

표준 Go의 직접 호출 규칙에서는 helper 안의 recover()가 panic을 회복하지 못합니다. recover가 유효하려면 panic이 진행 중인 같은 고루틴에서 deferred function이 실행되고, 그 deferred function의 호출 본문에서 recover()가 직접 평가되어야 합니다.

func helper() any { return recover() }
func f() {
    defer func() { _ = helper() }()
    panic("boom")
}

T0에 f가 closure를 defer stack에 등록합니다. T1에 panic이 발생하고 closure가 실행됩니다. T2에 closure는 helper를 호출하지만 recover를 평가하는 frame은 helper입니다. 이 직접 deferred-call 조건을 만족하지 않으므로 helper의 결과는 nil이고 panic은 계속 unwind하여 프로세스의 panic 처리로 갑니다. 즉 “잡지 못할 수도 있다”가 아니라 이 단순한 간접 형태에서는 잡지 못하는 것이 규칙입니다.

안전한 형태는 deferred closure 자체가 recover를 호출하고, 필요한 로깅·변환 helper에는 값을 인자로 전달하는 것입니다. defer func(){ if v := recover(); v != nil { report(v) } }()처럼 쓰면 closure에서 recovery가 성립합니다. 함수값이나 wrapper를 한 단계 더 넣었을 때 같은 결론을 확대하려면 대상 Go spec과 실제 toolchain을 고정해 따로 시험해야 합니다. 이 예제에서 helper가 nil을 돌려준 직후 closure가 끝나도 panic 상태는 소멸하지 않으므로, 다음 caller 문장이 실행된다고 기대할 수 없습니다. recover 실패를 성공 반환으로 바꾸지 말고 worker 경계에서 panic 값과 stack을 기록해야 부분 side effect를 놓치지 않습니다.