176만명의 커뮤니티!! 함께 토론해봐요.
미해결
[4주 과정] 『부트캠프 백엔드 개발자 편 with 스프링 부트』 완독 챌린지
책 99페이지에서 만든 ProductController는 src/test/java 하위에 만들어져있는데, 이곳에 파일을 그대로 둔 채로 책 107페이지 스프링 빈 실습을 진행하면 제대로 진행이 되지 않았습니다. 혹시나 하여 test가 아닌 src/main/java 하위로 옮기고 진행하니 책의 결과와 같은 결과가 나왔습니다. 책 어디에도 ProductController의 파일 위치를 옮긴다는 말이 작성되어있지 않은데 옮기고 진행하는 것이 맞는지 궁금합니다!
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요! 디테일한 건데요. 오타 제보 합니다! as-is 스마트폰 to-be 스마트폰 케이스 감사합니다.
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요 학습중인 수업자료를 받아볼 수 있을까요??
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요~! 영한님 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 가 코드를 수정한 이후에 코드를 비교해보는 영역에서 브랜치를 어떻게 관리하는게 좋을 지 의문이 들었습니다. AI 가 다수의 코드를 변경하고 있는데, 실제 실무에서는 한 꺼번 에 코드를 바꿔버리면 diff가 너무 많아서 개발시 우려되는 부분이 많이 생깁니다. gpt에 물어보면 ai/product-draft 와 같이 실험용 브랜치에서 작업 이후에 선별하여 수정하라는 답변을 받았는데요. 아직 섹션3을 수강하고 있어서, 이른 질문일지 모르지만 해당 사항 관련하여 실무적인 관점에서 실제로 어떻게 하는게 좋은 방법일 지 조언 한 번 부탁드립니다.
해결됨
AI한테 시키기 전에 알아야 할 SQL/DB 초기초
이런식으로 mysql.server start 를 했는데 저렇게 다음 명령어?로 넘어가서 뭔가 더 작성을 해야하는거 같은데.. 제가 뭔가 다운을 덜 받은건가요? 아니면..뭔가 더 입력을 해야하나요? 여기서 막혀서요 ㅠ
해결됨
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요, 이번 강의를 듣고 아주 간단한 질문을 남깁니다. Soft Delete + 이력 테이블 설계가 필요한 이유가 외래 키 제약 조건으로 인한 삭제 어려움 때문이라 이해했습니다. 일부 실무자들은 이러한 삭제 불편함으로 인해 물리적으로 외래 키 제약조건을 DB에 걸지 않는다는 말을 들은 적이 있는 것 같은데요, 만약 그렇게 제약이 없다면 단순히 Hard Delete + 이력 테이블 구조로 고정해도 괜찮은 걸까요?
미해결
[4주 과정] 『부트캠프 백엔드 개발자 편 with 스프링 부트』 완독 챌린지
어노테이션 뭐가 있는지 궁금했습니다. 스프링 공식 문서( https://docs.spring.io/spring-framework/reference/index.html )에 Annotation 검색해보니까 여러가지가 나오네요. 어떤 걸 봐야 어노테이션 전체를 볼 수 있나요? 어노테이션 페이지가 따로 없나요?
미해결
견고한 결제 시스템 구축
혹시 프로젝트 아키텍처는 어떤 구성을 위주로 구성하였을까요? 제가 보기에는 핵사고날 아키텍처를 일부 차용하여 성향에 맞게 적용한 것 같은데 이 아키텍처로 페이먼트서비스를 만든 이유와 장단점 같은 게 궁금합니다.
미해결
graphRAG - Neo4J로 구현하는 지식 그래프 기반 RAG 시스템 (feat. LangChain)
여기 수업자료 .env sample만 있는게 맞을까요? 수업화면에 보이는 pdf가 없습니다.
미해결
graphRAG - Neo4J로 구현하는 지식 그래프 기반 RAG 시스템 (feat. LangChain)
학습 관련 질문이 있으시면, 상세하게 남겨주세요. 문제가 발생한 부분의 코드를 함께 올려주세요. 수업 영상 몇 분/초 구간인지 알려주세요.
미해결
김영한의 실전 데이터베이스 - 기본편
[질문 템플릿] 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가 발생하는건지 궁금합니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 레거시와 AI 활용편
강사님 안녕하세요. 쿠폰 조회 로직 구조 관련해서 의견 여쭤봅니다. 현재 제 구현은 findBestBenefitCoupons 에서 DB(Querydsl) 쿼리 하나로 - 대상 필터링(INCLUDE/EXCLUDE, 기간, 상태), - 할인금액 계산, - 적용가능 여부 정렬, - 페이지네이션(Slice) 까지 전부 처리하고 있습니다. 그런데 쿼리가 너무 복잡해져서, “DB에서는 가능한 필터링/후보 추출만 하고, 복잡한 적용 규칙/최종 정렬은 애플리케이션 레이어에서 처리”하는 방식으로 바꿔도 괜찮을지 고민 중입니다. 제 가정은 사용자별 쿠폰 수가 많아도 수천 장 수준이라 앱 처리도 감당 가능하다는 점입니다. 강사님 코틀린 예제 CouponTargetReader )는 DB는 타겟 조회 중심이고 조합은 앱에서 하는 패턴으로 보였는데, 제 케이스(최적 쿠폰 + 페이징)에도 이 방향이 실무적으로 타당할까요? 아니면 정렬/페이징 일관성 때문에 핵심 랭킹 로직은 DB에 유지하는 게 더 맞을까요? 추가로 궁금한 점이 있습니다. 대규모 커머스 회사에서는 이런 “최적 쿠폰 목록” 문제를 보통 어떻게 처리하나요? 쿠폰 목록은 조건(회원/주문금액/대상/기간)이 많아서 캐싱도 쉽지 않아 보이는데, 실무에서는 어떤 식으로 분리(DB/애플리케이션/배치/사전계산)하고 어떤 기준으로 설계 결정을 내리는지 궁금합니다. 저는 지금 소규모 서비스에서 개발 중이라, 대규모 트래픽/대량 데이터 환경에서의 실무 관점 인사이트를 얻고 싶습니다. 판단 기준(데이터 건수, 성능 임계치, 페이지 정합성, 운영 복잡도)도 함께 조언 부탁드립니다.
미해결
AI 시대에 살아남기: Supabase로 백엔드 뚝딱!
정답으로 보여주신 이미지에는 아래와 같이 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는 왜 필요한거고, 어떤 의도로 생성하는것인지 궁금합니다
미해결
데이터 분석 SQL Fundamentals
date_part의 결과에 대한 data type을 출력해 보니 "double precision"으로 나옵니다. 저는 date_part에서 추출한 part가 예를 들어 'month'라고 하면 그 값 자체가 date 유형으로 생각해서 to_char(date_part('month', hiredate), 'month')의 결과가 'january' 로 기대했는데, 오류가 나오더라구요.
미해결
[4주 과정] 『부트캠프 백엔드 개발자 편 with 스프링 부트』 완독 챌린지
p107 '3주 차 난생 첫 프로젝트, 상품 조회와 등록 API' 내 '4 스프링 IoC & 스프링 빈 등록하기' 내 '@Component를 달아 두면 생기는 일' 질문 입니다. AnnotationDemo 클래스가 어디있는지 모르겠습니다.
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요. 주문, 상품과 같은 비즈니스에 중요한 데이터를 전체 행 스냅샷 이력 테이블 로 관리 하는 상황일 때, 대상 테이블(주문, 상품 등)의 칼럼이 추가/삭제되는 상황에 이력 테이블에 어떻게 반영해야할지 질문 드리고 싶습니다. - 추가: 신규 기능으로 인해 새로운 칼럼 추가 - 삭제: 기획 변경으로 오랜 기간 미사용 칼럼으로 낭비되어 삭제로 결정된 경우 등
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요! 강의를 다 보고 이 프로젝트를 제 손으로 다시 작성해보려고 합니다. 코드를 눈으로 쭉 봤지만 SQL, 데이터베이스 구조 등은 정확히 들여다보지는 않았기 때문에... 무엇보다도 코드를 느끼려면 다시 작성해보고 테스트도 보고 그러는게 좋을 것 같아서요. 완전 같게 작성하기 보다는 강의에서 해주셨던 부분들 개선해보거나 바꿔보거나 하려고요 저는 python 개발자이기 때문에 Spring 대신 FastAPI, JPA 대신 sqlalchemy 를 사용하려 합니다. 작성하려고 보니 어떤 순서로 작성하는 것이 좋을까 질문 드려도 되나 싶어서 질문 올려봅니다. 일단 제 생각에는 v1/products 부터 시작 하려고 하는데 우선은 프로젝트 구조부터 간단히 잡고 그 다음은 도메인 클래스, 엔티티, productService, controller 순서로 구현/테스트 코드 작성 v1/products 가 완성되면 서버 실행해서 동작 확인 그 다음은 뭐 v1/products/{productId} 이런 순서로 작성해보려고 하는데요 재민님은 혹시 이 프로젝트 만들때 어떤 순서로 구현하셨는지? 혹시 테스트부터 시작 하시는지? 처음 시작할 때 의 팁 있으시면 공유 부탁 드립니다 좋은 강의 감사합니다!
미해결
옆집 개발자와 같이 진짜 이해하며 만들어보는 첫 Spring Boot 프로젝트
강의에선 되게 단순하게 큰 틀 위주로 알려주시는 것 같아서 개인적으로 더 자세한 의미나 추가적인 개념이 궁금할 때 검색해보는 편인데, DI라는 것이 클래스 간의 결합도를 낮추고 객체의 유연성을 높이기 위해 빈 객체를 만들어 주입하는 것을 의미한다고 정리했습니다. 이게 맞게 정리한건지 궁금합니다. 또 추상 클래스와 인터페이스 간의 차이점은 찾아봐도 이해가 어렵길래 선생님의 친절한 설명이 필요할 것 같아서 추가로 여쭤봅니다!
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요 영한님. 강의 정말 잘 듣고 있습니다. common_code_detail 은 pk로 natural key(group_code, code) 를 사용하는 것이 정형화되어 있다고 하신 부분을 이해했습니다. 서비스를 운영하다 보면 code의 값을 수정할 경우가 생길 가능성이 있을 거 같은데요. 예를 들면, 다음과 같은 요구사항이 있을 거 같습니다. group_code가 ORDER_STATUS 인 code에 대한 변경 요청. SHIPPING 을 두가지 상태로 확장(SHIPPING_START, SHIPPING_COMPLETED) 변경 전의 SHIPPING은 SHIPPING_COMPLETED로 취급한다. 설계 1편의 "pk는 immutable해야한다" 라는 3번째 규칙이 있었는데요. 공통 코드 테이블의 경우에는 3번째 규칙을 유연하게 적용해야하나? 하는 생각이 들었습니다. 공통 테이블은 natural key를 사용하니 어느정도 허용을 한다고 보면 될까요? 아니면, 기존 키는 삭제하지 않은 채로 그대로 두고 새로 만들어서 규칙을 지키는 방향으로 하시는지 궁금하네요. 실무에서 이런 케이스들은 어떻게 다루시는지 궁금합니다. 감사합니다.
