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한테 물어보면 빨리 답을 찾으실 수도 있을 겁니다!

의존 방향에 대한 고민

안녕하세요 질문 감사드립니다!아주 멋진 고민들을 하고 계시군요! 그 과정 자체가 좋은 훈련이라고 생각합니다우선 적어주신 상황에 대해 종합적인 제 의견을 드리겠습니다Coupon과 OwnedCoupon은 개념적으로 같은 격벽안에 존재합니다정확히 보면 Coupon을 기반으로 OwnedCoupon이 만들어지는 구조를 갖고 있습니다(다만 이걸 부모 자식의 관계라 보기는 어렵다고 생각합니다)같은 격벽에 존재하는 측면에서는 서로 알고 있는 부분이 크게 문제가 되지 않을 것 같습니다물론 이 부분이 맘에 너무 걸린다하면 ownedCoupon 에 coupon 정보를 모두 다 넣어 버리면 ownedCoupon은 coupon을 몰라도 되겠지만 이러면 데이터 구조 및 요구사항을 불만족 하는 부분이 생기게 되겠죠, 다른 관점의 타협하는 측면에선 다른 형태의 쿠폰 데이터 객체(ex]CouponCondition..)를 구성 할 수도 있을 것 같습니다적어주신 수정 관점에서 말해주신 부분은 아주 타당한 관점입니다 그 측면으로 보면 OwnedCouponService에 있는게 맞죠 😃결국 어떤 시선으로 내가 보고 개념의 구조를 잡아갈 것인가? 이게 중요합니다Coupon 과 OwnedCoupon은 같은 개념 군집(격벽 안에) 있는가?Coupon 과 OwnedCoupon의 거리는 얼마나 떨어져있는가?Coupon 과 OwnedCoupon의 응집도가 서로를 알고 있는게 해가 되는가?요구사항 기준 OwnedCoupon이 Coupon을 모를 수 있는가?사용자가 쿠폰을 다운로드 한다 의 의미를 OwnedCoupon를 기준점으로 바라봐도 괜찮은가?이런 느낌의 질문들을 해보시고 어떻게 구성할지 기준을 정하시면 됩니다 😃(이미 적어주신 우려 사항들도 충분히 좋은 관점들입니다) 사실 적어주신 것 처럼 논리적으로 동작 흐름을 이해해보면 정적인 Coupon을 다운로드 하면 동적인(소유 관점) OwnedCoupon이 생성이 되는게 맞기 때문에 CouponService가 타당해 보이긴합니다만이걸 쉽게 뒤집어 보면 말장난과 같습니다 OwnedCoupon은 정적 기준 데이터인 Coupon을 통해서 생성 될 수 있다그러므로 interface 역할을 하는 CouponId 를 전달 받아서 스스로를 생성한다.이것을 쿠폰 다운로드라고 보지 않고 소유 쿠폰 생성 관점으로 보겠다라고 한다면 말이 이상하지 않습니다ㅎㅎ;; 그래서 이 강의의 목적도 그랬지만 최대한 많은 고민을 하시면서 기준을 정해보시길 바랍니다 😃결국은 우리가 선택한 것이 기준이 되기 때문에 나와 팀원이 충분히 납득 할 수 있는 방향이라면 그것이 정답에 가까운 것이라고 생각합니다또한 코드는 지속적으로 계속 가꿔가야한다 생각합니다! 그래서 너무 깊은 고민보다는 요구사항 구현을 먼저 충족 하면서 고민을 계속하고 구현 완료 후 남는 시간에 한번 더 리뷰를 해서 정리하거나, 추후 리펙토링 대상으로 가져가야 한다고 봅니다 (다만 추후 리펙토링 이 말은 현실적으로 안/못 보겠다는 것이랑 비슷해서.... 일정이 빠듯하면 어려운 문제입니다)모쪼록 답이 되었길 바랍니다! 감사합니다!

예약 변경 시 '과거 정책 기준 재계산' 요구사항에 따른 스냅샷 데이터 구조 설계 고민

안녕하세요 질문 감사드립니다!우선 현실적인 타협이 가장 우선시 되어야 할 것 같습니다, 어드민/CS가 개입한 예약의 변경의 경우 특정 상황에서 진행하는 게 일반 적일 것 같은데, 그런 요청에서도 과거 기준으로 모든 걸 돌려서 진행하려면 상당히 까다로워지고, 사이드 이펙트로 현재의 재고나 현재의 옵션에도 영향이 갈 수 있게 됩니다 (로직상 실수 가능성이 높다는 의미, 가령 delete 된 옵션을 쓰는 로직을 억지로 넣어야 한다거나)상식적인 선에서는 예약의 변경은 현재 정책을 따르는 게 맞다고 생각합니다.다만 서비스의 특성 및 고객의 니즈를 맞춰야 하는 게 중요하다면 (한 명이 거래액이 몇천만 원대라던가..)심플하게는 조건에 대한 값들도 별도 json에 저장하면 될 것 같습니다, 이 값은 어드민 예약 변경 시에만 쓰일 것이기 때문에 그 정도로 구성해도 되지 않을까 싶습니다 + 변경이 잦을 수 있는 현실 or 상황 or 서비스 특성이라면 json 자체는 괜찮은 선택이라고 봅니다저도 그런 경우에는 json을 쓰긴 합니다다만 예약 전까지 정보를 보통 json에 담고 완료된 최종 데이터는 온전한 테이블에 저장하는 편이긴 합니다만, 이건 요구사항+현실에 따라 판단해야 할 것 같습니다!실제로는 회사의 정확한 상황과 서비스 성장을 위한 니즈가 더욱 중요한 부분이니 답변 내용은 참고만 부탁드립니다!이번 강의도 수강 감사합니다!