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

정답으로 보여주신 이미지에는 아래와 같이 FK가 설정되어있는 것 같았는데 맞을까요?profiles.user_id -> auth.users.id (CASCADE) todos.user_id -> auth.users.id (CASCADE) todos.user_id -> profiles.users.id (CASCADE)todos.user_id -> profiles.users.id를 잇는 FK는 왜 필요한거고, 어떤 의도로 생성하는것인지 궁금합니다

제가 따라한 실습 코드에서는항목 클릭 했을 때 여러 개 todo 항목이 있을 경우line-through 가 맨 뒤 항목에만 적용되는데여러 항목을 렌더링 했을 경우 클릭한 doto를 click 시 못 찾아 가는 상황인가요?

안녕하세요 선생님좋은 강의 잘 듣고 있습니다 감사합니다.질문이 있는데 받아주시면 감사하겠습니다S3, DynamoDB 등은 연결하는 건 게이트웨이 VPC 엔드포인트인 것으로 알고 있어서 햇갈려서 질문드립니다.감사합니다.

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

안녕하세요 강의를 듣다가 전반적인 학습 방향성에 고민이 있어서 질문드립니다. 풀스택 개발자가 목표입니다 취업전 총 3번의 프로젝트를 진행 해보려고 합니다.(실서비스 프로젝트 1개 / 실서비스 프로젝트를 위한 연습 프로젝트 2개 ) 첫번째 프로젝트는프레임워크를 사용하기 전 전반적인 기초체력을 기르기 위해서fe - 바닐라 js로 spa방식 (csr)be express로 api구성 + 로우쿼리로 db 연동 두번째 프로젝트는 추후 next, nest 등 프레임워크 학습후 진행 해보려고 합니다.fe - nextbe - nest + prisma 등인프라 - aws운영 - • Sentry - 에러 추적  • CloudWatch - AWS 로그/모니터링  • Datadog - 통합 모니터링  • Winston / Pino - 로그 라이브러리 실서비스 프로젝트는 fe는 next / be는 nest를 사용해 개발할 예정이고실제 사용자가 있는 b2b 쇼핑몰이라 배포/인프라(aws), 운영(모니터링/로깅)까지 a~z까지 모두 경험 해볼 프로젝트입니다. 현재 첫번째 프로젝트를 위해강의자분께서 제공한express part1 수강은 끝난 상태입니다프론트 및 db관련 강의들은 타 강의자분의 강의를 통해 준비를 마친 상태입니다. 혹시 part2 까지 수강후전반적인 기능구현 실습들을 진행 해보는 타강의를 수강하고 프로젝트를 시작해야할까요아님 프로젝트 경험 먼저 해본뒤 part2 강의수강, 기능구현 실습강의를 수강 하는게 더 효율적일까요.. 프로젝트 완성도를 위해 강의만 쭉 들으니어디까지 공부를 해야하는것인가에 대한 기준도 안 잡히고강의만 듣고 직접 강의 코드를 쳐보는것만으로는 구현력이 안 길러지는 것 같습니다..또한 강의 수강 기간이 길어지다보니앞서 들었던 강의 내용들이 잘 기억이 안 나는 부분들에 대한 걱정 또한 있습니다.반면에 실무적인 코드 경험 (강의를 통한 간접경험) 없이 프로젝트를 진행하면실무에서 쓰지 않는 코드 / 리펙토링 하기 어려운 코드 / 보안에 대한 인식 부재로 인한 위험성 등여러가지 잘못된 코드를 작성하고 학습하게될까봐 두려움이 있습니다. 어느 시점에 구현력을 기르기 위해서 프로젝트를 진행 해봐야하는지도무지 감이 안 잡혀서 질문 드립니다.. 강의 외적인 성격이 짙은 질문인데 염치 불구하고 질문드립니다..

실제 현업에서는 동기 엔진 모듈과 비동기 엔진 모듈 두개를 만들어두고, 상황에 따른 api를 정의 후 호출해서 사용되는지 궁금합니다.

강의 잘 듣고 있습니다! 수강중 궁금한 내용이 있어서 남겨요. 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원)

Express는 비동기 에러를 잡지 못한다고 강의에서 배웠습니다. 이게 혹시 싱글 스레드와 관련이 있을까요? 그렇다면 스프링의 경우는 어떻게 다를까요?Express는 에러 발생 지점에 가까이 정의된 에러 처리 미들웨어를 우선적으로 처리한다고 배웠습니다. 단순 코드적으로 위치가 가까운 거 맞나요? 에러 처리 미들웨어가 여러 개 있고 파일 내에 섞여있으면 코드 파악이 어려워질 수 있을 것 같아요. 실무에서 보통 권장되는 방식은 뭘까요? 에러처리 미들웨어를 하나만 두는지, 나눠서 같은 코드 위치에 두는지, 나누서 서로 다른 코드 위치 (라우터 사이)에 두는지 궁금합니다.

강의에서 Express 모듈을 사용할때 commonJS 방식인 require로 가져오는데 Node.js 환경에서 ESM 방식으로 할 수는 없는 걸까요?

안녕하세요!문제를 한번에 풀고 채점하고 싶은데 자료 하나에 합쳐져 있어서혹시 문제집을 문제/해설 각각 pdf 자료로 받을 수 있는 방법은 없을지 문의드립니다.감사합니다. 

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

킬구형 ㅎㅇ 요즘에 배치 다시 학습하면서 좀 고민인 부분이 있음. 현재 회사에서 배치 Job이 좀 많이 늘어나면서 코드 관리가 너무 어렵더라고. Spring MVC에서는 Controller-Service-Repository 같은 레이어드 아키텍처나 클린 아키텍처처럼 널리 쓰이는 구조가 있는데, 배치 쪽은 이런 패키지 구조나 설계 방식에 대한 레퍼런스가 상대적으로 적은 것 같아서. 최근에 클린 아키텍처를 배우면서 배치에도 이런 구조를 적용할 수 있는지 궁금해졌거든.지금 나는 대략 이런 식으로 구성하고 있어:batch/ ├── order/ │ ├── confirm/ │ │ ├── OrderConfirmJobConfig.java │ │ ├── OrderConfirmReader.java │ │ ├── OrderConfirmProcessor.java │ │ ├── OrderConfirmWriter.java │ │ └── OrderConfirmJobListener.java ├── payment/ │ ├── settle/ │ └── cancel/ ├── support/ ├── domain/ ├── application/ └── infrastructure/ 하나의 Job을 하나의 큰 애그리게이트처럼 보고 있어서, 관련 클래스를 패키지별로 분리하기보다 한 폴더 안에서 로우 레벨로 관리하는 게 더 편하더라고.근데 Job이 계속 많아질수록 이게 맞는 건지, 더 나은 방법이 있는 건지 잘 모르겠어서. 혹시 형은 실무에서 Job이 많아졌을 때 패키지 구조나 코드 구성을 어떻게 가져가? 객체 간 위계나 import 의존성 방향 같은 것도 신경 써서 설계하는지도 궁금해. 물론 사람마다 차이가 있겠지만 시간 괜찮으면 경험 공유해주면 도움이 많이 될 것 같아!

혹시 Nginx나 Apache를 사용하는 경우 ejs로 SSR을 구현하는 것이 강좌에서 한 방법과는 달라질까요?

화면에 수정사항에 "register" ==>"/users/register" 로 되어 있는데 저는 그렇게 하면 error 화면이 뜹니다.하단 수업 노트에는return res.status(400).send("User already exists");이렇게 되어 있습니다.제 코드에서 아래와 같이 수정하니까 동작하긴 하는데....return res.render("users/register",{error:"User already exists"});이렇게 "users/register"로 앞에 "/" 없이 "users/register"로 하니까 동작하는데 제가 어디선가 잘못한 것일까요?

해답에 (A)가 오답인 이유가Glacier 유형은 법/감사/규정 목적으로 장기 보관해야 되는 경우에만 사용하기 때문이라고 해설이 되어 있는데문제에는 회사의 보안 규정에 스토리지 전략을 따르는 것으로 주어져 있습니다.문제에서의 회사의 보안 규정이 법/감사/규정에 포함되지 않는건가요?

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

킬9형 안녕실무에서 Spring batch를 실행해줄 스케줄러와 batch 실행 환경은 어떤게 있는지 궁금해.현재 인프라는 AWS에서 EKS, ElastiCache(Redis), Aurora MySQL을 사용하고 있어.

jwt가 뭔지 왜 사용하는건지에 대한 자세한 내용은 안 다루는거 같고 전반적인 crud의 감만 잡고 넘어 가는건지 궁금합니다.이부분을 part2에서 제대로 배우는지 아님 제가 추가로 학습을 해야하는 부분일까요?설명히 제대로 안 된 부분들을 직접 찾아서 공부하면서 강의를 듣다보니 흐름도 깨져서 파트2 에서 다룬다면 전반적인 구현정도로만 넘어가려고 질문드립니다.

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