[TWC 4.5Sota] Overloading vs. Overriding

결론

Overloading(오버로딩)은 같은 이름의 함수를 매개변수의 타입이나 개수를 다르게 하여 여러 개 정의하는 컴파일 타임 다형성이며, Overriding(오버라이딩)은 상속 관계에서 부모 클래스의 가상 함수를 자식 클래스에서 재정의하는 런타임 다형성입니다. 핵심 차이는 오버로딩은 함수 시그니처(signature)를 기반으로 컴파일러가 어떤 함수를 호출할지 결정하고, 오버라이딩은 객체의 실제 타입을 기반으로 런타임에 동적으로 결정한다는 점입니다.

---

1단계: 직관적인 비유 (Intuitive Analogy)

Overloading: 같은 이름의 다른 도구들

오버로딩은 **"만능 드라이버 세트"**에 비유할 수 있습니다. 당신의 공구함에 "드라이버"라는 이름이 붙은 도구가 여러 개 있습니다. 일자 드라이버, 십자 드라이버, 육각 드라이버 등 다양한 종류가 있죠. 모두 "드라이버"라는 같은 이름이지만, 나사의 모양(매개변수)에 따라 어떤 드라이버를 사용할지 당신은 즉시 판단합니다.

십자 나사를 보면 십자 드라이버를 선택하고, 육각 나사를 보면 육각 드라이버를 선택합니다. 이 선택은 나사를 보는 순간(컴파일 타임)에 이미 결정됩니다. 당신이 공구함을 열기 전에 이미 어떤 도구가 필요한지 알고 있는 것이죠.

Overriding: 같은 명령, 다른 실행

오버라이딩은 **"다국적 회사의 지사들"**에 비유할 수 있습니다. 본사에서 "연말 파티를 개최하라"는 지시를 내립니다. 이 지시는 모든 지사에 동일하게 전달되지만, 각 지사는 자신들의 문화와 상황에 맞게 파티를 다르게 개최합니다.

한국 지사는 한식 뷔페와 송년회를 열고, 미국 지사는 크리스마스 파티를 열며, 일본 지사는 보넨카이(忘年会)를 엽니다. 같은 명령("파티를 개최하라")이지만, 실제로 어떤 지사가 실행하는지(객체의 실제 타입)에 따라 행동이 달라집니다. 그리고 이는 파티가 실제로 열리는 시점(런타임)에 결정됩니다.

핵심은 오버로딩은 "어떤 도구를 쓸 것인가?"의 문제이고, 오버라이딩은 "누가 실행할 것인가?"의 문제입니다.

---

2단계: 핵심 이론과 역사 (Core Theory & History)

Overloading의 핵심 이론

**함수 오버로딩(Function Overloading)**은 같은 스코프 내에서 동일한 이름을 가진 여러 함수를 선언할 수 있게 하는 기능으로, C++의 정적 다형성(Static Polymorphism) 또는 **컴파일 타임 다형성(Compile-time Polymorphism)**의 핵심 메커니즘입니다.

함수 시그니처 (Function Signature)

컴파일러는 함수 시그니처를 기반으로 오버로딩된 함수들을 구별합니다. C++에서 함수 시그니처는 다음을 포함합니다:

1. 함수 이름 (Function Name)
2. 매개변수의 개수 (Number of Parameters)
3. 매개변수의 타입 (Types of Parameters)
4. 매개변수의 순서 (Order of Parameters)
5. CV-한정자 (const/volatile qualifiers) - 멤버 함수의 경우
6. 참조 한정자 (Reference Qualifiers) - C++11부터: &, &&

중요: 반환 타입(Return Type)은 시그니처에 포함되지 않습니다. 이는 역사적으로 함수 호출 시 반환 타입만으로는 어떤 함수를 호출할지 결정할 수 없기 때문입니다.

// C++20 기준 오버로딩 예제
class Calculator {
public:
    // 1. 매개변수 개수로 구분
    int add(int a, int b) { return a + b; }
    int add(int a, int b, int c) { return a + b + c; }
    
    // 2. 매개변수 타입으로 구분
    double add(double a, double b) { return a + b; }
    
    // 3. const 한정자로 구분 (멤버 함수)
    void display() { std::cout << "Non-const\n"; }
    void display() const { std::cout << "Const\n"; }
    
    // 4. C++11 참조 한정자로 구분
    void process() & { std::cout << "Lvalue\n"; }
    void process() && { std::cout << "Rvalue\n"; }
};

Name Mangling (이름 맹글링)

오버로딩은 컴파일러의 Name Mangling 기법으로 구현됩니다. C++에서 함수 이름은 타입 정보를 포함한 고유한 심볼로 변환됩니다:

void func(int);        // 맹글링 후: _Z4funci (GCC/Clang)
void func(double);     // 맹글링 후: _Z4funcd
void func(int, double); // 맹글링 후: _Z4funcid

각 컴파일러(GCC, MSVC, Clang)는 자체적인 맹글링 규칙을 사용하지만, Itanium C++ ABI가 사실상의 표준이 되었습니다.

Overriding의 핵심 이론

**함수 오버라이딩(Function Overriding)**은 상속 관계에서 파생 클래스가 기반 클래스의 가상 함수를 재정의하는 것으로, C++의 동적 다형성(Dynamic Polymorphism) 또는 **런타임 다형성(Runtime Polymorphism)**의 핵심입니다.

Virtual Function (가상 함수)

오버라이딩은 virtual 키워드를 통해 활성화됩니다. 가상 함수가 호출될 때, 컴파일러는 포인터나 참조가 가리키는 객체의 실제 타입을 기반으로 어떤 함수를 호출할지 결정합니다.

class Shape {
public:
    virtual void draw() const {
        std::cout << "Drawing Shape\n";
    }
    virtual ~Shape() = default; // 가상 소멸자 필수!
};

class Circle : public Shape {
public:
    void draw() const override { // C++11: override 키워드
        std::cout << "Drawing Circle\n";
    }
};

class Rectangle : public Shape {
public:
    void draw() const override {
        std::cout << "Drawing Rectangle\n";
    }
};

Virtual Table (가상 함수 테이블, vtable)

오버라이딩은 **Virtual Table(vtable)**과 **Virtual Pointer(vptr)**를 통해 구현됩니다:

1. vtable: 각 클래스마다 컴파일러가 생성하는 가상 함수 포인터들의 배열
2. vptr: 각 객체가 가지는 자신의 클래스의 vtable을 가리키는 포인터

Shape 객체의 메모리 구조:
+-------------------+
| vptr → Shape::vtable |
+-------------------+
| 멤버 변수들...     |
+-------------------+

Shape::vtable:
+--------------------------+
| Shape::draw() 주소       |
| Shape::~Shape() 주소     |
+--------------------------+

Circle 객체의 메모리 구조:
+-------------------+
| vptr → Circle::vtable |
+-------------------+
| Shape 멤버 변수들  |
| Circle 멤버 변수들 |
+-------------------+

Circle::vtable:
+--------------------------+
| Circle::draw() 주소      | <- 오버라이드됨!
| Circle::~Circle() 주소   |
+--------------------------+

역사적 맥락

Overloading의 역사

함수 오버로딩은 Bjarne Stroustrup이 1979년 C++의 전신인 "C with Classes"를 개발할 때 도입한 개념입니다. 당시 Simula 67의 영향을 받았으며, 같은 개념적 작업을 수행하는 함수들에 동일한 이름을 부여함으로써 프로그래머의 인지 부담을 줄이고자 했습니다.

초기 C 언어에서는 함수 이름이 고유해야 했기 때문에 abs_int(), abs_float(), abs_double() 같은 이름을 사용해야 했지만, C++에서는 단순히 abs()로 통일할 수 있게 되었습니다.

**연산자 오버로딩(Operator Overloading)**도 같은 시기에 도입되었으며, 이는 C++이 사용자 정의 타입을 내장 타입처럼 자연스럽게 사용할 수 있게 만든 혁명적인 기능이었습니다.

Overriding의 역사

가상 함수와 오버라이딩은 Simula 67(1967년, Ole-Johan Dahl과 Kristen Nygaard)에서 처음 도입된 개념입니다. Simula는 최초의 객체지향 언어로, 클래스, 상속, 가상 함수의 개념을 확립했습니다.

Stroustrup은 Simula의 가상 함수 메커니즘을 C++에 도입하면서, 성능을 위해 vtable 구현을 선택했습니다. 이는 Smalltalk의 메시지 패싱 방식보다 빠르지만, C의 제로 오버헤드 원칙과 타협한 결과였습니다.

C++11에서는 override와 final 키워드가 추가되어 의도를 명확히 하고 실수를 방지할 수 있게 되었습니다:

class Base {
    virtual void foo(int);
};

class Derived : public Base {
    // C++03: 실수로 오버로딩이 됨 (int vs long)
    virtual void foo(long); 
    
    // C++11: 컴파일 에러! 오버라이드가 아님을 명확히 검출
    void foo(long) override; 
    
    // 올바른 오버라이딩
    void foo(int) override;
};

C++20에서는 Concepts와 함께 템플릿 오버로딩이 더욱 정교해졌으며, Coroutines의 도입으로 새로운 형태의 함수 오버로딩 패턴이 등장했습니다.

C++20의 새로운 기능들

1. Concepts를 활용한 오버로딩

C++20의 Concepts는 템플릿 오버로딩을 더욱 명확하고 강력하게 만듭니다:

#include <concepts>

// Concept 정의
template<typename T>
concept Integral = std::is_integral_v<T>;

template<typename T>
concept FloatingPoint = std::floating_point<T>;

// Concepts를 사용한 오버로딩
class MathLib {
public:
    // 정수 타입에 대한 오버로딩
    template<Integral T>
    auto process(T value) {
        return value * 2;
    }
    
    // 부동소수점 타입에 대한 오버로딩
    template<FloatingPoint T>
    auto process(T value) {
        return value * 2.5;
    }
};

이는 기존 SFINAE(Substitution Failure Is Not An Error)보다 훨씬 가독성이 높고 에러 메시지가 명확합니다.

2. Abbreviated Function Templates (축약 함수 템플릿)

C++20에서는 auto 키워드로 더 간결한 템플릿 오버로딩을 작성할 수 있습니다:

// C++20 이전
template<typename T>
void print(T value) {
    std::cout << value << '\n';
}

// C++20
void print(auto value) {
    std::cout << value << '\n';
}

// Concepts와 결합
void print(std::integral auto value) {
    std::cout << "Integer: " << value << '\n';
}

void print(std::floating_point auto value) {
    std::cout << "Float: " << value << '\n';
}

3. Three-way Comparison (우주선 연산자)

C++20의 <=> 연산자는 오버로딩의 새로운 차원을 열었습니다:

#include <compare>

class Point {
    int x, y;
public:
    // 하나의 연산자로 6개의 비교 연산자를 자동 생성
    auto operator<=>(const Point&) const = default;
};

---

3단계: 응용과 확장 (Application & Extension)

Overloading의 산업적 응용

1. API 설계의 사용성 향상

**게임 엔진 (Unreal Engine, Unity)**에서 오버로딩은 필수적입니다:

// Unreal Engine 스타일의 벡터 연산
class FVector {
public:
    // 다양한 생성자 오버로딩
    FVector();                           // 기본값
    FVector(float X, float Y, float Z);  // 개별 값
    FVector(const FVector2D& V, float Z); // 2D → 3D 변환
    
    // 연산자 오버로딩
    FVector operator+(const FVector& V) const;
    FVector operator*(float Scale) const;
    float operator|(const FVector& V) const; // 내적
    FVector operator^(const FVector& V) const; // 외적
};

// 사용 예
FVector a(1, 2, 3);
FVector b(4, 5, 6);
float dot = a | b;    // 직관적인 문법!
FVector cross = a ^ b;

이러한 연산자 오버로딩은 수학적 표현을 코드로 자연스럽게 변환할 수 있게 하여, 게임 프로그래머의 생산성을 극대화합니다.

2. 데이터베이스 및 ORM 라이브러리

SQLite의 C++ 래퍼나 ORM에서 오버로딩은 타입 안정성을 제공합니다:

class Statement {
public:
    // 다양한 타입에 대한 바인딩 오버로딩
    void bind(int idx, int value);
    void bind(int idx, double value);
    void bind(int idx, const std::string& value);
    void bind(int idx, std::string_view value);  // C++17
    void bind(int idx, std::span<const uint8_t> blob); // C++20
    void bind(int idx, std::nullptr_t); // NULL 바인딩
};

// 사용
stmt.bind(1, 42);
stmt.bind(2, 3.14);
stmt.bind(3, "hello");
stmt.bind(4, nullptr);

컴파일 타임에 타입 검증이 이루어지므로, 런타임 에러를 방지할 수 있습니다.

3. 고성능 수치 계산 라이브러리 (Eigen, Armadillo)

선형대수 라이브러리에서 오버로딩과 템플릿 메타프로그래밍이 결합되면 제로 오버헤드 추상화를 달성합니다:

// Eigen 스타일
Eigen::MatrixXd A(3, 3);
Eigen::VectorXd x(3);
Eigen::VectorXd b = A * x;  // 연산자 오버로딩

// Expression Templates를 통한 최적화
// b = A * x + y * 2.0 - z;
// → 루프 융합(loop fusion)으로 단일 루프로 최적화

이는 MATLAB과 같은 문법을 유지하면서 C의 성능을 얻을 수 있게 합니다.

Overriding의 산업적 응용

1. 플러그인 아키텍처 (Plugin Architecture)

Adobe Photoshop, VSCode와 같은 플러그인 기반 애플리케이션은 오버라이딩을 핵심으로 합니다:

// 플러그인 인터페이스
class IPlugin {
public:
    virtual ~IPlugin() = default;
    virtual std::string getName() const = 0;
    virtual void initialize() = 0;
    virtual void execute() = 0;
    virtual void shutdown() = 0;
};

// 구체적인 플러그인
class ImageFilterPlugin : public IPlugin {
public:
    std::string getName() const override { 
        return "Blur Filter"; 
    }
    void initialize() override {
        // GPU 리소스 할당 등
    }
    void execute() override {
        // 실제 필터링 로직
    }
    void shutdown() override {
        // 정리 작업
    }
};

// 호스트 애플리케이션
class PluginManager {
    std::vector<std::unique_ptr<IPlugin>> plugins;
public:
    void executeAll() {
        for (auto& plugin : plugins) {
            plugin->execute(); // 런타임 다형성!
        }
    }
};

이 패턴은 **Open/Closed Principle(개방-폐쇄 원칙)**을 구현하며, 애플리케이션을 재컴파일하지 않고도 기능을 확장할 수 있게 합니다.

2. 게임의 엔티티 시스템

게임 엔진의 엔티티 시스템은 오버라이딩의 교과서적 예시입니다:

class GameObject {
protected:
    Transform transform;
public:
    virtual ~GameObject() = default;
    virtual void update(float deltaTime) = 0;
    virtual void render() = 0;
    virtual void onCollision(GameObject* other) {}
};

class Player : public GameObject {
    float health;
    Weapon* weapon;
public:
    void update(float deltaTime) override {
        // 입력 처리, 물리 업데이트
        handleInput();
        updatePhysics(deltaTime);
    }
    
    void render() override {
        // 플레이어 렌더링
        renderModel();
        renderHealthBar();
    }
    
    void onCollision(GameObject* other) override {
        if (auto* enemy = dynamic_cast<Enemy*>(other)) {
            takeDamage(enemy->getDamage());
        }
    }
};

class Enemy : public GameObject {
    AI* brain;
public:
    void update(float deltaTime) override {
        // AI 로직
        brain->think();
        moveTowardsPlayer(deltaTime);
    }
    
    void render() override {
        renderModel();
        renderHealthBar();
    }
};

// 게임 루프
std::vector<std::unique_ptr<GameObject>> entities;

void gameLoop(float deltaTime) {
    for (auto& entity : entities) {
        entity->update(deltaTime);  // 각 객체의 실제 타입에 맞는 update 호출
        entity->render();           // 각 객체의 실제 타입에 맞는 render 호출
    }
}

3. 디자인 패턴의 구현

많은 GoF 디자인 패턴이 오버라이딩에 의존합니다:

전략 패턴 (Strategy Pattern):

class SortStrategy {
public:
    virtual ~SortStrategy() = default;
    virtual void sort(std::vector<int>& data) = 0;
};

class QuickSort : public SortStrategy {
public:
    void sort(std::vector<int>& data) override {
        // 퀵소트 구현
    }
};

class MergeSort : public SortStrategy {
public:
    void sort(std::vector<int>& data) override {
        // 병합정렬 구현
    }
};

class Sorter {
    std::unique_ptr<SortStrategy> strategy;
public:
    void setStrategy(std::unique_ptr<SortStrategy> s) {
        strategy = std::move(s);
    }
    
    void performSort(std::vector<int>& data) {
        strategy->sort(data); // 런타임에 전략 선택!
    }
};

팩토리 패턴 (Factory Pattern):

class Document {
public:
    virtual ~Document() = default;
    virtual void open() = 0;
    virtual void save() = 0;
};

class PDFDocument : public Document {
public:
    void open() override { /* PDF 열기 로직 */ }
    void save() override { /* PDF 저장 로직 */ }
};

class WordDocument : public Document {
public:
    void open() override { /* Word 열기 로직 */ }
    void save() override { /* Word 저장 로직 */ }
};

class DocumentFactory {
public:
    static std::unique_ptr<Document> create(const std::string& type) {
        if (type == "pdf") return std::make_unique<PDFDocument>();
        if (type == "word") return std::make_unique<WordDocument>();
        throw std::invalid_argument("Unknown document type");
    }
};

오버로딩과 오버라이딩의 결합

실제 시스템에서는 두 개념이 함께 사용됩니다:

class Renderer {
public:
    // 오버로딩: 다양한 프리미티브 렌더링
    virtual void draw(const Point& p) { /* 점 그리기 */ }
    virtual void draw(const Line& l) { /* 선 그리기 */ }
    virtual void draw(const Circle& c) { /* 원 그리기 */ }
    
    virtual ~Renderer() = default;
};

class OpenGLRenderer : public Renderer {
public:
    // 오버라이딩: OpenGL로 구현
    void draw(const Point& p) override { 
        // glVertex로 구현
    }
    void draw(const Line& l) override { 
        // glBegin(GL_LINES)로 구현
    }
    void draw(const Circle& c) override { 
        // 삼각형 팬으로 근사
    }
};

class VulkanRenderer : public Renderer {
public:
    // 오버라이딩: Vulkan으로 구현
    void draw(const Point& p) override { 
        // vkCmdDraw로 구현
    }
    void draw(const Line& l) override { 
        // Vulkan 라인 파이프라인
    }
    void draw(const Circle& c) override { 
        // Compute shader로 렌더링
    }
};

// 사용
void renderScene(Renderer* renderer) {
    Point pt{10, 20};
    Line ln{{0, 0}, {100, 100}};
    Circle circ{50, 50, 25};
    
    renderer->draw(pt);  // 오버로딩으로 함수 선택 + 오버라이딩으로 구현 선택
    renderer->draw(ln);
    renderer->draw(circ);
}

다른 언어와의 비교

Java

• 오버로딩: C++와 유사하게 지원
• 오버라이딩: 모든 메서드가 기본적으로 가상 함수 (virtual by default)
• @Override 어노테이션으로 의도 명시

Python

• 오버로딩: 기본적으로 지원 안 함 (마지막 정의가 이전 것을 덮어씀)
  • functools.singledispatch나 타입 힌트로 유사하게 구현 가능
• 오버라이딩: 자연스럽게 지원 (덕 타이핑)

Rust

• 오버로딩: 직접적으로 지원하지 않음
  • Trait 시스템과 제네릭으로 유사한 효과
• 오버라이딩: Trait의 메서드를 재정의하는 방식

---

4단계: 시스템과 코드 (System & Code Integration)

거시적 관점: 시스템과 사회적 영향

소프트웨어 아키텍처에 미치는 영향

오버로딩과 오버라이딩은 소프트웨어 아키텍처의 근간을 형성합니다. 이들은 단순한 문법적 기능을 넘어, 대규모 시스템의 설계 철학을 결정합니다.

1. 유지보수성과 확장성의 경제학

오버라이딩 기반의 다형성은 **변경의 국지화(Localization of Change)**를 가능하게 합니다. 예를 들어, Microsoft Windows의 그래픽 드라이버 아키텍처를 생각해봅시다:

// Windows 그래픽 드라이버 추상 인터페이스
class IDisplayDriver {
public:
    virtual void setResolution(int width, int height) = 0;
    virtual void drawPixel(int x, int y, Color c) = 0;
    virtual void bitBlt(Surface* src, Rect srcRect, Point dest) = 0;
    // ... 수백 개의 메서드
};

// NVIDIA 드라이버
class NVIDIADriver : public IDisplayDriver {
    // NVIDIA GPU 특화 구현
};

// AMD 드라이버
class AMDDriver : public IDisplayDriver {
    // AMD GPU 특화 구현
};

이 구조 덕분에:

• Windows는 드라이버 코드를 알지 못해도 모든 GPU를 지원할 수 있습니다
• 새로운 GPU 제조사는 Windows를 수정하지 않고 드라이버만 작성하면 됩니다
• 버그 수정이나 최적화가 해당 드라이버 내부에 국한됩니다

이는 수십억 달러 규모의 생태계를 가능하게 하는 아키텍처입니다. 만약 오버라이딩이 없었다면, GPU마다 Windows 커널을 수정해야 했을 것이고, 이는 사실상 불가능했을 것입니다.

경제적 파급효과:

• NVIDIA의 2024년 매출 609억 달러
• AMD의 GPU 부문 매출 약 65억 달러
• 이 모든 것이 플러그인 가능한 드라이버 아키텍처 위에 구축됨

2. 웹 브라우저 엔진의 진화

Chrome, Firefox, Safari의 렌더링 엔진(Blink, Gecko, WebKit)은 모두 오버라이딩을 핵심으로 사용합니다:

// 브라우저 렌더링 엔진의 추상 노드
class Node {
public:
    virtual void layout() = 0;
    virtual void paint(GraphicsContext&) = 0;
    virtual void handleEvent(Event&) {}
    virtual ~Node() = default;
};

class Element : public Node {
    // HTML 엘리먼트의 공통 동작
};

class HTMLDivElement : public Element {
    void layout() override {
        // Block 레이아웃 알고리즘
    }
};

class HTMLCanvasElement : public Element {
    void layout() override {
        // Canvas 특화 레이아웃
    }
    void paint(GraphicsContext& ctx) override {
        // GPU 가속 렌더링
    }
};

이 구조는:

• 새로운 HTML 태그를 추가할 때 기존 코드를 거의 수정하지 않아도 됩니다
• CSS의 새로운 레이아웃 모드(Flexbox, Grid)를 구현할 때 확장이 쉽습니다
• 성능 최적화가 개별 엘리먼트 수준에서 가능합니다

3. 클라우드 인프라의 추상화

AWS, Azure, GCP는 모두 추상 인터페이스와 오버라이딩을 통해 다양한 백엔드를 지원합니다:

class StorageProvider {
public:
    virtual void put(const std::string& key, std::span<const uint8_t> data) = 0;
    virtual std::vector<uint8_t> get(const std::string& key) = 0;
    virtual void del(const std::string& key) = 0;
    virtual ~StorageProvider() = default;
};

class S3Provider : public StorageProvider {
    void put(const std::string& key, std::span<const uint8_t> data) override {
        // AWS S3 API 호출
    }
    // ...
};

class AzureBlobProvider : public StorageProvider {
    void put(const std::string& key, std::span<const uint8_t> data) override {
        // Azure Blob Storage API 호출
    }
    // ...
};

// 사용자 애플리케이션은 추상 인터페이스만 사용
class Application {
    std::unique_ptr<StorageProvider> storage;
public:
    Application(std::unique_ptr<StorageProvider> s) : storage(std::move(s)) {}
    
    void saveData(const std::string& key, const Data& data) {
        storage->put(key, serialize(data)); // 어떤 클라우드든 동일한 코드!
    }
};

이는 벤더 락인(Vendor Lock-in)을 방지하고, 멀티 클라우드 전략을 가능하게 합니다.

윤리적 딜레마와 설계 결정

1. 성능 vs 유연성의 트레이드오프

가상 함수는 **추가적인 간접 참조(indirection)**를 발생시킵니다:

• vtable lookup: 메모리 접근 1회 추가
• 함수 포인터 역참조: 간접 점프로 인한 파이프라인 스톨
• 인라이닝 불가: 컴파일러가 함수를 인라이닝할 수 없음

현대 게임에서 **초당 60프레임(16.67ms)**을 유지하려면, 매 프레임 수백만 개의 객체를 처리해야 합니다. 여기서 가상 함수의 오버헤드는 심각한 문제가 될 수 있습니다.

해결책들:

• Data-Oriented Design (DOD): 가상 함수 대신 데이터 중심 설계
• Entity Component System (ECS): Unity DOTS, Unreal의 Mass Entity
• CRTP (Curiously Recurring Template Pattern): 컴파일 타임 다형성

// CRTP로 오버헤드 제거
template<typename Derived>
class Shape {
public:
    void draw() {
        static_cast<Derived*>(this)->drawImpl();
    }
};

class Circle : public Shape<Circle> {
public:
    void drawImpl() {
        // 구현
    }
};

// 사용
template<typename T>
void render(Shape<T>& shape) {
    shape.draw(); // 가상 함수 호출 없음! 인라이닝 가능!
}

이는 설계 결정의 윤리적 차원을 보여줍니다: 유연성을 위해 성능을 희생할 것인가, 아니면 성능을 위해 복잡성을 감수할 것인가?

2. ABI 안정성 (Application Binary Interface Stability)

가상 함수는 ABI의 일부가 됩니다. 한번 공개된 가상 함수는:

• 순서를 바꿀 수 없습니다 (vtable 순서 고정)
• 제거할 수 없습니다 (하위 호환성 깨짐)
• 새로운 가상 함수를 중간에 추가하기 어렵습니다

Qt 프레임워크는 이 문제로 고생하며, Q_PRIVATE 패턴을 사용합니다:

class QObjectPrivate; // 전방 선언

class QObject {
    QObjectPrivate* d_ptr; // pImpl 패턴
    Q_DECLARE_PRIVATE(QObject)
public:
    virtual void someMethod();
    // 새로운 가상 함수를 d_ptr을 통해 간접적으로 추가
};

이는 장기적인 소프트웨어 유지보수의 중요성을 보여줍니다.

미래 기술 트렌드

1. Concepts와 정적 다형성의 부활

C++20 Concepts는 컴파일 타임 다형성의 르네상스를 가져왔습니다:

template<typename T>
concept Drawable = requires(T t, GraphicsContext& ctx) {
    { t.draw(ctx) } -> std::same_as<void>;
};

// 가상 함수 없이 다형성!
void renderAll(const std::vector<Drawable auto>& objects, GraphicsContext& ctx) {
    for (const auto& obj : objects) {
        obj.draw(ctx); // 완전히 인라이닝 가능!
    }
}

이는 제로 오버헤드 추상화의 완성형이며, 게임 엔진과 임베디드 시스템에서 점점 더 많이 사용될 것입니다.

2. LLVM과 Devirtualization

현대 컴파일러(LLVM, GCC)는 점점 더 똑똑해져서 가상 함수 호출을 최적화합니다:

Shape* s = new Circle();
s->draw(); // 컴파일러가 실제 타입을 알면 직접 Circle::draw() 호출로 최적화

Whole Program Optimization (WPO) 과 Link-Time Optimization (LTO) 기술이 발전하면서, 가상 함수의 오버헤드가 점점 줄어들고 있습니다.

3. Rust의 영향

Rust는 Trait Objects를 통해 가상 함수와 유사한 기능을 제공하면서도:

• 메모리 안전성을 보장합니다
• Fat Pointers를 사용하여 vtable을 더 효율적으로 관리합니다

trait Drawable {
    fn draw(&self);
}

// 동적 디스패치
fn render(drawable: &dyn Drawable) {
    drawable.draw();
}

// 정적 디스패치 (제네릭)
fn render_fast<T: Drawable>(drawable: &T) {
    drawable.draw(); // 인라이닝 가능!
}

C++도 이러한 아이디어를 받아들여 C++23의 Deducing This와 같은 기능이 추가되고 있습니다.

---

미시적 관점: 하드웨어와 수학적 기초

컴파일러의 구현: Name Mangling 상세

오버로딩은 컴파일러의 Name Mangling 과정을 통해 구현됩니다. Itanium C++ ABI를 따르는 맹글링 규칙을 살펴봅시다:

namespace MyLib {
    class Calculator {
    public:
        int add(int a, int b);
        double add(double a, double b);
        int add(int a, int b, int c);
    };
}

맹글링 후 심볼:

_ZN5MyLib10Calculator3addEii      // int add(int, int)
_ZN5MyLib10Calculator3addEdd      // double add(double, double)
_ZN5MyLib10Calculator3addEiii     // int add(int, int, int)

맹글링 규칙 해독:

• _Z: 맹글링된 이름의 시작
• N: Nested name (네임스페이스/클래스 내부)
• 5MyLib: 길이(5) + "MyLib"
• 10Calculator: 길이(10) + "Calculator"
• 3add: 길이(3) + "add"
• E: Nested name의 끝
• ii: 매개변수 타입 (int, int)
• dd: 매개변수 타입 (double, double)
• iii: 매개변수 타입 (int, int, int)

타입 인코딩 표:

i = int
l = long
d = double
f = float
b = bool
c = char
v = void
P = pointer (예: Pi = int*)
R = reference (예: Ri = int&)
K = const (예: Ki = const int)

템플릿 맹글링:

template<typename T>
T max(T a, T b);

max<int>(1, 2);     // _Z3maxIiET_S0_S0_
max<double>(1.0, 2.0); // _Z3maxIdET_S0_S0_

이 맹글링 과정은 **링커(Linker)**가 올바른 함수를 찾을 수 있게 합니다.

어셈블리 레벨에서의 함수 호출

일반 함수 호출 (Static Dispatch):

void foo(int x) {
    // ...
}

int main() {
    foo(42);
}

생성된 어셈블리 (x86-64):

main:
    mov     edi, 42        ; 첫 번째 인자를 edi 레지스터에
    call    foo            ; 직접 호출! 주소가 컴파일 타임에 결정됨
    ret

가상 함수 호출 (Dynamic Dispatch):

class Base {
public:
    virtual void foo(int x);
};

void callFoo(Base* obj) {
    obj->foo(42);
}

생성된 어셈블리:

callFoo:
    mov     rdi, [rbp - 8]   ; obj 포인터를 rdi에 로드
    mov     rax, [rdi]       ; *obj → vtable 포인터를 rax에 로드 (간접 참조 1)
    mov     rax, [rax]       ; vtable[0] → foo의 주소를 rax에 로드 (간접 참조 2)
    mov     esi, 42          ; 두 번째 인자 (첫 번째는 this)
    call    rax              ; 간접 호출! 주소가 런타임에 결정됨
    ret

성능 차이:

• 일반 함수: 1번의 메모리 접근(명령어 페치), 분기 예측 가능
• 가상 함수: 3번의 메모리 접근(obj, vtable, 함수 포인터), 분기 예측 불가

현대 CPU는 **분기 예측기(Branch Predictor)**를 사용하지만, 가상 함수 호출은 간접 점프이므로 예측이 어렵습니다.

CPU 마이크로아키텍처와의 상호작용

1. 캐시 미스 (Cache Miss)

vtable은 별도의 메모리 영역에 저장됩니다. 많은 다형적 객체를 순회할 때:

std::vector<std::unique_ptr<Shape>> shapes;
for (auto& shape : shapes) {
    shape->draw(); // 매번 vtable 접근 → 캐시 미스 가능성
}

메모리 접근 패턴:

객체 1의 메모리 → vtable 1 → 함수 1
객체 2의 메모리 → vtable 2 → 함수 2
객체 3의 메모리 → vtable 1 → 함수 1
...

vtable이 **L1 캐시(~4 사이클)**에 있으면 빠르지만, L3 캐시(~40 사이클) 또는 **메인 메모리(~200 사이클)**에 있으면 매우 느립니다.

2. 파이프라인 스톨 (Pipeline Stall)

현대 CPU는 슈퍼스칼라(Superscalar) 파이프라인을 사용하여 여러 명령어를 병렬로 실행합니다. 하지만 가상 함수 호출은:

Fetch → Decode → Execute → Memory → Writeback
                    ↓
            간접 점프 대상을 알 수 없음
                    ↓
            파이프라인을 비워야 함 (flush)

이는 10~20 사이클의 지연을 유발할 수 있습니다.

3. 분기 예측 실패 (Branch Misprediction)

CPU는 **BTB(Branch Target Buffer)**를 사용하여 간접 점프를 예측합니다. 하지만 다형적 컬렉션에서:

std::vector<std::unique_ptr<Shape>> shapes = {
    std::make_unique<Circle>(),
    std::make_unique<Rectangle>(),
    std::make_unique<Circle>(),
    std::make_unique<Triangle>(),
    // ...
};

타입이 자주 바뀌면 예측 실패율이 높아집니다. Intel의 연구에 따르면, 분기 예측 실패는 평균 15~20 사이클의 페널티를 발생시킵니다.

메모리 레이아웃 상세

객체의 메모리 구조:

class Base {
    int x;
    virtual void foo();
    virtual void bar();
};

class Derived : public Base {
    int y;
    void foo() override;
};

메모리 레이아웃 (64비트 시스템):

Base 객체:
+0: vptr (8바이트) → Base::vtable
+8: x (4바이트)
+12: padding (4바이트, 정렬을 위해)
총 크기: 16바이트

Derived 객체:
+0: vptr (8바이트) → Derived::vtable
+8: x (4바이트, Base로부터 상속)
+12: y (4바이트)
총 크기: 16바이트

Base::vtable:
+0: Base::foo 주소
+8: Base::bar 주소

Derived::vtable:
+0: Derived::foo 주소 (오버라이드됨!)
+8: Base::bar 주소 (상속됨)

다중 상속의 복잡성:

class A {
    int a;
    virtual void foo();
};

class B {
    int b;
    virtual void bar();
};

class C : public A, public B {
    int c;
    void foo() override;
    void bar() override;
};

C 객체의 메모리 레이아웃:

+0: vptr_A → C::vtable_A
+8: a
+12: padding
+16: vptr_B → C::vtable_B
+24: b
+28: padding
+32: c
총 크기: 40바이트 (두 개의 vptr!)

다중 상속 시 타입 캐스팅에는 **포인터 조정(pointer adjustment)**이 필요합니다:

C* c = new C();
B* b = c; // 컴파일러가 포인터를 16바이트 증가시킴!

생성된 어셈블리:

mov rax, [rbp - 8]  ; C* c
add rax, 16         ; B의 서브객체로 조정
mov [rbp - 16], rax ; B* b

수학적 기초: 타입 시스템과 함수 공간

오버로딩은 **함수 공간의 분할(Partition)**로 이해할 수 있습니다.

함수의 타입:

f: A → B

여기서 A는 정의역(domain), B는 치역(codomain)입니다.

오버로딩된 함수 집합:

int    add(int, int);
double add(double, double);
string add(string, string);

이는 수학적으로:

add: (ℤ × ℤ → ℤ) ∪ (ℝ × ℝ → ℝ) ∪ (String × String → String)

각 오버로드는 **서로소 집합(disjoint sets)**의 정의역을 가지므로, 컴파일러는 인자의 타입을 보고 유일한 함수를 선택할 수 있습니다.

Overload Resolution Algorithm:

1. Candidate Functions: 이름이 일치하는 모든 함수
2. Viable Functions: 인자 개수가 맞고 각 인자가 변환 가능한 함수
3. Best Match: 가장 적은 변환이 필요한 함수

예:

void f(int);
void f(double);
void f(long);

f(3.14f); // float → double 변환 (승격)
          // float → int 변환 (narrowing)
          // float → long 변환 (narrowing)
          // 결과: f(double) 선택 (승격이 narrowing보다 우선)

**오버라이딩과 동적 디스패치는 서브타입 다형성(Subtype Polymorphism)**입니다.

리스코프 치환 원칙(Liskov Substitution Principle):

S <: T (S는 T의 서브타입) 
⇒ ∀f: T → U, ∀x: S, f(x)는 타입 안전

즉, 파생 클래스는 기반 클래스를 대체할 수 있어야 합니다.

최적화 기법: Devirtualization

1. Final Classes와 함수

C++11의 final 키워드는 컴파일러에게 더 이상 오버라이드가 없음을 알려줍니다:

class Shape {
public:
    virtual void draw() const = 0;
};

class Circle final : public Shape {
public:
    void draw() const override final {
        // ...
    }
};

void render(const Circle& c) {
    c.draw(); // 가상 함수 호출이지만, 컴파일러가 직접 호출로 최적화 가능!
}

2. Whole Program Optimization

링크 타임에 전체 프로그램을 분석하여:

// file1.cpp
class Base {
public:
    virtual void foo();
};

// file2.cpp
void callFoo(Base* b) {
    b->foo();
}

// main.cpp
int main() {
    Base b;
    callFoo(&b); // 실제로는 Base 타입만 사용됨
}

컴파일러가 Base를 상속하는 클래스가 없음을 발견하면, 가상 함수를 일반 함수로 변환할 수 있습니다.

3. Profile-Guided Optimization (PGO)

프로파일링 데이터를 사용하여:

• 가장 자주 호출되는 타입을 인라이닝
• 드물게 호출되는 타입을 out-of-line으로 처리

// 프로파일링 결과: 90% Circle, 10% Rectangle
void render(Shape* s) {
    if (auto* c = dynamic_cast<Circle*>(s)) {
        // 인라이닝된 Circle::draw()
    } else {
        s->draw(); // 가상 함수 호출
    }
}

최신 C++ 표준의 개선

C++20: Concepts를 사용한 오버로딩 개선

#include <concepts>

template<typename T>
concept SmallType = sizeof(T) <= 16;

template<typename T>
concept LargeType = sizeof(T) > 16;

// 작은 타입은 값으로 전달
template<SmallType T>
void process(T value) {
    // ...
}

// 큰 타입은 const 참조로 전달
template<LargeType T>
void process(const T& value) {
    // ...
}

C++23: Deducing This (Explicit Object Parameter)

struct Widget {
    // 하나의 함수로 4가지 오버로드를 대체!
    void process(this auto&& self) {
        // self는 Widget&, const Widget&, Widget&&, const Widget&& 모두 가능
    }
};

이는 코드 중복을 극적으로 줄이고, **완벽한 전달(perfect forwarding)**을 단순화합니다.

실제 코드 예제: 완전한 구현

마지막으로, 오버로딩과 오버라이딩을 모두 사용하는 완전한 예제를 봅시다:

#include <iostream>
#include <vector>
#include <memory>
#include <cmath>
#include <concepts>

// ============== 오버로딩 예제 ==============

// Concepts를 사용한 템플릿 오버로딩 (C++20)
template<typename T>
concept Numeric = std::integral<T> || std::floating_point<T>;

class Math {
public:
    // 1. 매개변수 개수로 오버로딩
    static double distance(double x1, double y1, double x2, double y2) {
        return std::sqrt((x2-x1)*(x2-x1) + (y2-y1)*(y2-y1));
    }
    
    static double distance(double x1, double y1, double z1, 
                          double x2, double y2, double z2) {
        return std::sqrt((x2-x1)*(x2-x1) + (y2-y1)*(y2-y1) + (z2-z1)*(z2-z1));
    }
    
    // 2. 타입으로 오버로딩 (Concepts 사용)
    template<std::integral T>
    static T clamp(T value, T min, T max) {
        std::cout << "[Integer clamp] ";
        return value < min ? min : (value > max ? max : value);
    }
    
    template<std::floating_point T>
    static T clamp(T value, T min, T max) {
        std::cout << "[Float clamp] ";
        return value < min ? min : (value > max ? max : value);
    }
};

// 연산자 오버로딩
class Vector2D {
    double x, y;
public:
    Vector2D(double x = 0, double y = 0) : x(x), y(y) {}
    
    // 산술 연산자 오버로딩
    Vector2D operator+(const Vector2D& other) const {
        return {x + other.x, y + other.y};
    }
    
    Vector2D operator*(double scalar) const {
        return {x * scalar, y * scalar};
    }
    
    // 출력 연산자 오버로딩
    friend std::ostream& operator<<(std::ostream& os, const Vector2D& v) {
        return os << "(" << v.x << ", " << v.y << ")";
    }
};

// ============== 오버라이딩 예제 ==============

// 기반 클래스
class Shape {
protected:
    std::string name;
public:
    explicit Shape(std::string n) : name(std::move(n)) {}
    virtual ~Shape() = default;
    
    // 순수 가상 함수
    virtual double area() const = 0;
    virtual double perimeter() const = 0;
    virtual void draw() const = 0;
    
    // 일반 가상 함수
    virtual void describe() const {
        std::cout << "Shape: " << name << "\n";
    }
};

class Circle : public Shape {
    double radius;
public:
    explicit Circle(double r) : Shape("Circle"), radius(r) {}
    
    // 오버라이딩
    double area() const override {
        return 3.14159 * radius * radius;
    }
    
    double perimeter() const override {
        return 2 * 3.14159 * radius;
    }
    
    void draw() const override {
        std::cout << "Drawing a circle with radius " << radius << "\n";
    }
    
    void describe() const override {
        Shape::describe(); // 기반 클래스 함수 호출
        std::cout << "  Radius: " << radius << "\n";
    }
};

class Rectangle : public Shape {
    double width, height;
public:
    Rectangle(double w, double h) : Shape("Rectangle"), width(w), height(h) {}
    
    double area() const override {
        return width * height;
    }
    
    double perimeter() const override {
        return 2 * (width + height);
    }
    
    void draw() const override {
        std::cout << "Drawing a rectangle " << width << "x" << height << "\n";
    }
    
    void describe() const override {
        Shape::describe();
        std::cout << "  Dimensions: " << width << "x" << height << "\n";
    }
};

// ============== 오버로딩 + 오버라이딩 결합 ==============

class Renderer {
public:
    // 오버로딩: 다양한 타입의 렌더링
    virtual void render(const Shape& shape) {
        std::cout << "[Base Renderer] ";
        shape.draw();
    }
    
    virtual void render(const std::vector<std::unique_ptr<Shape>>& shapes) {
        std::cout << "[Base Renderer] Rendering " << shapes.size() << " shapes:\n";
        for (const auto& shape : shapes) {
            render(*shape);
        }
    }
    
    virtual ~Renderer() = default;
};

class OpenGLRenderer : public Renderer {
public:
    // 오버라이딩: OpenGL 특화 렌더링
    void render(const Shape& shape) override {
        std::cout << "[OpenGL] ";
        shape.draw();
        std::cout << "  (using OpenGL context)\n";
    }
    
    void render(const std::vector<std::unique_ptr<Shape>>& shapes) override {
        std::cout << "[OpenGL] Batch rendering " << shapes.size() << " shapes:\n";
        for (const auto& shape : shapes) {
            render(*shape);
        }
    }
};

// ============== 메인 함수 ==============

int main() {
    std::cout << "=== Overloading 예제 ===\n\n";
    
    // 매개변수 개수로 구분
    std::cout << "2D distance: " << Math::distance(0, 0, 3, 4) << "\n";
    std::cout << "3D distance: " << Math::distance(0, 0, 0, 1, 1, 1) << "\n\n";
    
    // 타입으로 구분
    std::cout << Math::clamp(5, 0, 10) << "\n";
    std::cout << Math::clamp(5.7, 0.0, 10.0) << "\n\n";
    
    // 연산자 오버로딩
    Vector2D v1(3, 4);
    Vector2D v2(1, 2);
    std::cout << "v1 + v2 = " << (v1 + v2) << "\n";
    std::cout << "v1 * 2 = " << (v1 * 2) << "\n\n";
    
    std::cout << "=== Overriding 예제 ===\n\n";
    
    // 다형성
    std::vector<std::unique_ptr<Shape>> shapes;
    shapes.push_back(std::make_unique<Circle>(5.0));
    shapes.push_back(std::make_unique<Rectangle>(4.0, 6.0));
    shapes.push_back(std::make_unique<Circle>(3.0));
    
    for (const auto& shape : shapes) {
        shape->describe();
        std::cout << "  Area: " << shape->area() << "\n";
        std::cout << "  Perimeter: " << shape->perimeter() << "\n";
        shape->draw();
        std::cout << "\n";
    }
    
    std::cout << "=== Overloading + Overriding 결합 ===\n\n";
    
    // 기본 렌더러
    Renderer baseRenderer;
    baseRenderer.render(shapes);
    std::cout << "\n";
    
    // OpenGL 렌더러 (오버라이딩)
    OpenGLRenderer glRenderer;
    glRenderer.render(shapes);
    
    // 다형적 사용
    Renderer* renderer = &glRenderer;
    std::cout << "\n=== 다형적 렌더링 ===\n";
    renderer->render(shapes); // 런타임에 OpenGLRenderer::render 호출!
    
    return 0;
}

컴파일 및 실행:

# C++20 표준으로 컴파일
g++ -std=c++20 -O2 -o example example.cpp
./example

---

결론: 미시에서 거시로, 그리고 다시 미시로

오버로딩과 오버라이딩은 단순한 문법적 기능이 아닙니다. 이들은 **소프트웨어 공학의 가장 근본적인 문제 - "변화를 어떻게 관리할 것인가?"**에 대한 서로 다른 해답입니다.

오버로딩은 컴파일 타임의 명확성을 추구합니다. 모든 것이 결정되고, 최적화되며, 예측 가능합니다. 이는 수학적 정확성과 기계의 효율성을 중시하는 C++의 철학을 반영합니다.

오버라이딩은 런타임의 유연성을 추구합니다. 확장 가능하고, 플러그 가능하며, 진화할 수 있습니다. 이는 변화하는 세계에 적응해야 하는 소프트웨어의 현실을 반영합니다.

그리고 놀랍게도, 이 두 개념은 하드웨어 레벨의 트랜지스터와 레지스터에서부터 글로벌 소프트웨어 생태계에 이르기까지 모든 추상화 계층에서 작동합니다. 한 줄의 virtual 키워드가 수십억 달러의 산업을 가능하게 하고, Name Mangling의 정교함이 개발자의 생산성을 수백 배 향상시킵니다.

이것이 바로 컴퓨터 과학의 아름다움입니다: 미시적 최적화가 거시적 혁신으로 이어지고, 거시적 설계가 다시 미시적 구현의 세부사항을 결정하는 끝없는 순환. 오버로딩과 오버라이딩은 그 순환의 완벽한 예시입니다.