VSCode를 사용하다가 Orca로 옮긴 후기

많은 사람들이 코딩 에이전트를 터미널에서 사용하곤 합니다. VSCode에서 터미널을 하나 열고 클로드 코드(Claude Code)나 코덱스(Codex)를 실행하면, 에이전트가 파일을 읽고 고치는 과정을 편집기에서 그대로 볼 수 있기 때문입니다. 저도 한동안은 VSCode를 사용해 코딩 에이전트를 아무 문제 없이 편리하게 사용했습니다.

하지만 문제는 두 번째 에이전트를 켤 때 생깁니다. 터미널을 하나 더 열어 다른 에이전트를 실행하면, 두 에이전트가 같은 작업 디렉터리를 보고, 한쪽이 파일을 고치는 동안 다른 쪽도 같은 파일을 읽습니다. 브랜치도 하나뿐이라 서로 다른 두 작업의 변경 사항이 한곳에 섞이게 됩니다. 이 상태에서 커밋을 하려고 하면, 어느 줄이 어느 작업의 결과인지 되짚어봐야 하는 번거로운 문제가 발생합니다.

이러한 문제를 해결하고자, 여러 에이전트로 병렬 작업을 하기 좋은 도구를 찾아보다가 오르카(Orca)라는 도구를 알게 되었습니다. 최근 2주 반 동안은 오르카(Orca)라는 도구로 옮겨 작업을 해보고 있습니다. 그래서 이번 글은 코덱스와 클로드, 두 에이전트를 함께 쓰는 사람의 기준으로 쓴 이야기입니다. 이 글에서는 오르카가 무엇인지 먼저 소개한 다음, 제가 VSCode를 사용하면서 겪었던 불편과 옮기고 나서 달라진 작업 방식, 그리고 지금까지 확인한 한계를 이야기해보겠습니다.

Orca(오르카)란?

오르카를 설명할 때 먼저 짚어야 할 것은 이것이 새로운 AI 모델이 아니라는 점입니다. 쓰던 에이전트를 그대로 쓰되, 그 에이전트들을 어디에 담아 둘지를 바꾸는 도구입니다.

1) 모델이 아니라 에이전트를 담는 그릇

오르카는 오픈소스 도구로, 공식 사이트에서는 스스로를 에이전트 개발 환경(Agent Development Environment)이라고 소개합니다. MIT 라이선스로 공개되어 있어 소스를 직접 확인할 수 있고, macOS와 윈도우, 리눅스를 지원합니다.

오르카 안에서 돌아가는 것은 클로드 코드, 코덱스, 제미나이(Gemini), 커서 CLI(Cursor CLI)처럼 이미 쓰고 있는 에이전트들입니다. 오르카가 제공하는 것은 모델이 아니라, 그 에이전트들이 각자 어디서 일할지를 정해 주는 자리입니다.

새로운 에이전트 모델이 아니기 때문에, 구독을 새로 늘릴 필요 없이 쓰던 계정을 그대로 연결하면 됩니다. 저는 클로드와 코덱스 계정을 하나씩 등록해 두고 작업에 따라 골라서 사용하고 있습니다.

2) 작업마다 따로 열리는 git 워크트리

오르카의 구조에서 핵심은 워크트리(worktree)입니다. 낯선 이름이지만 git에 원래 있는 기능인데요. 하나의 저장소를 여러 디렉터리로 펼쳐 두고, 각 디렉터리에 서로 다른 브랜치를 올려 두는 방식입니다.

오르카는 작업을 하나 만들 때마다 이 워크트리를 하나씩 생성합니다. 그 결과 에이전트마다 자기 폴더와 자기 브랜치를 갖게 됩니다. A 작업의 에이전트가 파일을 고쳐도 B 작업의 폴더에는 아무 일도 일어나지 않습니다. 또한 같은 파일을 두 에이전트가 동시에 열어도 서로 다른 사본이라 충돌하지 않습니다. 커밋도 각자의 브랜치에 쌓이기 때문에, 나중에 어느 작업의 결과인지 되짚을 필요가 없습니다.

3) 한 화면에 모이는 여러 에이전트

오르카의 또다른 장점은, 이렇게 나뉜 작업들을 한 화면에서 관리한다는 점입니다.

왼쪽에 저장소와 작업 목록이 있고, 작업을 고르면 그 워크트리의 터미널과 변경 사항, 필요하면 브라우저까지 같은 창 안에서 열립니다. 목록에는 어떤 작업이 어느 에이전트로 돌고 있고 어디까지 진행됐는지가 함께 보여서, 터미널을 하나씩 눌러 보지 않아도 누가 무엇을 하는 중인지 알 수 있습니다.

VSCode로 두 에이전트를 돌리며 불편했던 점

VSCode로도 충분히 에이전트를 돌릴 수 있었지만, 에이전트 구독을 두 개로 늘린 뒤부터 같은 불편이 반복됐습니다.

1) 이전 버전을 보고 판단하는 다른 에이전트

자주 걸린 지점은 작업 디렉터리였습니다. VSCode에서 터미널을 두 개 열면 두 에이전트가 같은 폴더를 봅니다. 제가 한쪽에서 이미 고쳐 둔 내용이 있는데도 다른 에이전트는 그 이전 상태를 기준으로 판단해, 엉뚱한 답을 내놓는 일이 있었습니다. 같은 파일의 서로 다른 시점을 보고 있으니 생기는 일이었습니다.

하지만 오르카로 옮긴 뒤에는 이 일이 없어졌습니다. 작업마다 워크트리가 따로 생겨서, 두 에이전트가 같은 사본을 두고 부딪히지 않고, 변경 사항도 작업별 브랜치에 나뉘어 쌓입니다. 어느 시점의 내용을 기준으로 일하는지가 작업 단위로 분명해진 셈입니다.

2) 브랜치를 오가며 생기는 대기

폴더가 하나뿐이라 브랜치를 바꾸려면 작업 중인 내용을 먼저 치워야 합니다. 에이전트가 파일을 고치고 있는 중이라면 그 작업이 끝나기를 기다렸다가 정리하고 브랜치를 옮기게 됩니다.

결국 두 작업을 동시에 진행한다고 생각했지만 실제로는 번갈아 진행하는 형태가 됐습니다. 한쪽이 움직이는 동안 다른 쪽은 멈춰 있어야 했기 때문입니다.

3) 터미널 이름만으로는 알기 어려운 진행 상황

터미널이 두 개에서 세 개로 늘어나면 어느 탭이 무슨 작업인지 이름만으로는 구분되지 않습니다. 보고 있는 답변이 코덱스가 낸 것인지 클로드가 낸 것인지도 출력을 한참 올려 보고 나서야 알게되는 상황이 자주 발생했습니다.

진행 상황도 마찬가지였습니다. 에이전트가 아직 일하는 중인지 이미 끝내고 멈춰 있는 것인지 알려면 탭을 하나씩 눌러 마지막 출력을 읽어야 했습니다. 오래 걸리는 작업을 맡겨 두고 다른 일을 하다 보면, 이미 끝난 줄 모르고 한참 뒤에 확인하는 경우도 있었습니다.

4) 구독 두 개의 사용량을 따로 세는 번거로움

또한 코덱스를 얼마나 썼고 언제 다시 채워지는지, 클로드는 또 얼마나 남았는지를 작업할 때마다 따로 확인하면서 써야 했습니다. 한 번 보고 끝나는 일이 아니라 맡길 때마다 반복되는 일이라, 나중에는 확인을 미루게 됐고 어느 에이전트에게 맡길지는 그때그때 감으로 정했습니다.

옮기고 나서 달라진 작업 방식

도구를 바꾸면서 기능이 늘어난 것보다, 작업을 나누는 단위가 달라진 쪽이 더 크게 느껴졌습니다.

1) 작업마다 하나씩 생기는 워크트리

작업을 하나 만들 때 제가 하는 일은 이름을 정하고 어떤 에이전트를 붙일지 고르는 것까지입니다. 그 다음은 오르카가 맡아서 그 작업 몫의 워크트리를 실제로 만들어 줍니다. 폴더와 브랜치가 함께 준비되기 때문에, 제가 git 명령을 직접 치지는 않습니다. 예전에는 금방 끝날 일에 브랜치까지 만드는 것이 번거로워서, 쓰던 브랜치에서 그냥 이어가곤 했는데, 지금은 그럴 일이 없어졌습니다.

작업이 끝나면 그 워크트리를 통째로 정리하고, 결과를 더 봐야 하면 남겨 둡니다. 브랜치를 지우고 폴더를 원래대로 되돌리는 일을 따로 하지 않아도 되기 때문에, 작업을 시작하는 것만큼 끝내는 것도 가벼워졌습니다.

2) 작업이 끝나면 오는 완료 알림

터미널을 눌러 확인하는 대신 알림을 받게 되면서 확인하는 습관이 바뀌었습니다. 예전에는 작업이 종료가 됐는지, 작업 중인지 확인을 위해 중간에 몇 번씩 들여다봤는데요, 그때마다 하던 일의 흐름이 끊겼습니다.

작업을 맡겨 두고 다른 일을 하다 보면 시켜 놓았다는 사실 자체를 잊기도 합니다. 하지만 오르카는 작업이 끝나면 알림을 보내줘서, 맡겨 둔 일이 끝났다는 것을 바로 알아차릴 수 있습니다.

알림은 오르카를 띄워 둔 컴퓨터에서만 오는 것이 아닙니다. 계정을 연결해 두면 휴대폰으로도 같은 알림이 옵니다. 오래 걸릴 작업을 맡겨 두고 자리를 떠서 평소 하던 일을 보다가, 끝났다는 알림을 받고 그때 돌아와 확인하면, 시간을 효율적으로 사용할 수 있습니다. 작업이 도는 동안 컴퓨터 앞을 지키고 있을 이유가 없어진 셈입니다.

확인하는 것에서 끝나지 않고 휴대폰에서 다음 지시를 바로 넣을 수도 있습니다. 결과를 훑어보고 이어서 시킬 일이 분명하면 자리로 돌아오기 전에 다음 작업을 걸어 둡니다. 돌아왔을 때 그것까지 끝나 있으면 기다리는 시간이 한 번 더 줄어듭니다.

3) 검토 범위가 분명해진 변경 사항

변경 사항이 각 작업의 브랜치에 나뉘어 담기면서 검토하는 방식도 달라졌습니다. 어떤 작업을 볼 때 그 워크트리의 diff만 보면 되기 때문에, 다른 작업의 수정이 섞여 들어오지 않습니다.

이 덕분에 결과가 마음에 들지 않을 때의 대처도 간단해졌습니다. 예전에는 두 작업이 섞인 상태에서 한쪽만 되돌리려면 어느 줄이 어느 작업의 것인지 가려내야 했지만, 지금은 해당 워크트리를 통째로 삭제하면 됩니다.

4) 한눈에 보이는 사용량

사용량을 한곳에서 볼 수 있게 되면서 에이전트를 고르는 기준이 생겼습니다.

오르카는 두 계정의 사용량을 한 화면에 보여 줍니다. 코덱스를 얼마나 썼고 언제 다시 채워지는지가 바로 보여서, 남은 양을 보고 이번 작업을 어느 쪽에 맡길지 정할 수 있습니다. 코덱스가 얼마 남지 않았으면 긴 작업은 클로드로 넘기는 식으로 작업이 가능해집니다.

오르카가 잘 맞는 상황과 그렇지 않은 상황

도구를 바꾸는 데에는 적응 비용이 들기 때문에, 모든 상황에 권할 만한 것은 아닙니다.

1) 에이전트를 두 개 이상 돌리는 사람

여러 작업을 동시에 맡기고, 그 결과를 각각 검토해야 하는 상황이라면 유용합니다. 작업이 서로 다른 브랜치에 나뉘어 있으니 검토할 범위가 분명하고, 하나를 버리더라도 다른 작업에 영향이 없습니다.

구독을 두 개 이상 쓰고 있다면 이점이 더 큽니다. 어느 에이전트에게 무엇을 맡길지 고르는 일이 사용량을 확인하는 일과 한자리에서 이뤄지기 때문입니다.

2) 아직 VSCode가 나은 경우

에이전트를 하나만 쓰고 있다면 지금 쓰는 편집기로도 충분합니다. 확장 프로그램과 단축키, 디버거를 새 환경으로 옮겨 오는 비용이 적지 않은데, 작업을 나눠 맡길 일이 없다면 그 비용을 치르고 얻는 것이 크지 않습니다. 오르카의 이점은 작업이 두 갈래 이상으로 갈릴 때부터 나타나기 때문입니다.

에이전트에게 맡기는 일과 직접 쓰는 일의 비중을 먼저 따져 보시길 권합니다. 맡기는 쪽이 늘고 있다면 옮길 이유가 생기고, 직접 쓰는 쪽이 여전히 많다면 서두를 필요가 없습니다.

아직 확인해야 할 한계점

오르카는 아직 빠르게 바뀌는 중입니다. 제가 쓰는 동안에도 버전이 여러 번 올라갔고, 지금 쓰는 버전은 1.4.205입니다. 화면 구성이나 기능 이름이 글을 읽는 시점과 다를 수 있습니다. 작업 단위로 분리 된다는 점은 장점이면서 동시에 생각할 거리이기도 합니다. 폴더가 나뉘어 있으므로 한 작업에서 설치한 의존성이나 만들어 둔 설정 파일이 다른 작업에는 없습니다. 여러 작업에 공통으로 필요한 준비가 있다면 그 부분을 어떻게 공유할지 정해 두는 편이 좋습니다.

쓰면서 크게 불편했던 점은 아직 없습니다. 굳이 꼽자면 VSCode에서 쓰던 ‘터미널 키퍼(Terminal Keeper)’처럼 폴더마다 어떤 터미널을 띄울지 미리 정해 두는 방식이 없다는 점입니다. 작업을 만들 때마다 터미널이 새로 생기다 보니, 자주 쓰는 구성을 저장해 두고 불러오는 식으로는 쓰지 못하고 있습니다.

마치며

VSCode를 쓸 때에는 에이전트를 하나 더 켜는 일이 곧 관리할 것을 하나 더 만드는 일이었습니다. 그러다보니, 에이전트를 여러개 사용하는 것이 효율적으로 다가오지 않았습니다. 어느 터미널이 무슨 작업인지 기억해야 했고, 두 작업의 변경 사항이 섞이지 않도록 신경 써야 했습니다.

오르카로 옮긴 뒤에는 워크트리와 브랜치가 함께 만들어지고, 에이전트는 자기 폴더 안에서만 움직이기 때문에, 제가 하던 관리 업무가 자연스럽게 훨씬 쉬워졌습니다. 다만 이 장점은 에이전트를 여러 개 돌리는 사람에게 더 크게 돌아옵니다. 현재 하나만 쓰신다면 지금 쓰는 편집기로도 충분하고, 굳이 옮기면서 적응 비용을 치를 이유가 크지는 않습니다. 저처럼 새로운 도구를 경험해보고 싶으시다거나, 에이전트를 여러 개 사용하고 계신 분들에게는 오르카를 사용해 보시는 것을 추천드립니다.

이 글은 AI의 도움을 받아 작성했습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은

“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.