복잡한 시스템에서 직접 상태 관리를 하다 보면 한계와 어려움이 분명하게 드러납니다. 이 글에서는 카카오뱅크 알림 발송 시스템 개발에 FSM(Finite State Machine) 개념을 어떻게 적용했는지, 직접 구현 방식의 한계와 Spring Statemachine을 활용해 얻은 장점, 그리고 실제로 마주한 도전 과제를 다룹니다. 프레임워크가 제공하는 체계적인 상태 관리와 개발 생산성 향상 효과, 그리고 학습 비용과 복잡성이라는 트레이드오프를 균형 있게 짚으며, 상황에 맞는 기술 선택의 중요성을 제시합니다. 실전 경험에서 나온 균형 잡힌 시각과 노하우가 궁금하신 분들은 꼭 읽어보시길 추천합니다.

안녕하세요, 카카오뱅크 플랫폼엔지니어링팀에서 알림 시스템 개발을 담당하고 있는 서버 개발자 Danny입니다.

카카오뱅크의 알림 시스템은 고객에게 다양한 알림을 전달하는 핵심 역할을 하고 있습니다. 최근 알림서비스 2.0을 준비하면서, 알림 메시지의 ‘상태’를 효율적으로 관리할 수 있는 방법에 대해 고민하게 되었습니다. 이 과정에서 과거 인증 시스템 개발 당시 Spring Statemachine을 도입해 복잡한 상태 전환과 예외 상황을 효과적으로 처리했던 경험이 떠올랐습니다. 이러한 경험을 바탕으로, Spring Statemachine의 일부 기능을 직접 구현해 알림 시스템에 보다 적합한 방식으로 상태 관리를 커스터마이즈해 보았습니다.

이번 글에서는 유한 상태 기계(Finite State Machine, 이하 FSM)을 직접 구현하며 발견한 한계점을 분석하고, 이후 Spring Statemachine을 실제로 도입한 경험과 그 과정에서 얻은 인사이트를 공유하고자 합니다. Spring Statemachine 도입을 고민 중이거나 효과적인 상태 관리 시스템 구현 방법을 찾고 계신 개발자분들께 작은 참고가 되길 바랍니다.

그럼 먼저, 카카오뱅크의 알림 발송 시스템이 어떤 역할을 하는지부터 살펴보겠습니다.

카카오뱅크 알림 발송 시스템

카카오뱅크의 OX 퀴즈 광고 앱푸시, 민생회복 소비쿠폰 안내 알림톡, 그리고 이용 약관 및 상품 설명서 안내 이메일 등은 모두 플랫폼엔지니어링팀에서 관리하는 UMS(Unified Messaging System, 통합 알림 발송 시스템)를 통해 발송됩니다. 고객에게 발송되는 모든 알림 메시지는 SMS/LMS, 이메일, 팩스, 앱푸시, 알림톡 등 다양한 채널을 통해 UMS를 거쳐 전달됩니다.

1-push-talk-email
[그림 1] 고객에게 발송되는 알림 메시지 채널 예시: 앱푸시, 알림톡, 이메일

UMS는 고객에게 알림을 발송하기 위한 시스템으로, 접수, 발송, 재처리 등 여러 기능이 모듈화된 서비스로 구성되어 있습니다. 이 중 가장 먼저 동작하는 것은 발송할 알림을 접수하는 알림 접수 서비스입니다. 알림 접수 서비스는 메시지를 접수한 후, 고객에게 발송이 가능한지 필터링 단계를 거칩니다. 예약 발송인 경우에는 지정된 발송 시간까지 대기하다가, 시간이 되면 해당 메시지를 알림 발송 서비스로 전달합니다. 또한, 필요에 따라 예약된 메시지를 발송 전에 취소할 수 있으며, 발송에 실패한 메시지는 재처리할 수도 있습니다.

알림 메시지는 발송 서비스로 전달되기 전까지 여러 상태(state)로 관리되며, 각 상태로 전이되기 위한 명확한 조건이 정의되어 있습니다. 예를 들어, 메시지가 시스템에 접수되면 접수 완료(RECEIVED) 상태가 됩니다. 예약된 메시지는 설정된 시간까지 대기하다가, 예약 시간이 도래하면 필터링 과정을 거쳐 발송 서비스로 전달됩니다. 이후 발송이 성공하면 발송 완료(SENT_SUCCEEDED) 상태가 되고, 실패할 경우에는 발송 실패(SENT_FAILED) 상태로 전이됩니다. 실제 비즈니스 로직은 이보다 훨씬 복잡하지만, 이해를 돕기 위해 이 글에서는 주요 상태 전이만 단순화하여 설명하겠습니다.

상태가 전이될 때마다 수행해야 하는 작업도 다양합니다. 예를 들어, 접수 완료(RECEIVED) 상태에서 발송 완료(SENT_SUCCEEDED) 또는 발송 실패(SENT_FAILED) 상태로 넘어가기 위해서는 반드시 메시지가 발송 서비스로 전달되어야 합니다. 그리고 발송 실패(SENT_FAILED) 상태로 바뀌면 메시지 발송 실패 결과를 클라이언트에 알리는 별도의 알림 로직이 필요합니다. 이처럼 각 상태 전이와 그에 따른 처리 과정을 체계적으로 설계하는 것이 알림 접수 서비스의 신뢰성과 일관성을 확보하는 데 핵심적인 역할을 합니다.

효과적인 상태 관리, 유한 상태 기계(Finite State Machine, FSM)

알림 접수 서비스를 안정적으로 구현하고 효율적으로 관리하기 위해서는 명확한 상태 관리가 필수적입니다. 이때 유용한 도구 중 하나가 FSM입니다. FSM은 상태와 상태 간 전이 조건을 명확하게 정의해 복잡한 로직을 체계적으로 관리할 수 있습니다. 이러한 특성 덕분에 FSM은 컴파일러, 임베디드 시스템, 게임 등 다양한 분야에서 널리 활용되고 있습니다.

💡 FSM이란?

유한 상태 기계(Finite State Machine, FSM)은 컴퓨터 과학에서 널리 사용되는 수학적 모델로, 주로 컴퓨터 프로그램이나 논리 회로의 설계에 활용됩니다. 상태 기계(State Machine), 유한 오토마톤(Finite Automaton) 등 유사한 용어로도 불리며, 일반적으로는 유한한 개수의 상태로 구성된 FSM을 의미합니다. 참고로, 이론적으로는 무한한 개수의 상태를 갖는 무한 상태 기계도 존재하지만, 실제 구현에서는 대부분 유한 상태 기계를 사용합니다.

FSM의 주요 구성 요소

FSM은 다음과 같은 네 가지 주요 요소로 구성됩니다.

  • • 상태(State): 시스템이 특정 시점에 처한 조건이나 상황을 나타냅니다.
  • • 이벤트(Event): 상태 전이를 유발하는 외부 입력이나 내부 조건입니다.
  • • 가드(Guard): 상태 전이가 발생하기 위한 특정 조건을 의미합니다.
  • • 전이(Transition): 한 상태에서 다른 상태로의 이동을 정의하며, 특정 이벤트에 의해 발생합니다.
  • • 행동(Action): 상태 전이 시 또는 특정 상태에 진입하거나 머무는 동안 수행되는 작업입니다.

2-fsm-state-machine-notation
[그림 2] FSM 다이어그램

위 그림을 한 줄로 요약하면 다음과 같습니다.

A '상태'에서 특정 '이벤트'가 발생하면 B 상태로 '전이'되고, 이 과정에서 특정 '행동'이 수행된다.

이러한 FSM은 다음과 같은 주요 특징을 가집니다.

  • • 명확한 상태 정의: 각 상태와 전이 조건이 명확하게 정의되어 있어, 시스템 동작을 직관적으로 이해할 수 있습니다.
  • • 예측 가능한 동작: 상태 전이 구조가 명확하게 설계되어 있어, 입력에 따른 결과를 쉽게 예측할 수 있습니다.
  • • 유지보수 용이성: 상태와 전이 조건이 명확히 분리되어 있어, 시스템의 변경이나 확장 시에도 유연하게 대응할 수 있습니다.

이처럼 복잡한 상태 관리가 요구되는 시스템에서는 FSM을 활용하면 설계와 구현의 일관성과 효율성을 높일 수 있습니다.

0 to 1, FSM 직접 구현해보기

별도의 프레임워크 없이 FSM을 직접 구현한다면 어떻게 구성할 수 있을까요?

⚠️ 아래 코드는 Kotlin으로 작성되었으며, 실제 환경보다 단순화된 예제입니다.

단순하게 구현하기 위한 방법은, 먼저 상태를 정의하고 각 상태에서 이동 가능한 전이 경로를 Map 형태로 관리하는 것입니다.

enum class MessageStatus(
    val desc: String
) {
    RECEIVED("접수 완료"),
    CANCELLED("취소됨"),
    SENT_SUCCEEDED("발송완료"),
    SENT_FAILED("발송실패"),
    // ...
    ;
}

private val statusMap = mapOf(
    RECEIVED to listOf(CANCELLED, SENT_SUCCEEDED, SENT_FAILED),
    // ...
)

그 다음, 아래 코드와 같이 상태 전이를 수행할 수 있습니다.

fun transition(id: String, currentStatus: MessageStatus, nextStatus: MessageStatus): Boolean {
    // 1. 저장소에서 id 로 발송 메시지를 조회
    val message = messageRepository.findById(id) ?: return false
    
    // 2. 전이 가능한 다음 상태 조회
    val allowedNextStatuses = statusMap[currentStatus] ?: return false
    
    // 3. 전이 전 비즈니스 로직 수행
    preAction(currentStatus, nextStatus, message)
    
    // 4. 상태 업데이트
    updateMessageStatus(id, to)
    
    // 5. 전이 후 비즈니스 로직 수행
    postAction(currentStatus, nextStatus, message)
}

이처럼 직접 FSM을 구현하는 방식은 프레임워크에 대한 의존성이 없기 때문에, 시스템의 요구사항에 맞춰 구조를 자유롭게 설계할 수 있다는 장점이 있습니다. 또한, 프레임워크에서 제공하는 복잡하거나 불필요한 기능을 제거함으로써, 보다 경량화된 시스템을 구축할 수도 있습니다.

하지만 이런 방식은 상태 관리 로직을 처음부터 끝까지 직접 작성해야 하므로, 개발에 더 많은 시간이 소요될 수 있습니다. 유지보수 측면에서도 프레임워크가 제공하는 기능들을 직접 구현해야 하기에 추가적인 부담이 발생합니다. 특히 복잡한 비즈니스 로직이나 다양한 이벤트 기반 처리가 요구되는 상황에서는 직접 구현하는 방식이 오히려 적합하지 않을 수 있습니다.

프로젝트 규모가 커짐에 따라 상태 관리와 전이 로직이 복잡해질 것을 고려하여, 직접 구현하는 방식보다 이미 검증된 프레임워크를 활용하는 것이 더 효율적이라고 판단했습니다.

Spring Statemachine 기반 상태 관리하기

다양한 상태 관리 프레임워크가 존재하지만, 저희 프로젝트는 Spring 기반으로 구현되었기 때문에 Spring 생태계와의 호환성이 중요한 고려사항이었습니다. 특히 알림 메시지의 상태 정의와 전이 로직은 변경 가능성이 높아, 향후 확장성이 반드시 고려되어야 했으며, 짧은 기간 내에 안정적으로 개발되어야 한다는 점도 중요한 요구사항이었습니다. 이러한 점들을 충족하기 위해 저희는 Spring Statemachine 프레임워크를 활용해 보기로 했습니다.

개발 당시 Spring Statemachine은 4.0.x 버전까지 출시되어 있어 비교적 안정적인 프레임워크라고 판단할 수 있었습니다. 공식 가이드를 검토해본 결과, 제공되는 기능들이 저희의 요구사항을 충분히 만족할 수 있는 수준이었습니다. 더불어, 이미 검증된 프레임워크를 도입함으로써 개발 속도를 높일 수 있을 뿐 아니라, 향후 유지보수나 확장성 측면에서도 유리할 것으로 기대했습니다.

그렇다면 Spring Statemachine을 어떻게 활용했는지 한번 알아보겠습니다.

💡 Spring Statemachine이란?

Spring Statemachine은 스프링 생태계에서 제공하는 FSM 구현 프레임워크로, 선언적 상태 정의, 전이 조건, 액션 등을 손쉽게 설정할 수 있습니다. 복잡한 상태 전이와 이벤트 처리가 필요한 엔터프라이즈 환경에서 널리 활용되고 있으며, Spring 기반 시스템과의 높은 호환성을 제공합니다. 프레임워크에 대한 보다 자세한 내용은 공식 문서를 참고하시길 바랍니다.

1. 의존성 추가

Spring Statemachine을 사용하기 위해서는 먼저 프로젝트에 의존성을 추가해야 합니다. Gradle을 사용하는 경우, 다음과 같이 설정할 수 있습니다.

dependencies {
    implementation("org.springframework.statemachine:spring-statemachine-starter")
}
 
dependencyManagement {
    imports {
        mavenBom "org.framework.statemachine:spring-statemachine-bom:4.0.0"
    }
}

기본적으로 spring-statemachine-starter 모듈을 추가하면 대부분의 핵심 기능을 사용할 수 있습니다. 필요에 따라 다음과 같은 추가 모듈을 선택적으로 포함할 수도 있습니다.

  • ﹒spring-statemachine-core: Statemachine의 핵심 기능을 제공합니다.
  • ﹒spring-statemachine-data-redis: Redis를 상태 저장소로 사용할 수 있도록 지원합니다.
  • ﹒spring-statemachine-data-jpa: JPA 기반의 상태 저장 기능을 제공합니다.
  • ﹒spring-statemachine-test: Statemachine 테스트를 위한 유틸리티를 제공합니다.

2. 상태와 이벤트 정의

Spring Statemachine을 사용하기 위해서는 사용할 상태(State) 와 이벤트(Event) 를 enum 타입으로 정의해야 합니다.

enum class MessageStatus(
    val desc: String,
) {
    RECEIVED("접수 완료"),
    CANCELLED("취소됨"),
    SENT_SUCCEEDED("발송완료"),
    SENT_FAILED("발송실패"),
    // ...
}

enum class MessageEvent(
    val desc: String,
) {
    SEND("발송"),
    CANCEL("취소"),
    // ...
}

3. 상태 머신 구성

앞서 작성한 상태와 이벤트는 상태 머신 구성 시 사용됩니다. Spring Statemachine에서는 StateMachineConfigurerAdapter를 상속받아 상태 머신을 구성할 수 있으며, 이때 정의한 MessageState와 MessageEvent를 제네릭 타입으로 지정합니다. 상태 머신에는 사용할 상태 목록뿐 아니라 초기 상태와 종료 상태를 지정해야 하고, 이는 StateMachineStateConfigurer를 통해 정의할 수 있습니다. 이때 초기 상태는 반드시 지정해야 하며, RECEIVED 상태를 초기 상태로 설정할 수 있습니다. 종료 상태도 지정할 수 있지만 필수 항목은 아닙니다.

@Configuration
@EnableStateMachineFactory(name = ["MESSAGE_STATE_MACHINE_FACTORY"])
class MessageStateMachineConfig : StateMachineConfigurerAdapter<MessageState, MessageEvent>() {
    override fun configure(states: StateMachineStateConfigurer<MessageState, MessageEvent>) {
        super.configure(states)
        states
            .withStates()
            .initial(RECEIVED)
            .state(CANCELLED)
            .state(SENT_SUCCEEDED)
            .state(SENT_FAILED)
    }    
}

4. 전이 정의

상태 간의 전이는 MessageStateMachineConfig 클래스 내에서 StateMachineTransitionConfigurer를 통해 정의할 수 있습니다. 각 전이는 소스 상태, 타겟 상태, 이벤트, 가드(Guard), 액션(Action) 등을 지정할 수 있습니다. 예를 들어, RECEIVED 상태에서 CANCEL 이벤트가 발생하면, cancelGuard() 조건을 만족할 경우 CANCELLED 상태로 전이되며, cancelAction()이 함께 실행되도록 정의할 수 있습니다.

이를 구현한 코드는 다음과 같습니다.

override fun configure(transitions: StateMachineTransitionConfigurer<MessageState, MessageEvent>) {
    super.configure(transitions)
    transitions
        .withExternal()
            .source(RECEIVED).target(CANCELLED).event(CANCEL)
            .guard(cancelGuard())
            .action(cancelAction())
        .and()
        //...
}

Spring Statemachine을 서비스에 맞게 커스터마이징하기

앞서 전이를 정의할 때 사용한 cancelGuard()와 cancelAction() 메서드는 Spring Statemachine에서 제공하는 Action 및 Guard 인터페이스를 구현한 클래스입니다.

public interface Action<S, E> {
    void execute(StateContext<S, E> context);
}

public interface Guard<S, E> {
    boolean evaluate(StateContext<S, E> context);
}

외부 프레임워크에서 제공하는 인터페이스를 별도의 추상화 없이 직접 사용할 경우, 프로젝트가 Spring Statemachine에 강하게 결합될 수 있습니다. 예를 들어, Spring Statemachine의 Guard 인터페이스에 변경이 생기면, 이를 직접 사용하는 모든 코드 역시 함께 수정해줘야 합니다. 이는 코드의 유지보수성을 떨어뜨릴 뿐 아니라 서비스 안정성에서 영향을 줄 수 있습니다. 따라서 이러한 결합도를 낮추기 위해, 저희는 Action과 Guard 인터페이스를 감싸는 내부 인터페이스를 별도로 정의하고, 이를 구현하는 클래스를 만들어 사용하는 방식을 채택했습니다.

interface MessageGuard<S, E> : Guard<S, E> {
    fun support(guardName: String): Boolean
}

이러한 설계 방식은 객체 지향 개발 원칙인 SOLID 원칙 중 ‘D’에 해당하는DIP(Dependency Inversion Principle), 즉 의존성 역전 원칙을 따르는 방식입니다. Spring Statemachine에서 다른 프레임워크로 전환이 필요할 때도 내부에서 사용하는 Action과 Guard 인터페이스의 구현만 변경하면 되기 때문에, 전체적인 결합도를 효과적으로 낮출 수 있습니다.

위와 같이 정의한 내부 인터페이스는 각 구현체에 대한 Spring Bean을 생성합니다.

@Component
class CancelGuard : MessageGuard<MessageState, MessageEvent> {
    override fun evaluate(context: StateContext<KakaoState, KakaoEvent>): Boolean {
        // 필터 통과 여부 판단 로직 구현
    }

    override fun support(guardName: String): Boolean {
        return guardName == "CANCEL_GUARD"
    }
}

Guard를 가져올 수 있는 GuardFactory도 구현하여 StateMachineTransitionConfigurer에서 사용할 수 있도록 했습니다.

@Component
class GuardFactory(
    private val guards: List<MessageGuard<MessageState, MessageEvent>>,
) {
    fun getGuard(name: String): Guard<MessageState, MessageEvent> {
        return guards.first { it.support(name) }
    }
}

Guard를 정의하는 곳에 GuardFactory를 주입받아 처리할 수 있도록 구성했습니다.

override fun configure(transitions: StateMachineTransitionConfigurer<MessageState, MessageEvent>) {
    super.configure(transitions)
    transitions
        .withExternal()
        .source(RECEIVED).target(CANCELLED).event(CANCEL)
        .guard(guardOf("CANCEL_GUARD"))
        .action(cancelAction())
}

private fun guardOf(name: String): Guard<MessageState, MessageEvent> {
    return guardFactory.getGuard(name)
}

커스텀한 FSM 사용하기

드디어 설정이 끝났습니다. 이제 FSM을 생성하고 사용할 수 있습니다. Spring Statemachine에서는 StateMachineFactory를 사용해 상태 머신 인스턴스를 생성한 뒤, 이벤트를 전송하여 상태 전이를 수행합니다. 일반적으로는 acquireStateMachine() 메서드를 통해 상태 머신 인스턴스를 획득하고, sendEvent() 메서드를 호출하여 이벤트를 전송합니다. 만약 machineId로 조회한 상태 머신 인스턴스가 존재하지 않으면, 새로 생성됩니다.

1. 데이터 전달

다음 예시 코드는 해당 머신에 CANCEL 이벤트를 전송하여 상태 전이를 수행합니다. 이때 단순한 이벤트만 전송하는 것이 아니라, 필요한 헤더 정보를 함께 포함한 메시지 형태로 이벤트를 전송할 수도 있습니다.

fun publish(machineId: String) {
    val matchedMachine = stateMachineService.acquireStateMachine(machineId)
    val headers = mapOf(
        "ID" to machineId,
    )
    val message = createMessage(CANCEL, MessageHeaders(headers))

    matchedMachine
        .sendEvent(Mono.just(message))
        .doOnNext {
            if (it.resultType == DENIED) {
                log.info("result DENIED")
            }
        }
        .doOnComplete {
            // 상태 전이 완료 후 처리 로직
        }
        .doFinally {
            // 필요시 상태 머신 정리 로직
        }
        .subscribe()
}

위 예시처럼 상태를 전이할 때 필요한 데이터를 이벤트 메시지의 헤더(Header) 에 담아 함께 전송할 수 있습니다. 전송된 헤더 데이터는 Action이나 Guard 내부에서 꺼내어 사용할 수 있으며, 상태 전이 로직에 필요한 정보를 주입하는 데 유용합니다.

예를 들어, 메시지 ID나 사용자 정보 등을 헤더에 포함시킨 뒤, Action 내부에서 이를 활용하여 필요한 작업을 수행할 수 있습니다.

@Component
class CancelGuard : MessageGuard<MessageState, MessageEvent> {
    override fun evaluate(context: StateContext<MessageState, MessageEvent>): Boolean {
        val messageId = context.messageHeaders["ID"] as String
        
        // 필터 통과 여부 판단 로직 구현
    }

    override fun support(guardName: String): Boolean {
        return guardName == "CANCEL_GUARD"
    }
}

2. 상태 머신 영속화

Spring Statemachine은 상태 머신의 현재 상태를 영속화할 수 있는 다양한 방법을 제공합니다. 예를 들어, Redis나 JPA를 활용하여 상태 머신의 상태를 저장하고 복원함으로써 시스템 재시작 시에도 상태 머신의 상태를 유지할 수 있습니다. 저희는 Redis를 활용하여 상태 머신을 영속화해 분산 환경에서도 일관된 상태 관리가 가능하도록 했습니다.

@Configuration
@EnableStateMachineFactory
class RedisStateMachineConfig : StateMachineConfigurerAdapter<KakaoState, KakaoEvent>() {
    @Bean(name = ["stateMachineRuntimePersister"])
    fun stateMachineRuntimePersister(
        redisStateMachineRepository: RedisStateMachineRepository
    ): StateMachineRuntimePersister<KakaoState, KakaoEvent, String> {
        return RedisPersistingStateMachineInterceptor(redisStateMachineRepository)
    }

    @Bean(name = ["kakaoStateMachineService"])
    fun kakaoStateMachineService(
        @Qualifier("KAKAO_STATE_MACHINE_FACTORY")
        kakaoStateMachineFactory: StateMachineFactory<KakaoState, KakaoEvent>,
        stateMachineRuntimePersister: StateMachineRuntimePersister<KakaoState, KakaoEvent, String>
    ): StateMachineService<KakaoState, KakaoEvent> {
        return DefaultStateMachineService(kakaoStateMachineFactory, stateMachineRuntimePersister)
    }
}

도입하며 느낀 경험과 인사이트

Spring Statemachine을 도입한 이후, 상태 관리가 훨씬 명확해지고 유지보수가 용이해졌습니다. 또한, 상태 전이 로직이 명확히 분리되어 있어 새로운 요구사항이 생길 때에도 쉽게 기능을 확장할 수 있었습니다. 다만, 프레임워크 자체의 복잡성으로 인해 도입 초기에는 학습 곡선이 존재했고, 특정 상황에서는 프레임워크의 제약으로 인해 원하는 동작을 그대로 구현하기 어려운 경우도 있었습니다.

예를 들어, Spring Statemachine에는 별도의 기본 TTL(Time-To-Live)이 설정되어 있지 않기 때문에 상태 머신 인스턴스는 명시적으로 삭제하지 않는 한 Redis에 영구적으로 남게 됩니다. 이로 인해 메모리 누수가 발생할 수 있으므로 상태 머신의 생명 주기가 종료된 후에는 반드시 인스턴스를 삭제해야 하며, 이에 대한 인식과 관리가 필요했습니다.

외부 프레임워크를 활용함으로써 확장성 있는 시스템을 구성할 수 있었지만, 동시에 프레임워크의 제약 사항도 충분히 고려해야 한다는 점을 깨달았습니다. 또한, 실제 요구사항보다 더 많은 기능을 프레임워크가 제공하는 경우, 오히려 불필요한 복잡성이 추가되는 상황도 겪었습니다. 이러한 경험을 통해 프레임워크 도입 시에는 단순한 기술적 유용성뿐 아니라 프로젝트의 맥락과 규모에 맞는 선택인지를 신중히 판단해야 한다는 중요한 인사이트를 얻을 수 있었습니다.

3-comparing-custom-implementation-framework
[그림 3] 직접 구현 vs 프레임워크 도입 비교

마무리하며

“장인은 도구를 가리지 않는다"는 말이 있지만, 이것이 아무 도구나 사용해도 된다는 뜻은 아닙니다. 진정한 장인은 주어진 상황에 가장 적합한 도구를 선택할 줄 아는 사람입니다. Spring Statemachine을 도입하며 얻은 가장 큰 교훈은 바로 이것이었습니다.

프레임워크는 분명 강력한 도구입니다. Spring Statemachine은 복잡한 상태 관리를 체계적으로 해결해주었고, 검증된 기능을 활용해 개발 속도도 높일 수 있었습니다. 하지만 동시에 불필요한 복잡성과 학습 비용, 그리고 프레임워크 고유의 제약사항들도 함께 따라왔습니다. TTL 관리나 메모리 누수 같은 예상치 못한 이슈들을 마주하면서 프레임워크 선택의 신중함이 얼마나 중요한지 깨달았습니다.

이 경험을 통해 다시 한 번 느낀 것은, 기술 선택에서 가장 중요한 것은 균형 잡힌 시각이라는 점입니다. 프로젝트의 규모, 팀의 역량, 요구사항의 복잡도, 향후 확장성 등 다양한 요소를 종합적으로 고려해야 합니다. 때로는 직접 구현하는 것이 더 나은 선택일 수 있고, 또 어떤 경우에는 검증된 프레임워크를 활용하는 것이 정답일 수 있습니다. 중요한 것은 도구 자체에 매몰되지 않고, 주어진 문제를 해결하는 데 가장 효과적인 방법을 찾는 것입니다.

결국 개발자의 진정한 역량은 특정 도구에 대한 숙련도가 아니라, 상황에 맞는 최적의 솔루션을 선택하고 적용할 수 있는 판단력에 있다는 것을 다시 한번 깨달았습니다. 이 글을 읽고 계신 여러분도 기술을 선택할 때, 도구 자체보다 ‘문제를 해결하는 데 가장 적합한 방법이 무엇인지’ 한 번 더 고민해보셨으면 합니다.