요즘은 IDE를 쓰지 않습니다. 코드 수정부터 파일 탐색, 테스트, 검색, 브라우저 확인까지 거의 모든 작업을 터미널 코딩 에이전트에 맡깁니다. 그러다 보니 에디터 화면보다 여러 터미널과 에이전트 세션을 어떻게 관리할지가 더 중요해졌습니다.
그래서 최근에는 Orca를 꽤 자주 쓰고 있습니다. Orca는 스스로를 IDE가 아니라 ADE라고 부릅니다. 풀어 쓰면 Agent Development Environment, AI 에이전트와 함께 개발하기 위한 환경이라는 뜻입니다.
저는 Orca를 새 IDE로 보지 않습니다. 흩어져 있던 터미널 창과 에이전트 세션을 작업 단위로 묶어주는 터미널 대체제에 더 가깝게 느꼈습니다. 코드를 직접 편집하는 창보다 여러 작업을 나눠 맡기고, 진행 상황을 오가며 결과를 검토하는 작업실입니다.
제가 실제로 쓰고 있는 Orca 화면입니다. 왼쪽에는 여러 프로젝트와 워크트리별 에이전트 상태가 모이고, 가운데에는 터미널, 오른쪽에는 현재 브랜치의 변경 사항이 배치됩니다.
Orca ADE는 무엇이 다른가
Orca는 Claude Code, Codex, OpenCode 같은 터미널형 코딩 에이전트를 한곳에서 실행하고 관리하는 오픈소스 도구입니다. 공식 사이트도 핵심을 “여러 에이전트를 격리된 워크트리에서 나란히 실행한다"고 설명합니다.
Orca가 새 AI 모델을 제공하는 서비스는 아닙니다. 제가 이미 쓰고 있는 CLI 에이전트를 불러와 각각의 작업 공간과 터미널, 변경 사항을 관리합니다.
일반 터미널은 창과 탭, 셸 세션을 중심으로 움직입니다. Orca는 작업 단위인 워크트리부터 보입니다. 기능 하나, 버그 하나, 실험 하나를 별도 워크트리로 만들고 그 안에 에이전트 세션과 터미널, 에디터, 브라우저를 묶습니다.
그래서 제게 Orca의 비교 대상은 IDE보다 기존 터미널에 가깝습니다.
Orca 공식 저장소가 제공하는 이미지입니다. 데스크톱에서 여러 에이전트와 워크트리를 관리하고 모바일 컴패니언으로 상태를 확인하는 구성을 보여줍니다.
가장 좋은 점은 병렬 작업입니다
제가 Orca에서 가장 만족한 부분은 여러 에이전트를 동시에 돌리는 흐름입니다.
제가 쓰는 날을 예로 들면, Android 빌드 문제를 추적하는 세션을 기다리면서 CUDA 조사 결과를 보고 곧바로 블로그 작업으로 넘어갑니다. 저장소와 워크트리가 갈려 있으니 한 에이전트의 수정이 다른 작업에 섞이지 않습니다.
Orca의 워크트리는 이름만 붙인 가상 공간이 아닙니다. 실제 git worktree를 사용합니다. 각 작업은 별도 브랜치와 별도 디렉터리, 별도 파일을 가집니다. 터미널에서 평소처럼 git status, git rebase, git cherry-pick을 써도 되고 Orca가 변경 사항을 다시 읽습니다.
여러 터미널 창만 늘어놓았을 때와도 다릅니다. 왼쪽 사이드바에서 어떤 에이전트가 작업 중인지, 응답을 기다리는지, 끝났는지를 보고 필요한 세션으로 바로 넘어갑니다.
예전에는 에이전트 하나에게 일을 시키고 끝나기를 기다렸습니다. 지금은 첫 번째 에이전트가 긴 빌드를 돌리는 동안 두 번째 작업으로 넘어가고, 두 번째가 자료를 읽는 동안 세 번째 결과를 검토합니다.
에이전트 세 명이 세 배 빨라지는 건 아닙니다. 다만 제가 한 세션의 대기 시간에 붙잡히지 않게 됐습니다. 직접 써보니 이 차이가 꽤 컸습니다.
같은 문제를 여러 에이전트에게 맡길 수도 있습니다
한 문제에 여러 답을 받아볼 때도 병렬 작업이 쓸모 있었습니다. 같은 문제를 Claude Code와 Codex에 각각 맡기고 결과를 비교할 수 있습니다.
Orca 공식 문서도 같은 기준 브랜치에서 세 개의 워크트리를 만들고, 같은 프롬프트를 세 에이전트에게 넣은 뒤, 각 변경 사항을 비교해 가장 나은 결과를 고르는 흐름을 소개합니다.
어려운 버그나 설계 판단에서는 이 병렬 비교가 특히 유용했습니다. 에이전트 하나의 첫 답을 계속 수정시키는 것보다 독립된 접근을 나란히 받아보면 어디서 의견이 갈리는지 바로 보입니다. 결과가 좋은 하나만 남기고 나머지 워크트리를 지우면 됩니다.
다만 매번 이렇게 할 필요는 없습니다. 모델 사용량도 늘고, 세 결과를 검토하는 비용도 생깁니다. 저는 답이 명확한 단순 작업보다 원인 추적이나 구현 방향이 여러 개인 문제에서 더 가치가 컸습니다.
터미널과 브라우저가 같은 작업 안에 있습니다
터미널과 브라우저가 작업별로 묶이는 점도 편했습니다.
각 워크트리에는 실제 Chromium 브라우저가 들어갑니다. 주소창과 방문 기록, 개발자 도구를 쓸 수 있고 브라우저 탭과 스크롤 위치도 워크트리마다 따로 유지됩니다. 다른 작업으로 이동했다가 돌아와도 그 작업에서 보던 페이지가 그대로 남습니다.
웹 화면을 수정할 때는 에이전트가 코드를 바꾸고, 같은 작업의 브라우저에서 결과를 열어보고, 다시 터미널에서 로그를 확인하는 흐름이 한 창 안에서 이어집니다. 터미널과 브라우저를 별도 앱으로 오가며 어느 프로젝트의 개발 서버였는지 다시 찾는 일이 줄었습니다.
브라우저는 에이전트가 CLI로 조작할 수도 있습니다. 제가 열어둔 탭을 같은 세션의 에이전트에게 확인시켜보면, 서로 다른 화면을 보고 엇갈리는 일이 확실히 줄었습니다.
제게 Orca는 IDE가 아니라 터미널 대체제입니다
다른 IDE가 파일 편집기를 중심에 두고 터미널을 보조 도구로 붙였다면, Orca는 순서가 반대입니다. 가운데 놓인 여러 터미널과 에이전트 세션이 중심이고, 파일 브라우저와 편집기, Git diff 화면이 그 주변을 받칩니다. 직접 써보면 다중 터미널에 IDE 기능을 끼워 넣은 느낌에 가깝습니다.
터미널이 중심이라고 해서 소스 검토가 불편한 건 아닙니다. 에이전트가 작업을 마치면 같은 워크트리의 파일 브라우저에서 수정된 소스를 열고, diff 화면에서 바뀐 줄을 이어서 확인할 수 있습니다. 검토하다가 다시 터미널로 돌아가 후속 지시를 내리는 흐름도 자연스럽습니다.
지난 OMP 글을 쓸 때만 해도 “코드 편집은 에디터에서 한다”고 적었습니다. 지금은 그마저도 달라졌습니다. 이제 IDE를 쓰지 않고 파일 수정과 검토까지 터미널 에이전트 안에서 처리합니다.
Orca를 켜면 파일보다 사이드바의 세션 상태부터 봅니다. 결과가 나온 세션으로 옮겨가 검토하고, 막힌 세션에는 답을 준 뒤 다음 작업을 띄웁니다. 예전에는 여러 터미널 창과 탭을 오가며 하던 일입니다.
이 흐름을 직접 겪고 나니 ADE라는 이름도 이해됐습니다. Orca는 IDE에 AI 채팅창을 하나 더 붙인 도구가 아니라, 여러 터미널 에이전트가 동시에 일하는 상황을 기준으로 작업 공간을 다시 만든 도구였습니다.
가장 아쉬운 점은 터미널 인라인 이미지입니다
제가 Orca를 쓰며 가장 아쉬웠던 점은 터미널 안에서 이미지가 보이지 않는다는 겁니다.
오마이파이를 쓸 때는 에이전트가 이미지를 열어 확인하면 같은 그림이 터미널 안에 바로 나타납니다. 에이전트가 무엇을 보고 판단하는지 저도 그 자리에서 확인할 수 있어서 편했습니다. 스크린샷이나 다이어그램을 놓고 작업할 때는 터미널을 벗어나지 않아도 됐고요.
Orca에서는 에이전트가 이미지를 읽어도 제 터미널에는 그림이 나타나지 않습니다. 결국 파일을 별도로 열어야 합니다. 여러 세션을 오가며 작업하는 Orca의 흐름은 편한데, 이미지 확인에서 한 번씩 끊기는 게 꽤 아쉽더라고요.
이 문제는 Orca GitHub의 이슈 #6880에도 올라와 있습니다. 이슈에 기록된 테스트에서는 iTerm2 인라인 이미지와 Kitty 그래픽 프로토콜 모두 그림 대신 빈 공간이 나타났습니다. 2026년 7월 15일 현재 이 이슈는 P1 우선순위로 열려 있습니다.
다행히 PR #7775는 터미널에 인라인 이미지 애드온을 붙여 SIXEL, iTerm2 IIP, Kitty 그래픽 프로토콜을 지원하는 작업입니다. 자동 테스트는 대부분 통과했습니다. 다만 수동 스모크 테스트가 남아 있어 아직 병합되지는 않았습니다.
저에게 인라인 이미지는 장식 기능이 아닙니다. 에이전트와 같은 화면을 보면서 판단할 수 있게 해주는 기능입니다. OMP에서 이미 그 편리함을 익힌 만큼 Orca에도 빨리 들어오길 기다리고 있습니다.
누구에게 잘 맞을까
하나의 저장소에서 한 번에 한 가지 작업만 하고, 터미널 에이전트도 하나만 쓴다면 기존 터미널만으로 충분할 수 있습니다. 그런 사용에서는 Orca의 워크트리 중심 구조가 오히려 복잡하게 느껴질 수 있습니다.
반대로 다음과 같은 상황이라면 장점이 분명합니다.
- 여러 프로젝트를 동시에 관리합니다.
- 긴 빌드나 조사 작업을 에이전트에게 자주 맡깁니다.
- Claude Code와 Codex처럼 서로 다른 CLI 에이전트를 함께 씁니다.
- 같은 문제에 여러 접근을 받아 비교하고 싶습니다.
- 터미널, 브라우저, Git 변경 사항을 작업 단위로 묶고 싶습니다.
저에게 Orca는 코드를 더 잘 써주는 도구라기보다, 여러 코딩 에이전트를 실제 작업 흐름에 넣어주는 도구였습니다.
결론: 병렬 작업에 강한 터미널 대체제
Orca를 계속 켜두게 만든 건 병렬 작업이었습니다.
터미널만 여러 개 띄워도 에이전트를 동시에 돌릴 수는 있습니다. Orca에서는 사이드바의 작업 중, 대기, 완료 상태를 훑고 바로 다음 세션으로 넘어갑니다. 워크트리와 파일, 브라우저도 해당 작업에 붙어 있으니 어디에서 무엇을 하던 세션인지 다시 찾는 시간이 줄었습니다.
저는 이제 IDE를 쓰지 않기 때문에 Orca를 IDE 대체제로 평가할 이유도 없습니다. 제가 하루 종일 켜두던 여러 터미널과 에이전트 세션을 얼마나 잘 대신하는지가 더 중요했습니다.
OMP가 하나의 터미널 안에 강력한 코딩 에이전트를 넣어줬다면, Orca는 그런 터미널을 여러 개 띄워 하나의 작업실로 묶어줍니다. 지금 제 개발 흐름에서 Orca는 IDE보다 터미널을 대체하는 도구입니다.
댓글