172만명의 커뮤니티!! 함께 토론해봐요.
미해결
6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법
1. 현재 학습 진도 섹션 3 15강 수강 2. 어려움을 겪는 부분 아직 섹션3 15강밖에 수강하지 않았지만 예전에 배포했을때 설정 문제로 과금이 나간적이있어서 강의는 계속 들으면서 로컬에서 해보고 개인 프로젝트에 적용해보는것이 좋을까요? 아니면 둘 다 하는것이 좋을까요??
해결됨
은행 서버 프로젝트 실습을 통해 배우는 코틀린 마스터 클래스
안녕하세요, 강사님 🙂 덕분에 코프링을 빠르게 배우고 있어 감사드립니다! 영상 8:20 경, JWT 설명 중 withSubject() 의 값으로 email 만 넣는다던가, name 만 넣어서 구현한다고 말씀주셨습니다. 고민을 해봤지만 여러 개의 Subject 를 만드는 이유가 궁금해서 질문드립니다. 상황 예시와 함께 답변해주시면 감사드립니다!!
해결됨
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
안녕하세요. 인기 게시판 목록 기능을 Redis의 Sorted Set을 활용해 좋아요 순으로 정렬하는 방식으로 구현하다 고민이 생겨 질문하게 되었습니다. 먼저 잦은 데이터 변경을 고려해서 Sorted Set의 member에는 게시판 ID만 저장하고, score에는 좋아요 수를 저장하도록 했습니다. 하지만 목록을 생성하기 위해서는 제목, 생성일 같은 부가 정보가 필요한데 이 데이터를 얻는 효율적인 방식에 대해 고민이 생겨 질문을 드리게 되었습니다. AI에게 도움을 받아 2가지 방법을 생각해보았는데 현실성이 있는지 판단 부탁 드립니다. Redis + RDB 조합 Redis ZSet에서 상위 10개의 ID 목록을 먼저 조회합니다. 해당 ID 목록을 가지고 RDB에 WHERE id IN (...) 쿼리를 날려 상세 데이터를 가져옵니다. 데이터베이스의 IN 쿼리는 순서를 보장하지 않기 때문에 애플리케이션에서 Redis가 준 ID 순서대로 리스트를 다시 재정렬하여 반환합니다. 제가 생각하기에는 인기 게시판 목록을 조회할 때마다 RDB의 ORDER BY 부하를 줄이려다 오히려 애플리케이션 단에서 정렬과 DB 조회가 일어나다 보니 얻는 것보다는 잃는 게 많은 구조가 아닌지 고민이 됩니다. Redis Sorted Set + Hash 조합 정렬 기준(ID, 좋아요 수)은 기존대로 Sorted Set에 관리합니다. 게시판의 상세 부가 정보는 Redis의 Hash 자료구조에 따로 캐싱합니다. 목록 조회 시 Sorted Set에서 ID를 뽑은 후 DB를 거치지 않고 Hash에서 상세 데이터를 조회합니다. 이 방식은 DB에 부하를 줄일 수 있지만 데이터가 자주 변하게 된다면 레디스에서 데이터를 자주 변경해야 되어 메모리에 큰 부하를 줄 수 있을 것 같아 고민이 되는 것 같습니다.
미해결
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판
테스트 작성 시, 소스파일에(src) 있는 DTO를 그대로 사용하지 않고, 복사해와서 새로 정의를 하시던데 그 이유가 뭔지 궁금합니다!
미해결
6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법
안녕하세요 딩코님! 좋은 강의 잘 들었습니다. 강의를 듣다가 조언을 구하고 싶은게 있어서 질문 남깁니다. 저는 현재 주니어 개발자로 일으나 부하테스트 같은것을 회사에서 해볼 수 없는 상황이라(운영 인력이 아님...또한 작은 시스템이라 모니터링도 없고 구축할수도 없는 환경)강의에서 다뤄주신 내용을 실무에 적용해보기가 어려운데요... 그래서 제가 생각해본게 테스트 코드로 만들어서 돌려보면 어떨까 생각했거든요. 예를들어 아래와 같은 메소드를 만들어 놓고, 캐시 전/후를 비교하는 거죠... long start = System.currentTimeMillis(); service.findSomething(id); long elapsed = System.currentTimeMillis() - start; System.out.println(elapsed); 그런데 한가지 고민되는 포인트가, 테스트 코드로 만들어서 돌렸을때 성능 개선을 수치적으로 적기가 좀 애매할것 같다고 생각이 들어서요. 아무래도 JVM이라던지, warmup이라던지 통제할 수 없는 변수가 있다보니까요. 그래서 질문은 아래와 같습니다. 특정 메소드에 로컬 캐시를 적용하기 전/후 테스트 코드에서 성능을 비교 했을때, 1초->1ms로 성능 개선했다. <- 이런 문장이 임팩트가 있을까요? 아님 테스트 코드에서 한건 좀 신뢰성이 떨어질까요? ㅠㅠ 테스트 코드에서 돌려봤을때 누가봐도 신뢰성있게 만들려면 어떻게(?), 무슨 툴(?)을 써서 하는게 좋을까요? ㅠㅠ 저 같이 운영 환경에 적용해볼수 없는 개발자에게 조언을 주시면 또 감사하겠습니다!
미해결
커머스 서비스로 배우는 NestJS 실전 개발 (w. Prisma, Docker, Redis, Kafka)
prisma generate로 생성했으면 qty, unit_price 같은 값들 number | null 이라 필터링을 한번 해줘야 될텐데 강사님 코드에는 그런 흔적이 없이 깔끔하게 처리되어 빌드가 잘되는거 같아보여요. 물론 사소한것이지만 라이브러리 버전차이인지 따로 처리해준게 있는건지 궁금합니다
미해결
커머스 서비스로 배우는 NestJS 실전 개발 (w. Prisma, Docker, Redis, Kafka)
createdAt이랑 updatedAt은 default(now()) 랑 @updatedAt 을 통해 prisma model에서 핸들링이 가능한데 사용하지않고 dto에서 직접 다루는 이유가 궁금합니다
미해결
커머스 서비스로 배우는 NestJS 실전 개발 (w. Prisma, Docker, Redis, Kafka)
relationMode="prisma"로 지정하면 ORM으로 조인하는 기능들 사용하면서 실제 DB에는 관계가 안걸리는걸로 알고 있는데 복잡한 조인이 아니면 저런식으로 사용해도 상관없지 않나 생각이 들어 강사님께서는 어떻게 생각하시는지 궁금해서 어쭤봅니다.
미해결
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판
6:27분 쯤 강의 내역에서 각 브로커가 파티션을 분사하는 과정에서 브로커 3에 topic3이 갑자기 생겼는데 그림에서 오타인 걸까요 ?
해결됨
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
안녕하세요. 최근 수백만 동시 접속을 처리하는 예매 시스템 아키텍처 관련 강의와 유튜브 영상을 참고하면서, 작은 프로젝트로 선착순 쿠폰 발급 시스템을 직접 구현해보며 학습하고 있습니다. 현재는 Redis를 활용해 선착순 쿠폰 발급을 구현하는 구조를 고민하고 있는데, 몇 가지 아키텍처 설계에 대해 궁금한 점이 있어 질문드립니다. 1. Redis + DB 원자성 관련 Redis에서 쿠폰 발급 가능 수량을 감소시키고, 동시에 DB에도 반드시 반영(쿠폰 발급 및 사용자 할당 기록)해야 하는 상황을 가정하고 있습니다. 이 경우 Redis의 재고 감소와 DB 반영을 하나의 트랜잭션처럼 원자적으로 묶어야 할 것 같은데, 현실적으로는 분산 환경 특성상 이를 직접적으로 묶는 것이 어렵다고 이해하고 있습니다. 그래서 일반적으로는 Lua Script로 Redis 내부에서 쿠폰 재고 감소 중복 발급 방지 처리 Redis Stream(또는 Queue)에 발급 이벤트 기록 을 원자적으로 수행하고, 이후 별도의 스케줄러(또는 Worker)가 해당 Stream을 읽어서 DB에 반영하는 방식 으로 설계하는 것이 맞는지 궁금합니다. 2. 메시지 큐(Kafka 등) 사용 시 구조 또한 쿠폰 발급 결과를 Kafka 같은 메시지 큐로 전달하는 방식도 있을 것 같은데, 이 경우에도 동일하게 Lua Script로 Redis 내부에서 쿠폰 재고 감소 중복 발급 방지 처리 Redis Stream(또는 Queue)에 발급 이벤트 기록 이후 스케줄러가 stream읽어서 Kafka로 전달 Consumer가 DB에 반영 과 같은 구조로 가져가는 것이 일반적인지 궁금합니다.
해결됨
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
Lock 해제 코드에서 다른 사용자가 생성한 락을 삭제하지 않기 위해 본인의 identifier이랑 락의 value를 비교해서 삭제하는 로직 부분에서 궁금한 내용이 있습니다. 멀티스레드, 프로세스 환경에서 충분히 일어날 일 이라고 하셨는데 내가 락을 얻으면 다른 사용자는 락을 얻지 못해 value는 항상 나의 identifier이 들어있어야 하는게 아닌가? 라는 생각이 드는데 rd.set(lock_name, identifier, nx=True, px=lock_timeout_ms) 이 코드 방식으로 락을 만들면 여러 사용자가 특정 환경에 락을 얻을 수 있는건가요?
해결됨
6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법
?
해결됨
6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법
프로젝트한게 없는데 어떻게 하죠??..포트폴리오를 작성하려는데..프로젝트한게없어서 강의들으면서 한걸 써도 된아요??
해결됨
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
학습 중 궁금한 점이 있으시면 편하게 질문 주세요. 참고로 질문이 구체적일 수록 더 정확한 답변을 드릴 수 있습니다. 😊 안녕하세요. 강의를 듣고 있는 개발자입니다. 이전에 유튜브에서 선착순 예매 관련 영상을 봤었는데 해당 영상에서 레디스를 이용해서 대기큐를 구현하는 것을 설명해주셨는데 그거에 대해서 질문이 있습니다. 레디스의 소티드 셋에 넣고 폴링을 통해서 상태를 확인한다. 타 스케줄러가 소티드셋에서 꺼내서 액티브로 바꾼다 라는 설명이 있었는데, 정확히 어떤식으로 구현하는 건지가 궁금합니다. 스케줄러가 꺼내고 액티브 유저 set으로 집어 넣는건가요? 그리고 소티드셋에서 꺼내서 엑티브 유저로 만드는 작업은 원자적으로 처리되게 하는건가요?
미해결
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
안녕하세요. 항상 좋은 강의 감사합니다. API LIMIT을 보면 ABUSING이랑 비슷한 개념이라고 느꼈습니다. 예를 들어, 어떤 유튜브 라이브에서 좋아요 리액션을 너무 많이 눌렸을 때, API LIMIT 알고리즘으로 고정 윈도우 방식이 적절하다고 생각했습니다. INCR 이 빈번한 작업이기 때문이죠. 근데 악성 BOT(봇)으로 좋아요를 악의적으로 누를 수도 있는데 이때는 ABUSING(어뷰징) 처리를 해야한다면 API LIMIT과 동일하게 가져가는게 맞을지 설명주신 API LIMIT도 제한 구간 10초당 몇개 를 구간과 임계치를 설정하는데, 보통 어떤 기준으로 실무에서 설정하는지 궁금합니다. 운영하면서도 모니터링하면서 조절할거 같은데 유튜브 라이브의 임계치 구간을 설명한다고 가정하면 인간의 마우스나 손으로 눌렸을 때 1초당 10번 이하? 이렇게 추상적인 실험 데이터도 정하는게 맞는지도 궁금합니다. 감사합니다.
미해결
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
DB부하를 줄이는 전략에서 DB의 데이터 사용자 이름을 변경 할 때, 기존 캐식 삭제 보다 기존 캐시의 JSON 프로필 이름만 수정하는 게 더 비효율적인가요? 기존 캐식 삭제 > 새로운 캐시 생성 VS 기존 캐시의 수정
미해결
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
항상 좋은 강의 감사합니다. Redis와 Kafca의 Pub/Sub 차이가 궁금합니당. 예를 들어, 인스타 라이브에서 사용자의 리액션 좋아요를 Redis에 두고 post로 좋아요를 업데이트 칠 때, MYSQL 좋아요 수도 같이 증가하기 위해 Redis와 Kafca의 Pub/Sub 의 차이점이 있을까요? 좋아요 api가 redis의 좋아요 수 증가 > kafca 메시지 발행 > mysql 구조라 가정했을 때, 대규모트래픽에서 kafca와 redis의 Pub/Sub의 차이랑 뭐가 더 적절한 선택인지 궁금합니다. 감사합니다.
미해결
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판
설명중에 @Version 필드를 낙관적 락에서 이용할 수 있어가지고~ 라고 하셧는데 실제 돌려보니 비관적락 2에도 DB 업데이트가 되었습니다. AI 에게 물어보니 @Version 어노테이션이 붙은 필드는 JPA 사용시 @Lock 어노테이션 사용여부 상관없이 업데이트가 된다고 합니다. 혹 다른 qna 에도 같은 내용이 있는지 확인은 모두 안해 보았습니다. ======================== 응, 같은 엔터티 row에 실제 UPDATE 가 나가면 @Version 필드는 증가한다고 보면 돼. 락 방식이 낙관적이든 비관적이든 핵심은 이거야. @Version private Long version; 이 필드가 있는 엔터티가 dirty checking으로 변경 감지 되고, flush/commit 때 UPDATE 대상이 되면 JPA/Hibernate가 version 값을 같이 갱신해. ========================
미해결
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
RDBMS 로만 생각이 고정되어있었는데- 캐싱으로도 이렇게 문제들을 해결할수 있는거군요...
미해결
2026년! 백엔드 개발자를 위한 Redis 실전 가이드: 기초부터 실무 패턴까지
안녕하세요, 강의 잘 듣고 있습니다. 양질의 강의 감사드립니다. Sorted Set을 활용한 리더보드 강의 시청 후 궁금한 점이 생겨 질문 남깁니다. Redis 공식 문서에 따르면 Score가 동률일 때 사전순(lexicographical)으로 처리된다고 명시되어 있는데요, 실제 비즈니스 환경에서는 사전순이 아닌 여러 기준을 복합적으로 비교해야 하는 경우가 많을 것 같습니다. Score가 64비트 부동소수점임을 활용해, 자릿수별로 기준을 나누는 방안(예: 1~8자리는 기본 점수, 9~12자리는 2순위 기준, 13~15자리는 3순위 기준 ...)도 생각해 보았습니다. 다만 동률 비교 기준이 많아지거나 기본 점수 자체가 클 경우 double 정밀도 한계로 인해 적용이 어렵겠다는 생각이 들었습니다. 실무에서는 이러한 복잡한 동률 상황을 어떤 방식으로 처리하는지 팁을 여쭤봐도 될까요? 감사합니다.
