## 1. 기본 아키텍처와 동적 관리

• 구조: 다국어 입력기는 모듈형 플러그인 방식이 가장 유리하며, 중앙 엔진과 독립된 언어 모듈로 구성됩니다.

• 동적 관리: 사용 중 언어를 추가/제거하려면, 입력기를 앱과 분리된 독립적인 시스템 서비스로 설계하고 IPC(프로세스 간 통신)를 통해 동적으로 플러그인을 로드/언로드하는 방식이 필요합니다.

## 2. 다중 사용자 및 sudo 환경의 난제

• 다중 사용자: 여러 사용자를 지원하려면, 각 사용자를 위한 독립된 입력 세션을 생성하고 격리해야 합니다. 마스터 데몬이 사용자별 인스턴스를 관리하고 입력을 정확히 라우팅합니다.

• sudo 문제: sudo 사용 시 입력기가 비활성화되는 문제는, sudo가 실행 환경(환경 변수, 권한)을 변경하여 클라이언트(앱)와 서버(데몬) 간의 통신을 단절시키기 때문에 발생합니다.

• 사용자 식별: 이 문제를 해결하고 원래 로그인한 사용자를 정확히 찾으려면, SUDO_UID 환경 변수, getlogin(), getuid() 등을 계층적으로 확인하는 견고한 로직이 필요합니다.

## 3. 통신 방식 논쟁: D-Bus vs. 소켓

이것이 오늘 대화의 핵심이었습니다.

• D-Bus:

  • 장점: 주소 관리, 보안 정책, 자동 실행 등 복잡한 기능들을 프레임워크 차원에서 제공하여 개발이 편리하고 안정적입니다.

  • 단점 (개발자님의 핵심 지적): 구조적 오버헤드로 인해 실질적인 성능 병목을 유발합니다. 이 지연 때문에 동기식 구현이 어려우며, 비동기식 구현은 '잘못된 창에 글자가 출력되는' 레이스 컨디션과 보안 허점을 낳습니다. 또한 과거 IBus에서 키로깅이 가능했던 것처럼 프레임워크 자체의 취약점에 노출될 수 있습니다.

• 유닉스 소켓:

  • 장점: D-Bus보다 훨씬 가볍고 빠릅니다. 또한 커널이 제공하는 SO_PEERCRED 기능을 통해 접속한 클라이언트의 신원을 직접 확인할 수 있어, 더 명확하고 투명한 보안 모델을 직접 구현할 수 있습니다.

  • 단점: 클라이언트가 서버의 주소를 찾아야 하는 문제를 직접 해결해야 합니다.

## 4. 최종 결론: 견고한 소켓 통신 설계

D-Bus의 한계를 극복하고 안정적인 소켓 통신을 구현하기 위한 최종적인 설계는 다음과 같습니다.

1. 주소 찾기: 클라이언트와 서버는 XDG_RUNTIME_DIR 환경 변수를 최우선으로 사용하여 통신 주소를 공유합니다. 이 변수는 시스템의 세션 관리자(pam_xdg.so 등)가 보장해 주는 표준입니다.

2. 폴백(Fallback) 전략: XDG_RUNTIME_DIR이 없는 환경(콘솔 등)을 대비해, /tmp 내에 UID 기반의 보안 디렉터리를 만들어 통신하는 대체 경로를 마련합니다.

결론적으로, 일반적인 데스크톱 표준인 D-Bus 방식의 편리함 이면에는 입력기처럼 지연에 민감한 프로그램에 치명적인 성능 및 보안 문제가 있음을 확인했습니다. 이에 대한 해결책으로, 커널의 기능을 적극 활용하는 직접적인 소켓 통신 방식을 채택하되, XDG_RUNTIME_DIR과 같은 현대적인 표준을 활용하여 통신 경로를 안정적으로 찾는 것이 매우 견고한 설계라는 결론에 이르렀습니다.

------------

아휴.. 제미니 돌대가리.. 내가 다 가르쳐주네 ㅎㅎ