24년 1월 8일(월요일) - 66번째 TIL

 

오늘은 아침에 기술면접 준비를 해두고, 담당 튜터님과 피드백 일정을 잡고, 오전에는.. ERD를 또 갈아엎었다. 

 

그래도 이번에는 조금 더 깔끔하게 다듬었고, 결제 부분을 포인트로 대체해서 구현하기로 했다. 

 

그리고 로직들도 다듬어서 각 케이스별 처리 방법도 정리를 해두었다. 

 

또한 AWS의 EC2 및 RDS, S3 인스턴스를 만들어서 팀원들과 공유를 해두었고, 

 

코드 컨벤션으로 JpaRepository를 상속받을 것인가와 @RepositoryDefinition 으로 할 것인가를 고민해봤고, JpaRepository를 상속받은 것으로 결론이 났다. 

 

사실 나는 납득이 안 됐었다. 필요하지 않은 메서드들까지 전부 구현을 해주기 때문에 캡슐화 되지 않는다고 생각했고, 기본 제공 메서드를 테스트 코드를 작성할 수 있는 RepositoryDefinition방식이 더 맞다고 생각했는데, 이미 잘 만들어진 도구를 가져다 쓴다는 관점과, 팀원 간 표준화된 메서드를 쓸 수 있다는 장점으로 JpaRepository를 쓰는 것 같다. 

 

또한 Service 단을 인터페이스와 구현체로 구분할지 말지를 고민하다가 클래스만 만들다가 구분해야 할 상황이 오면 인터페이스와 구현체로 나누기로 했다. 

 

정말 많이 고민을 했었는데, 우선 -Impl 접미사가 붙는다는 것은 구현체가 1개라는 것을 암시하는 명명법이기도 하고, 만일 -ImplV1이 -ImplV2로 버전업이 된다고 하더라도, 그러면 -ImplV2 만 쓴다면 -ImplV1은 더 이상 사용하지 않으면서 메모리만 차지하니 삭제해도 되고, 이러면 결국 다시 구현체를 만드는게 의미가 있나 하는 문제가 생긴다. 또한 깃의 히스토리가 있으니 기존 버전으로 다시 돌릴 수도 있다. 

 

이를 튜터님께 다시 여쭤보니 우선 시스템 간 연계가 있다면 인터페이스를 쓰지만, 내부에서만 쓴다면 클래스로 쓴다고 하셨다. 

 

팀끼리 의논한게 다행히? 도 얼추 방향이 맞아가고 있다. 원래 계획은 오늘까지 완성이었지만, 사실 안 될 거 알고 있었다 ㅋㅋ 수요일에 튜터님 정기 면담이 있으니 그때를 기점으로 하려고 한다. 

 

 

 

내가 레디스를 도맡겠다고 한 만큼, 그리고 프론트도 맡겠다고 한 만큼 앞단의 전부를 내 마음대로 할 수 있어서 많이 고민을 해보고 있다. 

 

예를 들어, 기존에는 JwtUtil 객체를 기존 프로젝트에서는 Bearer 접두사를 붙여놨었는데, 지금은 제외하고 토큰을 만들도록 하거나, 아니면 토큰 유효성 검사에서 조금 더 우아하게 eum을 활용하여 통과, 만료, 거부 처리를 해두려고 하고 있다. 

 

JWT랑 Redis 장인 돼야지 

 

새벽 1시부터 젭에 들어와서 TIL을 쓰는데 이 시간까지 열심히 하는 분들이 정말 많다. 아무 팀이나 슬쩍 들어가서 보고 있으면 대부분 문제를 겪고 계시길래 같이 고민하고 또 해결해가는게 정말 재밌다.. 나 가르치는 건 정말 못하는데 문제 해결해주는 건 또 적성엔 맞는 희안한 성격을 가지고 있네 ㅋ ㅋ