불량 판정률이 갑자기 튀자 현장은 곧바로 모델 정확도를 의심했다. 하지만 로그를 따라가 보니 판정 모델보다 프레임 처리 타이밍이 먼저 흔들리고 있었다.
C++ 팀은 성능을 감으로 이야기하지 않았다. 어느 구간에서 몇 ms가 더 걸렸는지, 어떤 메모리 복사가 늘었는지를 수치로 좁혀 갔다.
문제를 좁혀 간 순서
08:20
모델 정확도 대신 프레임 드롭을 봤다
불량률보다 먼저 카메라 입력과 판정 스레드 간 지연 차이를 확인했다.
09:10
메모리 복사 구간이 늘어난 것을 발견했다
새 장비 드라이버 도입 이후 프레임 버퍼 복사가 한 번 더 생기면서 지연이 누적됐다.
11:00
판정 경로를 단순화하고 캐시 전략을 조정했다
정확도 코드를 건드리지 않고도 판정 타이밍을 다시 안정화할 수 있었다.
왜 C++가 필요한 장면이었나
이 문제는 단순한 웹 지연과 달랐다. 라인 속도와 카메라 입력, 메모리 복사 비용이 한 몸처럼 연결돼 있었다.
C++는 이 물리적 예산을 직접 다루게 해 준다. 그래서 성능 이슈를 “느리다”가 아니라 “어디에서 얼마를 썼는지”로 이야기할 수 있다.
팀이 다시 적어 둔 규칙
- 새 장비 드라이버 도입 시 프레임 복사 수를 반드시 측정한다.
- 성능 문제는 모델 정확도와 타이밍 이슈를 분리해서 본다.
- 메모리 소유권과 버퍼 생명주기를 코드 리뷰 항목으로 둔다.
인시던트에서 배운 점
- C++는 성능을 감이 아니라 구조와 비용으로 다루게 만든다.
- 비전/임베디드 현장에서는 모델보다 타이밍이 문제인 경우가 많다.
- 하드웨어 제어와 메모리 경계가 사업 품질과 직접 연결되는 분야에서 C++는 여전히 핵심이다.