Programming

Mybatis와 JPA가 무엇인가?

eatingmouse — Wed, 4 Mar 2026 11:58:01 +0900

필자가 한참 취준생으로 바빴던 시절, 취업공고로 자주 걸려있던 문구가 있다.

필수 기술: Mybatis

그 당시에 JPA만 사용해봤던 나였기에 머리위로 물음표가 떠올랐다.

Mybatis가 뭔데?

지금이야 Mybatis를 다루는 회사를 다니고 있기도 하고 여러번 만져봤기에 익숙해지긴 했지만 그 당시에는 미숙했다.

JPA에 대한 감각이 무뎌지고 있기도하고 과거의 무지함에 대한 반성에 대한 의미로 Mybatis와 JPA의 개념에 대해 다시한번 확고히 짚고 넘어가려고한다.

Mybatis, JPA가 무엇이냐!

데이터 베이스 접근 계층을 구축해주는 프레임워크다.

즉, 자바 프로그램과 데이터베이스 사이를 이어주는 다리 역할을 수행한다.

Mybatis와 JPA의 본질적인 기능은 완전히 동일하지만, 데이터를 어떻게 바라보는지에 대해 차이점이 분명히 존재한다.

Mybatis는 mapper를 통해 직접적인 쿼리를 짜고, DAO를 통해 연결하며 IF와 IMPL을 통해 서비스를 구축한다.

즉, 개발자가 모든 경로를 직접적으로 연결시킬 수 있다.

그에 비해 JPA는 Entity라는 자바객체를 통해 껍데기를 만들고, Repository를 통해 만들어낸 Entity를 데이터베이스에 연결한다.

쿼리 자체를 커스텀마이징할 수 있긴하지만, 대부분의 경로(쿼리)는 자동으로 생성되며, 사용자는 생성된 기능을 서비스에서 사용만 하면 된다.

즉, 개발자가 쿼리에 얼마나 관여를 하냐가 JPA와 Mybatis를 가르는 큰 차이점이라고 볼 수 있다.

자동으로 생성되는 JPA가 현대식이고, 쿼리를 개발자가 전부 신경써줘야하는 Mybatis는 너무 구시대적이지 않냐고 생각할수도 있는데, 전혀 그렇지 않다.

대규모의 쿼리를 다루거나, 성능 최적화에 대해 신경쓰는 등 개발자가 직접적으로 데이터베이스에 영향을 끼칠 필요가 있는 시스템에는 Mybatis가 어울리고, 데이터구조가 빠르게 바뀌거나 기능을 빠르게 만들어내는 등 속도가 중요한곳에서는 JPA가 훨씬 유리하다.

둘 다 나쁘지 않는 프레임워크지만, 사용하는 방법이 다르고 상황에 맞게 어울리는 프레임워크를 사용해야한다.

자바스크립트를 수정해도 캐시데이터를 삭제하지 않으면 적용되지 않는 문제..

eatingmouse — Tue, 27 Jan 2026 15:07:52 +0900

자바 스프링과 JSP를 사용하는 환경에서 기존에 사용되던 자바스크립트를 수정하던 중, 문제가 발생했다.

기존에 사용하던 고객분께서 캐시데이터를 삭제하지 않으면, 변경된 자바스크립트가 반영되지 않는 문제였다.

관련해서 문제를 알아봤는데, 결과부터 말하자면 브라우저의 정적자원 캐싱 메커니즘이 문제라고한다.

브라우저는 매번 서버에서 용량이 큰 JS, CSS파일 등을 받아오면 속도가 느려지기 때문에, 한 번 받은 파일은 컴퓨 로컬 저장소에 저장하고 사용한다고 한다.

때문에, 파일명이 동일할경우 과거버전과 수정 후 버전을 브라우저에서 인식하지 못하는 문제가 발생한다.

해결방법은 생각보다도 간단하다.

자바스크립트를 호출할때, 자동으로 바뀔 수 있도록 인자값을 넣어주면 된다.

예시)

<script src="<c:url value='/js/test.js' />?v=${now}"></script>      /* 날짜를 통해 버전명을 동적으로 부여하는 방법 */
<script src="<c:url value='/js/a1b2c3.test.js'"/></script>         /*  빌드 도구(Webpack, Vite, Jenkins 등)를 사용하여 파일 이름에 해시코드를 섞는방법 */

그 밖에도 방법은 많으니 자유껏 사용하면 된다.

개발자로서 해선 안될 버릇들..(닌자 코드)

eatingmouse — Fri, 2 Jan 2026 13:29:05 +0900

웹서핑을 하던 중 재밌는글을 발견했다.

https://ko.javascript.info/ninja-code

닌자 코드

ko.javascript.info

위 사이트에서는 '닌자'(고위 개발자)가 되는 방법이 적혀있는 사이트인데,

개발자가 가져서 안될 버릇들을 반어법을 사용해 재미있게 풀어놓았다.

유머성이 짙은 글이지만, 실무에서도 도움이 될 만한 내용이 가득하니, 한번쯤 들어가서 읽어보면 좋을 듯 하다.

의존성주입 구현

eatingmouse — Wed, 3 Dec 2025 10:26:42 +0900

Spring에서 의존성을 구현할때에는 크게 3가지 방법으로 나뉜다.

1. 필드 주입

@Controller
public class AutoTestingController extends CommonController {
	@Autowired 
	private PsyItemVerIF psyItemVerIF; 
}

- 필드에 있는 변수에 @Autowired를 붙여 리플렉션을 통해 의존성을 주입하는 방법이다.

Spring은 컨테이너에서 @Autowire가 붙은 서비스타입의 빈을 찾아 의존성주입을 시킨다.

짧고 간단하게 의존성주입을 할 수 있지만 final을 붙일 수 없어 불변성을 보장할 수 없고, private를 통해 직접적으로 접근할 수 있

어 객체지향의 캡슐화 원칙을 위반한다.(유지보수 및 보안성 위험)

대부분의 프로그래머들이 권장하는 방법은 아니다.

2. 생성자 주입

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;

@Controller
@RequiredArgsConstructor
public class AutoTestingController extends CommonController {

	private final PsyItemVerIF psyItemVerIF; 
    
}

- 객체가 생성되는 지점에 매개변수를 통해 의존성을 주입하는 방법이다.

lombok 라이브러리를 통해 사용하면 짧은 코드로 구현이 가능하며, final를 통해 불변성의 보장이 가능하다.

대부분이 권장하는 방법이다.

3. Setter 주입

@Controller
public class MyController {
    
    private MyService myService;

    @Autowired 
    public void setMyService(MyService myService) { 
        this.myService = myService;
    }
}

- 공개적인 Setter를 통해 함수를 구현하고 필드에 의존성을 주입하는 방법이다.

필드 주입과 동일하게 final를 사용하지 못해 불변성이 보장이 안되지만, 선택적 의존성과 객체 변경이 가능하다는 점에서

의의를 둘 수 있다.

필수적이지 않은 의존성을 다루거나 런타임 변경 가능성이 있는 등 특수한 경우에 사용되는걸 보통 권장한다.

자바스프링 프로젝트 컨테이너화 및 배포하기 #3 배포하기

eatingmouse — Thu, 10 Apr 2025 14:28:39 +0900

이제, 태그지정까지 마쳤으니 지정된 컨테이너를 Gcloud에 Push시켜주어야한다.

docker push gcr.io/YOUR_PROJECT_ID/spring-app:latest

성공적으로 push를 마쳤다면, 다음과 같은 명령어로 클라우드 배포를 할 수 있다.

gcloud run deploy 도커의 이미지명 --image 태그한 이미지명 --allow-unauthenticated --add-cloudsql-instances slq인스턴스명

Cloud가 정상적으로 실행됐다면 CloudRun의 로그를 통해 프로젝트가 보내오는 로그를 받아올 수 있다.

자바스프링 프로젝트 컨테이너화 및 배포하기 #2 Docker 설정

eatingmouse — Thu, 10 Apr 2025 14:18:29 +0900

이제, 클라우드의 설정을 마쳤으니 이번에는 프로젝트를 컨테이너화 시키기 위해 프로젝트의 Docker설정이 필요하다.

우선, 자신이 원하는 경로에 맞춰 Docker 파일을 생성시켜주어야 하는데, 필자같은 경우에는 다음과 같은 경로로 설정했다.

그리고서는 Docker파일 및 sql설정을 위한 docker-compose.yml를 작성해주자.

Dockerfile

FROM ubuntu:latest
LABEL authors="autohrs"

ENTRYPOINT ["top", "-b"]

# OpenJDK 17을 기반으로 사용
FROM openjdk:17

# 작업 디렉터리 설정
WORKDIR /app

# 현재 프로젝트의 JAR 파일을 컨테이너로 복사
COPY build/libs/*.jar app.jar

# 8080 포트 노출
EXPOSE 8080

# 컨테이너에서 실행할 명령어
CMD ["java", "-jar", "app.jar"]

docker-compose.yml

version: '3.8'

services:
  db:
    image: mysql:latest
    container_name: mysql_db
    restart: always
    environment:
      MYSQL_DATABASE: book_manage
      MYSQL_USER: user
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: rootpassword
    ports:
      - "3307:3306"
    networks:
      - app-network

  app:
    image: bookmanage-spring-app:latest
    build: .
    container_name: spring_app
    restart: always
    depends_on:
      - db
    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://ip주소/인스턴스ID?useSSL=false&characterEncoding=UTF-8&serverTimezone=UTC
      SPRING_DATASOURCE_USERNAME: username
      SPRING_DATASOURCE_PASSWORD: password
    ports:
      - "8080:8080"
    networks:
      - app-network

networks:
  app-network:

username과 password같은 설정은 이전에 sqlcloud에서 설정한대로 가져오면되며, 포트번호같은경우에는 3306:3306으로 할시 중복되는 상황이 나와 3307:3306으로 해두었다.

Spring_datasource_url과 같은 경우에는 이전에 만들어두었던 sql인스턴스에서 가져와줘야한다.

후에는 application.properties에도 sqlcloud의 설정과 맞춰 변경시켜주자.

spring.datasource.url=jdbc:mysql://ip주소/인스턴스ID?useSSL=false&characterEncoding=UTF-8&serverTimezone=UTC
spring.datasource.username=username
spring.datasource.password=rootpassword

이제, 프로젝트를 컨테이너화할 차례인데 우선, 다음과 같은 명령어를 터미널에 입력하여 .jar파일을 만들어야한다.

./gradlew build

jar파일이 생성되면 다음과 같은 명령어를 통해 프로젝트를 컨테이너화 시켜주자.

docker-compose up --build -d

그리고, gcloud에 올릴 수 있도록 다음과 같은 명령어로 컨테이너에 태그를 지정하면 마무리다.

docker tag 컨테이너명 gcr.io/클라우드 인스턴스 ID/컨테이너명:latest

*클라우드 sql연동 참조 블로그*

https://velog.io/@alstjsdlr0321/Spring-Boot-GCP-Cloud-SQL-DB-%EC%97%B0%EB%8F%99

자바스프링 프로젝트 컨테이너화 및 배포하기 #1 클라우드 설정

eatingmouse — Thu, 10 Apr 2025 13:41:55 +0900

이번에는 저번에 만들었던 북길 프로젝트를 클라우드 배포하는 과정을 포스팃할 생각이다.

필자의 경우에는 프로젝트를 컨테이너화 시킬때에는 Docker를 활용했으며, cloud run을 통해 프로젝트를 배포할 생각이다.

우선, 프로젝트를 컨테이너화 시키기전에 프로젝트를 가동시킬 클라우드의 설정이 필요하다.

https://cloud.google.com/?hl=ko

cloud.google.com

구글 클라우드 사이트에 들어가고, 콘솔에 들어간뒤 새로운 프로젝트를 만들어줘야한다.

프로젝트ID는 후에 자주사용되며, 프로젝트명이 프로젝트 ID의 생성에 영향을 끼치기 때문에 프로젝트명을 직관성있게 만들어주는게 좋다.

cloud run은 서버리스 컨테이너로, 다른 클라우드와 달리 콘솔을 통해 클라우드에 접속해 mysql을 설정하는 방법을 사용하기 어렵다.

때문에 구글 클라우드에서 제공하는 sql클라우드를 사용해야한다.

위의 이미지대로, 검색창을 통해 클라우드 sql에 접근한뒤, 인스턴스 만들기를 통해 인스턴스를 만들어준다.

후에는 무슨 데이터베이스를 사용할지 정하고 인스턴스 정보를 설정해야한다.

인스턴스 ID와 비밀번호는 후에 Root로 접속할때 사용하기에 꼼꼼하게 체크해야되며, 리전 영역은 가능한 거주하고 있는 국가와 일치하게 해주는게 좋다.

후에는 Iam에 들어가서, 필요에 따라 자신의 계정에 권한을 쥐어주자.

https://cloud.google.com/sdk?hl=ko

cloud.google.com

그리고, 클라우드에서 명령어를 넣어주어주기 위해 위의 사이트에 들어가 CLI를 설치해주자.

CLI의 설치를 마쳤다면, GoogleCloudShell이 생겼을것이다.

GoogleCloudShell를 통해 접속을 하고, gcloud auth login를 통해 로그인 및 하고자 하는 프로젝트를 연동시켜주자.

프로젝트 연동을 위해서는 프로젝트의 ID값이 필요한데, 프로젝트 선택하는 창에서 볼 수 있다.

이제, 성공적으로 로그인 및 클라우드 연동이 끝났다면, 이번에는 sql을 건드려줘야한다.

우선, 다음과 같은 명령어를 통해 sql에 접속해주자.

gcloud sql connect [INSTANCE_ID] --user=root

그리고, 프로젝트의 설정에 맞춰 프로젝트를 생성시켜주고, 생성후에는 다음과 같은 명령어로 유저생성 및 권한 부여를 해주자.

사용자생성:

CREATE USER '유저'@'%' IDENTIFIED BY '비밀번호';

권한부여:

GRANT ALL PRIVILEGES ON 데이터베이스명.* TO 'bookmanage_user'@'%';
FLUSH PRIVILEGES;

<button>을 통해 <script>영역으로 값을 전달

eatingmouse — Fri, 14 Feb 2025 13:07:13 +0900

프로젝트를 진행하던 도중 또 다른 문제가 발생했다.

<button th:attr="onclick='bookmarkBook(\''
        + ${book.bookTitle} + '\', \''
        + ${book.bookAuth} + '\', \''
        + ${book.bookPub} + '\', \''
        + ${book.bookPubYear} + '\', \''
        + ${#strings.length(book.des) > 0 ? #strings.substring(book.des, 0, (book.des.length() > 400 ? 400 : book.des.length())) + (book.des.length() > 400 ? '...' : '') : ''} + '\', \''
        + ${book.discount} + '\', \''
        + ${book.ISBN} + '\', \''
        + ${book.img} + '\')'">북마크
</button>

위의 코드와 같이 button을 눌렀을 때 인자값을 <script>영역으로 넘겨주려다가 book.des에 ' '나 ()등 특수기호들이 들어가 스크립트가 정상적으로 작동되지 않았다.

후에 인터넷 서핑 및 서적을 통해 찾아보니 위와 같이 버튼에 직접적으로 인자를 넘겨주는 행위가 보안면에서 좋은 방법은 아니라는걸 알게됐다(...)

<button th:data-title="${book.bookTitle}"
        th:data-auth="${book.bookAuth}"
        th:data-pub="${book.bookPub}"
        th:data-pubyear="${book.bookPubYear}"
        th:data-des="${book.des != null and book.des.length() > 0 ? #strings.substring(book.des, 0, (book.des.length() > 100 ? 100 : book.des.length())) + (book.des.length() > 100 ? '...' : '') : ''}"
        th:data-discount="${book.discount}"
        th:data-isbn="${book.ISBN}"
        th:data-img="${book.img}"
        onclick="bookmarkBook(this)">북마크
</button>

다른 사이트를 참고해, 위의 코드와 같이 data속성을 저장하여 script로 전달해주는 방법으로 변경했다.

Lombok 생성자 생성안됨 문제

eatingmouse — Wed, 12 Feb 2025 17:20:43 +0900

프로젝트를 진행하던 도중 @Data어노테이션을 사용하는데 Setter가 정상적으로 작동하지 않는 문제가 발생했다.

@Data어노테이션은 Getter과 Setter와 생성자까지 전부 자동으로 생성해주기 때문에 무엇이 문제인지 헷갈려 하던도중

생성자를 명시적으로 생성해주니 해결되었다.

@Data
public class BookResponseDto {
    private int totalResults;
    private List<BookDto> bookLists;

    public BookResponseDto(int totalResults, List<BookDto> bookLists) {
        this.totalResults = totalResults;
        this.bookLists = bookLists;
    }
}

아마 변수에 BookDto라는 복합적인 객체 타입을 인식하지 못하고 자동적으로 생성자를 생성하지 못해 생긴 문제라고 생각된다.

java.lang.IllegalArgumentException: The Unicode character at code point [49,548] cannot be encoded as it is outside the permitted range of 0 to 255

eatingmouse — Sat, 8 Feb 2025 19:29:23 +0900

프로젝트를 진행하던중 이번에는 한글이 담겨진 데이터를 타임리프로 만들어진 프론트로 보내주는 과정에서 오류가 발생했다.

오류를 해결하기 위해서는 다음의 코드를 application.properties에 등록하는것이 가장 보편적이지만

spring.http.encoding.charset=UTF-8
spring.http.encoding.enabled=true
spring.http.encoding.force=true

필자는 등록을 해줬음에도 해결이 되지 않았다.

그래서 필자는 스프링에서 변환시켜주는것보다 데이터를 전달해줄 때 직접적으로 인코딩 방식을 지정을 해주는 방식을 채택했고 코드는 다음과 같다.

return "redirect:/example?keyword=" + URLEncoder.encode(keyword, StandardCharsets.UTF_8);

위와 같이 인코드 방식을 UTF-8로 직접적으로 지정해주니 문제없이 작동됐다.