안녕하세요 토비님!! 강의를 완강하고 제 프로젝트를 리팩토링하면서 피드백받고싶은점이 생겨 질문글을 올립니다. Repository Port를 기술에 종속시키지 않기 위해 Adapter에서 JPA, MyBatis, QueryDSL을 조합하는 구조를 선택했는데, 이 설계 방향이 적절한지 조언을 구하고 싶습니다. 현재 구조 core/ └── domain/ └── application/ └── required/ ← Port 인터페이스 └── ~Repository adapter/ └── persistence/ ├── ~RepositoryAdapter ← Port 구현체 ├── ~JpaRepository ← Spring Data JPA └── ~MybatisMapper ← Mybatis 매퍼 인터페이스 의존 관계 [Service] → [Repository] ←impl― [RepositoryAdapter] → [JpaRepository] → [MybatisMapper] → [JPAQueryFactory] (core) (core) (adapter) (adapter) 예시 @Repository @RequiredArgsConstructor public class ItemRepositoryAdapter implements ItemRepository { private final ItemJpaRepository itemJpaRepository; private final ItemMybatisMapper itemMybatisMapper; @Override public List<Item> findBySearchRequest(ItemSearchRequest request) { return itemMybatisMapper.findBySearchRequest(request) .stream() .map(Item::from) .toList(); } @Override public List<Item> saveAll(List<Item> items) { return itemJpaRepository.saveAll(items); } } @Repository @RequiredArgsConstructor public class AuctionRepositoryAdapter implements AuctionRepository { private final JPAQueryFactory jpaQueryFactory; private final AuctionJpaRepository auctionJpaRepository; @Override public void deleteAllByRegionAndRealmId(RegionType region, Long realmId) { QAuction qAuction = QAuction.auction; BooleanBuilder filter = new BooleanBuilder(); filter.and(qAuction.region.eq(region)); if (realmId == null) { filter.and(qAuction.realmId.isNull()); } else { filter.and(qAuction.realmId.eq(realmId)); } jpaQueryFactory.delete(qAuction) .where(filter) .execute(); } @Override public int saveAll(List<Auction> auctions) { if (auctions.isEmpty()) return 0; return auctionJpaRepository.saveAll(auctions).size(); } } 이 구조를 선택한 이유 동적 쿼리, 벌크 연산 등 JPA만으로 해결하기 어려운 케이스가 있어 MyBatis와 QueryDSL을 병행 사용하고 있습니다. 일반적인 방식인 Port 인터페이스가 Spring Data JPA Repository를 상속하는 구조를 채택하지 않은 이유: MyBatis나 QueryDSL 기반 구현체를 만들 수 없음 CustomRepository 인터페이스를 별도로 만들어야 하는 복잡도 증가 현재 방식의 장점: Port 인터페이스가 순수 Java 인터페이스로 유지됨 RepositoryAdapter에서 상황에 맞는 기술을 자유롭게 조합 가능 추가 인터페이스 없이 단순한 구조 유지 저는 현재 구조가 의존 관계도 외부에서 내부로 향하고 테스트도 쉬워서 괜찮다고 생각하는데 토비님의 생각도 듣고싶습니다!! 좋은 강의 감사합니다!!
안녕하세요, 강사님덕분에 많이 배웁니다. 공부하면서 궁금한 내용이 있어 질문드립니다. FK 값 중복은 괜찮은거지? - 예시 규칙 1의 products(판매 상품) 가게 id(FK) 값 규칙 3 내용 중, 서비스를 중심으로 동사(팔다)를 골라 엔티티간 관계를 설정할 때 예시 2 내용입니다. 가게(stores), 판매상품(products) - 하나의 가계는 여러 개의 상품을 판다(팔수있다) 여기까지 이해를 했는데, 판매상품과 가게 관계에서 왜 '하나의 상품' 이라는 표현을 하는건가요? 여러개의 상품을 판다. 라고 벌써 정의 했으면서, 왜 하나의 상품이라고 하지? 여러개의 상품은 하나의 가게에 의해 팔린다. 라고 해야 하지 않나? 그래서 1:N 관계가 되는거 아니야? 그런 생각에 질의 드렸습니다. 감사합니다ㅡ
안녕하세요, 강사님. 이번 강의를 듣고 2가지 궁금증이 생겨 질문을 올리게 되었습니다. created_at 과 updated_at 구현 DB 레벨에서 ON UPDATE 와 DEFAULT CURRENT_TIMESTAMP 를 활용할 수 있다고 말씀해 주셨는데요, JPA에서는 @CreatedDate 와 @LastModifiedDate 로 애플리케이션 단에서 이를 구현할 수도 있습니다. 실무에서는 각각을 언제 사용할까요? 그리고 권장하는 구현이 따로 있으실까요? DB ENUM 타입을 잘 사용하지 않는 이유 실무에서 DB ENUM 데이터 타입 사용을 권장하지 않는다는 말씀으로 이해했습니다. 단순히 해당 ENUM 값의 범위가 변경되었을 때 이를 바꿔주는 것 이상으로 성능 이슈가 있어서라고 생각했습니다만, 정확히 알기가 어렵습니다. 자세한 설명을 부탁드려도 될까요? 감사합니다.
이런 식으로 실무적으로 접근했을 때 이 강의에서 예시를 들어주셨던 것처럼 (학생, 과목, 수강), (사용자, 영화, 평가) 엔티티를 개념적 모델링 단계에서 먼저 설계를 할텐데, 이때 설계 순서가 궁금합니다. (학생, 과목), (사용자, 영화) 와 같은 기본 엔티티를 먼저 만든 다음에 M:N 다대다 관계인 것을 확인하고 이것을 풀어내면서 동시에 비즈니스적 의미를 넣기 위해 중심(연관) 엔티티를 만드는 게 일반적인가요? 아니면 처음부터 학생 -> 수강 -> 과목 or 사용자 -> 평가 -> 영화 로 이어지도록 설계하는 게 일반적인가요?
package hellojpa; import javax.persistence.Entity; import javax.persistence.Id; @Entity public class Member { @Id private Long id; private String name; public Long getId() { return id; } public void setId(Long id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } } package hellojpa; import javax.persistence.EntityManager; import javax.persistence.EntityManagerFactory; import javax.persistence.EntityTransaction; import javax.persistence.Persistence; public class JpaMain { public static void main(String[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello"); EntityManager em = emf.createEntityManager(); EntityTransaction tx = em.getTransaction(); tx.begin(); Member member = new Member(); member.setId(1L); member.setName("HelloA"); em.persist(member); tx.commit(); em.close(); emf.close(); } } C:\Users\User\.jdks\temurin-21.0.9\bin\java.exe "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2025.2.2\lib\idea_rt.jar=65054" -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 -classpath C:\study\ex1-hello-jpa\ex1-hello-jpa\target\classes;C:\Users\User\.m2\repository\javax\xml\bind\jaxb-api\2.3.0\jaxb-api-2.3.0.jar;C:\Users\User\.m2\repository\org\hibernate\hibernate-entitymanager\ 5.3.10.Final \ hibernate-entitymanager-5.3.10.Final .jar;C:\Users\User\.m2\repository\org\jboss\logging\jboss-logging\ 3.3.2.Final \ jboss-logging-3.3.2.Final .jar;C:\Users\User\.m2\repository\org\hibernate\hibernate-core\ 5.3.10.Final \ hibernate-core-5.3.10.Final .jar;C:\Users\User\.m2\repository\org\javassist\javassist\3.23.2-GA\javassist-3.23.2-GA.jar;C:\Users\User\.m2\repository\antlr\antlr\2.7.7\antlr-2.7.7.jar;C:\Users\User\.m2\repository\org\jboss\jandex\ 2.0.5.Final \ jandex-2.0.5.Final .jar;C:\Users\User\.m2\repository\com\fasterxml\classmate\1.3.4\classmate-1.3.4.jar;C:\Users\User\.m2\repository\javax\activation\javax.activation-api\1.2.0\javax.activation-api-1.2.0.jar;C:\Users\User\.m2\repository\org\dom4j\dom4j\2.1.1\dom4j-2.1.1.jar;C:\Users\User\.m2\repository\org\hibernate\common\hibernate-commons-annotations\ 5.0.4.Final \ hibernate-commons-annotations-5.0.4.Final .jar;C:\Users\User\.m2\repository\javax\persistence\javax.persistence-api\2.2\javax.persistence-api-2.2.jar;C:\Users\User\.m2\repository\net\bytebuddy\byte-buddy\1.9.5\byte-buddy-1.9.5.jar;C:\Users\User\.m2\repository\org\jboss\spec\javax\transaction\jboss-transaction-api_1.2_spec\ 1.1.1.Final \jboss-transaction-api_1.2_ spec-1.1.1.Final .jar;C:\Users\User\.m2\repository\com\h2database\h2\1.4.199\h2-1.4.199.jar hellojpa.JpaMain 1월 13, 2026 3:42:37 오후 org.hibernate.jpa.internal.util.LogHelper logPersistenceUnitInformation INFO: HHH000204: Processing PersistenceUnitInfo [ name: hello ...] 1월 13, 2026 3:42:37 오후 org.hibernate.Version logVersion INFO: HHH000412: Hibernate Core { 5.3.10.Final } 1월 13, 2026 3:42:37 오후 org.hibernate.cfg.Environment <clinit> INFO: HHH000206: hibernate.properties not found 1월 13, 2026 3:42:37 오후 org.hibernate.annotations.common.reflection.java .JavaReflectionManager <clinit> INFO: HCANN000001: Hibernate Commons Annotations { 5.0.4.Final } 1월 13, 2026 3:42:38 오후 org.hibernate.engine.jdbc.connections.internal.ConnectionProviderInitiator initiateService WARN: HHH000181: No appropriate connection provider encountered, assuming application will be supplying connections 1월 13, 2026 3:42:38 오후 org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator initiateService WARN: HHH000342: Could not obtain connection to query metadata : The application must supply JDBC connections 1월 13, 2026 3:42:38 오후 org.hibernate.dialect.Dialect <init> INFO: HHH000400: Using dialect: org.hibernate.dialect.H2Dialect 1월 13, 2026 3:42:38 오후 org.hibernate.engine.jdbc.env.internal.LobCreatorBuilderImpl makeLobCreatorBuilder INFO: HHH000422: Disabling contextual LOB creation as connection was null Exception in thread "main" java.lang.UnsupportedOperationException: The application must supply JDBC connections at org.hibernate.engine.jdbc.connections.internal.UserSuppliedConnectionProviderImpl.getConnection(UserSuppliedConnectionProviderImpl.java:44) at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:35) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:106) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:136) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:254) at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:262) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:236) at org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:86) at hellojpa.JpaMain.main(JpaMain.java:16) Process finished with exit code 1 이거 에러 발생한 이유가 뭘까요? 강의 러닝타임은 11분대입니다.
안녕하세요 강의 너무 잘 듣고 있습니다. lag와 lead 함수에서 offset은 row 단위로밖에 설정을 못하는 걸까요? hiredate를 기준으로 order by 했을 때 day를 기준으로 offset을 설정할 수 있는지 궁금합니다. ex) lag를 이용하여 1일전 매출을 가져오는 방법
안녕하세요, 좋은 강의 항상 감사드립니다. 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
사용자가 캘린더를 보유했는지 여부로 확인할 것 같습니다. 이유는 추후 서비스 확장할 때 조금 더 수월할 것 같다는 생각이 들었습니다. 프로젝트를 시작하면서부터 아래와 같은 생각을 했습니다. - "누구나 호스트가 되면 안될까?" - "호스트 역시도 커피챗을 신청할 수 있게 하고 싶다." 그래서 위와 같이 서비스 정책을 확장할 때를 대비해서 (마이그레이션 비용을 줄이는 방향으로) is_host로 검사하는 것이 아닌 일단 캘린더 보유 여부로 호스트인지 아닌지 확인하자라고 판단했습니다.