2.1 아키텍처의 선택: 서버 모델의 설계 우위

IME 로직을 구현하는 방식은 크게 두 가지로 나뉩니다. 첫째는 IME 로직 전체를 라이브러리화하여 각 애플리케이션이 직접 로드하는 서버리스(in-process) 모델이며, 둘째는 시스템 전역에 단 하나의 IME 데몬(서버)을 두고 애플리케이션들이 IPC 통신으로 서비스를 요청하는 서버(out-of-process) 모델입니다.

서버리스 모델은 언뜻 보기에 별도의 데몬을 관리할 필요가 없어 단순해 보이지만, 앞서 제시한 핵심 요구사항을 만족시키지 못하는 근본적인 결함을 가지고 있습니다.

자원 낭비: 10개의 애플리케이션이 실행되면, 동일한 IME 라이브러리가 메모리에 10번 중복으로 로드됩니다. 이는 시스템 자원을 심각하게 낭비하는 비효율적인 방식입니다.

전역 설정의 동적 반영 불가: 사용자가 별도의 설정 프로그램을 통해 새로운 언어를 추가해도, 이미 실행 중인 앱들은 이 변경 사실을 알 방법이 없어 모든 앱을 재시작해야만 합니다.

전역 상태 표시의 어려움: 사용자는 화면 구석의 아이콘을 통해 현재 입력 모드가 ‘한글’인지 ‘영어’인지 알아야 합니다. 하지만 서버리스 모델에서는 각 앱이 자신만의 상태를 가지므로, 어떤 앱을 기준으로 할지 알 수 없어 전역 인디케이터를 만들 수 없습니다. 이를 해결하려면 결국 상태 동기화를 위한 별도의 ‘인디케이터 데몬’과 IPC가 필요해져, 서버리스 모델의 장점은 사라지고 복잡성만 늘어납니다.

반면, IPC 서버 기반의 플러그인 IME 아키텍처는 이러한 문제들을 구조적으로 완벽하게 해결합니다.

이 아키텍처의 설계 우위는 명확합니다.

중앙 집중식 효율성 및 관리: 모든 언어 플러그인, 설정, 현재 상태는 단 하나의 서버 프로세스에서 관리됩니다. 따라서 자원 중복이 없을 뿐만 아니라, 설정 변경이나 현재 상태 조회가 단일 통신 채널을 통해 즉시 일관되게 이루어집니다.

최적화된 사용자 경험: 서버는 모든 언어 엔진을 미리 메모리에 로드해두므로, 사용자는 어떤 앱에서든 지연 없이 즉각적으로 언어를 전환하고 사용할 수 있습니다.

이러한 이유로, 효율적이고 관리하기 용이하며 쾌적한 다국어 입력 환경을 구축하기 위한 아키텍처를 선택할 때, IPC 서버 기반의 플러그인 모델은 다른 대안과 비교할 수 없는 명백한 장점을 가집니다.