이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대학원 연구실에서 학습된 모델을 실험에 쓰는데 추론 시간이 너무 길어 실험 주기가 느려지는 문제가 있었습니다. 프로파일링을 해보니 데이터를 한 건씩 넣고 있어서 대부분의 시간이 처리 대기에 낭비되고 있었습니다. 배치로 묶어 한 번에 처리하도록 바꿨더니 처리량이 약 4배 올랐습니다. 처음엔 배치 크기를 너무 크게 잡아 메모리 부족 오류가 났습니다. 장치 메모리를 확인하며 크기를 줄여가며 조정했고, 최종적으로 안정적인 크기를 찾았습니다. 이 과정에서 배치 크기와 메모리 사용량 사이의 관계를 직접 측정하며 이해했습니다. 추론 최적화는 글로 읽는 것과 실제 측정 결과가 다른 경우가 많다는 것도 이때 배웠습니다. 지금은 최적화 전에 빠짐없이 어디서 시간을 쓰는지 먼저 측정합니다.
졸업 프로젝트에서 모바일 환경에서 동작해야 하는 이미지 분류 모델을 만들었습니다. 데스크톱에서는 잘 동작했는데 모바일 기기에서 추론 시간이 3초를 넘어 실사용이 어려운 수준이었습니다. 모델 크기를 줄이는 방향을 검토했습니다. 양자화 기법을 처음 적용해봤는데, 정확도가 약 6포인트 떨어지는 대신 추론 시간이 절반으로 줄었습니다. 정확도 손실이 허용 가능한지 기준이 없어서 팀원들과 논의했습니다. 분류 오류의 영향이 크지 않은 응용이라 4포인트 이내 손실은 괜찮다는 기준을 정했고, 이 기준에 맞는 수준까지 조정했습니다. 처음엔 이 기법이 이런 트레이드오프를 만든다는 걸 몰랐고, 직접 실험해보고 나서야 어떤 상황에 쓸 수 있는지 감이 생겼습니다.
개인 사이드 프로젝트에서 이미지를 실시간으로 처리하는 파이프라인을 만들었습니다. 처음엔 전처리를 CPU에서 하고 모델만 GPU에서 돌렸는데, 전처리 시간이 모델 추론보다 오래 걸리는 이상한 상황이 생겼습니다. 측정해보니 이미지 크기 조절과 정규화 과정에서 CPU와 GPU 사이의 데이터 이동 비용이 생각보다 컸습니다. 전처리 연산 일부를 GPU에서 직접 처리하도록 구조를 바꿨습니다.
이동 횟수를 줄이는 것만으로 전체 파이프라인 지연이 약 30% 개선됐습니다. 처음엔 GPU가 비싼 연산에만 쓰는 것이라고 생각했는데, 데이터 이동 자체가 병목이 될 수 있다는 것을 이 경험으로 알게 됐습니다. 이후 파이프라인을 설계할 때 처리 단계뿐 아니라 데이터 이동 경로도 함께 보는 편입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.