Null 공포증을 내려놓자

Null이라는 개념을 만든 것이 "백만 달러짜리 실수"라는 일화를 한 번쯤 들어봤을 텐데, 그만큼 Null과 NullPointerException(이하 NPE)은 많은 개발자들을 괴롭히고 애플리케이션에 문제를 야기시킨다. 그래서 Null을 다루지 않기 위한 여러 가지 방법을 사용하는데, 대표적인 방법으로 Null Object Pattern을 사용하여 Null을 대신할 객체(이하 Null Object)를 만들어 둔다.

 

나쁘지 않은 방법이다. 특히 특정 객체에 대한 Null 문제가 아니라 객체의 속성이나 필드가 Null인 케이스를 방어해 두기도 좋다.

 

그러다 보면 보이게 되는 코드들이 맹목적인 Null 방어 코드들이다. 마치 Null만 막으면 애플리케이션이 안전해진다고 착각한다. Null을 다루는 코드는 위험이 있고 세련되지 못하다고 착각한다.

 

최근 많은 프로그래밍 언어는 Null 참조를 대체하거나 피하기 위한 다양한 기법을 도입하고 있는데, 예를 들어 코틀린의 경우 nullable 타입과 non-nullable 타입을 엄격하게 구분한다. 실수로 Null 참조를 피하기 위함이다. 여기서 알 수 있는 사실은 최신의 프로그래밍 언어들도 Null을 없애지는 않았다는 점이다. 분명 Null로 다뤄야 좀 더 적절한 참조가 있다. 위험이 있더라도 말이다. Null이 적절한 참조에서 어색하게 Null Object를 넣지 말아야 한다.

 

Null Object의 반환은 반드시 개발자의 의도적이어야 한다. Null Object가 반환되어도 애플리케이션 동작에 문제가 없는지 충분히 고민하고 반환해야 한다. 맹목적인 방어적 코드로 사용하다 보면 분명 애플리케이션에 문제가 생긴다. 당장 눈앞의 NPE는 막아줄지언정 애플리케이션의 정상 동작을 막는다. 차라리 예외가 터져서 문제를 인식하게 하는 편이 훨씬 좋다. 인식하면 문제점을 파악하고 수정할 수 있는 기회가 있다. 이보다 무서운 것은 의도치 않게 동작하는 애플리케이션이다. Exception 상황을 catch하여 기계적으로 Null Object를 넣지 말자. 터질 Exception은 터져야 한다.