자바에서는 클래스를 만들 때 필드(Field), 생성자(Constructor), Getter/Setter를 모두 작성해야 하지만, 코틀린은 이를 프로퍼티(Property)라는 개념으로 통합하여 한 줄로 해결한다.

1. 클래스 선언과 생성자

코틀린은 클래스 이름 바로 옆에 생성자를 정의하는 주 생성자(Primary Constructor) 방식을 사용한다.

// 코틀린: 단 한 줄로 필드 생성, 생성자, Getter/Setter까지 해결
class User(val name: String, var age: Int)

// 자바였다면?
/*
public final class User {
    private final String name;
    private int age;

    public User(String name, int age) {
        this.name = name;
        this.age = age;
    }
    public String getName() { return name; }
    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }
}
*/

2. 프로퍼티 (Property)

코틀린에서는 클래스의 필드를 프로퍼티라고 부른다.

val 프로퍼티: 내부적으로 private 필드 + public Getter를 생성한다.

var 프로퍼티: 내부적으로 private 필드 + public Getter + public Setter를 생성한다.

사용할 때는 자바처럼 .getName()을 호출할 필요 없이 점(.) 연산자로 바로 접근한다.

val user = User("John Doe", 20)
println(user.name) // 내부적으로 getName() 호출
user.age = 21      // 내부적으로 setAge() 호출

3. 커스텀 Getter / Setter

기본적인 Getter/Setter 외에 특정한 로직이 필요할 때 직접 정의할 수 있다. 이때 실제 값을 담고 있는 field (Backing Field)라는 키워드를 사용한다.

class Person(var name: String) {
    var nickname: String = ""
        set(value) {
            // 입력값을 대문자로 바꿔서 저장하는 로직
            field = value.uppercase()
        }

    val isAdult: Boolean
        get() = this.age >= 20 // 별도의 필드 없이 계산된 값만 반환 (Custom Getter)
}

4. 초기화 블록 (init)

주 생성자에는 코드를 작성할 공간이 없다. 만약 객체가 생성되는 시점에 로직을 실행하고 싶다면 init 블록을 사용한다.

class Student(val name: String) {
    init {
        println("학생 객체가 생성되었습니다: $name")
        require(name.isNotEmpty()) { "이름은 비어있을 수 없습니다." }
    }
}

5. 데이터 클래스 (Data Class)

데이터를 담는 것이 목적인 클래스라면 data 키워드만 붙여보자. toString(), equals(), hashCode(), copy() 등을 컴파일러가 자동으로 만들어준다. (자바의 Record와 유사)

data class Book(val title: String, val author: String)

val book1 = Book("Kotlin", "JetBrains")
println(book1) // Book(title=Kotlin, author=JetBrains) 가 예쁘게 출력됨

요약하자면?

• 간결성: 주 생성자를 통해 필드 선언과 동시에 초기화가 가능하다.
• 프로퍼티: Getter/Setter를 일일이 만들지 않아도 코틀린이 알아서 생성해 준다.
• field: 커스텀 Setter에서 실제 값을 가리키기 위해 사용하는 예약어이다.
• data class: 데이터를 다루는 클래스를 위한 최고의 편의 기능을 제공한다.

코틀린에서 함수는 독립적으로 존재할 수 있으며, 자바보다 훨씬 간결하고 유연하게 선언할 수 있어 '코틀린의 꽃'이라 불린다.

1. 함수 선언 기본

자바와 가장 큰 차이점은 파라미터의 이름이 타입보다 먼저 오며, 반환 타입이 함수 정의 끝에 위치한다는 점이다.

fun sum(a: Int, b: Int): Int {
    return a + b
}

2. 단일 식 함수 (Expression Body)

함수의 몸체가 단 한 줄의 식으로 이루어져 있다면, 중괄호{}와 return을 생략하고 =를 사용하여 축약할 수 있다.

// 반환 타입까지 추론이 가능하여 생략할 수 있다.
fun sum(a: Int, b: Int) = a + b

3. Top-Level Function (최상위 함수)

코틀린은 클래스 밖에서도 함수를 선언할 수 있다. 이는 자바에서 유틸리티 성격의 메서드를 만들기 위해 무의미한 클래스(UtilClass)를 생성해야 했던 불편함을 해결해준다.

Kotlin: 클래스 없이 함수만 선언해도 어디서든 접근 가능.

Java 비유: 자바의 static 메서드와 유사하게 동작하지만, 훨씬 가독성이 좋고 코드가 깔끔해진다.

// Utils.kt 파일
fun log(message: String) {
    println("Log: $message")
}

class Service {
    fun run() {
        log("서비스 실행") // 클래스 외부 함수를 바로 사용
    }
}

4. 기본 파라미터와 오버로딩 (Default Parameters)

자바에서는 파라미터 개수가 다를 때마다 여러 개의 메서드를 오버로딩(Overload)해야 했다. 코틀린은 기본값(Default Value)을 설정하여 이를 함수 하나로 처리한다.

// 함수 하나로 3가지 케이스를 모두 대응 가능
fun sum(a: Int, b: Int, c: Int = 0) = a + b + c

fun main() {
    sum(1, 2)       // c는 기본값 0 사용 (결과: 3)
    sum(1, 2, 3)    // c에 3 대입 (결과: 6)

    // Named Arguments: 이름을 지정하면 순서와 상관없이 대입 가능
    sum(b = 10, a = 5) 
}

5. Unit 반환 (Java의 void)

반환값이 없는 함수의 경우 자바에서는 void를 사용하지만, 코틀린은 Unit이라는 객체를 반환한다. (생략 가능)

fun printSum(a: Int, b: Int): Unit { // : Unit은 생략 가능
    println(a + b)
}

요약하자면?

간결성: = 하나로 함수를 정의할 수 있는 단일 식 함수 지원.

유연성: 클래스에 얽매이지 않는 최상위 함수 제공.

효율성: 기본 파라미터를 통해 복잡한 오버로딩 없이 함수 하나로 다양한 케이스 대응.

코틀린의 가장 큰 특징은 컴파일 단계에서 NullPointerException(NPE)을 방지하도록 설계되었다는 점이다.

1. Null을 대입하려면 타입 지정이 필수다

코틀린은 타입 추론을 지원하지만, null을 대입할 때는 이야기가 다르다.

var name = null // (X) 컴파일러가 타입을 추론할 수 없음

어떤 타입의 Null인지 알 수 없기 때문에, Null을 허용하려면 반드시 명시적 타입 지정과 함께 ? 키워드를 붙여야 한다.

var name : String? = null // (O)
name = "John Doe"

2. String?과 String은 서로 다른 타입이다

가장 흔히 하는 착각이 String?을 단순히 String에 null이 추가된 상태로 보는 것이지만, 코틀린에서 이 둘은 완전히 다른 타입으로 취급된다.

Java와 비교해보자, Java 에서는 래퍼클래스와 기본 타입이 존재한다. 예시를 들어보자면 Java에서는 정수를 표기할 때 Integer 와 int 를 사용할 수 있는데 두 타입은 null의 허용 여부를 보여주는 단편적인 예시이다.

Integer num1 = null;
int num2 = 0;
num2 = num1; // 오류 발생! (언박싱 과정에서 NPE 위험)

이처럼 코틀린에서도 null이 가능한 타입(String?)의 값을 null이 불가능한 타입(String)에 그냥 대입할 수는 없다.

3. Null을 안전하게 처리하는 방법

A. 강제 타입 변환 (!!)

!!를 사용하면 Nullable 타입을 Non-Null 타입으로 강제로 바꿀 수 있다.

var name : String? = null
var name2 : String = name!! // "내가 책임질게, 무조건 null 아니야!"

• 주의: 만약 name이 실제로 null이라면 런타임에 에러가 발생한다. 이는 개발자의 책임이며, 가급적 사용을 지양해야 하는 좋지 않은 방법이다.

B. 내장 함수 ?.let { } 사용 (권장)

코틀린이 제공하는 가장 세련된 방법 중 하나다.

의미: "null이 아니면(?.) 다음 내용을 실행하자(let { })"

fun main() {
    var name : String? = "John Doe"
    var name2 : String = ""

    name?.let {
        name2 = it // it은 null이 아닌 name을 가리킴
    }
}

C. 안전한 호출(?.)과 엘비스 연산자(?:)

• ?. (Safe Call): null이면 뒤의 코드를 실행하지 않고 바로 null을 반환한다.
• ?: (Elvis Operator): null일 경우 지정한 기본값을 대신 사용한다.

  val length = name?.length ?: 0 // name이 null이면 0을 반환

요약하자면?

1. ?: 이 변수는 null일 수도 있음을 선언.
2. String? ≠ String: 둘은 엄격히 다른 타입이므로 직접 대입 불가.
3. ?.let: null이 아닐 때만 안전하게 코드를 수행하는 가장 코틀린스러운 방법.
4. !!: 강제로 null이 아님을 선언하지만, NPE 위험이 커서 권장하지 않음.
5. ?.: null이면 실행하지 않음 (Safe Call)
6. ?:: null이면 이 값을 대신 사용함 (Elvis Operator)

코틀린에서 데이터를 담는 대표적인 자료구조이다. 가장 큰 차이점은 크기 변경이 가능한가와 수정 가능한가에 있다.

Array (배열)

자바의 배열과 유사하다. 크기가 정해져 있으며, 한 번 생성하면 크기를 늘리거나 줄일 수 없다.

fun main() {
    // arrayOf를 사용하여 생성
    val array = arrayOf(1, 2, 3)

    // 인덱스로 접근 및 수정 가능
    array[0] = 10
    println(array[0]) // 10

    // array.size로 크기 확인 가능
}

List (리스트)

코틀린의 리스트는 크게 두 가지로 나뉜다. 기본적으로 listOf로 만드는 리스트는 수정이 불가능(Immutable)하다는 점이 중요하다.

Immutable List (수정 불가) 생성 시점에 정해진 데이터를 읽기만 할 수 있으며, 요소를 추가하거나 변경할 수 없다.

val list = listOf(1, 2, 3)
// list[0] = 10 // (X) 에러 발생: 수정 불가

Mutable List (수정 가능) 요소를 추가, 삭제, 수정할 수 있는 리스트이다. Java의 ArrayList와 비슷하다.

val mutableList = mutableListOf(1, 2, 3)

mutableList.add(4)      // 요소 추가
mutableList.removeAt(0) // 0번 인덱스 삭제
mutableList[0] = 10     // 요소 수정

요약하자면?

• Array: 크기 고정, 내부 값 수정 가능.

• List (listOf): 크기 고정, 내부 값 수정 불가.

• MutableList (mutableListOf): 크기 가변, 내부 값 수정 가능.

Tip: 코틀린에서는 데이터의 일관성을 위해 가능하면 수정 불가능한 List를 먼저 사용하고, 데이터 변경이 꼭 필요한 경우에만 MutableList를 사용하는 것을 권장한다.

https://www.youtube.com/watch?v=OtHkb6wAI5U

조건문

자바에서는 if-else 또는 switch-case 문으로 조건문을 작성할 수 있다.

Kotlin에서 if 문은 when으로 치환할 수 있다. when은 Java의 switch와 비슷하지만 조금 더 강력한 조건들을 지정할 수 있다. (범위 지정, 값 비교, 식 사용 등)

조건문이 식으로 성립된다.

또한 중요한 점은 Kotlin에서의 조건문(when, if)은 식(Expression)으로 치환될 수 있다는 점이다. 즉, 조건문의 결과값을 변수에 바로 대입할 수 있다.

fun main() {
    var i = 5

    var result = if (i > 10) { // 조건문 통과 후 바로 result로 대입
        "10 보다 크다"
    } else if (i > 5) {
        "5보다 크다"
    } else {
        "5다."
    }
    print(result) // "5다." 가 출력된다.
}

// when으로 바꾼다면 다음과 같은 식이 된다.
fun main() {
    var i = 5

    var result = when { // 조건문 통과 후 바로 result로 대입
        i > 10 -> {
            "10 보다 크다"
        }
        i > 5 -> {
            "5보다 크다"
        }
        else -> {
            "5다."
        }
    }
    print(result) // "5다." 가 출력된다.
}

삼항 연산자

자바에서는 보통 다음과 같이 사용된다.

boolean result = i > 10 ? true : false; 

Kotlin에는 별도의 삼항 연산자가 없다. 대신 if를 식 그대로 적어주면 삼항 연산과 동일한 결과를 확인할 수 있다.

var result = if (i > 10) true else false

반복문

반복문은 보통 리스트(List) 같은 자료형을 순회할 때 자주 사용된다.

Kotlin은 for in 형태를 사용하며, Java의 향상된 for문이나 Python과 유사한 형태라 직관적이다.

다양한 for in 사용법

fun main() {
    val numbers = listOf(1, 2, 3, 4, 5) 

    // 1. 리스트 전체 순환
    for (item in numbers) {
        print(item)
    }

    // 2. 특정 범위 지정 (.. 사용 시 마지막 숫자 포함: 0123)
    for (i in 0..3) {
        print(i) 
    }

    // 3. 리스트 크기만큼 반복 (until 사용 시 마지막 미포함: 01234)
    // 0..numbers.size-1 와 동일하게 작동한다.
    for (i in 0 until numbers.size) {
        print(i)
    }

    // 4. 건너뛰며 반복 (step 사용)
    for (i in 0..10 step 2) {
        print(i) // 0, 2, 4, 6, 8, 10 출력
    }
}

forEach

함수형 스타일의 forEach 역시 가능하다.

fun main() {
    val numbers = listOf(1, 2, 3, 4, 5)

    // 일반적인 형태
    numbers.forEach { item ->
        print(item)
    }

    // 더 간결하게 it 키워드 사용 (파라미터가 하나일 때 생략 가능)
    numbers.forEach { print(it) }
}

while문

Java와 완벽하게 동일한 형태로 사용 가능하다. break, continue 둘 다 가능하므로 기존에 알고 있는 형태로 사용하자.

https://www.youtube.com/watch?v=OtHkb6wAI5U

변수

변수의 종류

코틀린 변수는 두 가지 키워드로 구분된다.

• val (Value): 읽기 전용(Read-only). 초기화 후 재할당이 불가능하며, Java의 final과 유사하다.

• var (Variable): 가변(Mutable). 선언 후 값을 자유롭게 변경할 수 있다.

타입 추론

코틀린 변수는 타입 추론을 지원한다 타입 추론이란 자료형(데이터 타입)을 명시하지 않아도 된다는 것을 의미한다.

정확히는 변수 선언 시 자료형이 명시되지 않았다면 대입되는 값을 통해 컴파일러가 타입을 지정하는 것이다.

var name1 = "kotlin" // String으로 추론
var name2 : String = "java" // 명시적 타입 지정

모두 String 으로 인식이 된다는 소리.

단, 타입을 지정해줄 때는 : Type 과 같은 형태로 변수 명 뒤에 붙이면 된다.

타입 추론의 제약

타입 추론은 편리한 기능이지만 다음과 같은 주의점을 숙지해야한다.

초기화 필수

초기화 필수란 무엇일까?

val name1 // (X) 에러 발생 : 타입을 알 수 없음
// name1 = "kotlin" // 애초에 선언 시 초기화 되지 않았다는 오류가 표기

val name2 : String // (O) 선언 시점이 아닌 추후 초기화를 위해 타입을 지정
name2 = "kotlin" // 정상적으로 컴파일

Null Safe

코틀린 변수는 기본적으로 Null을 허용하지 않는다. Java Spring 에선 Null을 위한 방어코드를 작성하는 일이 빈번한데, Kotlin 에서는 기본적으로 변수에서 부터 null을 허용하지 않기 때문에 조금 더 안전하게 코드 작성이 가능하다.

다만 변수가 null을 허용하기 위해선 타입 뒤에 ?를 붙이는 것으로 null을 허용할 수 있다.

var name1 : String? = "kotlin" // null 허용 

위와 같은 상황일 때 var를 통한 선언으로 가변 변수 적용이 되며 추 후 null 로 값이 변경될 수 있다.

물론 val 도 null 초기화가 가능하다. 따라서

val name2 : String? = null

과 같이 선언하면 불변이면서 Null인 상태 도 가능하다는 것

간단하게 코드 블럭으로 살펴보자면

var name1 : String? = "kotlin" 
name1 = null // var이므로 재할당 가능 + Nullable이므로 null 가능

val name2 : String? = null 
// name2 = "java" // Error: val은 재할당 불가! (불변이면서 null인 상태 유지)

일단 얘기해보자면 코드 자체는 그렇게 크게 문제가 없었다. 다만 Gateway든 다른 서비스에서든 생성한 커스텀 헤더를 클라이언트쪽에서 확인할 수 없는 문제였다.

즉, 생성된 커스텀 헤더들은 서버에서만 통한다는 얘기....

여기서 내가 생각하고 구현한 구조와 흐름과 통상적인 웹 동작에서의 구조와 흐름에 대한 차이 대해 조금 정리해보고자 한다.

내가 생각한 버전

1. 로그인 요청

일단 내가 구현한 흐름 자체는 로그인 요청이 수행되면 서버에서는 JWT를 생성하여 쿠키나 헤더를 통해 Gateway로 전달이 된다.

2. Gateway

Gateway로 넘어온다면 쿠키에서 JWT를 추출하고 추출한 JWT를 기반으로 커스텀 헤더를 생성하여 Down Stream을 진행한다.

통상적인 웹 동작

1. 로그인 요청

일반적인 웹 시스템에서는 사용자가 로그인하면 서버는 JWT(또는 세션 ID)를 HttpOnly 쿠키 또는 LocalStorage에 저장하게 된다.

이후의 모든 요청에서는 클라이언트(브라우저 또는 앱) 가 이 토큰을 보관하고, 서버로의 요청 시마다 Authorization 헤더에 붙이거나, 자동으로 쿠키를 전송하게 된다.

Authorization: Bearer <JWT_TOKEN>
혹은
Cookie: accessToken=xxx;

이 구조에서 핵심은 "클라이언트가 토큰을 소유"하고 있다는 점이다. 그래서 사용자는 로그인 이후에도 새로고침이나 다른 페이지 이동 등에서도 인증 상태를 유지할 수 있게 된다.

서버 인증 처리

서버에서는 요청을 받을 때마다 클라이언트가 보낸 JWT를 검증하여 인증 처리를 진행하고, 필요한 경우에는 내부적으로 사용자 정보를 조회하거나 권한 확인을 하게 된다. 이 과정에서 추가적인 커스텀 헤더를 붙이는 경우도 있지만, 그것은 클라이언트가 아닌 서버 간 통신에서만 주로 사용된다.

구조적 차이와 문제 포인트

정리하면, 내가 구현한 구조에서는 "JWT → 커스텀 헤더로 변환 → 이후 요청은 커스텀 헤더 기반" 이라는 방식이고, 클라이언트는 이 커스텀 헤더들을 알 수 없고, 사용할 수 없는 구조이다.

즉, 클라이언트는 인증 정보를 소유하지 않기 때문에, 로그인 이후 인증 유지가 어려워지는 문제가 생긴다. (한 번 로그인하면 커스텀 헤더가 서버 간 통신에만 사용되므로, 클라이언트가 직접 다음 요청을 보낼 수 없는 구조)

그래서 생긴 이슈:

• Postman에서 직접 커스텀 헤더를 입력하면 정상 작동
• 하지만 브라우저나 앱에서는 커스텀 헤더를 자동으로 생성하거나 보낼 수 없음
• 따라서 로그인 이후 상태를 유지하거나 인증 요청을 할 수 없음

이슈를 해결하기 위해

AI님들과 얘기를 조금 해봤는데 여러가지 방안을 알려주었다.

그런데 일단 내가 생각한 방안은 커스텀 헤더 기반 인증이기 때문에 다음 포스팅 부터는 커스텀 헤더 기반 인증 유지 하는 방법으로 문제를 해결하겠다.

Postman의 한계인건지, 내 코드가 너무 조잡한건지 그것도 아니라면 내가 아직 MSA에서의 인증 방식에 대해 제대로 깨닫지 못한건지..

굳이 JWT를 통해서 CustomHeader를 생성하고 Downstream까지 해놓고 매 요청마다 JWT를 계속 추가되어 기존의 CustomHeader들은 모두 무용지물이 되는 상황이다.

어떤 상황인지 공부도 필요하고... 코드 수정에 들어가야 할 것 같다... ㅠ

시작하기 전에...

먼저 RabbitMQ를 이용한 작업을 할 차례였고, RabbitMQ를 통한 메시지 처리도 API Gateway 통해야 하는 줄 알았다.

그리고 각 서비스마다 독립적인 DB를 가지기 때문에 테이블간의 연관관계 설정을 위해서, 예를 들면 Product가 User을 FK로 가지기 위해서 연관 관계를 설정하는 타이밍을 위해

User 서비스에서 User정보를 넘겨주려는 API 역시 생성하려 하였다.

이 두가지 논점을 먼저 해결하고 이번 포스팅의 목적인 메시지큐 구축 작업을 작성하도록 하겠다.

User 정보 API

먼저 User 정보를 위한 API 설계는 진행하지 않았다.

이유 역시 두가지 정도가 있는데

1. 기존에 생성한 CustomHeader인 X-User-Id에 User를 식별할 정보가 담겨져있다.

2. 메시지 큐를 이용한 데이터 교환은 비동기 작업이다.

이 두 가지 내용이다.

CustomHeader

X-User-Id에는 UserId로 식별할 수 있는 email이 담겨져있고, 해당 헤더는 이미 존재하는지 확인하는 작업후 생성되는 헤더이기 때문에 일반적인 상황에서는 추가적으로 확인하는 작업이 필요하지 않다.

따라서 Product를 생성하는 동기 처리까지 오기 전에 이미 검증을 끝내었기 때문에 API를 생성할 이유가 없는 것이다.

다만 User 서비스에 실제 해당 ID(email)가 존재하는지 100% 보장할 수는 없기 때문에 문제가 발생할 수 있으나 해당 문제는 밑에서 다시 다루도록 하겠다.

메시지큐는 비동기 작업

위의 이유가 사실 따지고보자면 1개의 이유이긴 하다. 일단 내용을 보자

Product 서비스에서 Product를 생성하는 과정 : 동기 작업 Product 서비스에서 User 서비스 API를 호출하여 정보 교환 : 동기 작업

그렇지만 소제목으로 적어뒀듯이 메시지큐는 비동기 작업이다.

그렇다면 왜 메시지큐를 통한 비동기 작업이 필요할까?

이유는 User의 삭제, 변경등의 이유이다.

기존 RDB의 Cascade 역할을 대체하기 위함으로도 볼 수 있는 과정으로 서로 독립된 DB를 사용하는 만큼 데이터 동기화를 통한 일관성(Consistency) 원칙을 지키기 위함이다.

정확하게는 최종적 일관성(Eventual Consistency) 을 보장하기 위함이다. (나중에 SAGA 패턴에 대해 공부하고 글을 적어보자...)

User 확인이 정말 필요 없나?

위에서 했던 얘기를 조금 더 이어나가보자면 (잘못된 정보 주의) 사실 확인하는게 데이터 자체의 안정성 면에서는 더 좋다고 생각된다. 해당 부분을 해결하려면 Auth - User 관계처럼 로그인할 때 한 번의 HTTP 동기 처리가 이루어지는 것 처럼 User 정보를 받아오는것으로 해결할 수 있다.

단 처리해야 하는 시점을 명확히 해야 한다. 내가 생각하기에 USER를 확인하는 시점은 Product가 생성될 때 1번만 User 정보를 받아오면 된다.

해당 과정은 비동기 처리로 하기에는 적절하지 않은 동기 작업이기에 비동기 처리에 엮을 필요가 없다는 생각이다.

이쯤으로 User 정보 API에 대한 얘기를 마치고 본격적으로 RabbitMQ 작업을 진행하겠다.

RabbitMQ

처음에 했던 얘기를 다시 가져오자면 RabbitMQ 메시지 처리를 API Gateway를 통해야 하는 줄 알았지만 둘의 역할은 다르다.

• API Gateway는 주로 HTTP 요청을 라우팅하고 인증, 로깅 등의 기능을 제공하는 반면,
• RabbitMQ는 비동기 메시지 큐로, 서비스 간의 직접적인 통신을 줄이고 비동기 이벤트 처리를 가능하게 한다.

따라서 각 서비스가 RabbitMQ를 직접 퍼블리싱(Publish)하고 서브스크라이브(Subscribe)하는 구조로 설계하는 게 일반적이다.

기본적인 흐름

기본적으로 User 서비스에서 User 삭제 이벤트를 발생시키면, Product 서비스가 이를 수신하여 관련 데이터를 정리하는 구조다. RabbitMQ를 활용하는 이유는 서비스 간의 결합도를 낮추고, 데이터 동기화 문제를 해결하기 위함이다.

흐름 요약

1. User 서비스에서 사용자가 삭제되면, UserEventPublisher가 삭제 이벤트를 발행(Publish).
2. RabbitMQ가 메시지를 큐(Queue)에 저장.
3. Product 서비스가 해당 메시지를 수신(Subscribe)하여, 삭제된 사용자와 연결된 상품을 삭제.

RabbitMQConfig

먼저 RabbitMQConfig를 통신하려는 서비스 (현재는 User - Product) 양쪽에 작성한다.

@Configuration
public class RabbitMQConfig {

    // Exchange 설정
    public static final String EXCHANGE = "user.exchange";

    // Queue 설정
    public static final String USER_UPDATED_QUEUE = "user.updated.queue";

    // RoutingKey 설정
    public static final String USER_UPDATED_ROUTING_KEY = "user.updated";

    // Bean 등록
    // exchange 설정
    @Bean
    public DirectExchange userExchange() {
        return new DirectExchange(EXCHANGE);
    }

    @Bean
    public Queue userDeletedQueue() {
        return new Queue(USER_DELETED_QUEUE);
    }

    // binding 설정
    @Bean
    public Binding userDeletedBinding(Queue userDeletedQueue, DirectExchange exchange) {
        return BindingBuilder.bind(userDeletedQueue)
                .to(exchange)
                .with(USER_DELETED_ROUTING_KEY);
    }

    @Bean
    public MessageConverter jsonMessageConverter() {
        return new Jackson2JsonMessageConverter();
    }

    @Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {
        RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory);
        rabbitTemplate.setMessageConverter(jsonMessageConverter());
        return rabbitTemplate;
    }
}

일단 간략하게 User삭제를 위한 Exchange, Queue, RoutingKey 를 선언해줬다. 일반적으로 아래와 같이 사용되며

Exchange(교환기): 메시지를 전달하는 중심 허브 역할. Queue(큐): 메시지를 저장하고, 구독한 서비스가 가져가도록 함. Routing Key(라우팅 키): 특정 큐에 메시지를 전달하기 위한 식별자. RabbitTemplate: 메시지를 변환하고, RabbitMQ에 전송하는 역할.

해당 서비스에서는 다음과 같은 역할을 가진다.

DirectExchange: 특정 라우팅 키를 가진 메시지를 해당 큐로 보냄. Queue: 삭제 이벤트를 저장하는 큐. Binding: RoutingKey를 기준으로 큐를 Exchange에 연결. RabbitTemplate: JSON 메시지를 변환하여 RabbitMQ로 전송하는 역할.

UserEventPublisher

다음으로는 User와 관련된 Event가 발생되었을 때 이벤트를 발급할 수 있는 코드를 작성하도록 하겠다. (User Service 내부)

@Service
public class UserEventPublisher {

    private final RabbitTemplate rabbitTemplate;

    @Autowired
    public UserEventPublisher(RabbitTemplate rabbitTemplate) {
        this.rabbitTemplate = rabbitTemplate;
    }

    public void publishUserDeleted(String userId) {  // 삭제 이벤트 추가
        rabbitTemplate.convertAndSend(
                RabbitMQConfig.EXCHANGE,
                RabbitMQConfig.USER_DELETED_ROUTING_KEY,
                userId
        );
    }
}

publishUserDeleted(userId): 삭제된 유저 ID를 RabbitMQ에 발행. Exchange(user.exchange) → Queue(user.deleted.queue)로 메시지가 전달됨.

해당 이벤트를 비지니스로직에

해당 이벤트를 비지니스로직에 작성하므로써 요청이 들어올 경우 이벤트를 발급한다.

@Transactional
public void deleteUser(String email) {
    User user = userRepository.findByEmail(email)
            .orElseThrow(() -> new CustomException(ErrorCode.USER_NOT_FOUND));

    userRepository.delete(user);
    eventPublisher.publishUserDeleted(email);
}

UserEventListener

이제 발급받은 event를 수신할 UserEventListener를 Product 서비스 내에 작성한다.

@Component
@RequiredArgsConstructor
public class UserEventListener {

    private final ProductRepository productRepository;

    @RabbitListener(queues = RabbitMQConfig.USER_DELETED_QUEUE)
    public void handleUserDeletedEvent(String userId) {

        List<Product> products = productRepository.findByOwner(userId);

        if (!products.isEmpty()) {
            productRepository.deleteAll(products);
        }
    }
}

트러블슈팅을 먼저 진행하고 가야 할 것 같다.

그렇지만 따로 문제가 생겼던 코드는 커밋을 해두지 않았기에 실행했던 스크린샷과 같은 자료가 없고, 그냥 이러한 문제를 겪었었다 정도를 적는 시간이 될 것 같다.

트러블 슈팅

내가 겪었던 문제는 필터에서의 익명 인증 객체가 설정되는 문제였다.

나는 일단 MSA 구조 자체에서 Gateway에 보안적인 부분을 모두 할당? 한다는 점으로 이해하고 작업했었으며, 그로 인해 CustomHeader를 생성했고 해당 헤더들을 각 서비스에서 검증만하는 방식으로 구현했다.

이러한 방식을 통해 API Gateway :

• JWT 토큰 검증 및 인증 객체 생성 후 Gateway내에 저장
• CustomHeader 생성 및 DownStream 진행

각 서비스 :

• DownStream 방식으로 전해진 헤더 검증
• 리소스 접근

의 방식으로 진행된다고 생각했고, DownStream 방식으로 전해진 헤더 검증 을 SecurityConfig와 더불어 Filter를 통해 구현한다면 리소스 접근까지 해결할 수 있으리라 생각했다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http, SignatureAuthFilter signatureAuthFilter) throws Exception {
        http.csrf(AbstractHttpConfigurer::disable)
            .authorizeHttpRequests(authorize -> authorize
                .requestMatchers("/v1/auth/**").permitAll()
                .anyRequest().authenticated()
            )
            .addFilterBefore(signatureAuthFilter, UsernamePasswordAuthenticationFilter.class)
            .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS));

        return http.build();
    }
}

처음에 저렇게 Filter를 생성했는데 바로 여기서 익명 인증 객체의 문제가 발생했다.

@Component
@RequiredArgsConstructor
@Slf4j
public class SignatureAuthFilter extends OncePerRequestFilter {

    private final SignatureUtil signatureUtil;
    private final List<String> excludedPaths = List.of("/v1/auth/login", "/v1/users/signup", "/v1/users/email");

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {

        System.out.println("DISPATCHER TYPE : " + request.getDispatcherType());

        String path = request.getRequestURI();

        // 화이트리스트 URL 예외 처리 (필터 통과)
        if (excludedPaths.contains(path)) {
            filterChain.doFilter(request, response);
            return;  //  반드시 return 추가
        }

        String userId = request.getHeader("X-User-Id");
        String timestamp = request.getHeader("X-Timestamp");
        String signature = request.getHeader("X-Signature");

        // 헤더 값 검증 실패 시 즉시 리턴
        if (userId == null || timestamp == null || signature == null) {
            response.sendError(HttpStatus.UNAUTHORIZED.value(), "Missing authentication headers");
            return;
        }

        log.debug("Received authentication headers: userId={}, timestamp={}, signature={}", userId, timestamp, signature);

        // 타임스탬프 검증
        if (!signatureUtil.isTimestampValid(timestamp)) {
            response.sendError(HttpStatus.UNAUTHORIZED.value(), "Timestamp expired");
            return;
        }

        // 서명 검증
        if (!signatureUtil.validateSignature(userId, timestamp, signature)) {
            response.sendError(HttpStatus.UNAUTHORIZED.value(), "Invalid signature");
            return;
        }

        // 인증 정보 설정 (ROLE_USER 부여)
        List<GrantedAuthority> authorities = List.of(new SimpleGrantedAuthority("ROLE_USER"));

        UsernamePasswordAuthenticationToken authentication =
                new UsernamePasswordAuthenticationToken(userId, null, authorities);

        SecurityContextHolder.getContext().setAuthentication(authentication);

        log.debug("Authentication: {}", SecurityContextHolder.getContext().getAuthentication());

        // 검증 완료 후 필터 체인 실행
        filterChain.doFilter(request, response);
    }
}

위의 코드는 구현한 필터인데 구체적으로 문제가 발생했던 지점은 다음과 같은 부분이다.

// 인증 정보 설정 (ROLE_USER 부여)
List<GrantedAuthority> authorities = List.of(new SimpleGrantedAuthority("ROLE_USER"));

UsernamePasswordAuthenticationToken authentication =
                new UsernamePasswordAuthenticationToken(userId, null, authorities);

SecurityContextHolder.getContext().setAuthentication(authentication);

조금 보기 힘들 수 있으니 익명 인증이 활성화 되는 흐름을 먼저 정리해보겠다. (다음 정리하는 내용은 SecurityConfig에서 설정해놓은 필터의 순서로 볼 수 있다.)

1. 요청이 들어옴

2. Filter Chain 실행

3. Custom Filter 실행 3-1. SecurityContextHolder.getContext().setAuthentication(auth) 를 제대로 설정하지 않으면 인증되지 않은 상태가 유지됨

4. SecurityContext의 Authentication 값 확인 SecurityContextHolder.getContext().setAuthentication() 값이 null이거나 isAuthenticated() == false일 경우 AnonymousAuthenticationToken 이 자동으로 설정됨 (자동으로 익명 인증 객체가 생성된다는 뜻)

5. 이후 인증이 필요한 경로에 접근할 경우 지속해서 AnonymousAuthenticationToken가 인증 객체로 사용된다.

6. SecurityConfig에서 보면 CustomFilter 후에 UsernamePasswordAuthenticationFilter 를 실행하도록 하였는데 UsernamePasswordAuthenticationFilter 는 JWT 토큰과 관련된 인증 필터이므로 SignatureAuthFilter 이후 아무 역할을 하지 않는다.

7. SecurityContext가 유지되지 않는다면, 다음 요청 시에도 익명 인증 객체가 설정됨 SecurityContextHolder.getContext().setAuthentication(auth)을 제대로 설정하지 않으면 매 요청마다 SecurityContext가 AnonymousAuthenticationToken을 생성하게 됨 결국 모든 요청이 익명 사용자로 처리됨

이렇게 정리해도 어려운건 매한가지 인것 같다.

다만 4번 부터 문제일 것이라 생각되었고, 조금 크리티컬한 문제는 CustomFilter 실행 후 아무런 역할을 하지 않는 필터가 작동하기 때문에 AnonymousAuthenticationFilter 이전에 인증 객체를 설정하는 커스텀 필터를 작동하면 문제가 해결될 것이라 생각하고 필터의 순서를 바꿔도 보았다.

아쉽게도 이전에 실행하는 필터를 변경한다해도 문제가 없어지지는 않았다.

해결법

그래서 나는 필터 방식을 버리고 Interceptor 방식을 택했다.

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig implements WebMvcConfigurer {

    private final GatewayAuthenticationInterceptor gatewayAuthenticationInterceptor;

    @Bean
    public PasswordEncoder getPasswordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .cors(cors -> cors.configurationSource(corsConfigurationSource()))
                .csrf(AbstractHttpConfigurer::disable)
                .sessionManagement(sessionManagement ->
                        sessionManagement.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                )
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll()
                        .requestMatchers("/v1/users/email","/v1/users/signup").permitAll()
                        .requestMatchers("/v1/users/**").permitAll()  // 모든 /v1/users/** 경로 허용
                        .anyRequest().permitAll()  // 다른 모든 요청도 허용
                );
        return http.build();
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(gatewayAuthenticationInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns(
                    "/error",
                    "/v1/users/signup",
                    "/v1/users/email",
                    "/v1/auth/login"
                );
    }
}

@Component
public class GatewayAuthenticationInterceptor implements HandlerInterceptor {

    @Autowired
    private GatewaySignatureVerifier signatureVerifier;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        String userId = request.getHeader("X-User-Id");
        String timestamp = request.getHeader("X-Timestamp");
        String signature = request.getHeader("X-Signature");

        if (userId == null || timestamp == null || signature == null) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }

        boolean isValid = signatureVerifier.isValidSignature(
            userId,
            Long.parseLong(timestamp),
            signature
        );

        if (!isValid) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }

        return true;
    }
} 

인터셉터 방식을 적용하기 위해 일단 Spring Security의 모든 경로에 대해 접근을 허용하도록 변경했다.

그 후 모든 경로에 인터셉터를 추가하였고, 따라서 모든 요청에 헤더를 검증할 수 있도록 구현되었다.

6번 포스팅의 하단부분에 다음과 같이 적어뒀었다.

보안적인 주의점 일단 X-User-Id 헤더와 같은 경우 Client에서의 직접적인 입력을 반드시 막아야 한다.

Gateway에서 입력해야 인증객체가 설정되는 것이기 때문에 외부에서 입력할 경우 정상적으로 작동하지 않을 가능성이 높으며 탈취와 같은 위험이 존재할 수 있다.

이러한 문제를 해결하기 위해 몇 가지 방법이 존재했는데 나는 이번에 Signature를 생성하는 방법으로 하고자 한다.

가장 보안이 좋다고 알려져있는 방식은 내부 통신만 허용하는 방식인데... 어려워서 포기했다... (다음에 공부해보고 도입해보도록 하겠다.)

여튼 X-User-Id 방식의 보안적 취약을 해결하는 보편적인 방법은 X-User-Id 에 기반하여 X-Signature 를 API GateWay에서 생성하는 방식이다.

이렇게 gateway에서 두 가지 헤더가 나오게 된다면 각 마이크로 서비스에서는 X-Signature 검증만 통과하면 된다.

TCP 3-Way Handshake에서 각 패킷이 인증 정보를 포함하듯이, X-Signature 방식도 API Gateway가 검증 가능한 정보를 포함하여 보안성을 강화하는 방식이다.

다만 예시를 이렇게 들었다고 해서 해당 방식이 동일하지는 않다.

3-Way Handshake는 양방향 통신을 위해 연결을 설정하는 과정이며, X-Signature는 서버 간 신뢰성을 검증하는 보안 장치의 개념이다.

Signature 구현

앞서 Signature가 가져야 하는 특성이 있다.

• HMAC(해시 기반 메시지 인증 코드) 또는 RSA 서명을 사용하여야 한다.
• X-Signature는 유효 기간을 포함하여 재사용 방지(Replay Attack 방어)를 위한 타임스탬프를 추가해야 한다.

이 두 가지 특성을 염두하고 구현을 시작하도록 하겠다.

HMAC(해시 기반 메시지 인증 코드)

이번에는 HMAC을 이용하여 구현하도록 하겠다.

SignatureUtil

SignatureUtil 클래스를 구현하도록 하겠다. 먼저 Signature를 생성하기 위해 SecretKey부터 생성해야 한다. openssl rand -hex 32 명령어를 터미널에 입력하여 시크릿 키를 생성해야 한다.

그리고 암호화 알고리즘을 설정하여 해싱할 수 있도록 한다. private static final String HMAC_ALGORITHM = "HmacSHA256";

이제 다음으로는 직접 서명을 생성해야 한다.

jwt token으로 부터 가져온 userId와 현재 시간을 기준으로 Timestamp를 생성하여 서명 문자열을 생성한다.

String message = userId + ":" + timestamp;

Mac mac = Mac.getInstance(HMAC_ALGORITHM);
SecretKeySpec secretKeySpec = new SecretKeySpec(secretKey.getBytes(StandardCharsets.UTF_8), HMAC_ALGORITHM);
mac.init(secretKeySpec);
byte[] hash = mac.doFinal(message.getBytes(StandardCharsets.UTF_8));
return Base64.getEncoder().encodeToString(hash);

먼저 지정한 알고리즘을 통해 mac인스턴스를 초기화 하고 비밀키를 설정한다. 그 후 서명 문자열을 해시 계산하고 계산된 해시를 Base64로 인코딩하여 서명을 생성한다.

@Component
public class GatewaySignatureUtil {

    @Value("${gateway.security.secret-key}")
    private String secretKey;

    private static final String HMAC_ALGORITHM = "HmacSHA256";

    public String createSignature(String userId, long timestamp) {
        String message = userId + ":" + timestamp;
        try {
            Mac mac = Mac.getInstance(HMAC_ALGORITHM);
            SecretKeySpec secretKeySpec = new SecretKeySpec(secretKey.getBytes(StandardCharsets.UTF_8), HMAC_ALGORITHM);
            mac.init(secretKeySpec);
            byte[] hash = mac.doFinal(message.getBytes(StandardCharsets.UTF_8));
            return Base64.getEncoder().encodeToString(hash);
        } catch (NoSuchAlgorithmException | InvalidKeyException e) {
            throw new RuntimeException("Failed to create signature", e);
        }
    }
} 

CustomHeader 추가

6번 포스팅 코드에 추가하면 되며, 추가할 내용도 매우 간단한다.

기존에 작성했던 Filter에 Util 클래스 의존성을 추가해주고 Signature 만 생성할 수 있도록 한다.

// 타임스탬프 생성
long timestamp = System.currentTimeMillis();

// 서명 생성
String signature = gatewaySignatureUtil.createSignature(userId, timestamp);

// 새로운 헤더 추가
ServerWebExchange mutatedExchange = exchange.mutate()
        .request(builder -> builder
                .header("X-User-Id", userId)
                .header("X-Timestamp", String.valueOf(timestamp))
                .header("X-Signature", signature))
                .build();

여기까지가 Gateway에서 진행할 내용이다.

각 서비스에서

일단 UserService에서 진행하였으며, 따로 Filter를 구현해서 인증 객체를 설정하는 방법이 아닌 Interceptor를 생성하여 모든 요청을 가로채는 방식으로 구현했다.

SecurityConfig

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig implements WebMvcConfigurer {

    private final GatewayAuthenticationInterceptor gatewayAuthenticationInterceptor;

    @Bean
    public PasswordEncoder getPasswordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .csrf(AbstractHttpConfigurer::disable)
                .sessionManagement(sessionManagement ->
                        sessionManagement.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                )
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll()
                        .requestMatchers("/v1/users/email","/v1/users/signup").permitAll()
                        .requestMatchers("/v1/users/**").permitAll()  // 모든 /v1/users/** 경로 허용
                        .anyRequest().permitAll()  // 다른 모든 요청도 허용
                );
        return http.build();
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(gatewayAuthenticationInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns(
                    "/error",
                    "/v1/users/signup",
                    "/v1/users/email",
                    "/v1/auth/login"
                );
    }
}

SecurityConfig에서 봐야 할 곳은 모든 경로에 대한 접근을 허용했다는 점이다. 모든 경로의 대한 접근을 허용한 후 모든 경로에 Interceptor를 작동하게 하여 매 요청마다 검증하는 방식으로 구현되었다.

@Component
public class GatewayAuthenticationInterceptor implements HandlerInterceptor {

    @Autowired
    private GatewaySignatureVerifier signatureVerifier;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        String userId = request.getHeader("X-User-Id");
        String timestamp = request.getHeader("X-Timestamp");
        String signature = request.getHeader("X-Signature");

        if (userId == null || timestamp == null || signature == null) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }

        boolean isValid = signatureVerifier.isValidSignature(
            userId,
            Long.parseLong(timestamp),
            signature
        );

        if (!isValid) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return false;
        }

        return true;
    }
} 

보완할 점과 고려해야 할 점

인터셉터는 Spring Security 필터보다 먼저 실행된다.

지금은 모든 요청에 대해 permitAll() 방식으로 되어있기 때문에 문제가 생길 가능성은 없지만 고려해야 할 점은 다음과 같다.

인터셉터에서 인증 실패 시 false를 반환하는 방식과 Spring Security 자체적인 인증/인가 로직의 충돌 가능성이 있다.

특정 엔드포인트에 hasRole(), hasAuthority(), 같은 접근 제어가 걸릴 경우 문제가 발생할 수 있다.

서버 간 요청 재사용(Replay Attack) 방어 필요

해당 부분은 구현하면서 발견했던 문제점이다.

현재 X-Timestamp 기반으로 검증을 수행하지만, timestamp 값이 유효한지 확인하는 로직이 없기 때문에 다음 포스팅에 짤막하게 추가하고 넘어가도록 하겠다.

Spring WebFlux와의 호환성

이건 계속 고민하고 있는 문제였다. 아마 추후에도 MVC 기반과 WebFlux 기반의 문제 때문에 충돌할 가능성이 있다고 생각된다.

만약 Spring WebFlux 기반으로 완전 전환한다면, WebFilter 방식으로 인터셉터를 대체하는 것이 더 적절할 수도 있을 것 같지만 일단은 현재 방식으로 구현하도록 하겠다.

Spring WebFlux

Spring WebFlux에 대해 조금 더 알고 가야 한다.

https://inpa.tistory.com/entry/👩‍💻-동기비동기-블로킹논블로킹-개념-정리 [Inpa Dev 👨‍💻:티스토리] 위 블로그에서 자세하게 나와있는 것 같다.

먼저 Spring WebFlux를 한 문장으로 정의하면

Spring WebFlux 는 비동기 + 논블로킹 + 반응형 기반의 웹 프레임워크

라고 정의할 수 있는데... 벌써부터 어질하다.

또한 기존의 Spring MVC는 동기 + 블로킹I/O 기반으로 되어있다면 Spring WebFlux는 비동기 + 논블로킹 기반으로 되어있다는 특징이 존재한다.

표로 요약해보면 다음과 같이 나온다.

기존 Spring MVC의 동기(Blocking I/O) 모델

Spring MVC는 서블릿(Servlet) 기반의 프레임워크로, 내부적으로 동기(Blocking) 방식의 I/O 처리를 사용한다.

Spring MVC의 주요 특징

1. Thread-per-request 모델

• 요청이 들어오면 스레드를 할당하고, 응답이 끝날 때까지 해당 스레드가 차단됨.
• 요청 수가 많아지면 스레드가 부족해지고, 성능이 저하됨.

2. Blocking I/O (동기 방식)

• 데이터베이스 쿼리, API 호출 등의 작업이 끝날 때까지 스레드가 대기(Block)함.
• CPU 리소스를 비효율적으로 사용하게 됨.

Spring WebFlux와 비동기(Non-blocking) I/O

Spring WebFlux는 Reactor 기반의 비동기 논블로킹(Non-blocking) 방식을 사용한다. 즉, 요청이 들어와도 스레드가 대기하지 않고, 이벤트가 발생하면 비동기적으로 처리한다.

###Spring WebFlux의 주요 특징

1. Event Loop 모델

• 요청을 스레드 하나에서 여러 개 처리 가능
• 기존의 스레드 차단 방식(Blocking I/O) 대신 비동기 이벤트 기반(Non-blocking I/O) 사용

2.Reactor 기반의 Reactive Streams 지원

• Mono(01개) 또는 Flux(0N개)를 반환
• 데이터가 준비되면 이벤트 기반으로 Subscriber가 데이터를 받음
• 기존 Blocking 코드보다 더 많은 동시 요청 처리 가능

비동기

비동기는 다들 알듯이 프로그래밍에서 비동기는 작업이 독립적으로 실행되며, 작업이 시작되면 해당 작업이 완료될 때까지 기다리지 않고 다음 코드를 실행할 수 있다는 것을 의미한다.

논 블로킹

논블록킹은 단어에서 알 수 있듯이 다른 요청의 작업을 처리하기 위해 현재 작업을 block(차단, 대기) 하냐 안하냐의 유무를 나타내는 프로세스의 실행 방식이다.

Reactor

Reactor는 Spring WebFlux에서 비동기 스트림을 처리하기 위해 사용하는 라이브러리

• Reactive Streams 표준을 구현한 라이브러리이며, Publisher-Subscriber 패턴을 기반으로 동작한다.
• Mono 와 Flux라는 두 가지 기본 데이터 타입을 제공한다.

Reactive Streams

Reactive Streams는 비동기 + 논블로킹 + 백프레셔 지원을 위한 표준 스펙으로 데이터 스트림을 효율적으로 처리할 수 있도록 설계된 비동기 데이터 흐름 표준

Reactive Streams가 필요한 이유

위에서 잠깐 얘기했듯이 기존의 Spring MVC 즉, 블로킹 방식에서는 데이터의 소비 속도보다 공급 속도가 빠르면 성능 저하 및 메모리 과부하가 발생한다.

이쯤에서 Reactor는 잠깐 끊어야겠다. 당연히 Spring WebFlux가 Reactor 기반이니까 계속 공부하는게 나을 수 있지만 지금은 어떤 특성을 가지고 있는지 알고만 가는게 맞다고 생각된다.

여튼 요약하자면 Spring WebFlux 는 대용량의 데이터와 대규모 트래픽을 유연하고 안정적으로 처리할 수 있는 라이브러리 기반으로 제작된 프레임워크라는 것이다.

Mono & Flux (Reactive Streams 구현체)

Spring WebFlux에서는 Reactor 라이브러리를 사용하며, Reactor는 Reactive Streams를 구현하고 있다. Mono와 Flux는 Reactive Streams 인터페이스를 구현한 Reactive 타입이다.

Mono와 Flux는 각각 위와 같은 특성을 가지고 있는데 지금까지 작성했던 내용을 보고 지난 포스팅에서의 반환 타입이 Mono인 것을 보면 왜 Mono를 사용했는지 알 수 있다.

왜 Mono였을까?

1. MSA의 가장 큰 특징은 각 서비스(컴포넌트)가 이벤트를 비동기적으로 송수신 하며 자신의 업무를 계속해나간다.

2. Spring WebFlux 는 비동기 + 논블로킹 + 반응형 기반의 웹 프레임워크이며, Spring WebFlux의 filter() 메서드는 논블로킹 방식으로 작동해야 한다. ( Spring WebFlux는 비동기 + 논블로킹 기반의 프레임워크이므로, 내부에서 실행되는 모든 필터(WebFilter) 역시 논블로킹 방식으로 동작해야 성능을 극대화할 수 있다. )

3. JWT 필터에서 단일 인증 객체를 처리하기 때문이다. (0~1개의 데이터 처리)

이러한 3가지 이유로 Filter에서 Mono를 통해 인증 객체를 전달하는 것이다.

Exchange

대충 하면 안되겠지만 이만하면 겉핥기정도는 된 것 같다. 그래서 다음 내용으로 Exchage에 관한 내용을 짧막하게 적고 가겠다.

Exchange가 어디서 나왔냐면... SecurityConfig나 JwtFilter에 모두 나왔다.

일단 Spring WebFlux가 Netty기반으로 되어있다. 기존의 Spring MVC 에서는 Tomcat 기반이었고, Tomcat은 Servlet기반의 블로킹 형태의 WAS다. 그렇다면 Spring WebFlux는 Netty 기반이고, Netty는 논블로킹 형태의 WAS다.

이러한 특징으로 Spring Webflux를 사용하는 MSA에서 ServerWebExchange를 사용한다. (exchange는 Request + Response를 한 번에 관리할 수 있기 때문에 WebFlux에서 사용된다.)

지난 포스팅에서 User와 Auth간의 소통을 구현했었는데 별개의 서버에서 API를 불러다 사용하는 방식으로 구현했었다.

그렇지만 MSA는 서버간의 직접 소통을 권하지는 않는다.

이 문제를 해결하기 위해서 API Gateway를 설정하고 모든 서비스는 API Gateway를 통하여 소통하도록 구현해야 한다.

JwtUtil

먼저 gateway에 JwtUtil을 구현한다.

Auth-Service 에서 받아온 로그인을 위한 인증 토큰을 사용하기 위해 필요한 구성이다.

@Component
public class JwtUtil {

    // TODO : Secret Key 환경 변수로 수정
    private final String SECRET_KEY = "2~~";

    public String extractEmail(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET_KEY.getBytes(StandardCharsets.UTF_8))
                .parseClaimsJws(token)
                .getBody()
                .getSubject();
    }

    public boolean validateToken(String token) {
        try {
            Jwts.parser()
                    .setSigningKey(SECRET_KEY.getBytes(StandardCharsets.UTF_8))
                    .parseClaimsJws(token);
            return true;
        } catch (JwtException | IllegalArgumentException e) {
            return false;
        }
    }
}

지금은 간단한 구현이기 때문에 SECRET_KEY 자체를 하드코딩 해두었다.

그 다음으로는 정보 추출과 토큰 검증이다.

JwtAuthenticationFilter

@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter implements WebFilter {
    private final JwtUtil jwtUtil;
    private static final List<String> EXCLUDED_PATHS = List.of("/v1/auth/login", "/v1/users/email", "/v1/users/signup");

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
        String path = exchange.getRequest().getURI().getPath();

        if (EXCLUDED_PATHS.contains(path)) {
            return chain.filter(exchange);
        }

        String authHeader = exchange.getRequest().getHeaders().getFirst(HttpHeaders.AUTHORIZATION);
        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            return onError(exchange, "Missing or Invalid Authorization Header", HttpStatus.UNAUTHORIZED);
        }

        String token = authHeader.substring(7);
        if (!jwtUtil.validateToken(token)) {
            return onError(exchange, "Invalid JWT Token", HttpStatus.UNAUTHORIZED);
        }

        // userId 추출
        String userId = jwtUtil.extractEmail(token);

        // userId를 헤더에 추가해서 downstream service로 넘겨줌
        ServerWebExchange mutatedExchange = exchange.mutate()
                .request(builder -> builder.header("X-User-Id", userId))
                .build();

        return chain.filter(mutatedExchange);
    }

    private Mono<Void> onError(ServerWebExchange exchange, String err, HttpStatus status) {
        exchange.getResponse().setStatusCode(status);
        return exchange.getResponse().setComplete();
    }
}

전체 코드는 이러하며 각 코드가 하는 일을 조금 살펴보도록 하겠다.

WebFilter

일단 MSA 관점에서 API Gateway 레이어에서 인증 처리는 대표적인 패턴이다.

WebFilter는 Spring WebFlux의 비동기 논블로킹 필터로서, Gateway의 필터 체인에서 모든 요청 전처리 역할을 수행한다.

이 말은 다음과 같이 정리할 수 있다.

• servlet filter가 아닌 Reactive 환경에 맞춰 설계된 필터
• 비동기 스트림에서 효율적인 성능 제공
• ServerWebExchange 로 요청과 응답을 통째로 다룰 수 있어 헤더 수정, Body 조작 등 유연성 확보
• API Gateway 레이어에서 권한 체크, 토큰 파싱, 인증 실패 차단 등 전방위 컨트롤 가능

WebFlux

https://adjh54.tistory.com/232

ServerWebExchange

ServerWebExchange는 불변 객체로 mutate로 복제 후 헤더에 X-User-Id라는 헤더를 추가하여 다른 서비스로 넘겨주는 방식이다.

ServerWebExchange mutatedExchange = exchange.mutate()
    .request(builder -> builder.header("X-User-Id", userId))
    .build();

Security Config

@Configuration
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    public SecurityConfig(JwtAuthenticationFilter jwtAuthenticationFilter) {
        this.jwtAuthenticationFilter = jwtAuthenticationFilter;
    }

    @Bean
    public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http) throws Exception {
        http
                .csrf(ServerHttpSecurity.CsrfSpec::disable)
                .authorizeExchange(exchanges -> exchanges
                        .pathMatchers("/v1/auth/**").permitAll()
                        .pathMatchers("/v1/users/**").permitAll()
                        .pathMatchers("/logout").permitAll()
                        .pathMatchers("/error").permitAll()
                        .anyExchange().authenticated()
                )
                .addFilterAt(jwtAuthenticationFilter, SecurityWebFiltersOrder.AUTHENTICATION);

        return http.build();
    }
}

평소에 사용하던 Security Config 와 비슷하지만 authorizeExchange 라던가 pathMatchers 처럼 경로를 허용하는 방식등 기존의 Web MVC 패턴이 아닌 경로 형태로 진행된다.

위와 같이 구현하면 다른 서비스에서도 인증이 가능하다.

보안적인 주의점

일단 X-User-Id 헤더와 같은 경우 Client에서의 직접적인 입력을 반드시 막아야 한다.

Gateway에서 입력해야 인증객체가 설정되는 것이기 때문에 외부에서 입력할 경우 정상적으로 작동하지 않을 가능성이 높으며 탈취와 같은 위험이 존재할 수 있다.

끝!

이번 포스팅은 조금 공부가 더 필요할 것 같기 때문에 다음 포스팅에서는 WebFlux, Mono등 조금 더 용어나 그 외의 주요 특징들을 다루는 글을 적도록 하겠다.

물론 지금은 PathVariable 방식을 사용해도 큰 문제가 없으나 나중을 고려해서 RequestBody 방식으로 수정하여 사용하려 했다.

@FeignClient(name = "msa-user-service", url = "http://localhost:8081") // in local environment 
public interface UserServiceClient {
    @GetMapping ("v1/users/email")
    UserDto findUserByEmail(@RequestBody EmailRequestDto email);
}

UserController 내에서도 당연히 정보를 얻어오는것이니까 GetMapping을 사용했고 그에따라 FeignClient 역시 GetMapping으로 설정했다.

처음에는 이렇게 하고 포스트맨에서 api를 호출해보니 403에러가 발생했다.

403?

403이면 뭐 SecurityConfig에서 CORS 설정을 안해줬겠지 하고 부랴부랴 UserService에 CORS 설정을 해주었다.

왜 CORS 부터 의심했냐면 결국 두 가지의 서비스이기 때문에 port 번호가 달라 접근할 수 없다고 생각했다.

그래도 403

여튼 UserService에 CORS 설정을 해두어도 계속 403 에러가 발생했다.

그렇다면 의심해볼 내용은 역시 FeignClient일 것 같다. FeignClient를 계속 찾아보면서

https://yijoon009.tistory.com/entry/Parameter-Handling-in-Spring-Boot-Using-Feign-Client

위의 블로그 내용이 어쩌다가 서치가 되었는데

RequestBody의 주의점으로 GET 요청에는 적합하지 않다 라는 내용이 존재한다.

POST로 바꾸자

그래서 두 곳의 메서드 모두 POST 로 변경했다.

그리고 실행해보면...

로그인 결과가 잘 나오는걸 볼 수 있다.

뒤늦게 알게 된 사실

AuthService만의 문제라고 생각해서 AuthService의 로그만 보고있었다.

그렇지만 403만 알려주니까 왜 그런지 몰랐는데...

UserService에서 친절하게 얘기하고 있었다. POST 요청 들어오는데 POST 요청은 없어서 못받는다고...

왜 Feign Client는

RequestBody를 보낼 때 POST만 가능할까?

답은 이전 포스트에서 얘기했었다.

Feign Client는 Spring Cloud에서 제공하는 HTTP 클라이언트로, REST API 호출을 인터페이스 기반으로 간결하게 구현할 수 있도록 도와주는 라이브러리

라고 요약했는데 다른 말로 풀어보면 Feign Client는 HTTP 클라이언트를 구현한 인터페이스라서 HTTP 요청의 특성을 그대로 따르게된다.

결국 HTTP 요청 본문을 포함할 수 있는 메서드가 POST, PUT, PATCH 메서드 밖에 없다.

아마 조금 더 Feign Client를 일찍 찾아봤다면 하지 않았을 실수 같다...

User

그렇지만 User는 매우 간단하다.

지난 포스팅에서 얘기 했듯이 회원을 등록하는게 User-Service가 하는 일이다.

다만 1가지 추가가 되었는데 Auth에서 해당 User를 찾을 수 있도록, Email을 통한 Read 작업이라고 할 수 있다.

회원 가입

회원 가입은 매우 간단하다.

    @Transactional
    public void signup(SignupRequestDto requestDto) {
        String encodedPassword = passwordEncoder.encode(requestDto.getPassword());

        // 저장하기 전 User 객체 생성
        User newUser = User.builder()
                .username(requestDto.getUsername())
                .email(requestDto.getEmail())
                .password(encodedPassword)
                .phoneNumber(requestDto.getPhoneNumber())
                .role(UserRole.USER)
                .build();

        // User가 이미 존재하는지 확인
        if(userRepository.findByEmail(newUser.getEmail()).isEmpty()) {
            userRepository.save(newUser);
        } else {
            throw new CustomException(ErrorCode.CONFLICT_USER);
        }
    }

단순하게 Dto에 담긴 내용을 꺼내 이미 newUser로 객체 생성한 뒤

조건을 통해 isEmpty를 만족한다면 기존에 존재하지 않은 email로 인식하여 가입에 성공하고, 그 외의 경우는 중복 처리를 해준다.

회원 조회

회원 조회 역시 간단하다.

    @Transactional(readOnly = true)
    public UserDto findEmail(String email) {
        User user = userRepository.findByEmail(email)
                .orElseThrow(() -> new CustomException(ErrorCode.USER_NOT_FOUND));

        return UserDto.builder()
                .id(user.getId())
                .username(user.getUsername())
                .email(user.getEmail())
                .phoneNumber(user.getPhoneNumber())
                .role(user.getRole().toString())
                .build();
    }

딱히 설명할 게 없으므로 Pass하도록 하겠다.

Auth

그 전에..

일단 서비스 로직을 작성하기 전에 잠깐 얘기하자면

User와 Auth를 분리하기로 했다.

가능하면 지금부터 분리할 수 있는 내용은 분리하는게 조금 더 낫다는 판단이 있었기 때문이다.

초기 설정

일단 Auth 서비스는 현재 시점 기준으로 db를 따로 갖고있지 않는다. 아마 OAuth나 그 외의 서드파티 로그인을 구현한다 해도 DB를 가지고 있지 않을 예정이다.

User 서비스의 어떤 방식으로 가입했는지 구분할 수 있는 컬럼이 생기는 변화가 존재할 예정이다.

따라서 매번 하던 SpringBoot 의존성 추가에 JPA라거나 DB 관련한 드라이버는 제외해야 한다. 또한 properties, yml 역시 db연결 부분을 제외해줘야 한다.

내용추가

로그인

로그인 시점에서 Auth 서비스는 입력받은 email을 기반으로 회원이 존재하는지 확인해야 한다.

하지만 DB를 소유하고 있지 않기 때문에 User 서비스의 DB에서 email에 맞는 User 정보를 가져와야 한다.

그리고 가져온 정보를 토대로 JWT를 발급한다.

UserServiceClient ( FeignClient )

먼저 UserServiceClient 라는 인터페이스를 생성해준다.

@FeignClient(name = "msa-user-service", url = "http://localhost:8081") // in local environment 
public interface UserServiceClient {
    @PostMapping ("v1/users/email")
    UserDto findUserByEmail(@RequestBody EmailRequestDto email);
}

먼저 코드를 보면 FeignClient라는게 보인다.

• https://velog.io/@choidongkuen/FeignClient-사용법에-대해-알아봅시다.-Spring-Cloud-OpenFeign
• https://velog.io/@skyepodium/2019-10-06-1410-작성됨

잘 정리된 글이 있어 가져왔다.

일단 여기서 간단하게 요약한다면

Feign Client는 Spring Cloud에서 제공하는 HTTP 클라이언트로, REST API 호출을 인터페이스 기반으로 간결하게 구현할 수 있도록 도와주는 라이브러리

일반적인 RestTemplate 또는 WebClient보다 코드가 간단하고, 선언적인 방식으로 API 호출 가능

대충 HTTP 클라이언트의 기능을 간단한 코드로 구현한 내용이라고 생각하면 된다.

다시 코드로 넘어와서

@FeignClient(name = "msa-user-service", url = "http://localhost:8081") // in local environment 
public interface UserServiceClient {
    @PostMapping ("v1/users/email")
    UserDto findUserByEmail(@RequestBody EmailRequestDto email);
}

해당 코드를 통해 http://localhost:8081/v1/users/email 에 접근하여 결과를 받을 수 있다는 점이다.

따라서 저 코드를 통해 받는 정보는 위에서 작성했던 회원 조회의 결과값이다.

AuthService

이제 위에서 구현한 코드를 실제로 사용할 타이밍이다.

@Service
@RequiredArgsConstructor
public class AuthService {

    private final UserServiceClient userServiceClient;
    private final JwtUtil jwtUtil;
    private final PasswordEncoder passwordEncoder;

    public String login(LoginRequestDto requestDto) {
        // 1. email 을 통해 UserService 에서 UserDto 로 객체 생성
        EmailRequestDto emailRequestDto = new EmailRequestDto(requestDto.getEmail());
        UserDto user = userServiceClient.findUserByEmail(emailRequestDto);

        // 2. UserDto 의 password 와 request 의 password 를 비교
        if (!passwordEncoder.matches(requestDto.getPassword(), user.getPassword())) {
            throw new CustomException(ErrorCode.AUTHENTICATION_FAILED);
        }

        // 3. JWT 토큰 생성
        return jwtUtil.generateToken(user.getEmail());
    }
}

일단 Mono Repo와 Poly Repo의 차이를 간략하게 알아보자

Mono Repo vs Poly(Multi) Repo

• Mono Repo : msa-shopping-mvp 하나로 통합

즉 우리가 그냥 Github에 생성하는 하나의 Repo를 말하는 것 같다. 아마 지금까지 해온 Monolithic의 Mono랑 같은 맥략인듯 하다.

• Poly(Multi) Repo : user-service, order-service, cart-service 등으로 분리 (운영 확장성↑)

MSA의 특징은 각 서비스가 독립적으로 분리되어있고, 그에 따라 DB 역시 독립적으로 존재한다는 것이다.

즉, Repo 역시 여러개 존재하는 구조가 Poly(Multi) Repo이다.

내가 생각하기에 MSA 구조인 만큼 MVP를 만든다 하여도 Poly Repo 구조로 시작해보는게 나을 것 같다. (뭐 CI/CD가 힘들 수 있지만 어떻게든 되겠지)

Poly(Multi) Repo 설정

딱히 설정이라고 할 건 없다.

다만 repo를 여러개 생성하는 것인데... 그 repo를 하나의 Repo로 묶어서 관리하는 방법도 존재하겠지만

나는 이번에 Organization을 생성하여 관리하도록 할 예정이다.

Organization을 생성하면 권한 관리와 협업이 어렵움과 CI/CD 구성의 불편함도 해소 될 수 있다.

개발 순서

를 정하기 전에 API Gateway에 대해 조금 더 알아보자

예전에 잠깐 Node.js를 봤을 때, 정확히는 Express.js를 사용할 때 routes를 생성해서 하는 방식이 API Gateway랑 비슷한 방식일것이라고 짐작으로 예상했었다.

다만 Express에서는 단순하게 클라이언트의 요청을 핸들러로 넘기는, REST API의 엔드포인트 관리만을 담당한다.

그에 반해 API Gateway는 각각의 마이크로 서비스의 요청을 라우팅하기 때문에 라우팅 범위에서도 꽤나 다르게 작동하며 보안, 로드 밸런싱, 장애 대응, 트래픽 제한 등의 추가 기능 역시 API Gateway에서 담당한다.

일단 내가 중요하다고 생각했던 내용은 라우팅에 관련한 내용이며 라우팅과 Security관련된 내용을 API Gateway에 작성해야 하고 따라서 개발 순서도 Gateway가 1순위이며 그 외에 각 서비스로 진행될 줄 알았다.

개발 순서

그렇지만 라우팅을 하기 전에 각 서비스에서 비지니스 로직을 구현하고, 각 서비스에서 제작된 API들을 API Gateway쪽으로 넘기는 방식으로 진행 될 것 같다.

가장 처음으로

그래서 가장 처음 개발할 서비스 로직은 아마 User (& Auth) 쪽이지 않을까 싶다.

개발할 내용으로는 다음과 같으리라 예상된다.

User Service

1. 회원 가입

Auth Service 2. 로그인 (당장에는 email 로그인이기 때문에 User에 위치할 가능성이 높음) 3. JWT 발급

각 서비스에서 JWT 발급이 끝난다면

API Gateway

1. JWT 검증 및 사용자 정보 추출(Filter)
2. 인증된 요청을 각 서비스로 전달

검증까지 필요하다면 API Gateway전에 상품을 올리는 product Service로 검증해볼 수 있겠다.

끝!

다음 포스팅 부터는 진짜 개발이 진행될 예정이다.

확정된 기술은 다음과 같으며

MSA 기반이므로 각 서비스의 기술 스택 확정 Spring Boot → User/Auth, Product, Order, Cart 서비스 MySQL → 관계형 데이터 저장 Redis → 로그인 토큰 캐싱

아래의 기술은 조금 더 선별하는 과정이 필요하다.

Kafka or RabbitMQ → 주문 상태 변경 이벤트 처리 고려 Docker & Kubernetes → 서비스 배포 고려 API Gateway 필요 여부 검토 (ex: Spring Cloud Gateway, Kong API Gateway) CI/CD 파이프라인 구성 고려 (ex: GitHub Actions, Jenkins)

Kafka or RabbitMQ

일단 MSA 구조에서 해당 기술 스택이 필요한 이유는 다음과 같다.

• 주문이 생성되거나 상태가 변경될 때(확인됨, 배송 중, 완료됨 등) 다른 서비스(예: 결제, 알림, 배송)와 비동기적으로 이벤트를 주고받아야 함.
• 비동기 메시징을 통해 서비스 간 결합도를 낮추고 확장성을 높일 수 있음.

표를 통해 살펴보면 각 스택은 이러한 특징을 가지고 있다.

일단 대용량 처리나 로그 분석, 트래킹이나 스트리밍의 기능이 MVP 단계에서 필요하지 않기 때문에 Kafka 자체는 오버엔지니어링이라 보여질 수 있다.

• RabbitMQ → 주문 생성/취소 이벤트, 재고 업데이트 등의 메시징 용도
• Kafka → 실시간 로그 분석 또는 주문 상태 스트리밍이 필요하다면 고려

따라서 MVP에서는 RabbitMQ 먼저 적용 후, 필요 시 Kafka 확장

Docker & Kubernetes

MSA 구조는 각 서비스가 독립적으로 배포되어야 하는 구조이기 때문에 환경 일관성을 유지하고, 운영 효율성을 높이기 위해 컨테이너 기반 배포 필요하다.

Docker Compose로 MVP 배포 후 Kubernetes 확장은 나중에 고려

API Gateway 필요 여부

MSA에서는 여러 개의 서비스가 각각 API를 노출하기 때문에 API Gateway가 있으면 인증, 로드 밸런싱, CORS, API 버전 관리 등을 중앙에서 처리 가능하다.

또한 API Gateway 없이 클라이언트가 모든 서비스에 직접 요청하면 관리가 복잡해지고, 보안 리스크 증가할 수 있다.

그럼 어떤 API Gateway 옵션이 존재할까

다행?이도 Spring Cloud Gateway라는게 존재하고 Spring Boot 환경과 자연스럽게 통합이 가능한 API Gateway가 존재한다.

다만 트래픽이 많아질수록 Kong이 고려되는 경우도 있다고 한다.

MVP 단계에서는 Spring Cloud Gateway 사용 후, 트래픽 증가 시 Kong으로 확장 고려

CI/CD

Jenkins는 기업에서 많이 사용하는 엔터프라이즈급 CI/CD를 구축할 때 필요하다.

MVP 단계에서는 GitHub Actions을 당연히 사용해보겠지만 고도화 단계에서도 Jenkins는 고려해봐야 할 것 같다.

너무 MVP만 생각하는거 아닌가..?

위에서 정리한 내용을 보면 너무 MVP위주로 상대적으로 규모가 작은 스택만을 선별했다고 볼 수 있는데, 개발을 하면서 적절한 기술 스택을 선정하는 것 역시 중요하다고 생각한다.

뿐만 아니라 내가 여기서 사용해본 기술이 몇 개 되지 않는 점 역시 존재하기 때문에 MVP 에서 실제 서비스가 가능한 프로젝트로 바꾼다 하여도 결국에는 다 경험을 해봐야 하는 스택들이다.

이렇게 기술 스택을 고민하면 캠프를 진행할때 이따금씩 튜터님들이 말씀해주셨던 내용이 생각이 난다.기술 스택을 정해서 하나만 확 파보는 것이 취업에 더 도움이 될 수 있다는 내용이다.

물론 최근 공고를 봐도 해당 기술스택을 해본게 아닌 경험이 많은 사람을 찾는 내용도 많지만 다양한 기술을 사용하는 공고도 많이 보인다.

MVP를 만들고 고도화 시키는게 조금 번거롭다고 생각되기도 하고, MVP만 만들고 제풀에 꺾일 수 있겠지만 그래도 나는 가능하면 많은 스택을 경험해보는 것도 중요하다고 생각된다.

일단 MVP의 목표로 다음과 같이 선정했었는데

User Service → 회원가입 & 로그인 (JWT) Product Service → 상품 목록 조회 Cart Service → 장바구니 추가 Order Service → 주문 생성

아무래도 고도화 할 때 OAuth나 MFA 같은 기능을 추가하기 위해서는 인증 서비스를 분리하는 것이 더 효과적이면서 보안적인 향상이 이루어 질 것이란 판단이 있기 때문에

User Service → 회원가입 Auth Server → 로그인 (JWT) Product Service → 상품 목록 조회 Cart Service → 장바구니 추가 Order Service → 주문 생성

정도로 추가될 것 같다.

전체 서비스의 API 명세는 다음과 같이 나온다.

각 명세의 사용법과 Reponse는 링크에서 확인할 수 있다.

API 명세 : https://ten-tornado-b09.notion.site/MVP-API-1b06d194f5f980f881a1f8a48cbe963b?pvs=4

ERD는 개인적으로 작성해서 문서화 했기 때문에 따로 포스팅하지 않도록 하겠으며, 다음 포스팅은 각 서비스의 초기 설정과 API Gateway에 대해 적어 보도록 하겠다.

그리고 서비스 런칭 수준으로 프로젝트를 끌어올렸을 때 기준을 잡는다면 소요 기간은 아마 30-50일 사이로 잡히지 않을까 싶다.

짤막한 일정 선정 이유

• 0일 ~ 2주 : MVP
• 3주 ~ : 고도화 및 배포

일단 이번 포스팅에서는 핵심 기능 정의와 기술 스택 선별 그리고 해당 기술을 선택한 이유까지만 적어 보도록 하겠다.

1차 목표 - MVP

MVP에는 다음과 같은 기능을 담고자 한다.

• User Service → 회원가입 & 로그인 (JWT)
• Product Service → 상품 목록 조회
• Cart Service → 장바구니 추가
• Order Service → 주문 생성

일단 MSA를 경험하는게 먼저일 것 같다는 생각이 들어서 MVP를 위의 4가지 기능으로 선정했고, MVP외의 기능은 추후에 확장하며 진행하겠다.

핵심 기능 정의

사용자 관리(User Service)

회원 가입, 로그인, 비밀번호 변경 JWT 기반 인증 및 OAuth2 소셜 로그인 (카카오, 네이버 등)

상품 관리(Product Service)

상품 목록 조회, 검색 카테고리 및 브랜드별 필터링 상품 상세 페이지

장바구니(Cart Service)

사용자가 상품을 장바구니에 추가/삭제 수량 변경

주문 및 결제(Order & Payment Service)

주문 생성 (배송 정보 입력) 결제 처리 (카드, 가상계좌, 네이버페이 등) 주문 상태 변경 (결제 완료 → 배송 중 → 배송 완료)

재고 관리(Inventory Service)

주문 시 재고 감소 재고 부족 알림

리뷰 및 평점(Review Service)

상품에 대한 리뷰 작성 별점 평가 추천 및 검색(Search & Recommendation Service)

인기 상품 추천 Elasticsearch를 활용한 검색 최적화

고객 서비스(CS Service)

문의하기, 1:1 채팅 상담 환불/반품 처리

이벤트 및 쿠폰 관리(Coupon Service)

프로모션, 쿠폰 할인 적용 특정 유저 대상 이벤트

배송 관리(Delivery Service)

배송 추적 배송 상태 업데이트

기술 스택

일단 MSA에 초점을 맞춘 프로젝트기 때문에 프론트는 추후에 구현이 가능하거나 러닝커브를 고려한 후 선별을 하도록 하겠다.

기술 스택은 다음과 같이 정했다.

Backend : Java(Spring Boot 3.x)

DBMS

1) MySQL : 정형 데이터 관리 2) MongoDB : 비정형 데이터 관리 (로그, 채팅 메시지, 리뷰 등)

통신 방식 서비스 간 RESTful API RabbitMQ(이벤트 기반 처리)

RabbitMQ vs Kafka

https://yay-dev.tistory.com/157

왜 RabbitMQ를 쓰냐면...

사실 MSA구조의 서비스를 개발 심지어 초기에는 MVP를 목표로하기 때문에 대용량 처리나 매우 복잡한 아키텍쳐를 가질 필요가 없다는 판단이기 때문이다.

또한 추후에 CS관련 기술을 고려했을 때 아마도 1:1 채팅이 될 예정인데 지연 시간이 짧은 RabbitMQ가 메시지 처리 브로커로 조금 더 알맞지 않을까 싶기 때문이다.

(맘 같아선 서비스 간 통신은 Kafka, 채팅 서비스에서는 RabbitMQ였지만 작은 규모의 서비스에서 기술 다 때려넣는게 좋지 않은건 아니까..)

즉, 정리해보면 다음과 같이 정리되겠다.

• RabbitMQ: 지연 시간이 짧고, CS(1:1 채팅) 같은 빠른 응답이 필요한 서비스에 적합
• Kafka: 대용량 스트리밍 데이터 처리에 강점이 있지만, 초기 MSA에서는 과도한 복잡성 초래 가능

👉 결론: RabbitMQ를 사용하여 이벤트 기반 처리를 하되, 추후 Kafka 도입을 고려

일단 지금까지 코테나 기존에 작성했던 면접 질문들만 보고 있었는데

실전으로 코드를 작성할 기회 자체는 조금 없었던 것 같기 때문에 새로운 프로젝트를 진행해볼 생각이다.

얼마전 대학 동기와 얘기했을 때 친구 기준 사이드 프로젝트는 2가지 정도로 나뉜다는 것 같다고 얘기해줬다.

1. 내가 알고있고 사용해본 기술을 다 때려넣어서 만든 프로젝트
2. 실제 서비스 런칭을 목표로 진행하는 프로젝트

뭐 매번 그랬..? 공모전은 예외로 치면 항상 1번이 나에게는 주류였고, 이번에 생각난 목표를 도전해볼 겸 이번에도 1번의 형태로 진행될 것 같다.

일단 이번 목표는 예전에 진행했던 Hot-item-collector 서비스를 리팩토링 하는 겸 MSA 형태로 구현해볼 예정이다.