저는 예전에 컴퓨터 비전(Computer Vision)이 모델의 문제라고 생각했습니다. 하지만 그것은 파이프라인(Pipeline)의 문제이며, 모델은 쉬운 부분입니다.

제가 계속해서 목격하는 패턴은 이렇습니다. 한 팀이 탐지기(Detector)를 학습시키거나 미세 조정(Fine-tuning)하여 정제된 클립(Curated clip)에서 인상적인 수치를 달성하면 모두가 박수를 칩니다. 하지만 그것이 실제 세상에 나가면 무너져 버립니다. 조명이 잘못되었습니다. 카메라가 움직였습니다. 누군가 학습 세트에서 본 적 없는 색상의 옷을 입었습니다. 응답이 0.5초 늦게 도착하면 전체 시스템이 고장 난 것처럼 느껴집니다. 데모는 성공했지만, 제품은 실패한 것입니다.

저는 이제 카메라 기반의 제품을 충분히 출시해 보았기에, 대부분의 사람들이 처음에 갖는 사고 모델(Mental model)이 틀렸다고 믿습니다. 컴퓨터 비전은 "사물을 인식하는 모델"이 아닙니다. 그것은 실시간 루프(Real-time loop)입니다. 즉, 당신이 통제할 수 없는 세상 속에서 빠르고 신뢰할 수 있게 감지(Sense)하고, 결정(Decide)하고, 행동(Act)하는 것입니다. 모델은 그 루프의 한 노드(Node)일 뿐입니다. 모델을 작동하게 만드는 것은 기본 조건(Table stakes)입니다. 루프를 유지되게 만드는 것이 실제 엔지니어링입니다.

모델은 제품이 아니라 하나의 노드입니다

만약 당신이 어떤 실시간 시스템이라도 구축해 본 적이 있다면, 이러한 프레임워크가 익숙하게 느껴질 것입니다. 비전 모델을 요청 경로(Request path)에 있는 단일 서비스처럼 생각하십시오. 모델은 입력을 받고, 출력을 생성하며, 지연 시간(Latency) 비용이 발생합니다. 그것이 시스템 전체는 아닙니다. 시스템은 그 주변의 모든 것입니다. 프레임이 어디서 오는지, 출력에 어떤 일이 일어나는지, 전체 체인이 얼마나 빨리 실행되는지, 그리고 모델이 틀렸을 때(틀릴 것이기 때문입니다) 제품이 어떻게 작동하는지 등이 포함됩니다.

탐지(Detection)는 제품의 절반에 불과합니다. 유용한 비전 시스템은 루프를 완성합니다. 무언가를 감지하고, 그것이 무엇을 의미하는지 결정한 다음, 응답이 이벤트와 연결된 것처럼 느껴질 만큼 충분히 빠르게 실제 세상에서 눈에 보이는 행동을 수행합니다. 빠르고 신뢰할 수 있는 응답 없는 감지는 제품이 아니라 과학 프로젝트일 뿐입니다.

제가 들 수 있는 가장 명확한 사례는 제가 모든 소프트웨어 개발을 담당하고 있는 제품인 Raqts입니다. 이것은 반응형 라켓 스포츠 벽(racquet-sport wall)입니다. 사용자가 벽을 치면, 시스템은 사용자가 어떻게, 어디를 쳤는지에 따라 실시간으로 반응합니다. 카메라와 비전 파이프라인 (vision pipeline)이 플레이를 읽고, 시스템이 응답합니다. 이 루프의 모든 단계가 빠르고 신뢰할 수 있어야만 이 방식은 작동합니다. 늦은 판독은 벽을 "약간 덜 정확하게" 만드는 것이 아닙니다. 그것은 벽이 고장 난 것처럼 느껴지게 만듭니다. 실시간 (Real-time)은 점진적인 차이가 아니라 이진법적인 (binary) 경험입니다.

작동 여부를 결정하는 네 가지 요소

비전 데모 (vision demo)는 쉽습니다. 하지만 비전 제품 (vision product)은 그렇지 않습니다. 네 가지 동인이 당신이 어떤 결과물을 갖게 될지를 결정하며, 이것들이 바로 실제 예산과 리스크가 집중되는 지점입니다. 이 중 어느 것도 "더 나은 모델을 선택하라"는 것이 아닙니다.

1. 실제 환경에서의 정확도, 이는 전혀 다른 숫자입니다

큐레이션된 클립 (curated clip)에서 얻는 정확도와 프로덕션 (production) 환경에서 얻는 정확도는 서로 다른 두 개의 숫자이며, 오직 하나만이 중요합니다. 물리적 세계는 신뢰할 수 없는 사용자 입력 (untrusted user input)이 적대적인 것과 마찬가지로 적대적입니다. 물리적 세계는 당신이 테스트하지 않은 조명, 설치하지 않은 각도, 그리고 깨끗한 데이터에는 결코 없었던 배경의 혼란스러움을 당신에게 던져줄 것입니다.

이를 입력 유효성 검사 (input validation)처럼 취급하십시오. 제어된 녹화본에서 얻은 숫자를 신뢰하지 못하는 것처럼, 요청 본문 (request body)이 한 번 파싱되었다고 해서 그것을 신뢰해서는 안 됩니다. 진정한 정확도는 대표성 있는 데이터 (representative data), 까다로운 사례 테스트 (hard-case testing), 그리고 모델이 실패하는 지점에 대한 정직한 측정으로 얻어집니다. 가장 먼저 던져야 할 질문은 "얼마나 정확한가"가 아니라 "어떤 실제 조건 하에서 정확하며, 그것을 어떻게 알고 있는가"여야 합니다.

2. 지연 시간 예산 (latency budget)은 엄격한 제약 조건입니다

상호작용이 필요한 모든 것에서 응답은 이벤트와 연결되어 있다는 느낌을 주어야 합니다. 이는 카메라에서 추론 (inference)을 거쳐 동작에 이르기까지의 엔드 투 엔드 (end-to-end) 예산을 부여하며, 이는 게임 루프의 프레임 예산 (frame budget)이나 서비스의 p99 목표와 마찬가지로 엄격한 엔지니어링 제약 조건입니다. 이는 어떤 모델을 사용할지, 어디서 실행할지, 어떤 하드웨어에서 구동할지와 같은 다른 모든 선택을 결정짓습니다.

정확하지만 느린 시스템은, 빠르지만 틀린 시스템만큼이나 실시간 제품으로서 확실히 실패합니다. 만약 Raqts가 0.5초 늦게 타격(hit)을 읽는다면, 그 어떤 정확도로도 제품의 사용감을 살릴 수 없을 것입니다. 당신은 이 두 가지를 동시에 엔지니어링해야 하며, 예산은 모델을 선택한 후에 발견되는 것이 아니라 모델을 고르기 전에 이미 고정되어 있습니다.

3. 모델이 실행되는 위치는 아키텍처 결정 사항입니다

비전 모델(Vision model)은 컴퓨팅 비용이 저렴하고 유연한 클라우드(Cloud)에서 실행될 수도 있고, 카메라 옆에 있는 장치인 엣지(Edge)에서 실행될 수도 있습니다. 이는 다른 분야에서 이미 알고 있는 클라우드 대 로컬(Cloud-versus-local)의 트레이드오프(Trade-off)와 동일한 형태를 가집니다.

클라우드는 구축과 업데이트가 더 간단하지만, 네트워크 왕복 시간(Network round-trips)과 연결성에 대한 강력한 의존성을 추가합니다. 엣지는 지연 시간(Latency)을 낮게 유지하고 오프라인에서도 작동하지만, 현장 하드웨어가 처리할 수 있는 범위로 제약을 받으며 업데이트를 더 어렵게 만듭니다. 실시간성이 중요하거나 개인정보 보호에 민감한 제품은 엣지 쪽으로 기울며, 배치(Batch) 처리 방식이거나 오차를 허용할 수 있는 제품은 클라우드 쪽으로 기울어집니다. 이 단 하나의 결정은 비용, 속도, 신뢰성에 연쇄적인 영향을 미치므로, 습관에 따라 결정하지 말고 실제 지연 시간과 연결성 수치를 바탕으로 의도적이고 조기에 결정해야 합니다.

4. 하드웨어 접점(Hardware seams)은 각각 하나의 작은 프로젝트입니다

비전 제품은 소프트웨어만으로 존재하는 경우가 드뭅니다. 선택하고 배치해야 할 카메라가 있고, 제어해야 할 마운트(Mounts)와 조명이 있으며, 종종 소프트웨어가 동기화하여 구동해야 하는 액추에이터(Actuators), 센서(Sensors) 또는 디스플레이(Displays)가 있습니다. 이것이 구축 과정의 IoT 측면이며, 타이밍(Timing), 고장 모드(Failure modes), 그리고 순수 웹 앱은 결코 직면하지 않는 물리적 제약과 같은 모든 하드웨어 접점의 무게를 감당해야 합니다.

Raqts는 벽, 카메라, 그리고 반응형 피드백이 하나의 시스템으로 작동하는 것입니다. 이는 화면으로만 구성된 앱과는 진정으로 다른 구축 방식입니다. 제가 계속해서 다시 배우는 교훈은 이것입니다: 하드웨어 접점의 개수를 정직하게 산정하십시오. 왜냐하면 모든 서드파티 통합(Third-party integration)이 일반적인 구축 과정 내의 작은 프로젝트인 것처럼, 각 접점 또한 프로젝트 내부의 작은 프로젝트이기 때문입니다. 고장 모드는 모델이 아니라 접점에 존재합니다.

현재 제가 범위를 산정하는 방법

이 방식은 제가 어떤 0에서 1을 만드는 빌드(zero-to-one build)를 할 때 사용하는 원칙과 동일합니다. 누군가 숫자를 제시하기 전에 위험 요소가 있는 부분을 먼저 명명하는 것입니다. 컴퓨터 비전(Computer Vision)의 경우, 이는 다섯 가지 질문으로 요약됩니다.

• 모델이 내려야 할 단 하나의 결정을 정의하십시오. 탐지(Detect), 분류(Classify), 카운팅(Count), 또는 추적(Track) 중 하나를 정해야 합니다. 신뢰할 수 있게 수행되는 하나의 명확한 비전 작업이 모호한 다섯 가지 작업보다 낫습니다. 그 외의 모든 것은 다운스트림 소프트웨어(downstream software)의 영역입니다.
• 실제 환경 조건을 확정하십시오. 조명, 각도, 거리, 속도, 그리고 실제로 발생하는 엣지 케이스(edge cases)를 정의해야 합니다. 이 목록이 데모(demo)와 제품(product)을 가르는 차이점입니다.
• 지연 시간 예산(latency budget)을 설정하십시오. 응답이 얼마나 빠르게 느껴져야 하는지 결정하십시오. 왜냐하면 그 제약 조건이 모델과 실행 위치를 결정하기 때문입니다.
• 엣지(edge) 대 클라우드(cloud)를 의도적으로 결정하십시오. 습관에 의해서가 아니라, 지연 시간, 연결성, 그리고 개인정보 보호 요구 사항에 따라 결정해야 합니다.
• 하드웨어 접점(hardware seams)을 파악하십시오. 카메라, 마운트, 조명, 그리고 시스템이 물리적으로 반응하여 구동해야 하는 모든 것을 포함합니다.

이 다섯 가지를 명확히 하면, 추정치는 막연한 믿음이 아니라 정의된 대상에 대한 논의가 됩니다.

AI가 실제로 변화시킨 부분

이 부분이 진정으로 변화한 지점이며, 사람들이 예상하는 부분과는 다릅니다. 몇 년 전만 해도 맞춤형 비전 역량은 대규모 데이터셋을 수집하고 모델을 처음부터 학습시키는 것을 의미했습니다. 이는 너무 느리고 비용이 많이 들어서 막대한 예산이 있는 경우에만 시도할 수 있었습니다. 이제 현대적인 파운데이션 모델(foundation models)과 성숙한 비전 툴링(vision tooling) 덕분에 훨씬 더 빠르게 강력한 첫 번째 버전을 구현할 수 있습니다.

하지만 그것이 무엇을 하는지 주목하십시오. 그것은 힘든 일을 없애는 것이 아니라, 옮기는 것입니다. 모델을 구축하는 비용이 저렴해지면, 여러분의 노력은 항상 진짜 작업이었던 부분들, 즉 실제 환경에서의 정확도, 지연 시간 루프(latency loop), 그리고 하드웨어 통합(hardware integration)에 더 많이 투입됩니다. 희소한 기술은 "모델을 학습시킬 수 있는가"에서 "어떤 비전 작업이 실제로 문제를 해결하는지, 그리고 실제 환경의 고장 모드(failure modes)가 어디에 숨어 있는지 알고 있는가"로 변했습니다.

그것이 현재 컴퓨터 비전 (Computer Vision)의 솔직한 상태입니다. 작동하는 프로토타입 (Prototype)을 만드는 장벽은 바닥까지 낮아졌습니다. 하지만 작동하는 제품을 만드는 장벽은 전혀 움직이지 않았습니다. 왜냐하면 문제는 결코 모델 (Model)이 아니었기 때문입니다. 그것은 언제나 루프 (Loop)였습니다.

컴퓨터 비전 제품은 모델이 아닙니다. 그것은 루프입니다: 당신이 통제할 수 없는 세상 속에서, 빠르고 신뢰할 수 있게 보고, 결정하고, 행동하는 것입니다. 이 네 가지 동력 (Drivers)을 제대로 갖춘다면, 당신은 물리적 세계를 감지하고 그에 반응하는 소프트웨어를 갖게 됩니다. 이를 건너뛴다면, 실제 환경과 접촉하는 순간 결코 살아남지 못할 데모 (Demo)를 갖게 될 뿐입니다.

제가 고객들에게 전달하는 체크리스트가 포함된, 구매자 대상의 더 긴 버전이 필요하시다면, Null Studio 블로그인 nullstud.io에 작성해 두었습니다.