사용자에서 데이터 엔지니어로, 쏘카 온보딩 회고

쏘카 데이터엔지니어링팀 신입 엔지니어가 K8s·Airflow·MSK·KDS를 처음 접하며 3개월 만에 실프로젝트 2개를 완료한 온보딩 회고다. 운전 점수 MSK Produce와 서버 로그 KDS Consumer를 구현하며 MSK vs KDS 차이를 실전에서 체감한 내용을 담았다.

핵심 포인트

MSK vs KDS 핵심 차이: MSK는 offset 자동 관리로 Consumer가 읽은 위치를 신경 쓰지 않아도 됨, KDS는 sequence number 직접 관리 필요
MSK vs KDS 스케일링: MSK는 파티션 수 감소 불가, KDS는 샤드 수 동적 조정 가능해 리소스 관리 더 유연
프로젝트 1(운전 점수 파이프라인): 운행 기록 통계화 → 운전 점수 산출 → AWS MSK Produce, 데이터 누락·지연 처리가 핵심 과제
프로젝트 2(서버 로그 KDS Consumer): K8s 위 Consumer 서비스 구축, Helm 차트 작성·배포, 레거시 시스템 병행 운영 설계
Glue Schema 도입: MSK Produce/Consume 간 데이터 스키마 일관성 유지, 팀 간 협업 시 스키마 변경 효율 관리
온보딩 체계: K8s·Helm 등 핵심 기술 스택 포함 과제, Notion 내부 문서 기반 자기주도 학습, 입사 1개월 후 온콜 엔지니어 참여

상세 정리

입사 배경: 의료기기 스타트업 데이터 엔지니어, 소규모 데이터 경험, K8s·Spark·Flink 미경험 상태로 입사
데이터 규모 기준: "하루 안에 정합성 문제 해결 가능 여부" → 쏘카는 대용량 데이터 기준에 해당
운전 점수 프로젝트: 데이터 누락·지연 발생 → 적재 스케줄 조정으로 완화, 마케팅 엔지니어링팀과 MSK 데이터 포맷 긴밀히 협의
정합성 보장: Produce 단계에서 코드로 검증 로직 구현, 25년 1월 중순 서비스 배포 완료
KDS Consumer 경험: Helm 차트로 K8s 배포 환경 구성, 온보딩 K8s 학습을 실프로젝트에 바로 적용
레거시 병행 운영: 기존 시스템 유지 상태에서 새 구조로 전환, 데이터 정합성 지속 확인 방법 설계
온콜 엔지니어 경험(입사 1개월 후): Opsgenie 스케줄, 데이터 적재·재적재·GCP 권한·Airflow 에러 등 Ad-hoc 다양하게 대응
컨텍스트 스위칭이 가장 어려웠으나 파이프라인·인프라 전체 구조 파악에 가장 효과적