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;

3.1

• 폼 데이터(form data)는 HTML <form> 태그로 브라우저에서 서버로 전송되는 사용자 입력값이다
• 서버 컨트롤러는 이 값을 DTO(Data Transfer Object)로 받아 처리한 뒤 최종적으로 DB에 저장한다

3.2 💡 실습: 폼 데어터를 DTO로 받기

• Step 1: 입력 폼 만들기
• Step 2: 컨트롤러 만들기

// AritcleController.java
package com.example.firstproject.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public class ArticleController {
    @GetMapping("/articles/new")
    public String newArticleForm() {
        return "articles/new";
    }
}

• Step 3:  품 데이터 전송하기
  • action 속성: 어디에 데이터 보낼지
  • method 속성: 어떻게 데이터 보낼지

//templates/articles/new.mustache
<form class="container" action="/articles/create" method="post">

• Step 4:  품 데이터 받기

@PostMapping 만들기

    @PostMapping("articles/create")
    public String createArticle() {
        return "";
    }

• Step 5: DTO 만들기

  • com.example.firstproject 에서 dto packege 생성

  • dto 패키지에 ArticleFrom 클래스 생성

    package com.example.firstproject.dto;
    
    public class ArticleForm {
    
      private String title;
      private String content;
    
          //전송받은 제목과 내용을 필드에 저장하는 생성자 추가
      public ArticleForm(String title, String content) {
          this.title = title;
          this.content = content;
      }
    
          //데이터를 잘 받았는지 확인할 toString() 메소드 추가
      @Override
      public String toString() {
          return "ArticleForm{" +
                  "title='" + title + '\'' +
                  ", content='" + content + '\'' +
                  '}';
      }
    }

• Step 6: 품 데이터를 DTO에 담기

//ArticleController.java
  @PostMapping("articles/create")
  public String createArticle(ArticleForm form) {
      System.out.println(form.toString());
      return "";
  }

• Step 7: 입력 폼과 DTO 필드 연결하기

3.3 DTO를 데이터베이스에 저장하기

데이터베이스와 JPA

• JPA: JAVA ↔ DB 명령을 내리는 도구. JPA의 핵심 도구:
  • entity: 자바 객체를 DB가 이해할 수 있게 만든 것
  • repository: 엔티티가 DB속 테이블에 저장 및 관리하게 만든 것

DTO를 엔티티로 변환하기 && 리파지터리로 엔티티를 DB에 저장하기

[브라우저 폼 제출]
        │  POST /articles/create
        ▼
[Spring MVC]
  - 요청 파라미터 바인딩 → ArticleForm (DTO) 생성
        ▼
[Controller]
  - form.toEntity() 호출 → Article (Entity)로 변환
        ▼
[Repository (JPA)]
  - articleRepository.save(entity) → DB 저장
        ▼
[응답]
  - redirect 또는 뷰 렌더링

src/main/java/com/example/firstproject
├─ controller/
│  └─ ArticleController.java
├─ dto/
│  └─ ArticleForm.java        // DTO: 요청 데이터 운반
├─ entity/
│  └─ Article.java            // Entity: JPA 관리 객체
└─ repository/
   └─ ArticleRepository.java  // CRUD 인터페이스

DB 데이터 조회하기

• H2 DB 접속하기

**Step 1:**

>application.properties
spring.application.name=firstproject
spring.h2.console.enabled=true

**Step 2: `run` tab에서 jdbc 검색**
Database available at 'jdbc:h2:mem:......'

**Step 3: `localhost:8080/h2-console` 접속**
JDBC URL:.... 

• 데이터 조회하기

4장 - 롬복과 리팩터링

롬복(lombok): 코드 간단하게 만들어 주는 라이브러리

• 코드 반복 최소화
• 로깅 기능 지원

롬복을 활용해 리팩터링하기

• 롬복 설치하기

dependencies {
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
//생략
}

• DTO & Entity 리팩터링하기

  • @AllArgsConstructor : 모든 필드를 받는 생성자를 자동 생성
  • @ToString : 객체를 보기 좋게 문자열로 출력

• 컨트롤러에 로그 남기기

  • import lombok.extern.slf4j.Slf4j; + 클래스에 @Slf4j

    → System.out.println 대신 레벨별 로그 관리 가능(info/debug/warn/error), 운영환경에서 필터링 쉬움

5장 - 게시글 읽기: Read

데이터 조회 과정

단일 데이터 조회하기

[Client/Browser]
      │ (1) GET /articles/{id}
      ▼
[Controller]
      │ (2) 요청 파라미터(id) 해석 → 조회 지시
      ▼
[Repository]
      │ (3) DB에 조회 질의
      ▼
[DB]
      │ (4) 결과를 Entity로 반환
      ▼
[Model + View(템플릿)]
      │ (5) Model에 담아 템플릿 렌더링
      ▼
[Client/Browser]
      (6) 최종 HTML 응답 표시

데이터 목록 조회하기

GET /articles 요청이 오면 DB에서 모든 Article을 조회 → 모델에 articleList로 담음 → articles/index 템플릿으로 목록 렌더링

@GetMapping("/articles")
    public String index(Model model) {
        // 1. 모든 데이터 가져오기
        ArrayList<Article> articleEntityList = articleRepository.findAll();
        // 2. 모델에 데이터 등록하기
        model.addAttribute("articleList", articleEntityList);
        // 3. 뷰 페이지 설정하기
        return "articles/index";

    }

1. JDK: Java 17
2. JDE: IntelliJ IDEA Community Edition
3. 스프링 부트: 3.1.0 버전

실습환경 구축 글 👉 https://velog.io/@ttt-1-2/실습-환경-설치

1장 - 스프링 부트 시작하기

스프링 부트(Spring Boot)는 스프링을 개선하여 자바 애플리케이션 개발을 단순화한 프레임워크다

💡 1.1 실습: 헬로 월드! 출력

• Step 1: Run ‘FirstprojectAp…main()’
• Step 2: 크롬 브라우저에 localhost:8080 접속한다
• Step 3: 출력

src > main > resources > static 디렉터리에서 hello.html 파일 생성

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
    <h1>헬로 월드!</h1>
</body>
</html>

• Step 4: Rerun firstproject

  localhost:8080/hello.html로 접속하면 ‘헬로 월드!’가 화면에 표시된 것을 확인할 수 있다.

1.2 웹 서비스의 동작 원리 이해하기

클라이언트 ↔ 서버:

• 클라이언트(Client): 서버에 요청을 보내는 쪽
• 서버(Server): 클라이언트의 요청을 받아 처리하고 응답하는 쪽

만약 서버가 중지되면 웹사이트에 접속할 수 없고 다시 실행(Rerun)하면 정상적으로 접근할 수 있다. 실행 로그의 메시지를 살펴보면:

Tomcat started on port(s): 8080 (http) with context path ''
//--> 톰캣 서버가 8080번 포트에서 구동 중임을 의미한다

localhost:8080/hello.html 의 의미

• localhost: 현재 사용 중인 내 컴퓨터
• 8080: 톰캣이 실행되고 있는 포트 번호
• hello.html: 클라이언트가 요청하면 서버는 /static, /public, /resources, /META-INF/resources 경로에서 해당 파일을 순서대로 탐색한다. 파일이 존재하면 반환하고 없으면 404 에러를 응답한다.

2장 - MVC 패턴 이해와 실습

2.1 뷰 템플릿과 MVC 패턴

• 뷰 템플릿: 웹 애플리케이션에서 데이터를 화면에 출력할 때 사용하는 틀이다.
• MVC 패턴:
  • Model (모델): 데이터와 비즈니스 로직을 담당한다
  • View (뷰): 사용자에게 보여지는 화면을 담당한다. 즉 데이터를 받아서 웹 페이지나 화면에 출력한다
  • Controller (컨트롤러): 클라이언트의 요청을 받아 어떤 Model을 사용할지 결정하고 그 결과를 View에 전달한다

 //MVC 패턴

 [ Client ]
     |
     v
[ Controller ] -----> [ Model ] -----> [ Database / Data ]
     |                       |
     v                       |
   [ View ] <-----------------
     |
     v
 [ Client Screen ]

💡2.2 실습: MVC 패턴 활용해 뷰 템플릿 페이지 만들기

[ View: greetings.mustache ]
    ↓
    ( {{username}} )

[ Controller: FirstController.java ]
    ↓
    @GetMapping("/hi")
    public String niceToMeetYou(Model model) {
        model.addAttribute("username", "홍팍");
        return "greetings";
    }

[ Model: 데이터 ]
    ↓
    model.addAttribute("username", "홍팍");

[ Client 화면 출력 ]
    ↓
    <h1>Trang님, 반갑습니다!</h1>

2.3 MVC의 역할과 실행 흐름 이해하기

/hi 페이지의 실행 흐름

@Controller // 1. 컨트롤러 선언
public class FirstController {
    @GetMapping("/hi") // 2. URL 요청

    public String niceToMeetYou(Model model) { // 3. 메소드 수행 + 4. 모델 객체 가져오기
        model.addAttribute("username", "hongpark"); // 5. 모델 변수 등록
        return "greetings"; // 6. 뷰 템플렛 페이지 반환
    }
}    

2.4 뷰 템플릿 페이지에 레이아웃 적용하기

• 레이아웃: 화면에 요소를 배치하는 일

💡 실습 /hi 페이지에 헤더-푸터 레이아웃 적용하기

• Bootstrap은 HTML, CSS, JavaScript가 미리 준비되어 있는 프레임워크다. Bootstrap 공식 사이트에 접속해서 필요한 코드와 컴포넌트를 가져올 것이다. 이번 실습에서는 템플릿을 헤더와 푸터로 나누어 재사용할 수 있도록 구성해 코드의 가독성과 유지보수성을 높인다

• 폴더 구조:

main
├── java
│   └── com.example.firstproject
│       ├── FirstprojectApplication.java
│       └── controller
│           └── FirstController.java
│
└── resources
    ├── static
    ├── templates
    │   ├── greetings.mustache
    │   ├── goodbye.mustache
    │   └── layouts
    │       ├── header.mustache
    │       └── footer.mustache
    │
    └── application.properties

• 공통 헤더-푸터를 포함하고 본문에 {{username}}을 출력하는 템플릿:

{{>layouts/header}}

    <!-- content -->
    <div class="bg-dark text-white p-5">
        <h1>{{username}}님, 반갑습니다!</h1>
    </div>

{{>layouts/footer}}

마무리

실습 코드: https://github.com/ttt-1-2/BE-SpringBoot.git

소스 코드 레포지토리

• https://github.com/gilbutITbook/080354

실습 환경 (Mac OS)

1. JDK: Java 17

• 터미널에서 자바 버전 확인하기: java --version. 만약 출력 결과가 JDK 17로 설정되어 있다면 정상적으로 설치된 것이다
• 만약 java --version 실행 시 JDK 17이 설정되어 있지 않다면 Homebrew를 이용해 설치할 수 있다

  $ brew update
  $ brew install openjdk@17

2. JDE: 인텔리제이 CE(Community Edition)

• 다운로드 페이지: https://www.jetbrains.com/idea/download/?section=mac

3. 스프링 부트: 3.1.0

• Spring Initializr 페이지: https://start.spring.io/

• 첫번째 프로젝트 설정:

  • Project: Gradle - Groovy
  • Language: Java
  • Spring Boot: 3.5.5 (or 기본값)
  • Packaging: Jar
  • Java: 17
  • Dependencies → Add dependencies:
    • Spring Web
    • H2 Database
    • Mustache
    • Spring Data JPA

이제 설치한 인텔리제이 CE에서 firstproject를 열고 실행하면 된다.

• Note: 책에서 스프링 부트 3.1.0 버전을 사용한다. 책을 따라 실습하고 싶으시면 build.gradle 파일을 열고 코드 수정하면 된다.

  plugins {
    id 'java'
    id 'org.springframework.boot' version '3.1.0' //여기에서 버전 바꾸면 된다
    id 'io.spring.dependency-management' version '1.1.7'
  }