유통이 왕이라면, 데이터는 어디에서 흘러야 하는가

Jun 15, 2026

6 min read

2 views

86%

누가 더 중요한가, 제품인가 유통인가

대부분의 팀은 제품을 먼저 생각한다. 무엇을 만들지, 어떤 기능이 더 뛰어난지, 어떤 구조가 더 우아한지에 몰두한다. 그런데 시장에서 실제로 승패를 가르는 것은 종종 전혀 다른 질문이다. 그 제품이 어떻게 퍼지는가, 그리고 그 퍼짐이 얼마나 자연스럽고 빠르며 저항이 적은가다.

이 질문은 소프트웨어 시스템 안에서도 똑같이 반복된다. 마이크로서비스를 잘게 나누면 설계는 더 깔끔해 보인다. 하지만 서비스가 늘어날수록 더 본질적인 문제가 떠오른다. 데이터는 어떻게 흘러야 하는가. 한 서비스가 가진 사실을 다른 서비스가 어떻게 알게 만들 것인가. 이때 많은 팀이 API 호출, 강한 결합, 수동 동기화 같은 임시방편으로 버틴다. 그러나 결국 시스템을 지배하는 것은 기능 목록이 아니라 유통 경로, 즉 정보가 이동하는 방식이다.

이 둘은 놀라울 만큼 닮아 있다. 시장에서 제품의 가치는 유통망을 타고 증폭되고, 시스템에서 데이터의 가치는 변화 전파 경로를 통해 증폭된다. 결국 핵심은 이것이다.

강한 제품은 좋은 유통을 만나야 이기고, 강한 서비스는 좋은 데이터 전파를 만나야 살아남는다.

유통은 단순한 배달이 아니라 힘의 구조다

유통을 단순히 물건을 옮기는 일로 보면 핵심을 놓친다. 유통은 제품과 시장 사이의 마찰을 얼마나 줄이는지에 관한 문제다. 같은 제품이라도 누가 더 쉽게 접하게 만들고, 누가 더 자주 보게 만들고, 누가 더 적은 클릭과 결정으로 도달하게 하느냐에 따라 결과가 달라진다. 그래서 유통은 보조 기능이 아니라 시장 점유율을 결정하는 인프라다.

이 관점은 소프트웨어 아키텍처에도 그대로 적용된다. 마이크로서비스의 목적은 단지 코드베이스를 쪼개는 것이 아니다. 변화를 어디서 만들고, 어디로 퍼뜨릴지 통제하는 것이다. 그러나 현실에서는 서비스 간 데이터 전달이 종종 우연과 편법의 산물이 된다. 한 서비스가 다른 서비스의 데이터베이스를 직접 참조하거나, 동기 API 호출로 상태를 확인하거나, 배치 작업으로 밤마다 맞춰 놓는다. 이런 방식은 겉으로는 작동하지만, 사실상 변화의 유통망이 불안정한 상태다.

유통이 강한 기업은 하나의 사실을 안다. 좋은 제품은 스스로 퍼지지 않는다. 좋은 시스템도 마찬가지다. 진실이 시스템 전체에 얼마나 빨리, 얼마나 정확하게, 얼마나 저항 없이 전파되는가가 아키텍처의 경쟁력이다. 데이터가 늦게 퍼지면 의사결정도 늦고, 서비스 간 불일치도 커지며, 결국 조직은 점점 더 많은 예외 처리에 의존하게 된다.

이때 중요한 통찰은 이것이다. 유통은 결과가 아니라 설계 대상이라는 점이다. 시장이든 시스템이든, 성공하는 구조는 우연히 생기지 않는다. 의도적으로 깔아둔 경로 위에서만 강해진다.

마이크로서비스의 진짜 문제는 분산이 아니라 전파다

마이크로서비스를 도입한 많은 팀이 처음 기대하는 것은 속도다. 팀별 독립 배포, 기술 스택 자율성, 기능 단위 분리 같은 장점이 떠오른다. 하지만 얼마 지나지 않아 다른 현실을 마주한다. 서비스가 늘어나면서 서로를 알아야 할 이유도 늘어나고, 상태 불일치는 더 자주 발생하며, “이 값은 어디가 진실인가”라는 질문이 반복된다.

이 문제의 본질은 분산 자체가 아니다. 전파 모델의 부재다. 각 서비스가 자기 DB를 소유한다는 원칙은 강력하지만, 그 순간 오히려 새로운 질문이 생긴다. 한 서비스에서 발생한 변경을 다른 서비스가 어떤 방식으로 받아들여야 하는가.

여기서 Change Data Capture, 즉 CDC는 단순한 기술이 아니라 사고방식의 전환을 보여준다. CRUD API로 “가져오는” 방식 대신, 변화가 발생했을 때 그 사실을 캡처해 흘려보내는 방식이다. 이는 데이터 공유를 요청 중심에서 이벤트 중심으로 바꾸는 일이다. 다른 서비스가 “지금 상태를 보여줘”라고 묻는 대신, 원천이 “내 상태가 이렇게 바뀌었다”고 알린다.

이 차이는 매우 크다. 요청 기반 통합은 각 소비자가 소스 서비스의 현재 상태를 계속 조회해야 하므로 결합이 커진다. 반면 CDC는 변경이 일어나는 순간을 기준으로 시스템 전체의 기억을 갱신한다. 즉, 서비스 간 관계를 조회 관계에서 전파 관계로 바꾼다.

분산 시스템의 난제는 데이터가 여러 곳에 있다는 사실이 아니라, 변화가 여러 곳에 다르게 도착한다는 사실이다.

그래서 좋은 아키텍처는 단지 데이터를 저장하는 구조가 아니다. 데이터를 언제, 어떤 순서로, 어떤 일관성 수준으로 배달할지를 정의하는 구조다. 결국 마이크로서비스에서 가장 중요한 설계 질문은 서비스가 몇 개인가가 아니라, 사실이 어떻게 이동하는가다.

시장의 유통망과 시스템의 데이터 흐름은 같은 원리로 작동한다

유통과 CDC를 함께 보면 하나의 공통된 패턴이 보인다. 둘 다 중앙의 진실을 얼마나 많은 곳에 얼마나 빨리 퍼뜨릴 수 있는가를 다룬다. 다만 시장에서는 제품이, 시스템에서는 상태 변화가 움직인다. 시장에서는 광고, 입점, 제휴, 물류가 유통망이고, 시스템에서는 CDC, 메시지 큐, 스트림, 구독자가 유통망이다.

이 둘의 닮은 점을 이해하면 구조를 보는 눈이 달라진다. 예를 들어 신제품을 세상에 내놓을 때 최고의 품질만으로는 부족하다. 사람들이 만나는 지점, 추천받는 경로, 결제까지의 마찰, 재구매의 동선이 함께 설계되어야 한다. 마찬가지로 주문 서비스가 바뀌었다고 할 때, 고객 서비스, 정산, 재고, 알림 서비스가 각자 다른 방식으로 그 변화를 받아서는 안 된다. 같은 변화가 같은 의미로 같은 순서에 가깝게 전파되어야 한다.

한 레스토랑 체인을 생각해 보자. 본사에서 메뉴 가격을 바꾸는 것은 쉽다. 하지만 POS, 배달앱, 인쇄 메뉴판, 재고 예측, 직원 교육, 프로모션 규칙까지 모두 제때 반영되지 않으면 실제 운영은 혼란에 빠진다. 이때 문제는 가격 변경 그 자체가 아니라 변경의 배달 시스템이다. 변화가 모든 접점에 일관되게 도달하지 않으면, 조직은 한 진실을 여러 버전으로 운영하게 된다.

소프트웨어도 똑같다. 주문 상태가 바뀌었는데 배송 서비스는 이전 상태를 보고 있고, 알림 서비스는 이미 발송했으며, 회계 서비스는 아직 반영하지 못했다면 시스템은 하나처럼 보이지만 실제로는 여러 개의 현실을 동시에 운영하는 셈이다. 이는 단순한 버그가 아니라 유통 구조의 실패다.

여기서 중요한 비유가 하나 있다. 전통적인 통합 방식은 도서관의 열람 시스템에 가깝다. 필요한 사람이 가서 직접 찾는다. CDC는 우편 시스템에 가깝다. 책이 아니라 변화 공지, 즉 “어느 장서가 바뀌었다”는 사실을 정해진 구독자에게 자동으로 보낸다. 현대 시스템이 복잡해질수록 우리는 열람보다 우편에 가까운 모델을 더 잘 설계해야 한다.

진짜 경쟁력은 기능이 아니라 마찰이 낮은 경로다

많은 조직이 “무엇을 만들까”에는 과도하게 집중하지만, “어떻게 퍼질까”에는 놀라울 만큼 무심하다. 그러나 성숙한 시스템과 성숙한 사업은 공통적으로 마찰이 낮은 경로를 가진다. 사용자는 적은 노력으로 가치를 받는다. 서비스는 적은 조정으로 최신 상태를 공유한다. 운영은 적은 수작업으로 안정성을 유지한다.

이때 핵심 지표는 단순한 속도가 아니다. 전파의 품질이다. 유통에서 중요한 것은 도달률, 반복 노출, 전환율, 재구매율이다. 데이터 흐름에서 중요한 것은 전달 지연, 순서 보장, 중복 처리, 재처리 가능성이다. 이 지표들은 서로 다른 언어처럼 보이지만, 결국 같은 질문에 답한다. “좋은 것이 도달할 수 있도록 경로가 잘 설계되었는가.”

특히 CDC는 시스템 설계자에게 중요한 습관을 요구한다. 데이터를 직접 요청하는 대신 변경을 흘려보내는 구조를 택하면, 소비자는 더 느슨하게 결합될 수 있다. 각 서비스는 원천의 내부 구현을 덜 알게 되고, 변화의 사실만 받아 자기 목적에 맞게 반응한다. 이는 단순한 기술 선택이 아니라 조직의 협업 구조를 바꾸는 선택이다. 팀은 서로의 내부를 몰라도 되고, 대신 공통의 사실 흐름을 신뢰해야 한다.

이 신뢰가 쌓이면 아키텍처는 더 커져도 덜 깨진다. 반대로 전파 경로가 불명확하면 규모가 커질수록 문제는 배가된다. 작은 시스템에서는 수동 동기화가 버틸 수 있지만, 큰 시스템에서는 그것이 병목이 된다. 작은 시장에서는 입소문이 우연히 작동할 수 있지만, 큰 시장에서는 유통이 곧 전략이 된다.

확장되는 시스템에서 경쟁력은 발명보다 전달에 있다. 좋은 것을 더 멀리, 더 빠르게, 더 일관되게 보내는 능력이 곧 힘이다.

Key Takeaways

제품보다 경로를 먼저 보라. 훌륭한 기능도 퍼지는 경로가 나쁘면 힘을 잃는다. 시장이든 시스템이든, 먼저 유통 구조를 점검하라.
데이터 공유를 조회가 아니라 전파로 설계하라. 마이크로서비스 사이에서 “가져오기”보다 “알리기”가 더 자연스러운지 질문하라. 변화가 생길 때 자동으로 흘러가게 만들 수 있다면 그쪽이 보통 더 강하다.
진실의 단일 출처보다 진실의 빠른 확산이 더 중요할 때가 많다. 한 곳에만 데이터가 있는 것보다, 변경 사실이 여러 소비자에게 일관되게 도달하는 것이 운영 안정성에 더 중요할 수 있다.
마찰이 적은 경로를 설계하라. 사용자에게는 구매까지의 경로를, 시스템에는 변화 전파 경로를 단순화하라. 복잡성은 보통 가치가 아니라 마찰로 쌓인다.
유통은 결과가 아니라 전략이다. 시장에서의 유통망처럼, 시스템 안의 데이터 흐름도 의도적으로 설계하고 측정해야 한다. 우연에 맡기면 규모가 커질수록 비용이 폭발한다.

결론: 왕은 제품이 아니라, 흐름을 지배하는 자다

우리는 자주 성공을 “무엇을 만들었는가”로 설명하지만, 실제로는 “어떻게 퍼졌는가”가 더 깊은 원인인 경우가 많다. 좋은 제품이 아니라 좋은 유통이 시장을 장악하고, 좋은 서비스가 아니라 좋은 전파 구조가 분산 시스템을 안정시킨다. 결국 승자는 더 뛰어난 실체를 가진 쪽이 아니라 흐름을 설계한 쪽이다.

이 관점은 소프트웨어 아키텍처를 보는 방식을 바꾼다. 마이크로서비스는 서비스의 집합이 아니라 변경이 이동하는 네트워크다. CDC는 단순한 데이터 통합 기술이 아니라, 그 네트워크에 질서를 부여하는 방식이다. 그리고 유통은 더 이상 마케팅 용어가 아니다. 어떤 조직이든, 어떤 시스템이든, 가치를 멀리까지 안정적으로 보내는 능력이 곧 지배력이다.

그래서 다음 번에 기능을 설계할 때는 이렇게 물어야 한다. 이 기능은 좋은가, 보다 중요한 질문은 따로 있다. 이 기능이 어떻게 퍼질 것인가? 마이크로서비스를 설계할 때도 마찬가지다. 어떤 서비스가 맞는가보다, 이 변화가 어떤 경로로 시스템 전체에 도달하는가?

그 질문을 던지는 순간, 우리는 비로소 제품을 넘어 유통을, 저장을 넘어 전파를, 구조를 넘어 흐름을 보게 된다. 그리고 그때부터 시스템과 시장은 더 이상 별개의 문제가 아니다. 둘 다 결국 같은 진실을 향한다. 왕은 실체가 아니라 흐름을 지배하는 자다.