강사님 안녕하세요. 쿠폰 조회 로직 구조 관련해서 의견 여쭤봅니다.현재 제 구현은 findBestBenefitCoupons에서 DB(Querydsl) 쿼리 하나로- 대상 필터링(INCLUDE/EXCLUDE, 기간, 상태),- 할인금액 계산,- 적용가능 여부 정렬,- 페이지네이션(Slice)까지 전부 처리하고 있습니다.그런데 쿼리가 너무 복잡해져서,“DB에서는 가능한 필터링/후보 추출만 하고, 복잡한 적용 규칙/최종 정렬은 애플리케이션 레이어에서 처리”하는 방식으로 바꿔도 괜찮을지 고민 중입니다.제 가정은 사용자별 쿠폰 수가 많아도 수천 장 수준이라 앱 처리도 감당 가능하다는 점입니다.강사님 코틀린 예제CouponTargetReader)는 DB는 타겟 조회 중심이고 조합은 앱에서 하는 패턴으로 보였는데,제 케이스(최적 쿠폰 + 페이징)에도 이 방향이 실무적으로 타당할까요?아니면 정렬/페이징 일관성 때문에 핵심 랭킹 로직은 DB에 유지하는 게 더 맞을까요?추가로 궁금한 점이 있습니다.대규모 커머스 회사에서는 이런 “최적 쿠폰 목록” 문제를 보통 어떻게 처리하나요?쿠폰 목록은 조건(회원/주문금액/대상/기간)이 많아서 캐싱도 쉽지 않아 보이는데,실무에서는 어떤 식으로 분리(DB/애플리케이션/배치/사전계산)하고 어떤 기준으로 설계 결정을 내리는지 궁금합니다.저는 지금 소규모 서비스에서 개발 중이라,대규모 트래픽/대량 데이터 환경에서의 실무 관점 인사이트를 얻고 싶습니다.판단 기준(데이터 건수, 성능 임계치, 페이지 정합성, 운영 복잡도)도 함께 조언 부탁드립니다. 

안녕하세요!강의를 다 보고 이 프로젝트를 제 손으로 다시 작성해보려고 합니다.코드를 눈으로 쭉 봤지만 SQL, 데이터베이스 구조 등은 정확히 들여다보지는 않았기 때문에...무엇보다도 코드를 느끼려면 다시 작성해보고 테스트도 보고 그러는게 좋을 것 같아서요. 완전 같게 작성하기 보다는 강의에서 해주셨던 부분들 개선해보거나 바꿔보거나 하려고요 저는 python 개발자이기 때문에 Spring 대신 FastAPI, JPA 대신 sqlalchemy 를 사용하려 합니다.작성하려고 보니 어떤 순서로 작성하는 것이 좋을까 질문 드려도 되나 싶어서 질문 올려봅니다. 일단 제 생각에는 v1/products 부터 시작 하려고 하는데우선은 프로젝트 구조부터 간단히 잡고 그 다음은도메인 클래스, 엔티티, productService, controller 순서로 구현/테스트 코드 작성v1/products 가 완성되면 서버 실행해서 동작 확인그 다음은 뭐 v1/products/{productId} 이런 순서로 작성해보려고 하는데요 재민님은 혹시 이 프로젝트 만들때 어떤 순서로 구현하셨는지?혹시 테스트부터 시작 하시는지? 처음 시작할 때 의 팁 있으시면 공유 부탁 드립니다 좋은 강의 감사합니다! 

강의 잘 듣고 있습니다! 수강중 궁금한 내용이 있어서 남겨요. CartItem 개념객체가 ProductOption을 알고 있지만 CartItemResponse를 보니 장바구니에 노출 시켜줄 때는 오직 Product의 가격으로만 노출 켜주고 있더라고요. 장바구니에 담기는 단위, 기준이 ProductOption이지만 CartItemResponse에서는 product의 가격으로 노출 시키고 있는 이유가 궁금합니다!또한 ProductOption의 Price는 Product의 Price와 별개로 봐야 하는건가요?그리고 ProductOption 단위 하나로 옵션개념이 잡혀있는 것 같은데 (ex: 색상:REDㅣ사이즈:M), 만약 이 옵션들이 하나의 단위가 아닌 개별로 데이터를 가지게 된다면 어떻게 해야할까요?(ex: 색상:RED +3000원 - 사이즈:M +500원)(ex: 색상:BULE +3000원 - 사이즈:M +1000원)

안녕하세요..열심히 강의를 듣고 싶지만 프로젝트가 그레이들 인식을 하지 못해서 코드조차 제대로 못보고 있습니다ㅠ 지금까지 해본 것intellij cache invalidate.idea 파일 삭제 후 그레이들 재빌드gradle.properties jdk 21 버전으로 되어 있어서 프로젝트 구조 및 세팅 모두 jdk 21로 동일하게 맞춤세팅에서 gradle default로 되어 있는거 intellij로 옵션도 변경 시도인텔리제이 업그레이드 (2023년 버전 -> 2025년)./gradlew build clean 명령어는 정상적으로 되는 것을 확인마음 잡고 오랜만에 공부하려 했는데 시작조차 안돼서 답답하네요 흑흑 ,,,어떻게 하면 좋을까요?

안녕하세요. 최근 객체 간 의존 방향 고민에 많은 시간을 쏟고 있어 질문드립니다.핵심 질문도메인/서비스 간 의존 방향을 결정할 때 어떤 기준을 적용하면 좋을까요? "누가 누구를 알아야 하는가"에 대한 판단 기준이나 원칙이 있을까요? 저는 덜 중요한 개념의 변경이 중요한 개념에 영향을 주면 안된다고 생각하고 있었습니다. 그래서 중요한 개념이 덜 중요한 개념을 모르도록 코드를 짜려고 노력하는데요. 막상 개발할 때는 이게 잘 안되어서 고민에 시간을 많이 사용하거나, 타협하곤 합니다. 이런 상황이 이번 강의를 보면서도 나타나 질문글을 작성하게 되었습니다. 구체적인 상황그런데 강의에서 download 메서드를 CouponService로 이동하는 과정을 보고 다음과 같은 의문이 들었습니다:변경 후 구조:CouponService → OwnedCoupon, OwnedCouponRepository 의존OwnedCoupon → Coupon, CouponRepository 의존우려 사항:Coupon과 OwnedCoupon이 서로를 알게 되는 것이 순환 참조나 강결합을 유발하지 않을까? OwnedCoupon에 필드 추가 시, 기존에는 OwnedCouponService만 수정하면 됐지만 이제는 CouponService도 함께 수정해야 함논리적으로는 CouponService에 download 기능이 있는 것이 맞아 보이지만, Coupon과 OwnedCoupon이 서로 알게 되는 것이 괜찮은 설계인가? 이런 고민에 시간을 많이 쓰다 보니 개발 시간이 부족하다고 느껴집니다. 마감을 위해 구현 후 리팩토링하는 방식으로 진행하고 있지만, 리팩토링을 못할 때도 많고 마음의 짐으로 남는 것 같습니다.조언 부탁드립니다. 감사합니다.

안녕하세요 강사님. 지난번 '어드민 예약 변경 시 쿠폰 회수' 관련 질문을 드렸던 수강생입니다. 답변 주신 내용을 바탕으로 설계를 보완하던 중, 스냅샷 데이터의 범위와 확장성에 대해 추가적인 고민이 생겨 조언을 구합니다.[현재 아키텍처 상황] 현재 예약 테이블에는 예약 시점의 가격 정보를 JSON 형태의 스냅샷으로 저장하고 있습니다.이유: 가격 결정 요소(할인, 이벤트, 기업 지원 등)가 빈번하게 변경/추가되어 RDB 컬럼으로 대응하기 어렵기 때문입니다.저장 데이터: 현재는 '결과값' 위주로 저장합니다. (예: 적용된 할인 명, 타입(정액/정률), 최종 할인 금액)[직면한 문제: 변경 시점의 기준 모호성] 예약 시점(T1)과 변경 시점(T2) 사이에 정책이 변경되었을 때, 어드민에서 예약을 수정하면 어떤 정책을 따라야 하는가에 대한 딜레마입니다.만약 기획 요구사항이 "변경 시점(T2)의 정책이 아니라, 최초 예약 시점(T1)의 정책 조건을 유지한 채 금액만 다시 계산해 주세요"라고 한다면 문제가 복잡해집니다.현 구조의 한계: 현재 JSON에는 '결과(할인액)'만 있고 '조건(최소 결제 금액, 당시 허용된 옵션 목록 등)'은 없습니다.예상되는 부작용: 이를 해결하려면 예약 시점의 모든 검증 조건(Condition)을 JSON에 다 때려 넣어야 합니다.이렇게 되면 도메인 로직이 바뀔 때마다 JSON 스키마도 계속 비대해지고,과거 JSON 데이터와 현재 로직 간의 정합성을 맞추기 매우 까다로워질 것 같습니다.[질문] 이처럼 "빈번하게 변하는 가격 정책"과 "과거 기준 수정"을 동시에 만족해야 할 때, 실무에서는 보통 어떤 접근 방식을 취하나요?JSON 스냅샷 확장: 다소 복잡해지더라도 예약 시점의 검증 조건(Parameter)들까지 모두 JSON에 스냅샷으로 남기는 게 맞나요? (JSON 컬럼 사용이 잘못된 선택이었을까요?)Policy Versioning (정책 버전 관리): 아니면 가격/할인 정책 테이블 자체를 버전 관리(Effective Date 등)하여, 예약 시점의 policy_version_id를 매핑해두고 로직을 태우는 방식을 써야 할까요?현실적인 타협: 아니면 보통 어드민 변경 건은 "재계산 불가(단순 금액 입력)"로 처리하거나, "무조건 현재(T2) 정책"을 따르게 하는 등 복잡도를 낮추는 타협점을 찾나요?확장성 있는 가격 스냅샷 설계에 대한 강사님의 경험과 조언을 부탁드립니다..!

이전강의에 이어 이번강의도 또 듣게되네요선생님께서 늘 강의에서 느낀다 라는 표현을 많이 하시는데 이게 되게 중요한건가 보네요잘 듣겟습니다

안녕하세요실무에서 '관리자(Admin) 예약 변경 기능' 정책을 두고 기획팀과 이견이 있어, 실무에서는 어떤 방식이 범용적인지 여쭙고 싶습니다.[시스템 상황]유저가 예약할 때 다양한 할인(이벤트, 타임세일, 쿠폰, 기업지원 등)이 적용되며, 이 정보는 예약 시점에 스냅샷(Snapshot)으로 저장됩니다.현재 어드민(상담원/운영팀)이 유저의 예약 시간/날짜를 변경하는 기능을 개발 중입니다.[이슈 사항]기획상으로는 어드민에서 시간을 변경할 때도 모든 할인 조건을 '실시간'으로 재검증하라고 합니다.문제는 재검증 과정에서 '쿠폰 박탈' 같은 상황이 발생한다는 점입니다.예시 상황:유저가 5만원짜리 예약에 5만원 이상 결제 시 사용 가능한 10% 쿠폰을 씀.어드민이 사정상(또는 유저 요청으로) 가격이 저렴한 타임이나 옵션으로 변경함 -> 결제액이 4만원이 됨.기획 요구사항: "최소 결제 금액(5만원) 조건을 불만족하게 되었으니, 자동으로 쿠폰 적용을 해제(원복)하고 금액을 재계산한다."[제(개발자) 의견 및 고민]저는 위 기획이 어드민 기능의 목적과 UX(고객 경험)에 맞지 않는다고 생각합니다.고객 경험 훼손: 유저는 단지 시간을 바꿨을 뿐인데, 시스템이 엄격하게 검증해서 "조건 미달이니 쿠폰 뺏어가겠습니다"라고 하면 컴플레인 요지가 다분합니다. (유저 입장에선 혜택 유지를 원하니까요.)데이터 복잡도: 이미 스냅샷으로 저장된 할인 정보를, 수정 시점에 다시 현재 기준의 마스터 데이터(쿠폰 유효기간, 최소금액 등)와 대조해서 '줬다 뺏는' 로직을 짜는 건 구현 복잡도 대비 실익이 너무 적습니다.관리자의 재량: 어드민에서의 변경은 보통 '강제성(Override)'을 띠는 경우가 많은데, 시스템이 칼같이 혜택을 잘라버리는 게 맞나 싶습니다.[질문]보통 예약 도메인에서 관리자(Admin)가 개입하여 예약을 변경할 때도, 이렇게 엄격하게 유저의 할인 자격(최소금액, 유효기간 등)을 재검증하여 박탈시키는 게 맞나요?아니면 어드민 권한 변경인 경우 "기존 스냅샷(혜택)을 최대한 유지"해주거나, 가격 변동이 불가피하면 "취소 후 재예약"을 하는 프로세스가 더 일반적인가요?개발자로서 이 복잡한 '조건부 쿠폰 회수' 로직을 방어하고 싶은데, 설득력 있는 논리가 필요합니다. 조언 부탁드립니다!

안녕하세요! 수업 잘 듣고 있습니다.사소한 내용이긴한데..OrderService.create 에서 OrderKeyGenerator 객체를 를 주입받아 generate() 를 호출해서 orderKey 를 생성하는 부분에서OrderKeyGenerator class 는 상태를 가지지도 않고 Property 를 가지지도 않는데 static method, 함수로 구현 되어도 되지 않았을까 하는 생각이 들었는데요.어떤 고려사항이 있는지 궁금합니다.static 이든 함수든 객체 메서드이든 상관 없다?나중에 OrderKeyGenerator 가 확장되는 것이 고려된 것?OrderSerivce 에서 사용하는 기능이니 주입되는 것이 더 응집되어 보여서 더 좋다?그냥 함수를 가져다 쓰는 것보다 객체를 주입하는 쪽이 테스트 하기 좋다?generate 가 순수함수가 아니라서?class OrderKeyGenerator { fun generate(): String { return Base64.getUrlEncoder().withoutPadding().encodeToString( ByteBuffer.allocate(16).apply { UUID.randomUUID().also { putLong(it.mostSignificantBits) putLong(it.leastSignificantBits) } }.array(), ) } }

상황 정리저희가 매장 관리자용 통합 예약 관리 시스템을 개발하고 있습니다.현재 시스템 구조[외부 예약 플랫폼 (네이버 같은)] ↓ 자동 연동 [매장 POS 시스템 (티오더 같은)] ↓ API 폴링 [우리 통합 관리 시스템] 고객이 외부 플랫폼에서 예약하면 POS에 자동으로 들어옴우리는 POS API를 폴링해서 예약 데이터를 가져옴우리 어드민에서 직접 예약 등록 기능도 곧 추가 예정문제 상황POS 업체에 확인해보니:API에서 외부 플랫폼 예약 구분이 안 됨 → 구분값 추가 예정외부 예약은 원칙적으로 수정 불가현재는 수정이 되지만 플랫폼 API 키가 연결 안 되어 사실상 불가능DB만 바꿔서는 의미 없고, 외부 플랫폼 API 재호출이 필요POS와 외부 플랫폼 간 연동이 아직 불완전한 상태논의된 두 가지 방향A안 (readonly 방식)- 우리 어드민 생성 예약 → POS 직접 등록 (수정 가능) - 외부 플랫폼 예약 → POS에서 폴링해서 조회만 (수정 불가) - UI에서 "외부 예약" 표시하고 수정 버튼 비활성화 - 수정 필요시 원본 플랫폼 바로가기 링크 제공 B안 (통합 수정 방식)- 모든 예약을 우리 시스템에서 직접 수정 가능하게 - 외부 예약 수정 시 POS API → 외부 플랫폼 API 호출까지 처리 장단점 분석A안 장점각 시스템의 책임 범위가 명확함동기화 정합성 이슈 없음외부 플랫폼 정책 변경에 영향 안 받음여러 플랫폼을 한 곳에서 조회만 해도 관리자 리소스 절감 효과A안 단점수정은 여전히 각 플랫폼에서 해야 함"진정한 통합 관리"는 아님B안 장점완전한 통합 관리 경험관리자가 한 곳에서 모든 예약 제어B안 단점외부 플랫폼 API 직접 연동 불가 (계약 주체가 매장)POS가 외부 플랫폼 제어 API를 제공해야 하는데 현재 없음POS-외부 플랫폼 양쪽 동기화 복잡도 높음외부 플랫폼 정책(취소규칙 등) 변경 시 계속 대응 필요문제 발생 시 책임 소재 애매질문이런 다중 오리진 데이터를 통합하는 시스템에서:readonly로 가는 게 맞을까요, 아니면 수정까지 구현해야 할까요?단계적으로 접근한다면 어떤 순서가 좋을까요?1단계: 통합 조회만2단계: POS가 API 제공하면 그때 수정 추가비슷한 사례에서 일반적으로 어떻게 접근하나요?현재 상황에서는 A안(readonly)이 합리적이라고 판단됩니다.하지만 시간이 지나서 다음 조건들이 충족된다면:POS에서 외부 예약 플랫폼 식별값을 제공외부 예약 플랫폼 API를 저희가 제공받을 수 있음그때는 어떤 아키텍처로 가야 할까요?옵션 1: 직접 호출 방식[우리 시스템] → [외부 플랫폼 API] (직접 호출) → [POS API] (동기화용) 우리가 외부 플랫폼 API를 직접 호출POS는 조회 + 동기화 확인용으로만 사용옵션 2: POS Proxy 방식[우리 시스템] → [POS API] → [외부 플랫폼 API] POS가 외부 플랫폼 제어 API를 제공하도록 요청우리는 POS API만 호출하면 POS가 내부적으로 플랫폼 API 처리외부 플랫폼 변경사항은 POS가 책임옵션 3: readonly 유지[우리 시스템] → [POS API] (조회만) 기술적으로 가능해져도 readonly 유지각 플랫폼 바로가기만 제공어떤 방식이 일반적이고, 각 옵션의 trade-off는 무엇인가요?특히 옵션 1 vs 옵션 2에서:우리가 직접 여러 외부 API를 관리하는 게 나을까요?아니면 POS가 Proxy/Gateway 역할을 하게 하는 게 나을까요?

안녕하세요!PG 결제 승인 API 구현 중 고민이 되는 부분이 있어서 질문드립니다! PG사로 부터 /callback/success 등과 같이 콜백 url로 요청을 받았을때 결제 승인을 서버에서 진행하는 플로우인데결제 승인 요청 전 결제 검증PG 결제 승인 API 호출정상 승인 or 승인 실패 시 transaction_history 저장의 흐름인 것 같은데 추가적으로 3번에서 정상 승인 시에 PG사로 부터 응답받은 paymentKey, amount 등을 요청한 paymentKet, amount와 동일한지 검증이 필요할까? 라는 생각이 들었습니다. 궁금한 점은실무에서 PG사 연동 시에는 결제 승인 응답 후 검증 로직을 다루는지? 다룬다면 실제 승인 요청 내역과 응답 내역이 다르다면 어떻게 처리하는지? (클라이언트로 응답, 불일치 시 보정 전략 등..)외부 API 호출 시 서킷 브레이커를 사용하는 걸 선호하는지?정도가 있습니다!제미니님 덕분에 항상 많이 배워갑니다 감사합니다~! 

강사님의 코드를 보니 Question 클래스 등에 id, userId, title, content 등만 넣어두신 것 같은데 일반적으로 자주 표현되는 다른 필드를 표현하려면 어떻게 하는 것이 좋을까요?예를 들어 QnA 조회시 질문 목록에서 질문 작성자의 이름이 표시되는 형태가 많습니다. 이때 그렇다면 QnAResponse 에 questionAuthor 필드가 있어야 할 것 같은데 해당 필드가 추가된다면 어떻게 username 정보를 넣어주어야 할지 궁금합니다. 1안. Question 클래스가 userId 대신 User 클래스를 가지고 있는다...2안. Controller에서 user 목록을 조회해서 response 팩토리 메서드에서 매핑한다.2안이 더 나을 것 같긴 합니다만, 리스트이다 보니 매핑로직이 복잡해 질 것 같기도 하고... qnsList->question->userId 모아서 userList조회... map생성 후 매핑 등등 이런 과정이 괜찮은건지 궁금합니다.또 2안이 더 나은 방법이라면 response에 노출해야하는 join 필드 5-6개 처럼 많을때는 어떻게 처리하시는 편인지도 궁금합니다

안녕하세요 결제 코드느끼기 강의를 보며 궁금한점이 있어서 질문을 남깁니다.여러 주문들을 동시에 넣었고createPayment가 되고 PG사로부터 success가 콜백 호출 된다 했을때, 동시성 문제가 우려되는데요 각 주문마다 point 혹은 coupon을 쓴다고 했을때, 고객이 가진 point 이상으로 point가 차감된다든지, 쿠폰 재사용 문제를 직면했을때 예외처리가 없어보이며, 이 때문에 이를 복구하는 방안같은건 없어보입니다.(괜히 예외처리를 했다가 고객의 돈이 빠져나가고 결제상태가 안바뀔 염려때문)그럼에도 각 Value Object에서 valid및 예외처리하는 로직이 success api에 추가할 수 있을까요? 아니면 주문 결제 전 단계에서 막으면 좋을까요?아니면 그럴 가능성이 자주는 없으니, 결제 상태는 Ready인 부분을 찾아서 수동 수정하는것도 방법이라고 보시나요?

이수 관련 수료가 되지 않아요~TT 이벤트 부분이 수강 기록이 진행되지 않는것 같습니다.

자주하는 질문은어디서 볼수 있나요  CSS ID 에 고유 주소를 부여하고  다른 페이지에 ㅎ설치한 버튼 기능에 id주소의 값을 #과함께 설정을 해 주었습니다.  하지만 페이지에서 확인해 보니 연동이 안됩니다.

헤더 질문드립니다. 헤더의 메인 햄버거 모양이 모바일 화면에서 보이지 않습니다.  엑스표창은 보이지만 팝업창에 메뉴의 하위 요소가 보이지 않는이유가 혹시 글자색상이 투명색으로 지정되어도 그런 현상이 나옵니까? 메인 화면을 설정할때 처음 엘리멘터써킷 이전에 다른 메뉴를 설정을 하고 엘리멘터 써킷 메뉴를 재 지정하고 이전 메뉴를 삭제 했던 과정이 있었는데 그 과정에서 잘못되었다면 메뉴가 보이지 않을수 있는ㄴ지요

헤더설정 질문 드립니다. 헤더를 푸터와 함께 별도로 작업을 해 놓았고. 메인 홈화면에서는 헤더를 만든후 원래 페이지에 만들었던 헤더 페이지를 지워 헤더를 모든 페이지에 활성화 시켰습니다.  당연히 엘리멘터로 편집창에서 보면 홈화면이나 다른 블로그 게시판 이런 페이지에서는 헤더의 모습을 볼수 없지만 홈페이지 주소로 들어가면 헤더가 나옵니다.  하지만모바일 화면에서 활성화 시켜보면 헤더의 메인 햄버거 모양까지 나오고 햄버거 모양을 클릭했을때 팝업창이 활성화 되는 모습이 가려져서 보이지가 않습니다.  조언구합니다.

여기서 만든 메뉴위에 이런게 추가적으로 뜨는데 구조 컨테이너에도 안나오는데 이거 어떻게 없에는지 궁금합니다. 웹버전에서는 안보이는데 모바일버전에서만 뜨네요

1강 구매한 도메인 주소는 asdfqwer을 구매했는데, 2강 호스팅에서 대표 도메엔 연결에서는 왜 구매한 도메인 주소를 연결하지 않고 갑자기 다른 도메인을 연결하였나요?  원래 구매한 도메인을 연결하는게 맞죠? 초보라서 몰라서 질문드립니다.

지금 웹 페이지를 강의에 따라서 만들고 있는데 엘리멘터로 편집을 하기전에 워드프레스로 작업을 했던 웹 화면이 있어서 웹페이지를 열어보면 엘리멘터로 작업한 홈 화면이 먼저 나오지 않고 이전에 워드프레스로 작성한 웹 페이지가 먼저 나옵니다.  엘리멘터로 작업한 홈화면이 제일 먼저 보여지게 하려면 어떻게 하나요