자바 Optional은 데이터 경계에서만 쓰는 이유

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

자바 Optional은 불확실해 보이는 모든 값을 감싸는 장식이 아니다. 메서드가 값을 돌려주지 못할 수 있고, 그다음 처리를 호출자가 실제로 선택해야 할 때 반환 타입으로 쓰는 것이 가장 자연스럽다. 필드와 파라미터의 기본값으로 삼으면 끝나지 않은 선택이 객체와 호출 체인 전체로 퍼진다.

호출자에게 정말 선택이 있는지부터 본다

findById 같은 데이터 조회는 결과가 없을 수 있다. 호출자는 그 부재를 예외로 바꾸거나, 그대로 받아들이거나, 대체 값을 쓸 수 있으므로 Optional이 실제 계약을 드러낸다. 애플리케이션이 응답을 통제할 수 없는 외부 API 클라이언트도 비슷한 경계다.

반면 데이터가 없으면 이미 예외를 던지기로 한 메서드가 성공 결과까지 Optional로 감싸면 호출자에게 남은 선택이 없다. 모든 반환값을 습관적으로 감싸는 코드가 특히 나쁜 이유다. 확정된 동작을 불확실한 것처럼 보이게 한다.

불확실성은 데이터 경계에서 들고 온다

Optional이 자연스러운 위치는 대개 데이터 조회나 외부 호출 주변이다. 다음 레이어가 결과를 해석하고 자기 계약이 확정적이라면 애플리케이션 안쪽에는 확정된 값을 넘긴다. 아래 리포지토리가 Optional을 반환한다는 이유만으로 상위 서비스 작업까지 계속 같은 타입을 돌려줄 필요는 없다.

물론 예외는 있다. 흐름 뒤에서도 부재가 중요한 상태일 수 있고 제품 성격에 따라 규칙도 달라진다. 그래서 팀은 해결되지 않은 부재가 어느 경계를 넘을 수 있는지, 누가 이를 처리할지 합의해야 한다. 핵심은 Optional을 금지하는 것이 아니라 이미 끝난 결정을 다시 호출자에게 넘기지 않는 데 있다.