안녕하세요.좋은 강의 잘듣고 많이 배우고 있습니다. 좋은 강의 만들어주셔서 감사합니다.다름이 아니라, 어댑터에서 엔티티에 의존성을 가지는 것이 크게 문제되지 않는다고 말씀주신 내용에 의문이 있어 질문드립니다! 어댑터에서 도메인에 직접 의존하는 것을 막기 위해서 변환 역할을 하는 매퍼 클래스나 DTO에서 엔티티를 자기 자신으로 변환하는 로직을 가지는 것은 어떨까요? 타이트하게 룰을 잡는 케이스를 가정한다면, application layer 내부에 port가 존재할 것이고 이 port에서 return 하는 dto도 application layer일 것이고, 이 dto 안에서 Entity를 받아서 자기 자신으로 변환하는 로직을 가진다면 entity가 application 밖으로 나가지 않을 수 있지 않을까요?(controller, repository 등 마찬가지입니다)그리고 dto를 application에서 변환하는 것이 로직의 침투라고 표현하시기도 했는데, 그렇다면 provided port 역시 어댑터의 요구가 침투하는 구조라고 볼 수도 있을 것 같기도 합니다..(생각해보니 이상적으로는 계층별로 DTO를 생성하는게 맞다고 생각은 들지만, "엔티티를 반환하는 트레이드오프가 굉장히 효율적이고 정당하다"라고 말씀하신 것 같다고도 생각이 듭니다) 강의에서 항상 기술이 등장한 배경과 사상을 이해하고, 이를 바탕으로 정당하게 규칙을 스스로 정하는 것을 강조하시는 것 같습니다. 그래서 강의에서 말씀하신 내용이 비슷한 맥락으로, "절대 노출되면 안된다"라는 것에 대한 반박이라고 받아들여지긴 합니다만.. 그래도 바깥쪽으로 노출하지 않는 것이 의존성 관리 차원에서 더 좋지 않을까하는 생각에 질문드립니다!

@Slf4j @SpringBootTest class SplitBloomFilterRedisHandlerTest extends RedisTestContainerSupport { @Autowired SplitBloomFilterRedisHandler splitBloomFilterRedisHandler; @Test void mightContain() { SplitBloomFilter splitBloomFilter = SplitBloomFilter.create("testId", 1000, 0.01); List<String> values = IntStream.range(0, 1000).mapToObj(idx -> "value" + idx).toList(); for (String value : values) { splitBloomFilterRedisHandler.add(splitBloomFilter, value); } for (String value : values) { boolean result = splitBloomFilterRedisHandler.mightContain(splitBloomFilter, value); assertThat(result).isTrue(); } for (int i = 0; i < 1000; i++) { String value = "notAddedValue" + i; boolean result = splitBloomFilterRedisHandler.mightContain(splitBloomFilter, value); if (result) { log.info("value={}", value); } } } }  위 코드는 SplitBloomFilterRedisHandlerTest 인데요.강의 중 코드입니다 1000 크기에 0.01 오차율의 Bloom Filter 를 만들고1000개의 데이터를 넣고 False Positive 까지 검증해보는 코드인데요.질문입니다Split 전략을 배우기 전에순수한 Bloom Filter 구현 강의에서도 위와 동일한 테스트 코드가 있는데요이 때, 순수한 Bloom Filter 의 한계로써생성한 Bloom Filter 크기를 초과하여 데이터를 넣으면 비트 1이 많아져 오차율이 증가하고그로 인해 False Positive 데이터가 많이 조회되는 현상을 살펴보거든요.그리고 그 해결책으로처음부터 큰 Bloom Filter 를 만드는 것 이외에Split / Sharding / Sub Filter 전략이라고 말씀하시는데요근데 위 Split 전략의 테스트 코드에서 BloomFilter 크기는 1000으로 만들고 데이터를 훨씬 초과하여 2000개 만들어 넣어보면순수한 Bloom Filter 때처럼 False Positive 데이터가 많이 조회됩니다.저는 PC 가 느려서 False Positive 를 1000번으로 조회하였고오차율 (0.01) 에 의하면 약 10개의 False Positive 가 나와야 하는데데이터 1000개를 저장했을 때는 오차율에 맞게 8개로 떨어지는데데이터 2000개를 저장했을 때는 오차율을 훨씬 넘어갑니다제가 코드를 잘못 따라 친건지.. Split 도 원래 그런건지..제 질문 의미가 전달될지는 모르겠지만.. 명확하게 개념 정리가 되지 않아 질문드립니다

예제에서는 도메인에 별도 PasswordEncoder 인터페이스를 정의해 사용하고 있습니다. 만약에, Member 도메인이 Spring Security의 PasswordEncoder 인터페이스를 직접 의존한다면, 구현체가 아니라 인터페이스를 참조하더라도 순수 도메인 설계 관점에서 위반으로 봐야 할까요? 저는 인터페이스 의존이라 괜찮을 수 있다고 생각했지만 AI는도메인에서는 자체 PasswordEncoder 포트만 사용하고, Spring Security PasswordEncoder는 인프라 어댑터에서 위임하는 것이 좋다.고 제안했습니다. 토비님은 어느 쪽이 더 적절하다고 보시는지, 판단 기준도 함께 듣고 싶습니다.

 안녕하세요 강사님,다름이 아니라 강의 들으면서 카카오 oauth 설정 및 테스트 중인데카카오 REST API 키에도 클라이언트 시크릿이 생긴 것 같습니다.구글처럼 yaml에 kakao.client.secret 키 넣어주고 요청 바디에 같이 보내니까 그제서야 액세스 토큰 및 프로필 정보 응답이 왔습니다.강의 촬영 당시와 현재의 카카오 developers UI 및 메뉴 구성이 많이 바뀌어서 제가 모종의 설정을 놓친건지, 아니면 새롭게 카카오 클라이언트 시크릿이 추가되어서 이제는 구글처럼 시크릿 키를 요청 바디에 넣고 보내는 게 맞는 방법이 된 건지 말씀 여쭤보고자 질문 드립니다.양질의 강의 항상 감사드립니다.  

안녕하세요 재미니님 유튜브로 접하게 되어 인프런 강의까지 듣게된 백엔드 개발자(5년) 입니다.현재 팀의 레거시 시스템을 고도화하는 레거시 시스템을 개편하는데 주력하고 있는 업무를 맡고 있습니다. 저희 회사는 규모가 적지 않고, 팀내에서 담당하는 시스템도 많은데 제 기준으로는 꽤나 보수적인 조직이라 ai 활용하는데 제약이 많은 편이라고 생각합니다. 금융권처럼 로컬 PC에서 외부망을 아예 차단하고 있지는 않지만, chat gpt, gemini 등 각종 llm을 제공하는 웹사이트는 차단이 되어있고 사내 자체 llm 만 사용할수 있는 환경입니다. 운이 좋게도(??) junie 는 아직 차단되어 있지 않아 많이 활용하고 있는데, 신규 구축이 아닌 기존 레거시 시스템을 분석하여 컨버전을 하는 과정에서 사용하기에 보안적으로 이슈가 될 부분이 있을까 싶어서 걱정이 많이 되는데, ai를 활용하면 생산성이 넘사벽으로 높아지는 환경에서 보수적으로는 보안 이슈를 걱정하는 팀원들이 있을경우, 재미니님은 어떤식으로 팀원들을 설득하실지, 보안 이슈가 없도록 방안은 어떻게 마련하고 계신지 궁금합니다.추가로 극단적인 예시긴 하지만, 비지니스 로직이 프로시저에 녹아져 있는경우, db 에 의존적으로 운영되고 있는 시스템(ex. 트리거, 서버 크론잡 스케줄링 등) 의 경우 ai를 활용하여 레거시를 최대한 개선하고 싶다면 어떤 전략을 활용할 수 있을지도 의견 주시면 감사하겠습니다.소중한 강의 제공해주셔서 감사합니다.

안녕하세요, step 4에 fanout 브로드캐스팅으로 구현한 이유가 궁금해서 질문드립니다.다른 질문을 찾아보니 아래와 같이 답변을 주셨습니다."정리하면 Fanout은 모든 큐에 메시지를 브로드캐스트하지만 WebSocket을 이용해 특정 뉴스 타입만 선택적으로 구독할 수 있습니다. (서로 독립적으로 동작합니다)따라서 Pub/Sub의 성격을 이용해서 브로드 캐스트를 하는 것은 Direct나 Topic 보다 Fanout이 적합하고, 전체 브로드캐스트가 필요하지 않은 Pub/Sub의 일부 제한이 필요한 경우는 WebSocket과 STOMP를 통해서 필터링.. 여기서 저는 왜 step4에서 Pub/Sub의 성격을 이용해서 브로드캐스팅하는지 이해가 안됩니다.어차피 WebSocket에서 필터링할 것이라면 왜 비효율적으로 브로드캐스팅하는건가요?fanout보다 topic Exchange가 적합하지 않나요?어차피 브로드캐스팅하고 모든 큐에 넣을 것이라면, javaQueue, vueQueue, springQueue로 구분할 필요가 있나요? pub/sub 모델은 아니지만, 하나의 newQueue로 관리하고 simpMessagingTemplate의 destination을 구분하는 것은 어떤가요?

도커안하고 일반적으로 mysql이나 데이터베이스에서 사용하는거 올려주실순없나여ㅜㅜ이미다 찍으셨겠지만..

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)네2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)네3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)네[질문 내용]여기에 질문 내용을 남겨주세요왜 자꾸 Unused property 가 뜰까요?.... Gradle 업로드 해도 계속이러네요ㅠㅠ 제미나이와 몇시간을 여러방법을 썼는데 실패해서 처음 질문드려요.....

안녕하세요.게시판 관련 강의를 듣는 도중 궁금한 점이 있어 질문을 남깁니다.강의에서는 Snowflake 기반 단순 정렬을 기준으로 커버링 인덱스를 설명해주셨는데요,실무에서는 여러 정렬 조건과 필터, 검색 조건이 함께 붙는 경우가 많습니다.✅ 이런 복합적인 조회 패턴에서도 커버링 인덱스를 중심으로 설계하는 것이 적절한지,아니면 다른 전략을 어떻게 사용해야 하는지 궁금합니다.(설명이 길어질 경우 간단한 힌트라도 부탁드립니다.)💥 걱정하는 부분정렬되는 컬럼 전부에 대해 인덱스를 걸면 더 문제가 발생할 것 같아요.검색 %검색어%의 경우에는 결국엔 full_scan이어서 성능 최적화가 불가능하다.

강의 잘 듣고 있는데요.같은 프로젝트에 대해 다수의 팀원이 개발한다고 가정 할 때현재의 AI를 사용하는 방식이 어디까지 유효할 지 재미니님의 생각이 궁금하여 의견 여쭙습니다.예를 들어 저는 AI를 적극 사용하고 싶을 때, 하지만 팀의 문화가 AI를 위와 같이 그닥 사용하지 않을 때, 강의 속에서 AI를 활용하는 방안을 어디까지 얘기하는게 좋을 지 등이 궁금합니다.제가 느낄 때, 위 강의 과정에서는 md 파일을 꾸준히 업데이트 하며, 히스토리를 쌓아가는 것 같아 의견을 여쭤봅니다.

안녕하세요.이제 강의를 조금씩 들어보려고 하는데 강의 pdf는 있는데 소스코드는 따로 못본거 같은데 어디서 확인할 수 있을까요? https://github.com/onjsdnjs/spring-security-master/tree/master이거인거 같은데 단원하고 코드하고 연결이 안되어있어서 각 강의 단원별 뭘 봐야되는지 알수가 없어서 너무 많은 시간이 낭비되는거 같습니다.... 체계화가 안되어있어서 시작하기 전 부터 좀 실망스럽고 당황스럽습니다. 맵핑 (단원 - 깃 브랜치) 되어있는 자료가 있으면 좋겠습니다. 감사합니다.

안녕하세요.설정 시 String 으로 작성 된게 눈에 걸려서 확인해봤는데, Spring AMQP 2.X 에서는 다른 방법이 있어서 내용 공유 드립니다...다른 수강생분들도 참고용으로 q&a로 남겼습니다..감사합니다...@Bean public Queue orderQueue() { return QueueBuilder.durable(ORDER_COMPLETED_QUEUE) .deadLetterExchange(DLX) // Available since Spring AMQP 2.x .deadLetterRoutingKey(DLQ) // Available since Spring AMQP 2.x // .withArgument("x-dead-letter-exchange", DLX) // Spring AMQP 1.x compatible // .withArgument("x-dead-letter-routing-key", DLQ) // Spring AMQP 1.x compatible .ttl(5000) .build(); }

안녕하세요 분명 강사님 클로드는 굉장히 친절하게 현 상황도 보고를 하고 다 만들면 어떤 기능이 있고 이런이런거에 기반해서 만들었다고 뜨는데 제건 그렇지 않네요 기존에 설정을 해두신 건지 궁금합니다.

제미니님 안녕하세요!30강 5분쯤에서 나온 결제 구조 관련해서 질문이 있습니다. 검증과 처리 책임을 모두 가지고 있던 PaymentManager를 Validator와 Processor로 분리한 의도는 이해했습니다.그리고 Validator와 Processor 각각에서 주문과 결제를 다시 조회하도록 구현하신 이유가 컴포넌트를 명확하게 분리하고 재사용성을 높이기 위함이라고 이해했습니다. 여기서 말씀해주신 “명확하다”는 표현이 PaymentService에서 비즈니스 흐름을 더 명확하게 드러내기 위한 설계 의도라고 이해해도 괜찮을까요? 한편으로는 다른 방식도 떠올랐는데, Validator에서 검증하면서 조회한 주문/결제 정보를 PaymentContext 같은 객체에 담아서 Processor.success로 전달하는 구조는 어떻게 생각하시는지 궁금합니다. 이런 방식이 책임 분리나 구조적인 측면에서 문제가 생길 여지가 있는지, 혹은 실제로는 어떤 트레이드오프가 있는지도 함께 알고 싶습니다!

안녕하세요 ~ 강의 잘 수강하고 있습니다 !ERD 부분에서 질문이 생겨 여쭤보게 되었습니다 !! chat_participant 부분에서 전용 pk를 하나 두고 chat_room_id와 member_id를 두셨는데, 혹시 이런 경우에는 pk 자체를 chat_participant_id 라는 전용 pk 말고 chat_room_id, member_id 복합 pk로 사용해도 괜찮을까요 ? message_read_status 테이블을 따로 정규화시킨 이유가 있을까요 ?chat_message와 거의 비슷한 외래키를 쓰고 있는데 chat_message 테이블 안에 isRead 컬럼 자체를 두는 것이 더 적절하지 않은지 강의를 수강하다 궁금해서 여쭤보게 되었습니다 !! 또, 혹시 강의 내용을 공부한 부분에 대해서 학습 목적으로 블로그에 공부한 것들을 정리해서 업로드하는것이 괜찮을까요 ? 좋은 강의 제공해주셔서 너무 감사드립니다 ~~~ 오늘 설 연휴인데 새해복 많이 받으셔요 ~~

안녕하세요. 20강 클레임 미검증 주의 강의를 듣다가JJWT 0.12 버전에서Claims claims = Jwts.parserBuilder() .setSigningKey(key) .build() .parseClaimsJws(token) .getBody();위의 예제 코드에서 parserBuilder, setSigningKey는더 이상 0.12 이상 버전에서는 지원하지 않는 메소드라고 나와서요Claims claims = Jwts.parser() .verifyWith(key) .build() .parseSignedClaims(token) .getPayload();위의 코드로 대체하면 될지 문의 드립니다...!

강의보면서 하나하나 따라적는게 좀 불편한데, 소스코드도 제공가능한지 문의드립니다.

안녕하세요우선 강의 잘 들었습니다~batch 를 실무에 적용해보고자 하는데요spring batch의 경우 batch_db에batch_job 관련 테이블이 자동 실행되는 걸로 보이는데요실무에서는 dba를 통해 테이블을 생성해야되는데요batch_job 관련 스키마를 모두 반드시 생성을 해야 되는 건가요??

혹시 선생님께서 수업 중 사용하신 ppt 파일이 있으실까요? 복습할 때 꼭 필요해서 질문드립니다!

안녕하세요 ! 결제 개념 쪽 강의 내용 중 궁금한 부분이 있어 질문 드립니다 ! 1. PaymentCreator를 별도 컴포넌트로 분리한 이유결제 개념에서 PaymentCreator를 별도의 컴포넌트로 추출하신 이유가 궁금합니다.결제 생성 또한 결제 개념을 처리하는 기능의 일부라고 생각해서, PaymentProcessor 내부에서 함께 처리할 수도 있지 않을까 생각했는데 Creator를 분리하신 설계 의도가 무엇인지 알고 궁금합니다!2. Manager vs Processor 네이밍 전략 기준다른 개념 영역에서는 Manager라는 네이밍을 사용하시다가결제 영역에서는 Processor라는 네이밍을 채택하신 이유가 궁금합니다.두 네이밍 사이에 역할적/의미적 차이를 두고 설계하신 것인지, 혹은 도메인 특성에 따른 네이밍 전략인지 궁금합니다 !