맨땅에 코딩

네트워크 - 쿠키(Cookie)

jiubuntu — Mon, 20 Jul 2026 20:55:55 +0900

HTTP는 무상태 프로토콜이라 서버가 클라이언트 상태를 기억하지 못한다고 앞서 정리했었는데, 이 문제를 실무에서 가장 널리 해결하는 방법이 바로 쿠키입니다. 이에 대한 내용을 정리해보려고 합니다.

1. Set-Cookie와 Cookie

Set-Cookie: 서버 → 클라이언트로 쿠키를 전달(응답 헤더)
Cookie: 클라이언트가 서버로부터 받은 쿠키를 저장해두었다가, 이후 요청 시 서버로 함께 전달(요청 헤더)

2. 쿠키의 사용처와 주의점

사용처

사용자 로그인 세션 관리
광고 정보 트래킹

주의점

쿠키 정보는 요청할 때마다 항상 서버로 전송되기 때문에, 쿠키에 담는 데이터가 많아질수록 네트워크 트래픽이 늘어나기 때문에 세션 id, 인증 토큰 정도의 최소한의 정보만 담는 것이 좋음
서버에 전송할 필요 없이 브라우저 내부에만 데이터를 저장하고 싶다면 쿠키 대신 웹 스토리지(localStorage, sessionStorage) 사용 고려
주민번호, 신용카드 번호 같은 보안에 민감한 데이터는 절대 저장 X.

3. 쿠키의 생명주기 - Expires, max-age

속성	설명
expires	만료 날짜/시각을 직접 지정 (예: expires=Sat, 26-Dec-2020 04:39:21 GMT), 해당 시점이 되면 쿠키 삭제
max-age	초 단위로 유효 시간 지정 (예: max-age=3600 → 3600초). 0이나 음수를 지정하면 즉시 쿠키 삭제

이 값의 지정 여부에 따라 쿠키의 종류도 나뉩니다.

세션 쿠키: 만료 날짜를 생략하면 브라우저를 종료할 때까지만 유지
영속 쿠키: 만료 날짜(expires/max-age)를 지정하면 해당 시점까지 유지

4. 쿠키의 유효 범위 - Domain, Path

Domain은 쿠키가 어떤 도메인까지 접근 가능한지를 결정합니다.

명시한 경우 (domain=example.org): 지정한 도메인은 물론, dev.example.org 같은 서브 도메인에서도 쿠키 접근 가능
생략한 경우: 쿠키를 생성한 현재 문서 기준 도메인에서만 접근 가능하며, 서브 도메인에서는 접근 불가

Path는 쿠키가 적용되는 URL 경로 범위를 결정합니다.

지정한 경로와 그 하위 경로에서만 쿠키에 접근 가능
일반적으로 path=/ (루트)로 지정해 모든 경로에서 사용 가능하게 함
예를 들어 path=/home으로 지정하면:
- /home, /home/level1, /home/level1/level2 → 접근 가능
- /hello → 접근 불가능 (경로가 겹치지 않음)

5. 쿠키 보안 - Secure, HttpOnly, SameSite

속성	동작
Secure	기본적으로 쿠키는 http/https를 구분하지 않고 전송되지만, Secure를 적용하면 https인 경우에만 전송됨
HttpOnly	자바스크립트(document.cookie)로 쿠키에 접근하지 못하게 막음. HTTP 전송에만 사용
SameSite	요청을 보낸 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송

6. 정리

쿠키는 무상태인 HTTP에서 로그인 세션 같은 상태를 유지하기 위한 대표적인 수단입니다. 다만 요청마다 자동으로 서버에 전송된다는 특성 때문에 트래픽과 보안 이슈가 함께 따라오므로, 최소한의 정보만 담고, Domain/Path로 범위를 제한하고, Secure/HttpOnly/SameSite로 보안을 강화하는 것을 권장합니다.

네트워크 - HTTP 헤더 정리

jiubuntu — Mon, 20 Jul 2026 20:45:10 +0900

HTTP 헤더는 HTTP 메시지를 전송하는 데 필요한 모든 부가 정보를 담습니다. 어떤 형식의 데이터를 보내는지, 클라이언트가 어떤 응답을 선호하는지, 인증은 어떻게 할지 등이 전부 헤더에 담깁니다.

1. 헤더 분류

HTTP 헤더는 적용 범위에 따라 크게 4가지로 분류됩니다.

분류	설명	예시
General 헤더	메시지 전체에 적용되는 정보	Connection: close
Request 헤더	요청에 대한 정보	User-Agent: Mozilla/5.0 (Macintosh; ..)
Response 헤더	응답에 대한 정보	Server: Apache
Representation 헤더	표현 데이터 바디에 대한 정보	Content-Type: text/html, Content-Length: 3423

2. 표현(Representation) 헤더

표현 헤더는 주고받는 실제 데이터(바디)의 속성을 설명하는 헤더입니다.

Content-Type: 표현 데이터의 형식 (예: text/html, application/json)
Content-Encoding: 표현 데이터의 압축 방식. 데이터를 전송하는 쪽에서 압축을 수행한 뒤 이 헤더를 추가해서, 받는 쪽이 어떤 방식으로 압축이 되어있는지 알고 압축을 해제할 수 있게 해줌.
Content-Language: 표현 데이터가 어떤 자연 언어(한국어, 영어 등)로 작성되었는지 표현
Content-Length: 표현 데이터의 길이(바이트 수)

3. 콘텐츠 협상 (Content Negotiation)

콘텐츠 협상은 클라이언트가 서버에게 자신이 선호하는 표현 방식을 요청하는 것입니다.

Accept: 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset: 클라이언트가 선호하는 문자 인코딩 전달
Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 전달
Accept-Language: 클라이언트가 선호하는 자연 언어 전달

협상의 우선순위: Quality Values(q)

클라이언트가 여러 값을 나열할 때는 Quality Values(q) 값으로 우선순위를 표현합니다.

q 값은 0~1 사이이며, 값이 클수록 우선순위가 높음
q 값을 생략하면 기본값은 1

예를 들어 다음과 같은 Accept-Language 헤더가 있다면:

Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

우선순위는 다음과 같이 정해지게 됩니다.

순위	값	비고
1	ko-KR	q 생략 → 기본값 1
2	ko	q=0.9
3	en-US	q=0.8
4	en	q=0.7

4. 전송 방식 4가지

HTTP는 상황에 따라 데이터를 다른 방식으로 전송할 수 있습니다.

전송방식	특징
단순 전송	Content-Length를 알고 있을 때 한 번에 전송
압축 전송	Content-Encoding으로 압축 방식을 명시하고 압축해서 전송
분할 전송	Transfer-Encoding: chunked를 사용해 데이터를 여러 조각으로 나누어 전송
범위 전송	클라이언트가 원하는 범위(Range)만 지정해서 요청/응답

5. 일반 정보 헤더

Referer: 이전 웹페이지의 주소가 담기는 헤더로, 주로 유입 경로 분석에 활용
User-Agent: 클라이언트의 애플리케이션(웹 브라우저 등) 정보를 담음. 어떤 브라우저 환경에서 장애가 발생하는지 로그로 파악할 때 유용함
Server: 요청을 처리하는 origin 서버의 소프트웨어 정보를 담음
Date: 메시지가 생성된 날짜와 시각을 담음
Host: 요청한 호스트(도메인) 정보를 담으며, 요청 시 필수값. 하나의 서버가 여러 도메인을 처리하는 가상 호스팅 환경에서, 어떤 도메인으로 온 요청인지 구분하기 위해 반드시 필요.

6. 인증 헤더

Authorization: 클라이언트의 인증 정보를 서버에 전달하는 헤더
WWW-Authenticate: 리소스에 접근하기 위해 필요한 인증 방법을 정의하는 헤더 (서버가 401 응답과 함께 내려줌)

네트워크 - HTTP의 특징과 속성

jiubuntu — Mon, 20 Jul 2026 20:28:44 +0900

HTTP의 기본 구조와 특징, 그리고 HTTP 메서드가 갖는 세 가지 속성(안전, 멱등성, 캐시 가능)을 정리해보려고 합니다.

1. HTTP는 클라이언트-서버 구조

HTTP(HyperText Transfer Protocol)는 기본적으로 클라이언트가 요청을 보내고, 서버가 응답을 돌려주는 단방향 요청-응답 구조로 동작합니다. 브라우저(클라이언트)가 서버에 요청하면, 서버는 그에 맞는 데이터를 응답으로 돌려주는 방식입니다.

2. HTTP의 두 가지 핵심 특징

무상태 프로토콜 (Stateless)

서버가 클라이언트의 이전 요청 상태를 기억하지 않는다는 뜻입니다. 각 요청은 독립적으로 처리되며, 서버 입장에서는 매번 처음 보는 요청처럼 취급됩니다.

예시: 온라인 쇼핑몰에서 로그인을 한 뒤 상품 목록 페이지로 이동했다고 가정해봅시다. 만약 HTTP가 완전히 무상태라면, 서버는 상품 목록을 요청받는 순간 이 사람이 아까 로그인한 사람이라는 사실을 전혀 알지 못합니다. 그래서 매 요청마다 로그인 여부를 다시 증명해야 하는데, 이를 해결하기 위해 실무에서는 쿠키나 세션, 토큰(JWT) 같은 별도의 방법으로 클라이언트 상태를 서버 혹은 클라이언트 쪽에 저장해서 활용합니다.

무상태의 장점은 서버가 클라이언트 상태를 신경 쓰지 않아도 되기 때문에 서버를 자유롭게 늘리거나 줄이는 확장(스케일 아웃)이 쉬워진다는 점입니다.

비연결성 (Connectionless)

클라이언트와 서버가 요청-응답을 주고받은 뒤에는 연결을 유지하지 않고 바로 끊어버리는 특징입니다.

예시: 하나의 웹페이지를 열 때 HTML 문서, CSS 파일, 이미지 여러 장 등 수십 개의 리소스를 요청해야 합니다. 원칙적으로 비연결성을 따르면 이 리소스 하나하나를 요청할 때마다 매번 새로 연결을 맺고, 응답을 받은 뒤 바로 연결을 끊는 것을 반복해야 합니다. 이렇게 되면 매번 TCP 연결(3-way handshake)을 새로 맺어야 하니 자원 낭비가 심해지는데, 이 문제를 완화하기 위해 실제로는 HTTP의 Keep-Alive 같은 기법으로 일정 시간 동안 연결을 유지하며 여러 요청을 처리하도록 보완하고 있습니다.

3. HTTP 메서드가 갖는 세 가지 속성

HTTP 메서드(GET, POST, PUT, PATCH, DELETE 등)는 각각 안전(Safe), 멱등(Idempotent), 캐시 가능(Cacheable) 이라는 세 가지 속성을 기준으로 구분할 수 있습니다.

안전(Safe)

요청을 보내도 서버의 상태(데이터)를 변경하지 않는 성질을 말합니다. 즉, 조회만 할 뿐 아무것도 바꾸지 않는다는 뜻입니다.

GET, HEAD → 안전함 (단순 조회이므로 리소스를 변경하지 않음)
POST, PUT, PATCH, DELETE → 안전하지 않음 (리소스를 생성/수정/삭제하므로 상태가 변경됨)

멱등(Idempotent)

같은 요청을 한 번 보내든 여러 번 반복해서 보내든 결과가 동일하게 유지되는 성질입니다. 여기서 결과가 같다는 것은 서버에 저장된 리소스의 최종 상태가 같다는 의미이며, 요청 중간에 발생할 수 있는 동시성 문제(다른 사용자의 요청이 끼어드는 것 등 외부 요인)는 고려하지 않습니다.

GET, PUT, DELETE → 멱등함
- GET: 여러 번 조회해도 결과는 동일
- PUT: 특정 리소스를 통째로 같은 값으로 덮어쓰는 것이므로, 여러 번 반복해도 최종 상태는 같음
- DELETE: 같은 리소스를 여러 번 삭제 요청해도 결과적으로 리소스가 없는 상태는 동일
POST → 멱등하지 않음
- 예를 들어 게시글을 작성하는 POST 요청을 두 번 보내면 게시글이 두 개 생성되므로, 요청할 때마다 결과(서버 상태)가 달라짐

캐시 가능(Cacheable)

응답 결과를 캐시(임시 저장)해서 재사용할 수 있는지를 나타내는 속성입니다. 캐시가 가능하면 매번 서버에 요청을 보내지 않고 저장해둔 응답을 재활용할 수 있어 성능상 이점이 큽니다.

주로 GET, HEAD 메서드에 캐시가 사용. 조회 요청의 응답은 자주 재사용될 가능성이 높기 때문임
POST, PATCH도 스펙상으로는 캐시가 가능하도록 정의되어 있지만, 응답 내용이 매번 달라지는 경우가 많고 실제로 이를 지원하는 형태로 구현하는 경우는 많지 않음.

4. 정리

메서드	안전	멱등	캐시가능
GET	O	O	O
HEAD	O	O	O
POST	X	X	조건부(실무에서는 거의 사용 안 함)
PUT	X	O	X
PATCH	X	X	조건부(실무에서는 거의 사용 안 함)
DELETE	X	O	X

네트워크 - IP(Internet Protocol) 그리고 TCP와 UDP

jiubuntu — Mon, 20 Jul 2026 20:18:46 +0900

IP(인터넷 프로토콜)한계와, 그 한계를 TCP가 어떻게 보완하는지, 그리고 UDP는 왜 다른 선택을 했는지 정리해보려고 합니다.

1. 인터넷 프로토콜 스택은 4계층으로 이루어져 있다

우리가 인터넷으로 데이터를 주고받을 때, 실제로는 여러 계층의 프로토콜이 순서대로 데이터를 감싸고 벗기며 동작하게 됩니다.

프로토콜 4계층을 표로 정리해보자면 다음과 같습니다.

계층	이름	프로토콜/예시	역할
4	애플리케이션 계층	HTTP, FTP, DNS	실제 우리가 사용하는 서비스 데이터(웹 문서 등)를 생성
3	전송 계층	TCP, UDP	포트를 이용해 프로세스 간 데이터 전달, 신뢰성 제어
2	인터넷 계층	IP	목적지 IP 주소까지 패킷을 전달(라우팅)
1	네트워크 인터페이스 계층	이더넷, LAN 드라이버, 물리 장치	실제 케이블/신호로 데이터를 전송

데이터를 보낼 때는 4계층 → 1계층 순으로 각 계층의 헤더가 씌워지고(캡슐화), 받는 쪽에서는 1계층 → 4계층 순으로 헤더를 하나씩 벗겨내며(역캡슐화) 원래 데이터를 복원하게 됩니다.

2. IP(인터넷 프로토콜)만으로는 부족하다

인터넷 계층의 IP는 패킷을 목적지까지 전달하는 역할을 하지만, 딱 여기까지만 책임집니다. IP 패킷에는 출발지/목적지 IP 주소 정보만 있을 뿐, 다음과 같은 정보가 빠져 있습니다.

포트 정보 없음: 같은 컴퓨터 안에서 어떤 프로세스(애플리케이션)에게 데이터를 전달해야 하는지 알 수 없다.
순서 정보 없음: 패킷을 여러 개로 나눠 보내도, 도착한 순서가 보낸 순서와 같다는 보장이 없다.
전송 신뢰성 없음: 패킷이 중간에 소실되거나 유실되어도 IP 자체는 이를 감지하거나 재전송하지 않다.

즉, IP는 신뢰할 수 없는 프로토콜이기 때문에 전송 계층의 도움이 필요합니다.

3. TCP: 가상의 연결로 신뢰성을 보장한다

TCP(Transmission Control Protocol)는 IP가 채우지 못한 빈틈을 메워주는 전송 계층 프로토콜입니다. TCP 세그먼트에는 다음 정보가 담겨 있습니다.

출발지 포트 / 목적지 포트
전송 제어 정보(플래그, 윈도우 크기 등)
순서(Sequence) 정보

이 세그먼트가 다시 IP 패킷 안에 담겨서 전송되기 때문에, 최종적으로는 IP 패킷 안에 TCP 세그먼트가 들어있고, 그 안에 실제 데이터가 들어있는 구조가 됩니다.

TCP의 대표적인 특징 중 하나가 3-way handshake 인데, 실제로 물리적인 회선이 연결되는 것은 아니지만, 통신을 시작하기 전에 서로 연결할 준비가 되었는지 확인하는 가상의 연결 과정입니다.

3-way handshake 과정

	단계	플래그	설명
1	클라이언트 → 서버	SYN	클라이언트가 연결을 요청하며 SYN(동기화) 패킷 전송
2	서버 → 클라이언트	SYN ACK	서버가 요청을 수락하고, 자신도 SYN을 보내며 동시에 클라이언트의 SYN에 대한 ACK(응답) 전송
3	클라이언트 → 서버	ACK	클라이언트가 서버의 SYN에 대한 ACK를 전송하며 연결 완료

이 과정을 통해 양쪽 모두 상대방이 내 요청을 받았고, 통신할 준비가 되었다는 것을 서로 확인한 뒤에 데이터 전송을 시작합니다. 이 덕분에 TCP는 순서 보장과 데이터 전달 신뢰성을 확보할 수 있습니다.

4. UDP: 연결 없이, 단순하고 빠르게

UDP(User Datagram Protocol)는 TCP와 정반대의 선택을 한 프로토콜입니다.

3-way handshake 같은 연결 과정이 없음
순서 보장이 없음
전송 신뢰성 보장이 없음

이렇게만 보면 단점처럼 보이지만, 사실 이것이 UDP의 핵심 장점이기도 합니다. 가상 연결 과정 자체가 없다 보니 구조가 단순하고, 그만큼 속도가 빠릅니다.

UDP는 IP와 거의 비슷한 수준의 기능만 제공하는데, IP에 없는 다음 두 가지 정보만 추가로 가지고 있습니다.

포트 정보: 어떤 프로세스로 전달할지 구분 가능
체크섬(checksum): 데이터가 훼손되지 않았는지 검증하는 최소한의 무결성 체크

5. TCP vs UDP, 언제 무엇을 쓸까?

구분	TCP	UDP
연결 방식	3-way handshake(가상 연결)	연결 과정 없음
순서 보장	O	X
전송 신뢰성	O (재전송, 흐름/혼잡 제어)	X
속도	상대적으로 느림	상대적으로 빠름
대표 활용	웹(HTTP), 파일 전송, 이메일	실시간 스트리밍, 온라인 게임, DNS

정리하면, IP는 일단 목적지로 보내기만 담당하는 최소한의 프로토콜이고, 그 위에서 TCP는 신뢰성과 순서를, UDP는 속도와 단순함을 각각 선택한 전송 계층 프로토콜이라고 볼 수 있습니다.

Java - 돈 계산에 BigDecimal을 써야 하는 이유

jiubuntu — Mon, 29 Jun 2026 11:58:59 +0900

프로젝트를 진행하면서 돈과 관련된 필드는 BigDecimal을 사용했었는데 ,

이 글에서는 double로 돈계산을 할 때 왜 위험한지, BigDecimal이 정확히 어떤 문제를 해결해주는지, 그리고 BigDecimal을 사용할때 마주칠 수 있는 주의점을 코드로 직접 확인하며 정리해보려고 합니다.

1. double의 함정: 2진법은 10진 소수를 정확히 표현하지 못한다

double a = 0.1;
double b = 0.2;
System.out.println(a + b);
// 결과: 0.30000000000000004

double은 IEEE 754 이진 부동소수점 방식으로 숫자를 저장합니다. 컴퓨터는 모든 실수를 2의 거듭제곱의 합으로 표현하는데, 0.1처럼 흔한 10진 소수도 2진법으로는 무한소수가 되어버립니다. 10진법에서 1/3이 0.333...으로 끝나지 않는 것과 같은 원리입니다. 결국 컴퓨터는 이 무한소수를 어느 지점에서 끊어서 근사값으로 저장하고, 그 결과 아주 작은 오차가 생깁니다.

이 오차는 한 번이면 무시할 수 있을 정도로 작지만, 연산이 누적되면 커집니다.

double sum = 0;
for (int i = 0; i < 10; i++) {
    sum += 0.1;
}
System.out.println(sum);
// 결과: 0.9999999999999999

금액을 더하고 곱하고 나누는 연산이 반복되는 결제·정산 시스템에서, 이런 오차는 "장부가 1원 안 맞는" 형태의 실제 버그로 이어질 수 있습니다.

2. BigDecimal을 쓴다고 끝이 아니다

여기서 주의할 점은 BigDecimal을 쓰는 것 자체가 중요한 게 아니라, 어떻게 생성하느냐가 중요합니다.

BigDecimal wrong = new BigDecimal(0.1);
System.out.println(wrong);
// 결과: 0.1000000000000000055511151231257827021181583404541015625

BigDecimal right1 = new BigDecimal("0.1");
BigDecimal right2 = BigDecimal.valueOf(0.1);
System.out.println(right1); // 0.1
System.out.println(right2); // 0.1

new BigDecimal(double) 생성자에 double 리터럴을 그대로 넘기면, 이미 부동소수점으로 깨져버린 값을 그대로 가져와서 BigDecimal로 감싸는 것뿐입니다. BigDecimal은 오차를 자동으로 없애주는 객체가 아니라, 10진수를 정확하게 표현할 수 있는 자료구조일 뿐입니다. 이미 깨진 값을 넣으면 깨진 값 그대로 보존됩니다.

그래서 사용규칙은 명확합니다.

돈 관련 값은 항상 String으로 받아 new BigDecimal("19.99")로 생성하거나, double에서 변환해야 한다면 BigDecimal.valueOf(double)을 사용해야 합니다. new BigDecimal(double)은 절대 쓰지 않아야 합니다.

3. BigDecimal이 정확한 이유: 내부 구조 자체가 다르다

double이 2의 거듭제곱 분수로 값을 표현하는 반면, BigDecimal은 내부적으로 BigInteger unscaledValue와 int scale 두 값으로 숫자를 표현합니다. 예를 들어 19.99는 unscaledValue = 1999, scale = 2로 저장되어 1999 × 10⁻²를 의미합니다.

10진수 기반이기 때문에 10진 소수를 손실 없이 정확히 표현할 수 있어서, 2진법으로 변환하는 과정 자체가 없으니, 애초에 오차가 생길 여지가 없습니다.

BigDecimal p = new BigDecimal("19.99");
BigDecimal q = new BigDecimal("3");
System.out.println(p.multiply(q));
// 결과: 59.97

4. equals() 주의 : 값이 같아도 false가 나올 수 있다

BigDecimal x = new BigDecimal("1.0");
BigDecimal y = new BigDecimal("1.00");

System.out.println(x.equals(y));     // false
System.out.println(x.compareTo(y) == 0); // true

BigDecimal.equals()는 값뿐 아니라 scale(소수점 자릿수)까지 같아야 true를 반환합니다. 1.0과 1.00은 수학적으로 같은 값이지만, equals() 기준으로는 다르다고 판단합니다.

5. 나눗셈은 반올림 정책을 강제로 명시해야 한다

BigDecimal total = new BigDecimal("100");
BigDecimal parts = new BigDecimal("3");

total.divide(parts);
// ArithmeticException: Non-terminating decimal expansion;
// no exact representable decimal result.

100을 3으로 나누면 33.333...처럼 무한소수가 됩니다. BigDecimal은 이를 정확히 표현할 수 없으면 예외를 던져서, 반올림 방식을 직접 선택하도록 강제합니다.

total.divide(parts, 2, RoundingMode.HALF_UP);
// 33.33

이 부분이 double과 가장 본질적으로 다른 지점입니다. double은 그냥 알아서 (잘린) 근사값을 내놓고 끝나지만, BigDecimal은 어떤 방식으로 반올림할지를 코드에서 명시적으로 선택하게 만듭니다.

돈 계산에서 이게 중요한 이유는, 반올림 방식이 세금 계산·포인트 적립·환율 변환처럼 법적·회계적으로 정해져 있는 경우가 많기 때문입니다. 같은 코드베이스 안에서도 계산 종류마다 다른 반올림 규칙이 필요할 수 있는데, 이를 암묵적으로 처리하면 나중에 정산 불일치가 생겼을 때 어디서 얼마가 어떻게 반올림됐는지 추적이 거의 불가능해집니다.

정리

BigDecimal을 쓰는 이유는 크게 두 가지

부동소수점 오차 방지 : double은 2진법 한계로 10진 소수를 정확히 표현하지 못하지만, BigDecimal은 10진수 기반이라 정확
반올림 정책의 명시적 통제 : 나눗셈처럼 무한소수가 나오는 연산에서 반올림 방식을 코드 차원에서 강제로 선택하게 만들어, 암묵적 반올림으로 인한 회계 불일치 방지

JPA 연관관계 매핑 - @OneToOne

jiubuntu — Sun, 28 Dec 2025 22:13:54 +0900

JPA를 사용하는 프로젝트를 진행하면서 @OneToOne 연관관계 매핑을 하는 경우가 종종 발생했는데,

다대일이나 일대다 관계보다 고려할 것이 많아

엔티티를 설계에 어려움을 겪으며 얻은 지식과 경험을 작성해 보려고 합니다.

먼저

상품, 그리고 상품에 대한 재고 엔티티가 있다고 가정을 해보겠습니다.

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "product_id")
    private Long id;
    
    private String name;
}

@Entity
public class Stock {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "stock_id")
    private Long id;
}

이 2개의 엔티티가 있을때
1대1 연관관계를 매핑하기 위해서는 주 테이블과 대상 테이블을 식별해야 합니다.

저는 여기서 상품와 재고 중 주 테이블과 대상 테이블을 정하는 것은 개발자가 생각하는 것에 따라 달라지는 것이 아닌가? 라는 1차원적인 생각이 들었는데,

주 테이블과 대상 테이블을 나누는 기준은 비즈니스 규칙에 따라 상위개념과 하위개념으로 분류 되었을때, 상위 개념이 주 테이블이고 하위 개념이 대상테이블이 된다는 것을 깨달았습니다.

그러면 여기서 어떤엔티티가 상위개념이고 하위개념인지 명확하게 알 수 있는데,

재고는 상품이 없으면 존재할 이유가 없고,

상품은 재고가 없어도 존재할 이유가 있기 때문에

상품 = 상위개념 = 주 테이블

재고 = 하위개념 = 대상 테이블

이라는 규칙이 성립되게 됩니다.

이제 주 테이블과 대상 테이블을 식별하였으니

외래키를 어느 테이블이 관리할 것인가에 대한 고민을 하게 됩니다.

여기서 어느 테이블이 관리하는지에 따라 장단점이 있는데,

정리해보자면

주 테이블이 외래키를 관리 (단방향)

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "product_id")
    private Long id;

    private String name;

    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "stock_id")
    private Stock stock;
}

장점

1. 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인할 수 있다.

2. 이론적으로 지연로딩이 가능하다.

단점

1. 값이 없으면 외래키에 null을 허용한다.

대상 테이블이 외래키를 관리(양방향)

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "product_id")
    private Long id;

    private String name;

    @OneToOne(mappedBy = "product")
    private Stock stock;
}

@Entity
public class Stock {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "stock_id")
    private Long id;

    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "product_id")
    private Product product;
}

장점

1. 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조가 유지된다.

단점

1. 지연로딩이 불가능하고 항상 즉시 로딩된다. (주 테이블을 조회할 때 ID값을 모르기 때문)

2. 대상테이블에 외래키 단방향 관계는 JPA에서 지원하지 않기 때문에 항상 양방향 매핑을 해야한다.

이렇게 정리해볼 수 있는데,

만약에 비즈니스 규칙이 바뀌어 일대일 관계가 다대일 관계로 확장될 가능성이 있다면 대상 테이블에 외래키를 두는것이 좋고,

그렇지 않다면 주 테이블에 외래키를 두는 것이 좋다고 생각합니다.

SpringBoot - QueryDSL 환경세팅

jiubuntu — Sat, 7 Jun 2025 13:56:26 +0900

현재 사용하는 SpringBoot 버전 3.3.5 이다.

QueryDSL 5.0.0 버전부터는 javax가 아닌 jakarta Persistence 기반이기 때문에
jakarta EE 기반인 3.x.x 버전과 호환이 된다.

그래서 5.0.0 버전으로 세팅했다.

implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'

annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta"
annotationProcessor "jakarta.annotation:jakarta.annotation-api"
annotationProcessor "jakarta.persistence:jakarta.persistence-api"

build.gradle > dependencies에 이와같이 추가하면 된다.

추가하고나서 인텔리제이 우측상단 Gradle에서 build > clean 후에 build 하고나면

build/generated 폴더에 Q클래스가 생성되는것을 확인할 수 있다.

그런데 build/generated 폴더에 생성되었기 때문에 SpringBoot에서 import를 하지 못한다.

그렇기 때문에 추가적인 설정이 필요하다.

def generated = 'src/main/generated'

// querydsl QClass 파일 생성 위치를 지정
tasks.withType(JavaCompile) {
	options.generatedSourceOutputDirectory = file(generated)
}


// java source Set 에 querydsl QClass 위치 추가
sourceSets {
	main.java.srcDirs += "$projectDir/src/main/generated"
}

// build clean 시에 QClass 디렉토리 삭제
clean {
	delete file(generated)
}

이렇게 설정해주면 /src/main/generated에 Q클래스들이 만들어지게되고,

자동적으로 import 할 수 있게된다.

Factory method 'sqlSessionFactory' threw exception; nested exception is java.io.FileNotFoundException: class path resource [mapper/] cannot be resolved to URL because it does not exist 에러 해결

jiubuntu — Tue, 18 Feb 2025 10:18:10 +0900

Factory method 'sqlSessionFactory' threw exception; nested exception is java.io.FileNotFoundException: class path resource [mapper/] cannot be resolved to URL because it does not exist

Mybatis 환경세팅을하고 스프링부트를 실행시켰는데 해당 에러가 나면서 실행이 되지 않았다.
파악해보니, Mybatis가 Mapper XML 파일을 읽어들이지못해 나는 에러였다.

<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" 
    "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

XML 파일에 추가해주었더니 해결되었다.

hikaripool-1 - failed to execute isvalid() for connection 에러 해결

jiubuntu — Mon, 17 Feb 2025 16:44:29 +0900

hikaripool-1 - failed to execute isvalid() for connection, configure connection test query (receiver class cohttp://m.ibm.as400.access.as400jdbcconnectionimpl does not define or inherit an implementation of the resolved method 'abstract boolean isvalid(int)' of interface java.sql.connection.).
현재 AS400 DB2를 사용하고있는데 Spring Boot 에서 Mybatis를 연동하는 중, 이 에러를 마주했다.

에러를 분석해보니 hikariCP에서는 isValid()라는 함수를 사용해서 유효성 검사를 하고 DB와 커넥션을 맺는다고 한다.
그런데 jt400 JDBC드라이버에는 isValid()함수가 구현이 안되어있는 것 같다. (jt400을 최신버전으로 바꿔도 안됨)

이 에러를 해결하기위해서는 유효성 검사를 다른 방식으로 해주면 된다.

application.properties에

spring.datasource.hikari.connection-test-query: values 1

를 추가했더니 해결됐다.

유효성 검사를 ' values 1 '이라는 쿼리를 통해서 하는 것이다.
출처 : https://stackoverflow.com/questions/68120283/unable-to-connect-ibmi-machine-with-spring-data-jpa

AWS - Nginx에 React 프로젝트 빌드 후 배포하기

jiubuntu — Mon, 10 Feb 2025 22:13:22 +0900

로컬에 존재하는 React 프로젝트를 AWS EC2에 배포해보자.

배포하기전에 EC2에 Nginx가 미리 설치되어 있어야 하고, 보안그룹의 인바운드 규칙에 80번 포트가 추가되어 있어야 한다.

1. 내 로컬 PC에서 React 프로젝트 빌드

npm run build

2. SSH로 AWS 접속 후, Nginx 기본 설정 비활성화

sudo rm /etc/nginx/sites-enabled/default

3. 로컬에 있는 build 폴더를 EC2 서버로 옮기기

scp -i [pem파일경로] -r build/ ubuntu@[AWS퍼블릭ip]:~/react-app
// 로컬의 build 폴더를 서버의 홈 디렉토리에 react-app 이라는 폴더로 만든다.

4. 로컬에서 가져온 폴더를 Nginx 루트로 이동

sudo mv ~/react-app /var/www/react-app

5. 권한설정

sudo chown -R www-data:www-data /var/www/react-app

6. Nginx 설정

sudo vi /etc/nginx/sites-available/react-app

이 명령어를 통해 vi 에디터로 설정파일을 새로 만드는 동시에 파일을 연다. (처음엔 sudo 명령어 붙여야 저장이 된다. 안그러면 계속 읽기모드로 켜짐)

server {
    listen 80;
    listen [::]:80 default_server;
    server_name _;

    root /var/www/react-app;
    index index.html;

    location / {
            #try_files $uri /index.html;
            try_files $uri $uri/ =404;
    }

}

나는 이와같이 작성했다. ipv6 지원 하지않을거면 listen [::]:80 default_server 부분은 제외해도 된다.

명령어 모드에서 :wq를 하고 나온다.

7. 설정 적용

sudo ln -s /etc/nginx/sites-available/react-app /etc/nginx/sites-enabled/
sudo nginx -t  # 설정 확인
sudo systemctl restart nginx

sudo ln -s /etc/nginx/sites-available/react-app /etc/nginx/sites-enabled/ 명령어로 sites-available 폴더에 만든 설정 파일들을 sites-enabled 로 연결하는 심볼릭 링크를 생성한다.

그리고 nginx를 restart하면 배포완료 !