CRUD관련: async def get_db() 관련

안녕하세요! 강사 해여입니다.질문을 누락하여 답변이 늦어진 점 사과드립니다 ㅜㅜ! 1. 강의 코드는 사실.. 이미 커넥션 풀을 사용하고 있습니다.SQLAlchemy의 create_async_engine 함수는 poolclass 인자를 별도로 지정하지 않아도, 기본값으로 비동기 환경에 최적화된 AsyncAdaptedQueuePool을 사용합니다.따라서 강의 코드(create_async_engine(DATABASE_URL, echo=True, future=True))는 풀링을 사용하지 않는 것이 아니라, 가장 표준적이고 적절한 비동기 커넥션 풀을 기본 설정으로 사용하고 있는 것입니다.2. 그래서.. 별도로poolclass=QueuePool을 추가할 필요는 없습니다!AI의 답변 예시에 포함된 poolclass=QueuePool은 '풀링 기능을 새로 추가'하는 코드가 아닙니다.QueuePool은 본래 동기(sync) 방식용 풀입니다. create_async_engine에 이 인자를 전달해도 SQLAlchemy가 내부적으로 AsyncAdaptedQueuePool로 감싸서(wrapping) 처리해주기는 하지만, 이는 불필요한 코드이며 혼란을 줄 수 있습니다. 3. 또한 일반적으로 성능 튜닝은 다른 파라미터로 수행합니다.AI의 답변에서 실질적으로 유용한 정보는 pool_size, max_overflow, pool_recycle 같은 튜닝용 파라미터입니다.이 파라미터들은 AsyncAdaptedQueuePool을 포함한 모든 풀에서 공통적으로 작동합니다.실제 서비스를 운영할 때는 트래픽 상황에 맞춰 이 값들을 조절하여(예: pool_size=10, max_overflow=20) 데이터베이스 연결 성능을 최적화할 수 있습니다.감사합니다!

nox 실행 에러 메세지

안녕하세요 강사해여입니다. 소중한 피드백 감사드립니다. 현재 해당 강의의 구성이 E2E로 진행되면 좋을 것 같다는 피드백이 있어, 새롭게 강의를 작성하고 있습니다. 말씀주신 부분은 바로 처리해놓겠습니다 🙂 감사합니다.

.

안녕하세요. 강사해여입니다. 질문의 내용이 삭제된 듯 하네요! 확인 주시면 답변드릴게요 🙂

핫픽스코드 수정필요

안녕하세요 강사해여입니다! 아이고 코드를 작성하고 강의자료를 작성하던 중 복사 붙여넣기 시 에러가 있었던 것 같네요! 확인 후 처리해두겠습니다! 감사합니다.

13강 질문

안녕하세요! 강사 해여입니다.먼저 수강신청에 대한 감사의 말씀과 늦어진 답변에 대한 사과의 말씀올립니다. 안녕하세요! 두 가지 질문에 대해 답변드리겠습니다.1번 질문 .네, 좋은 관찰입니다! 혼란스러우실 수 있는데, 정확한 해석을 설명드릴게요.해당 부분은 Pycaret 버전에 따라 인코딩이 어떻게 되는 지에 따라 달라요!다음의 경우라면, *(일반적으로 알파벳 순 인코딩 때문에)클래스 0 = 'CH' (알파벳순으로 먼저 오는 것)클래스 1 = 'MM'SHAP 값의 의미양(+)의 SHAP 값: 클래스 1(MM) 예측 확률을 높임음(-)의 SHAP 값: 클래스 0(CH) 예측 확률을 높임따라서 올바른 해석은:LoyalCH가 높으면(빨간색) → SHAP 값이 음수 → CH(클래스 0) 구매 확률 증가가 되게 됩니다!만일 수강생 분의 환경에서 반대로 레이블이 되어있다면 말씀주신 해석이 맞아요 🙂2번 질문.observation=0은 홀드아웃(테스트) 세트 기준 0번째 행을 의미합니다. 만약 인덱스 범위를 벗어나면 오류가 납니다.(훈련셋에서 보고 싶다면 use_train_data=True를 줄 수 있어요:interpret_model(tuned_lgbm, plot='reason', observation=0, use_train_data=True) )감사합니다!

best model 이 튜닝이 불가한 게 선택된 경우

안녕하세요! 강사해여입니다. 인프런 인턴님이 너무 잘 답변주셨군요! Pycaret은 성능을 기준으로 모델을 선택하기 때문에 항상 튜닝기법이 사용 가능한 모델이 선택되지는 않아요! 그래서 중간중간 강의에서 몇 가지 모델을 제외 후 선택하고 있는데, 이러한 이유랍니다. 하지만 실제로 AutoML은 간단한 형태의 구현이 선호되기 때문에 이런 부분에 대해서는 후처리 혹은 예외처리를 사용해 패스해버리는 경우가 많답니다 🙂 감사합니다!

22강 마지막 영상 짤림

안녕하세요! 강사 해여입니다.먼저 친절한 피드백과 수강 감사드립니다! 말씀주신 부분은 편집자에게 전달하여 수정해놓도록 하겠습니다. 감사합니다!

백엔드 신입으로써 알아야할 보안에 대한 기본 수준이 궁금합니다

안녕하세요, 강사해여입니다.먼저 답변이 늦어진 점에 대해 사과의 말씀올립니다!.제 메일이 질문 등록관련 메일을 잘못 분류해버려서 확인이 늦었네요..!오, 질문자님께서 찾아보신 내용이 백엔드 신입이 알아야 할 보안의 '국룰' 그 자체입니다! 🎯결론부터 말씀드리면, 네, 그 부분들은 '이런 게 있구나' 수준이 아니라, '직접' 연습하고 '왜' 쓰는지 설명할 수 있을 정도로 아셔야 합니다. 먼저 말씀주신 4가지는 보안기법은 백엔드 개발자가 코드를 짜면서 마주치고 고려해야 하는, 밥 먹는 것과 같은 기본 중의 기본입니다.SQL 인젝션 (SQL Injection)왜? 백엔드는 DB와 직접 대화합니다. 유저가 입력한 값을 검증 없이 SQL 쿼리에 그대로 붙여넣으면(string concatenation), DB가 통째로 털리거나 삭제될 수 있습니다.어떻게? "이런 게 있구나"가 아니라, Prepared Statement (Parameter-based query) 를 왜 써야 하는지, ORM(JPA, TypeORM 등)이 이걸 어떻게 막아주는지 원리를 아셔야 해요.XSS & HttpOnly왜? 유저가 입력한 스크립트가 다른 유저 화면에서 실행되면, 쿠키(로그인 정보)를 탈취당할 수 있습니다.어떻게? 백엔드 개발자는 두 가지를 해야 합니다.데이터를 DB에 저장할 때 (Input) 또는 화면에 뿌려줄 때 (Output) 이스케이프(escaping) 처리를 해야 합니다. (e.g., 를 <script>로)쿠키를 발급할 때 HttpOnly 플래그를 켜서, 자바스크립트가 쿠키에 접근하는 것을 원천 차단해야 합니다. (이건 순수 백엔드 영역!)CSRF & SameSite왜? 로그인한 유저가 자기도 모르게 악성 링크를 클릭해서 "비밀번호 변경"이나 "글 삭제" 같은 요청을 서버에 보내버릴 수 있습니다.어떻게? 예전엔 CSRF 토큰을 많이 썼지만, 요즘엔 쿠키에 SameSite=Strict 또는 SameSite=Lax 설정을 걸어서 브라우저 레벨에서 대부분 방어합니다. 이 옵션이 무엇을 의미하는지 아는 것이 중요합니다.HTTPS (SSL/TLS)왜? 유저가 아이디/비번을 입력할 때, 그 데이터가 인터넷 망을 통해 서버로 날아가는 모든 과정을 암호화합니다. 이게 없으면 중간에서 누구나 훔쳐볼 수 있어요.어떻게? 신입에게 직접 SSL 인증서를 발급하고 서버에 세팅하라고 시키진 않을 수 있지만 (주로 인프라/데브옵스 담당), 최소한 HTTPS가 왜 필요하고, HTTP와 뭐가 다른지 설명할 수는 있어야 합니다.그러면 저 4개만 알면 될까요? 답은 아니요입니다! 저 4가지가 '공격 기법'에 대한 방어라면, 백엔드 개발자가 '기본적으로 구현해야 할' 보안 기능들이 몇 가지 더 있습니다. '기본 세트'라고 보시면 돼요.🔒 비밀번호 암호화 (Hashing)절대! NEVER! 유저 비밀번호를 쌩 텍스트(Plain Text)로 DB에 저장하면 안 됩니다.최소한 bcrypt 같은 단방향 해시 함수를 사용해서 '해시값'으로 변환해 저장해야 합니다. (MD5, SHA-1 같은 옛날 방식은 쓰면 안 돼요!)🔑 인증(Authentication)과 인가(Authorization)인증 (AuthN): 이 사람이 '누구'인지 확인하는 것 (e.g., 로그인, JWT 발급)인가 (AuthZ): 이 사람이 '권한'이 있는지 확인하는 것 (e.g., '관리자'만 이 API를 쓸 수 있는가?)이건 그냥 보안이 아니라, 백엔드 기능의 핵심입니다.🛡 입력값 검증 (Input Validation)"유저가 보내는 모든 데이터는 일단 의심하고 본다."가 기본 마인드셋입니다.이메일 필드에 진짜 이메일 형식이 왔는지, 나이 필드에 숫자가 왔는지, 글 내용의 길이가 너무 길진 않은지 등등... 모든 API의 입구에서 검증해야 합니다.🤫 민감한 정보 노출 금지 (Error Handling)에러가 났을 때, 유저에게 SQL database connection error... 같은 시스템 내부 오류 메시지나 스택 트레이스(stack trace)를 그대로 보여주면 안 됩니다.해커에게 시스템 내부 구조에 대한 힌트를 주는 꼴입니다. 에러는 '로깅'만 하고, 유저에겐 "서버 오류가 발생했습니다." 같은 일반적인 메시지만 보여줘야 합니다.사실 신입 혹은 한명의 개발자에게 이 모든 것을 '마스터'해서 완벽하게 방어하라고 기대하진 않습니다. 😅다만, "왜 쿼리를 이렇게 짜셨어요?" 또는 "쿠키 설정은 왜 이렇게 하셨어요?"라고 물었을 때,"SQL 인젝션을 방어하기 위해 Prepared Statement를 사용했습니다.""XSS 공격 시 쿠키 탈취를 막기 위해 HttpOnly 플래그를 켰습니다."라고 '보안' 관점에서 그 이유를 설명할 수 있는 것. 그게 신입에게 기대하는 '기본 수준'입니다.지금처럼 궁금해하고 직접 찾아보는 태도가 제일 중요합니다! 화이팅입니다! 💪

노션 학습자료 링크 부탁드립니다!

아이고 강의 소개 페이지 수정이 안되었군요!금일 저녁 퇴근 후 수정해놓을게요 🙂 피드백 감사드립니다!!

강의 소개란에 '이런 내용을 배워요' 잘못 올라온거 같아요

안녕하세요, 처음 제공되는 템플릿에 포함된 내용이 바로올라와버렸군요 😅바로 수정하였습니다! 친절한 피드백 감사드리며! 즐거운 수강되길 바랍니다!! 언제든 질문이 생기면 편하게 올려주세요!항상 친절히 답변해드릴게요 🙂