데이터 온보딩(data onboarding)은 새 출처나 새 고객의 데이터가 들어올 때 시작해, 그 데이터를 원래 목적한 업무에 쓸 수 있을 때 끝납니다. 단계는 대체로 같습니다. 출처에 연결하고, 필드를 받는 시스템이 기대하는 이름과 유형에 매핑하고, 공백, 중복, 일관되지 않은 형식을 확인하고, 각 필드의 의미와 예외 레코드를 담당자와 확인합니다. 광고 분야에서는 같은 용어를 오프라인 고객 레코드와 온라인 식별자를 매칭한다는 더 좁은 뜻으로 씁니다. 이 항목은 일반적인 경우를 다룹니다.
AI 업무에서 데이터 적재는 중간 지점입니다. 온보딩은 데이터가 쓰일 Use Case 기준으로 확인을 마쳤을 때 끝납니다. 모델에 필요한 필드가 있고, 그 의미가 확인됐고, 이 데이터로 낸 결과를 알려진 기준선과 비교할 수 있어야 합니다. 지금은 이 작업의 상당 부분을 사람이 직접 하며, 대개 forward deployed engineer가 맡고, 고객마다 반복합니다. 매핑, 준비 규칙, 승인 기준을 재사용 가능한 자산으로 기록하면, 온보딩은 매번 새로 하는 프로젝트가 아니라 AI-ready data로 가는 반복 가능한 단계가 됩니다.
데이터 온보딩은 데이터 준비와 어떻게 다른가요?
온보딩은 출처를 들여오고 그 안에 무엇이 있는지 확인합니다. 연결, 필드 매핑, 첫 품질 검사, 각 필드의 의미에 대한 담당자 확인이 여기에 속합니다. 데이터 준비는 그다음에 시작하며 하나의 Use Case에 맞춰 진행합니다. 업무가 의존하는 필드를 고르고, 단위와 코드를 변환하고, 예외를 처리하고, 결과가 업무 요구에 맞는지 확인합니다.
- 온보딩: 출처나 고객마다 한 번 하며, 데이터를 이해했을 때 끝납니다.
- 준비: Use Case마다 한 번 하며, 데이터가 업무에 맞을 때 끝납니다.
- 같은 출처, 다른 준비: 같은 고객 테이블이라도 이탈 예측 모델과 채권 회수 워크플로에는 서로 다른 필드, 단위, 예외가 필요합니다.
두 번째 단계는 AI 데이터 준비는 업무에서 시작합니다에서 다룹니다.
AI 업무에서 데이터 온보딩은 어디서 문제가 되나요?
새 고객의 추출 파일을 월요일에 적재하고, 화요일에 모델을 실행하고, 금요일에 첫 검토 회의를 엽니다. 숫자는 그럴듯해 보이는데, 바로 그 점이 문제입니다. 비교할 대상이 없기 때문입니다. 합의한 기준선이 없고, 두 필드는 이름만 보고 매핑했으며, 고객이 예외로 취급하는 레코드 목록은 요청한 적조차 없습니다.
적재는 중간 지점입니다. 결과를 쓸 수 있게 하려면 마지막 확인이 필요합니다. 각 필드의 의미를 담당자와 확인하고, 첫 실행 전에 통과 기준을 합의하고, 매핑과 규칙을 기록해 다음 출처가 거기서 시작하게 합니다. Syntitan은 이 기록을 Project의 Version으로 남기므로, 온보딩은 고객마다 처음부터 다시 하는 프로젝트가 아니라 반복 가능한 단계가 됩니다.