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

안녕하세요 질문 감사드립니다!실무 상황마다 다를 수 있지만 일반적으로 삭제 시에 완전 삭제(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를 어떻게 더 활용할 수 있을까를 같이 고민하는 것이라고 생각이 됩니다.모쪼록 답이 되었길 바랍니다! 감사합니다!

결제 개념 컴포넌트 분리 기준과 네이밍 전략에 대한 질문있습니다 !

안녕하세요 질문 감사드립니다![질문1]제가 느낀 것은 결제의 생명주기는 큰 기준에서 분리되어 있다고 생각했습니다 생성 -> 성공/실패 이런 느낌으로 나뉘어져있다고 생각하였고 그 기준에서 생성과 처리(성공/실패)를 분리하게 되었습니다물론 생성 자체도 단순 처리라고 볼 수 있지만, 이는 행위적으로 생성과 생성 이후에 어떠한 과정으로 인해 발생하는 결과(성공 또는 실패)를 분리하는 구조를 만들고자 했습니다! 그렇지만 이는 제가 의도적으로 생명주기를 잘 보이도록하고 느낌을 보여드리고자 나눈 것이지 실제 적어주신 것 처럼 Processor로 처리하는게 이상하지는 않습니다! 모쪼록 이러한 관점을 참고하셔서 한번 생각해보시면 좋을 것 같습니다! [질문2]사실 저는 Manager, Processor 라는 이름을 선호하지 않습니다 😅왜냐하면 클래스 이름을 봤을때 직관성과 명확성이 떨어지기 때문입니다 그치만 실제로 초기 개발시에는 네이밍 때문에 맞추기위해 너무 작은 조각(Reader, Writer, Appender, Updater ....) 으로 쪼개면 그것 대로 비효율과 낭비가 생긴다고 생각하고 그럴때 진화 중간 단계(추후 덩치가 커지면 분리를 위한 단계)로 저런 모호한네이밍을 사용하는 편인 것 같습니다 그래서 사실 Manager, Processor, Handler 요런 네이밍 결정시에는 엄청난 기준이 있지는 않습니다ㅎㅎ;그냥 모여진 함수들의 책임이나 역할의 뉘앙스가 중계하거나 관리 역할에 가깝다면 Manager를 쓰는 것 같고 / 처리 관점의 뉘앙스가 강하면 Processor 라고 지칭하는 편입니다! 적으면서 생각해보니 결제 개념에는 처리가 더 자연스럽게 잘 어울리다고 판단한 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

PaymentValidator와 PaymentProcessor에서 주문과 결제를 중복 조회하는 구조에 대한 질문이 있습니다 !

안녕하세요 질문 감사드립니다!적어주신 것 처럼 비즈니스 흐름을 명확히 들어내는 의도라고 이해해주셔도 괜찮습니다!부가적으로 이러한 분리가 각 클래스들의 책임과 맡고있는 역할도 명확해지는 것 같습니다! 추가적으로 적어주신 방식도 가능은 할 것 같습니다만, 느낌적으로 잘 봐야할 것 같습니다지금 코드 없이 상상을 해봤을때는 Validator가 validation 까지 처리한 후 PaymentContext를 직접 만드는 책임을 갖는 것은 조금 과하지 않을까? 라는 생각이 드는 것 같습니다일반적으로 validator의 결과는 예외를 던지거나 validation의 상태를 전달하는 정도가 적합하다고 생각되어 Context는 너무 크지 않을까하는 생각이 드는 것 같습니다! 다만 이는 불가하다거나, 구조적 문제 보다는 얼마나 더 비즈니스와 협력 도구들의 관계를 잘 나타내는지 관점으로 생각하면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

사용자가 상품을 선택하고 쿠폰을 고를 때 가장 혜택이 큰 쿠폰을 고르는 상황

안녕하세요 질문 감사드립니다!우선 findBestBenefitCoupons 이 무슨 기능인지와, 쿼리 분할 또는 어플리케이션에서 로직 적용 가능 여부를 검토해봐야할 것 같습니다만 최종적으로 핵심적인 필터링 +페이징 + 정렬에 대한 부분을 포함하려면 쿼리 레벨에서 처리하는게 성능적으로 구현적으로 훨씬 더 좋다고 보긴합니다오히려 쿼리를 분할하려면 대상을 추출하는 쿼리 + 데이터를 채우는 쿼리 (in절로 ID를 받거나함) 이렇게 두개정도로 나눌 수 있을 것 같습니다 다만 적어주신 것 처럼 사용자 별 쿠폰 수 자체가 많지 않는 것을 맞기 때문에 어플 구현 로직으로 풀 수 있다는 것도 타당한 관점이긴합니다 (데이터 건수가 적기 때문에)그렇지만 항상 규모가 커질 것을 예상하고 대비하는 것이 중요하다고 볼 수도 있으니 이런 조회는 최대한 DB 리소스를 활용하는게 좋지 않을까란 생각이 먼저 드는 것 같습니다!타당성은 둘 다 있으니 결정하시면 좋을 것 같습니다 (저라면 쿼리를 분할 할 수 있는지 각을 보고 또는 얼마나 복잡한 쿼리인지 분리 + 최적화가 불가한지에 따라 결정할 것 같네요)적어주신 "최적 쿠폰 목록" 기능이 정확히 뭔지 모르겠지만 유추해보면 결제 금액에서 최대한 많이 쓰게해서 최적의 쿠폰을 적용해주는 기능 이라고 유추가 되긴합니다이 전제라면 사실 사용자의 활성화 + 최소 주문 조건이 허용 +@ 어쩃든 적용 가능한 대상 쿠폰을 목록을 전체 가져와서 로직으로 loop를 돌릴 것 같습니다이 기능 자체는 대규모로 가더라도 데이터 규모 자체가 적어주신 것 처럼 기하급수적으로 커지긴 힘드니 별반 다르지 않은 것 같습니다 추가로 막연한 대규모에서도 모든 부분이 대규모는 아니다 보니까 또 엄청나게 특별함이 있지는 않습니다모든 기능이 대규모 데이터/트래픽이 되지는 않다보니 가장 중요한건 데이터의 수 / 데이터의 성장 곡선 이런 기준이 기본이 되는 것 같습니다 서비스 특성이 쿠폰을 난사하는 패턴이 아닌 이상 사용자가 보유한 활성화 된 쿠폰은데이터 규모가 작기 때문에 크게 캐싱을하거나 할 필요성도 크게 못 느끼는 것 같습니다 모쪼록 답이 되었길 바랍니다! 감사합니다!

AI 를 적용시 브랜치를 다루는 팁 같은게 있을까요?

안녕하세요 질문 감사드립니다!오...! 사실 이 부분은 이번 강의에서 직접적으로 언급하지는 않습니다만! 중요한 부분 같습니다! (저도 계속 실험하면서 고민하고 있는 부분이고요) 이것 관련해서는 여러 전략을 사용하는 것 같은데요기본적으로는 AI에게 요청한 Task별로 브랜치를 분리 하는게 아직은 좋다고 생각합니다가령 동시적으로 작업을 시킬때 main 브랜치 그 자체에 모두 작업을 한다면 생각보다 작업 사항이 제대로 이행됬는지 스르륵 (또는 꼼꼼히) 리뷰하기가 힘들어집니다그래서 AI에게 요청할 작업 단위를 적절히 나눴고 병렬 적으로 Task를 돌린다면 자연스럽게 브랜치를 나누는게 맞다 생각하는 것 같습니다 +아예 같은 repo를 local에 n개 clone 받아서 병렬로 돌리시는 분들도 있다고 합니다(다만 이제 AI Agent들이 worktree 자체를 너무 잘 활용해서 이럴 필요도 없다고 하시는 분들도 있구요ㅎㅎ, 저도 몇번 테스트 해봤는데 정신 없기도하고 괜찮기도 했습니다) ++ 이런 전략 또한 사실 매일 바뀌는 것 같습니다, 트렌드가 너무 빠르게 변화고 진화하고 있어서 잠깐 놓치면 다른 전략이 대세더라구요ㅎㅎ.. 최근에 본 어떤 분 의견은 브랜치 분리 자체가 필요 없다 라고 말하신 분들도 있었습니다ㅎㅎ;;모쪼록 답이 되었길 바랍니다! 감사합니다!

새로 개발한다면 구현 순서

안녕하세요 질문 감사드립니다! 다시 작성하신다니 아주 멋진 훈련입니다! 👍사실 저의 경우는 이 프로젝트는 강의 예제 목적이다보니 엄청 규칙을 잡고 구현하진 않았습닌다만실제로 실무라고 생각하고 구현해본다면 개념 클래스들과 개념 컴포넌트(Reader, Appender ... etc) 들의 구조를 먼저 잡고 세부 구현을 채워나가는 것을 선호합니다추가로 그 구조를 잡을때 테스트 먼저 시작하는 것을 보통 선호합니다 😃다만! 한가지 규칙과 패턴으로 구현하지 않는게 좋은 훈련 같습니다 (실제로 실무에서 저도 그렇게하구요!)요구사항 케이스마다 데이터베이스 먼저 구조를 잡는게 중요할 때가 있는 것 같구요!또 외부 연동 먼저 구축해놓고 시작하는게 유리한 경우가 있는 것 같구요 (ex] 결제 등등)개인적으로 아주 좋은 학습법이라 생각합니다, 많이 생각하시고 많이 고민하시면서 구현하시면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

장바구니 아이템 가격 기준?

안녕하세요 질문 감사드립니다!해당 부분은 최종 수정에서 누락난 부분 같습니다! 버그네요😱 최종 프로젝트를 수정해서 올려두겠습니다!(그전에 간단한 수정이니 AI로 돌려보시는걸 추천드려요ㅎㅎ)추가 질문 주신 부분에서 보면 ProductOption이 생기면서 Product의 가격은 무의미해진게 맞습니다, 다만 '대표 가격' 의 의미로 동작한다고 봐야할 것 같습니다이런걸 활용하는 쇼핑몰을 보면 고객의 선택을 이끌기 위해 이 가격을 활용하는 것 같더라구요 (상품 목록에서 노출 하는 가격을 이 것으로 사용)그치만 이러면 상세 페이지 와서 옵션 선택 후 가격이 증가하는 것을 보고 고객이 화날 수 있으니 적절히 조절해야하는 것 같습니다 (상품가격을 가장 일반적인 옵션의 가격으로 한다던가..)옵션개념에 대해 질문 주신 것은 별도 스펙으로 구현해야할 것 같습니다 회사마다 부루는 명칭은 다르겠지만 저는 그런 것을 '다중옵션' 이라고 부르는데요!그 스펙을 구현해야할 것 같습니다, 단일 선택이 아닌 여러 옵션을 선택해서 조합하는 방식이 되겠죠지금 코드에서 한번 구현해보시는 것도 좋은 훈련일 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

인텔리제이에서 legacy 프로젝트 그레이들 인식 불가

음 IDE에서 나오는 에러 메세지를 올려주시면 같이 확인 해볼 수 있을 것 같아요!또는 GPT한테 물어보면 빨리 답을 찾으실 수도 있을 겁니다!