'데이터플로 모델'을 다시 본다: 저자들이 스스로 매긴 11년 성적표

스트리밍 데이터 처리 분야에서 하나의 이정표로 꼽히는 논문이 있다. 11년 전 발표된 '데이터플로 모델(The Dataflow Model)'이다. 이 논문은 경계가 없고(unbounded) 순서가 뒤섞인(out-of-order) 데이터가 더 이상 예외가 아니라 새로운 표준이 되었다고 선언했다. 그러면서 데이터가 완결되기를 마냥 기다리는 관행을 멈춰야 한다고 주장했다. 배치와 스트리밍이라는 두 세계를 아우르는 통합 모델을 제시하며, 윈도잉(windowing), 트리거(triggers), 워터마크(watermarks), 리트랙션(retractions)이라는 개념을 통해 정확성·지연시간·비용을 자유롭게 맞바꿀 수 있게 하자는 것이 핵심이었다.

이 논문이 VLDB의 'Test of Time' 상을 받게 되면서, 저자들이 직접 자신의 작업을 되돌아보는 후속 글을 내놨다. 무엇이 잘 늙었고(aged well), 무엇이 잘못 늙었으며, 무엇을 놓쳤는지를 스스로 채점하는 형식이다. 흥미로운 것은 저자들이 이 논문을 이름과 달리 본질적으로는 '스트리밍 분석(streaming analytics)'에 관한 논문이었다고 재정의한다는 점이다. 자기 성취를 자랑하기보다 설계상의 오판을 구체적으로 인정하는 이런 회고는, 데이터 인프라를 다루는 실무자에게 오히려 더 실용적인 참고자료가 된다.

여전히 유효한 세 가지 토대

저자들이 잘 늙었다고 평가한 것은 세 가지 근본 전제다. 첫째, 데이터가 시스템에 도착한 시점이 아니라 실제로 발생한 시점, 즉 이벤트 시간(event time)을 처리의 중심에 두어야 한다는 원칙이다. 둘째, 데이터가 완전해지기를 기다리는 일은 부질없다(futility of waiting for completeness)는 통찰이다. 분산 환경에서 '모든 데이터가 도착했다'는 상태는 사실상 오지 않으며, 이를 전제로 시스템을 설계하면 안 된다는 것이다. 셋째, 강한 일관성(strong consistency)을 타협하지 않고 고수한 점이다. 이 세 가지는 오늘날 대규모 실시간 데이터 파이프라인을 설계할 때도 그대로 통용되는 기본기다.

잘못 늙은 분석 인터페이스

반면 저자들은 분석 인터페이스를 설계한 방식에서 중요한 부분을 틀렸다고 인정한다. 우선 윈도잉과 트리거링의 의미론(semantics)이 운영상의 관심사와 뒤엉킨 채, 필요 이상으로 논문의 서술을 지배하게 만든 점을 꼽는다. 개념적 모델과 시스템 운영의 세부가 분리되지 않은 채 뒤섞였다는 자기비판이다. 특히 트리거는 '과도하게 설계된(over-engineered)' 해법이었다고 평가한다. 사용자가 애초에 마주하지 말았어야 할 질문에 대해, 복잡한 메커니즘으로 답을 강요한 셈이라는 것이다.

가장 근본적인 반성은 세계관 자체에 있다. 논문은 스트림 중심(stream-centric)의 시각을 취했는데, 저자들은 이것이 더 깊은 진실을 놓쳤다고 말한다. 스트림과 테이블은 서로 다른 별개의 대상이 아니라, 같은 대상을 서로 다른 접근 의미론(access semantics)으로 표현한 두 가지 표상일 뿐이라는 것이다. 스트림을 특별한 무언가로 떼어놓고 바라본 프레임 자체가 불필요한 복잡성을 낳았다는 반성이다.

결국 데이터베이스의 방식으로

주목할 대목은 논문이 지향했던 분석 목표를 실제로 구현해낸 것이 무엇이었느냐다. 저자들에 따르면 그 성과를 실현한 메커니즘들은 결국 데이터베이스의 전통적 방식에서 나왔다. SQL, 증분 뷰 유지관리(incremental view maintenance), 그리고 명시적인 신선도 계약(freshness contracts)을 갖춘 구체화 뷰(materialized views)가 그것이다. 스트리밍만의 새로운 기계장치를 정교하게 다듬는 데 지나치게 몰두한 나머지, 이미 데이터베이스 진영이 축적해온 검증된 도구들이 답에 더 가까웠다는 사실을 놓쳤다는 자기평가다.

한국의 데이터 엔지니어와 플랫폼 실무자에게 이 회고가 주는 함의는 분명하다. 스트리밍 시스템을 도입할 때 '스트리밍은 근본적으로 다른 패러다임'이라는 전제에 갇히기보다, 스트림과 테이블을 하나의 대상에 대한 두 시선으로 다루는 관점이 실무적으로 더 견고할 수 있다는 것이다. 이벤트 시간을 기준으로 삼고 완결성에 의존하지 않으며 일관성을 지킨다는 원칙은 그대로 가져가되, 사용자에게 트리거 같은 저수준 운영 개념을 노출하기보다 SQL과 구체화 뷰, 신선도 계약처럼 익숙하고 선언적인 인터페이스로 문제를 감싸는 방향이 검토할 가치가 있다.

다만 이 글은 어디까지나 원저자들의 사후 회고라는 한계를 지닌다. 어떤 구체적인 벤치마크나 새로운 실험 결과가 아니라, 11년의 산업 흐름을 지켜본 뒤의 관점 정리에 가깝다. 따라서 '스트리밍 전용 추상화보다 데이터베이스 계보의 도구가 낫다'는 결론을 자신의 워크로드에 그대로 이식하기 전에, 지연시간 요구사항과 상태 관리 규모, 팀이 다뤄야 할 운영 복잡성을 스스로의 맥락에서 다시 저울질하는 과정이 필요하다. 회고가 제시하는 것은 정답표가 아니라, 검증된 판단의 방향타다.