C++의 새 흐름 "네오클래시컬" - 분할 이터레이터가 다시 주목받는 이유

오래된 문제를 새로운 시각으로

C++ 개발자들 사이에서 최근 "네오클래시컬 C++(Neoclassical C++)"이라는 표현이 자주 들려요. 이게 뭐냐면, C++의 본래 강점인 제로 코스트 추상화(zero-cost abstraction), 그러니까 "높은 수준의 코드를 써도 성능 손해는 없다"는 철학을 다시 강조하면서, 현대적인 도구들(C++20의 ranges, concepts, modules 등)로 재해석하는 흐름이에요. 그 흐름 위에서 이번에 "분할 이터레이터(segmented iterators)"라는 주제가 다시 다뤄지고 있어요.

분할 이터레이터가 뭔가요

먼저 일반적인 이터레이터(iterator)부터 설명할게요. 이터레이터는 컨테이너(예: 배열, 리스트)의 원소를 하나씩 순회할 수 있게 해주는 객체예요. for (auto it = v.begin(); it != v.end(); ++it) 같은 코드에서 it이 바로 이터레이터죠.

그런데 어떤 자료구조는 내부가 여러 개의 연속된 블록으로 나뉘어 있어요. 대표적인 게 std::deque예요. deque은 큰 배열 하나가 아니라 작은 배열 여러 개를 묶어서 마치 하나의 큰 배열처럼 보여주는 자료구조거든요. 또 rope이나 청크 기반의 텍스트 버퍼, GPU에서 자주 쓰는 분할 메모리 구조도 비슷해요.

이런 구조에서 이터레이터를 "한 칸씩 ++ 해가며 순회"하면, 블록 경계를 넘어갈 때마다 "지금 어느 블록에 있지? 다음 블록은 어디지?" 같은 검사를 매번 해야 해요. 이게 단순한 배열 순회보다 훨씬 느려지는 원인이에요. 분할 이터레이터는 이 문제를 해결하려는 아이디어예요. "한 블록 안에서는 빠른 순회, 블록 사이는 별도 점프"로 두 단계로 나누어 처리하자는 거죠.

왜 지금 다시 이 주제인가

사실 분할 이터레이터 아이디어 자체는 새롭지 않아요. 2000년대 초반 매트 오스턴(Matt Austern)이 처음 제안했지만, 표준에 채택되지 못하고 잊혀진 개념이었거든요. 그런데 C++20에서 Ranges 라이브러리가 등장하고, C++23의 views::chunk나 views::join 같은 분할 구조를 다루는 뷰들이 표준에 들어오면서 다시 "세그먼트 기반 순회"가 자연스럽게 필요해진 거예요.

특히 성능이 중요한 도메인에서요. 예를 들어 머신러닝 텐서 라이브러리는 메모리를 작은 타일(tile) 단위로 잘라서 저장하거든요. 데이터베이스 엔진도 컬럼 데이터를 페이지 단위로 관리하고요. 이런 데서 표준 std::for_each나 std::transform 같은 알고리즘이 분할 구조를 인식하지 못하면, 내부적으로 매 원소마다 경계 검사를 하느라 캐시 효율이 크게 떨어져요.

어떻게 동작하나

핵심은 알고리즘이 "이 이터레이터는 분할되어 있다"는 사실을 컴파일 시점에 알 수 있게 만드는 거예요. C++20의 concepts를 사용하면 "세그먼트 이터레이터의 요건"을 타입 시스템에 명시할 수 있어요. 그러면 std::for_each 같은 알고리즘이 그 요건을 감지하고, 내부적으로 "바깥 루프는 세그먼트 단위, 안쪽 루프는 원소 단위"로 두 단계 순회를 자동으로 펼쳐주는 거죠.

이게 왜 빠르냐면, 안쪽 루프는 단순히 한 블록 내의 연속 메모리를 도는 거라서 컴파일러가 SIMD(병렬 명령) 최적화나 루프 언롤링을 적극적으로 적용할 수 있거든요. 반면 단순한 단일 이터레이터 순회는 매번 "다음이 같은 블록인가?"를 확인하느라 이런 최적화가 막혀요. 벤치마크에 따라서는 2배에서 10배까지 차이가 나기도 해요.

다른 언어와의 비교

Rust의 경우 비슷한 아이디어가 Iterator trait의 fold나 rayon 라이브러리의 병렬 순회에 녹아 있어요. Java의 Spliterator도 같은 발상이고요. 이름에서 알 수 있듯이 "split이 가능한 iterator"라는 뜻이에요. C++만 표준 차원에서 이 개념이 빠져 있었는데, 이제 비로소 따라잡으려는 움직임이 보이는 거죠.

한국 개발자에게 주는 시사점

게임 엔진, 자율주행, 금융 거래 시스템처럼 C++을 실무에서 쓰는 한국 회사들이 점점 늘고 있어요. 이런 곳에서는 알고리즘의 "이론적 복잡도"보다 "실제 캐시 효율"이 성능을 가르는 경우가 많아요. 분할 이터레이터 개념을 이해해 두면, 직접 자료구조를 설계할 때나 외부 라이브러리를 평가할 때 훨씬 좋은 판단을 할 수 있어요.