새벽 4시 반에 눈을 뜨면, 세수하고 옷을 챙겨 입은 뒤 집을 나선다. 학원에 도착하면 대략 6시 10분쯤이고, 참치 김밥이나 빵으로 간단히 아침을 해결한다. 컴퓨터 앞에 앉아 오늘 해야 할 일을 고민하다 보면, 문득 다른 분들이 만든 메인 페이지, 카카오 결제, 회원 가입·로그인 화면을 보며 ‘나도 저렇게 만들 수 있을까?’ 하는 생각이 든다.
내가 맡은 상품 파트는 쇼핑몰 전반에서 가장 중요한 부분 중 하나라 반드시 완성해야 한다는 책임감을 느낀다.
그래서 아침마다 나에게 묵묵히 외친다.
“나는 할 수 있다. 할 수 있어야 한다. 해야만 한다.”
6월 18일
6월 18일에는 IntelliJ Database 콘솔에서 MySQL DDL 실행 중 인코딩 문제와 권한 오류를 해결했다. 외래 키 제약 때문에 테이블 삭제가 안 돼서 다음과 같이 처리했다:
SET FOREIGN_KEY_CHECKS = 0;
DROP TABLE ITEM;
SET FOREIGN_KEY_CHECKS = 1;6월 19일
6월 19일에는 도메인(Entity) 클래스와 DTO의 패키지 구조를 정리했다.
• src/main/java/com/example/domain에 Entity 클래스 배치
• src/main/java/com/example/dto에 DTO 클래스 분리
또한 MyBatis 매핑 과정에서 Setter가 필요함을 확인했고, Getter만 있을 경우 프로퍼티 주입 오류가 발생한다는 것을 배웠다.
6월 20일
6월 20일에는 HTTP 404 에러의 원인을 점검했다.
1. WAR 파일 이름 기반 컨텍스트 경로 확인
2. Controller에 @GetMapping("/detail") 선언 여부 검사
3. DispatcherServlet의 매핑 패턴(*.do 등) 점검
4. ViewResolver(prefix/suffix) 설정과 JSP 파일 위치(/WEB-INF/views/item/detail.jsp) 최종 확인
이 네 가지를 차례로 점검해 문제를 해결했다.
6월 21일
6월 21일에는 다음 두 가지를 정리했다.
-
JPA Repository vs MyBatis Mapper
• Spring Data JPA의 JpaRepository<T, ID> ↔ MyBatis의 Mapper 인터페이스(@Mapper)
• XML 매퍼와 애노테이션(@Select/@Insert 등) 방식
• @MapperScan 설정 또는 MapperScannerConfigurer 사용 방법 -
MyBatis와 JPA의 주요 차이점
• ORM vs SQL 매핑
• JPA는 엔티티 객체를 기준으로 SQL을 자동 생성하는 ORM 방식이었는데,
• MyBatis는 개발자가 직접 SQL을 작성하고 결과를 매핑하는 매핑 프레임워크였다.
• 쿼리 제어력
• JPA는 메소드 이름 전략이나 JPQL을 활용해서 간단한 CRUD는 편리했는데, 복잡한 조인은 다소 불편했다.
• MyBatis는 복잡한 SQL을 XML 혹은 애노테이션에 그대로 작성할 수 있어서 세밀한 제어가 가능했다.
• 런타임 동작 방식
• JPA는 1차 캐시(EntityManager)와 영속성 컨텍스트를 이용해 객체 상태를 관리했는데,
• MyBatis는 매번 SQL을 실행하고 결과를 DTO/도메인에 매핑했으며, 별도의 캐시 설정이 필요했다.
• Lazy Loading
• JPA는 연관 엔티티를 지연 로딩으로 가져올 수 있었고 프록시 객체를 사용했는데,
• MyBatis는 지연 로딩을 사용하려면 추가 설정(association fetchType="lazy")이 필요했다.
• 트랜잭션 관리
• 둘 다 Spring의 @Transactional을 동일하게 적용할 수 있었지만,
• JPA는 변경 감지(Dirty Checking)를 활용해 트랜잭션 커밋 시 자동으로 UPDATE 쿼리를 실행했다.
• 학습 곡선
• JPA는 개념(엔티티 라이프사이클, 래지스트리 등)이 많아 진입 장벽이 있었는데,
• MyBatis는 SQL 중심이어서 SQL에 익숙한 개발자에게 더 직관적이었다.
