ML Systems Data Engineering

ML은 빅데이터의 성장과 맞물려 있습니다. 대규모 데이터 시스템은 복잡하며 표준과 도구가 빠르게 변합니다. 이 글은 데이터 소스 → 데이터 포맷/저장 방식 → 데이터 모델(관계형·NoSQL) 순서로 기초를 정리하여, 실무에서 흔히 마주치는 선택지를 이해하도록 돕습니다. 프로세스 간 데이터 전달 방식과 배치/스트림 처리의 구분은 후속 글에서 다룹니다.

---

데이터 소스(Data Sources)

• 사용자 입력 데이터: 텍스트·이미지·동영상·파일 등 오입력 가능성이 높아 강한 검증과 짧은 지연의 빠른 처리가 필요합니다.
• 시스템 생성 데이터: 로그·서비스 출력·모델 예측 등입니다. 보통 주기적 처리가 가능하나, 이상 징후 탐지를 위해 빠른 파이프라인을 갖추면 좋습니다. 대량 저장 시 저빈도 접근 스토리지 활용을 고려합니다.
• 행동 로그(사용자 행태): 클릭·스크롤 등으로, 개인정보 이슈에 유의합니다.
• 사내 운영 DB: 재고·CRM·사용자 등 내부 앱 데이터입니다. 예로, 검색 질의 의도 파악 후 가용 제품을 내부 DB에서 조회합니다.
• 서드파티 데이터: 타사가 수집·가공해 판매하는 데이터입니다. 최근 프라이버시 정책 변화로 가용성이 줄어 퍼스트파티 데이터의 중요성이 커졌습니다.

---

데이터 포맷(Data Formats)

데이터를 저장·전송하기 위해 직렬화를 사용합니다. 선택 시 가독성, 접근 패턴, 텍스트/바이너리 여부, 크기를 고려합니다.

대표 포맷 개관

• JSON(텍스트, 가독성 있음): 범용적입니다. 스키마를 나중에 바꾸면 역호환성 이슈가 큽니다.
• CSV(텍스트, 행 지향) ↔ Parquet(바이너리, 열 지향): 두 패러다임을 대표합니다.
• Avro/Protobuf/TFRecord/피클: 바이너리 위주의 포맷입니다.

행 지향(Row-major) vs 열 지향(Column-major)

• 행 지향(CSV): 연속된 행 원소가 메모리상 인접합니다. 샘플 단위 접근·쓰기가 빠릅니다.
• 열 지향(Parquet): 연속된 열 원소가 인접합니다. 특정 열만 부분 읽기가 효율적입니다. 수천 개 특성 중 일부 열만 읽는 분석에 유리합니다.
• 결론: 쓰기가 많으면 행 지향, 열 기반 조회가 많으면 열 지향이 적합합니다.

pandas vs NumPy

• pandas DataFrame은 열 지향을 전제로 설계되었습니다. 열 단위 반복이 행 단위 반복보다 훨씬 빠릅니다.
• 같은 데이터를 NumPy ndarray(기본 행 지향)로 변환하면 행 접근이 빨라집니다.

텍스트 vs 바이너리

• 텍스트 파일은 사람이 읽기 쉽지만 용량이 큽니다. 예를 들어 1000000을 텍스트로 저장하면 7바이트, int32 바이너리로는 4바이트입니다.
• 예시: 17,654×10 크기의 CSV(텍스트) 14MB가 Parquet(바이너리) 6MB로 감소했습니다.
• AWS는 Parquet가 텍스트 대비 최대 2배 빠른 언로드와 최대 6배 저장 절감이 가능하다고 권장합니다.

---

데이터 모델(Data Models)

관계형 모델(Relational)

• 릴레이션은 튜플의 집합이며 표(table)로 시각화합니다. 행·열의 순서는 의미가 없습니다.
• 정규화로 중복을 줄이고 무결성을 높입니다. 예를 들어 Book에서 Publisher를 분리하면 출판사 정보 변경 시 단일 테이블만 업데이트하면 됩니다. 다만 JOIN 비용이 커질 수 있습니다.
• SQL은 선언적 언어입니다. 무엇을 질의할지 표현하면 DB 옵티마이저가 어떻게를 결정합니다. 임의 질의 최적화는 난이도가 높아 쿼리 옵티마이저의 품질이 중요합니다.

선언적 ML로의 확장

• Ludwig, H2O AutoML 등은 스키마와 태스크만 선언하면 모델 탐색·학습을 자동화합니다. 다만 특징 공학, 데이터 처리, 평가, 시프트 감지, 지속 학습 등 운영상의 어려움은 여전히 남습니다.

NoSQL(= Not Only SQL)

관계형의 엄격한 스키마와 복잡한 SQL의 제약을 완화합니다.

• 문서 모델(Document): JSON/BSON 등 문서 단위 저장으로 지역성이 좋아 단일 개체 조회가 쉽습니다. 컬렉션 내 문서는 서로 다른 스키마를 가질 수 있습니다. 반면 문서 간 조인·범위 질의는 비효율적입니다.
• 그래프 모델(Graph): 노드·엣지로 관계를 1급 개념으로 모델링합니다. 관계 경로 탐색(예: 미국에서 태어난 모든 사람)이 빠릅니다. 미지의 홉 수 탐색은 관계형·문서형에서 표현과 성능 모두 불리합니다.

실무에서는 관계형과 문서형을 함께 지원하는 DB(PostgreSQL, MySQL 등)도 널리 사용합니다.

---

구조화 데이터 vs 비구조화 데이터

• 구조화 데이터: 명시적 스키마를 따릅니다. 검색·분석이 용이하나 스키마 변경 비용이 큽니다.
• 비구조화 데이터: 스키마 없이 텍스트·수치·이미지 등 임의 포맷을 저장합니다. 저장은 유연하나, 해석 책임이 다운스트림 애플리케이션으로 이동합니다.
• 데이터 웨어하우스: 가공된 구조화 데이터 저장소입니다.
• 데이터 레이크: 원천·혼합 데이터 저장소입니다. 보통 후처리 전 단계로 사용합니다.

---

맺음말

데이터 시스템은 소스·포맷·모델의 선택에 따라 성능, 비용, 운영 난이도가 크게 달라집니다.

• 읽기 패턴이 열 중심이면 열 지향 포맷과 분석 친화 DB를,
• 쓰기·온라인 트랜잭션이 빈번하면 행 지향·트랜잭션 DB를,
• 관계 탐색이 핵심이면 그래프 모델을 우선 고려하는 것이 합리적입니다.

단일 해법보다 복합 전략이 일반적입니다.

이후에는 프로세스 간 데이터 전달, 배치 vs 스트림 처리, 레이블 생성·샘플링을 다룰 예정입니다.