이 글이 다루는 것
Foundry는 데이터를 어떻게 저장하는가에서 다뤘듯, Foundry는 원본 데이터를 Dataset에 먼저 그대로 적재한 뒤(ELT) 이후 단계에서 정제합니다. 그 “이후 단계”를 실제로 구성하는 도구가 Pipeline Builder이고, 이 도구의 GUI로 표현하기 어려운 복잡한 로직을 코드로 관리하는 도구가 Code Repository입니다. 두 도구는 경쟁 관계가 아니라, 같은 파이프라인을 만드는 두 가지 방식입니다 — 이 글은 언제 어느 쪽을 쓰는지, 그리고 실제로 어떻게 조합해서 쓰는지를 다룹니다.
Pipeline Builder — 드래그 앤 드롭으로 파이프라인 구성하기
파이프라인은 방향성 비순환 그래프(DAG) 구조로 구성됩니다. 순환이 없어야 데이터가 어디서 시작해서 어디서 끝나는지 명확하고, 병렬 처리도 가능합니다. 파이프라인은 보통 세 구간으로 나뉩니다.
| 구간 | 역할 |
|---|---|
| Source | RDBMS, API, 파일 등 원천 Dataset을 읽어옴(스키마 추론 포함) |
| Transform | 정제·가공·병합하는 핵심 로직 |
| Sink | 최종 결과를 Dataset으로 다시 적재(이후 Ontology Manager에서 매핑) |
Transform은 크게 행 단위와 데이터셋 단위로 나뉩니다.
행 단위 변환
- Cast/Type Conversion: 문자열을 날짜·숫자형으로 변환합니다. 잘못된 캐스팅은 런타임 에러로 이어지므로 Null 처리를 함께 정의해야 합니다.
- String Manipulation: 공백 제거, 대소문자 변환, 정규표현식 기반 패턴 추출.
데이터셋 단위 변환
- Filtering: 불필요한 레코드를 조기에 제거해서 이후 단계의 처리량을 줄입니다.
- Joining: 서로 다른 Dataset을 키 기준으로 결합합니다. 한쪽 데이터가 충분히 작다면 브로드캐스트 조인으로 셔플 비용을 줄일 수 있습니다.
- Aggregation: GROUP BY 기반 집계입니다. 분산 처리 환경에서는 파티셔닝 전략이 성능을 좌우합니다.
Pipeline Builder GUI는 이 정도 수준의 필터·조인·집계·타입 변환에 최적화되어 있습니다. 팀원 누구나 화면만 보고도 전체 흐름을 파악할 수 있다는 것이 가장 큰 강점입니다.
Code Repository — 복잡한 로직을 코드로 관리하기
GUI가 표현하기 어려운 지점, 예를 들어 조건이 여러 겹 겹치는 분기 로직이나 여러 파이프라인에서 반복해서 쓰는 함수는 Code Repository에서 Python(PySpark)이나 SQL 코드로 직접 작성합니다. 핵심은 “Everything as Code” 사고방식입니다 — 로직 자체를 코드로 정의하면 변경 이력 추적, 코드 리뷰(Pull Request), 자동화된 테스트, 문제가 생겼을 때의 롤백까지 전부 같은 Git 워크플로우 안에서 처리됩니다.
일반 GUI 파이프라인과 Code Repository 기반 관리의 차이는 다음과 같습니다.
| 항목 | GUI 기반(Pipeline Builder) | 코드 기반(Code Repository) |
|---|---|---|
| 변경 이력 | 추적 어려움 | Git 커밋으로 전부 기록 |
| 재사용 | 각 파이프라인마다 다시 구성 | 함수·모듈로 만들어 여러 곳에서 import |
| 검토 | 별도 승인 절차 없음 | Pull Request로 코드 리뷰 후 병합 |
| 복구 | 이전 상태로 되돌리기 어려움 | 이전 정상 커밋으로 즉시 롤백 |
Foundry의 Code Repository는 이 워크플로우를 플랫폼 안에 내장하고 있어서, 별도의 외부 Git 서버 없이도 브랜치·PR·코드 리뷰가 그대로 동작합니다.
실무에서 쓰는 흐름
- 간단한 것은 Pipeline Builder로 먼저 만든다: 필터·조인·집계 정도는 GUI로 빠르게 구성합니다.
- 복잡해지는 지점만 Code Repository로 분리한다: 조건 분기가 여러 겹이거나, 같은 로직을 다른 파이프라인에서도 써야 한다면 그 부분만 함수로 코드화합니다.
- Transform 함수 작성: PySpark 코드로 입력 Dataset을 받아 가공된 출력 Dataset을 반환하는 함수를 정의합니다.
- 빌드(Build) 실행: 작성한 코드를 실행해서 실제 Dataset을 생성·갱신합니다. 이 빌드 이력은 Data Lineage에 그대로 기록됩니다.
- Pull Request와 리뷰: 변경 사항을 병합하기 전, 동료가 코드 리뷰를 거칩니다.
- 머지 후 자동 반영: 병합되면 프로덕션 파이프라인에 반영됩니다. 이후 같은 Transform을 다시 실행해도 같은 입력에 같은 출력이 나오는지(멱등성)를 유지해야 합니다.
인접 개념과의 관계
Pipeline Builder와 Code Repository로 만들어진 결과물은 결국 Dataset입니다. 이 Dataset이 Ontology Manager에서 Object Type으로 매핑되어야 비로소 온톨로지의 일부가 됩니다. 또한 파이프라인이 복잡해질수록 “이 Dataset이 어디서 왔는지” 추적하는 일이 중요해지는데, 이는 별도 도구인 Data Lineage의 영역입니다.
자주 하는 실수
- GUI로 될 일을 굳이 코드로 짜기: 단순한 필터·조인 정도는 GUI가 더 빠르고, 나중에 다른 팀원이 유지보수하기도 쉽습니다. Code Repository는 GUI로 표현하기 어려운 복잡한 조건 분기나 재사용 가능한 로직에 쓰는 것이 맞습니다.
- 한 Transform에 로직을 다 몰아넣기: Filter → Project → Aggregate → Join을 하나의 거대한 Transform으로 처리하면, 중간에 문제가 생겼을 때 어느 단계에서 잘못됐는지 추적하기 어렵습니다. 단계를 모듈 단위로 쪼개면 디버깅과 재사용이 쉬워집니다.
- PR 없이 바로 메인 브랜치에 커밋하기: 코드 기반 관리의 핵심 이점은 리뷰 과정에서 실수를 걸러내는 것입니다. 이 과정을 생략하면 일반 GUI 파이프라인과 다를 바 없어집니다.
- 스키마 변화를 가정하지 않기: 원천 데이터의 컬럼이 추가되거나 타입이 바뀌는 일은 실무에서 흔합니다. 스키마 검증 없이 파이프라인을 짜면, 원천이 바뀔 때마다 다운스트림이 조용히 깨지거나 잘못된 값을 흘려보냅니다.
- 멱등성을 신경 쓰지 않기: 같은 로직을 두 번 실행했을 때 결과가 달라진다면(예: 매번 append만 하는 로직), 재실행이나 재처리 상황에서 데이터가 중복되거나 꼬입니다.
다음으로 읽을 글
파이프라인이 만든 Dataset을 온톨로지로 매핑하는 절차는 Ontology Manager 실전 가이드에서, 이 데이터가 어떤 경로를 거쳐왔는지 추적하는 방법은 Data Lineage에서 이어서 다룹니다.
자주 묻는 질문
Q. Pipeline Builder와 Code Repository 중 뭘 먼저 배워야 하나요?
간단한 변환 작업이 많다면 Pipeline Builder부터 익히는 것이 빠릅니다. 로직이 복잡해지거나 여러 명이 코드를 함께 관리해야 하는 상황이 오면 Code Repository로 전환하는 경우가 많습니다.
Q. 두 도구를 섞어서 써도 되나요?
네. 같은 파이프라인 안에서 일부는 Pipeline Builder로, 복잡한 부분만 Code Repository로 작성해 연결하는 방식이 실무에서 흔히 쓰입니다.
Q. Code Repository는 어떤 언어를 지원하나요?
Python, SQL, Java 등 여러 언어를 지원하며, 팀의 기존 코드 자산과 스킬셋에 맞춰 선택할 수 있습니다.
Q. 파이프라인 결과가 온톨로지에 바로 반영되나요?
파이프라인이 만든 Dataset을 Ontology Manager에서 Object Type에 매핑해야 온톨로지에 반영됩니다. 파이프라인 자체가 온톨로지를 자동으로 갱신하지는 않습니다.
Q. 자주 하는 실수는 무엇인가요?
처음부터 모든 로직을 Code Repository로 짜서 유지보수 부담을 키우는 경우가 많습니다. 간단한 변환은 Pipeline Builder로 남겨두고 복잡한 부분만 코드로 옮기는 것이 유지보수에 유리합니다.