다음과 같은 선언은 표준 라이브러리에 포함된 것이 아니라, 단지 개념을 설명하기 위해 사용한 예시입니다:

class Matrix;
class MatrixOperator;

이 두 줄은 전방선언(Forward Declaration)을 나타냅니다. 즉, 해당 타입이 존재한다는 것을 알리지만, 정의는 나중에 하겠다는 의미입니다. 예를 들어, 다음과 같이 구성할 수 있습니다:

class Matrix;  // 전방선언

class MatrixOperator {
public:
    static Matrix Add(const Matrix& a, const Matrix& b);
    static Matrix Multiply(const Matrix& a, const Matrix& b);
};

그리고 나서 실제 Matrix 클래스를 정의합니다:

class Matrix {
private:
    double* data;
    int rows;
    int cols;

    friend class MatrixOperator;  // 알고리즘 모듈 접근 허용
};

이 구조의 목적은 데이터 구조와 알고리즘을 명확히 분리하는 것입니다. Matrix는 오직 메모리 관리와 상태 저장에 집중하고, 복잡한 계산 로직은 MatrixOperator라는 별도의 클래스로 분리합니다. 이 방식은 특히 다음 상황에서 유리합니다: - 행렬 연산은 대칭적이고, 한 쪽 객체만의 메서드로 표현하기 어렵습니다. - 특정 알고리즘이 (예: LU 분해, SVD, SIMD 최적화) 클래스 자체의 기능이라기보다는 독립적인 수학적 모듈에 가깝습니다. - 직접 메모리 접근이 성능에 필수적인 경우. 또한, 이 접근은 std::cout << value처럼 비멤버 함수가 내부 상태를 접근해야 하는 상황에서도 자연스럽게 적용됩니다. 이러한 경우, 연산자 오버로딩 함수는 클래스 멤버가 아니며, friend를 통해 접근 권한을 획득합니다. 이 설계는 전통적인 객체 지향 프로그래밍(예: C#)과 다릅니다. C#에서는 모든 행동이 클래스 내부에 포함되지만, C++에서는 모듈 단위로 책임을 분리하는 것이 더 일반적입니다. 특히 고성능 시스템(예: 이미지 프레임 처리)에서는 다음과 같은 패턴이 자주 사용됩니다:

class FrameBuffer {
private:
    float* buffer;
    size_t size;

    friend class FrameProcessor;  // 실시간 처리 모듈에게 직접 접근 허용
};

외부에서 buffer를 직접 수정하는 것을 막으면서도, 핵심 처리기에서 최소한의 오버헤드로 메모리에 접근할 수 있게 됩니다. 결론적으로, friend는 단순한 접근 제어가 아니라, **데이터와 알고리즘의 분리**, **성능 최적화**, **모듈 간의 협력**을 가능하게 하는 중요한 도구입니다. 이는 '클래스 중심'이 아닌 '모듈 중심'의 설계 철학에서 비롯됩니다. 이제부터는 다음과 같은 순서로 공부하는 것이 좋습니다: 1. 연산자 오버로딩 2. 비멤버 함수 및 매개변수 관련 검색(ADL) 3. 템플릿 기반 설계 4. 반복자 패턴 이 과정을 거치면 friend가 왜 "제로 코스트 추상화"와 함께 작동하는지 이해하게 될 것입니다.