기록하는 습관

[AI] 대화형 AI와 백엔드 통신 방법 (WebSocket vs. SSE)

로그뉴 — Fri, 7 Feb 2025 18:00:47 +0900

1. WebSocket vs SSE 비교

특징WebSocketSSE (Server-Sent Events)

통신 방식	양방향 (full-duplex)	단방향 (server -> client)
연결 유지	지속적인 연결 유지 (클라이언트와 서버가 모두 메시지 전송 가능)	지속적인 연결 유지 (서버에서 클라이언트로만 데이터 전송 가능)
브라우저 지원	대부분의 최신 브라우저 지원	대부분의 최신 브라우저 지원 (IE 지원 X)
재연결	직접 구현 필요	자동 재연결 지원 (EventSource API)
사용 사례	채팅, 온라인 게임, 금융 거래	실시간 알림, 데이터 스트리밍, 로그 업데이트

2. 대화형 AI와의 통신에서 적합한 방식

WebSocket이 더 적합한 경우
- AI가 클라이언트의 입력을 실시간으로 받아야 하고, 결과를 즉시 반환해야 하는 경우 (예: 실시간 채팅 AI, 협업 문서 편집)
- AI가 사용자의 중간 입력을 실시간 반영하여 동적으로 응답을 생성하는 경우 (예: AI 코딩 도우미)
- 일반적인 챗봇처럼 AI가 클라이언트의 요청을 받아 응답하는 패턴이 많을 경우
SSE가 더 적합한 경우
- AI가 한 번의 요청에 대해 지속적으로 데이터를 스트리밍하는 경우 (예: ChatGPT처럼 길게 이어지는 답변)
- 일방적인 데이터 전송이 주된 경우 (예: 뉴스 업데이트, 실시간 알림)
- 재연결이 중요한 경우 (SSE는 기본적으로 자동 재연결 기능을 제공)

3. 대화형 AI 에서의 적용

AI가 유저와의 대화를 기반으로 추천을 해주거나, 지속적인 이벤트 업데이트가 필요하다면

WebSocket: 유저가 여러 가지 조건을 변경하면서 AI의 추천이 계속 바뀌는 경우 적합.
SSE: AI가 특정 조건에 맞는 추천을 한 번 생성한 후 지속적으로 스트리밍할 때 적합.

결론

실시간 대화 및 쌍방향 커뮤니케이션이 필요한 경우 → WebSocket
AI 응답이 일방향 스트리밍(단방향 푸시) 형태라면 → SSE

AI가 실시간 대화형 추천 기능을 담당한다면 WebSocket을, 추천 정보를 스트리밍하듯 보여준다면 SSE를 사용하는 게 좋다.

내가 WebSocket 으로 선택한 이유

사용자가 AI 답변 중에 조건을 수정할 수 있음 → 양방향 통신 필요
- SSE는 서버에서 클라이언트로만 데이터를 보낼 수 있어서, 사용자가 조건을 바꿀 때마다 새로운 HTTP 요청을 보내야 함.
- WebSocket을 쓰면 AI가 답변을 보내는 중에도 사용자가 즉시 조건을 수정하고 다시 요청할 수 있음.
- 즉, 연속적인 요청-응답 구조가 필요하므로 WebSocket이 적합!
AI가 실시간으로 업데이트하면서 보내야 할 수도 있음
- AI가 "추천을 한 번에 다 생성하는게 아니라, 단계별로 점진적으로 응답을 보내는 방식"이라면?
- WebSocket을 쓰면 한 번의 연결에서 스트리밍 방식으로 응답을 보낼 수 있음.
- 반면 SSE는 서버 → 클라이언트 방향이므로, 사용자가 중간에 요청을 수정하려면 새로운 SSE 연결을 만들어야 함.
사용자 경험 (UX) 개선
- WebSocket을 쓰면,
  - 사용자가 조건을 변경하면 기존 응답을 즉시 취소하고 새로운 플랜을 받을 수 있음.
  - AI가 실시간으로 상태 업데이트할 수 있어서,
    "지금 추천 생성 중... " 같은 UI를 쉽게 만들 수 있음.

결론

사용자가 AI 응답 중에도 조건을 수정할 수 있는 경우 → WebSocket이 더 적합!
한 번 요청하면 AI가 일방적으로 최종 결과를 전달하는 경우 → SSE 가능

추천 아키텍처 예시 (WebSocket 사용)

사용자가 WebSocket 연결 생성 (ws://server/ai-recommend)
사용자가 추천 요청 ({"action": "request_plan", "criteria": {...}})
AI가 실시간으로 응답을 보냄 ({"status": "processing", "step": 1, "data": {...}})
사용자가 조건을 변경하면 즉시 새로운 요청을 전송
서버는 기존 추천을 취소하고 새로운 추천을 보내줌

이렇게 하면 빠르게 응답을 주고받으면서 실시간 인터랙션이 가능한 AI 추천 시스템을 만들 수 있다.

[AI] WebSocket vs. WebSocket Stream

로그뉴 — Fri, 7 Feb 2025 18:00:14 +0900

WebSocket Stream 방식이란?

WebSocket Stream 방식은 서버가 데이터를 한 번에 전송하는 게 아니라, 여러 번에 걸쳐 스트리밍(조각)으로 보내는 방식이다.

즉, WebSocket 연결을 유지하면서 데이터를 점진적으로 처리하고, 필요한 만큼 실시간으로 전송하는 패턴을 의미한다.

✅ 일반적인 WebSocket vs. WebSocket Stream

방식설명

일반 WebSocket	한 번의 요청으로 한 번의 응답을 받음 (ex. 채팅 메시지)
WebSocket Stream	서버가 데이터를 조각으로 나눠서 지속적으로 전송 (ex. AI 응답, 실시간 데이터 처리)

WebSocket Stream이 필요한 경우?

AI가 긴 답변을 한 번에 보내기 어렵고, 조금씩 전송해야 할 때
실시간 데이터 업데이트 (예: 주식 가격, 게임 상태, AI 답변)
스트리밍 기반 AI 응답 (ex. ChatGPT API처럼 조금씩 출력)

✅ WebSocket Stream이 좋은 이유

실시간 업데이트 가능
- AI가 응답을 다 만들 때까지 기다리지 않고, 중간 진행 상황도 받을 수 있음
빠른 응답 속도
- 긴 데이터(예: AI 생성 결과)를 한꺼번에 보내는 것보다, 조금씩 보내는 게 UX가 좋음
사용자가 즉시 반응 가능
- AI가 답변을 생성하는 동안에도, FE에서 취소하거나 조건을 수정할 수 있음

최종 정리

✔ WebSocket Stream = 데이터를 한꺼번에 보내지 않고, 필요한 만큼 실시간으로 조각(스트림)으로 전송하는 방식
✔ AI 추천 플랜 같은 경우, 생성되는 대로 WebSocket으로 보내면 FE에서 실시간 업데이트 가능
✔ ChatGPT처럼 AI 응답이 천천히 나오는 경우에도 적합

즉, WebSocket Stream을 쓰면 AI 응답을 기다리지 않고, 빠르게 처리할 수 있음.

** 통신 구조

[FE] --- WebSocket Stream ---> [BE] --- WebSocket Stream ---> [AI 서버]

[JPA] 예외 처리와 엔티티 비교

로그뉴 — Thu, 25 Jan 2024 13:21:55 +0900

1. 예외 처리

jpa 표준 예외는 javax.persistence.PersistenceException의 자식 클래스이다.

jpa 예외는 모두 unchecked 예외이다.

** unchecked 예외란?

언체크 예외는 RuntimeException의 하위 클래스들을 의미. 체크 예외와는 달리 에러 처리를 강제하지 않는다.
말 그대로 실행 중에(runtime) 발생할 수 있는 예외를 의미한다.

배열의 범위를 벗어난(ArrayIndexOutOfBoundsException)
값이 null이 참조변수를 참조(NullPointerException)

JPA 표준 예외 2가지

1. 트랜잭션 롤백을 표시하는 예외

트랜잭션 강제로 커밋해도 커밋되지 않고, javax.persistence.RollbackException 예외 발생

트랜잭션 롤백을 표시하는 예외	설명
javax.persistence.EntityExistsException	EntityManaget.persist(..) 호출 시 이미 같은 엔티티가 있으면 발생
javax.persistence.EntityNotFoundException	EntityManager.getReference(..)를 호출했는데 실제 사용 시 엔티티가 존재하지 않으면 발생. refresh(..), lock(..)에서도 발생
javax.persistence.OptimisticLockException	낙관적 락 충돌 시 발생
javax.persistence.PessimisticLockException	비관적 락 충돌 시 발생
javax.persistence.RollbackException	EntityTransaction.commit() 실패 시 발생. 롤백이 표시되어 있는 트랜잭션 커밋 시에도 발생
javax.persistence.TransactionRequiredException	트랜잭션이 필요할 때 트랜잭션 없으면 발생. 트랜잭션 없이 엔티티 변경할 때 주로 발생

2. 트랜잭션 롤백을 표시하지 않는 예외

심각한 예외가 아니므로 개발자가 트랜잭션 커밋 롤백할지 판단

트랜잭션 롤백을 표시하는 예외	설명
javax.persistence.NoResultException	Query.getSingleResult() 호출 시 결과가 하나도 없을 때 발생
javax.persistence.NonUniqueResultException	Query.getSingleResult() 호출 시 겨로가가 둘 이상일 때 발생
javax.persistence.LockTimeoutException	비관적 락에서 시간 초과 시 발생
javax.persistence.QueryTimeoutException	쿼리 실행 시간 초과 시 발생

2. 스프링 프레임워크의 JPA 예외 반환

스프링 프레임워크는 데이터 접근 계층에 대한 예외를 추상화해서 제공

JPA 예외	스프링 변환 예외
javax.persistence.PersistenceException	org.springframework.orm.jpa.JpaSystemException
javax.persistence.NoResultException	org.springframework.dao.Ex=mptyResultDataAccessException
javax.persistence.NonUniqueResultException	org.springframework.dao.IncorrectResultSizeDataAccessException
javax.persistence.LockTimeoutException	org.springframework.CannotAcquireLockException

3. 스프링 프레임워크에 JPA 예외 변환기 적용

JPA 예외를 스프링 프레임워크가 제공하는 추상화된 예외로 변경하려면 PersistenceExceptionTranslationPostProcessor를 스프링 빈으로 등록한다.

@Bean
public PersistenceExceptionTranslationPostProcessor exceptionTranslation() {
    return new PersistenceExceptionTranslationPostProcessor();
}

트랜잭션 롤백 시 주의사항

데이터베이스의 반영사항만 롤백하였을 경우 영속성 컨택스트 내부 객체는 그대로 남아다. 따라서 트랜잭션이 롤백된 영속성 컨텍스트를 그대로 사용할 때 조심해야 한다.

트랜잭션당 영속성 컨택스트 전략
- 문제생겼을 때 트랜잭션 AOP 종료시점 트랜잭션 롤백하면서 영속성 컨택스트 함께 종료하므로 문제가 없다.
OSIV 사용 전략(문제됨)
- 영속성 컨택스트 범위 > 트랜잭션 범위일 경우 문제가 발생한다.
- 롤백하고 남아있는 영속성 컨택스트에 이상이 발생해도 다른 컨택스트에서 그대로 사용할 수 있다.
- 해결방법 → em.clear() 영속성 컨텍스트 초기화해 예방한다.

4. 엔티티 비교

1) 영속성 컨텍스트가 같을 때 엔티티 비교

비교 방법 3가지
- 동일성(identical): == 비교가 같다.
- 동등성(equivalent): equals() 비교가 같다.
- 데이터베이스 동등성: @Id인 데이터베이스 식별자가 같다. member.getld().equals(findMember.getld())

2) 영속성 컨텍스트가 다를 때 엔티티 비교

서비스에만 @Transactional이 있는 경우의 트랜잭션 범위와 영속성 컨텍스트의 범위
영속성 컨텍스트가 다르면 동일성 비교에 실패
- 동일성: == 비교가 실패
- 동등성: equals() 비교가 만족. 단 equals() 구현해야 함
  - 비즈니스 키를 활용한 동등성 비교 권장(예: 주민등록번호)
- 데이터베이스 동등성: @Id인 데이터베이스 식별자 같음
```
member.getId().equals(findMember.getId())
```

[JPA] 스프링 데이터 JPA (2)

로그뉴 — Thu, 14 Dec 2023 17:00:58 +0900

스프링 데이터 JPA와 QueryDSL 통합

1. QueryDslPredicateExecutor 사용

첫 번째 방법은 다음처럼 리포지토리에서 QueryDslPredicateExecutor를 상속받으면 된다.

이제 상품 리포지토리에서 QueryDSL을 사용할 수 있다. 아래 예제는 QueryDSL이 생성한 쿼리 타입으로 장난감이라는 이름을 포함하고 있으면서 가격이 10000~20000원인 상품을 검색한다.

public interface ItemRepository extends JpaRepository<Item, Long>, QueryDslPredicateExecutor<Item> {}

QItem item = QItem.item;
Iterable<Item> result = itemRepository.findAll(
	item.name.contains("장난감").and(item.price.between(10000, 20000))
);

예제의 QueryDslPredicateExecutor 인터페이스를 보면 QueryDSL을 검색조건으로 사용하면서 스프링 데이터 JPA가 제공하는 페이징과 정렬 기능도 함께 사용할 수 있다.

public interface QueryDslPredicateExecutor<T> {
	T findOne(Predicate predicate);
    Iterable<T> findAll(Predicate predicate);
    Iterable<T> findAll(Predicate predicate, OrderSpecifier<?>... orders);
    Page<T> findAll(Predicate predicate, Pageable pageable);
    long count(Predicate predicate);
}

지금까지 살펴본 QueryDslPredicateExecutor는 스프링 데이터 JPA에서 편리하게 QueryDSL을 사용할 수 있지만 기능에 한계가 있다. 예를 들어 join, fetch를 사용할 수 없다. 따라서 QueryDSL이 제공하는 다양한 기능을 사용하려면 JPAQuery를 직접 사용하거나 스프링 데이터 JPA가 제공하는 QueryDslRepositorySupport를 사용해야 한다.

2. QueryDslRepositorySupport 사용

QueryDSL의 모든 기능을 사용하려면 JPAQuery 객체를 직접 생성해서 사용하면 된다. 이때 스프링 데이터 JPA가 제공하는 QueryDslRepositorySupport를 상속받아 사용하면 조금 더 편리하게 QueryDSL을 사용할 수 있다.

public interface CustomOrderRepository {
	public List<Order> search(OrderSearch orderSearch);
}

public class OrderRepositoryImpl extends QueryDslRepositorySupport implements CustomOrderRepository {
	public OrderRepositoryImpl() {
    	super(Order.class);
    }
    
    @Override
    public List<Order> search(OrderSearch orderSearch) {
    	QOrder order = QOrder.order;
        QMember member = QMember.member;
        
        JPQLQuery query = from(order);
        
        if(StringUtils.hasText(orderSearch.getMemberName())) {	
        	query.leftJoin(order.member, member).where(member.name.contains(orderSearch.getMemberName()));
        }
        
        if(orderSearch.getOrderStatus() != null) {
        	query.where(order.status.eq(orderSerach.getOrderStatus()));
        }
        
        return query.list(order);
    }
}

3. QuerydslReositorySupport 인터페이스

1. Querydsl 3.x 버전을 대상
2. Querydsl 4.x에 나온 JPAQueryFactory로 시작할 수 없음
3. select로 시작할 수 없음 (from으로 시작해야함)
4. QueryFactory 를 제공하지 않음
5. 스프링 데이터 Sort 기능이 정상 동작하지 않음. 큐 소트를 사용하면 되긴하지만 정렬을 직접해줘야 함

[JPA] 스프링 데이터 JPA

로그뉴 — Thu, 7 Dec 2023 14:38:50 +0900

쿼리 메소드 기능

1. 메소드 이름으로 쿼리 생성

public interface MemberRepository extends Repository<Member, Long> {
    List<Member> findByEmailAndName(String email, String name);
}

// 실행되는 JPQL
select m from Member m where m.email = ?1 and m.name = ?2

** 엔티티의 필드명이 변경되면 인터페이스에 정의한 메소드 이름도 꼭 함께 변경해야 한다. 그렇지 않으면 애플리케이션 시작하는 시점에 오류가 발생한다.

2. JPA NamedQuery

// 어노테이션 방식
@Entity
@NamedQuery(
    name="Member.findByUsername",
    query="select m from Member m where m.username = :username")
public class Member {
    ...
}

스프링 데이터 jpa를 사용하면 메소드 이름만으로 Named 쿼리를 호출할 수 있다.

public interface MemberRepository 
    extends JpaRepository<Member, Long> { // 여기 선언한 Member 도메인 클래스

    List<Member> findByUsername(@Param("username") String username);
}

스프링 데이터 JPA는 선언한 "도메인 클래스 + .(점) + 메소드 이름"으로 Named 쿼리를 찾아서 실행한다. 위의 예제의 경우, Member.findByUsername이라는 Named 쿼리를 실행한다.

3. @Query, 리포지토리 메소드에 쿼리 정의

리포지토리 메소드에 직접 쿼리를 정의하는 방법.

- 실행할 메소드에 정적 쿼리를 직접 작성하므로 이름 없는 Named 쿼리라 할 수 있다.

- JPA Named 애플리케이션 실행 시점에 문법 오류를 발견할 수 있는 것이 장점이다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query("select m from Member m where m.username = ?1")
    Member findByUsername (String username);
}

Native SQL을 사용하려면 @Query 어노테이션에 nativeQuery = true를 설정한다.

public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query(value = "SELECT * FROM MEMBER WHERE USERNAME = ?0”,
        nativeQuery = true)
    Member findByUsername (String username);
}

4. 파라미터 바인딩

스프링 데이터 JPA는 위치 기반 파라미터 바인딩과 이름 기반 파라미터 바인딩을 모두 지원한다.

select m from Member m where m.username = ?1 //위치 기반
select m from Member m where m.username = :name //이름기반

5. 벌크성 수정 쿼리

- 스프링 데이터 JPA에서 벌크성 수정, 삭제 쿼리는 Modifying 어노테이션을 사용하면 된다.

- 벌크성 쿼리를 실행하고 나서 영속성 컨텍스트를 초기화하고 싶으면 @Modifying(clearAutomatically = true)를 사용하면 된다. (기본값은 false)

@Modifying
@Query("update Product p set p.price = p.price * 1.1 where
    p.stockAmount < :stockAmount")
int bulkPriceUp(@Param("stockAmount") String stockAmount);

6. 반환 타입

- 한 건 이상이면 컬렉션 인터페이스 사용, 단건이면 반환 타입을 지정한다.

- 조회 결과가 없으면 컬렉션은 빈 컬렉션을 반환하고, 단건은 null을 반환한다.

- 단건을 기대하고 반환 타입을 지정했는데 결과가 2건 이상 조회되면 NonUniqueResultException 예외가 발생한다.

List<Member> findByName (String name); // 컬렉션
Member findByEmail (String email); // 단건

7. 페이징과 정렬

- Page를 사용하면 스프링 데이터 JPA는 페이징 기능을 제공하기 위해 검색된 데이터 건수를 조회하는 count 쿼리를 추가로 호출한다.

//count 쿼리 사용
Page<Member> findByName(String name, Pageable pageable);

//count 쿼리 사용 안 함
List<Member> findByName(String name, Pageable pageable);

//페이징 조건과 정렬 조건 설정
PageRequest pageRequest =
    new PageRequest(0, 10, new Sort(Direction.DESC, "name"));

Page<Member> result =
    memberRepository.findByNameStartingWith("김", pageRequest);

List<Member> members = result.getContent (); //조회된 데이터
int totalPages = result.getTotalPages (); //전체 페이지 수
boolean hasNextPage = result .hasNextPage (); //다음 페이지 존재 여부

참고) Page 인터페이스

public interface Page<T> extends Iterable<T> {

    int getNumber(); //현재 페이지
    int getSize(); //페이지 크기
    int getTotalPages(); //전체 페이지 수
    int getNumberOfElements(); //현재 페이지에 나올 데이터 수
    long getTotalElements(); //전체 데이터 수
    boolean hasPreviousPage(); //이전 페이지 여부
    boolean isFirstPage(); //현재 페이지가 첫 페이지 인지 여부
    boolean hasNextPage(); //다음 페이지 여부
    boolean isLastPage(); //현재 페이지가 마지막 페이지 인지 여부
    Pageable nextPageable(); //다음 페이지 객체, 다음 페이지가 없으면 null
    Pageable previousPageable(); //다음 페이지 객체, 이전 페이지가 없으면 null
    List<T> getContent(); //조회된 데이터
    boolean hasContent(); //조회된 데이터 존재 여부
    Sort getSort(); //정렬정보

}

명세

- Specification은 컴포지트 패턴으로 구성되어 있어서 여러 Specification을 조합할 수 있다.

사용자 정의 리포지터리 구현

- 스프링 데이터 JPA로 리포지터리를 개발하면 인터페이스만 정의하고 구현체는 만들지 않는다.

- 메소드를 직접 구현하고 싶다면? -> 리포지터리를 직접 구현하면 공통 인터페이스가 제공하는 기능까지 모두 구현해야 하므로, 스프링 데이터 JPA는 이런 문제를 우회해서 필요한 메소드만 구현할 수 있는 방법을 제공한다.

public interface MemberRepositoryCustom {
    public List<Member> findMemberCustom();
}

// 클래스 이름을 짓는 규칙: (repository interface 이름 + Impl)
public class MemberRepositorylmpl implements MemberRepositoryCustom {
    @Override
    public List<Member> findMemberCustom () {
        ... //사용자정의구현
    }
}

[JPA] 객체지향 쿼리와 JPQL

로그뉴 — Thu, 9 Nov 2023 15:00:37 +0900

1. 기본 문법과 쿼리 API

Java Persistence Query Language(JPQL)은 엔터티 객체를 대상으로 하는 쿼리 언어로, SQL과 유사하지만 테이블이 아닌 엔터티에 대해 작동한다.

1.1 기본 문법

JPQL의 기본 문법은 다음과 같다:

SELECT <별칭 또는 엔터티명>
FROM <엔터티명>
WHERE <조건>

예)

SELECT e FROM Employee e WHERE e.department = 'IT'

이 쿼리는 'IT' 부서에 속한 모든 직원을 검색한다.

1.2 쿼리 API

JPQL은 EntityManager를 통해 실행된다. EntityManager는 엔터티를 관리하고 영속성 컨텍스트를 제공하는데, 이를 이용해 JPQL을 실행할 수 있다.

EntityManager em = // EntityManager를 얻는 코드

TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.department = 'IT'", Employee.class);

List<Employee> resultList = query.getResultList();

이렇게 얻은 resultList에는 쿼리 결과가 들어있다.

2. 파라미터 바인딩

파라미터 바인딩은 JPQL 쿼리에 동적인 값들을 전달하는 방법을 의미한다. 정적인 쿼리만으로는 한계가 있음.

2.1 위치 기반 파라미터 바인딩

가장 간단한 방법은 위치 기반 파라미터 바인딩이다. 쿼리 문자열 안에 ?1, ?2, 등의 플레이스홀더를 사용하고, 파라미터 인덱스에 해당하는 값을 지정한다.

TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.department = ?1", Employee.class);
query.setParameter(1, "IT");

List<Employee> resultList = query.getResultList();

2.2 이름 기반 파라미터 바인딩

이름 기반 파라미터 바인딩은 :파라미터명 형식을 사용한다. 가독성이 더 높고, 순서에 구애받지 않아 편리하다.

TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.department = :dept", Employee.class);
query.setParameter("dept", "IT");

List<Employee> resultList = query.getResultList();

2.3 위치 기반 vs. 이름 기반

선택은 개인의 취향이지만, 보통 이름 기반 파라미터 바인딩이 더 가독성이 좋다고 생각함.

3. 프로젝션

프로젝션은 JPQL에서 쿼리 결과로 가져올 데이터를 선택하는 방법이다. 불필요한 데이터를 가져오지 않고 필요한 부분만 선택하여 성능을 최적화할 수 있다.

3.1 엔터티 프로젝션

가장 간단한 프로젝션은 엔터티 자체를 선택하는 것이다.

TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.department = 'IT'", Employee.class);

List<Employee> resultList = query.getResultList();

이 경우에는 Employee 엔터티 전체를 가져오게 된다.

3.2 단일 값 프로젝션

만약 엔터티의 특정 필드만 필요하다면, 단일 값 프로젝션을 사용할 수 있다.

TypedQuery<String> query = em.createQuery("SELECT e.name FROM Employee e WHERE e.department = 'IT'", String.class);

List<String> resultList = query.getResultList();

위의 예시에서는 직원의 이름만을 가져오고 있다.

3.3 여러 값 프로젝션

여러 값을 한 번에 가져올 수도 있다. 그러나 이 경우는 Object[]나 Tuple을 사용해야 한다.

TypedQuery<Object[]> query = em.createQuery("SELECT e.name, e.salary FROM Employee e WHERE e.department = 'IT'", Object[].class);

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

3.4 DTO 프로젝션

가장 권장되는 방법 중 하나는 DTO(Data Transfer Object)를 사용하는 것이다. 엔터티의 일부 필드만 필요한 경우 DTO를 활용하여 필요한 정보만 전달받을 수 있다.

TypedQuery<EmployeeDTO> query = em.createQuery("SELECT new com.example.EmployeeDTO(e.name, e.salary) FROM Employee e WHERE e.department = 'IT'", EmployeeDTO.class);

List<EmployeeDTO> resultList = query.getResultList();

4. 페이징 API

페이징은 대량의 데이터를 작은 일부분씩 나눠서 가져오는 기술로, 성능을 향상시키고 메모리 소비를 줄일 수 있다.

4.1 setFirstResult와 setMaxResults

setFirstResult는 가져올 결과의 시작 위치를 지정하고, setMaxResults는 가져올 최대 결과 수를 지정한다. 이 두 메서드를 사용하여 페이징을 구현할 수 있다.

int pageNumber = 1;
int pageSize = 10;

TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.department = 'IT'", Employee.class);

query.setFirstResult((pageNumber - 1) * pageSize);
query.setMaxResults(pageSize);

List<Employee> resultList = query.getResultList();

위의 예시에서는 1페이지에서 10개의 결과를 가져오고 있다.

4.2 페이징을 위한 쿼리 작성

쿼리 자체에서 페이징을 구현할 수도 있다. OFFSET과 LIMIT을 사용하는 방법이 있다.

int pageNumber = 1;
int pageSize = 10;

TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.department = 'IT' ORDER BY e.name")
    .setFirstResult((pageNumber - 1) * pageSize)
    .setMaxResults(pageSize);

List<Employee> resultList = query.getResultList();

이렇게 하면 데이터베이스에서 직접 페이징이 이루어진다.

5. 집합과 정렬

데이터를 검색하면서 종종 집합(집계) 함수를 사용하여 결과를 합치거나 통계를 내는 경우가 있다. 또한 정렬은 결과를 특정 기준에 따라 정렬하는 것으로, 보기 좋은 결과를 얻기 위해 중요하다.

5.1 집합 함수

JPQL에서는 다양한 집합 함수를 사용할 수 있다. 가장 일반적인 것은 COUNT, SUM, AVG, MIN, MAX 등이다.

TypedQuery<Long> countQuery = em.createQuery("SELECT COUNT(e) FROM Employee e", Long.class);
Long totalCount = countQuery.getSingleResult();

TypedQuery<Double> avgSalaryQuery = em.createQuery("SELECT AVG(e.salary) FROM Employee e", Double.class);
Double averageSalary = avgSalaryQuery.getSingleResult();

위의 예시에서는 COUNT와 AVG 함수를 사용하여 직원의 총 수와 평균 급여를 구하고 있다.

5.2 정렬

결과를 특정 기준에 따라 정렬하려면 ORDER BY 절을 사용한다.

TypedQuery<Employee> query = em.createQuery("SELECT e FROM Employee e WHERE e.department = 'IT' ORDER BY e.salary DESC", Employee.class);

List<Employee> resultList = query.getResultList();

위의 예시에서는 IT 부서에 속한 직원들을 급여 기준으로 내림차순 정렬하고 있다.

6. 서브쿼리

NOT EXISTS : 서브쿼리에 결과가 존재하면 참
NOT IN : 서브쿼리의 결과 중 하나라도 같은 것이 있으면 참
ALL : 모두 만족하면 참
ANY, SOME : 같은 의미, 조건을 하나라도 만족하면 참
JPA는 SELECT, WHERE, HAVING절에서만 서브 쿼리 사용 가능
FROM절의 서브 쿼리는 현재 JPQL에서 불가능 (조인으로 풀 수 있으면 풀어서 해결)

7. JPQL 타입

문자: 'HELLO', 'She''s'
숫자: 10L(Long), 10D(Double), 10F(Float)
Boolean: TRUE, FALSE
ENUM: jpabook.MemberType.Admin (패키지명 포함)
엔티티 타입: TYPE(m) = Member (상속 관계에서 사용)

8. JPQL 기본 함수

CONCAT
SUBSTRING
TRIM
LOWER, UPPER
LENGTH
LOCATE
ABS, SQRT, MOD
SIZE, INDEX

[JPA] 9장 값 타입

로그뉴 — Wed, 25 Oct 2023 15:26:16 +0900

JPA 의 데이터 타입을 가장 크게 분류하면 엔티티 타입과 값 타입으로 나눌 수 있다.

엔티티 타입 : @Entity로 정의하는 객체
- 식별자를 통해 지속적으로 추적할 수 있다.
- 엔티티의 속성 값을 변경하더라도 같은 엔티티이다.

값 타입 : int, Integer, String 처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체를 말한다.
- 식별자가 없고 숫자나 문자같은 속성만 있으므로 추적할 수 없다.
- 숫자 값을 100에서 200으로 변경하면 완전히 다른 값으로 대체된다.

값 타입은 다음의 3가지로 나눌 수 있다.

기본값 타입(Basic value type)
- 자바 기본 타입(예: int, double)
- 래퍼 클래스(예: Integer)
- String

임베디드 타입(복합 값 타입)
- JPA 에서 사용자가 직접 정의한 값 타입

컬렉션 값 타입
- 하나 이상의 값 타입을 저장할 때 사용한다.

1. 기본값 타입

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

	private String name;
	private int age;
}

Member 엔티티의 값 타입인 name, age 속성은 식별자 값도 없고 생명 주기도 회원 엔티티에 의존한다.

따라서 회원 엔티티 인스턴스를 제거하면 name, age 값도 제거된다.

값 타입은 공유하면 안 된다.

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

@Embeddable : 값 타입을 정의하는 곳에 표시

@Embedded : 값 타입을 사용하는 곳에 표시

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

  @Embedded 
  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"))
  })
  Address companyAddress;
}

임베디드 타입이 null이면 매핑한 컬럼 값은 모두 null이 된다.

3. 값 타입과 불변 객체

member1.setHomeAddress(new Address("oldCIty"));
Address address = member1.getHomeAddress();

address.setCity("newCity");
member2.setHomeAddress(address);

영속성 컨텍스트는 회원1의 주소도 newCity로 변경시켜버린다.
이러한 부작용을 막으려면 값을 복사해서 사용하면 안된다.

값 타입 복사

자바는 기본 타입에 값을 대입하면 값을 복사해서 전달하고 객체에 값을 대입하면 참조값을 전달한다. (Call by value, Call by reference)
문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본타입이 아니라 객체 타입이여서 대입해서 사용하게 되면 공유 참조로 인한 Side Effect가 발생할 수 있다.
객체의 공유참조는 피할 수 없는데, 따라서 근본적인 해결책이 필요하다.
가장 단순한 방법은 객체의 값을 수정하지 못하게 막으면 공유 참조해도 값을 변경하지 못하므로 부작용을 막을 수 있다.

불변 객체

객체를 불변하게 만들면 값을 수정할 수 없으므로 부작용이 원천 차단 가능하다.
따라서 되도록 값 타입은 불변 객체로 설계하자.
불변 객체도 결국 객체여서 참조 값 공유를 피할 수는 없지만 인스턴스의 값을 수정할 수 없으므로 부작용이 발생하지 않는다.
불변 객체를 구현하는 방법은 다양하지만 가장 간단한 방법은 생성자로만 값을 설정하고 수정자를 만들지 않으면 된다. (setter를 제거)

4. 값 타입의 비교

자바가 제공하는 객체 비교 2가지
- 동일성 : ==
- 동등성 : equals()
값 타입을 비교할 때는 equlas()를 사용해서 동등성을 비교해야 한다.
값 타입의 equals() 메소드를 재정의할 때는 모든 필드값을 비교하도록 구현한다.
자바에서 equals()를 재정의하면 hashCode()도 재정의하는 것이 안전하다. 그렇지 않으면 해시를 사용하는 컬렉션(HashSet, HashMap)이 정상 동작하지 않는다.

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> favor丄teFoods = new HashSet<String>();

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

@Embeddable
public class Address {
  @Column
  private String city;
  private String street;
  private String zipcode
  //...
}

FavoriteFoods는 기본값 타입인 String을 컬렉션으로 가진다.

이것은 데이터베이스 테이블로 매핑해야 하는데 관계형 데이터베이스의 테이블은 컬럼 안에 컬렉션을 포함할 수 없다.

따라서 별도의 테이블을 추가하고 @CollectionTable를 사용해서 추가한 테이블을 매핑 해야 한다.

값 타입 컬렉션의 제약사항

값 타입 컬렉션에 변경 사항이 발생하면, 값 타입 컬렉션이 매핑된 테이블의 연관된 모든 데이터를 삭제하고, 현재 값 타입 컬렉션 객체에 있는 모든 값을 데이터베이스에 다시 저장한다.
값 타입 컬렉션의 매핑된 테이블에 데이터가 많다면 값 타입 대신 일대다 관계를 고려해야 한다.
값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 한다. 따라서 데이터베이스 기본 키 제약조건으로 인해 null을 입력할 수 없고, 같은 값을 중복해서 저장할 수 없는 제약도 있다.
이러한 문제를 해결하려면 값 타입 컬렉션 대신 새로운 엔티티를 만들어서 일대다 관계로 설정하고 cascade + orphan remove 기능을 적용하면 값 타입 컬렉션처럼 사용할 수 있다.

[JPA] 복합키에서 equals () 및 hashCode () 구현

로그뉴 — Thu, 5 Oct 2023 14:17:39 +0900

회사에서 JPA 스터디를 중간에 참여하게 되어 7장부터 글을 쓰게 되었다.

앞으로 책을 읽고 알게된 내용이나, 궁금했던 점 위주로 정리할 예정이다.

복합 키와 식별관계 매핑

식별관계 vs 비식별관계

DB 테이블 사이의 관계는 외래 키가 기본 키에 포함되는지 여부에 따라 식별, 비식별로 구분된다.

식별관계

식별 관계는 부모 테이블의 기본 키를 내려 받아 자식 테이블의 기본키 + 외래키로 사용하는 관계

비식별관계

비식별 관계는 부모 테이블의 기본 키를 받아서 자식 테이블의 외래 키로만 사용하는 관계다.
비식별 관계는 외래키에 NULL을 허용하는지에 따라 필수적, 선택적으로 갈린다.

필수적 비식별 관계
- 외래키에 NULL 허용하지 않음
- 연관관계를 필수적으로 맺어야함
선택적 비식별 관계
- 외래키에 NULL 허용함
- 연관관계를 맺을지 말지 선택 가능

** 비식별 관계를 주로 사용하는 것을 추천한다.

복합키를 구성하기 위한 필수조건

1. @EmbeddedId 또는 @IdClass

2. public의 no-args constructor

3. serializable을 상속 받기

4. equals(), hashCode() Override

복합키 : 비식별 관계 매핑

식별자 필드가 2개 이상이면 별도의 식별자 클래스를 만들고 equals와 hashcode를 override해야 한다.
JPA는 복합키를 지원하기 위해 @IdClass, @EmbeddedId 2가지 방법을 제공한다.

@IdClass는 관계형 DB에 가까운 방법이고 @EmbeddedId는 좀 더 객체지향에 가까운 방법이다.

ParentId id1 = new ParentId();
id1.setId1("test1");
id1.setId2("test2");

ParentId id2 = new ParentId();
id2.setId1("test1");
id2.setId2("test2");

id1.equals(id2) // false

id1.equals(id2) 의 결과값은 false이다.

자바의 모든 클래스는 기본으로 Object 클래스를 상속받는데 이 클래스가 제공하는 기본 equals()는 인스턴스 참조 값 비교인 ==비교(동일성비교)를 하기 때문이다.

식별자 클래스의 equals(), hashCode()는 영속성 컨텍스트가 식별자를 비교할때 사용하기 때문에 반드시 오버라이딩 해야한다.

식별자 객체의 동등성(equals)이 지켜지지 않으면 예상과 다른 엔티티가 조회되거나 엔티티를 찾을 수 없는 등 영속성 컨텍스트가 엔티티를 관리하는 데 문제가 발생한다.

복합 키를 사용할 때 equals()와 hashCode()를 필수로 구현해야 하는 이유?

복합키는 일반적으로 두 개 이상의 필드를 조합하여 하나의 키를 구성하는데, 여러 필드로 구성된 복합키의 경우에는 각 필드의 값이 같더라도 인스턴스가 다를 수 있다. 이때 equals()와 hashCode() 메서드를 적절히 오버라이딩하여 두 객체가 동일한 키를 나타내는지를 정의하면, 해시 기반의 자료구조에서 올바르게 동작하도록 할 수 있다.

equals() 메서드를 오버라이딩하는 이유:

equals() 메서드는 두 객체가 동등한지 여부를 판단한다. 복합키의 경우, 여러 필드를 비교하여 동등성을 판단해야 한다. 따라서 equals() 메서드를 오버라이딩하여 동등성 비교를 정의할 수 있다.

hashCode() 메서드를 오버라이딩하는 이유:

hashCode() 메서드는 해시 기반 자료구조에서 객체의 해시 코드를 반환한다. 해시 기반 자료구조에서 객체를 저장하고 검색할 때 해시 코드를 사용하여 성능을 향상시킬 수 있다. 복합키의 경우, 각 필드의 해시 코드를 조합하여 객체의 해시 코드를 생성할 수 있도록 hashCode() 메서드를 오버라이딩해야 한다.

equals()와 hashCode()를 오버라이딩 하는 예시

OrderKey 클래스가 있고, 사용자 ID와 주문 번호 두 필드로 구성되어 있다.

각 주문은 사용자 ID와 주문 번호로 식별된다. (= 복합키)

import java.util.Objects;

public class OrderKey {
    private Long userId;
    private String orderNumber;

    // 생성자, getter, setter 생략 (필요에 따라 구현)

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        OrderKey orderKey = (OrderKey) o;
        return Objects.equals(userId, orderKey.userId) &&
                Objects.equals(orderNumber, orderKey.orderNumber);
    }

    @Override
    public int hashCode() {
        return Objects.hash(userId, orderNumber);
    }
}

위 코드에서는 OrderKey 클래스를 정의하고, 이 클래스에서 equals()와 hashCode() 메서드를 오버라이딩하여 복합키의 동등성 비교와 해시 코드 생성을 정의했다.

[Kotlin In Action]10장 - 애노테이션과 리플렉션

로그뉴 — Tue, 30 May 2023 10:41:57 +0900

** 이 글은 Kotlin In Action을 읽고 정리한 글입니다. **

10.1 애노테이션 선언과 적용

10.1.1 애노테이션 적용

애노테이션 적용을 위해서는 적용하는 대상 앞에 애노테이션을 붙이면 된다.

애노테이션은 '@'과 애노테이션 이름으로 이루어진다.

예를 들어 JUnit 프레임워크를 사용한다면 테스트 메서드 앞에 '@Test' 애노테이션을 붙이면 된다.

class MyTest{
  @Test fun testTrue(){
    Assert.assertTrue(true)
  }
}

애노테이션의 인자로는 원시 타입의 값, 문자열, enum, 클래스 참조, 다른 애노테이션 클래스, 배열이 들어갈 수 있다.

애노테이션의 인자를 지정하는 문법은 자바와 약간 다르다.

클래스를 애노테이션 인자로 지정할 때는 @MyAnnotation (MyClass:class) 처럼 ::class 를 클래스 이름 뒤에 넣어야 한다.
다른 애노테이션을 인자로 지정할 때는 인자로 들어가는 애노테이션의 이름 앞에 @ 를 넣지 않아야 한다.
배열을 인자로 지정하려면 RequestMapping(path = arrayOf("/foo", "/bar")) 처럼 arrayOf 함수를 사용한다.

10.1.2 애노테이션 대상

코틀린 소스코드에서 한 선언을 컴파일한 결과가 여러 자바 선언과 대응하는 경우가 자주 있다. 그리고 이때 코틀린 선언과 대응하는 여러 자바 선언에 각각 애노테이션을 붙여야 할 때가 있다.

예를 들어 코틀린 프로퍼티는 기본적으로 자바 필드와 게터 메서드 선언과 대응한다. 프로퍼티가 변경 가능하면 세터에 대응하는 자바 세터 메서드와 세터 파라미터가 추가된다. 게다가 주 생성자에서 프로퍼티를 선언하면 이런 접근자 메서드와 파라미터 외에 자바 생성자 파라미터와도 대응이 된다. 따라서 애노테이션을 붙일 때 이런 요소 중 어떤 요소에 애노테이션을 붙일지 표시할 필요가 있다.

사용 시점 대상 선언으로 애노테이션을 붙일 요소를 정할 수 있다. 사용 시점 대상은 @ 기호와 애노테이션 이름 사이에 붙으며, 애노테이션 이름과는 : 으로 분리된다.

사용 지점 대상을 지정할 때 지원하는 대상 목록은 아래와 같다.

property 프로퍼티 전체. 자바에서 선언된 애노테이션에는 이 사용 지점 대상을 사용할 수 없다.
field 프로퍼티에 의해 생성되는 (뒷받침하는) 필드
get 프로퍼티 게터
set 프로퍼티 세터
receiver 확장 함수나 프로퍼티의 수신 객체 파라미터
param 생성자 파라미터
setparam 세터 파라미터
delegate 위임 프로퍼티의 위임 인스턴스를 담아둔 필드
file 파일 안에 선언된 최상위 함수와 프로퍼티를 담아두는 클래스

10.1.3 애노테이션을 활용한 JSON 직렬화 제어

직렬화란?

직렬화(serialization)는 객체를 저장장치에 저장하거나 네트워크를 통해 전송하기 위해 텍스트나 이진 형식으로 변환하는 것이다.

역직렬화란?

역직렬화(deserialization)는 텍스트나 이진 형식으로 저장된 데이터로부터 원래의 객체를 만들어낸다.

Person 의 인스턴스를 serialize 함수에 전달하면 JSON 표현이 담긴 문자열을 돌려받는다.

data class Person(val name: String, val age: Int)

>>> val person = Person("Alice", 29)
>>> println(serialize(person))

{"age": 29, "name": "Alice"}

JSON 표현을 다시 객체로 만들려면 deserialize 함수를 호출한다.

>>> val json = """{"name": "Alice", "age": 29}"""
>>> println(deserialize<Person>(json))

Person(name=Alice, age=29)

JSON에는 객체의 타입이 저장되지 않기 때문에 JSON 데이터로부터 인스턴스를 만들려면 타입 인자로 클래스를 명시해야 한다. 여기서는 Person 클래스를 타입 인자로 넘겼다.

애노테이션을 활용해 객체를 직렬화하거나 역직렬화하는 방법을 제어할 수 있다. 객체를 JSON으로 직렬화할 때 제이키드 라이브러리는 기본적으로 모든 프로퍼티를 직렬화하면 프로퍼티 이름을 키로 사용한다. 애노테이션을 사용하면 이런 동작을 변경할 수 있다.

@JsonExclude 애노테이션을 사용하면 직렬화나 역직렬화 시 그 프로퍼티를 무시할 수 있다.
@JsonName 애노테이션을 사용하면 프로퍼티를 표현하는 키/값 쌍의 키로 프로퍼티 이름 대신 애노테이션이 지정한 이름을 쓰게 할 수 있다.

10.1.4 애노테이션 선언

@JsonExclude 애노테이션

아무 파라미터도 없는 가장 단순한 애노테이션
애노테이션 선언은 일반 클래스 선언처럼 보이지만 일반 클래스와 차이는 class앞에 annotation이라는 변경자가 붙어있다는 점이다.
애노테이션은 오직 선언이나 식과 관련있는 메타데이터의 구조를 정의하기 때문에 내부에 아무 코드도 들어있을 수 없다.

@Target(AnnotationTarget.PROPERTY)
annotation class JsonExclude

@JsonName 애노테이션

파라미터가 있는 애노테이션
파라미터는 애노테이션 클래스의 주생성자에 파라미터를 선언해야 한다.
다만 애노테이션 클래스는 모든 파리미터에 앞에 val을 붙여야 한다.

@Target(AnnotationTarget.PROPERTY)
annotation class JsonName(val name: String)

10.1.5 메타애노테이션: 애노테이션을 처리하는 방법 제어

메타애노테이션이란?

애노테이션 클래스에 적용할 수 있는 애노테이션

표준라이브러리에서는 몇 가지 메타애노테이션이 있으며, 그런 애노테이션은 컴파일러가 애노테이션을 처리하는 방법을 제어한다. 가장 흔히 쓰는 메타에노테이션은 @Taget이다. 제이키드 라이브러리는 프로퍼티 애노테이션만을 사용하므로, 애노테이션 클래스에 @Target을 지정해야 한다. 필요하다면 둘 이상의 대상을 한꺼번에 선언할수 있다.

@Target(AnnotationTarget.PROPERTY, AnnotationTarget.METHOD)
annotation class JsonExclude

만약 메타애노테이션을 직접 만든다면 AnnotationTarget.ANNOTATION_CLASS를 대상으로 지정하라.

@Target(AnnotationTarget.ANNOTATION_CLASS)
annotation class BindingAnnotation

@BindingAnnotation
annotation class MyBinding

10.1.6 애노테이션 파라미터로 클래스 사용

어떤 클래스를 선언 메타데이터로 참조할 수 있는 기능이 필요할 때에는 클래스 참조를 파라미터로 하는 애노테이션 클래스를 선언하면 그런 기능을 사용할 수 있다.

@DeserializeInterface애노테이션

직렬화된 Person 인스턴스를 역직렬화하는 과정에서 company 프로퍼티를 표현하는 JSON을 읽으면 제이키드는 그 프로퍼티 값에 해당하는 JSON을 역직렬화하면서 CompanyImpl의 인스턴스를 만들어 Person 인스턴스의 company 프로퍼티에 설정한다. 이렇게 역직렬화에 사용할 클래스를 지정하기 위해 DeserializeInterface 애노테이션의 인자로 CompanyImpl::class를 넘긴다.

interface Company { 
    val name: String
}

data class CompanyImpl(override val name: String) : Company

data class Person(
    val name: String,

    @DeserializeInterface(CompanyImpl::class) 
    val company: Company
)

KClass는 자바 java.lang.class타입과 같은 역할을 하는 코틀린 타입이다. 코틀린 클래스에 대한 참조를 저장할 때 KClass 타입을 사용한다.

10.1.7 애노테이션 파라미터로 제네릭 클래스 받기

기본적으로 제이키드는 원시 타입이 아닌 프로퍼티를 중첩된 객체로 직렬화 한다. 이런 기본동작을 변경하고 싶으면 값을 직렬화하는 로직을 직접 제공하면 된다. 클래스를 인자로 받아야 하면 애노테이션 파라미터 타입에 KClass<out 허용할 클래스 이름> 을 쓴다. 제네릭 클래스를 인자로 받아야 하면 KClass<out 허용할 클래스 이름<*>> 처럼 허용할 클래스 이름 뒤에 스타 프로젝션을 덧붙인다. 이 애노테이션이 어떤 타입에 대해 쓰일 지 알 수 없기 때문이다.

@CustomSerializer 애노테이션은 커스텀 직렬화 클래스에 대한 참조를 인자로 받는다.

data class Person( 
    val name: String,
    @CustomSerializer(DateSerializer::class) val birthDate: Date
)

annotation class CustomSerializer(
	val serializerClass: KClass<out ValueSerializer<*>>
)

10.2 리플렉션: 실행 시점에 코틀린 객체 내부 관찰

리플렉션이란?

실행 시점에 동적으로 객체의 프로퍼티와 메서드에 접근할 수 있게 해주는 방법

코틀린에서 리플렉션을 사용하려면 두 가지 서로 다른 리플렉션 API를 다뤄야 한다.

java.lang.reflect 패키지를 통해 제공하는 표준 리플렉션
코틀린이 kotlin.reflect 패키지를 통해 제공하는 코틀린 리플렉션

JSON 직렬화 라이브러리는 어떤 객체든 JSON으로 변환할 수 있어야 하고, 실행 시점이 되기 전까지는 라이브러리가 직렬화할 프로퍼티나 클래스에 대한 정보를 알 수 없다. 이런 경우 리플렉션을 사용해야 한다.

10.2.1 코틀린 리플렉션 API: KClass, KCallable, KFunction, KProperty

kClass

java.lang.class에 해당하는 KClass를 사용하면 클래스 안에 모든 선언을 열거하고 각 선언에 접근하거나 클래스의 상위 클래스를 얻는 등의 작업이 가능하다. 실행시점에 객체의 클래스를 얻으려면 먼저 객체의 javaClass 프로퍼티를 사용해 객체의 자바 클래스를 얻어야 한다. javaClass는 자바의 java.lang.Object.getClass()와 같다. 일단 자바 클래스를 얻었으면 kotlin 확장 프로퍼티를 통해 자바에서 코틀린 리플렉션 API로 옮겨올수 있다.

class Person(val name: String, val age: Int)

>>> import kotlin.reflect.full.*          # memberProperties 확장함수 import
>>> val person = Person("Alice", 29)
>>> val kClass = person.javaClass.kotlin  # kClass<Person>의 인스턴스를 반환한다.
>>> println(kClass.simpleName)
Person
>>> kClass.memberProperties.forEach { println(it.name) }
age
name

KClass에 대해 사용할 수 있는 다양한 기능은 실제로 kotlin-reflect 라이브러리 (implementation "org.jetbrains.kotlin:kotlin-reflect") 를 통해 제공하는 확장함수다. 이런 확장함수를 사용하기 위해서는 import kotlin.reflect.full.* 로 확장함수를 import해야 한다.

kCallable

함수와 프로퍼티를 아우르는 공통 상위 인터페이스이다. 그안에는 call메소드가 있다. call을 사용하면 함수나 프로퍼티의 게터를 호출할 수 있다.

interface KClass<T : Any>
{ 
    val simpleName: String?
    val qualifiedName: String?
    val members: Collection<KCallable<*>>
    val constructors: Collection<KFunction<T>>
    val nestedClasses: Collection<KClass<*>>
    ...
}
interface KCallable<out R> {
    fun call(vararg args: Any?): R
    ...
}

kFunction

리플렉션 call을 사용할 때는 함수 인자를 vararg 리스트로 전달한다. ::foo식의 값 타입이 리플렉션 API에 있는 KFunction 클래스의 인스턴스임을 알 수 있다. 이 함수 참조가 가르키는 함수를 호출하려면 KCallable.call 메소드를 호출한다.

fun foo(x: Int) = println(x)
>>> val kFunction = ::foo
>>> kFunction.call(42)
42

kProperty

kProperty의 call 메서드를 호출할 수 있다. kProperty의 call은 프로퍼티의 게터를 호출한다.

>>> var counter = 0
>>> val kProperty = ::counter
>>> kProperty.setter.call(21)
>>> println(kProperty.get()) 
21

멤버 프로퍼티는 kProperty1 인스턴스로 표현된다.

class Person(val name:String, val age:Int)
>>> val person = Person(“Alice”, 29)
>>> val memberProperty = Person::age
>>> println(memberProperty.get(person)) 
>>> 29

10.2.2 리플렉션을 사용한 객체 직렬화 구현

아래 함수는 클래스의 각 프로퍼티를 차례로 직렬화한다. 결과 JSON은 { prop1: value1, prop2: value2 } 같은 형태다.

private fun StringBuilder.serializeObject(obj: Any){
    val kClass = obj.javaClass.kotlin
    val properties = kClass.memberProperties
    properties.jointToStringBuilder(
    		this, prefix = “{“, postfix = “}”) { prop -> 
        serializeString(prop.name)
        append(“: “)
        serializePropertyValue(prop.get(obj)) 
    }
}

10.2.3 애노테이션을 활용한 직렬화 제어

10.2.4 JSON 파싱과 객체 역직렬화

10.2.5 최종 역직렬화 단계: callBy(), 리플렉션을 사용해 객체 만들기

[Kotlin In Action]6장 - 코틀린 타입 시스템

로그뉴 — Mon, 13 Mar 2023 23:28:07 +0900

** 이 글은 Kotlin In Action을 읽고 정리한 글입니다. **

1. 널 가능성

fun strLenSafe(s: String?) = s.length()

타입 이름 뒤에 물음표(?)를 붙이면 그 타입의 변수나 프로퍼티에 null 참조를 저장할 수 있다.

val x:String? = null
val y:String = x

널이 될 수 있는 값을 널이 될 수 없는 타입의 변수에 대입할 수 없다.

안전한 호출 연산자 ?.

null 검사와 메서드 호출을 한 번의 연산으로 수행한다.

val country = this.company?.address?.country

엘비스 ?:연산자

이항 연산자로 좌항을 계산한 값이 널인지 검사한다. 좌항 값이 널이 아니면 좌항 값을 결과로 하고, 좌항 값이 널이면 우항 값을 결과로 한다.

val info = xxxRepository.findById(id) ?: throw CustomException()

안전한 캐스트 as?

as?는 값을 대상 타입으로 변환할 수 없으면 null을 반환한다.

val otherPerson = o as? Person ?: return false // 변환 실패시 null 반환

널 아님 단언 !!

어떤 값이든 널이 될 수 없는 타입으로 강제로 바꿀 수 있다.

여러 !! 단언문을 한 줄에 함께 쓰는 것을 피하라.

val sNotNull: String = s!!

let 함수

null이 될 수 있는 값을 null이 아닌 값만 인자로 받는 함수에 넘기는 경우.

let 함수는 자신의 수신 객체를 인자로 전달받은 람다에게 넘긴다.

let을 중첩시키는 것보다, if를 사용해 모든 값을 한꺼번에 검사하는 편이 낫다.

email?.let { sendEmailTo(it) }

lateinit 나중에 초기화

프로퍼티를 나중에 초기화 할 수 있는 키워드로, 나중에 초기화하는 프로퍼티는 항상 var여야 한다.

private lateinit var myService: MyService

Null이 될 수 있는 타입 확장

널이 될 수 있는 타입의 확장 함수는 안전한 호출 없이도 호출 가능하다.

코틀린에서는 널이 될 수 있는 타입의 확장함수 안에서는 this가 널이 될 수 있다는 점이 자바와 다르다.

input.isNullorEmpty()
input.isNullorBlank()

타입 파라미터의 널 가능성

모든 타입 파라미터는 기본적으로 널이 될 수 있다.
널 가능 타입과 널 불가 타입 모두 타입 파라미터 인자로 사용 가능하다.

타입 파라미터 T를 클래스나 함수 안에서 타입 이름으로 사용하면 이름 끝에 물음표가 없더라도 T가 널이 될 수 있는 타입이다.

fun <T> printHashCode(t: T) { // t는 Any? 타입으로 추론
    println(t?.hashCode()) 
}

fun <T: Any> printHashCode(t: T) { // t는 Any 타입으로 추론
     println(t.hashCode())
}

타입 파라미터가 널이 아님을 확실히 하려면 널이 될 수 없는 타입 상한을 지정해야 한다.

fun <T: Any> printHashCode(t: T) { // 널이 될 수 없는 타입 T
		println(t.hashCode())
}

자바의 널 가능성 애노테이션

자바 코드에 널 가능성 애노테이션을 사용하면 코틀린은 그 정보를 활용한다.

@Nullable String ‐> String?
@NotNull String ‐> String

JSR‐305 표준, 안드로이드, 젯브레인 애노테이션 등의 널 가능성 애노테이션 지원한다.

플랫폼 타입

널 관련 정보를 알 수 없는 자바 타입을 말한다.

널 가능 타입으로 처리해도 되고 널 불가 타입으로 처리해도 되기 때문에 널 가능성을 코틀린 코드에서 알맞게 처리해야 한다.

코틀린에서 플랫폼 타입을 선언할 수는 없고, 자바 코드에서 가져온 타입만 플랫폼 타입이 된다.

public class Person { 
    private final String name;
    public String getName() {
       return name;
    }   
}

fun yellAt(p: Person) {
    println(person.name.toUpperCase() + "!!!") // person.name이 null일 때 예외 발생
}

fun yellAtSafe(p: Person) {
    println((person.name ?: "Anyone").toUpperCase() + "!!!")
}

2. 코틀린의 원시 타입

코틀린은 원시 타입과 래퍼 타입을 구분하지 않는다.

숫자 변환

한 숫자 타입을 다른 타입 숫자로 자동 변환하지 않으므로 명시적으로 변환해야 함

숫자 리터럴은 컴파일러가 필요한 변환을 자동으로 처리 연산자를 각 타입에 대해 오버로딩하고 있다.

val b: Byte = 1
val l = b + 1L
val l1: Long = 42 // Int 타입 리터럴을 Long으로 컴파일러가 변환 
val i: Int = 42 
val l2: Long = i.toLong()

최상위 타입

val answer: Any = 42

Any 타입은 모든 널이 될 수 없는 타입의 조상 타입니다. 내부에서 Any는 Object에 대응한다. 코틀린에서 Any를 사용하면 자바 바이트코드의 Object로 컴파일된다.

Any 타입에는 널이 들어갈 수 없다! -> Any?를 사용해야 널 허용.
Any: toString, equals, hashCode 세 개의 메서드 제공

Unit 타입

Unit 타입은 자바의 void와 같은 기능을 한다.

관심을 가질 만한 내용을 리턴하지 않는 함수의 리턴 타입으로 Unit 사용한다.
Unit은 void와 달리 타입, Unit이라는 단일 값을 가짐. 리턴 타입이 Unit인 함수는 묵시적으로 Unit을 리턴

interface Processor<T> {
    fun process(): T
}

class NoResultProcessor: Processor<Unit> {
    override fun process() {
        // 업무 처리 코드
    }
}

Nothing 타입

fun fail(message: String): Nothing {
     throw IllegalStateException(message)
}

Nothing 타입은 함수가 결코 정상적을 끝나지 않는다는 의미를 가지고 있다.

Nothing 타입은 아무 값도 포함하지 않는다. 함수의 반환 타입이나 반환 타입으로 쓰일 타입 파라미터로만 쓸 수 있다.

3. 컬렉션과 배열

읽기 전용과 변경 가능한 컬렉션

인터페이스 분리
- kotlin.collections.Collection : 조회 기능만 제공
- kotlin.collections.MutableCollection : 수정 기능도 함께 제공

읽기 전용 컬렉션 인터페이스는 읽기 전용이고, 실제 구현체는 수정 가능할 수 있다.

코틀린 컬렉션과 자바

모든 코틀린 컬렉션은 그에 상응하는 자바 컬렉션 인터페이스의 인스턴스이다.

읽기 전용과 변경 가능 2가지를 제공한다.