std::span C++20: 안전한 버퍼 전달을 위한 사용(그리고 사용하지 말아야 할 때)

URL: https://techfortalk.co.uk/2025/12/30/stdspan-c20-when-to-use-and-not-use-for-safe-buffer-passing/

Title: std::span C++20: 안전한 버퍼 전달을 위한 사용(그리고 사용하지 말아야 할 때)

Introduction

현대 C++에서 효율적인 데이터 처리는 매우 중요하며, 특히 성능이 중요한 애플리케이션에서는 메모리 레이아웃과 접근 패턴이 전체 성능에 큰 영향을 줄 수 있습니다. 이 글에서는 C++에서 연속(contiguous) 데이터 버퍼를 함수에 전달하는 여러 방법을 살펴보고, 각각의 장단점을 정리합니다. 원시 포인터(raw pointer), std::vector, std::array 같은 전통적인 접근을 먼저 살펴본 뒤, 연속 메모리를 다루기 위한 안전하고 유연하며 타입 안정적인 대안으로 설계된 C++20 기능인 std::span을 소개합니다. 이러한 접근들을 이해하면 개발자는 안전성, 성능, 사용성을 균형 있게 고려하여 애플리케이션의 데이터 관리 방식을 더 합리적으로 선택할 수 있습니다.

Passing Contiguous Data Buffers in Performance-Critical C++

데이터를 다룰 때 우리는 캐시 효율성과 예측 가능한 접근 패턴 때문에 연속 메모리 레이아웃에 주목하곤 합니다. 성능이 중요한 시스템 레벨 C++ 애플리케이션에서는 이 문제가 특히 핵심이 됩니다. 실제로 함수에 데이터 버퍼를 전달하는 전통적인 방식은 몇 가지로 좁혀집니다.

• 원시 포인터(raw pointers)
• std::vector
• std::array

각 접근은 아키텍처적 트레이드오프를 갖고 있으며, 무분별하게 사용하면 버그, 성능 오버헤드, 혹은 지나치게 경직된 API로 이어질 수 있습니다.

Raw Pointers: The Decoupled Metadata Problem

가장 원초적이고 역사적으로 흔한 접근은 원시 포인터와 별도의 크기(size) 파라미터를 함께 사용하는 방식입니다. 이 패턴은 여전히 디바이스 드라이버, 네트워킹 스택, C API에서 널리 사용됩니다. 핵심 문제는 메타데이터(특히 버퍼 크기)가 데이터 포인터에 본질적으로 결합되어 있지 않다는 점입니다. 이러한 분리는 컴파일러가 강제하는 계약이 아니라 전적으로 프로그래머의 규율에 의존하는 취약한 계약을 만듭니다. 아래 예제를 보겠습니다.

예제 9.1: 원시 포인터 인터페이스를 이용한 패킷 처리

cpp
// filename: sample_program_raw_pointer.cpp
#include <iostream>
#include <cstdint>

void process_packet(const uint8_t* buffer, std::size_t length)
{
    for (std::size_t i = 0; i < length; ++i)
    {
        std::cout << std::hex << static_cast<int>(buffer[i]) << " ";
    }
    std::cout << "\n";
}

int main()
{
    uint8_t packet[] = {0xDE, 0xAD, 0xBE, 0xEF};
    process_packet(packet, 4);
    return 0;
}

이 프로그램은 패킷 처리에서 원시 포인터를 사용하는 방법을 보여주며, 이는 임베디드 시스템, 네트워크 프로그래밍, 성능이 중요한 코드에서 전형적인 패턴입니다. 네트워크 패킷이나 프로토콜 데이터는 종종 미리 할당된(preallocated) 또는 고정 크기 버퍼로 들어오며, 예를 들어 고속 디바이스 드라이버에서 DMA 기반 영역 같은 형태가 흔합니다. 이런 버퍼는 여러 파싱 단계로 전달되며, 각 단계는 헤더를 건너뛰기 위해 포인터를 앞으로 이동시키면서 남은 페이로드 길이를 갱신할 수 있습니다.

만약 포인터 이동(pointer advancement)이나 길이 재계산(length recalculation) 중 하나라도 잘못되면, 함수는 유효한 버퍼 경계를 넘어 읽게 될 수 있습니다. 컴파일러는 포인터 위치와 버퍼 크기 사이의 이런 논리적 불일치를 감지할 수 없고, 오류는 특정 트래픽 패턴이나 타이밍 조건에서만 드러나는 경우가 많습니다. 활성 포인터 위치와 버퍼의 유효 범위 사이의 일관성을 유지하는 책임이 전적으로 프로그래머에게 있기 때문에, 컴파일 타임/런타임 경계 체크를 적용하는 타입 안전 추상화에 비해 매우 오류가 발생하기 쉬운 방식입니다.

std::vector: Safe Size Handling but API Rigidity

버퍼나 데이터 관리를 위해 다음으로 떠올리기 쉬운 선택은 std::vector<>입니다. std::vector를 사용하면 컨테이너가 크기를 내부적으로 보유하므로 크기 불일치 문제를 피할 수 있습니다. 정확성 관점에서 이는 원시 포인터보다 큰 개선입니다.

예제 9.2: std::vector를 사용한 텔레메트리 로깅

cpp
// filename: sample_program_vector_telemetry.cpp
#include <iostream>
#include <vector>

void log_telemetry(const std::vector<int>& entries)
{
    for (int e : entries)
    {
        std::cout << e << " ";
    }
    std::cout << "\n";
}

int main()
{
    std::vector<int> data = {10, 20, 30};
    log_telemetry(data);
    return 0;
}

여기서의 한계는 안전성(safety)이 아니라, 함수 시그니처가 명시적으로 std::vector를 요구한다는 점입니다. 즉 호출자는 이미 데이터를 vector에 저장하고 있어야 합니다. 호출자가 스택 배열, 메모리 매핑 버퍼, 또는 std::array에 데이터를 갖고 있다면 버퍼를 직접 전달할 수 없습니다. 실제로는 함수가 읽기 전용 접근만 필요하더라도, 임시 std::vector를 만들고 요소를 복사하는 식의 변환을 강요받는 일이 자주 발생합니다.

이것이 std::vector 기반 함수 인터페이스의 핵심 트레이드오프입니다. 알고리즘을 특정 소유(owning) 컨테이너에 결합(couple)해 버립니다. 저지연(low-latency)이나 메모리 제약 시스템에서는 힙 할당과 복사가 심각한 비용이 될 수 있습니다.

The std::array Type Rigidity Problem

연속 데이터를 표현하는 또 다른 선택은 std::array입니다. 원시 배열과 달리 크기 정보를 갖고 타입 시스템과 깔끔하게 통합됩니다. 많은 임베디드 및 성능 민감 애플리케이션에서 이러한 특성은 std::array를 훌륭한 기본 컨테이너로 만들어 줍니다. 하지만 std::array에서는 버퍼의 크기가 타입 자체의 일부입니다. 이는 크기가 다른 두 배열이 컴파일러에게 완전히 무관한 타입으로 취급된다는 뜻입니다. 다음 프로그램을 보겠습니다.

예제: 함수 타입의 일부가 되는 크기

cpp
// filename: sample_program_array_rigid.cpp
#include <array>
#include <iostream>

void apply_filter(const std::array<float, 1024>& signal)
{
    std::cout << "Processing 1024 samples\n";
}

int main()
{
    std::array<float, 512> small_signal{};
    std::array<float, 1024> large_signal{};
    
    apply_filter(large_signal);     // Works
    // apply_filter(small_signal);  // Compile-time error
    
    return 0;
}

이 코드는 small_signal을 apply_filter에 전달하면 컴파일에 실패합니다. 이 실패는 논리 오류나 안전 문제 때문이 아닙니다. std::array<float, 512>와 std::array<float, 1024>가 서로 다른 타입이고, 함수가 그중 하나만 받도록 명시되어 있기 때문에 발생합니다.

이런 경직성은 알고리즘이 정말로 정확히 특정 개수의 요소를 요구할 때는 적절합니다. 하지만 신호 처리, 필터링, 수치 해석 등 많은 현실 세계 알고리즘에서는 크기가 특정 컴파일 타임 상수여야 할 이유가 없습니다. 필요한 것은 데이터가 연속적이고, 런타임에 요소 개수를 알 수 있다는 점뿐입니다. 이 지점에서 개발자들은 종종 템플릿을 사용하게 됩니다.

Template Solution Creates Binary Bloat

크기 N에 대해 템플릿을 사용하면 컴파일은 해결되지만, N 값마다 별도의 머신 코드가 생성됩니다. 아래 예제를 보겠습니다.

예제: 템플릿 기반 std::array 인터페이스

cpp
// filename: sample_program_array_template.cpp
#include <array>
#include <iostream>

template <std::size_t N>
void apply_filter(const std::array<float, N>& signal)
{
    std::cout << "Processing " << N << " samples\n";
}

int main()
{
    std::array<float, 512> small_signal{};
    std::array<float, 1024> large_signal{};
    
    apply_filter(small_signal);   // Instantiates apply_filter<512>
    apply_filter(large_signal);   // Instantiates apply_filter<1024>
    
    return 0;
}

이 버전은 컴파일되고 올바르게 동작합니다. 각 호출은 해당 크기에 대한 별도의 함수 인스턴스를 생성합니다. 알고리즘 로직은 동일하지만, 컴파일러는 N 값마다 서로 다른 머신 코드를 내보냅니다.

이는 기대된 정상 동작이지만, 실무적으로는 결과가 따릅니다. 지원해야 하는 크기 종류가 늘어날수록 생성되는 함수 수도 늘어납니다. 그 결과 바이너리 크기, 심볼 수, 컴파일 시간이 증가합니다.

이제 위 상황에서 우리의 친구 std::span이 등장해 문제를 해결해 줍니다. 어떻게 동작하는지 살펴보겠습니다.

std::span (C++20): A Non-Owning View for Contiguous Memory

C++20은 std::span을 도입했는데, 이는 지금까지 논의한 상황을 포함해 함수 인터페이스에서 연속 버퍼를 전달하고 처리하기 위해 특별히 설계되었습니다. 사용하기 전에, std::span이 무엇이고 무엇이 아닌지 명확히 해 두는 것이 도움이 됩니다.

• std::span은 컨테이너가 아닙니다.
• std::span은 메모리를 소유하지 않으며, 할당/해제를 절대 수행하지 않습니다.
• std::span은 C 스타일 배열, std::array, std::vector, 혹은 길이와 함께 제공되는 원시 포인터 같은 기존 연속 메모리 블록에 대한 가벼운 뷰(view)입니다.

핵심 아이디어는 std::span이 요소 접근과 요소 개수를 제공하되, 메모리가 어떻게 생성/리사이즈/해제되는지에 대한 책임은 지지 않는다는 점입니다.

std::span이 포인터와 크기를 캡슐화하는 방식

내부적으로 span은 보통 첫 요소를 가리키는 포인터와 크기(size)로 구현됩니다. 정석 형태는 기본적으로 동적 extent를 갖는 std::span<T>입니다.

span이 크기를 획득하는 방식은 다음과 같습니다.

• C 스타일 배열에서는 크기가 컴파일 타임에 추론됩니다.
• std::vector에서는 vector::size()에서 크기를 얻습니다.
• std::array에서는 크기가 배열 타입의 일부로 존재합니다.
• 원시 포인터에서는 크기를 명시적으로 제공해야 합니다.

C++ std::span: 연속 데이터에 대해 타입 안전하고 컨테이너에 독립적인 함수 작성

C++20의 std::span은 배열, std::vector, std::array 및 기타 연속 시퀀스를 함수에 전달하기 위한 타입 안전(type-safe)한 비소유(non-owning) 뷰를 제공합니다. 포인터와 크기를 묶어 경계 인지(bounded) 접근을 가능하게 하여 안전성을 높이면서도 성능은 유지합니다. 다음 예제로 동작을 살펴보겠습니다.

예제: std::span을 이용한 범용 센서 데이터 처리

cpp
// filename: sample_program_with_span.cpp
#include <iostream>
#include <span>
#include <vector>
#include <array>

void process_sensors(std::span<const int> data)
{
    std::cout << "Processing " << data.size() << " elements: ";
    for (int val : data)
    {
        std::cout << val << ' ';
    }
    std::cout << '\n';
}

int main()
{
    // 1. C-style array (size deduced automatically)
    int raw_array[] = {1, 2, 3};
    process_sensors(raw_array);

    // 2. std::vector (size taken from container metadata)
    std::vector<int> v = {10, 20, 30, 40};
    process_sensors(v);

    // 3. std::array (size taken from type)
    std::array<int, 2> a = {100, 200};
    process_sensors(a);

    // 4. Subview created from a container
    process_sensors(std::span(v).subspan(1, 2));

    // 5. Raw pointer with explicit size
    int sensor_buffer[] = {7, 8, 9, 10, 11};
    int* ptr = sensor_buffer + 1;     // pointer to second element
    std::size_t count = 3;            // number of valid elements
    process_sensors(std::span(ptr, count));

    return 0;
}

std::span을 사용하면 원시 배열, std::vector, std::array 같은 어떤 연속 데이터 소스든 단일하고 일관된 인터페이스로 받는 제네릭 함수를 작성할 수 있다는 점을 확인할 수 있습니다. 이 예제는 현실적인 함수 인터페이스에서 std::span을 구성하는 지원되는 모든 방법을 보여줍니다.

• C 스타일 배열을 전달할 때 span은 크기를 자동으로 추론합니다.
• **std::vector**를 전달할 때 span은 vector::size()를 사용합니다.
• **std::array**를 전달할 때 크기는 배열 타입에서 옵니다.
• 원시 포인터를 전달할 때는 크기를 명시적으로 제공해야 합니다.

마지막 케이스는 시스템 코드에서 특히 중요합니다. 레거시 API, 메모리 매핑 영역, DMA 버퍼, 드라이버 인터페이스는 종종 컨테이너가 아니라 포인터와 길이를 제공합니다. 그 포인터와 길이로 std::span을 생성하면 둘이 즉시 결합되어, 함수는 서로 느슨하게 관련된 두 파라미터 대신 단일 객체를 대상으로 동작할 수 있습니다.

span이 한 번 구성되면 함수는 더 이상 포인터와 별도의 크기를 다루지 않습니다. 포인터–크기 불일치 위험 없이 슬라이싱(subspan), 반복(iteration), 추가 전달이 가능한 경계 인지 뷰를 다루게 됩니다.

Limitation of std::span: No Container-Specific Operations

하지만 std::span은 모든 상황에서 만능 도구가 아닙니다. 데이터를 std::span으로 전달하는 순간, 당신은 컨테이너 인터페이스가 아니라 **버퍼 뷰(view)**를 선택하는 것입니다. 즉 컨테이너 전용 연산은 더 이상 사용할 수 없습니다. std::span은 메모리 관리나 컨테이너 유틸리티를 지원하지 않습니다. 크기 변경(resize), 할당(allocation), 저장소(storage) 관리가 불가능합니다. push_back, insert, erase, reserve, capacity 같은 메서드도 제공되지 않습니다.

Where Should We Use std::span in C++ Applications

std::span은 함수가 연속 데이터를 접근해야 하지만, 그 데이터를 소유하거나 관리할 필요가 없는 곳에서 사용해야 합니다. 이는 설계 목적에서 바로 도출됩니다. std::span은 컨테이너가 아니라 연속 메모리에 대한 비소유 뷰입니다. 역할은 기존 요소 블록에 접근하고 순회하는 데로 제한되며, 소유권(ownership), 할당(allocation), 수명(lifetime) 관리는 원시 버퍼, std::vector, std::array 같은 원본 소스에 남아 있습니다.

따라서 std::span은 데이터에 대해 연산은 수행하지만 데이터 저장 방식은 통제하지 말아야 하는 알고리즘/처리 코드에 특히 적합합니다.

When NOT to Use std::span in C++: Common Pitfalls and Alternatives

std::span은 C++20에서 연속 데이터에 대한 가볍고 비소유적인 뷰를 제공하며, 함수 파라미터로 쓰기에 이상적입니다. 하지만 클래스 멤버로 사용하거나, 수명 관리를 기대하거나, 비연속 데이터를 다루거나, 컨테이너 전용 연산이 필요한 경우 std::span을 사용하면 댕글링 참조 같은 버그로 이어질 수 있습니다.

클래스 데이터 멤버로 std::span 사용을 피하라

클래스에 std::span을 저장하면 원본 데이터가 파괴되거나 재할당(reallocate)될 때 댕글링 포인터가 생길 위험이 있으며, 이는 C++ 애플리케이션에서 미정의 동작(undefined behavior)을 유발합니다. 수명이 긴 객체에서는 소유를 위해 std::vector나 std::array 같은 타입을 선호하세요. 이는 임베디드 시스템이나 멀티스레드 코드에서 흔한 미묘한 크래시를 예방합니다.

수명(lifetime) 관리를 위해 std::span을 쓰지 마라

std::span은 데이터의 수명을 연장할 수 없으므로, 원본 버퍼보다 오래 살아야 하는 큐, 캐시, 비동기 작업(async task)에는 안전하지 않습니다. 지속성이 필요하다면 std::unique_ptr<std::vector<T>> 또는 std::shared_ptr 같은 소유 타입을 사용하세요. C++ 개발자들은 이런 방식으로 span을 오용할 때 수명 버그가 자주 발생한다고 보고합니다.

비연속 컨테이너에서는 std::span이 실패한다

std::span은 연속 메모리를 요구하므로 std::list, std::forward_list, 또는 deque의 꼬리(tail) 같은 구조와는 호환되지 않습니다. 흩어진 데이터 접근에는 이터레이터, std::ranges, 또는 컨테이너 뷰를 사용하세요. 이 제한은 오래된 STL 패턴에서 마이그레이션하는 팀이 자주 마주치는 함정입니다.

std::span에는 컨테이너 전용 메서드가 없다

std::span에는 vector::reserve(), capacity(), array::fill(), push_back() 같은 컨테이너 전용 메서드가 없습니다. 이는 동적 연산에서 필수인 기능입니다. 이런 기능이 C++ 설계에서 중요하다면 구체 컨테이너 타입을 유지해야 합니다. std::span은 읽기 전용 또는 제네릭 접근 패턴에 가장 적합합니다.

Conclusion

현대 C++에서 연속 버퍼를 전달하는 방식 선택은 안전성과 성능 모두에 직접적인 영향을 줍니다. 원시 포인터는 유연하지만 오류가 발생하기 쉽고, std::vector와 std::array 같은 컨테이너는 함수 경계에서 불필요한 소유권이나 인터페이스 제약을 부과하는 경우가 많습니다.

C++20에 도입된 std::span은 런타임 오버헤드 없이 버퍼 크기를 명시적으로 만들 수 있는 비소유 뷰를 제공합니다. 올바르게 사용하면 원시 포인터+길이 쌍에 대한 더 안전한 대안이자, 컨테이너 기반 파라미터보다 더 유연한 인터페이스를 제공합니다.

std::span은 데이터 소유자가 아니라 짧게 살아있는 뷰로 취급될 때 가장 효과적입니다. 이러한 규율을 지키면 시스템 레벨 코드에서 요구되는 성능 특성을 유지하면서도, C++에서 안전한 버퍼 전달을 위한 더 명확한 API를 설계할 수 있습니다.