1. 프런트엔드 컴파일러: JDK의 javac(.java -> .class로 변경), 이클립스 JDT의 증분 컴파일러(변경된 파일만 다시 컴파일하도록. 일반 컴파일은 500개 파일 중 하나만 고쳐도 의존성 따라 싹 다 다시 컴파일해야 하는데 그러지 않도록하는 것이 증분 컴파일임)
2. JIT 컴파일러: 핫스팟 가상 머신의 C1, C2 컴파일러
3. AOT 컴파일러

이번 장은 그 중 1번. 이전 6, 7, 8, 9장에서 설명되었던 런타임단계의 클래스 로딩, 링킹, 초기화, 스프링 컨테이너 빈 생성, 의존관계 주입 등 class파일을 JVM 메모리에 올리고 객체를 Container 등록하는 과정 전에 일어나는 빌드 타임 작업에 대한 설명을 할 거란 말. 톰캣 올리기 전 끝나있는 class 파일 만드는 "컴파일"에 대해 설명하는 장임.

최적화 또한 다음과 같이 정의한다: javac와 같은 프런트엔드 컴파일러는 코드 실행 효율 측면의 최적화는 거의 하지 않으며, JDK 1.3 이후로는 성능 최적화를 런타임 컴파일러에 집중시켰다. (그루비 클래스 파일 등도 최적화 효과를 공평하게 누리기 위해)

개발단계까지 최적화를 넓혀 부른다면, 런타임: 실행 효율을 높이는 최적화를 JIT 컴파일러에서 지속해서 수행 컴파일타임: 개발자 코딩 효율 높이는 최적화를 프런트엔드 컴파일러가 수행

10.2 javac 컴파일러

• 순수 자바로 작성
• JDK 6부터 javac 표준 자바 SE API에 포함. 원래는 구현 코드도 다 tools.jar에 별도로 담겨있었음. tools.jar 라이브러리가 클래스패스에 존재해야 javac 쓸 수 있었음 -> 표준 자바 클래스 라이브러리로 지금은 옮겨짐

Java소스파일을 클래스 파일로 컴파일 하는 방법은 아주 느슨하게 설명되어있어 자유도가 높음 장점: 자바 프런트엔드 컴파일러의 자유도 vs 단점:컴파일 과정이 특정 JDK 또는 컴파일러 구현에 따라 달라지는 경우도 생김

javac 코드의 전체 구조 확인을 통한 컴파일 처리 단계: 1단계 준비 + 3단계 처리 0: 플러그인 annotation 처리기 초기화 1: 구문 분석 및 심벌 테이블 채우기(소스 코드 토큰화하여 추상 구문 트리 구성/심벌 주소와 심벌 정보 생성) 2: 플러그인 annotation 처리기들로 annotation 처리 3: 의미분석 및 바이트코드 생성(특성검사를 통한 문법의 정적 정보 확인/데이터 흐름 및 제어 흐름 분석을 통한 프로그램의 동적 실행 과정 확인/편의문법 제거하여 원래 형식으로 복원/바이트 코드 생성)

compile 도중에 플러그인 annotation 실행 시, 새로운 심벌 생성될 수 있음. 그럼 이 새 심벌 다시 처리하려고 심벌 테이블 채우던 때로 돌아가야 함 그 상호작용순서는 아래와 같음:

javac의 컴파일 과정 맡은 클래스: com.sun.tools.javac.main.JavaCompiler 앞선 3단계 처리는 compile() method에 집중되어있음

javac 소스코드 기준으로 3단계 처리 과정 항목별 설명:

1: 구문분석 및 심벌 테이블 채우기 구문분석:

• parseFiles() method.
• 소스코드, 문자스트림 -> 토큰 집합으로(int a = b -> int, a, =, b)
• com.sun.tools.javac.parser.Scanner 클래스가 해당 나눔을 담당 -> 해당 나눔은 곧 "추상 구문 트리"를 만드는 것과 같음

심벌 테이블 채우기:

• enterTrees() method.
• 심벌테이블 = 심벌 주소 + 심벌 정보
• 의미 분석 과정 중 의미 확인(이름을 원래 선언과 일치하게 사용하는지 확인), 중간 코드 생성 시 참조, 목적 코드 생성 시에도 주소 할당에 심벌 테이블 활용
• com. sun. tools.javac.comp.Enter 클래스가 담당 -> 이 단계의 결과로 컴파일 단위 각각에 대한 추상 구문 트리의 최상위 노드와 package-info.java의 최상위 노드 목록 만들어짐(전체 프로젝트의 구조 지도를 만든다는 뜻 -> 다음 단계에서 그래야 타입 검사, 흐름 분석, 바이트 코드를 생성할 수 있으므로)

2: 애너테이션 처리

• 애너테이션 처리 중에 구문 트리를 수정하면 컴파일러는 '구문 분석 및 심벌 테이블 채우기' 단계로 돌아가야 함 -> 이걸 모든 플러그인 애너테이션 처리기가 구문 트리 수정 안할 때까지 반복함
• 컴파일러의 애너테이션 처리 API 사용: 개발자 코드가 컴파일러 동작에 영향 줄 수 있음. 예시로, Lombok의 Getter/Setter 생성, null 확인, 검사 예외 테이블 생성, equals(), hashCode() method 생성 등을 자동으로 작성하게 할 수 있음
• 해당 자동화 애너테이션 처리기는 0단계인 initProcessAnnotations()에서 초기화하여 실행은 processAnnotation()이 담당.
• processAnnotation()은 com.sun.tools.javac.processing.JavacProcessingEnvironment 클래스의 doProcessing()을 실행 할 새 애너테이션 처리기가 있을 시 호출 -> 해당 메서드가 새 JavaCompiler 객체 생성하여 컴파일 이후 단계 처리.

3: 의미 분석과 바이트코드 생성

• 의미분석: 구조적으로 올바른 소스가 '맥락상으로도 올바른지' 확인(예: 타입 검사, 제어 흐름 검사, 데이터 흐름 검사) 그 중

1) 특성 검사: 변수를 사용하기 앞서 선언이 되어 있는지, 변수와 할당될 데이터의 타입이 일치하는지 등을 확인 / 접기(constant folding)라는 최적화도 수행 2) 데이터와 제어 흐름 분석: 프로그램이 맥락상 논리적으로 올바른지 확인. 기본적으로 클래스 로딩 시 수행하는 데이터 및 제어 흐름 분석의 목적과 같음 BUT 검증 범위가 다르기 때문에 항목에 따라 컴파일 타임에만 수행되거나 런타임에만 수행되기도 함 (ex. 지역변수는 상수 풀에 대한 심벌 참조가 없어 접근 플래그 정보 저장 못되므로, final이 붙어도 런타임에는 아무 영향이 없음. so, 오직 컴파일타임에 javac 컴파일러에서만 보장, 검사되는 대표적 예시)

• 편의 문법 제거: desugar() method 촉발. 람다 등 편의 문법을 원래 기본 구문으로 복원
• 바이트코드 생성: com.sun.tools.javac.jvm.Gen 클래스 담당 / 심벌 테이블 단계에서 이름만 등록되고 실제 코드 구현은 바이트코드 생성 시 완성되는 자동생성작업도 여기서 진행(ex. <init())

JAVA 편의문법: Generic, 오토박싱/언박싱, 개선된 for문, 가변 길이 매개 변수, 조건부 컴파일 등(C#과 비교하여 코드 트렌드를 따르는 다양한 편의 문법의 예시와 역사, 사용법)

실전: 플러그인 애너테이션 처리기 제작

Oracle:

• 사용자(User)와 스키마(Schema)가 1:1로 매핑됨
• 사용자를 생성하면 동일한 이름의 스키마가 자동으로 생성됨
• 테이블은 직접 사용자(=스키마)에 속함

MSSQL:

• 사용자와 스키마가 분리되어 있음
• 한 사용자가 여러 스키마를 소유할 수 있고, 여러 사용자가 하나의 스키마에 객체를 생성할 수 있음
• 테이블은 스키마에 속하고, 스키마는 사용자에게 속함
• 한 계정으로 여러 DB에 붙을 수 있음

2. 테이블 참조 방식

Oracle:

SELECT * FROM SCOTT.EMP;  -- SCOTT은 사용자이자 스키마

MSSQL:

SELECT * FROM Sales.Orders;  -- Sales는 스키마, 소유자는 별도로 존재

3. 권한을 누가 주는가?

Oracle: sys

MSSQL: sa

• 시스템권한은 사용자가 데이터베이스에서 특정 작업을 수행 할 수 있도록 한다
• 권한의 ANY 키워드는 사용자가 모든 스키마에서 권한을 가짐을 의미 한다.
• GRANT 명령은 사용자 또는 ROLE에 대해서 권한을 부여 할 수 있다.
• REVOKE 명령은 권한을 회수 한다.

대표적인 시스템권한

• CREATE SESSION : 데이터 베이스를 연결할 수 있는 권한
• CREATE ROLE : 오라클 데이터베이스 역할을 생성할 수 있는 권한
• CREATE VIEW : 뷰의 생성 권한
• ALTER USER : 생성한 사용자의 정의를 변경할 수 있는 권한
• DROP USER : 생성한 사용자를 삭제시키는 권한

시스템권한 부여 문법

• system_privilege : 부여할 시스템권한의 이름
• role : 부여할 데이터베이스 역할의 이름
• user, role : 부여할 사용자 이름과 다른 데이터 베이스 역할 이름
• PUBLIC : 시스템권한, 또는 데이터베이스 역할을 모든 사용자에게 부여할 수 있다.
• WITH ADMIN OPTION : 권한을 부여 받은 사용자도 부여 받은 권한을 다른 사용자 또는 역할로 부여할 수 있게된다.

시스템권한 회수

-- scott 사용자에게 부여한 생성, 수정, 삭제 권한을 회수 한다.
SQL>REVOKE CREATE USER, ALTER USER, DROP USER
    FROM scott;
 권한이 회수되었습니다.

시스템 권한을 회수해도, 회수 당한 사용자가 권한을 부여한 당사자는 여전히 받은 권한을 유지한다.

객체권한(Object Privileges)

• 테이블이나 뷰, 시퀀스, 프로시저, 함수, 또는 패키지 중 지정된 한 객체에 특별한 작업을 수행 할 수 있게 한다.
• 객체 소유자는 다른 사용자에게 특정 객체권한을 부여 할 수 있다.
• PUBLIC으로 권한을 부여하면 회수할 때도 PUBLIC으로 해야 한다.
• 기본적으로 소유한 객체에 대해서는 모든 권한이 자동적으로 획득된다.
• WITH GRANT OPTION 옵션은 ROLE에 권한을 부여할 때는 사용할 수 없다.

객체권한 부여 예제

-- scott USER에게 emp테이블을 SELECT, INSERT할 수 있는 권한을 부여했다.
-- scott USER도 다른 USER에게 그 권한을 부여 할 수 있다.
SQL>GRANT SELECT, INSERT
    ON emp
    TO scott
    WITH  GRANT  OPTION;
 권한이 부여되었습니다.

객체권한의 회수

• 객체 권한의 철회는 그 권한을 부여한 부여자만이 수행할수 있다.
• CASCADE CONSTRAINTS : 이 명령어의 사용으로 참조 객체 권한에서 사용 된 참조 무결성 제한을 같이 삭제 할 수 있다.
• WITH GRANT OPTION으로 객체 권한을 부여한 사용자의 객체 권한을 철회하면, 권한을 부여받은 사용자가 부여한 객체 권한 또한 같이 철회되는 종속철회가 발생한다.

시스템 권한: "무언가를 만들거나 없앨 수 있는" 권한 객체 권한: "이미 있는 것을 사용할 수 있는" 권한

롤(ROLE)

• ROLE을 이용하면 권한 부여와 회수를 쉽게 할 수 있다.
• ROLE은 CREATE ROLE권한을 가진 USER에 의해서 생성 된다.
• 한 사용자가 여러개의 ROLL을 ACCESS할 수 있고, 여러 사용자에게 같은 ROLE을 부여할 수 있다.
• 시스템 권한을 부여하고, 취소할 때와 동일한 명령을 사용하여 사용자에게 부여하고, 취소 한다.
• 사용자는 ROLE에 ROLE을 부여할 수 있다.
• 오라클 데이터베이스를 설치하면 기본적으로 CONNECT, RESOURCE, DBA ROLE이 제공 된다.

ROLE의 부여 순서

① ROLE의 생성 : CREATE ROLE manager ② ROLE에 권한 부여 : GRANT create session, create table TO manager ③ ROLE을 사용자 또는 ROLE에게 부여 : GRANT manager TO scott, test;

-- ROLE을 생성 합니다.
SQL>CREATE ROLE manager;

-- ROLE에 권한을 부여 합니다.
SQL>GRANT create session, create table TO manager;

-- 권한이 부여된ROLE을 USER나 ROLE에 부여 합니다.
SQL>GRANT manager TO scott, test;

RESOURCE ROLE

• Store Procedure나 Trigger와 같은 PL/SQL을 사용할 수 있는 권한 들로 이루어져 있다.
• PL/SQL을 사용하려면 RESOURCE ROLE을 부여해야 한다.
• 유저를 생성하면 일반적으로 CONNECT, RESOURCE롤을 부여 한다.

DBA ROLE

• 모든 시스템 권한이 부여된 ROLE 이다.
• DBA ROLE은 데이터베이스 관리자에게만 부여해야 한다.

출처: http://www.gurubee.net/lecture/1345

-- SQL PLUS를 실행시키고 SCOTT/TIGER로 접속을 한다.
SQL>CREATE USER TEST IDENTIFIED BY TEST;

1행에 오류:
ORA-01031: 권한이 불충분합니다

-- SCOTT USER는 사용자 생성 권한이 없어서 사용자를 생성할 수 없다.
-- DBA Role이 있는 유저로 접속 
-- sqlplus / as sysdba 로 접속하셔도 됩니다.
SQL>CONN sys/manager AS SYSDBA

 -- USER를 다시 생성.
SQL>CREATE USER TEST IDENTIFIED BY TEST;    
 사용자가 생성되었습니다.    

새로 생성한 USER 접근권한 부여

SQL> CONN TEST/TEST

ERROR:
ORA-01045: 사용자 TEST는 CREATE SESSION 권한을 가지고있지 않음;

-- 새로 생성한 TEST USER는 권한이 없어서 접근할 수가 없다.
-- 모든 USER는 권한이 있고 권한에 해당하는 역할만 할 수 있다.
-- TEST라는 USER를 사용하기 위해서도 권한을 부여해 주어야 한다.
SQL> CONN sys/manager AS SYSDBA
연결되었습니다.

SQL> GRANT connect, resource TO TEST ;
권한이 부여되었습니다.

SQL> CONN TEST/TEST
연결되었습니다.

User 정보를 변경해보자.

ALTER USER문으로 변경 가능한 옵션

• 비밀번호
• 운영체제 인증
• 디폴트 테이블 스페이스
• 임시 테이블 스페이스
• 테이블 스페이스 분배 할당
• 프로파일 및 디폴트 역할

USER 수정

-- SYS 권한으로 접속한다.    
C:\> SQLPLUS /NOLOG
SQL> CONN / AS SYSDBA       

-- scott USER의 비밀번호를 수정한다.
SQL> ALTER USER scott IDENTIFIED BY lion;    
 사용자가 변경되었습니다.

-- scott USER의 비밀번호가 변경된 것을 확인할 수 있다.
SQL> CONN scott/lion    
접속되었습니다.


SQL> CONN / AS SYSDBA
접속되었습니다.

-- scott USER의 비밀번호를 처음처럼 수정한다.
SQL> ALTER USER scott IDENTIFIED BY tiger;    
사용자가 변경되었습니다.

USER 삭제

DROP USER user_name [CASCADE}

USER 정보 확인

-- 데이터베이스에 등록된 사용자를 조회하기 위해서는 DBA_USERS라는 
    데이터사전을 조회하면 된다.
-- SQL*Plus를 실행시켜  SYS계정으로 접속을 한다.
SQL> CONN / AS SYSDBA 

SQL> SELECT username, default_tablespace, temporary_tablespace
     FROM DBA_USERS;

USERNAME         DEFAULT_TABLESPACE      TEMPORARY_TABLES
---------------- -------------------     ----------------
SYS               SYSTEM                  TEMP
SYSTEM            TOOLS                   TEMP
OUTLN             SYSTEM                  SYSTEM
DBSNMP            SYSTEM                  SYSTEM
ORDSYS            SYSTEM                  SYSTEM
ORDPLUGINS        SYSTEM                  SYSTEM
MDSYS             SYSTEM                  SYSTEM
CTXSYS            DRSYS                   DRSYS
SCOTT             SYSTEM                  SYSTEM
TEST              TEST                    SYSTEM
STORM             STORM                   SYSTEM
KJS               SYSTEM                  SYSTEM

 위와 같이 유저와 테이블 스페이스에 대한 정보가 화면에 나온다.      

출처: http://www.gurubee.net/lecture/1006

SELECT 
    AUTHOR_ID,
    AUTHOR_NAME,
    CATEGORY,
    TOTAL_SALES
FROM (
    SELECT 
        NVL(TO_CHAR(A.AUTHOR_ID), '전체') AS AUTHOR_ID,
        NVL(A.AUTHOR_NAME, '전체') AS AUTHOR_NAME,
        NVL(B.CATEGORY, '전체') AS CATEGORY,
        TO_CHAR(SUM(B.PRICE * S.SALES), '999,999,999') AS TOTAL_SALES
    FROM BOOK B
    JOIN AUTHOR A ON B.AUTHOR_ID = A.AUTHOR_ID
    JOIN BOOK_SALES S ON B.BOOK_ID = S.BOOK_ID
    GROUP BY ROLLUP(A.AUTHOR_ID, A.AUTHOR_NAME, B.CATEGORY)
)
ORDER BY AUTHOR_ID

GROUP BY 시 ROLLUP으로 소계, 총합을 표현하는 코드를 작성했고, 이렇게 작성 시 1 전체 전체 5,751,000 같은 필요없는 값이 나오게 되었다. 물론 MAX 함수를 통해 AUTHOR_NAME을 뽑았다면 해결 가능하지만, 오늘 팀장님께 QUERY 교육 중 GROUPING_ID의 존재에 대해 알게 되어 정리한다.

GROUPING_ID

SELECT
    AUTHOR_ID,
    AUTHOR_NAME,
    CATEGORY,
    TOTAL_SALES
FROM (
    SELECT
        NVL(TO_CHAR(A.AUTHOR_ID), '합계') AS AUTHOR_ID,
        NVL(A.AUTHOR_NAME, '합계') AS AUTHOR_NAME,
        NVL(B.CATEGORY, '소계') AS CATEGORY,
        TO_CHAR(SUM(B.PRICE * S.SALES), '999,999,999') AS TOTAL_SALES,
         GROUPING_ID(A.AUTHOR_ID,  A.AUTHOR_NAME, B.CATEGORY) gid
    FROM BOOK B
    JOIN AUTHOR A ON B.AUTHOR_ID = A.AUTHOR_ID
    JOIN BOOK_SALES S ON B.BOOK_ID = S.BOOK_ID
    GROUP BY ROLLUP(A.AUTHOR_ID,  A.AUTHOR_NAME, B.CATEGORY)
    ORDER BY AUTHOR_ID
)
WHERE gid != 3
ORDER BY AUTHOR_ID

이렇게 처리하게 되면,

0, 0, 1, 3, 0, 1, 3, 7 이렇게 2의 3승개의 데이터가 나오게 되어 3, 3을 제거하면 우리가 필요로 하지 않았던 데이터가 사라지게 된다.

필요없는 데이터를 처리하기 위해 GROUPING_ID를 활용한 경험을 정리해보았다.

구루비_ROLLUP 구루비_GROUPING_ID

IaaS (Infrastructure as a Service)

• 가상 서버, 스토리지, 네트워크 등 기본적인 컴퓨팅 인프라를 제공하는 서비스
• Amazon EC2가 대표적인 예시

IaaS의 특징

• 사용자가 직접 OS, 미들웨어, 런타임, 애플리케이션을 설치하고 관리
• 더 많은 통제권과 유연성 제공
• 관리 책임이 큼 (OS 업데이트, 보안 패치, 런타임 환경 설정 등)

IaaS 배포 프로세스 예시

1. EC2, RDS 서버 연결
2. JPA로 테이블 생성
3. React 서버 실행
4. 연결 확인 후 tar 압축파일 생성

PaaS (Platform as a Service)

• 애플리케이션 실행에 필요한 플랫폼을 제공하는 서비스
• AWS Elastic Beanstalk이 대표적인 예시

PaaS의 특징

• OS, 미들웨어, 런타임 환경을 서비스 제공자가 관리
• 개발과 배포에 더 집중 가능
• 코드 업로드만으로 배포 가능
• 자동 스케일링과 로드 밸런싱 제공
• 환경 관리 자동화

Docker: 컨테이너화 플랫폼

• 애플리케이션을 "컨테이너"라는 표준화된 단위로 패키징하는 플랫폼

Docker 컨테이너란?

• 컨테이너는 애플리케이션과 그것을 실행하는데 필요한 모든 의존성(라이브러리, 설정 등)을 하나의 패키지로 묶은 것
• 마치 선박 컨테이너처럼 표준화된 방식으로 어디서든 실행이 가능

Docker의 장점

• 환경 일관성: "내 컴퓨터에서는 작동했는데..." 문제 해결
• 격리성: 각 애플리케이션이 독립된 환경에서 실행
• 이식성: 개발/테스트/운영 환경 간 쉬운 이동
• 자원 효율성: VM보다 가벼운 구조

Docker 사용 예시

Spring Boot 애플리케이션을 위한 Dockerfile 예시:

FROM openjdk:17
COPY target/FITPLE-1.0.0.jar app.jar
EXPOSE 8081
ENTRYPOINT ["java","-jar","/app.jar"]

Docker와 클라우드 서비스의 관계

• Docker 자체는 IaaS나 PaaS로 직접 분류되지 않으며, 사용 방식에 따라 다르게 활용될 수 있음

IaaS 방식

• EC2에 Docker를 직접 설치하고 관리
• 더 많은 통제권과 책임
• 직접적인 Docker 설치, 관리, 운영 필요

PaaS 방식

• AWS ECS, EKS와 같은 관리형 컨테이너 서비스 사용
• AWS가 Docker 실행 환경을 관리
• 컨테이너 이미지만 제공하면 됨

IaaS: 빈 아파트를 받아서 직접 가구를 놓고 꾸미는 것 PaaS: 풀옵션 원룸처럼 다 갖춰진 환경을 받는 것 Docker: 가구나 살림살이를 표준화된 상자에 담아서 쉽게 옮길 수 있게 해주는 포장 기술

서비스에 필요한 기능: 비즈니스 로직 시간을 재거나, 권한을 체크하거나, transaction을 거는 기능(=부가기능): 인프라 로직

인프라 로직

• 애플리케이션 전 영역에서 나타남
• 중복코드 -> 유지보수 힘듬
• 비즈니스 로직과 섞여 있어 비즈니스 로직을 이해하기 힘들게 만듬
• 로깅, 트랜잭션, 성능 측정 등의 부가기능
• Cross-cutting concern

Aspect-Oriented Programming

• OOP와 같은 하나의 패러다임으로, 각 언어마다 AOP 구현체를 필요로 함
• Java: AspectJ

Target

• 어떤 대상에 부가 기능을 부여할 것인가

  Advice

• 어떠한 기능을 부가할 것인가

  Join point

• 어디에 적용할 것인가: 메서드가 호출, 실행, 필드에 접근할 때, 필드에 접근할 때 등에 적용 / But Spring에서는 메서드가 실행될 때 만으로 한정

  Point cut

• 포인트컷(Pointcut)은 관심 조인 포인트를 결정하므로 어드바이스가 실행되는 시기를 제어할 수 있음

1. 자기소개

2. Spring을 쓰는 이유가 뭐냐

3. JPA가 나오게 된 이유가 뭐라고 생각하나?

4. MyBatis로 매핑할때랑 JPA 쓸 때랑 어떤 차이가 있었는지?

5. IoC, DI에 대한 심도 있는 질문. DI를 쓰는 이유를 말해봐라. Singleton 패턴에 대해서 아는지?

6. AOP, Filter 기능을 프로젝트에서 활용해본 적 있는지?

7. List, Map 등 Java Collection을 필요에 의해 사용해 본 경험이 있는가?

8. ArrayList, HashMap 말고 다른 Java Collection 사용해본 적은 없는지?

9. JVM 1.7, 1.8에서 22까지 나왔는데 이들이 바뀌면서 어떤 차이를 보여줬는지 알고 있나?

10. JVM의 메모리 영역 등 내부 작동 방식에 대해 알고 있나? 설명해봐라.

11. JPA에서 비영속적 객체를 영속적으로 바꾸는 건 언제 했고 왜 했는지?

12. 국비 프로젝트를 진행하면 비전공자들과는 어떤 식으로 함께 했는지? 주로 가르쳐주는 방식이었는지?

13. 프로젝트를 진행하다가 갈등이 생기면 어떻게 했는지?

14. 회사에 궁금한 점은?

15. 언제부터 출근할 수 있는지?

16. 회사에 마지막으로 어필하고 싶은 점은?

전반적으로 면접이 아니라 수업을 듣고 온 것 같은 느낌. 뭔가 괜히 감사했음. 무례한 질문 하나도 없었음. 개발자 2분이서 질문하심. 오전 9시 면접인데 오전 8시 반에 가서 대기할 줄 알았는데, 바로 시험 보고 면접 봄. 서초라 위치적으로 좋은 곳 같음. 사무실이 매우 cozy 하고 따뜻했음.

2차도 보고싶다

느낀점:

• 국비수업 때 이론 정리한 거 조금 더 읽고 가자
• 자소서 워딩을 조심하자
• 경험을 토대로 얘기하자

JWT

• RFC 7519 표준으로 정의된 방식
• JSON format을 Base 64로 encode해서 만든다
• payload에 담겨있는 것 = Claim (사용자에 대한 property)
• signature : 검증을 위해 필요 (header + payload 인코딩)

signature:

HMACSHA256 (
      base64UrlEncode(header) + "." +
      base64UrlEncode(payload),
    your-256-bit-secret
) 

• secret: 서버만 가지고 있는 인증을 위한 비밀키

JWT 인증 절차

1. username, password 인증시도
2. 인증 확인 - DB 연동
3. JWT 토큰 (서버가) 발급
4. JWT를 response header에 담아 보냄
5. Client는 JWT를 저장 (localStorage, cookie에)
6. 다음 요청부터 저장된 JWT를 request header의 Authorization 값에 보냄
7. 요청에 담긴 JWT (서버가) 검증
8. 검증 성공 시, 인증 처리(session 기반 x, but 여기서 session이 생겨 인증정보 저장됨), 권한 부여
9. 인증 후, 요청처리 (buisness logic), response (response 후 session 삭제)

리렌더링과 상태 유지

• 일반 변수를 사용하면, 컴포넌트가 리렌더링될 때마다 변수가 초기화 됨

예를 들어, 위 코드에서 let number = 1로 했다면:

const App061 = () => {
  let number = 1;  // 컴포넌트가 리렌더링될 때마다 다시 1로 초기화됨

  const add = () => {
    number++;  // 값은 증가하지만 리렌더링되면 다시 1로 돌아감
    console.log(number);  // 콘솔에는 증가된 값이 보이지만
    // UI는 업데이트되지 않음
  };

  return <h1>숫자: {number}</h1>;  // 항상 1만 표시됨
};

리렌더링 트리거

• useState의 setState 함수(여기서는 setNumber)는 React에게 "상태가 변경되었으니 화면을 다시 그려야 해"라고 알려줌
• 일반 변수는 값이 변경되어도 React는 이를 모르기 때문에 화면이 업데이트되지 않음

비동기적 업데이트 처리

• React는 성능 최적화를 위해 여러 상태 업데이트를 배치(batch)로 처리
• useState는 이러한 비동기적 업데이트를 안전하게 처리할 수 있음

// 이전 상태를 기반으로 안전하게 업데이트
setNumber(prev => prev + 1);

그 차이점을 예시로 보자면,

// 일반 변수를 사용한 경우
let normalVar = 0;
const handleClick = () => {
  normalVar += 1;  // 값은 변경되지만
  console.log(normalVar);  // 콘솔에만 보이고
  // 화면은 업데이트되지 않음
};

// useState를 사용한 경우
const [stateVar, setStateVar] = useState(0);
const handleClick = () => {
  setStateVar(prev => prev + 1);  // 값이 변경되고
  // React가 컴포넌트를 다시 렌더링하여
  // 화면도 업데이트됨
};

따라서 Hook(useState)을 사용하는 것은:

컴포넌트의 상태를 안정적으로 유지하고 UI를 자동으로 업데이트하며, React의 렌더링 사이클과 조화롭게 동작하기 위해서!

그러니까 react가 처리를 하면 화면 업데이트가 안되니까 변수말고 hook을 쓴다는거다. React의 핵심 특징 중 하나는 "상태가 변경되면 화면을 자동으로 다시 그린다"는 점인데, 근데 React가 일반 변수의 변경은 감지할 수 없으므로 화면 업데이트가 필요한 값들은 항상 useState같은 Hook으로 관리하는 것이 좋다.

React의 value는 HTML 에서 value 와 다르다

무슨 뜻일까?

코드로 먼저 확인하자.

import React, { useState } from 'react';


const App016 = () => {

  const [fruit, setFruit] = useState('grape');

  const [key, setKey] = useState(1);

  const resetSelect = () => setKey(prev => prev + 1);

  const items = [
    { id: 1, name: 'Apple' },
    { id: 2, name: 'Banana' },
    { id: 3, name: 'Cherry' },
  ];

    return (
      <>
        <h2>Controlled Component (value=)</h2>
        <select value={fruit} onChange={(e) => setFruit(e.target.value)}>
          <option value="apple">사과</option>
          <option value="banana">바나나</option>
          <option value="orange">오렌지</option>
          <option value="grape">포도</option>
        </select>
        <p>Selected: {fruit}</p>
      </>
    );
};

export default App016;

e.target.value를 보자.

HTML Value vs. React Value

동작 방식의 차이

• HTML value: 초기값만 설정하고 이후 사용자의 입력에 따라 자유롭게 변경
• React value: 컴포넌트의 state와 연결되어 있으며, state가 변경되지 않으면 값이 변경되지 않음

제어 방식의 차이

// HTML
<select value="apple">  // 초기값만 설정하고 이후 자유롭게 변경 가능

// React
<select value={fruit} onChange={(e) => setFruit(e.target.value)}>  
// value와 onChange가 쌍으로 동작

• React에서는 value와 onChange 핸들러가 세트로 동작하여 "제어 컴포넌트(Controlled Component)"를 형성한다.

상태 관리

• HTML: DOM 요소 자체가 상태를 관리
• React: 컴포넌트의 state가 상태를 관리하고, 이 state가 변경될 때마다 컴포넌트가 다시 렌더링 됨

const [fruit, setFruit] = useState('grape');  // state 관리
...
<select value={fruit} onChange={(e) => setFruit(e.target.value)}>

여기서 value는 단순한 속성이 아니라 React의 단방향 데이터 흐름을 구현하는 중요한 요소

사용자가 select를 변경하면:

- onChange 이벤트가 발생
- setFruit로 state 업데이트
- 컴포넌트 리렌더링
- 새로운 value 값이 select에 반영

React는 한 페이지 내에서 component가 변화될 때

State의 기본 개념

const [count, setCount] = useState(0);

count: 현재 상태값
setCount: 상태를 업데이트하는 함수
0: 초기값

State의 특징

• 컴포넌트에 종속적: 각 컴포넌트는 자신만의 독립적인 state를 가짐
• 비동기적 업데이트: setState는 비동기적으로 처리됨
• 불변성 유지: 직접 수정하지 않고 항상 setState 함수를 통해 업데이트해야 함

잘못된 State 사용 예시

// ❌ 잘못된 방법
count = count + 1;  // state 직접 수정

// ✅ 올바른 방법
setCount(count + 1);  // setState 함수 사용

이전 상태를 기반으로 업데이트

// 이전 상태값을 사용할 때의 올바른 방법
setCount(prevCount => prevCount + 1);

객체 형태의 State 업데이트

const [user, setUser] = useState({
  name: 'John',
  age: 25
});

// 객체 업데이트 시 spread 연산자 사용
setUser({
  ...user,
  age: 26
});

1. 앤드포인트 설계
2. 비즈니스 로직 구현
3. 응답구조 결정
4. 데이터베이스 연동
5. 만들어야하는 테이블

1. 앤드포인트 설계

트레이너-회원 MBTI 매칭 시스템의 API 엔드포인트를 설계

기본 URL: /api/v1

MBTI 관련 엔드포인트

GET /mbti-traits             - 모든 MBTI 유형의 특성 조회
GET /mbti-traits/{type}      - 특정 MBTI 유형의 특성 조회 (예: /mbti-traits/ENFJ)

트레이너 관련 엔드포인트

GET    /trainers             - 트레이너 목록 조회
GET    /trainers/{id}        - 특정 트레이너 정보 조회
POST   /trainers             - 새로운 트레이너 등록
PUT    /trainers/{id}        - 트레이너 정보 수정
DELETE /trainers/{id}        - 트레이너 정보 삭제

매칭 관련 엔드포인트

POST   /matching             - MBTI 기반 트레이너 매칭 요청
GET    /matching/history     - 매칭 히스토리 조회

각 엔드포인트의 쿼리 파라미터와 요청/응답 예시를 설계

MBTI 특성 조회

GET /api/v1/mbti-traits
- 쿼리 파라미터:
  - category (선택): training, communication, motivation
  예시: /mbti-traits?category=training

GET /api/v1/mbti-traits/{type}
- 경로 변수: type (MBTI 유형)
- 쿼리 파라미터 없음

트레이너 목록 조회

GET /api/v1/trainers
- 쿼리 파라미터:
  - mbti: MBTI 유형으로 필터링
  - specialty: 전문분야 (weight, diet, rehab 등)
  - page: 페이지 번호 (기본값 0)
  - size: 페이지 크기 (기본값 10)
  - sort: 정렬 기준 (experience, rating)
  예시: /trainers?mbti=ENFJ&specialty=weight&page=0&size=10

매칭 요청

POST /api/v1/matching
- 요청 바디 파라미터:
  - userMbti: 사용자 MBTI
  - preferredStyle: 선호하는 트레이닝 스타일
  - goals: 운동 목표
  - location: 선호 지역
  - priceRange: 가격대

각 엔드포인트의 요청/응답 구조 자세한 설계

MBTI 특성 전체 조회

GET /api/v1/mbti-traits

응답 예시:
{
    "status": "success",
    "data": [
        {
            "type": "ENFJ",
            "training": {
                "preferredStyle": ["group", "motivation"],
                "learningMethod": "demonstration",
                "feedbackStyle": "positive-reinforcement"
            },
            "communication": {
                "style": "encouraging",
                "preferredFormat": "detailed-explanation"
            }
        },
        {
            "type": "INTJ",
            ...
        }
    ]
}

특정 MBTI 특성 조회

GET /api/v1/mbti-traits/ENFJ

응답 예시:
{
    "status": "success",
    "data": {
        "type": "ENFJ",
        "training": { ... },
        "communication": { ... }
    }
}

트레이너 목록 조회

GET /api/v1/trainers?mbti=ENFJ&specialty=weight&page=0&size=10

응답 예시:
{
    "status": "success",
    "data": {
        "trainers": [
            {
                "id": 1,
                "name": "김트레이너",
                "mbti": "ENFJ",
                "specialties": ["weight", "diet"],
                "experience": 5,
                "rating": 4.8,
                "priceRange": {
                    "min": 50000,
                    "max": 100000
                },
                "location": "강남구"
            }
        ],
        "pagination": {
            "currentPage": 0,
            "totalPages": 5,
            "totalElements": 48
        }
    }
}

매칭 요청

POST /api/v1/matching

요청 바디:
{
    "userMbti": "INTJ",
    "preferences": {
        "trainingStyle": ["individual", "data-driven"],
        "goals": ["muscle-gain", "strength"],
        "location": "강남구",
        "priceRange": {
            "min": 50000,
            "max": 150000
        }
    }
}

응답 예시:
{
    "status": "success",
    "data": {
        "matches": [
            {
                "trainerId": 1,
                "matchScore": 95,
                "matchReason": [
                    "MBTI 궁합도: 높음",
                    "선호 트레이닝 스타일 일치",
                    "위치 적합"
                ],
                "trainerInfo": {
                    "name": "김트레이너",
                    "specialties": ["weight", "diet"],
                    ...
                }
            }
        ]
    }
}

에러 응답 구조

{
    "status": "error",
    "error": {
        "code": "INVALID_MBTI",
        "message": "Invalid MBTI type provided",
        "details": "MBTI type must be one of: ENFJ, INFJ..."
    }
}

2. 비즈니스 로직 구현

MBTI 매칭 점수 계산 로직

@Service
public class MatchingService {
    public int calculateMatchScore(String userMbti, Trainer trainer) {
        int score = 0;

        // 1. MBTI 성향 매칭 (40점)
        score += calculateMbtiCompatibility(userMbti, trainer.getMbti());

        // 2. 트레이닝 스타일 매칭 (30점)
        score += calculateTrainingStyleMatch(userMbti, trainer.getTrainingStyle());

        // 3. 경험 점수 (20점)
        score += Math.min(trainer.getExperience() * 4, 20);

        // 4. 리뷰 평점 반영 (10점)
        score += (trainer.getRating() * 2);

        return score;
    }
}

3. 응답구조 결정

응답구조는 크게 성공과 실패 두 가지 경우로 나누어 설계

성공 응답 구조

@Getter
class MatchingResponse {
    private String status = "success";
    private MatchingData data;
}

@Getter
class MatchingData {
    private List<MatchResult> matches;  // 매칭 결과 리스트
    private int totalScore;             // 전체 매칭 점수
}

@Getter
class MatchResult {
    private Long trainerId;             // 트레이너 ID
    private String trainerName;         // 트레이너 이름
    private String mbti;                // 트레이너 MBTI
    private int matchScore;             // 매칭 점수
    private Map<String, Integer> scoreDetails; // 점수 상세 내역
    private TrainerInfo trainerInfo;    // 트레이너 상세 정보
}

실패 응답 구조

@Getter
class ErrorResponse {
    private String status = "error";
    private ErrorData error;
}

@Getter
class ErrorData {
    private String code;        // 에러 코드
    private String message;     // 에러 메시지
    private String details;     // 상세 설명
}

이렇게 응답구조를 일관되게 가져가면 프론트엔드에서 데이터를 처리하기가 훨씬 수월하다.

Lombok을 사용하면?

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
class MatchingResponse {
    private String status = "success";
    private MatchingData data;
}

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
class MatchingData {
    private List<MatchResult> matches;
    private int totalScore;
}

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
class MatchResult {
    private Long trainerId;
    private String trainerName;
    private String mbti;
    private int matchScore;
    private Map<String, Integer> scoreDetails;
    private TrainerInfo trainerInfo;
}

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
class ErrorResponse {
    private String status = "error";
    private ErrorData error;
}

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
class ErrorData {
    private String code;
    private String message;
    private String details;
}

4. 데이터베이스 연동을 위한 Spring Boot + MySQL 설정

application.yml 설정

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mbti_matching?useSSL=false&serverTimezone=UTC
    username: root
    password: yourpassword
    driver-class-name: com.mysql.cj.jdbc.Driver

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

Entity 클래스 생성

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "trainers")
public class Trainer {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private String mbti;

    @ElementCollection
    private List<String> specialties;

    private int experience;
    private double rating;

    @Embedded
    private Address address;
}

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "matching_results")
public class MatchingResult {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    private Trainer trainer;

    private String userMbti;
    private int matchScore;
    private LocalDateTime matchedAt;
}

Repository 인터페이스

@Repository
public interface TrainerRepository extends JpaRepository<Trainer, Long> {
    List<Trainer> findByMbti(String mbti);
    List<Trainer> findBySpecialtiesContaining(String specialty);
}

@Repository
public interface MatchingResultRepository extends JpaRepository<MatchingResult, Long> {
    List<MatchingResult> findByUserMbti(String userMbti);
}

5. 데이터베이스 테이블 설계

trainers (트레이너 정보)

CREATE TABLE trainers (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    mbti VARCHAR(4) NOT NULL,
    experience INT NOT NULL,
    rating DECIMAL(2,1),
    introduction TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

trainer_specialties (트레이너 전문분야)

CREATE TABLE trainer_specialties (
    trainer_id BIGINT,
    specialty VARCHAR(50),
    PRIMARY KEY (trainer_id, specialty),
    FOREIGN KEY (trainer_id) REFERENCES trainers(id)
);

matching_results (매칭 결과)

CREATE TABLE matching_results (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    trainer_id BIGINT,
    user_mbti VARCHAR(4) NOT NULL,
    match_score INT NOT NULL,
    matched_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (trainer_id) REFERENCES trainers(id)
);

mbti_traits (MBTI 특성)

CREATE TABLE mbti_traits (
    mbti_type VARCHAR(4) PRIMARY KEY,
    preferred_training_style JSON,
    communication_style VARCHAR(100),
    learning_preference VARCHAR(100)
);
trainer_reviews (트레이너 리뷰)

sql
CREATE TABLE trainer_reviews (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    trainer_id BIGINT,
    rating INT NOT NULL,
    comment TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (trainer_id) REFERENCES trainers(id)
);

정리하자면,

Spring Boot로 API를 만들 때 전체적인 구조

Controller: API 엔드포인트를 정의하고 요청을 받는 곳 DTO: 요청/응답의 데이터 구조를 정의하는 클래스 Service: 비즈니스 로직이 실제로 구현되는 곳 Entity: 데이터베이스 테이블과 매핑되는 클래스 Repository: 데이터베이스 작업을 처리하는 인터페이스

// 1. Controller + DTO
@RestController
@RequestMapping("/api/v1")
public class MatchingController {
    @PostMapping("/matching")
    public ResponseEntity<MatchingResponseDTO> matchTrainer(@RequestBody MatchingRequestDTO request) {
        return ResponseEntity.ok(matchingService.findMatch(request));
    }
}

// 2. Service (비즈니스 로직)
@Service
public class MatchingService {
    public int calculateMatchScore(String userMbti, Trainer trainer) {
        int score = 0;
        score += calculateMbtiCompatibility(userMbti, trainer.getMbti());
        ...
    }
}

// 3. Entity
@Entity
@Table(name = "trainers")
public class Trainer {
    @Id
    private Long id;
    private String mbti;
    ...
}

// 4. Repository
@Repository
public interface TrainerRepository extends JpaRepository<Trainer, Long> {
    List<Trainer> findByMbti(String mbti);
}

우리가 만드는 API:

@RestController
public class TrainerController {
    @Autowired
    private TrainerRepository trainerRepository; // 데이터베이스 연결

    @GetMapping("/api/v1/trainers")
    public List<Trainer> getTrainers() {
        // MySQL 데이터베이스에서 트레이너 정보를 가져옴
        return trainerRepository.findAll();
    }
}

• 외부 API를 사용할 때는 그 회사의 데이터베이스에서 데이터를 가져오는 것이고 우리가 API를 만들 때는 우리가 직접 MySQL같은 데이터베이스를 만들고, 거기에 데이터를 넣어서 사용하는 것.
• 그래서 아까 테이블 설계에서 만든 데이터베이스 테이블에 실제 트레이너 정보, MBTI 정보 등을 넣어야 API가 제대로 동작한다.

SQL INSERT 문을 사용해 데이터 넣기

MBTI 특성 데이터

-- 기존 데이터 삭제 및 AUTO_INCREMENT 초기화
DELETE FROM mbti_traits;
ALTER TABLE mbti_traits AUTO_INCREMENT = 1;

-- mbti_traits 데이터 삽입
INSERT INTO mbti_traits (mbti_type, preferred_training_style, communication_style, learning_preference)
VALUES 
('ISTJ', '{"styles": ["structured", "consistent", "traditional"], "focus": ["detail-oriented", "routine-based"]}', '명확하고 구체적인 지시', '단계별 체계적 학습'),
('ISFJ', '{"styles": ["supportive", "organized", "patient"], "focus": ["personal-care", "steady-progress"]}', '따뜻하고 개인적인 관심', '실제 경험 기반 학습'),
('INFJ', '{"styles": ["holistic", "personalized", "growth-focused"], "focus": ["long-term-vision", "meaningful-goals"]}', '통찰력 있는 조언', '개념적 이해와 실천'),
('INTJ', '{"styles": ["analytical", "efficient", "goal-oriented"], "focus": ["strategy", "optimization"]}', '논리적이고 직접적인 소통', '이론과 시스템 이해'),
('ISTP', '{"styles": ["practical", "adaptable", "hands-on"], "focus": ["technique", "immediate-results"]}', '간단명료한 설명', '실전 중심 학습'),
('ISFP', '{"styles": ["gentle", "flexible", "individual"], "focus": ["comfort", "enjoyment"]}', '부드럽고 개인적인 방식', '감각적 체험 학습'),
('INFP', '{"styles": ["authentic", "value-driven", "creative"], "focus": ["personal-meaning", "inner-motivation"]}', '공감적이고 영감을 주는 소통', '자기주도적 학습'),
('INTP', '{"styles": ["logical", "innovative", "knowledge-based"], "focus": ["understanding", "mastery"]}', '개념적이고 논리적인 설명', '원리 탐구 중심'),
('ESTP', '{"styles": ["dynamic", "energetic", "action-oriented"], "focus": ["challenge", "variety"]}', '즉각적이고 활동적인 소통', '행동 중심 학습'),
('ESFP', '{"styles": ["fun", "social", "encouraging"], "focus": ["enjoyment", "social-interaction"]}', '열정적이고 친근한 소통', '그룹 활동 학습'),
('ENFP', '{"styles": ["enthusiastic", "creative", "motivating"], "focus": ["inspiration", "possibilities"]}', '열정적이고 영감을 주는 소통', '창의적 접근 학습'),
('ENTP', '{"styles": ["challenging", "innovative", "strategic"], "focus": ["improvement", "experimentation"]}', '도전적이고 지적인 토론', '실험적 학습'),
('ESTJ', '{"styles": ["organized", "result-driven", "directive"], "focus": ["efficiency", "achievement"]}', '명확한 지시와 피드백', '구조화된 목표 중심'),
('ESFJ', '{"styles": ["supportive", "collaborative", "structured"], "focus": ["harmony", "encouragement"]}', '친근하고 상세한 안내', '협력적 학습'),
('ENFJ', '{"styles": ["inspiring", "people-focused", "growth-oriented"], "focus": ["development", "potential"]}', '동기부여와 격려', '관계 중심 학습'),
('ENTJ', '{"styles": ["strategic", "challenging", "leadership"], "focus": ["achievement", "excellence"]}', '전략적이고 결과 중심적 소통', '목표 지향적 학습');

트레이너 데이터 (30명)

-- 기존 데이터 삭제 및 AUTO_INCREMENT 초기화
DELETE FROM trainers;
ALTER TABLE trainers AUTO_INCREMENT = 1;

-- trainers 데이터 삽입
INSERT INTO trainers (name, mbti, experience, rating, introduction, created_at) 
VALUES 
('김지훈', 'ENFJ', 5, 4.8, '따뜻한 동기부여로 목표 달성을 돕는 트레이너입니다.', NOW()),
('이서연', 'INTJ', 7, 4.9, '과학적 접근으로 최적의 결과를 만듭니다.', NOW()),
('박민준', 'ISTP', 3, 4.7, '효율적인 동작과 자세 교정에 강점이 있습니다.', NOW()),
('정다은', 'ENFP', 4, 4.6, '즐거운 운동으로 건강한 습관을 만들어요!', NOW()),
('최준호', 'ISTJ', 8, 4.9, '체계적인 프로그램으로 확실한 변화를 약속합니다.', NOW()),
('한미래', 'ESFJ', 2, 4.5, '초보자도 편하게 시작할 수 있는 트레이닝을 제공합니다.', NOW()),
('송태현', 'ENTJ', 6, 4.8, '목표 달성을 위한 명확한 방향을 제시합니다.', NOW()),
('임수진', 'ISFP', 4, 4.7, '개인의 특성을 고려한 맞춤형 트레이닝을 진행합니다.', NOW()),
('강동원', 'ESTP', 5, 4.6, '다이나믹한 트레이닝으로 재미있게 운동해요!', NOW()),
('윤서아', 'INFJ', 3, 4.8, '건강한 마인드와 함께하는 전인적 트레이닝', NOW()),
('조현우', 'ESTJ', 9, 4.9, '목표 달성을 위한 체계적인 프로그램을 제공합니다.', NOW()),
('백지영', 'INTP', 4, 4.7, '과학적 원리 기반의 효과적인 트레이닝', NOW()),
('신준영', 'ESFP', 3, 4.5, '즐거운 분위기로 운동을 재미있게!', NOW()),
('오민지', 'ISFJ', 6, 4.8, '꾸준한 관리와 케어로 함께 성장해요', NOW()),
('권현석', 'ENTP', 5, 4.7, '창의적인 운동 방법으로 지루하지 않게!', NOW()),
('유하은', 'INFP', 2, 4.6, '개인의 페이스를 존중하는 맞춤 트레이닝', NOW()),
('장민재', 'ENFJ', 7, 4.9, '전문적인 지도와 따뜻한 응원을 함께 제공합니다.', NOW()),
('황세아', 'ISTJ', 4, 4.7, '기초부터 차근차근 탄탄하게 지도합니다.', NOW()),
('문지원', 'ESTP', 5, 4.8, '활기찬 트레이닝으로 운동이 즐거워집니다.', NOW()),
('양현직', 'INTJ', 8, 4.9, '데이터 기반의 과학적인 트레이닝을 제공합니다.', NOW()),
('구자민', 'ESFJ', 3, 4.6, '친근한 방식으로 편안한 트레이닝을 진행합니다.', NOW()),
('배수현', 'ENFP', 4, 4.7, '긍정적인 에너지로 즐거운 운동을 만듭니다.', NOW()),
('홍준표', 'ISTP', 6, 4.8, '정확한 자세와 효율적인 동작을 중점으로 지도합니다.', NOW()),
('서지안', 'ENTJ', 5, 4.7, '목표 달성을 위한 전략적인 트레이닝을 제공합니다.', NOW()),
('남궁원', 'ISFP', 3, 4.6, '개인의 특성을 고려한 맞춤형 프로그램을 진행합니다.', NOW()),
('도하윤', 'INFJ', 4, 4.8, '심신의 균형을 고려한 전인적 트레이닝을 제공합니다.', NOW()),
('설윤아', 'ESTJ', 7, 4.9, '체계적이고 효율적인 트레이닝으로 목표를 달성합니다.', NOW()),
('진현서', 'INTP', 5, 4.7, '과학적 접근으로 최적의 트레이닝을 설계합니다.', NOW()),
('추민혁', 'ESFP', 2, 4.5, '즐거운 분위기에서 효과적인 운동을 진행합니다.', NOW()),
('노지현', 'ISFJ', 6, 4.8, '세심한 관리와 꾸준한 피드백을 제공합니다.', NOW());

-- trainer_specialties 데이터 삽입
INSERT INTO trainer_specialties (trainer_id, specialty)
VALUES 
(1, 'weight-training'), (1, 'diet-management'),
(2, 'bodybuilding'), (2, 'posture-correction'),
(3, 'crossfit'), (3, 'functional-training'),
(4, 'diet-management'), (4, 'yoga'),
(5, 'weight-training'), (5, 'powerlifting'),
(6, 'pilates'), (6, 'rehabilitation'),
(7, 'bodybuilding'), (7, 'weight-training'),
(8, 'yoga'), (8, 'stretching'),
(9, 'crossfit'), (9, 'hiit'),
(10, 'meditation'), (10, 'holistic-training'),
(11, 'weight-training'), (11, 'sports-conditioning'),
(12, 'functional-training'), (12, 'mobility'),
(13, 'dance-fitness'), (13, 'cardio'),
(14, 'rehabilitation'), (14, 'senior-fitness'),
(15, 'calisthenics'), (15, 'parkour'),
(16, 'yoga'), (16, 'mindfulness'),
(17, 'weight-training'), (17, 'diet-management'),
(18, 'posture-correction'), (18, 'core-training'),
(19, 'crossfit'), (19, 'olympic-lifting'),
(20, 'bodybuilding'), (20, 'contest-prep'),
(21, 'pilates'), (21, 'pre-natal'),
(22, 'dance-fitness'), (22, 'zumba'),
(23, 'martial-arts'), (23, 'kickboxing'),
(24, 'sports-conditioning'), (24, 'athletic-training'),
(25, 'yoga'), (25, 'meditation'),
(26, 'holistic-training'), (26, 'wellness-coaching'),
(27, 'weight-training'), (27, 'powerlifting'),
(28, 'functional-training'), (28, 'mobility'),
(29, 'cardio'), (29, 'hiit'),
(30, 'rehabilitation'), (30, 'senior-fitness');

사용자(회원) 데이터 (50명)

-- 기존 데이터 삭제 및 AUTO_INCREMENT 초기화
DELETE FROM users;
ALTER TABLE users AUTO_INCREMENT = 1;

-- users 테이블 데이터 삽입
INSERT INTO users (username, mbti, age, gender, fitness_goal, preferred_training_style, experience_level, created_at) 
VALUES 
('user1', 'ENFJ', 25, 'F', 'weight-loss', '{"preferred": ["supportive", "structured"]}', 'beginner', NOW()),
('user2', 'INTJ', 30, 'M', 'muscle-gain', '{"preferred": ["analytical", "independent"]}', 'intermediate', NOW()),
('user3', 'ISFP', 28, 'F', 'flexibility', '{"preferred": ["gentle", "creative"]}', 'beginner', NOW()),
('user4', 'ENTP', 35, 'M', 'strength', '{"preferred": ["challenging", "varied"]}', 'advanced', NOW()),
('user5', 'ISFJ', 27, 'F', 'wellness', '{"preferred": ["consistent", "supportive"]}', 'beginner', NOW()),
('user6', 'ESTP', 32, 'M', 'athletic', '{"preferred": ["dynamic", "intense"]}', 'intermediate', NOW()),
('user7', 'INFP', 29, 'F', 'mindfulness', '{"preferred": ["gentle", "personal"]}', 'beginner', NOW()),
('user8', 'ESTJ', 31, 'M', 'weight-loss', '{"preferred": ["structured", "efficient"]}', 'intermediate', NOW()),
('user9', 'ENFP', 26, 'F', 'toning', '{"preferred": ["fun", "creative"]}', 'beginner', NOW()),
('user10', 'ISTP', 33, 'M', 'strength', '{"preferred": ["practical", "technical"]}', 'advanced', NOW()),
('user11', 'ENTJ', 28, 'F', 'muscle-gain', '{"preferred": ["challenging", "efficient"]}', 'intermediate', NOW()),
('user12', 'INFJ', 34, 'M', 'wellness', '{"preferred": ["holistic", "meaningful"]}', 'beginner', NOW()),
('user13', 'ESFP', 27, 'F', 'fitness', '{"preferred": ["fun", "social"]}', 'intermediate', NOW()),
('user14', 'ISTJ', 36, 'M', 'strength', '{"preferred": ["structured", "consistent"]}', 'advanced', NOW()),
('user15', 'ESFJ', 29, 'F', 'weight-loss', '{"preferred": ["supportive", "social"]}', 'beginner', NOW()),
('user16', 'INTP', 31, 'M', 'muscle-gain', '{"preferred": ["analytical", "independent"]}', 'intermediate', NOW()),
('user17', 'ENFJ', 28, 'F', 'flexibility', '{"preferred": ["encouraging", "structured"]}', 'beginner', NOW()),
('user18', 'ISTP', 33, 'M', 'strength', '{"preferred": ["practical", "efficient"]}', 'advanced', NOW()),
('user19', 'ENFP', 26, 'F', 'wellness', '{"preferred": ["fun", "creative"]}', 'beginner', NOW()),
('user20', 'INTJ', 35, 'M', 'muscle-gain', '{"preferred": ["analytical", "systematic"]}', 'intermediate', NOW()),
('user21', 'ISFP', 27, 'F', 'toning', '{"preferred": ["gentle", "personal"]}', 'beginner', NOW()),
('user22', 'ESTJ', 32, 'M', 'strength', '{"preferred": ["structured", "efficient"]}', 'advanced', NOW()),
('user23', 'INFP', 29, 'F', 'mindfulness', '{"preferred": ["gentle", "creative"]}', 'beginner', NOW()),
('user24', 'ENTP', 34, 'M', 'athletic', '{"preferred": ["challenging", "varied"]}', 'intermediate', NOW()),
('user25', 'ISFJ', 28, 'F', 'wellness', '{"preferred": ["supportive", "consistent"]}', 'beginner', NOW()),
('user26', 'ESTP', 31, 'M', 'strength', '{"preferred": ["dynamic", "challenging"]}', 'advanced', NOW()),
('user27', 'INFJ', 27, 'F', 'flexibility', '{"preferred": ["holistic", "meaningful"]}', 'beginner', NOW()),
('user28', 'ESFP', 33, 'M', 'fitness', '{"preferred": ["fun", "energetic"]}', 'intermediate', NOW()),
('user29', 'ISTJ', 30, 'F', 'weight-loss', '{"preferred": ["structured", "consistent"]}', 'beginner', NOW()),
('user30', 'ENTJ', 35, 'M', 'muscle-gain', '{"preferred": ["challenging", "efficient"]}', 'advanced', NOW()),
('user31', 'ESFJ', 28, 'F', 'wellness', '{"preferred": ["supportive", "social"]}', 'beginner', NOW()),
('user32', 'INTP', 32, 'M', 'strength', '{"preferred": ["analytical", "technical"]}', 'intermediate', NOW()),
('user33', 'ENFJ', 29, 'F', 'toning', '{"preferred": ["encouraging", "structured"]}', 'beginner', NOW()),
('user34', 'ISTP', 34, 'M', 'athletic', '{"preferred": ["practical", "technical"]}', 'advanced', NOW()),
('user35', 'ENFP', 27, 'F', 'flexibility', '{"preferred": ["fun", "creative"]}', 'beginner', NOW()),
('user36', 'INTJ', 33, 'M', 'muscle-gain', '{"preferred": ["analytical", "systematic"]}', 'intermediate', NOW()),
('user37', 'ISFP', 28, 'F', 'mindfulness', '{"preferred": ["gentle", "personal"]}', 'beginner', NOW()),
('user38', 'ESTJ', 31, 'M', 'strength', '{"preferred": ["structured", "efficient"]}', 'advanced', NOW()),
('user39', 'INFP', 26, 'F', 'wellness', '{"preferred": ["gentle", "creative"]}', 'beginner', NOW()),
('user40', 'ENTP', 35, 'M', 'athletic', '{"preferred": ["challenging", "varied"]}', 'intermediate', NOW()),
('user41', 'ISFJ', 29, 'F', 'weight-loss', '{"preferred": ["supportive", "consistent"]}', 'beginner', NOW()),
('user42', 'ESTP', 32, 'M', 'strength', '{"preferred": ["dynamic", "challenging"]}', 'advanced', NOW()),
('user43', 'INFJ', 28, 'F', 'flexibility', '{"preferred": ["holistic", "meaningful"]}', 'beginner', NOW()),
('user44', 'ESFP', 34, 'M', 'fitness', '{"preferred": ["fun", "energetic"]}', 'intermediate', NOW()),
('user45', 'ISTJ', 27, 'F', 'toning', '{"preferred": ["structured", "consistent"]}', 'beginner', NOW()),
('user46', 'ENTJ', 33, 'M', 'muscle-gain', '{"preferred": ["challenging", "efficient"]}', 'advanced', NOW()),
('user47', 'ESFJ', 30, 'F', 'wellness', '{"preferred": ["supportive", "social"]}', 'beginner', NOW()),
('user48', 'INTP', 35, 'M', 'strength', '{"preferred": ["analytical", "technical"]}', 'intermediate', NOW()),
('user49', 'ENFJ', 28, 'F', 'mindfulness', '{"preferred": ["encouraging", "structured"]}', 'beginner', NOW()),
('user50', 'ISTP', 32, 'M', 'athletic', '{"preferred": ["practical", "technical"]}', 'advanced', NOW());

매칭 결과와 리뷰 데이터

-- 기존 데이터 삭제 및 AUTO_INCREMENT 초기화
DELETE FROM matching_results;
ALTER TABLE matching_results AUTO_INCREMENT = 1;

DELETE FROM trainer_reviews;
ALTER TABLE trainer_reviews AUTO_INCREMENT = 1;

-- matching_results 데이터 삽입
INSERT INTO matching_results (trainer_id, user_mbti, match_score, matched_at)
VALUES 
-- ENFJ 유저들의 매칭
(2, 'ENFJ', 85, '2024-01-15'),
(7, 'ENFJ', 92, '2024-01-16'),
(15, 'ENFJ', 88, '2024-01-17'),
(20, 'ENFJ', 90, '2024-01-18'),

-- INTJ 유저들의 매칭
(5, 'INTJ', 95, '2024-01-19'),
(12, 'INTJ', 87, '2024-01-20'),
(18, 'INTJ', 89, '2024-01-21'),

-- ISFP 유저들의 매칭
(8, 'ISFP', 91, '2024-01-22'),
(16, 'ISFP', 86, '2024-01-23'),
(25, 'ISFP', 88, '2024-01-24'),

-- ENTP 유저들의 매칭
(3, 'ENTP', 93, '2024-02-01'),
(9, 'ENTP', 87, '2024-02-02'),
(22, 'ENTP', 85, '2024-02-03'),

-- 다른 MBTI 유형들의 매칭
(1, 'ISFJ', 89, '2024-02-04'),
(4, 'ESTP', 92, '2024-02-05'),
(6, 'INFP', 84, '2024-02-06'),
(10, 'ESTJ', 88, '2024-02-07'),
(11, 'ENFP', 90, '2024-02-08'),
(13, 'ISTP', 86, '2024-02-09'),
(14, 'ENTJ', 91, '2024-02-10');

-- trainer_reviews 데이터 삽입
INSERT INTO trainer_reviews (trainer_id, rating, comment, created_at)
VALUES 
(1, 5, '트레이너님의 꼼꼼한 지도 덕분에 운동이 많이 늘었어요!', '2024-01-20'),
(1, 4, '체계적인 프로그램으로 목표 달성에 도움이 되었습니다.', '2024-01-21'),
(2, 5, '과학적인 접근방식이 매우 인상적이었습니다.', '2024-01-22'),
(2, 5, '전문성이 돋보이는 트레이너님입니다.', '2024-01-23'),
(3, 4, '효율적인 운동 방법을 잘 알려주셨어요.', '2024-01-24'),
(4, 5, '즐겁게 운동할 수 있도록 도와주셔서 감사합니다.', '2024-01-25'),
(5, 5, '정확한 자세 교정으로 통증이 많이 개선되었어요.', '2024-01-26'),
(6, 4, '초보자도 쉽게 따라할 수 있게 설명해주셔서 좋았습니다.', '2024-01-27'),
(7, 5, '목표 달성을 위한 동기부여가 큰 도움이 되었어요.', '2024-01-28'),
(8, 4, '맞춤형 프로그램으로 꾸준한 관리가 가능했습니다.', '2024-01-29'),
(9, 5, '활기찬 에너지로 운동이 즐거웠어요!', '2024-01-30'),
(10, 5, '전인적인 관리로 건강이 많이 개선되었습니다.', '2024-02-01'),
(11, 4, '체계적인 프로그램이 마음에 들었어요.', '2024-02-02'),
(12, 5, '전문적인 지식을 바탕으로 한 트레이닝이 좋았습니다.', '2024-02-03'),
(13, 4, '즐거운 분위기에서 운동할 수 있었어요.', '2024-02-04'),
(14, 5, '꾸준한 관리와 피드백이 도움이 되었습니다.', '2024-02-05'),
(15, 4, '창의적인 운동 방법으로 지루하지 않았어요.', '2024-02-06');

사용자 선호도와 세션 기록 데이터

-- 기존 데이터 삭제 및 AUTO_INCREMENT 초기화
DELETE FROM user_preferences;
ALTER TABLE user_preferences AUTO_INCREMENT = 1;

DELETE FROM training_sessions;
ALTER TABLE training_sessions AUTO_INCREMENT = 1;

-- user_preferences 데이터 삽입
INSERT INTO user_preferences (user_id, preferred_time, preferred_intensity, health_conditions, goals, created_at)
VALUES 
(1, 'morning', 'moderate', '없음', '{"primary": "weight-loss", "secondary": "muscle-tone"}', NOW()),
(2, 'evening', 'high', '허리 통증', '{"primary": "strength", "secondary": "posture"}', NOW()),
(3, 'afternoon', 'low', '없음', '{"primary": "flexibility", "secondary": "stress-relief"}', NOW()),
(4, 'morning', 'high', '없음', '{"primary": "muscle-gain", "secondary": "strength"}', NOW()),
(5, 'evening', 'moderate', '어깨 통증', '{"primary": "rehabilitation", "secondary": "flexibility"}', NOW());

-- training_sessions 데이터 삽입
INSERT INTO training_sessions (user_id, trainer_id, session_date, duration, session_type, notes, status)
VALUES 
-- 사용자 1의 세션
(1, 3, '2024-01-15', 60, 'personal', '체중 감량 프로그램 시작', 'completed'),
(1, 3, '2024-01-17', 60, 'personal', '유산소 운동 강화', 'completed'),
(1, 3, '2024-01-19', 60, 'personal', '근력 운동 도입', 'completed'),

-- 사용자 2의 세션
(2, 5, '2024-01-16', 90, 'personal', '웨이트 트레이닝 기초', 'completed'),
(2, 5, '2024-01-18', 90, 'personal', '자세 교정 중점', 'completed'),
(2, 5, '2024-01-20', 90, 'personal', '강도 상승', 'cancelled'),

-- 사용자 3의 세션
(3, 8, '2024-01-15', 60, 'personal', '스트레칭 위주 프로그램', 'completed'),
(3, 8, '2024-01-18', 60, 'personal', '코어 강화 운동 추가', 'completed'),
(3, 8, '2024-01-21', 60, 'personal', '유연성 향상 확인', 'scheduled'),

-- 사용자 4의 세션
(4, 2, '2024-01-17', 90, 'personal', '근비대 프로그램 시작', 'completed'),
(4, 2, '2024-01-19', 90, 'personal', '식단 조절 병행', 'completed'),
(4, 2, '2024-01-21', 90, 'personal', '1RM 측정', 'scheduled'),

-- 사용자 5의 세션
(5, 6, '2024-01-16', 60, 'rehabilitation', '어깨 재활 운동', 'completed'),
(5, 6, '2024-01-18', 60, 'rehabilitation', '가동범위 확인', 'completed'),
(5, 6, '2024-01-20', 60, 'rehabilitation', '단계별 부하 증가', 'scheduled');

-- matching_statistics 데이터 삽입
INSERT INTO matching_statistics (trainer_id, total_matches, successful_matches, avg_rating, updated_at)
VALUES 
(1, 45, 40, 4.8, NOW()),
(2, 38, 35, 4.9, NOW()),
(3, 42, 38, 4.7, NOW()),
(4, 30, 27, 4.6, NOW()),
(5, 50, 45, 4.9, NOW()),
(6, 25, 22, 4.5, NOW()),
(7, 35, 32, 4.8, NOW()),
(8, 28, 25, 4.7, NOW()),
(9, 33, 30, 4.6, NOW()),
(10, 40, 36, 4.8, NOW());

함수가 정의될 때 발생하는 2가지 동작

1. 해당 함수에 Constructor 자격이 부여되고, 이 자격이 부여된 것만 new를 통해 객체 생성 가능

2. 해당 함수의 Prototype Object 생성하고 연결

Prototype Link, Prototype Object

• 이 두가지를 통틀어 Prototype 이라고 부른다.

점점 최상위로 타고타고 올라가면 결국 js도 Object가 최상위 타고 타고 올라가는 것을 Prototype Chain이라고 부른다.

1. 객체 생성과 생성자 함수

JavaScript에서 객체를 생성하는 가장 기본적인 방법은 생성자 함수를 사용하는 것이다. 생성자 함수는 객체를 만드는 틀이 되며, 이를 통해 생성된 객체를 인스턴스라고 한다.

기본적인 생성자 함수

function Person() {}
const person = new Person();  // Person 객체 생성
console.log(person, typeof person);  // Person {} 'object'

속성이 있는 생성자 함수

function Person(name, age) {
    this.name = name;
    this.age = age;

    this.hello = function() {
        console.log(`Hello, I'm ${this.name}`);
    };
}

const person = new Person('Mark', 37);
person.hello();  // "Hello, I'm Mark"

2. 프로토타입과 상속

JavaScript는 프로토타입을 통해 객체 간의 상속을 구현한다. 모든 객체는 프로토타입 체인을 통해 다른 객체의 속성과 메서드를 상속받을 수 있다.

프로토타입을 이용한 메서드 정의

function Animal(type, name, sound) {
    this.type = type;
    this.name = name;
    this.sound = sound;
}

Animal.prototype.say = function() {
    console.log(this.sound);
};

function Dog(name, sound) {
    Animal.call(this, '개', name, sound);
}
Dog.prototype = Animal.prototype;

const dog = new Dog('멍멍이', '왈왈');
dog.say();  // "왈왈"

3. 클래스 문법

ES6부터는 class 키워드를 사용하여 더 명확하고 직관적인 객체 지향 프로그래밍이 가능해졌다.

기본 클래스 정의

class Person {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    hello() {
        console.log(`Hello, I'm ${this.name}`);
    }
}

const person = new Person('Mark', 37);
person.hello();

getter와 setter

class User {
    _name = 'no name';

    get name() {
        return this._name + "!";
    }

    set name(value) {
        this._name = value;
    }
}

정적 메서드와 속성

class Calculator {
    static PI = 3.14159;

    static sum(a, b) {
        return a + b;
    }
}

console.log(Calculator.PI);      // 3.14159
console.log(Calculator.sum(1, 2)); // 3

클래스 상속

class Animal {
    constructor(name) {
        this.name = name;
    }

    speak() {
        console.log(`${this.name} makes a sound.`);
    }
}

class Dog extends Animal {
    constructor(name) {
        super(name);
    }

    speak() {
        console.log(`${this.name} barks.`);
    }
}

const dog = new Dog('Rex');
dog.speak();  // "Rex barks."

주요 특징 정리

1. 클래스는 호이스팅되지 않으므로 선언 전에 사용할 수 없다.
2. 클래스 내의 모든 메서드는 엄격 모드(strict mode)에서 실행된다.
3. 상속을 사용할 때는 반드시 super()를 호출해야 한다.
4. 정적 메서드는 인스턴스가 아닌 클래스 자체에서 호출한다.

결론

JavaScript의 객체 지향 프로그래밍은 프로토타입 기반으로 동작하며, ES6의 클래스 문법은 이를 더 편리하게 사용할 수 있게 해준다. 클래스는 실제로 프로토타입 상속의 문법적 설탕(Syntactic Sugar)이지만, 코드의 가독성과 유지보수성을 크게 향상시킨다.

• JavaScript에서 Scope는 변수가 유효한 범위를 의미
• 코드의 어느 부분에서 변수에 접근하고 사용할 수 있는지를 결정하는 규칙

Scope의 종류

• JavaScript에는 크게 3가지 종류의 Scope가 있습니다:

1. Global Scope (전역 범위)

• 전역 범위에 선언된 변수는 코드 어디에서나 접근이 가능

let globalVar = "나는 전역 변수";
const globalConst = "나도 전역 변수";

function someFunction() {
    console.log(globalVar);     // "나는 전역 변수" 출력
    console.log(globalConst);   // "나도 전역 변수" 출력
}

someFunction();
console.log(globalVar);         // "나는 전역 변수" 출력

2. Function Scope (함수 범위)

• 함수 내부에서 선언된 변수는 해당 함수 내에서만 접근이 가능
• 특히 var 키워드로 선언된 변수는 함수 스코프를 가짐

function myFunction() {
    var functionVar = "함수 안에서만 살아요";
    console.log(functionVar);   // "함수 안에서만 살아요" 출력
}

myFunction();
// console.log(functionVar);    // 에러! functionVar는 함수 밖에서 접근 불가

3. Block Scope (블록 범위)

• 중괄호 {} 내부에서 let이나 const로 선언된 변수는 해당 블록 내에서만 접근이 가능

if (true) {
    let blockVar = "블록 안에서만 살아요";
    const blockConst = "나도 블록 안에서만";
    console.log(blockVar);      // "블록 안에서만 살아요" 출력
    console.log(blockConst);    // "나도 블록 안에서만" 출력
}

// console.log(blockVar);       // 에러! 블록 밖이라 접근 불가
// console.log(blockConst);     // 에러! 블록 밖이라 접근 불가

변수 선언 방식에 따른 Scope 차이

var vs let/const

function scopeTest() {
    var functionScoped = "var는 함수 스코프";
    let blockScoped = "let은 블록 스코프";

    if (true) {
        var functionScoped2 = "여전히 함수 스코프";
        let blockScoped2 = "블록 스코프";
        console.log(functionScoped);   // 접근 가능
        console.log(blockScoped);      // 접근 가능
    }

    console.log(functionScoped2);      // 접근 가능
    // console.log(blockScoped2);      // 에러! 블록을 벗어남
}

키워드 없는 선언 (주의!)

function dangerousScope() {
    noKeyword = "위험해요!";  // 자동으로 전역 변수가 됨
}

dangerousScope();
console.log(noKeyword);  // "위험해요!" 출력 - 의도치 않은 전역 변수 생성

실제 사용 예시와 주의사항

// 블록 외부에서 선언
const outer1 = 100;
let outer2 = 200;
var outer3 = 300;

{
    // 블록 내부에서 외부 변수 접근
    console.log(outer1);  // 100
    console.log(outer2);  // 200
    console.log(outer3);  // 300

    // 블록 내부에서 새로운 변수 선언
    const inner1 = "블록 안";
    let inner2 = "블록 안";
    var inner3 = "함수가 아닌 블록에서 var는 전역이 됨";
}

// console.log(inner1);  // 에러! block scope
// console.log(inner2);  // 에러! block scope
console.log(inner3);     // "함수가 아닌 블록에서 var는 전역이 됨" - var의 특이한 동작

호이스팅이란?

• JavaScript에서 변수나 함수의 선언이 코드의 최상단으로 끌어올려지는 것처럼 동작하는 현상

함수 호이스팅

• 함수 선언문은 전체가 호이스팅

// 함수를 호출하고
hello();  // "안녕하세요!" 출력

// 나중에 함수를 선언해도 정상 작동합니다
function hello() {
    console.log("안녕하세요!");
}

• 이것이 가능한 이유는 JavaScript 엔진이 코드를 실행하기 전에 함수 선언을 최상단으로 끌어올리기 때문

변수 호이스팅

• var로 선언된 변수는 호이스팅되지만, 초기화는 호이스팅되지 않음

console.log(name);  // undefined
var name = "John";  

// 위 코드는 실제로 다음과 같이 동작
var name;          // 선언부가 위로 호이스팅됨
console.log(name); // undefined
name = "John";     // 할당은 원래 위치에서 실행

var vs let/const

// var의 경우
console.log(varVariable);  // undefined
var varVariable = 10;

// let의 경우
console.log(letVariable);  // ReferenceError!
let letVariable = 10;

// const의 경우
console.log(constVariable);  // ReferenceError!
const constVariable = 10;

호이스팅의 실제 예제

1. 함수 호이스팅

// 함수 호출이 선언보다 먼저 와도 동작
hello2();  // "hello2() 호출 실행되나요?" 출력

function hello2() {
    console.log("hello2() 호출 실행되나요?");
}

2. var 호이스팅의 특이한 동작

console.log(val_2);  // undefined
var val_2;          // 선언만 호이스팅됨

console.log(val_3);  // undefined
var val_3 = 10;     // 선언은 호이스팅되지만 할당은 그대로

val_4++;            // NaN - undefined에 증가 연산을 시도
console.log(val_4); // NaN
var val_4 = 10;

호이스팅이 문제가 되는 경우

1. 의도치 않은 undefined

function getName() {
    console.log(name);  // undefined
    var name = "John";  // 의도와 다르게 undefined 출력
    return name;
}

2. 변수 재선언으로 인한 혼란

var x = 1;
{
    console.log(x);  // undefined
    var x = 2;       // 호이스팅으로 인해 위의 x가 undefined
}

정리

1. let과 const 사용하기

   • 호이스팅으로 인한 혼란을 방지
   • 더 예측 가능한 스코프 규칙

2. 함수 선언을 코드 최상단에 배치

   • 호이스팅에 의존하지 않고 코드를 명확하게 작성

3. 변수 선언과 초기화를 함께하기

   • 변수를 사용하기 전에 확실히 초기화

• 호이스팅은 JavaScript의 독특한 특성 중 하나
• ES6에서 도입된 let과 const를 사용하면 호이스팅으로 인한 혼란을 크게 줄일 수 있음
• 호이스팅을 이해하는 것은 JavaScript 코드의 동작을 예측하고 디버깅하는 데 매우 중요

++ 나중에 ESLint 라는 도구를 사용 시, hoisting 이 발생하는 곳에 경고 발생함

this 바인딩과 호출 방식 이해하기

• 메서드 호출 방식에 따른 this 바인딩의 차이점

1. 일반적인 메서드 정의 방식들

const dog = {
    sound: "멍멍!",

    // 1. 이름 있는 함수
    say1: function aaa() {
        console.log(`say1: ${this.sound}`);
    },

    // 2. 익명 함수
    say2: function() {
        console.log(`say2: ${this.sound}`);
    },

    // 3. ES6 메서드 단축 구문
    say3() {
        console.log(`say3: ${this.sound}`);
    },

    // 4. 화살표 함수 (this 바인딩 주의!)
    say4: () => {
        console.log(`say4: ${this.sound}`); // undefined
    }
}

2. this 바인딩의 차이점

• 메서드를 다른 변수에 할당할 때 this 바인딩이 어떻게 달라지는지 확인

const cat = {
    sound: "야옹~"
};

// 1. 메서드로 호출 - 정상 동작
cat.say1 = dog.say1;
cat.say1();  // "야옹~" 출력

// 2. 일반 변수에 할당 - this 바인딩 끊김
const 개냥이 = cat.say1;
개냥이();  // undefined

3. 해결 방법

• this 바인딩이 끊기는 문제를 해결하는 여러 방법

// 1. bind() 사용
const 개냥이1 = cat.say1.bind(cat);

// 2. 화살표 함수로 감싸서 메서드 호출 형태 유지
const 개냥이2 = () => cat.say1();

// 3. call() 사용
const 개냥이3 = cat.say1;
개냥이3.call(cat);

정리

• 메서드 호출 형태(객체.메서드())가 this 바인딩에 중요한 영향을 미친다.
• 화살표 함수를 메서드로 직접 정의하면 this 바인딩이 일어나지 않는다.
• 화살표 함수로 메서드를 감쌀 때는 내부에서 메서드 호출 형태를 유지하면 정상 동작한다.

• 특정 DB에서 동작

• @Query에 nativeQuery = true 속성 추가

  // Native Query 사용
    @Query(value = "select * from book", nativeQuery = true)
    List<Book> findAllCustom1();

• 특정 DB에 의존 시, JPA의 장점에서 벗어남

• DB 벤더를 바꾸거나, 이종 DB로 마이그레이션 하는 게 현업에서 흔한 일 아님

Native Query 사용 이유

1. 성능 이슈 해결

// Native Query로 Update
    @Transactional  // UPDATE, INSERT, DELETE 수행하는 @Query 수행 시
    @Modifying  //  UPDATE, INSERT,DELETE 수행하는 @Query 임을 알림
    @Query(value = "update book set category = 'IT 전문서'", nativeQuery = true)
    int updateCategories();
    // DML 의 경우 리턴타입이 void, int, long 일수 있다.
    // int 나 long 리턴하게 되면 affected row 를 받게 된다.

2. JPA 기본 제공하는 기능이 아닐 시

// JPA 에선 지원하지 않는 쿼리
    @Query(value="show tables", nativeQuery = true)
    List<String> showTables();

Converter

• JPA에서 Entity의 필드와 데이터베이스 칼럼 사이의 변환을 담당
• 예시:
  • enum: Converter 사용 / 정의한 순서대로 들어가는 Ordinal, 문자열 둘 중 하나를 쓰는데 가급적 문자열을 쓰도록 권장됨(유지보수를 위해)
  • enum Ordinal일 경우: OrdinalEnumValueConverter 동작

기본 사용법

• 기본적으로 JPA는 다음과 같은 단순 타입 변환을 자동으로 해준다

  @Entity
  public class Book {
    private String name;        // VARCHAR로 변환
    private LocalDateTime createdAt;  // TIMESTAMP로 변환
    private Boolean isActive;   // BOOLEAN/BIT로 변환
  }

• 하지만 복잡한 객체를 DB에 저장할 때는 @Converter가 필요하다

  @Entity
  public class Book {
    @Convert(converter = BookStatusConverter.class)
    private BookStatus status;  // 단순 Integer가 아닌 커스텀 객체로 변환
  }

  Converter 구현

  @Converter
  public class BookStatusConverter implements AttributeConverter<BookStatus, Integer> {
    // BookStatus -> DB 칼럼값으로 변환
    @Override
    public Integer convertToDatabaseColumn(BookStatus bookStatus) {
        return bookStatus.getCode();
    }
  
    // DB column 값 -> BookStatus로 변환
    @Override
    public BookStatus convertToEntityAttribute(Integer s) {
        return s != null ? new BookStatus(s) : null;
    }
  }

  BookStatus 클래스

  @Data
  public class BookStatus {
    private int code;
    private String description;
  
    public BookStatus(int code) {
        this.code = code;
        this.description = parseDescription(code);
    }
  
    private String parseDescription(int code) {
        return switch (code) {
            case 100 -> "판매종료";
            case 200 -> "판매중";
            case 300 -> "판매보류";
            default -> "미지원";
        };
    }
  
    public boolean isDisplayed(){
        return code == 200;
    }
  }

  주의할 점

• @Transactional과 함께 사용할 때 주의가 필요하다. Converter에서 잘못된 값을 반환하면 영속성 컨텍스트의 변경 감지로 인해 데이터가 유실될 수 있다.

• Converter는 DB에 매우 가깝게 동작하므로 디버깅이 어렵다. 따라서 아래와 같은 점을 고려해야 한다:

• null 처리를 확실히 한다

• 예외 발생 가능성을 최소화한다
• 변환 로직을 단순하게 유지한다

Converter의 장점

• 도메인 로직 캡슐화: 단순 정수가 아닌 의미있는 객체로 상태를 표현할 수 있다
• 데이터 일관성: 상태값 변환 로직을 한 곳에서 관리할 수 있다
• 객체지향적 설계: DB는 단순하게 유지하면서 애플리케이션에서는 풍부한 객체를 사용할 수 있다

Embedded

• 코드 반복 -> Embed 쓰기
• 가독성을 높여줌

임베디드 타입 정의 및 사용

@Data
@AllArgsConstructor
@NoArgsConstructor
@Embeddable     // Embed 할 수 있는 클래스임을 선언
public class Address {
    private String city;        // 도시
    private String district;    // 구/군
    @Column(name = "address_detail")
    private String detail;      // 상세주소
    private String zipCode;     // 우편번호
}

@Embedded
@AttributeOverrides({
    @AttributeOverride(name = "city", column = @Column(name = "home_city")),
    @AttributeOverride(name = "district", column = @Column(name = "home_distirct")),
    @AttributeOverride(name = "detail", column = @Column(name = "home_address_detail")),
    @AttributeOverride(name = "zipCode", column = @Column(name = "home_zip_code")),
})
private Address homeAddress;  // 집주소

@Embedded
@AttributeOverrides({
    @AttributeOverride(name = "city", column = @Column(name = "company_city")),
    @AttributeOverride(name = "district", column = @Column(name = "company_distirct")),
    @AttributeOverride(name = "detail", column = @Column(name = "company_address_detail")),
    @AttributeOverride(name = "zipCode", column = @Column(name = "company_zip_code")),
})
private Address companyAddress;  // 회사 주소

임베디드 타입 활용

@Test
void embeddedTest1() {
    // 기본 저장 테스트
    User user = new User();
    user.setName("절미");
    user.setHomeAddress(new Address("서울시", "강남구", "강남대로 888", "08865"));
    user.setCompanyAddress(new Address("문선시", "문선구", "문선로 777", "12345"));
    userRepository.save(user);

    // 저장된 데이터 확인
    userRepository.findAll().forEach(System.out::println);
    userHistoryRepository.findAll().forEach(System.out::println);
}

@Test
void embeddedTest2() {
    // 1. 정상적인 주소 데이터
    User user1 = new User();
    user1.setName("steve");
    user1.setHomeAddress(new Address("서울시", "강남구", "강남대로 777 골드타워", "08765"));
    user1.setCompanyAddress(new Address("서울시", "성동구", "성수1로 333 우리빌딩", "04455"));
    userRepository.save(user1);

    // 2. null 주소 데이터
    User user2 = new User();
    user2.setName("joshua");
    user2.setHomeAddress(null);
    user2.setCompanyAddress(null);
    userRepository.save(user2);

    // 3. empty 주소 데이터
    User user3 = new User();
    user3.setName("jordan");
    user3.setHomeAddress(new Address());
    user3.setCompanyAddress(new Address());
    userRepository.save(user3);

    // 저장된 데이터 확인
    userRepository.findAll().forEach(System.out::println);
    userHistoryRepository.findAll().forEach(System.out::println);

    // DB에 실제 저장된 로우 데이터 확인
    System.out.println("🤪".repeat(20));
    userRepository.findAllRowRecord().forEach(a -> System.out.println(a.entrySet()));
}

        // Embedded된 Address 추가
        userHistory.setHomeAddress(user.getHomeAddress());
        userHistory.setCompanyAddress(user.getCompanyAddress());

        userHistoryRepository.save(userHistory);
    }
}

• @Embeddable과 @Embedded를 사용하여 값 타입을 정의하고 사용
• @AttributeOverrides로 같은 임베디드 타입을 여러번 사용할 때 컬럼명 충돌 방지
• Address가 null이거나 empty인 경우 모든 필드가 null로 저장됨

BUT

• annotation이 지저분해짐
• @AttributeOverrieds 대신 또 다른 객체를 선언하는게 나을지, 각자의 판단이 필요

@DynamicInsert

• INSERT SQL을 생성할 때 null이 아닌 필드들만 포함
• null 값을 가진 필드는 SQL문에서 제외되어, DB에 설정된 기본값(default value)이 적용
• 생성일자(createdAt) 필드가 null이면 해당 필드는 INSERT 문에서 제외되고, DB에 설정된 기본값(예: CURRENT_TIMESTAMP)이 사용됨

@DynamicUpdate

• UPDATE SQL을 생성할 때 변경된 필드들만 포함
• 변경되지 않은 필드들은 UPDATE 문에서 제외
• 불필요한 컬럼 업데이트를 방지하고 SQL 성능을 최적화

Custom Query를 사용하는 이유

1. Query Method의 가독성(너무 길어짐)

• Query 구문은 SQL이 아닌 JPQL임.

JPQL

• Entity 기반의 쿼리를 생성하기 위한 구문
• (실제 생성된 물리적 테이블 이름: created_at) but, property명을 사용(createdAt)
• dialect에 따라 쿼리 자동 생성
• native query와 차이 있음

JPQL Positional Parameter

• ?1, ?2...
• 1-based index

JPQL Named Parameter

• @Param ,: 접두어 사용
• Parameter 순서에 영향 x

2. Entity 연결하지 않은 Query 사용 가능

// interface
public interface BookNameAndCategory1 {
   String getName();
   String getCategory();
}

// DTO
@Data
@AllArgsConstructor
@NoArgsConstructor
// 이는 엔티티가 아니다.
public class BookNameAndCategory2 {
   private String name;
   private String category;
}

@Test
void queryTest(){
   bookRepository.findBookNameAndCategory3().forEach(b -> {
       System.out.println(b.getName() + " : " + b.getCategory());
   });
}

@OneToOne

@Data
@NoArgsConstructor
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
@Entity
public class BookReviewInfo extends BaseEntity{
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    // BookReviewInfo: Book
    // 1:1 연결
//    private Long bookId;   // FK 역할.

    @OneToOne(optional = false)   // Book 과 1:1 로 relation
    // optional = false  <= Book(부모) 는 null 허용하지 않는다 (즉, 반드시 Book 을 참조)
    private Book book;   // 부모 Entity 참조
    // 기본적으로 Entity 에선 직접적으로 다른 Entity 를 직접 참조 못한다
    // @OneToOne 과 같은 relation 어노테이션을 지정해주어야 한다.

    // NULL 을 허용하면 wrapper 객체 사용
    // NULL 을 허용하지 않을거면 primitive 객체 사용 -> DDL 에 NOT NULL 부여됨
    // 이번예제에서 아래 두개값은 기본값 0 을 사용하기 위해 primitive 를 사용합니다.
    //   --> 굳이 null check 안해도 된다.
    private float averageReviewScore;
    private int reviewCount;

}

@OneToOne(mappedBy = "book")    // 해당 Entity 의 테이블에선 연관키를 가지지 않는다.
    @ToString.Exclude   // Lombok 의 ToString 에서 배제 (양방향에서의 순환참조 때문에)
    private BookReviewInfo bookReviewInfo;

@Test
    void crudTest3() {
        givenBookReviewInfo();

        // Book(부모)에서 BookReviewInfo(자식) 조회
        System.out.println("🎅".repeat(20));

        // @ OneToOne 양방향 참조
        BookReviewInfo result2 = bookRepository
                .findById(1L)   // @OneToOne 연결된 entity 와의 join 문 발생
                .orElseThrow(RuntimeException::new)
                .getBookReviewInfo()
                ;

        System.out.println(">>> " + result2);
    }

Test 결과:

Hibernate: 
    create table book_review_info (
        average_review_score float(24) not null,
        review_count integer not null,
        book_id bigint not null unique,
        created_at timestamp(6),
        id bigint generated by default as identity,
        updated_at timestamp(6),
        primary key (id)
    )
Hibernate: 
    create table t_user (
        created_at timestamp(6),
        id bigint generated by default as identity,
        updated_at timestamp(6),
        email varchar(255) unique,
        name varchar(255),
        gender enum ('FEMALE','MALE'),
        primary key (id)
    )
Hibernate: 
    create table user_history (
        created_at timestamp(6),
        id bigint generated by default as identity,
        updated_at timestamp(6),
        user_id bigint,
        email varchar(255),
        name varchar(255),
        primary key (id)
    )
Hibernate: 
    create index IDXg8gqk4e142wekcb1t6d3v2mwx 
       on t_user (name)
Hibernate: 
    alter table if exists book_review_info 
       add constraint FKp5fhkokpbtoxmc3mxo8ay9e5l 
       foreign key (book_id) 
       references book

----------------------------------------
[ crudTest3() ] 호출

Hibernate: 
    select
        bri1_0.id,
        bri1_0.average_review_score,
        bri1_0.book_id,
        b1_0.id,
        b1_0.author_id,
        b1_0.category,
        b1_0.created_at,
        b1_0.name,
        b1_0.publisher_id,
        b1_0.updated_at,
        bri1_0.created_at,
        bri1_0.review_count,
        bri1_0.updated_at 
    from
        book_review_info bri1_0 
    join
        book b1_0 
            on b1_0.id=bri1_0.book_id 
    where
        bri1_0.id=?
>>> Book(super=BaseEntity(createdAt=2024-12-30T09:28:23.398898, updatedAt=2024-12-30T09:28:23.398898), id=1, name=JPA 완전정복, category=null, authorId=1, publisherId=1)
🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅🎅
Hibernate: 
    select
        b1_0.id,
        b1_0.author_id,
        bri1_0.id,
        bri1_0.average_review_score,
        bri1_0.book_id,
        bri1_0.created_at,
        bri1_0.review_count,
        bri1_0.updated_at,
        b1_0.category,
        b1_0.created_at,
        b1_0.name,
        b1_0.publisher_id,
        b1_0.updated_at 
    from
        book b1_0 
    left join
        book_review_info bri1_0 
            on b1_0.id=bri1_0.book_id 
    where
        b1_0.id=?
>>> BookReviewInfo(super=BaseEntity(createdAt=2024-12-30T09:28:23.422437, updatedAt=2024-12-30T09:28:23.422437), id=1, book=Book(super=BaseEntity(createdAt=2024-12-30T09:28:23.398898, updatedAt=2024-12-30T09:28:23.398898), id=1, name=JPA 완전정복, category=null, authorId=1, publisherId=1), averageReviewScore=4.5, reviewCount=2)
----------------------------------------

@OneToMany

1. 기본 매핑 방식

*중간 테이블 생성 방식: *

@OneToMany만 사용하면 자동으로 중간 테이블이 생성됩니다.

@OneToMany
private List<UserHistory> userHistories = new ArrayList<>();    // NPE 방지

생성되는 테이블 구조:

 create table t_user_user_histories (
    user_histories_id bigint not null unique,
    user_id bigint not null
)

*직접 외래키 방식: *

• 중간 테이블 없이 직접 외래키를 사용하려면 @JoinColumn을 추가합니다.

  @OneToMany
  @JoinColumn(name = "user_id")  // user_id 컬럼을 외래키로 사용
  private List<UserHistory> userHistories = new ArrayList<>();

2. Fetch 전략 (+추가 공부)

@OneToMany의 EAGER 사용시 주의사항:

@OneToMany(fetch = FetchType.EAGER)
@JoinColumn(name = "user_id")
private List<UserHistory> userHistories = new ArrayList<>();

*N+1 문제 발생 위험: *

• 성능 저하 가능성
• 대안: LAZY + 필요시 fetch join 사용

@Query("SELECT u FROM User u JOIN FETCH u.userHistories")
List<User> findAllWithHistories();

3. 양방향 매핑시 읽기 전용 설정

// User 엔티티
@OneToMany(fetch = FetchType.EAGER)
@JoinColumn(name = "user_id",    // Entity가 어떤 컬럼으로 join할지 지정
        insertable = false, updatable = false // read only 설정
)
private List<UserHistory> userHistories = new ArrayList<>();

// UserHistory 엔티티
@Column(name="user_id", insertable = false, updatable = false)
private Long userId;

@ManyToOne

1. 양방향 관계에서의 순환참조 문제

// Book 엔티티
class Book {
    @OneToOne(mappedBy = "book")
    private BookReviewInfo bookReviewInfo;
}

// BookReviewInfo 엔티티
class BookReviewInfo {
    @OneToOne
    private Book book;
}

순환참조 해결:

@ToString.Exclude   // Lombok의 ToString에서 배제
private BookReviewInfo bookReviewInfo;

@OneToMany, @ManyToOne 어느 Entity에서 연관 Entity가 필요한가에 따라 둘 중 어느것을 쓸 지가 달라진다.

각 연관관계 fetch type의 default 속성

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

@Test
    @Transactional
    void bookRelationTest() {

        // 테스트용 데이터 입력(Publisher, Book, Review)
        givenBookAndReview();

        // 특정 User
        User user = userRepository.findByEmail("martin@redknight.com");

        System.out.println("👇👇👇👇👇👇여기가 무시무시한 query 생성지 👇👇👇👇👇👇");
        // 특정 User 가 남긴 Review 정보들 가져오기
        System.out.println("Review: " + user.getReviews());     // getxxx() 시점에서 outer join들을 사용하여 읽어들임

        System.out.println("😁".repeat(20));
        // 특정 User 가 남긴 Review 중 첫번째 Review의 Book 정보 가져오기
        System.out.println("Book: " + user.getReviews().get(0).getBook());

        System.out.println("😇".repeat(20));
        // 특정 User 가 남긴 Review 중 첫번째 Review의 Book의 Publisher 정보 가져오기
        System.out.println("Publisher: " + user.getReviews().get(0).getBook().getPublisher());
    }

👇👇👇👇👇👇여기가 무시무시한 query 생성지 👇👇👇👇👇👇
Hibernate: 
    select
        r1_0.user_id,
        r1_0.id,
        b1_0.id,
        b1_0.author_id,
        bri1_0.id,
        bri1_0.average_review_score,
        bri1_0.book_id,
        bri1_0.created_at,
        bri1_0.review_count,
        bri1_0.updated_at,
        b1_0.category,
        b1_0.created_at,
        b1_0.name,
        p1_0.id,
        p1_0.created_at,
        p1_0.name,
        p1_0.updated_at,
        b1_0.updated_at,
        r1_0.content,
        r1_0.created_at,
        r1_0.score,
        r1_0.title,
        r1_0.updated_at 
    from
        review r1_0 
    left join
        book b1_0 
            on b1_0.id=r1_0.book_id 
    left join
        book_review_info bri1_0 
            on b1_0.id=bri1_0.book_id 
    left join
        publisher p1_0 
            on p1_0.id=b1_0.publisher_id 
    where
        r1_0.user_id=?
Review: [Review(super=BaseEntity(createdAt=2024-12-30T12:18:33.006304, updatedAt=2024-12-30T12:18:33.006304), id=1, title=내 인생을 바꾼 책, content=너무너무 재미있고 즐거운 책이었어요, score=5.0, user=User(super=BaseEntity(createdAt=2024-12-30T12:18:32.669926, updatedAt=2024-12-30T12:18:32.669926), id=1, name=martin, email=martin@redknight.com, gender=null), book=Book(super=BaseEntity(createdAt=2024-12-30T12:18:33.003352, updatedAt=2024-12-30T12:18:33.003352), id=1, name=JPA 완전정복, category=null, authorId=null))]
😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁
Book: Book(super=BaseEntity(createdAt=2024-12-30T12:18:33.003352, updatedAt=2024-12-30T12:18:33.003352), id=1, name=JPA 완전정복, category=null, authorId=null)
😇😇😇😇😇😇😇😇😇😇😇😇😇😇😇😇😇😇😇😇
Publisher: Publisher(super=BaseEntity(createdAt=2024-12-30T12:18:32.990396, updatedAt=2024-12-30T12:18:32.990396), id=1, name=K-출판사, books=[])

JPA의 장점: getter만 썼을 뿐인데, 알아서 query가 실행된다는 점

@ManyToMany

보통 잘 안 쓰고, 1:N, M:1로 별도의 테이블을 빼서 만든다.

1. 둘의 차이가 뭘까?

uniqueConstraints

email에만 unique 설정

정답: uniqueConstraints는 복합키로도 unique 설정 가능

2. save는 언제 INSERT/UPDATE일까?

@Test
void insertAndUpdateTest() {
    System.out.println("\n-- TEST#insertAndUpdateTest() ---------------------------------------------");
    User user = new User();
    user.setName("kname");
    user.setEmail("kname@mail.com");

    userRepository.save(user);  // INSERT

    user2=userRepository.findById(1L).orElseThrow(RuntimeException::new);
    user2.setName("pname");

    userRepository.save(user2); // UPDATE

    System.out.println("\n------------------------------------------------------------\n");
}

• id를 확인하고 있으면 update, 없으면 insert

3. @Transient

• 영속성 처리에서 배제되고, 굳이 db에 반영하고 싶지 않음
• 단기적으로 잠시 머무르는 변수

4. ENUM

• JPA는 기본적으로 enum을 정수 타입으로 저장(0, 1 등)
• 문자 타입으로 저장할 수 있도록 설정해주어야 함

Listener 사용법

Entity Listener

• 특정 이벤트에서 Entity 관련으로 동작

• auditing: PrePersist, PreUpdate 많이 쓰임

1. Entity 객체 내부에서 선언

@PrePersist
    public void prePersist() {
        System.out.println(">>> prePersist");
        this.createdAt = LocalDateTime.now();
        this.updatedAt = LocalDateTime.now();
    }

    @PreUpdate
    public void preUpdate() {
        System.out.println(">>> preUpdate");
        this.updatedAt = LocalDateTime.now();
    }

    @PreRemove
    public void preRemove() {
        System.out.println(">>> preRemove");
    }

    @PostPersist
    public void postPersist() {
        System.out.println(">>> postPersist");
    }

    @PostUpdate
    public void postUpdate() {
        System.out.println(">>> postUpdate");
    }

    @PostRemove
    public void postRemove() {
        System.out.println(">>> postRemove");
    }

    @PostLoad
    public void postLoad() {
        System.out.println(">>> postLoad");
    }

• 객체 내부에 선언 후 사용
• 현재시간 입력을 위해 매번 반복되는 코드 / 데이터 정확도 문제
• 여러 Entity에 동일하게 사용되는 Listener를 담은 클래스 사용하자

2. 별도의 Listener Class

public interface Auditable {
    LocalDateTime getCreatedAt();
    LocalDateTime getUpdatedAt();

    void setCreatedAt(LocalDateTime createdAt);
    void setUpdatedAt(LocalDateTime updatedAt);
}

@EntityListeners(value = {MyEntityListener.class})

public class User implements Auditable {

• Listener class 사용 시, 공통적 부분에 대한 listener를 하나만 구현하여 @EntityListeners를 사용해 참조하여 사용가능하다. 반복적 코딩을 줄일 수 있다.

+ Log Data (히스토리 데이터)에 "곧 수정될 내용"을 history 담기

• event listener에서 특정값을 추가하는 경우 말고, 특정 데이터가 수정되면 해당값의 복사본을 다른 테이블에 저장해두는 event일 경우
• User Entity에 User data라는 중요 데이터가 있으므로, 수정된 내역의 히스토리를 필요해 보임.

import com.lec.spring.domain.UserHistory;
import org.springframework.data.jpa.repository.JpaRepository;

public interface UserHistoryRepository extends 
    JpaRepository<UserHistory, Long> {

@Component
public class UserEntityListener {

    @Autowired
    private UserHistoryRepository userHistoryRepository;

    @PreUpdate  // User 가 UPDATE 수행하기 전
    @PrePersist     // User 가 INSERT 수행하기 전
    public void addHistory(Object o) {
        System.out.println(">>UserEntityListener addHistory() 호출");

        User user = (User) o;
        // UserHistory 에 UPDATE 될 User 정보 담아서 저장 (INSERT)
        UserHistory userHistory = new UserHistory();
        userHistory.setUserId(user.getId());
        userHistory.setName(user.getName());
        userHistory.setEmail(user.getEmail());

        userHistoryRepository.save(userHistory);    // INSERT
    }

@EntityListeners(value = {MyEntityListener.class, UserEntityListener.class})

• but,Entity Listener는 Spring Bean 주입받지 못해 NPE 발생

// Listener 안에서 스프링 빈 객체 수동으로 주입받기
        UserHistoryRepository userHistoryRepository = BeanUtils.getBean(
        UserHistoryRepository.class);

• UserHistory에도 @EntityListeners 설정 : INSERT, UPDATE될 때, createdAt, updatedAt이 이제 자동으로 세팅된다. 코드의 반복이 줄어들었음.

@EntityListeners(value = MyEntityListener.class)

• 생성일, 수정일은 워낙 많은 Entity에서도 사용하여, Spring에서도 기본 Listener를 제공하고 있다.

3. Spring에서 제공하는 AuditingEventListener 사용

@EnableJpaAuditing

@EntityListeners(value = AuditingEntityListener.class)

@CreatedDate
private LocalDateTime createdAt;
@LastModifiedDate
private LocalDateTime updatedAt;

• 이렇게 되면, createdAt, updatedAt를 엄청 반복하니, 리팩토링해서 AuditingEntityListener 사용해보자.

BaseEntity

@Data
@MappedSuperclass   // (JPA)가 이 클래스의 속성을, 상속받는 Entity 에 포함시켜줌
@EntityListeners(AuditingEntityListener.class)
public class BaseEntity{

    @CreatedDate
    private LocalDateTime createdAt;
    @LastModifiedDate
    private LocalDateTime updatedAt;

}

@EntityListeners(value = {UserEntityListener.class})
public class User extends BaseEntity implements Auditable {

Lombok의 toString 문제 해결

// 부모쪽도 toString으로 호출
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = false)

• 매 Entity마다 Auditable을 implement 할 필요없이, BaseEntity만 Auditable을 implement하게 하면 된다.

public class User extends BaseEntity {

@Data
@MappedSuperclass   // (JPA)가 이 클래스의 속성을, 상속받는 Entity 에 포함시켜줌
@EntityListeners(AuditingEntityListener.class)
public class BaseEntity implements Auditable {

    @CreatedDate
    private LocalDateTime createdAt;
    @LastModifiedDate
    private LocalDateTime updatedAt;

}

JPA CRUD

@Repository
public interface PostRepository extends JpaRepository<Post, Long> {
}

@Service
public class BoardServiceImpl implements BoardService {

    private final PostRepository postRepository;

    public BoardServiceImpl(PostRepository postRepository) {
        this.postRepository = postRepository;
    }

    @Override
    public int write(Post post) {
        postRepository.save(post);
        return 1;
    }

    @Override
    public Post detail(Long id) {
        Optional<Post> postOptional = postRepository.findById(id);
        if (postOptional.isPresent()) {
            Post post = postOptional.get();

            if (post.getViewCnt() == null) {
                post.setViewCnt(1L);
            } else {
                post.setViewCnt(post.getViewCnt() + 1);
            }

            postRepository.save(post);
            return post;
        }
        return null;
    }


    @Override
    public List<Post> list() {
        return postRepository.findAll(Sort.by(Sort.Order.desc("id")));
    }

    @Override
    public Post selectById(Long id) {
        return postRepository.findById(id).orElse(null);
    }

    @Override
    public int update(Post post) {
        // 주의! 위 post 매개변수에는 viewcnt 값이 없기 때문에
        // 위 post 값으로 save 하면 viewcnt 값은 0 으로 초기화 된다.

        Optional<Post> existingPost = postRepository.findById(post.getId());
        if (existingPost.isPresent()) {
            Post updatedPost = existingPost.get();
            updatedPost.setSubject(post.getSubject());
            updatedPost.setContent(post.getContent());
            postRepository.save(updatedPost);
            return 1;
        }
        return 0;
    }

    @Override
    public int deleteById(Long id) {
        if (postRepository.existsById(id)) {
            postRepository.deleteById(id);
            return 1;
        }
        return 0;
    }
}

이런 식으로 사용된다. refactoring 하면서 허무한 마음이 들었다. 내가 쓰던 sql query문들은 어디로..

물론 relation에 대해 배우면 좀 더 복잡해지겠지만, 일단 이걸로 돌아간다니! ORM을 쓰는 이유가 너무나 뼈저리게 느껴졌다.

JPA Entity Relation

• Entity는 양방향 참조하는 경우가 많다.

1:1

• 지속적으로 서비스 무중단 제공해야 하고, 속성을 추가해야하는 방식의 컬럼이라면, 1:1 연관관계를 맺는 테이블을 추가하는 것도 방법.

3편에서 이어서

Persistence:

• 영속성
• 데이터를 생성한 프로그램이 종료되어도 사라지지 않는 데이터의 특성
• 영구적으로 파일, 데이터베이스 등 활용하여 저장

ORM:

• object relational mapping
• 비영속성 객체를 영속성 객체에 연결해주는 기술
• 직접 매핑하기 때문에 쿼리문을 거의 다루지 않음
• 자바 객체 다루듯 작업

JPA:

• Java Persistence API
• Java 진영에서 ORM 표준으로 채택된 API
• 데이터베이스 코드 관련 유연성
• 어설프게 다루면 성능 이슈 만들 수 있음
• 데이터베이스에 대해 독립적이라, 특정 데이터베이스의 강력한 기능 활영하기 어려움

Hibernate:

• JPA의 실제 구현체

Spring Data JPA:

• Hibernate를 더 간편하게 사용하기 위해 만든 기술

이제까지 사용한 MyBatis -> Persistence Context

Entity:

Entity Manager:

• persistenece context에 넣어두고 객체들의 생사 관리
• 엔티티에 대한 정보를 수정한다

엔티티 Manager 메소드의 상태

• 비영속 상태
• 영속된
• Detached(준영속)
• 지워져야 함

Optional:

• null일 수도 있는 객체를 감싸는 래퍼 클래스
• NullPointerException을 방지하는데 도움을 줌
• 명시적으로 값이 없을 수 있다는 것을 표현

Optional 사용 시 주의사항:

• Optional을 필드로 사용하지 않기
• Optional을 생성자나 메서드의 매개변수로 사용하지 않기
• Collections, Arrays 등의 컨테이너를 Optional로 감싸지 않기
• Optional.get() 직접 호출은 피하고 대신 orElse, orElseGet, orElseThrow

// Optional 생성
Optional<String> opt1 = Optional.empty();  // 빈 Optional
Optional<String> opt2 = Optional.of("값");  // null이 아닌 값으로 Optional 생성
Optional<String> opt3 = Optional.ofNullable(nullable);  // null일 수도 있는 값으로 생성

// 값 처리
opt.isPresent();  // 값이 존재하는지 확인
opt.isEmpty();    // 값이 없는지 확인
opt.get();        // 값 가져오기 (값이 없으면 예외 발생)
opt.orElse("기본값");  // 값이 없을 때 기본값 반환
opt.orElseGet(() -> "기본값 생성");  // 값이 없을 때 기본값 생성

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmail(String email);
}

@Service
public class UserService {
    public User getUser(String email) {
        return userRepository.findByEmail(email)
            .orElseThrow(() -> new UserNotFoundException("사용자를 찾을 수 없습니다"));
    }
}

Flush:

• SQL쿼리의 변화를 주는게 아니라 'DB 반영 시점'을 조정한다.
• 로그 출력으로는 변화를 확인하기 힘들다

QueryByExample(QBE)

• 복잡한 조건에 대한 쿼리문을 작성할 때 사용
• 비교적 최근에 만들어짐
• 크게 효과적이진 않음

2. Query Method

• where 조건절을 메소드 이름 선언만으로 만들어주도록 한다

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByName(String name);
    User findByEmail(String email);
}

• Repository 인터페이스를 생성하고 JpaRepository를 상속받는다.
• 제네릭 타입으로 엔티티 클래스와 ID 타입을 지정한다.
• 메소드 이름 규칙에 따라 쿼리 메소드를 정의.

User findByEmail(String email);
User getByEmail(String email);
User readByEmail(String email);
User queryByEmail(String email);
User searchByEmail(String email);
User streamByEmail(String email);

조건절 키워드

비교 연산자

List<User> findByAgeGreaterThan(int age);              // > 
List<User> findByAgeGreaterThanEqual(int age);         // >=
List<User> findByAgeLessThan(int age);                 // 
List<User> findByAgeLessThanEqual(int age);            // <=

논리 연산자

List<User> findByEmailAndName(String email, String name);   // AND
List<User> findByEmailOrName(String email, String name);    // OR 

Between

List<User> findByCreatedAtBetween(LocalDateTime start, LocalDateTime end);
List<User> findByAgeBetween(int start, int end);

Like 검색

List<User> findByNameStartingWith(String prefix);      // LIKE 'prefix%'
List<User> findByNameEndingWith(String suffix);        // LIKE '%suffix'
List<User> findByNameContains(String word);           // LIKE '%word%'
List<User> findByNameLike(String likePattern);        // 

LIKE 직접 지정, NULL 체크, IN 절

List<User> findByIdIsNotNull();
List<User> findByIdIsNull();
List<User> findByNameIn(List<String> names);

정렬과 페이징

// 메소드 이름으로 정렬
List<User> findByNameOrderByIdDesc(String name);

// Sort 파라미터로 정렬
List<User> findByName(String name, Sort sort);

페이징

// Pageable 파라미터로 페이징 처리
Page<User> findByName(String name, Pageable pageable);

// 사용 예시
PageRequest pageRequest = PageRequest.of(0, 10, Sort.by(Sort.Direction.DESC, "id"));
Page<User> userPage = userRepository.findByName("John", pageRequest);

예시

// 최근 24시간 내 생성된 활성 사용자 찾기
List<User> findByCreatedAtAfterAndActiveTrue(LocalDateTime yesterday);

// 특정 이메일 도메인을 사용하는 사용자 찾기
List<User> findByEmailEndingWith(String domain);

// 이름으로 검색하고 ID로 정렬하여 상위 5명 가져오기
List<User> findTop5ByNameContainingOrderByIdDesc(String name);

동일한 user의 computer라 하더라도 session, cookie는 브라우저가 다르면 다르게 관리한다. cookie, session은 브라우저가 관리한다.

Cookie

• Server: Cookie 생성 -> Response에 담아 보냄
• Browser: Cookie 저장
• Browser: 다음 요청 보낼 때 Cookie 담아보냄
• Server: 내가 보냈던 거란 걸 알고 클라이언트 상세 정보를 저장(name value 쌍)

네트워크 연결성

• connection도 system 자원이므로, 웹은 request, response가 완료되면 접속이 끊어짐 (= 통신의 연속성이 없음)
• 쿠키의 등장

Spring 환경에서 Cookie 다루는 법

1. Severlet의 HttpServletResponse 객체 사용
2. CookieValue("key") 사용

package com.lec.spring.controller5;

import jakarta.servlet.http.Cookie;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.*;

import java.io.IOException;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;

@Controller
@RequestMapping("/cookie")
public class CookieController {

    // 클라이언트로부터 온 request 안의 cookie 정보들 조회
    @RequestMapping("/list")
    public void list(HttpServletRequest request, Model model){
        // 클라이언트 안의 쿠키 정보는 request 시에 서버로 전달된다.
        // request.getCookies() 로 쿠키 받아올수 있다.
        Cookie[] cookies = request.getCookies();

        StringBuffer buff = new StringBuffer();

        if(cookies != null){  // 쿠키가 하나도 없다면 null 을 리턴한다
            for (int i = 0; i < cookies.length; i++) {
                // Cookie 는 name-value 쌍으로 이루어진 데이터 (name, value 는 모두 String)
                String name = cookies[i].getName();
                String value = cookies[i].getValue();
                buff.append((i + 1) + "] " + name + " : " + value + "<br>");
            }

        } else {
            buff.append("쿠키가 없습니다<br>");
        }

        model.addAttribute("result", buff.toString());

    }

    // 쿠키 생성 절차
    //1. 쿠키(Cookie) 클래스로 생성
    //2. 쿠키속성 설정(setter)
    //3. 쿠키의 전송 (response 객체에 탑재:addCookie())
    @RequestMapping("/create")
    public String create(HttpServletResponse response) throws IOException {
        String cookieName1 = "num1";
        String cookieValue1 = "" + (int)(Math.random() * 10);
        Cookie cookie1 = new Cookie(cookieName1, cookieValue1);  // name-value 쌍으로 Cookie 생성
        cookie1.setMaxAge(30); // 쿠키 파기(expiry) 시간 설정 (생성 시점으로부터 30 초 후)
        response.addCookie(cookie1);  // response 에 Cookie 추가

        // 쿠키는 얼마든지 생성 가능
        String cookieName2 = "datetime";
        String cookieValue2 = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddhhmmss"));

        Cookie cookie2 = new Cookie(cookieName2, cookieValue2);
        cookie2.setMaxAge(45);
        response.addCookie(cookie2);

        // response.sendRedirect("/cookie/list");
        return "redirect:/cookie/list";
    }

    @RequestMapping("/delete")
    public String delete(HttpServletResponse response){
        String cookieName = "num1";  // 삭제할 cookie 의 name
        Cookie cookie = new Cookie(cookieName, "");
        cookie.setMaxAge(0);   // response 되자마자 해당 name 의 cookie 는 삭제됨.
        response.addCookie(cookie);

        return "redirect:/cookie/list";
    }

    @RequestMapping("/num1")
    @ResponseBody
    public String num1(@CookieValue(value = "num1", required = false) Cookie cookie){

        if(cookie != null){
            return cookie.getName() + " : " + cookie.getValue();
        }

        return "num1 쿠키 없어요";
    }

    //------------------------------------------------------------------------
    public static final String ADMIN_ID = "admin";
    public static final String ADMIN_PW = "1234";

    @GetMapping("/login")
    public void login(@CookieValue(name="username", required = false) String username, Model model){
        model.addAttribute("username", username);
    }

    @PostMapping("/login")
    public String loginOk(String username, String password, HttpServletResponse response, Model model){
        // username /password 일치하면 인증성공 -> 쿠키 발급
        if(ADMIN_ID.equalsIgnoreCase(username) && ADMIN_PW.equals(password)){
            Cookie cookie = new Cookie("username", username);
            cookie.setMaxAge(30);
            response.addCookie(cookie);

            model.addAttribute("result", true);
        } else {
            Cookie cookie = new Cookie("username", username);
            cookie.setMaxAge(0);   // 기존에 혹시 있었을 쿠키도 삭제한다.
            response.addCookie(cookie);
        }

        return "cookie/loginOk";
    }

    @PostMapping("/logout")
    public String logout(HttpServletResponse response){
        Cookie cookie = new Cookie("username", "");
        cookie.setMaxAge(0);   // 기존에 혹시 있었을 쿠키도 삭제한다.
        response.addCookie(cookie);

        return "cookie/logout";
    }


}

Session

• Client의 상태를 기억하는 웹 기술
• Client: Request
• Server: new Client의 상세정보 저장 위한 (name-value쌍) 테이블 형성 / 오로지 이 Client만을 위한(고유한 Id가 있는) table = session => Cookie에 비해 보안성이 높고 제한이 크게 없음
• Session Reponse값에 쿠기 Session id 끼워서 보냄
• 클라이언트가 이 쿠키를 보게 됨
• Client: 다시 request 보낼 때 cookie의 Session id를 넣어 보냄 (Session id에는 무엇이든 들어갈 수 있음)

Spring이 session을 다루는 법

1. HttpSession object 사용
2. @SessionAttribute 사용
3. Model에 저장 시, session, request에 저장 (RedirectAttribute도 내부적으로 session 사용)

package com.lec.spring.controller5;

import jakarta.servlet.http.HttpSession;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Enumeration;

@Controller
@RequestMapping("/session")
public class SessionController {

    // HttpSession 객체
    //  현재 request 한 client 에 대한 Session 정보
    //  session 은 attribute(name-value쌍) 들이 담겨 있다
    //   name: String 타입,  value: Object 타입
    @RequestMapping("/list")
    public void list(HttpSession session, Model model){
        Enumeration<String> enumeration = session.getAttributeNames();

        StringBuffer buff = new StringBuffer();

        int i = 0;
        while(enumeration.hasMoreElements()){
            String sessionName = enumeration.nextElement();
            // session.getAttribute('name')  <-- 특정 세션 attr value 추출. 리턴타입 Object. 해당 name 이 없으면 null 리턴
            String sessionValue = session.getAttribute(sessionName).toString();

            buff.append((i + 1) + "] " + sessionName + " : " + sessionValue + "<br>");
            i++;
        }
        if(i == 0){
            buff.append("세션 안에 attribute 가 없습니다<br>");
        }

        model.addAttribute("result", buff.toString());
    }

    @RequestMapping("/create")
    public String create(HttpSession session){
        String sessionName, sessionValue;

        sessionName = "num1";
        sessionValue = "" + (int)(Math.random() * 100);

        // 세션 attr : name-value 생성
        // setAttribute(String name, Object value) 두번째 매개변수는 Object 타입이다
        session.setAttribute(sessionName, sessionValue);

        sessionName = "datetime";
        sessionValue = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd hh:mm:ss"));
        session.setAttribute(sessionName, sessionValue);

        return "redirect:/session/list";
    }

    @RequestMapping("/delete")
    public String delete(HttpSession session){
        // removeAttribute(name) 세션 attribute 삭제
        session.removeAttribute("num1");
        return "redirect:/session/list";
    }

    //-------------------------------------------------
    public static final String ADMIN_ID = "admin";
    public static final String ADMIN_PW = "1234";

    @GetMapping("/login")
    public void login(HttpSession session, Model model){
        // 현재 로그인 상태인지, 즉 로그인 세션 (name이 'username'인 세션값)이 있는지 확인
        if(session.getAttribute("username") != null){
            model.addAttribute("username", session.getAttribute("username"));
        }
    }

    @PostMapping("/login")
    public String loginOk(String username, String password, HttpSession session
            , Model model){

        // 세션 name-value 지정
        String sessionName = "username";
        String sessionValue = username;

        // 제출된 id /pw 값이 일치하면 로그인 성공 + 세션 attr 생성
        if(ADMIN_ID.equalsIgnoreCase(username) && ADMIN_PW.equals(password)){
            session.setAttribute(sessionName, sessionValue);
            model.addAttribute("result", true);
        }else{
            session.removeAttribute(sessionName);
        }

        return "session/loginOk";
    }

    @PostMapping("/logout")
    public String logout(HttpSession session){

        String sessionName = "username";

        // 세션 삭제
        session.removeAttribute(sessionName);

        return "session/logout";
    }

}