Go의 recover() 함수는 패닉으로 인한 언와인딩 프로세스의 일환으로 실행되고 있는 지연 함수 내에서 직접 호출될 때만 패닉을 중지합니다. 헬퍼 함수 내에서 생성된 지연 클로저에 의해 호출된 경우 **recover()**를 호출하면 런타임은 현재 고루틴의 실행 프레임이 활성 패닉과 관련된 최상위 지연 프레임이 아니라고 감지합니다.
// 이 패턴은 복구하지 못합니다: func handlePanic() { if r := recover(); r != nil { log.Println("복구됨:", r) } } func risky() { defer handlePanic() // 여기서 recover()는 nil을 반환합니다 panic("error") }
런타임는 이 검사를 g.recover 필드를 통해 유지하며, 이는 복구 권한을 가진 지연 함수의 스택 프레임 포인터를 저장합니다. **recover()**가 실행될 때, 현재 스택 포인터를 이 저장된 값과 비교하며, 일치하지 않으면 **recover()**는 nil을 반환하고 패닉은 스택을 따라 전파됩니다. 이러한 아키텍처 제약은 복구 로직이 명시적이고 국소화되도록 보장하여, 깊게 중첩된 헬퍼 함수가 상위 수준의 복구 핸들러에 전파되어야 하는 패닉을 우연히 잡아내지 못하도록 합니다.
수천 개의 동시 고루틴을 처리하는 고처리량 마이크로서비스에서 우리는 잘못된 요청으로 인한 서버 크래시를 방지하기 위해 중앙 집중식 패닉 복구 메커니즘을 구현했습니다. 초기 구현은 로깅 및 메트릭을 캡슐화한 유틸리티 함수 SafeRecover()를 사용하였으며, 개발자들은 각 핸들러의 시작 부분에서 defer SafeRecover()를 사용했습니다. 그러나 요청 핸들러에서 나누기 0 오류가 발생하는 경우 서비스가 크래시되는 사고가 발생했으며, 이는 분명한 복구 메커니즘에도 불구하고 패닉이 가로채어지지 않았음을 알게 해주었습니다. 이는 **recover()**가 헬퍼 내에 중첩되어 호출된 것이 아니라 직접 호출되었기 때문입니다.
우리는 우선 개발자들에게 각 함수 진입 점에서 수동으로 defer func() { if r := recover(); r != nil { ... } }()를 쓰도록 의무화할 것을 고려했습니다. 이 접근 방식은 런타임 준수를 보장하는 **recover()**에 직접 접근할 수 있었지만, 상당한 보일러플레이트를 도입하고 인간의 일관성에 의존하므로 대규모 팀에서 오류가 발생하기 쉬웠으며 코드 검토 중 시행하기 어려웠습니다.
두 번째 접근 방식은 SafeRecover()를 수정하여 클로저를 인수로 받아서 헬퍼 로직을 호출하기 전에 그 전달된 함수 내에서 **recover()**를 실행하도록 하는 것이었습니다. 이는 기술적으로 **recover()**를 지연 프레임에 배치하여 요구 사항을 충족했지만, 핸들러가 복구 로직을 콜백으로 전달해야 하므로 API가 어색해지고 제어 흐름이 복잡해지며 가독성이 떨어지고 불필요한 간접성이 추가되었습니다.
궁극적으로 우리는 HTTP 라우터 수준에서 미들웨어 래퍼를 구현하여 defer func() { if r := recover(); r != nil { logAndMetrics(r) } }()를 미들웨어의 지연 클로저 내에서 직접 실행하는 세 번째 접근 방식을 선택했습니다. 이 솔루션은 **recover()**가 올바른 스택 깊이에서 호출되도록 보장하면서 문제를 분리하여 처리하며, 향후 혼돈 테스트에서 100% 패닉 가로채기 비율과 후속 분기에 제로 크래시 루프를 기록했습니다.
왜 recover()가 지연 함수 밖에서 호출될 때 nil을 반환하나요? 패닉이 활성화되어 있지 않더라도 말이죠?
지연 실행 컨텍스트 밖에서 **recover()**는 현재 고루틴의 패닉 상태를 조회하고 활성 패닉 레코드가 없음을 찾아 즉시 nil을 반환합니다. 미묘한 점은 **recover()**가 현재 함수가 지연 스택 언와인딩의 일환으로 실행되고 있는지 여부를 확인하는 것이며, 프로그램 어딘가에 패닉이 존재하는지만을 확인하는 것이 아닙니다. 정상 실행 경로에서 호출될 때, 런타임은 고루틴 구조의 _panic 필드가 nil인 것을 찾아 하위 효과 없이 nil을 반환하여 정규 오류 처리가 복구 메커니즘을 유발하는 우발적 오용을 방지합니다.
동일한 고루틴의 여러 지연 함수가 recover()를 호출하면 어떻게 되며, 왜 첫 번째 호출만 성공하나요?
패닉이 발생하면 Go는 지연 함수를 LIFO 순서로 실행하며, **recover()**를 호출하는 첫 번째 지연 함수는 고루틴의 내부 _panic 연결 리스트에서 활성 패닉 상태를 원자적으로 지웁니다. 이후 **recover()**를 호출하는 지연 함수는 패닉이 이미 해결되었음을 발견하여 원래의 패닉 값을 대신 nil을 반환하게 됩니다. 이 설계는 가장 깊은 복구 범위가 우선하는 결정론적 패닉 처리를 보장하고, 스택이 정상 실행으로 복원된 후 오류 전파 논리를 혼란스럽게 할 수 있는 중복 복구 시도를 예방합니다.
panic(nil)의 동작은 panic("nil") 또는 panic(0)와 어떻게 다르며, 왜 Go 1.21이 이 동작을 변경했나요?
Go 1.21 이전에 **panic(nil)**을 호출하면 런타임이 패닉 값을 특별한 센티넬로 처리하여 **recover()**가 nil로 반환하게 하여 패닉을 처리할 항목이 없는 recover() 호출과 구별할 수 없게 하여 위험한 모호성을 생성했습니다. Go 1.21과 이후에서는 런타임이 nil 패닉 값을 자동으로 "runtime error: panic called with nil argument" 문자열을 포함하는 비-널 런타임 오류로 변환하여 **recover()**가 패닉을 성공적으로 가로챌 때 항상 비-널 값을 반환하도록 보장합니다. 이 변경은 오류 처리 코드에서 모호성을 제거하여 개발자들이 if r := recover(); r != nil을 안전하게 확인할 수 있도록 하여 반환된 nil이 진정으로 패닉이 발생하지 않았음을 나타낸다는 것을 보장했습니다.