검증, 판단시 - 쿼리 사용 vs 조회 후 서비스에서 판단

[koreaioi]

검증, 판단시 - 쿼리 사용 vs 조회 후 서비스에서 판단

여러분들은 다음과 같은 검증이나 판단이 필요할 때, sql 쿼리를 사용하나요? 아니면 조회하여 서비스에서 판단하나요?
본인의 기준이 있다면 설명해주세요.

예시

• 사용자가 이미 해당 슬롯에 예약 또는 대기 중인가?
• 해당 슬롯에 이미 RESERVED 예약이 존재하는가?

[softmoca]

저는 이 질문이 사이클1에서 깊게 다뤘던 비즈니스 규칙은 어디에 있어야 하는가와 정확히 같은 본질의 질문이라고 생각합니다.

쿼리로 판정하느냐 / 조회 후 Service에서 판정하느냐는 단순한 구현 선택이 아니라,
그 규칙의 본체가 어디 사느냐를 정하는 일입니다.
그리고 그 결정은 규칙의 성격마다 달라야 한다고 봅니다.

저는 "조회 후 도메인에서 판단"을 기본으로 두되, (1) 시스템 전체 상태에 의존하거나 (2) 동시성 보호가 필요한 규칙은 DB에 맡긴다를 기준으로 삼고 있습니다.

그래서 둘은 양자택일이 아니라, 같은 규칙을 도메인 + DB 제약의 조합으로 함께 지키는 경우가 많다고 생각합니다.

1. 질문의 본질 — 책임의 위치를 정하는 일

표면적으로 이 질문은 "쿼리 한 번이 빠르냐, 조회 후 자바 로직이 명확하냐"의 트레이드오프로 보입니다.

하지만 사이클1 토론에서 정리했듯, 진짜 질문은 이거라고 생각합니다.

이 비즈니스 규칙(중복 거부, 본인 예약 확인 등)의 본체가 어디에 살아야 하는가?

• 쿼리로 판정 → 규칙의 본체가 SQL의 WHERE 절에 산다
• 조회 후 Service에서 판정 → 규칙의 본체가 자바 도메인에 산다

이건 단순 성능 비교가 아니라 책임 분배의 문제입니다.

그래서 매번 같은 답이 나올 수 없고, 규칙의 성격에 따라 달라져야 한다고 생각합니다.

2. 쿼리로 판정하는 방식의 강점과 약점

// 쿼리에서 판정
boolean exists = reservationRepository
        .existsByDateAndTimeIdAndThemeIdAndStatus(date, timeId, themeId, RESERVED);
if (exists) throw new BusinessRuleViolationException(...);

강점

• 빠르다: DB가 인덱스로 답하므로 ms 단위. 전체 조회보다 효율적
• 동시성에 강하다: 그 순간의 진실을 봄. 메모리에 올린 뒤 체크하는 것보다 안전
• 메모리 부담이 없다: 결과 row 0개 또는 1개만 받으므로 가볍다
• 시스템 전체 상태를 봐야 할 때 필수 (예: 이메일 유일성)

약점

• 규칙이 SQL에 박힌다: 자바 단위 테스트로 닿을 수 없어 통합 테스트가 강제됨
• 이름이 규칙을 못 드러낸다: existsByDateAndTimeIdAndThemeIdAndStatus는 "데이터 접근"의 이름이지 "비즈니스 판정"의 이름이 아님. 규칙의 의도가 코드에서 잘 추론되지 않음
• 규칙 변경 시 SQL 수정 필요: "30분 이상 차이면 중복 아님" 같은 변형이 들어오면 SQL이 복잡해짐
• Mock으로 우회되기 쉽다: 사이클1 토론에서 정리한 "Mock이 거짓말한다"의 함정

3. 조회 후 Service/도메인에서 판정하는 방식의 강점과 약점

// 조회 후 도메인에서 판정
List<Reservation> sameDate = reservationRepository.findByDate(date);
Reservations reservations = new Reservations(sameDate);
reservations.validateNotDuplicate(date, timeId, themeId);

강점

• 규칙이 도메인에 응집된다: Reservations.validateNotDuplicate(...)가 규칙 자체를 표현
• 단위 테스트가 가능하다: DB 없이 1~5ms로 케이스 다양화 가능
• 규칙 변경에 강하다: 자바 로직 수정으로 충분, 테스트도 빠르게 회귀 검증
• 이름이 규칙의 언어: 코드에서 의도가 즉시 추론됨

약점

• 메모리 비용: 같은 날짜 예약 N건을 모두 메모리에 올림
• 동시성 위험: 사이클1 도메인 분리의 한계에서 정리했듯, "조회 시점"과 "저장 시점" 사이에 다른 트랜잭션이 끼어들면 메모리의 데이터가 더 이상 진실이 아님
• DB 인덱스 활용을 못 한다: 전체 조회 + 메모리 필터링이 인덱스 카운트보다 비효율적일 수 있음
• 시스템 전체 상태에는 안 맞음: 1000만 사용자에서 "이메일 중복인가"를 도메인으로 빼는 건 부적절

4. 제 판단 기준 — 규칙의 성격으로 갈라본다

사이클1 토론에서 정리한 분류를 그대로 이어가면, 저는 세 갈래로 봅니다.

Type 1: 입력값만으로 판정 가능 → 무조건 도메인

• 이름 30자 이하, 과거 시점 거부, 영업시간 내 검증
• 외부 상태 무관 → 쿼리로 갈 이유 자체가 없음

Type 2: 좁은 범위 상태에 의존 → 도메인 + DB 안전망

• 같은 슬롯의 중복 예약, 본인 예약·대기 중복 확인
• 의존 데이터 크기가 작다 (시간 슬롯 수만큼, 한 사용자의 예약만큼)
• → 도메인으로 빼는 게 합리적, 단 동시성 위험은 DB UNIQUE 제약으로 2차 방어

Type 3: 시스템 전체 상태에 의존 → DB에 위임

• 이메일 전체 유일성, 동시 예약 한도, 인기 테마 집계
• 전체 데이터를 메모리에 올릴 수 없음, 동시성·인덱스 활용 필수
• → 쿼리로 판정, 또는 DB 제약/락에 위임

핵심: 이 분류의 기준은 "쿼리가 빠른가"가 아니라 의존 데이터의 범위와 크기입니다.

데이터가 작고 좁은 범위면 도메인이 다룰 수 있고, 크고 전역이면 DB가 더 잘합니다.

5. 질문에 주신 두 예시를 적용해보면

예시 1. "사용자가 이미 해당 슬롯에 예약 또는 대기 중인가?"

의존 데이터를 보면:

• "이 사용자의" 예약·대기 중에서 "이 슬롯과 일치하는 것이 있는가"
• 의존 범위: 한 사용자의 예약·대기 (보통 매우 적음, 수십 개 이하)

→ Type 2입니다. 도메인으로 빼서 검증하기 좋다고 봅니다.

// 한 사용자의 예약·대기를 모아 도메인 객체로
MyReservationsAndWaitings my = reservationService.findMineWithWaitings(memberId);
my.validateNoConflict(slot);

이렇게 하면 "내 예약·대기와 충돌이 무엇인가"라는 규칙이 도메인에 응집되고, 단위 테스트로 다양한 케이스(예약만 있을 때, 대기만 있을 때, 둘 다 있을 때, 취소된 것 제외 등)를 빠르게 검증할 수 있습니다.

다만 단순히 "있나 없나"만 묻는 거라면 existsByMemberIdAndSlot 쿼리도 합리적인 선택입니다.

규칙이 복잡해질 가능성이 있다면 도메인으로 빼고, 단순 boolean이고 변경 가능성이 적다면 쿼리로 두는 식입니다.

예시 2. "해당 슬롯에 이미 RESERVED 예약이 존재하는가?"

이건 본질적으로 같은 형태지만 결이 다릅니다.

• 의존 범위: 이 슬롯의 모든 예약
• 데이터 크기: 한 슬롯의 RESERVED 예약은 최대 1개 (그게 비즈니스 규칙이니까)
• 동시성 위험: 매우 크다 — 같은 슬롯에 동시 요청이 몰리면 둘 다 통과하고 둘 다 저장될 수 있음

→ Type 2이긴 하지만 동시성 위험이 강한 케이스입니다.

저라면 이렇게 합니다.

1. 도메인 + 좁은 조회로 1차 방어 (사용자에게 친화적 에러 메시지)
2. DB UNIQUE 제약으로 2차 방어 (동시성 안전망)

// 1차: 도메인 검증
boolean alreadyReserved = reservationRepository
        .findReservedBySlot(slot)
        .isPresent();
if (alreadyReserved) throw new BusinessRuleViolationException(...);

// 2차: DB 제약 (schema.sql)
// UNIQUE(date, time_id, theme_id) WHERE status = 'RESERVED'

1차만으로는 동시성에서 뚫리고, 2차만으로는 좋은 에러 메시지를 못 줍니다.

둘은 보완 관계입니다. 사이클1 토론에서 정리한 "어떤 규칙은 도메인 + DB 제약의 조합으로 함께 지켜야 한다"가 정확히 이 상황입니다.

6. 한 가지 더 — 이름의 신호

사이클1 토론에서 정리한 통찰 중 하나가 이름이 책임의 위치를 드러낸다는 것이었습니다.

• existsByDateAndTimeIdAndThemeId → "데이터가 있나 없나"라는 데이터 접근의 언어
• hasDuplicateReservation → "중복인가"라는 비즈니스 판정의 언어

Repository 메서드 이름이 비즈니스 판정 언어에 가까워지면, 그건 책임이 잘못된 위치에 있다는 신호일 수 있습니다. Repository는 "찾아주는" 책임이고, "판정하는" 책임은 도메인입니다.

// 책임이 모호한 패턴
reservationRepository.existsByDateAndTimeAndTheme(...)  // 판정에 가까운 이름

// 책임이 명확한 패턴
reservationRepository.findReservedBySlot(slot)          // 데이터 접근
reservations.hasDuplicate(slot)                          // 판정

이건 두 방식 중 어느 쪽을 고르든 적용되는 원칙입니다.

쿼리로 판정하더라도 메서드 이름을 데이터 접근의 언어로 두고, 판정은 호출하는 쪽에서 명시적으로 하는 게 좋다고 생각합니다.

7. 정리 — 제 기준

쿼리 vs 조회 후 판단은 양자택일이 아니라 규칙 성격에 따른 분배의 문제다. 그리고 동시성·정합성이 걸린 규칙은 둘 다 하는 경우도 많다.

제가 따르는 기준:

신호	선택
입력값만으로 판정 가능	도메인 (외부 의존 없음)
좁은 범위 상태에 의존, 데이터 작음	도메인 + DB 제약 안전망
시스템 전체 상태, 데이터 큼	쿼리 (DB에 위임)
동시성 보호 필수	DB UNIQUE/락 (도메인은 사용자 친화 메시지용 1차 방어)
규칙이 자주 바뀔 것 같음	도메인 (단위 테스트로 빠른 회귀)
단순 boolean이고 변경 적음	쿼리도 합리적

핵심 사고

• "쿼리가 빠르니까"가 아니라 "이 규칙이 어디 살아야 자연스러운가"부터 묻는다
• 메모리 비용·동시성 위험·테스트 비용을 함께 본다
• 둘 다 하는 게 정답인 경우가 많다 — 도메인은 친화적 검증, DB는 최종 방어

질문에 주신 두 예시는 둘 다 Type 2 영역이라 도메인으로 빼는 게 좋다고 봅니다.

다만 "RESERVED 예약 중복"은 동시성 위험이 크므로 DB UNIQUE 제약을 반드시 함께 두고, "본인 예약·대기 중복"은 동시성보다 규칙 자체의 명확성이 더 중요하니 도메인 검증이 핵심이라고 생각합니다.

[koreaioi]

저는 "이 판정 로직을 나중에 수정, 확장할 때, 어디를 고치는 게 자연스럽고 테스트하기 쉬운가?" 를 고민해 결정하려고합니다.

---

이번 미션에서의 예시 2가지를 들어보겠습니다.

1. 예약 요청

두 가지 검증이 필요합니다.

1. 내가 이미 예약한 슬롯은 추가로 예약할 수 없다.
2. 다른 사람이 예약했다면 대기가 된다.
   이 두 검증은 exists 쿼리 두 번으로 빠르게 처리할 수 있습니다.

하지만 "대기자 10명이 넘으면 마감" 요구사항이 추가되는 순간, 쿼리 기반 로직은 변경이 광범위해집니다. 반면 처음부터 List<Reservation>으로 조회했다면, 해당 컬렉션에 검증 로직만 추가하면 됩니다.

"내가 이미 예약한 슬롯인지", "다른 사람이 예약했는지"는 결국 특정 슬롯의 예약+대기 목록을 탐색하는 일입니다. 어차피 같은 범위를 보는 거라면, 쿼리를 여러 번 나눠 쓰는 것보다 한 번 조회 후 Reservations라는 일급 컬렉션으로 포장해 로직을 응집하는 게 수정·확장에 훨씬 유리합니다.

---

2. 예약 취소

예약 취소 시 대기 1순위를 RESERVED로 승격해야 합니다. 이때 대기 1순위를 찾는 방법이 두 가지입니다.

• 쿼리로 직접 조회: Optional<Reservation>으로 대기 1순위만 가져오기
• List로 조회 후 서비스에서 탐색: List<Reservation> 전체를 가져와 도메인에서 꺼내기
  단순히 "지금 당장 빠른 것"만 보면 쿼리 한 번이 맞습니다. 그러나 "VIP는 순번과 무관하게 재정렬 시 우선 선점" 같은 요구사항이 추가되면 이야기가 달라집니다.

"누가 1순위인가"라는 판정은 비즈니스 규칙입니다. 지금은 단순 순번이지만, VIP·등급·예약 이력 등 기준이 얼마든지 복잡해질 수 있는 영역입니다. 그렇기 때문에 그 판정을 SQL에 두는 것보다 도메인에 두는 게 자연스럽습니다.

---

쿼리 사용

이런 관점에서 닉네임 중복 검증과 같이 DB 전체를 확인해야한다면, 쿼리로 판단하는 게 좋겠죠.
모두 조회하여 서비스단에서 검증하기엔 수정·확장할 이유와, 테스트로 얻을 이점이 적기 때문입니다!

[sangjun121]

앞서 두분이 말씀해주신 내용과 조금은 결이 다른 기준이라고 생각이 드는데요, 저는 유스케이스가 감춰지는가를 기준으로 결정할 것 같습니다.

쿼리에 작성하면, 유스케이스에 감춰지는 경우

송송님이 남기신 코멘트를 읽어보니 예약이 존재하는 경우 예약 생성을 보내면 예외가 발생하는 것이 아닌, 자동으로 대기 상태가 되는 것으로 이해했습니다. 이때 진행하는 두가지 검증은 서로 다른 종류이며 SQL에서 한번에 처리하는 경우 유스케이스가 감춰질 수 있다고 생각이 듭니다.

물론 쿼리가 두번 나간다는 측면에서는 불리하지 않은거 아닌가 생각이 들 수 있지만, 인덱스로 걸어둔다면 현재 규모에서 성능적인 차이는 미비할 것 같습니다. 그래서 저는 오히려 유스케이스를 드러내는 것이 좋다고 생각합니다.

쿼리에 작성하더라도, 유스케이스가 감춰지지 않는 경우

오히려 반대로, 슬롯을 조회해서, 현재 예약 가능한 시간 목록을 불러온다고 가정해볼게요. 이 상황에서 exist로 reservation을 조회해서, reservation_time에 예약이 하나라도 있는 경우는 해당 reservation_time에 reserved라는 boolean값을 한번에 불러오는 쿼리를 고민해볼 수 있을 것 같습니다.

물론 reservation_time를 모두 불러오고, reservation에 해당 슬롯에 존재하는 모든 time을 불러와 서비스에서 두개를 비교하며 공통되는 경우, 예약된 것으로 판단하는 로직을 작성할 수도 있을 것 같은데요, 이는 SQL에서 한번에 처리하더라도 "현재 예약 가능한 시간을 조회한다."라는 유스케이스가 코드에 명확히 드러나기 때문에 사용해도 무방하다고 생각합니다!