Vision AI 제품 개발 과정 - (2) 데이터 가공, 학습데이터셋 구축, 모델 학습 및 검증

June 19, 2025

이 글은 Vision AI 제품 개발 과정의 두 번째 편으로,
전체 내용은 다음과 같은 흐름으로 구성되어 있습니다:

(1) Task 정의, 데이터 수집, 데이터 정제
(2) 데이터 가공, 학습데이터셋 구축, 모델 학습 및 검증
(3) 모델 최적화 및 경량화, 분석엔진 개발, 시스템 배포 및 운영

4. 데이터 가공

데이터 수집과 정제가 완료되면,
이제 본격적으로 학습 가능한 구조로 데이터를 가공하는 단계로 진입합니다.
바로 라벨링 작업입니다.

Vision AI 프로젝트 전체 과정 중 가장 노동집약적이면서도,
모델 품질을 좌우하는 민감한 구간입니다.

이 단계는 원시 데이터를 AI 모델이 이해할 수 있는 형태로 변환하며,
모델 성능을 결정짓는 핵심 기반을 마련하는 과정입니다.

AI Engineer는 라벨링에서 졸업할 수 없다

많은 분들이 라벨링은 신입이 하는 반복 업무라고 생각하실 수 있습니다.
실제로 많은 AI Engineer들이 커리어 초기에 처음 맡는 작업이 라벨링이기도 합니다.

하지만 그 인식은 반쯤만 맞습니다.
왜냐하면, 라벨링은 기계적인 작업이 아니라
AI 모델 성능을 결정짓는 정밀 공정이기 때문입니다.

또한 연차가 쌓이더라도 클래스 정의 변경, 기준 변경, QA 시스템 점검 등
경험자일수록 손을 댈 일이 계속 발생하는 구조입니다.

라벨링 방식

라벨링 방식	설명
BBox (bounding box)	객체 감지를 위한 기본 형태
Segmentation	보다 정밀한 경계가 필요한 경우
Keypoint / Pose	사람의 자세나 행동 분석을 위한 형태

프로젝트 성격에 따라 Instance 구분 여부도 달라집니다.

라벨링 작업을 시작하기 전에는 다음을 명확히 정리해야 합니다:

객체의 정의 기준
겹침/가림 처리 방식
흐릿하거나 작게 보이는 객체의 포함 여부
라벨 간 중첩 허용 여부
클래스 분류 기준

자동화 도구의 한계와 Human-in-the-loop

Roboflow, SAM(Segment Anything Model) 등 오토라벨링 도구의 확산으로
라벨링 속도와 효율이 많이 향상되었습니다.

또한 Active Learning, Semi-supervised Learning과 같은 기술도
라벨링 부담을 줄이기 위한 시도로 주목받고 있습니다.

하지만 실제 산업 Vision AI 프로젝트에서
라벨링의 주체는 여전히 사람입니다.
즉, 여전히 Human-in-the-loop 구조가 기본입니다.

그 이유는 다음과 같습니다:

작업 기준과 객체 정의가 고객사마다 다르고
클래스 기준이 자주 바뀌며
실시간성 및 정밀도가 중요한 경우가 많기 때문입니다.

폐쇄망 환경에서의 라벨링: 도구보다 사람이 먼저

특히 보안이 중요한 공장이나 화학설비 등에서는
폐쇄망 환경으로 인해 클라우드 기반 라벨링 툴 자체가 사용 불가능한 경우가 많습니다.

이럴 때는

전문 라벨러가 현장에 직접 투입되고
AI 엔지니어도 함께 입장해,
작업 기준을 실시간으로 조율하며 라벨링을 수행합니다.

화학공장 프로젝트에서는 라벨러들과 함께 작업장에 들어가
실내/실외 구분, 방독마스크 착용 조건 등 기준을 직접 설명하고
현장에서 수기로 라벨링 방향을 맞춰가며 데이터셋을 완성했습니다.

라벨러도 전문직이다

많은 분들이 라벨러를 기초적인 아르바이트 수준으로 오해하지만,
실제 산업 데이터 구축 프로젝트에 투입되는 라벨러는 전문성을 갖춘 인력입니다.

일정 기준 이상의 교육을 수료하고
데이터 라벨링 자격증(AIDE)을 보유한 경우도 있으며
정밀도와 재현율 기준에 따라 검수 피드백을 받으며 반복 개선합니다.

일부 라벨러는 AI Engineer보다 데이터에 대한 이해도가 깊기도 합니다.
즉, 라벨러는 객체 판단, 상황 이해, 데이터 규칙 해석이 포함된
정교한 작업을 수행하는 중요한 역할입니다.

라벨링 QA는 데이터 품질을 보장하는 마지막 방어선

라벨링이 끝났다고 바로 학습에 사용할 수는 없습니다.
QA(Quality Assurance)를 통해 라벨 품질을 검증해야 합니다.

일반적인 라벨링 QA 체계:

QA 방식	설명
이중 작업(Double labeling)	동일 데이터를 두 명이 작업, 결과 비교로 불일치 검수
샘플 검수(Sampling QA)	일부 샘플 검토로 전체 품질 예측
라벨 기준 문서화 및 교육	작업 전 기준 공유 및 준수 여부 확인
시각화 기반 검수	labelme, CVAT 등 도구로 육안 확인
AI 예측 결과와의 교차검수	초기 모델 예측 결과와 라벨 비교로 신뢰도 역검증

공식 프로젝트에서는 검수 기준이 수치화되기도 하며,
QA 리포트를 별도로 제출해야 하는 경우도 있습니다.

PoC 모델에서는 왜 직접 라벨링이 기본인가

PoC(Proof of Concept) 단계의 모델은 보통 빠르게 결과를 보여줘야 하고,
Task나 클래스 정의도 수시로 바뀔 가능성이 크기 때문에
외부 업체에 라벨링을 맡기기 어려운 구조입니다.

게다가 현실적으로는,
돈이 지급되는 PoC와 무상 기술 검토용 PoC가 완전히 다릅니다.

돈이 지급되는 PoC의 경우에는 일부 외주 활용이 가능하지만,
무상 PoC 혹은 내부 실험 성격의 PoC는 예산이 없기 때문에 외주를 줄 수조차 없습니다.

이런 경우, 결국 AI Engineer가 직접 라벨링까지 수행하게 됩니다.
또한, 초기 결과가 미흡할 경우 추가 라벨링, 클래스 구조 조정,
학습데이터 보강까지 모두 직접 반복하게 되는 구조입니다.

예상과 달리 실무에서는 PoC 단계가 더 어려운 경우가 많습니다.
오히려 Task 정의와 라벨 기준이 더 불안정하고,
반복 보정이 많기 때문에 직접 손을 대야 할 일이 더 많습니다.

PoC 단계에서는 제품 연동 없이 추론 결과만으로
기술 가능성을 보여줘야 하므로,
이 단계에는 분석엔진 연동이나 시스템 인터페이스 구성 없이
라벨링 → 모델 학습 → 추론 결과 제출 구조로만 운영됩니다.

정리

자동화 기술이 발전하더라도,
라벨링은 여전히 사람이 해야 하는 일입니다.

AI는 객체를 감지할 수 있어도
“이걸 진짜 안전모로 판단할지”는 사람의 몫입니다.

그리고 그것이 바로
AI Engineer의 피, 땀, 눈물이 라벨링에 녹아 있는 이유입니다.

라벨링은 모델 성능을 좌우하는 정밀 공정
Human-in-the-loop 구조가 여전히 기본
폐쇄망 환경에서는 현장 투입 필수
QA 체계를 통한 품질 확보 필요
PoC 단계에서는 직접 라벨링이 불가피함

라벨링은 디지털 인형눈 붙이기가 아닌,
AI가 현장에서 제대로 작동하도록 만드는 핵심 기반 작업입니다.

5. 학습데이터셋 구축

라벨링이 완료되면, 이제 본격적으로 학습에 사용할 데이터셋을 구성해야 합니다.
많은 분들이 이 단계를 train/val/test split 정도로 생각하지만,
모델 성능을 좌우할 수 있는 전략적 판단이 필요한 구간입니다.

이 단계의 목적은 실제 현장에서 발생할 수 있는 다양한 상황을
학습에 충분히 반영하는 것입니다.
클래스 불균형, 환경 변화, 시나리오 다양성 등을 고려해
데이터셋의 구조와 분포를 체계적으로 설계해야 합니다.

클래스 불균형은 피할 수 없다

Vision AI 프로젝트에서는 클래스 간 데이터 수가
자연스럽게 불균형해지는 구조를 가집니다.

예를 들어, 사람, 안전모, 보호복 등은
비교적 쉽게 많은 데이터를 확보할 수 있지만,
보안경, 방독마스크와 같은 작은 객체는
카메라 위치나 정면 시야 조건 등으로 인해 확보 자체가 어렵습니다.

이로 인해 특정 클래스의 수가 전체 데이터의 5%도 안 되는 경우도 자주 발생합니다.

시나리오/구역별 데이터 분포 전략

실내/실외, 주간/야간, 조도 등 다양한 환경 요소를 반영해야 하므로
데이터셋 분포를 다음 기준에 따라 점검합니다:

작업 구역별 (실내, 실외 등)
시나리오별 (모든 보호구 착용 / 일부 착용 / 미착용)
객체 조합별 분포 (사람+보호복 vs 사람+보호복+마스크 등)

클래스 수만 보는 것이 아니라,
현장에서 빈번하게 발생하는 조합이 충분히 반영됐는지를 확인해야 합니다.

train/val/test 분할 기준: 환경 독립성

train/val:
동일한 수집 환경 내에서 샘플링하되,
구역과 시나리오가 고르게 분포되도록 구성합니다.
test:
가능한 경우,
별도의 환경·시간대·카메라에서 수집한 데이터를 사용하는 것이 가장 이상적입니다.

test 세트는 모델이 처음 보는 상황에 얼마나 잘 대응하는지를 평가하기 위한 것이므로,
train/val과 최대한 독립적인 구성이어야 합니다.

데이터셋 보완 전략: 오픈데이터셋과 Background

불균형하거나 희귀한 클래스를 보완하기 위해
AIHub 등 오픈데이터셋을 병합하거나,
객체가 없는 Background 이미지를 추가해 Negative Set을 구성합니다.

예시:

방독마스크 → 외부 데이터셋에서 bbox 기준 유사 객체 병합
사람이 없는 작업장 배경 → False Positive 억제용 Background 추가

모든 이미지에 객체가 있는 경우,
모델이 “항상 무언가를 탐지해야 한다”고 오해할 수 있기 때문에
Negative 샘플의 비율 확보가 매우 중요합니다.

계절·기상 변화 대응을 위한 사전 설계

장기 운영되는 프로젝트라면
계절과 기상 변화에 대비한 사전 데이터 수집이 필요합니다.

특히 실외 작업장의 경우:

눈, 비, 안개, 낙엽 등 날씨 변화
해뜰녘, 정오, 해질녘, 야간 등 시간대 변화
사람이 없는 순수 배경 이미지

이러한 다양한 조건에서 데이터를 확보해두면
Domain Shift 발생 시에도 성능 저하 없이 대응할 수 있습니다.

데이터셋 최종 검수: 클래스와 시나리오 점검

모델 학습 전, 데이터셋의 품질을 점검하는 절차가 필요합니다:

클래스별 수량 파악
시나리오별 영상 수량 체크
클래스 중복, 누락 여부
오탈자, 잘못된 라벨링 누락 등

특히 프로젝트 초기에는 AI Engineer가 이 검수 과정을 반복하며
데이터셋 구조를 조정하게 되는 경우가 많습니다.

정리

좋은 모델은 좋은 데이터에서 나오고,
좋은 데이터는 균형 잡힌 시나리오와 철저한 검수에서 만들어집니다.

클래스 불균형은 불가피하므로 대응 전략이 필요
train/val/test는 환경 독립성 기준으로 분할
부족 클래스는 오픈데이터셋과 Background 이미지로 보완
Negative Set 추가는 False Positive 억제에 효과적
계절·기상 변화 대응을 위한 사전 수집은 필수
클래스/시나리오별 분포를 수치로 점검하고 기록

데이터셋 구성은 AI가 현장에서 어떤 상황에서 무엇을 판단해야 하는지를
학습 가능한 구조로 설계하는 작업입니다.
이 과정이 곧 프로젝트의 성공 가능성을 결정합니다.

6. 모델 학습

학습 데이터셋 구성이 끝났다면, 이제 실제로 모델을 학습시키는 단계입니다.
train.py를 실행하는 것만으로 끝나는 게 아니라,
프로젝트 성격과 Task 정의에 맞는 학습 전략을 수립하는 과정입니다.

이 단계에서는 모델을 훈련시키는 것을 넘어서,
현장 환경에서 요구되는 성능과 제약 조건을 모두 만족하는 모델을 만들어야 합니다.
특히 실시간성, 정확도, 리소스 효율성 사이의 균형을 찾는 것이 핵심입니다.

모델 선택 기준: 실시간성과 정확도의 균형

산업 현장의 실시간 CCTV 기반 Vision AI 프로젝트에서는
Ultralytics YOLO 계열(YOLOv8, v11)이 가장 널리 사용됩니다.
실시간성과 정확도를 동시에 요구하는 경우가 많기 때문입니다.

모델 선택 기준	추천 모델	특징
실시간성 중시	YOLOv8n/s	빠른 추론 속도, 경량화
정확도 중시	YOLOv11L, YOLOv12L	높은 정확도, 메모리 사용량 큼

YOLOv12의 경우 Transformer 기반 구조로 인해 정확도는 높지만,
메모리 사용량이 커서 OOM 오류가 자주 발생합니다.
서버 자원이 제한된 경우 YOLOv11 계열을 더 선호하는 편입니다.
(실제로 저 역시 v11 계열을 가장 많이 활용합니다.)

모델 선택은 다음 요소에 따라 결정합니다:

속도 vs 정확도 Trade-off
운영 환경(GPU 사양, 실시간 여부)
변환 호환성 (ONNX, TensorRT 등)

학습 파라미터 설정 전략

imgsz: 1280        # 입력 이미지 크기 (보통 FHD 기준)
batch: 8~32        # GPU 메모리 따라 조절 (A40 기준 8~16 추천)
epochs: 100~1000   # 상황에 따라 탄력적 설정
patience: 100       # Early Stopping 기준

대부분 A40, L40S 등 서버급 GPU를 사용
batch size가 너무 크면 OOM(Out-Of-Memory) 오류 발생
epoch는 100부터 시작하되,
폐쇄망 환경에서는 nohup으로 백그라운드 학습을 자주 수행
여러 설정 조합의 학습 스크립트를 미리 준비해두고,
1000 epoch 이상 장기 실행하는 방식으로 운용

실시간 환경 고려사항

입력 해상도를 너무 낮추면 소형 객체 검출 성능이 떨어짐
실시간 시나리오의 경우 FPS 목표에 맞춰 imgsz와 모델 크기 조율

데이터 증강 (Augmentation): Flip도 함부로 쓰면 안 된다

증강 방식	설명
Horizontal Flip	좌우 반전
HSV 조정	색상·채도·밝기 조정
Scale / Translate	크기 조정 및 이동
Mosaic, Mixup	YOLO 기본 내장

실무에서는 Augmentation도 무조건 많을수록 좋은 것이 아니라,
데이터의 특성과 클래스 구조에 따라 조정하는 것이 중요합니다.
특히 Flip은 Horizontal만 해야 합니다.

학습 중 모니터링과 점검 루틴

TensorBoard / W&B 로그로 과적합 여부 확인
Validation 추이 모니터링
특정 클래스 mAP이 낮을 경우 라벨링·데이터셋 재검토
모델 저장 중단 방지를 위한 주기 저장 옵션 설정

폐쇄망 환경에서의 실험 설계와 백업 플랜

train.sh 스크립트를 다양한 조합(imgsz, batch, epochs 등)으로 작성
nohup으로 백그라운드 학습 실행
접속이 어려운 환경에서는 한 번에 다양한 조건으로 장기 학습 설계
튜닝 기회가 제한되므로 최대한 미리 실험 계획 구성 필요

하드웨어 환경에 따른 MKL 설정

PyTorch, NumPy, SciPy 등 주요 프레임워크는
고속 수치 연산을 위해 내부적으로 MKL(Intel Math Kernel Library)을 사용합니다.

MKL은 인텔 CPU에 최적화된 수학 연산 라이브러리로,
선형대수, FFT, 행렬 곱셈 등에서 높은 성능을 제공합니다.

하지만 AMD 등 인텔이 아닌 CPU 환경에서는
다음과 같은 문제가 발생할 수 있습니다:

학습 중 불규칙한 멈춤 현상
연산 속도 저하 및 불안정한 계산 흐름
CPU 최적화 경로가 정상적으로 작동하지 않음

이러한 문제를 방지하기 위해,
아래 환경 변수를 반드시 export해야 합니다:

export MKL_SERVICE_FORCE_INTEL=TRUE

이 설정은 MKL이 인텔 CPU용 연산 경로를 강제로 사용하도록 하여,
비인텔 CPU에서도 안정적인 실행이 가능하도록 도와줍니다.

.bashrc 등 실행 스크립트에도 이 설정을 추가하는 것을 권장합니다.

성능 지표

mAP(mean Average Precision)
Precision / Recall 곡선
Confusion Matrix
시각화된 예측 결과 (예: bbox overlay 결과)

수치만으로 평가하지 말고, 실패 케이스를 직접 시각화하여 원인을 분석해야 합니다.

정리

학습은 모델의 첫 번째 성장입니다.
결국 학습 파라미터 하나하나가 현장 환경에서 얼마나 잘 작동할지를 좌우합니다.

YOLO 계열은 실시간 CCTV 프로젝트에서 주력 사용
GPU OOM 방지를 위해 batch는 여유 있게
폐쇄망 환경에서는 nohup과 조합별 스크립트 준비
Intel CPU 여부에 따른 환경 설정 필수
모델 크기는 속도·정확도 요구사항에 따라 조정
학습은 실행보다 설계가 더 중요

실행보다 중요한 것은, 운영 환경을 고려한 설계입니다.
그리고 그것이 바로 실무에서의 학습입니다.

7. 모델 검증

모델 학습이 완료되면,
이제 실제 환경에서 얼마나 잘 작동하는지를 검증하고 평가하는 단계입니다.

mAP 수치만으로는 충분하지 않습니다.
해당 모델이 실제 과업에 부합하는 성능을 보이는지,
현장 적용이 가능한 신뢰성과 정확도를 갖추었는지를 중심으로 검토해야 합니다.

검증 지표 구성

Vision AI 모델의 성능 평가는 다음과 같은 정량·정성 지표 조합을 기준으로 수행합니다:

지표	설명
mAP	전체 클래스 평균 정확도, 성능 추세 확인용
Precision / Recall	탐지 신뢰도 vs 놓치는 비율
F1 Score	Precision과 Recall의 조화 평균
Confusion Matrix	클래스별 분류 정확도 시각화
Detection Examples	실제 예측 결과 이미지 시각화 (bbox 포함)

수치만으로 부족한 경우,
오탐 / 미탐 사례를 시각화해 검토하는 작업이 필수입니다.

실시간성 평가

Vision AI 시스템은 대시보드, 알림 시스템 등과 연동되는 경우가 많기 때문에
실시간 추론 속도 역시 주요 검증 항목입니다.

Frame 당 처리 시간 (ms/frame)
초당 추론 가능 프레임 수 (FPS)

실시간성 확보 여부는 시스템 전체 신뢰도와 직결됩니다.

벤치마크 기준 설정

모델이 현장에서 통과해야 할 성능 기준선(벤치마크)을
고객과 사전에 협의하고 명확히 설정해두는 것이 좋습니다.

예시:

안전모 인식 정확도 ≥ 95%
마스크 착용 탐지 누락률 ≤ 5%
실시간 추론 속도 ≥ 10 FPS

이러한 기준은 운영 SLA(Service Level Agreement)의 근거가 되며,
추후 모델 유지보수 또는 재학습 판단 시 기준으로 활용됩니다.

실제 데이터 기반 검증

검증 데이터는 라벨링 기준이 완성도 높고,
현장 환경과 유사한 조건이어야 의미가 있습니다.

수집 당시 조명, 카메라 위치, 각도, 해상도 일치 여부
시나리오 별로 정상/비정상 케이스 균형 있게 포함
실제 현장과 도메인 차이가 크지 않도록 구성

필요 시, 실제 현장 CCTV 영상 일부를 테스트셋으로 분리해 사용하는 경우도 있습니다.

수동 검수와 시각화 기반 검토

수치 기반 검증 외에도 사람이 직접 예측 결과를 눈으로 검토하는 과정이 중요합니다.

bbox 시각화 이미지에서 누락, 오탐, 위치 오류 확인
특정 클래스에서 반복적으로 낮은 성능 → 클래스 통합, 세분화, 라벨 보완 또는 데이터 보강
시간이 걸리더라도, 현장 운영 중 오류 발생 가능성을 줄이는 데 매우 효과적

정리

모델 검증은 단순한 수치 평가가 아니라,
실제 적용 가능한 수준인지 판단하는 현장 적합성 테스트입니다.

mAP, Precision/Recall, F1 Score 등 지표 기반 분석
시각화 기반 수동 검토로 오류 검출
고객 기준선(SLA)에 맞는 벤치마크 통과 여부 확인
실시간성·클래스별 신뢰도까지 포함해 다각도 검토

검증 결과는 운영 시스템 반영뿐 아니라,
필요 시 재학습과 모델 개선의 기준이 됩니다.

Share on

Twitter Facebook LinkedIn

indexkim