face_recognition은 입문에 더없이 좋지만, 모든 도구가 그렇듯 경계가 있습니다. 이 장에서는 이 라이브러리의 한계를 과장 없이 정직하게 짚습니다. 한계를 분명히 알아야 "언제까지 face_recognition으로 충분하고, 언제 다른 도구로 갈아탈지"를 스스로 판단할 수 있습니다.

정확도의 천장

face_recognition이 쓰는 dlib 128차원 모델은 2017년 무렵의 기술입니다. 정면의 깨끗한 얼굴에서는 훌륭하지만, 최신 모델(PART 07의 ArcFace 계열)에 비하면 어려운 조건에서 뒤처집니다.

즉 "소규모, 정면 위주, 통제된 환경"에서는 face_recognition으로 충분합니다. 반대로 다양한 각도와 대규모가 섞이면 천장에 부딪힙니다.

dlib에 묶여 있다는 점

face_recognition은 dlib 위에 올라간 얇은 껍데기입니다. 장점이자 단점입니다. 장점은 PART 01에서 conda로 dlib을 깔아 둔 덕에 바로 쓸 수 있다는 것이고, 단점은 dlib의 제약을 그대로 물려받는다는 것입니다.

특히 GPU 가속을 제대로 쓰려면 dlib을 CUDA 지원으로 직접 빌드해야 하는데, 이는 PART 01에서 우리가 일부러 피한 바로 그 빌드 지옥입니다. CPU만으로도 소규모는 충분하지만, 빠른 GPU 추론이 필요해지는 순간 설치 난이도가 급등합니다.

유지보수의 정체

현실적인 함정이 하나 더 있습니다. face_recognition 패키지 자체의 업데이트가 오랫동안 활발하지 않습니다. 새 파이썬·새 의존성 환경에서 설치가 매끄럽지 않을 때가 있고, 최신 기법이 반영되지도 않습니다.

이는 "지금 안 된다"는 뜻이 아니라 "미래가 보장되지 않는다"는 신호입니다. 학습용·프로토타입으로는 훌륭하지만, 몇 년을 운영할 제품의 핵심 엔진으로 삼기에는 위험이 따릅니다. 그래서 이 책은 face_recognition을 "개념을 잡는 입문 도구"로 자리매김하고, 다음 장과 이어지는 PART에서 대안을 함께 제시합니다.

갈아탈 시점을 알리는 신호

다음 신호가 보이면 다른 도구를 검토할 때입니다.

• 옆얼굴·마스크·저조도에서 오인·누락이 잦아진다 → 더 강건한 모델 필요
• 등록 인원이 수천 명을 넘어 비교가 느려진다 → 대규모용 인덱싱 필요(PART 07)
• 감정·나이·성별 같은 분석이 추가로 필요해진다 → 올인원 도구(PART 06)
• GPU로 속도를 높여야 하는데 dlib 빌드가 막힌다 → 설치 부담 적은 대안 필요

실무 팁. 도구를 바꿀 때 코드 전체를 갈아엎지 않도록, 인식 부분을 함수 하나로 감싸 두세요. 예컨대 get_embedding(image)처럼 입력과 출력만 정해 두면, 내부를 face_recognition에서 InsightFace로 바꿔도 나머지 코드는 그대로 둘 수 있습니다. PART 04에서 강조한 "검출·인식 부분만 갈아 끼우는 구조"가 여기서 빛을 발합니다.

이 장에서 기억할 것

face_recognition은 정면·소규모·통제된 환경에서는 충분하지만, 옆얼굴·대규모·GPU가 필요한 순간 정확도와 설치 양쪽에서 천장에 부딪힙니다. dlib 의존과 패키지 유지보수 정체는 미래를 보장하지 못한다는 신호입니다. 인식 부분을 함수로 감싸 두면 갈아타기가 쉬워집니다. 다음 장에서는 그 첫 대안으로, 설치 없이 OpenCV에 내장된 SFace를 만납니다.