파이프라인의 프로젝트 경계와 담당 역할

프로젝트는 관련 데이터와 코드를 모으고 팀의 접근 권한을 관리하는 단위입니다. 활동 이력, 프로젝트 문서, 리소스 사용량과 연산 지표도 프로젝트에서 관리합니다. 프로젝트의 목적, 하위 팀에 제공하는 출력과 변경 책임을 분명하게 나누면 권한과 유지보수 범위를 함께 정리할 수 있습니다.

프로젝트를 나누는 기준

Code Repositories 중심으로 개발한다면 프로젝트와 코드 저장소를 일대일로 두는 구성이 권장됩니다. 범위를 넓히면 협업 가능한 작업이 많아지지만 버전 관리와 운영 조율도 어려워집니다. 서로 조율할 수 있는 규모의 담당 팀이 프로젝트의 규약을 정하고 출력 계약을 유지하도록 구성합니다.

파일 구조와 접근 권한을 함께 적용할 리소스를 한 프로젝트에 묶습니다. 같은 업무에 속해도 하위 구성요소마다 권한이 달라야 한다면 여러 프로젝트로 나누는 방안을 검토합니다.

수집부터 업무 활용까지

각 단계는 하위 프로젝트가 가져가서 사용할 출력을 제공하는 독립적인 관리 단위입니다. 담당 팀은 변환뿐 아니라 출력의 빌드 스케줄, 상태 검사와 필요한 단위 테스트 및 데이터 무결성 검사도 관리합니다. 설계할 때는 온톨로지에 필요한 업무 객체에서 거꾸로 출발하여 필요한 원천과 변환을 결정하는 편이 좋습니다.

Data Connection과 원천 연결

Data Connection에 소스 시스템을 등록하고 하나 이상의 동기화를 구성하면 원천 프로젝트의 raw 데이터셋으로 데이터가 들어옵니다. 새 연결은 Foundry 워커를 권장하며, 사설망 경유가 필요하면 해당 네트워크에 맞는 직접 연결, 프라이빗 링크 또는 에이전트 프록시를 구성합니다. 에이전트 워커는 Legacy 실행 방식이므로 모든 새 연결에 에이전트를 설치하는 것을 기본 절차로 삼지 않습니다.

에이전트를 사용하는 경우에는 에이전트 관리자가 설치 및 구성을 담당하고, 관리자를 위한 별도 프로젝트에 에이전트 리소스를 보관하여 접근을 제한합니다. 원천 소유자, 연결 담당 개발자와 관리자가 초기 연결을 함께 준비합니다. 데이터의 환경 간 이동에 승인이 필요한 경우에는 준법 또는 법무 담당자도 참여합니다.

연결을 구성한 뒤에는 원천 개발자가 개별 동기화를 독립적으로 추가할 수 있도록 테이블과 파일을 미리 볼 권한을 준비합니다. 매번 관계 팀에 새 연결 설치를 요청하는 구조보다 원천별 연결과 개별 동기화 책임을 구분하는 편이 운영하기 쉽습니다.

수집 방식에서 SNAPSHOT은 현재 데이터를 새 데이터로 대체하고 APPEND는 기존 데이터에 누적합니다. 이 선택은 하위 증분 파이프라인의 입력 처리 방식과 비용에 영향을 줍니다. 실제 연결 설정은 Data Connection에서 다룹니다.

원천 프로젝트

논리적인 원천 시스템마다 대응하는 프로젝트를 둡니다. 원시 데이터를 가능한 한 원천 형태에 가깝게 수집한 뒤, 프로젝트의 변환에서 정리된 데이터셋을 만듭니다.

이 구조는 새 데이터를 찾는 위치와 접근 통제 지점을 모으고, 서로 다른 팀이 같은 데이터를 중복 수집할 가능성을 줄입니다. 저장소도 원천의 형식과 자료형에 맞춘 작은 범위로 유지할 수 있습니다. 공유하기 전에 민감한 필드를 제거하거나 적절히 비식별 처리하고 값을 표준화할 수 있습니다.

정리된 출력의 계약

출력 데이터셋과 스키마는 다른 팀이 사용하는 데이터 인터페이스입니다. 원천의 테이블 또는 파일과 일대일로 대응하도록 구성하고, 출력 행은 원천 행으로 직접 추적할 수 있어야 합니다. 원천 프로젝트에서 업무별 집계와 결합을 늘리기보다 공통으로 사용할 수 있는 정리 작업에 집중합니다.

• 열 이름 규칙을 통일합니다.
• 열에 적절한 자료형을 명시합니다.
• 누락, 잘못된 형식과 자료형 오류를 처리합니다.
• 기본 상태 검사를 구성합니다.
• 일반적인 공유에 적합하지 않은 개인정보와 민감한 필드를 제거합니다.

민감한 필드는 공유 범위가 커지기 전에 식별하는 편이 좋습니다. Sensitive Data Scanner로 발견 작업을 지원하고, 필요한 데이터만 남기는 최소화와 값의 노출을 줄이는 처리를 설계에 반영할 수 있습니다.

원천이 자료형을 제공해도 날짜, 일시와 숫자의 형식이 일정하지 않다면 먼저 STRING으로 수집할 수 있습니다. 특히 DATE, DATETIME, TIMESTAMP는 원천별 비표준 표현에 주의합니다. 이후 명시적으로 파싱하고 잘못된 값, 사용 불가능한 행 또는 중복 행을 어떻게 처리하는지 정합니다.

출력에는 데이터의 의미, 원천 시스템, 담당 연락처, 관리 절차와 필요한 열별 메타데이터를 기록합니다. 비슷한 원천에서 같은 파싱과 오류 처리 로직이 반복되면 공유 Python 라이브러리로 일관되게 관리할 수 있습니다.

구성 절차

1. 관리자가 원천 프로젝트와 해당 원천 개발자 그룹을 만듭니다. 프로젝트에서 데이터셋을 빌드하는 권한은 해당 개발자 그룹으로 제한합니다.
2. 원천 소유자와 연결 관리자가 네트워크 및 인증을 준비합니다. 에이전트가 필요한 연결에는 에이전트 관리자가 참여합니다. 개발자가 필요한 테이블과 파일을 미리 볼 수 있게 설정합니다.
3. 개발자가 수집 주기와 쓰기 방식을 정해 원시 데이터셋 동기화를 만들고 상태 검사를 추가합니다.
4. 정리 변환을 작성하여 하위 프로젝트에서 사용할 출력을 만듭니다.
5. 새 원천 데이터 요청, 출력 개선과 품질 문제는 프로젝트 또는 정리된 데이터셋의 Issue로 접수합니다.

권장 폴더

공통 변환 프로젝트

Transform project는 관련 있는 데이터를 결합하여 여러 업무가 재사용할 수 있는 결과를 만듭니다. 정리된 원천에 조회용 데이터를 조인하여 값을 확장하거나, 관계를 정규화 및 비정규화하여 객체 중심 또는 시간 중심 데이터셋을 만들거나, 공통 지표를 집계합니다.

하위 프로젝트가 중간 결과에 직접 의존하면 내부 구현 변경이 곧 외부 영향으로 이어집니다. 안정적인 출력은 /data/output에 모으고 그 경계를 유지합니다.

온톨로지 프로젝트

Ontology project는 하나 또는 관련된 여러 업무 객체의 정의에 맞는 최종 데이터셋을 만듭니다. 관련 업무 도메인의 객체를 한 프로젝트에서 관리할 수 있습니다. Object Explorer 조회를 지원하는 데이터셋과 동기화도 필요한 범위에서 함께 관리합니다.

하위 업무는 이 계층의 공통 객체 정의를 사용하며, 원천 정리와 중간 변환을 직접 알아야만 사용할 수 있는 구조를 피합니다. 상위 계보는 확인할 수 있지만 온톨로지 출력이 업무 객체에 대한 안정적인 인터페이스가 됩니다.

문서, 의미 있는 상태 검사, 정기 스케줄과 Data Catalog의 정리 및 태그를 유지합니다. 여러 팀이 변경할수록 출력 스키마를 보존하는 검사가 중요합니다.

업무 프로젝트

Workflow project 또는 use case project는 특정 업무 결과와 협업 팀을 중심으로 구성합니다. 업무 절차, BI 분석, 모델 개발과 애플리케이션이 같은 객체 의미를 사용하도록 온톨로지 프로젝트의 데이터를 참조하는 것이 권장됩니다.

필요한 데이터가 온톨로지에 없다면 공통 계층을 보강하는 방안을 검토합니다. 원천이나 다른 업무의 중간 데이터에 임의로 의존하면 같은 업무 개체를 서로 다르게 해석하기 쉽습니다.

프로젝트 문서 배치

주요 데이터셋과 관계를 보여 주는 Data Lineage 그래프를 프로젝트 루트에 저장합니다. 갱신 주기, 관련 데이터 묶음 또는 크기 등 서로 다른 관점의 그래프를 둘 수 있습니다.

프로젝트 제목 아래의 짧은 설명은 전체 프로젝트 목록에도 표시되므로 프로젝트를 모르는 사람이 목적을 파악할 수 있게 작성합니다. 최상위 폴더 오른쪽의 Add Documentation에서 Markdown으로 목적, 주요 출력과 이용 조건을 설명합니다. 긴 문서는 Documentation 폴더에 올린 Markdown 파일이나 Notepad에 두고 최상위 문서에서 연결합니다.

코드 저장소에는 README.md를 두고 각 변환 파일의 역할과 중요한 결정 이유를 설명합니다.

담당 역할

다음은 팀의 책임을 나누는 역할 예시이며 Foundry의 권한 역할 이름과 일대일로 대응하는 목록은 아닙니다. 초기에는 한 사람이 여러 역할을 맡거나 일부 역할을 별도로 두지 않을 수 있습니다.