병렬 에이전트 코딩, 이렇게 세팅합니다

이전 뉴스레터에서 프롬프트 기법이나 Plan Mode, CLAUDE.md 같은 이야기를 많이 했는데요. 근데 솔직히 그것만으로는 부족하더라고요. 아무리 프롬프트를 잘 짜도, 워크트리 전환이 번거롭거나 세션 관리가 안 되면 결국 한 번에 하나씩 하게 되거든요. 병렬로 에이전트를 돌리려면 환경 자체가 그걸 지원해야 해요.

그래서 오늘은 평소에 잘 안 하던 걸 해보려고 해요. 제 개발 환경 세팅을 전부 공유합니다. 정답이 아니에요. 저한테 맞는 세팅일 뿐이에요. 근데 이 세팅을 만들면서 고민했던 것들이 여러분한테도 참고가 될 수 있을 것 같아서요.

터미널 개발 환경

왜 환경 세팅을 공유하는 건가

이전 뉴스레터에서 Boris Cherny의 "워크트리 3~5개를 동시에 돌려라"도 다뤘고, Compound Engineering의 "시스템을 만들어라"도 다뤘잖아요. 근데 댓글이나 피드백을 보면 공통적인 질문이 하나 있었어요.

"구체적으로 어떻게 세팅해요?"

원리는 알겠는데 실제로 터미널을 어떻게 구성하는지, 워크트리를 어떻게 관리하는지, 에이전트를 어떻게 띄우는지가 막막하다는 거예요. 그래서 오늘은 원리가 아니라 실제 세팅을 보여드리려고 합니다. 제 dotfiles를 GitHub에 공개해뒀거든요. 이 글에서 핵심만 뽑아서 설명할게요.

한 가지 먼저 말씀드리면요. 저는 VSCode나 Cursor 같은 GUI 에디터를 안 써요. 터미널에서 전부 해요. "터미널이 답이다"라고 주장하는 건 아니에요. GUI 에디터를 쓰더라도 오늘 공유하는 개념들 — 세션 격리, 워크트리 관리, 에이전트 자동 실행 — 은 동일하게 적용할 수 있어요. 도구보다 구조가 중요한 거예요.

제 개발 환경은 창이 세 개입니다

복잡해 보일 수 있는데, 구조는 단순해요. 하나의 프로젝트 세션에 창 세 개예요.

창	도구	역할
1번 창: code	OpenCode (AI 에이전트 TUI)	코드가 만들어지는 곳
2번 창: git	lazygit (Git TUI)	변경 사항을 보고 검증하는 곳
3번 창: term	일반 터미널	빌드, 테스트, 디버깅하는 곳

끝이에요. 에디터가 없어요. Neovim이 설치되어 있긴 한데, 파일을 빠르게 확인할 때 가끔 쓰는 정도예요. 주력이 아니에요.

왜 이렇게 됐냐면요. AI 에이전트가 코드를 짜는 시대에 에디터의 역할이 바뀌었다고 느꼈거든요. 예전에는 에디터가 "코드를 치는 도구"였잖아요. 근데 지금은 코드를 치는 건 에이전트가 해요. 사람이 하는 건 계획, 지시, 검증이에요. 그러면 필요한 도구가 달라져요.

계획과 지시 → AI 에이전트 (OpenCode)
검증 → Git diff를 보여주는 도구 (lazygit)
실행 → 빌드하고 테스트하는 터미널

이 세 가지가 있으면 충분해요. 에디터에서 코드를 직접 치는 일이 거의 없으니까요.

dev — 이 세 개를 한 방에 띄우는 스크립트

매번 터미널을 열고, tmux 세션을 만들고, OpenCode를 실행하고, lazygit을 띄우는 걸 반복하기 싫었어요. 그래서 dev라는 스크립트를 만들었어요. 프로젝트 폴더에서 dev를 치면 끝이에요.

# 프로젝트 폴더에서
dev

이거 하나 치면 tmux 세션이 생기면서 3개 창이 자동으로 뜹니다:

# dev 스크립트의 핵심 부분
tmux new-session -d -s "$TMUX_SESSION" -n "code" -c "$TARGET_PATH"
tmux send-keys -t "$TMUX_SESSION:code" "opencode" Enter

tmux new-window -t "$TMUX_SESSION" -n "git" -c "$TARGET_PATH"
tmux send-keys -t "$TMUX_SESSION:git" "lazygit" Enter

tmux new-window -t "$TMUX_SESSION" -n "term" -c "$TARGET_PATH"

1번 창에 OpenCode가 자동 실행되고, 2번 창에 lazygit이 뜨고, 3번 창은 빈 터미널이에요. Cmd+1, Cmd+2, Cmd+3으로 창을 전환하면서 작업해요. 브라우저 탭 전환하듯이요.

진짜 힘은 워크트리 연동에서 나옵니다

근데 dev의 진짜 가치는 여기서부터예요. 이름을 붙여서 실행하면 Git Worktree가 자동으로 생성됩니다.

# 워크트리 + 세션 자동 생성
dev feature-auth
dev bugfix-login
dev experiment-ui

이러면 각각 독립된 워크트리가 만들어지고, 거기에 맞는 tmux 세션이 뜨면서 OpenCode와 lazygit이 자동 실행돼요. 완전히 격리된 환경이에요. 브랜치도 자동 생성이에요.

이전 뉴스레터에서 Boris Cherny가 "워크트리를 동시에 돌리고, 각각 별도의 에이전트를 병렬로 운영하라"고 했잖아요. 그리고 Compound Engineering에서 "Git Worktree로 격리 환경을 만들어라"고 했고요. dev 스크립트는 그 개념을 커맨드 하나로 자동화한 거예요.

이게 왜 중요하냐면요. 워크트리를 수동으로 만들면 이런 과정을 거쳐야 해요:

# 수동으로 하면 이만큼 쳐야 해요
mkdir -p ../.worktrees/myapp
git worktree add ../.worktrees/myapp/feature-auth -b feature-auth
cd ../.worktrees/myapp/feature-auth
tmux new-session -d -s dev_feature-auth
# ... OpenCode 실행, lazygit 실행, 창 전환 ...

dev feature-auth 한 줄이면 이 전부가 끝나요. 그리고 작업이 끝나면:

# 세션 정리 (tmux + 워크트리 + 브랜치 한 번에 삭제)
dev -c feature-auth

# 전부 정리
dev -c --all

# tmux가 죽은 고아 워크트리만 정리
dev -c --orphans

dev -l을 치면 현재 레포의 모든 세션 상태를 볼 수 있어요:

Sessions for myapp:

  * feature-auth  [feature-auth]  3 windows
  * bugfix-login  [bugfix-login]  3 windows
  - experiment-ui [experiment-ui] (no tmux)

별표(*)가 붙은 건 tmux가 살아있는 세션이고, -는 워크트리는 있지만 tmux가 없는 거예요.

세션이 이미 있으면?

이미 존재하는 세션에 dev를 치면 fzf로 선택지가 뜹니다:

Action:
> attach    ← 기존 세션에 다시 붙기
  restart   ← 세션을 끄고 다시 시작
  stop      ← 세션 + 워크트리 + 브랜치 전부 정리

이런 식으로 세션의 생성부터 전환, 정리까지 dev 하나로 전부 돼요. 병렬 에이전트 코딩에서 세션 관리의 마찰을 없애는 게 핵심이에요. 워크트리를 만드는 게 귀찮으면 결국 하나의 브랜치에서 순차적으로 작업하게 되거든요.

코딩 워크스페이스

터미널 세팅 — 사소하지만 체감 큰 것들

dev 스크립트가 잘 돌아가려면 밑바탕이 되는 터미널 세팅이 중요해요. 하나하나는 사소한데, 조합되면 체감이 커요.

Ghostty — Cmd+숫자로 창 전환

터미널은 Ghostty를 써요. 이전 뉴스레터에서 다뤘던 Mitchell Hashimoto가 만든 터미널이에요. 왜 Ghostty를 쓰냐면, 빠르고 가볍고, 키바인딩 커스터마이징이 자유로워서예요.

가장 중요한 세팅이 이거예요:

# ghostty/config
# Cmd+1~9로 tmux 윈도우 전환 (브라우저 탭처럼)
keybind = super+digit_1=text:\x01\x31
keybind = super+digit_2=text:\x01\x32
keybind = super+digit_3=text:\x01\x33

Cmd+1을 누르면 Ghostty가 tmux한테 Ctrl+A, 1 시퀀스를 보내요. 그러면 tmux가 1번 창(OpenCode)으로 전환돼요. Cmd+2는 lazygit, Cmd+3은 터미널. 브라우저에서 탭 전환하듯이 창을 넘나들 수 있어요.

이거 안 하면 매번 Ctrl+A 누르고 숫자를 누르는 2타가 필요한데, Cmd+숫자 1타면 끝이에요. 하루에 수백 번 전환하니까 체감이 커요.

# Cmd+N으로 새 tmux 윈도우 생성
keybind = super+n=text:\x01c

Cmd+N은 새 tmux 창을 만들어요. 3번 창 외에 추가 터미널이 필요할 때 쓰고요.

tmux — 세션이 죽지 않습니다

tmux 설정에서 핵심은 두 가지예요.

첫째, Prefix를 Ctrl+A로 바꿨어요.

# tmux/.tmux.conf
unbind C-b
set -g prefix C-a
bind C-a send-prefix

기본값인 Ctrl+B는 손이 불편하거든요. Ctrl+A가 훨씬 자연스러워요.

둘째, 세션 자동 저장/복구예요.

# tmux-resurrect + tmux-continuum
set -g @resurrect-capture-pane-contents 'on'
set -g @resurrect-strategy-nvim 'session'
set -g @continuum-restore 'on'
set -g @continuum-save-interval '15'  # 15분마다 자동 저장

15분마다 모든 tmux 세션이 자동 저장돼요. 컴퓨터가 꺼지거나 터미널이 죽어도, 다시 tmux를 열면 세션이 그대로 복구돼요. 병렬로 워크트리 세션 여러 개를 띄워놓고 작업하는데, 이게 날아가면 큰일이잖아요. 이 세팅 덕분에 안심하고 여러 세션을 열어둘 수 있어요.

Starship — 프롬프트는 최소한으로

프롬프트 세팅이 좀 특이해요. 보통 프롬프트에 Git 상태라든가 언어 버전이라든가 온갖 정보를 넣잖아요. 저는 딱 두 개만 보여요.

# starship/starship.toml
format = "$directory $git_branch "

[git_status]
disabled = true

[time]
disabled = true

디렉토리 경로랑 Git 브랜치. 끝이에요. Git status(더티 파일이 몇 개인지, 스테이징된 게 있는지)는 안 보여요. 왜냐면 lazygit에서 보거든요. 프롬프트에서까지 보여줄 필요가 없어요. 프롬프트가 길어지면 터미널이 복잡해지고, 복잡해지면 피로해져요.

그리고 이 세팅이 있어요:

[directory.substitutions]
"~/workspaces/" = ""

~/workspaces/myapp/src 대신 myapp/src만 보여요. 어차피 모든 프로젝트가 ~/workspaces/ 아래에 있으니까, 접두사를 빼버린 거예요. 프롬프트가 짧아지니까 한눈에 어디인지 파악이 돼요.

fzf — 모든 곳에 퍼지 파인더

fzf는 "터미널의 검색 엔진"이에요. 이 도구가 제 세팅 전반에 걸쳐서 쓰여요.

셸 히스토리 검색: Ctrl+R 누르면 fzf로 이전 명령어를 퍼지 검색
탭 완성: cd를 치고 Tab을 누르면 fzf-tab이 디렉토리 목록을 fzf 팝업으로 보여줌
dev 스크립트: 기존 세션에서 dev를 치면 fzf로 attach/restart/stop 선택
tmux 세션 전환: Alt+S를 누르면 세션 목록이 트리 형태로 뜸

통일감이 있어요. 어디서든 퍼지 검색이 되니까 정확한 이름을 기억할 필요가 없어요. 대충 몇 글자만 치면 찾아져요.

그리고 fzf 테마를 Dracula로 맞춰놨어요:

# zsh/.zshrc
export FZF_DEFAULT_OPTS="
  --height=40%
  --layout=reverse
  --border
  --color=fg:#f8f8f2,bg:#282a36,hl:#bd93f9
  --color=fg+:#f8f8f2,bg+:#44475a,hl+:#bd93f9
  --color=info:#ffb86c,prompt:#50fa7b,pointer:#ff79c6
  --color=marker:#ff79c6,spinner:#ffb86c,header:#6272a4
"

Ghostty, tmux, fzf, git-delta가 전부 Dracula 계열이에요. 이건 취향이긴 한데, 시각적 통일감이 피로를 줄여줘요. 창을 전환해도 색감이 일관되니까 눈이 적응할 필요가 없어요.

git-delta — diff를 제대로 보는 법

Git diff를 볼 때 기본 diff는 솔직히 보기 불편하잖아요. git-delta를 쓰면 side-by-side로 변경사항을 한눈에 볼 수 있어요.

# git/.gitconfig
[core]
    pager = delta

[delta]
    navigate = true
    line-numbers = true
    side-by-side = true
    syntax-theme = Dracula

lazygit에서 에이전트가 바꾼 코드를 리뷰할 때, side-by-side diff가 있으면 "뭐가 바뀌었는지"가 바로 보여요. 에이전트 코딩에서 검증의 효율이 올라가요.

AI 에이전트 세팅

OpenCode 설정에서 중요한 게 몇 가지 있어요.

질문하지 마, 그냥 해

{
  "permission": {
    "question": "deny"
  }
}

이 한 줄이 핵심이에요. 보통 AI 에이전트가 "이 파일을 수정해도 될까요?" "이 명령어를 실행해도 될까요?" 하면서 물어보잖아요. 이걸 전부 자동 승인으로 바꾼 거예요.

왜냐면요. 병렬로 세션을 여러 개 띄워놓고 작업하는데, 하나하나 승인하러 다니면 병렬의 의미가 없거든요. 에이전트한테 계획을 주고 실행을 맡겼으면, 실행은 에이전트가 알아서 하게 두는 거예요. 검증은 lazygit에서 결과를 보고 하면 돼요.

이건 이전 뉴스레터에서 다뤘던 개발자 성장 5단계 중 "Stage 3: 계획 우선, PR 리뷰"와 맥이 같아요. 라인별로 감시하지 말고, 결과를 PR 수준에서 리뷰하라는 거잖아요. 에이전트한테 질문 권한을 빼는 건 그 철학을 세팅으로 구현한 거예요.

물론 주의할 점이 있어요. 이건 워크트리로 격리된 환경에서만 안전해요. 메인 브랜치에서 이렇게 하면 위험해요. dev feature-auth로 격리된 워크트리를 만들고, 거기서 에이전트를 자유롭게 돌리고, 결과를 lazygit에서 검증하고 나서야 메인에 머지하는 거예요. 격리가 먼저, 자율이 그 다음이에요.

LSP 린터를 꺼놨습니다

{
  "lsp": {
    "eslint": { "disabled": true },
    "oxlint": { "disabled": true }
  }
}

이것도 의도적이에요. 에이전트가 코드를 짜는 중간에 린터가 끼어들면 에이전트의 흐름이 끊기거든요. 린팅은 에이전트가 작업을 끝내고 나서, 3번 창(터미널)에서 따로 돌려요. 작성과 검증을 분리하는 거예요.

MCP 서버 — 에이전트가 외부 도구를 직접 쓰게

OpenCode에 MCP 서버를 연결해놨어요. 예를 들어 ClickHouse MCP를 연결하면, 에이전트한테 "이번 주 DAU 추이를 봐줘"라고 하면 에이전트가 직접 DB에 쿼리를 날려요. 이전 뉴스레터에서 Boris Cherny가 "6개월째 SQL을 직접 안 쓴다"고 했는데, 같은 원리예요.

{
  "mcp": {
    "clickhouse": {
      "type": "local",
      "command": ["uv", "run", "--with", 
        "git+https://github.com/ClickHouse/mcp-clickhouse.git",
        "--python", "3.10", "mcp-clickhouse"],
      "environment": {
        "CLICKHOUSE_HOST": "...",
        "CLICKHOUSE_USER": "readonly_full"
      }
    }
  }
}

readonly_full이라는 유저명에 주목해 주세요. 읽기 전용 계정이에요. 에이전트한테 자율을 주되, 데이터를 변경할 수는 없게 제한한 거예요. 자율과 안전 사이의 균형이에요.

한 줄이면 전부 세팅됩니다

이 세팅을 처음부터 다시 해야 한다면 얼마나 걸릴까요. 한 줄이면 돼요.

git clone https://github.com/effy-coding/dotfiles && cd dotfiles && ./install.sh

install.sh가 하는 일을 순서대로 보면:

1. Homebrew 설치 (없으면)
2. Brewfile로 패키지 일괄 설치 (Ghostty, tmux, lazygit, fzf, ripgrep, eza...)
3. fzf-tab 설치
4. LazyVim 세팅
5. 심볼릭 링크 생성 (zsh, git, ghostty, starship, tmux, nvim, opencode 설정 파일들)
6. fzf 키바인딩 설정
7. mise로 런타임 설치 (Node.js, Bun)
8. bun 글로벌 패키지 설치
9. dev 스크립트를 ~/.local/bin에 설치
10. macOS 시스템 설정 적용 (키보드 반복 속도, Dock, Finder 등)

새 맥북을 사면 이것만 돌리면 끝이에요. 10분이면 제 개발 환경이 그대로 복원돼요.

이게 왜 중요하냐면요. 환경을 코드로 관리할 수 있다는 거예요. 이전 뉴스레터에서 "CLAUDE.md에 규칙을 축적하라"고 했잖아요. dotfiles도 같은 원리예요. 개발 환경의 모든 설정을 코드로 관리하면, 버전 관리도 되고 공유도 되고 복원도 돼요. Compound Engineering에서 말한 "시스템이 쓸수록 좋아지게 만들어라"를 개발 환경에 적용한 거예요.

macOS 세팅도 코드입니다

재밌는 부분이 하나 더 있어요. macos.sh에서 macOS 시스템 설정까지 코드로 관리해요.

# 키보드 반복 속도 최대 (코딩할 때 체감 큼)
defaults write NSGlobalDomain KeyRepeat -int 1
defaults write NSGlobalDomain InitialKeyRepeat -int 10

# 길게 누르면 특수문자 뜨는 거 끄기 (키 반복이 되게)
defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool false

# 마우스 가속 끄기 (정밀한 커서 제어)
defaults write .GlobalPreferences com.apple.mouse.scaling -1

키보드 반복 속도를 최대로 올리는 거, 사소해 보이지만 하루 종일 터미널을 쓰면 체감이 커요. 방향키로 이동하거나 백스페이스로 지울 때 속도가 확 달라져요.

에피의 시선 — 왜 이렇게 됐는지

솔직히 처음부터 이런 세팅은 아니었어요.

VSCode를 오래 썼고, Cursor도 써봤어요. 근데 에이전트 코딩을 하면 할수록 에디터의 역할이 줄어드는 걸 느꼈어요. 에디터에서 하는 일이 "AI가 바꾼 파일 열어서 diff 보기"가 대부분이 되더라고요. 그러면 lazygit이 더 빠르거든요. 파일 단위가 아니라 변경 단위로 볼 수 있으니까요.

그리고 병렬 작업을 하려고 하니까 GUI 에디터가 불편해졌어요. VSCode 창을 3개 열면 컨텍스트가 헷갈려요. 어떤 창이 어떤 워크트리인지. tmux 세션은 이름이 붙어있으니까 dev -l만 치면 한눈에 보여요.

근데 한 가지 강조하고 싶은 건요. 이건 저한테 맞는 세팅이에요. Cursor에서 멀티 에이전트를 돌리는 분들도 있고, Windsurf에서 잘 쓰는 분들도 있어요. 도구는 상관없어요.

중요한 건 이 세 가지예요:

세션 격리: 에이전트가 작업하는 환경이 서로 격리되어 있는가
전환 비용 최소화: 세션 간 전환이 Cmd+숫자 하나로 되는가 (또는 그에 준하는 수준인가)
생성/정리 자동화: 새 세션을 만들고 끝나면 정리하는 게 번거롭지 않은가

이 세 가지만 충족되면 GUI든 TUI든 병렬 에이전트 코딩이 가능해요. 제 dev 스크립트는 이 세 가지를 터미널 환경에서 풀어낸 하나의 예시일 뿐이에요.

터미널 환경

오늘 바로 해보세요

전체 세팅을 한 번에 따라 할 필요는 없어요. 단계별로 가세요.

1. Ghostty + tmux에서 Cmd+숫자 키바인딩 세팅 (10분)

Ghostty를 쓰고 있다면, 설정 파일(~/.config/ghostty/config)에 이걸 추가해보세요:

keybind = super+digit_1=text:\x01\x31
keybind = super+digit_2=text:\x01\x32
keybind = super+digit_3=text:\x01\x33

tmux Prefix가 Ctrl+A여야 작동해요. .tmux.conf에 이걸 추가하세요:

unbind C-b
set -g prefix C-a
bind C-a send-prefix

이것만 해도 tmux 창 전환이 브라우저 탭 전환만큼 자연스러워져요.

2. dev 스크립트 핵심만 복붙해서 써보기 (5분)

전체 스크립트가 아니라, 핵심만 가져와서 써보세요:

#!/bin/bash
# 최소 버전: 현재 디렉토리에서 3개 창 tmux 세션 생성
SESSION="dev_$(basename $(pwd) | tr ' ./' '_')"

tmux new-session -d -s "$SESSION" -n "code" -c "$(pwd)"
tmux send-keys -t "$SESSION:code" "opencode" Enter

tmux new-window -t "$SESSION" -n "git" -c "$(pwd)"
tmux send-keys -t "$SESSION:git" "lazygit" Enter

tmux new-window -t "$SESSION" -n "term" -c "$(pwd)"

tmux select-window -t "$SESSION:code"
tmux attach-session -t "$SESSION"

이걸 ~/.local/bin/dev에 저장하고 chmod +x를 주세요. OpenCode 대신 다른 에이전트를 쓴다면 opencode 부분만 바꾸면 돼요. 프로젝트 폴더에서 dev만 치면 바로 개발 환경이 뜹니다.

3. dotfiles 레포 만들기 시작 (30분)

지금 쓰고 있는 .zshrc, .gitconfig, 터미널 설정 파일들을 하나의 Git 레포로 모아보세요:

mkdir ~/dotfiles
cd ~/dotfiles
git init

# 지금 쓰고 있는 설정 파일들을 복사
cp ~/.zshrc zsh/.zshrc
cp ~/.gitconfig git/.gitconfig
# ... 나머지 설정들

git add .
git commit -m "initial dotfiles"

완벽하지 않아도 돼요. 시작이 중요해요. 설정을 바꿀 때마다 커밋하면, 시간이 지나면서 자기만의 개발 환경이 코드로 축적돼요. 이전 뉴스레터에서 "CLAUDE.md가 쓸수록 좋아진다"고 했잖아요. dotfiles도 똑같아요.

마무리

"좋은 도구를 쓰는 것보다, 도구들이 잘 물리게 만드는 게 중요합니다."

에이전트 코딩의 효율은 프롬프트 기법에서만 나오는 게 아니에요. OpenCode가 돌아가는 창, lazygit으로 검증하는 창, 빌드하는 창이 하나의 세션으로 묶여 있고, 그 세션을 워크트리와 함께 필요한 만큼 띄울 수 있고, 한 줄이면 생성되고 한 줄이면 정리되는 환경. 이런 환경의 매끄러움이 프롬프트 기법 못지않게 중요해요.

제 dotfiles를 GitHub에 공개해뒀습니다. 전부 따라 할 필요는 없어요. 필요한 부분만 골라 쓰세요.

여러분의 개발 환경 세팅도 궁금합니다. 이 메일에 답장으로 공유해주시면 다음 뉴스레터에서 소개해볼게요.