Go는 Java, C++, JavaScript, Python과 같은 언어와 비교해 오류를 다루는 방식이 비교적 다릅니다. Go에서 오류는 내장된 error 타입의 값이며, 함수는 일반적으로 다른 반환값과 함께 오류를 호출자에게 반환합니다. 따라서 오류를 검사하고 처리하는 일은 별도의 예외 메커니즘으로 넘겨지는 대신 프로그램 흐름에 명시적으로 포함됩니다.
Christoph Berger라는 커뮤니티 기여자가 처음 작성한 뒤 JetBrains Go 블로그로 옮겨진 JetBrains 가이드는 입출력, 네트워크, 데이터 검증 등의 오류를 처리하기 위한 여러 기법과 실천 방법을 소개합니다. 이 가이드는 Go 언어의 최신 변경 사항을 반영하기 위해 2026년 8월에 업데이트되었습니다.
반환이 출발점이다
함수가 문제를 처리하기에 충분한 맥락을 갖고 있지 않다면 오류를 호출한 함수에 반환해야 합니다. Go에서는 일반적으로 오류 값을 반환 목록의 마지막에 둡니다. 예를 들어 ReadFile()과 같은 함수는 파일 내용과 오류를 반환하며, 성공하면 오류 값은 nil이고 실패하면 다른 값이 됩니다.
가이드는 호출자가 오류를 무시하지 말고 즉시 검사해야 한다고 설명합니다. 함수가 파일이나 네트워크 연결과 같은 리소스를 열었다면 종료할 때 정리하도록 defer를 사용해야 합니다. 다만 먼저 열기 작업이 성공했는지 확인해야 합니다. 유효하지 않은 리소스를 닫으려 하면 추가 문제가 발생할 수 있기 때문입니다.
오류 구조를 손상시키지 않고 맥락 추가하기
오류는 처리되거나 기록되기 전에 여러 함수로 이루어진 연쇄를 거칠 수 있습니다. 이 과정에서 각 함수는 실패한 작업이나 처리 중이던 경로와 같은 유용한 정보를 추가할 수 있습니다. 그러나 err.Error()를 문자열로 변환해 결합하면 오류 체인과 오류의 유형 구조가 손실됩니다.
올바른 방법은 fmt.Errorf()를 %w 동사와 함께 사용해 원래 오류를 보존하면서 오류를 래핑하는 것입니다. 그러면 이후 errors.Unwrap()으로 한 단계 아래에 접근하거나, errors.Is()와 errors.As()로 래핑 체인 안의 특정 오류를 검사할 수 있습니다. Go 1.26에는 As()를 타입 측면에서 더 안전하게 대체하는 일반 함수 errors.AsType()가 추가됩니다. 이 함수는 일치하는 오류와 불리언 값을 반환하며, 이전 방식에서는 실행 시점에 나타날 수 있는 타입 오류를 컴파일러가 발견할 수 있도록 합니다.
여러 오류와 취소된 맥락
오류가 항상 선형적인 체인을 이루는 것은 아닙니다. 예를 들어 여러 파일을 처리할 때 일부 작업은 성공하고 다른 작업은 실패할 수 있습니다. Go 1.20부터 제공되는 표준 패키지의 errors.Join()은 여러 오류를 하나의 값으로 결합하면서 성공적으로 처리된 내용도 보존합니다.
가이드는 errors.Unwrap()이 하나의 값만 반환하므로 결합된 오류를 처리할 때 nil을 반환한다고 설명합니다. 결합된 오류에 접근하려면 해당 값이 Unwrap() []error를 제공하는 인터페이스를 구현하는지 확인해야 합니다. 또한 Go 1.20부터 context.WithCancelCause()를 사용해 사용자 지정 원인을 맥락 취소와 연결한 뒤, 일반적인 context.Canceled 값에만 의존하지 않고 context.Cause(ctx)를 통해 그 원인을 가져올 수 있습니다.
panic은 언제 적절한가?
panic과 recover는 오류 검사를 일상적으로 대신하는 수단이 되어서는 안 됩니다. 유효하지 않은 사용자 입력, 누락된 파일, 네트워크 시간 초과와 같이 예상 가능한 오류는 정상적인 반환 경로를 통해 처리하고 반환해야 합니다.
문제가 예상 밖이고 의미 있는 처리 방법이 없을 때는 panic이 적절합니다. 예를 들어 사전에 유효성을 확인했어야 하는 고정 정규 표현식의 컴파일이 실패하는 경우가 이에 해당합니다. HTTP 서버에서는 가능한 경우 recover()를 지연된 함수 안에서 사용해 현재 요청 처리가 중단되더라도 다른 요청에 영향을 주지 않도록 할 수 있습니다. 반면 메모리 부족과 같은 상황에서는 애플리케이션이 계속 실행할 실질적인 선택지를 갖지 못할 수 있습니다.
개발자에게 실질적으로 중요한 점은 무엇인가?
- 오류를 무시하지 마세요: 오류 값을 빈 식별자에 할당하거나 유일한 반환값을 버리면 문제 발견이 늦어지고 이후에 나타나는 영향을 진단하기 어려워질 수 있습니다.
- 적절한 곳에서 기록하세요: 함수는 오류를 처리하거나 호출자에게 반환해야 합니다. 가이드는 라이브러리가 자체적으로 기록하는 것을 피하라고 권장합니다. 라이브러리 사용자가 다른 로그나 출력 대상을 선호할 수 있기 때문입니다.
- 적절한 타입을 사용하세요: 사용자 지정 오류 타입은 추가 정보를 담을 수 있습니다. fs.PathError는 작업, 경로, 내부 오류를 제공하는 예입니다.
- 네트워크 오류를 구분하세요: net.OpError를 사용하면 연결 실패의 성격을 검사할 수 있으며, 일시적인 오류라면 재시도하거나 지수 백오프와 같은 전략을 사용할 수 있습니다.
- 입출력 작업에서 바이트 수를 활용하세요: io.Reader 인터페이스는 오류와 함께 처리된 바이트 수를 반환하므로 모든 데이터를 다시 처리하지 않고 작업을 재개하는 데 도움이 될 수 있습니다.
- io.EOF에 유의하세요: 패키지의 의미 체계에 따르면 이 값은 읽기 스트림의 정상적인 끝을 나타내며, 반드시 일반적인 오류로 기록해야 하는 실패를 의미하지는 않습니다.
- log.Fatal()을 무분별하게 사용하지 마세요: 이 함수는 os.Exit()를 호출해 지연된 함수를 건너뛰므로, 가이드는 사용을 제한하거나 main() 함수에서 os.Exit()를 사용할 것을 제안합니다.
certi.news의 편집상 결론은 오류 경로를 명확하게 만드는 것이 단순히 장황한 코딩 스타일이 아니라 프로그램 설계의 일부라는 점입니다. 체계적인 래핑, 적절한 타입, 책임 있는 로깅은 진단을 실행 가능한 수준으로 만들지만, panic이나 일반적인 메시지에 의존하거나 오류를 버리면 나중에 개발자에게 필요한 정보가 숨겨집니다. 실질적인 선택은 여전히 애플리케이션의 맥락에 달려 있습니다. 요청 서버에는 제한적인 복구가 필요할 수 있지만, 복구할 수 없는 오류는 종료와 재시작을 요구할 수 있습니다.