터미널 설정을 정리하기 전까지는 새 PC를 세팅할 때마다 같은 일을 반복했습니다. Windows Terminal 테마를 다시 맞추고, WSL Ubuntu에서 alias를 복사하고, Git Bash 설정을 다시 만들고, VS Code 터미널 기본 셸을 바꾸는 식이었습니다. 그때마다 “이번에는 제대로 백업해둬야지”라고 생각했지만, 실제로는 메모장과 클라우드 폴더에 설정 조각만 흩어져 있었습니다.
그래서 2026년 1월 3일부터 2월 20일까지 Windows 11 환경에서 Dotfiles를 정리했습니다. 사용 환경은 Windows 11, Windows Terminal, WSL Ubuntu, Git Bash, VS Code였습니다. 처음 관리한 설정 파일 수는 총 23개였고, 최종 Dotfiles 저장소에 남긴 파일 수는 14개였습니다. 삭제하거나 제외한 설정 파일은 9개였습니다.
이 글은 Dotfiles 개념을 설명하는 글이 아닙니다. 제가 실제로 터미널 설정을 하나의 저장소로 모으는 과정에서 alias 충돌, PATH 오류, 절대경로 문제를 겪고 기준을 만든 후기입니다.
처음에는 설정 파일을 전부 저장소에 넣으려고 했다
처음에는 모든 설정을 백업하면 안전하다고 생각했습니다. Windows Terminal의 settings.json, WSL의 .bashrc, .profile, Git Bash의 .bashrc, Git 설정, VS Code 터미널 설정, PowerShell 프로필까지 전부 모았습니다. 그렇게 하니 설정 파일이 금방 23개가 됐습니다.
문제는 그중 일부가 실제로는 필요 없는 파일이었다는 점입니다. 예전에 테스트용으로 만든 설정, 특정 프로젝트에서만 쓰던 PATH, 임시 alias, 더 이상 사용하지 않는 터미널 테마가 섞여 있었습니다. 저장소가 커질수록 복구가 쉬워지는 것이 아니라, 어떤 파일을 적용해야 하는지 더 헷갈렸습니다.
그래서 45일 동안 실제로 쓰는 파일만 남겼습니다. 최종적으로 Dotfiles 저장소에 남긴 파일 수는 14개였고, 나머지 9개는 삭제하거나 제외했습니다. 이때부터 Dotfiles는 많이 모으는 것이 아니라, 다시 설치할 때 필요한 설정만 남기는 작업이라고 느꼈습니다.
가장 큰 실패: .bashrc와 .zshrc alias 중복
가장 크게 당황했던 실패는 .bashrc와 .zshrc에 같은 alias를 중복 등록한 일이었습니다. 같은 명령어 이름을 두 파일에 각각 다르게 적어두었고, 터미널에 따라 예상과 다르게 실행됐습니다.
예를 들어 어떤 터미널에서는 gs가 git status로 실행됐는데, 다른 환경에서는 제가 임시로 만든 스크립트가 실행됐습니다. 처음에는 Git 문제인 줄 알았지만, 확인해보니 alias가 여러 파일에서 중복 정의된 것이 원인이었습니다.
처음 사용한 alias 수는 41개였습니다. 많으면 편할 줄 알았지만, 실제로 매일 쓰는 것은 절반도 되지 않았습니다. 결국 최종 유지한 alias 수는 18개로 줄였습니다. 매일 쓰는 Git 명령어, 폴더 이동, VS Code 실행, 로그 확인 정도만 남겼습니다.
Dotfiles 정리 전후 비교표
| 설정 항목 | 정리 전 상태 | 정리 후 상태 | 문제점 | 개선 방식 | 실제 효과 |
|---|---|---|---|---|---|
| 설정 파일 | 총 23개 | 14개만 저장소에 유지 | 테스트용 설정과 실제 설정이 섞임 | 복구에 필요한 파일만 선별 | 새 PC 적용 과정이 단순해짐 |
| alias | 41개 | 18개 | 기억하지 못하는 alias와 중복 명령어가 많음 | 매일 쓰는 명령어만 유지 | 명령어 오작동이 줄어듦 |
| 터미널 프로필 | 7개 | 3개 | 비슷한 프로필이 많아 선택이 번거로움 | Windows Terminal, WSL Ubuntu, Git Bash 중심으로 정리 | 작업 환경 선택이 빨라짐 |
| Git 설정 | 개인 설정과 공통 설정이 섞임 | 공통 설정과 로컬 설정 분리 | Git 관련 설정 오류 6회 발생 | 사용자 정보와 credential 설정 제외 | 잘못된 계정으로 커밋하는 실수가 줄어듦 |
| PATH 설정 | 여러 파일에서 중복 등록 | OS별 설정 파일로 분리 | PATH 충돌 오류 4회 발생 | Windows, WSL, Git Bash 경로를 따로 관리 | 명령어 실행 우선순위가 안정됨 |
| 복구 문서 | 기억에 의존 | README에 복구 순서 기록 | 새 PC 세팅 때 순서를 자주 잊음 | install 스크립트와 수동 설정 순서 작성 | 세팅 시간이 2시간 20분에서 38분으로 감소 |
터미널 프로필 7개를 3개로 줄였다
Windows Terminal에는 처음에 프로필이 7개 있었습니다. PowerShell, 명령 프롬프트, WSL Ubuntu, Git Bash, Node 전용, Python 전용, 테스트용 프로필까지 만들어두었습니다. 보기에는 그럴듯했지만 실제로는 거의 쓰지 않는 프로필이 많았습니다.
최종적으로는 3개만 남겼습니다. 기본 Windows 작업용, WSL Ubuntu 개발용, Git Bash 호환성 확인용입니다. Node나 Python 전용 프로필은 별도로 유지하지 않았습니다. 프로젝트별 가상환경이나 VS Code 터미널에서 처리하는 편이 더 단순했습니다.
프로필을 줄인 뒤에는 터미널을 열 때 고민이 줄었습니다. 예전에는 “이 프로젝트는 어떤 프로필로 열어야 하지?”를 생각했지만, 지금은 대부분 WSL Ubuntu에서 작업하고, Windows 경로 확인이 필요할 때만 Git Bash를 열었습니다.
절대경로를 저장소에 올렸다가 다른 노트북에서 깨졌다
또 다른 실패 사례는 절대경로 문제였습니다. 처음에는 제 노트북에서 잘 작동하는 경로를 그대로 설정 파일에 넣었습니다. 예를 들면 사용자 폴더, 프로젝트 폴더, 특정 프로그램 설치 경로가 그대로 들어갔습니다.
문제는 다른 노트북에서 발생했습니다. 사용자 이름이 다르고, WSL 경로도 다르고, Git Bash에서 인식하는 드라이브 위치도 달랐습니다. 제 PC에서는 잘 되던 설정이 다른 노트북에서는 바로 깨졌습니다.
이후에는 절대경로를 줄였습니다. 꼭 필요한 경로는 환경변수로 분리하거나 README에 수동 설정 항목으로 적었습니다. Dotfiles 저장소에는 “내 컴퓨터에서만 되는 설정”이 아니라 “다른 환경에서도 재현 가능한 설정”만 남기려고 했습니다.
Git 관련 설정 오류 6회와 PATH 충돌 4회
정리 기간 동안 Git 관련 설정 오류는 6회 발생했습니다. 대부분 사용자 이름, 이메일, credential helper, 줄바꿈 설정이 섞이면서 생긴 문제였습니다. 회사 작업과 개인 작업을 같은 Git 설정으로 처리하려다 보니 커밋 계정이 잘못 잡히는 경우도 있었습니다.
PATH 충돌 오류는 4회 있었습니다. 같은 node, python, git 명령어가 Windows 쪽에서 실행될 때도 있고, WSL 안에서 실행될 때도 있었습니다. 어떤 터미널에서 어떤 경로가 먼저 잡히는지 명확하지 않았습니다.
이 문제를 줄이기 위해 OS별 설정을 분리했습니다. WSL 설정은 WSL 폴더에, Git Bash 설정은 Git Bash 전용 파일에, Windows Terminal 설정은 터미널 프로필용으로만 관리했습니다. PATH는 아무 파일에나 추가하지 않고, 필요한 위치에서 한 번만 등록했습니다.
install 스크립트를 만들고 새 PC 세팅 시간이 줄었다
Dotfiles를 정리하기 전에는 새 PC 환경 세팅에 2시간 20분 정도 걸렸습니다. 프로그램 설치, 터미널 설정 복사, Git 설정, VS Code 터미널 설정, alias 복사, PATH 수정까지 전부 손으로 했습니다.
정리 후에는 새 PC 환경 세팅 시간이 38분으로 줄었습니다. 가장 효과가 컸던 것은 install 스크립트였습니다. 모든 것을 자동화한 것은 아니지만, 기본 폴더 확인, 설정 파일 복사, 심볼릭 링크 생성, Git 기본 설정 확인 정도는 스크립트로 처리했습니다.
dotfiles/
README.md
install.ps1
install.sh
windows/
terminal-settings.json
wsl/
bashrc
profile
gitbash/
bashrc-gitbash
git/
gitconfig-common
vscode/
settings-terminal.json이 구조로 나누니 어떤 설정이 어디에 적용되는지 훨씬 명확해졌습니다. 특히 install 스크립트보다 중요한 것은 README였습니다. 스크립트가 처리하지 못하는 수동 작업 순서를 기록해두니 다음 세팅 때 기억에 의존하지 않아도 됐습니다.
README에 복구 순서를 적은 것이 생각보다 중요했다
처음에는 설정 파일만 있으면 충분하다고 생각했습니다. 하지만 실제로 새 환경에서 복구하려고 하니 순서가 중요했습니다. Git을 먼저 설치해야 하는지, WSL을 먼저 켜야 하는지, Windows Terminal 설정을 언제 덮어써야 하는지 헷갈렸습니다.
그래서 README에 복구 순서를 적었습니다. Windows 기본 프로그램 설치, Git 설치, WSL Ubuntu 설정, 저장소 clone, install 스크립트 실행, VS Code 터미널 확인, Git 사용자 정보 별도 입력 순서로 정리했습니다.
이 문서가 없었다면 Dotfiles 저장소는 그냥 설정 파일 모음에 가까웠을 겁니다. README를 만든 뒤에야 실제로 복구 가능한 백업처럼 느껴졌습니다.
민감 정보는 저장소에서 제외했다
Dotfiles를 Git 저장소로 관리하면서 가장 조심한 부분은 보안이었습니다. 편의를 위해 설정 파일 안에 개인 이메일, 회사 서버 주소, 토큰, 프로젝트 경로가 섞여 있었습니다. 이것을 그대로 올리면 위험했습니다.
그래서 민감 정보는 저장소에서 제외했습니다. 실제 값이 들어간 파일 대신 예시 파일만 남겼습니다. 예를 들어 .env는 올리지 않고 .env.example만 남겼습니다. SSH 키, API 토큰, 회사 내부 주소, credential 관련 파일은 Dotfiles 저장소에 넣지 않았습니다.
이 과정에서 Dotfiles 관리는 편의성만의 문제가 아니라는 것을 느꼈습니다. 백업이 편해져도 민감 정보가 노출되면 더 큰 문제가 될 수 있습니다.
비교 기준별 실제 체감
복구 속도
새 PC 환경 세팅 시간이 기존 2시간 20분에서 38분으로 줄었습니다. 설정 파일을 찾고 복사하는 시간이 크게 줄었습니다.
재현성
절대경로를 줄이고 OS별 설정을 분리하니 다른 노트북에서도 설정이 덜 깨졌습니다. 내 PC에서만 되는 설정을 줄이는 것이 핵심이었습니다.
보안
민감 정보를 제외하니 저장소를 관리하는 부담이 줄었습니다. Dotfiles에는 SSH 키나 토큰이 절대 들어가면 안 된다는 기준이 생겼습니다.
설정 충돌
alias 중복, Git 설정 오류 6회, PATH 충돌 오류 4회를 겪은 뒤 설정을 줄였습니다. 많은 설정보다 충돌 없는 설정이 더 중요했습니다.
유지보수 난이도
23개 파일을 모두 관리할 때보다 14개만 남긴 뒤 유지보수가 쉬워졌습니다. alias도 41개에서 18개로 줄이니 기억하기 편했습니다.
결론: Dotfiles 관리는 터미널 꾸미기가 아니라 개발 환경 백업 전략이었다
2026년 1월 3일부터 2월 20일까지 Windows Terminal, WSL Ubuntu, Git Bash, VS Code 터미널 설정을 정리한 결론은 분명합니다. Dotfiles 관리는 멋진 터미널 꾸미기가 아니라, 개발 환경을 다시 만들 수 있게 기록하는 백업 전략이었습니다.
처음에는 설정 파일 23개, alias 41개, 터미널 프로필 7개로 시작했습니다. 하지만 실제로 정리해보니 많을수록 좋은 것이 아니었습니다. 최종적으로 저장소에는 14개 파일만 남겼고, alias는 18개, 터미널 프로필은 3개로 줄였습니다.
가장 큰 실패는 .bashrc와 .zshrc에 같은 alias를 중복 등록해 명령어가 예상과 다르게 실행된 일이었습니다. 또 절대경로를 그대로 저장소에 올려 다른 노트북에서 설정이 깨진 경험도 있었습니다. 여기에 Git 관련 설정 오류 6회, PATH 충돌 오류 4회를 겪으면서 OS별 설정 분리, 민감 정보 제외, install 스크립트 작성, README 복구 순서 기록이 필요하다는 것을 알게 됐습니다.
Dotfiles를 정리한 뒤 가장 큰 변화는 새 PC 세팅 시간이었습니다. 기존에는 2시간 20분 걸리던 작업이 38분으로 줄었습니다. 이 정도만으로도 저장소를 만든 의미는 충분했습니다. 다만 핵심은 화려한 프롬프트가 아니라, 문제가 생겼을 때 같은 환경을 다시 만들 수 있는 기록이었습니다.
Dotfiles 저장소를 만들기 전 반드시 제외해야 할 항목 체크리스트
- SSH 개인키 파일이 저장소에 포함되어 있지 않은가?
- API 토큰, 접근 키, 인증 문자열이 설정 파일에 남아 있지 않은가?
- 회사 내부 서버 주소나 비공개 저장소 경로가 포함되어 있지 않은가?
- 개인 이메일과 사용자 이름을 공통 설정에 그대로 넣지 않았는가?
- 특정 PC 사용자명에 묶인 절대경로가 들어 있지 않은가?
- 프로젝트별 임시 PATH를 공통 설정에 넣고 있지 않은가?
.env파일 대신.env.example만 올렸는가?- Git credential 관련 파일을 제외했는가?
- 브라우저 토큰이나 세션 파일이 섞여 있지 않은가?
- install 스크립트가 민감 정보를 출력하거나 저장하지 않는가?
- Windows, WSL, Git Bash 설정을 한 파일에 섞지 않았는가?
- 복구 순서를 README에 기록했는가?
Dotfiles를 만들면서 가장 크게 배운 점은 설정도 설명할 수 있어야 유지할 수 있다는 것이었습니다. 왜 이 alias가 필요한지, 왜 이 PATH가 들어가는지, 어떤 파일은 왜 제외해야 하는지 모르면 저장소는 금방 복잡해집니다. 지금은 터미널을 예쁘게 꾸미는 것보다, 6개월 뒤 다른 PC에서도 같은 환경을 다시 만들 수 있는지를 더 중요하게 보고 있습니다.