업계는 잘못된 의사결정을 돈으로 덮는 방식에 익숙하다. 처리량이 부족하면 인스턴스를 늘리고, 꼬리 지연 시간(tail latency)이 불안정하면 캐시 앞에 또 다른 캐시를 추가한다. 켈리 서머스는 이런 문제의 본질을 정확히 짚었다. 패턴 기반 아키텍처는 조직적으로는 깔끔해 보일 수 있지만, 연산 측면에서는 낭비가 크다. 해법은 또 다른 계층을 쌓는 것이 아니라 기본기에 있다. 백엔드팀에 투자하거나 운영하는 기업에 있어 데이터 구조와 알고리즘은 단순한 면접 과제가 아니다. 이는 서비스 수준 목표(SLO)와 매출원가(COGS)에 직접적인 영향을 주는 핵심 운영 자산이다.
개발자는 이미 이 사실을 잘 알고 있다. 기술 책임자 역시 클라우드 요금이 급증할 때 매출원가 항목에서 같은 압박을 체감한다. 두 경우 모두 해법은 같다. 데이터 구조의 선택과 설계를 핵심 아키텍처 결정으로 다루고, 알고리즘적 트레이드오프를 재무 부서가 ROI를 따지듯 평가하는 문화를 정착시키는 것이다. 켈리 서머스가 강조하듯 “컴퓨터가 실제로 작동하는 방식을 존중하면서 깔끔하고 유지 가능한 시스템을 구축할 수 있는 개발자”가 필요하다.
기본기는 과거에 대한 향수가 아니다
단순한 전제에서 출발하자. 대규모 환경에서는 작은 비효율도 곧 하나의 기능 전체에 맞먹는 비용과 사용자 불편으로 이어진다. 제프 딘이 널리 인용한 “지연 시간 수치” 요약표가 존재하는 이유도 바로 여기에 있다. 메인 메모리 접근은 L1 캐시 접근보다 수백 배 느리고, 데이터센터를 가로지르는 전송은 그보다 훨씬 더 느리다. 만약 핵심 경로가 메모리나 네트워크를 이리저리 오가며 지역성(locality)을 고려하지 않는다면, 사용자는 시간을 잃고 기업은 비용을 잃는다.
결국 물리 법칙의 기본이 엄청난 차이를 만든다.
여기에 2013년 제프 딘과 루이스 안드레 바로소가 제시한 ‘대규모 환경에서의 꼬리 지연 문제(tail at scale)‘ 개념을 더해 보자. 99퍼센타일 지연 시간은 서비스 수준 협약이 무너지는 지점이다. 팬아웃(fan-out) 서비스에서는 드문 지연도 흔히 나타나는 문제가 되기 때문이다. 꼬리 지연을 견디는 시스템은 단순히 복제나 재시도에 의존하는 것이 아니라, 알고리즘 선택과 데이터 레이아웃 설계가 똑같이 중요하다. 다시 말해, 기본기는 서비스 수준 목표에는 긍정적으로, 재무제표에는 부정적으로 그대로 드러난다.
조금 추상적으로 들린다면, 자바의 해시맵(HashMap) 사례를 보자. 자바 8 이전에는 공격자가 다수의 키를 동일한 버킷에 몰아넣으면, 평균 조회 시간 O(1)이 최악의 경우 O(n)까지 떨어져 성능이 크게 저하되거나 서비스 거부(DoS) 공격에 악용될 수 있었다. 자바팀은 JEP 180을 통해 이 문제를 해결했다. 긴 충돌 체인을 균형 이진 트리(red-black tree)로 변환해(tree-ify) 최악의 경우를 O(log n)으로 개선한 것이다. 이는 미세한 최적화가 아니라 알고리즘과 데이터 구조 차원의 결정이었으며, 전 세계에서 가장 널리 사용되는 컬렉션 중 하나의 보안과 성능 프로파일을 바꿔 놓았다. 아키텍처 부사장이라면 바로 이런 ‘기본기’ 논의가 설계 리뷰에서 반드시 다뤄지길 원할 것이다.
CS101에서는 빅 오(Big O) 표기법을 가르치지만, 실제 프로덕션 환경에서는 메모리가 성능을 지배한다. 울리히 드레퍼가 2007년에 발표한 고전 논문은, 선형처럼 보이는 코드도 캐시를 thrash하거나 NUMA 경계를 넘나들면 초선형(superlinear) 동작을 보일 수 있음을 설명한다. 따라서 지역성을 극대화하는 데이터 구조와 접근 패턴, 예컨대 페이지 크기 노드를 갖는 B-트리, SoA(Structure of Arrays)와 AoS(Array of Structures) 레이아웃 비교, 링 버퍼는 학문적인 디테일이 아니다. 이는 CPU가 실제로 연산을 수행하느냐 아니면 대기 상태에 머무느냐를 결정짓는 요소다. 쉽게 말하면, 캐시 친화적인 데이터 구조는 이미 비용을 지불한 컴퓨팅 자원을 실제 활용 가능한 처리량으로 전환한다.
스토리지 엔진은 예산을 가진 데이터 구조다
모든 데이터베이스 스토리지 엔진은 손익계산서를 갖춘 하나의 데이터 구조다. 예를 들어 B+트리는 디스크 기반의 빠른 읽기와 범위 검색에 최적화되어 있지만, 그 대가로 쓰기 비용(쓰기 증폭)이 커진다. 반대로 로그 구조 병합 트리(LSM 트리)는 높은 쓰기 성능을 제공하지만, 컴팩션(compaction) 과정과 읽기 증폭으로 인한 비용을 안게 된다. 어느 쪽이 더 낫다고 단정할 수는 없다. 이는 알고리즘적 트레이드오프의 결과이며, 그 영향은 IOPS, SSD 수명, 컴팩션 시 CPU 소모 같은 운영 지표에 직접 드러난다.
워크로드가 쓰기 위주이고 읽기를 묶어서 처리한다면 LSM 트리가 적합하다. 반대로 읽기 지연에 민감하고 범위 검색이 많다면 B+트리가 유리하다. 결국 이 선택은 데이터 구조를 고르는 문제이자, 클라우드 비용과 SLO로 직결되는 사안이다. 그렇게 다뤄야 한다.
납득이 가지 않는다면 프랭크 맥셰리, 마이클 아이사드, 데릭 머레이가 발표한 흥미로운 논문을 보자. 이들은 직설적인 질문을 던진다. “화려한 병렬 시스템이 제대로 구현된 단일 스레드를 이기려면 몇 대의 머신이 필요할까?” 그들은 이를 ‘COST(configuration that outperforms a single thread)’라는 지표로 정의했는데, 많은 시스템이 단일 스레드를 능가하려면 수백 개 코어가 필요하다는 결과가 나왔다. 그러나 더 나은 알고리즘이나 데이터 구조를 적용해 클러스터 자체가 필요 없게 된다면, 이는 단순한 엔지니어링 과시가 아니다. 수백만 달러의 비용을 절감하고 공격 표면을 줄이는 실질적인 성과다.
순수하게 알고리즘 선택만으로도 큰 성과를 낸 사례는 가까이에서도 찾을 수 있다. 페이스북은 zlib에서 Zstandard(zstd)로 전환했다. 이는 ‘성급한 최적화’가 아니라, 더 나은 압축률과 더 빠른 압축·해제를 제공하는 알고리즘을 전략적으로 선택한 것이었다. 그 결과 성능이 향상됐을 뿐 아니라 대규모 환경에서 스토리지와 전송 비용까지 줄일 수 있었다. 다시 말해, 기본기가 확실한 비즈니스 성과로 이어진 사례다.
AI가 이 모든 걸 바꿔놓았는가?
일부 개발자는 AI가 이 공식을 완전히 뒤집는다고 생각하지만, 그렇기도 하고 아니기도 하다. 실제로는 공식이 달라진 게 아니라 데이터 구조 기본기의 중요성이 더 커진 것에 가깝다.
머신러닝 파이프라인은 움직이는 데이터 구조다. 컬럼 형식, 벡터 인덱스, 블룸 필터, 세그먼트 트리, 메시지 큐, 캐시 계층 등이 그것이다. 잘못된 선택은 연쇄적으로 문제를 일으킨다. 제한 없는 조인으로 인해 계속 반복되는 ETL 작업, 비정상적인 재현율과 지연 시간 트레이드오프가 있는 벡터 스토어, 모델 연산보다 직렬화(serialization) 오버헤드가 더 큰 추론 경로 등이 대표적이다.
더 좋은 GPU를 구매하거나 GPU 개수를 늘리는 것이 곧바로 AI 시스템 최적화로 이어지지는 않는다. 적합한 인덱스와 배치 크기를 선택하고, 캐시 지역성을 고려해 피처를 설계하며, 데이터 이동을 마치 실제로 비용을 지불하는 것처럼 설계하는 것이다. 왜냐하면 실제로 비용을 지불하고 있기 때문이다.
백엔드 엔지니어링팀을 운영하면서 설계 문서에 데이터 구조 선택과 그에 따른 트레이드오프를 명확히 기록하지 않는다면, 아마도 기본기를 다른 곳의 인프라 비용으로 메우고 있을 가능성이 크다. 물론 서머스는 이 문제에 대해 집요하지만 광신적인 태도를 보이지는 않는다. 기본기가 중요하다는 점은 분명하지만, 때로는 팀이 수용할 수 있는 만큼의 좋은 요소를 아키텍처에 녹여내는 것이 현실적인 답이 될 수 있다는 것이다. 서머스의 말처럼 “최선의 아키텍처란 항상 정답을 고집하는 것이 아니라, 팀이 이미 좋아하는 프레임워크 안에 좋은 기본기를 슬며시 끼워 넣는 것일 때도 있다.”
서머스가 우리의 시선을 다시 기본기로 돌리는 것은 타당하다. 빠르고 예측 가능하며 비용 효율적인 백엔드를 좌우하는 요소는 최신 프레임워크가 아니라 컴퓨팅 기본기다.
만약 팀이 서비스 수준 목표를 충족하는 순간이 ‘성능 담당자’가 자정에 perf 도구를 꺼내들 때뿐이라면, 그것은 사실상 복불복에 의존하는 시스템을 만든 것과 다름없다. 반대로 기본기가 일상화되어 있고, 팀 모두가 왜 주 인덱스가 4KB 페이지를 가진 B+트리인지, 그리고 컴팩션 부담이 어디에 숨어 있는지 이해하고 있다면, 시스템은 예측 가능해진다. 그리고 바로 그 예측 가능성이야말로 고객과 CFO에게 제공하는 진짜 가치다.
더 많은 하드웨어로 기본기를 덮어버리는 것은 달콤할 만큼 쉬운 선택이다. 그러나 장기적으로는 알고리즘의 명확성과 신중한 데이터 구조 설계가 이자가 쌓이듯 누적된다. 이것이야말로 사용자는 물론 손익계산서(P&L)에 한 약속을 지켜내는 방법이다.
dl-itworldkorea@foundryco.com
Matt Asay editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.