학습된 머신러닝 모델을 실제 서비스에 바로 연결하는 건 생각보다 복잡합니다. 단순히 모델을 만든다고 끝이 아니라, 실시간 예측 요청을 안정적으로 처리할 수 있어야 비로소 ‘배포 완료’라 할 수 있죠. 이때 가장 많이 사용되는 솔루션이 바로 TensorFlow Serving입니다. 성능 좋고 확장성 있는 서빙 시스템을 고민 중이라면, 이 포스팅을 끝까지 보세요. 실무자 입장에서 쓴 현실적인 구축 방법과 운영 노하우까지 풀어보겠습니다.
- TensorFlow Serving이 왜 필요한지부터 제대로 짚고 넘어가야 합니다.
- 모델 저장은 단순한 저장이 아니라 버전 관리까지 고려해야 해요.
- 서빙 서버는 Docker로 띄우는 게 가장 간단하고 강력한 방법입니다.
- REST API와 gRPC 중 어떤 요청 방식이 당신에게 더 맞을지도 따져봐야죠.
- 확장성과 성능을 고려한 실제 사례까지 함께 보면 훨씬 감이 잡힐 겁니다.
1. TensorFlow Serving은 단순한 ‘모델 서버’가 아니다
처음엔 “그냥 모델만 띄우면 되지” 싶었죠. 그런데 막상 해보면, 병목 생기고, 예측 요청이 중복되고, 예전 버전 모델로 응답 오고 난리가 납니다. TensorFlow Serving은 이런 문제를 해결하는 고성능 서버입니다. 구글 내부에서도 대규모 모델 서빙에 사용하고 있을 만큼 안정성과 성능이 보장돼 있어요.
무엇보다 좋은 점은 모델 버전 관리, 배치 처리, GPU 최적화 같은 기능이 기본 탑재돼 있다는 점이에요. 한마디로 머신러닝 모델 서빙에 특화된 전용 서버라고 보면 됩니다.
✨ 이런 분들에게 딱
- 하루 수천 건 이상 예측 요청이 들어오는 서비스를 운영 중인 분
- 모델을 자주 교체하거나 테스트 버전과 운영 버전을 병행하고 싶은 분
- 도커 기반으로 쉽게 운영하고 싶은 머신러닝 개발자
2. 모델은 SavedModel 형식으로 꼭 저장해야 합니다
TensorFlow Serving은 SavedModel
형식만 인식합니다. Keras 모델을 저장할 때는 다음과 같이 저장하죠:
tf.saved_model.save(model, “exported_model/1”)
여기서 숫자 1
은 모델 버전을 의미합니다. 이 구조가 중요한 이유는, 버전 관리가 가능하기 때문입니다. 예를 들어 2
라는 폴더를 추가하면 기존 모델을 교체하지 않고 새 모델을 추가로 배포할 수 있어요. 추후 롤백도 손쉽게 가능하죠. 버전 관리 안 되면 실서비스 중에 오류 하나만 나도 대혼란이 벌어집니다.
💡 실무 팁
- 버전 번호는 정수만 허용되며, 문자 포함된 폴더는 무시됩니다.
- 하나의 model_base_path 아래 여러 버전을 둘 수 있습니다.
3. Docker로 띄우면 서버 세팅이 확 쉬워집니다
TensorFlow Serving을 설치하는 가장 간단한 방법은 도커(Docker)를 활용하는 겁니다. 복잡한 환경 설정 없이 바로 서빙 가능합니다.
docker run -p 8500:8500 -v "$(pwd)/exported_model:/models/my_model" -e MODEL_NAME=my_model tensorflow/serving
위 명령어는 현재 디렉토리에 있는 exported_model
을 my_model
이라는 이름으로 서빙합니다. 기본적으로 gRPC(8500)
와 REST(8501)
를 지원하죠. 포트 포워딩도 명확하게 설정할 수 있어요.
📌 도커 사용이 어려울 때는?
직접 바이너리를 설치하는 방법도 있습니다. 하지만 의존성 문제로 인한 빌드 에러가 꽤 빈번하기 때문에 추천하진 않아요. 특히 Mac에서는 gRPC 관련 컴파일 문제가 자주 생깁니다.
4. REST와 gRPC 요청 방식, 뭐가 다를까?
TensorFlow Serving은 두 가지 방식으로 요청을 받습니다:
방식 | 특징 | 언제 쓰면 좋은가 |
---|---|---|
REST API | HTTP POST 방식, JSON 형태 요청 | 웹 프론트엔드와 연결 시 편리 |
gRPC | Protocol Buffer 기반, 이진 전송 | 모바일/내부 통신에서 고속 추론 필요할 때 |
초심자에겐 REST가 다루기 쉽습니다. 예측 요청을 아래처럼 보내면 되죠:
{ “instances”: [[5.1, 3.5, 1.4, 0.2]] }
결과는 이렇게 옵니다:
{ “predictions”: [[0.95, 0.03, 0.02]] }
이처럼 모델 추론을 외부 API처럼 쉽게 연결할 수 있는 게 TensorFlow Serving의 강점이에요.
5. 성능 최적화와 대규모 배포 전략
서비스 규모가 커지면 성능이 생명입니다. TensorFlow Serving은 배칭 기능을 지원합니다. 여러 개의 예측 요청을 한꺼번에 묶어 GPU 연산 성능을 최대한 끌어낼 수 있죠. 또한 모델 인스턴스를 복수 개 띄워 병렬 처리 성능도 강화할 수 있어요.
🔧 실사례: 쿠버네티스로 운영한 경험
제가 참여한 프로젝트에서는 하루 30만 건 이상 추론 요청을 처리해야 했는데, TensorFlow Serving을 Docker로 구성하고 Kubernetes 위에서 HPA
(Horizontal Pod Autoscaler)를 붙였습니다. 여기에 GPU 서버 2대를 붙여서 지연 시간도 30ms 내외로 잘 잡혔습니다.
또한 AWS에서 ALB
(Application Load Balancer)를 앞단에 둬서 요청 분산도 쉽게 처리했죠.
6. 모델 업데이트와 무중단 배포
실시간 서비스 중에는 모델 교체가 신중해야 합니다. TensorFlow Serving은 폴더에 새 버전을 추가하면 자동으로 최신 버전을 인식할 수 있어요. 예전 모델로 바로 롤백도 가능하죠.
추가적으로 config 파일
을 사용하면 여러 모델을 동시에 서빙하거나, 특정 버전만 선택해서 운영할 수도 있습니다.
🪄 리얼 꿀팁
- 버전 폴더 추가 후 컨테이너 재시작하면 바로 적용됩니다.
- 동적 리로드는 config 파일 방식에서만 지원돼요.
7. 마무리하며 – ‘모델 서빙’이 진짜 ML 서비스의 시작이다
머신러닝 개발의 끝은 ‘모델 저장’이 아니라 ‘모델 서빙’입니다. 텐서플로우 서빙은 이 마지막 단계를 완성도 있게 마무리할 수 있는 핵심 도구죠. 특히 도커 기반으로 쉽게 운영 가능하고, 확장성과 안정성 모두에서 검증된 만큼 ML 프로젝트를 실서비스로 연결할 때 가장 신뢰할 수 있는 선택입니다.
이번 포스팅을 통해 모델 저장부터 서빙, 요청 처리, 운영까지 전 과정을 한눈에 정리해드렸습니다. 혼자 개발하시는 분들이나 소규모 팀이라도 바로 적용할 수 있도록 최대한 현실적으로 풀어봤어요. 도움이 되셨다면 다른 머신러닝 관련 글도 기대해주세요 🙂