프론트엔드 개발자를 위한 맥북 초기 세팅

시작하며

프론트엔드 개발자의 맥북 초기 세팅과 기본 설치 프로그램을 정리한 글입니다.
설치 방법 자체보다는, 왜 이 방법을 선택했는지를 중심으로 정리했습니다.

Homebrew

macOS에서 개발 환경을 구성할 때 Homebrew는 사실상 표준입니다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Homebrew를 사용하면 다음과 같은 이점이 있습니다.

• 필요한 개발 도구를 한 곳에서 관리 가능
• 새 맥북에서도 동일한 환경을 빠르게 구성 가능
• 업데이트 및 제거가 간단함

이후 설치하는 대부분의 개발 도구는 가능한 한 Homebrew를 통해 관리합니다.

Node.js 버전 관리 (nvm)

프로젝트를 진행하다 보면 불가피하게 여러 프로젝트가 서로 다른 개발 환경을 가지는 상황이 발생합니다. 이런 상황에서 “내 컴퓨터에 맞춰서 어떻게든 되게 만드는 것”이 아니라, 환경 차이에 쉽게 대응할 수 있는 방법을 선택하는 것이 맞다고 생각합니다.

Node.js를 직접 설치해서 사용하는 방법도 있습니다.
하지만 이 방식은 다음과 같은 문제를 바로 만들어냅니다.

• 프로젝트 간 Node 버전 충돌
• 버전 변경 시 기존 프로젝트 깨짐
• 환경 재현이 어려움

그래서 Node.js는 직접 설치하지 않고, nvm을 통해 버전 관리하는 것이 사실상 필수라고 생각합니다.

이를 위해 사용하는 도구가 nvm(Node Version Manager) 입니다.

nvm 설치

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

프로젝트 단위로 Node 버전 관리

Node 버전 관리는 개인 환경에만 맡겨두지 않고, 프로젝트 자체에 명시되어야 한다고 생각합니다.

그래서 각 프로젝트에는 .nvmrc 파일과 package.json의 engines.node를 함께 관리합니다.

이렇게 하면 새로운 개발자가 합류하거나, 다른 환경에서 작업하더라도 동일한 기준을 유지할 수 있습니다.

Java 버전 관리 (jenv)

프론트엔드 개발 환경에서도 Java가 필요한 상황은 생각보다 자주 발생합니다.

특히 다음과 같은 경우에는 Java 개발 환경이 필수가 됩니다.

• React Native(Android) 프로젝트
• Android 빌드 및 테스트
• Gradle 기반 툴 체인 사용

Java 역시 Node.js와 마찬가지로 직접 설치해서 전역으로 관리하면 금방 문제가 생깁니다.

• 프로젝트마다 요구하는 JDK 버전이 다름
• Android Gradle Plugin 버전에 따라 JDK 요구사항이 바뀜
• 최신 Java 설치 후 기존 프로젝트 빌드 실패

특히 React Native 프로젝트를 여러 개 동시에 진행할 경우, 이 문제를 거의 반드시 한 번 이상 겪게 됩니다.

그래서 Java 역시 직접 설치해서 쓰기보다는, 버전 관리 도구를 사용하는 것이 필수라고 생각합니다.

jenv를 사용하는 이유

이를 위해 사용하는 도구가 jenv입니다.

jenv를 사용하면 다음과 같은 점이 명확해집니다.

• 프로젝트마다 사용할 JDK 버전을 고정 가능
• 전역 Java 환경 오염 방지
• React Native / Android 빌드 환경 재현 가능

Node.js에서 nvm을 사용하는 것과 동일한 이유로, Java 역시 jenv를 통해 관리하는 것이 가장 안정적이었습니다.

jenv 설치

jenv는 Homebrew를 통해 설치합니다.

brew install jenv

설치 후, 쉘 설정 파일에 다음 내용을 추가합니다.

export PATH="$HOME/.jenv/bin:$PATH"
eval "$(jenv init -)"

설치 적용후 zshrc를 1회 실행해줍니다.

source ~/.zshrc

Java 버전 2개 설치 (JDK 11, JDK 17)

자바는 Homebrew Cask로 설치합니다.

brew install --cask temurin@11
brew install --cask temurin@17

아래 명령어로 jenv에 자바 버전을 등록합니다.

jenv add /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
jenv add /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home

프로젝트 단위로 Java 버전 고정

프로젝트 루트에서 사용할 Java 버전을 지정합니다.

# 예: 레거시 프로젝트
jenv local 11.0

# 예: 최신 React Native / Android 프로젝트
jenv local 17.0

이렇게 설정하면 해당 프로젝트 디렉토리에는 .java-version 파일이 생성되고, 다른 프로젝트로 이동했을 때 자동으로 Java 버전이 전환됩니다.

오른쪽 Command 키를 한/영 키로 전환

왜 Caps Lock 대신 오른쪽 Command인가

macOS의 기본 Caps Lock 키는 두 가지 역할을 동시에 수행합니다.

• 키를 짧게 눌렀다 뗐을 때 → 한/영 전환
• 키를 길게 눌렀다 뗐을 때 → Caps Lock

이 두 동작을 구분하기 위해 macOS는 내부적으로 입력 지연(delay) 을 두고 판단합니다. 이 구조 때문에 빠르게 타이핑하면서 한/영 전환을 시도하면 전환이 누락되거나 의도와 다르게 동작하는 경우가 종종 발생합니다.

특히 코드 작성 중에는 영문 입력과 한글 입력을 짧은 간격으로 반복하게 되는데, 이때 한/영 전환이 정확히 동작하지 않으면 타이핑 흐름이 깨지기 쉽습니다.

그래서 저는 Caps Lock 대신 오른쪽 Command 키를 한/영 전환 키로 사용합니다.

왜 hidutil을 사용했는가

한/영 키를 바꾸는 가장 흔한 방법 중 하나는 Karabiner 같은 키 매핑 앱을 사용하는 것입니다.

저 역시 처음에는 Karabiner를 사용했지만, 사용 중 간헐적으로 한/영 전환이 되지 않는 현상을 경험했습니다.

원인을 파악해보니, 키 입력이 실제로 화면에 문자로 입력되기까지는 대략 다음과 같은 단계를 거칩니다.

1. 물리 키보드 입력
2. HID(Human Interface Device) 레벨
3. 입력 소스 / 키보드 레이아웃
4. 애플리케이션
5. 텍스트 입력

hidutil은 이 중 2번, HID 레벨 바로 다음 단계에서 동작합니다.

즉, 아직 어떤 애플리케이션이 실행 중인지도 모르고, 한글 입력인지 영문 입력인지도 결정되기 전 상태에서 키를 다른 키로 바꿔버리는 방식입니다.

이 방식 덕분에 다음과 같은 특징을 가집니다.

• 특정 애플리케이션에 의존하지 않음
• 입력 소스(한글/영문)와 무관하게 동일하게 동작
• sleep / wake 이후에도 비교적 안정적으로 유지됨

한/영 전환처럼 입력 타이밍이 중요한 키 설정에는 hidutil이 더 적합하다고 판단했습니다.

hidutil로 오른쪽 Command 키를 한/영 키로 설정하기

hidutil은 macOS에 기본으로 포함된 도구로, 별도의 설치 없이 바로 사용할 수 있습니다.

hidutil로 설정한 키 매핑은 기본적으로 재부팅 후 초기화되며 로그인 시 자동으로 다시 적용되도록 LaunchAgent를 설정합니다.

# LaunchAgents 디렉토리 생성
mkdir -p ~/Library/LaunchAgents
 
# 설정 파일 생성
touch ~/Library/LaunchAgents/local.hidutilKeyMapping.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>local.hidutilKeyMapping</string>
 
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/hidutil</string>
    <string>property</string>
    <string>--set</string>
    <string>{
      "UserKeyMapping": [
        {
          "HIDKeyboardModifierMappingSrc": 0x7000000E7,
          "HIDKeyboardModifierMappingDst": 0x70000006D
        }
      ]
    }</string>
  </array>
 
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

# 문법 검사
plutil -lint ~/Library/LaunchAgents/local.hidutilKeyMapping.plist
 
# LaunchAgent 등록 및 실행
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/local.hidutilKeyMapping.plist
launchctl kickstart -k gui/$(id -u)/local.hidutilKeyMapping

정상적으로 등록되었는지는 다음 명령으로 확인할 수 있습니다.

launchctl list | grep hidutil

이렇게 매핑한 뒤, 시스템 설정 → 키보드 → 키보드 단축키 → 입력 소스에서 F18 키를 한/영 전환 키로 지정하면 됩니다.

원화(₩) 키를 백틱(`)으로 전환

맥북에서 한글 입력 모드일 때 키보드의 백틱(`) 위치에 해당하는 키를 누르면 원화(₩) 문자가 입력됩니다.

하지만 실제 개발 과정에서는 원화 문자를 사용할 일은 거의 없고,

• Markdown 코드 블록
• JavaScript 템플릿 문자열
• 쉘 명령어

등에서 백틱(`) 을 훨씬 더 자주 사용하게 됩니다.

그래서 해당 키를 원화 대신 백틱(`) 으로 사용하도록 설정했습니다.

선택한 방법

원화 키를 백틱으로 바꾸는 방법은 여러 가지가 있지만, 이 글에서는 DefaultKeyBinding.dict를 사용했습니다.

이 방식은 macOS의 기본 텍스트 입력 시스템(Cocoa) 을 사용하는 영역에서 입력 문자를 치환하는 방식입니다.

~/Library/KeyBindings/DefaultKeyBinding.dict
 
{
  "₩" = ("insertText:", "`");
}

이 방법을 사용하는 이유

DefaultKeyBinding.dict 방식은 모든 애플리케이션에서 완벽하게 동일하게 동작하지는 않습니다.

일부 애플리케이션이나 특수 입력 환경에서는 여전히 원화 문자가 입력될 수 있습니다.

하지만 제가 실제로 개발 작업을 하는 VS Code, 코드 편집 영역, Markdown 작성 환경에서는 정상적으로 동작합니다.

모든 환경을 완벽하게 통일하기보다는, 실제 개발에 필요한 영역에서 안정적으로 동작하는 방식을 선택했습니다.

Rectangle

macOS에서 창을 빠르게 정렬할 수 있는 무료 창 배치 소프트웨어입니다.
아래와 같은 단축키를 통해 작업 공간을 효율적으로 구성할 수 있습니다.

• ⌃⌥ ← : 왼쪽 절반
• ⌃⌥ → : 오른쪽 절반
• ⌃⌥ ↵ : 전체 화면
• ⌃⌥⌘ ←/→ : 왼쪽/오른쪽 모니터로 이동

Spectacle의 후속으로, Spectacle은 더 이상 유지보수가 되지 않아 최신 macOS와 호환성에 문제가 있습니다.
Rectangle은 오픈소스로 지속적으로 업데이트되고 있으며, 사용자 설정도 지원합니다.

• 다운로드: https://rectangleapp.com
• Homebrew: brew install --cask rectangle