항해 플러스 최종 회고 (+주차별 학습내용 정리)

 

들어가며

11월 30일, 10주 간의 항해 교육 과정이 끝났다.

역시 돌아보니 짧게 느껴지는 건 여느 경험과도 비슷한 감정을 느끼는 것 같다.

 

항해 수강 전, 커리큘럼을 보았을 땐 이런 생각을 했다.

 

TDD, Kafka, Redis... 다 익숙한 키워드인데, 혼자서도 공부할 수 있지 않을까? 과연 큰 돈을 내면서까지 배울만한 가치가 있을까?

 

물론 마음만 먹으면 혼자서도 가능했을지 모른다. 하지만 혼자서는 하지 못할 이유가 있었다.

 

1. 10주안에 기술을 익히고, 프로젝트에 반영

2. 광범위한 사용 방법 중 실무에 꼭 필요한 방법을 캐치

3. 시니어 개발자들의 트러블슈팅 경험으로 얻어낸 노하우

 

이 세 가지는 혼자 공부해서 얻어내기엔 너무 오랜 시간이 필요한 것들이었다.

그런 의미에서 나에게 지난 10주는 폭발적으로 성장할 수 있었던 시간이었다.

 

 

 

 

 

10주 전의 내 모습

0주차 회고를 다시 읽어보니, 그 당시의 내 감정이 생생히 떠오른다.

현재 다니고 있는 회사에서도 많은 것을 배우고 있지만, '혹시 내가 우물 안 개구리가 되어가고 있는 건 아닐까?' 하는 불안감이 늘 마음 한구석에 자리 잡고 있었다.

또, '나는 과연 올바르게 성장하고 있는 개발자인가?', '이 방향은 맞는 걸까?' 라는 질문이 끊임없이 떠올랐다. 하지만 그 질문들에 명확한 답을 찾지 못한 채 시간만 흘러갔던 것 같다.

그 답을 찾기 위해서 결국 항해를 신청했다.

 

 

 

 

 

 

10주 과정을 통해 배운 점

 

1. 성장의 방향성

주니어 개발자라면, 아니 어느 직업이든 간에 성장하고 있는 사람이라면 가장 고민되는 부분이라고 생각된다.

내가 가는 길이 비록 지름길은 아니더라도, 최종 목적지에 맞는 방향으로 나아가고 있는지 종종 의문이 들고, 때로는 길을 헤매기도 한다.

그런 고민을 가지고 시작한 항해 과정에서, 코치님들은 단순히 '이렇게만 해' 하고 정답을 내려주는 게 아닌, '이런 관점으로 바라보고 해결해보자.' 라는 제안을 던져주었다.

또 흥미로웠던 점은 코치님들마다도 각각이 문제를 바라보는 방식이나 해결 방법이 모두 다르다는 것이었다.

그 과정에서 깨달은 점이 있었다.

 

개발에는 정답이 없다. 다만, 주어진 시스템에 가장 적합한 최적의 방안을 선택할 줄 아는 것이 중요하다.

 

 

이 원칙을 바탕으로 성장하기 위해 필요한 세 가지 방향성을 정리할 수 있었다.

 

1. 여러 방안을 떠올릴 수 있는 사고력

2. 여러 방안을 실제로 구현하고, 결과를 비교할 수 있는 실행력

3. 그중 최적의 방법을 선택할 수 있는 판단력

 

이걸 가능하게 하는 것 핵심은 결국 소통과 학습이었다.

 

 

2. 소통

항해 이전에는 개발자 네트워킹을 경험해본 적이 없었다. 마냥 게을렀던 게 한몫했지만, 비전공자로서 기본기가 부족하다보는 생각에 갇혀 혼자서만 공부해왔었던 것 같다.

 

하지만 항해에서는 비슷한 연차의 개발자들과 각자의 생각을 나누고, 코드 리뷰를 통해 지식을 공유하면서 이전에는 상상도 못 했던 성장 속도를 체감했다.

 

특히, 시니어 개발자들과의 대화를 통해 내가 평소 막연히 궁금했던 것들을 명확히 할 수 있었다.

• 객체지향적인 코드란 무엇인가?
• 좋은 테스트 코드의 기준은 무엇인가?
• 클린 아키텍처는 어떻게 실무에서 적용되는가?

이런 질문들을 여러 번 던져보며 추상적이었던 개념들이 점점 구체화되고 확고해졌다.

 

 

3. 꾸준함

10주 동안 항해를 하면서 내 생활 패턴은 다음과 같았다.

7시반 기상 -> 9시반 출근 -> 18시반 퇴근 -> 20시 저녁식사 -> 20시반 학습 -> 3시 취침

 

회사 일을 병행하며 개인 과제에 이렇게 긴 시간 몰두해 본 경험은 처음이었다.

0주차 회고에 적었던 것처럼, 이번 과정에서 '내가 노력한 만큼 얻어갈 것'이라는 생각으로 임했고, 주어진 과제에 허투루 시간을 쓰지 않으려 했다. 주차별 주어진 핵심 키워드에 몰두했지만, 그것도 시간이 늘 부족하다고 느껴질 정도였다.

 

그럼에도 10주동안의 반복적인 학습과 몰입 덕분에 한 가지 큰 깨달음을 얻었다.

내가 스스로의 시간을 어떻게 활용하고, 어떤 방식으로 유지할 수 있을지 감이 잡혔다.

'꾸준함'이야말로 성장의 지름길임을 깨달을 수 있었다.

 

 

 

 

 

수료 이후

1. 인간은 망각의 동물, 10주 과정을 복습하자!

마지막 수료식 날, 코치님께서 "새로운 것을 배우기 이전에 이미 배운 내용을 확실히 내 것으로 만들어야 한다"고 말씀하셨다.
그러고 보니 시간이 지나면서 벌써 1주차 내용이 가물가물해지고 있다. 다시 한번 복습하며, 그 당시 어떤 고민을 했고, 어떻게 개선했는지 정리해 나갈 필요가 있었다.
이를 위해 이 글의 마지막에 주차별 회고를 추가해 복습 자료로 활용할 수 있도록 작성하였다.

 

 

2. 코치님들에게 이력서 피드백 받기

수료 이후, 3명의 코치님을 찾아가 이력서에 대한 피드백을 직접 받을 기회가 있었다.

 

 

29CM: 하헌우 코치, 허재 코치
퇴근 후, 팀원들과 함께 무신사 사옥으로 찾아가 두 코치님을 만났다.
회사 구경을 마친 뒤 근처 음식점에서 코치님들의 진솔한 이야기와 사고방식을 들을 수 있었다. 특히, 젊은 나이에 리더로서 역할을 맡게 된 두 분의 비상한 사고방식이 인상적이었다.
아이패드에 작성한 이력서를 가지고 즉석에서 컨펌을 받으며, 수정해야 할 부분에 대해 구체적인 피드백을 들을 수 있어 큰 도움이 되었다.

 

무신사 사옥 방문!

 

 

우아한형제들: 토투 코치
토요일 오전 11시, 강남에서 코치님과 티타임 및 식사를 함께했다.
유쾌하고 긍정적인 에너지를 가지고 계셔서 삶의 지혜와 개발자로서의 방향성에 대해 많은 영감을 얻었다.
수정된 이력서를 추가로 리뷰받으며, 이력서 작성의 구체적인 방향을 더 명확히 할 수 있었다.

 

토투 코치님과 팀원들

 

 

3. 계속되는 소통과 학습 환경 만들기

성장에 있어 가장 중요한 요소는 지속적인 소통과 학습 환경을 유지하는 것이다. 수료 후에도 이 분위기를 잃지 않기 위해 동기들과 알고리즘 스터디를 시작하기로 했다.
함께 성장하며 학습할 수 있는 환경을 만들어가는 것이 앞으로의 과제다.

 

 

 

 

 

마치며

정신없이 지나간 10주. 힘들었지만 동기들과 함께여서 재밌었고, 기억에 남는 순간들이 많았다.
이 과정을 다른 사람들에게 강요하고 싶진 않지만, 아래 조건에 해당하는 사람(= 수강 전의 나)이라면 꼭 경험해보길 추천하며 이 글을 마친다. 

 

1. 비전공자로, 전공자 개발자와 소통하며 자신의 수준을 점검하고 싶은 사람
2. 회사에 다니고 있지만 비슷한 연차의 개발자들과 비교해 자신의 실력을 확인해보고 싶은 사람
3. 빅테크 기업이나 다른 분야의 기업으로 이직을 희망하나, 현재 회사의 기술 스택이 달라 고민 중인 사람
4. 혼자 공부 중이지만 어디서부터 시작해야 할지 몰라 막막한 사람

 

 

 

 

 

---

 

 

별첨: 주차 별 회고

나중에 10주 과정 때 어떤 걸 배우고 느꼈는 지 기억하기 위해 주차별로 키워드와 고민했던 점들을 정리해보았다.

 

 

1주차

주제

포인트 충전, 사용에 대한 동시성 처리와 통합 테스트

 

키워드

TDD, Lock, 테스트 코드

 

학습내용

 

1. ReentrantLock을 사용한 애플리케이션 레벨 Lock 적용

첫 과제에서는 포인트 충전, 사용 시 발생할 수 있는 동시성 문제를 해결하기 위해 Lock을 도입하는 과제가 주어졌다.

이 과제에서는 멀티 인스턴스를 고려하지 않아도 되었기에, DB 레벨 Lock 대신 Application 레벨의 Lock을 사용해 동시 접근을 제어했다. 이를 통해 동시성 처리의 흐름과 작동 원리를 이해할 수 있었다.

 

예를 들어, 아래는 ReentrantLock을 활용한 동시성 처리 코드이다.

@Component
class UserLockManager : IUserLockManager {
    private val lockMap: ConcurrentHashMap<Long, ReentrantLock> = ConcurrentHashMap()

    override fun <T> executeWithLock(
        userId: Long,
        action: () -> T,
    ): T {
        val lock = lockMap.computeIfAbsent(userId) { ReentrantLock() }

        if (!lock.tryLock(10, TimeUnit.SECONDS)) {
            throw LockAcquisitionException("락 획득에 실패했습니다. userId: $userId")
        }

        return try {
            action()
        } finally {
            lock.unlock()
        }
    }
}

 

 

이 동시성 처리에 대해 문서로 작성한 자료를 코치님께 피드백을 받을 기회가 있었다.

 

"동시성 이슈에 대한 공부를 많이 하셨네요. 자료가 보기 좋아요 이해가 쏙쏙 됩니다."
- 버킷플레이스 이석범 코치님

 

시니어 개발자로부터 이런 피드백을 들을 수 있었던 건 값진 경험이었다. 이 과정에서 작성했던 자료는 다듬어서 블로그에 재작성했다.

 

아래는 블로그로 옮긴 글 링크이다

동시성 처리 쉽게 이해하기 (synchronized, reentrantLock)

 

 

 

2. 테스트 더블을 사용한 단위 테스트 작성

단위 테스트 작성에는 테스트 대상 메서드의 독립성을 보장하기 위해 Mock과 Stub 객체를 활용했다.

단위 테스트를 작성하는 기준은 테스트 대상 메서드가 자체 로직이 있는지 여부로 판단해 볼 수 있다. 외부 의존성을 배제하고 순수 비즈니스 로직을 검증하는 것이 핵심이었다.

 

예를 들어, 아래 checkUserExists 메서드는 유저를 찾지 못하면 예외를 던지는 비즈니스 로직을 포함하고 있다

fun checkUserExists(userId: Long): User {
    return userRepository.findByIdOrNull(userId)
        ?: throw CoreException(
            errorType = ErrorType.USER_NOT_FOUND,
            details =
                mapOf(
                    "userId" to userId,
                ),
        )
}

 

위 로직을 테스트할 때는 외부 의존성인 userRepository를 Mock으로 대체해 순수 비즈니스를 검증할 수 있다.

 

class UserServiceTest {
    private val userRepository = mockk<UserRepository>(relaxed = true)
    private val balanceHistoryRepository = mockk<BalanceHistoryRepository>(relaxed = true)
    private val userService = UserService(userRepository, balanceHistoryRepository)

    @Test
    fun `should return user by id`() {
        // given
        val userId = 1L
        val user = mockk<User>()
        every { userRepository.findByIdOrNull(userId) } returns user

        // when
        val result = userService.checkUserExists(userId)

        // then
        assertEquals(user, result)
    }

    @Test
    fun `must throw exception when user not found`() {
        // given
        val userId = 1L
        every { userRepository.findByIdOrNull(userId) } returns null

        // when / then
        assertThrows<CoreException> {
            userService.checkUserExists(userId)
        }
    }
 }

 

 

 

고민 포인트

 

1. 단위 테스트 통합 테스트의 작성 범위

• 단위 테스트: 메서드 수준의 세부적인 로직 검증 → 화이트박스 테스트
• 통합 테스트: 여러 서비스 간의 결합을 검증하며 전체 usecase를 확인 → 블랙박스 테스트

 

2. 좋은 테스트 코드란?

• 테스트 코드는 요구사항을 명확히 나열한 문서와 같다.
• 테스트 작성이 어려운 코드는 설계의 문제일 가능성이 높다. 테스트 코드 작성을 통해 자연스럽게 객체지향 설계로 이어질 수 있음을 체감했다.

 

3. 테스트 코드 네이밍

 

• Kotlin에서는 백틱(`)을 활용해 메서드명을 쉽게 작성할 수 있다.
• 코치님들마다 선호하는 방식이 달랐지만, must, should와 같은 강한 어조를 선호하는 경우가 있다.
• 테스트 코드가 요구사항을 설명하는 문서라는 점에서, 한글과 영어 중 어느 쪽이든 명확하고 이해하기 쉬운 표현을 사용하는 것이 중요하다고 느꼈다.

 

추가

 

1. 당시 회고글

TDD, 동시성 처리 - 항해 플러스 회고 (1주차)

 

2. 프로젝트 소스

GitHub - eastshine12/hhplus-tdd-jvm: Point 서비스 / 항해 플러스 1주차 / TDD & Concurrency Control

 

 

---

 

2주차

주제

선착순 특강신청 서비스

 

키워드

클린 아키텍처, 레이어드 아키텍처, DB Lock

 

학습내용

 

1. 클린 아키텍처와 레이어드 아키텍처를 적용

특강 신청 서비스 구현 과정에서 클린 아키텍처와 레이어드 아키텍처를 적용했다.
이를 통해 도메인 레이어, 애플리케이션 레이어, 인터페이스 레이어 간의 단방향 의존성을 유지하며 각 계층의 역할을 명확히 분리하는 방법을 익혔다.

인프라스트럭처 레이어에서는 JPA 레파지토리 구현체를 만들어 도메인에 의존되지 않는 형식을 취했다.

 

 

2. DB 레벨에서의 Lock을 구현

선착순으로 특강 신청을 처리하기 위해 DB Lock을 사용했다.

낙관적 락과 비관적 락의 장단점을 분석한 결과, 요구사항에서 명시된 선착순 시스템을 구현하기 위해 트랜잭션의 순차 처리가 보장되는 비관적 락을 선택하였다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT l FROM Lecture l WHERE l.id= :lectureId")
fun findByIdOrNullWithLock(lectureId: Long): Lecture?

 

 

고민 포인트

 

1. 계층간의 DTO 분리

계층 간의 단방향 의존성을 유지하기 위해 데이터를 전달하는 DTO를 각 계층별로 정의했다.

• 고민
  도메인 레이어에서 정의한 객체를 그대로 애플리케이션 레이어와 인터페이스 레이어에서도 사용할 수 있지 않을까? 계층마다 DTO를 따로 작성해야 하는 이유가 무엇인지 궁금했다.
• 해결
  각 레이어의 역할과 책임에 맞게 DTO를 분리해야 한다는 결론에 도달했다.
  • 도메인 레이어: 비즈니스 로직을 다루는 풍부한 객체
  • 애플리케이션 레이어: 비즈니스 로직의 결과 데이터를 제공
  • 인터페이스 레이어: HTTP 응답에 필요한 데이터만 포함
  즉, 애플리케이션 레이어의 Facade에서 반환하는 객체는 비즈니스 로직의 결과를 담고, 인터페이스 레이어의 컨트롤러는 그 중 필요한 데이터를 가공하여 HTTP 응답 값으로 전달한다.
• 결론: 각 계층마다 DTO를 분리하는 것이 설계의 명확성과 유지보수성을 높인다.

 

2. TDD의 활용 빈도

TDD(Test-Driven Development)는 로직의 안정성과 설계의 견고성을 높이지만, 모든 상황에서 적용하기란 쉽지 않았다.

• 고민
  복잡한 로직을 작성할 때는 로직 구현 자체가 어려워 TDD를 적용할 여유가 없었다. 결국 단순한 로직에만 TDD를 적용하고, 복잡한 로직은 TLD(Test Last Development) 방식으로 구현하게 되는 경우가 많았다.
• 해결
  오히려 복잡한 로직일수록 TDD의 위력을 발휘한다는 사실을 깨달았다.
  • 생소하거나 복잡한 로직일수록, 요구사항을 테스트로 정의하며 구현하면 더욱 안정적인 코드를 만들 수 있다.
  • 반면, 단순 CRUD와 같은 익숙한 로직에서는 TLD 방식을 활용할 수도 있다.
• 결론: TDD는 상황에 따라 적재적소에 활용하는 것이 중요하다.

 

 

추가

 

당시 회고글

Clean Architecture - 항해 플러스 회고 (2주차)

 

 

프로젝트 소스

GitHub - eastshine12/hhplus-lecture: 특강 신청 서비스 / 항해 플러스 2주차 / Clean Architecture

 

 

---

 

3~5주차

는 잘 정리해둔 회고글로 대체

 

회고글

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

 

프로젝트 소스

GitHub - eastshine12/concert-reservation: 콘서트 예약 서비스 / 항해플러스 / Queue, Token, Concurrency

 

---

 

6주차

주제

시나리오 내에 발생할 수 있는 동시성 이슈 제어 방식 비교 및 선정

 

키워드

x-lock, 낙관적 락, 비관적 락, 분산 락

 

학습내용

 

1. 동시성 이슈가 발생하는 로직에서 낙관적 락, 비관적 락, 분산 락 적용

콘서트 예약 서비스에서 Lock 성능 비교해보기 (feat. 낙관적 락, 비관적 락, 분산 락)

 

 

고민 포인트

 

1. 테스트 환경 설정

DB 락(H2)과 Redis를 사용한 분산 락의 성능 비교를 진행하려고 했으나, 테스트 환경의 차이로 인해 고민이 생겼다.

• H2 DB 락: 스프링 부트와 동일 프로세스에서 실행되어 네트워크를 타지 않는다.
• Redis 분산 락: 로컬 컨테이너에서 실행되며, 네트워크를 타는 방식이다.

이처럼 테스트 환경이 상이하면 성능 비교가 공정하지 않을 수 있으므로, 두 환경 모두 컨테이너로 띄워 동일한 조건을 구현하려고 했다.

결론적으로, DB와 Redis 모두 컨테이너 환경에서 실행하여 테스트 환경을 일관되게 설정했다.

 

2. 분산락 AOP와 @Transactional 의 실행 순서

분산 락 AOP를 적용하기 위해 어노테이션을 작성하고 트랜잭션이 적용된 메서드에 붙였으나, 트랜잭션이 시작된 이후에 락이 걸리는 문제에 직면했다. 이는 동시성을 보장하지 못하는 결과를 초래한다.

 

그 이유는, @Transactional은 메서드 진입 시점에서 이미 DB 커넥션과 트랜잭션을 시작한다.
만약 분산락 AOP가 그보다 늦게 실행된다면, 여러 스레드가 거의 동시에 트랜잭션을 시작하고, 이후에야 락을 획득하는 상황이 발생한다. 이로 인해 DB 상태 조회나 일부 변경이 락 없이 진행될 수 있어 완전한 동시성 제어가 어렵다.

 

문제를 해결하기 위해 아래 세 가지 방법을 시도했다.

• 방법 1: 트랜잭션 메서드 상위(e.g., Facade)에서 Lock을 거는 방식
• 방법 2: Lock AOP의 @Order를 낮은 값으로 설정해, 트랜잭션보다 먼저 실행되도록 하는 방식
• 방법 3: Lock AOP 내부에서 REQUIRES_NEW 트랜잭션 속성을 사용해, 독립적인 트랜잭션으로 실행되도록 설정하는 방식

최종적으로 방법 2를 선택했다.

Lock AOP의 @Order를 낮게 설정하면, 스프링 프레임워크의 어드바이스 실행 순서 규칙에 따라 트랜잭션보다 먼저 실행되기 때문이다.

• @Transactional: Ordered.LOWEST_PRECEDENCE로 설정되어 있어, 모든 AOP 어드바이스 중 가장 마지막에 실행된다.
• Lock AOP: @Order를 Ordered.HIGHEST_PRECEDENCE으로 설정하면, 트랜잭션보다 먼저 실행될 수 있다.

 

 

 

프로젝트 소스

GitHub - eastshine12/concert-reservation: 콘서트 예약 서비스 / 항해플러스 / Queue, Token, Concurrency

 

 

---

 

7주차

주제

Redis를 사용한 캐시 적용 및 대기열 로직 이관

 

키워드

Redis, 캐시, 대기열

 

학습내용

 

1. 캐시 적용 기준을 세우고 실제 로직에 캐시 적용 및 대기열 로직을 Redis로 이관

Redis 기반의 캐싱 및 대기열 관리를 통한 콘서트 예약 서비스 성능 개선

 

 

고민 포인트

 

1. Redis 대기열 관리 방식

대기열을 WaitingToken(대기 토큰)과 ActiveToken(예약 가능한 활성 토큰)으로 나누어 Sorted Set(ZSet)으로 관리했는데, 각 토큰 상태 조회 시 두 개의 ZSet을 모두 탐색해야 하는 비효율이 발생했다.

• 해결
  각 토큰 정보를 Hash 구조로 전환하여, 토큰을 key로 하고 콘서트 스케줄 ID, 상태, 만료일자 등을 value로 저장했다. 이를 통해 단일 조회로 필요한 정보를 얻을 수 있게 했다.

 

• 결론
  Hash를 활용한 설계 변경으로 토큰 상태 조회 성능이 향상되어, 대기열 관리가 더욱 효율적으로 이루어졌다.

 

 

 

프로젝트 소스

GitHub - eastshine12/concert-reservation: 콘서트 예약 서비스 / 항해플러스 / Queue, Token, Concurrency

 

---

 

8주차

주제

자주 조회되는 쿼리를 분석하고 인덱스를 사용하여 쿼리 성능 개선

 

키워드

인덱스

 

학습내용

1. 좌석 조회 쿼리에 여러 방식의 인덱스를 걸어보고 최적의 인덱스 사용

해당 주차의 관련 내용을 아래 글에 작성하였다.

콘서트 예약 서비스의 인덱스 설계와 성능 비교

 

 

프로젝트 소스

GitHub - eastshine12/concert-reservation: 콘서트 예약 서비스 / 항해플러스 / Queue, Token, Concurrency

 

---

 

9주차

주제

Docker를 활용한 Kafka 컨테이너를 구성 및 이벤트 기반 로직 전환

 

키워드

Docker, Kafka, Transactional Outbox Pattern, TestContainers

 

 

학습내용

 

1. 예약 생성 로직을 Kafka 이벤트 발행 구조로 전환

• 기존 직접 호출 구조를 이벤트 발행 → 소비 패턴으로 개선

2. Transactional Outbox Pattern 적용

• Outbox 테이블에 이벤트 발행 기록을 남기고, 재처리 스케줄러로 발행 실패 이벤트를 재전송
• @TransactionalEventListener(BEFORE_COMMIT)로 메인 트랜잭션과 관심사를 분리

@Component
class ReservationEventListener(
    private val outboxRepository: OutboxRepository,
    private val externalEventPublisher: ReservationExternalEventPublisher,
    private val objectMapper: ObjectMapper,
) {
    @TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
    fun saveOutbox(event: ReservationEvent.Created) {
        outboxRepository.save(
            Outbox(
                topic = "concert.reservation.created",
                key = event.reservationId.toString(),
                eventType = "RESERVATION_CREATED",
                payload = objectMapper.writeValueAsString(event),
            ),
        )
    }

    @Async
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    fun publishKafkaMessage(event: ReservationEvent.Created) {
        externalEventPublisher.publish(
            topic = "concert.reservation.created",
            key = event.reservationId.toString(),
            payload = event,
        )
    }
}

 

 

고민 포인트

 

1. 로직 분리

@Transactional
fun 결제처리(command): 결제정보 {
    return runCatching {
        val 예약정보 = 예약확인및확정처리(예약ID)  // 1
        val 좌석정보 = 좌석정보검증및가져오기(예약정보.좌석ID) // 2
        사용자잔액차감(사용자ID, 좌석정보.가격, USE) // 3
        대기열토큰만료처리(토큰) // 4
        결제이력저장(사용자ID, 예약ID, 좌석정보.가격)  // 5
    }.getOrElse { 예외 ->
        throw 익셉션()
    }
}

 

결제 로직에서 예약 확정(예약확인및확정처리)과 사용자 잔액 차감(사용자잔액차감)은 필수 로직으로 반드시 성공해야 한다.
반면, 대기열 토큰 만료나 결제 이력 저장은 최종 일관성을 맞추기 위한 보조 로직이므로 이벤트 처리로 분리할 수 있다.
이때, 예약 확정과 잔액 차감 같은 필수 로직을 어떻게 처리할지, 실패 상황에서 보장성을 어떻게 유지할지 고민이 필요했다.

 

 

해결

1. 방법 1: 예약 확정과 잔액 차감을 같은 트랜잭션으로 처리
   • 두 로직을 하나의 트랜잭션에서 처리하여 필수 로직의 성공을 보장한다.
   • 대기열 토큰 만료와 결제 이력 저장은 이벤트 기반으로 처리해 트랜잭션 범위를 줄이고, 실패 시 재처리를 스케줄러로 보완
2. 방법 2: 보상 트랜잭션 적용
   • 예약 확정과 잔액 차감을 독립적으로 처리하되, 잔액 차감 로직이 실패할 경우 예약 확정 처리에 대해 보상 트랜잭션을 실행(e.g. 예약 상태를 취소로 되돌림)
   • 이를 통해 전체 로직의 안정성과 유연성을 확보

 

결론
방법 1은 필수 로직의 성공을 확실히 보장하는 안전한 선택이지만, 트랜잭션 범위가 넓어질 수 있다.
방법 2는 트랜잭션 범위를 줄이고 유연성을 제공하지만, 보상 트랜잭션 설계와 운영의 복잡도가 높아질 수 있다.

각 방법의 장단점을 이해하고 상황에 맞게 알맞은 방법을 선택할 수 있어야 한다.

 

 

 

프로젝트 소스

GitHub - eastshine12/concert-reservation: 콘서트 예약 서비스 / 항해플러스 / Queue, Token, Concurrency

 

---

 

10주차

주제

유저 행동 기반 부하 테스트 및 가상 장애 대응 문서 작성

 

키워드

부하 테스트, K6

 

학습내용

 

1. 유저 시나리오 기반 부하 테스트 시나리오 작성

• Docker로 Spring App, Kafka, Redis, MySQL, InfluxDB, Grafana 등을 띄우고,
  k6 스크립트를 통해 실제 유저 행동을 모방하는 시나리오를 실행

 

• 시나리오 1: 토큰 발급 → 토큰 상태 조회

export default function () {
     // 토큰 발급
     let token = getWaitingToken()

     // 토큰 상태 조회
     for (let i = 0; i < 5; i++) { // 5회 반복
         getQueueStatus(token)
         sleep(1);
     }
 }

 

 

• 시나리오 2: 콘서트 좌석 조회 → 예약 → 결제
  이를 통해 시스템 한계치 파악 및 SLA/SLO 검증

export default function () {
     let currentId = exec.scenario.iterationInTest + 1;
     let token = getWaitingToken(currentId);

     getConcertSeats(token); // 좌석 조회
     sleep(2);
     let reservationId = reserveSeat(token, currentId); // 예약
     sleep(2);
     processPayment(token, reservationId, currentId); // 결제
     sleep(2);
 }

 

 

 

부하 테스트: 유저 행동 기반 시나리오로 시스템 한계 측정과 SLA, SLO 검증

 

 

프로젝트 소스

GitHub - eastshine12/concert-reservation: 콘서트 예약 서비스 / 항해플러스 / Queue, Token, Concurrency

 

---