MacBook으로 개발 환경 세팅 1년 — 윈도우와 진짜 다른 점
MacBook으로 개발 환경 세팅 1년 —
윈도우와 진짜 다른 점
Windows에서 3년, MacBook M2 Pro로 넘어와서 1년. "유닉스 기반이라 개발이 편하다"는 말이 맞는지 틀린지, 직접 겪으며 기록했다. 좋은 것만 쓰지 않는다.
Windows에서 Next.js 개발을 3년 했다. WSL2, PowerShell, Git Bash를 번갈아 쓰면서 "이게 맞나?" 싶은 순간들이 쌓였다. MacBook M2 Pro로 갈아타고 1년이 지났다. "맥은 개발 환경이 좋다"는 말이 진짜인지, 과장인지, 지금 기억할 수 있는 것들을 다 기록한다.
좋은 것만 쓰지 않는다. 어려웠던 것, 예상과 달랐던 것, 아직도 Windows가 나은 부분도 같이 쓴다.
Windows 개발 경험
실사용 기간
12코어 CPU
스택 기준
내 개발 스택 — 비교의 기준
이 글의 비교는 내 스택 기준이다. 다른 스택(Python ML, iOS 네이티브, Java 등)은 경험이 없으니 그쪽에 대한 이야기는 하지 않는다.
첫날 세팅 — Windows와 가장 다른 출발점
MacBook을 처음 켜고 개발 환경을 세팅하는 데 걸린 시간은 약 2시간 반이었다. Windows에서 WSL2 세팅에 반나절을 쓰던 경험과 비교하면 체감이 달랐다. 가장 큰 이유는 Homebrew다.
macOS에서 Homebrew는 Node.js, Git, Python, Docker 등 거의 모든 개발 도구를 brew install 한 줄로 설치한다. Windows의 winget이 비슷한 역할을 하지만 패키지 수와 안정성에서 아직 차이가 있다. 새 MacBook을 받으면 Brewfile 하나로 전체 환경을 복원할 수 있는 것이 1년 후 가장 만족하는 부분이다.
Mac vs Windows — 개발 환경 항목별 비교
ls, grep, sed, awk — 모두 별도 설치 없이 작동한다.npm install이 Windows보다 빠른 경우가 많다 — 특히 native addon이 포함된 패키지는 차이가 명확하다. node_modules 생성 시 심볼릭 링크 처리가 Windows보다 안정적이다. node-gyp 관련 오류를 Mac에서 한 번도 못 봤다.MAX_PATH)이 node_modules 중첩에서 오류를 만들기도 했다. nvm-windows는 nvm(Mac/Linux용)과 사용법이 약간 다르다.--platform linux/amd64 플래그가 종종 필요하다..env 파일이 Unix 경로로 일관되게 동작한다. export로 쉘 환경 변수 설정이 직관적이다. macOS Keychain에 민감한 값을 저장하는 방법도 있지만 복잡해서 그냥 .env를 쓴다.초기 세팅 순서 — 실제로 진행한 방법
Homebrew 설치 후 brew install git node nvm pnpm wget curl gh. GitHub CLI(gh)도 이 때 같이 설치했다. Windows에서 각각 개별 설치하던 것이 한 줄로 끝났다.
brew install --cask iterm2 후 Oh My Zsh 설치. zsh-autosuggestions, zsh-syntax-highlighting, git 플러그인 추가. Powerlevel10k 테마 적용. 이후 터미널 자동완성과 컬러링이 작업 속도를 올렸다.
ssh-keygen -t ed25519로 키 생성, ssh-add --apple-use-keychain으로 Keychain 등록. gh auth login으로 GitHub CLI 인증 완료. 이후 SSH 비밀번호를 다시 입력한 적이 없다.
Settings Sync로 이전 VS Code 설정을 그대로 가져왔다. 확장 프로그램, 키바인딩, 스니펫까지 복원됐다. code . 명령어로 터미널에서 직접 VS Code를 열 수 있게 PATH 설정.
nvm install 20으로 Node LTS 설치. .nvmrc 파일이 있는 프로젝트는 nvm use로 자동 전환. 프로젝트 클론 후 pnpm install — Windows 대비 native addon 오류 없이 한 번에 완료됐다.
Finder에서 숨김 파일 표시(Cmd+Shift+.), 키 반복 속도 최대화(defaults write), Dock 자동 숨기기. 개발 작업에 방해되는 알림 정리. 총 세팅 시간 2시간 반이었다.
실제 쓰는 터미널 명령 — 1년 후 자주 쓰는 것들
예상과 달랐던 것들 — 솔직하게
구형 npm 패키지 중 ARM64 바이너리를 제공하지 않는 것들이 있었다. node-canvas, 일부 이미지 처리 라이브러리가 문제를 일으켰다. --platform linux/amd64로 Docker 이미지를 Rosetta로 돌리거나, arch -x86_64로 명령어를 실행하는 우회책을 쓰기도 했다. 2024년 기준으로는 대부분 해결됐지만, 도입 초기(2023)에는 실제 작업 시간을 잡아먹었다.
macOS 기본 파일 시스템은 대소문자를 구분하지 않지만(case-insensitive) Linux 서버는 구분한다. import Button from './button'이 macOS에서는 되고 Vercel 배포 후 Cannot find module './Button' 오류가 났다. 이 문제로 배포 실패를 두 번 겪었다. 파일명 대소문자를 처음부터 일관되게 쓰는 습관이 필수다.
Steam 게임 상당수가 macOS를 지원하지 않는다. 지원하더라도 Windows 대비 성능이 낮다. 퇴근 후 PC 게임을 MacBook으로 하는 건 포기했다. MacBook은 개발 기기다 — 이걸 처음부터 명확히 하면 실망이 없다. 게임 겸용이 필요하면 Windows 데스크탑을 별도로 두는 게 현실적이다.
Cmd+Shift+4로 범위 선택 스크린샷, Cmd+Shift+5로 녹화. 기본 도구만으로 PR용 스크린샷, 버그 리포트 녹화를 빠르게 만들었다. Windows의 Snipping Tool이나 Xbox Game Bar보다 훨씬 직관적이었다. 프론트엔드 작업에서 결과물을 자주 공유해야 하는 상황에서 이 차이가 매일 느껴졌다.
프론트엔드 개발 도구 — Mac vs Windows 호환성 요약
| 도구 / 환경 | Mac (M2) | Windows | 비고 |
|---|---|---|---|
| Node.js / npm | ◎ 완벽 | △ native addon 주의 | node-gyp 오류 Mac에서 0회 |
| pnpm / yarn | ◎ 완벽 | ○ 양호 | 실질 차이 없음 |
| Docker | △ ARM 이미지 주의 | ○ x86 호환성 높음 | 레거시 이미지는 Windows 유리 |
| Git | ◎ 완벽 | ○ Git Bash로 해결 | LF/CRLF 주의 필요 |
| VS Code | ◎ 완벽 | ◎ 완벽 | 플랫폼 차이 없음 |
| Xcode 시뮬레이터 | ◎ Mac 전용 | ✗ 불가 | iOS Safari 테스트 필수 도구 |
| 터미널 (Zsh) | ◎ 기본 제공 | △ WSL2 필요 | Mac이 압도적으로 편함 |
| Homebrew | ◎ 완벽 | △ winget으로 일부 대체 | Homebrew 생태계가 더 풍부 |
| Figma 데스크탑 | ◎ 완벽 | ◎ 완벽 | 차이 없음 |
| Prisma / Supabase CLI | ◎ 완벽 | △ WSL2 권장 | Windows 직접 실행 시 간헐적 오류 |
| 스크린샷·녹화 | ◎ 기본 도구 탁월 | △ 서드파티 권장 | Mac 기본 캡처 도구가 훨씬 편함 |
| 배터리 (코딩 중) | ◎ 10–12시간 | ✗ 4–5시간 | 가장 큰 실용적 차이 |
항목별 개발 환경 만족도 — 1년 기준
"MacBook이 좋은 이유는 유닉스 기반이 아니다. 유닉스 기반 위에 쌓인 생태계와 통합이 자연스럽기 때문이다."
— 1년 후 macOS 개발 환경 회고, Obsidian 메모1년 후 솔직한 결론
웹 프론트엔드 개발자에게 MacBook은 확실히 좋은 선택이다. 터미널, Node 생태계, 배터리, iOS 테스트 환경 — 이 네 가지만으로도 전환 비용을 정당화할 수 있었다. 특히 배터리는 숫자로 보이는 생산성 차이였다.
다만 만능은 아니다. Docker 레거시 이미지, 파일 시스템 대소문자 함정, ARM64 초기 호환성 이슈 — 이 세 가지는 실제로 작업 시간을 잡아먹었다. 알고 시작하면 피할 수 있는 것들이라 이 글이 도움이 됐으면 한다.
Brewfile로 환경 스냅샷 관리 — Mac 세팅의 진짜 킬러 기능.
파일 시스템 대소문자·ARM 호환성 — 알고 시작해야 할 함정들.
Docker 레거시 이미지 — 이 영역만큼은 Windows WSL2가 유리하다.
Mac이나 Windows에서 개발 환경 세팅하면서 겪은 이슈 있으신가요?
특히 ARM64 호환성 이슈, WSL2 vs Mac 터미널 비교 경험, 아니면 "Mac으로 와서 이게 제일 좋았다"는 이야기 모두 댓글로 알려주세요. 비슷한 스택 쓰시는 분들의 경험이 특히 궁금합니다.