Magical Memories in Seattle

우분투 26.04(GNOME 환경)에서 한영키를 눌렀을 때 입력 모드가 전환되었다가 안 되었다가 하는 기현상은 리눅스 유저들이 가장 흔하게 겪는 고질적인 문제이다. 이 현상이 발생하는 근본적인 원인은 우분투의 기본 입력기인 IBus(아이버스)의 한글 플러그인 설정이 꼬였거나, 단축키 입력 타이밍이 디스플레이 서버(Wayland)와 어긋나기 때문이다. 

스트레스 없이 한영 전환을 100% 확실하게 고정할 수 있는 3단계 해결책을 순서대로 적용해 보는 것을 권장한다.

1단계: 한글 입력기(Hangul) 토글 키 설정 초기화 및 재등록 

우분투 설정 메뉴의 키보드 단축키와 한글 입력기 내부의 한영키 인식이 서로 충돌하면서 먹통이 되는 경우가 많다. 이 충돌을 완벽히 정리해 주어야 한다.

1. 우분투 설정(Settings) -> 키보드(Keyboard)로 이동한다.
2. '입력 소스(Input Sources)' 항목에 한국어(Hangul)가 등록되어 있는지 확인한다.

• 만약 한국어만 있고 옆에 Hangul이라는 글자가 없다면 입력 소스 추가(+)를 눌러 한국어(Hangul)를 정확히 다시 추가하고 기존 구형 한국어는 지워야 한다.

1. 한국어(Hangul) 항목 우측에 있는 점 3개 아이콘을 누르고 기본 설정(Preferences)을 클릭한다.
2. 한글 입력기 설정 창이 뜨면 한글전환(Hangul Toggle Key) 섹션을 확인한다.
3. 기존에 등록된 키 목록을 선택하고 오른쪽의 삭제(Remove) 버튼을 눌러 싹 비운다.
4. 다시 추가(Add) 버튼을 누른 뒤, 키보드의 한영키를 꾹 누른다. 화면에 Alt_R 혹은 Hangul이라고 인식되면 확인을 눌러 저장한다.

2단계: GNOME 단축키 겹침 문제 해결하기

우분투 자체 시스템 레지스트리에서 오른쪽 Alt 키(Alt_R)를 '창 메뉴 띄우기'나 '다른 특수문자 입력(가운데 점 등)' 용도로 선점하고 있으면, 한영키를 눌러도 한글 입력기까지 신호가 전달되지 못하고 중간에 증발한다. 이를 터미널 명령어로 강제 해제해야 한다.

터미널을 열고 아래 명령어 두 줄을 차례대로 복사해서 실행한다.

Bash

# 시스템 우측 Alt 키의 특수 기능 선점 해제
gsettings set org.gnome.desktop.input-sources xkb-options "['korean:ralt_hangul']"

# 단축키 충돌을 방지하기 위해 ibus 엔진 옵션 강제 동기화
gsettings set org.freedesktop.ibus.general.hotkey triggers "['Hangul']"

3단계: 근본적인 해결책 — Fcitx5 입력기로 교체하기 (개인적으로 가장 권장)

만약 1, 2단계를 적용했는데도 Wayland 디스플레이 서버 특유의 반응 지연 때문에 한영키가 여전히 씹힌다면, 버그가 많고 무거운 순정 IBus 입력기를 과감히 버리고 리눅스 진영에서 가장 빠르고 가벼운 Fcitx5(파이시틱스5) 입력기로 교체하는 것이 정신 건강에 가장 좋다. 한영 전환 반응 속도가 윈도우 11 수준으로 즉각 즉각 바뀐다.

1. Fcitx5 및 한글 패키지 설치

Bash

sudo apt update
sudo apt install fcitx5 fcitx5-hangul fcitx5-frontend-qt5 fcitx5-frontend-gtk3

2. 우분투 기본 입력기 프레임워크 변경

ash

# 시스템 기본 입력기를 ibus에서 fcitx5로 강제 변경
im-config -n fcitx5

3. 환경 변수 등록 (부팅 시 자동 인식)

사용자 환경 설정 파일에 fcitx5 설정을 주입한다.

Bash

echo "export GTK_IM_MODULE=fcitx" >> ~/.profile
echo "export QT_IM_MODULE=fcitx" >> ~/.profile
echo "export XMODIFIERS=@im=fcitx" >> ~/.profile

4. 시스템 재부팅 및 세팅

컴퓨터를 한 번 재부팅한 뒤, 앱 메뉴에서 Fcitx5 설정(Fcitx5 Configuration) 메뉴를 열어준다.

• 오른쪽 창(Available Input Method)에서 Hangul을 찾아 왼쪽 창(Current Input Method)으로 옮겨준다.
• 하단의 Global Options 탭으로 이동하여 Trigger Input Method 항목의 단축키를 본인의 한영키로 지정해 주면 끝난다.

IBus의 고질적인 타이밍 버그 때문에 끊기던 현상이었다면, 2번 단계의 레지스트리 정리나 3번 Fcitx5 교체를 통해 완전히 해결된다.

우분투 26.04 환경에서 `sudo` 명령어를 실행할 때 비밀번호 입력을 건너뛰게 하려면, 리눅스의 권한 관리 설정 파일인 **sudoers** 파일을 수정해야 한다. 이 설정은 편리하지만 보안상 시스템 방어벽을 낮추는 행위이므로, 시스템 전체에 적용하기보다 **내 계정 하나에만 안전하게 적용**하는 것이 바람직하다.

설정하는 구체적인 방법은 다음과 같다.

---

### 1. 안전한 sudoers 편집기 실행

sudoers 파일은 문법이 조금이라도 틀리면 시스템 전체에서 `sudo` 권한이 락(Lock)에 걸려 시스템이 망가질 수 있다. 따라서 일반 nano 편집기로 열지 말고, 문법 오류를 자동으로 검사해 주는 **`visudo`** 명령어를 반드시 사용해야 한다.

터미널을 연 뒤 아래 명령어를 입력한다.

```bash
sudo visudo

```

---

### 2. 내 계정에만 비밀번호 면제 설정 추가

파일이 열리면 키보드 방향키를 이용해 **맨 아랫줄**로 이동한다. 그리고 다음 형식을 맞춰 한 줄을 추가해 준다.

```text
사용자계정명 ALL=(ALL:ALL) NOPASSWD: ALL

```

* **예시:** 만약 내 우분투 로그인 아이디(계정명)가 `ubuntu`라면 다음과 같이 입력하면 된다.
```text
ubuntu ALL=(ALL:ALL) NOPASSWD: ALL

```


* **팁:** 계정명을 잘 모른다면 터미널에 `whoami`를 입력하여 나오는 단어를 적으면 된다.

---

### 3. 저장 및 빠져나오기

`visudo` 편집기의 기본 하단 단내에 맞춰 저장하고 종료한다. (보통 nano 기반인 경우)

1. `Ctrl + O`를 누르고 `Enter`를 쳐서 저장한다.
2. `Ctrl + X`를 눌러 편집기를 빠져나온다.

만약 문법에 에러가 있다면 종료 시 경고 문구가 뜨며 다시 수정할 기회를 준다. 정상적으로 저장되었다면 즉시 설정이 반영된다.

---

### 4. 테스트 및 주의사항

새로운 터미널 창을 열고 패키지 목록을 갱신하는 등 아무 sudo 명령어나 실행해 본다.

```bash
sudo apt update

```

이제 비밀번호를 묻지 않고 명령어가 바로 실행되는 것을 확인할 수 있다.

> ⚠️ **보안 경고:** 이 설정을 적용하면 사용자가 자리를 비웠을 때나, 혹시 모를 악성 스크립트/바이러스가 백그라운드에서 실행될 때 시스템 루트(Root) 권한을 제약 없이 즉시 탈취당할 수 있다. 편리함과 보안성 사이의 타협점이므로 개인 PC가 아닌 공용 서버나 외부 네트워크 노출이 잦은 환경에서는 신중하게 결정해야 한다.

윈도우즈에선 시스펨 환경변수에 새로운 폴더를 등록하고 리눅스에선 .bashrc 에도 추가한다.

MaterialApp(
  // 라이트 모드 테마 설정
  theme: ThemeData(
    useMaterial3: true, // 머티리얼 3 디자인 규칙을 적용한다
    colorScheme: ColorScheme.fromSeed(
      seedColor: Colors.blue, // 파란색을 기준으로 밝은 화면용 색상들을 자동 생성한다
      brightness: Brightness.light,
    ),
    // ColorScheme이 자동으로 계산한 배경색 대신, 특정 색상을 강제하고 싶다면 이렇게 덮어쓸 수 있다
    scaffoldBackgroundColor: Colors.white,
  ),

  // 다크 모드 테마 설정
  darkTheme: ThemeData(
    useMaterial3: true,
    colorScheme: ColorScheme.fromSeed(
      seedColor: Colors.indigo, // 남색을 기준으로 어두운 화면용 색상들을 자동 생성한다
      brightness: Brightness.dark, // 다크 모드에 맞는 명도와 채도로 계산하라고 지시한다
    ),
    scaffoldBackgroundColor: Colors.grey[900],
  ),

  // 시스템 설정(밝음/어두움)에 따라 테마를 자동으로 결정하도록 지정한다
  themeMode: ThemeMode.system, 
  home: const MainScreen(),
);

위의 Material3 theme에 맞는 appbarTheme 과 elevatedButtonTheme 도 지정해줘야하나 아니면 알아서 해주나?

결론부터 말하자면 프레임워크가 알아서 해준다.

머티리얼 3(Material 3) 디자인 시스템에서 ColorScheme.fromSeed()를 사용하면, 플러터가 계산해 낸 색상 팔레트를 기반으로 앱바(AppBar)와 버튼(ElevatedButton) 등 모든 기본 위젯의 스타일이 자동으로 결정된다. 따라서 굳이 appBarTheme이나 elevatedButtonTheme을 일일이 작성할 필요가 없다.

자동으로 적용되는 방식은 다음과 같다.

1. 앱바(AppBar)의 자동 적용 과거 머티리얼 2에서는 앱바의 배경이 무조건 주조색(Primary Color)이었지만, 머티리얼 3부터는 화면 배경색과 통일감을 주는 표면색(Surface Color)을 기본으로 사용한다. 화면을 스크롤하면 내용물이 앱바 밑으로 지나갈 때 옅은 주조색이 스며드는 효과(Surface Tint)가 자동으로 적용되어 입체감을 준다.
2. 버튼(ElevatedButton)의 자동 적용 씨앗 색상(Seed Color)에 맞춰 버튼의 텍스트 색상, 눌렀을 때의 물결 효과 색상, 그림자 깊이(Elevation)가 자동으로 설정된다. 모서리의 둥근 정도(Border Radius) 역시 머티리얼 3의 알약 모양(StadiumBorder) 표준 규격에 맞게 자동으로 그려진다.

그렇다면 언제 직접 지정해야 하는가?

오직 구글이 정해놓은 머티리얼 3의 기본 디자인 규칙을 개발자 마음대로 바꾸고 싶을 때만 따로 작성하여 덮어쓰면 된다.

예를 들어 머티리얼 3를 쓰면서도 예전 방식처럼 앱바의 배경색을 무조건 진한 씨앗 색상으로 칠하고 싶거나, 모든 버튼의 모양을 둥글지 않은 뾰족한 직사각형으로 강제하고 싶을 때만 theme 내부의 appBarTheme이나 elevatedButtonTheme 옵션을 추가하여 구체적인 속성을 적어주면 된다.

결과적으로 특별한 커스텀 디자인 요구사항이 없다면 ColorScheme 설정 하나만 남겨두어도 앱이 아주 세련되게 알아서 잘 꾸며진다.

ThemeData에서 primarySwatch와 primaryColor는 앱의 주요 색상을 지정한다는 목적은 같지만, 다루는 색상의 범위와 프레임워크가 이를 활용하는 방식에서 분명한 차이가 있다.

1. primarySwatch (색상 팔레트) 단일 색상이 아니라, 특정 색을 기준으로 아주 연한 색부터 아주 진한 색까지 10단계(50~900)의 명암으로 촘촘하게 구성된 색상 묶음(MaterialColor 클래스)이다. 이 값을 설정하면 플러터는 버튼이 눌렸을 때의 물결(Ripple) 효과, 비활성화된 위젯의 색상, 스크롤의 끝부분에서 나타나는 효과 등 다양한 UI 상황에 맞춰 팔레트 안에서 가장 어울리는 명암의 색을 스스로 골라 앱 전체에 조화롭게 적용한다. 프레임워크에 색상 세트를 통째로 넘겨주고 알아서 상황에 맞게 쓰라고 지시하는 것과 같다.
2. primaryColor (단일 색상) 명암 단계가 전혀 없는 딱 하나의 고정된 단일 색상(Color 클래스) 값이다. 주로 앱바(AppBar)의 기본 배경색 등 큼직한 UI 요소에 1차원적으로 지정될 때 쓰인다. 팔레트가 아니기 때문에 상호작용에 따른 동적인 색상 변화(예: 클릭 시 조금 어두워지는 효과)를 프레임워크가 유연하게 계산해주지 못한다. 특정 부위에 칠할 단 하나의 물감만 쥐여주는 것과 같다.
3. 두 속성의 관계 코드를 작성할 때 primarySwatch에 Colors.blue를 지정하면, 플러터는 자동으로 파란색 팔레트의 중간 기준점인 Colors.blue[500] 값을 빼내어 primaryColor로 설정해 버린다. 즉, primarySwatch 하나만 잘 설정해 두면 웬만한 색상 처리는 프레임워크가 알아서 해준다.

다만, 플러터가 최신 머티리얼 3(Material 3) 디자인 시스템을 기본값으로 채택한 이후부터는 이 두 속성보다는 colorScheme 옵션을 사용하여 색상 체계를 훨씬 세밀하고 현대적으로 제어하는 방식을 권장하고 있다.