묻고 답해요
164만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결제미니의 개발실무 - 커머스 백엔드 기본편
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
제미니님 안녕하세요. 강의를 통해 각 개념 간의 응집성을 높이고, 불필요한 의존성을 줄여 격벽을 세우는 설계를 깊이 있게 연습하고 있습니다.강의에서 배운 원칙을 적용하여 '리뷰'나 '찜' 같은 개념들이 '상품' 개념을 단방향으로 참조하도록 구조를 잡고 있습니다. 하지만 실제 상품 목록 조회 기능을 구현하다 보니, 설계의 일관성을 유지하기 어려운 상황을 마주하게 되어 조언을 구하고자 합니다.개념 간 의존성의 역전: 목록 화면에서 '리뷰 수'나 '찜 수'를 함께 보여주거나, 이를 기준으로 상품을 정렬해야 하는 요구사항이 생겼습니다. 이 경우 상품 개념이 본래 몰라야 할 하위 개념(리뷰, 찜 등)의 상태를 알아야만 하는 상황이 발생합니다.API 구성의 어려움: 상세 페이지는 API를 잘게 나누어 클라이언트에서 합성함으로써 개념 간의 독립성을 지킬 수 있지만, 목록의 경우 수십 개의 상품에 대해 매번 각각의 리뷰 수 API를 호출하여 클라이언트가 매핑하는 방식은 어딘가 어색하고 성능과 구현 효율 면에서 의문이 듭니다.결국 조회를 위해 상품이 다시 리뷰나 찜을 알게 되면, 처음 설계한 개념 간의 단방향 참조 구조가 깨지거나 서로를 참조하는 순환 참조가 발생할 것 같아 우려됩니다.이처럼 개념 간의 격벽을 유지하려는 설계 원칙과, 여러 개념의 데이터가 한꺼번에 필요한 조회 요구사항이 충돌할 때 어떤 식으로 접근하는 것이 현명할까요? 원칙을 고수하며 우회할 방법이 있을지, 혹은 이런 조회 상황에서는 설계적 타협이 필요한 것인지 견해를 듣고 싶습니다.
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
DELETE -> SELECT 질문 드립니다.
안녕하세요 단건데이터(ex: 로그) 처리의 경우에는 크게 고민하지 않고 MERGE를 사용하여 처리하고 있습니다. 하지만 10~20건 이상의 데이터셋이 들어오는 경우에는 어떤 방식으로 처리하는 것이 더 적절한지 고민이 되어 질문드립니다. 데이터 DELETE -> INSERT 2번의 쿼리 수행(또는 BEGIN으로 1번에 수행) 데이터 STATE (I, U, D 등)를 활용하는 방식 화면에서 데이터에 INSERT / UPDATE / DELETE 상태값을 기반으로 서버에서 DELETE 1회, INSERT 1회, UPDATE N회를 수행실무에서는 작업 공수 문제로 1번 방식(DELETE -> INSERT)을 선택하는 경우가 많았습니다. 다만 이 방법을 사용하면서 DELETE로 인해 발생하는 DB 블록 낭비기존 데이터의 CREATE_DATE가 유지되지 않아 UPDATE_DATE와 의미 차이가 사라지는 문제데이터 관리, 유지보수, 성능 측면에서 어떤 방식이 더 바람직한 선택인지 궁금합니다.
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
상속 관계 모델링의 적용 기준 질문
안녕하세요 영한님!"8. 상속 관계 설계" 강의에서, 상품 테이블을 예시로 들어, 슈퍼타입-서브타입 모델링을 설명해주셨는데요! 만약에 서브타입이 다른 테이블과 관계를 맺게 된다면, 이 케이스에도 슈퍼타입-서브타입 모델링을 적용하는게 괜찮을지 궁금하여 질문을 드립니다! 예를 들어, 신고 내역을 저장하는 테이블을 모델링하는 상황에서, 회원 신고/게시글 신고/댓글 신고/그룹 신고 이렇게 나뉜다면 슈퍼타입-서브타입 상속 전략을 사용해도 괜찮은지 궁금합니다.
-
미해결김영한의 실전 데이터베이스 - 기본편
ON을 명시하지 않았을 경우 질문드립니다.
문제 3번을 풀다가select * from orders o inner join users as u on o.user_id=u.user_id inner join products as p;이러한 쿼리를 작성하게 되었습니다.실행 결과로 오류 없이 테이블이 나왔습니다.그래서 이걸 바탕으로 문제를 풀었다가 결과가 답안과 달라 문제점을 찾다가 on o.product_id=p.product_id 을 작성하지 않은 잘못된 쿼리라는 것 알았습니다.여기서 질문이 있습니다.inner join이 공통된 부분을 join하는 것이라고 하셨는데,orders와 users를 조인 후 products를 조인 할 때 제가 작성한 쿼리의 경우 연결 조건인 ON을 지정하지 않았는데 어떻게 join하여 결과 테이블이 나올 수 있는 것인가요?
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
TTL 캐싱에 대한 질문
안녕하세요! 강의를 듣다보니 TTL 캐싱을 사용할 때에도 오류가능성이 존재하지 않나 싶어 질문 남깁니다. TTL을 1분이라 가정했을 때 TTL이 지나기 전에 DB의 값이 바뀌고, 그 이후 TTL이 지나기 전에 캐싱된 값을 사용하게 된다면 DB에 있는 값과 캐싱되어있는 값에는 차이가 존재하지 않나요? 이에 대해선 어떻게 구현되어있는지 궁금합니다
-
미해결김영한의 실전 데이터베이스 - 기본편
강의 2:53 union을썼는데도 션이 중복
[질문 내용]강의 UNION 정렬 2:53초부근에UNION을 사용해서 결과를 불러오는데 션이 중복으로 표출됩니다. UNION은 중복을 제거하지 않나요?created_at 에 데이터가 다르기때문에 모두 표출된건지 궁금합니다!
-
미해결실전! 데이터베이스 완전정복 [설계편]
커버링 인덱스에 대해서 질문드립니다.
안녕하세요. 강의 정말 잘 듣고 있습니다. 강의를 듣다가 커버링 인덱스(Covering Index) 관련해서 궁금한 점이 생겨 질문드립니다.커버링 인덱스는 SELECT 문에서 조회하는 컬럼들이 모두 인덱스에 포함되어 있을 때, 원본 테이블을 조회하지 않고 인덱스만으로 쿼리를 처리할 수 있는 방식이라고 이해했습니다.그렇다면,SELECT에 포함된 컬럼들이 각각 단일 인덱스로 존재하는 경우에도 커버링 인덱스로 처리될 수 있는지 궁금합니다.아니면 반드시 하나의 복합 인덱스(composite index) 로 묶여 있어야 커버링 인덱스로 동작하는 것인지 알고 싶습니다.예를 들어,id는 Primary Key라서 자동으로 인덱스가 생성되어 있고name 컬럼에 대해서도 검색을 위해 인덱스를 추가하려고 할 때다음 두 방식 중 어떤 것이 더 적절한지 궁금합니다.name 컬럼에 단일 인덱스를 생성(id, name) 형태의 복합 인덱스를 생성이 경우 커버링 인덱스 관점에서 어떤 방식이 더 올바른 설계인지 설명해주시면 감사하겠습니다 :>
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
공통 코드 사용시 컬럼 타입 설정
안녕하세요.공통 코드를 가져와 사용하는 테이블 스키마를 정의할 때 궁금한 점이 있습니다.영상 11분 05초를 보면 주문 테이블과 결제 테이블을 정의합니다.이때 , order_status, payment_method, payment_status와 같은 컬럼을 varchar로 정의하셨습니다.type-safe하게 정의한다면, 해당 컬럼들을 enum으로 정의하거나 공통 코드 상세 테이블과 relation을 설정해서 외래키를 사용할 거 같은데,이와 같은 방식은 유지보수를 더 어렵게 만드는 구조인걸까요?type-safe하게 만들고 싶다면 애플리케이션 레벨(서버측 코드)에서 정의해주는게 좋은 방법인걸까요?----------------------참고로 저는 nodejs 기반의 백엔드 개발자이며,김영한님의 강의는 네트워크+DB만 수강하고 있습니다.(java+springboot+jpa 등의 지식과 경험은 전무합니다.)
-
해결됨제미니의 개발실무 - 커머스 백엔드 기본편
프로덕트와 프로덕트카테고리 사이의 삭제 정책
안녕하세요, 선생님!좋은 강의 제공해주셔서 감사합니다. 덕분에 단순히 구현에만 집중하기보다, 설계와 개념에 대해 더 고민하면서 코드를 작성하게 되었습니다.섹션 2의 ‘개념 느끼기’ 부분에서 Product가 Product Category보다 더 상위의 개념이라고 말씀해주셨던 것으로 기억합니다. 저도 그렇게 이해했습니다.그런데 코드 구현 파트에서 Product와 Product Category 사이의 삭제 정책을 두 가지 예시로 설명해주셨는데, 그 부분에서 한 가지 궁금증이 생겼습니다.제 생각에는 개념적으로 Product가 더 상위 개념이라면, Product가 삭제될 때 Product Category도 함께 삭제되는 정책이 조금 더 자연스러운 흐름처럼 느껴졌습니다.이 부분에 대해 제가 개념을 잘못 이해한 것인지, 아니면 실무적인 관점에서 추가로 고려해야 할 부분이 있는지 궁금합니다.혹시 제가 놓치고 있는 관점이 있다면 조언 부탁드립니다!
-
미해결graphRAG - Neo4J로 구현하는 지식 그래프 기반 RAG 시스템 (feat. LangChain)
강의 github 어디에 있나요?
안녕하세요. 강의 코드가 담겨있는 github 을 찾고자 합니다. 알려주시면 감사하겠습니다.
-
미해결비전공자도 이해할 수 있는 DB 설계 입문/실전
규칙 1에 대해서
규칙 1에 대해서 생각이 나서 드는 의문인데요누가 좋아요를 눌렀는지 그 컬럼이 지금 여러개의 원소가 들어가있으니까 그 컬럼만 빼서 다른 테이블에 다 만들어야하는거아닌가요? 어짜피 게시글 id는 1,2로 딱 하나하나씩 들어가 있으니까...왜 이 중복을 밑으로 나열하는지 모르겠어여
-
미해결김영한의 실전 데이터베이스 - 기본편
where 대신 having을 써도 되나요?
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]select * from products p1where price >= (select avg(p2.price) from products p2 where p2.category = p1.category);대신에select name,price from products p1where price >= (select avg(p2.price) from products p2group by categoryhaving p1.category=p2.category);으로 써도 문제 없나요?
-
해결됨10,000++억의 데이터를 다루는 카카오 면접관의 MySQL
21강에서 이해하기 어려운 부분들이 있습니다!
안녕하세요 Hong님! 21강 '데이터 모델링 : 수많은 yes or no 속성 디자인 정의와 논리 모델' 을 듣는 와중에 이해하기 어려운 부분들이 있어 질문드리고 싶습니다!Boolean 속성이 늘어날 때의 문제들21강에서 yes or no 속성이 늘어나는 것이 근본적인 아키텍처 관점에서의 문제점, ALTER 로 스키마를 변경하는 작업이 필요하다는 것, Boolean 타입으로 표현할 수 있는 정보의 한계, I/O 비용의 증가를 만들어낸다고 설명해주셨는데요!근본적인 아키텍처에 어떤 문제점이 생기는지, 잘 모르겠습니다.ALTER로 스키마를 변경하는 것으로 문제가 야기되는 부분이 정확히 어떤 부분이라고 생각하시는지 궁금합니다. 이미 많은 레코드가 있는 테이블의 스키마를 변경함으로써 생겨나는 I/O 부하를 생각하시는 걸까요?I/O 비용의 증가가 발생한다는 부분은 2번에서의 비용 증가를 말씀해주신 걸까요? SELECT 비용 증가라면 사실 저장해야 하는 정보가 늘어나면서 자연스러운게 아닌가 싶은데 어떤 관점에서의 문제를 짚어주신 건지 궁금합니다.논리 모델과 물리 모델논리 모델과 물리 모델을 분리시키는 것이 기본적인 데이터베이스의 설계 원칙이라는 설명을 해주셨는데요! 그 뒤의 설명이 물리 모델 설계 방법들이고 해당 원칙을 어떻게 적용해야 할지에 대한 가이드는 없어서 해당 원칙을 언급해주시고 넘어가셨던 이유가 궁금합니다. 논리 모델과 물리 모델을 분리시키는 건 One Table per Anchor, Side Table, EAV 세 가지 기법이 있다고 설명해주시려는 의도였던 걸까요? 이어지는 설명에서 혼동이 와서 설명을 어떻게 정리하여 이해해야 하는지 파악이 어렵습니다 ㅠ 항상 질문에 좋은 답변을 주시기 위해 노력하시는 Hong님 감사합니다 :)
-
미해결김영한의 실전 데이터베이스 - 기본편
주문 내역에 대한 고객 데이터
=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/[질문 내용] 강사님께서 주문 내역에 대한 데이터면 이제 주문(orders) 테이블을 기준으로 하는것이 좋겠다 정도는 이제 느낌이 올거에요 라고 하셨는데 전혀 느낌이 오지않아서 흑흑... 제가 생각하기엔 ~에 대한 [고객 데이터]이니까 users가 주인공이여서 그걸 기준으로 잡는다고 생각했는데요~ 에 대한일때 ~물결표시있는 부분을 기준으로 잡아야하나요?
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
history_creted_at과 valid_from
안녕하세요,강의에서 valid_from과 valid_to를 사용하는 경우 history_created_at이 빠져있는데이게 개념적으로는 같아서 제거가 된 게 맞는지 궁금합니다!
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
함수 기반 인덱스 (Function-Based Index)
안녕하세요 영한님!!항상 좋은 강의 만들어주셔서 감사합니다!함수 기반 인덱스 생성에서 질문이 있어서 글을 남깁니다! 강의를 들으면서 함수 기반 인덱스를 생성하면 가상 컬럼이 없고, 인덱스만 만들어진다고 이해했습니다.그래서 product_json 테이블에 만들어진 가상 컬럼과 idx_v_storage 인덱스를 drop한 다음 각각 두가지 방식으로 테스트를 해보았는데요 CREATE INDEX idx_func_storage ON product_json (( CAST(attributes->'$.storage' AS UNSIGNED)));EXPLAIN SELECT * FROM product_json WHERE attributes->'$.storage' = 256; 이렇게 할 경우엔idx_func_storage 인덱스를 잘 타는 걸로 나왔지만,CREATE INDEX idx_func_storage ON product_json ((JSON_VALUE(attributes, '$.storage' RETURNING UNSIGNED)));EXPLAIN SELECT * FROM product_json WHERE attributes->'$.storage' = 256; 이 경우에는 FULL TABLE SCAN 이 되고, 인덱스도 NULL로 나왔습니다. 두 방식 모두 각각 idx_func_storage 인덱스는 잘 생성이 되었는데도 JSON_VALUE() 방식에서는 인덱스를 사용하지않았습니다그래서 AI에게 물어보니MySQL functional index는 WHERE절의 표현식이 인덱스 정의와 문자 수준으로 동일해야 한다.이유는 가상 컬럼 방식에서는 MySQL이 내부적으로 expression rewrite 과 virtual column substitution를 더 적극 수행하지만 functional index는 표현식 exact match 요구가 훨씬 엄격하기 때문이다.CREATE INDEX idx_func_storage ON product_json ((CAST(attributes->'$.storage' AS UNSIGNED))); 이렇게 인덱스를 생성했다면EXPLAIN SELECT *FROM product_json WHERE CAST(attributes->'$.storage' AS UNSIGNED) = 256; 이렇게 WHERE 절을 작성해야 하고CREATE INDEX idx_func_storage ON product_json ((JSON_VALUE(attributes, '$.storage' RETURNING UNSIGNED)));이렇게 인덱스를 생성했다면EXPLAIN SELECT * FROM product_json WHERE JSON_VALUE(attributes, '$.storage' RETURNING UNSIGNED) = 256이렇게 WHERE 절을 작성해야 한다고 답변해주었는데요!이렇게 각각 테스트 해보면, 인덱스를 잘 타는 것으로 나옵니다..!또한 CAST()로 인덱스를 생성한 경우 WHERE절에 JSON_VALUE()를 사용한 쿼리는 Index를 사용하지않고, FULL TABLE SCAN을 했으며,JSON_VALUE()로 인덱스를 생성한 경우 WHERE절에 JSON_VALUE()를 사용했을 경우에만 Index를 사용했습니다.제 테스트에서는 CAST() 기반 인덱스는WHERE절 축약 표현식에서도 인덱스를 사용하였고, WHERE절 JSON_VALUE()는 인덱스를 사용하지 않았습니다.JSON_VALUE() 기반 인덱스에서는 WHERE절에 동일한 JSON_VALUE() 표현식을 사용했을 경우에만 인덱스를 사용하는 것으로 보였습니다이게 맞는 걸까요? 아니면 제가 잘못 확인한 걸까요?, 또한 functional index 매칭 규칙 실제 범위가 어디까지 인지? AI가 답변해준 동작 방식이 맞는 건지도 여쭤보고 싶습니다! (제 MySQL버전이 8.0.41이네요,,)영상을 다시 잘 보니, 2:18 분에 idx_func_storage 인덱스를 CAST() 구문으로 생성하시고, 2:25분에 확인하실 때, EXPLAIN의 결과에서 idx_v_storage인덱스가 나오긴 합니다!
-
미해결비전공자도 이해할 수 있는 DB 설계 입문/실전
강사님도 실제로 구글 시트에 이런식으로 적으면서하는걸까요?!
뭔가 머리속으로만 하기엔 너무 헷갈려서 적으면서하려고하는데 강사님도 실제로 저렇게 스프레드시트에 적어가면서 하는지 궁금합니다 ! 그리고 완성된 스키마들을 스프레드시트같은곳에 보통 타입이랑 컬럼명 정리해서 적어놓는편이실까요?!
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
comment 채번을 사용해야 하는 이유에 대한 설명이 필요합니다.
안녕하세요. 식별 vs 비셕별에 대한 db 설계 관련 내용 중에 영한님께서 일대다의 경우인 board 테이블(one)과 comment(many)에서 board 테이블의 id가 식별관계로 사용되는 경우 comment의 id는 채번을 따서 사용해야하고 시퀀스나 auto increment를 사용할 수 없다고 하셨는데 그 이유가 궁금합니다. 어쨋든 board 테이블의 id값은 row마다 존재하기에 각 comment row의 데이터가 어떤 board에 속하는지 그리고 순서도 asc 순으로 보장된다고 생각하는데요..꼭 채번을 사용해서 만들어야한다고 설명해주신 이유가 무엇인지 궁금합니다.더구나 max+1 같은 경우 comment의 id값이 중복될 여지도 있다고 생각하는데요..설명해주시면 감사하겠습니다.
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
추후 강의 질문있습니다
안녕하세요! 늦었지만 새해복 많이받으세요! 신입때 영한님 강의 봤었는데 벌써 6년차에 접어들고 있습니다..!다름이 아니라 최근 실무에서 레거시 코드를 개선하면서 고민을 많이 하고 있는데요주변에 시니어분들이 있으나 아키텍처에 대해서 크게 고민하고 있지 않아 제가 고민 후 적용해보고 있습니다.예를 들어 레이어드 아키텍처로 구현되어 있는 프로젝트가 있으나 규모가 커지면서 점점 유지보수가 힘든 지경까지 왔는데요(메서드 하나에 1천 줄... 이상)이런 상황에서 DDD 아키텍처를 이용해서 코드를 작성해보고 있습니다. 하지만 아무래도 혼자 공부하고 혼자 해보다보니 이게 맞는건지 제대로 하는건지 궁금한 부분이 꽤나 많습니다.그래서 질문은 향후 아키텍처에 관련된 강의 계획이 있으신지 너무 궁금합니다...!!클린아키텍처, 핵사고널, DDD 다양한 방법과 적용된 프로젝트가 많은데 이런 강의도 하실 예정이신지.. 없으시다면 꼭 해주셨으면 합니다!! 아무튼 강의 계속 보면서 많은 도움 받고 있습니다 감사합니다!!다시 한번 새해 복 많이 받으세요!
-
해결됨제미니의 개발실무 - 커머스 백엔드 레거시와 AI 활용편
소스코드 보안
안녕하세요 재미니님 유튜브로 접하게 되어 인프런 강의까지 듣게된 백엔드 개발자(5년) 입니다.현재 팀의 레거시 시스템을 고도화하는 레거시 시스템을 개편하는데 주력하고 있는 업무를 맡고 있습니다. 저희 회사는 규모가 적지 않고, 팀내에서 담당하는 시스템도 많은데 제 기준으로는 꽤나 보수적인 조직이라 ai 활용하는데 제약이 많은 편이라고 생각합니다. 금융권처럼 로컬 PC에서 외부망을 아예 차단하고 있지는 않지만, chat gpt, gemini 등 각종 llm을 제공하는 웹사이트는 차단이 되어있고 사내 자체 llm 만 사용할수 있는 환경입니다. 운이 좋게도(??) junie 는 아직 차단되어 있지 않아 많이 활용하고 있는데, 신규 구축이 아닌 기존 레거시 시스템을 분석하여 컨버전을 하는 과정에서 사용하기에 보안적으로 이슈가 될 부분이 있을까 싶어서 걱정이 많이 되는데, ai를 활용하면 생산성이 넘사벽으로 높아지는 환경에서 보수적으로는 보안 이슈를 걱정하는 팀원들이 있을경우, 재미니님은 어떤식으로 팀원들을 설득하실지, 보안 이슈가 없도록 방안은 어떻게 마련하고 계신지 궁금합니다.추가로 극단적인 예시긴 하지만, 비지니스 로직이 프로시저에 녹아져 있는경우, db 에 의존적으로 운영되고 있는 시스템(ex. 트리거, 서버 크론잡 스케줄링 등) 의 경우 ai를 활용하여 레거시를 최대한 개선하고 싶다면 어떤 전략을 활용할 수 있을지도 의견 주시면 감사하겠습니다.소중한 강의 제공해주셔서 감사합니다.