객체지향(OOP)의 오버헤드에 관한 고찰

클래스 기반 OOP의 오버헤드

1. 클래스 정의 자체의 메모리 오버헤드
   - 클래스가 정의되면 메타정보(vtable, type info 등)가 메모리에 로딩됨
   - 사용하지 않아도 런타임 시 로딩 및 관리됨
2. 단일 인스턴스를 위해서도 클래스 정의 필요
   - 1회성 객체라도 클래스 정의가 필수
   - 명시적 설계 구조를 강제하지만 유연성은 떨어짐
3. 상속 체계로 인한 비용
   - 다형성, 가상 함수, 동적 바인딩 등은 런타임 비용을 수반
   - vtable 조회는 실행 성능에 영향 가능
4. 복잡한 설계 패턴 강제
   - SRP, SOLID 등으로 구조가 깊어짐
   - 단순 기능도 여러 객체와 계층 구조 필요

함수형 프로그래밍(예: JavaScript의 클로저)에서는?

• 함수 단위로 즉시 실행 및 캡슐화 가능
• vtable, 메타클래스 구조 없음
• 1회성 상태 유지 객체에 적합
• 런타임에 동적 생성 가능 → 선언/사용 비용 낮음

OOP vs 클로저 구조 비교

항목	클래스 기반 OOP	클로저 기반 설계
선언 구조	미리 정의된 클래스 필요	즉석 함수 생성 가능
런타임 오버헤드	vtable, 타입 정보, 상속 체계 등 존재	거의 없음 (함수 스코프 유지)
사용 용도	명확한 타입 구조, 재사용, 상속	간단한 상태 은닉, 유틸 함수
1회성 객체 사용	불필요한 클래스 정의 필요할 수 있음	함수 한 번으로 캡슐화 가능

→ 모든 기능을 클래스로 선언하는 것은 OOP 철학에는 부합하지만, 메모리 효율성, 런타임 성능, 코드 유연성 측면에서는 과도한 오버헤드를 초래할 수 있음.
→ 간단한 상태 보존, 1회성 기능에는 함수 기반 구조(클로저)가 더 적절함.
→ JavaScript, Python이 함수와 클래스 모두를 허용하는 이유도 여기에 있음.

---

커널, 혹은 운영체제(OS) 개발에서 OOP는?

C++ 같은 객체지향 언어는 거의 사용되지 않으며, 사용되더라도 매우 제한적입니다.

1. 직접적이고 예측 가능한 메모리 제어가 필요
   - 커널은 하드웨어 자원을 직접 다룸
   - C++의 new, delete, STL 등은 런타임 메모리 제어가 불투명
   - C는 메모리 할당이 명시적이고 예측 가능함
2. 런타임 오버헤드를 최소화해야 함
   - C++의 virtual 함수, 예외 처리, RTTI 등은 런타임 비용을 유발
   - 커널은 실시간 성능 요구 → 지연 시간(latency)을 최소화해야 함
   - 동적 바인딩 구조는 지양
3. 이식성과 컴파일 제어가 중요
   - 커널은 다양한 아키텍처(x86, ARM 등)에 포팅되어야 함
   - C는 이식성이 뛰어나고 표준화되어 있음
   - C++은 컴파일러 의존성 및 ABI 문제 발생 가능
4. 부트스트랩과 초기화 코드의 복잡도 회피
   - 전역 객체 초기화, 템플릿 메타프로그래밍은 부트로더 단계에서 부적합
   - 초기화 순서 불명확 시 undefined behavior 발생 위험
   - C는 단순하고 명확한 구조 제공 → 부트코드에 적합
5. 디버깅과 분석 도구 호환성
   - C는 gdb, lldb 등의 저수준 디버깅 도구와 잘 호환
   - C++은 이름 맹글링, 가상 함수 포인터 등으로 디버깅이 복잡

C++을 제한적으로 사용하는 커널 예

• 클래스 대신 struct + 함수 사용
• new/delete 금지, placement new만 허용
• STL, 예외 처리, RTTI 사용 금지
• 템플릿은 정적 코드에 제한적으로 사용
• 예: Fuchsia OS(Google), Haiku OS 등은 제한된 규칙으로 C++ 사용

결론

• 커널은 성능, 예측성, 안정성, 제어 가능성이 최우선
• C++ 객체지향은 고수준 설계에는 적합하지만, 커널에는 위험 요소
• 낮은 수준에서 동작하는 만큼, 개발자의 제어권이 중요
• C 스타일의 명시적 프로그래밍이 더 선호됨