• 목록

데이터 처리에서 배치와 스트림을 구분할 때 한 번에 많이 처리하느냐 한 건씩 처리하느냐만 떠올리면 실제 시스템을 이해하기 어렵습니다. 데이터 범위가 끝나는지, 결과를 언제 내야 하는지, 늦게 도착한 데이터를 어떻게 반영하는지도 중요합니다.

같은 서비스 안에서 두 방식이 함께 사용될 수 있습니다. Apache Beam의 기본 개념을 참고해 처리 대상과 시간의 의미를 입문 수준으로 정리합니다.

AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.

핵심 정리
배치는 정해진 범위의 데이터를 묶어 처리하는 관점이고 스트림은 계속 도착하는 데이터를 다루는 관점입니다. 도착 순서와 발생 시각, 결과 갱신 기준을 구분해야 처리 결과를 설명할 수 있습니다.

1. 데이터 범위가 끝나는지를 먼저 봅니다

어제 하루의 주문 파일처럼 처리 대상이 정해진 데이터와 앞으로 계속 들어오는 주문 이벤트는 범위의 끝이 다릅니다. Apache Beam은 이를 설명할 때 bounded와 unbounded라는 개념을 사용합니다.

배치와 스트림을 이해할 때도 이런 범위 구분이 도움이 됩니다. 가상의 보고서 작업에서 특정 날짜의 파일을 읽고 끝내는 처리와 새 이벤트를 계속 받아 합계를 갱신하는 처리는 완료 조건이 다릅니다.

파일을 읽는다고 언제나 배치만 가능한지, 작은 묶음으로 처리한다고 스트림이 아닌지는 구현과 모델에 따라 더 살펴야 합니다. 화면에서 한 건씩 보이는 모습보다 데이터의 범위와 결과를 내는 조건을 먼저 설명하는 편이 정확합니다.

2. 처리 속도와 처리 방식을 같은 뜻으로 쓰지 않습니다

스트림이라는 이름이 붙었다고 모든 결과가 즉시 확정되는 것은 아닙니다. 입력과 전달, 계산과 저장에 시간이 들며 일부 결과는 일정 구간을 모아야 의미가 있습니다.

반대로 배치도 작은 범위를 자주 처리하면 짧은 간격으로 결과를 제공할 수 있습니다. 가상의 요구 사항이 매일 아침 전날 합계를 받는 것인지 주문 후 가까운 시점에 상태를 보고 싶은 것인지 먼저 구분합니다.

필요한 지연 수준과 결과의 완전성, 운영 비용을 함께 생각해야 합니다. 빠른 방식이라는 인상만으로 스트림을 선택하면 늦은 데이터와 상태 관리 문제를 놓칠 수 있습니다.

방식의 이름보다 서비스가 기대하는 결과 시점을 문장으로 적어 봅니다.

3. 발생 시각과 처리 시각은 다를 수 있습니다

사용자의 행동이 실제 발생한 시각과 서버가 그 이벤트를 받은 시각, 계산에 반영한 시각은 같지 않을 수 있습니다. 가상의 모바일 앱에서 연결이 늦게 복구되어 이전 이벤트를 나중에 보내는 경우를 생각할 수 있습니다.

이벤트 발생 시각 기준으로 집계할지 처리 시각 기준으로 집계할지에 따라 어느 시간 구간에 포함되는지가 달라집니다. Apache Beam의 설명도 event time과 processing time을 구분합니다.

입문 실습에서는 이벤트마다 두 시각을 따로 적어 같은 데이터가 어떤 기준으로 묶이는지 비교하면 도움이 됩니다. 하나의 timestamp라는 이름만 남기면 그 값이 무엇을 의미하는지 모호해지므로 데이터 정의에 시각의 기준을 명시합니다.

4. 계속 들어오는 데이터를 구간으로 나눌 수 있습니다

끝없이 도착하는 데이터를 대상으로 합계나 평균을 계산하려면 일정한 범위를 정해 결과를 볼 수 있습니다. 시간 창을 사용해 구간별로 묶는 방식이 한 예입니다.

가상의 실습에서는 10분 단위 발생 시각으로 이벤트를 나누고 각 구간의 건수를 계산할 수 있습니다. 이 숫자는 운영 권장값이 아니라 경계를 이해하기 위한 예시입니다.

경계에 정확히 걸린 이벤트를 어느 구간에 넣는지 규칙도 정해야 합니다. 같은 이벤트가 여러 구간에 들어갈 수 있는 방식도 있으므로 선택한 창의 의미를 설명합니다.

창을 만들었다는 사실만으로 늦게 도착한 이벤트의 처리가 자동으로 해결되는 것은 아니며 갱신 정책을 함께 정해야 합니다.

5. 늦게 도착한 데이터는 결과 갱신 정책과 연결됩니다

이미 화면에 보여 준 집계 구간에 과거 이벤트가 추가로 들어오면 어떻게 할지 결정해야 합니다. 결과를 수정할지, 별도 보정 자료로 남길지, 어느 범위까지 늦은 데이터를 반영할지 서비스 요구를 확인합니다.

Beam의 워터마크는 이벤트 시간 진행을 추정하는 개념이며 모든 과거 데이터가 확실히 도착했다는 절대 보장으로 이해하면 안 됩니다. 가상의 대시보드에는 임시 집계와 후속 갱신 가능성을 구분해 표시할 수 있습니다.

사용자가 확정된 보고서로 활용하는 데이터라면 확정 기준도 필요합니다. 개발자는 빠르게 값을 내는 일과 완전한 값으로 확정하는 일이 다른 시점일 수 있다는 점을 문서에 남겨야 합니다.

6. 중복과 재처리는 업무 결과의 관점에서 봅니다

입력 전달이나 작업 복구 과정에서 같은 이벤트를 다시 처리할 가능성을 어떻게 다룰지 정합니다. 도구가 제공하는 처리 보장과 외부 저장소에 실제로 반영되는 결과의 조건을 구분해야 합니다.

가상의 주문 집계에서는 이벤트 식별자를 활용할지, 결과를 덮어쓸지, 중복을 어떤 범위에서 확인할지 생각할 수 있습니다. 특정 프레임워크의 기능 이름만으로 전체 업무에서 중복이 없다고 단정하지 않습니다.

재실행할 수 있는 배치 작업도 같은 문제가 생길 수 있습니다. 테스트에는 동일 이벤트가 두 번 들어오는 경우와 중간 실패 후 다시 시작하는 경우를 넣어 기대 결과가 유지되는지 확인할 수 있습니다.

이 문제는 속도보다 결과의 의미와 관련됩니다.

7. 두 방식을 함께 사용하는 흐름도 가능합니다

가상의 서비스에서 최근 상태는 스트림으로 보여 주고 일정 시점에 범위가 정해진 자료로 다시 집계해 보고서를 만들 수 있습니다. 이렇게 구성한다고 항상 더 좋은 것은 아니며 두 결과가 어떤 기준으로 다른지 설명할 수 있어야 합니다.

입력 범위와 시간 기준, 수정 정책이 다르면 같은 날짜의 숫자가 잠시 다르게 보일 수 있습니다. 사용자가 어느 값을 어떤 목적으로 사용할지 정하고 결과의 관계를 문서화합니다.

배치 결과가 반드시 정답이고 스트림 결과는 항상 부정확하다고 일반화하지 않습니다. 실제 데이터와 계산 규칙이 품질을 결정하므로 두 방식의 역할을 명확히 나누고 비교 가능한 조건을 맞추는 것이 중요합니다.

8. 작은 이벤트 표로 시간과 결과를 직접 따라갑니다

학습용 표에 이벤트 번호, 발생 시각, 도착 시각, 값의 네 칸을 만듭니다. 먼저 발생 순서대로 계산하고 다음에는 일부 이벤트를 늦게 도착시키거나 중복해서 넣어 봅니다.

같은 시간 창에 들어가는 이벤트와 결과가 바뀌는 시점을 적으면 코드 없이도 핵심 문제를 이해할 수 있습니다. 이후 도구를 사용할 때는 이런 규칙이 어느 설정에 대응하는지 공식 문서에서 확인합니다.

단순한 예시를 실제 처리 보장의 검증으로 확대하지 않고 학습한 범위를 명시합니다. 배치와 스트림의 차이는 데이터를 몇 건씩 읽는지보다 범위와 시간, 결과 갱신을 어떻게 정의하는지에서 분명해집니다.

9. 자주 묻는 질문

Q1. 스트림 처리는 항상 한 건씩 실행하나요?

내부 실행 방식은 도구와 구현에 따라 다를 수 있습니다. 계속 도착하는 데이터를 다룬다는 모델과 실제로 묶어 실행하는 단위를 구분해야 합니다.

처리 방식의 이름만으로 내부 동작을 단정하지 않습니다.

Q2. 스트림 결과는 바로 확정된 값인가요?

늦은 데이터와 갱신 정책에 따라 달라집니다. 빠르게 제공한 결과와 최종 확정 기준을 구분할 필요가 있습니다.

사용자가 어떤 상태의 값을 보고 있는지 설명해야 합니다.

Q3. 워터마크가 지나면 과거 데이터는 절대 안 오나요?

그렇게 보장하는 의미로 이해하면 안 됩니다. 워터마크는 이벤트 시간 진행을 추정하는 데 사용됩니다.

늦게 온 데이터의 처리 조건은 별도로 정합니다.

Q4. 배치와 스트림 중 하나만 골라야 하나요?

같은 서비스에서 서로 다른 역할로 함께 사용할 수 있습니다. 다만 시간 기준과 입력 범위, 결과 갱신 방식의 관계를 명확히 해야 합니다.

도구보다 필요한 결과와 지연 조건을 먼저 정합니다.

참고 자료

• Apache Beam: 데이터 범위와 시간 모델
• Apache Beam: 용어 설명