awake123 님의 블로그

데이터 베이스의 락

awake123 — Sun, 1 Feb 2026 22:23:13 +0900

데이터 베이스에서 락이란

여러 트랜잭션이 동시에 같은 데이터를 읽고/수정하려고 할 때 **데이터의 정합성(일관성)**을 지키기 위해 “잠금”을 걸어 접근을 제어하는 메커니즘

핵심은 동시성(성능) ↔ 일관성(정확성) 균형

락이 필요한 대표 상황

Lost Update(갱신 분실): A와 B가 같은 행을 읽고 각각 수정 → 나중에 커밋한 값이 앞선 변경을 덮어씀
Dirty Read: 아직 커밋 안 된 데이터를 다른 트랜잭션이 읽음
Non-repeatable Read / Phantom Read: 같은 조회를 두 번 했는데 중간에 다른 트랜잭션이 수정/삽입해서 결과가 달라짐

1) 락의 기본 종류: Shared / Exclusive

Shared Lock (S Lock, 읽기 락)

“읽을게요” 잠금
여러 트랜잭션이 동시에 S락은 가능
하지만 누군가가 X락(쓰기)을 걸려 하면 충돌

Exclusive Lock (X Lock, 쓰기 락)

“수정할게요” 잠금
단독으로만 가능 (다른 S/X 모두 막음)
UPDATE/DELETE 같은 쓰기 작업에 필요

2) 락의 범위(Granularity)

DB는 상황에 따라 잠금을 “어디까지” 걸지 결정합니다.

Row Lock(행 락): 특정 행만 잠금 → 동시성 좋음
Page/Block Lock: 특정 페이지(블록) 단위 잠금
Table Lock(테이블 락): 테이블 전체 잠금 → 동시성 나쁨, 대신 관리 단순/빠른 경우도 있음
Index Lock / Key-range Lock(범위 락): 인덱스 범위를 잠가 팬텀을 막는 방식(격리수준 관련)

3) 트랜잭션 격리수준과 락의 관계

격리수준이 높을수록 “안전”하지만 보통 락/대기 증가로 성능 부담이 커집니다.

READ UNCOMMITTED: 커밋 안 된 데이터도 읽을 수 있음(Dirty Read 가능)
READ COMMITTED: 커밋된 것만 읽음(Dirty Read 방지)
REPEATABLE READ: 같은 행을 반복 조회해도 동일(Non-repeatable 방지), DB에 따라 팬텀은 남을 수 있음
SERIALIZABLE: 가장 강함(팬텀도 방지), 동시성 가장 떨어짐

실무에선 “격리수준”이 곧 “락/버전관리 전략”과 붙어 있고, DB마다 구현이 달라요. (예: 어떤 DB는 MVCC로 읽기 락을 줄임)

4) 비관적 락 vs 낙관적 락 (애플리케이션 관점)

비관적 락(Pessimistic)

“충돌 날 것 같으니 미리 잠금”
DB 락을 강하게 사용
예: SELECT ... FOR UPDATE (읽으면서 수정 예정이니 X락 걸어라)

장점: 충돌 시 데이터 꼬임 방지에 강함
단점: 대기/교착상태(Deadlock) 가능, 동시성 감소

낙관적 락(Optimistic)

“충돌은 드물다, 커밋할 때 검사”
보통 version 컬럼으로 체크 (JPA의 @Version 같은 방식)
업데이트 시 WHERE id=? AND version=? 조건으로 성공/실패 판단

장점: 락 대기 적고 동시성 좋음
단점: 충돌 발생 시 재시도 로직 필요

5) 데드락(Deadlock)

서로가 서로의 락을 기다리며 영원히 못 움직이는 상태.

예)

T1: A행 X락 → B행 X락 시도(대기)
T2: B행 X락 → A행 X락 시도(대기)
→ 교착

대부분 DB는 데드락을 감지해서 한 트랜잭션을 롤백(희생자 선택) 시킵니다.

예방 팁(실무에서 진짜 중요)

항상 같은 순서로 락 획득(예: id 오름차순)
트랜잭션을 짧게 유지
인덱스를 잘 잡아 불필요한 범위 락/테이블 스캔 방지
“한 번에 많이 갱신” 배치 작업은 chunking

6) (자주 헷갈리는 포인트) MVCC와 락

많은 현대 DB는 **MVCC(다중 버전 동시성 제어)**로 “읽기”는 과거 버전을 보게 해서 읽기 락을 줄입니다.
하지만 쓰기-쓰기 충돌이나 **특정 격리수준(팬텀 방지)**에서는 여전히 락이 필요합니다.

스프링/JPA 실무 기준으로 감 잡기

동시 수정이 자주 일어나는 “수량/좌석/재고/포인트” 같은 곳
- 충돌이 잦으면: 비관적 락(SELECT FOR UPDATE) 고려
- 충돌이 드물면: 낙관적 락(@Version) 선호
“조회만 많고 수정이 적은” 화면
- MVCC 덕에 보통 큰 문제 없음
“조회 후 계산해서 수정” 패턴(읽고 → 계산 → 업데이트)
- Lost Update 위험이 큼 → 락 전략 필수

* 개인적인 의문.

- 예전에 DB를 이용할때 DB에 다수의 인원이 다양한 요청을 보내 DB가 멈춰버리던 현상을 락에 걸렸다고 표현하는 걸 들은적이 있는데 이거과 다른점인지?

락(Lock) = DB가 동시성 제어를 위해 의도적으로 거는 잠금(정상 기능)
DB가 멈춘 것처럼 보임 = 대개 락 때문에 “기다림”이 길어져서 그렇게 보이는 현상 (또는 교착, 과도한 부하)

둘은 같은 개념이 아니라, 원인(락)과 결과(멈춘 것처럼 보임) 관계

“DB가 멈춘다”가 실제로는 뭐였을 가능성이 큰가

1) 락 대기(Lock Wait)

어떤 트랜잭션이 행/테이블을 잡고 오래 안 놓음(커밋/롤백 안 함)
다른 트랜잭션들이 그 락이 풀릴 때까지 대기
앱에서는 API가 응답이 늦어지거나 타임아웃 → “DB 멈춤”처럼 체감

대표 원인

트랜잭션을 너무 길게 잡음 (대량 업데이트, 외부 API 호출을 트랜잭션 안에서 함)
인덱스가 없어 범위를 넓게 잠금(테이블 스캔) → 락 범위가 커짐

2) 데드락(Deadlock)

서로가 서로의 락을 기다리는 교착 상태
DB가 “영원히 멈추게” 두진 않고, 보통 한쪽 트랜잭션을 강제 롤백시킴
앱에서는 간헐적으로 오류가 나거나 재시도가 필요

3) 리소스 병목(부하로 인한 정지처럼 보임)

이건 “락”이 원인이 아닐 수도 있어요.

CPU 100%, 디스크 I/O 포화, 커넥션 풀 고갈, 슬로우 쿼리 폭증
결과적으로 요청이 쌓여서 “멈춤”처럼 보임

다만 락 대기도 결국은 대기 요청이 쌓여서 DB/애플리케이션 리소스를 같이 잡아먹기 때문에 부하처럼 보일 수 있습니다.

* 락을 거는 주체는?

대부분의 락은 DB가 “자동으로” 걸고, 필요할 때만 사람이 의도적으로 더 강하게 걸어 제어

1) DB가 자동으로 거는 락(기본)

트랜잭션에서

UPDATE / DELETE / INSERT 하면 DB가 알아서 쓰기 락(X락) 걸고,
격리수준/엔진 방식에 따라 읽기에도 필요한 제어(MVCC 포함)를 자동.

그래서 보통 개발자가 “락을 걸자”라고 코드에 쓰지 않아도, 쓰기 작업 자체가 락을 동반

2) 사람이 의도적으로 거는 락(명시적/강제)

충돌이 잦거나 “읽고 나서 반드시 수정” 같은 흐름을 안전하게 만들려면 개발자가 명시적으로 락을 겁니다.

대표 예시

비관적 락: SELECT ... FOR UPDATE
→ “지금 읽는 이 행은 내가 곧 수정할 거니까 다른 수정 못 하게 잡아둬”
(DB별로) 테이블 락: LOCK TABLE ...
JPA에선 @Lock(PESSIMISTIC_WRITE) 같은 걸로 걸기도 함
낙관적 락은 “락을 거는” 느낌이라기보다 version으로 충돌 감지를 사람이 설계하는 방식

3) 그럼 “락 문제”를 누가 만들기도 하냐?

락 자체는 정상 기능인데, 아래는 사람이 만든 코드/설계 때문에 락이 길어져서 사고가 납니다.

트랜잭션을 길게 잡음 (트랜잭션 안에서 외부 API 호출, 사용자 입력 대기 등)
인덱스가 없어 업데이트/조회 범위가 커짐 → 락 범위 확대
같은 자원을 서로 다른 순서로 잠금 → 데드락
한 번에 대량 갱신(배치)으로 많은 행을 오래 잠금

* DB별로 락을 거는 법과 락에 의해 발생하는 현상이 모두 다른지?

1) DB별 락 거는 법

MySQL (InnoDB)

행 잠금(비관적 락)

SELECT ... FOR UPDATE : 조회한 행을 수정 목적으로 잠금
SELECT ... FOR SHARE (또는 구버전 LOCK IN SHARE MODE) : 공유(읽기) 잠금

경합 줄이기 옵션

... FOR UPDATE NOWAIT : 못 잡으면 바로 실패
... FOR UPDATE SKIP LOCKED : 잠긴 행은 건너뛰고 가져오기 (큐/작업자 패턴에 자주 씀)

테이블 락

LOCK TABLES t WRITE/READ (주의: InnoDB라도 테이블 락을 강제로 걸 수 있음)

애플리케이션(Advisory) 락

GET_LOCK('name', timeout), RELEASE_LOCK('name') : “업무용 뮤텍스” 같은 개념

PostgreSQL

행 잠금(비관적 락)

SELECT ... FOR UPDATE
FOR NO KEY UPDATE / FOR SHARE / FOR KEY SHARE 처럼 더 세분화된 모드가 있음(외래키/키변경과 얽힐 때 의미가 커짐)

옵션

NOWAIT, SKIP LOCKED 지원

테이블 락

LOCK TABLE t IN ... MODE (여러 모드 존재)

Advisory 락

pg_advisory_lock(...), pg_advisory_unlock(...) (세션/트랜잭션 단위 둘 다 가능)

Oracle

행 잠금

SELECT ... FOR UPDATE [NOWAIT | WAIT n | SKIP LOCKED]

테이블 락

LOCK TABLE t IN ... MODE

업무용 락(패키지)

DBMS_LOCK 등을 이용한 사용자 정의 락도 많이 씀

SQL Server

SQL Server는 “구문”보다 힌트/트랜잭션 격리수준으로 제어하는 경우가 많아요.

행/범위 잠금 힌트(SELECT에 붙임)

WITH (UPDLOCK) : 읽으면서 업데이트 락(수정 예정)
WITH (XLOCK) : 배타 락
WITH (HOLDLOCK) : 범위를 오래 유지(사실상 더 강한 일관성)
ROWLOCK, PAGLOCK, TABLOCK 등으로 잠금 단위 힌트

Advisory 락

sp_getapplock / sp_releaseapplock : 애플리케이션 락

2) DB별 락에 의한 현상

공통으로 나타나는 현상(대부분 DB에서 똑같이 체감)

Blocking(락 대기)

어떤 트랜잭션이 락을 쥐고 있고 → 다른 트랜잭션이 줄줄이 대기
앱에서는 “DB 멈춘 듯” 보이는 가장 흔한 원인

Deadlock(교착상태)

서로 필요한 락을 교차로 잡고 기다림
보통 DB가 감지해서 한쪽을 강제 롤백(에러 발생)시킴

Lock timeout / statement timeout

일정 시간 기다리다 실패 (DB/설정/쿼리 옵션에 따라 메시지 다름)

DB마다 달라지는 “대표적인 차이 포인트”

1) 읽기가 막히는가? (MVCC/스냅샷 차이)

PostgreSQL / Oracle: 기본적으로 읽기는 MVCC 기반이라 대부분의 경우 “쓰기 때문에 읽기가 막히는 느낌”이 덜함
(대신 오래된 트랜잭션이 남아 있으면 정리/성능 문제가 생길 수 있음)
MySQL(InnoDB): MVCC가 있지만, 격리수준/쿼리 패턴에 따라 FOR UPDATE 같은 잠금 읽기가 흔하고, 인덱스가 없으면 락 범위가 커지기 쉬움
SQL Server: 기본 READ COMMITTED는 읽기/쓰기 경합이 더 보일 수 있고, 스냅샷 계열(예: RCSI/SNAPSHOT)을 켜면 양상이 확 달라짐

2) “범위 락/팬텀 방지” 방식이 다름

MySQL(InnoDB): (특히 REPEATABLE READ에서) 인덱스를 기반으로 next-key(레코드+갭) 락 같은 “범위 잠금”이 생겨서 생각보다 많이 막히는 경우가 있음
→ 인덱스 유무/조건이 락 범위에 큰 영향
PostgreSQL: SERIALIZABLE에서 내부적으로 충돌을 탐지하는 방식(SSI)이라, “잠금으로 막는다” 느낌이 아니라 커밋 시점에 실패(serialization failure)로 나타나는 경우가 있음
Oracle: 읽기 일관성이 강하고, 팬텀/일관성은 방식이 다르게 체감됨(읽기가 잘 안 막히는 편)

3) 잠금 단위/에스컬레이션(승격)

SQL Server는 “행→페이지→테이블”처럼 락 에스컬레이션이 이슈로 자주 등장합니다(설정/상황에 따라).
MySQL/InnoDB, PostgreSQL도 잠금 단위 개념은 있지만, SQL Server만큼 “에스컬레이션 때문에 갑자기 테이블이 막힘”이 대표 밈처럼 자주 나오진 않는 편(대신 다른 요인이 큼).

4) “문제 징후”가 보이는 방식이 다름

MySQL: “Lock wait timeout”, “Deadlock found…” 같은 메시지로 자주 인지
PostgreSQL: “deadlock detected”도 있지만 SERIALIZABLE이면 “could not serialize access…”처럼 재시도를 전제로 한 실패가 나옴
SQL Server: deadlock victim, lock request time out period exceeded 등
Oracle: NOWAIT/WAIT 옵션에 따른 에러, 대기 이벤트로 보이는 경우 많음

“DB가 멈춘 것 같다”를 락으로 의심할 때 3가지

**대기 체인(blocking chain)**이 있는지
오래 열린 트랜잭션이 있는지(커밋 안 하고 잡고 있는 세션)
인덱스 부재로 락 범위가 커진 것인지(조건 컬럼 인덱스 확인)

http와 https의 차이

awake123 — Sun, 25 Jan 2026 12:08:44 +0900

1. http

HTTP(HyperText Transfer Protocol) 는 웹에서 클라이언트(브라우저) 가 서버 에 “리소스(HTML, JSON, 이미지 등)를 달라”라고 요청하고, 서버가 응답하는 통신 규칙(프로토콜).
즉, 웹의 기본 대화 방식.

HTTP가 하는 일 (역할)

브라우저 → 서버로 요청(Request) 을 보냄
서버 → 브라우저로 응답(Response) 을 보냄
이 과정을 통해 페이지가 뜨거나(HTML), API 응답(JSON)을 받습니다.

HTTP의 핵심 특징

1) 요청/응답 구조

요청: 메서드 + 경로 + 헤더 + 바디
응답: 상태코드 + 헤더 + 바디

예) API 호출의 전형적인 흐름

GET /users/1 → 유저 정보 달라
서버 응답: 200 OK + JSON 바디

2) Stateless (무상태)

HTTP 자체는 이전 요청을 기억하지 않음.
그래서 로그인 같은 “상태”는 보통 아래로 보완합니다.

쿠키/세션
토큰(JWT 등)

3) 사람이 읽기 쉬운 텍스트 기반

요청 라인/헤더는 텍스트로 표현됩니다(그래서 디버깅이 쉬움).

4) 기본 포트

HTTP 기본 포트: 80
(단, 실제 서비스는 리버스 프록시/로드밸런서 구성에 따라 달라질 수 있어요.)

HTTP에서 자주 쓰는 메서드

GET: 조회
POST: 생성/처리
PUT: 전체 수정(또는 대체)
PATCH: 부분 수정
DELETE: 삭제

상태코드(응답 코드) 감 잡기

2xx 성공: 200 OK, 201 Created
3xx 리다이렉트: 301, 302
4xx 클라이언트 오류: 400, 401, 403, 404
5xx 서버 오류: 500, 502, 503

2. https

HTTPS(HyperText Transfer Protocol Secure) 는 HTTP에 보안 계층(TLS/SSL) 을 붙인 통신 방식.
즉, “HTTP로 주고받되, 그 내용을 안전하게(암호화/검증/인증) 주고받는 프로토콜”

HTTPS는 아래 3가지를 보장하려고 만들어졌습니다.

기밀성(Confidentiality): 전송 내용이 암호화되어 중간에서 훔쳐봐도 읽기 어려움
무결성(Integrity): 데이터가 중간에서 변조되면 감지/차단
인증(Authentication): 접속한 서버가 진짜 그 서버인지(가짜 서버 방지) 확인

HTTPS는 어떻게 동작하나? (큰 흐름)

HTTPS는 “HTTP 요청/응답”을 하기 전에, 먼저 TLS 핸드셰이크로 안전한 통신 준비를 합니다.

1) TLS 핸드셰이크(보안 통로 만들기)

브라우저(클라이언트)가 서버에게 “보안 연결하자” 요청
서버가 인증서(서버의 신분증) 를 줌
브라우저는 인증서가 신뢰할 수 있는 CA(인증기관) 로부터 발급된 건지, 도메인/유효기간이 맞는지 확인
확인이 끝나면, 양쪽이 같은 대칭키(세션키) 를 안전하게 합의
이후부터는 그 세션키로 데이터가 빠르게 암호화되어 오감

핵심은:

인증서로 ‘진짜 서버’인지 확인
이후 세션키로 실제 데이터 암호화 (대칭키가 빠르기 때문)

2) 그 다음에 “그냥 HTTP처럼” 통신

보안 통로 위에서

GET /…, POST /… 같은 HTTP 요청/응답이 그대로 오가는데
내용은 전부 암호화된 상태로 전송됩니다.

HTTPS의 특징

1) 기본 포트

HTTPS 기본 포트: 443

2) URL 표기

https:// 로 시작
브라우저 자물쇠 아이콘(인증서 유효 + 안전 연결)

3) 성능은?

예전엔 “HTTPS는 느리다” 인식이 있었는데, 지금은:

TLS 최적화, 세션 재사용, HTTP/2/HTTP/3 등으로
실사용에서 큰 차이 없거나 오히려 더 나은 경우도 많습니다.
(단, 최초 연결 시 핸드셰이크 비용은 존재)

단 HTTPS가 있어도 “완벽”은 아니다

HTTPS는 전송 구간을 보호합니다.
서버 자체가 털리거나, 사용자 PC가 악성코드에 감염되면 별개 문제.
HTTPS라고 해서 “그 사이트가 무조건 안전한 서비스/정상 기업”을 의미하진 않습니다.
도메인 소유를 증명하는 인증서도 많아서(기본 DV) 피싱에 악용될 수도 있어요.
다만 중간자 공격/도청/변조는 크게 막아줍니다.

http를 사용하면 발생할수있는 취약점

1) 도청 스니핑 (Packet Sniffing)

같은 네트워크(공용 와이파이, 사내망 등)에서 공격자가 트래픽을 가로채서 읽는 방식
HTTP는 평문이라 로그인 ID/PW, 쿠키, 폼 입력값, API 응답(JSON) 등이 그대로 보일 수 있음
예: 공용 와이파이에서 HTTP 로그인 → 계정 정보 노출

2) 중간자 공격 (MITM)

공격자가 사용자↔서버 사이에 끼어들어 보거나/바꾸거나/가짜로 응답함
HTTP는 “서버가 진짜인지” 확인이 약해서 더 쉽습니다.
예: 로그인 페이지를 가짜로 바꿔서 비밀번호를 빼감

3) 트래픽 변조 (Content Injection / Ad Injection)

통신 내용을 중간에서 수정해서 악성 스크립트/광고/리다이렉트를 끼워 넣음
예: HTTP로 받는 웹페이지에 <script>를 주입 → 악성 사이트로 유도, 추가 악성코드 다운로드 유도

4) 세션 하이재킹 (Session Hijacking)

로그인 후에 서버가 “너 로그인 됐어”라고 식별하는 값이 보통 세션 쿠키인데,
HTTP에서는 이 쿠키가 노출될 수 있어서 비번 없이도 로그인 상태를 탈취 가능
예: 쿠키를 훔쳐서 그대로 재사용 → 내 계정으로 접속된 것처럼 행동

5) 세션 고정 (Session Fixation)

공격자가 특정 세션 ID를 피해자에게 쓰게 만든 뒤(링크/주입 등),
피해자가 로그인하면 그 세션이 “로그인된 세션”이 되어서 공격자가 그대로 탈취
HTTP 환경에서 세션 관리가 허술하면 더 위험해질 수 있음

“HTTP 환경에서 더 쉽게 악용되지만, 근본 원인은 세션 재발급/검증 로직 미흡”

6) 다운그레이드/SSL Stripping (HTTPS를 HTTP로 떨어뜨리기)

사용자가 원래 HTTPS로 갈 상황인데, 공격자가 중간에서 “HTTP로 접속하게” 유도/강제
예: 첫 접속이 HTTP인 사이트에서 301/302를 가로채 HTTPS 이동을 막고 계속 HTTP로 사용하게 만들기
(HSTS 적용이 약하면 특히 위험)

7) DNS 스푸핑/피싱 결합

DNS 응답을 속이거나 공유기/와이파이에서 DNS를 조작해 가짜 서버로 보내는 방식
HTTP면 그 가짜 서버가 진짜처럼 보이기 쉬움(인증서 검증이 없으니까)
예: bank.example.com을 가짜 IP로 연결 → 똑같은 로그인 화면 제공 → 정보 탈취

“DNS 조작 자체는 HTTPS에도 발생할 수 있으나, HTTPS는 인증서 검증으로 피해를 크게 줄인다.”

https를 사용하지 않고 해당 취약점에 의한 피해를 줄이거나 일부 막을수 있는 우회방법

1) 애플리케이션 레벨 암호화 (Payload 자체를 암호화)

전송 내용(바디) 을 앱에서 직접 암호화해서 보내는 방식입니다.

예: 클라이언트가 AES-GCM 같은 대칭키로 JSON 바디를 암호화 → 서버에서 복호화
장점: 네트워크에서 바디를 훔쳐봐도 내용은 읽기 어려움
한계(치명적):
- 헤더/URL/도메인은 여전히 노출(무슨 API를 호출하는지, 어떤 서버인지 등)
- 서버 인증이 없으면 키 교환 과정 자체가 MITM에 뚫림(키를 중간자가 갈아끼울 수 있음)
- 구현 실수(키 관리/nonce 재사용/검증 누락)로 오히려 취약해질 가능성이 큼
  → 보통 “HTTPS 위에 추가로” 쓰는 방식이지, 대체재로는 비추천

2) HMAC/서명으로 변조 감지 (무결성만 확보)

요청/응답에 서명(HMAC 또는 공개키 서명) 을 붙여서 중간 변조를 감지하는 방식입니다.

예: HMAC(secret, timestamp + body) 를 헤더로 보내고 서버가 검증
장점: 변조는 막거나 탐지 가능
한계:
- 내용은 여전히 도청 가능(기밀성 없음)
- 비밀키 공유/배포 문제가 남음
- 재전송 공격(replay) 방지용 timestamp/nonce가 필요
  → “변조 방지”에는 도움되지만, ‘보는 것’은 못 막음

3) 세션 탈취 완화 (쿠키/세션 운용으로 피해 줄이기)

HTTPS 없이도 세션 하이재킹 위험을 낮추는 운영은 가능해요(완전 차단은 아님).

쿠키에 HttpOnly (JS로 쿠키 읽기 차단)
세션을 IP/UA/디바이스 지문에 바인딩(환경 바뀌면 세션 폐기)
세션 수명 짧게 + 민감 기능은 재인증(비밀번호/2FA)
요청마다 CSRF 토큰/Origin 검사 등
한계:
- 네트워크에서 쿠키가 보이면 그대로 탈취 가능
- 공용망/NAT 환경에서 IP 바인딩은 오탐/불편 증가
  → “탈취 후 악용”을 줄이는 수준

4) 네트워크를 ‘사설화’해서 통로 자체를 믿는 방식

“HTTP를 쓰되, 그 통신이 흐르는 망을 암호화/격리”하는 접근입니다.

VPN(사이트-투-사이트 / 클라이언트 VPN)
전용망, 사내망, 프라이빗 APN
SSH 터널링(포트포워딩)
장점: 인터넷 구간 노출을 줄임(외부 스니핑/변조 난이도 상승)
한계:
- 결국 “TLS를 다른 형태로 쓰는 것”이지, HTTP 자체가 안전해지는 건 아님
- VPN/터널 종단이 뚫리면 동일 문제 재발
- 공용 사용자 대상 서비스엔 적용이 어렵거나 운영 부담이 큼

5) “사용자 실수/다운그레이드”만 줄이는 장치

HTTPS를 쓰지 않는다고 했으니 이건 제한적이지만,
최소한 “HTTP로 넘어가게 만드는 공격”을 줄이려면 HSTS 같은 게 필요함
(다만 HSTS는 HTTPS가 전제라 여기선 실질적 해결책이 아님)

즉

기밀성(도청 방지) + 무결성(변조 방지) + 서버 인증을 동시에 해결하려면 사실상 TLS(=HTTPS) 가 정답

HTTPS 없이 할 수 있는 건:

(a) 앱 데이터만 암호화해서 “내용만” 가리기
(b) 서명으로 변조만 막기
(c) 세션 정책으로 피해를 줄이기
(d) VPN/터널로 망을 감싸기

HTTP의 실질적인 장점(HTTPS 대비)

1) 설정이 단순함

인증서 발급/갱신, 체인 문제, SNI, TLS 설정 같은 게 없음
“로컬에서 잠깐 띄워서 확인” 같은 용도에 편합니다.

2) 최초 연결 오버헤드가 더 적음(아주 미세)

TLS 핸드셰이크가 없어서 이론상 더 가볍습니다.
다만 요즘은 TLS 1.3, 세션 재개, HTTP/2/3 최적화로 체감 차이는 거의 없거나 오히려 HTTPS가 더 빠른 경우도 많습니다(HTTP/2/3는 보통 TLS와 같이 쓰이니까).

3) 디버깅/패킷 분석이 쉬움(보안 장비 없이)

네트워크에서 그냥 캡처하면 내용이 보이니 트러블슈팅이 쉽습니다.
물론 이건 **“장점”이라기보다 “보안이 없어서 생기는 편의”**에 가깝습니다.
HTTPS도 개발 환경에서는 프록시(Charles/Fiddler), 로컬 CA, 로그 등으로 충분히 디버깅 가능합니다.

4) 아주 제한된 환경에서의 적용 용이성

극도로 단순한 장치/레거시 시스템에서 TLS 스택이 부담될 수 있음(메모리/CPU/라이브러리).
다만 요즘 IoT도 경량 TLS가 많고, 외부망이면 TLS가 사실상 필수에 가까워요.

5) “민감 정보가 전혀 없는 내부 폐쇄망”에선 비용 대비 효율

인터넷과 완전히 분리된 망(진짜 폐쇄)에서
테스트용, 상태 페이지(health check) 등 민감정보 0인 경우엔 HTTP가 운영 단순성 면에서 선택될 수 있습니다.

HTTP의 장점 = 단순함/편의/레거시 호환
HTTPS의 가치 = 인터넷에서 서비스를 ‘성립’시키는 안전장치

개발 서버를 https로 사용하는법

A. mkcert로 “신뢰되는 로컬 인증서” 만들기 (가장 추천)

장점: 크롬/엣지에서 경고 없이 정상 HTTPS, 설정도 단순
개요: 내 PC에 로컬 CA를 설치하고, localhost용 인증서를 발급해서 서버에 붙입니다.

1) 인증서 발급

mkcert 설치 후:
- mkcert -install
- mkcert localhost 127.0.0.1 ::1
그러면 대개 이런 파일이 생깁니다:
- localhost+2.pem (인증서)
- localhost+2-key.pem (개인키)

2) Spring Boot(내장 톰캣)에 HTTPS 붙이기

Spring Boot는 보통 PKCS12(.p12) 키스토어를 씁니다. pem을 p12로 변환.

openssl pkcs12 -export \
  -in localhost+2.pem \
  -inkey localhost+2-key.pem \
  -out localhost.p12 \
  -name local-https \
  -passout pass:changeit

src/main/resources/localhost.p12로 넣고 application.yml:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:localhost.p12
    key-store-type: PKCS12
    key-store-password: changeit
    key-alias: local-https

3) React(dev server)도 HTTPS로 띄우고 싶으면

Vite/CRA 각각 방법이 다른데, 핵심은 “인증서/키를 지정해서 https로 구동”입니다.
다만 보통은 프론트는 http로 두고, API만 https로 붙이는 경우도 많아요(프록시 설정으로 해결).

B. “로컬은 HTTP 그대로 + 프록시/리버스 프록시로만 HTTPS” (현업에서도 자주)

로컬에서 HTTPS가 꼭 필요한 경우가 쿠키 Secure, 일부 브라우저 기능(권한/보안 컨텍스트), OAuth 리다이렉트 URI 때문이면,

프론트/백엔드 자체는 http 유지
앞단 프록시(예: nginx, caddy)에서만 https로 종단처리
이 방식이 가장 덜 번거롭습니다.

서버 배포후 https를 사용하는 법

A. 가장 흔한 구조: Nginx(443) → Spring Boot(8080)

장점: 운영 안정적, 인증서 갱신 자동화 쉬움, 리다이렉트/HSTS/압축/정적파일 처리 유리

1) DNS 설정

도메인의 A 레코드(또는 CNAME)를 서버 IP로 연결

2) 인증서 발급 (Certbot + Nginx)

Ubuntu 기준으로 보통:

certbot --nginx -d example.com -d www.example.com
자동으로 Nginx 설정에 SSL 적용 + 갱신 스케줄(renew)까지 잡히는 경우가 많습니다.

3) HTTP → HTTPS 리다이렉트 (필수)

Nginx에서 80은 무조건 443로 보내기:

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://$host$request_uri;
}

4) 443에서 프록시로 백엔드 연결

server {
  listen 443 ssl;
  server_name example.com www.example.com;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  location /api/ {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }

  location / {
    # 리액트 정적 빌드 서빙 또는 별도 프론트 서버로 프록시
  }
}

B. 클라우드 쓰는 경우: 로드밸런서(ALB) / Cloudflare에서 HTTPS 종료

AWS ALB에 ACM 인증서 붙이고, ALB → EC2(또는 ECS)로 HTTP 전달
Cloudflare 사용 시 “Full(strict)” 등 모드로 종단 처리
포인트: 이 경우에도 “외부는 HTTPS”, 내부는 HTTP일 수 있습니다(내부망이면 보통 OK).

C. Spring Boot에 인증서 직접 붙여서 443로 띄우는 방식(가능은 함)

단독 서버/간단 배포면 가능하지만,
운영에서는 보통 Nginx/ALB 앞단을 둡니다(갱신/보안헤더/성능/라우팅이 편함).

배포에서 꼭 같이 해야 하는 보안/동작 체크

리다이렉트: 80 → 443 (301/308)
HSTS(선택이지만 권장): HTTPS 강제(다운그레이드 공격 방지)
쿠키 설정: Secure, HttpOnly, SameSite (특히 세션/로그인)
혼합 콘텐츠 제거: 모든 리소스(API/이미지/CDN) URL을 https로 통일

https를 사용하여 추가 비용이 발생하는 경우

1) 로드밸런서(ALB)를 새로 쓰게 되는 경우

단일 서버에 Nginx+Let’s Encrypt로 붙이면 추가비용 없음
그런데 “HTTPS 처리를 ALB에서 하겠다”로 가면
- ALB 사용료가 추가될 수 있음 (인증서는 ACM으로 무료여도 ALB 자체가 유료)

2) 유료 인증서(상용 CA)를 쓰는 경우

회사 정책/특수 요구로 EV/OV 인증서 등을 요구하면 유료
일반 개인/프로젝트/대부분 서비스는 Let’s Encrypt로 충분

3) CDN/WAF/보안 서비스 유료 플랜을 쓰는 경우

Cloudflare 같은 걸 “기능 때문에” 유료로 올릴 수는 있는데
이것도 HTTPS 자체 때문이라기보단 “부가 기능” 때문에 비용이 발생

SSL 인증 (정확히는 TLS 인증)

어디에 쓰나: 브라우저 ↔ 웹서버, API 통신(HTTPS)
목적:
1. 통신 암호화(도청 방지)
2. 데이터 변조 방지
3. “이 서버가 진짜 그 도메인의 서버인지” 서버 신원 확인
신뢰의 근거: CA(인증기관) 가 발급한 인증서(서버의 신분증)
- 브라우저/OS는 “신뢰하는 CA 목록”을 기본으로 가지고 있고, 그 체인을 검증해서 믿습니다.
대표 포트: 443 (HTTPS)
핵심 포인트: “서버가 example.com 맞아?”를 공인 구조(CA)로 검증하는 체계

SSH 인증

어디에 쓰나: 서버 원격 접속(터미널), 파일 전송(SCP/SFTP), Git 접속(git@…)
목적:
1. 원격 접속 통신 암호화
2. 접속하는 주체(사용자/클라이언트) 인증
신뢰의 근거: 보통 공개키/개인키 키페어(내가 만든 키)
- 서버는 “이 사용자의 공개키를 허용한다”를 authorized_keys에 등록해둠
- 클라이언트는 개인키로 “내가 그 키의 주인”임을 증명
- 서버 자체의 신원도 확인은 하는데, 방식이 TLS와 달라요:
  - 처음 접속 때 서버가 host key를 보여주고, 클라이언트가 그 지문을 저장(known_hosts)
  - 이후 값이 바뀌면 경고(중간자 공격 의심)
대표 포트: 22
핵심 포인트: CA 같은 공인 구조보다는 키 등록/지문 고정(TOFU) 중심

한 줄로 비교

TLS(SSL): “이 도메인의 서버가 진짜인지”를 CA 인증서로 보증하면서 웹 통신을 안전하게.
SSH: “서버에 접속하는 사용자가 누구인지”를 키 기반 로그인으로 안전하게.

HTTPS 배포: TLS 인증서(Let’s Encrypt 등) 필요
서버 배포/관리 접속: SSH 키 필요 (ssh ubuntu@서버IP, GitHub SSH 키 등)

TLS인증서를 발급 받을수 있는 방법

1) Let’s Encrypt로 발급 (무료, 실무 표준)

준비물

도메인(예: example.com)이 내 서버 IP를 가리키도록 DNS 설정
외부에서 80(HTTP) 또는 DNS 설정 변경이 가능해야 함

인증(검증) 방식 2개

A. HTTP-01 (가장 흔함)

Let’s Encrypt가 도메인이 정말 본인것 인지 확인하기 위해
http://example.com/.well-known/acme-challenge/... 경로로 접근해 검증
그래서 80 포트가 외부에서 열려 있어야 합니다.

B. DNS-01 (와일드카드/80 막힌 환경에 유리)

DNS에 _acme-challenge TXT 레코드를 넣어 검증
*.example.com 와일드카드 인증서가 필요하면 보통 이 방식이 필요합니다(일반적으로).
(DNS-01은 TXT 레코드로 검증한다는 설명 참고. )

발급 도구(ACME 클라이언트)

A. Certbot (가장 대중적)

Nginx/Apache 플러그인으로 “발급 + 설정”까지 자동으로 해주는 경우가 많아요.
갱신도 certbot renew로 자동화가 잘 되어 있습니다(드라이런도 지원).

B. acme.sh (가볍고, DNS-01 자동화에 강함)

임베디드/공유기/도커 등에서도 많이 씁니다(standalone/webroot/dns 등 모드).

2) AWS 같은 클라우드에서 “관리형 인증서”로 발급 (대개 무료지만 제약 있음)

AWS ACM (Amazon Certificate Manager)

ACM에서 퍼블릭 인증서를 요청할 수 있고,
CloudFront/ELB/API Gateway 같은 AWS 통합 서비스에 붙이면 갱신까지 관리형으로 굴릴 수 있어요.
단, 일반적으로 “EC2에 파일로 내려받아 설치” 같은 건 제약이 있습니다(통합 서비스용으로 쓰는 형태).
(그래서 EC2 단독이면 보통 Let’s Encrypt + Nginx로 처리합니다.)

3) 자체 서명(Self-signed) 인증서 (무료, 로컬/내부망용)

내가 직접 서명한 인증서
브라우저에 ‘안전하지 않음’ 경고가 뜨는 게 정상이라, 보통 로컬 개발/내부 테스트에만 씁니다.

http의 버전별 차이점과 성능

HTTP/0.9

아주 초기 형태. GET만 있고 헤더/상태코드 같은 개념이 거의 없음.
성능/기능 비교 대상으로는 거의 안 씀(역사 수준).

HTTP/1.0

특징

요청/응답에 헤더 개념이 생기고, 상태코드도 정착.
기본적으로 요청 1번 = TCP 연결 1번(짧게 끊김).

성능

리소스(이미지/CSS/JS)가 많은 웹페이지는 연결을 계속 새로 열어야 해서 느림.
TCP 핸드셰이크(3-way) 비용이 매 요청마다 반복.

HTTP/1.1

핵심 개선

지속 연결(Keep-Alive): TCP 연결을 재사용.
파이프라이닝(pipelining): 여러 요청을 연달아 보내는 시도(하지만 실전에서는 문제 때문에 거의 비활성/비권장).
Host 헤더로 가상호스팅 가능(하나의 IP에서 여러 도메인).

성능 특징

1.0보다 훨씬 좋아짐(연결 재사용).
하지만 여전히 “한 연결에서 요청/응답이 사실상 순서대로” 처리되는 성격이 강해 병목이 생김.

대표 병목: HOL(Head-of-Line) Blocking (애플리케이션 레벨)

하나의 큰 응답이 앞에 걸리면 뒤의 작은 파일들이 줄줄이 대기.
그래서 브라우저가 “병렬 다운로드”하려고 여러 TCP 연결을 동시에 여는 방식으로 우회(도메인당 6개 내외 같은 제한 관행).

HTTP/2

핵심 목표: “한 연결에서 진짜 병렬로 처리하자”

바이너리 프레이밍: 텍스트가 아니라 프레임 단위로 쪼개 전송.
멀티플렉싱: 하나의 TCP 연결 위에서 여러 요청/응답을 동시에 섞어 보내기 가능.
헤더 압축(HPACK): 중복 헤더를 줄여 전송량 감소.
서버 푸시(Server Push): 서버가 필요 리소스를 미리 푸시(요즘은 운영에서 꺼두는 경우가 많음).

성능이 좋아지는 이유

HTTP/1.1의 핵심 병목이던 애플리케이션 레벨 HOL을 크게 줄임.
여러 연결을 억지로 열 필요가 줄어 TCP 연결 수 감소 → 서버/네트워크 효율 증가.
헤더가 큰 API 환경에서 HPACK이 체감될 때가 많음.

하지만 남는 병목: TCP 레벨 HOL

HTTP/2는 여전히 TCP 위에서 동작.
TCP는 패킷 손실이 나면 그 이후 데이터도 “정렬/재전송” 때문에 대기 → 한 패킷 손실이 전체 스트림에 영향을 줄 수 있음(특히 모바일/무선).

HTTP/3 (QUIC 기반)

핵심 목표: “TCP 때문에 생기는 HOL도 없애자”

HTTP/3는 TCP가 아니라 QUIC(UDP 위에서 동작) 를 사용.
QUIC은 내부적으로 암호화(TLS 1.3)와 전송제어를 포함.

핵심 개선점(성능)

스트림 단위 전송: 한 스트림에서 손실이 나도 다른 스트림은 영향이 훨씬 적음 → TCP HOL 완화.
연결 성립이 빠름: 보통 TLS 1.3과 결합하여 RTT를 줄이는 데 유리.
Connection Migration: IP가 바뀌어도(와이파이↔LTE) 연결을 더 잘 이어감(모바일 강점).
손실 회복/혼잡제어가 애플리케이션 레벨에서 더 유연하게 설계됨.

체감이 큰 환경

모바일, 무선, 패킷 손실/지연이 있는 네트워크
리소스/요청이 많은 웹앱

1.0 → 1.1: 연결 재사용으로 기본 성능 개선
1.1 → 2: 한 연결에서 멀티플렉싱 + 헤더 압축으로 병렬성/효율 개선
2 → 3: TCP HOL을 QUIC으로 줄여 특히 불안정한 네트워크에서 강함

https는 버전이 없는지?

HTTP 버전: HTTP/1.1, HTTP/2, HTTP/3
TLS 버전(= HTTPS에서의 보안 프로토콜 버전): TLS 1.0, 1.1, 1.2, 1.3

즉 HTTPS = (어떤 HTTP 버전) + TLS 조합이고, “HTTPS 2.0” 같은 식으로 말하진 않는 편.

그럼 HTTP/2에서 HTTPS vs HTTP/3에서 HTTPS는 뭐가 다른지?

둘 다 “암호화된 웹 통신”이지만 아래가 다릅니다.

1) 밑바닥 전송 계층이 다름

HTTP/2 over HTTPS: HTTP/2 + TLS 가 TCP 위에서 동작
HTTP/3 over HTTPS: HTTP/3 + TLS 1.3 이 QUIC(UDP 기반) 위에서 동작
- QUIC 안에 TLS 1.3 핸드셰이크가 통합돼 있다고 보면 됩니다.

결과적으로 “HTTPS를 쓰느냐”보다, TCP냐 QUIC이냐가 체감 차이를 만듭니다.

**HTTP/2(=TCP 기반)**는 “한 연결에서 멀티플렉싱”은 되지만,

TCP 특성상 패킷 손실이 나면 그 연결의 데이터가 대기하는 TCP 레벨 HOL(Head-of-Line) 문제가 생길 수 있어요.

**HTTP/3(=QUIC 기반)**는 스트림을 더 분리해서 다루므로,

한 스트림에서 손실이 나도 다른 스트림 영향이 상대적으로 적고
특히 모바일/무선/손실 많은 환경에서 유리한 경우가 많습니다.

HTTP/2: 표준상 TLS 없이도 가능(h2c) 하지만, 브라우저 웹에선 사실상 HTTPS(h2)만 쓴다고 봐도 됨.
HTTP/3: 구조상 TLS 1.3이 사실상 필수라서 브라우저 환경에선 항상 암호화라고 보면 됨.

TLS의 버전별 차이는?

TLS 1.0 (1999) / TLS 1.1 (2006)

현황: IETF에서 공식적으로 폐기(Historic) 되었고, 산업 표준/브라우저도 대부분 비활성화했습니다.
왜 위험한가(요지): 최신 권고 암호/메커니즘 지원이 부족하고, 현대 보안 프로파일에서 요구하는 수준을 충족하기 어렵습니다(그래서 “피해야 한다”가 표준 결론).

* 신규 구축/배포에서 TLS1.0/1.1은 옵션에서 빼는게 원칙

TLS 1.2 (2008)

현황: 아직도 가장 널리 호환되는 “현역” 버전(레거시 호환용으로 유지되는 경우 많음).
핵심 개선 방향
- 암호 스위트 구성/해시/서명 알고리즘 선택 폭이 커지고, 현대적인 조합(AEAD 등)을 사용할 수 있는 기반이 됩니다. (표준은 TLS 1.2가 1.0/1.1을 대체했다고 명시)
주의점(중요): TLS 1.2는 “구식 알고리즘도 여전히 선택 가능”한 구조라서, 서버 설정이 허술하면 약한 조합으로 협상될 수 있음 → 그래서 보안 가이드는 강한 조합만 허용하도록 권장합니다.

TLS 1.3 (2018)

현황: 최신 표준. 보안/단순성/성능을 위해 프로토콜을 크게 정리했습니다. TLS 1.3 문서는 TLS 1.2(RFC 5246)를 “폐기/대체(obsoletes)”로 명시합니다.
가장 큰 차이 3가지

1) 더 빠른 핸드셰이크(지연 감소)

일반적으로 1-RTT로 핸드셰이크가 끝나도록 줄였고, 재접속 상황에선 0-RTT(early data) 도 가능하지만 리플레이 위험이 있어 신중히 써야 합니다.

2) “안전한 것만 남기기”로 프로토콜 단순화

TLS 1.3는 구식 구성요소를 대거 제거해서, 운영자가 “실수로 약한 조합을 켜는” 가능성을 줄였습니다(요지는 단순+강화).

3) 더 강한 기본 보안 성질(현대적 설계)

최신 권고에 맞춰 TLS 1.3을 기본으로 두고, 호환 필요 시에만 TLS 1.2를 허용하라는 가이드가 일반적입니다.

HSTS란?

HTTP Strict Transport Security :

“이 도메인은 앞으로 무조건 HTTPS로만 접속해라” 를 브라우저에 강제시키는 보안 정책

왜 쓰나

HTTP→HTTPS로 리다이렉트만 해도 보통은 되지만, 공격자가 중간에서 HTTPS로 가는 리다이렉트를 막고 HTTP에 머물게 하는 공격(SSL Stripping) 을 시도할 수 있어요.
HSTS가 있으면 브라우저가 아예 HTTP로 접속 자체를 시도하지 않고 처음부터 HTTPS로 붙습니다.

어떻게 동작하나

서버가 HTTPS 응답에 아래 헤더를 실어 보냅니다.

Strict-Transport-Security: max-age=...; includeSubDomains; preload

브라우저는 이걸 기억했다가:

사용자가 http://example.com을 입력해도
브라우저가 내부적으로 https://example.com으로 바꿔 접속합니다.

주요 옵션

max-age: “얼마나 오래 HTTPS만 쓰도록 강제할지”(초 단위)
- 예: max-age=31536000 (1년)
includeSubDomains: 하위 도메인도 전부 강제
- 예: api.example.com, www.example.com 포함
preload: 브라우저에 “처음부터” 강제 목록으로 등록하는 용도(아래 주의 참고)

중요한 주의사항

HSTS는 한 번 적용하면 되돌리기 어렵습니다.
- 특히 includeSubDomains + max-age가 길면, 하위 도메인까지 HTTPS가 준비되지 않았을 때 장애가 날 수 있어요.
preload까지 등록하면(브라우저 내장 목록) 사실상 “되돌리기 더 어려운” 수준입니다.
그래서 preload는 모든 서브도메인까지 HTTPS 완비된 뒤에 하는 게 안전합니다.

JVM

awake123 — Sun, 18 Jan 2026 23:34:32 +0900

자바 가상 머신
컴파일된 .class 파일(바이트코드)을 os관계 없이 실행시켜주는 도구

실무에서의 중요도
사용하지 못한다면 :

자바 바이트 코드 실행 불가. -> 모든 자바기반 서비스 동작 불가.
플랫폼 독립성 상실 -> 윈도우, 리눅스 , 맥에 맞게 매번 빌드해야함.
가비지 컬렉션 기반 메모리 관리 기능 소실 -> 메모리 누수 위험 증가
자바 생태계 라이브러리, 프레임워크 사용 불가 -> 스프링기반 웹 서비스 구동 불가 / 마이크로서비스 기반 구조 대부분 장애.
개발 운영 생산성 급락 -> JIT 최적화 , 여러 성능의 튜닝 옵션, 풍부한 모니터링도구(JMX,Flight Recorder)등 사라짐.

금융권 백엔드 시스템, 공공기관 전산시스템, 대규모 웹서비스 등도 자바 기반이기에 사용불가.

최적화/효율성 제공
최적화 :

JIT 컴파일 -> jvm은 처음에는 바이트 코드를 인터프리터로 실행시키지만 자주 실행되는 코드를 감지하면 네이티브 코드로 컴파일하여 속도를 향상시킨다.
hotspot기반 실행 최적화 -> 코드 실행 패턴을 관찰하여 가장 많이 사용되는 부분(hot spot)을 자동 최적화. / 개발자가 성능 튜닝을 하지 않아도 지속적으로 개선.
가비지 컬렉션 기반 메모리 최적화 -> 필요없는 객체를 제거하여 메모리 누수방지, 서버 안정성 향상, 등의 효과를 제공.
멀티스레드 최적화 -> 스레드 스케쥴링, 락 최적화, 병렬 가비지 컬렉션 으로 멀티코어 자원 최대 활용.

효율성 :
플랫폼 독립성 -> 바이트 코드는 어느 os에서나 자바 가상머신으로 동일하게 실행. / 운영 비용 절감
메모리 영역 최적화 구조 -> Heap 객체 저장 / Stack 메서드 호출, 지역변수 / Method Area 클래스 정보 / Native Method Stack JNI 호출
라이브러리/프레임워크 생태계 활용 -> 자바, 코틀린, 스칼라, 그루비등 언어모두 동작가능 / Spring , Hibernate , Spark, Netty등 강력한 프레임워크

자바 가상머신의 주요 역할 :
바이트 코드를 로드하고 실행.

런타임 환경 제공. -> 네트워크 처리, 파일 시스템 접근, 스레드 관리, / 앱이 운영체제의 의존성을 최소화하고 동일하게 동작하도록 도움.

보안 역할 -> 악의적 코드 실행 방지/ 불법 메모리 접근 차단 / 시스템 자원 오남용 방지

성능관리 및 모니터링 -> JMX / JFR / VisualVM / GC로그 분석 제공

면접에서 질문한 의도 :

자바의 기초 기술 이해도
자바 개발의 기초이기에 언어와 플랫폼의 근본원리를 제대로 이해하고 있는지 확인.

시스템 구조적 사고 능력 -> 실행 구조 전체와 연결되어 있으니 jvm을 설명하는 과정에서 지원자가 시스템을 전체적으로 바라보는 능력을 평가가능,

실무경험 기반 설명 능력 -> GC튜닝 경험 / JVM 옵션 사용 경험 /장애 대응에서 JVM 로그 분석 경험/ 메모리 누수 해결 사례

자바 언어에 대한 이해도. -> 왜 자바가 플랫폼 독립적인지. / 왜 JVM 환경에서 메모리 누수가 발생할수 있는지/ 왜 GC가 필요한지.

메모리 누수가 발생하는 이유
1.객체가 아직 참조되기 때문.
-> 컬렉션(List, Map)에 객체를 넣고 제거하지 않음
-> 사용이 끝난 객체를 정적(static) 변수로 계속 참조
-> 오래 남아있는 캐시에 객체를 계속 쌓아둠
2. Listener, Callback 등록후 제거하지 않은 경우

3.ThreadLocal 오용
-> ThreadLocal 사용후 remove()하지 않은 경우
-> 스레드 풀에서 재사용되는 스레드에 ThreadLocal 값이 그대로 남는 경우

4. 닫지 않는 외부 자원(파일 ,소켓)

5. classLoader 누수
-> 정적 필드에 큰 객체를 보관
-> 스레드가 종료되지 않아 클래스 로더를 붙잡고있는 경우

인터프리터와 네이티브 코드의 차이점
1. 인터프리터
-> 바이트 코드를 한줄씩 읽고 바로 실행.
-> 실행속도는 다소 느림.
-> 초기 시작 시간이 빠름
-> 즉시 실행이 필요하거나 코드가 자주 실행되지 않는 경우 유리.

2. 네이티브 코드
-> JVM이 코드 실행 패턴을 분석하여 자주 실행되는 코드를 최적화된 기계어로 컴파일 후 캐싱
-> 이후 인터프리팅 없이 네이티브 코드로만 실행. / 매우 빠른 속도
-> 장기 실행 서버에서 큰 이점

JVM 메모리 영역 구조가 왜 최적화 구조인가.
1. 스택과 힙의 분리
-> 스택 : 메서드 실행 정보, 지역 변수가 짧은 생명 주기로 빠르게 생성.삭제
-> LIFO구조라 매우 빠르게 관리가능.
-> 힙: 객체가 오래 살아남고 구조가 복잡함.
-> GC가 필요.

=> 생존 주기가 다른 데이터를 분리하여 최적의 관리 방식.

2. Young / old Generation
-> young : 짧게 살아가는 객체 / 빠른 Minor GC
-> old : 오래 살아남는 객체 / 상대적으로 느린 Major GC 주기적 실행

3. Metaspace / Method Area 분리
Metaspace는 JVM의 Method Area를 대체하는 영역이며, 클래스 메타데이터를 저장한다.
(Java 8 이전: PermGen, 이후: Metaspace)

JVM에서 보안 역할은 어떻게 동작하는가.
1. 바이트 코드 검증
-> 클래스 로딩시 바이트 코드를 검증하며
-> 불법 메모리 접근
-> 스택 오버플로
-> 유효하지 않은 점프 등을 차단.

2. Class loader 보안
-> 상위 로더가 로드한 클래스는 하위로더가 재정의 불가
-> 악성코드가 중요 클래스 바꿔치기 방지.

3. Security Manager
-> 권한기반 제어로 파일 접근, 네트워크 접근을 제한 하는 역할.
Java 17부터 deprecated

4. Sandbox 실행
-> 서명되지 않은 코드나 외부코드(Applet 시절)는 Sandbox에서 격리.

application context

awake123 — Fri, 16 Jan 2026 19:51:37 +0900

“application context”는 스프링(Spring)에서 애플리케이션이 동작하는 데 필요한 모든 객체(Bean)와 설정을 담고 관리하는 컨테이너

ApplicationContext의 역할

빈(Bean) 생성/관리: @Component, @Service, @Repository, @Configuration 등으로 등록된 객체를 만들고 주입해줌(DI)
설정 로딩: application.yml/properties, @Configuration 설정, 프로파일(dev, prod) 등 반영
라이프사이클 관리: 초기화/종료 콜백, 스코프(singleton, request 등) 관리
부가 기능 제공: 이벤트 발행/구독, 국제화(i18n), 리소스 로딩 등

BeanFactory와의 차이점

BeanFactory는 “빈 관리”의 최소 기능만.
ApplicationContext는 **BeanFactory + 각종 편의 기능(이벤트, i18n, 리소스 등)**을 포함한 “확장판”.

웹에서 자주 나오는 “컨텍스트” 2가지

Root ApplicationContext: 서비스/레포지토리 등 “공통 빈” 중심
Servlet(Web) ApplicationContext: 컨트롤러/웹 관련 빈 중심 (DispatcherServlet이 갖는 컨텍스트)

ApplicationContext가 생성되는 시점

실행 시작

main()
SpringApplication.run(…) 호출
스프링부트가 환경을 보고 어떤 ApplicationContext를 쓸지 결정
- 웹 앱이면 보통 ServletWebServerApplicationContext (톰캣 내장 등)

핵심: refresh()에서 컨테이너가 “살아남”

ApplicationContext.refresh() 실행 (여기가 핵심 단계)
- 설정/클래스 스캔 결과를 “빈 정의(BeanDefinition)”로 등록
- 그 빈들을 실제 객체로 만들고(싱글톤 위주) 의존성 주입까지 완료
- 각종 후처리기/프록시(AOP) 준비

서버/서블릿 시작

내장 톰캣/서버 시작
DispatcherServlet 등록 및 초기화
요청이 들어오면 DispatcherServlet이 컨트롤러 호출

2) @Autowired가 왜 되는가 (DI 동작 원리)

전제

@Component / @Service / @Repository / @Configuration 같은 것들이 스캔되거나,
@Bean 메서드로 등록되면
→ ApplicationContext 안에 빈으로 등록됩니다.

주입이 일어나는 타이밍

refresh() 과정에서 빈을 생성할 때,
스프링이 “이 빈이 필요로 하는 의존성”을 확인하고 찾아서 넣습니다.

어떻게 찾나 (정확히)

기본은 타입(Type) 기준으로 찾음
후보가 여러 개면:
- @Primary가 우선
- 또는 @Qualifier("빈이름")로 지정
- 또는 주입 지점을 이름/파라미터명 등으로 매칭(상황에 따라)

3) @Transactional이 왜 되는가 (AOP + 프록시)

핵심 한 줄:

@Transactional은 “그 메서드 호출을 가로채서” 트랜잭션 시작/커밋/롤백을 자동으로 해주는 AOP예요.

동작 방식 (프록시)

ApplicationContext가 빈을 만들 때,
“이 빈에 트랜잭션 어드바이스가 적용되어야 한다”를 감지하면
원본 객체 대신 프록시 객체(대리자) 를 빈으로 등록합니다.
외부에서 그 빈의 메서드를 호출하면
→ 프록시가 먼저 실행되어 트랜잭션을 처리한 뒤
→ 실제 메서드를 호출합니다.

JPA/MyBatis와 연결

@Transactional이 붙으면 스프링은 내부에서 PlatformTransactionManager를 통해 트랜잭션을 관리
JPA면 보통 JpaTransactionManager, MyBatis/ JDBC면 DataSourceTransactionManager 계열
같은 트랜잭션 안에서 JPA와 MyBatis를 섞으면 같은 DataSource를 공유하는지 같은 것들이 중요 포인트가 됩니다.

1) @Autowired가 나오는 이유: 컨테이너가 DI를 해주기 때문

@Autowired는 “객체를 스프링이 만들어서 관리할 테니, 필요한 의존성을 찾아 넣어줘”라는 의미.
그 ‘찾아 넣는 주체’가 ApplicationContext예요.
그래서 ApplicationContext를 설명하면 보통
- “빈 등록”
- “빈 생성”
- “의존성 주입(DI)”
  이 흐름이 나오고, DI의 대표 어노테이션이 @Autowired라 같이 등장합니다.

컨테이너 밖에서는?

내가 new Service()로 직접 만들면 스프링이 관여를 못 해서 @Autowired는 주입이 안 됨(null/에러).

2) @Transactional이 나오는 이유: 컨테이너가 AOP 프록시를 붙여주기 때문

@Transactional은 메서드 호출을 가로채서
- 트랜잭션 시작 → 실제 메서드 실행 → 커밋/롤백
  을 자동으로 해주는 기능인데,
이 “가로채기”가 AOP 프록시로 구현되고,
그 프록시를 붙여서 빈으로 등록해주는 게 ApplicationContext의 역할이에요.

컨테이너 밖에서는?

new로 만든 객체는 프록시가 붙지 않아서 @Transactional이 동작하지 않음(그냥 주석처럼 됨).

ApplicationContext를 사용하지 않는다면

1) DI(@Autowired) 동작 안 함

내가 new로 직접 객체 만들면 스프링이 관여 못 해서
@Autowired 주입이 안 되거나(필드 주입이면 null), 생성자에 직접 다 넣어줘야 합니다.

OrderService s = new OrderService(); // new로 만들면
// s 안의 @Autowired repo는 주입 안 됨

2) AOP 기반 기능이 거의 다 안 됨 (@Transactional 포함)

@Transactional, @Async, @Cacheable, @Retryable 같은 건
컨테이너가 프록시를 만들어 줄 때만 제대로 동작합니다.
컨테이너 없이 new로 만들면 프록시가 없어서 “어노테이션이 있어도 효과 없음”이 됩니다.

3) 설정/환경 기능도 못 씀

@Value, @ConfigurationProperties, 프로파일(dev/prod), 자동 설정(autoconfig) 등
전부 컨테이너가 설정을 읽고 빈에 반영해주는 구조라 사용이 매우 제한됩니다.

4) 웹(MVC) 자체가 사실상 불가능/매우 불편

스프링 MVC는 DispatcherServlet이 컨트롤러 빈을 컨테이너에서 찾아 호출하는 구조라,
컨테이너가 없으면 스프링 MVC를 쓰는 의미가 크게 줄고, 사실상 “순수 서블릿/필터”로 돌아갑니다.

사용하지 못할 경우 대안

객체 생성: 직접 new
의존성 연결: 생성자에 직접 넣기(수동 DI)
트랜잭션: 직접 Connection 열고 commit/rollback
설정 값 로딩: 직접 properties 읽어서 전달
공통 관심사(로깅/보안/검증): 직접 코드로 감싸기(데코레이터/프록시 패턴을 수동 구현)

즉, 가능은 하지만 스프링이 제공하는 생산성이 거의 사라지고 코드량/실수/중복이 크게 늘어납니다.

현실적으로 안쓰는 경우는?

아주 작은 유틸/배치/CLI에서 스프링 없이 자바로만 가볍게 만들 때
스프링을 쓰더라도, 일부 아주 단순한 모듈은 순수 자바로 테스트할 때(단위 테스트에서 목 객체로 대체)
반대로 “스프링부트 웹 서비스”라면 컨테이너 없이 운영하는 건 보통 선택지가 아닙니다.

꼬리 질문

Q1. refresh()에서 “프록시(AOP)”가 준비된다고 했는데, 누가/어떻게 프록시를 붙이나요?

A. 컨테이너가 빈을 생성한 뒤 BeanPostProcessor(대표적으로 AOP 관련 후처리기)가 빈을 검사해서, @Transactional 같은 어드바이스 적용 대상이면 원본 빈 대신 프록시 빈을 등록합니다. 그래서 외부 호출이 프록시를 먼저 타면서 트랜잭션이 시작/종료됩니다.

Q2. @Autowired는 “타입 기준”이라 했는데, 같은 타입 빈이 2개면 어떻게 되나요?

A. 기본은 NoUniqueBeanDefinitionException이 납니다. 해결은 보통 3가지:

@Primary로 기본 빈 지정
@Qualifier("빈이름")로 명시
주입 지점의 이름/파라미터명과 빈 이름을 맞춰서 해결(상황에 따라)

Q3. JPA와 MyBatis를 같은 트랜잭션에서 섞을 수 있다고 했는데 조건이 뭐예요?

A. 핵심 조건은 같은 DataSource(같은 트랜잭션 매니저 관할) 를 공유해야 합니다. @Transactional이 같은 트랜잭션 경계에서 동작하려면 JPA(EntityManager)와 MyBatis(SqlSession)가 결국 같은 커넥션/트랜잭션에 묶여야 합니다. 설정이 분리되어 있으면 “같은 @Transactional인데도” 실제론 서로 다른 트랜잭션이 될 수 있어요.

Q4. ApplicationContext는 인터페이스인가요? 구현체는 뭐가 있어요?

A. ApplicationContext는 인터페이스이고, 상황별 구현체가 있어요.

일반 애플리케이션: AnnotationConfigApplicationContext 등
스프링부트 웹: 보통 ServletWebServerApplicationContext
웹/환경에 맞게 컨테이너 구현이 달라지지만 “빈 관리/DI/AOP 적용” 같은 핵심 역할은 동일합니다.

Q5. 빈 스코프가 singleton, request 등이라고 했는데 실제 차이는?

singleton: 컨테이너당 1개 인스턴스(기본값)
prototype: 요청할 때마다 새로 생성(컨테이너가 “생성까지만” 관리, 이후 생명주기 관여 적음)
request/session: 웹 요청/세션 단위로 1개(웹 컨텍스트에서 의미가 큼)
스코프가 다르면 메모리/동시성/상태관리 방식이 달라져서 설계에 영향이 큽니다.

Q6. 빈 생명주기(초기화/종료 콜백)는 어떤 방식으로 걸 수 있나요?

A. 대표적으로 3가지가 많아요.

@PostConstruct, @PreDestroy
InitializingBean, DisposableBean 인터페이스 구현
@Bean(initMethod=..., destroyMethod=...)
스프링부트에서는 보통 @PostConstruct/@PreDestroy가 가장 깔끔하게 쓰입니다.

Q7. 빈(Bean)과 그냥 객체(new로 만든 객체)는 뭐가 달라요?

A. 빈은 스프링 컨테이너가 생성/관리하는 객체라서 DI, AOP(@Transactional 등), 설정 주입(@Value), 라이프사이클 관리 같은 혜택을 받습니다. 반면 new로 만든 객체는 스프링이 모르는 객체라 이런 기능이 거의 적용되지 않아요.

Q8. 왜 굳이 컨테이너를 쓰나요? 그냥 new로 만들어도 되잖아요.

A. new로도 가능하지만 규모가 커지면

의존성 연결이 복잡해지고
공통 기능(트랜잭션/로깅/보안)을 일일이 반복 구현해야 하고
테스트/교체가 어려워집니다.
컨테이너를 쓰면 객체 생성/조립/공통 기능을 표준 방식으로 처리해서 중복과 실수를 줄이고 유지보수성이 좋아집니다.

Q9. ApplicationContext는 어디서 “가져와서” 쓰나요? 내가 직접 new 해서 써요?

A. 보통 웹/부트 애플리케이션에서는 직접 꺼내서 쓰는 일이 거의 없고, 스프링부트가 실행 중에 컨텍스트를 만들고 빈들을 주입해줘요. 정말 필요할 때만

생성자 주입으로 ApplicationContext를 받거나
ApplicationContextAware를 쓰거나
테스트에서 @SpringBootTest로 컨텍스트를 띄우는 식으로 접근합니다.
하지만 “컨테이너를 코드에서 여기저기 꺼내 쓰는 패턴”은 남용하면 의존성이 꼬여서 보통 권장되지 않습니다.

WAS와 웹서버

awake123 — Sun, 11 Jan 2026 13:38:28 +0900

1.WAS와 웹서버의 차이

웹서버 (Web Server)

역할: HTTP 요청을 받아서 정적인 리소스를 응답
- 예: HTML, CSS, JS, 이미지, 동영상, 다운로드 파일
특징
- 정적 파일 서빙에 최적화(빠르고 가벼움)
- 리버스 프록시 기능(요청을 뒤의 서버로 전달), 로드밸런싱, SSL 종료(HTTPS 처리) 등을 자주 담당
예시
- Nginx, Apache HTTP Server, Caddy

WAS (Web Application Server)

역할: 웹 애플리케이션을 실행해서 동적인 응답을 생성
- 예: 로그인/회원가입, 게시판 CRUD, 결제 처리, 권한 체크, DB 조회 결과로 HTML/JSON 생성 등
특징
- 비즈니스 로직 실행 + DB 연동 + 트랜잭션 + 세션/인증 등 “앱” 기능의 중심
- 보통 프레임워크(Spring, Django 등)가 여기서 돌아감
예시
- Java: Tomcat(서블릿 컨테이너), Jetty, Undertow / (더 전통적 의미의 WAS: WebLogic, WebSphere, JBoss/WildFly 등)
- Node.js(Express/Nest)도 “WAS 역할”을 하는 애플리케이션 서버로 보면 됨

* 둘을 같이 쓰는 이유

클라이언트 → 웹서버(Nginx) → WAS(Tomcat/Spring Boot) → DB

웹 :

정적 파일은 바로 처리(빠름)
동적 요청은 WAS로 전달(리버스 프록시)
HTTPS, 압축(gzip/br), 캐싱, 로드밸런싱, 보안 헤더 같은 공통 처리 담당

WAS:

API/비즈니스 로직 처리
DB 접근, 인증/인가, 트랜잭션 등 핵심 기능 처리

웹서버와 was를 사용해본 경험

1. 웹서버

리액트 npm run dev로 실행한 웹 서버

2. was

세미 프로젝트, 학업중 과제 등 다양한 스프링 부트 프로젝트

톰캣을 활용한 웹 페이지.

* 단 톰캣은 전통적인 was라기보다는 서블릿 컨테이너이며 전통적인 was는 WebLogic/WebSphere/WildFly

2. was와 웨서버가 제공하는 최적화

웹서버가 제공하는 최적화 (Nginx/Apache/Caddy 등)

정리하면 “요청을 싸게 처리하고, 뒤쪽 서버(WAS)를 보호/가볍게” 해줍니다.

정적 파일 고속 서빙
- OS 레벨 최적화(예: sendfile)로 파일을 효율적으로 전송
- 정적 파일에 대한 캐시 헤더(ETag, Cache-Control) 설정으로 재요청 줄임
동시 접속 처리 효율
- 이벤트 기반/비동기 처리로 커넥션을 가볍게 유지(특히 Nginx)
- Keep-Alive 관리, 대량 연결에 강함
압축/전송 최적화
- gzip / brotli 압축으로 트래픽 절감
- HTTP/2(그리고 환경에 따라 HTTP/3)로 다중화/헤더 압축 등
TLS(HTTPS) 처리 최적화
- TLS 종료(암복호화)를 웹서버가 맡아 WAS 부담 감소
리버스 프록시 버퍼링
- 느린 클라이언트에게 응답을 웹서버가 대신 천천히 보내고, WAS는 빨리 반환 가능(특히 업로드/다운로드에서 체감 큼)
로드밸런싱/헬스체크
- 여러 WAS 인스턴스로 분산 + 장애 인스턴스 제외
보안/안정성 최적화
- Rate limiting, IP 차단, WAF 연계, 요청 크기 제한 등으로 WAS 보호
캐싱(선택)
- 자주 조회되는 응답을 웹서버/프록시 레벨에서 캐시(구성에 따라)

WAS가 제공하는 최적화 (Tomcat/Jetty + Spring 등)

정리하면 “코드를 빠르고 안정적으로 실행하고, DB 작업을 효율화”합니다.

요청 처리 스레드/큐 관리
- 스레드 풀로 생성/파괴 비용을 줄이고 처리량 안정화
- 백프레셔(큐/최대 동시 처리)로 과부하 시 무너짐 방지
세션/인증/인가 처리
- 세션(또는 토큰 검증) 처리 흐름 최적화(필터 체인 등)
DB 최적화의 핵심: 커넥션 풀
- HikariCP 같은 커넥션 풀로 DB 연결 재사용(성능에 매우 큰 영향)
쿼리 실행 최적화
- PreparedStatement 재사용, 배치 처리, 트랜잭션 경계 관리
- ORM(JPA) 사용 시 1차 캐시/지연 로딩 등으로 쿼리 패턴 최적화(잘 쓰면 이득, 잘못 쓰면 N+1 폭탄)
애플리케이션 캐싱
- 로컬 캐시(Caffeine), 분산 캐시(Redis) 등으로 DB hit 줄임
직렬화/역직렬화 최적화
- JSON 파싱/생성(Jackson) 설정, 페이로드 크기 조절, 압축 연계
런타임 최적화
- JVM JIT 컴파일, GC 튜닝(필요 시), 클래스 로딩 최적화 등
비동기 처리/스트리밍(선택)
- Async Servlet, WebFlux 같은 모델로 I/O 대기 효율 개선(케이스에 따라)

요약.

웹서버 최적화 = “요청/정적/전송/보안/분산”을 싸게 처리해서 WAS를 보호
WAS 최적화 = “비즈니스 로직/DB/캐시/스레드”를 효율적으로 돌려 응답을 빨리 생성

꼬리질문

1) Tomcat은 웹서버인가요, WAS인가요?

Tomcat은 웹서버라기보단 서블릿 컨테이너이고, 자바 웹 애플리케이션을 실행해서 동적 응답을 만들기 때문에 실무에서는 WAS처럼 사용합니다.
다만 Nginx 같은 웹서버처럼 정적 파일/프록시/캐싱에 특화된 제품과는 역할이 다릅니다.

2) Spring Boot 내장 톰캣(JAR) vs 외부 Tomcat(WAR) 배포 차이는?

JAR(내장 톰캣): 애플리케이션 안에 서버가 포함돼서 java -jar로 실행 가능, 배포/실행이 단순함
WAR(외부 톰캣): 톰캣이 별도 설치돼 있고 그 위에 WAR를 올리는 방식, 운영 표준이 그렇게 잡혀있는 조직에서 사용
요즘은 보통 Spring Boot JAR 방식이 더 흔하고, 레거시/기업 환경에선 WAR도 많이 봅니다.

3) Nginx 리버스 프록시를 두면 요청 흐름은 어떻게 되나요?

클라이언트 요청을 Nginx가 먼저 받고,

/, /assets 같은 정적 경로는 Nginx가 직접 서빙
/api 같은 동적 요청만 WAS(Spring)로 프록시해서 전달합니다.
이렇게 분리하면 WAS는 로직 처리에 집중하고, 정적/연결 처리는 웹서버가 맡아서 전체 성능이 안정적입니다.

4) 정적 파일 캐싱 전략은 어떻게 잡나요?

기본 전략은:

파일명에 해시가 붙는 빌드 산출물(app.abc123.js)은 Cache-Control: max-age 길게 + immutable로 강하게 캐싱
index.html처럼 엔트리 파일은 짧게 캐싱하거나 no-cache로 두고, 새 배포 시 최신 번들을 가리키게 합니다.
ETag를 쓰면 변경 시점 판단도 깔끔합니다.

5) HTTPS(SSL 종료)는 어디서 처리하는 게 좋나요?

대부분은 웹서버(Nginx)나 로드밸런서에서 SSL 종료를 합니다.
이유는 TLS 처리를 앞단에서 통합하면 WAS 부담이 줄고, 인증서 관리/갱신도 한 곳에서 관리돼 운영이 편합니다.
내부망 구간은 HTTP로 두거나, 보안 요구가 높으면 내부도 TLS를 유지합니다.

6) WAS 성능 튜닝은 뭘 만져봤나요?

핵심은 “WAS 자체”보다 DB 접근 최적화가 체감이 큽니다.

HikariCP 커넥션 풀(max pool size, timeout)
Tomcat 스레드 풀(max threads, accept queue)
요청 타임아웃/리트라이 정책
그리고 실제로는 슬로우 쿼리/병목 로그를 보고 조정하는 게 정석입니다.

7) N+1 문제를 겪어봤다면 어떻게 발견하고 해결하나요?

발견: 목록 조회에서 쿼리가 1번이 아니라 엔티티 개수만큼 추가로 나가는지 로그로 확인합니다.
해결: 상황에 따라

fetch join으로 한 번에 가져오거나
DTO projection으로 필요한 필드만 조회하거나
@EntityGraph, batch size 설정으로 완화합니다.
핵심은 “조회 목적에 맞게 쿼리 형태를 바꾸는 것”입니다.

8) 세션 기반 vs JWT 기반 인증의 장단점은?

세션: 서버가 상태를 가짐(상태 기반). 구현이 직관적이지만 수평 확장 시 세션 공유가 필요합니다.
JWT: 토큰에 인증 정보를 담아 무상태(Stateless) 로 확장에 유리합니다. 대신 토큰 탈취/폐기(로그아웃) 처리, 만료/리프레시 설계가 중요합니다.
실무는 서비스 성격과 확장 요구에 따라 선택합니다.

9) WAS를 수평 확장하면 세션은 어떻게 처리하나요?

대표 방법은 3가지입니다.

Sticky Session: 같은 사용자를 같은 서버로 붙임(간단하지만 장애/확장 유연성 떨어짐)
세션 스토리지 외부화: Redis 같은 곳에 세션 저장(Spring Session Redis 등)
JWT로 무상태화: 서버에 세션을 두지 않음
확장성과 운영 안정성은 보통 2)나 3)이 더 좋습니다.

10) 운영 배포 구조를 설계한다면 어떤 구성이 현실적인가요?

대표적으로는:

정적 프론트: CDN/정적 호스팅(또는 Nginx)
백엔드 API: Spring Boot(WAS)
앞단: Nginx 또는 로드밸런서(HTTPS 종료, 라우팅, 보안)
데이터: DB + 필요하면 Redis(캐시/세션)
이 구조가 성능/보안/확장성 밸런스가 좋아서 가장 흔합니다.

Garbage Collection

awake123 — Wed, 7 Jan 2026 16:46:36 +0900

1. Garbage Collection 이란

프로그램이 사용하지 않게 된 메모리(객체)를 자동으로 찾아서 회수해 주는 메모리 관리 기능

자바처럼 객체를 new로 계속 만들면 힙(Heap)에 쌓이는데,
그 객체를 더 이상 참조(사용)하지 않으면 메모리를 계속 차지합니다.
GC는 이런 “도달 불가능(unreachable)” 객체를 정리해서 힙 공간을 회수합니다.

장점

메모리 해제 실수 방지(누수, 이중 해제 등)
개발 생산성 ↑

단점

GC가 돌 때 **일시 정지(STW: Stop-The-World)**가 발생할 수 있어 성능/지연에 영향
“GC가 알아서 해주겠지”로 설계하면 참조를 오래 잡고 있어서 메모리 사용량이 커질 수 있음

해당 개념이 실무에서 없다면

1) 진짜로 GC가 없는 환경이라면 (수동 메모리 관리)

GC가 없으면 “자동 청소”가 없어서, 아래를 개발자가 직접 책임져야 합니다.

메모리 누수(Leak): 할당하고 해제를 안 하면 점점 RAM 먹고 죽음
이중 해제(Double free): 같은 메모리를 두 번 해제 → 크래시/취약점
댕글링 포인터(Dangling pointer): 해제한 메모리를 다시 사용 → 미정의 동작
Use-after-free: 보안 이슈로도 이어짐
소유권(누가 해제 책임?) 설계가 코드 전반의 핵심이 됨

2) GC가 있지만, “없다고 생각하고” 개발한다면 (자바/코틀린/Go 등)

GC가 자동으로 해주긴 하지만, 개념을 모르면 실무에서 자주 터지는 게 있어요.

OOM(OutOfMemoryError): 참조를 오래 잡아두면 GC가 못 치움
예: static 컬렉션에 계속 쌓기, 캐시 무한 성장, 세션/리스너 미해제
지연/끊김(Stop-the-world): 트래픽 많은 서버에서 GC가 길어지면 응답이 튐
→ “가끔 2~5초 멈춤” 같은 장애 원인
성능 저하: 객체를 너무 많이/자주 만들면 GC가 바빠짐
예: 문자열/컬렉션 남발, 불필요한 박싱, 큰 객체 반복 생성
리소스 누수: 메모리 말고도
파일/소켓/DB커넥션 같은 건 GC가 “즉시” 닫아주지 않음
→ try-with-resources 같은 걸로 명시적으로 닫아야 함

즉

GC가 없으면: 메모리 생명주기 관리가 개발의 핵심 리스크가 됨
GC가 있는데 개념을 모르면: OOM/지연/성능/리소스 누수로 실무 장애가 나기 쉬움

자바 가상 머신

awake123 — Wed, 7 Jan 2026 08:47:38 +0900

spring의 예외처리방식

awake123 — Tue, 30 Dec 2025 17:44:31 +0900

1. spring의 예외처리방식

Spring에서 “예외 처리”는 크게 (1) 예외가 전파/롤백되는 방식과 (2) 컨트롤러 계층에서 HTTP 응답으로 바꾸는 방식으로 나눠서 본다.

1) 예외 전파 & 트랜잭션 롤백 규칙 (@Transactional)

Unchecked 예외(RuntimeException, Error)
→ 기본적으로 트랜잭션 롤백
Checked 예외(Exception)
→ 기본적으로 롤백 안 함 (커밋될 수 있음)

설정 가능:

@Transactional(rollbackFor = Exception.class) : 체크 예외도 롤백
@Transactional(noRollbackFor = 특정예외.class) : 런타임 예외여도 롤백 제외 가능

주의사항 :

예외를 try-catch로 잡고 삼키면(throw 안 하면) 스프링은 “정상 처리”로 보고 롤백 안 됩니다.
프록시 기반이라 같은 클래스 내부 self-invocation(자기 메서드 호출)에서는 @Transactional이 적용 안 되는 함정이 있습니다.

ex)

1-1. 기본 롤백 규칙: RuntimeException이면 롤백, Checked Exception이면 기본은 커밋

@Service
@RequiredArgsConstructor
public class MemberService {
    private final MemberRepository repo;

    @Transactional
    public void runtimeExceptionRollback() {
        repo.save(new Member("a"));
        throw new IllegalStateException("런타임 예외"); // ✅ 기본 롤백
    }

    @Transactional
    public void checkedExceptionDefaultCommit() throws Exception {
        repo.save(new Member("b"));
        throw new Exception("체크 예외"); // ⚠️ 기본은 롤백 안 함(커밋될 수 있음)
    }
}

1-2. 체크 예외도 롤백시키기: rollbackFor

@Transactional(rollbackFor = Exception.class)
public void checkedExceptionRollback() throws Exception {
    repo.save(new Member("c"));
    throw new Exception("체크 예외"); // ✅ 롤백
}

1-3. 예외를 잡아먹으면 롤백 안 됨

@Transactional
public void swallowedExceptionCommit() {
    repo.save(new Member("d"));
    try {
        throw new IllegalStateException("문제");
    } catch (Exception e) {
        // 예외를 밖으로 던지지 않으면 스프링 입장에선 "정상 종료"로 보고 커밋될 수 있음
    }
}

1-4. 잡고 싶으면 롤백 마킹을 직접

import org.springframework.transaction.interceptor.TransactionAspectSupport;

@Transactional
public void catchButRollback() {
    repo.save(new Member("e"));
    try {
        throw new IllegalStateException("문제");
    } catch (Exception e) {
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); // ✅ 강제 롤백
    }
}

1-5. @Transactional이 “안 먹는” 케이스(자기 자신 메서드 호출)

@Service
public class AService {

    @Transactional
    public void txMethod() {
        // 트랜잭션이 걸리길 기대
    }

    public void outer() {
        txMethod(); // ⚠️ 같은 클래스 내부 호출은 프록시를 안 거쳐서 트랜잭션이 적용 안 될 수 있음
    }
}

2) MVC/REST에서 예외를 HTTP 응답으로 변환하는 방식

A. @ExceptionHandler (컨트롤러 내부)

특정 컨트롤러에서만 예외 처리하고 싶을 때.

@ExceptionHandler(MyException.class)
반환은 ResponseEntity 혹은 객체(→ JSON)

B. @ControllerAdvice / @RestControllerAdvice (전역 처리)

프로젝트 전체 컨트롤러에 공통 적용.

실무에서 제일 흔한 패턴
예외별로 상태코드/메시지 통일 가능

C. ResponseStatusException / @ResponseStatus

throw new ResponseStatusException(HttpStatus.NOT_FOUND, "없음")
또는 커스텀 예외 클래스에 @ResponseStatus(HttpStatus.BAD_REQUEST) 지정

ex)

2-1. DTO 검증 실패 → MethodArgumentNotValidException → @RestControllerAdvice가 JSON 응답으로 변환

DTO

public class SignupRequest {
    @NotBlank(message = "사용자 ID는 필수입니다")
    @Size(min = 4, max = 20, message = "사용자 ID는 4~20자")
    private String userId;
}

Controller

@PostMapping("/api/members")
public ResponseEntity<Void> signup(@Valid @RequestBody SignupRequest req) {
    return ResponseEntity.ok().build();
}

전역 처리

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<Map<String, Object>> handle(MethodArgumentNotValidException e) {
        Map<String, String> fieldErrors = new LinkedHashMap<>();
        e.getBindingResult().getFieldErrors()
                .forEach(fe -> fieldErrors.put(fe.getField(), fe.getDefaultMessage()));

        Map<String, Object> body = new LinkedHashMap<>();
        body.put("code", "VALIDATION_ERROR");
        body.put("errors", fieldErrors);

        return ResponseEntity.badRequest().body(body);
    }
}

응답 예시(400)

{
  "code": "VALIDATION_ERROR",
  "errors": {
    "userId": "사용자 ID는 필수입니다"
  }
}

2-2. 비즈니스 예외(예: 중복 ID) → 커스텀 예외 → Advice에서 409로 변환

public class DuplicateUserIdException extends RuntimeException {
    public DuplicateUserIdException(String msg) { super(msg); }
}

@Service
public class MemberService {
    public void signup(SignupRequest req) {
        if (/*이미 존재*/) throw new DuplicateUserIdException("이미 사용 중인 ID입니다");
    }
}

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(DuplicateUserIdException.class)
    public ResponseEntity<Map<String, Object>> handleDup(DuplicateUserIdException e) {
        return ResponseEntity.status(409).body(Map.of("code","DUPLICATE_ID","message", e.getMessage()));
    }
}

3) Spring Boot 기본(자동) 예외 응답

별도 처리 안 하면 Boot가 기본 에러 핸들러로:

HTML(브라우저) 또는 JSON(API 요청) 형태로 에러 응답 생성
BasicErrorController + ErrorAttributes 기반
(보통 API 서버면 이 기본 응답 대신, Advice로 “에러 포맷”을 통일합니다.)

ex)

3-1. 예: 존재하지 않는 URL 호출

{
  "timestamp": "2026-01-01T06:00:00.000+00:00",
  "status": 404,
  "error": "Not Found",
  "path": "/no-such-api"
}

4) 필터/인터셉터/시큐리티에서의 예외

Filter 체인에서 터진 예외는 @ControllerAdvice로 안 잡히는 경우가 많습니다.
Spring Security는 보통:
- 인증 실패: AuthenticationEntryPoint
- 인가 실패: AccessDeniedHandler
  쪽에서 응답을 만들어줍니다.

주의사항:

**@ControllerAdvice는 ‘컨트롤러까지 들어온 예외’**를 주로 처리합니다.
필터(Filter)에서 터진 예외는 Advice가 못 잡는 경우가 많습니다.
Spring Security는 자체 진입점/핸들러로 응답을 만드는 흐름이 일반적입니다.

ex)

4-1. Filter에서 예외가 터짐 → Advice로 안 잡힘(대표 케이스)

@Component
public class ApiKeyFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res, FilterChain chain)
            throws ServletException, IOException {

        String apiKey = req.getHeader("X-API-KEY");
        if (apiKey == null) {
            throw new IllegalStateException("API KEY 없음"); // ⚠️ 여기서 터지면 ControllerAdvice가 못 받을 수 있음
        }
        chain.doFilter(req, res);
    }
}

해결 패턴(필터에서 직접 응답 작성)

if (apiKey == null) {
    res.setStatus(401);
    res.setContentType("application/json;charset=UTF-8");
    res.getWriter().write("{\"code\":\"UNAUTHORIZED\",\"message\":\"API KEY가 필요합니다\"}");
    return;
}

4-2. Interceptor에서 예외/차단 처리

@Component
public class AdminInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) throws Exception {
        if (!"admin".equals(req.getHeader("X-ROLE"))) {
            res.setStatus(403);
            res.setContentType("application/json;charset=UTF-8");
            res.getWriter().write("{\"code\":\"FORBIDDEN\",\"message\":\"권한 없음\"}");
            return false; // ✅ 여기서 요청 중단 (컨트롤러 미진입)
        }
        return true;
    }
}

등록:

@Configuration
public class WebConfig implements WebMvcConfigurer {
    private final AdminInterceptor adminInterceptor;

    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(adminInterceptor).addPathPatterns("/api/admin/**");
    }
}

4-3. Spring Security: 인증/인가 예외는 보통 여기서 응답을 만듦

인증 안 됨(401): AuthenticationEntryPoint
권한 없음(403): AccessDeniedHandler

@Component
public class RestAuthenticationEntryPoint implements AuthenticationEntryPoint {
    @Override
    public void commence(HttpServletRequest req, HttpServletResponse res, AuthenticationException ex)
            throws IOException {
        res.setStatus(401);
        res.setContentType("application/json;charset=UTF-8");
        res.getWriter().write("{\"code\":\"UNAUTHORIZED\",\"message\":\"로그인이 필요합니다\"}");
    }
}

@Component
public class RestAccessDeniedHandler implements AccessDeniedHandler {
    @Override
    public void handle(HttpServletRequest req, HttpServletResponse res, AccessDeniedException ex)
            throws IOException {
        res.setStatus(403);
        res.setContentType("application/json;charset=UTF-8");
        res.getWriter().write("{\"code\":\"FORBIDDEN\",\"message\":\"접근 권한이 없습니다\"}");
    }
}

Security 설정에 연결:

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http,
        RestAuthenticationEntryPoint entryPoint,
        RestAccessDeniedHandler deniedHandler) throws Exception {

    return http
        .csrf(csrf -> csrf.disable())
        .exceptionHandling(ex -> ex
            .authenticationEntryPoint(entryPoint)
            .accessDeniedHandler(deniedHandler)
        )
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/admin/**").hasRole("ADMIN")
            .anyRequest().permitAll()
        )
        .build();
}

2. 해당 예외 처리를 실무에서 사용하지 못할 경우.

1) 트랜잭션 롤백 규칙을 모르면 생기는 문제(정합성/데이터 오염)

부분 저장(Partial Commit)
예: 회원 저장은 됐는데, 권한/프로필/연관 테이블 저장 중 예외 → 롤백이 안 돼서 DB에 “반쯤 생성된 회원”이 남음.
체크 예외로 인해 커밋되는 사고
체크 예외는 기본 롤백이 아니라서, “실패했다고 생각했는데 DB엔 반영”되는 케이스가 생김.
try-catch로 예외를 삼켜서 커밋
에러를 로그만 찍고 정상 리턴 → 스프링은 성공으로 보고 커밋 → 나중에 데이터 꼬임이 누적.
재처리/복구 비용 증가
데이터가 한번 오염되면 운영에서 수작업 수정, 배치 복구, 고객 응대가 필요해짐.

2) MVC/REST 예외를 응답으로 변환 못하면 생기는 문제(프론트/QA/사용자 경험)

에러 응답 포맷이 제각각
어떤 API는 {message}, 어떤 API는 Boot 기본 {status,error,path}…
→ 프론트가 케이스별 파싱 분기 지옥 + 버그 증가.
필드 검증 에러를 제대로 못 줌
“아이디가 비었어요” 같은 정확한 안내 대신 그냥 500/400만 떨어짐
→ 사용자 이탈 + CS 증가.
상태코드가 엉망
중복인데 500, 권한없는데 200+메시지…
→ 프론트가 정상/에러 판단 못해서 화면/로직 꼬임.
디버깅 난이도 상승
QA가 재현해도 “왜 실패했는지” 정보가 없거나 매번 다름 → 수정 속도 느려짐.

3) Spring Boot 기본(자동) 에러 응답에만 의존하면 생기는 문제(보안/일관성/운영)

환경에 따라 메시지 노출이 달라짐
개발/운영 설정에 따라 stacktrace/exception 메시지가 노출되거나 숨겨짐 → 보안 리스크/혼선.
API 표준 계약이 깨짐
“우리 API는 항상 code/message/errors 준다” 같은 계약을 못 지킴 → 프론트/외부 연동 불안정.
로그/모니터링과 연결이 어려움
에러코드 체계가 없으니 대시보드에서 원인 분류(중복/검증/권한/서버오류)가 힘들어짐.

4) 필터/인터셉터/시큐리티 예외를 다루지 못하면 생기는 문제(인증/인가/장애)

401/403이 아니라 500이 나감
인증 실패가 서버 장애처럼 보이고, 프론트는 “로그인 유도” 대신 “오류 화면”을 띄움.
CORS/프리플라이트가 깨짐
필터에서 예외나 응답을 잘못 만들면 OPTIONS 요청이 실패 → 브라우저에서 아예 호출 자체가 막힘.
Security 예외 응답 포맷 불일치
일반 API는 {code,message}인데, 인증 실패만 기본 포맷/HTML로 내려감 → 프론트 처리 실패(토큰 만료 처리 등).
응답이 이미 커밋된 뒤 예외
필터/시큐리티 체인에서 예외 처리 미흡하면 “응답을 쓰다가 또 예외”가 터져 로그만 남고 클라이언트는 애매한 응답을 받음.

* try-catch에 과하게 의존하던가 비즈니스 로직에서 예외를 하나하나 처리할 경우

1) 코드 품질 문제

중복 폭발: 모든 메서드에 try { ... } catch (...) { ... }가 깔리면서 같은 응답 생성/로그/메시지 처리 코드가 반복됨.
관심사 섞임: 원래 로직(회원가입/주문/결제) + 에러 응답 포맷팅 + 로깅 + 상태코드 결정이 한 덩어리가 됨 → 유지보수 난이도 급상승.
읽기/리뷰 난이도 증가: 핵심 로직이 try-catch에 묻혀서 “이 API가 뭘 하는지” 파악이 느려짐. 실수도 늘어남.
일관성 붕괴: 어떤 곳은 400, 어떤 곳은 409, 어떤 곳은 200+message… 팀원이 늘수록 더 엉망이 됨.

2) 기능/정합성 문제(특히 트랜잭션)

예외 삼킴으로 커밋: 서비스에서 예외를 잡고 정상 리턴하면 스프링은 성공으로 보고 트랜잭션이 커밋될 수 있음 → “반쯤 저장된 데이터”가 남음.
롤백 조건 누락: 체크 예외/특정 예외에서 롤백이 필요해도 각 메서드에서 빠뜨리기 쉬움.
복구 불가능한 데이터 오염: 한번 꼬인 데이터는 나중에 발견되고, 수정 비용이 훨씬 큼(수동 수정/배치/CS).

3) 장애 대응/운영 문제

로그 품질이 나빠짐: 여기저기서 각각 log.error(...) 찍다 보면
- 같은 에러가 여러 번 찍히거나(중복 로그)
- 반대로 중요한 맥락(요청ID/사용자/에러코드)이 누락됨.
모니터링/통계가 안 됨: 전역 에러코드/상태코드 체계가 없으니 “검증오류가 많은지”, “권한오류 폭증인지”를 지표로 못 봄.
버그 수정 속도 저하: 에러 처리 로직이 분산돼 있어서 수정하려면 파일을 수십 군데 찾아다녀야 함.

4) 클라이언트(프론트/앱) 연동 문제

응답 포맷이 들쭉날쭉: 프론트가 케이스별 파싱 분기를 계속 추가하게 됨 → 프론트 버그/개발기간 증가.
HTTP 의미가 깨짐: “중복”인데 500, “권한 없음”인데 200…
→ 재시도/로그아웃/토스트 메시지 같은 UX 처리를 제대로 못 함.
국제화/메시지 정책 관리 불가: 메시지를 여기저기 하드코딩하면 문구 수정, 정책 변경(노출 수준 조정)이 거의 불가능해짐.

5) 보안/정보노출 리스크

예외 메시지 그대로 노출: try-catch에서 e.getMessage()를 그대로 내려주면 내부 테이블명/쿼리/스택 정보가 새어 나갈 수 있음.
필터/시큐리티 예외 대응 실패: 인증/인가에서 발생한 예외를 컨트롤러에서 처리하려다 못 잡고 500으로 터지는 케이스가 생김.

6) 테스트/확장 문제

테스트가 무의미해짐: 전역 처리라면 “예외 → 어떤 응답”이 일관되게 검증 가능한데, 분산 처리면 케이스마다 테스트를 새로 짜야 함.
요구사항 변경에 취약: “에러 포맷에 traceId 추가” 같은 변경이 오면 전역은 1곳 수정인데, 분산은 전부 수정.

즉 try-catch로 “개별 대응”하면 단기적으로는 빨라 보이지만, 실무에서는 정합성 사고(커밋/롤백) + 응답/상태코드 불일치 + 유지보수 지옥으로 비용이 크게 늘어납니다.

* try-catch를 사용해도 괜찮은것.

A. 외부 경계(네트워크/파일/외부 시스템) 호출

HTTP 호출(WebClient/RestTemplate), 메시지큐, 파일 IO, S3 업로드 등
이유: 여기서 터지는 예외는 도메인(비즈니스) 예외로 치환해야 내부 로직이 깔끔해짐

try {
    externalClient.send(...);
} catch (TimeoutException e) {
    throw new ExternalTimeoutException("외부 시스템 타임아웃", e);
} catch (Exception e) {
    throw new ExternalSystemException("외부 시스템 오류", e);
}

→ 그리고 @RestControllerAdvice에서 ExternalTimeoutException은 504, ExternalSystemException은 502/500 같은 식으로 통일.

B. 리소스 정리 / 보장 (close, unlock, 임시파일 삭제)

try-with-resources 사용이 정석
이유: “실패해도 반드시 정리”가 목적이지, 에러 응답을 만들 목적이 아님

C. “예외가 정상 흐름인” 케이스를 명확히 다룰 때(아주 제한적으로)

예: 캐시 읽기 실패하면 DB로 폴백

try {
    return cache.get(key);
} catch (Exception e) {
    log.warn("캐시 실패, DB로 폴백", e);
    return repo.find(...);
}

*try- catch를 쓰면 안되는 부분.

A. 컨트롤러에서 비즈니스 예외를 try-catch로 응답 만들기

문제: 포맷/상태코드가 컨트롤러마다 달라짐
정석: 컨트롤러는 얇게, 예외는 @RestControllerAdvice가 응답으로 변환

B. 서비스에서 예외를 잡고 “정상 리턴”

문제: 트랜잭션이 커밋될 수 있음(데이터 오염)
정석: 서비스는 예외를 던져서 실패를 명확히 만들 것

C. “모든 예외 catch(Exception)”로 뭉개기

문제: 원인 분류 불가 + 장애 탐지 늦어짐 + 디버깅 지옥
정석: 외부 경계에서만 필요한 범위로 잡고, 내부는 타입별로 처리

전체 예시

시나리오

요청: POST /api/members
검증: userId 필수, 4~20자
비즈니스: userId 중복이면 실패(409)
외부: 이메일 인증코드 발송(외부 시스템, 실패 가능)

권장 패턴

원칙

컨트롤러: try-catch 없음, 얇게
서비스: 비즈니스 예외는 던짐(런타임)
외부 호출은 try-catch로 치환(변환) 후 던짐
응답 포맷은 @RestControllerAdvice가 통일

1) DTO

public class SignupRequest {
    @NotBlank(message = "사용자 ID는 필수입니다")
    @Size(min = 4, max = 20, message = "사용자 ID는 4~20자")
    private String userId;

    @NotBlank(message = "이메일은 필수입니다")
    private String email;
}

2) 컨트롤러(try-catch 없음)

@PostMapping("/api/members")
public ResponseEntity<Void> signup(@Valid @RequestBody SignupRequest req) {
    memberService.signup(req);
    return ResponseEntity.status(201).build();
}

3) 서비스(비즈니스 규칙 + 외부 호출은 치환)

@Service
@RequiredArgsConstructor
public class MemberService {
    private final MemberRepository memberRepository;
    private final MailClient mailClient;

    @Transactional
    public void signup(SignupRequest req) {
        if (memberRepository.existsByUserId(req.getUserId())) {
            throw new DuplicateUserIdException("이미 사용 중인 ID입니다");
        }

        memberRepository.save(new Member(req.getUserId(), req.getEmail()));

        // 외부 시스템: 실패 가능 → try-catch로 도메인 예외로 치환 후 throw
        try {
            mailClient.sendVerificationCode(req.getEmail());
        } catch (Exception e) {
            throw new ExternalMailSendException("이메일 발송에 실패했습니다", e);
        }
    }
}

4) 전역 예외 처리(응답 통일)

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<?> handleValid(MethodArgumentNotValidException e) {
        Map<String, String> errors = new LinkedHashMap<>();
        e.getBindingResult().getFieldErrors()
                .forEach(fe -> errors.put(fe.getField(), fe.getDefaultMessage()));
        return ResponseEntity.badRequest().body(Map.of("code","VALIDATION_ERROR","errors",errors));
    }

    @ExceptionHandler(DuplicateUserIdException.class)
    public ResponseEntity<?> handleDup(DuplicateUserIdException e) {
        return ResponseEntity.status(409).body(Map.of("code","DUPLICATE_ID","message", e.getMessage()));
    }

    @ExceptionHandler(ExternalMailSendException.class)
    public ResponseEntity<?> handleExternal(ExternalMailSendException e) {
        return ResponseEntity.status(502).body(Map.of("code","MAIL_SEND_FAILED","message", e.getMessage()));
    }
}

비권장

특징

컨트롤러에서 try-catch로 응답을 직접 만듦
서비스에서 예외를 잡고 “정상 리턴” → 커밋/오염 위험
에러 포맷이 API마다 달라질 가능성 높음

1) 컨트롤러가 모든 걸 try-catch로 처리

@PostMapping("/api/members")
public ResponseEntity<?> signup(@Valid @RequestBody SignupRequest req) {
    try {
        memberService.signup(req);
        return ResponseEntity.status(201).body(Map.of("message","ok"));
    } catch (DuplicateUserIdException e) {
        return ResponseEntity.status(400).body("중복입니다"); // ⚠️ 409가 아니라 400, 포맷도 문자열
    } catch (Exception e) {
        return ResponseEntity.status(200).body("실패했지만 200"); // ⚠️ 상태코드 의미 붕괴
    }
}

문제점

중복인데 400, 심지어 어떤 곳은 200… 클라이언트 로직 꼬임
응답 포맷이 문자열/객체 뒤섞임 → 프론트 파싱 분기가 어려워짐

2) 서비스에서 예외 삼키기(정합성 사고 포인트)

@Transactional
public void signup(SignupRequest req) {
    try {
        if (memberRepository.existsByUserId(req.getUserId())) {
            throw new DuplicateUserIdException("중복");
        }
        memberRepository.save(new Member(req.getUserId(), req.getEmail()));
        mailClient.sendVerificationCode(req.getEmail());
    } catch (Exception e) {
        // ⚠️ 로그만 찍고 끝(또는 무시)
        // 여기서 메서드가 정상 종료되면 트랜잭션 커밋될 수 있음 → "반쯤 성공" 데이터 생성
    }
}

문제점

외부 메일 실패가 발생해도 회원은 저장됨(정책이 그게 아니라면 “데이터 오염”)
실패를 호출자가 알 수 없음(응답은 성공처럼 나갈 수 있음)

결론: try-catch는 “응답 만들기”가 아니라 “경계 처리”에만

외부 호출 실패를 의미 있는 도메인 예외로 변환
리소스 정리, 폴백

Q1. @Transactional에서 Runtime 예외는 롤백인데, Checked 예외는 왜 기본 롤백이 아닌가요?

A. 스프링의 기본 정책은 “프로그래밍 오류/예상치 못한 실패(Runtime)”는 롤백, “업무적으로 예상 가능한 예외(Checked)”는 호출자가 처리할 수도 있다고 보고 커밋될 수 있게 둔 겁니다. 그래서 Checked 예외도 롤백이 필요하면 rollbackFor로 명시합니다.

Q2. 서비스에서 try-catch로 예외를 잡아야 하는 경우에도 롤백이 되게 하려면 어떻게 하나요?

A. ① 잡고 다시 throw(도메인 예외로 치환해서 throw)하거나, ② 정말 잡고 끝내야 한다면 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()로 롤백 마킹합니다. 실무에서는 보통 “삼키지 말고 치환해서 던진다”를 기본으로 둡니다.

Q3. self-invocation 때문에 트랜잭션이 안 걸리면 실무에서 어떻게 해결하나요?

A. 가장 흔한 해결은 구조 분리입니다. 트랜잭션이 필요한 메서드를 다른 서비스 빈으로 분리해서 “프록시를 거치게” 만듭니다. 또는 호출 경로를 컨트롤러→서비스 빈으로 유지합니다(같은 클래스 내부 호출 피함). 특수하게 AspectJ weaving을 쓰는 방법도 있지만 일반적이지 않습니다.

Q4. 전역 @RestControllerAdvice를 쓰면 모든 예외를 다 거기서 처리하면 되나요?

A. 원칙적으로는 “컨트롤러 레벨 예외”는 전역 Advice에서 통일하는 게 맞지만, 필터/시큐리티 체인에서 발생한 예외는 Advice 범위를 벗어나기 쉬워서 401/403 같은 건 Security 핸들러(EntryPoint/DeniedHandler)에서 처리합니다. 즉 “레이어별로 책임이 다릅니다.”

Q5. 중복 ID 같은 비즈니스 예외를 409로 주는 이유는 뭔가요?

A. 409 Conflict는 “현재 리소스 상태와 충돌”을 표현하기에 적합합니다(이미 존재하는 ID로 생성 시도). 400으로 처리해도 동작은 하지만, 상태코드를 의미 있게 쓰면 프론트가 예외를 더 정확히 분기(중복 안내/재시도 금지 등)할 수 있습니다.

Q6. @Valid @RequestBody 말고 @RequestParam/@PathVariable 검증은 어떤 예외가 터지고 어떻게 처리하나요?

A. @Validated를 클래스/컨트롤러에 붙이고 @Min, @NotBlank 같은 검증을 파라미터에 걸면 보통 **ConstraintViolationException**이 발생합니다. 전역 @RestControllerAdvice에서 이 예외를 잡아 400으로 통일하고, violation 정보를 원하는 포맷으로 내려줍니다.

Q7. JSON이 깨졌거나 타입이 안 맞으면(예: age에 "abc") 검증 예외가 아니라 뭐가 터지나요?

A. 컨트롤러 진입 전 Jackson 파싱 단계에서 실패하므로 보통 HttpMessageNotReadableException(또는 그 내부 cause)이 발생합니다. 이건 검증 실패와 성격이 달라서 “요청 바디 형식 오류”로 400을 내려주고 메시지는 일반화하는 게 안전합니다.

Q8. 전역 핸들러에 @ExceptionHandler(Exception.class) 같은 마지막 처리기를 두면 뭐가 위험하죠?

A. 너무 넓게 잡으면 원인 분류가 어려워지고(모든 게 500), 실수로 비즈니스 예외까지 500으로 덮어버릴 수 있습니다. 그래서 “구체 예외 핸들러를 위에 두고”, 마지막 핸들러는 진짜 예측 불가 오류만 처리하게 하며, 응답 메시지는 일반화하고 상세 원인은 로그로 남깁니다.

Q9. 컨트롤러에서 응답 바디를 직접 쓰는 것 말고 “표준 에러 응답 DTO”를 만들어서 통일하려면 어떻게 하나요?

A. ErrorResponse(code, message, errors, timestamp, path, traceId) 같은 DTO를 만들고, 전역 핸들러와 Security 핸들러(EntryPoint/DeniedHandler)가 모두 동일 DTO를 반환하게 맞춥니다. 이렇게 하면 프론트가 항상 같은 규격으로 처리합니다.

Q10. 외부 메일 발송이 실패했을 때, “회원 저장은 커밋하고 메일은 나중에 재시도”하고 싶으면 어떻게 설계하나요?

A. 같은 트랜잭션 안에서 외부 호출 실패를 throw하면 저장이 롤백됩니다. 커밋을 유지하려면 트랜잭션을 분리해야 합니다. 대표 선택지는

회원 저장 커밋 후 **이벤트 발행(비동기)**로 메일 발송
장애 내구성이 더 필요하면 아웃박스 패턴(DB에 발송 작업을 기록하고 워커가 처리)
즉 “DB 정합성 트랜잭션”과 “외부 부수효과”를 분리합니다.

스프링 프레임 워크

awake123 — Mon, 22 Dec 2025 18:18:16 +0900

1. 스프링 프레임 워크란

**스프링 프레임워크(Spring Framework)**는
자바(Java) 기반 엔터프라이즈 애플리케이션을 효율적으로 개발하기 위한 오픈소스 프레임워크입니다.
핵심 목적은 객체 간 결합도를 낮추고(유연성↑), 반복 작업을 줄이며(생산성↑), 테스트와 유지보수를 쉽게 만드는 것입니다.

1) IoC (Inversion of Control, 제어의 역전)

객체를 개발자가 직접 new 하지 않음
스프링 컨테이너가 객체 생성과 생명주기를 관리
코드가 프레임워크에 덜 의존 → 변경에 강함

@Component
public class ServiceA {
    // 객체 생성 안 함
}

2) DI (Dependency Injection, 의존성 주입)

객체가 필요한 의존 객체를 외부에서 주입
결합도 감소, 테스트 용이

@RequiredArgsConstructor
@Service
public class OrderService {
    private final OrderRepository orderRepository;
}

3) AOP (Aspect Oriented Programming)

공통 관심사 분리
로깅, 트랜잭션, 보안 등을 핵심 로직과 분리

@Transactional
public void save() { }

스프링 vs 스프링 부트

Spring Framework
- 기능이 많고 유연하지만 설정이 복잡
Spring Boot
- 스프링을 쉽게 쓰게 만든 도구
- 자동 설정, 내장 서버, 빠른 시작

왜 스프링을 쓰는가 (현실적인 이유)

대규모 서비스에 검증됨
유지보수·테스트에 강함
생태계 방대 (JPA, Security, Batch 등)
국내·해외 채용 시장 사실상 표준

2. 스프링을 실무에서 사용하지 못한다면.

“스프링을 실무에서 사용하지 못한다면 → 백엔드 개발자로서 실무 투입이 매우 어렵다”
특히 국내 Java 백엔드 시장에서는 거의 불가능에 가깝습니다.

그 이유로는

1) 실무 요구 자체가 스프링 전제

대부분 채용 공고는 암묵적으로 아래를 기본값으로 둡니다.

Spring Boot
Spring MVC
Spring Data JPA
@Transactional
DI / IoC 이해

=> *“자바는 할 줄 압니다”*는
스프링을 못 쓰면 의미가 거의 없습니다.

2) 단순 문법 문제가 아님

스프링을 못 쓴다는 건 보통 이런 상태입니다.

@Service, @Repository 역할 구분 불가
트랜잭션 경계 설정 못함
DI 설계 감각 없음
테스트 코드 작성 불가
계층 분리 개념이 흐림

이건 툴 미숙이 아니라
=>서버 애플리케이션 설계 역량 부족으로 평가됩니다.

3) “다른 프레임워크 하면 되지 않나요?”의 현실

이론적으로는 가능하지만 현실은 다릅니다.

대안현실

순수 Servlet	실무 거의 없음
Node.js	Java 포지션과 분리
Python (Django)	주니어 진입 장벽 높음
Go	신입 거의 안 씀

=> Java를 선택했다면 스프링은 선택이 아니라 필수입니다.

3.스프링이 제공하는 최적화와 효율성

1) 객체 생성·관리 최적화 (IoC / DI)

문제 (스프링 없을 때)

객체 생성 위치가 분산됨
new 남발 → 결합도 증가
교체·테스트 비용 폭증

스프링의 최적화

싱글톤 컨테이너 기본 관리
객체 재사용 → 메모리 절약
의존성 변경 시 코드 수정 최소화

@Service // 기본 싱글톤
public class OrderService { }

=>객체 생성 비용 + 관리 비용 감소

2) 트랜잭션 처리 최적화

문제

try-catch + commit/rollback 직접 관리
예외 누락 시 데이터 꼬임
코드 가독성 최악

스프링의 최적화

선언적 트랜잭션 (@Transactional)
런타임 예외 기준 자동 rollback
커넥션 효율적 재사용

@Transactional
public void saveOrder() { }

=>정합성 유지 + 개발자 실수 제거

3) AOP 기반 공통 로직 분리

문제

로깅, 권한, 시간 측정 코드 중복
핵심 로직 가독성 붕괴

스프링의 최적화

프록시 기반 AOP
핵심 비즈니스 로직 집중

@Around("execution(* service..*(..))")

=>중복 제거 + 코드 응집도 상승

4) 데이터 접근 성능 최적화 (Spring Data JPA)

제공 최적화 요소

1차 캐시 (영속성 컨텍스트)
쓰기 지연 (Batch Insert)
변경 감지 (Dirty Checking)

member.setName("변경");
// update 쿼리 자동 처리

=>불필요한 SQL 감소 = DB 부하 감소

5) 웹 요청 처리 효율 (Spring MVC)

최적화 포인트

DispatcherServlet 중앙 제어
스레드 재사용 (서블릿 컨테이너)
파라미터 바인딩 자동화

@GetMapping("/users/{id}")
public UserDto get(@PathVariable Long id)

=>요청 처리 비용 감소 + 코드 간결

6) 예외 처리 & 안정성 최적화

전역 예외 처리 (@ControllerAdvice)
일관된 에러 응답
장애 지점 추적 용이

=>운영 안정성 ↑ / 장애 대응 시간 ↓

7) 테스트 효율 극대화

DI 기반 Mock 주입 가능
단위 테스트/통합 테스트 분리

@MockBean
private UserRepository userRepository;

=>테스트 작성 비용 감소 + 품질 상승

4. 면접관이 해당 질문을 한다면 그 의도는.

1) “이 사람이 스프링을 써본 사람인가?”

의도: 공식 문서 암기 vs 실무 사용 경험 구분
보고 싶은 신호
- “CPU 최적화” 같은 추상적 얘기 X
- 트랜잭션, 객체 생명주기, 중복 제거 같은 현실적 얘기 O

=> 실무자는
“스프링의 최적화는 성능보다 실수 방지·유지보수 비용 감소 쪽이 큽니다”라고 답함

2) “프레임워크의 역할을 과대평가하지는 않는가?”

의도: 스프링을 만능으로 보는지 확인
보고 싶은 신호
- “스프링이 알아서 성능 다 잡아줍니다” X
- “설계를 단순화해 잘못된 최적화를 줄여준다” O

=> 면접관은
**‘스프링이 뭘 해주고, 뭘 안 해주는지’**를 아는지를 봅니다.

3) “이 사람이 왜 이 구조를 쓰는지 알고 있나?”

의도: 관성적인 사용자인지 판단
보고 싶은 신호
- DI → 결합도 감소
- AOP → 공통 로직 분리
- @Transactional → 정합성·커넥션 관리

=> “왜 쓰는지” 설명 못 하면
복붙 개발자로 분류됩니다.

4) “문제 생겼을 때 원인 추적이 가능한가?”

의도: 장애 대응 가능성 평가
보고 싶은 신호
- 프록시/AOP/트랜잭션 경계 이해
- “이 지점에서 프록시 때문에 동작이 달라질 수 있다”는 인식

=> 이 질문은
**‘운영 중 문제를 혼자 해결할 수 있나?’**를 보는 질문입니다.

5) “우리 팀에 바로 투입해도 되는가?”

의도: 온보딩 비용 계산
합격 신호
- 스프링이 개발 속도·안정성·협업 효율을 높인다는 설명
- 코드 품질 관점의 최적화 언급

전원희씨 rest api 피드백

awake123 — Mon, 22 Dec 2025 15:05:24 +0900

개발자 : 전원희

프로젝트 : ReDeal - 중고 거래 플랫폼

1. 로그아웃시 알림 창이 다수 발생.

-> 시연 도중 발생한거라 캡쳐는 없지만 다수 발생하는것을 확인 했습니다.

2. 엔티티 사용시 createdDate과 updatedDate는 공통 엔티티로 뺄수 있을것 같습니다.

3. status 사용시 string보다 enum을 사용하는게 좋을 것 같습니다.

4. 추가적으로 status는 "판매중" , "완료" 같은 한글보다 영어나 코드로 저장하는것이 더 나을것 같습니다.

5. 삭제시 이미 한번 조회를 해온 후라 굳이 ID기반으로 삭제할 필요는 없을 것 같습니다.

의문점

1.로그인 / 회원가입시 미리 데이터가 입력되어있는 부분들이 있었는데 왜 그런건지?

2. 현재 git 상 엔티티에 OneToMany나 ManyToOne등의 연관관계 매핑이 안보이는데 의도된 사안인지?