이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
온디바이스 SDK와 Web SDK의 가장 큰 차이는 실행 환경의 제약입니다. 온디바이스는 CPU·메모리·배터리 제약 안에서 동작해야 하기 때문에 메모리 사용량과 연산 효율이 설계의 핵심 기준이 됩니다.
네트워크 의존도도 다릅니다. Web SDK는 인터넷 연결이 기본 전제이지만, 온디바이스는 오프라인에서도 동작하거나 낮은 대역폭에서도 견고해야 하는 경우가 많습니다. 모델 경량화와 로컬 캐싱 전략이 온디바이스 SDK 설계의 중요한 부분입니다.
배포 방식의 차이도 있습니다. Web SDK는 서버에서 버전을 바꾸면 바로 반영되지만, 온디바이스는 앱 업데이트를 통해 반영됩니다. 이전 버전과의 하위 호환성을 더 오래 유지해야 해서 API 설계 시 확장성을 더 신중하게 고려했습니다.
온디바이스 SDK와 Web SDK를 동시에 유지하던 프로젝트에서 가장 충돌이 잦았던 부분은 모델 업데이트 주기였습니다. Web SDK는 서버 배포로 즉시 반영이 가능했지만, 온디바이스는 앱스토어 심사와 사용자 업데이트를 거쳐야 해서 최대 3주 지연이 발생했습니다. 이를 해결하기 위해 모델 버저닝 레이어를 별도로 두고, 온디바이스 SDK가 서버에서 경량 델타 패치를 내려받아 모델을 갱신하는 구조를 설계했습니다. 결과적으로 주요 업데이트의 배포 지연을 1주 이내로 단축했고, 두 SDK의 추론 결과 일관성도 크게 향상됐습니다. 온디바이스의 진짜 어려움은 메모리보다 버저닝과 배포 전략이라는 걸 이때 배웠습니다.
온디바이스 SDK를 처음 설계할 때 네트워크 단절 시나리오를 과소평가했습니다. 초기 버전은 모델 초기화 시 서버에서 토큰을 받아오는 구조였는데, 오프라인 환경에서는 SDK 전체가 작동 불능이 되는 문제가 발생했습니다. 이후 로컬 캐시 우선 로딩 원칙을 채택해, 초기화 시 서버 응답 없이도 번들된 기본 모델로 즉시 기동하고, 네트워크 복구 시 백그라운드에서 최신 모델을 동기화하는 방식으로 재설계했습니다. Web SDK와의 근본적 차이는 신뢰 가능한 네트워크를 전제하지 않는 설계 철학이라는 점을 체득했습니다.
폴백 경로를 먼저 설계한 뒤 온라인 경로를 얹는 순서가 온디바이스 SDK에서는 더 안전하다는 시각을 갖게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.