안녕하세요! 늦었지만 새해복 많이받으세요! 신입때 영한님 강의 봤었는데 벌써 6년차에 접어들고 있습니다..! 다름이 아니라 최근 실무에서 레거시 코드를 개선하면서 고민을 많이 하고 있는데요 주변에 시니어분들이 있으나 아키텍처에 대해서 크게 고민하고 있지 않아 제가 고민 후 적용해보고 있습니다. 예를 들어 레이어드 아키텍처로 구현되어 있는 프로젝트가 있으나 규모가 커지면서 점점 유지보수가 힘든 지경까지 왔는데요 (메서드 하나에 1천 줄... 이상) 이런 상황에서 DDD 아키텍처를 이용해서 코드를 작성해보고 있습니다. 하지만 아무래도 혼자 공부하고 혼자 해보다보니 이게 맞는건지 제대로 하는건지 궁금한 부분이 꽤나 많습니다. 그래서 질문은 향후 아키텍처에 관련된 강의 계획이 있으신지 너무 궁금합니다...!! 클린아키텍처, 핵사고널, DDD 다양한 방법과 적용된 프로젝트가 많은데 이런 강의도 하실 예정이신지.. 없으시다면 꼭 해주셨으면 합니다!! 아무튼 강의 계속 보면서 많은 도움 받고 있습니다 감사합니다!! 다시 한번 새해 복 많이 받으세요!
안녕하세요! 현재 사내 시스템의 기본 차트 기능이 요구사항을 구현하기엔 너무 복잡하고 한계가 있어서, 차라리 API로 데이터를 직접 뽑아 커스텀 대시보드 웹사이트를 자체 구축하여 운영하고 있습니다. 이 과정에서 데이터 구조 및 아키텍처 설계에 대한 고민이 생겨 선배님들의 조언을 구하고자 합니다. [현재 상황 및 아키텍처] 요구사항: N개의 프로젝트마다 각기 다른 40여 개의 통계 차트를 제공해야 합니다. 데이터 수집 (파멸의 약 30만 번 API 호출...): 외부 API를 연동해 통계 데이터를 수집합니다. 전체 프로젝트 기준 매일 새벽 3시에 약 프로젝트 갯수 * 3000 번의 API 호출이 발생합니다. 배치 및 동시성 처리: Spring WebFlux를 활용해 10개 단위로 청크(Chunk)를 나누어 병렬로 배치 처리를 하고 있습니다. 데이터 적재: 프로젝트의 일별 베이스라인(Baseline)을 유지하기 위해 원본(Raw) 데이터는 MongoDB에 저장하고 있습니다. 실시간 동기화: 사용자가 화면에서 차트 '새로고침'을 누르면, 해당 시점에 즉시 API를 다시 쏘아서 데이터를 업데이트해 줍니다. 현재의 서빙 방식: 일별 통계 결과는 현재 Redis에 담아두고 클라이언트에 제공하고 있습니다. 🤔 [고민되는 지점] 프로젝트당 40개의 차트를 그리는데, 각 차트(통계)마다 필요한 Raw Data의 종류와 개수가 천차만별입니다. 처음에는 통계 결과용 RDB 테이블을 만들까 했지만, Project_ID 와 구조가 제각각인 Raw Data 들을 깔끔하게 담아내기가 까다로웠습니다. 그래서 현재는 캐시 툴에 크게 의존하고 있는데, 앞으로 차트 종류가 더 늘어나고 시스템이 확장될 것을 고려하여 좀 더 포괄적인 대응을 위해 "차트에 대한 메타데이터 테이블"을 별도로 설계하여 매핑하는 방식 으로 구조를 개편할까 고민 중입니다. 💡 [질문 드립니다] 이처럼 요구되는 Raw Data의 형태와 수량이 각기 다른 수십 개의 차트를 서빙할 때, 메타데이터 테이블을 도입하여 관리하는 방식에 대해 어떻게 생각하시나요? 캐시에만 의존하는 것보다 나은 선택일까요? 혹시 비슷한 형태의 대규모 API 연동 기반 통계/대시보드 시스템을 구축에 있어, 추천할 만한 데이터 모델링이나 아키텍처 개선 방향이 있을지 궁금합니다.... 개인적인 고민 질문드려 죄송하고 잘 모르는 후배가 선배님께 여쭤봅니다. 영한님이 아니시더라도 해당 고민을 들어주시고 의견 주시는 선배님들께 감사합니다 !
학습 관련 질문을 남겨 주세요, 상세하게 해 주시면 더 좋습니다 먼저 유사한 질문이 있는지 검색을 해 주시면 궁금하신 부분을 빠르게 아실 수도 있습니다 강의 내용 중에 잘못된 부분이나 보완이 필요한 부분이 있으면 말씀 해 주세요 저자께서 유튜브에 소개한 강의를 따라 인프런 결제까지 했는데요, 교재로 책을 보내주신다고 하셨는데 어디서 신청하는건가요
영한님, 안녕하세요. 또 좋은 강의로 다시 만나뵙게 되었네요. Spring, Java 로 강의를 듣다가 순수 DB 만 설명을 듣다보니 다소 적응이 되지 않는 감이 있는데요 ㅎ 카테고리의 비정형 속성을 관리하기 위해 Json 설계하는 부분을 설명해주셨는데 이런 경우, Java 에서는 보통 어떤 식으로 객체와 맵핑을 하는지요? 각 카테고리별로 도메인 객체를 분리해서 각각 연동을 하는 식인지, 아니면 단순히 Map 으로 활용하는지 궁금합니다. 저장할 때도 객체를 그대로 저장하면 되기 때문에 편리하다고 하셨는데 각 카테고리별로 별도 객체가 있고 이를 개별 저장하는 형태를 말씀하시는 것인지 질문드립니다.
시력 이슈로 Deprecated 안녕하세요. 영한님! 7장1, 2, 3page 오타 제보 합니다! 아래 쿼리를 실행해서 데이터를 생성하고, -- # 7. 통계 테이블 설계 -- ## 통계 데이터와 성능 문제 -- ### 원본 데이터 준비 DROP TABLE IF EXISTS orders; CREATE TABLE orders ( order_id BIGINT AUTO_INCREMENT PRIMARY KEY, customer_id BIGINT NOT NULL, total_amount INT NOT NULL, order_status VARCHAR(20) NOT NULL, order_date DATETIME NOT NULL ); -- 데이터 입력 (예시를 위해 소량만 입력하지만, 실제로는 수백만 건이라고 가정한다) INSERT INTO orders (customer_id, total_amount, order_status, order_date) VALUES (1, 10000, 'COMPLETED', '2026-01-01 10:00:00'), (2, 25000, 'COMPLETED', '2026-01-01 14:30:00'), (3, 15000, 'COMPLETED', '2026-01-01 18:20:00'), (4, 50000, 'COMPLETED', '2026-01-02 09:15:00'), (5, 30000, 'COMPLETED', '2026-01-02 11:00:00'), (6, 12000, 'CANCELLED', '2026-01-02 15:45:00'), (7, 45000, 'COMPLETED', '2026-01-03 10:00:00'); 아래 통계 쿼리를 실행하면, -- ### 원본 테이블 직접 집계의 유혹 SELECT DATE(order_date) as stat_date, COUNT(*) as order_count, SUM(total_amount) as total_sales FROM orders WHERE order_status = 'COMPLETED' GROUP BY DATE(order_date) ORDER BY stat_date; 아래와 같은 결과가 나온다고 적혀있는데요. 2026-01-02 데이터가 3개라서 실제로는 아래와 같은 결과가 나와야할것 같아요! 감사합니다.
Node.js에서는 req와 res 사이에 인증 처리와 같은 로직을 넣기 위해 미들웨어를 직접 만들어야 할 것 입니다. Express에서의 미들웨어 구현과 동작 방식은 최선의 방식인지 궁금합니다! 즉 Express가 아닌 Node.js로 미들웨어를 직접 구현했을때 Express 방식보다 더 나은 설계가 될 수 있는지 궁금합니다. 또 Nest.js (nest 아니더라도 다른 프레임워크) 에서는 Express가 미들웨어를 구현하고 동작시키는 방식을 그대로 따르고 있는지 아니면 설계 상의 차이를 두었는지도 궁금합니다. 감사합니다!
안녕하세요~! 영한님 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); 위와 같이 명시적으로 인덱스를 생성한 이유가 있을까요? 감사합니다.
안녕하세요, 이번 강의를 듣고 아주 간단한 질문을 남깁니다. Soft Delete + 이력 테이블 설계가 필요한 이유가 외래 키 제약 조건으로 인한 삭제 어려움 때문이라 이해했습니다. 일부 실무자들은 이러한 삭제 불편함으로 인해 물리적으로 외래 키 제약조건을 DB에 걸지 않는다는 말을 들은 적이 있는 것 같은데요, 만약 그렇게 제약이 없다면 단순히 Hard Delete + 이력 테이블 구조로 고정해도 괜찮은 걸까요?
윈도우10 환경에서 테스트 중입니다. 파일을 다운로드 받아서 PowerShell에서 패키지를 설치하고 명령어를 실행했지만, rune Server 관련 에러가 나오는데, 무엇이 문제인 걸까요? PS C:\dev\study\multi-paradigm-programming-main> pnpm -F lecture dev > lecture@1.0.0 dev C:\dev\study\multi-paradigm-programming-main\apps\lecture > pnpm rune dev ▲ Rune Server v1.0.24 ⨯ Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:' at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:187:11) at defaultLoad (node:internal/modules/esm/load:82:3) at ModuleLoader.load (node:internal/modules/esm/loader:815:12) at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:594:31) at #createModuleJob (node:internal/modules/esm/loader:624:36) at #getJobFromResolveResult (node:internal/modules/esm/loader:343:34) at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:311:41) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:664:25) { code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME' }
안녕하세요. 주문, 상품과 같은 비즈니스에 중요한 데이터를 전체 행 스냅샷 이력 테이블 로 관리 하는 상황일 때, 대상 테이블(주문, 상품 등)의 칼럼이 추가/삭제되는 상황에 이력 테이블에 어떻게 반영해야할지 질문 드리고 싶습니다. - 추가: 신규 기능으로 인해 새로운 칼럼 추가 - 삭제: 기획 변경으로 오랜 기간 미사용 칼럼으로 낭비되어 삭제로 결정된 경우 등
안녕하세요 영한님. 강의 정말 잘 듣고 있습니다. 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를 사용하니 어느정도 허용을 한다고 보면 될까요? 아니면, 기존 키는 삭제하지 않은 채로 그대로 두고 새로 만들어서 규칙을 지키는 방향으로 하시는지 궁금하네요. 실무에서 이런 케이스들은 어떻게 다루시는지 궁금합니다. 감사합니다.
이번 강의의 수업자료 pdf 보니, 제목 클릭 시 링크위치가 각 챕터가 아닌, 마지막 페이지 정리 내 제목들로 이동합니다. 9. 논리적 모델링 - 실습.pdf 파일 제외하곤 모든 파일의 목차들이 다 마지막 정리로 이동하더라고요. 그동안 영한님 강의들 자료에는 각 챕터로 쉽게 이동 하기 좋았거든요. 이부분이 개선 가능할까요? 이 상태여도 학습은 가능한데, 건의드립니다. 감사합니다.
안녕하세요 강의를 듣다가 전반적인 학습 방향성에 고민이 있어서 질문드립니다. 풀스택 개발자가 목표입니다 취업전 총 3번의 프로젝트를 진행 해보려고 합니다. (실서비스 프로젝트 1개 / 실서비스 프로젝트를 위한 연습 프로젝트 2개 ) 첫번째 프로젝트는 프레임워크를 사용하기 전 전반적인 기초체력을 기르기 위해서 fe - 바닐라 js로 spa방식 (csr) be express로 api구성 + 로우쿼리로 db 연동 두번째 프로젝트는 추후 next, nest 등 프레임워크 학습후 진행 해보려고 합니다. fe - next be - nest + prisma 등 인프라 - aws 운영 - • Sentry - 에러 추적 • CloudWatch - AWS 로그/모니터링 • Datadog - 통합 모니터링 • Winston / Pino - 로그 라이브러리 실서비스 프로젝트는 fe는 next / be는 nest를 사용해 개발할 예정이고 실제 사용자가 있는 b2b 쇼핑몰이라 배포/인프라(aws), 운영(모니터링/로깅) 까지 a~z까지 모두 경험 해볼 프로젝트입니다. 현재 첫번째 프로젝트를 위해 강의자분께서 제공한 express part1 수강은 끝난 상태입니다 프론트 및 db관련 강의들은 타 강의자분의 강의를 통해 준비를 마친 상태입니다. 혹시 part2 까지 수강후 전반적인 기능구현 실습들을 진행 해보는 타강의를 수강하고 프로젝트를 시작해야할까요 아님 프로젝트 경험 먼저 해본뒤 part2 강의수강, 기능구현 실습강의를 수강 하는게 더 효율적일까요.. 프로젝트 완성도를 위해 강의만 쭉 들으니 어디까지 공부를 해야하는것인가에 대한 기준도 안 잡히고 강의만 듣고 직접 강의 코드를 쳐보는것만으로는 구현력이 안 길러지는 것 같습니다.. 또한 강의 수강 기간이 길어지다보니 앞서 들었던 강의 내용들이 잘 기억이 안 나는 부분들에 대한 걱정 또한 있습니다. 반면에 실무적인 코드 경험 (강의를 통한 간접경험) 없이 프로젝트를 진행하면 실무에서 쓰지 않는 코드 / 리펙토링 하기 어려운 코드 / 보안에 대한 인식 부재로 인한 위험성 등 여러가지 잘못된 코드를 작성하고 학습하게될까봐 두려움이 있습니다. 어느 시점에 구현력을 기르기 위해서 프로젝트를 진행 해봐야하는지 도무지 감이 안 잡혀서 질문 드립니다.. 강의 외적인 성격이 짙은 질문인데 염치 불구하고 질문드립니다..
안녕하세요 영한님! 기초부터 설계까지 영한님의 강의 덕분에 실무에서 테이블을 설계할 때 큰 자신감을 얻고 있습니다. 늘 감사드립니다. 강의를 듣고 운영 중인 서비스의 ERD를 검토해보니 과거 설계된 테이블들이 비식별 관계가 아닌 식별 관계로 되어 있는 등 개선이 필요한 상황입니다. 하지만 1인 개발 상황에서 데이터 마이그레이션을 수반한 대규모 리팩토링은 리스크가 크고, 기획팀의 신규 기능 배포 속도도 맞춰야 하는 딜레마에 빠져 있습니다. 조만간 동료 개발자가 합류할 예정인데, 현시점에서 제가 취해야 할 스탠스에 대해 의견을 여쭙고 싶습니다. 방안 A: 기획팀에 상황 공유후, 일괄 재설계를 통해 '기술 부채'를 완전히 청산하고 신규 기능을 올린다. 방안 B: 영향도가 큰 부분부터 점진적으로 수정하며, 팀원이 합류한 뒤 안정적으로 함께 리팩토링을 진행한다. 영한님의 실무 경험에 비추어 보았을 때 어떤 결정을 내리는 것이 팀과 서비스 관점에서 더 좋을지 조언해주시면 큰 도움이 될 것 같습니다. 감사합니다.
안녕하세요 영한님! 섹션 3의 계층 구조 강의를 듣고, 계층(트리) 구조를 모델링하는 다른 방법에 대해서도 찾아보면서 인접 리스트 모델 , 폐쇠 테이블 모델 이외에도 경로 열거 모델 , 중첩 세트 모델 등이 있다는 점을 알게되었는데요 실무에서 경험을 묻고싶습니다! 강의에서 소개해주신 이외에도 다른 모델을 상황에 맞게 자주 사용하시는지, 혹은 다른 방법들의 단점으로 인해 결국 인접 리스트 와 폐쇠 테이블 모델 의 사용으로 귀결되는 것인지 궁금합니다.
