기본 콘텐츠로 건너뛰기

4월, 2023의 게시물 표시

Null Object Pattern 과 Optional 사용

오늘 정리해 보고자 하는 건 누구나 다 아는 패턴 중 하나일 Null Object Pattern 에 대해서 한번 생각해 보려고 한다. 일단은 글작성 동기는 어떻게? 퇴사를 얼마 안남기고 막내 프로그래머(경력상 막내지만 착실한 친구)에게 Optional 을 설명해 주고 있었는데, 뭔가 부족한 설명을 한 것 같은 느낌이라 좀 더 어딘가에 정리를 해 놓고 싶었습니다.  Optional 을 설명하다 보면 참 많이 돌아가게 되더구요. 전혀 생각도 못했습니다. 시스템 내에서 NullPointerException 이 어떤 의미로 다가왔었는가 Null Check 로직이 많아지면 얼마나 코드를 읽기 어렵게 만들어 주는가 이런 체크 로직이 많은 상황에서 새로운 다향성 객체가 만들어질 때 얼마나 많은 수정이 일어난는가 등등 그런 이유로 Optional 이 생겨나긴 했는데 일단 그 장점과 위험성은 정리해 놓은 분들이 많으니 블로그를 검색해봐라로 마무리 되었습니다. 그런데 말이죠 예전에도 Null Object Pattern 은 빈번하진 않아도 꽤 사용이 되었던 패턴입니다. 그 정의는 매우 단순합니다. 우선 ChatGPT 가 알려주는 Null Object Pattern 은 이렇습니다. "Null Object Pattern is a design pattern in object-oriented programming that allows the use of a special null object to represent the absence of an object. Instead of returning a null reference from a method or property, the null object pattern provides a substitute object that behaves in a predictable and consistent way with the rest of the system. This can help to reduce the amount of nu

[영상공유] Spring for the Architecturally Curious Developer by Oliver Drotbohm

이번 영상은 Oliver Drotbohm이 Spring Monolith에 대해서 설명하는 영상이다. 전체적으로 Josh Long 처럼 말이 빠르지 않아서 나 같은 사람도 꽤 알아들을 수 있었던 영상이다. 시간은 50정도지만 실제로 들어보면 그렇게 길게 느껴지지는 않는다. 2015년 즈음 Spring Boot 와 Spring Cloud  프로젝트가 본격화 되면서 Microservice Architecture(MSA)가 개발의 기본 아키텍처로 자리를 잡았고, 당시 거의 모든 개발자들이 MSA를 도입하려고 많은 노력을 해 왔다고 생각한다. 필자도 최근 몇개의 프로젝트(또는 회사)에서 프로젝트를 진행하면서 MSA를 변형해서라도 프로젝트에 도입해보고자 노력을 했던 것 같다. 그런데, 최근 Modular Monolith 라는 용어가 개발 커뮤니티에서 많이 보이고 있다. Monolith 가 다시 화두에 올라오고 있는 이유를 정확히 알수 있을 정도의 경험과 실력은 없지만 Simon Brown 이 유튜브 강의( 여기 에서 볼 수 있다)와 그 간의 경험을 바탕으로 약간 정리해볼까 한다. 일단은 모두가 MSA를 도입하려고 했던 이유부터 아주 간단하게 알아보면 다음과 같다.(사실은 필자가 MSA를 좋아했던 이유다) Monolith 는 회사 전체 시스템을 하나의 모듈로 보고 개발이 되다보니 개발 조직간의 협업의 어려움, 수평확장의 어려움과 비효율성 및 비용증가, 시스템이 커짐에 따라 발생하는 유지보수 문제성 등이 있었고 이로 인해 발전해 온 SOA의 경우는 무겁고 비싼 ESB를 기반으로 개발되다보니 비용적인 측면과 이후 거의 모두가 ESB 지옥을 경험하는 경험들이 발생했다. 그에 MSA는 SOA의 기본 이점을 유지하면서도 가볍고 클라우드 환경에 적합한 개발이 가능하다는 이점이 있었다. 서비스간 통신에 기본적이고 단순한 프로토콜(일반적으로는 Rest API)을 이용해서 통신하다보니 다른 서비스들이 특정 프레임워크나 언어에 구애받을 필요가 없었다. 병목지점이 될만한 서비스들만 확장을 할