Chapter 2를 돌아보며 - 항해 플러스 회고 (5주차)

 

들어가며

벌써 항해를 시작하고 10주 과정의 절반 지점에 도착했다. 본업과 함께 강도 높은 과제를 수행하는 것이 쉽지는 않았지만, 절반이 지났다는 점에서 남은 절반도 금방 잘 해낼 수 있을 것 같다는 생각이 든다. 지난 5주 동안 우리 팀 5명 중 3명이 이탈했다. 대부분이 본업 때문에 과제에 집중하기 어려웠기 때문이었다. 다행히 나의 경우 회사가 바쁜 시즌이 아니어서 (물론 바쁘지 않아도 힘들지만) 여기까지 버틸 수 있었다.
 

그래도 열심히 했잖아?

 
지난 3주 동안 과제를 진행하면서 많은 것을 배우고 경험했다. 일 끝나고 새벽 2~3시까지 과제를 하며 피곤에 지쳐 있었지만, 덕분에 단기간에 큰 성장을 이룬 것 같다. 이번 회고에서는 프로젝트 Chapter 2(3~5주차)를 진행하면서 배운 점들과, 여전히 고민 중인 부분들을 정리해보려고 한다.
 
 

시나리오

이번 프로젝트는 콘서트 좌석 예약 서비스를 개발하는 것이었다. 예약 시스템에서는 대기열 관리가 매우 중요한 요소고, 여러 사용자가 동시에 좌석을 예약하려고 할 때 공정하게 예약을 처리하고 좌석 상태를 적절하게 관리하는 것이 핵심이었다. 각 기능마다의 비즈니스 로직이 생각보다 복잡하게 얽혀 있었고, 덕분에 여러 가지 고민과 새로운 접근 방식을 시도하면서 문제 해결에 대한 접근 방법이 확장된 느낌을 받았다.
 
 

목표

이번 프로젝트의 주요 목표는 아래와 같다.

1. 도메인에 대한 이해

콘서트, 예약, 결제라는 도메인에 대한 이해가 필요했다. 시나리오를 받은 후 제일 먼저 요구사항을 리스트로 작성하고, 도메인 별로 묶어 어떤 기능을 구현해야 할지에 대해 고민했다. 이를 통해 각 기능이 실제 도메인에서 어떻게 작동하는지를 이해하고, 비즈니스 로직을 설계하고 구현했다.

 

2. 비즈니스 로직의 명확한 분리

유지보수성을 높이기 위해 클린 & 레이어드 아키텍처에 따라 비즈니스 로직을 명확하게 분리하고, 각 계층의 역할을 정의했다. 하위의 레이어만 의존하는 단방향 의존성을 유지하려고 노력했다. 로직이 복잡해질수록 역할과 책임을 명확하게 분리하여 객체지향적 접근 방식으로 작성했다.
 

3. 동시성 문제 해결

좌석 예약 시 여러 사용자가 동시에 접근할 수 있는 상황에서 데이터의 일관성을 유지하며 충돌을 방지하는 것이 목표였다. 도메인 특성을 이해하고, 동시성 문제를 해결하기 위한 방법을 고민했다. 예를 들어, 유저의 포인트 충전 로직에서는 충전에 대한 순차 보장이 필요하지 않다고 판단하여 낙관적 락을 사용하고, 실패한 스레드에 대해서는 재시도하지 않고 에러 처리를 하도록 구현했다.
 

4. 새로운 기술 습득

코틀린과 JPA 같은 새로운 기술을 실무에 적용할 수 있는 수준으로 학습하고 활용하는 것도 중요한 목표 중 하나였다.
 
 
 

문제 및 시도, 해결 과정

 

1. 시퀀스 다이어그램 작성

이번에 처음으로 시퀀스 다이어그램을 작성했다. 복잡한 비즈니스 로직을 시각적으로 표현하면서 전체 흐름을 더 잘 이해할 수 있었고, 팀원들과의 커뮤니케이션에도 큰 도움이 되었다. 시퀀스 다이어그램을 통해 각 컴포넌트의 상호작용과 데이터 흐름을 명확하게 시각화할 수 있었고, 코드 구현에 소요되는 시간을 대폭 줄일 수 있었다. 앞으로도 프로젝트를 진행할 때마다 시퀀스 다이어그램을 적극적으로 활용할 계획이다.
시퀀스 다이어그램 작성 GitHub 링크
 

2. 대기열 시스템의 구현과 동시성 처리

대기열 시스템을 어떻게 구현할지, 특히 여러 사용자가 동시에 예약을 시도할 때 동시성 문제를 어떻게 해결할지가 큰 고민이었다. Redis 대신 RDB를 사용해 대기열을 구현하고, 비관적 락과 낙관적 락을 상황에 맞게 적용해 문제를 해결했다. 유저의 포인트 충전 로직에는 낙관적 락을 사용해 데이터베이스 부하를 줄이면서도 일관성을 유지했고, 좌석 예약이나 결제 등의 중요한 비즈니스 로직에는 비관적 락을 사용해 순서가 보장되고 일관성 있는 결과를 응답하도록 작성했다. 이 과정에서 동시성 문제를 해결하기 위한 다양한 방법들을 학습할 수 있었다.
동시성 처리 쉽게 이해하기
 

3. 테스트 코드 작성

좋은 테스트 코드란 무엇일까에 대해 많은 고민을 했다. 단순히 기능이 잘 동작하는지만 확인하는 것이 아니라, 다양한 실패 시나리오를 커버할 수 있는 테스트를 작성하려고 노력했다. 엣지 케이스와 실패 시나리오를 포괄하는 테스트를 통해 서비스의 안정성을 보장하고자 했다.

 
 

4. 대기열 토큰 관리

대기열 토큰 관리 방법으로 유저 인증과 대기열 토큰의 관계를 분리하고 세션 기반으로 토큰을 저장하는 방식을 시도했다. 이는 은행에서 대기표를 받듯이 다른 유저에게 대기표를 넘겨줄 수 있는 구조로 설계했다. 이를 통해 더 유연한 시스템을 구축할 수 있었다.

아래와 같이 user에 대한 식별자를 제거하고, token으로 대기열에 대한 상태만을 관리하도록 했다.

@Entity
class WaitingQueue(
    val scheduleId: Long,
    val token: String,
    status: QueueStatus,
    expiresAt: LocalDateTime?,
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,
) : BaseEntity() {
    @Enumerated(EnumType.STRING)
    var status: QueueStatus = status
        protected set

    var expiresAt: LocalDateTime? = expiresAt
        protected set

    fun expire() {
        status = QueueStatus.EXPIRED
    }

    fun activate(expireMinutes: Long) {
        this.status = QueueStatus.ACTIVE
        this.expiresAt = LocalDateTime.now().plusMinutes(expireMinutes)
    }
}

 

5. 코틀린에서의 JPA 사용

코틀린으로 JPA를 사용하는 것도 새로운 도전이었다. 특히 엔티티 선언 방식에 대해 인터넷을 검색해보면 의견이 분분했는데, 코치님의 실무 경험에 따른 조언을 바탕으로 ID를 null 대신 0으로 초기화하는 방식을 선택했다. 이를 통해 !! 연산자 사용을 줄일 수 있었고, JPA에서 엔티티를 저장할 때도 더 자연스럽게 동작하게 되었다.

예를 들어, 다음과 같은 방식으로 구현했다.

@Entity
class Concert(
    title: String,
    duration: Int,
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,
) : BaseEntity() {
    var title: String = title
        protected set

    var duration: Int = duration
        protected set
}

 
 

6. 애플리케이션 계층 관리

애플리케이션 계층은 가능한 얇게 유지하고, 비즈니스 로직은 도메인에서 두껍게 유지하려고 했다. 또 엔티티를 직접 넘겨받는 대신 POJO 객체를 주고받으며, 엔티티 변경은 내부에서만 이루어지도록 했다.

예를 들어, 예약 가능 좌석 수에 대한 필드 값 변경 시 다음과 같은 방식으로 메서드를 작성했다.

@Entity
class ConcertSchedule(
    val concertId: Long,
    startTime: LocalDateTime,
    totalSeats: Int,
    availableSeats: Int,
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,
) : BaseEntity() {
    
    ...
    
    fun occupySeat() {
        if (availableSeats <= 0) {
            throw CoreException(
                errorType = ErrorType.SEAT_UNAVAILABLE,
                message = "No available seats left to reserve.",
            )
        }
        this.availableSeats -= 1
    }

    ...
}

 

메서드명을 가능한 도메인 관점에서의 행위명으로 명확하게 표현했다. 예를 들어, decrementAvailableSeats() 대신 occupySeat() 같은 행위명을 사용함으로써 코드의 가독성을 높였고, 코드의 의미를 더 명확하게 전달할 수 있었다.

 

7. 에러 핸들링

기존에는 개별적으로 커스텀 예외를 만들어 사용했지만, 관리가 어려워지는 문제점이 있었다.

 
 

이를 개선하기 위해 ErrorType을 작성하고, 각 에러 코드, 메시지, 로그 레벨을 부여해 하나의 커스텀 예외로 처리했다.

예를 들어, 다음과 같이 ErrorType을 정의했다.

enum class ErrorType(val code: ErrorCode, val message: String, val logLevel: LogLevel) {
    // common
    SYSTEM_FAILURE(SYSTEM_ERROR, "System encountered an unexpected error.", ERROR),
    TOKEN_EXPIRED(AUTHORIZATION_ERROR, "The token has expired.", WARN),

    // WaitingQueue
    INVALID_TOKEN(VALIDATION_ERROR, "Invalid or missing token.", WARN),
    QUEUE_ALREADY_EXISTS(QUEUE_ERROR, "A queue already exists for this token.", WARN),
    NO_QUEUE_FOUND(QUEUE_ERROR, "No queue found for the given token.", WARN),

    // Concert
    ...

    // User
    ...

    // Payment
    ...
}

class CoreException(
    val errorType: ErrorType,
    val details: Any? = null,
    message: String = errorType.message,
) : RuntimeException(message)

 
이 방식 덕분에 예외 처리에 대한 유지보수 향상과 일관성을 유지할 수 있었다.
 
 
 
 

앞으로 개선해나갈 점

 

1. 대기열 시스템의 고도화

현재는 RDB에 저장된 토큰을 사용해 대기열을 관리하고 있지만, 앞으로는 성능 면에서 더 빠른 응답 처리를 할 수 있도록 개선해보고자 한다. 이를 위해 Redis와 같은 메모리 기반 데이터 저장소를 사용하는 것을 고려 중이다.
 

2. 테스트 작성

이번 과제에서 테스트 코드를 총 77개 작성했다. 실무에서 테스트 코드를 작성해본 경험이 없어서 이 숫자가 많은지 적은지는 모르겠지만, 테스트를 작성하면서 중요한 점을 깨달았다. 테스트 커버리지를 채우기 위한 테스트 코드가 아닌, 실제로 시스템의 안정성을 보장하는 테스트 코드를 작성해야 한다는 것이다.
단위 테스트는 화이트박스 테스트로 내부 로직을 검증하는 데 집중해야 하며, 통합 테스트는 블랙박스 테스트로 외부에서의 일관성을 검증해야 한다. 이러한 주제를 벗어나는 테스트는 지양해야 한다고 생각한다. 다양한 엣지 케이스를 테스트하여 시스템의 안정성을 보장해야 한다.
 

3. 서비스의 확장성을 고려한 설계

현재의 구조가 어느 정도의 트래픽을 처리할 수 있을지, 향후 트래픽 증가에 어떻게 대응할 수 있을지를 고려해보고 반영할 계획이다.
 
 
 

마치며

이번 프로젝트를 통해 가장 크게 느낀 것은 기능 구현 자체보다 유지보수성과 확장성을 고려한 설계의 중요성이었다. 3주 동안 수많은 고민과 삽질 아닌 삽질을 하며, 단순히 작동하는 코드가 아니라 '잘 설계된 코드'를 만드는 것이 얼마나 중요한지 깨닫게 되었다. 또한, 새로운 기술을 습득하고 이를 적용하는 과정에서 많은 성장을 이루었다.
 
아직 항해의 반이 남았지만 조금씩 성장하고 있음을 느끼고 있고, 힘들지만 동시에 뿌듯함도 크다. 앞으로 남은 기간 동안도 계속해서 배우고, 이 프로젝트를 더 개선하기 위해 노력할 것이다. 이 과정이 끝날 때쯤에는 지금보다 훨씬 더 나아진 모습을 기대하며, 끝까지 최선을 다해보려고 한다.