2021-05-31(Mon)

Facts (사실, 객관)

코드숨 5주차 강의를 수강했다.

수요일에 있을 지원 기업 최종면접을 조금 준비했다.

Feelings (느낌, 주관)

경험상 기술을 학습할 땐 '불편함'을 먼저 느끼는 것이 효과적이다. 덕분에 lombok과 dozer를 효과적으로 학습할 수 있었다.

한편 아래 코드숨 강의를 수강하며 아래 의문이 들었다.

유효성 검사는 Entity에서는 하지 않고 DTO에서만 해야할까?

코드숨 강의에서는 Entity에서 하는 유효성 검사 조건을 삭제하고 DTO 객체에만 유효성 검사 조건을 삽입하는 내용이 있었다. 이유는 DTO를 만들었으니 Entity 객체는 '웹이 더 이상 아니니까'였다. 이는 DTO 객체를 사용함으로써 외부에서 Entity 생성에 관여하는 부분이 사라졌으므로, DTO에서만 유효성 검사하면 된다는 말씀으로 이해했는데, 뭔가 위화감이 느껴졌다. 그래서 다른 개발자들의 의견을 찾아봤다.

만약 유효성 검사 대상을 Entity에서 제거하고 DTO에 추가하면 아래 장단점이 있다.

• 장점: Entity 객체 생성 메서드를 부르기 전에 유효성 예외가 검출되므로 오버헤드를 줄일 수 있다.

• 단점: DTO를 거치지 않고 Entity를 생성하는 경우가 있다면, 논리상 유효하지 않은 Entity가 만들어질 수 있다는 위험이 있다.

그런데 위 단점은 Entity에도 유효성 검사 조건을 넣으면 해결되며, 여기에 따르는 구현 비용이 적고, 성능상 비용도 막 크리티컬하게 크지 않으므로, 왠만한 상황에선 Entity와 DTO 양 쪽에서 유효성 검사를 하는게 좋다고 판단했다. 스택오버플로우 참고.

한편 동시성 제어에 대해서 면접 때 부족함을 느꼈는데, 학습하면 할 수록 민망함은 커져만 간다..

Findings (배운 점)

java bean validation 표준의 개념, 이를 애너테이션으로 추가하는 방법을 학습했다.

lombok으로 객체의 Constructor, Getter, Setter 등 보일러 플레이트를 제거하는 방법을 학습했다.

Object Mapper인 dozer 사용법을 학습했다.

동시성 제어에 대해서 학습했다. 상용 web에서 동시성 제어를 한다면, 성능 저하와 데드락의 위험, Read-Write 비율을 고려하여 왠만하면 locking보다는 Timestamp Ordering이나 낙관적 검증기법을 사용하는 것이 적절하다는 나름의 결론을 얻었다. 내가 이전에 했던 게임 사이트 프로젝트에서는 게임에 동시 접속할 때 lock을 사용했었는데, 영 좋지 않은 방법이었던 셈이다.

lock에 대해서도 어설프게 알고 있는 것을 느껴서 재학습했다.

Affimation (자기 선언)

나는 성장한다-실패했던 부분은 반복하지 않고, 몰랐던 부분은 설명할 수 있도록 이해한다.