10장에서 다룰 내용:

• JPQL
• Criteria
• QueryDSL
• 네이티브 SQL
• 객체지향 쿼리 심화

1. 객체지향 쿼리 소개

JPA는 다양한 쿼리 방법을 지원한다. 핵심은 "테이블이 아닌 엔티티 객체를 대상으로 쿼리한다"는 점이다.

JPA가 지원하는 쿼리 방식:

• JPQL: 가장 기본이 되는 객체지향 쿼리 언어
• Criteria: JPQL을 자바 API로 작성하는 방식
• QueryDSL: Criteria보다 훨씬 간결하고 직관적인 오픈소스 라이브러리
• 네이티브 SQL: SQL을 직접 사용
• JDBC 직접 사용: JDBC, MyBatis 등을 JPA와 함께 사용

실무에서는 JPQL을 기본으로 쓰고, 필요에 따라 Criteria나 QueryDSL을 조합한다.

2. JPQL

JPQL 문법은 SQL과 유사하다. SELECT, UPDATE, DELETE를 지원한다.

• SELECT 기본 예시

// 기본 조회
SELECT m FROM Member AS m WHERE m.age > 18

TypeQuery, Query

em.createQuery()의 반환 타입에 따라 두 가지로 나뉜다.

TypeQuery: 반환 타입이 명확할 때

TypedQuery<Member> query =
    em.createQuery("SELECT m FROM Member m", Member.class);

List<Member> resultList = query.getResultList();
for (Member member : resultList) {
    System.out.println("member = " + member);
}

Query: 반환 타입이 여러 개일 때

Query query =
    em.createQuery("SELECT m.username, m.age FROM Member m");

List resultList = query.getResultList();
for (Object o : resultList) {
    Object[] result = (Object[]) o; // 결과가 여러 타입이면 Object[]
    System.out.println("username = " + result[0]);
    System.out.println("age = " + result[1]);
}

결과 조회 API

query.getResultList();    // 결과가 없으면 빈 컬렉션 반환
query.getSingleResult();  // 결과가 정확히 1개일 때 사용

파라미터 바인딩

이름 기준 파라미터 (권장):

List<Member> members =
    em.createQuery("SELECT m FROM Member m WHERE m.username = :username", Member.class)
      .setParameter("username", usernameParam)
      .getResultList();

위치 기준 파라미터 (비권장):

List<Member> members =
    em.createQuery("SELECT m FROM Member m WHERE m.username = ?1", Member.class)
      .setParameter(1, usernameParam)
      .getResultList();

이름 기준 파라미터를 사용하는 것이 훨씬 명확하고 유지보수에 유리하다. 위치 기준은 순서가 바뀌면 버그가 생기기 쉽다.

프로젝션 (Projection)

SELECT 절에서 조회할 대상을 지정하는 것을 프로젝션이라 한다.

// 엔티티 프로젝션 - 엔티티 전체 조회
SELECT m FROM Member m        // Member 엔티티
SELECT m.team FROM Member m   // 연관 엔티티 Team 조회

• 임베디드 타입 프로젝션:

String query = "SELECT a FROM Address a";
// 단, 임베디드 타입은 독립적으로 조회 불가 → 엔티티를 통해 조회해야 함

String query = "SELECT o.address FROM Order o";

• 스칼라 타입 프로젝션 (단순 값 조회)

// 단일 타입
List<String> usernames =
    em.createQuery("SELECT m.username FROM Member m", String.class)
      .getResultList();

// DISTINCT로 중복 제거
SELECT DISTINCT m.username FROM Member m

// 집합 함수
SELECT AVG(o.orderAmount) FROM Order o

• 여러 값 조회: 반환 타입이 다를 경우 Object[]로 받는다:

// Object[] 방식
List<Object[]> resultList =
    em.createQuery("SELECT m.username, m.age FROM Member m")
      .getResultList();

for (Object[] row : resultList) {
    String username = (String) row[0];
    Integer age     = (Integer) row[1];
}

• 명령어로 DTO 직접 조회 (권장) Object[]보다 DTO로 바로 받는 방식이 더 깔끔하다:

public class UserDTO {
    private String username;
    private int age;

    public UserDTO(String username, int age) {
        this.username = username;
        this.age = age;
    }
}

TypedQuery<UserDTO> query =
    em.createQuery(
        "SELECT new jpabook.jpql.UserDTO(m.username, m.age) FROM Member m",
        UserDTO.class
    );

페이징 API

JPA는 페이징을 두 가지 API로 추상화한다. DB마다 다른 페이징 SQL을 자동으로 생성해준다.

TypedQuery<Member> query =
    em.createQuery("SELECT m FROM Member m ORDER BY m.username DESC", Member.class);

query.setFirstResult(10);  // 조회 시작 위치 (0부터 시작)
query.setMaxResults(20);   // 조회할 데이터 수
query.getResultList();     // 11번째부터 20개 조회

→ DB별로 생성되는 SQL이 다르다. JPA가 알아서 변환해준다.

집합과 정렬

• 집합 함수

SELECT
    COUNT(m),    -- 회원 수 (반환: Long)
    SUM(m.age),  -- 나이 합 (반환: Long)
    AVG(m.age),  -- 평균 나이 (반환: Double)
    MAX(m.age),  -- 최대 나이
    MIN(m.age)   -- 최소 나이
FROM Member m

• GROUP BY / HAVING

SELECT t.name, COUNT(m.age), SUM(m.age), AVG(m.age), MAX(m.age), MIN(m.age)
FROM Member m LEFT JOIN m.team t
GROUP BY t.name

• ORDER BY

SELECT t.name, COUNT(m.age) AS cnt
FROM Member m LEFT JOIN m.team t
GROUP BY t.name
ORDER BY cnt

조인 (JOIN)

• 내부 조인 (INNER JOIN)

String query = "SELECT m FROM Member m INNER JOIN m.team t WHERE t.name = :teamName";

List<Member> members = em.createQuery(query, Member.class)
    .setParameter("teamName", "팀A")
    .getResultList();

• 외부 조인 (LEFT OUTER JOIN)

SELECT m FROM Member m LEFT [OUTER] JOIN m.team t

페치 조인 (Fetch Join)

페치 조인은 JPQL에서 성능 최적화를 위해 제공하는 특별한 조인이다. 연관 엔티티를 SQL 한 번에 함께 조회한다. 지연 로딩으로 설정해도 페치 조인을 사용하면 즉시 함께 로딩된다.

• 엔티티 페치 조인:

// JPQL
SELECT m FROM Member m JOIN FETCH m.team

→ 실행 SQL:

SELECT M.*, T.*
FROM MEMBER M INNER JOIN TEAM T ON M.TEAM_ID = T.ID

일반 조인과 다르게, 페치 조인은 연관 엔티티까지 함께 SELECT 절에 포함해서 가져온다. member.getTeam()을 호출해도 추가 쿼리가 발생하지 않는다.

• 컬렉션 페치 조인

select t from Team t join fetch t.members where t.name = '팀A'

→ 실행 SQL:

SELECT T.*, M.*
FROM TEAM T INNER JOIN MEMBER M ON T.ID = M.TEAM_ID
WHERE T.NAME = '팀A'

일대다 조인이므로 팀A에 회원이 2명이면 결과 row가 2개 나온다. 즉 팀 객체가 중복으로 조회될 수 있다.

• 페치 조인과 DISTINCT: 컬렉션 페치 조인 시 중복 결과를 제거하려면 DISTINCT를 사용한다.

select distinct t from Team t join fetch t.members where t.name = '팀A'

• 일반 조인 vs 페치 조인 차이

// 일반 조인 → SELECT 절에 Team만 포함, members는 미로딩
select t from Team t join t.members m where t.name = '팀A'

// 페치 조인 → SELECT 절에 Team + Member 모두 포함
select t from Team t join fetch t.members where t.name = '팀A'

페치 조인 한계

• 페치 조인 대상에는 별칭을 줄 수 없다 (Hibernate는 가능하나 권장하지 않음)
• 둘 이상의 컬렉션을 페치 조인할 수 없다 (MultipleBagFetchException 발생)
• 컬렉션 페치 조인 시 페이징 API(setFirstResult, setMaxResults)를 사용할 수 없다 → 전체 데이터를 메모리에 올려 페이징하므로 위험

경로 표현식

.을 통해 객체 그래프를 탐색하는 것이다.

select m.username   // 상태 필드
from Member m
    join m.team t   // 단일 값 연관 필드
    join m.orders o // 컬렉션 값 연관 필드
where t.name = '팀A'

경로 표현식의 3가지 종류:

서브쿼리

JPQL도 SQL처럼 서브쿼리를 지원한다. WHERE, HAVING 절에서 사용 가능하다 (SELECT, FROM 절에서는 불가).

조건식

JPQL에서 사용하는 기본 조건식들이다.

타입 표현:

상속 관계와 TYPE, TREAT

• TYPE: 상속 관계에서 특정 하위 타입만 조회할 때 사용한다.

// Item의 하위 타입 중 Book, Movie만 조회
// JPQL
select i from Item i where type(i) IN (Book, Movie)

// 실행 SQL (단일 테이블 전략 기준)
SELECT i FROM Item i WHERE i.DTYPE in ('B', 'M')

• TREAT: 상속 구조에서 부모 타입을 자식 타입으로 다운캐스팅할 때 사용한다.

select i from Item i where treat(i as Book).author = 'kim'

사용자 정의 함수 (JPA 2.1)

DB 전용 함수나 커스텀 함수를 JPQL에서 사용하고 싶을 때:

// JPQL
select function('group_concat', i.name) from Item i

// Dialect에 등록
public class MyH2Dialect extends H2Dialect {
    public MyH2Dialect() {
        registerFunction("group_concat",
            new StandardSQLFunction("group_concat", StandardBasicTypes.STRING));
    }
}

엔티티 직접 사용

기본 키 값 대신 엔티티를 직접 파라미터로 사용할 수 있다. JPA가 자동으로 PK 비교로 변환한다.

// 엔티티를 직접 파라미터로
String qlString = "select m from Member m where m = :member";
List resultList = em.createQuery(qlString)
    .setParameter("member", member)  // 엔티티 직접 전달
    .getResultList();

// 실행 SQL → PK로 자동 변환
select m from Member m where m.id = ?

Named 쿼리: 정적 쿼리

JPQL은 동적 쿼리와 정적 쿼리로 나뉜다.

• 동적 쿼리: em.createQuery("...")처럼 런타임에 문자열로 만드는 방식
• 정적 쿼리 (Named 쿼리): 미리 이름을 붙여 정의해두는 방식 → 애플리케이션 로딩 시점에 문법 검증

@NamedQuery로 정의:

@Entity
@NamedQuery(
    name = "Member.findByUsername",
    query = "select m from Member m where m.username = :username"
)
public class Member {
    ...
}

사용:

List<Member> resultList = em.createNamedQuery("Member.findByUsername", Member.class)
    .setParameter("username", "회원1")
    .getResultList();

XML로 정의하는 방법도 있다:

<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings>
    <named-query name="Member.findByUsername">
        <query><![CDATA[
            select m from Member m where m.username = :username
        ]]></query>
    </named-query>

    <named-query name="Member.count">
        <query>select count(m) from Member m</query>
    </named-query>
</entity-mappings>

3. Criteria

JPQL을 자바 코드로 작성하는 API. 컴파일 시점에 오류를 잡을 수 있지만 코드가 복잡하다. 실무에서는 보통 QueryDSL을 더 선호한다.

기본 구조:

// JPQL: select m from Member m where m.username='회원1' order by m.age desc

CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Member> cq = cb.createQuery(Member.class);
Root<Member> m = cq.from(Member.class); // FROM

cq.select(m)
  .where(cb.equal(m.get("username"), "회원1"))  // WHERE
  .orderBy(cb.desc(m.get("age")));              // ORDER BY

List<Member> resultList = em.createQuery(cq).getResultList();

CriteriaBuilder는 em.getCriteriaBuilder()로 얻는다. Root는 조회 시작점(FROM 절의 엔티티)이다.

조회 (SELECT)

단일 타입 조회:

cq.select(m);  // JPQL: select m

여러 값 조회 (multiselect):

// JPQL: select m.username, m.age
cq.multiselect(m.get("username"), m.get("age"));

// 또는 cb.array() 사용
cq.select(cb.array(m.get("username"), m.get("age")));

Tuple 조회 (별칭으로 접근):

CriteriaQuery<Tuple> cq = cb.createTupleQuery();
Root<Member> m = cq.from(Member.class);

cq.multiselect(
    m.get("username").alias("username"),
    m.get("age").alias("age")
);

for (Tuple tuple : em.createQuery(cq).getResultList()) {
    String username = tuple.get("username", String.class);
    Integer age     = tuple.get("age", Integer.class);
}

GROUP BY / HAVING

// JPQL: select m.team.name, max(m.age), min(m.age) from Member m group by m.team.name

Expression<Integer> maxAge = cb.max(m.<Integer>get("age"));
Expression<Integer> minAge = cb.min(m.<Integer>get("age"));

cq.multiselect(m.get("team").get("name"), maxAge, minAge)
  .groupBy(m.get("team").get("name"))
  .having(cb.gt(minAge, 10));  // HAVING min(m.age) > 10

조인 (JOIN)

// JPQL: select m, t from Member m inner join m.team t where t.name = '팀A'

Root<Member> m = cq.from(Member.class);
Join<Member, Team> t = m.join("team", JoinType.INNER); // INNER / LEFT / RIGHT

cq.multiselect(m, t)
  .where(cb.equal(t.get("name"), "팀A"));

• 페치 조인:

m.fetch("team", JoinType.LEFT);
cq.select(m);

파라미터 바인딩

// JPQL: select m from Member m where m.username = :usernameParam

ParameterExpression<String> usernameParam = cb.parameter(String.class, "usernameParam");
cq.select(m).where(cb.equal(m.get("username"), usernameParam));

em.createQuery(cq).setParameter("usernameParam", "회원1").getResultList();

Criteria는 타입 안전하고 동적 쿼리 작성에 강점이 있지만, 코드가 길고 가독성이 떨어진다. 실무에서는 QueryDSL이 같은 장점을 훨씬 간결하게 제공하므로 더 많이 사용된다.

동적 쿼리

Criteria의 가장 큰 강점. 조건에 따라 쿼리를 동적으로 조립할 수 있다.

• JPQL 방식 (문자열 조합 → 지저분):

StringBuilder jpql = new StringBuilder("select m from Member m join m.team t");
List<String> criteria = new ArrayList<>();

if (age != null) criteria.add(" m.age = :age ");
if (username != null) criteria.add(" m.username = :username ");
if (teamName != null) criteria.add(" t.name = :teamName ");

if (!criteria.isEmpty()) jpql.append(" where ");
for (int i = 0; i < criteria.size(); i++) {
    if (i > 0) jpql.append(" and ");
    jpql.append(criteria.get(i));
}

• Criteria 방식 (타입 안전, 깔끔):

List<Predicate> predicates = new ArrayList<>();

if (age != null) predicates.add(cb.equal(m.<Integer>get("age"), cb.parameter(Integer.class, "age")));
if (username != null) predicates.add(cb.equal(m.get("username"), cb.parameter(String.class, "username")));
if (teamName != null) predicates.add(cb.equal(t.get("name"), cb.parameter(String.class, "teamName")));

cq.where(cb.and(predicates.toArray(new Predicate[0])));

메타모델 API

m.get("age")처럼 문자열로 필드를 참조하면 오타가 생겨도 컴파일 에러가 안 난다. 메타모델을 사용하면 Member_.age처럼 타입 안전하게 참조할 수 있다.

// 메타모델 사용 전
m.<Integer>get("age")

// 메타모델 사용 후 (타입 안전)
m.get(Member_.age)

메타모델 클래스(Member_)는 어노테이션 프로세서가 자동 생성한다. 실무에서는 빌드 도구 설정으로 자동화한다.

4. QueryDSL

Criteria의 복잡함을 해결한 오픈소스 라이브러리. JPQL과 거의 같은 문법을 자바 코드로 간결하게 작성할 수 있다.

설정

<dependency>
    <groupId>com.mysema.querydsl</groupId>
    <artifactId>querydsl-jpa</artifactId>
    <version>3.6.3</version>
</dependency>

QueryDSL도 Q 클래스를 자동 생성해야 한다. mvn compile 후 target/generated-sources에 생성된다.

기본 사용법

JPAQuery query = new JPAQuery(em);
QMember qMember = new QMember("m"); // Q 클래스 생성

List<Member> members = query
    .from(qMember)
    .where(qMember.name.eq("회원1"))
    .orderBy(qMember.name.desc())
    .list(qMember);

• 기본 인스턴스 사용 (권장):

// static import 활용
import static jpabook.jpashop.domain.QMember.member;

List<Member> members = query
    .from(member)
    .where(member.name.eq("회원1"))
    .list(member);

검색 조건

// where 절에 and 조건 나열
query.from(item)
    .where(item.name.eq("좋은상품"), item.price.gt(20000))
    .list(item);

// 다양한 조건 메서드
item.price.between(10000, 20000)       // BETWEEN
item.name.contains("상품")             // LIKE '%상품%'
item.name.startsWith("좋은")           // LIKE '좋은%'

결과 조회

query.list(item);          // 리스트 반환, 없으면 빈 컬렉션
query.uniqueResult(item);  // 단건, 없으면 null, 2개 이상이면 예외
query.singleResult(item);  // 단건, 없으면 null (uniqueResult와 유사)

페이징 / 정렬

query.from(item)
    .where(item.price.gt(20000))
    .orderBy(item.price.desc(), item.stockQuantity.asc())
    .offset(10).limit(20)
    .list(item);

그룹

query.from(item)
    .groupBy(item.price)
    .having(item.price.gt(1000))
    .list(item);

5. 네이티브 SQL

• JPQL이 아무리 강력해도 결국 한계가 있다. 특정 DB에서만 지원하는 기능, 예를 들어 오라클의 CONNECT BY나 SQL 힌트 같은 건 JPQL로 표현이 안 된다.

→ 이럴 때 쓰는 게 네이티브 SQL이다. JPA가 직접 SQL을 날릴 수 있도록 지원해주는 기능이다.

• JDBC로 직접 SQL을 쓰는 것과 차이가 있다. 네이티브 SQL을 쓰면 영속성 컨텍스트 기능은 그대로 사용할 수 있다. 단점은 특정 DB에 종속적인 쿼리를 작성하게 되므로 DB를 바꾸면 SQL도 바꿔야 한다는 것이다.

엔티티 조회

String sql = "SELECT ID, AGE, NAME, TEAM_ID FROM MEMBER WHERE AGE > ?";

Query nativeQuery = em.createNativeQuery(sql, Member.class)
    .setParameter(1, 20);

List<Member> resultList = nativeQuery.getResultList();

값 조회

엔티티가 아닌 여러 컬럼 값을 그냥 받고 싶을 때는 두 번째 파라미터 없이 호출하면 된다.

String sql = "SELECT ID, AGE, NAME FROM MEMBER WHERE AGE > ?";

Query nativeQuery = em.createNativeQuery(sql)
    .setParameter(1, 20);

List<Object[]> resultList = nativeQuery.getResultList();

for (Object[] row : resultList) {
    String id   = (String) row[0];
    int    age  = (Integer) row[1];
    String name = (String) row[2];
}

결과 매핑 사용

엔티티와 스칼라 값을 함께 조회하는 복잡한 경우엔 @SqlResultSetMapping을 써서 매핑을 정의한다.

@SqlResultSetMapping(
    name = "memberWithOrderCount",
    entities = {
        @EntityResult(entityClass = Member.class)
    },
    columns = {
        @ColumnResult(name = "ORDER_COUNT")
    }
)

String sql = "SELECT M.ID, AGE, NAME, TEAM_ID, I.ORDER_COUNT "
           + "FROM MEMBER M "
           + "LEFT JOIN (SELECT IM.ID, COUNT(*) AS ORDER_COUNT "
           + "           FROM ORDERS O, MEMBER IM "
           + "           WHERE O.MEMBER_ID = IM.ID) I "
           + "ON M.ID = I.ID";

Query nativeQuery = em.createNativeQuery(sql, "memberWithOrderCount");

→ 복잡한 쿼리 결과를 엔티티 + 추가 컬럼으로 나눠서 받을 수 있다.

Named 네이티브 쿼리

JPQL처럼 이름을 붙여서 관리할 수 있다.

엔티티 클래스에 @NamedNativeQuery로 정의하고 em.createNamedQuery()로 사용한다.

@Entity
@NamedNativeQuery(
    name  = "Member.memberSQL",
    query = "SELECT ID, AGE, NAME, TEAM_ID FROM MEMBER WHERE AGE > ?",
    resultClass = Member.class
)
public class Member { ... }

TypedQuery<Member> nativeQuery =
    em.createNamedQuery("Member.memberSQL", Member.class)
      .setParameter(1, 20);

네이티브 SQL 정리

네이티브 SQL은 관리하기 쉽지 않다. 자주 쓰면 특정 DB에 종속적인 쿼리가 늘어나서 이식성이 떨어진다.

→ 최대한 JPQL을 쓰고, 방법이 없을 때만 네이티브 SQL을 쓰는 것이 맞다.

그래도 안 되면 MyBatis 같은 SQL 매퍼를 함께 도입하는 것도 방법이다.

6. 객체 지향 쿼리 심화

벌크 연산

벌크 연산은 한 번에 여러 엔티티를 수정하거나 삭제할 때 사용한다.

예를 들어 재고가 10개 미만인 모든 상품의 가격을 10% 올리고 싶다면, 엔티티를 하나씩 꺼내서 수정하는 건 비효율적이다.

// UPDATE 벌크 연산
String jpql = "update Product p "
            + "set p.price = p.price * 1.1 "
            + "where p.stockAmount < :stockAmount";

int resultCount = em.createQuery(jpql)
    .setParameter("stockAmount", 10)
    .executeUpdate();

// DELETE 벌크 연산
String jpql = "delete from Product p "
            + "where p.price < :price";

int resultCount = em.createQuery(jpql)
    .setParameter("price", 100)
    .executeUpdate();

→ executeUpdate()를 사용하고, 영향받은 엔티티 건수를 반환한다.

영속성 컨텍스트와 JPQL

• JPQL 조회 시 동작 방식

DB 조회 결과 → 엔티티 확인
    ↓
이미 영속성 컨텍스트에 있음? → YES → 기존 엔티티 반환 (DB 결과 버림)
                              → NO  → 새 엔티티 영속성 컨텍스트에 저장 후 반환

• JPQL과 플러시

JPQL 실행 전에 JPA는 자동으로 플러시를 한다. 영속성 컨텍스트에 변경 사항이 있는 상태에서 JPQL로 조회하면, 아직 DB에 반영되지 않은 내용이 누락될 수 있기 때문이다.

em.persist(new Product("상품X", 1000)); // 아직 DB에 없음

// JPQL 실행 직전에 자동 flush 발생
List<Product> results = em.createQuery("select p from Product p", Product.class)
    .getResultList();
// 상품X도 결과에 포함된다

→ FlushModeType.COMMIT 으로 설정하면 플러시 시점을 조정할 수 있다. 다만 이 경우 JPQL 조회 시 누락 문제가 생길 수 있으니 주의해서 사용해야 한다.

스토어드 프로시저 (JPA 2.1)

JPA 2.1부터 스토어드 프로시저 호출을 지원한다.

// 순서 기반 파라미터
StoredProcedureQuery spq =
    em.createStoredProcedureQuery("proc_multiply");

spq.registerStoredProcedureParameter(1, Integer.class, ParameterMode.IN);
spq.registerStoredProcedureParameter(2, Integer.class, ParameterMode.OUT);

spq.setParameter(1, 100);
spq.execute();

Integer out = (Integer) spq.getOutputParameterValue(2);
System.out.println("out = " + out); // 결과 출력

Named 스토어드 프로시저도 정의해서 재사용할 수 있다.

@NamedStoredProcedureQuery(
    name           = "multiply",
    procedureName  = "proc_multiply",
    parameters     = {
        @StoredProcedureParameter(name = "inParam",  mode = ParameterMode.IN,  type = Integer.class),
        @StoredProcedureParameter(name = "outParam", mode = ParameterMode.OUT, type = Integer.class)
    }
)
@Entity
public class Member { ... }

StoredProcedureQuery spq = em.createNamedStoredProcedureQuery("multiply");
spq.setParameter("inParam", 100);
spq.execute();

Integer out = (Integer) spq.getOutputParameterValue("outParam");

→ 이름 기반으로 관리하면 재사용하기 훨씬 편하다.

9장에서 다룰 내용:

• 기본값 타입
• 임베디드 타입
• 컬렉션 타입

1. 기본값 타입

기본값 타입은 자바에서 제공하는 기본타입과 유사하다.

예를 들어 int, double, String, Integer처럼 단순한 값을 저장하는 타입을 말한다.

2. 임베디드 타입(복합 값 타입)

• 새로운 값 타입을 직접 정의해서 사용할 수 있다. JPA에서는 이를 임베디드 타입이라고 한다.
• 기본 사용법:

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    // 근무 기간
    @Embedded
    private Period workPeriod;

    // 집 주소
    @Embedded
    private Address homeAddress;
}

@Embeddable
public class Period {
    private LocalDate startDate;
    private LocalDate endDate;

    // 의미 있는 메서드도 추가 가능
    public boolean isWork() {
        LocalDate now = LocalDate.now();
        return !now.isBefore(startDate) && !now.isAfter(endDate);
    }
}

@Embeddable
public class Address {
    @Column(name = "city")
    private String city;
    private String street;
    private String zipcode;
}

임베디드 타입을 사용하면 DB 테이블 구조는 그대로이고, 객체 모델만 더 명확해진다. isWork() 같은 유의미한 메서드를 값 타입 안에 정의할 수 있어 응집도가 높아진다.

임베디드 타입과 테이블 매핑

임베디드 타입을 사용해도 테이블은 하나다. 임베디드 타입 필드들이 Member 테이블 컬럼으로 그냥 펼쳐진다.

CREATE TABLE MEMBER (
    ID         BIGINT NOT NULL,
    NAME       VARCHAR(255),
    START_DATE DATE,
    END_DATE   DATE,
    CITY       VARCHAR(255),
    STREET     VARCHAR(255),
    ZIPCODE    VARCHAR(255),
    PRIMARY KEY (ID)
);

임베디드 타입 중첩

임베디드 타입 안에 또 다른 임베디드 타입을 넣을 수 있다.

@Embeddable
public class Address {
    private String city;
    private String street;

    @Embedded
    private Zipcode zipcode; // 중첩 임베디드
}

@Embeddable
public class Zipcode {
    private String zip;
    private String plusFour;
}

같은 임베디드 타입을 두 번 사용하는 경우: @AttributeOverride

하나의 엔티티에 같은 임베디드 타입을 두 번 사용하면 컬럼명이 충돌한다. 이때 @AttributeOverride로 컬럼명을 재정의한다.

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    @Embedded
    private Address homeAddress;

    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name = "city",    column = @Column(name = "COMPANY_CITY")),
        @AttributeOverride(name = "street",  column = @Column(name = "COMPANY_STREET")),
        @AttributeOverride(name = "zipcode", column = @Column(name = "COMPANY_ZIPCODE"))
    })
    private Address companyAddress;
}

임베디드 타입과 null

임베디드 타입을 null로 설정하면 매핑된 컬럼들도 모두 null이 된다.

member.setAddress(null);
em.persist(member); // city, street, zipcode 모두 null로 저장

3. 값 타입과 불변 객체

값 타입은 공유하면 위험하다.

• 위험한 코드 예제:

// 위험한 코드!
Address address = new Address("서울", "강남대로", "12345");

member1.setHomeAddress(address);
member2.setHomeAddress(address); // 같은 인스턴스 공유

member1.getHomeAddress().setCity("부산"); // member2도 부산이 되어버린다!

→ 해결책: 값 타입을 불변 객체로 만든다. setter를 제거하고 생성자로만 초기화한다.

@Embeddable
public class Address {
    private String city;
    private String street;
    private String zipcode;

    // 기본 생성자 (JPA 필수)
    protected Address() {}

    // 값 변경은 새 객체 생성으로만 가능
    public Address(String city, String street, String zipcode) {
        this.city = city;
        this.street = street;
        this.zipcode = zipcode;
    }

    // getter만 제공, setter 없음
}

값을 변경하고 싶으면 새 객체를 만들어서 교체하는 방식을 사용한다.

4. 값 타입의 비교

값 타입은 ==가 아니라 equals()로 비교해야 한다.

Address a1 = new Address("서울", "강남대로", "12345");
Address a2 = new Address("서울", "강남대로", "12345");

System.out.println(a1 == a2);       // false (다른 인스턴스)
System.out.println(a1.equals(a2));  // true (내용이 같으면)

→ 임베디드 타입에는 반드시 equals()와 hashCode()를 재정의해야 한다.

@Embeddable
public class Address {
    ...

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Address)) return false;
        Address address = (Address) o;
        return Objects.equals(city, address.city) &&
               Objects.equals(street, address.street) &&
               Objects.equals(zipcode, address.zipcode);
    }

    @Override
    public int hashCode() {
        return Objects.hash(city, street, zipcode);
    }
}

5. 값 타입 컬렉션

값 타입을 컬렉션으로 가지고 싶으면 @ElementCollection과 @CollectionTable을 사용한다.

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;

    @Embedded
    private Address homeAddress;

    @ElementCollection
    @CollectionTable(
        name = "FAVORITE_FOODS",
        joinColumns = @JoinColumn(name = "MEMBER_ID")
    )
    @Column(name = "FOOD_NAME")
    private Set<String> favoriteFoods = new HashSet<>();

    @ElementCollection
    @CollectionTable(
        name = "ADDRESS",
        joinColumns = @JoinColumn(name = "MEMBER_ID")
    )
    private List<Address> addressHistory = new ArrayList<>();
}

→ 값 타입 컬렉션은 별도의 테이블에 저장된다. 기본 페치 전략은 LAZY다.

-- FAVORITE_FOODS 테이블
CREATE TABLE FAVORITE_FOODS (
    MEMBER_ID  BIGINT NOT NULL,
    FOOD_NAME  VARCHAR(255)
);

-- ADDRESS 테이블
CREATE TABLE ADDRESS (
    MEMBER_ID BIGINT NOT NULL,
    CITY      VARCHAR(255),
    STREET    VARCHAR(255),
    ZIPCODE   VARCHAR(255)
);

값 타입 컬렉션 수정

Member member = em.find(Member.class, 1L);

// 음식 수정: 치킨 → 한식
member.getFavoriteFoods().remove("치킨");
member.getFavoriteFoods().add("한식");

// 주소 수정: 기존 주소 삭제 후 새 주소 추가
member.getAddressHistory().remove(new Address("서울", "기존로", "11111"));
member.getAddressHistory().add(new Address("서울", "새로운로", "22222"));

값 타입 컬렉션은 값이 변경되면 해당 컬렉션 테이블의 데이터를 전부 삭제하고 다시 저장한다. 따라서 데이터가 많다면 성능 문제가 생길 수 있다.

값 타입 컬렉션의 제약과 대안

값 타입 컬렉션은 편리하지만 제약이 있다.

• 값 타입에는 식별자가 없어서 변경 추적이 어렵다.
• 변경이 일어나면 관련 테이블의 모든 데이터를 지우고 다시 저장한다.
• 데이터가 많아지면 성능이 떨어진다.

실무에서의 대안: 값 타입 컬렉션 대신 일대다 관계 + 별도 엔티티를 사용한다.

@Entity
public class AddressEntity {
    @Id @GeneratedValue
    private Long id;

    @Embedded
    private Address address;
}

// Member에서는
@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
@JoinColumn(name = "MEMBER_ID")
private List<AddressEntity> addressHistory = new ArrayList<>();

→ 이렇게 하면 식별자가 생겨서 변경 추적이 가능하고, 성능도 안정적이다.

8장에서 다룰 내용:

• 프록시와 즉시로딩, 지연로딩
• 영속성 전이와 고아 객체

1. 프록시

엔티티를 조회할 때 연관된 엔티티가 항상 필요한 것은 아니다. ex: 회원을 조회할 때 팀 정보는 상황에 따라 사용할 수도 있고 사용하지 않을 수도 있다. 하지만 기본적으로 em.find()를 사용하면 연관된 엔티티까지 함께 조회될 수 있어 비효율이 발생한다.

→ 이 문제를 해결하기 위해 JPA는 지연 로딩을 제공한다. 실제 사용하는 시점까지 데이터베이스 조회를 미루는 방식이다. 이때 실제 엔티티 대신 사용하는 객체를 프록시라 한다.

프록시 기초

JPA에서 엔티티 조회 방법:

• em.find(): 즉시 조회, DB 바로 접근
• em.getReference(): 프록시 반환, DB 조회하지 않음

프록시 구조: 프록시는 실제 엔티티를 상속한 객체다. 겉보기에는 동일하게 사용 가능하다. 또한 프록시는 내부에 실제 엔티티 참조(target)를 가진다.

프록시 초기화

// MemberProxy 반환
Member member = em.getReference(Member.class, "id1");
member.getName(); // 1. getName()

// 프록시 클래스 예상 코드
class MemberEntity extends Member {
    Member target = null;

    public String getName() {

        if(target == null) {
            // 2. 초기화 요청
            // 3. DB 조회
            // 4. 실제 엔티티 생성 및 참조 보관
        }

        // 5. target.getName()
        return target.getName();
    }
}

프로시와 식별자

엔티티를 프록시 조회할 때 식별자(PK) 값을 파라미터로 전달하는데 프록시 객체는 이 식별자 값을 보관한다.

Team team = em.getReference(Team.class, "team1"); //식별자 보관
team.getId(); //초기화되지 않음

프록시 확인

프록시 초기화 여부 확인 방법: PersistenceUnitUtil.isLoaded()

boolean isLoad = em.getEntityManagerFactory()
                                .getPersistenceUnitUtil()
                                .isLoaded(entity);

→ 초기화 안됨: false → 초기화됨: true

2. 즉시 로딩과 지연 로딩

연관 엔티티를 언제 조회할지 결정하는 방식이다. 핵심은 “지금 가져올지, 나중에 필요할 때 가져올지”이다.

2.1 즉시 로딩 (EAGER)

엔티티를 조회할 때 연관 엔티티도 함께 조회한다. 한 번 조회 시 JOIN을 사용해서 같이 가져오는 경우가 많다. 조회 시점에 이미 데이터가 준비되어 있어서 바로 사용할 수 있다. 하지만 필요하지 않은 데이터까지 가져올 수 있다.

예시 코드

@Entity
public class Member {

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "TEAM_ID")
    private Team team;

}

-- 실행 SQL (예시)

SELECT
    M.MEMBER_ID,
    M.TEAM_ID,
    M.USERNAME,
    T.TEAM_ID,
    T.NAME
FROM MEMBER M LEFT OUTER JOIN TEAM T
    ON M.TEAM_ID = T.TEAM_ID
WHERE M.MEMBER_ID = 'member1';

→ member를 조회하는 순간 team도 같이 조회된다. 이후 getTeam() 호출 시 추가 쿼리는 발생하지 않는다.

2.2 지연 로딩 (LAZY)

연관 엔티티를 실제 사용할 때 조회한다. 처음에는 프록시 객체만 들어가 있고, 값이 필요한 순간 DB를 조회한다. 불필요한 데이터 조회를 줄일 수 있다.

예시 코드

@Entity
public class Member {

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;

}

-- 실행 SQL 흐름

-- 1. member 조회
SELECT *
FROM MEMBER
WHERE MEMBER_ID = 'member1';

-- 2. team 실제 사용 시 조회
SELECT *
FROM TEAM
WHERE TEAM_ID = 'team1';

→ 처음에는 team이 프록시로 들어오고, getName()을 호출하는 순간 실제 team 데이터를 가져온다.

즉시 로딩은 조회 시점에 모두 가져와서 편하지만 비효율이 생길 수 있다. 지연 로딩은 필요한 시점에만 조회해서 성능에 유리하지만, 사용 시점과 영속성 컨텍스트를 신경 써야 한다.

실무에서는 대부분 LAZY를 기본으로 사용하고, 필요한 경우에만 JOIN이나 fetch 전략으로 최적화한다.

3. 지연 로딩 활용

3.1 프록시와 컬렉션 래퍼

지연 로딩에서 컬렉션은 일반 List가 아니라 하이버네이트가 제공하는 컬렉션 래퍼로 관리된다. 이 객체는 내부적으로 프록시처럼 동작하며 실제 데이터가 필요할 때 DB를 조회한다.

Member member = em.find(Member.class, "member1");
List<Order> orders = member.getOrders();
System.out.println(orders.getClass().getName());

orders를 조회해도 초기화되지 않는다. 실제 데이터 접근 시점에 초기화된다. member.getOrders().get(0);

이 시점에 DB를 조회하여 주문 데이터를 가져온다. 그리고 Order는 Product를 즉시 로딩으로 설정했으므로 함께 로딩된다.

3.2 JPA 기본 페치 전략

JPA의 기본 전략은 단건 연관은 즉시 로딩, 컬렉션은 지연 로딩이다.

@ManyToOne, @OneToOne → EAGER @OneToMany, @ManyToMany → LAZY

컬렉션은 데이터 양이 많을 수 있어서 기본적으로 지연 로딩을 사용한다. 실무에서는 대부분 LAZY를 기본으로 두고 필요한 경우만 fetch join으로 최적화한다.

3.3 컬렉션에 EAGER 사용 시 주의점

컬렉션을 즉시 로딩으로 설정하면 조인으로 인해 데이터가 급격히 증가할 수 있다. 특히 여러 컬렉션을 동시에 조인하면 N × M 형태로 결과가 커진다. 성능 문제가 발생할 수 있다.

또한 컬렉션 즉시 로딩은 항상 OUTER JOIN을 사용한다. 데이터가 없어도 결과를 유지하기 위함이다.

결론적으로 컬렉션에는 EAGER 사용을 지양하고, 필요 시 명시적으로 조회 전략을 조정하는 것이 좋다.

4. 영속성 전이: CASCADE

영속성 전이는 부모 엔티티를 저장하거나 삭제할 때 연관된 자식 엔티티도 함께 처리하도록 해주는 기능이다. 즉, 부모만 persist/remove 해도 자식까지 자동으로 처리된다.

4.1 저장 (CascadeType.PERSIST)

cascade 옵션을 사용하면 부모만 저장해도 자식까지 함께 저장된다.

@Entity
public class Parent {

    @OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)
    private List<Child> children = new ArrayList<>();

}

private static void saveWithCascade(EntityManager em) {

    Child child1 = new Child();
    Child child2 = new Child();

    Parent parent = new Parent();
    child1.setParent(parent);
    child2.setParent(parent);

    parent.getChildren().add(child1);
    parent.getChildren().add(child2);

    em.persist(parent);

}

→ parent만 persist 해도 child1, child2까지 함께 저장된다.

4.2 삭제 (CascadeType.REMOVE)

삭제도 동일하게 부모만 제거하면 자식도 함께 삭제된다.

Parent parent = em.find(Parent.class, 1L);
em.remove(parent);

• CascadeType.REMOVE 설정 시 자식까지 자동 삭제된다.
• 설정이 없으면 FK 제약 때문에 예외가 발생한다.

4.3 CASCADE 종류

CascadeType은 여러 옵션을 제공한다.

public enum CascadeType {
    ALL,
    PERSIST,
    MERGE,
    REMOVE,
    REFRESH,
    DETACH
}

여러 옵션을 함께 사용할 수도 있다.

cascade = {CascadeType.PERSIST, CascadeType.REMOVE}

5. 고아 객체

고아 객체 제거는 부모와의 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능이다. 즉, 컬렉션에서 참조만 제거하면 DB에서도 DELETE 된다.

@Entity
public class Parent {

    @Id @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "parent", orphanRemoval = true)
    private List<Child> children = new ArrayList<>();

}

사용 방식은 컬렉션에서 제거하는 것만으로 충분하다.

Parent parent = em.find(Parent.class, id);
parent.getChildren().remove(0);

→ flush 시점에 DELETE FROM CHILD 실행된다.

모든 자식을 제거하려면 컬렉션을 비우면 된다: parent.getChildren().clear();

고아 객체 제거는 “더 이상 어떤 곳에서도 참조되지 않는 엔티티를 삭제”하는 개념이다. 따라서 한 부모에 완전히 종속된 경우에만 사용해야 하며, 여러 곳에서 참조되는 엔티티에는 사용하면 안 된다. (보통 @OneToOne, @OneToMany에서 사용)

또한 부모를 삭제하면 자식도 함께 삭제되는데, 이는 CascadeType.REMOVE와 유사하게 동작한다.

6. 영속성 전이 + 고아 객체, 생명주기

Cascade + orphanRemoval을 함께 사용하면 부모가 자식의 전체 생명주기를 관리할 수 있다.

• 자식 추가는 cascade로 처리된다.

Parent parent = em.find(Parent.class, parentId);
parent.addChild(child1);

→ parent만 관리하면 child 자동 persist

• 자식 삭제는 orphanRemoval로 처리된다.

Parent parent = em.find(Parent.class, parentId);
parent.getChildren().remove(child1);

→ 컬렉션에서 제거하면 child 자동 delete

7장에서 다룰 고급 매핑은 다음과 같다:

• 상속 관계 패핑
• MappedSuperClass
• 복합 키와 식별 관계 매핑
• 조인 테이블
• 엔티티 하나에 여러 테이블 매핑

1. 상속 관계 매핑

객체지향에서는 상속 구조를 사용하지만 데이터베이스는 테이블 구조를 사용한다. 그래서 JPA에서는 상속 구조를 테이블로 변환하는 전략이 필요하다.

대표적으로 3가지 전략이 있다.

1.1 조인 전력

부모와 자식 각각 테이블을 만든다. 자식 테이블은 부모의 PK를 FK로 같이 사용한다. 조회 시에는 JOIN이 필요하다.

장점

• 정규화 구조 유지
• 데이터 중복 없음
• 외래키 제약 사용 가능

단점

• JOIN 많이 발생 → 성능 저하 가능
• INSERT 시 여러 번 쿼리 실행

핵심 설정

@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "DTYPE")

1.2 단일 테이블 전략

모든 데이터를 하나의 테이블에 저장한다. DTYPE 컬럼으로 타입을 구분한다.

장점

• JOIN 없음 → 조회 성능 가장 빠름
• 구조 단순

단점

• 사용하지 않는 컬럼은 null 허용
• 테이블이 커질 수 있음

핵심 설정

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "DTYPE")

1.3 구현 클래스마다 테이블 전략

자식 엔티티마다 테이블을 만든다. 각 테이블에 부모 필드까지 모두 포함된다.

장점

• 서브 타입별로 독립적 저장
• NOT NULL 제약 사용 가능

단점

• UNION 쿼리 필요 → 성능 안 좋음
• 비추천 전략

핵심 설정

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

2. @MappedSuperClass

@MappedSuperclass는 테이블과 매핑되지 않는 부모 클래스이다. 단순히 공통 필드를 자식 엔티티에 상속하기 위한 용도이다. 데이터베이스에는 테이블이 생성되지 않는다.

• 왜 사용하는가: 여러 엔티티에서 공통으로 사용하는 필드가 있다. (ex: id, name 같은 기본 정보. 이런 필드를 부모 클래스에 모아두고 재사용한다)

• 구조:

  • 부모 클래스는 @MappedSuperclass로 선언한다.

  • 자식 클래스만 @Entity로 테이블과 매핑된다.

    @MappedSuperclass
    public abstract class BaseEntity {
      @Id @GeneratedValue
      private Long id;
      private String name;
    }
    
    @Entity
    public class Member extends BaseEntity {
      private String email;
    }
    
    @Entity
    public class Seller extends BaseEntity {
      private String shopName;
    }

특징:

• 부모 클래스는 테이블이 없다
• 자식 엔티티만 테이블이 생성된다
• 공통 컬럼을 코드 레벨에서 재사용한다

주의점:

• @MappedSuperclass는 엔티티가 아니다
• em.find()나 JPQL에서 조회할 수 없다
• 보통 abstract 클래스로 만든다

→ 정리: @MappedSuperclass는 테이블 매핑이 아닌 공통 필드 상속용 구조이다.

3. 복합 키와 식별 관계 매핑

3.1 식별 관계 vs 비식별 관계

테이블 관계는 외래 키가 기본 키에 포함되는지에 따라 나뉜다.

• 식별 관계 (Identifying Relationship)
  • 부모의 기본 키를 자식이 내려받는다. 자식은 부모 PK를 포함해서 복합 키를 만든다.
  • PK + FK 구조
• 비식별 관계 (Non-identifying Relationship)
  • 부모의 기본 키를 자식이 외래 키로만 사용한다.
  • 자식은 별도의 PK를 가진다.
  • 필수적 관계: FK에 NULL 불가
  • 선택적 관계: FK에 NULL 허용

3.2 복합 키: 비식별 관계 매핑

복합 키는 2개 이상의 컬럼으로 구성된 PK이다. JPA에서는 단순히 @Id 여러 개로 처리할 수 없다 →식별자 클래스를 만들어야 한다.

JPA는 두 가지 방법을 제공한다.

• @IdClass: DB 중심, 단순
• @EmbeddedId: 객체지향, 깔끔

@IdClass

DB 중심 방식이다. 엔티티에 여러 @Id를 직접 선언한다.

@IdClass(ParentId.class)
class Parent {
    @Id String id1;
    @Id String id2;
}

@EmbeddedId

객체지향 방식이다. 식별자 클래스를 엔티티 안에 포함한다.

@EmbeddedId
private ParentId id;

3.3 복합 키: 식별 관계 매핑

• 식별 관계 구조: 식별 관계에서는 부모 → 자식 → 손자까지 기본 키가 계속 전파된다.

ex:

• Parent
• Child (PK = parent_id + child_id)
• GrandChild (PK = parent_id + child_id + grandchild_id)

@IdClass로 식별 관계 매핑

식별 관계에서는 @Id + @ManyToOne을 같이 사용한다.

Child 엔티티 핵심

@Id
@ManyToOne
@JoinColumn(name = "PARENT_ID")
private Parent parent;

@Id
@Column(name = "CHILD_ID")
private String childId;

ChildId (식별자 클래스)

class ChildId {
    private String parent;   // Parent.id
    private String childId;
}

GrandChild까지 확장

@Id
@ManyToOne
@JoinColumns({
    @JoinColumn(name = "PARENT_ID"),
    @JoinColumn(name = "CHILD_ID")
})
private Child child;

@Id
@Column(name = "GRANDCHILD_ID")
private String id;

@EmbeddedId + 식별 관계

이 경우는 @MapsId 사용이 핵심이다.

Child 엔티티

@EmbeddedId
private ChildId id;

@MapsId("parentId")
@ManyToOne
@JoinColumn(name = "PARENT_ID")
private Parent parent;

ChildId

@Embeddable
class ChildId {
    private String parentId;
    private String id;
}

GrandChild (EmbeddedId)

@EmbeddedId
private GrandChildId id;

@MapsId("childId")
@ManyToOne
@JoinColumns({
    @JoinColumn(name = "PARENT_ID"),
    @JoinColumn(name = "CHILD_ID")
})
private Child child;

3.4 비식별 관계로 구현

구조 변화

Before (식별 관계)

• PK = 부모 PK 포함

After (비식별 관계)

• PK = 독립적인 값
• FK = 따로 존재

@Id @GeneratedValue
private Long id;

@ManyToOne
@JoinColumn(name = "PARENT_ID")
private Parent parent;

3.5 일대일 식별 관계

자식 PK = 부모 PK → 복합 키 필요 없음

@Entity
class BoardDetail {

    @Id
    private Long boardId;

    @MapsId
    @OneToOne
    @JoinColumn(name="BOARD_ID")
    private Board board;
}

3.6 식별 vs 비식별 관계 정리

식별 관계 단점

• PK가 계속 증가
• JOIN 복잡
• SQL 복잡
• 변경 어려움
• 복합 키 필수

비식별 관계 장점

• 단순한 PK
• 유지보수 쉬움
• 변경 유연
• JPA 사용 편함

4. 조인 테이블

데이터베이스 테이블의 연관관계를 설계하는 방법은 크게 2가지다.

• 조인 컬럼 사용 (외래 키)
• 조인 테이블 사용

조인 컬럼 vs 조인 테이블

JPA 매핑

• 조인 컬럼

@ManyToOne
@JoinColumn(name = "LOCKER_ID")
private Locker locker;

• 조인 테이블

@ManyToOne
@JoinTable(
    name = "MEMBER_LOCKER",
    joinColumns = @JoinColumn(name = "MEMBER_ID"),
    inverseJoinColumns = @JoinColumn(name = "LOCKER_ID")
)
private Locker locker;

5. 엔티티 하나에 여러 테이블 매핑

하나의 엔티티를 여러 테이블에 매핑할 수 있다.

• @SecondaryTable

@Entity
@Table(name = "BOARD")
@SecondaryTable(
    name = "BOARD_DETAIL",
    pkJoinColumns = @PrimaryKeyJoinColumn(name = "BOARD_DETAIL_ID")
)
public class Board {

    @Id
    private Long id;

    private String title;

    @Column(table = "BOARD_DETAIL")
    private String content;
}

동작 방식:

• BOARD → id, title

• BOARD_DETAIL → content

• 기본 키로 조인

• 여러 테이블 매핑

@SecondaryTables({
    @SecondaryTable(name="BOARD_DETAIL"),
    @SecondaryTable(name="BOARD_FILE")
})

• 단점: 항상 조인 발생, 성능 최적화 어려움
• 권장 방식: 실무에서는: 엔티티 분리 + 연관관계 사용

6장은 다양한 연관관계를 다룬다 (다대일, 일대다, 일대일, 다대다).

1. 다대일

• 다대일 관계의 반대 방향은 항상 일대다 관계고 일대다 관계의 방향은 항상 다대일 관계다.
  • 데이터베이스 테이블: 일(1), 다(N) 관계에서 외래 키는 항상 다쪽에 있다.
  • 객체 양방향 관계: 연관관계의 주인은 항상 다쪽이다.

ex: 회원(N), 팀(1)이 있으면 회원 쪽이 연관관계의 주인이다.

1.1 다대일 단방향 [N:1]

// 회원 엔티티

@Entity
public class Member {

    @Id @GeneratedValue
    @Column(name="MEMBER_ID"
    private Long id;

    private String username;

    @ManyToOne
    @JoinColumn(name="TEAM_ID")
    private Team team;

    // ...
}

// 팀 엔티티

@Entity 
public class Team {

    @Id @GeneratedValue
    @Column(name="TEAM_ID")
    private Long id;

    private String name;

    // ...
}

→ 회원은 Member.team으로 팀 엔티티를 참조 할 수 있다. 팀에는 회원을 참조하는 필드가 없다. 회원과 팀은 다대일 단방향 연관관계다.

1.2 다대일 양방향 [N:1, 1:N]

// 회원 엔티티

@ManyToOne
@JoinColumn(name="TEAM_ID")
private Team team;

// 팀 엔티티

@OneToMany(mappedBy="team")
private List<Member> members = new ArrayList<Member>();

• 양방향은 키가 있는 쪽이 연관관계의 주인이다.
  • Member.team : 외래 키(TEAM_ID)를 관리하는 연관관계의 주인이다.
  • Team.members : mappedBy로 매핑된 주인이 아닌 쪽이다. 조회와 객체 그래프 탐색에만 사용한다.
• 양방향 연관관계는 항상 서로를 참조해야 한다.

2. 일대다

일대다 관계는 다대일 관계의 반대 반향이다. 일대다 관계는 엔티티를 하나 이상 참조할 수 있어서 자바 컬렉션인 Collection, List, Set, Map 중에 하나를 사용해야 한다.

2.1 일대다 단방향 [1:N]

하나의 팀은 여러 회원을 참조할 수 있는데 이런 관계를 일대다 관계라 한다. 팀은 회원들을 참조하지만 회원은 팀을 참조하지 않으면 둘의 관계는 일대다 단방향 관계다.

// 팀 엔티티

@OneToMany
// 일대다 단방향 관계를 매핑할 때는 @JoinColumn을 명시해야 한다.
@JoinColumn(name="TEAM_ID") //  MEMBER 테이블의 TEAM_ID (FK)
private List<Member> members = new ArrayList<Member>()'

// 회원
@Id @GeneratedValue
@Column(name="MEMBER_ID")
private Long id;

private String username;

• 일대다 단방향 매핑의 단점: 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있다. Team에서 members를 추가하면 Member 테이블의 team_id를 변경해야 해서 INSERT 이후에 추가 UPDATE 쿼리가 발생한다 → 비효율적

일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자

2.2 일대다 양방향 [1:N, N:1]

일대다 양방향 매핑은 일반적으로 존재하지 않는다. 양방향 매핑에서 연관관계의 주인은 항상 외래 키를 가진 쪽이고, @OneToMany는 주인이 될 수 없고 @ManyToOne에는 mappedBy 속성이 없다.

다만 아래와 같이 일대다를 주인처럼 사용하는 방식으로 “형식적인 양방향” 구현은 가능하다.

// 팀 엔티티

@OneToMany
@JoinColumn(name="TEAM_ID")
private List<Member> members = new ArrayList<Member>()'

// 회원 엔티티

@ManyToOne
@JoinColumn(name="TEAM_ID", insertable=false, updatable=false)
private Team team;

• 단점:
  • Member 쪽은 읽기 전용이 되고, 연관관계 관리가 Team에만 집중되어 구조가 비정상적이다.
  • 불필요한 UPDATE 쿼리가 발생해 성능상 비효율이 생긴다.

될 수 있으면 다대일 양방향 매핑을 사용하자!

3. 일대일 [1:1]

일대일 관계는 양쪽이 서로 하나의 관계만 가지는 구조다. (ex: 회원은 하나의 사물함만 사용하고, 사물함도 하나의 회원에 의해서만 사용된다.)

• 일대일 관계는 그 반대 방향에서도 동일하게 일대일 관계가 된다.
• 외래 키는 주 테이블이나 대상 테이블 둘 중 어느 곳에나 둘 수 있다.
  • 주 테이블 외래키: 주 테이블에 외래 키를 두고 대상 테이블을 참조한다. 일반적으로 객체지향 설계와 유사해 관리가 편리하다.
  • 대상 테이블 외래키: 대상 테이블에 외래 키를 두는 방식으로, 데이터베이스 설계 중심으로 볼 때 선택할 수 있다.

3.1 주 테이블에 외래 키

객체지향 개발자들은 주 테이블에 외래 키가 있는 것을 선호한다. JPA도 주 테이블에 외래 키가 있으면 더 직관적이고 편리하게 매핑할 수 있다.

단방향

// Member
@OneToOne
@JoinColumn(name="LOCKER_ID")
private Locker locker;

// Locker
@Id @GeneratedValue
@Column(name="LOCKER_ID")
private Long id;

객체 매핑에는 @OneToOne을 사용하고, @JoinColumn으로 외래 키를 지정한다. 이 경우 Member 테이블에 LOCKER_ID가 생성되어 Locker를 참조한다.

이 구조는 다대일 단방향과 거의 동일하게 동작하고 관계의 최대 개수가 1:1이라는 점만 다르다.

양방향

// Member
@OneToOne
@JoinColumn(name="LOCKER_ID")
private Locker locker;

// Locker
@OneToOne(mappedBy="locker")
private Member member;

MEMBER 테이블이 외래 키를 가지고 있어서 Member 엔티티에 있는 Member.locker가 연관관계의 주인이다.

반대 매핑인 사물한의 Locker.member는 mappedBy를 선언해서 연관관계의 주인이 아니라고 설정했다.

3.2 대상 테이블에 외래 키

단방향

일대일 관계 중 대상 테이블에 외래 키가 있는 단방향 관계는 JPA에서 지원하지 않는다.

JPA2.0부터 일대다 단방향 관계에서 대상 테이블에 외래 키가 있는 매핑을 허용했다. 하지만 일대일 단방향은 이런 매핑을 허용하지 않는다.

양방향

// Member
@OneToOne(mappedBy="member")
private Locker locker;

// Locker
@OneToOne
@JoinColumn(name="MEMBER_ID")
private Member member;

이 경우 대상 엔티티인 Locker가 연관관계의 주인이 되며, MEMBER_ID 외래 키를 통해 관계를 관리한다. Member는 mappedBy를 사용해 읽기 전용으로 관계를 조회만 한다.

4. 다대다 [N:N]

• 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다. 그래서 보통 다대다 관계를 일대다, 다대일 관계로 풀어내는 연결 테이블을 사용한다.
• 객체는 테이블과 다르게 객체 2개로 다대다 관계를 만들 수 있다. ex: 회원 객체는 컬렉션을 사용해서 상품들을 참조하면 되고 반대로 상품들도 컬렉션을 사용해서 회원들을 참조하면 된다.

4.1 다대다: 단방향

// Member
@ManyToMany
@JoinTable(name="MEMBER_PRODUCT", 
                    joinColumns = @JoinColumn(name="MEMBER_ID"),
                    inverseJoinColumns = @JoinColumn(name="PRODUCT_ID")
private List<Product> products = new ArrayList<Product>();

// Product
@Id @Column(name="PRODUCT_ID")
private String id;

회원 엔티티와 상품 엔티티를 @ManyToMany 로 매핑했다. 중요한 포인트: @ManyToMany 와 @JoinTable 을 사용해서 연결 테이블을 바로 매핑했다.

속성을 정리하면:

• @JoinTable.name : 연결 테이블 지정
• @JoinTable.joinColumns : 현재 방향인 회원과 매핑할 조인 컬럼 정보 지정
• @JoinTable.inverseJoinColumns : 반대 방향인 상품과 매핑할 조인 컬럼 정보를 지정

4.2 다대다: 양방향

다대다 매핑이므로 역방향도 @ManyToMany 를 사용한다. 양쪽 중 원하는 곳에 mappedBy로 연관관계의 주인을 지정한다.

// 역방향 추가
// Product

@ManyToMany(mappedBy="products") 
private List<Member> members;

4.3 다대다: 매핑의 한계와 극복, 연결 엔티티 사용

@ManyToMany

• 장점: 연결 테이블을 자동으로 처리해주므로 도메인 모델이 단순해지고 여러 가지로 편리하다.
• 한계: 예를 들어 회원이 상품을 주문하면 단순히 회원 ID와 상품 ID만 저장하는 것이 아니라 주문 수량, 주문 날짜와 같은 추가 정보가 필요하다. 하지만 @ManyToMany에서는 연결 테이블이 엔티티로 존재하지 않기 때문에 이러한 컬럼을 매핑할 수 없다.

→ 이를 해결하기 위해 연결 테이블을 별도의 엔티티로 만들어 다대다 관계를 일대다, 다대일 관계로 풀어야 한다.

// Member
@Id @Column(name="MEMBER_ID")
private String id;

@OneToMany(mappedBy = "member")
private List<MemberProduct> memberProducts;

// Product
@Id @Column(name="PRODUCT_ID")
private String id;

private String name;

// MemberProduct (회원상품 엔티티)

@Id
@ManyToOne
@JoinColumn(name="MEMBER_ID")
private Member member; // MemberProductId.member와 연결

@Id
@ManyToOne
@JoinColumn(name="PRODUCT_ID")
private Product product; // MemberProductId.product와 연결

위 예제에서 MemberProduct 엔티티는 member와 product를 함께 기본 키로 사용하는 복합 키 구조를 가진다. 즉, MEMBER_ID와 PRODUCT_ID를 조합해 하나의 식별자로 사용하며, 같은 회원과 상품의 조합은 하나만 존재할 수 있다.

회원상품은 회원과 상품의 기본 키를 받아서 자신의 기본 키로 사용한다. 이처럼 부모 엔티티의 기본 키를 자식 엔티티의 기본 키로 함께 사용하는 관계를 식별관계(Identifying Relationship) 라고 한다.

→ 복합 키를 사용하는 방법이 복잡하다.

4.4 다대다: 새로운 기본키 사용

추천하는 방식은 데이터베이스에서 자동으로 생성되는 대리 키(Long 타입)를 기본 키로 사용하는 것이다. 기존의 복합 키 대신 ORDER_ID와 같은 단일 기본 키를 두고, MEMBER_ID, PRODUCT_ID는 외래 키로만 사용한다.

// Order
@Id @GeneratedValue
@Column(name="ORDER_ID")
private Long id;

@ManyToOne
@JoinColumn(name="MEMBER_ID")
private Member member;

@ManyToOne
@JoinColumn(name="PRODUCT_ID")
private Product product;

// Member
@OneToMany(mappedBy="member")
private List<Order> orders = new ArrayList<Order>();

// Product
@Id @Column(name="PRODUCT_ID")
private String id;
private String name;

이 방식은 엔티티가 독립적인 식별자를 가지게 되어 식별관계가 아닌 비식별관계로 구성된다. 그 결과 매핑이 단순해지고, 코드 작성과 유지보수가 훨씬 수월해진다.

다대다 연관관계 정리

다대다 관계를 일대다 다대일 관계로 풀어내기 위해 연결 테이블을 만들 때 식별자를 어떻게 구성할지 선택해야 한다.

• 식별 관계: 받아온 식별자를 기본 키 + 외래 키로 사용한다.
• 비식별 관계: 받아온 식별자는 외래 키로만 사용하고 새로운 식별자를 추가한다.

5장의 목표는 객체의 참조와 테이블의 외래 키를 매핑하는 것이다.

5장의 핵심 키워드:

• 방향 (direction): 단방향, 양방향이 있다. 방향은 객체관계에만 존재하고 테으블 관계는 항상 양방향이다.
• 다중성 (multiplicity): 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M) 다중성이 있다.
• 연관관계 주인 (owner): 객체를 양방향 연관관계로 만들면 연관관계의 주인을 정해야 한다.

1. 단방향 연관관계

ex: 회원과 팀의 관계를 알아보자

• 회원과 팀이 잇다
• 회원은 하나의 팀에만 소속될 수 있다
• 회원과 팀은 다대일 관계다

객체 연관관계

• 회원 객체는 Member.team 필드(멤버 볌수)로 팀 객체와 연관관계를 맺는다
• 회원 객체와 팀 객체: 단방향 관계다.
  • 회원: Member.team 필드를 통해 팀을 알 수 있다 (member.getTeam()으로 조회)
  • 팀: 회원을 알 수 없다 (team → member 접근 필드 없음)

테이블 연관관계

• 회원 테이블은: TEAM_ID 외래 키로 팀 테이블과 연관관계를 맺는다.
• 회원 테이블과 팀 테이블: 양방향 관계.
  • 회원: TEAM_ID 외래 키를 통해서 회원과 팀을 조인할 수 있다
  • 팀: 회원도 조인할 수 있다

-- 회원과 팀을 조인하는 SQL
SELECT *
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.ID

-- 팀과 회원을 조인하는 SQL
SELECT *
FROM TEAM T
JOIN MEMBER M ON T.ID = M.TEAM_ID

1.1 순수한 객체 연관관계

• 객체는 참조를 사용해서 연관관계를 탐색하는 것이 객체 그래프 탐색이라 한다.

member1.setTeam(team1);
member2.setTeam(team1);

Team findTeam = member1.getTeam();

1.2 테이블 연관관계

데이터베이스는 외래 키를 사용해서 연관관계를 탐색하는 것이 조인이라 한다.

SELECT T.*
FROM MEMBER M
    JOIN TEAM T ON M.TEAM_ID = T.ID
WHERE M.MEMBER_ID = 'member1'

1.3 객체 관계 매핑

ex: 회원 엔티티 매핑

@ManyToOne
@JoinColumn(name="TEAM_ID")
private Team team;

• @ManyToOne: 다대일(N:1) 관계. 매핑할 때 이렇게 다중성을 나타내는 어노테이션은 필수다.
• @JoinColumn(name=”TEAM_ID”): 조인 컬럼은 외래 키를 매핑할 때 사용한다. name 속성: 매핑할 외래 키 이름. 이 어노테이션은 생략할 수 있다

1.4 @JoinColumn

속성:

• name: 매핑할 외래 키 이름
• referencedColumnName: 외래 키가 참조하는 대상 테이블의 컬럼명
• foreignKey(DDL): 외래 키 제약조건을 직접 지정. 테이블 생성할 때만 사용
• unique, nullable, insertable, updatable, columnDefinition, table: @Column의 속성과 같다

1.5 @ManyToOne

속성:

• optional: 연관관계가 필수인지(null 허용 여부)를 설정한다
• fetch: 연관 엔티티의 조회 방식을 설정한다 (LAZY 또는 EAGER)
• cascade: 연관 엔티티에 대한 영속성 전이 범위를 설정한다
• targetEntity: 연관될 엔티티 타입을 지정한다

2. 연관관계 사용

2.1 저장

public void testSave() {

    //팀1 저장
    Team team1 = new Team("team1", "팀1");
    em.persist(team1);

    //회원1 저장
    Member member1 = new Member("member1", "회원1");
    member1.setTeam(team1); // 연관관계 설정: member1 -> team1
    em.persist(member1);

    //회원2 저장
    Member member2 = new Member("member2", "회원2");
    member2.setTeam(team1); // 연관관계 설정: member2 -> team1
    em.persist(member2);
}

2.2 조회

• 연관관계가 있는 엔티티를 조회하는 방법은 크게 2가지다.

  • 객체 그래프 탐색

    Team team = member.getTeam();

  • 객체지향 쿼리 사용 JPQL

    List<Member> resultList = em.createQuery(jpql, Member.class)
          .setParameter("teamName", "팀1");
          .getResultList();

2.3 수정

//회원1에 새로운 팀2 설정
Member member = em.find(Member.class, "member1");
member.setTeam(team2);

2.4 연관관계 제거

member1.setTeam(null); //연관관계 제거

2.5 연관된 엔티티 삭제

member1.setTeam(null); //회원1 연관관계 제거
member2.setTeam(null); //회원2 연관관계 제거
em.remove(team); //팀 삭제

3. 양방향 연관관계

회원 → 팀 접근하고 반대 방향 팀 → 회원 접근할 수 있는 양방향 연관관계로 매핑해 볼 것이다.

3.1 양방향 연관관계 매핑

매핑한 팀 엔티티:

@Entity
public class Team {

    @Id
    @Column(name="TEAM_ID")
    private Stirng id;

    // 추가
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<Member>();

}

• mappedBy: 양방향 매핑일 때 사용, 반대 쪽 매핑의 필드 이름을 값으로 주면된다.

3.2 일대다 컬렉션 조회

List<Member> members = team.getMembers(); // (팀 -> 회원), 객체 그래프 탐색

4. 연관관계의 주인

복습:

• 테이블: 외래 키 하나로 두 테이블의 연관관계를 관리한다
• 엔티티: 단방향으로 매핑하면 참조를 하나만 사용

→ 엔티티를 양방향 관계로 설정하면 객체의 참조는 둘인데 외래 키는 하나다.

연관관계의 주인

• 두 연관관계 중 하나를 연관관계의 주인으로 정해야한다.
  • 연관관계의 주인만이 데이터베이스 연관관계와 매핑되고 외래 키를 관리(등록, 수정, 삭제)할 수 있다
  • 주인이 아닌 쪽: 읽기만 할 수 있다

연관관계의 주인은 외래 키가 있는 곳

연관관계의 주인은 외래 키(FK)를 가진 쪽이고 Team–Member 관계에서는 TEAM_ID를 가진 MEMBER가 주인이 된다.

5. 양방향 연관관계 저장

양방향 연관관계는 연관관계의 주인이 외래 키를 관리한다. 주인이 아닌 방향은 값을 설정하지 않아도 데이터베이스에 외래 키 값이 정상 입력된다.

team1.getMembers().add(member1); // 무시
team1.getMembers().add(member2); // 무시

member1.setTeam(team1); // 연관관계 설정 
member2.setTeam(team1); // 연관관계 설정

6. 양방향 연관관계의 주의점

외래 키 값이 저장되지 않는다면 연관관계의 주인이 아닌 쪽에서 값을 설정했는지 먼저 확인해야 한다.

6.1 순수한 객체까지 고려한 양방향 연관관계

객체 관점에서 양쪽 방향에 모두 값을 입력해주는 것이 가장 안전하다.

member1.setTeam(team1); // 회원 -> 팀
team1.getMembers().add(member1); // 팀 -> 회원

6.2 연관관계 편의 메소드

양방향 연관관계는 양쪽 다 신경 써야 한다. 각각 호출하다 보면 실수로 둘 중 하나만 호출해서 양방향이 깨질 수 있다. 편의 메소드 사용 방법:

  private Team team;

  public void setTeam(Team team) {

      if (this.team != null) {
        this.team.getMembers().remove(this);
      }
      this.team = team;
      team.getMembers().add(this);
  }
}

JPA는 다양한 어노테이션을 지원하는데 크게 4가지로 나눌 수 있다:

• 객체와 테이블 매핑: @Entity, @Table
• 기본 키 매핑: @Id
• 필드와 컬럼 매핑: @Column
• 연관관꼐 패핑: @ManyToOne, @JoinColumn

4장에서 객체와 테이블 매핑, 기본 키 매핑, 필드와 컬럼 매핑을 다룰 것이다.

1. @Entity

JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수로 붙여야 한다.

• 속성: name: 사용할 엔티티 이름 (기본값: 클래스 이름)
• 주의사항:
  • 기본 생성자는 필수!
  • final 클래스, enum, interface, inner 클래스 사용할 수 없다
  • 저장할 필드에 final을 사용하면 안 된다.

public Member() {} // 직접 만든 기본 생성자

// 임의 생성자
public Member(String name) {
    this.name = name;
}

2. @Table

@Table은 엔티티와 매핑할 테이블을 지정한다.

• 속성:
  • name: 매핑할 테이블 이름
  • catalog: catalog 기능이 있는 데이터베이스에서 catalog를 매핑한다
  • schema: schema 기능이 있는 데이터베이스에서 schema를 매핑한다
  • uniqueConstraints: DDL 생성시에 유니크 제약 조건을 만든다

3. 다양한 매핑 사용

요구사항:

• 회원: 일반회원, 관리자로 구분한다
• 회원 가입일 + 수정일이 있어야 한다
• 회원 설명 필드 있어야 한다. 이 필드는 길이 제한이 없다

package jpabook.start;

import javax.persistence.*;
import java.util.Date;

@Entity
@Table(name="MEMBER")

public class Member {

    @Id
    @Column(name="ID")
    private String id;

    @Column(name="NAME")
    private String username;

    private Integer age;

    //===추가===
    @Enumerated(EnumType.String)
    private RoleType roletype;

    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;

    @Temporal(TemporalType.TIMESTAMP)
    private Date lastModifiedDate;

    @Lob
    private String description;

    //Getter, Setter
    ...
}

package jpabook.start;

public enum RoleType {
    ADMIN, USER
}

4. 데이터베이스 스키마 사용

JPA는 데이터베이스 스키마를 자동으로 생성하는 기능을 지원한다. 이 기능은 persistence.xml 또는 application.yml에서 설정할 수 있다.

<property name="hibernate.hbm2ddl.auto" value="create" />
<property namee="hibernate.show_sql" value="true" />

• [hibernate.hbm2ddl.auto] 속성:
  • create: 기존 테이블을 삭제하고 새로 생성한다
  • create-drop: 실행 시 생성하고 종료 시 삭제한다
  • update: 엔티티 변경 사항만 DB에 반영한다
  • validate: 엔티티와 DB 구조를 비교만 하고 수정하지 않는다
  • none: 아무 작업도 하지 않는다

5. DDL 생성 기능

• 추가 제약조건이 있다: 회원 이름은 필수로 입력되어야 하고, 10자를 초과하면 안 된다.

@Column(name="NAME", nullable=false, lengeth=10) // 추가 제약조건

@Column 매핑 정보

• nullable = false → DDL에서 NOT NULL 제약 조건을 설정한다.

• length → DDL에서 문자 길이(컬럼 크기)를 설정한다.

• 추가 제약조건: 유니크

@Table(name="MEMBER", uniqueConstraints = {@UniqueConstraint( //추가 //**
        name = "NAME_AGE_UNIQUE",
        columnNames = {"NAME", "AGE"} )})

엔티티의 @Column 속성들은 주로 DDL 자동 생성 시에만 사용되고 애플리케이션 실행 로직에는 영향을 주지 않는다. 하지만 엔티티만 보고도 제약조건을 쉽게 파악할 수 있어 코드 가독성과 유지보수에 도움이 된다.

6. 기본 키 매핑

JPA가 제공하는 데이터베이스 기본 키 생성 전략은 다음과 같다

• 직접 할당: 애플리케이션에서 직접 기본 키 값을 설정한다
• 자동 생성:
  • IDENTITY: DB의 auto increment 기능을 사용해 기본 키를 생성한다
  • SEQUENCE: DB의 시퀀스를 사용해 기본 키를 생성한다
  • TABLE: 별도의 키 생성 테이블을 사용해 기본 키를 관리한다

6.1 기본 키 직접 할당전략

기본 키를 직접 할당하려면 다음 코드와 같이 @Id 로 매핑하면 된다.

@Id
@Column(name="id")
private String id;

Board board = new Board();
board.setID("id") // 기본 키 직접할당
em.persist(board);

6.2 IDENTITY 전략

IDENTITY는 기본키 생성을 데이터베이스에 위임하는 전략이다.

IDENTITY 전략을 사용하려면 @GeneratedValue의 strategy 속성값을 GenerationType.IDENTITY로 지정하면 된다. 이전략을 사용하면 JPA는 기본 키 값을 얻어오기 위해 데이터베이스를 추가로 조회한다.

@Entity
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

}

private static void logic(EntityManager em) {
    Board board = new Board();
    em.persist(board);
    System.out.println("board.id = " + board.getId);
}
// 출력: board.id=1

6.3 SEQUENCE 전략

시퀀스: 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트다. SEQUENCE 전략은 이 시퀀스를 사용해서 기본 키를 생성한다.

• 시퀀스 DDL:

CREATE TABLE BOARD {
    ID INT NOT NULL PRIMARY KEY,
    DATA VARCHAR(255)
 }

 CREATE SEQUENCE BOARD_SEQ START WITH 1 INCREMENT BY 1;

• 시퀀스 매핑 코드:

@Entity
@SequenceGenerator(
    name = "BOARD_SEQ_GENERATOR",
    sequenceName = "BOARD_SEQ", //매핑할 db 시퀀스 이름
    initialValue = 1, allocationSize = 1)
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
                        generator = "BOARD_SEQ_GENERATOR")
    private Long id;

    ..
}

@SequenceGenerator: 는 시퀀스 생성 방식을 정의하는 설정이고, 실제로는 @GeneratedValue에서 generator 이름을 통해 사용된다. 즉, @SequenceGenerator는 정의, @GeneratedValue는 실행 역할을 한다.

• name: 시퀀스 생성기를 식별하기 위한 이름이다
• sequenceName: 매핑할 데이터베이스 시퀀스 이름이다
• initialValue: 시퀀스의 시작 값을 설정한다
• allocationSize: 한 번에 가져올 시퀀스 값의 증가 크기를 설정하여 성능을 최적화한다
• catalog, schema: 시퀀스가 속한 데이터베이스의 catalog와 schema를 지정한다

6.4 TABLE 전략

TABLE 전략: 키 생성 전용 테이블을 하나 만들고 여기에 이름과 값으로 사용할 컬럼을 만들어 데이터베이스 시퀀스를 흉낸다.

• TABLE 전략 키 생성 DDL

CREATE table MY_SEQUENCES {
    sequence_name varchar(255) not null,
    next_val bigint,
    primary key (sequence_name)
 }

• TABLE 전략 매핑 코드

@Entity
@TableGenerator(
    name = "BOARD_SEQ_GENERATOR",
    table = "MY_SEQUENCES", 
    pkColumnValue = "BOARD_SEQ", allocationSize = 1)
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.TABLE,
                        generator = "BOARD_SEQ_GENERATOR")
    private Long id;

    ..
}

6.5 AUTO 전략

GenerationType.AUTO 는 선택한 데이터베이스 방언에 따라 IDENTITY, SEQUENCE, TABL 전략 중 하나를 자동으로 선택한다.

ex: 오라클을 선택하면 SEQUENCE, MySQL을 선택하면 IDENTITY를 사용한다.

6.6 기본 키 매핑 정리

em.persist() 를 호출한 직후에 발생하는 일을 식별자 할당 전략별로 정리하면 다음과 같다.

• 직적 할당: persist 전에 애플리케이션에서 직접 id 값을 설정해야 한다
• SEQUENCE: 시퀀스를 통해 id를 먼저 조회한 후 엔티티에 할당한다
• TABLE: 키 생성 테이블에서 id를 조회하고 값을 증가시킨 후 할당한다
• IDENTITY: 엔티티를 먼저 DB에 저장한 후 생성된 id 값을 조회한다

7. 필드와 컬럼 매핑: 레퍼런스

7.1 @Column

@Column의 속성:

• name: 컬럼 이름을 지정한다
• insertable: INSERT SQL에 포함할지 여부를 설정한다
• updatable: UPDATE SQL에 포함할지 여부를 설정한다
• table: 매핑할 테이블을 지정한다
• nullable(DDL): NOT NULL 제약 조건을 설정한다
• unique(DDL): UNIQUE 제약 조건을 설정한다
• columnDefinition(DDL): 컬럼의 DDL을 직접 정의한다
• length(DDL): 문자열 컬럼의 길이를 설정한다
• precision, scale(DDL): 숫자의 전체 자릿수와

7.2 @Enumerated

자바의 enum 타입을 매핑할 때 사용한다

• EnumType.ORDINAL: enum 순서를 데이터베이스에 저장
• EnumType.STRING: enum 이름을 데이터베이스에 저장

7.3 @Temporal

날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용한다.

• value 속성:
  • TemporalType.DATE: 날짜(년,월,일)만 저장한다
  • TemporalType.TIME: 시간(시,분,초)만 저장한다
  • TemporalType.TIMESTAMP: 날짜와 시간을 모두 저장한다

7.4 @Lob

데이터베이스 BLOB, CLOB 타입과 매핑한다.

• BLOB: byte[], java.sql.BLOB
• CLOB: String, char[], java.sql.CLOB

7.5 @Transient

이 필드는 매핑하지 않는다. 데이터베이스에 저장하지 않고 조회하지도 않는다. 객체에 임시로 어떤 값을 보관하고 싶을 때 사용한다.

@Transient
private Integer temp;

7.6 @Access

JPA가 엔티티 데이터에 접근하는 방식을 지정한다:

• 필드 접근: AccessType.FIELD로 지정한다. 필드에 직접 접근한다. 필드 접근 권한이 private이어도 접근할 수 있다.
• 프로퍼티 접근: AccessType.PROPERTY로 지정한다. 접근자 getter를 사용한다.

1. 엔티티 매니저 팩토리와 엔티티 매니저

하나의 데이터베이스만 사용하는 애플리케이션에서는 보통 EntityManagerFactory를 하나만 생성해서 사용한다.

// 공장 생성, 초기 비용이 매우 큼
EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");

Persistence.createEntityManagerFactory("jpabook")를 실행하면 META-INF/persistence.xml에 정의된 설정을 기반으로 EntityManagerFactory가 만들어진다. 이때 데이터베이스 연결 설정을 읽고 커넥션 풀을 준비하며 JPA 관련 초기화 작업이 수행되므로 생성 비용이 상당히 크다.

이후에는 필요할 때마다 EntityManagerFactory를 통해 엔티티 매니저를 생성해서 사용한다.

// 엔티티 매니저 생성, 비용이 거의 없음
EntityManager em = emf.createEntityManager();

엔티티 매니저는 실제로 데이터베이스와 CRUD 작업을 수행하는 객체이며 생성 비용이 낮기 때문에 요청 단위로 생성하고 사용 후 종료하는 방식이 일반적이다.

주의: 엔티티 매니저는 여러 스레드에서 동시에 공유해서 사용하면 안 된다.

2. 영속성 컨텍스트란?

영속성 컨텍스트 (persistence context) = 엔티티를 영구 저장하는 환경

em.persist(member);

3. 엔티티의 생명주기

엔티티는 4가지 상태가 있다:

(1) 비영속 (new/transient)

엔티티 객체를 생성만 한 상태로, 아직 영속성 컨텍스트와 전혀 관계가 없다. 데이터베이스와 연결되지 않은 순수 객체 상태다.

Member member = new Member(); // 비영속 상태
member.setName("Trang");

(2) 영속 (managed)

엔티티 매니저를 통해 영속성 컨텍스트에 저장된 상태다. 이 상태에서는 JPA가 엔티티를 관리하고 변경 사항을 자동으로 감지하여 DB에 반영한다.

em.persist(member); // 영속 상태로 전환

(3) 준영속 (detached)

영속 상태였던 엔티티가 더 이상 영속성 컨텍스트에 의해 관리되지 않는 상태다. 변경을 해도 DB에 반영되지 않는다.

em.detach(member); // 준영속 상태

(4) 삭제 (removed): 삭제된 상태

엔티티가 삭제 대상으로 지정된 상태다. 이후 트랜잭션을 커밋하면 실제 DB에서도 삭제된다.

em.remove(member); // 삭제 상태

4. 영속성 컨텍스트의 특징

4.1 엔티티 조회

JPA에서 엔티티를 조회할 때는 1차 캐시(영속성 컨텍스트)를 먼저 사용한다.

1차 캐시는 엔티티 매니저 내부에 존재하는 저장 공간이며 같은 트랜잭션 내에서 엔티티를 효율적으로 관리하기 위해 사용된다. 1차 캐시의 키는 식별자 값(ID)이다. 이 식별자 값은 데이터베이스의 기본 키(PK)와 매핑된다.

조회 과정은 다음과 같이 동작한다.

1. 먼저 1차 캐시에서 식별자 값으로 엔티티를 조회한다.
2. 1차 캐시에 해당 엔티티가 없으면 데이터베이스에서 조회한다.
3. 조회한 데이터를 기반으로 엔티티 객체를 생성한다.
4. 생성된 엔티티를 1차 캐시에 저장한 후 반환한다.

// 엔티티를 생성한 상태 (비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

// 엔티티를 영속
em.persist(member); // 1차 캐시에 저장됨

// 1차 캐시 에서 조회
Member findMember = em.find(Member.class, "member1");

4.2 엔티티 등록

엔티티 등록은 새로운 객체를 생성하고 데이터베이스에 저장하는 과정이다. JPA에서는 persist() 메서드를 사용해서 엔티티를 영속 상태로 만든다.

Member member = new Member();
member.setName("Trang");

em.persist(member); // 영속 상태

엔티티를 persist() 하면 바로 SQL이 실행되는 것이 아니라, 쓰기 지연 SQL 저장소에 INSERT 쿼리가 먼저 저장된다. 이후 트랜잭션을 커밋하는 시점에 SQL이 실제 데이터베이스로 전달된다.

tx.commit(); // 이때 INSERT SQL 실행

동작 흐름:

1. 엔티티 생성 (비영속 상태)
2. persist() 호출 → 영속 상태 전환
3. INSERT SQL을 쓰기 지연 저장소에 저장
4. commit 시점에 DB에 반영

4.3 엔티티 수정

엔티티 수정은 별도의 update 메서드를 호출하지 않고, 변경 감지(dirty checking)를 통해 자동으로 처리된다.

변경 감지 (Dirty Checking)

JPA는 엔티티의 변경을 자동으로 감지한다.

Member member = em.find(Member.class, 1L);
member.setName("New Name"); // 값 변경

별도의 update 호출 없이도 트랜잭션 commit 시점에 JPA가 변경을 감지해서 UPDATE SQL을 생성한다.

동작 방식:

1. 엔티티를 조회하면 초기 상태를 스냅샷으로 저장한다.
2. 트랜잭션 종료 시점에 현재 값과 비교한다.
3. 변경된 경우에만 UPDATE SQL을 실행한다.

@DynamicUpdate

@org.hibernate.annotations.DynamicUpdate

이 옵션을 사용하면 변경된 컬럼만 포함한 UPDATE SQL이 생성된다. 불필요한 컬럼 업데이트를 줄이고 성능을 조금 더 최적화할 수 있다.

4.4 엔티티 삭제

엔티티를 삭제하려면 먼저 삭제 대상 엔티티를 조회해야 한다.

Member memberA = em.find(Member.class, "memberA"); // 삭제 대상 조회
em.remove(memberA); // 엔티티 삭제

5. 플러시 (flush)

flush는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 과정이다.

• 직접 호출: 개발자가 직접 flush를 호출하고 현재까지의 변경 사항이 즉시 DB에 반영된다.

em.flush();

• 트랜잭션 커밋 시 자동 호출

tx.commit();

트랜잭션을 커밋하면 flush가 자동으로 실행된 후 commit이 진행된다. 따라서 대부분의 경우 flush를 직접 호출할 필요는 없다.

• JPQL 쿼리 실행 시 자동 호출: JPQL을 실행하기 전에 flush가 자동으로 호출된다.

6. 준영속

준영속 상태는 엔티티가 더 이상 영속성 컨텍스트에 의해 관리되지 않는 상태다. 이 상태에서는 엔티티를 수정해도 변경 사항이 DB에 반영되지 않는다.

detach()

em.detach(member);

특정 엔티티를 준영속 상태로 전환한다. 해당 엔티티만 영속성 컨텍스트에서 분리된다.

clear()

em.clear();

영속성 컨텍스트를 초기화한다. 관리 중이던 모든 엔티티가 한 번에 준영속 상태가 된다.

close()

em.close();

영속성 컨텍스트를 종료한다. 이후에는 엔티티 매니저를 더 이상 사용할 수 없다.

병합

준영속 상태의 엔티티를 다시 영속 상태로 변형하려면 병합을 사용하면 된다.

// 정의
public <T> T merge(T entity);

// merge() 사용 예
Member mergeMember = em.merge(member);

// 전체 흐름 예시
// 1. 엔티티 조회 (영속 상태)
Member member = em.find(Member.class, 1L);

// 2. 준영속 상태로 변경
em.detach(member);

// 3. 값 변경 (DB 반영 안 됨)
member.setName("New Name");

// 4. merge 호출 → 다시 영속 상태
Member mergedMember = em.merge(member);

// 5. commit 시 UPDATE SQL 실행
tx.commit();

깃허브: https://github.com/holyeye/jpabook

2026년 3월 기준으로 책 내용을 변경해서 실습을 진행했다: (1) 이클립스 → 인텔리제이 (2) Maven → Gradle

폴더 구조는 다음과 같다:

build.gradle

• Gradle: 프로젝트의 의존성과 빌드 설정을 관리하는 파일이다. 어떤 라이브러리를 사용할지, 자바 버전은 무엇인지 등을 여기서 설정한다.

plugins {
    id 'java'
}

group = 'hellojpa'
version = '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.hibernate:hibernate-core:5.6.15.Final'
    implementation 'javax.persistence:javax.persistence-api:2.2'
    runtimeOnly 'com.h2database:h2:2.2.224'
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

persistence.xml

persistence.xml은 JPA 설정 파일이다. 사용할 데이터베이스, 사용할 JPA 구현체, 엔티티 클래스, JPA 동작 옵션 등은 여기에서 설정한다.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
             http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd"
             version="2.2">

        // persistence-unit은 JPA 설정 단위이다
    <persistence-unit name="jpabook">
                // JPA가 관리할 엔티티 클래스를 등록한다
        <class>hellojpa.Member</class>

        <properties>

            <!-- database connection -->
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:~/test"/>
            <property name="javax.persistence.jdbc.user" value="sa"/>
            <property name="javax.persistence.jdbc.password" value=""/>

            <!-- Hibernate -->
            <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>

            <!-- console SQL -->
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.format_sql" value="true"/>

            <!-- auto create table -->
            <property name="hibernate.hbm2ddl.auto" value="create"/>

        </properties>

    </persistence-unit>

</persistence>

Member

이번 실습에서 Member 클래스는 JPA 엔티티 클래스이다. 데이터베이스 테이블과 매핑된다.

package hellojpa;

import javax.persistence.*;
import lombok.Getter;
import lombok.Setter;

@Entity
@Table(name = "MEMBER")
@Getter
@Setter

public class Member {

    @Id
    @Column(name = "ID")
    private String id;

    @Column(name = "NAME")
    private String username;

    // 매핑 정보가 없는 필드
    private Integer age;
}

• @Entity: 이 클래스가 JPA 엔티티임을 나타낸다 → 이 객체는 데이터베이스 테이블과 매핑된다
• @Table: 엔티티가 매핑될 테이블 이름을 지정한다
• @Id: 기본 키를 지정한다
• @Column: 필드와 DB 컬럼을 매핑한다
• 매핑 어노테이션이 없으면 필드 이름 그대로 컬럼이 생성된다

참고: JPA 어노테이션의 패키지는 javax.persistence이다.

JpaMain

• EntityManagerFactory: EntityManager를 생성한다. 애플리케이션 전체에서 하나만 생성한다.
• EntityManager: JPA의 핵심 객체이다. (엔티티 저장, 엔티티 조회, 엔티티 수정, 엔티티 삭제)
• 트랜잭션: JPA의 모든 데이터 변경 작업은 트랜잭션 안에서 실행해야 한다.

  package hellojpa;
  

import javax.persistence.*; import java.util.List;

public class JpaMain { public static void main(String[] args) {

    // 엔티티 매니저 팩토리 - 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");

    // 엔티티 매니저 - 생성
    EntityManager em = emf.createEntityManager();

    // 트랜잭션 - 획득
    EntityTransaction tx = em.getTransaction();

    try {
        tx.begin();
        logic(em);
        tx.commit();
    } catch (Exception e) {
        tx.rollback();
    } finally {
        em.close();
    }
    emf.close();
}

// 비지니스 로직
private static void logic(EntityManager em) {
    String id = "id1";
    Member member = new Member();
    member.setId(id);
    member.setUsername("유정");
    member.setAge(2);

    // 등록
    em.persist(member);
    // 수정
    member.setAge(20);
    // 한 건 조회
    Member findMember = em.find(Member.class, id);
    System.out.println("findMember=" + findMember.getUsername() + ", age=" + findMember.getAge());
    // 목록 조회
    List<Member> members = em.createQuery("select m from Member m", Member.class).getResultList();
    System.out.println("members.size=" + members.size());

    // 삭제
    em.remove(member);
}

} ```

JPA를 사용하면 SQL 자체보다 내가 만든 객체에 더 집중할 수 있다. 데이터베이스가 바뀌더라도(MySQL → Oracle 등) 애플리케이션 코드를 크게 바꾸지 않고 유지보수하기 쉬워진다.

예전에는 보통 다음과 같은 흐름으로 개발했다:

• ORM 이전: Java → JDBC → SQL → DB

  개발자가 직접 SQL을 작성하고, 조회 결과를 다시 자바 객체로 하나하나 매핑해야 했다.

• ORM 이후: Java 객체 → ORM → SQL → DB

  개발자는 객체 중심으로 개발하고, ORM이 중간에서 SQL 생성과 매핑을 도와준다.

즉, ORM은 객체와 관계형 데이터베이스 사이의 번역기 같은 역할을 한다. 자바는 객체를 사용하고 데이터베이스는 테이블을 사용하므로 둘 사이에는 구조 차이가 있다. ORM은 이 차이를 줄여 주어서 개발자가 조금 더 자연스럽게 객체지향적으로 개발할 수 있게 해준다.

1. SQL을 직접 다룰 때 발생하는 문제점

반복

ex: 회원 정보를 조회한다고 해보자.

1. 조회용 SQL을 직접 작성한다.
2. JDBC API를 사용해서 SQL을 실행한다.
3. 결과(ResultSet)를 꺼내서 자바 객체에 하나씩 넣는다.

아래와 같이 Member 객체와 MemberDAO가 있다고 가정해보자.

public class Member {
    private String memberId;
    private String name;
}

public class MemberDAO {
    public Member find(String memberId) {
        // DB에서 회원을 조회하는 로직이 들어간다
        return null;
    }
}

겉으로 보면 find() 메서드 하나만 있으면 될 것 같지만 실제 내부에서는 꽤 많은 코드가 필요하다.

ex: DB 연결 얻기, SQL 문자열 작성, PreparedStatement 생성, 파라미터 바인딩, SQL 실행, ResultSet 조회, 컬럼 값을 꺼내서 Member 객체에 저장, 자원 반납(Connection, Statement, ResultSet 닫기)

→ 비즈니스 로직보다 JDBC 처리 코드가 더 많이 보이는 경우가 많다.

SQL에 의존적인 개발

SQL을 직접 다루면 자바 코드가 데이터베이스 구조에 강하게 묶이게 된다.

ex: 회원 연락처를 추가할 때 겉보기에는 필드 하나 추가한 것뿐이지만 실제로는 수정할 것이 많다.

// 회원 클래스에 연락처 필드 추가
pulic class Member {
    private String memberId;
    private String name;
    private String tel;
}

수정해야 하는 부분

• 자바 객체에 필드 추가
• DB 테이블에 컬럼 추가
• INSERT SQL 수정
• UPDATE SQL 수정
• SELECT SQL 수정
• ResultSet 매핑 코드 수정

계층 분할이 어려워진다

객체지향적으로 설계하면 보통 다음처럼 생각한다.

• Member는 회원 객체다
• Team은 팀 객체다
• 회원은 한 팀에 속할 수 있다

자바 코드에서는 자연스럽게 이렇게 표현하고 싶어진다.

member.getTeam();

하지만 SQL 중심으로 개발하면 그렇게 단순하지 않다.

member.getTeam()을 호출한다고 자동으로 팀 정보가 나오는 것이 아니다. 개발자는 먼저 DAO 안을 열어 보고 어떤 SQL이 실행되고 있는지 확인해야 한다. (회원만 조회하는 SQL인지, 팀까지 조인해서 조회하는 SQL인지, 팀은 따로 다시 조회해야 하는지..)

→ 객체를 사용하는 입장에서는 그냥 member.getTeam() 하면 될 것 같지만, 실제로는 DAO 내부 SQL 구현을 알아야만 동작을 예측할 수 있다.

JPA와 문제 해결

JPA를 사용하면 개발자가 SQL을 직접 다루기보다 엔티티 객체를 중심으로 개발하게 된다.

// 저장 기능
jpa.persist(member);

// 조회 기능
String memberId = "helloId";
Member member = jpa.find(Member.class, memberId);

// 수정 기능
Member member = jpa.find(Member.class, memberId);
member.setName("이름변경")

// 연관된 객체 조회
Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam();

필요한 시점에 JPA가 적절한 SELECT SQL을 실행해서 팀 정보를 가져온다 → 개발자는 “이 시점에 조인 SQL을 직접 날려야 하나?”를 덜 고민하게 된다.

2. 패러다임의 불일치

상속

• 문제점: 객체는 상속 구조를 사용할 수 있지만 데이터베이스에는 상속 개념이 없다. JDBC를 사용하면 insert 시 여러 SQL을 작성해야 하고, 조회할 때는 여러 테이블을 JOIN 해야 한다.
• JPA 해결: JPA는 객체 상속 구조를 그대로 저장할 수 있게 해 준다.

연관관계

• 문제점: 객체는 참조로 관계를 표현하지만 데이터베이스는 외래 키로 관계를 표현한다.
• JPA 해결: 객체 참조만 설정하면 JPA가 외래 키를 자동으로 관리한다.

member.setTeam(team);
em.persist(member);

객체 그래프 탐색

• 문제점: JDBC에서는 객체처럼 자유롭게 탐색하기 어렵고 필요한 SQL을 직접 작성해야 한다.
• JPA 해결: 객체처럼 자연스럽게 탐색할 수 있다.

Member member = em.find(Member.class, 1L);
Team team = member.getTeam();

비교

• 문제점: DB는 PK 값으로 데이터를 비교하고 객체는 equals()로 객체를 비교한다.
• JPA 해결: JPA는 같은 트랜잭션일 때 같은 객체가 조회되는 것을 보장한다.

3. JPA란 무엇일까?

• ORM (Object-Relational Mapping): 객체와 관계형 데이터베이스를 매핑한다.
• JPA(Java Persistence API)는 자바 진영의 ORM 기술 표준이다. (JPA는 실제 ORM 엔진이 아니라 ORM 기술의 규격이다. 실제 동작은 Hibernate, EclipseLink 같은 구현체가 수행한다.)

개발자는 JPA API를 사용하여 객체 중심으로 코드를 작성한다. 그러면 JPA 구현체가 내부적으로 SQL을 생성하여 데이터베이스와 통신한다.

개발자 코드
     |
     v
JPA API
(EntityManager, @Entity, @Id ...)
     |
     v
JPA 구현체 (Implementation)
------------------------------
| Hibernate                  |
| EclipseLink                |
| DataNucleus                |
------------------------------
     |
     v
SQL 생성
     |
     v
Database

JPA를 사용하면 생산성 향상, 유지보수 용이성, 객체와 관계형 데이터베이스 사이의 패러다임 불일치 해결 그리고 데이터 접근 추상화를 통한 벤더 독립성 등의 장점을 얻을 수 있다.

JPA를 사용하면 SQL 중심 개발에서 벗어나 객체 중심 개발이 가능해진다.

관계형 데이터베이스(Relational Database)를 제대로 사용하려면 단순히 데이터를 저장하는 것만으로는 부족하다. 실제로 서비스를 운영하다 보면 데이터 조회, 성능, 설계, 안정성까지 모두 고려해야 한다.

대표적으로 중요한 요소는 다음 네 가지다:

• SQL
• Index
• Modeling
• Backup

(1) SQL - 데이터베이스의 기본 언어

관계형 데이터베이스를 다루기 위해서는 SQL을 이해하고 잘 사용할 수 있어야 한다. SQL은 데이터베이스와 대화하는 언어다.

SQL에는 여러 종류의 명령이 있지만 그 중에서도 가장 중요한 것은 SELECT이다. 실제 서비스에서는 데이터를 저장하는 것보다 데이터를 조회하는 일이 훨씬 많기 때문이다. (ex: 유튜브 영상 업로드 1번에 조회수 수백만 번, 쇼핑몰 상품 등록 1번에 상품 조회 수천 번…)

그래서 데이터베이스에서는

데이터를 얼마나 빠르고 정확하게 조회할 수 있는지가 매우 중요하다.

(2) Index - 데이터를 빠르게 찾는 방법

데이터가 적을 때는 문제가 없지만 데이터가 많아지면 검색 속도가 느려질 수 있다. 이때 사용하는 것이 인덱스이다.

ex: 책에서 특정 내용을 찾는다고 생각해보자

• 인덱스가 없는 경우 처음 페이지부터 끝까지 다 읽어야 한다.

page 1 → page 2 → page 3 → ... → page 500

• 인덱스가 있는 경우 목차에서 바로 찾을 수 있다

index → page 327

데이터베이스에서도 같은 원리가 적용된다. 예를 들어 title 컬럼에 index가 있다면

SELECT * FROM topic WHERE title='MySQL';

이 검색을 훨씬 빠르게 수행할 수 있다.

(3) Modeling – 좋은 데이터 구조 설계

데이터가 많아질수록 테이블 구조를 잘 설계하는 것이 매우 중요하다. 이 과정을 데이터 모델링(Data Modeling)이라고 한다.

ex: 다음과 같은 테이블이 있다고 생각해보자.

user
-------------------
id
name
email
phone
address

그리고 게시글을 저장하는 테이블이 있다.

post
-------------------
id
title
content
user_name
user_email
user_phone

이 구조에는 같은 정보가 여러 번 저장되어 있다. 사용자가 전화번호를 바꾸면 user 테이블, post 테이블 둘 다 수정해야 한다. 그래서 보통 다음처럼 설계한다:

user
-------------------
id
name
email
phone

post
-------------------
id
title
content
user_id

이렇게 하면 데이터 중복이 줄어들고 관리가 쉬워진다. 이 과정을 정규화(Normalization)라고 한다. 좋은 데이터 모델링은 데이터 중복 감소, 데이터 일관성 유지, 유지보수 편리 같은 장점을 만든다.

(4) Backup – 데이터 보호

데이터베이스에서 가장 중요한 것 중 하나가 백업이다. 왜냐하면 데이터는 언제든지 사라질 수 있기 때문이다.

ex: 하드디스크 고장, 서버 오류, 실수로 데이터 삭제, 해킹,…

그래서 실제 서비스에서는 정기적으로 백업을 수행한다.

최근에는 클라우드를 많이 사용한다. 대표적인 클라우드 서비스: AWS (Amazon Web Services), Google Cloud, Microsoft Azure… 클라우드를 사용하면 자동 백업, 데이터 복구, 안정적인 저장 같은 기능을 쉽게 사용할 수 있다.

마무리

웹 애플리케이션을 개발하다 보면 자연스럽게 느끼게 되는 것이 하나 있다. 웹 서비스는 결국 데이터와 함께 돌아간다는 것이다. (ex: 회원가입을 하면 사용자 정보가 저장된다, 게시글을 작성하면 글 내용이 저장된다, 로그인하면 저장된 정보와 비교해서 인증을 한다)

프로그래밍 언어마다 데이터베이스에 연결하기 위한 라이브러리나 API가 존재한다. ex: Python MySQL API, PHP MySQL API, Java MySQL API. 이러한 API를 통해 웹 애플리케이션은 데이터베이스와 연결되어 데이터를 저장하고 조회하며 실제 서비스가 동작하게 된다.

이번 강의에서는 관계형 데이터베이스가 왜 필요한지 살펴보고, JOIN을 통해 데이터를 연결하는 방법과 MySQL을 사용하는 기본 환경을 간단히 알아본다.

관계형 데이터베이스의 필요성

• 유지 보수가 쉽다
• 중복된 데이터 제거가 쉽다
• 서로 다른 데이터를 연결할 수 있다 (관계형 데이터베이스의 꽃!)

ex: 만약 파일이나 하나의 테이블에 모든 정보를 같이 저장하면 다음과 같이 된다.

이 경우 같은 작성자가 여러 글을 쓰면 작성자 정보가 계속 반복 저장된다.

→ 이메일이 바뀌면 모든 row를 수정해야 한다. 데이터 중복이 많아지고 유지 보수가 어려워진다.

관계형 데이터베이스에서는 데이터를 테이블로 나누고 관계를 만든다.

(1) author 테이블

(2) post 테이블

이렇게 하면 작성자 정보는 한 번만 저장하고 게시글에서는 author_id로 연결한다. 데이터 중복이 줄어들고 관리가 훨씬 쉬워진다.

이처럼 서로 다른 데이터를 연결해 구조적으로 관리할 수 있는 것이 관계형 데이터베이스의 핵심이다.

JOIN - 관계형 데이터의 꽃

관계형 데이터베이스의 가장 큰 특징은 여러 테이블에 저장된 데이터를 서로 연결해서 조회할 수 있다는 것이다. 이때 사용하는 SQL 구문이 바로 JOIN이다.

ex: 다음과 같이 두 개의 테이블이 있다.

• author 테이블

• topic 테이블

여기서 topic 테이블의 author_id는 작성자 테이블(author)의 id를 참조하는 값이다. 즉 topic.author_id = [author.id](http://author.id/)

→ 이 관계를 이용하면 게시글 정보와 작성자 정보를 함께 조회할 수 있다.

JOIN을 사용하면 여러 테이블에 나누어 저장된 데이터를 연결하여 조회할 수 있다. 대표적인 JOIN의 종류는 다음과 같다:

• INNER JOIN: 두 테이블 모두에 존재하는 데이터만 조회
• LEFT JOIN : 왼쪽 테이블의 모든 데이터 유지
• RIGHT JOIN: 오른쪽 테이블의 모든 데이터 유지

-- topic 테이블과 author 테이블을 LEFT JOIN으로 연결
SELECT * FROM topic LEFT JOIN author ON topic.author_id=author.id;

-- 필요한 컬럼만 선택해서 조회
SELECT topic.id,title,description,created,name,profile FROM topic LEFT JOIN author ON topic.author_id=author.id;

→ 게시글 정보와 작성자 정보들은 다른 테이블에 저장되지만 JOIN 통해 한눈에 확인할 수 있다.

인터넷과 데이터베이스

인터넷은 여러 컴퓨터가 서로 통신할 수 있도록 연결해 주는 네트워크이다. 컴퓨터들은 인터넷을 통해 서로 요청(Request) 과 응답(Response) 을 주고받는다. 대표적인 구조가 바로 Client – Server 구조이다.

Client   ── 요청 ──▶  Server
Client   ◀─ 응답 ──   Server

데이터베이스도 같은 구조로 동작한다.

Database Client ── SQL Query ──▶ Database Server ── 데이터 처리 ──▶ 결과 반환 ──▶ Database Client

• MySQL Server: 데이터를 저장하고 관리하는 프로그램
• MySQL Client: 서버에 접속해서 SQL을 실행하는 프로그램

현재 실습에서 사용하고 있는 프로그램은 MySQL Client이다. mysql -uroot -p 로 MySQL 접속하면 영문으로 “Welcome to the MySQL monitor” 볼 수 있다. 여기서 말하는 MySQL monitor는 터미널에서 사용하는MySQL command line client를 의미한다. 즉, 우리가 SQL을 입력하고 결과를 확인하는 CLI(Command Line Interface) 기반 MySQL Client이다.

또 다른 MySQL Client로 MySQL Workbench가 있다. MySQL Workbench는 GUI기반 MySQL Client이다. 즉, 터미널 대신 그래픽 화면을 통해 데이터베이스를 관리할 수 있는 프로그램이다.

MySQL Workbench

다운로드: https://www.mysql.com/products/workbench/

앞에서 사용한 MySQL monitor는 터미널에서 SQL을 직접 입력해야 하는 CLI 방식이었다. 반면 MySQL Workbench는 GUI를 통해 데이터베이스를 관리할 수 있다.

ex: SQL 쿼리를 입력하고 실행하거나 데이터 조회 결과를 표 형태로 바로 확인할 수 있다.

MySQL Workbench를 사용하면 SQL 실행뿐 아니라 데이터베이스 서버의 상태, 성능, 사용자 관리 등 다양한 작업을 한 곳에서 관리할 수 있다.

이번 강의에서는 데이터베이스에서 가장 기본적인 작업인 CRUD(Create, Read, Update, Delete) 개념을 살펴본다.

지난 실습에서 생성한 topic 테이블의 구조를 확인하기 위해 DESC topic 명령어를 사용한다. 실행 결과는 다음과 같다.

INSERT 구문 (Create)

새로운 데이터를 테이블에 추가할 때 INSERT 구문을 사용한다.

INSERT INTO topic (title, description, created, author, profile)
VALUES('MySQL', 'MySQL is ...', NOW(), 'trang', 'developer');
-- topic 테이블에 새로운 게시글 데이터를 추가한다
-- NOW() : 현재 날짜와 시간을 자동으로 입력한다

SELECT 구문 (Read)

데이터를 조회할 때는 SELECT 구문을 사용한다.

-- topic 테이블의 모든 컬럼과 모든 데이터를 조회
SELECT * FROM topic;

-- 필요한 컬럼만 선택해서 조회
SELECT id,title,created,author FROM topic;

-- author가 'trang'인 데이터만 조회
SELECT id,title,created,author FROM topic WHERE author='trang';

-- id 기준으로 내림차순 정렬 (최신 글이 먼저 나오게)
SELECT id,title,created,author FROM topic WHERE author='trang' ORDER BY id DESC;

-- 결과를 3개 row까지만 조회
SELECT * FROM topic LIMIT 3;

UPDATE 구문

기존 데이터를 수정할 때 UPDATE 구문을 사용한다.

-- id가 2인 row의 title과 description을 수정
UPDATE topic SET description='Oracle is ...', title='Oracle' WHERE id=2;

• 주의: WHERE 조건을 넣지 않으면 테이블의 모든 데이터가 수정될 수 있다.

DELETE 구문

데이터를 삭제할 때는 DELETE 구문을 사용한다.

-- id가 5인 데이터를 삭제
DELETE FROM topic WHERE id=5;

• 주의: WHERE 조건이 없으면 테이블의 모든 데이터가 삭제된다.

정리

데이터베이스에서 데이터를 다룰 때 가장 기본이 되는 작업은 CRUD이다.

CREATE → INSERT
READ   → SELECT
UPDATE → UPDATE
DELETE → DELETE

각각의 SQL 구문을 통해 데이터를 추가하고, 조회하고, 수정하고, 삭제할 수 있다.

또한 UPDATE나 DELETE를 사용할 때는 반드시 WHERE 조건을 확인해야 한다!

실습 tips: MySQL cheating sheet 검색하면 주요 SQL 문법과 예시를 빠르게 확인할 수 있다.

실습: 테이블의 생성

먼저 사용할 데이터베이스를 선택한다.

USE opentutorials

다음으로 topic이라는 테이블을 생성한다.

CREATE TABLE topic (
  id INT(11) NOT NULL AUTO_INCREMENT,
  title VARCHAR(100) NOT NULL,
  description TEXT NULL,
  created DATETIME NOT NULL,
  author VARCHAR(15) NULL,
  profile VARCHAR(200) NULL,
  PRIMARY KEY(id)
);

이 테이블은 게시글 정보를 저장하는 간단한 구조이다. 각 컬럼의 의미는 다음과 같다:

id

id INT(11) NOT NULL AUTO_INCREMENT,

• INT : 정수형 데이터 타입
• NOT NULL : 값이 반드시 있어야 한다
• AUTO_INCREMENT : 새로운 데이터가 추가될 때마다 값이 자동으로 1씩 증가한다. (게시글마다 고유한 id 위해 꼭 넣어 줘야 함!)

title

title VARCHAR(100) NOT NULL

• VARCHAR(100) : 최대 100자의 문자열을 저장할 수 있다
• NOT NULL : 제목은 반드시 있어야 하므로 NULL을 허용하지 않는다

description

description TEXT NULL

• TEXT : 긴 문자열을 저장할 수 있는 타입
• NULL : 값이 없어도 허용한다. 본문은 길어질 수 있기 때문에 VARCHAR 대신 TEXT 타입을 사용한다.

created

created DATETIME NOT NULL

• DATETIME : 날짜와 시간을 함께 저장하는 데이터 타입
• NOT NULL : 게시글이 생성된 시간은 반드시 기록되어야 한다.

author

author VARCHAR(15) NULL

• VARCHAR(15) : 최대 15자의 문자열을 저장할 수 있다
• NULL : 작성자가 없는 경우도 허용한다

profile

profile VARCHAR(200) NULL

• VARCHAR(200) : 최대 200자의 문자열을 저장할 수 있다.

PRIMARY KEY

PRIMARY KEY(id)

PRIMARY KEY는 각 행을 구분하는 유일한 값을 의미한다. 이 테이블에서는 id 컬럼을 기본 키로 사용한다.

주의점: AUTO_INCREMENT와 PRIMARY KEY

id 컬럼을 보면 AUTO_INCREMENT 옵션이 붙어 있다. AUTO_INCREMENT는 데이터가 추가될 때 값이 자동으로 1씩 증가하도록 하는 기능이다.

→ AUTO_INCREMENT를 사용하는 컬럼은 반드시 KEY로 정의되어야 한다. 보통은 PRIMARY KEY 로 설정한다.

테이블이 잘 생성되었는지 확인하려면 SHOW TABLES 명령어 사용한다. 여기에서 topic 테이블이 보이면 정상적으로 생성된 것이다.

정리

이번 실습 에서는 다음 내용을 확인했다.

• USE : 사용할 데이터베이스 선택
• CREATE TABLE : 새로운 테이블 생성
• VARCHAR, TEXT, DATETIME ,… : 컬럼에 사용할 데이터 타입 지정
• AUTO_INCREMENT : 데이터 추가 시 값 자동 증가
• PRIMARY KEY : 각 row를 구분하는 고유 키 설정
• SHOW TABLES : 생성된 테이블 확인

MySQL의 구조

데이터베이스의 구조를 간단하게 보면 다음과 같다:

Database Server
┌───────────────────────────────────────────────────────────────┐
│                                                               │
│   Database                                                    │
│   ┌───────────────────────────────────────────────┐           │
│   │                                               │           │
│   │   Table            Table            Table     │           │
│   │  ┌───────┐        ┌───────┐        ┌───────┐  │           │
│   │  │ row   │        │ row   │        │ row   │  │           │
│   │  │ row   │        │ row   │        │ row   │  │           │
│   │  │ row   │        │ row   │        │ row   │  │           │
│   │  └───────┘        └───────┘        └───────┘  │           │
│   │                                               │           │
│   └───────────────────────────────────────────────┘           │
│                                                               │
│   Database                                                    │
│   ┌───────────────────────────────────────────────┐           │
│   │   Table        Table        Table             │           │
│   └───────────────────────────────────────────────┘           │
│                                                               │
└───────────────────────────────────────────────────────────────┘

(1) Database Server: 여러 개의 데이터베이스를 관리하는 시스템이다. MySQL 프로그램이 실행되는 환경이라고 볼 수 있다.

(2) Database: 여러 개의 테이블을 포함하는 공간이다.

(2) Table: 실제 데이터가 저장되는 구조다.

MySQL 서버 접속

MySQL 서버에 접속하려면 터미널에서 다음 명령어를 사용한다: mysql -u root -p

MySQL 스키마의 사용

• 스키마 생성, 삭제:

• 스키마 목록 확인:

• 스키마 선택해서 사용:

SQL과 테이블 구조

• SQL: Structured Query Language
• 예를 들어 하나의 테이블은 다음과 같은 구조를 가진다.

  table
  ├─ row
  │   ├─ column
  │   ├─ column
  │   └─ column
  └─ row

파일 기반으로 데이터를 관리할 때 여러 가지 한계가 있었다. 이 문제를 해결하기 위해 1960년대부터 데이터베이스 연구가 시작된다. 1970년에는 Edgar F. Codd가 IBM에서 관계형 데이터베이스(Relational Database) 개념을 제안한다.

이후 수십 년이 지난 지금까지도 관계형 데이터베이스는 가장 널리 사용되는 데이터베이스 모델이다. (ex: MySQL, Oracle, SQL Server, PostgreSQL, Db2, Access)

MySQL은 무료로 사용할 수 있는 오픈소스 소프트웨어이며 성능도 준수한 관계형 데이터베이스다. 그래서 웹 개발에서 많이 사용되는 데이터베이스 중 하나이자 좋은 대안으로 자주 언급된다.

데이터베이스의 목적

데이터베이스를 이해할 때 스프레드시트와 비교해 보면 이해하기 쉽다.

공통점

(1) 데이터를 표 형태로 저장한다

(2) 필터나 정렬 기능으로 데이터를 정리할 수 있다

차이점

스프레드시트: 사용자가 직접 화면에서 클릭하면서 데이터를 조회하고 수정한다.

데이터베이스 (MySQL): 프로그래밍 언어를 통해 데이터를 조작할 수 있다. 프로그램에서 자동으로 데이터를 처리할 수 있다.

→ 스프레드시트는 사람이 직접 다루는 도구 vs 데이터베이스는 프로그램이 데이터를 다루기 위한 시스템이다.

웹 서비스에서는 데이터베이스가 핵심 역할을 한다. 예를 들어 회원가입을 하면 사용자 정보가 데이터베이스에 저장된다. 로그인을 하면 서버가 데이터베이스에서 사용자 정보를 조회한다. → 그래서 데이터베이스는 웹 서비스의 데이터를 관리하는 기반 시스템이라고 볼 수 있다.

MySQL 설치 (macOS 환경 기준)

아래 링크에 접속하면 다운로드할 수 있다:

https://dev.mysql.com/downloads/mysql/

설치

• 다운로드한 파일을 실행하면 설치가 시작된다.
• 주의: Accounts and Roles 화면에서 사용자 비밀번호를 입력해야 한다.

설정

• MySQL 실행 파일이 다음 경로에 설치된다. /usr/local/mysql/bin
• 터미널에서 MySQL 명령어를 바로 사용하려면 PATH 환경변수에 이 경로를 추가해야 한다.

# step 1: 터미널에서 설정 파일을 연다.
nano ~/.zshrc

# step 2: 다음 내용을 추가한다.
export PATH=$PATH:/usr/local/mysql/bin

# step 3: 설정을 적용한다.
source ~/.zshrc

# 이제 터미널에서 다음 명령어로 MySQL에 접속할 수 있다.
mysql -u root -p

이제 Enter password: 에 사용자 지정한 비밀번호를 입력하면 된다

• mysql 클라이언트 종료하기: mysql> exit

첫번째 강의에서는 데이터베이스의 기본 개념을 먼저 잡는다.

데이터베이스의 본질

데이터베이스의 핵심은 결국 CRUD다.

입력:

• 생성 → Create
• 수정 → Update
• 삭제 → Delete

출력:

• 조회 → Read

데이터를 생성하고, 읽고, 수정하고, 삭제하는 것이 데이터베이스가 하는 가장 기본적인 작업이다.

File vs Database

File

파일로 데이터를 관리하면 구조적으로 다루기 어렵다. (ex: 텍스트 파일을 만들면 문장 순서를 바꾸거나 특정 정보만 따로 보기가 쉽지 않다. 제목, 본문 같은 데이터도 원하는 방식으로 조회하기 어렵다…)

Spreadsheet

엑셀처럼 스프레드시트를 사용하면 조금 나아진다. 필터나 정렬 기능을 통해 데이터를 어느 정도 구조적으로 볼 수 있다.

Database

데이터베이스를 사용하면 데이터를 구조적으로 저장하고 관리할 수 있다. 필요한 데이터만 조회하거나 정렬, 필터링하는 것도 훨씬 쉽게 할 수 있다. 데이터가 많아지고 여러 사람이 함께 사용해야 할 때 특히 유용하다.

Database 1을 마치며

통계를 보면 2026년 기준으로 Oracle이 1위, MySQL이 2위다. (출처: https://db-engines.com/en/ranking) 데이터베이스도 종류가 여러 가지 있다. Oracle, MySQL, PostgreSQL 같은 관계형 데이터베이스 있고 MongoDB처럼 관계형이 아닌 데이터베이스도 있다.

그래서 보통은 관계형 데이터베이스 하나 + 비관계형 데이터베이스 하나 이렇게 같이 배워두면 좋다고 한다. MySQL은 비교적 배우기 쉬워서 입문용 데이터베이스로 많이 추천된다고 한다.

10.1 REST API와 JSON

REST API

• REST API (Representational State Transfer API)는 서버의 자원을 클라이언트에 구애받지 않고 사용할 수 있게하는 설계 방식이다
• 다음과 같이 REST API의 동작을 이해할 수 있다:

[클라이언트들]
 PC / 모바일 / 태블릿 / IoT ...
        │
        │  HTTP 요청
        ▼
+------------------+
|   REST API 서버  |
+------------------+
        │  JSON 응답(뷰X, 데이터O) //서버는 화면이 아닌 데이터(JSON) 를 돌려준다.
        ▼
자원(RESOURCE): /articles
   ├─ GET    /articles          → 글 목록 조회
   ├─ GET    /articles/{id}     → 글 단건 조회
   ├─ POST   /articles          → 글 생성
   ├─ PATCH  /articles/{id}     → 글 부분 수정
   └─ DELETE /articles/{id}     → 글 삭제

JSON

• JSON 데이터는 키(key)와 값(value)으로 구성된 정렬되지 않는 속성(properties)의 집합이다.
  • 키: 큰따옴표 (””)로 감싼다
  • 값: 문자열인 경우만 큰따옴표 (””)로 감싼다

{
    "name": "망고",
    "breeds": "골든리트리버",
    "age": 2
}

10.2 REST API 동작 살펴보기

연습용으로 Talend API Tester 이용해 HTTP 요청을 보내고 돌아온 응답을 확인하겠습니다. {JSON} Placeholder 사이트에서 자원들을 JSON 형식으로 받아 실습해 보겠습니다!

• {JSON} Placeholder 사이트
• Talend API 확장 프로그램 설치

HTTP 상태 코드

HTTP 상태 코드는 클라이언트가 보낸 요청이 성공/실패했는지 알려주는 코드다. 코드는 100번대부터 500번대까지 5개 그룹으로 나눠 있다.

자세한 내용: MDN 웹 문서

GET 요청하고 응답받기

• Method: GET
• URL: https://jsonplaceholder.typicode.com/posts
• 응답: 200 (OK)

POST 요청하고 응답받기

• Method: POST
• URL: https://jsonplaceholder.typicode.com/posts
• 응답: 201 (OK)

PATCH 요청하고 응답받기

• Method: PATCH
• URL: https://jsonplaceholder.typicode.com/posts/1
• 응답: 200 (OK)

DELETE 요청하고 응답받기

• Method: DELETE
• URL: https://jsonplaceholder.typicode.com/posts/10
• 응답: 200 (OK)

11장 - HTTP와 REST 컨트롤러

Part 2에서 만든 firstproject를 이용해 데이터를 CRUD하기 위해 REST API를 구현해 보겠습니다!

• REST API:
  • REST: HTTP URL로 서버의 자원을 명시하고, HTTP 메소드로 해당 자원에 대해 CRUD하는 것
  • API: 클라이언트가 서버의 자원을 요청할 수 있도록 서버에서 제공하는 인터페이스

REST API 구현

GET 구현하기

    // GET
  @GetMapping("/api/articles")
  public List<Article> index() {
      return articleRepository.findAll();
  }

  @GetMapping("/api/articles/{id}")
  public Article show(@PathVariable Long id) {
      return articleRepository.findById(id).orElse(null);
  }

POST 구현하기

• 주의점: @RequestBody 추가해야 본문(BODY)을 받아 올 수 있다!

  // POST
  @PostMapping("/api/articles")
  public Article create(@RequestBody ArticleForm dto) {
      Article article = dto.toEntity();
      return articleRepository.save(article);
  }

PATCH 구현하기

• 주의점: 일부만 수정한 경우: patch 메소드를 만들어야 한다

    // PATCH
  @PatchMapping("/api/articles/{id}")
  public ResponseEntity<Article> update(@PathVariable Long id, @RequestBody ArticleForm dto) {
      // 1. DTO -> 엔티티 변환하기
      Article article = dto.toEntity();
      // 2. 타깃 조회하기
      Article target = articleRepository.findById(id).orElse(null);
      // 3. 잘못된 요청 처리하기
      if(target == null || id != article.getId()) {
          return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(null);
      }
      // 4. 업데이트 및 정상 응답(200)하기
      target.patch(article); // 기존 데이터에 새 데이터 붙이기
      Article updated = articleRepository.save(target); // 수정 내용 DB에 최종 저장
      return ResponseEntity.status(HttpStatus.OK).body(updated);
  }

DELETE 구현하기

  // DELETE
  @DeleteMapping("/api/articles/{id}")
  public ResponseEntity<Article> delete(@PathVariable Long id) {
      // 1. 대상 찾기
      Article target = articleRepository.findById(id).orElse(null);
      // 2. 잘못된 요청 찾기
      if(target == null) {
          return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(null);
      }
      // 3. 대상 삭제하기
      articleRepository.delete(target);
      return ResponseEntity.status(HttpStatus.OK).build();
  }

12장 - 서비스 계층과 트렌잭션

12.1 개념

• 서비스: 컨트롤러와 리포지토리 사이에서 비즈니스 규칙을 수행하고 흐름을 조정한다. 여러 리포지토리 호출을 묶어 트랜잭션 경계를 만든다
• 트랜잭션: 여러 데이터 작업을 하나의 논리적 단위로 묶어 전부 성공하면 커밋하고 하나라도 실패하면 롤백한다

ex:

• 웨이터 = 컨트롤러: 손님(클라이언트) 주문을 받아 전달한다
• 주방장 = 서비스: 어떤 메뉴(비즈니스 로직)를 어떤 순서로 만들지 결정하고 전체를 지휘한다. 여러 하위 작업을 하나의 주문 단위(트랜잭션) 로 묶는다
• 보조요리사 = 리포지토리: 주방장이 지시한 대로 재료 창고(DB) 에서 꺼내고 넣는 CRUD 를 수행한다
• 트랜잭션 = 한 테이블의 코스 전체: 모든 요리가 완성되어야 서빙한다. 하나라도 문제가 나면 전체 취소(롤백) 하고 처음부터 다시 준비한다

12.2 서비스 계층 만들기

이전 11장까지 만든 코드를 요청해 보겠습니다!

수정한 부분:

• service package 만들기
• ArticleApiController 수정하기

ex:

• 수정하기 전:

// controller

  // POST
  @PostMapping("/api/articles")
  public Article create(ArticleForm dto) {
      Article article = dto.toEntity();
      return articleRepository.save(article);
  }

• 수정한 후:

// controller

  // POST
  @PostMapping("/api/articles")
  public ResponseEntity<Article> create(@RequestBody ArticleForm dto) {
      Article created = articleService.create(dto);
      return (created != null) ?
              ResponseEntity.status(HttpStatus.OK).body(created) :
              ResponseEntity.status(HttpStatus.BAD_REQUEST).build();
  }

// service

    public Article create(ArticleForm dto) {
            Article article = dto.toEntity();
            if (article.getId() != null) {
                return null;
            }
            return articleRepository.save(article);
    }

12.3 트랜잭션 맛보기

• ArticleApiController

  @PostMapping("/api/transaction-test")
  public ResponseEntity<List<Article>> transactionTest (@RequestBody List<ArticleForm> dtos) {
      List<Article> createdList = articleService.createArticles(dtos);
      return (createdList != null) ?
              ResponseEntity.status(HttpStatus.OK).body(createdList) :
              ResponseEntity.status(HttpStatus.BAD_REQUEST).build();
  }

• ArticleService

  @Transactional
  public List<Article> createArticles(List<ArticleForm> dtos) {
      // 1. dto 묶음을 엔티티 묶음으로 변환하기
      List<Article> articleList = dtos.stream()
              .map(dto -> dto.toEntity())
              .collect(Collectors.toList());
      // 2. 엔티티 묶음을 DB에 저장하기
      articleList.stream()
              .forEach(article -> articleRepository.save(article));
      // 3. 강제 예외 발생시키기
      articleRepository.findById(-1L)
              .orElseThrow(() -> new IllegalArgumentException("결제 실패!"));
      // 4. 결과 값 반환하기
      return articleList;

  }

→ @Transactional로 메서드 전체를 하나의 트랜잭션으로 묶어 DTO 목록을 엔티티로 변환해 저장한 뒤, 의도적으로 예외를 던져 롤백이 일어나는지 확인한다. 예외가 발생하면 이전에 저장된 작업이 모두 취소되어 DB에 반영되지 않는다!

13장 - 테스트 코드 작성하기

테스트 코드는 보통 3단계로 작성한다:

1. 예상 데이터 작성하기
2. 실제 데이터 획득하기
3. 예상 데이터와 실제 데이터 비교해 검증하기

테스트 코드 작성하기

• 메소드 오른쪽 누르고 Generate → Test 선택. JUnit5로 테스트를 만들겠습니다!

• ArticleSeriveTest 생성 위치를 확인할 수 있다

• 테스트 코드 작성하기:

  @SpringBootTest
  class ArticleServiceTest {
    @Autowired
    ArticleService articleService;
  
    @Test
    void index() {
        // 1. 예상 데이터
        Article a = new Article(1L, "가가가가", "1111");
        Article b = new Article(2L, "나나나나", "2222");
        Article c = new Article(3L, "다다다다", "3333");
        List<Article> expected = new ArrayList<Article>(Arrays.asList(a,b,c));
        // 2. 실제 데이터
        List<Article> articles = articleService.index();
        // 3. 비교 및 검증
        assertEquals(expected.toString(), articles.toString());
    }
    @Test
    void show_성공() {
        // 1. 예상 데이터
        Long id = 1L;
        Article expected = new Article(id, "가가가가", "1111");
        // 2. 실제 데이터
        Article article = articleService.show(id);
        // 3. 비교 및 검증
        assertEquals(expected.toString(), article.toString());
    }
  
    @Test
    void show_실패() {
        // 1. 예상 데이터
        Long id = -1L;
        Article expected = null;
        // 2. 실제 데이터
        Article article = articleService.show(id);
        // 3. 비교 및 검증
        assertEquals(expected, article);
    }
  }

1. 투포인터

2. 1 백준 1253 좋다

3. 슬라이딩 윈도우

4. 1 백준 12891번: DNA 비밀번호

다른 점은 투 포인터의 경우 두 인덱스 start, end를 조건에 따라 독립적으로 이동시키며 구간을 늘리거나 줄여서 배열을 탐색합니다.

반면 슬라이딩 윈도우는 고정 크기의 윈도우를 유지한 채 한 칸씩 이동하면서 들어오는 원소 && 빠지는 원소만 O(1)로 반영해 문제를 해결합니다.

1. 투 포인터

• 투 포인터는 두 개의 포인터 start(left), end(right) 이용해 값을 탐색하는 알고리즘입니다.

1.1) 1253 좋다

• sort() 함수를 이용해 배열 정렬해 줍니다
• 배열 양 끝에서 i(start)=0 와 j(end)=N-1 포인터를 지정해 두 수의 합이 find과 같으면 res 증가 시켰습니다

#include<iostream>
#include<vector>
#include<algorithm>
using namespace std;

int main() {
    ios::sync_with_stdio(false);
    cin.tie(NULL);
    cout.tie(NULL);

    int N;
    cin >> N;
    vector<int> A(N,0);

    for(int i=0;i<N;i++) {
        cin >> A[i];
    }

    sort(A.begin(), A.end());
    int res = 0;

    for(int k=0; k<N; k++) {
        long find = A[k];
        int i = 0, j = N-1;

        while(i < j) {
            if(A[i] + A[j] == find) {
                if(i != k && j != k) { //서로 다른 수의 합인지 체크
                    res++;
                    break;
                }
                else if (i==k) i++;
                else if (j==k) j--;
            }
            else if(A[i] + A[j] < find) i++;
            else j--;
        }
    }

    cout << res;
}

2. 슬라이딩 윈도우

슬라이딩 윈도우는 투 포인터와 유사한데 윈도우의 크기는 고정됩니다.

2.1) 12891번: DNA 비밀번호

• 문제 요약: 문자열이 {A, C, G, T} 로만 이루어진 DNA 문자열에서 길이 S의 모든 부분문자열을 검사해 각 문자 A, C, G, T가 최소 몇 번 이상 등장해야 한다는 조건을 모두 만족하면 비밀번호로 인정하여 개수를 센다

• 풀이 과정:

  • Step 1: 체크 배열(checkArr) 저장
  • Step 2: 윈도우에 포함된 문자로 현재 상태 배열 (myArray) 만든다. myArr && checkArr 비교
  • Step 3: 3: 윈도우를 한 칸씩 이동해 myArr 업데이트한다. 계속해서 myArr && checkArr 비교한다

#include<iostream>
using namespace std;

int checkArr[4];
// myArr[i]: 슬라이딩 윈도우 안에서 각 문자가 나온 현재 개수
int myArr[4];
// check: 4가지 조건(A/C/G/T) 중에서 요구에 도달한 항목 수
int check = 0;
void Add(char c);
void Remove(char c);

void Add(char c) { //새로 들어온 문자를 처리하는 함수
    switch (c) {
        case 'A':
            myArr[0]++;
            if (myArr[0] == checkArr[0]) check++;
            break;
        case 'C':
            myArr[1]++;
            if (myArr[1] == checkArr[1])  check++;
            break;
        case 'G':
            myArr[2]++;
            if (myArr[2] == checkArr[2])  check++;
            break;
        case 'T':
            myArr[3]++;
            if (myArr[3] == checkArr[3])  check++;
            break;
    }
}

void Remove(char c) { //제거할 문자를 처리하는 함수
    switch(c) {
        case 'A':
            if (myArr[0] == checkArr[0]) check--;
            myArr[0]--;
            break;
        case 'C':
            if (myArr[1] == checkArr[1]) check--;
            myArr[1]--;
            break;
        case 'G':
            if (myArr[2] == checkArr[2]) check--;
            myArr[2]--;
            break;
        case 'T':
            if (myArr[3] == checkArr[3]) check--;
            myArr[3]--;
            break;
    }
}

int main() {
    ios::sync_with_stdio(false);
    cin.tie(NULL);
    cout.tie(NULL);

    int S, P;
    cin >> S >> P;
    int Result = 0;
    string A;
    cin >> A;

    for(int i=0;i<4;i++) {
        cin >> checkArr[i];
        if(checkArr[i] == 0) {
            check++;
        }
    }

    // 초기 윈도우: [0, P-1] 구간을 먼저 반영
    for(int i=0; i<P; i++) {
        Add(A[i]);
    }
    // 초기 윈도우가 4가지 조건을 모두 만족하면 결과 +1
    if(check == 4) {
        Result++;
    }

    //슬라이딩 윈도우 처리 부분
    for(int i=P; i<S; i++) {
        int j = i-P; // i: 새로 들어오는 문자의 인덱스, j: 빠져나가는 문자의 인덱스
        Add(A[i]);
        Remove(A[j]);
        if (check == 4) {
            Result++;
        }
    }
    cout << Result << "\n";
}

*이 글은 교재 "Do it! 알고리즘 코딩 테스트 C++" 기반으로 작성했습니다!

6.1 링크와 리다이렉트

• 링크(link): 사용자가 <a>나 <form>을 통해 다른 페이지로 이동하겠다는 요청만 전달하고 그 결과 페이지를 그대로 응답받는 단순 내비게이션 기능이다
• 리다이렉트(redirect): 서버가 요청을 처리한 뒤 ‘다음으로 갈 주소’를 클라이언트에 지시하여 다시 요청하게 만드는 방식이다

6.2 링크와 리다이렉트를 이용해 페이지 연결하기

• 새 글 작성 링크 만들기

<a href="/articles/new">New Article</a>

• <목록 페이지> → <목록 페이지> 돌아가기

<a href="/articles">Back</a>

• <입력 페이지> → <상세 페이지> 이동하기

  • 리다이렉드: 클라이언트의 요청를 받아 새로운 URL 주소로 재요청하라고 지시하는 것이다

    return "redirect:URL_주소";

• <상세 페이지> → <목록 페이지> 돌아가기

//show.mustache
<a href="/articles">Go to Article List</a>

• <목록 페이지> → <상세 페이지> 이동하기

 <td colspan="2"><a href="/articles/{{id}}">{{title}}</td>

7장 - 데이터 수정 과정

- 1단계: <수정 페이지> 만들고 기존 데이터 불러오기

[목록 페이지] 
    │ (항목 클릭)
    v
[상세 페이지]
    │ (Edit 버튼)
    v
[컨트롤러] ── DB에서 기존 데이터 조회 ──> [모델에 담음]
    │
    v
[수정 폼 페이지 렌더]

- 2단계: 데이터를 수정해 DB에 반영한 후 결과를 볼 수 있게 <상세 페이지>로 리다이렉트하기

[수정 폼 페이지] --(Submit: 폼데이터)--> [컨트롤러]
    │                                             
    └─ DTO 생성 → 엔티티로 변환/병합 → 리포지토리.save() → DB 갱신
                                                    │
                                                    v
                                리다이렉트(결과 확인용 페이지 또는 목록)

HTTP 메소드

• HTTP(HyperText Transfer Protocol)는 웹 서비스에 사용하는 프로토콜이다
• HTTP의 대표적인 메서드:
  • POST
  • GET
  • PATCH(PUT)
  • DELETE

CRUD를 위한 SQL 문과 HTTP 메서드

8장 - 게시글 삭제하기: DELETE

데이터 삭제 과정

• Step 1: 클라이언트가 HTTP 메서드로 게시글 삭제 요청
• Step 2: 요청 받은 컨트롤러는 리파지터리를 통해 DB에 저장된 데이터를 찾아 삭제한다
• Step 3: 삭제 완료시 클라이언트를 결과 페이지로 리타이렉트한다

[상세 페이지] (Delete 클릭)
      │  POST/GET /articles/{id}/delete
      v
[컨트롤러] ── findById(id) → 존재 확인
      │
      ├─ 존재 O → repository.delete(엔티티)
      │
      └─ 존재 X → 아무 것도 안 함
      v
redirect:/articles  (목록)

[컨트롤러]
  delete 성공 → redirectAttributes.addFlashAttribute("msg", "삭제되었습니다!")
  └─ redirect:/articles
                 │
                 v
        [목록 페이지 index.mustache]
           {{#msg}} 삭제되었습니다! {{/msg}}

SQL 문으로 직접 DB 삭제하기

DELETE [FROM] 테이블면 WHERE 조건;

9장 - CRUD와 SQL 쿼리 종합

9.1 JPA 로깅 설정하기

• 쿼리(query)란 DB에 정보를 요청하는 구문
• SQL 쿼리:
  • INSERT (생성)
  • SELECT (조회)
  • UPDATE (수정)
  • DELETE (삭제)
• 로깅(logging): 시스템이 작동할 때 당시의 상태와 작동 정보를 기록하는 것

# resources/application.properties
# JPA 로깅 설정
# 디버그 레벨로 쿼리 출력
logging.level.org.hibernate.SQL=DEBUG

# 쿼리 줄바꿈하기
spring.jpa.properties.hibernate.format_sql=true

# 매개변수 값 보여 주기
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE

# DB URL 설정
# 유니크 URL 생성하지 않기
spring.datasource.generate-unique-name=false
# 고정 URL 설정하기
spring.datasource.url=jdbc:h2:mem:testdb

• 로깅 레벨은 7단계가 있다:

  • TRACE(레벨1): DEBUG 레벨보다 더 상세한 정보
  • DEBUG(레벨2): 응용 프로그램을 디버깅하는 데 필요한 세부 정보
  • INFRO(레벨3): 응용 프로그램의 순조로운 진행 정보
  • WARN(레벨4): 잠재적으로 유해한 상황 정보
  • ERROR(레벨5): 응용 프로그램이 수행할 수 있는 정도의 오류 정보
  • FATAL(레벨6): 응용 프로그램이 중단될 만한 심각한 오류 정보
  • OFF(레벨7): 로깅 기능 해제

• 서버 실행하고 쿼리 확인:

• H2 Console 접속:

9.2 SQL 쿼리 로그 확인하기

INSERT 문

데이터를 생상(Create)할 때 어떤 SQL 쿼리가 동작하는지 확인해 보겠습니다

SELECT 문

데이터를 조회(Read)할 때 어떤 SQL 쿼리가 동작하는지 확인해 보겠습니다

UPDATE 문

데이터를 수정(UPDATE)할 때 어떤 SQL 쿼리가 동작하는지 확인해 보겠습니다

DELETE 문

데이터를 삭제(DELETE)할 때 어떤 SQL 쿼리가 동작하는지 확인해 보겠습니다

9.3 기본 SQL 쿼리 작성하기

• CREATE TABLE 문의 형식은 다음과 같습니다:

CREATE TABLE 테이블명 (
    속성명1 자료형,
    속성명2 자료형
    속성명3 자료형,
    PRIMARY KEY (기본키)
);

• ex: coffee 테이블을 만들어 보겠습니다

coffee 데이터 생성하기

//데이터 생성하기
****
INSERT
INTO    
        coffee
        (id, name, price) 
VALUES
        (1, '아메리카노', 4100)

coffee 데이터 조회하기

// 데이터 조회하기

SELECT
    id, name, price
FROM
    coffee
WHERE
    id = 3;

coffee 데이터 수정하기

UPDATE
    coffee
SET
    price = 9900
WHERE
    id = 4;

coffee 데이터 삭제하기

DELETE
FROM
    coffee
WHERE
    id = 4;