Nasdaq Stock Pipeline 회고록
프로젝트를 시작한 이유
제가 데이터관련 업을 시작하게 된계기는 주식 자동화 매매 시스템 구축이었습니다. 이전부터 각종 강의를 들으면서 단일 머신에서 동작하는 주식매매 파이썬 프로그램을 만든 이후 겪었던 데이터 수집단계에서의 문제점 실시간 데이터의 활용 등등.. 엔지니어링 관점에서 관심있는 주제를 다뤄보고 싶었습니다.
특히 실시간성이 중요한 주식 도메인이었기 때문에 Kafka를 중심으로 한 이벤트 스트리밍 아키텍처를 선택했고, 배치와 스트리밍을 함께 사용하는 Lambda Architecture를 처음으로 실제로 구현해본 프로젝트입니다.
성과
메타코드 오프라인 모임 발표 및 우수사례 선정
프로젝트 완성 후 메타코드(Metacode) 오프라인 모임에서 발표했고, 우수사례로 선정되었습니다. 발표 영상이 메타코드 유튜브 채널에 업로드되어 있습니다.
📺 발표 영상 보기
멀티캠퍼스 기업 교육 콘텐츠 제안
발표 이후 메타코드 측으로부터 아래와 같은 연락을 받았습니다.
멀티캠퍼스 교육 플랫폼에 업로드되어 제휴 기업 임직원 대상으로 제공되는 콘텐츠로 채택되었습니다.
배운 것들
기술적으로
- Lambda Architecture를 직접 구현 — 배치(Airflow)와 스트리밍(Kafka + Spark)을 분리하고, Redis를 Serving Layer로 두어 두 데이터를 결합하는 구조를 처음부터 설계하고 구현했습니다.
- Kafka 운영 경험 — 토픽 분리 전략, 파티션 키 설계, 멱등성 설정, DLQ 운영까지 프로덕션에 가까운 수준으로 다뤄볼 수 있었습니다.
- Spark Structured Streaming — 정적 배치 데이터와 실시간 스트림을 조인하여 기술적 지표를 계산하는 하이브리드 처리를 구현했습니다.
- 트러블슈팅 경험 — DuckDB 동시성 문제, Airflow OOM, 단일 DB vs 샤딩 성능 비교 등 실제 운영에서 마주치는 문제들을 직접 해결하면서 판단력이 생겼습니다.
설계 측면에서
- 처음부터 완벽한 설계를 하려 하기보다, 동작하는 것을 먼저 만들고 문제를 만나면서 개선하는 방식이 더 효과적이었습니다. 그 과정에서 파일기반으로 동작하는 sqllite, duckdb 의 한계를 알게 되었습니다.
- 기술 선택에는 항상 트레이드오프가 있습니다. DuckDB에서 PostgreSQL로 전환한 것처럼, 빠른 프로토타입 도구가 운영 환경에서는 제약이 될 수 있습니다.
아쉬운 점
- 짜투리 시간을 활용하여 작업을 하다보니, 실시간 알림 기능(Slack, 이메일 등)까지 연결하지 못했습니다. 이후 개선 프로젝트를 반영했을때 해당 기능을 추가시킬 예정입니다.
- Spark 튜닝(파티셔닝 전략, 셔플 최소화)을 체계적으로 적용하지 못하고 기본 설정으로 운영했습니다. → 스터디를 통해 추가 학습이후 성능 최적화도 구현해 볼 계획입니다.
- 테스트 코드가 부족했습니다. 특히 Kafka Consumer 로직의 단위 테스트가 없어 변경 시 불안감이 있었습니다.
다음에 한다면
- dbt를 배치 레이어 변환 단계에 도입하여 SQL 기반으로 지표 계산 로직을 관리하고 싶습니다.
- 스트리밍 처리를 Flink로 대체해서 상태 관리(stateful processing)를 더 세밀하게 다뤄보고 싶습니다.