트리아지의 일부로서의 성능 미니 위생

1. 성능 미니 위생은 triage를 돕는다

"성능"이라는 단어를 들으면 초보자의 머릿속에는 누군가 검은 터틀넥을 입고 버블 정렬을 최적화해서 "거의 빠르게" 만드는 모습이 떠오르곤 합니다. 메모리 버그 조사에서는 현실적으로 더 단순합니다: 성능은 오직 그것이 행동의 안정성에 얼마나 영향을 미치는지에 따라 중요합니다. 메모리에서 우연한 복사와 이동이 많을수록 버그 주변의 "잡음"이 커지고, 근본 원인을 결과와 구분하기가 더 어려워집니다.

예를 들어 수명 오류가 있다고 합시다: 어디선가 std::vector의 요소에 대한 포인터를 저장한 뒤 push_back을 호출하여 reallocation이 발생했다고 합시다. 만약 reallocation이 현재 capacity에 따라 "가끔" 발생한다면, 그 버그도 "가끔" 나타납니다. 조사 기간 동안 reserve를 추가하면 이동이 사라질 수 있고 — 그러면 추적이 쉬워지거나, 반대로 문제가 reallocation이 아니라 코드의 다른 부분에 있음을 알게 됩니다. 두 경우 모두 이득입니다: 신호를 제어할 수 있게 됩니다.

오늘의 핵심 원칙을 명심하세요: 먼저 정확성, 그다음 최적화. 우리는 프로그램을 속도만을 위해 '튜닝'하지 않습니다. 우리는 (a) 보통 코드를 더 빠르게 하고, (b) 우연한 사건(복사, 이동) 수를 줄이며, 그 결과로 (c) 조사 과정을 단순화하고 sanitizer 리포트를 더 직관적으로 만드는 작은 변경을 할 것입니다.

2. std::vector: reserve, reallocation 및 resize와의 차이

std::vector는 범용 컨테이너이지만 한 가지 성격이 있습니다: 요소들을 연속된 메모리 블록에 저장합니다. 공간이 있는 동안은 좋습니다. 공간이 부족하면 vector는 새 버퍼(보통 더 큰)를 할당하고 요소들을 그쪽으로 옮긴 뒤 이전 버퍼를 해제합니다. 이것이 바로 reallocation입니다. 이후에는 이전 버퍼의 모든 포인터/참조/반복자/std::span가 무효화됩니다.

일어나는 일을 단순화한 도식은 다음과 같습니다:

flowchart LR
    A[vector buffer #1
capacity=3] -->|push_back 4th| B[allocate buffer #2
capacity=6]
    B --> C[move/copy elements]
    C --> D[free buffer #1]

버그 조사에서 핵심 단어는 "가끔"입니다. 때로는 capacity가 충분하고, 때로는 그렇지 않습니다. 때로는 push_back이 이동을 일으키고, 때로는 일으키지 않습니다. 그래서 같은 잘못된 포인터가 우연히 아직 데이터를 가리키기도 하고, 때로는 더는 유효하지 않은 주소를 가리키기도 합니다. 그런 순간에 sanitizer는 일주일 뒤에 현장에 온 탐정처럼 보입니다: 흔적은 있지만 절반은 비에 씻겨 내려간 상태입니다.

이때 reserve는 단순한 "최적화"가 아니라 실험의 안정화 수단이 됩니다. 예상되는 최대 크기를 알고 있다면 미리 vector에게 충분한 메모리를 할당해 달라고 요청하여 이동 횟수를 줄일 수 있습니다.

간단한 예: reserve가 동작을 더 예측 가능하게 만드는 경우:

#include <vector>
#include <string>

int main() {
    std::vector<std::string> lines;
    lines.reserve(1000); // 재할당이 적어짐 -> 임의 이동이 줄어듭니다

    lines.push_back("one");
    lines.push_back("two");
}

실용적 팁: 말이나 문서에서는 쉽게 "reserve()"라고 하지만 실제 코드에서는 항상 reserve(size_type)처럼 구체적 크기를 전달합니다. 디버깅할 때는 문자 그대로 "이만큼을 예약한다"는 점을 기억하세요.

reserve와 resize — 비슷한 단어, 다른 결과

이 두 메서드는 둘 다 '크기'에 관한 것처럼 보여 자주 혼동됩니다. 하지만 의미상 서로 다른 세계에 속합니다: reserve는 용량(capacity)에 관한 것이고, resize는 논리적 크기(size)와 요소의 생성/삭제에 관한 것입니다. Triage에서 이것은 중요합니다: 잘못 사용하면 불필요한 요소, 예기치 않은 값, 때로는 다른 로직 경로를 야기하여 원래 조사하던 버그와 다른 문제를 조사하게 됩니다.

일반 언어로 정리하면, reserve(n)는 이렇게 말합니다: "친애하는 vector, 적어도 n개의 요소를 위한 공간을 준비해 줘. 하지만 내가 실제로 보관하고 있는 요소들은 건드리지 마." resize(n)는 이렇게 말합니다: "친애하는 vector, 이제 실제로 너의 요소 수는 n이야; 부족하면 새 요소를 만들고, 많으면 삭제해."

사용자 입력 명령을 읽고 문자열 기록을 보관하는 교육용 컨텍스트의 미니 데모:

#include <iostream>
#include <vector>
#include <string>

int main() {
    std::vector<std::string> history;
    history.reserve(3);

    std::cout << history.size() << '\n'; // 0
    history.push_back("add task");
    std::cout << history.size() << '\n'; // 1
}

이제 resize로 같은 것을 해 보면 차이를 느낄 수 있습니다:

#include <iostream>
#include <vector>
#include <string>

int main() {
    std::vector<std::string> history;
    history.resize(3); // size가 3이 됨, 빈 문자열 3개가 추가됩니다

    std::cout << history.size() << '\n'; // 3
    std::cout << '"' << history[0] << '"' << '\n'; // ""
}

Triage에서 특히 중요한 점: '최적화'를 목적으로 실수로 resize를 사용하면 프로그램 동작을 변경하게 됩니다. 조사는 가능한 한 작은 변경으로 이뤄져야 합니다. 요약하면: reserve는 일반적으로 안전한 "안정화 수단"이고, resize는 데이터와 로직을 변경하는 동작입니다.

3. 복사 감소와 정직한 시그니처

C++에서 복사는 은근한 문제입니다. 초보자는 문자열을 전달하는 것을 대수롭지 않게 여기지만, 문자열 내부는 힙의 버퍼이고 복사는 메모리 할당과 데이터 이동, 추가 재할당을 유발할 수 있습니다. 아무 문제가 없더라도 복사는 "배경"을 만듭니다: 더 많은 할당, 더 많은 메모리 이동, 수명 버그가 드러나거나 은폐될 수 있는 위치가 늘어납니다.

메모리 버그 조사의 관점에서 불필요한 복사는 두 가지로 해롭습니다. 첫째, 할당 패턴을 바꿉니다: sanitizer가 보여주는 할당/해제 경로가 불필요하게 복잡해집니다. 둘째, 복사는 우연히 데이터의 수명을 연장할 수 있습니다(예: 문자열을 복사해서 std::string_view가 '작동'하게 만들 수 있음). 이는 특히 성가십니다: 버그가 '재현 불가'하게 되어 복사 때문에 우연히 가려지기 때문입니다.

따라서 미니 위생의 규칙은 간단합니다: 실제로 복사나 소유권이 필요할 때만 값으로 전달한다, 그 외의 경우에는 const& 또는 뷰 타입을 사용하세요(수명 조건이 맞을 때).

참고용 간단한 표(과하지 않게):

int x

const T&

std::string_view

std::span<const T>

콘솔 작업 관리자 예시에서의 정직한 시그니처

내용을 공중에 떠있게 두지 않기 위해, 간단한 콘솔 '작업 관리자' 애플리케이션에 연결해 보겠습니다. 모델은 다음과 같습니다:

#include <string>

struct Task {
    int id = 0;
    std::string text;
    bool done = false;
};

그리고 저장소는:

#include <vector>

struct TaskStore {
    std::vector<Task> tasks;
};

이제 함수 시그니처를 봅시다. 예를 들어 작업을 추가하는 함수가 있습니다. 직관적인(하지만 덜 좋은) 버전은 다음과 같습니다:

#include <string>
#include <vector>

void add_task(std::vector<Task>& tasks, std::string text) {
    tasks.push_back(Task{static_cast<int>(tasks.size()) + 1, text, false});
}

여기서 text는 값으로 전달되어 호출 시 복사됩니다. 때로는 괜찮지만, 대부분의 경우 우리는 "문자열과 유사한 것"을 불필요한 복사 없이 받기를 원하고, 내부에선 std::string으로 소유권을 확보하고 싶습니다.

이 경우의 깔끔한 대안:

#include <string>
#include <string_view>
#include <vector>

void add_task(std::vector<Task>& tasks, std::string_view text) {
    Task t;
    t.id = static_cast<int>(tasks.size()) + 1;
    t.text = std::string{text}; // 복사는 정확히 한 번: 저장소에만 합니다
    t.done = false;
    tasks.push_back(t);
}

요점은 미세하지만 실용적입니다: 함수는 호출자에게서 미리 std::string을 만들 것을 요구하지 않습니다. std::string, 문자열 리터럴, 문자열 조각 등 여러 것을 받을 수 있습니다. 그러나 Task 내부에는 dangling을 피하기 위해 소유하는 문자열을 저장합니다.

출력도 마찬가지입니다. 컨테이너를 값으로 전달해 작업 목록을 출력하는 것은 전형적인 불필요한 복사입니다(추가 메모리, 불필요한 이동).

#include <iostream>
#include <vector>

void print_tasks(const std::vector<Task>& tasks) {
    for (const Task& t : tasks) {
        std::cout << t.id << ". " << t.text << '\n';
    }
}

이것은 '슈퍼 최적화'가 아니라 기본적인 정직성입니다: 출력 함수는 목록을 소유해서는 안 되고 단지 읽기만 해야 합니다.

string_view와 span — 편리한 뷰 타입이지만 엄격한 lifetime 요구

뷰 타입은 데이터를 "잠깐 들여다보는" 것과 같습니다. 편리하고 빠르지만, 뷰를 구조체 필드에 저장하거나 임시 객체에 대한 뷰를 반환하면 "어제는 동작했음"이라는 고전적인 문제가 발생합니다.

Triage에서 뷰 타입은 복사 수를 줄여 할당과 이동을 줄여주므로 유용합니다. 하지만 그 대가는 수명 규율입니다.

사용자 명령을 파싱하는 전형적인 함수를 살펴봅시다. 우리는 문자열 line을 읽고 그것이 "add "로 시작하는지 확인하고 싶습니다:

#include <string_view>

bool starts_with_add(std::string_view s) {
    return s.starts_with("add ");
}

사용 예:

#include <iostream>
#include <string>

int main() {
    std::string line = "add buy milk";
    std::cout << std::boolalpha << starts_with_add(line) << '\n'; // true
}

여기서는 안전합니다: line이 호출보다 더 오래 살아 있으니까요. 위험은 로컬 문자열에 대한 std::string_view를 반환하려 할 때 시작됩니다:

#include <string>
#include <string_view>

std::string_view bad() {
    std::string tmp = "add buy milk";
    return tmp; // tmp가 소멸됨 -> view가 dangling이 됩니다
}

이 함정은 이전에 lifetime 문제에서 다뤘던 것이며, 여기서는 '위생' 관점에서 중요합니다: 때로는 불필요한 복사가 문제를 숨기고, 반대로 정직한 시그니처가 문제를 드러냅니다. 규칙은 간단합니다: std::string_view와 std::span은 파라미터로는 훌륭하지만, 소유권 보장이 없는 '저장된' 데이터로는 위험합니다.

reserve와 복사 감소: 실제 코드 조각에서의 안정화

둘 다를 동시에 보여주는 작은 애플리케이션 조각을 만들어 봅시다: 명령을 읽고 작업을 추가하며 가끔 목록을 출력합니다. 조사 중에는 작업 벡터가 두 번의 연산마다 이동하지 않고, 문자열이 세 번씩 불필요하게 복사되지 않는 것이 중요합니다.

간단한 템플릿(복잡한 아키텍처 없이 원칙만):

#include <iostream>
#include <string>
#include <vector>

int main() {
    std::vector<Task> tasks;
    tasks.reserve(100); // 디버깅 동안 요소 주소를 안정화합니다

    std::string line;
    while (std::getline(std::cin, line)) {
        if (line == "list") {
            print_tasks(tasks);
        } else if (line.starts_with("add ")) {
            add_task(tasks, std::string_view(line).substr(4));
        }
    }
}

여기서 중요한 점은 add_task가 std::string_view를 받고 우리가 line의 부분 문자열에 대한 view를 전달한다는 것입니다. 이것은 안전합니다: add_task 내부에서 std::string을 만들어 Task에 저장하므로 뷰를 보관하지 않습니다. 즉, 뷰는 "일시적"으로만 사용됩니다.

그리고 tasks.reserve(100)는 "우리가 정확히 100개의 작업을 갖겠다"는 약속이 아니라 실용적인 조치입니다: "조사하는 동안 std::vector가 자주 메모리를 옮기지 않게 합시다." 버그가 찾혀 수정되면 이 값을 재검토하거나 필요 없으면 제거할 수 있습니다.

명확히 하자면: reserve는 절대적인 "절대 이동 없음" 보장을 제공하지 않습니다. 만약 작업이 101개가 되면 이동이 발생합니다. 하지만 triage에서는 종종 원하는 바가 바로 이것입니다: 동작을 "제어 가능한" 상태로 만드는 것. 가설을 검증하려면 reserve(1000)를 넣어 보고, 필요하면 제거하여 증상이 바뀌는지 확인할 수 있습니다.

4. 흔한 실수

실수 #1: reserve를 모든 버그를 막는 마법의 부적으로 여기는 것.
몇 번 성공을 겪으면 "아, reserve를 추가했더니 더 이상 크래시가 안 난다 — 고쳤다"는 생각이 들 수 있습니다. 아니요. reserve는 use-after-realloc 증상을 없앨 수는 있지만, 근본 원인(예: std::vector 요소에 대한 포인터/참조를 보관하는 것)은 남아 있습니다. 단지 버그가 더 교묘해져서 데이터가 더 많아질 때까지 숨어 있을 뿐입니다.

실수 #2: reserve와 resize를 혼동하고 새로운 문제를 조사하는 것.
재할당 횟수를 줄이려다 실수로 resize를 호출하면 컨테이너의 내용이 바뀝니다. 결과적으로 "빈" 요소가 생기거나 로직이 달라져서 원래 있던 버그와 다른 증상을 조사하게 됩니다. Triage에서 이는 특히 해롭습니다.

실수 #3: std::string_view를 모델 내부에 저장하도록 시그니처를 '최적화'하는 것.
학생들이 std::string_view가 복사를 줄여준다는 것을 보고 이를 Task에 저장하여 "아예 문자열을 복사하지 않겠다"고 결정하는 경우가 많습니다. 그러다 보니 원본 문자열이 임시이거나 재사용되면 모든 작업이 같은 버퍼를 가리키게 됩니다. 데이터 모델은 보통 필요한 것을 소유해야 합니다.

실수 #4: 큰 객체를 단순화 때문에 값으로 전달하고 나중에 불안정성에 놀라는 것.
std::vector<Task>나 std::string을 값으로 전달하는 것이 항상 나쁜 것은 아니지만, 함수가 데이터를 소유할 필요가 없다면 이는 은밀한 복사를 추가합니다. 이러한 복사들은 불필요한 할당과 이동을 만들고, 진단 리포트를 복잡하게 하여 행위를 덜 반복 가능하게 만듭니다.

실수 #5: 소유해야 할 결과에 뷰 타입을 사용하고 reserve로 이를 '고치려' 하는 것.
때로는 "std::string_view를 반환하면 더 빠르겠지"라는 유혹이 있습니다. 하지만 반환된 값이 내부 임시 문자열과 독립적으로 존재해야 한다면 뷰는 근본적으로 부적절합니다. reserve는 컨테이너에 관한 것이지 지역 변수의 수명 문제를 해결해주지 않습니다. 이런 경우 올바른 해결책은 보통 단순합니다: std::string을 값으로 반환하고 안심하세요.

1

과제

C++ SELF, 레벨 47, 레슨 3

잠금

제곱표

제곱표

열림

1

과제

C++ SELF, 레벨 47, 레슨 3

잠금

문구 연결

문구 연결

열림

1

과제

C++ SELF, 레벨 47, 레슨 3

잠금

문자열 필터

문자열 필터

열림

1

과제

C++ SELF, 레벨 47, 레슨 3

잠금

콘솔 작업 목록

콘솔 작업 목록

열림