Java Optional이 response 필드 nullable 표현에 적합할까?

Java에서는 null을 안전하게 다루고 표현력을 높이는 방법으로 Optional이 잘 알려져있는 것 같습니다.
하지만 실제로 사용하다보니 wrapper 타입이라는 점으로 인해 고민되는 요인들이 꽤 많았는데요.

정확히는 Optional을 nullable 표현의 용도로 API response 필드 값에 사용하고 싶었는데 그 과정에서 고민되는 점이 있었어요.
오늘은 그 내용에 대해 개인적인 생각을 적어보려고 합니다.

Optional을 response 필드에 사용할 때 문제점

 

1. 직렬화

"Optional은 직렬화하는데 의도치 않는 필드가 직렬화되는 문제가 발생할 수 있습니다."

직렬화 라이브러리의 구현마다 다르겠지만 모두 Optional을 호환하는지는 보장되지 않으므로
우리가 제어할 수 있는 영역이 줄어들고 커스텀할 수 있는 영역이 있더라도 고민거리와 복잡도가 높아지는 방향성이니 좋은 선택은 아닌 걸로 판단되었어요.

그렇다고 응답의 해당 필드는 nullable하다는 표현을 포기하기에는 아쉬운 결정이었던 것 같습니다.
그래서 아래와 같이 주석으로 nullable을 표현해도 봤지만 좀 더 다른 좋은 방법이 없을까? 고민을 이어갔습니다.

그리고 사실 이 문제는 꽤 치명적이라고 판단했지만
해당 문제를 발견한 건 좀 더 좋은 방법은 없을지 찾는 과정에서 발견했습니다.
왜냐면 Spring boot에서는 optional response를 지원하는 것인지 직렬화 문제가 발생하지 않았기 때문이었습니다.
그럼 괜찮은 거 아니야? 싶을 수 있지만 여전히 직렬화 이슈는 존재하므로 일관된 컨벤션을 가져가고 싶었습니다.

 

API 조회 시 직렬화 문제가 발생하지 않고 적절하게 응답 데이터가 내려오는 모습

 

2.  파라미터에 사용할 때와 Wrapper class에 대한 오버헤드

"Optional은 wrapper class이고 이에 따른 오버헤드가 존재합니다."

그리고 파라미터로 사용할 때 불필요한 오버헤드가 생기는 경험을 자주했습니다.

다음과 같이 nullable한 표현을 위해 Optional을 사용했었는데요.
표현력은 올라갔지만 매번 Optional을 사용해줘야 하는 오버헤드가 생겼습니다.
그럼에도 나쁘지 않은 적정선이었다고 생각하는데 사용하면서 이상하게 거부감이 많이 들었던 것 같아요.
그래서 이것도 좀 더 편하고 좋은 방법이 없을까? 찾기 시작했습니다.

 

 

그리고 발견한 @Nullable, @NotNull

@Nullable, @NotNull은 자바에서 기본으로 제공해주는 기본 어노테이션입니다.
아쉽게도 컴파일 타임에 검증해주는 걸 기본으로 제공하진 않지만 오버헤드를 줄이고 표현력을 높일 수 있는 방안이 될 수 있을 걸로 판단됐습니다.
그리고 기본적으로 @Nullable을 달아주지 않으면 @NotNull로 표기해준다는 점에서 나름의 규칙이 있는 것이 맘에 들었습니다.

단순하게 @Nullable이 없는 건 NotNull로 취급하고 @Nullable이 있는 경우 null check를 해주는 식으로 컨벤션을 잡고
비교적 단순한 규칙이라 복잡도도 낮은 것 같다는 생각도 들었어요.

그리고 아래와 같이 IDE에서 마우스를 hover하면 나오는 명세에도 @Nullable이 적혀있는 점이 맘에 들었습니다.

 

 

@Nullable을 코드에 적용한 모습 AS-IS, TO-BE

개인적으로 "표현력 높이기" + "컨벤션을 만들어 소통 비용 줄이기"를 기준으로 이렇게 코드를 작성해봤는데
잘 했는지에 대한 판단은 시간이 지나고 사용성에 대해 피드백을 받는 시점에서야 알 수 있을 것 같습니다.

여러분은 어느쪽이 좀 더 취향이신가요?
혹은 java에서 nullable한 값을 다루는 노하우가 있으신가요?
아니면 역시 자바는 버리고 코틀린이나 해야겠다는 생각이 들 수도 있을 것 같습니다.

말하는 감자에게 좋은 의견 부탁드립니다. 감사합니다 🙏