myh7754 님의 블로그

GC 동작 방식 및 원리 (2)

myh7754 — Wed, 15 Jul 2026 20:36:21 +0900

GC — Stop-the-World, Card Table, 그리고 알고리즘의 진화

지난 글에서는 JVM의 어떤 객체가 GC 대상이 되는지(3가지 가설, GC Root)를 다뤘다. 이번 글에서는 그 GC가 실제로 어떤 과정으로 동작하는지, 속도가 느려지는 원인인 STW는 무엇인지, 그리고 GC가 어떻게 발전해왔는지를 다룬다. 핵심 질문은 하나다.

GC의 역사는 곧 Stop-the-World를 줄여온 역사다. 어떻게 줄여왔는가?

1 Stop-the-World — GC 속도 저하의 원인

GC가 살아있는 객체를 판별하려면 GC Root에서 참조 그래프를 탐색(Mark)해야 한다. 문제는 탐색하는 동안 애플리케이션 스레드가 참조를 바꿔버리면 판정이 틀어진다는 것이다.

// GC가 A를 Mark하는 중에...
A.ref = B;      // 애플리케이션 스레드가 참조를 추가하면
C.ref = null;   // Mark 결과와 실제 그래프가 어긋난다

가장 확실한 해결책은 GC가 도는 동안 애플리케이션 스레드를 전부 멈추는 것이다. 이것이 Stop-the-World(STW)다. STW 동안 애플리케이션은 아무 요청도 처리하지 못하고, 힙이 클수록 탐색할 그래프가 커져 STW도 길어진다.

Safepoint

스레드는 아무 지점에서나 마음대로 멈추지 못한다. 객체 참조가 일관된 상태임이 보장되는 지점, 즉 Safepoint에서만 멈춘다. JVM은 다음 위치에 Safepoint를 심어둔다.

메서드 호출 직후
루프의 백엣지(back-edge, 루프 마지막에서 처음으로 돌아가는 지점)
예외 처리 지점
일부 반환 지점

while (true) {
    i++;
    // ← 매 반복마다 Safepoint 폴링 (GC가 요청했는지 검사)
}

만약 루프에 Safepoint가 없다면 이 스레드는 영원히 GC에 협조하지 않는다. GC가 필요하면 모든 스레드가 Safepoint에 도달할 때까지 기다린 뒤에야 STW가 시작된다.

counted loop와 TTSP 문제

counted loop란 다음처럼 반복 횟수가 명확하고, int 인덱스 기반이며, 종료가 보장되는 루프다.

for (int i = 0; i < 1_000_000; i++) {
    // ...
}

JIT 입장에서는 "어차피 유한 루프인데 매 반복마다 Safepoint를 검사하면 느리다"고 판단해, 최적화 과정에서 루프 내부의 Safepoint 폴링을 제거할 수 있다. 문제는 이 루프가 거대할 때다. 이 루프를 도는 스레드 하나가 Safepoint에 도달하지 못하면, 이미 멈춘 나머지 모든 스레드가 그 스레드 하나를 기다린다. 이를 Time-To-Safepoint(TTSP) 문제라 부른다.

JVM도 나중에 문제를 인식했다.

예전 HotSpot은 counted loop에서 polling 제거를 적극적으로 했다.

하지만 TTSP 이슈가 많이 발생해서:

-XX:+UseCountedLoopSafepoints

옵션이 추가되었다.

다만 요즘 JVM은 예전보다 똑똑하다.

최신 HotSpot(C2)은 무조건 제거하지는 않는다.

루프 크기, 최적화 상태 등에 따라 다르게 처리한다.

그래도 아주 긴 계산 루프에서는 여전히 TTSP 문제가 발생할 가능성이 있다.

2 Mark-Sweep-Compact와 세대별 GC

모든 GC 알고리즘의 뼈대는 3단계다.

단계동작부작용

Mark	GC Root에서 참조 그래프 탐색, 살아있는 객체 표시	그래프 크기에 비례한 시간
Sweep	표시되지 않은 객체 수거	단편화(Fragmentation) 발생
Compact	살아남은 객체를 한쪽으로 밀어 단편화 제거	객체 이동 → 참조 주소 갱신 필요 → 비용 큼

Sweep만 하면 힙에 구멍이 숭숭 뚫린다. 총 여유 공간은 충분한데 연속된 공간이 없어 큰 객체를 할당하지 못하는 상황이 온다. 그래서 Compact가 필요하지만, 객체를 옮기면 그 객체를 가리키던 모든 참조를 갱신해야 해서 비싸다. 이 트레이드오프가 이후 모든 알고리즘 설계를 관통한다.

Copying Collector — 약한 세대 가설의 구현

Mark-Sweep과 전혀 다른 접근이 하나 더 있다. Copying Collector는 공간을 둘로 나눠두고, GC 때 살아있는 객체만 반대편 공간으로 복사한 뒤, 원본 공간을 통째로 리셋하는 방식이다.

여기서 중요한 것은 죽은 객체를 '치우는' 동작 자체가 없다는 점이다.

방식죽은 객체 처리비용이 비례하는 대상

Sweep	하나하나 방문해서 해제	전체 객체 수
Copying	아예 건드리지 않음 (영역 포인터만 리셋)	생존자 수

지난 글의 약한 세대 가설을 떠올려보자. 대부분의 객체는 금방 죽는다. 즉 Young 영역의 생존자는 극소수다. 비용이 생존자 수에만 비례하는 Copying은 Young 영역에 압도적으로 유리하고, 복사 과정에서 객체가 한쪽에 몰리므로 단편화도 원천 차단된다. Young 영역의 GC가 Copying 방식인 이유다.

Heap 구조와 Minor GC

힙은 Young 영역과 Old 영역으로 나뉘고, Young은 다시 Eden과 2개의 Survivor(S0, S1) 로 나뉜다. Copying을 위해 Survivor 한쪽은 반드시 비워둔다.

[Eden            ][S0 (From)][S1 (To, 비움)]     [Old              ]

새 객체는 Eden에 할당된다
Eden이 가득 차면 Minor GC가 시작된다

Minor GC 동작 과정

Eden + 현재 사용 중인 Survivor(From)에서 살아있는 객체를 식별한다
생존자를 비어있는 Survivor(To)로 복사하고, age 카운터를 +1 한다 (몇 번의 GC를 살아남았는지 기록)
이때 age가 임계값(-XX:MaxTenuringThreshold, 기본 15) 이상인 객체는 To가 아닌 Old 영역으로 복사된다 — 승격(Promotion)은 별도 단계가 아니라 복사하는 순간의 목적지 판정이다
Eden과 옛 Survivor(From)는 죽은 객체를 개별 정리하지 않고 통째로 비운다
Survivor의 역할을 swap 한다 (From ↔ To)

객체가 Old 영역으로 가는 3가지 경로

경로조건성격

age 승격	age ≥ 임계값	정상 승격
조기 승격	Survivor(To)가 가득 차 복사 공간 부족	비정상 승격 (Survivor 크기 튜닝 신호)
직행 할당	처음부터 크기가 매우 큰 객체	승격이 아니라 Eden을 거치지 않는 직접 할당 (G1에서는 Humongous Region으로)

여기까지가 지난 글 가설들의 구현이다. 강한 세대 가설(오래 산 객체는 더 오래 산다)이 바로 age 기반 승격과 Old 분리의 근거다 — 여기까지 살아남은 객체는 앞으로도 오래 살 가능성이 높으므로, Old로 보내 Minor GC 대상에서 제외한다.

GC 범위에 따른 용어 정리 (Major/Full GC는 공식 스펙 용어가 아니라 관례적 용어라 문서마다 정의가 조금씩 다르다)

용어대상트리거

Minor GC	Young 영역	Eden이 가득 참
Major GC	Old 영역	Old가 가득 참
Full GC	Heap 전체 (+ Metaspace)	Old 부족, 승격 실패 등

3 Card Table과 Write Barrier — 세 번째 가설의 구현

가설 3개 중 2개의 구현을 봤다. 이제 마지막이다.

가설구현

약한 세대 가설	Young 분리 + Copying Collector + Minor GC
강한 세대 가설	age 기반 승격 + Old 분리
세대간 참조 희소성	Card Table + Write Barrier (이번 장)

Minor GC의 GC Root는 지난 글에서 본 static 변수, 스택, 스레드만이 아니다. Old 영역에서 Young 영역을 가리키는 참조도 (Minor GC 관점에서는) Root로 취급해야 한다. Old 객체가 살아있고 그 객체가 Young 객체를 참조한다면, 그 Young 객체도 살아있기 때문이다.

그럼 Minor GC 때마다 Old 영역 전체를 스캔해야 하나? 그러면 Young/Old를 나눈 의미가 없다. 여기서 세대간 참조 희소성 가설이 등장한다. Old → Young 참조는 드물다. 드물다면, 그 드문 것만 기록해두면 된다.

Card Table

Old 영역을 512바이트 단위의 카드(Card) 로 쪼개고, 각 카드의 상태를 바이트 배열로 관리한다.

Old 영역:   [card 0][card 1][card 2][card 3] ...
Card Table: [clean ][dirty ][clean ][dirty ] ...
                       │                │
                       └─ 이 카드 안에 Young을 가리키는 참조가 있을 "수" 있음

Old 객체의 필드에 Young 객체 참조가 쓰이면, 해당 카드를 dirty로 표시한다. Minor GC는 Old 전체가 아니라 dirty 카드만 스캔하면 된다.

Write Barrier

그럼 dirty 표시는 누가 하는가? JVM이 참조 대입 코드마다 자동으로 끼워 넣는 짧은 코드, Write Barrier다.

// 개발자가 쓴 코드
oldObject.field = youngObject;

// JVM이 실제로 실행하는 코드 (개념적으로)
oldObject.field = youngObject;
cardTable[addressOf(oldObject) >> 9] = DIRTY;  // 512B = 2^9

모든 참조 대입에 비용이 추가되지만(보통 수 ns), Minor GC 때 Old 전체 스캔을 피하는 이득이 훨씬 크다. 평상시에 조금씩 비용을 내고, GC 때 크게 아끼는 전형적인 트레이드오프다.

4 GC 알고리즘의 진화

이제 도구가 갖춰졌다. 각 알고리즘이 STW를 어떻게 줄여왔는지 순서대로 본다.

Serial GC — 출발점

GC 스레드 1개로 Mark-Sweep-Compact 수행
전 과정이 STW
힙이 작은 단일 코어 환경, 컨테이너 리소스가 극도로 제한된 환경 정도에서만 의미가 있다
-XX:+UseSerialGC

Parallel GC — 처리량의 시대 (Java 8 기본)

GC 작업 자체를 여러 스레드로 병렬화. STW는 여전히 발생하지만 길이가 짧아진다
목표가 처리량(Throughput) 최대화: 전체 실행 시간 중 GC가 차지하는 비율을 최소화해 단위 시간당 처리량을 높인다
배치 처리처럼 "잠깐 멈춰도 총 작업이 빨리 끝나면 되는" 워크로드에 여전히 유효하다
-XX:+UseParallelGC

CMS — Concurrent의 시초 (Java 14에서 제거)

Mark 단계 대부분을 애플리케이션 스레드와 동시에(Concurrent) 수행해 STW를 크게 줄인 첫 시도
그러나 치명적 약점이 있었다
- Compact를 하지 않아 단편화 누적 → 결국 Full GC(전체 STW Compact)로 폭발
- 동시 수행을 위한 CPU 경합, 복잡한 튜닝
실패로 끝났지만, CMS가 개척한 Concurrent Marking은 이후 모든 GC의 토대가 됐다

G1 GC — 예측 가능한 멈춤 (Java 9+ 기본)

G1은 힙 구조 자체를 바꿨다. Young/Old를 물리적으로 연속된 큰 덩어리로 두지 않고, 힙을 동일 크기의 Region(기본 1~32MB) 수백~수천 개로 쪼갠다. 각 Region이 그때그때 Eden, Survivor, Old 역할을 맡는다.

[E][O][O][E][S][O][H][H][E][O][ ][O] ...
 └ Region 단위로 역할이 동적으로 배정된다

Garbage-First: 쓰레기 비율이 가장 높은 Region부터 골라서 수거한다. 적은 비용으로 많은 공간을 회수
Pause 목표 기반 동작: -XX:MaxGCPauseMillis=200(기본 200ms)을 주면, G1이 목표 안에 끝낼 수 있는 만큼의 Region만 골라 수거한다. "얼마나 오래 멈출지"를 개발자가 협상할 수 있게 됐다
수거 = 생존자를 다른 Region으로 복사 → Region 단위 Compact가 자연스럽게 일어나 CMS의 단편화 문제를 해결
Humongous 객체: Region 크기의 50%를 넘는 객체는 전용 Region(H)에 연속 할당된다. 앞서 본 "Old 직행 할당"이 G1에서 구현되는 방식이다. 거대 배열을 자주 만들면 Humongous 할당이 잦아져 GC 압박이 커진다 — 실무에서 대용량 byte[] 캐시가 문제 되는 지점이다

ZGC — 힙 크기와 무관한 정지 시간 (Java 15 정식, 21에서 세대 지원)

G1도 생존자 복사(Evacuation)는 STW로 한다. ZGC는 이 마지막 벽을 넘었다. 객체 이동조차 애플리케이션과 동시에 수행해, 힙이 수 TB여도 STW를 1ms 미만으로 유지한다.

핵심 기술은 두 가지다.

Colored Pointer — 64비트 포인터의 남는 상위 비트에 객체의 GC 상태(Marked, Remapped 등)를 심는다. 객체가 아니라 포인터 자체에 메타데이터를 넣는 발상이다.

Load Barrier — Write Barrier가 "쓸 때" 끼어들었다면, ZGC는 참조를 읽을 때 끼어든다.

// 개발자가 쓴 코드
Object o = container.field;

// ZGC가 실제로 실행하는 것 (개념적으로)
Object o = container.field;
if (포인터 색상이 현재 GC 단계와 안 맞으면) {
    o = 객체의 새 주소로 교정하고 포인터를 갱신;  // self-healing
}

GC가 객체를 옮기는 도중에 애플리케이션이 옛 주소를 읽으면, Load Barrier가 그 자리에서 새 주소로 고쳐준다. 그래서 "모든 참조를 한 번에 갱신하기 위한 STW"가 필요 없다. 대가는 모든 참조 읽기에 붙는 미세한 비용과 다소 높은 CPU/메모리 오버헤드다.

Tri-color Marking — Concurrent Mark가 객체를 잃어버리지 않는 이유

CMS 이후의 모든 Concurrent GC는 삼색 마킹으로 동작한다.

색의미

흰색	아직 방문하지 않음 (Mark 종료 시 흰색 = 수거 대상)
회색	방문했지만 자식들은 아직 탐색 전
검은색	자신과 자식 모두 탐색 완료

문제는 Mark 도중 애플리케이션이 이런 짓을 할 때다.

black.ref = white;   // 1. 검은 객체가 흰 객체를 새로 참조
gray.ref = null;     // 2. 회색에서 그 흰 객체로 가는 경로 제거

검은 객체는 "탐색 완료"라 다시 방문하지 않고, 흰 객체로 가는 다른 경로는 끊겼다. 살아있는 객체가 흰색인 채로 Mark가 끝나 수거돼버린다(lost object problem). 이를 막는 것도 Write Barrier다. 위 1번 같은 대입이 일어나면 Barrier가 감지해 해당 객체를 다시 회색으로 되돌리거나(Incremental Update, CMS 방식), 끊기기 직전의 참조를 기록해둔다(SATB, G1 방식).

5 그래서 뭘 써야 하나

워크로드선택이유

배치/오프라인 처리	Parallel GC	멈춤보다 총 처리량이 중요
일반적인 웹 서버 (힙 수 GB)	G1 (기본값)	처리량과 지연의 균형, 튜닝 부담 적음
초저지연 요구 (거래 시스템 등), 초대형 힙	ZGC	STW < 1ms, 힙 크기 무관
극소 리소스 컨테이너	Serial GC	오버헤드 최소

대부분의 경우 정답은 "기본값(G1)을 쓰고, 문제가 측정되면 그때 움직여라"다. GC 로그(-Xlog:gc*) 없이 GC를 튜닝하는 것은 지난 글의 표현을 빌리면, 참조 그래프를 안 보고 메모리 누수를 잡겠다는 것과 같다.

정리

개념핵심

Stop-the-World	Mark 중 그래프 변경을 막기 위한 전체 정지. GC 발전 = STW 축소의 역사
Safepoint	스레드가 안전하게 멈출 수 있는 지점. counted loop의 TTSP 함정 주의
Copying (Young)	약한 세대 가설의 구현. 죽은 객체는 건드리지 않고 생존자만 복사, 비용은 생존자 수에 비례, 단편화 원천 차단
승격 (Promotion)	강한 세대 가설의 구현. age 승격 / 조기 승격 / 직행 할당 3가지 경로로 Old행
Card Table / Write Barrier	세대간 참조 희소성 가설의 구현. dirty 카드만 스캔해 Old 전체 스캔 회피
Serial → Parallel	STW 자체의 병렬화, 처리량 중심
CMS → G1	Concurrent Mark 도입 → Region 구조 + Pause 목표 + 자연스러운 Compact
ZGC	Colored Pointer + Load Barrier로 객체 이동까지 동시 수행, STW < 1ms
Tri-color Marking	Concurrent Mark의 이론적 기반, Write Barrier가 lost object 방지

여기까지 GC 알고리즘의 진화와 STW, Card Table의 동작을 알아봤다. 다음 글에서는 GC 로그를 직접 읽고(-Xlog:gc*), 힙 덤프(jmap, MAT)로 지난 글의 누수 패턴들을 실제로 잡아내는 과정을 다룬다.

@Component가 Spring Boot에 등록되는 과정

myh7754 — Thu, 4 Jun 2026 01:21:08 +0900

@Component는 어떻게 Spring Bean으로 등록될까

@Component(혹은 @Service, @Repository 등)를 붙이면 Spring이 알아서 객체를 만들어 관리해 준다. 이 "알아서"의 내부 과정을 SpringApplication.run()부터 싱글톤 캐시에 올라가기까지 단계별로 따라가 본다.

본격적으로 들어가기 전에 Bean이 무엇인지부터 짚고 시작하자.

1. Bean이란?

Spring에서는 객체를 직접 new 해서 쓰지 않는다.

MemberService memberService = new MemberService();

이런 코드를 개발자 대신 Spring이 수행하고, 생명주기까지 관리한다. 이렇게 Spring 컨테이너가 생성·관리하는 객체를 Bean이라고 부른다.

2. 등록 과정의 시작점

@SpringBootApplication
public class App {
    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

이 코드가 실행되면 SpringApplication.run()이 호출되고, Spring Boot는 내부적으로 ApplicationContext 를 생성한다. 이 ApplicationContext가 컨테이너의 핵심이며, 다음 역할을 담당한다.

Bean 생성
Bean 저장
Bean 조회
DI(의존성 주입) 수행
생명주기 관리

3. @SpringBootApplication 뜯어보기

@SpringBootApplication은 사실 아래 세 어노테이션을 합쳐 놓은 것이다.

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan

이 중 Bean 등록과 직접 관련된 것은 @ComponentScan 이다.

4. @ComponentScan — 후보 탐색

컴포넌트 스캔은 @ComponentScan이 붙은 클래스의 패키지를 기준으로, 그 하위 패키지의 클래스들을 전부 탐색한다.

이때 ClassPath를 스캔하는데, 핵심은 클래스를 로딩하지 않는다는 점이다. 실제 클래스 파일(.class)을 읽되 ASM으로 바이트코드를 파싱해서 어노테이션 정보만 빠르게 확인한다. JVM에 클래스를 적재(load)하지 않고 "읽기만" 하기 때문에 가볍고 빠르다.

이렇게 스캔하면서 @Component가 붙은 후보들을 찾아낸다. 대표적으로 다음이 있다.

@Service
@Repository
@Controller
@RestController

이들을 한 번에 잡아낼 수 있는 이유는, 이 어노테이션들이 내부적으로 @Component를 메타 어노테이션으로 달고 있기 때문이다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Component   // ← 이 메타 어노테이션 덕분에 스캔 대상이 된다
public @interface Service {
    // 실제로는 @AliasFor("value") 등이 더 있지만 핵심은 @Component
}

5. BeanDefinition 생성 — 객체가 아니라 "설계도"

후보를 찾았다고 바로 객체를 만들지는 않는다. 먼저 BeanDefinition 을 만든다. BeanDefinition은 Bean의 설계도라고 보면 된다. 담기는 정보는 대략 다음과 같다.

항목설명

클래스 이름	어떤 클래스로 만들지
Scope	Singleton / Prototype 등
생성 방식	생성자 / 팩토리 메서드 등
생성자 정보	어떤 생성자를 쓸지
Lazy 여부	지연 초기화 대상인지
Primary 여부	동일 타입 충돌 시 우선순위

6. BeanDefinitionRegistry 등록

만들어진 BeanDefinition은 BeanDefinitionRegistry 에 저장된다.

memberService  →  BeanDefinition(MemberService)

즉 "이 클래스를 나중에 Bean으로 만들 예정"이라고 예약해 둔 상태다. 이때 Bean 이름은 기본적으로 클래스명의 첫 글자를 소문자로 바꾼 형태가 된다.

MemberService  →  memberService

참고: URLParser처럼 앞 두 글자가 모두 대문자인 경우엔 그대로 URLParser로 유지된다. (Introspector.decapitalize() 규칙)

7. BeanFactory가 객체를 생성한다

지금까지(4~6번)는 "설계도 등록" 단계였고, 이제부터 실제 객체가 만들어진다. 컨테이너 초기화 흐름은 다음과 같다.

refresh()
 ├─ invokeBeanFactoryPostProcessors()
 │     └─ ConfigurationClassPostProcessor  ← 여기서 @ComponentScan 실행 (4~6번)
 │
 └─ finishBeanFactoryInitialization()
       └─ preInstantiateSingletons()        ← 여기서 객체 생성 (7~11번)

preInstantiateSingletons()에서 싱글톤 Bean 생성이 시작된다.

8. 생성자 호출 (+ 생성자 주입)

생성자에 필요한 파라미터를 분석하고, 해당 Bean들을 찾아 주입하면서 객체를 만든다.

// 개념적으로는
new MemberService(memberRepository);

// 실제로는 Reflection 사용
Constructor.newInstance(찾은_Bean들);

여기서 생성자 주입은 객체 생성 시점에 함께 이루어진다. 이 부분도 AutowiredAnnotationBeanPostProcessor가 쓸 생성자를 골라준다(determineCandidateConstructors). 여기까지 오면 객체 생성 자체는 완료된다.

9. 의존성 주입 (필드 / setter)

객체가 만들어진 뒤, AutowiredAnnotationBeanPostProcessor 가 그 Bean을 훑어서 @Autowired가 붙은 필드나 setter에 필요한 Bean을 찾아 주입한다.

그런데 필드 주입은 안티패턴으로 분류되며, 생성자 주입이 권장된다. 이유는 다음과 같다.

① final을 못 붙인다 → 불변성이 깨진다

필드 주입은 객체를 만든 뒤에 값을 꽂는 방식이라 final을 쓸 수 없다. 생성자 주입은 final로 선언해서, 한 번 주입되면 바꾸지 못하게 막을 수 있다.

② 테스트 시 객체를 순수하게 못 만든다

MemberService s = new MemberService();  // repo가 null → NPE

필드 주입은 생성자에 의존성이 없으니, 순수하게 new로 만들면 필드가 비어 있다. 테스트하려면 Spring 컨테이너를 띄우거나 Reflection을 써야 한다. 생성자 주입이면 new MemberService(mockRepo) 한 줄로 끝난다.

③ 순환참조를 (조용히) 허용할 수 있다

A↔B 순환참조가 있을 때, 생성자 주입은 시작 시점에 무조건 에러로 터뜨려서 "설계가 잘못됐다"고 바로 알려준다.

⚠️ 버전 주의: 흔히 "필드 주입은 순환참조가 있어도 에러 없이 굴러간다"고 설명하는데, 이는 Spring Boot 2.6 미만에서의 이야기다. Spring Boot 2.6 / Spring Framework 5.3부터는 spring.main.allow-circular-references 기본값이 false 라서, 필드 주입이어도 기본 설정에서는 시작 시점에 BeanCurrentlyInCreationException이 발생한다. 옛날처럼 통과시키려면 해당 옵션을 true로 켜거나 @Lazy를 써야 한다. 즉 필드 주입은 "옵션을 켜면 순환참조를 숨길 수 있는" 반면, 생성자 주입은 아예 끌 수조차 없이 항상 막힌다는 점이 차이다.

④ 의존성이 숨겨진다

생성자 주입은 생성자 시그니처만 봐도 이 클래스가 무엇을 필요로 하는지 한눈에 드러난다. 필드 주입은 클래스 여기저기 흩어진 @Autowired를 전부 찾아봐야 한다.

10. 초기화 후처리 (@PostConstruct → AOP Proxy)

DI가 끝난 뒤 초기화 콜백과 프록시 처리가 이어진다.

@Autowired 주입 끝
   → @PostConstruct 실행        (postProcessBeforeInitialization 시점)
   → (InitializingBean.afterPropertiesSet / init-method)
   → AOP Proxy 생성             (postProcessAfterInitialization 시점)

@PostConstruct : "주입이 다 끝났으니 이제 초기화 로직을 돌려라"는 콜백.
AOP Proxy : @Transactional, @Async 같은 게 걸려 있으면 원본 객체를 프록시로 감싸서 바꿔치기한다. 초기화가 끝난 다음에 감싸진다는 게 포인트.

11. Singleton Cache 저장

완성된 Bean은 1차 캐시에 들어간다. DefaultSingletonBeanRegistry의 singletonObjects인데, ConcurrentHashMap<String, Object> 구조다.

// Spring 내부 소스
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

singletonObjects: { "memberService" → MemberService 객체 }

이제 getBean("memberService")를 호출하면 매번 새로 만드는 게 아니라 이 캐시에서 꺼내준다. 그래서 싱글톤이 "딱 하나"로 유지되는 것이다.

MemberService service = context.getBean(MemberService.class);  // 캐시에서 반환

참고: 싱글톤 3단계 캐시 사실 DefaultSingletonBeanRegistry에는 캐시가 세 개 있고, 이 구조가 9번에서 본 순환참조 해소의 핵심이다.

1차 singletonObjects : 완성된 Bean

2차 earlySingletonObjects : 생성은 됐지만 아직 미완성인(주입 진행 중) Bean

3차 singletonFactories : 미완성 Bean을 반환할 수 있는 ObjectFactory

생성 도중인 Bean을 3차 → 2차로 "조기 노출(early exposure)"해서 순환참조를 풀어내는 구조다. (단, 10번에서 본 것처럼 기본 설정에서는 순환참조 자체가 막혀 있다.)

정리

전체 흐름을 한 줄로 요약하면 이렇다.

@ComponentScan (ASM 스캔)
   → 후보 발견
   → BeanDefinition 생성
   → BeanDefinitionRegistry 등록
   → preInstantiateSingletons()
   → 생성자 호출 (+ 생성자 주입)
   → 필드/setter 주입
   → @PostConstruct → AOP Proxy
   → singletonObjects(1차 캐시) 저장

@Component 하나가 컨테이너 안에서 거치는 길이 생각보다 길다. 특히 "BeanDefinition 등록 단계"와 "실제 객체 생성 단계"가 분리되어 있다는 점, 그리고 생성자 주입과 필드 주입의 시점 차이를 이해하면 DI 관련 동작 대부분이 설명된다.

GC 동작 방식 및 원리 (1)

myh7754 — Tue, 2 Jun 2026 19:44:13 +0900

GC — 세대 가설과 GC Root

GC가 객체의 생사를 판별하는 근거와, 실무에서 자주 마주치는 GC Root발 메모리 누수 패턴을 코드와 함께 파헤친다.

C와 C++에서는 메모리 할당과 해제를 개발자가 직접 관리해야 한다. Java는 이 과정을 자동화한 GC(Garbage Collector)를 제공한다.

GC 알고리즘(G1, ZGC 등)과 Stop-the-World, Card Table, Write Barrier 등 세부 동작은 다음 글에서 다룬다. 이 글에서는 GC가 세대를 나누는 근거와 GC Root, 그리고 GC Root로 인한 메모리 누수 패턴까지만 짚는다.

1 GC를 뒷받침하는 3가지 가설

GC는 아래 3가지 가설을 근거로 동작 방식을 설계한다.

가설	내용	근거가 되는 설계
약한 세대 가설 (Weak Generational Hypothesis)	대부분의 객체는 생성된 직후 빠르게 사라진다	Young 영역 분리
강한 세대 가설 (Strong Generational Hypothesis)	오래 살아남은 객체일수록 더 오래 산다	Old 영역 분리
세대간 참조 희소성 (Intergenerational Reference Rarity)	Old 영역이 Young 영역을 참조하는 경우는 드물다	Card Table로 그 드문 참조만 기록 → Minor GC 시 Old 영역 전체를 스캔할 필요 없음

이 세 가설이 바로 Java GC가 Heap을 Young/Old로 나누고, Minor GC에서 Old 영역을 건너뛸 수 있게 하는 근거다.

2 GC 대상은 어떻게 선별되는가

GC 대상을 판별하는 알고리즘은 크게 2가지다.

Reference Counting

객체가 참조될 때마다 카운트를 +1 하고, 참조가 끊기면 -1 한다. 카운트가 0이 되면 GC 대상으로 판단한다.

단점은 순환 참조다. 서로를 참조하는 두 객체는 외부에서 접근 불가능해도 카운트가 0이 되지 않아 영원히 수거되지 않는다. 이 문제를 해결하는 것이 Reachability다.

Reachability

GC Root를 기준으로 참조 그래프를 탐색해, GC Root에서 끝까지 도달 가능(Reachable)한 객체만 살아있다고 판단한다. 도달할 수 없는 객체는 GC 대상이 된다.

GC Root란?

무조건 살아있다고 간주하는 시작점이다. GC는 이 지점들에서 출발해 참조 그래프를 탐색(Mark)하고, 방문하지 못한 객체를 수거(Sweep)한다.

GC Root의 종류

static 변수
스택 프레임의 지역 변수 / 매개변수
실행 중인 스레드

JVM에서 살아있는 모든 스레드 객체 자체가 GC Root다. 스레드가 살아있는 동안, 그 스레드의 스택 프레임과 내부 참조들은 모두 Reachable 상태를 유지한다.

3 GC Root로 발생하는 메모리 누수 패턴

GC는 도달 가능한 객체를 정확히 판단하지만, 개발자가 의도치 않게 GC Root까지의 참조 체인을 계속 살려두면 메모리 누수가 발생한다. 실무에서 자주 만나는 3가지 패턴을 코드로 살펴본다.

패턴 1: static 컬렉션에 지속적으로 추가

class EventBus {
    // static → GC Root → listeners의 모든 원소가 Reachable
    private static final List<EventListener> listeners = new ArrayList<>();

    public static void register(EventListener listener) {
        listeners.add(listener);
        // 제거 로직이 없으면 등록된 listener는 절대 GC되지 않음
    }
}

해결 1: 명시적 unregister() 제공

class EventBus {
    private static final List<EventListener> listeners = new ArrayList<>();

    public static void register(EventListener listener) {
        listeners.add(listener);
    }

    // 사용 측에서 반드시 호출해야 함
    public static void unregister(EventListener listener) {
        listeners.remove(listener);
        // listener → GC Root 체인 끊김 → GC 대상이 될 수 있음
    }
}

// 사용 예
EventListener listener = new MyListener();
EventBus.register(listener);
try {
    // ...
} finally {
    EventBus.unregister(listener);  // 반드시 해제
}

해결 2: WeakReference 활용

class EventBus {
    // WeakReference로 감싸면 listener를 Strong 참조하는 곳이 없을 때 GC 가능
    private static final List<WeakReference<EventListener>> listeners = new ArrayList<>();

    public static void register(EventListener listener) {
        listeners.add(new WeakReference<>(listener));
    }

    public static void notify(Event event) {
        Iterator<WeakReference<EventListener>> it = listeners.iterator();
        while (it.hasNext()) {
            EventListener listener = it.next().get();
            if (listener == null) {
                it.remove();  // 이미 GC된 항목 정리
            } else {
                listener.onEvent(event);
            }
        }
    }
}

WeakReference 방식은 unregister를 강제하지 않아도 외부에서 Strong 참조가 없어지면 자동으로 GC된다. 다만 get()이 null을 반환할 수 있으므로 null 체크가 필수다.

패턴 2: ThreadLocal 변수 미정리

// 스레드 풀 환경에서 스레드가 재사용되는 경우
private static final ThreadLocal<LargeObject> context = new ThreadLocal<>();

void handleRequest() {
    context.set(new LargeObject());
    process();
    // context.remove() 호출 안 하면?
    // 스레드가 풀로 반환된 후에도 ThreadLocal이 LargeObject를 참조
    // 해당 스레드가 살아있는 한(= GC Root) LargeObject도 살아있음
}

해결: finally 블록에서 반드시 context.remove() 호출.

void handleRequest() {
    context.set(new LargeObject());
    try {
        process();
    } finally {
        context.remove();  // 반드시 정리
    }
}

패턴 3: 익명 클래스 / 람다의 외부 참조

class View {
    private byte[] largeData = new byte[1024 * 1024];  // 1MB

    void startAsyncTask() {
        // 익명 클래스는 암묵적으로 외부 클래스(View) 인스턴스를 참조
        new Thread(() -> {
            // 이 람다가 살아있는 동안 View 인스턴스도 GC 불가
            // largeData도 함께 메모리에 남음
            doLongRunningTask();
        }).start();
    }
}

해결 1: 필요한 데이터만 지역변수로 캡처

class View {
    private byte[] largeData = new byte[1024 * 1024];  // 1MB

    void startAsyncTask() {
        // largeData에서 실제로 필요한 값만 추출해서 캡처
        // 람다는 View 인스턴스가 아닌 int 값만 참조 → View는 GC 가능
        int targetValue = extractTargetValue(largeData);

        new Thread(() -> {
            doLongRunningTask(targetValue);  // View 참조 없음
        }).start();
    }
}

해결 2: static 중첩 클래스 사용

class View {
    private byte[] largeData = new byte[1024 * 1024];

    void startAsyncTask() {
        // static 중첩 클래스는 외부 클래스 인스턴스를 암묵적으로 참조하지 않음
        new Thread(new StaticTask()).start();
    }

    // static → 외부 클래스(View)에 대한 암묵적 참조 없음
    private static class StaticTask implements Runnable {
        @Override
        public void run() {
            doLongRunningTask();  // View.this 참조 불가 → View GC 가능
        }
    }
}

내부 클래스(Inner Class)와 static 중첩 클래스(Static Nested Class)의 차이가 여기서 중요하다. 내부 클래스는 외부 인스턴스에 대한 암묵적 참조(Outer.this)를 갖지만, static 중첩 클래스는 그렇지 않다.

정리

개념	핵심
세대 가설 3가지	약한/강한 세대 가설로 Young·Old 분리, 참조 희소성으로 Card Table 기반 Minor GC 최적화
Reference Counting	참조 카운트 기반, 순환 참조 문제로 단독 사용 불가
Reachability	GC Root에서 도달 가능한 객체만 생존 판정
GC Root	static 변수, 스택 프레임의 지역변수/매개변수, 실행 중인 스레드
누수 패턴	static 컬렉션 미정리, ThreadLocal 미정리, 람다/익명 클래스의 외부 참조

여기까지 GC의 세대 가설과 GC Root를 알아봤다. 다음 글에서는 실제 GC 알고리즘(Serial, Parallel, G1, ZGC)과 Stop-the-World, Card Table의 동작을 이어서 다룬다.

JVM 정리 — Java 코드가 실행되기까지

myh7754 — Thu, 28 May 2026 17:17:31 +0900

JVM — Java 코드가 실행되기까지

Class Loader → Runtime Data Area → Execution Engine 전체 흐름을 코드와 함께 깊이 파헤친다.

Java 코드는 어떻게 실행될까?

main()을 실행하는 순간 JVM 안에서는 수십 가지 일이 동시에 벌어진다.

이 글에서는 Class Loader → Runtime Data Area → Execution Engine → GC로 이어지는 JVM 실행 흐름 전체를 코드와 함께 깊이 다룬다.

GC는 분량상 별도 글에서 다룬다. 이 글에서는 구조와 기본 동작만 짚는다.

Java 실행 흐름 개요

.java 파일
  └─► javac (컴파일러)
        └─► 플랫폼 독립적인 .class (바이트코드)
              └─► JVM
                    ├─ Class Loader      → .class를 메모리에 적재
                    ├─ Runtime Data Area → 메모리 영역 구성
                    └─ Execution Engine  → 바이트코드 → 기계어 → 실행
                                                  ↑
                                              GC가 Heap 관리

바이트코드는 OS에 종속되지 않는다. OS마다 구현된 JVM이 이를 받아서 해당 플랫폼의 기계어로 변환하며 실행한다. "Write Once, Run Anywhere"가 가능한 이유다.

예시 코드

아래 코드를 기준으로 JVM의 각 영역이 어떻게 동작하는지 설명한다.

public interface Animal {
    String getName();
}

public class Dog implements Animal {
    public static int count = 2;    // static → Method Area
    private String name;            // instance 필드 → Heap

    public Dog(String name) { this.name = name; }

    @Override
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
}

public class Main {
    public static void main(String[] args) {
        int x = 7;                          // Stack: primitive 직접 저장
        int[] numbers = {1, 2, 3};          // Stack: 참조값(0x4000) → Heap: int[]
        Animal animal = new Dog("coco");    // Stack: 참조값(0x1000) → Heap: Dog①
        Dog d = new Dog("changed");         // Stack: 참조값(0x2000) → Heap: Dog②

        Thread thread2 = new Thread(() -> {
            Dog sharedDog = (Dog) animal;   // Dog①을 두 스레드가 공유 → Race Condition
            int localVar = 3;               // Thread 2의 Stack에만 존재
        });
        thread2.start();
    }
}

이 코드를 실행하면 메모리는 아래처럼 구성된다.

1 Class Loader

.class 파일을 JVM 메모리에 올리는 역할을 한다. 세 단계로 동작한다.

1-1. Loading

.class 파일을 읽어 JVM 메모리에 적재한다.

1-2. Linking

Verification
바이트코드가 JVM 명세에 맞는지 검증한다. 손상된 클래스 파일이나 명세 위반 코드를 이 단계에서 차단한다.

Preparation
static 변수에 타입별 기본값을 할당한다. (int → 0, boolean → false, 참조형 → null)

Resolution
클래스 파일 안의 심볼릭 참조(#1, #2 …)를 실제 메모리 주소로 치환한다. 이 심볼릭 참조들은 Method Area의 Runtime Constant Pool에 저장되어 있다가 이 단계에서 실제 참조로 교체된다.

Runtime Constant Pool이란?
클래스 파일 안에는 "coco" 같은 상수, 메서드 시그니처, 필드 이름 등이 #1, #3 같은 심볼릭 인덱스로 저장되어 있다. Class Loader가 클래스를 메모리에 올리면 이 정보들이 Method Area의 Runtime Constant Pool에 적재되고, Resolution 단계에서 실제 메모리 주소로 교체된다.

1-3. Initialization

static 변수에 코드에서 정의한 실제 값을 할당하고, static 블록을 실행한다.

public static int count = 2;
// Preparation:   count = 0  (기본값)
// Initialization: count = 2  (실제 값)

Lazy Loading: Class Loader는 필요한 시점에만 클래스를 로드한다. 처음 실행 시 모든 클래스를 올리지 않는다. 이 덕분에 애플리케이션 시작 비용이 줄어든다.

Class Loader 계층 구조

Bootstrap Class Loader    (C++로 구현, JVM 내장)
  └─ java.lang.String, Object 등 핵심 클래스
Platform Class Loader     (Java 9 이전: Extension Class Loader)
  └─ Java 확장 라이브러리 (java.sql, java.xml 등)
Application Class Loader
  └─ 내가 만든 클래스 + kafka, redis 등 외부 라이브러리

Java 9 변경사항: Java 9에서 모듈 시스템(JPMS)이 도입되면서 Extension ClassLoader가 Platform ClassLoader로 이름이 바뀌고 역할도 재정의됐다. Java 8 이하 자료를 볼 때 참고하자.

부모 위임 모델 (Parent Delegation Model)

클래스 로드 요청이 오면 자식 ClassLoader가 직접 처리하기 전에 부모에게 먼저 위임한다. 부모가 처리하지 못할 때만 자식이 처리한다.

클래스 로드 요청 (Dog.class)
  → Application ClassLoader: "내가 먼저 로드할게"
      → Platform ClassLoader에 위임
          → Bootstrap ClassLoader에 위임
              → "Dog는 모름" → 반환
          → "Dog는 모름" → 반환
      → Application ClassLoader가 직접 로드

이 구조 덕분에 java.lang.String처럼 핵심 클래스를 외부에서 악의적으로 덮어쓰는 것을 방지할 수 있다.

2 Runtime Data Area

JVM이 OS로부터 할당받아 사용하는 메모리 공간이다. 스레드 공유 여부에 따라 두 가지로 나뉜다.

스레드 비공유 영역 (Thread-private)

각 스레드가 독립적으로 보유하는 영역이다.

PC Register

현재 스레드가 실행 중인 바이트코드의 위치(주소)를 저장한다. 스레드 스케줄링으로 CPU를 뺏겼다가 다시 받았을 때 어디서부터 재개할지 추적하는 역할이다. Native Method 실행 중에는 undefined 상태가 된다.

JVM Stack

메서드 호출마다 Stack Frame이 하나씩 쌓이고, 메서드가 종료되면 pop된다. GC 없이 자동 해제된다.

Stack Frame 내부 구조:

Local Variable Array: 지역 변수, 파라미터
Operand Stack: 연산 중간 값 (바이트코드 명령어들이 이 스택을 읽고 씀)
Frame Data: 메서드 반환 주소, 상수 풀 참조

main() Stack Frame
├─ x        = 7          (int, primitive → 값 직접 저장)
├─ numbers  = 0x4000     (int[], 참조값만 저장 → 실제 배열은 Heap)
├─ animal   = 0x1000     (Dog①의 Heap 주소)
└─ d        = 0x2000     (Dog②의 Heap 주소)

StackOverflowError: 재귀 호출이 끝없이 쌓이면 Stack 공간이 초과된다. -Xss 옵션으로 스택 크기를 조절할 수 있다.

Native Method Stack

C/C++로 작성된 Native Method 실행 전용 스택이다. JNI(Java Native Interface)와 함께 동작한다.

스레드 공유 영역 (Thread-shared)

모든 스레드가 접근 가능한 영역이다.

Heap

new 키워드로 생성된 객체 인스턴스가 저장된다. 모든 스레드가 공유하기 때문에 멀티스레드 환경에서 Race Condition이 발생할 수 있다. GC의 주요 대상이다.

Heap
├── Young Generation
│   ├── Eden       ← new 로 생성된 객체가 처음 올라오는 곳
│   └── Survivor (S0, S1)
└── Old Generation ← 오래 살아남은 객체가 이동하는 곳

String Constant Pool

Heap 안에 존재하는 문자열 리터럴 전용 공간이다.

String a = "hello";             // Pool에 "hello" 생성 후 참조
String b = "hello";             // Pool에 이미 있으므로 재사용 → a == b: true
String c = new String("hello"); // new 키워드 → Pool 아닌 Heap에 별도 객체 생성
                                // a == c: false, a.equals(c): true

왜 Java 7부터 Pool이 Heap으로 이동했나?
이전까지는 Pool이 PermGen(Permanent Generation) 영역에 있었다. PermGen은 크기가 고정되어 있어 문자열이 많이 쌓이면 OutOfMemoryError가 발생하는 문제가 있었다. Java 7부터 Pool을 Heap으로 옮겨 GC 대상이 되도록 해 이 문제를 해결했다.

intern() 메서드를 사용하면 Heap에 생성된 String 객체를 Pool로 이동시키거나, 이미 Pool에 동일한 값이 있으면 그것을 재사용할 수 있다.

Method Area

클래스 자체의 메타데이터가 올라오는 곳이다.

저장되는 정보:

클래스 이름, 부모 클래스, 인터페이스 정보
static 변수 (예: Dog.count = 2)
메서드 바이트코드
Runtime Constant Pool (심볼릭 참조 → Resolution 후 실제 주소로 교체)

Java 8: PermGen → Metaspace
Java 8 이전에는 Method Area가 Heap 내부의 PermGen으로 구현되어 있었다. 크기가 고정되어 있어 클래스를 많이 로드하면 java.lang.OutOfMemoryError: PermGen space가 발생했다. Java 8부터 Metaspace로 전환됐다. Metaspace는 JVM Heap이 아닌 Native Memory(OS가 관리하는 메모리)를 직접 사용하기 때문에 크기가 동적으로 조절된다. -XX:MaxMetaspaceSize로 상한을 설정할 수 있다.

3 Execution Engine

Class Loader가 올리고, Runtime Data Area가 저장하면, Execution Engine이 실행한다. 세 가지 컴포넌트로 구성된다.

Interpreter

바이트코드를 한 줄씩 읽어 기계어로 변환하며 실행한다. 구현이 단순하고 즉시 실행이 가능하다.

단점: 같은 코드를 반복 실행해도 매번 새로 해석한다. 자주 호출되는 코드에서는 병목이 생긴다.

JIT Compiler (Just-In-Time)

Interpreter의 반복 해석 문제를 보완하기 위해 도입됐다. JVM이 실행 중에 반복 호출되는 코드(핫스팟)를 감지하면, 해당 바이트코드를 통째로 네이티브 코드로 컴파일해 캐싱한다. 이후 동일한 코드 실행 시 컴파일 없이 캐시된 네이티브 코드를 바로 실행한다.

처음 실행  → Interpreter가 한 줄씩 해석
반복 감지  → JIT가 네이티브 코드로 컴파일 + 캐싱
이후 실행  → 캐싱된 네이티브 코드 바로 실행 (빠름)

왜 처음부터 JIT를 안 쓰나? 한 번만 실행되는 코드까지 전부 컴파일하면 컴파일 비용 자체가 오히려 더 크다. Interpreter로 시작해서 자주 쓰이는 코드만 JIT가 가져가는 구조가 효율적이다.

Tiered Compilation — C1 / C2

Java 7부터 기본값. JIT를 두 단계로 나눠 점진적으로 최적화를 적용한다.

호출 횟수          컴파일러
0회              → Interpreter
~2,000회         → C1 (가벼운 최적화)
~10,000회        → C2 (공격적인 최적화)

위 수치는 JVM 기본값이다. -XX:CompileThreshold 옵션으로 직접 조절할 수 있다. JVM 버전이나 환경에 따라 실제 임계값은 다를 수 있다.

C1 (Client Compiler)
빠르게 컴파일하고 가벼운 최적화를 수행한다. 인라이닝, 기본 최적화가 주다. 목적은 컴파일 지연 최소화다.

C2 (Server Compiler)
컴파일이 느리지만 공격적인 최적화를 수행한다. 루프 최적화, 탈출 분석(Escape Analysis), 인라이닝 등을 적극 적용한다. 목적은 장기 실행 성능 극대화다.

C2 주요 최적화

① 인라이닝 (Inlining)

메서드 호출을 없애고 호출부에 코드를 직접 삽입한다.

// 최적화 전
int result = add(a, b);
int add(int x, int y) { return x + y; }

// C2 인라이닝 후
int result = a + b;  // Stack Frame 생성/반환 오버헤드 제거

메서드 호출은 Stack Frame 생성 → 인자 복사 → 반환 주소 저장 등의 비용이 있다. 짧은 메서드가 루프 안에서 반복 호출될수록 인라이닝 효과가 크다.

② 루프 최적화 (Loop Optimization)

반복문 내부의 불필요한 연산을 제거하거나 재구성한다. 대표적인 예가 루프 불변 코드 이동 (Loop Invariant Code Motion)이다.

// 최적화 전: list.size()를 매 반복마다 호출
for (int i = 0; i < list.size(); i++) {
    process(list.get(i));
}

// C2 최적화 후: 루프 불변 값을 밖으로 꺼냄
int size = list.size();
for (int i = 0; i < size; i++) {
    process(list.get(i));
}

이 외에도 루프 언롤링(Loop Unrolling)(반복 횟수를 줄이고 본문을 펼침), 벡터화(SIMD 명령어 활용) 등도 수행한다.

③ 탈출 분석 (Escape Analysis)

객체가 생성된 메서드 밖으로 "탈출"하는지 분석한다. 탈출하지 않는 객체는 Heap 대신 Stack에 할당한다.

// 탈출하는 경우 → Heap 할당
Dog createDog() {
    Dog d = new Dog("coco");
    return d;  // 메서드 밖으로 나감 → Heap
}

// 탈출하지 않는 경우 → Stack 할당 가능
void process() {
    Dog d = new Dog("coco");
    System.out.println(d.getName());
    // d가 이 메서드 안에서만 쓰임 → C2가 Stack에 할당
}  // 메서드 종료 시 자동 해제 → GC 부담 없음

Heap 할당은 GC 대상이 되어 Stop-the-World를 유발할 수 있다. Stack 할당은 메서드 종료 시 자동 해제되어 GC를 완전히 우회한다.

④ 락 제거 (Lock Elision)

탈출 분석의 연장선이다. 객체가 단일 스레드 안에서만 사용된다고 분석되면, 해당 객체의 synchronized 블록 자체를 제거한다.

void method() {
    StringBuffer sb = new StringBuffer();  // synchronized 메서드를 가짐
    sb.append("hello");
    sb.append(" world");
    System.out.println(sb.toString());
    // sb가 이 메서드 밖으로 나가지 않음
    // → C2가 synchronized 자체를 제거
}

StringBuffer는 메서드마다 synchronized가 걸려 있지만, 로컬에서만 쓰이는 경우 락 비용 없이 실행된다.

OSR (On-Stack Replacement)

JIT 설명에서 빠지기 쉬운 개념이다. 일반적으로 JIT는 메서드 단위로 컴파일하는데, 긴 루프가 있으면 문제가 생긴다. 루프가 끝나야 다음 메서드 호출이 발생하고, 그때서야 JIT가 적용되기 때문이다.

OSR은 이미 실행 중인 루프를 중간에 JIT 컴파일된 코드로 교체하는 기법이다. Interpreter로 루프를 돌다가 핫스팟으로 감지되는 순간, 루프가 끝날 때까지 기다리지 않고 즉시 최적화된 네이티브 코드로 전환한다.

[루프 실행 중, Interpreter]
  i=0  → i=1  → ... → i=4999  ← 핫스팟 감지
                               ← JIT 컴파일 완료
  i=5000 → 이 시점부터 네이티브 코드로 교체(OSR)
  i=5001 → i=5002 → ... [이후 JIT 속도로 실행]

Deoptimization

C2가 공격적 최적화를 수행했는데 이후에 그 가정이 틀렸음이 확인되면, JVM은 최적화를 취소하고 Interpreter로 되돌아간다.

void process() {
    Dog d = new Dog("coco");
    // C2 판단: "d는 탈출하지 않는다" → Stack 할당으로 최적화
    // 이후 리플렉션 등으로 d가 외부에 노출되는 경우가 생기면?
    // → Deoptimization: 최적화 취소 → Interpreter로 복귀
}

Deoptimization은 JVM이 안전하게 동작을 보장하기 위한 메커니즘이다. -XX:+PrintCompilation 옵션을 켜면 JIT 컴파일과 Deoptimization 과정을 로그로 확인할 수 있다.

4 GC (Garbage Collector)

Heap에서 더 이상 참조되지 않는 객체를 자동으로 제거한다. Java는 개발자가 직접 메모리를 해제하지 않아도 된다.

1. 객체 생성        → Eden에 할당
2. Eden이 꽉 참     → Minor GC 발생
3. 살아남은 객체    → Survivor로 이동 (age 증가)
4. age 임계값 초과  → Old Generation으로 이동 (Promotion)
5. Old Gen이 꽉 참  → Major GC (Full GC) 발생

GC 알고리즘(G1, ZGC 등), Stop-the-World, Card Table, Write Barrier 등 세부 동작은 다음 글에서 다룬다.

정리

컴포넌트	역할
Class Loader	`.class` 파일을 Loading → Linking → Initialization 순으로 메모리에 적재
Runtime Data Area	Thread-private(PC, Stack, Native Stack) + Thread-shared(Heap, String Pool, Method Area)
Execution Engine	Interpreter로 시작, 핫스팟 감지 시 JIT(C1→C2)로 최적화. OSR, Deopt, Escape Analysis 등 수행
GC	Heap의 unreachable 객체를 자동 제거

JVM은 단순한 실행 환경이 아니다. Class Loader가 보안을 담당하고, Runtime Data Area가 메모리를 구조화하고, Execution Engine이 런타임에 코드를 분석해 최적화하는, 정교하게 설계된 시스템이다.

Deboard 블로그 프로젝트 좋아요 동시성 및 데드락 문제 해결과정

myh7754 — Sun, 12 Apr 2026 13:34:17 +0900

좋아요 동시성 문제 — 데드락에서 Race Condition까지

toggleLike 구현 후 동시성 테스트를 작성하는 과정에서 단계적으로 발견한 두 가지 문제와 해결 과정을 정리한다.

P — 문제 발견 과정

toggleLike 구조

좋아요 토글은 직관적으로 이렇게 동작한다.

1. (userId, postId)로 좋아요 레코드 조회
2. 있으면 → likeCount 감소 + 레코드 삭제
3. 없으면 → likeCount 증가 + 레코드 삽입

조회와 삽입이 별도 쿼리로 나뉘어 있어 두 요청이 동시에 진입하면 정합성이 깨질 수 있다고 판단했다.

동시성 테스트 작성

CountDownLatch로 100개 스레드를 동시에 출발시키는 테스트를 작성했다.

CountDownLatch startLatch = new CountDownLatch(1);
CountDownLatch doneLatch = new CountDownLatch(100);

for (int i = 0; i < 100; i++) {
    executorService.submit(() -> {
        startLatch.await(); // 100개 스레드 동시 출발 대기
        likeService.toggleLike(postId);
        doneLatch.countDown();
    });
}
startLatch.countDown(); // 동시 출발 신호
doneLatch.await();

테스트 실행 → 데드락 발생

예상했던 race condition보다 먼저 데드락이 터졌다.

com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException:
Deadlock found when trying to get lock; try restarting transaction

A — 1차: 데드락 분석 및 해결

원인: FK shared lock upgrade 충돌

초기 구현 코드 흐름은 이랬다.

Optional<Likes> likes = likesRepository.findByPostIdAndUserId(postId, userId);
if (likes.isPresent()) {
    likesRepository.delete(likes.get());       // Likes 조작
} else {
    likesRepository.save(Likes.toEntity(...)); // Likes INSERT ← FK로 Post에 shared lock
}
int count = likesRepository.countByPostId(postId);
Post post = postService.getPostById(postId);   // Post SELECT
post.setLikeCount(count);                      // commit 시 Post UPDATE (exclusive lock 필요)

likes 테이블은 post_id로 posts에 FK를 가지고 있다. InnoDB는 FK 참조 무결성 확인을 위해 INSERT 시 참조 대상 행(posts)에 shared lock을 획득한다.

이후 commit 시점에 dirty checking으로 UPDATE posts가 실행되는데 exclusive lock이 필요하다.

TX A: INSERT likes → posts shared lock 획득
      → commit 시 posts exclusive lock 필요 (TX B가 shared lock 보유 중 → 대기)

TX B: INSERT likes → posts shared lock 획득
      → commit 시 posts exclusive lock 필요 (TX A가 shared lock 보유 중 → 대기)

→ 두 트랜잭션이 각각 shared lock을 쥔 채 upgrade를 기다림 → Deadlock

교착상태 4조건 중 점유대기(hold-and-wait) 가 성립하고 있었다.

해결: posts UPDATE를 먼저 실행

posts에 대한 UPDATE를 likes 조작보다 먼저 실행하면 exclusive lock을 선점할 수 있다. 이후 INSERT likes의 FK shared lock 요청은 자신의 exclusive lock으로 만족되므로 순환 대기가 사라진다.

// 변경 후 — posts UPDATE 먼저, likes 조작 나중
if (likes.isPresent()) {
    postRepository.decreaseLikeCount(postId);  // posts UPDATE 먼저
    likesRepository.delete(likes.get());        // Likes DELETE 나중
} else {
    postRepository.increaseLikeCount(postId);  // posts UPDATE 먼저
    likesRepository.save(...);                  // Likes INSERT 나중
}

또한 getReferenceById로 User/Post 프록시만 가져와 불필요한 SELECT를 제거했다.

Post post = postService.getPostReferenceById(postId);  // SELECT 없이 프록시만 반환
User user = userService.getUserReferenceById(userId);  // SELECT 없이 프록시만 반환

데드락 해결 후 재테스트

데드락은 사라졌다. 하지만 같은 사용자가 동시에 요청을 보내면 likes 행이 중복 삽입되는 문제가 남아 있었다. 그리고 더 근본적인 문제가 보이기 시작했다.

A — 2차: Race Condition 분석 및 해결

문제 1: likeCount Lost Update

기존 dirty checking 방식은 read → modify → write 3단계가 분리되어 있어 비원자적이다.

TX A: post 읽음 (likeCount = 5) ──── +1 ──── likeCount = 6 commit
TX B: post 읽음 (likeCount = 5) ──── +1 ──── likeCount = 6 commit  ← A 덮어씀
→ 기대값: 7, 실제값: 6

실제로 테스트로 확인했다.

[dirty checking] likeEntity 수: 100, likeCount: 6 → 불일치

100명이 동시에 좋아요를 눌렀는데 likes 행은 100개가 정상 저장됐지만 likeCount는 6으로 기록됐다. 좋아요 자체는 되는데 화면에 표시되는 숫자가 틀리는 문제다.

문제 2: 중복 likes 행 삽입

같은 사용자가 수십 ms 간격으로 동시에 요청을 보내면 두 요청이 모두 "없음"을 읽고 INSERT를 시도한다.

TX A: findByPostIdAndUserId → 없음 → INSERT likes
TX B: findByPostIdAndUserId → 없음 → INSERT likes  ← 중복 행 삽입

모바일 더블탭, 네트워크 재전송 같은 상황에서 발생할 수 있는 구조적 취약점이다.

방안 비교

방안 1: 비관적 락 (Pessimistic Lock)

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT p FROM Post p WHERE p.id = :postId")
Optional<Post> findByIdForUpdate(@Param("postId") Long postId);

인기 게시글에 트래픽이 몰릴수록 그 행 하나에 락 경합이 집중되어 처리량이 선형으로 떨어진다. 또한 데드락 해결을 위해 Post SELECT를 제거한 방향과 역행한다.

방안 2: 낙관적 락 + @Retryable

@Retryable(value = {ObjectOptimisticLockingFailureException.class}, maxAttempts = 3)
public void toggleLike(Long postId) { ... }

lost update는 해결되지만 중복 INSERT 문제는 여전히 UNIQUE 제약이 필요하다. 결국 UNIQUE 제약을 쓰면서 낙관적 락을 추가하는 셈인데, Post 엔티티에 @Version을 두면 RSS 업데이트, 조회수 등 Post를 건드리는 다른 모든 연산과 버전 충돌이 생긴다.

실측 검증: @Version을 추가하고 100명 동시 좋아요 테스트를 돌렸다.

[낙관적 락] likeEntity 수: 12, likeCount: 12  ← 88건 데이터 유실

30회 재시도 설정에도 100명 중 12명만 커밋에 성공했다. 인기 게시글은 동시 트래픽이 한 행에 집중되는 특성상 낙관적 락은 재시도가 재시도를 부르는 구조가 된다.

방안 3: Redis 분산락

Boolean acquired = redisTemplate.opsForValue()
    .setIfAbsent("lock:likes:" + userId + ":" + postId, "1", Duration.ofSeconds(5));

두 문제를 모두 해결하지만 좋아요처럼 결국 DB에 써야 하는 작업에서는 Redis가 속도 이점을 제공하지 못한다. DB 왕복은 어차피 필요하고, Redis 락 획득/해제 왕복이 추가로 붙는다.

실측 결과: 비관적 락 2617ms → Redis 분산락(spin-wait) 6167ms. DB만 쓰는 것보다 느렸다.

Redis 장애 시 좋아요 기능 전체가 마비된다. Redis 분산락이 유효한 케이스는 재고 차감처럼 UNIQUE 제약으로 막을 수 없거나, 외부 API 호출 제한처럼 DB가 없는 자원을 조정해야 하는 상황이다.

방안 4: synchronized

public synchronized void toggleLike(Long postId) { ... }

synchronized는 JVM 메모리의 모니터 락을 사용한다. Spring Bean은 싱글톤이라 서버 1대 안에서는 동일한 인스턴스를 공유하므로 락이 동작한다.

하지만 서버가 2대 이상이면 각 JVM은 독립된 프로세스라 서버 A의 락이 서버 B에 아무 영향을 주지 않는다. DB는 공유하고 있으므로 두 서버가 동시에 같은 행을 수정하는 상황이 그대로 발생한다.

서버 A (JVM 1)                서버 B (JVM 2)
┌─────────────────┐           ┌─────────────────┐
│  synchronized   │           │  synchronized   │
│  → 락 획득 ✓   │           │  → 락 획득 ✓   │  ← 서로 모름
└─────────────────┘           └─────────────────┘
        ↓                             ↓
    DB (공유)  ←─────────────────────┘

현재 프로젝트가 단일 서버라도 스케일아웃 순간 무력화되는 방어는 설계 단계에서 제외해야 한다.

방안 5: DB UNIQUE + @Modifying 원자적 SQL (채택)

두 문제를 각각 가장 단순하게 해결한다.

중복 INSERT 방지: (user_id, post_id) UNIQUE 제약으로 DB 레벨에서 차단
lost update 방지: UPDATE Post SET likeCount = likeCount + 1 으로 DB가 현재 값 기준 원자적 처리

// 변경 전 — read-modify-write, 간격 존재 → lost update
post.setLikeCount(post.getLikeCount() + 1);

// 변경 후 — DB가 원자적으로 처리, 간격 없음
@Modifying
@Query("UPDATE Post p SET p.likeCount = p.likeCount + 1 WHERE p.id = :postId")
void increaseLikeCount(@Param("postId") Long postId);

채택 이유:

두 문제를 모두 해결하는 유일한 방안이 DB 제약 + 원자적 UPDATE 조합
낙관적 락도 결국 UNIQUE가 필요하므로 @Version 추가 없이 @Modifying만으로 충분
Redis 의존성 없이 DB만으로 정합성 보장
정상 경로에서 추가 쿼리 없음

A — 구현

1. DB UNIQUE 제약

@Entity
@Table(
    name = "likes",
    uniqueConstraints = {
        @UniqueConstraint(columnNames = {"user_id", "post_id"})
    }
)
public class Likes { ... }

2. 원자적 likeCount 업데이트

@Modifying
@Query("UPDATE Post p SET p.likeCount = p.likeCount + 1 WHERE p.id = :postId")
void increaseLikeCount(@Param("postId") Long postId);

@Modifying
@Query("UPDATE Post p SET p.likeCount = p.likeCount - 1 WHERE p.id = :postId AND p.likeCount > 0")
void decreaseLikeCount(@Param("postId") Long postId);

AND p.likeCount > 0 조건으로 음수 방지도 함께 처리한다.

3. 예외 처리

@Transactional
public void toggleLike(Long postId) {
    Long userId = userService.getCurrentUserId();
    try {
        Optional<Likes> like = likesRepository.findByPostIdAndUserId(postId, userId);
        if (like.isPresent()) {
            postRepository.decreaseLikeCount(postId);
            likesRepository.delete(like.get());
        } else {
            Post post = postService.getPostReferenceById(postId);
            User user = userService.getUserReferenceById(userId);
            postRepository.increaseLikeCount(postId);
            likesRepository.save(Likes.toEntity(user, post));
        }
    } catch (DataIntegrityViolationException e) {
        // UNIQUE 제약 위반 = 중복 요청
        // 트랜잭션 롤백으로 increaseLikeCount도 함께 원복 → likeCount 정합성 유지
        log.error("중복 좋아요 요청 차단: userId={}, postId={}", userId, postId);
    }
}

DataIntegrityViolationException 발생 시 트랜잭션 전체가 롤백되므로 이미 실행된 increaseLikeCount도 함께 원복된다. likeCount 정합성이 자동으로 유지된다.

R — 결과

CountDownLatch 기반 동시성 테스트 3종으로 검증했다.

테스트	likeEntity 수	likeCount	결과
[비교] dirty checking 100명 동시	100	6	불일치 — 문제 증명
@Modifying JPQL 100명 동시	100	100	일치 — 정상
동일 사용자 100회 동시 요청	1	1	중복 차단 확인

비관적 락 대비 인기 게시글에서 락 경합 없이 동시 처리량을 유지하면서 데이터 정합성을 보장한다.

R — 성능 비교

정합성 검증 이후, 각 방식을 동일 조건(100명 동시, 단일 서버)에서 TransactionTemplate으로 직접 실행해 처리시간을 측정했다.

방식	처리시간	성공 건수	비고
낙관적 락 (30회 재시도)	1502ms	12/100	빠른 게 아니라 88건 포기 — 데이터 유실
@Modifying JPQL	2339ms	100/100	정합성 + 처리량 모두 확보
synchronized	2642ms	100/100	단일 JVM에서만 유효
비관적 락	2617ms	100/100	완전 직렬화, lock 보유 시간 길어
Redis 분산락 (spin-wait)	6167ms	100/100	DB 왕복 + Redis 왕복 중복

주의: 절대 수치는 JVM 워밍업 순서의 영향을 받는다. 방향성 참고용으로 해석해야 한다.

낙관적 락 결과 해석

1502ms로 가장 빠르게 보이지만 12건만 실제로 저장됐다. "빠른 것"이 아니라 88개 스레드가 재시도를 포기하고 조기 종료한 것이다. 인기 게시글처럼 트래픽이 한 행에 집중되는 환경에서 낙관적 락은 성능 해법이 아니다.

Redis 분산락 결과 해석

Redis 자체는 마이크로초(μs) 단위의 인메모리 저장소다. 느린 이유는 Redis가 아니라 구조에 있다.

비관적 락:      앱 → DB (1번 왕복)
Redis 분산락:   앱 → Redis (SETNX) → DB → Redis (DEL)  (3번 왕복)

좋아요는 결국 DB에 써야 하므로 DB 왕복을 줄일 수 없다. Redis 락 획득/해제 왕복이 추가로 붙어 항상 DB 단독보다 느리다. Redis 분산락이 의미 있는 케이스는 DB가 없는 자원(외부 API 제한, 이메일 중복 발송 방지 등)을 조정할 때다.

마치며

테스트가 없으면 보이지 않는 버그가 있다

동시성 문제는 코드 리뷰만으로 발견하기 어렵다. CountDownLatch로 동시 실행을 강제하는 테스트를 작성하고 나서야 데드락이 드러났고, 데드락을 해결한 뒤에야 그 아래 숨어 있던 race condition이 보였다.

하나를 고치면 다음 문제가 보인다

데드락을 해결하자 lost update가 드러났다. 첫 번째 문제가 더 깊은 구조적 취약점을 가리고 있었던 것이다.

DB를 신뢰하라

애플리케이션 레이어의 check-then-act 로직은 동시성 환경에서 보장을 제공하지 못한다. DB UNIQUE 제약과 원자적 UPDATE는 어떤 레이어에서 실수가 나와도 최종 보루가 되어준다.

브라우저에 url을 입력 후 과정

myh7754 — Wed, 18 Mar 2026 20:42:57 +0900

1. 먼저 리다이렉트가 있다면 리다이렉트를 진행하고 없다면 그대로 해당 요청에 대한 과정이 진행됨.

2. 캐싱 브라우저 캐시, os 캐시를 확인

3. 없다면 DNS 서버에 "www.naver.com의 IP 주소가 뭐야?"라고 물어봄 -> 도메인을 ip 주소로 맵핑

4. DNS 서버로부터 223.130.195.200 같은 실제 IP 주소를 받아와.

5. TCP/IP 연결 -> IP 주소를 알았으니 이제 서버와 연결 통로를 만들어야 해. 이때 신뢰성 있는 연결을 위해 3-Way Handshake 과정을 거쳐.

클라이언트 -> 서버: 연결하자! (SYN)
서버 -> 클라이언트: 그래, 연결하자! 나도 준비됐어. (SYN+ACK)
클라이언트 -> 서버: 확인했어. 이제 데이터 보낼게! (ACK)

6. Http 요청 메시지 전송. 연결이 완료되면 브라우저는 서버에 실제 데이터를 달라고 요청해

-> "GET /index.html HTTP/1.1" 같은 메시지를 담은 HTTP Request를 보지.

7. 서버의 응답 및 데이터 전송

서버(WAS)는 요청을 분석해서 필요한 데이터(HTML, JSON 등)를 준비해. 성공적이라면 "200 OK" 상태 코드와 함께 HTML 파일을 브라우저로 다시 보내줘.

8 여기서 랜더링 과정이 발생

https://myh7754.tistory.com/43

SSR, CSR, SPA 차이점 및 개념, Virtual Dom

SPA용자가 클릭을 할 때마다 서버에서 새로운 .html 파일을 새로 받아오는 게 아니라, 처음에 받은 페이지 하나에서 필요한 부분만 교체하며 보여주는 방식.CSR 클라이언트 사이드 랜더링 SPA라는

myh7754.tistory.com

SSR, CSR, SPA 차이점 및 개념, Virtual Dom

myh7754 — Wed, 18 Mar 2026 19:27:40 +0900

SPA

용자가 클릭을 할 때마다 서버에서 새로운 .html 파일을 새로 받아오는 게 아니라, 처음에 받은 페이지 하나에서 필요한 부분만 교체하며 보여주는 방식.

CSR 클라이언트 사이드 랜더링

SPA라는 구조를 가장 효율적으로 서비스하기 위해 선택하는 전략이 바로 CSR이다.
서버는 텅 빈 HTML과 JS 파일만 보내주고, 브라우저(클라이언트)가 JS를 실행해 동적으로 DOM을 생성하고 화면을 그리는 방식.
React, Vue
장점:
- 첫 로딩 이후에는 서버 부하가 적음.
- 변경된 데이터만 받아오므로 화면 전환이 매우 빠름.
단점:
- 초기 로딩 속도(TTV)가 느림 (JS 파일이 무거울수록 심화).

SSR 서버 사이드 랜더링

사용자가 요청할 때마다 서버에서 즉석으로 HTML을 생성(렌더링)하여 완성된 페이지를 브라우저에 전달하는 방식.
Thymeleaf, JSP등
장점:
- 초기 로딩 속도가 빠름 (이미 완성된 HTML을 받기 때문).
단점:
- 페이지 이동 시마다 화면 깜빡임(새로고침) 발생.
- 서버가 매번 페이지를 생성해야 하므로 서버 부하가 높음.

(SSR + CSR)

최근 트렌드는 두 방식의 장점만 합치는 것이다. 첫 화면은 서버에서 빠르게 보여주고(SSR), 이후 동작은 부드럽게(CSR) 처리한다.

Next.js: 리액트 기반의 프레임워크지만, SSR과 SSG(Static Site Generation)를 기본으로 지원한다. "SEO가 중요한 리액트 서비스"를 만들 때 필수적인 선택지다.
Nuxt.js: Vue.js 진영에서 Next.js와 같은 역할을 하는 프레임워크다.

Dom 이란?

개념: 웹 페이지(HTML 문서)를 브라우저가 이해할 수 있도록 객체(Object) 형태로 만든 모델.

HTML은 단순한 텍스트 파일일 뿐이야. 자바스크립트(JS)는 텍스트를 직접 수정할 수 없어. 그래서 브라우저가 HTML을 읽어서 "이 버튼은 하나의 객체야", "이 글자는 하나의 속성값이야"라고 자바스크립트가 건드릴 수 있는 형태로 변환해 주는 거야.

Dom의 한계와 문제점

요즘 웹은 한 페이지에서 수만 번의 변화가 일어나. 그런데 DOM의 특정 요소를 하나 바꾸면, 브라우저는 그 변화 때문에 영향받는 다른 요소들의 위치를 다 다시 계산(Reflow)하고 색칠(Repaint)해야 해.

성능 저하: 이 과정이 너무 자주 일어나면 화면이 버벅거리게 돼.
해결책: 그래서 "실제 DOM을 매번 건드리지 말고, 메모리에 가짜 DOM(Virtual DOM)을 만들어서 연습해본 뒤에 한 번에 반영하자!"라는 아이디어가 나온 거지.

Vurtual Dom

실제 DOM의 구조를 자바스크립트 객체 형태로 메모리에 복사해둔 가벼운 복사본이다.

실제 화면에 직접 그리는 것이 아니라, 메모리상에서 먼저 연산을 수행하기 때문에 훨씬 빠르다.

동작 원리 (Diffing & Patching)

변화가 발생했을 때 리액트가 화면을 업데이트하는 3단계 과정이다.

Render: 데이터가 변경되면 전체 UI를 Virtual DOM에 리렌더링한다. (메모리상의 가상 객체만 생성하는 것이라 매우 빠름)
Diffing (비교): 이전의 Virtual DOM 스냅샷과 방금 만든 새로운 Virtual DOM을 비교하여 실제로 바뀐 부분만 찾아낸다.
Reconciliation (재조정/Patching): 바뀐 부분만 실제 DOM에 적용한다.

State 상태값을 내려받아서 사용하기 까지의 과정

먼저 컴포넌트 내부에서 관리할 데이터를 선언해. 리액트의 경우 useState 같은 훅(Hook)을 사용해서 상태의 초기값을 설정. 이 단계에서 메모리상에 해당 상태를 위한 공간이 할당
사용자가 버튼을 클릭하거나 API로부터 데이터를 받아오는 등의 이벤트가 발생하면, 상태를 변경하는 함수(예: setState)를 호출
( 중요한 점은 상태를 직접 수정(state = new)하는 게 아니라, 반드시 제공된 함수를 써야 한다는 것,
그래야 프레임워크가 "상태가 바뀌었으니 화면을 다시 그려야겠구나!"라고 인지할 수 있음)
상태 변경 함수가 호출되면 컴포넌트는 리렌더링(Re-rendering) 단계에 진입
가상 돔 생성: 바뀐 상태값을 반영하여 새로운 가상 돔(Virtual DOM) 트리를 메모리에 새로 생성
디핑(Diffing): 이전 단계에서 가지고 있던 기존 가상 돔과 방금 만든 새로운 가상 돔을 비교
재조정(Reconciliation): 비교 결과, 실제로 바뀐 요소가 무엇인지 찾아냄
계산이 끝나면 바뀐 부분만 실제 브라우저의 DOM에 적용
결과적으로 HTML 템플릿 안에 작성해두었던 변수 자리에 새로운 상태값이 채워지게

면접질문 RestAPI, 웹 기본(통신), 세션 쿠키

myh7754 — Wed, 18 Mar 2026 07:28:55 +0900

너무 오랜만이라 어떤 글을 쓸지 고민이 많았는데...

내가 하는 공부가 매일매일 해도 보여지지 않아서.. 억지로 git에 커밋하지 않는 한 보여지지 않는 게 아쉬워서 다시 조금이라도 꾸준히 써보려고 한다.
우선 요즘 면접 때 들었던 질문에 대한 답, 그리고 기본적인 cs지식을 차근차근 정리해 보려 한다.

우선 면접에서 실제 들었던 면접 질문 그리고 그 답들을 정리해 보려한다.

Rest API란?

-> REST API는

RestFul한 api를 말하며 일련의 특징과 규칙 등을 지키는 api를 일컸는다.

Rest는 웹서버에 있는 자원과 자원의 상태 등을 전송하는 방식을 말한다.

http 같은 프로토콜 위에서 리소스를 uri로 구분하고, get, post, put, delete 등으로 작업을 표시하는 방식

Restful api의 특징

Uniform Interface: HTTP 표준만 따르면 플랫폼에 상관없이 사용 가능한 일관된 인터페이스를 가집니다.
Stateless (무상태성): 서버는 클라이언트의 상태를 저장하지 않습니다. 클라이언트의 요청만으로 모든 처리가 가능해야 하며, 이는 서버의 확장성을 높여줍니다.
Client-Server 구조: 자원을 가진 서버와 요청을 하는 클라이언트가 명확히 분리되어 있어 각각 독립적인 개발과 확장이 가능합니다.
Cacheable (캐시 처리 가능): HTTP의 캐싱 기능을 적용할 수 있어 효율적인 네트워크 사용이 가능합니다.

1-1 Get vs Post차이

Get : 리소스 조회, URL의 쿼리 스트링 명시적 (민감한 정보를 보내기엔 부적절),

멱등성 O 여러번 해도 결과 동일 -> 여러번 조회해도 같은 값이 나옴

Post : 리소스 생성, Http Body 숨켜짐,

멱등성 x -> (카운터 버튼): 누를 때마다 숫자가 1, 2, 3...으로 올라갑니다. 누르는 횟수에 따라 결과가 매번 달라짐

1-2 Put vs Patch차이

Put : 대상 리소스의 전체를 업데이트, 만약 보내지 않은 필드가 있다면, 그 필드는 보통 null이나 기본값으로 덮어씌워짐.

Patch : 리소스의 일부 필드만 변경. 수정하고 싶은 값만 보내면 나머지 데이터는 그대로 유지

1-3 GraphQL

기존 REST API의 한계를 극복하기 위해 만들어졌으며, 핵심은 "클라이언트가 필요한 데이터의 구조를 직접 정의해서 요청 한다."

쿼리언어

사용 이유

REST API로 개발하다 보면 필연적으로 마주치는 두 가지 비효율을 해결

1. Over-fetching (오버페칭) : 사용자 이름만 필요한데 서버는 주소, 전화번호, 이메일까지 다 보냄.

2. Under-fetching (언더페칭) : 내 정보'와 '내가 쓴 댓글'을 보려면 /users/1 호출 후 /comments?user_id=1을 또 호출해야 함 (N+1 문제와 유사한 다중 호출).

해결: 한 번의 쿼리로 유저 정보와 하위 댓글 리스트를 묶어서 가져옴.

REST API vs GraphQL (면접용 비교)

구분	REST API	GraphQL
엔드포인트	자원마다 다름 (/users, /posts)	단 하나 (/graphql)
데이터 결정권	서버가 정한 대로 줌	클라이언트가 원하는 대로 받음
HTTP 상태 코드	200, 404, 500 등 다양하게 활용	대부분 200 OK로 오고, 에러는 Body에 담김
캐싱	HTTP 표준 캐시(브라우저 단) 활용 쉬움	HTTP 캐시 활용이 어려움 (별도 라이브러리 필요)

2. HTTP 에러코드 (400 vs 500)

4xx (Client Error): "요청이 잘못됨"

클라이언트가 보낸 데이터나 주소가 틀렸을 때 발생해. 서버는 정상인데 너(클라이언트)가 고쳐서 다시 보내야 해.
400 (Bad Request): 파라미터 타입이 틀리거나 필수 값이 없을 때.
401 (Unauthorized): 누구인지 모름 (로그인 필요).
403 (Forbidden): 누구인지는 아는데, 이 페이지를 볼 권한이 없음 (일반 유저가 관리자 페이지 접근).
404 (Not Found): 요청한 URL 주소가 잘못됨.

5xx (Server Error): "서버가 터짐"

요청은 잘 왔는데, 서버 로직(Java 코드)에서 에러가 나거나 DB가 죽었을 때 발생해.
500 (Internal Server Error): 가장 흔함. 코드에서 NullPointerException 같은 예외가 터졌을 때.
503 (Service Unavailable): 서버 점검 중이거나 사람이 너무 많이 몰려서 응답 불가.

3. 사용자 식별 (쿠키 vs 세션 vs JWT)

"로그인 유지를 어떻게 하나요?"라는 질문에 대한 핵심 비교야.

구분	쿠키 (Cookie)	세션 (Session)	JWT (Token)
저장 위치	클라이언트(브라우저)	서버 메모리/DB	클라이언트
보안성	낮음 (탈취 쉬움)	높음 (서버가 관리)	중간 (암호화됨)
확장성	높음	낮음 (서버 동기화 필요)	매우 높음 (무상태성)

세션 방식: 서버가 "철수"라는 정보를 메모리에 들고 있고, 철수한테는 "번호표(세션ID)"만 줘. 보안은 좋지만, 서버가 여러 대(Scale-out)가 되면 모든 서버가 철수 정보를 공유해야 해서 복잡해져.
JWT 방식: 아예 철수의 정보를 암호화해서 티켓(Token)으로 만들어줘. 서버는 저장 공간이 필요 없어서 무상태성(Stateless)을 유지하기 좋고, 마이크로서비스(MSA)에서 아주 유리해.

3-1 CSRF 공격

쿠키를 쓰면 왜 위험한가요?라는 꼬리 질문에 대한 답변.

정의: 사용자가 로그인된 상태에서, 공격자가 만든 가짜 사이트를 클릭했을 때 사용자의 의도와 상관없이 서버에 위험한 요청(비밀번호 변경, 송금 등)을 보내는 공격.
왜 가능할까? 브라우저는 해당 사이트로 요청을 보낼 때 쿠키를 자동으로 실어 보내기 때문. (서버는 "철수 쿠키가 왔네? 철수가 보낸 거구나!" 하고 믿어버려.)

대응 방법

CSRF 토큰: 서버가 매번 임의의 토큰을 발행해서, 이 토큰이 없는 요청은 거부하는 방식.
SameSite 설정: 쿠키를 구울 때 SameSite=Strict 옵션을 주면, 다른 사이트에서 보낸 요청에는 쿠키가 포함되지 않는다.

Redis와 사용법

myh7754 — Sun, 29 Jun 2025 14:37:36 +0900

set key value get key // 출력값은 value keys * // 모든 키값의 value 출력 del key // key값 삭제 set key value ex 시간 // ex하고 시간(초)를 넣으면 시간초 후 expired ttl key // 해당key값의 expired 남은 시간 출력 삭제되어있으면 -2 , 시간 제한이 없다면 -1 flushall // 모든 값 삭제

코딩 테스트를 위한 Javascript 문법 정리

myh7754 — Sun, 8 Jun 2025 22:08:19 +0900

코딩 테스트를 위한 JavaScript 문법 정리

원래는 Python으로 코딩 테스트를 준비해왔지만, 이번 기업은 JavaScript만 사용 가능한 상황. 다른 기업들도 특정 언어만 허용하는 경우가 많기 때문에, 이번 기회에 JS로도 코테 문제를 풀 수 있도록 준비해보자.

입력 처리

js
복사편집
const fs = require('fs');
let input = fs.readFileSync('/dev/stdin').toString().trim().split(' ');

예시 입력

csharp
복사편집
string 5

input 값:

js
복사편집
['string', '5']

split(' '): 공백 기준 분리
문자열 → 숫자 변환 필요 시 Number(input[1]) 등으로 처리

문자열 처리

✅ 문자열 반복

js
복사편집
"abc".repeat(3);  // "abcabcabc"

✅ 문자열 슬라이싱

js
복사편집
const str = "HelloWorld";
str.slice(0, 5);  // "Hello"
str.slice(5);     // "World"
str.slice(2, 7);  // "lloWo"

✅ 대소문자 처리

js
복사편집
let s = "Hello World";

s.toLowerCase(); // "hello world"
s.toUpperCase(); // "HELLO WORLD"

// 대소문자 반전
let swapped = "";
for (let ch of s) {
  swapped += (ch === ch.toLowerCase()) ? ch.toUpperCase() : ch.toLowerCase();
}
// 결과: "hELLO wORLD"

반복문

✅ 기본 for문

js
복사편집
for (let i = 0; i < 5; i++) {
  console.log(i);  // 0 1 2 3 4
}

✅ forEach

js
복사편집
arr.forEach((value, index, array) => {
  // value: 요소 값
  // index: 요소 인덱스
  // array: 원본 배열
});

✅ for-of

js
복사편집
let arr = ['a', 'b', 'c'];
for (let value of arr) {
  console.log(value);  // a b c
}

정렬

✅ 문자열 정렬

js
복사편집
let arr = ['banana', 'apple', 'cherry'];
arr.sort();
// 결과: ['apple', 'banana', 'cherry']

✅ 숫자 정렬

기본 sort()는 문자열 기준이라 숫자를 정렬하려면 비교 함수를 써야 함.

js
복사편집
let nums = [10, 2, 33, 25];
nums.sort((a, b) => a - b);  // 오름차순
// 결과: [2, 10, 25, 33]

자바스크립트 자료구조

배열 (Array)

js
복사편집
let arr = [1, 2, 3, 4, 5];

메서드	설명	예시	결과
push()	뒤에 요소 추가	arr.push(6)	[1,2,3,4,5,6]
pop()	뒤에서 요소 제거	arr.pop()	[1,2,3,4], 반환값 5
shift()	앞에서 요소 제거	arr.shift()	[2,3,4,5], 반환값 1
unshift()	앞에 요소 추가	arr.unshift(0)	[0,1,2,3,4,5]
slice(start, end)	잘라내기 (원본 보존)	arr.slice(1, 3)	[2,3]
splice(start, deleteCount, ...items)	배열 중간 삭제/추가 (원본 변경)	arr.splice(2, 1, 9)	[1,2,9,4,5]즉, 인덱스 2의 값 1개를 지우고 그 자리에 9를 넣음
sort((a,b)=>a-b)	정렬 (숫자는 비교 함수 필수)	arr.sort((a,b)=>a-b)	[1,2,3,4,5]
reverse()	배열 뒤집기	arr.reverse()	[5,4,3,2,1]
map()	요소 변형	arr.map(x => x * 2)	[2,4,6,8,10]
filter()	조건 필터링	arr.filter(x => x % 2 === 0)	[2,4]
reduce()	누적 합 등	arr.reduce((a, b) => a + b, 0)	15 ← 파이썬의 sum()

집합 (Set)

js
복사편집
let s = new Set([1, 2, 3]);

메서드	설명	예시	결과
add(val)	값 추가	s.add(4)	Set {1,2,3,4}
delete(val)	값 삭제	s.delete(2)	true, Set: {1,3}
has(val)	값 존재 여부	s.has(3)	true
size	요소 개수	s.size	3
Array.from(set)	배열로 변환	Array.from(s)	[1,2,3]

맵 (Map) - 파이썬의 딕셔너리

js
복사편집
let m = new Map();
m.set('a', 1);
m.set('b', 2);

메서드	설명	예시	결과
set(key, val)	값 저장	m.set('c', 3)	Map {'a' => 1, 'b' => 2, 'c' => 3}
get(key)	값 얻기	m.get('a')	1
has(key)	키 존재 확인	m.has('b')	true
delete(key)	키 삭제	m.delete('b')	true
size	요소 개수	m.size	2
Object.fromEntries(m)	객체로 변환	{ a: 1, c: 3 }

객체 (Object) - 파이썬 dict 역할

Map과의 차이점은 객체는 반드시 키값이 문자열이다.

js
복사편집
let obj = { a: 1, b: 2 };

메서드	설명	예시	결과
obj['a']	값 접근	obj['a']	1
obj['c'] = 3	값 추가	{a:1, b:2, c:3}
delete obj['b']	키 삭제	{a:1}
Object.keys(obj)	키 배열	['a', 'b']
Object.values(obj)	값 배열	[1, 2]
Object.entries(obj)	[key, val] 쌍 배열	[ ['a', 1], ['b', 2] ]

슬라이딩 윈도우

js
복사편집
let arr = [1, 2, 3, 4, 5];
let k = 3;
let maxSum = 0;
for (let i = 0; i <= arr.length - k; i++) {
    let window = arr.slice(i, i + k);
    let sum = window.reduce((a, b) => a + b, 0);
    maxSum = Math.max(maxSum, sum);
}
console.log(maxSum); // 12

조합, 순열

조합과 순열은 기본 문법에 없으므로 함수로 구현해야 합니다.

js
복사편집
function combinations(arr, r) {
    if (r === 0) return [[]];
    if (arr.length < r) return [];
    const [head, ...rest] = arr;
    const withHead = combinations(rest, r - 1).map(c => [head, ...c]);
    const withoutHead = combinations(rest, r);
    return withHead.concat(withoutHead);
}
combinations([1,2,3], 2); // [[1,2],[1,3],[2,3]]

덱 (Deque)

JS에는 내장 Deque가 없지만 배열로 구현 가능.

js
복사편집
let deque = [];
deque.push(1);        // 오른쪽 추가
deque.unshift(2);     // 왼쪽 추가
deque.pop();          // 오른쪽 제거
deque.shift();        // 왼쪽 제거

Json과 Object의 차이, Java에서 Json객체 사용법

myh7754 — Mon, 9 Dec 2024 01:48:53 +0900

Object와 Json객체의 차이

json은 데이터를 저장하거나 전송하기위한 텍스트 기반의 데이터 포맷이다.

json은 key값과 value로 이루어져 있다.

obejct 객체는 프로그램에서 데이터를 조작하거나 관리하기 위한 자료구조 이다.

즉 자바스크립트에서 http의 통신수단으로 사용되는 것은 Js의 Object가 아니라 Json형식으로 클라이언트와 데이터를 주고 받는 다는 것이다.

자바 스크립트에서 JSON 객체를 다루는법

JSON.parse() : json을 js object로 파싱하기 위해서 메서드를 사용

JSON.stringify() : Js Object를 JSON으로 변환해주기 위해 필요한 것.

json

{
  "name": "Alice",
  "age": 25,
  "isStudent": true
}

object로 파싱

const jsonString = '{"name": "Alice", "age": 25, "isStudent": true}';
const obj = JSON.parse(jsonString);

console.log(obj.name); // "Alice"
console.log(obj.age);  // 25

JavaScript 객체

const obj = {
  name: "Alice",
  age: 25,
  isStudent: true
};

json으로 변환

const obj = { name: "Alice", age: 25, isStudent: true };
const jsonString = JSON.stringify(obj);

console.log(jsonString); // '{"name":"Alice","age":25,"isStudent":true}'

Java에서 Json 객체 다루기

java에서는 Jackson 라이브러리를 이용하여 json 객체를 파싱하여 사용한다.

의존성 추가 (Gradle)

implementation 'com.fasterxml.jackson.core:jackson-databind:2.15.2'

JSON → Java 변환

class Person {
	private String name;
	private int age;
	
	getter setter등등
}

public static void main(String[] args) throws Exception {
        String jsonString = "{\\"name\\":\\"Alice\\",\\"age\\":25,\\"isStudent\\":true}";

        // ObjectMapper를 이용해 JSON 문자열을 Java 객체로 변환
        ObjectMapper mapper = new ObjectMapper();
        Person person = new Person();
        person.setName("Alice");
        person.setAge(25);

        // 변환된 객체 출력
        System.out.println(person.getName()); // Alice
        System.out.println(person.getAge());  // 25

        // Java 객체를 JSON 문자열로 변환
        jsonString = mapper.writeValueAsString(person);
        System.out.println(jsonString); // {"name":"Alice","age":25,"isStudent":true}
    }

OAuth2.0 google, kakao, naver

myh7754 — Mon, 2 Dec 2024 23:57:29 +0900

OAuth2.0

사용자의 인증 및 권한을 부여하기 위한 프로토콜이다.

다양한 서비스에서 로그인할 때 사용 된다. → 카카오, 네이버, 구글로 로그인하기 와 같은 기능을 구현하는 방식이다.

출처 : https://blog.naver.com/mds_datasecurity/222182943542

https://developers.kakao.com/docs/latest/ko/kakaologin/rest-api

다음은 일반적인 oauth2.0과 카카오의 oauth2.0의 동작 방식을 정의해 놓은 시퀀스 다이어그램이다.

대부분의 oauth2.0은 위와 비슷한 방식으로 처리 된다.

client

구글이나 카카오를 통해 로그인하려는 앱 → 사용자가 사용하는 기기

Resource Owner(리소스 소유자)

자원을 소유하는 사용자(로그인을 하는 사용자) → 사용자의 구글 이메일이나, 사진 등의 권한을 허용할 수 있음.

Authorization Server(인증서버)

클라이언트에게 인증을 제공하고 엑세스 토큰을 발급하는 서버이다.

Resource Server(리소스 서버)

리소스 소유자의 데이터를 실제로 보관하는 서버.

Access Token

client가 인증받은 후 리소스 서버에 접근할 수 있도록 발급되는 토큰
이 토큰을 이용하여 리소스 서버에서 개인정보를 받을 수 있다.
만료기간이 짧음

Refresh Token

access token의 유효 기간이 만료된 후 새로운 access token을 얻기 위해 사용하는 토큰
만료기간이 Access Token에 비해 김

Spring에서 google, kakao, naver oauth2.0설정

스프링의 resource의 yml 파일 설정은 다음과 같이하고 client id와 sceret에 각 사이트의 develop에서 발급받은 id 비밀번호를 넣으면 된다.

spring:
  security:
    oauth2:
      client:
        registration:
          google:
            client-id: YOUR_GOOGLE_CLIENT_ID
            client-secret: YOUR_GOOGLE_CLIENT_SECRET
            scope: profile, email
            redirect-uri: "{baseUrl}/login/oauth2/code/google"
            client-name: Google
          naver:
            client-id: YOUR_NAVER_CLIENT_ID
            client-secret: YOUR_NAVER_CLIENT_SECRET
            scope: name, email
            redirect-uri: "{baseUrl}/login/oauth2/code/naver"
            client-name: Naver
            provider: naver
          kakao:
            client-id: YOUR_KAKAO_CLIENT_ID
            client-secret: YOUR_KAKAO_CLIENT_SECRET
            scope: profile_nickname, account_email
            redirect-uri: "{baseUrl}/login/oauth2/code/kakao"
            client-name: Kakao
            provider: kakao
        provider:
          kakao:
            authorization-uri: <https://kauth.kakao.com/oauth/authorize>
            token-uri: <https://kauth.kakao.com/oauth/token>
            user-info-uri: <https://kapi.kakao.com/v2/user/me>
            user-name-attribute: id
          naver:
            authorization-uri: <https://nid.naver.com/oauth2.0/authorize>
            token-uri: <https://nid.naver.com/oauth2.0/token>
            user-info-uri: <https://openapi.naver.com/v1/nid/me>
            user-name-attribute: response

package com.est.oauth2.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .csrf(csrf -> csrf.disable())
                .formLogin(form -> form.disable())
                .oauth2Login(Customizer.withDefaults()) // oauth2.0로그인 방식
                .authorizeHttpRequests(
                        auth -> auth.requestMatchers("/login")
                                    .anonymous()
                                .requestMatchers("/user/**")
                                    .hasAnyAuthority("USER")
                                .requestMatchers("/admin/**")
                                    .hasAnyAuthority("ADMIN")
                                .anyRequest()
                                    .authenticated()
                )
                .build();
    }

}

설정을 마친 뒤 다음과 같이 OAuth2User 객체를 사용하여 정보를 사용할 수 있다.

@Controller
public class HomeController {

    @GetMapping("/home")
    public String home(@AuthenticationPrincipal OAuth2User oAuth2User, Model model) {
        model.addAttribute("name", oAuth2User.getAttribute("name")); // 사용자 이름
        model.addAttribute("email", oAuth2User.getAttribute("email")); // 이메일
        return "home"; // home.html
    }
}

JavaScrpit Event, 동기, 비동기 통신

myh7754 — Mon, 2 Dec 2024 17:22:54 +0900

JS

var : 값을 다시 초기화 하는게 가능

호이스팅 : 선언이 스코프 최상단으로 끌어 올려지는 현상(초기화는 나중에 됨, undefined로 초기화)

ex)

var a = 10;

var a = 40;

a = 40이 들어감

hoisting

console.log(a); // undefined (호이스팅)
var a = 10;

가능하면 let을 사용하는게 좋음

let : 값을 초기화 다시 초기화하는게 불가 재할당은 가능 → 일반 변수같은 느낌

ex)

let b =30;

let b = 40; → 이렇게 다시 선언하여 초기화는 불가능

b = 40; → 이렇게 재할당은 가능

const : 상수 재할당은 안됨

undefiend : 변수는 선언되어 있지만 값이 정의 되지 않았다는 상태를 나타내줌 → 시스템이 자동으로 부여

let value;
console.log(value);  // undefined

null : 의도적으로 값이 비어있다는 것을 개발자가 명시적으로 나타낼 때 사용하는 값 → 개발자가 명시

let value = null;
console.log(value);  // null

NaN : 숫자가 아닌값을 연산에 사용했을 때 발생하는 값들 → 숫자가 아닌 값. type이 “number”로 반환됨

console.log(parseInt("Hello"));  // NaN

자기 자신과 같지 않다

console.log(NaN === NaN);  // false
console.log(isNaN(NaN));   // true

자바스크립트는

==비교를 타입캐스팅 자동으로 하기때문에

5 == ‘5’가 같은 true로 나온다 그래서 ===비교를 해야함

5 === ‘5’ 이렇게 해야 false가 나옴 타입까지 동일해야 true

자바스크립트는 변수에 함수를 할당하여 사용가능

const hello = funciton() { console.log("hello world"); }; 
hello(); // 이런식으로 사용 가능

function greet() {
	return funciton() {
		console.log("hello world");
	}
}
const hello = greet();
hello(); // hello world 출력

클로저

함수와 그 함수가 선언될 때의 스코프를 기억하는 기능
→ 예를 들어 자바에서 함수를 호출하면 스코프가 그 안에서만 적용 되지만 자바스크립트는 밖에서도 함수가 살아있어서 아래와 같이 count가 유지됨
클로저를 통해 함수는 자신의 외부 함수의 변수에 접근할 수 있고, 이 변수들은 함수가 실행된 후에도 유지된다.

function createCounter() {
    let count = 0;
    return function() {
        count += 1;
        return count;
    };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2 count가 계속 살아있음

객체

키-값의 집합으로 이루어져 아래와 같이 사용 가능하다. 이것은 JSON형태라고함

const myObj = { // JSON 형태 KEY: VALUE
	username: "user1",
	password: "1234",
	level: 50,
	isAdmin: false
}

console.log(myObj.username); // user1
console.log(myObj.isAdmin); // false

const userLevel = myObj.level;
console.log(userLevel + 100); // 150

Event

브라우저에서 사용자가 버튼을 클릭, 키보드를 누르거나 페이지가 로드되는 것을 이벤트라 부른다.

mouse 이벤트

click : 요소를 클릭할 때 발생

dblclick : 더블 클릭할 때

mouseover : 마우스가 요소 위로 올라갈 때

mouseout : 마우스가 요소를 벗어날 때

키보드 이벤트

keydown : 키를 누를 때

keyup : 키를 뗄 때

폼 이벤트

submit : 폼이 제출될 때

change : 입력 값이 변경될 때

등등 이 있다.

이벤트 리스너

특정 이벤트가 발생했을 때 실행되는 함수를 연결하는 메서드이다.

js에 내장되어 있는 객체인 document를 이용하여 사용한다.

브라우저는 html문서를 파싱하여 DOM이라는 구조를 만드는데 document는 이 DOM에 접근할 수 있도록 도와주는 객체이다.

document.getElementById(" " ).addEventListener("이벤트", ()=> { 실행메서드});

document.getElementById(" ").removeEventListener("이벤트", ()=> {실행메서드}); : 실행 메서드를 실행하고 해당 리스너를 제거한다.

다음과 같이 html과 Event를 이용하여 사용할 수 있다

mouse

<div id="mouseBox">마우스 이벤트 테스트</div>
<button id="mouseButton">클릭하세요</button>

// 클릭 이벤트
document.getElementById("mouseButton").addEventListener("click", () => {
  alert("버튼이 클릭되었습니다!");
});
const mouseBox = document.getElementById("mouseBox");

mouseBox.addEventListener("mouseover", () => {
  mouseBox.textContent = "마우스가 올라왔습니다!";
});

mouseBox.addEventListener("mouseout", () => {
  mouseBox.textContent = "마우스가 벗어났습니다!";
});

keyboard

<input id="keyboardInput" type="text" placeholder="키보드를 입력하세요" />
<p id="keyResult"></p>

const input = document.getElementById("keyboardInput");
const keyResult = document.getElementById("keyResult");

// 키가 눌렸을 때 (keydown) 값이 event변수에 전달
input.addEventListener("keydown", (event) => {
  keyResult.textContent = `눌린 키: ${event.key}`;
});

// 키가 떼어졌을 때 (keyup)
input.addEventListener("keyup", () => {
  keyResult.textContent = "키를 뗐습니다.";
});

form

<form id="formTest">
  <label for="formInput">이름:</label>
  <input id="formInput" type="text" placeholder="이름을 입력하세요" />
  <button type="submit">제출</button>
</form>
<p id="formMessage"></p>

const form = document.getElementById("formTest");
const formMessage = document.getElementById("formMessage");

// 제출 이벤트
form.addEventListener("submit", (event) => {
  event.preventDefault(); // 기본 동작 방지
  formMessage.textContent = "폼이 제출되었습니다!";
});

// 값 변경 이벤트
const formInput = document.getElementById("formInput");
formInput.addEventListener("change", () => {
  formMessage.textContent = `입력 값이 변경되었습니다: ${formInput.value}`;
});

DOM(Document Object Model)

웹 페이지의 문서 구조를 객체 모델로 표현한 것

getElementById("Id") : id값으로 html내의 요소를 가져오는 함수

document.getElementsByClassName("클래스이름") : 클래스 이름으로 요소를 가져오는 함수

document.querySelector('css선택자') : 선택자를 이용하여 요소를 가져오는 함수

동기통신

컴퓨터 프로세스에서 하나의 작업이 완료가 될 때 까지 작업을 기다렸다가 모든 작업을 순차적으로 처리하는 방식을 말한다.
장점은 단순하고 작은 규모 시스템에서 유리하게 작용할 수 있다.

비동기 통신

동기 통신과 반대로 서로 서로를 기다리지 않고 독립적으로 진행되는 방식이다.
문서의 각 요소를 객체로 나타내며, 이 객체를 통해 문서의 내용, 구조, 스타일 등을 동적으로 수정하고 접근할 수 있다

Fetch API

http요청을 비동기 방식으로 처리하여 도와주는 인터페이스

Promise

fetch API는 http 요청을 비동기적으로 수행하기 위해 Promise 객체를 사용한다.
Promise는 비동기 작업이 완료되었을 때의 결과를 나타내는 객체.
fetch가 반환하는 Promise 객체는 네트워크 요청의 상태를 관리하고, 요청이 완료된 후 응답을 처리하는 방법을 제공

Promise는 3가지 주요 상태를 가진다 대기(Pending), 이행(Fulfilled), 거부(Rejected)

Pending상태에서 Fulfilled나 Rejected상태가 될 수 있지만 반대는 안된다. 즉 Fulfilled가 된 상태에서 Pending이 되지 못함

대기(Pending)

Promise가 생성된 초기 상태, 비동기 작업이 아직 완료되지 않았거나 결과가 아직 확정되지 않은 상태

이행(Fulfilled)

비동기 작업이 성공적으로 완료되어, Promise가 결과값을 가진 상태
이 상태로 변경되면, then() 메서드에 전달된 성공 콜백 함수가 호출된다.
결과값이 Promise 객체에 저장, Promise는 이 상태에 도달하면 더 이상 상태가 변경되지 않는다.

거부(Rejected)

비동기 작업이 실패하거나 에러가 발생하여, Promise가 실패 상태를 나타내는 상태.
catch() 메서드에 전달된 에러 처리 콜백 함수가 호출
에러 정보가 Promise 객체에 저장되고, Promise는 이 상태에 도달하면 더 이상 상태가 변경되지 않는다.

fetch(url, 옵션)
  .then(onFulfilled => { ... }) // 성공시
  .catch(onRejected => { ... }); // 실해시

fetch()의 인자로는 요청을 보낼 url , 메타데이터(Option)을 부여한다.

옵션은 객체 형식으로부여 가능하고 요청의 **본문(body)**부분은 일반적으로 **JSON.stingify()**를 이용하여 객체를 문자열화 하여 포함시킨다.

fetch(url, 옵션)

위의 옵션 값

{
	method: HTTP 메서드,
	headers: {
		헤더 키: 헤더 값,
	},
	body: JSON.stringify(본문 값),
	[credentials: 쿠키 및 인증정보 포함 여부]
}

[오르미 백엔드7기] (Spring Security , Cors,CSRF)

myh7754 — Fri, 29 Nov 2024 01:33:22 +0900

Spring Seucirty

Spring 웹 애플리케이션에서 인증 과 인가를 관리하는 보안 프레임워크이다.

Filter

인증 토큰을 검증하여 사용자 신원을 확인.

톰켓에서 dispatcher servlet으로 전달하기 전에 실행
요청과 응답에 대해 특정 작업을 수행 후 원래 요청을 서블릿이나 리소스로 전달하는 역할.
인증, 로깅, 보안 검사 등에 사용된다.

예시 : JWT 토큰 파싱 및 검증.

FilterChainProxy: Spring Security에서 필터 체인을 관리하는 클래스

SecurityFilterChain 인터페이스를 통해 요청을 필터링할 필터 목록을 제공.
Servlet의 기본 Filter 인터페이스를 기반으로 동작.

Interceptor

요청한 사용자의 권한(Role)을 검증하여 특정 리소스 접근 제한.

DisPatcher Servlet 에서 컨트롤러로 전달하기 전에 실행
핸들러 매핑 이후 컨트롤러에 접근하기 전에 인증/인가 처리 가능
주로 요청 데이터 검사나 로직 검증에 활용된다.

예시 : 관리자만 접근 가능한 URL 제어.

인증

사용자 또는 시스템의 신원을 확인하는 과정.

사용자가 자신이 주장하는 신원, 즉 자신이 실제로 누구인지를 증명하도록 요구하는 과정이다.

Spring Security에서 인증 과정은 사용자가 제공하는 자격 증명, 보통 사용자 이름과 비밀번호를 기반으로 이루어진다.

Spring Security는 다양한 인증 방식(폼 로그인, OAuth2, JWT 등)을 지원.

인가

인증된 사용자가 특정 자원에 접근할 권한이 있는지를 결정 URL 기반 접근 제어, 메소드 수준 보안, 역할(Role) 기반 권한 부여 등을 통해 세부적인 권한 관리 가능.

SecurityContextHolder

인증 정보를 저장하고 접근하는 클래스 현재 요청의 SecurityContext를 관리하여 인증된 사용자 정보를 저장.

SecurityContext는 또한 인증(Authentication) 정보를 담고 있는 인터페이스이다. SecurityContext는 인증 정보를 Authentication 객체로서 저장하고, Authentication 객체는 사용자의 인증 상태와 권한 정보를 담고 있으며, 이를 통해 사용자가 어떤 권한을 가지고 있는지, 그리고 현재 인증된 사용자에 대한 세부 정보를 알 수 있게 되는 것

ex) SecurityContextHolder.getContext().getAuthentication()을 통해 인증 정보에 접근 가능.

SecurityContext

SecurityContext는 현재 인증된 사용자의 정보를 담고 있는 인터페이스.
사용자가 어플리케이션에 로그인하면, 해당 사용자의 인증 정보가 Authentication 객체로 생성되고, 이 객체는 SecurityContext에 저장
이후 애플리케이션의 어디에서든 SecurityContext를 통해 현재 사용자의 인증 정보에 접근할 수 있다.
인증 상태와 권한 정보를 기반으로 보안 결정을 내리는 데 사용.

Authentication

사용자의 인증 및 권한 정보를 표현하는 인터페이스
주요 구성 요소:
- Principal: 사용자의 식별자를 의미. → UserDetail or 사용자명을 나타내는 String 등.
- Credentials: 인증 자격(예: 비밀번호).
- Authorities: getAuthorities() 메서드를 통해 접근할 수 있으며, 사용자가 가지고 있는 권한(또는 역할)의 목록을 제공. 이 권한들은 GrantedAuthority 인터페이스의 구현체로 표현
- Authenticated: isAuthenticated() 메서드를 통해 현재 사용자가 인증되었는지 여부를 반환. 인증이 성공적으로 이루어진 경우, 이 값은 true

UserDetails

사용자 정보를 캡슐화하는 인터페이스.
커스텀 구현 시 사용자 이름, 비밀번호, 권한, 계정 상태(활성화, 잠김 여부 등)를 정의.
Spring Security는 이를 통해 인증 가능한 사용자 정보를 관리.

어플리케이션에서 추가적인 사용자 정보를 관리하거나 특수한 로직이 필요한 경우, UserDetails 인터페이스를 구현하여 커스텀할 수 있다.

커스텀 할 때 기본적으로 오버라이드 해야하는 메소드는 다음과 같다.

< 표 1 > UserDetails 메서드

메소드 반환 타입 설명 기본값

getAuthorities()	Collection<? extends GrantedAuthority>	사용자 권한 목록을 반환
getPassword()	String	사용자 비밀번호를 반환
getUsername()	String	사용자 고유한 값을 반환
isAccountNonExpired()	boolean	계정의 만료 여부 반환	true ( 만료 안됨 )
isAccountNonLocked()	boolean	계정의 잠김 여부 반환	true ( 잠기지 않음 )
isCredentialsNonExpired()	boolean	비밀번호 만료 여부 반환	true ( 만료 안됨 )
isEnabled()	boolean	계정의 활성화 여부 반환	true ( 활성화 됨 )

import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.userdetails.UserDetails;

import java.util.Collection;

public class CustomUserDetails implements UserDetails {
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return null;
    }

    @Override
    public String getPassword() {
        return null;
    }

    @Override
    public String getUsername() {
        return null;
    }

    @Override
    public boolean isAccountNonExpired() {
        return UserDetails.super.isAccountNonExpired();
    }

    @Override
    public boolean isAccountNonLocked() {
        return UserDetails.super.isAccountNonLocked();
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return UserDetails.super.isCredentialsNonExpired();
    }

    @Override
    public boolean isEnabled() {
        return UserDetails.super.isEnabled();
    }
}

UserDetailsService

UserDetailsService는 사용자명(username)을 기반으로 UserDetails 객체를 로드하는 역할

사용자 인증 과정에서 필요한 사용자 정보를 데이터베이스나 다른 저장소에서 가져오는 데 사용된다.

메소드 반환 타입 설명

loadUserByUsername()

UserDetails

유저의 정보를 불러와서 UserDetails로 반환

import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.core.userdetails.UsernameNotFoundException;

public class CustomUserDetailService implements UserDetailsService {
    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return null;
    }
}

Security Config

어플리케이션의 보안 정책을 종합적으로 정의하고 관리하는 중심적 구성 요소

Spring Security를 활용하는 애플리케이션에서 반드시 필요하며 다음과 같은 설정을 할 수 있다.

인증(Authentication) 관리
SecurityConfig는 사용자 인증을 위한 설정을 담당한다. - 사용자 정보의 출처를 정의하는 UserDetailsService, 비밀번호 암호화 방식, 인증 요청 처리 방식을 설정하는 작업이 포함된다
이 과정에서 개발자는 데이터베이스, LDAP, OAuth2 등 다양한 인증 방법을 선택하고 구현할 수 있다.
권한 부여(Authorization) 관리 사용자가 애플리케이션 내의 자원에 접근할 수 있는지 여부를 결정하는 과정 URL 기반 접근 제어와 메소드 기반 접근 제어를 설정하여, 특정 역할(Role)이나 권한(Authority)을 가진 사용자만이 특정 자원에 접근할 수 있도록 보장한다. 이를 통해 민감한 정보나 기능에 대한 비인가 접근을 방지
HTTP 보안 설정 CSRF보호 , 세션 관리 등 웹 애플리케이션의 보안과 관련된 다양한 HTTP 설정을 제공
커스터마이징과 확장 개발자는 자신만의 인증 방식이나 필터를 추가하거나, 기존의 보안 흐름을 재정의하여 애플리케이션의 보안 모델을 더욱 견고하게 만들 수 있다.

Form

form 로그인 방식은 사용자가 로그인 정보를 제공하여 이를 바탕으로 사용자의 신원을 확인하여 인증하는 방식이다. 주로 POST 요청을 통해 서버로 전송된 사용자 입력값을 서버에서 처리하게 된다. Spring Security는 이러한 로그인 폼을 매우 쉽게 설정하고 관리할 수 있는 기능을 제공.

과정은 다음과 같다

사용자가 아이디 비밀번호 입력
http요청을 통해 전달받아 Spring security는 요청을 UsernamePasswordAuthenticationFilter를 통해 처리.

// 내일 예제코드 보고 수정
protected void configure(HttpSecurity http) throws Exception {
    http
        .formLogin() // Form 기반 로그인 활성화
        .loginPage("/login") // 커스텀 로그인 페이지 URL
        .defaultSuccessUrl("/home", true) // 로그인 성공 시 이동할 URL
        .permitAll() // 모든 사용자 접근 허용
        .and()
        .logout() // 로그아웃 설정
        .logoutSuccessUrl("/login?logout") // 로그아웃 성공 후 이동할 URL
        .permitAll();
}

UsernamePasswordAuthenticationFilter 처리:
- 입력값을 UsernamePasswordAuthenticationToken 객체로 변환.
- 이 객체는 인증되지 않은 상태로 생성됩니다.
AuthenticationManager로 인증 요청 전달
- 여러 AuthenticationProvider를 순회하여 적합한 인증 제공자가 있는지 확인.
- 보통 DaoAuthenticationProvider가 UserDetailsService를 통해 사용자 정보를 조회.
비밀번호 검증

PasswordEncoder를 사용하여 입력된 비밀번호와 저장된 암호화된 비밀번호를 비교.
일치하면 인증 성공.

@Bean
public AuthenticationManager authManager(HttpSecurity http) throws Exception {
    return http.getSharedObject(AuthenticationManagerBuilder.class)
            .userDetailsService(customUserDetailsService) // 사용자 정보 조회 서비스
            .passwordEncoder(passwordEncoder()) // 비밀번호 인코딩
            .and()
            .build();
}

Granted Authority 객체를 이용해 인가를 저장

인가 : 인증의 마지막 프로세스에서 관리되는 것

인코딩 , 디코딩

인코딩

주로 비밀번호를 안전하게 처리하는데 사용된다.
사용자로 부터 입력받은 비밀번호를 주로 해시함수를 사용하여 변환한 후 사용하는 방식이다.
인코딩은 단방향으로 암호화하여 db 유출 시에도 사용자의 비밀번호가 보호되도록 한다.
Spring Security는 여러 인코딩 알고리즘을 제공하는데 대표적으로 BCryptPasswordEncoder가 사용됨. → 이 알고리즘은 해시화하고 추가적으로 Salt를 적용하여 같은 비밀번호라도 다른 해시값을 생성하도록 한다. 저장하는 시점에 매번 다른 Salt가 생겨 Salt도 함께 저장되는 것 디코딩할 때는 저장된 Salt도 가져와서 해시화 하여 인증. 디코딩할때도 Salt로 다른 해시값으로 인증하는게 아님.

디코딩

데이터를 원래 상태로 복원하기보다는 주로 검증하는 역할을 수행한다.
사용자가 입력한 비밀번호를 저장된 인코딩된 비밀번호와 비교하여 해시값과 일치하는지 확인하여 인증한다.

세션

세션은 서버가 관리하는 사용자의 정보이다 : 사용자의 로그인상태를 유지중
서버측에서 세션이 생성될 때 만들어진 세션ID로 식별한다.
사용자 정보는 서버에 저장되고, 브라우저에는 세션ID만 있음.
세션은 일정 시간 동안만 유지됨(ex 30분). 시간이 지나면 만료되 로그아웃 처리

쿠키

쿠키는 HTTP 프로토콜의 stateless(상태 비저장) 특성을 보완하기 위한 기술.
클라이언트(브라우저)가 관리하는 정보이다. ex) 사용자의 다크모드 설정, 선호 설정, 로그인 정보
쿠키가 탈취되거나 변조되면 보안 문제가 생길 수 있음. 이를 막기 위해 httpOnly, Secure 과 같은 옵션을 사용

Security의 Thymeleaf

Spring Security와 Thymeleaf는 HTML 템플릿에서 인증 및 권한을 쉽게 처리할 수 있도록 돕는 속성을 제공한다.

sec:authorize

특정 권한에 따라 콘텐츠를 표시하거나 숨김.
예: sec:authorize="isAuthenticated()" → 로그인한 사용자만 볼 수 있음.

조건 설명

isAnonymous()	비로그인 사용자에게만 콘텐츠 표시
isAuthenticated()	로그인된 사용자에게만 콘텐츠 표시
hasRole('ROLE_NAME')	특정 권한을 가진 사용자만 콘텐츠 표시
hasAnyRole('ROLE1', 'ROLE2')	여러 권한 중 하나를 가진 사용자에게 콘텐츠 표시
permitAll	모든 사용자에게 콘텐츠 표시
denyAll	누구에게도 콘텐츠 표시하지 않음

sec:authentication
- 인증된 사용자 정보를 템플릿에서 가져온다.
속성 설명

principal 인증된 사용자의 객체

principal.name 인증된 사용자의 사용자명

principal.authorities 인증된 사용자의 권한 목록

1. sec:authorize 예시

HTML 템플릿에서 사용자 권한에 따라 콘텐츠를 표시

<!-- 로그인된 사용자만 보기 -->
<div sec:authorize="isAuthenticated()">
    안녕하세요, <span sec:authentication="name"></span>님!
</div>

<!-- 관리자만 접근 가능 -->
<a href="/admin" sec:authorize="hasRole('ADMIN')">관리자 페이지</a>

<!-- 비로그인 사용자만 보기 -->
<div sec:authorize="isAnonymous()">
    <a href="/login">로그인</a>
    <a href="/signup">회원가입</a>
</div>

<!-- 모든 사용자에게 콘텐츠 노출 -->
<div sec:authorize="permitAll">
    모든 사용자가 볼 수 있는 공지사항입니다.
</div>

2. sec:authentication 예시

템플릿에서 로그인된 사용자 정보를 출력.

<!-- 사용자 정보 출력 -->
<p>현재 사용자: <span sec:authentication="name"></span></p>

<!-- 사용자 권한 출력 -->
<p>권한: <span sec:authentication="principal.authorities"></span></p>

CSRF 공격

(Cross-Site Request Forgery) 로그인 되어 있는 인증정보를 가지고 공격하는 것 (쿠키, 세션으로 자주 발생)

공격자가 사용자의 인증 정보를 이용해 악의적인 요청을 보내는 방식으로 이루어진다.

CSRF 공격을 방지하기 위한 주요 방법 중 하나는 CSRF 토큰을 사용하는 것이다.

Spring Security에서 CSRF의 설정

Spring Security를 사용하면 기본적으로 CSRF 보호가 활성화 된다.

@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) // CSRF 토큰을 쿠키에 저장
            )
            .authorizeHttpRequests(auth -> auth
                .anyRequest().authenticated() // 모든 요청 인증 필요
            );

        return http.build();
    }
}

CORS

Cors(Cross-Origin Resource Sharing)는 원하지 않는 출처에서 서버 리소스가 무단으로 접근되는 것을 방지하기 위한 보안 장치이다. 보안상의 이유로 기본적으로 다른 출처의 리소스에 대한 요청을 차단하는데 이 때문에 다음과 같은 문제가 발생한다. CORS 문제는 일반적으로 클라이언트와 서버가 다른 출처에 있을 때 발생한다. Cors는 두가지 주요 요청 유형을 관리한다.

첫번째로 단순 요청 get,post,head와 같은 제한된 헤더를 사용하는 요청으로 Access-Control-Allow-Origin헤더만 포함하여 응답하면 된다.
두번째는 프리 플라이트요청(preflight requests)은 OPTIONS 메서드를 사용하여 서버의 정책을 사전에 확인하는 요청으로 요청의 유효성을 검증해 응답한다.

예시 :

프론트엔드: http://localhost:3000
백엔드: http://localhost:8080

이런 경우:

클라이언트가 API 요청을 보내면 브라우저는 CORS 정책을 확인.
서버가 해당 요청을 허용하지 않는다면, 브라우저는 요청을 차단하고 CORS 오류를 발생시킨다.

해결 방법은 클라이언트가 다른 출처에서 오는 요청을 처리할 수 있도록 허용하는 것이다.

Spring Security에서 Cors의 설정

@Configuration
public class SecurityConfig {
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                .cors(cors -> {}) // CORS 활성화 (CorsConfigurationSource 사용)
                .authorizeHttpRequests(auth -> auth
                        .anyRequest().authenticated() // 모든 요청 인증 필요
                );
        return http.build();
    }
    
    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration configuration = new CorsConfiguration();
        configuration.setAllowedOrigins(List.of("<http://localhost:3000>")); // 허용할 Origin
        configuration.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE")); // 허용할 HTTP 메서드
        configuration.setAllowedHeaders(List.of("Authorization", "Content-Type")); // 허용할 헤더
        configuration.setAllowCredentials(true); // 쿠키 허용
        
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration); // 모든 경로에 적용
        return source;
    }
}

jwt (JSON Web Token)

JSON 객체를 사용하여 정보를 안전하게 전달하기 위한 토큰 기반 인증 방식이다.

[오르미 백엔드7기](Spring 프록시객체, 지연로딩 ,즉시로딩, 영속성전이, N+1문제)

myh7754 — Mon, 25 Nov 2024 09:22:58 +0900

프록시 객체

ㅇ

지연 로딩

데이터베이스에서 필요한 데이터만을 필요 시점에 로딩함으로써 애플리케이션의 성능을 최적화하는 데 큰 기여한다.

지연 로딩의 핵심 개념은 객체가 참조하고 있는 다른 객체나 컬렉션의 데이터를 처음부터 메모리에 로딩하지 않고, 해당 데이터에 실제로 접근하려는 시점에 로딩을 수행하는 것

→ 즉 커밋할 때 한번에 로드할 수 있도록 하는 것

지연 로딩의 동작 방식은 **프록시 패턴(Proxy Pattern)**을 기반으로 함

프록시 객체는 엔티티의 메타데이터와 식발자를 보유하여 엔티티 접근 시도가 있을 때 DB세션이 열려 있는지 확인하고 데이터베이스 쿼리를 실행하여 데이터를 로드한다. 데이터베이스 세션이 닫힌 상태에서 프록시 객체에 접근하면 LazyInitializationException 발생.

지연로딩 설정은 fetch에 값을 FetchType.LAZY로 설정하면 된다.

@Entity
public class BaseBallPlayer {
	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "team_id")
	private BaseBallTeam team;
}

즉시로딩

특정 객체와 그 객체가 연관된 다른 객체들을 한꺼번에 로드하여 애플리케이션의 성능과 사용성을 향상시키는 방법이다.

예를 들어, A 객체가 B 객체를 참조하고 있을 때, 즉시 로딩이 설정되어 있다면 A 객체를 로드하는 동시에 B 객체도 함께 로드된다.

단점.

불필요한 데이터를 메모리에 로드하게 되어 메모리 사용량이 증가할 수 있다.

예를 들어, 특정 엔티티가 다수의 연관된 엔티티를 가지고 있을 때, 모든 연관 엔티티를 즉시 로딩하게 되면 시스템의 메모리 리소스를 과도하게 사용하게 된다는 단점이 있다.

즉시로딩 설정 FetchType.EAGER

@Entity
public class BaseBallPlayer {
	@ManyToOne(fetch = FetchType.EAGER)
	@JoinColumn(name = "team_id")
	private BaseBallTeam team;
}

영속성 전이

부모 엔티티에 대해 수행된 특정 작업이 연관된 자식 엔티티에도 자동으로 전파되도록 하는 것

예를 들어, 부모 객체를 데이터베이스에 저장할 때, 연관된 자식 객체들도 자동으로 저장되도록 설정할 수 있다.

Cascade 데이터베이스에서 cascade는 외래 키 제약조건(Foreign Key constraint)이 참조하는 기본키가 삭제되거나 업데이트 되었을 때 그 부모 레코드와 연관된 자식 테이블의 레코드도 자동으로 삭제되거나 업데이트되는 방식

연관관계에서 CasCade를 설정은 다음과 같이 정의된다.

@OneToMany, @ManyToOne, @OneToOne, @ManyToMany와 같은 관계 매핑 어노테이션에 cascade = CascadeType.XXX 형식으로 설정.

CascadeType 에는 ALL, PERSIST, MERGE, REMOVE, REFRESH, DETACH 가 존재한다.

PERSIST CascadeType.PERSIST는 부모 객체를 영속화할 때, 연관된 자식 객체들도 함께 영속화하도록 설정. 예시 : 새로운 A 객체를 생성하면서 그와 연관된 B 객체들을 추가하고, A 객체를 데이터베이스에 저장할 때, B 객체들도 자동으로 데이터베이스에 저장하도록 한다.
MERGE 부모 객체의 상태를 병합할 때, 연관된 자식 객체들도 함께 병합된다. 예시 : A 객체의 정보를 업데이트할 때, 그와 연관된 B 객체도 함께 업데이트 된다.
REMOVE 부모 객체가 삭제될 때, 연관된 자식 객체들도 함께 삭제된다. 예시 : 특정 A 객체를 삭제할 때, 그와 연관된 모든 B 객체들도 자동으로 삭제되도록 설정하여 부모-자식 관계에서 불필요한 데이터가 남지 않도록 한다.
REFRESH 부모 객체를 새로고침할 때, 연관된 자식 객체들도 함께 새로고침 된다. 데이터베이스에서 최신 데이터를 가져와 엔티티 상태를 동기화할 때 유용하다.
DETACH 부모 객체가 비영속화될 때, 연관된 자식 객체들도 함께 비영속화된다. 세션의 관리를 효율적으로 처리할 수 있도록 도와준다. 예시 : 특정 A 객체를 detach할 때, 그와 연관된 B 객체도 함께 detach되어 세션 관리가 간소화된다.
ALL 앞서 언급한 모든 전이 작업을 한꺼번에 적용하는 설정 부모 객체에 대해 수행된 모든 작업이 자식 객체에도 동일하게 적용되도록 설정하는 것이며, 이를 통해 부모와 자식 객체 간의 상태를 항상 동기화된 상태로 유지할 수 있다.

N+1 문제

ORM을 사용하여 객체와 DB 테이블 간 매핑이 이루어지며, 이를 통해 개발자는 DB의 세부 사항을 신경쓰지 않고 객체지향적으로 코드를 작성할 수 있다.

하지만 ORM으로 생성된 코드는 자동화된 커리이므로 성능 최적화면에서 복잡하고 불필요한 코드가 발생할 수 있다 이 문제 중 가장 대표적인 것이 N+1문제이다.

@Getter
@Setter
@Entity
public class Board {

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

    @Column(nullable = false, length = 50)
    private String name;
    
    @OneToMany(mappedBy = "board", fetch = FetchType.LAZY)
    private List<Post> postList = new ArrayList<>();

}

@Getter
@Entity
public class Post {

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

    private String title;
    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "board_id")
    private Board board;

}

위의 예제와 같이 1개의 게시판에 여러개의 글이 있을 수 있다.

하나의 게시판에 10개의 글이 있다면 1개의 게시판을 조회하면 10개의 글을 조회하는 쿼리가 발생되어 성능저하가 발생된다. 즉 총 부모+자식의 쿼리수 1+10 = 11개의 쿼리가 발생하여 문제가 발생하는 것이 N+1 문제이다.

fetch join

fetch join은 N+1문제를 해소할 수 있는 방법으로 사용된다. fetch join은 연관된 엔티티를 한 번의 쿼리로 모두 조회한다.

jpa에서 사용법은 @OneToMany 또는 @ManyToOne 관계에서 fetch = FetchType.EAGER를 설정하여 즉시 로딩을 사용 하는 것이다.

@OneToMany(fetch = FetchType.EAGER)
private List<Post> posts;

하지만 fetch join또한 데이터의 양이 많아질 경우 , 하나의 쿼리에서 너무 많은 데이터를 가져와 성능이 저하 될 수 있다.

따라서 fetch join외에도 Batch Size와 같은 수단을 통해서 성능 튜닝을 유연히 수행할 수 있어야 한다.

배치 쿼리 (Batch Query): N+1 문제를 해결하기 위한 또 다른 방법은 배치 쿼리.

예를 들어, 여러 부모 엔티티에 대해 한 번에 자식 데이터를 가져오는 방식 JPA에서는 @Query 또는 @BatchSize를 사용하여 배치 처리를 할 수 있다.

[오르미 백엔드 7기] (Spring Entity 개념, 연관관계, 공통속성정의)

myh7754 — Mon, 25 Nov 2024 01:06:31 +0900

Entity

엔티티(Entity)는 데이터베이스의 특정 테이블을 자바 클래스 형태로 표현한 것

create table boards(
    board_id bigint not null primary key auto_increment,
    name varchar(20) not null
);

위의 sql문을 java의 Spring으로 표현하면 다음과 같다

@Getter
@Setter
@Entity
@Table(name = "boards")
public class Board {
    
    private Long boardId;
    
    private String name;
    
}

@Id

기본키를 정의하는 필드를 사용할 때 선언.

기본 키 필드는 보통 @GeneratedValue을 통해 자동으로 생성.

@Getter
@Setter
@Entity
@Table(name = "boards")
public class Board {
    
    @Id
    @GeneratedValue(strategy = GenerationType.사용할생성전략)
    private Long boardId;
    
    private String name;

생성 전략

@GeneratedValue에도 종류가 있는데 일반적으로 auto_increment와 비슷한 @GeneratedValue의 IDENTITY 전략을 사용한다.

자동 증가 전략 (jakarta.persistence.GenerationType.AUTO) 데이터베이스의 기본키 생성 규칙을 자동으로 결정하며, 데이터베이스가 기본키를 생성하는 방식을 따르게 된다.
시퀀스 전략 (jakarta.persistence.GenerationType.SEQUENCE) 기본키 값을 데이터베이스 시퀀스 객체를 사용하여 자동으로 생성하는 전략 @SequenceGenerator를 통하여 시퀀스의 이름과 시작 값 등을 자세히 정의하는 것도 가능 생성된 시퀀스를 사용하여 각 엔티티의 기본키 값을 생성
식별자 전략 (jakarta.persistence.GenerationType.IDENTITY) 기본키 필드에 대한 자동 증가 속성(auto increment)과 같음

기타 전략들

테이블 전략 (jakarta.persistence.GenerationType.TABLE) 시퀀스 전략과 유사하게 @TableGenerator를 통하여 기본키 값을 생성할 테이블과 관련된 설정을 직접 정의할 수 있다. 테이블 전략은 DBMS 제품군과는 상관 없이 개발 전략에 맞추어 취하는 방법
UUID 전략 (jakarta.persistence.GenerationType.UUID) 기본키 값을 UUID로서 생성하여 할당하는 전략

@Column

@Column은 테이블 컬럼의 데이터 타입과 제약 조건을 정의할 때에도 사용

nullable, columnDefinition, unique와 같은 제약조건 속성

@Getter
@Setter
@Entity
@Table(name = "boards")
public class Board {
    
    private Long boardId;
	   
	  @Column(nullable = false, length = 50)
    private String name;
    
}

EntityManager

엔티티 객체의 생명주기를 관리하고 레코드와 객체 간 매핑 및 조작을 쉽게 수행할 수 있도록 도와준다.
**영속성 컨텍스트(Persistence Context)**를 통해 엔티티 객체의 상태를 관리를 한다.
1차 캐시 역할을 하여 db의 불필요한 트랜잭션을 줄이고 성능을 향상시킨다
트랜잭션 관리를 담당하며 트랜잭션의 **시작(BEGIN), 커밋(COMMIT), 롤백(ROLLBACK)**을 제어한다.

영속성 컨텍스트(Persistence Context)란?

엔티티 매니져가 관리하는 객체이다.

엔티티 객체의 상태를 추적하고, 해당 엔티티가 언제, 어떻게 데이터베이스와 상호작용 하는지를 결정한다.
데이터베이스에 불필요한 접근을 줄이고, 성능을 최적화하며, 데이터의 일관성을 보장하는 역할을 수행한다.
영속성 컨텍스트는 기본적으로 세션(Session)이라고도 불리며, 이 세션은 엔티티 객체를 캐싱하는 역할을 수행한다.
트랜잭션이 시작되면 영속성 컨텍스트가 생성되며, 트랜잭션이 종료될 때까지 유지된다.
1차 캐시로 작동되어 동일한 컨텍스트 내에서 여러번 조회할 때 캐시된 엔티티를 반환하여 성능을 최적화한다.

영속성 컨텍스트의 엔티티 관리

엔티티는 컨텍스트 내에서 크게 4가지 상태로 관리된다.

비영속 상태(transient) 엔티티 객체가 아직 영속성 컨텍스트에서 관리하지 않는 상태. 데이터 베이스에 저장이 되거나 하지 않는다.
영속(관리)(managed) 영속성 컨텍스트에 의해 엔티티 객체가 관리되고 있는 상태. 엔티티의 변경사항을 추적(변경감지)하며, 트랜잭션이 커밋 될 때 변경사항을 자동 반영한다.
준영속(detached) 엔티티가 영속성 컨텍스트의 생명주기를 벗어나거나 명시적으로 분리 된 경우. 필드 변화가 일어난 후 커밋이 발생하더라도 관리를 받지 않고있기 때문에 변경사항이 반영 x 다시 반영해야 한다면 준영속 상태에서 병합(merge)를 통해 영속상태로 변경해야 한다.
삭제(removed) 영속성 컨텍스트 뿐 아니라 db에서도 삭제하기 위한 상태. 제 상태에서 엔티티는 트랜잭션이 커밋될 때 데이터베이스에서 삭제된다.

변경 감지

영속성 컨텍스트에 의해 관리되는 엔티티의 상태변화를 영속성 컨텍스트가 자동으로 감지하고 db에 반영하는 것을 의미한다.

엔티티 객체의 상태를 추적하기 위해 모든 필드 값들이 스냅샷으로 저장된다.
스냅샷
엔티티 초기 상태를 복사한 것
영속성 컨텍스트가 가장 최신의 스냅샷과 비교하여 어떤 필드가 변경되었는지 검사하고 컴밋할 때 db에 반영된다.

연관관계

db에서 테이블간의 관계(외래키와 같은)를 엔티티간의 관계로 표현한 개념이다.

일대일 연관관계(One to One)

@OneToOne 락커와 회원의 연관관계

@Entity
public class Locker {

	...
	
}

@Entity
public class Member {
	...
	private Grade memberType;
	
	@OneToOne
	private Locker locker;
}

일대다, 다대일 (One to Many, Many to One)

하나의 팀에는 많은 선수들이 있고, 많은 선수들은 하나의 팀에 속해있다.

@Entity
public class BaseBallPlayer {
	...
	@ManyToOne
	private BaseBallTeam team;
	...	
}

@Entity
public class BaseBallTeam {
	...
	@OneToMany
	private List<BaseBallPlayer> players;
	...
}

일대다로 매핑할 경우에는 연관관계의 대상이 되는 객체를 List<> 타입의 필드로서 선언한다는것

꼭 List<>일 필요는 없지만 반드시 Collection타입이어야 한다.

다대다 @ManyToMany는 자바는 쉽게 표현 가능한 상황이지만 db에서는 어렵기 때문에 잘 사용하지 않고 만약 필요하다면 다대다 관계를 풀어서 일대다 + 다대일 관계로 처리한다. -> 중간 테이블을 만들어서 관리한다

연관관계 소유자

연관관계를 맺는 두 엔티티 객체 사이에 어느 엔티티가 외래키를 갖고 있는지를 결정하는 주체이다.

@OneToOne, @OneToMany, @ManyToOne, @ManyToMany을 통해서 엔티티 간의 관계를 정의하였는데 여기서 속성 mappedBy 속성을 통해 연관관계의 외래키 소유자를 명시할 수 있다.

다음 예시들은 모두 양방향 매핑을 기준으로 표현한 것 이다.

양방향 매핑 : 서로가 서로의 참조를 볼 수 있어 team에서도 선수를 가져와 사용할 수 있고 선수도 팀의 정보를 가져와 사용할 수 있는 관계로 보면 된다.

일대일 관계

mappedBy 속성을 통해 Locker는 OneToOne으로 연결된 필드의 이름 locker의 이름을 통해 연결하고 JoinColumn을 통해 외래키 필드의 이름을 locker_id로 설정한다.

@Entity
public class Locker {
	...
	@OneToOne(mappedBy = "locker") // OneToOne으로 연결된 Locker필드의 이름
	private Member member;
	...
}

@Entity
public class Member {
	...
	private Grade memberType;
	@OneToOne
	@JoinColumn(name = "locker_id") // 외래키의 이름 설정
	private Locker locker;
	...
}

다대일, 일대다 관계 @ManyToOne , @OneToMany

다음과 같이 Post테이블은 Board테이블의 번호를 참조하여 외래키로 가지고 있다.

< 표 8 > 게시판(Board) 테이블

번호 이름

1	공지 사항
2	자유 게시판

< 표 9 > 게시글(Post) 테이블

번호 제목 내용 게시판 번호

1	첫 번째 공지사항	첫 공지입니다. 안녕하…	1
2	Spring은 즐거워요	Spring이 이렇게…	2

위의 테이블의 외래키 설정을 나타내면 다음과 같다.

@Entity
public class Board {
	private int id;
	private String name;
	@OneToMany(mappedBy = "board")
	private List<Post> post;
}

@Entity
public class Post() {
	private int id;
	private String title;
	private String conetent;
	@ManyToOne
	@JoinColumn(name = "board_id", nullable = false) // 외래키 설정
	private Board board;
}

공통속성 정의(@MappedSuperclass)

@MappedSuperclass은 상속 구조에서 공통 속성을 정의할 때 사용하는 방법이다.

클래스가 직접적으로 테이블과 매핑되지 않으면서도 자식 클래스에 공통 속성을 제공할 수 있도록 한다.

즉 @MappedSuperclass가 적용된 클래스는 엔티티(Entity)가 아니며, 데이터베이스 테이블로 매핑되지 않지만 이를 상속받는 자식 클래스는 부모 클래스의 필드를 자신의 테이블에 포함시키게 되는 것이다.

다음 예제와 같이 공통된 속성 createAt, id 등을 정의하여 베이스 테이블을 만들어 사용하면 속성은 공통되지만 독립적으로 각각 테이블에 적용되어 사용할 수 있다.

@MappedSuperclass
public abstract class BaseEntity {

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

    @Column(name = "created_at", nullable = false, updatable = false)
    private LocalDateTime createdAt;

    @Column(name = "updated_at")
    private LocalDateTime updatedAt;
}

@Entity
@Table(name = "board")
public class Board extends BaseEntity {

    @Column(nullable = false, length = 100)
    private String name;
}

@Entity
@Table(name = "post")
public class Post extends BaseEntity {

    @Column(nullable = false, length = 100)
    private String title;

    @Column(length = 1000)
    private String contents;
}

[오르미 백엔드7기] (Spring JPA 기본,ORM이란? , JDBC)

myh7754 — Fri, 22 Nov 2024 17:33:31 +0900

JPA

SPRING에서 데이터베이스의 데이터를 꺼내 사용하기 위해 DBMS에 접근하는 기술

DB 커넥터

프로그램과 DB간 상호작용을 가능하게 하는 구성요소.

통신을 관리하고 중재하는 핵심적인 역할.

다양한 DBMS(PostgreSQL, MySQL)등 과 연결을 표준화된 방식으로 처리한다.

커넥터는 보통 Query(질의)를 보내고 결과를 받아오며, 트랜잭션을 관리하는데 필요.

연결관리, 데이터 변환, 오류처리, 보안기능을 포함.

db와 연결을 효율적으로 사용하기 위해 커넥션 풀링을 지원

db커넥터는 크게 2가지 Driver와 Client Library로 나눈다.

*풀링(Pooling): 자원을 필요할 때마다 생성하는 대신 미리 자원을 할당해 놓고 필요한 시점에 꺼내서 사용하는 방법.

DB 커넥션 풀링 : 데이터 베이스와 연결을 미리 생성하여 필요할 때 할당해 사용 후 다시 풀에 반환하는 방식. 장점

데이터베이스 서버와의 빈번한 연결 및 해제를 방지하여 시스템의 성능을 향상
연결 수에 대한 제어를 통해 자원 고갈을 방지함으로써 안정성을 제공*

Driver

SQL 명령문을 전송하고 결과를 받아오는 역할을 수행한다.

Client Library

클라이언트 라이브러리는 드라이버를 추상화하여 개발자가 더 편리하게 사용할 수 있도록 제공.

JDBC

JDBC는 SQL 질의 실행, 데이터베이스 연결 관리, 트랜잭션 처리, 결과 집합(ResultSet) 처리 등 데이터베이스와 관련된 모든 작업을 Java 애플리케이션에서 직접 수행할 수 있도록 기능을 제공.

특정 데이터베이스 제품에 종속되지 않고 다양한 데이터베이스 시스템과 상호 운용이 가능하도록 설계되었다.

→ 여러 종류의 DB 사용가능

ORM

객체 지향 프로그래밍 언어의 객체와 관계형 데이터베이스의 테이블 간의 불일치를 해소하기 위한 방법

ORM은 객체 지향 시스템의 객체를 관계형 데이터베이스의 레코드와 매핑하는 과정을 자동화함.

불일치의 예시)

< 표 1 > 게시판 테이블

번호 이름

1	공지 사항
2	자유 게시판

< 표 2 > 게시글 테이블

번호 제목 내용 게시판 번호

1	첫 번째 공지사항	첫 공지입니다. 안녕하…	1
2	Spring은 즐거워요	Spring이 이렇게…	2

두 테이블의 join을 위해 게시글 테이블에 fk를 추가한 형태 이것을 스키마로 작성하면 다음과 같다.

create table boards(
    board_id bigint not null primary key auto_increment,
    name varchar(20) not null
);

create table posts(
    post_id bigint not null primary key auto_increment,
    title varchar(255) not null,
    contents text,
    board_id bigint not null,
    foreign key (board_id) references boards(board_id)
);

만약 이 때 post에서 board_id만으로 작성된 게시판을 알고 싶을 때 문제가 발생한다.

db 입장에서는 문제없이 join으로 해결 가능하다.

select boards.name
    , posts.*
from posts
left join boards
    on boards.board_id = posts.board_id
;

하지만 java입장에서는 다음과 같이 post 만으로 board객체의 이름을 알 수 없는 문제가 발생한다.

@Getter
@Setter
public class Post {
    private Long postId;
    private String title;
    private String content;
    private Long boardId;
}

그렇기 때문에 Post는 Board의 모든 값을 알기 위해 객체를 직접 할당하여 정보를 사용한다. 이러한 상황에서 객체와 테이블간 패러다임 불일치가 발생하는 것이다.

@Getter
@Setter
public class Post {
    private Long postId;
    
    private String title;
    private String content;
    
    // private Long boardId;
    
    private Board board; // <- 객체를 직접 할당
}

Java Persistence API(JPA)

자바에서 ORM을 표준화 하기 위해 정의된 일종의 인터페이스.

데이터 베이스와 테이블 간 매핑 설정을 하기위해 어노테이션 혹은 XML 기반의 메타데이터를 사용.

해당 메타데이터로 Entity, 필드와 컬럼 간 매핑, 객체 간의 연관 관계 등을 정의.

복잡한 쿼리나 대량의 데이터를 처리하는 경우, 자칫 잘못하면 여러 문제가 발생하여 성능상의 문제가 발생할 수 있다.

Data Persistence

데이터 영속성은 시스템에서 생성된 데이터가 프로그램 실행 종료가 된 후에도 사라지지 않고 유지하는 특성을 의미한다.

Hibernate

jpa를 구현한 프레임워크 중 하나.

객체 지향 프로그래밍의 객체와 관계형 db 테이블 간 매핑을 자동화 하여 데이터 지속성 관리 기능을 제공한다.

[오르미 백엔드 7기] (Spring Controller, thymeleaf 실습)

myh7754 — Tue, 19 Nov 2024 21:32:59 +0900

실습

Controller

@Controller
public class TController {

//    @ResponseBody
//    @GetMapping("/params1")
//    String showPram1(HttpServletResponse req) {
//        String name =
//        System.out.println("name =" + name);
//    }

    @ResponseBody
    @GetMapping("/params1")
    public String showParam1(HttpServletRequest req) {
        System.out.println("/param1");
        String name = req.getParameter("name");
        return "";
    }
    // localhost:8080/params2?name=...
    @ResponseBody
    @GetMapping("/params2")
    public String showParams2(@RequestParam(name = "name") String name ) {
        System.out.println("/params2");
        System.out.println("name = " + name);
        return "";
    }

    //required = false로 두면 name을 강요하지 않음
    //age에서 강요는 하지 않지만 값은 가지고 시작했으면 좋겠을 때defaultValue에 값
    @ResponseBody
    @GetMapping("/params3")
    public String showParams3(
            @RequestParam(name = "name", required = false) String name,
            @RequestParam(name = "age", required = false, defaultValue =  "1")  int age
    ) {
        System.out.println("/params3");
        System.out.println("name = " + name);
        System.out.println("age = " + age);
        return "";
    }

    // 로그인 할 때
    // id ,비밀번호 <- 객체로 관리 가능
    //@ModelAttribute를 붙히면 info에 값을 받기위한 값이라고 Spring이 인지해서 bean으로 등록
    // 값을 받기위해서는 SignForm클래스에서 주입받기 위한 Setter가 필요한데 @Data를 붙히면 그역할을 대신해줄 수 있음
    @ResponseBody
    @GetMapping("/params4")
    public String showParams4(@ModelAttribute SignForm info) {
        System.out.println("username = "  + info.getUsername());
        return "";
    }

    @Data
    class SignForm { // VO(Value Object)
        private String username;
        private int password;
    }
    //DTO vs VO

    //@ModelAttribute를 안붙혀도 info 자리에 들어가면 Spring이 알아서 인지함
    @ResponseBody
    @GetMapping("/params5")
    public String showParams5(SignForm info) {
        System.out.println("username = "  + info.getUsername());
        return "";
    }

    // 여러값을 받는 방법 객체로 받으면됨
    @ResponseBody
    @GetMapping("/params6")
    public String showParams6(@RequestParam(name = "favorite") String[] favorites) {
        System.out.println("/params6");

        //
        for (String favorite : favorites) {
            System.out.println("favorite = " + favorite);
        }
        return "";
    }
}

경로 변수

// 경로 변수
@Controller
public class T2Controller {
    // REST API
    // /boards/공지사항/posts/1의 url을 받을 때 -> 게시글이 늘어가면 1에서 계속해서 늘어남 이때 해결방법
    // pathVariable -> @PathVariable
    @ResponseBody
    @GetMapping("/boards/공지사항/posts/{id}")
    public String showPathV(@PathVariable(name = "id") int id) {
        System.out.println("id = " + id);
        return "";
    }

    //같은경로 요청이 2개가 들어오면 더 구체적인 쪽을 실행
    // ex) /path1/ 과 /path1/test가 있다면  /path1/test을 요청했을 때 /path1는 무시

    //path2/mango
    //path2
    // 이렇게하면 2가지 url을 받았을 때 쓰는 기능을 정의할 수 있음 /Dpath와 /path2/{name}
    @ResponseBody
    @GetMapping(value = { "/Dpath", "/path2/{name}"})
    public String showPathV2(@PathVariable(name = "name", required = true) String name) {
        System.out.println("name = " + name);
        return "";
    }

    //Optional을 사용해서 값이 비어있다면 null로 받고 있다면 받도록 설정할 수 있음
    @ResponseBody
    @GetMapping(value = {"/Dpath2", "/path3/{name}"})
    public String showPathV3(
            @PathVariable(name = "name") Optional<String> name
    ) {

        System.out.println("/path3 =" + name.orElse("null"));
        System.out.println("/name = " + name.orElse("null"));
        return "";
    }

    // GetMapping의 {name} 과 @PathVariable의 변수 name이 같다면 자동으로 연결해 준다.
    @ResponseBody
    @GetMapping("/path4/{name}")
    public  String showPathV4(@PathVariable String name) {
        System.out.println("/path4/" + name);
        System.out.println("name = " + name);
        return "";
    }
}

Controller 와 service 연

@Controller
@RequiredArgsConstructor
public class T3Controller {
    private final TService service;
    
    @ResponseBody
    @GetMapping("/sum")
    public String result(Numbers numbers) {
        int result = service.sum(numbers);
        return "";
    }

    @Data
    public class Numbers {
        private int a;
        private int b;
    }

}

@Service
public class TService {
//    public int sum(int a, int b) {
//        return a + b;
//    }

    public int sum(T3Controller.Numbers numbers) {
        return numbers.getA() + numbers.getB();
    }

}

Thymeleaf

thymeleaf 문법1

java파일

@Controller
public class Thymeleaf1 {
    public String prefix = "/thymeleaf";
    @GetMapping("/")
    public String index() {
        return "index";
    }

    // Model로 model을 스프링이 자동으로 넣어줌
    @GetMapping("/1")
    public String page1(Model model) {
        // model을 key와 value로 값을 받음
        model.addAttribute("key", "model의 값 입니다.");
        return prefix + "/page1";
    }

    @GetMapping("/2")
    public String page2(Post post, Model model) {
        model.addAttribute("post", post);
        return prefix + "/page2";
    }

    @Data
    class Post {
        private String title;
        private String content;
    }
    // utext가 위험한 이유 (Escape처리를 안한 text)
    @GetMapping("/3")
    public String page3(Post post, Model model) {
        String unsafe = "<script>alert('해킹');</script>";
        model.addAttribute("script", unsafe);
        return prefix + "/page3";
    }
}

html 파일

//index
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Title</title>
</head>
<body>
  <div th:each = "index : ${#numbers.sequence(1,11)}">
    <a th:href="@{~/thymeleaf/{idx}(idx=${index})}">viewpage[[${index}]]</a>
  </div>
</body>
</html>

// 1번 model 객체로 받아온 key값에 해당하는 value값을 출력
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>page1</title>
</head>
<body>
<!--    model atrribute에서 받아온 해당하는 key값의 value를 가져옴-->
    <h1 th:text="${key}">나는 페이지1</h1>
</body>
</html>

// 2번 model 객체로 전달받은 post의 변수를 사용
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>page2</title>
</head>
<body>
  <h1 th:text="${post.getTitle()}">게시물 제목</h1>

    <div>
        <span th:text="${post.getContent()}"> 내용</span>
    </div>
</body>
</html>

// 3번 escape 처리를 안한 utext에 자바스크립트 코드가 그대로 들어와서 변경됨
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>page3</title>
</head>
<body>
    <div th:text ="${script}">1번</div>
<!--    컨트롤러에서 만든 script코드가 반영되어 버림-->
    <div th:utext ="${script}">2번</div>
</body>
</html>

thymeleaf 문법2

java파일

@Controller
//@RequestMapping을 사용하면 항상 url Mapping할 때 맨 앞에 /view의 값이 붙음
@RequestMapping("/thymeleaf")
public class ThymeLeaf2 {
    public String prefix = "/thymeleaf";

    @GetMapping("/5") // /view/1 과 같음
    public String syntaxPage1(Model model) {
        model.addAttribute("username", "Hello World");
        return prefix+"/page5";
    }

    @GetMapping("/6")
    public String syntaxPage2(Model model) {
        List<String> shopList = Arrays.asList("양파", "돈");
        model.addAttribute("shopList", shopList);
        return prefix + "/page6";
    }
    //post 값을 넣어 생성하여 view로 전달
    @GetMapping("/7")
    public String syntaxPage3(Model model) {
        Post post = new Post(1, "안녕하세요", "content");
        model.addAttribute("post", post);
        return prefix + "/page7";
    }

    // view로 생성된 post를 전달
    @GetMapping("/8")
    public String syntaxPage4(Model model) {
        model.addAttribute("post",new Post());
        return prefix + "/page8";
    }

    // view에서 post로 전달받은 객체를 전달받아 줄력
    @PostMapping("/9")
    public  String syntaxPage5(Post post, String content) {
        System.out.println("post = " + post);
        System.out.println("content = " + content);
        return  "index";
    }

    @GetMapping("/10")
    public String syntaxPage6() {
        return prefix + "/thpage1";
    }
    @GetMapping("/11")
    public String syntaxPage7(int target, Model model) {
        model.addAttribute("target", target);
        return prefix + "/thpage2";
    }
}

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Post {
    private int id;
    private String title;
    private String content;
}

html 파일

// 5번 th:if문 조건을 만족하면 실행 thLunless문 조건을 불만족하면 실행하지 않음
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
    <div>
        <span th:if="username != null"> [[${username}]] 회원님! 반갑습니다.</span>
        <span th:unless="username != null"> 회원이 없습니다.</span>
    </div>
</body>
</html>

//6번 컬렉션도 전달 가능
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>page6</title>
</head>
<body>
    <h2>물건</h2>
    <ul>
        <li th:each = "item : ${shopList}" th:text="${item}"></li>
    </ul>
</body>
</html>

//7번 th:object를 상속받은 자식 태그부터 getTitle,post.title을 하지 않아도 해당 객체에 전달받은 필드 값을 바로 사용가능
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>문법 페이지 3</title>
</head>
<body>
<!-- th:object : wrapper클래스 하위 태그에 post라는 객체를 적용시켜줄꺼야-->
<div class="wrapper" th:object="${post}">
    <h2 th:text="*{title}">제목란</h2>
    <hr />
    <h4> [[ *{id} ]] 번 게시글,  작성자 : </h4>
    <div class="contents">
        <p th:text="*{content}"></p>
    </div>
</div>
</body>
</html>

//8번 
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>게시글 작성</title>
</head>
<body>
    <div> 게시물 작성</div>
    <form th:action="@{/page/5}" method ="post">
        <div>
            <label for="title">제목 : </label>
            <input id="title" type="text" name="title">
        </div>
        <div>
            <textarea name = "content" cols="30" rows="10"></textarea>
        </div>
        <div>
            <button type="submit">작성</button>
        </div>
    </form>
</body>
</html>
//9번 8번에서 전달받은 post에 값을 담아 다시 Post방식으로 넘겨준다.

//10번
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
  <ul>
    <li>
      <a th:href="@{~/page/1}"> page1</a>
    </li>

<!--  #numbers.sequence  [1,2,3,4] 배열 자동으로 생성-->
    <li th:each = " idxx : ${#numbers.sequence(1,4)}">
      <a th:href="@{~/view/{idx}(idx=${idxx})}" >view[[${idxx}]]</a>
    </li>
  </ul>
</body>
</html>

//11번
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<!--html 내부에서 변수를 만들고 싶을 때 th:with-->
  <div th:with="name = '구구단'">
    <h2 th:text="${name}"></h2>
    <h3>[[${target}]]</h3>
    <div>
<!--     th:block 어떤 태그를 써야할지 애매할 때 넣는다-->
      <th:block th:each="idx : ${#numbers.sequence(1,9)}">
        <p>[[ ${target} ]] X [[ ${idx}]] = [[ ${target} * ${idx}]]</p>
      </th:block>
    </div>
  </div>
</body>
</html>

[오르미 백엔드 7기](POJO, SPRING @Controller, Thymeleaf + CS지식(CSR, SSR))

myh7754 — Mon, 18 Nov 2024 16:34:52 +0900

POJO

특정 프레임워크, 라이브러리, 기술에 종속, 의존하지 않고 순수 자바 객체만을 사용해서 만든 자바 프로그램이다.

스프링은 POJO를 따르는 프레임워크로 주요 기술인 IoC/DI, AOP, PSA는 애플리케이션을 POJO로 개발할 수 있게 해주는 기술이다.

POJO의 규칙

프레임 워크, 특정 환경과 규약에 종속되지 않는다.

Spring,Hibernate와 같은 프레임워크에 의존하지 않는 객체
특정 프레임워크나 라이브러리의 클래스를 상속받거나 인터페이스를 구현하지 않는다.

간단한 구조

필요한 필드 , 생성자, Getter/Setter 메서드만 포함

SRP 단일 책임 원칙을 지키는 클래스여야한다.

POJO의 장점

특정 환경이나 기술에 종속적이지 않아 재사용이 가능, 확장 가능한 유연한 코드를 작성할 수 있음.
특정 기술이나 환경에 종속적이지 않아 테스트가 단순해짐.
객체지향적인 설계를 제한 없이 적용할 수 있다.

SPRING에서 POJO를 적용한 예

spring의 어노테이션은 강한 의존성을 만들지 않고 Spring이 어노테이션을 읽고 처리하기 때문에 POJO를 위반하지 않는다.

Spring이 POJO를 관리하는 코드

import org.springframework.stereotype.Service;
@Service  // Spring 컨테이너에 ProductService를 빈으로 등록
public class ProductService {
    public String getProductName() {
        return "Laptop";
    }
}

Spring 컨테이너에서 POJO를 사용하는 코드

Spring 컨테이너를 통해 객체를 생성하고 의존성을 주입

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;

@Controller
public class ProductController {
    private final ProductService productService;

    @Autowired
    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    public void printProductName() {
        System.out.println(productService.getProductName());
    }
}

Spring 컨테이너에서 POJO를 사용하는 코드

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;

@Controller
public class ProductController {
    private final ProductService productService;

    @Autowired
    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    public void printProductName() {
        System.out.println(productService.getProductName());
    }
}

@Controller

spring 에게 해당 어노테이션이 붙은 클래스가 컨트롤러임을 선언하여 반환하는 값은 뷰 이름이나 데이터를 반환한다.

@RequestMapping

method에 요청할 방식 get, post를 정하고, path에 경로를 적는다.

@RequestMapping(method = RequestMethod.GET, path = "/hello-world")
    public String receiveRequestFormBrowser() {
        System.out.println("hello");
        return "index";
    }

@GetMapping

@RequestMapping의 Get방식을 합쳐놓은게 @GetMapping

@GetMapping("/print")
    public void receiveGetRequest(HttpServletResponse response) throws IOException {
        // 한국어가 ??로 나오고 인식을 못함 ?? 123 hello가 출력됨
        PrintWriter writer = response.getWriter();
        writer.println("할로 123 hello"); //  ?? 123 hello

        response.setContentType("text/html;charset=UTF-8"); //이걸 쓰고 아래와 같이 쓰면 한국어 사용가능
        PrintWriter writer = response.getWriter();
        writer.println("할로 123 hello"); // 할로 123 hello
    }

@ResponseBody

return 값에 html이 아니라 뷰렌더링 없이 리턴값을 직접 페이지에 랜더링하여 전송하는 어노테이션이다.

@ResponseBody
    @GetMapping("/print2")
    public String receive2() {
        return "안녕하세요";
    }

Thymeleaf

html에 java코드를 사용하기 위해 java코드를 html로 변환해주는 템플릿 엔진

Thymeleaf는 HTML 속성에 th: 접두사를 붙여 동작을 정의합니다.

속성 설명

th:text	텍스트를 출력 (HTML 이스케이프 처리)
th:utext	텍스트를 출력 (HTML 이스케이프 미처리)
th:href	링크의 href 속성을 동적으로 설정
th:src	이미지 등의 src 속성을 동적으로 설정
th:alt	이미지 태그의 alt 속성을 동적으로 설정
th:action	폼 태그의 action 속성을 동적으로 설정
th:onclick	클릭 이벤트 속성 설정
th:value	입력 필드의 기본값 설정
th:style	style 속성을 동적으로 설정
th:class	class 속성을 동적으로 설정
th:if	조건에 따라 렌더링 (True일 때만 출력)
th:unless	조건에 따라 렌더링 (False일 때만 출력)
th:each	반복문 처리
th:object	폼의 기본 객체 설정
th:field	폼 필드 바인딩
th:remove	요소를 제거 (all, tag, body 등 옵션)

Thymeleaf 문법

Controller에서 전달받은 값을 기준으로 사용가능

ex)

@Controller
public class TestController {
    @GetMapping("/test")
    public String test(Model model) {
        model.addAttribute("msg", null); // null 값 전달
        return "test";
    }
}

Thymeleaf에서 변수를 사용할 때는 ${}를 사용 ${variable}: 현재 컨텍스트에 있는 변수 출력 @{url}: URL을 동적으로 생성

th:text = "${전달 받은 메시지 값}" <div th:text="${msg}">기본값</div> → 기본값과 상관없이 msg출력
만약 msg값이 null 이라면 그냥 기본 div 태그가 출력

<p th:text="${name}">Default Name</p> <!-- name 변수 값 출력 -->
<a th:href="@{/home}">Home</a>         <!-- /home URL 생성 -->

th:href = “@{url}” : url 생성 방식

정적 url

<a th:href="@{/home}">Home</a>

동적 url (경로 변수)

<a th:href="@{/user/{id}(id=${userId})}">User Profile</

쿼리 파라미터

<a th:href="@{/search(query=${searchTerm})}">Search</a>

th:each = "item :${items}" : 리스트나 배열을 순회하여 렌더링

<ul>
  <li th:each="item : ${items}" th:text="${item}">Sample Item</li>
</ul>

th:if = "${user ≠ null}" : 널이 아니면 이 태그가 출력
th:unless = "${user ≠ null}" : 널이면 이 태그가 출력 unless는 else처럼 사용하려면 else와 다르게 if와 같은조건을 한번 더 입력해줘야함

<p th:if="${user.isAdmin}">관리자</p>
<p th:unless="${user.isAdmin}">일반 사용자</p>

th: fragment =”” : 웹페이지에 메뉴 탭이나 네비바와 같이 공통으로 반복되는 영역을 정의할 때 사용 특히 header와 footer에 유용

<div th:fragment="header">
  <h1>Header Content</h1>
</div>

정의한 fragement를th:include 또는 th:replace로 가져온다.

<div th:include="fragments.html :: header"></div>
<div th:replace="fragments.html :: header"></div>

th:include: HTML 내부에 삽입. th:replace: 기존 HTML을 대체.

form th:object="${user}" : form 태크에서 데이터를 보낼 때 object에서 지정한 객체에 값을 담아 전달한다.

이미지와 같이 User Data에 있는 필드 name과 age가 담겨 object로 전달받아 name과 age를 사용가능.

출처 : 오르미 백엔드 부트캠프

th:inline : Javascript , css 코드 안에서 데이터를 동적으로 삽입

<script th:inline="javascript">
    var username = [[${user.name}]];  // Alice
    var items = [[${items}]];        // ["Item1", "Item2", "Item3"]
</script>

CSR, SSR (CS지식)

CSR (클라이언트 사이드 랜더링)

개념
- 클라이언트(브라우저)에서 웹 페이지의 렌더링을 담당하는 방식
- 서버는 HTML 껍데기와 함께 필요한 JavaScript 파일을 클라이언트에 전달하고, 클라이언트에서 JavaScript가 실행되어 동적으로 페이지를 구성한다.
작동 방식
1. 브라우저가 서버에 요청
2. 서버는 기본적인 html과 js 파일을 반환
3. 클라이언트에서 js가 실행되어 DOM을 구성하고 데이터를 받아와 화면을 동적으로 렌더링
특징
- 처음 로딩 속도가 느릴 수 있음 (js 실행 대기)
- 이후 페이지 간 이동은 빠름 (SPA 방식)
- 데이터를 동적으로 받아오기 때문에 인터랙티브한 UI 구현에 유리.
- API 호출을 통해 필요한 데이터만 받아와 클라이언트에서 렌더링.
장점
- 더 나은 ux 제공
- 서버 부하 감소, 네트워크 요청 최소화(필요한 데이터만 가져옴)
단점
- seo(검색 엔진 최적화)에 불리함
- 초기 로딩 속도가 느릴 수 있음

SSR 서버사이드 랜더링 → html의 조립이 다 끝난 상태로 넘어감

개념
- 서버에서 HTML을 완성하여 브라우저에 전달하는 방식. 브라우저는 전달받은 HTML을 바로 화면에 렌더링. 모든 페이지 요청마다 서버에서 새로운 HTML이 생성.
작동방식
1. 브라우저가 서버에 요청을 보냄.
2. 서버에서 HTML을 조립하고 완성된 페이지를 반환.
3. 브라우저는 받은 HTML을 바로 렌더링.
특징
- 첫 로딩 속도가 빠름 (완전한 HTML 제공).
- 페이지 이동 시마다 서버에 새 요청을 보냄
- SEO(검색 엔진 최적화)에 유리 (HTML이 이미 준비된 상태
장점
- 초기 렌더링 속도가 빠름
- SEO에 최적화된 구조.
단점
- 서버 부하가 증가할 수 있음.
- 페이지 간 이동 시 전체 새로고침이 발생
- 동적인 UI 구현이 번거로울 수 있음.

[오르미 백엔드7기] (Spring DI, IOC, AOP, Annotation)

myh7754 — Thu, 14 Nov 2024 17:17:57 +0900

DI , 의존성주입

의존성 주입은 객체가 자신이 의존하는 다른 객체를 직접 생성하거나 관리하는 것이 아니라 외부에서 주입받는 방식으로 제어의 흐름을 반전시키는 제어의 역전 IOC(Inversion of Control, IoC)원칙을 기반으로 한다.
외부에서 의존성을 주입받아 객체의 생명주기와 의존성 관리는 프레임워크에 맡기고 개발자는 비즈니스 로직에만 집중한다.
크게 3가지 생성자주입, setter주입, 필드주입이 있다.

생성자 주입 : 필드 내에서 boardRepository를 생성하지 않고 밖에서 생성된 repository를 생성자에서 주입받아 사용

public class BoardService {
    private final BoardRepository boardRepository;

    // 생성자 주입
    public BoardService(BoardRepository boardRepository) {
        this.boardRepository = boardRepository;
    }

    public void addBoard(Board board) {
        boardRepository.addBoard(board);
    }
}

Setter주입 : 객체가 생성된 후 세터 메서드를 통해 주입받는 방식 기본적으로 생성자 주입을 할 수 있다면 생성자 주입

public class BoardService {
    private BoardRepository boardRepository;

    // 세터 주입
    public void setBoardRepository(BoardRepository boardRepository) {
        this.boardRepository = boardRepository;
    }

    public void addBoard(Board board) {
        if (boardRepository != null) {
            boardRepository.addBoard(board);
        } else {
            throw new IllegalStateException("BoardRepository is not set.");
        }
    }
}

필드 주입 : @Autowired 어노테이션과 함께 직접 필드안에 주입하는 방식 -> 필드 주입은 테스트가 어렵고, 리팩토링 시 문제가 발생할 가능성이 높아 안티패턴으로 간주
@Autowired는 Bean컨테이너에서 등록되어 있는 객체를 찾아 타입에 맞게 자동으로 등록된다.

import org.springframework.beans.factory.annotation.Autowired;

public class BoardService {
    @Autowired
    private BoardRepository boardRepository;  // 필드 주입

    public void addBoard(Board board) {
        boardRepository.addBoard(board);
    }
}

IOC

ioc는 객체의 생성, 초기화, 의존성 관리 등의 제어 흐름을 ioc컨테이너로 넘겨 관리하도록 하는 것. -> 객체의 제어권을 프레임워크로 넘기는 것.
스프링 컨테이너가 관리하는 객체를 Bean이라고 하고 이 Bean 컨테이너를 빈 팩토리라고 부른다.
IoC가 구현하는 주요 방법이 DI 즉 외부에서 의존성을 주입받는 방식이고, IoC 컨테이너라 불리는 것을 Spring Container가 구현하는 것.
크게 2종류 BeanFactory , ApplicationContext로 나뉜다.BeanFactory
bean이라 불리는 객체를 생성, 관리 의존성 주입한다.
빈이 동일한 의존성을 공유할 수 있도록 싱글톤 빈을 보장한다.ApplicationContext
BeanFactory에서 확장한 컨테이너로 애플리케이션 레이어 통합을 지원하며, 데이터베이스 연동, 트랜잭션 관리, 웹 애플리케이션 설정 등을 하나의 컨텍스트에서 통합 관리할 수 있도록 도와준다.
다양한 설정 방식을 지원. XML 설정 파일을 사용하는 ClassPathXmlApplicationContext, 파일 시스템에서 XML 설정 파일을 읽어오는 FileSystemXmlApplicationContext, 그리고 어노테이션 기반의 설정을 지원하는 AnnotationConfigApplicationContext 등

Spring Container = IoC Container

DI와 IOC를 기반으로 객체를 관리하고 의존성을 주입하며 객체간 상호작용을 조율하는 역할을 한다.
핵심기능은 Bean객체의 생성, 초기화, 설정, 의존성 관리이다.
BeanFacktory와 ApplicationContext라는 두 인터페이스가 포함되어 있으며 이를통해 빈 객체와 스프링 어플리케이션의 객체를 각각 관리한다.
ApplicationContext: BeanFactory를 확장한 형태 → 메시지 소스 접근, 이벤트 처리, 트랜잭션 관리 등 고급 기능을 지원

AOP

관점 지향 프로그래밍으로, 핵심 비즈니스 로직과 공통 기능(예: 로깅, 트랜잭션 관리 등)을 분리해주는 프로그래밍 패러다임.
Spring에서는 @Aspect, @Before, @After, @Around 등의 어노테이션으로 AOP 기능을 설정
@Aspect : 클래스가 AOP 기능을 제공하는 관점(aspect)임을 나타낸다.
@Before: 메서드 실행 전에 특정 동작을 수행.
@After: 메서드 실행 후에 특정 동작을 수행.
@Around: 메서드 실행 전후에 특정 동작을 수행하며, 메서드 실행 자체를 제어할 수도 있다.

PSA

Annotation

@Configuration , @bean 컨테이너

스프링 컨테이너는 @Configuration 클래스 내부의 @Bean 메서드를 호출하여 반환된 객체를 싱글톤 빈으로 관리
@Configuration : 해당 클래스가 Spring 설정 파일임을 나타낸다.
@Bean : 직접 객체를 생성하고 Bean으로 등록할 때 사용@Component, @ComponentScan
@Configuration public class AppConfig { @Bean public BoardService boardService(BoardRepository boardRepository) { return new BoardService(boardRepository); } @Bean public BoardRepository boardRepository() { return new BoardRepository(); } }
클래스에 @Component를 붙이면 별도 @Bean 설정 없이 자동으로 스캔
@Component: 클래스를 Spring Bean으로 등록 → 이를 확장한 어노테이션으로 @Service, @Repository, @Controller 등이 있다.
@ComponentScan: 지정한 패키지를 스캔하여 @Component가 붙은 클래스를 Bean으로 등록@Autowired -> 예전에는 주입받기 위해 사용하는 건데 지금은 그냥 자동으로 해줌 spring이
@Component public class BoardRepository { // Bean으로 자동 등록 }
@Autowired: Bean을 자동으로 주입합니다.

@AllArgsConstructor

모든 필드의 인자 있는 생성자 생성@NoArgsConstructor
@AllArgsConstructor public class Board { private Long id; private String title; private String content; }
인자 없는 생성자 생성
@RequiredArgsConstructor
@RequiredArgsConstructor: 모든 final 필드 및 @NonNull로 표시된 필드를 포함하는 생성자를 자동 생성 -> 즉 반드시 생성되어야 하는 final 필드만 처리한다.
public class BoardService { private final BoardRepository boardRepository; // 반드시 생성자를 통해 주입 public void addBoard(Board board) { boardRepository.addBoard(board); } }

[오르미 백엔드 7기] (database 실습2)

myh7754 — Thu, 14 Nov 2024 02:53:03 +0900

show databases ;
drop database if exists `practice`;
create database `practice`;
use `practice`;
create table air_logistics (
    #unsigned 절대값
    id int unsigned not null primary key auto_increment,
    category varchar(10) not null,
    special_baggage Boolean not null comment 'true = 1 , false = 0',
    send varchar(5) not null,
    receive varchar(5) not null,
    airline varchar(10) not null,
    distance int not null,
    special_rate int unsigned not null,
    rate int unsigned not null,
    send_date datetime default CURRENT_TIMESTAMP
);

insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('식품',0,'중국','한국','대한항공',1,0,1500,"2024-11-30");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('기호품',0,'한국','호주','아시아나',2,0,2000,"2024-11-30");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('전자제품',1,'일본','한국','낫폰항공',1,1000,1500,"2024-11-30");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('의학품',1,'미국','한국','델타항공',4,1000,1500,"2024-12-01");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('식품',0,'인도','한국','고우에어',3,0,1500,"2024-12-01");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('일바누편',0,'한국','캐나다','대한항공',4,0,1500,"2024-12-01");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('의류',1,'한국','일본','아시아나',1,1000,1500,"2024-12-02");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('전자제품',1,'미국','한국','델타항공',4,1000,1500,"2024-12-02");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('주류',1,'칠레','한국','라탐항공',4,0,1000,"2024-12-03");
insert into air_logistics(category, special_baggage, send, receive, airline, distance, special_rate, rate, send_date) values ('주류',1,'독일','한국','대한항공',4,0,1000,"2024-12-03");
select * from air_logistics;
# 1.우리 공항에서 보내는 곳과 그 보낸 곳의 항공편 수가 어떻게 되는지 전체 데이터를 알고 싶습니다.
select
    send as '보내는 곳',
    count(`send`) as '항공편 수'
from
    air_logistics
-- 보내는 곳과 count를 묶어주기 위해 group by 사용
group by
    send;

# 1-1. 추가 한국의 항공편만 보고싶습니다.
# where을 사용한 경우
select send as '보내는곳', count(`send`) as '항공편수'
from air_logistics
where send = '한국'
group by send
;
# having을 사용한경우 where 로 할 수 있다면 성능상 where이 좋습니다.
select
    send as '보내는곳', count(`send`) as '항공편수'
from air_logistics
group by send
having send = '한국'
;
# 1-3 미국에서 우리 공항으로 들어오는 물류의 항공편이 몇건인지
select
    count(`send`) as '미국에서 들어오는 항공편 수'
from air_logistics
where send = '미국' and receive = '한국';

-- 품류 관리표
create table `category_tb`(
    id int unsigned not null primary key auto_increment,
    category varchar(10) not null,
    special_baggage Boolean not null comment 'true = 1 , false = 0'
);
insert into category_tb(category, special_baggage) values ('식품',false);
insert into category_tb(category, special_baggage) values ('기호품',false);
insert into category_tb(category, special_baggage) values ('전자제품',true);
insert into category_tb(category, special_baggage) values ('의학품',true);
insert into category_tb(category, special_baggage) values ('식품',false);
insert into category_tb(category, special_baggage) values ('일바누편',false);
insert into category_tb(category, special_baggage) values ('의류',true);
insert into category_tb(category, special_baggage) values ('전자제품',true);
insert into category_tb(category, special_baggage) values ('주류',true);
insert into category_tb(category, special_baggage) values ('주류',true);
select * from category_tb;
-- 원본 테이블에 품류 번호 컬럼 추가
alter table air_logistics add column category_id int unsigned not null after id;


desc air_logistics;
select * from air_logistics;
select * from category_tb;
-- 두 테이블을 join하여동일한 컬럼 값으로 변경
# update 값을바꿀테이블 join 엮을테이블 on 공통된컬럼 set 바꿀테이블에수정할값;
update air_logistics a
join
    category_tb b
on a.category = b.category
set a.category_id = b.id;
-- 외래키 추가
alter table air_logistics add foreign key (category_id) references category_tb(id);
-- 이제 엮였으므로 원본에서 불필요한 catgory와 special_beggage 삭제
alter table air_logistics
drop column category,
drop column special_baggage;

# 1-4특별수하물이 0일때는 O 아닐때는 x 조회
-- case를 사용할 경우 반드시 end를 쓴다 -> 이 sql은 switch case문처럼 작동
select
    a.category as '품류',
    case
        -- case의 조건
        when a.special_baggage = true
        -- 참이라면
        then 'O'
        -- 거짓이라면 (생략가능)
        else 'X'
        -- 종료했을 때 결과 (생략가능)
    end as '특별_수하물_여부'
from category_tb a;
# 쪼개놓은 테이블 2개를 다시 원본테이블로 표시하는 방법
-- select from 왼쪽테이블 join 오른쪽테이블 on 공통된 컬럼
# join은 left join 혹은 right join 중 하나를 선택할 수 있으며
# 만약 left join을 한다면 on에 있는 공통된 컬럼에서 왼쪽값을 기준으로 일치하는 행을 넣고 없다면 null 값을 넣는다.
select
    a.id as '번호',
    b.category as '품류',
    b.special_baggage as '특별 수하물 여부',
    a.send as '보내는 곳',
    a.receive as '받는 곳',
    a.airline as '항공편',
    a.distance as '거리',
    a.special_rate as '특별운임비',
    a.rate as '운임비',
    a.send_date as '보내는 날짜'
from
    air_logistics a
right join
    category_tb b
on a.category_id = b.id ;
select * from air_logistics;
select * from category_tb;

-- 거리탈 운임 표
CREATE TABLE `distance_charge` (
    id int unsigned not null primary key auto_increment,
    `culture_code` VARCHAR(5) NOT NULL UNIQUE,
    distance int not null,
    rate int unsigned not null
);

-- 데이터 추가
INSERT INTO `distance_charge`
SET `culture_code` = '아시아',
    `distance` = 1,
    `rate` = 1500
;

INSERT INTO `distance_charge`
SET `culture_code` = '오세아니아',
    `distance` = 2,
    `rate` = 2000
;

INSERT INTO `distance_charge`
SET `culture_code` = '인도',
    `distance` = 3,
    `rate` = 2500
;

INSERT INTO `distance_charge`
SET `culture_code` = '유럽-미국',
    `distance` = 4,
    `rate` = 3000
;

-- 문화권 테이블
CREATE TABLE `culture` (
    `id` INT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
    `culture_code` VARCHAR(5) NOT NULL,
    `nation` VARCHAR(5) NOT NULL UNIQUE
);
-- 데이터추가

INSERT INTO `culture`
SET `culture_code` = '아시아',
    `nation` = '한국'
;

INSERT INTO `culture`
SET `culture_code` = '아시아',
    `nation` = '일본'
;

INSERT INTO `culture`
SET `culture_code` = '아시아',
    `nation` = '중국'
;

INSERT INTO `culture`
SET `culture_code` = '오세아니아',
    `nation` = '호주'
;

INSERT INTO `culture`
SET `culture_code` = '인도',
    `nation` = '인도'
;

INSERT INTO `culture`
SET `culture_code` = '유럽-미국',
    `nation` = '독일'
;

INSERT INTO `culture`
SET `culture_code` = '유럽-미국',
    `nation` = '칠레'
;

INSERT INTO `culture`
SET `culture_code` = '유럽-미국',
    `nation` = '미국'
;

INSERT INTO `culture`
SET `culture_code` = '유럽-미국',
    `nation` = '캐나다'
;

alter table air_logistics
drop column distance,
drop column rate;
select * from air_logistics;

-- 외래키 추가

# alter table
#     draft
#     add constraint
#         fk_export_nt foreign key(target_nation)
#             references
#                 culture(nation)
# ; 이코드는fk_export_nt 제약조건 이름
alter table air_logistics add foreign key(receive) references  culture(nation);
# constraint를 넣는 이유가 뭐지? 없어도 똑같지 않나?
alter table culture add constraint foreign key(culture_code) references distance_charge(culture_code);


-- 특별 수하물 운임표
CREATE TABLE `special_charge_table`(
    id int unsigned not null primary key auto_increment,
    special_baggage Boolean not null comment 'true = 1 , false = 0',
    special_rate int unsigned not null
);
-- 데이터 추가
INSERT INTO `special_charge_table`
SET special_baggage = true,
    `special_rate` = 1000
;

INSERT INTO `special_charge_table`
SET special_baggage = false,
    `special_rate` = 0
;
drop table special_charge_table;
-- 외래키 추가
alter table category_tb add constraint foreign key (special_baggage) references special_charge_table(special_baggage);

-- 칠레로 가는 전자제품의 운임(특별운임 포함)
select
    (
        select st.category
        from category_tb st
        where st.category = '전자제품'
    ) as '품류'
     , c.nation
     , ((
            select dc.rate
            from distance_charge dc
                     left join culture c
                               on dc.culture_code = c.culture_code
            where c.nation = '칠레'
              and
                c.culture_code = dc.culture_code
        )
    +
        (
            select sct.special_rate
            from special_charge_table sct
                     left join category_tb s
                               on sct.special_baggage = s.special_baggage
            where s.category = '전자제품'
        ))
      as '운임'
from
    culture c
where
    c.nation = '칠레'
;

후기

중간에 놓쳐서 뒤에가 조금 더 이해가 안갔던 것 같습니다. 혼자 차근차근 하니 막상 그렇게 많은 내용은 아니였던 것 같고 강사님이 뒤에 문제가 더 많았다고 들었던 것 같은데 강의 때 조금더 잘 따라갔다면 더 많이 풀 수 있지 않았을까 하는 아쉬움이 남습니다.

[오르미 백엔드7기] (Database실습1, ERD)

myh7754 — Wed, 13 Nov 2024 01:39:05 +0900

ERD (엔티티 관계 다이어그램, Entity Relationship Diagram)

데이터 베이스 설계 과정에서 사용되는 모델링 기법 중 하나이다.
데이터 베이스에 저장될 데이터 엔티티(Entity)들과 엔티티 간의 관계를 시각적으로 표현하는 기법.
Entity는 정의 가능한 사물 또는 개념을 의미하고 아래와 같이 표현된다.

테이블 이름 , pk정보,컬럼이름 ,자료형 ,제약조건

|(필수, mandatory ) or O(Optional, 선택).

관계

1:1 관계 : 하나의 인스턴스 엔티티가 다른 하나의 인스턴스와 관계를 맺는 것/
ex) 한 사람은 하나의 여권을 가질 수 있고, 한 여권은 한 사람에게만 발급된다.

1:n 관계 : 하나의 엔티티가 여러개의 인스턴스와 관계를 맺는 것
ex) 하나의 사용자는 여러개의 전화번호를 가질 수 있지만 여러명의 유저가 하나의 전화번호를 가질 수는 없다.

n:m 관계 : 양쪽 엔티티가 서로 여러 관계를 맺고, 두 엔티티 모두 여러 인스턴스가 서로 연결되는 구조
ex) 한명의 학생은 여러 수업을 수강할 수 있고, 수업은 여러 학생 등록할 수 있다.

sql 실습

DDL

CREATE

열 : 열의 이름
데이터 타입 : 정수, 문자열, 날짜
제약조건 : NOT NULL, DEFAULT, PRIMARY KEY 등의 옵션
COMMENT : 별명

CREATE TABLE [데이터베이스이름].[테이블이름] (
    [열] [데이터타입] [제약조건] COMMENT [별명],
)

실제 예시

CREATE TABLE test_db.students (
    name     VARCHAR(255) NOT NULL, // NOT NULL은 해당 열에 NULL값을 허용하지 않는 의미
    age INT NOT NULL,
    address VARCHAR(255) NOT NULL
)

UNIQUE 제약조건 : 중복 없이 유일하게 들어가야하는 정보 ex) id, 이메일

CREATE TABLE 테이블명 (
        컬럼명 데이터타입 UNIQUE 
        ...
)

DEFAULT 제약조건 : 컬럼에 값을 입력하지 않을 경우 기본값이 적용된다.

CREATE TABLE 테이블명 (
        컬럼명 데이터타입 DEFAULT 기본값
        ...
)

실제예시

CREATE TABLE profile (
    id VARCHAR(255) NOT NULL,
    create_date DATE DEFAULT now()
)

INSERT INTO profile (id) VALUES (45)

PRIMARY KEY (기본키) : 데이터를 식별하기 위한 기준. 기본키는 NULL 값을 가질 수 없으며 중복된 값을 가져서도 안된다 즉 NOT NULL + UNIQUE -> ID같은 속성

auto_increment : 자동증가 옵션과 함께 많이 사용

CREATE TABLE 테이블명 (
        컬럼명 데이터타입 PRIMARY KEY auto_increment.
        ...
)

FOREIGN KEY (외래키) : 테이블간 관계를 나타낼 때 사용. 다른 테이블의 기본키를 참조해 외래키로 사용한다. 즉 외래키는 다른 테이블의 기본키 중 하나

RESTRICT : 대부분의 DBMS 시스템은 DEFAULT 설정으로 RESTRICT가 적용된다. 데이터 무결성을 유지하기 위한 가장 안전한 옵션인데, 외래키 제약 조건이 설정된 경우 참조된 행이 삭제되는 것을 방지한다.

이 제약조건을 사용하게 될때 자식의 모든 레코드를 삭제해야 부모 테이블을 삭제할 수 있다.

CASECADE : 부모테이블에 대한 DELETE를 허용. 참조된 테이블의 레코드가 삭제될 때 해당 레코드를 참조하는 다른 테이블의 레코드도 함께 삭제도니다. 즉 부모의 행이 삭제되면 관련된 자식 테이블 행도 자동삭제된다.

SET NULL : 부모 테이블의 정보가 삭제되었을 때 참고하던 자식 테이블의 FK 컬럼값이 NULL로 변경

CREATE TABLE customer (
        id INT PRIMARY KEY, 
        name VARCHAR(10) NOT NULL, 
        address VARCHAR(200), 
        contact VARCHAR(100)
);
CREATE TABLE orders (
        id INT PRIMARY KEY,
        customer_id INT, 
        date TIMESTAMP DEFAULT now(),
        payment VARCHAR(50),
        amount INT,
        delivery_amount INT,
        -- 참조한 외래키
        FOREIGN KEY (customer_id) REFERENCES customer(id) [ON DELETE CASCADE|ON DELETE SET NULL] 
)

ALTER : 테이블의 구조 변경을 위해 사용

ALTER TABLE students ADD grade VARCHAR(20) // varchar속성의 grade 추가
ALTER TABLE students RENAME COLUMN grade TO grea // students의 grade이름을 great로 수정
ALTER TABLE students MODIFY COLUMN address VARCHAR(100) // 타입을 varchar로 수정
ALTER TABLE students DROP COLUMN grade // grade 열삭제

DML

DCL

[오르미 백엔드 7기] (DataBase)

myh7754 — Mon, 11 Nov 2024 11:23:59 +0900

데이터 베이스란?

데이터 베이스는 방대한 데이터를 체계적으로 저장, 관리, 검색할 수 있도록 도와주는 기술.
단순한 저장소를 넘어 데이터의 무결성을 유지하고, 효율적인 검색과 처리를 가능하게 하고, 복잡한 데이터 구조를 논리적으로 표현할 수 있는 도구.

데이터 베이스의 종류

관계형 데이터베이스 (Relational Database)

MariaDB , MySQL , PostSQL, OracleDB , Microsoft SQL Server
데이터와 데이터간 관계를 정의하는 구조를 가진다.
행(Row)와 열(Column)로 이루어져 있다. SQL을 사용해서 다룰 수 있다.

NoSQL 데이터 베이스

MongoDB(문서형), Redis(키-값)
비관계형 db로 sql을 사용하지 않고 당양한 데이터 모델을 지원하여 관리한다.
주로 비정형 데이터를 효율적으로 처리 가능하고 고성능, 높은 확장성을 제공하는 것이 특징이다.
문서, 키-값, 열, 그래프 등 다양한 형태로 데이터를 저장한다.

객체지향 데이터 베이스(Object-Oriented Database)

객체지향 프로그래밍의 개념을 db에 적용한 시스템.
객체와 객체 간의 관계를 저장하고, 관리한다.
복잡한 구조를 관리하는데 유리하고, 상속, 다형성 등 개념을 db에서도 사용가능하다,

그래프 데이터베이스(Graph Database)

노드(Node), 간선(Edge), 속성(Property)으로 구성된 그래프 구조를 기반으로 데이터를 저장 관리한다.
복잡한 관계와 연결성을 가진 데이터를 처리하는데 적합하며, 소셜네트워크, 추천시스템, 경로 탐색 등에서 유용하게 사용된다.

분산 데이터베이스(Distributed Database)

여러 네트워크에 분산된 db를 하나의 통합된 db처럼 관리하는 db 시스템이다.
고가용성, 확장성, 성능 향상을 목표로 한다. 클리우드 환경에서 자주 사용되고 대규모 데이터 처리와 실시간 데이터 접근에 적합하다.

데이터베이스 관리 시스템 (DBMS)

db를 생성하고 관리하며 조작할 수 있게 해주는 소프트웨어
db에 대해 데이터의 저장,검색,수정,삭제 등의 작업을 지원하고 데이터를 효율적으로 사용할 수 있도록 지원한다.
DB는 데이터 저장소, DBMS는 그 데이터를 관리하고 조작하는 도구
주요 기능

동시성 제어 : 여러 사용자가 동시에 데이터베이스에 접근하여도 데이터의 일관성을 유지
무결성 유지 : 데이터의 정확성과 신뢰성을 보장. ex) 잘못된 데이터가 저장되는 것을 방지
보안관리 : 권한을 통해 특정 사용자만 db에 접근 가능하도록 설정
백업과 복구 : 데이터 손실 시 복구할 수 있는 기능을 제공

관계형 데이터베이스 시스템 (RDBMS)

스키마

데이터 베이스에서 데이터 구조와 제약 조건을 정의한 것. 테이블, 뷰, 인덱스, 권한 등 데이터 베이스의 객체들이 어떻게 구성될지를 명세

테이블

행과 열로 구성. 데이터를 모아놓은 표라고 생각하면 됨.
행 : 튜플, 레코드. 차수: 속성의 개수
열 :

키

기본키(Primary Key)

주키라고도 불리며 테이블에서 각 행을 고유하게 식별할 수 있는 열이다.
기본키는 중복된 값이나 Null 값을 허용하지 않으며, 각 행을 유일하게 식별해야한다.

왜래키(Foreign Key)

한 테이블의 열이 다른 테이블의 기본 키를 참조하는 제약 조건.
테이블 간 관계를 정의하고 참조 무결성을 보장한다.

참조 무결성 : 왜래 키로 참조된 데이터가 항상 유요하게 유지되도록 하는 것
ex) 두 테이블 A와 B가 있을 때, B 테이블의 어떤 열이 A 테이블의 기본 키(Primary Key)를 참조한다면, B 테이블에 들어가는 외래 키 값은 반드시 A 테이블에 존재하는 값이어야 한다.

유니크 키(Unique Key)

열의 값이 테이블 내에서 중복되지 않도록 보장하는 제약조건
기본키와 비슷하지만 Null값을 허용하는 차이점 존재.

복합 키(Composite Key)

두개 이상의 열을 조합하여 테이블의 각 행을 고유하게 식별하는 키

행(Row)

데이터 베이스의 기본 구성 단위로 저장된 실제 데이터를 나타냄 튜플(Tuple)라고 불린다.. ex) 실제 사용자의 정보들

열(Column)

데이터의 특정 속성을 나타냄 ex) 카테고리 분류 : 이름, 번호, id, 주민등록번호 ...
데이터 타입 정수(INT), 문자열(CHAR), 날짜(DATE)등이 존재
열에는 제약조건(Constraint) 및 인덱스(index)를 설정할 수 있다.

제약조건

데이터 베이스에서 데이터의 무결성과 일관성을 보장하기 위해 설정하는 규칙
제약조건은 데이터가 테이블에 삽입, 수정, 삭제될 때 데이터의 정확성과 일관성을 유지하도록 돕는다.
-> 이상현상이 발생하지 않도록 한다.

기본 키 제약조건

기본 키는 중복된 값이나 NULL 값을 허용하지 않는다.

외래 키 제약조건

한 테이블의 열이 다른 테이블의 기본 키를 참조하도록 설정한다.

유니크 제약조건

열의 값이 테이블 내에서 중복되지 않도록 보장. 기본키는 자동으로 유니크 제약조건을 가진다.
데이터의 중복을 방지하고, 특정 열의 값이 유일하도록 유지

Null 제약조건

열이 NULL 값을 가질 수 없도록 설정합니다. 이 제약조건은 데이터가 반드시 존재해야 하는 열에 적용

기본값 제약조건

명시적으로 값이 제공되지 않을 때 사용할 기본값을 설정

검사 제약조건(Check Constraint)

열의 값이 특정 조건을 만족해야 한다고 설정
이 제약조건은 데이터가 특정 규칙을 따르도록 강제

인덱스(INDEX)

데이터 검색의 성능을 향상시키기 위해 사용되는 구조. 특정 열에 대해 생성되어, 해당 열의 값고 그에 대응하는 데이터의 위치를 효율적으로 매핑한다. 이를 통해 DB는 쿼리 실행시 테이블의 전체 스캔 없이 인덱스를 통한 데이터 접근이 가능하다.
하지만 인덱스를 생성하고 유지하는데 추가적인 저장 공간이 필요하고 데이터 삽입, 수정, 삭제 시 인덱스도 함께 갱신해야 하므로 성능 오버헤드가 발생할 수 있다.

오버헤드 : 인덱스를 생성하고 유지하는 과정에서 발생하는 추가적인 처리 비용을 의미.
구체적으로 오버헤드는 성능에 부담을 주는 추가 작업이나 추가적인 자원 소모를 가리킨다.

SQL

RDBMS에서 데이터정의 조작 제어, 검색을 수행하는데 사용되는 표준화된 프로그래밍 언어

DESC [테이블 이름]; // 테이블의 구조(스키마) 확인

데이터 정의 언어 (DDL)

주요 목적은 DB의 객체를 생성, 수정, 삭제하는 것

CREATE TABLE 테이블이름(필드이름 TYPE 제약조건, ... KEY (필드이름) REPERENCES target_tb(필드이름) ) ;
ex )
CREATE TABLE Users (
    user_id INT NOT NULL,
    username VARCHAR(50) NOT NULL UNIQUE,
    password VARCHAR(100) NOT NULL,
    email VARCHAR(100),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (user_id),
    FOREIGN KEY (email) REFERENCES EmailList(email) -- 예시로 외래키 설정
);

테이블 생성시 부여 가능 옵션
AUTO_INCREMENT
NOT NULL
UNIQUE
DEFAULT
CHECK
PRIMARY KEY
FOREIGN KEY

AUTO_INCREMENT: 숫자형 컬럼(Column)에 고유한 값을 증가시켜 삽입할 때 사용. 주키(Primary Key)에 주로 사용.
NOT NULL: 해당 컬럼(Column)에 null값을 허용하지 않는다.
UNIQUE: 컬럼(Column)에 저장된 값이 테이블 내에서 고유한 값이 되도록 보장. 이 옵션이 추가되면 중복된 로우(Row)을 허용하지 않는다.
DEFAULT: 컬럼(Column)의 기본 값을 지정. 만일 INSERT 구문에서 값이 없이 로우(Row)이 추가되었다면 기본값을 채워 추가.
CHECK: 추가되는 로우(Row)의 컬럼(Column)의 값이 CHECK의 조건에 해당하는지 확인.
PRIMARY KEY: 테이블의 주키가 될 컬럼(Column)을 설정.
FOREIGN KEY: 다른 테이블의 주키(Primary Key)를 참조하여 두 테이블 간의 관계(Relation)를 설정.

DROP TABLE 테이블이름;

ALTER TABLE [테이블 이름] ADD COLUMN [컬럼 이름] [자료형] [옵션];
ALTER TABLE [테이블 이름] MODIFY COLUMN [컬럼 이름] [자료형] [옵션];
ALTER TABLE [테이블 이름] CHANGE COLUMN [이전 컬럼 이름] [변경할 컬럼 이름] [자료형] [옵션];
ALTER TABLE [테이블 이름] DROP COLUMN [컬럼 이름];
ALTER TABLE [테이블 이름] RENAME [변경할 테이블 이름];

ADD COLUMN : 테이블에 컬럼을 추가
MODIFY COLUMN : 테이블의 컬럼 명세를 변경.
CHANGE COLUMN : 테이블에 컬럼 명세를 이름과 함께 변경.
DROP COLUMN : 테이블의 컬럼을 삭제.
RENAME COLUMN : 테이블 이름을 변경.

특정 테이블의 모든 데이터를 삭제하지만 테이블의 구조는 유지하는 명령어
TRUNCATE TABLE 테이블이름;

데이터 조작 언어 (DML)

SELECT 필드이름 [as 별칭], FROM 테이블이름 [CONDITIONS];
SELECT 필드이름1, 필드이름2, ...
FROM 테이블이름
WHERE 조건;

INSERT INTO 테이블이름 (필드이름1, 필드이름2, ...)
VALUES (값1, 값2, ...);
INSERT INTO [테이블 이름] VALUES (값1, 값2, 값3, ...);
INSERT INTO [테이블 이름] (컬럼1, 컬럼2, ...) VALUES (값1, 값2, ...);
INSERT INTO [테이블 이름] SET [컬럼1] = [값1], [컬럼2] = [값2] ... ;

첫번째 방식을 사용할 때에는 VALUES 에 기재하는 값들의 순서를 열의 순서와 동일하게 하여야 한다. 생략된 열이 있다면 DEFAULT나 NULL로서 값이 채워진다,
두번째 방식은 열과 값이 일치하게 기재하여야 한다. 생략된 열이 있다면 DEFAULT나 NULL로서 값이 채워진다,
세번째 방식은 특정 열에만 값을 추가할 때 유리. 생략된 열이 있다면 DEFAULT나 NULL로서 값이 채워진다,

UPDATE 테이블이름
SET 필드이름1 = 값1, 필드이름2 = 값2, ...
WHERE 조건;

DELETE FROM 테이블이름
WHERE 조건;

데이터 제어 언어 (DCL)

계정생성
CREATE USER 'ID'@'HOST' IDENTIFIED BY'PWD';
권한 부여
GRANT 권한 ON database.table TO 'ID'@'HOST'
권한 삭제
REVOKE 권한 ON database.table To 'ID'@'HOST'

sql 실행 순서

5 SELECT [컬럼명]
1 FROM [테이블명]
2 WHERE [조건절]
3 GROUP BY [컬럼명] // 같은 그룹의 총 주문수
4 HAVING [그룹BY를 사용할 때의 조건절]
6 ORDER BY [컬럼명] [정렬방식]
7 LIMIT [오프셋]

FROM (1): 데이터가 어디서부터 가져올지 지정. 즉, 쿼리에서 사용할 테이블을 선택하는 단계.
WHERE (2): 데이터를 필터링하는 단계로, 테이블에서 조건에 맞는 행만 추출.
GROUP BY (3): 데이터를 그룹화하는 단계. 같은 값을 가진 컬럼을 기준으로 그룹을 만들어서, 각 그룹에 대한 집계 연산을 수행할 수 있게 한다. 예를 들어 "같은 그룹의 총 주문 수"처럼 그룹별로 데이터를 계산할 때 사용.
HAVING (4): GROUP BY로 그룹화된 데이터에 대한 추가 필터링 조건을 설정. WHERE와 달리, 그룹화된 결과에 조건을 적용하는 것이 특징.
SELECT (5): 지정한 컬럼들을 조회하고, 이 단계에서만 데이터를 실제로 선택해 보여준다.
ORDER BY (6): 조회된 데이터를 정렬한다. 컬럼명과 정렬방식(오름차순 ASC나 내림차순 DESC)을 지정할 수 있다.
LIMIT (7): 조회된 결과의 행 수를 제한하고, 오프셋을 설정하여 몇 번째부터 데이터를 가져올지 지정.

테이블 조인

INNER조인 (교집합) : 두 테이블에서 공통된 값을 가진 데이터만 조회
예: SELECT * FROM A INNER JOIN B ON A.id = B.a_id;
결과: 두 테이블에서 일치하는 행만 반환

left join or right join (차집합) :

왼쪽 테이블의 모든 행과 오른쪽 테이블에서 일치하는 행을 조회하며, 일치하지 않는 경우 NULL로 표시
오른쪽 테이블의 모든 행과 왼쪽 테이블에서 일치하는 행을 조회하며, 일치하지 않는 경우 NULL로 표시
예 :
SELECT FROM A LEFT JOIN B ON A.id = B.a_id;
SELECT FROM A RIGHT JOIN B ON A.id = B.a_id;
왼쪽 테이블의 모든 데이터가 반환되며, 오른쪽 테이블에 매칭되지 않는 값은 NULL로 채워진다.
오른쪽 테이블의 모든 데이터가 반환되며, 왼쪽 테이블에 매칭되지 않는 값은 NULL로 채워진다.

FULL JOIN(FULL OUTER JOIN) (합집합) :
두 테이블의 모든 데이터를 포함하며, 일치하지 않는 데이터는 NULL로 표시.
예: SELECT * FROM A FULL OUTER JOIN B ON A.id = B.a_id;
두 테이블에 일치하는 데이터와 일치하지 않는 데이터를 모두 조회. 일치하지 않는 부분은 NULL이 채워진다.

트랜잭션 (ACID원칙)

트랜잭션은 DB의 하나의 논리적 작업 단위를 의미 여러 작업이 묶여 하나의 작업처럼 처리되는 것을 말함.

원자성 (Atomicity) : 전체다 성공하면 반영 , 실패하면 전체 다 실패 하지만 save포인트를 만들고 그 시점으로 롤백은 가능
ex) 여러 작업 중 중간에 오류가 발생하면, 트랜잭션 전체가 롤백되어 아무런 변화도 없는 상태로 복원.

일관성 (Consistency) : 트랜잭션이 실행되기 전과 후에 데이터베이스가 일관된 상태를 유지해야 한다.데이터베이스에 미리 정의된 규칙(제약 조건 등)을 항상 만족하도록 보장
ex) 송금 트랜잭션의 경우 A 계좌에서 돈이 빠져나가면 B 계좌에는 동일한 금액이 더해져야 한다.

고립성 (Isolation) : 트랜잭션 간에 서로의 작업이 독립적으로 실행되어야 하며, 중간 결과가 다른 트랜잭션에 영향을 주어서는 안된다.
ex) 두 사용자가 동시에 같은 상품을 구매할 때, 고립성이 보장되면 재고가 음수가 되는 상황이 발생하지 않는다.

지속성 (Durability) : 결과를 커밋해서 그 결과가 확정이 되었다면 데이터베이스에 확실하게 반영해서 영구적으로 적용되어야 한다.
ex) 회원가입을 했다면 휘발성이 되면 안된다.

트랜잭션 예시

회원 가입을 위한 트랜잭션에서, 새로운 사용자 정보를 데이터베이스에 삽입한 후 회원에게 환영 메일을 보내는 두 가지 작업이 트랜잭션으로 묶여 있을 수 있다. 두 작업이 모두 성공해야만 트랜잭션이 커밋되며, 하나라도 실패하면 전체 작업이 롤백되어 데이터베이스에 아무 변화도 남기지 않는다.

비관적인 락(잠금) vs 낙관적인 락(잠금)

비관적인 락

데이터에 대한 잠금을 통해 동시성 문제를 방지하는 접근 방식. 데이터의 수정 작업이 진행될 때.
다른 트랜잭션이 동일한 데이터에 접근하거나 수정하는 것을 방지하기 위해 잠금을 설정.
비관적 잠금은 트랜잭션이 데이터에 접근하거나 변경할 때 해당 데이터에 대한 잠금을 강제적으로 수행함으로써 데이터의 일관성을 유지하는 방식.

데이터에 대한 잠금을 트랜잭션이 수행하기 전부터 설정한다.
트랜잭션이 완료될 때까지 잠금을 유지.
단점 : 잠금을 유지하는 동안 다른 트랜잭션이 대기하게 되어 성능 저하가 발생할 수 있음. 교착상태가 발생할 수 있음유지하는 동안 다른 트랜잭션이 대기하게 되어 성능 저하가 발생할 수 있음. 교착상태가 발생할 수 있음

낙관적인 락

데이터 충돌이 발생하지 않을 것을 가정하에 동작하는 방식.
잠금을 설정하지 않고, 트랜잭션이 데이터를 읽고 수정한 후 변경 사항을 데이터베이스에 반영할 때 데이터 충돌여부를 확인.
충돌이 발생하지 않은 경우 데이터베이스에 반영.
이 방식은 데이터 충돌이 발생할 수 있으며, 충돌 발생 시 트랜잭션을 재시도 해야할 수 있다.
트랜잭션의 수가 많거나 데이터 충돌이 빈번하게 발생하는 경우, 성능저하가 발생할 수 있다.

principal	인증된 사용자의 객체
principal.name	인증된 사용자의 사용자명
principal.authorities	인증된 사용자의 권한 목록