어떤 기술 문서를 본 적이 있다. Hadoop 위에 HBase를 올리고, 그 위에 OpenTSDB를 얹고, 옆에 Kafka와 Zookeeper를 붙이고, 전체를 Kubernetes로 감쌌다. 거기에 Redis, MariaDB, MongoDB까지 주렁주렁 매달았다. 마치 오픈소스 빅데이터 솔루션의 종합 선물 세트 같았다.
화려했다. 위압적이었다. 그리고 동시에 한 가지 질문이 떠올랐다.
Chapter 1 닭 잡는 데 소 잡는 칼
초당 수십만 건의 시계열 데이터를 처리해야 한다고 했다. 커넥티드 카, IoT 센서, 실시간 모니터링. 분명 가볍지 않은 요구사항이다.
그런데 그 정도 규모를 위해 Hadoop부터 HBase, OpenTSDB까지 이어지는 3단 적층 구조가 정말 필요한가. PostgreSQL 위에 TimescaleDB 하나만 올려도, ClickHouse 하나만 붙여도 충분히 감당할 수 있는 규모다. 관리 포인트는 셋에서 하나로 줄고, 운영 인력은 절반 이하로 줄고, 장애 원인 추적에 걸리는 시간은 비교조차 할 수 없을 만큼 짧아진다.
그런데도 굳이 저 거대한 구조를 선택한다. 왜일까.
Chapter 2 교수님, 하둡 없어도 빅데이터입니다
대학과 연구소에서 하둡이라는 단어는 일종의 문법이 되었다. 빅데이터를 논할 때 하둡을 언급하지 않으면 뭔가 빠진 것 같은 분위기. 논문에 하둡 아키텍처 다이어그램이 없으면 심사위원이 고개를 갸웃거리는 풍경.
하둡이 나쁜 기술은 아니다. 분산 파일 시스템의 근본이고, 페타바이트 단위의 데이터를 여러 서버에 흩어 담는 데는 여전히 탄탄한 선택이다. 문제는 그 위엄에 기대어 사고를 멈추는 것이다.
2020년대 중반, 클라우드 서비스 하나면 하둡을 직접 설치하지 않아도 같은 효과를 낼 수 있다. 그런데도 하둡부터 주렁주렁 그려 넣는 건, "우리는 기초부터 다 통제할 줄 안다"는 학계의 자존심 때문이다.
"하둡이 없으면 빅데이터가 아니지."
"이 정도 스택은 갖춰야 논문이 나오지."
"국가 과제 쓸 때 구조도가 빈약하면 안 돼."
이 말들의 공통점이 보이는가. 전부 기술적 판단이 아니라 정치적 판단이다. 문제 해결이 아니라 서류 통과가 목적인 설계. 엔지니어링의 탈을 쓴 관료주의다.
Chapter 3 인프라 괴물의 탄생 구조
이런 과잉 설계가 반복되는 데는 구조적 이유가 있다.
첫째, 국산화라는 명분이다. 외국산 상용 솔루션에 돈을 쓰지 말고 오픈소스를 조합해 우리만의 시스템을 만들겠다는 취지 자체는 나쁘지 않다. 하지만 오픈소스를 많이 쓸수록 "더 많은 기술을 소화했다"는 성과물이 되기 때문에, 설계는 점점 비대해진다. 기술 선택의 기준이 효율이 아니라 수량이 되는 것이다.
둘째, 성능이라는 수치의 유혹이다. 초당 29만 건 조회. 이 숫자는 인상적으로 들린다. 그런데 그 비교 대상이 구형 MySQL이라면 이야기가 달라진다. TimescaleDB나 ClickHouse와 비교하면 어떤가. 단일 노드에서도 수백만 포인트를 초당 처리하는 시대에, 분산 클러스터를 동원해 29만 건을 자랑하는 건 솔직히 민망한 수준이다.
셋째, 플랫폼이라는 야심이다. 단순 저장이 아니라 인증, 전처리, 변환, 라우팅, 후처리까지 모두 하나의 시스템 안에서 해결하겠다는 욕심. Authenticator에서 Preprocessor, Enricher, Message Router, Forwarder까지 이어지는 8단계 파이프라인. 데이터가 저장소에 도착하기 전에 거쳐야 할 서버가 너무 많다. 네트워크 홉이 늘어날 때마다 지연은 쌓이고, 장애 포인트는 곱으로 늘어난다.
Chapter 4 서류는 화려하게, 코드는 담백하게
현장의 실무자들은 이미 답을 알고 있다.
서류에는 Hadoop, Kubernetes, Distributed Cluster를 대문짝만하게 박아 놓는다. 교수님이 좋아하는 단어, 심사위원이 끄덕일 만한 아키텍처, 정부 과제에서 예산을 따낼 수 있는 규모감을 연출한다.
그리고 실제 내부에서는 TimescaleDB 하나로 깔끔하게 돌린다.
이것이 실무자의 생존 전략이 되어버렸다는 사실이 씁쓸하다. 기술적으로 옳은 선택을 하면 서류가 빈약해 보이고, 서류를 화려하게 만들면 운영이 지옥이 된다. 그래서 겉과 속을 분리한다. 이중 장부를 쓰는 엔지니어링.
Chapter 5 진짜 실력은 빼는 데 있다
만약 같은 요구사항을 처음부터 다시 설계한다면 어떻게 될까.
IoT 기기에서 데이터가 들어온다. 통합 게이트웨이 하나가 인증, 전처리, 라우팅을 모두 처리한다. 고성능 시계열 DB 하나가 데이터를 받아 저장한다. 웹 인터페이스가 그 데이터를 보여준다. 끝이다.
네 단계. 관리 포인트는 최소화. 장애 추적은 명확. 성능은 동등하거나 그 이상.
이 구조로도 초당 수십만 건은 거뜬하다. 오히려 네트워크 홉이 줄어드니 지연 시간은 더 짧아진다. Zookeeper가 필요 없으니 클러스터 관리의 악몽에서 벗어난다. 한 사람이 퇴사해도 시스템은 무너지지 않는다.
엔지니어링의 정수는 복잡한 것을 만드는 데 있지 않다. 복잡해 보이는 문제를 단순하게 해결하는 데 있다. 레이어를 하나 더 쌓는 것보다, 레이어 하나를 걷어내면서도 같은 성능을 유지하는 것이 더 어렵고, 더 가치 있다.
Epilogue: 복잡함의 공범들에게
이 글이 특정 기술이나 특정 팀을 비난하려는 것은 아니다. 하둡도 좋은 기술이고, 분산 시스템도 필요한 곳에는 반드시 필요하다. 문제는 기술 선택이 순수한 기술적 판단이 아니라, 서류의 무게감, 논문의 볼륨, 과제 심사의 눈치에 의해 결정되는 현실이다.
교수는 거대한 아키텍처 다이어그램이 있어야 과제를 딴다. 연구원은 그 다이어그램을 현실로 만들어야 실적이 된다. 실무자는 그 현실 위에서 운영의 지옥을 버텨야 월급을 받는다. 모두가 복잡함의 공범이면서 동시에 피해자다.
이 악순환을 끊으려면, 기술적 판단이 기술적 근거로만 이루어지는 환경이 먼저 만들어져야 한다. "이 문제를 풀기 위해 가장 적은 비용으로 가장 안정적인 방법이 무엇인가"라는 질문이 "이 서류를 통과시키기 위해 얼마나 많은 기술을 나열해야 하는가"보다 앞서는 문화.
엔지니어의 실력은 쌓아올린 스택의 높이가 아니라, 걷어낸 복잡함의 깊이로 측정된다. 진짜 실력자는 하둡을 외치는 사람이 아니라, 하둡 없이도 같은 결과를 만들어내는 사람이다.