이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트에서 딥러닝 모델을 엣지 디바이스에 올리는 작업을 했습니다. 서버에서 잘 돌아가던 모델이 디바이스에서 레이턴시가 600ms 이상 나와 실시간으로 쓰기 어려운 상황이었습니다. 첫 번째로 시도한 건 INT8 양자화였습니다. PyTorch의 post-training quantization을 적용했고, 정확도 손실이 1% 미만인 상태에서 추론 속도가 약 2.3배 빨라졌습니다. 두 번째는 ONNX로 모델을 변환해 런타임 최적화를 적용하는 것이었는데, 불필요한 연산 노드를 제거하고 배치 처리 구조로 바꾸니 추론 시간이 200ms 아래로 줄었습니다. 최종적으로 TensorRT로 엔진을 빌드해 목표였던 150ms 이하를 달성했습니다. 이 과정에서 최적화는 단계적으로 가면서 각 단계에서 정확도와 속도의 트레이드오프를 확인하는 것이 핵심이라는 걸 배웠습니다.
실시간 추론 최적화에서 단일 요청 레이턴시를 줄이는 것 외에, 배치 처리를 다시 설계해서 전체 처리량을 높이는 방향도 시도했습니다. 개별 요청을 그때그때 처리하던 구조에서 짧은 시간 내에 들어오는 요청을 묶어 배치로 처리하는 방식(dynamic batching)으로 바꾸면, GPU 자원 활용률이 올라가고 단위 시간당 처리량이 늘어납니다. TensorRT Serving에서 제공하는 dynamic batching 옵션을 적용했을 때, 단일 요청 레이턴시는 약간 늘었지만 초당 처리 가능한 요청 수가 3배 이상 증가했습니다.
레이턴시와 처리량은 트레이드오프 관계이므로 요구사항에 맞는 기준을 먼저 정해야 합니다. 최적화 방향이 '개별 빠르게'인지 '전체 많이'인지에 따라 적용 기술이 달라진다는 것을 그 작업에서 배웠습니다.
실시간 추론 최적화 작업에서 기술적 결과를 내는 것과 팀이 그 결과를 신뢰하고 실제 서비스에 반영하도록 합의하는 것은 별개의 과제였습니다. 양자화와 ONNX 변환으로 속도가 개선됐지만, 팀에서는 정확도 손실에 대한 우려가 있었습니다. 이때 '정확도 손실이 1% 미만이다'는 수치만 말하지 않고, 어떤 입력 유형에서 손실이 발생하는지와 서비스에서 그 케이스가 얼마나 자주 나오는지를 함께 정리해서 보여줬습니다.
팀 설득은 수치보다 그 수치가 실제로 의미하는 범위를 함께 보여줄 때 효과적입니다. 최적화 결과를 배포 결정에 연결하려면 기술 검증과 동시에 팀이 납득하는 기준을 함께 만드는 과정이 필요했습니다. 그 경험이 기술 작업과 소통을 분리하지 않게 된 계기였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 크래프톤 AI 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.