STT(Speech-to-Text) 및 TA(Text Analysis) AI 데이터를 시각화하는 대시보드를 운영하고 있습니다. 초기 웹 애플리케이션은 대시보드 성격보다는 AI 추론 결과를 검증하고 재학습 데이터를 생성하기 위한 검증 도구로 설계되었습니다. 이후 고객 니즈에 따라 대시보드 화면이 추가되었고, 점차 분석 및 조회 기능이 확장되었습니다.
초기에는 모든 데이터를 RDB 기반으로 조회하는 아키텍처로 구성되어 기능적으로 큰 문제는 없었습니다. 그러나 데이터 적재 기간이 길어지면서 전체 데이터 규모가 증가했고, 고객 요청에 따라 조회 및 분석 대상 필드가 지속적으로 추가되었습니다.
그 결과, 단순 데이터 증가뿐 아니라 스키마 확장으로 인한 조회 복잡도 및 성능 저하 문제가 발생하기 시작했습니다.
1. 기존 구조의 한계: RDB로는 감당하기 어려운 조회
웹 애플리케이션에는 API 요청 타임아웃이 30초로 설정되어 있습니다.
대시보드 특성상 다음과 같은 고비용 쿼리가 빈번하게 발생했습니다.
- 다수 테이블간 JOIN
- 날짜 기준 집계 집계 (GROUP BY)
- 조회 기간이 길어질수록 스캔 범위가 증가하는 구조
데이터 규모가 증가함에 따라, 1개월 이상의 기간을 조회할 경우 API 타임아웃이 빈번하게 발생했습니다.
인덱스 튜닝 및 쿼리 최적화를 시도했으나, OLTP 용도로 설계된 RDB 환경에서 OLAP 성격의 집계·분석 쿼리를 지속적으로 처리하는 데에는 구조적 한계가 존재했습니다.
결국 운영 안정성을 확보하기 위해 조회 기간을 1개월로 제한하는 정책을 적용하였으며, 이는 곧 고객 사용성 저하 및 불편으로 이어졌습니다.
JOIN 및 집계 쿼리로 고비용 조회 요청이 현실적으로 어려웠던 기존 대시보드 화면
2. 요구사항 변화: “1년치 데이터를 보고 싶다”
고객사에서 1년치 데이터 조회를 요청했습니다. 이 시점에서 선택지는 명확했습니다.
- RDB 기반 구조를 유지한 채 임시방편을 늘릴 것인가
- 분석 전용 저장소를 도입할 것인가
문제의 본질은 단순한 성능 개선이 아니었습니다. 핵심은 대용량 데이터에 대한 집계 및 분석 쿼리를 안정적으로 처리할 수 있는 아키텍처를 갖추는 것이었습니다
기존 RDB 구조는 OLTP 중심으로 설계되어 있었으며, 1년치 데이터 범위의 집계·조인·그룹화 연산을 지속적으로 처리하기에는 구조적 한계가 명확했습니다..
3. AWS Redshift Serverless를 선택한 이유
왜 Redshift인가
요구사항은 전형적인 분석 워크로드였습니다.
- 대량 데이터 스캔
- 기간 기반 집계
- 대시보드 조회 중심
이는 트랜잭션 처리보다 분석 처리(OLAP)에 최적화된 저장소가 적합했습니다.
왜 Serverless인가
Redshift 중에서도 Serverless를 선택한 이유는 다음과 같습니다.
- 클러스터 운영 부담 없음
- 노드 타입 선정, 용량 예측, 수동 스케일링 등의 운영 관리가 불필요
- 탄력적 리소스 사용
- 조회 트래픽이 상시 일정하지 않고 특정 시점에 집중되는 패턴
- 빠른 도입
- PoC부터 서비스 적용까지 속도가 중요
유지 비용은 RDB보다 증가했지만, 성능 + 개발/운영 공수 감소를 함께 고려했을 때 합리적인 선택이었습니다.
4. 초기 설계: RDB → Redshift 배치 적재
초기 아키텍처는 비교적 단순한 배치 기반 동기화 구조였습니다.
- 적재 주기: 일 단위 배치
- 기준 컬럼: 날짜(Date) 기준
- 적재 방식: 변경 또는 신규 데이터만 반영하는 Incremental Load
운영 중인 RDB를 소스(Source)로 유지하면서, AWS Glue를 활용해 정기 배치 작업을 수행하고 Redshift로 데이터를 적재했습니다.
결과는?
Redshift 전환 이후 대시보드 조회 성능은 눈에 띄게 개선되었습니다.
- 대량 집계 쿼리 응답 시간 단축
- 1개월 제한 정책 해소
- 장기간 데이터 조회 가능
5. 문제 발생: 결과 재처리와 데이터 정합성
데이터 특성상 재처리 요청이 종종 발생했습니다.
- AI 추론 재처리 결과 변경됨
- RDB 원본 데이터 수정
문제는 여기서부터였습니다
- RDB: 최신 데이터
- Redshift: 과거 결과 유지
단순한 일 배치 구조로는 이미 적재된 Redshift 데이터와의 정합성을 맞출 수 없었습니다. 데이터를 빠르게 보여주는 것보다, 맞는 데이터를 보여주는 것이 더 중요한 상황이었습니다.
6. 해결 방향: 이벤트 기반 데이터 적재
핵심은 단순합니다. “데이터가 변경된 시점을 기준으로, 필요한 범위만 다시 적재하자.”
이를 위해 EventBridge 기반 구조로 파이프라인을 재설계했습니다.
이벤트 트리거
- RDB 데이터 적재 배치가 완료될 때마다 이벤트 발행
- 이는 데이터가 추가되거나 수정되었음을 의미
이벤트에는 다음의 추가 정보가 포함됩니다.
- 변경된 데이터의 날짜 범위 (예: 2026-01-01 ~ 2026-01-03)
Amazon EventBridge Rule 설정 콘솔 화면
7. Lambda의 역할: 판단이 아닌 조정
EventBridge는 이벤트를 감지하고, Lambda는 그 이벤트를 해석해 Glue Job을 실행합니다.
Lambda의 책임은 명확합니다.
- 이벤트로부터 날짜 범위 파싱
- Glue Job 실행
- 날짜 범위를 Job Parameter로 전달
Lambda는 데이터를 직접 처리하지 않습니다. “어떤 데이터를 처리할지”만 결정합니다.
EventBridge에서 전달 받은 이벤트의 detail 값을 이용해 AWS Glue Job 실행
8. Glue Job과 Redshift 적재 전략
Glue Job 내부 로직은 최대한 단순하게 유지합니다.
- Lambda로부터 날짜 범위 수신
- 해당 날짜 범위의 Redshift 데이터 삭제
- RDB에서 동일 날짜 데이터 조회
- Redshift에 재적재 (Append 방식)
기존 데이터 변경 시에는 해당 날짜 전체를 삭제 후 재적재하는 전략을 사용합니다.
이 방식의 장점은
- 재실행 안전 (Idempotent)
- 부분 재적재 가능
- 복잡한 MERGE 로직 불필요
9. 최종 구조
RDB에서 Redshift로의 이벤트 기반 데이터 파이프라인
10. 비용 관점에서의 선택
RDB에 집계 테이블을 따로 두는 방식도 고려했지만,
- 집계 로직 개발/유지 비용
- 요구사항 변경 시 대응 어려움
- 여전히 RDB 성능 한계
를 감안하면, Redshift 도입이 장기적으로 더 합리적이라고 판단했습니다. 단순 인프라 비용이 아니라, 개발·운영 비용까지 포함한 선택이었습니다.
11. 장애 및 재처리 전략
이벤트 기반 구조라도 장애는 발생할 수 있습니다.
- 이벤트 누락
- Glue Job 실패
- 특정 기간 수동 재처리 요청
이를 대비해 로컬 환경에서 EventBridge 이벤트를 직접 발행할 수 있는 간단한 Python 기반 CLI 도구를 자체 개발했습니다.
이 CLI를 통해:
- 날짜 범위를 지정해 이벤트 발행
- 동일한 Lambda → Glue → Redshift 경로로 재적재 수행
자동화 위에, 사람이 개입할 수 있는 재처리 경로를 의도적으로 남겨두었습니다.
boto3를 활용한 EventBridge PutEvents CLI 도구
12.마무리
Redshift Serverless를 도입한 이유는 단순히 “빠른 조회” 때문이 아니었습니다.
데이터 변경을 전제로 한 구조가 필요했고, 그에 맞게 파이프라인을 진화시킨 결과가 지금의 형태입니다. 완벽한 실시간 동기화보다는, 운영 가능한 정합성을 선택한 사례로 참고가 되었으면 합니다.
참고문헌
본 글의 아키텍처 설계 및 서비스 구성은 다음 AWS 공식 문서를 참고했습니다.
AWS 공식 가이드 문서
- https://docs.aws.amazon.com/redshift
- https://docs.aws.amazon.com/glue
- https://docs.aws.amazon.com/eventbridge
- https://docs.aws.amazon.com/lambda/