Optional로 NPE 방지

2. 핵심 원리

2.1 NPE — 10억 달러짜리 실수

null 참조를 발명한 토니 호어(Tony Hoare)는 2009년 강연에서 이를 "10억 달러짜리 실수(billion-dollar mistake)"라고 불렀습니다. 1965년 ALGOL W 에 "구현하기 쉬워서" 넣었는데, 이후 수십 년간 셀 수 없는 버그·보안 취약점·시스템 다운을 만들었다는 것입니다.

자바에서 null 의 근본 문제는 타입 시스템의 구멍입니다. String s 라는 선언은 "s 는 String 이다"라고 말하지만 실제로는 "String 이거나 null 이다"입니다. 컴파일러는 이 차이를 검사하지 않으므로 모든 참조 변수가 잠재적 폭탄이고, 안전성은 전적으로 개발자의 기억력과 규율에 달려 있습니다.

2.2 null 의 구체적인 문제

2.3 Optional 의 설계 의도 — 반환 타입 전용

Optional<T> 은 "T 타입 값이 있거나 없음"을 나타내는 컨테이너 객체입니다. 내부는 단순합니다.

public final class Optional<T> {
    private static final Optional<?> EMPTY = new Optional<>(null);
    private final T value;                    // null 이면 empty
    ...
}

JDK 설계자(Brian Goetz)의 공식 입장은 명확합니다.

Optional 은 "결과 없음"을 표현할 명확한 방법이 필요하고 null 반환이 오류를 유발할 가능성이 높은 라이브러리 메서드의 반환 타입을 위한 제한적 메커니즘으로 만들어졌다.

즉 Optional 은 "null 을 없애는 만능 도구"가 아니라 "이 메서드는 값을 못 돌려줄 수 있다"는 신호를 시그니처에 넣는 도구입니다. 그래서 설계상:

• Serializable 이 아닙니다(필드에 넣지 말라는 의도).
• 값 기반 클래스(value-based)로 == 비교, 동기화, identity 사용을 금지합니다.
• 객체 하나를 추가로 할당하므로 성능 민감한 경로(핫 루프의 필드)에는 부적합합니다.

2.4 생성 — of / ofNullable / empty

Optional.of(null) 이 NPE 를 던지는 것은 버그가 아니라 의도입니다. "여기엔 null 이 올 수 없다"는 선언이므로 null 이 오면 가장 이른 시점에 실패하게 합니다(fail-fast).

2.5 안전한 값 추출 — orElse vs orElseGet vs orElseThrow

orElse 와 orElseGet 의 평가 시점 차이가 가장 중요한 원리입니다. 자바는 메서드를 호출하기 전에 인자를 먼저 평가합니다.

opt.orElse(loadDefault()) 는 loadDefault() 를 먼저 실행하고 그 결과를 orElse 에 넘깁니다 — Optional 에 값이 있든 없든. 반면 orElseGet(() -> loadDefault()) 는 람다를 넘기므로 Optional 이 비어 있을 때만 람다가 호출됩니다.

Optional<String> name = Optional.of("kim");
String a = name.orElse(expensive("A"));           // expensive("A") 실행됨! (값이 있어도)
String b = name.orElseGet(() -> expensive("B"));  // expensive 실행 안 됨

orElse 의 인자가 상수나 이미 있는 변수면 차이가 없지만, DB 조회·객체 생성·로깅이면 성능 낭비이자 부수효과 버그입니다. 규칙: 인자가 리터럴/변수면 orElse, 계산이 필요하면 orElseGet.

2.6 변환 — map / flatMap / filter

Optional 은 스트림처럼 체이닝합니다. 값이 없으면 체인 전체가 empty 로 흘러가고, 중간에 NPE 가 나지 않습니다.

map vs flatMap: user.map(User::address) 에서 address() 가 Address 를 돌려주면 Optional<Address>. 만약 address() 가 이미 Optional<Address> 를 돌려준다면 map 은 Optional<Optional<Address>> 를 만들므로 flatMap 을 씁니다. 스트림의 map/flatMap 과 같은 관계입니다.

map 의 null 처리: map 의 함수가 null 을 돌려주면 자동으로 empty 가 됩니다. 그래서 Optional.ofNullable(user).map(User::getAddress).map(Address::getCity) 는 어느 단계에서 null 이 나와도 안전합니다 — 이것이 중첩 DTO 접근 패턴의 핵심입니다.

2.7 소비 — ifPresent / ifPresentOrElse

if (opt.isPresent()) { use(opt.get()); } 는 opt.ifPresent(this::use) 로 바꿉니다. 전자는 null 체크와 형태가 동일하므로 Optional 을 쓰는 의미가 없습니다.

2.8 안티패턴 — 쓰면 안 되는 곳

Optional 을 파라미터로 받지 말라는 이유를 조금 더: 메서드 내부에서 어차피 isPresent 분기를 해야 하고, 호출자는 foo(Optional.ofNullable(x)) 처럼 불필요한 래핑을 합니다. 자바 언어 설계자들은 "Optional 을 파라미터로 받는 API 는 거의 항상 잘못 설계된 것"이라고 말합니다.

2.9 Objects 유틸 — requireNonNull / requireNonNullElse

Optional 이 아닌 곳(생성자 인자 검증, 파라미터 기본값)에는 java.util.Objects 가 적합합니다.

record 의 컴팩트 생성자에서 Objects.requireNonNull(name, "name") 로 불변식을 지키는 것이 JDK 21 관용구입니다. 생성 시점에 null 을 막으면 그 객체를 쓰는 모든 코드에서 null 검사가 사라집니다 — Optional 보다 훨씬 강력한 null 제거 전략입니다.

2.10 JDK 21 기준 대안 — 패턴 매칭과 sealed

Optional 은 "값이 있음 / 없음" 두 상태만 표현합니다. "없음"의 이유(찾지 못함 / 권한 없음 / 만료됨)까지 표현하려면 sealed interface + record + switch 패턴 매칭이 더 정확합니다.

sealed interface Lookup<T> permits Found, NotFound, Forbidden {}
record Found<T>(T value) implements Lookup<T> {}
record NotFound<T>(String id) implements Lookup<T> {}
record Forbidden<T>(String reason) implements Lookup<T> {}

String msg = switch (lookup) {                 // 컴파일러가 세 경우 모두 처리했는지 검사(exhaustiveness)
    case Found<User> f -> "hello " + f.value().name();
    case NotFound<User> n -> "no user " + n.id();
    case Forbidden<User> x -> "denied: " + x.reason();
};

instanceof 패턴 매칭(JDK 16+)은 nullable 값을 다룰 때 캐스팅과 null 검사를 합칩니다: if (obj instanceof String s && !s.isBlank()) — obj 가 null 이면 instanceof 가 false 이므로 안전합니다. switch 에 case null -> (JDK 21) 을 두면 null 을 명시적으로 분기할 수 있습니다.