개발자라면 누구나 한 번쯤 겪어봤을 공포가 있습니다.
바로 NPE(Null Pointer Exception)입니다.
자바에서는 NPE, C언어에서는 세그먼테이션 폴트(Segmentation Fault)라고 불리죠.
앱이 갑자기 툭 꺼져버리거나, 서버 로그에 시뻘건 에러가 줄줄이 찍히는 그 순간.
정말 식은땀이 흐릅니다.
이 널(Null) 참조를 만든 토니 호어(Tony Hoare) 경은 2009년에 이렇게 말했습니다.
"그것은 나의 10억 달러짜리 실수(Billion Dollar Mistake)였다."
구현하기 너무 쉬워서 그냥 넣었는데, 그게 수많은 시스템 오류와 보안 취약점을 만들었다는 거죠.
저도 주니어 시절엔 이 말을 철석같이 믿었습니다.
"아, Null은 악의 축이구나. 무조건 없애야 하는구나."
그런데 10년 넘게 시스템 프로그래밍을 하고, 밑바닥 메모리까지 다루다 보니 생각이 좀 달라졌습니다.
오늘은 커피 한 잔 하면서 이 'Null의 변명'을 좀 해볼까 합니다.
정말 Null이 그렇게 나쁜 놈일까요?
사실 40년 IT 역사에서 10억 달러 손해는... 솔직히 말해 '반올림 오차' 수준입니다.
요즘 우리가 잘못된 아키텍처나 비효율적인 클라우드 비용으로 날리는 돈이 훨씬 더 크거든요.
진짜 문제는 Null 그 자체가 아닙니다.
우리가 Null을 미워하는 진짜 이유는 '찾기 쉬워서'입니다.
이걸 '술 취한 사람의 등불 원리(Drunkard’s search principle)'라고 부르더군요.
술 취한 사람이 잃어버린 열쇠를 어두운 골목이 아니라 가로등 밑에서 찾는 것과 같습니다.
왜냐고요? 거기가 밝아서 잘 보이거든요.
Null 포인터 오류는 런타임에 아주 시끄럽게 터집니다.
"나 여기서 죽었어!"라고 명확하게 비명을 지르죠.
대부분 오타나 초기화 실수 같은 사소한 버그입니다. 고치기도 쉽습니다.
하지만 제가 C나 Odin 같은 시스템 언어로 개발하면서 진짜 무서웠던 건 Null이 아니었습니다.
정말 무서운 건 '조용히 메모리를 망가뜨리는 놈들'입니다.
이미 해제된 메모리를 다시 사용하는 Use-after-free.
배열의 범위를 벗어나서 엉뚱한 값을 읽는 잘못된 포인터 연산.
이런 버그들은 에러도 안 내고, 데이터만 조용히 오염시킵니다.
나중에 원인을 찾으려 하면 며칠 밤을 새워도 못 찾는 경우가 허다하죠.
이에 비하면 Null 포인터 역참조는 차라리 '애교' 수준입니다.
그럼 요즘 핫한 Rust 같은 언어들처럼 컴파일 타임에 Null을 원천 봉쇄하면 되지 않을까요?
물론 훌륭한 접근입니다.
하지만 여기엔 우리가 간과하기 쉬운 '엔지니어링 트레이드오프'가 숨어 있습니다.
Null을 없앤다는 건, 모든 변수가 태어날 때부터 '명시적 초기화(Explicit Initialization)'를 해야 한다는 뜻입니다.
쉽게 말해, 빈 껍데기 상태를 허용하지 않는 거죠.
안전해 보이죠?
하지만 시스템 레벨에서 보면 이야기가 다릅니다.
커스텀 할당자(Custom Allocator)를 만들거나, 거대한 메모리 블록을 다룰 때 이 제약은 족쇄가 됩니다.
예를 들어봅시다.
운영체제에서 메모리를 받아올 때(mmap 등), 보통 그 메모리는 0으로 채워져 있습니다.
Odin이나 Go 같은 언어는 이 '제로 값(Zero Value)'을 적극적으로 활용합니다.
그냥 0으로 채워진 상태를 '비어있음'으로 약속하고 쓰는 거죠.
성능적으로 이게 훨씬 이득인 경우가 많습니다.
그런데 "모든 것은 초기화되어야 한다"는 규칙을 강제하면?
이미 0으로 잘 채워진 메모리에, 굳이 또 값을 덮어써야 하는 비효율이 발생할 수 있습니다.
컴파일러는 생각보다 멍청합니다.
우리가 설계한 전체 아키텍처의 의도를 모릅니다.
그저 문법적 규칙만 검사할 뿐이죠.
개별 변수의 안전을 챙기려다가, 시스템 전체의 성능이나 유연성을 희생하는 '아키텍처적 불균형'이 생길 수 있다는 겁니다.
물론 웹 애플리케이션이나 비즈니스 로직에서는 Null을 피하는 게 정신 건강에 좋습니다.
하지만 "Null은 무조건 나쁘다"라고 단정 짓는 건 위험합니다.
Null은 단순한 실수가 아니라, '값이 없음'을 표현하는 가장 가볍고 효율적인 센티넬(Sentinel) 값이기도 하니까요.
오늘의 결론
Null을 너무 미워하지 마세요.
그것은 어쩌면 우리에게 가장 솔직하게 위험을 알려주는 고마운 신호등일지도 모릅니다.
진짜 고수는 도구를 탓하기보다, 그 도구가 가진 '양날의 검'을 이해하고 적재적소에 쓰는 사람이 아닐까요?
다음번 코드 리뷰 때 후배가 Null 체크를 빼먹었다면, 10억 달러짜리 실수라고 혼내기보단 이렇게 말해주세요.
"이거 터지면 네가 새벽에 전화 받을 거지?"라고요.
