원인의 발단....
❗️ 리팩토링 전
private void updateFields(UpdateRepairArticleRequestDto request, RepairArticle repairArticle) {
if (request.category() != null) {
repairArticle.setCategory(request.category());
}
// 기타 조건문 처리...
}
❗️ 리팩토링 후
private void updateFields(UpdateRepairArticleRequestDto request, RepairArticle repairArticle) {
Optional.ofNullable(request.category()).ifPresent(repairArticle::setCategory);
// 기타 Optional 처리...
}
Patch API를 구현하면서 여러 줄의 if 문이 너무 보기 싫어 Optional을 활용해 리팩토링을 하였다.(실제로 훨씬 깔끔하다!)
그런데 이 코드리뷰를 받고 나서 고민이 들기 시작했다.
Optional을 쓰면 가독성이 상승하지만, 이게 다일까? 성능적인 측면에서는 문제가 없을까?
결론은 Optional을 사용하면 성능이 떨어진다.
1. 객체 생성 오버헤드
Optional은 객체이다. Optional.ofNullable() 같은 메소드를 호출할 때마다 새로운 Optional 객체가 생성된다는 뜻이다.
이는 단순한 if 문을 사용할 때와 비교하여 추가적인 메모리 할당과 가비지 컬렉션 부담을 의미한다.
각 Optional 객체는 래핑된 값에 대한 참조와 객체 자체의 메타데이터를 포함하기 때문에, 이러한 객체들이 대량으로 생성될 경우 성능 저하가 발생할 수 있다.
2. 메소드 호출 오버헤드
Optional을 사용하면 .ifPresent(), .orElse(), .orElseGet() 등과 같은 메소드 체이닝이 일반적이다.
이 메소드들은 내부적으로 추가적인 함수 호출을 발생시키며, 이는 컴파일러나 JVM이 최적화하기 어려울 수 있다.
- 이런 추가적인 메소드 호출들은 컨텍스트 스위칭과 콜 스택 관리에 따른 오버헤드를 발생시킨다.
그렇다면 Optional을 사용하지 않고 if문을 사용하는게 맞는걸까?
아니면 가독성을 챙기고 성능을 떨어뜨리는게 맞는걸까?
근데 생각해보면 이 정도 오버헤드에 성능이 크게 하락하지도 않을것 같다. 하지만 백엔드 개발자라면 성능이 좋은 코드를 짜는게 우선이 아닐까??? 고민이 된다..🫠🫠
결론
관련해서 자료들을 찾아봐도 전부 상황에 맞게 판단하여 사용하라는 소리 뿐이다...
하지만 나는 짬이 없어서 내 판단이 이 상황에 적합한지 확신이 잘 서지 않는다.
❗️그래서❗️
짬밥 충만한 멘토님에게 질문한 결과 여러가지 조언을 들을 수 있었다.
- 이 정도 오버헤드는 돈만 있으면 다 해결된다.
- 일단 쓰고 문제가 생기면 그 때 해결하라
- 이 정도 오버헤드보다 개발자 몸값이 더 비싸니 이런거 고민하지 말라
이 부분에 대해 고민하면서 스트림 API 등 다양한 사례들도 함께 고민하면서 머리가 아팠는데 멘토님의 조언이 정말 도움이 되었다.
"장고 끝에 악수 둔다" 라는 말이 있듯이 너무 깊게 생각하면 오히려 안좋은 결과를 초래할 수 있다는 것을 깨닫게 되었다...
하지만 개발자로서 이런 고민은 한 번 쯤은 해 봐도 나쁘지 않을 것 같다.
