Go, nil 체크 범람? 근본적인 설계 문제 지적

본문은 생성자에서 nil 의존성을 체크하는 코드가 실제 오류 발생 지점(초기화 시점)을 은폐한다고 지적한다. 이는 실패 즉시 알림(Fail Fast) 원칙에 위배되며, 침묵하는 실패(Silent Failure)를 야기하여 디버깅을 어렵게 만든다고 설명한다. 커뮤니티에서는 이러한 초기화 오류(Initialization Errors)를 에러 래핑(Error Wrapping)을 통해 명확히 전달해야 한다는 의견이 제시되었다.

글은 프로그램의 불변성(Invariants)을 확립하는 것이 중요하다고 강조한다. 외부 입력은 신뢰할 수 없는 경계(Untrusted Boundary)로 간주하여 검증해야 하지만, 일단 시스템 내부로 들어온 값은 신뢰할 수 있는 내부 데이터(Trusted Inner-Layer Data)로 간주해야 한다는 것이다. 과도한 nil 체크는 이러한 내부 신뢰성(Internal Trust)을 저해하며, 코드의 복잡성을 증가시킨다고 분석한다.

커뮤니티에서는 Go의 모든 포인터가 nil을 허용하는 점이 근본적인 문제라는 지적이 나왔다. Rust의 `Option` 타입이나 C#의 nullable 타입과 달리, Go는 컴파일러 수준에서 nil 가능성을 명시적으로 관리하지 않아 개발자의 머릿속 추론에 의존하게 된다는 비판이다. 이는 명시적 계약(Explicit Contracts) 부재로 이어져, 에러 래핑(Error Wrapping) 시에도 문자열 검색에 의존하는 등 비효율을 초래한다고 언급된다.

에러 래핑은 오류 발생 지점의 컨텍스트를 누적하여 전달하는 유용한 기법으로 논의되었다. 하지만 `fmt.Errorf`의 `%w` 사용 시, 실제로는 에러 문자열 검색에 의존하게 되어 통일된 스택 트레이싱(Unified Stack Tracing) 부재가 문제로 지적되었다. 일부에서는 고유 에러 코드(Unique Error Codes)를 부여하는 방식을 대안으로 제시했으나, 이는 수동 관리의 번거로움이 따른다는 단점이 있다.

오류를 무시하고 계속 진행하는 '침묵하는 실패'는 장기적인 비용(Second-Order Cost)을 발생시킨다고 지적한다. 이는 관찰 가능성(Observability) 인프라 구축에 엔지니어링 노력을 낭비하게 만들며, 근본적인 원인 파악을 어렵게 한다. 따라서 오류는 명확하게 전달(Loud Failure)되어야 하며, 시스템의 오류 처리 경계(Error Handling Boundary)를 신중하게 설계해야 함을 강조한다.