RGB-D 데이터에서 Depth Estimation과 Semantic Segmentation 이해하기

컴퓨터 비전에서 장면을 이해한다는 말은 보통 이미지 안에 무엇이 있는지를 구분하는 일부터 떠올리게 됩니다.
그런데 실제 환경에서는 단순히 객체의 종류만 아는 것으로는 충분하지 않은 경우가 많습니다. 물체가 얼마나 떨어져 있는지, 어떤 물체가 다른 물체 위에 놓여 있는지, 그리고 공간이 어떤 구조를 가지는지까지 함께 알아야 비로소 장면을 더 제대로 이해할 수 있습니다. 색상이나 질감만으로는 구분하기 어려운 흰 벽과 흰 가구 같은 경우, 혹은 그림자나 반사처럼 시각적으로 혼란스러운 환경에서는 이런 한계가 더 뚜렷하게 드러납니다. 이때 깊이 정보는 3차원 구조와 거리 단서를 제공하기 때문에 RGB가 놓치는 부분을 보완해줄 수 있습니다.

Depth map은 입력 영상의 각 픽셀에 대해 카메라나 센서로부터의 거리를 저장한 1채널 영상입니다.
즉, RGB가 “무슨 색인가”를 담고 있다면, depth는 “얼마나 떨어져 있는가”를 담고 있다고 볼 수 있습니다. 이 정보는 자율주행, 로봇공학, AR/VR 같은 분야에서도 널리 활용되고, 필요에 따라 여러 채널 표현으로 바꾸어 사용할 수도 있습니다. 결국 depth는 단순한 보조 정보가 아니라, 장면의 물리적 구조를 드러내는 중요한 단서입니다.

Depth는 어떻게 얻을 수 있을까

가장 직관적인 방법은 두 카메라를 사용하는 stereo 방식입니다.
두 카메라가 같은 장면을 조금 다른 위치에서 바라보면, 같은 물체가 두 영상에서 서로 다른 위치에 맺히게 됩니다. 이 차이를 시차라고 하고, 초점거리와 두 카메라 사이 거리까지 알면 삼각측량을 통해 깊이를 계산할 수 있습니다. 정리하면 깊이는 시차에 반비례하고, 초점거리와 baseline에 비례하는 구조가 됩니다. 그래서 멀리 있는 물체는 시차가 작고, 가까운 물체는 시차가 커집니다.

이 원리는 단순하지만 실제 적용은 생각보다 까다롭습니다.
두 카메라의 내부·외부 파라미터를 정밀하게 맞춰야 하고, 텍스처가 부족한 영역에서는 대응점을 찾기 어렵습니다. 또 한 카메라에는 보이지만 다른 카메라에는 보이지 않는 가려짐 문제도 존재합니다. 센서를 직접 사용하는 방법도 있지만, 장비 가격, 설치 제약, 실외 사용 한계, 반사나 산란 같은 환경 노이즈 문제가 따라옵니다.

그래서 자연스럽게 하나의 질문으로 이어집니다.
“단일 RGB 이미지 한 장만으로도 깊이를 추정할 수 없을까?”

그래서 등장한 것이 Monocular Depth Estimation이다

단일 이미지에서 깊이를 추정하는 일은 본질적으로 어려운 문제입니다.
하나의 2D 이미지는 여러 가능한 3D 장면으로 해석될 수 있기 때문입니다. stereo처럼 직접적인 시차 정보도 없으니, 물체의 크기, 원근, 위치, 윤곽, 배치 같은 간접 단서를 더 잘 읽어야 합니다. 예전에는 이런 단서를 사람이 직접 설계하는 handcrafted 방식이 많았지만, 일반화와 실시간성 면에서 한계가 있었습니다. 그래서 최근에는 딥러닝을 통해 단일 이미지로부터 depth를 직접 예측하는 방향이 핵심 흐름이 되었습니다.

여기서 중요한 점은, monocular depth estimation이 단순히 depth map 하나를 얻는 문제로 끝나지 않는다는 것입니다.
한 번 깊이 정보를 얻고 나면, 그 정보는 이후의 장면 이해 문제에 그대로 연결됩니다. 특히 semantic segmentation처럼 픽셀 단위 예측을 해야 하는 문제에서는 depth가 꽤 강력한 보조 신호가 됩니다.

RGB-D Semantic Segmentation은 왜 필요한가

semantic segmentation은 이미지의 각 픽셀에 클래스를 부여하는 작업입니다.
겉으로 보기에는 RGB만으로도 충분해 보일 수 있습니다. 하지만 실제 실내 장면을 떠올려보면, 색상과 질감이 비슷해서 RGB만으로 구분하기 어려운 경우가 많습니다. 예를 들어 벽과 캐비닛이 모두 밝은 톤이라면 색상 정보만으로는 경계가 모호할 수 있습니다. 이때 depth는 거리와 3차원 구조를 제공하므로, 같은 색이어도 서로 다른 객체라는 사실을 더 쉽게 드러냅니다. 색은 비슷하지만 거리가 다르면 다른 물체일 가능성이 높기 때문입니다.

초기의 RGB-D segmentation 접근은 비교적 단순했습니다.
RGB와 depth를 채널 방향으로 이어 붙이고, 이를 여러 스케일로 분해한 뒤 convolution으로 feature를 추출하고, 다시 업샘플링과 결합을 거쳐 픽셀 단위 분류를 수행하는 방식입니다. 후처리로 superpixel을 이용해 결과를 다듬기도 했습니다.

이런 구조는 RGB와 depth를 함께 쓴다는 점에서는 의미가 있었지만, 시간이 지나면서 한 가지 문제가 분명해졌습니다.
RGB와 depth는 성질 자체가 너무 다르다는 점입니다.

RGB와 Depth를 그냥 붙이면 왜 잘 안 될까

RGB는 색상과 질감 정보를 중심으로 움직이고, depth는 거리와 기하 구조 정보를 중심으로 움직입니다.
즉, 두 입력은 서로 보완적이지만 같은 종류의 신호는 아닙니다. 그런데 이 둘을 단순히 channel-wise stack으로 한 번에 넣어버리면, 네트워크 입장에서는 성질이 다른 두 모달리티를 동시에 같은 방식으로 처리해야 합니다. 그러면 오히려 각자의 장점을 충분히 활용하지 못하고, 심한 경우 단독으로 썼을 때보다도 성능이 떨어질 수 있습니다.

그래서 RGB와 depth 각각에 최적화된 인코더가 필요하고, 두 분기에서 얻은 특징을 적절한 시점과 방식으로 결합하는 설계가 중요해집니다.

이 지점에서 멀티모달 학습의 핵심이 드러납니다.
중요한 것은 정보를 많이 넣는 것이 아니라, 서로 다른 정보를 어떻게 합칠 것인가입니다. RGB와 depth는 각자 잘하는 일이 다르기 때문에, 한쪽을 다른 쪽에 억지로 맞추는 것이 아니라 각각의 특성을 살린 뒤 필요한 순간에 융합하는 편이 더 자연스럽습니다.

FuseNet은 이 문제를 어떻게 풀었을까

이런 고민에서 등장한 대표적인 구조가 FuseNet입니다.
기본 아이디어는 단순합니다. RGB 전용 인코더와 depth 전용 인코더를 따로 두고, 이후 이를 통합하는 디코더를 사용합니다. 각 인코더는 서로 다른 모달리티에 맞는 특징을 따로 추출하고, 네트워크의 여러 깊이 수준에서 RGB와 depth 정보를 융합합니다. 중요한 점은, 이 구조가 단순 입력 스택에서 한 걸음 더 나아가 어디에서, 얼마나 자주, 어떤 방식으로 fusion할 것인가를 설계의 중심으로 가져왔다는 점입니다.

조금 더 직관적으로 말하면,
RGB branch는 색과 질감에 민감한 특징을 잘 뽑고, depth branch는 구조와 거리 단서를 더 잘 뽑습니다. 그렇다면 처음부터 둘을 섞어버리기보다, 각각의 branch가 자기 역할을 충분히 수행하게 한 뒤 중간중간 정보를 교환하는 편이 더 낫습니다. FuseNet은 바로 이 생각을 구조로 옮긴 모델이라고 볼 수 있습니다.

단순한 결합보다 중요한 것은, 각 분기의 활성화를 살리는 일이다

여기서 한 가지 더 중요한 포인트가 있습니다.
RGB와 depth를 융합한다고 해서 무조건 강한 활성화가 좋은 것은 아닙니다. 오히려 너무 이른 단계에서 한꺼번에 합친 뒤 ReLU 같은 비선형 함수를 지나면, 따로 처리했을 때 살아남을 수 있었던 정보가 함께 사라질 수 있습니다. 비선형 함수는 입력이 어떻게 합쳐졌는지에 따라 전혀 다른 출력을 만들기 때문입니다. 그래서 두 branch를 분리해서 처리한 뒤, 그 다음에 element-wise summation으로 합치는 방식이 정보 보존 측면에서 더 유리할 수 있습니다.

 

이 부분은 실무적으로도 꽤 중요합니다.
예를 들어 textureless한 영역에서는 RGB보다 depth가 더 풍부한 구조 정보를 줄 수 있고, 반대로 구조가 약한 영역에서는 RGB의 색 정보가 더 유용할 수 있습니다. 두 branch를 잘 나눠서 유지하면, 한쪽이 약한 부분을 다른 쪽이 자연스럽게 메워줄 수 있습니다. 즉, 핵심은 단순한 합이 아니라 서로 다른 강점을 잃지 않게 보존하는 융합입니다.

Fusion도 어디서 얼마나 하느냐가 중요하다

FuseNet 계열에서는 fusion 전략도 하나가 아닙니다.
대표적으로 Sparse Fusion과 Dense Fusion을 생각해볼 수 있습니다. Sparse Fusion은 pooling 직전 같은 제한된 지점에서만 fusion을 수행합니다. 구조가 단순하고 연산량과 메모리 부담이 적다는 장점이 있습니다. 반면 Dense Fusion은 더 많은 convolution block에서 반복적으로 fusion을 수행해, 다양한 깊이에서 지속적으로 정보를 교환하려고 합니다. 얼핏 보면 더 자주 섞는 Dense Fusion이 항상 좋아 보이지만, 실제로는 꼭 그렇지 않습니다.

 

이유는 분명합니다.
융합도 결국 정보 결합이기 때문에, 너무 적으면 상호 보완을 충분히 못 하고, 너무 많으면 오히려 각 분기의 고유한 특성이 희석될 수 있습니다. 다시 말해 fusion은 많다고 무조건 좋은 것이 아니라, 적절한 깊이와 빈도에서 일어나야 합니다.

실험이 보여주는 핵심: 과도한 융합은 오히려 독이 될 수 있다

실험 결과는 이 점을 꽤 명확하게 보여줍니다.
RGB-D를 단순히 입력 스택으로 쓰는 방식은 RGB 단독이나 RGB-HHA보다 오히려 좋지 않았습니다. 반면 인코더를 분리하고 중간에서 적절히 융합하는 구조는 더 나은 성능을 보였습니다. 특히 Sparse Fusion은 단계가 깊어질수록 성능이 올라가다가 특정 지점 이후 포화되는 경향을 보였고, Dense Fusion은 오히려 초반 이후 성능이 계속 감소하는 경향을 보였습니다.

이 결과는 꽤 흥미롭습니다.
보통 멀티모달 문제를 처음 보면 “정보가 많을수록 좋다”라고 생각하기 쉽습니다. 그런데 실제로는 그렇지 않습니다. 중요한 것은 정보량 자체보다 정보를 섞는 타이밍과 방식입니다. RGB와 depth는 서로 보완적이지만, 동시에 다른 성질을 가지는 신호입니다. 그러니 잘 융합하면 강력한 시너지가 나오지만, 무작정 자주 섞으면 오히려 서로의 표현을 흐릴 수 있습니다.

 

이 점이 RGB-D segmentation 설계에서 가장 중요한 교훈 중 하나로 보입니다.

결국 RGB-D 학습의 핵심은 “분리한 뒤 잘 섞는 것”이다

정리해보면 흐름은 꽤 자연스럽습니다.
처음에는 depth가 왜 필요한지 이해해야 합니다. RGB만으로는 놓치기 쉬운 거리, 구조, support 관계 같은 단서가 존재하기 때문입니다. 그 다음에는 depth를 어떻게 얻는지 봐야 합니다. stereo와 센서 방식에는 장점이 있지만 제약도 많고, 그래서 monocular depth estimation이 중요한 문제가 됩니다. 마지막으로 RGB-D semantic segmentation으로 넘어오면, depth는 더 이상 부가 정보가 아니라 segmentation 품질을 실제로 끌어올릴 수 있는 중요한 모달리티가 됩니다. 다만 이때 핵심은 RGB와 depth를 한 덩어리로 다루는 것이 아니라, 각자 잘 처리한 뒤 적절하게 융합하는 것입니다.

개인적으로 이 주제에서 가장 인상적인 부분도 바로 여기입니다.
깊이 정보가 강력하다는 사실 자체보다, 그 강력한 정보를 어떻게 네트워크 안에서 활용해야 하는가가 더 중요하다는 점입니다. 단순한 채널 추가로는 부족하고, branch 분리, fusion 위치, activation 이후 정보 보존까지 함께 고민해야 합니다. 결국 좋은 멀티모달 모델은 입력이 많아서 좋은 것이 아니라, 다른 성질의 정보를 서로 방해하지 않게 잘 조율해서 좋다는 점을 보여주는 사례라고 볼 수 있습니다.

마무리하며

RGB-D 데이터는 장면 이해를 한 단계 더 깊게 만들어줍니다.
RGB가 물체의 겉모습을 설명한다면, depth는 그 물체가 공간 안에서 어디에 놓여 있는지를 설명합니다. 그리고 semantic segmentation처럼 픽셀 단위 판단이 필요한 문제에서는 이 차이가 꽤 크게 작용합니다.

다만 depth를 쓴다고 해서 자동으로 성능이 좋아지는 것은 아닙니다.
오히려 서로 다른 모달리티의 차이를 무시하면 성능이 나빠질 수도 있습니다. 그래서 앞으로 RGB-D 기반 모델을 볼 때는 단순히 “depth를 넣었는가”보다, depth를 어떤 branch에서 어떻게 처리하고, 어느 지점에서 어떤 방식으로 fusion했는가를 더 중요하게 보는 것이 좋습니다. 이 질문이 결국 모델의 성능과 해석을 동시에 좌우하는 핵심이기 때문입니다.