안녕하세요!AI로 개발하는 대략적인 방법에 대해서 알 수 있어서 재밌게 잘 듣고 있습니다!! 다만, 프론트에서 React 훅을 만드는 작업(API 작업)을 다루는 부분이 많이 스킵되어 이 부분을 어떻게 처리해야 할 지 고민이 됩니다.이전에 AI로 프로젝트를 진행할 때에도, 이미 만들어진 UI/UX에 API 추가하는 것이 항상 어려움이 있었던 작업이라..혹시, API를 연결할 때 조금 더 수월하게 할 수 있는 팁 같은 것이 있을까요?감사합니다!

책 99페이지에서 만든 ProductController는 src/test/java 하위에 만들어져있는데, 이곳에 파일을 그대로 둔 채로 책 107페이지 스프링 빈 실습을 진행하면 제대로 진행이 되지 않았습니다.혹시나 하여 test가 아닌 src/main/java 하위로 옮기고 진행하니 책의 결과와 같은 결과가 나왔습니다. 책 어디에도 ProductController의 파일 위치를 옮긴다는 말이 작성되어있지 않은데 옮기고 진행하는 것이 맞는지 궁금합니다!   

안녕하세요! 디테일한 건데요. 오타 제보 합니다!as-is스마트폰to-be스마트폰 케이스감사합니다.

안녕하세요 학습중인 수업자료를 받아볼 수 있을까요??

안녕하세요~! 영한님category_path 를 생성하는 과정에서 idx_descendant 인덱스를 생성하는데요. descendant_id 는 외래키로 설정해서 인덱스가 자동으로 생성되지 않나요?!아래 쿼리를 실행했을 때 index 가 생성되는 것을 확인 했습니다!create table category_path ( ancestor_id bigint not null, -- 조상 노드 descendant_id bigint not null, -- 자손 노드 depth int not null, -- 거리 (깊이 차이) primary key (ancestor_id, descendant_id), foreign key (ancestor_id) references category_closure(category_id), foreign key (descendant_id) references category_closure(category_id) ); create index idx_depth on category_path(depth); show indexes from category_path;  create index idx_descendant on category_path(descendant_id);위와 같이 명시적으로 인덱스를 생성한 이유가 있을까요? 감사합니다.

AI로 코드를 분석해보거나레거시의 수정 포인트를 느껴보거나 하는 부분은많이 와닿았는데요.AI 가 코드를 수정한 이후에코드를 비교해보는 영역에서 브랜치를 어떻게 관리하는게 좋을 지 의문이 들었습니다.AI 가 다수의 코드를 변경하고 있는데, 실제 실무에서는 한 꺼번 에 코드를 바꿔버리면 diff가 너무 많아서 개발시 우려되는 부분이 많이 생깁니다.gpt에 물어보면 ai/product-draft 와 같이 실험용 브랜치에서 작업 이후에 선별하여 수정하라는 답변을 받았는데요.아직 섹션3을 수강하고 있어서, 이른 질문일지 모르지만 해당 사항 관련하여 실무적인 관점에서 실제로 어떻게 하는게 좋은 방법일 지 조언 한 번 부탁드립니다.

이런식으로 mysql.server start 를 했는데저렇게 다음 명령어?로 넘어가서뭔가 더 작성을 해야하는거 같은데..제가 뭔가 다운을 덜 받은건가요? 아니면..뭔가 더 입력을 해야하나요? 여기서 막혀서요 ㅠ  

안녕하세요, 이번 강의를 듣고 아주 간단한 질문을 남깁니다.Soft Delete + 이력 테이블 설계가 필요한 이유가 외래 키 제약 조건으로 인한 삭제 어려움 때문이라 이해했습니다.일부 실무자들은 이러한 삭제 불편함으로 인해 물리적으로 외래 키 제약조건을 DB에 걸지 않는다는 말을 들은 적이 있는 것 같은데요, 만약 그렇게 제약이 없다면 단순히 Hard Delete + 이력 테이블 구조로 고정해도 괜찮은 걸까요?

어노테이션 뭐가 있는지 궁금했습니다. 스프링 공식 문서(https://docs.spring.io/spring-framework/reference/index.html)에 Annotation 검색해보니까 여러가지가 나오네요. 어떤 걸 봐야 어노테이션 전체를 볼 수 있나요?어노테이션 페이지가 따로 없나요?

혹시 프로젝트 아키텍처는 어떤 구성을 위주로 구성하였을까요?제가 보기에는 핵사고날 아키텍처를 일부 차용하여 성향에 맞게 적용한 것 같은데이 아키텍처로 페이먼트서비스를 만든 이유와 장단점 같은 게 궁금합니다.

여기 수업자료 .env sample만 있는게 맞을까요? 수업화면에 보이는 pdf가 없습니다.

학습 관련 질문이 있으시면, 상세하게 남겨주세요.문제가 발생한 부분의 코드를 함께 올려주세요.수업 영상 몇 분/초 구간인지 알려주세요.

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 primary key 로 where 절에 넣고 select 를 하면 key 에 primary 가 찍혀 효율적인 조회가 가능하다고 알고있습니다! 그런데 수업 내용에서 EXPLAIN SELECT item_id, price, item_name FROM items WHERE price BETWEEN 50000 AND 100000; 해당 쿼리를 사용하면 extra 에 Using index condition 나와 인덱스를 사용해서 구했다 < 까지는 이해가 가는데 여기서 item_id 라는 primary key 가 존재하는데 이거로 db 접글을 재시도하면 어째서 랜덤i/0가 발생하는건지 궁금합니다.

강사님 안녕하세요. 쿠폰 조회 로직 구조 관련해서 의견 여쭤봅니다.현재 제 구현은 findBestBenefitCoupons에서 DB(Querydsl) 쿼리 하나로- 대상 필터링(INCLUDE/EXCLUDE, 기간, 상태),- 할인금액 계산,- 적용가능 여부 정렬,- 페이지네이션(Slice)까지 전부 처리하고 있습니다.그런데 쿼리가 너무 복잡해져서,“DB에서는 가능한 필터링/후보 추출만 하고, 복잡한 적용 규칙/최종 정렬은 애플리케이션 레이어에서 처리”하는 방식으로 바꿔도 괜찮을지 고민 중입니다.제 가정은 사용자별 쿠폰 수가 많아도 수천 장 수준이라 앱 처리도 감당 가능하다는 점입니다.강사님 코틀린 예제CouponTargetReader)는 DB는 타겟 조회 중심이고 조합은 앱에서 하는 패턴으로 보였는데,제 케이스(최적 쿠폰 + 페이징)에도 이 방향이 실무적으로 타당할까요?아니면 정렬/페이징 일관성 때문에 핵심 랭킹 로직은 DB에 유지하는 게 더 맞을까요?추가로 궁금한 점이 있습니다.대규모 커머스 회사에서는 이런 “최적 쿠폰 목록” 문제를 보통 어떻게 처리하나요?쿠폰 목록은 조건(회원/주문금액/대상/기간)이 많아서 캐싱도 쉽지 않아 보이는데,실무에서는 어떤 식으로 분리(DB/애플리케이션/배치/사전계산)하고 어떤 기준으로 설계 결정을 내리는지 궁금합니다.저는 지금 소규모 서비스에서 개발 중이라,대규모 트래픽/대량 데이터 환경에서의 실무 관점 인사이트를 얻고 싶습니다.판단 기준(데이터 건수, 성능 임계치, 페이지 정합성, 운영 복잡도)도 함께 조언 부탁드립니다. 

정답으로 보여주신 이미지에는 아래와 같이 FK가 설정되어있는 것 같았는데 맞을까요?profiles.user_id -> auth.users.id (CASCADE) todos.user_id -> auth.users.id (CASCADE) todos.user_id -> profiles.users.id (CASCADE)todos.user_id -> profiles.users.id를 잇는 FK는 왜 필요한거고, 어떤 의도로 생성하는것인지 궁금합니다

date_part의 결과에 대한 data type을 출력해 보니 "double precision"으로 나옵니다. 저는 date_part에서 추출한 part가 예를 들어 'month'라고 하면 그 값 자체가 date 유형으로 생각해서 to_char(date_part('month', hiredate), 'month')의 결과가 'january' 로 기대했는데, 오류가 나오더라구요.

p107'3주 차 난생 첫 프로젝트, 상품 조회와 등록 API' 내 '4 스프링 IoC & 스프링 빈 등록하기' 내 '@Component를 달아 두면 생기는 일' 질문 입니다.  AnnotationDemo 클래스가 어디있는지 모르겠습니다. 

안녕하세요.주문, 상품과 같은 비즈니스에 중요한 데이터를 전체 행 스냅샷 이력 테이블로 관리 하는 상황일 때, 대상 테이블(주문, 상품 등)의 칼럼이 추가/삭제되는 상황에 이력 테이블에 어떻게 반영해야할지 질문 드리고 싶습니다.- 추가: 신규 기능으로 인해 새로운 칼럼 추가- 삭제: 기획 변경으로 오랜 기간 미사용 칼럼으로 낭비되어 삭제로 결정된 경우 등 

안녕하세요!강의를 다 보고 이 프로젝트를 제 손으로 다시 작성해보려고 합니다.코드를 눈으로 쭉 봤지만 SQL, 데이터베이스 구조 등은 정확히 들여다보지는 않았기 때문에...무엇보다도 코드를 느끼려면 다시 작성해보고 테스트도 보고 그러는게 좋을 것 같아서요. 완전 같게 작성하기 보다는 강의에서 해주셨던 부분들 개선해보거나 바꿔보거나 하려고요 저는 python 개발자이기 때문에 Spring 대신 FastAPI, JPA 대신 sqlalchemy 를 사용하려 합니다.작성하려고 보니 어떤 순서로 작성하는 것이 좋을까 질문 드려도 되나 싶어서 질문 올려봅니다. 일단 제 생각에는 v1/products 부터 시작 하려고 하는데우선은 프로젝트 구조부터 간단히 잡고 그 다음은도메인 클래스, 엔티티, productService, controller 순서로 구현/테스트 코드 작성v1/products 가 완성되면 서버 실행해서 동작 확인그 다음은 뭐 v1/products/{productId} 이런 순서로 작성해보려고 하는데요 재민님은 혹시 이 프로젝트 만들때 어떤 순서로 구현하셨는지?혹시 테스트부터 시작 하시는지? 처음 시작할 때 의 팁 있으시면 공유 부탁 드립니다 좋은 강의 감사합니다! 

강의에선 되게 단순하게 큰 틀 위주로 알려주시는 것 같아서 개인적으로 더 자세한 의미나 추가적인 개념이 궁금할 때 검색해보는 편인데, DI라는 것이 클래스 간의 결합도를 낮추고 객체의 유연성을 높이기 위해 빈 객체를 만들어 주입하는 것을 의미한다고 정리했습니다. 이게 맞게 정리한건지 궁금합니다. 또 추상 클래스와 인터페이스 간의 차이점은 찾아봐도 이해가 어렵길래 선생님의 친절한 설명이 필요할 것 같아서 추가로 여쭤봅니다!