팀 내부에서 그레이존 스터디를 통해 프로젝트를 진행하며 처음 접하거나, 모르는 부분을 탐구하고자 하였다. 첫번째 스터디에서는 신입으로 입사한 나를 위해 광고 도메인의 RTB를 이해하는 시간을 가졌고, 두번째 스터디에서는 스파크, 세번째는 하둡 + 스파크를 공부해보았고, 이 글은 세번째 스터디를 준비하며 공부한 내용을 기록한 글이다.

하둡을 왜사용할까

1. 분산 저장이 가능하다 데이터를 한 서버에 몰아넣는 게 아니라, 수백~수천 대 서버에 쪼개서 저장한다. 한 서버가 죽어도 다른 서버에 복제본이 있으니까 데이터가 안 날라간다.

2. 대용량 배치 처리에 최적화됐다 MapReduce 방식으로 데이터를 병렬 처리하니까, 혼자 하면 며칠 걸릴 연산도 수백 대가 나눠서 빠르게 끝낼 수 있다.

3. 확장이 쉽다 서버 더 추가하면 그냥 성능이 늘어난다. 수평 확장(Scale-out)이 자연스럽게 된다.

4. 다양한 데이터 형식을 다 받는다 정형 데이터뿐 아니라 로그, 이미지, 텍스트 같은 비정형 데이터도 그냥 저장해두고 나중에 필요할 때 처리하면 된다.

예를들면 이해가 쉽다. 로그가 하루에 몇억건 이상 쌓이는 서비스가 있다고 가정해보자. 서버 하나에 해당 로그를 다 넣을 수도 있겠지만, 시간이 지나 로그가 쌓인다면 쿼리 성능은 처참할 것이다. 또한 DB서버가 다운될 수도 있다. 이전에 배웠던 인덱스 튜닝, 파티셔닝등을 해도 한계가 명확하다.

고성능 서버 한대로 업그레이드 하면 되지 않을까? 그래도 1년 뒤에는 데이터가 넘칠게 뻔하고, 서버 하나가 죽으면 전체적인 장애가 발생할 것이다.

그렇다면 하둡을 도입해보자. 일반 서버 20대에 하둡을 구성하면 어떻게 될까?

데이터는 20대에 나눠서 저장되고, 각 데이터는 복제된다. 서버 한두 대가 죽어도 데이터는 안전하다. 쿼리를 날리면 20대가 동시에 나눠서 처리하니까 속도도 압도적으로 빠르다. 비용도 고성능 서버 한 대보다 일반 서버 20대가 더 쌀 수 있다. 나중에 데이터가 더 늘어나면 서버 몇 대만 추가하면 그만이다. 로그뿐만 아니라 이미지, 텍스트, JSON 등 형식이 제각각인 데이터도 일단 하둡에 다 던져놓고 나중에 필요할 때 꺼내서 분석하면 된다. 기존 RDB였다면 스키마를 미리 정의해야 했겠지만, 하둡은 그런 제약이 없다. 결국 하둡은 "데이터가 너무 많아서 기존 방식으로는 감당이 안 될 때" 꺼내드는 도구다. 모든 서비스에 필요한 건 아니지만, 데이터가 폭발적으로 쌓이는 순간 하둡 같은 분산 시스템은 선택이 아니라 필수가 된다.

목표

1. 하둡이 무엇인가?왜 사용하는지 알아본다.
2. 하둡을 내부 HFDS에서 CSV파일을 읽는다.
3. 도커를 통해 마스터1, 워커4개를 띄워 각각 Spark 설정을 한다.
4. 워커 1개, 2개, 4개를 띄워서 분산처리를 하였을떄 속도 비교를 한다.

아키텍처

Mac (로컬)                         Docker (spark-net)
──────────────────                 ──────────────────────────────
Hadoop HDFS                        spark-driver
  NameNode                           └── benchmark.py 실행
  DataNode                               ↓ job 제출
  /data/amazon_big.csv           spark-master
  (포트 9870, 9000)                   └── task 배분
                                  spark-worker-1  (2core 2GB)
                                  spark-worker-2  (2core 2GB)
                                  spark-worker-3  (2core 2GB)
                                  spark-worker-4  (2core 2GB)
                                       ↓ HDFS 읽기
                                  192.168.x.x:9000 (Mac 로컬 IP)

왜 이 구조인가

처음에는 Docker 안에 Hadoop까지 포함하려 했지만, Mac M1 (ARM64) 환경에서 Hadoop 이미지 호환 문제가 계속 발생했다. 결론적으로 Hadoop은 로컬 Mac에 직접 설치하고, Spark만 Docker로 구성하는 방식을 택했다.

Docker 컨테이너가 로컬 HDFS에 접근할 때는 localhost를 쓸 수 없다. localhost는 각 컨테이너 자신을 가리키기 때문이다. 대신 docker-compose.yml의 extra_hosts에 host.docker.internal:host-gateway를 설정하면, 컨테이너 안에서 host.docker.internal 이라는 주소로 Mac에 접근할 수 있다. Docker가 내부적으로 host-gateway를 Mac의 실제 IP로 변환해준다.

spark-dirver가 로컬의 benchmark.py를 어떻게 실행해주는 원리

docker-compose.yml에 이 설정이 있다:

spark-driver:
  volumes:
    - ../benchmark.py:/app/benchmark.py  

    이 설정이 하는 일:
로컬 Mac                        Docker spark-driver 컨테이너
─────────────────               ──────────────────────────
~/JupyterProject/               /app/
  benchmark.py       ←마운트→     benchmark.py

마운트는 복사가 아니라 연결이다. 로컬 파일과 컨테이너 안의 파일이 같은 파일을 가리킨다. 로컬에서 수정하면 컨테이너 안에서도 즉시 반영된다.

<실행 흐름>

```jsx
docker exec spark-driver python3 /app/benchmark.py
    ↓
1. spark-driver 컨테이너 안에서 python3 실행
2. /app/benchmark.py 읽음 (= 로컬 benchmark.py)
3. SparkSession 생성 → spark-master:7077 연결
4. HDFS에서 데이터 읽기 → 192.168.x.x:9000
5. Worker들한테 task 분배
6. 결과를 /tmp에 저장

환경 구성

로컬 환경

Docker 환경

custom-spark:3.5.0은 apache/spark:3.5.0 기반으로 pandas, matplotlib, pyspark를 추가 설치한 커스텀 이미지다.

왜 driver를 로컬에서 실행안하고 도커 내부로 두었는지

문제 상황

처음에는 benchmark.py를 로컬 PyCharm에서 직접 실행했다. count, GroupBy는 성공했지만 Sort, Join 같은 shuffle이 필요한 작업에서 계속 실패했다.

Failed to connect to /172.20.0.4:45565
Operation timed out

shuffle이 뭔가

Sort나 Join 같은 작업은 여러 Worker에 흩어진 데이터를 재분배해야 한다.

Worker-1: [5, 2, 8]
Worker-2: [1, 9, 3]
          ↓ 전체 정렬하려면 데이터를 섞어야 함
Worker-1: [1, 2, 3]  ← Worker-2 데이터 일부를 받아옴
Worker-2: [5, 8, 9]

이 데이터 재분배 과정을 shuffle이라고 한다. shuffle이 끝나면 Worker들은 결과를 Driver에게 돌려줘야 한다.

Driver가 Docker 밖(로컬 Mac)에 있을 때 생기는 문제

로컬 Mac (Driver)              Docker 내부 네트워크
──────────────────             ──────────────────────
192.168.219.103                172.20.0.4 (worker-1)
                               172.20.0.5 (worker-2)
                               172.20.0.6 (worker-3)
                               172.20.0.7 (worker-4)

Worker들이 shuffle 결과를 자신의 내부 IP에 올려놓는다.

Worker-1 → "결과를 172.20.0.4:45565 에 올려뒀어"
Driver   → 172.20.0.4:45565 접근 시도
         → Connection timed out ❌

172.20.0.x는 Docker 내부 네트워크 주소다. 로컬 Mac에서는 이 주소로 직접 접근이 안 된다. Docker가 포트 포워딩(8081, 8082 등)으로 일부 포트를 열어두긴 하지만, shuffle에서 사용하는 포트는 랜덤으로 생성되기 때문에 포워딩이 안 돼있다.

결국 Driver가 Worker의 shuffle 결과를 가져올 수 없어서 작업이 실패한다.

Driver를 Docker 안으로 이동하면 해결되는 이유

spark-driver 컨테이너를 추가해서 Driver도 같은 Docker 네트워크 안에 넣었다.

Docker spark-net (172.20.0.x 대역)
──────────────────────────────────
spark-driver   172.20.0.2  ← Driver
spark-master   172.20.0.3
spark-worker-1 172.20.0.4
spark-worker-2 172.20.0.5
spark-worker-3 172.20.0.6
spark-worker-4 172.20.0.7

이제 Driver, Master, Worker가 전부 같은 172.20.0.x 대역 안에 있다.

Worker-1 → "결과를 172.20.0.4:45565 에 올려뒀어"
Driver   → 172.20.0.4:45565 접근 시도
         → 같은 네트워크라 바로 접근 ✅

별도의 포트 포워딩 없이도 컨테이너끼리 내부 IP로 자유롭게 통신할 수 있다.

정리

count와 GroupBy가 성공한 이유는 shuffle이 없거나 적어서 Worker → Driver 단방향 통신만으로 끝나기 때문이다. Sort와 Join은 Worker들끼리 + Driver와 양방향 통신이 필요해서 같은 네트워크에 있어야 한다.

폴더 구조

JupyterProject/
  ├── docker/
  │     ├── docker-compose.yml
  │     └── Dockerfile
  ├── env/
  │     └── hadoop.env
  ├── resource/
  │     ├── amazon.csv          (원본 1,465행)
  │     └── amazon_big.csv      (500배 복제 732,500행)
  ├── benchmark.py
  ├── benchmark_results.csv     (결과)
  └── benchmark_result.png      (차트)

실행 방법

1. 로컬 HDFS 시작

# HDFS 시작
start-dfs.sh

# 프로세스 확인
jps
# NameNode, DataNode, SecondaryNameNode 세 개가 보여야 함

2. HDFS에 데이터 업로드 (최초 1회)

cd ~/PycharmProjects/JupyterProject

# 테스트 데이터 생성 (500배 복제)
python3 -c "
import pandas as pd
df = pd.read_csv('./resource/amazon.csv')
big_df = pd.concat([df] * 500, ignore_index=True)
big_df.to_csv('./resource/amazon_big.csv', index=False)
print(f'생성 완료: {len(big_df):,}행')
"

# HDFS 업로드
hdfs dfs -mkdir -p /data
hdfs dfs -put ./resource/amazon_big.csv /data/amazon_big.csv
hdfs dfs -ls /data

3. Docker Spark 클러스터 시작

cd docker
docker-compose up -d
docker logs spark-master | tail -10

4. 벤치마크 실행

docker exec spark-driver python3 /app/benchmark.py

한 번 실행으로 워커 1개 → 2개 → 4개 순서로 자동 테스트된다.

5. 결과 복사

docker cp spark-driver:/tmp/benchmark_results.csv ~/PycharmProjects/JupyterProject/
docker cp spark-driver:/tmp/benchmark_result.png ~/PycharmProjects/JupyterProject/

벤치마크 태스크 설명

1. HDFS 읽기 + count

HDFS에서 CSV를 읽고 전체 행 수를 세는 가장 기본적인 작업이다.

df.count()

Spark는 lazy evaluation 방식이라 .count() 같은 액션이 호출돼야 실제로 데이터를 읽는다. 워커 수가 많을수록 파일을 병렬로 읽어 빠르다.

2. GroupBy 집계

첫 번째 컬럼(product_id) 기준으로 그룹화해서 각 그룹의 행 수를 세는 작업이다.

df.groupBy(first_col).count().collect()

같은 키를 가진 데이터가 여러 워커에 흩어져 있으면 한 곳으로 모아야 집계할 수 있다. 워커가 많을수록 병렬로 처리해 빠르다.

3. Sort Top 1000

숫자형 컬럼 기준으로 내림차순 정렬 후 상위 1000개를 가져오는 작업이다.

df.orderBy(F.col(sort_col).desc()).limit(1000).collect()

전체 데이터를 다 봐야 정렬할 수 있어서 데이터 이동(shuffle)이 발생한다. 분산 처리 효과가 잘 드러나는 작업이다.

4. Self Join (50만 rows)

같은 데이터를 두 개로 나눠 서로 Join하는 작업이다.

df1 = df.limit(500_000).withColumn("_key", F.monotonically_increasing_id())
df2 = df.limit(500_000).withColumn("_key", F.monotonically_increasing_id())
df1.join(df2, "_key").count()

Join은 같은 키를 가진 데이터를 한 워커로 모아야 해서 shuffle이 가장 많이 발생한다. 워커 수 차이가 가장 크게 나타나는 작업이다.

5. HDFS Parquet 쓰기

처리 결과를 다시 HDFS에 Parquet 형식으로 저장하는 작업이다.

df.limit(100_000).write.mode("overwrite").parquet(out_path)

Parquet은 컬럼 기반 저장 포맷으로 CSV보다 빠르고 용량이 작다. HDFS 쓰기 속도는 디스크 I/O에 영향을 받아 워커 수 효과가 상대적으로 작다.

벤치마크 결과

데이터: 732,500행 (amazon_big.csv)

결과 분석

워커 4개가 1개보다 평균 2배 빠르다. 이론상 4배여야 하는데 2배 정도인 이유는 모두 같은 물리 머신(Mac)에서 CPU를 나눠 쓰기 때문이다. 실제 물리적으로 다른 서버에서 실행하면 더 큰 차이가 난다.

Self Join이 가장 큰 효과(2.15배)를 보이는 이유는 shuffle이 가장 많이 발생하는 작업이라 워커가 많을수록 병렬 처리 효과가 크기 때문이다. Parquet 쓰기가 가장 작은 효과(1.54배)를 보이는 이유는 디스크 I/O가 병목이라 워커 수보다 저장 속도가 더 영향을 주기 때문이다.

그 외 알아본 것

start-dfs.sh — HDFS 시작 스크립트

HDFS를 구성하는 프로세스들을 한 번에 시작하는 스크립트다

내부적으로 이 세 가지를 순서대로 실행한다..

NameNode 시작 → DataNode 시작 → SecondaryNameNode 시작

ash

`start-dfs.sh   # 시작
stop-dfs.sh    # 종료`

네임노드 & 데이터노드

HDFS는 파일을 저장할 때 두 가지 역할로 나눠서 관리한다.

네임노드 (NameNode)

파일의 위치 지도를 관리하는 관리자다.

실제 데이터를 저장하지는 않고, "어떤 파일이 어느 데이터노드에 있는지"만 기록한다. 도서관으로 치면 책 자체가 아니라 책의 목차와 위치를 적어둔 안내 데스크다.

네임노드가 기억하는 것들:

• 파일 이름, 크기, 권한
• 파일이 몇 개의 블록으로 쪼개졌는지
• 각 블록이 어느 데이터노드에 저장됐는지

/data/amazon.csv
  └── 블록1 → 데이터노드 3번, 7번, 15번
  └── 블록2 → 데이터노드 2번, 9번, 11번

네임노드는 단 한 대만 존재한다. 그래서 네임노드가 죽으면 전체 HDFS가 멈춘다. 이걸 단일 장애점(SPOF)이라고 하는데, 이를 해결하려고 고가용성(HA) 설정에서는 네임노드를 두 대 띄워서 하나가 죽으면 다른 하나가 이어받는 구조를 쓴다.

데이터노드 (DataNode)

실제 파일 데이터를 블록 단위로 저장하는 일꾼이다.

네임노드의 지시에 따라 블록을 저장하고, 읽고, 복제한다. 수백~수천 대가 붙을 수 있고, 대수가 늘수록 저장 용량과 처리 속도가 함께 늘어난다.

데이터노드가 하는 일:

• 파일 블록을 로컬 디스크에 저장
• 주기적으로 네임노드에 "나 살아있어요" 신호(Heartbeat) 전송
• 복제본이 부족하면 다른 데이터노드로 블록 복사

Heartbeat가 끊기면?
  네임노드가 해당 데이터노드를 Dead로 간주
  → 그 노드에 있던 블록을 다른 노드에 자동 복제
  → 복제 수(dfs.replication) 맞출 때까지 계속

둘의 관계 요약

파일을 읽을 때 흐름을 보면 역할이 명확해진다.

클라이언트 → 네임노드에 물어봄 "amazon.csv 어디 있어?"
네임노드   → "블록1은 3번 노드, 블록2는 9번 노드에 있어"
클라이언트 → 데이터노드 3번, 9번에 직접 접근해서 데이터 읽음

네임노드는 지도, 데이터노드는 창고다. 지도 없이는 창고를 찾을 수 없고, 창고 없이는 지도가 의미가 없다.

처음에는 S3 업로드에 대한 지식이 부족했기 때문에, 아무 고민 없이 가장 흔하고 직관적인 방식인 서버 직접 업로드를 선택했다.

MultipartFile을 받아 클라이언트 → 서버 → S3 로 업로드하는 구조

문제없이 잘 동작했고, 구현도 어렵지 않았다. 하지만 프로젝트를 진행하던 중, 프론트엔드 팀원이자 동네 친구에게 이런 제안을 받았다.

💬 “Presigned URL 방식으로 바꾸는 게 어때?”

솔직히 처음에는 “뭐가 그렇게 다른데?” 라는 생각이 먼저 들었다.

하지만 장점이 명확하다면 바꿀 이유는 충분하다고 생각했고, 공부 + 실제 구현을 해보면서 왜 많은 서비스들이 Presigned URL 방식을 선택하는지 몸소 이해하게 되었다.

이 글은 직접 업로드 → Presigned URL 방식으로 전환한 이유와 구현 과정, 그리고 사용하면서 느낀 장단점과 고민 포인트를 정리한 기록이다.

왜 직접 업로드에서 Presigned URL로 바꾸었을까?

이 질문에 대한 답은 두 방식의 구조 차이를 보면 바로 이해된다.

직접 업로드 방식

클라이언트 → 서버(MultipartFile) → S3

• 서버가 파일을 직접 받아서
• 다시 S3로 업로드

Presigned URL 방식

클라이언트 → S3 (직접 업로드)

• 서버는 업로드 URL만 발급
• 실제 파일 전송은 클라이언트가 S3와 직접 수행

우리 서비스는 블로그형 서비스다. 즉, 이미지 업로드가 굉장히 잦다. 이 상황에서 모든 이미지가 서버를 거쳐 간다면?

• 서버 IO 증가
• 네트워크 대역폭 사용 증가
• 트래픽 증가 시 병목 발생 가능성이 높아진다.

👉 “굳이 서버가 파일을 중계해야 할까?” 이 질문에 대한 답이 Presigned URL이었다.

Presigned URL이란 무엇일까?

Presigned URL은 AWS S3에 특정 작업을 허용해주는 임시 URL이다.

조금 풀어서 말하면,

“이 URL을 가진 사람은 이 파일을, 이 시간 동안만, 이 권한으로 S3에 업로드(또는 다운로드)할 수 있다” 라는 정보를 서명(Sign) 해서 만든 URL이다.

즉, Presigned URL에는 이미 다음 정보들이 포함되어 있다.

• 어떤 S3 버킷
• 어떤 객체(Key)
• 어떤 행위 (PUT / GET)
• 유효 시간
• 서버의 AWS 자격 증명으로 서명된 권한

그래서 클라이언트는 AWS Access Key를 전혀 몰라도 Presigned URL 하나만으로 S3에 직접 접근 할 수 있다.

📌 Presigned URL의 특징

✔️ 권한 위임이다

• 서버가 가진 S3 접근 권한을
• 아주 제한적으로, 잠시 동안만 클라이언트에게 위임

✔️ 임시적이다

• 보통 몇 분 ~ 몇 십 분 후 자동 만료
• 만료되면 URL은 즉시 무효

✔️ 안전하다

• AWS 자격 증명을 노출하지 않는다
• 서버가 허용한 작업만 가능하다

🔄 한 줄로 정리하면

Presigned URL은 “서버가 S3 업로드 권한을 잠깐 빌려주는 링크”다.

이 개념을 이해하고 나면, 왜 서버를 거치지 않고도 S3 업로드가 가능한지, 그리고 왜 많은 서비스들이 이 방식을 선택하는지가 자연스럽게 이어진다.

Presigned URL의 치명적인 단점: 고아 파일 문제

Presigned URL을 적용하면서 가장 크게 체감한 단점이 바로 이 부분이었다.

현재 플로우

// 1. Presigned URL 요청
const { presignedUrl, fileUrl } = await getPresignedUrl();

// 2. S3 업로드
await uploadToS3(presignedUrl, imageFile);

// 3. 회원가입
await register({ profileImageUrl: fileUrl });

❌ 3번에서 실패 or 사용자가 회원가입 프로세스에서 이미지 등록 후 페이지를 나간다면? S3에는 파일이 있을것이다. 하지만 DB에는 해당 fileUrl이 존재하지 않을 것이다. 이렇게 되면 S3에만 올라가있고 DB에서 조회할 수 없는 고아파일이 발생하는 것이다.

🛠️ 해결 전략

1️⃣ 파일 존재 검증

if (!s3Service.fileExists(request.profileImageUrl())) {
    throw new IllegalArgumentException("이미지가 존재하지 않습니다.");
}

2️⃣ 주기적인 Cleanup 배치

@Scheduled(cron = "0 0 2 * * *")
public void cleanupOrphanFiles() {
    // DB에 없는 S3 파일 삭제
}

📊 직접 업로드 vs Presigned URL 정리

직접 업로드

장점

• 트랜잭션 안정성
• 고아 파일 없음
• 검증 쉬움

단점

• 서버 부하 큼
• 업로드 느림
• 대역폭 비용 증가

Presigned URL

장점

• 서버 부하 거의 0
• 빠른 업로드
• 확장성 우수

단점

• 고아 파일 관리 필요
• 클라이언트 로직 복잡
• 검증 제한적

✍️ 마무리하며

Presigned URL은 “서버를 가볍게 만들고 싶은 서비스”라면 거의 필수에 가까운 선택지였다.

다만, 무조건 좋은 방식은 아니고 서비스 특성과 트랜잭션 요구사항에 따라 충분한 고민이 필요하다는 것도 느꼈다.

이번 경험을 통해 “왜 이렇게 설계했는지”를 이해하게 된 것이 가장 큰 수확이었다.

이번 프로젝트에서는 아키텍처를 직접 설계하며 다양한 고민들을 마주했는데 그 중하나가 DDD와 JPA에 대한 충돌점이다.

DDD를 왜 선택하셨나요?

헬시플레이트에는 인증, 유저, 식재료, 레시피등 다양한 논리적 도메인들이 존재한다. 또한 장기적인 프로젝트로서 추가적인 도메인이 늘어날 가능성이 높다라는 전제를 가지고 시작했다. 이러한 경우 일반적인 레이어드 아키텍처를 사용한다면 확장성과 유지보수성이 낮다고 판단했고 이를 잘 분리하고 관리를 하기위해 DDD의 아키텍처를 따라가기로했다.

단점

내가 느꼈던 DDD의 단점은 숙련도가 낮을 수록 개발속도가 느려지는것과 코드의 복잡도가 증가하는 것이다.

장점

물론 단점도 존재했지만 그보다 장점도 크게 느껴졌다.

우선, 코드를 작성할 때 한 번 더 고민하고 생각하며 나의 철학에 맞는 코드를 작성하고 있는지 한 번 더 확인할 수 있었다. "올바른 모듈에 위치하는지", "도메인 로직이 응용 계층에 섞여 있지는 않은지", "이 객체가 진짜 필요한 책임인지" 등을 끊임없이 질문하게 된다.

우아한테크코스를 수료한 지금, 요즘 들어 시간에 대한 조바심이 생기기 시작했고, 내가 1년동안 배운 우아한테크코스의 철학이 흔들릴 때도 생기는 것 같다. 빠르게 기능을 만들어내는 것도 중요하지만, 제대로 된 설계와 구조를 고민하는 시간이 결국 기술 부채를 줄이고 추후 기능 확장을 위한 리팩토링 영역을 줄이는 등 장기적으로는 더 빠른 개발을 가능하게 한다는 걸 깨달았다. DDD는 그런 고민을 강제하는 아키텍처였다.

DDD와 JPA의 충돌점

하지만 DDD를 실제로 적용하다 보니 JPA와의 충돌점들을 마주하게 되었다. 이론적으로 완벽해 보이는 두 기술이지만, 함께 사용하려니 여러 난관이 있었다.

1.Value Object의 불변성 vs JPA의 기본 생성자 요구사항

DDD의 Value Object는 불변 객체여야 한다. 하지만 JPA는 엔티티와 임베디드 객체에 기본 생성자를 요구한다. Ingredient(식재료)는 Aggreate Root이고 IngredientName(식재료명)은 그안에 필드로 존재한다.

  @Embeddable
  @Getter
  @EqualsAndHashCode
  @NoArgsConstructor(access = AccessLevel.PROTECTED)  // JPA를 위한 타협
  public class IngredientName {

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

      private IngredientName(final String value) {
          this.value = value;
      }

      public static IngredientName of(final String value) {
          validateName(value);
          return new IngredientName(value);
      }

      private static void validateName(final String value) {
          if (value == null || value.isBlank()) {
              throw new IllegalArgumentException("식재료명은 공백일 수 없습니다.");
          }
          if (value.length() > 100) {
              throw new IllegalArgumentException("식재료명은 100자 이하여야 합니다.");
          }
      }
  }

해결 방법으로는

• @NoArgsConstructor(access = AccessLevel.PROTECTED)를 사용해서 JPA의 요구사항을 만족하면서도 외부에서의 무분별한 생성은 막는다.
• 정적 팩토리 메서드를 통해서만 객체를 생성하도록 강제하여 유효성 검증을 보장한다.

2. Aggregate Root와 연관관계 관리

DDD에서는 Aggregate 간의 참조는 ID로 해야한다고 권장하지만, JPA의 연관관계 매핑은 객체 참조를 사용한다. 이 부분이 가장 애매하다고 느껴졌다. DDD관점에서 다른 Aggregate와의 관계를 간접참조로 구성한다면 JPA의 객체참조로부터 오는 dirty checking, fetch=Lazy, 엔티티 그래프 장점들을 포기해야하는것이 아닌가?

@Entity
@Table(name = "ingredient")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Ingredient extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "ingredient_id")
    private Long id;

    //등록한 회원
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "registered_by")
    private User registeredBy;

위의 코드는 식재료를 등록한 사용자를 판별하기위해 User 객체를 @ManyToOne으로 연관관계를 맺었었다. 하지만 DDD관점에서 아래와 같은 문제점들이 있다.

• Ingredient Aggregate가 User Aggregate를 객체로 소유
• updateIngredient() 안에서 User 접근이 기술적으로 가능
• Lazy라도 탐색 자체가 허용됨

DDD에서는 애그리거트간 독립성과 트랜잭션 일관성이 매우 중요하다.Ingredient가 저장될때 User또한 같이 변경된다면 사이드 이펙트가 발생할 것이다.

고민과 해결책 모색

Aggregate Root간 연관관계 문제를 해결하기 위해 두 가지 방향을 고민했다.

방향 1. 순수 DDD 방식 - ID 참조만 사용

@Embeddable
@Getter
@EqualsAndHashCode
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class RegisterId {

    @Column(name = "registeredId")
    private Long value;

    private RegisterId(final Long value) {
        this.value = value;
    }

    public static RegisterId of(final Long value) {
        return new RegisterId(value);
    }
}

public class Ingredient{

    @Embedded
    private RegisterId registeredBy;  // Long userId를 감싼 Value Object

}

전형적인 DDD의 ID 간접 참조 방식이다. 사용시 따라오는 장점과 고민되는점은 아래와 같았다.

장점

• Aggregate 간 의존성 제거
• 도메인 모델의 순수성 유지
• 의도하지 않은 User 변경 원천 차단

  고민되는 점

• User 정보가 필요한 조회 시 JOIN 쿼리를 직접 작성해야 함
• "내가 등록한 식재료 목록 + 등록자 이름" 같은 조회는 도메인 모델만으로는 표현하기 어려움
• 조회 책임이 개발자에게 넘어오기 때문에 비효율적인 조회 로직을 만들 가능성이 있다.

방향 2. 실용적 JPA 방식 - 객체 참조 사용

@ManyToOne(fetch = FetchType.LAZY)
private User registeredBy;

장점

• 객체 그래프 탐색 가능
• 간단한 조회 코드 작성 가능
• JPA의 편의성 극대화

문제점

• Aggregate 간 직접 참조로 인해 독립성 훼손
• 도메인 로직 내에서 User 엔티티 접근 가능
• 의도하지 않은 상태 변경 가능성
• DDD의 Aggregate 경계 원칙과 충돌

어느 한쪽을 선택하면 다른 한쪽의 장점을 포기해야하는 딜레마에 빠지게 된다.

CQRS로 해결하기

CQRS란?

CQRS(Command Query Responsibility Segregation)는 쓰기(Command)와 읽기(Query)의 책임을 분리하는 아키텍처 패턴이다.

• Command (쓰기)
  • 데이터를 변경
  • 비즈니스 규칙과 도메인 무결성에 집중
• Query (읽기)
  • 데이터를 조회
  • 성능과 조회 편의성에 집중

쓰기 모델은 DDD 원칙을 엄격히 준수하고,
읽기 모델은 JOIN, DTO 프로젝션 등 조회 최적화를 적극 활용한다.

즉,

• Command 모델에서는 Aggregate 독립성과 도메인 규칙을 지키는 것이 가장 중요하고
• Query 모델에서는 객체 그래프보다는 SQL 관점에서 “어떻게 빠르게 조회할 것인가”에 집중한다.

조회가 필요한 경우: 식재료 정보 + 등록한 사용자 정보

예를 들어
“내가 등록한 식재료 목록과 함께 등록한 사용자 정보(닉네임 등)를 조회”해야 한다면
Command 모델의 Ingredient 엔티티를 그대로 사용하는 것은 적합하지 않다.

이 경우 Query 전용 DTO와 JOIN 쿼리를 활용한다.

Query 모델 – 읽기 전용 DTO

package com.healthy_plate.ingredient.application.dto;

/**
 * 읽기 전용 DTO - 식재료 정보 + 등록자 정보
 * CQRS Query 모델
 */
public record IngredientWithUserDto(
    Long ingredientId,
    String ingredientName,
    String ingredientNameEn,
    Integer calorie,
    Double servingSize,
    String unit,
    String registrationType,
    Boolean isVerified,
    Long registeredUserId,
    String registeredUserNickname
) {

    public static IngredientWithUserDto of(
        final Long ingredientId,
        final String ingredientName,
        final String ingredientNameEn,
        final Integer calorie,
        final Double servingSize,
        final String unit,
        final String registrationType,
        final Boolean isVerified,
        final Long registeredUserId,
        final String registeredUserNickname
    ) {
        return new IngredientWithUserDto(
            ingredientId,
            ingredientName,
            ingredientNameEn,
            calorie,
            servingSize,
            unit,
            registrationType,
            isVerified,
            registeredUserId,
            registeredUserNickname
        );
    }
}

이 DTO는 조회 전용(Query Model) 이며,

• Entity가 아니다
• 변경 로직이 없다
• 화면/API에 필요한 데이터만 포함한다

Query Repository – JOIN 기반 조회

@Override
@Query("""
    SELECT new com.healthy_plate.ingredient.application.dto.IngredientWithUserDto(
        i.id,
        i.name.value,
        i.nameEn,
        i.calorie.value,
        i.servingSize.value,
        CAST(i.unit AS string),
        CAST(i.registrationType AS string),
        i.isVerified,
        u.id,
        u.profile.nickname
    )
    FROM Ingredient i
    JOIN User u ON i.registerId.value = u.id
    WHERE u.id = :userId
""")
List<IngredientWithUserDto> findByUserIdWithUserInfo(
    @Param("userId") Long userId
);

특징

• User 엔티티를 Command 모델에서 직접 참조하지 않음
• 조회 시에만 명시적으로 JOIN 수행
• DTO 프로젝션으로 필요한 데이터만 조회
• N+1 문제 없이 쿼리 1번으로 조회 완료

정리

• 쓰기(Command)

  • Ingredient는 User를 객체로 참조하지 않고 ID(Value Object)만 보관
  • Aggregate 독립성 및 도메인 무결성 유지

• 읽기(Query)

  • JOIN + DTO를 활용해 조회 성능 최적화
  • 화면/API 요구사항에 맞춘 유연한 조회 가능

CQRS를 통해 DDD의 원칙과 JPA의 실용성 사이의 충돌을 자연스럽게 해소할 수 있었다.

2025년 10월 28일에 개최된 배달의 민족 기술 공유 행사인 '우아한테크컨퍼런스'에 다녀왔다. 개발자로 전향하고 한번쯤은 개발자 컨퍼런스를 경험해보고 싶었고, 타 컨퍼런스에 몇번 신청하긴 했지만 선정되진 않았었다. 이번에도 우테코 및 공식 홈페이지 추첨에서 떨어졌으나 3기 선배 '티케'의 배려로 참여할 수 있었다 (다시 한번 감사합니다😊) .

우아한테크코스의 커리큘럼에 녹아있는 교육 철학처럼 이번 경험을 통해 얻은 지식과 깨달음을 혼자 가져가는 것이 아닌 모두와 함께 공유하여 더불어 성장하고자 되도록 꼼꼼히 글을 작성했다.

우아콘은 백엔드, 프론트엔드, 모바일 앱, PM, 인프라, AI, 로봇, 데이터 등 시간대별로 다양한 세션들이 준비되어 있었고 원하는 시간에 맞춰 해당 세션에 참여하여 발표를 들었다.

이런 행사가 처음이라 들뜬 마음을 감추지 못한채 준비되어 있는 다양한 체험을 먼저 해버렸다. 원래 혼자 사진을 절대 절대 안찍는데 우아네컷의 상품이 너무나 궁금하여 저질러버렸다... (사진도 2장이 나와버려서 매우 곤란했다.)

나는 아래의 5개의 세션을 들었고, 발표 내용을 클로바 노트로 기록하였다. 기록한 내용들을 보기 쉽게 요약하여 보여주고, 추가적으로 나의 생각을 써보려고한다.

💡 들었던 세션 목록

1. AI 네이티브 회사를 향항 새로운 항해
2. 글로벌 타킷팅 서비스, 수억 명의 고객을 향한 도전
3. 더 나은 이상 탐지를 위한 여정: 서버부터 서비스, 그리고 문화 까지
4. ServerSentEvents로 실시간 알림 전송하기
5. BROS 레거시 스파게티 코드 개선
6. RAG, 들어는 봤는데... 내 서비스엔 어떻게 쓰지?

AI 네이티브 회사를 향항 새로운 항해

LLM, AI Agent, MCP... 요즘 개발자라면 대부분 어떤식으로든 AI를 활용한다고 생각한다. 이번 세션에서는 배달의 민족에서 AI를 도입했던 경험을 다룬다.

1️⃣ AI 생산성 기대와 초기 충격

AI 기술이 본격적으로 확산되면서, AI를 잘 활용하는 방법을 다룬 콘텐츠들도 쏟아졌고, 이를 보며 “곧 AI 시대가 온다”는 기대감과 동시에 “이 변화 속에서 뒤처지지 않으려면 어떻게 생산성을 높여야 할까” 하는 고민이 함께 생겼다.

이 주제는 단지 최근의 화두가 아니라, 오래전부터 사람들이 꾸준히 고민해온 생산성의 본질적 문제라고 생각한다.

2️⃣ 우아한형제들의 빠른 AI 도입과 변화

이런 상황 속에서 우아한형제들은 비교적 이른 시기에 AI 솔루션을 도입했다. 특히 GitHub Copilot을 빠르게 적용하면서, 개발자들이 “코딩이 더 편해졌다”, “생산성이 확실히 올라갔다”는 긍정적인 피드백을 많이 남겼다.

그럼에도 불구하고 코드리뷰, 자동화, 테스트등에서 불편한 점들이 존재했고, AI의 발전에도 해당 문제들은 해결되지 않았다.

3️⃣ 한계와 현실적 문제 인식

AI 도입 이후에도 활용 편차가 매우 컸다. 잘 쓰는 사람과 그렇지 않은 사람의 격차가 뚜렷했고, 일부는 “AI를 안 쓰면 뒤처진다”는 압박감 속에서 억지로 사용하는 모습도 보였다.

결국 내부적으로는 “해외에서는 AI가 생산성을 폭발적으로 높였다는데, 왜 우리는 그렇지 못한가?”라는 의문이 제기되었다.

4️⃣ 개선 방향: 검증과 반복의 루프

이런 문제를 단순히 “AI는 효과가 없다”로 결론내릴 수는 없었다. 그래서 AI 도입을 검증하고 개선하는 구조적 접근이 필요하다고 판단했다.

우리는** “리뷰 → PoC → 플랜”**의 짧은 루프를 반복하는 전략을 세웠다.

• 리뷰(Review): 현재 상황과 결과물을 점검하고, 산출물이 실제로 가치가 있는지 평가

• PoC(Proof of Concept): 개념 검증을 통해 기술적 가능성과 효용성 확인

• 플랜(Plan): 검증된 결과를 바탕으로 실행 계획을 구체화

이 과정을 통해 추측이 아닌 데이터 기반의 개선을 추진하기로 했다.

5️⃣ 현재 위치와 AI 발전 단계 인식

OpenAI가 제시한 AI 발전 5단계 모델을 기준으로 보면, 현재는 3단계 ‘에이전트(Agent) 시대’에 해당한다.

1단계: 단순한 대화 수행 2단계: 데이터 기반 조언과 추론 가능 3단계: 사용자를 대신해 독립적으로 작업 수행 4단계: 문제를 스스로 정의하고 혁신적 해결 시도 5단계: 완전한 자율적 지능

현재는 3단계, 즉 ‘에이전트가 실제 업무를 수행할 수 있는 단계’에 진입했다고 판단된다. 따라서 앞으로의 과제는 독립적으로 업무를 처리할 수 있는 AI 에이전트를 어떻게 만들 것인가에 집중되어야 한다.

발표자는 이 AI 모델을 2차 산업혁명의 엔진에 비유한다. 무한한 가능성을 지녔지만, 효율·내구성·비용의 균형이 핵심이다. 이 모델을 어떻게 설계하고 적용하느냐에 따라 AI의 실제 생산성 향상 효과가 결정될 것이다.

🧐 세션 후기

AI 트렌드인 Agent와 MCP에 관심이 많아 꾸준히 따라가려고 노력중이다. 그러나 학습을 거듭할수록 하나의 의문이 생겼다. “과연 우리는 AI에게 전적으로 의존할 수 있을까?”

개인적으로 현재의 AI 열풍에는 일정 부분 ‘버블’이 존재한다고 생각한다. 빅테크 기업들이 가장 먼저 AI를 도입하며 생산성과 편의성을 높이고 있지만, 그만큼 새로운 위험도 함께 커지고 있다. 예를 들어, 잘못된 데이터를 학습시키는 휴먼 에러, 외부에서 의도적으로 조작된 악의적 학습, 그리고 그로 인한 결과 왜곡의 가능성은 여전히 남아 있다.

결국 AI는 스스로 학습하고 판단하는 시스템이기에, 언제나 오판의 위험을 내포한다. 따라서 우리는 “AI의 활용”뿐 아니라 “AI의 한계와 검증”에도 동일한 관심을 가져야 한다고 생각한다.

글로벌 타킷팅 서비스, 수억 명의 고객을 향한 도전

우아한 형제들에서 사용하는 타켓팅 서비스인 버즈가 글로벌 서비스로 확장하면서 선택한 기술들과 코드부터 인프라까지 어떤 변경 사항들이 있었는지에 대한 내용으로 진행되었던 세션이다.

1️⃣ 타겟팅 서비스란 무엇인가

‘버즈(Buzz)’는 배민의 유저 데이터를 기반으로 맞춤형 마케팅을 지원하는 타겟팅 시스템이다. 이 시스템의 핵심은 모든 유저에게 동일한 메시지를 보내는 대신, 필요한 사람에게 필요한 쿠폰과 정보를 제공하는 것이다.

타겟팅은 ‘세그먼트(Segment)’라는 개념으로 운영된다. 예를 들어, “20대 여성 중 최근 1주일 내 신한카드로 결제한 포항 거주자” 같은 조건이 세그먼트를 구성한다. 이 조건 기반의 고객 그룹을 빠르게 분석하기 위해, 오픈서치(OpenSearch) 가 핵심 데이터베이스로 활용된다.

💡오픈서치란?
오픈서치는 빠른 검색·집계, 스키마리스 JSON 저장, 쿼리 DSL 지원, 샤드 기반 확장성 등으로 수억 건의 고객 데이터를 1초 이내로 조회할 수 있게 한다.

2️⃣ 데이터 수집과 세그먼트 활용 구조

고객 속성 데이터는 매일 파이프라인을 통해 업데이트된다. 예를 들어, 마케터가 “생일 고객에게 쿠폰을 발행하고 싶다”고 요청하면, 데이터 엔지니어는 회원 DB에서 생일 정보를 추출해 데이터 웨어하우스로 복제하고, 버즈 시스템이 이를 집계해 오픈서치에 적재한다.

이 데이터는 푸시 액션(쿠폰, 알림)이나 퍼스널라이제이션(개인화된 배너 노출)에 활용된다.

💡 데이터 웨어하우스란?
데이터 웨어하우스는 다양한 소스에서 가져온 데이터를 통합하고 정리하여 저장하는 시스템으로, 비즈니스 인텔리전스, 보고, 분석을 통해 기업의 의사결정을 지원하는 데이터 저장소이다. 현재 운영 데이터와 분리된 독립적인 공간으로, 과거 데이터를 분석하고 추세를 파악하는 데 사용된다.

💡퍼스널라이제이션이란?
소비자 개인의 취향, 관심사, 구매이력, 나이등으로 특정 고객에게 정교한 맞춤형으로 제공하는 것

3️⃣ 글로벌 확장과 기술적 도전

버즈는 글로벌 버전인 세그멘텀(Segmentum) 으로 확장되며 70개국, 약 1.5억 명의 고객을 대상으로 서비스가 운영되고 있다.

확장 과정에서 직면한 주요 과제는 네 가지였다:

• 낮은 API 레이턴시 (P95: 60ms, P99: 80ms 이하)
• 수억 명 단위 데이터 스케일
• 높은 TPS(초당 요청 처리)
• 비용 효율성

4️⃣ 배포 전략 결정: 리전 단위 분산

초기에는 중앙집중형 배포(아시아 단일 리전) 방식을 고려했으나, 거리로 인한 레이턴시와 장애 전파 문제가 발생했다.

반면, 70개국 개별 배포는 비용과 운영 복잡도가 너무 높았다.

결론적으로, 4개 주요 리전(한국 포함) 에 리전 단위 배포를 진행하여 성능과 운영 효율의 균형을 맞췄다.

5️⃣ 데이터베이스 선택: DynamoDB 중심 아키텍처

1억 명 고객 × 1만 세그먼트 = 1천억 관계 데이터라는 규모에서 데이터 저장 효율성과 비용을 모두 고려해야 했다. 후보로는 Redis, DynamoDB, Cassandra를 검토했고, 확장성·일관성·운영 효율성을 이유로 DynamoDB를 선택했다.

<비용 최적화 전략>

• 세그먼트 CDC를 통한 변경분만 업데이트

• DynamoDB TTL로 만료된 데이터 자동 삭제 (비용 청구 없음)

• 이 방식으로 일일 데이터 업데이트 비용을 대폭 절감했다.

6️⃣ 성능 최적화: 빠르고 안정적인 응답

아래는 버즈 서비스 팀에서 성능 최적화를 방법들이다.

1. 카페인 캐시(Caffeine Cache)

• 메타데이터를 로컬 캐시로 관리해 DB I/O 최소화

2. 커넥션 풀 및 Keep-Alive 설정

• 초기 핸드셰이크 비용 제거, 연결 재사용

3. Fail-Fast 전략

• 지연이 발생하면 빠르게 실패 후 재시도 (테일 레이턴시 개선)

4. Request Hedging

• 동일 요청을 두 번 보내 빠른 응답을 선택해 안정성 확보

결과적으로, 글로벌 환경에서 P95: 10ms / P99: 20ms 수준의 성능을 달성했다.

7️⃣ 글로벌 운영 후기와 교훈

글로벌 운영을 하면서 버즈 서비스 팀은 여러가지를 배웠다고 한다. 발표만 들었는데도 너무나 방대한 영역이었기에 얼마나 노력하셨는지 감도 오지 않았다.

어려움

• 기술 부채를 일시적으로 상환해야 하는 고통 (3개월 이상 소요)

• 버즈/세그멘텀 간 기술 스택 차이로 인한 복잡성

• DH는 독일에 있기에 한국과는 시차가 7시간이 난다. 또한 언어·문화적 장벽이 존재하였다.

얻은 교훈

• 확장 가능한 아키텍처 설계의 중요성

• 기술 도입의 명확한 기준 필요성

• 글로벌 협업에서의 신뢰와 원팀 문화의 가치

🧐 세션 후기

사용자 규모를 들었을 때 가장 먼저 떠오른 감정은 “1억 5천만 명이 사용하는 서비스에 대한 경외심”이었다.

모잇지 서비스를 개발하며 수백 명의 트래픽만으로도 성능과 안정성을 고민했던 입장에서, 이 수치는 단순한 숫자가 아니라 ‘설계 철학의 깊이 차이’로 느껴졌다.

다만 아직 주니어 개발자 준비생으로서 대규모 트래픽 환경을 직접 경험해보지 못했다는 점에서, 이런 감정은 어쩌면 당연한 것일지도 모른다.

더 나은 이상 탐지를 위한 여정: 서버부터 서비스, 그리고 문화 까지

이번 세션을 통해 처음으로 *SRE(Site Reliability Engineering) * 팀의 존재를 알게 되었다. 사실 ‘SRE’라는 용어조차 이번에 처음 들었다. 하지만 이번 세션을 들으면서 그들이 얼마나 중요한 역할을 하는지, 내가 과거에 경험했던 단순한 로그 수집이나 모니터링 작업이,SRE의 관점에서 체계적으로 확장되면 어떤 수준의 관리로 발전할 수 있는지 구체적으로 이해할 수 있었다.

1️⃣ SRE란 무엇인가

SRE(Site Reliability Engineering)는 시스템 신뢰성을 보장하기 위한 기술·문화적 접근 방식이다. 회사마다 약간씩 SRE에 대한 정의가 다르기에 우아한 형제들을 기준으로 설명하겠다.

우아한형제들에서는 SRE를 다음과 같은 네 가지 영역으로 정의하고 있다:

1. 관찰 가능성 확보

• 로그·메트릭·트레이싱 등으로 서비스 상태를 실시간 파악

2. 이상 탐지 및 경보 체계 구축

• 장애 전조를 조기에 인지

3. 장애 대응 정책 및 전파 프로세스 설계

4. 후속 조치 및 재발 방지 관리

이러한 체계를 통해 서비스 신뢰성을 높이고, 장애 발생 시 복구 시간을 최소화하는 것을 목표로 한다.

2️⃣ 왜 이상 탐지가 중요한가

배달의민족 서비스에서 장애는 곧 사용자 경험 저하와 매출 손실로 이어진다. 완벽한 장애 예방은 불가능하며, 빠른 감지와 대응 속도가 핵심 경쟁력이다. 따라서 SRE팀은 “장애를 없애는 것보다, 빠르게 복구하는 체계”에 집중하고 있다.

3️⃣ 초기 접근: 전사 경보 시스템

과거 배달의 민족에서는 각 팀이 독립적으로 모니터링을 운영했기 때문에 아래와 같은 문제점이 있었다.

• 모니터링 사각지대 발생

• 경보 기준 불일치

• 담당자 부재 시 대응 지연

이를 해결하기 위해 중앙 통합 경보 시스템을 구축했다.

• 핵심 지표(트래픽, 오류율, 응답 시간 등)를 표준화

• 전사 공통의 알림 기준 수립

• 운영자 개입 없이 자동화된 경보 발송

이 과정을 통해 운영 문화의 일원화와 그레이존 축소라는 효과를 얻었다.

4️⃣ 서비스 이상 탐지 시스템 기획

SRE팀은 단순한 인프라 수준의 모니터링을 넘어, 서비스가 정상적으로 동작하고 있는지를 판단할 수 있는 상위 레벨의 모니터링 시스템이 필요하다고 보았다.

여기서 말하는 ‘서비스 지표’는 CPU, 메모리, 네트워크와 같은 시스템 리소스 지표가 아니라 비즈니스 지표, 즉 서비스의 성능과 품질을 나타내는 지표를 의미한다.

예를 들어, 서비스가 정상적으로 작동한다면 특정 주문 건수나 결제 성공률 등이 일정한 패턴을 유지해야 한다. 하지만 서비스의 ‘정상 상태’에는 정답이 없다. 비즈니스 환경은 끊임없이 변화하며, 외부 요인(이벤트, 날씨, 트래픽 변화 등)에 따라 지표도 달라지기 때문이다.

5️⃣ 장애 탐지 및 대응 프로세스

우아한형제들 SRE팀은 서비스 장애 탐지를 위해 중앙값 기반의 예측값과 실시간 데이터를 비교하여 편차가 임계치에 도달하면 경보를 발생시키는 전략을 도입했다.

이를 통해 불필요한 오탐(False Positive)을 최소화하고, 이상 상황을 신속히 감지하여 장애 대응 속도를 대폭 단축할 수 있었다.

6️⃣ 서비스 조직과의 협업

이 시스템은 SRE팀 단독이 아닌, 서비스 조직과의 공동 설계를 통해 완성되었다.

기존 문제

• 조직별 지표·경보 기준이 상이

• 전사적 장애 현황 파악 불가

• 경보 의미 불명확, 대응 절차 비일관적

해결 방향

• 표준화된 서비스 지표 정의

• 통일된 경보 포맷 및 대응 프로세스 적용

• 조직별 맞춤 인터뷰 및 협업 설계 → “획일화가 아닌, 비즈니스에 맞춘 표준화”

7️⃣ 성과와 배운 점

1. 완벽보다 실행 우선 빠르게 시도하고 빠르게 실패해야 개선이 가능하다.

2. 유저 중심의 지표 선정 CPU·메모리보다 사용자의 액션을 반영한 지표가 효과적이다.

3. 공동의 목표 설정 SRE와 서비스 조직이 각자의 역할에 집중해야 시너지가 난다.

🧐 세션 후기

우선 발표자분의 한 말씀이 굉장히 인상적이었다.

장애를 근본적으로 방지하는 것은 불가능에 가깝다.사실 아무것도 안 하면 장애는 거의 발생하지 않는다. 근데 이제 회사는 계속 일을 해야 되고 더 나은 서비스를 만들어야 되기 때문에 변화가 계속 있고 이런 변화가 있는 한 장애는 피할 수가 없다. 그래서 이렇게 장애가 필연적이라면은 결국 서비스를 좀 빠르게 복구하는 데 집중을 해야 되겠죠.

이 말이 이번 세션의 핵심을 가장 잘 설명한다고 느꼈다. SRE의 본질은 장애 ‘예방’이 아니라 장애 ‘복구 능력’을 체계화하여 장애 복구 시간을 최소화 시키는것이라고 생각하고 우리가 지향해야할 부분이라고 생각한다.

ServerSentEvents로 실시간 알림 전송하기

이 세션은 기대를 했고, 열심히 따라가려고 노력했지만 아쉽게도 잘 이해가 되지 않았다... 내가 SSE를 경험해봤다면 도움이 되겠지만, 기본 지식이 없는 상태에서 듣다보니 머릿속에 남은 것이 적었다.😢

이번 세션은 추후 SSE를 사용하게 될 날을 기약하며 단순히 발표내용을 정리하는것으로 마무리 하려고한다.

💡이 세션은 기록된 내용을 가독성을 향상 시키는데 집중하였습니다. 잘못된 부분이 있다면 댓글에 기재해주면 감사하겠습니다.

들어가며

주문 접수 채널 팀에서는 수십만 파트너들이 주문을 쉽고 빠르게 처리할 수 있도록 PC 앱, 안드로이드 키오스크 등 다양한 프로그램을 개발하고 있다. 식당에서 들리는 주문 알림음, 그 시스템을 어떻게 개선했는지 이야기해보겠다.

1️⃣기존 MQTT 알림 시스템

기존 시스템은 MQTT 브로커를 통해 알림을 전송했다. 클라이언트가 MQTT에 연결하여 토픽을 구독하면, 도메인 서버에서 변경 사항 발생 시 메시지를 발행하고, 클라이언트는 이를 수신해 API로 상세 정보를 조회한 후 알림을 표시했다.

2️⃣기존 시스템의 문제점

제로 페이로드 문제 레거시 클라이언트에서 긴 페이로드가 잘리는 문제로 인해 변경 ID만 전송하고 클라이언트가 API로 상세 정보를 조회했다. 이로 인해 알림 로직이 클라이언트에 있어 문구나 시점 변경 시 앱 업데이트가 필수였다.

보안 문제 토픽 구독에 인증이 없어 다른 파트너의 토픽 구독이 가능했다. 다만 제로 페이로드였기에 유의미한 정보는 API 호출로만 얻을 수 있어 큰 문제는 없었다.

네트워크 문제 MQTT가 사용하는 1883, 8883 포트가 일부 환경에서 방화벽에 차단되어 폴링 로직이 추가로 필요했다.

웹뷰 연결 문제 웹뷰에서 여러 탭이 동시에 열리는 환경에서 MQTT 인증서 관리의 복잡도가 높았다.

3️⃣ AWS IoT 도입

AWS IoT를 도입하여 일부 문제를 해결했다.

보안 강화: x509 인증서 발급 시 자신의 토픽만 구독 가능하도록 권한을 부여했다.

페이로드 정형화: 보안이 강화되어 페이로드에 유의미한 정보(title, content, eventType, soundType 등)를 포함시켰다. 클라이언트는 수신 즉시 알림을 표시하게 되어 버전 종속성이 사라졌다.

하지만 MQTT를 사용하는 한 네트워크와 웹뷰 문제는 여전했다.

4️⃣ SSE 도입

왜 SSE인가?

실시간 통신 방식을 검토했다.

• 폴링: 주기적 요청으로 비효율적
• 웹소켓: 양방향 통신이지만 모든 API를 웹소켓으로 재정의해야 하는 오버 엔지니어링
• SSE: 서버에서 클라이언트로 단방향 푸시, 기존 API 구조 유지 가능

알림만 필요한 발표자의 상황에 SSE가 적합했다.

5️⃣ 메시지 전달 방식 선택

세 가지 방식을 검토했다.

1. 세션 연결 서버로 API 호출: 성능은 좋지만 세션 관리 복잡, 유실 가능성
2. 브로커로 특정 서버에 전송: 순서 보장되지만 토픽 관리 복잡, 유실 가능성
3. 모든 서버로 브로드캐스트 후 필터링: 간단하고 순서 보장, 쉬운 스케일 아웃

메시지 신뢰성이 가장 중요했기에 3번 방식을 선택했다.

6️⃣ 메시지 안정성 확보

Last-Event-ID 활용

SSE 표준인 Last-Event-ID 헤더를 활용했다. 클라이언트가 마지막 수신 ID를 헤더로 전송하면, 재연결 시 그 이후 메시지를 조회해 전송하여 순단 중 유실을 방지했다.

커밋 메시지

주문서 출력, 신규 알림 등 중요 메시지는 정확히 한 번만 전달되어야 했다. commitUrl을 포함한 메시지를 전송하고, 클라이언트가 수신 시 이를 호출하면 서버에서 마킹했다. 주기적으로 미커밋 이벤트를 조회해 재발행했다.

보안 강화

같은 세션의 동시 접속을 차단했다. 세션 매니저로 활성 세션을 관리하고, 메시지 전송 전 세션 유효성을 검증해 비정상 세션은 강제 종료했다.

폴링 제거

클라이언트의 다양한 폴링 로직을 서버로 이동시켰다. SSE 연결 시 서버가 각 도메인을 주기적으로 호출하고, 변경 시에만 클라이언트에 전송해 API 호출을 줄였다.

7️⃣ 전환 과정의 문제들

백프레셔 문제

코루틴 채널을 기본값(capacity=RENDEZVOUS, 즉 0)으로 생성해서 버퍼가 없었다. 메시지 처리가 지연되면 Kafka max.poll.interval이 초과되어 파티션 할당이 해제되었다. 적절한 capacity와 onBufferOverflow 설정으로 해결했다.

배포 시 CPU 스파이크

배포로 연결이 끊기면 모든 클라이언트가 동시에 재연결을 시도했다. 연결 유지 시간이 일정해 주기적으로 CPU가 급증했다. 연결 유지 시간과 재연결에 랜덤 지터를 부여해 해결했다.

불필요한 네트워크

앱, PC, 웹뷰 등 프로그램별, 버전별로 처리 가능한 메시지가 달랐지만 모든 메시지를 전송했다. 연결 시 처리 가능한 이벤트 타입을 받아 필터링하여 불필요한 네트워크 I/O를 제거했다.

8️⃣ 향후 개선 계획

메시지 브로커 변경: Kafka 대신 Redis Stream이나 NATS 같은 경량 프로토콜을 검토 중이다.

모바일 앱 SSE 도입: 포그라운드에서는 SSE, 백그라운드에서는 푸시로 전환하여 속도와 비용을 개선할 예정이다.

9️⃣ 결론

SSE 도입으로 다음과 같은 성과를 얻었다.

• 서버 비용 절감 및 일평균 4천만 건의 안정적 처리
• 폴링 제거로 네트워크 트래픽 감소
• 클라이언트 업데이트 없이 알림 제어 가능
• 코틀린 코드로 작성되어 쉬운 수정 및 반영
• 웹뷰 지원 및 보안 강화

BROS 레거시 스파게티 코드 개선

이 세션을 들은 이유는 우아한테크코스를 진행하며 프로젝트의 레거시 코드를 리팩토링하는 경험을 해보았기 때문이다.

내 기억상 리팩토링 과정은 힘들었었다. 리팩토링 이전에는 구현 능력이 중요하다고 생각했는데, 리팩토링을 시작하며 설계 능력의 중요성을 체감하였다. 아직 전체적인 아키텍쳐 설계 능력이 부족했던 나로서는 리팩토링 과정이 가장 고통스럽기도 하였다.😢

이러한 이유로 조언 혹은 배움을 얻을 수 있을까 싶어 해당 세션에 참여하였다. BROS는 우아한 형제의 수백개의 프로젝트 중에서 10년 동안 유지보수 되어왔던 레거시 코드이며 10손가락 안에드는 코드라인수를 가졌다. 과연 BROS팀은 어떻게 리팩토링을 하였을까?

단계별로 발표내용을 분석해보겠다.

1️⃣ BROS의 시스템 구조와 문제점

멀티 모듈 프로젝트 구조

BROS는 여러 서버와 여러 공통 모듈이 존재하는 멀티 모듈 프로젝트로 구성되어 있다. 주요 서버들은 '딜리버리 서비스'라는 공통 모듈을 의존하고 있으며, 이 공통 모듈에 기능을 작성하면 여러 서버에서 사용할 수 있다. 그 결과 쉽게 기능이 추가되어 대부분의 비즈니스 로직을 포함한 매우 거대한 모듈이 되었다.

진짜 문제는 이 거대한 공통 모듈을 여러 팀이 커밋하고 있다는 점이다.

R&R 문제

💡R&R 이란?
R&R은 Role & Responsibilities의 약자로, 조직 내에서 각 구성원이 맡은 역할과 책임을 뜻한다.

여러 팀이 하나의 공통 모듈을 관리하면서 다음과 같은 문제가 발생했다.

• 브랜치가 너무 다양하고 복잡
• 원치 않은 레거시 코드와 코딩 스타일 마주침
• R&R 논의, 개발 검토, 리뷰, 배포 이후 조치 등 팀과 팀을 넘어 과한 커뮤니케이션 발생

결과적으로 역할을 넘어선 과도한 비용이 발생했다.

스파게티 코드 문제

딜리버리 서비스 모듈 안에는 배달 관련 기능이 있고, 이 기능이 수행되면 애플리케이션 이벤트를 발행한다. 그러면 이벤트 리스너 또는 트랜잭셔널 이벤트 리스너로 구현된 후처리 리스너에서 나머지 동작을 수행하는 구조였다.

이벤트와 리스너의 복잡한 관계

• 배달 이벤트: 약 39개
• 후처리 리스너: 19개

서비스 A가 기능을 수행하면 애플리케이션 이벤트를 발행하고, 리스너 B, C, D에서 각각 이벤트를 소비한다. 문제는 리스너가 단순히 종료되지 않고, 다시 순환 호출되거나 다른 도메인을 호출하는 경우가 있다는 점이다. 그 서비스에서 또 다른 이벤트를 발행하면 대응되는 리스너들이 또 이를 소비하는 방식으로, 서비스와 리스너가 N:M 관계를 가지고 서로 복잡하게 호출하는 구조였다.

❗결과적으로

• 개발 검토 중 길을 잃어버리기도 함
• 높은 인지 부하로 위험 요소 증가
• 영향 범위 파악에 매우 큰 비용 발생

2️⃣ 해결과정

이 과제의 핵심은 사실 RNR 정리 과정을 통해 공통 모듈이 엮여있는 역할과 책임을 분리하는 것이었고, 이를 위해 선행 업무로 코드 청소를 먼저 해야 되고 그다음에 또 성능 개선까지 같이 챙겨야 하는 미션을 받았다.

1. 🧹복잡한 코드 청소: 애플리케이션 이벤트 리스너 정리

코드 청소를 위해 다음 단계를 이어갔다.

1. 일단 먼저 사용 여부와 대체제를 확인한 뒤에 삭제를 먼저 검토했다.
2. 처리 리스너 내에 존재하는 비즈니스 로직들을 각 도메인에 맞게 리팩터링을 진행을 했다.
3. 최종적으로 이제 애플리케이션 이벤트 리스트를 삭제하는 방향으로 가져갔고 이 리팩터링한 기능을 직접 메소드 콜 방식으로 개선했다.

결과

• 리스너가 19개 → 5개로 감소 (14개 제거)
• 리스너 로직 간소화 및 도메인 응집도와 가시성 향상
• 불필요하게 긴 트랜잭션을 짧게 축소

2. 💫 R&R 정리

R&R 정리는 가장 메인이 되는 과제였다. 공통 모듈 사이의 역할과 책임을 끊어어 내고자 많은 노력을 했음이 보였다.

1. 라이더 서버

문제점

• 라이더 서버는 라이더 팀 담당이지만 배달 수행에 직접 트랜잭션을 실행하는 역할이 과도함
• 공통 모듈을 계속 수정해야 하는 부담
• 액터(라이더 vs 관리자)에 의존하는 로직이 공통 모듈에 존재

해결 배달 서버를 중간에 투입했다. 네트워크 구간은 증가했지만 배달 수행의 직접 트랜잭션 실행 역할을 배달 서버에 부여하고, 라이더 서버는 배달 서버를 호출하는 방식으로 역할을 축소했다. 액터에 의존한 로직은 배달 서버와 어드민 서버 각각 앞쪽으로 이관하고, 공통 모듈에는 배달 도메인에 집중한 코드만 남겼다.

2. 라이더 메시지 도메인

문제점 관리자의 주소 변경, 고객/사장님의 주문 취소 시 라이더에게 동선 변경을 알리는 웹소켓 발행 코드가 공통 모듈에 존재했다. 배달팀 입장에서 담당 도메인도 아니고 코드 수정이 어려웠다.

해결 배달 이벤트를 라이더에게 보낼지, 어떻게 보낼지 결정하는 도메인은 라이더에 더 가깝게 위치해야 한다고 합의했다. 메신저 서버를 활용하여 기존 웹소켓 발행 기능을 모두 이관시켰다. 기존 애플리케이션 이벤트 리스너는 Kafka를 사용해서 서버 분리를 진행했다. 메신저 서버에서 Kafka를 통해 이벤트를 소비하고 여기에서만 웹소켓이 발행되도록 R&R을 정리했다.

3. R&R 정리: 문의 내역 도메인

라이더와 상담사를 연결하는 도메인이 공통 모듈에 위치했다. 새로운 공통 모듈을 만들고 리팩토링하면서 코드를 이관했다. 소프트한 경계 격리를 의도했다.

3. ⭕성능 개선: API 3대장 개선

라이더 서버의 가장 많이 호출되는 API인 '배달 진행 목록' API를 대상으로 성능 개선을 진행했다.

문제점

• 반복적으로 DB 조회 수행
• REST Call이 있음에도 트랜잭션을 길게 사용
• 방어 로직을 수행하는 Insert 기능을 위해 Writer DB를 오랫동안 점유

해결

• 배달 서버를 중간에 두고 DB 사용을 모두 위임
• 불필요한 단계 제거
• 중복된 DB 사용을 줄이고 리더 DB 사용
• REST Call 시점에 트랜잭션이 포함되지 않도록 처리
• 방어 로직 수행 시 잠깐만 Writer DB를 사용하도록 트랜잭션 범위 최소화
• Response 크기 경량화

3️⃣ 성과

1. ⭕ 코드 품질 개선

스파게티 코드 제거

• 이벤트 리스너: 19개 → 5개 (14개 제거)
• 기존 마이너 버그와 취약점 개선
• 미사용 비즈니스 로직, 테이블 적재, 리소스 제거

복잡도 감소

• 프로젝트 전체 코드: 3천 라인 증가 (4개월간 다른 팀 개발 병행)
• 순환 복잡도와 인지 복잡도 감소 (코드량 증가에도 불구하고)
• 특히 공통 모듈: 1만 라인 이상 제거, 복잡도 크게 감소

테스트 커버리지 향상

• 30% 초반 → 36% 상승
• 리팩토링한 코드들의 커버리지 대부분 70~80% 이상

2. ⭕ R&R 정리

• 라이더 서버: 역할과 책임 축소
• 메신저 서버: 배차 추천/거절 시점만 사용 → 배달 전반적인 부분으로 확대
• 배달 서버: 배달 내역 서빙 역할 → 라이더의 배달 수행 처리로 재정의

3. ⭕ 성능 개선

서버 관점

• 주요 API 레이턴시: 약간 감소 (중간 서버 추가로 네트워크 구간 증가했으나 성능 유지)
• 리스폰스 사이즈: 최대 44% 감소

DB 관점

• 저녁 타임 피크 기준 라이터 DB CPU: 최대 7% 감소 (비싼 머신 사용 중이라 큰 변화 기대 어려웠으나 성과 달성)
• 데일리 기준 라이터 DB CPU: 5% 이상 감소
• 리더 DB CPU: 각각 1%, 2.7% 증가 (트랜잭션 분리하여 라이터 DB 사용 줄이고 리더 DB로 전환한 의도대로 작동)

4. 무장애 달성

4개월간 개선 업무로 장애 발생 없음 - 참여자들이 가장 만족하는 성과

🧐 세션 후기

대규모 프로젝트의 리팩토링 과정을 들으며, 만약 내가 시작한다면 어디서부터 손대야 할지 상상해보았다.

결론적으로, "네! 10분 동안 멍만 때렸습니다."

리팩토링 능력을 키우려면 어떻게 해야 할까? 애초에 모든 것을 고려한 설계란 가능한 것일까? 책을 더 읽고, 다른 사람들의 코드를 관찰하며 학습할 필요가 있겠다.

RAG, 들어는 봤는데... 내 서비스엔 어떻게 쓰지?

이번 세션은 개인적으로 가장 기대했던 부분이다. ‘모잇지’ 프로젝트에서는 핵심 로직에 AI를 직접 활용해보았고, 앞으로는 단순히 학습 데이터에 기반한 응답이 아닌, 실제 데이터 기반의 신뢰성 높은 응답으로 서비스를 발전시키고자 했다.

그 과정에서 주목한 개념이 바로 RAG(Retrieval-Augmented Generation) 이다. RAG는 최근 AI 분야에서 가장 주목받는 트렌드 중 하나로, 관련 학습 자료도 다양하게 존재했다. 그러나 여러 자료를 살펴보아도, 우아한테크코스 백엔드 코치 검프 의 설명만큼 명확하게 이해되는 것은 없었다.

1️⃣ RAG가 필요한 이유

LLM을 사용할 때 쿼리를 던지면 때로는 정상 응답이 오고, 때로는 응답이 불가하거나 환각(Hallucination) 현상이 발생한다. LLM이 바보라서일까? 아니다. 이런 일이 발생하는 이유는 LLM이 인터넷에 있는 정보와 학습 모델이 가진 자체 데이터로만 학습했기 때문이다. 환각이 발생하는 이유는 학습 데이터에 없는 것을 요청했기 때문이다.

▪️예시

질문: "이번 주 미팅 일정은?" 결과: 환각 발생 (LLM의 학습 데이터에 없는 정보)

당연한 결과이다. 사람의 경우에도 누군가가 대뜸 이런 질문을 하더라도 그 사람의 일정에 대해 모른다면 대답을 할리 만무하다.

해결 방법은 쿼리 + 컨텍스트을 같이 제공한다. 캘린더 파일과 함께 "이번 주 미팅 일정은?"이라고 보내면 LLM이 쿼리와 컨텍스트를 이해하고 정상적인 응답을 할 수 있다.

▪️쿼리-컨텍스트 결합도 증가

이때 새로운 문제가 발생한다. 준비해야 할 쿼리-컨텍스트가 많아지면 어떻게 될까?

"이번 주 미팅 일정은?" "기획서 내용 요약해줘" "데이터가 존재하는지 확인해줘"

쿼리-컨텍스트 결합도가 증가하면 또 다른 문제가 발생한다. 쿼리로는 "이번 주 미팅 일정은?"이라고 보냈는데 컨텍스트로 파일 시스템 정보를 주면 LLM이 이해하지 못하고 잘못된 응답을 받게 된다.

2️⃣ RAG란?

RAG는 이러한 문제를 해결한다. 사용자가 쿼리를 보내면 그 쿼리에 맞는 정보를 지식 베이스에서 검색해 온 다음, 검색해 온 내용을 바탕으로 쿼리와 함께 LLM에게 정보를 보내어 정상적인 응답을 받게 하는 것이다.

💡 한마디로 RAG란
LLM이 새로운 정보를 검색하고 통합할 수 있도록 하는 기술

3️⃣RAG의 3가지 핵심 컴포넌트

1. 색인(Indexing) 파이프라인 문서를 검색 가능한 형태로 준비하고 저장하는 단계. 예를 들어 캘린더 파일을 검색해서 가져오기 위해 미리 준비하는 것이다.

2. 생성(Generation) 파이프라인 질문에 맞는 정보를 검색하고 답변을 생성하는 과정. 색인 파이프라인에서 준비된 파일을 가져와 LLM에게 던지고 정상적인 응답을 받게 하는 과정이다.

3. 평가(Evaluation) 사용자와 직접 인터랙션하지는 않지만 시스템의 품질을 측정하고 개선하기에 필수적인 요소다.

4️⃣ RAG 구현 6단계

(실은 이전에 검프가 교육 운영 RAG를 만들기 위해 MCP 를 도입하는 과정이 있었지만 내용이 길어 이번에는 적지 않았다.)

💡RAG 구현 6단계 요약

1. 사용 사례 식별 및 RAG 필요성 평가: RAG의 필요성 확인
2. 요구 사항 수집 및 분석: RAG 시스템에 필요한 요구 사항 분석
3. RAG 프레임워크 결정: Spring AI 선택
4. 색인 파이프라인 구현: 로딩, 청킹, 임베딩, 저장소
5. 생성 파이프라인 구현: 검색, 증강, 생성
6. 평가 구현: 컨텍스트 관련성, 답변 충실성, 답변 관련성

RAG를 구현하기 위해서는 위의 여섯 단계가 필요했다. 이 여섯 단계가 완료되어야 운영 배포가 완료되었다고 말할 수 있다.

이제부터 단계별로 요약하여 설명하겠다.

1. 사용 사례 식별 및 RAG 필요성 평가

RAG가 듣고보니 정말 좋은데 모든 AI 관련 프로젝트에서 도입하면 좋지 않을까? 그렇지 않다. RAG를 무조건 써야 한다고 생각하면 배보다 배꼽이 커지는 경우가 발생한다. 한다. RAG는 쿼리-컨텍스트 결합도가 많이 증가할 때가 RAG 도입 시점이다.

RAG가 필요한 경우

• 실시간으로 정보가 업데이트되는 경우
• 도메인 내 특화 지식이 필요한 경우

RAG가 불필요한 경우

• 간단한 질의응답
• 업데이트되지 않는 정적 데이터
• 일반적인 대화

2. 요구 사항 수집 및 분석

3. RAG 프레임워크 결정

어떤 프레임워크를 사용할지 결정하는 단계다. 검프는 RAG 구현시 스프링 AI를 선택했고 이유는 아래와 같다.

Spring AI vs LangChain 비교

유의사항

• 프레임워크의 장점보다 팀이 익숙한 언어 환경이 생산성에 더 큰 영향을 미침

• 혼자 개발하거나 배울 수는 있지만 팀 내 코드 리뷰나 코멘트를 받으려면 팀원들이 익숙한 언어가 훨씬 생산성이 좋음

• 모든 항목에서 가능한 것은 없음 - 우리 상황에서 중요한 것의 우선순위 결정 필요

• "완벽함보다 빠른 검증" 슬로건으로 빠른 빌드, 배포, 검증이 가능한 Spring AI 선택

4. 색인 파이프라인 구현

문서를 검색 가능한 형태로 준비하고 저장하는 단계다. 핵심 요소는 로딩, 청킹, 임베딩, 저장소 네 가지다.

4-1. 로딩 (Loading)

데이터 소스를 연결하고 수집하는 요소다. 캘린더 API를 통해 캘린더 파일을 가져온다고 생각하면 된다.

고려 사항

• 어떤 데이터 연결: DB, 구글 드라이브, 캘린더

• 어떤 포맷 파싱: JSON, 텍스트, XML

• 데이터 정제: 개인정보 마스킹, 중복 제거

유의사항

• 텍스트 데이터를 먼저 고려한다. (이미지, 음성, 비디오는 이후 모든 프로세스 변경 필요)

• 외부 API 호출 제한에 유념한다.

• 한 번에 모든 데이터를 가져올지, 조금씩 가져올지 확인한다.

4-2. 청킹 (Chunking)

데이터를 검색 가능한 단위로 분할하는 요소다. 캘린더에서 가져온 파일을 검색 가능한 단위로 잘게 쪼갠다고 생각하면 된다.

고려 사항

• 분할 전략: 고정 크기 청킹, 부모-자식 구조

  • 고정 크기 청킹: 청크 크기를 미리 결정
  • 부모-자식 구조: 부모 청크에는 전반적인 요약, 자식 청크에는 세부 사항과 부모 청크 정보 또는 시퀀스 번호

• 크기와 중복: 5천 자 (Spring AI 기본값), 중복 없음 (부모-자식 구조)

• 메타데이터: 출처, 시간, 구조 정보 저장

유의사항

• 청크 크기 최적화가 필요하다.

  • 작으면: 빠르고 성능 좋지만 문맥적 검색 신뢰도가 떨어진다.
  • 크면: 성능 떨어진다.
  • 도메인 특성에 따라 설정하는 것을 추천한다.

• 청킹 전략에 따라 분할로 인한 의미 손실 발생 - 도메인 고려하여 손실 허용 범위 설정

• 메타데이터는 필수다. 청크된 데이터의 의미를 정리해 주는 데이터가 있으면 검색 시 더 나은 성능

4-3. 임베딩 (Embedding)

분할된 내용을 컴퓨터가 이해하는 n차원 형태로 변환하는 것이다. 배열의 각 요소가 차원이고, 각 차원의 숫자들이 분할한 데이터를 표현한다.

유의사항

• 파운데이션 모델로 항상 먼저 검증

• 도메인 속성에 따라 파인 튜닝할 수 있지만 처음 전체 플로우를 해볼 때까지는 파운데이션 모델 사용

• 차원 수는 높을수록 성능 좋지만 비용 증가 - 적절한 수 선택

4-4. 저장소 (Storage)

임베딩된 데이터를 저장하고 검색할 서비스다. 컴퓨터가 이해할 수 있는 벡터 형태로 변환된 파일을 나중에 검색하기 위해 저장한다.

5. 생성 파이프라인 구현

질문에 맞는 정보를 검색하고 답변을 생성하는 과정이다. 핵심 요소는 검색, 증강, 생성 세 가지다.

5-1. 검색 (Retrieval)

사용자 질문에 가장 관련성 높은 청크를 추출하는 것이다. 색인 단계에서 저장된 청크들을 검색기에서 가져온다.

고려 사항

• 검색 전략: 저장소 기본 설정인 문맥적 임베딩 사용
  • 문맥적 임베딩: 문맥 기반 검색 (예: "애플"이 과일인지 회사인지 구분한다)
• 사용자 질문 최적화: LLM을 이용하여 최적화한다. (불필요한 것은 버리고 필요한 것만 남긴다)

유의사항

• 메타데이터 필터링으로 검색 효율성 향상: 데이터 세부 내용보다 필터링된 내용 검색이 효율적이다.

• 청크 개수 설정 필요: 많이 가져올수록 컨텍스트 윈도우가 빠르게 소비 된다.

• 유사도 점수 기준 필요: 우리 도메인에서 어느 정도 유사도까지를 맞다고 판단할지 설정해야한다.

• 검색된 데이터의 정밀도는 평가 단계에서 면밀히 검토한다.

5-2. 증강 (Augmentation)

검색된 청크를 사용자 질문과 결합하여 LLM에게 전달하는 요소다. 사용자 질문과 검색된 데이터를 프롬프트와 함께 던지는 과정이다.

고려 사항

• 페르소나를 정의: 예시) AI가 수행할 역할이나 성격을 "교육 운영 데이터를 검색해 주는 서비스"

• 컨텍스트 제약: 검색된 내용으로만 답변

• 프롬프팅 기법: 추론 과정을 응답하도록 요구, 답변 형식을 특정 형식으로 지정

유의사항

• 검색된 청크 원본 유지하여 검증: 프롬프트를 수정하다 청크가 너무 커져도 청크 수정보다는 프롬프팅 수정이나 청크 개수를 조정한다.

• 프롬프트 명확히 제시: "검색된 내용으로만 답변해", "이런 응답 형식으로 답변해" 등 명확한 제약

• 프롬프트도 컨텍스트 윈도우 사이즈에 포함 - 간결화가 필요하다.

5-3. 생성 (Generation)

증강된 프롬프트를 받아 최종 응답을 생성하는 요소다. 쿼리, 컨텍스트, 프롬프트를 LLM이 받아서 사용자에게 응답하는 과정이다.

유의사항

• 파운데이션 모델로 먼저 검증: 오픈소스 모델, 파인 튜닝 모델도 있지만 처음에는 범용 모델로 모든 프로세스를 검증하는 것을 추천한다.

• 프롬프트의 점 하나로 결과값이 크게 달라진다.(진짜로)

• 모델 자체가 바뀌면 기존에 잘 나오던 것도 안 나올 수 있다.

• 모델 크기는 도메인의 가치에 따라 설정한다 : 방대한 데이터 검색이나 의료 정보는 큰 모델, 단순 캘린더 일정은 작은 모델을 선택한다.

• 성능과 속도 사이의 트레이드 오프 필요가 필요하다: 늦더라도 정확한 답변 vs 빠르지만 부족한 답변 사이의 트레이드 오프가 필요하다.

• 증강된 데이터의 품질은 평가 단계에서 고려한다.

6. 평가 구현

시스템의 품질을 측정하고 개선하는 과정이다. 세 가지 큰 지표를 측정한다.

6-1. 컨텍스트 관련성 (Context Relevance)

검색된 정보가 사용자 질문과 얼마나 관련성이 높은지를 평가하는 지표다.

6-2. 답변 충실성 (Answer Faithfulness)

생성된 답변이 검색된 정보에 얼마나 사실적으로 근거하는지 평가하는 지표다.

6-3. 답변 관련성 (Answer Relevance)

생성된 답변이 사용자 질문과 얼마나 관련성이 높은지 평가하는 지표다.

2025 우아콘을 마치며🎉

처음의 마음가짐

사실 처음 마음가짐은 "컨퍼런스 현장의 분위기를 느끼자"였다.

아마도 마음 한편에 발표를 하시는 개발자 분의 내용을 내가 감히 이해할 수 없을 거라는 주눅이 들었었나 보다.

예상과 달랐던 경험

하지만 막상 발표를 들어보니 발표 내용이 이해가 되었고, 너무나도 배울 점이 많았다.

우테코에 들어오기 전이라면 하나도 알아듣지 못했을 내용들이 전부는 아니더라도 귀에 들어오고, 발표 내용에 대해서 고민까지 할 수 있게 되었다.

실제로 슬리도를 통해 발표자 분께 이것저것 질문을 하고 답변을 받는 경험을 할 수 있었기에, 우아한형제들의 현업 개발자 분들과 커뮤니케이션을 하고 있다는 사실에 더욱 뿌듯했던 것 같다.

성장의 원동력

아마도 이 모든 것은 우테코 내의 커리큘럼에 녹아있던 교육철학을 자연스레 배운 덕분이라 생각한다.

다시 한번 이런 소중한 경험을 주신 코치님들과 다양한 이야기를 나누었던 크루들에게 감사함을 전하고 싶다.

앞으로의 다짐

앞으로도 이러한 컨퍼런스에 자주 참여할 것 같다.

동기부여도 되고 다양한 개발자들의 모습을 볼 수 있다는 것은 많은 것을 배우게 해준다.

2025 우아콘은 내 인생 첫 컨퍼런스였고, 최고의 경험이었다! 🎉

이번 글에서는 한 단계 더 나아가 커스텀 예외(Custom Exception)를 가 무엇인지, 올바른 커스텀 예외 생성 방법에 대하여 써보았다.

커스텀 예외(Custom Exception)

예외 처리를 학습하다 보면 한 가지 의문이 생긴다.

“표준 예외(IllegalArgumentException, IOException 등)만으로 충분할까?” “우리 서비스의 도메인 로직을 반영한 의미 있는 예외는 어떻게 만들어야 할까?”

이 질문의 답을 찾는 과정에서 커스텀 예외(Custom Exception) 개념이 등장한다.

커스텀 예외가 필요한 이유

표준 예외는 대부분 일반적인 오류 상황을 표현한다. 예를 들어 IllegalArgumentException은 잘못된 인자를 의미하지만 “사용자 포인트가 부족하다”와 같은 도메인 고유의 상황을 담기에는 한계가 있다.

즉, 비즈니스 맥락(Context)을 명확히 전달하기 어렵다.

예시

이처럼 커스텀 예외를 통해 “어떤 문제인지”뿐만 아니라 “왜 발생했는지”를 코드 레벨에서 명확히 표현할 수 있다.

커스텀 예외 설계 기본 구조

커스텀 예외는 Throwable와 상속관계에 있는 클래스를 상속받아 사용한다. 일반적으로 RuntimeException 을 상속받아 정의한다. 이는 명시적인 try-catch 없이도 전파된다.

pblic class ExternalApiException extends RuntimeException {

    public ExternalApiException(String message) {
        super(message);
    }

}

커스텀 예외 Best Practice

필요한 예외를 직접 정의하는 것은 좋은 접근이다. 하지만 만든 예외의 이름이 "NoData", "GoodException", "BadSituation" 과 같다면 어떨까?

이런 이름의 예외가 애플리케이션 실행 중 발생한다면 문제가 ‘무엇 때문인지’ 파악하기가 매우 어려울 것이다. 예외 메시지를 보고도 원인을 유추할 수 없다면 그 예외는 사실상 의미 없는 신호에 불과하다.

단독으로 개발하는 상황이라면 그나마 감내할 수 있겠지만 프로젝트가 팀 단위로 진행되는 협업 환경이라면 이야기가 달라진다. 코드 리뷰나 디버깅 과정에서 “이 예외가 정확히 어떤 상황을 의미하는가?”라는 질문이 쏟아질 것이고 팀원들 사이에서 좋지 않은 인상을 줄 가능성이 높다.

즉, 예외 이름은 예외의 본질을 드러내야 한다. “무엇이 잘못되었는가?”를 명확히 표현하지 못하는 예외는 오히려 문제 해결을 더디게 만든다.

이러한 상황을 방지하고 좋은 예외를 만드는 4가지 Best Practice를 살펴보자.

1. Always Provide a Benefit

항상 “이 예외를 통해 얻을 수 있는 정보”를 제공하자.

커스텀 예외는 단순히 오류를 알리는 용도가 아니다. 개발자에게 문제의 원인을 명확히 설명하고, 해결 방향을 제시해야 한다.

즉, “이 예외를 던짐으로써 팀원이 얻을 수 있는 이점(benefit)”이 있어야 한다.

아무런 이점도 제공할 수 없다면 UnsupportedOperationException 이나 IllegalArgumentException 과 같은 표준 예외 중 하나를 사용하는 것이 좋다 . 모든 Java 개발자는 이미 이러한 예외를 알고 있을 것이다. 이렇게 하면 코드와 API를 더 쉽게 이해할 수 있다.

예시

// ❌ 나쁜 예시
throw new NoDataException("데이터 없음");

// ✅ 좋은 예시
throw new UserNotFoundException("ID가 42인 사용자를 찾을 수 없습니다.");

좋은 예외는 에러 로그를 읽는 순간 무엇이, 왜, 어디서 발생했는지 즉시 이해할 수 있어야한다. 이는 디버깅 속도를 높이고 장애에 대응하는 시간을 단축시킨다.

2. Follow the Naming Convention

예외 클래스는 반드시 Exception으로 끝나야 한다.

명명 규칙을 통일하면 프로젝트 전체에서 예외를 식별하기 쉬워진다. 또한 IDE나 검색 도구를 사용할 때, Exception 접미사만으로 관련 클래스를 빠르게 찾을 수 있다.

실제로 Java에서 기본적으로 구현한 예외들을 살펴보면 모두 Exception으로 끝나는걸 확인할 수 있다.

3. Provide Javadoc Comments for Your Exception Class

예외의 목적과 사용 의도를 명확히 문서화하자.

커스텀 예외 클래스는 재사용될 가능성이 높다. 따라서 예외가 언제 발생하는지, 어떤 상황에서 던져지는지를 Javadoc 주석으로 명확히 기술하는 것이 중요하다. 이를 통해 팀원이나 후속 개발자가 예외의 용도를 이해하기 쉽다.

실제로 모잇지 서비스를 구현하면서 커스텀 예외 문서화의 중요성을 크게 느꼈다. 프론트파트 개발시 간헐적 API 에러가 발생했는데 Swagger를 활용하여 다양한 커스텀 예외를 문서화하여 프론트엔드와 협업할 때 예외 발생 상황과 의미를 명확히 전달할 수 있었고

그 결과 장애 대응을 빠르게 할 수 있었다.

/**
 * 외부 API 호출 중 예기치 않은 오류가 발생했을 때 던져진다.
 * 주로 네트워크 지연, 응답 파싱 실패, 인증 오류 등의 상황에서 사용된다.
 */
public class ExternalApiException extends RuntimeException {
    public ExternalApiException(String message) {
        super(message);
    }
}

4. Provider Constructor That Sets the Cause

원인 예외(cause)를 함께 전달하는 생성자를 제공하자.

커스텀 예외가 감싸는 내부 예외(예: IOException, SQLException)를 명시적으로 연결하면 전체 예외 흐름을 추적하기가 훨씬 쉬워진다.

public class ExternalApiException extends RuntimeException {

    public ExternalApiException(String message) {
        super(message);
    }

    public ExternalApiException(String message, Throwable cause) {
        super(message, cause);
    }
}

이 패턴을 사용하면 예외 스택 트레이스에 원인(cause) 이 함께 포함되어 로그 분석 및 장애 추적이 용이해진다.

커스텀 예외 체크리스트

이 표는 커스텀 예외를 설계할 때 확인해야 할 체크리스트이다. 각 항목을 검토하면서 좋은 커스텀 예외를 만들 수 있다.

마무리

커스텀 예외가 무엇인지, 어떻게 사용하는지 알아보았다. 가장 중요한 것은 커스텀예외를 통해 무엇을 전달할 것인지 명확히 해야한다.

예외 처리는 비용이 크다. 그렇기에 예외를 남발하기 보다는 꼭 필요한 부분에 구현하고 문제 상황에 따른 적절한 에외를 발생하는게 중요하다.

1. Throws

Java에서 메서드가 호출 중에 예외를 발생시킬 가능성이 있는 경우 그 예외를 메서드 선언부에 명시하는 것이 바로 throws 키워드다.

특히 Checked 예외는 컴파일러가 예외 처리를 강제하기 때문에 메서드 내부에서 직접 처리하지 않고 상위 호출자에게 전달하려면 반드시 throws를 사용해야 한다.

public void readFile(String path) throws IOException {
    FileReader reader = new FileReader(path);
    // 파일 읽기 로직
}

위 코드에서 readFile 메서드는 IOException을 처리하지 않고 호출자에게 전달한다. 따라서 호출하는 쪽에서 try-catch 로 예외를 처리하거나 다시 throws로 던져야 한다.

💡개발자는 throws로 던져진 예외를 어느 계층에서 처리할지 명확히 결정해야 한다. 예를 들어 Controller–Service–Repository 구조에서는, Repository에서 발생한 예외를 어디까지 전파할지가 중요한 설계 포인트다. 이에 대한 구체적인 논의는 다음 글에서 다루겠다.

2. try-catch

예외가 발생하면 기본적으로 try-catch를 사용하여 예외를 처리할 수 있다.

try{
    //예외가 발생할 가능성이 있는 로직
}catch(Excetpion e){
    //예외가 발생시 실행할 로직
}

기본적인 형태는 위와 같이 try 구간과 catch 구간으로 나뉘어져 있다.

2-1. try

• 예외가 발생할 가능성이 있는 로직이 위치한다.

2-2. catch

• 예외가 발생하면 catch 블록이 실행된다.
• catch()의 파라미터에는 처리할 예외 클래스를 지정한다.
• 예를 들어 catch(IOException e)는 IO 관련 예외만 처리한다.

주의점

• catch(Exception e)는 모든 예외를 포괄하기 때문에 예외별 맞춤 처리 불가능하다.
• 일반적으로 구체적 예외 → 상위 예외 순서로 catch를 작성하는 것이 좋다.

예제

try {
    FileReader reader = new FileReader("data.txt");
} catch (FileNotFoundException e) {
    System.out.println("파일이 존재하지 않습니다: " + e.getMessage());
} catch (IOException e) {
    System.out.println("입출력 오류 발생: " + e.getMessage());
} catch(Exception e){
    System.out.println("Exception 예외까지 도달: " +  e.getMessage());
}

위의 코드를 보자.

1. 'data.txt' 파일이 없으면 → FileNotFoundException 발생
2. 파일 읽는 도중 다른 IO 문제가 생기면 → IOException 발생
3. 위 두 경우에 해당하지 않는 기타 문제 발생 시 → Exception 발생

3. multi-catch

만약 하나의 catch 문에 복수의 예외를 잡고 싶다면 아래와 같이 multi-catch로 구현할 수 있다.(Java 7 이상에서 사용 가능)

• 처리 로직이 동일한 경우만 사용 가능

• multi-catch 내부에서 e 변수는 final 취급 → 재할당 불가

  try {
    // 파일 읽기 또는 DB 처리
  } catch (IOException | SQLException e) {
    e.printStackTrace(); // 두 예외를 동일하게 처리
  }

4. finally

만약 try-catch로 감싼 로직이 정상 동작하든, 예외가 발생하든 반드시 실행시키고 싶은 로직이 있다면 finally 를 이용하면 된다. finally가 중요하게 쓰이는 대표적인 경우는 파일, DB, 소켓 등과 같은 자원 관리이다. 예외 발생 시 자원을 닫지 않으면 메모리 누수 / 리소스 누수가 발생할 가능성이 있기 때문이다.

public void readFileWithoutFinally() {
    FileReader reader = null;
    try {
        reader = new FileReader("data.txt");
        int data = reader.read();
        // 파일 읽기 로직 수행
    } catch (IOException e) {
        e.printStackTrace();
    }
    // reader.close()가 예외 발생 시 호출되지 않아 자원 누수 가능
}

위 코드는 예외가 발생하면 reader.close()가 호출되지 않아 자원 누수 위험이 존재한다. 이를 보완한 코드를 살펴보자. 예외 발생 여부와 관계없이 finally 블록 내부 코드는 항상 실행되기 때문에 자원 해제를 강제하여 메모리/리소스 누수를 방지한다.
<finally로 보완한 안전한 코드>

public void readFileWithFinally() {
    FileReader reader = null;
    try {
        reader = new FileReader("data.txt");
        int data = reader.read();
        // 파일 읽기 로직 수행
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        try {
            if (reader != null) {
                reader.close(); // 예외 여부와 관계없이 항상 호출
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

그렇다면 개발자는 파일, DB, 소켓등을 사용할 때 매번 직접 finally를 붙여야 할까? 물론 메모리 / 리소스 누수를 방지하기 위해서 반드시 작성해야할 것이다. 하지만 문제점이 있다. 그것은 개발자가 finally를 실수로 안붙이는 휴먼에러의 가능성이 존재한다. 이를 보완해줄 방법이 존재한다.

5. try-with-resources

Java 7 이상에서는 파일, DB, 소켓 등 자원을 안전하게 자동으로 해제하기 위해 try-with-resources 구문을 사용할 수 있다. 이 구문을 사용하면 finally 블록을 직접 작성하지 않아도 자원을 자동으로 닫을 수 있어 코드가 간결해지고 예외 안전성이 높아진다.

특징

1. 자동 자원 관리

   • try 괄호 안에서 선언한 자원(AutoCloseable 구현 클래스)은 try 블록 종료 시 자동으로 close() 호출

2. 예외 발생 여부와 상관없이 실행

   • Checked/Unchecked 예외 모두 처리 가능

3. 코드가 간결해짐

   • finally 블록에서 자원을 닫는 반복적인 코드를 제거

기본 문법

try (자원 선언) {
    // 자원을 사용하는 로직
} catch (예외 e) {
    // 예외 처리
}

try(자원 선언) 의 괄호 안에는 FileReader, BufferedReader, Connection, PreparedStatement 과 같은 AutoCloseable 인터페이스를 구현한 객체를 선언할 수 있다.

또한 여러 자원도 ;로 구분하여 동시에 선언 가능하다.

예제: JDBC 사용

아래 코드는 필자가 우테코 미션에서 구현한 JdbcTemplate 예제이다. try-with-resources를 사용하여 Connection, PreparedStatement, ResultSet 객체를 자동으로 close하고 있다.

    public <T>List<T> query(String sql, RowMapper<T> rowMapper) {
        try (Connection conn = dataSource.getConnection();
             PreparedStatement pstmt = conn.prepareStatement(sql);
             ResultSet rs = pstmt.executeQuery()) {

            log.debug("query : {}", sql);

            List<T> results = new ArrayList<>();
            while (rs.next()) {
                results.add(rowMapper.mapRow(rs));
            }
            return results;
        } catch (SQLException e) {
            log.error(e.getMessage(), e);
            throw new DataAccessException(e);
        }
    }

마무리

예외 처리는 코드의 품질을 결정짓는 중요한 요소다. throws로 예외를 넘길지, try-catch로 직접 처리할지, 혹은 try-with-resources로 안전성을 확보할지는 모두 의도적인 설계 선택이다.

결국 예외 처리의 목표는 “모든 예외를 잡는 것”이 아니라, 올바른 위치에서 책임 있게 다루는 것이다.

이 글은 우아한테크코스의 테크니컬 라이팅을 목적으로, 프로그래밍을 어느 정도 경험했지만 예외(Exception) 에 대한 이해가 부족하거나 궁금한 사람들을 위해 작성되었다.
관련 코드는 Java 로 작성되었으며, 자바와 스프링 영역에서의 예외의 개념부터 시작하여 다양한 예외 처리 전략 까지 단계적으로 살펴본다.

대부분의 사람들은 프로그래밍을 하다 보면 다음과 같은 문제 상황을 한 번쯤 경험하게 된다.

• 코드에 오타가 났다던가
• 함수에 잘못된 값을 전달했다던가
• 무한 루프를 만들고 실행했다던가

이러한 문제들은 프로그램의 정상적인 실행을 방해한다.
그렇다면 프로그래머들은 이런 상황을 어떻게 해결할까?
이 질문에 대한 답이 바로 예외 처리(Exception Handling) 이다.

2. 예외와 에러의 차이

예외(Exception)를 이해하기 위해서는 먼저 에러(Error) 와의 차이를 명확히 구분해야 한다. 결론부터 말하자면 차이점은 아래와 같다.

에러(Error) : 시스템의 고장으로 인한 복구 불가능한 문제 예외(Exception) : 프로그램 실행 중 발생하는 복구 가능한 문제

추가적으로 오류와 에러를 혼동하시는 분들이 있는데 프로그래밍 세계에서 일반적으로 ‘에러’와 ‘오류’는 같은 의미로 사용된다.
즉, 일상적으로 “오류가 났다”라고 말하는 것은 대부분 시스템 수준의 에러(Error) 를 의미한다.

2-1. 자바의 예외 계층 구조

자바에서는 에러와 예외를 Throwable 클래스를 최상위로 두고 시스템 수준의 에러는 Error, 프로그램 실행 중 발생하는 문제는 Exception으로 나누어 관리하고있다.

Throwable
├── Error
└── Exception
     ├── RuntimeException (Unchecked)
     └── Checked Exception

다음으로는 에러와 예외에 대한 개념을 알아보자.

2-2. 에러(Error)란 무엇인가

오류(Error) 는 프로그램이 제어할 수 없는 심각한 문제 상황을 뜻한다.
주로 시스템 자원 부족, 가상머신(VM)의 비정상 동작, 하드웨어 장애 등의 원인으로 발생하며, 다음과 같이 세 가지 유형으로 나눌 수 있다.

🔹 컴파일 에러 (Compile-time Error)

코드의 문법이나 구조가 언어의 규칙(Java, Python 등)에 맞지 않아 프로그램이 실행조차 되지 않는 오류이다.
이러한 에러는 컴파일러나 IDE에서 자동으로 탐지되며, 메시지를 통해 비교적 쉽게 해결할 수 있다.

예시:

• 문법 에러(Syntax Error)
• 타입 불일치(Type Error)

🔹 런타임 에러 (Runtime Error)

프로그램 실행 도중 발생하는 예외적 상황으로, 프로그램이 중단되거나 비정상 동작하게 된다.
이번 글의 주제인 예외(Exception) 는 바로 이 런타임 시점에서 발생한다.
이러한 에러는 로그 분석이나 스택 트레이스(Stack Trace) 를 통해 원인을 파악할 수 있으며, 예외 처리 전략으로 대응이 가능하다.

예시:

• 0으로 나누기
• Null 참조
• 파일 없음

🔹 논리 에러 (Logical Error)

문법적으로나 실행적으로는 문제가 없지만 프로그램의 결과가 의도와 다르게 나오는 오류이다.
예를 들어, 잔고가 0원인데 결제가 되는 상황을 생각할 수 있다.
이런 오류는 테스트와 디버깅을 통해서만 탐지할 수 있다.

예시:

• 잘못된 알고리즘
• 조건식 오류
• 계산 실수

2-3. 예외(Exception)란 무엇인가

사전적으로 예외는 어떤 일에서 제외되거나 특별한 경우를 의미하는 단어이다. 그러나 프로그래밍 세계에서의 예외(Exception)는 다른 의미를 가진다.

프로그래밍에서의 예외는 프로그램 실행 중(런타임) 발생하는 오류 상황을 말한다. 예외 처리는 이러한 오류가 프로그램의 비정상 종료로 이어지지 않도록 오류를 감지하고, 이에 대한 적절한 대응 로직을 수행하는 과정이다. 즉, 예외는 “복구 가능한 오류”이며, 코드 레벨에서 처리할 수 있는 문제이다.

예외 처리의 예시

예를 들어, 파일을 열 때 해당 파일이 존재하지 않는다면 예외가 발생한다.
이 상황에서 예외를 처리하지 않으면 프로그램이 즉시 종료된다.
하지만 예외 처리를 통해 다음과 같이 대응할 수 있다.

try {
    FileReader reader = new FileReader("data.txt");
} catch (FileNotFoundException e) {
    System.out.println("파일이 없습니다. 기본 설정으로 진행합니다.");
}

위의 설명으로 사전 설명은 끝났다고 생각한다. 이제 본격적으로 예외에 대해 알아보자.

Exception 클래스

자바 프로그래밍을 경험한 사람이라면 Exception 클래스를 한 번쯤은 마주쳤을 것이다.
Exception 클래스가 어떻게 구성되어 있는지, 그리고 어떤 역할을 하는지를 자세히 살펴보자.

💡Exception.class docs 공식문서를 보는 것도 추천한다.

1. Exception 클래스의 정의

Exception은 java.lang 패키지에 포함된 클래스이며,Throwable 클래스를 상속 받고 있고, 자바의 모든 체크 예외(Checked Exception) 의 기본 클래스이다.

package java.lang;

public class Exception extends Throwable {
    ...
}

2. Exception 클래스의 주요 생성자

Exception 클래스는 다양한 상황에서 예외를 생성할 수 있도록 여러 생성자 오버로딩을 제공한다.

3. Checked 예외 ,Unchecked 예외

위에서 Checked 예외를 언급했다. 모두가 예상했겠지만 Unchekced 예외 또한 존재하고, 두 예외의 차이점을 알아보자.

3-1. checked 예외

• 컴파일러가 명시적 처리(try-catch 또는 throws 선언) 를 강제하는 예외이다.

• Exception의 하위 클래스 중 RuntimeException을 상속하지 않은 것들이 이에 해당한다.

• 예시) IOException, SQLException, FileNotFoundException

public void readFile() throws IOException {
    FileReader reader = new FileReader("data.txt"); // FileReader 생성 시 IOException 발생 가능
    // 반드시 예외 선언 필요: checked 예외는 메서드에서 직접 처리하거나 선언해야 함
}

위 코드에서 FileReader 생성 시, 생성자의 매개변수로 지정된 "data.txt" 파일이 존재하지 않거나 경로가 잘못되었다면 IOException(checked 예외)이 발생한다. 이러한 경우를 대비하기 위해 checked 예외는 메서드 내부에서 반드시 처리되어야 한다.
처리 방법은 두 가지가 있다:

1. 메서드 내부에서 try-catch 블록으로 직접 처리
2. 메서드 선언부에 throws IOException을 선언하여 상위 호출자에게 전달

이 선언이나 처리가 이루어지지 않으면 컴파일 오류가 발생한다.
즉, Checked 예외는 코드 어디선가 반드시 해결해야 하며, 처리하지 않고 넘어갈 수 없다.

3-1. Unchecked 예외

• RuntimeException을 상속하는 예외이다.

• 명시적 예외 처리 없이 발생 가능하다 (컴파일러가 강제하지 않음)

• 주로 프로그래밍 오류로 발생한다.

• 예시) NullPointerException, IllegalArgumentException, ArrayIndexOutOfBoundsException

public void divide(int a, int b) {
    // b가 0이면 ArithmeticException 발생 (Unchecked 예외)
    int result = a / b;
    System.out.println("결과: " + result);
}

위 코드에서 정수를 0으로 나누면 ArithmeticException이 발생한다.
하지만 예외가 발생해도 애플리케이션이 자동으로 종료되지는 않으며, 컴파일러도 이를 체크하지 않기 때문에 try-catch 선언이 필수는 아니다.

즉, Unchecked 예외는 발생 가능성이 있어도 처리해야 한다는 강제성은 없다. 다만 필요하다면 try-catch로 처리할 수 있으며, 코드 설계 시 예외가 발생하지 않도록 사전에 오류를 방지하는 것이 권장된다.

❓왜 예외를 두가지 상황으로 나누었을까?

그에 대한 해답은 자바의 아버지라 불리는 James Gosling 과의 대화에서 알 수 있다.

💡제임스 고슬링과의 인터뷰

James Gosling이 체크 예외 설계 의도를 설명한 인터뷰가 있으며, 그 중 일부가 다음과 같다:

“In Java you can ignore exceptions, but you have to willfully do it. You can’t accidentally say, ‘I don’t care.’ You have to explicitly say, ‘I don’t care.’” — Artima, “Failure and Exceptions — A Conversation with James Gosling, Part II” artima.com

이 발언은 “예외 처리를 무시하려면 명시적으로 그렇게 해야 한다”는 의미다.
즉, 자바는 컴파일러 수준에서 예외 처리를 강제함으로써, 개발자가 단순히 “귀찮아서” 예외를 무시하는 일을 방지한다.
이것이 바로 Gosling이 추구한 안정성과 명시성 중심의 설계 철학이다.

또한, 같은 인터뷰에서 Gosling은 C 언어에서 오류 코드를 무시하는 관습을 지적하면서 Java가 예외 처리를 강제한 이유를 설명한다.

결국 자바는 이러한 철학을 기반으로,예외를 두 가지로 구분했다. 컴파일러가 강제하는 “체크 예외(Checked Exception)” 와
개발자 선택에 맡기는 “언체크 예외(Unchecked Exception)” 로 말이다.

1. 프로젝트 위치 확인

SSM(Session Manager)로 EC2에 접속 후 프로젝트가 어디에 있는지부터 확인했다.

/home/ubuntu/actions-runner/_work/2025-moitz/2025-moitz/backend 경로에서 프로젝트를 찾았다.

cd ~/actions-runner/_work/2025-moitz/2025-moitz/backend
ls

build/libs 안에 빌드된 JAR 파일이 존재하는 것을 확인했다.

2. 애플리케이션 백그라운드 실행 시도

nohup을 사용하여 JAR 파일을 백그라운드로 실행했다.

nohup java -jar build/libs/moitz-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

하지만 실행 직후 프로세스가 종료되었다.

ps -ef | grep java를 통해 확인해도 JAR 프로세스가 남아있지 않았다.

3. MongoDB와 Redis 서버 상태 확인

Spring Boot 설정을 보면 MongoDB와 Redis에 연결하도록 되어 있었다.

먼저 MongoDB가 실행 중인지 확인했다.

ps -ef | grep mongod
systemctl status mongod

• MongoDB 프로세스가 정상적으로 실행 중임을 확인했다.
• PID 3031에서 8시간 이상 가동 중이었다.

다음으로 Redis 상태를 확인했다.

ps -ef | grep redis

• Redis도 정상적으로 127.0.0.1:6379에서 실행 중이었다.

즉, Spring Boot 종료 원인은 DB나 Redis 부재 문제가 아니었다.

4. 로그 디렉토리 및 권한 확인

애플리케이션이 로그를 기록하는 디렉토리 권한을 확인했다.

ls -ld ~/actions-runner/_work/2025-moitz/2025-moitz/backend/logs

• 로그 디렉토리는 존재했고, ubuntu 계정으로 읽기/쓰기/실행 권한이 있었다.
• 따라서 로그 권한 문제로 종료된 것은 아니었다.

5. JAR 직접 실행 및 로그 확인

run.log 파일로 표준 출력과 오류 출력을 기록하며 애플리케이션을 실행했다.

java -jar build/libs/moitz-0.0.1-SNAPSHOT.jar > run.log 2>&1
tail -n 50 run.log

로그를 확인한 결과, 초기 WARN 메시지 외에는 fatal error가 없었지만 애플리케이션은 바로 종료되었다.

6. 애플리케이션 종료 원인 파악

추가 로그 확인 결과, 애플리케이션 시작 시 외부 OPEN API를 호출하는 과정에서 에러가 발생했다.

ExternalApiException: OPEN API 응답이 정상적으로 생성되지 않았습니다.
at com.f12.moitz.infrastructure.client.open.OpenApiClient.searchRoute(OpenApiClient.java:96)

• 애플리케이션 시작시 SubwayEdges 초기화를 위한 Setup과정에서 API 호출을 시도했다.
• 외부 API 관련 예외가 전파되었고, Spring Boot 컨텍스트가 종료되었다.
• 결과적으로 서버가 시작 직후 종료된 것이다.

원인 요약

• MongoDB와 Redis 서버 모두 정상
• 로그 디렉토리 권한 문제 없음
• JAR 파일 자체는 정상 실행 가능
• 애플리케이션이 바로 종료된 이유: 외부 OPEN API 호출 실패로 ApplicationContext 초기화 실패

해결 전략

아직 이부분에 대해서는 고민을 하고 있다. 외부 API가 애플리케이션 시작때 관여를 하고 있다면 외부 API의 서버에 문제가 생긴다면 (ex) 대한민국 전산망 화재 ) 우리의 서비스는 배포 조차 할 수 없는 것이다. 현재로서는 아래와 같은 방법이 생각이 난다.

로컬 더미 데이터 활용

개발 환경에서는 OPEN API 대신 로컬 JSON/CSV 데이터를 사용하여 초기화한다.

마무리

이번 경험을 통해 EC2에서 Spring Boot 실행 시 흔히 겪는 문제들을 확인하고, 외부 API 호출과 관련된 초기화 과정이 애플리케이션 종료의 주요 원인임을 파악했다.

개발 환경에서는 예외 처리와 API 호출 지연을 통해 서버를 안전하게 실행할 수 있다는 것을 배웠다.

예전에는 개발을 하면서 데이터의 중요성을 크게 못느꼈던 것 같다. 하지만 성장하면서 발로 뛰어 모은 데이터, 다양한 로그 데이터등이 서비스를 성장시킬 수 있는 가치있는 보물임을 느꼈다.

$ sudo systemctl status mongod
× mongod.service - MongoDB Database Server
     Loaded: loaded (/usr/lib/systemd/system/mongod.service; disabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-09-19 04:28:34 UTC; 16s ago
   ...
Sep 19 04:28:34 ip-10-0-0-68 mongod[1252]: {"msg":"Failed to unlink socket file","attr":{"path":"/tmp/mongodb-27017.sock","error":"Operation not permitted"}}

로그를 확인해보니 MongoDB가 /tmp/mongodb-27017.sock 파일을 삭제하지 못해 시작이 실패했다. 이는 주로 파일 권한 문제 또는 이전에 종료되지 않은 MongoDB 프로세스 때문에 발생하는 문제였다.

문제 원인 분석

1. mongod.service 상태 확인:

sudo systemctl status mongod

결과에서 Failed with result 'exit-code'와 함께 Failed to unlink socket file 에러가 발생했다.

1. 로그 확인:

sudo tail -50 /var/log/mongodb/mongod.log

• Failed to unlink socket file
• Fatal assertion

위 로그를 통해 MongoDB 소켓 파일 삭제 실패가 직접적인 원인임을 확인했다.

문제 해결 과정

1. 소켓 파일 확인

ls -l /tmp/mongodb-27017.sock

파일이 존재하고 소유권 또는 권한 문제로 MongoDB가 접근하지 못함을 확인했다.

2. 소켓 파일 삭제

sudo rm /tmp/mongodb-27017.sock

삭제 후 MongoDB가 새 소켓 파일을 생성할 수 있게 되었다.

3. MongoDB 재시작

sudo systemctl start mongod
sudo systemctl status mongod

• 정상적으로 서비스가 시작됨을 확인했다.
• 추가적으로 /tmp 폴더 권한이 올바른지 확인하였다.

ls -ld /tmp
# 권한: drwxrwxrwt

결론

이번 문제는 MongoDB가 소켓 파일을 삭제하지 못해 발생한 서비스 시작 실패였다.

핵심 해결 방법은 다음과 같다.

1. /tmp/mongodb-27017.sock 파일 삭제
2. MongoDB 서비스 재시작
3. /tmp 권한 확인 (필요 시 chmod 1777 /tmp)

이 과정을 통해 MongoDB를 정상적으로 기동시킬 수 있었다.

이번 사례를 통해, MongoDB 서비스 문제는 권한 및 소켓 파일 문제에서 시작되는 경우가 많음을 알 수 있었다.

운영 환경에서 MongoDB가 갑자기 시작되지 않을 때, 먼저 /tmp와 소켓 파일을 확인하는 습관이 필요하다고 느꼈다.

미션과 퀘스트를 병행하면서 모잇지 프로젝트의 유지보수를 하기위해 오랜만에 개발 브랜치를 가져와 로컬에서 여러 테스트를 하려고 하였다. 그동안 내가 확인하지 못했던 코드들이 반영되었기에 여러 문제 상황을 마주했는데 그중 하나인 빈충돌 트러블 슈팅에 대해 공유하려고 한다.

문제 상황

Spring Boot 프로젝트를 실행했을 때, 애플리케이션 컨텍스트 초기화 단계에서 아래와 같은 에러가 발생했다.

UnsatisfiedDependencyException: Error creating bean with name 'openApiClient'
No qualifying bean of type 'org.springframework.web.client.RestClient' available:
expected single matching bean but found 3: kakaoRestClient, odsayRestClient, openRestClient

처음에는 단순히 의존성 주입 실패 정도로만 보였지만, 로그를 따라가면서 원인을 추적해보았다.

기존 코드

@Slf4j
@RequiredArgsConstructor
@Component
public class OdsayClient {

    private static final String ODSAY_ROUTE_SEARCH_URL = "/searchPubTransPathT?SX=%f&SY=%f&EX=%f&EY=%f&apiKey=%s&searchPathType=%d";
    private static final int SEARCH_PATH_TYPE = 1;

    private final RestClient odsayRestClient;
    private final ObjectMapper objectMapper;

    @Value("${odsay.api.key}")
    private String odsayApiKey;

기존 코드에서는 생성자 파라미터이름 매칭을 사용하여 빈을 찾아서 등록해주었다.

이때 RestClient 타입의 여러빈들이 등록되어 있다면, 스프링은 파라미터 이름 odsayRestClient 과 동일한 이름을 가진 빈을 우선적으로 주입한다.

따라서 빈 이름과 생성자 파라미터 이름이 정확히 일치해야 원하는 빈이 주입된다.

여기서 궁금증이 생겼다.

해당 코드는 운영환경에서도 배포가 되어 있었고, 서비스가 정상적으로 운영되고 있었다.

하지만 나의 로컬 환경에서는 빈충돌 에러가 생기는 이유가 뭘까?

원인 분석

문제의 핵심은 RestClient 타입의 빈이 여러 개 등록되어 있었던 점이었다.

ClientConfig 클래스에서 다음과 같이 세 개의 빈을 등록했다.

@Bean
public RestClient kakaoRestClient() {
    return RestClient.builder()
            .baseUrl("https://dapi.kakao.com/v2/local/search")
            .build();
}

@Bean
public RestClient odsayRestClient() {
    return RestClient.builder()
            .baseUrl("https://api.odsay.com/v1/api")
            .build();
}

@Bean
public RestClient openRestClient() {
    return RestClient.builder()
            .baseUrl("https://apis.data.go.kr/B553766/path")
            .build();
}

각각 카카오 API, Odsay API, 공공 데이터 API 호출을 위한 클라이언트였다.

그러나 OdsayClient, KakaoMapClient, OpenApiClient 같은 클래스에서 단순히 RestClient 타입만 의존성 주입을 시도했기 때문에, 스프링은 어떤 빈을 넣어야 하는지 판단할 수 없어 에러를 발생시켰다.

해결 방법

빈 충돌 문제를 해결하기 위해 선택할 수 있는 방법은 크게 세 가지였다.

1. @Qualifier 사용 (권장)

빈 주입 시 어떤 빈을 사용할지 명확히 지정한다.

@Component
public class OdsayClient {

    private final RestClient odsayRestClient;
    private final ObjectMapper objectMapper;

    public OdsayClient(@Qualifier("odsayRestClient") RestClient odsayRestClient,
                       ObjectMapper objectMapper) {
        this.odsayRestClient = odsayRestClient;
        this.objectMapper = objectMapper;
    }
}

이 방식이 가장 안전하며, 이름과 빈이 매칭되기 때문에 의도한 대로 주입이 이루어진다.

➡️ 가장 명확한 방법.

➡️ 빈 이름은 `@Bean 메서드명(odsayRestClient)`과 동일해야 한다.

2. @Primary 지정

여러 개의 빈 중 하나를 기본값으로 지정할 수 있다.

@Bean
@Primary
public RestClient openRestClient() {
    return RestClient.builder()
            .baseUrl("https://apis.data.go.kr/B553766/path")
            .build();
}

그러면 @Qualifier가 없는 경우 자동으로 openRestClient가 주입된다.

하지만 이번 경우처럼 빈마다 목적이 다른 상황에서는 적합하지 않았다.

3. 생성자 파라미터이름 매칭 (기존 코드)⭐⭐⭐⭐⭐

스프링은 생성자 파라미터 이름과 빈 이름이 일치하면 자동으로 매칭을 시도한다.

@RequiredArgsConstructor
@Component
public class OdsayClient {
    private final RestClient odsayRestClient; // 필드명 == 빈 이름
    private final ObjectMapper objectMapper;
}

기존 코드에 적용했던 방법이다. 이 방법을 도입하였기에 이번 빈충돌 에러를 겪었다..ㅠㅠ

왜 운영에선 되고 로컬에선 안 됐을까?

운영 서버에서는 Gradle을 사용하여 빌드/배포가 이루어진다.

이때 Gradle은 기본적으로 파라미터 이름을 클래스 파일에 유지하도록 컴파일 옵션을 적용하기 때문에,

스프링이 생성자 파라미터 이름(odsayRestClient)을 정확히 읽어낼 수 있었다.

하지만 내 로컬 환경(IntelliJ)에서는 빌드 도구 설정이 Gradle이 아니라 IntelliJ IDEA로 되어 있었다.

IntelliJ 기본 컴파일러는 파라미터 이름 정보를 class 파일에 포함하지 않는다.

즉, 런타임에서 스프링이 파라미터 이름을 읽지 못하고 단순히 타입만 가지고 주입하려고 하다 보니,

동일한 타입(RestClient)의 여러 빈이 등록된 상황에서 빈 충돌 오류가 발생했던 것이다.

정리하면

• 운영 (Gradle 빌드) → 파라미터 이름 정보 유지 → 이름 기반 매칭 정상 동작 ✅
• 로컬 (IntelliJ 빌드) → 파라미터 이름 정보 누락 → 타입만 보고 주입 시도 → 다중 빈 충돌 발생 ❌

최종 선택

이번 프로젝트에서는 생성자를 직접 정의하고 @Qualifier를 명시적으로 붙이는 방식을 선택했다.

이렇게 했을 때:

• 어떤 빈이 주입되는지 명확히 알 수 있었고
• Lombok이 @Qualifier를 복사하지 않는 문제도 피할 수 있었으며
• 코드 가독성 측면에서도 의도 전달이 분명해졌다.
• 가장 중요한건 로컬 환경 세팅에 영향을 받지 않는다는 것이다.

배운 점

1. 동일한 타입의 빈이 여러 개 등록되면 충돌이 발생한다.
2. @Qualifier를 사용하여 명확하게 주입 대상을 지정할 수 있다.
3. @Primary, 파라미터 이름 매칭 등 다른 방법도 있지만, 가장 안정적인 방법은 @Qualifier를 활용하는 것이다.
4. Lombok의 @RequiredArgsConstructor는 @Qualifier를 복사하지 않으므로, 이 경우에는 생성자를 직접 작성하는 편이 안전하다.
5. 로컬 환경 세팅에 따라 다른 결과가 나올 수 있으므로 팀 컨벤션을 확실히 하자.

마무리

이번 트러블슈팅을 통해 스프링 빈 주입 과정에서 모호성이 생기면 반드시 해결해야 한다는 점을 다시 한번 깨달았다.

같은 코드라도 각자의 로컬 환경 세팅에 따라 다른 결과가 나오기 때문에 협업시 팀 컨벤션을 정하는 것이 이러한 문제를 안겪는 핵심이라 생각한다.

앞으로 비슷한 상황이 발생을 때는 로컬 환경 세팅에 영향을 받지 않는 @Qualifier를 적극적으로 활용할 것이다.

우아한 테크코스 스레드 퀘스트를 수행하다보니 궁금한 점이 생겼다. 웹 애플리케이션에서 수많은 사용자가 동시에 우리 서버에 요청을 보낼 때, 스프링은 어떻게 이 모든 요청을 효율적으로 처리하는 걸까? 그 비밀은 바로 톰캣(Tomcat)의 스레드 풀과 연결 관리 설정에 있다.

오늘은 application.yml 파일에서 설정할 수 있는 톰캣의 핵심 설정 세 가지를 톰캣 공식 문서를 바탕으로 분석한 결과를 써보려고 한다.

🔍 톰캣 설정 파일 위치와 구조

먼저 스프링 부트 프로젝트의 study/src/main/resources/application.yml 파일을 찾아보자. 이 파일에서 톰캣의 성능과 안정성을 결정하는 중요한 설정들을 확인할 수 있다.

server:
  tomcat:
    accept-count: 1
    max-connections: 1
    threads:
      max: 2

📋 톰캣 핵심 설정 3가지

1. acceptCount - 대기열의 크기를 결정한다

톰캣 공식 문서 원문:

The maximum length of the operating system provided queue for incoming connection requests when maxConnections has been reached. The operating system may ignore this setting and use a different size for the queue. When this queue is full, the operating system may actively refuse additional connections or those connections may time out. The default value is 100

한글 번역 및 분석:acceptCount는 maxConnections에 도달했을 때 들어오는 연결 요청을 위한 운영체제 제공 대기열의 최대 길이를 의미한다. 운영체제는 이 설정을 무시하고 대기열에 다른 크기를 사용할 수도 있다. 이 대기열이 가득 차면 운영체제는 추가 연결을 적극적으로 거부하거나 해당 연결이 타임아웃될 수 있다. 기본값은 100이다.

의미:

• 서버가 최대 연결 수에 도달했을 때의 "버퍼 역할"을 한다
• 갑작스러운 트래픽 급증 시 연결을 완전히 거부하지 않고 잠시 대기시킨다
• 너무 큰 값으로 설정하면 메모리 사용량이 증가할 수 있다

2. maxConnections - 동시 연결의 한계를 정하다

톰캣 공식 문서 원문:

The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection. This additional connection be blocked until the number of connections being processed falls below maxConnections at which point the server will start accepting and processing new connections again. Note that once the limit has been reached, the operating system may still accept connections based on the acceptCount setting. The default value is 8192.

For NIO/NIO2 only, setting the value to -1, will disable the maxConnections feature and connections will not be counted

한글 번역 및 분석: 서버가 주어진 시간에 수락하고 처리할 수 있는 최대 연결 수를 의미한다. 이 숫자에 도달하면 서버는 추가 연결 하나를 더 수락하지만 처리하지는 않는다. 이 추가 연결은 처리 중인 연결 수가 maxConnections 아래로 떨어질 때까지 차단되며, 그 시점에서 서버는 새로운 연결을 다시 수락하고 처리하기 시작한다. 한계에 도달하면 운영체제는 여전히 acceptCount 설정에 따라 연결을 수락할 수 있다는 점을 주의해야 한다. 기본값은 8192이다.

NIO/NIO2에서만 값을 -1로 설정하면 maxConnections 기능이 비활성화되고 연결이 카운트되지 않는다.

의미:

• TCP 연결 자체의 최대 개수를 제한한다
• Keep-Alive 연결도 이 수치에 포함된다
• 메모리와 파일 디스크립터 사용량을 제어하는 핵심 설정이다

3. maxThreads - 요청 처리의 핵심 동력을 관리하다

톰캣 공식 문서 원문:

The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. Note that if an executor is configured any value set for this attribute will be recorded correctly but it will be reported (e.g. via JMX) as -1 to make clear that it is not used.

한글 번역 및 분석: 이 커넥터가 생성할 요청 처리 스레드의 최대 개수로, 따라서 동시에 처리할 수 있는 최대 요청 수를 결정한다. 지정되지 않으면 이 속성은 200으로 설정된다. 이 커넥터에 실행자(executor)가 연결되어 있으면 커넥터가 내부 스레드 풀이 아닌 실행자를 사용하여 작업을 실행하므로 이 속성은 무시된다. 실행자가 구성되어 있으면 이 속성에 설정된 값은 정확히 기록되지만 사용되지 않는다는 것을 명확히 하기 위해 (예: JMX를 통해) -1로 보고된다는 점을 주의해야 한다.

의미:

• 실제로 요청을 처리하는 워커 스레드의 개수를 결정한다
• CPU 집약적인 작업이 많다면 CPU 코어 수와 비슷하게 설정한다
• I/O 대기가 많은 작업이라면 더 많은 스레드를 할당할 수 있다

• threads.max는 "얼마나 많은 스레드로 동시에 처리할 수 있냐"

• max-connections는 "동시에 유지할 수 있는 연결 수"
• accept-count는 "스레드 다 차면 몇 개까지 대기열에 둘 수 있냐"

🔄 톰캣 다중 사용자 요청 처리 흐름

이제 이 세 설정이 어떻게 협력하여 다중 사용자 요청을 처리하는지 살펴보자.

1단계: 연결 수락

• 클라이언트가 서버에 TCP 연결을 요청한다
• maxConnections 한계 내에서 연결을 수락한다

2단계: 대기열 관리

• maxConnections에 도달하면 acceptCount 크기만큼 대기열에서 대기한다
• 대기열마저 가득 차면 새로운 연결을 거부한다

3단계: 요청 처리

• 수락된 연결에서 HTTP 요청이 들어오면 maxThreads 범위 내에서 스레드를 할당한다
• 할당된 스레드가 실제 비즈니스 로직을 처리한다

4단계: 자원 반환

• 요청 처리가 완료되면 스레드를 스레드 풀로 반환한다

퀘스트의 전달한 핵심 가치가 마지막에 적혀져 있었다.

📚 이것이 WAS 스레드풀에서 의미하는 것

• WAS는 무제한으로 요청을 받아들이지 않는다.
• WAS는 정해진 규칙에 따라 자원을 할당한다.
• 이러한 설정은 서버가 과부하로 인해 죽지 않도록 보호하는 핵심 메커니즘이다.
• 실무에서는 대용량 트래픽 상황에서 이 설정들이 사용자 경험과 서비스 안정성을 좌우하는 중요한 요소가 된다.

모잇지 프로젝트를 진행하며 개발 환경과 운영 환경에서 서로 다른 로깅 전략이 필요했다. 그 이유는 개발 환경에서 직접 보는 것이 효과적인 로그들이 있었고, 운영 환경에서는 모니터링을 목적으로 남기는 로그들이 필요했다. 이번에 로그를 담당하며 이를 효과적으로 관리하는 방법을 알아보았다.

🔧 1. 전역 변수 관리 - logback-variable.properties

로깅 설정에서 사용할 변수들을 중앙에서 관리한다다.

# 로그 파일 위치
# 로그 파일 경로 backend/logs/info 또는 backend/logs/error
LOG_PATH=./logs
DEBUG_PATH=debug
WARN_PATH=warn
INFO_PATH=info
ERROR_PATH=error

# 로그 출력 포맷 
# CONSOLE_PATTERN : 개발 환경(콘솔에 출력)
# ROLLING_PATTERN : 운영 환경(파일로 저장) 
CONSOLE_PATTERN=%d{yyyy-MM-dd HH:mm:ss.SSS} %magenta([%thread]) %highlight([%-3level]) %logger{36} - %replace(%msg){'\n', ' '} %n 
ROLLING_PATTERN=%d{yyyy-MM-dd HH:mm:ss.SSS}  %logger{5} - %msg %n

# 로그 파일 정책
MAX_FILE_SIZE=10MB
TOTAL_SIZE=100MB
MAX_HISTORY=10

변수 설명

• LOG_PATH: 로그 파일이 저장될 기본 경로
• DEBUG_PATH, INFO_PATH, ERROR_PATH, WARN_PATH: 각각 일반 로그와 에러 로그의 하위 디렉토리
• CONSOLE_PATTERN: 개발 환경에서 콘솔에 출력될 로그 포맷 (컬러 포함)
• ROLLING_PATTERN: 운영 환경에서 파일에 저장될 로그 포맷 (심플)
• MAX_FILE_SIZE: 개별 로그 파일의 최대 크기
• TOTAL_SIZE: 전체 로그 파일들의 최대 크기
• MAX_HISTORY: 보관할 로그 파일의 최대 개수

⚙️ 2. application.properties 환경별 설정

개발 환경 설정

# application-dev.properties
# 개발 환경에서는 주로 콘솔 로깅 사용
spring.profiles.active=dev

운영 환경 설정

# application-prod.properties  
# 운영 환경에서는 파일 로깅 사용
spring.profiles.active=prod
logging.file.path=./logs

📊 3. 로그 출력 패턴 분석

개발 환경 로그 예시

2025-08-04 10:15:31.420 [main] [DEBUG] com.f12.moitz.service.UserService - 사용자 정보 조회 시작
2025-08-04 10:15:31.425 [http-nio-8080-exec-1] [INFO] com.f12.moitz.controller.UserController - GET /api/users 요청 수신

📡 모니터링 로그 쿼리를 위한 Logstash

운영 환경에서는 단순히 로그를 파일에 저장하는 것만으로는 부족하다. ElasticSearch + Logstash 또는 CloudWatch, OpenSearch 같은 로그 수집 시스템으로 로그를 전달하고, 이를 분석할 수 있어야 한다.

이를 위해 logback-spring.xml에서는 LogstashEncoder를 사용해 로그를 JSON 포맷으로 변환했다. 이를 위한 설정은 아래와 같다.

<encoder class="net.logstash.logback.encoder.LogstashEncoder"/>

📄 4. logback-spring.xml 전체 구조

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <!-- 외부 프로퍼티 로딩 -->
    <property resource="logback-variable.properties" />

    <!-- Spring 환경 변수 (application.properties 에서 주입됨) -->
    <springProperty scope="context" name="DEBUG_LOG_PATH" source="logging.file.debug.path"/>
    <springProperty scope="context" name="INFO_LOG_PATH" source="logging.file.info.path"/>
    <springProperty scope="context" name="WARN_LOG_PATH" source="logging.file.warn.path"/>
    <springProperty scope="context" name="ERROR_LOG_PATH" source="logging.file.error.path"/>

    <!-- 개발 환경용 설정 -->
    <springProfile name="dev">
        <!-- 콘솔 전용 Appender -->
        <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
            <encoder>
                <pattern>${CONSOLE_PATTERN}</pattern>
            </encoder>
        </appender>
        <!-- DEBUG 전용 Appender -->
        <appender name="FILE_DEBUG" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
            <file>${LOG_PATH}/${DEBUG_PATH}/application.log</file>
            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>${DEBUG_LOG_PATH}/application-info-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern>
                <maxHistory>${MAX_HISTORY}</maxHistory>
                <maxFileSize>${MAX_FILE_SIZE}</maxFileSize>
                <totalSizeCap>${TOTAL_SIZE}</totalSizeCap>
            </rollingPolicy>
        </appender>

        <root level="DEBUG">
            <appender-ref ref="CONSOLE"/>
            <appender-ref ref="FILE_DEBUG"/>
        </root>
        <!-- 프레임워크 기본 로거 수준 설정 -->
        <logger name="org.springframework" level="INFO"/>
        <logger name="org.springframework.boot" level="INFO"/>
        <logger name="org.hibernate" level="WARN"/>
        <logger name="org.apache.catalina" level="INFO"/>
        <logger name="com.zaxxer.hikari" level="WARN"/>

        <!--mongoDB-->
        <logger name="data.mongodb" level="WARN"/>
        <logger name="org.mongodb.driver" level="WARN"/>

        <!--Web Flux-->
        <logger name="io.netty" level="WARN"/>
        <logger name="reactor.netty" level="WARN"/>

        <!-- CloudWatch 메트릭 관련 로거 비활성화 -->
        <logger name="io.micrometer.cloudwatch2" level="OFF"/>
        <logger name="software.amazon.awssdk" level="OFF"/>
        <logger name="io.micrometer.core.instrument.push.PushMeterRegistry" level="OFF"/>

        <!-- AWS SDK 관련 로거 비활성화 -->
        <logger name="software.amazon.awssdk.auth.credentials" level="OFF"/>
        <logger name="software.amazon.awssdk.core.interceptor" level="OFF"/>
        <logger name="software.amazon.awssdk.services.cloudwatch" level="OFF"/>
        <logger name="software.amazon.awssdk.utils.cache" level="OFF"/>
        <logger name="software.amazon.awssdk.core.internal" level="OFF"/>

    </springProfile>

    <!-- ========================================================= -->

    <!-- 운영 환경용 설정 -->
    <springProfile name="prod">

        <!-- INFO 전용 Appender -->
        <appender name="FILE_INFO" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>

            <file>${LOG_PATH}/${INFO_PATH}/application-info.log</file>

            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>${INFO_LOG_PATH}/application-info-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern>
                <maxHistory>${MAX_HISTORY}</maxHistory>
                <maxFileSize>${MAX_FILE_SIZE}</maxFileSize>
                <totalSizeCap>${TOTAL_SIZE}</totalSizeCap>
            </rollingPolicy>

            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>INFO</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
        </appender>

        <!-- WARN 전용 Appender -->
        <appender name="FILE_WARN" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>

            <file>${LOG_PATH}/${WARN_PATH}/application-warn.log</file>

            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>${WARN_LOG_PATH}/application-warn-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern>
                <maxHistory>${MAX_HISTORY}</maxHistory>
                <maxFileSize>${MAX_FILE_SIZE}</maxFileSize>
                <totalSizeCap>${TOTAL_SIZE}</totalSizeCap>
            </rollingPolicy>

            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>WARN</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
        </appender>

        <!-- ERROR 전용 Appender -->
        <appender name="FILE_ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>

            <file>${LOG_PATH}/${ERROR_PATH}/application-error.log</file>

            <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
                <fileNamePattern>${ERROR_LOG_PATH}/application-error-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern>
                <maxHistory>${MAX_HISTORY}</maxHistory>
                <maxFileSize>${MAX_FILE_SIZE}</maxFileSize>
                <totalSizeCap>${TOTAL_SIZE}</totalSizeCap>
            </rollingPolicy>

            <filter class="ch.qos.logback.classic.filter.LevelFilter">
                <level>ERROR</level>
                <onMatch>ACCEPT</onMatch>
                <onMismatch>DENY</onMismatch>
            </filter>
        </appender>

        <root level="INFO">
            <appender-ref ref="FILE_INFO"/>
            <appender-ref ref="FILE_WARN"/>
            <appender-ref ref="FILE_ERROR"/>
        </root>
    </springProfile>

</configuration>

🔍 5. 로깅 설정 파일 상세 분석

외부 프로퍼티 로딩

<property resource="logback-variable.properties" />

logback-variable.properties에 정의된 전역 변수들을 logback 설정에서 사용할 수 있게 한다.

Spring 환경 변수 연동

<springProperty scope="context" name="DEBUG_LOG_PATH" source="logging.file.debug.path" defaultValue="${LOG_PATH}/${DEBUG_PATH}" />
<springProperty scope="context" name="INFO_LOG_PATH"  source="logging.file.info.path"  defaultValue="${LOG_PATH}/${INFO_PATH}" />
<springProperty scope="context" name="WARN_LOG_PATH"  source="logging.file.warn.path"  defaultValue="${LOG_PATH}/${WARN_PATH}" />
<springProperty scope="context" name="ERROR_LOG_PATH" source="logging.file.error.path" defaultValue="${LOG_PATH}/${ERROR_PATH}" />

• scope="context": Spring ApplicationContext가 초기화될 때 값을 가져옴
• name: logback 내에서 참조할 이름 (ex. ${INFO_LOG_PATH})
• source: Spring 설정 파일(application.properties)에서 가져올 key 값
• defaultValue: source에서 값을 찾지 못할 경우 사용할 기본값

개발 환경 설정 (dev profile)

<springProfile name="dev">
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>${CONSOLE_PATTERN}</pattern>
        </encoder>
    </appender>

    <!-- 프레임워크 로거 레벨 설정 -->
    <logger name="org.springframework" level="INFO"/>
    <logger name="org.springframework.boot" level="INFO"/>
    <logger name="org.hibernate" level="WARN"/>
    <logger name="org.apache.catalina" level="INFO"/>
    <logger name="com.zaxxer.hikari" level="WARN"/>
    <!-- 그외에도 DB, CloudWatch, AWS 등의 로거 레벨 설정 가능-->
    <root level="DEBUG">
        <appender-ref ref="CONSOLE"/>
    </root>
</springProfile>

주요 구성 요소:

• springProfile: Spring 프로파일이 dev일 때만 활성화
• appender: 로그 출력 방식을 정의 (콘솔 출력용)
• encoder: 로그 메시지의 출력 포맷 정의
• logger: 특정 패키지/클래스의 로그 레벨 설정
• root level: 전체 애플리케이션의 기본 로그 레벨

운영 환경 설정 (prod profile)

INFO 전용 Appender

<appender name="FILE_INFO" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_PATH}/${INFO_PATH}/application-info.log</file>

    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <fileNamePattern>${INFO_LOG_PATH}/application-info-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern>
        <maxHistory>${MAX_HISTORY}</maxHistory>
        <maxFileSize>${MAX_FILE_SIZE}</maxFileSize>
        <totalSizeCap>${TOTAL_SIZE}</totalSizeCap>
    </rollingPolicy>

    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>INFO</level>
    </filter>

    <encoder>
      <pattern>${ROLLING_PATTERN}</pattern>
    </encoder>
</appender>

ERROR 전용 Appender

<appender name="FILE_ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_PATH}/${ERROR_PATH}/application-error.log</file>

    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <fileNamePattern>${ERROR_LOG_PATH}/application-error-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern>
        <maxHistory>${MAX_HISTORY}</maxHistory>
        <maxFileSize>${MAX_FILE_SIZE}</maxFileSize>
        <totalSizeCap>${TOTAL_SIZE}</totalSizeCap>
    </rollingPolicy>

    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>ERROR</level>
    </filter>

    <encoder>
        <pattern>${ROLLING_PATTERN}</pattern>
    </encoder>
</appender>

WARN,DEBUG 전용 Appender는 이하 생략하겠다...

주요 구성 요소:

• RollingFileAppender: 파일 크기/시간 기준으로 로그 파일을 분할
• rollingPolicy: 파일 롤링 정책 설정
  • fileNamePattern: 롤링된 파일의 이름 패턴 및 압축 설정
  • maxFileSize: 단일 로그 파일의 최대 크기 (예: 10MB)
  • maxHistory: 최대 보관 일수 또는 개수 (예: 10일)
  • totalSizeCap: 전체 로그 디렉토리의 최대 용량 제한 (예: 50MB)
• filter: 특정 로그 레벨 필터링
  • ThresholdFilter: 설정된 레벨 이상만 출력 (INFO 설정 시 DEBUG 무시)

🚀 6. 실행 방법

개발 환경 실행

# IDE에서 실행 시
-Dspring.profiles.active=dev

# JAR 실행 시
java -jar -Dspring.profiles.active=dev your-application.jar

운영 환경 실행

# JAR 실행 시
java -jar -Dspring.profiles.active=prod your-application.jar

📂 7. 생성되는 폴더 구조

운영 환경에서는 다음과 같은 폴더 구조가 생성된다.

logs/
├── info/
│   ├── application-info.log
│   ├── application-info-2025-08-04.0.log.zip
│   └── application-info-2025-08-04.1.log.zip
└── error/
    ├── application-error.log
    ├── application-error-2025-08-04.0.log.zip
    └── application-error-2025-08-04.1.log.zip
└── warn/
    ├── application-warn.log
    ├── application-warn-2025-08-04.0.log.zip
    └── application-warn-2025-08-04.1.log.zip

💡 8. 주요 장점

환경별 최적화

• 개발 환경: 콘솔 출력, 컬러 하이라이트, 상세한 디버그 정보
• 운영 환경: 파일 저장, 레벨별 분리, 압축 및 롤링

자동 로그 관리

• 파일 크기 기반 자동 롤링
• 날짜별 파일 분할
• 오래된 로그 자동 삭제
• ZIP 압축으로 저장 공간 절약

성능 최적화

• 운영 환경에서 불필요한 로그 레벨 제한
• 프레임워크 로거 레벨 조정으로 노이즈 감소
• 효율적인 파일 I/O

```

이 설정을 통해 개발과 운영 환경에서 각각 최적화된 로깅 전략을 구현할 수 있었다. 개발 시에는 상세한 디버그 정보를, 운영 시에는 효율적이고 관리하기 쉬운 로그를 얻을 수 있었다.

모니터링이란?

시스템의 상태와 성능을 지속적으로 관찰하고 측정하여 문제를 사전에 감지하고 대응하는 활동입니다. 제가 모니터링에 대해 공부하면서 생각한 주요한 핵심요소는 3가지 입니다.

** 1. 수집 **

• 지표(매트릭) 수집 : CPU, 메모리, 디스크, 사용률등 수치 데이터 수집.
• 로그 수집 : 로그를 레벨에 따라 나누고(Info, Warn, Error 등) 대쉬보드에서 모니터링을 하여 운영 상황에서 발생한 문제 상황 인식.
• 트레이스 : 요청의 전체 처리 과정을 추적.

** 2. 시각화 **

• 그래프 및 차트로 데이터를 이해하기 쉽게 표현
• 대쉬보드를 통한 실시간 상태 확인

** 3. 알림 **

• 임계값 초과 시 자동 알림 발송
• 문제 상황을 즉시 인지하고 대응

사전 준비사항

IAM 역할 설정

EC2 인스턴스에 CloudWatch 에이전트 사용을 위한 IAM 역할을 설정했습니다. 다음 정책이 필요합니다:

• CloudWatchAgentServerPolicy (CloudWatch 에이전트용)

IAM 역할 설정 방법:

1. AWS EC2 콘솔에서 해당 인스턴스 선택
2. 작업 → 보안 → IAM 역할 수정
3. 위 정책들이 포함된 역할을 선택하여 적용

역할 생성에 대한 내용은 여러 글들이 있으니 참고하면 금방 할 것 같습니다.

CloudWatch 에이전트 설치

모든 과정은 EC2 인스턴스 안에서 진행했습니다.

1. 패키지 다운로드

먼저 CloudWatch 에이전트 패키지를 다운로드했습니다:

# Ubuntu/Debian 계열
wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

2. 패키지 설치

다운로드한 패키지를 설치했습니다:

sudo dpkg -i amazon-cloudwatch-agent.deb

설치가 완료되면 /opt/aws/amazon-cloudwatch-agent/ 디렉토리가 생성됩니다.

구성 파일 생성

1. 구성 파일 디렉토리 이동

CloudWatch 에이전트 구성 파일을 생성하기 위해 해당 디렉토리로 이동했습니다:

cd /opt/aws/amazon-cloudwatch-agent/bin/

2. 구성 파일 생성

종합적인 모니터링을 위한 구성 파일을 생성했습니다:

sudo vi config.json

vi 에디터로 amazon-cloudwatch-agent.json 파일을 생성 후 아래 내용을 넣습니다.

 {
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent"
  },
  "metrics": {
    "namespace": "CWAgent",
   "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    },
    "metrics_collected": {
      "cpu": {
        "measurement": ["cpu_usage_user", "cpu_usage_system", "cpu_usage_idle", "cpu_usage_iowait"],
        "metrics_collection_interval": 60,
        "totalcpu": true
      },
      "disk": {
        "measurement": ["used_percent"],
        "metrics_collection_interval": 60,
        "resources": ["*"]
      },
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/messages",
            "log_group_name": "lifelog-dev-system-logs",
            "log_stream_name": "{instance_id}-messages",
            "timezone": "Local"
          }
        ]
      }
    }
  }
}

CloudWatch 에이전트 실행

1. 에이전트 시작

config.json파일을 실행하기 위한 권한을 주었습니다.

chmod 755 config.json

그리고 생성한 config.json 파일을 참조하여 CloudWatch 에이전트를 시작했습니다

sudo amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:config.json -s

2. 에이전트 상태 확인

정상적으로 실행되고 있는지 상태를 확인했습니다:

sudo systemctl status amazon-cloudwatch-agent

<결과>

3. 시스템 서비스 관리

에이전트가 시스템 서비스로 등록되었으므로, 이후에는 systemctl로도 관리할 수 있습니다:

# 상태 확인
sudo systemctl status amazon-cloudwatch-agent

# 재시작
sudo systemctl restart amazon-cloudwatch-agent

# 자동 시작 설정 (인스턴스 재부팅 시 자동 시작)
sudo systemctl enable amazon-cloudwatch-agent

모니터링 결과 확인

CloudWatch 대시보드에서 시각화하기

모니터링 설정이 완료되었다면, CloudWatch 대시보드를 통해 수집된 메트릭을 시각화해보겠습니다.

대시보드 생성 과정

1. AWS 콘솔 → CloudWatch → 대시보드 → 대시보드 생성
2. 위젯 추가 → 선 그래프 선택
3. 지표 탭 → 모든 지표 → CWAgent 네임스페이스 선택

수집되는 주요 메트릭

CloudWatch Agent를 통해 다음과 같은 시스템 메트릭들이 1분 간격으로 수집됩니다:

• CPU 사용률

  • cpu_usage_idle: 유휴 상태 CPU 비율
  • cpu_usage_iowait: I/O 대기 시간
  • cpu_usage_user: 사용자 프로세스 CPU 사용률
  • cpu_usage_system: 시스템 프로세스 CPU 사용률

• 디스크 사용률

  • disk_used_percent: 디스크 사용률 (%)

• 메모리 사용률

  • mem_used_percent: 메모리 사용률 (%)

대시보드 결과 예시

설정이 완료되면 아래와 같이 실시간 모니터링 대시보드를 확인할 수 있습니다:

참고: 메트릭이 대시보드에 나타나기까지 5-10분 정도 소요될 수 있습니다. Agent 설정 적용 후 잠시 기다린 다음 확인해보세요.

처음엔 "도대체 그게 왜 중요한 거지?🙄"라는 생각이 들었다. 왜 객체의 상태를 바꾸면 안 되는 걸까? 직접 코드를 구현하고, 다양한 상황을 실험해보면서, 불변 객체가 왜 필요하고 어떤 문제를 막아주는지 조금씩 체감할 수 있었다. 이 글에서는 그 과정을 통해 내가 깨달은 불변 객체의 필요성에 대해 이야기해보려 한다.

💡불변 객체란?

불변 객체(Immutable Object) 란 한 번 생성되면 내부 상태가 절대 변하지 않는 객체를 말한다. 즉, 객체가 생성된 이후에는 어떤 방식으로도 그 속성 값을 바꿀 수 없다.

이러한 특성 덕분에, 불변 객체는 사용하는 입장에서 믿고 쓸 수 있는 신뢰성 있는 객체가 된다. 상태가 바뀌지 않기 때문에 언제, 어디서, 어떤 상황에서 사용해도 예측 가능한 동일한 동작을 보장한다.

여기서 "예측 가능한 동작"이란 이 객체는 어떤 코드에서 사용하든 항상 같은 값을 리턴하고, 갑작스러운 변경이 발생하지 않는다는 의미다..

예를 들어, 아래와 같은 코드가 있다고 해보자.

Crew meringue = new Crew("머랭", "WANNI"); 
System.out.println(meringue.getName()); 

만약 위의 Crew 객체가 불변 객체라면, 어떤 메서드, 어떤 클래스, 어떤 스레드에서 호출하더라도 meringue.getName()은 항상 "머랭"을 반환한다.

하지만 Crew 객체가 가변 객체라면? 외부에서 객체의 상태를 바꿀 수 있게 되면, 협업 중 누군가 실수로 값을 바꾸거나, 멀티스레드 환경에서 예상치 못한 변경이 일어나 버그의 원인이 될 수도 있다.

💡불변 객체를 만드는 4가지 원칙

불변 객체를 만들기 위해선 몇 가지 원칙을 지켜야 한다. 이 네가지 원칙이 잘 어우러질때 비로소 완전한 불변 객체가 완성된다.

각 원칙은 다음과 같다. 1️⃣ 필드는 private으로 선언해 외부 접근을 막자. 2️⃣ setter는 지양하자. 3️⃣ 값의 재할당을 막기 위해 final을 붙이자. 4️⃣ 컬렉션이나 참조 타입은 방어적 복사를 활용하자.

아래 코드는 불변 객체를 만들기 위한 4가지 원칙을 전혀 지키지 않은 사례다. 이 코드가 어떤 문제를 만들 수 있는지 각 단계별로 살펴보고, 어떻게 개선할 수 있는지도 함께 알아보자.

• Crew 클래스: 크루원들의 이름과 그룹을 저장하는 클래스.

• Team 클래스: 크루들을 관리하는 일급 컬렉션

  public class Crew {
       public String name;
    public String group;
  
    public Crew(String name,String group) {
        this.name = name;
        this.group = group;
    }
  
    public String getName() {
        return name;
    }
  
    public String getGroup() {
        return group;
    }
  
    public void setName(String name) {
        this.name = name;
    }
  
    public void setGroup(String group) {
        this.group = group;
    }
  }

public class Team {
    public List<Crew> crews;

    public Team(List<Crew> crews) {
        this.crews = crews;
    }

    public List<Crew> getCrews() {
        return crews;
    }
}

🔻필드는 private으로 선언해 외부 접근을 막자.

만약 각 필드가 private으로 선언되지 않는다면 무슨 문제가 생길 수 있을까? 객체지향적 관점에서 보면, 캡슐화(encapsulation) 원칙이 깨진다는 문제가 있다.

위키백과에서는 캡슐화를 다음과 같이 정의한다:

객체의 속성(data fields)과 행위(methods)를 하나로 묶고, 실제 구현 내용 일부를 외부에 감추어 은닉한다.

private 접근 지정자는 클래스 내부에서만 접근이 가능하다. 반면 protected나 public은 클래스 외부에서도 필드에 접근할 수 있기 때문에, 내부 구현이 노출되고 데이터가 외부에서 쉽게 변경될 수 있다.

아래 예제를 통해 문제 상황을 확인해보자.

    @DisplayName("크루원의 이름을 확인한다.")
    @Test
    void test() {
        Crew moco = new Crew("모코", "WANNI");
        moco.name = "레몬";
        moco.group = "NEO";

        SoftAssertions.assertSoftly(softly -> {
            softly.assertThat(moco.name).isEqualTo("레몬");
            softly.assertThat(moco.group).isEqualTo("NEO");
        });
    }

Crew 클래스의 필드가 public으로 선언되어 있기 때문에, 외부 코드에서 name과 group을 마음대로 바꿀 수 있다. 이로 인해 객체의 신뢰성과 일관성이 무너진다.

✅ 해결 방법은 간단하다.

필드를 private으로 선언하자. 이렇게 하면 객체의 내부 상태가 외부에서 직접 보이거나 변경되는 일을 막을 수 있고, 객체지향의 핵심 원칙인 캡슐화를 자연스럽게 지킬 수 있다.

private String name;
private String group;

애초에 컴파일 단계에서 에러가 발생하여 잘못된 접근을 사전에 차단할 수 있다.

🔻Setter는 지양하자.

앞서 필드를 private으로 선언했으니, 더 이상 값을 수정할 수 없을까? 그렇지 않다. setter 메서드가 존재한다면, 외부에서는 여전히 객체의 내부 상태를 마음대로 바꿀 수 있다.

    @DisplayName("setter로 크루원의 정보를 바꾼다.")
    @Test
    void test() {
        Crew moco = new Crew("모코", "WANNI");
        moco.setName("레몬");
        moco.setGroup("NEO");

        SoftAssertions.assertSoftly(softly -> {
            softly.assertThat(moco.getName()).isEqualTo("레몬");
            softly.assertThat(moco.getGroup()).isEqualTo("NEO");
        });
    }

가장 중요한 문제는, 필드를 protected나 public으로 선언했을 때와 마찬가지로, 객체가 생성된 이후에도 마음만 먹으면 내부 상태를 얼마든지 바꿀 수 있다는 점이다.

이 문제를 해결하려면, 모든 상태를 생성자에서 한 번만 초기화하고, 이후에는 절대 수정할 수 없도록 setter 자체를 만들지 말자.

이렇게 하면 객체는 항상 일정한 상태를 유지하며, 예측 가능하고 안전한 구조를 가질 수 있다.

public class Crew {
    private String name;
    private String group;

    public Crew(String name,String group) {
        this.name = name;
        this.group = group;
    }

    public String getName() {
        return name;
    }

    public String getGroup() {
        return group;
    }
}

🔻값의 재할당을 막기 위해 final을 붙이자.

그렇다면 final의 역할은 무엇일까? 가장 핵심적인 기능은 한 번 할당된 값을 다시는 바꿀 수 없게 만드는 것, 즉 재할당을 막는 것이다 때문에 변경되지 않을 거란걸 명시적으로 표현할떄, 특히 협업 때 쓰는게 좋다

예를들어 아래와 같이 number라는 변수에 값을 할당하고 final을 붙이면

final int number = 1;

이제 이 변수에는 다시 값을 넣을 수 없다. 즉, 다음과 같은 코드는 컴파일 오류를 발생시킨다:

number = 2; //컴파일 에러

이처럼 final을 사용하면 변수나 필드가 다른 값으로 바뀌는 실수를 방지할 수 있다. 클래스의 필드에 final을 붙이는 이유도 같은 맥락으로, 객체의 상태를 의도하지 않은 변경으로부터 보호하기 위함이다.

💡그렇다면 객체 앞에 final이 붙는다면?

 final List<Crew> crews = new ArrayList<>();
 final Crew crew = new Crew("레몬","WANNI");

약 crews 리스트에 crews.add()를 하면 값이 들어갈까? final이라 명시되었기에 약간의 고민이 생길것이다. 또한 player안의 필드값을 변경할 수 있을까?

결론부터 말하자면, 가능하다.

그 이유는 final의 역할이 "재할당을 막는 것" 이기 때문이다. 즉, crews라는 변수에 다른 리스트를 새로 할당하는 건 불가능하지만, 리스트 내부의 요소를 추가하거나 수정하는 건 가능하다.

위에서 말한 것처럼

crews = new ArrayList<>()
crew = new Crew("머랭","NEO")

위의 코드와 처럼 재할당을 하려고 하는것을 방지하기 위해 명시적으로 쓰인다.

🔻컬렉션이나 참조 타입은 방어적 복사를 활용하자.

public class Team {
    private final List<Crew> crews;

    public Team(final List<Crew> crews) {
        this.crews = crews; // 외부 리스트를 그대로 참조
    }

    public List<Crew> getCrews() {
        return crews; // 내부 리스트를 그대로 노출
    }
}

이 코드는 우리가 흔히 볼 수 있는 아주 평범한 구조다. 겉보기엔private 필드에 setter도 없고, 나름 캡슐화가 잘 되어 있는 것처럼 보인다. 그래서 방어적 복사의 개념을 처음 접하기 전에는 이 코드의 문제점을 쉽게 눈치채기 어렵다.

하지만 아래 예시를 보면서 왜 방어적 복사가 필요한지 알아보자.

List<Crew> crewList = new ArrayList<>();
crewList.add(new Crew("레몬", "WANNI"));

Team team = new Team(crewList);

이 코드는 Crew 객체를 생성해서 리스트에 담고, 그 리스트를 이용해 Team 객체를 만든다. 여기까지는 전혀 문제 없어 보인다. 충분히 자연스럽고, 흔히 사용하는 방식이다.

⚠️그런데 여기서 문제가 발생할 수 있다.

// 외부에서 원본 리스트 수정
crewList.add(new Crew("브리", "NEO"));

// 내부 리스트에 직접 접근하여 조작
team.getCrews().add(new Crew("솔라", "NEO"));

//출력
System.out.println(team.getCrews());
/*
[
예상 출력 값: 
  Crew{name='레몬', team='WANNI'},
  Crew{name='브리', team='NEO'},
  Crew{name='솔라', team='NEO'}
]
*/

위 코드에서는 Team 객체가 생성된 이후에도 외부에서 얼마든지 내부 상태를 바꿀 수 있는 문제가 발생한다.

• 첫 번째 줄에서는 Team이 생성된 이후, 원래 넘겼던 crewList를 직접 수정함으로써 내부 데이터에 영향을 준다.

• 두 번째 줄에서는 getCrews()를 통해 내부 리스트에 접근하고, 그대로 .add()를 호출해서 새로운 객체를 추가하고 있다.

이 두 줄만으로 Team의 내부 상태는 언제든지 변경 가능해졌고, 이는 불변성을 완전히 깨트리는 심각한 설계적 결함이다.

더욱 심각한 상황도 있다. 만약 실수로 데이터를 삭제한다면 어떻게 될 것인가.

crewList.clear(); // 외부에서 리스트를 삭제

team.getCrews().clear(); // 내부 리스트를 직접 삭제

System.out.println(team.getCrews()); // []

아무리 Team 객체 내부에서 crews를 private final로 선언했다고 해도, 내부 리스트가 외부에 노출되어 있거나 방어적 복사가 되지 않았다면, 이렇게 외부에서 .clear()를 호출함으로써 내부 데이터를 완전히 지워버릴 수 있다.

🚨이러한 문제를 방지하기 위해서는 다음과 같은 방어적 복사 전략이 반드시 필요하다.

[수정된 Team 클래스]

public class Team {
    private final List<Crew> crews;

    public Team(final List<Crew> crews) {
        this.crews = new ArrayList<>(crews); // 방어적 복사
    }

    public List<Crew> getCrews() {
        return Collections.unmodifiableList(crews); // 불변 리스트로 노출
    }
}

⭕방어적 복사의 장점

1. Team객체를 만들 때 생성자를 통해 외부에서 받은 리스트를 직접 필드로 저장하지 않고, 리스트 복사본을 만들어 참조를 끝는다. 외부에서 원본 리스트를 건드려도 Team 객체 내부 리스트가 영향을 받지 않음 → 내부 데이터 보호.

2. 필드의 crews를 반환시 Collections의 unmodifiableList를 사용하여 불변 리스트로 반환한다. 외부에서 getCrews()로 받은 리스트를 조작하려고 해도 UnsupportedOperationException 발생 → 불변성 유지.

❌방어적 복사의 단점

매번 복사본을 만들기 때문에 성능 이슈가 발생 가능하다. (특히 리스트가 클때)

✅ 마무리하며...

불변 객체는 처음엔 낯설 수 있지만, 객체의 상태가 예측 가능하고 안정적이라는 점에서 큰 장점을 가진다. 특히 협업이 잦고, 사이드 이펙트에 민감한 환경일수록 불변 객체는 강력한 무기가 된다.

방어적 복사와 final, private, setter 지양과 같은 원칙을 차근차근 적용하다 보면 어느새 견고하고 유지보수하기 쉬운 코드를 만들 수 있게 될 것이다!

"불변 객체는 객체를 믿고 쓸 수 있게 만드는 가장 단단한 약속이다."

우아한테크코스 레벨1 인터뷰를 통해, Static에 대한 나의 기준이 책이나 주변 크루와 같은 외부적인 요인에 의해 결정되어 왔고, 내가 이를 얕게 공부해왔다는 사실을 깨달았다. 이번 기회를 통해 Static에 대해 깊이 있게 공부하고, 언제, 왜 사용할지에 대한 나만의 기준을 세워보고자 한다.

나는 프리코스를 거치며 Parser, Validator와 같은 유틸리티 클래스를 사용하면서 Static의 편리함을 직접 경험했다. 입력값을 검증하거나 다른 형태로 변환하는 등, 간단하면서도 여러 곳에서 사용할 수 있다고 판단되는 경우 Static을 사용했다.

하지만, 이 기준은 굉장히 모호하지 않은가? '간단함'과 '여러 곳에서 사용됨'이라는 기준이 구체적으로 무엇을 의미하는지 누군가 묻는다면 제대로 대답할 수 있을까?

이처럼 안일하고 성의 없는 기준은 나의 성장을 방해하는 큰 요인 중 하나였다. 이번 기회를 통해, 얕게 알고 있던 나 자신을 되돌아보고, Static에 대해 제대로 공부해보자!

Static이란?

스태틱은 크게 4가지로 분류된다.

1. static 변수 : 모든 객체가 공유
2. static 메서드 : 객체 없이 호출 가능
3. static 블록 : 클래스 로드 시 한 번 실행
4. static 내부 클래스 : 외부 클래스 없이 사용 가능

🔻static 변수

• 클래스가 메모리에 로드될 때 한 번만 생성됨.

• 모든 객체가 동일한 값을 공유함.
• 객체가 없어도 클래스명.변수명으로 접근 가능.

class Example {
    static int count = 0; // 클래스 변수 (공유됨)

    Example() {
        count++; // 객체가 생성될 때마다 증가
    }

    void showCount() {
        System.out.println("Count: " + count);
    }
}

public class Main {
    public static void main(String[] args) {
        Example e1 = new Example();
        Example e2 = new Example();
        e1.showCount(); // Count: 2
        e2.showCount(); // Count: 2
    }
}

🔻static 메서드

• 객체 없이 호출 가능 (클래스명.메서드명()).

• static 변수만 접근 가능 (인스턴스 변수는 사용 불가).

내가 위에서 말했던 유틸리티 클래스를 만들어 사용한 사례이다.

• validateInputNullOrEmpty는 입력을 하지 않았거나 빈 값을 입력했는지를 검증한다.
• parseStringToIntegerList는 문자열을 "," 기준으로 정수형 리스트로 변환한다.

이 원래 이 메서드들을 사용하려면 Validator 나 Parser 클래스를 인스턴스화 했어야 했지만, static 메서드로 선언 하면 클래스명.메서드명() 형태로 간편하게 사용할 수 있다.

import java.util.List;
import java.util.ArrayList;

class Validator {
    public static void validateInputNullOrEmpty(String input) {
        if (input == null || input.trim().isEmpty()) {
            throw new IllegalArgumentException("입력은 필수 입니다.");
        }
    }
}

class Parser {
    public static List<Integer> parseStringToIntegerList(String input) {
        List<Integer> result = new ArrayList<>();

        String[] parts = input.split(",");
        for (String part : parts) {
            try {
                result.add(Integer.parseInt(part.trim()));
            } catch (NumberFormatException e) {
                throw new IllegalArgumentException("숫자를 입력해 주세요.");
            }
        }
        return result;
    }
}

public class Main {
    public static void main(String[] args) {
        String input = "1, 2, 3, 4, 5";

        Validator.validateInputNullOrEmpty(input); // 입력값 검증

        List<Integer> numbers = Parser.parseStringToIntegerList(input); //문자열 -> 정수형 리스트로 변환

        System.out.println("Parsed numbers: " + numbers); // 출력: [1, 2, 3, 4, 5]
    }
}

🔻static 블록

• 클래스가 로드될 때 한 번 실행됨.

• 주로 초기화 작업에 사용됨.
• 한 클래스 안에 여러개의 static 블록을 사용할 수 있다.
• static 블록의 순서대로 로딩한다.

class Example {
    static String value;

    static {
        value = "첫번째 스태틱 블록";
           System.out.println(value);
    }

    static {
        value = "두번째 스태틱 블록";
        System.out.println(value);

    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println(Example.value);
    }
}

/*
<출력결과>
첫번째 스태틱 블록
두번째 스태틱 블록
두번째 스태틱 블록
*/

💡만약 클래스 내부에 스태틱 블록, 인스턴스 블록, 생성자가 있다면 출력 순서는 어떻게 될까?

public class Example {

    static {
        System.out.println("1. static 블록 실행!");
    }

    {
        System.out.println("2. 인스턴스 블록 실행!");
    }

    public Example() {
        System.out.println("3. 생성자 실행!");
    }

    public static void main(String[] args) {
        System.out.println("메인 메서드 시작!");
        new Example();
        System.out.println("-----------");
        new Example();
    }
}

1. static 블록 실행!
메인 메서드 시작!
2. 인스턴스 블록 실행!
3. 생성자 실행!
-----------
2. 인스턴스 블록 실행!
3. 생성자 실행!

🔢** 실행 순서**

1. static 블록 → 클래스가 메모리에 로드될 때 단 한 번 실행

2. ** 인스턴스 블록** → 객체가 생성될 때마다 생성자보다 먼저 실행

3. 생성자 → 인스턴스 블록 이후 실행됨

🔻static 내부 클래스

• 외부 클래스의 인스턴스 없이 사용 가능.

class Example {
    static class Inner {
        void display() {
            System.out.println("예제의 내부 클래스에서 출력합니다!");
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Example.Inner obj = new Example.Inner();
        obj.display();  // 예제의 내부 클래스에서 출력합니다!
    }
}

⭕다양한 스태틱 사용 사례

평소에 우리는 Staitc을 알게 모르게 자주 사용하고 있었다. 어느 부분에서 사용하고 있었을지 알아보자.

🔻상수 선언

• 공통적으로 쓰이는 값들을 전역으로 공유하고 싶을 때 사용한다.
• 클래스명.상수명 으로 접근 가능하다.

우아한테크코스의 미션을 진행하면서 공통적으로 쓰이는 예외메시지를 한곳에서 관리하고 싶을때 사용했었다.

public class ErrorMessage {
    public static final String NULL_POINTER = "NULL 참조가 발생했습니다.";
    public static final String INVALID_INPUT = "잘못된 입력입니다.";
    public static final String USER_NOT_FOUND = "사용자를 찾을 수 없습니다.";
    public static final String IMPOSSIBLE_POSITION = "이동 불가능한 위치입니다.";
}

🔻Enum 클래스

Enum(열거형)은 자바에서 열거된 상수들을 다룰 수 있게 해주는 특별한 클래스이다. 내부적으로 Enum은 여러 개의 static final 필드를 통해 상수들을 정의하며, 이들은 클래스가 로드될 때 static 블록을 통해 초기화된다.

public enum Day {
    MONDAY, TUESDAY, WEDNESDAY;
}

위의 Day 클래스는 Enum클래스로 선언되어 있다. 겉으로는 왜 static으로 구성돼 있는지 잘 드러나지 않지만, 디컴파일을 통해 내부 구조를 보면 다음과 같다:

[디컴파일된 Day.class]

public final class Day extends Enum<Day> {

    public static final Day MONDAY;
    public static final Day TUESDAY;
    public static final Day WEDNESDAY;
    private static final Day[] VALUES;

    static {
        MONDAY = new Day("MONDAY", 0);
        TUESDAY = new Day("TUESDAY", 1);
        WEDNESDAY = new Day("WEDNESDAY", 2);
        VALUES = new Day[] { MONDAY, TUESDAY, WEDNESDAY };
    }

    public static Day[] values() {
        return VALUES.clone();
    }

    private Day(String name, int ordinal) {
        super(name, ordinal);
    }
}

Enum 클래스의 필드를 보면 모두 static 변수로 선언되어 있다. 그리고 static 블록에서 초기화를 하고 있다. 그렇기에 클래스명.변수명 으로 사용이 가능하다.

public class Main {
    public static void main(String[] args) {
        Day today = Day.MONDAY;
        System.out.println("오늘은 " + today + "입니다.");
    }

    //출력: 오늘은 MONDAY입니다.

}

🔻Math 클래스

• Math는 객체를 생성하지 않고 바로 사용하는 순수 유틸리티 클래스.
• 내부 메서드는 모두 static으로 선언되어 있다.

아래는 Math클래스의 사용 예시이다. Math.메서드명() 으로 사용가능하다.

public class MathPractice {
    public static void main(String[] args) {
        int absValue = Math.abs(-1);
        System.out.println(absValue);
    }
    //출력: 1
}

Math 클래스 내부의 메서드들을 살펴보면 전부 Static으로 선언되있다. 아래는 몇가지 Math의 메서드을 가져와 봤다.

   @IntrinsicCandidate
    public static int abs(int a) {
        return (a < 0) ? -a : a;
    }

   @IntrinsicCandidate
    public static int min(int a, int b) {
        return (a <= b) ? a : b;
    }

   @IntrinsicCandidate
    public static double max(double a, double b) {
        if (a != a)
            return a;   // a is NaN
        if ((a == 0.0d) &&
            (b == 0.0d) &&
            (Double.doubleToRawLongBits(a) == negativeZeroDoubleBits)) {
            // Raw conversion ok since NaN can't map to -0.0.
            return b;
        }
        return (a >= b) ? a : b;
    }

🔻Collections / Arrays 클래스

Java에서 Collections와 Arrays 클래스는 유용한 정적(static) 메서드들을 제공하여 컬렉션 및 배열을 쉽게 조작할 수 있도록 도와준다.

public class CollectionPractice {
    public static void main(String[] args) {
        // Arrays.asList 는 static 메서드
        List<Integer> numberList = Arrays.asList(1, 3, 2, 9, 4, 5);

        // Collections.sort 도 static 메서드
        Collections.sort(numberList);

        System.out.println("정렬된 리스트: " + numberList);
    }
    // 출력: 정렬된 리스트: [1, 2, 3, 4, 5, 9]
}

예시를 위해 몇가지 메서드들을 가져와봤다.

// 배열을 리스트로 변환
 public static <T> List<T> asList(T... a) {
        return new ArrayList<>(a);
    }
 //정렬 메서드
 public static <T extends Comparable<? super T>> void sort(List<T> list) {
        list.sort(null);
    }
//리스트 랜덤 메서드
 public static void shuffle(List<?> list) {
        Random rnd = r;
        if (rnd == null)
            r = rnd = new Random(); // harmless race.
        shuffle(list, rnd);
    }

🔻Singleton(싱글톤) 패턴

• 싱글톤(Singleton) 패턴은 객체를 오직 하나만 생성하도록 보장하는 디자인 패턴이다.
• 객체를 생성하지 않아도 메서드명.getInstance()로 호출 가능하고, 어디서든 동일한 인스턴스에 접근할 수 있다.

public class Singleton {
    // static으로 유일한 인스턴스를 선언
    private static Singleton instance = new Singleton();

    private Singleton() {}

    // static 메서드를 통해 인스턴스를 제공
    public static Singleton getInstance() {
        return instance;
    }
}

[사용예시]

public class Main {
    public static void main(String[] args) {
        Singleton s1 = Singleton.getInstance();
        Singleton s2 = Singleton.getInstance();

        s1.doSomething();

        System.out.println(s1 == s2);  // true (동일 인스턴스(객체))
    }
}

💡나의 Static 사용 기준 정해보기

• 인스턴스 필드나 상태를 가지지 않고, 범용적인 기능 제공(유틸리티성)을 목적으로 하는 클래스는
  객체 생성 없이 사용될 수 있도록 static 메서드로 구성한다.

• 단! 캐싱이나 설정값처럼 전역적으로 공유해야 하는 데이터는 static 필드를 써야한다.

• 즉, 불변 유틸리티 + 공유 자원이 static을 사용하는 핵심 영역이다.

🔻반례: 객체의 상태를 다루는 경우

• 객체의 상태를 다루는 클래스, 즉 내부에 필드가 있고 그 값이 바뀌는 경우에는 static 보다는 인스턴스 메서드를 사용하는 것이 적절하다.

  public class Counter {
    private static int count = 0;
  
    public static void increment() {
        count++;
    }
  
    public static int getCount() {
        return count;
    }
  }

위의 메서드를 static으로 선언하게 되면, 모든 Counter 인스턴스는 동일한 값을 공유하게 된다. 따라서 서로 다른 객체에서 increment()를 호출해도 count 값은 공통으로 증가하게 된다.

🔻나의 static 사용 기준

스프링 시큐리티를 처음으로 공부하고 프로젝트에 적용하게 되면서 배운 내용들과 생각을 정리한 글이다.😊

💡스프링 시큐리티(Spring Security) 란?

공식문서에서는 아래와 같이 정의하고 있다.

Spring Security는 인증(Authentication), 권한 부여(Authorization), 그리고 일반적인 공격으로부터의 보호를 제공하는 프레임워크이다. 명령형(imperative)과 리액티브(reactive) 애플리케이션 보안을 모두 완벽히 지원하며, Spring 기반 애플리케이션 보안을 위한 사실상의 표준(de-facto standard)으로 자리 잡고 있다.

스프링 시큐리티 아키텍쳐

먼저 공식 문서를 통해 스프링 시큐리티 아키텍쳐 에 대해 공부를 하였다. 공식문서에서 서블릿에 대한 얘기가 나오기에 예전에 공부한 서블릿을 복습하였다. 글에서는 단순히 공식 문서 이해를 위해서 단순 요약하여 정리하였다.

스프링 시큐리티와 서블릿의 관계

1. 서블릿 이란?

서블릿은 웹 애플리케이션에서 HTTP 요청을 처리하는 표준 방식으로, Java EE(Enterprise Edition) 의 일부로 등장했다. 서블릿은 HTTP 요청을 받아 요청 데이터를 처리하고, 동적으로 생성한 응답 데이터를 클라이언트에 전달하는 역할을 수행한다. 주로 웹 서버와 클라이언트 간의 데이터 교환을 중재하는 핵심 요소로 사용된다.

2.스프링과 서블릿의 관계

스프링은 Java EE의 복잡성을 해결하고, 더 효율적인 애플리케이션 개발을 지원하기 위해 개발된 프레임워크다. 스프링은 웹 애플리케이션을 처리하기 위해 서블릿을 기반으로 하는 스프링 MVC라는 웹 프레임워크를 제공하게 되었고, 이 과정에서 서블릿은 중요한 역할을 한다. 그 중 DispatcherServlet은 스프링 MVC 애플리케이션의 핵심 서블릿으로, 모든 HTTP 요청을 처리하는 주요 역할을 담당한다.

3. 스프링 시큐리티와 서블릿의 연관성

스프링 시큐리티는 서블릿 컨테이너를 기반으로 동작하며, 서블릿과 밀접하게 연관되어 있다. 스프링 시큐리티는 서블릿 필터(Servlet Filter) 를 활용하여 요청과 응답에 대한 보안 처리를 한다. 서블릿 필터는 서블릿 요청과 응답을 가로채어 중간에서 작업을 수행할 수 있게 해주는 기술이다. 스프링 시큐리티는 서블릿 필터를 통해 인증 및 권한 부여 로직을 처리하며, 웹 애플리케이션에서 발생하는 보안 관련 작업을 제어한다.

이제 공식 문서를 번역하며 이해를 해보려고한다.

공식문서

• https://docs.spring.io/spring-security/site/docs/5.4.6/reference/html5/#servlet-architecture

  1. FilterChain

클라이언트가 요청을 보내면 컨테이너는 요청 URI 경로에 따라 처리해야 할 필터(Filter)와 서블릿(Servlet)을 포함하는 FilterChain을 생성한다.

스프링 MVC 애플리케이션에서는 이 서블릿이 주로 DispatcherServlet 이다. 하나의 요청(HttpServletRequest, HttpServletResponse)에 대해 하나의 Servlet만이 직접 처리할 수 있다는 제약이 있지만, 여러 개의 Filter는 함께 사용될 수 있다.

FilterChain은 요청 흐름에서 다음 필터나 서블릿을 호출하며, 요청 처리의 순서를 제어한다. 이를 통해 필터는 요청이 처리되기 전 또는 후에 원하는 작업을 삽입할 수 있다.

2. DelegatingFilterProxy

스프링은 필터를 구현한 DelegatingFilterProxy 를 제공하고, DelegatingFilterProxy는 Spring과 서블릿 컨테이너를 연결해준다. 서블릿 컨테이너가 직접 Spring Bean을 알지 못하므로, DelegatingFilterProxy가 대신 Spring Bean으로 등록된 필터(Filter)를 찾아 실행한다.

위의 그림은 DelegatingFilterProxy가 필터와 FilterChain에서 어떻게 작동하는지 보여주는 그림이다. DelegatingFilterProxy는 ApplicationContext에서 Bean Filter0을 찾아 실행한다.

3. FilterChainProxy

FilterChainProxy는 Spring Security에서 중요한 역할을 하는 필터로, 여러 보안 필터를 관리하고 순차적으로 실행하는 데 사용된다. SecurityFilterChain을 통해 필터를 처리하고, 이를 DelegatingFilterProxy가 위임하여 실행하도록 한다.

4. SecurityFilterChain

SecurityFilterChain은 FilterChainProxy에 의해 사용되어, 요청에 대해 호출해야 할 Spring Security 필터를 결정한다. 요청되는 URL에 따라 알맞는 SecurityFilterChain(0~n) 이 실행된다.

5.Handling Security Exceptions

ExceptionTranslationFilter는 FilterChainProxy 내의 보안 필터(Security Filters) 중 하나이며, 요청 중 발생하는 인증 및 권한 문제를 처리하고 적절한 응답을 반환하는 역할을 하는 필터이다.

ExceptionTranslationFilter의 동작

1. 요청 처리 시작

   • 요청(로그인)의 결과로 인증 실패나 권한 거부등이 발생할 수 있다.
     

2. 인증되지 않았거나 AuthenticationException이 발생한 경우

   • 이 단계는 사용자가 로그인하지 않았거나, 인증 정보가 잘못된 경우에 해당한다.
     • AuthenticationEntryPoint 호출하여 로그인 페이지로 리디렉션 하여 인증 정보가 필 요하다는 것을 클라이언트에게 알린다.
       

3. AccessDeniedException이 발생한 경우

   • 이 단계는 사용자가 로그인은 되어 있지만, 해당 요청에 필요한 권한이 부족한 경우에 해당한다.

   • AccessDeniedHandler 호출하여 접근 권한이 없다는 메시지를 클라이언트에게 보냅니 다.

   • 웹페이지는 403, REST API에서는 403 응답 코드를 반환한다.

     
     
   4. 예외가 없는 경우
      • 요청 처리 과정에서 AccessDeniedException이나 AuthenticationException이 발생하지 않으면, ExceptionTranslationFilter는 아무 작업도 하지 않고 요청 처리를 정상적으로 마친다..

쉽게 말하자면 ExceptionTranslationFilter를 보안 수문장이라고 생각할 수 있다:

• 수문장은 요청을 그대로 전달한다.(정상적인 경우).
• 만약 인증되지 않았거나 잘못된 인증 정보가 있다면, "로그인하세요!"라고 알려준다.
• 인증은 되었지만 권한이 부족한 경우, "여기는 들어오면 안 돼요!"라고 거절한다.
• 문제가 없으면 그냥 지나가게 한다.

Spring Security 시작하기

빈에 등록하기

스프링 시큐리티는 Gradle 기준으로 build.gradle에 아래와 같이 설정하면 스프링 부트가 자동으로 빈으로 등록하여 사용할 수 있다.

dependencies{
    implementation 'org.springframework.boot:spring-boot-starter-security'
}

SecurityConfig 커스텀하기

💡SecurityConfig란?

Spring Security 환경 설정을 위한 클래스이다.

SecurityConfig를 구성하기 위해서는 두 가지 애너테이션이 필요하다. 이를 통해 이 클래스가 Spring Security의 보안 설정을 정의한 클래스임을 나타낼 수 있다.

• @EnableWebSecurity : SpringConfig 클래스에 @EnableWebSecurity 애너테이션을 사용하면 해당 클래스가 Spring Security의 보안 설정을 담당하는 설정 클래스로 인식된다. 이 애너테이션을 사용함으로써 Spring Security의 보안 관련 설정을 활성화할 수 있다.

• @Configruation :

• Spring 설정 클래스*를 정의할 때 사용된다. 이 애너테이션을 붙인 클래스는 Spring 컨테이너의 빈(Bean) 으로 등록되며, 이 클래스에서 정의된 @Bean 메서드들을 Spring 컨테이너에 등록할 수 있다. 즉, 보안 설정 클래스의 필터 체인, 인증 매니저(AuthenticationManager), CORS 설정 등과 같은 모든 보안 관련 설정을 Spring 컨테이너가 관리할 수 있도록 등록한다.

@Configuration        // Spring 설정 클래스를 정의 
@EnableWebSecurity  // Spring Security 설정 활성화
public class SecurityConfig

커스텀하는 두가지 방법

스프링 시큐리티에서는 보안을 구성하기 위한 두가지 주요 방법이 존재한다.바로

1. WebSecurityConfigurerAdapter 상속받기
2. SecurityFilterChain을 이용한 Bean 방식이다.

두 방식 모두 보안 설정을 정의하는 데 사용되지만, 방식과 구현 방법에 차이가 있다.

🔻WebSecurityConfigurerAdapter

• 5.7 버전 이전에 스프링 시큐리티에서 사용되던 기존의 보안 설정 방식이다.

• 개발자는 WebSecurityConfigurerAdapter를 상속받고 클래스에서 제공하는 여러 메서드 (예: configure(HttpSecurity http))를 @Override하는 방식으로 다양한 보안 설정을 커스텀 구성한다.

• 상속 구조에 의존하기 때문에 확장이 제한적일 수 있다.

예시 코드

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/public/**").permitAll()
                .anyRequest().authenticated()
            .and()
            .formLogin();
    }
}

🔻SecurityFilterChain(권장)

Spring Security 5.7 이상에서는 WebSecurityConfigurerAdapter을 지양하고 SecurityFilterChain을 사용하는 방식이 권장된다. 이 방식은 @Bean을 이용하여 보안 설정을 선언적으로 정의한다.

@Bean방식의 장점

• 유연성 : 여러 구성 요소를 조합하거나 조건에 따라 설정할 수 있다.

• 상속의 종속성 제거 : 기존에 WebSecurityConfigurerAdapter 를 반드시 상속해야 했기 때문에 상당히 의존적이었다. 하지만 @Bean을 통해 클래스를 독립적으로 관리할 수 있다.

• Spring과 자연스럽게 통합 : @Bean으로 정의된 보안 구성 요소들은 스프링의 IoC 컨테이너에서 관리를 하기 때문에 스프링의 설정 관행에 맞게 자연스럽게 통합됩니다.

• 테스트 용이성 : 설정이 각 메서드에 분리되어 작성되므로, 특정 설정을 테스트하거나 수정하기가 간단하다.

예시 코드

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**").permitAll()
                .anyRequest().authenticated())
            .formLogin();
        return http.build();
    }
}

✨컴포넌트 기반 아키텍처로의 발전

Spring은 의존성 주입(Dependency Injection) 과 컴포넌트 기반 개발을 핵심 철학으로 삼고 있기 때문에 Spring Security 또한 점점 컴포넌트 기반 아키텍처를 강조하며 발전했다.

기존 WebSecurityConfigurerAdapter 방식은 클래스 상속에 의존했기 때문에 보안 설정을 커스터마이징하기 위해 추상 메서드를 오버라이드해야 했다. 그리고 상속 구조 때문에 다중 상속이 불가능했다. 예를 들어 클래스가 이미 다른 클래스를 상속받고 있다면WebSecurityConfigurerAdapter를 상속할 수 없는 한계가 있었다. 또한 보안 설정이 다른 컴포넌트와 강하게 결합되거나 재사용이 어려웠다.
반면, SecurityFilterChain은 상속 대신 구성(Composition) 방식을 사용하여 보안 설정을 유연하게 정의한다. 컴포넌트 기반으로 보안 설정을 관리하고, 각 보안 설정이 독립적인 빈(Bean)으로 관리되므로 다중 필터 체인 정의나 재사용이 훨씬 용이하다.

프로젝트에서 배포와 CI/CD를 담당하기로 하였다. CD는 경험이 없고,배포와 CI는 교육에서 빠르게 맛만 본 느낌이라 가입부터 배포, CI/CD까지 공부한 내용을 글로 정리하여 공부하고자 한다.

강의 구입

처음 교육에서 AWS를 설명 들었을 때에는 쉽게 이해가 되지 않았고, 스스로 구글링을 하며 배우기에는 자신이 없었다. 때문에 인프런에서 블랙프라이데이 행사때 눈여겨 보던 박재성님의 AWS와 CI/CD 강의를 구입하였다.

• 비전공자도 이해할 수 있는 AWS 입문/실전
• 비전공자도 이해할 수 있는 CI/CD 입문·실전

앞으로 강의 내용과 서적, 구글링을 통해 배운내용을 토대로 진행하려고한다.

사전 준비

• 이메일
• 신용카드
• 전화번호

프리티어 계정 만들기

프리티어 계정 무한 생성하기

AWS에 가입하는 새로운 계정은 1년간 프리티어 혜택을 받을 수 있다. 하지만 나는 전에 쓰던 이메일 계정은 탈퇴를 하였고, 탈퇴한 계정은 다시 재가입이 안된다는 것을 알았다. 이때 새로운 계정을 계속해서 생성하여 프리티어 혜택을 받을 수 있는 방법을 찾았다. AWS는 메일 계정을 기준으로 계정이 생성된다. 때문에 카드나 전화번호가 동일해도 이메일만 다르다면 무제한 무료 사용이 가능하다. 이때 Gmail을 통해 계정을 만드는 글을 발견했다.

• 딱 5분만에 아마존 aws평생 사용하기

상세 정보 입력

이 단계에서 중요한 부분은

• 이름 : 본인의 이름을 영문으로 작성
• 국가코드 : 국가코드(82:대한민국) 포함한 전화번호를 입력합니다.
• 국가 또는 리전 : 국가를 선택합니다. 순서는 섞여있어 찾기는 어렵지만 중간쯤에 케냐,쿠웨이트 사이에 대한민국이 있습니다.
• 주소: 영문 주소를 입력합니다. 한글 주소 영문 변환 사이트

결제 정보 입력

프리티어로 EC2,RDS,S3등 주요 서비스들을 무료로 사용할 수 있다. 하지만, 프리티어를 초과하는 부분에 대해서는 서비스 마다 다른 요금이 청구되기 때문에 유의해야한다.

SMS/전화 인증

이번에도 국가는 대한민국으로, 전화번호는 010으로 시작하여 입력하면 된다.

Support 플랜 선택

AWS는 사용자들을 위해 다양한 지원을 하고 있으며, 지원들 마다 가격이 다르다. 나는 프리티어를 사용 할려고 하고, 나중에 변경할 수도 있기 때문에 기본 지원을 선택하면 된다.

로그인

처음 로그인을 시도하면 두가지 로그인 방식이 존재한다.

1. AWS 루트 사용자

AWS 계정을 처음 생성할 때 사용된 이메일 주소와 비밀번호로 로그인하는 사용자이다.

<특징>

• AWS 계정의 모든 권한을 가지고 있다.
• IAM 정책이나 권한 제약 없이 AWS 리소스에 접근 가능하다.
• 매우 강력하기 때문에 보안 위험이 크다.

2. IAM 사용자

AWS 루트 사용자가 생성한 개별 사용자 계정으로, 특정 권한을 가진 계정입니다.

<특징>

• IAM(Identity and Access Management)을 통해 만들어진 사용자.
• 루트 사용자와 달리 필요한 권한만 부여받아 사용합니다.
• IAM 정책을 통해 접근할 수 있는 AWS 서비스와 리소스를 제한할 수 있습니다.
• 보안 그룹 작업, 특정 서비스 이용 등 제한된 범위에서 사용.

AWS의 권고사항을 보면, 루트 사용자를 일반적으로 사용하지 말 것을 강력하게 권고하고 있다 왜냐하면 root계정은 모든 권한을 가지고 있기 때문에 해킹시 금전적으로 막대한 손해를 입을 가능성이 높다. 즉, 루트 계정을 만들고 IAM 관리자 계정을 생성한 후 IAM 사용자로 이용하는 것을 추천한다.

우테코 선발과정이 끝나고 오랜만에 다시 알고리즘을 시작하였다. 알고리즘 스터디를 만들었고, 하루에 최소 한문제씩 문제를 해결하는 것이 목표이다. DFS와 BFS를 공부하다가 알고리즘을 중단하였기에 블로그에 정리해둔 글과 강의를 통하여 잃어버린 감을 다시 찾으려고 노력하였다. 하지만 백준 2667 번 문제는 내가 처음 겪은 형식이였고, 많은 고민 끝에 문제를 해결하지 못하고 강의를 통해 해결하였다.

유튜브 강의 : 단지 번호 붙이기_자바 (백준 2667)

다른 사람들의 해설과 강의를 통해 약간의 힌트를 얻고 나머지는 스스로 해결하고자 했지만 생각보다 쉽지 않았다.😅

총 두가지 방식의 코드로 해결하였고, 처음 코드는 내가 힌트를 얻고 최초로 해결한 코드이며, 두번쨰 코드는 복습을 위해 다른 방식으로 해결하였다.

문제

<그림 1>과 같이 정사각형 모양의 지도가 있다. 1은 집이 있는 곳을, 0은 집이 없는 곳을 나타낸다. 철수는 이 지도를 가지고 연결된 집의 모임인 단지를 정의하고, 단지에 번호를 붙이려 한다. 여기서 연결되었다는 것은 어떤 집이 좌우, 혹은 아래위로 다른 집이 있는 경우를 말한다. 대각선상에 집이 있는 경우는 연결된 것이 아니다. <그림 2>는 <그림 1>을 단지별로 번호를 붙인 것이다. 지도를 입력하여 단지수를 출력하고, 각 단지에 속하는 집의 수를 오름차순으로 정렬하여 출력하는 프로그램을 작성하시오.

입력

첫 번째 줄에는 지도의 크기 N(정사각형이므로 가로와 세로의 크기는 같으며 5≤N≤25)이 입력되고, 그 다음 N줄에는 각각 N개의 자료(0혹은 1)가 입력된다.

출력

첫 번째 줄에는 총 단지수를 출력하시오. 그리고 각 단지내 집의 수를 오름차순으로 정렬하여 한 줄에 하나씩 출력하시오.

예제 입력

7 0110100 0110101 1110101 0000111 0100000 0111110 0111000

예제 출력

3 7 8 9

풀이🔻

문제에서 가장 중요한 포인트를 생각해보자

• 1은 집이 있는 곳을, 0은 집이 없는 곳을 나타낸다.
• 연결되었다는 것은 어떤 집이 좌우, 혹은 아래위로 다른 집이 있는 경우를 말한다. 대각선상에 집이 있는 경우는 연결된 것이 아니다.

처음 문제를 보았을 때 2차원 배열을 활용해서 각 배열의 값이 1이냐 0이냐를 판단하고자 했다.

    static int[][] complex; //1과 0을 저장할 이차원배열


    complex = new int[N][N]; //지도 초기화

    //단지 입력
    String[] line = new String[N];
        for (int i = 0; i < N; i++) {
            String str = br.readLine();
            for (int j = 0; j < N; j++) {
                //한줄씩 입력받아 1 혹은 0을 넣는다
                complex[i][j] = Character.getNumericValue(str.charAt(j)); 
            }
        }

그리고 만약 값이 1 이라면 주변의(상하좌우) 값이 1인지, 0인지 확인해야 함을 인지했다. 좌우, 혹은 아래위를 이동하기 위해 X좌표 배열과 Y좌표 배열을 사용하였다.

    static int[] x = {0, 0, 1, -1};
    static int[] y = {1, -1, 0, 0};

만약 0이라면 다음 배열 위치로 넘어가고, 주변에 1이 있다면 그 위치에 DFS를 통하여 진입하고, 또 그 위치에서 주변에 1이 있는지 판단하여 재귀적으로 DFS를 호출한다.

         //각 단지의 개수를 저장하기 위한 ArrayList를 하나 생성
        ArrayList<Integer> countList = new ArrayList<> ();
        for (int i = 0; i < N; i++) {
            for (int j = 0; j < N; j++) {
                if (complex[i][j] == 1) { //만약 현재 위치의 값이 1이라면
                    countDanji = 0; 
                    dfs(i, j); //dfs시작
                    countList.add(countDanji); //dfs종료후 리스트에 추가
                }
            }
        }

가장 핵심 로직인 DFS메서드 이다.

1. 현재위치를 방문했다는 것을 기록하기 위해 현재 배열값을 1 -> 0으로 바꾸어준다
   2. 단지의 개수를 1증가 시킨다.
   3. 상하좌우가 1인지 0인지 판단하기 위해 현재 배열위치에서

(-1,0),(1,0),(0,-1),(0,1) 해주며 만약 조건에 맞는다면 DFS 메서드를 재귀호출한다.

  java
   static void dfs(int i, int j) {
        complex[i][j] = 0;
        countDanji++;
        for (int k = 0; k < 4; k++) {
            int newX = i + x[k];
            int newY = j + y[k];
            // 유효성 검사: 범위를 벗어나지 않고 값이 1인지 확인
            if (newX >= 0 && newX < complex.length && newY >= 0 && newY < complex[0].length && complex[newX][newY] == 1) {
                dfs(newX, newY);
            }
        }
    }

전체코드

1번 코드

• 단지 배열을 1과 0으로 채움
• 방문 기록을 단지 배열의 값을 1 -> 0로 바꾸는 것으로 판단
  • BufferedWriter를 사용

import java.io.*;
import java.util.ArrayList;
import java.util.Collections;

public class B_2667 {

    static int[][] complex;
    static int countDanji;
    static int[] x = {0, 0, 1, -1};
    static int[] y = {1, -1, 0, 0};

    public static void main(String[] args) throws IOException{

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        //지도 크기 입력
        int N = Integer.parseInt(br.readLine());

        //지도 초기화
        complex = new int[N][N];
        //visit 초기화

        //지도 입력
        String[] line = new String[N];
        for (int i = 0; i < N; i++) {
            String str = br.readLine();
            for (int j = 0; j < N; j++) {
                complex[i][j] = Character.getNumericValue(str.charAt(j));
            }
        }

        //돌면서 dfs;
        ArrayList<Integer> countList = new ArrayList<>();
        for (int i = 0; i < N; i++) {
            for (int j = 0; j < N; j++) {
                if (complex[i][j] == 1) {
                    countDanji = 0;
                    dfs(i, j);
                    countList.add(countDanji);
                }
            }
        }

        //출력
        bw.write(countList.size()+"\n");
        Collections.sort(countList);

        for (int i = 0; i < countList.size(); i++) {
            bw.write(countList.get(i) +"\n");
        }

        //bw,br 종료
        br.close();
        bw.flush();
        bw.close();
    }

    static void dfs(int i, int j) {
        complex[i][j] = 0;
        countDanji++;
        for (int k = 0; k < 4; k++) {
            int newX = i + x[k];
            int newY = j + y[k];
            // 유효성 검사: 범위를 벗어나지 않고 값이 1인지 확인
            if (newX >= 0 && newX < complex.length && newY >= 0 && newY < complex[0].length && complex[newX][newY] == 1) {
                dfs(newX, newY);
            }
        }
    }

}

2번 코드

• 단지 배열을 boolean형으로 true와 false로 채움
• 방문 기록을 boolean형 visited배열을 통해 true와 false로 구분함
• 단지 배열과 visited배열을 초기화 할 때 공간을 크게 할당하여 Index out of bounds for length 에러를 예방함
  • System.out 사용

import java.io.*;
import java.util.ArrayList;
import java.util.Collections;


public class B_2667_v2 {

    static boolean[][] visited;
    static boolean[][] complex;
    static int countPerDanji;
    static int[] dirX = {-1, 1, 0, 0};
    static int[] dirY = {0, 0, -1, 1};

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        //지도 크기 입력
        int N = Integer.parseInt(br.readLine());

        //초기화
        visited = new boolean[N + 10][N + 10];
        complex = new boolean[N + 10][N + 10];

        //지도(complex) 초기값 설정
        for (int i = 1; i <= N; i++) {
            //한줄씩 입력
            String str = br.readLine();
            for (int j = 1; j <= N; j++) {
                if (str.charAt(j-1) == '1') {
                    complex[i][j] = true;
                }
            }
        }
        br.close();

        ArrayList<Integer> danji = new ArrayList<>();
        for (int i = 1; i <= N; i++) {
            for (int j = 1; j <= N; j++) {
                if (complex[i][j] && !visited[i][j]) {
                    countPerDanji = 0;
                    dfs(i, j);
                    danji.add(countPerDanji);
                }
            }
        }

        System.out.println(danji.size());
        Collections.sort(danji);
        for (int i = 0; i < danji.size(); i++) {
            System.out.println(danji.get(i));
        }
    }

    //dfs 구현
    static void dfs(int x, int y) {
        visited[x][y] = true;
        countPerDanji++;

        for (int i = 0; i < 4; i++) {
            int positionX = dirX[i] + x;
            int positionY = dirY[i] + y;
            if (!visited[positionX][positionY] && complex[positionX][positionY]) {
                dfs(positionX, positionY);
            }
        }
    }
}

SpringSecurity 및 JWT 강의를 보며 소셜로그인을 구현중이였다. 우선 강의 내용을 실습을 통해 구현해보고, 현재 진행 중이던 팀프로젝트에 적용하면서 생겼던 문제들을 분석하고 해결했던 과정을 기록하고자 한다.

민감정보가 담긴 yml 파일 관리

이슈:

구글,네이버,카카오등 클라이언트 정보등이 담긴 민감정보를 깃에 안올리면서 팀원들과 공유하는 방법이 필요

해결 방안:

• gitignore 파일에 yml 파일을 추가하여 Git에 포함되지 않도록 설정.

• 팀원 간 수동으로 yml 파일을 공유하고 로컬 환경에서 배포.

  매번 수동으로 yml파일을 관리하는 것은 비효율 적으로 생각했고,우리 팀은 서브모듈을 활용하여 yml파일을 관리하는 private repository를 하나 개설하였다. 이 외에도 환경변수로 파일을 관리하는 방법등이 있다고 들어 추후 공부할 예정이다.

OAuth2.0 Client_id공유로 인한 에러

이슈:

• 실습에 썼던 구글,네이버,카카오의 애플리케이션의 Client_Id와 Client_Secret 설정을 프로젝트에도 동일하게 사용하였더니 에러가 발생했다. 이유를 몰라 많이 곤란한 문제였다.
• 소셜로그인 창으로 이동하지 않는다.
• 콘솔에도 에러 원인이 나오지 않는다.

해결방안:

• 프로젝트마다 각 소셜 플랫폼의 애플리케이션을 새로 설정해준다.

💡궁금점:

2개의 프로젝트에서 동일한 리디렉션 url을 설정 한다면, OAuth에서는 동일한 프로젝트로 인식하고 처리해주지 않을까 싶었던 것이 나의 생각이였다. 하지만 생각과 달리 에러가 발생하였고, 해당 이유를 추후에 공부하여 정리해야겠다.

스프링 시큐리티 설정 에러

이슈:

• 구글,네이버,카카오로 나뉜 로그인 설정을 구현하기 위해 .oauth2Login()을 여러번 사용하여 해결하고자 했으나 에러가 발생하였다.
• 404에러, 회원가입이 되지 않는등 다양한 에러가 발생하였다.
• 콘솔 로그에서도 나오지 명확한 에러 원인을 찾지 못했었다.

[기존코드]

.oauth2Login(oauth -> oauth
                        .loginProcessingUrl("/login/oauth2/code/google")  // 구글 로그인 URL 처리
                        .userInfoEndpoint(userinfo -> userinfo
                                .userService(principalOauth2UserService)))

 .oauth2Login(oauth -> oauth
                        .loginProcessingUrl("/login/oauth2/code/naver")  // 네이버 로그인 URL 처리
                        .userInfoEndpoint(userinfo -> userinfo
                                .userService(principalOauth2UserService)))

.oauth2Login(oauth -> oauth
                        .loginProcessingUrl("/login/oauth2/code/kakao")  // 카카오 로그인 URL 처리
                        .userInfoEndpoint(userinfo -> userinfo
                                .userService(principalOauth2UserService)))

해결방안:

• 핵심은 .oauth2Login() 메서드가 중복 호출될 때 발생하는 구성 충돌이라고 한다. Spring Security에서 .oauth2Login()은 OAuth2 로그인 흐름을 정의하는 메서드이다. 그러나 이 메서드는 한 번만 호출되어야 하고, 모든 OAuth2 프로바이더를 통합적으로 처리해야 한다.

• loginProcessingUrl 설정 통합: 각 소셜 로그인별 loginProcessingUrl을 하나로 통합하고, {registrationId}를 사용하여 각 소셜 로그인에 맞게 처리하도록 했다. Spring Security는 {registrationId} 값을 자동으로 채워주기 때문에, 개별 로그인 경로를 지정할 필요는 없다.

        .oauth2Login(oauth -> oauth
                        .userInfoEndpoint(userinfo -> userinfo
                                .userService(principalOauth2UserService))  // PrincipalOauth2UserService 사용
  
                        // 각 소셜 로그인 경로에 대해 공통으로 처리
                        .loginProcessingUrl("/login/oauth2/code/{registrationId}")  // Spring Security가 자동으로 {registrationId}에 해당하는 로그인 URL 처리
                        .defaultSuccessUrl("/home", true)  // 로그인 후 리디렉션되는 페이지
  
                )

세션(Session)은 클라이언트와 서버 간의 상태를 유지하기 위한 기술이다. 클라이언트가 서버에 접속해서 통신을 시작한 시점부터 종료할 때까지의 기간 또는 그 기간 동안 서버에서 클라이언트를 식별하고 상태를 유지하는 방식이다.

세션의 주요 특징

1. 상태 유지

• HTTP는 무상태(Stateless) 프로토콜이기 때문에, 기본적으로 클라이언트와 서버 간의 이전 요청 상태를 기억하지 않는다.
• 세션은 클라이언트를 식별해 서버가 클라이언트 상태를 유지하도록 도와준다.

2. 서버에 저장

• 세션 정보는 보통 서버의 메모리나 데이터베이스에 저장된다.
• 클라이언트는 세션 ID를 쿠키나 URL 파라미터 등을 통해 서버로 전송한다.

3. 유효 기간

• 세션은 기본적으로 유효 기간(예: 30분)이 있으며, 유효 기간 동안 클라이언트와 서버의 상태를 유지한다.
• 유효 기간이 지나면 세션 정보는 삭제된다.

세션의 구성 요소

1. 세션 ID

• 세션을 식별하는 고유한 키.
• 보통 랜덤 문자열로 생성되어 클라이언트에 전달된다.

2. 세션 저장소

• 서버에서 세션 데이터를 저장하는 공간.
• 메모리, 데이터베이스, 파일 시스템 등을 사용한다.

3. 쿠키

• 세션 ID를 저장하고 클라이언트가 서버에 요청할 때마다 이를 전송하는 역할.

세션의 동작 원리

[로그인을 통한 세션 동작 구조]

1. 클라이언트가 서버로 요청을 보낸다

• 주소, 로그인등을 클라이언트가 서버로 요청한다.
  

2. 서버는 해당 요청이 최초인지 판단한다.

• 해댕 요청에 대한 응답하는 메서드가 존재하는지 확인한다.
• 최초 요청이면 세션ID를 생성하고 메모리나 데이터베이스에 저장한다.
• 최초 요청이 아니라면 Client에게 전달받은 SessionId를 메모리나 데이터베이스에서 찾는다.
  

3. 클라이언트한테 세션ID를 전달한다.

• 서버는 HTTP Header 안에 쿠키 안에 세션 ID를 담아 클라이언트에 전달한다.

• 세션 ID는 일반적으로 쿠키를 통해 클라이언트의 브라우저에 저장된다.

  
  

4. 다음 요청 부터 Client는 Header안 쿠키에 세션ID를 들고 간다.

• 클라이언트는 이후 요청마다 세션 ID를 서버로 전송한다.
• 서버는 세션 ID를 확인하여 저장된 세션 정보를 로드한다.
  

5. 세션 종료

• 세션의 유효 기간이 만료, 사용자의 로그아웃, 사용자 브라우저 종료등을 하면 세션이 종료되고, 서버는 해당 세션 데이터를 삭제한다.

세션과 로드밸런싱

만약 서버1이 동시 요청을 100개까지 정상적으로 처리한다고 했을때 101번째 부터는 요청을 처리하는 속도가 느려질 것이다. 그때 101번째 요청부터 서버2로 요청을 넘겨 분담하는 것이 로드 밸런싱이다.

궁금증

1. Client가 서버1에 요청을 보낸다면 서버1 안에서 세션ID를 생성,저장 후에 Client한테 header안의 쿠키를 통하여 세션ID를 담아 보낼 것이다.
2. 만약 Client가 요청을 보냈는데 로드 밸런싱으로 인해 서버2로 세션ID를 보내면 서버2는 해당 세션ID를 저장하고 있지 않기 때문에 최초의 요청으로 받아들일것이다.

이 문제를 어떻게 해결할까?

해결방안

1. Sticky Session 사용

로드밸런서가 세션 기간 동안 동일한 클라이언트의 request를 항상 동일한 서버로 라우팅 해주는 기능이다.

예를 들어, Client가 1번부터 3번까지의 서버 중 1번 서버에 세션을 생성하였다면, 이후에 Client가 보내는 모든 요청은 1번 서버로만 보내지게 된다. 즉, Load Balancer는 User가 첫 번째 세션을 생성한 서버로 모든 요청을 리다이렉트 하여 고정된 세션만 사용하게 한다.

장점

• 서버들간의 세션 데이터 교환을 할 필요가 없다.

단점

• 특정 서버에 과부하가 발생할 수 있다.
• 트래픽이 균등하게 배분될 수 없다.
• 특정 서버의 사람들만 활발히 활동할 경우 해당 서버만 과부하가 걸린다.

2. Session Storage 사용

세션을 저장하는 공간을 의미한다. 각 서버는 세션 스토리지를 공유하여 사용한다. 많은 사람들이 이 방식을 채택한다고 한다.

장점

• Sticky Session처럼 트래픽이 몰리는 현상을 방지할 수 있다.
• 서버가 증설되더라도 각 서버에 세션 스토리지의 정보만을 입력하면 사용가능하다.

단점

• 세션 스토리지에 문제가 생기면 모든 세션이 이용이 불가하다.

3. 세션 복제

하나의 세션 저장소에서 변경이 발생하면 변경 사항이 모든 다른 세션에 복제를 하는 것이다.

장점

• 세션을 복제한다면 클라이언트가 이후에 어떤 서버에 접속하더라도 로그인 정보가 세션에서 복제되어 있으므로 세션을 사용 가능하다.
• 장애가 발생하더라도 서비스가 중단 되지 않는다.

단점

• 모든 서버가 동일한 세션 객체를 가져야 하기 때문에 많은 메모리가 필요하다.