Omarchy 설치 전 기존 개발 환경을 그대로 살리는 세 가지 설정
TuBrief 편집팀
2026년 9월 12일
0
컴퓨터/소프트웨어원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
베이스캠프(Basecamp)가 주도해 공개한 아치 리눅스(Arch Linux) 기반 오피니언 배포판 Omarchy는 하이프랜드(Hyprland) 타일링 컴포지터와 퀵셸(Quickshell) 데스크톱 툴킷을 묶어 기본 설치 상태부터 정교한 작업 화면을 띄워줍니다. 수동 닷파일(dotfiles) 관리에 피로를 느끼는 엔지니어에게 매력적인 시스템이지만, 쓰던 홈 디렉터리에 그대로 덮어씌웠다가는 세션 매니저부터 먹통이 됩니다.
기존에 쓰던 Neovim, Docker 컨테이너, 커스텀 셸 환경을 깨뜨리지 않고 Omarchy를 얹으려면 세 가지 구체적인 충돌 지점부터 격리해야 합니다.
배포판 전환 과정에서 발생하는 부팅 실패의 대부분은 XDG 규격을 벗어난 이전 런타임 파일과 시스템 기본 구성의 충돌에서 시작됩니다. Omarchy는 시스템 설정을 /usr/share/omarchy에 두고 사용자 재정의 설정을 ~/.config에 강제하는 구조를 씁니다. 만약 쓰던 hyprland.conf나 웨이바(Waybar) 스타일시트가 그대로 남아 있으면 퀵셸 네이티브 모듈(~/.config/omarchy/shell.json)과 파라미터가 꼬이면서 Wayland 핸드셰이크 단계에서 화면이 멈춥니다. 셸 스크립트에 남아 있는 비표준 PATH나 LD_LIBRARY_PATH 때문에 기본 터미널이 그래픽 드라이버를 잡지 못하고 튕기기도 합니다.
기존 환경을 건드리지 않고 형상을 보존하려면 작업 트리를 홈 디렉터리로 매핑하는 Git 베어(bare) 저장소 패턴을 써야 합니다. GNU Stow처럼 심볼릭 링크를 일일이 거는 방식은 기존 파일이 있으면 작업을 멈춰버려 되돌리기가 번거롭습니다.
git init --bare "$HOME/.dotfiles.git"
alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles.git/ --work-tree=$HOME'
dotfiles config --local status.showUntrackedFiles no
dotfiles add ~/.config/nvim ~/.config/tmux ~/.zshrc ~/.gitconfig
dotfiles commit -m "chore: snapshot pre-omarchy"
dotfiles archive --format=tar.gz -o "$HOME/pre_omarchy_backup_$(date +%Y%m%d).tar.gz" HEAD
백업 아카이브를 만든 뒤, 충돌을 일으키는 데스크톱 디렉터리를 홈 디렉터리 바깥 격리 폴더로 치웁니다.
mkdir -p "$HOME/.config_quarantine"
for dir in hypr waybar foot alacritty rofi; do
[ -d "$HOME/.config/$dir" ] && mv "$HOME/.config/$dir" "$HOME/.config_quarantine/"
done
데스크톱 설정을 치워두면 Omarchy 기본 퀵셸이 정상적으로 구동되고, 코드 편집기나 터미널 셸 설정은 원래 쓰던 상태 그대로 유지할 수 있습니다.
Omarchy는 Claude Code나 OpenCode 같은 AI 코딩 도구를 데스크톱 내부 워크플로우에 깊게 결합해 둡니다. 문제는 이들 도구가 호스트 터미널의 권한을 그대로 물려받는다는 점입니다. 서브프로세스 실행만 제한하고 파일 입출력 시스템 콜을 감시하지 않는 런타임이 많아, 프롬프트 인젝션이나 예기치 않은 스크립트 실행이 발생하면 ~/.ssh, ~/.aws, ~/.gnupg 폴더와 도커 소켓이 무방비로 노출됩니다.
리눅스 커널의 비특권 사용자 네임스페이스(Unprivileged User Namespaces)를 다루는 버블랩(Bubblewrap)으로 최소 권한 실행 환경을 짜야 합니다. 민감한 인증 키 폴더 위에 빈 메모리 마운트를 덮어씌우면 읽기 작업 자체를 막을 수 있습니다.
#!/usr/bin/env bash
# /usr/local/bin/agent-jail: Bubblewrap 기반 AI 에이전트 격리 실행기
set -euo pipefail
WORKSPACE="${1:-$(pwd)}"
DUMMY_DIR=$(mktemp -d /tmp/jail-empty-XXXXXX)
trap 'rm -rf "${DUMMY_DIR}"' EXIT
exec bwrap \
--ro-bind /usr /usr \
--ro-bind /lib /lib \
--ro-bind /lib64 /lib64 \
--ro-bind /bin /bin \
--ro-bind /etc/resolv.conf /etc/resolv.conf \
--ro-bind /etc/ssl /etc/ssl \
--ro-bind /etc/ca-certificates /etc/ca-certificates \
--proc /proc \
--dev /dev \
--tmpfs /tmp \
--tmpfs "$HOME" \
--bind "$WORKSPACE" "$WORKSPACE" \
--ro-bind "$DUMMY_DIR" "$HOME/.ssh" \
--ro-bind "$DUMMY_DIR" "$HOME/.aws" \
--ro-bind "$DUMMY_DIR" "$HOME/.gnupg" \
--unshare-all \
--share-net \
--unshare-pid \
--new-session \
--die-with-parent \
--setenv PATH "/usr/local/bin:/usr/bin:/bin" \
--setenv HOME "$HOME" \
--chdir "$WORKSPACE" \
-- /usr/bin/opencode "$@"
API 키를 전역 환경 변수에 평문으로 박아두는 방식도 피해야 합니다. chmod 700 권한을 준 ~/.config/secure-vault 디렉터리에 ai.env 파일을 만들고 권한을 chmod 600으로 묶어둔 뒤, 스크립트 실행 시점에만 서브셸로 읽어 들여야 /proc/$PID/environ 조회를 통한 토큰 유출을 막을 수 있습니다.
기존 Neovim 구성을 Omarchy에 가져올 때 가장 자주 터지는 곳은 Mason 플러그인입니다. Mason이 GitHub에서 내려받는 사전 컴파일 바이너리는 롤링 릴리스 환경에서 최신 glibc 심볼과 어긋나면서 실행 오류를 뿜어냅니다.
Mason의 자동 바이너리 다운로드를 끄고 아치 공식 리포지토리의 네이티브 패키지로 LSP 경로를 돌려놓으면 이 문제가 사라집니다. 네트워크 다운로드 단계와 래퍼 계층이 빠지면서 에디터 초기 로딩 시간도 30ms 안쪽으로 떨어집니다.
-- ~/.config/nvim/lua/plugins/lsp-native.lua
return {
{
"williamboman/mason.nvim",
opts = { auto_install = false },
},
{
"neovim/nvim-lspconfig",
opts = {
servers = {
gopls = { cmd = { "/usr/bin/gopls" } },
pyright = { cmd = { "/usr/bin/pyright-langserver", "--stdio" } },
rust_analyzer = { cmd = { "/usr/bin/rust-analyzer" } },
lua_ls = { cmd = { "/usr/bin/lua-language-server" } },
},
},
},
}
설정 후 터미널에서 바이너리를 직접 깔아줍니다.
sudo pacman -S --needed gopls pyright rust-analyzer lua-language-server ripgrep fd
마지막 걸림돌은 도커입니다. Omarchy는 루트리스(Rootless) 도커를 기본으로 사용합니다. 커널의 서브 UID 매핑 규칙 때문에 호스트의 파일 소유권과 컨테이너 내부 사용자 권한 사이에 오프셋이 생깁니다.
호스트 /etc/subuid에 할당된 시작 번호가 100000이라면, 컨테이너 안의 일반 사용자(UID 1000)는 호스트 관점에서 UID 100999()로 인식됩니다. 소스 코드를 바인드 마운트(-v $(pwd):/workspace)했을 때 쓰기 권한이 막혀 에러를 내는 이유가 여기에 있습니다. 프로젝트 디렉터리에 POSIX 접근 제어 목록(ACL) 상속 규칙을 지정해 두면 호스트 소유권을 어지럽히지 않고도 컨테이너 프로세스에 쓰기 권한을 열어줄 수 있습니다.
#!/usr/bin/env bash
# docker-rootless-align: Rootless Docker 서브 UID 볼륨 마운트 권한 자동 보정
set -euo pipefail
TARGET_PATH="${1:-$(pwd)}"
CURRENT_USER=$(whoami)
SUBUID_START=$(grep "^${CURRENT_USER}:" /etc/subuid | cut -d: -f2 || true)
if [[ -z "$SUBUID_START" ]]; then
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 "${CURRENT_USER}"
SUBUID_START=100000
fi
HOST_MAPPED_UID=$(( SUBUID_START + 1000 - 1 ))
setfacl -R -m "u:${HOST_MAPPED_UID}:rwx" "$TARGET_PATH"
setfacl -R -d -m "u:${HOST_MAPPED_UID}:rwx" "$TARGET_PATH"
sudo loginctl enable-linger "${CURRENT_USER}"
systemctl --user enable --now docker.service
설정을 마쳤다면 터미널에서 hyprctl instances로 활성 윈도우 인스턴스를 점검하고, nvim --headless "+checkhealth" +qa로 LSP 동작을 확인합니다. docker run --rm alpine ping -c 1 1.1.1.1 명령어로 서브네임스페이스 네트워크까지 통과하면 일상 개발 작업을 그대로 이어갈 준비가 끝납니다.