문제 상황

• 로컬에서는 Prometheus가 localhost:8080/actuator/prometheus와 localhost:9090/metrics 엔드포인트 둘 다 스크랩 잘됨.
• 그런데 EC2에 올리자 Prometheus UI에서는 localhost:9090/metrics만 보이고, localhost:8080/actuator/prometheus가 잡히지 않음.
• EC2 내부에서 curl http://127.0.0.1:8080/actuator/prometheus는 잘 열림. 문제는 Prometheus가 제대로 스크랩하지 못하는 것.

0. 전체 목표

• EC2에 Prometheus 설치
• Spring Boot(8080) Actuator Prometheus 엔드포인트(/actuator/prometheus)를 스크랩해서 모니터링
• 최종적으로 Grafana 대시보드에 시각화

1. Prometheus 설치 및 기본 설정

1. EC2(Ubuntu) 터미널에서 Prometheus 바이너리 다운로드 & 압축 해제

   wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz
   tar xvfz prometheus-2.47.0.linux-amd64.tar.gz
   cd prometheus-2.47.0.linux-amd64

2. 바이너리(prometheus, promtool)를 시스템 경로로 복사

   sudo cp prometheus /usr/local/bin/
   sudo cp promtool /usr/local/bin/

3. 콘솔 템플릿, 라이브러리, 설정 파일을 /etc/prometheus로 복사

   sudo mkdir -p /etc/prometheus
   sudo cp -r consoles /etc/prometheus/
   sudo cp -r console_libraries /etc/prometheus/
   sudo cp prometheus.yml /etc/prometheus/

4. /etc/prometheus/prometheus.yml 열어보면 기본값으로 localhost:9090/metrics만 스크랩하도록 설정돼 있음.

   global:
     scrape_interval: 15s
   scrape_configs:
     - job_name: 'prometheus'
       static_configs:
         - targets: ['localhost:9090']

   → 아직 Spring 애플리케이션 스크랩 설정 없음.

2. Spring Boot Actuator 설정 확인

로컬 개발 환경에서 이미 다음 작업을 해뒀다.

• build.gradle 또는 pom.xml에

  implementation 'org.springframework.boot:spring-boot-starter-actuator'
  implementation 'io.micrometer:micrometer-registry-prometheus'

• application.yml에

  management:
    endpoints:
      web:
        exposure:
          include: "*"

• 이 상태에서 http://localhost:8080/actuator/prometheus 접속하면 Micrometer 메트릭이 JSON으로 잘 찍힘.

로컬에서는 /actuator/prometheus와 /metrics 둘 다 Prometheus UI에 잡힘.

3. Prometheus에 Spring Actuator 잡아주기

EC2에 올려놓은 prometheus.yml을 수정해서 Actuator 스크랩 잡아주려고 했다.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  # 추가
  - job_name: "spring-actuator"
    metrics_path: '/actuator/prometheus'
    scrape_interval: 15s
    static_configs:
      - targets: ['localhost:8080']

수정 후 Prometheus 재시작:

sudo systemctl daemon-reload
sudo systemctl restart prometheus

근데 Prometheus 웹 UI → Targets 가서 봐도 여전히 "spring-actuator" job이 등록되지 않고 localhost:9090/metrics만 보였다. 즉, 설정이 반영되지 않는 듯한 증상.

4. /etc/prometheus/prometheus.yml에 수정이 안 된 문제

• EC2 터미널에서 nano /etc/prometheus/prometheus.yml 열어보니, 내가 수정한 내용이 반영되어 있지 않았다.
• 그냥 ~/prometheus-2.47.0.linux-amd64/prometheus.yml만 수정했고, 실제로 Prometheus가 읽는 /etc/prometheus/prometheus.yml은 그대로 기본값이었다.

확인:

cat /etc/prometheus/prometheus.yml
# ... 스크랩 설정이 기본상태로 남아 있었음

5. 홈 디렉터리 수정본을 실제 경로로 복사

결국 홈 디렉터리에서 수정한 prometheus.yml을 /etc/prometheus/로 복사한 뒤에야 설정이 먹혔다.

sudo cp ~/prometheus-2.47.0.linux-amd64/prometheus.yml /etc/prometheus/prometheus.yml
sudo systemctl daemon-reload
sudo systemctl restart prometheus

이제 Prometheus UI → Targets에서 “spring-actuator → localhost:8080/actuator/prometheus”가 UP 상태로 떠 있었다.

6. Prometheus 서비스 등록(별도 사용자를 만들진 않고 바로 실행)

서비스 유닛 파일은 이렇게 만들었다. (/etc/systemd/system/prometheus.service)

[Unit]
Description=Prometheus Monitoring Service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.console.templates=/etc/prometheus/consoles \
  --web.console.libraries=/etc/prometheus/console_libraries
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

그리고 실행:

sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus
sudo systemctl status prometheus   # Active: active (running) 확인

—> 이로써 nohup prometheus 같은 백그라운드 실행 없이, EC2가 재부팅돼도 Prometheus가 자동 시작되도록 설정 완료.

7. 최종 확인

1. EC2 내부(SSH 터미널)에서:

   curl -v http://127.0.0.1:8080/actuator/prometheus

   → 200 OK, Micrometer 메트릭 JSON 출력됨.

2. Prometheus UI (http://EC2_PUBLIC_IP:9090) → Targets 탭 확인

   • prometheus → localhost:9090/metrics → UP
   • spring-actuator → localhost:8080/actuator/prometheus → UP

3. Grafana 대시보드에서 Prometheus 데이터 소스로 http://EC2_PUBLIC_IP:9090 추가 후 시각화 가능해졌다.

TIL 포인트

• Prometheus 설정 파일은 실제 서비스가 읽는 경로(/etc/prometheus/prometheus.yml)를 수정해야 한다.
• Spring Boot Actuator 메트릭 스크랩은 절대 public IP:8080이 아니라 **localhost:8080**을 targets에 넣어야 EC2 내부에서 제대로 접근 가능하다.

이상으로 “EC2 Prometheus, Spring Actuator 엔드포인트가 잡히지 않을 때”에 대한 내 TIL 정리 끝.

상황 요약

• CI 파이프라인은 다음 순서로 짜놨음:

  1. Redis 설치
  2. 테스트 실행
  3. Gradle 빌드
  4. EC2 배포

• 테스트는 로컬에선 -Dspring.profiles.active=test 옵션 주고 하면 잘 됨

• 근데 GitHub Actions에선 테스트 단계에서 무조건 실패

⚠️ 실패 로그들

대표적인 실패 에러는 이거들:

1. 프로퍼티 안 채워짐

Caused by: java.lang.IllegalArgumentException at PropertyPlaceholderHelper.java:180

→ ${xxx} 로 설정을 불러오는데 해당 값이 없어서 생긴 에러

2. JWT secret 문제

Caused by: io.jsonwebtoken.security.WeakKeyException at Keys.java:96

→ secret 값이 너무 짧거나 base64 디코딩 실패

🔍 원인 찾기

처음에는 test용 yml 파일이 잘못됐나 싶었는데, 진짜 문제는 application.yml에 있었다.

spring:
  profiles:
    active: local
    include: secret

이게 모든 상황에서 local과 secret 프로파일을 로드함. test 프로파일만 써도 결국 MySQL, JWT, mail 등 민감한 설정이 필요해졌던 거다.

→ 그래서 CI 환경에서는 저 설정들이 없으니까 에러가 나는 구조였던 것.

application-local.yml, secret.yml을 base64로 인코딩해서 GitHub 환경변수(Secrets)에 등록

- name: Restore local.yml
  run: echo "${{ secrets.LOCAL_YML }}" | base64 -d > src/main/resources/application-local.yml

- name: Restore secret.yml
  run: echo "${{ secrets.SECRET_YML }}" | base64 -d > src/main/resources/application-secret.yml

이렇게 해도 실패. 어째서???

Caused by: org.hibernate.HibernateException at DialectFactoryImpl.java:191

그리고 마지막 한 줄:

BUILD FAILED in 55s
Error: Process completed with exit code 1.

즉, DB 연결 시도 중 Dialect 감지를 못 해서 터진 것.

application-test.yml에서는 H2로 설정되어 있지만, 해당 에러는 테스트 중 JPA가 H2가 아닌 MySQL을 로딩하려다 발생한 거였다.

즉, application-test.yml이 로드되지 않고 application-local.yml이 먼저 로드된 상태.

CI 환경에는 MySQL이 없으니 당연히 실패한 거다.

이유는 application.yml의 고정된 Profile 설정 때문이었다.

spring:
  profiles:
    active: local
    include: secret

이렇게 되어 있었기 때문에, 내가 아무리 CI 환경에서 - Dspring.profiles.active=test를 주더라도 application.yml은 여전히 local과 secret 프로파일을 로딩했다.

결국 테스트에서도 MySQL 설정이 적용되어버리는 구조였던 것. CI 환경에는 MySQL이 없으니 당연히 DB Dialect도 찾지 못하고 터지는 게 맞았던 거다.

✅ 결국 해결한 방법

application.yml에서 프로파일을 환경변수 기반으로 바꿨음:

spring:
  profiles:
-   active: local
-   include: secret
+   active: ${SPRING_PROFILES_ACTIVE:local}
+   include: ${SPRING_PROFILES_INCLUDE:secret}

→ 기본은 여전히 local/secret이지만, 환경변수로 덮어쓸 수 있게 된 것이다.

그리고 GitHub Actions에서 이렇게 설정했다:

- name: Set profile
  run: echo "SPRING_PROFILES_ACTIVE=test" >> $GITHUB_ENV

→ application.yml이 기본값은 local/secret 쓰지만, CI 환경에서는 test만 쓰도록 override 가능해짐.

배포까지 확인

회고

• 진짜 핵심은 application.yml을 너무 고정값으로 설정해놨던 거
• CI 환경에서는 로컬이랑 완전히 동일하게 설정해줘야 제대로 작동함
• application.yml은 최대한 유연하게 구성해야 한다는 걸 뼈저리게 느낌
• 삽질도 많았지만 덕분에 Spring Profile, GitHub Actions, CI/CD 전반을 한층 이해하게 됨

기억할 것

CI 환경에서 계속 실패하면 application.yml부터 의심하자. 환경 변수로 유연하게 바꾸는 게 답이다.

초기에는 간단하게 Spring Boot에서 구글 SMTP를 사용하여 메일을 보내고 있었다. 메일 전송은 성공적으로 되었지만, 중요한 문제가 있었다.

❌ 메일이 전부 스팸함으로 분류됨

운영 서비스에서는 치명적인 문제라 판단했고, 도메인 기반 인증이 가능한 AWS SES(Simple Email Service) 로 전환하기로 결정했다.

🔧 1차 삽질: MailConfig 수정 누락

application.yml과 IAM 사용자 설정 등 SES 전환을 잘 마쳤다고 생각했는데, 메일 전송 시 아래 에러가 발생했다:

jakarta.mail.MessagingException: Could not convert socket to TLS;
  nested exception is:
        java.io.IOException: Server is not trusted: email-smtp.ap-northeast-2.amazonaws.com

한참 TLS 인증 문제로 삽질했지만, 원인은 어이없게도...

// 기존 설정 (구글 SMTP)
props.put("mail.smtp.ssl.trust", "smtp.gmail.com");

// → AWS SES 변경 시 이 부분도 바꿔줘야 한다!
props.put("mail.smtp.ssl.trust", "email-smtp.ap-northeast-2.amazonaws.com");

📌 MailConfig에서 호스트 변경은 했지만 ssl.trust는 안 바꿔서 TLS 오류가 발생했던 것...

🔐 2차 삽질: 535 Authentication Credentials Invalid

TLS 에러를 해결하고 나니 이번엔 인증 오류가 떴다:

jakarta.mail.AuthenticationFailedException: 535 Authentication Credentials Invalid

그래서 AWS 공식 문서를 보고 Secret Access Key → SMTP 비밀번호로 변환하는 Python 스크립트를 사용했다.

#!/usr/bin/env python3

import hmac
import hashlib
import base64
import argparse

SMTP_REGIONS = [
    "us-east-2",  # US East (Ohio)
    "us-east-1",  # US East (N. Virginia)
    "us-west-2",  # US West (Oregon)
    "ap-south-1",  # Asia Pacific (Mumbai)
    "ap-northeast-2",  # Asia Pacific (Seoul)
    "ap-southeast-1",  # Asia Pacific (Singapore)
    "ap-southeast-2",  # Asia Pacific (Sydney)
    "ap-northeast-1",  # Asia Pacific (Tokyo)
    "ca-central-1",  # Canada (Central)
    "eu-central-1",  # Europe (Frankfurt)
    "eu-west-1",  # Europe (Ireland)
    "eu-west-2",  # Europe (London)
    "eu-south-1",  # Europe (Milan)
    "eu-north-1",  # Europe (Stockholm)
    "sa-east-1",  # South America (Sao Paulo)
    "us-gov-west-1",  # AWS GovCloud (US)
    "us-gov-east-1",  # AWS GovCloud (US)
]

# These values are required to calculate the signature. Do not change them.
DATE = "11111111"
SERVICE = "ses"
MESSAGE = "SendRawEmail"
TERMINAL = "aws4_request"
VERSION = 0x04


def sign(key, msg):
    return hmac.new(key, msg.encode("utf-8"), hashlib.sha256).digest()


def calculate_key(secret_access_key, region):
    if region not in SMTP_REGIONS:
        raise ValueError(f"The {region} Region doesn't have an SMTP endpoint.")

    signature = sign(("AWS4" + secret_access_key).encode("utf-8"), DATE)
    signature = sign(signature, region)
    signature = sign(signature, SERVICE)
    signature = sign(signature, TERMINAL)
    signature = sign(signature, MESSAGE)
    signature_and_version = bytes([VERSION]) + signature
    smtp_password = base64.b64encode(signature_and_version)
    return smtp_password.decode("utf-8")


def main():
    parser = argparse.ArgumentParser(
        description="Convert a Secret Access Key to an SMTP password."
    )
    parser.add_argument("secret", help="The Secret Access Key to convert.")
    parser.add_argument(
        "region",
        help="The AWS Region where the SMTP password will be used.",
        choices=SMTP_REGIONS,
    )
    args = parser.parse_args()
    print(calculate_key(args.secret, args.region))


if __name__ == "__main__":
    main()

하지만...

❌ 여전히 535 에러 발생

멘탈 붕괴 후… 그냥 CSV 파일에서 받은 Secret Access Key를 그대로 넣어봤는데…

✅ 성공했다.

즉, 변환할 필요 없음!!

SMTP 전용 자격 증명을 발급하면 그 자체가 비밀번호로 바로 사용 가능하다.

✅ 마무리: SPF 설정도 필수

메일이 받은편지함에 잘 도착하기 위해서는 도메인에 아래 TXT 레코드를 추가해야 한다:

TXT    @    "v=spf1 include:amazonses.com ~all"

💭 회고

🧠 "문서가 항상 맞는 건 아니다. 직접 해보는 것이 답이다."

Spring Boot에서 AWS SES를 설정할 땐 단순히 username/password만 입력한다고 끝이 아니라, JavaMail 설정, 도메인 인증, 자격 증명 발급 방식까지 모두 정확히 이해하고 설정해야 한다.

프론트엔드에서 SSE(Server-Sent Events)를 이용해 알림을 구독하려 할 때, 다음과 같은 에러가 발생했다.

EventSource's response has a Content-Type specifying an unsupported type: text/event-stream, text/event-stream. Aborting the connection.

또한 연결이 되자마자 readyState는 2(closed)로 바뀌며, onerror 콜백이 실행되었다. HTTP 응답 코드는 200이었기 때문에, 일단 백엔드나 프록시에서 문제가 발생했다고 생각하지는 않았다.

1. "설정은 다 맞췄는데 왜 안 되지?"

처음에는 백엔드 쪽을 의심했다.

• SseEmitter는 연결 직후 .event("connect").data("connected")를 정상적으로 보내고 있었고,
• heartbeat도 .comment("heartbeat") 형식으로 주기적으로 전송하고 있었다.
• Nginx도 proxy_buffering off, chunked_transfer_encoding on, X-Accel-Buffering no 등 기본 설정은 잘 반영되어 있었다.

게다가 curl로 테스트하면 정상적으로 연결이 유지되었고, heartbeat도 잘 수신되었다.

그래서 프론트 문제일 가능성을 의심했지만, 브라우저 콘솔이 알려준 핵심 단서는 바로 이 부분이었다:

Content-Type: text/event-stream, text/event-stream

2. Content-Type 헤더 중복 문제

Content-Type 헤더가 중복되어 내려가고 있었던 것이다. 이는 Nginx에서 수동으로 add_header Content-Type text/event-stream;를 설정한 것이 원인이었다.

하지만 Spring에서도 이미 text/event-stream을 자동으로 내려주고 있었기 때문에, 브라우저는 이를 비정상적인 응답으로 판단하고 SSE 연결을 바로 종료시켰던 것이다.

해결 방법: /etc/nginx/sites-available/default

# 아래 줄은 제거
add_header Content-Type text/event-stream;

이후 nginx -s reload로 설정을 반영한 뒤 문제는 해결되었다.

3. heartbeat가 있는데도 연결이 끊기는 이유

한 가지 이상한 점은 heartbeat도 주기적으로 보내고 있었는데, 브라우저에서는 연결이 유지되지 않았다는 점이다.

그 이유는 heartbeat를 .comment("heartbeat")로 보내고 있었기 때문이다. 이 방식은 EventSource 내부에서 keep-alive 용도로 사용되긴 하지만, 클라이언트에서 직접 수신하는 이벤트로는 인식되지 않는다.

하지만 프론트에서는 다음과 같이 addEventListener("heartbeat")로 수신을 시도하고 있었다.

eventSource.addEventListener("heartbeat", (e) => {
  console.log("💓 heartbeat 수신:", e.data);
});

따라서 heartbeat도 아래와 같이 수정해주었다.

emitter.send(
  SseEmitter.event()
    .name("heartbeat")
    .data("ping")
);

결과 요약

회고

이번 문제는 언뜻 보기엔 별 문제가 없어 보였지만, 브라우저가 SSE를 다루는 방식은 매우 엄격하며 사소한 설정 차이도 치명적인 결과를 초래할 수 있다는 점을 배웠다.

특히 다음 두 가지는 기억해두어야 할 교훈이다:

• 헤더 중복은 예상보다 더 쉽게 발생하고, 브라우저가 연결을 아예 차단할 수 있다.
• heartbeat는 브라우저가 인식 가능한 방식(event + data)으로 명시적으로 보내야 한다.

처음엔 명확한 로그도 없이 애매하게 끊기고, curl에서는 잘 되던 탓에 문제를 좁히는 데 시간이 오래 걸렸지만, 오히려 그 과정을 통해 SSE의 구조와 동작 원리를 더 깊이 이해할 수 있었다.

이메일 인증 기능을 구현하기 위해 Gmail SMTP 설정을 application-secret.yml에 저장했다.

spring:
  mail:
    host: smtp.gmail.com
    port: 587
    username: coldrice99@gmail.com
    password: my-app-password
    properties:
      mail:
        smtp:
          auth: true
          starttls:
            enable: true

스프링 프로파일도 정상적으로 지정한 상태였다.

# application.yml
spring:
  profiles:
    active: local
    include: secret

✅ 실행 시 출력도 분명히 두 개의 profile이 활성화된 것으로 확인됨:

The following 2 profiles are active: "secret", "local"

그런데도 메일 발송 기능은 항상 실패하고 콘솔에는 아래와 같은 로그가 출력되었다.

✅ 메일 설정 확인:
➡ Host = null
➡ Port = -1
➡ Username = null

🔍 잘못된 진단

• 처음에는 application-secret.yml이 제대로 로딩되지 않는다고 판단하고 프로파일 설정을 수차례 확인
• yml 구조, 들여쓰기, 파일 위치, 프로파일 명칭 등 다양한 부분을 의심하며 불필요한 수정들을 반복함
• 하지만 설정 로딩 자체는 전혀 문제가 없었음

💡 진짜 원인: JavaMailSender를 직접 Bean 등록하지 않았기 때문

Spring Boot는 JavaMailSender를 자동 구성해주지만, 조건부 자동 설정(@ConditionalOnMissingBean)이기 때문에
명시적인 Bean 등록을 하지 않으면, 해당 설정을 사용하는 시점까지 mail 관련 속성을 로딩하지 않음.

즉, application.yml에 mail 속성이 들어 있어도, 그걸 사용할 JavaMailSender가 없으면 아무 일도 일어나지 않음.

✅ 최종 해결 방법

JavaMailSender를 직접 Bean으로 등록하고, 설정 값을 주입받도록 구성했다.

@Configuration
public class MailConfig {

    @Value("${spring.mail.host}")
    private String host;

    @Value("${spring.mail.port}")
    private int port;

    @Value("${spring.mail.username}")
    private String username;

    @Value("${spring.mail.password}")
    private String password;

    @Bean
    public JavaMailSender javaMailSender() {
        JavaMailSenderImpl mailSender = new JavaMailSenderImpl();
        mailSender.setHost(host);
        mailSender.setPort(port);
        mailSender.setUsername(username);
        mailSender.setPassword(password);

        Properties props = mailSender.getJavaMailProperties();
        props.put("mail.smtp.auth", "true");
        props.put("mail.smtp.starttls.enable", "true");

        return mailSender;
    }
}

이후 정상적으로 아래와 같은 로그가 출력되었고, 이메일도 성공적으로 발송되었다.

✅ 메일 설정 확인:
➡ Host = smtp.gmail.com
➡ Port = 587
➡ Username = coldrice99@gmail.com

✍️ 마무리

이번 경험을 통해 Spring Boot의 자동 설정은 무조건 되는 것이 아니라 조건부로 작동함을 다시금 깨달았다.
특히 외부 설정값(yml)에만 집중하다 보면, 실제로 그것을 사용하는 객체가 없어서 생기는 문제를 놓칠 수 있다.

✅ 문제 코드

아래는 클럽 관리자인지 검증하는 로직이다:

if (!club.getManager().equals(manager)) {
    throw new GlobalException(ExceptionCode.UNAUTHORIZED_MANAGER);
}

로그를 찍어보면 다음과 같았다:

System.out.println("club.getManager() = " + club.getManager().getId());
System.out.println("requesting manager = " + manager.getId());

📋 출력 결과:

club.getManager() = 2
requesting manager = 2

두 ID는 분명히 같지만, equals는 false를 반환하여 예외가 발생하고 있었다.

🔍 원인 분석

JPA에서 equals()를 오버라이드하지 않으면, 기본적으로 Object.equals()가 사용된다. 이는 객체의 참조(주소)가 같은지를 비교하기 때문에, 같은 ID를 가진 Member라도 다른 영속성 컨텍스트에서 가져온 객체는 다르다고 판단한다.

즉, 다음과 같은 상황이 되는 것이다:

Member managerFromClub = club.getManager(); // 영속성 컨텍스트 A
Member currentUser = userDetails.getMember(); // 영속성 컨텍스트 B

managerFromClub.equals(currentUser); // false → 예외 발생

✅ 해결 방법

Member 엔티티에 equals()와 hashCode()를 오버라이드하여 ID 기준으로 논리적 동일성을 판단하도록 수정했다:

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Member member = (Member) o;
    return id != null && id.equals(member.id);
}

@Override
public int hashCode() {
    return getClass().hashCode();
}

🔎 이렇게 하면 ID만 같아도 equals()가 true로 판단되어 로직이 제대로 작동한다. 위 코드는 JPA에서 권장하는 패턴이며, Hibernate 공식 문서에서도 소개된 방식이다.

📌 결론

• 인증/인가 관련 로직에서 equals로 객체 비교하는 경우 주의해야 한다.

처음에는 Redis getFairLock을 사용하여 처리 순서를 보장하려 했으나, 테스트 로그를 통해 순서가 보장되지 않는다고 잘못 판단했다. 이로 인해 FairLock은 성능만 저하시킨다고 생각해 사용을 배제했다.
그러나 서비스 로그를 통해 Redis Fair Lock이 요청 순서를 정확히 보장하고 있었음을 뒤늦게 확인했다.

트러블슈팅 과정

1. 초기 테스트 로그와 문제점

초기 테스트 코드는 스레드 시작 및 완료 로그를 출력하여 처리 순서를 확인했다.

@Test
@DisplayName("Redis 락 동시성 제어 테스트")
void redisLockConcurrencyTest() throws InterruptedException {
    for (int i = 0; i < threadCount; i++) {
        int threadId = i;
        executorService.submit(() -> {
            try {
                System.out.println("Thread 시작: " + Thread.currentThread().getId());
                Member threadMember = new Member("Test User" + threadId, "test" + threadId + "@example.com",
                    "password", MemberRole.USER);
                memberRepository.save(threadMember);
                couponService.issueCoupon(coupon.getId(), new RequestDto(threadMember.getId()), threadMember);
            } catch (GlobalException e) {
                System.out.println("Thread 예외: " + Thread.currentThread().getId() + ", " + e.getMessage());
            } finally {
                latch.countDown();
                System.out.println("Thread 완료: " + Thread.currentThread().getId());
            }
        });
    }
}

테스트 로그 결과:

Thread 시작: 70
Thread 시작: 63
Thread 시작: 61
...
Thread 완료: 61
Thread 완료: 70
Thread 완료: 63
...

문제점: 이 로그를 기반으로 FairLock이 제대로 동작하지 않는다고 판단했다.
그러나 테스트 코드의 Thread 시작 로그는 실제 락 처리 순서를 반영하지 않았다.

2. 서비스 로그를 통한 검증

서비스 코드에서 실제로 락을 대기하고 획득하는 부분에 로그를 추가해 검증했다.

@Transactional
public void issueCoupon(Long couponId, RequestDto request, Member member) {
    String lockKey = "coupon:" + couponId;
    RLock lock = redissonClient.getFairLock(lockKey);

    try {
        System.out.println("대기중: " + Thread.currentThread().getId());
        if (!lock.tryLock(1, 10, TimeUnit.SECONDS)) {
            System.out.println("Thread " + Thread.currentThread().getId() + "락 획득 실패.");
            throw new IllegalStateException("동시에 너무 많은 요청이 발생했습니다. 잠시 후 다시 시도해주세요.");
        }
        System.out.println("Thread " + Thread.currentThread().getId() + "락 획득.");

        // 비즈니스 로직 처리
        Coupon coupon = couponRepository.findById(couponId)
            .orElseThrow(() -> new GlobalException(COUPON_NOT_FOUND));
        coupon.validateQuantity();
        coupon.decreaseQuantity();

        Issuance issuance = Issuance.builder()
            .member(member)
            .coupon(coupon)
            .build();
        issuanceRepository.save(issuance);

    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
            System.out.println("Thread " + Thread.currentThread().getId() + " released lock.");
        }
    }
}

3. 로그 결과를 통한 순서 보장 확인

대기 중 로그와 락 획득 및 해제 로그를 비교해 FairLock이 요청 순서를 정확히 보장하고 있음을 확인했다.

1. 대기 중 순서:

   63, 71, 65, 70, 62, 61, 66, 64, 68, 67, 103, 98, 139...

2. 락 획득 순서:

   70, 63, 61, 65, 64, 71, 62, 66, 68, 67, 103, 98, 139...

분석:

• 초기 몇 개의 스레드는 락 대기 순서와 락 획득 순서가 불일치했으나, 68번 스레드 이후부터는 락 대기 순서대로 락을 획득하고 있었다.
• 초기 순서 불일치는 스레드 스케줄링의 비결정성과 로그 출력 시점과 락 처리의 비동기적 특성에 의해 발생한 것이다.

결론

1. Redis Fair Lock은 요청 순서를 보장:

   • FairLock은 Redis 대기열을 기반으로 락 획득 순서를 보장한다는 점이 확인됐다.
   • 초기 혼란은 테스트 로그가 실제 순서를 정확히 반영하지 않았기 때문이었다.

2. 초기 순서 불일치는 자연스러운 현상:

   • 스레드 스케줄링과 Redis 통신의 비동기적 특성으로 인해, 초기 몇 개의 스레드에서는 대기 순서와 락 획득 순서가 다를 수 있다.
   • 그러나 이후부터는 락 대기열에 따라 순서가 명확히 유지된다.

3. FairLock 사용 유지 결정:

   • FairLock을 사용하면 성능이 약간 저하될 수 있지만, 요청 순서가 중요한 경우에는 반드시 사용해야 한다는 결론을 내렸다.

쿠폰 발급 API에서 다수의 요청이 동시에 들어왔을 때, 동시성 문제와 요청 순서 처리 문제가 발생했다. 초기 코드는 Redis의 RLock을 사용하여 동시성 문제를 해결했으나, 요청을 순서대로 처리하는 데 실패했다. 이를 해결하기 위해 다양한 방법을 시도했으나, 동시에 들어오는 요청의 순서 처리에 완벽한 보장을 구현하기 어렵다는 결론을 지었다.

트러블슈팅 과정

1. 초기 코드와 문제점

초기 코드

@Transactional
public void issueCoupon(Long couponId, RequestDto request, Member member) {
    // Redis 락
    String lockKey = "coupon:" + couponId;
    RLock lock = redissonClient.getLock(lockKey);

    try {
        // 락 획득 시도 (최대 1초 대기, 10초 유지)
        if (!lock.tryLock(1, 10, TimeUnit.SECONDS)) {
            throw new IllegalStateException("동시에 너무 많은 요청이 발생했습니다. 잠시 후 다시 시도해주세요.");
        }

        Coupon coupon = couponRepository.findById(couponId)
            .orElseThrow(() -> new GlobalException(COUPON_NOT_FOUND));

        if (issuanceRepository.findByMemberIdAndCouponId(member.getId(), couponId).isPresent()) {
            throw new GlobalException(COUPON_ALREADY_ISSUED);
        }

        coupon.validateQuantity();
        coupon.decreaseQuantity();

        Issuance issuance = Issuance.builder()
            .member(member)
            .coupon(coupon)
            .build();
        issuanceRepository.save(issuance);
    } catch (InterruptedException e) {
        throw new IllegalArgumentException("Redis 락을 획득하는데 실패했습니다.", e);
    } finally {
        TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
            @Override
            public void afterCompletion(int status) {
                if (lock.isHeldByCurrentThread()) {
                    lock.unlock();
                }
            }
        });
    }
}

문제점

1. 동시성 제어: RLock으로 처리되어 문제없음.
2. 요청 순서 처리 실패: 동시에 여러 요청이 들어왔을 때, 요청 순서대로 처리되지 않음.

2. 요청 순서 처리 시도

2.1 Redis Queue를 활용한 요청 순서 처리

• 아이디어: Redis List 자료구조에 요청을 순차적으로 추가하고, 본인의 순서가 되면 실행.
• 코드:

  String queueKey = "coupon:queue:" + couponId;
  redisTemplate.opsForList().rightPush(queueKey, threadId);
  

while (true) { String currentThreadId = redisTemplate.opsForList().index(queueKey, 0); if (threadId.equals(currentThreadId)) { break; } Thread.sleep(50); // 자신의 순서가 아닐 경우 대기 }

- **문제점**:
  - 요청 간 간격이 매우 짧을 경우 **동시에 여러 요청이 추가**되어 순서 꼬임.
  - Redis 외부에서의 동시성 문제로 인해 요청 간 지연 발생.

#### 2.2 Lua Script를 활용한 요청 순서 확인
- **아이디어**: Redis Lua Script를 활용해 현재 큐의 첫 번째 요청인지 확인.
- **코드**:
```java
String luaScript = """
    local sortedSetKey = KEYS[1]
    local memberId = ARGV[1]
    local timestamp = ARGV[2]

    redis.call('ZADD', sortedSetKey, timestamp, memberId)
    local minMember = redis.call('ZRANGE', sortedSetKey, 0, 0)[1]

    if minMember == memberId then
        return true
    else
        return false
    end
""";

Boolean isEligible = redisTemplate.execute(
    script,
    Collections.singletonList(sortedSetKey),
    String.valueOf(member.getId()), String.valueOf(uniqueTimestamp)
);

• 문제점:
  • Lua Script는 Redis 서버에서 원자적으로 실행되지만, Redis 외부의 동시성 문제를 해결하지 못함.
  • 요청의 timestamp가 거의 동일하거나 충돌할 경우, 요청 순서가 어긋남.

2.3 Redis Sorted Set을 활용한 요청 순서 처리

• 아이디어: Redis Sorted Set에 요청을 추가하고, 최소 점수를 가진 요청만 실행.
• 문제점:
  • System.nanoTime() 기반 timestamp 값이 충돌할 가능성 있음.
  • Redis Sorted Set은 점수가 동일할 경우 memberId의 사전순 정렬을 따르므로, 예상과 다른 순서로 실행.

3. 요청 순서 처리 실패 원인 분석

3.1 Redis와 Lua Script의 한계

• Redis는 매우 빠른 속도를 제공하지만, 외부의 동시성 문제를 제어하지 못함.
• Lua Script가 Redis 서버 내에서 원자적으로 실행되더라도, 응답 간 시간 차로 인해 외부 요청의 순서가 엉킬 수 있음.

3.2 점수 충돌로 인한 정렬 실패

• Redis Sorted Set에서 점수가 동일할 경우, memberId를 기준으로 사전순 정렬이 수행됨.
• System.nanoTime() 값을 사용해 점수를 생성했지만, 요청 간 간격이 매우 짧아 충돌 발생.

3.3 현실적인 요청 간 간격 문제

• 테스트 환경에서는 Thread.sleep(20)으로 간격을 강제 조정해 요청 순서를 처리했으나, 이는 실제 서비스 환경에서 비현실적.

4. 최종 결론: 거의 동시에 들어오는 요청에 대한 순서 처리 포기

1. 이유

• Redis의 기본 데이터 구조와 Lua Script를 활용해 여러 시도를 했지만, 거의 동시에 들어오는 요청의 순서 보장은 현실적으로 어렵다는 결론에 도달.
• 요청 간 간격이 거의 없어 점수 충돌과 정렬 문제가 발생.

2. 현실적인 해결책
   • 테스트에서 요청 간에 약간의 시간 간격(Thread.sleep(20);, 약 0.02초)을 두니 요청 순서가 보장되었음.
   • 따라서 0.02초 이상의 간격을 두고 요청이 들어오는 경우, 요청 순서대로 처리가 되는 것을 확인.

5. 테스트 코드

@Test
@DisplayName("Redis 락 동시성 제어 & 요청 순서 처리 테스트")
void redisLockConcurrencyTest() throws InterruptedException {
    for (int i = 0; i < threadCount; i++) {
        int threadId = i;
        Thread.sleep(20); // 20ms 간격
        executorService.submit(() -> {
            try {
                System.out.println("Thread 시작: " + Thread.currentThread().getId());
                Member threadMember = new Member("Test User" + threadId, "test" + threadId + "@example.com",
                    "password", MemberRole.USER);
                memberRepository.save(threadMember);
                couponService.issueCoupon(coupon.getId(), new RequestDto(threadMember.getId()), threadMember);
            } catch (GlobalException e) {
                System.out.println("Thread 예외: " + Thread.currentThread().getId() + ", " + e.getMessage());
            } finally {
                latch.countDown();
                System.out.println("Thread 완료: " + Thread.currentThread().getId());
            }
        });
    }

    latch.await();

    // 결과 검증
    Coupon updatedCoupon = couponRepository.findById(coupon.getId()).orElseThrow();
    System.out.println("남은 쿠폰 수량: " + updatedCoupon.getQuantity());
    System.out.println("발급된 쿠폰 수량: " + issuanceRepository.count());

    assertEquals(0, updatedCoupon.getQuantity());
    assertEquals(100, issuanceRepository.count());
}

테스트 결과

요청 순서 처리 실패 (거의 동시에 요청)

0.02초 간격 추가 후 요청 순서 처리 성공

향후 개선 방향

1. 메시지 큐 도입:
   • 요청 순서가 중요한 경우 Kafka나 RabbitMQ 같은 메시지 큐를 고려.
2. Redis 활용의 한계 인식:
   • Redis는 주로 간단한 동시성 제어 및 캐싱에 적합하며, 복잡한 요청 순서 처리는 별도의 도구로 해결 필요.

다음 포스트에서 FairLock을 사용하여 간단하게 순서가 보장하는 것을 성공 https://velog.io/@happy_code/FairLock%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%9C-%EC%88%9C%EC%84%9C-%EB%B3%B4%EC%9E%A5-%ED%99%95%EC%9D%B8

• 테스트 도구: nGrinder
• 테스트 스크립트: 로그인 후 쿠폰 발급 API 호출 (동일한 API 테스트)
• Vuser 수: 99명 → 99명의 가상 사용자가 동시에 부하를 발생시킴
• Processes/Threads: 3 프로세스, 각 프로세스당 33 쓰레드
• Duration: 1분 → 테스트는 1분간 진행
• Ramp-Up: 비활성화 (즉시 99명의 사용자 부하 발생)
• 테스트 조건:
  • 비관적 락: 데이터베이스 수준에서 락 관리
  • 레디스 락: RedissonClient를 이용한 분산 락 관리
  • 낙관적 락: @Retryable을 활용하여 낙관적 락 충돌 시 재시도

2. 결과 비교

3. 성능 분석

비관적 락

• TPS: 90.5
• Mean Test Time: 1,089.81 ms

비관적 락은 데이터베이스 수준에서 자원에 대한 락을 독점하기 때문에 경합이 심해질수록 대기 시간이 길어지고, 동시 요청을 처리하는 데 병목이 발생.

• 약 5,000건의 요청만 성공적으로 처리되었으며, 초당 처리량이 90~117 TPS로 제한.

주요 원인:

• 락을 획득한 트랜잭션이 완료될 때까지 다른 쓰레드가 대기해야 함.

레디스 락

• TPS: 3,938.0
• Mean Test Time: 22.95 ms

레디스 락은 Redis의 분산 락 기능을 활용하여 더 빠르게 락을 관리하고 해제. 트랜잭션 부담이 줄어들어 더 많은 동시 요청을 효율적으로 처리.

• 약 214,969건의 요청을 처리하였으며, 초당 처리량은 3,938 TPS에 달한다.

주요 원인:

• 레디스 락은 락의 획득/해제가 비동기적이고 빠르게 이루어지며, 데이터베이스에 직접 락을 걸지 않음.

낙관적 락

• TPS: 94.8
• Mean Test Time: 1,043.60 ms

낙관적 락은 트랜잭션 시작 시에는 락을 걸지 않고, 커밋 단계에서만 충돌을 감지. 충돌 발생 시 @Retryable을 활용해 재시도 로직을 처리.

• 초당 처리량은 약 94.8 TPS로 비관적 락과 유사하나, 평균 응답 시간이 소폭 개선됨.

재시도 관련 데이터:

• 최대 재시도 횟수: 62회

주요 원인:

• 데이터베이스에 락을 걸지 않고도 충돌을 효율적으로 처리.
• 하지만 충돌이 잦을 경우 재시도 로직으로 인해 TPS가 제한적.

4. 결론

• 레디스 락은 비관적 락과 낙관적 락 대비 성능이 월등히 우수합니다.
• 특히 TPS와 평균 응답 시간에서 큰 차이를 보이며, 동시 요청이 많은 환경에서 레디스 락이 훨씬 더 적합.
• 낙관적 락은 비관적 락과 유사한 성능을 보이지만, 재시도 로직으로 인해 시스템 자원 사용량이 다소 증가할 수 있음.

비관적 락은 데이터 무결성이 절대적으로 중요한 시스템에 적합. | 레디스 락은 동시성이 중요한 대규모 시스템에서 성능 병목을 해소하는 데 효과적. ✅ 낙관적 락은 경합이 적은 환경에서 데이터 처리 성능을 높이는 데 유리. |

낙관적 락(Optimistic Lock)을 적용하여 동시성 제어를 시도했지만, 버전 충돌이 발생했을 때 재시도 로직이 제대로 작동하지 않음. 재시도가 실행되어야 하는 상황에서 기타 예외가 발생하며 스레드가 종료되는 현상을 겪음.

이슈 발견 및 원인 분석

1. 기타 예외 로그 분석
   로그에 출력된 메시지:

   기타 예외 발생: Row was updated or deleted by another transaction

   이 로그를 보고 처음에는 낙관적 락이 제대로 작동하지 않는 것으로 판단. 그러나 실제로는 버전 충돌(Exception)이 잘못 감지되고 있었음.

2. Exception 감지 문제
   버전 충돌(Exception)은 OptimisticEntityLockException으로 감지될 것으로 예상했으나, 실제로는 ObjectOptimisticLockingFailureException로 발생하는 것을 확인. 따라서 잘못된 예외를 처리하려다 보니 재시도 로직이 실행되지 않고 종료된 것이 문제의 원인이었음.

해결 과정

1. 올바른 예외 처리 적용

   • 낙관적 락에서 발생하는 ObjectOptimisticLockingFailureException을 감지하도록 예외 처리 로직을 수정.

2. 재시도 로직 구현

   • 재시도를 수동으로 처리하는 while 루프 대신, Spring의 @Retryable 어노테이션을 활용.
   • @Retryable은 지정된 예외가 발생했을 때, 자동으로 재시도하도록 설정할 수 있음.
   • 재시도 횟수를 넉넉하게 설정(예: 100회)하여 높은 동시성 환경에서도 충분히 처리 가능하도록 조정.

3. 최종 코드

   @Transactional
   @Retryable(
       value = {ObjectOptimisticLockingFailureException.class},
       maxAttempts = 100,
       backoff = @Backoff(delay = 50) // 50ms 간격으로 재시도
   )
   public void issueCoupon(Long couponId, RequestDto request, Member member) {
       System.out.println("재시도 횟수: " + RetrySynchronizationManager.getContext().getRetryCount());
   
       // 디비 단에서 낙관적 락 적용
       Coupon coupon = couponRepository.findByIdWithOptimisticLock(couponId)
           .orElseThrow(() -> new GlobalException(COUPON_NOT_FOUND));
   
       if (issuanceRepository.findByMemberIdAndCouponId(member.getId(), couponId).isPresent()) {
           throw new GlobalException(COUPON_ALREADY_ISSUED);
       }
   
       coupon.validateQuantity();
       coupon.decreaseQuantity();
   
       // 버전 업데이트
       couponRepository.saveAndFlush(coupon);
   
       Issuance issuance = Issuance.builder()
           .member(member)
           .coupon(coupon)
           .build();
       issuanceRepository.save(issuance);
   
       System.out.println("쿠폰 발급 성공. 쿠폰 버전: " + coupon.getVersion());
   }

4. 테스트 코드 개선 재시도 횟수 확인과 동시성 제어 테스트를 위해 로그와 테스트 환경을 조정:

   @Test
   @DisplayName("낙관적 락 동시성 제어 테스트")
   void optimisticLockConcurrencyTest() throws InterruptedException {
       for (int i = 0; i < threadCount; i++) {
           int threadId = i;
           executorService.submit(() -> {
               try {
                   System.out.println("Thread 시작: " + threadId);
                   Member threadMember = new Member("Test User" + threadId, "test" + threadId + "@example.com", "password", MemberRole.USER);
                   memberRepository.save(threadMember);
   
                   couponService.issueCoupon(coupon.getId(), new RequestDto(threadMember.getId()), threadMember);
               } catch (Exception e) {
                   System.out.println("Thread 예외: " + threadId + ", " + e.getMessage());
               } finally {
                   latch.countDown();
                   System.out.println("Thread 완료: " + threadId);
               }
           });
       }
   
       latch.await();
   
       // 결과 검증
       Coupon updatedCoupon = couponRepository.findById(coupon.getId()).orElseThrow();
       System.out.println("남은 쿠폰 수량: " + updatedCoupon.getQuantity());
       System.out.println("발급된 쿠폰 수량: " + issuanceRepository.count());
   }

결과

• 동시성 제어 성공
  재시도 로직이 제대로 동작하면서 낙관적 락을 통한 데이터 정합성이 보장됨.
• 재시도 횟수 확인
  테스트 결과 재시도 횟수는 많게는 19번까지 발생했으며, 설정된 최대 재시도 횟수 내에서 처리 성공.

느낀 점

• Spring의 @Retryable을 활용하면 수동적인 재시도 로직보다 간결하고 효과적으로 동시성 문제를 해결할 수 있음.
• Exception 타입의 정확한 확인이 문제 해결의 열쇠였음. 추후 Exception 발생 시 로그를 꼼꼼히 살펴보고 문제를 정확히 정의하는 습관을 가져야겠다고 느꼈음.

1. 테스트 환경

• 테스트 도구: nGrinder
• 테스트 스크립트: 로그인 후 쿠폰 발급 API 호출 (동일한 API 테스트)
• Vuser 수: 99명 → 99명의 가상 사용자가 동시에 부하를 발생시킴
• Processes/Threads: 3 프로세스, 각 프로세스당 33 쓰레드
• Duration: 1분 → 테스트는 1분간 진행
• Ramp-Up: 비활성화 (즉시 99명의 사용자 부하 발생)
• 테스트 조건:
  • 비관적 락: 데이터베이스 수준에서 락 관리
  • 레디스 락: RedissonClient를 이용한 분산 락 관리

2. 결과 비교

3. 성능 분석

비관적 락

• TPS: 90.5
• Mean Test Time: 1,089.81 ms

비관적 락은 데이터베이스 수준에서 자원에 대한 락을 독점하기 때문에 경합이 심해질수록 대기 시간이 길어지고, 동시 요청을 처리하는 데 병목이 발생.

• 약 5,000건의 요청만 성공적으로 처리되었으며, 초당 처리량이 90~117 TPS로 제한.

주요 원인:

• 락을 획득한 트랜잭션이 완료될 때까지 다른 쓰레드가 대기해야 함.

레디스 락

• TPS: 3,938.0
• Mean Test Time: 22.95 ms

레디스 락은 Redis의 분산 락 기능을 활용하여 더 빠르게 락을 관리하고 해제. 트랜잭션 부담이 줄어들어 더 많은 동시 요청을 효율적으로 처리.

• 약 214,969건의 요청을 처리하였으며, 초당 처리량은 3,938 TPS에 달한다.

주요 원인:

• 레디스 락은 락의 획득/해제가 비동기적이고 빠르게 이루어지며, 데이터베이스에 직접 락을 걸지 않음.

4. 결론

• 레디스 락은 비관적 락과 비교하여 성능이 월등히 우수합니다.
• 특히 TPS와 평균 응답 시간에서 큰 차이를 보이며, 동시 요청이 많은 환경에서 레디스 락이 훨씬 더 적합.

| 결론 | 비관적 락은 데이터 무결성이 절대적으로 중요한 시스템에 적합하지만, 성능 병목이 발생할 수 있다. | | 레디스 락은 동시성이 중요한 대규모 시스템에서 성능 병목을 해소하는 데 효과적. ✅ |

5. 제언

• 대규모 동시 요청을 처리해야 하는 시스템에서는 레디스 락을 사용하는 것이 권장.
• 데이터 무결성이 절대적으로 필요하고 경합이 적은 시스템에서는 비관적 락을 사용할 수 있다.

쿠폰 발급 기능에서 Redisson RedLock을 활용해 동시성 제어를 구현했다. 락 해제 시 중복 해제를 방지하기 위해 isHeldByCurrentThread()를 사용했지만, RedissonMultiLock에서 UnsupportedOperationException 예외가 발생했다.

2. 원인 분석

1. RedissonMultiLock 특성

   • RedissonMultiLock은 여러 노드에 대한 락을 조합하여 사용하는 RedLock 구현체이다.
   • 개별 노드의 락을 관리하므로 단일 노드의 상태를 검사하는 isHeldByCurrentThread() 메서드를 지원하지 않는다.

2. isHeldByCurrentThread() 호출 시 문제

   • isHeldByCurrentThread()는 RedissonLock에는 존재하지만, RedissonMultiLock에서는 지원되지 않는다.
   • 이를 호출할 경우 UnsupportedOperationException 예외가 발생한다.

발생한 코드

if (redLock.isHeldByCurrentThread()) { 
    redLock.unlock();
}

예외 로그

java.lang.UnsupportedOperationException: null  
    at org.redisson.RedissonMultiLock.isHeldByCurrentThread(RedissonMultiLock.java:490)

3. 해결 방법

핵심 전략: RedissonMultiLock에서는 isHeldByCurrentThread()를 사용하지 말고, 트랜잭션 종료 시점에 unlock()만 호출하도록 한다.

최종 코드

TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
    @Override
    public void afterCompletion(int status) {
        try {
            redLock.unlock(); // 바로 unlock 호출
            System.out.println("Thread " + Thread.currentThread().getId() + " released lock.");
        } catch (IllegalMonitorStateException e) {
            System.out.println("Lock already released or not held by thread.");
        } catch (Exception e) {
            System.err.println("Unexpected exception during lock release: " + e.getMessage());
        }
    }
});

포인트:

• isHeldByCurrentThread() 검사를 제거한다.
• unlock() 호출 시 이미 해제된 락에 대한 예외(IllegalMonitorStateException)는 명확하게 처리한다.

4. 개선된 동작

1. 불필요한 검증 제거

   • isHeldByCurrentThread() 대신 트랜잭션 종료 시점에 unlock()만 호출한다.

2. RedissonMultiLock 호환성 유지

   • RedissonMultiLock의 제한사항을 준수하면서도 안전하게 락을 해제한다.

3. 안정적인 예외 처리

   • 이미 해제된 락에 대한 unlock() 호출은 예외를 무시하도록 처리한다.

5. 학습한 점

1. RedissonMultiLock의 한계

   • isHeldByCurrentThread()는 RedissonLock 전용 메서드이며, RedissonMultiLock에서는 지원되지 않는다.

2. 중복 해제 방지 전략

   • 트랜잭션 종료 시점에만 unlock()을 호출해야 하며, 불필요한 검증 로직은 제거해야 한다.

3. 예외 처리

   • unlock() 호출 시 이미 해제된 락에 대해 IllegalMonitorStateException이 발생할 수 있으므로 이를 적절히 처리한다.

쿠폰 발급 기능에서 Redisson 락을 활용하여 동시성 문제를 해결하려고 했지만, 레이스 컨디션으로 인해 남은 쿠폰 수량과 발급된 쿠폰 수량이 불일치하는 문제가 발생했습니다.

• 증상:
  • 락이 해제된 시점에 트랜잭션이 아직 커밋되지 않아 다른 스레드가 동일한 리소스에 접근하게 됨.
  • 결과적으로 남은 쿠폰 수량은 줄지 않고, 발급된 쿠폰 수량은 중복되어 계산됨.

원인 분석

1. 트랜잭션과 락의 비동기적 해제

   • issuanceRepository.save()로 쿠폰 발급 데이터를 저장했지만, DB 트랜잭션이 커밋되지 않은 상태에서 락이 해제됨.
   • 다른 스레드가 락을 획득하여 발급 중인 데이터가 아직 반영되지 않은 쿠폰 수량을 기반으로 작업을 수행함.

2. 트랜잭션 종료와 락 해제의 타이밍 차이

   • 트랜잭션 커밋은 비즈니스 로직이 끝난 후에 발생.
   • 하지만 락은 트랜잭션 종료와 무관하게 finally 블록에서 해제됨.

해결 방법

1. 락을 트랜잭션 커밋 이후에 해제

락을 트랜잭션의 종료 후 해제하도록 구현. 이를 위해 TransactionSynchronizationManager.registerSynchronization을 사용하여 트랜잭션의 커밋 이후 이벤트를 감지.

수정된 코드

@Transactional
public void issueCoupon(Long couponId, RequestDto request, Member member) {
    String lockKey = "coupon:" + couponId;
    RLock lock = redissonClient.getLock(lockKey);

    try {
        // 락 획득
        if (!lock.tryLock(5, 10, TimeUnit.SECONDS)) {
            System.out.println("Thread " + Thread.currentThread().getId() + "락 획득 실패.");
            throw new IllegalStateException("동시에 너무 많은 요청이 발생했습니다. 잠시 후 다시 시도해주세요.");
        }
        System.out.println("Thread " + Thread.currentThread().getId() + "락 획득.");

        // 트랜잭션 종료 후 락 해제를 보장
        TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
            @Override
            public void afterCompletion(int status) {
                if (lock.isHeldByCurrentThread()) {
                    lock.unlock();
                    System.out.println("Thread " + Thread.currentThread().getId() + " released lock.");
                }
            }
        });

        // 비즈니스 로직
        Coupon coupon = couponRepository.findById(couponId)
            .orElseThrow(() -> new GlobalException(COUPON_NOT_FOUND));

        if (issuanceRepository.findByMemberIdAndCouponId(member.getId(), couponId).isPresent()) {
            throw new GlobalException(COUPON_ALREADY_ISSUED);
        }

        coupon.validateQuantity();
        coupon.decreaseQuantity();

        Issuance issuance = Issuance.builder()
            .member(member)
            .coupon(coupon)
            .build();
        issuanceRepository.save(issuance);

    } catch (InterruptedException e) {
        System.out.println("Thread " + Thread.currentThread().getId() + " was interrupted.");
        throw new IllegalArgumentException("Redis 락을 획득하는데 실패했습니다.", e);
    }
}

결과

• 테스트 시 기대 결과:
  • 남은 쿠폰 수량: 0
  • 발급된 쿠폰 수량: 100
• 동시성 문제 해결:
  • 락이 트랜잭션 종료 후에 해제되므로 DB 커밋된 데이터를 기반으로 다음 스레드가 작업을 수행함.
  • 레이스 컨디션 방지 성공.

배운 점

1. 트랜잭션과 락의 타이밍 관리:

   • 락 해제는 트랜잭션 종료 이후에 실행해야 동시성 문제를 방지할 수 있음.

2. TransactionSynchronizationManager의 활용:

   • 트랜잭션의 상태(커밋/롤백)를 감지하여, 필요한 로직을 실행할 수 있음.

• 목표: 쿠폰 발급 기능에서 동시성 제어를 테스트하기 위해 비관적 락 (Pessimistic Lock)을 적용.
• 증상:
  • 테스트 코드 실행 결과:
    • 쿠폰 수량: 100
    • 발급된 쿠폰 수량: 0
  • 동시성 문제가 해결되지 않았으며, 비관적 락이 제대로 동작하지 않음.

2️⃣ 문제 원인 분석

🔍 비관적 락과 트랜잭션의 관계

• 비관적 락은 트랜잭션 내에서만 유효합니다.
  • 락은 트랜잭션 시작 시 설정되고, 트랜잭션 종료 시 해제됩니다.
• 테스트 실행 시, @Transactional이 없는 상태에서 트랜잭션이 제대로 관리되지 않아 락이 즉시 해제되었음.
• 결과적으로, 여러 스레드가 동시에 쿠폰 수량을 감소시키려 했으나, 락이 동작하지 않아 동시성 문제가 발생.

🔍 테스트 코드의 설계 문제

• 서비스 레이어에서 트랜잭션 경계를 명확히 설정하지 않았음.
• 테스트 메서드 자체에서 트랜잭션을 사용하려고 했으나, 비관적 락은 트랜잭션 범위를 벗어나면 동작하지 않음.

3️⃣ 문제 해결

🛠️ 서비스 레이어에 @Transactional 추가

• CouponService의 issueCoupon 메서드에 트랜잭션을 적용.
  • 비관적 락의 생명 주기를 트랜잭션 경계 내로 설정하여 락이 올바르게 동작하도록 수정.

@Transactional
public void issueCoupon(Long couponId, RequestDto request, Member member) {
    Coupon coupon = couponRepository.findByIdWithPessimisticLock(couponId)
        .orElseThrow(() -> new GlobalException(COUPON_NOT_FOUND));

    if (issuanceRepository.findByMemberIdAndCouponId(member.getId(), couponId).isPresent()) {
        throw new GlobalException(COUPON_ALREADY_ISSUED);
    }

    coupon.validateQuantity();
    coupon.decreaseQuantity();

    Issuance issuance = Issuance.builder()
        .member(member)
        .coupon(coupon)
        .build();
    issuanceRepository.save(issuance);
}

🛠️ 비관적 락 적용

• CouponRepository에 비관적 락을 적용한 JPQL 작성:

  @Query("SELECT c FROM Coupon c WHERE c.id = :id FOR UPDATE")
  Optional<Coupon> findByIdWithPessimisticLock(@Param("id") Long id);

🛠️ 테스트 코드 수정

• 기존 테스트 코드에서 트랜잭션 경계를 테스트 메서드가 아닌 서비스 레이어로 이동.
• 각 스레드가 쿠폰을 발급받을 때 새로운 Member를 생성하여 동시성 문제를 재현.
• 스레드 실행 결과를 검증하도록 추가 로그 및 검증 코드 작성.

4️⃣ 결과

✅ 수정 후 테스트 결과

• 남은 쿠폰 수량: 0
• 발급된 쿠폰 수량: 100
• 비관적 락이 트랜잭션 경계 내에서 제대로 동작하여 동시성 문제가 해결됨.

✅ 로그

Thread 시작: 0
Thread 시작: 1
Thread 시작: 2
...
Thread 완료: 98
Thread 완료: 99
남은 쿠폰 수량: 0
발급된 쿠폰 수량: 100

5️⃣ 트랜잭션의 중요성

🔑 왜 트랜잭션이 중요한가?

• 비관적 락은 트랜잭션 내부에서만 유효합니다.
• 트랜잭션이 시작되지 않으면 락이 바로 해제되어 다른 스레드가 데이터에 접근.
• 스프링의 @Transactional은 트랜잭션의 경계를 명확히 설정하여 락의 생명 주기를 보장.

6️⃣ 트랜잭션 미적용 시 문제점

• 트랜잭션이 없는 경우:
  • 비관적 락이 제대로 적용되지 않아 동시성 문제가 발생.
  • 테스트 코드 실행 결과, 모든 스레드가 동시에 쿠폰을 발급하려고 시도하여 발급된 쿠폰 수량이 0으로 유지됨.
• 트랜잭션 적용 후:
  • 비관적 락이 트랜잭션 시작 시 설정되고 종료 시 해제.
  • 하나의 스레드가 쿠폰 발급 작업을 완료하기 전까지 다른 스레드는 대기.

7️⃣ 향후 개선점

1. 비관적 락과 성능 분석:

   • 비관적 락은 성능 저하(TPS 감소)를 초래할 수 있음.
   • Redis 분산 락과의 성능 비교를 통해 최적의 동시성 제어 방식 선택.

2. 테스트 시나리오 확장:

   • 대규모 사용자 환경(TPS 증가)을 가정한 테스트.
   • 실제 배포 환경과 유사한 성능 테스트 도구(nGrinder) 활용.

3. 에러 로그 및 예외 처리 개선:

   • GlobalException 외에 동시성 제어 실패 로그를 추가하여 성능 병목점 분석.

8️⃣ 최종 정리

• 비관적 락은 트랜잭션 경계 내에서만 동작하며, 트랜잭션 관리가 필수.
• 트랜잭션을 활용한 락 관리로 동시성 제어 문제를 해결할 수 있음.
• 쿠폰 발급과 같은 민감한 동시성 로직에는 락 방식과 성능의 균형을 고려한 설계가 중요.

참고 코드: 테스트 결과 확인

@Test
@DisplayName("비관적 락 동시성 제어 테스트")
void pessimisticLockConcurrencyTest() throws InterruptedException {
    for (int i = 0; i < threadCount; i++) {
        int threadId = i;
        executorService.submit(() -> {
            try {
                Member threadMember = new Member("Test User " + threadId, "test" + threadId + "@example.com", "password", MemberRole.USER);
                memberRepository.save(threadMember);
                couponService.issueCoupon(coupon.getId(), new RequestDto(threadMember.getId()), threadMember);
            } catch (GlobalException e) {
                System.out.println("Thread " + threadId + " 예외 발생: " + e.getMessage());
            } finally {
                latch.countDown();
            }
        });
    }
    latch.await();

    Coupon updatedCoupon = couponRepository.findById(coupon.getId()).orElseThrow();
    System.out.println("남은 쿠폰 수량: " + updatedCoupon.getQuantity());
    System.out.println("발급된 쿠폰 수량: " + issuanceRepository.count());
    assertEquals(0, updatedCoupon.getQuantity());
    assertEquals(100, issuanceRepository.count());
}

1️⃣ 문제 상황

쿠폰 발급 API의 동시성 문제를 확인하기 위해 다음과 같은 테스트 코드를 작성했다:

@SpringBootTest
@Transactional
public class CouponConcurrencyTest {
    @Test
    void issueCoupon_concurrencyTest() throws InterruptedException {
        int threadCount = 10;
        ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    couponService.issueCoupon(coupon.getId(), new RequestDto(member.getId()), member);
                } catch (Exception e) {
                    System.out.println("예외 발생: " + e.getMessage());
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
    }
}

테스트 실행 결과, 아래와 같은 예외가 발생하며 동작하지 않았다:

예외 발생: 해당 쿠폰을 찾을 수 없습니다.

2️⃣ 원인 분석

1. 트랜잭션 격리로 인한 데이터 접근 제한:

   • @Transactional은 트랜잭션이 종료되기 전까지 데이터 변경 사항을 해당 트랜잭션 범위 내에서만 볼 수 있다.
   • 동시성 테스트에서 다른 스레드가 데이터에 접근하려 하면, 커밋되지 않은 데이터에 접근할 수 없어 조회에 실패한다.

2. 테스트의 롤백 동작:

   • 테스트 메서드에 @Transactional을 붙이면 테스트 종료 후 데이터가 자동으로 롤백된다.
   • 롤백 동작으로 인해 데이터가 제대로 반영되지 않아 다른 스레드가 동일한 데이터를 사용할 수 없다.

3️⃣ 해결 방안

✅ 1. @Transactional 제거 및 명시적 데이터 초기화

• 테스트 메서드에서 @Transactional을 제거하고, 테스트 종료 후 명시적으로 데이터를 초기화한다.
• @AfterEach를 활용하여 데이터 정리를 진행한다:

@AfterEach
void tearDown() {
    issuanceRepository.deleteAll();
    couponRepository.deleteAll();
    memberRepository.deleteAll();
}

✅ 2. 트랜잭션 격리 수준 조정 (비권장)

• READ_UNCOMMITTED로 설정하여 다른 스레드가 커밋되지 않은 데이터를 읽을 수 있도록 허용할 수 있다:

@Transactional(isolation = Isolation.READ_UNCOMMITTED)

• 하지만 이는 Dirty Read(더티 읽기)와 같은 데이터 무결성 문제가 발생할 가능성이 있어 권장되지 않는다.

✅ 3. 동시성 테스트를 별도의 통합 테스트로 진행

• 동시성 문제를 테스트할 때는 데이터베이스와 트랜잭션 관리 없이, 독립적으로 테스트를 진행한다.
• 트랜잭션 롤백과 같은 문제를 회피하며, 동시성 시나리오를 단순화할 수 있다.

4️⃣ 적용 결과

@Transactional을 제거하고 @AfterEach로 데이터 초기화를 추가한 후, 테스트가 정상적으로 동작하며 쿠폰 발급 및 동시성 문제가 확인되었다:

남은 쿠폰 수량: 10 // 동시성 제어 문제로 중복 쿠폰 발급이 발생.
발급된 쿠폰 수량: 10

5️⃣ 배운 점

• 트랜잭션 격리와 롤백은 테스트 환경에서 예상치 못한 문제를 일으킬 수 있다.
• 동시성 테스트를 수행할 때는 트랜잭션 관리 방식을 조정하거나 제거하여 테스트 환경을 적합하게 설정해야 한다.
• 테스트 데이터 관리는 @Transactional 없이 명시적으로 관리하는 것이 동시성 테스트에 유리하다.

💭 회고

이번 경험을 통해 Spring의 @Transactional과 트랜잭션 격리 수준이 테스트 동작에 어떻게 영향을 미치는지 깊이 이해할 수 있었다. 특히 동시성 테스트는 단순히 코드를 작성하는 것만이 아니라, 테스트 환경과 트랜잭션 동작 방식에 대한 명확한 이해가 필요함을 느꼈다.

1️⃣ H2 임베디드 데이터베이스: 왜 사용할까?

H2 임베디드는 메모리 기반의 경량 데이터베이스로, 실제 데이터베이스와 유사한 환경을 제공합니다. 이를 통해 JPA나 JDBC와 같은 데이터 액세스 로직을 실제 데이터베이스에서 테스트하듯이 검증할 수 있습니다.

✅ 장점 1: 실제 데이터베이스와 유사한 환경

H2 임베디드는 실제 SQL 문법과 동작을 지원하므로, 실제 데이터베이스 환경과 유사한 조건에서 테스트를 실행할 수 있습니다.

@SpringBootTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY)
public class UserRepositoryTest {

    @Autowired
    private UserRepository userRepository;

    @Test
    public void userSaveTest() {
        // Given
        User user = new User("test@example.com", "password");

        // When
        userRepository.save(user);

        // Then
        User result = userRepository.findByEmail("test@example.com").orElseThrow();
        assertEquals("test@example.com", result.getEmail());
    }
}

위 예제는 실제 데이터베이스를 사용하는 것처럼 JPA 레포지토리 동작을 테스트합니다.
장점:

• 엔티티 매핑 오류, 쿼리 오류, 트랜잭션 문제 등 데이터베이스와 관련된 잠재적인 문제를 초기에 발견 가능.

✅ 장점 2: 통합 테스트 환경 제공

H2 임베디드는 단순히 데이터를 저장하는 것을 넘어, 애플리케이션과 데이터베이스 간의 연동을 포함한 통합 테스트를 가능하게 합니다.
이는 단순 로직 테스트를 넘어 애플리케이션 전체의 동작을 검증할 수 있는 강력한 도구가 됩니다.

2️⃣ Mockito를 사용하는 방식: 언제 유용할까?

Mockito는 주로 단위 테스트에서 레포지토리, 서비스, 컨트롤러의 특정 메서드를 모킹(mocking)하여 테스트하는 데 사용됩니다.

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    public void findUserTest() {
        // Given
        User mockUser = new User("test@example.com", "password");
        Mockito.when(userRepository.findByEmail("test@example.com")).thenReturn(Optional.of(mockUser));

        // When
        User result = userService.findUserByEmail("test@example.com");

        // Then
        assertEquals("test@example.com", result.getEmail());
    }
}

Mockito를 사용하면 특정 레포지토리 메서드의 동작을 모킹하여, 반환값을 미리 설정하고 로직을 검증할 수 있습니다.

⛔ 문제점: 실제 데이터베이스와의 불일치

Mockito는 테스트 환경에서 실제 데이터베이스와 독립적으로 동작하므로 아래와 같은 한계가 존재합니다:

1. 레포지토리 구현 검증 실패

   • 쿼리 작성 오류가 있어도 테스트가 성공할 수 있습니다.
   • 예를 들어, @Query로 작성한 JPQL이 실제 데이터베이스에서 실행되지 않을 경우, Mockito 테스트에서는 이를 검출하지 못합니다.

2. 엔티티 매핑 검증 부족

   • @Column, @OneToMany 등 데이터베이스와의 매핑이 잘못되었을 때 오류를 발견할 수 없습니다.

3. 테스트 신뢰도 저하

   • 실제 데이터베이스와의 상호작용 없이 반환값을 강제로 설정하기 때문에, 레포지토리의 동작이 실제 서비스와 일치하지 않을 가능성이 높아집니다.

3️⃣ H2 임베디드와 Mockito: 언제, 어떻게 사용할까?

H2 임베디드를 사용할 때

• JPA, JDBC 테스트: 실제 데이터베이스와의 연동을 검증해야 하는 경우.
• 쿼리 검증: JPQL이나 Native Query의 실행 가능성과 성능 검증이 필요한 경우.
• 통합 테스트: 데이터베이스와의 상호작용을 포함한 전체적인 동작 검증이 필요한 경우.

Mockito를 사용할 때

• 단위 테스트: 데이터베이스와 독립적으로 특정 메서드나 로직을 검증해야 하는 경우.
• 테스트 속도: 빠른 테스트가 필요한 경우.
• 의존성 분리: 데이터베이스와의 상호작용 없이 서비스나 컨트롤러 로직만 검증할 때.

4️⃣ H2 임베디드를 사용하는 이유

결론적으로, H2 임베디드는 데이터베이스와 연동된 애플리케이션의 테스트에서 테스트 신뢰도를 높이는 가장 적합한 도구입니다.
Mockito는 단위 테스트에서는 유용하지만, 실제 데이터베이스와 관련된 문제를 발견하는 데는 한계가 있습니다.

요약:

• H2 임베디드: 데이터베이스 연동 로직, 엔티티 매핑, 쿼리 검증 등 통합 테스트에 적합.
• Mockito: 특정 메서드나 로직을 빠르고 독립적으로 테스트할 때 적합.

테스트의 목표는 단순히 테스트 코드를 작성하는 것이 아니라, 실제로 발생할 수 있는 오류를 조기에 발견하여 프로젝트의 품질을 높이는 데 있습니다.

Cart cart = cartRepository.findByMemberIdAndMenuIdAndStoreId(member.getId(), request.menuId(), request.storeId())
                .map(existingCart -> {
                    existingCart.updateQuantity(request.quantity());
                    return existingCart;
                })
                .orElseGet(() -> Cart.builder()
                        .member(member)
                        .menu(menu)
                        .store(store)
                        .quantity(request.quantity())
                        .price(request.price())
                        .build());

이 코드는 Optional, 빌더 패턴, 람다 표현식을 활용하여 객체 조회와 생성 로직을 간결하게 처리하는 매우 유용한 예제입니다. 이 코드에서 배운 점과 주요 개념들을 정리했습니다.

2. 주요 개념

1. Optional:

   • 데이터가 있을 수도, 없을 수도 있는 상황을 처리하는 Java의 클래스.
   • map()과 orElseGet()을 사용해 조회 결과에 따라 다른 동작을 수행.

2. 빌더 패턴:

   • 객체 생성 시 복잡한 생성자를 대신해, 메서드 체이닝으로 가독성 있고 직관적인 코드 작성.

3. 람다 표현식:

   • 간결한 문법으로 코드를 줄이고 가독성을 높임.

4. 메서드 체이닝:

   • 여러 메서드를 연결해 순차적으로 작업을 처리.

3. 코드 해석

이 코드의 목적은 특정 조건에 맞는 카트를 조회하거나, 없다면 새로 생성하는 것입니다.

1) 카트 조회

cartRepository.findByMemberIdAndMenuIdAndStoreId(member.getId(), request.menuId(), request.storeId())

• cartRepository에서 특정 멤버, 메뉴, 가게 ID를 조건으로 카트를 검색.
• 반환값은 Optional:
  • 조회된 카트가 존재 → Optional 내부에 Cart 객체 포함.
  • 조회된 카트가 없음 → 비어 있는 Optional 반환.

2) 조회된 카트가 존재하는 경우 (map)

.map(existingCart -> {
    existingCart.updateQuantity(request.quantity());
    return existingCart;
})

• Optional.map()은 값이 존재할 때 실행.
• existingCart는 Optional 내부의 실제 Cart 객체.
• 동작:
  1. updateQuantity()로 카트 수량을 업데이트.
  2. 업데이트된 existingCart를 반환.

3) 조회된 카트가 없는 경우 (orElseGet)

.orElseGet(() -> Cart.builder()
        .member(member)
        .menu(menu)
        .store(store)
        .quantity(request.quantity())
        .price(request.price())
        .build());

• orElseGet()은 값이 없을 때 실행.
• Cart.builder()로 새 카트를 생성.
• 동작:
  1. 필요한 필드(member, menu, store, quantity, price)를 설정.
  2. .build() 호출로 새 Cart 객체 생성.

4. 빌더 패턴의 역할

빌더 패턴은 복잡한 객체 생성 로직을 간결하게 처리합니다. 예를 들어:

Cart.builder()
    .member(member)
    .menu(menu)
    .store(store)
    .quantity(request.quantity())
    .price(request.price())
    .build();

• 필드 설정이 명시적이고 순서에 구애받지 않아 가독성이 뛰어납니다.
• 특히, 객체가 Immutable(불변)해야 하는 경우에도 빌더 패턴이 유용합니다.

5. Optional과 빌더 패턴의 결합

• Optional은 데이터 조회 후 결과에 따라 로직을 분기 처리합니다.
• 빌더 패턴은 조건에 따라 새 객체를 유연하게 생성할 수 있습니다.
• 이 두 가지를 결합하면 조회-수정-생성 로직을 간단하게 구현할 수 있습니다.

6. 오늘의 배운 점

1. Optional 활용:

   • 조회 결과가 존재할 때는 map()으로 값 수정.
   • 조회 결과가 없을 때는 orElseGet()으로 기본값 생성.

2. 빌더 패턴 사용:

   • 복잡한 객체 생성 로직을 간단하고 명확하게 작성.
   • 선택적 필드 초기화 및 가독성 높은 코드 작성 가능.

3. 람다 표현식과 메서드 체이닝:

   • 간결한 코드 작성과 가독성 향상.

7. 실전에서의 활용

1. 상태 기반 객체 처리:

   • 조회된 데이터가 존재하면 수정하고, 없으면 생성.
   • 상태 전환 로직을 Optional과 빌더로 쉽게 구현.

2. Immutable 객체 생성:

   • 빌더 패턴은 객체를 불변하게 설계하는 데 유리.

3. 코드 간소화:

   • 람다 표현식과 빌더 패턴을 활용해 코드 중복 최소화.

8. 앞으로의 적용

• 복잡한 객체 생성 시 빌더 패턴을 적극 활용: 특히, 생성자 매개변수가 많거나 선택적 필드가 많을 때.
• 조회-수정-생성 로직에 Optional 사용: 데이터 상태에 따라 유연하게 처리.
• 코드 가독성을 높이는 방법을 고민하며, 메서드 체이닝과 람다 표현식 활용을 늘려야겠다.

허용 가능한 중복은 도메인별 요구사항이나 특수성 때문에 모듈 간 유사한 코드가 반복되지만, 이를 완전히 제거하지 않고 설계의 유연성을 위해 일부 중복을 허용하는 접근 방식이다.

2. 왜 중복이 발생할까?

1. 도메인별 요구사항의 차이

   • 각 API(User, Boss, Admin)의 비즈니스 로직이 다름.
   • 예: User API는 간단한 검증, Admin API는 복잡한 인증과 권한 확인.

2. 모듈의 독립성 유지

   • 모든 로직을 Core에 몰아넣으면 과도한 의존성으로 수정 시 영향 범위가 커짐.
   • 각 API는 독립적으로 동작해야 함.

3. 중복 제거의 비용

   • 중복을 완전히 제거하려 하면 복잡한 추상화로 인해 코드 가독성과 유지보수성이 저하될 수 있음.

3. 허용 가능한 중복의 예시

1) 데이터 검증

• User API는 간단한 이메일/비밀번호 검증.
• Admin API는 관리자 전용 키와 권한 검증 추가.
  → 공통 부분은 재사용하되, 도메인별 검증은 각 모듈에서 구현.

2) 응답 포맷

• 공통 응답 포맷(ApiResponse)은 Core에서 제공.
• 도메인별 데이터 구조나 메시지 차이는 API 모듈에서 처리.

4. 중복 제거와 허용 중복의 균형

1. 중복 제거

   • 공통 로직(예: 예외 처리, 공통 응답 포맷 등)은 Core 모듈에 배치.

2. 허용 중복

   • 도메인별 요구사항이 다른 경우 각 API 모듈에서 구현.
   • 필요 이상의 일반화는 피하고, 특화 로직은 분리.

5. 결론

모든 중복을 제거하려는 시도는 설계를 복잡하게 만들 수 있다.
공통 로직은 Core에서 관리하되, 도메인별 요구사항은 API 모듈에서 처리하도록 설계 균형을 맞추는 것이 중요하다.
필요한 중복은 프로젝트의 유연성과 유지보수성을 보장하는 데 기여할 수 있다.

1.1. Gradle 멀티 모듈 프로젝트 생성

1. 루트 프로젝트 생성:

   • Gradle 기반의 프로젝트를 생성한다.
   • 프로젝트 이름은 팀 프로젝트 이름에 맞게 설정한다.

2. Gradle 설정 파일 생성:

   • settings.gradle 파일에서 멀티 모듈을 정의한다.
   • 하위 모듈의 경로를 지정.

settings.gradle 예시:

rootProject.name = 'waiting-system'

include 'libs:core'
include 'libs:database'
include 'libs:s3-client'
include 'libs:queue-client'
include 'api:user-api'
include 'api:boss-api'
include 'api:admin-api'

3. 디렉토리 구조 생성:
   • libs/와 api/ 디렉토리를 만들고, 각각 모듈 디렉토리를 생성한다.

최종 디렉토리 구조:

waiting-system/
├── build.gradle
├── settings.gradle
├── libs/
│   ├── core/
│   ├── database/
│   ├── s3-client/
│   └── queue-client/
└── api/
    ├── user-api/
    ├── boss-api/
    └── admin-api/

2. 각 모듈별 초기화

2.1. Core 모듈 초기화

1. libs/core 디렉토리로 이동:

   • Gradle 초기화 명령 실행 (gradle init).

2. build.gradle 파일 작성:

   • Core 모듈에 필요한 의존성(Spring Web, Validation 등)을 추가.

libs/core/build.gradle:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-validation'
}

2.2. Database 모듈 초기화

1. libs/database 디렉토리로 이동:

   • Gradle 초기화 명령 실행.

2. build.gradle 파일 작성:

   • JPA 및 Core 모듈 의존성을 추가.

libs/database/build.gradle:

dependencies {
    implementation project(':libs:core') // Core 모듈 의존
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
}

2.3. S3-Client 모듈 초기화

1. libs/s3-client 디렉토리로 이동:

   • Gradle 초기화 명령 실행.

2. build.gradle 파일 작성:

   • Core 모듈과 S3 관련 의존성을 추가.

libs/s3-client/build.gradle:

dependencies {
    implementation project(':libs:core')
    implementation 'com.amazonaws:aws-java-sdk-s3'
}

2.4. Queue-Client 모듈 초기화

1. libs/queue-client 디렉토리로 이동:

   • Gradle 초기화 명령 실행.

2. build.gradle 파일 작성:

   • Core 모듈과 메시지 큐 관련 의존성을 추가.

libs/queue-client/build.gradle:

dependencies {
    implementation project(':libs:core')
    implementation 'org.springframework.boot:spring-boot-starter-amqp' // RabbitMQ 예시
}

2.5. API 모듈 초기화 (User, Boss, Admin)

1. 각 API 모듈 디렉토리 초기화:

   • api/user-api, api/boss-api, api/admin-api 각각 초기화.

2. build.gradle 파일 작성:

   • Core 모듈과 필요한 라이브러리 의존성을 추가.

api/user-api/build.gradle:

dependencies {
    implementation project(':libs:core') // 공통 기능
    implementation project(':libs:database') // 데이터베이스
    implementation project(':libs:s3-client') // 파일 저장
    implementation project(':libs:queue-client') // 메시지 큐
}

3. 공통 빌드 설정

3.1. 루트 프로젝트 build.gradle 설정

1. 공통 의존성 버전 관리:
   • build.gradle에서 플러그인 및 공통 의존성 버전을 설정.

build.gradle:

plugins {
    id 'org.springframework.boot' version '3.1.0' apply false
    id 'io.spring.dependency-management' version '1.1.3' apply false
    id 'java'
}

allprojects {
    group = 'com.example'
    version = '1.0.0'

    repositories {
        mavenCentral()
    }
}

subprojects {
    apply plugin: 'java'
    apply plugin: 'io.spring.dependency-management'

    dependencies {
        testImplementation 'org.springframework.boot:spring-boot-starter-test'
    }
}

4. 프로젝트 초기 테스트

1. Gradle 빌드 확인:

   • 최상위 디렉토리에서 ./gradlew build를 실행해 빌드가 정상적으로 작동하는지 확인.

2. 모듈 간 의존성 확인:

   • 각 모듈에서 ./gradlew dependencies를 실행해 의존성이 제대로 연결되었는지 점검.

3. Spring Boot 애플리케이션 실행:

   • API 모듈 중 하나(예: user-api)에 @SpringBootApplication을 추가해 애플리케이션이 정상적으로 실행되는지 확인.

5. 초기 설계의 유의점

1. 모듈 경량화:

   • 각 모듈은 역할에 맞는 기능만 포함해야 하며, 필요 이상으로 의존성을 추가하지 않는다.

2. 의존성 주의:

   • Core 모듈에서만 Spring Web을 의존하도록 설정하고, 다른 모듈에서 직접 사용하지 않도록 제한.

3. 테스트 전략 수립:

   • Core, Database, API 모듈 각각의 단위 테스트와 통합 테스트를 별도로 작성한다.

4. 유지보수 고려:

   • 라이브러리(S3, Queue 등)는 API 모듈에서 직접 구현하지 않고, 공통 모듈을 활용해 재사용성을 높인다.