용어 관련

안녕하세요 질문 남겨주셔서 감사합니다!! 말씀해주신 부분처럼 도메인 용어에 익숙하지 않으신걸 대비하여 강의 진행하면서 종종 말씀드리는 방향으로 진행했다고 생각했는데.. 아직은 제가 좀 부족했나보네요.관련해서는 따로 제가 자료를 만들어서 공유드리던지 하겠습니다.이렇게 좋은 의견 주셔서 감사합니다!! 오늘도 좋은 하루 보내세요!

Outbox 패턴 도입이유

안녕하세요 배고프면근손실님!! 질문 남겨주셔서 감사합니다.질문해주신 부분은 정확하게 짚으신거에요. 절대 틀린말이 아니라고 생각합니다.지금 결국 DB를 저장하고 나서 RPC 실패 시 HTTP 오류가 나는데, Payout만 남는다. 이 문제를 해결하기 위한 핵심은 메시징 큐가 아니라 결국 체인 호출을 HTTP 요청과 분리하는거죠.말하신것처럼 커밋 후 202 돌려주고, 워커가 DB에서 처리하고자 하는 데이터를 꺼내서 처리하는 구조도 일반적으로 사용 가능해요. 이런 케이스에 대해서는 DB 테이블 자체가 작업 목록 역할을 하기 떄문에, DB와 큐 사이의 유실문제도 생기지는 않겠죠.OutBox도 맞는 말입니다. 결국 이중쓰기를 풀기위한 패턴이라, 큐를 쓰기로 했다는 전제가 먼저 있어야하는거죠.제가 여기서 Redis(BullMQ)를 사용한 이유는 뭐 여러가지가 있겠지만 크게 나열해보자면 다음과같아요.재시도, 백오프, DLQ와 같은 작업 처리 기능을 직접 만들지 않고 쓰기 위해서워커가 DB를 계속 폴링하지 않게 하고 싶어서어느정도의 학습 목적 - DB와 브로커 사이의 이중쓰기, 적어도 한 번 전달같은 문제가 실무에서는 되게 흔하다보니깐 Kafka, SQS, RAbbitMQ를 쓰는 실무에서 그대로 적용이 가능하다고 생각해서.물론 이 패턴을 FOR UPDATE SKIP LOCKED같은 패턴으로도 풀 수 있어요. OutBox라는것은 구현하는 방식에 따라서 여러가지 구조로 구성은 가능하기 떄문이죠.혹시 질문에 대한 답이 되셨을까요?? 추가적인 질문이 있다면 편하게 알려주세요!!요즘 날씨가 많이 추워요 감기 조심하시고 감사합니다!

사용자설정에 claude 설정들은 어떻게 하나요??

안녕하세요 kokoNut님 말씀해주신 부분처럼 그렇게 셋팅하셔도 되고,--safe-mode까지 붙여서 사용하신다면 추가적인 MCP 같은 도구들도 배제가되어서 저와 더욱더 유사한 환경을 구현하실 수 있을겁니다.하지만 기본적으로 외부 셋팅 즉 kokoNut님의 셋팅이 들어가도 큰 상관이 없습니다.- 이상한 전역 Hooks만 설정을 안해두셨다면...불안하시다면 말씀해주신 설정과 --safe-mode 조합하셔서 따라오셔도 무방하고 무언가 결과물 자체를 평가하는 Eval에 대한 내용은 아니기 떄문에 Claude Code를 전반적으로 학습하고 익숙하게 사용하는데에 초점을 맞춰주시면 좋을꺼같습니다.감사합니다!!

윈도우 환경에서는 진행이 어렵나요?

안녕하세요 kokoNut님 질문 남겨주셔서 합니다!!결국 기본적으로는 Claude Code를 활용하거나 간단한 Shell 명령어만 수행하기 떄문에 듣는데에 있어서는 큰 문제는 없을꺼같습니다.대신 절대 어려운 Shell 명령어는 없지만, Window에서 사용하는 형태로 조금만 수정하신다면 듣기 편하실겁니다.감사합니다. 좋은 하루 보내세요!!

강의 앞부분이 짤린거 같아요.

안녕하세요 YongIl Park님 질문 남겨주셔서 감사합니다. 저도 확인해보니 일부 잘려있네요.아무래도 녹화하는 과정에서 OS의 메모리 문제로 Sync가 맞지 않았던거 같습니다.모든 강의에서 초반부에 제가 말씀드리는 부분은 다 이런 내용입니다.저번 시간에는 ~~ 이런거 했었다.그래서 그냥 저번시간은 뭐였는지 간단하게만 언급하는 내용으로만 인지해주시면 감사하겠습니다.또한 제가 강의를 촬영하는 환경이나 마이크의 위치가 촬영 할 떄마다 조금씩은 달라 질 수 있습니다. 일관된 볼륨을 100% 완벽하게 제공해드리지 못해서 죄송합니다 ㅠㅠ혹시라도 추가로 듣는데에 있어서 불편함이 있다면 추가로 질문 남겨주시면 감사하겠습니다.날씨가 요즘 많이 춥습니다 감기 부디 조심하시고 오늘도 좋은 하루보내세요!!

TTL 산정 기준

안녕하세요 가다가진아님 질문 남겨주셔서 너무 감사합니다. 우선 요즘 날씨가 많이 추워요 ㅠㅠ 건강 조심하시고 항상 가다가진아님의 커리어를 응원할게요!!질문 주신 부분에 대해서 답을 해드리자면, 우선 기준은 없다로 말할 수 잇을꺼같아요.이 TTL이라는 산정 기준은 다양한 요소가 고려가 될꺼에요.어떤 도메인인지서비스가 얼마나 성숙하지MAU 및 DAU는 어떤지DB와 데이터 일관성이 많이 벌어져도 괜찮은지 등등 정말 많은 요인이 개입이 되게 됩니다.그래서 이 모든 것들을 기준을 잡고 5초로 하세요, 10초로 하세요 이렇게 말 할 수는 없을꺼같아요.대신 이렇게 사고를 해보시면 좋을꺼같아요.배너 같은 데이터는 캐시 주기를 오래 놓아도 괜찮겠죠?? 변화가 없는 어드민이 셋팅하는 값이니깐요.자연스럽게 그러면 이렇게 생각 해보실 수도 있죠 "잘 변화가 없는 데이터는 캐시 생명 주기를 길게 가져가야겠다"서비스 관점의 데이터는 어떨까요?? 예를들면 상품 재고 같은 데이터요.실시간으로 많이 변동이 될 수 있고 데이터의 일관성이 떨어진다면 시스템 장애가 발생하기 떄문에 "캐시를 넣지 않아야겠다."캐시라는것은 필수가 아니에요. 넣으면 되는 부분이 있고 오히려 넣지 않아야되는 부분이 있습니다. 그래서 가다가진아님임 어떤 부분에 집중하고 있는지 캐시를 넣었을 떄 어떤걸 고려해야 하는지 그리고 생명 주기를 길게 빼버리면 어떤 문제가 발생할지 이런 부분들을 고려하셔서 적합한 생명 주기를 설정하기를 추천 드릴게요.참고로 저는 너무 트래픽이 적어서 데이터의 상태가 많이 바뀌지 않는 형태에 대해서는 1초로 넣는 경우도 있어요!! 텀블링 하드라는 문제 정도는 예방하고 싶어서요!!감사합니다!

강의자료 문의

안녕하세요 혹시 모든 자료가 필요하신걸까요?? 저희도 내부적으로 찾아봐야 할 부분이 있어서필요한 자료가 따로 있으신건지 아니면 그냥 모든 자료를 제공해드리는것이 편하신지 말씀해주시면 전달드리도록 하겠습니다!

경쟁상태

안녕하세요 Cola님 질문 남겨주셔서 감사합니다. 음 우선적으로 제가 촬영하면서 표현이 조금 과한 부분이 있는거 같네요. 조금 정정해서 설명을 드릴게요.결론부터 말씀드리자면 이거는 트랜잭션 격리 수준에 따라서 다른요소입니다. Defaut인 REPEATABLE READ에서는같은 email이두번들어가는것까지는막아줍니다. 하지만경쟁상태와완전히무관한건아니고, 격리수준에따라결과가달라지며데드락이발생할수있습니다.그럼 왜 REPEATABLE READ에서는중복이생기지 않을까?여러분들이 사용하시는 일반 SELECT는 Lock없이 스냅샷 데이터를 읽지만, INSERT ... SELECT 안의 SELECT(여기 예시로는 NOT EXISTS 서브쿼리)는 조금 차이가 있습니다.REPEATABLE READ에서 InnoDB는이 SELECT가읽는범위에공유(S) next-key 락을겁니다. 그래서 email = 'test메일'을찾는순간그값이들어갈자리에 즉 자리라는걸 갭이라고 표현하는데, 이 갭에락이걸리고, 그걸 갭 락이라고 불러요. 이러면 다른트랜잭션은그자리에 INSERT할수없게됩니다.또 이렇게 락을 거는 읽기는 스냅샷이 아닌 최신 커밋 데이터를 읽기 떄문에, 먼저 실행된 트랜잭션이 커밋한 row를 후속으로 들어오는 트랜잭션이 볼 수 있죠.그럼 진짜 트랜잭션이 동시에 실행되면 어떻게 될까?이거는 제가 예시를 좀 들어보도록 할게요.T1 : NOT EXISTS 확인 → 없음 → 해당갭에 S 락획득T2: NOT EXISTS 확인 → 없음 → 같은갭에 S 락획득 (S 락끼리는호환)T1: INSERT시도 → T2의 S 락때문에대기T2: INSERT시도 → T1의 S 락때문에대기서로기다리는데드락 → InnoDB가감지해서한쪽을롤백 (한쪽은 애플리케이션 에러 발생)즉 결론은 한 건만 들어가고 중복은 생기지 않을꺼에요. 하지만 애플리케이션 상에서의 에러가 발생을 하게 되겠죠.READ COMMITTED에서는 어떨까요??해당 격리수준으로 가게 된다면, 이 SELECT는 락 없이 consistent read로 동작을 할 겁니다.그냥 일반 읽기로 해석하시면 됩니다.그러면 앞선 예시에서 T1, T2 둘 다 "없음"을 확인하고 둘 다 INSERT해서 같은 건이 드렁 갈 수 있어요.그래서 어떻게 막는가?격리 수준에 영향을 받지 않고 중복을 막고 싶다면 UNIQUE 조건을 걸어버리시는게 가장 좋습니다.그 다음에 INSERT IGNORE나 INSERT ... ON DUPLICATED KEY UPDATE를 쓰거나, 중복 키 에러 등등을 애플리케이션 레벨에서도 고려하시면 좋을꺼에요.결론 : NOT EXISTS 방식은 UNIQUE 제약을 걸 수 없는 상황에서 쓰는 차선책이다.

stmt

안녕하세요 Cola님 질문 주셔서 너무 감사합니다. 우선 저도 Cola님이 남겨주신 질문의 의도가 명확하게 이해가 가지 않아서.. 전체적으로 정리해드릴게요.제가 말하는 stmt는 PreparedStatement를 의미합니다.JDBC를 직접 써라 그런 느낌을 말씀드리기 보다는 DB에 쿼리를 보낼 떄 "SQL 툴"과 "파라미터 값"을 분리해서 보내는 방식을 설명드린거였어요.이 방식을 어떤 기술을 쓰든 내부적으로는 똑같이 적용된다는 의미였고요JDBC : PreparedStatement를직접만들고 setLong(), setString() 등으로값을바인딩MyBatis : #{param}으로작성하면내부에서 PreparedStatement로바인딩 (${param}은문자열치환이라해당되지않고 SQL Injection 위험이있습니다)JPA/Hibernate: JPQL이나메서드쿼리도최종적으로 PreparedStatement로실행그래서 그냥 그대로 사용하시는거 사용하시면 되는거고, 그저 PreparedStatement를 알고 있어라라는 의미입니다.참고로 MyBatis는 ORM으로 생각하지는 않아요 단순 SQL Mapper라고 생각하고 혼동이 오실까봐 이렇게 추가로 설명드릴게요!!혹시 추가적인 질문이 있다면 편하게 남겨주세요. 감사합니다!!

실습 결과 차이 | 테스트 해보면서 우리가 만든 모델로 의미 검색 해보면서 왜 이상한지 이해하기

안녕하세요 blueBird님 질문 남겨주셔서 감사합니다!! 우선 제가 결론부터 말씀드릴게요.코드가 절대 잘못된게 아닙니다. 학습 자체가 원래 돌릴떄마다 다른 값이 나오는게 정상적이에요.숫자가 다른 이유학습 자체가 확률적이기 떄문입니다. 기본적으로 train.ts 파일을 보시면 난수가 들어가는 부분들이 크게 세가지가 있어요.model.ts의 초기화 : Math.random으로 인해서 랜덤 초기화를 진행합니다.에폭마다 학습 쌍을 섞는 셔플도 Math.radom을 사용하고 있어요에폭 : 학습 데이터 전체를 처음부터 끝까지 한 번 다 훑는 단위negative sampling에서도 가짜 쌍을 뽑는데, 이것도 Math.random입니다.그렇다고 시드를 고정하지는 않아요.시드 : 난수 생성기 시작 지점그래서 실행할 떄마다 출발하는 부분이 다른거고, 중간에 보는 순서도 다른거고 쌍도 매번 다르기 떄문에 수치가 다른게 맞습니다. bludBird님이 계속 실행해보셔도 다른 값이 나올꺼에요그러기 떄문에 수치 자체를 보기 보다는 순위를 집중적으로 보시면 됩니다.실행마다 수치는 달라지니깐 결국 어떤 방향으로 가고있냐를 보는것이 모델 학습이에요. 그 부분에 집중해서 보는것이 분포 가설이 잘 보이냐라는 관점인거죠. 그래서 동물 단어 순위를 집중적으로 보시면 됩니다.이렇게 답변 드릴 수 있을꺼 같은데, 추가적인 질문이 있다면 편하게 댓글로 남겨주시거나 추가 질문으로 남겨주세요!!질문 주제가 다르다면 추가적인 질문으로 논의 열어주시면 감사하겠습니다!! 다양한 분들이 참고 하실 수 있는 자료로써 활용이 될 수 있을꺼같아요!!오늘도 좋은하루 보내세요!! 감사합니다!