데이터 원천·유형과 수집 방식

핵심 요약

데이터 원천은 조직 내부와 외부로 나눌 수 있고, 데이터 형식은 정형·반정형·비정형으로 나눌 수 있다. 내부 데이터라고 모두 정형인 것도 아니며 외부 데이터라고 모두 비정형인 것도 아니다. 분류 축을 섞지 않아야 적절한 수집·저장·분석 방법을 선택할 수 있다.

수집은 데이터를 한 번 복사하는 행위가 아니다. 원천의 의미와 기준 시점, 변경·삭제, 중복·유실, 출처와 권한을 추적할 수 있어야 이후 분석을 재현할 수 있다. 재시도와 재처리 후에도 같은 원천 변화가 결과에 중복 반영되지 않도록 식별자·기준점·멱등성 규칙을 설계해야 한다.

학습 목표

• 내부·외부 데이터와 정형·반정형·비정형 데이터를 구분한다.
• 배치·스트림, 밀어넣기·가져오기 방식의 적용 조건을 설명한다.
• 파일·API·데이터베이스·로그 수집의 장단점을 판정한다.
• 출처·기준 시점·수집 실패를 포함한 수집 품질을 검증한다.
• 전체·증분·변경 데이터 수집과 스키마 변경 대응을 판정한다.

1. 데이터 원천과 형식

1.1 내부·외부 데이터

내부 데이터는 조직의 거래, 고객 접점, 설비, 인사, 회계 시스템 등에서 생성된다. 업무 의미와 책임자를 확인하기 쉽지만 시스템별 코드와 기준 시점이 다를 수 있다. 외부 데이터는 공공데이터, 제휴사, 시장·날씨 정보 등에서 얻으며 라이선스, 제공 안정성, 갱신 주기와 정의 변경을 확인해야 한다.

1.2 정형·반정형·비정형

CSV는 흔히 정형 교환 파일로 쓰이지만 구분자, 인코딩, 헤더와 자료형 제약이 파일 자체에 충분히 표현되지 않을 수 있다. 형식 이름만으로 품질을 단정하지 않는다.

2. 수집 시점과 흐름

2.1 배치 수집

일정 주기마다 파일이나 변경분을 모아 가져온다. 구현과 재처리가 비교적 단순하지만 최신성은 주기에 제한된다. 전체 추출과 증분 추출을 구분하고 마지막 성공 기준점을 관리해야 한다.

2.2 스트림 수집

이벤트가 발생할 때 연속적으로 전달한다. 짧은 지연시간에 적합하지만 중복, 순서, 늦게 도착한 이벤트, 재처리와 상태 관리가 중요하다.

2.3 밀어넣기와 가져오기

원천이 이벤트를 보내는 방식은 밀어넣기, 수집 시스템이 주기적으로 조회하는 방식은 가져오기로 볼 수 있다. 전자는 변화에 빠르게 반응할 수 있고, 후자는 수집 주체가 일정과 부하를 통제하기 쉽다.

배치와 스트림은 배타적이지 않다. 실시간 경보는 스트림으로 제공하고 일별 배치 재계산으로 누락·지연 이벤트를 반영해 확정 결과를 만들 수 있다.

2.4 전체·증분·변경 데이터 수집

증분 수집에서 수정 시각 > 마지막 시각만 사용하면 같은 시각의 레코드나 늦게 반영된 변경을 놓칠 수 있다. 시간과 고유 순번을 함께 쓰거나 일정 겹침 구간을 재조회한 뒤 식별자로 중복을 제거하는 방안을 검토한다. 삭제는 현재 테이블 조회만으로 사라진 사실을 알기 어려울 수 있으므로 삭제 표시, 변경 로그, 주기적 전체 대사 같은 절차가 필요하다.

3. 대표 수집 방식

수집 방식은 하나만 선택하지 않을 수 있다. 기준 정보는 API로, 대량 이력은 파일로, 실시간 상태는 이벤트로 받을 수 있다.

3.1 API와 파일 수집의 완료 판단

4. 수집 품질과 계보

수집 레코드에는 가능하면 원천, 원천 식별자, 발생 시각, 수집 시각, 스키마 버전, 배치 또는 이벤트 ID를 남긴다. 이를 통해 중복 제거, 지연 분석, 재처리와 계보 추적이 가능해진다.

수집 성공률은 받은 건수만으로 판단하지 않는다. 원천 예상 건수, 누락 구간, 체크섬, 마지막 변경 시점, 오류 응답을 함께 확인한다. 시간이 다른 시스템을 결합할 때는 표준 시간대와 발생 시각·처리 시각을 구분한다.

4.1 공통 수집 메타데이터

4.2 스키마 변경과 데이터 계약

원천 필드가 추가·삭제되거나 자료형·코드 의미가 바뀌면 수집은 성공해도 분석 결과가 잘못될 수 있다. 데이터 계약에는 필드 의미·자료형·필수 여부·시간대·허용 코드·변경 통지·호환성 원칙을 정할 수 있다.

스키마 변경을 자동으로 모두 허용하거나 모두 거부하지 않는다. 하위 호환 여부와 업무 영향에 따라 수용·격리·차단 기준을 정한다.

4.3 수집 품질 대사

5. 사례 적용

상황: 관광 수요를 예측하기 위해 예약 데이터, 날씨 API, 후기 텍스트와 실시간 입장 이벤트를 모은다.

주어진 조건: 예약은 내부 정형 테이블, 날씨는 외부 반정형 응답, 후기는 비정형 텍스트, 입장 기록은 연속 이벤트다.

판단 과정: 각 원천의 출처·구조·갱신 주기·허용 지연을 별도로 정의한다. 예약은 수정 시각과 예약 ID를 기준으로 겹침 구간을 둔 증분 조회를 수행하고 취소·삭제 반영을 대사한다. 날씨는 호출 시각·예보 생성 시각·대상 시각과 API 버전을 저장하고 모든 페이지·지역의 완료 여부를 검증한다. 후기는 이용 조건을 확인한 배치 수집으로 출처·게시 시각·수집 시각을 남긴다. 입장은 고유 이벤트 ID와 발생·수집 시각, 체크포인트를 사용해 재전송에도 중복 반영되지 않도록 처리한다.

결론: 하나의 수집 기술로 통일하기보다 원천별 특성에 맞추고, 공통 메타데이터·스키마 버전·원천 대사·재처리 기준으로 통합한다. 실시간 입장 집계는 이후 배치 재대사로 누락·지연 이벤트를 보정할 수 있다.

오답 함정: 외부 API 응답을 언제나 정확한 사실로 보거나, 실시간 이벤트의 수신 시각을 실제 발생 시각과 같은 것으로 가정하지 않는다.

내부·외부는 데이터 원천의 축이고 정형·반정형·비정형은 형식의 축이다. 예를 들어 외부 API의 JSON은 원천 기준으로 외부, 형식 기준으로 반정형이므로 두 축을 같은 분류 목록처럼 섞지 않는다.

수집 방식은 “최신 기술”이 아니라 지연 요구·원천 지원·변경 식별·재처리·비용으로 선택한다. 수집 대상 건수를 $N_{expected}$, 정상 수집 건수를 $N_{received}$라 하면 대사율은 분모와 기간을 명시해 계산한다.

시험 판단 포인트

• 내부·외부는 출처 축, 정형·반정형·비정형은 구조 축이다.
• 배치 수집은 주기적 묶음, 스트림 수집은 연속 이벤트에 적합하다.
• API는 호출 제한·버전·페이지 처리, 파일은 중복·부분 전송·스키마 변경을 점검한다.
• 발생 시각과 수집 시각, 전체 추출과 증분 추출을 구분한다.
• 수집 데이터에는 출처·스키마·배치 식별자 등 계보 정보를 남긴다.
• 배치·스트림과 push·pull, 전체·증분·변경 데이터 수집은 서로 다른 설계 축이다.
• 증분 기준점과 삭제 반영, 스키마·코드 의미 변경을 함께 관리한다.

자주 틀리는 부분

• 내부 데이터이면 품질과 권한 문제가 없다고 보지 않는다.
• JSON이라는 이유만으로 비정형 데이터로 분류하지 않는다.
• 스트림 수집에서는 중복이 발생하지 않는다고 가정하지 않는다.
• 공개 웹페이지의 데이터가 사용 조건과 법적 검토 없이 자유롭게 수집 가능하다고 판단하지 않는다.
• API가 HTTP 성공을 반환했다는 사실만으로 모든 페이지가 수집됐다고 보지 않는다.
• 정확히 한 번 처리된다는 표현만 믿고 식별자·체크포인트·멱등성 설계를 생략하지 않는다.