RT-DETR이 YOLO 자리 가져간다는 얘기, 좀 걸러볼 만한 부분

객체 탐지에서 Transformer 기반의 RT-DETR이 YOLO를 대체하고 있다는 주장이 꽤 자주 들림. NMS가 필요 없고, 정확도도 비슷하거나 살짝 우위고, 작은 객체에 강하다는 게 핵심이거든요. 흥미로운 주장이긴 한데, 이게 정말 "YOLO 시대 끝"을 의미하는 건 좀 다른 얘기.

본문 들어가기 전에 짚고 갈 용어 몇 개.

• RT-DETR: Real-Time DEtection TRansformer. Baidu가 2023년에 낸 Transformer 기반 실시간 객체 탐지 모델
• DETR: Meta가 2020년에 처음 공개한 원조 Transformer 객체 탐지 모델. 느리지만 NMS가 필요 없는 게 특징
• NMS: Non-Maximum Suppression. 여러 개의 겹친 박스 중 하나만 남기는 후처리 단계
• Ultralytics: YOLO 시리즈 패키징으로 유명한 Python 라이브러리. 최근엔 RT-DETR도 같이 지원함

RT-DETR이 흥미로운 이유#

CNN 기반 객체 탐지의 약점은 두 가지로 정리됨. 하나는 로컬 receptive field 한계라 멀리 떨어진 픽셀끼리의 관계를 잘 못 본다는 점이고, 다른 하나는 anchor 설계와 NMS 후처리에 사람 손이 너무 많이 들어간다는 점. RT-DETR은 이걸 Transformer의 글로벌 attention과 set prediction 방식으로 풀어버린 것.

특히 NMS-free 설계는 단순히 "한 단계 줄였다" 수준이 아님. NMS는 CPU에서 도는 후처리라서, 객체가 많은 프레임에서는 추론 시간이 들쭉날쭉해짐. 자율주행이나 실시간 모니터링처럼 latency 일관성이 중요한 환경에서는 이게 의외로 큰 문제거든요. RT-DETR은 모델 출력 단계에서 이미 중복 박스를 처리하기 때문에 객체 수가 늘어도 추론 시간이 거의 평탄하다는 게 자료 기반 주장의 핵심.

이론적으로는 작은 객체에도 강함. 글로벌 attention 덕에 multi-scale feature fusion이 자연스럽게 되기 때문에, 멀리 있는 작은 새 같은 것도 잘 잡을 가능성이 있음. 직접 비교해본 건 아니라 실제로 그런지는 모르겠지만, 공식 벤치 기준으로는 비슷한 latency 구간에서 mAP가 더 잘 나온다고 함.

NMS-free라는 말의 무게#

이 부분은 좀 더 짚어볼 만함. YOLO 계열은 anchor 기반으로 한 객체에 여러 개의 후보 박스를 만든 뒤 NMS로 추려냄. 직관적이긴 한데, anchor 디자인이 도메인마다 달라야 한다는 게 은근 귀찮음. 항공사진과 보행자 탐지에 같은 anchor를 쓰면 성능이 안 나오니까.

RT-DETR의 set prediction은 모델이 처음부터 "객체 N개 = 박스 N개"를 예측하도록 학습됨. 헝가리안 매칭으로 GT랑 1:1 매칭을 강제하면서 학습되거든요. 그래서 한 객체에 박스 한 개만 떨어지는 거. 깔끔하긴 한데, 이 학습 방식 자체가 데이터가 적을 때 수렴이 잘 안 되는 경향이 있다는 얘기가 종종 들림. 후기들 보면 fine-tuning이 YOLO만큼 만만하진 않다는 의견이 자주 나오더라고요.

여담인데, 내가 운영하는 aickyway.com이 AI 이미지 생성 쪽이라 객체 탐지를 직접 쓸 일은 별로 없음. 다만 POD 디자인 작업에서 생성 이미지의 특정 요소만 분리해야 할 때 가끔 segmentation 쪽 모델을 만져봤는데, 그쪽도 anchor 떼어낸 흐름이긴 했음. 안 잡아도 되는 게 진짜 편하긴 하네요.

그래서 YOLO 자리 가져가나#

여기서부턴 좀 회의적임. 모델 그 자체로만 보면 RT-DETR이 매력적인 건 맞는데, 객체 탐지를 실제로 쓰는 입장에서는 모델 성능 외 변수가 더 클 때가 많거든요.

첫째로 생태계. YOLO는 v5, v8, v11까지 오면서 튜토리얼, 사전학습 weights, 모바일/엣지 변환 도구, fine-tuning 스크립트가 산처럼 쌓여 있음. RT-DETR도 Ultralytics에 들어왔으니 진입 장벽은 낮아졌지만, 커스텀 데이터셋용 가이드나 troubleshooting 글의 양은 한참 부족함. 처음 도입하는 사람한텐 검색해도 안 나오는 문제가 자주 생긴다는 뜻.

둘째로 엣지 배포. 라즈베리파이, Jetson, 모바일 NPU에 모델을 돌려야 하는 경우가 의외로 많은데, Transformer 계열은 quantization이나 pruning 후의 정확도 하락이 CNN보다 큰 경향이 있다고 함. ONNX 변환은 되지만 진짜 임베디드에서 실시간으로 돌리려면 추가 작업이 더 들 가능성이 높음. 이 부분은 직접 안 해봐서 정확한 건 모르는데, Transformer를 엣지에 올리는 일 자체가 아직 미성숙한 분야인 듯.

셋째로 학습 비용. NMS-free 매칭이 좋긴 한데, 수렴까지 epoch가 더 필요한 경우가 자주 보고됨. 데이터가 1,000장 미만 수준의 작은 커스텀 데이터셋이면 YOLO가 더 안전한 선택일 수 있음.

한계 / 직접 안 해본 부분#

위 내용 중 상당 부분은 자료와 공식 벤치 기반임. 직접 RT-DETR을 커스텀 데이터로 학습시켜본 건 아니거든요. 그래서 "fine-tuning이 까다롭다"는 부분도 후기들의 평균이지 내 측정은 아님. 약간 걸러 들어야 하는 부분.

또 객체 탐지는 진짜 환경 의존성이 큼. 클래스 수, 데이터 분포, 해상도, 도메인이 다 다르기 때문에 한 데이터셋의 mAP 비교만 보고 결론 내기 어려움. COCO에서 잘 된다고 의료 영상이나 위성 이미지에서 똑같이 잘 된다는 보장은 없거든요.

결론#

RT-DETR은 객체 탐지 아키텍처 흐름이 진짜로 Transformer 쪽으로 옮겨가고 있다는 신호임. NMS-free라는 설계 결정 하나만으로도 추론 안정성이 달라지는 게 매력적이고, 글로벌 attention의 작은 객체 처리 능력도 실험할 가치가 충분함.

근데 "YOLO 자리를 가져간다"는 표현은 좀 과함. 새로운 프로젝트에서 후보로 검토할 만한 모델 하나가 늘어난 정도이지, 기존 YOLO 인프라를 통째로 갈아엎을 이유는 없음. 솔직히 그건 그냥 마케팅 톤. 작은 커스텀 데이터셋이거나 엣지 배포가 핵심이면 여전히 YOLO가 안전한 선택.