학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요, 강사님! 강의를 듣다가 리포지토리 추상화 와 관련하여 실무적인 고민이 생겨 질문드립니다. ( java 학습 전에 안드로이드 kotlin 개발 중에 겪었던 문제) 현재 인터페이스를 통해 리포지토리를 추상화하고, 향후 데이터 저장소가 바뀌어도 MemberService 등 비즈니스 로직을 보호하는 설계를 공부하고 있습니다. 그런데 만약 외부 시스템이나 DB의 ID 규격이 바뀌어 데이터 타입 자체가 달라지는 경우 에는 어떻게 대처하는 것이 정석인지 궁금합니다. 1. 타입 불일치 및 형변환의 한계 예를 들어, 현재 우리 시스템의 도메인(Member) ID는 Long 인데, 나중에 도입할 외부 API의 ID가 2131293e-r1232... 같은 UUID(String) 형태라면, 물리적으로 Long 으로의 형변환 자체가 불가능합니다. 2. 이 경우 어떤 방식이 가장 권장되는 '정석'인가요? 방안 A: 도메인 모델은 우리 시스템의 기준( Long )을 유지하고, 리포지토리 구현체 내부에서 외부 ID(String)를 별도의 필드에 매핑(저장)하며 우리만의 PK를 새로 생성한다. 방안 B: 인터페이스와 도메인의 ID 타입을 처음부터 가장 범용적인 String 으로 변경하여 외부 규격에 맞춘다. 방안 C: 기타 실무에서 주로 사용하는 별도의 전략이 있는지 궁금합니다. 3. 고민의 요지 구현체 내부에서 '임의로 타입을 가공하거나 재조립'해서 서비스에 넘겨주는 것이 도메인의 순수성을 지키는 올바른 방향인지, 아니면 애초에 이런 타입 변경의 가능성까지 고려하여 인터페이스를 더 유연하게(예: Generic 사용 등) 설계해야 하는 것인지 강사님의 실무 노하우를 듣고 싶습니다!
어노테이션 뭐가 있는지 궁금했습니다. 스프링 공식 문서( https://docs.spring.io/spring-framework/reference/index.html )에 Annotation 검색해보니까 여러가지가 나오네요. 어떤 걸 봐야 어노테이션 전체를 볼 수 있나요? 어노테이션 페이지가 따로 없나요?
취준생으로서 아주 유용하게 강의를 듣고있습니다. 그런데 테스트코드를 실행할 때 현재상황에서 기본설정된 junit6이 지원되지않는 상황이고 build.gradle 의존성에서 junit5로 지정변경하고 테스트 케이스를 작성하고 실행할때 junit5와 6이 버전충돌해서 테스트코드가 실행이 안됩니다. 어떻게 해결해야 할까요?
강사님 안녕하세요. 쿠폰 조회 로직 구조 관련해서 의견 여쭤봅니다. 현재 제 구현은 findBestBenefitCoupons 에서 DB(Querydsl) 쿼리 하나로 - 대상 필터링(INCLUDE/EXCLUDE, 기간, 상태), - 할인금액 계산, - 적용가능 여부 정렬, - 페이지네이션(Slice) 까지 전부 처리하고 있습니다. 그런데 쿼리가 너무 복잡해져서, “DB에서는 가능한 필터링/후보 추출만 하고, 복잡한 적용 규칙/최종 정렬은 애플리케이션 레이어에서 처리”하는 방식으로 바꿔도 괜찮을지 고민 중입니다. 제 가정은 사용자별 쿠폰 수가 많아도 수천 장 수준이라 앱 처리도 감당 가능하다는 점입니다. 강사님 코틀린 예제 CouponTargetReader )는 DB는 타겟 조회 중심이고 조합은 앱에서 하는 패턴으로 보였는데, 제 케이스(최적 쿠폰 + 페이징)에도 이 방향이 실무적으로 타당할까요? 아니면 정렬/페이징 일관성 때문에 핵심 랭킹 로직은 DB에 유지하는 게 더 맞을까요? 추가로 궁금한 점이 있습니다. 대규모 커머스 회사에서는 이런 “최적 쿠폰 목록” 문제를 보통 어떻게 처리하나요? 쿠폰 목록은 조건(회원/주문금액/대상/기간)이 많아서 캐싱도 쉽지 않아 보이는데, 실무에서는 어떤 식으로 분리(DB/애플리케이션/배치/사전계산)하고 어떤 기준으로 설계 결정을 내리는지 궁금합니다. 저는 지금 소규모 서비스에서 개발 중이라, 대규모 트래픽/대량 데이터 환경에서의 실무 관점 인사이트를 얻고 싶습니다. 판단 기준(데이터 건수, 성능 임계치, 페이지 정합성, 운영 복잡도)도 함께 조언 부탁드립니다.
안녕하세요 강사님 제가 알림기능을 만들려고 하는데 예를 들어 음식을 사고 영수증을 찍었을 때 OCR 기술을 이용하여 사진을 인식하여 유통기한이 임박했을때 알림이 오는 기능을 만들려고 생각중입니다. 이런 경우는 따로 ERD 를 이용해서 만들어야 할까요? 이런 기능 자체가 처음이라 질문드립니다. 그리고 알림 기능은 현업에서 파이어베이스를 쓰는 게 맞을까요?
첨부한 사진의 소스 상으로 보면 @Bean으로 두개의 customAuthenticationProvider를 등록했습니다. 그러면 @Bean으로 등록했기 때문에 이 두 커스텀 프로바이더는 처음에 parent의 providers에 추가되고, http build 하는 과정에서 빌더에 이 두 커스텀 프로바이더를 추가하니 child 쪽의 providers에도 다시 추가, http.formLogin(Customizer.withDefaults());를 호출하기 때문에 child 쪽에 DaoAuthenticationProvider 추가. 최종적으로 child - CustomAuthenticationProvider, CustomAuthenticationProvider2, DaoAuthenticationProver parent - CustomAuthenticationProvider, CustomAuthenticationProvider 이렇게 추가되어야 하지 않나요?
강의에선 되게 단순하게 큰 틀 위주로 알려주시는 것 같아서 개인적으로 더 자세한 의미나 추가적인 개념이 궁금할 때 검색해보는 편인데, DI라는 것이 클래스 간의 결합도를 낮추고 객체의 유연성을 높이기 위해 빈 객체를 만들어 주입하는 것을 의미한다고 정리했습니다. 이게 맞게 정리한건지 궁금합니다. 또 추상 클래스와 인터페이스 간의 차이점은 찾아봐도 이해가 어렵길래 선생님의 친절한 설명이 필요할 것 같아서 추가로 여쭤봅니다!
'섹션 5. 클라우드에서 내 서비스 띄우기: AWS로 배포하기' - '26. AWS EC2 서버에 애플리케이션 배포' 강의를 듣던 중 문제가 생겨 AI를 활용해 문제를 해결해보다가 해결을 못 했습니다. 이미 너무 많이 만져서 원래 상태로 복구하긴 힘들 거 같네요. 강의를 처음부터 다시 들으면서 다시 만들어야 할까요? 깃허브 같이 중간 결과물을 다운 받을 수 있는 곳은 없나요?
안녕하세요, 토비님. 강의 초반에 말씀해 주신 것처럼, 리팩토링 과정에서 “제가 했다면 어떻게 했을까”를 계속 생각해 보며 토비님의 의사결정 과정을 따라가고 있습니다. MemberService.register() 메소드에서 emailSender.send(...) 를 sendWelcomeEmail() 로 분리하시는 과정을 보며 두 가지 고민이 생겼습니다. 첫째, 환영 이메일의 내용이나 정책이 변경될 때마다 MemberService 의 코드가 함께 변경되어야 한다면, 이는 SRP 위반에 해당하지 않는지에 대한 고민입니다. 이 경우 환영 이메일 전송에 대한 책임을 EmailSender 인터페이스 쪽으로 옮기는 것이 더 적절한지 궁금해졌습니다. 둘째, 만약 EmailSender 인터페이스에 해당 메소드를 추가한다면, 구현체가 늘어날수록 인터페이스가 비대해지거나 향후 구현 복잡도가 증가할 수 있다고 느꼈습니다. 이런 경우 default method 로 제공하는 방식에 대해서는 어떻게 생각하시는지도 궁금합니다.
강의 잘 듣고 있습니다! 수강중 궁금한 내용이 있어서 남겨요. 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원)
22. REST 방식 컨트롤러 만들기(2)에서 포스트맨으로 글 등록 테스트 할 때 complete 필드가 없는 경우 Bad Request 400에러가 나는 걸 확인했습니다. { "title": "Test title", "writer": "testuser", "complete": false, "dueDate": "2026-02-04" } 위와같이 complete필드를 추가하니 잘 되었는데, 문제는 29강에서처럼 브라우저 화면에서 테스트 해보니 아래와같이 400에러가 발생합니다. 여기도 마찬가지로 입력폼에서 complete필드가 없어서 그런것 같은데 강의에서는 등록이 잘 되는게 이해가 안되네요. 섹션4까지 완성된 코드를 다운받아서 실행해보았지만 위의 사진처럼 브라우저에서 등록 시 400에러가 발생합니다.
