이 글은 2026년 07월 01일 작성된 글입니다.

Docker를 학습하며 이미지 빌드, 레이어와 캐시, 데이터베이스 컨테이너, Spring Boot 배포, 멀티 스테이지 빌드까지 학습했다. 특히 Docker를 이용한 실제 배포 환경과 이미지 최적화 방법을 중심으로 정리했다.

1. Docker 이미지와 캐시

Docker 이미지는 여러 개의 레이어(Layer)로 구성되며, 각 레이어는 변경할 수 없는(Immutable) 구조를 가진다.

핵심

• Dockerfile의 명령어마다 새로운 레이어 생성
• 변경되지 않은 레이어는 캐시 재사용
• 변경된 레이어 이후는 다시 빌드
• 자주 변경되는 내용은 아래쪽에 배치

FROM nginx:latest
COPY source/web /web
RUN apt-get update

2. 여러 사이트를 포함한 이미지 생성

하나의 Nginx 이미지에서 여러 사이트를 동시에 서비스할 수 있다.

핵심

• 하나의 이미지에 site1, site2, site3 포함
• 여러 포트를 각각 다른 사이트에 연결
• 설정 변경 후 이미지 재빌드

COPY source/web /web
COPY vhost.conf /etc/nginx/conf.d/

3. docker history

이미지가 어떤 레이어로 만들어졌는지 확인할 수 있다.

핵심

• 레이어 확인
• 이미지 생성 과정 추적
• 이미지 최적화 분석

docker history myimage

4. Dockerfile 최적화

Docker는 캐시를 최대한 활용하도록 설계되어 있다.

핵심

• 변경이 적은 작업은 위쪽
• 변경이 많은 작업은 아래쪽
• 캐시 효율 증가
• 빌드 속도 향상

5. 캐시 동작 방식

중간 단계에서 캐시가 깨지면 이후 단계도 모두 새로 실행된다.

핵심

• 특정 레이어 변경
• 이후 레이어 전부 재빌드
• Dockerfile 순서가 중요

6. 캐시 비활성화

캐시 없이 새롭게 이미지를 빌드할 수 있다.

핵심

• 모든 단계 새로 실행
• 테스트 시 유용

docker build --no-cache .

7. Oracle, PostgreSQL, Redis 컨테이너

Docker로 다양한 데이터베이스를 쉽게 실행할 수 있다.

핵심

• Oracle 11g
• PostgreSQL
• Redis
• 포트와 볼륨 설정
• DBeaver 연동 가능

docker run -p 5432:5432 postgres

8. Redis 특징

Redis는 메모리 기반 Key-Value 데이터베이스이다.

핵심

• 캐시 서버
• 세션 저장
• 메시지 큐
• 매우 빠른 조회 속도

9. Java 컴파일과 JAR 실행

컨테이너에서도 Java를 직접 컴파일하고 실행할 수 있다.

핵심

• javac 컴파일
• jar 생성
• java -jar 실행

javac Main.java
java Main
java -jar app.jar

10. Gradle 빌드

Gradle을 이용하면 프로젝트를 자동으로 빌드할 수 있다.

핵심

• 의존성 관리
• JAR 생성
• 자동 빌드

gradle build

11. Spring Boot 실행

Gradle 컨테이너에서 Spring 프로젝트를 빌드하고 실행할 수 있다.

핵심

• Git Clone
• Gradle Build
• JAR 실행
• 포트 매핑

java -jar app.jar

12. 빌드 서버와 운영 서버 분리

빌드는 빌드 서버에서, 실행은 운영 서버에서 수행하는 것이 일반적이다.

핵심

• 역할 분리
• 운영 서버 경량화
• 보안 향상
• 성능 향상

13. docker cp · 바인드 마운트 · 볼륨

빌드 결과물을 운영 서버로 전달하는 여러 방법을 학습했다.

핵심

• docker cp
• Bind Mount
• Docker Volume
• JAR 공유

14. 실행 전용 Docker 이미지

빌드된 JAR만 포함하는 이미지를 만들면 어디서든 실행 가능하다.

핵심

• GraalVM 기반
• JAR 포함
• 즉시 실행 가능

FROM graalvm:21

COPY app.jar /app/app.jar

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

15. 멀티 스테이지 빌드

빌드와 실행 환경을 하나의 Dockerfile에서 관리할 수 있다.

핵심

• Build Stage
• Runtime Stage
• 빌드 도구 제거
• 이미지 크기 감소

FROM gradle AS builder

RUN gradle build

FROM graalvm

COPY --from=builder ...

빌드 흐름

소스코드
    ↓
Build Stage
    ↓
JAR 생성
    ↓
Runtime Stage
    ↓
최종 이미지

16. 멀티 스테이지 장점

복잡했던 배포 과정을 Dockerfile 하나로 단순화할 수 있다.

핵심

• docker cp 불필요
• 별도 빌드 컨테이너 불필요
• Dockerfile 하나로 빌드
• 운영 이미지 최소화

✅ 정리

• Docker 이미지는 여러 개의 레이어로 구성되며 변경되지 않은 레이어는 캐시를 재사용한다.
• Dockerfile은 변경이 적은 명령을 위쪽에 배치할수록 빌드 속도를 높일 수 있다.
• docker history를 통해 이미지의 레이어 구조를 확인하고 최적화할 수 있다.
• Oracle, PostgreSQL, Redis를 Docker 컨테이너로 손쉽게 구축하고 개발 환경에서 활용할 수 있다.
• Gradle을 이용해 Spring Boot 프로젝트를 빌드하고 JAR 파일을 생성할 수 있다.
• 빌드 서버와 운영 서버를 분리하면 보안과 성능 측면에서 유리하다.
• docker cp, 바인드 마운트, Docker Volume을 이용해 빌드 결과물을 다양한 방식으로 공유할 수 있다.
• 실행에 필요한 JAR만 포함한 Docker 이미지를 만들면 어디서든 동일한 환경에서 실행할 수 있다.
• 멀티 스테이지 빌드를 사용하면 빌드와 실행 환경을 하나의 Dockerfile로 관리하면서 이미지 크기와 배포 과정을 모두 최적화할 수 있다.

이 글은 2026년 06월 30일 작성된 글입니다.

Docker를 학습하면서 컨테이너의 포트 매핑부터 네트워크 통신, 바인드 마운트, Dockerfile 작성, 이미지 빌드와 레이어 구조까지 학습했다. 특히 컨테이너 간 통신 방식과 Docker Image가 생성되는 과정을 중심으로 정리했다.

1. 포트 매핑

Docker 컨테이너는 외부와 격리되어 실행되므로, 서비스를 외부에서 사용하려면 포트를 연결해야 한다.

핵심

• -p : 호스트 포트와 컨테이너 포트를 직접 연결
• -P : 노출된 포트를 임의의 호스트 포트에 자동 연결
• 외부에서 서비스에 접근하려면 포트 매핑이 필수이다.

docker run -d -p 8080:80 nginx

2. 컨테이너 정보 확인

실행 중인 컨테이너의 설정과 네트워크 정보를 확인할 수 있다.

핵심

• 컨테이너 ID 확인
• IP 주소 확인
• 포트 매핑 확인
• 환경 변수 및 실행 정보 확인

docker inspect mynginx

특정 정보만 확인할 수도 있다.

docker inspect mynginx | grep '"IPAddress"'

3. 컨테이너 내부 작업

실행 중인 컨테이너에 접속하거나 파일을 복사할 수 있다.

핵심

• docker exec : 컨테이너 내부 명령 실행
• docker cp : 호스트 ↔ 컨테이너 파일 복사
• 웹루트에 HTML을 추가하여 즉시 서비스 가능

docker exec -it mynginx bash

docker cp index.html mynginx:/usr/share/nginx/html/

4. 바인드 마운트

호스트 디렉터리와 컨테이너 디렉터리를 연결하는 기능이다.

핵심

• 호스트에서 수정하면 즉시 반영
• 컨테이너 삭제 후에도 파일 유지
• 개발 환경에서 매우 유용

docker run \
-v ./html:/usr/share/nginx/html

장점

• 실시간 반영
• 파일 유지
• 코드 관리 편리

5. 컨테이너 네트워크

컨테이너끼리 다양한 방법으로 통신할 수 있다.

핵심

• 기본 Bridge Network 제공
• 사용자 정의 Network 생성 가능
• IP 또는 컨테이너 이름으로 통신 가능

docker network create common

통신 방식

6. docker exec와 docker cp 활용

컨테이너 내부를 직접 수정하지 않아도 필요한 파일을 쉽게 관리할 수 있다.

핵심

• 컨테이너 접속 없이 파일 복사 가능
• 호스트와 컨테이너 간 양방향 복사 지원
• 웹 리소스 관리에 자주 사용

docker cp sub.html mynginx:/usr/share/nginx/html/

7. Docker Image와 Dockerfile

Docker 이미지는 애플리케이션뿐 아니라 실행 환경까지 함께 포함하는 패키지이다.

핵심

• 실행 환경까지 함께 배포
• Dockerfile을 기반으로 이미지 생성
• 동일한 환경을 어디서나 재현 가능

FROM nginx:latest

COPY source/index.html /usr/share/nginx/html/

이미지 생성

docker build -t myname/nginx:1 .

8. Docker Image Layer

Docker 이미지는 여러 개의 Layer로 구성된다.

핵심

• 모든 Layer는 Immutable(불변)
• Dockerfile 한 줄마다 Layer 생성
• 변경되지 않은 Layer는 재사용

FROM nginx:latest
COPY source/index.html /usr/share/nginx/html/
RUN apt-get update

주요 Layer

9. Docker Cache

Docker는 변경되지 않은 Layer를 캐시하여 빌드 시간을 줄인다.

핵심

• 변경된 Layer부터 다시 빌드
• 이전 Layer는 그대로 재사용
• Dockerfile 작성 순서가 중요

예시

FROM
 ↓
COPY
 ↓
RUN

• COPY가 변경되면 이후 RUN도 다시 실행된다.
• 아무것도 변경되지 않았다면 모든 Layer가 캐시를 사용한다.

✅ 정리

• Docker 컨테이너는 포트 매핑을 통해 외부와 통신할 수 있다.
• docker inspect, docker exec, docker cp를 이용하면 실행 중인 컨테이너를 쉽게 관리할 수 있다.
• 바인드 마운트를 사용하면 호스트와 컨테이너가 동일한 파일을 공유하여 개발이 편리해진다.
• 사용자 정의 네트워크를 사용하면 컨테이너 이름만으로도 통신할 수 있다.
• host.docker.internal을 이용하면 컨테이너에서 호스트 OS의 서비스에도 접근할 수 있다.
• Docker Image는 애플리케이션뿐 아니라 실행 환경까지 함께 포함하여 동일한 실행 환경을 보장한다.
• Dockerfile의 각 명령은 하나의 Layer를 생성하며, Layer 구조 덕분에 캐시를 효율적으로 활용할 수 있다.
• Docker의 네트워크와 이미지 구조를 이해하면 개발과 배포 환경을 더욱 안정적으로 관리할 수 있다.

이 글은 2025년 06월 29일 작성된 글입니다.

백엔드 개발에서는 리눅스 환경을 자주 사용하기 때문에 Bash Shell 명령어를 익혀두는 것이 중요하다. 이번에는 파일과 디렉토리 관리, VIM, 파이프, 이동 및 복사 등 Bash Shell의 기본 명령어와 실습 내용을 정리했다.

1. Bash Shell이란?

Bash(Bourne Again SHell)는 리눅스와 macOS에서 기본적으로 사용하는 명령어 인터프리터(Shell)이다.

핵심

• 터미널에서 명령어를 실행하는 프로그램
• 리눅스 및 macOS 기본 Shell
• 파일 및 디렉토리 관리
• 프로그램 실행 및 시스템 관리

2. 파일 및 디렉토리 조회

핵심

• 현재 위치 확인

• 파일 목록 조회

• 숨김 파일 확인

• 화면 초기화

  명령어 설명

  ---

  pwd 현재 위치 출력 ls 파일 목록 출력 ls -l 상세 목록 출력 ll ls -l 축약형 ls -al 숨김 파일까지 출력 clear 화면 지우기

pwd
ls
ls -al
clear

3. 디렉토리 이동

핵심

• 홈 디렉토리 이동
• 절대경로 이동
• 상대경로 이동
• 상위 디렉토리 이동

cd ~
cd /폴더명
cd ./폴더명
cd ..
cd .

4. 파일과 디렉토리 생성

핵심

• 파일 생성
• 디렉토리 생성
• 여러 디렉토리 생성

touch memo.txt
mkdir test
mkdir -p a/b/c/d

5. 파일 및 디렉토리 삭제

핵심

• 파일 삭제
• 빈 디렉토리 삭제
• 강제 삭제
• 와일드카드 사용

rm memo.txt
rm *
rmdir test
rm -rf test

숨김 파일

touch .hidden
ls -al
rm .hidden

6. echo와 리다이렉션

핵심

• 화면 출력
• 덮어쓰기
• 이어쓰기

echo "Hello"
echo "Hello" > test.txt
echo "World" >> test.txt
cat test.txt

기호 의미

> 덮어쓰기 >> 이어쓰기

7. VIM

핵심

• 입력 모드

• 명령 모드

• 저장

• 저장 없이 종료

  명령 설명

  ---

  a 입력 모드 ESC 명령 모드 :wq 저장 후 종료 :q! 저장 없이 종료

8. 파이프

핵심

• 명령어 연결
• 원하는 결과만 추출
• 파일 저장

history | fgrep ls
ps -aux | fgrep sshd
history | fgrep mkdir > mk_history.txt

9. 파일 이동 및 복사

핵심

• 파일 이동
• 이름 변경
• 파일 복사
• 디렉토리 복사

mv aaa folder
cp aaa bbb
cp -r folder backup

10. 압축

핵심

• 압축
• 압축 해제

zip file.zip a.txt b.txt
unzip file.zip

11. 자주 사용하는 명령어

기능 명령어

현재 위치 pwd 파일 조회 ls, ls -al 이동 cd 파일 생성 touch 폴더 생성 mkdir 삭제 rm, rm -rf 내용 출력 cat 문자열 출력 echo 편집 vim 이동 mv 복사 cp 압축 zip

✅ 정리

• Bash Shell은 운영체제와 상호작용하기 위한 기본 Shell 프로그램이다.
• ls, cd, pwd를 이용하여 파일과 디렉토리를 조회하고 이동할 수 있다.
• touch, mkdir, rm, rm -rf를 이용하여 파일과 디렉토리를 생성하거나 삭제할 수 있다.
• echo, cat, 리다이렉션을 이용하여 파일 내용을 관리할 수 있다.
• VIM에서는 입력 모드와 명령 모드를 전환하여 파일을 편집할 수 있다.
• 파이프(|)를 사용하면 여러 명령어를 연결하여 원하는 결과만 추출할 수 있다.
• mv와 cp를 이용하여 파일과 디렉토리를 이동하거나 복사할 수 있다.
• Bash 기본 명령어는 백엔드 개발과 리눅스 서버 운영의 기초이다.

이 글은 2026년 06월 26일 작성된 글입니다.

Bash Shell은 리눅스와 macOS에서 사용하는 기본 명령어 인터프리터이다. 백엔드 개발에서는 서버 접속, 파일 관리, Git 사용 등 대부분의 작업을 터미널에서 수행하기 때문에 Bash 명령어를 익혀두는 것이 중요하다.

1. Bash Shell이란?

Bash(Bourne Again SHell)는 사용자가 입력한 명령어를 운영체제가 이해할 수 있도록 전달하는 명령어 인터프리터(Shell)이다.

터미널을 통해 파일 관리, 프로그램 실행, 서버 관리 등 다양한 작업을 수행할 수 있다.

핵심

• 운영체제와 사용자를 연결하는 CLI(Command Line Interface) 환경이다.
• 리눅스와 macOS에서 기본적으로 사용되는 Shell이다.
• 백엔드 개발과 서버 운영에서 가장 많이 사용하는 도구이다.

pwd
ls
cd

2. 파일 및 디렉토리 조회

현재 위치를 확인하거나 파일 및 디렉토리 목록을 조회할 때 사용하는 명령어이다.

핵심

• pwd는 현재 작업 중인 디렉토리를 확인한다.
• ls -al은 숨김 파일까지 모두 출력한다.

pwd
ls
ls -al
clear

3. 디렉토리 이동

디렉토리를 이동할 때 사용하는 명령어이다.

핵심

• cd ~는 홈 디렉토리로 이동한다.
• cd ..는 상위 디렉토리로 이동한다.
• 절대경로와 상대경로를 모두 사용할 수 있다.

cd ~
cd ..
cd project
cd /Users/minhyuk/project

절대경로와 상대경로

4. 파일 및 디렉토리 생성

파일과 디렉토리를 생성할 때 사용하는 명령어이다.

핵심

• touch는 빈 파일을 생성한다.
• mkdir는 디렉토리를 생성한다.
• mkdir -p는 중간 경로까지 한 번에 생성한다.

touch test.txt

mkdir project

mkdir -p a/b/c

5. 파일 및 디렉토리 삭제

파일과 디렉토리를 삭제할 때 사용하는 명령어이다.

핵심

• rm은 파일을 삭제한다.
• rmdir은 비어있는 디렉토리만 삭제할 수 있다.
• rm -rf는 디렉토리를 강제로 삭제한다.

rm test.txt

rmdir project

rm -rf project

삭제 명령어 비교

6. echo와 리다이렉션

echo는 문자열을 출력하거나 파일에 저장할 때 사용한다.

핵심

• >는 기존 내용을 덮어쓴다.
• >>는 기존 내용 뒤에 이어서 작성한다.

echo "Hello"

echo "Hello" > test.txt

echo "World" >> test.txt

리다이렉션

7. cat 명령어

파일의 내용을 출력할 때 사용하는 명령어이다.

핵심

• 파일 내용을 빠르게 확인할 수 있다.
• 텍스트 파일 확인 시 가장 많이 사용하는 명령어이다.

cat test.txt

8. VIM 편집기

VIM은 터미널 환경에서 사용하는 대표적인 텍스트 편집기이다.

핵심

• 입력 모드와 명령 모드를 구분하여 사용한다.
• 저장과 종료 명령을 익혀두면 대부분의 작업이 가능하다.

a      입력 모드

ESC    명령 모드

:wq    저장 후 종료

:q!    저장하지 않고 종료

9. Pipe와 fgrep

Pipe(|)는 앞 명령어의 실행 결과를 다음 명령어의 입력으로 전달한다.

fgrep은 특정 문자열이 포함된 결과만 필터링할 때 사용한다.

핵심

• 여러 명령어를 연결하여 사용할 수 있다.
• 원하는 결과만 추출할 수 있다.

history | fgrep mkdir

ps -aux | fgrep sshd

ls -al | less

동작 흐름

명령어 실행
      ↓
Pipe(|)
      ↓
fgrep / less
      ↓
필요한 결과만 출력

10. 파일 이동 및 복사

파일이나 디렉토리를 이동하거나 복사할 때 사용하는 명령어이다.

핵심

• mv는 이동과 이름 변경을 모두 수행한다.
• 디렉토리 복사는 cp -r 옵션이 필요하다.

mv aaa bbb

cp aaa ccc

cp -r folder1 folder2

11. ZIP 압축

파일을 압축하거나 압축을 해제할 때 사용하는 명령어이다.

핵심

• 여러 파일을 하나의 ZIP 파일로 압축할 수 있다.
• unzip으로 쉽게 압축을 해제할 수 있다.

zip files.zip a.txt b.txt

unzip files.zip

12. 파일 권한(Permission)

리눅스에서는 파일과 디렉토리에 읽기(Read), 쓰기(Write), 실행(Execute) 권한이 존재한다.

핵심

• r, w, x 권한으로 구성된다.
• chmod를 이용해 권한을 변경할 수 있다.

chmod 755 run.sh

권한 숫자

권한 예시

-rwxr-xr-x

• 첫 글자가 d이면 디렉토리이다.
• 첫 글자가 -이면 일반 파일이다.

✅ 정리

• Bash Shell은 운영체제와 사용자가 명령어로 상호작용할 수 있도록 도와주는 명령어 인터프리터이다.
• pwd, ls, cd는 파일과 디렉토리를 탐색할 때 가장 기본이 되는 명령어이다.
• touch, mkdir, rm, rm -rf를 이용해 파일과 디렉토리를 생성하고 삭제할 수 있다.
• echo, cat, 리다이렉션을 이용하면 파일을 생성하고 내용을 저장하거나 확인할 수 있다.
• VIM은 터미널 환경에서 자주 사용하는 텍스트 편집기로 입력 모드와 명령 모드를 구분해서 사용한다.
• Pipe와 fgrep을 활용하면 여러 명령어를 연결하여 원하는 결과만 효율적으로 추출할 수 있다.
• mv, cp, zip, chmod는 파일 관리와 서버 작업에서 자주 사용하는 핵심 명령어이다.

2026.06.11 ~ 06.24 | 팀 프로젝트 | 4인 개발

프로젝트 소개

Wedge는 예비부부(CLIENT)와 웨딩 전문 프리랜서(FREELANCER)를 연결하는 매칭 플랫폼이다.

웨딩홀 패키지에 묶여 있으면 비싸고 선택지도 좁다. 반대로 프리랜서 입장에서는 실력이 있어도 홍보 채널이 없으면 일감을 못 찾는다. Wedge는 이 둘을 직접 연결하는 구조다. 핵심 차별점은 역경매 방식: 예비부부가 구인글을 올리면 프리랜서가 직접 제안서를 내고, 부부가 마음에 드는 제안을 수락하면 예약이 자동 생성된다.

기능 범위가 꽤 넓었다. 인증, 프로필, 포트폴리오, 북마크, 예약, 실시간 채팅, 리뷰, 커뮤니티, 구인/제안, AI 챗봇, CI/CD까지 — 이걸 2주 안에 4명이 완성해야 했다.

배포 URL: wedge-tawny.vercel.app
시연 영상: streamable.com/6dklaq

팀원과 역할 분담

내가 맡은 파트 — 기술적 결정들

1. 인증 시스템: JWT + RTR + OAuth2

인증은 대부분의 기능이 의존하는 뿌리라서 가장 먼저, 가장 꼼꼼하게 설계했다.

RTR(Refresh Token Rotation)

일반 JWT 구조에서 Refresh Token이 탈취되면, 만료될 때까지 공격자가 계속 쓸 수 있다. RTR을 적용하면 토큰을 사용할 때마다 새 토큰으로 교체되므로, 탈취 피해를 최소화할 수 있다.

구현 방식은 간단하다. Redis에 memberId를 키로 Refresh Token 1개만 유지한다. save()를 호출하면 기존 토큰이 덮어써지면서 자동으로 무효화된다. 누가 먼저 쓰든 나머지 한쪽은 차단된다.

refreshTokenRepository.save(RefreshToken.builder()
    .memberId(memberId)
    .token(newRefreshToken)  // upsert — 기존 토큰 자동 무효화
    .build());

이메일 인증 상태 머신

Redis 키를 두 개로 분리했다: 인증 코드(TTL 5분)와 완료 플래그(TTL 30분). 역할과 만료 시간이 다르기 때문에 하나로 합칠 수 없다. 인증 코드 검증 즉시 삭제해서 1회용을 보장하고, 회원가입 완료 시 플래그도 삭제해서 중복 가입을 차단한다. DB 대신 Redis를 쓴 이유는 TTL 덕에 만료 배치 작업이 필요 없고, 조회도 ~1ms로 빠르기 때문이다.

OAuth2 (Google + Kakao) 통합

구글과 카카오는 JSON 응답 구조가 다르다. providerId, email, name의 경로가 제각각이다. OAuth2MemberService.loadUser()에서 provider별 파싱만 다르게 처리하고, 그 이후는 동일한 Member 엔티티로 통합했다. 프론트엔드는 로그인 경로와 상관없이 JWT 하나로만 통신한다.

2. Mixed Content & Caddy 리버스 프록시

배포 직전에 생각지 못한 문제가 터졌다. Vercel(HTTPS)에서 AWS EC2(HTTP, 8080) API를 호출하니 브라우저가 Mixed Content 정책으로 전부 차단했다.

브라우저 → Vercel(HTTPS) → AWS EC2:8080(HTTP) ← 차단!

해결책은 Caddy였다.

api.wedge.o-r.kr {
    reverse_proxy localhost:8080
}

이 두 줄이 전부다. 도메인을 적으면 Caddy가 Let's Encrypt에서 인증서를 자동 발급하고, 만료 30일 전에 알아서 갱신한다.

브라우저 → Vercel(HTTPS) → Caddy(HTTPS, 443) → Spring Boot(HTTP, 8080)

Spring Boot에 SSL을 직접 붙이면 keystore 설정, 인증서 갱신 시 재시작이 필요한데, Caddy로 분리하면 그 복잡함이 사라진다. 2주짜리 프로젝트에서 인프라에 쓸 수 있는 시간은 제한적이었고, Caddy 덕분에 인프라 세팅 시간을 크게 줄일 수 있었다.

3. CI/CD 파이프라인

dev 브랜치에 push되면 CI가 돌고, main에 머지되면 자동 배포된다.

CI: GitHub Actions가 MySQL 8.0 + Redis 서비스 컨테이너를 직접 띄워서 통합 테스트를 돌린다. Mock이 아니라 실제 DB에 쿼리를 날린다. 테스트가 하나라도 실패하면 PR 머지가 차단된다.

CD: bootJar 빌드 → Docker 이미지 빌드 → Docker Hub 푸시(latest + commit SHA 태그) → SSH로 EC2 접속 → 컨테이너 교체.

EC2에서 직접 Gradle 빌드하면 t2.micro(메모리 1GB)가 OOM으로 죽는다. 그래서 GitHub Actions에서 빌드해서 완성된 이미지만 EC2로 당겨오는 구조를 택했다. commit SHA 태그를 따로 붙여두는 이유는 롤백을 위해서다. latest만 있으면 이전 버전으로 돌아가기 어렵다.

Docker 멀티 스테이지 빌드도 적용했다. Stage 1(JDK + Gradle)에서 빌드하고, Stage 2(JRE만)에서 jar를 복사해 실행한다. 최종 이미지에 JDK와 소스코드가 들어가지 않아서 이미지가 ~300MB 가벼워진다.

배포 흐름 전체:

조직 레포 dev → main 머지
    ↓ (포크 자동 동기화)
개인 포크 main 업데이트
    ↓ (CD 트리거)
GitHub Actions: 빌드 → Docker Hub
    ↓ (SSH)
AWS EC2: pull → 컨테이너 교체 → 완료

4. 구인/제안 시스템

구인글에서 제안서 수락까지 이어지는 흐름을 설계했다. 제안서가 수락되면 예약이 자동 생성된다. DB 제약도 꼼꼼하게 걸었다: 구인글 동시 등록 최대 3건, 제안서 동시 제출 최대 5건. 마감된 구인글은 수정 차단, proposals 테이블에 (recruit_post_id, freelancer_profile_id) 복합 UNIQUE 키로 중복 제안을 막았다.

5. 커뮤니티 게시판

REVIEW/TIP 카테고리로 분리된 커뮤니티 게시판을 구현했다. 소프트 삭제(is_deleted)를 적용해서 데이터는 남기고 노출만 끄는 구조다. 후반에 이미지 첨부 기능과 프리랜서 언급 기능까지 추가됐다.

팀 협업: 잘 된 것들

Git 전략이 단순하고 명확했다. dev 브랜치에서 기능 브랜치를 따고, PR을 통해 합쳤다. CI가 붙어 있으니 깨진 코드가 dev에 섞이는 일이 거의 없었다.

역할 분리가 깔끔했다. 백엔드 4명이 도메인 단위로 나눠서 작업했는데, 인터페이스(API 스펙)만 맞추면 서로 크게 충돌하지 않았다. 프론트는 이민서 님이 디자인 시스템과 마이페이지를 담당하면서 UI 일관성을 잡아줬다.

Mock 없이 통합 테스트. CI에서 실제 MySQL과 Redis를 띄워서 테스트했기 때문에 "로컬에서는 됐는데 서버에서 안 됨" 같은 상황이 훨씬 줄었다.

아쉬운 것들

t2.micro의 한계. 메모리 1GB로 MySQL + Redis + Spring Boot를 동시에 돌리니 가끔 OOM이 났다. Swap 2GB를 추가해서 겨우 버텼는데, 실제 서비스라면 인스턴스 스펙을 올려야 한다.

테스트 커버리지. CI에서 통합 테스트를 돌리긴 했지만, 작성된 테스트의 양이 충분하지 않았다. 빠르게 기능을 만드는 데 집중하다 보니 엣지 케이스 테스트가 부족했다.

AI 기능과 채팅이 후순위로 밀렸다. 원래 MVP 우선순위에서 하위였던 기능들이 마지막에 붙었다. 완성은 됐지만 더 다듬을 시간이 없었다.

배포 자동화의 빈틈. 조직 레포 → 개인 포크 동기화를 GitHub Actions로 자동화했는데, 간혹 sync가 늦거나 실패하는 케이스가 있었다. 더 견고한 파이프라인이 필요하다.

배운 것

2주는 생각보다 훨씬 짧다. 기능을 처음부터 완벽하게 만들려고 하면 아무것도 완성되지 않는다. MVP 우선순위를 정하고, 핵심이 아닌 것은 과감하게 뒤로 미루는 판단이 중요했다.

인증 시스템은 프로젝트 초반에 완성도 있게 설계해두길 잘했다. 모든 기능이 인증에 의존하기 때문에, 이게 불안정하면 팀 전체가 흔들린다.

Caddy는 정말 좋은 도구다. 단, ACME 챌린지를 위해 80포트가 열려 있어야 한다는 걸 처음에 몰라서 삽질했다.

CI/CD를 처음부터 구성해둔 게 팀 전체 생산성에 크게 기여했다. 수동으로 배포하느라 시간을 쓰지 않아도 됐고, 테스트가 자동으로 돌아가니 서로 코드를 합치는 데 덜 불안했다.

마무리

2주 안에 이 정도 규모의 서비스를 완성한 게 신기하게 느껴진다. 팀원 각자가 맡은 영역을 끝까지 책임졌고, 덕분에 배포 URL이 실제로 돌아간다.

다음에는 테스트 커버리지를 처음부터 챙기면서 만들고 싶다.

GitHub | 배포 URL | 시연 영상

이 글은 2025년 06월 09일 작성된 글입니다.

Spring Security를 프로젝트에 적용하면서 CustomAuthenticationFilter, SecurityContext, JWT 인증, 인가 처리, CORS 설정까지 학습했다. 기존에 직접 구현하던 인증/인가 로직을 Spring Security가 이해할 수 있도록 연결하는 과정에 집중했다.

1. CustomAuthenticationFilter 인증 처리

Spring Security가 JWT와 apiKey를 이해하지 못하기 때문에 필터를 추가하여 먼저 인증을 수행하도록 구현했다.

핵심

• CustomAuthenticationFilter는 UsernamePasswordAuthenticationFilter 이전에 실행된다.
• accessToken 또는 apiKey가 존재하면 인증을 수행한다.
• 로그인하지 않은 요청도 통과시켜야 한다.
• 인증이 필요한지 여부는 이후 Spring Security가 판단한다.

if (accessToken != null || apiKey != null) {
    // 인증 처리
}

인증 흐름

사용자 요청
    ↓
CustomAuthenticationFilter
    ↓
UsernamePasswordAuthenticationFilter
    ↓
인가 처리
    ↓
Controller

2. 필터에서 예외 처리

필터는 컨트롤러보다 먼저 실행되기 때문에 ControllerAdvice가 처리할 수 없다.

핵심

• 필터 내부에서 직접 예외 처리 필요
• 인증 실패 시 즉시 응답 반환
• 컨트롤러 진입 전에 요청 차단 가능

try {
    // 인증 처리
} catch (Exception e) {
    response.setStatus(401);
}

3. SecurityContext 이해

Spring Security는 현재 요청 사용자의 정보를 SecurityContext에 저장한다.

핵심

• 인증 성공 후 사용자 정보 저장
• 인가 과정에서 권한 체크
• 요청 종료 시 자동 제거

SecurityContextHolder
    .getContext()
    .setAuthentication(authentication);

동작 순서

요청
 ↓
인증
 ↓
SecurityContext 저장
 ↓
인가
 ↓
Controller 실행
 ↓
SecurityContext 제거

4. SecurityUser 도입

Spring Security 기본 User 클래스에는 프로젝트에서 필요한 id, nickname 정보가 없다.

핵심

• UserDetails 구현
• id 저장 가능
• nickname 저장 가능
• Principal에서 Member 복원 가능

public class SecurityUser implements UserDetails {
    private Long id;
    private String nickname;
}

5. 선언적 인가 처리

기존에 컨트롤러에서 직접 권한을 검사하던 방식을 제거하고 Security 설정으로 이동했다.

핵심

• 관리자 API 접근 제한
• 인증 사용자 접근 제한
• Security 설정에서 일괄 관리

.requestMatchers("/api/*/adm/**")
.hasRole("ADMIN")

URL 패턴

*   → 한 단계
**  → 여러 단계

/api/*/adm/**

예시

/api/v1/adm/members
/api/v2/adm/posts/1
/api/test/adm/stats/today

6. 인증된 사용자 복원

CustomAuthenticationFilter가 인증을 끝냈기 때문에 Rq에서 다시 인증할 필요가 없어졌다.

변경 전

Rq.getActor()
    -> 직접 인증

변경 후

SecurityContext
    -> Principal
    -> Member 복원

핵심

• 인증은 필터에서 1회 수행
• 컨트롤러는 인증 결과만 사용
• 중복 제거

7. REST API 보안 설정

REST API에서 사용하지 않는 Security 기능을 비활성화했다.

핵심

• Form Login 비활성화
• Session 인증 비활성화
• HTTP Basic 비활성화
• Stateless 구조 사용

http
    .formLogin(form -> form.disable())
    .httpBasic(httpBasic -> httpBasic.disable());

8. 쿠키 보안 강화

apiKey 쿠키에 보안 옵션을 추가했다.

핵심

• HttpOnly
• Secure
• SameSite=Strict
• MaxAge=1년

cookie.setHttpOnly(true);
cookie.setSecure(true);
cookie.setMaxAge(31536000);

SameSite 옵션

9. CORS 설정

프론트엔드와 백엔드가 서로 다른 도메인에서 통신할 수 있도록 설정했다.

핵심

• 허용 Origin 설정
• 허용 Header 설정
• 허용 Method 설정

configuration.addAllowedOrigin("http://localhost:3000");

10. @WithUserDetails 활용

테스트 코드에서 인증 관련 반복 코드를 제거했다.

기존

.header("Authorization", "Bearer ...")

변경

@WithUserDetails("user1")

핵심

• 테스트 코드 단순화
• 인증 사용자 자동 생성
• UserDetailsService 필요

11. 로그 레벨 설정

개발 환경에서는 DEBUG 로그를 사용하도록 설정했다.

로그 레벨

logging:
  level:
    com.back: DEBUG

12. 순환참조 문제 해결

SecurityConfig, Filter, MemberService, Rq 사이에서 순환참조가 발생했다.

문제

CustomAuthenticationFilter
 ↓
Rq
 ↓
MemberService
 ↓
SecurityConfig
 ↓
CustomAuthenticationFilter

해결

• 의존성 구조 재설계
• 순환 의존 제거
• Security 설정 분리

✅ 정리

• CustomAuthenticationFilter를 추가하여 JWT와 apiKey 인증을 Spring Security 앞단에서 처리했다.
• 인증 성공 시 SecurityContext에 사용자 정보를 저장하여 Spring Security가 이해할 수 있도록 연결했다.
• SecurityUser를 도입하여 id와 nickname 같은 사용자 정보를 함께 관리할 수 있게 되었다.
• 관리자 권한과 인증 여부를 Security 설정으로 이동하여 선언적으로 인가를 처리하게 되었다.
• REST API 환경에 맞게 Form Login, Session 인증 등을 비활성화하고 Stateless 구조를 구성했다.
• 쿠키에 Secure, HttpOnly, SameSite 옵션을 적용하여 보안을 강화했다.
• @WithUserDetails를 사용하여 테스트 코드의 인증 관련 보일러플레이트를 제거했다.
• Spring Security의 필터 체인 구조와 인증·인가 흐름을 실제 프로젝트에 맞게 커스터마이징하는 방법을 학습했다.

이 글은 2026년 06월 08일 작성된 글입니다.

오늘은 기존 API Key 인증 구조에서 Spring Security 기반 인증/인가 구조로 넘어가는 과정을 정리했다.
관리자 API, 권한 체크, Security Filter, 비밀번호 암호화, JWT Access Token 도입 흐름까지 학습했다.

1. 최신성이 필요한 데이터는 DB 조회가 필요하다

내 정보 조회처럼 항상 최신 데이터가 필요한 경우에는 토큰에 담긴 정보만 믿지 않고 DB를 다시 조회해야 한다.

Member member = memberService.findById(actor.getId())
        .orElseThrow(() -> new ServiceException("401-1", "존재하지 않는 회원입니다."));

토큰은 요청자를 식별하는 데 사용할 수 있지만, 닉네임이나 권한처럼 변경될 수 있는 정보는 DB에서 최신 상태를 확인하는 것이 안전하다.

2. 관리자용 API 구현

관리자 전용 회원 조회 API와 게시물 통계 API를 구현했다.

GET /api/v1/adm/members
GET /api/v1/adm/members/{id}
GET /api/v1/adm/posts/count

관리자 API는 일반 사용자 API와 구분하기 위해 /adm 경로를 사용했다.

3. 관리자 권한 체크

관리자 API는 관리자 권한을 가진 사용자만 접근할 수 있도록 제한했다.

.andExpect(status().isForbidden())
.andExpect(jsonPath("$.resultCode").value("403-1"))
.andExpect(jsonPath("$.msg").value("권한이 없습니다."));

권한이 없는 사용자가 관리자 API를 호출하면 403 Forbidden 응답을 반환한다.

4. 인증과 인가

인증은 요청을 보낸 사용자가 누구인지 확인하는 과정이다.

이 요청을 보낸 너는 누구니?

인가는 인증된 사용자가 해당 URL에 접근할 권한이 있는지 확인하는 과정이다.

너는 이 API에 접근할 권한이 있니?

스프링 시큐리티에서 말하는 인가는 주로 URL 접근 권한 체크를 의미한다.

5. Spring Security 설치

Spring Security 의존성을 추가했다.

implementation("org.springframework.boot:spring-boot-starter-security")
testImplementation("org.springframework.security:spring-security-test")

Spring Security는 인증과 인가를 필터 기반으로 처리하는 보안 프레임워크다.

6. Spring Security 기본 동작

Spring Security를 추가하면 기본적으로 모든 요청을 보호한다.

즉, 별도 설정이 없으면 로그인하지 않은 사용자는 대부분의 요청에 접근할 수 없다.

REST API와 JWT를 사용하는 경우에는 프로젝트 방식에 맞게 직접 커스터마이징해야 한다.

7. Security 설정

REST API 프로젝트에 맞게 Security 설정을 수정했다.

csrf.disable();

또한 개발 편의를 위해 h2-console 접근을 허용했다.

REST API에서는 보통 세션 기반 폼 로그인이 아니라 토큰 인증을 사용하므로 CSRF 설정을 비활성화하는 경우가 많다.

8. CSRF와 SameSite

CSRF는 사용자가 의도하지 않은 요청을 브라우저가 대신 보내게 만드는 공격이다.

REST API에서는 보통 Authorization 헤더 기반 토큰 인증을 사용하고, 쿠키를 쓰더라도 SameSite 옵션을 함께 사용한다.

9. Security Filter

Spring Security는 컨트롤러가 실행되기 전에 필터에서 먼저 동작한다.

요청
→ Security Filter
→ Controller

권한이 없으면 컨트롤러 액션 메서드는 실행되지 않는다.

10. 커스텀 인증 필터가 필요한 이유

Spring Security는 기본적으로 우리가 만든 JWT, apiKey, refreshToken 구조를 알지 못한다.

따라서 우리가 만든 인증 방식을 Spring Security가 이해할 수 있는 형태로 바꿔주는 커스텀 필터가 필요하다.

JWT / apiKey
→ CustomAuthenticationFilter
→ Spring Security 인증 객체

11. UsernamePasswordAuthenticationFilter 이전에 실행

커스텀 필터는 Spring Security의 기본 인증 필터보다 먼저 실행되도록 등록한다.

addFilterBefore(customAuthenticationFilter, UsernamePasswordAuthenticationFilter.class)

이렇게 해야 이후 Security 과정에서 인증된 사용자로 판단할 수 있다.

12. 비밀번호 암호화

비밀번호는 복호화가 불가능한 방식으로 암호화해서 저장해야 한다.

로그인 시에는 사용자가 입력한 비밀번호를 같은 방식으로 암호화한 뒤 저장된 값과 비교한다.

입력 비밀번호 → 암호화 → 저장된 암호화 값과 비교

비밀번호 원문을 저장하지 않기 때문에 DB가 유출되어도 피해를 줄일 수 있다.

13. 로그 레벨

Spring Boot의 기본 로그 레벨은 INFO다.

개발이나 테스트 환경에서는 DEBUG 레벨로 낮추면 더 자세한 로그를 확인할 수 있다.

운영 환경에서는 보통 INFO 이상만 출력한다.

14. 인증이 필요 없는 요청은 패스

로그인, 회원가입, 공개 API처럼 인증이 필요 없는 요청은 커스텀 필터에서 통과시켜야 한다.

인증 필요 없음 → pass
인증 필요함 → accessToken / apiKey 검사

15. Access Token과 apiKey

기존 apiKey 방식은 매 요청마다 DB 조회가 필요했다.

SELECT * FROM member WHERE apiKey = ?

JWT 기반 Access Token을 사용하면 서버가 시크릿 키로 토큰을 검증할 수 있어 DB 조회 없이 인증할 수 있다.

16. Access Token과 Refresh Token

기존 apiKey는 Refresh Token 역할로 사용하고, JWT는 Access Token 역할로 사용할 예정이다.

17. JWT 라이브러리 추가

JWT 처리를 위해 jjwt 라이브러리를 추가했다.

implementation("io.jsonwebtoken:jjwt-api:0.12.6")
runtimeOnly("io.jsonwebtoken:jjwt-impl:0.12.6")
runtimeOnly("io.jsonwebtoken:jjwt-jackson:0.12.6")

18. JWT 생성에 필요한 정보

JWT를 만들기 위해서는 다음 정보가 필요하다.

• SecretKey
• 서명 알고리즘
• Claims
• 발급 시간
• 만료 시간

Claims에는 사용자 id, username 같은 인증에 필요한 데이터를 담을 수 있다.

19. JWT는 암호화가 아니다

JWT는 암호화가 아니라 인코딩이다.

즉, 누구나 JWT 내용을 디코딩해서 확인할 수 있다.

JWT = Base64 인코딩된 토큰

따라서 비밀번호 같은 민감 정보는 절대 JWT에 넣으면 안 된다.

20. 순환참조 문제

커스텀 필터를 추가하는 과정에서 순환참조 문제가 발생했다.

customAuthenticationFilter
→ rq
→ memberService
→ securityConfig
→ customAuthenticationFilter

스프링은 순환참조를 기본적으로 허용하지 않기 때문에 의존성 구조를 재설계해야 한다.

✅ 정리

• 관리자 API는 일반 API와 분리하고 관리자 권한 체크를 적용해야 한다.
• Spring Security는 필터 기반으로 컨트롤러 실행 전에 인증과 인가를 처리한다.
• REST API + JWT 구조에서는 커스텀 필터를 통해 Spring Security가 이해할 수 있는 인증 객체를 만들어야 한다.
• 비밀번호는 복호화가 불가능한 방식으로 암호화해서 저장해야 한다.
• Access Token은 DB 조회 없이 빠르게 인증할 수 있고, Refresh Token은 재발급과 폐기에 사용된다.
• JWT는 암호화가 아니라 인코딩이므로 민감 정보를 담으면 안 된다.
• 순환참조가 발생하면 빈 의존성 구조를 다시 정리해야 한다.

이 글은 2026년 06월 05일 작성된 글입니다.

오늘은 API Key 기반 인증을 쿠키 기반 인증으로 확장하고, JWT(JSON Web Token)를 이용한 Access Token 구조를 학습했다. 또한 OpenAPI와 Postman에서 인증을 처리하는 방법, 인증(Authentication)과 인가(Authorization)의 흐름을 정리했다.

1. API Key 쿠키 자동 전송

모든 요청에서 apiKey 쿠키가 자동으로 전송되도록 리팩토링했다.

핵심

• 인증 정보 전달 코드 중복 제거
• Rq 클래스로 쿠키 처리 로직 이동
• 모든 요청에 apiKey 쿠키 자동 포함

2. Cookie 기반 인증 추가

기존 Authorization 헤더 인증 외에 Cookie 기반 인증도 지원하도록 개선했다.

.cookie(new Cookie("apiKey", apiKey))

핵심

• Authorization 헤더 인증 지원
• Cookie 인증 지원
• 인증 방식 다중화

3. getActor 리팩토링

인증 정보 조회 로직을 정리하여 가독성과 재사용성을 높였다.

핵심

• 인증 관련 코드 분리
• 중복 제거
• 유지보수성 향상

4. Rq 클래스 개선

공통 요청 처리 기능을 Rq 클래스로 이동했다.

private String getHeader(String name, String defaultValue) {
    return Optional
            .ofNullable(req.getHeader(name))
            .filter(headerValue -> !headerValue.isBlank())
            .orElse(defaultValue);
}

핵심

• getHeader 추가
• getCookieValue 추가
• Optional 활용
• null 처리 개선

5. Rq 클래스와 쿠키 정리

Rq 클래스

• 컨트롤러 공통 로직 담당
• HttpServletRequest 래핑
• HttpServletResponse 래핑
• HttpSession 래핑
• 파사드(Facade) 패턴 적용

쿠키 특징

• 쿠키 관리는 브라우저가 담당
• 서버는 Set-Cookie 응답만 전달
• 브라우저가 쿠키를 저장
• 이후 요청 시 자동 전송
• 동일 도메인에서만 사용 가능

6. 개발 환경용 API Key 설정

개발 편의를 위해 샘플 회원의 apiKey와 username을 동일하게 설정했다.

핵심

• 개발환경(dev) 전용 적용
• 운영환경(prod) 제외
• 테스트 편의성 향상

7. static 필드 의존성 주입

Spring은 static 필드 직접 주입을 지원하지 않는다.

해결 방법

• setter 메서드 생성
• @Autowired 적용
• setter 내부에서 static 필드 초기화

AppConfig 활용

AppConfig.isDev()

핵심

• Environment 직접 주입 불필요
• 가독성 향상
• 편리한 환경 체크

8. 로그아웃 구현

HttpOnly 쿠키를 삭제하는 로그아웃 기능을 구현했다.

assertThat(apiKeyCookie.getMaxAge()).isEqualTo(0);

핵심

• DELETE 요청 사용
• Set-Cookie 응답 전송
• Max-Age=0 설정
• 브라우저가 자동 삭제

9. OpenAPI에서 로그인/로그아웃

Swagger(OpenAPI) 환경에서도 로그인과 로그아웃이 가능하도록 설정했다.

핵심

• 로그인 시 apiKey 쿠키 생성
• API 테스트 가능
• 로그아웃 시 쿠키 삭제

10. @SecurityScheme 적용

OpenAPI에서 Authorization 헤더를 직접 입력할 수 있도록 설정했다.

@SecurityScheme

핵심

• Swagger 인증 지원
• Bearer Token 입력 가능
• API 테스트 편의성 향상

11. 인증 흐름 정리

인증 정보 우선순위

1. Authorization 헤더
2. Cookie(apiKey)

핵심

• 헤더 인증 우선
• 쿠키 인증 보조
• 둘 다 없으면 인증 실패

12. JWT 기반 Access Token 도입

기존 apiKey 방식의 단점을 해결하기 위해 JWT 기반 Access Token을 도입한다.

기존 방식

SELECT * FROM member WHERE apiKey = ?

문제점

• 매 요청마다 DB 조회
• 서버 부하 증가

13. Access Token과 Refresh Token

핵심

• JWT = Access Token
• apiKey = Refresh Token
• 인증 성능 향상

14. JWT 특징

JWT(JSON Web Token)는 인증 정보를 담은 토큰이다.

JWT 구성 요소

• Header
• Payload(Claims)
• Signature

핵심

• 서버 저장 불필요
• Stateless 인증
• DB 조회 없음
• 빠른 인증 처리

15. JWT 라이브러리 추가

implementation("io.jsonwebtoken:jjwt-api:0.12.6")
runtimeOnly("io.jsonwebtoken:jjwt-impl:0.12.6")
runtimeOnly("io.jsonwebtoken:jjwt-jackson:0.12.6")

핵심

• JWT 생성
• JWT 검증
• JWT 파싱

16. JWT 생성 테스트

JWT를 생성하고 디코딩하여 내부 데이터를 확인했다.

JWT에 포함되는 정보

• 사용자 정보
• 발급 시간(iat)
• 만료 시간(exp)
• 기타 Claims

주의사항

JWT는 암호화가 아니다.

JWT는 Base64 인코딩이므로 누구나 내용을 확인할 수 있다.

따라서 비밀번호와 같은 민감 정보는 절대 저장하면 안 된다.

✅ 정리

• API Key 인증을 Cookie 기반 인증으로 확장하였다.
• Authorization 헤더와 Cookie 인증을 모두 지원하도록 개선하였다.
• Rq 클래스로 요청 처리 공통 로직을 분리하였다.
• OpenAPI에서도 로그인과 로그아웃을 수행할 수 있도록 설정하였다.
• JWT 기반 Access Token 구조를 도입하기 위한 기반 작업을 진행하였다.
• JWT는 서버 저장 없이 검증 가능한 Stateless 인증 방식이다.
• 기존 apiKey는 Refresh Token 역할로 활용할 예정이다.

이 글은 2026년 06월 01일 작성된 글입니다.

오늘은 API Key 기반 인증을 쿠키 기반 인증으로 확장하고, JWT(JSON Web Token)를 이용한 Access Token 구조를 학습했다. 또한 OpenAPI와 Postman에서 인증을 처리하는 방법, 인증(Authentication)과 인가(Authorization)의 흐름을 정리했다.

1. API Key 쿠키 자동 전송

모든 요청에서 apiKey 쿠키가 자동으로 전송되도록 리팩토링했다.

핵심

• 인증 정보 전달 코드 중복 제거
• Rq 클래스로 쿠키 처리 로직 이동
• 모든 요청에 apiKey 쿠키 자동 포함

2. Cookie 기반 인증 추가

기존 Authorization 헤더 인증 외에 Cookie 기반 인증도 지원하도록 개선했다.

.cookie(new Cookie("apiKey", apiKey))

핵심

• Authorization 헤더 인증 지원
• Cookie 인증 지원
• 인증 방식 다중화

3. getActor 리팩토링

인증 정보 조회 로직을 정리하여 가독성과 재사용성을 높였다.

핵심

• 인증 관련 코드 분리
• 중복 제거
• 유지보수성 향상

4. Rq 클래스 개선

공통 요청 처리 기능을 Rq 클래스로 이동했다.

private String getHeader(String name, String defaultValue) {
    return Optional
            .ofNullable(req.getHeader(name))
            .filter(headerValue -> !headerValue.isBlank())
            .orElse(defaultValue);
}

핵심

• getHeader 추가
• getCookieValue 추가
• Optional 활용
• null 처리 개선

5. Rq 클래스와 쿠키 정리

Rq 클래스

• 컨트롤러 공통 로직 담당
• HttpServletRequest 래핑
• HttpServletResponse 래핑
• HttpSession 래핑
• 파사드(Facade) 패턴 적용

쿠키 특징

• 쿠키 관리는 브라우저가 담당
• 서버는 Set-Cookie 응답만 전달
• 브라우저가 쿠키를 저장
• 이후 요청 시 자동 전송
• 동일 도메인에서만 사용 가능

6. 개발 환경용 API Key 설정

개발 편의를 위해 샘플 회원의 apiKey와 username을 동일하게 설정했다.

핵심

• 개발환경(dev) 전용 적용
• 운영환경(prod) 제외
• 테스트 편의성 향상

7. static 필드 의존성 주입

Spring은 static 필드 직접 주입을 지원하지 않는다.

해결 방법

• setter 메서드 생성
• @Autowired 적용
• setter 내부에서 static 필드 초기화

AppConfig 활용

AppConfig.isDev()

핵심

• Environment 직접 주입 불필요
• 가독성 향상
• 편리한 환경 체크

8. 로그아웃 구현

HttpOnly 쿠키를 삭제하는 로그아웃 기능을 구현했다.

assertThat(apiKeyCookie.getMaxAge()).isEqualTo(0);

핵심

• DELETE 요청 사용
• Set-Cookie 응답 전송
• Max-Age=0 설정
• 브라우저가 자동 삭제

9. OpenAPI에서 로그인/로그아웃

Swagger(OpenAPI) 환경에서도 로그인과 로그아웃이 가능하도록 설정했다.

핵심

• 로그인 시 apiKey 쿠키 생성
• API 테스트 가능
• 로그아웃 시 쿠키 삭제

10. @SecurityScheme 적용

OpenAPI에서 Authorization 헤더를 직접 입력할 수 있도록 설정했다.

@SecurityScheme

핵심

• Swagger 인증 지원
• Bearer Token 입력 가능
• API 테스트 편의성 향상

11. 인증 흐름 정리

인증 정보 우선순위

1. Authorization 헤더
2. Cookie(apiKey)

핵심

• 헤더 인증 우선
• 쿠키 인증 보조
• 둘 다 없으면 인증 실패

12. JWT 기반 Access Token 도입

기존 apiKey 방식의 단점을 해결하기 위해 JWT 기반 Access Token을 도입한다.

기존 방식

SELECT * FROM member WHERE apiKey = ?

문제점

• 매 요청마다 DB 조회
• 서버 부하 증가

13. Access Token과 Refresh Token

핵심

• JWT = Access Token
• apiKey = Refresh Token
• 인증 성능 향상

14. JWT 특징

JWT(JSON Web Token)는 인증 정보를 담은 토큰이다.

JWT 구성 요소

• Header
• Payload(Claims)
• Signature

핵심

• 서버 저장 불필요
• Stateless 인증
• DB 조회 없음
• 빠른 인증 처리

15. JWT 라이브러리 추가

implementation("io.jsonwebtoken:jjwt-api:0.12.6")
runtimeOnly("io.jsonwebtoken:jjwt-impl:0.12.6")
runtimeOnly("io.jsonwebtoken:jjwt-jackson:0.12.6")

핵심

• JWT 생성
• JWT 검증
• JWT 파싱

16. JWT 생성 테스트

JWT를 생성하고 디코딩하여 내부 데이터를 확인했다.

JWT에 포함되는 정보

• 사용자 정보
• 발급 시간(iat)
• 만료 시간(exp)
• 기타 Claims

주의사항

JWT는 암호화가 아니다.

JWT는 Base64 인코딩이므로 누구나 내용을 확인할 수 있다.

따라서 비밀번호와 같은 민감 정보는 절대 저장하면 안 된다.

✅ 정리

• API Key 인증을 Cookie 기반 인증으로 확장하였다.
• Authorization 헤더와 Cookie 인증을 모두 지원하도록 개선하였다.
• Rq 클래스로 요청 처리 공통 로직을 분리하였다.
• OpenAPI에서도 로그인과 로그아웃을 수행할 수 있도록 설정하였다.
• JWT 기반 Access Token 구조를 도입하기 위한 기반 작업을 진행하였다.
• JWT는 서버 저장 없이 검증 가능한 Stateless 인증 방식이다.
• 기존 apiKey는 Refresh Token 역할로 활용할 예정이다.

이 글은 2026년 06월 02일 작성된 글입니다.

오늘은 REST API 인증(Authentication)과 인가(Authorization)를 구현하며 API Key 기반 인증 구조를 적용했다. 또한 회원가입, 로그인 API를 구현하고 Postman을 활용한 인증 테스트 방법을 학습했다.

1. DTO 변경 시 테스트도 함께 수정

DTO 구조가 변경되면 API 응답 형식도 변경되므로 테스트 코드 역시 함께 수정해야 한다.

핵심

• DTO 변경 시 테스트 코드도 수정
• 응답 JSON 검증 유지
• 테스트와 실제 API 스펙 동기화

2. username/password 인증 방식

초기에는 글 작성 시 username과 password를 요청 파라미터로 전달하여 사용자를 식별했다.

{
  "username": "user1",
  "password": "1234"
}

문제점

• 매 요청마다 인증정보 전송
• 클라이언트에 비밀번호 저장 필요
• 보안상 위험
• 요청 데이터가 불필요하게 커짐

3. ServiceException과 전역 예외 처리

오류 응답 형식을 통일하기 위해 ServiceException을 도입하고 GlobalExceptionHandler에서 처리했다.

핵심

• 예외 응답 형식 통일
• 중복 코드 제거
• 유지보수성 향상

4. API Key 인증 방식 도입

username/password 대신 apiKey를 사용하도록 구조를 변경했다.

@Column(unique = true)
private String apiKey;

핵심

• 회원마다 고유 API Key 발급
• 비밀번호 대신 API Key 사용
• 클라이언트에는 API Key만 저장

5. API Key 방식의 장점

핵심

• 비밀번호 노출 위험 감소
• 사용자 비밀번호 저장 불필요
• 인증정보 관리 단순화
• 피해 범위 축소 가능

6. 회원가입 API 구현

회원가입 기능을 테스트 코드와 함께 구현했다.

POST /api/v1/members

핵심

• 회원 생성
• username 중복 검사
• 서비스 계층으로 검증 로직 이동

7. 로그인 API 구현

로그인 성공 시 API Key를 반환하도록 구현했다.

POST /api/v1/members/login

응답 예시

{
  "resultCode": "200-1",
  "msg": "유저1님 환영합니다.",
  "data": {
    "apiKey": "..."
  }
}

핵심

• 로그인 성공 시 API Key 반환
• 이후 요청에서 API Key 사용

8. Postman API Key 자동 저장

로그인 성공 후 API Key를 자동으로 컬렉션 변수에 저장하도록 설정했다.

const apiKey = pm.response.json()?.data?.apiKey;

if (apiKey) {
    pm.collectionVariables.set("apiKey", apiKey);
}

핵심

• 로그인 후 자동 갱신
• 수동 복사 제거
• 테스트 편의성 향상

9. Authorization 헤더 사용

인증정보를 요청 파라미터가 아닌 HTTP 헤더에 저장하도록 변경했다.

Authorization: Bearer {apiKey}

핵심

• REST API 표준 방식
• 인증정보와 요청 데이터 분리
• 보안성 향상

10. @RequestHeader 활용

@RequestHeader("Authorization")
String authorization

핵심

• HTTP 헤더 값 주입
• Authorization 헤더 처리
• Bearer Token 인증 구현

11. 인증정보 상속 구조(Postman)

Postman에서는 인증정보를 상위 레벨에서 설정할 수 있다.

핵심

• Collection → Folder → Request 순서 상속
• 중복 설정 제거
• 유지보수 편리

12. 인증(Authentication)과 인가(Authorization)

인증

사용자가 누구인지 확인하는 과정

예시

• 로그인
• API Key 검증
• 토큰 검증

인가

인증된 사용자의 권한을 확인하는 과정

예시

• 본인 글만 수정 가능
• 본인 댓글만 삭제 가능

13. 글 수정 권한 체크

글 작성자만 수정 가능하도록 인가 로직을 추가했다.

핵심

• API Key 인증
• 작성자 검증
• 권한 없는 접근 차단

14. 글 삭제 권한 체크

글 작성자만 삭제 가능하도록 수정했다.

핵심

• 작성자 검증
• 권한 체크
• 테스트 코드 수정

15. 댓글 API 인증 적용

댓글 등록 역시 API Key 인증 기반으로 변경했다.

핵심

• 댓글 작성 인증
• API Key 기반 사용자 식별
• 테스트 코드 수정

✅ 정리

• username/password 방식 대신 API Key 인증 구조를 도입했다.
• ServiceException과 GlobalExceptionHandler로 예외 응답을 통일했다.
• 회원가입과 로그인 API를 구현하고 API Key를 발급하도록 만들었다.
• Authorization 헤더를 활용하여 인증정보를 표준 방식으로 전달하도록 변경했다.
• Postman 컬렉션 변수를 활용해 API Key를 자동 관리할 수 있게 만들었다.
• 글과 댓글 수정·삭제 시 작성자 권한 검사를 통해 인가 기능을 구현했다.

이 글은 2026년 06월 01일 작성된 글입니다.

오늘은 REST API 인증(Authentication)과 인가(Authorization)를 구현하며 API Key 기반 인증 구조를 적용했다. 또한 회원가입, 로그인 API를 구현하고 Postman을 활용한 인증 테스트 방법을 학습했다.

1. DTO 변경 시 테스트도 함께 수정

DTO 구조가 변경되면 API 응답 형식도 변경되므로 테스트 코드 역시 함께 수정해야 한다.

핵심

• DTO 변경 시 테스트 코드도 수정
• 응답 JSON 검증 유지
• 테스트와 실제 API 스펙 동기화

2. username/password 인증 방식

초기에는 글 작성 시 username과 password를 요청 파라미터로 전달하여 사용자를 식별했다.

{
  "username": "user1",
  "password": "1234"
}

문제점

• 매 요청마다 인증정보 전송
• 클라이언트에 비밀번호 저장 필요
• 보안상 위험
• 요청 데이터가 불필요하게 커짐

3. ServiceException과 전역 예외 처리

오류 응답 형식을 통일하기 위해 ServiceException을 도입하고 GlobalExceptionHandler에서 처리했다.

핵심

• 예외 응답 형식 통일
• 중복 코드 제거
• 유지보수성 향상

4. API Key 인증 방식 도입

username/password 대신 apiKey를 사용하도록 구조를 변경했다.

@Column(unique = true)
private String apiKey;

핵심

• 회원마다 고유 API Key 발급
• 비밀번호 대신 API Key 사용
• 클라이언트에는 API Key만 저장

5. API Key 방식의 장점

핵심

• 비밀번호 노출 위험 감소
• 사용자 비밀번호 저장 불필요
• 인증정보 관리 단순화
• 피해 범위 축소 가능

6. 회원가입 API 구현

회원가입 기능을 테스트 코드와 함께 구현했다.

POST /api/v1/members

핵심

• 회원 생성
• username 중복 검사
• 서비스 계층으로 검증 로직 이동

7. 로그인 API 구현

로그인 성공 시 API Key를 반환하도록 구현했다.

POST /api/v1/members/login

응답 예시

{
  "resultCode": "200-1",
  "msg": "유저1님 환영합니다.",
  "data": {
    "apiKey": "..."
  }
}

핵심

• 로그인 성공 시 API Key 반환
• 이후 요청에서 API Key 사용

8. Postman API Key 자동 저장

로그인 성공 후 API Key를 자동으로 컬렉션 변수에 저장하도록 설정했다.

const apiKey = pm.response.json()?.data?.apiKey;

if (apiKey) {
    pm.collectionVariables.set("apiKey", apiKey);
}

핵심

• 로그인 후 자동 갱신
• 수동 복사 제거
• 테스트 편의성 향상

9. Authorization 헤더 사용

인증정보를 요청 파라미터가 아닌 HTTP 헤더에 저장하도록 변경했다.

Authorization: Bearer {apiKey}

핵심

• REST API 표준 방식
• 인증정보와 요청 데이터 분리
• 보안성 향상

10. @RequestHeader 활용

@RequestHeader("Authorization")
String authorization

핵심

• HTTP 헤더 값 주입
• Authorization 헤더 처리
• Bearer Token 인증 구현

11. 인증정보 상속 구조(Postman)

Postman에서는 인증정보를 상위 레벨에서 설정할 수 있다.

핵심

• Collection → Folder → Request 순서 상속
• 중복 설정 제거
• 유지보수 편리

12. 인증(Authentication)과 인가(Authorization)

인증

사용자가 누구인지 확인하는 과정

예시

• 로그인
• API Key 검증
• 토큰 검증

인가

인증된 사용자의 권한을 확인하는 과정

예시

• 본인 글만 수정 가능
• 본인 댓글만 삭제 가능

13. 글 수정 권한 체크

글 작성자만 수정 가능하도록 인가 로직을 추가했다.

핵심

• API Key 인증
• 작성자 검증
• 권한 없는 접근 차단

14. 글 삭제 권한 체크

글 작성자만 삭제 가능하도록 수정했다.

핵심

• 작성자 검증
• 권한 체크
• 테스트 코드 수정

15. 댓글 API 인증 적용

댓글 등록 역시 API Key 인증 기반으로 변경했다.

핵심

• 댓글 작성 인증
• API Key 기반 사용자 식별
• 테스트 코드 수정

✅ 정리

• username/password 방식 대신 API Key 인증 구조를 도입했다.
• ServiceException과 GlobalExceptionHandler로 예외 응답을 통일했다.
• 회원가입과 로그인 API를 구현하고 API Key를 발급하도록 만들었다.
• Authorization 헤더를 활용하여 인증정보를 표준 방식으로 전달하도록 변경했다.
• Postman 컬렉션 변수를 활용해 API Key를 자동 관리할 수 있게 만들었다.
• 글과 댓글 수정·삭제 시 작성자 권한 검사를 통해 인가 기능을 구현했다.

이 글은 2026년 05월 29일 작성된 글입니다.

오늘은 Next.js 프론트엔드와 Spring Boot REST API를 연동하여 게시글과 댓글의 CRUD 기능을 구현했다. 또한 DTO 설계 원칙과 API 응답 구조에 대해 학습했다.

1. apiFetch 확장

기존 GET 요청만 처리하던 apiFetch 함수를 확장하여 POST 요청도 처리할 수 있도록 개선했다.

await apiFetch("/api/v1/posts", {
    method: "POST",
    body: JSON.stringify(data),
});

핵심

• GET, POST 요청을 공통 함수로 처리
• 기본 headers 설정 추가
• 중복 코드 감소

2. 게시글 작성 기능

게시글 작성 후 성공 메시지를 출력하고 상세 페이지로 이동하도록 구현했다.

router.replace(`/posts/${id}`);

핵심

• 작성 완료 후 상세 페이지 이동
• replace 사용으로 뒤로가기 시 작성 페이지 재진입 방지
• autofocus 적용

3. 게시글 삭제 기능

게시글 삭제 API와 연동하고 사용자 확인 절차를 추가했다.

if (confirm("정말 삭제하시겠습니까?")) {
    // 삭제 요청
}

핵심

• 삭제 전 확인 창 제공
• 삭제 완료 후 목록 페이지 이동

4. 게시글 수정 기능

수정 페이지를 구현하고 기존 데이터를 불러와 수정 API와 연동했다.

setTitle(post.title);
setContent(post.content);

핵심

• 수정 폼 구현
• 기존 데이터 자동 입력
• 수정 API 호출

5. 댓글 목록 조회

댓글 다건 조회 API를 연동하고 로딩 상태를 처리했다.

const [comments, setComments] = useState<PostCommentDto[] | null>(null);

핵심

• 댓글 목록 API 연동
• 로딩 상태 표시
• 댓글 DTO 타입 정의

6. 상태 초기값을 null로 두는 이유

const [comments, setComments] = useState<PostCommentDto[] | null>(null);

핵심

• null → 로딩 중
• [] → 데이터 없음

초기값을 빈 배열로 두면 로딩 중인지 데이터가 없는지 구분할 수 없다.

7. 댓글 삭제

댓글 삭제 후 상태값을 직접 수정하여 화면에 즉시 반영되도록 구현했다.

setComments(
    comments.filter(comment => comment.id !== id)
);

핵심

• 새로고침 없이 UI 갱신
• 상태 기반 렌더링 활용

8. 댓글 등록

댓글 작성 폼을 구현하고 등록 즉시 화면에 반영되도록 처리했다.

setComments([...comments, newComment]);

핵심

• 댓글 등록 API 연동
• 실시간 UI 갱신

9. DTO 설계 원칙

DTO에는 꼭 필요한 데이터만 포함해야 한다.

좋은 예시

{
    "id": 4,
    "authorName": "유저3",
    "content": "댓글 2-1"
}

좋지 않은 예시

{
    "author": {
        ...
    },
    "post": {
        ...
    }
}

핵심

• 최소 공개 원칙
• 필요한 데이터만 응답
• 엔티티 직접 노출 지양

10. 작성자 정보 추가

게시글과 댓글에 작성자 정보를 추가했다.

@ManyToOne
private Member author;

핵심

• 게시글 작성자 관리
• 댓글 작성자 관리
• DTO에는 authorName만 노출

✅ 정리

• apiFetch를 확장하여 GET과 POST 요청을 공통 처리할 수 있게 만들었다.
• 게시글 작성, 수정, 삭제 기능을 REST API와 연동했다.
• 댓글 조회, 등록, 삭제 기능을 구현하고 상태 변경으로 UI를 즉시 갱신했다.
• 상태 초기값을 null로 두어 로딩 상태와 빈 데이터를 구분할 수 있게 했다.
• DTO에는 필요한 데이터만 담아 최소 공개 원칙을 적용했다.
• 게시글과 댓글에 작성자 정보를 추가하여 데이터 구조를 확장했다.

이 글은 2026년 05월 28일 작성된 글입니다.

📌 오늘 배운 내용

오늘은 Next.js 기반 프론트엔드 프로젝트를 세팅하고, Spring Boot REST API 서버와 연동하여 게시글 목록/상세/작성 기능을 구현했다.
또한 서버 컴포넌트와 클라이언트 컴포넌트의 차이, fetch 기반 데이터 요청, 환경변수 관리, 동적 라우팅 등을 학습했다.

1. Next.js 프로젝트 생성 및 실행

프로젝트 생성

npx create-next-app@latest

실행

npm run dev

2. Prettier 설정

{
    "tabWidth": 4,
    "trailingComma": "all",
    "semi": false,
    "singleQuote": true
}

3. 서버 컴포넌트와 클라이언트 컴포넌트

'use client'

4. 글 목록 API 연동

useEffect(() => {
    fetch('http://localhost:8080/api/v1/posts')
        .then((res) => res.json())
        .then((data) => setPosts(data))
}, [])

5. 동적 라우팅

src/app/posts/[id]/page.tsx

6. Guard Clause 패턴

if (post == null) {
    return <div>로딩중...</div>
}

return <div>{post.title}</div>

7. 환경변수 사용

NEXT_PUBLIC_API_BASE_URL=http://localhost:8080

8. 실제 글 작성 API 요청

fetch(`${process.env.NEXT_PUBLIC_API_BASE_URL}/api/v1/posts`, {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({
        title: titleInput.value,
        content: contentInput.value,
    }),
})

✅ 정리

• Next.js App Router 기반 프로젝트 구조를 학습했다.
• 서버 컴포넌트와 클라이언트 컴포넌트의 차이를 이해했다.
• REST API 데이터를 fetch로 받아 렌더링했다.
• 동적 라우팅과 환경변수를 적용했다.
• POST 요청으로 실제 글 작성 기능을 구현했다.

이 글은 2026년 05월 27일 작성된 글입니다.

오늘은 REST API 테스트 강화와 Swagger 문서 자동화, 그리고 IoC 컨테이너 구조 확장을 진행했다.

1. 댓글 삭제 기능 구현

댓글 삭제 API를 구현했다.

@Transactional
public void delete(PostComment postComment)

2. orphanRemoval 과 더티체킹

@OneToMany(orphanRemoval = true)

@Transactional 이 있어야 더티체킹이 동작한다.

3. 조회 전용 트랜잭션

@Transactional(readOnly = true)

조회 메서드 성능 최적화 적용.

4. RsData 응답 구조

{
  "resultCode": "200-1",
  "msg": "댓글 삭제 완료"
}

공통 응답 구조 적용.

5. 제네릭 적용

RsData<PostDto>

타입 안정성 강화.

6. DELETE 메서드 적용

@DeleteMapping

REST 스타일로 개선.

7. POSTMAN 활용

/api/v1/posts

API 테스트 진행.

8. JSON 요청 처리

@RequestBody

JSON → 객체 자동 변환.

9. Validation 처리

@Valid

REST API에서는 BindingResult를 거의 사용하지 않는다.

10. SpringDoc 도입

implementation("org.springdoc:springdoc-openapi-starter-webmvc-ui:2.8.9")

Swagger 기반 OPEN API 문서 자동 생성.

11. Swagger UI

http://localhost:8080/swagger-ui/index.html

브라우저에서 API 테스트 가능.

12. CORS 처리

Access-Control-Allow-Origin

외부 fetch 요청 허용 설정.

IoC 컨테이너 확장

13. BeanDefinition 기반 구조

Map<String, BeanDefinition>

빈 생성 정보를 저장.

14. @Bean 메서드 기반 생성

new BeanDefinition<>(
    TestJacksonConfig.class,
    "testBaseJavaTimeModule"
)

메서드 기반 빈 생성 지원.

15. reflections 라이브러리 활용

implementation("org.reflections:reflections:0.10.2")

패키지 스캔 자동화 구현.

✅ 정리

• REST API에서는 상태코드와 응답 구조를 명확하게 관리하는 것이 중요하다.
• SpringDoc을 통해 Swagger 기반 문서를 자동 생성할 수 있었다.
• CORS 설정을 통해 다른 서버에서 오는 fetch 요청도 허용할 수 있었다.
• IoC 컨테이너는 BeanDefinition 기반 구조로 점점 실제 스프링과 비슷하게 발전하고 있다.

이 글은 2026년 05월 26일 작성된 글입니다.

오늘은 REST API 테스트를 더 정교하게 다듬고, 예외 처리와 HTTP 상태코드 처리, 그리고 IoC 컨테이너의 BeanDefinition 구조를 확장하는 작업을 진행했다.

1. 글 수정 테스트케이스 보강

글 수정 API 테스트를 더 강화했다.

기존에는 응답만 확인했다면, 이제는 실제로 수정된 데이터가 DB에 반영되었는지도 검증했다.

assertThat(post.getTitle()).isEqualTo("수정된 제목");

2. 테스트 검증 범위

REST API 테스트에서 어디까지 검증해야 하는지 기준을 정리했다.

필수

응답 JSON 구조와 필드값 검증

{
  "resultCode": "200-1",
  "msg": "글 수정 완료"
}

선택

실제 DB 조회 후 데이터 검증

Post post = postService.findById(1);

응답 구조 검증은 필수, DB 반영 여부까지 확인하는 것은 상황에 따라 선택이다.

3. 글 삭제 테스트

글 삭제 API 테스트를 추가했다.

mockMvc.perform(delete("/api/v1/posts/1"))

4. 단건 조회 테스트

단건 조회 테스트도 추가했다.

.andExpect(jsonPath("$.data.id").value(1))

5. 다건 조회 테스트

게시글 목록 조회 테스트를 구현했다.

.andExpect(jsonPath("$.data.length()").value(3))

6. Postman baseURL 변수

Postman Collection에 baseURL 변수를 추가했다.

{{baseURL}}/api/v1/posts

7. 존재하지 않는 글 조회

존재하지 않는 글 조회 시 404 응답을 반환하도록 수정했다.

return ResponseEntity.status(404).body(rsData);

8. Validation 예외 처리

제목 없이 글 작성 시 400 Bad Request가 발생하도록 구현했다.

@NotBlank
private String title;

9. MethodArgumentNotValidException 처리

유효성 검증 실패 시 발생하는 예외를 처리했다.

@ExceptionHandler(MethodArgumentNotValidException.class)

10. FieldError 메세지 처리

검증 에러를 문자열 형태로 정리했다.

.map(error -> error.getField()
        + "-" + error.getCode()
        + "-" + error.getDefaultMessage())

11. 잘못된 JSON 처리

JSON 형식이 잘못된 경우에도 400 응답을 반환하도록 처리했다.

12. 댓글 단건조회 테스트

댓글 API 테스트도 시작했다.

/api/v1/posts/1/comments/2

13. 댓글 다건조회 테스트

댓글 목록 조회 테스트 추가.

/api/v1/posts/1/comments

14. BeanDefinition 메서드 기반 생성

@Bean 메서드 기반 생성도 처리할 수 있도록 확장했다.

new BeanDefinition<>(
    TestJacksonConfig.class,
    "testBaseJavaTimeModule"
);

15. 생성 의존성이 있는 BeanDefinition

assertThat(beanDefinition.getParameterNames())
    .containsExactly("testBaseJavaTimeModule");

✅ 정리

• REST API 테스트에서는 응답 JSON 구조 검증이 가장 중요하다.
• Validation 예외는 MethodArgumentNotValidException으로 처리할 수 있다.
• ResponseEntity를 사용하면 상태코드와 응답 구조를 더 유연하게 관리할 수 있다.
• BeanDefinition이 확장되면서 @Bean 메서드 기반 빈 생성도 처리할 수 있게 되었다.

이 글은 2026년 05월 22일 작성된 글입니다.

오늘은 IoC 컨테이너의 @Bean 처리 구조와 REST API 응답 구조 개선, AOP, DTO 활용 기준, 그리고 컨트롤러 TDD 흐름까지 정리했다.

1. Jackson 라이브러리 추가

Java 객체를 JSON으로 변환하기 위해 Jackson 라이브러리를 추가했다.

implementation("com.fasterxml.jackson.core:jackson-databind:2.18.2")
implementation("com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.18.2")

jackson-datatype-jsr310은 LocalDateTime 같은 Java Time API 타입을 처리하기 위해 필요하다.

2. @Bean 어노테이션 추가

기존에는 @Component 계열 클래스만 빈으로 등록했다.

이제는 설정 클래스 안의 메서드에 @Bean을 붙여서 메서드의 반환 객체도 빈으로 등록할 수 있도록 구조를 확장했다.

@Configuration
public class TestJacksonConfig {
    @Bean
    public JavaTimeModule testBaseJavaTimeModule() {
        return new JavaTimeModule();
    }
}

3. ObjectMapper 빈 등록

ObjectMapper를 직접 생성하고, JavaTimeModule을 등록한 뒤 빈으로 관리하도록 했다.

@Bean
public ObjectMapper testBaseObjectMapper(JavaTimeModule testBaseJavaTimeModule) {
    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.registerModule(testBaseJavaTimeModule);
    return objectMapper;
}

이제 ObjectMapper도 IoC 컨테이너가 관리하는 객체가 되었다.

4. @Bean 의존관계 테스트

testBaseObjectMapper는 testBaseJavaTimeModule 빈에 의존한다.

@Test
@DisplayName("@Bean, testBaseJavaTimeModule 빈에 의존하는 testBaseObjectMapper 빈을 생성")
public void t8() {
    ObjectMapper testBaseObjectMapper = applicationContext.genBean("testBaseObjectMapper");

    assertThat(testBaseObjectMapper).isNotNull();
}

@Bean 메서드도 생성자 주입처럼 필요한 의존 빈을 매개변수로 받을 수 있다.

5. BeanDefinition 도입

빈 생성 방식이 늘어나면서 단순히 Class 정보만으로는 빈을 만들기 어려워졌다.

기존 방식:

• @Component 계열 클래스의 생성자 기반 빈 생성

새 방식:

• @Bean 메서드 기반 빈 생성

그래서 빈 생성에 필요한 정보를 담기 위한 BeanDefinition 클래스를 도입했다.

BeanDefinition<TestPostService> beanDefinition =
    new BeanDefinition<>(TestPostService.class);

6. BeanDefinition.getParameterNames()

BeanDefinition에서 빈 생성에 필요한 의존성 이름을 가져올 수 있게 했다.

String[] parameterNames = beanDefinition.getParameterNames();

테스트 예시:

assertThat(parameterNames).containsExactly("testPostRepository");

이를 통해 해당 빈을 만들기 위해 어떤 빈이 먼저 필요한지 알 수 있다.

7. BeanDefinition의 생성 방식 구분

BeanDefinition에 다음 기능을 추가했다.

beanDefinition.getBeanName();
beanDefinition.isCreateTypeMethod();

예시:

assertThat(beanDefinition.getBeanName()).isEqualTo("testPostService");
assertThat(beanDefinition.isCreateTypeMethod()).isFalse();

isCreateTypeMethod()는 빈 생성 방식이 메서드 기반인지 확인하기 위한 기능이다.

8. RsData의 한계

기존 RsData의 data 필드에는 하나의 값만 담을 수 있었다.

하지만 프론트에서 글 작성 후 다음 데이터를 함께 원할 수 있다.

• 생성된 게시글
• 전체 게시글 수
• 추가 메타 정보

이런 경우 단순히 data 하나만으로는 표현이 애매해질 수 있다.

9. ResBody 클래스 도입

복잡한 응답 데이터를 담기 위해 액션 메서드 전용 응답 본문 클래스를 두는 방식으로 개선했다.

처음에는 Map을 사용할 수도 있지만, 명확한 응답 구조를 위해 전용 클래스를 만드는 것이 더 좋다.

public record PostWriteResBody(
    PostDto post,
    long totalCount
) {
}

• 응답 구조 명확화
• 타입 안정성 증가
• 프론트와의 API 계약 관리 쉬움

10. HTTP 상태코드

게시글 작성 성공 시에는 201 Created가 가장 의미상 적절하다.

실제로는 200으로 응답해도 동작에는 문제가 없지만, 의미를 정확히 표현하려면 201이 더 적절하다.

11. ResponseEntity

HTTP 상태코드를 직접 지정하기 위해 ResponseEntity를 사용할 수 있다.

return ResponseEntity.status(201).body(rsData);

기존 응답 본문 구조를 유지하면서 HTTP 상태코드를 원하는 값으로 바꿀 수 있다.

12. ResponseAspect 도입

RsData의 resultCode를 기준으로 HTTP 상태코드를 자동 반영하기 위해 AOP를 도입했다.

@Aspect
@Component
public class ResponseAspect {
}

컨트롤러 메서드가 RsData를 반환하면 그 안의 statusCode를 HttpServletResponse에 반영한다.

if (proceed instanceof RsData<?> rsData) {
    response.setStatus(rsData.statusCode());
}

13. AOP 직접 사용

스프링에서 AOP는 간접적으로 자주 사용한다.

예시:

• @Transactional
• @Cacheable

이번에는 @Aspect를 직접 만들어서 응답 후처리 로직을 구현했다.

14. statusCode는 JSON에서 제외

RsData 내부의 statusCode는 HTTP 응답 상태코드 설정에만 사용된다.

응답 JSON에는 굳이 노출할 필요가 없으므로 @JsonIgnore를 적용했다.

@JsonIgnore
public int statusCode() {
    return statusCode;
}

15. DTO 활용 기준

REST API에서 DTO는 역할에 따라 나눌 수 있다.

RsData

조회 API를 제외한 대부분의 요청 응답에 사용한다.

RsData<Void>
RsData<PostDto>
RsData<List<PostDto>>
RsData<PostWriteResBody>

엔티티 DTO

엔티티를 외부에 직접 노출하지 않기 위해 사용한다.

PostDto
MemberDto

요청 본문 DTO

JSON 요청을 받을 때 사용한다.

PostWriteReqBody
PostModifyReqBody

응답 본문 DTO

응답 데이터가 복잡할 때만 만든다.

PostWriteResBody
PostModifyResBody

16. 댓글 수정 API 구현

댓글 수정 API를 구현했다.

댓글 작성, 삭제에 이어 수정까지 구현하면서 댓글 CRUD 흐름이 더 완성되었다.

17. 컨트롤러 TDD 시작

REST API 컨트롤러 테스트를 시작했다.

@SpringBootTest
@AutoConfigureMockMvc
@ActiveProfiles("test")
@Transactional
class ApiV1PostControllerTest {
}

주요 테스트 환경:

• @SpringBootTest
• @AutoConfigureMockMvc
• @ActiveProfiles("test")
• @Transactional

18. MockMvc

MockMvc를 사용하면 실제 서버를 띄우지 않고도 HTTP 요청과 응답을 테스트할 수 있다.

mockMvc.perform(post("/api/v1/posts"))

컨트롤러 테스트는 크게 두 단계로 볼 수 있다.

1. 요청을 날린다.
2. 결과를 검증한다.

19. 글 작성 테스트

POST 요청으로 글 작성 API를 테스트했다.

resultActions
    .andExpect(status().isCreated());

또한 andDo(print())를 추가해서 요청과 응답 내용을 확인했다.

20. 응답 JSON 전체 검증

REST API 테스트에서는 응답 JSON의 모든 필드를 검사하는 것이 좋다.

이유:

• 프론트와의 API 계약 보호
• 필드 누락 방지
• 응답 구조 변경 감지
• 회귀 버그 조기 발견

테스트 코드는 API 문서 역할도 함께 한다.

21. 자동화 테스트의 장점

ResponseAspect처럼 프로젝트 전반에 영향을 주는 코드를 수정할 때 자동화된 테스트가 안전망 역할을 한다.

테스트가 있으면 리팩토링 시 기존 기능이 깨졌는지 빠르게 확인할 수 있다.

22. 요구사항 변경과 TDD

기존 기능의 요구사항이 바뀌면 구현보다 테스트를 먼저 수정하는 흐름이 좋다.

예시:

• 더 이상 totalCount가 필요 없음
• PostWriteResBody 제거
• 테스트 실패 확인
• 구현 수정
• 테스트 통과

이 흐름이 TDD의 안정적인 변경 방식이다.

✅ 정리

• @Bean 방식이 추가되면서 빈 생성 정보를 표현하기 위해 BeanDefinition이 필요해졌다.
• Jackson과 ObjectMapper를 빈으로 등록하면서 설정 객체도 IoC 컨테이너가 관리할 수 있게 되었다.
• RsData와 응답 DTO를 분리하면 REST API 응답 구조를 더 명확하게 관리할 수 있다.
• AOP를 활용하면 RsData의 resultCode를 기반으로 HTTP 상태코드를 자동 반영할 수 있다.
• REST API 테스트에서는 응답 JSON의 모든 필드를 검증하여 프론트와의 API 계약을 지킬 수 있다.
• 자동화 테스트가 있으면 전역적인 리팩토링과 요구사항 변경에도 더 안전하게 대응할 수 있다.

이 글은 2026년 05월 20일 작성된 글입니다.

오늘은 ApplicationContext의 동적 빈 탐색 개선과 REST API 삭제/작성 요청 처리, RsData 응답 구조까지 정리했다.

1. ApplicationContext 하드코딩 제거

기존에는 ApplicationContext 내부에서 특정 클래스 이름이나 생성 방식을 하드코딩하는 부분이 있었다.

이를 ClsUtil을 활용하는 방식으로 변경하여 코드를 더 유연하게 만들었다.

ClsUtil.construct(cls, args);

• 하드코딩 감소
• 동적 객체 생성 가능
• IoC 컨테이너 구조 개선

2. 테스트용 패키지 이동

com.ll.domain.testPost.testPost 패키지를 테스트 폴더로 옮길 수 있게 되어 구조를 정리했다.

테스트 전용 클래스는 실제 애플리케이션 코드와 분리하는 것이 좋다.

• 테스트 코드와 운영 코드 분리
• 프로젝트 구조 명확화

3. Reflections 라이브러리 추가

패키지 스캔을 위해 org.reflections:reflections 라이브러리를 추가했다.

implementation("org.reflections:reflections:0.10.2")
implementation("ch.qos.logback:logback-classic:1.5.12")

이 라이브러리를 사용하면 특정 패키지 하위에서 어노테이션이 붙은 클래스를 자동으로 찾을 수 있다.

4. @Component 계열 클래스 스캔

@Component가 붙은 클래스를 스캔하여 빈 후보로 수집했다.

Reflections reflections = new Reflections("com.ll", TypesAnnotated);

Map<String, Class<?>> clsMap = reflections
    .getTypesAnnotatedWith(Component.class)
    .stream()
    .filter(cls -> !cls.isAnnotation())
    .collect(
        LinkedHashMap::new,
        (map, cls) -> map.put(Ut.str.lcfirst(cls.getSimpleName()), cls),
        Map::putAll
    );

@Service, @Repository처럼 @Component를 기반으로 한 어노테이션도 함께 탐색할 수 있다.

5. 빈 이름 규칙

스프링 빈 이름 규칙처럼 클래스명의 첫 글자를 소문자로 바꾸어 빈 이름을 만들었다.

MemberService -> memberService

이를 위해 lcfirst 유틸을 구현했다.

public static String lcfirst(String str) {
    if (str == null || str.isEmpty()) return str;

    char firstChar = str.charAt(0);

    if (Character.isLowerCase(firstChar)) return str;

    return Character.toLowerCase(firstChar) + str.substring(1);
}

6. annotatedClasses 함수 구현

특정 패키지 하위에서 특정 어노테이션을 가진 클래스를 수집하는 함수를 구현했다.

Map<String, Class<?>> annotatedClasses =
    ClsUtil.annotatedClasses("com.ll", Component.class);

테스트에서는 다음 빈들이 잘 수집되는지 확인했다.

• testFacadePostService
• testPostService
• testPostRepository

7. ApplicationContext 동적 빈 검색

이제 ApplicationContext는 더 이상 하드코딩 방식이 아니라 패키지를 스캔해서 동적으로 빈을 찾도록 변경했다.

applicationContext.genBean("testPostService");

내부적으로는 스캔된 클래스 목록에서 빈 이름에 맞는 클래스를 찾아 객체를 생성한다.

8. 댓글 삭제 API 구현

REST API에서 댓글 삭제 기능을 구현했다.

/api/v1/posts/1/comments/2/delete

처음에는 개발 편의를 위해 GET 방식으로 호출할 수 있게 만들었다.

하지만 삭제는 서버 상태를 변경하는 작업이므로 원칙적으로는 GET이 아니라 DELETE 메서드를 사용하는 것이 맞다.

9. orphanRemoval과 더티체킹

댓글 삭제 과정에서 orphanRemoval = true와 더티체킹을 활용했다.

@OneToMany(mappedBy = "post", orphanRemoval = true)
private List<PostComment> comments;

부모 엔티티에서 자식 엔티티를 제거하면 JPA가 변경을 감지해서 삭제 쿼리를 실행한다.

단, 더티체킹은 트랜잭션 안에서 동작하므로 @Transactional이 필요하다.

10. 조회 메서드 readOnly 트랜잭션

조회 전용 API에는 readOnly = true 옵션을 적용했다.

@Transactional(readOnly = true)

조회 작업임을 명확히 표현할 수 있고, 불필요한 변경 감지를 줄일 수 있다.

11. resultCode와 msg

조회가 아닌 요청에는 처리 결과를 명확하게 알려주는 응답이 필요하다.

{
  "resultCode": "200-1",
  "msg": "댓글이 삭제되었습니다."
}

resultCode는 HTTP 상태코드와 세부 구분코드를 함께 표현한다.

200-1

• 200: 성공
• -1: 세부 구분 코드

12. RsData 클래스 도입

조회 API를 제외한 요청 응답에 사용할 공통 응답 객체를 만들었다.

public class RsData<T> {
    private String resultCode;
    private String msg;
    private T data;
}

사용 예시:

• 글 작성 응답
• 글 수정 응답
• 글 삭제 응답
• 댓글 작성 응답
• 댓글 삭제 응답

13. data 필드 추가

resultCode와 msg만으로 부족한 경우를 위해 data 필드를 추가했다.

RsData<PostDto>

응답 결과와 함께 추가 데이터를 담을 수 있게 되었다.

14. RsData 제네릭 적용

처음에는 data 타입을 Object로 처리했지만, 이후 제네릭을 적용했다.

RsData<PostDto>
RsData<PostCommentDto>
RsData<Void>

제네릭을 사용하면 응답 데이터 타입을 더 명확하게 표현할 수 있다.

15. RsData

응답에 추가 데이터가 필요 없는 경우에는 RsData<Void>를 사용한다.

RsData<Void>

데이터 없이 resultCode와 msg만 전달할 때 적합하다.

16. 글 삭제 API 구현

글 삭제 기능도 구현했다.

/api/v1/posts/1/delete

글 삭제 시 관련 댓글은 CascadeType.REMOVE 설정 덕분에 함께 삭제된다.

17. Postman 사용

Postman을 사용해 REST API를 직접 호출하고 테스트했다.

예시 요청:

GET /api/v1/posts
GET /api/v1/posts/2
GET /api/v1/posts/2/comments
GET /api/v1/posts/2/comments/4

Postman을 사용하면 브라우저로 호출하기 어려운 DELETE, POST 요청도 쉽게 테스트할 수 있다.

18. DELETE 메서드 적용

삭제 요청을 GET에서 DELETE 방식으로 변경했다.

기존:

GET /api/v1/posts/1/delete

변경:

DELETE /api/v1/posts/1

REST API에서는 삭제 작업에 DELETE 메서드를 사용하는 것이 더 자연스럽다.

19. POST 요청과 @RequestBody

글 작성 API는 POST 요청으로 처리하고, 요청 본문은 JSON 형태로 받도록 변경했다.

{
  "title": "제목",
  "content": "내용"
}

@PostMapping
public RsData<PostDto> write(@RequestBody PostWriteReqBody reqBody) {
}

@RequestBody는 JSON 요청 본문을 자바 객체로 변환해준다.

20. REST API와 BindingResult

REST API에서는 @Valid를 사용하더라도 BindingResult를 직접 사용하는 경우가 많지 않다.

폼 기반 서버 렌더링에서는 검증 실패 후 다시 폼 화면을 보여줘야 하지만, REST API에서는 보통 에러 응답을 JSON으로 내려준다.

21. ReqBody 네이밍

기존 PostWriteForm이라는 이름을 PostWriteReqBody로 변경했다.

public record PostWriteReqBody(
    String title,
    String content
) {
}

REST API에서는 폼보다는 요청 본문을 의미하는 ReqBody라는 이름이 더 정확하다.

✅ 정리

• Reflections 라이브러리를 사용해 @Component 계열 클래스를 동적으로 수집할 수 있었다.
• ApplicationContext에서 하드코딩을 줄이고 패키지 스캔 기반 빈 생성을 구현할 수 있었다.
• 댓글 삭제에서는 orphanRemoval과 더티체킹, 트랜잭션의 관계를 이해할 수 있었다.
• RsData를 도입하면서 REST API 응답 구조를 공통화할 수 있었다.
• DELETE, POST, @RequestBody를 사용하면서 REST API다운 요청 구조에 가까워졌다.

이 글은 2026년 05월 19일 작성된 글입니다.

오늘은 REST API 기반 프로젝트 세팅과 JPA, DTO, API 버저닝, 댓글 API 구현까지 정리했다.

1. REST API 프로젝트 세팅

implementation("org.springframework.boot:spring-boot-starter-web")

REST API 서버 개발에 필요한 기본 의존성을 추가했다.

2. REST API vs 타임리프

REST API 방식에서는 백엔드는 데이터(JSON)만 제공한다.

{
  "id": 1,
  "title": "제목 1",
  "content": "내용 1"
}

타임리프 방식은 HTML까지 서버에서 렌더링해서 응답한다.

3. Post 도메인 구성

• JPA
• BaseEntity
• InitData
• Profile 설정

등 게시글 도메인의 기본 구조를 구성했다.

4. 게시글 샘플 데이터 생성

postService.write("제목 1", "내용 1");

게시글 3개를 자동 생성하도록 구성했다.

5. 댓글 도메인 추가

postCommentService.write(post, "댓글 1");

댓글 기능과 샘플 데이터 5개를 추가했다.

6. 글 다건조회 API

@GetMapping
public List<Post> getPosts() {
    return postService.findAll();
}

엔드포인트:

/api/v1/posts

7. 순환참조 문제

양방향 연관관계에서는 JSON 직렬화 시 무한 루프가 발생할 수 있다.

8. @JsonIgnore

@JsonIgnore
private Post post;

순환참조를 방지하기 위해 적용했다.

9. @RestController

@RestController
@RequestMapping("/api/v1/posts")

@RestController는 JSON 응답을 위한 컨트롤러이다.

10. 글 단건조회 API

@GetMapping("/{id}")
public Post getPost(@PathVariable long id)

엔드포인트:

/api/v1/posts/3

11. Jackson

Jackson은 Java 객체와 JSON 간 변환을 담당한다.

기능:

• 객체 → JSON
• JSON → 객체

12. REST API vs 타임리프 비교

13. API 버저닝

/api/v1/posts

REST API에서는 버저닝을 통해 하위 호환성을 유지한다.

14. 엔티티 직접 노출 문제

프론트 요구사항 때문에 엔티티 필드를 직접 수정하는 것은 좋지 않다.

예시:

• createDate → createdDate
• title → subject
• content → body

15. DTO 도입

public record PostDto(
    long id,
    String title,
    String content
) {
}

엔티티 대신 DTO를 응답 객체로 사용했다.

16. record 사용

.map(PostDto::new)

record 기반 DTO 구조로 변경했다.

17. 댓글 다건조회 API

/api/v1/comments

댓글 전체 조회 기능을 구현했다.

18. 댓글 단건조회 API

/api/v1/posts/1/comments/2

특정 게시글의 댓글 단건 조회를 구현했다.

19. 평면 리소스 vs 중첩 리소스

✅ 정리

• REST API 프로젝트를 구성하면서 JSON 기반 응답 구조를 이해할 수 있었다.
• 양방향 연관관계에서는 순환참조 문제가 발생할 수 있으며 @JsonIgnore로 해결할 수 있다.
• DTO를 사용하면 엔티티와 API 응답 구조를 분리할 수 있다.
• API 버저닝을 통해 하위 호환성을 유지하면서 API를 확장할 수 있다.
• 댓글 API까지 추가하면서 게시글과 댓글 간 관계 구조를 구현할 수 있었다.

이 글은 2026년 05월 18일 작성된 글입니다.

오늘은 인터셉터 기반 인증/인가 처리와 스코프(scope), 세션, request 객체 활용까지 정리했다.

1. 인터셉터 프로젝트 세팅

implementation("org.springframework.boot:spring-boot-starter-thymeleaf")

Spring MVC 기반 웹 프로젝트 환경을 구성했다.

2. 인터셉터 등록

registry.addInterceptor(new LoginInterceptor());

인터셉터를 등록하고 요청 흐름에서 로그를 확인했다.

3. 로그인 체크 인터셉터

public class LoginCheckInterceptor implements HandlerInterceptor {
}

로그인 여부를 검사하는 인터셉터를 추가했다.

4. 로그인 폼 구현

<form method="post">
    <input type="text" name="username">
    <input type="password" name="password">
</form>

5. 로그인 / 로그아웃 처리

session.setAttribute("loginedMember", member);

session.invalidate();

세션 기반 로그인/로그아웃을 구현했다.

6. 로그인 기능 보완

• 로그인 실패 처리
• 세션 유지
• 리다이렉트 흐름 개선

등 로그인 흐름을 보완했다.

7. 싱글톤 스코프

@Scope("singleton")

기본적으로 스프링 빈은 싱글톤 스코프를 사용한다.

특징:

• 컨테이너당 1개
• 메모리 효율적
• 상태 공유 주의 필요

8. 세션 스코프

@SessionScope

브라우저(HTTP 세션)마다 별도의 객체가 생성된다.

9. 세션 스코프와 프록시

@SessionScope(proxyMode = ScopedProxyMode.TARGET_CLASS)

세션 스코프 빈은 내부적으로 프록시 객체를 사용한다.

10. 세션에 로그인 정보 저장

session.setAttribute("member", member);

사용자별 로그인 상태를 유지할 수 있게 되었다.

11. Request 스코프

@RequestScope
public class Rq {
}

Rq 객체를 request 스코프로 변경했다.

12. Request 스코프 특징

request 스코프 객체는 하나의 요청 안에서 데이터를 공유하기 좋다.

활용 예시:

• 인터셉터
• 컨트롤러
• 템플릿

13. 현재 URL 조회

rq.getCurrentUrl();

현재 요청 주소를 쉽게 가져올 수 있도록 개선했다.

14. rq에 로그인 정보 저장

rq.setLoginedMember(member);

rq 객체에서 로그인 정보를 직접 관리하도록 변경했다.

15. rq 기반 코드 개선

rq 중심 구조로 리팩토링하면서

• 중복 제거
• 로그인 처리 통합
• 코드 가독성 향상

효과를 얻을 수 있었다.

16. rq에서 Member 객체 직접 관리

기존:

Integer memberId

개선:

Member member

객체 기반 접근으로 코드가 더 직관적으로 바뀌었다.

17. 스코프 종류 정리

18. Singleton vs Prototype

✅ 정리

• 인터셉터를 사용하면 공통 인증/인가 처리를 효율적으로 관리할 수 있다.
• 세션을 이용하면 사용자별 로그인 상태를 유지할 수 있다.
• 세션 스코프와 request 스코프를 통해 상황에 맞는 객체 생명주기를 사용할 수 있다.
• request 스코프 객체는 요청 단위 데이터 공유에 특히 유용하다.
• rq 객체를 중심으로 로그인 정보를 관리하면서 코드 구조를 더 깔끔하게 정리할 수 있었다.

이 글은 2026년 05월 15일 작성된 글입니다.

오늘은 생성자 파라미터 분석 유틸, 회원 CRUD 및 검색, 그리고 MyBatis resultMap과 association/collection 매핑까지 정리했다.

1. 생성자 파라미터 정보 조회

Parameter[] parameters =
    ClsUtil.getParameters(
        TestCar.class,
        new Object[]{"BMW", 1234}
    );

생성자의 타입과 이름 정보를 조회할 수 있도록 구현했다.

2. 생성자 파라미터 이름 조회

String[] parameterNames =
    ClsUtil.getParameterNames(
        TestCar.class,
        new Object[]{"BMW", 1234}
    );

Reflection 기반으로 생성자 파라미터 이름을 추출했다.

3. 타입 기반 생성자 선택

여러 생성자가 있을 때 입력된 타입과 일치하는 생성자를 선택하도록 개선했다.

• String
• int

등 타입 기준 생성자 탐색 가능.

4. 함수 파라미터 타입 조회 개선

특정 함수의 파라미터를 타입 기준으로 조회할 수 있도록 개선했다.

5. 회원 단건 조회

Member member = memberService.findByUsername("user2");

username 기반 회원 조회 테스트를 구현했다.

6. 회원 생성

int id = memberService.create(
    "user3",
    "{noop}1234",
    "유저3",
    "user3@test.com"
);

회원 생성 후 다시 조회해서 저장 여부를 검증했다.

7. 회원 삭제

memberService.deleteById(1);

삭제 후 회원 개수를 확인했다.

8. 회원 수정

memberService.update(
    1,
    "user1_updated",
    "{noop}5678",
    "유저1 수정",
    "user1_updated@test.com"
);

회원 정보 수정 기능을 구현했다.

9. 일부 데이터만 수정

memberService.update(
    1,
    "",
    "",
    "유저1 수정됨",
    ""
);

빈 값은 유지하고 특정 필드만 수정 가능하도록 처리했다.

10. 회원 검색

memberService.search("username", "user1");

검색 기준:

• username
• name
• email
• 전체 검색

11. 다중 회원 삭제

memberService.deleteByIds(Arrays.asList(id3, id4));

foreach 기반 다중 삭제 기능을 구현했다.

12. 게시글 작성자 정보 추가

ALTER TABLE post
ADD COLUMN memberId BIGINT UNSIGNED NULL;

게시글과 회원을 연결할 수 있도록 memberId를 추가했다.

13. 작성자 이름 포함 조회

Post post = postService.findByIdWithAuthorName(1);

JOIN 기반으로 작성자 이름까지 함께 조회했다.

14. 작성자 이름 검색

List<Post> posts =
    postService.searchWithAuthorName(
        "author",
        "유저1"
    );

작성자 이름 기반 검색 기능을 구현했다.

15. resultMap

<resultMap id="PostWithAuthorMap" type="Post">

JOIN 결과를 객체 구조에 맞게 매핑할 수 있다.

16. association

<association property="author"
             javaType="Member">

association은 1:1 관계 매핑에 사용된다.

예시:

• 게시글 → 작성자
• 회원 → 프로필

17. collection

<collection property="comments"
            ofType="Comment">

collection은 1:N 관계 매핑에 사용된다.

예시:

• 게시글 → 댓글 목록
• 주문 → 주문 항목 목록

18. association vs collection

✅ 정리

• Reflection 기반으로 생성자 파라미터 정보를 조회하는 기능을 구현할 수 있었다.
• 회원 CRUD와 검색 기능을 구현하면서 서비스 구조를 확장할 수 있었다.
• 게시글과 회원을 연결하여 작성자 개념을 추가할 수 있었다.
• MyBatis resultMap을 사용하면 JOIN 결과를 객체 구조에 맞게 유연하게 매핑할 수 있다.
• association은 1:1 관계, collection은 1:N 관계 매핑에 사용된다.