QueryDSL Q클래스 생성 방식과 QueryDSL-Sentry plugin 충돌 해결
모의 주식 투자 웹 서비스 '무주시' 운영 환경의 에러 모니터링과 장애 대응 속도·경험 개선을 위해 Sentry를 도입하였다. Sentry 도입 후 빌드 과정에서 QueryDSL의 Q 클래스와 충돌이 일어나며 빌드가 실패하였다. 해당 문제를 해내가며 QueryDSL 생성 방식과 충돌 원인 등을 알아보았다.
Etc
기타 학습 내용에 대한 정리
대기열에서 참여열로, 적정 배치 사이즈는 얼마일까?
대기열 시스템을 학습하며, 대기열을 통과한 사용자를 참여열로 이동시킬 때 "적절한 배치 사이즈와 스케줄링 주기는 얼마인가?"라는 의문이 들었다. 배치 사이즈가 너무 크면 대기열의 의미가 퇴색되고, 너무 작으면 서버 자원이 낭비되고 사용자 대기 시간이 길어져 사용자 경험이 떨어진다. 이 글에서는 실제 테스트와 계산을 통해 적정한 배치 사이즈를 찾아본 과정을 공유하고자 한다.
DDD를 적용하며 깨달은 객체 동등성의 중요성
학부생 때 전공 과목 프로젝트로 진행하였던 카풀 프로젝트를 도메인 주도 설계(DDD)의 헥사고날 아키텍처 기반으로 리팩토링하였다. 리팩토링 과정에서 특정 도메인을 표현하기 위해 도메인 엔티티와 VO(Value Object)를 정의하며 기능을 구현해나갔다. 이후 테스트 코드를 작성하며 스터빙(Stubbing)을 진행하고, 이를 해결하기 위해 any(...) 메서드를 사용하며 부정확한 테스트를 작성하고 있었다는 점을 인지하게 되었다. 이번 포스팅에서는 이러한 경험을 계기로 도메인 주도 설계에서 객체의 동등성 보장이 왜 중요한지에 대해 고민하고, 이를 통해 얻은 인사이트를 공유해보고자 한다.
UUID vs ULID, 인덱스로 사용하는 값에 따른 성능 비교
최근 이메일 발송 기능의 실행을 보장하기 위하여 Transactional Outbox Pattern을 적용하기 위해, 프로젝트 일부에 Event 기반 구조를 도입하게 되었다. 이벤트를 아웃박스로 변환하여 저장할 때, 이벤트를 식별하기 위한 식별자가 필요하였다. Spring Event를 통한 이벤트, 아웃박스 제어를 위해 식별자를 애플리케이션 레벨에서 생성하고 저장하며 Non-Sequential 식별자를 사용하게 되었다. 이 과정에서 UUID보다는 ULID로 값을 저장하였을 때 성능적으로 발생할 수 있는 이점에 대해 알아본 경험을 공유하고자 한다.
Github Pull Request Helper 크롬 확장 프로그램 개발
협업을 하며 Github Pull Request를 확인하는 것이 일상이 되었다. Pull Request 작성자가 올린 PR Description을 이용하여 기능과 코드의 명세를 확인한다. 이때, PR Description을 확인하기 위해 변경사항(File Changed) 탭을 번갈아 확인하는 과정을 반복하며 불편함을 느끼고 있었다. 그러던 중 변경사항 탭에서도 PR Description을 확인할 수 있다면, 사용자 경험 측면에서도 되게 편리할 뿐더러 불필요한 페이지 이동과 PR Description API 호출이 줄어들 것이라 생각하여 이를 적용할 방법을 생각해보았다. 그러던 중 평소에도 Github 관련 크롬 확장 프로그램(Chrome Extension)을 사용하였기에 이를 활용하여 나만의 크롬 확장 프로그램을 만들어보기로 하였다.
스프링부트 사용 시 Tomcat 의존성이 추가되는 원리
Spring AOP에 대해 공부하던 중, Spring-Transaction 디펜던시의 @Transactional 어노테이션도 횡단 관심사로써 서비스 코드 전반에 걸쳐 적용되어 AOP를 사용하는 것일텐데, 어떠한 방식으로 적용이 되는지 의문이 들어 해당 내용에 대해 찾아보기 시작하였다. 이는 스프링의 빈 등록 방식과 빈 후처리기(BeanPostProcessor)과 연관이 있었고, 이를 알아보기 위해 스프링의 빈이 등록되는 과정을 찾아 보게 되었다. 그 중 Tomcat 의존성이 어떠한 방식으로 추가되며, 이를 통해 단순 Servlet 애플리케이션과 Reactive 애플리케이션이 어떠한 원리로 분리되어 의존성을 주입받게 되는지에 대한 원리를 알아보고자 한다.
Java Generic Type Erasure
DTO에 대한 정적 팩토리 메서드를 구성하던 중 메서드 오버로딩을 통해 List를 인자로 받게 되었다. 제너릭 부분에 위치한 타입이 다르기 때문에 메서드 오버로딩이 가능할 것이라고 생각했지만 인텔리제이에서 예상치못한 오류를 만나게 되었다. Java의 타입 소거(Tryp Erasure)에 의해 발생하는 문제로, 해당 문제를 분석하며 알게된 정보들을 공유하고자 한다.
테스트 코드 작성의 중요성과 Mockito를 통한 테스트
대학교 종합설계 수업 프로젝트를 진행하며 테스트 코드 작성을 통한 코드 완성도를 하나의 목표로 하였다. 필자는 이전부터 Mock 객체를 사용한 테스트 코드 작성에 대해 의문점을 가지고 있었다. 이번 프로젝트를 진행하며 예외 상황을 고려하지 못하여 코드를 수정할 소요가 생기면서 테스트의 중요성을 깨닫게 되어 이 경험을 정리해보고자 한다.
Singleton
Effective Java를 읽던 중 Singleton 디자인 패턴에 관한 내용을 읽었다. Spring을 사용하다보면 "Bean은 싱글톤으로 관리된다"는 이야기를 자주 들을 수 있다. 또한, Spring을 사용해서 프로젝트를 진행할 때 마다 싱글톤이란 개념을 알고는 있었지만 이에 대해 깊게 생각해본 적은 없었던 것 같다. 기본적인 싱글톤 패턴의 개념부터 멀티 쓰레드 환경에서 주의사항에 대해 알아보고자 한다.
git merge 전략
본 포스팅은 기존 블로그(https://velog.io/@hky035/git-merge)에서 작성된 포스팅입니다.