[대규모 시스템 설계 #1] 대규모 시스템 설계 학습

개요호텔 예약 플랫폼 프로젝트를 기반으로, 대규모 시스템을 설계하는 과정에 대해 공유하는 시리즈를 시작한다.먼저, 이 글에서는 대규모 시스템이란 무엇인지, 왜 대규모 시스템을 학습하려 하는지,어떠한 상황을 가정하여 대규모 시스템으로 확장할 것인지에 대해 정리해보고자 한다.이 글이 앞으로 이어질 대규모 시스템 설계 이야기의 단단한 발판이 되길 바란다. 왜 대규모 시스템으로 설계하려 하는가?지금껏 실무에서 다뤄온 시스템은, 대부분 제한된 트래픽과 데이터를 기준으로 설계된 구조였다. 그 안에서도 병목을 줄이고 성능을 개선하려는 다양한 시도를 했지만, 데이터 규모가 커지는 순간에는 설계 자체를 다시 생각해야 한다는 점을 절실히 경험했다. 그래서 이번에는 단순히 ‘트래픽을 견디는 구조’를 점진적으로 개선하는 수준..

• format_list_bulleted 설계
• · 2025. 7. 17.

QueryDSL과 타입 안정성을 고려한 커서 설계기

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

• format_list_bulleted 설계
• · 2025. 4. 11.

JPA Pagable 변환 유틸 설계기

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

• format_list_bulleted 설계
• · 2025. 4. 4.

일관된 응답 구조 설계기

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

• format_list_bulleted 설계
• · 2025. 4. 2.

엔티티가 아니라 "도메인"을 설계하기

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

• format_list_bulleted 설계
• · 2025. 3. 31.

레이어, 패키지 구조 설계기

개요Spring Boot 멀티 모듈 초기 구성을 끝낸 후, 레이어 및 패키지 구조 설계에 대해 정리해보고자 한다 Spring Boot 멀티 모듈 프로젝트 구성개요Spring Boot 멀티 모듈 프로젝트 구성 이유 및 방법들을 해당 문서에 정리한다 목적초기 사이드 프로젝트 설계에서 어떠한 설계로 시작하는게 가장 적합할지 고찰해 보는 과정을 통해프로젝pablo7.tistory.com 목표어떠한 기준으로 레이어를 설계했는지 정리하는 과정을 통해 코드 작성에 대한 원칙을 만든다DIP (Dependency Inversion Principle)을 지킬 수 있는 패키지 구조를 고려하여가능한 기술 중심이 아닌, 기능 중심의 패키지 구조를 설계한다 기본 레이어 구조필자는 그동안 NestJS라는 프레임워크를 통해 아래와 ..

• format_list_bulleted 설계
• · 2025. 3. 23.