모의주식 투자 웹 서비스 '무주시'를 리팩토링하며 주식 종목 검색 기능을 개선하기로 결정하였다. MongoDB의 정규식 매칭 기능을 활용하여 결과를 조회하고, 검색 빈도로 정렬하여 반환하던 구조에서 MySQL로 데이터를 이관하고 Lucene을 통하여 자체 인덱스를 구축하여 검색 경험을 개선하였다. 최종적으로 검색 결과를 우선 순위대로 정렬하기 위하여 최종 점수를 계산할 때, 검색어와 결과 매칭 점수와 검색 빈도(인기도)를 기반으로 최종 점수를 도출하는 과정과 그 과정에서 Saturation 함수를 사용한 경험을 정리하고자 한다.
모의 주식 투자 웹 서비스 '무주시' 운영 환경의 에러 모니터링과 장애 대응 속도·경험 개선을 위해 Sentry를 도입하였다. Sentry 도입 후 빌드 과정에서 QueryDSL의 Q 클래스와 충돌이 일어나며 빌드가 실패하였다. 해당 문제를 해내가며 QueryDSL 생성 방식과 충돌 원인 등을 알아보았다.
모의 주식 투자 서비스 '무주시'를 리팩토링하며 가장 먼저 한국투자증권 실시간 체결가 웹소켓 세션 및 구독 관리 구조를 되돌아보았다. 이전에도 리팩토링을 진행하였지만, 그 과정에서도 구조에 대한 몇 가지 의문이 남아있었다. 웹소켓 세션과 구독 종목 관리 책임이 혼재되어 있어 계층간 경계가 모호하다는 느낌을 받았었다. 특히, 도메인 주도 설계와 헥사고날 아키텍처의 Port&Adapter를 통해 외부 인프라와 계층간 결합도를 분리하는 중요성에 대한 지식을 얻은 뒤 기존 리팩토링 구조에 대한 아쉬움이 크게 부각되었다. 이번 포스팅에서는 기존 리팩토링 구조에서 위와 같은 아쉬웠던 문제를 개선해 피드백한 과정을 정리하고자 한다.
대기열 시스템을 학습하며, 대기열을 통과한 사용자를 참여열로 이동시킬 때 "적절한 배치 사이즈와 스케줄링 주기는 얼마인가?"라는 의문이 들었다. 배치 사이즈가 너무 크면 대기열의 의미가 퇴색되고, 너무 작으면 서버 자원이 낭비되고 사용자 대기 시간이 길어져 사용자 경험이 떨어진다. 이 글에서는 실제 테스트와 계산을 통해 적정한 배치 사이즈를 찾아본 과정을 공유하고자 한다.
학부생 때 전공 과목 프로젝트로 진행하였던 카풀 프로젝트를 도메인 주도 설계(DDD)의 헥사고날 아키텍처 기반으로 리팩토링하였다. 리팩토링 과정에서 특정 도메인을 표현하기 위해 도메인 엔티티와 VO(Value Object)를 정의하며 기능을 구현해나갔다. 이후 테스트 코드를 작성하며 스터빙(Stubbing)을 진행하고, 이를 해결하기 위해 any(...) 메서드를 사용하며 부정확한 테스트를 작성하고 있었다는 점을 인지하게 되었다. 이번 포스팅에서는 이러한 경험을 계기로 도메인 주도 설계에서 객체의 동등성 보장이 왜 중요한지에 대해 고민하고, 이를 통해 얻은 인사이트를 공유해보고자 한다.