부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?

안녕하세요 질문 감사드립니다!제 경우는 비즈니스와 비즈니스로직의 응집도를 좀 더 중요하게 생각합니다그러다 보니 포인트 지급에 대한 부분을 별도 이벤트 발행으로 처리하기에는 응집도가 떨어진다고 느껴지는 것 같습니다또 비즈니스적으로 리뷰 작성과 포인트 지급이 상당히 가까운 개념적 관계에 속한다고 볼 것 같습니다(물론 논리적으로 "포인트는 글로벌하게 쓰이니 이벤트로 처리해도 되는거 아닌가?" 라는 생각도 틀리진 않습니다)결국 이벤트 기반 처리를 오용하게 되면 응집이 깨지는 문제가 있다고 생각 합니다그래서 저는 일반적으론비즈니스적 맥락이 완전히 분리 될 때 를 기준으로 이벤트 기반으로 처리하는 것 같습니다(ex] 이메일 발송, 알림톡 발송, callback 전송 등 완전히 다른 비즈니스/기능적 맥락)약간 다르지만 비슷한 관점으로는 동시성 관점으로 후 처리 or 비신뢰 처리가 되어도 된다라면 @Async 를 사용하는 경우가 있는 것 같습니다모쪼록 답이 되었길 바랍니다! 감사합니다!

null 을 많이 허용하지 않는 이유

안녕하세요 질문 감사드립니다!우선 저는 nullable 자체가 불확실성을 퍼트리는 역할을 한다고 생각합니다그런 측면에서 기본값이 존재한다면 이 불확실성이 퍼지는 것을 막을 수 있습니다특히 null 체크하는 로직이 계속 퍼져나가게 되는 상태에서 -1 같은 기본 값을 쓴다면별도 null체크 로직 없이 findById(-1) = 결과없음 = 로직상 진행 할 것이 없음 이런 흐름이 나타나게하는데 가능하다면 이것을 선호하는 편 입니다물론 nullable하다면 null 일 경우 별도 로직을 추가해애초에 조회를 하지 않고 에러를 뱉거나 할 수 있지만, 디비 자원이 크게 영향이 가지 않는 수준이라면 저는 코드에 좀 더 투자하는편 인 것 같습니다 😃그치만 그렇다고해서 항상 기본 값을 구성 할 수는 없다고 생각하기도 합니다, 그래서 가급적 명확히 통제 된 null을 사용하는 것을 선호하는 것 같습니다!(특정 레이어에서 객체가 변환되어 넘어갈 때 무조건 null을 없애게 끊게 한다던가 하는 식입니다) 또 특정 상황에 DB데이터를 확인할 때 레거시들에서 null 자체가 모호함을 주는 경우가 꽤 많아서 불호하기도합니다, 레거시들 보다보면 이게 정말 데이터가 없어서 null이란건지 아니면 초기화가 안 됬단건지...? 이런 데이터 관점에서도 모호함을 보여주기 때문에 가급적 DB에 null을 넣는 것을 최소화 하는 것을 선호합니다결국 장점을 요약 한다면 불확실성의 전파를 막고, 트레이드오프가 있지만 코드를 더 단순화하게 하고, 모호함을 줄일 수 있기 때문인 것 같습니다 (아마 장점이 더 있을텐데 지금 생각나는 것은 이 정도네요!) 결국 당연하지만 전략이란거는 적합한 상황에 맞춰서 쓸 때 가장 효율을 발휘하는 것 같습니다또 가장 중요한건 이 전략 관련해서는 팀/동료들과 얘기를 해서 기준을 정하는게 좋다고 생각하는 편입니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??

안녕하세요 질문 감사드립니다!저도 이제 시간이 지나서 가물가물한데요ㅎㅎ(아래 관련 유튜브 영상이 있습니다!)spring data 내부적으로 새 객체와 저장 된 객체를 구분할때 null 뿐만 아니라, Number Type에 따라 0일 경우 새 객체로 처리하는 로직이 존재하고 있었던 것으로 기억합니다.이게 그 수정 자체가.... 코틀린 호환 때문에 한거였는지는..? 저도 가물가물한데요 스프링 쪽 커밋 히스토리를 찾아봤을때 논의가 있고 결정이 된 사항으로 알고 있습니다아무튼 프레임워크 내부적으로 해당 방식을 지원하고 있고, 여태 제가 여러번 사용해봤는데 실질적인 문제는 못 느끼고 있습니다(아시는 분이 아마 문제 있을거라고 했는데 무슨 문제인지 정확히는 알려주시더라구요ㅎㅎ;;) 일단 프레임워크에서 지원하는 것과 별개로 왜 안쓰냐로 넘어가면..! 코틀린 코드에서 id 가 nullable 할 경우 계속 !! 를 붙혀주는게 보기가 싫었습니다 😅Repository 에서 조회 시에는 무조건 id가 null이 아닌 상태인데 코드에 계속 !!이 붙어 다니는게 비효율적으로 보였습니다ㅎㅎ그래서 프레임워크 레벨에서 지원하니 0으로 초기화해서 사용하고 있고, 저도 아직까지는 다른 문제를 찾지는 못해서 계속 유지 중입니다.다만 정석적으로 접근한다면 null로 선언하는게 맞다는 점은 참고 부탁드립니다!관련 유튜브 영상 링크 전달드립니다! 감사합니다!

제미니님 안녕하세요!

안녕하세요 질문 감사드립니다!목록을 보여줄때 개념간 격벽을 구성하지 않고 해당 데이터들을 조회하려면말씀해주신대로 10개 먼저 조회 후 ID기반으로 병합할 데이터를 조합 후 합쳐서 내려주면 될 것 같습니다 (그 역할을 프레젠테이션 레이어에서 하면 좋을 것 같구요!)+ 홍보아닌 홍보지만 후속 강의인 "커머스 레거시 x AI편"에서 마침 "상품 목록 조회 시 찜 수, 주문 수"를 조회하는 요구사항이 있습니다 😃위에 언급한 합성/조합에 대한 관점을 설명하오니 궁금하시다면 참고하셔도 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

JetBrains All Products Pack 3개월 이용권 신청 관련 문의

앗! 해당 이용권 증정 이벤트 관련해서는 제가 직접적으로 처리 및 관리하고 있지 않습니다!관련해서는 info@inflearn.com 으로 문의주시거나 인프런 고객센터 쪽으로 확인 부탁드립니다!우선 제가 담당 팀에게도 확인 요청 메일은 드려놓도록 하겠습니다!

개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조

안녕하세요 질문 감사드립니다![질문1]이 부분에서는 전략적으로 방향을 정해 선택을 해야하긴합니다저는 이 케이스라면은 로직을 조합하는 방식으로 해결할 수 있을 것 같습니다각 개념의 로직을 가능한 단순화 시키고 지키겠다는 방향으로 결정한다면조회 시에는 상품 목록 먼저 조회 후 리뷰 수, 찜 수를 불러와서 병합 할 것 같구요(그에 대하여 조합하는 레이어 또는 영역에 대한 고민은 필요할 것 같습니다)또 정렬을 진행한다면 복합 정렬이 아니라 단순 정렬이라면 리뷰 개념에서 먼저 상품 정렬에 대한 데이터를 가져온 후 상품을 가져오는 것도 방법일 것 같습니다 다만 이는 전체 코드 뉘앙스와 그만큼의 트레이드 오프가 가치가 있는가? 를 검토해보셨으면 좋겠습니다쿼리와 조인으로 풀면 심플한데 그렇게까지 유지해야하는 이점이 명확해야 할 것 같습니다제가 제안하는 격벽과 개념은 유연한 편입니다, 설계 개념/문서 같은 개념이 아니라 지금 나의 소프트웨어의 상태를 관망하고 고민하고 그대로 표현하는 형태이기 때문에 충분히 열고 닫힐 수 있습니다.그래서 충분히 근거가 타당하다면 일관성 유지는 어느 정도 타협 할 수 있다고 생각합니다특히 비즈니스의 흐름과 임팩트가 상품 목록에 담겨있다면 사실상 상품목록 조회는 애초에 모~든 개념을 다 알아야할 수도 있습니다말 장난이기도하지만, 그렇다면 "상품 목록" 자체가 전역에 있는 개념과 같이 봐야할 수도 있는 것 같습니다물론 저라면 그럼에도 적절히 합성 하는 방식을 선택할 것 같긴한데 어려운 상황도 분명히 있을 것입니다[질문2]음.. 우선 상품 목록의 찜 수, 리뷰 수 조회 시 별도 API를 호출하는 것은 타당하지 않은 구조라 생각하고 좋지 못한 구조라고 생각합니다그런 의미에서 저는 Presentation Layer(Controller 클래스들)은 개념 영역 바깥이라고 생각합니다(강의에서도 언급 했던 것 같은데 벌써 가물가물하네요;;)그래서 상품 목록 API는 1개로 유지하고, 그 안에서 로직적으로 ProductService, FavoriteService, ReviewService 를 조합하는 형태로 진행하시는게 좋을 것 같다고 생각합니다 만~약 API를 정말 나눈다하더라도 상품별로 각각 호출하는 것이 아닌 "상품 목록 조회 API -> 리뷰수 조회 API (ProductIds 를 받아서 벌크처리)" 이렇게 되어야 할 것 같은데, 상당히 비효율적인 방식이라고 보여집니다+ 홍보아닌 홍보지만 후속 강의인 "커머스 레거시 x AI편"에서 마침 "상품 목록 조회 시 찜 수, 주문 수"를 조회하는 요구사항이 있습니다 😃 (찜/주문 수 정렬 요구사항은 없긴합니다, 다만 위에 언급한 합성/조합에 대한 관점을 설명하오니 궁금하시다면 참고하셔도 좋을 것 같습니다!)모쪼록 답이 되었길 바랍니다! 감사합니다!

도메인 패키지의 격벽 범위와 레이어 간 경계에 대한 질문

안녕하세요 질문 감사드립니다![질문1]우선 적어주신 예제들도 격벽은 잘 지켜지고 있는 상태입니다, 개념(일반적으로 모호하게 쓰는 도메인이란 용어랑은 다름)에 대한 격벽이 둘러져있고, 격벽을 통과할 수 있는 허용 된 개념을 관리하고 있고, 적어주신 대상들이 모두 격벽을 넘는데 허용이 된 협력 관계의 개념들 때문에 격벽은 잘 유지되고 있는 상태입니다.예를들면 개념정리 내용을 보면 Payment 개념은 격벽을 통과하여 Order, Point, OwnedCoupon 와 관계를 맺고 있습니다그 상태 자체로 Repository를 접근하거나 도구 레이어에 접근해서 도구 클래스를 사용하는 것이 격벽을 지키지 않는 것은 아닙니다(아래도 적었지만 Repository 를 접근할수 있게 하냐는 다른 관점의 문제입니다, 격벽의 참조 허용은 A개념이 B개념을 알아도 되는가? 허용할 것인가? 가 전부입니다, 방화벽(Allow/Disallow)을 생각해보셔도 좋습니다)추가로 당연하지만 Service가 Service를 사용하는 방식 등에 대해 전략을 정하기 나름입니다만 제 경우는 비즈니스 로직 클래스가 다른 비즈니스 로직 클래스를 접근하는 것을 선호하지 않습니다그렇지만 Repository 를 직접 접근하는 것은 또 레이어 규칙을 어떻게 가져가야할지 전략을 선택해야하는 부분이긴합니다(관련 내용은 지속 성장 가능한 소프트웨어를 만들어가는 방법(동명의 인프런 무료 강의도 존재)에 있으니 궁금하시면 참고 부탁드립니다) 패키지을 나눴을 때 참조하고있는 다른 개념이 보여지게 된다면 그것 자체가 관계가 있다는 것을 보여주는 것이고, 그런 참조 상태를 보면서 격벽을 누구나 너무 쉽게 넘나드는지, 누가 넘을것인지, 어느 방향으로 넘길것인지 이런 것들을 고민하면 좋을 것 같습니다[질문2]비즈니스 레이어는 여러 도메인을 조합해 비즈니스 로직을 수행하는 레이어라고 이해했는데요.이 부분에 대한 이해가 저의 의도와 다른 것 같습니다, 비즈니스 레이어는 지정 된 개념(결제, 주문 등)에 대한 비즈니스 로직을 수행하는 레이어라고 이해하는 것이 더 적절할 것 같습니다그래서 단순히 여러 도메인을 조합 하는 관점 보다는 한 개념의 비즈니스 로직을 잘 나타내는 것이 주 목적이기 때문에 도메인 패키지에 있어도 괜찮다고 봅니다.(그래서 격벽을 세우고 참조 관계를 어떻게 맺을지 관리해야하는 것이죠, 아무나 격벽을 막 넘나들면 안 되기 때문에) 제 경우 패키지는 다양한 전략으로 사용하지만 보통 비즈니스 로직을 조합해야할 때 를 별도 패키지를 구성하는 것을 고민+검토하는 편입니다.이는 각각의 개념에 대한 비즈니스가 탄탄한 상태에서, 비즈니스와 비즈니스가 융합되는 형태가 보여질 때 사용하는 편입니다강의 기준 적절한 예제가 안 떠오르는데..... 대략 포인트와 쿠폰이 융합된 포인트쿠폰이란게 생긴다면 한쪽의 비즈니스에 속해있는 것이 아니기 때문에 융합하는 고민을 해볼 것 같습니다(복합결제 모쪼록 답이 되었길 바랍니다! 감사합니다!

프로덕트와 프로덕트카테고리 사이의 삭제 정책

안녕하세요 질문 감사드립니다!실무 상황마다 다를 수 있지만 일반적으로 삭제 시에 완전 삭제(hard-delete)가 아닌 삭제에 대한 플래그 처리(soft-delete)를 하기 때문에 이 부분은 선택 사항 정도로 볼 수 있을 것 같습니다다만 데이터의 정합성을 좀 더 중요시 하겠다면, ProductCategory의 상태도 삭제로 동기화 시켜놓을 수 있을 것 같습니다다만 ProductCategory를 완전 메타 데이터라고 정의한다면 상태 자체도 불 필요 할 수 있을 것 같네요(메타 데이터이기 때문에 Prodcut가 삭제 상태로 변경 된 상태면 ProductCategory또한 부모의 상태를 따르는 형태, 다만 운영팀에서 삭제 시에 Hard-Delete로 데이터를 정리해야함) 다른 상황과 배경으로는 Product, ProductCategory 모두 각각 상태가 있다고 가정했을때Product 삭제 시 ProductCategory도 모두 삭제 상태로 변경해뒀을 때삭제 복원 or 상태 재변경 기능이 있을때 모두 삭제 된 상태인 ProductCategory 중 어떤 것이 실제 삭제 된 것이고 운영팀이 임의로 삭제한 것인지 구분이 안 될 수 있습니다만약 Product의 상태만 바꿔두었다면 ProductCategory는 복원할 필요가 없고 최종 상태를 그대로 유지하고 있는 것이죠ProductCategory는 독립적으로 사용 될 가능성이 없기 때문에 반드시 동기적으로 삭제할 필요는 없다는 생각도 들긴합니다 이렇듯 실무에서는 요구사항과 전체 상황을 고려해서 삭제에 대한 전략을 판단이 필요합니다 😃모쪼록 답이 되었길 바랍니다! 감사합니다!

소스코드 보안

안녕하세요 질문 감사드립니다!사실 이 강의를 만들게 된 배경 중 하나가 질문해 주신 것과 같은 내용으로 제 개인 메일로 고민 상담을 많이 하셨던 것이 있습니다그런 의미에서 이렇게 공식적(?)으로 질문 주셔서 감사하네요 ㅎㅎ일단 기본적으로 보안에 대한 전략은 유료 플랜 결제 후에 설정으로 입력(Input)/출력(Output)을 학습 용도 또는 다른 목적으로 재사용하지 않게 하는 설정들이 존재하는 경우가 있습니다또는 공식적으로 사용자의 데이터를 사용하지 않는다고 공개 해둔 신뢰도가 있는 곳의 AI Agent를 사용하면 되는 것 같습니다 또한 그전에 기본적인 자세로는 소스코드 및 접근 데이터에 각종 KEY 및 민감 보안 정보가 존재해서는 안 됩니다 (사실 이건 AI를 쓰기 전부터 기본적으로 지켜야 하는 사항이죠 😅) 조금 민감한 곳에서는 PC 설치형으로 사용을 전사에 도입 전에 보안팀에서 모니터링을 통해 요청 외에 부가적으로 사용자의 데이터를 수집하거나 PC를 스캔하는지 등등을 체크해 주기도 합니다만, 서비스 제공자가 바보가 아닌 이상 대부분 자기들이 말한 서비스 약관을 지키는 것으로 확인된 것으로 알고 있습니다 그래서 팀원들을 설득하려면 공신력 있는 자료, 보안팀이 도와줄 수 있다면 검토 요청을 해볼 수 있을 것 같습니다 다만 이건 팀원 혼자로써는 좀 어렵죠..... 회사 규모가 있다면 상위 조직장에게 계속 에스컬레이션 해야 할 것 같습니다, 일반적으로 생산성 증가 자체는 무조건 발생할 것이니까요!그래서 이번 강의에서도 Junie를 사용하긴 했습니다, 비슷한 고민 있으신 분들의 환경에서도 Junie는 사용 가능하시더라구요 (이미 유료 버전으로 구매가 되어있기도 하구요, 부여 토큰은 적지만요ㅎㅎ;)claude, codex, gemini 등도 당연히 무료 사용이 가능하지만 아직 회사 레벨에서 허용하지 않는 경우가 꽤 많은듯합니다 😢그래서 Junie를 통해 생산성 증대와 베타적인 팀원들의 공감대를 끌어내보시면 좋을 것 같습니다실제로 팀원들 설득 방법은 결과물을 보여주는 방법밖에 없다고 봅니다그렇기 때문에 아래와 같은 실제 사례들을 계속 만들고 보여주고 느끼게(체감하게) 만들어서 흥미가 있는 팀원들을 계속 모아야 합니다테스트가 없던 기존 코드의 테스트 코드신규 기능에 대한 스펙 정의 문서기존 코드의 코드 규칙 분석 문서 및 구조 문서기존 코드의 문제에 대한 분석 문서우리 팀의 규칙이 일관적이지 않다면 그에 대한 문서우리 팀에서 코드에만 녹였던 규칙에 대한 표준 문서AI를 활용 가이드라인내가 사용한 프롬프트 이력들 (이렇게 써보세요! 전 느낌)추가로 적어주신 내용은 극단적이 아닌 아주 좋은 예시입니다, 사실 저도 프로시저를 걷어내는 것을 과거에 여러 번 아주 많은 양을 해봤었는데요 (사람이 할 짓이 못된다고 봅니다)AI의 발전으로 프로시저 쿼리 자체의 분석/분해/재구성/검증이 아주 많이 쉬워졌다고 생각합니다가장 베타적으로 쓴다 하더라도 기존에 방대한 프로시저의 분석 자체로 시작해서, 이걸 코드 기반 로직 조합 방식으로 변경을 요청하고 이를 검수해서 검증까지만 잘 하면 옮겨낼 수 있는 거죠트리거의 경우는 검수를 추가적으로 더 하긴 해야 하지만 맥락은 똑같습니다DB 중심 소프트웨어에서 어플리케이션 중심 소프트웨어로 조금씩 레거시를 개편하면서 옮겨올 때 AI의 활용도와 효과는 아주 좋다고 생각합니다 저라면 일단 팀원들을 설득하기 위해 AI에게 프로시저 분석 결과 / 그 속의 정책 내용을 추출해서 동료 개발자 및 기획자(or 도메인을 잘 아는 누군가) 와 공유할 것 같습니다보통 제 경험상 그런 스타일 레거시는 최신화된 온전한 문서/정책서가 없을 가능성이 높습니다(문서가 있어도 최신이 아니라 입에서 입으로 옮겨온 구전임)그런 방식으로 접근해서 실제 개선->검증까지 넘어가는 것을 보여준다면 팀원들도 분명히 흥미를 가질 것이라고 생각합니다모쪼록 답이 되었길 바랍니다! 감사합니다!

AI 사용 방법에 대하여...

안녕하세요 질문 감사드립니다!최근에 저에게 메일로 이런 비슷한 질문을 주신 분들이 꽤 많았습니다시장이 빠르게 변하고 있다고 난리지만 내 앞의 현실 / 내 일터에서는 "나만 그렇게 느끼나? 내가 예민한가?" 의 경우가 꽤 있는 것 같습니다제가 이번 강의 주제에 굳이 AI를 넣은 것도 그런 고민들에서 출발했던 것 같습니다. 아무튼 사설이 길었는데 질문에 대해 답변드리면, 활용 방안에 대해서는 모두 말해도 된다고 생각합니다다만 말로만으로는 나아지기 어려울 수 있습니다그렇기 때문에 아래와 같은 실제 사례들을 계속 만들고 보여주고 느끼게(체감하게) 만들어서 흥미가 있는 팀원들을 계속 모아야 합니다테스트가 없던 기존 코드의 테스트 코드 신규 기능에 대한 스펙 정의 문서기존 코드의 코드 규칙 분석 문서 및 구조 문서기존 코드의 문제에 대한 분석 문서우리 팀의 규칙이 일관적이지 않다면 그에 대한 문서우리 팀에서 코드에만 녹였던 규칙에 대한 표준 문서AI를 활용 가이드라인내가 사용한 프롬프트 이력들 (이렇게 써보세요! 전 느낌)이런 결과물들을 계속 git 또는 팀 문서에 올리고 팀원들과 공유해서 흥미를 느끼게 하는게 중요하다고 생각합니다이게 왜 중요하냐면 팀 전체가 AI 활용에 관심이 많아지고 적극 활용하면 팀의 재산이 되고 팀 자체의 성장과도 연결이 되기 때문입니다아직은 인간의 시대기 때문에 AI 활용을 잘 하는 팀원들이 뭉치면 점점 더 많은 일을 할 수 있다고 봅니다사실 강의에서 설명한 활용하는 방안들은 어떻게 보면 활용법 중 일부지만 결국 잘 활용하는 근본은 똑같다고 생각합니다그리고 근본을 잘 이해하고 있다면 다른 확장 도구들이 쥐어졌을 때 날개를 달 수 있을 것이고요다만 안타깝게도 저도 당연히 AI 활용 전문가는 아닙니다, 그래서 제 방법이 베스트를 다 모은 거라고 할 수는 없습니다 😅정말 중요한 건 개인이 아니라 팀이 일을 더 잘하기 위해 AI를 어떻게 더 활용할 수 있을까를 같이 고민하는 것이라고 생각이 됩니다.모쪼록 답이 되었길 바랍니다! 감사합니다!