Bài viết của codingpe

codingpe

@codingpe

Chứng nhận sự nghiệp
Xác minh Inflearn

Học viên: 3,501
Đánh giá khóa học: 113
Đánh giá khóa học: 4.9

Bài viết 30

Hỏi & Đáp

화면이 안나와요

일단 인프런 봇의 답변은 이렇네요. 한번 시도해 보시기 바랍니다. 이것도 안되면 담당자한테 직접 문의를 해야 할 거 같습니다.

2026-11-10T08:50:56.042Z

Lượt thích: 0
Số bình luận: 2
Lượt xem: 25

Hỏi & Đáp

화면이 안나와요

엇? 왜 그렇죠? 제 pc와 모바일 환경에서는 잘 나와요. 흠.. 이건 인프런에 문의를 해 봐야 할 거 같은데요. 일단 저도 인프런에 문의를 해 보겠습니다. 불편하시겠어요.. ㅠㅠ

2026-11-10T08:49:25.279Z

Lượt thích: 0
Số bình luận: 2
Lượt xem: 25

Hỏi & Đáp

화질 문의

안녕하세요 😊 제가 인프런 앱으로 몇 개 확인해 보니 그렇게 화질이 나쁘지는 않은거 같긴한데.. 혹시 어떤 강의 일까요? 그리고 데스크탑에서도 동일하게 화질이 안좋을까요??

2026-11-03T08:52:03.975Z

Lượt thích: 0
Số bình luận: 1
Lượt xem: 70

Hỏi & Đáp

안녕하세요.

안녕하세요. 😊 강의 자료를 하나씩 올리도록 하겠습니다. 수강해 주셔서 감사합니다. ^^

2026-10-31T07:09:52.646Z

Lượt thích: 0
Số bình luận: 3
Lượt xem: 123

Hỏi & Đáp

Redis 비동기 I/O 멀티플렉싱이 아니라 논블로킹 I/O 멀티플렉싱이 아닌가요?

안녕하세요! 좋은 질문 감사합니다. 말씀하신 내용이 정확합니다. 말씀해 주신 것처럼 Redis는 논블로킹 소켓과 epoll(Linux 기준)을 활용하여 여러 소켓의 I/O 준비 상태를 확인하고 실제 데이터 읽기는 read() 계열 함수를 호출하는 방식으로 처리합니다. 따라서 운영체제의 I/O 모델을 엄밀하게 구분한다면, Redis는 논블로킹 I/O + I/O 멀티플렉싱을 사용하는 동기 I/O 모델 이라고 설명하는 것이 더 정확합니다. 강의에서 '비동기 I/O 멀티플렉싱'이라고 표현한 것은 Redis가 특정 클라이언트의 네트워크 I/O를 기다리느라 멈춰 있지 않고 이벤트 루프를 통해 여러 클라이언트의 요청을 효율적으로 처리한다는 점을 쉽게 설명하기 위해 조금 포괄적으로 사용한 표현이었습니다. 다만 말씀하신 것처럼 기술적으로 엄밀하게는 '논블로킹 I/O와 I/O 멀티플렉싱' 이라고 표현하는 것이 맞습니다. 참고로 이 부분에 대한 상세한 내용은 제 유튜브 채널의 Redis 영상에서도 다루고 있습니다. 아래 영상의 7분 20초 부분 에서 Redis의 I/O 멀티플렉싱 동작 원리를 설명하고 있으니 함께 참고하시면 좋을 것 같습니다. https://youtu.be/H-jSrhvnaLY?si=-oMBYx85fB8lTt4M 좋은 질문과 꼼꼼한 피드백 감사드립니다. 앞으로도 궁금한 점이 있다면 언제든 질문해 주세요!

2026-10-25T03:19:09.674Z

Lượt thích: 0
Số bình luận: 2
Lượt xem: 59

Hỏi & Đáp

최근 N개 데이터 표현 시 중복 질문

네, 맞습니다. 😊 Redis의 List는 중복을 허용하기 때문에 말씀하신 것처럼 [101, 102, 103, 104, 105] 에서 다시 103을 LPUSH하고 LTRIM 0 4를 하면 [103, 101, 102, 103, 104] 처럼 중복이 생길 수 있습니다. 그래서 최근 본 상품처럼 동일 항목을 하나만 유지해야 한다면 List를 사용할 경우 보통 LREM → LPUSH → LTRIM 순서로 처리합니다. 강의 중, 패턴 02: 최근 본 상품 리스트 구현 (Lists) 에서도 해당 내용을 안내하고 있습니다. 그리고 또 다른 방법으로는 Sorted Set(ZSET) 을 사용할 수도 있습니다. 상품 ID를 member로, 조회 시간을 score로 저장하는 거죠. 이렇게 하면 중복 없이 최근 N개 데이터를 표현할 수 있습니다.

2026-09-18T07:18:08.680Z

Lượt thích: 0
Số bình luận: 1
Lượt xem: 72

Hỏi & Đáp

강의 교재가 있나요?

안녕하세요. 각 화면 하단에 '수업노트보기'라는 버튼이 있습니다. 이 버튼을 클릭하면 해당 수업에 대한 간단한 코멘트와 실습이 있을 경우 전체 소스가 제공됩니다. 확인 부탁 드립니다. 😊

2026-09-08T23:59:34.492Z

Lượt thích: 0
Số bình luận: 2
Lượt xem: 79

Hỏi & Đáp

pub/sub의 연결 객체에 대해 질문 드립니다.

안녕하세요. 😊 제가 언급한 "클라이언트 수만큼 pub/sub 연결을 하면 안된다."라는 말은 Redis 클라이언트가 아니라 브라우저를 말한 겁니다 . 아래와 같은 구조에서 [사용자(브라우저) - 애플리케이션 - Redis] 새로운 사용자(브라우저)가 접속할 때마다, 애플리케이션에서 Redis로 pub/sub 연결을 하기 때문에 문제라고 한 것입니다. 그래서 정상적인 구조는 애플리케이션에서 Redis로의 pub/sub 연결은 이 애플리케이션의 생명 주기 동안 1개만 유지 하고, 여러 사용자(여러 브라우저)에게는 애플리케이션 차원에서 큐(Queue)와 클라이언트 목록으로 관리해서 메시지를 나눠주는 방식(Fan-out)을 사용 합니다. (바로 다음 강의 [ 패턴 09-개선: FastAPI + Pub/Sub 연동 구조 개선] 에서 개선된 샘플을 제공하고 있습니다. 즉, Redis 구독 연결은 애플리케이션(서버 프로세스)당 1개로 고정하고, 그 연결로 받은 메시지를 애플리케이션 메모리 안에서 각 브라우저 연결(Queue)에 전달해주는 거죠. 그래서 브라우저가 100명이든 10,000명이든 Redis 입장에서 보는 구독 연결은 항상 1개입니다. 제가 표현을 단순히 Redis 클라이언트라고만 해서 혼란이 있었나 봅니다. 😊

2026-08-30T23:28:39.370Z

Lượt thích: 0
Số bình luận: 2
Lượt xem: 89

Hỏi & Đáp

레디스로 재고 관리

안녕하세요! 두 질문 모두 같은 핵심을 담고 있네요. Redis의 재고 감소와 DB 반영의 정합성에 대한 문제네요. 가장 심플한 구조 Lua Script로 Redis 작업을 처리한 뒤 바로 DB에 반영하는 방법이 있어요. 다만 이 구조는 Redis 성공 + DB 실패 시 정합성이 깨지는 문제가 있어요. 그래서 말씀하신 대로 중간에 큐를 두는 접근이 좋습니다. (1번 질문) Redis Stream + Worker + DB 제안하신 구조도 괜찮은 접근입니다. 다만 Worker 실패 시 재처리 전략을 검토해 주세요. 처리 완료 → XACK 미처리 메시지 확인 및 재처리 → XPENDING 중복처리에 대한 멱득성 보장 한 가지 더, Redis Stream은 인메모리 기반이라 Redis 장애 시 데이터 유실 가능성이 있어요. 프로덕션 환경이라면 AOF 설정을 반드시 활성화하세요. (2번 질문) Kafka 추가 1번 구조에서 Worker → DB 사이에 Kafka가 추가된 구조네요. Kafka를 추가하면 Consumer를 여러 개 띄워 처리량을 늘릴 수 있지만 운영 복잡도가 증가합니다. 트래픽이 충분히 커졌을 때 or 완벽한 내구성이 필요할 때 도입하는 걸 권장드립니다.

2026-06-03T23:34:37.748Z

Lượt thích: 0
Số bình luận: 2
Lượt xem: 133