이번 포스팅에서는 Warp 터미널에 대해서 정리하고자 한다. Warp는 Rust로 작성된 터미널로, 기존 터미널이 텍스트를 그냥 흘려보내는 방식을 블록 단위로 재설계하고 AI 명령어 생성을 내장했다. 2026년 4월 기준 GitHub 스타 26,400개, 사용자 70만 명 이상이다. Docker, Google Cloud, OpenAI 팀에서도 쓰고 있다고 한다. 처음에는 “터미널을 예쁘게 만든 거 아닌가?” 싶었는데, 써보면 명령어 입력 방식 자체가 다르다는 것을 알게 된다. 최근에는 Oz라는 클라우드 에이전트 오케스트레이션 플랫폼까지 내놓으면서, 터미널 앱 그 이상의 것을 지향하고 있다.
기존 터미널, 대체 뭐가 불편했던 걸까
iTerm2든 Terminal.app이든 GNOME Terminal이든, 기존 터미널은 텍스트를 위에서 아래로 흘려보내는 구조이다. 명령어와 출력이 하나의 연속된 텍스트로 이어지기 때문에, 5분 전에 실행한 명령어의 결과를 다시 찾으려면 스크롤을 올려가며 눈으로 훑어야 한다. docker logs나 kubectl get pods처럼 출력이 긴 명령어를 연달아 실행하면, 어디서 어떤 명령어의 출력이 시작되는지 구분이 안 된다. 솔직히 이게 불편한지도 모르고 쓰고 있었다.
Warp 터미널은 이 문제를 Block이라는 개념으로 해결한다. 각 명령어와 그 출력이 하나의 독립된 블록으로 묶이고, 블록 단위로 복사, 검색, 공유가 된다. 입력 영역도 코드 에디터처럼 멀티라인 편집과 구문 강조를 지원한다. 기존 터미널에서 긴 명령어를 수정하려면 화살표 키로 한 글자씩 이동해야 했는데, Warp 터미널에서는 마우스 클릭으로 원하는 위치에 커서를 놓고 편집할 수 있다. 이것만으로도 꽤 신세계이다.
설치는 간단하다, 다만 계정이 필요하다
Warp 터미널은 macOS, Linux, Windows를 모두 지원한다.
macOS
# Homebrew로 설치
brew install --cask warpHomebrew가 없는 경우 공식 다운로드 페이지에서 .dmg 파일을 직접 받아 설치할 수 있다.
Linux
# Debian/Ubuntu (.deb)
sudo apt install ./warp-terminal.deb
# Red Hat/Fedora (.rpm)
sudo rpm -i warp-terminal.rpm
# Arch Linux (AUR)
yay -S warp-terminal-binLinux에서는 .deb, .rpm, AppImage를 공식 지원하고, Arch Linux는 AUR에서 설치할 수 있다.
Windows
# winget으로 설치
winget install Warp.WarpWindows 11과 Windows 10 모두 x64, ARM64 아키텍처를 지원한다.
설치 후 첫 실행 시 계정 생성을 요구한다. 이 부분은 호불호가 갈린다. 터미널을 쓰는데 왜 로그인을 해야 하는지 거부감을 느끼는 개발자가 적지 않다. GitHub 또는 Google 계정으로 로그인하면 되고, 개인 사용자는 무료이다. AI 기능을 포함한 모든 기능을 무료로 쓸 수 있으니 비용 걱정은 안 해도 된다.
블록이 뭐길래 다들 얘기하는 걸까
Warp 터미널을 처음 열면 가장 먼저 느끼는 차이가 Block이다. 터미널에서 명령어를 실행할 때마다 해당 명령어와 출력이 하나의 블록으로 묶인다. 실패한 블록은 빨간색 배경으로 표시되어, 어떤 명령어에서 오류가 났는지 바로 보인다.
블록 탐색 단축키
# macOS
CMD+UP / CMD+DOWN — 블록 간 이동
SHIFT+CMD+UP/DOWN — 선택한 블록 내부 스크롤
CMD+클릭 — 블록 다중 선택 (토글)
SHIFT+클릭 — 블록 범위 선택
# Windows / Linux
CTRL+UP / CTRL+DOWN — 블록 간 이동
CTRL+SHIFT+UP/DOWN — 선택한 블록 내부 스크롤
CTRL+SHIFT+클릭 — 블록 다중 선택 (토글)
SHIFT+클릭 — 블록 범위 선택위 단축키를 사용하면 블록 단위로 터미널 출력을 탐색할 수 있다. 기존 터미널에서 Ctrl+F로 텍스트 전체를 검색하던 방식과 달리, 특정 블록을 선택한 뒤 해당 블록의 출력만 복사하거나 공유하는 것이 가능하다. docker compose logs처럼 수백 줄이 쏟아지는 상황에서 특히 유용하다.
출력이 길어서 화면을 넘어가면 Sticky Command Header가 자동으로 표시된다. 스크롤 중에도 현재 보고 있는 출력이 어떤 명령어의 결과인지 항상 확인할 수 있다.
AI 명령어 생성, 생각보다 자주 쓰게 된다
Warp 터미널의 AI 기능은 세 가지가 있다.
AI Command 생성
터미널 입력창에서 자연어로 원하는 작업을 설명하면, Warp AI가 해당 명령어를 자동 생성한다. 예를 들어 “현재 디렉토리에서 3일 이내에 수정된 .java 파일 찾기”라고 입력하면 다음과 같은 명령어를 제안한다.
find . -name "*.java" -mtime -3find의 -mtime 플래그 같은 것은 매번 쓸 때마다 “이게 -3이 3일 이내였나, 3일 이전이었나” 하고 검색하게 되는데, 이런 상황에서 자연어 입력이 실제로 시간을 아껴준다.
Agent Mode
Agent Mode는 한 줄짜리 명령어 제안이 아니라, 여러 단계에 걸친 작업을 대화 형태로 처리한다. “이 프로젝트의 테스트를 실행하고 실패하는 테스트를 고쳐줘”라고 요청하면, 에이전트가 파일을 읽고, 명령어를 실행하고, 코드를 수정한다. Claude Code의 터미널 에이전트와 비슷한 방식이다.
터미널 모드와 에이전트 모드는 인터페이스 상단에서 토글하는 구조이다.
모델 선택과 프라이버시
Warp 터미널은 특정 LLM에 종속되지 않는다. Claude, GPT, Gemini 중에서 골라 쓸 수 있다.
AI 기능을 쓸 때 가장 신경 쓰이는 건 코드 유출 문제이다. Warp는 LLM 제공업체와 Zero Data Retention 정책을 계약했고, SOC 2 인증을 받았다. 그래도 불안하다면 AI 기능만 설정에서 끌 수 있다. Warp 터미널 자체는 AI 없이도 블록 기능, 멀티라인 편집 등 충분히 쓸모가 있다.
Warp Drive와 Workflows, 팀에서 쓸 때 빛나는 기능
Warp Drive는 자주 쓰는 명령어와 워크플로우를 팀 단위로 공유하는 기능이다. 개인 북마크처럼 혼자 저장해 쓸 수도 있고, 팀 전체가 접근 가능한 공유 워크플로우를 만들 수도 있다.
배포 파이프라인에서 자주 실행하는 명령어를 Workflow로 정의해 두면 이런 식이다.
# ~/.warp/workflows/deploy-staging.yaml
name: Deploy to Staging
command: |
git checkout develop
git pull origin develop
./gradlew clean build -x test
docker build -t myapp:staging .
docker push registry.example.com/myapp:staging
kubectl set image deployment/myapp myapp=registry.example.com/myapp:staging -n staging
tags: ["deploy", "staging", "k8s"]위 YAML 파일은 Warp 터미널의 Workflow 정의 예시이다. 한 번 등록하면 Warp Drive에서 검색하거나 팀원에게 공유할 수 있다. 배포할 때마다 “그 명령어가 뭐였지?” 하고 Slack을 뒤지는 대신, 워크플로우 하나를 실행하면 된다.
Oz, 터미널 회사가 왜 에이전트 오케스트레이션을 만들었나
2026년에 Warp가 내놓은 Oz는 솔직히 처음에 좀 의아했다. 터미널 앱 회사가 왜 클라우드 에이전트 플랫폼을? 그런데 써보면 논리가 이해된다. 코딩 에이전트를 대규모로 클라우드에서 실행하고 관리하는 플랫폼이다.
왜 Oz가 필요한가
로컬 머신에서 Claude Code나 Codex 같은 코딩 에이전트를 돌리면, 하나의 작업에 CPU와 메모리를 점유하기 때문에 동시에 여러 에이전트를 실행하기 어렵다. Oz는 이 한계를 클라우드 인프라로 해결한다.
Warp 내부에서도 이미 Oz를 적극 활용하고 있는데, 전체 PR의 60%를 Oz 에이전트가 작성하고 있다고 밝혔다. 또한 사기 탐지 봇을 Oz 위에서 운영한 결과, 하루 아침에 약 6만 달러 규모의 부정 사용을 차단한 사례도 공개했다.
Oz CLI 사용법
# Oz CLI로 클라우드 에이전트 실행
oz agent run --prompt "fix the crash in auth service" --cwd ./myapp
# 로컬에서 에이전트 실행 후 자동 추적
oz --prompt "update README documentation"위 명령어에서 oz agent run은 클라우드에서 에이전트를 즉시 실행하는 것이고, oz만 사용하면 로컬에서 에이전트를 실행하되 자동으로 추적된다. Claude Code, Codex 등에서 만든 Skill이나 .agents/ 디렉토리의 커스텀 에이전트를 그대로 사용할 수 있다. 스케줄링은 Oz 웹 대시보드 또는 CLI에서 cron 기반으로 설정한다.
Oz가 흥미로운 건 Session Sharing이다. 클라우드 에이전트가 작업하는 과정을 링크 하나로 공유할 수 있고, 중간에 사람이 개입해서 방향을 틀 수 있다. 새벽 3시에 cron으로 돌린 에이전트가 이상한 방향으로 코드를 고치고 있으면, 다음 날 아침에 세션 링크를 열어서 확인하고 멈추면 된다.
에이전트가 만든 PR, 브랜치, 계획서 같은 산출물은 Artifacts로 자동 추적된다. 여러 저장소에 걸친 변경도 하나의 세션에서 처리할 수 있고, 기업 환경에서는 자체 인프라에 Oz를 Self-hosting하는 것도 가능하다.
Oz는 무료 사용자를 포함한 모든 Warp 사용자가 쓸 수 있다. Build/Business/Max 플랜에서는 클라우드 에이전트 크레딧이 추가된다.
그래서 iTerm2 대신 써야 하나?
macOS 사용자라면 이 질문을 안 할 수 없다. 정리하면 이런 차이가 있다.
| 항목 | iTerm2 | Warp 터미널 |
|---|---|---|
| 가격 | 무료 (오픈소스) | 개인 무료, 팀 유료 |
| AI 기능 | 없음 | 내장 (명령어 생성, Agent Mode) |
| 블록 기반 출력 | 없음 | 핵심 기능 |
| 팀 협업 | 없음 | Warp Drive, Session Sharing |
| 크로스 플랫폼 | macOS만 | macOS, Linux, Windows |
| tmux 지원 | 네이티브 통합 | 제한적 (자체 탭/패널 사용 권장) |
| 커스터마이징 | 매우 높음 | 테마/키바인딩 수준 |
| 계정 요구 | 없음 | 필수 (로그인 필요) |
| 오프라인 사용 | 완전 지원 | 가능 (AI 기능 제외) |
iTerm2는 20년 가까이 검증되었고, tmux 네이티브 통합이 잘 되어 있고, 계정 없이 바로 쓸 수 있고, 오픈소스이다. 이 장점들은 여전히 강하다.
Warp 터미널은 블록 기반 출력과 AI가 내장되어 있다는 점에서 방향이 다르다. 명령어 문법을 자주 검색하거나, 팀에서 터미널 워크플로우를 맞추고 싶거나, 코딩 에이전트를 클라우드에서 돌리고 싶다면 Warp 터미널이 맞다. tmux 워크플로우가 손에 붙어 있고 로그인 없이 가볍게 쓰고 싶다면 iTerm2를 굳이 바꿀 이유가 없다.
실전 설정, 내 워크플로우에 맞추기
테마 변경
Warp 터미널은 내장 테마 외에 커스텀 YAML 테마를 직접 만들어 쓸 수 있다.
# ~/.warp/themes/my-custom-theme.yaml
accent: "#61AFEF"
background: "#1E1E2E"
foreground: "#CDD6F4"
details: "darker"
terminal_colors:
normal:
black: "#45475A"
red: "#F38BA8"
green: "#A6E3A1"
yellow: "#F9E2AF"
blue: "#89B4FA"
magenta: "#F5C2E7"
cyan: "#94E2D5"
white: "#BAC2DE"
bright:
black: "#585B70"
red: "#F38BA8"
green: "#A6E3A1"
yellow: "#F9E2AF"
blue: "#89B4FA"
magenta: "#F5C2E7"
cyan: "#94E2D5"
white: "#A6ADC8"위 YAML은 Catppuccin Mocha 계열의 커스텀 테마 예시이다. ~/.warp/themes/ 디렉토리에 파일을 저장하면 Warp 설정의 테마 목록에 자동으로 나타난다. 커뮤니티 테마 저장소에서 다양한 테마를 다운로드할 수도 있다.
IntelliJ에서 Warp 터미널 연동하기
Warp는 GUI 애플리케이션이기 때문에 IntelliJ의 Shell path에 직접 지정하는 방식으로는 연동할 수 없다. IntelliJ의 Terminal 설정에서 Shell path는 /bin/zsh, /bin/bash 같은 셸 실행 파일만 지정 가능하다.
실무에서 가장 좋은 방법은 IntelliJ와 Warp 터미널을 별도 창으로 나란히 띄워서 사용하는 것이다. macOS라면 Stage Manager나 Split View로 화면을 분할하면 된다. Warp의 블록 기능과 AI 기능은 Warp 앱 내에서만 동작하므로, 내장 터미널에 억지로 넣는 것보다 별도 창이 훨씬 낫다.
자주 쓰는 단축키 설정
# Warp 핵심 단축키 (macOS 기준)
CMD+D — 화면 세로 분할
CMD+SHIFT+D — 화면 가로 분할
CMD+T — 새 탭
CMD+P — Command Palette
CTRL+SHIFT+R — 워크플로우 검색
CMD+I — Agent Mode 토글위 단축키는 Warp 터미널의 기본 설정 기준이다. Settings > Keybindings에서 원하는 키 조합으로 변경할 수 있다. tmux의 prefix + %나 prefix + " 대신 CMD+D와 CMD+SHIFT+D로 즉시 화면을 분할할 수 있어, tmux 없이도 멀티패널 작업이 가능하다.
결국 바꿀 만한가
지금까지 Warp 터미널에 대해서 정리해 보았다. 솔직히 터미널이라는 것이 수십 년간 기본 구조가 바뀌지 않았는데, Warp가 블록이라는 개념을 도입하면서 처음으로 “아, 이렇게도 되는구나” 하는 느낌을 줬다. AI 명령어 생성은 있으면 편하고, 없어도 살 수 있는 정도인데, 블록 기반 출력은 한 번 익숙해지면 기존 터미널로 돌아가기가 좀 괴롭다.
다만 계정 로그인이 필수라는 점, tmux 지원이 제한적이라는 점은 분명한 단점이다. tmux 기반으로 작업 환경을 완성해 놓은 개발자라면 굳이 바꿀 이유가 없다. 반대로 터미널을 처음 세팅하는 상황이거나, 기존 터미널에 별 애착이 없다면 한 번 깔아보는 것을 권한다. 무료이니 잃을 것은 없다.