C++ Composite 패턴: 파일 시스템·UI 트리를 하나의 인터페이스로 다루기

부분과 전체를 같은 인터페이스로 다루기

트리·부분-전체를 한 인터페이스로 묶는 흐름은 구조 패턴 시리즈의 다른 패턴들과 비교해 읽으면 좋습니다.

파일과 폴더를 따로 처리할 때 생기는 분기

문제: 파일과 폴더를 다른 방식으로 처리하면 코드가 복잡해집니다.

// 나쁜 설계: 타입 체크 필요
void printSize(FileSystemItem* item) {
    if (auto* file = dynamic_cast<File*>(item)) {
        std::cout << file->getSize() << '\n';
    } else if (auto* folder = dynamic_cast<Folder*>(item)) {
        for (auto& child : folder->getChildren()) {
            printSize(child);  // 재귀
        }
    }
}

해결: Composite 패턴은 leaf(파일)와 composite(폴더)를 동일한 인터페이스로 다룹니다.

// 좋은 설계: Composite
// 타입 정의
class Component {
public:
    virtual int getSize() const = 0;  // 통일된 인터페이스
};
class File : public Component {
    int size_;
public:
    int getSize() const override { return size_; }
};
class Folder : public Component {
    std::vector<std::shared_ptr<Component>> children_;
public:
    int getSize() const override {
        int total = 0;
        for (const auto& child : children_)
            total += child->getSize();  // 재귀
        return total;
    }
};

flowchart TD
    client[Client]
    component["Component<br/>(getSize)"]
    leaf["Leaf<br/>(File)"]
    composite["Composite<br/>(Folder)"]
    
    client --> component
    leaf -.implements.-> component
    composite -.implements.-> component
    composite --> component

“나쁜 설계” 코드의 진짜 문제는 dynamic_cast 자체보다 분기가 흩어진다는 것입니다. 크기 계산, 출력, 검색, 복사 같은 기능마다 똑같은 if (File) ... else if (Folder) 분기가 반복되고, 나중에 심볼릭 링크나 압축 파일 같은 세 번째 타입이 생기면 그 분기를 전부 찾아 고쳐야 합니다. 하나라도 빠뜨리면 컴파일러는 아무 말도 하지 않고, 새 타입은 그 함수에서 조용히 무시됩니다. Composite는 “크기를 구하는 방법”을 각 타입 안으로 옮겨서, 새 타입은 인터페이스만 구현하면 모든 순회 코드에서 자동으로 동작하게 만듭니다.

다이어그램에서 composite --> component 화살표가 이 패턴의 핵심입니다. Composite는 자식을 구체 타입이 아닌 Component로 보관합니다. 그래서 폴더 안에 파일이 들어갈 수도, 또 다른 폴더가 들어갈 수도 있고, 깊이 제한 없이 트리가 만들어집니다. 클라이언트 입장에서는 루트 하나에 getSize()를 호출하면 끝이고, 재귀는 트리 구조 자체가 처리합니다.

---

Component·Leaf·Composite 기본 구조

#include <algorithm>
#include <vector>
#include <memory>
#include <iostream>
class Component {
public:
    virtual void operation() const = 0;
    virtual void add(std::shared_ptr<Component>) {}
    virtual void remove(std::shared_ptr<Component>) {}
    virtual ~Component() = default;
};
// Leaf: 자식 없음
class Leaf : public Component {
    int id_;
public:
    explicit Leaf(int id) : id_(id) {}
    void operation() const override {
        std::cout << "Leaf " << id_ << '\n';
    }
};
// Composite: 자식 목록 보유
class Composite : public Component {
    std::vector<std::shared_ptr<Component>> children_;
public:
    void add(std::shared_ptr<Component> c) override {
        children_.push_back(std::move(c));
    }
    void remove(std::shared_ptr<Component> c) override {
        children_.erase(
            std::remove(children_.begin(), children_.end(), c),
            children_.end()
        );
    }
    void operation() const override {
        std::cout << "Composite [\n";
        for (const auto& c : children_)
            c->operation();
        std::cout << "]\n";
    }
};
int main() {
    auto root = std::make_shared<Composite>();
    root->add(std::make_shared<Leaf>(1));
    
    auto branch = std::make_shared<Composite>();
    branch->add(std::make_shared<Leaf>(2));
    branch->add(std::make_shared<Leaf>(3));
    root->add(branch);
    
    root->operation();
    // 출력:
    // Composite [
    // Leaf 1
    // Composite [
    // Leaf 2
    // Leaf 3
    // ]
    // ]
    return 0;
}

이 기본 구조에서 결정해야 하는 것이 세 가지 있습니다.

add/remove를 어디에 둘 것인가. 위 코드는 Component에 빈 기본 구현을 두는 “투명성(transparency)” 방식입니다. 클라이언트가 모든 노드를 같은 타입으로 다룰 수 있는 대신, Leaf에 add를 호출해도 컴파일러가 막지 못합니다. 반대로 다음 절의 파일 시스템 예제는 add를 Folder에만 두는 “안전성(safety)” 방식입니다. GoF 원서도 두 방식의 트레이드오프를 설명할 뿐 정답을 정하지 않습니다. 트리를 조립하는 코드가 구체 타입을 알고 있다면 안전성 쪽이 대부분 낫습니다.

소유권을 무엇으로 표현할 것인가. 예제는 shared_ptr을 쓰지만, 트리는 본질적으로 부모가 자식을 단독 소유하는 구조라 unique_ptr이 더 정확한 경우가 많습니다. shared_ptr은 같은 노드를 두 부모에 붙이는 것을 허용해 버려서, 한쪽에서 수정하면 다른 쪽 트리도 바뀌는 의도치 않은 공유가 생깁니다. 노드를 여러 곳에서 참조해야 하거나(예: UI 이벤트 핸들러가 위젯을 잡고 있는 경우) 트리 밖으로 노드를 넘겨야 할 때만 shared_ptr을 고르세요.

remove의 비교 기준. std::remove는 shared_ptr끼리 ==로 비교하므로 같은 객체를 가리키는 포인터만 지웁니다. 내용이 같은 다른 객체는 지워지지 않습니다. 또 std::remove는 원소를 뒤로 밀어 둘 뿐이라 반드시 erase와 함께 써야 하는데, 위 코드는 이 erase-remove 관용구를 지키고 있습니다.

---

파일과 폴더 크기를 재귀로 계산하기

#include <vector>
#include <memory>
#include <iostream>
#include <string>
class FileSystemItem {
public:
    virtual int getSize() const = 0;
    virtual void print(int indent = 0) const = 0;
    virtual ~FileSystemItem() = default;
};
class File : public FileSystemItem {
    std::string name_;
    int size_;
public:
    File(std::string name, int size) : name_(std::move(name)), size_(size) {}
    
    int getSize() const override { return size_; }
    
    void print(int indent = 0) const override {
        std::cout << std::string(indent, ' ') << "File: " << name_ 
                  << " (" << size_ << " bytes)\n";
    }
};
class Folder : public FileSystemItem {
    std::string name_;
    std::vector<std::shared_ptr<FileSystemItem>> children_;
public:
    explicit Folder(std::string name) : name_(std::move(name)) {}
    
    void add(std::shared_ptr<FileSystemItem> item) {
        children_.push_back(std::move(item));
    }
    
    int getSize() const override {
        int total = 0;
        for (const auto& child : children_)
            total += child->getSize();
        return total;
    }
    
    void print(int indent = 0) const override {
        std::cout << std::string(indent, ' ') << "Folder: " << name_ 
                  << " (" << getSize() << " bytes total)\n";
        for (const auto& child : children_)
            child->print(indent + 2);
    }
};
int main() {
    auto root = std::make_shared<Folder>("root");
    root->add(std::make_shared<File>("readme.txt", 100));
    
    auto src = std::make_shared<Folder>("src");
    src->add(std::make_shared<File>("main.cpp", 500));
    src->add(std::make_shared<File>("utils.cpp", 300));
    root->add(src);
    
    auto docs = std::make_shared<Folder>("docs");
    docs->add(std::make_shared<File>("manual.pdf", 2000));
    root->add(docs);
    
    root->print();
    // 출력:
    // Folder: root (2900 bytes total)
    //   File: readme.txt (100 bytes)
    //   Folder: src (800 bytes total)
    //     File: main.cpp (500 bytes)
    //     File: utils.cpp (300 bytes)
    //   Folder: docs (2000 bytes total)
    //     File: manual.pdf (2000 bytes)
    
    return 0;
}

핵심: getSize()가 재귀적으로 호출되어 전체 트리의 크기를 계산합니다.

이 예제에는 눈에 잘 띄지 않는 비용이 하나 있습니다. Folder::print()가 자기 줄을 찍을 때 getSize()를 호출하고, 그 getSize()는 하위 트리 전체를 다시 순회합니다. 그런 다음 자식마다 print()를 호출하면 자식 폴더도 또 자기 하위 트리를 순회합니다. 결국 깊이가 d인 파일은 d번 방문되어, 트리가 깊고 넓어지면 출력 한 번에 O(N·d)의 비용이 듭니다. 수십 개 노드에서는 문제가 없지만 실제 디스크처럼 수십만 개 항목을 다루면 체감됩니다. 해결책은 두 가지입니다. 한 번의 후위 순회로 크기를 계산해 반환하면서 출력하거나, 폴더마다 크기를 캐싱해 두고 자식이 추가·삭제될 때만 무효화하는 것입니다. 캐싱을 택하면 자식 변경을 부모에게 알려야 하므로 부모 포인터가 필요해지고, 설계가 한 단계 복잡해집니다.

int로 크기를 합산하는 것도 실제 파일 시스템이라면 바꿔야 합니다. 2GB를 넘는 순간 오버플로가 나므로 std::uintmax_t(std::filesystem::file_size의 반환 타입)를 쓰는 편이 맞습니다.

---

GUI 위젯 트리 그리기

#include <vector>
#include <memory>
#include <iostream>
#include <string>
class Widget {
public:
    virtual void render() const = 0;
    virtual void add(std::shared_ptr<Widget>) {}
    virtual ~Widget() = default;
};
class Button : public Widget {
    std::string label_;
public:
    explicit Button(std::string label) : label_(std::move(label)) {}
    
    void render() const override {
        std::cout << "[Button: " << label_ << "]\n";
    }
};
class Label : public Widget {
    std::string text_;
public:
    explicit Label(std::string text) : text_(std::move(text)) {}
    
    void render() const override {
        std::cout << "Label: " << text_ << '\n';
    }
};
class Panel : public Widget {
    std::string title_;
    std::vector<std::shared_ptr<Widget>> children_;
public:
    explicit Panel(std::string title) : title_(std::move(title)) {}
    
    void add(std::shared_ptr<Widget> widget) override {
        children_.push_back(std::move(widget));
    }
    
    void render() const override {
        std::cout << "=== Panel: " << title_ << " ===\n";
        for (const auto& child : children_)
            child->render();
        std::cout << "===================\n";
    }
};
int main() {
    auto mainPanel = std::make_shared<Panel>("Main Window");
    mainPanel->add(std::make_shared<Label>("Welcome!"));
    
    auto buttonPanel = std::make_shared<Panel>("Actions");
    buttonPanel->add(std::make_shared<Button>("OK"));
    buttonPanel->add(std::make_shared<Button>("Cancel"));
    mainPanel->add(buttonPanel);
    
    mainPanel->render();
    // 출력:
    // === Panel: Main Window ===
    // Label: Welcome!
    // === Panel: Actions ===
    // [Button: OK]
    // [Button: Cancel]
    // ===================
    // ===================
    
    return 0;
}

핵심: Panel은 다른 Panel이나 Button을 포함할 수 있어 중첩된 UI 계층을 표현합니다.

실제 GUI 프레임워크(Qt의 QWidget, 웹 브라우저의 DOM)도 이 구조를 씁니다. 다만 실무의 위젯 트리에는 예제에 없는 요구가 두 가지 더 붙습니다. 첫째, 렌더링은 위에서 아래로, 이벤트는 아래에서 위로 흐릅니다. 버튼을 클릭하면 버튼이 먼저 처리하고 처리하지 않으면 부모 패널로 이벤트를 올려 보내야 하므로 자식이 부모를 알아야 합니다. 이때 부모 참조를 shared_ptr로 두면 부모와 자식이 서로를 소유해 순환 참조가 생기므로, 부모 쪽은 반드시 weak_ptr이나 원시 포인터(부모가 자식보다 오래 산다는 보장이 있을 때)로 둡니다. 둘째, 레이아웃 계산처럼 자식의 결과를 부모가 모아야 하는 연산이 많아, render()처럼 결과 없이 순회하는 연산보다 getSize()처럼 값을 합성하는 연산이 더 자주 등장합니다.

---

Leaf의 add()·순환 참조·소유권 문제

Leaf에 add()를 호출했을 때

// ❌ 나쁜 예: 기반 클래스에 빈 add()가 있는 설계(1장, 3장 방식)에서
// Leaf에 add() 호출 시 무시됨
auto file = std::make_shared<File>("test.txt", 100);
file->add(anotherFile);  // 아무 일도 안 일어남

이 문제는 기본 구조의 Component나 GUI 위젯 트리의 Widget처럼 기반 클래스에 빈 add()를 둔 설계에서만 생깁니다. 파일 시스템 예제의 FileSystemItem처럼 add()가 Folder에만 있다면 위 코드는 애초에 “‘class File’ has no member named ‘add‘“로 컴파일되지 않습니다. 빈 기본 구현이 위험한 이유는, 파일을 폴더로 착각해 자식을 붙인 코드가 에러 없이 지나가고 추가한 항목이 사라지는 형태로 나중에 발견되기 때문입니다.

해결: Leaf의 add()에서 예외를 던지거나, 타입 체크를 추가하세요.

// ✅ 좋은 예: 예외 던지기
class File : public FileSystemItem {
public:
    void add(std::shared_ptr<FileSystemItem>) override {
        throw std::logic_error("Cannot add to a file");
    }
};

(이 코드는 FileSystemItem에 virtual void add(std::shared_ptr<FileSystemItem>)가 선언되어 있다고 가정하며, <stdexcept>가 필요합니다.) 예외를 던지면 최소한 실수가 조용히 묻히지는 않지만, 여전히 런타임에야 발견됩니다. 더 확실한 방법은 기반 클래스에 virtual Folder* asComposite() { return nullptr; } 같은 질의 함수를 두고 Composite에서만 this를 반환하게 해서, 호출자가 자식을 붙이기 전에 확인하게 만드는 것입니다. GoF 책이 소개하는 GetComposite() 방식이 이것입니다.

자식이 부모를 shared_ptr로 참조하는 순환

// ❌ 나쁜 예: 순환 참조
auto folder1 = std::make_shared<Folder>("A");
auto folder2 = std::make_shared<Folder>("B");
folder1->add(folder2);
folder2->add(folder1);  // 순환!

해결: 부모 포인터를 추가하여 순환을 감지하거나, weak_ptr을 사용하세요.

// ✅ 좋은 예: 부모 체크
class Folder : public FileSystemItem {
    std::weak_ptr<Folder> parent_;
public:
    void add(std::shared_ptr<FileSystemItem> item) {
        // 순환 체크 로직
        children_.push_back(std::move(item));
    }
};

순환이 생기면 두 가지 일이 동시에 벌어집니다. 첫째, getSize()나 print()가 A → B → A → B …로 끝없이 재귀하다가 스택 오버플로로 프로그램이 죽습니다(Linux에서는 “Segmentation fault”, Windows에서는 0xC00000FD). 둘째, A와 B가 서로를 shared_ptr로 붙잡고 있어서 바깥 변수가 모두 사라져도 참조 카운트가 0이 되지 않아 둘 다 영원히 해제되지 않습니다.

위 코드의 주석 “순환 체크 로직”을 실제로 채우는 방법은 이렇습니다. 새로 추가할 항목이 폴더라면, this에서 시작해 parent_를 따라 루트까지 올라가며 그 폴더가 조상 중에 있는지(또는 this 자신인지) 확인하고, 있으면 추가를 거부합니다. 부모 사슬만 확인하면 되므로 트리 깊이만큼의 비용이면 충분합니다. 여기서 parent_를 weak_ptr로 두는 이유는 부모 방향의 참조가 소유권을 갖지 않게 하기 위해서입니다. weak_ptr 자체가 순환을 막아 주는 것은 아니고, 순환 검사는 별도로 해야 합니다. 부모를 설정하려면 add 안에서 자식의 parent_에 자기 자신을 넣어야 하므로 Folder가 std::enable_shared_from_this<Folder>를 상속하고 shared_from_this()를 써야 합니다. 이 함수는 객체가 이미 shared_ptr로 관리되고 있을 때만 동작하고, 스택에 만든 객체에서 호출하면 std::bad_weak_ptr 예외가 납니다.

unique_ptr로 자식을 소유하는 설계라면 이 문제가 구조적으로 사라집니다. 노드를 한 부모에 넘기면(std::move) 호출자는 더 이상 그 노드를 들고 있지 않으므로, 같은 노드를 자기 후손에 다시 붙이는 코드를 쓰기가 훨씬 어려워집니다. 저는 트리의 공유가 필요하다는 확실한 이유가 없는 한 unique_ptr 자식 + 원시 포인터 부모 조합으로 시작하는 편이고, 순환 참조 버그를 가장 확실하게 막는 방법이 이것이었습니다.

raw 포인터 자식의 메모리 누수

// ❌ 나쁜 예: raw pointer 사용
class Composite {
    std::vector<Component*> children_;  // 누수 위험
};

해결: std::shared_ptr 또는 std::unique_ptr을 사용하세요.

// ✅ 좋은 예
class Composite {
    std::vector<std::shared_ptr<Component>> children_;
};

---

Visitor·Iterator와 함께 쓰기

Visitor로 트리 연산 분리

class Visitor {
public:
    virtual void visitFile(File* file) = 0;
    virtual void visitFolder(Folder* folder) = 0;
};
class SizeCalculator : public Visitor {
    int total_ = 0;
public:
    void visitFile(File* file) override { total_ += file->getSize(); }
    void visitFolder(Folder* folder) override {
        for (auto& child : folder->getChildren())
            child->accept(this);
    }
    int getTotal() const { return total_; }
};

이 코드가 동작하려면 FileSystemItem에 virtual void accept(Visitor*) = 0;이 있고, File::accept는 v->visitFile(this), Folder::accept는 v->visitFolder(this)를 호출해야 합니다. 이 “이중 디스패치”로 방문자가 노드의 실제 타입에 맞는 함수를 받게 됩니다. Visitor를 붙이는 이유는 연산을 트리 클래스 밖으로 빼기 위해서입니다. Composite만 쓰면 크기 계산, 검색, 직렬화, 권한 검사 같은 연산이 늘 때마다 모든 노드 클래스에 가상 함수를 추가해야 하는데, Visitor를 쓰면 연산 하나가 방문자 클래스 하나가 됩니다. 대신 반대 방향의 비용이 생겨서, 새 노드 타입을 추가하면 모든 방문자에 함수를 추가해야 합니다. 노드 종류는 거의 고정이고 연산이 자주 늘어나는 도메인(컴파일러의 AST가 대표적)에 잘 맞습니다. 노드 타입 집합이 닫혀 있다면 C++17의 std::variant와 std::visit로 같은 효과를 얻는 방법도 있습니다.

Iterator로 트리 순회 감추기

class Composite {
    std::vector<std::shared_ptr<Component>> children_;
public:
    auto begin() { return children_.begin(); }
    auto end() { return children_.end(); }
};
// 사용
for (auto& child : composite) {
    child->operation();
}

이 방식은 직계 자식만 순회합니다. 트리 전체를 깊이 우선으로 훑는 반복자가 필요하다면 명시적인 스택(std::vector<Component*>)에 방문할 노드를 쌓아 두는 반복자를 만들어야 합니다. 재귀 대신 명시적 스택을 쓰면 트리가 수만 단계로 깊어져도 호출 스택이 넘치지 않고, 순회를 중간에 멈췄다가 이어갈 수도 있습니다. 또 내부 vector의 반복자를 그대로 노출하면 호출자가 순회 중에 add를 호출해 반복자가 무효화되는 문제가 생길 수 있으니, 읽기 전용이면 const 버전만 공개하는 편이 안전합니다.

---

조직도 시스템 만들기

#include <vector>
#include <memory>
#include <iostream>
#include <string>
class Employee {
public:
    virtual void showDetails(int indent = 0) const = 0;
    virtual int getSalary() const = 0;
    virtual void add(std::shared_ptr<Employee>) {}
    virtual ~Employee() = default;
};
class Developer : public Employee {
    std::string name_;
    int salary_;
public:
    Developer(std::string name, int salary) 
        : name_(std::move(name)), salary_(salary) {}
    
    void showDetails(int indent = 0) const override {
        std::cout << std::string(indent, ' ') << "Developer: " << name_ 
                  << " ($" << salary_ << ")\n";
    }
    
    int getSalary() const override { return salary_; }
};
class Manager : public Employee {
    std::string name_;
    int salary_;
    std::vector<std::shared_ptr<Employee>> team_;
public:
    Manager(std::string name, int salary) 
        : name_(std::move(name)), salary_(salary) {}
    
    void add(std::shared_ptr<Employee> emp) override {
        team_.push_back(std::move(emp));
    }
    
    void showDetails(int indent = 0) const override {
        std::cout << std::string(indent, ' ') << "Manager: " << name_ 
                  << " ($" << salary_ << ") - Team size: " << team_.size() << '\n';
        for (const auto& emp : team_)
            emp->showDetails(indent + 2);
    }
    
    int getSalary() const override {
        int total = salary_;
        for (const auto& emp : team_)
            total += emp->getSalary();
        return total;
    }
};
int main() {
    auto ceo = std::make_shared<Manager>("Alice", 150000);
    
    auto engManager = std::make_shared<Manager>("Bob", 120000);
    engManager->add(std::make_shared<Developer>("Charlie", 80000));
    engManager->add(std::make_shared<Developer>("David", 85000));
    ceo->add(engManager);
    
    auto salesManager = std::make_shared<Manager>("Eve", 110000);
    salesManager->add(std::make_shared<Developer>("Frank", 70000));
    ceo->add(salesManager);
    
    ceo->showDetails();
    std::cout << "\nTotal company payroll: $" << ceo->getSalary() << '\n';
    
    // 출력:
    // Manager: Alice ($150000) - Team size: 2
    //   Manager: Bob ($120000) - Team size: 2
    //     Developer: Charlie ($80000)
    //     Developer: David ($85000)
    //   Manager: Eve ($110000) - Team size: 1
    //     Developer: Frank ($70000)
    //
    // Total company payroll: $615000
    
    return 0;
}

조직도 예제는 Composite가 Leaf와 자신의 데이터도 함께 가진다는 점이 파일 시스템 예제와 다릅니다. 폴더는 자기 크기가 없고 자식 합만 반환하지만, Manager는 자기 급여에 팀원 급여를 더합니다. 합산 연산을 설계할 때 “Composite 자신의 값을 포함하는가”를 명확히 정해 두지 않으면 합계가 중복되거나 빠지는 버그가 생깁니다. 또 현실의 조직은 한 사람이 두 팀에 걸치는 겸직이 있어 순수한 트리가 아니게 되는데, 이 경우 같은 Developer를 두 매니저에 add하면 총 급여가 두 번 합산됩니다. 트리 구조가 깨지는 도메인이라면 Composite보다 그래프 모델과 방문 기록(visited set)이 필요합니다.

---

Composite 패턴 요약

항목	설명
목적	leaf와 composite를 동일 인터페이스로 재귀 처리
장점	트리 구조를 일관된 API로 다룸, 새 종류의 node 추가 용이, 클라이언트 코드 단순화
단점	leaf에 의미 없는 add 등 메서드 노출, 타입 안전성 약화 가능
사용 시기	파일 시스템, UI 계층, 조직도, 메뉴 구조 등 트리 형태 데이터

관련 글: Adapter 패턴, Decorator 패턴, 반복자 가이드, Visitor 패턴, Flyweight 패턴. Composite 패턴으로 폴더/파일·메뉴 계층·조직도처럼 트리 구조를 같은 인터페이스로 재귀적으로 다룰 수 있습니다.

---

같이 보면 좋은 글

• C++ Adapter 패턴
• C++ Decorator 패턴
• C++ 반복자
• C++ Visitor 패턴: 더블 디스패치와 std::variant + std::visit 비교
• C++ Bridge 패턴
• C++ Facade 패턴
• C++ Flyweight 패턴
• C++ 디자인 패턴 | Adapter·Decorator
• 배열과 연결 리스트

---

자주 묻는 질문 (FAQ)

Q. add()와 remove()를 Component 인터페이스에 둘지, Composite에만 둘지 어떻게 정하나요?

A. Component 인터페이스에 두면 클라이언트가 Leaf와 Composite를 구분하지 않고 다룰 수 있는 투명성을 얻지만, 앞에서 본 것처럼 Leaf에서 add()가 호출될 때 예외를 던지거나 무시하는 런타임 처리가 필요합니다. Composite에만 두면 잘못된 호출을 컴파일 단계에서 막을 수 있는 대신, 트리를 조립하는 쪽에서 Composite 타입을 알고 있어야 합니다. 트리 구성 코드가 로더나 팩토리 한곳에 모여 있다면 Composite에만 두는 편이 안전하고, 순회·연산 코드에서는 Component 인터페이스만 쓰도록 나누는 방식이 흔합니다.