멀티스레딩?, 비동기?

멀티스레딩

그림에 왼쪽은 싱글스레드, 오른쪽은 멀티스레드이다.

비동기

참고 자료

• https://technote-mezza.tistory.com/69

WAS(Web Application Server)는 HTTP 프로토콜을 기반으로 사용자의 요청을 받아 서버에서 애플리케이션을 실행하고, 그 결과를 HTTP 응답으로 반환하는 미들웨어(Middleware)이다.

단순히 저장된 파일을 전달하는 것을 넘어, 요청에 따라 서버 내부 로직을 수행하고 데이터를 가공하여 동적 콘텐츠를 생성하며, 나아가 웹 애플리케이션이 안정적으로 실행될 수 있도록 실행 환경(Runtime Environment)을 제공하는 것이 핵심 역할이다.

note) 실무적으로 WAS는 Java의 Tomcat처럼 코드가 실행될 수 있는 환경을 제공하며, DB 접근, 트랜잭션 관리, 스레드 관리 등 백엔드의 복잡한 책임을 대신 처리해 주는 서버를 의미한다.

WAS 탄생 배경

초기 웹 서버는 미리 만들어진 HTML 파일을 클라이언트에 전달하는 역할만 수행했다. 하지만 웹 서비스가 발전하면서 다음과 같은 한계에 직면했다.

• 동적 데이터의 필요성 로그인 사용자마다 다른 화면 제공, 실시간 데이터 반영
• 비즈니스 로직 처리 요구 결제, 재고 관리, 권한 판단 같은 서버 측 연산 필요
• 자원 활용의 효율성 문제 요청마다 프로세스를 생성하는 방식은 비용이 과도했음

이러한 문제를 해결하기 위해 스레드 기반으로 요청을 처리하고, 애플리케이션 실행을 전담하는 서버인 WAS가 등장했다.

👉 이 구조 덕분에 서버는 다수의 요청을 효율적으로 처리하면서도 복잡한 비즈니스 로직을 안정적으로 실행할 수 있게 되었다.

WAS vs Web Server

Tip) 현대 아키텍처에서는 보안과 트래픽 분산을 위해 Web Server를 앞단에 두고, WAS를 수평 확장하는 구조가 일반적으로 사용된다.

WAS가 하는 일

1. 프로그램 실행 환경 제공 Spring과 같은 프레임워크가 동작할 수 있는 서블릿 컨테이너 제공
2. 스레드 관리 (Thread Management) Thread Pool을 통해 동시 요청을 안정적으로 처리
3. DB 커넥션 풀(DBCP) 관리 DB 연결 비용을 줄이고 성능을 최적화
4. 트랜잭션 관리 작업 단위의 일관성 보장
5. 보안 및 세션 관리 인증·인가, HttpSession 기반 사용자 상태 관리

👉 이 모든 기능은 개발자가 비즈니스 로직에만 집중할 수 있도록 돕기 위한 것이다.

요청 흐름

1. Web Server 수신: 클라이언트 요청이 들어오면 Web Server가 정적/동적 요청인지 판단해.
2. WAS 위임 (Tomcat): 동적 요청일 경우 WAS(Tomcat)로 넘겨. 이때 Tomcat은 요청을 처리할 스레드를 할당
3. DispatcherServlet 동작: Spring의 총지배인인 DispatcherServlet이 요청을 받아 어떤 컨트롤러가 처리할지 결정해.
4. 비즈니스 로직 실행 (Service): 실제 핵심 로직이 담긴 Service 레이어에서 연산이 수행
5. DB 연동 (JPA/Repository): JPA를 통해 DB에서 데이터를 가져오거나 저장
6. 응답 반환: 가공된 데이터를 다시 DispatcherServlet -> Tomcat -> Web Server를 거쳐 클라이언트에게 HTTP 응답으로 전달

이 과정에서 개발자는 비즈니스 로직에만 집중할 수 있고, 스레드 관리와 자원 관리는 WAS가 대신 책임진다.

WAS와 Thread Per Request Model

Thread Per Request Model이란?

Thread Per Request Model은 하나의 HTTP 요청을 하나의 스레드가 전담하여 처리하는 방식이다.

• 요청 1개 → 스레드 1개 할당
• 요청 처리 완료 → 스레드 반환

전통적인 WAS(Tomcat, Jetty)는 이 모델을 기본 동시성 처리 방식으로 사용한다.

WAS 내부 동작 흐름 (Tomcat 기준)

1. 클라이언트 요청 수신
2. Web Server가 동적 요청을 WAS로 전달
3. Tomcat Connector가 Thread Pool에서 스레드 할당
4. DispatcherServlet 실행
5. Controller → Service → Repository 순으로 로직 수행
6. 응답 생성 후 스레드 반환

이 과정에서 요청의 시작부터 끝까지 동일한 스레드가 사용된다.

Thread Per Request Model의 한계

• Blocking I/O 문제 DB나 외부 API 응답을 기다리는 동안 스레드는 대기 상태
• 동시성 확장의 한계 동시 요청 수 증가 = 스레드 증가 → 메모리 및 컨텍스트 스위칭 비용 증가

👉 트래픽이 급증하면 Thread Pool 고갈로 장애가 발생할 수 있다.

한계를 해결한 방법

기능	역할
Thread Pool	스레드 수 제한 및 재사용
Queue	초과 요청 대기
Timeout	비정상 요청 종료
DBCP	DB 대기 시간 단축
트랜잭션 관리	스레드 단위 작업 일관성

참고 자료

• https://mark-kim.blog/server_performance_tpr_thread_state/
• https://www.youtube.com/watch?v=NyhbNtOq0Bc
• https://helloworld-88.tistory.com/71
• https://velog.io/@developerjun0615/WEB-WAS-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

Heap 영역에서 동적으로 할당된 객체 중 더 이상 참조되지 않는 메모리(garbage)를
JVM이 자동으로 탐지하여 제거하는 프로세스이다.

C/C++처럼 개발자가 직접 메모리를 해제하지 않아도 되므로
메모리 관리 부담을 줄일 수 있지만,
GC 역시 비용이 존재하기 때문에 동작 원리를 이해하는 것이 중요하다.

GC 기본 동작 개념

GC는 모든 객체를 무작위로 삭제하지 않는다.
GC Root에서 시작해 참조 관계를 따라가며 “살아있는 객체”를 판단한다.

※ 실제 GC 동작은 GC 알고리즘에 따라 다르며,
Young Generation은 Copy 방식, Old Generation은 Mark-Sweep(-Compact) 방식이 주로 사용된다.

GC 공통 동작 순서 (개념적 흐름)

1. Stop-The-World (STW)
   GC를 수행하기 위해 GC 스레드를 제외한 모든 애플리케이션 스레드를 일시 중단한다.
   STW 시간이 길어질수록 서비스 지연(Latency)이 증가한다.

2. Mark
   GC Root(Stack의 지역 변수, Method Area의 static 변수, JNI 참조 등)에서 시작해
   참조 가능한 객체를 탐색하고 Reachable로 표시한다.

3. Sweep
   Mark되지 않은(Unreachable) 객체를 제거한다.
   ※ Young GC에서는 개별 Sweep 대신 Copy 방식이 사용된다.

4. Compact (GC 알고리즘에 따라 수행)
   살아남은 객체를 한쪽으로 이동시켜 메모리 파편화(Fragmentation)를 제거하고
   연속된 메모리 공간을 확보한다.

JVM Heap 메모리 영역

New / Young Generation

새롭게 생성된 객체가 할당되며, 생명 주기가 짧은 객체가 주로 머무는 영역이다.

• Eden
  new 키워드로 생성된 객체가 최초로 할당되는 영역
  → Bump-the-pointer 방식으로 빠른 객체 할당이 가능하다.

• Survivor (From / To)
  Minor GC에서 살아남은 객체가 이동하는 영역
  두 영역 중 하나는 항상 비어 있으며,
  GC마다 살아남은 객체를 다른 쪽으로 복사(Copy)한다.

• 관련 옵션
  -XX:NewSize, -XX:MaxNewSize

• 성능 포인트
  Young 영역이 너무 작으면 객체가 빠르게 Old 영역으로 Promotion되어
  Major GC 부하가 증가할 수 있다. (Premature Promotion)

Old Generation (Tenured Generation)

Young Generation에서 여러 번의 GC를 거쳐 살아남은 장수 객체가 저장되는 영역이다.

• Tenured
  Survivor 영역에서 age 임계값(기본 15)을 초과한 객체가 Promotion 되어 이동한다.

• 특징

  • 객체 생존율이 높음
  • GC 비용이 큼
  • STW 시간이 길어 성능에 직접적인 영향

• 관련 옵션
  -Xms, -Xmx (Young 영역을 제외한 나머지)

• 성능 포인트
  Old 영역이 가득 차면 Major GC 또는 Full GC가 발생한다.
  Heap이 큰 환경일수록 STW 시간을 줄이는 것이 핵심 튜닝 포인트이다.

Metaspace (Native Area)

Java 8부터 도입된 영역으로, JVM이 로드한 클래스 메타데이터를 저장한다.

• PermGen vs Metaspace

  • PermGen: Heap 영역 (Java 7 이하)
  • Metaspace: Native Memory 사용 (Java 8+)

• 특징

  • OS 메모리를 사용하여 PermGen 시절보다 OOM 발생 빈도 감소
  • 무한하지 않으며 설정에 따라 OutOfMemoryError: Metaspace 발생 가능

• 관련 옵션 -XX:MetaspaceSize, -XX:MaxMetaspaceSize

자세한 GC 동작 순서

GC는 Heap 전체를 한 번에 정리하지 않고,
Young Generation 중심의 Minor GC와 Old Generation 중심의 Major / Full GC로 나뉘어 수행된다.

대부분의 GC는 Minor GC이며,
Major GC는 발생 빈도는 낮지만 비용이 크다.

객체 생성

애플리케이션에서 객체를 생성하면 Eden 영역에 할당된다.
Eden은 연속된 메모리 구조를 사용하여 빠른 할당이 가능하다.

→ Eden이 가득 차면 Minor GC가 트리거된다.

Minor GC (Young Generation GC)

Young Generation(Eden + Survivor)만을 대상으로 수행된다.

📌 Minor GC 특징

1. 자주 발생
2. Copying 기반 → 메모리 파편화 없음
3. Major GC보다 STW 시간이 짧음

1. Stop-The-World (STW)

• 모든 애플리케이션 스레드 일시 정지
• Young 영역만 처리하므로 STW 시간이 비교적 짧다

2. Mark (Reachability 분석)

• GC Root에서 시작해 Eden과 Survivor 영역의 객체 중
• 참조 중인 객체만 Reachable로 표시

3. Copy (Young GC의 핵심)

• Reachable 객체를 Eden → Survivor(To)로 복사
• From 영역의 살아있는 객체도 함께 복사
• 이 과정에서 객체 age 증가
• Eden과 From 영역은 통째로 비워진다

4. Promotion

• age 임계값을 초과한 객체는 Old Generation으로 이동
• Survivor 공간이 부족해도 강제로 Promotion 발생 가능
• Old 영역에 공간이 없으면 Promotion Failure → OOM 발생 가능

→ Premature Promotion은 Major GC를 앞당기는 주요 원인이다.

Major GC / Full GC (Old Generation GC)

Old Generation을 대상으로 수행되며,
상황에 따라 Heap 전체를 정리하는 Full GC로 확장될 수 있다.

📒 실무에서는 Major GC와 Full GC를 혼용해 부르기도 하지만, 엄밀히는 Full GC는 Heap 전체(Young + Old + Metaspace)를 대상으로 한다.

📌 Major / Full GC 특징

• 발생 빈도 낮음
• STW 시간이 길어 서비스 지연 유발
• GC 튜닝의 핵심 대상
• CMS, G1, ZGC, Shenandoah 등은 STW 최소화를 목표로 설계됨

1. Stop-The-World (STW)

• Minor GC보다 훨씬 긴 STW 발생

2. Mark

• GC Root부터 Heap 전체를 스캔
• 살아있는 객체를 Reachable로 표시

3. Sweep

• Unreachable 객체 제거

4. Compact (알고리즘에 따라)

• 살아남은 객체를 한쪽으로 밀어 메모리 파편화 제거
• 연속된 메모리 공간 확보

GC 종료 후

• STW 해제 후 애플리케이션 재개
• GC가 잦거나 Major GC 시간이 길어질 경우

→ Latency 증가, Throughput 감소로 이어진다.

정리

GC는 자동이지만 공짜는 아니다.
객체 생명 주기를 잘못 설계하면 GC 비용은 그대로 성능 문제로 드러난다.

GC 튜닝의 핵심은

• Minor GC를 빠르게,
• Major GC를 최대한 늦게,
• STW 시간을 최소화하는 것이다.

참고 자료

• https://inpa.tistory.com/entry/JAVA-☕-가비지-컬렉션GC-동작-원리-알고리즘-💯-총정리
• [Java]가비지 컬렉터(Garbage Collector)란?

TDD에서 파생됨, TDD는 리소스가 많이 들어서 개발 시간 지연이라는 문제를 발생 시킴 그렇기에 BDD로 행동에 대한 중점 테스트를 하기 시작함, 하지만 TDD와 BDD는 상호보완 관계 테스트하는 영역이 다르기에 더 안전한 서비스를 만들 수 있음 즉 대화를 통해 요구사항을 예제로 명확 할 수 있다

사용이점

기능 명세서, 테스트 케이스, 매뉴얼 등등 여러 문서를 통합해서 작성 가능하고 "비개발자"뿐 아닌 "개발자" 모두 확인하면서 살아있는 문서를 만들 수 있다. 특히 Single Source of Truth를 유지하는 것에 도움을 준다.

BDD 사용 순서

1.명세 작성 PO, 기획자, 개발자 등이 모여 Gherkin 문법으로 .feature 파일을 작성하고 모두 동의를 해야한다.(이 시점에서 아직 구현 코드도 작성 안 함) -> Ex) Given 계산기에 2와 3을 입력하고...

2.Step Definition 자동화 개발자는 합의된 .feature 파일을 가져와 Step Definition (Java 테스트 코드)을 작성한다. (이때, 테스트를 실행하면 Step Definition 코드는 실제 서비스 로직을 찾지 못해 실패(Red) 상태가 되기에 TDD의 Red 단계와 유사)

3. 기능 구현

개발자는 이 실패한 Step Definition(테스트 코드)을 통과시키기 위해 최소한의 서비스 로직(생산 코드)을 작성합니다.

테스트 코드를 나중에 작성해도 될까?

결론은 그러면 안 된다. BDD는 통합 테스트로 이루어질 확률이 높다. 그렇기에 초기에 구상한 테스트 코드에 의존성이 추가되거나 변경되는 것은 당연하다. BDD의 테스트 코드 비즈니스 로직이 아닌 기술적인 구현 세부사항에 의존해야 하기에 변경은 상관없다. 테스트 코드 변경을 감수하고 비즈니스 코드를 작성하면 된다.

Cucumber

• spring boot에서 사용할 프레임 워크, .feature 파일 작성 하여
• jira 티켓에 [given, when, then]을 작성 -> 개발자와 비개발자 모두 확인할 수 있도록 (Gherkin 문법으로 작성 필수)

프로젝트 적용 예시

주어진 .feature 시나리오를 바탕으로 Java Step Definition 코드를 작성하겠다. 이 과정은 Gherkin 문장을 실제 Java 클래스의 메소드에 연결(Glue)하고, 그 메소드 안에서 애플리케이션의 핵심 로직을 호출하는 방식으로 진된다.

.feature 더하기 케이스

Feature: 계산기 기능

  Scenario: 두 수를 더한다
    Given 계산기에 2와 3을 입력하고
    When 더하기를 수행하면
    Then 결과는 5가 되어야 한다

더하기 케이스가 n개 예시

Feature: 계산기 기능

  Scenario Outline: 여러 수의 덧셈 검증
    Given 계산기에 <num1>과 <num2>를 입력하고
    When 더하기를 수행하면
    Then 결과는 <result>가 되어야 한다

    Examples:
      | num1 | num2 | result |
      | 2    | 3    | 5      |
      | 10   | 20   | 30     |
      | -1   | 5    | 4      |

.feature를 위한 Java Step Definition

1단계: 프로젝트 환경 준비 (Calculator.java)

테스트할 핵심 로직을 가진 간단한 Calculator 클래스를 준비합니다. 이 클래스는 Spring Bean으로 간주하고 테스트 환경에서 주입받아 사용합니다.

// src/main/java/com/example/app/Calculator.java

package com.example.app;

// 실제 애플리케이션의 핵심 로직
public class Calculator {
    private int result;

    public void input(int a, int b) {
        // 실제 입력 처리 로직 (필요하다면)
    }

    public void add(int a, int b) {
        this.result = a + b;
    }

    public int getResult() {
        return this.result;
    }
}

2단계: Step Definition 클래스 작성 (CalculatorSteps.java)

.feature 파일의 Gherkin 문장들을 처리할 Java 클래스를 작성한다. 보통 src/test/java/com/example/steps와 같은 패키지에 위치하며, Spring 환경을 사용하기 위한 설정이 포함된다.

// src/test/java/com/example/steps/CalculatorSteps.java

package com.example.steps;

import com.example.app.Calculator;
import io.cucumber.java.en.Given;
import io.cucumber.java.en.When;
import io.cucumber.java.en.Then;
import org.springframework.beans.factory.annotation.Autowired;
import static org.junit.jupiter.api.Assertions.assertEquals;

// 1. SpringBootTest 어노테이션을 사용하여 Spring 컨텍스트를 로드합니다.
//    (실제 Spring Boot 환경에서는 별도의 @ContextConfiguration 설정이 필요할 수 있습니다.)

public class CalculatorSteps {

    // 2. 테스트 대상인 Calculator Bean을 주입받기 위한 필드
    private Calculator calculator = new Calculator(); // 간단 예시를 위해 직접 인스턴스화

    // 테스트에 사용할 임시 변수
    private int number1;
    private int number2;
    private int actualResult;

    // =========================================================================
    // 3. GIVEN 절 구현: Given 계산기에 2와 3을 입력하고
    // =========================================================================
    // 정규 표현식: ^...$는 문장의 시작과 끝을 의미합니다. (\\d+)는 숫자를 캡처합니다.
    @Given("계산기에 {int}와 {int}을 입력하고")
    public void 계산기에_두_수를_입력하고(int a, int b) {
        // Cucumber가 feature 파일에서 '2'와 '3'을 추출하여 a와 b 인수로 전달합니다.
        this.number1 = a;
        this.number2 = b;
        // 입력 처리가 있다면 여기서 로직을 호출합니다.
    }

    // =========================================================================
    // 4. WHEN 절 구현: When 더하기를 수행하면
    // =========================================================================
    @When("더하기를 수행하면")
    public void 더하기를_수행하면() {
        // 실제 애플리케이션의 핵심 로직을 호출합니다.
        calculator.add(this.number1, this.number2);
        this.actualResult = calculator.getResult(); // 결과를 저장합니다.
    }

    // =========================================================================
    // 5. THEN 절 구현: Then 결과는 5가 되어야 한다
    // =========================================================================
    @Then("결과는 {int}가 되어야 한다")
    public void 결과는_기대값과_같아야_한다(int expectedResult) {
        // Cucumber가 feature 파일에서 '5'를 추출하여 expectedResult 인수로 전달합니다.

        // JUnit의 Assertion을 사용하여 실제 결과와 기대 결과를 비교하여 검증합니다.
        assertEquals(expectedResult, this.actualResult, "두 수의 덧셈 결과가 기대값과 다릅니다.");
    }
}

* 3단계: 테스트 러너 실행*

CucumberTestRunner 실행시 Cucumber 동작 순서

1. .feature 파일의 Given 계산기에 2와 3을 입력하고 문장을 읽습니다.
2. CalculatorSteps.java의 @Given("계산기에 {int}와 {int}을 입력하고") 메소드를 찾습니다.
3. 2와 3을 추출하여 number1과 number2 변수에 저장합니다.
4. When 더하기를 수행하면 문장을 읽고, @When("더하기를 수행하면") 메소드를 실행합니다.
5. calculator.add(2, 3)을 호출하고, 결과 5를 actualResult에 저장합니다.
6. Then 결과는 5가 되어야 한다 문장을 읽고, @Then("결과는 {int}가 되어야 한다") 메소드를 실행합니다.
7. assertEquals(5, actualResult)를 실행하여 테스트를 성공으로 처리합니다.

프로젝트에서 DDD 방법론을 사용하자는 의견이 나왔다. 저번 프로젝트에서도 사용을 했고 이벤트 스토밍으로 유비쿼터스 언어를 정할 수 있어서 좋다고 생각했는데 이번에는 좀 더 본격적으로 사용하면 좋을거라고 생각으로 조사한 내용을 정리하려고 한다.

DDD란?

DDD란 domain drvien design으로 복잡한 비즈니스 문제 영역(도메인)을 소프트웨어 설계의 중심에 두는 개발 방법론으로, 소프트웨어 구현 방법론 중 1개이며 애자일 + DDD 또는 워터풀 + DDD로 사용 가능하다.

DDD 특징

• 도메인 로직에 집중: 데이터베이스 중심의 설계가 아닌, 순수한 비즈니스 규칙과 로직에 초점 맞춤
• 유비쿼터스 언어: 도메인 전문가와 개발자가 분석, 설계, 그리고 코드에 이르기까지 동일한 표현과 단어로 구성된 통일된 언어 체계 구축
• 모델과 코드의 일치: 소프트웨어의 엔티티와 도메인 개념을 가능한 한 가깝게 일치시켜, 도메인에서 발생하는 변화를 코드에 쉽게 반영

📝 DDD 적용 1차: 도메인 분석과 전략적 설계

1차 과정은 도메인을 깊이 이해하고, 그 이해를 소프트웨어 모델로 풀어내는 반복적인 설계·구현 과정을 진행한다. 아래 단계들은 순서가 아닌 여러 번 왕복하며 모델을 다듬어 가는 순환적인 활동(Continuous Refinement)이다. (1차 과정은 팀원 모두가 같이 하여 도메인에 대해 자세히 아는 것이 중ㅇ요하다)

1. 이벤트 스토밍 워크숍으로 도메인 탐색

도메인 전문가와 개발자가 한자리에 모여, 비즈니스 흐름에서 발생하는 중요한 사건들을 "도메인 이벤트" 형태로 시간 순서대로 나열한다. 이를 통해 복잡한 비즈니스 프로세스를 빠르게 시각화하고, 팀이 공유하는 유비쿼터스 언어의 기초를 만듭니다. 이벤트 스토밍 진행 방법

2. 전략적 설계: 경계 컨텍스트와 컨텍스트 매핑

이벤트 스토밍에서 드러난 이벤트 흐름과 용어의 의미 변화 지점을 기준으로, 도메인을 여러 개의 경계 컨텍스트(Bounded Context)로 나눕니다. 각 컨텍스트 간의 통합 방식과 의존 관계는 컨텍스트 매핑(Context Mapping)으로 표현하한다. 전체 시스템의 협력 구조를 정의하는 단계

3. 전술적 설계 1: 애그리거트와 도메인 모델링

각 경계 컨텍스트 내부에서 비즈니스 규칙과 트랜잭션 일관성을 함께 묶어야 하는 범위를 중심으로 애그리거트(Aggregate)를 선정한다. 애그리거트 루트, 엔티티, 값 객체와 같은 전술적 패턴을 사용해 모델을 구체화하고, 애그리거트가 경계 컨텍스트 내의 일관성 규칙을 잘 표현하도록 정제한다.

4. 전술적 설계 2: 유스케이스 기반 행위 정의

유스케이스와 사용자 스토리를 분석해 사용자가 시스템에서 수행하는 작업(Command)과 그에 따른 도메인 동작을 정리합니다. 이를 바탕으로 애그리거트와 도메인 서비스의 메서드, 응용 서비스의 흐름을 정의하며, 필요 시 앞 단계(애그리거트 설계나 경계 컨텍스트 설계)로 돌아가 모델을 반복적으로 개선한다.

🛠️ DDD 적용 2차: 구현 설계와 개발

1차에서 도메인 모델과 경계 컨텍스트를 정리했다면, 2차에서는 이를 실제 시스템 구조와 코드로 옮겨가는 작업을 진행한다. 이 단계 역시 구현을 하면서 다시 모델을 수정하는 순환 구조를 가진다. (2차부터는 개발자들이 모여서 의논하는 것이 핵심이다.)

1. 도메인 모델을 담을 아키텍처 선택

도메인 계층을 기술 세부사항(웹, DB 등)으로부터 분리할 수 있는 [레이어드,헥사고날, 클린 아키텍처 등등] 패턴을 선택한다. (필요 시 CQRS나 이벤트 소싱을 고려 가능하다)

• 구조 명확화: "도메인 레이어에 애그리거트·엔티티·값 객체·도메인 서비스가 위치하고, 응용 레이어/어댑터 레이어가 이를 이용한다"는 구조를 명확

2. 테스트 전략 및 개발 방식 정의 (필수X)

도메인 모델을 신뢰할 수 있게 유지하기 위해 어떤 테스트 전략을 쓸지 결정해야한다. 유비쿼터스 언어를 그대로 사용하는 테스트 코드 작성을 목표로 합니다.

• 테스트 대상: 도메인 모델을 대상으로 하는 단위 테스트, 유스케이스 단위의 통합 테스트, 경계 컨텍스트 간 협력을 검증하는 E2E 테스트 등을 정의한다.
• 개발 방식: 팀 상황에 따라 TDD, ATDD, BDD 등 적용 여부와 범위를 정한다.

3. 구현 및 반복적 리팩터링

1차에서 정의한 경계 컨텍스트·애그리거트·유스케이스를 기준으로 응용 서비스, 도메인 모델, 인프라스트럭처 등등을 구현합니다.

• 구현 과정에서 발견되는 모델의 부족함이나 불편함은 다시 1차 설계 단계로 피드백하여, 모델과 코드가 함께 발전(Continuous Refinement)하도록 반복적으로 리팩터링한다.

결론

DDD와 함께 사용할 수 있는 방법론이 있다고 생각하지 못 했다. DDD가 방법론이라서 다른 것을 사용 안 하다고 여겼는데 조사를 통해서 다른 것임을 확인하고 어떻게 하면 DDD에서 추구하는 바를 프로젝트 전반에 녹여 낼 수 있을까 고민하게 되어서 조사하는 시간이 즐겁고 재미있었다.

참고 자료

• https://www.msaschool.io/operation/design/design-two/
• https://tech.kakaopay.com/post/backend-domain-driven-design/#step2---domain-model--function
• https://ksh-coding.tistory.com/103
• https://www.linkedin.com/pulse/strategic-vs-tactical-domain-driven-design-ddd-vintageglobal-lisbe/

부트캠프에서 진행한 스타벅스 클론에서 동시성 이슈를 비관적 락으로 해결하였다. 그런데 낙관적 락으로 해결을 왜 안 했냐는 질문을 받았고 주문에 대한 내용은 중요한 정보이기에 비관적 락으로 해결했다라는 나의 답은 근거가 없는 거라고 답변을 들었기에 2개를 비교하는 실험을 진행하려고 한다.

이전 프로젝트 내용 (비 관적락 사용)

• 주문 번호 구현, 동시성 오류 정리

• 주문 번호 구현, 동시성 오류 비관적 락(Pessimistic Lock)으로 해결하기

  테스트 환경

• API: POST /api/v1/orders (주문 생성)

• 동시성 제어 대상: OrderDailyCounter (매장별 일일 주문번호 카운터)

• 테스트 도구: k6 Testing

• 테스트 기간: 1분, 100 RPS

• github repo: https://github.com/Cori1304-Seong/starbucks-backend-v2

• ** 낙관적락 적용 PR**: https://github.com/Cori1304-Seong/starbucks-backend-v2/pull/1

  낙 관적락 1차 테스트

  1분 동안 100 RPS를 발생 시켰다. 당연히 실패율 0%에 비관적락 이상에 결과를 보여 줄 주 알았는데 아래 표와 같이 이상한 결과를 얻었다.

성능 비교표

1차 테스트 원인 분석

원인: 부하 테스트시 1개에 매장에만 요청을 보내는 것이 문제였다.

상세 설명

기존 테스트는 모든 주문이 1개에 매장으로 향한다. 이 경우 동시성 이슈가 있던 주문번호 생성 로직은 100% 충돌이 발생한다. 매장은 주문번호 생성을 위해서 주문이 들어오면 counter +1을 한 값을 주문번호로 만든다. 이때 동시에 요청이 들어오면 충돌이 발생했고 비관적 락은 충돌을 일어나는 것을 전제로 만든 로직이었고 낙관적 락은 그렇지 않았던게 문제 였다.
(낙관적 락은 충돌이 일어나지 않고 서로 다른 레코드에 적용해야 하는데 테스트 환경이 그렇지 못한 것이었다.)

시퀀스 다이어그램

k6 코드 변경

// 문제 코드
function makeOrderPayload(email, idx) {
  return JSON.stringify({
    storeId: 1, -> 원인 
    pickupType: "STORE_PICKUP",
    requestMemo: `주문자: ${email} - 얼음 많이, 샷 연하게 부탁드려요!`,
    cardNumber: `1234-5678-9${String(idx).padStart(3, "0")}-0000`,
    orderItems: [
      {
     //... 


// 수정 코드, storeId를 고정이 아닌 1~10인 랜덤 값으로 설정 (DB에 매장은 10개만 존재) 
function makeOrderPayload(email, idx) {
  const randomStoreId = Math.floor(Math.random() * 10) + 1; // 1~10 사이의 랜덤 storeId
  return JSON.stringify({
    storeId: randomStoreId,
    pickupType: "STORE_PICKUP",
    requestMemo: `주문자: ${email} - 얼음 많이, 샷 연하게 부탁드려요!`,
    cardNumber: `1234-5678-9${String(idx).padStart(3, "0")}-0000`,
    orderItems: [
      {

원인 요약

• spring boot에 문제 X, k6 부하 테스트 시나리오 문제
• 기존은 1개 매장에 1분 동안 100RPS, 현재는 10개에 매장에 1분 동안 100RPS
• 동일안 레코드에서 충돌 발생, 낙관적 락으로 해결할 수 없었기에 결과가 이상한게 아닌 테스트 시나리오가 문제

낙 관적락 2차 테스트

k6 코드 변경 후 드디어 원하던 결과를 얻었다.

성능 비교표

결론

처음 시도에서는 많이 당황했다. java 코드 문제라고 생각해서 AI에게 계속 물어도 해결지 않았던 문제였지만 낙관적 락을 다시 공부하면서 문제를 해결하였다. 이래서 CS 지식 즉 이론이 중요하다고 생각하게 되었다.

참고 자료

• https://ksh-coding.tistory.com/125#2.%20Base%20Code%EC%9D%98%20%EB%AC%B8%EC%A0%9C%EC%A0%90%20(%EB%8F%99%EC%8B%9C%EC%84%B1)-1
• https://chaewsscode.tistory.com/242

사이드 프로젝트에서 DDD 방법론을 이용해서 프로젝트를 진행할 예정이다. 그런데 아키텍처 선택에 대한 문제가 있기에 layered와 hexagonal 2개를 비교하려고 한다. (clean architechture는 논외로 치고 글을 작성했다)

Layered

Layered Architecture는 소프트웨어 시스템을 논리적인 책임에 따라 수직적인 계층으로 분리하여 설계하는 가장 보편적인 아키텍처이다. spring boot로 프로젝트를 진행하였다면 다들 Layered를 사용해본 경험을 가지고 있을 것이다. (Controller, Service, Repository, Entity 4개로 계층을 나눠서 사용했기에 Layered로 사용했을 거라고 추측하였다)

핵심 규칙

• 관심사 분리 : 각 계층은 오직 하나의 특정한 책임만 수행한다.
• 단방향 의존성 : 아래 계층은 위 계층을 모르고, 오직 아래 계층에게만 서비스를 요청하고 의존해야 한다.

폴더 구조 예시

Infrastructure, Application, Domain, Presentation

src/main/java/com/example/project/
 ├─ presentation/
 │    └─ article/
 │         ├─ ArticleController.java
 │         └─ ArticleDto.java
 │
 ├─ application/
 │    └─ article/
 │         └─ ArticleService.java
 │
 ├─ domain/
 │    └─ article/
 │         ├─ Article.java
 │         ├─ ArticleRepository.java   ← interface
 │         └─ ArticleService.java      ← DomainService(선택)
 │
 └─ infrastructure/
      └─ article/
           ├─ JpaArticleRepository.java  ← Repository 구현체
           └─ ArticleEntityMapper.java   ← JPA 엔티티 변환

Hexagonal

hexagonal은 비즈니스 로직을 중심에 두고, 외부 세계와의 모든 상호작용을 포트(Port)와 어댑터(Adapter)라는 표준화된 인터페이스를 사용하는 아키텍처이다.

핵심 규칙

모든 의존성은 안쪽을 향함(의존성 역전의 원칙) : 비즈니스 코어는 외부 기술(예: 특정 DB)에 대해 전혀 알지 못해야 한다. 코어는 자신이 필요한 기능을 인터페이스(포트)로만 정의하고, 실제 구현은 외부의 어댑터가 담당한다.

1. 외부가 내부에 의존
2. 비즈니스 로직은 기술 독립적
3. 외부 시스템 없이 테스트 가능 (의존성 없이)

폴더 구조 예시

src/main/java/com/example/project/
 ├─ domain/  // 1. Core: Domain Layer (가장 중심, 순수한 비즈니스 로직)
 │    └─ article/
 │         └─ Article.java                    // 핵심 도메인 모델, 비즈니스 규칙 포함
 │
 ├─ application/ // 2. Application Layer (Use Case 정의 및 구현)
 │    ├─ port/
 │    │    ├─ in/
 │    │    │    └─ ArticleCommandPort.java    // [인바운드 포트] 외부 요청을 처리하는 인터페이스 정의
 │    │    └─ out/
 │    │          └─ ArticleLoadPort.java       // [아웃바운드 포트] DB 접근 등 외부 호출을 위한 인터페이스 정의
 │    └─ service/
 │         └─ ArticleCommandService.java     // [Use Case 구현체] ArticleCommandPort 인터페이스 구현
 │
 └─ adapter/   // 3. Adapters Layer (인프라 및 입출력 기술 의존성 관리)
      ├─ in/
      │    └─ web/
      │          ├─ ArticleWebAdapter.java     // [인바운드 어댑터] Spring Controller 역할. Port 호출
      │          └─ ArticleRequest.java        // Web DTO
      └─ out/
          └─ persistence/
              ├─ JpaArticleAdapter.java      // [아웃바운드 어댑터] ArticleLoadPort 인터페이스 구현 (DB 연동)
              └─ JpaArticleEntity.java       // JPA 전용 엔티티

코드를 통한 비교

글을 읽고 또 읽어도 잘 모르겠다는 생각이 들었기에 코드를 직접 만들어 보기로 하였다. 숙소 예약 기능을 가진 프로젝트를 생성하고 아키텍처를 비교해 보겠다. 공부한 프로젝트 (코드와 폴더 구조에대해서 의견을 주시면 긍정적으로 반영하겠습니다. )

프로젝트는 3개에 도메인 기능이 있는데 [숙소 관리,예약 관리, 유저 관리]를 중심으로 구현하였다.

도메인 별로 파일 개수 비교

두 아키턱처에서 파일 개수가 나는 이유는 Layered의 Service 1개 역할을 Hexagonal에서는 UseCase Port + Service + Repository Port로 분리하고, 추가로 DTO, Mapper, Adapter를 더해서 총 7-10개 파일이 더 필요하기 때문이다.

결론

Hexagonal은 구조를 통해 강제적으로 SOLID 원칙을 준수하도록 만드는 방법이라고 느껴진다.환경을 통해서 개발자를 가이드하는 것, 이것이 좋은 아키텍처가 아닐까라는 생각이 들었다.

하지만 동시에 "Hexagonal은 모든 프로젝트에 실질적인 도움을 줄까?"라는 의문도 들었다. Hexagonal Architecture, 진짜 하실 건가요?와 okky 커뮤니트를 읽고 또 생각에 잠긴다.

최종 결론

결론은 또 케바케다. 결국 아키텍처는 현재 팀의 상황과 프로젝트 특성에 맞춰 선택해야 하며, "무조건 Hexagonal이 좋다" 또는 "과도하다"는 이분법적 사고보다는 트레이드오프를 이해하고 의식적으로 선택하는 것이 중요하다.

개인적으로 이번 조사를 통해 느낀 점은, Hexagonal Architecture는 "초기 비용을 지불하고 장기 이익을 얻는 투자"라는 것이다. 프로젝트가 그만한 투자 가치가 있는지 판단하는 것이 핵심이다.

참고 자료

• https://velog.io/@gayeong39/SPRING-%EB%A0%88%EC%9D%B4%EC%96%B4%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98 https://msolo021015.medium.com/layered-architecture-deep-dive-c0a5f5a9aa37
• https://curiousjinan.tistory.com/entry/spring-hexagonal-architecture

만약 개발자 면접에서 "REST API가 무엇인지 설명해 줄래요?"라고 질문하면 뭐라고 답할까? 아래와 같이 대답 할 수 있다

"REST API는 웹의 기본 프로토콜인 HTTP를 기반으로, 자원(Resource)을 이름(URI)으로 구분하고 해당 자원에 대한 행위(CRUD)를 HTTP 메서드를 통해 처리하도록 설계된 아키텍처 스타일입니다. 한마디로, 웹 상에서 데이터를 효율적으로 주고받기 위한 표준화된 통신 규약이라고 할 수 있습니다."

모범답안을 말하고 안심하겠지만, 2000년에 발표된 논문을 보면 로이 필딩(Roy Fielding)이 정의한 본래의 REST와는 거리가 있어 아쉬워할 것입니다. (REST 아키텍처 스타일 논문 작성자가 로이 필딩입니다.)

로이 필딩이 발표한 진정한 REST API가 무엇인지 자세히 살펴봅시다.

😮 REST API의 6가지 조건 (by Roy Fielding)

API가 RESTful 하다고 인정받으려면, 로이 필딩이 제시한 REST의 6가지 아키텍처 제약 조건을 만족해야 한ㄷ.

1. 클라이언트-서버 구조 (Client-Server)

• 규칙: 클라이언트(예: 웹 브라우저)와 서버(API 제공)가 독립적으로 분리되어야 합니다. 서버는 리소스 처리와 비즈니스 로직을, 클라이언트는 사용자 인터페이스를 담당한다.
• 장점: 각 부분이 독립적으로 개발 및 배포될 수 있어 상호 의존성이 낮아진다.

2. 무상태성 (Stateless)

• 규칙: 서버는 클라이언트의 요청 간 상태 정보(세션, 로그인 정보 등)를 저장하지 않는다. 모든 요청은 처리에 필요한 모든 정보를 스스로 포함해야 한다.
• 장점: 서버의 구현이 단순해지고, 수평적 확장성과 로드 밸런싱에 매우 유리

3. 캐시 처리 가능 (Cacheable)

• 규칙: 서버 응답은 데이터가 캐싱 가능한지 여부를 명시한다. (예: HTTP 헤더).
• 장점: 캐싱을 통해 불필요한 요청을 줄여 네트워크 트래픽을 감소시키고 성능을 향상시킬 수 있다.

4. 계층화 시스템 (Layered System)

• 규칙: 클라이언트는 서버에 직접 연결되었는지, 혹은 중간 계층(프록시, 로드 밸런서, 방화벽 등)을 통해 연결되었는지 알 필요가 없어야 한다.
• 장점: 시스템 보안 및 확장성을 위해 유연하게 중간 계층을 추가하고 변경할 수 있다.

5. 균일한 인터페이스 (Uniform Interface)

• 규칙: 시스템 전체에 걸쳐 일관되고 통일된 방식으로 상호작용이 가능해야 합니다. 이는 다음 네 가지 하위 원칙을 포함한다.

  1. 리소스 식별: URI를 사용하여 자원을 명확하게 식별 가능해야 한다
  2. 메시지를 통한 자원 조작: HTTP 메서드(GET, POST, PUT, DELETE)를 사용하여 자원에 대한 행위를 표현 가능해야 한다.
  3. 자기 서술적 메시지: 메시지(요청/응답)만으로 그 뜻을 완전히 파악할 수 있어야 한다. (예: HTTP 헤더에 데이터 타입 명시).
  4. HATEOAS: 응답에 현재 자원과 연관된 하이퍼링크를 포함하여, 클라이언트가 다음 상태로 전이하기 위해 수행할 수 있는 모든 작업을 동적으로 찾을 수 있어야 한다.

• 장점: API가 간결하고 예측 가능해지며, 클라이언트와 서버의 구현이 분리되어 독립적인 진화가 가능해진다.

6. Code-On-Demand (선택적 조건)

• 규칙: 서버가 클라이언트에게 실행 가능한 코드를 전송하여 클라이언트의 기능을 일시적으로 확장할 수 있어야 한다. (예: 자바스크립트).
• 참고: 이 조건은 선택 사항(Optional)이며, 필수 조건은 아닙니다.
• 장점: 클라이언트의 기능을 서버가 동적으로 확장할 수 있는 유연성을 제공한다.

완벽하게 REST API를 지키지 않는 이유

지금까지 개발하고 참고했던 API들을 되돌아보면, 6가지 조건을 모두 만족했는지 의문이 들었다. 그런데도 왜 사람들은 조건을 만족시키지 못했는데도 REST API라고 부르는 걸까?

1. REST는 대용량 하이퍼미디어 시스템을 위한 설계다

필딩의 논문 제목은 "네트워크 기반 소프트웨어 아키텍처의 아키텍처 스타일과 설계"이다. 즉, 특정 API 구현 방법에 대한 논문이 아니라 웹과 같은 대용량 분산 하이퍼미디어 시스템에서 사용할 아키텍처 원칙을 소개한 것이다.

현대의 REST API는 주로 데이터 교환(CRUD)에 집중하지만, 필딩의 REST는 상태 전이(HATEOAS)를 통한 시스템의 독립적 진화에 더 초점을 맞췄다는 점에서 목적과 사용처에 차이가 발생하였다.

2. HATEOAS 구현은 비효율적이다.

필딩의 REST에서 가장 중요한 원칙은 HATEOAS이다. HATEOAS를 사용하면 응답에 데이터뿐만 아니라 해당 데이터와 관련된 다음 요청에 필요한 URI를 포함하여 반환하며, 클라이언트가 서버와 동적으로 상호작용이 가능하게 한다.

<HATEOAS 예시: 상태 전이>

HATEOAS의 진정한 가치는 자원의 상태에 따라 다음 액션을 동적으로 제공하는 데 있다.

A. 주문 완료 전 상태

{
    "order_id": 500,
    "status": "PENDING",
    "total_price": 45000,
    "_links": {
        "self": { "href": "/orders/500" },
        "pay": { "href": "/orders/500/payment", "method": "POST" },
        "cancel": { "href": "/orders/500/cancel", "method": "POST" }
    }
}

클라이언트 행동: 클라이언트는 status가 PENDING일 때, 응답의 pay 또는 cancel 링크만 보고 해당 작업을 수행

B. 주문 완료 후 상태

결제를 완료하면 서버는 응답 데이터를 변경하여 pay 링크를 제거하고 refund 링크를 추가한다.

{
    "order_id": 500,
    "status": "COMPLETED",
    "total_price": 45000,
    "payment_date": "2025-11-20",
    "_links": {
        "self": { "href": "/orders/500" },
        "refund": { "href": "/orders/500/refund", "method": "POST" } 
    }
}

클라이언트 행동: 클라이언트는 이제 pay 링크가 없다는 것을 확인하고 결제 버튼을 숨기거나 비활성화하며, refund 링크를 통해 환불 요청만 할 수 있다.

하지만 현실적으로 HATEOAS를 구현하면 서버와 클라이언트 모두 개발 복잡성이 증가하여 효율성이 저하된다. 그렇기 때문에 거의 모든 상용 API는 HATEOAS를 사용하지 않는다.(필딩은 이를 HTTP API로 불러주길 원한다....)

3. SOAP의 대안과 HTTP의 편리성

2000년대 초반에는 XML 기반의 SOAP를 사용하는 API가 주를 이루었으나, SOAP는 XML 사용으로 인한 오버헤드와 복잡성이 존재했습니다. 이때, HTTP라는 이미 널리 사용되는 간단한 프로토콜을 활용하는 RESTful 방식이 편리한 대안으로 부상했습니다.

개발자들이 REST의 핵심인 'URI로 자원 식별'과 'HTTP 메서드로 행위 표현'이라는 가장 쉽고 강력한 두 가지 원칙만 차용하고, 복잡한 HATEOAS를 생략했습니다. 즉, 편의성과 실용주의 덕분에 HTTP 통신이 필요한 곳에 무분별하게 사용되며, 'REST API'라는 용어가 대중화 및 일반화된 것입니다.

4. 이미 관념이 잡혔다.

4번은 3번에 연장선이다. REST API라고 생각했던 (HTTP API)라는 이름을 바꿀 수 없게 되었다. 이미 문서와 글 그리고 회의때도 사용했고 의미 전달이 되기 때문이다. 예를 들어서 "옥동자"를 가지고 설명하면 원래는** 옥(玉)같이 예쁜 어린 아들, 몹시 소중한 아들** 이라는 뜻이지만, 개그맨 1명에 등장으로 의미가 별질되었다.

결론

현제 REST API는 필딩 아저씨의 API와는 다른 것이다. 목적은 같을 수 있지만 다르다. 테세우스의 배와 같다고 생각이 든다. 누구의 관점을 볼 것인가. 참 재미있는거 같다. 그래도 빌딩 아저씨 덕분에 REST API를 사용할 수 있다는 것은 맞다고 생각을 하기에 고맙다라는 마음이 든다. SOAP는 좀..

참고 자료

[WEB] REST(feat. 로이 필딩과 잘못된 REST)

흔히 잘못 이해되는 로이 필딩의 REST 논문

이번주 일요일 25.11.19에 1차 개발자 회의 주제로 API 설계 회의를 진행하려고 한다. 그때를 위해서 REST API에 대한 기록과 의논할 부분이 무엇이 있을지 서술하려고 한다. (아직 기획이 정리되지 않았기에 세부적인 내용을 정할 수 없지만 미래 정할 수 있는것을 정하려고 한다)

REST API란?

REST API는 REST 아키텍처 스타일의 설계 원칙을 따르는 애플리케이션 프로그래밍 인터페이스(API)입니다. REST는 Representational State Transfer의 약자로, 웹 API를 구축하는 방법에 대한 일련의 규칙과 지침입니다. Red Hat 인용

Rest API란 REST한 규칙을 지키는 API를 말하고 이 규칙을 지킨 API를 RESTful하다고 칭 합니다.

REST API 예제

👥 기본 자원 관리: 사용자 (/users)

🔗 관계형 자원 관리: 게시물과 댓글

⚙️ 기타 행위 및 쿼리 표현

의논할 부분

1. JWT 사용시 refresh와 access Token을 cookie only로 설정?

2. 이미지 사용시 multipart/form-data 사용? CDN 사용? (Server-Side Upload or Direct Upload)

3. Exception 처리

   • body에 들어갈 데이터를 어떻게 둘것인가? timestamp,status, msg, code, details

   /*예시*/
   {
      "timestamp": "2025-11-22T07:30:00Z",
      "status": 401,
      "code": "AUTH_001",
      "message": "Access token expired. Please refresh your token.",
      "details": null
   }

   4. success에도 code가 필요한가?

참고 자료

HTTP에 대해서 알아보자(정의와 구조) 개발 초보를 위한 RESTful API 설계 가이드 (구글) REST API란 무엇인가요? [REST API] Roy Fielding이 말하는 6가지 제약 조건 - Chat 상우

회의 후 결과물

과거 프로젝트를 진행하면서 spring과 서버에 대해서는 공부를 집중적으로 했지만 DB에 대해서는 적게 공부하였기 때문에 DB에 대한 공부를 하던 중 index 실습중에 마주친 문제와 index가 왜 필요한지에대해서 기술하기 위해 작성한 글이다.

Index란?

DB에서 데이터를 빠르게 검색하고 접근하기 위해 테이블의 하나 또는 여러 column을 이용하여 생성하는 자료 구조로 B-Tree 또는 B+Tree구조로 이뤄어 졌고 책의 목차 또는 색인처럼 동작하며 full Table Sca하는 대신, 인덱스를 통해 데이터가 저장된 위치를 즉시 찾아갈 수 있게 합니다

index의 목적

조회(SELECT) 작업의 성능을 크게 향상시키기 위해(그렇기에 사입, 삭재, 갱신시 오버해드가 발생할 수 있다. 그렇기에 전략적으로 사용해야 한다.)

백과사전 비유로 index 설명

• DB 테이블 (Table): 백과사전의 '본문 전체'입니다. (수많은 데이터가 순서 없이, 혹은 특정 순서로 저장되어 있는 곳)

• DB 인덱스 (Index): 백과사전의 '맨 뒤에 있는 찾아보기 (색인)'입니다.
• 데이터 검색 (Query): 인덱스가 없는 경우: 백과사전에서 특정 단어(예: '양자역학')를 찾으려면 첫 페이지부터 마지막 페이지까지 한 장씩 넘겨가며 눈으로 직접 찾아야 합니다. (이것이 Full Table Scan)

  • 인덱스가 있는 경우: 먼저 색인 페이지를 펼칩니다. 색인에서 '양자역학'을 찾으면 옆에 '357페이지'라고 적혀 있습니다. 바로 357페이지로 넘어가 원하는 정보를 즉시 찾습니다. (이것이 Index Scan)

실습 진행

1. repo clone
2. repo의 init.sql 문 실행 (DB에 테이블과 row 생성)
3. full scan과 range 조회 SQL 실행 후 시간과 결과 비교

마주친 문제

1. CTE 동작 안 됨

실습을 진행하기 위해서는 DB에 대량에 데이터가 필요했고 CTE를 사용해서 sql을 만들어 init.sql을 구정했다. 하지만 CTE 사용에서 에러가 발생했다. MySQL 8.0 신기술 CTE

<문제 내용> WITH RECURSIVE CTE를 이용하여 30만 개 숫자를 생성하는 과정에서 발생 ERROR 1137 (HY000): Can't reopen table: 'd4'

<문제 원인>

1. MySQL이 CTE를 “재사용 가능 데이터셋"으로 보지 않는 구조이지만 임시 테이블이라고 생각하고 사용하였다. (MySQL에서 CTE를 "쿼리 구조를 단순화하는 도구"로만 사용할 것을 권장한다)
2. CTE가 INSERT 대상 테이블과 충돌,INSERT … SELECT 구문 안에서 CTE가 동시에 참조되면 MySQL은 동일한 CTE를 2번 오픈하려다 실패함. [에러 sql] ``` sql

-- 실행 중 MySQL이 내부적으로 CTE를 두 번 읽으려 할 때, -- "Can't reopen table" 오류가 발생함 WITH RECURSIVE customer_seq AS ( SELECT 0 AS id UNION ALL SELECT id + 1 FROM customer_seq WHERE id + 1 < @customer_target )

INSERT INTO customer_seq SELECT ... FROM customer_seq;

**<문제 해결>**
재귀 CTE를 완전히 제거하고 숫자 생성 TEMP TABLE 방식으로 모두 교체
``` sql
CREATE TEMPORARY TABLE seq_100k (id INT PRIMARY KEY);

INSERT INTO seq_100k (id)
SELECT a.N + b.N * 1000 AS id
FROM 
    (SELECT @row1:=@row1+1 AS N FROM information_schema.columns, (SELECT @row1:= -1) r LIMIT 1000) a,
    (SELECT @row2:=@row2+1 AS N FROM information_schema.columns, (SELECT @row2:= -1) r LIMIT 100) b
LIMIT 100000;

2. 조회시 범위 지정

<문제 내용> city와 created_at에 복합 인덱스가 있음에도 불구하고, IGNORE INDEX를 통한 full scan에 총 응답 시간이 range보다 빠른 것을 확인

-- 문제의 쿼리 1: 인덱스 사용 (하지만 더 느림)
-- Total Time: 380 ms
SELECT *
FROM customers
WHERE city = 'Seoul'
  AND created_at BETWEEN '2024-01-01' AND '2024-12-31';

-- 문제의 쿼리 2: 인덱스 무시 (하지만 더 빠름)
-- Total Time: 155 ms
SELECT *
FROM customers IGNORE INDEX (idx_customers_city_created_at)
WHERE city = 'Seoul'
  AND created_at BETWEEN '2024-01-01' AND '2024-12-31';

<문제 원인>

1. 조회한 데이터가 많음 EXPLAIN을 통해 확인한 결과, 옵티마이저는 인덱스를 사용했지만(type: range) 조건에 해당하는 데이터가 약 2,000건 이상으로 많았다.
2. Bookmark Lookup 사용 SELECT * 때문에, 1번에서 찾은 2,000여 개의 PRIMARY KEY를 가지고 실제 테이블에 2,000번 접근하여 나머지 컬럼(id, name, email 등)을 가져왔다.

이 2개 과정에서 발생하는 대량의 Random I/O 비용이 테이블 전체를 순차적으로 읽는 Sequential I/O 비용보다 더 컸기 때문에 성능 역전 현상이 발생한 것이었다. <문제 해결> "커버링 인덱스"로 성능 극대화로 해결 Covering Index로 쿼리 성능 개선하기

-- AS-IS: 모든 컬럼 조회
SELECT * FROM customers ...

-- TO-BE: 필요한 컬럼만 명시
SELECT id, name, email, city, created_at FROM customers 

--------------------------------------------------------

-- AS-IS: 기존 인덱스
 INDEX idx_customers_city_created_at (city, created_at)

-- TO-BE: 커버링 인덱스
CREATE INDEX idx_customers_cover ON customers (city, created_at, id, name, email);

적용 후, EXPLAIN 결과의 Extra 필드에 Using index가 표시되었고 fetching 시간이 줄며 index를 사용한 조회가 더 효율적인 것을 실험하였다.

SELECT SQL_NO_CACHE id, name, email, city, created_at
             FROM customers
             WHERE city = 'Seoul'
               AND created_at BETWEEN '2025-10-01' AND '2025-10-02 23:59:59'
             LIMIT 10
10 rows retrieved starting from 1 in 156 ms (execution: 35 ms, fetching: 121 ms)

SELECT SQL_NO_CACHE id, name, email, city, created_at
             FROM customers IGNORE INDEX (idx_customers_cover)
             WHERE city = 'Seoul'
               AND created_at BETWEEN '2025-10-01' AND '2025-10-02 23:59:59'
             LIMIT 10
 10 rows retrieved starting from 1 in 227 ms (execution: 18 ms, fetching: 209 ms)

느낀점

index가 당연히 빠를거라고 간다하게 실습한 내용인데 잘못된 index 적용으로 full scan이 더 빠른 결과를 보게 되었다. 개발자의 실수가 이렇게 치명적일 수 있구나 다시 한 번 느끼게 되었고 테스트 하지 않았다면 잘못을 몰랐을 거라는 것에 테스트에 중요성을 더욱 더 깨닮게 되었다.

참고한 자료

망나니 개발자

구름 부트캠프후 모여행 프로젝트를 출시까지 진행하자고 팀원들이 모이게 되었고 함께 출시하기전 기획을 재정비하는 동안 인증/인가에서 개선 사항을 찾고 정리한 글이다.

개선 사항

1. 회원 탈퇴 기능

• *현황: * 회원 탈퇴 기능 부재
• *개선 제안: *
  1. Oauth 탈퇴 포함
  2. soft delete 사용

2. 게스트 초대 기능 URL 사용으로 변경

• *현황: * 불안정
• *개선 제안: *
  1. 링크 공유로 변경 요청 참고자료
  2. URL path를 어떻게 할지 의논 필요

3. admin 인증/인가 필요

• *현황: * admin 관려된 기능이 추가될 수 있기에 필요
• *개선 제안: *
  1. admin 계정 생성 개수 제한 또는 관리자가 직접 생성만 가능
  2. IP 또는 이메일 인증으로 보안 강화

4. refreshToken 탈취시 보안 정책

• *현황: * refreshToken을 read only로 cookie에 저장 중,
• *개선 제안: *
  1. Dpop 설계: 참고링크

Spring security를 다시 공부하다가 <모영행> 프로젝트의 인증/인가 로직에 문제가 없는지 확인하는 중에 UserDetails를 Authentication 객체 저장하고 @AuthenticationPrincipal를 이용해서 사용했는데 이 방법이 표준에 부합하고 효율적인 방법이었는지 의문이 들게 되어 글을 작성하게 되었다. (JWT를 사용하여 세션/폼을 사용하지 않았다.)

분석

Spring Security 인증 흐름 (표준 Ver.)

먼저, 정석적인 Spring Security의 인증 흐름이 무엇인지 보겠다. (JWT가 아닌 세션/폼 로그인 기준)

1. 사용자가 아이디/비밀번호를 Form으로 전송
2. AuthenticationFilter가 UsernamePasswordAuthenticationToken을 생성해 AuthenticationManager에게 전달 (이때 토큰의 principal은 사용자가 입력한 아이디(String))
3. AuthenticationManager는 등록된 AuthenticationProvider에게 인증 위임
4. AuthenticationProvider는 UserDetailsService를 통해 DB에서 사용자 정보 조회 (loadUserByUsername())
5. UserDetailsService는 조회된 정보를 바탕으로 UserDetails 객체를 생성후 반환
6. AuthenticationProvider는 반환된 UserDetails와 입력된 비밀번호를 비교하여 인증에 성공하면, '인증된' UsernamePasswordAuthenticationToken을 새로 생성 AuthenticationManager에게 돌려줌
7. AuthenticationManager는 이 토큰을 AuthenticationFilter로 반환
8. AuthenticationFilter는 최종적으로 인증된 토큰을 SecurityContextHolder에 저장

🤔사실 이 부분에서 궁금증이 시작되었다. 5번에서 UserDetails를 만들었는데, 8번에서는 Authentication 토큰을 저장합니다. UserDetails를 저장하는 방식은 잘못된건가?

의문의 답: Authentication 객체의 구조

답은 6번 단계에서 새로 생성되는 '인증된' Authentication 객체의 구조에 있었다. Authentication 인터페이스의 정의를 보면 내부에 인증의 주체, 즉 사용자 정보(Principal)를 담을 수 있는 getPrincipal() 메서드를 가지고 있고 Spring Security는 인증에 성공하면, UserDetailsService가 반환한 바로 그 UserDetails 객체를 이 principal 필드에 담아서 새로운 Authentication 객체를 만드는 것이었다.

public interface Authentication extends Principal, Serializable {
    // ... 다른 메서드들 ...

    // ⭐⭐⭐ 바로 이 녀석! ⭐⭐⭐
    // 이 인증의 주체(Principal)는 누구인가?
    Object getPrincipal();
}

// 6번 단계에서 일어나는 일 (개념적인 코드)
UserDetails userDetails = userDetailsService.loadUserByUsername(username);

// 비밀번호 검증 후...

// '인증된' 토큰을 새로 생성한다!
// 첫 번째 인자(principal)로 userDetails 객체를 넣어준다.
Authentication authenticatedToken = new UsernamePasswordAuthenticationToken(
    userDetails, // ⭐ 여기에 UserDetails가 쏙!
    null,        // 더 이상 비밀번호는 필요 없으므로 null 처리
    userDetails.getAuthorities() // 권한 정보
);

결국 SecurityContextHolder에 저장되는 것은 Authentication 객체가 맞지만, 그 객체는 principal이라는 이름으로 UserDetails를 품고 있는 것이다.

@AuthenticationPrincipal은 어떻게 동작하는가?

컨트롤러에서 사용한 @AuthenticationPrincipal은 어떻게 UserDetails를 바로 꺼내주는 걸까? ❓

@AuthenticationPrincipal CustomUserDetails userDetails

이 어노테이션은 Spring이 자동으로 처리해주는 '편의 기능(Syntactic Sugar)' 이다.

1. SecurityContextHolder에서 현재 스레드의 SecurityContext를 가져온다. (.getContext())
2. SecurityContext에서 Authentication 객체를 꺼낸다. (.getAuthentication())
3. Authentication 객체에서 Principal 객체를 꺼낸다. (.getPrincipal())
4. 꺼내온 Principal 객체를 파라미터에 선언된 CustomUserDetails 타입으로 안전하게 형변환하여 주입해준다.

이 모든 과정을 어노테이션 하나로 압축했기 때문에, 마치 UserDetails가 SecurityContext에 직접 저장된 것처럼 느꼈고 의문을 제기하게 되었다.

결론

• SecurityContextHolder는 Authentication 객체를 저장한다.
• 인증된 Authentication 객체는 principal 필드에 UserDetails 객체를 품고 있다.
• @AuthenticationPrincipal은 Authentication 객체 속 UserDetails를 편리하게 꺼내주는 마법 같은 어노테이션이다.

참고자료

• https://jeonyoungho.github.io/posts/Spring-Security-%EA%B0%9C%EC%9A%94-%EB%B0%8F-%EB%8F%99%EC%9E%91%EA%B3%BC%EC%A0%95/

• https://wildeveloperetrain.tistory.com/324

• https://www.inflearn.com/community/questions/937560/authenticationprincipal-%EC%82%AC%EC%9A%A9%EC%9D%B4-%EA%B0%80%EB%8A%A5%ED%95%9C-%EC%9D%B4%EC%9C%A0%EA%B0%80?srsltid=AfmBOoqp0WlaTJD5iXzRHwkivhhtC7t2F6VgWfQby79G6JrkByCBbgci

• https://velog.io/@yuureru/Spring-Security-%EB%8F%99%EC%9E%91%EA%B3%BC%EC%A0%95-%EA%B5%AC%EC%A1%B0

• 현황: 구름 딥다이브 3차 동료들과 사이드 프로젝트를 진행 중입니다.
• 기존 문제: 기존에 사용하던 CodeRabbit은 생성하는 리뷰 코멘트의 양이 많아 가독성이 저해되고 피로도가 높다는 의견이 있었습니다.
• 대안 검토: 다른 팀이 사용 중인 Gemini Code Assist는 리뷰가 비교적 짧고 간결하다는 정보를 얻었습니다.
• 목표: 팀 차원에서 최적의 AI 리뷰어를 선택하기 위해 두 도구를 비교 분석합니다.

AI 코드 리뷰어 소개

Gemini Code Assist

개발 주체

• Google (구글)
• 공식 문서 바로가기

AI 모델

• Gemini 2.5 (최신 Gemini 계열 LLM, 구글 파운데이션 모델)

동작 방식

1. 컨텍스트 수집: PR 변경 내역(diff), 제목·설명, 프로젝트 관련 파일 등을 선별적으로 수집, 1M 토큰 내 컨텍스트 구성
2. AI 분석 및 피드백 생성: Gemini 모델이 코드 품질, 보안, 성능, 스타일을 점검.
3. 결과 출력 (Output to PR): 요약 및 인라인 코멘트를 PR에 자동 게시.

학습 데이터 (공식적으로 공개된 범위)

• 공개 GitHub 코드 일부
• Google 내부 기술 문서, Google Cloud 관련 자료
• 사용자가 설치 시 허용한 저장소 코드(프로젝트 코드)

🔍 근거: Gemini Code Assist 문서에 “codebase awareness up to 1M tokens” 및 “custom style guides 적용 가능” 명시됨.
출처: developers.google.com, blog.google

특징 & 장점

• 대규모 컨텍스트: 최대 약 1,000,000 토큰 컨텍스트 윈도우 활용 (무료 버전<개인용>은 128,000 토큰).
• 실시간 코드 보조: 오류 탐지, 함수 제안, 테스트/디버깅 지원.
• 보안·컴플라이언스: Google Cloud 기반 엔터프라이즈 보안 체계 제공.

운영 현황 (2025년 10월 기준)

• AI PR 리뷰 분야 3위
• Google Cloud, Android Studio 기반 개발팀에서 주로 사용 추정

CodeRabbit

개발 주체

• CodeRabbit Inc.
• 오픈소스 저장소 바로가기

AI 모델

• 최신 LLM(대규모 언어 모델) 기반
• 구체적 모델명은 비공개 (최신 GPT 계열 추정)
• 공식 문서 참고

동작 방식

1. 컨텍스트 엔지니어링: 맥락 및 프로젝트 구조 전반 수집
2. 코드 그래프 분석: 시스템 전체 연결·의존성 파악
3. 리뷰 에이전트: AI가 리뷰 코멘트 및 개선안 생성
4. 검증 에이전트: 노이즈 제거, 실제 반영 가능한 제안만 필터링
5. 결과 출력 (Output to PR): 최종 리뷰를 PR에 자동 등록

학습 데이터

• 공개 GitHub 코드
• 자체 플랫폼에서 수집된 코드 리뷰 데이터
• 사용자 프로젝트 코드 (레포를 샌드박스에 복제 후 분석)

🔍 근거: CodeRabbit 공식 문서에서 “sandboxed repository clone” 및 “integrated linters/SAST” 언급.
출처: docs.coderabbit.ai

특징 & 장점

• 컨텍스트 엔지니어링 기반 정밀 분석
• 린터·SAST 결과 반영 → 구조화된 보안 점검 가능
• 자동 생성 다이어그램 제공 (코드 관계 시각화)
• “샌드박스 환경”에서 코드 실행 후 리뷰 제공

운영 현황 (2025년 10월 기준)

• AI PR 리뷰 분야 1위
• 2025년 1월 보안 사고 발생 (현재 취약점 수정 완료)
• 다양한 스타트업·팀에서 활발히 사용 중

비교 요약

가격 비교는 제외했음. (사이드 프로젝트에서는 무료 버전 사용 예정)

사용 후기

조사하면서 흥미로웠던 점은, 일부 글에서 Gemini code assist무료 버전(개인용)은 128,000 토큰으로 제공한다는 것이다. 하지만 사이드 프로젝트에서는 큰 제약이 되지 않으므로 문제 없다고 판단했다.

사용 후기 사이트

Gemini Code Assist

• Gemini Code Assist Review: Code Completions Need Improvement (The New Stack)
• Gemini Code Assist: AI 코딩 도구로 생산성을 극대화하는 법 (Tistory 블로그)
• Gemini Code Assist 기능 및 요금제 안내 (TILNote)

CodeRabbit

• AI 코드 리뷰 도구 CodeRabbit 사용 후기 및 장단점 분석 (APIDog)
• CodeRabbit: Code review GitHub PRs with GPT-4 (Reddit)
• 최고의 Flutter AI PR Reviewer를 찾아서 (Tistory 블로그)

추가 비교 (사용 후기 요약)

• 코멘트 길이/양

  • Gemini: 간결하고 요점 집중 → 협업 시 가독성 좋음
  • CodeRabbit: 리뷰가 많고 세밀 → 도움이 되지만 피로감 유발

• 정확성/품질

  • Gemini: 전반적으로 무난, 일부 누락 있음
  • CodeRabbit: 꼼꼼하고 정밀, 품질 일관

• 특화 기능

  • Gemini: Google Cloud·Android 생태계 연동, 대규모 컨텍스트 처리
  • CodeRabbit: 다이어그램/그래프 제공, 고도화된 SAST/린터 통합

• 협업/속도

  • Gemini: 빠른 반영, 개인·팀 환경에 부드럽게 연동
  • CodeRabbit: 즉각 리뷰 제공, 협업 최적화

• 단점

  • Gemini: 일부 답변 누락, 세밀한 이슈 캐치는 부족
  • CodeRabbit: 정보량 과다, 초기 셋팅 오류, 과거 보안 취약점 이력

결론

기존에 사용하던 CodeRabbit은 리뷰가 과도하게 많아 불편함이 있었고, 이 때문에 Gemini를 고려하게 되었다. 조사 과정에서 알게 된 점은 CodeRabbit은 자체 리뷰를 다른 AI로 재검증하지만, Gemini는 그렇지 않다는 것이다. 아마 이 차이가 리뷰 양의 차이를 만드는 원인일 것이다.

아직 어떤 도구를 선택해야 할지는 확신이 서지 않는다. 두 서비스 모두 훌륭하다.
개인적으로는 CodeRabbit을 선호한다. 다이어그램 제공 덕분에 팀원이 코드를 이해하는 데 도움이 되고, 과도한 리뷰를 통해 오히려 놓칠 수 있는 부분을 되돌아보게 만들기 때문이다.

참고자료

• [전문가 기고] 'AI 기반 코드 리뷰'를 혁신하는 컨텍스트 엔지니어링의 비밀
• 커서/코드레빗 개발팀이 말하는 AI 코딩 도구 잘 쓰는 법
• AI 코드 리뷰 도구 CodeRabbit에서 발견된 치명적 보안 취약점과 그 해결 과정

이 문서는 왜 성능 테스트 툴로 k6를 선택 했는지와 성능 테스가 무엇인지 기술한 글 입니다.

성능 테스트란?

성능 테스트 정의

성능 테스트(Performance Testing)는 소프트웨어나 시스템이 특정 작업 부하에서 얼마나 빠르게, 그리고 안정적으로 동작하는지를 평가하는 모든 테스트 활동을 총칭합니다. 단순히 기능이 올바르게 작동하는지를 확인하는 것을 넘어, 시스템의 속도, 확장성, 안정성을 측정하는 것이 핵심 (광범위하게 사용되기에 성능 테스트 범위와 함께 설명)

성능 테스트의 범위

성능 테스트는 단순히 시스템의 '속도'만 측정하는 것이 아니라, 다양한 측면에서 시스템의 한계와 효율성을 평가합니다. 대표적인 테스트 유형은 다음과 같습니다.

부하 테스트(Load Testing): 시스템이 예상되는 정상적인 사용자 수와 트랜잭션 양을 처리할 수 있는지 확인합니다. 예를 들어, 웹사이트에 동시에 1,000명의 사용자가 접속했을 때 응답 시간이 적절한지 테스트합니다.

스트레스 테스트(Stress Testing): 시스템이 최대 부하 용량을 초과하는 비정상적인 상황에서 어떻게 동작하는지 확인합니다. 시스템이 갑작스러운 트래픽 폭증에 무너지지 않고, 복구 능력을 갖추고 있는지 검증합니다.

내구성 테스트(Endurance Testing): 시스템이 장시간 동안 지속적인 부하를 견딜 수 있는지 확인합니다. 메모리 누수나 성능 저하 없이 안정적으로 운영되는지 테스트합니다.

볼륨 테스트(Volume Testing): 대량의 데이터(데이터베이스, 파일 등)를 처리할 때 시스템의 성능 저하가 발생하는지 확인합니다.

성능테스트 지표와 예시

응답 시간(Response Time): 사용자가 요청을 보낸 시점부터 응답을 받기까지 걸리는 시간

예시: "상품 구매" 요청에 대한 평균 응답 시간은 5초, 이는 사용자가 상품을 구매하기 위해 5초를 기다려야 한다는 의미로, 사용자 경험이 부정적이라는 것을 유추할 수 있습니다.

TPS (Transactions Per Second): 시스템이 1초 동안 처리할 수 있는 트랜잭션(요청)의 수

예시: 초당 100건의 구매 요청을 처리할 수 있는 시스템있고 만약 이벤트로 인해 초당 200건의 요청이 몰리면, 시스템은 정상적으로 처리하지 못하고 응답 시간이 지연되거나 오류가 발생할거라고 예측 가능합니다.

오류율(Error Rate): 테스트 도중 발생하는 오류의 비율

예시: 부하가 증가함에 따라 오류율이 5%로 상승했습니다. 이는 과부하 상황에서 시스템의 안정성이 저하되어 요청을 제대로 처리하지 못하고 있다는 것을 의미합니다.

CPU/메모리 사용량: 시스템 자원(CPU, 메모리)의 사용률

예시: 동시 접속자 수가 500명을 초과하자, CPU 사용량이 90%까지 치솟는다면 이는 시스템이 처리할 수 있는 부하의 한계에 도달했음을 보여주는 병목 지표입니다.

동시 사용자 수(Concurrent Users): 시스템이 성능 저하 없이 동시에 처리할 수 있는 최대 사용자 수

예시: A 시스템은 1,000명의 동시 사용자까지는 응답 시간 2초 이내를 유지하지만, 1,200명이 접속하는 순간부터 응답 시간이 급격히 늘어납니다.

성능 테스트의 중요성

1. 사용자 경험(UX) 증진 및 이탈률 감소 대표적으러 2초의 법칙과 3초의 마지노선 이론에 따르면 사용자는 웹페이지 이용시 2~3초라는 시간이 지나면 시비스 이탈률이 급격히 증가한다고 합니다. 성능 테스트는 이러한 잠재적 문제를 사전에 파악하고 해결하여, 사용자들이 빠르고 쾌적한 환경에서 서비스를 이용할 것이라고 예측할 수 있도록 도와줍니다.

2. 비즈니스 손실 예방 예측하지 못한 트래픽 폭증으로 시스템이 마비 또는 지연된다면, 그 기간 동안의 모든 비즈니스 활동(예: 온라인 판매, 서비스 제공)이 중단됩니다. 이는 곧바로 매출 손실, 기업 이미지 실추, 그리고 고객 신뢰도 하락으로 이어집니다. 성능 테스트는 시스템의 한계점을 미리 파악하고, 잠재적인 위험 상황에 대비하여 비즈니스 연속성을 확보할 수 있도록 도와줍니다.

3. 시스템의 안정성과 확장성 확보 성능 테스트를 통해 얻은 지표(CPU/메모리 사용량, 오류율 등)는 시스템의 병목 현상과 잠재적 오류를 발견하는 데 도움을 줍니다. 이러한 데이터를 바탕으로 시스템을 최적화하면, 더 적은 자원으로도 더 많은 부하를 효율적으로 처리할 수 있습니다. 이는 비용 효율적인 시스템 운영을 가능하게 하며, 향후 더 많은 사용자를 수용하기 위한 확장 계획을 수립하는데 도움을 줍니다.

성능 테스트 툴

성능 테스트 툴 소개에서 내용을 스크립하였습니다.

Apache JMeter

Apache JMeter는 강력한 성능 테스트 도구로, 다양한 프로토콜을 지원한다.

장점 및 특징

• 다양한 프로토콜 지원: HTTP, HTTPS, FTP, JDBC, JMS, LDAP, SOAP, TCP 등 다양한 프로토콜 지원
• 확장성: 플러그인을 통해 기능을 확장 가능
• 분산 테스트: 여러 머신에서 테스트를 실행하여 부하를 분산할 수 있다.
• 강력한 GUI: 사용자 친화적인 GUI로 테스트 계획을 쉽게 작성할 수 있다.
• 스크립트 지원: BeanShell, Groovy 등의 스크립트를 사용하여 복잡한 테스트 시나리오를 작성할 수 있다.

단점

• 고사양 요구: 많은 리소스를 소모하므로 고사양의 하드웨어가 필요할 수 있다.
• 복잡한 설정: 고급 기능을 사용하려면 복잡한 설정과 스크립팅이 필요할 수 있다.
• 실시간 모니터링 제약: 실시간으로 대규모 테스트를 모니터링하는 데 제약이 있을 수 있다. 러닝 커브 (기본적인 사용은 쉽지만, 고급 기능을 익히는 데는 시간이 필요함)

Gatling

실시간 그래프와 함께 상세한 보고서를 제공하는 유료 성능 테스트 도구 (JDK 8 이상이 요구)

장점

• 고성능: 비동기 방식으로 많은 사용자 요청을 처리할 수 있다.
• 확장성: Scala를 기반으로 스크립트를 작성하여 복잡한 테스트 시나리오를 구현할 수 있다.
• 실시간 보고: 테스트 진행 중 실시간으로 성능 지표를 모니터링할 수 있다.
• 자동 보고서 생성: 테스트가 끝나면 상세한 HTML 보고서를 자동으로 생성한다.
• DevOps 친화적: 코드로 시나리오를 작성하기 때문에 버전 관리 시스템과 CI/CD 파이프라인에 통합이 용이

단점

• 유료 정책
• 러닝 커브: Scala 언어에 익숙하지 않은 사용자는 시나리오 작성이 어려울 수 있다.
• 복잡한 설정: 고급 기능을 사용하기 위해서는 복잡한 설정과 코드 작성이 필요할 수 있다.
• 자원 요구: 대규모 테스트를 실행할 때는 높은 하드웨어 자원이 필요할 수 있다.

K6

성능 테스트 스크립트를 작성하고 실행할 수 있는 오픈 소스 도구

장점

• CLI 도구: 커맨드 라인 인터페이스(CLI)를 통해 쉽게 테스트를 실행하고 결과를 확인할 수 있다.
• 고성능: 단일 프로세스로 수천 개의 가상 사용자를 처리할 수 있다.
• 확장성: Grafana와 같은 모니터링 도구와 쉽게 통합할 수 있다.
• DevOps 친화적: CI/CD 파이프라인에 통합하여 자동화된 테스트 환경을 구축하기 용이하다.
• 경량화: 비교적 가벼운 도구로, 빠르고 간편하게 성능 테스트를 수행할 수 있다.

단점

• 고급 기능 한계: JMeter나 Gatling에 비해 고급 기능이 부족할 수 있다.
• 제한된 프로토콜 지원: HTTP/HTTPS 프로토콜 위주로 지원 다양한 프로토콜을 필요로 하는 경우 한계가 있을 수 있다.
• 러닝 커브: JavaScript에 익숙하지 않은 사용자는 초기 학습이 필요할 수 있다.

Locust

장점

• 실시간 피드백: 웹 인터페이스에서 실시간으로 결과를 확인할 수 있어 테스트 진행 상황을 쉽게 모니터링할 수 있다.
• 확장성: 분산 로드를 통해 대규모 부하 테스트가 가능하다.
• 커스터마이즈 가능: Python의 강력한 기능을 활용하여 복잡한 시나리오를 쉽게 작성할 수 있다.
• 경량화: 간편한 설치와 사용으로 빠르게 테스트를 시작할 수 있다.

단점

• 고급 기능 한계: JMeter와 같은 도구에 비해 고급 기능이 부족할 수 있다. 성능 제한: 대규모 테스트에서는 성능 제한이 있을 수 있으며, 분산 로드를 필요로 할 수 있다. Python 의존성: Python에 익숙하지 않은 사용자는 초기 학습이 필요할 수 있다.

k6를 선택한 이유

테스트 툴 희망조건

1. 가볍운 성능 (로컬에서 돌리기 위해서)
2. 직관적인 사용 방법
3. 테스트 방법과 결과 공유가 간편한 것
4. 학습 곡선이 낮을 것

k6를 선택한 이유

1. 가벼운 성능 (로컬 테스트): K6는 Go 언어로 개발되어 매우 경량화되어 있고, 다른 툴들 많은 자원을 소모하는 것과 달리, K6는 비교적 적은 리소스로 테스트 가능 합니다.

(grafana) Comparing k6 and JMeter for load testing 에서 제공한 결과입니다. 표와 같이 K6는 비교했던 테스트 툴들에 비해서 메모리 사용량이 적으면서 RTS가 많은 것을 볼 수 있습니다. RTS: Requests Per Second는 '초당 요청 수'를 의미합니다. 즉, 1초 동안 시스템이 처리할 수 있는 요청의 수를 나타내는 성능 지표

2. 직관적인 사용 방법 및 쉬운 공유: K6는 CLI 기반의 도구로, 복잡한 GUI 없이 명령어를 통해 테스트를 실행하고 결과를 즉시 확인할 수 있습니다. 테스트 결과를 JSON 형태로 출력할 수 있어, 이를 Jira나 Confluence 같은 협업 도구에 쉽게 첨부하여 팀원들과의 공유를 간편하게 만들 수 있습니다.

3. 낮은 학습 곡선: K6는 자바스크립트(JavaScript) 기반으로 스크립트를 작성합니다. 이는 대다수의 웹 개발자에게 익숙한 언어이므로, 별도의 언어 학습(예: Gatling의 Scala, Locust의 Python) 없이도 팀원들이 빠르게 테스트 스크립트를 작성하고 유지보수할 수 있습니다. 이는 테스트 도입의 초기 장벽을 크게 낮춥니다.

결론

성능 테스트는 개발의 마지막 단계에서 시스템의 안정성과 비즈니스 가치를 최종적으로 검증하는 중요한 절차입니다. <모여행>은 모든 기능 구현 이후, 최종적인 시스템의 완성도를 높이기 위해 k6를 활용하여 아래 3가지를 목표를 수행하여 더 좋은 서비스를 개발하겠습니다.

초기 목표: MVP 기능(항공권 검색/예매)에 대해 응답 시간 3초 이내, 오류율 1% 미만을 목표로 부하 테스트를 진행하겠습니다.

테스트 자동화: 향후 CI/CD 파이프라인에 K6를 연동하여 코드 배포 시마다 자동으로 성능 회귀 테스트를 수행하도록 하겠습니다.

지속적 관리: Grafana와 연동하여 주요 지표를 지속적으로 모니터링하고, 성능 저하가 감지될 경우 선제적으로 대응하겠습니다.

참고 자료

(velog) 성능테스트 툴 소개

(velog)Spring Boot로 K6 & Grafana를 활용한 부하테스트 해보기

(f-lab) 성능 테스트의 중요성과 목적 그리고 효과

(f-lab) 성능 테스트 중요성

(kakao-tech) 실시간 메시징 시스템 개발 - “성능 테스트 설계와 분석”

성능테스트 (부하테스트 도구 비교) - jmeter, k6, ngrinder, locust https://web.dev/case-studies/t-mobile-case-study?hl=en

https://loosie.tistory.com/821

https://www.mabl.com/articles/what-is-performance-testing

개요

이 문서는 모여행 백엔드 프로젝트의 테스트 전략을 정의합니다. 우리의 목표는 높은 품질의 코드를 유지하고, 버그를 조기에 발견하며, 리팩토링을 자신있게 수행할 수 있는 환경을 만드는 것입니다.

테스트의 중요성

• 코드 품질 보장
• 버그 조기 발견
• 안전한 리팩토링 지원
• 문서화 역할
• 설계 개선 유도

테스트 환경

기술 스택

• 테스트 프레임워크: JUnit 5
• 통합 테스트 도구: Testcontainers
• 목킹 프레임워크: Mockito
• API 테스트: REST Assured
• 로컬 개발 환경: Docker Compose
• CI/CD: GitHub Actions

테스트 계층

1. 서비스 계층 테스트

1.1 단위 테스트 (Unit Tests)

• 대상: Service 클래스의 개별 메서드
• 도구: JUnit 5, Mockito
• 특징:
  • Repository와 외부 의존성을 Mock 처리
  • 복잡한 비즈니스 로직 검증에 집중
  • 빠른 실행 속도로 즉각적인 피드백

// 서비스 단위 테스트 예시
@ExtendWith(MockitoExtension.class)
class TravelServiceTest {
    @Mock
    private TravelRepository travelRepository;

    @InjectMocks
    private TravelService travelService;

    @Test
    void 여행_일정_생성_단위테스트() {
        // given
        TravelPlanRequest request = new TravelPlanRequest(...);
        when(travelRepository.save(any())).thenReturn(...);

        // when
        TravelPlanResponse response = travelService.createPlan(request);

        // then
        assertThat(response).isNotNull();
        verify(travelRepository, times(1)).save(any());
    }
}

1.2 서비스 통합 테스트 (Service Integration Tests)

• 대상: Service와 Repository 간의 상호작용
• 도구: JUnit 5, TestContainers, Spring Boot Test
• 특징:
  • 실제 데이터베이스 사용 (TestContainers)
  • Repository 계층과의 결합 테스트
  • 복잡한 쿼리나 트랜잭션 검증

// 서비스 통합 테스트 예시
@SpringBootTest
@Testcontainers
class TravelServiceIntegrationTest {
    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:14");

    @Autowired
    private TravelService travelService;

    @Autowired
    private TravelRepository travelRepository;

    @Test
    void 여행_일정_저장_및_조회_통합테스트() {
        // given
        TravelPlanRequest request = new TravelPlanRequest(...);

        // when
        TravelPlanResponse created = travelService.createPlan(request);
        Travel found = travelRepository.findById(created.getId()).orElseThrow();

        // then
        assertThat(found.getTitle()).isEqualTo(request.getTitle());
        // 복잡한 비즈니스 규칙이나 DB 상태 검증
    }
}

2. API 엔드포인트 테스트 (End-to-End Tests)

• 대상: REST API 엔드포인트
• 도구: TestContainers, Spring Boot Test, REST Assured
• 특징:
  • 실제 애플리케이션 환경에서 전체 플로우 테스트
  • HTTP 요청/응답 검증
  • 실제 데이터베이스 사용
  • 보안, 인증/인가 포함한 전체 시나리오 검증

// API 엔드포인트 테스트 예시
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@Testcontainers
class TravelApiTest {
    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:14");

    @LocalServerPort
    private Integer port;

    @Autowired
    private TravelRepository travelRepository; // 테스트 데이터 준비 및 검증용

    @Test
    void 여행_일정_생성_API_테스트() {
        // given
        TravelPlanRequest request = new TravelPlanRequest(...);

        // when-then
        String travelId = given()
            .contentType(ContentType.JSON)
            .body(request)
        .when()
            .post("/api/v1/travels")
        .then()
            .statusCode(200)
            .extract().jsonPath().getString("id");

        // 데이터베이스 상태 검증
        Travel savedTravel = travelRepository.findById(travelId).orElseThrow();
        assertThat(savedTravel.getTitle()).isEqualTo(request.getTitle());
    }
}

• 시나리오 기반 테스트

테스트 전략 가이드

1. 서비스 계층 테스트 전략

단위 테스트 vs 통합 테스트 선택 기준

단위 테스트를 사용하는 경우:

• 단순한 CRUD 연산
• 단일 Repository에만 의존하는 로직
• 비즈니스 규칙 검증이 주목적인 경우

// 단위 테스트 예시: 단순 CRUD
@Test
void 여행_일정_상태_변경_테스트() {
    when(travelRepository.findById(any())).thenReturn(Optional.of(travel));
    travelService.updateTravelStatus(id, TravelStatus.COMPLETED);
    verify(travelRepository).save(travelCaptor.capture());
    assertThat(travelCaptor.getValue().getStatus()).isEqualTo(TravelStatus.COMPLETED);
}

통합 테스트를 사용하는 경우:

• 복수의 Repository 사용 (예: 여행과 참가자 동시 처리)
• 복잡한 조회 쿼리와 조인
• 트랜잭션 처리 검증 필요

// 통합 테스트 예시: 복합 연산
@Test
void 여행_참가자_추가_및_인원수_검증() {
    // given
    Travel travel = travelRepository.save(new Travel("...", 5)); // 최대 5명

    // when
    travelService.addParticipant(travel.getId(), participant);

    // then
    Travel updated = travelRepository.findWithParticipants(travel.getId());
    assertThat(updated.getParticipants()).hasSize(1);

    // 추가 참가자 5명 등록 시도
    assertThrows(TravelFullException.class, () -> {
        for (int i = 0; i < 5; i++) {
            travelService.addParticipant(travel.getId(), new Participant());
        }
    });
}

2. API 테스트 전략

테스트 시나리오 구성

• 단순 API 호출이 아닌 실제 사용자 시나리오 기반
• 인증/인가 포함
• 데이터베이스 상태 검증

// 시나리오 기반 API 테스트 예시
@Test
void 여행_일정_생성_및_참가자_추가_시나리오() {
    // 1. 여행 일정 생성
    String travelId = given()
        .header("Authorization", "Bearer " + hostToken)
        .contentType(ContentType.JSON)
        .body(travelRequest)
    .when()
        .post("/api/v1/travels")
    .then()
        .statusCode(200)
        .extract().jsonPath().getString("id");

    // 2. 참가자 추가
    given()
        .header("Authorization", "Bearer " + participantToken)
        .contentType(ContentType.JSON)
    .when()
        .post("/api/v1/travels/" + travelId + "/participants")
    .then()
        .statusCode(200);

    // 3. 데이터베이스 상태 검증
    Travel travel = travelRepository.findWithParticipants(travelId);
    assertThat(travel.getParticipants()).hasSize(1);
    assertThat(travel.getParticipants().get(0).getUserId())
        .isEqualTo(participantUserId);
}
}

## 테스트 구현 가이드라인

### 1. 테스트 케이스 작성 규칙

#### 테스트 클래스 구조
```java
// 예시: 여행 서비스 테스트 구조
class TravelServiceTest {
    @Nested
    class 여행_일정_생성 {
        @Test
        void 정상_경우() { ... }

        @Test
        void 유효하지_않은_데이터_입력시() { ... }
    }

    @Nested
    class 여행_참가자_추가 { ... }
}

테스트 메서드 명명

• 한글 메서드명 허용 (가독성 우선)
• [테스트_시나리오]_[기대_결과] 형식 권장
  • 예: 유효하지_않은_데이터_입력시_예외_발생()

2. 테스트 데이터 관리

테스트 픽스처 사용

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class TravelServiceTest {
    private static final Travel SAMPLE_TRAVEL = Travel.builder()
        .title("제주도 여행")
        .maxParticipants(5)
        .build();

    private static final TravelRequest VALID_REQUEST = TravelRequest.builder()
        .title("제주도 여행")
        .maxParticipants(5)
        .build();
}

테스트 데이터 빌더 패턴

class TestTravelBuilder {
    public static Travel createTravel() {
        return Travel.builder()
            .title("기본 여행")
            .maxParticipants(5)
            .build();
    }

    public static Travel createTravelWithParticipants(int participantCount) {
        Travel travel = createTravel();
        for (int i = 0; i < participantCount; i++) {
            travel.addParticipant(new Participant());
        }
        return travel;
    }
}

3. 예외 처리 테스트

• 예외 상황에 대한 테스트 케이스 필수
• 예외 메시지와 상태 코드 검증

@Test
void 최대_인원_초과_시_예외_발생() {
    // given
    Travel travel = TestTravelBuilder.createTravelWithParticipants(5);
    when(travelRepository.findById(any())).thenReturn(Optional.of(travel));

    // when & then
    assertThrows(TravelFullException.class, () ->
        travelService.addParticipant(travel.getId(), new Participant())
    );
}

• 테스트 메서드: [테스트시나리오_예상결과]
• 한글 메서드명 허용 (가독성이 더 좋은 경우)

2. 테스트 구조

• Given-When-Then 패턴 사용
• 각 섹션을 주석으로 구분
• 테스트 설명은 명확하고 구체적으로

3. 테스트 데이터

• 테스트 픽스처 활용
• 테스트 유틸리티 클래스 구현
• 의미 있는 테스트 데이터 사용

4. 모범 사례

• 하나의 테스트는 하나의 동작만 검증
• 불필요한 검증 피하기
• 테스트 간 독립성 유지
• 실패하는 케이스도 반드시 테스트

CI/CD 파이프라인 운영 전략

1. 테스트 실행 및 모니터링

1.1 테스트 레벨별 실행 전략

단위 테스트 (PR 기반)

• 실행 트리거: PR 생성/업데이트
• 목표 실행 시간: 3분 이내
• 실패 시 조치: PR 머지 블록

통합 테스트 (PR 기반)

• 실행 트리거: 메인/개발 브랜치 PR
• 목표 실행 시간: 10분 이내
• 실패 시 조치: PR 머지 블록

E2E 테스트 (일간 실행)

• 실행 주기: 매일 새벽 3시
• 목표 실행 시간: 30분 이내
• 실패 시 조치: 테스트 실패 대응팀 지정 및 긴급 조치 (미확정)

1.2 테스트 실패 대응 체계

실패 유형별 대응 전략

1. 단위 테스트 실패

   • 담당: PR 작성자
   • 조치: 즉시 코드 수정
   • SLA: 4시간 이내 (미확정)

2. 통합 테스트 실패

   • 담당: PR 작성자 + 테스트 담당자
   • 조치: 원인 분석 후 수정
   • SLA: 1일 이내 (미확정)

3. E2E 테스트 실패

   • 담당: 테스트 대응팀 (2인 1팀)
   • 조치: 원인 분석 및 해결 계획 수립
   • SLA: 2일 이내 (미확정)

구름톤 딥다이브에서 PM, PD, FE, BE 총 4개의 직군이 협업하여 5주 동안 프로젝트를 제작하였습니다. 본 문서는 프로젝트의 핵심 기능인 인증/인가 시스템에 대한 기술 명세를 다룹니다.

1. 서비스 소개

여행 계획 서비스의 주요 차별점은 비로그인 사용자도 손쉽게 접근하고 협업할 수 있는 기능입니다. 기존 서비스들의 높은 진입 장벽(필수 회원가입)을 해결하여 즉각적인 협업이 가능한 서비스를 구현하였습니다.

1.1 문제 정의

• 대부분의 여행 계획 서비스들은 로그인한 사용자만 접근 가능
• 여행 계획을 공유하려면 상대방도 회원가입이 필요
• 즉석에서 계획을 보거나 수정하기 어려움

1.2 해결해야 할 문제

• 비로그인 사용자의 접근성 제한
• 불필요한 회원가입으로 인한 사용자 이탈
• 즉각적인 협업의 어려움
• 외부 공유의 번거로움

1.3 개발환경 및 인프라

기술 스택

• Backend Framework: Spring Boot 3.5.4
• Java Version: Java 21
• Database:
  • Primary: MySQL 8.0.42
  • Cache: Redis 7.2
• Security:
  • Spring Security
  • JWT (0.11.5)
• API Documentation:
  • Springdoc OpenAPI (Swagger) 2.8.10
• ORM & Query:
  • Spring Data JPA
  • Querydsl 6.11
• Monitoring:
  • Spring Actuator
  • Prometheus/Micrometer
• Testing:
  • JUnit 5
  • Testcontainers

개발 및 배포 환경

1. 로컬 개발 환경

   • Docker Compose를 활용한 컨테이너 관리
   • MySQL(3306), Redis(6379) 포트 매핑

2. 테스트 환경

   • Testcontainers를 활용한 통합 테스트
   • GitHub Actions CI/CD 파이프라인

3. 모니터링 시스템

   • Actuator 엔드포인트 활용
   • Prometheus 메트릭스 수집

• JWT (JSON Web Token) 0.11.5
• API Documentation: SpringDoc OpenAPI (Swagger) 2.8.10
• ORM:
  • Spring Data JPA
  • Querydsl 6.11
• Monitoring:
  • Spring Actuator
  • Prometheus
• Testing:
  • JUnit
  • Spring Boot Test
  • Testcontainers

인프라 구성

• 컨테이너화: Docker Compose를 통한 로컬 개발 환경 구성
• 데이터베이스 구성:
  • MySQL: 3306 포트
  • Redis: 6379 포트
• CI/CD: GitHub Actions를 통한 자동화된 빌드 및 테스트

2. 설계

2.1 기획 요구사항 분석

1. 세분화된 권한 체계:
   • 총 5개 ROLE [Owner, Member, Traveler, Guest, Viewer]
   • 각 역할별 차등적 권한 부여
2. URL 기반 공유 시스템:
   • 간편한 공유 링크 생성
   • 권한별 차별화된 링크 생성
3. 비로그인 접근 지원:
   • Traveler, Guest 역할은 링크를 통한 비로그인 접근 가능
4. 보안 체계:
   • 초대자가 생성한 링크를 통해서만 접근 가능
   • 링크의 유효성 검증

2.2 권한 체계 상세

2.3 개발자 관점 요구사항

1. 통합된 인증 플로우:
   • 로그인/비로그인 사용자를 위한 단일 인증 흐름
   • 코드 복잡도 최소화
2. Role 기반 접근 제어:
   • 각 API 엔드포인트별 최소 필요 Role 정의
   • Spring Security의 @PreAuthorize 활용
3. 코드 품질:
   • 관심사 분리 원칙 준수
   • 중복 코드 최소화
4. 기술 스택 활용:
   • Spring Security와 JWT의 효율적 통합
   • Redis를 활용한 토큰 관리

2.4 인가(Authorization) 계층

Team 레벨
└── Owner/Member (팀의 모든 프로젝트 접근/편집)
    └── Project 레벨
        └── Traveler (특정 프로젝트 접근/편집)
            └── 외부 접근 레벨
                ├── Guest (읽기/쓰기)
                └── Viewer (읽기 전용)

3. 구현 방식 비교 분석

3.1 게스트 계정 생성 방식

구현 방법

1. 게스트 계정 생성 프로세스

   • 프로젝트 ID와 권한 레벨에 따른 게스트 계정 생성
   • 임시 비밀번호 생성 및 암호화 저장
   • 게스트 계정 메타데이터 (생성 시간, 마지막 접속 등) 기록
   • 초대 이메일 전송 및 접속 정보 전달

2. 권한 관리 시스템

   • Spring Security의 UserDetails 인터페이스 구현
   • 역할 기반 권한 관리 (RBAC) 적용
   • 세션 관리 및 자동 만료 처리

3. 데이터 관리 메커니즘

   • JPA 엔티티 관계 설정 (프로젝트-게스트 매핑)
   • 자동 데이터 정리 (Scheduled 태스크)
   • 사용자 활동 로깅 및 추적

장단점 분석

장점

• 기존 인증 시스템 활용 가능
• 사용자 행동 추적 용이
• 권한 관리 용이
• 세부적인 액세스 컨트롤 가능

단점

• 불필요한 계정 데이터 증가
• 임시 계정 관리 부담
• DB 의존도가 높음
• 스케일링 시 관리 복잡성 증가

보안 강화 방안

1. 계정 보안

   • 정기적인 비밀번호 만료 및 갱신
   • 접속 IP 제한 및 모니터링
   • 비활성 계정 자동 정리

2. 데이터 보호

   • 게스트 데이터 암호화 저장
   • 접근 로그 기록 및 감사
   • 데이터 백업 및 복구 정책

3.2 일회용 토큰 방식

구현 방법

1. 토큰 생성 프로세스

   • 프로젝트 ID, 권한 레벨, 유효기간을 포함한 JWT 토큰 생성
   • 난수화된 토큰 ID 및 서명 추가
   • Redis에 토큰 메타데이터 저장 (사용 횟수, 생성자 정보 등)
   • 초대 URL 생성 및 전송

2. 토큰 검증 시스템

   • Redis에서 토큰 유효성 검사
   • JWT 서명 및 만료 시간 검증
   • 사용 횟수 추적 및 제한 처리

3. 상태 관리 메커니즘

   • Redis TTL을 활용한 자동 만료 처리
   • 토큰 사용 현황 모니터링
   • 비정상 접근 탐지 및 차단

장단점 분석

장점

• 높은 보안성
• 사용 횟수 제한 가능
• 토큰 즉시 무효화 가능
• 세부적인 액세스 컨트롤

단점

• Redis 의존성
• 토큰 관리 복잡성
• 재사용 불가능
• 인프라 운영 비용 증가

보안 강화 방안

1. 토큰 보안

   • 암호화 방식의 정기적 업데이트
   • 이중 인증 옵션 제공
   • 토큰 사용 패턴 분석

2. 시스템 보호

   • Redis 클러스터링 구성
   • 데이터 독립성 보장
   • 재난 복구 전략 수립

3.3 링크 공유 방식 (채택)

구현 방법

1. 링크 생성 프로세스

   • 프로젝트 ID와 권한 레벨(Guest/Viewer)을 포함한 페이로드 생성
   • 시스템 비밀키를 사용하여 페이로드에 대한 HMAC 서명 생성
   • 만료 시간을 포함한 타임스탬프 추가
   • 페이로드, 서명, 타임스탬프를 Base64로 인코딩하여 단일 문자열로 변환

2. 링크 검증 프로세스

   • 수신된 링크를 Base64 디코딩하여 구성 요소 분리
   • 타임스탬프 검사로 만료 여부 확인
   • 시스템 비밀키로 HMAC 서명 재계산하여 위변조 검증
   • 프로젝트 ID와 권한 레벨 추출하여 접근 권한 부여

3. 권한 관리 메커니즘

   • Spring Security의 커스텀 필터를 통해 링크 기반 인증 처리
   • ThreadLocal에 추출된 권한 정보 저장
   • @PreAuthorize 어노테이션으로 각 API 엔드포인트 보호

장단점 분석

장점

• 인프라 의존성 없는 Stateless 방식
• 기존 API 재사용 가능
• 수평적 확장 용이
• 구현 및 유지보수 간편
• 서버 부하 최소화

단점

• 브라우저 히스토리에 노출
• 공유 링크 회수 어려움
• 접근 기록 추적 제한적
• 실시간 권한 변경 어려움

보안 강화 방안

1. 링크 보안

   • 짧은 만료 시간 설정 (기본 24시간)
   • 복잡한 난수를 포함한 URL 생성
   • HTTPS 필수 적용

2. 접근 제어

   • IP 기반 접근 제한
   • 동시 접속 제한
   • 비정상 패턴 감지 및 차단

4. 보안 및 구현 고려사항

4.1 링크 보안

• 만료 시간 설정: 모든 공유 링크에 유효 기간 설정
• 서명 검증: HMAC을 이용한 링크 무결성 검증
• Rate Limiting: IP 기반 접근 제한

4.2 권한 관리 및 구현 상세

1. 권한 관리 원칙

   @PreAuthorize("hasRole('OWNER') or hasRole('MEMBER')")
   @GetMapping("/projects/{projectId}")
   public ProjectResponse getProject(@PathVariable Long projectId) {
       // 프로젝트 조회 로직
   }

2. 계층형 권한 검증

   • Controller: @PreAuthorize 어노테이션
   • Service: Custom SecurityUtil 활용
   • Repository: 연관 관계 기반 검증

3. 인증 필터 처리

   public class JwtAuthenticationFilter extends OncePerRequestFilter {
       @Override
       protected void doFilterInternal(HttpServletRequest request,
           HttpServletResponse response, FilterChain filterChain) {
           // JWT 검증 및 인증 처리
       }
   }

• 감사 로깅: 주요 작업에 대한 로그 기록

4.3 데이터 보안 및 유효성 검증

1. 입력 값 검증

   @Validated
   @RequestBody ProjectCreateRequest request {
       @NotBlank
       @Size(max = 100)
       private String title;
   
       @NotNull
       @Future
       private LocalDateTime startDate;
   }

2. XSS 방지

   • HTML 이스케이프 처리
   • Content-Security-Policy 적용

3. API 요청 유효성

   • Rate Limiting 적용
   • 요청 크기 제한
   • 인증 헤더 검증

5. 결론 및 향후 계획

5.1 핵심 의사결정 사항

1. 링크 공유 방식 채택 이유

   • 높은 확장성과 단순한 아키텍처
   • 최소한의 인프라 의존성
   • 사용자 경험 최적화
   • 비용 효율적인 운영 가능
   • 실시간 모니터링 용이

2. 보안과 편의성의 균형

   • JWT + HMAC 기반의 안전한 서명
   • Actuator + Prometheus를 활용한 실시간 모니터링
   • 세부적인 로깅 및 추적 기능

3. 보안과 편의성의 균형

   • 24시간 제한의 링크 유효기간
   • 권한별 차등적 접근 제어
   • 간편한 공유 프로세스

5.2 향후 개선 계획

1. 단기 개선사항 (1-2개월)

   • 링크 관리 대시보드 구현
   • 접근 로그 시스템 강화
   • 실시간 알림 기능 추가

2. 중장기 계획 (3-6개월)

   • 실시간 권한 변경 기능 구현
   • OAuth 기반 소셜 로그인 통합
   • 분석 대시보드 개발

5.3 모니터링 및 유지보수

1. 시스템 모니터링

   management:
     endpoints:
       web:
         exposure:
           include: health,metrics,prometheus
     metrics:
       tags:
         application: moyeohaeng

2. 성능 측정 메트릭스

   • API 응답 시간 (Timer)
   • 동시 사용자 수 (Gauge)
   • 에러 빈도 (Counter)

3. 로그 추적

   @Slf4j
   @RestControllerAdvice
   public class GlobalExceptionHandler {
       @ExceptionHandler(Exception.class)
       public ResponseEntity<ErrorResponse> handleException(Exception e) {
           log.error("Unexpected error", e);
           // 에러 처리 로직
       }
   }

4. 트러블슈팅 가이드

   • 자주 발생하는 이슈 및 해결 방법
   • 성능 병목 해결 가이드
   • 재난 복구 시나리오

5. 운영 가이드

   • 시스템 상태 점검 및 정기 점검 절차
   • 로그 분석 및 모니터링 전략
   • 성능 최적화 가이드

6. 확장성 고려사항

   • 로드밸런싱 및 스케일아웃 전략
   • 캐시 전략 및 Redis 클러스터링
   • 데이터베이스 인덱싱 및 최적화

7. 보안 모니터링

   • 비정상 접근 탐지
   • 취약점 정기 점검
   • 보안 패치 관리

이 기술 명세서는 프로젝트의 현재 상태를 반영하며, 지속적인 업데이트와 개선이 이루어질 예정입니다. 팀원들의 피드백과 실제 운영 경험을 바탕으로 더 나은 서비스를 제공하기 위해 계속해서 발전시켜 나갈 것입니다.

대부분의 API가 하나의 동일한 CORS 정책을 공유하는, 일반적인 프로젝트 초기에 가장 적합한 방식입니다.

상황

• 모든 API 엔드포인트가 http://localhost:3000이나 https://app.moyeohaeng.com과 같은 단일 종류의 클라이언트로부터 요청을 받습니다.

추천 방식: 암시적 설정 (Customizer.withDefaults())

SecurityConfig는 CORS 설정의 구체적인 내용을 모르고, 스프링 컨테이너에 등록된 CorsConfigurationSource 빈을 자동으로 가져와 사용합니다. 이를 통해 설정을 분리하고 코드를 간결하게 유지할 수 있습니다.

1. application.yml - 설정 외부화

CORS 정책을 외부 설정 파일로 분리하여 관리합니다.

cors:
  allowed-origins: http://localhost:3000
  allowed-methods: GET,POST,PUT,DELETE,PATCH,OPTIONS
  allowed-headers: '*'

2. CorsConfig.java - 설정 빈 생성

@ConfigurationProperties를 사용해 yml 값을 읽어와 CorsConfigurationSource 빈을 생성합니다.

@Getter
@Setter
@Configuration
@ConfigurationProperties(prefix = "cors")
public class CorsConfig {

    private List<String> allowedOrigins;
    private List<String> allowedMethods;
    private List<String> allowedHeaders;

    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration config = new CorsConfiguration();
        config.setAllowedOrigins(allowedOrigins);
        config.setAllowedMethods(allowedMethods);
        config.setAllowedHeaders(allowedHeaders);
        config.setAllowCredentials(true);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return source;
    }
}

3. SecurityConfig.java - 자동 설정 적용

.cors(Customizer.withDefaults()) 한 줄만으로 위에서 생성된 빈을 자동으로 적용합니다.

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .cors(Customizer.withDefaults()) // 자동으로 CorsConfigurationSource 빈을 찾아 적용
            // ... 기타 설정
            .build();
    }
}

Level 2: 고급 설정 (다중 정책 시나리오)

API의 역할(예: 일반 사용자용, 관리자용)에 따라 여러 개의 다른 CORS 정책을 적용해야 할 때 사용하는 방식입니다.

상황

• 일반 사용자 API (/api/v1/**)는 웹 클라이언트의 접근을 허용합니다.
• 관리자 API (/api/admin/**)는 내부 관리자 대시보드나 특정 IP에서만 접근을 허용해야 합니다.

추천 방식: 명시적 의존성 주입

각기 다른 CORS 설정을 담은 빈을 여러 개 만들고, SecurityFilterChain에서 필요한 설정을 명시적으로 주입받아 사용합니다. 이를 통해 명확한 의존 관계를 설정하고 세밀한 제어가 가능해집니다.

1. CorsConfig.java - 여러 개의 설정 빈 생성

@Qualifier를 사용하여 각기 다른 CORS 설정 빈을 이름으로 구분하여 생성합니다.

@Configuration
public class CorsConfig {

    @Bean
    @Qualifier("appCorsSource")
    public CorsConfigurationSource appCorsConfigurationSource() { /* 웹 클라이언트용 설정 */ }

    @Bean
    @Qualifier("adminCorsSource")
    public CorsConfigurationSource adminCorsConfigurationSource() { /* 관리자용 설정 */ }
}

2. SecurityConfig.java - 필터 체인 분리 및 명시적 주입

URL 패턴에 따라 SecurityFilterChain을 분리하고, @Qualifier를 통해 해당 필터 체인에 맞는 CorsConfigurationSource 빈을 명시적으로 주입합니다.

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    // 일반 사용자 API 보안 설정
    @Bean
    @Order(1)
    public SecurityFilterChain apiFilterChain(HttpSecurity http, @Qualifier("appCorsSource") CorsConfigurationSource corsSource) throws Exception {
        http
            .securityMatcher("/api/v1/**")
            .cors(cors -> cors.configurationSource(corsSource)) // 'appCorsSource' 명시적 사용
            // ...
        return http.build();
    }

    // 관리자 API 보안 설정
    @Bean
    @Order(2)
    public SecurityFilterChain adminFilterChain(HttpSecurity http, @Qualifier("adminCorsSource") CorsConfigurationSource corsSource) throws Exception {
        http
            .securityMatcher("/api/admin/**")
            .cors(cors -> cors.configurationSource(corsSource)) // 'adminCorsSource' 명시적 사용
            // ...
        return http.build();
    }
}

결론

프로젝트 초기에는 기본 설정으로 시작하여 단순함을 유지하고, 기능이 확장되어 API 그룹별로 다른 보안 정책이 필요해지는 시점에 자연스럽게 고급 설정으로 리팩토링하는 것이 좋습니다.

이 문서는 CustomUserDetails 클래스의 역할과 JWT 기반의 stateless 인증 시스템에서의 사용 시점을 명확히 설명합니다.

1. CustomUserDetails이란?

CustomUserDetails은 Spring Security의 UserDetails 인터페이스를 구현한 클래스입니다.

• 역할: 인증이 완료된 사용자의 핵심 정보(ID, 이메일, 권한 등)를 담는 객체입니다.
• 목적: Spring Security가 현`재 요청을 보낸 사용자가 누구인지 식별하고, 권한을 확인하는 표준적인 방법을 제공합니다.
• 특징: Member 엔티티 전체가 아닌, 인증에 필수적인 최소한의 데이터만 포함하여 보안성과 효율성을 높입니다.

// CustomUserDetails의 주요 필드
private final Long id;
private final String email;
private final Collection<? extends GrantedAuthority> authorities;

2. 로그인 과정 vs 로그인 이후 API 요청

CustomUserDetails의 사용 시점을 이해하기 위해 두 과정을 구분해야 합니다.

로그인 (Authentication)

• 과정: 사용자가 이메일과 비밀번호로 로그인을 시도하는 최초의 인증 단계입니다.
• CustomUserDetails 사용 여부: 사용하지 않습니다.
• 핵심 로직: AuthService에서 전달받은 비밀번호와 DB에 저장된 해시된 비밀번호를 비교하여 사용자를 검증합니다. 검증 성공 시, JWT(Access Token, Refresh Token)를 생성하여 클라이언트에게 반환합니다.

로그인 이후 API 요청 (Authorization)

• 과정: 클라이언트가 로그인 시 발급받은 JWT를 HTTP 헤더에 담아 서버 자원을 요청하는 모든 후속 단계입니다.
• CustomUserDetails 사용 여부: 매우 중요하게 사용됩니다.
• 핵심 로D직:
  1. JWT 필터 실행: SecurityConfig에 등록된 커스텀 JWT 필터가 요청을 가로챕니다.
  2. 토큰 검증: 필터는 JWT의 유효성(서명, 만료 시간 등)을 검증합니다.
  3. CustomUserDetails 생성: 토큰이 유효하면, 토큰의 claims에 담긴 사용자 정보(ID, 이메일, 권한 등)를 추출하여 메모리 상에 CustomUserDetails 객체를 생성합니다.
  4. SecurityContext 등록: 생성된 CustomUserDetails을 Authentication 객체로 감싸 SecurityContextHolder에 등록합니다. 이로써 Spring Security는 현재 요청의 주체를 인식하게 됩니다.
  5. 컨트롤러/서비스 로직 실행: @AuthenticationPrincipal 어노테이션을 통해 컨트롤러에서 현재 사용자 정보를 직접 주입받거나, @PreAuthorize 등으로 권한 검사를 수행할 수 있습니다.

3. 왜 Stateless 환경에서 CustomUserDetails이 필요한가?

Stateless 원칙은 서버에 사용자 세션을 저장하지 않는다는 의미이지, 요청을 처리하는 메모리 상의 일시적인 정보까지 사용하지 않는다는 의미가 아닙니다.

CustomUserDetails은 서버에 저장되는 "상태(State)"가 아니라, 매 요청마다 JWT를 기반으로 생성되는 일회성 "신분증"입니다. 이 신분증이 있어야 Spring Security의 강력한 보안 기능들을 원활하게 활용할 수 있습니다.

4. 인증 흐름 다이어그램 (Mermaid)

sequenceDiagram
    participant Client
    participant "JWT Filter" as Filter
    participant "AuthService/DB" as Service
    participant Controller
    participant "Spring Security" as Security

    Note over Client, Service: 1. 최초 로그인 (Authentication) - CustomUserDetails 사용 안함
    Client->>Service: 로그인 요청 (이메일, 비밀번호)
    activate Service
    Service->>Service: DB 정보로 사용자 검증
    Service-->>Client: JWT 발급 (Access/Refresh Token)
    deactivate Service

    Note over Client, Security: 2. API 요청 (Authorization) - CustomUserDetails 사용
    Client->>Filter: API 요청 (with JWT)
    activate Filter
    Filter->>Filter: 1. JWT 유효성 검증
    Note right of Filter: 2. 토큰 정보로 CustomUserDetails 생성
    Filter->>Security: 3. SecurityContext에 Authentication 등록
    Filter->>Controller: 4. 요청 전달
    deactivate Filter

    activate Controller
    Controller->>Security: @AuthenticationPrincipal 요청
    activate Security
    Security-->>Controller: SecurityContext에서 CustomUserDetails 제공
    deactivate Security
    Controller-->>Client: API 응답
    deactivate Controller

5 CustomUserDetails 코드

package eightbit.moyeohaeng.global.security;

import java.util.Collection;
import java.util.Collections;

import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.SimpleGrantedAuthority;
import org.springframework.security.core.userdetails.UserDetails;

import eightbit.moyeohaeng.domain.member.entity.member.Member;
import lombok.Getter;

@Getter
public class CustomUserDetails implements UserDetails {

    private final Long id;
    private final String email;
    private final Collection<? extends GrantedAuthority> authorities;

    private CustomUserDetails(Long id, String email, Collection<? extends GrantedAuthority> authorities) {
        this.id = id;
        this.email = email;
        this.authorities = authorities;
    }

    public static CustomUserDetails from(Member member) {
        return new CustomUserDetails(
            member.getId(),
            member.getEmail(),
            Collections.singleton(new SimpleGrantedAuthority("ROLE_USER"))
        );
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return authorities;
    }

    @Override
    public String getPassword() {
        return null;
    }

    @Override
    public String getUsername() {
        return email;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

6. 요약

• 주문번호는 매장/날짜별로 반드시 유일해야 하며,
• 여러 사용자가 동시에 주문을 생성할 때 중복된 번호가 발생하면 절대 안 됨
• 단 하나의 트랜잭션만이 해당 카운터 row에 접근하도록 제어해야 함

🛡️ 비관적 락(Pessimistic Lock) 적용 이유

• 비관적 락을 사용하면, 해당 row에 대한 트랜잭션이 완료될 때까지 다른 트랜잭션의 접근이 차단됨
• 즉, 동시에 여러 사용자가 주문을 해도 race condition을 원천적으로 예방
• 예외 상황(충돌 등)에 대한 처리도 단순해짐
• 주문 생성 트래픽이 아주 높지 않다면, 성능 저하 없이 데이터 무결성을 보장할 수 있음

⚙️ JPA에서 비관적 락 적용 방법

// Repository에서 비관적 락 쿼리 작성 예시
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT c FROM OrderDailyCounter c WHERE c.id = :id")
Optional<OrderDailyCounter> findByIdForUpdate(@Param("id") OrderDailyCounterId id);

• 서비스에서 findByIdForUpdate로 카운터를 조회하면, 해당 row에 쓰기 락이 걸림
• 락이 해제될 때까지(트랜잭션 종료 시점까지) 다른 트랜잭션은 대기

🚦 실제 적용 흐름

1. 트랜잭션 시작
2. findByIdForUpdate로 카운터 row 조회(비관적 락)
3. 카운터 값 증가
4. 저장 및 트랜잭션 커밋
5. 락 해제, 다음 트랜잭션 진행

✅ 장점

• Race condition 완벽 방지
• 예외 상황 처리 단순(재시도 로직 등 불필요)
• 데이터 무결성 보장

⚠️ 단점

• 트래픽이 매우 높은 상황에서는 대기/병목 발생 가능
• 트랜잭션이 길어지면 데드락 위험
• DB에 락이 많이 걸리면 성능 저하 가능

📝 결론

• 주문번호처럼 절대 중복이 허용되지 않는 데이터에는 비관적 락이 매우 효과적
• 단, 트래픽 규모와 시스템 특성을 고려해 적용 필요
• 트래픽이 급격히 늘어날 경우, Redis나 Sequence 등 다른 대안도 함께 검토할 것!

🛠️ 실제 코드 변경 상세 (feat/#71-orderNumber-race-condition)

1. Repository에 비관적 락 메서드 추가

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT c FROM OrderDailyCounter c WHERE c.id = :id")
Optional<OrderDailyCounter> findByIdWithPessimisticLock(@Param("id") OrderDailyCounterId id);

• 기존 findById 대신, PESSIMISTIC_WRITE 락을 거는 쿼리 메서드를 추가

2. 서비스 로직에서 락 메서드 사용

변경 전:

OrderDailyCounter counter = orderDailyCounterRepository.findById(id)
    .orElseGet(() -> new OrderDailyCounter(id, 0));

변경 후:

OrderDailyCounter counter = orderDailyCounterRepository.findByIdWithPessimisticLock(id)
    .orElseGet(() -> {
        OrderDailyCounter newCounter = new OrderDailyCounter(id, 0);
        orderDailyCounterRepository.saveAndFlush(newCounter);
        return newCounter;
    });

• findByIdWithPessimisticLock로 row-level lock을 적용하여 카운터를 조회
• 만약 해당 row가 없으면 새로 생성 후 즉시 저장(saveAndFlush)하여 락이 적용된 상태로 카운터 관리

3. 카운터 증가 및 저장

변경 전/후 동일:

counter.increment();
orderDailyCounterRepository.save(counter);

4. 전체 흐름

1. 트랜잭션 시작
2. findByIdWithPessimisticLock로 카운터 row 조회(또는 신규 생성)
3. 카운터 값 증가
4. 저장 및 트랜잭션 커밋
5. 락 해제, 다음 트랜잭션 진행

💡 변경 효과

• 동시성 문제(race condition) 완전 차단
• 주문번호 중복 없이, 안정적으로 주문 처리 가능
• 예외 상황 처리 단순화(재시도 로직 필요 없음)
• 트래픽이 아주 높지 않다면 성능 저하 없이 데이터 무결성 보장

변경후 결과

구름 딥 다이브 프로젝트에서 스타벅스 앱 클론을 개발하던 중,
주문번호(order number) 중복 에러를 발견했습니다.

• 천천히 1번씩 주문하면 문제 없음
• 하지만 k6로 대량 주문 API 호출 시, 100번 중 96번 실패!
• 대표 에러:

  [ERROR: duplicate key value violates unique constraint "orders_order_number_key”]

  

이 글은 문제 해결 과정을 기록한 블로그 포스트입니다.

🔢 주문번호 조건

• 매장이 다르면 주문번호가 같아도 됨
• 같은 매장, 같은 날짜에는 주문번호 중복 불가
• 매일 주문번호는 1번부터 다시 시작
• 고객과 매장은 동일 주문번호를 확인
• A~Z 매장코드는 옵션, 실제 구현은 A로 통일

🚀 1차 프로젝트 구현

order_daily_counter 테이블의 카운터 값을 이용해 주문번호 생성

@Transactional
public String generateOrderNumber(OrderCreateRequest request) {
    LocalDate today = LocalDate.now();
    OrderDailyCounterId id = new OrderDailyCounterId(today, request.storeId());

    OrderDailyCounter counter = orderDailyCounterRepository.findById(id)
            .orElseGet(() -> new OrderDailyCounter(id, 0));

    counter.increment();
    orderDailyCounterRepository.save(counter);

    return "A-" + counter.getCount();
}

❓ 의문점

generateOrderNumber()에서 이미 저장을 하는데
왜 주문번호가 중복(동일)하게 나올까? 🧐

🛑 원인 분석

1. 🟠 @Transactional은 트랜잭션의 원자성만 보장, 동시성 제어는 별도 필요
2. 🟠 여러 트랜잭션이 동시에 같은 값을 읽고, 각각 증가 후 저장 → race condition 발생
3. 🟠 JPA/Hibernate의 save/merge 방식은 동시성 문제에 취약

🛠️ 문제 해결 접근 단계

1. 요구사항·제약 재정의
2. 시스템 환경 및 기술 스택 확인
3. 적용 가능한 동시성 제어 기법 조사

1️⃣ 요구사항·제약 재정의

• 같은 매장, 같은 날짜에는 주문번호 중복 불가
• 다른 매장끼리는 주문번호 중복 허용
• 초당 100건 이상의 주문이 들어올 수 있음 (1000이상까지 목표)
• order_daily_counter 테이블은 (date, store_id) 복합키 사용

2️⃣ 시스템 환경 및 기술 스택

• 백엔드: Spring Boot, JPA(Hibernate)
• 트랜잭션 관리: Spring의 @Transactional
• DB: PostgreSQL
• 운영환경: JVM 기반, Prometheus 지원

3️⃣ 적용 가능한 동시성 제어 기법

💡 결론

• 단순 @Transactional + save/merge만으로는 동시성 문제 해결 불가
• 반드시 DB atomic 연산, Optimistic Lock, Upsert 등 별도의 동시성 제어 필요!
• 시스템 환경과 요구사항에 맞는 방법을 신중히 선택해야 함

실제 적용 예시, 해결법 상세 구현, 트러블슈팅 경험 등은 별도 포스트로 이어집니다!