Access Token과 Refresh Token을 어디에 저장해야 하는가

JWT를 구현하면서 처음 고민했던 부분은 Access Token과 Refresh Token을 어디에 저장할 것 인가에 대한 것이었다. 로컬스토리지와 세션 스토리지는 자바스크립트로 토큰 값을 조작할 수 있어 XSS공격에 취약하기 때문에 쿠키를 사용하기로 했다. 물론 쿠키도 CSRF 공격에 활용될 수 있지만 SameSite나 Secure 정책으로 충분히 보완할 수 있다고 판단했다.

결과적으로 두 토큰을 서버(Redis) 에 저장하고, 클라이언트에는 Access Token만 쿠키로 전달하는 방식을 선택했다. 재발급 흐름은 다음과 같다. 만료된 Access Token을 사용해 Redis에서 Refresh Token을 조회하고, Refresh Token이 유효하면 새로운 Access Token을 발급해 Redis에 저장한 뒤 클라이언트에 다시 전달한다. Access Token을 Redis에 저장하는 이유는, 만료된 토큰을 Redis의 키로 관리하여 이미 사용된(혹은 재사용된) 토큰을 즉시 식별·차단함으로써 타인이 해당 토큰을 악용하지 못하도록 하기 위함이다.

토큰의 완전한 무상태(Stateless)를 포기하고, 토큰과 세션의 장점을 결합하려 했다.

이같은 구조를 채택했을 때의 장단점은 다음과 같다.

1. 쿠키 탈취 우려
   • Refresh Token가 쿠키로 전달되면 이를 탈취하여 토큰 재발급을 시도할 수 있다. HttpOnly 옵션으로 토큰 유출 위험을 낮출 수 있지만, 허점이 있을 수 있으므로 서버에 저장하는 것이 더 안전하다고 판단했다. 특히, Refresh Token은 유효기간을 길게 설정하므로 탈취 성공 시 피해가 더욱 크다.
2. 서버 측 즉시 제어 가능
   • Refresh Token을 서버에 보관하기 때문에 이를 삭제하여 해당 세션을 무효화 할 수 있다.
3. 만료된 쿠키 재사용 방지
   • Access Token을 Redis 키로 관리하면, 이미 만료되어 재발급 흐름에 사용된 토큰이나 재사용 시도를 즉시 탐지·차단할 수 있다.
4. 서버부하(트레이드오프)
   • 완전한 무상태가 아니므로, Access Token의 재발급시 서버에 일정 부하가 발생한다. 하지만 Access Token이 유효할 때는 단순 검증만 수행하므로 서버부담이 크지 않다.
5. 구현 복잡성 증가(트레이드오프)
   • 세션 또는 완전 stateless JWT보다 구현, 운영 복잡성이 높다(쿠키 정책, 재발급 흐름 등). 그럼에도 보안과 운영 제어의 이점이 이를 감수할 가치가 있다고 판단했다.

JWT 필터에서 재발급

(JWT 인증필터, Jwt Provider)

초기 구현에서는 재발급 로직을 JWT 인증 필터에 위임했다. 필터가 토큰의 유효성 검사와 함께 Access Token이 만료되면 즉시 재발급하도록 했다. Access Token 만료 자체가 토큰 손상이나 위변조를 의미하는 것은 아니므로, “바로 재발급해 응답하면 별도의 재발급 API는 불필요하다”는 판단이었다.

그러나 프론트엔드와 연동해 동시다발적으로 API를 호출해 보니 문제가 드러났다. 어떤 요청은 서버에서 재발급까지 성공했는데도, 다른 동시 요청들이 인증 실패가 발생했다.

문제의 근본 원인은 경쟁 상태(Race Condition) 였다. 프론트엔드에서는 한 페이지에서 다수의 AJAX 요청이 동시에 발생한다. 이 비동기적/동시다발적 요청 중 하나가 재발급 로직을 통해 새로운 Access Token을 발급받는 동안, 나머지 요청들은 여전히 갱신되기 전의 만료된 토큰을 담아 서버로 전송된다. 이로 인해, 서버는 일부 요청에 대해서는 재발급이 성공했음에도 불구하고 다른 요청들은 유효하지 않은 토큰으로 인증을 시도하게되어 인증에 실패하게 된다.

요청 인터셉터와 토큰 유효성 확인 API

결국 깨달은 건, 재발급을 서버가 알아서 해주길 바라면 Race Condition은 피할 수 없다는 거였다. 그래서 Axois 요청 인터셉터를 사용하여 메인 요청을 보내기 전에 클라이언트가 /auth로 토큰의 유효성을 확인 후 메인 요청을 수행하도록 리펙토링을 진행했다.

지금 생각해보면 정말 멍청한 생각이다. 문제를 제대로 이해하지 못한 상태에서 성급하게 해결책을 도입한 전형적인 임시 방편에 불과했다. 겉으로는 문제를 줄이는 것처럼 보였지만, 오히려 구조는 꼬이고 보안성은 떨어졌다.

1. 비효율성과 서버과부화
   • 요청 인터셉터는 모든 요청마다 /auth를 선행 호출한다. 이로 인해 토큰이 유효함에도 불필요하게 /auth가 호출되어 네트워크 비용이 증가하고, 서버에 과도한 부하를 유발하는 비효율적인 구조가 되었다.
2. 재발급로직의 중복
   • /auth와 요청인터셉터를 도입했음에도 Jwt 인증필터의 재발급로직은 삭제하지 않았기에 재발급로직이 중복되어 쿠키 갱신 타이밍과 Redis 갱신이 요청 단위로 뒤섞이면서 복잡성이 증가했다.
3. 요청 인터셉터간 경쟁 상태
   • 단순 요청 인터셉터의 도입은 전의 문제와 근본적으로 같은 문제를 반복했다. 단지 그냥 요청의 재발급 경쟁상태가 /auth에서 일어난 것 뿐이다. 덕분에 표면적인 인증실패를 줄이기 위해 /auth의 재발급 로직을 엑세스토큰-Redis 바인딩 체크을 하지 않고, Redis에서 토큰의 payload에 있는 유저의 id으로 Refresh Token을 조회 후 재발급하는 끔찍한 구조를 만들고 말았다.

결과적으로 이 리팩토링은 구조의 복잡성은 올라가고, 보안성은 후퇴한 실패한 리팩토링이었다.

응답 인터셉터와 재발급 단일화 구조

지금까지의 JWT 인증필터는 너무 많은 책임이 부여되어 토큰의 검증과 만료된 토큰을 재발급까지 수행했다. 모든 요청은 JWT 인증필터를 거치기 때문에 이곳에서 재발급이 이루어 진다면 경쟁상태(Race Condition)이 발생할 가능성이 너무 높았다. 또한 서로 다른 책임을 하나의 필터가 담당하므로 단일 책임 원칙에 반하며 이는 코드 복잡도 증가와 유지보수성이 저하되게 했다. 애초에 인증필터는 요청을 가로채 인증을 확인하는 역할인데 왜 이렇게 만들었는지 모르겠다.

그래서 JWT 인증필터에서는 토큰의 인증만 확인하도록 리펙토링했다. 이제 만료가 되었든 이상한 토큰이든 Valid한 토큰이 아니면 401을 던지도록 설계했다. 재발급은 별도의 API(/token/refresh)를 구현하여 재발급을 수행하도록 했다. 인증과 재발급 로직을 분리함으로써 각 컴포넌트가 단일 책임을 가지게 되어 클라이언트가 토큰 상태를 명확히 제어할 수 있게 되었다.

(JWT인증필터, JWT Provider, 재발급 API)

서버의 설계는 끝났다. 그렇다면 이제 클라이언트 쪽에서는 토큰을 어떻게 관리해야 할까? 이전 시도에서처럼 요청 인터셉터를 사용해 /auth를 매번 호출하는 방식은 결국 서버 부하만 늘리고 근본적인 문제를 해결하지 못했다. 결국 내가 내린 결론은 “서버는 알아서 재발급을 처리할 수 없고 재발급의 주도권은 반드시 클라이언트가 가져야 한다.” 였다. 그렇다면 가장 자연스러운 방법은, 서버가 만료된 토큰에 대해 401을 던지면 클라이언트는 이 응답을 토대로 토큰이 만료되었다는 판단 후 재발급을 요청하는 것 이다.

이때 사용할 수 있는 것이 Axios의 응답 인터셉터(Response Interceptor) 이다. 응답 인터셉터는 요청 인터셉터와 비슷하게 서버의 응답을 가로채 공통 로직을 실행할 수 있는 훅이다. 이를 통해 “401이 발생하면 /token/refresh로 재발급을 요청하고, 재발급이 완료되면 원래의 요청을 다시 시도한다”라는 흐름을 구현할 수 있다. 하지만 여기까지만 구현하면 경쟁 상태가 다시 발생할 수 밖에 없다. 전의 경우와 동일하게 여러 API를 동시에 호출하고, 그 모든 요청의 토큰이 만료된 상태라면, 각 요청의 인터셉터가 거의 동시에 /token/refresh를 호출하게 된다. 경쟁상태가 다른 형태로 반복되는 것 이다.

이를 해결하기 위해 Axios 인터셉터 기반의 단일 재발급(Single-Flight) 패턴을 도입했다.

Single-Flight란 같은 키에 대한 중복 작업을 한 번만 실행하고, 나머지 경쟁자들은 그 결과를 공유하도록 하는 중복 억제(deduplication) 기법이다. Go에서 널리 쓰이는 듯 하다.

이를 응답 인터셉터와 조합하면 다음과 같은 흐름이 가능하다.

1. 최초의 401 응답을 받은 요청만이 /token/refresh API를 호출한다.
2. 그 외의 모든 요청은 재발급이 완료될 때까지 대기열에 등록된다.
3. 재발급이 완료되면 대기 중이던 모든 요청이 순차적으로 다시 실행된다.

즉, 한 번의 재발급 요청만 수행하고, 그 사이 들어온 다른 요청들은 잠시 큐에 대기시킨 뒤, 재발급이 완료되면 새 토큰으로 모두 다시 시도하도록 설계했다.

좀 더 자세한 로직은 다음과 같다.

1. 401 응답을 받은 요청이 _retry 플래그로 중복 재시도를 방지한다.
2. 현재 재발급 중(isRefreshing = true)이라면, 해당 요청을 refreshSubscribers 큐에 등록한다.
3. 재발급이 완료되면 onRefreshed()가 호출되어 대기 중이던 요청들이 한꺼번에 다시 실행된다.
4. 재발급이 실패하면 모든 대기 요청은 취소되고, 사용자는 로그인 페이지로 이동된다.

let isRefreshing = false;
let refreshSubscribers = [];

const onRefreshed = () => {
  refreshSubscribers.forEach(callback => callback());
  refreshSubscribers = [];
};

const addRefreshSubscriber = (callback) => {
  refreshSubscribers.push(callback);
};

결과적으로 재발급은 오직 한 번만 수행되고, 모든 요청이 새 토큰으로 정상 재시도되는 안정적인 구조가 완성되었다. 이제 서버는 토큰 검증에만 집중하고, 클라이언트가 토큰 라이프사이클을 완전히 제어할 수 있게 되었다. 결과적으로 JWT 인증 구조 전반이 훨씬 단순하고 안정적으로 작동하게 되었다.

(응답 인터셉터 전체 코드)

이런 웹소켓 핸드쉐이크가 인터셉터를 안타잖아?

WebSocket 연결은 new WebSocket(url)로 시작되는 HTTP 업그레이드(handshake) 요청이고, 이 경로는 Axios가 만드는 HTTP 요청이 아니다. 당연히 Axios 인터셉터는 Axios가 만든 요청/응답에만 개입할 수 있으니, 웹소켓 핸드셰이크에는 애초에 끼어들 수 없다. 그래서 분명 재발급이 이루어 졌음에도 웹소켓 연결이 어떤 이유로 연결이 끊겨 재연결을 시도하면 인증문제로 실패했다.

결국 웹소켓 핸드쉐이크와 Axios요청 모두 하나의 재발급 요청 후 이를 공유해야한다. 이를위해 refreshManager라는 중간 매개체를 만들었다. refreshManager는 safeRefreshToken() 함수를 가지는데 이 함수는 실제 재발급 요청을 날리는 함수다.

// refreshManager.js
import axios from 'axios';

let isRefreshing = false;
let refreshPromise = null;

export const safeRefreshToken = async () => {
  if (isRefreshing) return refreshPromise;

  isRefreshing = true;
  refreshPromise = axios.get(`${process.env.REACT_APP_API_URL}/token/refresh`, {
    withCredentials: true,
  })
    .catch((err) => {
      throw err;
    })
    .finally(() => {
      isRefreshing = false;
    });

  return refreshPromise;
}; 

axiosInstance는 내부에서 safeRefreshToken()를 호출하여 재발급을 처리한다.

// axiosInstance.js
import axios from 'axios';
import { safeRefreshToken } from './refreshManager'; //

const instance = axios.create({
  baseURL: process.env.REACT_APP_API_URL,
  withCredentials: true,
});

let refreshSubscribers = [];

const onRefreshed = () => {
  refreshSubscribers.forEach(callback => callback());
  refreshSubscribers = [];
};

const addRefreshSubscriber = (callback) => {
  refreshSubscribers.push(callback);
};

// 응답 인터셉터
instance.interceptors.response.use(
  (response) => response,
  async (error) => {
    const { config, response } = error;
    const originalRequest = config;

    if (response?.status === 401 && !originalRequest._retry) {
      originalRequest._retry = true;

      return new Promise((resolve, reject) => {
        addRefreshSubscriber(() => {
          resolve(instance(originalRequest)); // 재요청 실행
        });

        // 단 한 번만 refresh 실행
        safeRefreshToken()
          .then(() => {
            onRefreshed(); // 대기 중인 요청들 처리
          })
          .catch((err) => {
            window.location.replace('/login');
            reject(err);
          });
      });
    }

    return Promise.reject(error);
  }
);

export default instance;

그리고 웹소켓은 연결이 끊어졌을 때(onWebSocketClose) 즉시 재연결하지 않고, 먼저 await safeRefreshToken()으로 최신 쿠키/토큰 확보 후 재연결한다. 이렇게 하면 한번의 재발급 요청으로 Axios와 웹소켓이 같은 Promise(같은 결과)를 공유하게 되어 갱신된 토큰으로 모든 요청이 처리될 수 있다.

🚶 axios 요청1  ┐
🚶 axios 요청2  ┼─────┐
🧍 websocket    ┘     │
                    ⏳ [safeRefreshToken 호출]
                      ↓
                🔄 /token/refresh
                      ↓
         ☑️ 성공  → 대기하던 요청들 다 실행
         ❌ 실패  → 로그인 페이지로 이동

마무리

Race Condition은 이 프로젝트를 진행하면서 나를 계속 괴롭게 했던 문제였다. JWT토큰은 물론이고 인증구현이 처음이라 안그래도 하나하나 알아가며 구현했어야 했는데, 동시성 문제까지 닥치니 매우 힘들었던 기억이 생생하다. 심지어 프론트 쪽 코드도 처음 작성해봤기에 배로 힘들었다. 그러나 이러한 경험이 없었다면 오랜 기간 Race Condition을 알거나 마주치기 어려웠을 것 이다. Axios 인터셉터라는 백엔드 개발자에게는 조금은 생소한 개념도 알게되었다. 결과적으로 인증관련 흐름을 깨지고 부서지며 체득할 수 있었던 경험이다. 또한, 설계의 중요성도 깨닫게 된것 같다. 무작정 구현만 일단 달려들면 더 큰 시련에 부딪힐 수 있다는 것을 몸으로 직접 깨달았다. 뭔가를 빨리 구현하고싶은 마음은 여전하지만 이때에 비해 설계에 훨씬 많은 시간을 쏟고 있다.

ORM (Object Relational Mapping)

Java와 DB는 서로 데이터를 관리하는 방식이 다르다.

Java는 객체의 형태로 데이터를 관리하지만 RDB는 이를 표 형식으로 저장하고 연관관계를 외래키를 이용하여 형성한다.

이런 두 패러다임의 괴리를 객체-관계 불일치라고 하고, 이 때문에 DB의 데이터를 객체로 변환하는 과정에서 적절한 매핑이 필요하다.

ORM은 바로 이러한 괴리를 해결하기위해 데이터베이스와 객체의 매핑을 수행하는 방법을 제공한다.

추가로 ORM은 이러한 매핑을 통해 SQL문을 직접 생성하고 수행까지 한다.

물론 단점(trade-off)도 존재하는데 SQL 쿼리가 개발자을 안거치고 자동으로 만들어져 수행되기에 의도와 다른 쿼리가 발생할 수도 있고, 성능이 떨어질 수도 있다.

그렇기에 상황에 따라 ORM에 쿼리를 맡길지 직접 작성할지 판단이 필요하다.

JPA (Java Persistensce API)

JPA는 자바 진영의 ORM 표준 명세로, 애플리케이션과 데이터베이스 간 객체-관계 매핑을 일관된 방식으로 다룰 수 있도록 하는 인터페이스 집합이다.

JPA 자체가 기능을 구현하는 것은 아니며, Hibernate, EclipseLink와 같은 구현체가 실제 동작을 담당한다.

JPA를 사용하면 다음과 같은 장점을 얻을 수 있다. • 엔티티와 테이블 매핑: 자바 클래스와 DB 테이블 간 매핑을 애노테이션으로 정의 • DDL 자동 생성: 매핑 정보를 기반으로 테이블 스키마 자동 생성 • JPQL 지원: 객체 지향 쿼리를 작성하면 구현체가 이를 SQL로 변환하여 실행 • DB 독립성 향상: 여러 DB 벤더 간 쿼리 차이를 최소화

단, 자동 쿼리 생성과 매핑 편의성 뒤에는 성능 문제가 숨어 있을 수 있다. 따라서 연관관계 설계와 쿼리 튜닝은 여전히 중요하며, 상황에 따라 직접 SQL/네이티브 쿼리를 사용하는 판단도 필요하다.

Hibernate

Hibernate는 JPA를 구현한 구현체 프레임워크 중 하나이다.

Spring Data JPA는 JPA 위의 추상화입니다. 기본적으로 Hibernate를 많이 쓰지만 필수는 아님(EclipseLink 등 다른 구현체도 가능)

이를 한층 더 추상화하여 개발자가 Repository만 정의해도 쿼리 없이 DB 연동이 가능하게 해준다.

Hibernate는 JDBC나 MyBatis에 비해 설정해야 할 것들이 적고, 상당부분이 자동화되어 있다.

또한 변경감지, 지연로딩, 캐시, 트랜잭션 관리 등의 기능을 통해 강력한 영속성 관리 기능을 제공한다.

순수 Hibernate환경에서는 /resources/META-INF/persistence.xml을 통해 데이터베이스 연결 정보, 사용할 엔티티 클래스, JPA 구현체(Hibernate) 등을 설정해야 한다. 이 파일은 JPA의 표준 설정 파일로, Hibernate가 아닌 다른 JPA 구현체에도 공통적으로 사용된다.

하지만 스프링부트에선 application.yml로 보다 간편한 설정이 가능하다. 또한 스프링부트는 @Entity가 붙은 클래스를 스캔해서 자동으로 등록하기에 다른 설정이 필요하지 않다. persistence.xml로 설정해본적 한번도 없다.스프링부트 최고!

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/oauth
    username: dev_bae
    password:

  jpa:
    hibernate:
      ddl-auto: create
    show-sql: true
    properties:
      hibernate:
        format_sql: true

EntityManagerFactory

밑에서 설명할 EntityManager을 생성하는 팩토리 객체이다.

EntityManagerFactory는 EntityManager뿐만 아니라 설정정보를 토대로 DB연결 정보, 커넥션 풀, 매핑된 엔터티 클래스들, 캐시전략, 영속성 컨텍스트등을 생성하기 때문에 생성비용이 크다.

따라서 어플리케이션 전체에서 한 번 생성하고 어플리케이션이 종료되면 close()를 호출해 닫는다.

EntityManager

EntityManager 말 그대로 Entity를 관리하는 객체이다.

즉, 자바객체와 DB의 테이블을 매핑하고 INSERT, SELECT, UPDATE, DELETE을 통한 CRUD작업을 객체 중심으로 쉽게 수행할 수 있게 한다.

EntityManager는 영속성 컨텍스트(Persistence Context)를 이용해 엔터티 객체의 생명주기를 관리한다. 영속성 컨텍스트는 DB에서 가져오거나 저장하는 엔터티 객체를 1차 캐시에 보관하고, 해당 객체의 상태를 추적하여 변경 사항이 감지되면 자동으로 SQL을 생성한다.

또한 트랜잭션의 관리도 맡고있다. 트랜잭션의 시작, 커밋, 롤백을 제어하는 역할도 한다. 보통 Spring에서는 @Transactional을 사용하여 선언적 트랜잭션을 처리한다.

EntityManager는 쓰레드당 하나가 생성되며, EntityManager는 트랜잭션 단위로 Entity를 관리한다.

😓 추가 학습에 따른 수정 EntityManager는 스레드 세이프하지 않다고 합니다. 그러므로 여러 스레드에서 공유해서는 안 됩니다. EntityManager는 보통 요청(Request) 또는 트랜잭션 단위로 생성·관리되며, 트랜잭션이 시작되면 해당 범위 내에서 엔티티를 관리합니다. 스프링에서는 이미 생성된 EntityManager 프록시가 주입되고, 트랜잭션이 시작되면 실제 DB 연결이 바인딩됩니다.

영속성 컨텍스트 (Persistence Context)

EntityManager는 영속성컨텍스트를 이용하여 Entity를 관리한다고 했다. 그럼 영속성컨텍스트는 어떻게 이를 관리하고 어떠한 동작들을 하는가?

영속성컨텍스트는 Entity의 상태를 추적하고, 해당 Entity가 실제 DB와 상호작용하는 방법과 시점을 결정하는 역할을 가지고 있다.

영속성 컨텍스트는 여러 역할을 맡고있다.

1. Entity 상태 관리(상태 추적)

   Entity의 생명주기(Transient → Managed → Detached → Removed)를 관리

   영속화(persist())하면 Managed(영속상태)로 진입하여, 영속성 컨텍스트가 이를 추적한다.

   ⇒ 이로인해 변경감지가(Dirty Checking)이 가능.

   • Entity의 생명주기 상태

     • 비영속(new / transient)

       영속성 컨텍스트가 관리하지 않는 상태이다. 그러므로 변경감지가 이루어지지 않고 DB에 저장되지도 않는다. 이를 영속성 컨텍스트가 관리하게 하기 위해선 merge나 persist되어야 한다.

     • 영속(persist()/managed)

       영속성 컨텍스트에 의해 관리되고 있는 상태이다. Entity의 변경사항을 추적하고, 트랜잭션이 커밋되면 변경사항이 DB에 반영된다.

     • 준영속(detach() / detached)

       더 이상 영속성 컨텍스트의 관리를 받지 않는 상태이다. (영속상태였다가 분리 된 상태) 비영속 상태와 동일하게 변경감지가 되지 않고 커밋하여도 DB에 반영되지 않는다. merge()를 통해 영속상태로 변경이 가능하다.

     • 삭제(remove() / removed)

       영속성 컨텍스트 뿐만 아니라 DB에서도 삭제를 하기 위한 상태이다. 커밋 시 DB에서 삭제된다.

       

2. 변경감지(Dirty Checking)

   영속성 컨텍스트에서 관리되고 있는 Entity객체의 상태변화를 자동으로 감지하여 이를 DB에 반영한다.

   이를 위해 스냅샷(Snapshot)이 사용되는데, 이는 Entity객체의 초기 상태를 저장하고 있다. 이후, Entity 객체체의 상태가 변경되면 가장 최신의 상태와 스냅샷을 비교하여 변경을 파악한다. 이 변경을 커밋시에 DB에 반영된다.

1. 1차캐시

   영속성 컨텍스트에 저장된 Entity는 DB에 조회하지 않고 바로 꺼내 반환한다.

   동일한 Entity가 동일한 영속성 컨텍스트에서 여러번 조회된다면, 하나하나 DB에 접근하여 반환받아오는 것이 아니고 이를 캐시된 Entity를 반환한다. ⇒ 성능 최적화

   영속성 컨텍스트가 종료되면 해당 캐시는 소멸함.

2. 지연로딩(Lazy Loading)를 통한 연관관계 관리

   지연로딩이란 객체의 전체 데이터를 즉시 불러오지 않고, 실제로 필요한 시점이 되서야 느긋하게 로딩을 하는 전략이다.

   지연로딩을 위해 Hibernate는 프록시객체를 사용한다.

   실제 Entity객체 대신 프록시객체를 반환하는데, 이 프록시 객체는 해당 Entity객체의 메타데이터와 식별자만 보유하고 있고 실제 이 객체에 접근해야할때 실제 DB에서 해당 데이터를 로드한다.

예를 들어, Member 객체가 Profile를 참조하고 있다. 이때 Member 객체를 조회하면 Profile의 실제객체가 아니라 프록시객체가 Member필드에 할당된다. Profile의 데이터를 실제 가져와야 할 때 해당 쿼리가 실행되어 Profile 데이터가 로딩된다.

3. 쓰기지연(Write-behind)

   쓰기지연을 이해하기위해 선행되어야할 개념인 Action Queue라는게 있다.

   Action Queue는 Entity를 관리할 쿼리들을 모아놓은 큐이다.

   즉, Hibernate는 Action Queue를 통해 쿼리를 생성할때마다 DB에 질의하지 않고 모아놨다가 한번에 반영시킨다.

그러면 안되겠지만 변기에 쓰레기를 버리는 못된 사람이 있다고 치자 이사람이 쓰레기를 하나 버릴때마다 물을 내리면 비효율적이지 않겠나? 이를 쓰레기를 변기에 모아놨다가 한번에 물을 내리는(flush)것 이다.
물을 내리는 행위 즉, 모아놨던 쿼리를 DB에 한번에 반영하는 방법은 flush()와 트랜잭션 커밋, JPQL쿼리 발생이 있다.

1. 동일성(identity) 보장

   같은 PK를 가지는 Entity를 영속성 컨텍스트 내에서 같은 객체로 판단하여 관리한다. 이는 ==비교도 동일성 확인이 가능하며, DB의 일관성을 보장해준다.

매핑객체

JPA가 사용할 Entity를 정의하여야 이를 DB에 매핑할 수 있다.

@Entity

Entity는 DB의 테이블을 자바 클래스 형태로 표현한 것이다. 이 Entity클래스의 인스턴스는 DB의 행(Row)를 의미한다.

@Entity 어노테이션으로 선언한다.

@Table어노테이션을 통해 DB의 어떤 테이블과 매핑되어야 하는지를 지정한다. @Table을 사용하지 않으면 클래스의 이름으로 매칭될 테이블의 이름을 유추하여 매핑을 수행한다.

JPA는 내부적으로 리플렉션을 사용해 Entity객체를 만드므로 기본생성자가 필수로 필요하다.

CREATE TABLE members(
    member_id bigint not null primary key auto_increment,
    name varchar(20) not null,
    email varchar(50) not null
);

@Getter
@Entity
@Table(name = "members")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Members {

   ...
}

@Id

테이블의 PK와 매핑되는 필드를 @Id어노테이션으로 선언할 수 있다.

@GeneratedValue를 통해 자동으로 생성되게 하거나, 수동으로 설정할 수 도 있다.

일반적으로 auto_increment와 동일한 IDENTITY전략을 사용한다. 물론 id 생성전략은 여러가지가 있다. 이에 대해 아래에서 알아보겠다.

• 자동 전략 (GenerationType.AUTO) JPA 구현체가 현재 사용 중인 데이터베이스 방언(dialect)에 맞춰 적절한 기본키 생성 전략을 자동으로 선택한다. 예를 들어, MySQL에서는 IDENTITY, Oracle에서는 SEQUENCE 전략을 선택하는 식이다.

  
  

• 시퀀스 전략 (GenerationType.SEQUENCE) 시퀀스 객체를 사용하여 자동으로 id값을 생성한다. @SequenceGenerator를 통해 시퀀스의 이름과 시작 값등을 정의할 수도 있다.

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "user_seq_gen")
    @SequenceGenerator(
        name = "user_seq_gen",
        sequenceName = "user_seq",   // DB 시퀀스 이름과 일치
        allocationSize = 1
    )
    private Long id;

  이렇게 해놓으면 우리가 시퀀스를 직접 호출하지 않아도 JPA가 INSERT전에 자동으로 시퀀스를 호출하여 id값을 생성한다.

  <br>

• 식별자 전략 (GenerationType.IDENTITY) auto_increment와 같은 방식이라고 생각해면 된다. DB에서 auto_increment방식으로 생성된 PK값을 가져와 매핑한다.

  <br>

• 테이블 전략(GenerationType.TABLE) 시퀀스 기능이 없는 DB에서 시퀀스전략과 비슷한 전략을 취할 수 있는 전략이다. @TableGenerator를 사용해 기본키 값을 생성하는 테이블의 설정을 정의할 수 있다.

  <br>

• UUID 전략 (GenerationType.UUID) 우주유일값을 기본키값으로 설정하는 전략이다! 짱 멋지다.

@Column

Hibernate는 기본적으로 필드 이름을 기반으로 DB의 칼럼을 매핑한다.

하지만 서로의 이름이 다르거나 명시적으로 표현해야할 때 @Column의 name을 통해 이름을 명시적으로 매핑 시킬 수 있다.

또한 DB 속성의 제약조건을 표현해 줄 수 있다. (columnDefinition, nullable, unique …)

이를 바탕으로 AutoDDL시 좀 더 구체적으로 테이블을 생성할 수도 있다.

@Enumerated

자바의 enum타입이랑 매핑할때 사용

• @Enumerated(EnumType.ORDINAL: enum클래스에 정의된 순서대로 숫자로 매핑
• @Enumerated(EnumType.STRING : enum의 이름이 그래도 매핑

기본값은 ORDINAL이라 굉장히 킹받는 상황이 생길 수 있다. 웬만하면 @Enumerated(EnumType.STRING)을 사용하자.(순서 변경 시 데이터 깨짐 방지).

연관관계

위에서 정리한 내용을 토대로 팀과 선수 Entity를 만들었다고 생각해보자. 이는 이대로 괜찮을까?

그렇지 않다 왜냐하면 둘의 관계가 정의되어 있지 않다.

객체와 테이블의 불일치를 해소하는 것이 orm이거늘.. 하지만 객체의 세상엔 관계라는 것이 따로 존재하지 않는다. 그로인해 앞으로 알아볼 Entity의 연관관계에는 Table의 관계와는 차이가 있을 수 밖에 없다.

Entity의 연관관계 매핑을 위해서는 3가지의 개념을 생각해봐야 한다.

다중성

다중성이란 테이블이 다른 대상과 얼마다 연결될 수 있는지를 정량적으로 표현한 것 이다.

DB를 기준으로 다중성을 결정한다.

일대일

말 그대로 하나의 객체가 다른 단 하나의 객체와만 연관될 때의 연관관계이다.

ex) 학생과 책상(학생은 각 하나의 책상을 사용한다.)

@Entity
public class Student{

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

    @OneToOne
    private Desk desk;

}

@OneToOne 어노테시션으로 선언한다.

일대다, 다대일

실생활에서도 가장 흔하게 볼 수 있는 연관관계 다중성이다. 하나의 엔터티가 여러 엔터티와 연관될 때 사용한다.

ex) 팀과 선수관계, 반과 학생관계, 게시판과 게시글의 관계 등

@Entity
public class Post{

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

    @ManyToOne
    @JoinColumn(name = "board_id")
    private Board board;

@Entity
public class Board{

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

    @OneToMany(mappedBy = "board")
    private List<Post> posts;

@ManyToOne과 @OneToMany를 사용하여 지정한다.

다대다

다대다 연관관계는 여러 엔터티가 여러 엔터티와 연관되는 관계이다.

ex) 학생과 전공수업

@Entity
public class Student{

    ...

    @ManyToMany
    private List<Class> classes;

@Entity
public class Class{

    ...
    @ManyToMany
    private List<Student> students;

위에서 언급했듯이 다대다 관계는 문제를 일으킬 가능성이 높다.

다대다연관관계가 생성되면 자동으로 중간테이블(외래키만 가지는)이 생기는데 이를 통하는 조인발생 시 예상보다 복잡한 쿼리 때문에 성능의 저하가 일어날 수 있다.

⇒ 다대다를 일대다 혹은 다대일로 풀어서 설계하는 것이 좋겠다.

방향

DB는 관계는 따로 방향이 없다. 데이터베이스 테이블은 외래 키 하나로 양 쪽 테이블 조인이 가능하다.

CREATE TABLE players(
    id bigint primary key not null auto_increment,
    name varchar(20) not null,
    team_id bigint not null ,
    CONSTRAINT fk_team
                    FOREIGN KEY (team_id)
                    REFERENCES teams(id)
                    ON DELETE CASCADE
                    ON UPDATE CASCADE
);

CREATE TABLE teams(
    id bigint primary key not null auto_increment,
    name varchar(20) not null
)

위처럼 teams테이블의 id를 참조하는 player테이블을 생성하면

위와 같은 관계가 생긴다. players가 외래키를 가지고 있지만 DB에서는 양쪽에서 조인이 가능하다.

SELECT 
    p.name AS player_name,
    t.name AS team_name
FROM 
    players p
JOIN 
    teams t ON p.team_id = t.id;

SELECT 
    t.name AS team_name,
    p.name AS player_name
FROM 
    teams t
JOIN 
    players p ON t.id = p.team_id;

객체관계의 방향

그렇다면 Entity객체는 어떨까?

Players이 Team을 가지고 있기에 이제 접근이 가능하다. (플레이어에서 팀으로)

하지만 팀에서 플레이어한테 접근을 할 수가 없다..! DB에서와는 다른 특징을 보인다.

그래서 Team에서도 Players에 접근이 가능하도록 Team에 players를 추가했다.

이제 서로 참조가 가능하다.

이를 양방향 관계라고 하지만 사실 양방향 관계는 단방향 참조를 각각 가지는 것이므로 단방향 두개라고 생각할 수 있다.

연관관계 소유자

위 처럼 양방향 관계에서 어떤 Entity가 외래키를 관리하는지 JPA에게 알려줘야 안헷갈려하지 않겠는가.

이를 위해서 우리는 양방향 연관관계 어떤 연관관계가 외래키를 진짜 가지고있는지를 설정해주어야 한다.

연관관계의 주인만이 두 객체 사이에서 조회, 수정, 삭제가 가능하고 아니라면 조회만 가능하다.

외래키를 가지는(연관관계 소유자)객체에는 @JoinColumn으로 지정하고

연관 관계의 주인이 아닌 객체에 mappedBy속성으로 지정할 수 있다.(Table로 따지면 외래키를 가지지 않는 / 참조당하는 쪽)

⇒ 참고로 단방향일땐 @JoinColumn만 사용하면 된다.

Team과 Players의 관계로 예를 들어보자.

@Entity
public class Players {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "team_id")
    private Teams team;

Players가 다(Many)쪽에 속하므로 Playsers가 외래키를 갖는 것이 적합하여 Players에 @JoinColumn을 붙여주고, Team에는 mappedBy을 사용하여 연관관계 소유자를 지정해주어야 한다.

@Entity
public class Teams {

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

    private String name;

    @OneToMany(mappedBy = "team")
    private List<Players> players;
}

이처럼 mappedBy로 지정할 때 값은 대상이 되는 변수명을 따라 지정한다.

다대다의 연관관계 소유자

다대다 관계에선 자동으로 중간테이블(외래키만 가지는)을 생성한다. 이 중간 테이블의 이름이나 칼럼명을 명시적으로 커스터마이징할 때 @JoinTable을 사용한다. 물론 mappedBy을 통해 주인이 아님을 명시적으로 정의해야한다.

@Entity
public class Student{

    ...

    @ManyToMany
    @JoinTable(
        name = "student_class_table",
        joinColumns = @JoinColumn(name="student_id"), //현재 엔터티의 외래키
        inverseJoinColumns = @JoinColumn(name="class_id") //상대 엔터티의 외래키
    )
    private List<Classes> classes;

    ...

}

다만, 위에서도 언급했듯이 다대다연관관계는 설계적 결함이 있는 경우라고 생각되어진다. 고로 일대다/일대일 구조로 바꾸어 설계하는 것이 성능/유지보수등 여러 방면에서 이로울 것 이다.

영속성 전이 : CASCADE

게시판과 게시글 엔터티가 있을 때, 게시판은 여러개의 게시글을 자식 엔터티로 가지고 있을테다. 이때 만약 게시판을 영속상태로 만들고 싶을때 자식 엔터티인 게시글들도 일일히 영속상태로 만들기 귀찮고 복잡할 수 있다. 이 때 사용할 수 있는 것이 영속성 전이이다.

영속성 전이는 JPA에서 특정 엔터티를 영속상태로 만들때 이와 연관된 엔터티도 함께 영속상태로 만들때 사용한다.

영속성 전이를 적용하면 게시판(부모 엔터티)을 저장하면 게시글(자식 엔터티)도 함께 저장되고, 삭제를 하는 경우에도 같은 방식으로 게시판이 삭제되면 게시글도 삭제 된다.

영속성 전이는 @ManyToOne과 @OneToMany관계에서 cascade속성을 통해 사용한다.

@Entity
public class Boards{

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

    private String title;
    private String description;

    @OneToMany(mappedBy = "board", cascade = CascadeType.ALL)
    private List<Posts> posts;
}

CASCADE의 종류

• CascadeType.ALL : 모든 Cascade 옵션을 적용
• CascadeType.PERSIST : 엔티티를 영속화할 때, 연관된 엔티티도 함께 영속화
• CascadeType.REMOVE : 엔티티를 제거할 때, 연관된 엔티티도 함께 제거
• CascadeType.MERGE : 엔티티 상태를 병합할 때, 연관된 엔티티도 함께 병합
• CascadeType.REFRESH : 부모 엔티티를 Refresh하면, 연관된 엔티티도 함께 Refresh
• CascadeType.DETACH : 부모 엔티티를 Detach하면, 연관된 엔티티도 함께 Detach

대부분의 경우 ALL을 사용하지만, 상황과 목적에 맞게 사용하면 된다.

고아객체

이름부터 폭력적인 이 고아객체는 말 그대로 부모가 버리거나, 부모가 없어진 객체이다.

Board board = em.find(Board .class, 1L);
board.getPosts().remove(0);

위 코드처럼 게시판에서 게시글을 삭제하면 삭제된 게시글은 부모가 없어져 고아객체가 된다. 이때 고아객체 제거 기능이 참이라면 해당 게시글은 게시판에서만 삭제되는 것이아니라 DB에서 삭제된다.

DELETE FROM posts WHERE ID = xxx;

실제로 위와 같은 SQL쿼리가 DB에 적용되며 부모잃은 불쌍한 게시글은 DB에서 삭제되고 만다.

이는 게시판 자체가 삭제되어도 같은 원리로 삭제된 게시판과 연관된 모든 게시글이 삭제된다.(CascadeType.REMOVE와 비슷)

부모 삭제 시 자식 자동 삭제는 orphanRemoval만으로 보장되지 않을 수 있으므로 보통 cascade = REMOVE를 함께 설정한다.

고아객체 제거는 위 설명과 같이 자식 엔터티가 부모 엔터티에 종속되어있을 때 사용된다. 부모로부터 참조가 제거되었다면 유일한 참조를 잃었다고 판단되는 객체가 고아객체이다. 즉 고아객체 제거 기능은 자식엔터티를 참조하는 곳이 하나만 존재할 때 사용할 수 있다.

고아객체 제거 기능은 @OneToOne, @OneToMany관계에서만 사용가능한데 orphanRemoval속성을 true로 주어 활성화한다.(기본값은 false이다)

@Entity
public class Boards{

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

    private String title;
    private String description;

    @OneToMany(mappedBy = "board", cascade = CascadeType.ALL, orphanRemoval= true)
    private List<Posts> posts;
}

참고로 위와 같이 cascade와 orphanRemoval= true를 함께 사용하면 자식 엔터티의 생명주기를 부모 엔터티로 관리가 가능하다. ⇒ 자식엔터티의 생명주기가 부모 엔터티에 의존

1차 프로젝트를 마치고 얼마되지 않아 바로 2차 프로젝트를 시작하게 되었다. 1차완 다르게 2차부터는 직접 주제를 정하고 기획을 했어야 했다. 그렇기에 팀장의 자리는 너무나 부담이 되어 피하고 싶었지만..이런 당첨되고 말았다. 그래도 어찌하리 막중한 책임감을 갖고 열심히 프로젝트를 이끌려고 했다. 그렇게 우리는 주제선정을 위해 시간을 가졌고 내가 구상한 주제와 팀원의 주제의 치열한 경쟁 끝에 데브코스 2차프로젝트로 개발자를 위한 채팅 서비스을 하게 되었다. 솔직히 처음엔 마음에 들지 않았다. 그때 나에겐 채팅이란 다 비슷비슷한 서비스라는 인식이 있었던 것 같다. 나중에 프로젝트 회고에서 다시 한 번 말할 것 같지만, 지금은 너무나 애정이 있는 프로젝트이다.

프로젝트의 목표는 협업중 깃허브에서의 코드리뷰보다 가볍고 쉬운 소통을 도와주는 채팅프로그램이었다.

그렇게 주제선정을 하고 각자 역할분담을 했다. 나의 첫 역할은 회원가입/로그인/마이페이지였다. 즉 유저와 관련한 기능을 맡게되었다. 난 이게 금방 끝날 줄 알았다..인증에 늪에 빠질줄은..

그러던 어느날 우리 팀에겐 큰 시련이 닥쳐왔다. 선정된 주제를 제안하신 팀원의 데브코스 하차 소식.. 개인사정이라고 하셔서 자세히 여쭤보진 않았다. 그건 그렇고 그분이 담당하신 부분은 깃허브 이벤트 알림 기능인 WebHook부분이었다. 우리팀은 일단 WebHook부분은 제쳐두고 채팅방기능을 완성한 뒤에 구현하는 것으로 합의했다. 이것이 나의 첫 팀장으로서의 시련이 아니었나싶다. 지금 생각해보니 이때부터 작업량에 대한 집착이 생긴 것 같기도 하다.

그렇게 우리는 작업을 시작하게 되었고, 나로썬 첫 주도적인 프로젝트의 시작이었다. 아래는 초반 개발을 하면서 마주했던 문제들의 극복과정의 일부 정리했다. 트러블 슈팅은 앞으로 몇개 더 업로드 해볼 생각이다.

참고로 이 프로젝트의 이름은 DevChat이다. 로그인 화면은 디자인하는 과정에서 임시로 작명한거였는데, 의외로 팀원들의 반응이 좋아서 그대로 채택되었다..너무 흔한것 같긴 하다만..

로그인 실패 시 커스텀 예외 처리 문제

문제상황

로그인 시 존재하지 않는 이메일로 접근하면, MemberService에서 커스텀 예외를 던지도록 구현했는데, Spring Security가 이를 인증 실패로 간주하지 않고 전역 예외로 처리했다.

결과적으로 AuthenticationFailureHandler가 호출되지 않고 예외가 앱 전체로 퍼지는 문제가 발생했다.

원인분석

AuthenticationManager는 기본적으로 AuthenticationException을 상속받는 UsernameNotFoundException 같은 인증 관련 예외만 “정상적인 인증 실패”로 처리한다. 그러나 내가 정의한 커스텀 예외 AuthenticationException을 상속받이 않았기에 인증 실패가 아닌 시스템 예외로 간주되어 필터 체인을 벗어났다.

해결방안

MemberService에서 유저를 찾을 수 없는 경우 기존 커스텀 예외가 아닌 UsernameNotFoundException을 던지도록 수정:

.orElseThrow(() -> new UsernameNotFoundException("이메일을 찾을 수 없습니다"));

이로써 Spring Security가 정상적으로 로그인 실패로 인식하고 AuthenticationFailureHandler를 타게 됨.

느낀점

Spring Security의 인증 흐름을 더 깊이 들여다보면, ExceptionTranslationFilter가 AuthenticationException 및 AccessDeniedException만 처리하고, 나머지 예외는 그대로 전파된다는 구조를 가진다. 따라서 커스텀 예외를 만들더라도, 그것이 AuthenticationException을 상속받지 않는다면 해당 필터에서 잡히지 않아 인증 실패 흐름이 아닌 전역 예외 처리 흐름으로 넘어간다는 점을 알게 되었다.

이 전까진 예외의 의도 정도만 생각하고 개발을 해왔다. 그러나 이번 경험을 통해서 예외의 의도뿐 아니라 상속 구조, 그리고 프레임워크 내부의 처리 흐름에 대한 이해의 중요성을 체감하게 되었다.

CORS설정 문제

문제상황

프론트엔드(React)에서 백엔드(Spring Boot)로 API 요청을 보낼 때, 브라우저 콘솔에 CORS 관련 에러가 발생하며 요청이 차단되었다.

분명 요청 URL과 포트도 맞췄고, 서버도 정상적으로 동작 중이었는데, 클라이언트 쪽에서 아예 응답 자체를 받지 못하는 상황이었다.

원인분석

Spring에서는 CORS 문제가 일어날 수 있는 곳은MVC단과 Security단이다.

• 인증/인가가 필요 없는 요청은 DispatcherServlet을 통해 MVC에의해 처리되고,
• 인증/인가가 필요한 요청은 Spring Security 필터 체인을 먼저 거치게 된다.

문제는 브라우저의 Preflight 요청(OPTIONS 메서드) 때문이다. 이 요청은 실제 요청 전에 브라우저가 서버의 CORS 정책을 확인하기 위해 보내는 것으로, Security를 거져야하는 요청이면 Security가 응답을 한다. 이때 WebMvcConfigurer에만 CORS 설정을 해둔 상태였기 때문에, 브라우저가 CORS 에러를 발생시킨 것이다.

즉, CORS 설정을 WebMvc 단에만 한 것은 MVC에서만 유효하고, Security를 통과하는 요청에는 전혀 영향을 주지 못한다는 것을 놓쳤던 것이 문제의 본질이었다.

해결방안

SecurityFilterChain 내부에 다음과 같이 cors() 설정을 추가해 Spring Security가 CORS 요청을 허용하도록 수정했다:

http.cors(Customizer.withDefaults());

그리고 별도로 작성한 WebConfig 클래스에서 다음과 같이 CORS 정책을 명시적으로 설정하여 클라이언트에서의 요청을 허용했다:

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:3000")
                .allowedMethods("*")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

이 두 설정이 함께 작동하면서 정상적으로 요청이 허용되었고, 클라이언트도 응답을 받을 수 있게 되었다.

느낀 점

이 문제를 통해 웹의 요청/응답 흐름이 생각보다 더 복잡한 구조와 메커니즘을 가지고 있다는 것을 알게 되었다. 특히 Spring에서는 요청이 Security와 MVC 두 레이어로 나뉘어 처리되고, 같은 설정(CORS)이라도 어느 레이어에서 적용되는지가 중요하다는 점을 명확히 느낄 수 있었다. 이번 경험을 계기로 웹 통신 구조나 브라우저의 동작 방식(Preflight 요청 등)에 대한 이해를 더 깊게 할 필요성을 느꼈다. 단순히 문제가 발생했을 때 설정만 고치는 것이 아니라, 그 이유와 내부 흐름까지 이해하는 자세가 중요하다는 것을 다시 한번 깨닫게 되었다.

사용자 정보 수정이 반영되지 않는 문제

문제상황

사용자 정보(예: 닉네임, 프로필 이미지 등)를 수정한 뒤에도, 프론트엔드에서 호출하는 "내 정보 조회 API" 응답 값이 여전히 수정 전 데이터를 반환했다.

원인분석

회원정보를 조회하는 API의 메소드는 아래와 같았는데

public MemberResponse getMemberDetails(Authentication auth) {
    MemberDetails member = (MemberDetails) auth.getPrincipal();
    return MemberDetails.toResponse(member);
}

Spring Security는 로그인 시 UserDetails 객체를 기반으로 Authentication을 생성하고, 이 객체를 SecurityContext에 저장하여 세션 단위로 인증 상태를 유지한다.

이 구조에서는 로그인 당시 생성된 MemberDetails 인스턴스가 Authentication.getPrincipal()에 그대로 담겨 있으며, 이후 사용자 정보가 DB에서 변경되더라도 기존 세션의 인증 객체는 자동으로 갱신되지 않는다. 그러므로 DM의 데이터를 수정했어도 인증객체는 로그인시의 유저정보를 여전히 담고 있어, 수정된 유저정보를 조회할 수 없었던 것 이다.

해결방안

이 문제를 해결하기 위해 생각한 방법은 크게 두 가지다:

- 방법 1. Authentication 객체를 직접 갱신

사용자 정보 수정 이후, 새로 생성한 MemberDetails로 인증 객체를 재구성하여 SecurityContext에 다시 설정하는 방식:

SecurityContextHolder.getContext().setAuthentication(newAuth);

이 방법이 세션 내 인증 정보와 사용자 정보가 항상 일치시키기에 깔끔하고, 성능에도 조금은 유리할 것 같았지만, 인증객체를 생성하는 로직을 따로 구성해야 하고 재인증 처리도 번거로울 수 있어서 이 방법은 선택하지 않았다.

- 방법 2. 요청마다 DB에서 사용자 정보를 다시 조회

Authentication.getPrincial()에서 사용자 ID만 추출한 뒤, DB에서 최신 사용자 정보를 조회해서 응답에 반영

    public MemberResponse getMemberDetails(Authentication auth) {
        MemberDetails loginMember = (MemberDetails) auth.getPrincipal();
        Long memberId = loginMember.getId();

        Member member = getMemberById(memberId);
        return MemberMapper.toResponse(member);
    }

나는 이 방식으로 구현했다. 인증 객체는 인증 상태 유지를 위해 그대로 두고, 실제 응답에 필요한 사용자 정보는 항상 최신 상태 기준으로 처리할 수 있도록 했다.

인증 객체를 직접 갱신하는 방법도 고려했지만, 구조가 복잡해지고 로직이 불필요하게 늘어나는 점이 부담스러웠다. 반면, DB에서 사용자 정보를 다시 조회하는 방식은 단순하고 변경된 내용을 바로 반영할 수 있어 더 명확하게 느껴졌다. 특히 닉네임이나 프로필처럼 보안과 직접 관련 없는 정보라면 굳이 인증 객체까지 건드릴 필요는 없다고 판단했다.

물론, 인가 정보가 DB에 존재하고 그 정보가 변경될 수 있었다면, 인증 객체와 DB 상태 간의 불일치로 인해 인가 로직에 문제가 생겼을 수도 있다. 하지만 당시에는 별도의 인가 시스템이 없는 상태였기 때문에, 이렇게 간단하게 해결하는 방식이 더 적절하다고 판단했다.

추가적인 성능 이슈에 대해서는, 향후 캐싱 등을 통해 충분히 개선할 수 있다고 보았고, 현재 서비스 구조와 요구 수준에서는 이 방식이 가장 깔끔하고 안전한 선택이라고 생각했다.

느낀점

이 문제를 마주하기 전까지 나는 Authentication 객체를 단순히 Spring Security가 사용하는 유저 정보 정도로만 생각하고 있었다. 하지만 실제로는 이 객체가 로그인 시점의 사용자 상태를 유지하는 일종의 스냅샷이라는 사실을 알게 되었다. 이러한 구조를 제대로 이해하지 못한 채, 사용자 정보를 수정하면 자동으로 Authentication 객체에도 반영될 것이라고 단순하게 생각했고, 변경 사항이 반영되지 않아 한참을 헤맸다.결국 내가 생각 없이 사용해오던 Spring Security의 구조, 특히 Authentication 객체의 역할과 동작 방식에 대해 처음부터 다시 이해하게 되었고, 그동안 기능 위주로만 개발해왔던 내 태도에 대해서도 반성하게 되었다. 이 경험을 통해 단순히 "작동한다"는 수준을 넘어서, Spring Security가 내부적으로 어떻게 인증 상태를 유지하고 처리하는지, 그 원리를 정확히 이해하는 것이 얼마나 중요한지 깊이 느낄 수 있었다.

MyBatis란

JDBC에서 SQL의 결과를 우리가 가지고 있는 Java객체에 매핑하려면 ResultSet을 불러와서 값을 직접 객체에 설정해주어야 한다. 즉 무지 귀찮다.

이를 쉽게 해주는 것이 MyBatis이다. MyBatis는 Java객체와 SQL데이터베이스 사이의 매핑을 쉽게 해주는 SQL 매퍼 프레임워크이다. 주의해야 할 건 이후 MyBatis는 완전한 ORM이 아니다.

MyBatis는 직접 작성한 SQL을 통한 결과를 XML이나 Annotation을 통해 수동으로 매핑하는 도구다.

이러한 이유로 MyBatis는 완전한 ORM이 아니다.(수동으로 매핑하므로)

혹자는 MyBatis가 구닥다리 프레임워크라고 할 수 있지만, 상황에 따라 다르다고 볼 수 있다.

특히 SQL 최적화나 복잡한 쿼리 작성이 중요하다면 JPA보다 좋은 선택이 될 수 있다.

Spring Boot + MyBatis 통합 설정 (Application YAML 설정)

이는 사실 Spring Boot에서 제공하는 설정인데 우리는 spring boot로 웹 개발할거니 적극 사용하도록 하자.

application.yml파일을 통해 여러 편리한 설정을 할 수 있는데 대충 아래와 같이 생겼다.

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mybatis
    username: dev_bae
    password:

mybatis:
  type-aliases-package: io.moon.mybatistest.entity
  configuration:
    map-underscore-to-camel-case: true
  mapper-locations: classpath:mappers/*.xml

spring.datasource 부분으로 연결정보를 입력하여 자동으로 DB에 접속할 수 있다. JDBC에 비해 아주 깔끔 간단한 모습

mybatis에 여러 설정을 걸 수 있는데

• type-aliases-package: XML에서 저 패키지 안의 클래스들은 간단한 이름으로 참조가 가능하다.(패키지명을 줄줄히 안 써도 된다.)
• configuration.map-underscore-to-camel-cas : SQL결과의 칼럼명이 스네이크케이스(item_id)일 경우 자바객체의 카멜케이스(itemId)로 자동 매핑해준다.
• mapper-location : 우리가 작성할 XML기반 매퍼파일(SQL이 작성되는 XML파일)의 위치를 지정한다. classpath: 는 resources/폴더를 기준으로 탐색한다.

Mapper인터페이스

MyBatis에서 mapper.xml에 작성한 SQL 쿼리를 수행하려면, 이를 호출할 메소드를 인터페이스에 정의해두어야 한다.

이때 mapper.xml의 <select>, <insert> 등 태그의 id는 해당 인터페이스의 메소드 이름과 정확히 일치해야 한다.

이 Mapper 인터페이스는 @Mapper 어노테이션을 사용하여 선언할 수 있으며,

해당 어노테이션이 붙은 인터페이스에 대해 MyBatis가 프록시 기반의 구현체를 자동 생성한다.

생성된 구현체는 Spring에서 스프링 빈으로 등록되어 의존성 주입 등을 통해 사용할 수 있다.

🤔 프록시 구현체가 뭐임?

프록시는 자주 듣지않음? 대리인 역할을 하는 객체라고 생각하면 됌. 님 자바에서 인터페이스만 있는데 이걸 구현도 안하고 사용할 줄 앎? 그럼 나도 알려주셈. 안되는거임. 그래서 MyBatis가 @Mapper가 사용된 인터페이스를 찾아서 프록시 구현체를 지가 만들어 주는 거임. 이 프록시 구현체는 인터페이스의 메소드가 호출되면 인터페이스 대신 해당 메소드를 실행함. 내부적으로 java.lang.reflect.Proxy 또는 CGLIB 같은 기술을 사용해 이 객체를 생성함. 이건 나도 잘 몰라서 추후에 정리할 예정임.

@Mapper
public interface ItemMapper {

    void save(Item item);
    int updatePrice(@Param("itemCode") String itemCode, @Param("price") Integer price);
    Optional<Item> findByItemCode(@Param("itemCode") String itemCode);
}

뭐 이렇게 생겼는데. @Param 은 예를들어 @Param("itemCode")라면 XML파일의 #{itemCode}부분과 매핑될 매개변수를 지정한다.

매개변수가 하나라면 @Param이 없어도 혼동이 없겠지만 두 개 이상이 바인딩되야 한다면 @Param으로 적확하게 이름을 알려주어야한다. 바인딩이란 어떤 변수나 매개변수에 실제 값을 연결(할당)하는 것을 말한다.

XML Mapper

MyBatis에서 SQL매핑의 방식은 어노테이션 매핑방법과 XML기반 매핑방법이 있다. 이글에선 XML기반 매핑만 다루어보겠다.

JDBC에서는 쿼리를 DB에게 날리려면 연결을 따와서 Statement를 가져와서 이를 실행시켜야 했지만 MyBatis에서는 XML에 SQL만 매핑시켜놓고 이를 실행시킬 메소드를 인터페이스에 정의해놓기만하면 해당 쿼리를 DB에 실행시킬 수 있다.

참 편하다.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="io.moon.mybatistest.mybatis.ItemMapper">

    <insert id="save" useGeneratedKeys="true" keyProperty="id">
        INSERT INTO items
            (name, code, price)
        VALUES
            (#{name}, #{itemCode}, #{price})
    </insert>

    <update id="updatePrice">
        UPDATE
            items
        SET
            price = #{price}
        WHERE
            code = #{itemCode}
    </update>

    <select id="findByItemCode" resultType="Item">
        SELECT
        --  자바객체의 필드이름을 기준으로 결과를 가져와야한다. as를 통해 이를 수행. 
            i.item_id as id,
            i.name,
            i.code as itemCode,
            i.price,
            i.created_at as createdAt
        FROM
            items i
        WHERE
            i.code = #{itemCode}
    </select>
</mapper>

저 위 세줄은 그냥 어디선가 가져오길 바란다.

mapper태그 안에 매핑될 SQL을 작성하는 방식이고 이 안의 namespace로 작성한 SQL을 실행할 메소드가 정의되어있는 인터페이스의 경로를 입력한다.

mapper태그 안에 작성할 SQL문에 따라 지정하고(INSERT,UPDATE,SELECT,DELETE) id에는 자바메소드 이름을 적으면 된다. resultType은 반환타입을 정해준다.

useGeneratedKeys은 DB에서 자동 생성된 키(ex. AUTO_INCREMENT)를 자바 객체에 넣어주려면 true로 입력하고,

keyProperty는 이 키값를 자바객체의 어느 필드에 저장할지를 지정한다.

추가로 주의해야할 부분은 SELECT시 DB의 칼럼명과 자바객체의 필드명이 상이하게 다를때(단, 스케이크케이스에서 카멜케이스는 설정하면 자동으로 매핑)

이를 DB에서 가져올때 AS를 통해 객체 필드명과 동일하게 가져와야한다.

MyBatis 실습

위의 개념들을 총동원해서 간단한 예제를 실습해보자.

Product테이블은 id, name, category, price 칼럼을 가진다. 이를 가격 범위로 검색하는 실습을 해보겠다.

우선 DB에 products테이블을 생성하자

create table products(
    id int auto_increment primary key,
    name varchar(50) not null,
    category varchar(100) not null,
    price int not null
);

Products Entity클래스를 만들자

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Products {
    private int id;
    private String name;
    private String category;
    private int price;

    public Products(String name, String category, int price) {
        this.name = name;
        this.category = category;
        this.price = price;
    }

    @Override
    public String toString() {
        return "Products{" +
                "id=" + id +
                ", name='" + name + '\'' +
                ", category='" + category + '\'' +
                ", price=" + price +
                '}';
    }
}

본인 이 Entity클래스에 생성자를 만들지 않아 수많은 에러를 맛봐야했음..
MyBatis는 생성자와 Setter를 기반으로 SELECT의 결과를 객체로 만들기 때문에 생성자가 있어야함..

Mapper인터페이스도 만들자

@Mapper
public interface ProductsMapper {
    void saveProducts(Products products);

    List<Products> searchProductsByPriceRange(
            @Param("category") String category,
            @Param("min") int min,
            @Param("max") int max
    );
}

이제 저 @Param에 입력된 값을 잘 기억해서 xml파일도 구성하자.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="io.moon.mybatistest.mybatis.ProductsMapper">

    <insert id="saveProducts" useGeneratedKeys="true" keyProperty="id">
        INSERT INTO products
            (name, category, price)
        VALUES
            (#{name}, #{category}, #{price})
    </insert>

    <select id="searchProductsByPriceRange" resultType="Products">

        SELECT * FROM products
        WHERE category = #{category}
          AND price BETWEEN #{min} AND #{max}

    </select>

</mapper>

반환타입이 List<Products>로 설정되어있고(인터페이스) xml의 resultType이 Products이므로 MyBatis가 결과값을 List에 넣어준다.

즉 각 행이 Products의 객체로 매핑된다.

이제 검색을 하면 되겠지만 테이블에 검색할 데이터가 없다. 이를 간단히 채울 수 있는 메소드를 만들어봤다.

@Component
public class ProductsUtil {

    @Autowired
    private ProductsMapper productsMapper;

    public ProductsUtil(ProductsMapper productsMapper) {
        this.productsMapper = productsMapper;
    }

    ArrayList<Products> productsList = new ArrayList<>();
    List<String> categories = List.of("Food", "Beverage", "Snack");
    public List<Products> genProducts(int quantity) {

        for (int i = 0; i < quantity; i++) {
            String name = "product" + i;
            Products products = new Products(name, categories.get(i%3), (int) (Math.random() * 10000));
            productsMapper.saveProducts(products);
            productsList.add(products);
        }

        return productsList;
    }
}

Food, Beverage, Snack카테고리를 가진 랜덤한 가격을가진 값들을 테이블에 INSERT하는 역할이다.

잘 작동하는 모습

마지막으로 카테고리별 금액 범위 검색을 해보면

    @Test
    @DisplayName("searchProducts")
    void searchProducts() throws Exception {

        List<Products> results = mapper.searchProductsByPriceRange("Food",2000,6000);
        for (Products products : results) {
            log.info("products = {}", products);
        }
    }

아주 잘 작동한다.

이처럼 MyBatis는 비교적 복잡한 쿼리가 많다면 JPA보다 좋은 선택이 될 수도? 있다.

데이터를 DB에 보관하여 오랫동안 저장되게 하는 것을 영속성(Persistence)라고 한다.

이는 앞으로 자주 등장할 단어이다. 좀 더 심오한 뜻이 있을 것도 같지만 영속성은 데이터가 휘발되게 하지 않고, 오랫동안 존재하도록 하는 것 이라고 이해하면 될 것이다.

그렇다면 우리는 데이터의 영속성을 위해 우리의 어플리케이션에 DB를 연결시켜주어야한다!

만약 당신이 Oracle을 연결해서 사용하고 있다고 가정해보자 근데 세상에 주식이 떨어져서 OracleDB를 지속할 돈이 부족하다. 그래서 당신은 MySQL로 DB를 바꾸려한다.

이런 이런 세상에 너무나 번거롭다. 연결에 관한 모든 것을 당신은 바꿔야한다. 앞으로 또 이런 일이 있을 때 당신은 이짓을 또하고 싶진 않을테다.

이를 위해 JAVA생태계에선 JPA를 사용한다. JPA를 제대로 이해하기 위한 개념, 기술들을 몇개의 글로 나누어 정리할 생각이다. 이번 글은 이해를 위한 몇가지 개념들과 JDBC에대해서 알아보겠다.

데이터베이스 커넥터

소프트웨어의 데이터를 보관하려면 DB와 연결 및 통신을 할 수 있어야 한다. 이를 가능케하는 것이 데이터베이스 커넥터이다.

데이터베이스 커넥터는 어플리케이션에서 작성한 SQL쿼리를 DB로 전달함으로써 데이터를 저장 및 관리하게 해준다.

데이터베이스 커넥터는 크게 두가지 요소로 구성되는데 드라이버(Driver)와 클라이언트 라이브러리(Client Library)이다.

드라이버(Driver)

드라이버는 DB와 실제로 통신하며, SQL문을 전송하고 결과를 받아오는 역할이다. 각 DB마다 통신규약이 다르기 때문에 DB마다 다른 드라이버를 사용한다.

클라이언트 라이브러리(Client Library)

드라이버는 저수준에서 DB와 연결되어 통신하기 때문에 개발자가 이를 직접 이를 다루기엔 복잡하다.

클라이언트 라이브러리는 이를 추상화하여 개발자가 쉽게 DB와 상호작용할 수 있게하는 고수준 API를 제공한다. 즉, 클라이언트 라이브러리는 드라이버를 추상화한 계층이다.

우리는 이를 이용해서 쉽게 DB와 연결할 수 있다.

그런데 보통 어플리케이션 특히 웹에서는 수많은 요청으로 인해 데이터가 수시로 바뀐다. 그렇다면 우리는 이 DB와의 연결을 어떻게 관리해야 좋을까?

1. 계속 연결을 지속한다
2. 데이터가 필요할 때마다 연결을 하고 작업이 끝나면 연결을 끊는다.

둘 다 뭔가 낭비가 심해보인다. 그렇다면 어떻게 하면 효율적으로 연결(Connection)을 관리할 수 있을까.

바로 커넥션 풀링(Connection Pooling)을 사용하는 것 이다.

커넥션 풀링(Connection Pooling)

Pool이 무엇인가. 수영장, 연못… 무언가 담겨있는 것정도로 이해가 되지 않는가?

우리는 약수터를 생각해보자. 어르신들이 약수터에 물마실라고 바가지를 들고다니는가? 바가지는 약수터에 둥둥 떠 있고, 약숫물이 필요할때만 사용하고 다시 띄어놓는다.

그렇다 커넥션 풀링도 비슷하다.

즉, 연결들을 미리 생성해두고 연결이 필요할 때마다 이를 할당해서 사용 후 반환하여 재사용이 가능케 하는 방식이다.

이 방식은 연결 생성 및 폐기에 따른 메모리 손해(오버헤드)를 줄여주고, 만약 폭발적인 연결수가 필요한 상황에서 모든 연결을 생성하면 자원고갈이 일어 날 수 있지만 커넥션 풀링은 그냥 좀 기다리면 된다. (콘서트 예매 대기열이 바로 이런 상황이다.)

JDBC(Java Database Connectivity)

글 시작에서 제시한 상황이 기억나는가.

어플리케이션에 이미 연결한 DB를 다른 DB로 바꿔야하는데, DB들은 접속방식과 SQL문법이 각자 다르다. 너무 피곤한 작업일 것 이다.

이를 극복할 수 있도록 하는 것이 JDBC이다.

JDBC는 다양한 DB들과의 연결을 일관된 방식으로 처리할 수 있는 표준 인터페이스(API)를 제공한다.

위에서 설병한 클라이언트 라이브러리 자바판이라고 생각해도 될 것 같다.

JDBC는 각 DBMS에 맞는 JDBC드라이버를 통해 DB와 연결하기 때문에 DB를 바꿔야 한다면 이 JDBC드라이버만 갈아끼우면 된다. 이러한 특성은 여러 DB을 동시에 연결하여 사용할 수 있게도 한다.

아니; 그럼 연결방식은 드라이버를 바꾸면 된다쳐도 SQL은 어떻게 바뀌어 적용되는거임?

니 말이 맞음. 못바꿈. SQL이 다 비슷비슷해서 운좋으면 그냥 써도 되는 SQL문이 있을 수 있겠지만 다른게 있으면 님이 바꿔야함;; 그래서 JPA가 있는거임 기다리셈

JDBC실습

JPA모른다고 DB연결 못하는 거 아니다. 추후에 불편한 상황이 생길 수 있지만 JDBC만으로도 충분히 DB와 통신하여 데이터를 관리할 수 있다. 이번엔 JDBC를 사용해서 앞선 개념들을 코드로 확인해보자.

@Slf4j
public class JdbcConnection {
        //연결 정보를 상수로 저장해 놓는다.
    public static class MysqlDbConnectionConstant {
        public static final String URL = "jdbc:mysql://localhost:3306/jdbc_exam";
        public static final String USERNAME = "dev_bae";
        public static final String PASSWORD = "mypassword";
    }

    public static Connection getConnection() throws SQLException {
            //DriverManager로 Connection객체를 생성 후 연결한다.
        Connection conn = DriverManager.getConnection(
                MysqlDbConnectionConstant.URL,
                MysqlDbConnectionConstant.USERNAME,
                MysqlDbConnectionConstant.PASSWORD
        );
        log.info("Connection = {}", conn);
        return conn;
    }
}

@Data
@RequiredArgsConstructor
@AllArgsConstructor
public class Member {
    private int id;
    private String username;
    private String password;
}

@Slf4j
public class JdbcExample {

    @Test
    @DisplayName("JDBC Insert")
    void insert() throws Exception {

                // 새로운 Member객체를 생성한다. 이 정보가 DB에 들어가게 된다.
        Member member1 = getMember("bae","very_hard_password");
        Member member2 = getMember("admin","super_password");

                // DB에 전송할 SQL문을 작성한다. 따로 메소드로 빼서 사용하면 더 편하다.
        String sql = "INSERT INTO users (username, password) values ('%s', '%s')"
                .formatted(member1.getUsername(), member1.getPassword());

        String sql2 = "INSERT INTO users (username, password) values ('%s', '%s')"
                .formatted(member2.getUsername(), member2.getPassword());

                //Connection객체를 생성, DB와 연결한다.
        Connection conn = JdbcConnection.getConnection();

        //Statement: SQL을 실제로 실행하는 객체이다
        //사실 이는 보안상 이슈가 있다. 이는 아래에서 다루도록 하겠다.
        Statement stmt = conn.createStatement();

                //exeuteUpdate를 통해 SQL을 실행한다. exeuteUpdate는 변경된 row수가 반환된다.
        int rowsAffected = stmt.executeUpdate(sql);
        log.info("rowsAffected = {}", rowsAffected);

        int rowsAffected2 = stmt.executeUpdate(sql2);
        log.info("rowsAffected2 = {}", rowsAffected2);

    }

    private static Member getMember(String username, String password) {
        return new Member(0,username,password);
    }
}

설레는 마음으로 실행시켜보면

log와 함께 정상적으로 실행된다.

DB에도 제대로 INSERT된 걸 확인할 수 있다.

Statement는 위험하다 : SQL Injection

사실 Statement 아주 위험한 취약점을 가지고 있다. 바로 SQL Injection에 아주 무기력하다.

Statement는 입력값을 직접 SQL에 삽입하기 때문인데 코드로 보는 것이 이해가 빠를 것이다.

@Test
    @DisplayName("SQL Injection")
    void injectTest() throws Exception {

        Member hacker = getMember("admin","' or '' = '");
        String sql = "SELECT * FROM users WHERE username = '%s' AND password = '%s'".
                formatted(hacker.getUsername(), hacker.getPassword());

        Connection conn = JdbcConnection.getConnection();
        Statement stmt = conn.createStatement();
        ResultSet rs = stmt.executeQuery(sql);
        while (rs.next()) {
            log.info("rs.getString(username) = {}", rs.getString("username"));
            log.info("rs.getString(password) = {}", rs.getString("password"));
        }
    }
}

위 코드의 결과를 예상해보자.

username에는 admin이 입력되었고 password에는 이상한 문자열이 삽입되있다. 상식적으로 아무런 결과값을 반환하면 안된다.

어머나 세상에 테이블에 존재하는 모든 계정 정보가 반환되었다.

왜 이런 일이 생기는 걸까? 위의 입력값을 삽입한 SQL문을 보자.

SELECT * FROM users WHERE username = 'admin' AND password = '' or '' = ''

SQL에서 AND 보다 OR의 우선순위가 낮음을 인지하고 이를 보기 좋게 변형하면

( (username = 'admin' AND password = '') OR ('' = '') )

이렇게 된다. 이러면 앞의 AND문이 거짓이라도 위의 '' = '' 가 무조건 참이기에 이 SQL문은 테이블의 모든 행을 가져와 버린다.

정보보안학을 전공한 나로써 용서가 되지 않는다. 이를 어떻게 해결할 수 있을까?

바로 PreparedStatement 을 사용하는 것 이다.

PreparedStatement

PreparedStatement 는 입력값을 자동으로 이스케이프 처리해주기 때문에 SQL Injection을 방어할 수 있다.

PreparedStatement 은 SQL문안에 ?을 삽입하여 파라미터를 설정할 수 있다.

"SELECT * FROM users WHERE username = ? AND password = ?";

?에 값을 집어넣으려면 setString() 등을 사용한다.

두개의 매개변수를 갖는데 첫번째 매개변수는 ?의 위치 (1부터 시작)

두번째 배개변수에는 집어넣을 값을 넣는다.

@Test
    @DisplayName("PreparedStatement")
    void preparedStmt() throws Exception {

        Member hacker = getMember("admin","' or '' = '");
        String sql = "SELECT * FROM users WHERE username = ? AND password = ?";

        Connection conn = JdbcConnection.getConnection();
        PreparedStatement pstmt = conn.prepareStatement(sql);

        pstmt.setString(1, hacker.getUsername());
        pstmt.setString(2, hacker.getPassword());

        ResultSet rs = pstmt.executeQuery();

        if (rs.next()) {
            log.info("rs.getString(username) = {}", rs.getString("username"));
            log.info("rs.getString(password) = {}", rs.getString("password"));
        }else{
            log.info("rs.getString(username) = null");
        }
    }

아까와 달리 아무런 값을 불러오지 못한다.

위와 같이 SQL Injection방지하고, 심지어 성능도 좋으니(쿼리캐시) 무조건 prepareStatement을 사용하는 걸 많이들 추천한다.

Connection Pooling(HikariDataSource)

위와 같이 연결이 필요할때 연결을 생성하고 폐기하는 식은 비효율적이므로 Connection Pooling을 사용한다고 위에서 설명했다. 이번엔 이를 어떻게 사용하는지를 코드로 알아보자

  @Test
  @DisplayName("히카리풀에서 멀티쓰레드가 연결 요청하는 테스트")
  void hikari_multiThread() throws Exception {

      //히카리데이터소스 생성
      HikariDataSource hikari = new HikariDataSource();
      //커넥션풀의 최대 커넥션 수 설정
      hikari.setMaximumPoolSize(2);

      //접속 정보 설정
      hikari.setJdbcUrl(JdbcConnection.MysqlDbConnectionConstant.URL);
      hikari.setUsername(JdbcConnection.MysqlDbConnectionConstant.USERNAME);
      hikari.setPassword(JdbcConnection.MysqlDbConnectionConstant.PASSWORD);

      String sql = "insert into users (username, password) values(?,?)";

      //각 쓰레드가 실행할 함수 - 히카리풀에서 커넥션을 불러오고 로그, SQL실행 후 반납 로그
      BiConsumer<String, String> multiConn = (user, password) -> {
          try{
              Connection conn = hikari.getConnection();
              PreparedStatement ps = conn.prepareStatement(sql);
              log.info("{} conn 획득 = {}", Thread.currentThread().getName(), conn);

              ps.setString(1, user);
              ps.setString(2, password);

              ps.executeUpdate();

              Thread.sleep(3000);

              ps.close();
              conn.close();
              log.info("{} conn 반환 = {}", Thread.currentThread().getName(), conn);

          } catch (Exception e) {
              throw new RuntimeException(e);
          }

      };

      Thread thread1 = new Thread(() -> multiConn.accept("test1", "test1_password"),"Thread-1");
      Thread thread2 = new Thread(() -> multiConn.accept("test2", "test2_password"),"Thread-2");
      Thread thread3 = new Thread(() -> multiConn.accept("test3", "test3_password"),"Thread-3");

      thread1.start();
      thread2.start();
      thread3.start();

      //로그 확인을 위해 스레드 종료를 기다림..
      thread1.join();
      thread2.join();
      thread3.join();
  }

HikariDataSource은 HikariCP라는 커넥션 풀을 사용하는 객체이다.

이를 이용해 커넥션을 생성해놓고 커넥션이 필요할 때마다 꺼내 사용하고 작업이 끝나면 이를 커넥션풀에 다시 반납한다.

위 코드는 최대 2개의 커넥션을 가지게 설정되었고, 이를 3개의 쓰레드로 동시에 사용해보면 아래와 같은 로그를 확인 할 수 있다.

로그의 com.mysql.cj.jdbc.ConnectionImpl@1f9f798c 부분을 보면 쓰레드2가 46db63cf연결을 반환한 뒤 쓰레드 3이 같은 46db63cf을 재사용하는 것을 확인 할 수 있다.

HikariProxyConnection은 다 다른데? 이건 뭐임?

HikariProxyConnection은 연결 즉 ConnectionImpl을 감싸는 프록시임. 님이 dataSource.getConnection()하면 HikariProxyConnection이게 반환되는 거임. 근데 이 프록시커넥션은 요청마다 새롭게 생성됨. 그래서 저 로그에서 프록시는 다 다른객체임. 사실 close를 하는데 끊어지는게 아니고 반납한다는게 이상하지 않음?? 사실은 너가 연결을 컨트롤하는게아니고 저 프록시가 해줌. 임마는 너가 close() 를 하면 는 커넥션을 끊는게 아니고 커넥션 풀로 다시 반환하는걸 하는게 이 녀석임. 그 외에도 너가 이미 닫힌 커넥션을 사용하는 폐급짓을 막아주고 커넥션 사용 시간을 측정, 어떤 스레드가 어떤 커넥션을 얼마나 썼는지 등을 하는 아주 휼룡한 커넥션의 비서임.

getGeneratedKeys / ResultSet

이번엔 getGeneratedKeys과 ResultSet을 코드로 간단하게 알아보겠다.

DB와 연결해서 테이블의 로우를 새로 INSERT했다고 생각해보자. 근데 테이블의 id에 auto_increment이 설정되어있다면 이 id값을 어떻게 가져 올 수 있을까?

이때 사용가능한 것이 getGeneratedKeys 이다.

• getGeneratedKeys

    @Test
    @DisplayName("getGeneratedKeysTest")
    void getGeneratedKeysTest() throws Exception {
        String spl = "INSERT INTO users (username, password) values(?,?)";
  
        try(
            Connection connection = hikari.getConnection();
            //getGeneratedKeys을 사용하려면 ****Statement.RETURN_GENERATED_KEYS을 입력해야 한다.
            PreparedStatement pstmt = 
                            connection.prepareStatement(spl, Statement.RETURN_GENERATED_KEYS)){
  
            pstmt.setString(1,"ilikeJDBC");
            pstmt.setString(2,"imaLiar");
  
                    //executeUpdate는 SQL이 반영된 row수만 반환한다.
            pstmt.executeUpdate();
  
                    //getGeneratedKeys를 통해 마지막 id값을 가져온다.
            ResultSet rs = pstmt.getGeneratedKeys();
  
            while (rs.next()){
                    //DB가 생성한 키 값만 담은 ResultSet리턴하므로 칼럼인덱스를 이용해 꺼낸다.
                int findByColIdx = rs.getInt(1);
                log.info("findByColIdx = {}", findByColIdx);
            }
  
        }catch(SQLException e){
            throw new RuntimeException(e);
        }

왜 rs.getInt("id")는 안됨?

JDBC의 getGeneratedKeys()에 “DB가 생성한 키 값만” 담은 ResultSet을 리턴함. 즉 칼럼명이 없는 표를 주면 어떻게 접근할꺼임? 인덱스로 접근할 수밖에 없음.

ResultSet은 쿼리 실행 후 반환된 결과 행(Row)들을 저장한다. next()을 통해 다음 행으로 이동한다.

• ResultSet

    @Test
    @DisplayName("ResultSetTest")
    void resultSetTest() throws Exception {
        String spl = "SELECT * FROM users";
        try(
              Connection connection = hikari.getConnection();
              PreparedStatement pstmt = 
                              connection.prepareStatement(spl, Statement.RETURN_GENERATED_KEYS)){
  
                    //실행 결과를 표형식으로 가져온다.
            ResultSet resultSet = pstmt.executeQuery();
  
                    //next로 행이동, 행이없으면 false를 반환한다.
            while (resultSet.next()){
                String id = resultSet.getString("id");
                String username = resultSet.getString("username");
  
                log.info("id = {}", id);
                log.info("username = {}", username);
            }
  
        }catch(SQLException e){
            throw new RuntimeException(e);
        }
  
    }
  

근데 왜 아까부터 close()안함 폐급임?

try-with-resources임. 예외가 발생하든 안하든 사용한 자원을 자동으로 닫아줌. 처음봐서 한번 써봤음.

트랜잭션

그대는 트랜잭션을 아는가. 대충 안다고 생각하고 설명하겠다. 트랜잭션에는 원자성이라는 특징이 존재한다.

원자성이랑 한 트랜젝션을 수행하면 이는 실행이 완전히 되거나 아예 실행이 안되야한다는 걸 뜻한다.

void logic() {
        int result = repository.a(request);
        repository.b(result);
    }

대충 이런 로직이 서비스단에 있다고 생각해보자 이 로직은 하나의 트랜잭션으로 묶어야한다.

그런데 a()만 성공하고 b()늘 실패한다면 a()결과만 반영되고 b()의 결과는 반영되지 못한다.

트랜잭션의 원자성을 맞족하지 못하게 된다.

그러므로 중간에 예외가 발생하면 logic의 모든 로직을 롤백해야한다.

그런데 repository에서 각 함수를 다른 Connection으로 수행하면 이를 만족하기 어렵다.

즉 하나의 로직에서는 하나의 Connection이 사용되어야 트랜잭션의 원자성을 만족할 수 있다.

지금까지는 dataSource.getConnection();이런식으로 커넥션을 꺼내왔으므로 작업마다 다른 커넥션이 사용됐다. 그렇다면 어떻게 하면 좋을까

이를 순수 JDBC로 해결하려면 DataSource단위로 오토커밋을 끄고(dataSource.setAutoCommit(false); : 이것도 hikari만 된다.)

모든 작업이 끝나면 commit하는 방법이 있을 거 같다.. 하지만 우리에겐 스프링이 있다.

스프링이 제공하는 DataSourceUtils과 PlatformTransactionManager 이용해서 안전하고 편하게 트랜잭션을 적용할 수 있다.

• DataSourceUtils

    private Connection getConnection(){
            return DataSourceUtils.getConnection(hikari);
        }

  DataSourceUtils.getConnection()을 사용하면 현재 트랜잭션이 있으면 이미 사용했던 커넥션을 반환한다. 아니면 새로운 커넥션을 반환한다.

  즉, 한 트랜잭션 안에서 하나의 커넥션을 사용할 수 있도록 한다.

    private void close(Connection conn, Statement stmt, ResultSet rs){
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);
        DataSourceUtils.releaseConnection(conn, hikari);
    }

  DataSourceUtils.releaseConnection()도 위의 논리와 같이 재사용을 위해 커넥션을 재우는게(idle) 아니라 트랜잭션 안이라면 이를 보류한다.

JdbcUtils.closeStatement(stmt)는 stmt.close()는 뭔 차이임?

JdbcUtils.closeStatement()내부적으로 이렇게 생김

    public static void closeStatement(@Nullable Statement stmt) {
        if (stmt != null) {
            try {
                stmt.close();
            } catch (SQLException ex) {
                logger.trace("Could not close JDBC Statement", ex);
            } catch (Throwable ex) {
                logger.trace("Unexpected exception on closing JDBC Statement", ex);
            }
        }
        }

그냥 stmt가 null이어도 짜증나는 NPE 안터지고 무시하고 중간에 예외생기면 그냥 삼켜버리고(안 던짐) 로그남기는 기능 가지고 있음.

• PlatformTransactionManager

    TransactionStatus transaction = platformTransactionManager.getTransaction(
            new DefaultTransactionDefinition()
    );

  위와같이 사용할 수 있는데 하나씩 뜯어서 알아보자

  • platformTransactionManager는 스프링에서 제공하는 트랜잭션 관리자 인터페이스이다.

    이 녀석이 실제로 트랜잭션을 시작, 커밋, 롤백하는 주인공이다.

  • getTransaction는 트랜잭션이 지금 있는지 판단후 트랜잭션을 시작한다. 기존 트랜잭션이 있으면 기존 트랜잭션을 사용한다. 이 메소드의 결과로 TransactionStatus 를 반환한다.

  • DefaultTransactionDefinition은 트랜잭션의 정책을 정의한다.

    항목으로는 PropagationBehavior, IsolationLevel, Timeout, ReadOnly이 있다.

    아무 설정을 안하면 기본정책이 적용된다.

- **`TransactionStatus`**는 **현재 트랜잭션의 상태를 나타내고 제어**할 수 있는 스프링의 트랜젝션 핸들러다.

    주요 기능으로는 isNewTransaction(), isCompleted(), setRollbackOnly(), isRollbackOnly()등이 있다.

위를 통합하여 사용하면 트랜잭션이 실제로 적용되는지 테스트해봅시다.

repository에 DataSourceUtils적용되있으나 코드로는 서비스만 보도록 하자.(너무 길다.)

레포지토리에는 save()와 update()가 구현되어 있다.

public void transactional(Member member, boolean exception) {
        TransactionStatus transaction = platformTransactionManager.getTransaction(
                new DefaultTransactionDefinition()
        );

        try{
            Member saved = repository.save(member);

            if(exception){
                throw new SQLException();
            }
            String newPassword = "Updated";
            repository.update(saved, newPassword);
            platformTransactionManager.commit(transaction);
            log.info("커밋되었습니다.");
        } catch (SQLException e) {
            log.info("롤백됩니다.");
            platformTransactionManager.rollback(transaction);
        }
    }

위 코드에서 exception이 false로 들어온다면 정상적으로 save와 update가 적용 될 것 이다.

하지만 save()를 수행하고 중간에 예외가 발생한다면 어떻게 될까. 트랜잭션을 적용하지 않았다면 save만 적용이 되고 update는 적용이 되지않아 원자성을 만족할 수 없다.

@Test
    @DisplayName("transaction_test")
    void transactional() throws Exception {

        Member member = new Member(null, "TransacionTest", "Original");
        boolean exception = true;
        service.transactional(member,exception);

    }

실제로 위 코드처럼 중간에 예외를 터트려보면

롤백된다는 로그가 찍히고

실제로 DB상으로도 save()도 적용이 안되고 롤백되어 버린걸 확인 할 수 있다.

REST는 Representational State Transfer의 약자로 표현적 상태 전송이라고 번역할 수 있으나

자원 표현을 통한 상태 전달이라고 설명하는 것이 이해가 쉬울 것 같습니다.

그럼 한 단어씩 뜯어서 본격적으로 REST를 알아보기 전에 대충 감을 잡아 봅시다.

1. 자원(Resource)

   자원은 상태의 주체가 되는 데이터입니다.

   예를 들어 회원정보를 수정하고 싶다면 회원정보가 자원이 됩니다.

   자원은 URI로 식별됩니다. https://csi/user/4567

2. 표현(Representation)

   회원정보에는 다양한 정보들이 있을 수 있습니다. 예를들어 ID, email, 나이 등

   이를 조작하려 할 때 자원의 현재 상태나 의도된 상태에 대한 값들과 무엇을 수행할지에 대한 표현을 Representation이라고 합니다.

   JSON, XML등의 형식으로 http 메시지 본문(Payload)에 담겨 전송됩니다.

    PUT /users/123 HTTP/1.1
    Content-Type: application/json
   
    {
      "email": "user@example.com",
      "age": 25
    }

3. 상태 전달(State Transfer)

   클라이언트가 서버의 자원상태를 요청(Request)하면 서버는 그에 대한 응답(Response)를 하여 자원의 상태를 전달합니다.(CRUD)

   자원 상태를 전달할 때 위에서 설명한 표현을 통해 특정 형태로 전송합니다.

즉, REST는 자원을 URI로 구분하여 해당 자원의 상태를 주고받는 것을 의미합니다.

여기서 중요한 점은 REST은 상태전달의 목적에 따라 HTTP 메소드를 통해 상태전달이 이루어집니다.

예를들어 34번 게시글을 보고싶다면 GET방식으로

http://posts.com/post/34 라는 URI에 요청을 보내면

서버는 이에 해당하는 페이지로 응답해서 그 게시글을 볼 수 있게 되는 것 입니다.

REST 아키텍처

REST 설계 원칙

위의 설명은 REST를 정말 간략히 설명한 것입니다.

REST를 처음 제안한 Roy Fielding은 REST API가 만족해야할 아키텍처 제약 조건이라고도 하는 6가지의 설계원칙을 소개했습니다.

클라이언트-서버 구조(Client-Server)

클라이언트와 서버 구조의 핵심 원리는 역할의 분리(Separation of Concerns)입니다. 말이 어려워 보이지만 우리는 이미 이 구조를 사용하고 있습니다.

자원을 요청하는 클라이언트와 자원이 있는 서버로 나눈 구조를 따라야 합니다.즉, 서버에서는 비즈니스 로직 처리 및 저장을 책임지고, 클라이언트에서는 요청한 자원을 화면에 나타내는 역할을 책임 집니다.

이 구조를 통해서 사용자 인터페이스의 다양한 플랫폼 간 이식성이 향상되고, 서버 구성요소의 단순화를 통해 확장성 또한 향상될 수 있습니다.

추가로 구성요소들의 의존성이 줄어들어 독립적으로 발전할 수 있게 됩니다.

(프론트와 백엔드가 너무나도 독립적으로 발전해버렸다..)

무상태(Stateless)

무상태란 서버가 클라이언트의 상태를 고려하지 않는 것을 의미합니다. 클라이언트가 서버에 보내는 요청에는 이를 이해하기 위한 모든 정보를 포함되어야 합니다. 즉, 서버는 클라이언트의 컨텍스트(ex. 쿠키, 세션)를 저장해선 안됩니다.

클라이언트가 이전 요청과 동일한 요청을 보냈다고 해도 서버는 이를 별개의 요청으로 판단하고 하나하나 처리만 하면 됩니다. 즉, 이전 요청이 다음 요청의 처리에 연관 되면 안됩니다.

무상태를 통해 3가지의 이점이 생깁니다.

• 가시성(Visibility) 향상 : 하나의 요청만으로 요청 전체의 의미 파악이 가능
• 신뢰성(Reliability) 향상 : 부분적인 오류 발생 시 쉬운 복구
• 확장성(Scalability) 향상 : 요청간 상태를 저장, 관리 하지 않기 때문에 서버는 빠르게 자원을 해제할 수 있고, 구현이 간단해 집니다.

무상태의 단점(trade-off)도 있습니다.

한 요청은 그 요청에 필요한 모든 정보를 가지고 있기 때문에 요청마다 반복적인 데이터(오버헤드)를 포함하여 성능이 저하 될 수 있습니다.

또 일관성 유지가 어렵습니다. 서버가 사용자의 상태를 모르므로, 항상 같은 경험을 제공하기 어려울 수 있습니다.

⇒ 클라이언트의 버전이 서로 다르다면, 각 버전마다 어떻게 동작할지 서버 알 수 없게 되기에(의존적 향상 : 어플리케이션의 동작을 클라이언트의 버전에 의존)

캐시(Cache)

서버의 응답 데이터가 암시적 또는 명시적으로 ‘캐시가능’ 또는 ‘불가능’으로 표시되어야 합니다. 캐시가능한 응답이라면 클라이언트의 캐시는 같은 요청에 대해 해당 데이터를 재사용할 수 있는 권한을 가지게 됩니다.

캐시는 반복되는 요청을 줄이거나 생략함으로 서버의 부담이 줄어 대량의 요청을 효율적으로 처리할수 있다.

이는 네트워크 효율성을 높여 응답 지연 시간(latency)을 줄일 수 있습니다.

단, 오래된 캐시가 서버의 최신 데이터와 다르다면 신뢰성을 저하 시킬 수 있습니다.

일관된 인터페이스(Uniform interface)

REST라는 아키텍처 스타일이 다른 네트워크 방식과 가장 뚜렷하게 다른 점은, 구성 요소들(예: 클라이언트와 서버)이 서로 소통할 때 '통일된 인터페이스'를 사용한다는 점입니다.

모든 기계가 동일한 콘센트를 쓰게 해서, 플러그를 바꿀 필요 없이 꽂기만 하면 되게 만든 것과 같습니다. 즉, 특정 상황에만 맞게 만드는 게 아니라 모든 구성 요소가 일관된 방식으로 소통할 수록 하여야 합니다. 이러한 원칙을 일반화(generality)라고 합니다.

일관된 인터페이스을 위한 조건들은 따로 존재하므로 이에 대한 설명은 아래에서 추가로 설명하겠습니다.

계층화(Layered System)

계층화는 각 구성요가 자신과 직접 상호작용하는 계층 외에는 볼 수 없도록(관심 없음) 제한 하는 것을 뜻합니다. 이를 통해 전체 시스템의 복잡도를 줄이고, 각 시스템의 독립성을 높입니다.

따라서 계층화 구조에서는 클라이언트가 대상 서버에 직접 연결되었는지, 중간 서버를 통새 연결되었는지 알 수 없습니다.

$$이해하기 어렵지만 근본있는 그림이다(Roy아저씨가 그린 그림)$$

계층화는 여러 목적에서 유용합니다.

• 본 서버는 순수 비지니스 로직만을 수행하고, 중간 서버들이 다른 부가적인 기능(보안, 암호화, 로드밸런싱 등)을 수행하도록 하여 구조의 유연성을 기대할 수 있습니다.
• 중간계층을 통해 연결하므로 보안성을 향상 할 수 있습니다.
• 여러 중간 서버를 두어 로드밸런싱을 수행하여 확장성을 향상 시킬 수 있습니다. (갑작스럽게 트래픽이 증가해도 대응이 가능)
• 계층 구조는 중간 서버를 들려서 통신하기 때문에 오버헤드와 지연이 생겨, 성능의 저하가 생길 수 있습니다. 이를 중간계층의 캐시기능을 통해 상쇄가 가능합니다.

Code-On-Demand(Optional)

COD는 클라이언트가 서버로부터 코드를 받아서 클라이언트에서 실행하는 것을 의미합니다.

이를 통해 클라이언트에 미리 구현해두어야할 기능이 줄어들기 때문에 클라이언트의 구현이 간단해지고, 배포 이후에 기능을 다운로드할 수 있기에 시스템의 확장성이 향상됩니다.

하지만 COD는 시스템의 가시성을 감소시키기 때문에(클라이언트에서 실행되는 코드이기 때문에 이를 실행하지 않는 외부에선 이해하기 어렵다.) 선택적 제약(Optional)으로 간주됩니다.

일관된 인터페이스의 조건

자원에 대한 식별(Identification of resources)

REST에서 자원이란(resourse) 이름을 가질 수 있는 모든 정보입니다. 즉, 특정 시점의 어떤 객체 그 자체가 아니라, 시간에 따라 바뀔 수도 있는 개체 (문서, 날씨, 이미지 etc)들에 대한 개념적 매핑이라고 말 할 수 있습니다.

리소스는 특정 시점의 결과물이 아니라, 그 뒤에 있는 개념이기 때문에 이를 나타내는 변하지 않는 식별자가 필요합니다.

즉 자원의 값이 변하여도 변하지 않는 일관적인 식별자URI가 중요합니다.

좋은 식별자를 통해 우리는 어떠한 객체 그 자체가 아니라 변화가 가능한 개념에 접근 할 수 있게 됩니다.

표현을 통한 리소스의 조작(Manipulation of resources through representations)

REST의 구성요소들은 리소스에 대해 어떠한 행동(조작)을 할 때, 리소스의 현재 상태나 의도된 상태에 대한 표현(representation)을 사용하여 리소스를 조작합니다.

이 표현에는 리소스의 상태에 대한 값과 무엇을 수행할 지에 대한 표현(http method)도 포함되어 있습니다.

즉, 표현을 통해 리소스를 조작하여야지 이를 URI을 통해 조작한다면 일관된 인터페이스가 불가 합니다.

아래와 같이 표현에 자원을 조작할 때 필요한 모든 정보가 담겨 전달 되게 해야한다.

PUT /users/123 HTTP/1.1
Content-Type: application/json

    {
    "userID" : 123
  "email": "new@example.com",
}

상태와 동작을 URI로 표현시키면 ❌

 /updateUserEmail?userId=123&email=new@example.com

자기 서술적 메세지(Self-descriptive message)

자기 서술적 메세지는 이를 이해하는데 필요한 모든 정보를 포함하는 메세지입니다.

이는 무상태(Stateless)와 관련이 있습니다. 앞서 설명했듯이 서버는 클라이언트의 상태에 관심이 없기 때문에 요청마다 그 요청을 설명하는데 필요한 모든 정보를 포함하여 요청해야합니다. 이는 응답도 마찬가지 입니다. (클라이언트도 서버안의 컨텍스트를 모른다.)

자기 서술적 메세지는 일반적으로 다음의 요소들을 포함하고 있다.

• HTTP 메서드 : 동작을 명확하게 표현 (GET, POST, PUT 등)
• URI : 대상이 되는 리소스를 나타낸다.
• 헤더 : Content-Type, Accept, Authorization 등 메세지의 형식, 요구, 제약을 설명
• 본문: 리소스의 상태나 입력 값(JSON, XML형태)

그렇다면 아래는 자기 서술적인 메세지 일까요?

HTTP/1.1 200 OK
Date: Sat, 06 Apr 2025 10:15:00 GMT
Content-Type: application/json
Cache-Control: no-store
{
  "id": 123,
  "name": "Jane Doe",
  "email": "new.email@example.com",
  "createdAt": "2022-01-01T10:00:00Z",
  "updatedAt": "2025-04-06T10:15:00Z"
}

놀랍게도 아니랍니다.

왜냐? 이 응답 메시지는 id , name email 의 값만을 알려주고 있고, id , name email이 정확이 무엇을 뜻하는 지에 대한 정보는 제공하지 않고 있습니다.

id는 사용자 id일수도 있고, 주문번호일 수도 있고

name은 실명인지 닉네임인지

email은 로그인용인지 알림 수신용인지

정확하게 제시하고 있지 않기에 이 응답 메시지는 Self-descriptive하지 않습니다.

그렇다면 Self-descriptive해지려면 어떻게 해야할까?

1. API 명세 문서화(OpenAPI / Swagger 등)

   API의 구조, 동작, 데이터 타입 등을 명세화하여 문서화

    User:
      type: object
      required:
        - id
        - name
        - email
      properties:
        id:
          type: integer
          description: 사용자 고유 식별자(로그인시 사용)
        name:
          type: string
          description: 사용자의 실명
        email:
          type: string
          format: email
          description: 알림 수신용 이메일 주소

   이런 API 명세 문서를 클라이언트측과 서버측이 공유하여 사용하면 양측이 메세지에 대한 정확한 이해를 할 수 있다.

2. JSON Sechema링크

   헤더에 Link를 사용하여 JSON Sechema같은 명세를 링크할 수 있습니다.

    Link: <https://api.example.com/schema/users.json>; rel="describedby"; type="application/schema+json"
   

   이 링크를 통해 클라이언트는응답에 있는 리소스의 명세를 파악할 수 있습니다.

   리소스 명세를 링크할때 HAL을 이용할 수도 있는데(좀 더 일반적인 것 같다.), HAL을 이후에 알아볼 HATEOAE에서 자세히 다루겠지만 지금은 링크를 통해 다음에 무엇을 할 수 있는지를 알려주는 것이라고만 이해해봅시다.

   이 HAL을 이용해 데이터의 구조와 의미를 설명하는 JSON Schema(OpenAPI와 비슷)를 링크할 수 있습니다.

    "describedby": {
          "href": "https://api.example.com/schemas/user.json",
          "type": "application/schema+json"
        }

   이 부분에서 나는 의문이 있었다. 아니 왜 하필 JSON Schema를 연결하는가 OpenAPI는 왜 안되는가?

   ⇒ 이는 OpenAPI는 전체 API의 명세를 담고 있어서 지나치게 복잡하기 때문입니다.

   JSON Schema는 하나의 리소스 단위로 스키마 문서를 쪼개서 배포할 수 있기 때문에 응답에 포함되어 있는 리소스의 명세만 링크가 가능합니다!

Hypermedia as the engine of application state(HATEOAS)

이걸 뭐라고 번역을 할까 고민하다가 하이퍼미디어 기반 애플리케이션 상태 제어쯤이면 괜찮지 않을까 한다..너무 길어서 이하 HATEOAS라고 하겠습니다.

HATEOAS란 클라이언트 어플리케이션이 서버로 부터 받는 하이퍼미디어 표현(links, form등)을 통해 상태 전이되어야 함을 의미합니다.

HATEOAS를 통해 클라이언트는 표현에 포함된 링크를 통해 다음 동작을 이해하고 진행할 수 있습니다. 즉 서버는 클라이언트가 어떤 상태에 있고, 어디로 이동(상태전이)가 가능한지를 하이퍼미디어 형태로 안내합니다.

위에 자기서술적메세지에서 잠깐 나온 HAL은 HATEOAS을 가능케하기위해 응답 메시지에서 하이퍼링크를 구조화해서 표현하는 JSON기반 포맷입니다.

{
  "id": "123",
  "name": "Alex",
  "email": "alex@example.com",
  "_links": {
    "self": {
      "href": "/users/123"
    },
    "update": {
      "href": "/users/123",
      "method": "PUT"
    },
    "delete": {
      "href": "/users/123",
      "method": "DELETE"
    },
    "friends": {
      "href": "/users/123/friends"
    }
  }
}

위와 같이 HAL은 _links키워드를 통해 현재 리소스에 관련된 링크들을 나열합니다.

이를 통해 클라이언트는 응답메시지를 통해 현재상태를 알 수 있고, 다음 할 수 있는 행동(상태)을 파악하고 동작 할 수 있습니다.

이러한 HATEOAS이 중요한 이유는 서버가 바뀌어도 클라이언트는 이를 몰라도 된다는 것입니다.

예를들어 특정 동작에 대한 URI가 바뀌었다고 생각해봅시다.

HATEOAS가 만족되지 않는 API를 이용한다면 클라이언트는 URI가 바뀔때마다 이를 파악하고 클라이언트의 코드를 수정해야 합니다.

하지만 HATEOAS가 만족된다면 클라이언트는 서버가 준 링크만 따라가면 되므로 문제가 없습니다.

이러한 이점은 새기능 추가, 다양한 클라이언트의 상황에서도 마찬가지로 적용됩니다.

그래 그래서 이걸 다 지켜?

• CMIS : REST 바이딩이 있습니다!

  Roy Fielding : ㅋㅋㅋREST바이딩이래 그거 REST아님 (실제로 한말 : “This so-called REST binding is not REST at all.”)

• 마소 : API 스타일 가이드 보러오세요!

  Roy Fielding : 응 아니야 걍 HTTP임; (“It's not REST. It's just HTTP.”)

• 그 외 (Google APIs, 트위터 등) : RESTful호소자(대부분 RPC)

이 글에서 계속 알아봤듯이 REST를 지켜 RESTful한 API를 구현하는 것은 쉬운 것이 아닙니다. 실제로 Roy아저씨도 이걸 느꼈는지 REST 원칙을 엄격하게 적용하는 것이 항상 최선은 아니며, 시스템의 전체를 통제할 수 있는 상황이라면 REST를 따지는 것이 시간 낭비일 수 있다고 언급한 바 있습니다.

그래서 우리도 RESTful에 너무 집착하지 말고 개발하는 시스템에 적합하고 이득이 될만한 부분을 차용하여 적용하는 것이 적합하다고 생각합니다.

마치며

사실 이글에 REST에 대한 간략한 개념을 정리할 예정이었습니다. 하지만 알아보면 알아볼 수록 블로그들마다 설명하는 것이 추상적이고 URI에 규칙? 같은걸 소개하고 있었다. 혼란스러워하다가 그냥 REST만든 사람의 설명을 보는게 정확할 거 같아서 Roy아저씨의 REST논문을 토대로 이 글을 작성하게 되었다.(물론 번역기를 십분 활용했다.) 영문으로 된 아주 긴 논문을 이해하는 것은 역시 생각보다 힘들었지만 이곳에 답이 있었다. RESTful하다는 것은 어떠한 정형화된 법칙을 따라야하는 것이 아니라 제시된 여러 제약사항(개념이라고 하고싶다)을 만족하는 것임을 알게 된거 같다.

이번 경험을 통해서 학습을 할때 특히 어떠한 개념을 학습할때는 공식문서가 느리지만 제일 빠른 길인 것 같다. 가장 정확하다는 확신이 서고, 의심이 생기지 않는다. 블로그같은 것을 통해 학습을 할땐 이게 맞는 말인지 항상 의심하고 다른거 찾아보다가 의심하고… 오히려 시간이 낭비되는거 같다.

데브코스 강사님이 항상 공식문서와 친해지라고 한 이유를 알 것 같다. 앞으론 영 읽는게 힘들지만 공식문서를 먼저 찾아야 겠다. 추가호 학습 과정에서 새롭게 알게된 OpenAPI(Swagger)를 학습을 해봐야 겠다.

참조

REST-API란[hjkim] REST API에 대하여 (feat. 로이 필딩 논문)[여행하는 개발자 해서미] Architectural Styles and the Design of Network-based Software Architectures[Roy Thomas Fielding] Untangled(Roy Fielding 블로그

DAO

이름이 귀엽지 않은가 DAO는 Data Access Object로 말 그대로 DB의 데이터에 접근하는 객체이다.

DAO의 주요역할은 아래와 같다.

• 데이터베이스 연결 및 쿼리 실행 SQL을 실행해서 데이터에 접근, 조회 및 조작.
• 비즈니스 로직과 분리 서비스 로직과 DB로직을 분리해서 보다 쉬운 유지보수를 가능케한다.
• 객체와 관계형 DB사이의 매핑 결과값을 객체로 변환하거나, 객체를 DB에 맞게 가공 및 저장한다.

Java Spring기준으로 DAO는 여러 모양새를 가지고 있을 수 있다.

• DB Connection이 설정되어 있는 경우
• 그렇지 않은 경우

MyBatis는 DB Connection정보를 root-context.xml이라는 파일에 저장하고 JPA는 application.yml(properties)에 설정하여 사용한다.

DTO

DTO는 Data Transfer Object로 데이터를 전달하는 객체이다. DTO는 Controller, View 등 레이어 사이에서 데이터를 전달하는 역할을 한다.

데이터를 전달하는게 역할을 가지는 객체이므로 서비스로직을 가지지 않는다. 데이터 전달 용도로 사용하는 객체이므로 당연히 서비스로직이 필요없다.

순수한 데이터객체로써 getter와 setter만 가진다.

public class DtoEx {
    private String name;
    private int age;

    DtoEx(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

• 롬복(Lombok)을 사용하여 가독성이 좋은 코드를 쓸 수 있다!

  @Data   //Setter, Getter, toString
  @Builder    //객체를 build 방식으로 생성할 수 있다.
  @AllArgsConstructor //모든 필드 값을 매개변수로 받는 생성자
  @NoArgsConstructor  //매개변수가 없는 생성자
  public class DtoHasSetter {
    private String name;
    private int age;
  }

VO

VO는 Value Object로 값 그 자체의 객체이다. 그냥 쉽게 Setter가 없는 DTO라고 보면 될 것 같다.(Getter만 존재 할 수 있다.)

즉 VO는 한 번 생성하면 변경이 불가하다(read-Only) 그렇기에 새로운 값을 사용하려면 새로운 VO를 생성해야한다.

또한 VO는 모든 필드값이 같으면 두 객체는 같다는 정의를 가진다. 이를 위해 equals()와 hashCode()의 오버라이딩이 필요하다.

@Getter
public class VoEx {
    private final String name;
    private final float height;

    public VoEx(String name, float height) {
        this.name = name;
        this.height = height;
    }


    @Override
    public int hashCode() {
        return Objects.hash(name, height);
    }


    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if(!(obj instanceof VoEx)) return false;
        VoEx o = (VoEx)obj;
        return Objects.equals(name, o.name) && height == o.height;
    }
}

public static void main(String[] args) {
        VoEx original = new VoEx("Max",182.2f);
        VoEx same = new VoEx("Max", 182.2f);

        boolean equals = original.equals(same);

        System.out.println(equals);
    }

// 출력 : true
// equals오버라이딩 안할 시 false가 출력된다)

Entity

Entity는 실제 DataBase의 테이블과 1:1 매핑되는 클래스이다. 고로 Entity는 DB 테이블의 존재하는 칼럼만을 필드로 가져야 한다. 테이블에 존재하지 않는 속성을 가져서도 안된다.

또한 Entity 기준으로 테이블이 형성되므로 Entity의 값이 바뀌면 DB에 반영된다.

Entity는 데이터를 전달하는 용도로 사용하면 안된다. 즉, DTO와 분리하여 사용하여야 한다.

추가로 Entity는 비즈니스 로직을 포함할 수도, setter() 메소드를 포함할 수도 있습니다.

@RequiredArgsConstructor
public class Order {
    private final int id;
    private final String customerId;
    private LocalDateTime orderDate;
    private int totalPrice;
    private Oder_Status status;

    //상태변경 비지니스 로직 가능
    public void setStatus(Oder_Status status) {
        this.status = status;
    }

    //id 기준으로 동일성 판단
    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Order order)) return false;
        return id == order.id;
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(id);
    }
}

마치며

공부하면서 자주 접하는 DAO, DTO, VO, Entity 개념을 그동안 다소 모호하게 알고 있었는데, 이번 글을 통해 가볍게나마 각 개념을 정리할 수 있었다. 단순히 개념을 읽고 이해하는 데 그치지 않고, 간단한 예제를 직접 만들어보며 코딩해 본 경험이 개념을 더 잘 체득하는 데 큰 도움이 되었다.

정적 페이지

• Web Server가 요청이 들어오면 해당 요청에 해당하는 파일을 반환한다.
• 이 파일은 항상 같은 페이지(밀키트 자판기라고 생각해보자. 밀키트 자판기는 밀키트를 조리해서 주지 않는다. 그냥 밀키트를 줄 뿐)
  • WEB이 정적자원을 처리한다.

동적 페이지

• 클라이언트의 요청에 맞게 동적인 데이터를 반환한다.(원하는 대로 조리를 해서 준다 와 개이득)
• Web Server에서 실행되는 프로그램의 연산을 통한 결과가 필요
  • 이 동적인 페이지 생성하기 위한 프로그램이 Servlet
  • 이러한 프로그램(Servlet)이 실행되는 서버가 WAS

웹 서버(Web Server)

• 클라이언트의 HTTP 요청을 해석하여 이에 맞는 데이터로 응답

• 이 HTTP를 해석하고 그에 맞는 데이터 형식으로 보내 준다.

• 정적데이터들을 다룬다.

  ⇒ 처리속도가 빠르고 트래픽 과부하를 잘 처리

왜 웹서버는 미들웨어가 아닌가?

⇒ 웹서버는 WAS와는 다르게 비지니스 로직을 담당하지 않기 때문에

어플리케이션 서버(Application Server)

• 데이터를 가공, 연산하여 처리하는 비지니스 로직을 처리하는 서버

• HTTP를 통해 컴퓨터나 장치에 비지니스 로직을 수행해주는 미들웨어로 볼 수 있다.

  ⇒http는 요청과 응답에 규약이있음. 이 데이터를 자바(or 다른 언어)로 쓸수 있게 바꾸어줌.

• 동적데이터를 처리, 주로 DB서버와 같이 수행한다.

WAS(Web Application Server)

• WAS는 JAVA EE스펙을 구현하여, 서블렛이나 JSP로 작성된 어플리케이션을 실행하는 소프트웨어(어플리케이션 서버)

어플리케이션 서버와 WAS는 같은 것 인가?

⇒ JAVA EE를 구현하여 서블릿으로 작성된 어플리케이션을 실행 할 수 있으면 WAS

즉, WAS는 어플리케이션 서버의 한 종류

Jakarta EE

분산 어플리케이션 개발 목적의 산업 표준 플랫 폼

Servlet(서블릿), JSP, EJB, JDBC, JNDI, JMX, JTA등의 기술을 포함

Servelet Container(Web Container)

CGI(Common Gateway Interface)

웹 서버가 동적인 데이터를 반환하기 위해선 이를 위한 비지니스로직을 처리하는 프로그램이 필요하다. 이 데이터를 처리하는 프로그램에 요청을 적절히 전달해주는 중간자 역할을 하는 프로그램이 CGI프로그램이다.

(클라이언드 → CGI Process → Program)

하지만 CGI는 실체가 있는 도구가 아니라 웹 서버와 외부 프로그램 사이에서 정보를 주고 받는 방법, 즉 표준 스펙이자 인터페이스입니다.

⇒ 다양한 언어(PHP, Python …)로 CGI를 구현(적용) 할 수 있다.

JAVA에선 CGI와 유사한 방식으로 구현된 서블릿(Servlet)이라는 프로그램이 존재

서블릿

서블릿은 JAVA를 사용하여 웹 요청(HTTP)을 처리하고 응답을 생성하는 서버 측 프로그램

• JAVA EE(Jakarta EE)에서 제공하는 웹 기술
• 클라이언트가 보낸 요청을 받고 서버에서 응답을 생성해서 돌려주는 역할

💡 Jakarta EE의 스펙(인터페이스, 명세) 중 하나인 Servlet을 구현 → 이를 WAS로 배포

서블릿은 싱글톤 패턴

싱글톤이란?

하나의 클래스에 대해 하나의 인스턴스만 존재하도록 보장하는 디자인 패턴

1. 서블릿은 싱글톤으로으로 동작한다. → 모든 요청에 대해서 하나의 같은 인스턴스를 공유

2. 여러 요청이 동시에 들어온다면?

   • 하나의 서블릿 인스턴스에 대해 여러 스레드가 동시에 접근
   • 멀티스레드 환경이 자동으로 만들어진다(서블릿 컨테이너가 함)

3. 이 때 서블릿 내부에 멤버 변수가 있으면?

    private int count = 0;
   
    protected void doGet(...) {
        count++; // Thread-Unsafe!
    }
   

   • 경합(race condition)이 발생가능
     • 둘 이상의 스레드(또는 프로세스)가 동시에 같은 자원에 접근하거나 변경할 때, 실행 순서에 따라 프로그램의 결과가 달라질 수 있는 상황(가능성이 현실이 됨..)
   • Thread-Safe하지 않음
     • Thread-unsafe라는 말은 여러 스레드가 동시에 어떤 공유 자원에 접근하거나 조작할 때, 예상치 못한 결과나 오류가 발생할 수 있는 상황을 의미(가능성)

💡서블릿의 Thread-Safe를 보장하려면 다음과 같은 방법을 적용해야 한다.

• 무상태(stateless) : 멤버변수를 사용하지 않음(로컬 변수만 사용)
• 읽기 전용(read-only) : 상수처럼 변하지 않는 값만 사용
• 동기화 처리 : synchronized, AtomicInteger 와 같은 별도의 Thread-Safe구조를 사

서블릿 컨테이너

⚡웹 컨터이너와 서블릿 컨테이너는 같은 말

• 서블릿 자체로 작동하는 것이 아니고 이를 생성, 소멸 및 관리해주는 것이 서블릿 컨테이너
• 서블릿이 역할을 수행하는 정의서라면, 서블릿 컨테이너는 이 정의서를 보고 수행한다.

💡Tomcat은 서블릿 컨테이너이면서도 WAS의 역할도 어느정도 가진다. 하지만 Tomcat은 JAVA EE의 스펙을 전부 구현하지 않기 때문에 → 서블릿 컨테이너라고 할 수 있다.

서블릿 컨테이너는 IoC(Inversion of Control: 제어의 역전)과 DI(Dependency Injection: 의존성주입)

을 할 수 있으며 서블릿 컨테이너의 역할은 다음과 같다.

(IoC와 DI는 아래에서 자세히 알아보자)

서블릿 컨테이너의 기능

• 웹 서버와 통신 지원

  • 서블릿과 Web Server가 통신할 수 있도록 한다.
  • 이는 서블릿 컨테이너가 알아서 하기 때문에 개발자는 통신에 신경을 쓸 필요가 없음

• 서블릿 생명주기 관리

  • 서블릿의 생성/호출/소멸을 관리
  • 요청이 들어오면 해당 서블릿을 찾고 없으면 초기화(web.xml을 읽는다.)
  • 서블릿의 메소드를 호출 → 실제 기능을 하도록 한다
  • 서블릿의 역할이 끝나면 GC가 관련 인스턴스를 소멸

• 멀티 쓰레딩 관리

  • 서블릿 컨테이너는 요청이 들어올때마다 새로운 쓰레드를 생성하여 멀티 쓰레딩 방식으로 처리

• JSP 지원

  • JSP를 서블릿으로 변환시켜 처리

IoC와 DI

이 이름만 들어도 어지러운 두개는 도대체 무엇일까? 알아보자

• IoC

  프로그램의 제어 흐름을 개발자가 아닌, 외부(프레임워크)가 맡는 것

  ⇒ 즉, 개발자가 객체 만들고 흐름을 제어하는 것이 아니고, 이를 외부 시스템이 대신 함 ㄱㅇㄷ.

• DI

  어떤 객체가 필요로 하는 의존 객체를 직접 만들지 않고, 외부에서 전달받는 방식

  ⇒ 필요한걸 내가 안만듦, 누가 대신 만들어서 내한테 줌.

  ❌ DI없는 코드

    class Engine {
        void start() { System.out.println("엔진 시작"); }
    }
  
    class Car {
        private Engine engine = new Engine();  // Car가 직접 Engine을 만듬
  
        void start() {
            engine.start();
        }
    }

  • Car는 항상 Engine에 강하게 묶여있다. (강한 결합)

    • 테스트 어렵고, 의존하는 객체(Engine )을 바꾸기도 어렵다. (구현객체를 참조)

    ⭕ DI 적용 코드

    class Car {
      private Engine engine;
    
      // 외부에서 의존성(Engine)을 주입받음
      public Car(Engine engine) {
          this.engine = engine;
      }
    
      void start() {
          engine.start();
      }
    }

  • 이제 Car는 어떤 Engine이든 의존이 가능(유연성 증가)(인터페이스를 참조 → 약한 결합)

    • 테스트, 유지보수, 확장성이 좋아짐

Spring MVC

MVC는 Model-View-Controller의 약자

Spring MVC는 이 구조를 기반으로 웹 어플리케이션을 구성하는 프레임워크이다.(Spring 프레임워크의 하위 모듈)

MVC구조

• Model - 데이터와 비지니스 로직을 처리
• View - 사용자에게 보여지는 화면
• Controller - 사용자의 요청을 받아 처리, 결과를 모델과 뷰로 전달

Spring MVC의 동작 흐름

1. DispatcherServlet이 요청을 받는다. (스프링의 프론트 컨트롤러)
2. 요청을 HandlerMapping에 넘겨준다
3. HandlerMapping은 해당 요청을 처리할 Handler(Controller)를 탐색
4. Handler실행 할 수 있는 HandlerAdapter를 탐색한다
5. 찾은 HandlerAdapter를 사용하여 Handler의 메소드를 실행
6. Handler의 반환값은 Model과 View임
7. View 이름을 ViewResolver에게 전달, ViewResolver는 해당 View객체를 전달
8. DispatcherServlet은 View에게 Model을 전달. (이때 Model이 null이면 그대로 View사용, 아니면 View에 Model데이터를 렌더링)
9. DispatcherServlet은 View의 결과를 응답

Spring Container(IoC 컨테이너, DI 컨테이너)

일단 스프링컨테이너, IoC컨테이너, DI컨테이너 모두 같은 것을 지칭하는 용어다.

왜 용어가 통일이 안되는가 헷갈리게..

자 스프링 컨테이너를 이해하기 위해선 일단 Bean이 무엇인지를 알아야합니다.

Bean이란 간단히 Spring이 관리하는 객체입니다. 즉 앞으로 알아볼 스프링 컨테이너가 생성하고 관리하는 객체가 Bean입니다.

앞에서 IoC에 대해서 간단하게 소개했었는데 이 Bean을 스프링 컨테이너가 IoC를 적용해서 관리합니다.(알아서 관리한다는 소리, 개발자가 직접 생성하고 관리하지 않는다.)

즉, 스프링컨테이너는 이 Bean의 생명 주기를 관리하는 역할을 합니다.

• DispatcherServlet이라는 서블릿이 Spring Container을 사용하여 요청을 처리합니다.

💡이 IoC컨테이너를 상속하여 부가 기능을 추가한 것이 ApplicationContext이다.

정리하자면 서블릿컨테이너 안에 Spring MVC의 DispatcherServlet이라는 서블릿이 등록되어 있고,

이 DispatcherServlet가 Spring컨테이너(ApplicationContext)을 통해 Bean들을(@Controller, @Service 등) 관리하여 요청에 의한 비지니스로직을 처리합니다.

웹 어플리케이션 요청-응답 흐름 정리

1. 클라이언트가 HTTP요청을 보낸다.

2. 이 요청을 WEB이 받는다.

   2-1. 정적 자원 요청이면 WEB이 직접 응답한다.

   2-2. 동적자원 요청이면 이른 WAS에 전달한다.

3. WAS(Servlet Container)가 요청을 받아 Spring MVC의 DispatcherServlet를 호출

4. DispatcherServlet이 요청에 따라 처리할 Controller Bean을 결정

5. Spring Container(ApplicationContext)가 등록된 Bean들을 이용해 로직 처리

6. 처리 결과를 View 또는 JSON의 형태로 응답

느낀점

웹 애플리케이션 아키텍처를 정리하면서 처음 보는 용어도 많고, 같은 개념을 여러 방식으로 부르는 경우도 많아 많이 헷갈렸던 것 같습니다. 하지만 개념을 하나씩 정리해가다 보니, 각 구성 요소의 역할과 흐름이 조금씩 보이기 시작했고, 웹의 전반적인 구조를 이해하는 데 큰 도움이 되었습니다.

단순히 코드를 따라치는 것만으로는 구현은 가능하겠지만, 구조와 개념에 대한 이해가 없다면 그것은 진짜 '이해한 것'이 아니라고 느꼈습니다. 앞으로도 무언가 어렵거나 개념이 잡히지 않을 때는, 스스로에게 설명하듯 글로 정리하며 학습하는 습관을 가져야겠다는 생각이 들었습니다.

글이 다소 길고 두서없을 수 있지만, 저에게는 분명히 정리가 되는 소중한 시간이었습니다. 혹시 잘못된 내용이나 부족한 부분이 있다면 언제든지 알려주십쇼! 저에게 정말 큰 도움이 될 겁니다.

참조

[Spring] Spring MVC - Servlet, Servlet Container, Spring Container 에 대해 [Spring] Servlet, Servlet Container, Spring MVC 정리

자료구조란 데이터를 효율적으로 저장하고 관리하는 방식 Create, Read, Update, Delete가 되어야 한다 (CRUD) 이번 글에선 자바의 배열과 Collections 자료구조에 대해서 간단하게 정리해보았다.

배열(Array)

메모리에 연속적인 위치에 차례대로 저장된다.

크기 고정(선언시에 지정한 크기 변하지 않는다.)

int[] intArr = {1,2,3,4}
//임마는 크기가 4개로 고정

Collections Framework

자바는 collections라는 라이브러리를 통해 다양한 자료구조를 제공한다.

java.util패키지에 포함되어 있음.

배열리스트(ArrayList<E>)

배열과 다르게 크기가 동적이다.

일정크기의 배열을 만들었다가 일정 수준 해당 배열이 차면 내부적으로 크기를 늘린다.

자바의 ArraryList는 길이가 자동으로 확장되지만, 자동으로 축소되진 않는다.

인덱스 기반 접근이 빠름 - 배열의 크기 조절, 중간에 요소 삽입/삭제 느림

⇒ 줄이고 싶으면 trimToSize()

ArrayList<String> arrList = new ArrayList<>();
arrList.add("Hello");
arrList.add("World"); //값 추가
arrList.get(1); //1번 인덱스 값 가져옴
arrList.remove(0) //0번 인덱스 값 삭제

연결리스트(LinkedList<E>)

내부적으로 노드를 사용하여 값을 연결한다. (연속적 위치 ❌)

요소의 삽입과 삭제가 쉽다.

자바의 연결리스트는 이중연결리스트로 구현되어 있다.

⇒ 각 노드가 자기의 앞, 뒤의 노드를 알고 있음

LinkedList<String> linkedList = new LinkedList<>();
linkedList.add("Hello");
linkedList.add("World");
linkedList.add("!");
linkedList.removeFirst();
linkedList.remove(1);

스택(Stack<E>)

LIFO(Last In, First Out) 구조를 가진다

⇒ 마지막에 추가된 데이터가 먼저 나온다. (ex. 쌓여올려진 접시들을 생각해보자)

인덱스로 접근하지 않고 push, pop을 이용하여 데이터를 추가, 삭제한다.

Stack<Integer> intStack = new Stack<>();
for(int i = 1; i <= 5; i++) {
    intStack.push(i); //1,2,3,4,5
}
intStack.pop(); //1,2,3,4
intStack.pop(); //1,2,3

큐(Queue)

FIFO(First In, First Out) 구조

⇒ 추가된 순서대로 데이터가 나온다. (줄을 선 모습을 생각해보자)

스택과 비슷하게 인덱스로 접근하지 않고 add와 poll로 데이터를 추가, 삭제한다.

💡 Queue는 인터페이스이므로 LinkedList 또는 PriorityQueue로 객체 생성해야 한다.

    Queue<Integer> q = new LinkedList<>();
    for(int i = 1; i <= 5; i++){
        q.add(i); // 1,2,3,4,5
    }

    q.poll(); // 2,3,4,5
    q.poll(); // 3,4,5

    System.out.println(q.peek()); //맨 앞 값 반환(제거X) 3
    System.out.println(q); // 3,4,5

덱(Deque<E>)

Deque(Double Ended Queue)는 스택과 큐를 합쳤다고 생각하면 편하다.

⇒ 양쪽(앞/뒤)에서 삽입과 삭제가 모두 가능하다.

💡 Deque는 인터페이스이므로 LinkedList 또는 ArrayDeque로 객체 생성해야 한다.

Deque<Integer> dq = new LinkedList<>();
dq.addFirst(10); //10
dq.addLast(20);  //10,20
dq.addFirst(30); //30,10,20

dq.pollLast(); //30, 10
dq.pollFirst(); // 10

해쉬맵(HashMap<K, V>)

키-값(Key, Value)쌍을 저장하는 자료구조

내부적으로 배열과 연결 리스트를 조합하여 구현된다.

키가 해슁되어 저장되기 때문에 검색이 빠르다.

💡해쉬(Hash)란?

본인은 해쉬를 정보보안으로 처음 알았다. 특히 포렌식할때 중요한 개념으로 배웠는데 어떠한 파일이나 자료들의 무결성을 증명하는 수단으로 쓰였다. 왜냐? 이 해시라는 것은 원칙적으로는 유일성을 보장하기 때문이다.

⇒ 한마디로 해싱이란 어떠한 데이터를 해쉬알고리즘을 통해서 그 데이터으로만 만들 수 있는 값을 만드는 것이다.

위 말대로면 아주 완벽해 보이지만 이 또한 인간이 만든것이므로 간혹 다른 데이터가 같은 해쉬값을 만들어 낼 수 도 있다. 이를 해쉬충돌이라고(Hash Collsion)이라고 한다.

이러한 문제가 해시맵에서 일어났을 때는 어떻게 대처를 하는지 밑에서 알아보자

1. 키를 해싱하여 해시 값을 만든다.
2. 이 해쉬값을 버킷이라는 배열의 길이로 나머지연산(%)하여 나온 값이 인덱스가 되어 해당 위치에 저장된다.(버킷은 고정길이 배열(Node<K,V>[])가 들어있다. 2차원 배열과 비슷?)
3. 여기서 만약 해쉬충돌이 일어난다면, 같은 버킷 내의 연결리스트로 값을 추가한다.(같은 키값 다른 벨류)
4. JAVA8부터는 연결리스트가 많아지면(해시충돌이 많이 일어나면) 트리(Red-Black Tree)로 변환되어 성능 최적화

배열 (Bucket) 구조:
[0]  →  null
[1]  →  null
[2]  →  ("apple", 100) → ("grape", 300)  ⬅ (해시 충돌 발생, 연결 리스트로 저장)
[3]  →  null
[4]  →  ("banana", 200)

HashMap<String, Integer> map = new HashMap<>();

// 데이터 추가 (put)
map.put("Apple", 1000);
map.put("Banana", 2000);
map.put("Cherry", 3000);

// 데이터 가져오기 (get)
System.out.println(map.get("Apple"));  

// 키 존재 여부 확인 (containsKey)
System.out.println(map.containsKey("Banana"));  

// 값 존재 여부 확인 (containsValue)
System.out.println(map.containsValue(400)); 

// 크기 확인 (size)
System.out.println(map.size());  

// 데이터 삭제 (remove)
map.remove("Cherry");

// 전체 출력 (entrySet)
for (var entry : map.entrySet()) {
    System.out.println(entry.getKey() + " -> " + entry.getValue());
}

스트림(Stream)이란

• 자료구조(컬렉션, 배열 등)을 쉽게 처리할 수 있도록 도와주는 기능
• 데이터를 반복문 없이 연속적으로 처리할 수 있게 함

기존의 for문 이나 iterator를 사용하면 코드가 길어짐

가독성 재사용성 떡락 또한 데이터 타입마다 다르게 다루어야한다 귀찮다.

⇒ 스트림은 데이터 소스에 상관없이(데이터 소스를 추상화) 모두 같은 방식으로 다룰 수 있다.

스트림의 특징

• 데이터를 한 줄씩 처리 : 자료구조 전체를 메모리에 올리지 않고, 하나씩 순차적으로 처리

• 불변성 : 기존의 데이터 변경 ❌, 새로운 데이터 반환

• 람다식 사용(→)

• 중간 연산과 최종 연산 : 데이터를 가공 → 중간 연산, 결과 출력 → 최종연산

  • 지연 연산 사용

    ⇒ 최종 연산이 호출되어야 중간 연산이 수행된다.

스트림 사용하기

스트림 만들기

스트림을 사용하려면 스트림을 만들어야겠죠.

어떤 스트림을 만드느냐에 따라서 방법이 조금씩 다릅니다.

• 배열 스트림 : Arrays.stream(배열명)으로 만들 수 있습니다.

String[] strArr = {"a", "b", "c", "d", "e", "f", "g", "h"};
Stream<String> arrStream = Arrays.stream(strArr);

• 컬렉션 스트림: .stream()으로 생성합니다.

LinkedList<String> linkedList = new LinkedList<>();
Stream<String> linkedListStream = linkedList.stream();

ArrayList<Integer> arrayList = new ArrayList<>();
Stream<Integer> arrayListStream = arrayList.stream();

• 직접 스트림 생성 : 배열이나 컬렉션 없이 직접 스트림 생성(builder(), Stream.of())

//builder 사용
Stream<String> builderStream = Stream.<String>builder()
      .add("a").add("b")
      .build();

//Stream.of()사용
Stream<String> streamOf = Stream.of("Hello", "World");

• 람다사용 : 람다를 사용하여 스트림을 생성 할 수도 있다. (Stream.generate(), Stream.iterate())

1. Stream.generate()

    Stream<Integer> randomStream = Stream.generate(() -> (int) (Math.random() * 100)).limit(3);
   

   Stream.generate()는 Supplier<T>람다식을 이용하므로 값을 공급하는(단지 생성하는) 스트림을 만들때 사용한다.

   limit()를 사용하지 않으면 무한으로 값이 생성된다 → 무한스트림!

1. Stream.iterate()

    Stream<Integer> iterateStream = Stream.iterate(0, n -> n + 2).limit(3

   Stream.iterate()는 매개변수가 1개 있는 UnaryOperator람다식을 사용해서 초기값으로 연산식을 통해 연산되는 값이 연속적으로 생성된다.

   또한, generate()와 동일하게 limit()를 사용하여 개수를 제한할 수 있다.

• 기본 타입형 스트림 : 기본형 스트림도 만들 수 있다!!

  (IntStream, LongStream, DoubleStream)

IntStream intStream = IntStream.range(1,5);
DoubleStream doubleStream = DoubleStream.of(1.2,15.8,2154.8487);

중간연산

데이터를 가공하는 과정(변형, 필터링… 등)

중간 연산은 메서드체이닝이 된다. (연속적으로 수행)

• filter() : 조건에 맞는 데이터 선택(필터링) , if문과 비슷한 역할

    List<Integer> list = Arrays.asList(1,2,3,4,5);
    Stream<Integer> result = list.stream().filter(n -> n > 3);
    result.forEach(System.out::println);
  
    /*출력
    4
    5
    */

• map(): 데이터를 변환

    List<String> strList = Arrays.asList("a", "b", "c", "d", "e", "f", "g", "h");
    Stream<String> strStream = strList.stream().map(l -> l.toUpperCase());
  
    strStream.forEach(l -> System.out.print(l+" "));
  
    /*출력
    A B C D E F G H 

• sorted() : 데이터 정렬 (Comparator를 사용한다.)

    List<String> words = List.of("apple", "banana", "blueberry", "oranges");
    Stream<String> wordsStream = words.stream()
            .sorted((s1, s2) ->  Integer.compare(s1.length(), s2.length()));
    wordsStream.forEach(System.out::println);
  
    //Comparator.comparing()을 사용하면 더 간결
    Stream<String> sortedWords = words.stream()
            .sorted(Comparator.comparing(String::length));  // 문자열 길이 기준 정렬
    sortedWords.forEach(System.out::println);
  
    /*출력
    apple
    banana
    oranges
    blueberry
    */

• distinct() : 중복제거

• skip(n) : 앞의 n개 건너뛰기

• peek() : 중간 상태 확인용(디버깅)

    List<String> listForRests = Arrays.asList("a", "a", "c", "d", "e", "f", "f", "h");
    Stream<String> wordsStreamForRests = listForRests.stream().distinct()
            .limit(4)
            .peek(s -> System.out.println("중간확인 : " + s))
            .skip(2);
    wordsStreamForRests.forEach(System.out::println);

최종 연산

스트림을 처리하여 최종 결과 반환

최종 연산 이 후엔 스트림이 소모(사용)되므로, 한번만 실행 가능

• 통계내기(기본형 타입만 가능)

    //count()로 개수 반환 long타입반환
    long count = IntStream.of(grades).count();
  
    //sum()으로 합계 구하기
    int summed = IntStream.of((grades)).sum();
  
    //min() 최솟값 : OptionalInt반환 (null값 대비)
    OptionalInt minimum = IntStream.of(grades).min();
  
    //max() 최댓값 : OptionalInt반환 (null값 대비)
    OptionalInt maximum = IntStream.of(grades).max();
  
    //average() 최솟값 : OptionalDouble반환 (null값 대비)
    OptionalDouble avg = IntStream.of(grades).average();
  

• collect(): 스트림 요소 원하는 자료형으로 변환

    List<String> list = List.of("apple", "banana", "cherry", "apple");
  
    // List -> Set 변환 (중복 제거)
    Set<String> set = list.stream()
                    .collect(Collectors.toSet());

• reduce() : 스트림의 요소를 누적하여 하나로 합친다.

  • 초기값이 있으면 T 반환, 없으면 Optional<T>를 반환한다. (null값 대비)

    List<Integer> numbers = List.of(1, 2, 3, 4, 5);
    //초기값이 없으므로 Optional<T>를 반환한다.
    Optional<Integer> sum = numbers.stream()
                   .reduce((a, b) -> a + b); //15
    
    //초기값 있으므로 Optional불필요(null일 수가 없음)                 
    int sumWithInitial = numbers.stream()
                  .reduce(5,(a, b) -> a + b); //20                       

• 매칭(anyMatch(), allMatch(), noneMatch())

  • 특정 조건을 만족하는 요소가 있는치 체크

  • boolean반환

    //길이가 4이상인 요소가 하나라도 있는지
    boolean any = members.stream().anyMatch(name -> name.length() >= 4);
    System.out.println(any); // true
    
    //모든 요소가 "e"를 포함하는지
    boolean all = members.stream().allMatch(name -> name.contains("e"));
    System.out.println(all); // false
    
    //q로 끝나는 요소가 하나도 없는지
    boolean noneMatched = members.stream().noneMatch(name -> name.endsWith("q"));
    System.out.println(noneMatched); // true

병렬 스트림(Parallel Stream)

여러 개의 스레드를 사용하여 데이터를 병렬로 처리가 가능!

parallelStream() 이나 parallel()을 이용해 병렬 스트림 사용

순서가 보장되지 않는다. (순서가 보장되어야 한다면 주의해야 한다.)

⇒ 즉, 기본 스트림은 순차적으로 하나씩 데이터를 처리하지만 병렬스트림은 여러 스레드에서 동시에 데이터를 처리한다!

List<String> list = List.of("A", "B", "C", "D", "E");

list.parallelStream()
        .forEach(s -> System.out.println(Thread.currentThread().getName() + " - " + s));

/*
출력
ForkJoinPool.commonPool-worker-3 - A
ForkJoinPool.commonPool-worker-1 - B
main - C
ForkJoinPool.commonPool-worker-2 - E
ForkJoinPool.commonPool-worker-5 - D
*/

parallel()은 기존 스트림을 병렬스트림으로 변환해준다.

list.stream()  // 순차 스트림
    .parallel()  // 병렬 처리로 변환
    .forEach(s -> System.out.println(Thread.currentThread().getName() + " - " + s));

이번 정리를 통해서 대충 스트림이 어떤 역할을 하는지는 알 것 같다.

하지만 아직 코드로 직접 사용하는데는 서툰거 같아서 틈틈히 일부로 스트림을 사용해봐야겠다.

또한 스트림을 알아보면서(사실 람다 공부했을 때) 메서드 참조(::) 가 근근히 보이는데 이것도 나중에 정리를 해봐야겠다. (멋져보이지 않는가!)

• 람다는 익명 함수라고도 한다.
• 함수를 간결하게 표현하는 방법
• 코드의 가독성이 좋아짐

한 번만 사용할 메소드를 일일히 정의하면 정의할 메소드가 너무 많아지지 않겠나!

그럴때 사용하기 좋은 것이 람다이다. 본인은 일회용 메소드 비슷하게 이해하고 있다.

익명 클래스 사용

• 익명클래스란 이름이 없는 클래스
• 클래스를 정의함과 동시에 인스턴스를 생성할 때 사용

람다가 없으면 있는 선택지는 익명클래스를 사용하는 겁니다.

Consumer<String> c = new Consumer<String>() {

    @Override
    public void accept(String s) {
        System.out.println("Hello, " + s);
    }
};

c.accept("Lambda!");

이렇게 일회용 메소드를 익명클래스를 이용해서도 사용할순 있다만, 너무 복잡하고 무엇보다 쓰기가 너무 귀찮습니다.

단, 익명클래스는 여러개의 메서드를 가질 수 있다는 장점?이 있습니다.(이럴 거면 그냥 클래스를 하나 만드는게..)

이런 귀찮음을 해결 할 수 있는게 람다입니다

람다의 구성

일단 람다가 어떻게 생겨먹었는지부터 보자

(매개변수,매개변수) → {
            표현식
        }

//매개변수 하나일때 () 생략가능        
매개변수 -> {
    표현식
}

//한 줄이면 {}도 생략가능, return쓰면 안됌(암시적 반환)
매개변수 -> 표현식

람다는 → 연산자를 사용한다.

→ 좌측에 있는 매개변수가 → 우축에 있는 명령문에 들어가 연산수행 가능

이 람다는 메소드와 동일하게 반환값을 변수에 할당할 수 있다.

추가로 람다식이 한줄일때 반환값이 있더라도 return을 명시하면 문법 오류 발생함.

(여러줄 일땐 {}과 함께 return 필수)

Function<Integer, Integer> square = x -> return x * x; - ❌

Function<Integer, Integer> square = x -> x * x; - ⭕

함수형 인터페이스(Functional Interface)

• 함수형 인터페이스는 하나의 추상 메서드만을 가지는 인터페이스

• 람다는 함수형 인터페이스의 추상 메서드를 구현하면서 사용합니다.

  ⇒ 람다 표현식으로 간단하게 이 하나의 추상 메서드를 구현!!

• 함수형 인터페이스에는 Consumer, Supplier, Function, Runnable 등이 있다.

  • 물론 우리가 직접 함수형 인터페이스를 만들 수도 있다.(@FunctionalInterface)

Consumer

@FunctionalInterface
public interface Consumer<T> {

    void accept(T t);

• 함수형 인터페이스 Consumer 는 accept()라는 추상 메소드를 가진다.
• accept() 는 입력값만 있고 반환을 하지 않는다. 즉, 소비만 한다.

Consumer<String> AnonymousConsumer  = new Consumer<String>() {
    @Override
    public void accept(String s) {
        System.out.println("Hello, " + s);
    }
};
AnonymousConsumer.accept("익명클라스~!");

Consumer<String> MultiLambda = (s) -> {
    System.out.println("Hello, " + s);
};

MultiLambda.accept("여러줄 람다~");

Consumer<String> SingleLambda = s -> System.out.println("Hello, " + s);
SingleLambda.accept("한 줄 람다~");

/*
출력
Hello, 익명클라스~!
Hello, 여러줄 람다~
Hello, 한 줄 람다~
*/

Supplier

public interface Supplier<T> {

    T get();
}

• Supplier는 get()이라는 추상 메소드를 가짐
• get()은 매개변수를 받지 않고 반환만 한다. 즉, 공급만 한다.

Supplier<String> justStringOut = () -> "Supplying..";
String str = justStringOut.get();
System.out.println(str);

Supplier<Integer> randomNumberSupplier = () -> (int) (Math.random() * 100);
for (int i = 0; i <= 5; i++){
    System.out.println(randomNumberSupplier.get());
}
/*
출력
Supplying..
31
84
64
16
50
43
*/

Function<T, R>

@FunctionalInterface
public interface Function<T, R> {
    R apply(T t);

• apply() 라는 추상 메서드 가짐
• 이름처럼 매개변수를 받아서 적용시키고 반환함 → <T, R> 모두 지정해야 한다.

Function<Integer, Integer> square = x -> x * x;
Integer applied = square.apply(5);
System.out.println(applied);

Function<String, String> upperCase = x -> x.toUpperCase();
String Uppercase = upperCase.apply("lambda");
System.out.println(Uppercase);

/*
출력
25
LAMBDA
*/

Runnable

@FunctionalInterface
public interface Runnable {

    void run();

• 매개변수도 없고, 반환도 안함

• 멀티쓰레드를 구현할 수 있게함(Thread클래스가 Runnable구현)

  • Thread의 start()를 호출 → 새로운 쓰레드가 생성 → run()이 백그라운드에서 실행

  • 사용법: Thread t = new Thread(runnable); t.start();

    ⇒ 멀티코어 CPU에서는 실제로 동시에 병렬 실행! (싱글코어에서는 그런 것처럼 보임)

Runnable runnable = () -> System.out.println("단지 실행할 뿐..");
runnable.run();

//출력 : 단지 실행할 뿐..

Runnable task = () -> {
    for (int i = 0; i < 5; i++) {
        System.out.println(Thread.currentThread().getName() + ": " + i);
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

    }
};

Thread thread1 = new Thread(task);
Thread thread2 = new Thread(task);

thread1.start();
thread2.start();

/*
출력
Thread-0: 0
Thread-1: 0
Thread-0: 1
Thread-1: 1
Thread-0: 2
Thread-1: 2
Thread-0: 3
Thread-1: 3
Thread-0: 4
Thread-1: 4
*/

이처럼 Runnable을 Thread에 전달하여 멀티쓰레드가 실행된다.

메서드 체이닝

• 객체에서 여러 개의 메서드를 연속적으로 호출 하는 것
• 점(.)을 이용해 연속호출

밑에서 대표적인 메서드 체이닝 방법 두개를 소개해 보겠다.

객체 자신을 반환 (this 반환)

public class MethodChaining {
    public String name;
    public int age;
    public boolean isGay;
    public String gay;

    public MethodChaining setName(String name) {
        this.name = name;
        return this;
    }

    public MethodChaining setAge(int age) {
        this.age = age;
        return this;
    }

    public MethodChaining setGay(boolean isGay) {
        this.isGay = isGay;
        gay = (isGay) ? "게이" : "게이아님";
        return this;
    }

    public MethodChaining show() {
        System.out.println("이름: " + name + " 나이: " + age + " 게이?: " + gay);
        return this;
    }
}

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

        new MethodChaining()
                .setName("홍석천")
                .setAge(54)
                .setGay(true)
                .show();
    }
}
/*
출력
이름: 홍석천 나이: 54 게이?: 게이
*/

이런식으로 같은 객체에서 this를 반환하는 메소드들을 연속해서 호출할 수 있다.

andThen()

Consumer과 Function함수형 인테페이스에는 사실 accept()말고도 하나의 메소드가 더 있다.

public interface Consumer<T> {


    void accept(T t);

    default Consumer<T> andThen(Consumer<? super T> after) {
        Objects.requireNonNull(after);
        return (T t) -> { accept(t); after.accept(t); };

@FunctionalInterface
public interface Function<T, R> {

    R apply(T t);

    default <V> Function<V, R> compose(Function<? super V, ? extends T> before) {
        Objects.requireNonNull(before);
        return (V v) -> apply(before.apply(v));
    }

    default <V> Function<T, V> andThen(Function<? super R, ? extends V> after) {
        Objects.requireNonNull(after);
        return (T t) -> after.apply(apply(t));
    }

두 함수형 인터페이스의 andThen을 잘보라!

모두 자기 자신을 반환하고 있다!(Function의 compose도 마찬가지다.)

즉, 이 두 함수형 인터페이스는 andThen과 compose(Function)를 통해서 메서드 체이닝이 가능하다.

//첫번째 방법
Consumer<String> consumer1 = (s) -> System.out.println("첫 번째 람다!: " + s);
Consumer<String> consumer2 = consumer1.andThen((s) -> System.out.println("두 번째 람다!: " + s));

consumer2.accept("메서드 체이닝!");

//두번때 방법
Consumer<String> consumer1 = (s) -> System.out.println("첫 번째 람다!: " + s);
Consumer<String> consumer2 = (s) -> System.out.println("두 번째 람다!: " + s);

Consumer<String> chaining = consumer1.andThen(consumer2);
chaining.accept("메서드 체이닝!");
/*출력
첫 번째 람다!: 메서드 체이닝!
두 번째 람다!: 메서드 체이닝!
*/

Function<Integer, Integer> function1 = i -> i * 2;
Function<Integer, Integer> function2 = i -> i + 10;

Function<Integer, Integer> answer = function1.andThen(function2);
Function<Integer, Integer> composed = function1.compose(function2);

System.out.println(answer.apply(3));
System.out.println(composed.apply(3));
/*
출력
16
26
*/

위와 같이 Function의 compose()는 andThen()과 실행순서가 반대이다.

⇒ andThen : 왼쪽실행 후 오른쪽실행

⇒ compose: 오른쪽 실행 후 왼쪽 실행

번외: 나의 착각

사실 위에 this를 반환하는 메소드들이 연속으로 호출이 가능한건 점(.)왼쪽의 메소드의 반환타입과 점(.) 오른쪽의 메소드의 매개변수 타입이 같기 때문에 메소드 체이닝이 가능하다고 생각해서

같은 원리로 this를 반환하지 않아도 반환타입가 매개변수 타입만 만족한다면 메소드 체이닝은 가능한게 아닌가..? 라고 생각했는데 뭐.. 되긴되는데 이건 메서드체이닝이 아니었다.

⇒ 걍 메서드를 중첩 호출하는 거임

public class Main {
    public static String methodA() {
        return "hello";
    }

    public static int methodB(String input) {
        return input.length();
    }

    public static void main(String[] args) {
        int result = methodB(methodA()); //이건 그냥 메서드 중첩 호출이다...
        System.out.println(result);
    }
}

예외(Exception)

• 프로그램 실행 중 발생하는 비정상적인 상황
• 예외도 객체다..

Checked Exception

• 컴파일 타임에서 검사되는 예외 → 예외 처리 강제 → 무시하면? 컴파일 오류

⇒ 고로 try-catch 나 throws / throw 를 사용해서 예외처리 해야함

• Exception 을 상속

Unchecked Exception

• 컴파일러가 체크하지 않는 예외 → 예외처리 하지 않아도 컴파일됨 → 실행중에 예외가 발생 할 수 있다.
• NullPointerException 과 같은 예외 자주 발생 → null 여부 확인해야 한다. 등
• RunTimeException 을 상속(RunTimeException은 Exception을 상속)

예외처리

throws

• 메서드 선언부에 작성하여 메서드에서 예외가 발생할 수 있음을 알림
• 메소드를 호출하는 시점에서 예외처리가 되야함(예외를 던져서 호출한 놈한테 책임전가 ㄷㄷ;)

throw

• 예외를 강제로 발생시킴

try-catch-fianlly

• try : 예외가 발생할 수 있는 코드 작성
• catch : 예외가 발생할때의 대처 작성
• finally : 예외 발생여부 상관없이 반드시 실행(생략가능)

public class ExceptionTest {
    public void ex() throws RuntimeException {
        System.out.println("예외 날라간드아~ㅋㅋ");
        throw new RuntimeException("쿠쿠루 삥뽕");
    }
}

public class ExMain {
    public static void main(String[] args) {
        try {
            ExceptionTest ex = new ExceptionTest();
            ex.ex();
        }catch (RuntimeException e) {
            System.out.println("에러 발생!!"+e);
        }finally {
            System.out.println("생략 안해주셔서 감사합니다..");
        }
    }
}

/*
출력
예외 날라간드아~ㅋㅋ
에러 발생!!java.lang.RuntimeException: 쿠쿠루 삥뽕
생략 안해주셔서 감사합니다..
*/

사용자 정의 예외

• 새로운 예외 클래스를 정의하여 사용가능

  ⇒ Exception 이나 RunTimeException클래스를 상속받아 생성

• 예외의 원인을 좀 더 정확히 특정 할 수 있음

catch(GotWeakerException e) {
    throw new FailLiftException("수행을 실패했습니다.",e); 

public class FailLiftException extends Exception {
    public FailLiftException (String message, Throwable cause) {
        super(message, cause);
    }
}

cause에 이 예외가 발생한 원인 예외를 넣어주면 연쇄적인 예외처리가 가능하다.

오류(Error)

• 시스템 수준의 심각한 문제 → 프로그램에서 처리 못함

• Throwable을 상속 받기에 try-catch 사용가능하지만 치명적인 문제이기에 조취를 취해야함

  ⇒ 즉, 잡지마라

• 오류도 객체..

제네릭(Generic)

• 자바에서 제네릭이란 참조 자료형의 타입을 일반화하는 것
  • 코드의 재사용성 높임
  • 타입 안정성 보장

⇒ 컴파일 시점에 타입이 결정되는 가변적인 타입 매개변수

한마디로 어떤 참조 자료형(클래스 타입)이 들어올지 모르기에 일단 뭐든 들어올 수 있게 열어 놓고 있다가, 실제 객체가 특정 타입으로 생성될 때 그 타입으로 결정되는 것 (양자역학인가..?)

제네릭 기호 네이밍

기본적으론 제네릭의 이름에 제약사항은 따로 없다. 사실 변수 이름 지을 때처럼 마음대로 정해도 된다. 하지만 다른 사람을 배려하는 마음으로 통상적인 네이밍을 따르는 것도 바람직 할 것 같다. (보통 대문자 알파벳 문자를 사용한다.)

• <T> : Type
• <E> : Element
• <K> : Key (Map)
• <V> : Value (Map)
• <N> : Number
• <R> : 리턴 타입(메서드에서 자주 사용)
• <U> , <S> : 제네릭 타입 여러개 일대 보조적 으로 사용

제네릭 사용

public class GenericBox<T> {
    public T stuff;

    public GenericBox(T stuff) {
        this.stuff = stuff;
    }

    public T whatHave() {
        System.out.println("I have " + stuff);
        return stuff;
    }
}

public class Main {
    public static void main(String[] args) {
        GenericBox<String> strBox = new GenericBox<String>("Tools");
        GenericBox<Integer> intBox = new GenericBox<>(1234);
        GenericBox<Boolean> boolBox = new GenericBox<>(true);

        strBox.whatHave();
        intBox.whatHave();
        boolBox.whatHave();
    }
}

/*
출력
I have Tools
I have 1234
I have true
*/

이런식으로 GenericBox의 필드타입을 제네릭을 사용하여 객체가 생성될때 필드의 타입이 결정된다.

참고로 제네릭 클래스의 인스턴스를 생성할 때

Box<String> myBox = new Box<String>();

이건 당연히 되겠지만

Box<> myBox = new Box<String>(); 이러면 오류발생 가능(컴파일러가 좌변의<>를 보고 우변의 <>을 추론하기 때문에)

Box<String> myBox = new Box<>(); 고로 이건 오류가 안남.

제네릭과 Static

Static필드에서의 제네릭

그렇다면 필드값이 Static이어도 제네릭이 사용가능 할까?

답은 안된다.

이유는 크게 두 가지다.

• static변수는 객체 생성 없이 접근이 가능

  • static 변수는 클래스 로드 시점에 생성 된다. 제네릭은 객체가 생성될 때 결정된다 → 충돌발생

    ⇒ 한마디로 static은 모든 인스턴스가 공유하지만, 제네릭 타입은 각 객체마다 다를 수 있으므로!!

• 타입소거

  • 제네릭은 컴파일 시에만 유효, 런타임에서 제네릭 타입 제거 → Object 또는 특정 상위 클래스로 변환

    ⇒ 클래스 수준에서 static 변수를 정의할 방법이 없다. (런타임에는 제네릭이 존재 X, )

    즉,

    static 변수는 클래스 로드 시점에 메로리에 로딩되어 런타임까지 유지되어야한다.

    근데,

    제네릭은 타입 소거로 인해서 런타임에서 타입 정보가 사라짐(Object)

Static메소드에서의 제네릭

근데 또 static 메소드는 된다. 뭘까 이 일관되지 않은 규칙은..

이유를 알아보자.

한마디로 Static 메서드의 제네릭 타입은 메서드가 호출될 때 결정되기 때문이다.

static변수와 마찬가지로 static메소드의 정의가 클래스 로드 시점에 메서드 영역에 저장된다.

하지만 static변수와 다르게 static메소드는 이 시점에서 제네릭의 타입이 결정 되지 않고 (static변수는 저장될때 타입이 결정되어야 하지만, static메소드는 호출 될때 결정해도 된다.)

⇒ 메소드가 호출될 때마다 다른 제네릭 타입을 사용할 수 있기때문에 제네릭 사용이 가능하다.

public class GenericBox<T> {

    public static <T> void whatHave(T t) {
        System.out.println("I have " + t);
    }
}

public class Main {
    public static void main(String[] args) {
        GenericBox.whatHave("Hello");
        GenericBox.whatHave(1234);
        GenericBox.whatHave(false);
    }
}

/*
출력
I have Hello
I have 1234
I have false
*/

제네릭 타입 제한

• 제네릭에서 특정 타입만을 허용하도록 제한하는 기능
• 상한제한과 하한제한으로 나눌 수 있다.

앞으로의 설명을 위해 아래와 같은 상속(구현) 관계가 있다고 생각 해보자

interface A class B implements A class C extends B class D

상한제한

extends 키워드를 사용하여 특정 클래스나 인터페이스를 상속하거나 구현한 타입만 허용

예를 들어

class UpperBoundedClass <T extends B>

이렇게 제한한다면 T는 B를 상속하는 타입만이 올 수 있습니다.(B포함)

⇒ B, C가 올 수 있음.

하한제한

super 키워드를 사용하여 특정 클래스의 상위 타입만 가능

class LowerBoundedClass <T super B>

⇒ B의 상위 타입인 B, A타입이 가능(B도 포함)

다중제약(다중 경계)

&를 사용하여 두개 이상의 제약을 걸 수 있다.(| 은 안됨!!)

class MultiBoundedClass <T extends B & A>

T 에는 B를 상속함과 동시에 A를 구현한 타입만이 올 수 있음.

⇒ 클래스는 하나만 가능하다(자바에선 다중 상속이 안되기에..)

와일드카드 : ?

• 와일드카드 ? 는 제네릭 타입을 사용할 때, 어떤 타입이 올지 모를 겅우 유연하게 처리하는 기능
• 메서드에서만 사용 가능

public class WildCard {
    public static void printList(List<?> list){
        for (Object o : list) {
            System.out.println(o);
        }
    }
}

public class WildCardMain {
    public static void main(String[] args) {
        List<String> strList = new ArrayList<>();
        strList.add("Hello");
        strList.add("World");

        List<Integer> intList = new ArrayList<>();
        intList.add(1);
        intList.add(2);

        WildCard.printList(strList);
        WildCard.printList(intList);
    }
}

/*
출력
Hello
World
1
2
*/

위처럼 printList의 매개변수를 List<?> 는 List의 타입이 무엇이든 받을 수 있다.

와일드카드 메서드와 제네릭 메서드의 차이

와일드카드 타입제한

제네릭과 유사하게 와일드카드의 범위를 제한할 수 있다.

1. ? (Unbounded Wildcard)

   • 어떤 타입의 제네릭이든 허용(모두 허용)

2. 상한제한(Upper Bounded Wildcard)

   • extends 키워드를 사용하여 제네릭과 동일하게 상속하는 하위 타입만 허용

   • ex) <? extends Number> : Number와 그 하위 타입만 허용(Number를 상속하는)

   • 읽기만 가능, 쓰기 불가

     ⇒ 위 예에서 Number와 그 하위 타입중 하나이지만 정확히 어떤 타입인지 모르기에 쓰기가 불가능.(Integer, Double, Float 뭘 넣어야할지 모름..)

3. 하한제한(Lower Bounded Wildcard)

   • super 키워드를 사용하여 상위 타입만을 허용

   • ex) <? super Integer> : Integer와 그 상위 타입만 허용

   • 쓰기가 가능

     ⇒ 위 예에서 Integer 또는 그 상위 타입(Number, Object) 중 하나지만, 최소한 Integer 이상이 보장되기 때문에!

번외: Optional

Optional 객체를 사용하면 null처리를 안전하고 우아하게 가능(정적 팩토리 메서드 사용하여 객체 생성)

• 정적 팩토리 메서드 : new 키워드로 객체를 만드는 대신 static메서드로 객체를 생성하게 하는 메소드
• null을 감싸는 객체 제공 → null을 직접 다루지 않고 안전한 연산 가능!

Optional 객체 생성 방법

1. Optional<String> opt1 = Optional.of("Hello"); : 반드시 값이 있어야 함
2. Optional<String> opt2 = Optional.ofNullable(null); : 값이 null일 수도 있다.
3. Optional<String> op3 = Optional.emtpy(); : 빈 객체 생성

Optional 구현 실습

import java.util.Objects;

public class Optional<T> {

    private final T data;

    private Optional(T data) { //private 생성자이므로 외부에서 접근 불가
        this.data = data;
    }

    public static <T> Optional<T> empty() { //빈 객체 반환
        return new Optional<>(null);
    }

    //값이 있는 객체를 반환 (requireNonNull : Null이면 예외 발생)
    public static <T> Optional<T> of(T value) { 
        return new Optional<>(Objects.requireNonNull(value));
    }

        // null이면 빈 객체 반환, 아니면 그 값 담긴 객체 반환
    public static <T> Optional<T> ofNullable(T value) {
        return value == null
                ? new Optional<>(null)
                : new Optional<>(value);
    }

        // 객체에 담긴 값 확인 -> null이면 예외 발생(커스텀 가능!)
    public T get() {
        if ( data == null ){
            throw new NoSuchElementException("No value present");
        }
        return data;
    }
        // 값 있음?
    public boolean isPresent() {
        return data != null;
    }
        // 빔?
    public boolean isEmpty() {
        return data == null;
    }

}

모든 클래스의 최상위 부모 클래스

⇒ 모든 클래스는 Object클래스를 자동으로 상속

class Test /*extends Object 생략 */ {}

Object클래스에는 모든 객체가 사용할 수 있는 기본 메서드 포함

• equals()

  • 기본은 == 연산자와 같이 메모리 주소를 비교

    하지만 override를 통해 논리적비교 구현 가능(값 비교)

• hashCode()

  • 객체를 해시기반 자료구조에 저장할때 사용
  • 같은 객체라면 동일한 hashCode값을 반환해야함 ⇒ equals() 오버라이딩할때 함꼐 오버라이딩해야 하는 이유

• toString()

  • 객체의 정보를 문자열로 표현
  • 기본적으로 클래스명@해시코드 형태로 출력
    • 오버라이딩을 통해 커스텀가능

equals() 오버라이딩

• 동등성 : 객체가 가지고 있는 값을 비교(논리적 비교)
• 동일성 : 객체의 메모리 주소값을 비교(==, 물리적 비교)

equals()는 기본적으로 == 와 동일하게 객체의 실제 메모리 주소값을 비교

⇒ 같은 데이터값을 가진 객체라도 다르다고 판단

객체간의 동등성을 비교하기 위해선 equals()를 오버라이딩하여 사용해야한다.

public class Person {
    public String name;
    public int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public boolean equals(Object o) {
            if (this == o) return true; // 같은 객체인지 확인(두 객체의 메모리 주소가 완전히 같은 객체)
        if (o == null || getClass() != o.getClass()) return false;//null이면 false, getClass를 통해 클래스 타입확인
        Person person = (Person) o; //o가 Person타입임이 확인 -> Person타입으로 다운캐스팅
        return age == person.age && Objects.equals(name, person.name);
        }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

public class Main {
    public static void main(String[] args) {
        Person person1 = new Person("John Doe", 27);
        Person person2 = new Person("John Doe", 27);

        boolean equals = person1.equals(person2);
        System.out.println(equals);
    }
}

출력
Override 전 : false
Override 후 : true

equals()를 오버라이딩하는 과정에서 마지막에 실질적인 비교를 할때

a.equals(b) 를 사용하면 a가 null 인 경우 NullPointerException 발생 가능

⇒ Objects.equals(a, b) 는 null를 자동으로 처리해 안전하게 비교가능

왜 hashCode()를 함께 오버라이딩 해야하는가

• hashCode()는 객체를 해시기반 컬렉션(HashMap, HashSet …)에 저장하거나 비교할 때 사용
• equals()만 오버라이딩하면 논리적으로 같은 객체가 다른 해시코드를 가질 수 있음.

⇒ 결과적으로 논리적으로 같은 객체(모든 필드의 값이 같은 객체)를 컬렉션에 중복 저장될 수 있음

문자열 상수

사실 같은 값을 가지고 있는String타입들을 비교하면 == 연산자를 통해서도 true 가 반환된다.

그렇다면 equals() 를 오버라이딩해야하는 이유가 없지 않은가!

자바에서는 문자열(String)을 효율적으로 관리하기 위해서 문자열 상수 풀이라는 메모리 영역을 사용한다.

문자열 상수풀은 Heap영역에 일부로, 동일한 문자열 리터럴을 재사용하여 메모리 낭비를 방지한다.

⇒ 즉 같은 값을 가진 String 객체들은 그 하나의 객체만을 재사용하여 참조한다.

public class Main {
    public static void main(String[] args) {
        String str1 = "Hello";
        String str2 = "Hello";

        boolean areTheySame = str1==str2;

        System.out.println(areTheySame); //ture
    }
}

하지만 new 키워드로 String 객체를 생성하면 Heap 영역에 새로운 객체가 생성된다.

⇒ 다른 객체를 참조하게 되어 == 연산자로 비교하면 false 반환

public class Main {
    public static void main(String[] args) {
        String str1 = new String("Hello");
        String str2 = new String("Hello");

        boolean areTheySame = str1==str2;
        boolean theValuesAreSame = str1.equals(str2);
        System.out.println(areTheySame); //false
        System.out.println(theValuesAreSame); //true
    }
}

따라서 이럴 땐 equals()를 사용하여 객체의 값을 비교해야한다.

Comparable / Comparator

Comparable

• 클래스 자체에서 정렬 기준을 지정(기본 정렬기준 지정)
• compareTo() 메소드를 오버라이딩하여 정의
• Collections.sort() , Arrays.sort()를 사용하면 자동으로 정용

public class BodyBuilders implements Comparable<BodyBuilders> {
    protected String name;
    protected int age;
    protected int volume;

    public BodyBuilders(String name, int age, int volume) {
        this.name = name;
        this.age = age;
        this.volume = volume;
    }

    @Override
    public int compareTo(BodyBuilders o) {
        return Integer.compare(this.volume, o.volume);
    }

    @Override
    public String toString() {
        return
                "name='" + name + '\'' +
                ", age=" + age +
                ", volume=" + volume +
                '}';
    }
}

public class Main {
    public static void main(String[] args) {
        List<BodyBuilders> builders = new ArrayList<>();
        builders.add(new BodyBuilders("John", 20, 20));
        builders.add(new BodyBuilders("Tom", 23, 28));
        builders.add(new BodyBuilders("Jack", 28, 30));
        builders.add(new BodyBuilders("Jane", 31, 18));

        System.out.println(builders);
        builders.sort(null); //Collections.sort(builders);
        System.out.println(builders);
    }
}

public int compareTo(BodyBuilders o) {
        return Integer.compare(this.volume, o.volume);
    }

이 부분을 내림차순으로 하고 싶다면

public int compareTo(BodyBuilders o) {
        return Integer.compare(o.volume, this.volume);
    }

이렇게 둘의 순서를 바꿔주면 된다.

왜냐하면

Integer.compare() 은

public static int compare(int x, int y) {
    return (x < y) ? -1 : ((x == y) ? 0 : 1);
}

이렇게 생겨먹었다.

• o1이 o2 보다 작으면 음수(x와 y의 위치를 유지) : o1 - o2 = 음수
• 두 값이 같으면 0
• o1이 o2보다 크면 양수(x와 y의 위치를 바꿈) : o1 - o2 = 양수

그러므로 비교 순서를 바꾸면 내림차순으로 정렬 된다.

이는 Comparator의 compare()에도 동일하게 적용된다.

Comparator

• 기본 정렬과 다른 정렬기준을 정립
• compare() 메소드를 오버라이딩하여 정의
• 클래스 자체의 변경없이 여러 정렬 기준을 만들 수 있음(클래스 외부에서 구현)

public class BuilderComparator implements Comparator<BodyBuilders> {
    @Override
    public int compare(BodyBuilders o1, BodyBuilders o2) {
        return Integer.compare(o1.age,o2.age);
    }
}

public class Main {
    public static void main(String[] args) {
        List<BodyBuilders> builders = new ArrayList<>();
        builders.add(new BodyBuilders("John", 45, 20));
        builders.add(new BodyBuilders("Tom", 23, 28));
        builders.add(new BodyBuilders("Jack", 28, 30));
        builders.add(new BodyBuilders("Jane", 31, 18));

        System.out.println(builders);
        builders.sort(new BuilderComparator()); //Collections.sort(builders, new BuilderComparator);
        System.out.println(builders);
    }
}

다중정렬

builders.sort((o1, o2) -> {
            if(o1.age == o2.age) {
                return Integer.compare(o2.volume, o1.volume);
            }
            return Integer.compare(o1.age, o2.age);
        });

이 방법이 지금의 나에겐 가장 현실적인 방법 같다.

밑의 두 방법은 아직 나에겐 무리다.. 미래를 기약하겠다.

userGuild.sort(
        Comparator.comparing(
                (Character c) -> c.getGold(), Comparator.reverseOrder()
        ).thenComparing(
                (Character c) -> c.getLevel()
        )
);

userGuild.sort(
        Comparator.comparing(
                Character::getGold, Comparator.reverseOrder()
        ).thenComparing(
                Character::getLevel
        )
);

Annotation

• 컴파일러가 읽을 수 있는 주석이라고 말할 수 있음
• 자바파일에서 클래스파일로 바뀌어도(컴파일이 끝나도) 유지된다.
• 일반주석은 사람에게 코드를 설명하는 용도와 비슷하게 Annotation은 프로그램(컴파일러, 런타임)에게 코드를 설명하는 역할을 수행한다.
• Annotation에 값을 넣어 줄 수 있다.

표준(내장) Annotation

자바가 기본적으로 제공하는 어노테이션이다.

1. @Override

   오버라이딩을 올바르게 했는지 컴파일러가 체크하게 한다.

2. @Deprected

   앞으로 사용하지 않는 것을 권장함.

    @Deprecated
    public class TrashClass {
   
        @Deprecated
        public void trash() {
            System.out.println("Trash");
        }
    }

   @Deprecated를 붙은 클래스나 메소드를 사용하려고 하면 밑줄따위가 그어지며 사용하지 않을 것을 권장한다.

3. @FunctionalInterface

   함수형 인터페이스가 하나의 추상메서드만 가지고 있는지를 확인한다.

   이는 람다을 사용하기 위해서 필요한 개념이다.

1. @SuppressWarnings(무시할 경고)

   컴파일러의 경고메세지를 무시한다.

   "unchecked", “deprected” , "all" 등이 올 수 있다.

메타 Annotation

어노테이션을 위한 어노테이션

1. @Target

   어노테이션을 정의할 때, 적용대상을 지정

   @Target({ElementType.TYPE, ElementType.METHOD}) 이런식으로 사용

2. @Retention

   어노테이션의 유지기간을 지정

   • Runtime 클래스 파일에도 존재, 실행시 사용가능(값 호출 가능)

   • Source 컴파일되면 사라짐 (걍 주석)

     @Rentention(RetentionPolicy.SOURCE) 사용 예

그 외. @Documented, @Inherited, @Repeatable 등..

어노테이션 생성

@Target({ElementType.FIELD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface TargetTest {
    String name() default "Test";
    int testCnt();
}

Reflection

• 리플렉션은 힙 영역에 로드된 Class 타입의 객체를 통해, 원하는 클래스의 인스턴스를 생성
• 인스턴스의 시그니쳐에 접근 제어자와 상관없이 접근이 가능하도록 하는 API

런타임(실행 시간)에 클래스, 메서드, 필드 등의 정보를 조회하고 조작할 수 있는 기능을 의미합니다.

⇒ 실행 중에 객체의 구조를 분석하고 동적으로 변경

JVM의 클래스 로더에서 클래스 파일에 대한 로딩을 완료 후 해당 클래스의 정보를 담은 Class 타입의 객체를 생성 후 힙 영역에 저장 → new키워드로 만드는 객체 와는 다르다.

Class 객체 로드 방법

1. 클래스 이름으로 Class 객체 가져오기

   Class<?> cl1 = Example.class;

2. 객체를 통한 Class 객체 가져오기

   Example example = new Example();

   Class<?> cls2 = example.getClass();

1. 클래스 이름을 문자열로 가져오기

   Class<?> cls3 = Class.forName("Example");

   • 클래스 이름을 문자열로 다룰 수 있기 때문에 동적으로 로딩이 가능.

Example example = new Example();
Class<?> cls2 = example.getClass();

여기서 나는 저 example 객체와 cls2 객체가 다른건가라는 생각을 했다.

결과적으로 다르다.

• example객체는 Example클래스의 실제 객체
• cls2객체는 Example의 클래스 메타정보를 가지고 있는 Class<?>의 객체이다.

여기까지 난 특정 클래스의 정보를 가지고 있는Class 객체를 생성?불러와서 이 객체를 통해서 특정 클래스의 정보를 가져올 수 있구나로 이해했다.

근데 왜 이게 되는거지가 궁금해서 좀 찾아보니 다음과 같은 과정으로 설명할 수 있을 거 같다.

1. A라는 클래스를 생성하면 JVM이 A클래스의 정보를 메소드 영역에 저장한다
2. Class 객체를 생성하면 Class 객체가 Heap영역에 로드되고, 메모리 영역에 있는 A클래스의 정보를 참조한다.

이제야 좀 이해가 되는 거 같다. 근데 의문점이 있다. 어째서 Class객체는 메타데이터의 접근제어자를 무시하는가..

⇒ 좀 찾아보니 JVM내부적으로 setAccessible(true)를 사용해서 접근 제한을 해제한단다.. 너무 딥해지니 이제 그만알아보자..

주요 메서드

클래스 관련

• getName() : 클래스 전체 이름 (패키지 포함)
• getSimpleName() : 클래스 이름 (패키지 제외)
• getPackage() : 패키지정보
• getSuperclass() : 부모클래스 정보
• getInterfaces() : 클래스가 구현한 인터페이스 정보

생성자 관련

• Constructor<?>[] constructor = cls.getConstructors(); : public 생성자들을 배열의 형태로 가져옴
• Constructor<?>[] constructor = cls.getConstructor(String.class); : 특정 매개변수 생성자 가져오기
• Constructor<?>[] constructor = cls.getDeclaredConstructors(); : private 생성자도 가져
• Object obj = constructor.newInstance("어쩌고"); : 생성자를 이용해 객체 생성

필드 관련

• Field[] fields = cls.getFields() : 필드 배열 가져오기

  • Field field = cls.getField("필드명") : 특정 public 필드 가져오기

• getDeclaredFields() : 모든 필드 가져오기

• getDeclaredField("필드명") : 특정 private필드 가져오기

• get(obj) : 객체의 필드 값을 가져옴(인스턴스 → 객체 필요, Static필드 → 객체 불필요)

• set(obj, "필드이름") : 필드값 변경

메소드 관련

• invoke(obj) : 매개변수 없는 메서드 실행
• invoke(obj, "매개변수 명", 인자값) : 매개변수 있는 메서드 실행

어노테이션 관련

• isAnnotationPresent(MyAnnotation.class) : 클래스의 모든 어노테이션 가져오기
• getAnnotation(MyAnnotation.class) : 특정 어노테이션 가져오기

클래스들이 구현해야하는 메서드들의 집합

클래스를 만들기위한 기본 뼈대.

추상 클래스 - 구현된 메소드와 필드를 가질수 있음, 단일 상속만 가능

인터페이스 - 메서드의 시그니쳐만 정의(이름, 변환형, 매개변수), 다중 상속 가능

인터페이스내의 메서드는 public과 abstract로 간주(생략가능)

인터페이스는 상수만 가질 수 있음(public, static, final로 자동으로 선언)

public interface TestInterface {
    int a = 0;  //자동으로 public static final

    public abstract void testMethod();
    void testMethod2(); //기본적으로 public abstract 간주
}

인터페이스가 public과 abstract 만 가능한 건 아님

default와 static은 가능

• default : 인터페이스 내에서 구현이 가능(override도 가능)
• static : 인터페이스 내에서 구현이 가능하나 재정의 불가능(override 불가)

public interface TestInterface {
    default void defaultTestMethod() {
        System.out.println("Default Method is available in Interface");
    }

    static void staticTestMethod() {
        System.out.println("Static Method is also available in Interface");
    }
}

package lec1.test.review;

public class TestClass implements TestInterface {

    @Override
    public void defaultTestMethod() {
        System.out.println("Default Method is available to override");

        TestInterface.super.defaultTestMethod(); //super키워드를 통해 인터페이스 내의 default메소드 호출 가능
    }

}

package lec1.test.review;

public class TestMain {
    public static void main(String[] args) {
        TestClass t = new TestClass();

        t.defaultTestMethod(); //Override된 메소드 호출
        TestInterface.staticTestMethod(); // Static이므로 인터페이스 이름을 통해 바로 접근 가능
    }
}

클래스가 여러 인터페이스를 구현가능(like 다중상속)

class A implements intesrfaceA, interfaceB

interface C extends interfaceA, interfaceB

인터페이스가 인터페이스를 다중상속가능

단, 이를 구현하는 class는 모든 메서드를 구현해야한다.

인터페이스 구현과 클래스 상속을 동시에 받는 겨우

class a extends b implements c

//c : void sleep();, method1();
//b : public void sleep();

클래스의 메서드가 인터페이스의 메서드보다 우선

c에 있는 sleep()을 b가 구현하고 a가 b를 상속받는다.

⇒ a는 method1()만 구현하면 된다. (부모클래스가 인터페이스를 이미 구현하고 상속한걸로 인식)

캐스팅

• 다운캐스팅 - 부모 객체를 자식 객체로 변환( 문제가 자주 일어남)
• 업캐스팅 - 자식 객체를 부모 타입으로 변환 (문제 거의 없음)

Inner Class

inner class는 outer 클래스의 멤버로 정의

inner class에서 outer변수는 사용이 가능하다

(변수명이 같다면 inner우선 ⇒ this.변수명이 자동으로 붙음)

outer변수를 사용하려면 outer클래스명.this.변수명 으로 사용

outer class에서 inner class의 변수에는 접근이 불가능(static 제외)

⇒ inner class의 객체를 생성후에 접근해야함

inner class의 인스턴스를 생성하려면 outer class의 인스턴스를 먼저 생성해야함

OuterClass out = new OuterClass();
OuterClass.InnerClass in = out.new InnerClass();

OuterClass.InnerClass in2 = new OuterClass().new InnerClass();

Static Inner Class

Outer class의 인스턴스와 독립적으로 존재

Outer class의 정적멤버에만 접근이 가능

Outer class의 인스턴스 없이 독립적으로 생성가능

Inner Class의 메모리 누수

static이 아닌 inner class는 메모리 누수를 일으킬 우려가 있음

일반 Inner Class는 Outer Class에 대한 참조를 유지하기 때문

Inner Class의 인스턴스가 생성되는 순간 Outer 클래스의 참조를 가진다.

⇒ Outer Class의 this 참조를 자동으로 포함하기 때문에 Outer class가 더이상 필요 없더라고 GC가 이를 해제하지 못함

⇒ Inner class의 객체가 Outer class의 객체보다 오래 유지되면 메모리 누수 발생 가능

public class OuterClass {
    private int ramdomNumber = 45678;

    public int getRamdomNumber() {
        return ramdomNumber;
    }

    public class InnerClass {
        public void trash() {
            System.out.println(ramdomNumber + "is still available");
        }
    }

}

public class TestMain {
    public static void main(String[] args) {
        OuterClass outerInstance = new OuterClass();
        OuterClass.InnerClass innerInstance = outerInstance.new InnerClass();

        System.out.println(outerInstance.getRamdomNumber());
        innerInstance.trash();
        outerInstance = null;
        //System.out.println(outerInstance.getRamdomNumber());
        innerInstance.trash();
    }

}

출력: 
45678
45678is still available
45678is still available

Outer 인스턴스가 null 로 변하고 나서도 Inner 인스턴스는 값을 계속 참조하여 호출이 가능함 → 메모리누수!

💡

메모리 누수를 방지하기 위해 특별한 경우가 아니라면(외부클래스의 멤버 사용 등) static으로 생성 요망

객체지향의 특징

• 캡슐화(Encapsulation)

  • 객체의 데이터와 메서드를 하나로 묶어 외부로부터 정보를 은닉하는 원칙
  • 객체가 제공하는 공용 메서드를 통해서만 조작가능
  • 접근제어자를 통해 구현될 수 있음

• 상속(Inheritance)

  • 부모클래스의 속성과 메소드를 자식클래스가 물려받아 사용할 수 있도록 하는 원칙
  • 코드의 재사용성 증가, 객체간의 관계가 명확하짐

• 다형성(Polymorphism)

  • 동일한 이름의 메서드를 다양한 형태로 구현하는 기능(Overloading, Overriding)
  • 오버로딩
    • 같은 이름 - 다른 매서드 시그니쳐(매개변수 타입, 개수 등)
  • 오버라이딩
    • 상속받은 메서드를 자식 클래스에서 재정의

• 추상화(Abstraction)

  • 복잡한 시스템내의 중요한 부분만 강조, 세부사항은 숨기는 것
  • 추상 클래스, 인터페이스로 추상화 구현

객체

객체는 데이터와 메서드를 하나로 묶은 실체로 상태와 행동으로 구성

클래스

객체의 설계도로 생각할 수 있다.

객체의 상태를 나타낼 수 있는 필드와 행동을 나타내는 메서드로 구성

이름은 대문자로 시작

• 정적변수(Static) : 클래스 자체에 속하여 모든 객체가 공유하는 변수
  • 클래스가 메모리에 올라갈때 같이 적재(클래스 멤버 변수) → 클래스에서 직접 참조 가능
• 인스턴스변수 : 인스턴스별로 독립적으로 가지는 변수

인스턴스

인스턴스는 클래스을 바탕으로 생성된 객체이다.

new 키워드로 생성

생성자

객체를 초기화하는 메서드

객체의 초기 상태를 설정한다.

• 생성자가 오버로딩되어 있지 않고 없는 상태면 컴파일러가 기본생성자를 자동 생성한다.
  • 사용자지정생성자가 하나 있으면 이 생성자가 기본생성자의 역할을 함(매개변수는 맞춰줘야 한다.)
• 생성자의 이름은 클래스의 이름과 같아야한다.
• 변환타입X

this

객체 자신을 참조하는 키워드

객체의 필드를 참조

public class Test{
    private int age;

    public howOld(int age){
        this.age = age;
    }
}

위와 같은 예일때 메서드의 매개변수 age와 필드 age를 구분하기 위해 this.age를 사용하여 객체자신을 참조한다.

생성자 체이닝(Constructor Chaining)

this로 같은 클래스의 다른 생성자를 호출 할 수 있다.

예를 들어 매개변수가 없는 생성자를 호출 했을때

this.(0,0) 이런식으로 다른 생성자를 호출하면 필드에 0값이 들어가게 된다.

스코프(Scope)

변수나 메서드에 접근할 수 있는 범위를 뜻한다.

• 클래스 스코프
• 메서드 스코프
• 블록 스코프
• 매개변수 스코프
• 정적 영역 스코프
  • 클래스의 모든 인스턴스가 공유한다.

• f2 : 변수이름을 바꿨을때 오류가 발행하는 위치로 순간이동(바꿔야 하는 곳을 찾기가 쉽다.)
• shift + f6 : 리팩토링(모든 관련 참조가 함께 변경 안전하게 변수이름을 바꿀 수 있다)
• ctrl + alt + v : 변수 추출 같은 원리로 클래스(c), 메소드(m)도 가능!

제어문

선택문

if, else if, else

• if문은 주어진 조건이 참이면 해당 블록을 실행.

if (조건식 or 값) {
    본문
}

• else if는 여러 개의 조건이 있을때 사용이 가능하다. 조건이 참이 블록을 실행하고 if문을 종료한다.(나머지 조건을 검사X)

if (a >= 6) {
    System.out.println("Too big");
    } else if(a < 6 && a >= 3){
        System.out.println("Good Number");
   }

//출력 : Good Number

• else는 ****어떠한 조건에도 만족하지 않을때 코드블록을 실행.

boolean isClassFinished = false;

if (isClassFinished) {
    System.out.println("Let's go to workout!!");
    } else{
        System.out.println("Hang on...");
        }

Switch

• if문과 비슷하나 case에 부합하는 값이 들어오면 해당 case문을 실행하고 그 아래의 모든 case를 실행시킴
  • break키워드를 사용해 해당 case만 실행 시킬 수 있음
• 모든 case에 부합하지 않을때 default키워드를 사용하여 실행시킴

int number = 2;

switch (number){
  case 1:
      System.out.println("1");
  case 2:
      System.out.println("2");
  case 3:
      System.out.println("3");
  case 4:
      System.out.println("4");
}

//출력
2
3
4

반복문

while

• 조건이 참일 동안 반복적으로 실행되는 제어문

do while

• while과 흡사하지만 do블록의 코드가 무조건 한번은 실행된다.
• do 블록(반복문)실행하고 조건식을 검사한다.

for

• while과는 다르게 반복 수를 명시적으로 제어할 수 있음
• for문의 외부에 있는 변수도 이용이 가능하다(이건 몰랐다..)

int a = 5;
for(; a <= 10; a++){
    System.out.println(a);
}

/* 출력
5
6
7
8
9
10
*/

함수

함수와 메서드

나는 함수와 메서드는 동일하고 용어의 차이인줄 알았는데 미묘한 차이가 있었다.

• 함수
  • 어떤 객체에 속하지 않고, 그자체로 호출된다.
  • 객체와 무관하게 독립적으로 존재
• 메서드
  • 클래스나 객체에 소속되어 있다.

메서드의 정의

접근제어자 반환자료형 메서드이름 (매게변수 ...) {
        본문
}

• 접근제어자 : 메서드에 접근할 수 있는 범주를 정의 → 데이터 은닉화와 캡슐화 강화
• 반환 자료형 : 메서드가 반환하는 자료형을 정의
• 매게변수 : 메서드가 사용할 수 있는 값, 매게변수는 호출 될 때 전달하는 인자값을 정의

접근제어자

가변인자(Vararg)

가변 인자를 사용하여 매개변수의 개수를 동적으로 설정할 수 있다!

public static void main(String[] args) {
        vararg("cat","dog","cow","rat","zebra");
    }

    public static void vararg(String...animals){
        for(String animal : animals){
            System.out.println(animal);
        }
    }

이런게 될 줄은 몰랐다. 나만 신기했나.. 난 너무 신기했다.

오버로딩

같은 이름을 가지는 메소드들을 여러개 정의 하는 것

단, 각 매서드의 매개변수의 타입이나 개수, 순서가 다르게 정의해야 한다.

반환 타입만으로는 오버로딩X

• 메서드 시그니쳐 : 메서드를 구별하는데 필요한 정보
  • 반환타입은 메서드 시그니쳐가 아니므로 메서드의 구별에 영향이 없다.

• 플랫폼 독립성
  • ‘Write Onne, Run Anywhere’원칙을 기반으로 한번 작성된 코드는 다양한 플랫폼에서 실행될 수 있습니다.
  • JVM이라는 중간 계층에서 자바를 실행시키므로 다른 운영체제에 JVM만 설치되어있다면 자바가 실행 가능
• 객체 지향 프로그램
  • 자바는 대표적인 객체 지향 프로그래밍 언어이다.
  • 코드의 재사용성과 확정성이 뛰어남

자바의 구성

• JDK(Java Development Kit)
  • 자바 애플리케이션을 개발하기 위한 도구의 모음
  • 컴파일러, 디버거, 자바API등이 포함
  • 자바 컴파일러(javac)는 자바 코드를 바이트코드로 컴파일하여 JVM에서 실행될 수 있도록 함
  • 자바 표준라이브러리를 통해 내장된 클래스나 매서드를 활용할 수 있게 함
• JRE(Java Runtime Environment)
  • 자바 애플리케이션을 실행하기 위한 환경 제공
  • JRE는 JVM과 자바 표준 라이브러리로 구성
  • 자바 실행을 위한 모든 요소를 포함(개발도구 X)
• JVM(Java Virtual Machine)
  • 자바 프로그램 실행 환경을 제공하는 핵심 구성요소
  • 바이트코드(.class 파일)을 읽고 해석 → 기계어로 변환
  • 메모리관리, 가비지 컬렉션, 쓰레드 관리 등의 기능

자료형과 메모리

원시 자료형(Primitive Data Types)

직접적으로 메모리의 특정 위치에 값을 저장

값으로써 직접 사용이 가능하다. 객체가 아님

정수 자료형

• byte

  • 1byte의 크기
  • -128부터 127까지의 정수 표현가능

• short

  • 2byte의 크기
  • -32,768부터 32767까지의 정수 표현가능

• int

  • 4byte의 크기

  • --2,147,483,648부터 2,147,483,647까지의 정수 표현 가능

  • 다양한 진수별 값 할당 가능

    int a = 0;
    int b = -1;
    int c = 0b1110; // 14(2)
    int d = 012; // 10(8) (앞에 0을 써줌으로써 8진수임을 표현)
    int e = 10;  // 10
    int f = 0xA; // 10(16)

• long

  • 8byte의 크기
  • -9,223,372,036,854,775,808부터 9,223,372,036,854,775,807까지의 정수 표현 가능;;
  • 값 할당시 할당될 값 뒤 L 을 입력해야함 long hugeNumber = 100_000_000_000L;

참고로 정수형 자료형에선 값에 언더바(_)을 사용하여 가독성을 높힐 수 있음

int justNumber = 1_000_000_000;
short smallNumber = 10_000;

실수 자료형

• float
  • 4byte의 크기
  • 약 6~7자리의 십진수 정밀도
  • double보다 정밀도가 낮아 정밀한 계산에서는 부적절
  • long과 비슷하게 값을 할당시 f를 덧붙여야함 float pi = 3.14f;
• double
  • 8byte의 크기
  • 약 15자리수의 정밀도 제공
  • float보다 정밀도가 큼

문자 자료형

• char

  • 2byte의 크기

  • 유니코드를 기반으로 문자를 저장

  • 작은 따옴표 사용(’)

    char a = '\uC548';
    char b = '\uB155';
    char c = '\uD558';
    char d = '\uC138';
    char e = '\uC694';
    
    System.out.printf("%c%c%c%c%c",a,b,c,d,e); // 안녕하세요

논리 자료형

• boolean
  • 참 or 거짓을 표현
  • 파이썬과 달리 소문자로 써야함.. 맘에 안듬

참조 자료형

• 참조 자료형은 객체를 참조하기 위해 사용된다.
• 기본자료형(원시자료형)과는 다르게 값이 저장된 메모리의 주소를 저장합니다.
• 힙(heap)영역에 저장된다.
• 참조변수는 힙 메모리의 객체를 가리키는 메모리 주소를 저장
• 가비지 컬렉션이 더 이상 사용되지 않는 객체를 메모리에서 해제 → 메모리 누수 방지 및 효율적인 메모리 사용

Wrapper Class

기본자료형(원시자료형)을 객체로 다룰 수 있게 하는 클래스

자바에선 객체만이 메서드에 인수로 전달, 컬렉션 클래스와 같은 데이터 구조에 저장

byte → Byte

short → Short

int → Integer

long → Long

float → Float

double → Double

char → Character

boolean → Boolean

• 박싱(Boxing) : 원시자료형을 래퍼클래스로 변환
• 언박싱(Unboxing) : 위 과정의 반대

int basicInt = 27;
Integer wrapperInt = Integer.valueOf(basicInt);

int unboxedInt = wrapperInt.intValue();

위 처럼 boxing을 위해선 valueOf를 사용하고

unboxing은 intValue를 사용하여 가능

JVM

JVM은 메모리를 영역들로 나누어 관리

메서드 영역(Method Area)

• 클래스의 메타데이터를 저장하는 공간(클래스 이름, 상위 클래스, 인터페이스 etc.)
  • 클래스와 메서드의 구조적 정보(클래스 정보, 메서드 코드, 정적 변수, 상수 풀) 저장
• 모든 스레드가 공유
• 프로그램 실행 동안 클래스 정의와 메서드 정의 유지

힙 영역(Heap Area)

• 동적으로 생성된 객체와 배열을 저장하는 공간
• 가비지 컬렉션에 의해 관리 → 더 이상 참조되지 않는 객체를 해제
• 프로그램 메모리 사용량 조절 / 데이터 저장과 관리

스택 영역(Stack Area)

• 스레드마다 별도로 할당
• 메서드 호출과 관련되 지역변수, 매게변수 저장
• 메서드 호출 시 스택 프래임이 생성, 종료되면 스택 프레임 제거
• LIFO방식으로 관리, 지역 변수와 메서드의 실행 정보 저장
• 메서드 호출의 효율적인 관리, 메모리 할당의 자동화

네이티브 메서드 스택 영역(Native Method Stack)

• 자바 외부에서 작성된 네이티브 메서드 호출 시 사용
• 자바 네이티브 인터페이스를 통해 C나 C++로 작성된 네이티브 코드를 실행할 때 필요한 메모리 공간 제공
• 자바와 네이티브 코드 간의 상호작용을 지원
• 외부 시스템과 상호작용 필요시 사용

연산자

Shift연산자

좌측 Shift

비트열을 왼쪽으로 지정된 수 만큼 이동(오른쪽 빈 자리는 0으로 채운다) → 결과적으로 2의 제곱수로 곱하는 결과 도출

int a = 7; // 0111
int leftShifted = a << 1; //1110(14)

우측 Shift

좌측 Shift와 동일하게 비트열을 오른쪽으로 이동(왼쪽 빈 자리는 원래의 부호 비트로 채움) → 결과적으로 2의 제곱수로 나눗셈하는 결과

int a = 12; // 1100
int rightShifted = a >> 1; //0110(6)

부호 없는 우측 Shift

우측 Shift와 흡사하나 왼쪽 빈자리를 0으로 채움 → 부호 비트를 무시

int a = -20;  // 1111 1111 1111 1111 1111 1111 1110 1100 
int result = a >>> 2;  // 0011 1111 1111 1111 1111 1111 1111 1011 

연산자의 우선순위

외울 필욘 없을거 같다.

• readme.md: 프로젝트를 소개하거나 여러 안내사항을 기록할 수 있다.
• HTML코드도 적용 가능
• 직관적이고 가독성이 뛰어나다 무엇보다 이쁜거 같다.

Markdown 문법

제목(Header)

# 제목 1
## 제목 2
### 제목 3
#### 제목 4
##### 제목 5
###### 제목 6

제목 1

제목 2

제목 3

#의 개수가 많을수록 작아진다. 플랫폼마다 지원하는 header에 차이가 있다. 노션에서는 ###까지 지원.

글자 서식

**굵은**
*기운*

굵은

기운

굵고 기운

코드

`print("Hello, World!")`

print("Hello, World!")

한줄짜리 코드를 나타낼 수 있음. 강조의 의미로써도 사용가능.

def solution(): print("Good Day")

def solution():
    print("Good Day")

여러줄의 코드를 나타낼 수 있음.

목록

- 목록 1
- 목록 2

 1. 숫자 목록 1
 2. 숫자 목록 2

• 목록 1
• 목록 2

1. 숫자 목록 1
2. 숫자 목록 2

체크 박스

[x] checked
[] unchecked

• checked
• unchecked

링크

[표시 될 텍스트](url주소)

내 블로그

이미지

![대체 텍스트](이미지 주소)

인용문

> 시간이 곧 금이다.

시간이 곧 금이다.

참고로 노션에서 토글로 작동하는 것 같다. 노션에선 /quote를 사용하도록 하자.

표

|항목 1|항목 2|항목 3|
|---|---|---|
|뭐시기|거시기|요시기|

개행

  (스페이스 두개) 
  or
  <br/>

노션에선 안먹지만
이곳에선 먹는다. 스페이스 두 개는 벨로그에서도 작동이 안됩니다.

git & github

git : 버전 관리 시스템으로 소스코드의 변경사항을 효율적으로 관리함으로써 효율적인 협업을 가능케하는 도구

github: git의 로컬 저장소을 원격 저장소(remote repository)에 호스팅해주는 플랫폼

명령어

기본 명령어

• git init : 새로운 git 저장소 생성
• git add [파일명] : 특정파일을 스테이징(git이 변경사항을 추적하는 것) -commit이 가능
• git status : 현재 저장소의 상태를 확인(스테이징 에어리어 확인 가능)
• git commit -m "메세지" : 변경사항을 커밋함.
• git log : 커밋 히스토리 확인

브랜치(Branch)

브랜치(Branch) : 코드 변경을 독립적(병렬적)으로 진행할 수 있도록 하는 기능입니다.

• git branch : 현재 브랜치 목록 확인
• git branch [브랜치명] : 새 브랜치 생성
• git checkout [브랜치명] : 해당 브랜치로 이동(HEAD 이동)

브랜치 합치기(Merge, Rebase)

A---B---C  (main)
        \
         D---E (feature-branch)

위와 같은 커밋 히스토리를 가진 브랜치가 있을때

• Merge : 두 개의 브랜치를 병합하여 기존 커밋 히스토리를 유지하면서 새로운 커밋을 생성

    A---B---C---M  (main)
         \       /
          D---E (feature-branch)
  

• Rebase : 커밋을 재배열하여 히스토리를 깔끔하게 만듬(기준이 되는 브랜치의 다른 브랜치의 커밋히스토리를 덮어씌움)

    A---B---C---D'---E'  (feature-branch)

각 브랜치에서 같은 파일의 같은 부분을 수정했을때 충돌발생 가능

즉 git이 어느 변경 사항을 유지해야 할지 결정 불가 일 때.

원격 저장소

• git remout -v : 원격 저장소 목록 확인

• git remote add [별칭] [URL] : 원격 저장소 추가

• git remote remove [별칭] : 원격 저장소 제거

• git push [별칭] [브랜치명] : 원격저장소에 로컬저장소를 업로드

• git pull origin [브랜치명] : 로컬저장소에 원격저장소를 다운로드

• git fetch : pull과 흡사하나 병합하지 않음

git 연습

https://learngitbranching.js.org/?locale=ko

평소와 같이 백준문제를 풀던 중 "IOIOI"라는 강렬한 제목에 이끌려 도전했다. 긴 문자열에서 패턴 문자열이 총 몇 번 포함되어 있는지 구하는 문제였다. 단순히 브루트포스로 문제를 풀었더니 이런 세상에 50점 따리를 맞고야 말았다.. 100점을 맞고 싶었던 나는 질문게시판을 돌아다니며 힌트를 찾으려 했고 그렇게 해서 KMP알고리즘의 존재를 알았다. 하지만 안타깝게도 나의 감자대가리는 이를 이해하는데 오랜시간이 걸리고야 말았다. 이글은 KMP알고리즘을 본인 스스로 완전히 이해하려하는 몸부림이다.

패턴매칭

패턴매칭이란 전체 문자열에서 특정한 문자열(패턴)을 찾는 것을 말합니다. 예를 들어 "ABCDAB"라는 전체문자열에 "AB"라는 문자열 즉 패턴을 찾는 것을 말합니다.

예를들어, 우리는 인터넷을 돌아다니며 나오는 모든 긴 글들을 다 읽을 용기가 없을 때 우리는 Ctrl + F를 입력해서 찾고싶은 키워드를 찾곤합니다.

근데 이 작업을 단순하게 하나하나 비교하는 브루트포스를 사용하여 구현하한다면 논문같이 긴 문자열 등에는 시간이 정말 오래 걸릴겁니다. 정말 화가 나겠죠

그래서 타켓 문자열이 길거나 찾을 패턴의 길이가 길수록 빠르고 효율적인 패턴매칭 알고리즘이 요구됩니다.

여러 패턴매칭 알고리즘이 있지만, 오늘은 브루트포스와 KMP알고리즘에 대해서만 설명하겠습니다.

브루트포스(Brute Force)

Brute = 짐승같은, 난폭한 Force = 힘, 폭력 즉 브루트포스는 무식하게 하나하나 대입하여 원하는 것을 찾는 알고리즘? 입니다. 아주 직관적인 방법이죠. 저는 정보보호학과를 나와서 브루트포스를 암호해독으로 처음 배웠습니다.

짧게 예를 들면 만약에 영문 소문자로만 이루어진 "iloveyou"라는 8자리 비밀번호가 있다고 칩시다. 근데 해커가 이 사람의 비밀번호가 영문소문자로만 이루어져 있고 8자리라는 걸 알고있습니다. 그래서 이 해커는 생각하는게 귀찮은 나머지 그냥 영어소문자로 만들수 있는 모든 8글자의 조합을 전부 시도합니다. 아주 무식하지만 아주 오랜 시간이 지나면 비밀번호를 알 수 있겠죠. 그래서 비밀번호를 충분히 길고 여러 요소를 섞으라고 하는겁니다...

이렇게 모든 조합가능한 수를 모두 대입하는 걸 브루트포스라고 합니다.

브루트포스는 당연하게도 패턴매칭에도 사용할 수 있습니다.

• 전체 문자열이 "AAABABC"
• 찾을 패턴이 "BC"라고 해보겠습니다.

처음으로 패턴의 처음 문자와 전체 문자열의 처음을 비교합니다. 처음부터 다르므로 패턴의 첫 문자를 전체 문자열의 다음 인덱스로 이동합니다.

또 다르죠? 다르므로 위와 같은 방식으로 패턴의 첫 문자가 일치할때까지 전체 문자열의 다음 인덱스로 이동합니다.

드디어 패턴의 처음과 일치하는 인덱스로 도착했습니다. 이제 패턴의 두번째 문자열이 전체 문자열의 다음 인덱스와도 같은지 확인합니다. 아쉽게도 패턴의 두번째 문자는 일치하지 않는군요.. 이제 패턴의 처음 문자를 또다시 비교합니다. 다르므로 반복합니다.

다시 패턴의 첫 문자와 일치하는 곳을 찾았습니다. 이어서 패턴의 두번째 문자를 비교해야합니다.

드디어 전체 문자열에서 패턴이 매칭되는 곳을 찾았습니다.

이렇게 전체문자열의 처음부터 끝까지 패턴의 한 문자씩 비교하며 패턴이 매칭되는 곳을 찾는 무식한 방법이 브루트포스입니다.

브루트 포스: 시간복잡도

전체문자열의 길이를 N, 패턴의 길이를 M이라고 할때

최악에 경우 N만큼 패턴의 첫 문자와 일치하는지 확인하는 시간 복잡도가 O(N), 위의 작업을 할 때마다 M만큼 매칭되는지 확인하는 시간 복잡도가 O(M)이기에 브루트 포스을 이용한 패턴매칭의 시간 복잡도는 O(N*M)입니다.

이는 문자열의 길이가 길면 길수록 패턴매칭에 소요되는 시간이 곱으로 늘어남을 뜻합니다. 그래서 제가 "IOIOI"문제를 50따리를 맞았습니다.

브루트 포스: Python 구현

브루트포스를 이용해서 매칭된 횟수와 매칭이 된 위치를 반환하는 패턴매칭 함수를 python으로 구현하면 아래와 같습니다.

def brute_force(target, pattern):

    t_idx, p_idx = 0,0  #전체 문자열의 인덱스, 패턴문자열의 인덱스 
    matched_idx = []    #패턴이 매칭된 전체문자열의 인덱스 값 저장하는 리스트
    cnt = 0             #매칭된 횟수 기록
    N, M = len(target), len(pattern)

    for idx in range(N-M+1):
        t_idx = idx

        #전체 문자열과 패턴이 일치하면 while문 실행행
        while target[t_idx] == pattern[p_idx]:
            if p_idx == M-1: 
                #패턴의 마지막 인덱스의 값까지 매칭되면 매칭이 시작된 전체문자열의 인덱스를 리스트에 저장
                matched_idx.append(t_idx)
                cnt += 1    #매칭된 횟수 +1
                break

            t_idx += 1  #전체문자열의 인덱스와 패턴의 인덱스 모두 +1
            p_idx += 1

        p_idx = 0   #매칭되지 않았다면 패턴의 인덱스값을 0으로 초기화화

    return cnt, matched_idx

print(brute_force("OOIOIOIOIIOII","IOI"))

#출력
(4, [2, 4, 6, 9])

KMP알고리즘

KMP(Knuth–Morris–Pratt)는 별뜻이 있는건 아니고 단순히 만든 사람들 이름을 따온겁니다. like 장덕철

KMP는 패턴의 접두사(prefix)와 접미사(suffix)의 개념을 활용해서 패턴매칭이 이루어집니다. 패턴내에서 접두사와 접미사가 동일한 부분이 있다면 중간에 매칭이 실패했을 때 접미사를 접두사로 봄으로써 반복되는 연산을 접두사와 접미사가 같은 만큼 건너뛸 수 있게 됩니다.

핵심은 매칭이 실패하였을 때 패턴의 처음으로 돌아가는 것이 아니라(브루트포스) 접미사를 접두사로 생각하고 이 둘이 같은 부분부터 다시 패턴매칭을 시작하는 것 입니다.

저도 그랬듯이 글로는 이게 무슨 소린가 싶을 수 있습니다. 정상입니다. 우선 KMP에서 핵심적인 개념인 접두사와 접미사에 관해 아래에서 설명하겠습니다.

접두사(prefix)와 접미사(suffix)

접두사와 접미사의 개념을 어렵지 않습니다. 지금 여러분 머리 속에 떠오른 그것들 입니다.

• 접두사 : 문자열의 앞 쪽 부분문자열

• 접미사 : 문자열의 뒤 쪽 부분문자열

"banana" 라는 문자열로 예를 들면

LPS

LPS는 Longest Prefix which is also Suffix 입니다. 가장 긴 접미사이기도 한 접두사?

말 참 어렵게 만들어 놨는데 이해하기 쉽게 말하면 아래와 같습니다.

문자열의 접두사와 접미사가 동일한 가장 긴 길이

KMP 알고리즘은 패턴의 0번째 인덱스부터 하나씩 길이를 늘려가며 만든 부분문자열의 LPS값을 활용합니다. LPS값을 구하는 과정에서 접두사와 접미사가 겹치는 경우(overlapping)도 포함합니다.

이를 "ABCABABC" 문자열로 예를 들어 설명 하겠습니다. 당연하게도 접두사나 접미사가 부분문자열 전체와 일치하는 경우는 포함하지 않습니다.

• 첫 번째 부분 문자열: A 여기선 접두사가 A, 접미사도 A입니다. 하지만 부분 문자열 전체와 일치하므로 LPS는 0입니다.

• 두 번째 부분 문자열: AB 접두사: A, AB 접미사: B, AB 전체와 일치하는 접두사와 접미사를 제외하기에 LPS는 0입니다.

• 세 번째 부분 문자열: ABC 접두사: A, AB, ABC 접미사: C, BC, ABC 위와 동일한 논리로 LPS는 0입니다.

• 네 번째 부분 문자열: ABCA 접두사: A, AB, ABC, ABCA 접미사: A, CA, BCA, ABCA 길이가 1인 접미사와 접두사가 일치함으로 LPS는 1입니다.

위와 같은 단계를 패턴과 부분문자열이 같을때 까지 진행합니다.

구한 LPS를 배열로 나타내면 아래와 같습니다.

[0, 0, 0, 1, 2, 1, 2, 3]

이렇게 구해진 LPS의 배열을 prefix table혹은 pi(파이)라고 합니다. 이글에선 pi라고 하겠습니다.

참고로 이런 LPS를 구하는 것을 Prefix Function이나 Failure Function이라고 합니다.

LPS: 구현

자 이제 LPS가 무엇인지 알았으니 구현을 해봐야겠죠. 저에게는 이것이 KMP고난의 시작이었습니다.

먼저 코드부터 보고 설명하겠습니다.

def lps(pattern):
    pi = [0 for _ in range(len(pattern))]

    j = 0   #if 접두사와 접미사가 같다면, 접두사의 끝 인덱스 => lps값

    for i in range(1, len(pattern)):    #i = 접미사의 첫 인덱스
        while j > 0 and pattern[j] != pattern[i]:
            j = pi[j-1]

        if pattern[i] == pattern[j]:
            j += 1
            pi[i] = j

    return pi  

print(lps("ABCABABC"))

#출력
[0, 0, 0, 1, 2, 1, 2, 3]

위 코드의 큰 흐름은 다음과 같습니다.

• j는 0에서 시작, i는 1에서 시작하여 비교

• pattern[j]와 pattern[i]가 같다면 j가 1증가하고 pi[i]에 j값 저장 후 i 1증가
• j가 0보다 크고 pattern[j]와 pattern[i]가 다르면 j를 pi[j-1]으로 이동 (j가 0이면 i만 1씩 증가)

여기서 j는 접두사와 접미사가 같다는 가정하에 접두사의 맨 마지막 인덱스 값입니다. 즉 접두사와 접미사가 같다면 j은 곧 lps값이 됩니다.

i는 접미사의 맨 처음 인덱스입니다.

아래서부터 단계별로 그림을 통해서 설명해보겠습니다.

pattern[j]와 pattern[i]가 일치하지 않으므로 해당 부분 문자열의 LPS는 0이다. j가 0이므로 i만 1증가 시킵니다.

pattern[j]와 pattern[i]가 일치하므로 j를 1증가시키고 pi[i]값이 j가 되어 LPS는 1이됩니다. 이후 i또한 1증가시켜 다음 부분문자열을 비교합니다.

pattern[j]와 pattern[i]가 다시 한 번 일치하므로 j를 1증가시키고 pi[i]값이 j가 되어 LPS는 2가 됩니다. 이후 i도 1증가하여 다음을 비교합니다.

또 다시 일치하므로 위와 같은 단계를 거쳐 LPS는 3이 됩니다.

다시 i를 1증가시켜 비교하니 이번엔 pattern[j]와 pattern[i]가 일치하지 않으므로 j를 pi[j-1]인 pi[2] 즉 1로 이동시킵니다.

이동시켰음에도 불구하고 또다시 일치하지 않으므로 j를 또다시 pi[j-1]로 이동시킵니다.

이제는 일치하므로 앞에서와 같이 j를 1증가시키고 j가 LPS값이 되니 pi[i]에 j을 저장합니다.

다음도 일치하므로 j값을 1증가시킨뒤 이 j가 LPS값이 되어 저장됩니다.

값이 일치하지 않으므로 j가 pi[j-1]로 이동지만 마지막 인덱스에서의 비교가 끝났으므로 함수를 종료한다.

위에서 그림을 통해 LPS를 구하는 논리에 대해서 알아봤습니다. 전체적인 흐름은 파악하실 수 있으셨을 겁니다.

근데 저는 개인적으로 일치하지 않을 때 갑자기 j가 pi[j-1]이 되는게 이해가 잘 안되서 자괴감에 빠졌었습니다. 왜 그러한지 제가 더 자세히 설명을 해보겠습니다.

위 그림과 같이 이전 부분 문자열의 LPS가 N인 상태에서 ★과 ♥가 일치하지 않은 경우를 예로 들면

j이전의 N길이의 접두사와 i이전에 N길이의 접미사가 같다는 것을 뜻하므로 pi[i-1] = N입니다. 동시에 j의 인덱스 값은 N이기 때문에 (index는 0부터 시작이므로) j = pi[i-1]이라는 논리가 성립합니다.

위 와 같은 논리로 pi[j-1]이 M이라면 위 그림의 초록색 부분은 모두 같은 문자열입니다. 고로 위 그림에서 화살표시된 곳의 인덱스 값은 M이며 pi[j-1]입니다.

i앞쪽의 M만큼의 문자열과 pi[j-1]앞의 M만큼의 문자열이 동일 하므로 j의 위치를 이곳으로 이동시켜 비교합니다.

정리하면 동일함이 보장되는 곳을 최대한 찾아 활용함으로써 쓸데없는 반복을 줄여 파이배열을 구할 수 있습니다.

Prefix function은 i가 1씩 전진만 하며 비교를 진행하기 때문에 시간 복잡도가 패턴의 길이를 N이라고 했을 때 O(N)입니다.

PI배열의 특성

참고로 알아두면 좋을 거 같아서 소개하는 pi배열의 특성입니다. 소개를 안하기엔 중요한 정보인거 같아서 짧게 소개하겠습니다.

n - pi[n-1]은 반복패턴의 길이 입니다.(n = 문자열의 길이)

위 그림의 n은 7입니다. n - pi[n-1] = 7 - pi[6] = 2 그림에서 확인 할 수 있듯이 반복패턴의 길이가 2인것을 알 수 있습니다. ('AB''AB'AB')

위의 예와 마찬가지로 n - pi[n-1]이 3이므로 반복패턴의 길이가 3인것을 알 수 있습니다.

원리를 간단히 그림으로 설명해보겠습니다.

문자열의 길이인 n의 pi[n-1]값은 문자열의 마지막 LPS값을 뜻합니다.

이는 LPS만큼만 접두사와 접미사가 같다는 것을 의미하므로 길이인 n에서 이를 빼게 되면 전체문자열의 반복패턴의 길이가 나오는 것입니다.

이러한 특성은 KMP알고리즘과는 상관없는 내용이지만 유익한 정보인거 같아 간단히 소개 해보았습니다.

KMP 알고리즘: 구현

위에서 KMP을 이해하기위해 접두사, 접미사의 개념과 LPS의 개념 마지막으로 pi배열의 원리과 구현까지 알아보았습니다. 이제 드디어 KMP를 구현해보고 자세히 뜯어볼 차례입니다. 참 오래 걸렸죠. 사실 KMP는 pi배열의 원리과 매우 비슷합니다.

문자열이 패턴과 일치하지 않는다면 접두사와(prefix)와 접미사(suffix)가 같은 길이만큼 건너뛰어서 매칭을 진행시키기 때문입니다.

KMP알고리즘의 전체적인 흐름은 다음과 같습니다.

• j(패턴 index), i(전체문자열 index)를 0,1로 초기화

• pattern[j] 와 전체문자열[i]를 비교하여 일치하면 j와 i를 1증가 만약, j의 값이 len(pattern)과 같아지면 패턴을 찾은것이므로 이를 저장
• pattern[j]와 pattern[i]가 다르다면 j를 pi[j-1]로 이동

pi배열의 구현과 매우 흡사하지 않습니까. 사실 pi배열 구현의 원리과 KMP는 같은 원리라해도 무방합니다.

이제 코드를 봅시다.

def lps(pattern):
    pi = [0 for _ in range(len(pattern))]

    j = 0   #if 접두사와 접미사가 같다면, 접두사의 끝 인덱스 => lps값

    for i in range(1, len(pattern)):    #i = 접미사의 첫 인덱스
        while j > 0 and pattern[j] != pattern[i]:
            j = pi[j-1]

        if pattern[i] == pattern[j]:
            j += 1
            pi[i] = j

    return pi  

def KMP(target, pattern):
    pi = lps(pattern)   #lps함수로 pi배열 생성성

    match_point = []
    cnt = 0

    j = 0
    for i in range(len(target)):
        while j > 0 and pattern[j] != target[i]:   #j가 0보다 크고 불일치하다면 j를 pi[j-1]로 이동
            j = pi[j-1]

        if pattern[j] == target[i]: #일치한다면 j와 i를 +1
            j += 1
            if j == len(pattern):   #j가 패턴의 길이가 된다면 패턴을 찾았다는 것을 의미하므로 이를 저장장
                cnt += 1
                match_point.append(i-len(pattern)+1)
                j = pi[j-1] #매칭되면 j를 pi[j-1]로 이동하여 계속 매칭시도도


    print(cnt)
    print(match_point)

KMP("OOIOIOIIOIOII","IOIOI")

#출력
2
[2, 7]

자 이제 하나씩 뜯어봅시다.

처음부터 일치하지 않고 j가 0이므로 i만 1 증가시킵니다.

이번에도 일치하지 않는군요. 아직 j가 0이므로 마찬가지로 i만 1 증가시켜줍니다.

드디어 일치하는군요! 일치하므로 i와 j 모두 1씩 증가시켜 계속 비교합니다.

마찬가지로 일치하므로 위와 같이 i, j 1증가 시켜줍시다. 사실 컴퓨터는 아직 모르지만 우리는 그림으로 패턴이 계속 일치해서 target문자열 인덱스 2에서 매칭되는 걸 미리 알 수 있습니다. 그러므로 매칭이 될때까지는 별도의 설명없이 그림만 첨부하도록 하겠습니다.

계속 일치하면서 j가 패턴의 마지막 인덱스위치까지 왔으므로 패턴이 매칭이 되었음을 알 수 있습니다. 그럼 매칭이 되었다는 것을 기록하고 계속 비교를 해야겠죠? 그렇다면 j를 어디로 이동시키고 비교를 해야 시간을 아낄 수 있을까요 바로 우리가 앞서 만든 pi배열을 사용하면 됩니다.

지금 우리는 i가 6인 지점에서 매칭을 마쳤습니다. 다음엔 i가 7인 지점을 비교를 해야합니다. 이 상태에서 j를 0으로 이동시키고 비교를 하는 것은 브루트 포스입니다.

하지만 우리는 LPS을 기록한 pi배열이 있습니다. tartget[46]는 패턴의 접미사로 생각할 수 있습니다. (i가 6에서 매칭되었으므로) 현재 j위치의 LPS는 3입니다. 이는 길이가 3인 접두사와 접미사가 같다는 것을 뜻합니다. 그러므로 패턴의 접두사와 target[46]이 같기에 같은 부분은 생략하고 비교를 진행해야 합니다. (그림에서 연두색으로 칠해진 곳이 같다.)

그래서 j는 pi[j]로 이동합니다. 매칭이 되지 않는 경우에 j의 위치를 이동할때도 위와 완전히 똑같은 논리가 적용됩니다. (pi배열을 만들때와도 매우 흡사합니다.)

이어서 진행해 봅시다.

j를 이동했음에도 일치하지 않습니다. 현재 j는 3이고 i가 7인 상태에서 불일치가 발생했으므로, pattern[0~2]와 target[4~6]은 같았다는 것을 알 수 있습니다. 또한 patter[0~2]의 LPS는 1이기에 pattern[0]과 target[6]이 일치한다는 것을 내포합니다.(target[6] = 접미사, pattern[0] = 접두사)

그러므로 j를 pi[j-1]인 1로 이동시켜 비교를 계속합니다.

또 같지 않으므로 j를 pi[j-1]인 0으로 이동시킵니다.

일치함으로 j와 i를 1씩 증가시킵니다.

j가 pattern의 마지막 인덱스 위치에 도달하고 문자열이 일치함으로, 패턴이 매칭되었음을 알 수 있습니다. 위에서 설명한대로 색깔칠해진 부분이 같기때문에 j를 pi[j]인 3으로 이동시켜 계속 진행합니다.

불일치 했지만 i가 문자열의 마지막에 도달했으므로 패턴매칭을 종료합니다.

KMP 알고리즘: 정리

KMP는 접두사(prefix)와 접미사(suffix)가 같다면 이를 활용해서 의미없는 반복을 줄이는 패턴매칭 알고리즘입니다. 브루트포스의 시간 복잡도가 O(NM)인거에 비해 *KMP는 O(N+M)의 시간복잡도**를 가지고 있습니다. (pi배열 만드는 시간복잡도 O(N) + KMP패턴매칭의 시간복잡도 O(M))

하지만 KMP는 찾을 패턴의 접두사와 접미사가 같은 부분이 있어야 효율이 나는 알고리즘입니다. 이말은 접두사와 접미사가 같은게 없다면 사실상 브루트포스와 다를게 없다는 소리입니다. 하지만 KMP의 패턴매칭 알고리즘은 그 원리에 있어서 다소 신박한 부분이 있기 때문에 이해해두면 신박한 문제나 상황에선 유용할 거 같습니다.

느낀점

패턴매칭에 대해서 아무것도 몰랐기에 KMP는 저의 첫 패턴매칭 알고리즘이었습니다. 그래서인지 이를 이해하는데 생각보다 많은 시간이 걸렸지만 결국 이해를 완전히 한거 같아서 너무나 기쁩니다. 이 과정에서 문자열을 이런식으로도 접근할 수 있구나를 느꼈고, 이 글을 쓰면서 pi배열을 만드는 과정과 KMP의 과정을 일일히 한 단계씩 그림을 그려봤던 것이 설명을 위한 것이었음에도 불구하고 누구보다 저에게 정말 큰 도움이 되었던 것 같습니다. 앞으로도 뭔가가 이해가 안된다면 그 과정을 성가시지만 일일히 그려보는 것도 좋을 것 같습니다. 마지막으로 이 긴글 읽으신 분들이 계시다면 정말 감사합니다. 혹시 오탈자다 글의 오류가 있다면 언제든지 알려주시면 저에게 큰 도움이 됩니다!

References

• [String] String searching #1 - prefix function & KMP (재녹음) https://www.youtube.com/watch?v=RHGfn52cHHw&list=WL&index=2&t=1015s [개발자 영맨(bluedawnstar)]

• [알고리즘] 패턴 매칭 알고리즘, KMP 알고리즘 ( Knuth–Morris–Pratt Algorithm ) https://ymg5218.tistory.com/152 [민규의 흔적:티스토리]

• [알고리즘/ 파이썬] KMP 알고리즘? 그림으로 쉽게 이해하기! https://yiyj1030.tistory.com/495 [컴퓨터 지식, 이렇게 쉽게!(ggyongi)]

sort()

sort()의 기본문법은 아래와 같습니다.

<list>.sort(key = <function>, reverse = <bool>

• sort()는 기존의 list를 정렬합니다.

• list에만 사용 할 수 있습니다.
• key를 통해 정렬기준을 정합니다.
• reverse값이 True면 내림차순, False은 오름차순입니다. (기본값은 False)

nums = [13,2,11,5,4,7,1]
nums.sort()
print("오름차순",nums)

nums.sort(reverse = True)
print("내림차순",nums)

#출력
오름차순 [1, 2, 4, 5, 7, 11, 13]
내림차순 [13, 11, 7, 5, 4, 2, 1]

위 코드에서 보이듯 sort()를 사용하면 원본 list가 정렬되어 수정됩니다.

sorted()

sorted()의 기본문법은 아래와 같습니다.

sorted(<iterable>, key = <function>, reverse = <bool>)

• 어떠한 iterable을 정렬된 list로 새로 만듭니다. (새로 정의 or 출력 필요)

• 모든 iterable에 사용이 가능합니다.
• key와 reverse의 기능은 sort()의 것과 동일합니다.

nums = [13,2,11,5,4,7,1]
sorted_nums = sorted(nums)

print("sorted: ",sorted_nums)
print("original: ",nums)

#출력
sorted:  [1, 2, 4, 5, 7, 11, 13]
original:  [13, 2, 11, 5, 4, 7, 1]

위와 같이 sorted()를 사용하면 새로운 정렬된 list가 생성되는 것을 알 수 있습니다. sorted()는 sort()와 다르게 list뿐만아니라 모든 iterable에 사용이 가능합니다.

_dict = {5:'A', 13:"E", 1:"B", 3:"G", 12:"C"}
_set = set([5,13,1,3,12])

sorted_dict = sorted(_dict)
sorted_set = sorted(_set)

print("dict: ",sorted_dict)
print("set: ",sorted_set)

#출력
dict:  [1, 3, 5, 12, 13]
set:  [1, 3, 5, 12, 13]

key 매개변수

sort()와 sorted()모두 key매개변수를 사용하여 정렬 기준을 세울 수 있습니다. key매개 변수에는 함수가 입력되어아하며 이 함수에 따라 정렬의 기준이 달라집니다. 보통 lambda를 많이 이용합니다.

lambda를 주로 많이 사용하지만 이를 사용하지 않는 예부터 살펴보겠습니다.

disorder = ["i'm","so","sorry","but","i","love","you"]

disorder.sort(key = len)

print(disorder)

#출력
['i', 'so', "i'm", 'but', 'you', 'love', 'sorry']

위와 같이 key에 len을 사용하면 글자 수를 기준으로 오름차순 되어 정렬됩니다. len함수에 정렬할 리스트의 요소들이 하나씩 들어가 반환되는 값을 기준으로 정렬이 되는 것입니다.

lambda 사용하기

key매개변수는 함수를 입력해야하므로 lambda를 사용해 정렬기준을 정할 수 있습니다.

student = {"Kim":80, "Lee": 70, "Bae": 15, "Park": 60, "Oh": 0}

sorted_student_1 = sorted(student, key = lambda x : student[x])
sorted_student_2 = sorted(student.items(), key = lambda x : x[0]) #items는 (key,value)을 쌍으로 가져옵니다
sorted_student_3 = sorted(student.items(), key = lambda x : x[1])
reversed_student = sorted(student, key = lambda x : -student[x])

print(sorted_student_1)
print(sorted_student_2)
print(sorted_student_3)
print(reversed_student)

#출력
['Oh', 'Bae', 'Park', 'Lee', 'Kim']
[('Bae', 15), ('Kim', 80), ('Lee', 70), ('Oh', 0), ('Park', 60)]
[('Oh', 0), ('Bae', 15), ('Park', 60), ('Lee', 70), ('Kim', 80)]
['Kim', 'Lee', 'Park', 'Bae', 'Oh']

• 첫번째 예시는 key = lambda x : student[x]를 사용하여 딕셔너리의 value값을 비교하여 정렬된 key값을 가지는 리스트을 반환합니다.

• 두번째 예시는 items()를 사용하여 key와 value를 쌍으로 가져와 key = lambda x : x[0]을 통해 key값을 정렬기준으로 하고 이를 (key, value)리스트로 반환합니다.

• 세번째 예시는 두번째와 비슷하지만 key = lambda x : x[1]을 통해 value값을 정렬기준으로 하고 (key, value)리스트로 반환합니다.

• 마지막은 첫번째 예시에 마이너스 부호(-)를 사용하여 내림차순으로 정렬합니다. (reverse = True와 동일)

다중조건 정렬

lambda를 이용해 정렬기준을 여러개로 설정할 수도 있습니다.

예를들어 나이와 이름이 기록된 명부 리스트가 있을때, 먼저 나이를 고려해서 정렬하고 만약 나이 같다면 이름 순대로 정렬해야 하는 경우 정렬기준을 튜플로 묶어 다음과 같이 설정하면 됩니다.

key = lambda x : (x[나이], x[이름])

people = {"Kim":54, "Lee": 25, "Bae": 25, "Park": 25, "Oh": 15}

sorted_people = sorted(people.items() , key= lambda x : (x[1],x[0]))

print(sorted_people)

#출력
[('Oh', 15), ('Bae', 25), ('Lee', 25), ('Park', 25), ('Kim', 54)]

위 코드를 보면 나이를 기준으로 오름차순으로 정렬되어있고, 나이가 같은 Bae,Lee,Park는 이름을 기준으로 오름차순으로 정렬되었습니다.

안정 정렬

안정정렬이란 같은 값을 정렬할때 기존 위치를 유지하여 정렬하는 것을 의미합니다.

• https://en.wikipedia.org/wiki/Sorting_algorithm#Stability

위 그림처럼 정렬이 안정적(Stable)하면 정렬하기 전의 중복된 값들의 위치가 정렬 후에도 유지됩니다. (불안정하다면 기존의 위치의 유지가 보장되지 않습니다.)

sort()와 sorted()모두 정렬의 안정성(Stability)이 보장됩니다.

마지막으로 위의 그림을 직접 코딩해보며 이 글을 마치겠습니다. 감사합니다.

cards = [("♠",7),["♥",5],["♥",2],["♠",5]]

cards.sort(key = lambda x : x[1])

print(cards)

#출력
[['♥', 2], ['♥', 5], ['♠', 5], ('♠', 7)]