Welcome! Everything is fine.

Claude Cowork Skill로 주간/월간 취업 리포트 자동화하기

개발곰발 — Fri, 31 Jul 2026 17:26:20 +0900

클로드에서 스킬을 사용하는 모습

반복되는 취업 지원 관리가 번거로웠다

취업 준비를 하면서 지원 현황은 모두 Notion DB에 기록하고 있었다. 지원한 회사, 마감일, 지원일, 진행 상태 등을 한곳에서 관리할 수 있어 기록 자체는 어렵지 않았다.

문제는 기록하는 것보다 관리하는 것이었다.

지원하는 회사가 하나둘 늘어나자 매번 Notion을 열어 어떤 공고의 마감이 얼마 남았는지, 어떤 회사가 30일 넘게 연락이 없는지 직접 확인해야 했다. 합격·불합격 메일을 받으면 상태도 수동으로 수정해야 했는데, 가끔 이를 놓쳐 실제 진행 상황과 Notion의 내용이 달라지기도 했다.

문득 이런 생각이 들었다.

"Claude는 Notion도 읽을 수 있고 Gmail도 읽을 수 있는데, 이걸 내가 직접 관리할 이유가 있을까?"

그렇게 반복적인 취업 지원 관리 업무를 Claude Cowork Skill로 자동화하기 시작했다.

Claude Cowork Skill로 자동화 구조 만들기

자동화 흐름은 크게 세 단계로 구성했다.

/weekly-report
     │
     ▼
Notion DB 조회
     │
     ▼
지원 현황 집계 및 분석
     │
     ▼
Gmail 리포트 작성

Notion DB에서 지원 현황 데이터를 가져온 뒤, 현재 진행 상황과 확인이 필요한 항목을 정리하고 Gmail 리포트 형태로 발송하는 구조다. 흥미로웠던 점은 Skill 파일 자체도 직접 작성하지 않았다는 것이다. Claude에게 자연어로 원하는 동작을 설명하면, 이를 실행 가능한 SKILL.md 형태로 구조화해준다.

"Notion에서 지난 7일 데이터 가져와서 집계하고, 마감 임박 항목은 리마인드로 강조해서 Gmail로 보내줘."

이렇게 요구사항을 전달하면 Claude가 아래와 같은 Skill 명세를 만들어준다.

---
name: weekly-report
description: >
  취업 지원 현황 주간 리포트를 생성하고 Gmail로 발송하는 스킬.
  사용자가 "주간 리포트", "weekly report" 등을 요청하면 실행한다.
---

## 목적
Notion DB에서 지난 7일간의 취업 지원 데이터를 집계하고,
30일 이상 무응답 항목을 정리한 뒤 Gmail로 리포트를 발송한다.


## Notion DB 정보
(...이하 생략)

생성된 Skill을 설치하면 이후에는 /weekly-report 명령 한 번으로 Notion 조회부터 리포트 생성, Gmail 발송까지 전체 흐름이 실행된다. Skill을 만들면서 가장 많이 한 일은 코드를 작성하는 것이 아니라 요구사항을 다듬는 것이었다. 처음에는 "주간 리포트를 보내줘" 수준이었지만, 사용하면서 필요한 규칙을 하나씩 추가했다.

마감 7일 이내 항목 리마인드
서류 제출 후 30일 이상 무응답 항목 자동 처리
신규 지원 / 진행 중 / 탈락 상태별 구분
표시할 항목이 없는 섹션은 생략

새로운 요구사항을 설명하면 Claude가 이를 Skill 문서에 반영해 주었고, Skill도 점점 실제 사용에 맞게 발전했다. 처음에는 매주 일요일 아침에 자동으로 리포트를 보내는 스케줄 실행을 고려했다. 하지만 컴퓨터가 꺼져 있으면 실행되지 않는다는 제약이 있어, 필요할 때 /weekly-report, /monthly-report 명령으로 실행하는 온디맨드 방식으로 변경했다. 발송 과정에서는 Gmail MCP의 발송 기능이 제한적이었기 때문에, Claude in Chrome을 활용해 Gmail 작성창을 직접 열고 리포트를 입력하는 방식으로 구현했다.

구현보다 디버깅이 더 오래 걸렸다

구현 과정에서 가장 오래 고민했던 부분은 외부 서비스와의 연동 방식이었다.

1. Notion 조회 방식

처음에는 SQL 쿼리로 Notion DB를 직접 조회하려고 했다. 하지만 해당 기능이 Business 플랜 이상에서만 지원된다는 것을 뒤늦게 알게 됐다. 결국 notion-search로 항목 목록을 조회한 뒤 notion-fetch로 개별 데이터를 가져오는 방식으로 우회했다. 현재는 정상적으로 동작하지만, 데이터가 많아질수록 여러 항목을 개별 조회해야 한다는 한계가 있다.

2. Gmail 본문이 비어 있는 문제

가장 오래 헤맨 부분은 Gmail 자동 작성이었다. 처음에는 Gmail의 접근성용 textarea에 리포트 내용을 입력하면 실제 메일 본문에도 반영될 것이라고 생각했다. 하지만 발송된 메일은 계속 빈 본문으로 도착했다.

확인해보니 Gmail은 화면에 표시되는 리치 텍스트 에디터(contenteditable)와 접근성용 textarea를 분리해서 관리하고 있었다. textarea의 값을 변경하는 것은 화면에 보이는 값만 바꾸는 것이었고, Gmail 내부 상태에는 반영되지 않아 실제 발송 시 본문이 비어 있었던 것이다.

해결 방법은 값을 직접 주입하는 것이 아니라, 사용자가 직접 붙여넣기한 것처럼 입력 이벤트를 발생시키는 것이었다.

const richEditor = document.querySelector('[contenteditable="true"][aria-multiline="true"]');

if (richEditor) {
  richEditor.focus();
  const dt = new DataTransfer();
  dt.setData('text/plain', reportText);

  richEditor.dispatchEvent(new ClipboardEvent('paste', {
    bubbles: true,
    cancelable: true,
    clipboardData: dt
  }));
}

DataTransfer를 이용해 실제 paste 이벤트를 발생시키자 Gmail이 이를 사용자 입력으로 인식했고, 정상적으로 본문이 작성됐다.

이번 경험을 통해 DOM 요소의 값을 변경하는 것과 서비스가 실제 입력으로 인식하는 것은 다를 수 있다는 점을 알게 됐다. 자동화에서는 단순히 값을 넣는 것보다, 대상 서비스가 동작하는 방식을 이해하고 그에 맞는 이벤트를 발생시키는 것이 중요했다.

실제로 사용해보니

현재는 실제로 /weekly-report와 /monthly-report를 실행해 취업 지원 현황 리포트를 받아보고 있다.

실제로 클로드가 보낸 이메일

리포트에는 신규 지원 현황, 진행 중인 전형, 합격·탈락 여부, 확인이 필요한 일정 등이 정리되어 있다. 실제 사용 중에는 마감이 얼마 남지 않은 지원 건을 리마인드로 확인하거나, 이전에 확인하지 못했던 서류 결과를 리포트를 통해 발견하는 경우도 있었다.

가장 크게 달라진 점은 취업 지원 현황을 관리하는 데 드는 신경 쓰는 비용이 줄었다는 것이다.

이전에는 주기적으로 Notion DB를 열어 전체 지원 현황을 직접 확인하고, 오래 대기 중인 항목을 찾아 상태를 수정해야 했다. 이제는 리포트를 통해 현재 상황을 한 번에 확인하고, 30일 이상 무응답인 항목도 자동으로 정리되기 때문에 DB 상태를 항상 최신으로 유지할 수 있게 됐다.

취업 준비 과정에서 지원 자체뿐 아니라 지원 현황을 관리하는 일도 생각보다 많은 에너지를 필요로 한다는 것을 느꼈는데, 이 부분을 자동화하면서 관리에 대한 부담이 확실히 줄었다.

마무리

취업 준비 과정에서도 개발자가 문제를 해결하는 방식은 적용할 수 있다고 느꼈다. 반복적으로 발생하는 불편함을 발견하고, 필요한 기능을 정의하고, 이를 자동화된 흐름으로 바꾸는 과정은 개발 과정과 크게 다르지 않았다. 특히 이번 경험에서 중요했던 것은 Claude가 코드를 작성해주는 것이 아니라, 내가 원하는 결과를 구체적인 요구사항으로 정의하는 일이었다. "어떤 데이터를 가져올지", "어떤 상황을 리마인드할지", "예외 상황은 어떻게 처리할지"를 정리하면서 자연스럽게 서비스의 요구사항을 설계하는 경험을 할 수 있었다.

Git 기본 브랜치를 master에서 main으로 변경하기

개발곰발 — Mon, 8 Jun 2026 23:56:54 +0900

새 프로젝트를 만들 때마다 기본 브랜치가 master로 생성되는 게 불편하다면, 전역 설정 한 번으로 해결할 수 있다.

설정해두면 이후 생성하는 모든 저장소에 자동으로 적용된다.

기본 브랜치 변경

터미널에서 아래 명령어를 실행한다.

git config --global init.defaultBranch main

설정 확인

아래 명령어로 현재 설정값을 확인할 수 있다.

git config --global --get init.defaultBranch

정상적으로 설정되었다면 main이 출력된다.

main

동작 확인

새 디렉터리를 만들고 Git 저장소를 초기화해서 직접 확인해볼 수 있다.

mkdir test-git
cd test-git
git init
git branch

main 브랜치로 초기화된 것을 확인할 수 있다.

이미 master로 생성된 저장소라면?

기존 저장소는 자동으로 변경되지 않으므로 직접 이름을 바꿔야 한다.

git branch -m master main

원격 저장소가 연결되어 있다면 변경된 브랜치를 푸시한다.

git push -u origin main

[DB] 데이터 무결성과 제약 조건 종류

개발곰발 — Sat, 11 Apr 2026 15:41:12 +0900

인프런 <김영한의 실전 데이터베이스 - 기본편> 강의를 토대로 정리한 내용입니다.

- 목차 -

1. 데이터 무결성

2. 기본 제약 조건

1) NOT NULL

2) UNIQUE

3) PRIMARY KEY

4) DEFAULT

3. 외래 키 제약 조건

1) 규칙

2) ON DELETE / ON UPDATE 옵션

4. CHECK 제약 조건

데이터 무결성

데이터 무결성(Data Integrity) : 데이터의 정확성, 일관성, 유효성을 유지하는 성질
제약 조건(Constraints) : 데이터 무결성을 강제하기 위해 테이블의 특정 컬럼에 설정하는 규칙

GIGO (Garbage In, Garbage Out) : 쓰레기가 들어가면 쓰레기가 나온다. 초기 데이터의 신뢰도가 결과물의 신뢰도를 결정한다.

잘못된 데이터는 잘못된 비즈니스 결정, 시스템 오류, 데이터 불일치 등 심각한 문제를 야기한다. 그래서 데이터베이스는 데이터를 지키는 '최후의 보루' 역할을 해야 한다. 1차 검증은 애플리케이션에서 하더라도, 데이터베이스에 유효한 값만 입력되도록 강제하기 위해 제약 조건(Constraints) 이 필요하다. 제약 조건에는 기본 제약 조건, 외래 키 제약 조건, CHECK 제약 조건이 있다.

기본 제약 조건

제약조건	역할	특징
NOT NULL	NULL 값 방지	필수 정보 누락을 원천 차단
UNIQUE	중복 값 방지	모든 값이 테이블 내에서 고유해야 함
PRIMARY KEY	행의 고유 식별자	NOT NULL + UNIQUE, 테이블당 1개만 설정 가능
DEFAULT	기본값 설정	값을 입력하지 않았을 때 자동으로 채워질 값 지정

NOT NULL : NULL 값 방지

NOT NULL은 해당 컬럼에 NULL 값이 저장되는 것을 허용하지 않는다. 필요한 정보가 누락되는 것을 막는다.

email VARCHAR(255) NOT NULL

UNIQUE : 중복 값 방지

UNIQUE는 해당 컬럼에 들어가는 모든 값은 테이블 내에서 반드시 고유해야 한다. 중복 데이터가 쌓이는 것을 막는다.

email VARCHAR(255) UNIQUE

PRIMARY KEY (기본 키) : 행의 대표 식별자

테이블의 각 행을 고유하게 식별하는 단 하나의 대표키다. NOT NULL + UNIQUE 특징을 모두 가지며, 테이블당 하나만 설정할 수 있다. 기본 키를 기준으로 데이터가 저장되고 검색되므로 성능에도 매우 중요한 역할을 한다.

user_id BIGINT PRIMARY KEY

여러 컬럼을 묶어 복합 기본 키로 지정할 수도 있다.

CREATE TABLE order_items (
  order_id INT,
  item_id  INT,
  quantity INT,
  PRIMARY KEY (order_id, item_id)
);

DEFAULT : 기본 값 설정

DEFAULT는 특정 컬럼에 값을 명시적으로 입력하지 않았을 경우, 자동으로 설정될 기본값을 지정한다.

status VARCHAR(50) DEFAULT 'PENDING'

외래 키 제약 조건 (Foreign Key)

외래 키 제약 조건은 참조 무결성을 강제하는 제약 조건이다.

참조 무결성(Referential Integrity) : 두 테이블의 관계가 항상 유효하고 일관된 상태를 유지해야 한다는 원칙,

규칙

외래 키 제약 조건은 두 가지 중요한 규칙을 통해 우리의 데이터를 보호한다.

자식 테이블: 부모 테이블에 존재하지 않는 id 값을 자식 테이블의 FK 컬럼에 넣으려는 시도를 막는다.
부모 테이블: 자식 테이블에서 참조하고 있는 행을 부모 테이블에서 함부로 삭제/변경하지 못하게 막는다.

CREATE TABLE orders (
  id      INT PRIMARY KEY,
  user_id INT,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

ON DELETE / ON UPDATE 옵션

외래 키의 ON DELETE와 ON UPDATE 에서 별도의 참조 동작을 지정하지 않으면, 기본적으로 부모 데이터의 삭제나 수정을 제한 한다. 지정할 수 있는 참조 동작은 다음과 같다.

옵션	동작
RESTRICT (기본값)	자식 테이블에 참조하는 행이 있으면 부모 행을 삭제/수정할 수 없다
CASCADE	부모 행이 삭제/수정되면 자식 행도 함께 자동으로 삭제/수정된다
SET NULL	부모 행이 삭제/수정되면 자식의 FK 컬럼 값을 NULL로 설정한다
SET DEFAULT	부모 행이 삭제/수정되면 자식의 FK 컬럼 값을 기본값으로 변경한다
NO ACTION	즉각 체크하지 않고, 트랜잭션 종료 시 무결성을 검사한다

CASCADE는 의도치 않은 대량 삭제 위험이 있다. 실무에서는 애플리케이션 계층에서 명시적으로 처리하는 방식을 선호하기도 한다.

CHECK 제약 조건

CHECK는 컬럼에 들어올 값의 범위나 조건을 직접 지정하며, 조건식이 참(true) 일 때만 입력을 허용한다. 데이터의 '내용'과 '비즈니스 규칙'을 DB 레벨에서 강제하기 위해 사용한다.

CREATE TABLE products (
  id            INT PRIMARY KEY,
  name          VARCHAR(100) NOT NULL,
  price         INT CHECK (price >= 0),
  discount_rate INT CHECK (discount_rate BETWEEN 0 AND 100)
);

컬럼 간 비교 조건도 표현할 수 있다.

CREATE TABLE employees (
  id         INT PRIMARY KEY,
  hire_date  DATE,
  birth_date DATE,
  CHECK (hire_date > birth_date)
);

⚠️ MySQL 주의사항: MySQL 8.0 이전 버전에서는 CHECK 제약 조건을 파싱은 하지만 실제로 강제하지 않는다. MySQL 8.0+, PostgreSQL, Oracle 등에서는 정상적으로 동작한다.

최근에는 유연성과 테스트 편의성을 위해 애플리케이션 코드에서 검증을 처리하는 추세다. DB의 CHECK 제약 조건은 핵심 데이터의 '최후 방어선'으로만 신중하게 사용한다.

[DB] 인덱스 생성 · 조회 · 삭제 및 실행 계획 보기(+ 인덱스로 정렬 작업 성능 개선하기)

개발곰발 — Sat, 24 Jan 2026 17:19:29 +0900

인프런 <김영한의 실전 데이터베이스 - 기본편> 강의를 토대로 정리한 내용입니다.

- 목차 -

1. 인덱스란?

2. 인덱스 사용하기

1) 인덱스 생성, 조회, 삭제

2) 인덱스 실행 계획 보기

3. 인덱스가 사용되는 상황

1) 동등 비교

2) 범위 검색

3) LIKE 범위 검색

4. 인덱스로 ORDER BY 성능 개선하기

인덱스란?

인덱스란 특정 컬럼(들)의 데이터를 기반으로 생성되는, 원본 테이블과는 별개의 특수한 자료구조이다. 인덱스를 사용하면 풀 테이블 스캔을 사용하지 않아서 빠른 검색이 가능하다. 그 이유는 인덱스 내부의 데이터는 항상 정렬된 상태를 유지하기 때문이다.

풀 테이블 스캔(Full Table Scan)이란?
풀 테이블 스캔은 말 그대로 테이블을 처음부터 끝까지 탐색한다는 뜻이다. 따라서 데이터가 많으면 많을수록 검색 시간이 정비례해서 늘어난다. 찾으려는 데이터가 우연히 첫 번째 행에 있다면 한 번의 비교만으로 끝나겠지만, 맨 마지막 행에 있다면 데이터의 수만큼 비교를 해야하는 상황이 된다. 이런 풀 테이블 스캔은 느린 검색의 원인이 되고, 매우 비용이 높은 작업이므로 서비스의 핵심 기능에서 가급적 풀테이블 스캔이 발생하지 않도록 설계해야 한다.

만약 item_name 컬럼에 인덱스를 생성하고 다음 쿼리를 실행하면 데이터베이스는 어떻게 동작할까?

SELECT * FROM items WHERE item_name = '게이밍 노트북';

풀 테이블 스캔 대신, item_name 기반의 인덱스를 찾아간다.
정렬되어 있기 때문에 '게이밍 노트북'이라는 값을 빠르게 찾아낸다.
찾아낸 인덱스 항목에서 실제 데이터의 행 위치 값을 확인한다.
원본 테이블의 해당 위치로 점프해서 단번에 원하는 데이터를 가져온다.

이런 식으로 인덱스를 사용해 기본적인 성능 최적화를 할 수 있다.

인덱스는 트리 자료 구조를 사용하기 때문에 이런 빠른 검색이 가능한데, 이전 발행 글 중 이진 탐색 트리에 대해 정리한 글이 있어 첨부한다. 핵심은 데이터를 입력하는 시점에 정렬해서 보관한다는 점이다. 따라서 검색 시에도 찾으려는 데이터보다 작은 값은 왼쪽, 큰 값은 오른쪽으로 가면서 빠르게 찾아낼 수 있다.

[CS 발표_07] 완전 이진 트리, 포화 이진 트리, 이진 탐색 트리란?

완전 이진 트리, 포화 이진 트리, 이진 탐색 트리의 차이점은 무엇인가요? 발표 때 사용한 PDF로 질문에 대한 답변을 대신합니다:) 더보기기술 면접 대비 CS 전공 핵심요약집 | 이수진 - 교보문고

3uomlkh.tistory.com

인덱스 사용하기

인덱스 생성, 조회, 삭제

인덱스를 생성, 조회, 삭제하는 명령어는 다음과 같다.

CREATE INDEX 인덱스이름 ON 테이블이름(컬럼1, 컬럼2, ...);

SHOW INDEX FROM 테이블이름;

DROP INDEX 인덱스이름 ON 테이블이름;

인덱스 실행 계획 보기

아래와 같이 인덱스를 만들었을 때, 해당 인덱스가 진짜 사용되고 있는지 어떻게 알 수 있을까?

CREATE INDEX idx_items_item_name ON items (item_name);

인덱스를 만들었다고 무조건 그 인덱스가 사용되는 것은 아니다. 쿼리 옵티마이저가 풀 테이블 스캔이 더 빠르겠다고 판단하면 사용되지 않을 수도 있다. 인덱스가 정말 사용되는지 확인하려면 다음과 같이 EXPLAIN 명령어를 사용하면 된다.

EXPLAIN SELECT * FROM items WHERE item_name = '게이밍 노트북';

우선, 인덱스가 없을 때는 다음과 같은 결과가 나온다.

인덱스가 사용되고 있지 않을 때

type : ALL 은 풀 테이블 스캔을 의미한다. 인덱스를 제대로 사용했다면 ref, range 등 다른 값이 표시된다.
key : NULL 은 쿼리를 실행할 때 어떤 인덱스도 사용하지 못했다는 뜻이다.
rows : 25 는 옵티마이저가 쿼리를 처리하기 위해 탐색할 것으로 예측하는 행의 수이다. 현재 item 테이블의 전체 데이터가 25개이므로, 모든 행을 탐색할 것으로 예측하고 있다.
filtered : 10.00 은 25개의 행을 모두 읽고 그중 10%인 2.5개 정도의 행이 WHERE절 조건을 만족할 것이라고 예측하고 있음을 의미한다.
Extra : Using where 은 데이터를 가져온 후에 WHERE절의 조건을 사용해 필터링 작업을 수행했다는 의미다. 인덱스를 사용하면 NULL이 나온다.

다음은 idx_items_item_name 이라는 인덱스를 만든 후 실행한 결과다. 항목 결과가 꽤 달라진 것을 볼 수 있다.

인덱스가 사용될 때

type : ref 는 = 조건이나 JOIN에서 인덱스를 사용했다는 의미다. 만약 range라면 범위 검색(BETWEEN, >, <, >= 등)에서 인덱스를 사용했다는 의미다.
key : idx_items_item_name 는 쿼리 실행에 idx_items_item_name 인덱스가 사용되었음을 명확히 보여준다.
rows : 1 을 보면, 옵티마이저가 쿼리를 처리하기 위해 단 한 개의 행만 탐색할 것으로 예측하고 있다. 이 값이 작을수록 효율적인 쿼리라고 할 수 있다.
filtered : 100.00 은 인덱스를 통해서 스캔한 1개의 행을 100% 선택한다는 뜻이다.
Extra : NULL 은 데이터를 가져온 후 별도의 필터링 작업이 필요 없다는 뜻이다.

인덱스가 사용되는 상황

동등 비교

동등 비교의 경우, 위에서 EXPLAIN 명령어를 설명할 때 함께 설명했다.

type이 ref 라면 인덱스를 사용해 동등 비교(=) 조건으로 데이터를 찾았다는 의미다.

범위 검색

범위 검색 역시 비슷한데, type이 range 라면 범위 검색(BETWEEN , > , < , LIKE 등)에 인덱스가 사용된다는 의미다.

범위 검색 인덱스가 어떻게 사용되는지 알아보자.

먼저 인덱스 없이 다음 EXPLAIN 명령어를 실행한다.

EXPLAIN SELECT * FROM items WHERE price BETWEEN 50000 AND 100000;

결과는 다음과 같다.

범위 검색에서 인덱스가 사용되고 있지 않을 때

type : ALL 을 보면 풀 테이블 스캔이 발생한 것을 알 수 있다.
key : NULL 은 price 컬럼을 조건으로 사용했지만, 해당 컬럼에 인덱스가 없어 인덱스를 사용하지 않았다는 의미다.
rows : 25 는 테이블의 전체 행 수를 예측한 수치로, 풀 테이블 스캔을 했기 때문이다.
filtered : 11.11 은 전체 행 중에 WHERE price BETWEEN 50000 AND 100000 조건을 만족하는 행은 약 11.11% 일 것이라고 예측한다는 의미다.
Extra : Using where 은 데이터를 가져온 후에 WHERE 절의 조건을 사용해 필터링했다는 의미다. 인덱스가 없기 때문에 모든 데이터를 다 가져온 후, 조건에 맞는지 일일이 비교하는 방식으로 골라내고 있다.

위와 같이 조건절에 사용되는 컬럼에 인덱스가 없으면 풀 테이블 스캔을 피할 수 없다.

다음은 idx_items_price 인덱스를 만들어 다시 실행 계획을 보자.

CREATE INDEX idx_items_price ON items (price);

결과는 다음과 같다.

범위 검색에서 인덱스가 사용되고 있을 때

type : range 은 인덱스를 사용해 특정 범위의 데이터를 스캔했다는 의미다.
key : idx_items_price 는 쿼리 실행에 idx_items_price 인덱스가 사용되었다는 의미다.
rows : 5 를 보면 기존 25에서 5로 확 줄어들었는데, 옵티마이저가 인덱스를 통해 조건에 맞는 5개의 데이터만 스캔할 것이라고 판단하고, 그 행 수를 5개로 예측한 것이다.
filtered : 100.00 는 인덱스를 통해서 스캔한 5개의 행을 100% 선택한다는 의미다.
Extra : Using index condition 는 인덱스 정보만으로 WHERE 조건절을 최대한 필터링한 후, 조건을 만족하는 데이터의 전체 행만 가져왔다는 의미다.

실제 조회 결과

인덱스를 사용한 실제 결과를 보면 idx_items_price 인덱스를 사용한 후에는 인덱스 키인 price를 기준으로 정렬되었다는 것을 알 수 있다. 이처럼 인덱스를 사용하면 쿼리 결과의 정렬 순서가 달라질 수 있다. 그러나 이런 순서가 항상 보장되는 것은 아니므로, 정렬이 필요하면 ORDER BY 절을 추가하는 것이 권장된다.

LIKE 범위 검색

LIKE 절에서 인덱스 사용 시, 와일드카드(%)의 위치가 중요하다. 와일드카드(%)는 검색어의 뒤쪽에 와야 한다.

%가 앞에 있으면 시작점이 불분명해져 정렬된 인덱스를 활용할 수 없다.

WHERE item_name LIKE '게이밍%' : 인덱스 사용 가능
WHERE item_name LIKE '%게이밍' : 인덱스 사용 불가 → 풀 테이블 스캔 발생
WHERE item_name LIKE '%게이밍%' : 인덱스 사용 불가 → 풀 테이블 스캔 발생

인덱스로 ORDER BY 성능 개선하기

인덱스는 정렬된 자료구조이기 때문에, 인덱스를 잘 활용한다면 정렬(ORDER BY) 작업의 성능을 개선할 수 있다. 데이터베이스는 이 과정에서 filesort라는 별도의 정렬 작업을 생략할 수 있게 된다.

filesort란?
메모리나 디스크를 사용해 정렬하는 내부 프로세스를 의미한다.

인덱스를 활용하지 않은 다음 쿼리의 실행 계획을 보면 filesort를 확인할 수 있다.

EXPLAIN SELECT * FROM items ORDER BY stock_quantity;

결과는 다음과 같다.

Extra : filesort인 경우

Extra : filesort 는 데이터를 모두 찾을 후에 stock_quantity를 기준으로 정렬 작업이 추가되었음을 보여준다.

인덱스로 정렬 처리하기

WHERE절과 ORDER BY절의 정렬 기준이 같으면 인덱스를 스캔하는 것만으로도 검색과 정렬을 한번에 해결할 수 있다.

price 컬럼에 idx_items_price 컬럼을 만들어 둔 상태에서, 다음 쿼리를 실행해보자.

EXPLAIN SELECT * FROM items WHERE price BETWEEN 50000 AND 100000 ORDER BY price;

결과는 다음과 같다.

인덱스를 사용해 정렬까지 한 번에 처리한 경우아

아까와 달리 Using filesort가 없어지고 Using index condition으로 바뀌었다. 데이터베이스 옵티마이저는 idx_items_price가 이미 price 순서로 정렬되어 있다는 것을 알고 있어서, 조건에 맞게 스캔만 해도 자연스럽게 price 순서로 정렬된 결과를 얻을 수 있다. 따라서 WHERE절과 ORDER BY절이 동일한 인덱스를 효율적으로 사용할 수 있다면, 데이터베이스는 정렬을 생략하고, 가장 빠른 방식으로 쿼리를 처리한다.

인덱스 역방향 스캔

데이터베이스 옵티마이저는 역방향 스캔(Backward Index Scan)이 가능하다. 따라서 오름차순 정렬이 아닌 내림차순 정렬을 하더라도 단일 컬럼 인덱스에서는 filesort 없이 처리할 수 있다.

EXPLAIN SELECT * FROM items WHERE price BETWEEN 50000 AND 100000 ORDER BY price DESC;

역방향 스캔을 한 실행 계획

Extra : Using index; Backward index scan 은 옵티마이저가 인덱스를 역순으로 스캔했음을 의미한다. 인덱스는 양방향 탐색이 가능하기 때문에 WHERE 조건에 맞는 데이터를 찾는 과정에서 이미 정렬 순서가 만족되므로 별도의 filesort 작업이 필요없다.

내림차순 인덱스

MySQL 8.0 버전부터는 내림차순 인덱스(Descending Index)를 정식으로 지원하기 때문에, 정렬 방향과 일치하는 인덱스를 직접 만들 수 있다.

기존 인덱스를 삭제하고, 다음과 같이 내림차순 인덱스를 만들 수 있다.

CREATE INDEX idx_items_price_desc ON items (price DESC);

결과는 다음과 같다. Extra 컬럼에서 Backward index scan이 사라진 것을 볼 수 있다. 이제 역방향 스캔 없이 정방향 스캔만하면 된다. 미세한 차이지만, 역방향 스캔이 정방향 스캔보다 좀 더 빠르기 때문에 이렇게 하면 가장 최적화된 버전이라고 할 수 있다.

내림차순 인덱스 적용 결과

[DB] UNION, UNION ALL, UNION 정렬

개발곰발 — Sat, 3 Jan 2026 14:38:24 +0900

인프런 <김영한의 실전 데이터베이스 - 기본편> 강의를 토대로 정리한 내용입니다.

UNION

UNION은 여러 개의 결과 집합을 아래로(수직으로) 이어 붙여서 더 많은 행을 가진 집합으로 만드는 기술이다.

UNION으로 연결되는 모든 SELECT문은 컬럼의 개수가 동일해야 한다.
각 SELECT 문의 같은 위치에 있는 컬럼들은 서로 호환 가능한 데이터 타입이어야 한다. (이름은 달라도 됨)
최종 결과의 컬럼 이름은 첫번째 SELECT 문의 컬럼 이름을 따른다.
중복되는 행은 자동으로 제거한다. → UNION ALL을 사용하면 의도적으로 중복을 허용할 수 있다.

아래 예시를 보면, 활동 고객 명단(users)과 탈퇴 고객 명단(retired_users)을 합쳤다. UNION은 기본적으로 두 결과 집합을 합친 뒤, 완전히 중복되는 행은 자동으로 제거하여 고유한 값만 남긴다.

select name, email from users

union

select name, email from retired_users;

UNION ALL

UNION ALL은 여러 개의 결과 집합을 아래로(수직으로) 이어 붙여 하나의 결과 집합으로 만든다. 중복 행을 제거하지 않고, 모든 행을 그대로 포함한다.

두 종류의 고객에게 이메일을 보내려고 할 때, 첫 번째 그룹은 '전자기기' 카테고리의 상품을 구매한 이력이 있는 고객이고, 두 번째 그룹은 '서울'에 거주하는 고객이다. '서울'에 살면서 '전자기기'를 구매한 고객을 최종 목록에 한 번만 포함할지, 중복을 허용할지에 따라 UNION을 쓸지, UNION ALL을 쓸지 결정할 수 있다.

먼저, UNION을 사용한 결과는 다음과 같다.

-- 전자기기 구매 고객
select u.name, u.email
from users u
inner join orders o on u.user_id = o.user_id
inner join products p on o.product_id = p.product_id
where p.category = '전자기기'

union

-- 서울 거주 고객
select name, email
from users
where address like '서울%';

UNION ALL을 사용하면 '션', '네이트', '마리퀴리'가 중복되어 나타난다.

-- 전자기기 구매 고객
select u.name, u.email
from users u
inner join orders o on u.user_id = o.user_id
inner join products p on o.product_id = p.product_id
where p.category = '전자기기'

union all

-- 서울 거주 고객
select name, email
from users
where address like '서울%';

UNION vs UNION ALL

한 줄 요약 : UNION ALL이 훨씬 빠르다.

UNION : 두 결과 집합을 합친 후,중복된 행을 제거한다.
UNION ALL : 중복 제거 과정 없이, 두 결과 집합을 그대로 모두 합친다.

중복을 제거하는 추가 과정이 없는 UNION ALL이 훨씬 빠르다. 따라서 중복을 제거해야만 하는 명확한 요구사항이 있을 때만 UNION을 사용한다. 불필요한 UNION은 쿼리를 느리게 만들 수 있다.

UNOIN 정렬

ORDER BY 절은 전체 UNION 연산의 가장 마지막에 한 번만 사용해야 한다.

합쳐진 최종 결과 전체에 대한 순서를 결정해야 하기 때문에, ORBER BY 절의 위치가 중요하다.

다음과 같이 활동 고객과 탈퇴 고객의 명단을 합친 후 이름(name) 기준 오름차순 정렬을 하면, ORDER BY 절을 UNION 연산자의 마지막에 배치함으로써, 합쳐진 모든 고객의 이름이 글자 순서대로 정렬된다.

select name, email from users

union

select name, email from retired_users
order by name; -- 최종 결과에 대한 정렬

또한 각 테이블에 이름이 다른 컬럼이 있다면, 그 컬럼들을 아우를 수 있는 중립적인 별칭을 사용하는 것을 권장한다.

select distinct u.name as 고객명, u.email as 이메일
from users u
join orders o on u.user_id = o.user_id
join products p on o.product_id = p.product_id
where p.category = '전자기기'

union all

select distinct u.name as 고객명, u.email as 이메일
from users u
join orders o on u.user_id = o.user_id
where o.quantity > 1;

[DB] 내부 조인, 외부조인, 셀프조인, 크로스조인

개발곰발 — Thu, 27 Nov 2025 15:26:43 +0900

인프런 <김영한의 실전 데이터베이스 - 기본편> 강의를 토대로 정리한 내용입니다.

만약 모든 정보를 한 테이블에 다 넣는다면 조회할 때는 좀 더 편리할 수도 있겠지만, 다음과 같은 문제가 발생할 수 있다.

데이터 중복
갱신 이상
삽입 이상
삭제 이상

이러한 문제들 때문에 데이터베이스를 설계할 때는 정규화(Normalization)라는 과정을 거친다.

정규화(Normalization) : 데이터의 중복을 최소화하고, 데이터의 일관성을 해치는 '이상 현상'들을 방지하기 위해 데이터를 논리적인 단위로 분리하는 과정.

그런데 이렇게 정규화를 거쳐서 쪼개진 테이블들에서 의미 있는 정보를 얻으려면 이 흩어진 데이터 조각들을 다시 합쳐야 한다. 이때 사용하는 기술이 바로 조인(JOIN) 이다. 조인의 종류에는 내부 조인, 외부 조인, 셀프 조인, 크로스 조인이 있다.

조인(JOIN) : 두 개 이상의 테이블을 특정 컬럼을 기준으로 연결하여, 마치 처음부터 하나의 테이블이었던 것처럼 보여주는 기능.

내부 조인

양쪽 테이블에 모두 공통으로 존재하는 데이터만을 보고싶을 때 사용하는 기술.

SELECT 컬럼1, 컬럼2, ...
FROM 테이블A
INNER JOIN 테이블B -- INNER 생략 가능
ON 테이블A.연결컬럼 = 테이블B.연결컬럼;

논리적 처리 순서 : FROM/JOIN (테이블 결합) → WHERE (조건 필터링) → SELECT (컬럼 선택)

외부 조인

한 쪽에는 데이터가 있지만, 다른 한 쪽에는 없는 데이터까지 모두 포함해서 보고싶을 때 사용하는 기술.

LEFT (OUTER) JOIN은 왼쪽 테이블을, RIGHT (OUTER) JOIN은 오른쪽 테이블을 기준으로 삼는다.
- 기준으로 되는 테이블의 모든 데이터를 결과에 포함시킨다.
- 그 다음, ON 조건에 맞는 데이터를 반대 테이블에서 찾아 옆에 붙여준다.
- 만약 반대 테이블에 짝이 맞는 데이터가 없다면, 그 자리는 NULL 값으로 채워진다.

셀프 조인

자기 참조 관계의 데이터를 한 번의 쿼리로 조회하기 위해 사용하는 기술.

자기 참조 관계란 한 테이블 안에서 자신의 컬럼이 같은 테이블의 다른 컬럼을 참조하는 구조를 말한다.
INNER JOIN → NULL이면 안나온다.
LEFT JOIN → NULL인 것까지 다 나온다.

크로스 조인

애초에 짝이나 관계가 없는 두 집단을 가지고 가능한 모든 조합을 만들어내야 할 때 사용하는 기술.

조인 조건 없이 한쪽 테이블의 모든 행을 다른 쪽 테이블의 모든 행과 하나씩 전부 연결하는 가장 단순한 조인 방식이다. 그러나, 크로스 조인은 결과의 행 수가 기하급수적으로 늘어날 수 있기 때문에 가급적 사용하지 않는 것이 좋다.
크로스 조인의 결과는 수학 용어로 카테시안 곱 또는 데카르트 곱이라고 한다.

[CS] 디자인 패턴 종류와 간단한 개념 정리

개발곰발 — Wed, 22 Oct 2025 23:27:40 +0900

해당 포스팅은 <면접을 위한 CS 전공지식 노트> 를 읽고 정리한 내용입니다.

디자인 패턴이란 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용해 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것이다. 디자인 패턴의 종류에는 싱글톤 패턴, 팩토리 패턴, 전략 패턴, 옵저버 패턴, 프록시 패턴, 이터레이터 패턴, 노출모듈 패턴, MVC 패턴, MVP 패턴, MVVM 패턴 등이 있다.

싱글톤 패턴

하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴.

싱글톤 패턴은 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하는 패턴이다. 데이터베이스 연결 모듈에 많이 쓰인다.

싱글톤 패턴의 장단점은 다음과 같다.

장점 : 사용하기 쉬움, 인스턴스 생성 시 비용 절감
단점 : 의존성이 높아짐, TDD를 하기 어려움(각 테스트마다 독립적인 인스턴스를 만들기 어려움)

싱글톤 패턴은 단순하고 실용적이지만 모듈 간의 결합을 강하게 만들 수 있다는 단점이 있다. 이때 의존성 주입(DI, Dependency Injection)을 통해 모듈 간의 결합을 느슨하게 만들 수 있다. 의존성 주입을 원칙은 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다는 것이다. 또한 둘 다 추상화에 의존해야 하며, 이때 추상화는 세부사항에 의존하지 않는다.

의존성 주입의 장단점
장점 : 모듈을 쉽게 교체 가능 → 테스팅, 마이그레이션 쉬워짐
단점 : 모듈들이 더욱더 분리되어 복잡성 증가

팩토리 패턴

객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴.

팩토리 패턴은 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 구체적인 내용을 결정하는 패턴이다. 즉, 객체 생성의 책임을 분리하는 것이 목적이다.

상위 클래스와 하위 클래스가 분리됨 → 느슨한 결합을 가짐
상위 클래스에서는 인스턴스 생성 방식에 대해 알 필요 없음 → 더 많은 유연성
객체 생성 로직이 분리되어 있음 → 코드를 리팩토링 시 한 곳만 고칠 수 있어 유지 보수성 증가

전략 패턴(= 정책 패턴)

객체의 행위를 바꾸고 싶을 때 직접 수정하지 않고 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴.

전략 패턴은 알고리즘이나 동작 방식을 유연하게 교체할 수 있도록 하는 패턴이다. 예를 들어, 결제 시스템에서 PaymentStrategy를 바꿔서 CardPayment, KakaoPay 등으로 교체할 수 있다. 즉, 동작을 유연하게 바꾸는 것이 목적이다.

옵저버 패턴

주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴.

옵저버 패턴은 주로 이벤트 기반 시스템에 사용되며, MVC 패턴에도 자주 사용된다. 옵저버 패턴에서의 주체, 옵저버의 개념은 다음과 같다.

주체 : 객체의 상태 변화를 보고 있는 관찰자로, 상태 변경 시 옵저버에게 알림을 보냄
옵저버 : 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변경 사항'이 생기는 객체들을 의미함

옵저버 패턴을 구현하는 방법에는 프록시 객체를 사용하는 방법이 있다. 프록시 객체를 통해 객체의 속성이나 메서드 변화 등을 감지하고 이를 미리 설정해놓은 옵저버들에게 전달하는 방법으로 구현한다.

프록시 객체
어떠한 대상의 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출 등)의 작업을 가로챌 수 있는 객체를 의미한다.

프록시 패턴

대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 패턴.

프록시 패턴은 실제 객체에 대한 접근을 제어하기 위해 그 객체를 대신하는 대리 객체를 두는 패턴이다. 이를 통해 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용한다.

프록시 서버 : 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램. 서버 앞단에 둬서 캐싱, 로깅, 데이터 분석을 서버보다 먼저 하는 서버를 말한다.
- 프록시 서버를 통해 포트 번호를 바꿔서 사용자가 실제 서버의 포트에 접근하지 못하게 하거나, 공격자의 DDOS 공격을 차단할 수 있다. 또한 CDN을 프록시 서버로 달아서 캐싱 처리를 용이하게 할 수 있다.
- nginx로 Node.js로 이루어진 서버의 앞단에 둬서 버퍼 오버플로우를 해결하거나 CloudFlare를 둬서 캐싱, 로그 분석 등을 할 수 있다.

DN(Content Delivery Network)
각 사용자가 인터넷과 가까운 곳에서 콘텐츠를 캐싱 또는 배포하는 서버 네트워크를 말한다.

이터레이터 패턴

이터레이터를 사용하여 컬렉션의 요소들에 접근하는 패턴.

이터레이터 패턴을 통해 순회할 수 있는 여러 가지 자료형과 상관없이 이터레이터라는 하나의 인터페이스로 순회할 수 있다.

다음 예제를 보면 서로 다른 자료 구조인 set과 map이지만, 똑같은 for a of b 라는 이터레이터 프로토콜을 통해 순회하는 것을 볼 수 있다.

const mp = new Map()
mp.set('a', 1)
mp.set('b', 2)
mp.set('c', 3)
const st = new Set()
st.add(1)
st.add(2)
st.add(3)
for (let a of mp) console.log(a)
for (let a of st) console.log(a)

노출 모듈 패턴

즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴.

자바 스크립트는 접근 제어자가 존재하지 않고 전역 범위에서 스크립트가 실행됨 -> 노출 모듈 패턴을 통해 접근 제어자를 구현하기도 함.

MVC 패턴

모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 패턴.

MVC 패턴을 이용하면 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 가각의 구성 요소에만 집중하여 개발할 수 있다. MVC 패턴을 이용한 대표적인 라이브러리에는 리액트(React.js)가 있다..라고 책에 나와있는데, 검색해보니 실제로 React 자체는 MVC를 완전히 구현한 라이브러리는 아니고, View 역할만 담당하는 컴포넌트 기반 라이브러리라고 한다. Controller나 Model 역할은 외부 상태 관리 라이브러리(Redux, Recoil 등)나 개발자가 직접 구현해야 한다. 즉, React로 MVC 구조를 구현할 수는 있지만, React자체가 MVC는 아니다.

MVC 패턴의 장단점은 다음과 같다.

장점 : 재사용성과 확장성이 용이함
단점 : 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해짐

모델(Model), 뷰(View), 컨트롤러(Controller)의 개념은 다음과 같다.

모델(Model)
- 애플리케이션의 데이터(데이터베이스, 상수, 변수 등)를 의미
뷰(View)
- 사용자 인터페이스 요소(inputbox, checkbox, textarea 등)를 의미
컨트롤러(Controller)
- 하나 이상의 모델과 뷰를 잇는 다리 역할을 하며, 메인 로직을 담당함.
- 모델과 뷰의 생명주기 관리
- 모델이나 뷰의 변경 통지를 받으면 이를 해석해 각각의 구성 요소에 해당 내용에 대해 알려줌

MVP 패턴

MVC 패턴으로부터 파생된 패턴으로, C에 해당하는 컨트롤러(Controller)가 프레젠터(Presenter) 로 교체된 패턴.

MVP패턴에서 뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 가진다.

MVVM 패턴

MVC의 C에 해당하는 컨트롤러(Controller)가 뷰모델(View Model)로 바뀐 패턴.

MVVM 패턴은 모델(Model), 뷰(View), 뷰모델(View Model)로 이루어진 패턴이다. MVVM 패턴을 이용한 대표적인 라이브러리에는 뷰(Vue.js)가 있다. 이 패턴에서 뷰모델이란 뷰를 더 추상화한 계층으로, MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징이다.

장점 : 뷰와 뷰모델 사이의 양방향 데이터 바인딩 지원, 별도의 코드 수정 없이 UI 재사용 가능, 단위 테스트가 쉬움
단점 : 양방향 바인딩이 많아질수록 복잡해짐

MVC 패턴과 MVVM 패턴의 차이
MVVM 패턴은 MVC 패턴과 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징이다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다는 장점이 있다.

'향로' 와 함께하는 추석 완강 챌린지 회고

개발곰발 — Tue, 14 Oct 2025 11:40:26 +0900

추석 연휴 동안 인프런에서 하는 챌린지에 참여했다.

연휴가 길어 늘어질 것을 대비해 신청한 챌린지였는데, 늘어지는 것을 아예 막을 순 없었다.

그러나 늘어지는 와중에 강의 하나라도 들으려고 노력했고, 단기간에 완강하게 되어 만족한다.

내가 수강한 강의는 <외워서 끝내는 네트워크 핵심이론 - 기초> 강의다.

한 번 더 복습해야할 것 같지만, 학부 때 배운 (다 까먹어가는) 네트워크 지식을 핵심만 골라 뇌에 새길 수 있었다.

다시 한 번 복습하고 응용편도 들어봐야겠다.

인프런 복습 기능 출시 기원 정권지르기 1일차..

향로님의 라이브를 들으며 아궁이 속 불씨를 꺼지지 않도록 하는 것이 중요하다는 것을 깨달았다.

그런데 내가 잘못 알고 있었던 건, 그 불씨가 꼭 개발에 국한되어야 한다는 것은 아니다.

개발이 될 수도 있고, 다른 새로운 공부, 혹은 취미 활동이 될 수도 있다.

중요한 건 지치지 않고 불씨가 꺼지지 않도록 하는 것!

[Docker] Docker Compose로 여러 컨테이너 띄우기

개발곰발 — Wed, 8 Oct 2025 23:59:38 +0900

인프런 <비전공자도 이해할 수 있는 Docker 입문/실전> 강의를 토대로 정리한 내용입니다.

Docker Compose란?

이전에 배운 Docker CLI, Dockerfile 등에 대해 제대로 숙지했다면 Docker Compose는 어렵지 않다!

Docker Compose는 쉽게 말하면 여러 컨테이너를 한 번에 띄우고 싶을 때 사용한다.

Docker Compose : 여러 개의 Docker 컨테이너들을 하나의 서비스로 정의하고 구성해 하나의 묶음으로 관리할 수 있게 도와주는 툴.
Docker Compose를 사용하는 이유?
- 여러 개의 컨테이너를 관리하는 데 용이하다.
- 복잡한 명령어로 실행하던 것을 간소화 시킬 수 있다.

자주 사용하는 Docker Compose CLI 명령어

compose.yml에서 정의한 컨테이너 실행
- docker compose up : 포그라운드에서 실행
- docker compose up -d : 백그라운드에서 실행
Docker Compose로 실행시킨 컨테이너 확인
- docker compose ps : 실행 중인 컨테이너 확인
- docker compose ps -a : 정의된 모든 컨테이너 확인
Docker Compose 로그 확인
- docker compose logs
컨테이너 실행 전 이미지 재빌드
- docker compose up --build : 포그라운드에서 실행
- docker compose up --build -d : 백그라운드에서 실행
이미지 다운받기 / 업데이트하기
- docker compose pull
- 로컬 환경에 이미지가 없다면 다운로드, 있는데 DockerHub의 이미지와 다를 경우 업데이트.
Docker Compose에서 이용한 컨테이너 종료
- docker compose down

Docker Compose로 MySQL, Redis 띄우기

Docker Compose로 MySQL과 Redis를 동시에 띄워보는 실습을 진행했다.

우선 compose.yml 파일은 다음과 같이 작성했다.

services:
  my-db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: pwd1234
    volumes:
      - ./mysql_data:/var/lib/mysql
    ports:
      - 3306:3306
  my-cache-server:
    image: redis
    ports:
      - 6379:6379

Docker Compose에서 하나의 컨테이너를 서비스(service) 라고 한다. 따라서 여러 개의 서비스를 적기 전에 services 라는 명령어를 적는다.
services 밑에는 컨테이너, 즉 서비스에 이름을 붙여 적는다. my-db, my-cache-server와 같이 내가 적고 싶은 이름을 적는다.
image에는 어떤 이미지를 기반으로 컨테이너를 띄울 것인지 적는다.
그 외에는 환경변수, 볼륨 설정, 포트 매핑과 같은 정보들을 적는다.

이제 docker compose up -d 명령어로 compose.yml에서 정의한 컨테이너를 실행시킨다.

그리고나서 docker ps (혹은 docker compose ps)로 확인해보니 MySQL과 Redis가 동시에 잘 띄워진 것을 볼 수 있다.

이렇게 Docker Compose를 사용하면 각각의 컨테이너를 따로 띄울 필요 없이 한 번에 띄울 수 있다.

docker compose down 명령어로 컨테이너들을 한 번에 내릴 수 있다.

[Spring] Spring Boot에서 URI가 컨트롤러에 매핑되는 흐름

개발곰발 — Fri, 19 Sep 2025 22:25:09 +0900

URI란?

URI(Uniform Resource Identifier) : 인터넷 상의 자원을 식별하는 통합 자원 식별자.
자원의 위치뿐만 아니라 이름이나 식별 정보를 포함하여 자원을 고유하게 지칭하는 문자열이다.
URI는 URL, URN의 상위 개념이다.

URI와 URL의 차이

URL(Uniform Resource Locator) : URI의 한 형태로, 네트워크상에서 자원의 위치와 접근 방법(프로토콜, 도메인, 경로 등)을 명시하는 규약.
모든 URL은 URI이지만, 모든 URI가 URL은 아니다.

Spring Boot에서 URI가 컨트롤러에 매핑되는 흐름

이제 Spring Boot에서 URI가 컨트롤러에 매핑되는 흐름을 살펴보자. DispatcherServlet의 동작 방식이라고 봐도 무방하다.

참고 자료로 본 블로그에 있던 DispatcherServlet의 처리 과정 그림을 차근 차근 이해하기 위해 직접 그려봤다.

1. 사용자(클라이언트)로부터 요청이 들어오면, 가장 먼저 DispatcherServlet이 받는다.

DispatcherServlet은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임하는 프론트 컨트롤러이다.

2. HandlerMapping이 요청 URI와 매핑된 컨트롤러를 찾아준다.

HandlerMapping은 @RequestMapping, @GetMapping 같은 어노테이션 정보를 기준으로 어떤 컨트롤러가 처리할 수 있는지 결정한다.

3. HandlerAdapter가 요청 파라미터를 바인딩하고, 선택된 컨트롤러 메서드를 호출한다.

HandlerAdapter는 어댑터 패턴 개념을 차용하여, DispatcherServlet이 컨트롤러의 구현 방식에 구애받지 않고 요청을 위임할 수 있도록 한다.

4. HandlerAdapter가 컨트롤러를 호출한다.

선택된 HandlerAdapter가 실제 RestController 메서드를 실행한다.
실행 전에 @PathVariable, @RequestBody 등의 요청 파라미터 바인딩이 이루어진다.

5. 컨트롤러가 응답 데이터를 반환한다. (ResponseEntity, DTO 등)

비즈니스 로직을 수행하기 위해 Service 계층을 호출하고, 필요 시 Repository를 통해 DB에 접근한다.

이 반환값을 HandlerAdapter가 받는다.

6. HandlerAdapter가 ResponseEntity를 처리한다.

@RestController가 붙은 컨트롤러 메서드의 반환값은 뷰가 아닌 응답 본문으로 처리되며, JSON/XML 같은 형식으로 변환할 때는 HttpMessageConverter가 직렬화를 수행한다.
뷰 템플릿이라면 ViewResolver가 화면을 렌더링한다.

7. 최종적으로 가공된 응답 객체를 DispatcherServlet에 다시 전달한다.

8. DispatcherServlet은 응답을 HTTP 응답으로 변환하여 클라이언트에 반환한다.

[ 참고 자료 ]

URL / URI / URN 차이점 - 한방 이해하기

URL / URI / URN 차이점 우리가 브라우저를 통해 웹을 이용하게 된다면, URL 단어는 익숙할 것이다. 하지만 가끔 뭔가 비스무리하면서도 다른 URI와 URN 이라는 단어를 사용하기도 하는데 이번 시간에

inpa.tistory.com

Spring 웹 요청 흐름(DispatcherServlet)

회사에서 신입 개발자 교육용으로 만들었던 자료입니다. 스프링에서 웹 요청 처리 흐름에 대한 내용으로 어...

blog.naver.com

[Spring] Dispatcher-Servlet(디스패처 서블릿)이란? 디스패처 서블릿의 개념과 동작 과정

이번에는 servlet의 심화 또는 대표주자인 dispatcher-servlet에 대해서 알아보도록 하겠습니다. 1. Dispatcher-Servlet(디스패처 서블릿)의 개념 [ Dispatcher-Servlet(디스패처 서블릿) 이란? ] 디스패처 서블릿의

mangkyu.tistory.com

[TIL] 멀티 스레드 - 스레드와 스레드 풀 이해하기

개발곰발 — Thu, 11 Sep 2025 18:24:45 +0900

인프런 <스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술> 강의를 보고 정리한 내용입니다.

멀티 스레드?

스레드(Thread) : 애플리케이션 코드가 순차적으로 실행되는 흐름
자바 애플리케이션 실행 시, main 스레드가 처음 시작
한 스레드는 한 번에 하나의 코드 라인만 수행
여러 작업을 동시에 처리해야 할 경우, 추가 스레드 생성 필요
예: 웹 서버에서 여러 요청을 동시에 처리하려면 멀티 스레드가 필수

요청마다 스레드를 만들면...

웹 서버가 요청마다 새 스레드를 만들면 어떨까?

장점

동시 요청 처리 가능
하나의 요청이 지연되더라도 나머지는 정상 동작
서버 리소스 허용 범위 내에서 처리량 확장 가능

단점

스레드 생성 비용 높음 → 요청 폭주 시 응답 지연
컨텍스트 스위칭(Context Switching) 비용 발생
OS가 CPU를 한 스레드에서 다른 스레드로 전환할 때 발생
스레드 생성이 무제한 → 리소스 한계 초과 시 서버 다운 위험

스레드 풀(Thread Pool)로 해결하기

요청마다 스레드를 만들 때 생기는 문제를 해결하기 위해 스레드 풀을 사용할 수 있다.

스레드 풀은 필요한 스레드를 보관하고 관리하는 곳이다.

스레드 풀에 생성 가능한 스레드의 최대치를 관리한다. 예를 들어 톰캣은 최대 200개가 기본 설정이며, 변경 가능하다.

동작 방식

필요한 스레드를 미리 생성해 스레드 풀에 보관한다.
요청이 들어오면 풀에서 스레드를 꺼내 사용한다.
사용 완료 후 다시 풀에 반납한다.

장점

스레드 생성/소멸 비용(CPU) 절감 → 응답 속도 향상
최대 스레드 수 제한으로 요청 폭주에도 안정적 처리 가능

단점

스레드 풀이 너무 클 경우 → 메모리 낭비

실무 팁

WAS 튜닝 핵심 : 최대 스레드(max thread) 수
- 너무 낮으면 → 동시 요청 많을 때 지연 발생
- 너무 높으면 → CPU/메모리 한계 초과, 서버 다운
장애 대응
- 클라우드 환경 : 서버 수 늘리고 튜닝
- 온프레미스 : 최대 스레드 수 최적화 필요

적정 스레드 수

애플리케이션 로직, CPU/메모리, IO 리소스 상황에 따라 다름 → 실제 서비스와 유사한 성능 테스트 필수
성능 테스트 도구 : Apache AB, JMeter, nGrinder

WAS와 멀티 스레드

멀티 스레드는 복잡하고 신경써야 하는 부분이 많은데,

WAS가 있기 때문에 개발자는 멀티 스레드 관련 코드를 신경쓰지 않아도 된다.

WAS가 멀티 스레드 처리를 담당 → 개발자는 싱글 스레드처럼 코딩 가능
단, 싱글톤 객체(서블릿, 스프링 빈) 사용 시 주의
- 공유 변수/멤버 변수는 동시 접근 문제 발생 가능 → 스레드 안전 필요

추가 개념

스레드 안전(Thread Safety) : 여러 스레드가 동시에 접근해도 데이터 일관성 유지
동시성 문제(Concurrency Issue) : race condition, deadlock
자바 스레드 풀 활용 예시 : ExecutorService, ThreadPoolExecutor

[Docker] Dockerfile 개념 및 사용법

개발곰발 — Fri, 5 Sep 2025 11:26:19 +0900

인프런 <비전공자도 이해할 수 있는 Docker 입문/실전> 강의를 토대로 정리한 내용입니다.

도커파일(Dockerfile)

도커파일(Dockerfile) : Docker 이미지를 만들기 위한 파일. 텍스트 파일로 작성되며, 확장자는 Dockerfile이다.

Dockerfile은 다음과 같이 만들 수 있다. 아래 Dockerfile은 강의 실습용으로 간단하게 작성한 것이다.

Dockerfile 명령어

Dockerfile 명령어 요약
▪️FROM : 베이스 이미지 생성, 모든 Dockerfile은 FROM으로 시작하며, 태그명을 적지 않을시 최신 버전 사용
▪️COPY : 호스트 파일을 복사해 컨테이너로 전달
▪️RUN : 이미지 생성 과정 중 컨테이너 내에서 명령어 실행
▪️ENTRYPOINT : 컨테이너 시작 시 항상 실행
▪️WORKDIR : 작업 디렉터리 설정
▪️EXPOSE : 컨테이너 포트 공개

Spring Boot 프로젝트 실행 - FROM, COPY, ENTRYPOINT

FROM, COPY, ENTRYPOINT 명령어를 사용해 Spring Boot 프로젝트를 Docker로 실행시켰다.

FROM openjdk:17-jdk

COPY build/libs/*SNAPSHOT.jar app.jar

ENTRYPOINT ["java", "-jar", "/app.jar"]

위 Dockerfile에서는 JDK 17 베이스 이미지로 컨테이너를 띄웠다. Spring Boot 프로젝트는 .jar 파일(여러 개의 클래스 파일, 리소스, 메타데이터를 하나로 묶은 압축 파일)을 실행시켜야 하는데, 지금은 컨테이너 환경에서 실행시켜야 한다. 따라서 해당 파일을 컨테이너로 복사해줘야 한다.

COPY build/libs/*SNAPSHOT.jar app.jar는 build/libs/ 안 SNAPSHOT.jar로 끝나는 파일을 컨테이너 안 app.jar로 복사하겠다는 의미다.
ENTRYPOINT ["java", "-jar", "/app.jar"]는 컨테이너가 실행될 때 최초로 실행시킬 명령어를 작성한 것이다.

.dockerignore 파일을 통해 특정 파일 또는 폴더를 COPY 하지 못하도록 할 수 있다.

Next.js 프로젝트 실행 - RUN, WORKDIR, EXPOSE

다음과 같이 Dockerfile을 작성해 Next.js 프로젝트를 Docker로 실행시켰다. 이번에는 RUN, WORKDIR, EXPOSE 명령어도 함께 사용했다.

FROM node

WORKDIR /app

COPY . .

RUN npm install

RUN npm run build

EXPOSE 3000

ENTRYPOINT [ "node", "dist/main.js" ]

위 Dockerfile에서는 node 베이스 이미지로 컨테이너를 띄웠고, app 이라는 폴더 안에 파일들이 복사되도록 작성했다. 또한 호스트에 있는 모든 파일을 복사해 컨테이너로 가져간다.

RUN npm install와 RUN npm run build는 컨테이너에서 Next.js를 실행시키고 패키지, 의존성, 라이브러리들을 설치하는 명령어를 실행한다.
EXPOSE 3000은 있으나 없으나 작동하는 방식에는 영향을 미치진 않고, 3000번 포트에서 실행될 것이라고 문서화하는 역할을 한다.

[MySQL] 날짜 범위 필터링하기

개발곰발 — Thu, 28 Aug 2025 10:16:14 +0900

SQL로 데이터를 조회하다 보면 특정 기간의 데이터를 가져와야 할 때가 많다.
예를 들어, "2022년 10월에 작성된 글만 조회" 같은 조건이 필요하다.

사실 나는 SQL 문제를 풀 때 LIKE 문법이 익숙해서 자주 사용하는데, 날짜 범위 필터링을 하는 방법은 더 많다.

따라서 날짜 범위 필터링 시 자주 쓰이는 SQL 문법들을 정리해봤다.

LIKE

WHERE CREATED_DATE LIKE '2022-10%'

LIKE는 문자열 비교 연산자로, '2022-10%' 라는 패턴을 주면, '2022-10'으로 시작하는 문자열을 찾아준다.

장점 : 간단하고 직관적인 문법
단점 : DATE 타입보다는 VARCHAR 처럼 문자열로 저장된 날짜에 적

BETWEEN

WHERE CREATED_DATE BETWEEN '2022-10-01' AND '2022-10-31'

BETWEEN A AND B는 A 이상 B 이하 범위를 의미한다. 즉, '2022-10-01' <= CREATED_DATE <= '2022-10-31' 조건과 동일하다. 단, 컬럼이 DATETIME 타입이라면 마지막 날짜를 '2022-10-31 23:59:59'까지 지정해야 안전하다. 이 문제를 해결하기 위해서는 아래 DATE() 함수를 참고하자.

장점 : 뛰어난 가독성
단점 : CREATED_DATE가 DATETIME일 경우 문제 발생 ('2022-10-31'은 2022-10-31 00:00:00까지만 포함)

DATE()

WHERE DATE(CREATED_DATE) BETWEEN '2022-10-01' AND '2022-10-31'

DATE() 함수는 DATETIME에서 날짜 부분(YYYY-MM-DD)만 잘라내는 함수로, 위에서 언급한 문제점을 해결할 수 있다. 그러나 날짜만 추출해서 비교해야 하기 때문에 인덱스에 있는 값 그대로는 비교할 수 없다. 따라서 DB는 모든 행을 하나씩 읽어서 DATE() 함수를 계산해야 조건을 판별할 수 있다. 이 과정 때문에 인덱스를 그대로 활용할 수 없고, 결국 Full Table Scan(테이블 전체 스캔)이 일어나 성능이 떨어질 수 있다.

장점 : DATETIME 컬럼에서도 정확히 원하는 날짜만 비교 가능
단점 : 컬럼에 함수를 적용(DATE(CREATED_DATE))하면 DB가 인덱스를 활용하지 못함. 즉, 데이터가 많아질수록 성능이 급격히 느려질 수 있음

YEAR() + MONTH()

WHERE YEAR(CREATED_DATE) = 2022 AND MONTH(CREATED_DATE) = 10

YEAR() 함수: 날짜에서 연도를 추출
MONTH() 함수: 날짜에서 월을 추출

각 함수로 날짜에서 연도, 월을 추출해 2022년 10월 데이터만 걸러낼 수 있다.

그러나 역시 DATE()를 사용할 때와 같은 단점이 있다.

장점 : 읽고 이해하기 쉬움
단점 : DATE()와 마찬가지로 인덱스를 사용하지 못하고, 성능이 떨어질 수 있음

>= AND <

WHERE CREATED_DATE >= '2022-10-01'
  AND CREATED_DATE < '2022-11-01'

시작일 이상(>= '2022-10-01') 다음 달 1일 미만(< '2022-11-01') 의 데이터를 구하는 쿼리다.10월 1일부터 10월 31일까지 모든 데이터가 포함된다. 가장 권장되는 방식이다.

장점 : DATE / DATETIME 모두 안정적으로 처리 가능, 인덱스 활용 가능
단점 : 문법이 장황해 보일 수 있음

[Docker] Docker Volume 개념 및 사용법

개발곰발 — Fri, 22 Aug 2025 15:48:18 +0900

인프런 <비전공자도 이해할 수 있는 Docker 입문/실전> 강의를 토대로 정리한 내용입니다.

도커볼륨(Docker Volume)

도커볼륨(Docker Volume) : 도커 컨테이너에서 데이터를 영속적으로 저장하기 위한 방법. 호스트 자체의 저장공간을 공유해 사용하는 형태.
특정 프로그램을 컨테이너로 띄우고 나서 기능이 추가되면 새로운 이미지를 만들어 컨테이너를 실행시켜야 한다. 이 때 새로운 컨테이너를 통째로 갈아끼우는 방식으로 교체하는데, 그렇게 하면 기존 컨테이너 내부의 데이터도 같이 삭제된다. 따라서 볼륨이라는 개념을 사용해 삭제되면 안되는 데이터를 저장할 수 있다.

도커볼륨(Docker Volume) 사용하기

볼륨을 사용할 때는 -v를 입력하고 호스트와 컨테이너의 절대 경로를 다음과 같이 입력해야 한다.

$ docker run -v [호스트의 디렉토리 절대경로]:[컨테이너의 디렉토리 절대경로] [이미지명]:[태그명]

-v : 호스트의 경로(1번)를 빌려서 2번 경로와 공유해서 쓰겠다는 의미.
[호스트의 디렉토리 절대경로] 에 디렉토리가 이미 존재할 경우, 호스트의 디렉터리가 컨테이너의 디렉터리를 덮어씌운다.
[호스트의 디렉토리 절대경로] 에 디렉토리가 존재하지 않을 경우, 호스트의 디렉터리 절대 경로에 디렉터리를 새로 만들고 컨테이너의 디렉터리에 있는 파일들을 호스트의 디렉터리로 복사해온다.

이것만 봐서는 어떻게 써야할지 막막한데, Docker로 MySQL를 실행시키는 실습을 통해 볼륨을 사용하는 방법을 자세히 알아보자.

패스워드 옵션과 함께 MySQL 실행하기

먼저 mysql을 실행시켰는데, docker ps로 보니 아무것도 떠있지 않다. docker ps -a로 확인해보니 중지된 mysql이 있고, 로그를 살펴보니 패스워드 옵션이 정의되지 않아 실행되지 못한 것이었다. 패스워드 옵션은 아래와 같이 알려주기도 하지만 DockerHub에서 찾을 수 있다.

다음과 같이 -e 옵션을 추가한 뒤 패스워드 옵션을 주고 다시 실행했다.

$ docker run -e MYSQL_ROOT_PASSWORD=password -d -p 3306:3306 mysql

다시 docker ps로 확인해보니 정상적으로 실행된 것을 알 수 있다.

컨테이너 안으로 들어가 직접 확인해보니 설정했던 비밀번호인 password가 잘 들어있는 것을 확인할 수 있다.

MySQL 컨테이너로 들어가 데이터베이스 만들기

이제 mysql 컨테이너에서 데이터베이스를 만들고, 컨테이너를 삭제했다가 다시 실행했을 때 해당 데이터베이스가 남아있는지 살펴볼 것이다. 여기서 볼륨이 필요한 이유를 알 수 있다.

컨테이너로 들어가서 mysql -u root -p 명령어로 mysql 내부로 들어간다. 처음 컨테이너를 만들 때 설정한 패스워드를 치고 들어가면 된다.

이렇게 mydb라는 새로운 데이터베이스를 만들고 컨테이너를 삭제 후 다시 만들었다. 그리고나서 다시 mysql로 들어가 확인해보니 mydb라는 데이터베이스가 사라졌다. 이런 상황을 방지하기 위해 볼륨을 사용해 컨테이너를 띄울 수 있다.

# 컨테이너 종료
$ docker stop [MySQL 컨테이너 ID]
$ docker rm [MySQL 컨테이너 ID]

# 컨테이너 생성
$ docker run -e MYSQL_ROOT_PASSWORD=password -p 3306:3306 -d mysql
$ docker exec -it [MySQL 컨테이너 ID] bash

$ mysql -u root -p
mysql> show databases; # 아까 생성한 데이터베이스가 없어진 걸 확인할 수 있다.

볼륨을 활용해 MySQL 띄우기

위에서 본 도커 볼륨을 사용하는 방법을 다시 보자.

$ docker run -v [호스트의 디렉토리 절대경로]:[컨테이너의 디렉토리 절대경로] [이미지명]:[태그명]

실습에서는 다음과 같이 작성했다. docker-mysql 폴더는 미리 만들어두었다. 그리고 pwd 명령어를 통해 출력된 경로를 [호스트의 디렉토리 절대경로]로 둔다.

$ docker run -e MYSQL_ROOT_PASSWORD=password -p 3306:3306 -v /home/won/docker-mysql/data:/var/lib/mysql -d mysql

참고로 컨테이너의 디렉토리 절대경로는 DockerHub에서 MySQL을 검색한 후 나오는 공식 문서를 통해 알 수 있다.

처음 데이터베이스를 만들었을 때와 마찬가지로, 컨테이너를 실행시킨 후 컨테이너 안의 mysql로 들어가 mydb 라는 데이터베이스를 만들어준다.

그리고 다시 컨테이너를 삭제 후, 다시 컨테이너를 생성해보면 mydb가 남아있는 것을 볼 수 있다. 볼륨을 사용하지 않았을 때는 사라졌었지만, 볼륨을 사용하니 삭제되지 않고 그대로 존재한다.

MYSQL_ROOT_PASSWORD를 바꿔서 명령어를 실행하면?
최초로 MySQL 띄울 때 설정한 데이터베이스 비밀번호가 호스트의 저장공간에 저장되기 때문에 컨테이너를 새로 띄워서 값을 바꿨다고 해도 기존의 값이 있어서 바뀌지 않는다. 따라서 비밀번호를 바꾸고 싶다면 MySQL 자체에서 비밀번호를 바꾸는 명령어를 날리거나 처음 저장한 MySQL 데이터 (실습에서는 data 자체)를 지워야 한다.

[Docker] 도커 주요 명령어 정리

개발곰발 — Mon, 18 Aug 2025 17:42:15 +0900

인프런 <비전공자도 이해할 수 있는 Docker 입문/실전> 강의를 토대로 정리한 내용입니다.

이미지(Image) 관련 명령어

이미지 다운로드

docker pull [이미지명]

$ docker pull nginx

최신 버전 이미지 다운로드. docker pull nginx:latest와 동일하게 작동

docker pull [이미지명:태그명]

$ docker pull nginx:stable-perl

특정 버전 이미지 다운로드. dockerhub에서 태그명 확인 가능

이미지 조회

docker image ls

$ docker image ls

다운받은 모든 이미지 조회
- REPOSITORY : 이미지 이름
- TAG : 이미지 태그명
- IMAGE ID : 이미지 ID
- CREATE : 이미지가 생성된 날짜(다운받은 날짜 X)
- SIZE : 이미지 크기

이미지 삭제

docker image rm [이미지 ID 또는 이미지명]

$ docker image rm nginx

$ docker image rm 07a

컨테이너에서 사용하고 있지 않은 특정 이미지 삭제
이미지 ID 입력 시, ID의 일부만 입력 가능

docker image rm -f [이미지 ID 또는 이미지명]

$ docker image rm -f nginx

중지된 컨테이너에서 사용하고 있는 특정 이미지 삭제
실행 중인 컨테이너에서 사용하고 있는 이미지는 강제 삭제 불가

docker image rm $(docker images -q)

$ docker image rm $(docker images -q)

컨테이너에서 사용하고 있지 않은 이미지만 전체 삭제

docker image rm -f $(docker images -q)

$ docker image rm -f $(docker images -q)

컨테이너에서 사용하고 있는 이미지를 포함해서 전체 이미지 삭제

컨테이너(Container) 관련 명령어

컨테이너 생성 / 실행

docker create 이미지명[:태그명]

$ docker create nginx

docker start 컨테이너명[또는 컨테이너 ID]

$ docker start 컨테이너명[또는 컨테이너 ID]

docker run 이미지명[:태그명]

$ docker run nginx

이미지를 바탕으로 컨테이너 생성 후 실행 (이미지가 없을 시 DockerHub에서 이미지를 다운받아 실행)
포그라운드에서 실행 → 추가적인 명령어 조작 불가

❓ 포그라운드와 백그라운드
포그라운드 : 내가 실행시킨 프로그램의 내용이 화면에서 실행되고 출력되는 상태
백그라운드 : 내가 실행시킨 프로그램이 컴퓨터 내부적으로 실행되는 상태

docker run -d --name [컨테이너 이름] 이미지명[:태그명]

$ docker run -d --name my-web-server nginx

컨테이너에 이름 붙여서 생성 및 실행

docker run -d -p [호스트 포트]:[컨테이너 포트] 이미지명[:태그명]

$ docker run -d -p 4000:80 nginx

도커를 실행하는 호스트의 4000번 포트를 컨테이너의 80번 포트로 연결하도록 설정

컨테이너 조회

docker ps

$ docker ps # 실행중인 컨테이너 조회
$ docker ps -a # 모든 컨테이너 조회

컨테이너 중지 / 삭제

docker stop 컨테이너명[또는 컨테이너 ID]

$ docker stop {nginx를 실행시킨 Contnainer ID}

docker rm 컨테이너명[또는 컨테이너 ID]

$ docker rm {nginx를 실행시킨 Contnainer ID}

중지되어 있는 특정 컨테이너 삭제

docker rm -f 컨테이너명[또는 컨테이너 ID]

$ docker rm -f 컨테이너명{nginx를 실행시킨 Contnainer ID}

실행되고 있는 특정 컨테이너 삭제

docker rm -f $(docker ps -qa)

$ docker rm -f $(docker ps -qa)

중지되어 있는 모든 컨테이너 삭제

docker kill 컨테이너명[또는 컨테이너 ID]

$ docker kill {nginx를 실행시킨 Contnainer ID}

특정 컨테이너 강제 중지

컨테이너 로그 조회

docker logs [컨테이너 ID 또는 컨테이너명]

$ docker run -d nginx
$ docker logs [nginx가 실행되고 있는 컨테이너 ID]

특정 컨테이너의 모든 로그 조회

dokcer logs --tail [로그 끝부터 표시할 줄 수] [컨테이너 ID 또는 컨테이너명]

$ dokcer logs --tail 10 [컨테이너 ID 또는 컨테이너명]

최근 로그 10줄만 조회

docker logs -f [컨테이너 ID 또는 컨테이너명]

$ docker run -d -p 80:80 nginx
$ docker logs -f

기존 로그도 조회하면서 생성되는 로그를 실시간으로 볼 때

docker logs --tail 0 -f [컨테이너 ID 또는 컨테이너명]

$ docker logs --tail 0 -f [컨테이너 ID 또는 컨테이너명]

기존 로그는 조회하지 않고 생성되는 로그를 실시간으로 볼 때

짧은 인턴을 마치고...

개발곰발 — Fri, 8 Aug 2025 20:09:08 +0900

들어가며

부트캠프를 수료하고 나서, 실제 개발 현장을 경험할 수 있는 한 달간의 인턴 기회가 생겼다. 부트캠프에서는 요구사항이 명확히 주어지고 팀원들과 함께 처음부터 만들어가는 구조였다면, 실무는 달랐다. 기존 코드베이스를 파악하고, 외부 시스템과 연동하고, 직접 본 적 없는 사람들과 소통하며 결과물을 만들어야 했다. 기대했던 경험을 모두 얻진 못했지만, 그 과정에서 오히려 더 본질적인 것들을 배웠다.

1주차 : 낯선 코드베이스에서 맥락을 읽는 법

첫 배정 업무는 커머스 서비스의 기존 코드 분석이었다. Postman으로 API 테스트를 진행하며 전체 데이터 흐름을 파악했고, 코드 구조가 실제 서비스 로직과 어떻게 연결되어 있는지 직접 추적했다.

분석 과정에서 한 가지 공백을 발견했다. 카테고리 구조가 아직 정의되어 있지 않은 상태였다. 기획 없이 개발을 진행할 수 없다고 판단해, 직접 카테고리 체계를 설계하고 스프레드시트로 정리한 뒤 컨펌을 받아 진행했다. 개발자가 구현만 담당하는 게 아니라, 요구사항이 불명확한 상황에서 스스로 맥락을 정의하고 진전시켜야 할 때도 있다는 걸 처음 체감한 순간이었다.

코드 작업으로는 Shopify 기반의 Liquid·JS 코드를 수정해 설계한 카테고리 구조를 반영했고, 기존 코드를 리팩토링하면서 두 가지 원칙을 적용했다.

단일 책임 원칙 (SRP) : 하나의 메서드가 하나의 역할만 하도록 분리해, 변경 영향 범위를 좁혔다.
캡슐화 : 외부에 노출이 불필요한 내부 구현을 숨겨, 의존성이 불필요하게 퍼지는 것을 차단했다.

이론으로 배웠던 원칙들을 실제 코드에 적용하는 작업은 생각보다 훨씬 판단이 많이 필요한 일이었다.

2~4주차 : 외부 API 연동 백엔드 개발

중반부터는 두 개의 외부 플랫폼 API를 연동하는 백엔드 개발을 맡았다. 부트캠프에서는 외부 API를 직접 다룬 경험이 없었기 때문에, 공식 문서를 꼼꼼히 읽고 Postman으로 동작을 검증하면서 연동 방식을 파악하는 것부터 시작했다.

API 명세서 : 구현 전에 먼저 정의한다

혼자 백엔드를 담당하는 구조였기 때문에 API 명세도 직접 처음부터 작성했다. 총 29개의 API를 노션으로 상세하게 정리했고, 작성 과정에서 의식적으로 프론트엔드 관점을 먼저 고려했다.

어떤 데이터를 응답에 포함시켜야 하는가
에러 케이스는 어떤 형태로 내려줘야 하는가
필드명은 사용하는 쪽 입장에서 직관적인가

명세는 마지막 주까지 피드백을 받으며 수정했다. 이 과정에서 명확한 문서가 단순히 "기록"이 아니라, 협업 속도와 커뮤니케이션 비용을 직접 결정한다는 걸 체감했다.

구현한 주요 기능

API	주요 처리 내용
토큰 저장 시 유저 정보 DB 저장	외부 API 3개 호출로 사용자 정보·스토어명·활성 상품 수 조회 후 저장
스토어 목록 조회	토큰 만료일 포함 응답 처리
상품 조회	외부 API 연동 및 응답 가공

중복 제거 : ArgumentResolver + 커스텀 어노테이션 적용

구현 과정에서 기존 코드의 구조적 문제를 발견했다. 토큰 추출 로직이 컨트롤러의 모든 메서드에 동일하게 반복되고 있었다. 단순 중복인 것처럼 보이지만, 이 구조에서는 추출 방식이 바뀌면 모든 메서드를 일일이 수정해야 했다.

수정 방식보다 구조를 바꾸는 게 맞다고 판단해, Spring MVC의 ArgumentResolver를 활용하는 방향으로 개선했다. 컨트롤러 메서드 파라미터에 @EbayToken 어노테이션만 붙이면 토큰 추출이 자동으로 처리되도록 하고, 이 ArgumentResolver를 Spring MVC에 등록해 모든 컨트롤러에서 재사용할 수 있게 했다.

// 개선 전: 토큰 추출 로직이 모든 메서드에 반복
String token = request.getHeader("Authorization").replace("Bearer ", "");

// 개선 후: 어노테이션만 붙이면 Spring MVC가 자동으로 처리
public ResponseEntity<?> getItems(@EbayToken String token) { ... }

변경 이후에는 토큰 처리 로직이 한 곳에서만 관리되기 때문에, 이후 수정이 생기더라도 ArgumentResolver 하나만 고치면 된다.

외부 클라이언트 소통

혼자 백엔드를 담당하다 보니, 직접 외부 클라이언트와 소통할 일도 생겼다. 계정 인증 이슈나 API 계정 발급 요청 등을 전화·메시지·메일로 처리했다. 업무 맥락에서 외부와 소통하는 것이 처음이라 처음에는 어색했지만, 기술적인 상황을 상대방이 이해할 수 있는 언어로 전달하는 연습이 됐다.

돌아보며 : 한 달이 남긴 것

기대했던 것과 달랐던 점, 그래서 배운 것

코드 리뷰와 함께하는 협업을 기대했지만, 구조상 혼자 판단해야 하는 상황이 많았다. 처음에는 답답했지만, 오히려 그 과정이 스스로 기준을 세우는 연습이 됐다. '이 코드가 좋은가?'를 스스로 판단해야 했기 때문에, 단순 구현보다 설계 이유를 더 깊이 고민하게 됐다.

프론트엔드와 처음 협업하면서 인증 토큰 처리를 내부에서 해줬어야 하는 부분을 초기에 놓쳤다. 경험 부족에서 비롯된 실수였지만, 이후 API를 설계할 때 "호출하는 쪽이 신경 써야 하는 것을 최소화하자"는 원칙을 의식적으로 적용하게 된 계기가 됐다.

실무에서 다시 확인한 것들

외부 API 연동은 문서 읽기에서 시작된다. 잘 모르는 시스템을 다룰 때 가장 먼저 해야 할 일은 공식 문서를 제대로 읽고, 직접 요청을 날려보며 동작을 확인하는 것이다. 이 순서가 익숙해지면 어떤 외부 시스템이든 처음의 막막함이 줄어든다.

문서화는 커뮤니케이션 비용을 결정한다. 명세가 명확할수록 질문이 줄고, 구현 속도가 빨라진다. 29개의 API 명세를 작성하면서 좋은 문서는 팀의 맥락을 공유하는 가장 효율적인 방법이라는 걸 느꼈다.

리팩토링은 코드를 고치는 게 아니라 구조를 바꾸는 것이다. 단순히 중복을 제거하는 것을 넘어, 변경이 생겼을 때 영향 범위를 최소화하는 구조를 고민하는 것이 진짜 리팩토링이라는 걸 실제 코드를 통해 배웠다.

마치며

한 달은 짧았다. 그렇지만 실제 서비스 코드를 분석하고, 외부 API를 직접 연동하고, 프론트엔드와 명세를 주고받으며 다듬어가는 경험은 부트캠프와는 결이 달랐다.

가장 크게 남은 질문은 이것이다. "내가 짠 코드는 유지보수하기 좋은 코드인가?" 혼자 작성하고 검증받지 못한 코드를 보면서, 코드 리뷰가 단순한 오류 수정이 아니라 더 나은 설계를 함께 만드는 과정이라는 걸 더 절실하게 이해하게 됐다. 다음에는 그 부분을 적극적으로 만들어가고 싶다.

[STUDY] 데이터베이스 핵심 개념 정리 : 정규화 · 인덱스 · 트랜잭션

개발곰발 — Thu, 26 Jun 2025 18:29:23 +0900

️ 데이터 베이스

데이터베이스(database) : 사용자나 프로그램에서 사용하기 위해 저장 및 관리하는 데이터 집합
- 개체(entity) : 데이터로 표현하려는 대상
- 속성(attribute) : 개체의 특성과 상태
- 관계(relationship) : 개체 간에 어떤 관련이 있는지 나타냄

관계형 데이터베이스

관계형 데이터베이스(RDB, Relational Database) : 데이터가 2차원 테이블에 저장되며, 데이터의 구조와 데이터 간 종속성 등을 알 수 있는 데이터베이스
- 릴레이션 : 관계형 데이터베이스에서 데이터의 개념적 모델
- 테이블 : 릴레이션을 실제로 구현한 개체로, 키-값으로 이루어진 2차원 형태
- 행(=튜플, 레코드) : 테이블을 구성하는 데이터들 중 가로로 묶은 데이터셋
- 열(=속성, 필드) : 테이블을 구성하는 데이터들 중 세로로 묶은 데이터셋

NoSQL 데이터베이스

NoSQL(Not Only SQL) 데이터베이스 : 비관계형 데이터베이스로, 보다 유연한 형태의 데이터베이스
- 대용량 데이터 조회시 속도 면에서 유리하다.
- 수평적 확장성이 좋아 서버를 추가해 데이터베이스를 확장하는 것이 쉽다.

관계형 데이터베이스 vs NoSQL 데이터베이스

구분	관계형 데이터베이스	NoSQL 데이터베이스
데이터 저장	2차원 테이블로 저장	분산형 구조로, 도큐먼트, 키-값, 그래프 등 다양한 형태로 저장
데이터 중복	중복 없음	중복 데이터가 있어서 데이터 갱신 시 이를 처리해야 함
스키마	스키마가 있어 데이터의 무결성 보장	스키마가 없고 유연한 데이터 처리 가능
데이터 확장	수직적 확장 지원	수평적 확장 지원
DBMS	Oracle, MySQL	MongoDB, Redis

인덱스

인덱스 : 추가적인 쓰기 작업과 저장 공간을 활용해 데이터베이스에서 튜플의 검색 성능을 높이기 위한 자료구조. 주로 조회 조건에 자주 사용되는 컬럼(WHERE절), JOIN에 자주 사용되는 컬럼, 정렬이나 GROUP BY에 사용되는 컬럼에 인덱스를 건다.

인덱스는 데이터베이스의 성능을 향상시키기 위해 일반적으로 사용되는 방법이다. 키-값 형태로 '속성 값 - 튜플 주소'를 인덱스 테이블에 저장한다. 인덱스 테이블은 다음처럼 속성값을 기준으로 정렬 상태를 유지한다.

하지만 인덱스를 사용한다고 항상 성능이 좋은 것은 아니다. 우선 인덱스 테이블 자체로 추가적인 공간이 필요해진다. 또한 데이터를 추가하면 다시 데이터를 재정렬해야 하고, 튜플이 삭제되는 경우 인덱스 테이블에서는 '사용하지 않음' 처리가 되지만 실제로 삭제되지 않고 테이블에 남아있다.

인덱스의 장단점을 정리하면 다음과 같다.

장점

인덱스 테이블에 데이터가 정렬되어 있어서 검색 속도가 빠르다.

단점

인덱스 테이블을 저장하기 위한 추가 공간이 필요하다.
정렬된 상태를 유지하기 위해 데이터를 추가, 수정, 삭제하는 경우 속도가 느리다.

인덱스 구현 방법

해시 테이블 인덱스

해시 테이블(hash table) : 속성 값으로 해시 값을 계산해 인덱싱하는 방법
장점
- O(1) 수준의 빠른 탐색
- 캐시 효율이 좋아 메모리 엔진 등에 적합
단점
- 범위 검색, 정렬이 필요한 연산 불가능
- 해시 충돌 발생 시 성능 저하 가능성

B+ 트리

B+ 트리(Balanced Tree) : 단말 노드에만 데이터를 저장하고 단말 노드 간에는 연결 리스트로 연결되는 방식
MySQL, PostgreSQL, Oracle 등 대부분의 DBMS의 기본 인덱스 구조
장점
- 정렬된 구조를 유지해 범위 검색에 강함
- O(log n) 탐색 시간
단점
- 삽입/삭제 시 노드 분할 또는 병합이 필요해 해시보다 약간 느림

트랜잭션

트랜잭션이란

트랜잭션(transaction) : 데이터베이스의 상태를 바꾸기 위해 수행하는 작업의 단위 또는 일련의 연산

ACID 특성

원자성(Atomicity) : 트랜잭션이 데이터베이스에 완전히 반영되거나 아예 실행되지 않아야 한다.
일관성(Consistency) : 트랜잭션 수행이 완료된 데이터베이스는 일관성이 있다.(데이터 무결성 유지)
독립성(Isolation) : 수행 중인 트랜잭션에 다른 트랜잭션이 끼어들 수 없다.
영속성(Durability) : 완료한 트랜잭션의 결과가 데이터베이스에 영구적으로 반영된다.

데드락

데드락(deadlock) : 두 개 이상의 트랜잭션이 서로가 점유한 자원을 기다리면서 무한 대기 상태에 빠지는 현상
데드락 방지 방법
- 트랜잭션 수행 전 미리 락 획득
- 트랜잭션이 들어온 순서에 따라 락을 획득하거나 특랜잭션을 종료

정규화와 역정규화

이상

이상(anomaly) : 트랜잭션 처리 중 속성 간 종속이나 데이터 중복으로 발생하는 문제
- 삽입 이상(insertion anomaly) : 데이터 삽입 시 의도치 않은 다른 데이터도 삽입된다.
- 갱신 이상(update anomaly) : 데이터 갱신 시 일부 튜플만 갱신되어 데이터 모순이 발생한다.
- 삭제 이상(deletion anomaly) : 데이터 삭제 시 의도하지 않은 데이터도 삭제된다.

정규화 단계

정규화(normalization) : 데이터베이스의 이상 현상을 해결하기 위해 테이블을 분해하는 것
- 데이터의 일관성, 최소한의 데이터 중복, 최대한의 데이터 유연성을 위한 방법
- 테이블을 분해하느라 연산 시간 증가 →상황에 따른 적절한 정규화 필요

제1정규형(1NF, First Normal Form)

제1정규형은 테이블의 모든 속성 값이 더 이상 분해될 수 없는 값(원자 값)으로 구성되어야 한다.

예를 들어, 전화번호가 이렇게 쉼표로 두 개가 들어가 있으면 쿼리를 짜기도 어렵고, 데이터 분석이 힘들어진다.

학생이름	전화번호
홍길동	010-1111-2222, 010-3333-4444

따라서 '전화번호' 속성에 속성 값이 하나만 존재할 수 있도록 다음고 같이 테이블을 분해한다.

학생이름	전화번호
홍길동	010-1111-2222
홍길동	010-3333-4444

제2정규형(2NF, Second Normal Form)

제2정규형은 제1정규형을 만족하고, 부분적 함수 종속을 제거해 완전 함수 종속을 만족해야 한다.

예를 들어, 아래와 같이 홍길동이 과목을 여러 개 들을 때마다 이름이 계속 중복되고 있다. 여기서 학생이름은 학생 ID에만 종속되므로 부분 종속되어 있다고 할 수 있다. 이 경우 제2정규형을 위반하게 된다.

학생ID	과목ID	점수	학생이름
1	A	90	홍길동
1	B	85	홍길동
2	A	88	김철수

따라서 다음과 같이 학생 테이블과 수강 테이블로 나눌 수 있다.

‍ 학생 테이블

학생ID	학생이름
1	홍길동
2	김철수

수강 테이블

학생ID	과목ID	점수
1	A	90
1	B	85
2	A	88

제3정규형(3NF, Third Normal Form)

제3정규형은 제2정규형을 만족하고, 이행적 종속이 없어야 한다.

아래 테이블을 보면 부서 이름은 부서 ID에 종속되고, 부서 ID는 직원 ID에 종속되어있다.

직원ID	부서ID	부서이름
1	10	인사팀
2	20	개발팀
3	10	인사팀

따라서 다음과 같이 이행 종속을 제거해 직원 테이블과 부서 테이블로 분리할 수 있다.

‍ 직원 테이블

직원ID	부서ID
1	10
2	20
3	10

부서 테이블

부서ID	부서이름
10	인사팀
20	개발팀

역정규화

역정규화(denormalization ) : 정규화된 테이블을 낮은 정규화 단계의 테이블로 되돌리는 것

역정규화를 하는 이유?
정규화는 데이터 중복을 제거하고 정합성을 높이는 데 효과적이지만, 테이블이 지나치게 분리되면 조인이 많아져 조회 성능이 떨어질 수 있다. 따라서 조회 성능이 중요한 상황에서는 일규 정규화 구조를 풀고 중복을 허용해 쿼리 성능을 개선하기 위해의도적으로 역정규화를 적용한다.

참고자료

기술 면접 대비 CS 전공 핵심요약집 | 이수진 - 교보문고

기술 면접 대비 CS 전공 핵심요약집 | 1분 1초가 아쉬운 취업/이직 준비생을 위해 기술 면접에 필요한 CS 전공의 핵심 내용만 간추렸다!비전공자는 물론 IT 전공자라도 광범위한 CS 전공 중에 어떤

product.kyobobook.co.kr

신입 개발자 기술면접 질문 정리 - 데이터베이스

데이터베이스의 특징에 대해 설명해주세요. 실시간 접근성(Real-Time Accessibility) : 비정형적인 질의(조회)에 대하여 실시간 처리에 의한 응답이 가능해야 하며, 지속적인 변화(Continuous Evloution) :

dev-coco.tistory.com

GitHub - WooVictory/Ready-For-Tech-Interview: 신입 개발자로서 지식을 쌓기 위해 공부하는 공간 ‍

신입 개발자로서 지식을 쌓기 위해 공부하는 공간 ‍ . Contribute to WooVictory/Ready-For-Tech-Interview development by creating an account on GitHub.

github.com

[STUDY] Spring IoC/DI와 객체지향 설계 원칙

개발곰발 — Thu, 19 Jun 2025 18:39:42 +0900

⭐ 객체지향 설계가 중요한 이유

객체 지향 프로그래밍은 객체를 중심으로 시스템을 구성하는 방식이다. 현실 세계의 사물이나 사건을 하나의 객체로 보고, 이런 객체들 간의 상호작용을 중심으로 프로그래밍한다. 복잡한 시스템일수록 기능을 분리하고, 역할을 명확히 나눈 구조가 필요하다. 객체지향은 이러한 확장성과 유지보수성을 높이기 위한 핵심 설계 방식이다. Spring은 객체지향 설계를 전제로 만들어진 프레임워크로, 특히 IoC와 DI는 객체 간의 관계를 유연하게 구성하고 관리하는 데 중요한 역할을 한다.

OOP 특징과 설계 원칙

객체 지향의 4가지 핵심 개념

추상화( Abstraction )

불필요한 세부 사항을 감추고 핵심적인 동작이나 속성만 드러내는 것

List 인터페이스를 사용할 때 내부 구조는 몰라도 add()나 get() 같은 기능만 사용하면 된다.

캡슐화( Encapsulation )

객체의 내부 상태를 감추고, 외부에서는 정해진 방식으로만 접근하게 하는 것

필드를 private으로 감추고 getter/setter를 사용하는 방식으로 캡슐화할 수 있다.
추상화와 캡슐화는 모두 '정보 은닉'을 기반으로 하지만, 추상화는 '무엇을 제공할지', 캡슐화는 '무엇을 감출지'에 초점을 둔다.

상속( Inheritance )

기존 클래스를 확장하여 새로운 클래스를 정의하는 것

공통 기능을 부모 클래스에 정의해두고, 자식 클래스는 이를 물려받아 재사용할 수 있다.

다형성( Polymorphism )

한 객체가 여러 타입의 객체로 취급될 수 있는 능력

다형성을 활용하면 중복을 제거하고, 변경사항이 생겨도 코드를 크게 고치지 않고 재사용할 수 있다.

이전에 자바 강의를 보며 다형성에 대해 공부하고 정리한 내용이다.

[Java/Study] 김영한의 실전 자바 기본 - 스터디 5회차

인프런 강의 을 보고 정리한 내용입니다.매주 모여 각자 정리한 내용을 기반으로 발표하고 질문 공유하는 스터디입니다.다형성(Polymorphism)객체 지향 프로그래밍의 특징 중 하나인 다형성은 한

3uomlkh.tistory.com

SOLID 원칙

SRP ( 단일 책임 원칙 )

하나의 클래스는 하나의 책임만 가져야 한다.

OCP ( 개방-폐쇄 원칙 )

확장에는 열려 있고, 변경에는 닫혀 있어야 한다.

LSP ( 리스코프 치환 원칙 )

자식 클래스는 부모 클래스를 대체할 수 있어야 한다.

ISP ( 인터페이스 분리 원칙 )

클라이언트에 맞는 인터페이스를 분리해 제공해야 한다.

DIP ( 의존 역전 원칙 )

프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안 된다.

IoC와 DI 이해하기

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

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것.

객체 생성이나 의존성 관리 같은 책임을 프레임워크가 대신 담당하는 개념이다.

️ IoC란 무엇인가요? 왜 필요한가요?
IoC는 제어의 역전(Inversion of Control)을 뜻하며, 객체 생성이나 의존성 관리 같은 책임을 개발자가 아니라 프레임워크가 대신 담당하는 개념입니다. Spring에서는 IoC 컨테이너가 객체를 생성하고, 필요한 의존성을 주입해줍니다. 이로 인해 객체 간 결합도가 낮아지고, 테스트나 유지보수가 용이해집니다.

의존성 주입( Dependency Injection, DI)

객체 간의 의존 관계를 외부에서 주입받는 방식

Spring에서는 생성자, 필드, 세터 주입 방식이 있다.
DI를 통해 구현체가 바뀌어도 클라이언트 코드는 변경되지 않아, 결합도를 낮추고 테스트가 쉬워진다.

️ DI(의존성 주입)는 왜 필요한가요? 직접 new로 만들면 안 되나요?
직접 new로 객체를 생성하면 클래스 내부에서 구현체에 강하게 결합됩니다. 반면 DI는 외부에서 의존성을 주입받아 추상화에 의존하게 만듭니다. 이를 통해 DIP(의존 역전 원칙)를 지킬 수 있고, 구현체 교체나 테스트가 유연해집니다. 예를 들어, 실제 서비스 대신 Mock 객체를 주입해 테스트할 수 있습니다.

아래 코드는 <스프링 핵심 원리 - 기본편>에 나오는 예시 중 일부인데, 직접 구현체에 의존하는 구조여서 잘못된 예시로 가져왔다.

OrderServiceImpl이 discountPolish 인터페이스 뿐만 아니라 RateDiscountPolish인 구체 클래스도 함께 의존하고있다. (DIP 위반) 따라서 할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야 한다. (OCP 위반)

public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final DiscountPolish discountPolish = new RateDiscountPolish();
    
    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolish.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

예시에서는 AppConfig 클래스를 통해 애플리케이션에 필요한 구현 객체를 생성하고, 생성자를 통해 의존성을 주입했다.
이처럼 객체를 생성하고 의존 관계를 연결하는 구성을 IoC 컨테이너 또는 DI 컨테이너라고 한다.

AppConfig는 구현체 변경 시 해당 설정만 수정하면 되므로, 클라이언트 코드의 변경 없이 유연하게 확장할 수 있다.
다만, 이는 개념 설명을 위한 수동 설정 예시이며, 실제 Spring Boot 환경에서는 @ComponentScan과 생성자 주입(@Autowired 또는 Lombok)을 통해 자동 주입이 이뤄지므로 AppConfig를 직접 작성할 필요는 없다.

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public static MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolish());
    }

    @Bean
    public DiscountPolish discountPolish() {
        return new RateDiscountPolish();
    }
}

OrderServiceImpl은 추상화에만 의존하도록 변경되었고, 이를 통해 DIP와 OCP 원칙을 만족하며, DI와 IoC 구조도 함께 실현된다.

public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolish discountPolish;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolish discountPolish) {
        this.memberRepository = memberRepository;
        this.discountPolish = discountPolish;
    }

    // ...
}

[STUDY] Spring Batch 핵심 구조와 개념 정리

개발곰발 — Thu, 12 Jun 2025 10:02:40 +0900

Spring Batch란?

배치(Batch) 처리란 대량의 데이터를 정해진 시점에 자동으로 일괄 처리하는 방식이다.

예시
- 매일 자정 주문 데이터 통계 저장
- 매주 고객 대상 이메일 발송
- DB 마이그레이션, 정산 처리 등
특징
- 사람이 직접 요청하지 않아도 자동으로 주기적 실행
- 실시간성보다 정확성과 안정성이 중요
- 실패 시 재처리, 로그 추적이 중요

Spring Batch는 대용량 배치 작업을 쉽고 안전하게 처리할 수 있도록 도와주는 Spring 기반 프레임워크다.

Job/Step 기반 구성 제공
예외, 로그. 재시작, 로깅 등의 기능 제공
청크 기반 처리, 병렬 처리 등 내장

Spring Batch의 구조

Job과 Step

아래 그림은 Spring Batch의 전반적인 실행 흐름을 나타낸다.

JobLauncher : 배치 실행을 트리거하는 컴포넌트. 배치 실행 시 JobRepository에 JobExecution을 생성해 기록
Job : 하나의 배치 단위. 여러 Step으로 구성될 수 있음
Step : 실제 데이터 처리가 수행되는 단위. 내부적으로 Reader → Processor → Writer 순서로 처리됨
JobRepository : Job/Step의 실행 상태를 저장하며, 재시작/중단/성공 여부 등을 추적
ItemReader : 데이터 소스로부터 입력 (CSV, DB, API 등)
ItemProcessor : 읽은 데이터를 가공, 변환, 필터링
ItemWriter : 최종 데이터를 외부로 출력 (DB 저장, 파일 기록 등)

️ Spring Batch의 Job과 Step의 구조에 대해 설명해주세요.
Spring Batch는 Job과 Step이라는 실행 단위로 구성되어 있습니다. Job은 배치 작업의 전체 단위를 나타내며, 여러 개의 Step으로 구성될 수 있습니다. 각 Step은 Reader, Processor, Writer 구성 요소를 포함하며 실제 데이터 처리가 수행되는 단위입니다. Job을 실행하면 JobLauncher가 실행을 시작하고, JobRepository에 실행 정보가 저장되어 상태 추적이나 재시작이 가능하도록 관리됩니다. Step은 각각 독립적으로 트랜잭션을 가질 수 있고, 순차적으로 실행하거나 조건에 따라 분기할 수도 있습니다. 이러한 구조는 작업을 단계별로 나누고 실행 흐름과 상태를 명확히 관리할 수 있도록 해줍니다.
특히 실행 실패 시 특정 Step부터 다시 실행하는 구조를 지원해, 복구 가능성과 실행 제어를 용이하게 합니다.

Reader · Processor · Writer

Spring Batch에서 하나의 Step은 크게 세 가지 구성 요소로 이루어진다.

각각 데이터를 읽고, 가공하고, 저장하는 역할을 담당하며, 책임이 명확하게 분리되어 있다.

Reader (ItemReader) – 데이터를 읽는 구성 요소
- 외부에서 데이터를 읽어오는 역할
- 입력 소스는 CSV, DB, XML, API 등 다양하게 설정 가능
- 한 번에 하나의 데이터를 반환, 더 이상 읽을 데이터가 없으면 null 반환
Processor (ItemProcessor) – 데이터를 가공하는 구성 요소
- Reader에서 읽어온 데이터를 가공하거나 변환하는 역할
- 반환값이 null일 경우 해당 데이터는 writer에 전달되지 않음
- 필수 구성 요소는 아니며, 필요 시에만 사용
Writer (ItemWriter) – 데이터를 저장하는 구성 요소
- 처리된 데이터를 최종적으로 어떤 형태로 저장할지 정하고, 외부에 출력하는 역할
- DB에 저장하거나, 파일로 출력하거나, 외부 API로 전송하는 등의 작업을 수행
- Reader와 달리 청크 단위로 데이터를 전달받아 처리

아래 코드는 팀 프로젝트에서 사용된 정산 처리 Step의 예시다. Settlement 데이터를 읽고, 상태를 변경한 뒤 DB에 반영하는 단일 Step으로, chunk(100)으로 설정된 만큼 데이터를 모아 한 번에 처리하고 커밋한다.

Step은 Reader → Processor → Writer 구조로 이루어져 있으며, 각 구성 요소는 다음과 같은 역할을 한다.

Reader : status가 'READY'인 정산 데이터를 조회(커서 기반)
Processor : 상태를 'COMPLETED'로 변경
Writer : 변경된 상태를 DB에 반영 (UPDATE)

Spring Batch는 청크 단위로 트랜잭션을 관리하기 때문에, 하나의 청크가 실패하면 해당 청크만 롤백되고, Job은 중단되거나 재시작된다.

커서 기반 vs 페이징 기반 Reader

Spring Batch에서 데이터베이스로부터 대량의 데이터를 읽어올 때는 Reader 전략을 신중하게 선택해야 한다.
대표적으로 사용되는 방식은 커서 기반(Cursor-based) 과 페이징 기반(Paging-based) 두 가지다.
두 방식 모두 대량 처리에 사용되지만, 기술 스택과 데이터 특성, 트랜잭션 전략에 따라 적합한 상황이 다르다.

실무에서는 보통...

커서 기반은 JdbcCursorItemReader와 같은 JDBC 기반 방식
페이징 기반은 JpaPagingItemReader와 같은 JPA 기반 방식으로 구현된다.

아래는 두 방식의 차이를 정리한 표다.

항목	커서 기반(Cursor-based)	페이징 기반(Paging-based)
처리 방식	커서를 열고 전체 데이터를 순차적으로 읽음	일정 크기로 나누어 반복 쿼리로 읽음
쿼리 실행	1번 실행 후 커서 유지	여러 번 쿼리 실행(page 수만큼)
메모리 사용	전체 데이터를 가져와 메모리 부담 많음	매 페이지마다 작게 나누어 가져와 메모리 부담 적음
속도	커넥션 유지로 속도 빠름	다수의 쿼리로 인해 상대적으로 느림
데이터 정합성	처리 중 데이터 변경 없음	처리 중 데이터 변경 시 중복/누락 가능성 존재
트랜잭션 처리	트랜잭션 전체 유지	각 페이지 단위로 트랜잭션 분리 가능
커넥션 점유	전체 작업 동안 커넥션 점유	각 페이지마다 커넥션 연결/해제 가능
적합한 상황	정적인 대량 데이터 처리, 빠른 일괄 처리	변동 가능한 데이터, 병렬성/복원력 필요 시

JPA 기반 페이징은 엔티티 관리와 연관 관계 처리 등 ORM의 이점을 활용할 수 있지만, 대량 데이터를 처리할 때는 성능 저하나 메모리 부담이 발생할 수 있다. 반면, 커서 기반은 ResultSet을 열어 한 줄씩 데이터를 스트리밍 방식으로 처리하므로 메모리 사용이 효율적이고 처리 속도도 빠르다. 하지만 커넥션을 오래 점유하게 되므로, 병렬 처리나 재시작이 필요한 경우에는 제약이 크다. 결국, 어떤 방식이 더 낫다고 단정하기보다는 배치 잡의 특성과 시스템 구조에 맞게 전략을 선택하는 것이 중요하다.

청크(Chunk) 기반 처리

청크(Chunk) : 일정한 개수로 묶인 데이터 단위.
청크 기반 처리 방식 : 지정한 개수만큼 모아서(청크 단위로) 처리하고 한 번에 커밋하는 방식. 청크 단위로 트랜잭션을 관리하면 데이터 부하를 최소화하면서 대용량 데이터 처리가 가능하고 실패 시 롤백을 효과적으로 수행할 수 있음.

Spring Batch에서는 chunk(10)처럼 청크 크기를 지정해 설정하며, 각 청크는 다음 순서로 처리된다.

ItemReader가 데이터를 하나씩 읽는다.
지정된 청크 크기만큼 모은다.
ItemProcessor로 데이터를 가공한다.
ItemWriter가 가공된 데이터를 한 번에 저장하고 커밋한다.

️ Spring Batch의 Chunk와 Chunk 기반 방식에 대해 설명해주세요.
Spring Batch는 기본적으로 Chunk 기반 처리 방식을 사용합니다. Chunk는 데이터를 일정 개수로 묶은 단위이며, 이 단위로 트랜잭션을 커밋합니다. 예를 들어 chunk 크기를 100으로 설정하면, 데이터를 한 건씩 읽고 가공하되 100건이 모일 때까지는 커밋하지 않고, 100건이 쌓인 시점에 한 번에 저장하고 트랜잭션을 커밋하게 됩니다. 이 방식은 매 건마다 커밋하지 않기 때문에 트랜잭션 부하를 줄일 수 있고, 중간에 예외가 발생하더라도 청크 단위로만 롤백되기 때문에 전체 작업을 처음부터 다시 실행할 필요가 없습니다. Chunk 기반 구조는 트랜잭션 범위를 적절히 나눌 수 있고, 데이터를 일괄 처리하면서도 실패 복구가 가능한 실행 구조를 제공합니다.

멱등성 (Idempotency)

멱등성(Idempotency) : 같은 작업을 여러 번 수행해도 결과가 변하지 않는 성질.
Spring Batch처럼 대량의 데이터를 청크 단위로 처리하고, 중간 실패 시 재시작이 가능한 구조에서는 멱등성을 보장하는 것이 데이터 정합성과 안정성을 유지하는 핵심 요소가 된다.

멱등성이 보장되지 않는다면?

DB에 중복된 레코드가 insert됨(DB에 별도의 Unique 제약조건이 없는 경우)
이미 처리된 상태의 데이터를 다시 덮어씀
외부 시스템(API, 메시지 큐 등)에 중복 요청이 발생함

실제로는 ItemWriter 단계에서의 멱등성 보장이 가장 중요하다. Writer는 트랜잭션의 커밋 지점이기 때문에, 이 단계에서의 중복/불일치는 곧 데이터 정합성 문제로 직결된다. Writer뿐만 아니라 Reader와 Processor에서도 방어적으로 멱등성을 고려해두면 더 안정적인 설계가 가능하다.

아래는 SettlementRegisterJobConfig 클래스의 일부이다.

Reader와 Writer 각 단계에서 다음과 같은 방법으로 멱등성이 보장된다.

Reader : 이미 settlement가 존재하는 payment는 조회되지 않음
Writer : 별도의 중복 처리 로직 없이도 안전하게 INSERT 가능

️ Spring Batch에서 멱등성은 어떻게 보장했나요?
Spring Batch는 청크 단위로 트랜잭션을 커밋하기 때문에 Step 도중 예외가 발생하거나 재시작되는 경우 동일한 데이터가 중복 처리될 수 있는 구조입니다. 그래서 멱등성을 보장하기 위해 Reader 단계에서부터 중복 가능성을 차단하는 조건을 명확히 설정했습니다. 예를 들어 정산 등록 Job에서는 payment 테이블에서 상태가 'DONE'이면서, 이미 settlement에 등록되지 않은 건만 조회하도록 LEFT JOIN + IS NULL 조건을 사용해 처리 대상을 선별했습니다. 정산 완료 Job에서는 settlement 테이블에서 status가 'READY'인 건만 조회해 상태를 'COMPLETED'로 업데이트하 하도록 구성했습니다. 이처럼 Reader에서 중복 대상을 제거하고, Writer는 ID 기반 처리를 통해 이미 처리된 데이터에 대해 다시 커밋되지 않도록 설계했습니다. 덕분에 Job이 재시작되더라도 데이터가 중복 저장되거나 상태가 반복 변경되는 문제 없이, 멱등성이 자연스럽게 보장되는 구조가 됩니다.

[STUDY] 동기 vs 비동기 - RabbitMQ로 비동기 이벤트 처리하기

개발곰발 — Thu, 5 Jun 2025 19:00:26 +0900

동기 · 비동기와 블로킹 · 논블로킹

동기 vs 비동기

동기(Synchronous) : 호출자와 요청자의 결과 확인이 동시에 일어남
비동기(Asynchronous) : 호출자와 요청자의 결과 확인이 동시에 일어나지 않아도 됨

블로킹 vs 논블로킹

블로킹(Blocking) : 호출자가 요청에 대한 결과가 나올 때까지 요청자에게 제어권을 돌려주지 않는 것
논블로킹(Non-Blocking) : 호출자가 요청에 대한 결과가 나오지 않더라도 요청자에게 제어권을 돌려줌

동시성 vs 병렬성

동시성(Concurrency) : 싱글 코어에서 여러 작업을 번갈아 가며 처리하는 방식
병렬성(Parallelism) : 멀티 코어가 각 작업을 물리적으로 동시에 처리하는 방식

예를 들어, 아래 코드는 메시지를 수신할 때 동시에 최대 3개의 메시지를 처리할 수 있도록 concurrency = "3" 설정을 해두었다.

이때 Spring은 내부적으로 멀티스레드 풀을 활용해 메시지를 병렬로 처리하려고 시도한다. 만약 이 코드가 단일 CPU 환경에서 실행된다면 실제로는 3개의 스레드가 반갈아 실행되며 각각의 메시지를 처리하게 되는데, 이 때 발생하는 것이 동시성 처리다.

메시징 시스템이란?

메시지 큐의 역할과 구조

메시지 큐(Message Queue, MQ) : 메시지 지향 미들웨어(Message Oriented Middleware, MOM)의 일종으로, 서로 독립적인 애플리케이션 간에 메시지를 주고받으며 비동기적으로 작업을 처리할 수 있도록 해주는 시스템이다.

메시징 시스템의 가장 기본적인 구조는 아래와 같이 생산자(Producer)가 메시지를 Message Queue에 넣고, 소비자(Consumer) 가 이를 꺼내 처리하는 구조이다. Producer와 Consumer가 비동기적으로 분리되어 있다는 것이 핵심이다.

메시지 큐의 특징
- 비동기 처리로 응답 지연 해소
  - Producer와 Consumer가 시간적으로 분리되어 요청-응답 병목 없이 빠른 사용자 응답 가능
- 버퍼링과 부하 완충
  - 큐에 메시지를 일시 저장함으로써, 트래픽 폭주나 처리 지연 상황에서도 안정적인 흐름 유지 가능
- 재처리 및 신뢰성 보장
  - 처리 실패 시 메시지를 DLQ 등으로 이동 후 재시도 가능 → 데이터 유실 없이 안정적인 메시지 처리

왜 메시지 기반 비동기 처리가 필요한가?

동기 처리의 한계

아래 코드는 메시지 큐를 도입하기 전, 이벤트 오픈 시 알림을 직접 전송하던 방식이다. openEventsIfDueBefore() 메서드는 DB에서 오픈 대상 이벤트를 조회한 뒤, 해당 이벤트에 참여한 사용자 목록을 가져와 notificationService.createNotification()을 직접 호출해 알림을 전송한다. 이때 알림 전송은 동기적으로 처리되며, 유저 수가 많아질수록 for문 내부 처리 시간이 길어지고, 전체 트랜잭션이 지연될 가능성이 크다.

동기 처리의 한계는 다음과 같이 정리할 수 있다.

모든 처리가 하나의 흐름에 묶여 있다.
- 이벤트 오픈부터 사용자 알림 전송까지 하나의 메서드/트랜잭션 안에서 모두 처리
사용자 수 증가 시 선형적으로 지연된다.
- for문으로 유저를 하나씩 순회하며 동기적으로 알림 전송 → 이 모든 작업이 반환될 때까지 대기
- 알림 전송 처리량이 늘수록, 전체 오픈 로직 지연이 심해짐
장애 복원력이 없다.
- 실패한 메시지를 따로 저장하거나, 재처리할 수 있는 구조가 없음 → 유저는 알림을 받지 못하고, 개발자는 실패한 알림이 뭔지 알기 어려움

메시지 큐 도입 전후 비교

MQ를 적용하지 않은 기존 구조의 흐름은 다음과 같다. 알림 전송까지 한 트랜잭션에서 처리되어 응답 지연이 발생할 확률이 높았고, 실패 시 전체 흐름이 중단될 수 있었다.

[Scheduler 실행 (주기적)]
       │
       ▼
[DB에서 READY 이벤트 조회]
       │
       ▼
[이벤트 상태 OPEN으로 변경]
       │
       ▼
[유저 조회 → 알림 직접 전송 (동기)]
       │
       ▼
[완료]

MQ 도입 후엔 알림 로직이 메시지 큐를 통해 비동기로 처리되며, Scheduler는 메시지를 발행만 하고, 알림 전송은 Consumer가 병렬로 처리하게 되었다. 구조는 복잡해졌지만, 시스템 확장성과 안정성 측면에선 명확한 개선이 있었다.

[이벤트 등록 시]
       │
       ▼
[Redis ZSET에 Event 메시지 저장]
       │
       ▼
[Scheduler 실행 (주기적)]
       │
       ▼
[Redis ZSET에서 오픈 대상 조회]
       │
       ▼
[DB 상태 OPEN으로 변경]
       │
       ▼
[RabbitMQ로 오픈 메시지 발행]
       │
       ▼
[Consumer가 알림 비동기 전송]
       │
       ▼
[완료]

RabbitMQ 기반 알림 처리 전략

Exchange 타입

Exchange란?
RabbitMQ에서 메시지를 수신하고, 적절한 Queue로 라우팅하는 역할을 하는 구성 요소.
Producer가 보낸 메시지는 먼저 Exchange로 도착하고,
Exchange는 메시지의 RoutingKey나 설정된 규칙을 기반으로 어떤 Queue로 메시지를 보낼지 결정한다.

Direct : 정확히 일치하는 RoutingKey로 메시지를 전달
Fanout : RoutingKey 없이, 바인딩된 모든 Queue에 메시지를 전파
Topic : 패턴 기반 RoutingKey 매칭, 라우팅 패턴 간의 와일드카드(*) 혹은 해시(#)가 일치해야 매칭
Headers : 메시지의 헤더 값을 기반으로 라우팅

프로젝트에서는 이벤트 오픈 시, 알림을 설정한 모든 유저에게 알림을 보내야 했기 때문에 Fanout 으로 설정했다.

DLQ · DLX 구조

DLQ(Dead Letter Queue) : 메시지 소비에 실패한 경우를 대비해 메시지를 별도로 저장하고 추후 재처리하거나 로그로 확인할 수 있게 해주는 구조
실패한 메시지는 DLX → DLQ로 이동, 이후 수동 재처리 또는 Retry Queue로의 자동 재처리 기반

TTL 기반 Retry 처리

DLQ에 쌓인 메시지를 자동으로 재시도하기 위해 TTL(Time To Live)과 Retry Queue를 활용
실패한 메시지는 DLQ에서 다시 Retry Queue로 전송
해당 Queue에는 TTL이 설정되어 있어 일정 시간 뒤 원래 Exchange로 재전송

[STUDY] Spring Security + JWT 로그인/로그아웃 흐름

개발곰발 — Thu, 29 May 2025 18:57:25 +0900

이번 주 스터디 주제는 인증/인가다!

최종 프로젝트에서 다른 팀원이 구현한 코드를 분석해보며 인증/인가에 대한 공부도 함께 진행해보려한다.

Spring Security + JWT를 사용하는 방식은 이전에 강의를 듣고 포스팅 한 적이 있지만,

프로젝트를 진행하면서 인증/인가 부분은 맡은 적이 없어서 기본에 충실한 내용들로 구성해 정리해보려 한다.

인증/인가가 필요했던 이유

우선 인증(Authentication)과 인가(Authorization)에 대해 짚고 가자.

인증(Authentication) : 사용자가 서비스에 가입되어 있는지 확인하는 과정(= 로그인)
인가(Authorization) : 인증된 사용자에 대해 권한을 확인하는 과정

인증/인가가 없다면 식당 예약, 이벤트 참여, 결제와 같은 주요 기능에 누구나 접근할 수 있어 보안상 문제가 발생할 수 있다.

또한 관리자만 접근 가능한 기능에 일반 유저가 접근할 수도 있다.

왜 Spring Security + JWT 인가?

Spring Security

Spring Security : 스프링 기반 애플리케이션에서 가장 널리 쓰이는 보안 프레임워크.

공식 홈페이지에는 다음과 같이 설명되어 있다.

출처: https://spring.io/projects/spring-security

위 내용을 요약하자면 다음과 같다.

Spring 기반 애플리케이션의 사실상 표준 보안 프레임워크
인증(Authentication)과 인가(Authorization) 모두 지원
세션 고정, 클릭재킹, CSRF 등 보안 위협에 대한 내장 보호 기능
필터 기반 구조로 커스터마이징이 용이
Spring Web MVC와도 쉽게 통합 가능

세션 고정 : 공격자가 세션 ID를 미리 정해놓고, 그 세션 ID로 피해자가 로그인하게 만든 뒤, 같은 세션 ID를 이용해 피해자처럼 접근하는 공격. → 로그인 시 세션 ID를 자동으로 바꿔줌으로써 방어함.
클락재킹 : 사용자가 알고 누른 게 아닌데, 누르게 만드는 공격. 공격자는 자신의 웹페이지 위에 투명한 iframe을 올려 유저가 어떤 버튼을 누르게 유도함. → 기본적으로 X-Frame-Options 헤더를 통해 iframe 삽입을 차단함.
CSRF(Cross Site Request Forgery) : 사용자가 자신의 의지와 상관없이 공격자가 의도한 행위를 특정 웹사이트에 요청하도록 하는 것. → CSRF Token을 발급하고, 요청마다 서버에서 토큰 일치 여부 검증.

이렇게 Spring Security는 필터 기반 구조라 JWT 기반 인증 플로우를 쉽게 구현할 수 있었고, 인가 처리도 URL/메서드 단위로 유연하게 제어할 수 있어 선택했다.

실제로 최종 프로젝트에서 인가 처리는 @Secured 어노테이션이 메서드 단위로 적용되어 있다.

JWT(Json Web Token)

JWT(Json Web Token) : 토큰 자체에 정보가 포함되어 있는 클레임 기반 토큰으로, 통신 정보를 JSON 형식을 사용하여 안전하게 전송하기 위해 사용됨.

JWT의 구조

JWT의 구조는 다음과 같이 헤더(Header), 페이로드(Payload), 서명(Signature)으로 나뉜다.

출처: https://jwt.io/

헤더(Header) : 토큰 타입, 서명 알고리즘
페이로드(Payload) : 사용자 정보(Claims), 만료 시간 등
서명(Signature) : 토큰 위조 방지용 서명

JWT의 특징

서버가 상태를 저장하지 않음(Stateless) → 서버가 이중화된 환경에서도 사용자의 로그인 정보를 일관성 있게 관리 가능
세션 기반 인증에 비해서 사용자 정보를 조회하기 위한 추가적인 작업이 필요하지 않음
디코딩이 쉬워 민감한 정보를 담는 것에 유의해야 함
JWT 탈취 시 위험 → 리프레시 토큰 도입 여부, 만료 시간 관리, 블랙리스트 등 보완 필요

최종 프로젝트에서는 Stateless 구조의 특성과, 수평 확장에 유리한 구조, 웹/모바일 등 다양한 클라이언트 환경과의 연동 편의성을 고려해 Spring Security와 연계한 JWT 기반 인증 방식을 선택했다.

세션 방식과 비교

항목	세션 기반 인증	JWT 기반 인증
상태 관리	Stateful(서버가 세션 저장)	Stateless(서버가 상태 저장X)
인증 정보 저장 위치	서버 세션(JSESSIONID)	클라이언트가 토큰 저장
서버 확장성	세션 공유 필요(Sticky Session, Redis 등)	수평 확장에 유리
요청 인증 방식	쿠키에 JSESSIONID 자동 포함	Authorization 헤더에 Bearer 토큰 명시
로그아웃 처리	세션 무효화	블랙리스트 처리, Refresh Token 삭제
클라이언트 호환성	브라우저 중심	웹/모바일 등 다양한 클라이언트에 적합

로그인/로그아웃 흐름

로그인 전체 흐름

1. 로그인 요청 수신

클라이언트가 이메일과 비밀번호를 담아 로그인 요청을 보내고, 해당 요청은 아래 컨트롤러에서 처리된다.

Access Token : 본문 응답으로 전달
Refresh Token : CookieUtil을 통해 응답 쿠키에 저장

AuthController.java

2. 사용자 조회 및 탈퇴 여부 확인, 비밀번호 검증

먼저 이메일로 사용자를 조회하고, 이미 탈퇴 처리된 사용자라면 예외를 발생시킨다. 즉, deletedAt 필드가 null이 아니라면 이미 탈퇴한 사용자로 간주한다.
요청에서 받은 비밀번호와 DB에 저장된 비밀번호를 비교해 검증한다. 비밀번호 검증은 Spring Security에서 제공하는BCryptPasswordEncoder를 사용한다.

AuthService.java

3. Access Token & Refresh Token 생성

인증이 완료된 유저 정보를 기반으로 JWT 토큰을 발급한다.
Access Token은 사용자 인증에 사용되고, Refresh Token은 재발급과 로그아웃 처리에 사용된다.

AuthService.java

createAccessToken(user)

sub, userId, role, nickname, email, iat, exp 등을 claim에 포함한 JWT를 생성
JwtUtil.createToken() 메서드를 내부적으로 사용

TokenService.java

JwtUtil.java

createRefreshToken(user)

Refresh Token도 JWT 형식으로 생성되며, userId를 값으로 Redis에 저장
클라이언트엔 쿠키로 전달

TokenService.java

Refresh Token을 사용한 이유

Access Token만 사용한다면?

1. 사용자 경험 저하 가능성

Access Token은 Stateless 인증 수단으로, 서버가 별도로 저장하지 않아 관리가 어렵다. 따라서 토큰이 탈취될 경우의 피해를 줄이기 위해, 일반적으로 유효기간을 짧게 설정한다.

하지만 이 경우,

유효기간이 짧기 때문에 사용자는 빈번하게 재로그인을 요구받게 된다.
로그인 상태 유지가 어렵고, 사용자 경험이 저하된다.

2. 탈취 대응 어려움

Access Token은 발급 이후 서버가 따로 보관하지 않기 때문에 그 토큰이 누가 들고 있든, 만료 전까지는 무조건 유효하다.

즉, 토큰이 외부에 노출되거나 탈취되었을 경우 다음과 같은 문제점이 있다.

서버는 이를 감지하거나 차단할 방법이 없다.
유저 본인이 탈취를 인지하지 않는 이상 방어할 수 없다.
특정 시점까지 공격자는 해당 사용자의 권한으로 모든 요청을 수행할 수 있다.

Refresh Token이 필요한 이유

1. 인증 상태를 유지하면서 UX를 보장

Access Token이 만료되더라도 Refresh Token으로 새로운 토큰을 재발급할 수 있다.

2. 탈취 대응 및 서버 측 제어 가능

Refresh Token은 서버에 저장되어 관리되기 때문에 로그아웃 시 삭제하거나 TTL 만료 설정이 가능하다.
탈취 의심 시 즉시 무효화할 수 있다.
Refresh Token 자체는 HttpOnly + Secure 쿠키로 보호되며, 클라이언트에서 직접 접근할 수 없다.

실제 코드에서도 Refresh Token은 HttpOnly + Secure 옵션을 명시했다. 이렇게 설정함으로써 자바스크립트 접근 차단과 HTTPS 연결 제한을 동시에 적용하고 있다.

CookieUtil.java

로그아웃 전체 흐름

1. 로그아웃 요청 수신

클라이언트는 로그아웃 시 Authorization 헤더에 Access Token을 담고, Refresh Token 쿠키도 함께 전송한다.

해당 요청은 아래 컨트롤러에서 처리된다. 로그아웃이 완료되면 클라이언트 측 쿠키를 삭제한다.

AuthController.java

2. Refresh Token 제거 및 블랙리스트 등록

클라이언트가 보낸 Refresh Token을 Redis에서 제거하고,

Access Token은 블랙리스트에 등록해 더 이상 사용하지 못하도록 처리한다.

AuthService.java

Refresh Token은 Redis에 refreshToken:{token} 형태로 저장돼 있다.

로그아웃 시 이 값을 삭제함으로써 이후 해당 토큰을 사용한 Access Token 재발급 요청을 차단할 수 있다.

TokenService.java

Access Token은 서버에서 따로 관리하지 않기 때문에 한 번 발급되면 만료 전까지는 항상 유효하다.

이로 인해 사용자가 로그아웃하거나 탈퇴해도 누구든 기존의 Access Token을 계속 사용할 수 있다는 보안 취약점이 존재한다.

따라서 우리는 JWT 기반 인증 구조의 현실적인 보완책으로 블랙리스트 전략을 사용하고 있다.

블랙리스트(Blacklist)란?
블랙리스트란 더 이상 유효하지 않다고 판단되는 JWT Access Token을 별도의 저장소에 보관해두고, 이후 해당 토큰이 사용된 요청을 서버에서 차단하는 전략이다.

다음과 같이 토큰을 Redis에 블랙리스트로 등록하고, 남은 유효 시간만큼 TTL을 설정해 만료 전까지 서버에서 차단할 수 있도록 처리한다.

TokenService.java

Key: blacklistToken:{JWT}
Value: 이유 + 사용자 정보 (ex. logout:userId=123)
TTL: 토큰 만료 시점까지만 유지

Access Token이 블랙리스트에 등록되면, JwtAuthenticationFilter 내부에서 아래와 같은 순서로 토큰 유효성을 검사한다.

Authorization 헤더에서 JWT 추출
Redis에 해당 토큰이 블랙리스트로 등록되어 있는지 조회
등록된 토큰일 경우 → 인증 중단 + 401 응답 반환

따라서 불필요한 리소스 낭비를 막고, 빠르고 안전하게 요청을 거절할 수 있다.

[STUDY] 동시성 제어 개념과 방법 알아보기

개발곰발 — Thu, 22 May 2025 17:00:09 +0900

최종 프로젝트가 끝난지 벌써 2주가 됐다...!

최종 프로젝트에서 나는 예약 및 이벤트 동시성 제어를 구현했지만 아쉬운 점이 많았다.

좀 더 다양한 동시성 제어 방법에 대해 공부하지 않은 점
DB 락 구현이 잘못된 점
내가 구현한 부분은 말로 설명하는 연습이 부족한 점

따라서 팀원들과 매주 모여 자신이 공부한 내용을 발표하고 의견을 나눠보기로 했다.

주제는 최종 프로젝트의 핵심적인 내용 위주로 진행될 예정이다.

첫 번째 주제는 "동시성 제어"이다.

내가 맡은 부분이긴하지만 어렵고 헷갈리는 부분이 많아 쉽지 않은 주제인 것 같다.

동시성(Cocurrency) 제어란?

둘 이상의 실행 흐름(스레드 또는 트랜잭션)이 동시에 동일한 자원에 접근할 때 발생할 수 있는 데이터 충돌이나 정합성 오류를 방지하기 위한 제어 기법.

동시성 제어가 없다면 다음과 같은 문제가 생길 수 있다.

선착순 100명 이벤트에 동시에 200명이 신청할 경우, 100명을 초과해 참여가 완료됨.
재고가 100개 남았을 때 동시에 100건의 주문이 들어올 경우, 재고 수량과 실제 판매량이 맞지 않음.

‍ 동시성 제어를 하지 않는다면...

경쟁 상태(Race Condition)

여러 프로세스 혹은 스레드에서 자원에 접근하는 순서에 따라 데이터 상태나 시스템의 동작 결과가 달라지는 현상.

경쟁상태의 대표적인 예시 - 너무 많은 우유 문제

냉장고는 공유자원, 엄마와 아빠는 각각의 프로세스라고 생각하고 아래 예시를 보자.

엄마가 냉장고를 열어 우유가 없는 것을 확인한다.
엄마가 우유를 사러 마트에 간다.
엄마가 우유를 사서 돌아오는 길에 아빠가 냉장고에 우유가 없는 것을 확인한다.
아빠가 우유를 사러 마트에 간다.
아빠가 우유를 사서 집에 돌아온다.

에상한 결과는 우유가 1개가 되는 것이었지만, 실제로는 2개가 되어버렸다.

두 프로세스(엄마, 아빠)가 거의 동시에 자원의 상태를 읽고 독립적으로 행동했기 때문이다.

이런 경쟁 상태로 아래 예시와 같이 데이터의 무결성이 손상될 수 있다.

재고 수량이 음수가 되는 현상
이벤트 정원을 초과해서 성공 처리되는 현상
포인트 중복 적립 또는 누락

✅ 임계 영역 : 공유 자원에 접근할 수 있고 접근 순서에 따라 결과가 달라지는 코드 영역.
(위 예시에서는 냉장고에 우유 유무를 판단하고 우유를 추가하는 부분)

- 임계 영역에서 경쟁 상태가 발생하는 것을 방지하려면 여러 프로세스가 공유 자원에 접근해도 데이터의 일관성이 유지되도록 프로세스 동기화를 해야한다.
- 임계 영역에 대한 접근을 동기화하는 것이 동시성 제어의 핵심이다.

동기(Blocking) : 호출자가 요청에 대한 결과가 나올 때까지 요청자에게 제어권을 돌려주지 않는 것.
비동기(non-blocking) : 호출자가 요청에 대한 결과가 나오지 않더라도 요청자에게 제어권을 돌려줌.
싱크(Sync) : 호출자와 요청자의 결과 확인이 동시에 일어남.
어싱크(Async) : 호출자와 요청자의 결과 확인이 동시에 일어나지 않아도 됨.

교착 상태(Deadlock)

2개 이상의 프로세스가 각각 자원을 가지고 있으면서 서로의 자원을 요구하며 기다리는 상태.

️교착 상태의 대표적인 예시 - 철학자들의 식사 문제

철학자들은 포크(자원)를 양손에 들어야 식사를 할 수 있다.
모두 동시에 왼쪽 포크를 들고, 오른쪽 포크가 놓이길 기다리면?
서로가 서로의 포크를 기다리는 상태에서 영원히 멈추게 된다.

위 예시와 같이 자원을 점유하고 있으면서 동시에 다른 자원을 기다리는 상황은 교착 상태를 유발한다.

아래의 조건을 모두 만족할 때 교착 상태가 발생한다.

상호배제(mutual exclusion) : 하나의 공유 자원에 하나의 프로세스만 접근할 수 있다.
점유와 대기(hold and wait) : 프로세스가 최소 하나의 자원을 점유하고 있는 상태에서 추가로 다른 프로세스에서 사용 중인 자원을 점유하기 위해 대기한다.
비선점(non-preemption) : 다른 프로세스에 할당된 자원을 뺏을 수 없다.
환형 대기(circular wait) : 프로세스가 자신의 자원을 점유하면서 앞이나 뒤에 있는 프로세스의 자원을 요구한다.

동시성 제어 방법

동시성 제어 방식은 단일 서버 내 스레드 수준의 처리부터, 데이터베이스 트랜잭션, 분산 환경까지 다양한 계층에서 이뤄질 수 있다.

synchronized

자바에서 제공하는 가장 기본적인 동시성 제어 키워드.

단일 JVM 내에서 여러 스레드가 동시에 공유 자원에 접근할 때 충돌을 방지하기 위해 사용된다.
단일 서버, 단일 JVM 내부의 멀티스레드 환경에서만 효과있다.
락 범위가 커지면 성능 병목이 발생할 수 있다.

사용 예시

다음과 같이 간단한 재고 감소 로직으로 테스트 해봤다.

동시에 100개 요청 테스트를 해보니 재고가 10개밖에 감소되지 않았다.

이번에는 synchronized 키워드를 사용했다.

정상적으로 100개가 감소되었다.

ReentrantLock

synchronized보다 더 세밀한 제어가 가능한 명시적 락 구현체.

자바의 java.util.concurrent.locks 패키지에 포함되어 있다.
임계 영역을 직접 lock/unlock 할 수 있는 구조를 제공한다.
락 획득 방식, 공정성, 대기 시간 설정 등에서 synchronized보다 유연하다.

낙관적 락 vs 비관적 락

언제 어떤 락을 써야 할까? 어떤 상황인지가 중요하다.

중돌이 자주 발생하는 상황인가?
읽기와 수정하기의 비율은 어디에 가까운가?

낙관적 락 (Optimistic Lock)

충돌이 없을 것이라고 낙관적으로 예상하는 방법.

실제로 Lock을 이용하지 않고 Version을 이용해 정합성을 맞춘다. ( JPA에서는 @Version 어노테이션 사용 )
어플리케이션 락
데드락의 가능성이 적고 성능의 이점이 있다.
충돌이 발생하면 오버헤드가 발생한다.

비관적 락(Pessimistic Lock)

충돌을 예상하고 미리 락을 거는 방법.

실제로 데이터에 락을 걸어 정합성을 맞춘다.
데이터베이스 락
충돌에 대한 오버헤드가 줄어들고 무결성을 지키기 용이하다.
충돌이 없으면 오버헤드가 발생한다. → 비관적 락은 실제로 충돌이 자주 발생할 것으로 예상되는 상황에서 사용해야 한다.

최종 프로젝트에서 선착순 이벤트 역시 한 번에 수많은 요청이 몰릴 것이 분명한 구조였기 때문에,

충돌이 실제로 발생할 가능성은 높다고 판단했다. 따라서 다음과 같이 비관적 락을 사용했다.

findByIdForUpdate()는 내부적으로 SELECT ... FOR UPDATE를 수행하여 이벤트 row를 트랜잭션 동안 잠금 상태로 유지한다.
이벤트 상태 확인, 중복 참여 검사, 좌석 감소, 참여 저장까지의 일련의 작업은 모두 하나의 트랜잭션 안에서 수행되며, 동시 접근으로부터 보호된다.

Redis 분산 락

(내용 추가 예정)

[Spring] Redis ZSET + RabbitMQ 적용해 이벤트 오픈 알림 구현하기

개발곰발 — Wed, 23 Apr 2025 23:56:27 +0900

기존 코드의 문제점

기존 이벤트 API는 오픈 알림이 구현되지 않았고,

단순 DB 기반 스케줄러로 1분마다 오픈 시간을 체크해 상태를 변경하는 구조였다.

하지만 지금과 같은 구조는 다음과 같은 단점이 있다.

데이터베이스 부하 증가
- 스케줄러는 매 분마다 WHERE open_at <= NOW() 조건으로 모든 이벤트를 조회해야 한다.
- 기존 코드는 매 분마다 위와 같은 조건으로 풀스캔하고 있다.
- 인덱스를 적용하더라도 유저 수와 이벤트 수가 많아질수록 쿼리 부하가 커지고, 인덱싱만으로는 처리 한계가 생긴다.

이벤트 오픈 비동기 전파 필요성
- 만약 알림 도메인과 직접적인 연결을 한다면?
  - 두 서비스가 서로의 생명주기와 내부 구조에 영향을 받을 수 있다.
  - 직접적인 연결은 유지보수를 어렵게 하고, 장애 전파 가능성을 높인다.
- MQ를 사용하면 이벤트 서비스는 오픈 시 메시지만 발행하고, 알림 도메인은 메시지를 수신해 독립적으로 처리함으로써 구조적으로 느슨한 연결과 안정적인 전송이 가능하다.

기능 구현

이벤트 생성 시 Redis ZSET 등록

기존 createEvent()에서 아래 코드를 추가했다.

openEpoch : LocalDateTime 타입인 openAt 값을 UTC 기준 초 단위 숫자(Epoch Time) 로 변환한 것. → Redis ZSET에서는 score(정렬 기준)가 double 숫자여야 하고, 시간 비교를 위해 초 단위 숫자가 가장 직관적이기 때문에 이와 같은 방식으로 변환.
ZSet에 event:open 을 key로, 이벤트의 ID를 value로 넣고 이벤트의 오픈 시간을 정렬 기준으로 등록했다.

이벤트 오픈 시간 확인 후 상태 변경 - openEventsIfDue()

기존 코드에서는 스케줄러를 통해 openEventsIfDue()가 실행되면 다음과 같은 흐름으로 진행됐다.

[1분마다 실행되는 스케줄러]
      ↓
[DB 조회]
  - 이벤트 테이블에서 
    상태가 READY이고 open_at ≤ 현재시간인 이벤트 전체 조회
      ↓
[DB 상태 변경]
  - 해당 이벤트의 상태를 OPENED로 변경
      ↓
[유저 알림 생성]
  - 참여 유저 목록을 조회하여
  - 알림을 직접 동기적으로 생성 (for-loop 돌면서 NotificationService 호출)
      ↓
[끝]
  - 유저에게는 알림이 전달되지만,
  - 동기 처리로 트랜잭션 지연 및 서비스 결합 발생 가능

개선된 openEventsIfDue()의 처리 흐름은 다음과 같다.

[1분마다 실행되는 스케줄러]
      ↓
[Redis ZSET 조회]
  - event:open ZSET에서
    score(=오픈 시간) ≤ now 인 ID들만 조회
      ↓
[각 ID별로 처리 반복]
      ↓
[1. 이벤트 엔티티 조회 및 상태 확인]
      ↓
[2. 상태가 READY면 OPENED로 변경]
      ↓
[3. MQ에 EventOpenMessage 발행]
      ↓
[4. Redis ZSET에서 해당 ID 제거]
      ↓
[끝]
  - 실제 알림은 Consumer가 비동기로 처리

리팩토링한 openEventsIfDue() 인데, 예약된 이벤트의 오픈 시간이 도달하면

1) 상태를 변경하고,

2) 메시지를 MQ로 발행해 후속 처리를 비동기 전파하는 핵심 메서드라고 할 수 있다.

rangeByScore(0, now)로 오픈 시간이 도달한 이벤트 ID만 선별 조회→ DB 쿼리 없이 오픈 대기 이벤트만 O(logN)으로 조회 가능 (= score 값이 0 이상 now 이하인 요소들의 value들(ID들)만 조회)
이벤트가 아직 READY 상태인지 확인 → READY 가 아닐 경우 건너뛰고, READY 상태라면 OPENED 로 상태 변경
오픈된 이벤트 정보를 MQ로 발행 → 알림/로그/통계 등은 직접 처리하지 않고, Consumer가 비동기로 처리
성공적으로 처리된 이벤트는 ZSET에서 제거

EventOpenProducer

위에서 메세지 발행을 하기 전 EventOpenProducer 클래스를 만들어야 한다.

해당 클래는 이벤트가 오픈되는 시점에 해당 이벤트 정보를 RabbitMQ에 메시지로 발행하는 역할을 한다.

이벤트 오픈 메시지를 fanout exchange로 발행한 이유

현재 이벤트가 등록되고, 이벤트가 열리면 발행은 모든 유저에게 하되, Customer 쪽에서 알림 수신 설정을 한 유저에게만 알림을 보내도록 했다. 사용자 설정과 같은 동적인 조건에 따라 메시지를 처리해야 하는 경우, Consumer 측에서 이러한 로직을 구현하는 것이 유연성과 확장성 측면에서 유리할 수 있다고 한다.

왜 routingKey는 빈 문자열("")로 설정하는가?

FanoutExchange는 메시지를 받으면 연결된 모든 큐에 브로드캐스트하기 때문에 라우팅 키가 필요하지 않다.

이벤트 오픈 시간에 맞춰 테스트 한 후 로그를 보니 이벤트 오픈 메세지가 정상적으로 발행되었다.

EventOpenConsumer

이제 발행을 했으면 메세지를 수신해야 한다.

EventOpenConsumer 클래스는 RabbitMQ를 통해 전송된 이벤트 오픈 메시지를 수신하고, 유저에게 알림을 생성하는 클래스다.

전체적인 흐름은 다음과 같다.

RabbitMQ의 Fanout Exchange로부터 메시지 수신
유효성 검사 → 잘못된 메시지는 무시
알림 설정이 활성화된 유저만 조회
각 유저에게 알림 생성
실패 시 로깅 처리

@RabbitListener 기반 메시지 수신 : consume()
- RabbitMQ로부터 EVENT_OPEN_QUEUE에 수신된 메시지를 자동으로 처리
메시지 유효성 검증 : isValid()
- 필수 필드(eventId, storeId)가 없는 메시지는 로그 경고 후 무시
알림 설정 유저만 선별 조회 : getUsers()
- userService.getUsersWithAlarmEnabled() 을 통해 알림을 활성화한 유저만 필터링
- 유저 목록 조회 실패 시 emptyList() 반환
알림 전송 + 예외 대응 : sendNotification() ⇒ 추후 MQ 기반 알림 전송 분리 적용 고려
- 알림 요청 객체(NotificationRequestDto) 생성 후 서비스 호출

MQ 메시지 발행 및 소비가 정상적으로 수행되고 있는 것을 RabbitMQ 대시보드의 Message Rates 그래프로 확인한 결과이다.

RabbitConfig - Queue, Exchange, Binding 설정

RabbitConfig에 이벤트 오픈 관련 설정 등록한다.

eventOpenQueue() : 이벤트 오픈 시 전체 유저에게 브로드캐스트할 큐 생성
- 큐 이름: EVENT_OPEN_QUEUE
- durable = true: 메시지 브로커 재시작 후에도 큐 유지
- 큐의 내구성을 보장하여 서비스 중단 없이 안정적인 운영 가능
eventOpenExchange() : Fanout 방식의 브로드캐스트 Exchange 정의
- Exchange란 메세지를 어떤 큐로 보낼지 결정하는 중간 허브를 말한다.
- Exchange 이름: EVENT_OPEN_EXCHANGE
- 메시지를 받은 모든 큐로 동시에 복제 전송
- durable = true, autoDelete = false: 안정성과 명시적 해제를 모두 고려
eventOpenBinding() : 큐와 익스체인지 연결
- eventOpenQueue()를 eventOpenExchange()에 바인딩
- Fanout 방식이므로 라우팅 키 불필요

[트러블슈팅] 정원이 남아있는 상태에서 이벤트 신청이 안되는 오류

개발곰발 — Fri, 18 Apr 2025 19:48:16 +0900

문제점

이벤트 정원이 10명인데도 200명 신청 시 9명까지만 들어가는 문제가 발생했다.
또한 로그에서 “이벤트 정원이 초과되었습니다.”라는 메세지가 떴다.

Redis에는 이미 200명이 저장된 상태
DB는 한 명이 누락된 상태
DB에 존재하지 않는 ID로 다시 신청 → EVENT_ALREADY_JOINED 예외 발생

원인

Redis와 DB의 정합성이 깨졌는데, 검증 기준은 Redis에만 의존하고 있기 때문이다.

Redis는 ID를 이미 참여한 유저로 보고 있지만, 실제 DB에는 들어가지 않았다.
하지만 ZSet에 있는 것만 보고 판단하여 중복 신청으로 막아버린 것이다.
Zset에는 실패한 유저도 들어있기 때문에 100% 신뢰할 수 없다.

왜 지금까지 이런 문제가 한 번도 없었는지는 잘 모르겠다..

해결 방법

validateEventCapacity() 메서드는 다음과 같았다.

private void validateEventCapacity(String zsetKey, int limit) {
    Long current = redisTemplate.opsForZSet().zCard(zsetKey);
    
    if (current != null && current >= limit) {
        throw new HandledException(ErrorCode.EVENT_FULL);
    }
}

메서드를 다음과 같이 수정하였다.

private void validateEventCapacity(String zsetKey, int limit, Event event) {
    Long current = redisTemplate.opsForZSet().zCard(zsetKey);
    
    // Redis 기준 정원 초과일 경우 -> DB 기준으로 한 번 더 확인
    if (current != null && current >= limit) {
        long dbCount = eventJoinRepository.countByEvent(event);

        if (dbCount >= limit) {
            throw new HandledException(ErrorCode.EVENT_FULL);
        }
    }
}

테스트 결과는 다음과 같다.

추가 +)

기존 코드에서 DB Insert 실패 시 ZSet에서 제거하는 로직을 추가했다.

private EventJoinResponseDto handleJoinLogic(Long eventId, AuthUser authUser) {
    User user = User.fromAuthUser(authUser);
    String zsetKey = EVENT_JOIN_PREFIX + eventId;

    Event event = eventRepository.findById(eventId)
            .orElseThrow(() -> new HandledException(ErrorCode.EVENT_NOT_FOUND));

    event.validateOpenStatus();
    validateEventNotAlreadyJoined(zsetKey, user);
    validateEventCapacity(zsetKey, event.getLimitPeople(), event);

    EventJoin eventJoin = saveEventJoin(event, user);

    log.info("이벤트 신청 성공: eventJoinId={}, user={}, event={}", eventJoin.getId(), user.getEmail(), eventId);
    return EventJoinResponseDto.fromEventJoin(eventJoin);
}

수정한 코드는 다음과 같다.

private EventJoinResponseDto handleJoinLogic(Long eventId, AuthUser authUser) {
    User user = User.fromAuthUser(authUser);
    String zsetKey = EVENT_JOIN_PREFIX + eventId;

    Event event = eventRepository.findById(eventId)
            .orElseThrow(() -> new HandledException(ErrorCode.EVENT_NOT_FOUND));

    event.validateOpenStatus();
    validateEventNotAlreadyJoined(zsetKey, user);
    validateEventCapacity(zsetKey, event.getLimitPeople(), event);

    try {
        EventJoin eventJoin = saveEventJoin(event, user);
        log.info("이벤트 신청 성공: eventJoinId={}, user={}, event={}", eventJoin.getId(), user.getEmail(), eventId);
        return EventJoinResponseDto.fromEventJoin(eventJoin);
    } catch (Exception e) {
        redisTemplate.opsForZSet().remove(zsetKey, String.valueOf(user.getId()));
        log.warn("DB insert 실패로 Redis 자리 반환: userId={}, eventId={}", user.getId(), eventId);
        throw e;
    }
}

1번 ~ 10번까지는 DB에 들어간 순서 그대로이고, 나머지는 순간적인 동시 처리 때문에 남아있는 것 같다.
그러나 이전에 ZRANGE event:join:1 0 -1 을 했을 때 는 200명이 그대로 들어가 있었다.
로직 수정 후 ZSet에서 실제 정원과 비슷한 수준으로 유지되고 있다.

200명(신청 시도 유저 전부) → 22명(정상적으로 반영된 유저 + 미처 삭제 되지 못한 유)

지삐띠가 만들어준 ZRANGE 수치 변화…

추가 공부

추후 MQ를 도입한다면 아래와 같은 흐름으로 진행될 것 같다.

1) 유저가 이벤트 신청
2) Redis ZSet에 userId 추가 시도
	- zCard 기준으로 정원 초과 여부 확인
	- 정원 초과 시 예외
3) Redis에 성공적으로 추가되면 MQ에 메세지 보냄("이벤트 신청했다.")
4) Redis만 보고 응답을 빠르게 반환
---
5) MQ는 이 메세지를 큐에 저장
---
6) Consumer(이벤트 신청 처리기)가 큐로부터 메시지를 수신
7) 메시지 처리
	- 이벤트 존재 여부 확인
	- 유저 정보 확인
	- DB에 Insert 시도
8) Consumer 처리 결과에 따라 분기
	- DB Insert 성공
	- DB Insert 실패 → Redis ZSet에서 해당 userId 제거

캐싱(caching)이란? / Redis(Remote Dictionary Server)란? / 데이터 캐싱 전략 정리

개발곰발 — Thu, 17 Apr 2025 00:08:38 +0900

캐싱(caching)이란?

Redis에 대해 알아보기 전, 먼저 캐시 & 캐싱이 무엇인지 알아보자! 파레토의 법칙에 따라 자주 사용되는 20%의 데이터를 미리 캐싱해둔다면 효과적인 성능 향상을 기대할 수 있다.

캐시(Cache) : 원본 저장소보다 데이터를 더 빠르고 효율적으로 가져올 수 있는 임시 데이터 저장소.
캐싱(Caching) : 캐시에 접근해 데이터를 빠르게 가져오는 방식.
캐시 사용 시 주의사항
- 자주 사용되면서 변경이 적은 데이터에 적합하다.
- 유실되어도 크게 문제가 없는 데이터에 적합하다.
- DB와 함께 사용 시 데이터 정합성 문제를 고려해야한다.

데이터 캐싱 전략

단순히 "캐싱"만 한다고 성능이 무조건 보장되는 것은 아니다. 어떻게 캐싱하느냐가 중요하다.
대표적인 데이터 캐싱 전략을 알아보자.

Cache Aside(=Look Aside, Lazy Loading)

캐시에서 데이터를 확인하고, 없다면 DB를 통해 조회해오는 방식.

Cache Aside는 Redis를 캐시로 쓸 때 가장 일반적으로 사용하는 방법으로, 데이터에 대한 요청이 들어오면 먼저 캐시를 확인한다.
- 캐시에 데이터가 있으면(cache hit) 캐시에서 데이터를 가져온다.
- 캐시에 데이터가 없으면(cache miss) DB에서 데이터를 가져와 캐시에 저장 후, 반환한다.
장점
- 캐시에 문제가 생기면 Db로 요청을 위임할 수 있어 캐시 미스 제어가 쉽다.
단점
- 데이터 불일치 가능성 : 캐시된 후 DB의 데이터가 변경되면 캐시는 오래된 데이터를 반환할 수 있다.

Write Around

데이터를 쓸 때 DB에만 저장하고 캐시에는 반영하지 않는 방식.

Write Around는 한 번 쓰고 자주 읽지는 않는 경우에 적합하다.
장점
- DB에 바로 쓰기 때문에 성능이 좋다.
- 불필요한 데이터를 캐시에 올리지 않고 바로 쓰기 때문에 리소스를 아낄 수 있다.
단점
- 캐시와 DB의 정합성 유지가 어렵다.

Write Through

데이터를 쓸 때 DB와 캐시 둘 다 동시에 갱신하는 방식.

Write Through는 데이터에 대한 요청이 들어오면 캐시와 DB에 모두 기록된다. 따라서 캐시에는 항상 최신 데이터가 저장된다. 데이터의 일관성이 중요할 때 사용한다.
장점
- 캐시가 항상 최신 정보를 가진다.
- 캐시와 DB가 항상 동기화 되어서 데이터 일관성을 보장한다.
단점
- 항상 두 번의 쓰기가 발생하므로 성능 문제에 유의해야 한다.

Write Back(=Write Behind)

데이터를 먼저 캐시에 저장하고, 이후 비동기로 DB에 반영하는 방식.

Write Back은 캐시에 한꺼번에 기록 후, 나중에 DB에 한꺼번에 저장한다. 이때 스케줄링을 사용한다.
장점
- DB에 대한 쓰기 작업 수를 줄여(한 번의 쿼리로 삽입) 성능이 좋다.
단점
-DB에 저장되기 전에 캐시에 오류가 나면 데이터 손실이 발생할 수 있다.

성능 개선을 한다고 꼭 바로 캐시를 적용하려고 하지 않아도 된다. 우선 SQL 튜닝을 통해 기본적으로 성능을 향상시킬 수 있다. 또한 SQL 튜닝은 추가적인 시스템 구축 없이도 적용할 수 있기 때문에 가장 먼저 고려해보도록 하자!

Redis(Remote Dictionary Server)

Redis는 데이터 처리 속도가 매우 빠른 Key-Value 기반의 NoSQL 데이터베이스이다.

특징
- Redis는 인메모리(in-memory)에 모든 데이터를 저장하므로 데이터의 처리 성능이 매우 빠르다.
- 다양한 자료구조를 제공한다.
- 싱글 스레드로 동작해 한 번에 하나의 명령만을 처리하기 때문에 Race Condition이 거의 발생하지 않는다.
- 메모리에 저장된 데이터를 디스크에 영속화하는 기능을 제공한다.(RDB, AOF)

Redis는 주로 캐싱에 사용된다는 것만 알고 있었는데, 검색해보니 아주 많은 사용 사례가 있었다.

캐싱
세션 관리
실시간 분석 및 통계
메시지 큐
지리공간 인덱싱
속도 제한
실시간 채팅 및 메시징

가장 먼저 캐싱을 통한 데이터 조회 성능 향상에 대해 학습하면서 자연스럽게 다른 기능을 익혀보는 것이 좋다. 또한 채용 공고에 자주 등장하는 ‘대용량 트래픽 처리 경험’을 위해 필수적인 것이 바로 Redis의 캐싱 기능이다!

Redis 기본 명령어

데이터 (Key-Value) 저장하기

# set [key 이름] [value]
$ set gom:name "gom gom"

Key로 Value 조회하기

# get [key 이름]
$ get gom:name

저장된 모든 Key 조회하기

$ keys *

단, Redis는 싱글 스레드로 동작하기 때문에 keys *와 같이 모든 키를 탐색하는 O(N) 복잡도의 작업은 성능에 큰 영향을 줄 수 있다.

key로 데이터 삭제하기

# del [key 이름]
$ del gom:name

데이터 저장 시 만료시간(TTL) 정하기

# set [key 이름] [value] ex [만료 시간(초)]
$ set gom:pet dog ex 30

데이터 저장 시 만료시간(TTL) 정하기

# ttl [key 이름]
$ ttl gom:pet

만료 시간이 몇 초 남았는지 반환
-2 : TTL이 만료된 경우
-1 : 키 값은 존재하지만, TTL이 설정되어있지 않은 경우

Redis Key 네이밍 컨벤션

보통 콜론(:)을 활용해 계층적으로 의미를 구분해 사용 → 가독성, 일관성, 검색 및 필터링 용이성, 확장

예를 들면 다음과 같이 사용할 수 있다.

users:100:profile : 사용자들 중에서 아이디가 100인 사용자의 프로필
products:123:details : 상품들 중에서 아이디가 123인 상품의 세부사항

참고 자료

[트러블슈팅] 순환 참조 오류(Circular Dependency)

개발곰발 — Wed, 16 Apr 2025 23:54:05 +0900

문제점

애플리케이션을 실행하자, 다음과 같은 에러가 발생했다.

원인

Bean 초기화 시에 순환 참조가 생기면서 앱이 실행되지 않았다.

EventService → EventJoinService를 @RequiredArgsConstructor로 주입
EventJoinService → EventService를 또 @RequiredArgsConstructor로 주입

서로 의존성을 주입하고 있어서 다음과 같은 순환 의존 구조가 된 것이다.

EventController
  → EventService
    → EventJoinService
      → EventService (다시 참조)

해결 과정

기존에 EventJoinService에서 사용하고 있던 EventService를 EventRepository로 바꿨다.

EventService의 getEvent() 메서드를 호출하는 구조였는데, 직접 eventRepository.findById() 를 사용하도록 수정했다.

Event와 User는 @ManyToOne → 즉, EventJoin이 소유자
비즈니스적으로 EventJoin을 만들기 위해 Event가 필요함.
그러니 eventRepository.findById() 혹은 findByIdForUpdate()를 호출하는 건 자연스러움.
EventJoinService 를 Event의 하위 개념이라는 것을 잊고 작업해서 실수를 한 것 같다.

구조를 생각해보면 User ↔ EventJoin ↔ Event 와 같은데,

EventJoin은 "누가 어떤 이벤트에 참여했는가"를 저장하는 이벤트 신청 테이블로, 유저와 이벤트 사이의 중간 테이블로 생각해야 한다. 또 단순 조회만을 하고 있기 때문에 굳이 EventService를 쓸 필요는 없다.

TableNow 개발 회고 #1 – API 설계, 데이터 모델링, 시스템 아키텍처와 초기 구현

개발곰발 — Thu, 10 Apr 2025 23:49:42 +0900

️최종 프로젝트 시작!

드디어 최종 프로젝트를 시작했다. 사실 벌써 2주차가 끝났지만 정신없이 달려오다보니 블로그에 기록을 하지 못했다.

한 주가 끝날 때마다 꾸준히 기록하는 습관을 가지자.✍

우리 팀은 테이블링 서비스를 주제로 정했다!

프로젝트명 : TableNow (테이블나우)
주제 : 식당을 예약하고 방문할 수 있는 실시간 예약 관리 시스템

1 ~ 2주차 일정

S.A 작성 후 피드백 받기
기본 기능 개발 완료
기본 기능 개발 후 코드리뷰 받기

핵심 기능

우리 팀의 핵심 기능은 다음과 같이 정리할 수 있다.

인증/보안	Spring Security + JWT Refresh Token 저장 및 관리(Redis) OAuth2.0 로그인 연동
검색/캐싱	인기 검색어 캐싱(Redis) Elasticsearch
동시성 제어	Redisson Redis Sorted Set
MQ	RabbitMQ

나는 예약/이벤트 도메인을 맡았고, 동시성 제어는 처음이어서 핵심 기술에 대해 고민이 많았다.

기술적의사결정 과정은 다음과 같다.

Redisson (분산 락)

목적: 예약 및 이벤트 요청 시 중복 처리를 방지하기 위한 분산 락 구현

[선택 이유]

Redis 기반으로 빠르고 가볍게 락을 제어 가능
Redisson은 다양한 락 타입 지원 (Fair, Reentrant 등)
TTL 설정으로 데드락 방지 가능
Spring Boot와의 통합이 쉬움

[다른 기술과의 비교]

DB 트랜잭션 락 (SELECT ... FOR UPDATE): 단일 DB 환경에서는 가능하지만, 분산 환경에서는 사용 불가
ZooKeeper: 고신뢰 락을 제공하지만 운영 복잡도가 매우 높음

[결론]
복잡한 락 시스템을 쓰기보다, Redis 기반의 간단하면서도 안정적인 락의 필요성을 느껴 Redisson으로 결정했다.
또한 다른 도메인에서도 Redis를 이미 사용하고 있으므로 추가적인 리스크 없이 도입이 가능하다.

Redis Sorted Set - 시간 기반 트리거 처리

목적: 리마인드 알림, 이벤트 오픈과 같이 특정 시간에 발생해야 하는 작업을 스케줄링

[선택 이유]

Sorted Set의 score에 timestamp를 사용해 시간순 정렬 가능
주기적인 polling으로 실행 대상만 빠르게 추출 가능
배치보다 실시간에 가깝고, 구현과 운영이 간편함
Redis 인프라를 재사용할 수 있어 도입 비용 거의 없음

[다른 기술과의 비교]

Quartz Scheduler: 정기적인 작업을 정밀하게 관리해야 할 때 사용함
RabbitMQ Delayed Queue: 구현 복잡하고 유연성 낮음, 지연 시간 기반(ex. 5분 뒤, 10분 뒤)이라 특정 시간 트리거에는 불편함
일반 DB + 배치: 실시간 반응이 어렵고 리소스 낭비가 될 수 있음

[결론]
시간을 score로 설정하여 정확한 시간에 맞춰서 작업을 트리거할 수 있다.
따라서 리마인드 알림, 이벤트 오픈 시간 도달 시 트리거(가게 상태 변경) 작업에 적합하다.
또한 이벤트 오픈 시 실시간 처리가 필요하므로 메모리 기반의 Redis가 효율적이다.

RabbitMQ - 비동기 이벤트 전파

목적: 예약 완료, 리마인드 알림, 이벤트 오픈 알림을 다른 도메인으로 안전하게 전파

[선택 이유]

메시지 전송의 신뢰성 보장
비동기 메시징 시스템으로 각 도메인 간 느슨한 결합 유지
다양한 메시징 패턴 (Fanout, Topic 등)을 제공해 유연한 라우팅 가능

[다른 기술과의 비교]

Kafka: 대용량 데이터 처리, 실시간, 고성능, 고가용성을 제공하지만 로그 기반 스트리밍에 초점, 복잡성 및 설정이 과도함
Redis Pub/Sub: 설정이 간단하고 미들웨어가 없어 가볍지만 메시지 유실 가능성이 있음
AWS SQS: 클라우드 종속적이고 비용이 발생할 수 있음

[결론]
MQ를 사용하는 것은 이번이 처음이지만, 대용량 데이터 처리나 로그 추적, 재처리가 필요한 상황은 아니었다.
다만 리마인드 알림뿐 아니라 빈자리 알림, 이벤트 오픈 알림처럼 선착순으로 처리되어야 하는 이벤트들이 존재했기 때문에
메시지의 정확한 도착 보장이 무엇보다 중요했다.
이에 따라 Kafka보다 속도는 느리더라도, 정확한 메시지 전달과 유연한 라우팅이 가능한 RabbitMQ를 선택하게 되었다.

와이어프레임

API 설계

노션으로 팀원들과 작성한 API 명세서다. 분류, 담당자, 진행사항, 메서드, 기능, URI, 응답/요청 헤더 및 바디, 상태 코드 등으로 이루어져 있다. RESTful한 API를 설계하고자 했다.

데이터 모델링

초기 ERD는 리뷰, 댓글, 좋아요, 즐겨찾기 등 부가적인 기능이 많았다. 하지만 비즈니스적으로 다가가 기능을 추가하는 것보다는 기술적인 도전을 하는 것에 초점을 맞추기로 했다. 따라서 테이블 수를 줄이고 각자 핵심적인 1 ~ 2개의 도메인만 맡아 진행했다.

아마 기술 고도화가 진행되면 좀 더 수정될 것이다.

아키텍처 설계

우리 팀은 무중단 배포 방식을 원했는데, 현실적인 상황에 맞춰 EC2 1대에 컨테이너 2개를 띄우고 그 앞단에 Nginx와 같은 웹서버를 두는 방향으로 정했다. Blue-Green 방식으로 진행하고자 한다.

프로젝트 구조

table-now
├── .github
│   └── ISSUE_TEMPLATE
│       ├── feature-request-issue-template.md
│       └── PULL_REQUEST_TEMPLATE.md
├── src
│   ├── main
│   │   ├── java
│   │   │   └── org.example.tablenow
│   │   │       ├── domain
│   │   │       │   ├── auth
│   │   │       │   ├── category
│   │   │       │   ├── event
│   │   │       │   ├── image
│   │   │       │   ├── notification
│   │   │       │   ├── payment
│   │   │       │   ├── reservation
│   │   │       │   ├── store
│   │   │       │   ├── user
│   │   │       │   └── waitlist
│   │   │       ├── global
│   │   │       │   ├── annotation
│   │   │       │   ├── config
│   │   │       │   ├── dto
│   │   │       │   ├── entity
│   │   │       │   ├── exception
│   │   │       │   ├── filter
│   │   │       │   ├── security
│   │   │       │   └── util
│   │   │       └── TableNowApplication.java
│   │   └── resources
│   │       ├── application.yml
│   │       ├── application-local.yml
│   │       └── application-test.yml
│   └── test
├── Dockerfile
├── docker-compose.yml
├── .env
├── .env.local
├── .env.test
├── .gitignore
├── .gitattributes
├── build.gradle
├── gradlew
├── gradlew.bat
├── settings.gradle

환경변수 관리는 어떻게 할까?
우리는 환경마다 다른 설정을 유연하게 관리하기 위해,
Spring Boot의 application.yml 계층 구조와 .env 파일을 함께 사용하는 방식을 선택했다.

application.yml : 공통 설정
application-local.yml : 로컬 개발 환경 설정
application-test.yml : 테스트 환경 설정

이 설정 파일들과 연동되는 .env, .env.local, .env.test 파일을 각각 만들어
DB 접속 정보, Redis 설정, AWS 자격 증명 등 외부 노출되면 안 되는 민감한 값을 여기에 따로 분리해 관리하고 있다.

예를 들어 .env.local에는 아래와 같은 값들이 들어간다.

이렇게 하면 민감한 정보는 Git에 올라가지 않고,
각 환경별로 .env만 바꿔주면 바로 설정이 적용되어 훨씬 안전하고 편하다.

EnvFile 플러그인 함께 사용하기
EnvFile 플러그인을 사용하면 Run/Debug Configuration에 .env 파일을 쉽게 연동할 수 있다.

아래처럼 Run 설정에서 "Enable EnvFile" 옵션을 체크하고 원하는 .env 파일 경로를 지정해주면, 실행 시 해당 환경변수들이 자동으로 애플리케이션에 주입된다.

기능 구현

2주차는 기술 고도화를 위한 기본 기능을 개발하고, 각자 받은 코드리뷰를 바탕으로 리팩토링을 진행했다.

예약 생성, 조회, 수정, 취소, 처리 기능 구현
이벤트 등록, 조회, 수정, 삭제, 신청(참여) 기능 구현

구현한 부분을 일일이 적기엔 양이 많고 기본적인 코드만 있어서 내가 신경 쓴 부분, 리팩토링 한 부분, 고민했던 점 등을 간단히 적어본다.

검증 책임 분리

예약 기능에서는 예약 가능 여부, 중복 여부, 매장 상태 등의 다양한 조건을 검증해야 했다. 조건이 복잡해질수록 코드가 비대해질 수 있기 때문에, 검증 책임을 메서드 단위로 분리하여 클린 코드 원칙(단일 책임, 가독성, 유지보수성)을 고려해 설계했다. 이 부분은 튜터님께서도 잘 구성했다고 긍정적인 피드백을 주셨다.

아래는 실제로 분리한 검증 메서드들이다.

이렇게 분리한 검증 로직은 메서드 내에서 다음과 같이 예약 생성 전 유효성 검사를 명확히 수행하도록 구성되어 있다.

도메인이 책임지는 예약 변경 로직

예약 상태 변경 로직은 단순히 서비스 레이어에서 처리하는 것이 아니라, 예약 도메인 자체가 그 책임을 가지도록 구성했다.
예를 들어 tryCancel() 메서드는 단순한 setter가 아니라, 예약이 취소 가능한 상태인지 자체 검증을 포함한 명확한 도메인 행위로 정의되어 있다.

또한 메서드 네이밍도 tryCancel, updateStatus처럼 의도를 잘 드러내는 이름으로 구성하여 코드를 읽는 사람도 도메인 흐름을 쉽게 이해할 수 있도록 했다.

서비스 레이어에서는 단순히 해당 도메인의 메서드를 호출하는 구조로, 책임이 자연스럽게 나뉜다.

서비스 로직에서 직접 상태를 변경하는 대신, 도메인 객체에게 그 책임을 위임함으로써 비즈니스 로직을 더욱 명확하고 견고하게 관리할 수 있었다. 물론 이런 방식이 모든 상황에 정답은 아니지만, 상황에 따라 잘 판단해서 사용하면 좋을 것 같다.

예약 시간 검증 리팩토링

초기에는 예약 시간의 유효성을 서비스단에서 메서드로 직접 검증했다.
아래와 같이 validateReservedAtHalfHour() 메서드를 통해 정시(00분) 또는 30분 단위가 아닌 경우 예외를 발생시키는 방식이었다.

하지만 튜터님으로부터 "요청 DTO의 단일 필드 유효성은 컨트롤러 단에서 처리하는 것이 적절하다" 는 피드백을 받고, 해당 검증 책임을 요청 객체 쪽으로 이동했다. 이에 따라 다른 팀원 분이 하신 방식을 따라 커스텀 어노테이션 @HalfHourOnly를 이용해 컨트롤러 진입 시점에서 입력값의 형식을 검증할 수 있도록 리팩토링했다.

검증 로직을 컨트롤러 단으로 이동시킴으로써 서비스 단의 책임을 명확히 하고, 비즈니스 로직 흐름을 더 깔끔하게 유지할 수 있었다.

DB Lock 구현

처음에는 정말 기본 기능만 구현한 후 Redisson을 적용하려고 했는데, 막상 진행하려니 아주 기본적인 구조여서 베이스 라인으로 하기에는 부실한 것 같다는 생각이 들었다. 고민하다가 튜터님께 질문하니 "현재 상황과 Redisson 락 적용을 비교하는 것은 크게 의미가 없다" 라고 하셨다. 따라서 추후 비교를 한다면 DB 락 vs Redisson 분산 락을 해보는 것이 더 낫다는 것이다.

따라서 우선은 DB 락을 먼저 적용해보기로 하고, JMeter도 익힐 겸 v1과 v2를 나눠 진행했다.

v1 : 별도의 락 없이 기본 로직 구현
v2 : Pessimistic Lock(DB 락)을 적용해 중복 참여 방지 및 정합성 확보

코드 자체는 이벤트를 가져올 때 제외하고는 모두 동일하다. v2에서는 다음과 같이 비관적 락이 적용된 findByIdForUpdate() 메서드를 이용해 이벤트를 가져온다.

정원이 10명인 이벤트에 200명이 동시에 이벤트를 신청하다고 가정하고 테스트 해보니, 그 결과는 다음과 같았다.

No Lock(왼) / DB Lock(오)

정리해보면, No Lock 버전은 응답 속도는 빠르지만 초과 신청이 발생해 정합성이 깨졌다.

반면, DB Lock을 적용한 버전은 응답 시간과 처리량은 감소했지만, 정확히 10명만 신청되며 정합성을 보장할 수 있었다.

Redisson 기반 분산 락(v3) 적용 시에는 이 두 가지 요소를 모두 개선하는 방향으로 고도화를 진행할 예정이다.

항목	No Lock	DB Lock
요청 수	200	200
평균 응답 시간	53ms	415ms
최대 응답 시간	199ms	753ms
에러율	90.50%	95.00%
Throughput	507.6/sec	233.9/sec
전송/수신 KB/sec	208.22 / 109.06	94.20 / 50.26

테스트

현재는 DB 락 기반으로 이벤트 신청 API의 동시성 문제를 방지하고 있으며, JMeter를 활용해 정합성 중심의 테스트를 수행했다.
단일 요청 기준의 API는 Postman으로 충분했지만, 이벤트와 같이 여러 사용자가 동시에 접근할 수 있는 기능에 대해서는
멀티 스레드 환경에서 예상치 못한 충돌이 없는지 중점적으로 검증했다.
이후 Redisson 적용 시, 동일한 시나리오로 성능 및 안정성 테스트를 진행해볼 예정이다.

Postman

주요 용도: REST API 기본 기능 테스트 및 빠른 검증
활용 내용
- 인증, 회원가입, 예약, 이벤트 등 API의 정상 응답/에러 응답 확인
- 다양한 요청 시나리오를 환경 변수 설정을 통해 반복 실행
- 팀원 간 공유를 위해 테스트 컬렉션 구성 및 문서화

JMeter

주요 용도: 이벤트 신청 API 등 동시성 문제 발생 가능 구간의 정합성 테스트, 성능 테스트
활용 내용
- 현재는 DB 락(Pessimistic Lock)을 적용한 상태
- 이벤트 신청 시 중복 참여나 초과 신청이 발생하지 않는지 확인
- 다양한 스레드 수로 시뮬레이션하며 정합성 유지 여부 체크
성능보다 데이터 충돌 방지 및 동시 요청 시 안정성 확인이 목적
향후 Redisson 분산 락 전환 전 비교 테스트를 위한 기반 마련

️ GitHub Actions 기반 CD 실전 트러블슈팅: EC2, ECR, ElastiCache

개발곰발 — Mon, 31 Mar 2025 16:15:12 +0900

처음으로 자동 배포를 설정하면서 겪은 트러블슈팅을 기록하고자 한다.✍

우선 CI/CD 환경은 다음과 같다.

EC2: Ubuntu 22.04, Docker 설치
ECR: Spring Boot 앱 이미지를 빌드하여 push
RDS: MySQL DB 사용
배포 방식: GitHub Actions를 통한 CI/CD 자동화

EC2 배포 시 오류 발생

command not found 에러

docker: command not found 에러는 EC2 서버에 Docker가 설치되어 있지 않아서 발생한 오류다. GitHub Actions에서 EC2로 SSH 접속은 성공했지만, EC2 안에 docker 명령어 자체가 없어서 전부 실패한 상황이다.

EC2에 SSH 접속 후 아래 명령어 실행해 Docker를 설치한다.

sudo apt update
sudo apt install -y docker.io
sudo systemctl start docker
sudo systemctl enable docker

위와 비슷하게 aws: command not found 에러도 발생했다. 이 에러는 EC2 서버에 awscli가 아예 설치되어 있지 않아서 발생한 에러로 역시 awscli를 한 번 설치하면 해결된다.

EC2에 SSH 접속 후 아래 명령어 실행한다. apt install awscli 명령어를 통해 설치를 하려 했지만, Ubuntu 24.04부터는 AWS에서 제공하는 공식 zip으로 설치해야 한다고 한다.

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

만약 unzip도 설치되어있지 않다면 먼저 설치해준다.

sudo apt update
sudo apt install -y unzip

설치 후, 다음 명령어로 정상적으로 설치되었는지 확인할 수 있다.

aws --version

GitHub Actions에서는 왜 aws 명령어가 되는데?
GitHub Actions에서 aws 명령어가 동작하는 이유는, GitHub의 리눅스 러너에 AWS CLI가 기본적으로 설치되어 있기 때문이다. 반면 EC2는 직접 설정하는 가상 서버이기 때문에, 필요한 도구는 모두 수동으로 설치해주어야 한다.

AWS IAM 권한 연결 문제

이제 aws 명령어 실행은 잘 되지만, Unable to locate credentials. You can configure credentials by running "aws configure". 이라는 에러가 발생했다. 이 에러는 EC2에서 AWS 인증정보(Access Key, Secret Key)가 아예 없는 상태여서 발생한 것이다.

자세한 원인을 살펴보니...

EC2에서 aws ecr get-login-password를 쓰려면 AWS IAM 권한이 있어야 한다.
EC2 안에 ~/.aws/credentials 파일이 없어서 발생했다.
즉, EC2가 ECR에 접근할 수 있는 권한이 없다는 뜻이다.

따라서 EC2에 IAM Role을 연결해 해결했다. EC2 인스턴스 세부정보를 보니, IAM Role이 비어있는 것을 확인할 수 있다.

따라서 IAM 역할을 EC2로 해서 새로 만든 후, AmazonEC2ContainerRegistryFullAccess 권한을 허용했다. ECR은 Private Registry라서 IAM 권한이 없으면 pull에 실패한다.

다음과 같이 설정해야 EC2가 ECR에서 pull/push 포함 풀 권한을 가진다.

docker pull 실패

배포 테스트에서 다음과 같은 에러가 발생했다.

에러 메시지를 분석해보니 두 가지 문제가 있었다.

1. docker login 관련 에러

Your authorization token has expired.

이 메시지는 ECR 인증 토큰이 만료되었음을 의미한다. AWS ECR은 보안을 위해 로그인 토큰이 12시간 동안만 유효하도록 설계되어 있다. 나는 EC2 인스턴스에 이미 AmazonEC2ContainerRegistryFullAccess IAM 역할을 부여했기 때문에, 별도로 로그인하지 않아도 될 줄 알았다. 하지만 실제로는 그렇지 않았다.

✔️ 정리하자면...
EC2가 ECR에 접근할 권한(IAM Role)은 있지만, Docker는 AWS IAM을 인식하지 못하기 때문에 별도의 로그인 절차가 필요하다.

따라서 AWS CLI를 통해 인증 토큰을 받아서 Docker에 전달해줘야 한다. 다음 명령어를 Deploy on EC2 단계에 추가하자 docker pull이 정상적으로 작동했다.

aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin $ECR_URI

✔️ IAM 권한과 Docker 인증은 별개!

IAM Role은 “리소스를 사용할 수 있는가”를 판단하는 권한이다.
하지만 Docker는 AWS의 권한 체계를 모름 → AWS CLI로 토큰을 받아서 docker login으로 명시적으로 인증해줘야 한다.

또한, ECR 인증 토큰은 단기(12시간 유효) 토큰이기 때문에, 주기적으로 재로그인하는 로직이 필요할 수 있다.

⚙️ 운영 환경에서는 ECS, Fargate, EKS 등의 컨테이너 오케스트레이션 서비스를 사용하는 경우가 많다. 이런 경우에는 해당 서비스가 ECR 인증을 자동으로 처리해주기 때문에 별도의 docker login이 필요 없다.

2. 포트 충돌 에러
에러 메시지 중 다음과 같은 내용이 있었다.

Bind for 0.0.0.0:8080 failed: port is already allocated.

이는 EC2 내에서 포트 8080을 이미 점유하고 있는 컨테이너가 실행 중이라는 뜻이다. 대부분 이전에 실행된 컨테이너가 종료되지 않아서 발생하는 문제다.

따라서 docker run을 하기 전에 기존 컨테이너를 정리해주는 명령어를 추가했다.

docker ps -q --filter ancestor=$ECR_URI | xargs -r docker stop
docker ps -aq --filter ancestor=$ECR_URI | xargs -r docker rm

$ECR_URI는 ECR 이미지 주소다. 하지만 이전과 다른 태그가 붙은 이미지거나 이름이 바뀌었다면 해당 필터에 안 잡힐 수 있다.

더 안전하게 하려면 컨테이너 이름을 명시해서 정리하는 것도 고려할 수 있다.

docker stop my-app-container || true
docker rm my-app-container || true

정상적으로 포트가 비워졌는지 확인하려면 다음 명령어를 사용한다.

sudo lsof -i :8080

health check 실패

배포는 성공적으로 완료되었지만, health check는 계속해서 실패하는 문제가 발생했다. 따라서 여러가지 가능성을 체크해보며 문제를 해결했다.

1단계: Docker 컨테이너 상태 확인

다음 명령어들을 통해 실행 상태 및 로그를 확인할 수 있다. 이 단계에서 컨테이너가 제대로 실행되지 않았거나, 실행되자마자 꺼지는 경우엔 로그에서 에러 메시지를 찾아야 한다.

docker ps                   # 현재 실행 중인 컨테이너 목록
docker ps -a                # 실행 이력이 있는 모든 컨테이너
docker logs <컨테이너 ID>  # 죽은 컨테이너의 로그까지 확인

2단계: Spring Actuator 설정 확인

컨테이너가 정상 작동하고 있는 것처럼 보이는데도 health check가 실패했다면,build.gradle에 Spring Actuator 의존성이 제대로 추가되었는지 확인한다.

implementation 'org.springframework.boot:spring-boot-starter-actuator'

또한 배포 시 사용되는 application-prod.yml에 다음 설정이 포함되어 있는지 확인한다.

management:
  endpoints:
    web:
      exposure:
        include: health,info

3단계: Spring Profile 활성화 확인

위 설정들이 application-prod.yml에 포함되어 있다면, 해당 프로파일이 실제로 활성화되고 있는지도 반드시 확인해야 한다. Spring Boot 앱을 실행할 때 다음과 같이 prod 프로파일이 활성화되어야 설정이 적용된다.

-Dspring.profiles.active=prod

기존에는 docker run 명령어에서 직접 전달했지만, Dockerfile 내 ENTRYPOINT를 다음과 같이 수정해 고정하는 방식으로 개선했다.

ENTRYPOINT ["java", "-Dspring.profiles.active=prod", "-jar", "app.jar"]

4단계: actuator 접근 권한 확인

설정이 잘 되어 있는데도 여전히 health check가 실패한다면, 보안 설정(SecurityConfig)을 점검해야 한다. EC2에 SSH 접속해 다음 명령어를 입력해 확인해봤다.

curl http://localhost:8080/actuator/health

해당 명령어를 실행했을 때 아래처럼 403 Forbidden 응답이 오면, actuator endpoint는 열려 있으나 접근 권한이 막혀 있다는 뜻이다.

또, SecurityConfig 클래스에서 actuator 경로도 허용해야 한다.

5단계: 외부 접속 테스트 및 보안 그룹 설정

EC2 내부에서는 health 응답이 잘 오는데도 외부 health check가 실패한다면, EC2 보안 그룹 설정을 점검해야 한다. AWS를 사용할 때는 특히나 보안 그룹 설정 문제인 경우가 많으니 잘 확인해두는 것이 좋다. 포트 8080이 퍼블릭으로 열려 있어야 외부에서 접근 가능하다.

EC2에서 다시 확인해보니 정상적으로 HTTP/1.1 200 OK 응답이 온 것을 볼 수 있다.

다음과 같이 웹 브라우저를 통해서도 볼 수 있는데, http://<EC2 퍼블릭 IPv4 주소>:8080/actuator/health 와 같이 입력해야 한다. 나는 EC2에 탄력적 IP를 할당하여 고정된 주소로 항상 접근 가능하도록 연결했다.

Redis 연결 실패 - ElastiCache 설정

배포 테스트가 정상적으로 끝났다고 생각했지만, 이후 테스트 중 Redis 연결 관련 오류가 발생했다.

로그를 자세히 보면 Redis 관련 오류라는 것을 알 수 있다.

Caused by: io. lettuce. core. RedisConnectionException: Unable to connect to
eightyage-cache. 2i7efi.ng. 0001.apn2. cache. amazonaws. com/<unresolved>: 6379

Redis 설정 점검

application-prod.yml에는 아래와 같이 Redis 설정을 해두었다.

data:
  redis:
    host: ${REDIS_HOST}
    port: 6379

그리고 REDIS_HOST 환경 변수는 GitHub Repository Secrets에 정상적으로 등록했다. 이 환경 변수에는 ElastiCache Redis 인스턴스의 엔드포인트가 들어간다.

EC2에서 직접 접속 확인

EC2에서 telnet으로 Redis에 접속을 시도해봤다.

telnet <REDIS_HOST> 6379

하지만 다음과 같이 연결이 되지 않았다.

원인 분석: 보안 그룹 인바운드 미설정

해당 문제는 ElastiCache Redis 인스턴스의 보안 그룹이 EC2의 접근을 허용하지 않아서 발생한 것이었다. Redis가 퍼블릭하게 열리지 않기 때문에, EC2처럼 내부 통신을 하려면 보안 그룹 간 인바운드 허용 설정이 필수다. 다음과 같이 인바운드 규칙에 EC2 인스턴스의 보안 그룹을 소스로 추가해준다.

보안 그룹 간 참조를 사용하는 이유: EC2 인스턴스의 IP는 변할 수 있으므로, 고정된 IP가 아닌 EC2가 속한 보안 그룹 자체를 참조하는 방식이 유지보수에 유리하다.

Redis 연결 성공

설정 변경 후 다시 접속을 시도해보니 정상적으로 연결이 되었다.

Spring Boot Actuator에서도 Redis 관련 항목이 포함된 health 정보가 정상적으로 출력되었다.

QueryDSL 사용하기(with JPA)

개발곰발 — Sat, 22 Mar 2025 00:15:35 +0900

QueryDSL란?

DSL(Domain-Specific-Language) : 특정 도메인에서 발생하는 문제를 효과적으로 해결하기 위해 설계된 언어.(ex. SQL, CSS, Regex 등)
QueryDSL : SQL 형식의 쿼리를 Type-Safe하게 생성할 수 있도록 하는 DSL을 제공하는 라이브러리. 엔티티의 매핑정보를 활용하여 쿼리에 적합하도록 쿼리 전용 클래스(Q클래스)로 재구성해준다.

✔️ Q클래스란?

Q클래스란 엔티티 클래스 속성과 구조를 설명해주는 메타데이터로, Type-Safe하게 쿼리 조건을 설정할 수 있다.
annotationProcessor를 통해 생성된 실제 Q클래스는 다음과 같다.

다 캡쳐하진 못했지만, Todo의 필드가 QTodo에서도 보이는 것을 알 수 있다.

Todo 엔티티(왼) / QTodo(오)

QueryDSL 시작하기

querydsl-jpa 의존성 추가하기

Spring Boot 3 이후부터는 javax에서 jakarta로 변경되었기 때문에 뒤에 꼭 jakarta를 붙여야 한다.
Q클래스를 사용하기 위해 annotationProcessor도 추가한다.

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"

다음과 같은 gradle script를 추가해 협업 시 Q클래스의 위치를 지정해줄 수 있디.

def generated = 'src/main/generated'

tasks.withType(JavaCompile).configureEach {
    options.getGeneratedSourceOutputDirectory().set(file(generated))
}

clean {
    delete file(generated)
}

여러 개발자가 같은 Q클래스를 Git에 올리면, 빌드할 때마다 변경된다. 따라서 .gitignore에 다음과 같이 등록해 놓는다. QueryDSL의 라이브러리 버전에 따라 생성되는 Q클래스 생김새가 달라질 수 있어 추가 해놓는 것이 좋다.

###QueryDSL###
/src/main/generated/

JPAQueryFactory Bean 등록

JPAQueryFactory를 사용하려면 JPAConfiguration 설정 클래스를 추가해야 한다.
QueryDSL이 JPA를 통해 엔티티를 조회하기 때문에 EntityManager가 필요하다.
JPAQueryFactory 생성 시 EntityManager를 넣어준다.

@Configuration
public class QueryDslConfig {

    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

TodoRepositoryQuery interface 생성

인터페이스를 하나 만들고, QueryDSL로 수행항 메서드를 선언한다. 나는 TodoRepositoryQuery라는 이름으로 만들었다.

public interface TodoRepositoryQuery {

    Optional<Todo> findByIdWithUser(Long todoId);

}

TodoRepositoryQueryImpl 생성

위에서 만든 TodoRepositoryQuery 인터페이스를 구현하는 TodoRepositoryQueryImpl 클래스를 만든다.
클래스 이름은 뒤에 Impl이라는 postfix를 반드시 붙여 구현한다.

@RequiredArgsConstructor
public class TodoRepositoryQueryImpl implements TodoRepositoryQuery {

    private final JPAQueryFactory jpaQueryFactory;

    @Override
    public Optional<Todo> findByIdWithUser(Long todoId) {
        return Optional.ofNullable(jpaQueryFactory.selectFrom(todo)
                .where(todo.id.eq(todoId))
                .leftJoin(todo.user)
                .fetchJoin() 
                .fetchOne());
    }
}

사용할 JPA Repository 수정

위에서 만든 TodoRepositoryQuery를 실제로 사용할 TodoRepository에 extends 한다.

public interface TodoRepository extends JpaRepository<Todo, Long>, TodoRepositoryQuery {
	//...중략
}

QueryDSL 쿼리 작성하기

영상 자료에 있는 코드를 다 가져오진 않고 내가 현재 작성 중인 쿼리로 대체하겠다. 검색 조건은 다음과 같다.

유저와 함께 일정 검색
검색 키워드로 일정 제목 검색
일정 생성일 범위로 일정 검색(최신순으로 정렬)
담당자 닉네임으로 일정 검색
검색 결과는 페이징 처리 하기
일정 제목, 담당자 수, 댓글 개수 보여주기

처음에는 findByTitle()처럼 검색 조건을 따로따로 받아 만드려고 하다가, 검색 API를 하나로 통일하고 파라미터를 추가해 동적 쿼리를 만드는 것이 나은 것 같아 바꿨다. 한편으로는 실무에서 지금보다 검색 조건이 훨씬 많은 경우에도 계속 파라미터만 추가하는 방식으로 구현할까? 라는 궁금증이 들었다.

전체 코드

응답 DTO로 TodoSearchResponse를 새로 만들어 반환하도록 했다. 해당 DTO에는 제목, 담당자 수, 댓글 개수를 담는다.

@GetMapping("/todos/search")
public ResponseEntity<Page<TodoSearchResponse>> searchTodos(
        @AuthenticationPrincipal AuthUser authUser,
        @RequestParam(required = false) String title,
        @RequestParam(required = false) LocalDate startDate,
        @RequestParam(required = false) LocalDate endDate,
        @RequestParam(required = false) String nickName,
        @RequestParam(defaultValue = "1") int page,
        @RequestParam(defaultValue = "10") int size) {
    return ResponseEntity.ok(todoService.searchTodos(authUser, title, startDate, endDate, nickName, page, size));
}

@Override
public Page<TodoSearchResponse> searchTodos(
        String title, LocalDate startDate, LocalDate endDate, 
        String nickName, Pageable pageable) {

    BooleanBuilder builder = new BooleanBuilder();

    if (title != null && !title.isEmpty()) {
        builder.and(todo.title.containsIgnoreCase(title));
    }

    if (startDate != null && endDate != null) {
        builder.and(todo.createdAt.between(startDate.atStartOfDay(), endDate.atTime(23, 59, 59)));
    }

    if (nickName != null && !nickName.isEmpty()) {
        builder.and(todo.user.nickName.containsIgnoreCase(nickName));
    }

    List<TodoSearchResponse> results = jpaQueryFactory
            .select(Projections.constructor(
                    TodoSearchResponse.class,
                    todo.title,
                    todo.managerCount,
                    todo.commentCount
            ))
            .from(todo)
            .where(builder)
            .orderBy(todo.createdAt.desc())
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize())
            .fetch();

    JPAQuery<Long> countQuery = jpaQueryFactory
            .select(todo.count())
            .from(todo)
            .where(builder);

    return PageableExecutionUtils.getPage(results, pageable, countQuery::fetchOne);
}

유저와 함께 일정 검색

유저와 함께 일정을 검색하는 기능은 기존 쿼리를 QueryDSL로 바꿔야 했다. 기존 JQPL 쿼리는 다음과 같다.

다음은 QueryDSL로 바꾼 코드다. SQL에 익숙하다면 읽기에 문제가 없을 것이다. 참고로, todo와 user는 Q클래스에서 import 해온 것이다.

selectFrom(todo) : Todo 엔티티를 기준으로 조회한다.
.leftJoin(todo.user, user) : 일정에 해당하는 User 정보를 함께 조회한다.
.fetchJoin() : N+1 문제를 해결할 수 있다.
.fetchOne() : 단일 엔티티를 반환한다.

✔️ fetchOne() vs fetch() vs fetchFirst() 차이

fetchOne() : 하나의 결과를 가져오고 싶을 때 사용.
- 쿼리 결과 1개 - 해당 엔티티 반환.
- 쿼리 결과 없음 - null 반환.
- 쿼리 결과 여러 개 - 예외(NonUniqueResultException) 발생.
fetch() : 리스트 형태와 같이 여러 개의 결과를 가져오고 싶을 때 사용.
fetchFirst() : limit(1).fetchOne()과 같은 결과를 낼 때 사용.
- 쿼리 결과 1개 - 해당 엔티티 반환.
- 쿼리 결과 없음 - null 반환.
- 쿼리 결과가 여러 개 - 예외를 발생시키지 않고 첫 번째 결과만 반환.
fetchOne()은 결과가 유일할 때 사용하고, fetchFirst()는 여러 개 중 하나만 가져올 때 사용.

검색 키워드로 일정 제목 검색

BooleanBuilder를 사용해 여러 개의 조건을 동적으로 추가했다. 따라서 제목과 생성일을 동시에 필터링해 검색하거나 닉네임과 생성일을 기준으로 검색하는 등의 동작이 가능하다. BooleanBuilder에 대한 자세한 내용은 아래에서 다룬다.

우선 BooleanBuilder를 먼저 생성하고, 제목이 비어있지 않은 경우에만 builder에 and() 연산자를 사용해 AND 조건을 추가한다. 따라서 모든 파라미터가 들어온다면 제목, 생성일, 닉네임을 모두 충족하는 일정을 검색하게 된다.

containsIgnoreCase() : 대소문자 상관없이 특정 문자열을 포함하고 있으면 treu를 반환한다.

일정 생성일 범위로 일정 검색

createdAT 필드가 startDate와 endDate 사이에 포함되는 데이터를 필터링한다. /todos/search?startDate=2025-03-10&endDate=2025-03-12&page&size 와 같이 호출할 경우, createdAt이 2025-03-10 00:00:00 이상이고 2025-03-12 23:59:59 이하인 데이터를 조회한다.

.atStartOfDay() : 해당 날짜의 00:00:00(자정)으로 변환한다.
.atTime(23, 59, 59) : 해당 날짜의 23:59:59 (하루의 마지막 순간)으로 변환한다.

담당자 닉네임으로 일정 검색

제목 검색과 마찬가지로 키워드가 부분적으로 일치해도 검색이 가능하다.

공통 코드 - Projections 사용

.select(Projections.constructor(TodoTitleResponse.class, todo.title)) : 여기서 Projections.constructor()은 DTO로 데이터 매핑 시 사용하는 QueryDSL의 기능이다. TodoTitleResponse DTO를 활용해 todo.title 값을 매핑하고 있다.
.where(builder) : 동적 검색 조건을 적용한다.
.offset(pageable.getOffset()) : 조회할 데이터의 시작 위치(몇 개를 건너뛸지)를 설정한다.
.limit(pageable.getPageSize()) : 가져올 최대 개수를 pageable.getPageSize()로 설정한다.
fetch() : 리스트 형태로 조회한다.
PageableExecutionUtils.getPage() : results.size() < pageable.getPageSize()라면 countQuery 실행 없이 페이징 정보를 생성한다.
위 코드에서 countQuery는 페이징 시 필요한 정보인 전체 검색 결과 개수를 구하는 역할을 한다.

✔️ PageableExecutionUtils란?

PageableExecutionUtils란 Spring Data JPA에서 Page 객체를 최적화하여 반환하는 유틸리티 메서드다. 불필요한 카운트 쿼리를 줄여 성능을 향상시킬 수 있다. PageableExecutionUtils 대신 PageImpl을 사용할 수도 있는데, PageImpl은 데이터를 조회하는 쿼리와 전체 개수를 조회하는 쿼리를 모두 호출해야 한다.

위 코드를 PageImpl로 바꿔보면 다음과 같다. 항상 countQuery를 실행하므로 불필요한 쿼리를 실행할 가능성이 높다.

long total = countQuery.fetchOne();
return new PageImpl<>(titleList, pageable, total);

PageableExecutionUtils은 countQuery 실행을 지연시켜 꼭 필요할 때만 실행되도록 최적화하는 방식이다. 데이터의 개수가 적을 경우 countQuery 실행을 생략해 성능을 향상시킨다.

return PageableExecutionUtils.getPage(titleList, pageable, countQuery::fetchOne);

countQuery를 생략 가능한 경우는 다음과 같다.

페이지 시작이면서 컨텐츠 사이즈가 페이지 사이즈보다 작을 때
마지막 페이지 일 때

결과

제목으로 검색 / 생성일 범위로 검색 / 닉네임으로 검색

생성일 + 닉네임 검색 / 생성일 + 제목 검색 / 제목 + 닉네임 검색

동적 쿼리

BooleanExpression

동적 쿼리는 사용자의 요구에 따라 변하는 쿼리를 말한다. 동적 쿼리를 알기위해서는 먼저 BooleanExpression에 대해 알아야 한다. 아래 내용은 우테톡 영상으로 보고 간단하게 정리한 내용이다.

BooleanExpression : 조건 부분에 들어가는 참/거짓 표현식. 아래와 같은 식을 말한다.

.from(store)
.where(store.name.eq("덮밥"))

BooleanExpression은 여러 개를 조합해 하나의 큰 BooleanExpression을 만들 수 있다.
여러 메서드로 분리해 작성할 수 있다.
.where(expression1, expression2)에서 , 는 AND와 같은 의미를 지닌다.

.from(store)
.where(expression1, expression2)
   
private BooleanExpression expression1(final String name) {
     return null이 아닌 expression;
}
   
private BooleanExpression expression2(final String name) {
     return null이 아닌 expression;
}

null이 반환되면 자동으로 조건에서 무시한다. 만약 아래 코드에서 expression1에 null이 들어가게 된다면 무시하고 expression2에 대해서만 조건을 걸고 쿼리를 실행한다.

.from(store)
.where(expression1, expression2)
   
private BooleanExpression expression1(final String name) {
    if (name == null) return null;
     return null이 아닌 expression;
}
   
private BooleanExpression expression2(final String name) {
     return null이 아닌 expression;
}

이렇게 BooleanExpression을 활용해 다음과 같이 동적 쿼리를 작성할 수 있다. BooleanExpression(혹은 null)을 반환하는 matchesCondition 메서드를 having절에 넣어줌으로써 동적으로 having 조건을 설정할 수 있다.

public List<Store> findPopularStoreByTotalRateOrOrderWithMin(final String type, final String min) {
    return jpaQueryFactory.selectFrom(store)
            .leftJoin(store.orders, order)
            .leftJoin(order.review, review)
            .groupBy(store.id)
            .having(matchesCondition(type, min))
            .fetch();
}

private BooleanExpression matchesCondition(final String type, final String min) {
    if (type.equals("orderCount")) {
        return filterByOrderCount(min);
    }
    if (type.equals("rate")) {
        return filterByRate(min);
    }
    return null;
}

BooleanBuilder

BooleanBuilder는 동적 쿼리를 작성할 때 유용하게 사용되는 클래스다. 검색 조건이 유동적으로 바뀌거나 여러 개의 조건을 조합해야 할 때 주로 사용된다.

여러 개의 조건을 필요할 때만 추가 가능 → 동적 쿼리 구현
조건이 있으면 추가하고, 없으면 제외하는 유연한 방식
where() 절에 그대로 넣어서 사용 가능
and(), or(), andNot() 등의 메서드 제공

따라서 위에 작성한 검색 기능에 적합하다고 판단되어 BooleanBuilder를 사용하였다. BooleanExpression 예시 코드처럼 type에 따라 하나의 조건만 적용된다면 BooleanExpression이 더 적합할 수 있겠지만, 여러 개의 조건을 조합할 때는 BooleanBuilder가 더 좋지 않을까 생각한다.

BooleanExpression과 BooleanBuilder 차이

그래서 BooleanExpression과 BooleanBuilder 차이를 한마디로 정리하면 뭘까?

검색하다 발견한 김영한님의 답변으로 간단하게 설명할 수 있을 것 같다.

QueryDSL에서 Projections를 사용하기

QueryDSL의 Projections는 DTO로 원하는 필드만 선택하여 조회할 때 사용된다. 엔티티를 그대로 조회하면 불필요한 필드까지 가져오게 되지만, Projections를 활용하면 필요한 데이터만 가져올 수 있다.

Projections.constructor() : 생성자 기반 매핑

Projections.constructor()은 DTO의 생성자를 활용해 필드를 매핑하는 방식이다.위에서 검색 기능을 구현할 때 사용한 방식이다.

List<TodoSearchResponse> results = jpaQueryFactory
        .select(Projections.constructor(
                TodoSearchResponse.class,
                todo.title,
                todo.managerCount,
                todo.commentCount
        ))
        .from(todo)
        .fetch();

Projections.bean() : Setter 기반 매핑

Projections.bean()은 Setter를 활용해 필드를 매핑하는 방식이다. 필드명이 일치하면 자동 매핑된다. Setter를 활용한 매핑이라 불변 객체에는 적합하지 않다.

.select(Projections.bean(TodoTitleResponse.class, todo.title.as("title")))

필드명이 다를 경우 Expressions.as()를 사용해야 한다.

Projections.fields() : 필드명 자동 매핑

Projections.fields()는 DTO의 필드명과 일치하는 값이 자동 매핑된다. 기본 생성자가 있어야 한다.

List<TodoSearchResponse> results = jpaQueryFactory
        .select(Projections.fields(
                TodoSearchResponse.class,
                todo.title,
                todo.managerCount,
                todo.commentCount
        ))
        .from(todo)
        .fetch();

필드명이 다를 경우 Expressions.as()를 사용해야 한다.

@QueryProjection

DTO 생성자에 @QueryProjection을 붙이면 QueryDSL이 자동으로 해당 DTO의 Q클래스를 생성한다.

@Getter
public class TodoTitleResponse {

    private String title;

    @QueryProjection // QueryDSL에서 생성자 기반 매핑을 지원하도록 설정
    public TodoTitleResponse(String title) {
        this.title = title;
    }
}

✔️ @QueryProjection 장단점

장점
- 컴파일 시점에 타입 체크를 할 수 있어 안정적이다.
- DTO 필드 변경 시 쿼리에서 자동으로 감지할 수 있다.
단점
- DTO가 QueryDSL에 종속된다.
- QDTO 클래스를 빌드할 때마다 생성해야 한다.
- QueryDSL을 제거할 경우 DTO 수정이 필요하다.

참고 자료

[AWS] EC2와 RDS를 연결해보자 (+Elastic IP, health check, security groups)

개발곰발 — Sat, 22 Mar 2025 00:05:22 +0900

이번 개인 과제 중 AWS를 실습하는 부분이 있는데, 요구사항은 다음과 같다. 먼저 EC2와 RDS를 구축하고 연결하는 과정을 기록해보려고 한다.✍

✔️ EC2
- EC2 인스턴스에서 어플리케이션을 실행한다.
- 탄력적 IP를 설정해 외부에서도 접속할 수 있도록 한다.
- 서버 접속 및 Live 상태를 확인할 수 있는 health check API를 만든다.

✔️ RDS
- RDS 데이터베이스를 구축한다.
- EC2에서 실행되는 어플리케이션에 연결한다.

✔️ S3
- S3 버킷을 생성한다.
- 유저의 프로필 이미지 업로드 및 관리 API를 구현한다.

프로젝트를 EC2에 배포하기

로컬에서 프로젝트 빌드하기

인텔리제이에서 프로젝트를 빌드해보자! EC2 인스턴스는 이미 만들어놨다는 가정 하에 진행하겠다.

1) Gradle 탭에서 Task - build에서 왼쪽에 톱니바퀴 모양이 있는 build를 두 번 클릭한다.

2) BUILD SUCCESSFUL 메시지가 뜨고 빌드가 정상적으로 수행되었다면 프로젝트에서 build - libs에 생긴 파일을 확인한다.

여기서 expert-0.0.1-SNAPSHOT.jar 파일을 EC2로 보내야 한다.

.jar 파일이 뭐길래...?

Java ARchive (자바 아카이브) 파일의 줄임말.
Spring Boot 프로젝트 전체를 하나로 압축한 실행 파일이다.
내가 작성한 소스 코드, 사용하는 라이브러리, 설정 파일, 실행 메타 정보 등이 전부 들어있다.
따라서 이 파일만 보내면 EC2에서도 별다른 설치 없이 바로 실행할 수 있다!

⚠️ 빌드 과정에서 발생한 오류

Error creating bean with name 'jwtAuthenticationFilter' defined in file ... 오류
- JwtAuthenticationFilter 클래스가 JwtUtil을 주입받으려고 했는데 스프링 컨테이너에 JwtUtil 빈이 등록되어 있지 않아 발생한 오류이다.
- JwtUtil을 Mock으로 주입해 해결했다.
Spring Security 인증이 걸리는 테스트가 있어 인증 객체가 필요하다는 문제가 있었다.
- @WithMockUser을 추가해 테스트용으로 가짜 인증 객체(SecurityContext)에 넣어 해결했다.

EC2에 .jar 파일 보내고 실행하기

1) 로컬에서 .jar 파일을 EC2로 보낸다. 로컬에서 다음 명령어를 입력한다.

나는 window라서 wsl에서 입력했다.

scp -i key.pem build/libs/expert-0.0.1-SNAPSHOT.jar ubuntu@EC2_IP:/home/ubuntu/

혹시 key.pem과 빌드된 파일이 다른 곳에 있다면 각 경로를 입력해줘야 한다. 나는 각자 다른 곳에 있어서 다음과 같이 경로를 하나하나 입력했다. 만약 잘 전송됐다면 왼쪽에 파일명이 뜨고 오른쪽에 100% 라고 뜰 것이다.

2) EC2에 접속한다.

key.pem이 있는 폴더에서 다음과 같이 입력한다.

ssh -i key.pem ubuntu@EC2_IP

이렇게 Welcome to Ubuntu~라는 글자가 나오면 정상적으로 접속된 것이다.

3) EC2에서 Spring boot 서버를 백그라운드로 실행한다.

우선 ls 명령어를 통해 실제로 EC2에 .jar 파일이 있는지 확인한다. 파일이 제대로 있다면 다음 명령어를 입력한다.

nohup java -jar expert-0.0.1-SNAPSHOT.jar &

nohup : no hang up의 줄임말로, 터미널 연결이 끊겨도 프로세스가 죽지 않고 계속 실행된다. 로그는 기본적으로 nohup.out 파일에 저장된다.
java -jar expert-0.0.1-SNAPSHOT.jar : java 명령어로 .jar 파일을 실행한다. Tomcat이 내장되어있어 8080 포트에서 바로 실행된다.
& : 해당 명령어를 백그라운드로 실행한다. 터미널에서 바로 다음 명령어를 입력할 수 있고, 실행된 프로세스는 PID를 부여받아 별도로 동작한다.

서버가 잘 실행된다면 다음과 같이 뜰 것이다.

[1] : 백그라운드 작업 번호
16824 : 실행된 프로세스의 PID (Process ID)
nohup: ignoring input and appending output to 'nohup.out' : 터미널 입력을 무시하고 모든 출력(로그)을 nohup.out 파일에 저장하겠다는 의미

⚠️ 배포 과정에서 발생한 오류

MySQL 연결 실패 오류 발생
- DB URL에서 localhost로 되어 있으면 EC2가 자기 자신을 찾다가 오류가 발생한다고 한다.
- 이때는 RDS를 구축하지 않은 상태여서 일단 DB 연결 없이 서버만 실행하는 방향으로 시도했다.
- 따라서 아래와 같이 application.properties에서 DB 설정을 주석 처리한후 다시 빌드했다.
8080 포트를 이미 다른 프로세스가 잡고 있는 문제 발생
- 새로 빌드하고 배포 후 다시 실행하려고 하자 위와 같은메세지가 나왔다. 기존에 실행한 java -jar 프로세스가 아직 살아있거나 두 번 실행해 포트 충돌이 난 것이다.
- ps -ef | grep java 명령어를 이용해 PID를 확인 후, kill -9 [PID] 명령어로 기존 프로세스를 종료한 후, 다시 서버를 실행한다.
접속이 안된다면 보안 규칙에서 8080 포트가 열려 있는지 확인한다. 만약 열려있지 않다면 다음과 같이 Inbound rules에 8080 포트를 추가한다.
nohup java -jar expert-0.0.1-SNAPSHOT.jar & 명령어 오류 : nohup: failed to run command 'java': No such file or directory 라는 오류 메세지가 나타났다. EC2 인스턴스에 Java가 설치되어 있지 않아서 발생한 오류이다. 다음과 같은 명령어를 입력해 Java를 설치 후 다시 시도한다.

sudo apt update
sudo apt install openjdk-17-jdk -y

탄력적 IP(Elastic IP) 설정하기

EC2 대시보드에서 Network & Security - Elastic IPs를 클릭한다.

Allocate Elastic IP address 클릭하고 Amazon에서 제공하는 IP를 선택 후 Allocate 한다.

생성된 Elastic IP를 선택하고 Actions - Associate Elastic IP address를 누른다.

연결할 인스턴스를 선택 후 Associate 한다.

이제 Public IP 대신 Elastic IP를 사용하면 된다. Elastic IP를 사용하면 인스턴스를 재시작해도 IP가 변하지 않고, Route53이나 외부 DNS에서 연결을 쉽게 할 수 있다. 그런데 연결이 안 된 EIP는 비용이 발생한다고 하니 꼭 인스턴스 연결 상태를 확인하자!

RDS

RDS 인스턴스를 생성 했다면, EC2와 RDS를 연결해야 한다.

보안 그룹 설정하기

기존에 EC2가 속한 보안그룹을 RDS에 추가한다. 나는 launch-wizard-2 라는 이름의 보안 그룹을 EC2에 적용했으므로 RDS에도 같은 것을 적용했다.

그리고 RDS 보안 그룹 Inbound rules에 MySQL/Aurora 포트(TCP 3306)를 추가했다. RDS 인스턴스는 AWS 내에서 격리되어 있기 때문에 외부에서 바로 접근할 수 없다. 따라서 RDS의 보안 그룹에서 MySQL/Aurora 포트(3306)를 허용해야, EC2 인스턴스의 보안 그룹 또는 특정 IP가 RDS와 연결될 수 있다.

RDS 연결 정보 작성하기

application.properties에 다음과 같이 RDS 연결 정보를 작성했다.

spring.datasource.url=jdbc:mysql://<엔드포인트>:<포트>/<DB명>
spring.datasource.username=admin
spring.datasource.password=비밀번호
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

spring.datasource.url : RDS 엔드포인트 + 포트 + DB명
spring.datasource.username : RDS 사용자명
spring.datasource.password : RDS 비밀번호
driver-class-name ; MySQL 사용 시 추가

참고로 RDS 엔드포인트는 RDS 내 데이터베이스에 들어가면 나와있다.

다시 빌드 후 배포하기

이제 위에서 EC2로 배포할 때 했던 과정을 다시 해주면 된다.

빌드
EC2로 새로 빌드한 .jar 파일 전송
EC2 접속 후 새 버전 실행
로그 확인 or 브라우저 테스트

health check API로 확인하기

health check를 위해 다음 의존성을 추가한다.

implementation 'org.springframework.boot:spring-boot-starter-actuator'

다음은 application.properties에 추가하는 설정으로, RDS 연결 확인을 위해 필요하다.

management.endpoint.health.show-details=always
management.health.db.enabled=true

management.endpoint.health.show-details=always
- 기본값은 when-authorized로, 권한이 없으면 status: "UP"만 보여준다.
- DB, Disk, Custom Health 등 상세 정보까지 모두 출력한다.
management.health.db.enabled=true
- Spring Boot Actuator에서 DataSource 연결(DB Health Check) 여부를 켜는 설정이다.
- DB 연결 상태를 확인하고 싶을 때 true로 설정한다.

health check로 확인해보면 다음과 같이 tjqjdmlDB가 정상적으로 돌아가고 있는 것을 알 수 있다.

위 결과에서 기본 경로가 /actuator/health가 아니라 그냥 /health인데, 아래 설정을 추가하면 /actuator 없이 루트 경로로 health check가 가능하다.

management.endpoints.web.base-path=/

[AWS] S3 시작하기 - bucket 만들기, bucket policy 설정, 정적 웹 사이트 호스팅, EC2에 S3 권한 주기

개발곰발 — Fri, 21 Mar 2025 00:50:03 +0900

S3(Simple Storage Service)란?

Amazon S3는 정적 웹 사이트 호스팅, 온라인 백업, 데이터 아카이브, 기업 애플리케이션, Big Data 분석 등 다양한 용도로 사용된다.
버킷(Buckets) : 데이터를 저장하는 가장 상위 레벨의 폴더 형태의 컨테이너. S3에 저장되는 파일들을 ‘객체’라고 부르고, 모든 객체는 ‘키’(디렉토리)로 식별된다.
버킷 이름 규칙
- 대문자와 언더스코어 사용 금지
- 길이 제한: 3자 이상, 63자 이하로 작성
- 소문자, 숫자, 점(.) 그리고 하이픈(-)만 사용 가능
- 반드시 문자 또는 숫자로 시작하고 끝내기
- 두 개의 점(.) 연속 사용 금지
- IP 주소 형식 사용 금지

S3 시작하기

버킷 만들기

Create bucket을 눌러 버킷을 생성해보자!

이름만 정하고 다른 옵션은 일단 그대로 두었다. 버킷의 이름은 global unique 하기 때문에 이미 있는 이름인 경우가 많다. 버킷 생성이 안된다면 이름 때문인지 확인해보자.

버킷 생성이 완료되면 다음과 같이 리스트에 나타난다. 해당 버킷의 AWS Resion은 서울인 것을 알 수 있고, 다른 Regon인 버킷이 추가되더라도 이 리스트에서 모두 볼 수 있다.

버킷에 파일 직접 업로드 하기

버킷 안에 들어가면 다음과 같이 되어있는데, 맨 오른쪽 Upload를 누른다.

들어가서 Add File을 통해 아무 파일이나 올린 후 Upload를 누른다.

그러면 이렇게 정상적으로 파일이 업로드되었음을 알 수 있다.

파일명을 눌러보면 다음과 같이 뜨는데, Object URL과 Open을 각각 눌러서 비교해보자.

각각 눌러서 보니 다음과 같은 차이점이 있다. 현재 접근 권한이 없어 아래과 같이 나오는데, 왜 Open을 누르면 제대로 보일까? 이 있는데. Open을 누르면 S3에서 만들어진 pre-signed URL이라는 것을 자동으로 만들어준다. pre-signed URL은 권한이 없어도 권한을 만들어주는 URL이라서 두번째처럼 접근이 가능하다.

Object URL로 들어갔을 때

Open으로 들어갔을 때

폴더 만들기

이제 폴더도 만들어보자. 다시 버킷에 들어가서 Create folder를 누른다.

폴더 이름을 적을 때는 /가 뒤에 자동으로 들어가기 때문에 /를 붙이지 않아도 된다. 폴더 이름을 적고 Create folder를 누른다.

그럼 이렇게 폴더가 완성되고, 이 안에서도 파일을 업로드할 수 있다.

버킷 폴리시(Bucket Policy)

버킷 폴리시란?

버킷 폴리시(Bucket Policy) : IAM 정책과 유사한 JSON 형식의 문서. S3 버킷과 그 안의 객체에 대한 접근 권한을 제어하는 역할을 한다.
특징
- 버킷 내 모든 객체에 대한 접근 제어
- 특정 객체 또는 특정 객체 그룹에 대한 접근 제어
- 허용할 IP 주소 또는 IP 대역을 지정해 특정 위치에서만 접근이 가능하도록 설정
- 접근할 수 있는 리소스의 범위를 지정해 필요한 리소스만 접근하도록 제한
- 암호화된 연결(SSL/TLS)을 사용하도록 강제 가능

버킷 폴리시 적용하기

버킷에서 Permissions에 들어간다.

Block public access도 모두 on이고, Bucket policy도 아예 작동하지 않는 것을 볼 수 있다.

먼저 Block public access에 들어가서 Block all public access에 되어있던 체크박스를 해제한다. 버킷을 만들 때 있었던 부분인데 이렇게 따로 설정을 바꿀 수 있다. 설정을 바꾼 후 Save changes를 누른다.

그럼 이렇게 off 된 모습을 볼 수 있다.

이제 Bucket policy에 들어가서 Bucket ARN을 복사한 후, Policy Generator로 들어간다.

Policy Generator에서 다음과 같이 설정해준다. Principal은 전체를 대상으로 하기 위해 * 를 적었다. ARN에는 들어오기 전 복사한 ARN을 붙여넣기 한다.

Actions는 줄 권한을 설정하면 되는데, 나는 읽기 권한을 위해 GetObject를 선택했다.

다 작성했다면 Add Statement를 누르고, Generate Policy를 누른다.

그럼 다음과 같은 JSON 형식의 Policy 문서가 뜨는데, 복사해서 Bucket policy에 붙여넣기 한다.

여기서 수정해야 할 점은 버킷 안에 있는 모든 것에 대한 권한이기 때문에 "Resource": "arn:aws:s3:::my-gom-bucket"가 아니라 "Resource": "arn:aws:s3:::my-gom-bucket/*"로 바꿔야 한다.

이렇게 모두 설정을 마치고 Object URL로 들어가니 이전과 달리 이미지가 잘 나오는 모습을 볼 수 있다.

정적 웹 사이트 호스팅

정적 웹 사이트 호스팅을 해보기 위해 html 파일을 버킷에 업로드했다.

업로드 후 버킷에서 Properties에 들어간다.

맨 아래 Static website hosting에서 Edit을 누른다.

다음과 같이 세팅을 해준다. index document에서는 내가 올린 html 파일명을 적어준다.

그럼 이렇게 Bucket website endpoint가 뜨게 되는데, 들어가보면 내가 올린 html 파일의 내용과 같다는 것을 알 수 있다. 만약 제대로 뜨지 않는다면 Bucket policy를 잘 설정했는지 확인하자.

정상적으로 뜬다!

EC2에 S3 권한 주기

EC2에 S3 권한을 주기 위해서는 IAM Role을 적용해줘야 한다. IAM - Role에 들어가서 Create role을 클릭한다.

Use case에 EC2 선택 후 다음으로 넘어간다.

검색창에 S3를 입력 후 AmazonS3FullAccess를 체크한다. 혹은 특정 버킷에만 권한을 주는 커스텀 정책을 만들 수도 있다. 그 다음 Role의 이름을 정하고 Create role을 눌러 생성한다.

다음과 같이 새로운 role이 생성된 것을 볼 수 있다.

이제 내 EC2 인스턴스로 와서 Actions - Security - Modify IAM Role을 누른다.

방금 만든 ec2-s3-access-role을 선택하고, Update IAM Role을 눌러서 저장한다.

그럼 이제 EC2가 S3 접근 권한을 갖게 되었다. 따라서 application.properties(혹은 application.yml)에 access-key와 secret-key를 작성할 필요가 없다. Role을 달면 EC2 인스턴스 메타데이터에서 자동으로 임시 키를 발급받아서 AWS 접근하게 된다.

[Java/Spring] 인터페이스 vs enum 클래스 vs final 클래스 - 상수 관리하는 법

개발곰발 — Wed, 19 Mar 2025 01:33:54 +0900

지난 프로젝트에서 다른 팀원 분이 상수를 인터페이스로 관리하는 것을 봤다. final 클래스나 enum 클래스를 사용하는 것이 더 나은 것이 아닐까? 하는 궁금증이 들어 검색도 해보고 튜터님께 찾아가 질문해봤다.

예시 코드는 내가 작성한 에러 메세지 enum 클래스인데, GPT한테 각각의 경우에 맞게 수정을 해달라고 해봤다.

final 클래스로 상수 관리하기

상수를 관리하려고 할 때 사용되는 가장 고전적인 방법이 아닐까 싶다. final 클래스를 만들고 , 상수들을 static final로 선언한다. 이렇게 하면 정적 import를 통해 클래스 이름을 생략해서 사용할 수 있다는 장점이 있다. 하지만 확장성과 유지보수성 측면에서 enum보다 떨어진다. 만약 final 클래스로 상수를 관리한다면 기본 생성자를 private으로 설정해 인스턴스화를 방지하는 것을 잊지 말자.

public final class ErrorOrderMessages {
    public static final String CANNOT_CANCEL_ORDER = "취소할 수 없는 주문입니다.";
    public static final String ONLY_USER_CAN_CANCEL = "본인의 주문만 취소할 수 있습니다.";
    public static final String ORDER_NOT_FOUND = "주문 내역이 존재하지 않습니다.";
    public static final String MINIMUM_ORDER_NOT_MET = "최소 주문 금액 이상 주문해야 합니다.";
    public static final String NOT_BUSINESS_HOURS = "현재 영업 시간이 아닙니다.";

    public static final String NOT_OWNER_ORDER = "본인 가게 주문만 처리할 수 있습니다.";
    public static final String ALREADY_DELIVERING_OR_COMPLETED = "이미 배달이 시작되었거나 완료된 주문입니다.";
    public static final String MUST_BE_ACCEPTED_BEFORE_COOKING = "주문 접수 후에 조리를 시작할 수 있습니다.";
    public static final String MUST_BE_COOKING_BEFORE_DELIVERY = "조리를 시작한 주문만 배달할 수 있습니다.";
    public static final String MUST_BE_DELIVERING_BEFORE_COMPLETE = "배달중인 주문만 배달 완료 처리를 할 수 있습니다.";
    public static final String ALREADY_COMPLETED = "이미 배달이 완료된 주문입니다.";

    private ErrorOrderMessages() {} // 인스턴스화 방지
}

튜터님은 상속 방지가 더 중요하다거나 캡슐화 자체가 중요하다면 final 클래스를 추천할 수도 있다고 하셨다.

interface로 상수 관리하기

인터페이스의 역할이 뭘까? 인터페이스는 어떤 클래스를 구현할 때 틀을 제공해주는 역할을 한다. 하지만 아래와 같은 경우는 틀을 제공하는 것이 아니라 이미 정해놓은 상수를 모아두는 역할을 할 뿐이다. 이렇게 인터페이스의 역할을 벗어나면 이를 구현하는 클래스들 사이의 일관성이 떨어지게 된다.

public interface ErrorOrderMessage {
    String CANNOT_CANCEL_ORDER = "취소할 수 없는 주문입니다.";
    String ONLY_USER_CAN_CANCEL = "본인의 주문만 취소할 수 있습니다.";
    String ORDER_NOT_FOUND = "주문 내역이 존재하지 않습니다.";
    String MINIMUM_ORDER_NOT_MET = "최소 주문 금액 이상 주문해야 합니다.";
    String NOT_BUSINESS_HOURS = "현재 영업 시간이 아닙니다.";

    String NOT_OWNER_ORDER = "본인 가게 주문만 처리할 수 있습니다.";
    String ALREADY_DELIVERING_OR_COMPLETED = "이미 배달이 시작되었거나 완료된 주문입니다.";
    String MUST_BE_ACCEPTED_BEFORE_COOKING = "주문 접수 후에 조리를 시작할 수 있습니다.";
    String MUST_BE_COOKING_BEFORE_DELIVERY = "조리를 시작한 주문만 배달할 수 있습니다.";
    String MUST_BE_DELIVERING_BEFORE_COMPLETE = "배달중인 주문만 배달 완료 처리를 할 수 있습니다.";
    String ALREADY_COMPLETED = "이미 배달이 완료된 주문입니다.";
}

하지만 튜터님 중 한 분은 인터페이스를 선호하진 않지만, 상수만을 저장하는 용도라고 한다면 인터페이스도 많이 사용할 것 같다고 말씀해주셨다. 혹은 상수 재사용이 제일 중요하다 하면 인터페이스를 주로 쓸 수 있을 것이라고 하셨다.

enum 클래스로 상수 관리하기

만약 에러 메세지를 여러 언어로 제공해야 하는 경우가 생긴다면 어떨까? enum 클래스를 사용한다면 그냥 필드 하나만 추가해주면 돼서 유지보수가 더 쉽다. enum은 특히 잘못된 값을 방지할 수 있어 타입 안정성을 보장한다는 장점이 있다.

@Getter
public enum ErrorOrderMessage {
    CANNOT_CANCEL_ORDER("취소할 수 없는 주문입니다."),
    ONLY_USER_CAN_CANCEL("본인의 주문만 취소할 수 있습니다."),
    ORDER_NOT_FOUND("주문 내역이 존재하지 않습니다."),
    MINIMUM_ORDER_NOT_MET("최소 주문 금액 이상 주문해야 합니다."),
    NOT_BUSINESS_HOURS("현재 영업 시간이 아닙니다."),

    NOT_OWNER_ORDER("본인 가게 주문만 처리할 수 있습니다."),
    ALREADY_DELIVERING_OR_COMPLETED("이미 배달이 시작되었거나 완료된 주문입니다."),
    MUST_BE_ACCEPTED_BEFORE_COOKING("주문 접수 후에 조리를 시작할 수 있습니다."),
    MUST_BE_COOKING_BEFORE_DELIVERY("조리를 시작한 주문만 배달할 수 있습니다."),
    MUST_BE_DELIVERING_BEFORE_COMPLETE("배달중인 주문만 배달 완료 처리를 할 수 있습니다."),
    ALREADY_COMPLETED("이미 배달이 완료된 주문입니다.");

    private final String message;

    ErrorOrderMessage(String message) {
        this.message = message;
    }
}

타입 안정성 향상 : 사전에 정의된 상수들로만 구성되므로 유효한 값만 입력된다. 유효하지 않은 값이 들어오면 컴파일 오류가 발생한다.
간결성 및 일관성 : 코드가 더 간결해지고 명확해지며, 데이터 일관성이 보장된다.
확장성 : enum에 새로운 상수를 추가하기만 하면 간편하게 확장이 가능하다.

결론

검색해서도 혹은 튜터님께 질문을 해서도 조금씩 의견이 다른 부분이 있었지만, 대부분 타입 안정성과 확장성 측면에서 enum을 주로 선호하는 것 같았다.

결론 : 그냥 enum 쓰자.

[AWS] RDS 가볍게 시작해보기!

개발곰발 — Tue, 18 Mar 2025 16:57:13 +0900

스파르타코딩클럽 AWS의 모든 것 (All about AWS) 강의를 듣고 정리한 내용입니다.

RDS란?

Relational Database Service(RDS) : AWS에서 제공하는 관리형 관계형 데이터베이스 서비스. Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server 등 다양한 엔진을 선택할 수 있으며, EC2에 직접 DB를 설치·운영하는 방식보다 운영 부담이 적다.

RDS 특징

자동 인프라 구축 및 관리
- DB 설치, 패치, 유지보수 작업을 AWS가 수행한다.
자동 백업과 복구
- 지속적인 자동 백업 지원
- 지정한 기간 내 언제든 복구 가능
모니터링 지원
- 성능 모니터링과 대시보드 제공
확장성
- 스토리지 자동 확장 지원
보안성
- VPC, IAM, KMS로 데이터 보안 강화
SSH 접근 불가
- EC2처럼 SSH로 접근하지 않고 DB 툴 또는 애플리케이션에서 연결한다.

Storage Auto Scaling

DB 용량의 한계치까지 왔을 때 자동으로 용량을 늘려준다.
사용을 위해 Maximum Storage Threshold를 지정해줘야 한다.
예측 불가능한 트래픽이 있을때 유용하다.

RDS Read Replicas

읽기 전용 복제본으로 읽기 부하를 분산시킬 수 있다.
특징
- 비동기 복제로 운영된다.
- SELECT 쿼리만 가능하다.
- INSERT, UPDATE, DELETE는 불가능하다.
사용 사례
- 조회가 많은 서비스에서 성능 향상용으로 사용한다.

RDS Multi-AZ

고가용성 확보를 위한 기능으로, 장애 발생 시 자동으로 대기 인스턴스로 전환한다.
특징
- 수동 설정 없이 옵션 선택만으로 구성 가능하다.
- 가용성을 높이지만 확장성에는 영향을 주지 않는다.
- Read Replica 역시 Multi-AZ로 구성할 수 있다.
Failover 발생 시
- DNS가 자동으로 대기 인스턴스로 연결 전환한다.

RDS 시작하기

AWS에서 RDS를 검색해 들어간다. 바로 Create database를 눌러 데이터베이스를 만들어보자.

제일 먼저 Standard create와 Easy create 중에서 고르면 되는데, 나는 강의를 따라 하느라 Standard로 골랐다. 그래서인지 옵션이 아주 많았는데 상황에 따라 맞게 고르면 될 것 같다.

그 다음은 어떤 DB를 쓸건지 고르는데, 나는 MySQL로 했다.

Templates은 Free Tire로 했다. 개인 프로젝트라면 거의 Free Tire로 하면 될 것이다.

Settings에서는 내 DB 인스턴스 이름과 master username, password를 정한다.

Storage에서는 다음과 같이 설정했고, 만약 DB가 20GB에 가깝게 차면 autoscaling해서 1000GB까지 늘린다는 것이다.

만약 로컬에서 RDS에 접근하고자 한다면 Public access를 Yes로 해줘야 한다.

보안 그룹은 db-mysql-security라는 이름으로 새로 만들어줬다.

Database port가 3366으로 되어있는데, MySQL의 포트 번호가 3366이기 때문에 그대로 둔다. 포트 번호는 DB에 따라 바뀔 수 있다.

Initial database name을 정하고 꼭 기억해둬야 한다. 그리고 자동 백업을 켜고 Backup retention period을 7로 설정해 7일 동안 자동 백업을 가지고 있도록 설정했다.

다 만들고 조금 기다리면 Avaliable이 뜨면서 성공적으로 RDS가 만들어진 것을 볼 수 있다.

sqlectron 이용해 RDS 사용하기

먼저 아래 링크에서 sqlectron을 설치한다.
sqlectron 설치하기

아까 기억해둔 db name과 password를 적는다.

여기서 Server Address는 RDS에 들어가면 나오는 Endpoint를 복사해 넣으면 된다.

저장 후 Connect를 누르면 다음과 같이 뜬다. 이곳이 RDS에 있는 MySQL이다.

간단한 SQL문을 작성해 Excute하니 user 테이블이 만들어진 것을 볼 수 있다.

옆 user 테이블을 우클릭하면 다음과 같이 Insert, Update, Delete 등을 할 수 있다. 나는 Insert Statement를 눌러 데이터를 추가해봤다.

다음과 같이 데이터를 넣고 Excute를 눌렀다.

정상적으로 데이터가 들어간 모습을 확인할 수 있다.

RDS Monitoring에 들어와서 보면 변화가 생긴 것을 볼 수 있다.

Spring Security + JWT 사용하기

개발곰발 — Sat, 15 Mar 2025 00:10:08 +0900

Spring Security란?

스프링 시큐리티(Spring Security) : 스프링 기반 애플리케이션에 강력한 인증/인가 기능을 제공하는 보안 프레임워크.
Spring Security와 JWT를 함께 사용하면 Stateless하게 사용하기 때문에 간단하게 적용할 수 있다.
Security 보안을 통과하려면 SecurityContext에 AbstractAuthenticationToken을 set해줘야 한다!
SecurityContext : 한 요청 내에서 현재 인증된 사용자와 그 사용자가 가지는 권한을 알려주는 객체.
- 보통 하나의 Authentication 객체를 포함하며, 그 객체는 다음과 같은 것들을 가지고 있다.
  - 사용자(Principal)
  - 인증 방식
  - 인증 상태
  - 사용자 권한 목록(GrantedAuthorities)

잠시 코드로 살펴보면 아래와 같이 설정해주는 것을 의미한다.

// ... 중략

JwtAuthenticationToken authenticationToken = new JwtAuthenticationToken(authUser);
SecurityContextHolder.getContext().setAuthentication(authenticationToken);

여기서 AbstractAuthenticationToken이 없는데? 라고 생각할수 있는데, 다음과 같이 JwtAuthenticationToken이 AbstractAuthenticationToken을 상속받고 있다. 따라서 JwtAuthenticationToken은 인증 객체로 활용될 수 있다.

public class JwtAuthenticationToken extends AbstractAuthenticationToken {

    private final AuthUser authUser;

    public JwtAuthenticationToken(AuthUser authUser) {
        super(authUser.getAuthorities());
        this.authUser = authUser;
        setAuthenticated(true);
    }

    @Override
    public Object getCredentials() {
        return null;
    }

    @Override
    public Object getPrincipal() {
        return authUser;
    }
}

Spring Security 적용하기

기존 Filter와 Argument Resolver를 사용하던 코드들을 Spring Security로 변경하고자 한다.

SecurityConfig

Filter와 Argument Resolver를 각각 config에 등록했던 것처럼 SecurityConfig를 만든다.
SecurityConfig에 Filter를 등록한다.
기존에는 PasswordEncoder를 따로 만들어줘야 했지만, Spring Security에서는 기본적으로 BCryptPasswordEncoder를 제공해준다. 따라서 Bean으로 등록해 사용한다.

@Configuration
@RequiredArgsConstructor
@EnableWebSecurity
@EnableMethodSecurity(securedEnabled = true) // @Secured 권한 체크
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    @Bean
    public PasswordEncoder passwordEncoder() { // 기본 제공
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .csrf(AbstractHttpConfigurer::disable)
                .sessionManagement(session -> session
                        .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                )
                .addFilterBefore(jwtAuthenticationFilter, SecurityContextHolderAwareRequestFilter.class)
                .formLogin(AbstractHttpConfigurer::disable)
                .anonymous(AbstractHttpConfigurer::disable)
                .httpBasic(AbstractHttpConfigurer::disable)
                .logout(AbstractHttpConfigurer::disable)
                .rememberMe(AbstractHttpConfigurer::disable)
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers(request -> request.getRequestURI().startsWith("/auth")).permitAll()
                        .requestMatchers("/test").hasAuthority(UserRole.Authority.ADMIN)
                        .requestMatchers("/open").permitAll()
                        .anyRequest().authenticated()
                )
                .build();
    }
}

코드를 차근차근 살펴보자. 다음과 같이 설정하면 SpringContextPersistenceFilter에서 매 요청마다 빈 SecurityContext를 설정해준다. 따라서 불필요하게 빈 SecurityContext를 생성하지 않고 SecurityContextHolder.getContext()를 통해 SecurityContext를 그냥 불러오기만 하면 된다.

.sessionManagement(session -> 
        session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
)

다음 Filter들은 JWT를 사용하고 있는 지금은 필요없기 때문에 disable로 설정한다. 세션에서 활용되는 Filter이기 때문이다.

.formLogin(AbstractHttpConfigurer::disable) // 폼 기반 로그인
.anonymous(AbstractHttpConfigurer::disable) // 익명 사용자 권한
.httpBasic(AbstractHttpConfigurer::disable) // 커스텀 Filter - 사용해도 되지만 여기서는 JwtAuthenticationFilter를 쓴다.
.logout(AbstractHttpConfigurer::disable) // 세션 정보를 지우는 요청(로그아웃) 관련
.rememberMe(AbstractHttpConfigurer::disable)

다음은 요청에 대한 인증 및 권한을 설정하는 부분이다. 특정 URL 패턴에 대한 접근 제어를 정의하고, 나머지 요청은 인증된 사용자만 접근할 수 있도록 한다.

.authorizeHttpRequests(auth -> auth
        .requestMatchers(request -> request.getRequestURI().startsWith("/auth")).permitAll()
        .requestMatchers("/test").hasAuthority(UserRole.Authority.ADMIN)
        .requestMatchers("/open").permitAll()
        .anyRequest().authenticated()
)

모든 /auth로 시작하는 요청은 인증 없이 접근 가능하도록 설정.
/test 엔드포인트는 ADMIN 권한이 있는 사용자만 접근 가능하도록 설정.
/open 엔드포인트는 모든 사용자에게 공개해 인증 없이 접근 가능하도록 설정.
위에서 지정한 URL 패턴을 제외한 모든 요청은 인증된 사용자만 접근 가능하도록 설정. 즉, AbstractAuthenticationToken이 set되어 있어야 통과가 가능하다.

해당 어노테이션을 설정하면 클래스나 메서드에 @Secured 어노테이션을 적용하여 역할 기반 접근 제어(Role-Based Access Control)를 설정할 수 있다. 서비스 클래스에서 특정 역할만 접근 가능하도록 설정하고 여러 개의 역할을 지정할 수 있다. 이 내용은 밑에서 다룬다.

@EnableMethodSecurity(securedEnabled = true)

JwtAuthenticationFilter

FilterConfig에서는 Filter를 Bean으로 등록해주기 때문에 JwtFilter에서 따로 등록해줄 필요가 없다. 그러나 SecurityConfig에서는 Bean으로 등록해주지 않기 때문에 JwtAuthenticationFilter에서 @Component로 등록을 해줘야 한다.
기존 Filter와 거의 비슷하다.

@Slf4j
@Component // Component로 등록해줘야 한다!
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtUtil jwtUtil;

    @Override
    protected void doFilterInternal(
            HttpServletRequest httpRequest,
            @NonNull HttpServletResponse httpResponse,
            @NonNull FilterChain chain
    ) throws ServletException, IOException {
        String authorizationHeader = httpRequest.getHeader("Authorization");

        if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
            String jwt = jwtUtil.substringToken(authorizationHeader);
            try {
                Claims claims = jwtUtil.extractClaims(jwt);

                if (SecurityContextHolder.getContext().getAuthentication() == null) {
                    setAuthentication(claims);
                }
            } catch (SecurityException | MalformedJwtException e) {
                log.error("Invalid JWT signature, 유효하지 않는 JWT 서명 입니다.", e);
                httpResponse.sendError(HttpServletResponse.SC_UNAUTHORIZED, "유효하지 않는 JWT 서명입니다.");
            } catch (ExpiredJwtException e) {
                log.error("Expired JWT token, 만료된 JWT token 입니다.", e);
                httpResponse.sendError(HttpServletResponse.SC_UNAUTHORIZED, "만료된 JWT 토큰입니다.");
            } catch (UnsupportedJwtException e) {
                log.error("Unsupported JWT token, 지원되지 않는 JWT 토큰 입니다.", e);
                httpResponse.sendError(HttpServletResponse.SC_BAD_REQUEST, "지원되지 않는 JWT 토큰입니다.");
            } catch (Exception e) {
                log.error("Internal server error", e);
                httpResponse.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
            }
        }
        chain.doFilter(httpRequest, httpResponse);
    }

    private void setAuthentication(Claims claims) {
        Long userId = Long.valueOf(claims.getSubject());
        String email = claims.get("email", String.class);
        UserRole userRole = UserRole.of(claims.get("userRole", String.class));
        String nickName = claims.get("nickName", String.class);

        AuthUser authUser = new AuthUser(userId, email, userRole, nickName);
        JwtAuthenticationToken authenticationToken = new JwtAuthenticationToken(authUser);
        SecurityContextHolder.getContext().setAuthentication(authenticationToken);
    }
}

위에서 두 번이나 언급한 "SecurityContext에 AbstractAuthenticationToken을 set해주는 과정"이 바로 아래 코드다. JWT에서 사용자 정보를 추출한 후, Spring Security의 SecurityContext에 인증 정보를 저장한다.

private void setAuthentication(Claims claims) {
    Long userId = Long.valueOf(claims.getSubject());
    String email = claims.get("email", String.class);
    UserRole userRole = UserRole.of(claims.get("userRole", String.class));
    String nickName = claims.get("nickName", String.class);

    AuthUser authUser = new AuthUser(userId, email, userRole, nickName); // 인증된 사용자 정보 생성
    JwtAuthenticationToken authenticationToken = new JwtAuthenticationToken(authUser); // 인증 토큰 생성
    SecurityContextHolder.getContext().setAuthentication(authenticationToken); // SecurityContext에 토큰 저장, 인가 통과를 위해
}

JWT 인증이 통과되면 SecurityContextHolder에 Authentication이 저장되고, 컨트롤러에서 @AuthenticationPrincipal AuthUser authUser를 사용하면 AuthUser를 바로 가져올 수 있다.

JwtAuthenticationToken

AbstractAuthenticationToken을 상속받는 클래스로, Spring Security에서 JWT 기반 인증을 처리하기 위한 Authentication 객체다.
기존의 AuthuserArgumentResolver를 대체한다.
@Auth 대신 @AuthenticationPrincipal을 사용한다.

public class JwtAuthenticationToken extends AbstractAuthenticationToken {

    private final AuthUser authUser;

    public JwtAuthenticationToken(AuthUser authUser) {
        super(authUser.getAuthorities()); // Authentication 객체에 사용자 권한 저장
        this.authUser = authUser;
        setAuthenticated(true); // 인증 완료된 사용자로 표시
    }

    @Override
    public Object getCredentials() { // JWT 기반 인증에서는 비밀번호가 필요 없으므로 null 반환
        return null;
    }

    @Override
    public Object getPrincipal() {
        return authUser;
    }
}

@getPrincipal() 메서드로 컨트롤러 파라미터에서 @AuthenticationPrincipal을 이용해 어떤 인증 객체를 받을지 설정한다.

@Override
public Object getPrincipal() {
    return authUser;
}

UserRole

기존의 UserRole enum 클래스는 다음과 같다.

public enum UserRole {
    ADMIN, USER;

    public static UserRole of(String role) {
        return Arrays.stream(UserRole.values())
                .filter(r -> r.name().equalsIgnoreCase(role))
                .findFirst()
                .orElseThrow(() -> new InvalidRequestException("유효하지 않은 UerRole"));
    }
}

수정된 코드는 다음과 같다. Spring Security에서 제공하는 권한 기능을 사용하려면 반드시 prefix로 ROLE_을 붙여야 한다.
Authority 클래스는 ROLE_USER과 ROLE_ADMIN을 하드코딩하지 않고 UserRole.Authority.USER와 같이 사용할 수 있도록 정의하는 역할을 한다. @Secured 안에 enum을 바로 넣지 못하기 때문에 이런 클래스를 사용한다.

@Getter
@RequiredArgsConstructor
public enum UserRole {
    ROLE_USER(Authority.USER),
    ROLE_ADMIN(Authority.ADMIN);

    private final String userRole;

    public static UserRole of(String role) {
        return Arrays.stream(UserRole.values())
                .filter(r -> r.name().equalsIgnoreCase(role))
                .findFirst()
                .orElseThrow(() -> new IllegalArgumentException("유효하지 않은 UserRole"));
    }

    public static class Authority {
        public static final String USER = "ROLE_USER";
        public static final String ADMIN = "ROLE_ADMIN";
    }
}

다음은 @Secured 안에 enum을 넣었을 때 호환되지 않는 타입이라고 에러가 발생하는 모습이다.

AuthUser

기존의 AuthUser는 UserRole을 필드로 가지고 있었다.

@Getter
public class AuthUser {

    private final Long id;
    private final String email;
    private final UserRole userRole;
    private final String nickName;

    public AuthUser(Long id, String email, UserRole userRole, String nickName) {
        this.id = id;
        this.email = email;
        this.userRole = userRole;
        this.nickName = nickName;
    }
}

그러나 Spring Security에서는 다음과 같이 Collection 타입의 필드인 authorities로 대체되었다. 권한이 여러 개일 수도 있는 상황을 커버하기 위해 이런 타입으로 받는다.

@Getter
public class AuthUser {

    private final Long id;
    private final String email;
    private final String nickName;
    private final Collection<? extends GrantedAuthority> authorities;

    public AuthUser(Long id, String email, UserRole userRole, String nickName) {
        this.id = id;
        this.email = email;
        this.authorities = List.of(new SimpleGrantedAuthority(userRole.name()));
        this.nickName = nickName;
    }
}

@Secured 사용하기

@EnableMethodSecurity(securedEnabled = true)를 설정하면 @Secured를 사용할 수 있다. 그리고 다음과 같이 @Secured 어노테이션을 사용하면 이 API는 권한이 ADMIN인 사용자만 사용이 가능하다는 것을 직관적으로 알 수 있다.

@Secured(UserRole.Authority.ADMIN)
@PatchMapping("/admin/users/{userId}")
public void changeUserRole(
        @PathVariable long userId,
        @RequestBody UserRoleChangeRequest userRoleChangeRequest) {
    userAdminService.changeUserRole(userId, userRoleChangeRequest);
}

[Spring] Spring Security 도입 후 NullPointException 해결(@AuthenticationPrincipal)

개발곰발 — Fri, 14 Mar 2025 10:59:33 +0900

어제 Spring Security 도입을 마무리 하고, 다음 단계를 진행하다가 일정을 생성하는 부분에서 다음과 같이 NPE가 발생했다.

Postman에서는 403 Forbidden 에러가 난 상황이다.

회원가입과 로그인은 정상적으로 됐고, DB에도 모든 정보가 다 빠짐없이 들어있다.

왜 userRole이 null인가... DB에도 다 들어있는데 왜 null이지...?

이 상황을 믿을 수가 없어 생성자에서 userRole이 null일 때 에러를 던지도록 해 다시 한 번 확인해봤다.

null이 맞다. 그렇다면 왜일까?

검색의 늪에 빠져있다가 여러 상황을 가정하고 확인해보았다.

~~JwtUtil과 JwtAuthenticationFilter에서userRole을 다른 단어로 입력한 경우~~ → 둘 다 userRole로 같음.
~~DB에 저장되지 않은 경우~~ → 아주 잘 저장되어있음.
~~JWT 생성 시 userRole이 포함되지 않은 경우~~ → 이 부분은 원래 있던 코드라 그럴 리 없음.
AuthUser를 생성하는 부분에서 null이 들어가고 있는 것 같은데, AuthUser를 만들고 있는 부분을 찾아보자 → 이 흐름이 맞았음!

JwtAuthenticationFilter에서 setAuthentication()을 보면 다음과 같다. 여기서 해당 메서드는 JWT 토큰을 검증한 후, Spring Security의 SecurityContext에 인증된 사용자 정보를 저장하는 역할을 한다. 여기서 JwtAuthenticationToken 부분을 보면 Spring Security에서 사용할 Authentication 객체를 생성한다.

JwtAuthenticationToken 클래스로 가서 다시 한 번 살펴보니 사용자의 권한(userRole)을 설정하고, 인증된 사용자로 set한다. 그리고 맨 아래 getPrincipal() 메서드를 통해 현재 로그인한 사용자의 정보를 반환한다. 여기서 이 getPrincipal() 메서드를 사용하고 있지 않다는 것을 깨달았다.

따라서 나는 이 부분을 이용해야 한다는 생각이 들어 TodoController의 saveTodo() 메서드에서 @Auth 어노테이션을 주석 처리한 후, 직접 getPrincipal() 메서드를 불러 authUser에 넣고 테스트 해봤다.

드디어 제대로 일정이 생성되었다! 하지만 @Auth를 이용해 바꿔야 했는데, 이 부분에서 내가 어제 실수를 했다는 것을 알게되었다.

바로 파일 정리를 하다가 생각없이 AuthUserArgumentResolver와 WebConfig를 삭제해버린 것이다.... 이 부분은 삭제하지 말고 Spring Security로 변경했어야 했는데, 필요없다고 생각해서 지웠다. 차라리 지우지 않았더라면 더 빨리 해결할 수 있었을 텐데 말이다. 정확한 이해 없이 적용하려고만 해서 이런 일이 벌어진 것 같다.

따라서 다시 해당 파일을 만든 후, AuthUserArgumentResolver의 resolveArgument()메서드를 다음과 같이 수정했다. 이전에는 값을 request에서 하나씩 가져와 새로운 AuthUser 객체를 만들어 반환했다.

수정 후, 현재 인증된 사용자의 정보를 가져와서(SecurityContextHolder.getContext().getAuthentication()) Principal을 꺼내(getPrincipal()) AuthUser로 반환한다. 이렇게 반환된 AuthUser는 TodoController의 authUser 파라미터에 자동으로 들어간다.

따라서 기존과 같이 이렇게 적어줘도 이제 정상적으로 들어간다.

Postman에서도 잘 테스트 된다.

자, 이렇게 겨우겨우 에러를 해결했지만 이 방법을 아래 어노테이션 하나로 해결할 수 있었다.

@AuthenticationPrincipal

이렇게 바꾸면 바로 적용 가능하다.

...나 오늘 뭐한거지...? 팀원 분이 마지막 스크럼때 알려주셔서 알았다. 강의를 더 자세히 봐야한다는 교훈을 얻었다. 강의 다시 봐야지...

[Spring] application.yml에 시크릿 키 넣지 말아주세요...(.env 파일 만들고 설정하기)

개발곰발 — Mon, 10 Mar 2025 21:47:24 +0900

깃허브에 시크릿키를 올리는 것은 위험하다. 따라서 우린 시크릿키를 내 로컬 파일에만 따로 적어놓고 깃허브에는 올라가지 않도록 해야한다.

먼저 resource 패키지 아래에 .env 파일을 만들고 올라가면 안되는 정보를 넣어준다.

그리고 인텔리제이 오른쪽 상단에 있는 점 세개를 누른 후 Edit...에 들어간다.

현재 내가 이미 환경 변수를 설정해놓은 상태지만, Environment variables가 없다면 Build and Run 옆에 있는 Modify options를 누른다.

그럼 이렇게 옵션들을 추가할 수 있는데, Environment variables를 추가해준다.

이제 이 환경 변수 경로를 설정해야한다. 경로는 .env 파일이 있는 경로로 설정하면 된다. 그리고 .env 파일 역시 깃허브에 올라가면 안되므로 해당 파일을 gitignore에 추가한다.

그러면 application.yml 파일에 직접 민감한 정보를 넣을 필요 없이 환경 변수 설정을 할 수 있다.

프로젝트를 시작할 때 생각해볼 것들

개발곰발 — Sat, 8 Mar 2025 19:29:54 +0900

이번 프로젝트를 끝내고, 지난 프로젝트에서 아쉬웠던 점을 정리해봤다. ️
그런 점을 이번 프로젝트에서 꽤 많이 개선한 것 같고,
이번 프로젝트에서의 아쉬운 점 역시 다음 프로젝트에서 개선할 수 있다면 좋을 것 같다!

팀원들과 사소한 것 하나까지 공유하자

지난 프로젝트에서는 git에 익숙하지 않은 팀원분들이 많았다. 그래서인지 사실 내가 맡은 기능을 개발하는 시간보다 git 관련 문제를 해결하는데 더 많은 시간을 쓴 것 같다. 우리팀에서 일어난 문제는 다음과 같았다.

merge가 되면 develop에서 pull을 받은 후, 자신의 브랜치에서 작업을 해야한다. 그러나 중간에 확인해보니 팀원 모두가 pull을 받지 않고 작업을 하고 있다는 사실을 알았다. 자신의 브랜치에서는 자신이 맡은 기능만을 개발해야한다고 알고 있었던 것이다.
자신의 브랜치에서 develop 브랜치로 merge를 해야하는데, 다른 팀원이 실수로 main 브랜치로 PR을 한 후 합쳐버렸다. 이런 상황을 미리 막기 위해 아예 develop 브랜치를 default 브랜치로 정했어야 했는데 아쉬운 부분이다.
PR 제목 컨벤션이나 내용 템플릿을 정하지 않아 통일성이 없는 PR들이 생겨나서 신경쓰였다.
커밋 메세지가 깨져서 알아보기 힘든 경우가 많았다. 보통 터미널에서 커밋 메세지를 작성하면 그런 문제가 생기는 것 같다. 나는 주로 커밋 메세지는 인텔리제이가 제공하는 창을 이용해 적어서 몰랐다. 지금 찾아보니 인코딩 세팅을 변경 해주면 해결되는 것 같다.

내가 알고 있는 내용이더라도 다른 사람은 모를 수 있고, 혹은 다른 스타일을 가지고 있을 수 있기 때문에 정말 사소한 부분까지도 공유하고 이야기를 나눠보는 것이 중요하다고 느꼈다.

공통으로 사용되는 파일을 잘 관리하자

프로젝트 내에서 거의 모든 도메인에서 사용되는 예외 처리나 리소스 패키지 안에 있는 파일 등을 잘 관리해야겠다고 느꼈다. 같은 기능을 파일이 여러 개 올라오거나, 올라오지 말아야 할 파일이 올라왔기 때문이다. 특히 application.properties와 같은 설정 파일은 .env 파일을 만들어 환경 변수를 관리하는 작업이 필요하다. 또한 공용으로 사용되는 파일은 미리 global(혹은 common) 패키지를 만들어 한 사람이 작성해 올리도록 하는 게 낫지 않을까 싶다.

commit & code convention을 자세히 정해놓자

간단한 커밋 컨벤션만 정하고 프로젝트에 들어갔기 때문에 통일성이 없는 부분이 상당히 많았다. 이건 발표 때 튜터님이 다른 팀에 지적한 내용인데, 우리팀에도 해당된다고 생각했다. 미리 파일명, 메서드명, 변수명 컨벤션을 정하고 시작했다면 좋았을 것 같다. 예를들어 어떤 조회 메서드의 이름을 findXXX(), getXXX() 둘 중 어떤 것을 쓸지, 각 엔티티에서 변수명은 어떤 식으로 쓸지 등을 정해놓으면 좋을 것 같다.

주석은 필요한 내용만 적자

아주 긴 주석을 마주하면 읽을 용기가 없어진다. 내가 생각하는 좋은 코드는 주석 없이도 잘 이해되는 코드지만, 주석을 달아야 한다면 정말 필요한 부분 한 두줄만 있으면 될 것 같다.

코드 리뷰를 하자

남이 쓴 코드를 읽는 건 정말 피곤한 일이다. 하지만 코드를 읽고, 이해하고, 잘못된 점이 있는지 검토하고, 리뷰를 달기 전 내가 알고 있는 지식이 맞는지 다시 한 번 검색하는 작업은 나를 더 성장시킨다. 지난 프로젝트에서 코드 리뷰를 하고 싶었지만 시간에 쫓기듯 개발해서 하지 못했다. 하지만 코드 리뷰를 했다면 다들 더 좋은 코드를 작성할 수 있는 힘을 기를 수 있지 않았을까? 이번 프로젝트에서 코드 리뷰를 하면서 코드 리뷰의 중요성을 다시 한 번 깨달았다. 그리고 스스로 실력이 부족하다는 생각에 코드리뷰를 잘 하지 않는 경우가 있는데, 오히려 다른 사람들의 코드를 보먀 왜 이렇게 짰는지 의견을 나눠보고 새로 알게 된 점을 따로 공부해보면 더 실력이 좋아질 것이다.

튜터님께 자세히 피드백 받자

여기서 말하는 자세한 피드백은 코드 리뷰를 말한다. API URL이나 진행 상황에 대한 피드백 이외에 핵심 기능에 대한 코드 리뷰를 받았다면 좋았을 것 같다. 이 부분은 이번 프로젝트 후 느낀 점이다. 이번 프로젝트에서 튜터님의 상세한 코드 리뷰를 듣고 어떤 방향으로 리팩토링 해볼 수 있을지에 대한 힌트를 얻었기 때문이다.

[Spring] enum abstract method로 중복을 해결해보자

개발곰발 — Fri, 7 Mar 2025 21:22:48 +0900

이번 심화 프로젝트를 진행하면서, 주문 상태가 늘어날수록 API와 로직이 같이 늘어나는 구조의 한계를 마주했다.
어떻게 개선했는지, 그리고 이 과정에서 배운 점을 정리해본다.

️ 변경 전 코드

우선 OwnerOrderController는 가게 사장님이 들어온 주문을 수락 및 거절하는 API를 가지고 있다. 수락이 되었다면 음식조리중, 배달중, 배달완료 순으로 흐를 수 있도록 해야한다. 다음 코드를 보면, 각각의 상태에 따라 API가 다 따로 만들어져있다. 처음에는 상태가 되돌아 갈 수 없도록 하는 것에만 집중해서 예외 처리만 하고 끝냈다.

@RestController
@RequiredArgsConstructor
@RequestMapping("/api")
public class OwnerOrderController {

    private final OwnerOrderService ownerOrderService;

    @Order
    @PatchMapping("/v1/orders/{orderId}/accept")
    public ResponseEntity<OrderStatusResponseDto> acceptOrder(
            @Auth AuthUser owner,
            @PathVariable Long orderId
    ) {
        return ResponseEntity.ok(ownerOrderService.acceptOrder(owner.getId(), orderId));
    }

    @Order
    @PatchMapping("/v1/orders/{orderId}/reject")
    public ResponseEntity<OrderStatusResponseDto> rejectOrder(
            @Auth AuthUser owner,
            @PathVariable Long orderId
    ) {
        return ResponseEntity.ok(ownerOrderService.rejectOrder(owner.getId(), orderId));
    }

    @Order
    @PatchMapping("/v1/orders/{orderId}/cook")
    public ResponseEntity<OrderStatusResponseDto> startCooking(
            @Auth AuthUser owner,
            @PathVariable Long orderId
    ) {
        return ResponseEntity.ok(ownerOrderService.startCooking(owner.getId(), orderId));
    }

    @Order
    @PatchMapping("/v1/orders/{orderId}/deliver")
    public ResponseEntity<OrderStatusResponseDto> startDelivery(
            @Auth AuthUser owner,
            @PathVariable Long orderId
    ) {
        return ResponseEntity.ok(ownerOrderService.startDelivery(owner.getId(), orderId));
    }

    @Order
    @PatchMapping("/v1/orders/{orderId}/complete")
    public ResponseEntity<OrderStatusResponseDto> completeDelivery(
            @Auth AuthUser owner,
            @PathVariable Long orderId
    ) {
        return ResponseEntity.ok(ownerOrderService.completeDelivery(owner.getId(), orderId));
    }
}

이런 경우는 문제점이 있다.

만약, API가 점점 늘어나서 몇 백개, 몇 만개가 된다면?

물론 주문하고 배달하기까지의 과정이 그렇게까지 많은 상태로 쪼개지긴 힘들겠지만, 어떤 상태가 추가된다면 또 새로운 API를 추가해야한다. 그리고 다음과 같이 상태 하나하나 따로 호출하게 된다.

음...

PATCH api/v1/orders/1/reject

PATCH api/v1/orders/1/cook

PATCH api/v1/orders/1/deliver

...이렇게 API URL만 적다가 끝나버릴수도...

그리고 OwnerOrderService를 보면 한 눈에 봐도 중복되는 코드가 아주 많다는 것을 볼 수 있다. 중복되는 코드가 눈에 보이면 빠르게 하나로 합칠 수 있다.

@Service
@RequiredArgsConstructor
public class OwnerOrderService {

    private final UserOrderService userOrderService;

    @Transactional
    public OrderStatusResponseDto acceptOrder(Long ownerId, Long orderId) {
        UserOrderEntity order = userOrderService.getOrderById(orderId);

        if (!Objects.equals(ownerId, order.getStore().getUser().getId())) {
            throw new InvalidRequestException(ErrorOrderMessage.NOT_OWNER_ORDER.getMessage());
        }

        if (!OrderStatus.PENDING.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.CANNOT_CANCEL_ORDER.getMessage());
        }

        order.updateOrderStatus(OrderStatus.ACCEPTED);

        return OrderStatusResponseDto.from(order);
    }

    @Transactional
    public OrderStatusResponseDto rejectOrder(Long ownerId, Long orderId) {
        UserOrderEntity order = userOrderService.getOrderById(orderId);

        if (!Objects.equals(ownerId, order.getStore().getUser().getId())) {
            throw new InvalidRequestException(ErrorOrderMessage.NOT_OWNER_ORDER.getMessage());
        }

        if (!OrderStatus.PENDING.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.CANNOT_CANCEL_ORDER.getMessage());
        }

        order.updateOrderStatus(OrderStatus.REJECTED);

        return OrderStatusResponseDto.from(order);
    }

    @Transactional
    public OrderStatusResponseDto startCooking(Long ownerId, Long orderId) {
        UserOrderEntity order = userOrderService.getOrderById(orderId);

        if (!Objects.equals(ownerId, order.getStore().getUser().getId())) {
            throw new InvalidRequestException(ErrorOrderMessage.NOT_OWNER_ORDER.getMessage());
        }

        if (OrderStatus.DELIVERING.equals(order.getOrderStatus())
        || OrderStatus.COMPLETED.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.ALREADY_DELIVERING_OR_COMPLETED.getMessage());
        }

        if (!OrderStatus.ACCEPTED.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.MUST_BE_ACCEPTED_BEFORE_COOKING.getMessage());
        }

        order.updateOrderStatus(OrderStatus.COOKING);

        return OrderStatusResponseDto.from(order);
    }

    @Transactional
    public OrderStatusResponseDto startDelivery(Long ownerId, Long orderId) {
        UserOrderEntity order = userOrderService.getOrderById(orderId);

        if (!ObjectUtils.nullSafeEquals(ownerId, order.getStore().getUser().getId())) {
            throw new InvalidRequestException(ErrorOrderMessage.NOT_OWNER_ORDER.getMessage());
        }

        if (OrderStatus.DELIVERING.equals(order.getOrderStatus())
                || OrderStatus.COMPLETED.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.ALREADY_DELIVERING_OR_COMPLETED.getMessage());
        }

        if (!OrderStatus.COOKING.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.MUST_BE_COOKING_BEFORE_DELIVERY.getMessage());
        }

        order.updateOrderStatus(OrderStatus.DELIVERING);

        return OrderStatusResponseDto.from(order);
    }

    @Transactional
    public OrderStatusResponseDto completeDelivery(Long ownerId, Long orderId) {
        UserOrderEntity order = userOrderService.getOrderById(orderId);

        if (!ObjectUtils.nullSafeEquals(ownerId, order.getStore().getUser().getId())) {
            throw new InvalidRequestException(ErrorOrderMessage.NOT_OWNER_ORDER.getMessage());
        }

        if (OrderStatus.COMPLETED.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.ALREADY_COMPLETED.getMessage());
        }

        if (!OrderStatus.DELIVERING.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.MUST_BE_DELIVERING_BEFORE_COMPLETE.getMessage());
        }

        order.updateOrderStatus(OrderStatus.COMPLETED);

        return OrderStatusResponseDto.from(order);
    }

}

다시 보니 다음과 같은 부분들이 반복되고 있었다.

▪️유저 아이디를 검증하는 코드

▪️ 현재 들어온 상태 변경을 하기에 적절한 상태인지 확인하는 코드

▪️order.updateOrderStatus()로 주문 상태를 변경하는 코드

▪️ OrderStatusResponseDto을 반환하는 코드

변경 전에는 다음과 같이 enum 클래스에서 상태명만 가져와 사용하고 있다.

@Getter
@RequiredArgsConstructor
public enum OrderStatus {

    PENDING("주문 확인전"),
    CANCELED("주문 취소"),
    ACCEPTED("주문 접수"),
    REJECTED("주문 거절"),
    COOKING("조리중"),
    DELIVERING("배달중"),
    COMPLETED("배달 완료");

    private final String description;

}

이제 리팩토링을 해보자!

✨ 리팩토링한 코드

튜터님의 피드백을 정리해보면 다음과 같다.

✔️ 중복되는 코드가 너무 많다.

✔️ 상태가 추가되면 API를 계속 추가해야하고, 관리가 어려워진다는 문제가 생긴다. 주문 상태를 파라미터마다 받는 것은 어떨까?

✔️ 각 상태마다 switch문으로 분기할 수 있을 것이다.

✔️ 각 상태별 예외처리를 메서드로 분리해 주문 상태에 따른 처리 로직만 남기면 코드를 간소화할 수 있다.

✔️ 현재 enum 클래스로 상태를 관리하고 있으므로, enum 내에 추상 메서드를 이용해 그 안에서 예외처리를 해볼 수도 있다.

먼저, 주문상태를 @RequestParam으로 받도록 변경했다. 다음과 같이 단 하나의 API만 남기고 모두 지웠다.

@RestController
@RequiredArgsConstructor
@RequestMapping("/api")
public class OwnerOrderController {

    private final OwnerOrderService ownerOrderService;

    @Order
    @PatchMapping("/v1/orders/{orderId}")
    public ResponseEntity<OrderStatusResponseDto> order(
            @Auth AuthUser owner,
            @PathVariable Long orderId,
            @RequestParam String status
    ) {
        return ResponseEntity.ok(ownerOrderService.order(owner.getId(), orderId, status));
    }

}

그러면 다음과 같이 호출할 수 있다. 주문 상태에 따라 status 값만 바꿔주면 된다.

PATCH /api/v1/orders/1?status=ACCEPTED

이제 이거 하나만 있으면 된다..!

그 다음 OwnerOrderService로 가보면 이전과 달리 아주 심플해진 코드를 볼 수 있다.

✔️ 사용자를 검증하는 코드를 private 메서드로 분리해 order() 메서드 내에서는 validateOwner() 한 줄로 적었다.

✔️ OrderStatus enum 클래스 내부에 추상 메서드 update()를 선언해 역시 OrderStatus.valueOf(status).update(order); 한 줄로 적었다.

@Service
@RequiredArgsConstructor
public class OwnerOrderService {

    private final UserOrderService userOrderService;

    @Transactional
    public OrderStatusResponseDto order(Long ownerId, Long orderId, String status) {
        UserOrderEntity order = userOrderService.getOrderById(orderId);
        validateOwner(ownerId, order);
        OrderStatus.valueOf(status).update(order);

        return OrderStatusResponseDto.from(order);
    }

    private void validateOwner(Long ownerId, UserOrderEntity order) {
        if (!Objects.equals(ownerId, order.getStore().getUser().getId())) {
            throw new InvalidRequestException(ErrorOrderMessage.NOT_OWNER_ORDER.getMessage());
        }
    }

}

그러면 이제 변경사항이 생겨도 사실상 Controller와 Service 쪽은 건드릴 필요가 없다. OrderStatus 클래스에 각 상태에 따른 예외 처리를 넣어놨기 때문이다. 중복이 되는 부분은 따로 빼서 메서드로 만들고, order를 받아 조건이 맞으면 해당 order의 상태를 수정하는 방식이다.

@Getter
@RequiredArgsConstructor
public enum OrderStatus {

    PENDING("주문 확인전") {
        @Override
        public void update(UserOrderEntity order) {

        }
    },
    CANCELED("주문 취소") {
        @Override
        public void update(UserOrderEntity order) {
            validateOrderCancelable(order);
        }
    },
    ACCEPTED("주문 접수") {
        @Override
        public void update(UserOrderEntity order) {
            validateOrderCancelable(order);
            order.updateOrderStatus(OrderStatus.ACCEPTED);
        }
    },
    REJECTED("주문 거절") {
        @Override
        public void update(UserOrderEntity order) {
            validateOrderCancelable(order);
            order.updateOrderStatus(OrderStatus.REJECTED);
        }
    },
    COOKING("조리중") {
        @Override
        public void update(UserOrderEntity order) {
            validateNotDeliveringOrCompleted(order);
            if (!OrderStatus.ACCEPTED.equals(order.getOrderStatus())) {
                throw new InvalidRequestException(ErrorOrderMessage.MUST_BE_ACCEPTED_BEFORE_COOKING.getMessage());
            }
            order.updateOrderStatus(OrderStatus.COOKING);
        }
    },
    DELIVERING("배달중") {
        @Override
        public void update(UserOrderEntity order) {
            validateNotDeliveringOrCompleted(order);
            if (!OrderStatus.COOKING.equals(order.getOrderStatus())) {
                throw new InvalidRequestException(ErrorOrderMessage.MUST_BE_COOKING_BEFORE_DELIVERY.getMessage());
            }
            order.updateOrderStatus(OrderStatus.DELIVERING);
        }
    },
    COMPLETED("배달 완료") {
        @Override
        public void update(UserOrderEntity order) {
            if (!OrderStatus.DELIVERING.equals(order.getOrderStatus())) {
                throw new InvalidRequestException(ErrorOrderMessage.MUST_BE_DELIVERING_BEFORE_COMPLETE.getMessage());
            }
            order.updateOrderStatus(OrderStatus.COMPLETED);
        }
    };

    private final String description;

    abstract public void update(UserOrderEntity order);

    private static void validateOrderCancelable(UserOrderEntity order) {
        if (!OrderStatus.PENDING.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.CANNOT_CANCEL_ORDER.getMessage());
        }
    }

    private static void validateNotDeliveringOrCompleted(UserOrderEntity order) {
        if (OrderStatus.DELIVERING.equals(order.getOrderStatus())
                || OrderStatus.COMPLETED.equals(order.getOrderStatus())) {
            throw new InvalidRequestException(ErrorOrderMessage.ALREADY_DELIVERING_OR_COMPLETED.getMessage());
        }
    }
}

이렇게 리팩토링을 진행한 뒤, Controller는 API 5개에서 1개로, Service의 중복 로직도 enum 내부로 분리되어 코드가 훨씬 간결해졌다. 이 과정을 통해 중복 코드에 대한 경각심을 다시 한 번 일깨웠고, enum 클래스에서 abstract 메서드를 사용하는 방법에 대해 학습했다.

[Spring] JWT 시크릿 키 설정 및 문제 해결 / -hex 64 vs -base64 32 차이

개발곰발 — Thu, 27 Feb 2025 19:23:10 +0900

Main 실행 시 에러 발생

처음 프로젝트를 받아 실행하니 다음과 같은 에러가 나왔다.

에러 메세지가 길긴 하지만 잘 읽어보면 JWT 시크릿 키에 대한 문제인 것을 짐작할 수 있다. application.properties 파일에 키를 넣으려고 했는데, 아예 resourse 폴더가 없었다. 따라서 먼저 키를 만들어야 했다.

java.lang.IllegalArgumentException: Could not resolve placeholder 'jwt.secret.key' in value "${jwt.secret.key}"

org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'jwtUtil': Injection of autowired dependencies failed

Unsatisfied dependency expressed through constructor parameter 0: 
Error creating bean with name 'jwtUtil': Injection of autowired dependencies failed

터미널에 아래와 같이 입력해 키를 만들었다. 키를 처음 만들어 보지만 검색하니 만드는 방법이 바로 나왔다. 터미널로 만드는 방법 외에도 키를 만드는 사이트를 활용하는 방법도 있었다.

openssl rand -hex 64

결과는 다음과 같이 아주 긴 시크릿 키가 나왔다.

22b8c9ae9a1b397ef0c8a2d142f91d1d00b7c0dc0dae01d2999d197f111f3e01c15a4477f63732fa2aa6fe8fbf313874b681fa31cef4049aa50707b7f8156

그리고 resourse 폴더를 생성 후, application.properties 파일을 만들고 다음과 같이 키를 넣었다.

jwt.secret.key="JWT_시크릿_키"

여기서 중요한 점은 JwtUtil 클래스에서 ${jwt.secret.key} 로 적었다면, jwt.secret.key 로 똑같이 적어야 한다는 점이다.

그런데 또 에러가 났다. 왜일까? 잘 살펴보니 새로운 에러가 등장했다.

java.lang.IllegalArgumentException: Illegal base64 character 22

해당 에러에 대한 내용을 검색하다가 JWT를 사용한 다른 사람의 스크린샷을 보고 나의 실수를 알아차렸다. 바로 쌍따옴표로 키를 감싼 것이다.

이렇게 작성하지 말고,

jwt.secret.key="JWT_시크릿_키"

이렇게 쌍따옴표 없이 작성해야 한다. 제대로 고친 후 실행하니 정상적으로 작동했다.

jwt.secret.key=JWT_시크릿_키

+) 추가 공부

처음에는 시크릿 키 값을 바꾼 것 때문에 정상 작동하는 줄 알았지만 아니었다. 키 값이 문제는 아니었지만, 내가 위에서 만든 키 값은 현재 프로젝트에서 사용하고 있는 알고리즘에 적합하지 않다는 것을 알게 되었다.

현재 프로젝트에서 적용한 알고리즘은 HS256 알고리즘이다.

private final SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;

사용하는 알고리즘에 따라 키를 다르게 생성해야 한다. 내가 위에서 키를 생성하기 위해 사용한 openssl rand -hex 64 는 HS512(512비트) 알고리즘을 사용할 때 적합하다.

따라서 다음과 같이 조금 다른 명령어를 gitbash에 치니 더 짧은 키가 나왔다.

openssl rand -base64 32

결과를 보니 확실히 위에서 얻은 키와 다르다.

7yD9Da2chXAX5qCI2WrIzdiIifDZI8WPtcqJ+rjUJRA=

-hex 64 vs -base64 32 차이

1) -hex 64 (HEX)

HS512(512비트) 알고리즘을 사용할 때 적합
다만, HEX 문자열은 Base64와 다르게 바로 Secret Key로 사용하려면 바이트 변환이 필요함
예제 변환 코드

    byte[] keyBytes = new BigInteger(secretKey, 16).toByteArray();

2) -base64 32 (Base64)

HS256(256비트) 알고리즘을 사용할 때 적합
Base64.getDecoder().decode(secretKey)를 통해 바로 바이트 배열로 변환 가능
Keys.hmacShaKeyFor(Base64.getDecoder().decode(secretKey))와 같은 방식으로 사용 가능

그런데, openssl rand -hex 64 를 이용해 생성한 키도 정상적으로 돌아가서 의문이 들었다. HS256 알고리즘에 적합한 키는 openssl rand -base64 32 로 생성한 키라고 했는데, 왜 정상적으로 작동하는 걸까? 이 부분은 GPT에게 물어봤다.

그 이유는 Spring Security 및 JJWT 라이브러리에서 내부적으로 HEX 문자열을 바이트 배열로 변환하여 처리하기 때문이라고 한다.

JJWT (Java JWT, JSON Web Token for Java) : Java 기반의 JWT(Json Web Token) 생성 및 검증을 위한 라이브러리로, JWT를 쉽게 다룰 수 있도록 도와준다.

JJWT에서 Keys.hmacShaKeyFor() 메서드는 다음과 같이 동작한다. byte[] keyBytes를 입력 받아 SecretKey 객체로 변환하는데, 여기서 입력값이 256비트보다 길면 자동으로 적절한 길이로 잘라서 사용한다.

public static SecretKey hmacShaKeyFor(byte[] keyBytes) {
    return new SecretKeySpec(keyBytes, SignatureAlgorithm.HS256.getJcaName());
}

따라서, 키가 길어도 문제가 발생하지 않는다. 하지만 불필요하게 긴 값을 사용하기보단 Base64 키를 사용해 변환 과정을 없애는 것이 더 효율적일 것이다.

[Spring] @EntityGraph로 N+1문제 해결하기

개발곰발 — Wed, 26 Feb 2025 00:14:37 +0900

다음 getTodos() 메서드에서 발생하고 있는 N+1 문제를 @EntityGraph를 사용해 해결해야 한다.

public Page<TodoResponse> getTodos(int page, int size) {
    Pageable pageable = PageRequest.of(page - 1, size);

    Page<Todo> todos = todoRepository.findAllByOrderByModifiedAtDesc(pageable);

    return todos.map(todo -> new TodoResponse(
            todo.getId(),
            todo.getTitle(),
            todo.getContents(),
            todo.getWeather(),
            new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()),
            todo.getCreatedAt(),
            todo.getModifiedAt()
    ));
}

위 코드에서 할일을 모두 불러온 후, 그 아래 유저를 또 다시 불러오는 과정에서 N+1 문제가 발생할 가능성이 높아보인다.

Todo 엔티티의 일부를 살펴보면 User와 @ManyToOne 다대일 연관관계를 맺고 있고, 지연 로딩(FetchType.LAZY)으로 설정되어 있다. 지연 로딩으로 설정하면 Todo를 조회할 때 User를 바로 가져오는 것이 아니라 프록시 객체로 있다가 실제 사용될 때 SELECT 쿼리가 실행되는 것이다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id", nullable = false)
private User user;

먼저 findAllByOrderByModifiedAtDesc() 메서드를 통해 다음과 같이 모든 todo를 불러오고 있다.

Page<Todo> todos = todoRepository.findAllByOrderByModifiedAtDesc(pageable);

이때 다음과 같은 쿼리가 실행될 것이다.

SELECT * FROM todo ORDER BY modified_at DESC LIMIT ?, ?

그리고 다음 코드에서 todo.getUser()를 하면 User에 대한 SELECT 추가 쿼리가 실행된다. 즉 todo가 100개라면 위에서 1개의 쿼리를 실행하고, 아래에서 100개의 쿼리가 또 발생하게 되는 것이다.

todos.map(todo -> new TodoResponse(
        todo.getId(),
        todo.getTitle(),
        todo.getContents(),
        todo.getWeather(),
        new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()), // N+1 문제 발생 가능
        todo.getCreatedAt(),
        todo.getModifiedAt()
));

Repository에서는 이미 다음과 같이 fetch join을 사용해 N+1 문제를 해결했다.

@Query("SELECT t FROM Todo t LEFT JOIN FETCH t.user u ORDER BY t.modifiedAt DESC")
Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

여기서 @EntityGraph라는 어노테이션을 활용해 해결해보자. @EntityGraph(attributePaths = {"user"})와 같이 적어주면 User도 함께 조회하도록 설정할 수 있다.

@EntityGraph(attributePaths = {"user"})
Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

+) N+1 문제 눈으로 확인하기

오늘 팀원분께서 N+1 문제를 해결하지 않았을 때의 결과와 해결했을 때의 결과를 직접 보여주셨다. 그래서 나도 따라서 테스트 해보니 훨씬 이해가 잘됐다. 미리 유저 2명을 생성하고, 일정도 각 유저마다 1개씩 만들어 테스트 했더니 다음과 같은 결과가 나왔다.

@EntityGraph 적용 전(왼) / @EntityGraph 적용 후(오)

N+1 문제를 해결하기 전에는 일정을 조회하고, 각 유저마다 한 번씩 더 조회하고 있다. 유저의 수(2명)만큼 쿼리가 실행된 것이다. N+1 문제를 해결한 후에는 유저를 추가로 조회하는 것 없이 쿼리가 한 번만 실행되는 것을 볼 수 있다.

[Spring] Spring에서 세션을 다루는 3가지 방법, 뭐가 제일 좋을까?

개발곰발 — Sat, 22 Feb 2025 14:00:58 +0900

튜터님의 해설 강의를 듣고 일정 관리 앱 과제를 리뷰하다가 알게 된 내용을 간단하게 포스팅 해본다. 이번 일정 관리 앱 과제에서 튜터님의 코드와 비교했을때, 가장 큰 차이 중 하나는 세션을 사용하는 방식이었다. 나는 HttpSession을 직접 가져와 사용하는 방식을 사용했다. 반면 튜터님은 @SessionAttribute 어노테이션을 사용하여 세션 속성을 자동 주입하는 방식을 사용하셨고, 그 방법이 더 쉽게 세션을 사용할 수 있는 것 같다.

세션을 사용하는 방식

HttpSession 사용하기

내가 작성한 댓글 생성 기능 부분이다. HttpServletRequest에서 HttpSession을 가져와 세션키를 사용하고 있다. 이 방법은 Servlet API에서 제공하는 기본적인 세션 관리 방식으로, 직접 HttpSession 객체를 사용하여 값을 저장하고 가져온다.

@PostMapping("/schedules/{scheduleId}/comments")
public ResponseEntity<CommentResponseDto> save(
    @PathVariable Long scheduleId,
    @Valid @RequestBody CommentRequestDto dto,
    HttpServletRequest request
) {
    HttpSession session = request.getSession(false);
    String sessionKey = (String) session.getAttribute("sessionKey");

    CommentResponseDto commentResponseDto = commentService.save(scheduleId, sessionKey, dto);
    return new ResponseEntity<>(commentResponseDto, HttpStatus.CREATED);
}

이 경우 한 눈에 보기에도 코드가 길어 간결해보이지 않는다는 단점이 있고, 만약 세션이 없을 경우 NullpointerException이 발생할 가능성이 있다. 또한 session.getAttribute()를 호출할 때 형 변환이 필요하다.

실제로 코드를 짜면서 아래 코드가 굉장히 많이 반복되어서 찝찝했는데 시간이 없어서 그냥 제출했다. 리뷰를 하면서 해당 코드가 있는 부분을 고치는데 너무 많아서 힘들었다.

HttpSession session = request.getSession(false);
String sessionKey = (String) session.getAttribute("sessionKey");

@SessionAttribute 사용하기

위 코드는 @SesstionAttribute 어노테이션을 사용해 더 간결하게 바꿀 수 있다. @SessionAttribute는 특정 값을 컨트롤러 메서드에서 세션 속성으로 직접 매핑한다. 자동으로 세션값을 주입해 주기 때문에 불필요한 코드가 사라진다.

@PostMapping("/schedules/{scheduleId}/comments")
public ResponseEntity<CommentResponseDto> save(
    @SessionAttribute(name = "LOGIN_USER") Long userId,
    @PathVariable Long scheduleId,
    @RequestBody CommentSaveRequestDto dto
) {
    return ResponseEntity.ok(commentService.save(userId, scheduleId, dto));
}

이 경우에는 첫 번째 방법보다 코드도 짧고 유지보수하기 쉽다. 세션을 가져오고, 속성을 읽은 후 형 변환까지 해야하는 과정 없이 바로 세션값을 사용할 수 있다.

HandlerMethodArgumentResolver 사용하기

세션을 사용하는 방법이 더 있는지 찾아보다가 발견한 방식이다. HandlerMethodArgumentResolver를 구현하여, 특정 세션 값을 자동으로 컨트롤러 매개변수로 주입하는 방식이다. 컨트롤러에서 매번 @SessionAttribute나 HttpSession을 호출할 필요 없이, 자동으로 특정 객체를 주입받을 수 있도록 설정할 수 있다. 세션을 가져오는 로직을 전역적으로 한 곳에서 관리할 수 있기 때문에 더 깔끔하고 유지보수가 쉽다. 사용하는 방법은 다음과 같다.

1) @LoginUser 어노테이션 생성
먼저 LoginUser라는 커스텀 어노테이션을 만든다.

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface LoginUser {
}

@Target(ElementType.PARAMETER) : 메서드의 파라미터에만 사용할 수 있도록 제한
@Retention(RetentionPolicy.RUNTIME) : 런타임에도 어노테이션이 유지되어 ArgumentResolver에서 인식할 수 있도록 설정
- RetentionPolicy.SOURCE: 소스 코드에서만 유지
- RetentionPolicy.CLASS: 클래스 파일에만 유지
- RetentionPolicy.RUNTIME: 런타임 시에도 유지

2) HandlerMethodArgumentResolver 구현
@LoginUser를 사용하면 자동으로 세션에서 값을 가져오도록 HandlerMethodArgumentResolver를 구현한다.

@Component
public class LoginUserArgumentResolver implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        // @LoginUser 애노테이션이 있고, Long 타입일 때만 적용
        return parameter.getParameterAnnotation(LoginUser.class) != null
                && parameter.getParameterType().equals(Long.class);
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
                                  NativeWebRequest webRequest, WebDataBinderFactory binderFactory) {
        // 요청 객체 및 세션 가져오기
        HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest();
        HttpSession session = request.getSession(false);

        if (session == null) {
            throw new RuntimeException("세션이 존재하지 않습니다.");
        }

        return userId;
    }
}

3) WebConfig에 등록
addArgumentResolvers()에서 위에서 만든 LoginUserArgumentResolver를 SPring의 ArgumentResolver 목록에 추가한다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
    private final LoginUserArgumentResolver loginUserArgumentResolver;

    public WebConfig(LoginUserArgumentResolver loginUserArgumentResolver) {
        this.loginUserArgumentResolver = loginUserArgumentResolver;
    }

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(loginUserArgumentResolver);
    }
}

이렇게 하면 컨트롤러에서 @LoginUser 어노테이션을 사용할 수 있다.

4) 컨트롤러에서 @LoginUser 사용
이제 다음과 같이 @LoginUser만 붙이면 세션값을 가져올 수 있다. 아마 제일 간결한 방식이지 않을까 싶다.

@PostMapping("/schedules/{scheduleId}/comments")
public ResponseEntity<CommentResponseDto> save(
        @LoginUser Long userId,  // 세션에서 자동으로 userId를 주입
        @PathVariable Long scheduleId,
        @RequestBody CommentSaveRequestDto dto
) {
    return ResponseEntity.ok(commentService.save(userId, scheduleId, dto));
}

그 외...

Spring Security : 세션 대신 SecurityContext에 사용자 정보 저장 가능
Spring Session : 서버 메모리가 아닌 Redis, JDBC, Hazelcast 같은 저장소에 세션 저장 가능
실무에서는 Spring Session + Redis를 많이 사용한다고 한다.(GPT가 한 말이라 100% 신뢰할 순 없지만...)

실무에서 세션을 사용하는 방식은 나중에 더 많은 것을 배우고 나서 다시 공부해보면 좋을 것 같다.

[Spring] Converter와 Fomatter 사용하기

개발곰발 — Fri, 21 Feb 2025 23:58:48 +0900

Converter 사용하기

Spring은 기본적인 컨버터를 제공하지만, 컨버터를 커스텀하게 구현할 수도 있다. 예를 들면, String 값을 특정 객체를 변환하고 싶다면 커스텀 컨버터를 구현해야 한다.

강의 실습을 따라 String 값을 Person 객체로 변환하는 컨버터를 구현해보자. Person 객체는 name과 age 필드를 갖는다. Controller에서 URL 파라미터를 Person 객체로 반환해야 한다면 커스텀 컨버터를 구현 후, WebMvcConfigurer 에서 등록해야 한다.

@GetMapping("/type-converter")
public void typeConverter(@RequestParam Person person) {
    log.info("person.getName() = {}", person.getName());
    log.info("person.getAge() = {}", person.getAge());
}

다음과 같이 Converter 인터페이스를 implements 한 StringToPersonConverter 클래스를 만든다. 그리고 convert() 메서드를 오버라이드 한다. convert() 메서드 내부에서는 "gom:1200" 과 같은 문자열이 들어오면 : 를 기준으로 나눈 후 이름과 나이를 구해 새로운 Person 객체를 반환하고 있다.

public class StringToPersonConverter implements Converter<String, Person> {
    
    // source = "gom:1200"
    @Override
    public Person convert(String source) {
    
        String[] parts = source.split(":");
        String name = parts[0];
        
        int months = Integer.parseInt(parts[1]);
        int age = months / 12;
        
        return new Person(name, age);
    }
}

그 다음 WebMvcConfigurer 인터페이스를 implements 한 WebConfig 클래스를 만든다. WebConfig 클래스에 다음과 같이 커스텀 컨버터를 등록해야 한다. 오버라이드 한 addFormatters() 메서드 내부에 registry.addConverter()를 통해 등록하자.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addConverter(new StringToPersonConverter());
        registry.addConverter(new PersonToStringConverter());
    }
}

이제 실행 후 Postman에서 테스트해본다. 정상적으로 작동하는 것을 볼 수 있다.

인텔리제이에서도 다음과 같이 이름과 나이가 잘 변환되어 출력된다.

Fomatter 사용하기

Fomatter는 Converter 보다 더 세밀한 문자열 포맷팅을 할 수 있는 기능이다. Formatter 인터페이스를 implements 해서 날짜, 숫자 같은 특정 데이터 포맷으로 변환해보자.

다음과 같이 Formatter 인터페이스를 implements한 PriceFormatter 클래스를 만든다. 그리고 parse() 메서드와 print() 메서드를 오버라이드한다.

@Slf4j
public class PriceFormatter implements Formatter<Number> {

    @Override
    public Number parse(String text, Locale locale) throws ParseException {
        log.info("text = {}, locale={}", text, locale);

        // 기본 제공되는 기능 숫자 중간에 (,) 쉼표를 넣어준다.
        NumberFormat format = NumberFormat.getInstance(locale);
        return format.parse(text);
    }

    @Override
    public String print(Number object, Locale locale) {
        log.info("object = {}, locale = {}", object, locale);
        return NumberFormat.getInstance(locale).format(object);
    }
}

Locale : 지역 및 언어 정보를 나타내는 객체. Locale 정보를 활용하여 나라별로 다른 숫자 포맷으로 만들어준다.

컨버터와 같이 WebConfig에 등록해준다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addFormatter(new PriceFormatter());
    }
}

Postman에서 잘 실행되는 모습을 볼 수 있다.

인텔리제이에서도 잘....되나? 했는데 당연히 위에 적어놓은 Log가 찍힐 줄 알았는데 찍히지 않았다. 찾아보니 Spring이 내부적으로 StringToBigDecimalConverter과 같은 기본 변환기를 사용해 변환할 수 있기 때문에 PriceFormatter가 실행되지 않을 가능성이 있다고 한다.

그래서 addFormatterForFieldType()을 사용해 특정 타입에 대해 강제로 PriceFormatter를 사용하도록 설정하니 로그가 제대로 찍혔다. 하지만 기본 변환기로 변환이 되는거라면 굳이 강제로 사용하게 할 이유는 없는 것 같다.. 이 부분은 더 알아봐야겠다.

[Git] 로컬 브랜치에서 pull 할 때 에러 발생 - stash로 임시 커밋하기

개발곰발 — Tue, 18 Feb 2025 23:28:08 +0900

문제점

develop 브랜치에서 git pull origin develop을 하려는데 에러가 발생했다.

에러 메세지를 읽어보니 내 브랜치에서 아직 커밋되지 않은 변경 사항이 존재하기 때문에 발생한 것이었다.

하지만 현재 내 로컬 브랜치에서의 작업이 아직 끝나지 않아서 commit하고 싶지 않았다.

해결 방법

변경 사항을 유지하면서 git pull 하는 방법으로 진행했다.

1) 변경 사항 임시 저장

git stash push -m "임시 저장"

2) 원격 저장소에서 최신 코드 가져오기

git switch develop
git pull origin develop

로컬 develop 브랜치에 원격 develop 코드를 가져올 것이기 때문에 develop 브랜치로 이동 후 진행했다.

3) 다시 내 브랜치로 이동 후 변경 사항 복구

git checkout LCW git stash pop # 임시 저장한 변경 사항 복원

이렇게 하면 커밋하지 않고 변경 사항을 저장했다가 다시 불러올 수 있다.

[Spring] 왜 엔티티에 Setter를 사용하면 안 될까?

개발곰발 — Thu, 13 Feb 2025 23:56:16 +0900

강의를 참고하여 비밀번호 수정 기능을 구현하던 중, 왜 단순히 Setter를 사용하지 않고 updatePassword() 메서드를 따로 만들어야 하는지 의문이 들었다.

public void updatePassword(String password) {
    this.password = password;
}

Member 엔티티에서 아래와 같이 @Setter를 password 필드 위에 추가하면 안되는 것일까?

@Setter
@Column(nullable = false)
private String password;

찾아보니 Setter의 사용을 지양하는 이유는 여러가지가 있었다.

1️⃣ Setter를 사용하면 객체의 일관성을 유지하기 어렵다.

어디서든 값이 변경될 수 있어 데이터 무결성이 깨질 위험이 있다.

2️⃣ Setter를 사용하면 변경의 의도가 불분명하다.

setPassword()만 보면 이 메서드가 비밀번호 변경을 위한 것인지, 처음 설정하는 것인지 알기 어렵다.

3️⃣ 비즈니스 로직을 명확하게 분리할 수 없다.

비밀번호 변경 시 기존 비밀번호 검증 같은 추가 로직이 필요할 수도 있다.

4️⃣ 결과적으로 유지보수가 어렵다.

여러 곳에서 Setter를 호출해버리면, 이후 로직 변경이 필요할 때 모든 코드에서 변경해야 한다.

결국, Setter를 사용하면 데이터의 무결성이 깨질 가능성이 높고, 유지보수도 어려워진다.

따라서, 비밀번호 변경 로직을 updatePassword() 같은 명확한 메서드로 분리하는 것이 바람직하다.

이렇게 하면 객체의 일관성을 유지하면서, 비즈니스 로직을 더욱 명확하게 관리할 수 있다.

[Spring] INSERT 됐지만 테이블이 안 보이는 문제 - @Transactional

개발곰발 — Wed, 12 Feb 2025 23:30:18 +0900

INSERT 됐지만 테이블이 안보이는 문제

댓글 작성 시, 아래와 같이 INSERT문은 제대로 실행된 것 같은데 DB에서는 comment 테이블이 보이지 않는 문제가 있었다.

@Transactional을 추가하지 않은 것이 원인이다. 트랜잭션이 자동으로 커밋되지 않아서 데이터가 DB에 반영되지 않았던 것이다. Service 계층에서 DB 작업을 수행할 때는 반드시 @Transactional 을 사용해 트랜잭션을 관리해야한다.

다음과 같이 @Transactional 을 붙인다.

@Transactional
public CommentResponseDto save(Long scheduleId, String email, CommentRequestDto dto) {
    Schedule schedule = scheduleRepository.findByIdOrElseThrow(scheduleId);
    Member member = memberRepository.findByEmailOrElseThrow(email);

    Comment comment = new Comment(dto.getContents(), member, schedule);
    Comment savedComment = commentRepository.save(comment);

    return new CommentResponseDto(
        savedComment.getId(),
        savedComment.getContents(),
        member.getUsername(),
        savedComment.getCreatedAt(),
        savedComment.getModifiedAt()
    );
}

이렇게 해도 되지만, 어제 <연관 관계 매핑 세션>에서 튜터님께서 클래스 레벨에 우선@Transactional(readOnly = true)를 사용한다는 것이 기억나 다음과 같이 수정했다. 그리고 지난번 피드백을 다시 보니 다른 튜터님께서도 "트랜잭션 범위를 확실히 하기 위해 DB 업데이트와 관련된 모든 작업을 트랜잭션 내에서 처리하는 것이 좋다."라고 피드백을 남겨주셨다.

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class CommentService {

    private final CommentRepository commentRepository;
    private final ScheduleRepository scheduleRepository;
    private final MemberRepository memberRepository;

    @Transactional
    public CommentResponseDto save(Long scheduleId, String email, CommentRequestDto dto) {
        Schedule schedule = scheduleRepository.findByIdOrElseThrow(scheduleId);
        Member member = memberRepository.findByEmailOrElseThrow(email);

        Comment comment = new Comment(dto.getContents(), member, schedule);
        Comment savedComment = commentRepository.save(comment);

        return new CommentResponseDto(
            savedComment.getId(),
            savedComment.getContents(),
            member.getUsername(),
            savedComment.getCreatedAt(),
            savedComment.getModifiedAt()
        );
    }
}

이 문제를 해결하면서 잘 신경쓰지 않았던 부분의 개념을 확실히 익히게 되었다.

클래스 레벨의 @Transactional(readOnly = true) 적용
- 기본적으로 모든 메서드는 읽기 전용 트랜잭션 사용
- 변경 감지(Dirty Checking) 비활성화 → 불필요한 데이터 변경 감지 로직 생략 → 성능 최적화
- 조회 시 @Transactional이 없어도 동작하지만, @Transactional(readOnly = true)를 사용하면 성능이 최적화 되며 Lazy Loading(지연 로딩) 사용 시 트랜잭션 유지가 필요할 수 있음
쓰기 작업에는 @Transactional을 개별적으로 추가해야 함.
- 메서드 레벨에서 @Transactional을 명시하면, 클래스 레벨의 readOnly = true를 무시하고 데이터 변경이 가능한 트랜잭션으로 동작

[Java/Study] 김영한의 실전 자바 중급 2편 - 스터디 15회차

개발곰발 — Fri, 7 Feb 2025 03:13:57 +0900

인프런 강의 <김영한의 실전 자바 - 중급 2편>을 보고 정리한 내용입니다.

매주 모여 각자 정리한 내용을 기반으로 발표하고 질문 공유하는 스터디입니다.

컬렉션 프레임워크 - Map, Stack, Queue

Map

Map은 키-값의 쌍을 저장하는 자료 구조로, HashMap이 많이 사용된다!

키 중복 불가능 / 값은 중복 가능 / 순서 유지X

자바는 Map 인터페이스의 메서드를 구현하는 HashMap, TreeMap, LinkedHashMap 등 다양한 Map 구현체를 제공한다. Map에서 키만 따로 떼어놓고 보면 Set과 똑같기 때문에 Set과 Map의 구현체는 거의 같다. 실제로 HashSet은 내부적으로 HashMap을 사용하여 구현된다. 따라서 각각의 특징도 이전에 배웠던 내용과 거의 흡사해 간략하게만 정리했다.

다음은 String과 Integer 타입을 키-값으로 사용하는 map을 각각의 구현체로 돌린 결과다. 간단한 코드라서 자바 코드를 모두 가져오진 않았지만, 결과를 보면 각 구현체의 특징을 알 수 있다.

// map에 넣은 데이터 순서
map.put("C", 10);
map.put("B", 20);
map.put("A", 30);
map.put("1", 40);
map.put("2", 50);

map = class java.util.HashMap
A=30 1=40 B=20 2=50 C=10

map = class java.util.LinkedHashMap
C=10 B=20 A=30 1=40 2=50

map = class java.util.TreeMap
1=40 2=50 A=30 B=20 C=10

✔️ Map 인터페이스 주요 메서드 정리

put(K key, V value) : 지정된 키와 값을 맵에 저장한다. (같은 키가 있으면 값 변경)
putAll(Map<? extends K, ? extends V> m) : 지정된 맵의 모든 매핑을 현재 맵에 복사한다.
putIfAbsent(K key, V value) : 지정된 키가 없는 경우에 키와 값을 맵에 저장한다.
get(Object key) : 지정된 키에 연결된 값을 반환한다.
getOrDefault(Object key, V defaultValue) : 지정된 키에 연결된 값을 반환한다. 키가 없는 경우 defaultValue로 지정한 값을 대신 반환한다.
remove(Object key) : 지정된 키와 그에 연결된 값을 맵에서 제거한다.
clear() : 맵에서 모든 키와 값을 제거한다.
containsKey(Object key) : 맵이 지정된 키를 포함하고 있는지 여부를 반환한다.
containsValue(Object value) : 맵이 하나 이상의 키에 지정된 값을 연결하고 있는지 여부를 반환한다.
keySet() : 맵의 키들을 Set 형태로 반환한다.
values() : 맵의 값들을 Collection 형태로 반환한다.
entrySet() : 맵의 키-값 쌍을 Set<Map.Entry<K, V>> 형태로 반환한다.
size() : 맵에 있는 키-값 쌍의 개수를 반환한다.
isEmpty() : 맵이 비어 있는지 여부를 반환한다.

✔️ Map 순회하기

다음과 같이 studentMap에 학생의 이름(키)과 점수(값)를 넣었다고 한다면, 어떻게 키와 값을 조회할 수 있을까?

Map<String, Integer> studentMap = new HashMap<>();

studentMap.put("studentA", 90);
studentMap.put("studentB", 80);
studentMap.put("studentC", 80);
studentMap.put("studentD", 100);

1) 키 목록 조회: keySet()

Set<String> keySet = studentMap.keySet();
for (String key : keySet) {
    Integer value = studentMap.get(key);
    System.out.println("key = " + key + ", value = " + value);
}

map.keySet()를 활용해 키의 목록을 조회할 수 있다. Map에서 키만 따로 떼어놓고 보면 Set과 똑같기 때문에 keySet()을 호출하면 Set을 반환한다. 여기서 얻은 키를 활용해 map.get()를 이용하면 해당 키에 따른 값도 구할 수 있다.

2) 값 목록 조회: values()

Collection<Integer> values = studentMap.values();
for (Integer value : values) {
    System.out.println("value = " + value);
}

map.values()를 활용해 값의 목록을 조회할 수 있다. 여기서 값은 중복을 허용하고, 입력 순서를 보장하지 않기 때문에 Set이나 List로 반환하기 애매하다. 따라서 상위 인터페이스인 Collection으로 반환한다.

3) 키와 값 목록 조회: entrySet()

Set<Map.Entry<String, Integer>> entries = studentMap.entrySet();
for (Map.Entry<String, Integer> entry : entries) {
    String key = entry.getKey();
    Integer value = entry.getValue();
    System.out.println("key = " + key + ", value = " + value);
}

❔Entry란 Map 내부에 있는 인터페이스로, Map 내부에서 키와 값을 하나로 묶어 저장할 때 사용하는 객체다.

따라서 map.entrySet()를 활용해 Entry 객체들을 가져와 각 Entry를 하나씩 꺼내면서 키와 값을 조회할 수 있다. 키를 가져올 때는 각 Entry에서 getKey(), 값을 가져올 때는 getValue()를 사용한다.

HashMap 은 HashSet 과 작동 원리가 같다. Set과 비교했을때 차이점은,

키를 사용해 해시 코드 생성
Entry를 사용해 키와 값을 하나로 묶어 저장

Map은 키를 저장하는 구조에서 해시 테이블을 활용한다. 따라서 Map의 키로 사용되는 객체는 hashCode() , equals() 를 반드시 구현해야 한다!

Stack

Stack은 나중에 넣은 것이 가장 먼저 나오는 후입 선출(LIFO, Last In First Out) 자료구조다!

단, Stack 클래스 대신 Deque를 사용하자!

push(E item) : 스택의 맨 위에 새로운 요소를 추가한다.
pop() : 스택의 맨 위에 있는 요소를 제거하고 반환한다. (스택이 비어있으면 예외 발생)
peek() : 스택의 맨 위 요소를 제거하지 않고 반환한다. (스택이 비어있으면 예외 발생)
isEmpty() : 스택이 비어있는지 확인한다.
size() : 스택에 있는 요소의 개수를 반환한다.

자바의 Stack 클래스는 내부에서 지금은 사용되지 않는 Vector라는 자료구조를 사용한다. 따라서 Stack 대신 더 빠르고 좋은 Deque를 사용할 것을 권장한다.

Queue

Queue는 가장 먼저 넣은 것이 가장 먼저 나오는 선입 선출(FIFO, First In First Out) 자료구조다!

Queue의 뒤에서 요소를 추가하고 앞에서 요소를 제거하는 방식으로 동작한다.

offer(E element) : 큐의 끝에 요소를 추가하며, 추가에 성공하면 true를 반환한다. (용량 제한이 있는 경우, 공간이 부족하면 false 반환)
poll() : 큐의 맨 앞 요소를 제거하고 반환한다. 큐가 비어 있으면 null을 반환한다.
peek() : 큐의 맨 앞 요소를 제거하지 않고 반환한다. 큐가 비어 있으면 null을 반환한다.
isEmpty() : 큐가 비어 있는지 확인한다.
size() : 큐에 있는 요소의 개수를 반환한다.

다음 그림과 같이 Queue 인터페이스 역시 Collection의 자식이다. 대표적인 구현체는 ArrayDeque, LinkedList가 있다.

Deque

Deque(Double Ended Queue)는 양쪽 끝에서 요소를 추가하거나 제거할 수 있는 유연한 자료구조다!

Deque를 사용하면 스택 연산과 큐 연산을 모두 수행할 수 있다.

offerFirst() : 앞에 추가한다.
offerLast() : 뒤에 추가한다.
pollFirst() : 앞에서 꺼낸다.
pollLast() : 뒤에서 꺼낸다.
Stack을 위한 메서드
- push() : 앞에서 추가한다.
- pop() : 앞에서 꺼낸다.
Queue를 위한 메서드
- offer() : 뒤에서 추가한다.
- poll() : 앞에서 꺼낸다.

Deque의 대표적인 구현체로 ArrayDeque와 LinkedList가 있다. ArrayDeque는 동적 크기의 배열을 사용하며, 일반적으로 LinkedList보다 더 빠른 성능을 제공한다. 두 구현체 모두 앞, 뒤에서의 삽입 및 삭제 연산에서 평균적으로 O(1)의 성능을 보이지만, ArrayDeque는 연속적인 메모리 블록을 사용하여 캐시 적중률이 높아 실제 환경에서는 LinkedList보다 더 나은 성능을 보여준다.

❓" ArrayDeque는 추가로 특별한 원형 큐 자료 구조를 사용하는데, 덕분에 앞, 뒤 입력 모두 O(1)의 성능을 제공한다." 라고 교안에 나와있는데, ArrayDeque는 고정된 크기의 배열을 사용하는게 아닌가? 하는 의문이 들어 좀 더 찾아봤다.

→ 여기서 말하는 '원형 큐 자료 구조를 사용한다'라는 말은, 원형 큐처럼 동작한다는 의미인 것 같다.

→ 내부적으로 배열을 기반으로 하면서도 처음과 끝에서 삽입/삭제가 가능하도록 인덱스를 조정하는 구조이기 때문에 원형 큐처럼 보이는 것이다.

→ 여기서 인덱스를 조정하는 구조란, 두 개의 인덱스(head, tail) 사용해 원형 큐처럼 인덱스를 순환하면서 관리하는 구조를 말한다.

컬렉션 프레임워크 - 순회, 정렬

Iterable & Iterator

자바는 모든 자료구조를 동일한 방법으로 편리하게 순회할 수 있도록 Iterable과 Iterator 인터페이스를 제공한다!

✔️ Iterable(반복 가능한) 인터페이스의 주요 메서드

public interface Iterable<T> {
    Iterator<T> iterator();
}

Iterator 반복자를 반환한다.
대부분의 컬렉션이 Iterable을 구현하고 있어 for-each문을 사용할 수 있다.

✔️ Iterator(반복자) 인터페이스의 주요 메서드

public interface Iterator<E> {
    boolean hasNext();
    E next();
}

컬렉션을 탐색(반복)하는 방법을 제공한다.
hasNext() : 다음 요소가 있는지 확인한다. 다음 요소가 없으면 false 를 반환한다.
next() : 다음 요소를 반환한다. 내부에 있는 위치를 다음으로 이동한다.
자료구조마다 Iterator의 구현 방식은 다르지만, 우리는 Iterator 인터페이스를 통해 동일한 방식으로 요소를 순회할 수 있다. 직접 구현할 필요 없이, 컬렉션 프레임워크가 제공하는 iterator() 메서드로 Iterator 객체를 가져와 사용하면 된다.

✔️ 향상된 for문(for-each)

향상된 for문을 사용하려면 Array 혹은 Iterable을 가지고 있어야 한다.

for (int i : arr) {
    System.out.println(i);
}

위와 같이 향상된 for문을 쓰면 자바는 컴파일 시점에 다음과 같이 코드를 변경한다. 두 코드는 같은 코드이지만, 향상된 for문이 더 깔끔하다.

while (iterator.hasNext()) {
    Integer i = iterator.next();
    System.out.println(i);
}

자바 Collection 인터페이스의 상위에 Iterable이 있다는 것에 주목하자!

하지만 Map은 키-값 구조이기 때문에 Iterable 대신 Map 인터페이스가 상위에 존재한다. 따라서 Map 자체를 Iterable을 통해 순회할 수는 없지만, entrySet(), keySet(), values()를 사용해 Set이나 Collection을 반환받아 향상된 for문을 사용할 수 있다.

Comparable & Comparator

객체를 기본 정렬할 때 Comparable를 사용하고, 다른 정렬 기준이 필요하면 Comparator를 사용하자!

✔️ 배열 정렬

Arrays.sort() : 배열에 들어있는 데이터를 순서대로 정렬한다.(오름차순)

Integer[] array = {3, 2, 1};
System.out.println(Arrays.toString(array));

System.out.println("기본 정렬 후");
Arrays.sort(array);
System.out.println(Arrays.toString(array));

[3, 2, 1]
기본 정렬 후
[1, 2, 3]

Arrays.sort(array, Comparator) : 내림차순 정렬이나 특정 기준을 적용한 정렬을 할 때 사용한다.

다음과 같이 인수로 비교자(Comparator)를 만들어 넘겨주고 정렬 방식을 지정한다. 두 인수를 비교해 경과 값을 반환한다.

public interface Comparator<T> {
    int compare(T o1, T o2);
}

첫 번째 인수가 더 작으면 음수(작은 값이 앞쪽으로 이동)
두 값이 같으면 0
첫 번째 인수가 더 크면 양수(큰 값이 앞쪽으로 이동)

강의 실습을 통해 다음과 같이 AscComparator와 DescComparator를 만들었다.

import java.util.Comparator;

public class AscComparator implements Comparator<Integer> {
    @Override
    public int compare(Integer o1, Integer o2) {
        return (o1 < o2) ? -1 : ((o1 == o2) ? 0 : 1);
    }
}

DescComparator는 AscComparator과 거의 같지만 마지막에 -1을 곱해줘서 정렬의 결과가 오름차순의 반대인 내림차순이 다.

import java.util.Comparator;

public class DescComparator implements Comparator<Integer> {
    @Override
    public int compare(Integer o1, Integer o2) {
        return ((o1 < o2) ? -1 : ((o1 == o2) ? 0 : 1)) * -1;
    }
}

다음과 같이 사용할 수 있다. 맨 마지막과 같이 reversed() 메서드를 사용하면 비교의 결과를 반대로 변경한다.

Integer[] array = {3, 2, 1};

Arrays.sort(array, new AscComparator()); // [1, 2, 3]
Arrays.sort(array, new DescComparator()); // [3, 2, 1]
Arrays.sort(array, new AscComparator().reversed()); // [3, 2, 1]

직접 만든 객체를 정렬하려면 객체에 비교 기능을 추가해주는 Comparable 인터페이스를 구현하면 된다. 자기 자신과 인수로 넘어온 객체를 비교해서 반환한다.

public interface Comparable<T> {
    public int compareTo(T o);
}

현재 객체가 인수로 주어진 객체보다 더 작으면 음수
두 객체의 크기가 같으면 0
현재 객체가 인수로 주어진 객체보다 더 크면 양수

Comparable을 구현한 MyUser 클래스를 보자. 정렬의 기준을 나이로 정해 compareTo()를 구현했다. 이후 MyUser로 구성된 배열을 Arrays.sort()에 넣으면 객체 스스로 가지고 있는 Comparable을 사용해 비교한다. 따라서 나이 기준 오름차순으로 정렬된다.

public class MyUser implements Comparable<MyUser> {

    private String id;
    private int age;

    public MyUser(String id, int age) {
        this.id = id;
        this.age = age;
    }

    public String getId() {
        return id;
    }

    public int getAge() {
        return age;
    }

    @Override
    public int compareTo(MyUser o) {
        return this.age < o.age ? -1 : (this.age == o.age ? 0 : 1);
    }

    @Override
    public String toString() {
        return "MyUser{" +
                "id='" + id + '\'' +
                ", age=" + age +
                '}';
    }
}

만약 나이가 아니라 아이디로 비교하고 싶다면 아이디로 비교할 수 있는 IdComparator를 만들어 Array.sort의 인수로 넘겨주면 된다. 그러면 MyUser 객체가 기본으로 가지고 있는 Comparable을 무시하고 전달된 비교자를 사용해 정렬한다.

public class IdComparator implements Comparator<MyUser> {
    @Override
    public int compare(MyUser o1, MyUser o2) {
        return o1.getId().compareTo(o2.getId());
    }
}

* 나이를 우선 비교하고, 나이가 같은 경우 아이디를 비교하려면 어떻게 해야할까?

Comparable을 활용한 기본 정렬

@Override
public int compareTo(MyUser other) {
    int ageCompare = Integer.compare(this.age, other.age); // 나이 기준 정렬
    if (ageCompare == 0) {
        return this.id.compareTo(other.id); // 같은 나이면 ID 기준 정렬 (문자열 오름차순)
    }
    return ageCompare;
}

Comparator를 활용한 정렬

여러 개의 정렬 기준을 적용해야 할 때 Comparator의 .thenComparing()을 활용하면 더 코드가 짧고 가독성이 좋아진자. thenComparing()은 여러 개의 정렬 기준을 쉽게 조합할 수 있는 메서드다.

// 나이 오름차순, 같은 나이면 ID 오름차순
Collections.sort(users, 
    Comparator.comparing(MyUser::getAge)
              .thenComparing(MyUser::getId)
);

만약 나이를 내림차순으로 정렬하고자 한다면, MyUser::getAge 뒤에 Comparator.reverseOrder()를 적용하면 된다.

✔️ 컬렉션 정렬

위에서 만든 MyUser 객체를 리스트에 담아 정렬한다면 다음과 같이 사용할 수 있다. 여기서 객체 스스로 정렬 메서드를 가지고 있는 list.sort() 사용을 더 권장한다.

list.sort() (권장)
list.sort(new Comparator()) (권장)
Collections.sort(list)
Collections.sort(list, Comparator())

// 기본 정렬
list.sort(null);
Collections.sort(list);

// IdComparator 정렬
list.sort(new IdComparator());
Collections.sort(list, new IdComparator());

✔️ TreeSet, TreeMap은 Comparable 혹은 Comparator 필수!

TreeSet이나 TreeMap은 이진 탐색 트리로 데이터를 정렬하면서 보관하기 때문에 정렬 기준을 꼭 제공해줘야 한다. 별도의 비교자를 제공하지 않으면 객체가 구현한 Comparable을 사용해 기본(자연) 순서로 정렬하고, 별도의 비교자를 제공하면 해당 Comparator를 사용해 정렬한다.

new TreeSet<>() // Comparable 사용
new TreeSet<>(new IdComparator()) // Comparator 사용

컬렉션 유틸

✔️ Collections 정렬 관련 메서드

max: 정렬 기준으로 최대 값을 찾아서 반환한다.
min: 정렬 기준으로 최소 값을 찾아서 반환한다.
shuffle: 컬렉션을 랜덤하게 섞는다.
sort: 정렬 기준으로 컬렉션을 정렬한다.
reverse: 정렬 기준의 반대로 컬렉션을 정렬한다. (컬렉션에 들어있는 결과를 반대로 정렬한다.)

✔️ of() 메서드로 컬렉션 생성(권장)

List.of(), Set.of(), Map.of()를 사용하면 불변 컬렉션을 반환므로 요소를 추가, 삭제, 변경할 수 없다.

List<Integer> list = List.of(1,2,3);
Set<Integer> set = Set.of(1,2,3);
Map<Integer,String> map = Map.of(1,"one",2,"two");

✔️ Arrays.asList() 메서드로 리스트 생성

고정 크기 리스트를 반환하므로, 요소를 추가하거나 삭제할 수 없지만, 기존 요소들은 변경할 수 있다.

List<Integer> list = Arrays.asList(1, 2, 3);

내부적으로 배열을 기반으로 하는 리스트이므로, asList()로 만든 리스트는 원본 배열과 연결된다.
기존 배열의 참조값을 그대로 활용하기 때문에 생성 비용이 적고, 큰 자료구조가 필요한 경우 적합하다.

Integer[] arr = {1, 2, 3};
List<Integer> list = Arrays.asList(arr);
arr[0] = 10;  // 리스트에도 반영됨 → list는 [10, 2, 3]

✔️ 불변 컬렉션 → 가변 컬렉션 전환

List<Integer> list = new ArrayList<>(List.of(1, 2, 3));
Set<Integer> set = new HashSet<>(Set.of(1, 2, 3));
Map<Integer, String> map = new HashMap<>(Map.of(1, "one", 2, "two"));

✔️ 가변 컬렉션 → 불변 컬렉션 전환

Collections.unmodifiableXXX()를 사용해 가변 컬렉션을 불변 컬렉션으로 전환할 수 있다.

List<Integer> mutableList = new ArrayList<>(List.of(1, 2, 3));
List<Integer> immutableList = Collections.unmodifiableList(mutableList);

Set<Integer> mutableSet = new HashSet<>(Set.of(1, 2, 3));
Set<Integer> immutableSet = Collections.unmodifiableSet(mutableSet);

Map<Integer, String> mutableMap = new HashMap<>(Map.of(1, "one", 2, "two"));
Map<Integer, String> immutableMap = Collections.unmodifiableMap(mutableMap);

✔️ 빈 가변 컬렉션 생성

List<Integer> mutableList = new ArrayList<>();
Set<Integer> mutableSet = new HashSet<>();
Map<Integer, String> mutableMap = new HashMap<>();

✔️ 빈 불변 컬렉션 생성

자바5부터 제공

List<Integer> emptyList = Collections.emptyList();
Set<Integer> emptySet = Collections.emptySet();
Map<Integer, String> emptyMap = Collections.emptyMap();

자바9부터 제공(권장)

List<Integer> emptyList = List.of();
Set<Integer> emptySet = Set.of();
Map<Integer, String> emptyMap = Map.of();

✔️ 멀티스레드 동기화

Collections.synchronizedList()를 사용해 동기화 문제가 발생하지 않는 안전한 리스트를 만들 수 있다.
동기화 작업으로 인해 성능은 일반 리스트보다 느리다.

ArrayList<Integer> list = new ArrayList<>();
list.add(1);
list.add(2);
list.add(3);

List<Integer> synchronizedList = Collections.synchronizedList(list);

드디어 자바 강의 기본편부터 중급1, 중급2편 완강!

꾸준히 복습하면서 나아가자.

[Spring] Spring에서 @RequestBody를 사용할 때 주의해야 할 점

개발곰발 — Tue, 4 Feb 2025 15:53:17 +0900

삭제 기능 테스트 도중, 올바른 비밀번호를 입력해도 404 에러가 뜨는 문제가 있었다. 404 에러를 던지도록 설정한 부분은 DB에 있는 비밀번호와 입력한 비밀번호가 틀리는 경우 발생한다.

이것저것 시도해보다 Repository Layer에서 정확한 scheduleId와 password가 출력되는 것을 확인한 후, 비밀번호를 검증하는 Service Layer에서 다음과 같이 출력해봤다.

System.out.println("db password = " + current.getPassword());
System.out.println("input password = " + password);
System.out.println("equals = " + current.getPassword().equals(password));

그 결과는 다음과 같았다. JSON 형식의 문자열이 그대로 들어온 것이다.

Controller에서 보니 비밀번호를 String 그대로 넣은 것이 문제였다.

@DeleteMapping("/{scheduleId}")
public ResponseEntity deleteSchedule(
        @PathVariable Long scheduleId,
        @RequestBody(required = false) String password
) {
    scheduleService.deleteSchedule(scheduleId, password);
    
    return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}

inputPassword → {"password": "1111"} (JSON 객체)
dbPassword → "1111" (String)

따라서 String 타입이 아닌 ScheduleRequestDto 타입으로 변경한 뒤 dto에서 getPassword()를 해서 비밀번호만 넘겨주었다.

@DeleteMapping("/{scheduleId}")
public ResponseEntity<Void> deleteSchedule(
        @PathVariable Long scheduleId,
        @RequestBody ScheduleRequestDto dto
) {
    scheduleService.deleteSchedule(scheduleId, dto.getPassword());
    return new ResponseEntity<>(HttpStatus.NO_CONTENT);
}

변경 후 다시 로그를 출력해보니 원하던 결과가 나왔다.

또한 Postamn에서의 테스트도 성공하였다.

이 과정을 통해 @RequestBody에서 JSON 데이터를 받을 때 String 대신 DTO 객체를 사용하는 것이 좋다는 것을 알게 되었다.

여기서 또 수정된 부분이 있는데, required = false로 적은 부분을 삭제한 부분이다. @RequestBody(required = true) 가 설정되어 있으면, 클라이언트는 JSON을 반드시 보내야 하지만, 특정 필드는 null이 될 수도 있다. 이때, @RequestBody(required = false)로 변경하면 요청 본문이 없어도 예외가 발생하지 않는다. 비밀번호가 선택 사항이라면 false로 하는 것도 고려할 수 있지만 보통 비밀번호는 필수값이기 때문에 사용하지 않는다.

[Spring] queryForObject() vs query()

개발곰발 — Mon, 3 Feb 2025 23:36:12 +0900

예외 처리를 구현하는 도중, 원하는 곳에서 예외가 발생하지 않고 엉뚱한 곳에서 발생해서 그 원인을 찾아보았다.

일정을 수정하는 부분 중 findScheduleByIdWithPassword()에서 내가 설정한 ScheduleNotFoundException이 아니라 EmptyResultDataAccessException이 났다.

@Transactional
@Override
public ScheduleResponseDto updateSchedule(Long scheduleId, ScheduleRequestDto dto) {
    Schedule current = scheduleRepository.findScheduleByIdWithPassword(scheduleId);

    if (current == null) {
        throw new ScheduleNotFoundException("수정할 일정이 존재하지 않습니다.");
    }

	// 중략..

}

해당 메서드가 구현되어있는 Repository로 가서 살펴보니, 다음과 같이 queryForObject()를 사용하고 있는 것이 문제였다. queryForObject()는 결과가 없으면 null을 반환하는 게 아니라 예외를 던지기 때문에, Service에서 null 체크를 할 수 없던 것이었다!

@Override
public Schedule findScheduleByIdWithPassword(Long scheduleId) {
    return jdbcTemplate.queryForObject(
            "SELECT * FROM schedules WHERE scheduleId = ?",
            scheduleWithPasswordRowMapper(),
            scheduleId
    );
}

따라서 queryForObject() 대신 query()를 사용하여 예외를 발생시키지 않고, 결과가 없으면 null을 반환하도록 수정했다. 그리고 Service에서 null 체크 후 사용자 정의 예외인 ScheduleNotFoundException을 던지는 것에 성공했다.

@Override
public Schedule findScheduleByIdWithPassword(Long scheduleId) {
    String query = "SELECT * FROM schedules WHERE scheduleId = ? AND is_deleted = FALSE";
    List<Schedule> schedules = jdbcTemplate.query(query, scheduleWithPasswordRowMapper(), scheduleId);
    return schedules.isEmpty() ? null : schedules.get(0);
}

Postman에서도 내가 원하는 대 상태코드와 메세지가 출력되는 것을 볼 수 있다.

✔️ 정리

queryForObject(): 단일 객체를 반환하는 메서드
- 결과가 반드시 1개일 거라고 가정할 때 사용해야 하는 메서드
- 조회된 결과가 0개면 EmptyResultDataAccessException 발생
- 조회된 결과가 2개 이상이면 IncorrectResultSizeDataAccessException 발생
query(): 여러 개의 결과를 처리하는 메서드
- 조회된 결과가 1개 이상이면 리스트로 반환
- queryForObject()와 다르게 결과가 없을 때 예외를 던지지 않음

즉, "조회된 결과가 없을 수도 있다"면 query()를 쓰고, "반드시 1개가 나와야 한다"면 queryForObject()를 쓰자!

[Java/Study] 김영한의 실전 자바 중급 2편 - 스터디 14회차

개발곰발 — Sat, 25 Jan 2025 14:08:51 +0900

인프런 강의 <김영한의 실전 자바 - 중급 2편>을 보고 정리한 내용입니다.

매주 모여 각자 정리한 내용을 기반으로 발표하고 질문 공유하는 스터디입니다.

HashSet

해시 코드

해시 자료 구조에 데이터를 저장하는 경우 hashCode() 를 구현해야 한다!

해시 인덱스는 배열의 인덱스로 사용되기 때문에 양의 정수만 사용 가능하다. 따라서 문자 혹은 객체의 경우 hashCode() 메서드를 통해 고유한 숫자를 만들고, 그 숫자를 이용해 해시 인덱스를 만든다.

문자열의 경우, hashCode() 메서드를 통해 문자를 기반으로 고유한 숫자를 만든다. 강의에서는 'A' - 65, 'B' - 66, 'AB' - 131와 같이 아스키 코드를 통해 각 문자에 고유한 숫자를 할당해 계산했다. 실제 자바의 String.hashCode()는 다음과 같이 각 문자에 가중치를 적용하여 더 복잡한 연산을 수행한다.

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

객체의 경우도 마찬가지로 hashCode() 메서드를 통해 고유한 숫자를 만든다. Object 에 있는 hashCode() 메서드를 보통 오버라이딩해서 사용한다. 해당 메서드의 기본 구현은 객체의 참조값을 기반으로 해시 코드를 생성한다. 따라서 만약 id값으로 Member 객체를 구분하고 싶다고 하면, 반드시 hashCode()를 구현해줘야 제대로 구분할 수 있다. 구현하지 않으면 각 인스턴스 별로 해시코드가 다르기 때문에 같은 id라도 인스턴스가 다르면 제대로 구분되지 않는다.

public class Object {
    public int hashCode();
}

✔️ Object의 기본 기능

hashCode() : 객체의 참조값을 기반으로 해시 코드 반환
equals() : == 동일성 비교를 해서 객체의 참조값이 같아야 true 반환

❓hash()와 hashCode() 차이

강의에서는 hash()를 사용했는데, IDE에서 생성된 걸 보니 hashCode()로 생성되었다. 그 차이가 무엇인지 궁금해서 찾아보았다.

private int hashIndex(Object value) {
    return Math.abs(value.hashCode() % capacity);
}

private int hashIndex(Object value) {
    return Math.abs(value.hash() % capacity);
}

hashCode() : 객체 자체의 고유 해시코드를 반환하며, 해시 기반 자료구조에서 사용된다.(ex. id 기반으로 해시 코드 생성 시)
Objects.hash() : 여러 필드를 기반으로 해시코드를 계산할 때 유용하며, 주로 hashCode() 메서드 구현을 단순화하는 데 사용된다.(ex. id와 name을 기반으로 해시 코드를 생성 시)

equals, hashCode의 중요성

해시 자료 구조 사용 시 equals()와 hashCode()를 반드시 구현해야 한다!

해시 자료 구조를 사용할 때 hashCode() 뿐만 아니라 해시 충돌을 대비해 equals() 역시 재정의가 필요하다. 해시 인덱스가 충돌하면 같은 해시 인덱스에 있는 데이터들을 하나하나 비교해야하는데, 이때 equals()를 사용하기 때문이다. 만약 특정 인덱스에 데이터가 하나만 있다고 하더라도 해시 인덱스와 실제 저장된 데이터는 다를 수 있기 때문에 equals()를 꼭 구현해야 한다.

"JPA" 회원 / "hi" 회원의 해시 인덱스 : 0번
"hi" 회원만 저장했을때, "JPA" 회원을 찾는다면?
- equals()를 구현했을 경우 -> 0번 인덱스에는 "hi" 회원만 존재하므로 검색 실패
- equals()를 구현하지 않았을 경우 -> 0번 인덱스에 있는 객체를 무작정 찾아서 "hi" 회원이 검색되는 오류 발생

이런 식으로 오류가 발생할 수 있는데, Object가 기본으로 제공하는 기능은 단순히 인스턴스의 참조값을 기반으로 작동하기 때문이다. 강의에서는 다음과 같이 세 가지 상황에서 어떤 결과가 나오는지 알아보았다.

hashCode, equals를 모두 구현하지 않은 경우
- 데이터 저장 문제 : Object의 기본 기능을 사용해 인스턴스 참조값 기반으로 해시 코드를 생성했기 때문에 같은 id라도 다른 위치에 저장되어 중복 저장되는 문제 발생
- 데이터 검색 문제 : 데이터 검색 시 사용되는 해시 코드 역시 달라서 검색 실패
hashCode는 구현했지만 equals를 구현하지 않은 경우
- 데이터 저장 문제 : hashCode() 재정의로 같은 id라면 같은 해시 코드를 사용, 그러나 중복 데이터 체크 로직에서 사용되는 contains()는 내부에서 equals()를 사용하므로 인스턴스의 참조값 기반으로 중복 체크
- 데이터 검색 문제 : contains() 내부에서 equals()로 비교하기 때문에 인스턴스 참조값을 비교하므로 검색 실패
hashCode, equals를 모두 구현한 경우 : 같은 id라면 같은 해시 코드 사용, 중복 데이터 체크 성공, 검색 성공

✔️ 용어 정리

해시 함수 : 임의의 길이릐 데이터를 입력받아 고정된 길이(=저장 공간의 크기)의 해시 코드를 출력하는 함수.
해시 충돌 : 다른 데이터를 입력해도 같은 해시 코드가 출력되는 것.
해시 코드 : 해시 함수를 통해서 나온 결과로, 데이터를 대표하는 값.
해시 인덱스 : 해시 코드를 사용해 데이터의 저장 위치를 결정하는 값.

Set

Set은 중복을 허용하지 않고, 순서를 보장하지 않는 자료구조로, 빠른 검색이 가능하다!

실무에서는 주로 HashSet을 사용하며, 상황에 따라 LinkedHashSet(입력 순서 보장), TreeSet(데이터 값 기준 정렬)을 사용한다!

HashSet / LinkedHashSet / TreeSet 요약

✔️ Set 인터페이스의 주요 메서드

add(E e) : 지정된 요소를 세트에 추가한다.(이미 존재하는 경우 추가X)
addAll(Collection<? extends E> c) : 지정된 컬렉션의 모든 요소를 세트에 추가한다.
contains(Object o) : 세트가 지정된 요소를 포함하고 있는지 여부를 반환한다.
containsAll(Collection<?> c) : 세트가 지정된 컬렉션의 모든 요소를 포함하고 있는지 여부를 반환한다.
remove(Object o) : 지정된 요소를 세트에서 제거한다.
removeAll(Collection<?> c) : 지정된 컬렉션에 포함된 요소를 세트에서 모두 제거한다.
retainAll(Collection<?> c) : 지정된 컬렉션에 포함된 요소만을 유지하고 나머지 요소는 세트에서 제거한다.
clear() : 세트에서 모든 요소를 제거한다.
size() : 세트에 있는 요소의 수를 반환한다.
isEmpty() : 세트가 비어 있는지 여부를 반환한다.
iterator() : 세트의 요소에 대한 반복자를 반환한다.
toArray() : 세트의 모든 요소를 배열로 반환한다.
toArray(T[] a) : 세트의 모든 요소를 지정된 배열로 반환한다.

✔️ 재해싱(rehashing)

데이터의 양이 75% 이상일 경우, 배열의 크기를 2배 증가시키고 모든 데이터의 해시 인덱스를 커진 배열에 맞춰 다시 계산하는 과정. 자바는 재해싱을 통해 최적화 한다.

✔️ 이진 탐색 트리

이진 탐색 트리 : 한 노드의 왼쪽 서브 트리는 해당 노드의 값보다 작은 값을 가진 노드로 구성되고, 오른쪽 서브 트리는 해당 노드의 값보다 큰 값을 가진 노드로 구성된 트리
- 데이터를 입력하는 시점에 데이터의 값을 기준으로 정렬해서 보관
- 한 번 비교를 할 때마다 절반의 데이터만 남길 수 있음
- O(log N)의 시간 복잡도
- 최악의 경우 O(n)의 시간 복잡도
- TreeSet은 레드-블랙 트리를 사용해 균형 유지, 따라서 최악의 경우에도 O(log N)의 시간 복잡도
- 데이터를 차례로 순회하기 위해 중위 순회(왼쪽 서브트리 -> 현재 노드 -> 오른쪽 서브트리)

다음과 같이 트리가 불균형해지면 데이터 수만큼 검색을 해야한다. 따라서 최악의 경우 O(n)의 성능이 나온다.

따라서 TreeSet은 불균형을 해결하기 위해 다음과 같이 레드-블랙 트리를 사용한다. 위의 불균형한 트리를 5를 기준으로 다시 정렬한 모습이다.

✔️ Set에 배열 편하게 넣기

Set 구현체의 생성자에 컬렉션을 전달할 수 있다.

따라서 다음과 같이 Integer 배열을 List로 바꿔 생성자에 넣으면 바로 추가된다.

Integer[] inputArr = {30, 20, 20, 10, 10};
Set<Integer> set = new LinkedHashSet<>(List.of(inputArr));

✔️ Arrays.asList()와 List.of()

Arrays.asList()와 List.of() 모두 자바에서 List 객체를 생성하는 데 사용된다. 자바 9 이상을 사용한다면 List.of()를 권장한다.

List.of()를 권장하는 이유가 궁금해 Arrays.asList()와 List.of()를 비교해보았다. List.of()를 사용하면 불변 컬렉션을 생성해서 데이터를 안전하게 보호할 수 있고, 가변 크기를 지원한다. 또한 내부적으로 더 효율적인 방식으로 동작한다고 한다. 가볍게 보고 넘어가자!

[Java/Study] 김영한의 실전 자바 중급 2편 - 스터디 13회차

개발곰발 — Sat, 18 Jan 2025 22:38:03 +0900

인프런 강의 <김영한의 실전 자바 - 중급 2편>을 보고 정리한 내용입니다.

매주 모여 각자 정리한 내용을 기반으로 발표하고 질문 공유하는 스터디입니다.

List

"의존한다" 라는 것은 무엇일까? 다음과 같이 MyList를 구현하는 MyArrayList와 MyArrayList를 만들었다.

public interface MyList<E> {
    int size();
    void add(E e);
    void add(int index, E e);
    E get(int index);
    E set(int index, E element);
    E remove(int index);
    int indexOf(E o);
}

public class MyArrayList<E> implements MyList<E> {
 //...
}

public class MyLinkedList<E> implements MyList<E> {
 //...
}

만약 MyArrayList 를 활용해서 많은 데이터를 처리하는 BatchProcessor 클래스를 개발한다고 할 때, 데이터를 앞에서 추가하는 일이 많은 상황이 올 수 있다. 그러면 그때마다 MyLinkedList 를 사용하도록 코드를 변경해야 한다. 이런 상황을 BatchProcessor가 구체적인 클래스에 의존한다고 표현한다.

public class BatchProcessor {

    private final MyArrayList<Integer> list = new MyArrayList<>();

    public BatchProcessor(MyList<Integer> list) {
        this.list = list;
    }

    public void logic(int size) {
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < size; i++) {
            list.add(0, i); // 앞에 추가
        }
        long endTime = System.currentTimeMillis();
        System.out.println("크기: " + size + 
        ", 계산 시간: " + (endTime - startTime) + "ms");
    }

}

구체적인 클래스에 의존하는 대신 추상적인 MyList 인터페이스에 의존할 수 있다. 이렇게 하면 BatchProcessor를 생성하는 시점에 리스트 전략을 선택해 전달하면 되고, 클라이언트 코드인 BatchProcessor의 변경 없이도 MyArrayList에서 MyLinkedList로 변경하는 것이 가능하다. 바로 이것을 의존 관계 주입(Dependency Injection, DI)이라고 한다.

public class BatchProcessor {

    private final MyList<Integer> list = new MyList<>();

    public BatchProcessor(MyList<Integer> list) {
        this.list = list;
    }

    public void logic(int size) {
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < size; i++) {
            list.add(0, i); // 앞에 추가
        }
        long endTime = System.currentTimeMillis();
        System.out.println("크기: " + size + 
        ", 계산 시간: " + (endTime - startTime) + "ms");
    }

}

다음과 같이 외부에서 MyArrayList를 쓸지, MyLinkedList를 쓸지 결정할 수 있다는 것이다. 이 예시 코드에서는 BatchProcessor의 생성자를 통해 의존관계를 주입했기 때문에 생성자 의존관계 주입(생성자 주입)이라고 한다.

public class BatchProcessorMain {
    public static void main(String[] args) {
//        MyArrayList<Integer> list = new MyArrayList<>();
        MyLinkedList<Integer> list = new MyLinkedList<>();

        BatchProcessor processor = new BatchProcessor(list);
        processor.logic(50_000);
    }
}

의존관계는 두 가지로 나뉜다.

1) 컴파일 타임 의존관계

컴파일 타임(compile time): 코드 컴파일 시점
자바 컴파일러가 보는 의존관계로, 실행하지 않은 소스 코드에 정적으로 나타난다.
BatchProcessor 클래스를 보면 MyList 인터페이스에만 의존하고 있는 것을 알 수 있다.
화살표 방향은 의존관계라고 보면 된다.

컴파일 타임 의존관계

2) 런타임 의존관계

런타임(runtime): 프로그램 실행 시점
실제 프로그램이 작동할 때 보이는 의존관계로, 프로그램이 실행될 때 인스턴스 간에 의존관계이다.
런타임 의존관계는 프로그램 실행 중에 계속 변할 수 있다.

런타임 의존관계

BatchProcessor를 생성할 때 생성자를 통해 MyArrayList의 참조인 x001을 던져준다. list 필드가 x001을 세팅하면 BatchProcessor가 MyArrayList를 사용할 수 있게 된다. 따라서 MyArrayList에 대해 런타임 의존관계를 가지게 된다. 따라서 이후에 logic() 을 호출하면 MyArrayList 인스턴스를 사용하게 된다.

클라이언트 클래스는 컴파일 타임에 추상적인 것에 의존하고, 런타임에 의존 관계 주입을 통해 구현체를 주입받아 사용함으로써 다양한 이점을 얻을 수 있다.

✔️ 전략 패턴(Strategy Pattern)
전략 패턴은 중요한 디자인 패턴 중 하나로, 위의 예시 코드처럼 알고리즘을 클라이언트 코드의 변경 없이 쉽게 교체할 수 있는 패턴이다. MyList 인터페이스가 전략을 정의하는 인터페이스가 되고, 각각의 구현체인 MyArrayList , MyLinkedList 가 전략의 구체적인 구현이 된다. 그리고 전략을 클라이언트 코드인 BatchProcessor의 변경 없이 손쉽게 교체할 수 있다.

ArrayList와 LinkedList의 성능을 비교해보면 어떨까? 결론부터 말하자면 대부분의 경우 ArrayList가 성능상 유리하기 때문에 실무에서는 주로 ArrayList를 사용한다. 데이터를 앞쪽에서 추가/삭제하는 일이 많다면 LinkedList를 고려하는 것이 좋다.

직접 구현한 MyArrayList & MyLinkedList와 자바가 제공하는 ArrayList & LinkedList의 성능 차이는 다음과 같다.

직접 구현한 List(왼) / 자바 List(오)

직접 구현한 List와 자바가 제공하는 List는 계산 시간 차이는 있지만 ArrayList와 LinkedList의 성능 차이는 비슷하다. 다른 점이라면 Linked 리스트의 경우 뒤에 추가(삭제) 할 때 자바의 LinkedList가 O(1)의 성능으로 더 빠르다. 왜냐하면 자바가 제공하는 LinkedList는 첫번째 위치뿐만 아니라 마지막 위치까지 가지고 있기 때문이다.

기능	ArrayList	LinkedList
앞에 추가(삭제)	O(n)	O(1)
평균 추가(삭제)	O(n)	O(n)
뒤에 추가(삭제)	O(1)	O(1)
인덱스 조회	O(1)	O(n)
검색	O(n)	O(n)

또한 데이터 추가 시 MyArrayList(평균 966ms)보다 자바의 ArrayList(평균 45ms)가 더 빠른 것을 알 수 있다. 그 이유는 자바의 ArrayList는 데이터를 추가할 때 메모리 고속 복사를 사용하기 때문이다. 데이터가 아주 많은 경우와 시스템에 따른 차이를 제외하면 대략 O(n/10) 정도의 성능으로 추정하고, 상수를 제거하면 O(n)이 된다.

✔️ 결론

이론과 달리 실제 성능은 요소의 순차적 접근 속도, 메모리 할당 및 해제 비용, CPU 캐시 활용도 등 다양한 요소에 의해 영향을 받는다. 또한 ArrayList가 데이터를 하나씩 미는 대신 메모리 고속 복사를 이용하기도 한다. 특히 ArrayList는 메모리 상에서 연속적으로 위치하기 때문에 CPU 캐시 효율이 좋고, 메모리 접근 속도가 빠르다. 반면, LinkedList 는 각 요소가 별도의 객체로 존재하고 다음 요소의 참조를 저장하기 때문에 CPU 캐시 효율이 떨어지고, 메모리 접근 속도가 상대적으로 느려질 수 있다.

=> 배열 리스트가 성능상 유리하다!

Hash

List와 Set의 차이는 다음과 같다.

List : 순서를 유지하며, 중복을 허용하는 자료구조. 인덱스를 통해 각 요소에 접근할 수 있다.
- ex. 장바구니 목록, 순서가 중요한 일련의 이벤트 목록.
Set : 순서를 유지하지 않으며, 중복을 허용하지 않는 자료구조. 요소의 유무를 빠르게 확인할 수 있도록 최적화 되어있어서 빠른 조회가 가능하다.
- ex. 회원 ID 집합, 고유한 항목의 집합.

직접 구현한 Set은 다음과 같다. 데이터 추가, 삭제, 확인만 하면 간단하게 구현할 수 있다. 단, Set은 중복을 허용하지 않기 때문에 데이터를 추가할 때 contains() 메서드로 중복 여부를 체크해줘야 한다.

public class MyHashSetV0 {

    private int[] elementData = new int[10];
    private int size = 0;

    // O(n) - contains() 메서드 때문
    public boolean add(int value) {
        // 중복 값 체크
        if (contains(value)) {
            return false;
        }
        elementData[size] = value;
        size++;
        return true;
    }

    // O(n) - for문으로 하나하나 찾아야 함
    public boolean contains(int value) {
        for (int data : elementData) {
            if (data == value) {
                return true;
            }
        }
        return false;
    }

    public int size() {
        return size;
    }

    @Override
    public String toString() {
        return "MyHashSetV0{" +
                "elementData=" + Arrays.toString(Arrays.copyOf(elementData, size)) +
                ", size=" + size +
                '}';
    }
}

이렇게 만든 Set은 데이터 추가, 검색 모두 O(n)으로 성능이 좋지 않다. 데이터를 추가할 때마다 중복 데이터가 있는지 체크하기 위해 Set의 전체 데이터를 확인해야 한다. 이런 문제는 해시 알고리즘을 사용하면 해결할 수 있다.

해시 알고리즘

배열에서 데이터를 검색할 때는 하나하나 비교해야하기 때문에 O(n)의 시간이 걸리고, 배열의 장점인 인덱스를 사용할 수 없다. 왜냐하면 인덱스와 데이터의 값이 서로 다르기 때문이다. 인덱스로 검색을 하려면 다음 코드와 같이 데이터 값을 인덱스 번호로 사용하면 된다. 이렇게 하면 인덱스로 바로 데이터를 찾을 수 있어 O(1)의 시간이 걸린다.

Integer[] inputArray = new Integer[10];
inputArray[1] = 1;
inputArray[2] = 2;
inputArray[5] = 8;
inputArray[8] = 8;

위의 배열을 출력하면 이렇게 나올 것이다. 찾는 것은 바로 찾을 수 있겠지만, 수많은 null 값들이 매우 거슬린다. 만약 99라는 값이 들어간다면, 배열은 입력 값의 범위 만큼 큰 배열을 사용해야 한다. 따라서 낭비되는 공간이 많이 발생한다.

inputArray = [null, 1, 2, null, null, 5, null, null, 8, null]

이런 문제는 나머지 연산을 통해 해결할 수 있다. 배열의 크기에 맞추어 나머지 연산을 한 결과는 다음과 같다. 이렇게 하면 0 ~ 9 범위로 인덱스 값이 나온다. 이렇게 배열의 인덱스로 사용할 수 있도록 원래의 값을 계산한 인덱스를 해시 인덱스(hashIndex)라 한다.

1 % 10 = 1
2 % 10 = 2
5 % 10 = 5
8 % 10 = 8
14 % 10 = 4
99 % 10 = 9

다음과 같이 나머지 연산을 하는 hashIndex() 메서드와 해시 인덱스를 이용해 값을 추가하는 add() 메서드를 구현했다. 넣을 때 hashIndex() 메서드를 통해 나온 값에 데이터를 넣고, 검색을 할 때도 검색하고자 하는 값을 hashIndex() 메서드에 넣어 해시 인덱스를 구하면 된다.

private static void add(Integer[] inputArray, int value) {
    int hashIndex = hashIndex(value);
    inputArray[hashIndex] = value;
}

static int hashIndex(int value) {
    return value % CAPACITY;
}

하지만 여기에도 한계가 있다. 바로 해시 충돌이 날 수 있다는 것이다. 만약 9와 99를 입력한다면 둘 다 10으로 나눈 나머지가 9이기 때문에 덮어씌워져 마지막에 저장한 값만 남게 된다.

99 % 10 = 9
9 % 10 = 9

이 문제를 해결하기 위해 배열의 크기를 늘리는 방법도 있겠지만 위에서 보았듯이 메모리 낭비가 심해질 것이다. 따라서 해시 충돌이 낮을 확률로 일어날 수 있다고 인정하고 같은 해시 인덱스의 값을 같은 인덱스에 저장하면 문제를 해결할 수 있다. 배열 안에 또 다른 배열(혹은 리스트)를 만들어 같은 해시 인덱스 값을 가진 데이터를 저장한다. 다음 코드는 LinkedList를 사용해 해시 충돌이 일어날 경우를 대비한 코드이다.

private static void add(LinkedList<Integer>[] buckets, int value) {
    int hashIndex = hashIndex(value);
    LinkedList<Integer> bucket = buckets[hashIndex]; // O(1)
    if (!bucket.contains(value)) { // 중복 체크 - O(n)
        bucket.add(value);
    }
}

private static boolean contains(LinkedList<Integer>[] buckets, int searchValue {
    int hashIndex = hashIndex(searchValue);
    LinkedList<Integer> bucket = buckets[hashIndex]; // O(1)
    return bucket.contains(searchValue); // O(n)
}

static int hashIndex(int value) {
    return value % CAPACITY;
}

데이터를 검색할 때는 LinkedList의 contains() 메서드를 이용해 모든 항목을 다 순회하면서 찾는 데이터가 있는지 확인한다. 따라서 O(n)의 성능이고, 해시 충돌이 발생하지 않아 데이터가 1개만 들어있는 경우에만 O(1)의 성능이다.

정리
해시 인덱스를 사용할 때 최악의 경우는 거의 발생하지 않고, 대부분 O(1)의 빠른 성능을 제공한다.

데이터 저장
- 평균: O(1)
- 최악: O(n)
데이터 조회
- 평균: O(1)
- 최악: O(n)