[사이드 프로젝트] QueryDSL과 타입 안정성을 고려한 커서 설계기

개요이 글은 이전 글 "정렬 하나에도 설계가 들어간다"의 연장선이다. Offset 기반 정렬 구조에서 성능 한계와 유지보수성 문제를 마주했고,이를 개선하기 위해 Keyset 기반 커서 방식으로 구조를 리팩토링하게 되었다.특히 QueryDSL 기반의 동적 쿼리 생성과타입 안정성을 보장하는 범용 커서 설계를 어떻게 구현할 수 있을지에 대해 집중했다. 이 과정에서 필자는 스스로에게 다음과 같은 질문을 던지게 되었다:다중 정렬이 필요하다면, 커서 값은 어떻게 쿼리에 반영되어야 할까?커서 값이 동일한 데이터가 여러 개인 경우, 중복 조회 문제는 어떻게 해결할 수 있을까?커서 방식의 동적 쿼리를 어떤 책임 단위로 나누는 것이 좋을까?QueryDSL 쿼리 구조와 정렬 기준을 어떻게 추상화할 수 있을까?커서 타입이 다..

• format_list_bulleted 개발 일기
• · 2025. 4. 11.
• textsms

[사이드 프로젝트] 정렬 하나에도 설계가 들어간다

개요이번 글은 "단순한 조회"를 넘어,정렬/페이징/쿼리 조건까지 어떻게 설계했는지를 기록한 글이다. 조회 API는 간단해 보이지만, 도메인과 사용자 경험에 가장 밀접한 영역이다.  필자는 이번 사이드 프로젝트에서 조회 API 기능을 구현할 때,"어떤 기술을 선택하는게 가장 합리적일까?""어떻게 해야 도메인 비즈니스에 특화된 조회 API의 정렬 기능을 통합할 수 있을까?"와 같은 질문을 반복해서 던졌던 것 같다.이번 글에서는 작은 욕심에서 시작된, 정렬 기능 설계 과정을 정리해보려 한다   정렬 조건은 단순하지 않았다필자는 사실 처음엔, 조회 API에서의 정렬 값을 단순한 문자열로 받을 계획이었다. 그 이유는, 도메인마다 정렬할 수 있는 필드가 모두 다를 수밖에 없다고 생각했기 때문이다.  예를 들어 아래..

• format_list_bulleted 개발 일기
• · 2025. 4. 4.
• textsms

[고찰하기] Lock 전략을 결정하는 건 기술이 아니라 도메인이다

개요이번 글은 동시성 문제 해결 전략에 대한 이야기다.사이드 프로젝트에서 약관 도메인의 생성 및 수정 API를 구현하면서,  동시성 이슈가 발생할 수 있는 지점이 존재했다.Spring Data JPA는 이를 해결하기 위한 강력한 기능을 제공한다.  어쩌면 이 글은 그냥 `@Version` 하나로 끝낼 수도 있었을 것이다.하지만 나는 단순히 동시성 문제를 "해결"하는 데서 멈추고 싶지 않았다.> "이 도메인에서는 어떤 방식이 가장 합리적일까?"이 질문을 던지며,  도메인의 특성과 시스템의 본질을 기준으로 기술 선택을 내리고자 했다.이번 글에서는  "기술보다 중요한 것이 무엇인가"에 대한 고민을 정리해보려 한다.   문제 인식먼저 약관 도메인 특성에 대해 잠시 설명하고자 한다.(약관 도메인 분석에 대해서는 ..

• format_list_bulleted 개발 일기
• · 2025. 4. 3.
• textsms

[사이드 프로젝트] 일관된 응답 구조 설계

개요이번 글은 "응답 구조 설계"에 대한 이야기다.사이드 프로젝트에서 약관 도메인의 CRUD API를 구현하면서,  수차례 API를 디버깅할 때마다 응답 형식이 제각각이라는 찜찜함을 느꼈다. "내가 예상치 못한 예외가 발생했을 때 보안에 치명적인 응답을 하면 어떡하지?""응답에 있어 성공과 예외 발생을 무엇으로 구분하지?" 이건 단순히 보기 불편한 문제가 아니다.  프론트엔드와 협업,  에러 상황의 예측,  API 명세의 신뢰성까지 흔들릴 수 있는 문제였다.그래서 생각했다."API는 항상 같은 방식으로 말해야 한다."이번 글에서는  스프링 환경에서 어떻게 일관된 응답 구조를 설계했고,  왜 그게 중요한 선택이었는지를 정리해보려 한다.   목표일관된 응답 구조 설계를 고민하게 된 첫 번째 이유는  "예상치..

• format_list_bulleted 개발 일기
• · 2025. 4. 2.
• textsms

[고찰하기] 필요한 기능만 의존하게 하자

개요이번 글은 의존성 관리에 대한 이야기다.사이드 프로젝트에서 약관 도메인의 CRUD API를 구현하면서,공통 모듈의 기능을 그대로 사용하는 것이 의도치 않은 위험성을 유발할 수 있음을 깨달았다."필요하지 않은 기능까지 의존하게 되는 구조가 안전한 설계라고 볼 수 있을까?"이 질문을 던지며,어떻게 하면 공통 모듈의 장점은 살리면서도 안전하게 분리된 설계를 만들 수 있을지 고민하게 됐다.이 글에서는 그 고민의 과정을 통해 정립된,필자의 의존성 관리 철학과 구조 설계 원칙을 정리해보고자 한다.   목적필자는 앞선 “레이어 및 패키지 구조 설계” 글에서  과거에 범했던 의존성 설계의 실수에 대해 돌아봤다.WHY?코드 재사용성을 높이겠다는 명분 아래,  여러 레이어 간 상호 의존을 허용한 결과,  서비스 객체는..

• format_list_bulleted 개발 일기
• · 2025. 4. 1.
• textsms

[고찰하기] 엔티티가 아니라 "도메인"을 설계하기

개요이번 글은 단순히 JPA 엔티티를 어떻게 설계했는지 정리하고자 하는 글이 아니다. 필자가 이번 사이드 프로젝트의 약관 도메인을 구현하면서,무엇을 고민했고, 어떤 기준으로 설계했는지를 돌아보며 정리한 글이다.이 과정을 통해 앞으로 도메인 설계 시, 스스로 사고하고 판단할 수 있는 틀을 만들고자 했다.즉, 도메인을 설계하는 사고방식에 대해 정리하고자 한다.목표이번 글을 통해 필자는 “도메인을 어떻게 바라보고 설계할 것인가”에 대한 나만의 기준을 세우고자 한다.  단순히 현재의 설계를 회고하는 것을 넘어, 앞으로 다른 도메인을 마주했을 때에도,같은 기준으로 사고하고 판단할 수 있도록 “설계의 중심에 둘 철학”을 명확히 하고 싶었다.   그렇다면 필자는 이번 도메인을 설계할 때 어떤 기준을 중심에 두고 있었..

• format_list_bulleted 개발 일기
• · 2025. 3. 31.
• textsms