MAU 3,000만 토스 개발자가 알려주는 금융 백엔드 실전: Outbox, 멱등성, Dual Write
안녕하세요. 좋은 강의 감사합니다. 한 가지 문의드리면 수강생 대부분은 블록체인에 익숙하지 않을 수 있으니, 코드를 설명하기 전에 주요 용어를 짧게 소개해 주시면 좋겠습니다. 예를 들어 ChainProbe 에서 chain 이 무엇을 가리키고 probe 가 어떤 동작을 뜻하는지, chainId 는 어떤 값인지 먼저 알면 getChainId() 를 왜 호출하는지도 이해하기 쉬울 것 같습니다. 지금은 도메인에 대한 이해도도 부족한 상태에서 생소한 용어가 코드에서 처음 나오다 보니, 실습에서 무엇을 확인하려는지 파악하기 다소 어렵네요.
Oracle 설치 방법 (on Container) 강의 수강중인데, 그대로 따라했는데도 docker desktop에 아무것도 안뜹니다. >docker run -d -p 1521:1521 docker.io/truevoly/oracle-12c c91e1231a551bc338f21fe3d48638127659c47f7c1700b91f13f3f9c63a568ea 여기까지는 잘 나오는데, > docker ps-a docker: unknown command: docker ps-a 여기서 이렇게 찾을 수 없다고 뜹니다.
안녕하세요. 기존 팔로우 수 계산하는건 select count(*) 해서 가져오는건데, 결국 해당 아이디의 팔로우 수가 증가하면 select할때 모든 row수를 가져와야하기 떄문에 쿼리 시간이 길어질 수 있어서, 별도의 followcount 테이블을 두어서 처리하는걸로 이해했는데요. 근데 followcount 테이블도 결국 팔로우를 수행할때마다 지속적으로 update 해주는 비용이 들어가는데 이런 부분은 어떻게 비교해야할까요?
안녕하세요. 백엔드 개발자로 회사업무에 ai를 좀 더 잘 사용해보기위해서 해당 강의를 들어보려고합니다 1) 2026년 현재 기준으로(10월말) 하네스다 뭐다 ai버전도 많이 바뀌었는데 현재 해당 강의가 아직도 도움이 될까요? 2) 해당 강의를 어떻게 수강하는게 효율적인가요? 구현을 한다면 직접 손으로 해야할까요?
질문이 있습니다 강의를 듣다보니 UUID를 써야겠다면 PK를 오토 인크리먼트 UNIQUE 를 UUID로 사용하라고 했는데 , 그리고 보안적인 측면으로 이야기하면서 오토인크리먼트는 유추 될수 있다 라고 하시면서 그러면 보안을 더 잘하는게 맞지 않냐는 말씀을 하셨습니다. 저도 말씀하신 생각과 같은데요 그런데 만약에 UUID와 오토 인크리먼트를 같이 쓰게되면 PK 값을 안보여주는 것도 이야기를 하셨는데 그러면 SELECT할때 WHERE 조건으로 UUID 즉 유니크 키를 사용하면 PK를 사용할때에 비해 이점이 줄지않나요? 그리고 문서 건수가 많아질수록 유니크 키 인덱스 부분도 쌓여서 비용이 쌓일거같은데 이부분이 궁금합니다.
안녕하세요 질문이 있습니다. b+트리 강의를 들으면서 문득 생각이 나서 질문드립니다.웹개발을 하는 회사원인데요 저희 회사에서는 pk를 랜덤 UUID를 사용해서 pk를 사용하고 있는데 프로젝트를 하면 마이그레이션을 하거나 할떄 꽤 많은 양을 합니다 수십만건 또는 수백만건 정도를 하는데 이 pk를 auto increment로만 바꿔도 성능이 많이 개선이 되나요?
paymentCreator 쪽을 보니 사용자가 결제를 진행하지 않고 결제창을 닫았다가 다시 열거나 새로고침 하면 db unique 단에서 에러가 날 것 같더라구요. creator 로직에서 조회를 먼저하고 있으면 반환 없으면 생성하는 방식으로 분기문을 둔다. db unique를 타게하고 try catch 등으로 처리한다. 가독성이나 복잡도 측면에서 각각의 장단점이 있을 것 같습니다! 또한 결제창을 닫고 쿠폰이나 포인트 사용을 변경하고 다시 여는 경우도 있을 것 같은데 주문에 대해서 결제가 유니크 하나로 제한해두신 이유도 궁금합니다 이런 경우가 payment 생성 말고도 다양한 로직에서 자주 나오는 상황일 것 같은데 제미니님은 주로 어떤 스타일로 개발하시는지 궁금합니다!
INSERT INTO users (name, email, age, city) SELECT '새 사용자', 'test메일', 25, 'seoul' WHERE NOT EXISTS ( SELECT 1 FROM users WHERE email = 'test메일' ); 이 쿼리를 처음에 설명해 주실 때 두 개의 프로세스가 동시에 데이터를 확인하고 삽입하려 할 때 경쟁상태가 발생할 수 있다라고 하셨다가 뒤에 이 방식은 사실상 경쟁상태에 무관하다고 정정해주셨는데 그럼 두 개의 프로세스가 동시에 데이터를 확인하고 삽입하려 했을때 무관하다는 의미인가요?? 왜 무관한지 잘 모르겠습니다.
eXPLAIN ANALYZE SELECT m.member_name, o.total _price FROM orders o JOIN member m ON m.member_id = o.member_id; 위쿼리를 시작했는데 거의 수분 5분이 넘어도 결과가 나오는데 너무 오래 걸립니다. Nested loop inner join (cost=5.85e+6 rows=4.86e+6) (actual time=2.89..446250 rows=5e+6 loops=1) -> Table scan on o (cost=503796 rows=4.86e+6) (actual time=0.77..3714 rows=5e+6 loops=1) -> Single-row index lookup on m using PRIMARY (member_id=o.member_id) (cost=1 rows=1) (actual time=0.0882..0.0882 rows=1 loops=5e+6) 위는 실행 계획으로 약7분 26초가 걸렸습니다. 그리고 데이터 넣을떄도 orders부분도 한 한시간 넘게 걸렷던거 같습니다. 강의를 듣고싶은데 이부분은 그냥 오래걸리면 넘어가도 될까요? 컴퓨터 사양도 그렇게 나쁘지않습니다 32gb램을쓰고 있는데 뭔가 강의를 계속해서 듣고 싶은데 이런거 하나하나 막힐때마다 너무 오래걸려서 어떻게 해야될지를 모르겠습니다.
안녕하세요 재민님! 강의를 들으면서 코드베이스를 보니, 조회 메서드에는 대부분 @Transactional(readOnly=true) 을 걸지 않으시더라고요. (물론 findById() 같은 건 Spring Data JPA 내부에 알아서 걸려있긴 하지만요) 예를 들어서, fun findByCategory(categoryId: Long, offsetLimit: OffsetLimit): Page<Product> { val categories = productCategoryRepository.findByCategoryIdAndStatus(categoryId, EntityStatus.ACTIVE, offsetLimit.toPageable()) val products = productRepository.findAllById(categories.content.map { it.productId }) .map { Product( id = it.id, name = it.name, thumbnailUrl = it.thumbnailUrl, description = it.description, shortDescription = it.shortDescription, price = Price( costPrice = it.costPrice, salesPrice = it.salesPrice, discountedPrice = it.discountedPrice, ), ) } return Page(products, categories.hasNext()) } productCategory를 조회하는 시점의 스냅샷과 product를 조회하는 스냅샷이 위 케이스에선 일치하지 않아도 별 문제가 생기지 않겠지만, 때로는 정합성과 같은 이유로 같은 시점의 스냅샷을 유지해야 하는 경우도 있을 것 같다는 생각이 들었습니다! 물론 이는 @Transactional 뿐만 아니라 DB 격리수준까지 엮인 문제라, 단순히 @Transcational 의 판단 기준으로만 보기는 어렵지만, 조회 시점에 @Transactional(readOnly=true) 를 사용하는 것에 대한 재민님만의 기준이 있는지 궁금합니다!
문제를 풀면서 66. 인덱스 설계 가이드 라인 에서 카디널리티 이야기가 나왔던게 생각이 났습니다. is_active는 값이 TRUE/FALSE 2개이므로 카디널리티가 낮을거라(중복도 높음) 생각했습니다. 그리하여 문제에서 주어진 쿼리를 보고 중간에서 is_active에서 풀 스캔 VS is_active 컬럼도 인덱스에 추가할지 고민이 되었습니다. 정답처럼 인덱스에 추가해주는게 더 나은 선택인걸까요? 음... 때에 따라 다른거 같기도 합니다! TRUE/FALSE의 비율 같은게 추가 조건으로 나왔더라면 선택하기 더 좋았을 거 같네요. 예를 들어, TRUE의 비율이 95% 다 이러면 인덱스를 달아주는 것과 풀 스캔이 별 차이가 없었을 거 같다는 생각이 드네요!
안녕하십니까! 덕분에 수업 잘 듣고 있습니다! 쿼리를 쉽고 가독성 좋게 설계하면서 추가 비용이 드는 형태가 많이 보이는데 제가 실제 실무를 겪어보진 않았지만 직감적으로 느끼는 부분이 있습니다! LLM이 발전하면서 쿼리에 대한 작성 난이도가 낮아졌을거라고 예상하고 시간이 지날수록 이런 부분이 더 빠르게 발전될 것이라고 생각합니다! 그럼 쿼리 작성에 대한 비용이 낮아지면서 0에 가까워질 거 같은데 그럼에도 기존 소프트웨어 개발 실무에서 적용된 "쉬운 쿼리, 조금의 추가 비용"의 형태가 유지될까요?! 아니면 실제로 이러한 부분이 현업에서도 반영이 되고 있나요? 비즈니스 의도, 집단 환경에 따라 다르겠지만 영한님의 시선으로도 의견이 궁금해서 질문드립니다!
궁금한게 key_length 를 이용해서 어떻게 사용하는지에 대해서가 22강에서 안나왔는데 그 이후로 나오나요? key_len 이 기대한것보다 적으면 인덱스가 잘 사용되고 있지 않다고만 설명을 하고 지나가셨는데 이후에 key_len 값을가지고 개선 하는방법이 나오는지 알고싶습니다.
