[C++ 스마트포인터 시리즈 1] ROS를 걷어내고 순수 C++로 구축하는 고성능 프로덕션 시스템 설계 가이드

[보고서] ROS를 걷어내고 순수 C++로 구축하는 고성능 프로덕션 시스템 설계 가이드

---

1. 보고서 제목

왜 우리는 ROS를 걷어냈는가: 안정성과 성능을 보장하는 순수 C++ 기반 로봇 프로덕션 프레임워크 구축 전략
부제: POC를 넘어 양산형 자율주행 및 로봇 소프트웨어를 위한 실전 아키텍처 가이드

---

2. Executive Summary (핵심 요약)

• 핵심 주장: ROS(특히 ROS 2)는 프로토타입 개발 및 빠른 검증에는 탁월하나, 자원이 제한된 임베디드 환경에서의 고성능 요구사항과 예측 불가능한 디버깅 이슈로 인해 실제 양산 제품(Production)에 적용하기에는 치명적인 한계가 있습니다.
• 주요 결론: 자율주행, 실외 배송 로봇 등 고도화된 시스템에서는 성능 최적화와 리소스 제어권을 확보하기 위해 ROS의 추상화 계층을 걷어내고, 직접 설계한 멀티스레드 기반의 순수 C++ 프레임워크를 도입해야 합니다.
• 시사점: 프레임워크를 직접 통제할 때 비로소 모든 CPU 코어의 자원을 100% 활용할 수 있으며, 시스템의 동작을 예측 가능하게 만들어 유지보수와 디버깅 효율을 획기적으로 높일 수 있습니다.
• Novelty: 본 강의는 단순한 ROS 사용법이 아닌, 실제 현업(스트라드비전, 로보티즈 등)의 양산 레벨에서 겪은 실패와 성공 경험을 바탕으로 '프레임워크 자체를 설계하는 관점'을 제시합니다.

---

3. 위계적 개요 (Hierarchical Outline)

• 서론: ROS와 프로덕션의 괴리 [00:00]
• 현업에서 ROS 기반 프로덕션 코드 개발의 위험성 경고
• 발표자의 이력 및 프레임워크 직접 개발 배경 소개

• 본론 1: 왜 ROS 2는 프로덕션에서 실패하는가? [08:35]
• 실제 프로젝트 사례: 실외 배송 로봇 개발기 [09:33]
• ROS 2의 기술적 한계: 멀티익스큐터, 토픽 시스템, 데이터 복사 문제 [11:10]

• 본론 2: 순수 C++ 프레임워크로의 전환과 결과 [14:44]
• ROS 제거 및 통합 익스큐터블 구현 전략 [16:42]
• 성능 변화: CPU 사용량 및 처리 속도의 극적인 향상 [17:25]
• 디버깅 효율성 및 개발 문화의 변화 [18:44]

• 본론 3: 프로덕션 코드를 위한 프로젝트 구조와 인프라 [19:36]
• 코드 구현 전 고려해야 할 프로젝트 구조 설계

---

4. 주요 내용 심층 분석

섹션 1. 서론: ROS 기반 프로덕션의 위험성 [00:00]

• 핵심 설명: ROS 2가 프로덕션 타겟(Real-time OS 지원 등)이라고 주장하지만, 실제 임베디드 환경에서 직접 적용해 본 결과 많은 부분이 제대로 동작하지 않음을 확인했습니다. [00:43]
• 강조 포인트: "로스를 사용하는 것을 반대하는 것이 아니라, 실제 프로덕션 단계에서 발생하는 문제를 해결하기 위해 어떤 개선이 필요한지 전달하는 것이 목적입니다." [01:10]
• 1문장 요약: ROS는 연구용으로 훌륭하나 제품화 단계에서는 통제 불가능한 변수를 생성하므로 주의가 필요합니다.

섹션 2. 왜 ROS 2로 프로덕션을 개발할 수 없는가? (문제점 분석) [08:35]

• 항목 01: 비효율적인 리소스 활용 및 멀티스레딩 이슈 [11:10]
• 핵심 내용: 당시 ROS 2의 멀티익스큐터는 이름과 달리 실제 멀티스레딩이 제대로 이루어지지 않았으며, 사용자가 리소스를 세밀하게 관리할 수 없었습니다. [11:57]
• 예시 사례: 30fps로 송출되는 USB 카메라 토픽이 받는 쪽 노드에서는 10fps 미만으로 떨어지는 현상 발생. [11:18]

• 항목 02: 예측 불가능한 토픽 시스템과 디버깅 난해함 [12:51]
• 핵심 내용: 통신 상태, 송수신 노드의 부하 상황에 따라 토픽 수신 여부가 결정되어 문제 발생 시 원인 파악이 불가능합니다. [13:01]
• 상황 예시: "쏘는 노드가 하나일 때 받는 노드가 여러 개면, 받는 노드들의 상태에 따라 토픽이 받아지고 안 받아집니다. 이걸로 어떻게 상용 제품을 만듭니까?" [13:20]

• 항목 03: 대용량 데이터(이미지 등) 처리 시 병목 [13:50]
• 핵심 내용: 댑스(Depth) 이미지와 같은 대용량 데이터를 전송할 때 DDS 통신 부하로 인해 전체 시스템이 마비되는 현상이 발생합니다. [14:34]
• 예시 문장: "30프레임으로 쏜 댑스 이미지가 받는 쪽에서 0.5프레임이 뜨고, 1~2초 전 이미지가 날아오는 말도 안 되는 상황이 벌어집니다." [14:02]

• 1문장 요약: ROS의 추상화와 통신 오버헤드가 고부하 임베디드 시스템의 안정성을 저해합니다.

섹션 3. ROS 제거 및 순수 C++ 프레임워크 구축 [14:44]

• 항목 01: 단일 실행 파일(Single Executable)로의 통합 [16:42]
• 핵심 내용: 여러 노드로 쪼개져 있던 시스템을 하나의 프로세스로 통합하여 메모리 공유 및 스레드 관리를 직접 통제합니다. [16:42]
• 변형 표현: "노드로 나눠져 있던 모든 걸 하나로 뭉쳐서 익스큐터블을 하나로 바꿨습니다."

• 항목 02: 직접적인 리소스 제어 (Thread & Memory) [16:53]
• 핵심 내용: 스레드 파이프라인, 뮤텍스, 메모리 할당 시스템을 직접 설계하여 성능을 예측 가능하게 만들었습니다. [17:01]

• 항목 03: 결과 - 극적인 성능 향상 [17:25]
• 수치적 증거: CPU 코어 8개를 모두 활용하게 되면서 평균 사용량이 80% 이상으로 증가, 단순 계산으로 약 8배의 성능 향상 효과를 거둠. [17:45]
• 상황별 적용: 멀티 카메라 시스템에서 슬램, 인퍼런스(Object Detection, Segmentation), 스트리밍을 실시간으로 동시 수행 가능해짐. [18:04]

• 1문장 요약: 시스템 통제권을 가져옴으로써 하드웨어 성능을 극한까지 끌어올리고 디버깅의 복잡성을 제거했습니다.

---

5. 핵심 질문 생성 및 답변

1. Q: ROS 2가 프로덕션에 적합하지 않은 결정적인 이유는 무엇인가요?

• A: 리소스 제어의 불확실성 때문입니다. 멀티스레딩이 의도대로 동작하지 않고, DDS 통신 오버헤드로 인해 대용량 데이터 처리 시 시스템 전체가 지연되거나 마비될 수 있기 때문입니다. [12:17], [14:34]

2. Q: ROS를 제거했을 때 얻을 수 있는 가장 큰 이점은 무엇인가요?

• A: 성능의 '예측 가능성'입니다. 하드웨어 자원(CPU, GPU)을 직접 배분하여 병목을 제거하고, 오류 발생 시 통신 문제인지 로직 문제인지 명확히 구분하여 디버깅 효율을 높일 수 있습니다. [16:53], [18:44]

3. Q: 우분투(Ubuntu) 환경에서 제품을 배포할 때의 문제는 무엇인가요?

• A: 커널 레벨을 수정하거나 제품 브링업(Bring-up) 단계에서 상업적으로 이용할 경우 캐노니컬 사의 라이선스 비용 이슈가 발생할 수 있어 양산 제품화에 걸림돌이 됩니다. [04:03]

4. Q: 자율주행 양산 소프트웨어 중에 ROS를 사용하는 경우가 있나요?

• A: 발표자는 단언컨대 실제 자동차 양산 레벨에서 ROS를 그대로 올린 사례는 없다고 강조하며, 자체 프레임워크 구축 능력이 엔지니어의 핵심 가치라고 말합니다. [05:30]

5. Q: 단일 프로세스로 통합하면 어떤 변화가 생기나요?

• A: 데이터 복사(Deep Copy) 없이 메모리를 공유할 수 있고, OS의 스케줄링에만 의존하던 스레드 실행 순서를 프레임워크 내에서 정교하게 관리할 수 있게 됩니다. [15:28], [17:01]

---

6. 전략적 인사이트 및 실전 적용 팁

• 인사이트: "추상화는 대가(Cost)를 동반한다." 빠른 개발을 위한 추상화는 프로덕션 단계에서 성능 저하와 원인 불명의 버그로 돌아옵니다. 시스템의 로우 레벨(스레드, 메모리 관리)을 이해하고 직접 다루는 능력이 고액 연봉 엔지니어의 차별점입니다. [06:45]
• 실전 팁:
• POC 단계: ROS를 사용하여 빠르게 기능을 검증하고 알고리즘의 유효성을 파악합니다.
• 프로덕션 전환: 데이터량이 많은 센서 데이터(이미지, 라이다 등) 처리부부터 우선적으로 순수 C++ 파이프라인으로 교체하십시오.
• 모듈화: 제어와 같이 타 모듈과 통신이 필수적인 부분만 최소한의 ROS 인터페이스를 남기고 내부 로직은 완전히 분리(Decoupling)하십시오. [15:06]

---

7. 종합 결론 및 액션 플랜

최종 결론: 성공적인 로봇/자율주행 제품 개발을 위해서는 ROS라는 편리한 도구에 의존하기보다, 시스템의 하드웨어 리소스를 완벽히 장악할 수 있는 순수 C++ 기반의 자체 프레임워크 설계 역량을 반드시 갖추어야 합니다.

액션 플랜:

1. 현재 시스템 분석: 운영 중인 ROS 시스템에서 CPU 사용률이 특정 코어에 쏠려 있지 않은지, 토픽 지연이 발생하지 않는지 모니터링하십시오.
2. 멀티스레드 학습: C++ std::thread, condition_variable, mutex를 활용한 데이터 파이프라인 설계 연습을 시작하십시오.
3. 모듈 통합 설계: 여러 노드로 분산된 기능을 하나의 실행 파일(Executable) 내에서 효율적으로 관리할 수 있는 클래스 구조를 설계해 보십시오.
4. 라이브러리화: ROS 의존성을 제거한 알고리즘을 독립적인 C++ 라이브러리로 분리하여 테스트 코드(GTest 등)를 통해 검증하는 습관을 들이십시오.

---

본 보고서는 [개발대장] 채널의 영상을 바탕으로 작성되었으며, 자세한 프로젝트 구조와 코드 구현 방법은 후속 강의를 통해 제공될 예정입니다.

---

사용자님의 질문은 현업 로봇 엔지니어들이 ROS를 마주하며 느끼는 현실적인 고충과 의문을 정확히 찌르고 있습니다. 영상의 맥락과 실제 산업계 상황을 바탕으로 답변해 드리겠습니다.

---

질문1. 임베디드 환경의 CPU, GPU 수준에 대하여

여기서 말하는 '임베디드 환경'은 일반적인 데스크탑(i9, RTX 5090 등)과는 거리가 멉니다. 로봇은 배터리로 움직여야 하고 크기와 발열에 제한이 있기 때문입니다. 주로 다음과 같은 사양을 의미합니다.

• 대표적인 하드웨어: NVIDIA Jetson 시리즈(Orin, Xavier 등)가 가장 표준적입니다.
• CPU 수준: 데스크탑 급 i7, i9이 아니라 모바일용 저전력 ARM 프로세서(8코어~12코어 내외)인 경우가 많습니다. 클럭 속도가 데스크탑보다 현저히 낮습니다.
• GPU 수준: RTX 5090 같은 외장 그래픽이 아니라, CPU와 메모리를 공유하는 통합형 GPU(iGPU)입니다. 텐서 코어가 포함되어 있지만, 전력 소모량(TDP)이 15W60W 수준으로 제한되어 있어 데스크탑 GPU 성능의 1020% 수준인 경우가 허다합니다.
• 결론: 자원이 매우 한정적이기 때문에, CPU 코어 하나만 100%를 쓰고 나머지가 노는 상황(ROS 2 초기 버전의 이슈)은 양산 로봇 입장에서 치명적인 자원 낭비가 됩니다.

---

질문2. 프레임워크를 새로 만들라는 것이 너무 가혹하지 않은지?

질문자님의 말씀대로 처음부터 모든 것을 다 만드는 것은 매우 어렵고 가혹한 일이 맞습니다. 하지만 영상에서 말하는 '프레임워크 구축'의 본질은 다음과 같습니다.

• 모든 것을 새로 만들라는 뜻인가?: 아닙니다. OpenCV, PCL(Point Cloud Library), Eigen, TensorRT 같은 기능성 라이브러리는 그대로 가져다 씁니다.
• 핵심은 '배차 시스템'과 '도로'를 까는 것: ROS가 제공하던 '통신(토픽/서비스)', '실행 관리(익스큐터)', '데이터 복사' 방식을 쓰지 않고, 순수 C++의 멀티스레드(Thread)와 공유 메모리 관리 로직을 직접 짜라는 것입니다.
• 복붙인가, 새로 짜기인가?: 알고리즘(수학적 로직)은 ROS에서 검증한 것을 가져오되, 그 알고리즘이 돌아가는 "그릇(프레임워크)"을 C++로 직접 구현하라는 뜻입니다.
• 왜 이런 무책임해 보이는 소리를 하는가?: 영상의 핵심은 "양산(Production)"에 있습니다. 수만 대의 로봇을 팔아야 하는 기업 입장에서, 로봇이 이유 없이 멈추거나 렉이 걸리면 전량 리콜 사태가 벌어집니다. "ROS가 그랬어요"라고 변명할 수 없기 때문에, 엔지니어가 100% 통제 가능한 코드를 가지라는 '현실적인 경고'인 셈입니다. (확실히 초보자에게는 매우 가혹한 조언입니다.)

---

질문3. ROS 커뮤니티는 왜 이 문제를 해결하지 않는가?

ROS는 전 세계 수만 명의 개발자가 참여하는 거대한 오픈 소스입니다. 그들도 문제를 알고 있고 해결하려고 노력하지만, 몇 가지 태생적인 한계가 있습니다.

1. 범용성 vs 최적화: ROS는 교육용 로봇부터 거대한 공장 자동화까지 '어디서든 돌아가게' 만들어야 합니다. 특정 임베디드 환경에만 최적화하기 어렵습니다. 반면, 기업은 자기들의 하드웨어에만 100% 맞춘 최적화가 필요합니다.
2. DDS라는 외부 엔진: ROS 2는 통신 엔진으로 'DDS'라는 표준 규격을 사용합니다. ROS 개발진이 직접 만든 게 아니라 외부 솔루션을 가져다 쓴 것이라, 통신 밑단에서 발생하는 지연이나 메모리 문제를 완벽하게 제어하기 힘든 구조적 한계가 있습니다.
3. 하드웨어 추상화 계층: ROS는 하드웨어가 무엇이든 상관없이 돌아가도록 '추상화'를 많이 해두었습니다. 추상화는 개발을 편하게 해주지만, 단계가 많아질수록 성능(속도)은 떨어집니다.
4. 능력의 문제가 아닌 목표의 문제: ROS 커뮤니티의 목표는 "누구나 쉽게 로봇을 만들게 하자"이지, "테슬라 같은 고성능 자율주행차의 양산 코드를 제공하자"가 아닙니다. 후자는 각 기업이 자기들의 기술 기밀로 직접 만들어야 할 영역으로 남겨두는 것입니다.

요약하자면:
ROS는 "대학생이나 연구원이 1달 만에 로봇을 굴리게 만드는 도구"로는 세계 최고입니다. 하지만 "영하 20도에서 24시간 내내 한정된 배터리로 복잡한 연산을 0.001초의 오차 없이 수행해야 하는 제품"을 만들기에는 너무 무겁고 느슨한 옷인 것입니다. 그래서 "진짜 프로가 되려면 그 옷을 직접 지어 입을 줄 알아야 한다"는 것이 영상의 요지입니다.

---

질문자님께서 짚어주신 "스마트 포인터(Smart Pointer)를 사용한 메모리 관리"는 직접 프레임워크를 구축할 때 핵심적인 기술 요소 중 하나가 맞습니다. 하지만 단순히 ROS 코드를 복사해서 개선하는 수준을 넘어, '데이터가 흐르는 통로 자체를 재설계'하라는 의미에 가깝습니다.

이해가 쉽도록 ROS의 방식과 순수 C++ 프레임워크 방식의 차이를 비교해 드릴게요.

---

1. ROS의 방식: "배달 대행 서비스" (Deep Copy & DDS)

ROS 2에서 노드 간 데이터를 주고받을 때는 기본적으로 데이터를 직렬화(Serialization)하여 통신 엔진(DDS)을 통해 보냅니다.

• 문제점: 같은 CPU 안에서 돌아가는데도 데이터를 복사해서 넘겨주는 경우가 많습니다. 특히 고화질 이미지 데이터는 한 번 복사할 때마다 CPU와 메모리 대역폭을 엄청나게 잡아먹습니다.
• 복붙의 한계: ROS의 rclcpp 라이브러리 소스 코드는 매우 방대하고 DDS 엔진과 강하게 결합되어 있어, 필요한 부분만 떼어내서 개선하기가 거의 불가능할 정도로 복잡합니다.

2. 순수 C++ 방식: "식당 내부 주방 시스템" (Shared Memory & Zero Copy)

발표자가 제안하는 방식은 데이터를 통신으로 보내지 말고, 메모리 주소값(Pointer)만 전달하여 데이터 복사를 0으로 만들라는 것입니다.

• 스마트 포인터의 역할: std::shared_ptr를 사용하면 데이터를 생성한 노드와 데이터를 사용하는 노드가 동일한 메모리 공간을 안전하게 바라볼 수 있습니다. 데이터를 다 썼을 때 자동으로 해제해주니 메모리 누수도 막을 수 있죠.
• 멀티스레딩 재설계: ROS의 익스큐터(Executor)에 맡기지 않고, C++ std::thread나 스레드 풀(Thread Pool)을 직접 만들어 "이미지 처리 스레드는 1번 코어, 슬램은 2, 3번 코어" 식으로 우선순위와 자원을 엔지니어가 직접 할당합니다.

---

3. "복붙"인가 "재창조"인가?

결론부터 말씀드리면 "구조는 새로 만들고, 알고리즘 로직만 가져온다"가 맞습니다.

1. 메시지 정의: ROS의 .msg 파일 대신, 순수 C++의 struct나 class로 데이터 형식을 만듭니다.
2. 데이터 전달: Publisher/Subscriber 대신, 큐(Queue)와 조건 변수(condition_variable)를 활용한 관찰자 패턴(Observer Pattern) 등을 직접 구현합니다.
3. 스마트 포인터 활용: 이 과정에서 std::unique_ptr나 std::shared_ptr를 사용하여 "복사 없는 데이터 전달(Zero-copy)" 파이프라인을 구축합니다.

4. 이게 왜 가혹하지 않은 선택인가 (역설적 이점)

처음에는 직접 만드는 게 고통스럽지만, 한 번 만들어두면 다음과 같은 압도적 이득이 생깁니다.

• 디버깅: ROS는 문제가 생기면 통신 문제인지, 미들웨어 문제인지 알기 어렵지만, 직접 짠 C++ 코드는 콜스택(Call Stack)을 찍으면 정확히 어디서 터졌는지 한눈에 보입니다.
• 성능: 영상에서 언급했듯, 똑같은 하드웨어에서 CPU 사용 효율이 8배나 차이 날 수 있는 비결이 바로 이 '통제권'에 있습니다.

결론적으로, 질문자님이 생각하신 스마트 포인터의 적극적 활용은 아주 정확한 방향입니다. 다만 ROS 코드를 수정하는 방식보다는, "C++ 표준 라이브러리를 사용해 우리 로봇에 딱 맞는 가볍고 빠른 고속도로를 새로 깐다"는 개념으로 접근하시는 것이 발표자의 의도에 부합합니다.

---

혹시 C++에서 멀티스레드 간에 데이터를 복사 없이 안전하게 주고받는 구체적인 코드 예시(Queue와 스마트 포인터 활용)가 궁금하신가요?

질문자님의 통찰이 아주 정확합니다! 유튜브 영상 링크를 공유하는 비유는 포인터와 참조(Reference)의 핵심을 꿰뚫는 완벽한 비유입니다.

질문하신 "어차피 CPU가 메모리에 접근해서 값을 읽어야 하는 건 똑같은데, 왜 주소만 주는 게 더 빠른가?"에 대한 답은 '이사 비용'과 '캐시 효율' 관점에서 설명할 수 있습니다.

---

1. "이사 비용"의 차이 (복사 vs 전달)

유튜브 영상 링크(주소)는 단 몇십 바이트밖에 안 되지만, 영상 파일 그 자체(데이터)는 몇 기가바이트일 수 있습니다.

• 값 복사 (Deep Copy): 함수를 호출할 때마다 영상 파일 전체를 새로 다운로드해서 친구에게 보내주는 것과 같습니다. 친구가 영상을 볼 때(CPU 연산)는 똑같이 메모리를 읽겠지만, 보내주는 과정(복사)에서 이미 엄청난 시간과 메모리 대역폭을 낭비하게 됩니다.
• 주소 전달 (Pass by Reference/Pointer): 링크만 띡 보내주는 것입니다. 보내는 과정이 순식간에 끝납니다.

특히 로봇에서 다루는 고해상도 이미지(4K, 뎁스 맵 등)나 수만 개의 포인트 클라우드 데이터는 한 번 복사할 때마다 CPU가 수 밀리초(ms) 동안 아무것도 못 하고 메모리 복사만 하고 있어야 합니다. 이게 쌓이면 프레임 드랍이 발생하는 것이죠.

---

2. "이동(Move)"의 마법 (C++11 이상)

질문자님이 언급하신 '이동(Move)'은 링크 공유와는 조금 결합된 개념입니다.

• 상황: 내가 가진 영상 파일이 너무 커서 복사해줄 순 없는데, 소유권을 넘겨주고 싶을 때 사용합니다.
• 작동 방식: 데이터 본체는 메모리에 그대로 두고, 그 데이터를 가리키는 '관리 장부(포인터)'만 쏙 가로채오는 방식입니다.
• 성능 이점: 실제 데이터 덩어리는 건드리지 않고, 주소값만 바꾸기 때문에 데이터가 아무리 커도 연산 속도가 일정()합니다.

---

3. "그럼 주소만 주는 게 무조건 좋은가?" (CPU와 메모리의 관계)

질문하신 "연산이 필요할 때만 메모리에서 불러와서 쓰는 게 나은가?"에 대해서는 두 가지 측면이 있습니다.

A. 큰 데이터 (객체, 배열, 이미지)

• 주소만 주는 게 압도적으로 유리합니다. 복사 비용이 읽기 비용보다 훨씬 크기 때문입니다.
• 로봇 프레임워크에서 스마트 포인터(std::shared_ptr)를 쓰는 이유가 바로 이것입니다. 여러 모듈(인지, 제어, 지도)이 커다란 이미지 데이터를 공유할 때, 주소만 들고 있게 하여 복사 비용을 '0'으로 만듭니다.

B. 아주 작은 데이터 (int, float, char)

• 이런 경우는 주소를 주는 게 오히려 손해일 수 있습니다.
• 이유: 주소를 찾아가는 과정(Dereferencing)도 결국 CPU 연산인데, 데이터 자체가 주소값(64비트 환경에서 8바이트)보다 작거나 비슷하면 그냥 값을 직접 복사해서 CPU 레지스터에 바로 올리는 게 더 빠릅니다.

---

4. ROS의 문제와 연결해보기

ROS 2의 기본 통신 방식이 비판받았던 이유는, 같은 컴퓨터(심지어 같은 프로세스) 안에서 데이터를 주고받는데도 "링크를 주면 될 것을 굳이 영상을 새로 인코딩(직렬화)해서 통신망으로 쏴주고, 받는 쪽에서 다시 디코딩(역직렬화)"하는 과정을 거쳤기 때문입니다.

발표자가 말한 "순수 C++ 프레임워크"는 이 과정을 생략하고, 전역적으로 관리되는 스마트 포인터 큐를 만들어 "주소만 툭 던져주고 바로 다음 연산으로 넘어가는" 구조를 직접 짜라는 뜻입니다.

---

요약하자면:

1. 값 복사: 데이터가 클수록 "복사하는 시간" 자체가 재앙이 됩니다.
2. 주소 전달: 복사 시간을 없애고, CPU가 실제 일을 해야 할 때만 메모리에 접근하게 합니다.
3. 결론: 연산 시 메모리 접근 비용은 동일할지언정, 연산 전후에 발생하는 '데이터 이동 및 복제' 비용을 제거하는 것이 시스템 전체 성능 향상의 핵심입니다.

혹시 로봇 프로젝트에서 가장 메모리를 많이 잡아먹는 '이미지 데이터'를 스마트 포인터로 주고받는 실제 C++ 코드 구조를 한번 보시겠어요?