이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
멀티 플랫폼 개발에서 가장 먼저 해결한 것은 플랫폼별 빌드 파이프라인 분리였습니다. Windows와 macOS에서 동일한 코드가 다르게 동작하는 경우가 있어, 플랫폼별 조건 컴파일과 CI 매트릭스 빌드를 구성해 각 환경을 자동으로 검증했습니다.
공통 비즈니스 로직은 플랫폼 독립 레이어로 분리했습니다. UI와 시스템 API는 플랫폼마다 달라지지만, 데이터 처리와 상태 관리는 공통 코어로 묶어두면 코드 중복이 줄고 버그 수정이 한 곳에서 모든 플랫폼에 반영됐습니다.
UI 차이 처리도 중요했습니다. 각 OS의 디자인 가이드라인이 달라 동일한 컴포넌트라도 표현 방식이 달랐고, 플랫폼 컨벤션을 따르는 것이 사용자 경험을 더 자연스럽게 만들었습니다.
Flutter로 iOS와 Android 동시 지원 앱을 작성할 때, 플랫폼 채널(Platform Channel)을 통한 네이티브 코드 연동이 가장 어려웠습니다. 블루투스 기기 스캔 기능이 Android에서는 잘 됐는데, iOS에서는 권한 요청 타이밍과 Info.plist 설정이 달라 앱이 묵묵히 실패하는 경우가 있었습니다.
플랫폼 분기 로직을 비즈니스 레이어에 직접 넣었다가, 나중에 유지보수가 어려워지는 것을 경험했고, 인터페이스를 공통으로 정의하고 플랫폼별 구현을 주입하는 방식으로 리팩터링했습니다. 이후에는 신규 플랫폼 기능을 추가해도 비즈니스 로직을 건드리지 않았고, CI에서 iOS 시뮬레이터와 Android 에뮬레이터를 함께 실행하니 플랫폼 간 회귀를 조기에 잡을 수 있었습니다.
멀티플랫폼에서는 추상화 경계를 처음부터 명확히 긋는 것이 나중 수정 비용을 낮추는 가장 큰 결이라는 걸 배웠습니다.
C++ 라이브러리를 Windows Linux macOS에서 동시에 빌드하는 과정에서 CMake를 사용했는데, 처음에는 하나의 CMakeLists.txt로 모든 플랫폼을 커버하려 했습니다. 실제로는 Windows에서 MSVC와 MinGW가 링킹 플래그에서 달라지는 부분이 있었고, macOS의 프레임워크 경로 처리가 Linux와 전혀 달랐습니다. 조건 분기를 점점 늘려가다 보니 CMakeLists.txt 자체가 읽기 어려운 조건 덩어리가 됐습니다. 한계를 인정하고 플랫폼별 CI 파이프라인을 분리해, 각 환경에서 독립적으로 빌드와 테스트가 돌도록 구성했습니다.
단일 빌드 파일로 모든 플랫폼을 추상화하려는 접근이 오히려 복잡도를 높인다는 것을 경험하고 나서, 공통 로직은 모듈로 분리하되 빌드 설정은 플랫폼별로 명시적으로 관리하는 방향을 선호하게 됐습니다. 완전한 추상화보다 명시적 분리가 더 나은 자리가 있다는 교훈이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.