행동 분류 추론 파이프라인 — 처리량 4.4배

6축 IMU raw 신호에서 903개 특징을 뽑아 행동을 분류하는 프로덕션 코어 패키지를 재작업해 처리량 4.4배, E2E 3.3배를 얻었다.

4.4×처리량
423win/sec
208 / 0pass / fail

문제

센서에서 올라온 6축 IMU raw 신호를 윈도우로 자르고 903개 특징을 추출해 행동을 분류하는 코어 패키지가 있었다. 이게 파이프라인 전체의 병목이었다. 실개체 하루치를 처리하는 데 E2E 65.8초가 걸렸고, 개체 수가 늘수록 재학습·재처리 주기가 그만큼 밀렸다.

문제는 이걸 건드리면 모델 출력이 바뀔 수 있다는 점이었다. 특징 하나의 수치가 미세하게 달라져도 학습된 분류기의 판정이 흔들린다. 속도를 얻자고 결과를 바꿀 수는 없었다.

한 일

병목의 정체부터 측정했다. 외부 라이브러리 호출 하나가 시간의 대부분을 먹고 있었다.

  • 그 라이브러리를 NumPy 재구현으로 대체했다. 다만 교체 전에 기존 출력과의 수치 동일성을 먼저 검증했다. 동일성이 확인된 뒤에야 바꿨기 때문에 결과 변화 없이 병목만 사라졌다.
  • 가장 느린 특징 세트를 선별적으로 벡터화했다. 63개 중 61개만 처리하고 나머지 2개는 per-row로 남겼다 — 벡터화했을 때 메모리 사용과 코드 복잡도가 얻는 속도보다 컸다. 전부 바꾸는 게 목표가 아니라 이득이 있는 곳만 바꾸는 게 목표였다.
  • 모델 로딩을 로컬 파일 폴백 구조에서 레지스트리 단일 경로로 정리했다. 어떤 모델이 실제로 서빙되고 있는지 추적 가능해졌다.
  • 입력 검증 게이트를 추가하고, 동작을 바꾸지 않는 범위에서 코드 중복을 제거했다.

결과

처리 속도 · win/sec · 높을수록 좋음
이전
96
이후
423
E2E 파이프라인 · 초 · 낮을수록 좋음
이전
65.8
이후
19.9

실개체 24시간 raw 216만 행 / 8,640 윈도우 기준. 전체 테스트 208 passed / 0 failed — 출력은 한 값도 바뀌지 않았다.