소프트웨어 개발을 하시는 분이나, 아니면 일반인(?) 여러분이라도 프로그램이 오류로 종료되었을 때 오류 메시지를 잘 살피신 분이라면, '널 포인터'(null pointer)라는 것을 들어 보신 적이 있을 것입니다.

프로그램을 만들 때, 프로그래머들은 거대한 컴퓨터 메모리를 수많은 조각으로 잘라서 이 조각은 이 용도, 저 조각은 저 용도로 사용하기로 정해 둡니다. 스타크래프트를 예로 들면, 전체 메모리 8기가바이트를 잘개 잘라서, 이쪽 4바이트는 유닛 체력에 쓰고, 저쪽 4바이트는 채취한 광물의 양을 나타내는 데 쓰고, 또 저쪽 8바이트는 유닛의 초당 대미지를 저장하는 데 쓴다는 것이죠.

이때 널 포인터란 '데이터가 아직 없는 상태'를 말합니다. 프로그램을 만들다 보면 여러 가지 이유로 어떤 메모리 공간에 아직 데이터를 저장하지 못할 때가 있습니다. 예를 들어, 아직 유닛이 생산되지도 않았는데 그 유닛의 남은 체력을 저장할 수는 없을 것입니다. 이건 유닛의 체력을 '0'으로 설정하는 것과는 약간 다른 개념입니다. '0'과 '값이 없음'은 의미가 다르죠.

이러한 개념은 엄청나게 널리 쓰이고 있기 때문에, 현존하는 주력 프로그래밍 언어들은 거의 대부분이 널 포인터 또는 그와 유사한 기능을 제공하고 있습니다. C/C++의 널 포인터, 자바의 널 레퍼런스, 파이선의 None, 자바스크립트의 null/undefined, PHP의 NULL 등이 그렇습니다.

----

널 포인터가 야기하는 대표적 문제로 '널 포인터 참조'가 있습니다. 쉽게 말해, 데이터가 아직 없는데 읽으려고 시도했을 때 나타나는 오류입니다. 예를 들어, 적 해병에게 공격을 받아서 유닛 체력을 6만큼 깎아야 하는데, 유닛 체력이 '널'이라면? 이 경우 컴퓨터가 취하는 가장 대표적인 행동은, 그냥 그 프로그램을 꺼 버리는 것입니다.







왜냐하면 널 포인터를 참조하려고 한 그 시점에서 프로그램을 계속 진행하는 것이 의미가 없기 때문입니다. 지금 당장 유닛 체력을 깎아야 하는데, 기존 값이 없기 때문에 계산이 불가능합니다. 이 경우 컴퓨터는 어떻게 해야 할까요? 유닛을 죽여 버린다? 현재 게임만 gg 치고 나간한다? 아니면 게임을 일시 정지한다? 컴퓨터는 이런 것을 판단할 능력이 없기 때문에 (정확히는, 프로그래머가 위기 상황 시 무엇을 해야 하는지 지시를 하지 않았기에) 이러한 오류를 복구 불가능한 것으로 판단합니다. 그래서 '치명적인 오류'입니다.

널 포인터 참조는 보통 프로그래머가 프로그램의 실행 순서를 잘 예측하지 못했기에 나타납니다. 유닛이 생산되기 전에 유닛의 체력을 설정하고 내보냈어야 하는데, 실수로 그냥 내보낸 거죠. 그랬다가 나중에 유닛의 체력이 필요한 상황, 예를 들어 적에게 공격 받거나 해서 체력을 살펴 볼 필요가 있을 때 '펑!' 하고 터지는 것입니다. 이런 종류의 버그는 상당히 흔합니다. 테스트를 아무리 열심히 해도 실수로 빼먹은 경우의 수가 있을 수 있거든요.

----

그런데 널 포인터는 정말로 필수일까요? 널 포인터라는 개념은 '토니 호어'(Tony Hoare)가 1965년에 처음 발명했습니다. 그리고 40년이 흐른 2009년, 토니 호어는 한 강연에서 다음과 같이 말했습니다:

(널 포인터는) 내 10억 달러짜리 실수였다. 1965년 당시, 나는 ALGOL W라는 객체 지향 언어에 쓰기 위해 포괄적인 타입 시스템을 설계하고 있었다. 내 원래 목표는 어떤 데이터를 읽든 항상 안전하도록 컴파일러가 자동으로 확인해 주는 것이었다. 그러나 나는 널 포인터를 집어넣으려는 유혹을 이길 수가 없었다. 그렇게 하는 게 훨씬 쉬웠기 때문이다. 이 결정은 셀 수도 없는 오류와 보안 버그, 시스템 다운을 낳았다. 지난 40년 동안 이러한 문제들 때문에 입은 고통과 손해는 10억 달러는 될 것이다.

그렇다면 대안은 무엇일까요? 여기서부터 좀 어려워지는데요. 이제부터는 개발자-언어를 사용할 것이기 때문입니다.

오늘날 가장 유명하고 가장 널리 쓰이는 대안은 'sum type' 또는 'tagged union'이라고 불리는 개념입니다. 개발자-언어로 옮기면, '널이 될 수 있는 변수는 따로 분류하자'는 것이죠. (원래는 약간 더 복잡하고, 약간 더 유용한 기능입니다. 자세한 것은 다음 기회에!)

예를 들어 설명하면 이런 느낌입니다.

Animal dog = new Animal(); // dog은 '일반 포인터'입니다. 일반 포인터는 항상 값을 가리키고 있으며, 절대로 널이 되지 않습니다.

Animal? cat = null; // cat은 '널이 될 수 있는(nullable) 포인터'입니다. 일단 null로 초기화해 봅시다.

일반적인 포인터과 달리, 널이 될 수 있는 포인터들은 사용하기 전에 명시적으로 '허락'을 받아야 합니다. 대표적으로 if를 사용할 수 있겠죠.

print(dog.name) // dog은 절대로 널이 되지 않는다는 것이 보장되어 있으므로 마음껏 사용해도 됩니다!

// 한편, cat은 널이 될 수 있는 포인터이므로 사용하기 전에 반드시 if를 넣어서 null 여부를 확인해야 합니다. 만일 이를 어기면, 컴파일 단계에서 컴파일러가 오류를 낼 것입니다.
if (cat == null) {
    print('무언가 잘못되었다. 난 여기서 빠져 나가야겠어.');
} else {
    print(cat.name);
}

특정 포인터들만 널이 될 수 있게 하고, 그러한 포인터는 사용하기 전에 항상 널 여부를 확인하게 함으로써, 모든 널 포인터 참조 오류를 없애버릴 수 있습니다. 또한 대부분의 포인터는 널이 아니라는 것이 보장되어 있기 때문에 마음 편히 쓸 수 있습니다. 요즘 나오는 언어들은 대부분 이 기능이 기본 탑재되어 있고, 기존 언어들도 하위 호환성 때문에 널 포인터를 완전히 없애지는 못하지만 이 기능과 유사한 개념을 탑재하기 시작하고 있습니다.

스위프트, 러스트, 하스켈, 스칼라, 코틀린 등이 sum type을 가지고 있는 대표적인 언어입니다. 이러한 언어에서는 널 포인터를 사전에 컴파일러가 차단하므로 널 포인터 오류가 나지 않습니다. 자바스크립트에서도 http://flowtype.org/ 라는 것을 사용하면 완전히는 아니더라도 사전에 널 포인터를 예방할 수 있습니다.

과연 이러한 언어들이 흥해서 10억 달러짜리 실수를 다소나마 만회할 수 있을지 기대됩니다.