SMS는 인도 사용자 금융활동의 핵심 데이터를 담고 있으며, 우리는 이를 실시간으로 수집해 신용평가에 활용하고 있습니다. 기존 Nifi 기반 실시간 파이프라인은 빠른 구축에는 유리했지만, 구조적 한계와 운영 리스크가 존재했습니다. 이를 개선하기 위해 Apache Flink 기반의 새로운 파이프라인을 도입하게 되었고, 본 글에서는 그 전환 과정과 기술적 배경, 운영 상의 변화, 그리고 향후 계획까지 자세히 소개합니다.
1. 실시간 SMS 데이터, 왜 중요한가?
SMS 데이터 기반 신용평가
인도 현지에서 사용자의 금융 활동 데이터를 가장 효과적으로 수집할 수 있는 채널 중 하나는 바로 SMS입니다.
BANK(은행), CARD(신용/체크카드사), CREDIT BUREAU(신용평가기관), LOAN PROVIDER(대출 제공자), MERCHANT(가맹점), OPERATOR(통신사), UPI(통합결제시스템), WALLET(전자지갑) 등 다양한 기관에서 발송하는 SMS는 사용자의 금융 생활 전반을 반영하는 생생한 기록이라고 할 수 있습니다.
이러한 SMS에는 다음과 같은 정보가 담겨 있습니다:
대출 실행, 상환, 연체, 이자 부과 등: 신용 상태를 직접적으로 보여주는 지표
급여 입금, 송금, 계좌 잔고 변화 등: 소득과 지출 흐름을 파악할 수 있는 단서
카드 승인, 실패, 결제 내역 등: 소비 패턴과 채무 가능성에 대한 힌트
디지털 지갑 및 UPI 트랜잭션: 현금 흐름, 거래 내역 등을 통해 신용평가의 보조 지표로 활용
이처럼 SMS는 사용자와 금융기관 간의 상호작용을 가장 직접적으로 보여주는 신용평가의 핵심 데이터입니다.
우리는 이 SMS 데이터들을 수집하고, 그 내용과 맥락을 정제하여 사용자의 신용을 정량적으로 해석할 수 있는 다양한 피처(feature)로 전환하고 있습니다. 이렇게 생성된 피처들은 신용평가 모델의 입력값으로 활용되어, 사용자에게 보다 정밀하고 맞춤화된 금융 서비스를 제공하는 데 기여하고 있습니다.
왜 실시간 처리가 필요한가?
초기에는 SMS 데이터를 하루 단위로 수집·분석하여 피처를 생성하는 배치(batch) 방식을 사용했습니다. 하지만 이 방식은 다음과 같은 문제를 야기했습니다
기존 사용자의 경우 최신 SMS가 피처에 즉시 반영되지 않기 때문에, 신용 상태의 변화를 실시간으로 반영하지 못하는 문제가 있었습니다.
신규 가입자의 경우는 아예 피처가 존재하지 않기 때문에, 초기 신용평가가 어렵고, 그로 인해 정확한 서비스 제공이 불가능했습니다.
모델 성능 검증 시점에도, 실제 수집된 메시지와 피처 생성 시점 간에 시차가 존재해, 모델 평가의 정확도가 떨어지는 문제가 발생했습니다.
이러한 문제를 해결하기 위해, 우리는 SMS 데이터를 실시간으로 수집하고 피처를 즉시 생성하는 구조로 전환하게 되었습니다. 그 결과, "SMS 데이터를 얼마나 빠르고, 정확하며, 안정적으로 수집하고 처리할 수 있는가"는 곧 신용평가 시스템의 정밀도와 서비스 품질을 좌우하는 핵심 요소가 되었습니다.
스트림 처리(Stream Processing)란?
스트림 처리이란, 데이터가 생성되는 즉시 처리하는 방식으로, 지속적으로 유입되는 이벤트를 실시간으로 분석하고 반영하는 데이터 처리 패러다임입니다.
우리가 다루는 대부분의 데이터는 이벤트의 연속적인 흐름, 즉 스트림(stream) 형태로 생성됩니다. 대출 실행과 상환, 송금 요청, 계좌 잔고 알림, 신용카드 결제, 지갑 충전, 사용자 로그인과 같은 행동은 모두 시간의 흐름에 따라 발생하는 이벤트이며, SMS 또한 이들 이벤트를 간접적으로 표현하는 데이터입니다.
이러한 스트림 데이터는 처리 방식에 따라 두 가지로 나뉩니다:
1️⃣
Unbounded Stream (무한 스트림): 시작은 있지만 끝이 없는 데이터 흐름 - 예시: 실시간 SMS, 카드 결제 이벤트, UPI 트랜잭션 - 지속적으로 이벤트가 유입되기 때문에, 계속해서 즉시 처리되어야 하며 모든 데이터를 기다릴 수 없으므로 정확한 순서(Event time)와 상태 관리가 중요
2️⃣
Bounded Stream (유한 스트림): 시작과 끝이 명확한 데이터 흐름 - 예시: 하루 동안 수집된 SMS 데이터를 한 번에 처리하는 배치(batch) 작업 - 입력이 완결된 상태이므로, 정렬이나 후처리로도 원하는 결과를 만들 수 있음
즉, 실시간 피처 생성을 위해 운영되는 SMS 파이프라인은 Unbounded Stream 기반의 스트림 처리 시스템이라고 할 수 있습니다.
2. 우리는 왜 Flink를 선택했을까?
기존 Nifi 기반 SMS 파이프라인의 한계
처음 SMS 데이터를 수집하고 처리할 때, 우리는 Apache Nifi 기반의 실시간 파이프라인을 운영하고 있었습니다. Nifi는 GUI 기반으로 데이터 흐름을 손쉽게 구성할 수 있고, 빠르게 배포할 수 있는 장점이 있어 초기 구축 단계에서는 매우 유용했습니다.
하지만 시간이 지나며 SMS 기반 신용평가 모델의 정밀도와 서비스 안정성이 점점 더 중요해졌고, 이 과정에서 Nifi 파이프라인 구조가 가진 한계가 명확히 드러나기 시작했습니다.
특히, 하나의 파이프라인 문제가 전체 시스템에 영향을 주는 구조적 위험성이 실제 장애로 이어졌던 사건이 있었습니다.
당시 Nifi 클러스터에는 SMS뿐 아니라 userlog, serverlog, fingerprint, binlog 등의 여러 파이프라인이 함께 운용되고 있었는데, userlog 파이프라인의 Elasticsearch 인덱싱 지연이 발생하면서 Nifi 내부 큐가 급격히 증가했고, 이로 인해 전체 클러스터의 처리 성능이 저하되며 SMS 메시지 처리까지 지연되는 문제가 발생했습니다.
결국 이 문제는 실시간 피처 생성에 영향을 주었고, 이는 신용평가 지연 및 서비스 품질 저하라는 결과를 낳았습니다.
이 사건은 단순한 일시적 장애를 넘어, “하나의 파이프라인 문제로 전체 파이프라인이 영향을 받는 구조는 더 이상 유지할 수 없다”는 분명한 문제의식을 우리에게 안겨주었습니다.
실시간 처리, Nifi 말고는 어떤 선택지가 있었을까
이러한 문제를 해결하기 위해, 우리는 기존 Nifi 기반 구조를 근본적으로 재설계할 필요가 있다고 판단했습니다. 그 과정에서 “Nifi를 대체할 새로운 스트리밍 처리 플랫폼”을 모색하게 되었고, 몇 가지 주요 대안들을 함께 검토했습니다.
Apache Kafka Streams는 Kafka 환경 내에서는 경량 스트림 처리에 적합한 대안이 될 수 있었지만, 우리는 Kafka가 아닌 Kinesis를 중심으로 한 아키텍처를 사용하고 있었기 때문에, 실질적인 후보로 고려되지는 않았습니다.
Apache Spark Structured Streaming은 Spark 생태계를 그대로 활용할 수 있고, 배치와 스트림을 통합해 운영할 수 있는 장점이 있었습니다. 하지만 마이크로배치 기반 구조 특성상, 우리가 요구하는 낮은 지연 시간(latency)과 정밀한 이벤트 타임 처리에는 다소 한계가 있었습니다. 또한 상태 기반 처리나 세션 윈도우와 같은 로직 구현에서도 Flink만큼 직관적이지 않았습니다.
Google Cloud Dataflow(Apache Beam 기반)도 Flink와 유사한 기능을 제공하며, 고급 스트리밍 처리에는 적합했지만, 우리는 인프라 전반이 AWS에 구성되어 있었기 때문에, GCP로의 기술 전환은 운영 부담과 비용 측면에서 현실적인 제약이 컸습니다.
이처럼 여러 대안을 검토한 결과, 우리의 환경과 요구 조건—Kinesis 기반 수집, 상태 기반 처리, 확장성과 안정성, AWS와의 호환성—를 모두 만족시킬 수 있는 플랫폼은 결국 Apache Flink였고, 우리는 이를 실시간 메시지 처리 시스템의 새로운 기반으로 채택하게 되었습니다.
Apache Flink란?
Apache Flink는 실시간 데이터 처리를 위한 오픈소스 분산 스트리밍 처리 프레임워크입니다. 대규모 클러스터 환경에서 높은 처리량과 확장성을 바탕으로, 대용량 데이터 스트림을 안정적이고 효율적으로 처리할 수 있도록 설계되었습니다.
우리가 Flink 도입을 통해 기대했던 주요 효과는 다음과 같습니다:
1. 향상된 처리 성능
기존 시스템 대비 더 빠른 처리 속도와 낮은 지연시간(latency)을 제공하여, 실시간 피처 생성과 연속적인 분석에 적합합니다.2. 복잡한 상태 관리
Flink는 Stateful Processing을 기본적으로 지원하여, 과거 상태와의 비교, 윈도우 기반 집계, 패턴 탐지 등 복잡한 비즈니스 로직을 실시간으로 처리할 수 있습니다.3. 높은 안정성과 내결함성
Exactly-once 처리 보장과 Checkpointing 기능을 통해, 장애가 발생하더라도 데이터 유실 없이 안전하게 복구가 가능합니다.4. 코드 기반 운영의 장점
기존 Nifi는 UI 기반으로 관리되어 복잡한 로직 관리가 어려웠던 반면, Flink는 코드 기반으로 구성되어 버전 관리, 테스트 자동화, 리뷰 프로세스 도입 등 엔지니어링 조직 관점에서 훨씬 유연한 운영이 가능합니다.5. 인프라 분리 및 독립 운영 가능
SMS 파이프라인을 별도의 Flink 클러스터로 분리함으로써, 다른 파이프라인의 부하나 장애로부터 독립적으로 운영할 수 있습니다.6. 확장성 있는 구조 설계
Flink는 클러스터 기반의 아키텍처로 설계되어 있어, 향후 데이터 증가나 새로운 메시지 유형 추가 시에도 유연하게 확장이 가능합니다.
이처럼 Apache Flink는 단순한 처리 성능을 넘어, 신뢰성과 확장성, 운영 효율까지 아우르는 실시간 파이프라인의 기반 기술로 우리의 요구를 충실히 만족시킬 수 있는 최적의 선택지였습니다.
3. Flink 도입 A to Z: 설계부터 검증, 그리고 배포까지
1) 기존 파이프라인 분석 – 무엇을 옮길 것인가?
Flink 파이프라인을 새롭게 구축하기 전, 우리는 먼저 기존 Nifi 기반 SMS 파이프라인이 수행하고 있던 기능들을 분석하고 정리하는 작업부터 시작했습니다.
단순 메시지 수집 이상의 다양한 처리 요구사항이 있었고, 특히 실시간 피처 생성을 위한 핵심 기능들은 다음과 같았습니다
💡
✅ 암호화된 Kinesis 메시지 복호화 ✅ 필수 필드 포함 여부 검증 및 필터링 ✅ 안드로이드 앱 버전에 따른 처리 로직 분기 ✅ SMS 전송 시작/완료 여부(flag)를 활용한 상태 추적 ✅ 처리 결과를 S3 및 DynamoDB에 저장
이러한 처리 로직은 Nifi에서는 GUI 중심으로 구성되어 있었고, 복잡한 조건 분기나 상태 기반 로직은 설계와 유지보수에 많은 제약이 있었기 때문에, 이를 코드 기반으로 체계화하고 유연하게 확장 가능하도록 재구성할 필요가 있었습니다.
또한, Flink 전환을 계획하며 우리는 기존 시스템의 실제 성능을 정량적으로 분석해봤습니다.
1️⃣ 하루 약 1억 건 이상의 SMS 메시지가 수신되고 있었으며,
2️⃣ 기존 구조에서는 Kinesis 수신 이후 DynamoDB 저장까지 평균 수 초에서 수십 초까지 소요되었습니다.
이는 단순히 “Flink를 써보자”가 아니라 “지금보다 빠르고 안정적인 메시지 처리 구조가 반드시 필요하다”는 구체적인 목표로 이어졌고, 이후 설계와 개발 방향에 큰 기준이 되었습니다.
2) 인프라 선택 – AWS Managed Flink
Flink 클러스터 운영에 대한 부담을 줄이기 위해, 우리는 AWS에서 제공하는 Managed Flink 서비스인 ‘Amazon Managed Service for Apache Flink’를 선택했습니다.
AWS의 스트리밍 데이터 처리 서비스는 다음과 같은 발전 단계를 거쳐 현재에 이르렀습니다:
2016년, Amazon은 자체 SQL 엔진 기반의 Kinesis Data Analytics를 출시
→ 하지만 SQL만으로는 복잡한 실시간 처리 요구사항을 만족시키기 어려웠음
→ 이에 따라 2018년, Apache Flink를 사용할 수 있는 기능이 추가됨
이후 기능이 점차 고도화되면서, 2023년 8월부로 서비스명이 'Amazon Kinesis Data Analytics'에서 'Amazon Managed Service for Apache Flink'로 변경되며 현재의 형태로 자리잡았습니다.
AWS Managed Flink는 다음과 같은 점에서 우리가 추구하는 시스템 요구사항에 잘 부합했습니다
완전 관리형 및 서버리스 환경으로, 인프라 운영 부담 없이 애플리케이션 개발에 집중 가능
자동 확장 및 내결함성 지원으로 높은 안정성 확보
Flink 애플리케이션의 설정, 배포, 모니터링을 AWS 환경에서 일관성 있게 관리 가능
IAM 기반의 보안 설정과 CloudWatch를 통한 로깅/모니터링도 손쉽게 연동 가능
이러한 장점 덕분에 우리는 자체적으로 Flink 클러스터를 운영하지 않고도, 안정적이고 확장 가능한 파이프라인을 구축할 수 있었습니다.
3) 개발 환경 구성 – 로컬 vs Managed
AWS에서는 Flink 애플리케이션을 위한 노트북 환경을 제공하며, 코드 실험과 스트림 처리 개발을 간소화해주는 장점이 있습니다.
하지만 실제로 사용해본 결과, UI/UX 측면에서 여러 가지 불편함과 여러 한계도 함께 존재했습니다.
대표적인 제약 사항은 다음과 같았습니다:
에러 메시지가 불친절하고 원인 파악이 어려움
Slack 알림, 외부 모니터링 도구, S3 이외 저장소 등과 연동 시 IAM 설정 등 추가 작업이 필요
필요한 라이브러리를 추가하거나 버전을 조정할 때 재빌드·재배포를 반복해야 하는 번거로움
이러한 이유로 우리는 보다 빠르고 유연한 개발 및 테스트 환경을 확보하기 위해, 로컬 Docker 기반 개발 환경을 직접 구성해 사용했습니다.
이 환경에서는 다음과 같은 점에서 유리했습니다:
개발 유연성
Zeppelin, %flink 매직 명령 등 제한 없이, Flink API(Java, Scala, Python)를 자유롭게 사용할 수 있습니다. IntelliJ, VSCode 등 IDE에서 직접 코드 작성 및 디버깅이 가능해 개발 생산성이 높아졌습니다.테스트와 디버깅 편리
로컬 파일 기반으로 테스트를 반복 실행할 수 있으며, stdout/stderr 로그를 터미널에서 바로 확인할 수 있어 CloudWatch 없이도 빠르게 디버깅할 수 있습니다.버전 및 설정 제어 가능
Flink, JDK, Python 등 환경 구성 요소의 버전을 직접 통제할 수 있고, 필요한 JAR 커넥터나 외부 라이브러리도 손쉽게 추가할 수 있습니다.CI/CD 통합 용이
CI/CD 파이프라인에 애플리케이션 빌드 및 배포를 직접 연동하기에도 용이합니다.
결과적으로, 로컬 개발 환경은 개발과 테스트의 유연성을 확보하면서도 운영 연계까지 고려할 수 있는 현실적인 대안이 되었습니다.
4) 개발 단계 – 주요 처리 로직 구현
처음에는 개발 편의성과 낮은 진입장벽을 고려해, Python 기반의 PyFlink로 개발하는 방안을 검토했습니다. 하지만 실제 테스트해본 결과, PyFlink는 지원하는 API가 제한적이고, 일부 커넥터나 고급 기능들이 미지원되어, 우리가 구현하고자 했던 복잡한 처리 로직에는 적합하지 않다는 판단을 내리게 되었습니다.
결국, 보다 안정적이고 기능적으로 완성된 Scala API 기반 Flink 애플리케이션으로 방향을 전환하게 되었습니다.
Scala 기반 Flink는 다음과 같은 점에서 유리했습니다:
풍부한 API 지원: 다양한 연산자, 커넥터, 윈도우 처리 기능 제공
충실한 공식 문서 및 커뮤니티 자료
Flink 내부 아키텍처와의 자연스러운 연동 (특히 상태 관리, 사이드 아웃풋 등)
Flink 기반 실시간 파이프라인을 개발하면서, 우리는 다음과 같은 핵심 기능들을 적극 활용했습니다:
ProcessFunction – 메시지 유형 분기 처리
ProcessFunction은 데이터 흐름을 조건에 따라 유연하게 분기할 수 있도록 도와주는 Flink의 기본 기능입니다. 우리는 SMS의 버전과 전송 상태에 따라 SMS 또는 SMS 수신 flag를 분리해야 했고, 이를 OutputTag와 함께 활용해 단일 스트림에서 두 가지 메시지 타입을 동시에 처리할 수 있도록 구현했습니다. 사이드 아웃풋 구조를 활용한 이 방식은 복잡한 조건 분기 로직을 깔끔하게 정리하는 데 효과적이었습니다.
KeyedProcessFunction – 메시지 지연 처리
일부 메시지는 수신 즉시 처리하기보다는, 특정 조건을 만족할 경우 일정 시간 지연 후 처리해야 했습니다. 이를 위해 Android ID 기준으로 스트림을 그룹화한 뒤, KeyedProcessFunction 기반의 커스텀 DelayProcessFunction을 구현했습니다. 메시지를 상태에 저장하고 타이머를 등록한 뒤, 타이머가 만료된 시점에만 emit하는 구조로, 유실 없이 지연 메시지를 정확한 타이밍에 처리할 수 있었습니다.
Session Windows – 중복 메시지 처리
짧은 시간 내에 동일하거나 유사한 메시지가 반복 수신되는 경우를 처리하기 위해, ProcessingTimeSessionWindows를 적용했습니다. Android ID 기준으로 세션을 구성한 후, 동일 세션 내의 메시지를 reduce 연산으로 하나로 압축해 처리함으로써, 불필요한 중복 저장을 방지하고 데이터 정합성을 높일 수 있었습니다.
StreamingFileSink – 비용 효율적 S3 저장
초기에는 Kinesis Firehose를 통해 메시지를 S3에 저장하는 구조를 사용했지만, 테스트를 거치며 비용이 과도하게 발생하고, 저장 포맷의 제약이 크다는 점을 확인했습니다. 이에 따라 Flink의 StreamingFileSink를 사용하여 메시지를 Parquet 포맷으로 압축 저장하고, 날짜 기준으로 버킷을 분리해 저장하는 구조로 전환했습니다. Flink 애플리케이션 내부에서 메시지 처리와 저장이 일괄적으로 이뤄지기 때문에 운영이 간소화되었고, 결과적으로 Kinesis Firehose 대비 운영 비용을 크게 절감할 수 있었습니다.
이처럼 Flink의 다양한 기능들을 유기적으로 조합함으로써, 조건 분기, 지연 처리, 중복 제거, 비용 최적화된 저장 등 실시간 메시지 처리에 필요한 여러 시나리오를 안정적이고 유연하게 구현할 수 있었습니다.
5) 최종 검증과 통합 모니터링 체계
검증: 기존 파이프라인과의 정합성 비교
Flink 파이프라인 개발을 마친 후, 본격적인 운영에 앞서 약 2주간의 in-house 테스트를 통해 데이터 정합성과 누락 여부에 대한 검증 작업을 수행했습니다. 검증은 기존 Nifi 기반 파이프라인과 동일 기간 동안 수집된 데이터를 기준으로 비교하는 방식으로 진행되었으며, 핵심 메시지 필드(android_id, message, message_received_time, sms_sender)를 기준으로 데이터가 정상적으로 수집, 처리, 저장되었는지를 확인했습니다.
이 과정에서 ingestion time 기준으로 기준 날짜가 달라질 수 있는 경우를 감안해, 전후 날짜의 데이터를 함께 비교했고, 누락이나 중복 여부를 정밀하게 분석했습니다. 결과적으로 Flink 파이프라인에서는 날짜 차이로 인한 경계 케이스는 일부 있었지만, 데이터 누락은 없는 것으로 확인되었고, 기존 Nifi 파이프라인에서는 특정 필드 매핑 오류로 인해 일부 메시지 누락이 발생했던 사례도 함께 발견되었습니다.
이러한 검증 결과를 바탕으로, Flink 파이프라인이 정합성과 안정성 면에서 기존 대비 충분한 수준의 신뢰도를 갖추고 있음을 확인했고, 안정적인 운영 전환의 근거로 삼을 수 있었습니다.
모니터링: CloudWatch 기반 통합 대시보드 구성
운영 전환과 함께 실시간 운영 상황을 관찰하고 빠르게 대응할 수 있도록, CloudWatch 메트릭을 기반으로 한 Grafana 통합 대시보드를 구성했습니다. 단일 시스템이 아닌, 전체 데이터 흐름(Kinesis → Flink → DynamoDB)을 하나의 대시보드에서 통합적으로 관찰할 수 있도록 설계한 것이 핵심입니다.
Kinesis는 Get Records, Get Records Latency, Get Records Success, Flink Behind Latest 등의 메트릭을 활용해 데이터 수신 지연이나 오류 여부를 실시간 확인할 수 있도록 구성했습니다.
Flink는 Uptime, KPU, Thread Count, CPU/Memory/Disk Utilization, Busy Time, Back Pressure Time, Checkpoint Size/Duration, Num Records In/Out, Task 단위 처리량 등 다양한 메트릭을 활용해 시스템 자원과 내부 처리 상태를 직관적으로 파악할 수 있게 했습니다.
DynamoDB는 Provisioned Capacity, Consumed Capacity, Write Throttle Events 등을 모니터링하여 타겟 데이터 저장 단계에서의 병목이나 리소스 한계 상황도 빠르게 감지할 수 있도록 구성했습니다.
이러한 구조는 특정 컴포넌트의 문제나 지연이 전체 파이프라인에 어떤 영향을 미치는지를 한 눈에 파악할 수 있게 해주며, 운영 중 이상 징후를 조기에 감지하고 대응할 수 있는 기반 체계로 활용되고 있습니다.
6) 안정적인 전환을 위한 운영 배포 전략
Flink 파이프라인으로의 전환은 단순한 개발 마이그레이션이 아니라, 실제 운영 환경에서 서비스 연속성과 안정성을 유지하며 진행되어야 했기 때문에 배포 시점과 절차에도 충분한 준비가 필요했습니다.
우리는 메시지 유입량이 가장 적은 시간대인 오전 4:30~5:30(IST 기준)을 배포 타이밍으로 정했고, 그에 맞춰 사전 준비와 단계별 전환 절차를 수립했습니다.
배포는 다음과 같은 순서로 진행되었습니다:
DynamoDB 용량 수동 조정: 일정 시간 동안 기존 Nifi 파이프라인과 새로운 Flink 파이프라인이 동시에 작동해야 했기 때문에, DynamoDB의 처리량을 일시적으로 수동 확장해 두 파이프라인의 부하를 안정적으로 처리할 수 있도록 했습니다.
신규 Flink 파이프라인 기동
신규 파이프라인 데이터 적재 상태 확인
모니터링 시스템으로 신규 파이프라인 정상 여부 점검
기존 Nifi 파이프라인 종료
DynamoDB 자동 스케일링 활성화로 복귀
메시지 데이터의 특성상 중복이 허용되는 구조이기 때문에, 파이프라인 전환 중에도 서비스는 중단되지 않았으며, 문제가 발생할 경우 기존 Nifi 파이프라인을 재기동하는 방식으로 롤백 계획도 마련해두었습니다.
이러한 절차를 통해, 운영 중단 없이 안전하게 파이프라인 전환을 완료할 수 있었고, 새로운 Flink 기반 메시지 파이프라인이 실시간 처리를 안정적으로 이어받을 수 있도록 구성할 수 있었습니다.
4. Flink 도입 이후, 어떤 변화가 있었나?
Flink 파이프라인을 본격 도입하면서 우리는 단순한 처리 성능 향상을 넘어, 데이터 처리 구조, 운영 안정성, 확장성 전반에 걸쳐 유의미한 변화를 경험할 수 있었습니다.
성능 향상
가장 직접적으로 체감할 수 있었던 변화는 처리 지연 시간의 개선이었습니다.
Flink 도입 이후 전체 메시지 처리 지연 시간이 모든 구간에서 크게 감소했습니다.
Flink 파이프라인은 병렬 처리와 스트림 중심의 구조 덕분에 전체적으로 더 빠르고 안정적인 처리 속도를 보여주었습니다. 특히 상위 10% 처리 지연 구간에서 기존 대비 60% 이상 개선된 결과를 확인할 수 있었습니다.
복잡한 데이터 처리 대응력
기존 Nifi 파이프라인은 메시지를 캐시에 저장한 후 처리하는 구조였기 때문에, 상태를 유지하거나 시간 기반으로 집계하는 로직 구현에는 한계가 있었습니다.
Flink에서는 Stateful Stream Processing을 통해 각 이벤트의 상태를 저장하고, 세션 단위로 집계하는 등의 복잡한 시간 기반 연산이 가능해졌습니다.
예를 들어 SMS 전송 시작/완료 여부(flag)의 경우, 세션 윈도우 방식을 적용하여 사용자 단위 세션 기반 집계가 가능해졌고, DynamoDB의 write throttle 현상도 효과적으로 줄일 수 있었습니다.
운영 방식의 변화: 코드 중심 관리
기존에는 UI 기반의 구성 도구(Nifi)를 통해 데이터 흐름을 시각적으로 정의하고 관리해야 했습니다.
이 방식은 빠르게 구축하는 데에는 적합하지만, 로직 변경 시 일관성 관리나 테스트 자동화 측면에서는 제약이 있었습니다.
Flink 전환 이후에는 전체 스트림 처리 로직을 프로그램 코드로 정의하고 관리하게 되었고, 이를 통해 버전 관리, 코드 리뷰, 테스트 자동화, 배포 자동화까지 유기적으로 연동할 수 있는 환경을 구축할 수 있었습니다.
덕분에 운영 관점에서도 변화에 유연하고 구조적으로 관리 가능한 체계로 전환되었습니다.
인프라 격리와 안정성 확보
이전에는 모든 메시지 파이프라인이 단일 Nifi 클러스터 내에서 운영되었기 때문에, 하나의 파이프라인에 문제가 발생하면 전체 클러스터 성능에 영향을 미치는 구조였습니다.
Flink 환경에서는 각각의 애플리케이션이 독립적인 KPU(Kinesis Processing Unit)를 할당받아 운영되므로, 서로 다른 파이프라인 간의 간섭 없이 격리된 환경에서 안정적으로 운영할 수 있습니다.
실제 운영 중에도 다른 파이프라인의 장애가 본 SMS 파이프라인에 영향을 주지 않는 구조적 안정성을 확보할 수 있었습니다.
확장성 확보
기존 Nifi는 자원 사용량을 모니터링한 후, 클러스터 노드 구성을 수동으로 조정해야 했습니다.
이 과정은 반복적인 인프라 작업과 운영 리스크를 동반했으며, 순간적인 부하에 즉각적으로 대응하기 어려웠습니다.
Managed Flink 환경에서는 리소스 사용량과 처리량을 기반으로 자동으로 병렬성을 조정할 수 있는 구조를 제공하며, 트래픽 급증에도 안정적으로 대응할 수 있는 자동 확장성과 자원 최적화를 동시에 실현할 수 있게 되었습니다.
이러한 변화를 통해 우리는 단순한 기술 스택 교체를 넘어서, 보다 정교하고 안정적인 실시간 데이터 처리 체계를 확보할 수 있었고, 기존 파이프라인에서 경험하던 여러 운영상 제약을 체계적으로 해결할 수 있었습니다.
5. 앞으로의 계획과 Flink의 역할
이번 메시지 파이프라인의 전환은 단순한 시스템 교체가 아닌, 우리가 실시간 데이터 처리 체계를 근본적으로 재정비하는 계기였습니다.
이를 기반으로 우리는 앞으로도 더 안정적이고 유연한 스트리밍 환경을 만들기 위해 다음과 같은 계획을 이어갈 예정입니다.
향후 계획
먼저, 현재의 Flink 기반 파이프라인을 더 범용적으로 확장할 수 있도록 공통된 스트리밍 개발 환경을 정비할 예정입니다. 이를 통해 새로운 스트림 처리 로직을 빠르게 개발하고 배포할 수 있는 기반을 마련하려고 합니다.
또한 코드베이스 정리를 통해 가독성과 유지보수성을 개선하고, CI/CD 연동을 통한 배포 자동화 체계도 고도화할 계획입니다. 테스트 자동화, 린 배포, 롤백 대응 등의 흐름도 함께 정비해 개발과 운영 간의 전환을 더 자연스럽게 연결하는 것이 목표입니다.
운영 관점에서는 모니터링과 알람 체계를 강화하여 이상 징후를 조기에 감지하고, 운영자가 더 빠르게 대응할 수 있도록 체계를 지속 개선해 나갈 예정입니다.
Flink의 역할
Flink는 이제 단순한 SMS 처리 도구가 아니라, 실시간 신용평가를 위한 핵심 데이터 수집 인프라의 중심축으로 자리잡고 있습니다. 우리가 실시간으로 수집하고 처리하는 SMS는 사용자 신용 상태를 이해하고, 적절한 시점에 금융 서비스를 제공하는 데 필수적인 요소이기 때문입니다.
Flink는 또한 구조적으로 확장 가능한 기반 기술입니다. 이번 SMS 파이프라인을 시작으로, 다양한 실시간 스트림 파이프라인으로의 확장이 가능하며, 복잡한 상태 기반 분석, 이벤트 기반 의사결정, 실시간 알림 처리 등 더 많은 도메인에서 활용될 수 있는 잠재력을 갖추고 있습니다.
이번 전환은 단지 하나의 파이프라인을 바꾸는 작업이 아니었습니다.
실시간 데이터 기반 의사결정 체계를 신뢰할 수 있는 구조로 옮기는 첫걸음이었고, Flink는 그 변화의 중심에서 중요한 역할을 하고 있습니다.
Apache Flink는 단순한 처리 성능 향상을 넘어, 실시간 시스템의 신뢰성과 확장성까지 함께 가져다준 강력한 기반 기술이었습니다. 앞으로도 우리는 변화하는 요구와 기술을 빠르게 수용하며, 더 나은 데이터 인프라를 위한 지속적인 개선을 이어갈 것입니다.