엔지니어 워크플로 개요

분석가는 이미 있는 데이터 위에 화면을 그립니다. 엔지니어는 그 데이터가 어떻게 거기 있게 되는지를 책임집니다. 포털에서 그 책임은 네 표면에 나뉘고, 끝점은 늘 데이터셋 한 종류로 모입니다.

엔지니어가 자주 머무는 네 표면

1. 커넥터(Connectors) — DB·S3·REST API·이벤트 스트림 같은 외부 시스템과 포털을 잇는 입구. 인증, 호스트, 스키마 매핑이 여기서 정의됩니다.
2. 파이프라인(Pipelines) — 노드를 잇는 워크플로우 편집기. 가져오기(source) → 변환(transform) → 적재(sink) 흐름의 표준 표현.
3. 코드(Codes) — Python 또는 SQL 스니펫. 파이프라인의 변환 노드에서 호출되거나 단독으로 실행되는 단위.
4. 데이터셋(Datasets) — 위 세 표면의 결과가 적재되는 곳. 동시에 분석가 코스의 입력.

네 표면의 끝점이 항상 데이터셋이라는 점이 핵심입니다. 엔지니어가 만든 데이터셋이 그대로 분석가의 컬렉션 트리에 떠서 위젯의 입력이 됩니다. 두 역할의 경계선이 곧 데이터셋.

익숙한 도구와의 대응 (1회만)

dbt·Airflow·Snowflake로 같은 흐름을 운영해 봤다면, 처음 30분만 다음 표를 머리에 두고 포털을 봐도 충분합니다. 02 레슨부터는 포털 어휘로만 갑니다.

기존 스택과 다른 점 두 가지만 미리.

• DAG와 모델이 한 캔버스에 같이 보입니다. Airflow의 task graph와 dbt의 모델 의존 그래프를 따로 운영하는 대신, 포털은 한 파이프라인 안에서 source·변환·sink 노드가 한 평면에 보입니다.
• 테이블은 데이터셋 하나로 통일됩니다. "source 테이블"과 "마트 테이블"의 구분은 컬렉션·권한·태그로 표현하고, 엔진 종류는 드러나지 않습니다.

이 매핑은 어느 표면을 먼저 열어야 하는지 판단을 빠르게 하려는 것이지, "포털이 dbt+Airflow의 1:1 대체"라는 주장은 아닙니다.

분석가와 엔지니어가 분담하는 일

같은 포털 안에서 두 역할이 부딪치지 않으려면 책임 분담을 합의해 둬야 합니다. 흔한 패턴.

조직 규모에 따라 한 사람이 두 역할을 겸하기도 합니다. 이 코스는 엔지니어가 어떤 표면에서 무엇을 책임지는지의 시점으로 모든 레슨을 갑니다.

이 레슨에서 익혀야 할 것

• 엔지니어의 네 표면 이름과 각각의 입력·출력
• 익숙한 도구(dbt·Airflow)와 포털 표면의 대응을 한 표로
• 분석가와의 책임 경계가 결국 데이터셋에서 만난다는 점

다음 레슨

첫 표면인 커넥터로 들어가 외부 시스템에 한 번 접속하고, 운영 데이터를 포털 데이터셋으로 떨어뜨려 봅니다.