Go 코드의 절반이 nil 체크라면? 방어 코딩의 함정

Go 코드의 절반이 nil 체크라면

Go로 서버나 CLI 도구를 좀 짜보신 분들은 이런 코드를 자주 보셨을 거예요. 함수 맨 위에 if arg == nil { return err }가 줄줄이 붙어 있고, 구조체 필드 하나 쓸 때마다 또 if s.Field != nil로 감싸고... nil 체크가 정작 중요한 로직보다 더 많은 자리를 차지하는 코드 말이에요. Konrad Reiche라는 개발자가 'Go엔 nil 체크가 과하게 많다'는 글을 썼는데, 우리가 평소 무심코 하던 방어 코딩 습관을 다시 돌아보게 만드는 내용이라 같이 풀어볼게요.

일단 nil이 뭐냐면

Go에서 포인터, 인터페이스, 맵, 슬라이스, 채널, 함수 타입은 아무 값도 안 들어있을 때 기본값이 nil이에요. 다른 언어의 null이랑 비슷한 친구죠. 문제는 nil 포인터를 그냥 역참조하면(가리키는 값을 꺼내 쓰려고 하면) 프로그램이 panic을 내면서 그 자리에서 죽어버린다는 거예요. 그러니 '혹시 nil이면 어떡하지?' 하는 불안감에 다들 곳곳에 체크를 박아두게 되는 거죠. 마음은 이해돼요. 한 번 데여보면 안 박을 수가 없거든요.

핵심은 '이 체크가 진짜 필요한가'

글이 짚는 핵심은 이거예요. 모든 nil 체크가 다 필요한 건 아니라는 거죠. 예를 들어 어떤 구조체를 항상 NewServer() 같은 생성자 함수로만 만든다고 해볼게요. 그 생성자가 내부 필드를 무조건 채워서 돌려준다면, 그 필드는 사실상 절대 nil이 될 수 없어요. 그런데도 그 필드를 쓸 때마다 nil인지 확인하는 건, 일어날 수 없는 일을 대비하느라 코드만 지저분해지는 셈이거든요.

여기서 나오는 사고방식이 바로 'fail fast(빠르게 실패하기)'예요. 만약 그 필드가 정말 nil이라면, 그건 사용자 입력 문제가 아니라 프로그래머가 코드를 잘못 짠 버그예요. 그런 버그는 조용히 넘어가게 하지 말고 차라리 panic으로 시끄럽게 터뜨려서 개발 단계에서 바로 잡는 게 낫다는 거죠. 진짜 nil 체크가 필요한 곳은 따로 있어요. 외부에서 들어오는 입력값, 맵 조회 결과(v, ok := m[key]), 일부러 '있을 수도 없을 수도 있는' optional 필드 같은 경계 지점이요. 이런 데서만 꼼꼼히 막고, 내가 보장한 불변 조건(invariant) 안쪽에서는 믿고 가자는 겁니다.

Go 특유의 함정 하나

여기서 Go의 악명 높은 함정도 짚고 갈게요. 인터페이스에 nil 포인터를 담으면, 그 인터페이스 자체는 nil이 '아니'게 돼요. var p *MyType = nil을 인터페이스 변수에 넣고 iface == nil로 비교하면 false가 나오거든요. 인터페이스는 (타입, 값) 한 쌍으로 이뤄지는데, 값은 nil이어도 타입 정보가 들어있어서 그래요. 이거 모르고 nil 체크 했다가 통과돼버려서 결국 panic 나는 경우가 정말 많아요. 그러니 nil 체크를 '많이' 하는 게 안전한 게 아니라, '제대로' 하는 게 중요하다는 거죠.

다른 언어는 어떻게 풀까

이 문제는 사실 Go가 언어 차원에서 null 안전성을 안 챙겨서 생기는 면이 커요. Rust는 아예 null이 없고 Option<T>로 '값이 있을 수도 없을 수도 있다'를 타입에 박아버려요. Kotlin이나 Swift는 String?처럼 nullable 타입을 따로 두고, 컴파일러가 체크 안 하면 빌드를 막아주죠. 이런 언어들은 '어디를 체크해야 하나'를 컴파일러가 강제해주니까, 사람이 감으로 방어 코딩할 일이 줄어요. Go는 이런 장치가 없으니 결국 팀의 규율과 코드 리뷰로 메워야 하는 거고요.

한국 개발자에게

쿠버네티스, Docker, 그리고 수많은 백엔드 인프라가 Go로 짜여 있어서 국내에서도 Go 쓰는 팀이 정말 많아졌잖아요. 코드 리뷰 때 '여기 nil 체크 빠진 거 아니야?' 하고 무조건 추가하자고 하기 전에, 한 번쯤 '이게 진짜 nil이 될 수 있는 값인가?'를 같이 따져보면 좋겠어요. 생성자로 불변 조건을 보장하고, 경계에서만 방어하고, 나머지는 믿고 가는 습관. 코드가 훨씬 읽기 편해지고, 정작 중요한 체크가 노이즈에 묻히지 않거든요.

정리하면 nil 체크는 많을수록 안전한 게 아니라, 꼭 필요한 곳에 정확히 있을 때 안전합니다. 여러분 팀 코드베이스엔 '습관적으로 박아둔' nil 체크가 얼마나 될 것 같으세요?