173만명의 커뮤니티!! 함께 토론해봐요.
해결됨
원클릭으로 AI가 생성해주는 Youtube 쇼츠 만들기 자동화(with n8n)
안녕하세요 ! 항상 궁금했던 것인데 fal.ai 처럼 여러 ai 툴들을 사용할 수 있는 이런 플랫폼에서 사용하는 것과 각각의 ai 툴 별로 결제해서 사용하는 것들의 차이가 뭘까요? 각각 툴로 결제해서 사용하는게 조금 더 퀄리티가 좋은걸까요?
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
안녕하세요, 강사님덕분에 많이 배웁니다. 공부하면서 궁금한 내용이 있어 질문드립니다. FK 값 중복은 괜찮은거지? - 예시 규칙 1의 products(판매 상품) 가게 id(FK) 값 규칙 3 내용 중, 서비스를 중심으로 동사(팔다)를 골라 엔티티간 관계를 설정할 때 예시 2 내용입니다. 가게(stores), 판매상품(products) - 하나의 가계는 여러 개의 상품을 판다(팔수있다) 여기까지 이해를 했는데, 판매상품과 가게 관계에서 왜 '하나의 상품' 이라는 표현을 하는건가요? 여러개의 상품을 판다. 라고 벌써 정의 했으면서, 왜 하나의 상품이라고 하지? 여러개의 상품은 하나의 가게에 의해 팔린다. 라고 해야 하지 않나? 그래서 1:N 관계가 되는거 아니야? 그런 생각에 질의 드렸습니다. 감사합니다ㅡ
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요, 강사님. 이번 강의를 듣고 2가지 궁금증이 생겨 질문을 올리게 되었습니다. created_at 과 updated_at 구현 DB 레벨에서 ON UPDATE 와 DEFAULT CURRENT_TIMESTAMP 를 활용할 수 있다고 말씀해 주셨는데요, JPA에서는 @CreatedDate 와 @LastModifiedDate 로 애플리케이션 단에서 이를 구현할 수도 있습니다. 실무에서는 각각을 언제 사용할까요? 그리고 권장하는 구현이 따로 있으실까요? DB ENUM 타입을 잘 사용하지 않는 이유 실무에서 DB ENUM 데이터 타입 사용을 권장하지 않는다는 말씀으로 이해했습니다. 단순히 해당 ENUM 값의 범위가 변경되었을 때 이를 바꿔주는 것 이상으로 성능 이슈가 있어서라고 생각했습니다만, 정확히 알기가 어렵습니다. 자세한 설명을 부탁드려도 될까요? 감사합니다.
미해결
프로그래밍 시작하기 : 파이썬 입문 (Inflearn Original)
계정을 바꾸어야 할 것 같네요 바꾼다고 했는데 그대로 한글이 ㅠㅠ
미해결
프로그래밍 시작하기 : 파이썬 입문 (Inflearn Original)
안녕하세요 선생님 맞는 건가요??
미해결
AWS(Amazon Web Service) 실전을 위한 강의
짧아서 7% 넘었다고 취소가 안되네요. 좀 속은 느낌이에요
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
이런 식으로 실무적으로 접근했을 때 이 강의에서 예시를 들어주셨던 것처럼 (학생, 과목, 수강), (사용자, 영화, 평가) 엔티티를 개념적 모델링 단계에서 먼저 설계를 할텐데, 이때 설계 순서가 궁금합니다. (학생, 과목), (사용자, 영화) 와 같은 기본 엔티티를 먼저 만든 다음에 M:N 다대다 관계인 것을 확인하고 이것을 풀어내면서 동시에 비즈니스적 의미를 넣기 위해 중심(연관) 엔티티를 만드는 게 일반적인가요? 아니면 처음부터 학생 -> 수강 -> 과목 or 사용자 -> 평가 -> 영화 로 이어지도록 설계하는 게 일반적인가요?
미해결
Airflow 마스터 클래스
2024년 2월 이후로 Tistory OpenAPI 서비스 종료가 되었다고 합니다. https://tistory.github.io/document-tistory-apis/
해결됨
[매일 완독 챌린지] 저자와 함께하는 <FastAPI로 기획에서 출시까지>
작가님, 4주 2회차 과제 내용이 잘 이해가 되지 않습니다 ^^; 책 309쪽의 코드에서 #이미 존재하는 타임슬롯과 겹치는지 확인 이 부분 에서 이미 과제에서 요구하는 사항이 구현된 것이 아닌가요?
미해결
데이터 분석 SQL Fundamentals
안녕하세요 강의 너무 잘 듣고 있습니다. lag와 lead 함수에서 offset은 row 단위로밖에 설정을 못하는 걸까요? hiredate를 기준으로 order by 했을 때 day를 기준으로 offset을 설정할 수 있는지 궁금합니다. ex) lag를 이용하여 1일전 매출을 가져오는 방법
해결됨
AI 다루는 백엔드 설계 기본 - SpringBoot SNS 편
클로드 대신 제미나이 사용해도 수업따라가는데는 문제가 없나요?
미해결
[개정판] 딥러닝 컴퓨터 비전 완벽 가이드
안녕하세요, 좋은 강의 항상 감사드립니다. runpod 방법으로 바뀐뒤 적용 후 학습을 해보는 과정에서 incredibles detect 실습과정에서 에러가 났다가 해결하여 제보드립니다. numpy 2.2.6버전으로 template에 깔려있어서 numpy .1.x 기준으로 컴파일된 다른 패키지가 서로 충돌이 일어나서 epoch 학습이 시작되지 않는 에러가 있었습니다. 전 깔끔하게 numpy를 삭제하고 다운그레이드한 뒤 해결하였습니다. # 수정전 # Runpod의 경우 GDrive 연결하지 않고 /workspace/ultra_workdir에 저장. !mkdir "/workspace/ultra_workdir" # 주피터 노트북에서 참조할 수 있도록 /workspace를 /content/workspace 디렉토리로 soft link 적용. !ln -s /workspace /content/workspace # 수정 후 !mkdir "/workspace/ultra_workdir" !ln -s /workspace /content/workspace !conda uninstall numpy --force -y !conda install numpy=1.26.4 -y
해결됨
[매일 완독 챌린지] 저자와 함께하는 <FastAPI로 기획에서 출시까지>
사용자가 캘린더를 보유했는지 여부로 확인할 것 같습니다. 이유는 추후 서비스 확장할 때 조금 더 수월할 것 같다는 생각이 들었습니다. 프로젝트를 시작하면서부터 아래와 같은 생각을 했습니다. - "누구나 호스트가 되면 안될까?" - "호스트 역시도 커피챗을 신청할 수 있게 하고 싶다." 그래서 위와 같이 서비스 정책을 확장할 때를 대비해서 (마이그레이션 비용을 줄이는 방향으로) is_host로 검사하는 것이 아닌 일단 캘린더 보유 여부로 호스트인지 아닌지 확인하자라고 판단했습니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
상황 정리 저희가 매장 관리자용 통합 예약 관리 시스템 을 개발하고 있습니다. 현재 시스템 구조 [외부 예약 플랫폼 (네이버 같은)] ↓ 자동 연동 [매장 POS 시스템 (티오더 같은)] ↓ API 폴링 [우리 통합 관리 시스템] 고객이 외부 플랫폼에서 예약하면 POS에 자동으로 들어옴 우리는 POS API를 폴링해서 예약 데이터를 가져옴 우리 어드민에서 직접 예약 등록 기능도 곧 추가 예정 문제 상황 POS 업체에 확인해보니: API에서 외부 플랫폼 예약 구분이 안 됨 → 구분값 추가 예정 외부 예약은 원칙적으로 수정 불가 현재는 수정이 되지만 플랫폼 API 키가 연결 안 되어 사실상 불가능 DB만 바꿔서는 의미 없고, 외부 플랫폼 API 재호출이 필요 POS와 외부 플랫폼 간 연동이 아직 불완전한 상태 논의된 두 가지 방향 A안 (readonly 방식) - 우리 어드민 생성 예약 → POS 직접 등록 (수정 가능) - 외부 플랫폼 예약 → POS에서 폴링해서 조회만 (수정 불가) - UI에서 "외부 예약" 표시하고 수정 버튼 비활성화 - 수정 필요시 원본 플랫폼 바로가기 링크 제공 B안 (통합 수정 방식) - 모든 예약을 우리 시스템에서 직접 수정 가능하게 - 외부 예약 수정 시 POS API → 외부 플랫폼 API 호출까지 처리 장단점 분석 A안 장점 각 시스템의 책임 범위가 명확함 동기화 정합성 이슈 없음 외부 플랫폼 정책 변경에 영향 안 받음 여러 플랫폼을 한 곳에서 조회만 해도 관리자 리소스 절감 효과 A안 단점 수정은 여전히 각 플랫폼에서 해야 함 "진정한 통합 관리"는 아님 B안 장점 완전한 통합 관리 경험 관리자가 한 곳에서 모든 예약 제어 B안 단점 외부 플랫폼 API 직접 연동 불가 (계약 주체가 매장) POS가 외부 플랫폼 제어 API를 제공해야 하는데 현재 없음 POS-외부 플랫폼 양쪽 동기화 복잡도 높음 외부 플랫폼 정책(취소규칙 등) 변경 시 계속 대응 필요 문제 발생 시 책임 소재 애매 질문 이런 다중 오리진 데이터를 통합하는 시스템 에서: readonly로 가는 게 맞을까요, 아니면 수정까지 구현해야 할까요? 단계적으로 접근한다면 어떤 순서가 좋을까요? 1단계: 통합 조회만 2단계: POS가 API 제공하면 그때 수정 추가 비슷한 사례에서 일반적으로 어떻게 접근하나요? 현재 상황에서는 A안(readonly)이 합리적이라고 판단됩니다. 하지만 시간이 지나서 다음 조건들이 충족된다면: POS에서 외부 예약 플랫폼 식별값을 제공 외부 예약 플랫폼 API를 저희가 제공받을 수 있음 그때는 어떤 아키텍처로 가야 할까요? 옵션 1: 직접 호출 방식 [우리 시스템] → [외부 플랫폼 API] (직접 호출) → [POS API] (동기화용) 우리가 외부 플랫폼 API를 직접 호출 POS는 조회 + 동기화 확인용으로만 사용 옵션 2: POS Proxy 방식 [우리 시스템] → [POS API] → [외부 플랫폼 API] POS가 외부 플랫폼 제어 API를 제공하도록 요청 우리는 POS API만 호출하면 POS가 내부적으로 플랫폼 API 처리 외부 플랫폼 변경사항은 POS가 책임 옵션 3: readonly 유지 [우리 시스템] → [POS API] (조회만) 기술적으로 가능해져도 readonly 유지 각 플랫폼 바로가기만 제공 어떤 방식이 일반적이고, 각 옵션의 trade-off는 무엇인가요? 특히 옵션 1 vs 옵션 2에서: 우리가 직접 여러 외부 API를 관리하는 게 나을까요? 아니면 POS가 Proxy/Gateway 역할을 하게 하는 게 나을까요?
해결됨
AI 다루는 백엔드 설계 기본 - SpringBoot SNS 편
git에 있는 .claude를 프로젝트 파일세 추가하고, 'User 도메인을 만들고 회원가입, 조회 등 관련 API를 만들어줘. ' 라고 동일하게 터미널에 입력시 얼추 강의와 비슷하게는 만들어지는데 (여러번 돌려봤는데) 예를들면 dto에 record가 생성은 되는데 네이밍이 아예 다르다거나, 네이밍은 그럴 수 있는데 내용이 아예 달라서(예: Annotation이 전혀 없이 아래와 같이 생성 되거나 다른 파일의 내용이 다르거나 하는 경우, Service에 애노테이션이 아예 없거나, Controller에도 메서드가 반절도 안만들어졌다거나, resources>http>user.sh파일 내용에 내용이 반절이상 없다거나.. 등 package com.apiece.springboot_sns_sample.controller.dto; import com.apiece.springboot_sns_sample.domain.user.User; public record UserRegisterRequest(String email, String password, String username) { public User toEntity(String encodedPassword) { return User.builder().email(email).password(encodedPassword).username(username).build(); } } 이럴 경우 어떻게 강의를 수강해 나가면 좋을지 궁금합니다.
미해결
다양한 사례로 익히는 SQL 데이터 분석
강사님 안녕하세요 WITH절로 조인하셨을때 아래와 같이 WHERE절에서 product_id를 비교했을때와 조인조건으로 넣었을때 같은 실행계획과 성능이 나오는것 같은데 둘다 맞다고 봐도 되나요? 조인조건에 있는 것과 where조건에 있는 것이 어떤 차이가 있는지 잘 모르겠어서요! [궁금한 사항] join temp_00 b on a . user_id = b . user_id and a . product_id != b . product_id --where a.product_id != b.product_id [전체쿼리] with temp_00 as ( select b . user_id , a . order_id , a . product_id from order_items a join orders b on a . order_id = b . order_id ), temp_01 as ( select a . user_id , a . product_id as prod_01 , b . product_id as prod_02 from temp_00 a join temp_00 b on a . user_id = b . user_id and a . product_id != b . product_id --where a.product_id != b.product_id ) select count (*) from temp_01
해결됨
원클릭으로 AI가 생성해주는 Youtube 쇼츠 만들기 자동화(with n8n)
다른 질문에도 있는 것 같은데, 이미지 생성 시 자꾸 이런식으로 새로운 cell 을 만들어냅니다. 해결 방법이 있을까요?
해결됨
[매일 완독 챌린지] 저자와 함께하는 <FastAPI로 기획에서 출시까지>
두 요소를 모두 사용 하나, 각각 다른 용도로 쓸 것입니다. is_host 용도: 호스트 전용 엔드포인트 접근 통제 및 UI 메뉴 노출, 권한 기반 라우팅 호스트를 위한 endpoint API 에 대한 이용 허가 여부를 결정하는 호스트의 access token 생성 및 엔드포인트 함수 내의 조건문을 위해 필요한 모델 필드라고 생각합니다. 예상되는 우려점은 호스트 유저가 더이상 host가 되지 않을 때, host를 위한 API의 이용 허가를 거부 해야하기 때문에 is_host 필드값의 확실한 업데이트가 필요합니다. 사용자 캘린더 보유 여부 용도: 실제 예약 생성/동기화가 필요한 시점에 필수 체크, 호스트의 온보딩 플로우의 완료조건 게스트의 성공적인 Booking 을 위해서는 실제 캘린더에 대한 접근이 필요하기 때문에, 호스트는 게스트가 Booking 하기 위해서는 캘린더를 무조건 보유해야 합니다. 예상되는 우려점은 호스트의 캘린더는 호스트가 Booking을 받을 준비가 되있다면 항상 존재 해야하며, 실제 올바른 호스트에 매핑이 되어야합니다. 만약 캘린더가 존재 하지않거나, 호스트 캘린더 ID 에 대한 검증이 제대로 동작 하지 않는다면, 게스트의 Booking 이 실패로 이어지거나 다른 호스트 캘린더에 등록이 될 수 있습니다.
해결됨
[매일 완독 챌린지] 저자와 함께하는 <FastAPI로 기획에서 출시까지>
중복 예약을 데이터베이스의 고유값 제약으로 예방하는 방법 조건은 1)동일 일자와 동일 타임 슬롯인 경우 중복으로 간주 2)약속(부킹)이 취소되어 attendance_status 모델 필드값이 cancellled인 경우 예약 가능 위를 구현하기 위해 데이터베이스에게 아래 정보가 고유해야 한다는 특별한 규칙을 알려줄 수 있습니다. 1)누가 예약하는지 2)언제 예약하는지 3)어느 시간대에 예약하는지 위의 세가지가 모두 같으면 중복 예약이라고 판단 합니다. 취소된 재예약은 가능하게 하기 위해 고유성 규칙에 한가지 예외를 부여합니다. 호스트, 날짜, 시간 슬롯의 조합은 고유해야 한다. 예외적으로 예약상태가 "취소됨"이라면 그 예약은 위의 고유성 규칙을 무시해 달라고 합니다. 새로운 예약 생성 시: 데이터베이스는 예약하려는 호스트, 날짜, 시간슬롯 정보를 보고, 현재 '취소됨' 상태가 아닌 다른 예약이 이미 있는지 찾아봅니다. 만약 '취소됨' 상태가 아닌 다른 예약이 이미 같은 자리에 있다면, 데이터베이스는 "안돼! 이미 예약된 자리야!"라고 하며 새로운 예약을 저장하지 못하게 합니다. 만약 같은 자리에 '취소됨' 상태가 아닌 예약이 없다면, 데이터베이스는 새로운 예약을 성공적으로 저장합니다. 예약 취소 시: 어떤 예약이 '취소됨(cancelled)' 상태로 변경되면, 데이터베이스의 이 "특별한 규칙"은 그 취소된 예약을 더 이상 고유성 검사 대상에서 제외 합니다. 이제 그 자리는 "비어있는" 것처럼 간주되므로, 다른 사람이 같은 호스트, 날짜, 시간슬롯 정로 새로운 예약을 만들 수 있게 됩니다.
해결됨
[매일 완독 챌린지] 저자와 함께하는 <FastAPI로 기획에서 출시까지>
사용자가 호스트인지 두 가지 방법으로 확인 가능합니다. 1. User 모델에 선언한 is_host 모델 필드가 True인지 확인 2.사용자가 캘린더를 보유했는지 확인 이 중 두 가지 방법 모두를 사용해야 한다고 생각합니다. 1. User 모델에 선언한 is_host 모델 필드가 True인지 확인 -> 관점적 측면에서 명시적이고 관리적인 역할 및 자격을 부여합니다. 즉 사용자가 호스트로 자격이 있다는 것을 의미합니다. 관리자가 특정 사용자를 호스트로 지정하거나 해제하는데 사용할 수 있고 캘린더의 유무와 별개로 관리가 가능하게 서비스의 효율을 향상시켜 줍니다. 2.사용자가 캘린더를 보유했는지 확인 ->실제 예약 요청이 들어 왔을 때 해당 호스트가 유효한 캘린더를 보유하고 있는지 확인하는 최종적인 역할을 할 수 있습니다. 즉 위의 두 정보가 모두 필요한 이유는 존재하지 않는 사용자의 username으로 캘린더 정보를 가져오려고 하거나 호스트가 아닌 사용자의 username으로 캘린더 정보를 가져오려고 하는 시도를 막을 수 있을것으로 예상됩니다. 요약하면 is host는 "호스트로서의 신분"을, 캘린더 보유 여부는 "호스트로서의 활동을 나타내는 정보여서 모두 필요합니다.
