이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기존 안드로이드 앱에 add-to-app 방식으로 Flutter 화면을 붙이는 작업을 맡았습니다. 액티비티마다 FlutterEngine을 새로 만들면 메모리가 급격히 늘어나는 문제를 먼저 맞았는데, 앱 전체에서 단일 FlutterEngine 인스턴스를 공유하는 방식으로 바꾸니 안정됐습니다. 플랫폼 채널로 네이티브 데이터를 넘기는 부분에서 직렬화 오버헤드가 생각보다 컸고, 큰 데이터는 MethodChannel 대신 EventChannel로 스트리밍하는 쪽이 나았습니다. Flutter 모듈 빌드가 전체 빌드 시간에 더해지면서 CI 파이프라인 시간이 두 배가 됐고, 모듈 캐시 전략을 별도로 짜야 했습니다. add-to-app은 점진적 마이그레이션에는 좋지만 구조 복잡도 비용이 분명히 있다고 생각합니다.
add-to-app 통합 후 첫 Flutter 화면 진입 시 눈에 띄는 딜레이가 생기는 문제를 겪었습니다. 프로파일러로 확인하니 Engine 초기화에만 400ms 이상 소요되고 있었고, 사용자 입장에서는 버튼을 눌렀는데 화면이 늦게 뜨는 것처럼 느껴졌습니다.
FlutterEngineGroup의 워밍업 기능을 써서 앱 시작 시점에 미리 Engine을 준비시키는 방식으로 전환했는데, 첫 진입 딜레이가 400ms에서 60ms 아래로 줄었습니다. 메모리 비용은 Engine 하나당 20MB 내외라 화면이 많지 않은 현재 구조에서는 감수할 수 있었지만, Flutter 화면이 늘어나면 기준을 다시 검토해야 한다는 점도 함께 기록해뒀습니다.
add-to-app은 점진 도입에는 좋지만 성능 함정이 명확하게 있고, 그 함정을 미리 알고 들어가야 나중에 재작업이 없다는 것을 배웠습니다.
Flutter add-to-app을 도입하면서 처음에는 네이티브 화면 대부분을 Flutter로 바꾸면 좋겠다고 생각했습니다. 실제로 두 화면을 마이그레이션한 뒤에 빌드 설정이 복잡해지고 네이티브와 Flutter 사이 상태 공유가 점점 뒤엉키는 문제가 보이기 시작했습니다.
PlatformChannel 호출이 늘어날수록 비동기 처리 오류가 잦아졌고, 디버깅 시 어느 쪽에서 문제가 생겼는지 바로 알기가 어려웠습니다. 결국 팀 내 합의로 신규 화면은 Flutter로 개발하되 기존 네이티브 화면은 교체하지 않는 방향으로 범위를 제한했습니다. 이 결정 이후 유지보수 부담이 줄었고, add-to-app이 강점을 발휘하는 구간이 어디인지 더 명확하게 보였습니다. 기술 도입은 장점만큼 한계를 먼저 파악하고 범위를 정하는 것이 더 중요하다는 점을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.