물체 검출 2: 한 단계 YOLO 계열과 실시간성, 그리고 라이선스

상태: 초안 (2026-10-13), 일부 실측. 격자·AP 예제는 노트북 CPU 에서 직접 돌린 값입니다(code/06_yolo_ap.py, 1초 안). 논문 수치는 원문을 열어 조건과 함께 옮겼고, 하드웨어는 등급으로 적었습니다. 라이선스 내용은 각 저장소의 LICENSE 파일과 공식 안내를 2026-10-13 에 확인한 것이며, 법률 자문이 아닙니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.

목차

• 1. 한 번만 본다
  • 직접 해 보기: 어느 칸이 책임지나
  • 손실의 설계
  • 결과(논문)
• 2. 계보: 앵커, 다중 해상도, 앵커 없이, NMS 없이
• 3. 직접 해 보기: AP 계산
• 4. 실시간성이란
• 5. 라이선스: AGPL 이 웹 서비스에서 뜻하는 것
• 6. 한계와 우리 프로젝트
• 참고 문헌

1. 한 번만 본다

5편의 Faster R-CNN 은 그림당 약 5fps 였습니다. 후보를 뽑고(1단계), 후보마다 잘라 판정하기(2단계) 때문입니다. Redmon 등의 YOLO(You Only Look Once, 2016)는 질문을 바꿉니다. 「검출을 회귀 문제 하나로 풀 수 없을까?」 그림을 망에 한 번 통과시키면 모든 상자와 클래스가 한꺼번에 나오게 하자는 것입니다.

YOLO v1 의 규칙은 이렇습니다.

• 448×448 입력을 S×S = 7×7 격자로 나눕니다.
• 물체의 중심이 떨어진 칸이 그 물체를 책임집니다.
• 칸마다 상자 B=2개(각각 x, y, w, h, 신뢰도)와 클래스 확률 C=20개(VOC) 한 벌을 냅니다.
• 그래서 출력은 7 × 7 × (2·5 + 20) = 7×7×30, 숫자 1,470개입니다.

직접 해 보기: 어느 칸이 책임지나

448px 그림에서 칸 하나는 64px 입니다. 탁구 장면에 대입해 보았습니다(실측).

선수 몸 중심  (200,260) → 칸 (행 4, 열 3)
공 중심       (330,95)  → 칸 (행 1, 열 5)
라켓 중심     (215,270) → 칸 (행 4, 열 3)   ← 선수와 같은 칸

선수와 라켓의 중심이 같은 칸에 떨어졌습니다. 그 칸은 클래스 확률을 한 벌만 내므로 「사람」과 「라켓」이 다툽니다. 논문도 한 칸이 제한된 수의 물체만 예측하는 것을 약점으로 들고, 새 떼처럼 작은 물체가 몰린 경우에 약하다고 적었습니다.

손실의 설계

손실은 상자 좌표·신뢰도·클래스의 오차 제곱 합인데, 몇 가지 손질이 「왜」를 보여 줍니다.

• 너비·높이는 제곱근으로 비교합니다. 큰 상자에서 10px 틀린 것과 작은 상자에서 10px 틀린 것이 같은 벌을 받으면 안 되기 때문입니다.
• 좌표 오차에 λ_coord = 5 를 곱하고, 물체 없는 칸의 신뢰도 오차에는 λ_noobj = 0.5 를 곱합니다. 대부분의 칸이 비어 있어서, 빈 칸의 목소리를 줄이지 않으면 학습이 「다 비었다」 쪽으로 쏠립니다. 4편의 focal loss 와 같은 문제를 상수 가중치로 다룬 셈입니다.

결과(논문)

같은 논문의 오류 분석에서 YOLO 는 위치 오류가 가장 큰 오류 유형이었습니다. 대신 배경을 물체로 착각하는 일은 Fast R-CNN 보다 적어서, 둘을 합치면 VOC 2012 에서 75.0(Fast R-CNN 단독 71.8)으로 올랐습니다. 그림 전체를 한 번에 보니 맥락 실수는 적고, 격자가 거칠어 위치는 덜 정확한 것입니다.

2. 계보: 앵커, 다중 해상도, 앵커 없이, NMS 없이

몇 가지 설계 이유를 짚으면 이렇습니다.

• k-평균 앵커(v2). 5편의 실험처럼 손으로 정한 앵커가 데이터의 물체 모양과 안 맞으면 구멍이 생깁니다. v2 는 학습 상자들을 1 − IoU 거리로 묶어 앵커를 정했고, 5개로 평균 IoU 61.0 을 내 손으로 고른 9개(60.9)와 비슷했습니다. 데이터에서 앵커를 정하면 적은 수로 충분합니다.
• 다중 해상도(SSD, v3). 작은 물체는 고해상도 지도, 큰 물체는 저해상도 지도에서 찾습니다. 5편의 FPN 과 같은 생각입니다.
• 앵커 없이(YOLOX). 앵커는 손으로 정하는 값(개수, 크기, IoU 문턱)을 늘립니다. 칸마다 상자 하나를 바로 내고, 어느 칸이 어느 정답을 맡을지를 학습 중에 동적으로 정하면 앵커가 필요 없습니다.
• NMS 없이(v10). NMS 는 망 밖의 후처리라서 시간이 들고, 문턱 하나로 겹친 물체와 중복을 가르지 못합니다(5편). 정답 하나에 예측 하나만 짝짓도록 학습하면 NMS 가 필요 없는데, 이것은 8편의 DETR 이 먼저 보인 생각입니다. v10 은 일대일 짝짓기만 쓰면 학습 신호가 적어지는 문제를, 학습 때 일대다 머리를 함께 두는 것으로 보완했습니다.

3. 직접 해 보기: AP 계산

검출 논문의 숫자는 거의 다 AP(Average Precision)입니다. 정답 공 5개가 있는 장면에서 검출기가 상자 8개를 냈다고 합시다. 점수 높은 순으로 정답과 IoU 0.5 이상으로 짝지어지면 맞음(1), 아니면 틀림(0)입니다(실측).

점수 순 맞음/틀림: [1, 1, 0, 1, 0, 1, 0, 0]
재현율: [0.2, 0.4, 0.4, 0.6, 0.6, 0.8, 0.8, 0.8]
정밀도: [1.0, 1.0, 0.67, 0.75, 0.6, 0.67, 0.57, 0.5]
AP = 0.683

AP 는 재현율(찾은 정답의 비율)을 가로축, 정밀도(낸 것 중 맞은 비율)를 세로축으로 한 곡선의 넓이입니다. 정밀도를 「오른쪽에서 본 최댓값」으로 펴서 계산합니다(모든 점 보간). 정답 5개 중 4개만 찾았으므로 재현율은 0.8 에서 멈추고, 그 뒤 넓이는 0 입니다.

같은 상자 8개라도 점수 순서가 바뀌면 AP 가 달라집니다.

AP 는 「맞혔나」뿐 아니라 「맞은 것에 높은 점수를 줬나」까지 채점합니다. 신뢰도 점수가 엉망인 검출기는 같은 상자를 내도 AP 가 낮습니다. 논문의 AP 를 읽을 때 기억해 둘 점입니다.

4. 실시간성이란

「실시간」은 상대적인 말입니다. 탁구 영상이 초당 60장이면 한 장에 쓸 수 있는 시간은 16.7ms 이고, 그 안에 디코딩·전처리·모델·후처리·판정이 다 들어가야 합니다. 논문의 fps 를 읽을 때는 조건을 같이 봐야 합니다.

• 하드웨어 등급: 데이터센터 GPU 와 휴대폰은 수십 배 차이가 납니다.
• 정밀도와 런타임: FP32 PyTorch 와 FP16 TensorRT 는 같은 모델도 몇 배 차이가 납니다(YOLOv10·RT-DETR 표는 TensorRT FP16).
• 배치: SSD 의 59fps 는 배치 8, 배치 1 이면 46fps 였습니다. 실시간 영상은 보통 배치 1 입니다.
• NMS 포함 여부: 망만 잰 시간인지, 후처리까지 잰 시간인지.

TT Score 의 공 찾기(BlurBall)는 서버 GPU 에서 창 하나(3프레임)에 10.5ms 였습니다(실측, TT Score 모델 해부 2편). 「몇 fps」보다 「한 장에 몇 ms, 무엇을 포함해서」로 적어야 비교가 됩니다.

5. 라이선스: AGPL 이 웹 서비스에서 뜻하는 것

YOLO 라는 이름은 여러 저장소가 나눠 씁니다. 라이선스가 저장소마다 다릅니다(각 LICENSE 파일, 2026-10-13 확인).

AGPL-3.0 은 GPL 에 네트워크 조항(13조)을 더한 것입니다. 프로그램을 고쳐서, 사용자가 네트워크로 그 프로그램과 상호작용하게 하면 그 사용자에게 고친 판의 소스 코드를 받을 방법을 제공해야 합니다. 배포하지 않고 서버에서만 돌려도 의무가 생긴다는 점이 GPL 과 다릅니다. Ultralytics 는 자기 안내 페이지에서 AGPL 의 공개 의무 없이 쓰려면(상업 제품, SaaS·API, 임베디드 기기, 상업적으로 쓰는 미세조정 모델 등) 기업 라이선스가 필요하다고 설명하고, 학습한 모델도 기본적으로 AGPL-3.0 을 따른다는 입장입니다. 마지막 주장(가중치에도 AGPL 이 미친다)이 법적으로 어디까지 성립하는지는 이 글이 판단할 수 없습니다. 다만 회사가 그렇게 주장하고 있다는 사실이 이미 위험 요소입니다.

TT Score 는 웹 서비스입니다. 그래서 공 찾기에는 코드가 MIT 인 WASB·BlurBall 을, 탁구대에는 Apache-2.0 인 SAM 2.1 을 골랐고, YOLO 계열 분할 모델은 AGPL 조건 때문에 후보에서 뺐습니다(TT Score 모델 해부 1편). 모델을 고를 때 정확도·속도와 같은 무게로 라이선스를 보는 이유입니다.

6. 한계와 우리 프로젝트

• 작은 물체. 격자 한 칸(v1 은 64px)보다 훨씬 작은 탁구공은 한 단계 검출기에도 어렵습니다. 다중 해상도로 나아졌지만, TT Score 는 공을 상자 대신 고해상도 히트맵으로 찾습니다(3편).
• NMS. 망 바깥의 후처리는 배포를 까다롭게 합니다. TT Score 의 자세 실험에서는 사람 검출기(RTMDet)의 ONNX 파일 안에 든 NMS 연산을 OpenCV DNN 이 읽지 못해, 사람 상자 대신 공 주변 상자로 우회했습니다(TT Score 모델 해부 4편). NMS 없는 검출기(v10, 8편의 DETR 계열)가 반가운 이유가 이런 데 있습니다.
• 같은 이름, 다른 모델. 「YOLO」라는 이름만으로는 구조도 라이선스도 정해지지 않습니다. 판 번호와 저장소를 함께 적어야 합니다.

다음 글은 합성곱을 버린 Vision Transformer 입니다.

티티 한마디. 같은 상자 여덟 개인데 점수 순서만 바꿨더니 AP 가 0.8 에서 0.4 가 됐어요. 맞힌 것에 자신 있게 높은 점수를 주는 것도 실력이에요.

참고 문헌

• Redmon, J., Divvala, S., Girshick, R., Farhadi, A. (2016). You Only Look Once: Unified, Real-Time Object Detection. CVPR 2016. https://arxiv.org/abs/1506.02640
• Liu, W. et al. (2016). SSD: Single Shot MultiBox Detector. ECCV 2016. https://arxiv.org/abs/1512.02325
• Redmon, J., Farhadi, A. (2017). YOLO9000: Better, Faster, Stronger. CVPR 2017. https://arxiv.org/abs/1612.08242
• Redmon, J., Farhadi, A. (2018). YOLOv3: An Incremental Improvement. arXiv. https://arxiv.org/abs/1804.02767
• Ge, Z., Liu, S., Wang, F., Li, Z., Sun, J. (2021). YOLOX: Exceeding YOLO Series in 2021. arXiv. https://arxiv.org/abs/2107.08430
• Wang, A. et al. (2024). YOLOv10: Real-Time End-to-End Object Detection. NeurIPS 2024. https://arxiv.org/abs/2405.14458
• Zhao, Y. et al. (2024). DETRs Beat YOLOs on Real-time Object Detection. CVPR 2024. https://arxiv.org/abs/2304.08069
• GNU Affero General Public License v3.0: https://www.gnu.org/licenses/agpl-3.0.html
• Ultralytics 라이선스 안내: https://www.ultralytics.com/license, 저장소 https://github.com/ultralytics/ultralytics
• 예제 코드와 출력: 이 폴더의 code/06_yolo_ap.py, code/06_yolo_ap.out.txt