데이터 엔지니어링 기반으로 자동화 처리 시스템을 팀 단위로 구축하는 프로젝트형 스터디입니다.
학습 중심이 아닌, 역할 분담 기반의 협업 중심 실전 경험을 목표로 합니다!!
1. 스터디 목표
제가 지향하는 방향은 실무 중심 + 협업 중심입니다.
단순히 기술을 공부하는 모임이 아니라,
프로젝트를 팀 단위로 역할을 나눠 실제처럼 운영합니다.
예시:
인원 A → DB 스키마 설계 및 성능 고려
인원 B → 데이터 파이프라인(ETL) 설계
인원 C → Airflow DAG 구성 및 스케줄링
인원 D → MLflow 기반 모델 관리
인원 E → Docker/AWS 배포 환경 구성
각자 맡은 파트를 책임지고 구현하지만,
최종 목표는 하나의 통합된 시스템 완성입니다.
즉, 개인 과제가 아니라
협업 구조 속에서 문제를 해결하는 경험을 만드는 스터디입니다.
2. 진행 방식
Step 1. 문제 정의
예시: 고객 이탈 예측 자동화 파이프라인 구축
단순히 “모델 만들기”가 아니라,
어떤 데이터를 어떻게 자동으로 수집·가공·적재·학습까지 연결할 것인지 정의합니다.
정의 항목 예시:
데이터 범위: 주문 이력, 접속 로그, 고객 등급 정보
이탈 정의 기준: 30일 이상 미구매 고객
모델 목표 지표: F1-score 0.75 이상
처리 주기: 매일 새벽 3시 자동 실행
최종 산출물: 예측 결과 테이블 + 대시보드용 적재 데이터
이 단계에서 “기술”이 아니라 “시스템 목적”을 명확히 합니다.
Step 2. 설계 문서 작성
실제 실무처럼 문서부터 만듭니다.
1) 데이터 흐름도
Raw → Staging → Mart → Feature → Model → Prediction
각 레이어에서 무엇이 변환되는지 정의
2) 데이터 흐름도
Raw → Staging → Mart → Feature → Model → Prediction
각 레이어에서 무엇이 변환되는지 정의
3) Airflow DAG 설계
extract_task
transform_task
feature_engineering_task
train_task
predict_task
Task 의존성 정의 (Upstream / Downstream)
4) Docker 구성도
airflow container
postgres container
mlflow container
trainer container
네트워크 및 볼륨 구조까지 설계
설계 문서가 승인되기 전까지 코드 작성 금지
Step 3. 구현
이 단계는 “코딩”이 아니라 협업 실행 훈련입니다.
Docker Compose로 개발 환경 통일
Git feature 브랜치 전략 적용
PR 리뷰 필수 (최소 1인 승인 후 merge)
이슈 단위 개발 (task 단위 쪼개기)
예시 흐름:
DB 설계 담당 → migration PR 생성
파이프라인 담당 → ETL 모듈 PR 생성
DAG 담당 → 의존성 연결 PR
충돌 발생 → 설계 문서 수정 후 재조정
단순 기능 구현이 아니라
통합 과정에서 발생하는 충돌을 해결하는 경험이 핵심입니다.
Step 4. 회고
단순 “느낀 점 공유”가 아니라 구조적 분석을 합니다.
예시 질문:
설계 문서와 실제 구현이 왜 달라졌는가?
데이터 스키마 변경이 왜 발생했는가?
Task 의존성이 잘못 설계된 부분은 무엇인가?
배포 시 컨테이너 충돌 원인은 무엇인가?
역할 분담이 명확했는가??
그리고 반드시 정리합니다:
다음 프로젝트에서 바꿀 점 3가지
유지할 점 3가지
기술이 아닌 “협업 방식” 개선 안
3. 운영 스킬
Linux (운영 환경)
Git / GitHub (형상관리)
Docker (컨테이너 환경)
RDBMS (PostgreSQL, MySQL)
Python (ETL / 데이터 처리)
Airflow (워크플로우 관리)
AWS (EC2, S3 중심)
MLflow (모델 관리)
Spark 또는 대용량 처리 경험
------------------------------
이런 분을 찾습니다.
실무형 데이터 엔지니어링 구조를 경험하고 싶은 분
협업을 통해 성장하고 싶은 분
단순 코드 작성이 아니라 “운영 경험”을 쌓고 싶은 분
관심있으신 분은 아래 오픈 카톡으로 연락주세요.
