기타 Lobsters · 2일 전

"널(null) 포인터는 10억 달러짜리 실수? 사실 제일 잡기 쉬운 버그인데"

핵심 요약
  • '10억 달러짜리 실수'로 불리는 널(null) 포인터에 대해 시스템 언어 Odin 개발자가 사실상 업계 기준 과장된 표현이라고 반박했습니다.
  • 널 포인터는 런타임에 가장 쉽게 감지되고 잡히는 사소한 버그인 반면, 실제 시스템 언어에선 '해제 후 사용' 등 다른 메모리 오류가 훨씬 심각하다고 지적했습니다.
  • 널을 없애기 위해 모든 변수를 강제 초기화하거나 래핑 타입을 강제하는 것은 시스템 레벨 개발에서 오히려 큰 비효율을 낳는다고 설명했습니다.
요약 1965년 널 참조(Null Reference)를 고안했던 토니 호어(Tony Hoare)는 이를 두고 수많은 시스템 충돌과 취약점을 낳은 ‘10억 달러짜리 실수(Billion Dollar Mistake)’라고 자책한 바 있습니다. 하지만 시스템 프로그래밍 언어 오딘(Odin)의 개발자 진저빌(gingerBill)은 이에 대해 정면으로 반박하는 글을 남겼습니다. 40년 넘는 세월 동안 IT 업계 전체에서 10억 달러 규모의 피해라면 사실상 오차 범위 수준의 과장에 불과하다는 지적입니다. 저자는 실무 관점에서 널 포인터 역참조가 메모리 안전하지 않은 언어에서 발생하는 유효하지 않은 메모리 주소 오류 중 가장 흔하지 않으며, 런타임에 가장 잡아내기 쉬운 부류라고 설명합니다. 대부분 오타 수준의 사소한 실수로 발생해 찾아서 고치기 쉬운 반면, 실제로 시스템 프로그래밍(C나 Odin 등)에서 훨씬 심각하고 흔한 문제는 해제 후 사용(use-after-free), 잘못된 포인터 연산, 매핑되지 않은 메모리 접근처럼 단순하게 해결하기 어려운 문제들이라는 것입니다. 널 포인터를 문제 삼는 것은 마치 술 취한 사람이 열쇠를 잃어버리고는 가로등 밑이 밝다는 이유로 거기서만 열쇠를 찾는 것과 같다고 비유했습니다. 또한 널 포인터를 원천 제거하려는 해결책에는 개발 언어 설계상 결코 가볍지 않은 트레이드오프가 따른다고 분석했습니다. 기본적으로 널 상태를 허용하지 않으려면 매번 사용할 때마다 포인터를 검사하게 하거나, 모든 값을 어디서나 명시적으로 초기화해야 합니다. 하지만 모든 변수의 강제 초기화나 널 방지 제약은 커스텀 메모리 할당자 구현처럼 시스템 프로그래밍에서 의도적으로 위험한 상태를 다뤄야 하는 작업을 지나치게 복잡하게 만듭니다. 결국 옵션/메이비(Option/Maybe) 타입 등으로 널을 억제하는 유행이 시스템 레벨 프로그래밍의 실무 현실과는 거리가 있을 수 있다는 개발자의 소신입니다.
Sponsored · 광고