하루를 마무리 하기 전, 오늘 있었던 일들을 잔잔히 되짚어봅니다.
성공과 실패의 모든 요소에서 '배울 점'을 찾아내어 기록하고,
더 성장하는 내일의 나를 위해 'action plan'을 세웁니다.
오늘도 감사하게 아샬님이 오셔서 어제보다 더 오랜 시간동안 특강을 진행해주셨다.
쉽지 않은 내용이라 소위 뇌가 녹아내리는 듯한(ㅎㅎ) 느낌이었는데, 노아님께 질문하려고 모아둔 질문과 관련된 내용을 말씀해주셔서 큰 도움이 되었다.
우선 아래는 내가 오전에 정리해둔 내용!
계속 도메인 모델을 설계하는데 애를 먹고 있었다.
어떻게 해야 할지 잘 감이 잡히지 않는 것도 그렇지만, 모델 안에 객체를 넣는 것이 아직 익숙치 않고 뭔가 부담스러운 일이었다.
분명 노아님과 기획단계에서 이야기 할 때, 'Address'라는 부분은 별도의 객체로 분리하여 쓰곤 한다는 이야기를 나눴었고 실제로 백엔드 쪽에서 Address라는 entity가 아닌 값 객체를 만들어 Place라는 엔티티 안에 넣어주기도 했다. 하지만 어떤 이유에선가 뭔가 이상하다는 느낌이 있었고 사실 Address 객체에 있는 요소들(fullAddress, sido, sigungu, placeId)을 다 헤쳤다가 다시 또 모았다가 거의 4~5번을 그렇게 풀었다 모았다 하면서 고민을 했더랬다.
결국은 Address 뿐만 아니라 ImageSource, BusinessHours라는 객체를 모두 헤쳐서 PlaceDto로 전달하는 정보에 포함시켰고 어마어마한 길이의(;;) 인자를 가진 DTO가 탄생하여 프론트에 넘겨지게 되었다.
사실 받아쓰는 입장에서야 뭐... 정보 하나 하나 확인하면서 꺼내 쓰면 되니까 그리 어려운 일은 아닌데, 기능 하나 없는 Place 클래스의 코드가 100줄이 넘어가는 기이한 현상이 일어났다.
사실 이상 신호라고 볼 수 있겠다. 그저 toDto() 메서드 하나 있는 클래스가 그렇게 비대해질 수 있는가...
그래서 우선 위 사진과 같이 다이어그램으로 모델을 조금 수정해두고 리팩터링을 해 둔 후에 노아님께 질문을 하려 했는데 마침 아샬님 특강이 진행되어 관련된 내용을 들을 기회를 얻은 것이다!!
정말, 아주아주 솔직하게 말하면 값 객체와 entity의 차이점을 좀 명확하게 알게된 건 요 며칠 사이라고 할 수 있다.
이전에 코딩 인터뷰나 개념노트를 정리하면서 값 객체와 entity에 대한 설명을 숱하게 접했고 정리도 해 두었지만 감이 잘 오지 않았다.
그래서 뭐가 어떻게 다른지도 모르겠거니와, '그래서 어쩌라는거지...?' 하는 느낌이 강했다.
하지만 엔티티와 값 객체가 다양하게 생기는 서비스를 만들기 시작하니 둘의 차이점이 예전보다 더 명확하게 다가왔고, 'identifier'의 존재 여부가 중요한 차이점이기는 하나 실제 개발에서 어떤 역할을 하는지도 좀 더 실감나게 다가왔다.
객체 안에 객체를 넣을 때에는 몇 가지 후속작업이 필요하기에, 그 시점에서 아주 단순하게 생각한다면 '그냥 풀어주는 게 훨 쉽지 않나?' 라는 마음이 들 수 있다.
하지만 값 객체를 사용할 경우 사용하는 요소들이 많아질 때 해당 요소에 대한 identity를 명확히 나타내는 역할을 할 수 있기도 하고, 프론트쪽에서도 좀 더 의미있는 묶음의 자료로 받을 수 있다는 점도 확인할 수 있었다.
builder라는 새로운 패턴(?)도 접하기도 했는데, 끝까지 아샬님이 강조하신 부분. 즉 '기본'에 충실하고 거기에 비타민(필살기 ㅎㅎㅎ)을 얹는 것이 중요하기 때문에 지금은 강의에서 배운 내용을 토대로 '기본'을 충실하게 다지는 데 집중하려고 한다. 기본만 따라가기에도 벅차긴 하다, 특히 테스트... ㅎㅎ.
오늘 흩어져있던 요소를 객체화하면서 겪었던 문제가 있었는데, 바로 PlaceDto로 장소 정보를 내보내기 위해 정보를 Dto로 변환하는 과정에서 겪은 문제이다.
아까 캡쳐를 따로 해두지 않아서 단순히 메시지의 일부만 남아있는데, InvalidDefinitionException가 발생한 것이다.
발생했을 그 시점에 정확히 메시지를 캡쳐해둘걸.. ;;
결론적으론 Place라는 entity를 toDto() 메서드로 DTO화 하는 과정에서 그 안에 예전에는 없었던 값 객체들이 생겼는데(BusinessHours, Address, ImageSource) 그 객체들 또한 별도로 Dto화 하지 않으면 위와 같은 익셉션이 발생한다.
처음엔 너무 당황했는데 비슷한 문제를 겪었던 동료의 조언을 받아 해당 값객체들을 먼저 DTO로 바꿔준 다음, 그 바꿔준 DTO를 포함하여 Place entity를 DTO로 변환하니 위와 같은 문제가 사라졌다.
직렬화, 역직렬화와 관련된 내용이기도 한 듯 한데, 이건 별도로 정리해야겠다.
오늘 아샬님의 말씀을 들으면서 내가 가질 수 있는 edge는 무엇일까 심히 고민스러웠다. 그 고민 때문에 지금 더 피곤한 기분이 드는 것 같기도 하다.
결국 취업을 위해서는 edge가 필요할 것이다. 취업 뿐만이 아니라 실무에서도 그리고 삶에서도 마찬가지.
그리고 그 edge를 갖추는 길은 결코 순탄치 않을 것이기에 고통이 전제되어 있는 길이지만, 지금과 같은 어려운 시기와 상황, 그리고 전 세계적인 침체 속에서도 결국 edge를 갖춘 인재는 시대의 흐름과 파도에 흔들리지 않을 뿐만 아니라 많은 사람들이 찾는 사람이 되지 않을까.
나은 사람이 되는 게 정말 쉽지 않다는 생각은 들지만 어려운 길을 택한 만큼 완주의 끝에는 더 큰 감동과 기쁨이 올 것이라 믿는다.
어제 오늘 코딩할 시간이 많이 없었는데, value object와 관련된 내용을 바탕으로 리팩터링 빠르게 하고, 또 이번 스프린트 태스크들을 해보자.
