다시보기 서비스도 제공하는지 궁금합니다.

안녕하세요 James 님 질문 감사합니다! 해당 챌린지는 다시보기를 따로 제공하지 않고, 추후 가공되어서 강의로 재출시될 예정입니다감사합니다

성능 측정시

안녕하세요 에어님! 좋은 질문 해주셔서 감사합니다네, 맞습니다. 이력서에 넣을 성능 수치는 AWS에 띄워서 측정하는 게 훨씬 좋습니다. 강의에서도 명확하게 "학습 초반에는 로컬에서, 이력서 작성 시에는 클라우드에서"라고 추천하고 있습니다.로컬 환경은 사양마다 결과가 달라집니다 면접관 입장에서 "제 로컬에서 0.5초 걸렸어요"라고 하면 "그래서 그게 정확한 거야?"라는 의문이 생깁니다. 또한 실무에서도 클라우드 환경에서 측정합니다 정확한 값을 분석하려면 보통 클라우드 상에 띄워놓고 하기 때문에, 이력서에도 그렇게 쓰는 걸 추천드립니다!그리고 AWS 경험 자체가 이력서의 강점이 됩니다! "AWS EC2에서 테스트했고, CloudWatch로 모니터링했습니다"라고 말하는 순간, 단순히 코드만 짠 사람이 아니라 실제 인프라 환경에서 성능 분석까지 해본 사람이 될 수 있어 더더욱 클라우드 상에서 측정하는 것을 추천드립니다!!

@EntityGraph와 fetch join 질문드립니다!

안녕하세요 라이언님 좋은 질문 해주셔서 감사합니다! 정확한 말씀입니다! @EntityGraph와 Fetch Join에는 분명한 차이가 있어요. 하지만 강의에서 강조한 "한계점"은 컬렉션 관계의 근본적인 제약을 의미합니다. 특히 1:N 관계에서 페이징 문제는 둘 다 동일하게 발생합니다LEFT JOIN vs INNER JOIN의 차이는 있지만, "여러 컬렉션 동시 조인", "컬렉션 페이징", "카테시안 곱" 같은 근본적인 한계는 동일하다는 게 핵심이에요.실제 프로젝트에서는 상황에 맞게 선택하되, 컬렉션 관계 페이징이 필요하면 두 쿼리로 나누는 전략을 고려해보는 것이 좋습니다 좋은 질문 주셔서 감사합니다!!

N+1 강의 관련 질문입니다!

안녕하세요 라이언님 좋은 질문 해주셔서 감사합니다 1. 말씀해주신 사항이 맞습니다!IN 절을 사용하면 쿼리 수는 당연히 줄어듭니다. N+1 문제에서 N번의 개별 쿼리가 나가던 걸 IN 절로 묶어서 훨씬 적은 횟수로 해결하게 됩니다예를 들어 회원 1000명의 주문을 조회한다면:N+1 방식: 1(회원 조회) + 1000(각 회원의 주문 조회) = 1001번의 쿼리IN 절 방식: 훨씬 적은 횟수 (아래에서 자세히 설명)말씀해주신게 정확합니다.2. 그런데 IN 절에도 제한이 있습니다강의에서 말씀드린 건 "IN 절도 무한정 크게 만들 수는 없다"는 겁니다.데이터베이스의 IN 절 크기 제한: 대부분의 데이터베이스는 한 번에 처리할 수 있는 IN 절의 크기에 제한이 있습니다. 예를 들어 Oracle은 기본적으로 IN 절에 1000개까지만 넣을 수 있습니다. Hibernate의 batch_fetch_size 설정: Hibernate도 hibernate.default_batch_fetch_size 설정에 따라 IN 절을 자동으로 나눕니다.spring: jpa: properties: hibernate: default_batch_fetch_size: 1000 이렇게 설정하면 Hibernate는 IN 절에 최대 1000개까지만 넣고, 그 이상이면 여러 번의 쿼리로 나눕니다.정리하면, 여러분의 이해가 정확합니다! IN 절을 쓰면 쿼리 수는 당연히 줄어듭니다. 강의에서 말씀드린 건 "IN 절에도 한계가 있고, 데이터가 정말 많으면 여러 번으로 나뉘어진다"는 것을 의미하고자 했습니다. 하지만 그래도 N+1보다는 훨씬 효율적이라고 볼 수 있습니다! 아무래도 강의에서 언급했던 내용때문에 헷갈리셨던 것 같습니다 ;_; 부디 답변이 되었길 바랍니다!@!

언커밋 상태에 대해 질문드립니다.

안녕하세요 라이언님 좋은 질문 해주셔서 감사합니다!1. 언커밋 상태란 정확히 무엇인가?언커밋 상태는 "작업은 했지만 아직 확정하지 않은 상태"예요. 워드로 비유하면 이렇습니다:언커밋: 문서 내용을 타이핑하고 있는데, 아직 "저장" 버튼을 누르지 않은 상태커밋: "저장" 버튼을 눌러서 파일로 확정된 상태롤백: "저장 안 함"을 선택해서 변경사항을 버린 상태데이터베이스에서는 다음과 같이 분류됩니다.UPDATE 같은 SQL을 실행했지만 COMMIT을 하지 않은 상태 → 언커밋COMMIT을 실행해서 데이터베이스에 영구 반영 → 커밋ROLLBACK을 실행해서 변경사항 취소 → 원래 상태로 복귀2. "다른 기자도 기사를 봤다"는 것의 의미여기서 핵심은 기자 A의 기사가 실제로 확정되어 "발행"된 게 아니라는 점입니다.기자 A의 상황기사 에디터 화면에서 "손흥민 맨유 이적!" 작성 중아직 "발행" 버튼을 누르지 않음 (언커밋 상태)화면에는 보이지만, 공식적으로 발행된 건 아님기자 B의 상황Read Uncommitted 레벨에서는 기자 A의 "작성 중인" 기사까지 볼 수 있음마치 다른 사람이 작성 중인 워드 문서를 엿보는 것과 같음기자 B가 이걸 보고 "확정된 정보"라고 착각해서 자기 기사에 인용해버림3. 커밋된 오보와의 차이커밋된 오보 (발행된 잘못된 기사):1. 기자 A: "손흥민 맨유 이적!" 작성 완료 2. 기자 A: "발행" 버튼 클릭 (COMMIT) → 공식 발행됨 3. 기자 B: 발행된 기사를 보고 인용 4. 기자 A: "앗, 오보였네!" → 기사 삭제 요청 5. 결과: 두 기사 모두 실제로 발행되었고, 나중에 수정/삭제 언커밋된 기사 (작성 중 취소):1. 기자 A: "손흥민 맨유 이적!" 작성 중 (언커밋) 2. 기자 B: 작성 중인 기사를 엿보고 인용 (Dirty Read) 3. 기자 A: "아니다" → 취소 버튼 (ROLLBACK) 4. 결과: 기자 A의 기사는 애초에 발행되지 않았는데, 기자 B는 "발행될 것"이라고 착각하고 인용해버림 4. 데이터베이스 관점에서의 차이언커밋 롤백:-- Transaction A START TRANSACTION; UPDATE news SET title = '손흥민 맨유 이적'; -- 변경 -- (이 시점에서 Transaction B가 읽음 = Dirty Read) ROLLBACK; -- 취소! 애초에 변경이 없었던 것처럼 됨 커밋 후 삭제:-- Transaction A START TRANSACTION; INSERT INTO news VALUES ('손흥민 맨유 이적'); COMMIT; -- 확정! DB에 영구 저장됨 -- Transaction B SELECT * FROM news; -- 확정된 기사 조회 -- 나중에 DELETE FROM news WHERE title = '손흥민 맨유 이적'; -- 오보 삭제 차이점:언커밋 롤백: 데이터가 "처음부터 없었던 것"으로 처리 (히스토리에도 안 남음)커밋 후 삭제: 데이터가 "한 번 존재했다가 삭제됨" (로그에 기록 남음)이라고 분류해야 합니다! 질문 주신 내용이 트랜잭션 격리성의 핵심 개념이니, 정확히 이해하고 넘어가시면 됩니다! 실제 프로젝트에서 격리 레벨을 적절히 선택하는 경험을 쌓아보시길 추천드립니다 🥰

트랜잭션 커밋 관련 질문드립니다.

안녕하세요 라이언님!좋은 질문 해주셔서 감사합니다. 트랜잭션의 핵심을 정확하게 짚어주셨네요! 이 질문에 답하려면 트랜잭션이 실제로 어떻게 동작하는지부터 이해해야 합니다.1. 왜 "uncommitted 업데이트"가 존재할까요?말씀하신 "처음부터 uncommitted 업데이트를 안 하면 되는 거 아니야?"는 사실 매우 핵심적인 질문입니다. 하지만 트랜잭션이 동작하는 방식 때문에 불가능합니다.예를 들어볼게요. A가 출금 트랜잭션을 시작했습니다.BEGIN; UPDATE account SET balance = balance - 500 WHERE id = 1; -- 여기서 다른 작업들을 더 수행... -- 검증 로직, 로그 기록 등... COMMIT; 트랜잭션이 시작되고 UPDATE를 실행하는 순간, 데이터베이스는 "변경 내용"을 어딘가에 기록해야 합니다. 왜냐하면 트랜잭션 내부에서는 변경된 값을 봐야 하니까 A의 트랜잭션이 출금 후 "내 잔액이 얼마지?"라고 다시 조회하면 500만원 차감된 값을 봐야 합니다. 본인의 트랜잭션 안에서는 이미 변경이 일어난 거니까요.롤백을 대비해야 하니까 커밋 전까지는 언제든 ROLLBACK이 가능해야 합니다. 그래서 원본 데이터도 유지하면서 변경 내용도 기록해둡니다.동시성 처리를 위해서도 필요합니다. 여러 트랜잭션이 동시에 실행되는데, 각 트랜잭션은 자기만의 "변경 버전"을 가지고 있어야 합니다.이렇게 "커밋은 안 했지만 변경은 기록된" 상태가 바로 uncommitted 상태입니다. 이건 데이터베이스가 트랜잭션을 지원하려면 필연적으로 생기는 겁니다.2. 그럼 다른 트랜잭션이 이걸 못 보게 하면 되는 거 아닌가요?정확합니다! 말씀하신게 바로 격리 수준(Isolation Level)의 핵심입니다."uncommitted 데이터를 다른 트랜잭션이 읽을 수 있나?"가 바로 격리 수준에 따라 달라집니다.READ UNCOMMITTED (강의 예시에서 문제가 된 상황): 다른 트랜잭션의 uncommitted 변경도 읽을 수 있습니다. 그래서 대출 심사가 500만원(아직 커밋 안 된 값)을 보게 되는 거죠.READ COMMITTED (제안하신 방식): 커밋된 데이터만 읽습니다. 대출 심사는 여전히 1000만원을 보게 됩니다. A의 출금 트랜잭션이 커밋되기 전까지는요.REPEATABLE READ: 트랜잭션 시작 시점의 스냅샷을 읽습니다. 중간에 다른 트랜잭션이 커밋해도 처음 본 값을 계속 봅니다.SERIALIZABLE: 완전히 순차적으로 실행되는 것처럼 동작합니다.제안해주신대로 "READ COMMITTED 이상"을 쓰면 Dirty Read 문제는 해결됩니다. 실제로 대부분의 데이터베이스는 기본값이 READ COMMITTED입니다.하지만 격리 수준을 높이면 성능 비용이 발생합니다.이런 고민을 실제 프로젝트에 적용해서 "동시성 문제를 이해하고, 적절한 격리 수준을 선택하고, 측정 가능한 결과를 만들었다"는 스토리를 완성해보세요. 그게 면접에서 정말 강력한 무기가 될 수 있을겁니다!! 감사합니다

Lovabe - supabese 연동이 노베이스 비개발자에겐 너무 어렵습니다.

우선 강의를 수정하기 전에 질문 주신 내용에 답변 드리자면 다음과 같습니다 supabase 없이 lovable 클라우드로 진행해도 괜찮습니다!또한, lovable 로 실습해도 좋지만 어렵다면 replit 으로 진행해보는 것을 추천드리며, 더 나아가서 2주차인 cursor 로 넘어가시는 것을 더욱 추천드립니다!

Lovabe - supabese 연동이 노베이스 비개발자에겐 너무 어렵습니다.

안녕하세요 멘토폴메이커님 좋은 질문 감사합니다! 확인해보니, Lovable 에 supabase를 연동하는게 기존 UI 와 달라진 점을 확인했습니다!변경한 내용에 맞춰서 강의를 새로 제작해서 올려두겠습니다 문의주셔서 감사합니다!!

cursor 유료가 과거에는 “500 fast 요청 + 무제한 slow” 같은 횟수 기반(레이트) 모델이었는데, 지금은 크레딧 기반으로 바뀌었습니다 라고 하는데 맞나요?

안녕하세요 재성님 좋은 질문 감사합니다!네, 맞습니다! Cursor의 요금제가 2025년 6월 16일부터 크레딧 기반으로 변경되었습니다과거 요금제 (2025년 6월 16일 이전)✓ 500 fast requests (빠른 응답) ✓ Unlimited slow requests (느린 무제한 응답) ✓ 명확한 횟수 기반 제한 이전에는 요청 횟수(request) 기반이었고, 일부 고급 모델은 2 requests를 소비했지만 예측 가능한 구조였습니다.현재 요금제 (2025년 6월 16일 이후)✓ Unlimited "Auto" 모드만 무제한 ✓ 프리미엄 모델 사용 시 크레딧 차감 ✓ 크레딧 소진 후 추가 요금 발생 가능크레딧 풀 방식으로 변경되어 사용하는 모델의 실제 API 비용에 따라 차감되는 구조입니다!

들여쓰기가 햇갈리네요

안녕하세요 jjjj1130님!! 파이썬 들여쓰기가 헷갈리시는 거 완전 자연스러운 반응이에요! 자바의 중괄호 방식에 익숙하신 상태에서 파이썬을 만나면 누구나 처음엔 낯설거든요. 하지만 걱정하지 마세요. 파이썬의 들여쓰기는 생각보다 규칙이 간단하고, 익숙해지면 오히려 코드가 깔끔해서 더 좋아질 겁니다!!1. 자바 vs 파이썬, 뭐가 다른가요?자바는 "중괄호 {}가 블록의 경계"를 알려줍니다. 들여쓰기는 사람이 보기 좋으라고 하는 것이지, 없어도 프로그램은 돌아갑니다.// 자바 - 중괄호가 블록 구분 if (조건) { 실행코드1; 실행코드2; } 반면 파이썬은 "들여쓰기 자체가 블록의 경계"입니다. 콜론 : 다음에 들여쓰기가 시작되고, 같은 칸만큼 들여쓴 코드들이 하나의 블록이 됩니다# 파이썬 - 들여쓰기가 블록 구분 if 조건: 실행코드1 실행코드2 2. 파이썬 들여쓰기 핵심 규칙 (이것만 기억하세요!)규칙 1: 콜론(:) 다음엔 무조건 들여쓰기if, for, while, def 같은 키워드 뒤에 콜론이 오면, 다음 줄부터 들여쓰기를 시작합니다.if x > 0: # 콜론 있음 → 다음 줄 들여쓰기 print("양수") print("입니다") 규칙 2: 같은 블록은 같은 칸 들여쓰기보통 스페이스 4칸(Tab 1번)을 사용해요. 파이참이나 VS Code 같은 IDE는 자동으로 맞춰줍니다.def solution(): # 첫 번째 블록 (4칸) for i in range(10): # 두 번째 블록 (8칸) if i % 2 == 0: # 세 번째 블록 (12칸) print(i) 규칙 3: 들여쓰기가 줄어들면 블록 종료if x > 0: print("블록 안") print("여전히 블록 안") print("블록 밖") # 들여쓰기 없음 = if 블록 종료 방법 1: 자바 코드를 파이썬으로 번역해보기지금 자바에 익숙하시니까, 간단한 자바 코드를 파이썬으로 옮겨보세요. 중괄호 위치가 들여쓰기 위치가 됩니다.// 자바 for (int i = 0; i # 파이썬 for i in range(5): if i % 2 == 0: print(i) 방법 2: 에러 메시지 읽어보기들여쓰기를 잘못하면 IndentationError가 나옵니다. 에러 메시지가 정확히 몇 번째 줄이 문제인지 알려주니까, 그 줄만 고치면 돼요.방법 3: 강의 코드 그대로 타이핑처음엔 강의 코드를 완전히 똑같이 따라 치는 연습을 해보세요. 손에 익으면 자연스럽게 감이 올 거예요. 복붙은 절대 금지! 직접 치면서 익혀야 합니다. 들여쓰기는 정말 2-3일 정도만 집중해서 연습하면 손에 완전히 익어요. 지금은 어색해도 곧 자연스러워질 거예요!오늘도 빠이팅해보시져!! 좋은 주말 보내세요 ㅎㅎ