우분투에서 VS Code 편하게 쓰는 개발자 팁 | Wayland·inotify·Remote-SSH 실...

우분투에서 VS Code 편하게 쓰는 개발자 팁 | Wayland·inotify·Remote-SSH 실전 가이드

· 22분 읽기 · 수정 중급 가이드
우분투에서 VS Code 편하게 쓰는 개발자 팁 | Wayland·inotify·Remote-SSH 실전 가이드

이 글의 핵심

우분투(Ubuntu) 데스크톱에서 VS Code를 쓸 때만 발생하는 문제 — Wayland 렌더링 지연, GTK 파일 감시자(inotify) 한도, apt/snap/.deb 설치 방식 차이, GNOME 테마·폰트 연동, Remote-SSH 원격 개발 — 를 원인과 함께 정리한 실전 가이드입니다. Windows/Mac에는 해당하지 않는 우분투 고유 이슈에 집중합니다.

들어가며

VS Code는 크로스 플랫폼 에디터지만, 실제로 우분투 데스크톱에서 매일 쓰다 보면 Windows나 macOS 사용자는 절대 겪지 않는 문제들과 마주치게 됩니다. GNOME이 Wayland로 전환되면서 생긴 렌더링 버그, 리눅스 커널 고유의 inotify 파일 감시자 한도, apt/snap/.deb라는 세 가지 설치 경로 중 무엇을 골라야 하는지에 대한 혼란, 그리고 한글 폰트가 이상하게 뭉개져 보이는 문제까지 — 이런 이슈는 공식 문서에도 잘 정리되어 있지 않아 매번 검색해서 해결하는 경우가 많습니다.

이 글은 VS Code 확장 개발 가이드나 C++ 개발용 VS Code 세팅처럼 범용 기능이나 특정 언어 세팅을 다루지 않습니다. 대신 우분투라는 배포판/데스크톱 환경에서만 발생하는 문제에 집중합니다. 디버깅 방법이나 추천 확장 프로그램 같은 일반적인 사용법은 이미 다른 글에서 다뤘으므로 이 글에서는 다루지 않거나 아주 짧게만 언급합니다.

대상 독자

  • 우분투 데스크톱을 메인 개발 환경으로 쓰는 백엔드/풀스택 개발자
  • GNOME Wayland 환경에서 VS Code 렌더링/입력 지연을 겪고 있는 사람
  • 리눅스 서버에 Remote-SSH로 접속해 원격 개발을 하려는 사람
  • 우분투 특유의 폰트, 키보드, 자격증명 저장 방식이 궁금한 사람

이 글을 읽으면

  • apt, snap, .deb 세 가지 설치 방식의 차이와 우분투에서의 권장 방법을 알 수 있습니다.
  • Wayland/X11 세션에 따른 렌더링·입력 지연 문제를 진단하고 해결할 수 있습니다.
  • inotify 한도 초과(ENOSPC) 오류의 근본 원인과 영구 해결법을 알 수 있습니다.
  • GNOME 다크모드/폰트/키보드 단축키를 VS Code와 매끄럽게 연동할 수 있습니다.
  • Remote-SSH로 원격 우분투 서버를 로컬처럼 개발할 수 있습니다.

실전 경험에서 배운 교훈

우분투에서 VS Code를 오래 써보면 가장 먼저 부딪히는 문제가 설치 방식입니다. Ubuntu Software(GNOME Software)를 열면 snap 버전이 검색 결과 최상단에 뜨는데, 별 생각 없이 이걸 설치하면 실행 속도가 눈에 띄게 느려지고, 특정 확장이 홈 디렉토리 밖의 파일(/etc, /usr 등)에 접근하지 못하는 샌드박스 제약에 부딪힙니다. 반대로 공식 APT 저장소를 등록하고 설치하면 일반 데스크톱 애플리케이션과 동일하게 동작하고 업데이트도 apt upgrade 한 번으로 끝납니다.

두 번째로 자주 겪는 문제는 최근 우분투 LTS 버전들이 기본 세션을 Wayland로 전환하면서 생긴 렌더링 이슈입니다. Electron 앱은 원래 X11을 전제로 설계되어 있어서, Wayland 세션에서는 XWayland라는 호환 계층을 거치게 되는데 이 과정에서 프레임 드롭과 입력 지연이 발생합니다. 특히 고해상도 모니터나 배율 조정(스케일링)을 쓰는 노트북에서 체감이 큽니다. 이 문제를 모르고 “VS Code가 원래 느린 편이구나”라고 오해하는 경우를 많이 봤습니다.

세 번째는 inotify 한도입니다. React/Next.js 같은 대형 프로젝트를 여러 개 동시에 열어두면 어느 순간부터 파일 저장 시 자동 감지가 되지 않거나, 터미널에 ENOSPC 에러가 뜨면서 워치가 아예 멈추는 경험을 하게 됩니다. 이건 우분투(리눅스 커널)의 기본 설정값이 개발 워크로드에 비해 낮게 잡혀 있기 때문이며, 커널 파라미터를 한 번 조정해두면 재부팅 후에도 유지되어 다시 겪을 일이 없습니다.

1. 설치 방식: apt vs snap vs .deb

세 가지 설치 경로의 차이

우분투에서 VS Code를 설치하는 방법은 크게 세 가지입니다. 첫째는 Microsoft의 공식 APT 저장소를 등록하고 apt install code로 설치하는 방법, 둘째는 snap install code --classic으로 스냅 패키지를 설치하는 방법, 셋째는 .deb 파일을 직접 다운로드해 dpkg -i로 설치하는 방법입니다.

# 방법 1: 공식 APT 저장소 등록 후 설치 (권장)
sudo apt update
sudo apt install -y wget gpg
wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
  | gpg --dearmor > packages.microsoft.gpg
sudo install -D -o root -g root -m 644 packages.microsoft.gpg \
  /etc/apt/keyrings/packages.microsoft.gpg
echo "deb [arch=amd64,arm64,armhf signed-by=/etc/apt/keyrings/packages.microsoft.gpg] \
  https://packages.microsoft.com/repos/code stable main" \
  | sudo tee /etc/apt/sources.list.d/vscode.list > /dev/null
sudo apt update
sudo apt install -y code

# 방법 2: snap (샌드박스 제약 있음, 비권장)
sudo snap install code --classic

# 방법 3: .deb 수동 설치 (업데이트가 수동으로만 반영됨)
wget -O vscode.deb https://update.code.visualstudio.com/latest/linux-deb-x64/stable
sudo apt install -y ./vscode.deb

이 세 방식은 겉보기엔 결과물이 비슷해 보이지만 내부 동작이 다릅니다. APT 저장소를 등록하면 이후 apt update && apt upgrade만 실행해도 VS Code가 다른 시스템 패키지와 함께 자동으로 최신 버전으로 갱신됩니다. 반면 snap은 AppArmor 기반 샌드박스 안에서 실행되기 때문에 홈 디렉토리 바깥의 파일 시스템 접근, 일부 시스템 트레이 아이콘, 특정 확장의 네이티브 바이너리 실행 등에서 예기치 못한 권한 오류를 만날 수 있습니다. .deb를 수동으로 받아 설치하면 자동 업데이트 자체가 되지 않아 계속 오래된 버전을 쓰게 되는 문제가 있습니다.

권장 사항: 개발용으로는 공식 APT 저장소를 등록하는 방법을 권장합니다. 한 번 등록해두면 이후 신경 쓸 일이 없고, 확장 프로그램의 네이티브 모듈(예: 디버거, 원격 개발 확장)이 시스템 리소스에 접근할 때 스냅 샌드박스로 인한 제약을 겪지 않습니다. 이미 snap으로 설치했다면 sudo snap remove code 후 위 방법 1로 재설치하는 것을 권장합니다.

2. Wayland vs X11: 렌더링·입력 지연 해결

왜 Wayland에서 VS Code가 느려지는가

우분투 22.04부터 GNOME 세션의 기본값이 Wayland로 바뀌었습니다. 문제는 VS Code를 비롯한 Electron 기반 애플리케이션들이 오랫동안 X11 프로토콜을 전제로 개발되어 왔다는 점입니다. Wayland 세션에서 X11 전용 앱을 실행하면 XWayland라는 호환 레이어를 거치는데, 이 과정에서 화면 합성(compositing)이 이중으로 일어나면서 스크롤 시 프레임이 끊기거나 타이핑한 글자가 화면에 반영되기까지 눈에 띄는 지연이 생깁니다. 특히 4K 모니터에 분수 배율(125%, 150% 등)을 적용한 환경에서 체감이 두드러집니다.

# 현재 세션이 Wayland인지 X11인지 확인
echo $XDG_SESSION_TYPE
# 출력이 'wayland'면 아래 방법 적용 대상

# 방법 1: VS Code가 네이티브 Wayland 렌더러를 쓰도록 강제
code --ozone-platform=wayland

# 매번 플래그를 입력하기 번거로우므로 실행 파일 자체에 반영
sudo sed -i "s|^Exec=/usr/share/code/code|Exec=/usr/share/code/code --ozone-platform=wayland|" \
  /usr/share/applications/code.desktop

# 방법 2: 그래도 렌더링이 불안정하면 GPU 가속을 끄고 소프트웨어 렌더링 사용
code --disable-gpu

# 두 옵션을 함께 쓰고 싶다면 settings.json에 인자를 추가하는 대신
# ~/.config/code-flags.conf 파일로 영구 적용 가능
echo "--ozone-platform=wayland" >> ~/.config/code-flags.conf

--ozone-platform=wayland 플래그는 Electron/Chromium이 XWayland를 거치지 않고 Wayland 컴포지터와 직접 통신하도록 강제합니다. 이렇게 하면 대부분의 경우 입력 지연이 눈에 띄게 줄어들고, 특히 트랙패드 스크롤이나 고배율 디스플레이에서의 커서 움직임이 훨씬 매끄러워집니다. 다만 일부 오래된 NVIDIA 독점 드라이버 조합에서는 Wayland 네이티브 렌더링 자체가 불안정해 화면이 깜빡이거나 완전히 멈추는 경우가 있는데, 이때는 --disable-gpu를 추가해 GPU 가속 자체를 포기하고 CPU 소프트웨어 렌더링으로 전환하면 안정성을 되찾을 수 있습니다. 물론 소프트웨어 렌더링은 애니메이션이나 대형 파일 스크롤이 다소 뻣뻣해지는 트레이드오프가 있습니다.

~/.config/code-flags.conf 파일은 VS Code가 시작할 때마다 자동으로 읽어들이는 플래그 목록 파일입니다. 매번 터미널에서 플래그를 입력하지 않아도 되고, 애플리케이션 런처(GNOME Activities)에서 아이콘을 클릭해 실행해도 동일하게 적용됩니다. 이 파일에 --ozone-platform=wayland와 --disable-gpu를 동시에 넣으면 렌더링 이슈로 고생하는 NVIDIA 노트북에서도 대부분 안정적으로 동작합니다.

트러블슈팅: 그래도 렌더링이 깨질 때

플래그를 적용해도 화면 일부가 그려지지 않거나 창을 옮길 때 잔상이 남는다면, 다음 순서로 원인을 좁혀나가는 것을 권장합니다.

  1. nvidia-smi 또는 glxinfo | grep "OpenGL renderer"로 실제 사용 중인 GPU 드라이버를 확인합니다. 오픈소스 Nouveau 드라이버와 NVIDIA 독점 드라이버가 혼재되어 있으면 렌더링이 불안정해지는 경우가 많습니다.
  2. journalctl --user -u gnome-shell --since "10 min ago"로 GNOME Shell 로그에서 관련 오류가 있는지 확인합니다.
  3. 그래도 해결되지 않으면 로그인 화면에서 세션을 “Ubuntu on Xorg”(X11)로 바꿔 임시로 우회할 수 있습니다. 근본 원인(드라이버 버전 불일치)을 해결할 때까지의 임시방편으로만 권장합니다.

3. inotify 한도 초과(ENOSPC) 해결

왜 발생하는가

VS Code는 파일 변경을 실시간으로 감지하기 위해 리눅스 커널의 inotify API를 사용합니다. 프로젝트 안의 모든 파일과 디렉토리마다 감시자(watcher)를 하나씩 등록하는데, node_modules가 수만 개의 파일을 포함하는 프로젝트를 열거나 여러 워크스페이스를 동시에 열어두면 커널이 허용하는 감시자 총량을 금방 넘어섭니다. 우분투의 기본값인 fs.inotify.max_user_watches=8192는 요즘 프론트엔드 프로젝트 기준으로는 매우 낮은 값입니다.

# 현재 한도 확인
cat /proc/sys/fs/inotify/max_user_watches
# 8192 (기본값)

# 영구 설정: sysctl 설정 파일 추가
echo "fs.inotify.max_user_watches=524288" | sudo tee /etc/sysctl.d/60-vscode.conf
echo "fs.inotify.max_user_instances=512" | sudo tee -a /etc/sysctl.d/60-vscode.conf

# 즉시 반영 (재부팅 불필요)
sudo sysctl --system

# 적용 확인
cat /proc/sys/fs/inotify/max_user_watches
# 524288

sysctl 명령을 터미널에 직접 입력해서 한도를 바꾸는 방법도 있지만, 그렇게 하면 재부팅 시 값이 초기화됩니다. /etc/sysctl.d/에 별도 설정 파일(60-vscode.conf 등 임의의 이름)을 만들어두면 부팅할 때마다 커널이 자동으로 이 값을 읽어들이므로 한 번만 설정하면 다시 신경 쓸 필요가 없습니다. max_user_watches는 감시할 수 있는 파일/디렉토리 개수, max_user_instances는 한 사용자가 동시에 만들 수 있는 inotify 인스턴스(즉 VS Code 창이나 다른 감시 프로그램의 개수) 상한을 의미합니다. VS Code 외에도 웹팩 dev server, nodemon 등도 같은 API를 쓰므로 이 값을 넉넉하게 잡아두면 여러 도구를 동시에 켜둬도 안전합니다.

흔한 실수: sysctl fs.inotify.max_user_watches=524288처럼 명령줄에서 직접 값을 바꾸고 끝내는 경우가 많은데, 이는 다음 재부팅 시 사라집니다. 반드시 /etc/sysctl.d/ 아래에 설정 파일로 남겨야 영구적으로 적용됩니다. VS Code를 재시작해도 오류가 계속되면 이미 열려 있던 워크스페이스를 완전히 닫았다가(창 자체를 종료) 다시 여는 것을 권장합니다. 값이 즉시 반영되더라도 이미 생성된 감시자 풀은 갱신되지 않기 때문입니다.

4. GNOME 폰트·한글 렌더링 설정

기본 폰트 렌더링이 흐릿하게 보일 때

우분투 기본 설치 상태에서는 폰트 힌팅(hinting)과 안티앨리어싱 설정이 배포판마다 조금씩 다르게 적용되어, 특히 저해상도 모니터에서 VS Code 에디터 폰트가 흐릿하게 보이는 경우가 있습니다. 또한 한글 주석이나 문자열을 다루는 개발자라면 기본 모노스페이스 폰트에 한글 글리프가 아예 없어서 시스템이 임의의 대체 폰트(보통 굵고 볼드하게 보이는 폰트)로 렌더링하는 문제를 겪습니다.

# 나눔고딕 코딩용 폰트 설치 (한글 고정폭 지원)
sudo apt install -y fonts-nanum fonts-nanum-coding

# 설치된 폰트 확인
fc-list | grep -i nanum
// settings.json — 영문/한글 폰트를 함께 지정해 가독성 확보
{
  "editor.fontFamily": "'D2Coding', 'NanumGothicCoding', 'Cascadia Code', monospace",
  "editor.fontLigatures": true,
  "editor.fontSize": 14
}

fontFamily에 여러 폰트를 쉼표로 나열하면 브라우저 CSS의 font-family처럼 앞쪽 폰트에 없는 글리프(한글 등)를 뒤쪽 폰트에서 순서대로 찾아 대체합니다. D2Coding이나 NanumGothicCoding처럼 한글 전용으로 폭이 영문 2배로 정확히 맞춰진 고정폭 폰트를 함께 지정해두면, 영문과 한글이 섞인 주석에서도 정렬이 흐트러지지 않습니다. fonts-nanum-coding 패키지는 나눔고딕코딩체를 시스템 폰트로 설치해주며, 설치 후에는 VS Code를 재시작해야 폰트 목록에 반영됩니다.

5. 리눅스 전용 키보드 단축키

Windows/Mac과 다른 점

VS Code의 기본 키 바인딩은 플랫폼마다 다르게 매핑되어 있습니다. 우분투(리눅스) 프리셋은 대체로 Windows와 유사하지만, GNOME 데스크톱 자체가 선점하는 전역 단축키와 충돌하는 경우가 종종 있습니다. 대표적으로 Ctrl+Alt+방향키는 GNOME의 워크스페이스 전환에, Super+D(또는 Ctrl+Alt+D)는 바탕화면 보기에, Ctrl+Alt+T는 일부 배포판에서 터미널 실행에 이미 할당되어 있어 VS Code 안에서 같은 조합을 커스텀 키 바인딩으로 쓰려 하면 아무 반응이 없거나 데스크톱 동작이 먼저 실행됩니다.

// keybindings.json — GNOME과 충돌하는 조합을 피해 재매핑한 예시
[
  {
    "key": "ctrl+alt+right",
    "command": "-workbench.action.terminal.focusNext"
  },
  {
    "key": "ctrl+shift+.",
    "command": "workbench.action.terminal.focusNext"
  },
  {
    "key": "ctrl+shift+,",
    "command": "workbench.action.terminal.focusPrevious"
  }
]

명령 앞에 붙은 하이픈(-)은 VS Code 키 바인딩 파일에서 기존 기본 바인딩을 “해제”하겠다는 의미입니다. GNOME이 Ctrl+Alt+방향키를 워크스페이스 전환용으로 이미 가로채고 있기 때문에, 이 조합에 의존하는 VS Code 기본 단축키(터미널 탭 이동 등)는 리눅스에서는 사실상 동작하지 않는 죽은 단축키가 됩니다. 이를 해제하고 GNOME과 겹치지 않는 조합(Ctrl+Shift+, / Ctrl+Shift+. 등)으로 재매핑하면 됩니다. GNOME 전역 단축키 자체를 바꾸고 싶다면 설정 앱의 “키보드 > 바로가기”에서 워크스페이스 전환 단축키를 다른 조합으로 옮기는 것도 방법입니다.

6. Remote-SSH로 원격 우분투 서버 개발

로컬 우분투에서 원격 리눅스 서버로

우분투 데스크톱을 로컬 개발 머신으로 쓰면서, 실제 빌드나 테스트는 스펙이 더 좋은 원격 리눅스 서버(사내 개발 서버, 클라우드 VM 등)에서 돌리고 싶은 경우가 많습니다. 이때 필요한 것이 Remote-SSH 확장입니다. WSL과 헷갈리기 쉬운데, WSL은 Windows 안에서 리눅스를 돌리는 기능이므로 이미 우분투를 로컬 OS로 쓰고 있다면 해당하지 않고, Remote-SSH는 순수하게 SSH 프로토콜로 원격 머신에 VS Code 서버를 설치해 로컬처럼 편집·디버깅하는 방식입니다.

# 1. 로컬 우분투에서 SSH 키 생성 (이미 있다면 생략)
ssh-keygen -t ed25519 -C "dev@local-ubuntu"

# 2. 공개키를 원격 서버에 등록
ssh-copy-id [email protected]

# 3. ~/.ssh/config에 호스트 등록 (Remote-SSH 확장이 이 목록을 읽음)
cat >> ~/.ssh/config << 'EOF'
Host devbox
    HostName remote-server.example.com
    User user
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
EOF

VS Code에서 Remote-SSH: Connect to Host를 실행하고 devbox를 선택하면, VS Code는 원격 서버에 자동으로 작은 서버 컴포넌트(VS Code Server)를 설치하고 로컬 에디터 UI만 남긴 채 나머지 언어 서버·터미널·디버거를 전부 원격에서 실행합니다. 로컬 우분투 머신의 자원(CPU, 메모리)은 거의 쓰지 않고, 원격 서버의 파일 시스템을 마치 로컬 디렉토리처럼 탐색·편집할 수 있습니다. ServerAliveInterval 60은 SSH 연결이 방화벽이나 NAT 타임아웃으로 끊기지 않도록 60초마다 keepalive 패킷을 보내는 설정으로, 장시간 디버깅 세션 중 연결이 끊기는 문제를 예방합니다.

흔한 실수: 원격 서버의 ~/.vscode-server 디렉토리가 로컬 VS Code 버전과 맞지 않아 연결이 반복 실패하는 경우가 있습니다. 이때는 원격 서버에서 rm -rf ~/.vscode-server로 캐시를 지우고 다시 연결하면 최신 버전이 재설치되면서 해결됩니다. 또한 사내망 서버라면 배스천(bastion) 호스트를 거쳐야 하는 경우가 많은데, ~/.ssh/config에 ProxyJump bastion-host 한 줄만 추가하면 Remote-SSH 확장이 자동으로 점프 호스트를 경유해 접속합니다.

7. GNOME 다크모드·테마 연동

우분투(GNOME)의 시스템 다크모드 설정과 VS Code 테마를 수동으로 따로 바꾸는 대신 자동으로 동기화하고 싶다면, GNOME의 color-scheme 설정을 감지하는 확장을 쓰거나 다음과 같이 간단한 셸 스크립트로 처리할 수 있습니다.

# 현재 GNOME 색상 테마 확인
gsettings get org.gnome.desktop.interface color-scheme
# 'prefer-dark' 또는 'default'

# settings.json에서 window.autoDetectColorScheme을 켜두면
# OS 테마 변경 시 VS Code가 자동으로 다크/라이트 테마를 전환합니다.
// settings.json
{
  "window.autoDetectColorScheme": true,
  "workbench.preferredDarkColorTheme": "Default Dark Modern",
  "workbench.preferredLightColorTheme": "Default Light Modern"
}

window.autoDetectColorScheme은 VS Code가 OS 수준의 다크/라이트 설정 변화를 감지해 지정된 두 테마 사이를 자동으로 전환하게 해주는 옵션입니다. GNOME의 설정 앱에서 “다크 스타일”을 켜고 끌 때마다 VS Code 창도 함께 즉시 바뀌므로, 밤에 작업할 때 매번 테마를 수동으로 바꾸는 번거로움을 없앨 수 있습니다.

8. GPU 가속 회피가 필요한 다른 상황들

앞서 Wayland 절에서 다룬 --disable-gpu 외에도, 우분투에서 흔히 겪는 GPU 관련 렌더링 버그가 몇 가지 더 있습니다. 특히 하이브리드 그래픽(인텔 내장 + NVIDIA 외장)을 쓰는 노트북에서 prime-select로 그래픽 카드를 전환한 직후 VS Code 창이 완전히 검게 렌더링되는 경우가 있는데, 이는 GPU 드라이버 전환 후 Electron의 GPU 캐시가 꼬였기 때문입니다.

# GPU 캐시를 초기화하고 소프트웨어 렌더링으로 안전하게 재시작
rm -rf ~/.config/Code/GPUCache
code --disable-gpu-sandbox

# 특정 확장(예: 원격 컨테이너 개발) 사용 중 렌더링이 깨지면
# GPU 가속 자체를 완전히 끄고 재시작
code --disable-gpu --disable-software-rasterizer

~/.config/Code/GPUCache 디렉토리는 Chromium 엔진이 GPU 셰이더 컴파일 결과를 캐싱해두는 곳으로, 그래픽 드라이버 버전이 바뀌면 이 캐시가 새 드라이버와 맞지 않아 화면이 깨지는 원인이 됩니다. 캐시를 지우고 재시작하면 VS Code가 처음부터 다시 셰이더를 컴파일하므로 안전하게 복구됩니다. --disable-gpu-sandbox는 GPU 프로세스의 샌드박스만 완화하는 옵션이라 --disable-gpu보다 성능 저하가 적으므로, 완전히 GPU를 끄기 전에 먼저 시도해볼 만합니다.

9. settings.json / keybindings.json 위치와 터미널 통합

우분투에서 VS Code의 사용자 설정 파일은 다음 경로에 저장됩니다. Windows(%APPDATA%\Code\User\)나 macOS(~/Library/Application Support/Code/User/)와는 경로 구조가 다르므로, 여러 OS를 오가며 dotfiles를 동기화하는 경우 이 차이를 알아두면 스크립트 작성에 도움이 됩니다.

~/.config/Code/User/settings.json       # 전역 사용자 설정
~/.config/Code/User/keybindings.json    # 커스텀 키 바인딩
~/.config/Code/User/snippets/           # 사용자 정의 스니펫
// settings.json — zsh를 기본 통합 터미널로 지정
{
  "terminal.integrated.defaultProfile.linux": "zsh",
  "terminal.integrated.profiles.linux": {
    "zsh": {
      "path": "/usr/bin/zsh",
      "args": ["-l"]
    }
  }
}

우분투는 기본 셸로 bash를 쓰지만, oh-my-zsh 등으로 zsh를 메인 셸로 바꾼 개발자가 많습니다. 문제는 zsh를 시스템 기본 셸(chsh -s $(which zsh))로 바꿔도 VS Code 내장 터미널이 이를 자동으로 따라가지 않는 경우가 있다는 점입니다. terminal.integrated.defaultProfile.linux를 명시적으로 지정해주면 VS Code 내장 터미널이 항상 지정한 셸로 열립니다. args: ["-l"]은 로그인 셸로 실행하라는 의미로, .zprofile이나 .bash_profile에 정의한 환경변수(예: nvm, pyenv 초기화 스크립트)가 VS Code 터미널에서도 동일하게 로드되도록 보장합니다. 이 옵션이 빠지면 터미널에서 nvm: command not found 같은 오류를 겪게 되는데, 원인은 대부분 로그인 셸이 아니어서 초기화 스크립트가 실행되지 않았기 때문입니다.

10. git 자격증명 연동 (libsecret/GNOME Keyring)

HTTPS로 원격 저장소를 clone/push할 때마다 사용자명과 비밀번호(또는 개인 액세스 토큰)를 매번 입력하는 것은 번거롭습니다. macOS는 Keychain을, Windows는 Credential Manager를 기본 제공하지만 우분투에서는 GNOME Keyring을 활용한 libsecret 기반 credential helper를 직접 등록해야 합니다.

# libsecret 관련 패키지 설치
sudo apt install -y libsecret-1-0 libsecret-1-dev

# git-credential-libsecret 빌드 (git 소스 패키지에 포함되어 있음)
sudo apt install -y build-essential
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make

# git 전역 설정에 credential helper 등록
git config --global credential.helper \
  /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

이렇게 등록해두면 첫 push 시 입력한 자격증명이 GNOME 로그인 키링(로그인 비밀번호로 암호화된 저장소)에 안전하게 저장되고, 이후에는 다시 묻지 않습니다. VS Code 내장 소스 제어 패널에서 push/pull을 할 때도 내부적으로 같은 git 설정을 그대로 사용하므로 터미널과 VS Code UI 양쪽 모두에서 재입력 없이 동작합니다. 참고로 GitHub/GitLab에서 비밀번호 인증이 더 이상 지원되지 않는 경우가 많으므로, 저장할 자격증명은 비밀번호가 아니라 개인 액세스 토큰(Personal Access Token)이어야 합니다.

흔한 실수: git config --global credential.helper store로 설정하면 자격증명이 ~/.git-credentials 파일에 평문으로 저장됩니다. 편리하지만 보안상 권장하지 않으며, 우분투에서는 반드시 GNOME Keyring 기반의 libsecret helper를 사용하는 것을 권장합니다.

결론

우분투에서 VS Code를 쓸 때 겪는 문제들은 대부분 “리눅스 데스크톱 환경 자체의 특성”에서 비롯됩니다. Wayland 전환에 따른 렌더링 지연, 커널 레벨의 inotify 한도, GNOME이 선점하는 전역 단축키, 그리고 apt/snap이라는 배포판 고유의 패키지 관리 방식 차이가 대표적입니다. 이 글에서 다룬 설정들은 대부분 한 번만 적용해두면 이후 다시 신경 쓸 필요가 없는 것들이므로, 새로 우분투 개발 환경을 세팅한다면 이 글의 순서(설치 방식 → 렌더링 → inotify → 폰트/키보드 → 원격 개발)대로 하나씩 점검해보는 것을 권장합니다. 더 범용적인 리눅스 명령어나 서버 운영 지식이 필요하다면 우분투 필수 명령어 가이드와 리눅스·맥 명령어 실전 가이드를 함께 참고하시기 바랍니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.