객체지향책을 다시 읽으면서 깨달은 건, 좋은 설계란 단순히 클래스를 예쁘게 나누는 게 아니라 변경이 생겼을 때 덜 흔들리는 구조를 만드는 일이라는 점이다. 그래서 이제는 데이터보다 먼저 객체들이 어떤 행동을 하고 어떤 책임을 질지, 메시지는 어떻게 오갈지를 고민해 변경이 퍼지는 방향을 좁히는 쪽으로 설계하려 한다.

측정 데이터 목록 조회에서 최신 20건만 필요함에도 조인 순서 때문에 수집 로그 테이블에서 불필요한 읽기가 많이 발생하고 있었다는 문제를 STATISTICS IO/TIME으로 확인했습니다. 인덱스를 넣어 측정 테이블 읽기를 줄이고, 결국 먼저 20건을 뽑아서 그 결과만 로그와 대상자 테이블에 조인하는 구조로 바꿔 전체 logical reads를 약 98% 줄였습니다.

레거시 iBatis 기반 프로젝트를 Spring Boot 3로 옮기며 등록·수정·삭제처럼 도메인 규칙과 변경 의도가 코드에 드러나는 부분은 JPA로 옮기고, 대시보드·검색·통계처럼 결과 모양을 SQL이 직접 만들어내는 조회는 MyBatis로 유지하기로 했습니다. 핵심은 기술을 섞는 것이 목적이 아니라 전환 리스크와 기능 성격에 따라 바꿀 것과 유지할 것을 명확히 나누는 현실적인 결정이었습니다.

레거시 eGov·XML 기반 권한을 Spring Security로 옮기면서 로그인은 되는데 이후 권한 동작(메뉴 노출 vs URL 접근 제어, 로그인 정책, 세션 연계 등)이 기존과 달라지는 문제가 생겼습니다. 해결은 단순 데이터 이식이 아니라 Authentication·SecurityContext·세션·URL 필터와 로그인 전 정책 검사(IP, 중복 로그인 등)를 다시 연결해 권한 흐름 전체를 복원하는 쪽으로 접근한 것이 핵심이었습니다.

DDD 맥락에서 CQRS를 꼭 인프라 분리로 시작할 필요는 없다는 이야기입니다 — 쓰기와 조회의 관심사가 달라지며 서비스가 비대해질 때 같은 DB를 쓰더라도 CommandService와 QueryService로 책임을 분리해 코드를 더 명확하게 만들면 된다는 결론입니다.