잡담 TIME
오늘 무작위로 다른 팀원들과 섞여 30분간 잡담을 하라는 미션이 있었다. 미션이 끝난 후에는 각자의 소속 조로 돌아가 대화 내용을 공유하는 것이 조건이었다. 예상대로 어색함을 많이 느낄 것 같아 부담스러웠지만, 어쩔 수 없이 참여할 수 밖에 없었다.
다행히 우리 조는 분위기가 좋았고 대화도 자연스럽게 이어졌다.
대화 주제
- 각자의 프로젝트 진행 상황
- 사전 강의에 대한 느낌
- 전공과 교육 배경
- 면접 복장
- 사용하는 키보드
다양한 이야기를 나누었고, 내가 생각한 것보다 훈련에 참여한 사람들 중 잘하는 분들이 많다는 것을 느꼈다. 그래서 오히려 받아들이고, 욕심을 조금 내려놓는 것도 괜찮겠다는 생각이 들었다.
데일리 스크럼 도입
소속 팀에 돌아와 잡담 내용을 공유한 후, 데일리 스크럼을 시작했다. 끝난 후에 발표의 부담을 줄이기 위해 데일리 스크럼 내용을 텍스트로 먼저 정리하는 규칙을 추가하기로 했다.
그리고 기록을 잘한다는 팀원들의 추천을 받아 튜터님과 멘토님의 피드백을 내가 대표로 정리하기로 했다.
엔티티 매핑 담당 논의
이후 엔티티 매핑 작업을 맡을 담당자를 정할지 분담해서 작업할지 논의가 있었는데, 합치는 상황을 고려해 한 사람이 맡는 것이 좋다는 결론이 나왔다. 그리고 내가 엔티티 매핑을 담당하게 되었다.
피드백
튜터님 피드백
엔티티 매핑 담당자
엔티티 매핑 담당으로 결정된 직후, 튜터님께 진행 상황을 공유드렸고, 한 사람이 모든 엔티티 매핑을 맡게 된 것에 대해 의아해하셨다. 튜터님은 각자가 나눠서 경험해보는 것도 좋지만, 일관성과 N:1 관계 매핑, Auditing 등을 관리하는 측면에서는 한 사람이 맡아 진행하는 것이 훨씬 빠를 수 있다고 하셨다. 그리고 어차피 인증/인가 담당자가 아키텍트의 전반적 역할을 맡게 될 수 밖에 없다고 하셨다.
테스트 코드
도전 과제를 필수 기능이 끝난 후 고려하는 것으로 결정했었는데, 특히 테스트 코드는 나중에 작성하는 것이 바람직하지 않다고 조언해 주셨다. 테스트 코드를 기능 구현 전에 먼저 작성해보는 방식을 권장하셨다.
인프라 설계
이전 인프라 설계도 관련 피드백을 제대로 이해하지 못하고 있어 추가적인 설명을 들을 수 있었다. AWS 영역의 엔드포인트, VPC, EC2, RDS의 구체적인 구분과 연결 방식이 아쉬웠다고 말씀해주셨다.
총괄 매니저님 전체 피드백
총괄 매니저님은 프로젝트도 중요하지만 코딩 테스트(코드타카)와 로깅(TIL)이 매우 중요한 부분이므로, 한쪽에만 집중하지 말고 밸런스를 잘 맞추는 것이 중요하다고 강조하셨다.
엔티티 매핑
본격적으로 도메인별로 패키지를 나누고 엔티티 클래스를 생성한 후, 기본적인 어노테이션을 추가했다. 먼저 각 클래스에 ERD를 토대로 필드를 작성하고 필요한 어노테이션을 붙였다. 어느 정도 필드 작업을 마친 후, 연관관계를 설정하기 시작했는데 여전히 익숙하지 않아 몇 대 몇 관계인지, 양방향인지 단방향인지, 외래키의 주인이 올바른지 하나씩 확인해가며 설정해서 생각보다 오래걸린 것 같다. 연관관계 설정을 마친 뒤 첫 PR을 생성했다. 로컬 기능 브랜치에서 커밋 후 원격으로 푸시하여 GitHub 웹에서 PR을 생성했다.
코드리뷰 피드백
나름 꼼꼼히 확인했다고 생각했지만, 코드리뷰를 통해 놓친 부분이 많다는 것을 알게 되었다. 괜히 한다고 한 것은 아닌지 중간에 생각이 들었었지만, 실수한 부분을 확인하면서 오히려 배울 수 있어 PR을 생성하길 잘했다는 생각이 들었다.
코드 리뷰를 통해 보완한 내용
- 기본 생성자 생성제한
- 엔티티 id UUID 타입 적용
- Enum 타입 및 변수 수정, @Enumerated 누락 추가
- 잘못 설정된 타입 수정
- 잘못된 연관관계 및 필드 옵션 수정
- 필드 순서 정리 및 가독성 개선
기본 생성자 생성제한
@NoArgsConstructor(access = AccessLevel.PROTECTED)
기본 생성자는 JPA가 엔티티를 제어하기 위해 사용하므로 외부에서의 접근을 막아두는 것이 좋다. 엔티티의 생성이 필요한 경우에는 별도의 생성자를 정의하거나 빌더 패턴을 활용할 수 있다.
JPA에서 지연 로딩(Lazy Loading)을 설정한 경우, 실제 엔티티 대신 프록시 객체를 통해 데이터를 조회하게 된다. 프록시 객체가 정상적으로 생성되려면 기본 생성자가 필요하며, 이 생성자의 접근 권한이 private일 경우 프록시 객체를 만들 수 없게 된다. 반면, public으로 설정하면 외부에서 무분별한 객체 생성을 허용하게 되므로, 기본 생성자의 접근 제한을 PROTECTED로 설정하는 것이 유리하다.